La evolución de los modelos de lenguaje grandes (LLMs) no solo reside en la mejora de sus arquitecturas neuronales o el tamaño de sus conjuntos de datos de entrenamiento, sino también en componentes fundamentales como el tokenizador. Este artículo aborda un problema recurrente en el diseño de LLMs: el trade-off entre la eficiencia de la representación del texto (menos tokens para el mismo contenido) y la granularidad necesaria para una interpretación precisa de las instrucciones. La migración de Claude Opus 4.6 a 4.7 por parte de Anthropic, con su nuevo tokenizador, ilustra este dilema, donde una mayor granularidad (más tokens) se busca para mejorar la 'instruction following' a expensas de un mayor costo computacional y económico.

Históricamente, los tokenizadores, como Byte-Pair Encoding (BPE) o WordPiece, buscan comprimir el texto en unidades sub-palabra para manejar vocabularios grandes y palabras fuera de vocabulario de manera eficiente. Sin embargo, una compresión excesiva puede llevar a la pérdida de matices o a la ambigüedad en la interpretación de instrucciones complejas, especialmente en tareas que requieren precisión a nivel de carácter o formato estricto. La decisión de Anthropic de aumentar el número de tokens para el mismo contenido sugiere una priorización de la fidelidad de la instrucción sobre la eficiencia de tokens, un cambio significativo en la ponderación de estos factores.

Arquitectura del Sistema

El sistema en cuestión es la API de inferencia de Anthropic para sus modelos Claude Opus. El componente central analizado es el tokenizador, una pieza de software que convierte texto plano en una secuencia de tokens numéricos, que son la entrada para el modelo de lenguaje. La API expone un endpoint /v1/messages/count_tokens que permite a los usuarios pre-calcular el número de tokens sin incurrir en costos de inferencia, facilitando la evaluación del impacto del tokenizador. La arquitectura de inferencia de Claude Code se basa en un mecanismo de 'prompt caching', donde los prefijos de las conversaciones (contexto estático y parte del historial) se almacenan en caché para reducir la latencia y el costo en turnos subsiguientes de una sesión. Este caché se particiona por modelo, lo que significa que un cambio de modelo (ej. 4.6 a 4.7) invalida las entradas de caché existentes, forzando una 'cold start' más costosa.

El tokenizador utiliza un algoritmo de codificación de sub-palabras, presumiblemente una variante de BPE, que aprende un vocabulario de unidades frecuentes a partir de un corpus de entrenamiento. La observación de que el contenido CJK (chino, japonés, coreano) y los símbolos tienen un ratio de tokens cercano a 1.0x, mientras que el inglés y el código tienen ratios de hasta 1.47x, sugiere que las porciones del vocabulario relacionadas con idiomas latinos y patrones de código fueron modificadas significativamente. Esto implica que el nuevo tokenizador de 4.7 utiliza fusiones de sub-palabras más cortas o menos frecuentes para patrones comunes en inglés y código, resultando en más tokens para el mismo texto. La interacción con el prompt caching es crítica: un mayor número de tokens por el mismo contenido implica que el volumen de datos en caché aumenta, afectando tanto los costos de escritura inicial como los de lectura subsiguiente, y acelerando el consumo de los límites de tasa para los usuarios de planes Max.

Flujo de Cálculo de Tokens y Costo en Claude API

  1. 1 Usuario Envía Texto Texto plano (código, prosa, etc.) enviado a la API de Anthropic.
  2. 2 Tokenizador 4.6/4.7 El tokenizador del modelo seleccionado convierte el texto en una secuencia de...
  3. 3 Conteo de Tokens La API devuelve el número de tokens resultantes.
  4. 4 Cálculo de Costo/Cuota El número de tokens se multiplica por el precio por token o se descuenta de l...

Flujo de Sesión con Prompt Caching en Claude Code

  1. 1 Turno 1: Cold Start Prefijo estático + input de usuario se tokenizan y escriben en caché (costo d...
  2. 2 Turno N: Cache Hit Prefijo en caché se lee (costo de lectura), nuevo input se tokeniza y añade a...
  3. 3 Modelo Infiere El LLM procesa el contexto completo (prefijo + historial + input) y genera un...
  4. 4 Respuesta Generada Tokens de salida se cuentan y se facturan.
  5. 5 Actualización de Caché Historial de conversación se actualiza en caché para el siguiente turno.
CapaTecnologíaJustificación
data-processing Anthropic Tokenizer (Proprietary BPE variant) Convierte texto plano en secuencias de tokens numéricos para la entrada del modelo. La versión 4.7 utiliza un vocabulario que resulta en más tokens para el mismo contenido en inglés y código. vs WordPiece, SentencePiece, GPT-2 BPE
cache Prompt Caching (Anthropic Internal) Almacena prefijos de conversación (contexto estático y historial) para reducir la latencia y el costo de inferencia en turnos subsiguientes de una sesión. Particionado por modelo. TTL de 5 minutos, particionado por ID de modelo.
compute Claude Opus 4.6 / 4.7 LLM Modelo de lenguaje grande que realiza la inferencia. La versión 4.7 muestra una mejora en la adherencia estricta a las instrucciones, posiblemente influenciada por el nuevo tokenizador y otros cambios internos.

Trade-offs

Ganancias
  • Adherencia estricta a instrucciones
Costes
  • Costo por sesión
  • Consumo de cuota/límites de tasa
  • Volumen de caché
from anthropic import Anthropic
client = Anthropic()
for model in ["claude-opus-4-6", "claude-opus-4-7"]:
    r = client.messages.count_tokens(
        model=model,
        messages=[{"role": "user", "content": sample_text}],
    )
    print(f"{model}: {r.input_tokens} tokens")
Demuestra cómo usar el cliente de Anthropic para comparar el conteo de tokens entre diferentes modelos para un mismo texto.

Fundamentos Teóricos

El problema de la tokenización y su impacto en el rendimiento de los modelos de lenguaje está profundamente arraigado en la investigación de Procesamiento de Lenguaje Natural (PLN). Los algoritmos de codificación de sub-palabras como Byte-Pair Encoding (BPE), introducido por Gage en 1994 para la compresión de datos y popularizado en PLN por Sennrich et al. en 2016 para la traducción automática neuronal, son fundamentales. Estos métodos buscan un equilibrio entre el tamaño del vocabulario y la longitud de la secuencia de tokens, lo cual directamente afecta la eficiencia computacional y la capacidad del modelo para capturar matices lingüísticos.

La hipótesis de que 'tokens más pequeños fuerzan la atención sobre palabras individuales' y mejoran la 'instruction following' se alinea con principios de la teoría de la información y la atención en redes neuronales. Una secuencia de tokens más larga para el mismo contenido puede obligar al mecanismo de atención del modelo a procesar información con mayor granularidad, lo que podría reducir la 'generalización silenciosa' de instrucciones. La evaluación de la 'instruction following' se basa en benchmarks como IFEval (Zhou et al., Google, 2023), que proporcionan un marco sistemático para medir la capacidad de los LLMs para adherirse a restricciones específicas, conectando directamente la ingeniería de tokenizadores con la evaluación rigurosa del comportamiento del modelo.