La mayoría de los desarrolladores y marketers que usan APIs de IA tienen una idea vaga de que «los tokens son como palabras» — y eso funciona bien hasta que envías un expediente legal de 40 páginas como contexto, ves que tu factura de API se dispara y te das cuenta de que no tenías ni idea de cuántos tokens eran. La relación entre el texto legible para humanos y los tokens de IA es lo suficientemente consistente como para planificar en torno a ella, una vez que conoces las proporciones reales.
Cómo funciona realmente la tokenización
Los tokenizadores no dividen el texto en los límites de las palabras. Usan codificación por pares de bytes (BPE) o algoritmos similares para dividir el texto en las unidades sub-léxicas más frecuentes encontradas en su corpus de entrenamiento. El resultado es que las palabras comunes en inglés suelen ser un token, las palabras poco comunes o largas se dividen en dos o tres tokens, y la puntuación y los espacios frecuentemente se agrupan con los caracteres adyacentes.
El tokenizador cl100k_base de OpenAI (usado por GPT-4o, GPT-4 y GPT-3.5-turbo) trata ” the” (con un espacio inicial) como un solo token, mientras que “tokenization” se divide en ” token” + “ization” — dos tokens. El tokenizador de Anthropic para Claude sigue patrones BPE similares pero no es idéntico al de OpenAI, por lo que el mismo texto puede producir recuentos de tokens ligeramente diferentes en distintos proveedores.
La implicación práctica: no puedes dividir tu recuento de palabras por un número fijo y obtener un recuento exacto de tokens. Pero puedes aproximarte lo suficiente para planificar — y para recuentos exactos, conviene usar una herramienta especializada.
Proporciones tokens-palabras para texto en inglés
Para prosa estándar en inglés — piensa en entradas de blog, correos empresariales, documentación o artículos de noticias — la proporción es consistentemente cercana a 0,75 palabras por token, o de forma equivalente, 1 token por 0,75 palabras. Eso significa:
- 1 palabra ≈ 1,3 tokens
- 100 palabras ≈ 133 tokens
- 500 palabras ≈ 667 tokens
Para una página estándar de texto en un documento (aproximadamente 250-300 palabras para una página académica a doble espacio, o 400-500 palabras para una página empresarial con tipografía densa), el recuento de tokens resulta así:
| Tipo de página | Palabras aprox. | Tokens aprox. |
|---|---|---|
| Página académica a doble espacio | 250 | 333 |
| Documento empresarial a espacio simple | 450 | 600 |
| Tipografía densa (novela de bolsillo) | 500 | 667 |
| Página web promedio | 350 | 467 |
Una novela estándar de 80.000 palabras tiene aproximadamente 106.000 tokens — lo que cabe cómodamente en la ventana de contexto de 200.000 tokens de Claude, pero requeriría fragmentación para modelos con límites de 32.000 o 128.000 tokens.
Para obtener recuentos exactos de tu texto específico en lugar de estimaciones, pégalo directamente en el Contador de tokens de IA. La herramienta usa el tokenizador real del modelo que estés utilizando y muestra los recuentos de tokens con desgloses de costo por modelo.
Tokens en otros idiomas
Los recuentos de tokens varían significativamente entre idiomas, y el texto en idiomas distintos al inglés casi siempre cuesta más tokens por palabra. Esto se debe a que los tokenizadores BPE se entrenan predominantemente con texto en inglés, lo que hace que las sub-palabras comunes en inglés sean más eficientes (un token por unidad) mientras que otros idiomas requieren más tokens para representar el mismo contenido semántico.
Español: el español es fonéticamente regular y comparte mucho vocabulario con el inglés (ambos de origen latino). La proporción es aproximadamente 1,1-1,2 tokens por palabra — alrededor de un 10-20 % más costoso que el inglés para el mismo contenido semántico. Un párrafo en español de 400 palabras tiene aproximadamente 450-480 tokens.
Francés e italiano: similar al español. Calcula un sobrecosto de tokens del 10-20 % frente al texto equivalente en inglés.
Alemán: los sustantivos compuestos del alemán son largos y a menudo se dividen en múltiples tokens. El texto alemán suele tener 1,2-1,4 tokens por palabra. La documentación técnica en alemán (sustantivos compuestos como «Softwareentwicklungsumgebung») puede elevar esta cifra aún más.
Chino (simplificado/tradicional): aquí es donde la diferencia se vuelve significativa. Los caracteres chinos no tienen espacios entre palabras, y cada carácter o par de caracteres frecuentemente se convierte en un token. La relación con las «palabras» es menos directa, pero como referencia aproximada, un carácter chino promedia unos 0,6-0,8 tokens con cl100k_base, mientras que el concepto equivalente en inglés puede requerir menos caracteres en total. Una frase corta en chino de 20 caracteres puede tener 15-20 tokens, mientras que el equivalente en inglés de 10 palabras tiene 13-14 tokens. La diferencia se reduce a medida que el contenido se alarga.
Japonés: similar al chino en ineficiencia de tokens para los tokenizadores BPE. El kanji japonés tokeniza aproximadamente 1 token por carácter, mientras que las cadenas en hiragana pueden fusionarse ligeramente.
Ruso y escritura cirílica: los caracteres fuera del ASCII se representan en UTF-8 como secuencias de múltiples bytes, y los tokenizadores suelen producir 2-3 tokens por palabra para el texto cirílico. El texto en ruso tiene habitualmente entre 1,5 y 2 veces el recuento de tokens del contenido equivalente en inglés.
Tokens en código
El código es distinto del lenguaje natural y tiene sus propios patrones de tokenización. Python, JavaScript y SQL bien formateados tienden a tokenizarse de forma más eficiente que el lenguaje natural porque palabras clave como def, return, SELECT y WHERE son lo suficientemente comunes como para convertirse en tokens únicos.
Puntos de referencia aproximados para tipos de código comunes:
| Tipo de código | Tokens por 100 caracteres |
|---|---|
| Python (limpio, comentado) | 25-35 |
| JavaScript/TypeScript | 28-38 |
| Consultas SQL | 20-30 |
| Datos JSON | 30-45 |
| Marcado HTML | 35-50 |
| CSS | 28-40 |
JSON es especialmente costoso por su estructura repetitiva: cada patrón "clave": "valor" tokeniza las comillas, los dos puntos y el espacio circundante por separado. Una carga útil JSON de 1.000 caracteres puede tener 300-450 tokens, significativamente más que 1.000 caracteres de Python.
Al construir pipelines RAG o herramientas de generación de código, la sobrecarga de JSON importa. Si estás pasando grandes cargas útiles JSON como contexto, considera serializar a un formato más compacto o eliminar los espacios en blanco antes de enviar.
Libros, documentos largos y ventanas de contexto
Entender los tokens por página ayuda a planificar la ventana de contexto. Aquí hay puntos de referencia para documentos largos comunes:
- Entrada de blog corta (800 palabras): ~1.067 tokens
- Artículo de formato largo (3.000 palabras): ~4.000 tokens
- Informe de 10 páginas (5.000 palabras): ~6.667 tokens
- Expediente legal de 40 páginas (20.000 palabras): ~26.667 tokens
- Novela (80.000 palabras): ~106.667 tokens
- Tesis académica completa (100.000 palabras): ~133.333 tokens
La ventana de contexto de 128.000 tokens de GPT-4o cabe aproximadamente 96.000 palabras o una novela de bolsillo de unas 320 páginas. La ventana de 200.000 tokens de Claude cabe aproximadamente 150.000 palabras — un libro completo de no ficción más tu system prompt e instrucciones. La ventana de 1 millón de tokens de Gemini 1.5 Pro cabe aproximadamente 750.000 palabras — varios libros a la vez.
Para el procesamiento empresarial de documentos, estas cifras definen tu estrategia de fragmentación. Un contrato de 100 páginas con ~50.000 tokens no cabrá en la ventana de contexto de 128.000 tokens de GPT-4o-mini a menos que tu system prompt sea mínimo.
Por qué conocer tus recuentos te ahorra dinero
Los recuentos de tokens determinan directamente tu factura de API. Una reducción del 10 % en la longitud de los prompts en un pipeline de alto volumen se traduce en una reducción del 10 % en los costos de tokens de entrada. Para un pipeline que gasta 2.000 dólares al mes, eso son 200 dólares al mes — ahorrados ajustando los prompts, eliminando instrucciones redundantes o cambiando de contexto JSON detallado a texto compacto.
Antes de optimizar, mide. Usa el Contador de tokens de IA para obtener recuentos exactos de tokens de tus prompts y ventanas de contexto, luego modela el costo con tu volumen de llamadas real. La herramienta también muestra los precios por modelo para que puedas ver si cambiar de GPT-4o a GPT-4o-mini (a 1/20 del costo) tiene sentido para tu carga de tokens específica.
Cuenta tus tokens antes de presupuestar
Deja de estimar. Pega tu prompt real en el Contador de tokens de IA — muestra los recuentos exactos de tokens usando el tokenizador real de tu modelo objetivo, más el costo resultante de la API a los precios actuales. Tarda 20 segundos y elimina todas las conjeturas de tu presupuesto de IA.
Preguntas frecuentes
¿Son los tokens iguales en GPT-4o, GPT-4o-mini y Claude? No. Las diferentes familias de modelos usan distintos tokenizadores. GPT-4o y GPT-4o-mini comparten el tokenizador cl100k_base, por lo que los recuentos de tokens son idénticos entre ellos — los precios difieren pero los recuentos no. Claude usa el tokenizador propio de Anthropic, que produce recuentos ligeramente diferentes para el mismo texto. La diferencia suele ser pequeña (menos del 5 %) para texto en inglés, pero puede ser mayor para otros idiomas o código.
¿Por qué mi recuento de tokens es más alto de lo esperado? Los system prompts cuentan para tus tokens de entrada y a menudo son más grandes de lo que la gente imagina. Un system prompt detallado con instrucciones de rol, reglas de formato y ejemplos de few-shot puede fácilmente tener 500-2.000 tokens antes de añadir ningún mensaje del usuario. Si tus costos parecen más altos de lo esperado, comprueba si estás contabilizando tu system prompt completo en tus estimaciones.
¿Los espacios en blanco cuentan como tokens? Sí. Los caracteres de espacio en blanco — espacios, tabulaciones, saltos de línea — son parte del flujo de tokens. Los espacios iniciales a menudo se fusionan con la palabra siguiente en un solo token. El doble espacio innecesario, los espacios finales y las líneas en blanco extra añaden a tu recuento de tokens, aunque la sobrecarga suele ser menor.
¿Cuál es el formato más eficiente en tokens para pasar datos estructurados?
Las tablas Markdown son generalmente más eficientes en tokens que JSON para datos estructurados que un modelo de lenguaje leerá. Una fila de tabla como | Producto A | $12,99 | En stock | es más compacta que el objeto JSON equivalente. CSV es aún más compacto para grandes conjuntos de datos. Usa JSON solo cuando la preservación de la estructura en la salida sea importante.
¿Cómo estimo los costos de tokens para un nuevo proyecto de IA antes de construirlo? Comienza con una muestra representativa de entradas reales — 10-20 ejemplos que reflejen tu rango de datos real. Tokenízalos, calcula el promedio de tokens por solicitud, multiplica por tu volumen de llamadas diario esperado y proyecta a costos mensuales y anuales. Contabiliza por separado los tokens de entrada (tu prompt más el contexto) y los tokens de salida (la respuesta del modelo), ya que se facturan a tarifas diferentes.
Lecturas relacionadas
- Contador de tokens de IA — recuentos exactos de tokens y estimaciones de costos para cualquier modelo
- Guía de descuentos en la API por lotes de IA — reduce tu costo por token un 50 %
- Marco de presupuesto y proyección de costos de IA
