Instructions to use patdev/k3-a40-bootstrap with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use patdev/k3-a40-bootstrap with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf patdev/k3-a40-bootstrap:BF16 # Run inference directly in the terminal: llama cli -hf patdev/k3-a40-bootstrap:BF16
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf patdev/k3-a40-bootstrap:BF16 # Run inference directly in the terminal: llama cli -hf patdev/k3-a40-bootstrap:BF16
Use pre-built binary
# Download pre-built binary from: # https://github.com/ggerganov/llama.cpp/releases # Start a local OpenAI-compatible server with a web UI: ./llama-server -hf patdev/k3-a40-bootstrap:BF16 # Run inference directly in the terminal: ./llama-cli -hf patdev/k3-a40-bootstrap:BF16
Build from source code
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-server llama-cli # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama-server -hf patdev/k3-a40-bootstrap:BF16 # Run inference directly in the terminal: ./build/bin/llama-cli -hf patdev/k3-a40-bootstrap:BF16
Use Docker
docker model run hf.co/patdev/k3-a40-bootstrap:BF16
- LM Studio
- Jan
- Ollama
How to use patdev/k3-a40-bootstrap with Ollama:
ollama run hf.co/patdev/k3-a40-bootstrap:BF16
- Unsloth Desktop
- Docker Model Runner
How to use patdev/k3-a40-bootstrap with Docker Model Runner:
docker model run hf.co/patdev/k3-a40-bootstrap:BF16
- Lemonade
How to use patdev/k3-a40-bootstrap with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull patdev/k3-a40-bootstrap:BF16
Run and chat with the model
lemonade run user.k3-a40-bootstrap-BF16
List all available models
lemonade list
- Atomic Chat
|
Download README.md from patdev/k3-a40-bootstrap: direct link, hf CLI and curl.
- Browser
- Download file 3.97 kB
-
https://huggingface.co/patdev/k3-a40-bootstrap/resolve/main/README.md
- Command line
-
hf download hf://patdev/k3-a40-bootstrap/README.md
-
curl -L -o README.md https://huggingface.co/patdev/k3-a40-bootstrap/resolve/main/README.md
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. | |