Límites de contexto y capacidad con varios modelos de IA

El problema no es elegir el mejor modelo, es respetar los dos techos de cada uno

Operar varios modelos en la misma aplicación no es cuestión de elegir el modelo "mejor". Es respetar los dos techos que carga cada uno: la ventana de contexto y la capacidad de procesamiento. Ignorar cualquiera de los dos hace caer la llamada en producción, a veces en silencio. La elección de qué modelo atiende cada tarea es, en la práctica, una decisión de enrutamiento.

Hay una lectura corriente que dice que basta con pagar por el modelo más capaz y dejar que la cola única resuelva el resto. Es una lectura cómoda y equivocada. Un modelo de ventana corta recibe un contexto más grande del que soporta y responde con un error, mientras que un modelo barato y veloz revienta el techo de tokens por minuto en el punto exacto del pico de demanda y devuelve una serie de 429. Cada uno de esos dos fallos cuenta una historia que el extremo más caro del catálogo rara vez resuelve por sí solo.

Como la decisión de usar varios modelos ya existe, la pregunta de este texto es otra: cómo operar cada uno dentro de sus propios límites. La respuesta es una decisión de enrutamiento, una cuestión de adecuación de ajuste, y nunca un "modelo grande para todo".

Los dos techos son distintos y muerden en momentos distintos

Confundir los dos límites es el error más común y el más difícil de ver. El techo de contexto y el techo de capacidad no se manifiestan a la misma hora, no se corrigen con la misma medida y no aparecen en los mismos registros.

El techo de contexto describe cuántos tokens puede cargar una sola solicitud. En la página de modelos vendidos por la plataforma Azure, una implementación de la familia GPT-4.1 está documentada con una ventana de 1.047.576 tokens en los despliegues de contexto largo, la misma tabla registra techos menores de 300.000 para los despliegues estándar, y el mismo documento separa esa ventana de la salida máxima y registra que la entrada, la salida y los tokens de razonamiento comparten el mismo presupuesto. Eso tiene una consecuencia incómoda: más entrada deja menos espacio para generar la respuesta. El mismo documento deja claro ese cálculo: una solicitud que excede la ventana se rechaza con un error explícito, y la respuesta incompleta bajo un HTTP 200 aparece cuando la generación toca el límite de salida restante dentro del presupuesto compartido, no cuando la entrada es demasiado grande para la ventana. Contra ese tipo de truncamiento silencioso la aplicación solo se defiende leyendo el motivo de detención que el proveedor devuelve junto con el cuerpo. Es el tipo de fallo que pasa desapercibido porque corre en el silencio de un estado 200.

El techo de capacidad es otra contabilidad. Trata de la velocidad y de la concurrencia: cuántos tokens por minuto gasta el endpoint, cuántas solicitudes por minuto acepta, cuántas llamadas paralelas aguanta antes de que se degrade la latencia. Cuando se alcanza ese techo, el proveedor responde con un 429. Traduciendo el estado HTTP: te pasaste del límite de uso. El 429 es honesto. Lo que no es honesto es la aplicación que reacciona a cada 429 con un nuevo intento inmediato y apila su propio congestionamiento.

El momento en que muerde cada uno es lo que lo diferencia todo. El contexto falla en la primera solicitud, esa que ya carga un informe entero. La capacidad solo aparece bajo carga, cuando la cola se sincroniza y treinta llamadas llegan en el mismo segundo. Unos errores de contexto en una mañana dispararon una alarma. Ninguna alarma avisa del 429 que llega en la hora de pico de la madrugada.

El marco de ajuste: cada tarea arranca de la pregunta correcta

La tarea tiene un contexto real y un pico de capacidad. Ningún modelo entrega los dos de regalo. Por eso el mapeo parte de las preguntas de la tarea, no de las virtudes publicitarias del modelo.

Cuatro preguntas resuelven la mayoría de los casos. Primera: cuál es el tamaño real del contexto de la tarea en su peor día. Segunda: cuántos tokens por minuto gasta la tarea en el pico. Tercera: qué salida máxima necesita la respuesta. Cuarta: cuánto puede pagar la operación por esa solicitud, porque un modelo que cumple el contexto y el pico pero cobra el doble tampoco cabe en la rutina.

Con las cuatro respuestas sobre la mesa, la elección se vuelve una cesta de modelos. Cada flujo de trabajo alimenta el modelo que cumple el contexto real y el pico esperado. Es una lógica de cobertura de riesgo, no una carrera por la mayor capacidad. La empresa que ya decidió operar un abanico de modelos ganó flexibilidad de enrutamiento, y esa base es lo que detalla el texto hermano sobre arquitectura multi-modelo de IA.

