KVBoost reutiliza la cache KV sin prefijo compartido

El prefill de un LLM vuelve a calcular los tensores clave-valor (KV) en cada petición, y los sistemas de prefix caching que hoy mitigan ese coste tienen una condición incómoda: solo aciertan si dos prompts comparten un prefijo contiguo desde el primer token. Si el fragmento repetido aparece en mitad del contexto, no hay reutilización posible. KVBoost, publicado en arXiv el 25 de agosto, propone reutilizar la cache KV por chunks sin importar en qué posición esté el contenido compartido.

El escenario es más habitual de lo que sugiere el planteamiento teórico. En un sistema RAG los mismos documentos se recuperan una y otra vez, pero rara vez en el mismo orden. En un asistente de código, los mismos ficheros aparecen intercalados con conversación distinta. En ambos casos el contenido repetido está ahí, solo que no al principio.

Dos hashes y dos reparaciones

La pieza central es un esquema de claves con doble hash que separa la identidad posicional (prefix hash) de la identidad de contenido (content hash). Con eso, el sistema admite coincidencias exactas y también aproximadas, algo que un caché de prefijos clásico no puede ofrecer.

El precio de trocear el contexto son los errores de frontera en la atención. Un chunk cacheado de forma independiente se calculó sin ver a sus vecinos, así que los tokens del borde arrastran una atención que no corresponde al contexto real. KVBoost plantea dos estrategias de reparación: SelectiveRecompute, que vuelve a codificar las regiones de borde, y CacheBlendRecompute, que hace una pasada de sondeo, localiza los tokens con mayor desviación y recalcula solo esos. El nombre remite a CacheBlend, la línea de trabajo previa sobre fusión de caches KV parciales.

Alrededor de eso, el sistema añade tres mecanismos más: cuantización asimétrica del KV (int8 e int4), división adaptativa de las fronteras de chunk y desalojo ponderado por importancia bajo un presupuesto de memoria fijo. Es una combinación pragmática, orientada a que la técnica sobreviva fuera del banco de pruebas.

Qué mide el paper y qué no

La evaluación se hace sobre Qwen/Qwen2.5-3B con 1.000 muestras de localización de bugs, un caso de uso donde el mismo repositorio se envía una y otra vez con preguntas distintas. El resumen que publica arXiv aparece truncado y no incluye las cifras finales de latencia ni de calidad, así que cualquiera que quiera citar aceleraciones concretas tendrá que ir al PDF. Es una v1 recién anunciada, sin revisión por pares.

Hay además una limitación de alcance que conviene leer bien: KVBoost está pensado para modelos decoder compatibles con HuggingFace, es decir, para quien sirve pesos abiertos en su propia infraestructura. No es algo que se pueda activar desde fuera contra una API cerrada.

Para quién es útil

Si tu equipo sirve modelos propios, esto va directo a la lista de cosas que probar. El prefill es donde se va el tiempo hasta el primer token cuando el contexto es largo, y la restricción del prefijo contiguo deja bastante ahorro sobre la mesa.

Si trabajas contra la API de Claude, la técnica no se aplica pero la lección sí. El prompt caching de Anthropic también funciona por prefijo, con puntos de corte explícitos, y eso obliga a ordenar el prompt de lo más estable a lo más volátil: primero instrucciones y documentos fijos, después el historial, al final la pregunta del turno. Trabajos como este recuerdan que esa restricción es de implementación y no una ley física, aunque hoy siga siendo la regla con la que toca diseñar.

Nos interesa menos la cifra de aceleración que la dirección del trabajo: mover la unidad de reutilización del prefijo al chunk es la clase de optimización aburrida que acaba cambiando el coste real de servir contexto largo. Queda por ver si el coste de las pasadas de reparación se mantiene bajo control cuando el número de chunks crece.