k3-a40-bootstrap / README.md
patdev's picture
Upload README.md with huggingface_hub
7a9438e verified
|
Raw History Blame Contribute Delete
3.97 kB
---
license: other
tags:
- vllm
- runpod
- claude-code
- anthropic-api
- kimi
- qwen
---
# Endpoint Anthropic pour Claude Code, sur une seule A40
Un pod RunPod à **0,44 $/h** qui sert l'API Anthropic (`/v1/messages`), au choix
avec **Qwen3-Coder-30B** ou **Kimi-Linear-48B**, à **575 tok/s en mono-flux** sur
de l'édition de code — le régime réel d'un agent.
```
ANTHROPIC_BASE_URL=https://<podId>-8080.proxy.runpod.net
ANTHROPIC_API_KEY=peu-importe
```
## Ce qui est mesuré
| | Qwen3-Coder-30B | Kimi-Linear-48B |
|---|---|---|
| édition de code, mono-flux | **575 tok/s** | 100 tok/s |
| agrégé, 16 flux | 782 tok/s | 616 tok/s |
| agrégé, 32 flux | **1 166 tok/s** | 772 tok/s |
| prefill à froid | 4 485 tok/s | **7 647 tok/s** |
| prefill à chaud | **70 568 tok/s** | 36 257 tok/s |
| contexte | 262 144 | **1 048 576** (KV 1 505 550) |
| $/1M en mono-flux | **0,21** | 1,22 |
| tool calling | oui (`qwen3_coder`) | oui (`kimi_k2`) |
Les deux franchissent 500 tok/s sur une seule A40 : Qwen **en mono-flux** grâce à
la spéculation, Kimi **en agrégé dès 16 flux** — la spéculation y étant
inutilisable puisqu'elle corrompt le code.
Les 575 tok/s dépassent d'un facteur 4,4 le plafond mémoire d'un décodage
classique (~130 tok/s mesuré) : c'est la spéculation n-gram qui émet **17,16
tokens en moyenne par lecture des poids**, parce qu'en édition de code la sortie
est largement prédictible depuis le prompt.
## Les fichiers
| fichier | rôle |
|---|---|
| `vllm_bootstrap.sh` | déploiement complet, deux modèles, **rechargement à chaud sans recréer le pod** |
| `anthropic_proxy.py` | pont Anthropic ↔ OpenAI : streaming SSE, appels d'outils, `count_tokens` |
| `test_anthropic.sh` | 5 contrôles de protocole — c'est eux qui distinguent « ça répond » de « Claude Code fonctionne » |
| `bench_endpoint.sh` | protocole de mesure commun à tous les modèles |
| `DEPLOY.md` | mise en service, réglages, pièges |
| `RESULTS.md` | toutes les mesures, y compris les négatives |
| `FINDINGS.md` | le journal des cinq sessions, avec les hypothèses réfutées |
Les artefacts Kimi-K3 (`k3_bootstrap.sh`, `Kimi-K3-DSpark-BF16.gguf`,
`fix_dspark_arch.py`, les binaires llama.cpp) restent présents ; voir `RESULTS.md`
pour savoir pourquoi cette piste a été abandonnée sur A40.
## Ce qui n'a pas marché, et qu'il ne faut pas refaire
- **Kimi-K3 auto-hébergé sur A40** est dominé sur tous les axes : 7,3 tok/s pour
2,20 $/h et ~85 $/1M, contre 29,2 tok/s et ~16 $/1M pour l'API officielle. Il
n'achète ni le prix ni la qualité.
- **Optimiser les kernels MoE** ne donnait rien parce que le mur était ailleurs :
llama.cpp sérialise les couches entre GPU, et le décodage tournait à 7 % du
plafond de bande passante. Fused SiTU : 0 %. Warp-row : +1,2 %.
- **La spéculation n-gram sur Kimi-Linear corrompt le code** de façon
reproductible (`fibonacci(n-1(n-1)`), alors que l'échantillonnage par rejet
devrait être sans perte. Elle y est désactivée par défaut.
- **`--enable-prefix-caching` doit être demandé explicitement.** Sans le flag,
Kimi-Linear donne 1,04× entre prefill froid et chaud, ce qui ressemble à une
limite d'architecture hybride ; avec, il donne 4,74×. J'ai d'abord conclu à
tort que vLLM ne savait pas cacher au-dessus d'un état récurrent.
- **Le taux d'acceptation n'est pas la métrique à suivre** : il chute de 68 % à
27 % pendant que le débit monte de 40 %. Ce qui compte est le nombre de tokens
émis par passe avant.
## Le compromis à connaître
La spéculation gagne en mono-flux et perd en agrégé — les brouillons consomment
le budget de batch. Aucun réglage ne gagne partout :
```
un seul utilisateur (Claude Code) speculation n=24 -> 575 tok/s, 0,21 $/1M
service multi-utilisateurs speculation OFF -> 1 166 tok/s, 0,105 $/1M
```
Le défaut du dépôt est la spéculation, la cible étant Claude Code.