Las cuatro caches clave para servir modelos LLM y reducir latencia

Introducción

A medida que las aplicaciones con modelos grandes de lenguaje (LLM) se vuelven más complejas, el costo y la latencia de la inferencia toman protagonismo. Una sola petición puede combinar instrucciones del sistema, historial de conversación, documentos recuperados, definiciones de herramientas y la entrada del usuario; en conjunto esto puede sumar miles o incluso millones de tokens. Volver a procesar la misma información una y otra vez consume tiempo y cómputo. El caching evita ese trabajo repetido, pero “cachear” en el mundo de LLMs no es un único método: hay varias técnicas que actúan en distintas capas y resuelven problemas diferentes. Aquí revisamos las cuatro caches principales y cómo se integran.

KV cache: recordar lo que el modelo ya procesó

El KV cache es la pieza fundamental de cualquier inferencia autoregresiva moderna. Los LLMs generan salida token por token; en cada paso, el mecanismo de atención calcula cómo el nuevo token debe relacionarse con los tokens previos. Para eso el modelo produce tensores Key (K) y Value (V) por los tokens procesados. Esos tensores sirven para que tokens futuros “atiendan” al contexto ya visto.

Sin una cache, el modelo tendría que volver a recomputar las representaciones K/V de todo el contexto en cada paso, lo que se vuelve rápidamente ineficiente a medida que la secuencia crece. El KV cache almacena esas representaciones en memoria (por ejemplo GPU) durante la generación y las reutiliza para los pasos de decodificación siguientes. El patrón es sencillo: calcular K/V una vez, guardarlos, y volver a usarlos mientras se generan tokens posteriores.

Durante la fase de prefill (cuando el modelo procesa el prompt inicial), se generan y almacenan los estados K/V para los tokens del prompt. Al iniciar la generación de la respuesta, esos estados cacheados permiten que el sistema sólo compute los K/V de los tokens nuevos y los concatene al estado existente. Esto reduce dramáticamente la carga computacional por token durante la decodificación.

Limitación: el KV cache suele estar asociado a una secuencia activa o a una petición concreta. Una vez que esa petición termina, el estado KV no es automáticamente reutilizable por una petición no relacionada, lo que motiva técnicas adicionales.

Prefix cache: reutilizar el comienzo de otra petición

En muchas aplicaciones la porción inicial de la entrada —system prompt, políticas, instrucciones, definiciones de herramientas— es compartida entre múltiples peticiones. Sin una estrategia adicional, el modelo volverá a procesar ese mismo prefijo cada vez. La prefix cache permite reusar los estados K/V correspondientes a esa porción común.

Una implementación común divide el prompt en bloques de tamaño fijo (por ejemplo, bloques de tokens). Cada bloque completo se asocia a una porción del KV cache y a un hash derivado de su contenido y su posición dentro del prefijo. Cuando llega una nueva petición, el sistema busca hashes coincidentes para identificar qué bloques ya existen en cache sin necesidad de comparar prompts carácter por carácter.

Así, si la nueva petición comparte los primeros dos bloques con una petición anterior, esos bloques generan CACHE HIT y se reutilizan sus estados K/V; sólo la parte no cacheada necesita pasar por el modelo. Esto es especialmente útil en entornos empresariales donde los mensajes del sistema y las instrucciones son estables: se evita repetir trabajo en cada conversación.

Prompt cache: dejar que el proveedor cachee el prompt

El prompt cache suele referirse a un mecanismo a nivel del proveedor de inferencia (o de un gateway) que almacena resultados intermedios o finales asociados a prompts completos o a entradas preprocesadas. En lugar de recalcular toda la prefill o incluso la inferencia completa, el proveedor puede devolver rápidamente una respuesta precalculada si detecta una coincidencia exacta o suficiente del prompt.

Esta capa es conveniente cuando las aplicaciones envían prompts repetidos o altamente similares. Sin embargo, implica decisiones operativas y de cumplimiento: usar cache del proveedor puede levantar preguntas sobre privacidad y residencia de datos, algo relevante para organizaciones en América Latina que deben cumplir requisitos regulatorios locales.

