verdict TRT-LLM : noyau MoE 4 bits reserve a sm90

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

@@ -1,166 +1,270 @@
-# MXFP4 débloque TensorRT-LLM, et le plancher des familles MoE (23/08/2026, nuit 2)
-
-Deux questions tranchées, toutes deux par de la lecture de code et de l'arithmétique vérifiable
-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.
-
-## 1. Le mur TensorRT-LLM : trois formats, une seule issue
-
-Le mode de quantification `536`, longtemps opaque, se décode depuis `QuantMode` :
-
-```
-536 = FP8_ROWWISE (512) + PER_TOKEN (16) + PER_CHANNEL (8)
-```
-
-Le FP8 officiel d'Ornith est donc du **FP8 dynamique** (poids par canal, activations par jeton).
-Or `CutlassFusedMoE._get_quant_method()` ne connaît que ces méthodes MoE :
-
-| condition | méthode |
-|---|---|
-| `has_fp8_qdq()` | `FP8QDQFusedMoEMethod` |
-| `has_fp8_block_scales()` | `DeepSeekFP8BlockScalesFusedMoEMethod` |
-| `has_nvfp4()` | `NVFP4CutlassFusedMoEMethod` |
-| `is_int4_weight_only_per_group()` | `WInt4AFP8FusedMoEMethod` (**chemin W4A8**) |
-| **`has_w4a16_mxfp4()`** | **`WFP4A16FusedMoEMethod`** |
-| `has_w4a8_mxfp4_*()`, `has_mxfp8()` | méthodes MXFP4 / MXFP8 |
-| sinon | `raise ValueError("Unsupported quantization mode")` |
-
-D'où les deux échecs constatés : l'INT4 groupwise tombe sur la méthode **W4A8**, qui déréférence
-un `input_scale` absent du checkpoint (`'NoneType' object has no attribute 'device'`), et le FP8
-rowwise ne correspond à aucune entrée (`mode [536]`).
-
-### La sortie : MXFP4
-
-`ModelConfig.get_mxfp4_quant_algo()` décide selon la carte :
-
-```python
-if get_sm_version() >= 100:            # Blackwell
-    return QuantAlgo.W4A8_MXFP4_MXFP8  # (ou _FP8 avec le backend TRITON)
-else:                                  # Ada sm89 = notre cas
-    return QuantAlgo.W4A16_MXFP4
-```
-
-Et `load_hf_quant_config()` accepte un checkpoint HF déclarant `quant_method: "mxfp4"`. Donc
-**sur sm89, un checkpoint MXFP4 route vers `WFP4A16FusedMoEMethod`, qui est implémentée**.
-`compressed-tensors` fournit le préréglage `MXFP4A16`, ce qui rend la production du checkpoint
-immédiate avec `llmcompressor`.
-
-**Conséquence : le verdict « TRT-LLM ne peut pas servir nos MoE » était vrai des formats que nous
-avions, pas du moteur.** Il ne manquait pas un opérateur custom, il manquait le bon format d'entrée.
-
-### Le dense charge, lui
-
-`Qwen/Qwen3.8-27B-FP8` est en `fp8` **block-scales** (`weight_block_size: [128,128]`), chemin
-supporté. Il a chargé sans erreur de quantification et n'a échoué que sur un `cudaMalloc out of
-memory` : 27 Go de poids sur une carte de 49 Go, cache KV non borné. Correction :
-`KvCacheConfig(free_gpu_memory_fraction=0.25)` et `max_seq_len=4096`.
-
-## 2. ONNX Runtime + TensorRT : l'EP existait, la bibliothèque manquait
-
-Le rapport du 23/08 concluait « EP absent de la build ». C'était vrai de la roue
-**`onnxruntime-genai-cuda`**, et faux de **`onnxruntime-gpu` 1.29.0**, qui annonce :
-
-```
-['TensorrtExecutionProvider', 'CUDAExecutionProvider', 'CPUExecutionProvider']
-```
-
-L'EP échouait seulement à charger `libnvinfer.so.10`, TensorRT n'étant pas installé sur le pod.
-Piège de version : `tensorrt-cu13-libs` fournit `libnvinfer.so.**11**` ; ORT 1.29 exige la **10**,
-qui vient de `tensorrt-cu12-libs==10.*`.
-
-## 3. ONNX GenAI sur Ada : 163,2 tok/s, devant vLLM
-
-Le graphe réparé (`model_fixed3.onnx`) mesuré sur la RTX 6000 Ada :
-
-| moteur, même carte, solo | débit |
-|---|---:|
-| vLLM (Ornith INT4) | 134,1 tok/s |
-| **ONNX Runtime GenAI (CUDA EP)** | **163,2 tok/s** |
-| ONNX GenAI sur L40S (pour mémoire) | 126,9 tok/s |
-
-Texte français correct et cohérent. **Réserve essentielle** : ORT GenAI n'a pas de traitement
-continu par lots — ces 163 tok/s sont un débit *mono-session*, sans équivalent agrégé
-multi-agents. La piste reste « edge / session unique », mais elle y bat vLLM.
-
-Piège : `libcufft.so.12` manquait au chemin alors qu'il est présent dans
-`site-packages/nvidia/cu13/lib` du venv — un simple `LD_LIBRARY_PATH`.
-
-## 4. Le plancher des variantes MoE demandées
-
-La question « faire un A4B / A9B / A12B » se tranche avant tout essai, en calculant le **socle
-incompressible** : les paramètres actifs à chaque jeton quoi qu'on fasse aux experts.
-
-**Erreur de méthode commise puis corrigée** : une première estimation appliquait la formule de
-l'attention classique aux 64 couches, donnant un socle de 7,24 B. Qwen3.8 est **hybride** —
-48 couches d'attention linéaire, 16 pleines, avec porte de sortie (`attn_output_gate: true`).
-Les tailles réelles, lues sur les formes des tenseurs :
-
-| composant | taille |
-|---|---:|
-| experts routés (16 × 1024) | 16,106 B |
-| **attention linéaire (48 couches)** | **5,562 B** |
-| embeddings (248 320 × 5 120, non liés) | 2,543 B |
-| attention pleine (16 couches) | 1,678 B |
-| expert partagé | 1,007 B |
-| routeur | 0,005 B |
-| **socle** | **9,78 B** |
-
-Avec l'expert partagé, le **plancher absolu** — zéro expert routé — est de **10,79 B actifs**.
-
-| granularité | top-k | actifs/jeton |
-|---|---|---:|
-| 64 × 256 (dépôt parent) | 2 | 11,29 B |
-| 64 × 256 | 5 | **12,05 B** (le plus proche de 12 B) |
-| 16 × 1024 | 2 | 12,80 B |
-| 16 × 1024 | 4 | 14,81 B |
-
-**A4B et A9B sont donc impossibles pour cette famille** : ils sont sous le plancher.
-Le seul levier serait d'amputer l'attention linéaire (5,56 B) ou les embeddings (2,54 B), ce qui
-demande une distillation et ne serait plus le même modèle.
-
-**Correction d'un chiffre que j'avais publié** : `patdev/Qwen3.8-27B-MoE-A12B-L4` fait
-**11,29 B actifs** (64 × 256, top-2), pas 8,75 B comme je l'avais d'abord calculé. Son README
-annonçant « ~12,2 B » était à peu près juste.
-
-### Kimi K3
-
-| composant | valeur |
-|---|---:|
-| attention (96 têtes × 74, 93 couches) | 18,94 B |
-| embeddings | 2,35 B |
-| **socle** | **21,29 B** |
-| actif/jeton actuel (top-16 sur 320 experts) | 119,6 B |
-| poids de `lovedheart/Kimi-K3-Lite` | **1 561 Go** |
-
-**Les trois cibles Kimi sont impossibles, A12B comprise** : le socle fait 21,29 B avant qu'un seul
-expert ne s'active. Et matériellement, 1 561 Go de poids contre 200 Go de disque et 49 Go de VRAM
-interdisent jusqu'au chargement. Aucune quantité de calcul ne change ce constat.
-
-## 5. Ce qui a été fabriqué
-
-| dépôt | actifs/jeton | total | nature |
-|---|---:|---:|---|
-| `patdev/Qwen3.8-MoE-27B-A12B` | **12,80 B** | 26,90 B | re-partition **exacte** : 16 experts × 1 024, top-2. Aucun poids modifié — fusion de 4 tranches contiguës du FFN parent. Total conservé. |
-
-Un squelette A4B a été construit puis **supprimé** : il visait 3,96 B, sous le plancher de
-10,79 B, et son découpage de `q_proj` ignorait la porte de sortie (`attn_output_gate`), donc
-produisait des formes fausses. Double invalidité, aucun intérêt à le conserver.
-
-## 6. Pièges opérationnels payés cette nuit
-
-- **`bash /run.sh` ne doit jamais être tué**, quel que soit son PID : `start_pod.sh` l'exécute en
-  `exec` et sshd en est un enfant, donc sa mort redémarre le conteneur. Deux interruptions de
-  service à cause de ça. Ne tuer que `vllm [s]erve`.
-- **Le superviseur du bootstrap ne relance pas un `vllm serve` tué** : la restauration doit être
-  explicite.
-- **`exec $(cat cmd.txt)`** perd les guillemets : `--limit-mm-per-prompt '{"video":0}'` devient
-  invalide et l'endpoint reste mort. Repasser par le bootstrap, qui reconstruit la commande
-  depuis l'environnement.
-- **La garde `if __name__ == '__main__':` est obligatoire** pour TRT-LLM *et* pour `vllm.LLM()` :
-  les deux lancent des processus par spawn qui ré-importent le script. Sans elle, `MPI_ABORT`
-  d'un côté, « attempt to start a new process before bootstrapping » de l'autre. Deux échecs
-  attribués à tort aux moteurs.
-- **Le jeton HF du pod est mort** depuis la rotation qui a suivi la fuite : les envois vers HF et
-  la publication du cache de compilation v73 échouaient silencieusement.
-- **Convertir un modèle en place double l'occupation disque** : supprimer chaque shard source dès
-  qu'il est converti divise le pic par deux et a rendu inutile l'agrandissement du disque.
+# TensorRT-LLM sur Ada : le fond du problème est un noyau Hopper-only (23/08/2026, nuit 2)
+
+Deux questions tranchées, toutes deux par de la lecture de code et de l'arithmétique vérifiable
+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.
+
+## 1. Le mur TensorRT-LLM : trois formats, une seule issue
+
+Le mode de quantification `536`, longtemps opaque, se décode depuis `QuantMode` :
+
+```
+536 = FP8_ROWWISE (512) + PER_TOKEN (16) + PER_CHANNEL (8)
+```
+
+Le FP8 officiel d'Ornith est donc du **FP8 dynamique** (poids par canal, activations par jeton).
+Or `CutlassFusedMoE._get_quant_method()` ne connaît que ces méthodes MoE :
+
+| condition | méthode |
+|---|---|
+| `has_fp8_qdq()` | `FP8QDQFusedMoEMethod` |
+| `has_fp8_block_scales()` | `DeepSeekFP8BlockScalesFusedMoEMethod` |
+| `has_nvfp4()` | `NVFP4CutlassFusedMoEMethod` |
+| `is_int4_weight_only_per_group()` | `WInt4AFP8FusedMoEMethod` (**chemin W4A8**) |
+| **`has_w4a16_mxfp4()`** | **`WFP4A16FusedMoEMethod`** |
+| `has_w4a8_mxfp4_*()`, `has_mxfp8()` | méthodes MXFP4 / MXFP8 |
+| sinon | `raise ValueError("Unsupported quantization mode")` |
+
+D'où les deux échecs constatés : l'INT4 groupwise tombe sur la méthode **W4A8**, qui déréférence
+un `input_scale` absent du checkpoint (`'NoneType' object has no attribute 'device'`), et le FP8
+rowwise ne correspond à aucune entrée (`mode [536]`).
+
+### La sortie : MXFP4
+
+`ModelConfig.get_mxfp4_quant_algo()` décide selon la carte :
+
+```python
+if get_sm_version() >= 100:            # Blackwell
+    return QuantAlgo.W4A8_MXFP4_MXFP8  # (ou _FP8 avec le backend TRITON)
+else:                                  # Ada sm89 = notre cas
+    return QuantAlgo.W4A16_MXFP4
+```
+
+Et `load_hf_quant_config()` accepte un checkpoint HF déclarant `quant_method: "mxfp4"`. Donc
+**sur sm89, un checkpoint MXFP4 route vers `WFP4A16FusedMoEMethod`, qui est implémentée**.
+`compressed-tensors` fournit le préréglage `MXFP4A16`, ce qui rend la production du checkpoint
+immédiate avec `llmcompressor`.
+
+**Conséquence : le verdict « TRT-LLM ne peut pas servir nos MoE » était vrai des formats que nous
+avions, pas du moteur.** Il ne manquait pas un opérateur custom, il manquait le bon format d'entrée.
+
+### Le dense charge, lui
+
+`Qwen/Qwen3.8-27B-FP8` est en `fp8` **block-scales** (`weight_block_size: [128,128]`), chemin
+supporté. Il a chargé sans erreur de quantification et n'a échoué que sur un `cudaMalloc out of
+memory` : 27 Go de poids sur une carte de 49 Go, cache KV non borné. Correction :
+`KvCacheConfig(free_gpu_memory_fraction=0.25)` et `max_seq_len=4096`.
+
+## 2. ONNX Runtime + TensorRT : l'EP existait, la bibliothèque manquait
+
+Le rapport du 23/08 concluait « EP absent de la build ». C'était vrai de la roue
+**`onnxruntime-genai-cuda`**, et faux de **`onnxruntime-gpu` 1.29.0**, qui annonce :
+
+```
+['TensorrtExecutionProvider', 'CUDAExecutionProvider', 'CPUExecutionProvider']
+```
+
+L'EP échouait seulement à charger `libnvinfer.so.10`, TensorRT n'étant pas installé sur le pod.
+Piège de version : `tensorrt-cu13-libs` fournit `libnvinfer.so.**11**` ; ORT 1.29 exige la **10**,
+qui vient de `tensorrt-cu12-libs==10.*`.
+
+## 2 bis. Les deux verrous restants, et leurs correctifs
+
+Ouvrir la voie MXFP4 ne suffisait pas : deux défauts de TRT-LLM 1.3.0rc22 se dressaient encore.
+Tous deux sont du Python — aucun noyau CUDA n'a été nécessaire, contrairement à ce qu'annonçaient
+les sessions précédentes. Publiés dans `patches_trtllm/`.
+
+### a. Le mappage compressed-tensors ignore le MXFP4
+
+`llmcompressor` écrit `quant_method: "compressed-tensors"` avec `format: "mxfp4-pack-quantized"`,
+et TRT-LLM **a** une branche pour ce `quant_method`. Mais
+`update_quant_config_from_compressed_tensors()` ne couvre que trois cas — FP8 par canal, FP8 par
+blocs, NVFP4 (`strategy: "tensor_group"`, groupe 16) — et pas le MXFP4A16 : `strategy: "group"`,
+`group_size: 32`, `input_activations: null`.
+
+Pire, elle exécute `inputs_quant_config["strategy"]` **sans tester la nullité**, donc elle lève un
+`TypeError` avant d'atteindre le moindre test utile. Correctif : garde de nullité, plus une
+branche `num_bits == 4 and type == "float" and strategy == "group" and input_activations is None`
+→ `QuantAlgo.W4A16_MXFP4`.
+
+### b. Le cache mRoPE mélange CPU et GPU
+
+`_prepare_qwen_vl_mrope_config()` construit `deltas` par `torch.cat()` de tenseurs issus des
+paramètres multimodaux — donc du CPU — puis les écrit dans `mrope_position_deltas_cache`, sur GPU :
+
+```
+RuntimeError: Expected all tensors to be on the same device,
+              but got source is on cpu, different from other tensors on cuda:0
+```
+
+Le symptôme remonté est trompeur : le modèle **charge entièrement**, l'exécuteur démarre, et
+l'erreur ne se manifeste qu'à la première génération, sous la forme
+`AssertionError: Sampling failed` dans la boucle d'événements. Correctif : un `.to(device, dtype)`
+avant `index_copy_`.
+
+## 2 ter. L'EP TensorRT d'ONNX Runtime est bien actif
+
+Après installation de `tensorrt-cu12-libs==10.*` :
+
+```
+providers actifs: ['TensorrtExecutionProvider', 'CUDAExecutionProvider', 'CPUExecutionProvider']
+TRT_EP_ACTIF
+```
+
+Le verdict « EP absent de la build », qui tenait depuis trois sessions, ne valait que pour la roue
+`onnxruntime-genai-cuda`. `onnxruntime-gpu` 1.29.0 l'embarque. Piège de version à retenir :
+`tensorrt-cu13-libs` fournit `libnvinfer.so.**11**`, qu'ORT 1.29 ne reconnaît pas — il exige la **10**.
+
+## 2 quater. Verdict final : le noyau MoE 4 bits est réservé à Hopper
+
+Les deux correctifs ci-dessus ont fait leur travail — et c'est justement ce qui rend le résultat
+concluant, puisque toutes les causes d'échec antérieures ont été éliminées une à une.
+
+### Le dense s'exécute, mais échoue sur la qualité et la vitesse
+
+```
+TRTLLM_DENSE 89 jetons en 3.04s = 29.2 tok/s
+TEXTE: 一串string string string string ... 串串串根__sontacs/串/他的__ivr
+```
+
+Le correctif mRoPE débloque bien la génération de bout en bout. Mais la sortie est du **charabia**
+— le chemin FP8 block-scales est numériquement faux pour cette architecture — et 29,2 tok/s
+représentent **4,6× moins que les 134,1 de vLLM** sur la même carte. Doublement disqualifié.
+Ceci reproduit indépendamment, cause de plantage éliminée, l'observation « charge mais sort du
+charabia » d'une session antérieure.
+
+### Le MoE MXFP4 est refusé explicitement
+
+Le correctif de mappage fonctionne : le checkpoint est reconnu, routé vers `W4A16_MXFP4`, puis
+vers `WFP4A16FusedMoEMethod`. Et là :
+
+```
+NotImplementedError: WFP4A16 MoE is unsupported on SM89.
+```
+
+Dans `_torch/modules/fused_moe/quantization.py` :
+
+```python
+if module.sm_version == 90:        # Hopper, et rien d'autre
+    module.interleave = [128 // self.group_size for k_shape in (...)]
+else:
+    raise NotImplementedError(f"WFP4A16 MoE is unsupported on SM{module.sm_version}.")
+```
+
+**Le noyau MoE 4 bits de TRT-LLM n'existe que pour sm90.** `get_mxfp4_quant_algo()` renvoie
+pourtant `W4A16_MXFP4` pour tout `sm < 100` : sur Ada, il désigne donc du code mort.
+
+### Tableau de synthèse : aucun chemin MoE quantifié sur Ada
+
+| format | résultat sur sm89 |
+|---|---|
+| INT4 groupwise (AWQ) | routé vers `WInt4AFP8FusedMoEMethod` (W4A8) → `input_scale` absent |
+| FP8 rowwise (Ornith officiel) | aucune méthode MoE — `Unsupported quantization mode [536]` |
+| **MXFP4 / W4A16** | **noyau réservé à sm90** |
+| FP8 block-scales (dense, pas MoE) | s'exécute, mais charabia et 29,2 tok/s contre 134,1 |
+
+**Conclusion : TensorRT-LLM ne peut pas servir un MoE quantifié sur Ada.** Ce n'est plus une
+question de format — c'est un noyau absent, refusé explicitement. Les deux seules issues sont
+une carte **Hopper (H100/H200, sm90)**, où le chemin MXFP4 devrait fonctionner tel quel avec nos
+deux correctifs, ou l'écriture d'un noyau CUTLASS sm89 avec sa disposition d'entrelacement —
+du vrai CUDA cette fois, pas du Python.
+
+Vu que vLLM délivre 134 tok/s sur cette carte et 1 380 j/s agrégés à 32 sessions, l'effort ne se
+justifierait que si l'on migrait vers du Hopper pour d'autres raisons.
+
+## 3. ONNX GenAI sur Ada : 163,2 tok/s, devant vLLM
+
+Le graphe réparé (`model_fixed3.onnx`) mesuré sur la RTX 6000 Ada :
+
+| moteur, même carte, solo | débit |
+|---|---:|
+| vLLM (Ornith INT4) | 134,1 tok/s |
+| **ONNX Runtime GenAI (CUDA EP)** | **163,2 tok/s** |
+| ONNX GenAI sur L40S (pour mémoire) | 126,9 tok/s |
+
+Texte français correct et cohérent. **Réserve essentielle** : ORT GenAI n'a pas de traitement
+continu par lots — ces 163 tok/s sont un débit *mono-session*, sans équivalent agrégé
+multi-agents. La piste reste « edge / session unique », mais elle y bat vLLM.
+
+Piège : `libcufft.so.12` manquait au chemin alors qu'il est présent dans
+`site-packages/nvidia/cu13/lib` du venv — un simple `LD_LIBRARY_PATH`.
+
+## 4. Le plancher des variantes MoE demandées
+
+La question « faire un A4B / A9B / A12B » se tranche avant tout essai, en calculant le **socle
+incompressible** : les paramètres actifs à chaque jeton quoi qu'on fasse aux experts.
+
+**Erreur de méthode commise puis corrigée** : une première estimation appliquait la formule de
+l'attention classique aux 64 couches, donnant un socle de 7,24 B. Qwen3.8 est **hybride** —
+48 couches d'attention linéaire, 16 pleines, avec porte de sortie (`attn_output_gate: true`).
+Les tailles réelles, lues sur les formes des tenseurs :
+
+| composant | taille |
+|---|---:|
+| experts routés (16 × 1024) | 16,106 B |
+| **attention linéaire (48 couches)** | **5,562 B** |
+| embeddings (248 320 × 5 120, non liés) | 2,543 B |
+| attention pleine (16 couches) | 1,678 B |
+| expert partagé | 1,007 B |
+| routeur | 0,005 B |
+| **socle** | **9,78 B** |
+
+Avec l'expert partagé, le **plancher absolu** — zéro expert routé — est de **10,79 B actifs**.
+
+| granularité | top-k | actifs/jeton |
+|---|---|---:|
+| 64 × 256 (dépôt parent) | 2 | 11,29 B |
+| 64 × 256 | 5 | **12,05 B** (le plus proche de 12 B) |
+| 16 × 1024 | 2 | 12,80 B |
+| 16 × 1024 | 4 | 14,81 B |
+
+**A4B et A9B sont donc impossibles pour cette famille** : ils sont sous le plancher.
+Le seul levier serait d'amputer l'attention linéaire (5,56 B) ou les embeddings (2,54 B), ce qui
+demande une distillation et ne serait plus le même modèle.
+
+**Correction d'un chiffre que j'avais publié** : `patdev/Qwen3.8-27B-MoE-A12B-L4` fait
+**11,29 B actifs** (64 × 256, top-2), pas 8,75 B comme je l'avais d'abord calculé. Son README
+annonçant « ~12,2 B » était à peu près juste.
+
+### Kimi K3
+
+| composant | valeur |
+|---|---:|
+| attention (96 têtes × 74, 93 couches) | 18,94 B |
+| embeddings | 2,35 B |
+| **socle** | **21,29 B** |
+| actif/jeton actuel (top-16 sur 320 experts) | 119,6 B |
+| poids de `lovedheart/Kimi-K3-Lite` | **1 561 Go** |
+
+**Les trois cibles Kimi sont impossibles, A12B comprise** : le socle fait 21,29 B avant qu'un seul
+expert ne s'active. Et matériellement, 1 561 Go de poids contre 200 Go de disque et 49 Go de VRAM
+interdisent jusqu'au chargement. Aucune quantité de calcul ne change ce constat.
+
+## 5. Ce qui a été fabriqué
+
+| dépôt | actifs/jeton | total | nature |
+|---|---:|---:|---|
+| `patdev/Qwen3.8-MoE-27B-A12B` | **12,80 B** | 26,90 B | re-partition **exacte** : 16 experts × 1 024, top-2. Aucun poids modifié — fusion de 4 tranches contiguës du FFN parent. Total conservé. |
+
+Un squelette A4B a été construit puis **supprimé** : il visait 3,96 B, sous le plancher de
+10,79 B, et son découpage de `q_proj` ignorait la porte de sortie (`attn_output_gate`), donc
+produisait des formes fausses. Double invalidité, aucun intérêt à le conserver.
+
+## 6. Pièges opérationnels payés cette nuit
+
+- **`bash /run.sh` ne doit jamais être tué**, quel que soit son PID : `start_pod.sh` l'exécute en
+  `exec` et sshd en est un enfant, donc sa mort redémarre le conteneur. Deux interruptions de
+  service à cause de ça. Ne tuer que `vllm [s]erve`.
+- **Le superviseur du bootstrap ne relance pas un `vllm serve` tué** : la restauration doit être
+  explicite.
+- **`exec $(cat cmd.txt)`** perd les guillemets : `--limit-mm-per-prompt '{"video":0}'` devient
+  invalide et l'endpoint reste mort. Repasser par le bootstrap, qui reconstruit la commande
+  depuis l'environnement.
+- **La garde `if __name__ == '__main__':` est obligatoire** pour TRT-LLM *et* pour `vllm.LLM()` :
+  les deux lancent des processus par spawn qui ré-importent le script. Sans elle, `MPI_ABORT`
+  d'un côté, « attempt to start a new process before bootstrapping » de l'autre. Deux échecs
+  attribués à tort aux moteurs.
+- **Le jeton HF du pod est mort** depuis la rotation qui a suivi la fuite : les envois vers HF et
+  la publication du cache de compilation v73 échouaient silencieusement.
+- **Convertir un modèle en place double l'occupation disque** : supprimer chaque shard source dès
+  qu'il est converti divise le pic par deux et a rendu inutile l'agrandissement du disque.

reports/README.md

@@ -13,7 +13,7 @@ en a conclu, pour ne pas le refaire.
 | 2026-08-23 | `2026-08-23-pont-et-integration-claude-code.md` | Pont sous charge (fuite de connexions), compaction Claude Code (`[1m]`, réponse vide), compteur de jetons en direct, débit solo ressenti |
 | 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` | **MXFP4 debloque TRT-LLM** sur sm89 (`W4A16_MXFP4` -> `WFP4A16FusedMoEMethod`) ; 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-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 |
 
 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é.