这篇实践解决的是一个很具体的问题：Qwen3.8-27B 在 DGX Spark 上直接用 vLLM 推理时，解码速度只有个位数，怎样通过 SGLang、NVFP4 与 DSpark 投机解码把它调到可用水平。最终方案给出了完整启动逻辑、基准数据和长上下文边界，适合已经有 DGX Spark、希望复用本地算力的人。

环境与目标

作者使用单台 DGX Spark（GB10/SM120），主模型为 Qwen3.8-27B-NVFP4，草稿模型为 RadixArk/Qwen3.8-27B-DSpark，运行镜像是 lmsysorg/sglang:qwen38-27b。推理服务对外使用 8000 端口，容器内部监听 30000。

原帖没有说明宿主机系统版本、驱动版本、模型下载过程和首次启动耗时，因此复现前应先确认 NVIDIA 驱动、Docker GPU 运行时以及两个模型目录都能被容器只读挂载。

配置思路

核心不是单独打开投机解码，而是同时控制显存占用、KV Cache 和预填充策略：

  1. 主模型使用 NVFP4，草稿模型保持未量化，并选择 DSpark，block size 为 7。
  2. KV Cache 改为 fp8_e4m3，模型计算类型保持 bfloat16；作者指出若继续使用 BF16 KV，约 50 GB 的缓存会造成显存压力。
  3. 上下文长度设为 262,144，静态显存比例控制在 0.88。作者此前使用 0.95 时发生过显存溢出。
  4. 注意力后端使用 FlashInfer，分块预填充大小为 8192，并把最大并发请求限制为 2。
  5. Mamba 状态使用 bfloat16，并使用额外缓冲策略管理 radix cache。
  6. 启动前检查同名残留容器和 8000 端口占用，避免服务实际启动失败却被误判为模型问题。

完整脚本还包含容器健康等待、日志截取、模型列表查询和一次聊天补全请求。复现时建议保留这四层验证，不要只看到容器处于 running 就认为服务可用。

验证方式与实测结果

第一步请求 /v1/models，确认服务暴露了预期模型；第二步调用兼容 OpenAI 的聊天补全接口，关闭 thinking 后检查返回 JSON。之后再进行吞吐测试。

作者对 HumanEval、GSM8K、MATH-500、MBPP、MT-Bench、AIME 2025/2026、LBPP 和 Alpaca 共 1,152 个请求进行了测试。各任务输出吞吐约为 23.99～36.30 token/s，投机接受长度约为 3.087～4.468。讨论中作者补充，短上下文表现尚可，预填充峰值约 2,000 token/s；当上下文超过 100K 后，生成速度可能降至十几 token/s。

常见问题与边界

  • 启动即 OOM：优先核对静态显存比例、KV Cache 类型和模型挂载，不要直接扩大上下文。
  • 短文本快、长上下文骤降：这是当前硬件带宽和投机接受率共同影响的结果，不应把短上下文峰值外推到 100K 以上。
  • 服务未响应：依次检查残留容器、端口占用、容器日志和模型目录权限。
  • 是否值得购买硬件：讨论普遍认为它更适合已有设备的个人或实验场景；若专门购机，只看 token 成本通常不如在线 API。

回退时可停止并删除该容器，恢复原有 vLLM 服务和端口映射；模型目录采用只读挂载，不会因删除容器而被修改。原帖未提供能耗、长期稳定性、并发压力和固定随机种子的对照数据，因此这些仍需要自行补测。

原作者：DT2025（DT）
原帖：https://linux.do/t/topic/2765361