Inkling entrena modelos para administrar su presupuesto de razonamiento

OpenRouter informó que las solicitudes que requieren razonamiento pueden consumir entre 10–1000× más tokens que las que no lo requieren. La caída en los precios de los tokens hace que ese intervalo parezca manejable, hasta que el modelo debe decidir cuánto aprovecharlo.

El escalamiento durante la inferencia convirtió la capacidad en un insumo medible

o3, de OpenAI, ayudó a demostrar que un mayor cómputo durante la inferencia podía mejorar el desempeño en pruebas comparativas, lo que desvió la atención de la idea de que casi toda la capacidad debía adquirirse durante el preentrenamiento. A partir de entonces, el cómputo podía aplicarse después de recibir la solicitud mediante una deliberación más prolongada, muestreos adicionales, verificación o búsqueda.

Cuando un desarrollador elige un modelo convencional y una instrucción, el costo de la llamada parece relativamente fijo. Un modelo de razonamiento puede generar distintas cantidades de contenido y consumir diferentes niveles de tiempo y cómputo según cuánto delibere. El desarrollador puede ajustar la calidad durante la inferencia, pero el costo cambia a la par.

La búsqueda durante la inferencia ofreció otra forma de destinar cómputo a ciertas tareas, aunque algunos expertos cuestionaron hasta qué punto se generalizan sus beneficios. Esa salvedad vuelve más importante la asignación. Si cada token adicional mejorara por igual todas las respuestas, la política sería sencilla: gastar tanto como el cliente esté dispuesto a tolerar. Cuando el rendimiento depende de la tarea, “¿cuánto?” se convierte en un problema de optimización independiente.

Los desarrolladores también pagan en forma de latencia. Un modelo que se detiene más tiempo puede mejorar una respuesta, pero en los sistemas interactivos la espera también forma parte de la calidad del producto. El sistema debe sopesar la mejora esperada frente al costo de los tokens, la demora y todo lo que la aplicación pierde mientras el modelo sigue razonando.

Inkling asigna un precio sombra al razonamiento durante el entrenamiento

El lanzamiento de Inkling por parte de Thinking Machines Lab va más allá de permitir que los usuarios soliciten distintos niveles de esfuerzo. Durante las trayectorias de aprendizaje por refuerzo, el laboratorio varió tanto el esfuerzo solicitado como un coeficiente de costo para los tokens de razonamiento, λ. El objetivo de entrenamiento penalizó tanto el incumplimiento de la tarea como el uso de tokens de razonamiento.

Ese coeficiente funciona como un precio sombra del razonamiento. Cuando cambia λ, el modelo no recibe simplemente la indicación de producir una respuesta más corta o más larga. Aprende una política: a partir de la tarea, el esfuerzo solicitado y el precio implícito de seguir razonando, decide si se justifica emplear más cómputo.

Entrenar con una penalización por token implica más que colocar un botón de “rápido” junto a otro de “profundo”. Una modalidad estática exige que el usuario o el desarrollador de la aplicación elija el presupuesto de antemano. En este caso, el modelo aprende cómo debe modificar su comportamiento conforme cambia el presupuesto.

La arquitectura de Inkling permite entender con particular claridad la lógica de asignación. Es un modelo de mezcla de expertos con pesos abiertos, 975B parámetros totales y 41B parámetros activos, entrenado para ofrecer capacidades generales y no especializadas. La mezcla de expertos distribuye el cómputo de forma selectiva entre las distintas partes del modelo. Variar el costo del razonamiento extiende esa selectividad en el tiempo: no solo determina qué capacidad se activa, sino también durante cuánto tiempo debe seguir utilizándola el sistema.

Como un modelo general atiende tareas muy diversas, un solo nivel de esfuerzo resulta poco eficiente desde el punto de vista económico. Algunas solicitudes no justifican una deliberación prolongada; otras sí. Entrenar con distintos valores de λ da al modelo un motivo para diferenciarlas, en lugar de tratar el esfuerzo máximo como la definición predeterminada de calidad.

Inkling por sí solo no puede demostrar que el aprendizaje por refuerzo con penalización por token encuentre el presupuesto correcto para las cargas de trabajo en producción. El presupuesto adecuado depende de la distribución de las tareas, los requisitos de latencia, la calidad de la evaluación y las consecuencias de una falla. Una penalización por token puede enseñar a ahorrar en función de un objetivo de entrenamiento, pero no puede demostrar que ese objetivo valore correctamente un error en el mundo real.

Los tokens más baratos aún pueden encarecer las tareas

Los desarrolladores ya enfrentan esa presión. En un análisis que abarcó más de 100T tokens, cientos de modelos y más de 3M usuarios, OpenRouter encontró que los modelos de razonamiento representaron más de la mitad del uso de tokens, mientras que el uso de modelos con pesos abiertos aumentó de manera sostenida. Esa proporción debe interpretarse con cuidado: las solicitudes que requieren razonamiento pueden consumir muchos más tokens que las que no lo requieren, por lo que concentrar la mayoría de los tokens no implica concentrar la mayoría de las solicitudes.

