Los tokens son creados por un tokenizer, un algoritmo separado que se ejecuta antes de que la red neuronal vea tu texto. El enfoque más común hoy es Byte Pair Encoding (BPE), utilizado por GPT, Claude y Llama. BPE comienza con caracteres individuales (o bytes) y fusiona iterativamente los pares más frecuentes en nuevos tokens. Después de suficientes fusiones, palabras comunes como "the" o "and" se convierten en tokens individuales, mientras que palabras raras o especializadas se dividen en fragmentos de subpalabras. La palabra "tokenization" misma podría convertirse en "token" + "ization" o "token" + "iz" + "ation" dependiendo del tokenizer específico. Este enfoque de subpalabras es lo que permite que los modelos modernos manejen errores de escritura, neologismos y código razonablemente bien — nunca encuentran una palabra verdaderamente "desconocida", solo combinaciones poco familiares de piezas conocidas.
Diferentes modelos usan diferentes tokenizers con diferentes vocabularios, y esto importa más de lo que la mayoría de la gente cree. El tokenizer de GPT-4 (cl100k) tiene alrededor de 100,000 tipos de tokens. El tokenizer de Claude es diferente. Llama usa otro más. La misma oración en ingles puede tokenizarse en un número diferente de tokens dependiendo de que modelo estes usando, lo cual afecta directamente el uso de la ventana de contexto y los costos de API. El código tiende a ser menos eficiente en tokens que la prosa porque los nombres de variables y tokens de sintaxis pueden no aparecer con suficiente frecuencia en los datos de entrenamiento para ganarse su propia entrada en el vocabulario. Los idiomas que no son ingles varian enormemente — los idiomas con escritura latina generalmente se tokenizan casi tan eficientemente como el ingles, pero el chino, japones, coreano, arabe y hindi frecuentemente requieren más tokens por significado equivalente porque sus caracteres pueden no haber estado tan representados durante el entrenamiento del tokenizer.
El tamaño del vocabulario del tokenizer crea una compensación real de ingenieria. Un vocabulario más grande significa que las palabras y frases comunes obtienen sus propios tokens dedicados, así que tu texto se comprime en menos tokens (más barato, más rápido, cabe más en el contexto). Pero un vocabulario más grande también significa una tabla de embeddings más grande en las capas de entrada y salida del modelo, lo cual incrementa el tamaño del modelo y el uso de memoria. La tabla de embeddings para un vocabulario de 100,000 tokens con una dimensión de modelo de 4,096 ya tiene 400 millones de parámetros — una porción nada trivial de un modelo más pequeño. Por eso los tamaños de vocabulario tienden a agruparse en el rango de 32K–128K: es el punto óptimo entre eficiencia de compresión y costo en parámetros.
Cuando los proveedores anuncian ventanas de contexto — 8K, 128K, 1M tokens — esos números incluyen todo: tu system prompt, tu historial de conversación, cualquier documento que pegues y la propia respuesta del modelo. Un error común de los desarrolladores es llenar la ventana de contexto con material de referencia y dejar muy pocos tokens para que el modelo genere una respuesta sustancial. La mayoría de las APIs te permiten establecer un parámetro max_tokens para la respuesta, pero si tu input ya consumio la mayor parte de la ventana de contexto, el modelo puede truncar su razonamiento o negarse a responder. En la práctica, quieres hacer un presupuesto: conoce el límite de contexto de tu modelo, estima el tamaño de tu input (la regla de 3/4 de palabra es una guia aproximada — para precisión, usa la libreria del tokenizer del proveedor) y reserva suficiente espacio para el output que necesitas.
Hay una dimensión de costos que la mayoría de la gente subestima. Los tokens de salida son típicamente 3–5 veces más caros que los tokens de entrada en los niveles de precios de API, porque generar cada token de salida requiere un forward pass completo a través del modelo, mientras que los tokens de entrada pueden procesarse en paralelo. Esta asimetría significa que un chatbot que da respuestas largas y verbosas cuesta dramaticamente más que uno entrenado para ser conciso. También es la razón por la que técnicas como el prompt caching (reutilizar los tokens de entrada procesados en múltiples solicitudes) pueden reducir costos significativamente para aplicaciones que comparten un system prompt común o contexto de documentos entre muchas consultas. Entender la economía de tokens no es solo académico — es la diferencia entre una funcionalidad de IA que cuesta $50/mes de operar y una que cuesta $5,000.