banc 4 modeles sur Ada : Kimi-Linear devant, variantes A4B/A9B/A12B, speculation contre-intuitive

reports/2026-08-23-banc-a12b-multisession.md

@@ -0,0 +1,125 @@
+# Qwen3.8-MoE-27B-A12B : banc multi-session, TurboQuant et n-gram (23/08/2026)
+
+Mesures sur RTX 6000 Ada (sm89), vLLM 0.27.1, checkpoint
+`patdev/Qwen3.8-MoE-27B-A12B-W4A16` (INT4 groupwise, noyau Marlin WNA16 MoE), contexte 32 k,
+`gpu-memory-utilization 0.90`. Prompt : génération d'une fonction Python avec docstring et test.
+
+## Ce que ONNX et TensorRT ne peuvent pas faire ici
+
+La demande initiale était « A12B en ONNX GenAI et en TensorRT, avec plusieurs sessions ».
+Trois vérifications l'ont écartée avant tout essai :
+
+| | verdict | preuve |
+|---|---|---|
+| A12B en ONNX GenAI | **impossible** | le constructeur d'ORT GenAI ne connaît pas `Qwen3_5MoeForCausalLM` (sa liste s'arrête à `Qwen3ForCausalLM`, `PhiMoEForCausalLM`, `GptOssForCausalLM`) ; l'attention linéaire hybride n'est exportable par aucun outil disponible |
+| A12B en TensorRT-LLM | **impossible sur Ada** | `NotImplementedError: WFP4A16 MoE is unsupported on SM89` — noyau réservé à sm90 |
+| plusieurs sessions en ONNX GenAI | **impossible par conception** | l'API `Generator` (`append_tokens`, `generate_next_token`, `is_done`) n'a aucun moyen d'ajouter ou retirer une requête en cours ; les 163 tok/s mesurés sont un plafond mono-session |
+
+Le MXFP4 produit pour TRT-LLM n'est pas non plus servable par vLLM : `_is_mxfp4()` route vers
+`CompressedTensorsW4A4Mxfp4`, donc du **W4A4** (activations 4 bits), alors que le checkpoint est
+weight-only (`input_activations: null`). Même classe de piège de mappage que celui trouvé dans
+TRT-LLM. D'où le choix du **W4A16 groupwise**, qui passe par le noyau Marlin éprouvé.
+
+## Montée en charge
+
+| concurrence | agrégé j/s | par flux | latence |
+|---|---:|---:|---:|
+| 1 | 45,7 | 45,7 | 4,4 s |
+| 4 | 151,4 | 37,8 | 5,3 s |
+| 8 | 294,9 | 36,9 | 5,4 s |
+| 16 | 529,0 | 33,1 | 6,0 s |
+| **32** | **875,5** | 27,4 | 7,3 s |
+
+**×19,2 entre 1 et 32 sessions**, pour seulement 40 % de perte par flux : le batching continu
+travaille très bien sur ce modèle.
+
+### L'écart avec Ornith se resserre sous charge
+
+| | solo | 32 sessions |
+|---|---:|---:|
+| Ornith-1.5-35B-A3B (≈3 B actifs) | 134,1 | 1 380 |
+| A12B (12,80 B actifs) | 45,7 | 875,5 |
+| **rapport** | **2,9×** | **1,58×** |
+
+En solo, l'A12B paie plein tarif ses 4,3× de paramètres actifs. À 32 sessions, l'écart tombe à
+1,58× : le régime devient limité par le calcul partagé entre requêtes, et le surcoût par jeton
+se dilue. **Pour un usage multi-agents, le supplément de qualité coûte bien moins cher qu'en
+solo.**
+
+## TurboQuant : recommandable ici, contrairement à Ornith
+
+| | bf16 KV | TurboQuant `k3v4_nc` | écart |
+|---|---:|---:|---|
+| cache KV | 232 288 jetons | **733 499** | **×3,16** |
+| solo | 45,7 | 45,3 | −0,9 % |
+| 8 sessions | 294,9 | 289,2 | −1,9 % |
+| 32 sessions | 875,5 | 839,7 | −4,1 % |
+
+**Le contexte triple pour ~4 % de débit à forte charge.** C'est l'inverse du résultat sur Ornith
+(15,0 contre 26,4 j/s le 22/08), et la raison est structurelle : l'A12B a **16 couches
+d'attention pleine** dont le cache est volumineux, alors qu'Ornith est presque entièrement en
+attention linéaire, dont les états sont de **taille fixe** et ne gagnent rien à être quantifiés.
+
+À retenir comme règle : **TurboQuant paie proportionnellement à la part d'attention pleine du
+modèle.**
+
+## Spéculation n-gram : ×2,8, mais uniquement sur du code
+
+| | bf16 | n-gram (k=3, lookup 4) | écart |
+|---|---:|---:|---|
+| solo | 45,7 | **129,2** | **+183 %** |
+| 8 sessions | 294,9 | **637,8** | **+116 %** |
+| latence solo | 4,4 s | **1,5 s** | −66 % |
+
+Elle amène l'A12B **au niveau d'Ornith en solo** (129,2 contre 134,1) alors qu'il active 4,3× plus
+de paramètres, et sans aucun poids supplémentaire.
+
+**Réserve majeure, à ne pas perdre de vue** : le prompt du banc demande d'écrire une fonction
+Python avec docstring et test unitaire, c'est-à-dire le **cas le plus favorable** à la
+spéculation n-gram, qui recopie des motifs répétés. Les mesures du 22/08 donnaient **+86 % en
+édition de code mais −43 % en prose**. Ce ×2,8 est un plafond de génération de code, pas une
+accélération générale : **activer pour du codage, désactiver pour de la rédaction.**
+
+## Contexte long : mesure dominée par le préremplissage
+
+| ~8 k de contexte | agrégé | par flux | latence |
+|---|---:|---:|---:|
+| 1 session | 26,2 | 26,2 | 7,6 s |
+| 8 sessions | 49,3 | 6,2 | 32,2 s |
+
+Ces chiffres ne mesurent **pas le décodage** : 8 000 jetons à ingérer pour 200 générés, donc le
+préremplissage domine. Ils disent surtout que le cache KV de l'A12B (232 288 jetons en bf16) est
+**4,1× plus petit** que celui d'Ornith (958 169) — d'où l'intérêt de TurboQuant sur ce modèle.
+
+## Pourquoi aucun brouillon Kimi ne nous servira
+
+Deux dépôts ont été proposés : `Inferact/Kimi-K3-DSpark` et `modal-labs/Kimi-K3-DFlash`. Tous deux
+déclarent `base_model: moonshotai/Kimi-K3` et sont inutilisables ici.
+
+Un brouillon de spéculation propose des jetons que la cible **vérifie** : il doit donc partager son
+vocabulaire exact, sa géométrie et sa disposition de cache.
+
+| | Kimi-K3-DSpark | notre A12B |
+|---|---:|---:|
+| `hidden_size` | 7 168 | 5 120 |
+| `vocab_size` | 163 840 | 248 320 |
+| attention | MLA (latent de 576) | linéaire hybride + GQA |
+
+Les identifiants de jetons ne désignent même pas les mêmes mots. Et le chiffre phare de DSpark —
+464 tok/s — est obtenu sur **4× GB300 en tensor-parallel 16**, sans rapport avec une carte à
+0,84 $/h. Kimi-K3 lui-même pèse 1 561 Go, hors de portée des 49 Go de VRAM.
+
+C'est précisément pourquoi la spéculation **n-gram** est le bon levier ici : elle ne demande aucun
+poids et fonctionne sur n'importe quel modèle.
+
+## Pièges rencontrés
+
+- **`ninja` est une dépendance cachée** des modèles à attention linéaire : leurs noyaux se
+  compilent à la volée. Sans lui dans le `PATH` du sous-processus, `EngineCore` meurt sur un
+  `RuntimeError: Engine core initialization failed` qui masque le vrai
+  `FileNotFoundError: 'ninja'` quinze lignes plus haut. Ornith y échappait, ses noyaux étant en
+  cache. `torch.compile` allait au bout (78 s) avant l'échec, ce qui faisait croire à tort à un
+  problème de modèle.
+- **Écrire un `.sh` avec Python sous Windows** produit des CRLF que bash refuse
+  (`syntax error near unexpected token $'{\r'`). Utiliser `newline="\n"`, ou `tr -d "\r"` à
+  l'arrivée, et valider par `bash -n`.

