El costo de un token: cómo funciona el precio de los modelos
"Las facturas de los modelos se miden en tokens, no en palabras ni solicitudes. Entender qué es un token, y cuáles pagas, mantiene el costo predecible."
Cuando usas un modelo a través de una API, no te facturan por solicitud ni por palabra. Te facturan por token. Los tokens son la unidad que el modelo realmente lee y escribe, y casi cada sorpresa en una factura de modelo viene de no entender qué son y cuáles pagas. La buena noticia es que el modelo de precios es simple una vez que ves su forma, y un puñado de hábitos mantienen los costos predecibles. La mala noticia es que las partes que impulsan tu factura suelen ser invisibles en el texto que ves en pantalla.
Este texto explica qué es un token, por qué la entrada y la salida tienen precios distintos, dónde se esconden los tokens ocultos, y cómo estimar y controlar lo que gastarás, todo en principios que siguen siendo ciertos sin importar qué proveedor o modelo uses.
Qué es realmente un token
Un token es un trozo de texto, aproximadamente una palabra, pero no exactamente. Los modelos no leen letras ni palabras enteras; dividen el texto en piezas que quedan en algún punto intermedio. Una palabra corta común puede ser un solo token, mientras que una palabra más larga o menos común puede partirse en dos o tres. Los espacios, la puntuación y el formato también cuentan. La regla general que la gente usa es que un token es en promedio un poco más corto que una palabra, pero la única forma de saberlo exactamente es dejar que el tokenizador del modelo cuente.
La consecuencia importante es que el conteo de tokens no se mapea limpiamente a tu intuición sobre la longitud. El texto denso, técnico o no inglés puede usar más tokens por palabra que la prosa inglesa simple. El código, con su puntuación y símbolos, puede ser pesado en tokens. Así que "qué tan largo es mi texto" es la pregunta equivocada; "cuántos tokens es mi texto" es la que le importa a tu factura, y las dos pueden divergir más de lo que esperas.
Los tokens de entrada y de salida tienen precios distintos
Cada interacción con un modelo tiene dos flujos de tokens, y casi siempre cuestan cantidades distintas. Los tokens de entrada son todo lo que envías: el prompt, las instrucciones, cualquier documento o ejemplo que incluyas. Los tokens de salida son todo lo que el modelo genera de vuelta. Los proveedores tarifan estos dos por separado, y los tokens de salida suelen ser los más caros de los dos.
La razón está enraizada en cómo funciona la generación. Leer la entrada es una sola pasada; el modelo lo absorbe todo y lo procesa. Producir la salida ocurre un token a la vez, cada paso un cómputo nuevo que depende de todo lo generado hasta ahora. Esa producción paso a paso es la parte costosa, por lo que la salida generada suele cargar un precio más alto que la entrada a la que respondió. Saber esto cambia cómo optimizas: una salida larga suele ser una palanca mayor sobre tu factura que una entrada larga.
Los tokens ocultos que impulsan tu factura
La sorpresa de facturación más común viene de tokens que nunca tecleaste explícitamente. Destacan tres fuentes.
Primera, las instrucciones del sistema y el contexto que reenvías. En una conversación, el modelo no tiene memoria entre turnos, así que para mantener la continuidad, las aplicaciones reenvían la conversación previa y cualquier instrucción permanente con cada solicitud. El costo de ese historial se paga de nuevo en cada turno. Una conversación larga se vuelve más cara por mensaje a medida que crece, porque cada mensaje nuevo arrastra toda la transcripción consigo como entrada.
Segunda, el contenido recuperado o adjunto. Cuando le das a un modelo documentos con los que trabajar, cada uno de esos tokens es entrada que pagas. Una función que mete documentos grandes en el prompt puede costar silenciosamente mucho más por llamada de lo que la pregunta corta del usuario sugeriría.
Tercera, el propio trabajo intermedio del modelo. Algunos modelos producen razonamiento interno antes de su respuesta final, y ese texto intermedio es salida generada por la que normalmente te facturan aunque no se le muestre al usuario. Una respuesta visible corta puede asentarse sobre un volumen mucho mayor de generación pagada.
Por qué la ventana de contexto importa para el costo
Cada modelo tiene una cantidad máxima de texto que puede considerar de una vez: su ventana de contexto. Es tentador tratar una ventana de contexto grande como espacio libre para volcarlo todo, pero la ventana es una capacidad, no un presupuesto. Sigues pagando por cada token que pones dentro de ella. Llenar una ventana grande hasta el borde significa pagar por una entrada grande en cada llamada.
La ventana sí impone un techo duro: entrada más salida no pueden excederla. Pero la disciplina práctica es usar mucho menos del máximo. Cuantos menos tokens envíes para lograr la tarea, menos cuesta cada llamada y, a menudo, más rápido devuelve. Una ventana grande es una conveniencia para el trabajo grande ocasional, no una licencia para ser derrochador en los rutinarios.
Estimar y controlar el gasto
Puedes pronosticar los costos antes de siquiera publicar. La aritmética es directa: estima los tokens típicos de entrada y de salida por llamada, multiplica cada uno por su precio respectivo, y multiplica por cuántas llamadas esperas. Hacer esto en una servilleta antes de construir atrapa los diseños caros mientras todavía son baratos de cambiar.
Para controlar el gasto una vez en marcha, unos pocos hábitos hacen la mayor parte del trabajo. Recorta lo que envías: descarta historial de conversación que no necesitas, resume el contexto largo en vez de reenviarlo literalmente, e incluye solo los documentos que importan. Pon tope a la longitud de salida cuando la tarea lo permita, ya que la salida es el flujo más caro. Recurre a un modelo más pequeño y barato para el trabajo rutinario y reserva el caro para las llamadas que genuinamente lo necesitan. Y mide el uso real en vez de confiar en estimaciones, porque los conteos de tokens reales sobre tráfico real son los únicos números que pagan la factura.
Una intuición rápida trabajada
Imagina un asistente de soporte. Un usuario teclea una pregunta de una línea: entrada minúscula. Pero tu sistema también envía una página de instrucciones permanentes, los últimos varios turnos de la conversación y tres artículos de ayuda recuperados. Las palabras visibles del usuario son un error de redondeo; la entrada real son las instrucciones, el historial y los artículos, repetidos en cada turno. Si el asistente luego escribe una respuesta exhaustiva de varios párrafos, esa salida puede costar más que toda la entrada junta. Ver la llamada así —la mayor parte del costo en lugares que el usuario nunca ve— es toda la idea. Optimizar la pregunta visible no ahorraría nada; recortar el contexto invisible y la longitud de salida es donde está el dinero.
En resumen
Los tokens, no las palabras ni las solicitudes, son lo que pagas, y los tokens que impulsan tu factura suelen ser los que no ves: historial de conversación reenviado, documentos adjuntos, instrucciones permanentes y la propia generación intermedia del modelo. La entrada y la salida tienen precios separados, y la salida suele costar más. Una ventana de contexto grande es capacidad que pagas por llenar, no espacio libre. Estima con aritmética simple antes de construir, recorta lo que envías y pon tope a lo que generas, y mide el uso real. El precio por tokens recompensa a quienes saben exactamente qué están enviando y castiga a quienes no.
