Enrutamiento de caché KV: Reducir el trabajo redundante de prellenado de LLM

El enrutamiento de caché KV importa cuando los prefijos de solicitud repetidos siguen apareciendo en el tráfico de tu LLM. Si la solicitud correcta llega a la réplica correcta, el motor de servicio puede reutilizar el estado de atención en caché en lugar de volver a calcular los mismos tokens de pre-relleno una y otra vez.

Eso suena como un detalle de infraestructura, pero rápidamente se convierte en un problema de producto. Los prompts largos del sistema, el contexto RAG, los ejemplos de pocos disparos y el historial de chat de múltiples turnos pueden hacer que el trabajo de pre-relleno sea costoso. Cuando cada réplica vuelve a calcular el mismo prefijo, los equipos pagan en latencia, tiempo de GPU y planificación de capacidad.

ShareAI ofrece a los desarrolladores una API para más de 150 modelos, visibilidad en el mercado, enrutamiento y conmutación por error. El enrutamiento de caché KV se encuentra una capa más abajo, dentro de la infraestructura de servicio de modelos. La conclusión útil para los lectores de ShareAI es simple: las decisiones de enrutamiento importan en cada capa de la pila de IA, desde la elección del modelo hasta qué réplica de GPU maneja un prompt repetido.

Por qué importa el enrutamiento de caché KV

Durante la inferencia de LLM, un modelo primero procesa el prompt de entrada en la fase de pre-relleno. Construye una caché de clave-valor, generalmente llamada caché KV, para que los tokens generados posteriormente puedan atender al contexto ya procesado.

El almacenamiento en caché de prefijos permite que los motores de servicio reutilicen esa caché cuando una solicitud posterior comparte el mismo comienzo del prompt. La documentación de almacenamiento en caché de prefijos automático de vLLM describe esto como reutilizar la caché KV para prefijos compartidos, de modo que la nueva solicitud pueda omitir el cálculo de la parte compartida. El almacenamiento en caché de prefijos de SGLang utiliza una idea relacionada para compartir la caché KV para secuencias comunes de tokens.

Esto es especialmente importante para cargas de trabajo donde muchas solicitudes comienzan de la misma manera: agentes de soporte con un prompt de sistema grande, aplicaciones RAG que usan fragmentos de documentación repetidos, agentes de codificación con instrucciones de repositorio o productos de chat que llevan el historial de conversación entre turnos.

Donde falla el balanceo de carga Round-Robin

El almacenamiento en caché de prefijos es más fácil en una sola réplica. El mismo proceso ve el prefijo repetido y puede reutilizar su caché si hay memoria disponible. El problema aparece cuando el servicio escala horizontalmente.

Con un balanceador de carga round-robin estándar, la primera solicitud puede calentar la caché en la réplica A, mientras que la segunda solicitud con el mismo prefijo llega a la réplica B. La réplica B no tiene ese estado en caché, por lo que vuelve a calcular el mismo trabajo de pre-relleno. La tercera solicitud puede ir a la réplica C y fallar nuevamente.

A medida que aumenta el número de réplicas, un balanceo de carga ingenuo puede distribuir solicitudes relacionadas entre más máquinas. La flota de servicio de modelos puede parecer equilibrada, pero la tasa de aciertos de la caché de prefijos disminuye. Esa es la brecha que el enrutamiento de caché KV intenta cerrar.

Tres niveles prácticos de enrutamiento

1. Afinidad de sesión

La afinidad de sesión dirige el tráfico del mismo usuario, espacio de trabajo, inquilino o conversación a la misma réplica. Es el lugar más sencillo para comenzar con chats de múltiples turnos porque las indicaciones de seguimiento suelen compartir el contexto previo.

La desventaja es que la identidad del usuario no siempre es igual a la similitud de las indicaciones. Dos usuarios pueden compartir la misma indicación larga del sistema y aún así ser dirigidos a réplicas diferentes. La afinidad de sesión también puede verse afectada cuando se agregan o eliminan réplicas.

