corrections : ONNX sans avantage (135,7 vs 134,1), EP TensorRT inaccessible depuis GenAI, A12B degenere

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

@@ -4,6 +4,17 @@ 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.
 
+
+> **AVERTISSEMENT ajouté après coup (23/08, 04:30).** Un contrôle de qualité de sortie
+> (proportion de 4-grammes distincts) donne **0,000 — DÉGÉNÉRÉ** sur
+> `Qwen3.8-MoE-27B-A12B-W4A16` : le modèle produit des points et des retours à la ligne en
+> boucle, pas du texte. **Tous les débits de l'A12B rapportés ci-dessous mesurent donc un modèle
+> qui ne génère rien d'utilisable**, et le gain de +183 % attribué à la spéculation n-gram était
+> un artefact — elle prédisait une répétition infinie, ce qui est trivial. Deux causes sont en
+> cours de départage : la fusion du routeur (moyenne de 4 lignes) et la quantification INT4
+> effectuée **sans données de calibration** (`DataFreePipeline`). La re-partition des experts,
+> elle, a été vérifiée exacte (formes et sommes de poids).
+
 ## Ce que ONNX et TensorRT ne peuvent pas faire ici
 
 La demande initiale était « A12B en ONNX GenAI et en TensorRT, avec plusieurs sessions ».

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

@@ -3,6 +3,30 @@
 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).
 
+
+> **AVERTISSEMENT ajouté après coup (23/08, 04:30).** Un contrôle de qualité de sortie
+> (proportion de 4-grammes distincts) donne **0,000 — DÉGÉNÉRÉ** sur
+> `Qwen3.8-MoE-27B-A12B-W4A16` : le modèle produit des points et des retours à la ligne en
+> boucle, pas du texte. **Tous les débits de l'A12B rapportés ci-dessous mesurent donc un modèle
+> qui ne génère rien d'utilisable**, et le gain de +183 % attribué à la spéculation n-gram était
+> un artefact — elle prédisait une répétition infinie, ce qui est trivial. Deux causes sont en
+> cours de départage : la fusion du routeur (moyenne de 4 lignes) et la quantification INT4
+> effectuée **sans données de calibration** (`DataFreePipeline`). La re-partition des experts,
+> elle, a été vérifiée exacte (formes et sommes de poids).
+
+
+> **CORRECTION (23/08, 04:50).** Le chiffre de **163,2 tok/s** attribué à ONNX GenAI **ne se
+> reproduit pas**. Remesuré dans une exécution contrôlée, rodage exclu du chronomètre, sur la même
+> carte : **135,7 tok/s** (4-grammes distincts 0,949, texte sain) — soit **à égalité avec vLLM**
+> (134,1), et non les +22 % annoncés. La mesure initiale était optimiste. **ONNX GenAI n'a donc
+> aucun avantage de débit sur vLLM**, et reste dépourvu de batching continu.
+>
+> Par ailleurs, l'EP TensorRT est **inaccessible depuis ONNX GenAI** :
+> `RuntimeError: Unknown provider name 'tensorrt'` — la roue GenAI ne connaît que DML, QNN,
+> OpenVINO, SNPE... L'EP fonctionne bien dans `onnxruntime-gpu` classique (`TRT_EP_ACTIF`), mais
+> celui-ci n'a pas de boucle de génération : il faudrait écrire la gestion du cache KV à la main,
+> pour un graphe que TensorRT fragmenterait de toute façon (601 nœuds `com.microsoft` sur 1 976).
+
 ## Le tableau d'ensemble
 
 | modèle | actifs/jeton | solo | 8 sessions | 32 sessions | cache KV | démarrage |

reports/2026-08-23-mxfp4-deblocage-trtllm-et-familles-moe.md

@@ -4,6 +4,19 @@ Deux questions tranchées, toutes deux par de la lecture de code et de l'arithm
 plutôt que par des essais successifs : **pourquoi TensorRT-LLM refusait nos modèles**, et
 **quelles variantes MoE sont réellement fabricables** à partir de Qwen3.8 et de Kimi K3.
 
+
+> **CORRECTION (23/08, 04:50).** Le chiffre de **163,2 tok/s** attribué à ONNX GenAI **ne se
+> reproduit pas**. Remesuré dans une exécution contrôlée, rodage exclu du chronomètre, sur la même
+> carte : **135,7 tok/s** (4-grammes distincts 0,949, texte sain) — soit **à égalité avec vLLM**
+> (134,1), et non les +22 % annoncés. La mesure initiale était optimiste. **ONNX GenAI n'a donc
+> aucun avantage de débit sur vLLM**, et reste dépourvu de batching continu.
+>
+> Par ailleurs, l'EP TensorRT est **inaccessible depuis ONNX GenAI** :
+> `RuntimeError: Unknown provider name 'tensorrt'` — la roue GenAI ne connaît que DML, QNN,
+> OpenVINO, SNPE... L'EP fonctionne bien dans `onnxruntime-gpu` classique (`TRT_EP_ACTIF`), mais
+> celui-ci n'a pas de boucle de génération : il faudrait écrire la gestion du cache KV à la main,
+> pour un graphe que TensorRT fragmenterait de toute façon (601 nœuds `com.microsoft` sur 1 976).
+
 ## 1. Le mur TensorRT-LLM : trois formats, une seule issue
 
 Le mode de quantification `536`, longtemps opaque, se décode depuis `QuantMode` :