En este artículo
El agente falla. El proveedor devuelve un error genérico, el log no dice qué se envió y la sesión queda en un estado que nadie puede reproducir. La reacción habitual es culpar al modelo. Casi siempre el problema está antes: el request salió con más tokens de los que el envelope podía admitir.
El fallo silencioso
Un agente que trabaja con herramientas no envía un mensaje: envía una estructura. La plantilla del modelo, el historial de la conversación, la descripción de las herramientas, los resultados de las llamadas anteriores y la instrucción actual se combinan en un solo payload. Cuando ese payload supera el límite, el proveedor puede truncar, rechazar o devolver un error que no distingue entre “modelo ocupado” y “contexto demasiado largo”.
El resultado es un fallo opaco. El agente no sabe si el problema fue la red, la cuota, el modelo o el tamaño. El operador no sabe qué parte del request creció. Y la sesión queda en un estado difícil de reproducir porque el historial ya cambió.
La hipótesis de este artículo es simple: la mayoría de esos fallos son de admisión, no de modelo. Se pueden prevenir midiendo antes de enviar.
Qué se envía realmente
El tamaño de un request no es el tamaño del mensaje del usuario. Es la suma de todo lo que el modelo necesita para responder. En un agente típico, esa suma incluye la plantilla, el historial, las herramientas, los resultados de herramientas y la reserva de salida. Cualquiera de esas partes puede crecer sin que el usuario lo note.
| Componente | Por qué crece | Quién lo controla |
|---|---|---|
| Plantilla | Cambia con el modelo y el formato | El harness |
| Historial | Se acumula en cada iteración | El agente |
| Herramientas | Más tools, más descripción | El diseño del agente |
| Resultados | Respuestas largas de APIs | La herramienta |
| Salida reservada | Se aparta antes de generar | El envelope |
La reserva de salida es la parte que más se olvida. Si el modelo tiene 32.768 tokens de ventana y se reservan 4.096 para la respuesta más 256 de margen, la entrada útil no es 32.768: es 28.416. Medir contra el número grande es una receta para el overflow.
El governor por request
La solución es un governor que se ejecuta antes de llamar al proveedor. Hace cuatro cosas: renderiza la plantilla exacta que usará el modelo, cuenta los tokens de esa representación, reserva la salida y decide si el request cabe. Si no cabe, lo rechaza en local con una causa legible.
El orden importa. Contar el mensaje del usuario sin renderizar la plantilla subestima el tamaño. Contar después de enviar no sirve. Reservar la salida al final convierte un límite conocido en una sorpresa. La única secuencia que produce un veredicto confiable es renderizar, contar, reservar y decidir.
“Si no se puede medir antes de enviar, no se puede atribuir después.” — Regla de diseño del contrato de admisión.
Rechazo local vs error del proveedor
En un canario interno, una solicitud de 35.562 tokens fue rechazada contra un límite de entrada de 28.416. El rechazo ocurrió antes de la llamada, sin corromper el payload del proveedor. La diferencia no es cosmética: un rechazo local dice “te pasaste por 7.146 tokens”, mientras que un error del proveedor dice “algo falló”.
El segundo beneficio es la estabilidad. Un request que se trunca en el proveedor puede dejar la sesión en un estado inconsistente: el historial contiene una respuesta que no corresponde, la herramienta quedó a medias y el siguiente turno arrastra el problema. Un rechazo local evita esa contaminación.
El tercero es el costo. Un request rechazado en local no consume cuota, no espera la cola y no activa reintentos. En un agente que itera mucho, esos rechazos silenciosos son la diferencia entre un sistema predecible y uno que se degrada sin que nadie sepa por qué.
Telemetría útil
Un rechazo sin telemetría es solo un error más claro. Para que sea accionable, el governor debe registrar el tamaño de cada componente, el límite aplicado, la reserva de salida, el veredicto y la causa. Con esos campos se puede responder qué creció, cuándo y por qué.
La telemetría también sirve para ajustar el diseño. Si el historial es el componente que más crece, la solución es compactar o resumir; si son las herramientas, la solución es reducir el catálogo; si es la salida reservada, la solución es un modelo con más ventana o una respuesta más corta. Sin datos, todo es intuición.
Cómo implementarlo
El esqueleto es pequeño. La clave es que el chequeo viva en el camino obligatorio, no en un script aparte que alguien puede olvidar.
render = apply_template(model, messages, tools)
tokens_in = tokenize(render)
envelope = context_limit - max_output - margin
if tokens_in > envelope:
reject(reason="overflow", tokens_in=tokens_in, envelope=envelope)
else:
admit(tokens_in=tokens_in, reserved=max_output + margin)Hay dos decisiones de diseño. La primera es qué plantilla se renderiza: la del modelo real, no una aproximación. La segunda es dónde se cuenta: en el mismo tokenizer que usa el proveedor, o en uno suficientemente cercano con un margen explícito. Un tokenizer distinto puede subestimar o sobreestimar; el margen debe cubrir esa diferencia.
Para contar tokens hay bibliotecas públicas que resuelven la parte mecánica: tiktoken para los modelos que lo usan y los tokenizers de Hugging Face para el resto. Lo importante no es la librería, sino que el conteo ocurra sobre la representación final del request y con el mismo criterio que el proveedor.
El resto es operación: logs, métricas y un test que fuerce el overflow. Un gate que nunca se prueba en rojo no es un gate.
Los límites del método
El contrato de admisión no elimina todos los fallos. No arregla un modelo que alucina, una herramienta que devuelve basura o una red que se cae. Tampoco convierte un tokenizer aproximado en exacto. Lo que hace es separar el problema de tamaño del problema de calidad, que es el primer paso para diagnosticar cualquiera de los dos.
Los canarios que sostienen este artículo cubren dos lanes y requests concretos. No son un benchmark universal. La conclusión que sí se sostiene es modesta y útil: medir antes de enviar convierte un error opaco en un rechazo accionable, y eso mejora la fiabilidad aunque el modelo no cambie.
Para seguir leyendo
Si te interesa el siguiente nivel —qué modelo respondió de verdad cuando hay fallbacks—, revisa los otros análisis de la sección de IA. Para el problema del contexto que se rompe en sesiones largas, nuestra pieza sobre checkpoint y compactación cubre la otra mitad. Y si estás eligiendo un modelo para agentes, la guía de LFM2.5 y los 2B activos explica por qué el costo por iteración importa más que el benchmark de un turno.
Preguntas frecuentes
¿Por qué no basta con contar el mensaje del usuario?
Porque el request incluye la plantilla, el historial, las herramientas y la reserva de salida. El mensaje del usuario suele ser la parte más pequeña.
¿Qué diferencia hay entre el límite del modelo y el límite de entrada?
El límite del modelo es la ventana total. El de entrada es esa ventana menos la salida reservada y el margen. Medir contra el total produce overflows que parecían imposibles.
¿Un rechazo local reemplaza al proveedor?
No. Es un filtro previo. El proveedor sigue siendo necesario para generar; el governor solo evita enviarle requests que no puede admitir.
El conocimiento verdadero trasciende a lo público 🌀
Continúa explorando Inteligencia Artificial con piezas relacionadas y evidencia adicional.
Ver relacionados
