La compression du cache KV est une décision d'infrastructure, pas un débat sur les modèles
La compression du cache KV n'est plus un débat sur la qualité des modèles. C'est une décision d'achat d'infrastructure avec un problème mathématique en annexe.
Je le dis sans détour parce que trop d'équipes traitent encore la mémoire des LLM à long contexte comme une course de benchmarks: TurboQuant contre OSCAR contre EpiCache, choisir un gagnant, passer à autre chose. En pratique, ce n'est pas ainsi que les déploiements échouent. Ils échouent parce qu'une équipe optimise la largeur de bits, une autre la portabilité, et une troisième découvre trop tard que l'historique d'une conversation multi-tours est un problème différent d'une seule invite de 128K. Selon le résumé du 18 juin de MarkTechPost, les trois approches résolvent des goulots d'étranglement adjacents, pas le même.
La compression du cache KV devient douloureuse quand la HBM, pas les FLOPs, est votre plafond
Les calculs mémoire sont la partie que les opérateurs ne peuvent pas ignorer. L'exemple source utilise Llama-3.1-70B en BF16: environ 0,31 Mo de cache KV par jeton, soit près de 40 Go à 128K jetons, et plus de 300 Go à 1M jetons. C'est le point où le cache peut dépasser les poids du modèle eux-mêmes. Si vous servez des requêtes à long contexte avec concurrence, chaque jeton décodé traîne ce cache à travers la mémoire à haute bande passante.
Ce changement compte plus qu'un point de classement supplémentaire. Une fois que le décodage devient limité par la bande passante, votre courbe de coût change. Vous ne demandez plus « Ce modèle peut-il bien répondre? », mais « Combien de sessions puis-je maintenir actives avant que le trafic mémoire ne détruise la latence? »
Dans un test de charge client que j'ai mené le mois dernier, le choix du modèle n'était pas la principale contrainte. La réutilisation de préfixe semblait excellente isolément, mais une fois le nombre de sessions concurrentes monté, la latence de queue a bondi parce que le mouvement mémoire, pas le calcul, était le facteur limitant. C'est pourquoi le travail de référence à 2 bits de KIVI compte encore en 2026: il a cadré la quantification du cache KV comme un problème de systèmes d'inférence, pas juste une astuce de compression.
TurboQuant est le choix de portabilité, pas le gagnant universel
TurboQuant est impressionnant pour une raison. Google Research et NYU ont construit une approche indépendante des données qui attaque les canaux aberrants sans calibration. D'abord, il fait tourner aléatoirement les vecteurs pour que les coordonnées se comportent plus comme des variables gaussiennes indépendantes. Puis il applique un quantificateur scalaire précalculé et une transformée QJL à 1 bit sur le résidu. La prétention théorique est forte: la distorsion reste dans un facteur constant proche de la borne inférieure.
C'est l'outil adapté quand la portabilité des modèles vous importe et que vous ne pouvez pas vous permettre une calibration personnalisée pour chaque cible de serving. Le point de fonctionnement rapporté est la plage de 3 à 4 bits, où la qualité reste quasi sans perte sur les charges de travail que l'article met en avant. Cela rend TurboQuant attractif pour les équipes exploitant des flottes mixtes ou expérimentant sur plusieurs architectures.
Mais voici la partie controverse: les gens répètent la mauvaise promesse. La revendication la plus bruyante autour de TurboQuant est la ligne « attention 8x plus rapide sur H100 » du billet de blog Google Research sur TurboQuant, pourtant l'article source note correctement que cela renvoie à un microbenchmark étroit, pas au serving de bout en bout. J'ai déjà vu ce schéma avec les noyaux d'inférence: une victoire à l'intérieur d'une étape devient un argument d'achat pour toute la pile. C'est ainsi que les équipes s'achètent de la déception.
OSCAR compte parce que quelqu'un a effectivement livré les parties brouillonnes
Si votre cible est une compression du cache KV en INT2 déployable, OSCAR est l'histoire pratique du moment. Le système de Together AI ne se contente pas de proposer une rotation sensible à l'attention; il empaquette autour le paging à précision mixte, les noyaux Triton et l'intégration SGLang. C'est important parce que les gains en production viennent généralement du package, pas de l'article.
Les détails comptent. OSCAR garde les jetons de sink et récents en BF16 tout en compressant les jetons historiques en INT2, ne laissant qu'environ 0,24 % des jetons non compressés à 128K de contexte selon le résumé. Il livre aussi des rotations précalculées pour les modèles supportés, ce qui élimine une étape de déploiement pénible. Le gain rapporté est substantiel: jusqu'à 7,83x de débit au niveau du job, environ 8x de réduction mémoire du cache KV à 100K de contexte, et jusqu'à 3x de décodage plus rapide sur les configurations testées.
C'est pourquoi je pense qu'OSCAR remporte actuellement l'argument de déployabilité à l'extrême bas-bit. Non pas parce que l'idée est plus élégante. Parce que quelqu'un a comblé l'écart entre la théorie de la quantification et la réalité du serving.
Même l'argument fort pour un gagnant en tête-à-tête s'effondre
Un contre-argument juste est que les entreprises ont besoin d'une réponse simple. Si une méthode bat une autre sur la qualité du benchmark et le débit, choisir le leader réduit la complexité. Il y a une logique là-dedans. Chaque chemin d'inférence supplémentaire ajoute des tests, une logique de retour en arrière, du travail d'observabilité et une charge de support. Se standardiser sur une méthode est souvent le choix d'exploitation sage.
Je suis d'accord avec cet instinct. Je ne pense juste pas que les preuves actuelles soutiennent un gagnant universel.
La comparaison rapportée par OSCAR suggère que TurboQuant chute fortement à des budgets similaires, mais cette lecture vient avec des avertissements que l'article source a eu raison de signaler: la comparaison s'exécute dans le cadre d'OSCAR, quantifie toutes les couches, utilise une seule graine aléatoire et évalue TurboQuant en dessous de son régime prévu de 3 à 4 bits. Ce n'est pas suffisant pour un verdict catégorique. Inversement, l'histoire de portabilité de TurboQuant ne répond pas à la question de savoir si vous pouvez obtenir un comportement de production stable en INT2 sur votre pile exacte la semaine prochaine.
Donc la vraie décision est plus étroite et plus ennuyeuse:
- Choisissez TurboQuant quand le déploiement indépendant du modèle et un comportement quasi sans perte à 3-4 bits comptent plus que la compression absolue.
- Choisissez OSCAR quand vous avez besoin d'INT2 sur modèles supportés, d'intégration en production et d'économies mémoire immédiates à long contexte.
- Ne forcez aucun des deux à résoudre la gestion mémoire multi-tours, car ce n'est pas leur rôle.
EpiCache est le rappel que les longues invites et les longues conversations sont des problèmes de systèmes différents
C'est la partie que beaucoup d'équipes manquent. Une seule invite de 128K et une conversation de deux heures ne sont pas la même charge de travail, même si les deux ressemblent à du « long contexte » sur une diapositive.
EpiCache d'Apple s'attaque directement au cas conversationnel. Au lieu de se demander seulement comment stocker précisément les jetons, il se demande quelle histoire garder active, comment la segmenter en épisodes cohérents, et comment récupérer le bon épisode pendant l'inférence. Le framework ajoute le pré-remplissage par blocs, le clustering épisodique, la récupération sur épisodes et le budgetage mémoire par couche.
Opérationnellement, c'est un axe différent de la quantification du cache KV. C'est de la gestion de cache, pas seulement du rétrécissement de cache. Les gains rapportés dans le matériel source sont exactement pourquoi cette distinction compte: jusqu'à 40 % de précision supérieure aux baselines d'éviction, une précision quasi équivalente au cache complet à une compression de 4 à 6x, jusqu'à 3,5x de pic mémoire inférieur, et environ 2,4x de latence inférieure sur les benchmarks de conversation évalués.
Ma réfutation à l'état d'esprit « choisissez juste un gagnant » est simple: EpiCache se compose avec TurboQuant ou OSCAR. Donc si votre charge de travail est un copilote de support, un assistant de recherche ou un agent interne avec un historique de chat profond, la meilleure pile peut être une méthode pour la rétention plus une autre pour la précision de stockage. Ce n'est pas de l'indécision. C'est du design de systèmes.
La bonne question est de savoir quelle contrainte vous coûte de l'argent en premier
Quand j'entre dans une revue d'inférence, je ne commence pas par les noms d'articles. Je commence par trois questions.
Premièrement, la flotte de serving est-elle limitée par la mémoire au moment du décodage, ou sommes-nous encore limités par le calcul? Deuxièmement, avons-nous besoin de portabilité entre modèles, ou pouvons-nous optimiser fortement pour une pile supportée? Troisièmement, la charge de travail est-elle dominée par une seule longue invite ou par de nombreux tours conversationnels?
Ces questions réduisent généralement le champ vite. Si la portabilité domine, TurboQuant a l'argument plus clair. Si votre équipe est déjà sur une pile qu'OSCAR supporte et que vous avez besoin d'économies INT2 agressives maintenant, OSCAR semble plus fort. Si les sessions de support ou la mémoire de l'agent sont le point douloureux, EpiCache a sa place dans le design même si vous quantifiez aussi.
C'est pourquoi je reviens toujours à la même thèse contrarienne: la compression du cache KV n'est pas vraiment une course. C'est un problème de design de pile qui a été marketé comme un combat de catch.
Lectures connexes
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation