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.93fait é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.