patdev/k3-a40-bootstrap

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.