Para operar la cesta hay que tratar el enrutamiento como una decisión de producción. El enrutamiento es la tubería que manda cada solicitud al modelo que encaja, con reglas por clave y observabilidad central. El costo entra como una de las dimensiones y como techo de gasto, y quien quiera ver la matemática de escala y de ahorro del enrutamiento encuentra base en el texto del model router y su prueba de ahorro y en la prueba del costo por token en producción.

Ejemplo trabajado: el número que solo un modelo de la cesta cumple

Un caso de proyecto ayuda a ver dónde se descarrila la cuenta. Toma una tubería que resume informes largos y que, en el pico, carga unos 74.000 tokens de contexto por llamada y dispara 38 llamadas por minuto. Los números aquí son puntos de diseño ilustrativos, derivados de la demanda de la aplicación, y jamás métricas oficiales de un proveedor.

Un candidato compacto, pensado para diálogo corto, tiene una ventana efectiva muy por debajo de lo que reclama la tarea. Acepta un chat rápido, pero recibe 74.000 tokens en la entrada, revienta el techo de ventana y es rechazado con un error de contexto en la primera llamada. Falla en la primera dimensión, ya en la primera llamada.

Un candidato de frontera aguanta una ventana mucho mayor con holgura. Parece ideal hasta mirar el pico. Las 38 llamadas por minuto, cada una transportando 74.000 tokens, producen un flujo que supera el techo de capacidad y escupe 429 en secuencia. El modelo es capaz. El techo, no.

El tercer candidato abre la ventana que pide el contexto y sostiene el pico sin tocar el 429. La elección no fue la "mejor" en un sentido heroico, fue la única que llenó las dos exigencias de la tarea. Ese es el ajuste que comete el enrutamiento: la tarea va al modelo cuya ventana y cuyo pico caben, en vez de ir a un default más grande.

Cómo una capa de enrutamiento entrega esa decisión de ajuste

Repetir la misma lógica no exigiría mucha conversación si la aplicación pudiera reinventar la integración en cada cambio. No puede. Por eso la decisión vive en una capa entre la aplicación y los modelos: un gateway corporativo de enrutamiento de LLMs, que recibe la llamada en la puerta única de la aplicación y elige el endpoint por regla.

Importa ser preciso sobre la división del trabajo. El operador mide el contexto real que transporta la tarea y el pico de capacidad que genera. El gateway usa la selección por contexto, costo, desempeño y latencia para cometer cada tarea al modelo cuya ventana cabe. No rastrea, llamada a llamada, el contexto ya usado frente al disponible. Eso no forma parte del alcance del producto. Forma parte del alcance la decisión de adecuación por reglas de clave, y es esa la que completa el ajuste.

Cuando el proveedor está congestionado, devuelve un 429 o revienta el techo de tokens por minuto, el gateway hace el failover automático hacia un modelo de reserva de una lista configurada, con reintentos de retroceso exponencial. La ruta crítica no se traba por un límite tocado. Quien ya estudió el comportamiento bajo indisponibilidad reconoce el patrón, y la guía de alta disponibilidad de LLM profundiza en las opciones de reserva. Un techo de gasto por clave cierra la cuenta a fin de mes. La observabilidad central muestra dónde tocó cada techo: los tokens que consumió cada modelo, la latencia real, los 429 interceptados.

El diagrama de abajo condensa el flujo de decisión de adecuación.

Los atributos a comparar por modelo antes de enrutar

Armar la cesta exige comparar los modelos por los atributos que importan. La tabla de abajo lista qué recolectar, fila por fila. Los valores exactos de proveedor no entran sin fuente, las celdas son rangos orientativos de diseño y cada fila debe validarse en el catálogo al cerrar la elección.

La regla práctica es leer la fila de la tarea y la fila del modelo juntas. Un modelo de frontera resuelve un documento de 74.000 tokens, pero cobra caro y cuesta latencia. Un intermedio que sostiene el pico resuelve lo mismo a menor costo cuando el contexto lo permite. La capacidad no es competencia bruta, es la curva de tokens por minuto frente a la ventana por solicitud, y solo el catálogo cerrado revela dónde opera realmente cada uno.

Cómo operacionalizar el ajuste en la práctica, paso a paso

El marco se vuelve rutina con ocho pasos, y cada uno produce un artefacto que alimenta al siguiente.

