OSCAR : Together AI open-source une quantification KV cache 2-bit qui réduit la mémoire par 8

OSCAR : Together AI open-source une quantification KV cache 2-bit qui réduit la mémoire par 8

🔎 Le goulot d'étranglement du serving LLM n'est plus le calcul, c'est la mémoire

Depuis fin 2025, le serving de modèles de langue en contexte long bute sur un mur physique. Les GPU disposent de teraflops de calcul sous-utilisés, mais manquent cruellement de mémoire pour stocker les clés et valeurs (KV cache) de l'attention sur des fenêtres de 128K, 256K ou 1M tokens.

Together AI vient de publier OSCAR, un système de quantification KV cache en 2 bits qui divise par 8 l'empreinte mémoire de ce cache, tout en maintenant une précision quasi-identique au BF16 sur les benchmarks de longue portée. Le papier est publié sur arXiv (mai 2026), et le code est ouvert.

C'est une rupture technique. Jusqu'ici, la quantification KV cache plafonnait à 4 bits (GPTQ, AWQ, KVQuant) avec des pertes mesurables au-delà de 32K tokens. Passer à 2 bits sans effondrer la qualité, c'est résoudre l'équation qui rend le long-contexte économiquement viable en production.

L'essentiel

• OSCAR quantifie le KV cache en INT2, divisant la mémoire de cache par 8 par rapport au BF16, ce qui permet de servir des modèles comme Claude Opus 4.7 ou GPT-5.5 sur des fenêtres de 256K tokens avec des configurations GPU réalistes.
• La clé technique : des rotations spectrales offline qui éliminent les outliers channel-wise avant quantification, un problème qui rendait l'INT2 KV cache impossible jusqu'ici.
• Les benchmarks RULER et Needle in a Haystack montrent une précision near-BF16, dépassant QTIP de Google sur les scénarios de contexte long, avec un overhead de calcul négligeable à l'inférence.

Outils recommandés

Pourquoi le KV cache est le vrai problème du long-contexte

Un modèle comme GPT-5.5 en BF16 consomme environ 2 bytes par paramètre de poids. Mais pour chaque token en entrée, le KV cache stocke deux vecteurs (clé et valeur) dont la taille dépend de la dimension du modèle et du nombre de têtes d'attention.

Pour un modèle de 70B paramètres avec une fenêtre de 128K tokens, le KV cache seul peut dépasser 16 Go. À 256K tokens, on dépasse la mémoire d'un H100. Le calcul GPU est largement sous-utilisé : la bande passante mémoire est le bottleneck, pas les FLOPs.

C'est exactement le problème que les meilleurs LLM pour la recherche rencontrent lorsqu'ils ingèrent des documents massifs. Le modèle doit stocker l'intégralité du contexte en mémoire avant de pouvoir répondre, et cette mémoire coûte cher.

La quantification des poids (INT4, INT8) est aujourd'hui mature. Mais la quantification du KV cache est un problème fondamentalement différent : elle intervient en ligne, pendant le préremplissage (prefill), et ne bénéficie pas d'un dataset de calibration statique.

Ce qui rend l'INT2 KV cache impossible sans OSCAR

La quantification à 2 bits signifie que chaque valeur n'a que 4 niveaux possibles. L'erreur de quantification est donc structurellement massive. Mais le vrai problème n'est pas la plage de valeurs : ce sont les outliers.

Dans le KV cache, certains canaux présentent des valeurs aberrantes (outliers) jusqu'à 100x plus grandes que la médiane. Ces outliers sont canal-par-canal (channel-wise), ce qui signifie qu'un quantizeur uniforme classique est forcé d'utiliser toute sa plage dynamique pour accommoder ces extrêmes.

Résultat : les 99% de valeurs normales sont écrasées dans 1 ou 2 niveaux de quantification, perdant quasiment toute information. C'est pour cela que KVQuant (2024) plafonnait à 4 bits et que les approches à 2 bits produisaient des réponses incohérentes au-delà de 8K tokens.

QTIP de Google (2025) a partiellement résolu le problème en utilisant une quantification par-tête et un codebook appris, mais au prix d'un overhead de calcul non négligeable et d'une complexité d'intégration importante.

Comment OSCAR résout le problème des outliers avec des rotations spectrales

L'insight fondamental d'OSCAR est simple mais élégant : au lieu de quantifier les vecteurs KV directement, on les projette dans un espace où les outliers n'existent plus, puis on quantifie dans cet espace.

