Qwen local se queda sin contexto antes de tiempo: separa KV cache, backend y GPU

Has configurado un Qwen local con 128K de contexto, pero quizá falla cerca de 72K, se vuelve demasiado lento o termina la respuesta sin respetar instrucciones del principio. Casi nunca hay un único ajuste mágico: la cuantización de los pesos, el KV cache, el backend de inferencia y la colocación en el hardware forman juntos el límite real.

Esta guía propone un diagnóstico repetible. Primero separarás capacidad, velocidad y memoria efectiva; después cambiarás una sola variable cada vez para decidir si conviene cambiar el KV cache, probar otro backend, redistribuir varias GPU o bajar el contexto objetivo de producción.

Respuesta directa: el contexto configurado es un techo, no una garantía

Seleccionar 128K solo pide al backend que prepare una entrada de ese tamaño. La configuración es viable mientras se cumpla este presupuesto:

pesos del modelo + KV cache + espacio de trabajo + margen de seguridad ≤ memoria que el backend puede usar realmente

Los pesos suelen ocupar una parte grande y casi fija al cargar el modelo. El KV cache crece con los token retenidos, mientras que los buffers temporales dependen del backend, el batch y los kernels. Incluso si todo cabe, la latencia o la capacidad de recuperar información lejana pueden dejar de ser aceptables antes del límite físico.

Por eso necesitas tres respuestas distintas: si cabe, si termina a una velocidad útil y si el modelo sigue aprovechando el principio. El valor máximo mostrado por una interfaz no responde por sí solo a ninguna.

Identifica el síntoma antes de cambiar toda la pila

“No llega a 128K” puede describir fallos muy distintos. Clasifica primero tu caso para no optimizar el componente equivocado.

Síntoma	Dirección más probable	Primera comprobación
Aparece OOM al cargar o reservar un contexto largo	Pesos y KV cache compiten por memoria, o una GPU no puede reservar su parte	Registra el pico y la memoria libre de cada GPU
El backend falla casi siempre cerca del mismo número de token	Formato del KV cache, implementación del backend o límite de asignación	Mantén modelo y hardware; cambia solo cache o backend
La entrada se acepta, pero el prefill o la generación se vuelven impracticables	Ancho de banda, tráfico entre GPU, kernels o longitud excesiva	Mide por separado el procesamiento del prompt y la generación
La respuesta termina, pero olvida restricciones tempranas	Calidad del contexto efectivo, no capacidad bruta	Coloca hechos de control a lo largo del prompt
La misma prueba unas veces pasa y otras falla	Falta de margen, carga concurrente o runtime inestable	Elimina otras cargas y repite tres veces

Si cabe pero es demasiado lento, reducir el KV cache no tiene por qué ser la mejor solución. Si cabe pero olvida el inicio, añadir VRAM tampoco garantiza una mejora.

Qué demuestra —y qué no— un salto reportado de 72K a 128K

En un informe de configuración del 23 de septiembre de 2026, Nigel Hungerford-Symes describió Qwen3.8-27B (Unsloth UD-Q5_K_M) en una RTX 5060 Ti de 16GB y una RTX 3070 de 8GB. La pila de 128K usaba beellama.cpp + kvarn5 KV + MTP n=2, con unos 36 tok/s en contexto corto y 18 tok/s a 126K; la configuración anterior con llama.cpp principal y KV q8_0 se detenía, según el autor, cerca de 72K.

El caso es relevante porque muestra que el límite utilizable de una máquina concreta puede cambiar al sustituir la pila de inferencia. No aísla la causa: cambiaron a la vez el backend, el esquema de KV cache y otros ajustes. Por tanto, no demuestra que un único formato haya producido todo el salto ni que esas velocidades se repitan en otro equipo.

Úsalo como pista de diagnóstico. Si tu límite aparece de forma estable en una longitud, incluye KV cache y backend en la comparación en vez de mirar solo el archivo del modelo.

Crea una línea base antes de tocar la configuración de 72K

Guarda una línea base reproducible antes de modificar nada. De otro modo, aunque la nueva pila funcione, no sabrás qué cambio fue decisivo.

Área	Valores que debes guardar
Modelo	Nombre completo, archivo exacto, cuantización de pesos, tamaño
Backend	Nombre, versión o commit, forma de arranque
Contexto	Ventana solicitada, token reales de entrada, token reservados para salida
KV cache	Tipo o esquema, colocación en GPU o RAM, ajustes de compresión
Hardware	Modelo y VRAM de cada GPU, RAM del sistema, topología PCIe
Colocación	Reparto entre GPU, componentes descargados, cruces entre dispositivos
Runtime	Batch, concurrencia, muestreo, salida máxima
Resultado	Éxito o error, texto exacto, pico de VRAM/RAM, velocidad de prefill y generación

No trates una GPU de 16GB y otra de 8GB como un único bloque sencillo de 24GB. El backend decide dónde viven pesos, cache y buffers; una tarjeta puede llenarse primero y el tráfico entre dispositivos puede dominar el coste en contextos largos.

Prueba cuatro variables por separado

1. La cuantización de pesos cambia la ocupación fija

La cuantización del modelo modifica sobre todo la memoria necesaria para cargar los pesos. Un archivo más pequeño puede dejar espacio para el KV cache, pero no garantiza un contexto más largo y también puede cambiar calidad o velocidad.

Para comprobar si los pesos están expulsando al cache, conserva backend, tipo de KV y prompt. Cambia solo la cuantización de pesos y registra cuánta memoria libera y si se desplaza el punto de fallo.

