在 RTX 5090 上用 DSpark 本地跑 Qwen3.8 27B，约 208 tok/s

本文转载自 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：

结论：

• 五套配置都在 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，只是方向性结果，非严谨评测；工具调用是核心诉求的话建议加大测试量。