2026-04-30
LiteLLM + Claude Code 搭配 DGX Spark — LAN 服務設定與協議轉換
透過 LiteLLM 代理將 Claude Code API 呼叫路由到 DGX Spark 上的自架 Qwen3 模型。涵蓋設定、模型別名對映、多 GPU 卸載,以及延遲與雲端 API 的取捨分析。
Claude Code 向 Anthropic API 格式發送請求。DGX Spark 執行帶有 OpenAI 相容端點的 vLLM。LiteLLM 橋接兩者 — 它即時將 Anthropic API 呼叫轉換為 OpenAI API 呼叫,讓 Claude Code 將你的本地 Qwen3 模型視為 Claude 模型。
架構
Claude Code(Anthropic API)
↓
LiteLLM 代理(localhost:4000)
• 將 claude-* 別名對映至 Qwen3 模型 ID
• 轉換訊息格式 + tool-use 結構
↓
vLLM(http://192.168.68.155:8888/v1)
• 在 GB10 上提供 Qwen3.6-35B-A3B-NVFP4 服務
LiteLLM 設定
# litellm_config.yaml
model_list:
- model_name: claude-sonnet-4-20250514
litellm_params:
model: openai/Intel/Qwen3.6-35B-A3B-int4-AutoRound
api_base: http://192.168.68.155:8888/v1
api_key: none
- model_name: claude-3-5-sonnet-20241022
litellm_params:
model: openai/Intel/Qwen3.6-35B-A3B-int4-AutoRound
api_base: http://192.168.68.155:8888/v1
api_key: none
- model_name: claude-3-opus-20240229
litellm_params:
model: openai/Intel/Qwen3.5-27B-int4-AutoRound
api_base: http://192.168.68.155:8888/v1
api_key: none
litellm_settings:
drop_params: true
set_verbose: false
啟動代理:
litellm --config litellm_config.yaml --port 4000
Claude Code 設定
在 Claude Code 設定中設定:
{
"apiBaseUrl": "http://localhost:4000",
"apiKey": "sk-local-any-string-works"
}
或使用 shell 啟動器模式:
#!/usr/bin/env bash
# claude_local.sh
export ANTHROPIC_API_KEY="sk-local-any-string"
export ANTHROPIC_BASE_URL="http://localhost:4000"
claude "$@"
vLLM 上的 NVFP4 模型
在 GB10 上提供 Qwen3.6-35B-A3B-NVFP4 以獲得最佳吞吐量:
docker run -d --gpus all --ipc host --shm-size 64gb \
-p 8888:8000 \
-v ~/.cache/huggingface:/root/.cache/huggingface \
vllm/vllm-openai:cu130-nightly \
RedHatAI/Qwen3.6-35B-A3B-NVFP4 \
--served-model-name Intel/Qwen3.6-35B-A3B-int4-AutoRound \
--host 0.0.0.0 --port 8000 \
--dtype bfloat16 --gpu-memory-utilization 0.9 \
--max-model-len 131072 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--reasoning-parser qwen3 \
--moe-backend=flashinfer_cutlass
--served-model-name 可以是任何字串 — 設定為與 LiteLLM 設定中的模型別名相符。
延遲實際對比
| 場景 | 延遲 |
|---|---|
| Claude Sonnet 4(雲端) | 0.8–2s TTFT |
| Qwen3.6-35B NVFP4+MTP(本地) | 0.15–0.4s TTFT |
| Qwen3.6-35B NVFP4(無 MTP) | 0.25–0.6s TTFT |
| Qwen3.5-27B int4(本地) | 0.1–0.25s TTFT |
在同一 LAN 上,本地 TTFT 低於雲端 — 無 TLS 握手,無地理路由。取捨是生成品質:Qwen3.6-35B NVFP4 在程式碼任務上與 Sonnet 3.5 相當,但在需要 Opus 等級能力的複雜推理上表現不足。
已知問題
- Tool-use 結構差異:Qwen3 的工具結構與 Anthropic 的略有不同。LiteLLM 的轉換處理了大多數情況,但複雜的嵌套工具呼叫(一次對話中多個工具結果)偶爾失敗。
- 大 context 串流:在 128K+ context 長度下,LiteLLM 的串流緩衝區在高並發時可能出現背壓。單使用者在任何 context 長度下均穩定。
- 模型預熱:伺服器啟動後第一個請求很慢(CUDA graph 編譯進行中)。在啟動腳本中建立 keep-alive ping。