reports/2026-08-23-banc-quatre-modeles-ada.md

@@ -0,0 +1,139 @@
+# Quatre familles de modèles sur RTX 6000 Ada : le débit suit l'activation (23/08/2026)
+
+Toutes les mesures sur la même carte (RTX 6000 Ada, sm89), vLLM 0.27.1, `--max-num-seqs 64`,
+`gpu-memory-utilization 0.92`, prompts identiques (génération de code, et prose pour comparaison).
+
+## Le tableau d'ensemble
+
+| modèle | actifs/jeton | solo | 8 sessions | 32 sessions | cache KV | démarrage |
+|---|---:|---:|---:|---:|---:|---:|
+| **Kimi-Linear-48B A3B** | 3,48 B | **152,2** | **772,8** | **1 609,8** | 866 531 | **70 s** |
+| Ornith-1.5-35B-A3B *(servi actuellement)* | ~3 B | 134,1 | — | 1 380 | 958 169 | ~140 s |
+| Kimi-Linear A4B (top-11) | 4,04 B | 143,7 | 618,2 | 1 286,5 | 1 743 985 | 60 s |
+| Kimi-Linear A9B (top-38) | 9,00 B | 95,9 | 463,5 | 1 245,4 | 1 616 554 | 70 s |
+| Kimi-Linear A12B (top-54) | 11,95 B | 80,7 | 481,2 | 1 183,5 | 1 545 557 | 60 s |
+| Qwen3.8-MoE-27B-A12B *(fabriqué cette nuit)* | 12,80 B | 45,7 | 294,9 | 875,5 | 232 288 | 130 s |
+| Qwen3.8-27B dense FP8 | 27 B | 21,0 | 184,8 | 598,0 | 197 361 | 220 s |
+
+## Trois régularités, et une règle qui s'est révélée fausse
+
+### 1. Le débit solo suit inversement les paramètres actifs
+
+3 B → 134-152 tok/s, 12 B → 45-81, 27 B → 21. La relation n'est pas strictement proportionnelle :
+**Kimi-Linear A12B fait 80,7 contre 45,7 pour notre Qwen3.8-A12B, à activation quasi identique**
+(11,95 contre 12,80 B). L'écart de 77 % vient de l'architecture : socle de 1,83 B et attention
+presque toute linéaire chez Kimi, contre 9,78 B de socle et 16 couches d'attention pleine chez
+Qwen3.8.
+
+### 2. Plus un modèle active de paramètres, mieux il monte en charge
+
+| modèle | solo → 32 sessions |
+|---|---:|
+| Ornith (3 B) | ×10,3 |
+| Qwen3.8-A12B (12,8 B) | ×19,2 |
+| Qwen3.8-27B dense (27 B) | ×28,5 |
+
+Mécanisme : un modèle à faible activation est borné par la bande passante mémoire et laisse les
+unités de calcul oisives ; les requêtes concurrentes viennent les remplir. Un dense, déjà saturé
+en calcul, avait le plus de marge relative à récupérer. Il finit néanmoins **2,3× derrière
+Ornith** à 32 sessions.
+
+### 3. Le coût d'un expert supplémentaire est sous-proportionnel en solo
+
+Sur Kimi-Linear, mêmes poids, seul `num_experts_per_token` change :
+
+| top-k | actifs | solo | coût par rapport à top-8 |
+|---|---:|---:|---|
+| 8 | 3,48 B | 152,2 | — |
+| 11 | 4,04 B | 143,7 | +16 % d'activation pour −5,6 % de débit |
+| 38 | 9,00 B | 95,9 | ×2,6 d'activation pour −37 % |
+| 54 | 11,95 B | 80,7 | ×3,4 d'activation pour −47 % |
+
+**En session unique, monter le nombre d'experts actifs est presque gratuit** — le bon levier pour
+gagner en qualité quand on code seul. À 32 sessions, chaque expert se paie plein tarif.
+
+Anomalie intéressante : **l'A12B bat l'A9B en multi-session** (481 contre 464 à 8 sessions) tout en
+activant 33 % de paramètres en plus. Au-delà d'un certain nombre d'experts actifs, le noyau MoE
+groupe mieux ses calculs. Conséquence pratique : **pour de la qualité en multi-agents, préférer
+l'A12B à l'A9B — le débit est équivalent.**
+
+### 4. La règle « la spéculation ne paie que sur les MoE » est FAUSSE
+
+Énoncée puis démentie par la mesure suivante :
+
+| modèle | effet du n-gram |
+|---|---|
+| Qwen3.8-MoE-A12B | **+183 %** solo |
+| Qwen3.8-27B dense | +11 % solo, **−9 %** à 8 sessions |
+| **Kimi-Linear-48B A3B (un MoE)** | **−77 %** solo, −78 % à 8, −62 % à 32 |
+
+Kimi-Linear est un MoE à 256 experts et perd les trois quarts de son débit. L'explication tient à
+l'**attention linéaire** : chaque jeton met à jour un état récurrent, et rejeter un brouillon
+impose de **restaurer cet état** — bien plus coûteux qu'un retour en arrière dans un cache KV
+classique. La spéculation est structurellement mal adaptée aux modèles à état.
+
+**Réserve sur le +183 % de notre A12B** : son routeur n'a pas été réentraîné après la
+re-partition (moyenne des lignes fusionnées). Un routeur mal calibré produit des sorties
+répétitives, que le n-gram prédit presque parfaitement — ce gain pourrait donc mesurer une
+dégénérescence plutôt qu'une accélération. Le banc ne contrôlait pas la qualité du texte : lacune
+de méthode, corrigée par un contrôle de répétitivité (proportion de 4-grammes distincts).
+
+## Les modèles Kimi : ce qui existe vraiment
+
+| dépôt | verdict |
+|---|---|
+| `moonshotai/Kimi-K3` (1 561 Go) | inhébergeable : 49 Go de VRAM, 200 Go de disque |
+| `ubicloud/Kimi-K3-Pruned-35B` / `-65B` | **leurres** : 2 et 3 couches sur 93, maquettes de pipeline |
+| `lovedheart/Kimi-K3-Lite` (1 561 Go) | socle de 21,29 B — A4B/A9B/A12B tous impossibles |
+| `Inferact/Kimi-K3-DSpark`, `modal-labs/Kimi-K3-DFlash` | brouillons de spéculation **pour K3 uniquement** |
+| **`cyankiwi/Kimi-Linear-48B-A3B-Instruct-AWQ-4bit`** | **30,5 Go, réel, complet — le meilleur du banc** |
+
+Un brouillon de spéculation doit partager le vocabulaire exact, la géométrie et la disposition de
+cache de sa cible. Kimi-K3-DSpark (vocab 163 840, dimension 7 168, MLA) ne peut rien proposer à
+Qwen3.8 (vocab 248 320, dimension 5 120) : les identifiants de jetons ne désignent même pas les
+mêmes mots. Et son chiffre phare — 464 tok/s — est obtenu sur **4× GB300 en tensor-parallel 16**.
+
+## Fabriquer les variantes Kimi : une ligne de configuration
+
+Contrairement à Qwen3.8, où le socle de 9,78 B rend A4B et A9B arithmétiquement impossibles, le
+socle de Kimi-Linear ne fait que **1,83 B** :
+
+| composant | taille |
+|---|---:|
+| experts routés (256) | 47,110 B |
+| attention pleine | 0,994 B |
+| embeddings (163 840 × 2 304) | 0,755 B |
+| expert partagé | 0,184 B |
+| normes + routeur | 0,079 B |
+| **socle** | **1,828 B** |
+| **par expert** | **0,184 B** |
+
+D'où : actifs = 1,828 + 0,184 + k × 0,184. Les trois cibles s'obtiennent en changeant
+`num_experts_per_token` (11, 38, 54 sur 256), poids partagés par liens durs — les quatre
+configurations occupent 30 Go au total.
+
+## Pièges rencontrés
+
+- **`max_num_seqs` est plafonné par le cache Mamba, pas par la VRAM.** Sur un hybride,
+  chaque séquence en décodage réserve un bloc d'état :
+  `ValueError: max_num_seqs (256) exceeds available Mamba cache blocks (251)`. Cela empêche la
+  capture des graphes CUDA, dont on sait qu'elle vaut un facteur 6. Borner explicitement.
+- **`ninja` est une dépendance cachée** des modèles à attention linéaire : leurs noyaux se
+  compilent à la volée. Sans lui dans le `PATH`, `EngineCore` meurt sur un message qui masque le
+  vrai `FileNotFoundError` quinze lignes plus haut.
+- **Le tokeniseur de Kimi-Linear** importe `bytes_to_unicode` depuis
+  `transformers.models.gpt2.tokenization_gpt2`, d'où la fonction a disparu ; elle vit désormais
+  dans `transformers.convert_slow_tokenizer`. Corrigé avec repli sur l'ancien chemin.
+- **Écrire un `.sh` avec Python sous Windows** produit des CRLF que bash refuse. Utiliser
+  `newline="\n"` et valider par `bash -n`.
+
+## Ce que cela implique
+
+**Le modèle servi aujourd'hui n'est pas le meilleur disponible.** Ornith était le choix par défaut
+depuis plusieurs sessions ; Kimi-Linear-48B-A3B fait mieux sur tous les axes mesurés — +13 % en
+solo, +17 % à 32 sessions, latence de 1,3 s, démarrage deux fois plus rapide — pour un contexte à
+peine inférieur (866 k contre 958 k). Il offre en prime un réglage qualité/vitesse par simple
+ligne de configuration.
+
+Réserve honnête : **ce banc mesure le débit, pas la qualité des réponses.** Kimi-Linear est de la
+génération Kimi 2, et aucune évaluation comparative de qualité n'a été faite ici.

