Galahad-kv guarda la KV-cache en NVMe y carga un bloque entre 2,8 y 4,3 veces más rápido que recalcularlo
Los autores de un preprint en arXiv probaron la capa de memoria galahad-kv. Guarda el estado KV de bloques de unos 16 000 tokens en un NVMe local cifrado y lo devuelve byte a byte, sin recalcular. La prueba usó 50 M de tokens de texto real, vLLM, una sola H100 y los modelos Gemma 4 12B y 31B. Cargar un bloque resultó entre 2,8 y 4,3 veces más rápido que recalcularlo y requirió entre 8,8 y 12,3 veces menos energía de la GPU. Ante hechos ocultos millones de tokens antes de la pregunta, el modelo 12B respondió bien en 82 de 100 casos y el 31B, en 98. • 100 de 100 bloques se cargaron sin recálculo • La memoria de la GPU no creció a lo largo de todo el flujo de 50 M de tokens • El precio: terabytes de NVMe y una escritura única de la memoria
Procesado por IA desde arXiv cs.CL; editado por Hamidun News
Los investigadores probaron una capa de memoria para LLM que no recalcula el prompt desde cero, sino que recupera del disco el estado KV ya preparado. El paquete galahad-kv se ejecutó sobre 50 M de tokens de texto público real mediante vLLM, en una sola NVIDIA H100 y con los modelos Gemma 4 12B y Gemma 4 31B. Los 100 bloques verificados, de 100, se devolvieron desde el almacenamiento sin recálculo. La carga resultó entre 2,8 y 4,3 veces más rápida, y la GPU gastó entre 8,8 y 12,3 veces menos energía.
Cómo funciona la capa de memoria
El modelo solo usa el texto que cabe en la ventana de contexto. Además, cada vez que recibe un prompt vuelve a calcular su estado interno KV (key-value), aunque el texto pueda no haber cambiado. En contextos largos, ese recálculo consume tiempo y energía.
Galahad-kv divide el flujo en bloques de aproximadamente 16 000 tokens. El estado KV de cada bloque se escribe en un disco NVMe local cifrado y, cuando se necesita, se devuelve byte a byte con exactitud. Según una estimación aproximada, 50 M de tokens equivalen a unos 3 100 bloques. El almacenamiento necesario se mide en terabytes.
Los autores aclaran de entrada que se trata de reutilizar un estado guardado. La ventana de atención sigue igual, solo se carga un bloque cada vez y la calidad de la respuesta depende del propio modelo.
Qué mostraron las mediciones
La prueba se hizo en una sola H100 con vLLM, y la profundidad de los bloques verificados llegó hasta los 50 M de tokens. Estas son las métricas clave:
- 100 de 100 bloques verificados se cargaron desde el almacenamiento cifrado sin recálculo, en ambos modelos y a profundidades de 0 a 50 M de tokens;
- la carga de un bloque es entre 2,8 y 4,3 veces más rápida que recalcularlo;
- el consumo de energía de la GPU es entre 8,8 y 12,3 veces menor;
- la memoria de la GPU se mantuvo estable a lo largo de todo el flujo de 50 M de tokens;
- Gemma 4 12B respondió correctamente 82 preguntas de 100 y Gemma 4 31B, 98 de 100;
- ninguno de los dos modelos inventó una respuesta.
El último punto importa tanto como la velocidad. En preguntas sobre hechos colocados millones de tokens antes de la consulta, lo más habitual es que el modelo falle respondiendo con aplomo algo que no viene al caso. Aquí los errores se limitaron a la ausencia de la respuesta correcta, no a alucinaciones. La diferencia entre el 82 % y el 98 % indica que la capa de memoria entrega el estado, pero leerlo bien le corresponde al propio modelo. El mayor lo hace notablemente mejor.
Límites del enfoque y a quién le sirve
El enfoque tiene tres limitaciones. La escritura de la memoria cuesta una vez: cada bloque debe calcularse y guardarse una sola vez. El almacenamiento exige terabytes de NVMe local. Y solo se carga un bloque a la vez, de modo que las preguntas que requieren combinar hechos de muchos puntos del corpus a la vez no quedan cubiertas por esta prueba. Es un preprint en su primera versión y por ahora no se ven reproducciones independientes. Sin embargo, los autores describen un protocolo diseñado para protegerse de las formas habituales de burlar los benchmarks de contexto largo, y ofrecen una reproducción en una sola GPU con software público y una licencia gratuita para el paquete.
La conclusión práctica para los ingenieros es esta. El enfoque tiene sentido allí donde un mismo gran volumen de texto se lee una y otra vez: repositorios de código, documentación, archivos, el historial largo de un agente. En esos casos, el recálculo del prefijo se lleva la mayor parte del tiempo de GPU.
Antes de implantarlo conviene calcular tres cosas: cuántos terabytes de NVMe harán falta para su corpus, si la escritura única se amortiza con su frecuencia de consultas y si su modelo basta para leer con precisión el bloque cargado. Para comprobarlo bastan una H100 y la pila pública del artículo. Una ejecución con sus propios datos mostrará rápidamente si se repiten las cifras de 2,8 a 4,3 veces en velocidad y de 8,8 a 12,3 veces en energía.
Preguntas frecuentes sobre la noticia
Cómo funciona la capa de memoria?
El modelo solo usa el texto que cabe en la ventana de contexto. Además, cada vez que recibe un prompt vuelve a calcular su estado interno KV (key-value), aunque el texto pueda no haber cambiado. En contextos largos, ese recálculo consume tiempo y energía. Galahad-kv divide el flujo en bloques de aproximadamente 16 000 tokens. El estado KV de cada bloque se escribe en un disco NVMe local cifrado y, cuando se necesita, se devuelve byte a byte con exactitud. Según una estimación aproximada, 50 M de tokens equivalen a unos 3 100 bloques. El almacenamiento necesario se mide en t
¿Qué se sabe sobre Qué mostraron las mediciones?
La prueba se hizo en una sola H100 con vLLM, y la profundidad de los bloques verificados llegó hasta los 50 M de tokens. Estas son las métricas clave: 100 de 100 bloques verificados se cargaron desde el almacenamiento cifrado sin recálculo, en ambos modelos y a profundidades de 0 a 50 M de tokens; la carga de un bloque es entre 2,8 y 4,3 veces más rápida que recalcularlo; el consumo de energía de la GPU es entre 8,8 y 12,3 veces menor; la memoria de la GPU se mantuvo estable a lo largo de todo el flujo de 50 M de tokens; Gemma 4 12B respondió correctamente 82 preguntas de 1
¿Qué se sabe sobre Límites del enfoque y a quién le sirve?
El enfoque tiene tres limitaciones. La escritura de la memoria cuesta una vez: cada bloque debe calcularse y guardarse una sola vez. El almacenamiento exige terabytes de NVMe local. Y solo se carga un bloque a la vez, de modo que las preguntas que requieren combinar hechos de muchos puntos del corpus a la vez no quedan cubiertas por esta prueba. Es un preprint en su primera versión y por ahora no se ven reproducciones independientes. Sin embargo, los autores describen un protocolo diseñado para protegerse de las formas habituales de burlar los benchmarks de contexto largo,
Build & Ship Production AI Apps with Vibe Coding
Join Zhemal Khamidun's hands-on Vibe Coding Intensive at hamidun.com/vibecoding — master Claude Code, Cursor, and autonomous agentic workflows.
Lo esencial de la IA — una vez por semana
Siete historias que de verdad importaron, elegidas a mano. Sin ruido ni notas de prensa.
¡Listo! Revisa tu correo para la confirmación.