2. El tipo de KV cache cambia el coste por token

El KV cache conserva estados reutilizados para los siguientes token. Con un modelo y una representación fijos, su uso de memoria suele crecer aproximadamente con los token retenidos, por lo que es la palanca más directa para contexto largo.

Compara tres resultados a la vez: pico de memoria, mayor entrada estable y precisión de recuperación. “Cabe 128K” no es una victoria útil si baja la exactitud o aumenta la inestabilidad.

3. El backend decide cómo se implementa todo

Los backends pueden variar en diseño del cache, asignación de memoria, reparto multi-GPU y kernels. El mismo valor de contexto y el mismo archivo no tienen por qué producir la misma curva de memoria ni la misma velocidad.

Si el backend candidato exige otro formato de KV, describe el resultado como “esta pila pasó”. No atribuyas todo a un solo formato. Para aislar el backend, repite un A/B con ajustes que ambos soporten siempre que sea posible.

4. La colocación del hardware determina qué recurso falla primero

El error habitual con varias GPU es observar solo la VRAM total. La ejecución puede fallar porque una tarjeta no consigue una reserva grande, el cache queda concentrado, no hay margen para el espacio de trabajo o el intercambio por PCIe vuelve inútil la velocidad.

Mide cada GPU. Si una está casi llena y otra conserva margen, reequilibra el reparto antes de sacrificar calidad del modelo.

Ejecuta una escalera de aceptación de contexto largo

No saltes de un prompt corto directamente a 128K. Una escalera fija muestra si el fallo aparece de golpe o si la configuración pierde utilidad poco a poco.

Un punto de partida práctico es 8K → 32K → 64K → 72K → 96K → 126K. 126K queda cerca de 128K y reserva espacio explícito para la salida; amplía esa reserva si necesitas respuestas largas.

Prepara un conjunto controlado de prompts

1. Cuenta token con el tokenizer usado realmente por el modelo; no estimes por caracteres ni por tamaño del archivo.
2. Inserta “hechos canario” distintos cerca del 10%, 20% y así hasta el 90%, por ejemplo ORBIT-17 = copper.
3. Añade una restricción de código al principio, otra en el centro y otra al final; pide que la respuesta las repita y aplique un cambio pequeño.
4. Mantén el orden del contenido, los parámetros de muestreo y el presupuesto de salida en todas las longitudes.
5. Elimina otras cargas y repite tres veces cada longitud crítica.

Los canarios miden recuperación, no toda la capacidad de programación. En la aceptación final añade código, logs o documentación parecidos a tu carga diaria.

Registra siempre las mismas métricas

Métrica	Pregunta que responde
Token reales de entrada	¿El backend aceptó la longitud objetivo?
Resultado de asignación y error exacto	¿Dónde fallan capacidad o compatibilidad?
Pico por GPU y pico de RAM	¿Qué dispositivo fue el cuello de botella?
Tiempo o velocidad de procesamiento del prompt	¿Sigue siendo aceptable el prefill?
Velocidad de generación	¿Es práctico interactuar después del prompt largo?
Canarios recuperados	¿Usa el modelo información distante?
Restricciones de código cumplidas	¿La ventana larga ayuda en la tarea real?

Define el criterio de aprobación antes de ejecutar. Un ejemplo: tres finalizaciones consecutivas en la longitud objetivo, ningún error de memoria o backend, al menos 9 de 10 canarios correctos y tiempos dentro del límite de tu flujo. 9/10 es solo un ejemplo; lo importante es no rebajar el listón después de ver un 128K que “arranca”.

Elige el siguiente paso según el resultado

Siempre aparece OOM en la misma longitud

Averigua qué dispositivo se llena primero. Si el crecimiento del cache consume el margen, compara primero un esquema de menor huella. Si los pesos dejan casi todo ocupado al cargar, prueba una cuantización más pequeña. Cambia una sola cosa y comprueba si el límite se mueve como esperabas.

El backend nuevo llega a 128K y el anterior se queda en 72K

Trata la nueva pila como candidata, repite tres veces y completa la prueba de recuperación. Si backend y cache cambiaron juntos, la conclusión defendible es que funciona la pila completa, no que hayas aislado una causa única.

128K termina, pero el rendimiento no es aceptable

Es un límite operativo, no un fallo de capacidad. Usa una ventana menor por defecto y activa contexto extremo solo en tareas concretas, o compara un modelo más pequeño, otro backend o una colocación mejor. “Puede ejecutarse” y “merece usarse a diario” son decisiones distintas.

128K termina, pero pierde información temprana

Trátalo como un problema de calidad del contexto efectivo. Ejecuta el mismo prompt a 64K, 72K y 96K para construir una curva de recuerdo. Si las longitudes menores son claramente más fiables, fija el límite de producción donde pasa la calidad, no donde cabe la memoria. La recuperación, el troceado o un resumen previo también pueden reducir material irrelevante en repositorios enormes.

Optimiza una ventana verificada, no el número mayor del menú

Si 72K cubre tus repositorios y logs habituales, no sustituyas a la vez cuantización, KV cache, backend y reparto de GPU solo para mostrar 128K. Conserva la base estable y exige que cada cambio demuestre una mejora de capacidad, velocidad o recuerdo.

Si de verdad necesitas más de 100K de entrada, define primero la escalera y los criterios de aceptación, y después compara combinaciones de cache y backend. La conclusión útil es concreta: “este modelo, backend, cache y hardware superaron 126K tres veces con nuestra velocidad y recuerdo mínimos”, no simplemente “la configuración admite 128K”.