Inférence LLM : kernels WebGPU, quantisation sous 2 bits et décodage spéculatif, la nouvelle vague d’optimisation

💡 En résumé

La course aux modèles toujours plus gros laisse place, en cette rentrée 2026, à une course à l’efficacité d’exécution d’une intensité rare. Quatre signaux convergents : Hugging Face industrialise l’inférence dans le navigateur avec 207 kernels WebGPU publiés comme des artefacts logiciels versionnés ; la quantisation descend sous la barre des 2 bits avec QTEA (1,7 bit par poids en moyenne, +16,7 % de précision sur le meilleur baseline ternaire) ; le décodage long-contexte attaque le mur de la bande passante mémoire avec Faster Flash Decoding (jusqu’à 11,6× au niveau kernel, 2,37× en bout-en-bout sur 256K de contexte) ; et le décodage spéculatif s’étend enfin aux modèles vision-langage sans perte avec GLANCE (2,93× plus rapide que l’autorégression). Même l’entraînement par renforcement s’y met, avec un clipping adaptatif (GAPO) qui cesse de brider les rollouts rares les plus informatifs. Décryptage d’une journée où l’ingénierie fine a remplacé les annonces de scaling.

🔥 Tendances : l’inférence devient un problème d’artefacts logiciels

207 kernels WebGPU : Hugging Face transforme les shaders en paquets versionnés

L’annonce la plus structurante de la journée vient de Hugging Face avec la première couche de son effort d’inférence dans le navigateur : @huggingface/kernels, une bibliothèque minimale pour charger et exécuter des kernels WebGPU optimisés depuis le Hub, accompagnée d’une collection initiale de 207 kernels publiés sur huggingface.co/webgpu-kernels.

La rupture n’est pas tant le nombre que la nature des artefacts. Chaque kernel est publié comme un paquet complet et versionné : son interface, ses templates de shaders, ses cas de correction, ses cas de benchmark et ses instructions d’utilisation vivent ensemble sur le Hub. Concrètement, chaque dépôt contient :

• manifest.json, source de vérité du contrat de l’opération (entrées, sorties, attributs, contraintes de types, règles de dérivation des formes) ;
• test.json, les cas de correction pour vérifier l’implémentation ;
• bench.json, les cas de benchmark et de tuning représentant les workloads d’évaluation ;
• les templates WGSL (.wgsl.jinja) paramétrés qui produisent les shaders pour une requête et un device donnés.

Cette structure transforme un shader en artefact logiciel réutilisable : l’interface est inspectable sans lire de WGSL, les preuves de correction et de performance voyagent avec l’implémentation, et les versions publiées peuvent être chargées explicitement — fini les URLs de fichiers non versionnées. Un loader JavaScript (getKernel avec un ID de dépôt et une version de contrat) fait le pont entre le dépôt et l’application, avec des variants par opération (formes égales, broadcast vectorisé, scalaire, broadcast général) sélectionnés à l’exécution selon l’appel et le device.

Le deuxième morceau de l’annonce est Fleet, une suite de benchmarking et de test dans le navigateur qui exécute et score les kernels sur le matériel de l’utilisateur — et, avec son consentement, fait remonter des preuves privées de performance et de correction depuis des devices qu’aucun labo conventionnel ne peut couvrir. C’est du crowdsourcing de benchmarks GPU, une réponse pragmatique à un problème connu : la portabilité WebGPU ne garantit pas la performance, car deux shaders peuvent implémenter la même opération avec des comportements très différents selon l’accélérateur — taille de workgroup, patterns d’accès mémoire, vectorisation, types de données, stratégies de fusion.

Le mur mémoire du long-contexte : Faster Flash Decoding

Côté recherche, le papier Faster Than Flash (arXiv 2609.00097) s’attaque au goulet d’étranglement qui limite les LLM long-contexte : la bande passante mémoire et la complexité quadratique de l’attention pendant le décodage. Les approches existantes se débattent dans un dilemme : les métriques basées sur des métadonnées coûtent de la mémoire, les stratégies de sélection adaptative coûtent du calcul.

La réponse est Faster Flash Decoding (FFD), un framework de co-design matériel-algorithme qui fusionne sélecteur et calculateur dans un kernel entièrement fusionné, remplaçant les index de métadonnées externes par un scan conscient du contenu via quantisation low-bit. La stratégie « top-delta » filtre dynamiquement les blocs pour atteindre une sparsité adaptative à la distribution, sans synchronisation globale. Résultats : jusqu’à 11,6× d’accélération au niveau kernel, extension à 256K de contexte, et 2,37× de débit amélioré en bout-en-bout — le tout sans entraînement, plug-and-play, en réutilisant les résultats du scan pour le calcul. La validation sur RULER et LongBench confirme le maintien de la précision.

🤖 Nouveaux outils : la quantisation sous 2 bits tient ses promesses

QTEA : des LLM ternaires à 1,7 bit par poids

