SERIE IA VERDE — La mecánica de los costos. R&D

SERIE IA VERDE — La mecánica de los costos

Laboratorio de Tecnología · Possition IA · R&D Lectura ~10 minutos · Nivel: informático sin experiencia previa en modelos de lenguaje Autor: Mg. Díaz Santiago Raúl — Possition IA

Casi todo el mundo entra a la factura de un modelo de lenguaje por el mismo lado: mira el precio por millón de tokens, lo compara con otro proveedor y elige. Después llega el resumen del mes y no cierra. La sensación es siempre la misma: "yo no consumí tanto".

Sí consumiste tanto. Lo que no viste es qué se consumió.

Este artículo no trae precios ni recetas de infraestructura. Trae la mecánica: de dónde sale cada peso de la factura.

1. El token es la foja, no la idea

Un modelo no lee palabras. Lee pedazos de texto de longitud variable —los tokens— que salen de un vocabulario fijo de unos cien mil símbolos. Ese vocabulario no se armó por criterios lingüísticos, sino por economía de cómputo: se parte de los bytes y se van fusionando los pares de caracteres más frecuentes del texto de entrenamiento hasta llegar a un diccionario de tamaño manejable.

La consecuencia es directa. Un expediente no se mide en argumentos: se mide en fojas. Dos escritos con la misma tesis cuestan distinto si uno ocupa el doble de papel. El token es la foja del modelo: nadie te cobra por lo que dijiste, te cobran por cuántas fojas ocupó decirlo.

Y acá aparece el primer sesgo económico, estructural y medible: como el vocabulario se ajustó mayoritariamente sobre texto en inglés, el español se parte en más pedazos. El mismo contenido cuesta entre un cuarto y la mitad más y ocupa más ventana de contexto. No es una decisión del modelo ni del proveedor: es el diseño del tokenizador. Si tu producto habla español, medí ese recargo con tus propios textos antes de creerle a una comparación hecha en inglés.

2. Leer es barato, escribir es caro

Toda llamada tiene dos fases, y son físicamente distintas.

En la primera el modelo lee tu prompt. Todos los tokens entran a la vez, en paralelo: los pesos del modelo se traen una sola vez de la memoria y sirven para procesarlos a todos. Es leer las cuatrocientas fojas del expediente de un saque, hojeando.

En la segunda el modelo escribe. Y acá no hay paralelismo posible: los tokens salen de a uno, y cada token generado obliga a recorrer todos los pesos del modelo otra vez. Es dictar la sentencia palabra por palabra, y antes de cada palabra volver a abrir los cuatro tomos del código completo, de tapa a tapa.

Esa asimetría es el origen del dato más citado y menos entendido de todas las listas de precios: el token de salida cuesta del orden de tres a cinco veces más que el de entrada. No es una decisión comercial arbitraria. Es que en la escritura la placa no está pensando: está esperando que la memoria le entregue datos. El cuello de botella no es el cálculo, es el viaje.

Probalo con un caso típico: seis mil tokens de entrada y quinientos de salida. La entrada es doce veces más larga y, aun así, la respuesta puede explicar la mayor parte de lo que pagás. Tomate treinta segundos y deducí la consecuencia antes de seguir: acortar la respuesta rinde mucho más que acortar la pregunta.

De ahí salen las decisiones aburridas que más ahorran: formatos breves, techos de longitud explícitos, nada de preámbulos. Y una alerta: los modelos que "razonan" generan un texto interno que se factura como salida —la parte cara— y que muchas veces no se te muestra. Un "sí o no" puede costar miles de tokens sin que veas ni uno.

3. La conversación no crece: se acumula

Este es el factor que funde presupuestos, y casi nadie lo modela.

El modelo no tiene memoria. Ninguna. Cada vez que tu usuario escribe, tu sistema le reenvía la conversación entera desde el principio: instrucción de sistema, todos los turnos anteriores y el mensaje nuevo. Lo que en pantalla parece un diálogo continuo es, del lado del motor, una serie de llamadas independientes donde el texto viejo vuelve a pasar por la caja.

La analogía es incómoda pero exacta: como si en cada presentación judicial tuvieras que transcribir íntegramente todas las anteriores antes de escribir el párrafo nuevo. En la foja cuarenta pagás por copiar treinta y nueve escritos para agregar un renglón.

Números sin fórmulas. Instrucción de mil tokens; cada turno agrega seiscientos entre pregunta y respuesta. Turno uno: mil tokens de entrada. Turno diez: seis mil cuatrocientos. Turno veinte: doce mil cuatrocientos. Turno cuarenta: veinticuatro mil cuatrocientos, para aportar seiscientos nuevos. Sumados todos los turnos, más de medio millón de tokens de entrada facturados en una charla cuyo contenido nuevo fue veinticuatro mil: veintiuna veces el contenido.

Lo que conviene retener no es el número: es la forma. El gasto crece más rápido que la charla. Duplicar el largo de la conversación no duplica el gasto de entrada: lo cuadruplica. Por eso el chatbot que era barato en las pruebas —donde nadie pasa del quinto turno— se vuelve caro en producción, donde la gente conversa.

Mitigaciones, con su costo honesto:

• Ventana deslizante. Mandás sólo los últimos turnos. Barato y efectivo; perdés memoria vieja.
• Resumen recursivo. Cada tanto comprimís el historial. Pagás una llamada extra y el gasto vuelve a crecer proporcional al uso.
• Caché de prefijo. El proveedor cobra más barato la parte del prompt que ya vio, pero exige que el arranque sea idéntico byte a byte. Eso vuelve el orden del prompt una decisión económica, no estética: lo invariante primero, lo variable al final. Un nombre de usuario o una fecha en el tercer renglón de la instrucción de sistema invalidan la caché de todo lo que sigue.

