Routage du cache KV : Réduire le travail redondant de pré-remplissage des LLM

Le routage du cache KV est important lorsque des préfixes de requêtes répétés apparaissent fréquemment dans votre trafic LLM. Si la bonne requête arrive sur la bonne réplique, le moteur de service peut réutiliser l'état d'attention mis en cache au lieu de recalculer les mêmes jetons de pré-remplissage encore et encore.

Cela peut sembler être un détail d'infrastructure, mais cela devient rapidement un problème de produit. Les longues requêtes système, le contexte RAG, les exemples few-shot et l'historique de chat multi-tours peuvent rendre le travail de pré-remplissage coûteux. Lorsque chaque réplique recalcule le même préfixe, les équipes paient en termes de latence, de temps GPU et de planification de capacité.

ShareAI offre aux développeurs une API unique pour 150+ modèles, une visibilité sur le marché, le routage et la reprise après défaillance. Le routage du cache KV se situe une couche en dessous, à l'intérieur de l'infrastructure de service de modèles. La leçon utile pour les lecteurs de ShareAI est simple : les décisions de routage comptent à chaque couche de la pile IA, du choix du modèle jusqu'à la réplique GPU qui gère une requête répétée.

Pourquoi le routage du cache KV est important

Lors de l'inférence LLM, un modèle traite d'abord la requête d'entrée dans la phase de pré-remplissage. Il construit un cache clé-valeur, généralement appelé cache KV, afin que les jetons générés ultérieurement puissent se référer au contexte déjà traité.

La mise en cache des préfixes permet aux moteurs de service de réutiliser ce cache lorsqu'une requête ultérieure partage le même début de requête. La documentation sur la mise en cache automatique des préfixes de vLLM décrit cela comme la réutilisation du cache KV pour les préfixes partagés afin que la nouvelle requête puisse éviter le calcul pour la partie partagée. La mise en cache des préfixes de SGLang utilise une idée similaire pour partager le cache KV pour des séquences de jetons communes.

Cela est particulièrement important pour les charges de travail où de nombreuses requêtes commencent de la même manière : agents de support avec une longue requête système, applications RAG utilisant des morceaux de documentation répétés, agents de codage avec des instructions de dépôt ou produits de chat qui conservent l'historique des conversations entre les tours.

Où le Round-Robin échoue

La mise en cache des préfixes est plus simple sur une seule réplique. Le même processus voit le préfixe répété et peut réutiliser son cache si la mémoire est disponible. Le problème apparaît lorsque le service s'étend horizontalement.

Avec un répartiteur de charge round-robin standard, la première requête peut chauffer le cache sur la réplique A, tandis que la deuxième requête avec le même préfixe arrive sur la réplique B. La réplique B n'a pas cet état mis en cache, donc elle recalcule le même travail de pré-remplissage. La troisième requête peut aller à la réplique C et manquer à nouveau.

À mesure que le nombre de répliques augmente, un équilibrage de charge naïf peut répartir les requêtes liées sur davantage de machines. La flotte de service de modèles peut sembler équilibrée, mais le taux de réussite du cache des préfixes diminue. C'est l'écart que le routage du cache KV tente de combler.

Trois niveaux pratiques de routage

1. Affinité de session

L'affinité de session dirige le trafic provenant du même utilisateur, espace de travail, locataire ou conversation vers la même réplique. C'est l'approche la plus simple pour commencer avec un chat multi-tours, car les invites de suivi partagent souvent le contexte précédent.

Le compromis est que l'identité de l'utilisateur n'est pas toujours la même que la similarité des invites. Deux utilisateurs peuvent partager la même longue invite système et être tout de même dirigés vers des répliques différentes. L'affinité de session peut également être perturbée lorsque des répliques sont ajoutées ou supprimées.

2. Routage par hachage de préfixe

Le routage par hachage de préfixe utilise l'invite elle-même comme clé de routage. Le routeur hache le début stable de l'invite et envoie les préfixes correspondants à la même réplique.

Cela fonctionne mieux lorsque des invites système répétées, des exemples few-shot ou un contexte récupéré partagé comptent davantage que l'identité de l'utilisateur. La partie difficile est de choisir la limite du préfixe. Si le hachage inclut un horodatage, un ID de requête ou un champ spécifique à l'utilisateur, la clé de routage se fragmente et la réutilisation du cache s'effondre.

3. Routage conscient des événements de cache

L'approche la plus avancée suit quels blocs de cache sont résidents sur quelle réplique, puis dirige chaque requête vers la réplique avec le meilleur chevauchement de cache tout en tenant compte de la charge. Le projet de routeur llm-d décrit un sélecteur de point de terminaison qui prend en compte la localité du cache KV, la charge actuelle et la priorité lors du choix de l'endroit où une requête doit aller.

C'est plus complexe, mais c'est la bonne direction pour des flottes à haut débit où les manques de cache sont mesurés, coûteux et fréquents.

Quand l'éviter

Le routage de cache KV ne vaut pas automatiquement la complexité. Il est peu adapté lorsque les invites sont courtes, principalement uniques ou traitées par lots avec peu de structure répétée.

La synthèse de documents, la génération créative, l'extraction ponctuelle et de nombreux travaux par lots asynchrones peuvent ne pas avoir suffisamment de chevauchement de préfixe partagé pour justifier un routage conscient du cache. Dans ces cas, un équilibrage de charge simple peut être plus clair.

Le test pratique est la mesure : taux de cache hit, temps jusqu'au premier jeton, débit, profondeur de la file d'attente, pression sur la mémoire GPU et coût par tâche terminée. Si le routage conscient du cache ne modifie pas ces chiffres, corrigez d'abord la structure de l'invite.

Comment cela s'intègre avec ShareAI