La quantisation post-entraînement (PTQ) plafonnait jusqu’ici sous la barre des 2 bits : les méthodes existantes échouent souvent à généraliser entre modèles et subissent des pertes sévères de précision. QTEA (arXiv 2609.00224) change la donne en combinant trois idées :

1. des poids ternaires (3 valeurs) avec des poids saillants résiduels comme compensateurs d’erreur, assignés à des colonnes sélectionnées en sparsité semi-structurée 1:4 pour rester GPU-friendly ;
2. un raffinement de rescale par colonne du style GPTQ, alternant mise à jour des échelles et des assignations ternaires pour réduire l’erreur de reconstruction ;
3. un error decay qui atténue la propagation d’erreur tardive — QTEA identifie la dépendance à l’ordre dans GPTQ et la corrige.

Les chiffres parlent d’eux-mêmes : sur Qwen3-14B, tous les poids sont compressés à 1,7 bit effectif par poids avec une amélioration moyenne de 16,7 % par rapport au meilleur baseline ternaire, et une perplexité 1,40× et 2,61× plus basse sur WikiText et C4. Sur Llama3-8B, gain de 6,6 % et perplexité 1,34×/1,95× améliorée. Un kernel basé sur des lookup-tables atteint 7,2× de génération plus rapide par token qu’un baseline FP16. Pour les déploiements edge et les cartes à mémoire contrainte, c’est un palier significatif.

REAL-Q : la quantisation cesse de geler le Hessien

REAL-Q (arXiv 2609.00049) attaque un défaut structurel des PTQ de pointe : elles quantifient chaque couche avec un solveur fermé du second ordre qui gèle le Hessien sur toute la couche — alors que le paysage de perte change colonne par colonne. Ce « information misalignment » force des approximations lourdes (couplage inter-canaux négligé, lignes de sortie poolées en groupes).

La parade : viser un surrogate aligné de la perte globale bout-en-bout et le raffiner par descente de gradient par blocs dynamique et fine après chaque bloc de 128 colonnes, couplée à une fenêtre glissante pour des transitions inter-couches lisses qui atténuent la propagation d’erreur. Sur LLaMA-3.1 (8B et 70B) et Qwen3 (0,6B-32B) en W4A16, REAL-Q réduit la divergence KL bout-en-bout jusqu’à ~49 % par rapport aux méthodes globalement guidées de l’état de l’art. Le message : la quantisation de qualité se mérite désormais par une optimisation fine, pas par une formule fermée.

HBQ : la quantisation par blocs hiérarchiques passe à l’ASIC

HBQ (arXiv 2609.00450) explore l’espace de conception de la Block Quantization (BQ) — qui quantifie poids ET activations, offrant un datapath unifié plus efficace que la weight-only quantization. Constat issu d’une exploration systématique : augmenter la taille des blocs améliore l’efficacité matérielle (amortissement de la déquantisation et des accumulations) mais dégrade la précision. HBQ résout le dilemme avec de grands blocs (efficacité maximale) et un scaling « significand » (SIG) à faible overhead pour la quantisation de second niveau, qui compense les erreurs des grands blocs mieux que les schémas Power-of-Two ou INT.

Les résultats matériels sont concrets : HBQ-A atteint la précision W4A16 avec seulement W4A5 (moins de surface silicium que NVFP4), et un accélérateur ASIC 28nm appliquant HBQ aux poids, activations et cache KV livre 2,3×/4,6× d’efficacité surfacique/énergétique à précision égale, avec 1,6-3,3× de réduction d’énergie système et 1,5-3,0× d’accélération. Quand la quantisation se co-conçoit avec le silicium, les gains se cumulent.

GLANCE : le décodage spéculatif sans perte arrive sur les VLM

Le décodage spéculatif accélérait la génération sans en changer le résultat… sauf sur les modèles vision-langage (VLM), piégés dans un cycle vicieux : le drafter doit rester petit donc autorégressif, il ne peut pas se payer l’image à chaque étape, la vision est compressée ou masquée — et un drafter coupé de l’image est le moins fiable précisément là où l’image rend le texte prédictible.

GLANCE (arXiv 2609.00355) casse le cycle aux deux bouts : une tête de diffusion par blocs lit l’état vision-langage déjà fusionné du target — la vision ne coûte donc rien au drafter — et remplit tout un bloc en un seul forward pass. Un large arbre de candidats est vérifié en une passe du target, et chaque prompt audité reproduit exactement le décodage glouton. Les workloads ancrés sur du grounding (qui récompensent le plus) entrent dans un régime de copie verbatim : les longs runs qui coûtaient une passe par token à un drafter autorégressif coûtent une passe au total à un drafter par blocs. Sous un même moteur et un même budget de rounds, GLANCE décode jusqu’à 2,93× plus vite que l’autorégression, accepte des blocs 2,7× plus longs qu’une tête EAGLE-3 entraînée sur le même corpus — et la loi qui organise ces résultats est élégante : la longueur acceptée est fixée par l’entropie du prochain token du target.

