Cuánto cuestan realmente los tokens LLM y cómo pagar por menos

Cada factura de API para un modelo de lenguaje es una factura de tokens, y casi nadie tiene una intuición de cuántos tokens tiene un determinado fragmento de texto. El resultado es la misma sorpresa dos veces al mes: una característica que parecía barata en las pruebas cuesta cuarenta veces más en producción, o una ventana de contexto que "debería encajar" rechaza la solicitud. Ambos son problemas aritméticos y vale la pena aprender la aritmética una vez.

Una ficha no es una palabra.

Los modelos no leen caracteres ni palabras. Leen tokens: fragmentos producidos por un codificador de pares de bytes que aprendió, durante el entrenamiento, qué secuencias ocurren con la frecuencia suficiente para merecer su propio símbolo. Las palabras comunes en inglés son una muestra. Los raros se dividen. Entonces token es uno y tokenization es tres, mientras que una cadena aleatoria como x7Qp2 puede costar cinco.

Las reglas generales que vale la pena seguir:

• prosa inglesa: aproximadamente cuatro caracteres por ficha, o aproximadamente 0,75 fichas por palabra. Un artículo de mil palabras equivale a alrededor de 1300 tokens.
• Código: considerablemente peor. Los identificadores de sangría, puntuación y camelCase se fragmentan. Haga un presupuesto más cercano a tres caracteres por token y trate el código minimizado como su propio desastre: tokeniza mal precisamente porque es inusual.
• Escrituras no latinas: mucho peor otra vez. El chino, el japonés y el coreano suelen tener cerca de una ficha por uno o dos caracteres, por lo que el mismo contenido en japonés puede costar varias veces más que la versión en inglés. El cirílico y el griego se encuentran en el medio.
• JSON: la puntuación es dinero real. Cada comilla, llave, dos puntos y coma es al menos parte de un token, y las estructuras profundamente anidadas con nombres clave largos pueden gastar más en sintaxis que en valores.

Las reglas generales sirven para realizar estimaciones. Cuando sea importante, cuente: el Calculadora de costos y tokens LLM tokeniza lo que pega e imprime el recuento, y también puede mostrar el texto con los límites del token marcados, que es la forma más rápida de comprender por qué una de sus indicaciones es inesperadamente costosa. Ver los nombres de sus propios identificadores romperse en cuatro pedazos explica muchas cosas.

La producción cuesta varias veces más que la entrada.

El detalle de los precios que la gente pasa por alto: los proveedores cobran por separado los tokens que usted envía y los tokens que genera el modelo, y la producción suele ser de cuatro a ocho veces la tasa de entrada. Un mensaje con 10.000 tokens de contexto y una respuesta de 200 tokens está dominado por la entrada. Una pauta con 500 fichas de instrucción que produce un ensayo de 4000 fichas está dominada, en gran medida, por el resultado.

Esto invierte muchos instintos de optimización. Recortar un mensaje del sistema de 900 a 600 tokens ahorra muy poco si el modelo escribe respuestas largas en cada llamada. Decirle al modelo que responda en tres oraciones en lugar de tres párrafos ahorra mucho. Pregunte en qué lado de la transacción se encuentra realmente su carga de trabajo antes de optimizar el lado equivocado.

La calculadora valora el mismo texto para cada modelo de su tabla, tanto a tasas de entrada como de salida, por lo que puede comparar un modelo barato que hace todo el trabajo con uno caro que hace parte del mismo. Los precios de referencia se almacenan localmente y se comparan periódicamente con las páginas del proveedor; trátelos como una ayuda para la planificación y confírmelos con la página de precios del propio proveedor antes de comprometerse con un presupuesto, porque las tarifas varían.

El chat es cuadrático y ahí es donde mueren los presupuestos

Una llamada API única cuesta lo que cuesta. Una conversación reenvía el historial completo en cada turno, por lo que un chat de veinte turnos no cuesta veinte veces un turno: cuesta aproximadamente la suma de una serie en crecimiento. El turno veinte paga nuevamente por los turnos del uno al diecinueve.

