Key Takeaways
- Llama 4 Scout (MoE) soporta hasta 10M tokens. DeepSeek V4-Flash y Qwen 3.6 soportan 1M y 256K tokens respectivamente (extensible a 1M mediante YaRN). Mayo de 2026 marca la primera generación de modelos abiertos capaces de millones de tokens.
- Contexto práctico por tamaño de modelo: los modelos 7B-8B mantienen calidad fiable en 16K-32K tokens. Los modelos de 70B+ y MoE lo extienden a 256K-1M tokens. Llama 4 Scout puede manejar contextos completos de un millón de tokens con VRAM suficiente.
- La RAM escala con la longitud del contexto Y el tamaño del modelo. Qwen 3.6 27B en Q4_K_M necesita ~22 GB con 128K y ~65+ GB con 1M de tokens. Llama 4 Scout necesita más de 150 GB para el contexto completo de 10M.
- El problema "Lost in the Middle" sigue vigente: los LLM pierden detalles de las secciones centrales del contexto. Mitigación: mantén la información crítica al inicio del prompt, usa RAG para búsquedas o procesa en fragmentos solapados.
- El contexto largo destaca en el análisis holístico de documentos completos (bases de código, contratos, libros). RAG destaca en tareas de búsqueda intensiva en muchos documentos. Elige según el tipo de tarea, no solo por el tamaño del contexto.
- Ollama usa 2048 tokens por defecto -- no 128K ni 1M. Establece num_ctx explícitamente en un Modelfile para acceder al contexto completo. Para contextos masivos (500K+), ajusta la implementación de atención para evitar OOM.
¿Qué es la longitud de contexto y por qué importa para los LLM locales?
La longitud de contexto es el número máximo de tokens que un modelo puede procesar en una sola llamada de inferencia -- el tamaño combinado de la entrada (tu documento, el historial de conversación, el prompt del sistema) y la salida (la respuesta del modelo). Un token ≈ 0,75 palabras en español; 128K tokens ≈ 96.000 palabras.
Para los casos de uso de LLM locales, el contexto largo permite: resumir libros enteros o informes largos, analizar bases de código completas en un solo prompt, procesar horas de transcripciones de reuniones y mantener historiales de conversación largos sin perder el contexto anterior.
La distinción clave es entre la longitud de contexto anunciada (lo que soporta la arquitectura del modelo) y la longitud de contexto práctica (donde la calidad se mantiene fiable). Un modelo puede soportar técnicamente 128K tokens, pero mostrar calidad degradada en la información presentada en el token número 100K.
¿Qué LLM locales soportan contexto de 128K tokens en 2026?
| Modelo | Ventana de contexto | Límite práctico | Comando Ollama |
|---|---|---|---|
| Llama 3.1 8B | 128K | ~32K fiable | ollama run llama3.2 |
| Llama 3.2 3B | 128K | ~16K fiable | ollama run llama3.2:3b |
| Llama 3.3 70B | 128K | ~64K fiable | ollama run llama3.3:70b |
| Qwen2.5 7B | 128K | ~32K fiable | ollama run qwen2.5:7b |
| Qwen2.5 72B | 128K | ~64K fiable | ollama run qwen2.5:72b |
| Mistral Small 3.1 24B | 128K | ~32K fiable | ollama run mistral-small3.1 |
| Gemma 2 2B | 8K | ~6K fiable | ollama run gemma2:2b |
| Mistral 7B v0.3 | 32K | ~16K fiable | ollama run llama3.2 |
¿Cuánta RAM necesita el procesamiento de contexto largo?
El uso de RAM escala tanto con el tamaño del modelo como con la longitud del contexto. El caché KV (caché clave-valor) almacena los estados de atención de todos los tokens procesados -- esto crece linealmente con la longitud del contexto.
A partir de abril de 2026, un modelo 7B en Q4_K_M con 4K de contexto usa ~6 GB de RAM. El mismo modelo con 32K de contexto usa ~8-9 GB de RAM. Con 128K de contexto: ~12-16 GB de RAM.
| Modelo | Contexto 4K | Contexto 32K | Contexto 128K |
|---|---|---|---|
| Llama 3.1 8B Q4_K_M | ~6 GB | ~9 GB | ~14 GB |
| Qwen2.5 14B Q4_K_M | ~9 GB | ~12 GB | ~18 GB |
| Mistral Small 3.1 24B Q4_K_M | ~14 GB | ~17 GB | ~24 GB |
| Llama 3.3 70B Q4_K_M | ~40 GB | ~45 GB | ~55 GB |
¿Por qué el contexto práctico es más corto que el máximo anunciado?
Los LLM entrenados con codificaciones de posición RoPE (usadas por Llama, Qwen, Mistral) pueden procesar técnicamente tokens hasta su longitud máxima de contexto, pero la calidad se degrada con un patrón conocido llamado efecto "lost in the middle".
Las investigaciones muestran que los modelos de lenguaje aprovechan mejor la información al principio y al final de la ventana de contexto. La información colocada en el medio de un contexto muy largo se recupera con menos fiabilidad. En la práctica, un modelo con 128K de ventana de contexto puede responder preguntas sobre el contenido de los primeros 32K tokens y los últimos 16K tokens de forma fiable, pero perder detalles del rango de 40K-80K tokens.
Para los modelos locales en particular, el límite práctico fiable escala con el tamaño del modelo: los modelos 3B ≈ 8K-16K fiable; los modelos 7B-8B ≈ 16K-32K fiable; los modelos 70B ≈ 64K fiable. Estas son aproximaciones -- el límite real depende de la tarea específica y de qué tan "importante" es la información recuperada.
Las ventanas de contexto largo permiten más entrada, pero la estructura del prompt determina si el modelo usa ese contexto de forma efectiva. Técnicas como RAG, encadenamiento de prompts y estrategias de gestión de ventanas de contexto se cubren en la guía de prompt engineering.
¿Cómo se configura la longitud de contexto en Ollama?
Ollama usa 2048 tokens de contexto por defecto, a menos que se configure de otra forma. Para usar la ventana de contexto completa de un modelo:
El tamaño de la ventana de contexto determina cuánto texto puede procesar un modelo, pero la estructura del prompt determina con qué efectividad usa ese contexto. Para profundizar en por qué los modelos pierden el rastro de la entrada anterior y las estrategias para mitigarlo, consulta ventanas de contexto explicadas: por qué la IA olvida.
# Set context length at runtime
ollama run llama3.2 --ctx 32768
# Or create a custom model with a Modelfile
cat << EOF > Modelfile
FROM llama3.1:8b
PARAMETER num_ctx 32768
EOF
ollama create llama3.1-32k -f Modelfile
ollama run llama3.1-32k
LLM locales de contexto largo: contexto regional
UE / RGPD + Ley de IA: La Ley de IA de la UE (en vigor desde febrero de 2025) clasifica los sistemas de IA que procesan datos personales a gran escala como potencialmente de alto riesgo. La inferencia local de contexto largo para análisis de documentos legales, resumen de historiales médicos o procesamiento de documentos de RRHH se encuentra en este nivel de riesgo. Ejecutar de forma local elimina el riesgo del procesador de datos de terceros según el Artículo 28 del RGPD -- ningún dato sale de la organización.
Para la conformidad con el BSI alemán en sistemas de IA que procesan documentos sensibles de forma local: la configuración recomendada es un modelo 7B en Q4_K_M con 32K de contexto (cabe en 9-10 GB de RAM en una estación de trabajo estándar). Esto proporciona calidad fiable en documentos de hasta 50 páginas manteniendo todos los datos en las instalaciones. Llama 3.1 8B y Mistral Small 3.1 son las opciones recomendadas para conformidad con la UE en procesamiento de documentos de contexto largo.
Para las directrices de la CNIL francesa sobre IA y datos personales: la inferencia local mediante Ollama sin llamadas a API externas satisface el requisito de que los datos personales no sean procesados por proveedores externos de IA sin una base jurídica válida.
Japón (METI): Los documentos japoneses requieren 1,5-2 veces más tokens que los documentos equivalentes en inglés debido a las diferencias del tokenizador. Un informe japonés de 50 páginas puede consumir 25K-35K tokens -- dentro del rango fiable de Qwen2.5 7B (límite práctico 32K) pero requiriendo configuración explícita del contexto en Ollama: PARAMETER num_ctx 32768. Para documentos legales y financieros en japonés, Qwen2.5 14B en Q4_K_M con 32K de contexto (~12 GB de RAM) ofrece la mejor relación calidad/RAM para procesamiento de contexto largo en japonés. El tokenizador nativo en japonés de Qwen2.5 procesa texto japonés un 30-40% más eficientemente que Llama.
China: Bajo la Ley de Seguridad de Datos de China (数据安全法), el procesamiento de documentos sensibles a través de APIs en la nube requiere conformidad regulatoria adicional. La inferencia local de contexto largo mediante Qwen2.5 (Alibaba) mantiene todo el contenido de los documentos en las instalaciones. Para el procesamiento empresarial de documentos en chino, Qwen2.5 72B con 32K de contexto en una estación de trabajo local (~45 GB de RAM) ofrece calidad casi equivalente a la nube con total soberanía de datos. El tokenizador nativo en chino de Qwen2.5 lo hace un 30-40% más eficiente en tokens que Llama para documentos en chino.
Errores comunes con los LLM locales de contexto largo
- Asumir que el contexto de 128K funciona igual de bien que 4K: El efecto "lost in the middle" significa que la información presentada hace 30K-80K tokens se recupera con menos fiabilidad que la información al inicio o al final. Para análisis de documentos críticos, divide los documentos largos en secciones de 16K-32K y procesa cada una por separado en lugar de alimentar todo un documento de 100K a la vez.
- No aumentar el tamaño de contexto por defecto de Ollama: Ollama usa 2048 tokens de contexto por defecto independientemente del máximo del modelo. Una conversación que supere los 2048 tokens truncará los mensajes anteriores. Siempre establece num_ctx explícitamente: añade PARAMETER num_ctx 32768 a tu Modelfile o usa --ctx en tiempo de ejecución.
- Ejecutar contexto largo con RAM insuficiente: Un modelo 7B con contexto de 128K en 8 GB de RAM total causa un uso severo del swap. Los pesos del modelo (~4,5 GB) más el caché KV de 128K (~8+ GB) superan los 8 GB. Reduce el contexto a 32K (cabe en ~9 GB) o usa 16+ GB de RAM para inferencia con contexto de 128K.
- Olvidar que la velocidad de generación no es el único factor de latencia con contexto largo: Con 32K de contexto, el tiempo hasta el primer token (TTFT) puede ser de 5-15 segundos en hardware de consumo -- el modelo debe procesar los 32K tokens de entrada antes de generar un solo token de salida. Esta fase de prefill escala linealmente con la longitud del contexto. Para uso interactivo, limita el contexto a 8K-16K. Reserva contextos de 32K+ para el procesamiento por lotes donde el TTFT es aceptable.
- Usar RAG cuando el contexto largo es la herramienta correcta (y viceversa): RAG es mejor para buscar en muchos documentos. El contexto largo es mejor cuando necesitas que el modelo razone sobre un documento completo y coherente -- un contrato, una base de código, un capítulo de libro -- donde perder cualquier parte rompería el análisis. Dividir un contrato legal de 10 páginas en fragmentos para RAG puede causar errores de referencias cruzadas que el contexto largo evita. Elige según el tipo de tarea, no por preferencia por defecto.
Preguntas frecuentes
¿Puedo resumir un libro completo con un LLM local?
Un libro típico de 300 páginas tiene 90.000-120.000 palabras -- aproximadamente 120K-160K tokens. Esto supera el contexto confiable práctico de la mayoría de los modelos 7B y requiere un modelo de 70B (64K fiable) o procesamiento por fragmentos. Para modelos 7B, divide el libro en capítulos de 20K palabras, resume cada uno y luego resume los resúmenes de los capítulos.
¿Cuántas páginas de texto caben en 32K tokens?
Aproximadamente 50-70 páginas de texto estándar (250 palabras por página). Un contexto de 32K tokens puede contener una novela corta, un artículo de investigación completo con apéndices o un documento de especificación técnica completo.
¿Aumentar la longitud de contexto ralentiza la inferencia?
Sí -- procesar un contexto de 32K tarda aproximadamente 3-4 veces más que procesar un contexto de 4K en el mismo hardware, debido al escalado cuadrático del cálculo de atención. La velocidad de generación (tokens por segundo) no se ve afectada de forma significativa, pero el tiempo hasta el primer token (TTFT) escala con la longitud de la entrada.
¿Qué LLM local maneja mejor RAG que el contexto largo?
Para tareas de búsqueda y recuperación de documentos, RAG (generación aumentada por recuperación) suele ser más efectivo que alimentar documentos completos como contexto. RAG recupera los 3-5 fragmentos más relevantes de un gran conjunto de documentos y solo proporciona esos al modelo. Esto usa 4K-8K tokens de contexto y evita el problema "lost in the middle". Herramientas como GPT4All LocalDocs y LlamaIndex implementan RAG local.
¿Qué es el caché KV y por qué crece con la longitud del contexto?
El caché KV (caché clave-valor) almacena los estados de atención de cada token procesado en la ventana de contexto. Cada token requiere una cantidad fija de memoria para sus vectores clave y valor -- por eso un contexto de 32K requiere 8 veces más memoria de caché KV que uno de 4K. Es por esto que un modelo 7B en Q4_K_M necesita ~6 GB para 4K de contexto, pero ~9 GB para 32K. Los pesos del modelo no cambian -- solo crece el caché KV.
¿Los modelos locales pueden manejar contextos de 1M tokens como Gemini 3.1 Pro?
No -- a partir de abril de 2026, ningún modelo ejecutable localmente soporta contextos de 1M tokens. La ventana de 1M tokens de Gemini 3.1 Pro requiere la infraestructura TPU de Google. De forma local, 128K es el máximo soportado por el hardware de consumo actual. Para tareas que requieren contextos de 1M+ tokens, las APIs en la nube siguen siendo la única opción práctica.
¿Qué es el problema "lost in the middle" y cómo lo evito?
Las investigaciones muestran que los LLM recuperan de forma fiable la información del principio y el final de la ventana de contexto, pero pierden detalles del medio. Para un contexto de 128K, el contenido colocado en los tokens 40K-80K es el que más probable es que sea ignorado. Para evitarlo: mantén la información importante al inicio del prompt, usa RAG para recuperar solo los fragmentos relevantes, o procesa documentos largos en secciones solapadas de 16K-32K.
¿Cómo verifico qué longitud de contexto está usando Ollama?
Ejecuta `ollama show <modelo>` -- la salida lista los parámetros incluyendo num_ctx. Si muestra 2048, Ollama está usando el valor por defecto, no la ventana de contexto completa del modelo. Para cambiarlo de forma persistente, crea un Modelfile con PARAMETER num_ctx 32768 y ejecuta ollama create <nombre> -f Modelfile. Verifica las sesiones activas con ollama ps.
¿Es mejor el contexto largo o RAG para preguntas y respuestas sobre documentos?
RAG suele ser más efectivo y eficiente en RAM que el contexto largo para preguntas y respuestas sobre documentos. RAG recupera 3-5 fragmentos relevantes (4K-8K tokens en total) de un corpus grande y evita el problema "lost in the middle". El contexto largo es mejor cuando el modelo necesita entender la estructura completa del documento o cuando el orden exacto y las relaciones entre secciones son importantes. Para la mayoría de las preguntas y respuestas prácticas sobre documentos, empieza con RAG.
Fuentes
- Lost in the Middle: How Language Models Use Long Contexts -- Liu et al., 2023
- Ollama Context Length Configuration -- Documentación de Ollama
- Llama 3.1 Technical Report -- Meta AI, 2024
- EU AI Act Official Text -- Parlamento Europeo, 2024