GAPO : un clipping adaptatif pour le RL avec récompenses vérifiables

Même l’entraînement s’optimise. GAPO (Group Adaptive Clipping Policy Optimization, arXiv 2609.00444) identifie une limite du GRPO standard : le ratio clipping fixe bride de la même façon les rollouts corrects rares (sur les problèmes durs) et abondants (sur les problèmes faciles) — alors que les rollouts à faible succès de groupe portent des ratios IS plus grands et un signal de gradient plus fort pour l’exploration. D’inspiration trust-region KL inverse, GAPO adapte la frontière de clipping à l’avantage du rollout : plus le signal d’apprentissage est grand, plus la marge de mise à jour est grande. Sans reward shaping, en préservant le surrogate PPO/GSPO, GAPO améliore Pass@1 et Pass@k sur les benchmarks de raisonnement mathématique et de code où les taux de passage du modèle de base sont faibles. Une correction chirurgicale, plug-in, d’un défaut connu du RLVR.

📊 Analyse : vers une « inférence en couches » où chaque brique est optimisable

Mises bout à bout, ces annonces dessinent une stratégie d’optimisation en couches qui ne laisse plus aucun niveau de la pile intact :

1. Couche matérielle/logicielle bas niveau : les kernels deviennent des artefacts versionnés avec contrats, tests et benchmarks embarqués (Hugging Face) — une gouvernance d’ingénierie qui manquait cruellement à l’écosystème, où un shader était un fichier opaque.
2. Couche modèle compressé : la quantisation sous 2 bits (QTEA), guidée par gradient (REAL-Q) et co-conçue avec le silicium (HBQ) repousse le point d’équilibre précision/mémoire. Le W4A5 qui égale le W4A16 est un marqueur : l’écart entre formats « académiques » et formats « industriels » se résorbe.
3. Couche décodage : le long-contexte (FFD) et le décodage spéculatif (GLANCE) attaquent les deux murs restants — bande passante mémoire et latence séquentielle — avec des gains qui se cumulent aux économies de la quantisation.
4. Couche entraînement : même le RLVR affine ses hyperparamètres (GAPO), signe que l’optimisation ne se limite plus à l’inférence.

Un point mérite l’attention des équipes MLOps : la mesure. Hugging Face pousse une philosophie où chaque kernel publie ses propres cas de correction et de benchmark, et où Fleet agrège des preuves depuis le matériel réel des utilisateurs. C’est une réponse directe à un problème que nous documentons ici depuis des mois : les benchmarks de laboratoire ne capturent pas la diversité des devices réels — un kernel rapide sur A100 peut être pathologiquement lent sur un GPU intégré, et seule la télémétrie de masse le révèle. Les équipes qui déploient de l’inférence locale (navigateur, edge, laptop) devraient suivre de près la collection webgpu-kernels : elle devient la référence pour qui veut éviter de réimplémenter des opérations déjà optimisées et testées.

Côté arbitrage économique, la tendance est limpide : à capacité de calcul constante, chaque pourcent d’efficacité d’inférence se traduit directement en marge ou en capacité client. La quantisation 1,7 bit, le décodage 11,6× et la fusion kernel après kernel sont les nouveaux leviers de coût — souvent plus actionnables que l’achat de GPU supplémentaires, surtout quand l’offre reste tendue.

🎯 À retenir

• Hugging Face publie @huggingface/kernels : 207 kernels WebGPU versionnés avec manifeste, tests de correction et benchmarks embarqués, plus Fleet, un banc de test dans le navigateur qui crowdsource les preuves de performance sur le matériel réel.
• QTEA fait passer la quantisation sous 2 bits en production : 1,7 bit/poids sur Qwen3-14B, +16,7 % de précision vs le meilleur baseline ternaire, 7,2× de génération plus rapide qu’en FP16.
• Faster Flash Decoding attaque le mur mémoire du long-contexte : kernel fusionné avec scan conscient du contenu, jusqu’à 11,6× au niveau kernel, 2,37× en bout-en-bout à 256K de contexte, sans entraînement.
• REAL-Q remplace le Hessien gelé par une descente de gradient par blocs : jusqu’à -49 % de divergence KL bout-en-bout en W4A16.
• HBQ co-conçoit quantisation et silicium : la précision W4A16 avec seulement W4A5, et 2,3-4,6× d’efficacité énergétique sur ASIC 28nm.
• GLANCE étend le décodage spéculatif sans perte aux VLM : 2,93× plus rapide que l’autorégression en décodant par blocs d’une passe.
• Pour les équipes d’ingénierie : l’inférence s’optimise désormais couche par couche avec des artefacts testables et versionnés — la question n’est plus « quel modèle ? » mais « quelle pile d’exécution, avec quels kernels, à quelle précision, sur quel device ? »