ShareAI est un marché et une API d'IA, pas le répartiteur de charge de service de modèles à l'intérieur de votre cluster GPU. Les développeurs utilisent ShareAI pour accéder à de nombreux modèles via une API, comparer les signaux du marché, router les requêtes, gérer l'utilisation et basculer en cas de dégradation d'une route.

Cela rend toujours le routage du cache KV pertinent. Si vous gérez votre propre pile d'inférence, cela vous aide à poser de meilleures questions sur l'infrastructure. Si vous consommez des modèles hébergés, cela vous aide à évaluer pourquoi deux routes avec des noms de modèles similaires peuvent se comporter différemment sous des charges de travail réelles.

Pour les constructeurs, cela se connecte également à la tarification. Une application avec des invites longues, un contexte RAG répété ou des boucles d'agents peut créer une utilisation de l'IA très inégale. ShareAI Builder permet aux propriétaires d'applications de router le trafic d'inférence IA via ShareAI, de définir une marge ou une surtaxe, de faire payer les clients à ShareAI pour l'utilisation routée et de recevoir des paiements mensuels basés sur l'utilisation générée. L'application elle-même reste construite en dehors de ShareAI.

Pour la sélection de modèles et l'évaluation des routes, commencez par le marché des modèles ShareAI. Pour les bases de l'implémentation, utilisez le Référence API ShareAI.

Liste de contrôle pour le routage du cache KV

• Placez d'abord le contenu stable de l'invite : invite système, règles d'outils, exemples et contexte répété.
• Déplacez les champs dynamiques plus tard : horodatages, identifiants de requêtes, faits spécifiques à l'utilisateur et instructions ponctuelles.
• Mesurez le taux de cache hit avant et après les modifications de routage.
• Surveillez ensemble le temps jusqu'au premier jeton, le débit, la profondeur de la file d'attente et la pression sur la VRAM.
• Commencez par le routage par hachage de préfixe avant de construire un routage conscient des événements de cache.
• Divisez les règles de routage par charge de travail au lieu d'imposer une politique globale unique.
• Gardez les coûts et la latence visibles au niveau de l'application, et pas seulement à l'intérieur du cluster d'inférence.

FAQ

Qu'est-ce que le routage du cache KV ?

Le routage du cache KV est une stratégie de routage qui envoie les requêtes avec des préfixes de prompt répétés vers des répliques susceptibles de contenir déjà le cache KV correspondant. L'objectif est de réduire les calculs redondants de pré-remplissage.

En quoi le routage du cache KV est-il différent de la mise en cache des préfixes ?

La mise en cache des préfixes est la capacité du moteur de service de modèle à réutiliser l'état mis en cache pour des préfixes de prompt partagés. Le routage du cache KV est la stratégie de placement du trafic qui aide les requêtes correspondantes à arriver là où cet état mis en cache existe déjà.

Pourquoi le routage en round-robin nuit-il à la mise en cache des préfixes ?

Le routage en round-robin répartit les requêtes entre les répliques sans savoir quelle réplique possède quel préfixe mis en cache. Un prompt répété peut manquer le cache simplement parce qu'il arrive sur une réplique différente.

Quels types de charges de travail bénéficient le plus du routage du cache KV ?

Les discussions multi-tours, RAG, agents de codage, agents de support, prompts few-shot et applications avec de longs prompts système partagés sont les meilleurs candidats car ils réutilisent des préfixes de prompt substantiels.

Quand une équipe devrait-elle éviter le routage du cache KV ?

Évitez-le lorsque les prompts sont courts, principalement uniques ou orientés par lots avec peu de structure répétée. Dans ces cas, la complexité du routage peut apporter peu de valeur.

vLLM et SGLang prennent-ils en charge la mise en cache des préfixes ?

Oui. vLLM documente la mise en cache automatique des préfixes, et SGLang documente la mise en cache des préfixes pour un cache KV partagé à travers des séquences de tokens communes. Le moteur de service a encore besoin d'aide pour le routage lorsque plusieurs répliques sont impliquées.

Le routage du cache KV est-il identique à la mise en cache sémantique ?

Non. Le routage du cache KV fonctionne avec une réutilisation exacte ou quasi-structurale des préfixes dans le service d'inférence. La mise en cache sémantique stocke et réutilise des réponses ou des résultats intermédiaires basés sur le sens, généralement avec des embeddings ou des seuils de similarité.

ShareAI remplace-t-il un répartiteur de charge conscient du cache KV ?

Non. ShareAI est le marché de l'IA et la couche API pour l'accès aux modèles, le routage, le basculement, l'utilisation et la facturation. Le routage conscient du KV-cache est une infrastructure de service de modèles de niveau inférieur pour les équipes exploitant des répliques d'inférence.

Comment les Builders doivent-ils envisager le routage du cache KV ?

Les Builders doivent considérer le comportement du cache comme un facteur de coût dans les applications fortement axées sur l'IA. Si leur application a une utilisation irrégulière, ShareAI peut aider à router et monétiser ce trafic IA tout en laissant l'application construite et détenue en dehors de ShareAI.

Que doivent mesurer les équipes avant de modifier le routage ?

Mesurez le taux de réussite du cache, le temps jusqu'au premier jeton, le débit, la profondeur de la file d'attente, la pression sur la VRAM, le coût par tâche et la qualité de sortie. Les modifications de routage doivent améliorer la charge de travail, pas seulement le tableau de bord.

Le routage du cache KV peut-il réduire les coûts des API IA ?

Il peut réduire les coûts d'infrastructure pour les équipes qui servent elles-mêmes des modèles, car un travail de pré-remplissage moins redondant peut améliorer l'efficacité du GPU. Pour les API hébergées, l'effet dépend de la manière dont le fournisseur expose ces économies en termes de prix ou de performance.