2. Enrutamiento por hash de prefijo

El enrutamiento por hash de prefijo utiliza la propia indicación como clave de enrutamiento. El enrutador genera un hash del inicio estable de la indicación y envía prefijos coincidentes a la misma réplica.

Esto funciona mejor cuando las indicaciones repetidas del sistema, los ejemplos de pocos disparos o el contexto recuperado compartido son más importantes que la identidad del usuario. La parte difícil es elegir el límite del prefijo. Si el hash incluye una marca de tiempo, ID de solicitud o campo específico del usuario, la clave de enrutamiento se fragmenta y el reutilizo de la caché se desmorona.

3. Enrutamiento consciente de eventos de caché

El enfoque más avanzado rastrea qué bloques de caché están presentes en qué réplica, luego dirige cada solicitud a la réplica con el mejor solapamiento de caché mientras aún considera la carga. El proyecto llm-d router describe un selector de puntos finales que considera la localidad de la caché KV, la carga actual y la prioridad al elegir dónde debe ir una solicitud.

Esto es más complejo, pero es la dirección correcta para flotas de alto rendimiento donde los fallos de caché son medidos, costosos y frecuentes.

Cuándo omitirlo

El enrutamiento de caché KV no vale automáticamente la complejidad. Es una opción débil cuando las indicaciones son cortas, mayormente únicas o procesadas en lotes con poca estructura repetida.

La resumición de documentos, generación creativa, extracción única y muchos trabajos por lotes asíncronos pueden no tener suficiente solapamiento de prefijos compartidos para justificar el enrutamiento consciente de la caché. En esos casos, el balanceo de carga simple puede ser más limpio.

La prueba práctica es la medición: tasa de aciertos de caché, tiempo hasta el primer token, rendimiento, profundidad de cola, presión de memoria GPU y costo por tarea completada. Si el enrutamiento consciente de caché no cambia esos números, corrige primero la estructura del prompt.

Cómo Esto Encaja Con ShareAI

ShareAI es un mercado y API de IA, no el balanceador de carga de modelos dentro de tu clúster de GPU. Los desarrolladores usan ShareAI para acceder a muchos modelos a través de una API, comparar señales del mercado, enrutar solicitudes, gestionar el uso y realizar failover cuando una ruta se degrada.

Eso aún hace que el enrutamiento de caché KV sea relevante. Si operas tu propia pila de inferencia, te ayuda a hacer mejores preguntas sobre infraestructura. Si consumes modelos alojados, te ayuda a evaluar por qué dos rutas con nombres de modelos similares pueden comportarse de manera diferente bajo cargas de trabajo reales.

Para los Constructores, esto también se conecta con los precios. Una aplicación con prompts largos, contexto RAG repetido o bucles de agentes puede crear un uso de IA muy desigual. ShareAI Builder permite a los propietarios de aplicaciones enrutar el tráfico de inferencia de IA a través de ShareAI, establecer un margen o recargo, hacer que los clientes paguen a ShareAI por el uso enrutado y recibir pagos mensuales basados en el uso generado. La aplicación en sí permanece construida fuera de ShareAI.

Para la selección de modelos y evaluación de rutas, comienza con el mercado de modelos de ShareAI. Para los conceptos básicos de implementación, utiliza el Referencia de API de ShareAI.

Lista de Verificación de Enrutamiento de Caché KV

• Coloca primero el contenido estable del prompt: prompt del sistema, reglas de herramientas, ejemplos y contexto repetido.
• Mueve los campos dinámicos después: marcas de tiempo, IDs de solicitudes, datos específicos del usuario e instrucciones puntuales.
• Mide la tasa de aciertos de caché antes y después de los cambios de enrutamiento.
• Observa el tiempo hasta el primer token, el rendimiento, la profundidad de cola y la presión de VRAM juntos.
• Comienza con el enrutamiento por hash de prefijo antes de construir un enrutamiento consciente de eventos de caché.
• Divide las reglas de enrutamiento por carga de trabajo en lugar de forzar una política global.
• Mantén visibles el costo y la latencia a nivel de la aplicación, no solo dentro del clúster de inferencia.

