La mitad de tu cuenta de IA es el modelo pensando en voz alta

La mitad de tu cuenta de IA es el modelo pensando en voz alta

La mitad de tu cuenta de IA es el modelo pensando en voz alta

Sé perfectamente el día en que entendí por qué mi cuenta de API se disparaba. Corrí un agente con una tarea de unas veinte líneas y al revisar el usage vi la wea: 800 tokens de respuesta, 40.000 de razonamiento. El modelo no estaba respondiendo; estaba pensando en voz alta y yo pagando cada pensamiento.

El costo escondido de los modelos que piensan

Los modelos de razonamiento gastan la mayoría de sus tokens —a veces más del 90%— en pensamiento interno, no en la respuesta. En una llamada suelta es molesto. En un flujo agéntico es una estafa matemática: cada vuelta le reenvías todo el razonamiento previo al modelo, así que el contexto crece casi cuadrático con la cantidad de pasos. El razonamiento largo del turno uno se relee y se refactura en cada llamada posterior. Traducción chilena: mientras más se enreda el agente, más caro se pone el enredo.

La respuesta obvia de la industria fue ponerle un tornillo: bajar el «reasoning effort» y listo. Cualquiera que lo haya intentado sabe cómo termina. Bajas el esfuerzo, el modelo deja de dudar y de reconsiderar, y la calidad se cae por la borda. No es lo mismo pensar rápido que pensar mal, pero los knobs de configuración te obligan a elegir entre las dos cosas.

La solución era entrenarlo, no configurarlo

Por eso me llamó la atención lo que hizo Fireworks con Ember-1: partieron de Kimi K3, un modelo de razonamiento, y en vez de pedirle que piense menos con parámetros, lo entrenaron para que piense menos. Más de 50 experimentos de entrenamiento para que el modelo aprenda a distinguir la reflexión que sirve —retomar una suposición, corregir en base a feedback— del loop inútil de «ya lo intenté y no funcionó, déjame intentarlo igual pero con otras palabras».

El resultado es incómodo para quien vendía tokens: misma calidad con un 40% menos de tokens. En benchmarks de código como SWE-bench Verified quedó casi clavado con el modelo base a máximo esfuerzo, y en pruebas A/B en producción real de clientes, un 35% de ahorro por tarea. El detalle que más me gustó: cuando corrían el modelo internamente con sus propios desarrolladores, nadie se dio cuenta del cambio. Cero noticias. Para un modelo cuya única promesa es «las mismas respuestas, menos tokens», que nadie note el cambio es la mejor validación posible.

Lo que esto significa para quien corre agentes

Yo tengo agentes corriendo en cron, haciendo pegas repetitivas mientras duermo. Cada uno consulta APIs de modelos que razonan, y el presupuesto mensual crece con cada tarea. He visto sesiones donde el modelo entra en un bucle de autocrítica que no aporta nada y donde el 80% de la factura es el modelo dudando de sí mismo. Con razonamiento a $15 por millón de tokens de salida, un loop mal cerrado cuesta más que el trabajo que estaba automatizando.

La lección que me llevo es simple y un poco incómoda: el ahorro ya no está en apagar el razonamiento, está en modelos especializados que aprendieron a razonar eficientemente. La forma más barata de correr un modelo grande dejó de ser «configurar menos esfuerzo» para pasar a ser «usar la versión que aprendió a pensar menos sin pensar peor». Es la diferencia entre pedirle a un becario que no piense tanto y contratar a alguien que ya sabe cuándo vale la pena pensar.

Si tu cuenta de IA se te está comiendo el presupuesto, hazme caso: mira cuánto de eso es razonamiento interno. Probablemente estás pagando caro por un modelo dudando en voz alta sobre cosas que ya resolvió hace tres turnos.

Fuente de inspiración: Introducing Ember-1 (Fireworks AI)

Comentarios

Aún no hay comentarios. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *