Metodología de tokens de IA

El contador de tokens estima cuántos tokens usará un fragmento de texto para una API de un modelo de lenguaje grande dado, y multiplica por el precio publicado actual para estimar el coste. Ambas mitades de esa frase tienen límites de precisión significativos.

Estimación de tokens: heurística, no exacta

Cada LLM moderno usa un tokenizador, típicamente BPE (Byte Pair Encoding) para GPT y Claude, SentencePiece para Gemini y Llama, que convierte el texto en una secuencia de IDs de tokens enteros. El mapeo exacto es específico del modelo y propietario; ejecutar el tokenizador real requiere el archivo del modelo de tokenizador (típicamente 1-5 MB) incluido en el cliente.

No incluimos tokenizadores porque se actualizan con los lanzamientos de modelos y el tamaño del paquete se acumula en 4+ proveedores. En cambio, usamos los ratios de caracteres por token publicados en la documentación de cada proveedor:

• GPT-3.5/4/5: ~4 caracteres por token para inglés; más para código; menos para scripts no latinos.
• Claude 3/4: ~3.5 caracteres por token. El tokenizador de Claude es ligeramente más agresivo que el de GPT.
• Gemini: ~4 caracteres por token para inglés.
• Llama 3/4: ~4 caracteres por token.

Estos ratios están dentro del ~10% del conteo real de tokens para prosa inglesa típica. Se desvían más para el código (que se tokeniza en más piezas debido a divisiones de identificadores), scripts no latinos (chino, japonés, árabe: a veces 2-3× más tokens por carácter) y datos estructurados (JSON, XML: entre inglés y código).

Precio: exacto pero desactualizado

Cada modelo tiene un precio publicado por token para la entrada y (por separado) para los tokens de salida. Codificamos estos precios en un registro que actualizamos manualmente cuando los proveedores actualizan sus precios (normalmente cada 1-3 meses a medida que se lanzan nuevos modelos y se reprecia los antiguos).

Los precios en el registro son correctos a partir del despliegue más reciente. Para la previsión real de costes en producción, compruebe con la página de precios del proveedor y presupueste un margen del 15-30% porque el coste real depende de la longitud de salida, que no es determinista.

Qué modelamos

Para cada modelo, la calculadora estima:

• Tokens de entrada (del prompt del usuario).
• Tokens de salida (de una estimación proporcionada por el usuario o del valor predeterminado del proveedor).
• Coste = tokens_entrada × precio_entrada + tokens_salida × precio_salida.
• El total en USD con 6 decimales.

Qué no modelamos

• Precios de entrada en caché. Varios proveedores (OpenAI, Anthropic) ofrecen precios con descuento para tokens de entrada que coinciden con un prefijo de prompt visto recientemente. Vale la pena conocerlo; no está modelado aquí.
• Descuentos de API por lotes. Los endpoints de lotes asíncronos suelen ofrecer un 50% de descuento; no está modelado.
• Entradas de imagen/audio/vídeo. Los costes de tokens multimodales varían según el modelo y se calculan de forma diferente al texto. En la hoja de ruta.
• Precios de modelos ajustados. Los proveedores tienen precios diferentes para los ajustes finos respecto a los modelos base.

Detalles del algoritmo: el bucle de fusión BPE

Tanto los tokenizadores de GPT como los de Claude son variantes de Byte Pair Encoding. El procedimiento en tiempo de entrenamiento (Sennrich et al., 2016) parte de un vocabulario base de bytes individuales y aplica repetidamente la fusión:encontrar el par adyacente más frecuente (a, b) en el corpus, agregar un nuevo token “ab” al vocabulario, reemplazar cada ocurrencia de (a, b) con él. El procedimiento se detiene cuando el vocabulario alcanza el tamaño objetivo: 100 277 para el cl100k_base de GPT-4o, ~128k para Llama 3, ~256k para Gemini. En tiempo de inferencia, el tokenizador aplica la lista de fusiones guardada de forma greedy a la entrada.

Nuestra heurística de ratio de caracteres omite el bucle de fusión por completo. Para un fragmento de texto con N caracteres y tokens por carácter observados r: tokens ≈ ⌈N × r⌉. Las constantes que usamos:

Derivación del coste: dados los tokens de entrada T_in, tokens de salida T_out y las tarifas por millón de tokens del proveedor p_in y p_out, el coste total en USD = (T_in × p_in + T_out × p_out) / 1 000 000. Redondeamos a seis decimales para preservar la precisión sub-centavo en prompts cortos.

Fuentes y referencias

Las heurísticas de esta página se calibran con el tokenizador de referencia tiktoken de OpenAI en un corpus de 100k muestras de Wikipedia en inglés. El algoritmo BPE está documentado en Sennrich, Haddow & Birch (2016); SentencePiece, usado por Gemini y Llama, en Kudo & Richardson (2018). Consulte el bloque de Fuentes y referencias a continuación para las citas primarias y las páginas de precios de los proveedores que reflejamos.

Supuestos y limitaciones

• Calibración solo para prosa en inglés. Las constantes de tokens por carácter están ajustadas al texto de Wikipedia en inglés. El código, JSON, chino, japonés, árabe y otros scripts no latinos pueden desviarse entre un 30 y un 300% (el chino típicamente usa 2-3× más tokens por carácter).
• Sin soporte para precios de entrada en caché. OpenAI y Anthropic ofrecen descuentos del 50-90% en tokens de prefijo reutilizados. La estimación de coste usa el precio completo sin caché.
• Sin descuento de API por lotes. Los endpoints de lotes asíncronos típicamente reducen a la mitad el coste por token; no reflejado aquí.
• La longitud de salida la proporciona el usuario. No podemos predecir la longitud de la respuesta; ±50% en T_out es típico dependiendo del prompt.
• Las entradas de visión y audio no están modeladas. Cada proveedor cuenta los tokens no textuales de manera diferente (teselas de imagen para GPT-4o, segundos de audio para Gemini, etc.).
• Los precios son una instantánea. El registro se actualiza mensualmente; los cambios de precio del proveedor a mitad de mes no se reflejan hasta el próximo despliegue.
• Los precios de modelos ajustados y de capacidad reservada difieren. La estimación usa únicamente tarifas estándar bajo demanda.

¿Qué tan precisa es realmente la estimación?

Para prosa inglesa típica de longitud moderada (50-5000 caracteres), nuestro conteo de tokens está dentro del 10% del conteo real y nuestra estimación de coste está dentro del 10-15% de la factura real de la API. Eso es suficiente para dimensionamiento aproximado: «¿este prompt cuesta 1 céntimo o 1 dólar?»; e insuficiente para facturación precisa al céntimo. Para esto último, use el tokenizador oficial del proveedor; para todo lo demás, el nuestro es una comprobación rápida útil.