1. Inventariar los flujos de la aplicación. Enumera qué ejecuta cada flujo y con qué frecuencia, sin decidir nada todavía.
2. Medir el contexto real por flujo. Recolecta la ventana de entrada más grande que cada uno ya haya cargado en producción, no la teórica.
3. Medir el pico de capacidad por flujo. Registra el máximo de tokens por minuto y de solicitudes por minuto observado, con fecha y hora.
4. Armar la cesta según la rúbrica. Cruza los atributos de cada flujo con los modelos candidatos y descarta el que no cabe.
5. Crear las reglas por clave. Comete cada flujo al modelo de la cesta que cumple su contexto y su pico.
6. Configurar el failover y el techo de gasto. Enumera los modelos de reserva para el 429, define el reintento con retroceso y fija el límite por clave.
7. Encender la observabilidad central. Agrega latencia, tokens y límites por modelo para ver dónde tocó cada techo.
8. Reevaluar con el ranking en tiempo real. El catálogo cambia, y parte de la madurez está en saber cómo una evaluación de endpoint reconfigura la política de enrutamiento de la empresa.

El paso ocho mantiene viva la cesta. Un modelo que lideró en el primer trimestre puede perder su posición en precio o en desempeño en el segundo, y reevaluar por ciclo es parte de la operación madura.

Preguntas frecuentes sobre límites de contexto y capacidad de modelos de IA

¿Qué es el límite de contexto de un modelo de IA? Es el techo de tokens que puede cargar una sola solicitud, sumando entrada, salida y tokens de razonamiento. Superar la ventana en la entrada genera un error rechazado por el proveedor; la respuesta truncada o incompleta bajo un HTTP 200 aparece cuando la salida toca el límite restante dentro del presupuesto compartido. Más entrada deja menos espacio para la salida.

¿Qué es tokens por minuto y por qué genera el error 429? Es el ritmo máximo de consumo que acepta el endpoint en una ventana de tiempo. Cuando el volumen supera el límite, el proveedor responde con el estado HTTP 429, señal de exceso de uso. Intentar de nuevo en el mismo instante solo empeora la cola.

¿Qué modelo elegir cuando la tarea tiene un contexto enorme, pero pocas solicitudes? Un modelo de ventana alta, porque la restricción es el tamaño de la solicitud, no la frecuencia. La salida máxima debe cubrir la respuesta. El costo por llamada pesa poco cuando el volumen es bajo.

¿Cómo enrutar varios modelos sin cambiar la integración de la aplicación? Manteniendo un solo endpoint y cambiando solo el modelo por regla de clave. El enrutamiento decide qué modelo atiende cada llamada, y cambiar de modelo exime de reescribir la aplicación.

¿Cómo saber cuánto del límite ya se usó? Por la observabilidad central, que registra tokens y latencia por modelo, y por los 429 capturados. Esa medición dice si el techo tocado fue el de contexto, el de capacidad o el de gasto.

Referencias y lectura complementaria

• Microsoft Learn, Microsoft Foundry: la página conceptual Foundry Models sold by Azure documenta, por modelo, la ventana de contexto, la salida máxima y el comportamiento de las solicitudes que exceden el presupuesto, incluido el caso de una respuesta HTTP 200 incompleta y el ejemplo de una ventana de 1.047.576 tokens. Consultada el 3 de septiembre de 2026.
• Nexforce Router: la página del Nexforce Router es la base institucional de las funciones de enrutamiento y de gobernanza citadas en este texto.

La decisión de ajuste es la pieza central de una operación multi-modelo

Quien opera varios modelos en producción descubre pronto que la verdad del sistema está en la frontera entre la demanda y el techo de cada endpoint. El enrutamiento de LLM suena a un problema de ingeniería. Es un problema de adecuación que se resuelve con contabilidad de contexto y de capacidad, y la cuenta vive exactamente en el encaje entre la ventana y el pico que exige cada tarea.

La cesta bien dimensionada, las reglas por clave y la observabilidad central convierten esa cuenta en una decisión tomada antes del pico, y no después del susto. Cuando el modelo que fue la elección heroica de la semana empieza a congestionarse, la capa de enrutamiento redirige el tráfico al modelo de reserva que sostiene la demanda, sin reintegrar y sin detenerse. El 429 deja de ser un fantasma y pasa a ser un dato.

El camino no exige adivinar el futuro ni coronar un único "mejor". Exige medir el contexto real de cada flujo, medir el pico de cada uno, armar la cesta que cubra las dos dimensiones y dejar que el gateway cometa cada tarea al modelo que de verdad cabe. Hecho eso, operar varios modelos deja de ser resistencia y se vuelve disciplina de producción. El número que tumba la aplicación no es el más grande ni el más pequeño. Es el primero que nadie midió.

La operación arranca con la medición de hoy. Elige un flujo, registra la ventana real más grande que haya cargado y compárala con la cesta que ya alcanza tu clave. El resto es enrutamiento.