ggml-webgpu: Improve prefill speeds for k-quants + refactor matmul for Q4/Q5/Q8 and k-quants by yomaytk · Pull Request #24225 · ggml-org/llama.cpp

## WebGPU + llama.cpp : les k-quants passent enfin à la vitesse supérieure

### Ce qui change concrètement

La PR #24225 de yomaytk dans ggml-org/llama.cpp refactorise le pipeline matmul pour les quantifications k-quants (Q2_K à Q6_K) sous le backend WebGPU. L'impact est mesuré sur pp512 (prefill de 512 tokens) sur M2 Pro — un hardware représentatif du segment "développeur local haut de gamme".

Les chiffres bruts : Q3_K passe de 92,54 t/s à 302,24 t/s sur Qwen3.5 4B (+3,27x), et de 79,06 t/s à 298,73 t/s sur Gemma4 E4B (+3,78x). Q2_K sur Qwen3 0.6B bondit de 817,86 t/s à 1991,81 t/s (+2,44x). Les gains sur Q4_K, Q5_K et Q6_K sont plus modestes mais cohérents : entre +1,33x et +1,52x selon le modèle.

### Pourquoi les k-quants étaient sous-optimaux sur WebGPU

Les k-quants (format introduit par llama.cpp pour compresser les poids par blocs avec des super-blocs) ont une structure de décodage plus complexe que les quantifications simples Q4_0 ou Q8_0. Chaque bloc nécessite de reconstruire des scales et des min-values à partir de bits compressés avant de pouvoir effectuer le produit matriciel. Sur Metal ou CUDA, des kernels dédiés exploitent cette structure depuis longtemps. Sur WebGPU, le backend ggml-webgpu utilisait jusqu'ici des chemins génériques moins efficaces — d'où l'écart massif observé sur Q3_K notamment.

La PR introduit des shaders WGSL spécialisés pour chaque format k-quant, avec une refactorisation du dispatch matmul qui adapte la taille des workgroups à la structure des blocs. Le gain asymétrique (3,78x sur Q3_K vs 1,34x sur Q4_K) s'explique : Q3_K avait le chemin le plus sous-optimal avant, Q4_K bénéficiait déjà partiellement d'optimisations antérieures.

### Contexte : pourquoi WebGPU compte maintenant

WebGPU n'est plus un backend expérimental. Depuis fin 2024, il est le seul chemin viable pour exécuter des LLMs quantisés directement dans le navigateur avec accélération GPU sur Windows (pas de Metal, pas de CUDA dans le browser). Il couvre aussi les GPU Intel Arc, les iGPU AMD et les configurations sans driver CUDA — soit une fraction non négligeable des machines de développeurs et d'utilisateurs finaux.

Avant cette PR, utiliser Q3_K via WebGPU sur un modèle 4B donnait ~79-92 t/s en prefill sur M2 Pro. C'est acceptable pour la génération token-by-token, mais pénalisant pour les longs contextes ou le batch processing. À ~300 t/s, le prefill d'un contexte de 4096 tokens passe de ~44s à ~13s — différence perceptible dans tout workflow interactif.

### Qui perd dans cette équation

Les backends concurrents dans l'écosystème browser-side : **WebLLM** (basé sur Apache TVM/MLC) et **Transformers.js** (ONNX Runtime Web) avaient jusqu'ici un avantage de performance sur les k-quants via leurs propres pipelines de compilation. Cette PR réduit l'écart et renforce llama.cpp comme référence unique couvrant CPU, Metal, CUDA, Vulkan et WebGPU dans une même codebase.

Côté hardware, les GPU sans support natif des opérations entières rapides (certains GPU mobiles anciens, WebGPU sur fallback CPU) ne bénéficieront pas des mêmes gains — les shaders WGSL optimisés supposent un dispatch GPU réel.

### Limites et ce qui manque encore

Les benchmarks sont exclusivement sur M2 Pro. Les performances sur GPU discrets (NVIDIA via WebGPU/Dawn, AMD RDNA) ne sont pas documentées dans la PR — les gains pourraient varier significativement selon l'architecture de l'unité de calcul shader. Le test couvre pp512 (prefill) mais pas tg128 (génération) : les speedups en decode sont probablement moindres car ce régime est memory-bandwidth-bound plutôt que compute-bound.

Q8_0 et les formats non-k-quants (Q4_0, Q5_0) sont mentionnés dans le titre de la PR comme refactorisés, mais les benchmarks publiés ne couvrent que les k-quants — les gains sur ces formats restent à vérifier indépendamment.

### Signal pour les praticiens

Si vous déployez llama.cpp via WebGPU (wasm build, applications Electron, ou serveurs Node.js avec backend GPU), cette PR justifie un test immédiat dès merge. Prioriser Q3_K sur les modèles 4B-7B si la latence de prefill est votre contrainte principale : le ratio qualité/vitesse devient nettement plus favorable. Pour les modèles sub-1B (Qwen3 0.6B), Q2_K à ~2000 t/s en prefill ouvre des cas d'usage temps-réel qui n'étaient pas praticables avant.