| # 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. |
|
|
