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
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
Fuente: arXiv cs.CL. Collage: Hamidun News.
Escuchar artículo
Ficha técnica y cifras clave
ParámetroDatos
Fuente originalarXiv cs.CL ↗
Editor jefe
Dato clave #1100 de 100 bloques se cargaron sin recálculo
Dato clave #2La memoria de la GPU no creció a lo largo de todo el flujo de 50 M de tokens
El precioterabytes de NVMe y una escritura única de la memoria

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,

ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Hands-On AI Engineering

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.

Explore Vibe Coding →Vibe Academy Platform
¿Qué te parece?
Cargando comentarios…