本文轉載自 Reddit 社區 r/LocalAIServers，作者 u/UnDadFeated。原文《Got Qwen3.8 27B running locally with DSpark on my RTX 5090 — ~208 tok/s》：https://www.reddit.com/r/LocalAIServers/comments/1vv3mzj/ 。版權歸原作者所有。

週末抽空把本地 LLM 部署到了「不卡頓」的狀態，下面是完整分享。核心成果一句話：Qwen3.8-27B（gittensor 專為 5090 打造的 NVFP4 版本）配合 DSpark 投機解碼草案模型，在 Docker 裡的 SGLang 上提供服務，單張 RTX 5090 32GB 達到約 208 tok/s，峰值 230+。

速度實測

直接打本機 OpenAI 兼容接口，每輪 256 token、開 thinking，5 輪跑分：

  • run1：230.9 tok/s

  • run2：148.3 tok/s（冷啟動後第一輪，屬熱身）

  • run3：232.2 tok/s

  • run4：232.4 tok/s

  • run5：229.1 tok/s

平均 208.2 tok/s。第一次偏低只是 warmup，穩定後穩穩停在 220 出頭。

為什麼選 Docker（以及踩的坑）

DSpark 草案模型只在某個特定運行時上才能加載：一個帶標籤的私有 SGLang 分支 lmsysorg/sglang:qwen38-27b。作者先是走常規路線——官方 PyPI 版 SGLang 一加載草案模型就崩（權重形狀不匹配，啟動即死）。這個分支源碼不公開，沒法「pip install」搞定，最後只能上 Docker 鏡像。

CachyOS 的坑（能幫你省一個晚上）

如果你在 CachyOS（或這類內核的 Arch）上，原版 Docker 守護進程會拒絕啟動，直到把 /etc/docker/daemon.json 寫成：

{"iptables": false, "bridge": "none", "storage-driver": "vfs"}

  • iptables:false + bridge:none 修復 nf_tables ... chain PREROUTING 報錯（Docker 無法建立網橋網絡）。

  • storage-driver:vfs 修復 overlay 掛載「無此設備」報錯（此內核沒編譯 overlay 模塊）。慢一點，但你只跑一個容器，無所謂。

  • 因為關掉了網橋網絡，容器要用 --network host 跑，而不是 -p 端口映射。

部署命令（可直接丟給 AI agent）

作者把整套搭建流程交給了編碼 agent（Hermes/Claude/Codex 都適用，無隱私信息，只需改路徑）：

docker run --gpus all --ipc=host --shm-size 32g --network host \
  -v <HF_HOME>:/root/.cache/huggingface \
  lmsysorg/sglang:qwen38-27b sglang serve \
    --model-path gittensor-model-hub/Qwen3.8-27B-NVFP4-RTX5090 \
    --speculative-algorithm DSPARK \
    --speculative-draft-model-path gittensor-model-hub/Qwen3.8-27B-DSpark-NVFP4 \
    --speculative-draft-model-quantization modelopt_fp4 \
    --speculative-dspark-block-size 7 \
    --trust-remote-code --tp-size 1 \
    --context-length 122880 --kv-cache-dtype fp8_e4m3 \
    --attention-backend flashinfer --chunked-prefill-size 1024 \
    --mamba-radix-cache-strategy extra_buffer_lazy \
    --mamba-ssm-dtype bfloat16 --max-mamba-cache-size 8 \
    --mm-feature-transport cpu --cuda-graph-max-bs-decode 1 \
    --mem-fraction-static 0.86 --max-running-requests 1 \
    --served-model-name qwen3.8 \
    --reasoning-parser qwen3 --tool-call-parser qwen3_coder \
    --host 0.0.0.0 --port 8000

  • 僅此分支兼容 DSpark；原生 PyPI SGLang 0.5.18 會以權重形狀報錯拒絕加載，別裝原生版。

  • 附帶 DeepSeek Harness（dsh）Web UI 跑在 :3080，指向 :8000/v1。

  • 運行實測：ai-sglang 一鍵拉起（含拉鏡像、跑容器、起 dsh、報 tok/s），約 58 秒就緒；ai-stop 一鍵關停。

補充：Qwen3.8 工具調用基準（5 套配置，RTX 5090）

作者用 20 條提示的工具調用用例做了橫向對比（pass=輸出合法 tool_calls 數組 + 合法 JSON 參數，而非自然語言回答；temp=0）。模型橫跨 llama.cpp 三種 GGUF、vLLM、SGLang+DSpark：

配置

工具調用準確率

平均解碼速度

llama.cpp A：utautako Q8attn+MTP (GGUF)

19/20 (95%)

~120 tok/s

llama.cpp B：unsloth UD-Q4_K_XL (GGUF, 無MTP)

19/20 (95%)

~119 tok/s

llama.cpp C：Jackrong Q4_K_M+MTP (GGUF)

19/20 (95%)

~120 tok/s

vLLM：NVFP4 基礎版

18/20 (90%)

~76 tok/s

SGLang + DSpark：NVFP4

19/20 (95%)

~211 tok/s

結論：

  • 五套配置都在 90%–95%，差距很小；所有失敗都是模型用自然語言作答而非調用工具，沒有一例 JSON 格式錯或函數名錯。

  • 最常錯的是複利計算器用例（5 套裡 4 套掛，僅 vLLM 是改掛了別的）。

  • NVFP4 版（vLLM 與 SGLang+DSpark）在工具調用上沒有比 GGUF 更差（vLLM 反而最低 90%）。

  • 速度差異巨大：DSpark（~211）約為 vLLM 基礎版（~76）的 2.8 倍、GGUF 版（~120）的 1.8 倍，準確率卻持平。

  • 注：單輪、20 條用例、temp 0，只是方向性結果，非嚴謹評測；工具調用是核心訴求的話建議加大測試量。