reports/README.md

@@ -14,6 +14,8 @@ en a conclu, pour ne pas le refaire.
 | 2026-08-23 | `2026-08-23-l4-graphes-cuda-et-multi-modeles.md` | L4 : 12,4 → 75,7 tok/s en activant les graphes CUDA (×6) ; rendement par Go/s vs notre TP=2 ; Kimi-K3 / Qwen3.8 déjà servis par le bootstrap ; TRT-LLM impasse confirmée |
 | 2026-08-23 | `2026-08-23-tensorrt-et-onnx-mesures.md` | TRT-LLM **impasse fermée** (INT4 et FP8, sur L40S et sur Ada) ; graphe ONNX réparé et fonctionnel (126,9 tok/s L40S) ; baseline L4 corrigée 13→76 ; MTP à 29 % d’acceptation même en FP8 |
 | 2026-08-23 | `2026-08-23-mxfp4-deblocage-trtllm-et-familles-moe.md` | **TRT-LLM : le noyau MoE 4 bits est reserve a sm90** — aucun chemin MoE quantifie sur Ada (2 correctifs Python ecrits, valables sur Hopper) ; l'EP TensorRT existe bien dans onnxruntime-gpu 1.29 ; **ONNX GenAI 163,2 tok/s sur Ada, devant vLLM** ; planchers reels Qwen3.8 (10,79 B) et Kimi K3 (21,29 B) : A4B et A9B impossibles |
-
+
+| 2026-08-23 | `2026-08-23-banc-quatre-modeles-ada.md` | **Kimi-Linear-48B bat Ornith sur tous les axes** (152 solo, 1 610 a 32) ; le debit suit l'activation ; variantes A4B/A9B/A12B par une ligne de config ; la regle « la speculation ne paie que sur les MoE » demontree FAUSSE (-77 % sur Kimi) |
+
 Convention : `AAAA-MM-JJ-sujet.md`, français, sources en URL, « non trouvé » explicite, et une
 section finale « ce que nous en avons fait » quand c'est appliqué.