Rotations spectrales offline

OSCAR applique une rotation orthogonale aux vecteurs clé et valeur, calculée offline à partir d'un dataset de calibration. Cette rotation est construite via une décomposition SVD (Singular Value Decomposition) des matrices de projection attention.

L'objectif : redistribuer l'énergie des outliers sur l'ensemble des dimensions, de sorte que chaque canal ait une variance comparable. Une fois les vecteurs rotatés, un quantizeur INT2 uniforme fonctionne correctement car il n'y a plus de canal dominant.

La rotation est offline, ce qui signifie zéro coût à l'inférence. Elle est stockée comme une matrice légère (quelques Ko par couche) et appliquée comme une simple multiplication matricielle pendant le préremplissage, une opération déjà vectorisée dans les kernels CUDA existants.

Quantification attention-aware

OSCAR ne traite pas les clés et les valeurs de manière identique. Les clés servent au calcul de score d'attention (query × key), tandis que les valeurs sont utilisées pour la combinaison pondérée (attention × value). L'erreur de quantification a donc un impact différent selon qu'elle touche K ou V.

Le système adapte sa stratégie de quantification : plus de bits effectifs pour les clés (où l'erreur se propage exponentiellement à travers le softmax), et une quantification plus agressive pour les valeurs (où l'erreur est linéairement amortie par les poids d'attention).

Cette distinction attention-aware est ce qui permet à OSCAR de rester en INT2 global tout en préservant la qualité. Comme on le voit dans le classement des meilleurs LLM agentic, la précision de l'attention sur les longues séquences est ce qui différencie un agent fiable d'un agent qui hallucine.

Benchmarks : near-BF16 sur RULER et Needle in a Haystack

Les résultats publiés par Together AI sont solides et mesurés sur les benchmarks standards du domaine.

RULER (Long-Contexte Reasoning)

RULER est le benchmark de référence pour évaluer la compréhension en contexte long. Il teste la récupération d'information, le raisonnement multi-étapes et la déduction sur des fenêtres allant jusqu'à 128K tokens.

OSCAR INT2 perd seulement 0.2% à 16K tokens et 1.2% à 128K tokens par rapport au BF16. QTIP s'effondre à 128K (-11.5 points), tandis que même KVQuant INT4 perd 5.7 points.

Needle in a Haystack

Le test "aiguille dans une botte de foin" place un fait unique à une position aléatoire dans un contexte long et vérifie si le modèle le récupère.

OSCAR INT2 maintient un taux de réussite supérieur à 99% jusqu'à 128K tokens, contre 97% pour QTIP et 99.5% pour le BF16. La dégradation n'apparaît de manière significative qu'au-delà de 256K tokens, une fenêtre où le BF16 lui-même commence à faiblir sur certains modèles.

Ces chiffres sont cohérents avec les performances qu'on observe sur les meilleurs LLM en contexte long : la qualité de l'attention est le facteur limitant, pas la capacité du modèle.

OSCAR vs QTIP vs OScaR académique : trois approches différentes

Il y a une confusion de nommage à clarifier. OScaR (avec un « c » minuscule) est aussi le nom d'un système algébrique computationnel développé dans le cadre de projets universitaires (cf. les papiers sur la théorie des nombres dans OSCAR, les bases monomiales en théorie de Lie, et les matroïdes dans OSCAR). Rien à voir avec la quantification KV cache.

La comparaison pertinente est entre OSCAR (Together AI), QTIP (Google), et les approches académiques de quantification KV cache.

OSCAR gagne sur pratiquement tous les axes. La rotation spectrale offline est une solution élégante qui déplace le problème de l'inférence vers un prétraitement one-time, un compromis quasi gratuit pour les déploiements de production où le modèle servi ne change pas toutes les heures.

Pour les équipes qui veulent tester ces approches en local avec des meilleurs LLM locaux, l'intégration d'OSCAR dans vLLM rend l'expérimentation accessible sans infrastructure cloud.

Impact concret sur le coût de serving

Prenons un cas réel : servir GPT-5.4 Pro (91 points au classement general) sur une fenêtre de 128K tokens avec un batch size de 32 requêtes concurrentes.

Mémoire KV cache (estimation par requête, modèle 70B-equivalent)

Passer de 153 Go à 19 Go de KV cache, c'est passer de 8 H100 à 2 H100 pour le même workload. À 2$/heure par H100, c'est une économie de ~12$/heure, soit ~8 640$/mois en continu.

Pour les hébergeurs qui servent des milliers de requêtes par minute, cette réduction transforme la viabilité économique du long-contexte. Un fournisseur comme Hostinger pourrait offrir du serving LLM à des prix radicalement inférieurs en intégrant OSCAR dans sa pile.

Ce que ça change pour les agents IA

Les agents qui recherchent, codent et créent sur le long terme accumulent du contexte au fil de leurs itérations. Un agent comme DeerFlow de ByteDance peut générer des dizaines de milliers de tokens de raisonnement intermédiaire avant de produire sa sortie finale.

Avec OSCAR, la mémoire nécessaire pour maintenir ce contexte intermédiaire est divisée par 8. Cela signifie soit des agents capables de raisonner sur des fenêtres plus longues, soit plus d'agents concurrents sur le même hardware.

La connexion avec les search agents open-source est directe : ces agents ingèrent des pages web entières, les stockent en contexte, et itèrent. Le KV cache est leur principal poste de coût mémoire.

De manière plus surprenante, des travaux montrent que grep est tout ce dont les agents IA ont besoin plutôt que la recherche vectorielle. Mais que l'agent utilise grep ou un retriever, le problème du KV cache en contexte long reste identique : il faut stocker les résultats de la recherche en mémoire pour les raisonner.

Limites d'OSCAR

Malgré ses résultats impressionnants, OSCAR a des limitations que le papier mentionne honnêtement.

Sensibilité au dataset de calibration

Les rotations spectrales sont calculées sur un dataset de calibration. Si la distribution des données de production diffère significativement (par exemple, passage du français à l'arabe, ou de la prose à du code très dense), l'efficacité de la rotation peut se dégrader. Together AI recommande de recalibrer pour les distributions significativement différentes.

C'est un point important pour les meilleurs LLM en français, dont les distributions attentionnelles en français peuvent différer suffisamment de l'anglais pour justifier une recalibration.

Dégradation au-delà de 256K tokens

Les benchmarks montrent une dégradation plus marquée au-delà de 256K tokens, où OSCAR INT2 perd environ 3-4% par rapport au BF16. Le papier suggère que les rotations spectrales deviennent moins efficaces quand la longueur de séquence dépasse largement celle du dataset de calibration.

Modèles non-standards

OSCAR a été validé sur des architectures transformer classiques (GPT, LLaMA, DeepSeek). Les architectures avec des mécanismes d'attention non-standard (attention linéaire, mamba-hybride) ne sont pas couvertes. Le moteur d'inférence local DS4 qui cible DeepSeek V4, par exemple, nécessiterait une adaptation spécifique.

Intégration pratique : comment utiliser OSCAR

OSCAR est conçu pour s'intégrer dans vLLM, le moteur de serving le plus utilisé en open-source. Le workflow est en deux phases.

Phase 1 : Calibration offline

La calibration consiste à faire passer un dataset représentatif (typiquement 512 à 2048 séquences) à travers le modèle pour calculer les matrices de rotation SVD par couche. Cette opération prend entre 10 et 30 minutes sur un seul GPU pour un modèle de 70B, et ne nécessite qu'une seule fois par configuration de modèle.

Phase 2 : Serving avec KV cache quantifié

Une fois les rotations calculées, elles sont chargées au démarrage du serveur vLLM. Le serving fonctionne normalement, avec une étape de rotation supplémentaire pendant le préremplissage. L'overhead mesuré est inférieur à 3% sur le temps total de préremplissage, car la rotation est fusionnée (fused) avec la projection QKV existante dans les kernels CUDA.

Pour ceux qui préfèrent éviter la complexité de vLLM, l'installation d'un LLM local avec LM Studio ou Ollama ne supporte pas encore OSCAR nativement, mais les kernels sont suffisamment simples pour être intégrés dans les agents IA open source avec Ollama à moyen terme.

Positionnement dans l'écosystème de quantification

OSCAR ne remplace pas la quantification des poids. C'est complémentaire. Une configuration de production optimale combine des poids en INT4 (via GPTQ ou AWQ) avec un KV cache en INT2 (via OSCAR).

La pile de quantification complète ressemble à ça :

Comparer cette pile avec les meilleurs LLM gratuits qui tournent en BF16 full sur le cloud du fournisseur : la différence de coût de serving est d'un ordre de grandeur.

Perspective historique : d'OSCaR mathématique à OSCAR quantification

Le nom OSCAR est un acronyme récursif dans le cas de Together AI. Mais la coïncidence avec le système algébrique OSCAR est intéressante.

Le projet OSCAR académique est un système de calcul algébrique open-source qui implémente des algorithmes en théorie des nombres, théorie de Lie, et géométrie algébrique. Les papiers publiés en 2024 décrivent des calculs de théorie des nombres dans OSCAR, des bases monomiales en théorie de Lie via OSCAR, et des matroïdes dans OSCAR.

Il existe aussi un papier de 1994 sur Oscar Klein et la théorie de jauge qui n'a aucun rapport avec l'un ou l'autre projet. Et le projet astrophysique CoReCon sur les contraintes de réionisation est dans un domaine totalement différent.

La leçon : quand vous cherchez "OSCAR" sur arXiv, précisez votre domaine. Together AI aurait peut-être dû choisir un nom moins ambigü, mais l'acronyme technique est justifié par le mécanisme (Orthogonal Spectral Channel-Aware Rotation).

❌ Erreurs courantes

Erreur 1 : Confondre quantification des poids et quantification du KV cache

Ce sont deux problèmes distincts. Quantifier les poids réduit la mémoire de stockage du modèle (fixe). Quantifier le KV cache réduit la mémoire par requête (dynamique, scale avec la longueur du contexte). OSCAR ne fait que du KV cache. Combiner les deux est nécessaire pour un déploiement optimal.

Erreur 2 : Penser que INT2 = INT2 partout

Toutes les quantifications 2-bit ne se valent pas. Un quantizeur naïf sur le KV cache produit des résultats inutilisables. OSCAR atteint l'INT2 viable précisément parce que les rotations spectrales transforment l'espace avant quantification. Comparer "OSCAR INT2" avec "INT2 generic" n'a pas de sens.

Erreur 3 : Ignorer le dataset de calibration

Utiliser les rotations spectrales calculées sur du texte anglais pour servir un modèle en chinois ou en arabe, c'est s'exposer à une dégradation silencieuse de la qualité. La calibration est un pas obligatoire, pas un détail.

❓ Questions fréquentes

OSCAR fonctionne-t-il avec les modèles de code comme Claude Opus 4.7 ou GPT-5.3 Codex ?

Le papier valide OSCAR sur des architectures decoder-only standard. Les modèles de code ont des distributions attentionnelles différentes (plus de focus local, moins de diffusion globale), ce qui peut nécessiter une recalibration. Les résultats préliminaires sont encourageants mais pas encore publiés pour les cas purement code.

Quel est l'overhead en latence ?

L'overhead mesuré est inférieur à 3% sur le temps de préremplissage (prefill) et nul sur la génération token par token (decode). La rotation est fusionnée avec la projection QKV existante, donc il n'y a pas de kernel supplémentaire.

OSCAR remplace-t-il les architectures de longue fenêtre comme Mamba ou Ring Attention ?

Non. OSCAR réduit la mémoire du KV cache existant. Les architectures sans KV cache (Mamba, RWKV) éliminent le problème différemment. Mais pour les transformers standard qui dominent le classement des meilleurs LLM pour coder, OSCAR est la solution la plus pragmatique.

Peut-on utiliser OSCAR avec des LLM pour agents comme ceux de la liste Hermes/OpenClaw ?

Oui, dès lors que le modèle sous-jacent est un transformer standard avec un mécanisme d'attention classique. Les agents qui accumulent du contexte sur de longues sessions sont d'ailleurs les premiers bénéficiaires de la réduction mémoire.

✅ Conclusion

OSCAR est la première solution de quantification KV cache INT2 qui tient la route en production, avec une perte mesurable de seulement 1.2% à 128K tokens sur RULER. En divisant par 8 la mémoire de cache, Together AI rend le serving de LLM en contexte long économiquement viable sans compromis architectural. Le code est ouvert, l'intégration vLLM est simple, et l'impact sur le coût de serving est immédiat. Si vous servez des LLM en production avec des fenêtres supérieures à 32K tokens, OSCAR n'est pas une option : c'est une obligation.

Sources : MarktechPost — Together AI open-sources OSCAR, OSCAR — Attention-Aware 2-bit KV Cache Quantization (arXiv, mai 2026), Together AI.