200K de contexto en una 4070 Ti Super: cómo el mismo archivo Qwen 27B decodificó 4x más rápido con streaming KV adaptativo

Una ventana de contexto más grande suele castigar al hardware local, pero esta prueba afirma que un cambio de motor invierte ese compromiso: el mismo archivo Qwen 3.8 27B IQ4XS alcanzó un contexto configurado de 200.000 tokens en un equipo Ryzen 7 con RTX 4070 Ti Super y se mantuvo reactivo. El canal detrás de la prueba es Token Race, y la configuración apunta a documentos largos, repositorios y sesiones de agentes en lugar de un chat corto. La afirmación central es que el diseño de la gestión del contexto, y no la memoria de vídeo bruta, decide si esa ventana sigue siendo productiva.

El marcador es inequívoco en ambos tamaños. A 100.000 tokens, el streaming KV adaptativo promedió 34,53 tokens generados por segundo mientras que el llama.cpp de serie promedió 12,58, una ventaja media de 2,83x con prompts emparejados. A 200.000 tokens, el adaptativo mantuvo 33,68 frente a 8,04 del de serie, una ventaja de 4,24x. El autor afirma que la configuración adaptativa ganó todas las comparaciones con prompts emparejados en ambos tamaños, así que el titular se apoya en la matriz completa de 11 prompts y no en una entrada favorable.

Esto se presenta como un resultado de motor de inferencia más que como una revisión de inteligencia, y los controles respaldan ese encuadre. Cada ejecución usó el mismo archivo de modelo IQ4XS con ajustes de contexto emparejados, un slot paralelo, flash attention, caché de claves Q8_0 con caché de valores Q4_0, tamaños de batch y micro-batch emparejados, y sin offload del proyector multimodal. Cada uno de los 11 prompts generó 256 tokens por completación, lo que mantiene la comparación en el comportamiento de decodificación bajo condiciones de servicio idénticas.

El detalle a 100.000 tokens muestra que la brecha no es un artefacto de prompts cortos. Las entradas cortas se agruparon cerca de 36 a 37 tokens por segundo en adaptativo frente a unos 14 en la versión de serie. Con unos 17.000 tokens de entrada, la pareja marcó 33,55 frente a 11,17, y con unos 25.000 de entrada fue 32,44 frente a 10,28. La entrada de 77.000 tokens ralentizó ambos motores como era de esperar, pero el adaptativo aun así produjo 20,09 frente a 5,06, lo que importa porque la carga de trabajo arrastrada es el caso realista del contexto largo.

El gráfico a 200.000 tokens convierte la historia de motor en una historia de capacidad. Seis entradas por debajo de 1.000 tokens promediaron 36,77 para el adaptativo frente a 9,06 para el de serie; dos entradas de 1.000 a 10.000 promediaron 36,45 frente a 8,83; dos entradas entre 10.000 y 50.000 llegaron a 31,42 frente a 6,68. La prueba de fuego es el prompt de 77.418 tokens: 14,09 tokens por segundo en adaptativo frente a 3,07 en serie, una ventaja de 4,59x justo en el tipo de documento largo o base de código que rompe las configuraciones locales ingenuas.

Las instantáneas de memoria se mantuvieron cerca mientras que la ubicación del cómputo divergía, y ese es el detalle más revelador. El adaptativo reportó 14.606 MB a 100.000 de contexto y 14.510 MB a 200.000; el de serie reportó 13.774 MB y 14.008 MB. La división visible estaba en la ubicación del cómputo: las ejecuciones adaptativas mantuvieron toda su pila de 66 capas en la tarjeta en ambas configuraciones, mientras que las de serie cayeron a 54 capas y luego a 43. Ese patrón respalda el diseño declarado del fork: mover la presión del contexto grande fuera de la residencia permanente en GPU en lugar de acaparar cada vez más memoria de vídeo.

El mecanismo tiene tres partes: los tensores de claves y valores autoritativos viven en la RAM del sistema fijada (pinned), la GPU conserva un grupo acotado de páginas residentes más un anillo de transferencia, y el motor reparte ese grupo a medida que crece el contexto. Durante la decodificación precarga las capas siguientes mientras la capa actual aún calcula, de modo que la siguiente capa encuentra su página lista. En términos sencillos, la GPU se queda en el cálculo del modelo mientras la RAM del sistema carga el contexto creciente y el conjunto de trabajo fluye por la memoria de vídeo.

Los comandos coinciden con ese diseño respaldado en memoria: el peso de embedding de tokens está en la CPU, con una etapa de streaming de 1024 MB a 100.000 de contexto y de 512 MB a 200.000. Las ejecuciones de serie dejaban la ubicación al ajuste automático y perdían capas de GPU a medida que crecía el contexto configurado. La documentación del fork describe el mismo enfoque con otras palabras: streaming CUDA página a página de las claves y valores en caché, con la división residente-más-transferencia reequilibrada al vuelo y lotes de transferencia ajustados a cada máquina. La advertencia honesta cierra el círculo: el contexto grande no es gratis, las transferencias siguen haciendo trabajo real, y los valores de 1024 y 512 MB son puntos de partida que hay que revalidar por equipo.