En la práctica, prompt caching puede acelerar mucho respuestas repetidas, pero requiere gestionar caducidad, control de versiones del prompt (si cambia la plantilla) y políticas de seguridad para no exponer datos sensibles a través del cache.

Semantic cache: cuando ni siquiera necesitas invocar al LLM

La semantic cache opera a un nivel más alto: en vez de guardar representaciones de tokens o prompts literales, almacena representaciones semánticas (por ejemplo, embeddings) de consultas y sus respuestas. Cuando llega una nueva consulta, se compara su embedding con los almacenados; si hay una respuesta existente suficientemente similar, el sistema puede devolver esa respuesta sin llamar al LLM.

Esta estrategia es ideal para escenarios con preguntas frecuentes, respuestas estandarizadas o contenido que no cambia con frecuencia. Reduce costos y latencia al evitar peticiones de inferencia innecesarias.

Riesgos y consideraciones: la correspondencia semántica no garantiza la misma exactitud contextual; es necesario definir umbrales de similitud y mecanismos para detectar cuándo es obligatorio invocar al modelo (por ejemplo, para información que debe estar actualizada). Además, hay que controlar la vigencia de las respuestas para evitar servir información obsoleta.

Cómo encajan las cuatro caches

Piensen en estas caches como capas complementarias:

• KV cache: capa más fina y obligatoria durante la decodificación token a token. Actúa dentro de la vida de una petición activa.
• Prefix cache: reutiliza partes compartidas entre peticiones en forma de bloques KV, reduciendo trabajo antes de generar tokens nuevos.
• Prompt cache: normalmente operada por el proveedor o por un gateway, devuelve resultados para prompts completos idénticos o permitidos por política.
• Semantic cache: capa más gruesa y orientada a la aplicación; evita llamadas al LLM cuando la intención y la respuesta ya existen en la base semántica.

Combinadas, estas técnicas reducen tanto la latencia como el gasto de cómputo: la semantic cache evita llamadas enteras; el prompt cache evita recomputar prompts completos; la prefix cache recicla prefijos comunes; y el KV cache hace eficiente la decodificación token por token.

Qué exactamente se está cacheando

• En KV cache: tensores Key/Value generados por capas del transformer para tokens procesados.
• En prefix cache: bloques de tokens asociados a porciones del KV cache, indexados por hash.
• En prompt cache: prompts preprocesados o respuestas completas asociadas a prompts idénticos o autorizados.
• En semantic cache: embeddings o vectores semánticos de consultas y la respuesta asociada.

Ejemplo práctico (escenario empresarial)

Imaginen un asistente virtual para atención al cliente en un banco latinoamericano. El system prompt contiene políticas de cumplimiento, definiciones de herramientas y mensajes regulatorios compartidos entre todas las conversaciones. Con prefix caching se pueden reutilizar los K/V asociados a esas políticas en cada sesión. En preguntas frecuentes (“¿cómo cancelar mi tarjeta?”), la semantic cache puede devolver una respuesta ya validada sin invocar al LLM. Para prompts internos repetidos, el prompt cache del proveedor puede retornar resultados precalculados. Durante la generación de respuestas largas, el KV cache acelera la decodificación token a token.

Modelo mental para recordar

Visualicen las caches como capas de granularidad: desde la más fina (KV) que vive durante la generación, hasta la más gruesa (semantic) que vive en la capa de aplicación. A mayor nivel, menos llamada al LLM; a menor nivel, menos recomputo dentro de la misma llamada.

Conclusión

El caching en inferencia de LLM es una familia de técnicas, no una sola solución. Implementarlas de forma coordinada permite reducir latencia y costos, mejorar la experiencia de usuario y escalar aplicaciones en producción. Para equipos y decisores en América Latina, la elección e integración de estas capas también debe considerar requisitos de privacidad, residencia de datos y políticas internas al decidir si usar caches locales, de proveedor o híbridos.

Adoptar una estrategia de caches bien pensada es una de las palancas más efectivas para llevar modelos LLM de pruebas a sistemas productivos y eficientes.