Cuando una solicitud que requiere razonamiento utiliza entre 10–1000× más tokens, la caída de los precios unitarios no resuelve la cuestión del costo. La reducción del precio por token ha coincidido con un aumento de los costos para los desarrolladores porque los modelos de razonamiento más recientes pueden emplear más tokens para completar una tarea. El insumo se abarató, pero aumentó la cantidad requerida para producir cada resultado útil.

Por ello, los desarrolladores deberían medir el costo de IA por tarea útil, no el precio del token de manera aislada. Una aplicación solo debería consumir una unidad adicional de inferencia cuando la reducción esperada del costo de los errores supere el cómputo y la latencia adicionales. Así, el presupuesto de razonamiento queda vinculado a la decisión que busca sustentar.

En una tarea de pocas consecuencias, el sistema racional puede aceptar una respuesta rápida o recurrir a un modelo más barato. Cuando aumenta el costo de equivocarse, el mismo sistema puede justificar un razonamiento más prolongado, el uso de herramientas, varios intentos en paralelo, la verificación o la revisión humana.

Quienes implementan estos sistemas tampoco pueden utilizar la extensión visible del razonamiento como un indicador confiable de calidad. Los investigadores de alineación de Anthropic encontraron que no se puede confiar en la legibilidad ni en la fidelidad de la cadena de pensamiento y que los modelos pueden ocultar su razonamiento. Es posible medir los tokens de razonamiento emitidos, pero su extensión no permite concluir que el proceso interno del modelo haya sido transparente o correcto. Los equipos deben evaluar la asignación a partir de los resultados, no dejarse impresionar por las transcripciones.

Los pesos abiertos trasladan el control del presupuesto sin eliminar el poder de la infraestructura

Los pesos abiertos permiten que quienes implementan los modelos examinen, adapten y reproduzcan su comportamiento posterior al entrenamiento. No tienen que aceptar la relación opaca que impone un proveedor cerrado entre esfuerzo, latencia y precio. Si los desarrolladores pueden incorporar al modelo el control del esfuerzo durante el entrenamiento y ajustarlo a sus cargas de trabajo, obtienen una alternativa al presupuesto de razonamiento que decida ofrecer un proveedor mediante su API.

La secuencia más amplia de productos de Thinking Machines Lab apunta en la misma dirección. Tinker, su API de ajuste fino, pasó a estar disponible de forma general con compatibilidad para Kimi K2 Thinking, lo que refuerza su énfasis en un comportamiento adaptable después del entrenamiento. Inkling, a su vez, pone a disposición un modelo de vanguardia con pesos abiertos para que terceros puedan implementarlo y experimentar con él. En conjunto, ambas iniciativas trasladan parte del control sobre el comportamiento del modelo, desde el catálogo de productos del proveedor hacia la infraestructura de entrenamiento e implementación del desarrollador.

Los pesos abiertos no descentralizan la infraestructura de razonamiento. Thinking Machines Lab también firmó un acuerdo con Nvidia para instalar más de un gigawatt de chips Vera Rubin, acompañado de una inversión considerable por parte de Nvidia. Los pesos abiertos cambian quién puede definir la política presupuestaria, pero no eliminan la concentración de capital necesaria para entrenar y operar sistemas de vanguardia.

Un desarrollador puede controlar λ sin controlar el centro de datos. Los equipos obtienen más opciones para elegir comportamientos y proveedores, aun cuando los suministradores de cómputo concentrados conserven la capacidad subyacente.

El presupuesto final de razonamiento corresponde al flujo de trabajo

Una política de esfuerzo aprendida es apenas la capa más básica de la asignación de cómputo. El modelo puede estimar si conviene prolongar el razonamiento, pero la organización que lo rodea asume las consecuencias de la decisión.

Los equipos deben tomar las decisiones determinantes en la canalización y el diseño del flujo de trabajo. Deben especificar cuánto vale un resultado correcto, cuánto cuesta un error, cuándo elegir un modelo más grande, cuándo se justifican las herramientas o los intentos en paralelo, qué evidencia cuenta como verificación y en qué momento debe intervenir el criterio humano.

Ningún producto puede depender de la regla “siempre razona más”. Esa regla supone que el cómputo es gratuito, que la latencia no importa y que todos los errores tienen el mismo costo. Un control de esfuerzo dentro del modelo puede ahorrar recursos en una llamada, pero el sistema encargado de asignarlos debe comparar esa llamada con otros modelos, otras herramientas y la opción de no automatizar la decisión.

El modelo puede estimar si el cómputo adicional podría mejorar una respuesta; quien lo implementa debe decidir cuánto vale la pena pagar por esa mejora. Cuando se confunden esas funciones, los proveedores optimizan la capacidad visible mientras los clientes absorben una combinación sin precio explícito de latencia, consumo de tokens y errores residuales.

El λ de Inkling no resuelve este problema de asignación; lo incorpora al objetivo de entrenamiento. El comprador aún debe evaluar los modelos por sus resultados en cada tarea y con varios niveles de esfuerzo, no mediante una sola calificación en una prueba comparativa ni por el precio de cada token.

El intervalo reportado de 10–1000× no es una escalera que deba subirse en todas las tareas. La ventaja de quien implementa el modelo consiste en saber dónde detenerse: cuando el siguiente token cuesta más que el error que podría evitar.