# Résultats mesurés — Kimi-K3, Kimi-Linear, Qwen3-Coder sur A40 Toutes les valeurs ci-dessous sont **mesurées**, jamais estimées, sauf mention explicite. Le coût au million est calculé depuis le tarif horaire RunPod et le débit mesuré. Protocole commun : `bench_endpoint.sh`, publié à côté. ## Synthèse | | Kimi-K3 REAP448 | Kimi-Linear 48B | Qwen3-Coder-30B | |---|---|---|---| | moteur | llama.cpp | vLLM 0.27.1 | vLLM 0.27.1 | | matériel | 5× A40 | **1× A40** | **1× A40** | | $/h | 2,20 | 0,44 | 0,44 | | decode 1 flux | 7,29 tok/s | 67–71 tok/s | **77,6–130 tok/s** | | agrégé 32 flux | ~14,5 (4 flux) | 780 tok/s | **1 166 tok/s** | | prefill à froid | ~165 tok/s | **6 162 tok/s** | 3 957 tok/s | | prefill à chaud | ~cache OK | 6 430 (pas de cache) | **63 315 tok/s** | | contexte | 524 288 | **1 048 576** | 262 144 | | $/1M à 32 flux | ~85 (1 flux) | 0,157 | **0,105** | | français | cassé | fluide | correct | | tool calling | — | oui (`kimi_k2`) | oui (`qwen3_coder`) | ## Kimi-K3 sur llama.cpp — la progression complète ``` Colibri CUDA custom, L40S 2,32 tok/s point de depart llama.cpp 2x A40, apres corrections 2,94 llama.cpp 5x A40, placement identique 5,44 <- effet vCPU (16 -> 41) llama.cpp 5x A40, tout en VRAM 7,35 idem sur 600 tokens reels 7,22 idem contexte 262 144 7,25 idem contexte 524 288 7,29 <- plafond idem contexte 1 048 576 OOM (29 Gio de KV f16) ``` Le débit est **plat sur 32× de contexte** : c'est la géométrie KDA+MLA qui le permet (24 couches sur 93 mettent en cache, les 69 autres portent un état récurrent de taille constante). 16 384 n'était pas une limite matérielle, juste un défaut jamais testé. ### Ce qui bornait vraiment le débit Six placements couvrant 60 à 88 Go de VRAM n'avaient rien changé. La cause n'est ni le kernel ni la bande passante : ``` 1 flux 5,56 tok/s agrege 2 flux 9,85 tok/s 1,77x 4 flux 14,53 tok/s 2,61x ``` La concurrence monte, donc le matériel était **inactif** entre les tokens : llama.cpp répartit les couches entre GPU et les exécute en séquence, un seul calcule à la fois. Confirmation arithmétique indépendante : ~7 Go lus par token à 138 ms = **51 Go/s contre 696 disponibles**, soit 7 % du plafond. ### Six hypothèses réfutées par la mesure | hypothèse | ce qui la tue | |---|---| | le modèle est cassé | Tokyo/Washington/Stockholm corrects, récursion Fibonacci correcte, chinois fluide | | le calcul CPU des experts domine | 16 → 8 experts ne donne que **+28 %** | | les traversées CPU↔GPU dominent | autofit (1–2) ≈ n-cpu-moe 86 (172) | | le kernel MoE est le goulot | fused SiTU **0 %**, warp-row **+1,2 %** | | on est borné par la bande passante | 7 % du plafond mesuré | | le code généré est cassé | test direct correct ; le prompt du selftest était ambigu | ### DSpark : zéro gain, zéro télémétrie ``` avec speculation 7,32 / 7,33 tok/s aucune metrique draft_n sans speculation 7,33 / 7,35 tok/s ``` Le mécanisme n'était pas cassé, le moteur l'était : la même idée sous vLLM donne +86 % avec 68 % d'acceptation et une télémétrie complète. ## Kimi-Linear 48B — 1M de contexte sur une seule carte ``` 27 couches = 7 MLA + 20 KDA KV/token = 7 x (512+64) x 2 = 7,88 Ko (Kimi-K3 : 24 couches -> 27,6 Ko) poids AWQ4 28,4 Gio + 7,88 Gio de KV a 1M = 36,3 Go sur une carte de 46 ``` vLLM le confirme au démarrage : **`GPU KV cache size: 1 416 566 tokens`**. ``` flux agrege /flux $/1M 1 67,4 67,4 1,814 4 206,6 51,6 0,592 8 352,4 44,0 0,347 16 556,1 34,8 0,220 32 779,9 24,4 0,157 ``` ### La spéculation n-gram y est cassée L'échantillonnage par rejet est censé être **sans perte** : toute différence de sortie est un bug. Elle corrompt le code, de façon reproductible : ``` avec speculation sans add() return a -b):\n return a - return a - b\n\ndef multiply(a, fibonacci fibonacci(n-1(n-1) + fibonacci(n-2) fibonacci(n-1) + fibonacci(n-2) ``` Signature : un fragment tout juste émis, recollé au mauvais endroit. La prose et la copie littérale restent parfaites — c'est pourquoi il a fallu des sondes ciblées : le code est dense en répétitions courtes (parenthèses, opérateurs) sur lesquelles le n-gram s'accroche. Elle est en plus **3 à 4× plus lente**, vLLM désactivant les CUDA graphs sous spéculation sur `TritonMLABackend` : ``` flux avec spec sans spec rapport 1 23,1 71,2 3,1x 4 58,7 249,6 4,3x 32 203,9 781,0 3,8x $/1M a 32 0,600 0,157 ``` ## Qwen3-Coder-30B — le meilleur compromis pour Claude Code ``` flux agrege /flux $/1M 1 77,6 77,6 1,575 4 265,3 66,3 0,461 8 496,8 62,1 0,246 16 782,4 48,9 0,156 32 1 165,6 36,4 0,105 prefill 38 494 tok a froid en 10,42 s = 3 693 tok/s ; a chaud 1,07 s = 63 315 decode a 119k de contexte : 34,3 tok/s ``` ### La spéculation dépend du régime Deux pods identiques tournant **simultanément**, pour éliminer la dérive d'hôte : ``` A. generation pure (aucun recouvrement) 102,21 -> 58,49 tok/s -43 % B. edition de code (la sortie reprend) 130,16 -> 242,39 tok/s +86 % ``` Ce n'est pas un gain gratuit, c'est un **pari sur la répétition**. Claude Code vit entièrement dans le régime B. Télémétrie : 706 acceptés sur 1035 = 68,2 %, par position 179/156/131/120/120, longueur acceptée moyenne 3,41. Mais elle **s'effondre sous concurrence**, car vLLM rabaisse `max_num_scheduled_tokens` à 2048 : ``` 1 flux 4 8 16 32 sans speculation 77,6 265,3 496,8 782,4 1165,6 avec speculation 79,2 110,1 154,4 271,2 296,1 ``` ## Comparaison externe ``` API Kimi-K3 officielle (RunPod) 29,2 tok/s ~16 $/1M pleine precision notre Kimi-K3 auto-heberge 7,3 tok/s ~85 $/1M 1,14 bit/poids notre Qwen3-Coder-30B 77,6 tok/s 0,105-1,58 4 bits ``` L'auto-hébergement de Kimi-K3 sur A40 est dominé sur tous les axes. Il n'achète ni le prix ni la qualité — il achète la confidentialité et le contrôle du contexte. ### Travaux antérieurs (dépôt Kimi-K3-L4-GenAI-TurboQuant, 8 août 2026, 1× L4) ``` vLLM AWQ Qwen3.5-9B + LoRA K3 + MTP-1 32,320 tok/s 485/533 = 90,99 % ORT GenAI CUDA INT4 30,271 vLLM AWQ + LoRA K3, sans speculation 22,674 OpenVINO INT4 g128, 8 threads (CPU) 5,029 ``` Cette lignée concluait déjà que **vLLM + AWQ est la bonne pile**. Le chemin suivi ici y arrive indépendamment, en mesurant la sérialisation de llama.cpp. Le benchmark TurboQuant MLA du même dépôt confirme par un chemin totalement indépendant la dérivation faite ici : 4 718 592 octets/couche pour 4096 tokens = 1152 octets/token/couche × 24 couches = **27,6 Ko/token**, exactement la valeur calculée depuis `config.json`. En TQ4 : compression 3,945×, **6,844 Gio pour 1M tokens sur 24 couches** — de quoi mettre Kimi-K3 à 1M dans les ~25 Go restés libres, si l'implémentation existait ailleurs que dans une opération ONNX compilée en sm_89. ## Aucune donnée sur Qwen3-Coder-Next 80B Trois tentatives, trois échecs d'infrastructure, zéro requête servie. ``` 1 bloque 22 min a l'init NCCL peer-to-peer sur 2x A40 2 NCCL_P2P_DISABLE=1 leve ce blocage, puis boucle ~10 min sur "No available shared memory broadcast block found in 60 seconds" 3 --enforce-eager passe la compilation et charge les poids (23,23 Gio/GPU) et le KV (16,23 Gio/GPU), puis rebloque au meme endroit ``` `NCCL_P2P_DISABLE=1` est **nécessaire** au tensor parallelism sur une paire d'A40 RunPod. Le second blocage reste non diagnostiqué ; le suspect est `VLLM_WORKER_MULTIPROC_METHOD=spawn`, que j'avais introduit en même temps que le correctif NCCL — deux variables changées d'un coup, ce qui était une erreur de méthode. Son log de démarrage a tout de même livré un point dur : `enable_prefix_caching=False`, la même limitation hybride que Kimi-Linear. ## Limites d'exploitation mesurées - **Proxy RunPod : coupure à ~125 s** (Cloudflare `524`). Un prefill à froid plus long ne passe pas en un appel — mesuré à ~40k tokens sur Kimi-K3 et ~232k sur Qwen. Parade : découper, chaque requête étendant le préfixe caché. - **Prefill de Kimi-K3, dégradation douce** : 228,6 → 149,8 tok/s de 8k à 43k de contexte, soit −34 % pour 5× le contexte. Bien mieux que quadratique, puisque seules 24 des 93 couches ont une attention complète. - **`--gpu-memory-utilization 0.93` fait échouer Kimi-Linear** au tout dernier pas, dans le rejection sampler qui réclame 160 Mio quand il en reste 143. 0,90 laisse la marge et conserve plus d'1M de tokens de KV. --- # Optimisation vers 500 tok/s — endpoint Anthropic, 1× A40 ## Le résultat ``` edition de code, mono-flux, via /v1/completions (6 essais consecutifs) 555,96 598,49 579,65 567,95 575,66 570,69 tok/s moyenne 574,7 via /v1/messages, protocole Anthropic (le chemin de Claude Code) 504,94 563,26 565,83 tok/s non streame 578,00 tok/s streame ``` Tous au-dessus de 500, y compris à travers le pont. Le coût tombe à **0,21 $ / 1M de tokens en mono-flux** sur une carte à 0,44 $/h. ## Le levier, et l'indicateur trompeur ``` profondeur debit acceptation longueur acceptee n=5 259,2 tok/s 68,2 % 3,41 n=12 363,9 tok/s 26,9 % 3,23 n=24 574,7 tok/s 71,5 % 17,16 ``` **Le taux d'acceptation n'est pas la métrique utile.** Il chute de 68 % à 27 % entre n=5 et n=12 pendant que le débit monte de 40 % : ce qui compte est le nombre de tokens émis *par passe avant*, pas la fraction acceptée. Suivre le taux d'acceptation aurait conduit à conclure que n=12 était une régression. Le signal exploitable était la **queue par position** : à n=12 elle restait plate (257/118/82/72/71/63/61/59/59/58/58/51), donc le 12ᵉ token deviné était encore accepté ~20 % du temps — la profondeur n'était pas saturée. À n=24, la longueur acceptée moyenne atteint **17,16 tokens**, parce qu'en édition de code la sortie est largement prédictible depuis le prompt. Aucun motif de corruption détecté à n=24 sur Qwen, et les annotations de type sont correctement appliquées. ## L'autre levier : `max-num-batched-tokens` vLLM le rabaisse à 2048 dès que la spéculation est active, et prévient lui-même que c'est sous-optimal. Le corriger à 16384 récupère une partie de l'effondrement en concurrence : ``` flux 1 4 8 16 32 sans speculation 77,6 265,3 496,8 782,4 1165,6 spec n=5 79,2 110,1 154,4 271,2 296,1 spec n=12 + 16384 93,3 186,9 278,4 297,2 336,9 ``` ## Le compromis à assumer La spéculation **gagne en mono-flux et perd en agrégé** : les brouillons consomment le budget de batch. Il n'existe pas de réglage qui gagne partout. ``` un seul utilisateur (Claude Code) speculation n=24 -> 575 tok/s, 0,21 $/1M service multi-utilisateurs speculation OFF -> 1166 tok/s a 32 flux, 0,105 $/1M ``` Les deux franchissent 500 tok/s sur une seule A40, par des chemins opposés. Le défaut du dépôt est la spéculation, puisque la cible visée est Claude Code. ## Le plafond physique, et pourquoi il est dépassé ``` poids actifs lus par token ~4,7 Go / 696 Go/s = 6,8 ms plafond mono-flux SANS speculation ~147 tok/s theorique, ~130 mesure ``` 575 tok/s en mono-flux dépasse ce plafond d'un facteur 4,4 — ce qui n'est possible que parce que la spéculation émet plusieurs tokens par lecture des poids. Sans elle, aucun réglage ne peut approcher 500 en mono-flux sur cette carte. --- # CORRECTION — le cache de préfixe fonctionne sur Kimi-Linear Une section plus haut affirme que Kimi-Linear n'a pas de cache de préfixe, sur la base d'un rapport froid/chaud de 1,04×. **C'était une erreur de configuration de ma part, pas une limite du modèle** : le pod concerné ne passait pas `--enable-prefix-caching`. Avec le flag explicite, sur la même carte : ``` sans le flag avec le flag prefill a froid 6 162 tok/s 7 647 tok/s prefill a chaud 6 430 tok/s 36 257 tok/s rapport 1,04x 4,74x ``` Conséquence pour un client agent : un prompt système de 32k **est** mis en cache sur Kimi-Linear. L'argument qui le disqualifiait pour Claude Code tombe. ## Kimi-Linear, mesures définitives (pod persistant, flags corrects) ``` flux 1 4 8 16 32 agrege 83,9 250,6 402,9 616,4 772,4 tok/s $/1M 1,457 0,488 0,303 0,198 0,158 prefill froid 7 647 tok/s (Qwen : 4 485) prefill chaud 36 257 tok/s (Qwen : 70 568) edition de code 100,5 tok/s (Qwen : 575) contexte 1 048 576 KV 1 505 550 tokens protocole Anthropic : les 5 controles passent ``` Kimi-Linear franchit 500 tok/s **en agrégé dès 16 flux** (616,4). Qwen les franchit **en mono-flux** (575). Les deux tiennent la cible sur une seule A40, par des chemins différents : la spéculation pour Qwen, la concurrence pour Kimi — chez qui la spéculation reste inutilisable puisqu'elle corrompt le code. ## Choix recommandé | besoin | modèle | pourquoi | |---|---|---| | Claude Code, un utilisateur | **Qwen3-Coder-30B** | 575 tok/s en édition de code, cache de préfixe 16×, 0,21 $/1M | | contexte au-delà de 262k | **Kimi-Linear-48B** | 1 048 576 tokens sur une carte, prefill à froid 1,7× meilleur | | service multi-utilisateurs | Qwen sans spéculation | 1 166 tok/s à 32 flux, 0,105 $/1M | --- # Endurance agentique — 553 tours de codage en boucle Un pic à 575 tok/s sur 900 tokens ne dit rien de la tenue sur une session. Test simulant le régime réel de Claude Code : prompt système volumineux, tours successifs avec résultats d'outils réinjectés, sorties de code, contexte qui gonfle puis se compacte. ``` 553 tours 387 100 tokens emis contexte 2 484 -> 35 352 debit soutenu 268,2 tok/s 0,456 $ / 1M par tour min 108 mediane 330 max 453 premier tiers 301,0 tok/s dernier tiers 304,6 tok/s <- aucune derive ``` **Le débit ne se dégrade pas sur la durée.** La variation par tour suit le cycle du cache de préfixe, pas une fatigue du serveur. ## Le compactage de l'historique décide de la moitié du débit Première version du test : retirer les deux plus anciens messages **à chaque tour** dès que l'historique dépasse une taille. Le préfixe change donc à chaque requête, le cache est invalidé en permanence : ``` elagage tour par tour 173,8 tok/s soutenus compactage par blocs 268,2 tok/s soutenus +54 % ``` Visible dans le journal au tour 127 : le compactage retire 32 messages, le contexte retombe de 35k à 19k, le tour suivant tombe à 165 tok/s le temps que le cache se reconstruise, puis remonte immédiatement à 360-410. **Un compactage rare et massif coûte un tour. Un élagage permanent coûte la moitié du débit.** Cela vaut pour tout client agent qui gère une fenêtre. ## Les trois régimes, à ne pas confondre ``` pic, 900 tokens, contexte court 575 tok/s 0,21 $/1M tour isole a 20k de contexte 421 tok/s session soutenue, compactage compris 268 tok/s 0,46 $/1M ``` Le troisième est celui qui décrit un usage réel. C'est lui qu'il faut citer pour dimensionner, et non le premier. --- # Plusieurs sessions Claude Code simultanées Deux mécanismes indépendants, qui tirent en sens contraire. ## Le cache de préfixe est global, et c'est un atout Ce n'est pas un cache par session mais un arbre partagé entre toutes les requêtes. Plusieurs clients Claude Code envoient le **même** prompt système : il n'est donc prefillé qu'une fois pour tous. ``` sessions blocs reutilisees 2 96 % (24 480 / 25 369) 4 96 % (49 104 / 50 997) 8 92 % (94 208 / 102 253) ``` Il survit aussi **entre** les campagnes : un second passage sur les mêmes prompts est parti à 187,5 tok/s agrégés contre 115,1 au premier, sans autre changement que le cache déjà chaud. ## La spéculation, elle, ne gagne que si l'on est seul Sessions agentiques simultanées, même matériel, même protocole : ``` AVEC spec n=24 SANS spec ecart sessions agrege /session agrege /session 1 - - 121,8 121,8 2 187,5 93,8 204,2 102,1 +9 % 4 240,4 60,1 333,9 83,5 +39 % 8 323,8 40,5 503,2 62,9 +55 % ``` Les brouillons consomment le budget de batch : dès **deux** sessions la spéculation coûte plus qu'elle ne rapporte, et l'écart se creuse. Elle reste imbattable en solo sur de l'édition de code (575 tok/s), régime où elle émet 17,16 tokens par lecture des poids. **Le défaut du dépôt est donc `VL_SPEC=off`.** Passer à `on` pour un usage strictement mono-session. ## Ce que ça donne concrètement ``` 1 session, edition de code, spec on 575 tok/s 0,21 $/1M 2 sessions, spec off 102 tok/s ch. 0,60 $/1M 4 sessions, spec off 83 tok/s ch. 0,37 $/1M 8 sessions, spec off 63 tok/s ch. 0,24 $/1M ``` Le débit par session baisse, le coût au million s'améliore : la carte est mieux occupée. Huit sessions Claude Code simultanées tiennent sur une seule A40 à 0,44 $/h, à 63 tok/s chacune. La capacité KV n'est pas le mur : ~450 000 tokens de cache pour des sessions qui plafonnent autour de 35 000 chacune, soit une douzaine avant saturation. --- # Le plafond de l'A40, et pourquoi 8 × 200 tok/s n'y tient pas ## La montée en charge, jusqu'au mur ``` sessions agrege /session $/1M cache partage 1 122,9 122,9 0,995 76 % 2 209,5 104,7 0,583 95 % 4 331,2 82,8 0,369 94 % 8 512,1 64,0 0,239 96 % 16 776,8 48,5 0,157 93 % 32 1 159,7 36,2 0,105 92 % ``` À 32 sessions : 36,25 pas par seconde × ~18 Go de poids lus par pas = **660 Go/s sur les 696 disponibles, soit 95 % du plafond de bande passante**. Le débit agrégé de ~1 160 tok/s est la limite matérielle, pas un défaut de réglage. Une cible de 8 × 200 = 1 600 tok/s demanderait 200 pas/s, soit **~2 000 Go/s** — presque trois fois ce que la carte peut lire. ## L'ordonnancement asynchrone ne donne rien vLLM le refusait tant que la spéculation tournait ; une fois celle-ci coupée, il devient disponible. Résultat, dans le bruit : ``` sessions sans async avec async 1 121,8 122,9 2 204,2 209,5 4 333,9 331,2 8 503,2 505,5 ``` Cohérent avec le reste : dans ce régime on est **borné par le GPU**, il n'y a donc pas d'ordonnancement CPU à recouvrir. ## La spéculation perd à toute profondeur, dès deux sessions Testée à deux profondeurs pour écarter l'idée qu'une profondeur faible ménagerait le budget de batch : ``` sessions sans spec spec n=24 spec n=4 4 83,5 60,1 25,3 8 64,0 40,5 22,1 16 48,5 - 23,1 ``` `n=4` est **encore pire** que `n=24`. Le coût n'est donc pas le budget de batch mais la **vérification payée sur chaque séquence** : plus il y a de séquences, plus elle pèse. La spéculation reste imbattable en solo (575 tok/s en édition de code, 17,16 tokens émis par lecture des poids) et perdante partout ailleurs. ## Comparatif matériel, sur ce qui borne vraiment | | $/h | VRAM | bande passante | vs A40 | $/token relatif | |---|---|---|---|---|---| | **A40** | 0,44 | 48 Go | 696 Go/s | — | **référence** | | RTX 4090 | 0,74 | 24 Go | 1008 Go/s | 1,45× | 1,16× | | L40 | 0,82 | 48 Go | 864 Go/s | 1,24× | 1,50× | | L40S | 0,99 | 48 Go | 864 Go/s | 1,24× | 1,81× | | A100 SXM | 1,59 | 80 Go | 2039 Go/s | 2,93× | 1,23× | **L'A40 est l'optimum économique** : toute alternative coûte plus cher au token. Elles achètent de la latence, pas de l'économie. Le RTX 4090 est en outre 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. --- # Le modèle dense : quatrième hypothèse réfutée Expérience discriminante. Si le plafond venait de la dispersion des tokens vers 128 experts, un modèle **dense** de taille totale comparable devait se comporter différemment. `cyankiwi/Qwen3.8-27B-AWQ-INT4` : 19,6 Gio, aucun expert. ``` sessions MoE Coder-30B Dense 27B ecart 1 122,9 26,2 4,7x plus lent 8 512,1 167,1 3,1x plus lent 32 1 159,7 320,8 3,6x plus lent montee 32/1 9,4x 12,2x ``` Le dense monte légèrement mieux en concurrence, mais part de si bas que ça ne compense jamais. **La dispersion MoE n'est pas le mur — c'est l'avantage** : le MoE ne lit que ~5 Gio d'actifs par token là où le dense en lit 19,6. ## Ce que le plafond n'est pas Cinq mécanismes testés, cinq réfutations : ``` lecture des poids -24 % de poids -> 0 % de debit calcul brut MoE ~5 %, dense ~11 % du plafond FLOPS bande passante MoE ~45 %, dense ~30 % des 696 Go/s dispersion MoE le dense est 3 a 4x plus lent ordonnancement CPU --async-scheduling dans le bruit speculation perdante a n=24 ET a n=4 ``` **Aucun mécanisme validé** n'explique le plafond de ~1 160 tok/s. Ce qui est établi, c'est ce qu'il n'est pas. Publier cette liste vaut mieux qu'habiller une sixième hypothèse en explication. ## Configuration retenue `cyankiwi/Qwen3-Coder-30B-A3B-Instruct-AWQ-4bit`, spéculation coupée, ordonnancement asynchrone, `max-num-seqs 64`, KV en fp8, contexte 262 144. C'est la meilleure combinaison mesurée, et les six variantes essayées sont documentées ci-dessus pour qu'on ne les retente pas.