¿Cuánto "piensa" realmente la traducción por IA?

Gemini es una fuente inagotable de sorpresas. Es el mejor LLM de traducción «listo para usar» para la mayoría de los idiomas. Gracias a su capacidad de razonamiento, puedes resolver incluso los problemas más difíciles, como modismos, referencias de anime o tu propia voz de marca™.

El problema es que razonar requiere tiempo. Y razonar cuesta dinero; cada token se factura. Como desarrollador, lo que buscas es tener bajo control ambos factores.

Gemini 2.5 nos lo ponía fácil. Gemini 3 nos lo ha puesto difícil.

Esto es lo que hemos aprendido en los laboratorios de Transept

Qué ha cambiado en Gemini 3

Gemini 2.5 contaba con thinkingBudget: un tope numérico para los tokens de razonamiento. Gemini 3 lo ha eliminado. Su sustituto es thinkingLevel: un ajuste categórico con cuatro valores: minimal, low, medium y high. Ambos parámetros son mutuamente excluyentes; enviar los dos a un modelo Gemini 3 devuelve un error 400 en los SDK actuales.

Esto cambia lo que significa «controlar los costes» en la práctica. Antes podías fijar un límite estricto a lo que estabas dispuesto a gastar. Ahora, depende del modelo gastar lo que considere oportuno según su interpretación de «medium».

Suponemos que el motivo es que los modelos reciben un post-entrenamiento para adaptar la extensión del razonamiento a la dificultad de cada tarea, igual que hacemos los humanos. Por tanto, fijar límites arbitrarios mermaría esta capacidad.

Pero ¿cuántos tokens consumen realmente los niveles low, medium y high?

Los datos

Presentamos una muestra de dos semanas de nuestro tráfico real de traducción: unas 1000 llamadas repartidas entre tres modelos Gemini 3. Los datos de los tokens de razonamiento provienen de usageMetadata.thoughtsTokenCount en cada respuesta, la fuente más precisa posible.

Tokens de razonamiento por modelo

Ese 15.725 no es una errata. Una sola petición de traducción en un modelo Flash, con el ajuste medio, consumió quince mil tokens de razonamiento.

Por lo general, estas inflaciones de tokens ocurren cuando Gemini filtra sus tokens de pensamiento en bruto en la respuesta. Como sabrá, el "pensamiento" del modelo no es realmente lo que piensa, sino más bien resúmenes pulidos; el razonamiento real del LLM se asemeja más a un flujo de conciencia.

Cabe destacar, no obstante, que en este caso concreto, Gemini se dedicó a rumiar tranquilamente la traducción del inglés al ucraniano de un pasaje literario con una frase como "el acero puro rechaza lacas y pinturas". Estuvo aplicando fuerza bruta y leyendo en voz alta unas doce variantes hasta que le gustó el resultado.

Unas semanas más tarde, una actualización: ese 15,725 no fue una muestra aislada de la entrega de Gemini, sino un patrón propio de las tareas complejas.

Con el aumento del tráfico, sobre todo en gemini-3.1-flash-lite, la misma cifra vuelve a aparecer una y otra vez. Se trata de un rango sospechosamente estrecho, entre 15,724 y 15,729, presente en docenas de peticiones, casi todas de modelos Lite devorando auditorías de glosarios. Curiosamente, esto ocurre con el esfuerzo de pensamiento bajo (low), que no es precisamente el ajuste que uno esperaría que fuera el más costoso.

Un modelo que arroja la misma cifra once veces ha tocado techo, no es que haya elegido una redacción concreta. El ajuste de pensamiento bajo (low) se satura en torno a los 15.700 tokens. Como los modelos pequeños como el lite piensan con menos eficacia, las tareas difíciles los empujan a consumir muchísimos tokens; esto nunca ocurre en los modelos más grandes, donde cada token tiene más probabilidades de representar un paso significativo hacia la respuesta.

Además, esta saturación tiene un coste. En Gemini 3, los tokens de pensamiento se descuentan del maxOutputTokens. Una petición que gasta 15.700 tokens en pensamiento apenas deja margen para la respuesta; sin embargo, todo el pensamiento se factura como tokens de salida. Con un presupuesto de 16.000 tokens, la auditoría devolvía resultados vacíos (finishReason=MAX_TOKENS) casi la mitad de las veces en documentos pequeños, lo que nos llevó a investigar.

Aumentar el presupuesto soluciona el síntoma, pero no la causa. Subimos el límite de la auditoría a 32.000 tokens en el ajuste bajo (low), lo que deja unos 16.000 para la salida tras una fase de pensamiento saturada; así dejaron de producirse respuestas vacías. Pero el pensamiento no disminuyó. No se puede limitar en Gemini 3, por lo que sigue consumiendo unos 15.700 tokens; el mayor presupuesto simplemente le da a la respuesta un lugar donde desplegarse.

La única solución real para esa saturación de 16.000 tokens de pensamiento fue reducir el alcance de la tarea.

El ajuste minimal es el único nivel que se comporta como un límite real, con un techo de unos 2.000 tokens. Sin embargo, solo está disponible para los modelos Lite.

Tokens de pensamiento por tipo de tarea (Flash frente a Pro, ambos en ajuste medium)

En traducciones directas, Pro piensa casi la mitad que Flash. Solo lo supera en razonamiento en tareas de reescritura. El esfuerzo de razonamiento va ligado a la dificultad de la tarea, no a la gama comercial del modelo.

Se podría decir que Pro obtiene mejores resultados en las pruebas de traducción precisamente por su capacidad para razonar más a fondo cuando la situación lo requiere.

Conclusiones prácticas

• No configures el thinkingBudget en modelos Gemini 3. O bien se ignorará, o bien provocará un error.
• El nivel medium no tiene un límite superior cerrado. Una estimación realista para el p90 sería de unos 4.000 tokens de pensamiento por llamada, no 2.000.
• Si necesitas un límite de coste estricto, utiliza minimal siempre que sea posible. No tiene sentido interrumpir la generación de respuestas: se te cobrará de todos modos.
• Si facturas por llamada, consulta usageMetadata.thoughtsTokenCount en cada respuesta. El dato no aparece en el cuerpo del mensaje, pero sí se refleja en la factura.
• Con el ajuste medium, Pro tiende a razonar menos que su mediana en tareas sencillas y más en las difíciles. Lite y Flash no presentan esta variabilidad.

Esto convierte a Pro en el mejor modelo para la corrección y el perfeccionamiento por encima del nivel base de los LLM, ya que es ahí donde se activa su creatividad. Para borradores de traducción directos, Flash es mejor opción.

Sin embargo, esto conlleva tiempo y dinero. En Transept, hemos logrado mitigar los costes de Pro mediante una lógica de corrección inteligente que solo recurre a él para las partes más difíciles. También usamos Pro para planificar y tomar decisiones, delegando la ejecución en modelos más pequeños y modelos ajustados.

De esta manera, todo funciona.