Capítulo 14 — Economía del token y precios de API

Publicado el: 2026-05-06 Última actualización el: 2026-07-07 Versión: 1
Capítulo 14 — Economía del token y precios de API

Capítulo 14 — Economía del token y precios de API

Decimocuarta entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que conecta la física del Capítulo 1 con las líneas de la factura — y explica por qué la factura del primer mes muchas veces no se parece en nada al modelo del equipo.


Por qué existe este capítulo

Los capítulos anteriores trataron el coste de la inferencia como un hecho físico — bytes movidos por HBM, FLOPs gastados en un matmul, segundos-GPU consumidos por una petición. Ese encuadre es correcto para el equipo dueño del silicio. Para la población mucho mayor de equipos que compran inferencia a una API, la superficie de coste está reformada por la unidad por la que cobra el proveedor: el token. El Capítulo 14 trata de por qué el token está precificado como está, por qué los lados de entrada y salida de la misma llamada tienen precios tan distintos, y de qué modo tan silencioso el historial de conversación de un chatbot y el pensamiento invisible de un modelo de razonamiento acaban en la factura.

En una línea: el token se cobra porque mapea casi linealmente al cómputo que gasta el proveedor, pero el token de entrada y el de salida son dos objetos de coste distintos, y el equipo que los trata como uno se lleva una sorpresa.

14.1 La salida cuesta 4–8× la entrada porque el decoding es la fase limitada por ancho de banda

Un token de entrada cabalga la ruta de prefill — denso, limitado por cómputo, paralelo entre todas las posiciones del prompt, exactamente la carga para la que las GPUs están diseñadas. En un modelo de 70B, un H100 se traga decenas de miles de tokens de entrada por segundo porque la operación es un matmul ancho con alta intensidad aritmética. Un token de salida cabalga la ruta de decode — secuencial, limitado por ancho de banda de memoria, un token por forward pass, cada paso leyendo la caché KV entera desde HBM. El mismo H100 produce 50–100 tokens de salida por segundo por petición. La proporción entre ambos throughputs es la proporción que la hoja de precios refleja. Los modelos frontera en 2025 cobran de dos a cinco dólares por millón de tokens de entrada y de diez a treinta dólares por millón de salida — una asimetría de 4:1 a 8:1 que no es una decisión de margen sino un pass-through directo de la asimetría de cómputo subyacente. La entrada cacheada es aún más barata porque el proveedor ya pagó el coste de prefill en una petición anterior. Las APIs de batch son a mitad de precio porque el proveedor puede meter el trabajo en ventanas de capacidad ociosa. Los tokens de razonamiento son tokens de salida porque eso es lo que son dentro del motor.

14.2 La palanca de optimización depende de la forma entrada/salida

El error es modelar el coste con un único número mental — "los tokens cuestan X" — en vez de descomponer entrada y salida por separado. Un triage de atención al cliente con mucho contexto que envía 8.500 tokens de entrada y recibe una respuesta de 600 tokens está dominado por el coste de entrada al precio de frontera (aproximadamente 255 $ de entrada frente a 90 $ de salida por cada 10.000 peticiones al día). Un sistema de redacción de textos largos al mismo volumen — 2.200 tokens de entrada, 3.000 tokens de salida — está dominado por la salida (66 $ de entrada frente a 450 $ de salida). El consejo de optimización es opuesto en los dos casos: acortar el prompt en el primero, acortar la respuesta en el segundo, y enrutar a un modelo cuyo perfil de precios favorezca el eje dominante. Una segunda descomposición que vale la pena hacer es por tenant o por carga. Los sistemas multi-tenant casi siempre muestran una asimetría en ley de potencias donde el 10 por ciento superior de tenants representa la mitad o más del gasto, y el trabajo de optimización de coste dirigido a esos tenants paga varias veces más que el trabajo uniforme repartido por la cola larga.

14.3 La acumulación de contexto y los tokens invisibles de razonamiento inflan la factura

El token más caro es el que el equipo olvidó que estaba enviando. Las APIs son sin estado; cada petición envía el historial completo de conversación como entrada en cada llamada. El coste de entrada acumulado a lo largo de una conversación de N turnos crece cuadráticamente en N, menos el crédito del caché de prefijo. Un equipo que dimensionó su sistema sobre una base de un turno descubre, seis meses después, que su conversación promedio abarca ya ocho turnos y que su coste de entrada por conversación se ha multiplicado aproximadamente como el cuadrado. El segundo multiplicador silencioso son los tokens de razonamiento. Modelos como o1/o3, el pensamiento extendido de Anthropic, DeepSeek R1 y las variantes de razonamiento de Google producen un gran volumen de pensamiento interno antes de la respuesta visible — a menudo 4.000–8.000 tokens detrás de una respuesta visible de 500 tokens. Esos tokens cabalgan el mismo bucle de decode de salida y se cobran como salida; no se devuelven al llamador salvo que el código los pida. La mitigación es instrumentar el objeto usage de la respuesta correctamente — prompt_tokens, cached_prompt_tokens, completion_tokens, reasoning_tokens, y cualquier categoría específica del proveedor — y marcar las categorías desconocidas en vez de tirarlas en silencio. Cada nueva dimensión facturada que el proveedor añada debe aparecer en el esquema de uso del equipo, o la siguiente factura es una sorpresa.

Vale la pena recordar: un esquema de logging de uso con solo "tokens de entrada" y "tokens de salida" es un esquema que va a absorber en silencio cada nueva categoría de facturación que el proveedor introduzca. Loguea cada dimensión revelada por separado, marca las desconocidas y re-descompón los costes cada trimestre.

Lo que prepara el Capítulo 14

Una vez que el equipo puede leer su propia factura con la descomposición entrada-frente-a-salida, por tenant y por categoría, la siguiente pregunta — la que hará finanzas — es si el equipo debería estar pagando por token en absoluto. El Capítulo 15 recorre la alternativa: llevar la inferencia a casa, alquilar o comprar GPUs, y pagar por hora-GPU en su lugar. La aritmética del punto de equilibrio es limpia. Lo que es menos limpio, y lo que la mayoría de los equipos subestima, es todo lo que hay en el lado dedicado del libro que no está en la factura de la GPU: la ingeniería de plataforma, los parches de seguridad, la coreografía de actualización de modelo, la rotación de on-call que responde cuando un nodo se cae de la flota.


Próximamente — Capítulo 15: APIs serverless frente a infraestructura dedicada. La fórmula del punto de equilibrio, el renglón oculto y las posturas híbridas donde ambas es la respuesta correcta.

¿Quieres el panorama completo? El capítulo del libro incluye las dataclasses ejecutables TokenPricing y UsageRecord, la función de coste acumulado de conversación que cuantifica el término cuadrático, el ejemplo trabajado del coste diario del "agente que creció", y las cápsulas "In Plain English" sobre por qué la salida cuesta más y cómo corre el contador cuando nadie está mirando. Consulta LLM Primer VI en Amazon →

SHO
SHO
CTO y Fundador de RECEIPTROLLER. Enfocado en datos, impulsado por la innovación, siempre curioso.