Contador de Tokens

El contador de tokens estima cómo los modelos de IA dividen un texto en unidades de procesamiento. Un token no siempre equivale a una palabra o un carácter; puede ser una palabra completa, parte de una palabra, puntuación, comportamiento de espacios o un carácter individual en algunos idiomas. El recuento importa para límites de contexto, costes, diseño de prompts, fragmentación RAG, gestión de historial y decisión de si una entrada cabe en una solicitud. Cada familia de modelos usa tokenizadores distintos, así que el número depende del modelo. La herramienta ayuda a recortar, dividir o estructurar texto antes de enviarlo, pero conviene verificar el límite real del modelo elegido.

Los tokenizadores de LLM modernos usan algoritmos de subpalabras — principalmente Byte Pair Encoding (BPE) y SentencePiece — en lugar de dividir por espacios en blanco. BPE parte de bytes individuales y fusiona iterativamente el par adyacente más frecuente, produciendo un vocabulario fijo de entre 32k y 200k símbolos. Las palabras comunes se convierten en un solo token, las palabras raras se dividen en varias subpalabras, y los bytes arbitrarios (emoji, caracteres de control) aún se codifican de forma segura porque el alfabeto cubre los 256 bytes. SentencePiece (usado por Llama, Mistral, variantes de Gemini) trata el espacio en blanco como un carácter regular mediante el marcador `▁`, por lo que los espacios iniciales pasan a formar parte del siguiente token, razón por la cual ` hello` y `hello` suelen tener IDs de token distintos. OpenAI publica tres vocabularios BPE principales a través de la biblioteca `tiktoken`: `p50k_base` (50.281 tokens, GPT-3 / Codex), `cl100k_base` (100.277 tokens, GPT-3.5 Turbo y GPT-4) y `o200k_base` (~200k tokens, GPT-4o y o1) que añade cobertura no inglesa y reduce los conteos de tokens en chino/japonés aproximadamente 1,4-1,7 veces. Claude usa un tokenizador relacionado pero propietario con una escala de vocabulario similar. Como ratios de trabajo aproximados, el texto en inglés promedia ~4 caracteres por token, el chino ~1,5-2 caracteres por token en cl100k_base y ~2 en o200k_base, y un solo emoji suele consumir 2-5 tokens porque se codifica como múltiples bytes UTF-8. El conteo de tokens impulsa tanto el uso de la ventana de contexto como el coste. Las ventanas actuales incluyen GPT-4o 128k, Claude 3.5 Sonnet 200k y Gemini 1.5 Pro 2M; el coste se factura como `tokens × precio_por_1M`, con precios separados para entrada y salida (p. ej. GPT-4o a $2,50/$10,00 por 1M, Claude 3.5 Sonnet a $3,00/$15,00). Este contador usa coeficientes heurísticos por familia porque incluir el archivo de vocabulario de cada tokenizador supondría megabytes de carga, por lo que el resultado es una estimación de trabajo — el número autoritativo es el campo `usage` de la respuesta API del modelo.

• BPE fusiona pares de bytes frecuentes en un vocabulario fijo; los vocabularios de OpenAI son `cl100k_base` (GPT-4/3.5), `o200k_base` (GPT-4o/o1), `p50k_base` (Codex).
• SentencePiece codifica los espacios en blanco iniciales como `▁`, por lo que ` world` y `world` se asignan a IDs de token distintos en Llama/Mistral/Gemini.
• Heurística en inglés ≈ 4 caracteres/token; CJK ≈ 1,5-2 caracteres/token en cl100k_base, ≈ 2 en o200k_base; emoji típicamente 2-5 tokens cada uno.
• Fórmula de coste: `(tokens_entrada / 1_000_000) × precio_entrada + (tokens_salida / 1_000_000) × precio_salida`, con precios separados para entrada y salida.
• Ventanas de contexto en 2025: GPT-4o 128k, GPT-4 Turbo 128k, Claude 3.5 Sonnet 200k, Gemini 1.5 Pro 2M, DeepSeek V3 128k.
• El mismo texto produce conteos de tokens distintos entre proveedores: el vocabulario del tokenizador, las reglas de respaldo de bytes y el manejo de espacios en blanco difieren.
• El conteo autoritativo es el campo `usage.prompt_tokens` / `usage.completion_tokens` (OpenAI) o `usage.input_tokens` / `usage.output_tokens` (Anthropic) de la respuesta API.