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