patdev/k3-a40-bootstrap

1---2license: other3tags:4  - vllm5  - runpod6  - claude-code7  - anthropic-api8  - kimi9  - qwen10---11 12# Endpoint Anthropic pour Claude Code, sur une seule A4013 14Un pod RunPod à **0,44 $/h** qui sert l'API Anthropic (`/v1/messages`), au choix15avec **Qwen3-Coder-30B** ou **Kimi-Linear-48B**, à **575 tok/s en mono-flux** sur16de l'édition de code — le régime réel d'un agent.17 18```19ANTHROPIC_BASE_URL=https://<podId>-8080.proxy.runpod.net20ANTHROPIC_API_KEY=peu-importe21```22 23## Ce qui est mesuré24 25| | Qwen3-Coder-30B | Kimi-Linear-48B |26|---|---|---|27| édition de code, mono-flux | **575 tok/s** | 100 tok/s |28| agrégé, 16 flux | 782 tok/s | 616 tok/s |29| agrégé, 32 flux | **1 166 tok/s** | 772 tok/s |30| prefill à froid | 4 485 tok/s | **7 647 tok/s** |31| prefill à chaud | **70 568 tok/s** | 36 257 tok/s |32| contexte | 262 144 | **1 048 576** (KV 1 505 550) |33| $/1M en mono-flux | **0,21** | 1,22 |34| tool calling | oui (`qwen3_coder`) | oui (`kimi_k2`) |35 36Les deux franchissent 500 tok/s sur une seule A40 : Qwen **en mono-flux** grâce à37la spéculation, Kimi **en agrégé dès 16 flux** — la spéculation y étant38inutilisable puisqu'elle corrompt le code.39 40Les 575 tok/s dépassent d'un facteur 4,4 le plafond mémoire d'un décodage41classique (~130 tok/s mesuré) : c'est la spéculation n-gram qui émet **17,1642tokens en moyenne par lecture des poids**, parce qu'en édition de code la sortie43est largement prédictible depuis le prompt.44 45## Les fichiers46 47| fichier | rôle |48|---|---|49| `vllm_bootstrap.sh` | déploiement complet, deux modèles, **rechargement à chaud sans recréer le pod** |50| `anthropic_proxy.py` | pont Anthropic ↔ OpenAI : streaming SSE, appels d'outils, `count_tokens` |51| `test_anthropic.sh` | 5 contrôles de protocole — c'est eux qui distinguent « ça répond » de « Claude Code fonctionne » |52| `bench_endpoint.sh` | protocole de mesure commun à tous les modèles |53| `DEPLOY.md` | mise en service, réglages, pièges |54| `RESULTS.md` | toutes les mesures, y compris les négatives |55| `FINDINGS.md` | le journal des cinq sessions, avec les hypothèses réfutées |56 57Les artefacts Kimi-K3 (`k3_bootstrap.sh`, `Kimi-K3-DSpark-BF16.gguf`,58`fix_dspark_arch.py`, les binaires llama.cpp) restent présents ; voir `RESULTS.md`59pour savoir pourquoi cette piste a été abandonnée sur A40.60 61## Ce qui n'a pas marché, et qu'il ne faut pas refaire62 63- **Kimi-K3 auto-hébergé sur A40** est dominé sur tous les axes : 7,3 tok/s pour64  2,20 $/h et ~85 $/1M, contre 29,2 tok/s et ~16 $/1M pour l'API officielle. Il65  n'achète ni le prix ni la qualité.66- **Optimiser les kernels MoE** ne donnait rien parce que le mur était ailleurs :67  llama.cpp sérialise les couches entre GPU, et le décodage tournait à 7 % du68  plafond de bande passante. Fused SiTU : 0 %. Warp-row : +1,2 %.69- **La spéculation n-gram sur Kimi-Linear corrompt le code** de façon70  reproductible (`fibonacci(n-1(n-1)`), alors que l'échantillonnage par rejet71  devrait être sans perte. Elle y est désactivée par défaut.72- **`--enable-prefix-caching` doit être demandé explicitement.** Sans le flag,73  Kimi-Linear donne 1,04× entre prefill froid et chaud, ce qui ressemble à une74  limite d'architecture hybride ; avec, il donne 4,74×. J'ai d'abord conclu à75  tort que vLLM ne savait pas cacher au-dessus d'un état récurrent.76- **Le taux d'acceptation n'est pas la métrique à suivre** : il chute de 68 % à77  27 % pendant que le débit monte de 40 %. Ce qui compte est le nombre de tokens78  émis par passe avant.79 80## Le compromis à connaître81 82La spéculation gagne en mono-flux et perd en agrégé — les brouillons consomment83le budget de batch. Aucun réglage ne gagne partout :84 85```86un seul utilisateur (Claude Code)   speculation n=24  ->   575 tok/s, 0,21 $/1M87service multi-utilisateurs          speculation OFF   -> 1 166 tok/s, 0,105 $/1M88```89 90Le défaut du dépôt est la spéculation, la cible étant Claude Code.91