Upload RESULTS.md with huggingface_hub

RESULTS.md

@@ -528,3 +528,45 @@ disqualifié par ses 24 Go, qui ne laissent presque rien au KV.
 
 Une cible de 200 tok/s par session à 8 sessions n'est atteignable que sur A100
 SXM (~190 tok/s attendus, extrapolés de la bande passante — non mesurés).
+
+---
+
+# L'élagage des experts ne donne rien — et ce que ça révèle
+
+Hypothèse testée : à forte concurrence tous les experts finissent par être lus à
+chaque pas, donc c'est la taille **totale** du modèle qui borne le débit, pas les
+3 B actifs. Réduire la taille devrait donc augmenter le débit proportionnellement.
+
+`mattbucci/Qwen3-Coder-REAP-25B-A3B-AWQ` : 103 experts au lieu de 128,
+**12,9 Gio au lieu de 16,9** (−24 %). Gain attendu ~1,31×.
+
+```
+sessions    30B complet (16,9 Gio)   REAP-25B (12,9 Gio)
+   1            122,9                    124,9
+   8            512,1                    511,8
+  32          1 159,7                  1 171,6
+```
+
+**Identique au bruit près.** L'hypothèse est réfutée : le débit n'est pas borné
+par la lecture des poids.
+
+## Ce que le mur n'est pas
+
+```
+lecture des poids   -24 % de poids -> 0 % de debit        refute
+calcul brut         1171 tok/s x 3 G x 2 = ~7 TFLOPS
+                    sur ~150 TFLOPS disponibles = 5 %     ecarte
+ordonnancement CPU  --async-scheduling : dans le bruit    refute
+speculation         perdante a n=24 ET a n=4              refute
+```
+
+Il reste **l'efficacité des kernels MoE** : la dispersion des tokens vers 128
+experts, avec très peu de lignes par expert et par pas. C'est un mur
+d'implémentation, pas de matériel — ce qui explique d'un coup pourquoi aucun des
+quatre leviers testés n'a bougé le débit.
+
+## Décision
+
+Le modèle non élagué est conservé : le REAP coûte 20 % des experts pour zéro
+gain mesuré, donc de la qualité perdue sans contrepartie. Il reste disponible
+(`VL_MODEL=reap`) au cas où les 4 Go de VRAM libérés seraient utiles au KV.