MiaAI-Lab/DeepSeek-v4.1-Flash-DGX-Sparks · 上手攻略
- 仓库：MiaAI-Lab/DeepSeek-v4.1-Flash-DGX-Sparks
- 链接：https://github.com/MiaAI-Lab/DeepSeek-v4.1-Flash-DGX-Sparks
- 分类：AI 推理 · 分布式推理
- 作者：Tom
- 更新：2026-09-16
是什么
这是一个在 3-4 台 NVIDIA DGX Spark 节点上通过 SGLang 部署 DeepSeek-V4.1-Flash 模型的生产级推理方案。模型以 MXFP4 稀疏专家 + FP8 密集权重运行，KV Cache 由 NVMe + 统一内存共同支撑，提供 OpenAI 兼容的 /v1/chat/completions 接口，支持 Tool Calling、Vision 和最长 1M token 的超长上下文。
⚠️ 硬件要求极高：每个 DGX Spark 节点配备 121.7 GiB 统一内存，3 节点合计约 365 GiB；4 节点方案权重占用 ~305 GiB GPU 内存（MXFP4 专家 ~77 GiB/节点）。非 DGX Spark 硬件无法直接复用此方案。
解决什么问题
DeepSeek-V4.1-Flash（MoE + 稀疏专家架构）原生 checkpoint 体积约 476 GiB，单卡或普通多卡服务器难以完整加载。此方案通过：
- 多节点 Tensor Parallel（TP=3/TP=4）：将模型分布在 3-4 台 DGX Spark 节点上
- NCCL over ConnectX-7 RoCE：节点间通过高速互联聚合为统一推理引擎
- NVMe Engram 表外置：MoE 的 n-gram 查找表移至 NVMe，减少统一内存占用
- DSpark 投机解码：4-token 窗口投机解码，Decode 吞吐提升至 3-4 倍
- OpenAI 兼容接口：无需修改调用侧代码，直接对接现有应用
硬件与网络要求
DGX Spark 节点配置（3节点示例）
| 节点 | IP | 角色 |
|---|---|---|
| spark1 | 10.0.0.1 | Head（API + rank 0） |
| spark2 | 10.0.0.2 | Worker（rank 1） |
| spark3 | 10.0.0.3 | Worker（rank 2） |
- 每节点 121.7 GiB 统一内存
- 节点间通过 ConnectX-7（InfiniBand HDR）RoCE 三角形互联
- spark1 通过 NFSv4 导出模型 checkpoint，spark2/spark3 挂载
- Engram 表（~189 GiB 总量）分散存储在各节点本地 NVMe
⚠️ 关键约束：OFFLOAD_MODE=ram 禁止使用——会将 Engram 表 evict 出 GPU，导致无法服务。Host RAM 在 Spark 架构上就是 GPU 内存，所有 pinned 缓冲（CUDA Graph、tokenizer 等）共享同一份内存，head 节点 OOM 会卡住所有 rank。
4 节点（TP=4）与 3 节点对比
| 指标 | 3 Sparks（TP=3） | 4 Sparks（TP=4） |
|---|---|---|
| 权重/节点 | ~101 GiB | ~77 GiB |
| 运行时空闲内存 | ~6 GB | ~40 GB |
| KV Pool | 750k tokens | 8M tokens（ pinned） |
| 上下文上限 | 256k | 1M（已验证） |
| 默认并发 | 4 | 8 |
| 单流 Decode | 37.9 tok/s | 45.4 tok/s |
| 4 流 Decode | 78.6 tok/s agg | 103.1 tok/s agg |
快速安装
前置条件
- 3 台（TP=3）或 4 台（TP=4）DGX Spark 节点，统一网络互通
- NVIDIA DGX Spark 镜像（
lmsysorg/sglang:dev-dsv41） - Docker、NCCL、InfiniBand 驱动已配置
- checkpoint 存放于 spark1 可访问路径（
~/NewModels/DS4.1）
启动流程（3 节点）
# 1. 复制环境配置模板
cd ~/NewModels/DS4.1
cp -n .env.example .env # 编辑填入节点 IP、SSH 用户等
# 2. 预检（检查 SSH、Docker、IB、checkpoint 分片、GPU 状态）
./start.sh doctor
# 3. 构建 Docker 镜像
./start.sh build
# 4. 导出 checkpoint + 创建 docker volume
./start.sh share
# 5. 将 Engram 表打包到各节点 NVMe（仅首次，约 10 分钟）
./start.sh pack
# 6. 启动推理服务（先起 worker，再起 head）
./start.sh serve
# 查看状态/日志
./start.sh status
./start.sh logs worker1 # 查看指定 worker 日志
完整启动约 12-13 分钟（读取 476 GiB checkpoint 约 8 分钟 + draft model + KV pool + CUDA Graph capture）。
4 节点启动（TP=4）
cp -n .env.tp4.example .env.tp4 # 填入 4 节点 IP 配置
./start-tp4.sh doctor
./start-tp4.sh build
./start-tp4.sh share
./start-tp4.sh pack # Engram 分片为 of4.bin（~48 GiB/节点）
./start-tp4.sh serve
核心用法
调用 API
服务启动后，OpenAI 兼容端点为 http://10.0.0.1:8888/v1/chat/completions：
curl http://10.0.0.1:8888/v1/chat/completions \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <API_KEY>' \
-d '{
"model": "deepseek-v4.1-flash",
"messages": [{"role": "user", "content": "What is 19 + 23?"}],
"max_tokens": 32,
"chat_template_kwargs": {"thinking": false}
}'
⚠️ thinking 参数：传入 thinking: false（或 enable_thinking: false）关闭思考链输出。仅在 max_tokens 足够时生效；若两者冲突，thinking 优先。建议始终传入 max_tokens，服务会自动填充并上限 clamp 到 32768，防止生成过长。
⚠️ TTFT（Time To First Token）：长上下文首 token 时间较长，例如 128K context 的 prefill TTFT 约 40 秒，属正常现象。
性能基准（4 Sparks，TP=4）
Decode（prose，256 completion tokens）：
| 并发 | TTFT | 聚合吞吐 | 单流吞吐 |
|---|---|---|---|
| ×1 | 212 ms | 45.4 tok/s | 45.4 tok/s |
| ×2 | 232 ms | 72.9 tok/s | 37.9 tok/s |
| ×4 | 270 ms | 103.1 tok/s | 26.7 tok/s |
| ×8 | 2.70 s | 114.1 tok/s | 23.2 tok/s |
| ×16 | 12.45 s | 134.2 tok/s | 22.0 tok/s |
⚠️ 8+ 并发是吞吐优化点，不是延迟优化点。16 流时 TTFT 达 12.45 秒，延迟已不可接受。
Prefill：
| 上下文 | Prompt Tokens | TTFT | 吞吐 |
|---|---|---|---|
| 4K | 4,118 | 1.23 s | 3,350 tok/s |
| 16K | 16,400 | 4.34 s | 3,782 tok/s |
| 32K | 32,788 | 8.70 s | 3,768 tok/s |
| 64K | 65,557 | 18.57 s | 3,531 tok/s |
| 128K | 131,093 | 40.32 s | 3,251 tok/s |
Prefill 在 16K-32K 区间达到峰值约 3.8k tok/s。
关键环境变量
| 变量 | 默认值 | 说明 |
|---|---|---|
TP_SIZE / EP_SIZE |
3 / 3 | Tensor Parallel / Expert Parallel 数量 |
CONTEXT_LENGTH |
262144（TP3）/ 1048576（TP4） | 单请求上下文上限 |
MAX_TOTAL_TOKENS |
750000（TP3）/ 8000000（TP4） | KV Pool 大小（pinned） |
MAX_RUNNING_REQUESTS |
4（TP3）/ 8（TP4） | 最大并发请求数 |
MEM_FRACTION_STATIC |
0.95（TP3）/ 0.80（TP4） | 静态内存保留比例 |
SPEC_ALGO |
DSPARK |
投机解码算法（off 禁用） |
DSPARK_BLOCK_SIZE |
3 | 4-token 验证窗口 |
API_KEY |
未设置 | Bearer Token 鉴权（需在 .env 配置） |
典型适用场景
- 超长上下文推理：1M token 上下文 Needle-in-a-Haystack 已验证，适合超长文档分析、多文档比对
- 高吞吐批量推理：多流并发下 Aggregate 134 tok/s，适合内容生成类应用
- Tool Calling / Agent 场景：内置 tool call 支持，可直接作为 Agent 后端
- 多模态（Vision）：支持图像输入
- DSpark 投机解码加速：Decode 吞吐可达 3-4 倍提升（需 MoE 稀疏特性配合）
坑与注意
⚠️ 硬件门槛极高：必须使用 DGX Spark（统一内存架构），普通 GPU 服务器无法复用。Checkpoint 本身 476 GiB，普通 A100/H100 多卡方案也不够。
⚠️ Head 节点 OOM 全局卡死：TP 同步机制决定了 head 节点内存耗尽会阻塞所有 rank。KV pool 满时 head 首先达到上限，此时应降低 MAX_RUNNING_REQUESTS 或 MEM_FRACTION_STATIC，而非提升。
⚠️ Engram 表不能 offload 到 RAM：Spark 架构下 host RAM = GPU memory，OFFLOAD_MODE=ram 会把 Engram 表 evict 掉。运行日志中 full_token= 数字是唯一判断标准，低于预期值说明 KV 被压占。
⚠️ TP3 时 rank 2 是全 padding：由于 heads=64/o_groups=8/draft_experts=128 无法被 3 整除，rank 2 的注意力分片完全为 padding，GPU 利用率不对称。
⚠️ NCCL 调试复杂：多节点 NCCL over RoCE 配置繁琐，首次部署建议开启 NCCL_DEBUG=INFO 查看通道和协议选择。
⚠️ 4 节点需 RoCE 交换机：3 节点可直连三角形，但 4 节点无法形成完整三角形，需要支持 InfiniBand HDR 的 RoCE 交换机，或配置 NCCL ring 模式。
⚠️ Docker 镜像为 dev 版本：lmsysorg/sglang:dev-dsv41 是开发版镜像，非生产稳定版，存在非预期行为风险。
与同类对比
| 特性 | 本方案 | vLLM 单机 | SGLang 单机 | DeepSeek API |
|---|---|---|---|---|
| 硬件要求 | 3-4× DGX Spark | 单机 8× A100/H100 | 单机 8× A100/H100 | 云服务 |
| 上下文 | 1M（已验证） | 最高 1M | 最高 1M | 128K |
| 投机解码 | DSpark（3-4×） | Speculative Decoding | RadixAttention | 不透明 |
| KV Pool | 8M tokens（pinned） | PagedAttention | PagedAttention | 不透明 |
| 部署难度 | 极高（多节点） | 中 | 中 | 零 |
| 成本 | 硬件成本极高 | 中等 | 中等 | 按量付费 |
一句话推荐结论
专业级分布式推理方案，面向拥有 DGX Spark 集群、需要 1M 超长上下文和高吞吐的场景；硬件门槛极高，普通用户建议直接使用 DeepSeek 官方 API 或社区的单机 SGLang/vLLM 方案。