Dos consecuencias. En primer lugar, los bucles de agente de larga duración son la forma más cara de uso de LLM y la que con mayor probabilidad se creará en prototipos sin medición. En segundo lugar, el almacenamiento en caché de avisos importa más que cualquier cambio de redacción: los proveedores descuentan los tokens que repiten un prefijo que ya han visto, lo que significa colocar el contenido estable (el aviso del sistema, el esquema, los ejemplos) al principio y la parte variable al final. Reordene el mismo mensaje para que una marca de tiempo cambiante se encuentre en la parte superior y haya invalidado el caché en cada llamada sin cambiar nada más.

Reducir un mensaje antes de enviarlo

La mayoría de las indicaciones de gran tamaño lo son por razones aburridas: alguien pegó un archivo completo cuando tres funciones eran relevantes, y el archivo tiene la mitad de comentarios y líneas en blanco. El Compresor de contexto LLM apunta exactamente a eso: elimina los comentarios del código, colapsa líneas en blanco, sangra y elimina palabras de relleno de la prosa, luego informa cuántos tokens salvó el recorte. En un archivo fuente real que se ejecuta habitualmente entre un 20% y un 40% sin tocar nada que el modelo necesite.

Los cortes manuales que vale la pena hacer antes de eso:

1. Envíe extractos, no archivos. La atención de los modelos tampoco es gratuita; El contexto irrelevante degrada considerablemente las respuestas, además de costar dinero.
2. Pele los troncos a la región defectuosa. Diez mil líneas de resultados exitosos de startups no contribuyen en nada al diagnóstico.
3. Deje caer el texto repetitivo. Encabezados de licencia, importaciones generadas, el mismo descargo de responsabilidad en cada registro.
4. Resumir en lugar de reenviar. En una conversación larga, reemplazar los puntos del uno al quince con un párrafo sobre el estado es el mayor ahorro disponible.

Cuando la entrada realmente no encaja

Las ventanas de contexto son grandes ahora, pero "grande" todavía es finito, y un libro, un año de registros o una transcripción completa excederán uno. Dividir es la respuesta estándar, y dónde se divide es importante: cortar a mitad de una frase o a mitad de una función produce partes que el modelo tiene que adivinar. El divisor rápido divide el texto en fragmentos del tamaño que usted elija respetando los límites y numera las partes para que pueda alimentarlas en secuencia con una instrucción coherente adjunta a cada una.

Una nota sobre las unidades: los tokens no son bytes. El Contador de bytes UTF-8 responde una pregunta diferente (cuánto espacio ocupa el texto en el cable o en una columna de base de datos) y los dos números divergen marcadamente para el texto no latino, donde los bytes por carácter aumentan al mismo tiempo que los caracteres por token disminuyen. Utilice bytes para los límites de almacenamiento y tokens para los límites del modelo, y nunca sustituya uno por el otro.

Un ejemplo trabajado

Suponga que responde veinte preguntas en un documento de treinta páginas. Treinta páginas equivalen a unas 15.000 palabras, es decir, unas 20.000 fichas. Ingenuamente, envía el documento con cada pregunta: 20 × 20 000 = 400 000 tokens de entrada, más quizás 20 × 300 tokens de salida.

Coloque el documento primero y manténgalo con bytes idénticos en todas las llamadas, y la mayoría de los proveedores ofrecen el prefijo repetido desde la memoria caché a una fracción del precio. Primero recorte el documento estándar y la base también se encogerá. Haga cinco preguntas por llamada en lugar de una y enviará el documento cuatro veces en lugar de veinte. La misma tarea, el mismo modelo y un orden de magnitud entre la versión descuidada y la cuidadosa, que es el objetivo de contar antes de enviar.

Tanto el contador como el compresor se ejecutan completamente en su navegador: el aviso sobre el precio no se carga en ningún lugar para ser medido.