Preguntas frecuentes

¿Qué es el enrutamiento de caché KV?

El enrutamiento de caché KV es una estrategia de enrutamiento que envía solicitudes con prefijos de indicaciones repetidos a réplicas que probablemente ya tengan la caché KV correspondiente. El objetivo es reducir el cálculo redundante de pre-relleno.

¿En qué se diferencia el enrutamiento de caché KV del almacenamiento en caché de prefijos?

El almacenamiento en caché de prefijos es la capacidad del motor de servicio del modelo para reutilizar el estado en caché para prefijos de indicaciones compartidos. El enrutamiento de caché KV es la estrategia de colocación de tráfico que ayuda a que las solicitudes coincidentes lleguen donde ese estado en caché ya existe.

¿Por qué el enrutamiento round-robin perjudica el almacenamiento en caché de prefijos?

El enrutamiento round-robin distribuye solicitudes entre réplicas sin saber qué réplica tiene qué prefijo en caché. Una indicación repetida puede perder la caché simplemente porque llega a una réplica diferente.

¿Qué cargas de trabajo se benefician más del enrutamiento de caché KV?

Los chats de múltiples turnos, RAG, agentes de codificación, agentes de soporte, indicaciones de pocos ejemplos y aplicaciones con indicaciones de sistema largas y compartidas son los candidatos más fuertes porque reutilizan prefijos de indicaciones sustanciales.

¿Cuándo debería un equipo omitir el enrutamiento de caché KV?

Omítalo cuando las indicaciones sean cortas, mayormente únicas o estén orientadas a lotes con poca estructura repetida. En esos casos, la complejidad del enrutamiento puede aportar poco valor.

¿vLLM y SGLang admiten el almacenamiento en caché de prefijos?

Sí. vLLM documenta el almacenamiento en caché de prefijos automático, y SGLang documenta el almacenamiento en caché de prefijos para la caché KV compartida en secuencias de tokens comunes. El motor de servicio aún necesita ayuda de enrutamiento cuando se involucran múltiples réplicas.

¿Es el enrutamiento de caché KV lo mismo que el almacenamiento en caché semántico?

No. El enrutamiento de caché KV funciona con la reutilización exacta o casi estructural de prefijos dentro del servicio de inferencia. El almacenamiento en caché semántico almacena y reutiliza respuestas o resultados intermedios basados en el significado, generalmente con embeddings o umbrales de similitud.

¿ShareAI reemplaza a un balanceador de carga consciente de caché KV?

No. ShareAI es el mercado de IA y la capa de API para acceso a modelos, enrutamiento, conmutación por error, uso y facturación. El enrutamiento consciente de KV-cache es una infraestructura de servicio de modelos de bajo nivel para equipos que operan réplicas de inferencia.

¿Cómo deberían los Constructores pensar sobre el enrutamiento de caché KV?

Los Constructores deberían tratar el comportamiento de la caché como un factor de costo dentro de las aplicaciones intensivas en IA. Si su aplicación tiene un uso desigual, ShareAI puede ayudar a enrutar y monetizar ese tráfico de IA mientras la aplicación permanece construida y propiedad fuera de ShareAI.

¿Qué deberían medir los equipos antes de cambiar el enrutamiento?

Medir la tasa de aciertos de la caché, el tiempo hasta el primer token, el rendimiento, la profundidad de la cola, la presión de VRAM, el costo por tarea y la calidad de salida. Los cambios de enrutamiento deberían mejorar la carga de trabajo, no solo el panel de control.

¿Puede el enrutamiento de caché KV reducir los costos de API de IA?

Puede reducir el costo de infraestructura para los equipos que sirven modelos por sí mismos porque un trabajo de prefijo menos redundante puede mejorar la eficiencia de la GPU. Para las API alojadas, el efecto depende de si el proveedor expone esos ahorros en precio o rendimiento.