La caché abarata el coeficiente, no la forma de la curva. Sólo truncar o resumir devuelve el gasto a un crecimiento proporcional.

4. La memoria que no aparece en la factura

Hay un costo que no está en ninguna línea del resumen y que igual te limita: mientras una conversación está viva, el motor guarda en memoria de video un pequeño registro por cada token ya visto, para no tener que recalcularlo en cada paso.

Ese registro es chico por token y enorme por acumulación. Con ventanas largas, un solo usuario de contexto muy extenso puede ocupar tanta memoria como veinte de contexto corto, y cuando la memoria se llena la latencia de todos empeora. El precio por token se mantiene plano; tu capacidad de atender gente, no.

Acá está el hallazgo más contraintuitivo: el tamaño del modelo no predice su costo. Cuánta memoria consume cada token de contexto depende de una decisión de arquitectura de atención publicada en el archivo de configuración de cada modelo abierto, y entre modelos de escala comparable se observan diferencias de hasta un factor de doce. Un modelo más chico, con una atención mal agrupada, puede necesitar más placas y costar varias veces más por token que otro que lo dobla en tamaño.

De ahí la única disciplina que sirve: el contexto largo no es una función que se activa, es una compra de memoria.

5. Los tokens que nadie tecleó

Antes de discutir el precio por token, conviene contar los tokens que estás mandando sin darte cuenta:

• La instrucción de sistema y los esquemas de herramientas. Las definiciones de una docena de funciones pueden ser varios miles de tokens que viajan en cada llamada, incluso cuando el usuario escribe "hola".
• Los documentos recuperados. Ocho fragmentos de quinientos tokens son cuatro mil tokens de entrada por consulta, y la mayoría no se usa para responder.
• El razonamiento interno. Facturado como salida, invisible en la respuesta.
• Los reintentos. Si el JSON sale mal y reintentás, pagaste dos veces. Con una tasa de fallo de uno en cinco, eso es un recargo del orden del veinticinco por ciento que no aparece en ningún tablero.
• El truncamiento. Chocar contra el máximo de tokens te cobra todo y no te sirve nada: costo con utilidad cero.
• Los agentes. En una arquitectura multiagente el mismo texto se paga tantas veces como agentes lo lean, y otra vez en cada ronda de ida y vuelta. Cinco agentes con tres rondas pueden multiplicar por quince el costo de un circuito lineal.

Sumalos y aparece el diagnóstico que vemos una y otra vez: buena parte de la factura son tokens de entrada que ningún humano escribió.

6. El lote: la palanca que no cuesta nada

Queda una última pieza, y es la más rara de explicar porque no se toca desde el prompt.

Como escribir obliga a recorrer todos los pesos, atender un pedido solo implica pagar ese recorrido completo para una única respuesta. Si atendés treinta y dos pedidos al mismo tiempo, el recorrido se hace una vez y sirve para los treinta y dos. Es el colectivo contra treinta y dos autos haciendo el mismo trayecto.

Por eso un servicio con tráfico esporádico paga la peor tarifa posible, y agrupar pedidos —aunque sea esperando unas decenas de milisegundos— es casi siempre la optimización de mayor retorno. También explica algo que desconcierta a quien viene de la computación clásica: en infraestructura propia, atender más usuarios a la vez baja el costo por respuesta.

7. Cómo comparar modelos, en cinco preguntas

Si mañana tenés que elegir, este es el orden que recomendamos. Notá que el precio de lista entra al final:

1. ¿Cuánta memoria consume cada token de contexto? Es lo que define cuánto hardware necesitás. Se lee en la configuración de atención del modelo, no en su nombre ni en su cantidad de parámetros.
2. ¿Cuántos parámetros lee de verdad? En los modelos de expertos, "activa pocos parámetros" describe el cálculo, no el tráfico de memoria: cuando atendés muchos pedidos juntos, el conjunto termina tocando la enorme mayoría de los expertos y hay que leerlos igual. La ventaja de esa arquitectura está en la calidad que alcanza, no en lo que ahorra al servir.
3. ¿Con cuánta concurrencia vas a operar? La misma pieza de hardware y el mismo modelo dan costos muy distintos según cuántos pedidos agrupes.
4. ¿Cuánto se le infla tu idioma? Medí la fertilidad del tokenizador con tus textos reales.
5. ¿Con qué frecuencia acierta al primer intento? Un modelo que cuesta el doble y no hay que corregir suele ser más barato en producción. Eso no aparece en ninguna lista de precios y sólo se conoce midiendo.

Y una advertencia metodológica, que es la que más nos importa: ningún cuadro de costos elige un modelo. El costo ordena a los candidatos; la decisión la toma la calidad medida en tu tarea, con tus datos y con un criterio de aceptación escrito antes de empezar.

Supuestos y límites. Este artículo es material educativo. Todas las cifras son órdenes de magnitud ilustrativos, tomados de literatura pública y de configuraciones publicadas por los desarrolladores de modelos abiertos; no son mediciones propias, no corresponden a ningún proveedor en particular y no constituyen una recomendación de compra. El ejemplo de la conversación asume una instrucción de sistema de 1.000 tokens, 600 tokens nuevos por turno, 40 turnos, sin caché ni resumen. El rango 3–5× entre token de salida y de entrada es el habitual en listas de precios públicas y varía por proveedor; el argumento físico que lo explica no depende del precio. Las relaciones entre modelos son mucho más robustas que cualquier valor absoluto, y todo despliegue real debe medirse antes de dimensionarse. No se describe aquí el modelo de costos interno de Possition IA.

Autor: Mg. Díaz Santiago Raúl — Possition IA · Laboratorio de Tecnología (R&D) · possition.com