Cuando los proveedores de modelos anunciaron context windows de un millón de tokens, muchos CTO e ingenieros jefe reaccionaron igual: «Perfecto — metemos toda la documentación ahí y no tenemos que lidiar con RAG». Es una reacción comprensible. Menos componentes, menos infraestructura, menos ajustes. La realidad en producción, sin embargo, es más compleja.
El context window grande es una herramienta poderosa — pero tiene sus límites físicos y económicos. Este artículo explica dónde se encuentran esos límites, muestra cuándo 1M de tokens resuelve realmente el problema y, por el contrario, cuándo su uso es innecesariamente caro y a veces incluso menos preciso que un pipeline bien diseñado con agentic RAG.
Qué significa realmente «1M de tokens»
El context window es la longitud máxima de texto — entrada más salida — que el modelo ve de una vez en una sola llamada. Un token equivale aproximadamente a 0,75 palabras en inglés; en español y en textos técnicos con terminología específica los tokens suelen ser algo más largos.
Un millón de tokens equivale a unas 750 000 palabras — toda la extensión media de una novela, cientos de páginas de documentación técnica o el código fuente completo de un proyecto de tamaño medio. Hoy no es una función premium: Claude (tiers superiores), Gemini 2.5/3.x y Llama 4 Maverick ofrecen 1M; Llama 4 Scout llega incluso a 10M de tokens. Sin embargo, no todos los modelos son tan «largos» — DeepSeek V3, por ejemplo, tiene 128K. Aun así, el contexto de 1M ya no es una característica excepcional, sino un estándar extendido.
El problema no es si el modelo puede manejar el contexto largo. El problema es cuánto cuesta y cómo se degrada la calidad de las respuestas a medida que crece el contexto.
Cómo crece el coste con la longitud del contexto
El coste computacional durante la inferencia no crece linealmente con el contexto — en realidad la situación es más compleja, pero para tomar decisiones prácticas basta con entender un mecanismo: la KV cache.
Cada token en el contexto requiere almacenar los llamados vectores key-value en la memoria de la GPU (VRAM). En cada nuevo token generado, el modelo accede a toda esa cache. Para un modelo de 7B, la KV cache con 128K tokens ocupa unos 16 GB; con 1M de tokens supera los 100 GB. Para un modelo de 70B con 128K tokens, la KV cache por sí sola ronda los 40 GB — y eso es sin los pesos del modelo.
El resultado en la práctica: si se quieren atender varias solicitudes paralelas con contexto largo, se necesita hardware enorme o se encolarán las peticiones. En una API cloud esto se traduce simplemente en un precio más alto por llamada — los modelos frontier cobran por cada token de entrada y el contexto largo corresponde directamente a costes más elevados. En un despliegue interno (on-prem) implica la necesidad de GPUs más numerosas o más potentes.
Existe una optimización importante: el prompt caching. Si el system prompt, la documentación u otro contenido estático se mantiene igual a través de múltiples llamadas, el proveedor almacena su representación KV y en lecturas repetidas se paga solo el 10 % del precio del token de entrada (en Anthropic). El cache write, en cambio, es algo más caro — entre el 125 y el 200 % del precio normal. El ahorro solo se produce cuando se lee el mismo prefijo repetidamente en un tiempo corto. Profundizamos en esta estrategia en el artículo prompt caching y coste.
«Lost in the middle» — cuando el modelo pierde el hilo
La mayoría de los ingenieros conoce el límite tecnológico del context window. Menos se habla de otro límite, más sutil: el context rot — la degradación de la calidad de las respuestas a medida que crece la longitud del contexto.
La investigación muestra que los modelos tienden a concentrar la atención en el inicio y el final del contexto. La información almacenada en la mitad de un documento largo aparece representada con menos precisión en las respuestas — fenómeno denominado «lost in the middle». El benchmark needle-in-a-haystack (buscar una frase escondida en un texto largo) mide únicamente la capacidad de encontrar un hecho aislado. Las tareas reales en producción son más complejas — requieren conectar múltiples informaciones de distintas partes del documento y razonar en varios pasos. En ese tipo de tareas la degradación de la calidad aparece antes y es más pronunciada.
En términos prácticos: si tiene un manual técnico de 500 páginas y pregunta sobre la dependencia entre la sección 3 y la sección 47, el modelo con todo el libro en contexto no responde necesariamente mejor que un modelo al que se le han proporcionado solo las dos secciones relevantes a través de RAG. Y ese segundo caso es considerablemente más barato.
Cuándo ayuda realmente el contexto largo
A pesar de estas limitaciones, existen escenarios donde el contexto largo es objetivamente la mejor elección. Las principales categorías:
Análisis de documentos completos con dependencia secuencial. Si se quiere resumir el acta de una reunión de tres horas, extraer decisiones de un expediente legal extenso o analizar un informe técnico largo donde la conclusión depende del contexto de la introducción — tener el documento completo en el contexto tiene sentido. Aquí la linealidad es una ventaja, no una debilidad.
Conversaciones largas con historial completo. Sistemas de chat multi-turno donde cada pregunta depende de la respuesta anterior — soporte al cliente con historial, asistencia técnica donde se va refinando una solución a lo largo de decenas de intercambios. Guardar todo el historial en el contexto es más sencillo que implementar una memoria sofisticada.
Code review o refactorización de un repositorio completo. Cuando se necesita que el modelo corrija una dependencia en varios archivos a la vez, el contexto de todo el código elimina inconsistencias. Así es exactamente como funcionan los agentes de coding modernos — Cursor, Claude Code y similares.
Una pregunta larga y puntual. Si se carga un contrato de 300 páginas una vez al mes y se pregunta sobre cláusulas de responsabilidad, la economía funciona. Una llamada, una salida clara, baja frecuencia — el coste es aceptable.
Cuándo RAG es más barato y más preciso
La mayoría de los sistemas LLM en producción en empresas funcionan de otra manera: una base de conocimiento extensa (documentación técnica, normas ISO, reglamentos internos, historiales de registros de servicio) sobre la que consultan decenas o cientos de empleados al día. Aquí el contexto largo sin RAG deja de tener sentido económico.
Situaciones donde RAG es la elección correcta:
- Alto número de llamadas con fuentes superpuestas. Si cien operarios al día hacen preguntas distintas sobre el mismo manual, RAG extrae solo los fragmentos relevantes y se paga una fracción de los tokens.
- La base de datos crece. El context window es fijo — si la documentación tiene 10 millones de tokens, ni una ventana de 1M es suficiente. RAG escala con el tamaño de la base sin cambiar la arquitectura.
- Se necesitan localizaciones precisas de la fuente. RAG devuelve chunks concretos con referencias. El contexto largo ofrece una respuesta, pero sin atribución a un párrafo concreto — algo importante en entornos regulados.
- La latencia baja es clave. El tiempo hasta el primer token (TTFT) crece con la longitud del contexto. Con 128K tokens la latencia es varios órdenes de magnitud mayor que con un contexto de 4K con chunks RAG relevantes.
Una comparación más detallada de ambos enfoques se encuentra en el artículo RAG vs fine-tuning — toma de decisiones, donde también se analizan escenarios combinados.
Enfoque híbrido: contexto + RAG
En la práctica, los mejores sistemas en producción no eligen entre «contexto completo» y «RAG puro» — utilizan ambos según la situación. Una arquitectura típica:
- 1.System prompt e instrucciones globales — estático, cacheado mediante prompt caching, barato en lecturas repetidas.
- 2.Chunks recuperados dinámicamente — fragmentos relevantes de la documentación, añadidos al contexto según la consulta. Típicamente 5–20 chunks de 200–500 tokens cada uno.
- 3.Historial de conversación — los últimos N intercambios, resumen del historial más antiguo si es necesario.
- 4.Documento completo en el contexto — solo si el documento es corto (menos de 50K tokens) y la tarea requiere el conjunto.
Esta combinación mantiene el tamaño efectivo del contexto en las consultas habituales entre 8 y 32K tokens, lo que es varios órdenes de magnitud más barato que los 500K+ de un «carga todo» ingenuo.
Toma de decisiones práctica: preguntas antes del despliegue
Antes de decidir la arquitectura, responda estas preguntas:
- ¿Cuántas veces al día se usa la misma base de conocimiento? Si más de 50 veces, RAG compensa económicamente incluso con costes de configuración más altos.
- ¿La base supera los 500K tokens? Si es así, el contexto largo no es suficiente y RAG es la única opción realista.
- ¿Depende la respuesta de la lectura secuencial del documento completo? Si es así, el contexto largo es una elección legítima.
- ¿Cuál es la tolerancia a la latencia? Una conversación en tiempo real con un requisito inferior a 2 segundos y el contexto largo son difíciles de combinar.
- ¿Se necesitan fuentes citables? RAG proporciona el chunk con la referencia; el contexto largo no.
Si la mayoría de las respuestas son «no, no, sí, alta, no» — el contexto largo puede ser la elección correcta. Si prevalece lo contrario, RAG o una arquitectura híbrida será mejor tanto económica como cualitativamente.
Prompt caching como punto intermedio
Un caso especial es la situación en que se tiene un contexto relativamente grande pero estático — por ejemplo, un manual de estilo corporativo, un extenso system prompt con instrucciones, o documentación de referencia. Aquí el prompt caching ofrece un punto intermedio atractivo:
- Primera llamada: se paga el precio completo por el write en cache (125–200 % del precio de entrada normal).
- Cada llamada siguiente dentro de la ventana TTL (5 minutos o 1 hora en Anthropic): se paga el 10 % del precio del token de entrada por la parte cacheada.
- Con un prefijo estático repetido diez veces, los costes totales son significativamente menores que sin cache.
Los ahorros típicos en producción con un workload adecuado alcanzan el 50–70 % de los costes de tokens de entrada. El énfasis está en «workload adecuado» — si cada usuario llega con un prompt largo completamente distinto, el cache hit rate estará cerca de cero y el cache write encarecerá el proceso.
Qué implica esto en la elección de hardware y del framework de serving
Si se opta por contextos realmente largos en un despliegue on-prem, es importante entender las implicaciones de hardware.
La KV cache para contextos largos necesita mucha VRAM adicional sobre los propios pesos del modelo. Para un modelo de 70B con 128K de contexto, la KV cache por sí sola ronda los 40 GB — a eso hay que añadir ~140–168 GB para los pesos del modelo en FP16 (o ~35–40 GB para la cuantización Q4_K_M). Esto supera rápidamente la capacidad de una sola GPU y requiere un setup multi-GPU o tensor parallelism.
En el lado de los frameworks de serving: vLLM y SGLang implementan PagedAttention y RadixAttention — técnicas que reducen la fragmentación de la KV cache y permiten compartirla de forma más eficiente entre solicitudes procesadas en paralelo. Ollama es excelente para escritorio y experimentos, pero para serving multi-usuario en producción con contextos largos el rendimiento es varios órdenes de magnitud inferior. Puede encontrar más información sobre la comparación de frameworks en vLLM vs SGLang vs Ollama.
El Grouped Query Attention (GQA), implementado por la mayoría de los modelos modernos, reduce significativamente el tamaño de la KV cache frente al clásico multi-head attention — al elegir un modelo para contexto largo es importante verificar que sea compatible con GQA.
Preguntas frecuentes
¿Reemplazará un millón de tokens a RAG por completo?
Para la mayoría de los sistemas en producción, no. La economía no funciona: 1M de tokens en cada llamada es varios órdenes de magnitud más caro que el retrieval de chunks relevantes. Además, la degradación de calidad con contextos muy largos es real. El contexto largo tiene sentido para análisis puntuales de documentos extensos, no para un sistema donde la misma base se consulta cien veces al día.
¿Cuánto disminuye la calidad de las respuestas con contextos largos?
Depende de la tarea. En la búsqueda simple de un hecho (needle-in-a-haystack), los modelos modernos son fiables incluso con 1M de tokens. En tareas más complejas — conexión de información de varios lugares, razonamiento multi-hop — la precisión disminuye de forma más marcada al aumentar la longitud. El fenómeno «lost in the middle» está documentado experimentalmente y hay que tenerlo en cuenta en el diseño de la arquitectura.
¿Es siempre ventajoso el prompt caching?
No. Es ventajoso con un prefijo estático o poco cambiante que se lee repetidamente dentro de la ventana TTL (5 minutos o 1 hora). Los tokens de cache write son más caros que los tokens de entrada normales (1,25–2× en Anthropic). Si cada usuario aporta un contexto largo único, o si la frecuencia de llamadas es baja, el cache hit rate será bajo y los costes totales pueden ser más altos que sin cacheo.
¿Qué hardware necesito para un despliegue local con contexto largo?
Depende del modelo y la longitud. Como referencia orientativa: para un modelo de 70B con 32K tokens se necesitan unos 50–80 GB de VRAM en total (pesos + KV cache con cuantización Q4). Con 128K tokens la KV cache por sí sola ronda los 40 GB (para 70B, KV en FP16). Para un modelo de 7B la situación es más favorable — con 128K tokens es viable en una GPU de gama alta con 40–80 GB de VRAM. La serie Apple M con memoria unificada (hasta 128–192 GB en M5 Ultra) es una interesante alternativa on-prem para 70B con contexto largo.
¿Se aplican los mismos principios a los modelos open-weight on-prem y a las API cloud?
La economía es distinta, los principios son los mismos. En una API cloud se paga directamente por tokens. On-prem se paga por hardware (CAPEX) y energía (OPEX) — pero la KV cache y, por tanto, las exigencias de memoria GPU crecen de la misma manera. La decisión «contexto largo vs RAG» no depende solo del coste de los tokens, sino de la arquitectura total de hardware, el tamaño del batch y la latencia.
*Si está diseñando la arquitectura de un sistema LLM y no tiene claro dónde está para usted la frontera entre contexto largo, prompt caching y RAG, en MP Industrial Solutions estaremos encantados de analizar su caso concreto — aportamos experiencia de despliegues en la industria donde cada euro de costes operativos cuenta.*