README 的 Quick start 要求 two DGX Sparks;正文说明默认 max_model_len 为 1,048,576。
DeepSeek-V4 Flash:双DGX Spark的1M上下文vLLM配方
给两台DGX Spark部署DeepSeek-V4 Flash的vLLM配方,主打1M上下文和DSpark推测解码。
🧭 决策指南
为什么现在热: 无法从材料判断
适合,如果你
-
你有两台 DGX Spark,并需要 DeepSeek-V4-Flash-Vision-Exp 的 1M-token 服务。
-
你的集群已经具备 RoCE/NCCL、ConnectX 网络和 passwordless SSH。README 的 Quick start 要求 RoCE/NCCL working;Optional: three Sparks 要求 passwordless SSH 和 ConnectX 链路。
-
你需要 OpenAI image_url/path 输入,而不是视频编码能力。README 正文写明 Anemll 0.1.1 支持 OpenAI image_url/path,并明确没有 video encoder。
-
你要在三台 DGX Spark 上获得 16 slots 和约 200 tok/s aggregate。README 的 Optional: three Sparks (TP=3) 写明 TP3_MAX_NUM_SEQS=16、约 200 tok/s aggregate at 16 streams。
不适合,如果你
-
你没有两台 DGX Spark,或无法提供 RoCE/NCCL 工作链路。README Quick start 明确要求 two DGX Sparks、RoCE/NCCL working。
-
你需要官方权重直接处理视频或完整 GIF 动画。README 正文明确写着 There is no video encoder in the official weights;GIF is a still frame。
-
你的主要场景是单用户 128K–256K 长上下文,并计划使用 TP=3。README TP=3 章节写明该范围预填充代价约 22%,并说 single-user long-context 更适合 2-node lane。
-
你只能运行 CPU 环境,却需要验证真实 tok/s。README Quick start 将 scripts/ci-validate.sh 标为 no GPU、will not measure tok/s;Live tok/s 需要 2× Spark pair。
前置条件
- 两台 DGX Spark;README Quick start 原文要求“two DGX Sparks”。
- RoCE/NCCL working;README Quick start 将其列为启动条件。
- 两台节点使用同一个镜像 ghcr.io/anemll/dspark-vllm-gx10:0.1.1。
- head 到 worker 的 passwordless SSH;README 的 Optional: three Sparks 章节明确列出该条件。
- worker 上预拉取约 19 GB 的 DSPARK_VLLM_IMAGE;README TP3 章节给出该容量。
- 需要配置 WORKER_HOST、MASTER_ADDR、NCCL_IB_HCA、NCCL_SOCKET_IFNAME、VLLM_HOST_IP、WORKER_VLLM_HOST_IP 和 HF_CACHE。
- 默认镜像为 Anemll 0.1.1,运行路径使用 /usr/local/bin/vllm serve、TP=2、mp、nnodes 2。
第一步命令(README 原文)
cp .env.dspark.example .env.dspark
要注意
-
start 必须先 worker 后 head;README Start 步骤明确规定顺序。Quick start 第 5 步写明“Start (worker first, then head)”。
-
两节点默认会在 worker 下载 checkpoint;设置 DSPARK_WORKER_HF_NFS=1 才改用 NFS。Quick start 的 Weights on the head 及 NFS 说明。
-
重启后若 dockerd 恢复 ranks,start 会以退出码 3 结束,不应立即执行 stop。Quick start Start 段落说明 restart: unless-stopped 和 exit 3。
-
6 个 1M 请求无法全部驻留,KV cache 表格说明 6.0M 超过共享池,额外请求会排队。How the KV cache works 章节的 6 × 1M = 6.0M impossible 示例。
-
不要手动设置 DSPARK_MODEL 或 GPU_MEMORY_UTILIZATION。.env.dspark switches 章节明确写着 Do not set these by hand。
-
max-cudagraph-capture-size 在 6×6 时应为 48;设为普通 42 会截断到 40 并损失 12%。Runtime flags 章节,数据测量日期为 2026-09-02。
-
TP=3 首次启动会编译数分钟,且每个 rank 必须出现 DSv4 TP pad: heads 64 -> 72。Optional: three Sparks (TP=3) 章节的首次启动说明。
替代方案
-
两节点 TP=2 lane:单用户长上下文场景优于 TP=3,尤其是 128K–256K 预填充。Optional: three Sparks (TP=3)
-
三节点 TP=3 lane:需要 16 slots、约 5M cached tokens 或 16 streams 约 200 tok/s aggregate 时更合适。Optional: three Sparks (TP=3)
材料未说明
- README 未提供 DGX Spark 的具体硬件型号、显存容量和 CUDA 驱动版本。
- README 未给出两节点 TP=2 的完整 tok/s、首 token 延迟和不同上下文长度的基准表;仅引用 results/RESULTS-2026-08-14.md。
- README 未说明 ghcr.io/anemll/dspark-vllm-gx10:0.1.1 镜像的具体发布日期或镜像 digest。
- README 未给出生产部署的认证、TLS、访问控制和多租户隔离方案。
- README 未说明官方 checkpoint 的完整下载耗时、磁盘空间要求或网络带宽要求。
- 项目没有发布版本,基础信息显示 Releases 为 0、最新版本为 No releases;正式版本兼容性边界未知。
- README 未说明 2026-09-09 Trending 上榜与具体用户增长、提交变化或外部事件之间的因果关系。
💡 深度解析
6
不适合
我主要做单机 Python 和普通 Docker 部署,没有维护过 NCCL、RoCE、head/worker 和多节点 vLLM;这个项目是否适合我直接接手?
适合读者: 只熟悉单机 Python 或普通 Docker、但希望把 DeepSeek-V4-Flash-Vision-Exp 部署到两台 DGX Spark 的应用开发者
不适合直接接手,因为项目把网络、容器、模型缓存和多节点并行配置都作为前置条件,学习曲线明显高于普通单机服务。
- Quick start 要求两台 DGX Spark、RoCE/NCCL 正常工作、两台机器使用同一镜像,并从 head 节点协调 worker。
.env.dspark至少要配置WORKER_HOST、MASTER_ADDR、NCCL_IB_HCA、NCCL_SOCKET_IFNAME、匹配的 TP/Gloo 网卡名、服务 IP 和 Hugging Face 缓存路径。- 项目洞察列出的常见故障包括网卡或 GID 不匹配、worker 镜像不一致、缓存路径错误、JIT 编译期间误重启,以及 earlyoom 杀掉 vLLM。
- README 的 CPU 校验只能检查配置,不能证明跨节点 GPU 服务可用;真正启动还涉及权重准备、Docker rank 恢复和长时间 JIT 编译。
- README Quick start:`You need two DGX Sparks, RoCE/NCCL working, and the same image on both`
- README Env:`WORKER_HOST`、`MASTER_ADDR`、`NCCL_IB_HCA`、`NCCL_SOCKET_IFNAME`、`TP_` / `GLOO_` IF names
- 项目洞察:学习难度较高,适合具备 Linux、Docker、SSH、多节点 GPU、NCCL/RoCE 和 vLLM 经验的用户
- 项目洞察:常见故障包括网络配置不匹配、镜像或缓存路径不一致、JIT 编译误重启和 earlyoom
bash scripts/ci-validate.sh
适合
我有两台 DGX Spark,准备使用 vLLM TP=2 和 RoCE/NCCL 部署 DeepSeek-V4-Flash-Vision-Exp;这个项目能否直接作为 1M-token 私有推理服务的部署方案?
适合读者: 维护两台 NVIDIA DGX Spark、已配置 RoCE/NCCL,并希望私有化运行 DeepSeek-V4-Flash-Vision-Exp 1M 上下文服务的 AI 基础设施工程师
适合,因为它就是面向两台 DGX Spark 的 TP=2 部署配方,并把 1M-token 上限、NVFP4 MLA KV 缓存和跨节点启动流程组合在一起。
- README 的 Quick start 要求两台 DGX Spark、RoCE/NCCL 正常工作,且两台机器使用同一镜像;默认镜像为
ghcr.io/anemll/dspark-vllm-gx10:0.1.1。 - 运行时默认
TP=2、nnodes 2,并使用--kv-cache-dtype nvfp4_ds_mla和--max-model-len 1048576。 - 启动日志给出的基线是 17.04 GiB KV cache、2,331,430 tokens,以及完整 1M 请求约 2.22 倍并发;这不是任意数量的 1M 请求并行。
- 服务通过
http://HEAD_NODE_IP:8888/v1暴露 OpenAI 风格接口,但认证、TLS 和限流不在项目范围内。
- README:Two-node DGX Spark recipe for `deepseek-ai/DeepSeek-V4-Flash-Vision-Exp`
- README:`vLLM TP=2`、`1M-token ceiling`、`nvfp4_ds_mla` KV
- README:`Available KV cache memory: 17.04 GiB`;`Maximum concurrency ... 2.22x`
- 项目洞察:双 DGX Spark 的 TP=2 分布式推理启动方案
cp .env.dspark.example .env.dspark
视情况
我计划让多个用户同时提交 200K 到 1M token 的长文档,并使用默认 `max_num_seqs=6`;这个项目能否满足这种并发服务需求?
适合读者: 默认使用 `max_num_seqs=6`、需要处理多个长文档请求,并计划通过 OpenAI API 提供内部并发服务的研究团队平台工程师
视情况:它能承载有限的长上下文并发,但不适合把默认配置理解为六个完整 1M 请求同时运行。
- README 的 KV 池为 2,331,430 tokens,
max_model_len是单请求上限 1,048,576,max_num_seqs=6是最多活跃序列数,不是六个满额请求的容量保证。 - README 给出的示例是 6×200K=1.2M 可以放入池中,而 6×500K=3.0M 接近或超过容量;6×1M=6.0M 不可能同时容纳,额外请求会排队。
- 启动日志中的完整 1M 请求并发为 2.22x,说明该配置更接近少量超长请求,而不是大规模并发服务。
- 项目洞察还指出默认
max_num_seqs为 6,过高并发会排队或耗尽 KV 池;服务默认暴露 HTTP 接口,但没有内置生产级限流和故障转移。
- README How the KV cache works:`KV pool ... 2,331,430 tokens`;`max_num_seqs ... 6`
- README 示例:`6 × 200k = 1.2M fits`;`6 × 1M = 6.0M impossible — extras queue`
- README:`Maximum concurrency for 1,048,576 tokens per request: 2.22x`
- 项目洞察:默认 `max_num_seqs` 为 6,过高并发会排队或耗尽 KV 池
curl -fsS http://127.0.0.1:8888/v1/models
适合
我需要通过 OpenAI 兼容接口提交长文档和 `image_url` 或本地 `path` 图片,但不需要视频理解;这个项目是否适合作为内部视觉推理后端?
适合读者: 需要把长文档、代码库和研究资料接入私有 OpenAI 兼容 API,并计划发送单张图片但不需要视频理解的企业或研究团队
适合,但前提是你的视觉需求限于单图输入;项目明确支持原生图片调用,却没有官方视频编码器。
- README 说明 Vision-Exp 的图片能力通过启动热修复接入,使用 checkpoint 中的 ViT 与 Aligner,并兼容 OpenAI
image_url/path。 - 旧的 Qwen3-VL sidecar 和 MCP 路径已移除,因此部署链路不需要额外的视觉旁路服务。
- README 明确写出官方权重没有 video encoder,GIF 只按静态帧处理;多帧或复杂视频分析不能按完整视频能力规划。
- API 默认位于
http://HEAD_NODE_IP:8888/v1,同时默认max_model_len为 1,048,576;但生产认证、TLS、审计和限流仍需由团队补充。
- README:`Native image support ... OpenAI image_url / path`
- README:`There is no video encoder in the official weights; GIF is a still frame`
- README:`The old Qwen3-VL sidecar / MCP path is removed`
- README:`API: http://HEAD_NODE_IP:8888/v1`
curl -fsS http://127.0.0.1:8888/v1/models
视情况
我不想在两台 DGX Spark 上各保存一份 157 GiB checkpoint,能否用这个项目的 `DSPARK_WORKER_HF_NFS=1` 让 worker 通过 NFS 复用 head 的模型缓存?
适合读者: 已拥有两台 DGX Spark、需要在本地保存或通过 NFS 共享超大模型权重,并负责 Docker、SSH 和节点缓存一致性的基础设施工程师
视情况:项目明确支持 NFS 共享权重,但 worker 会依赖 head 的 NFS、ConnectX 链路和正确挂载,稳定性不如两节点各自保存缓存。
- Quick start 说明,默认
DSPARK_WORKER_HF_NFS=0会把 checkpoint 准备到 worker;设为1后,worker 通过 ConnectX 链路上的 NFSv4 挂载 head 缓存。 - NFS 模式仍需要设置
WORKER_HF_CACHE,它表示 worker 上的本地 JIT overlay,而不是简单取消 worker 的缓存配置。 - 启动前两台机器必须有相同 Docker 镜像;README 还要求在
.env.dspark中配置WORKER_DIR、WORKER_SCRIPT_DIR和缓存路径(如果 checkout 路径不同)。 - 权重准备阶段强制联网;缓存完整后才能切换
HF_HUB_OFFLINE=1。NFS 抖动、权限和挂载故障会直接影响 worker 加载。
- README Quick start:`Set DSPARK_WORKER_HF_NFS=1 to keep weights only on the head`
- README Quick start:`the worker mounts that cache over NFSv4 on the ConnectX link`
- README Quick start:`Default DSPARK_WORKER_HF_NFS=0 also downloads onto the worker`
- 项目洞察:支持每个节点独立保存权重,也支持 worker 通过 NFS 挂载 head 节点缓存
cp .env.dspark.example .env.dspark
适合
我想在两台 DGX Spark 上验证 `nvfp4_ds_mla`、默认 6 个 speculative tokens 和 1M 上下文,并进一步比较 TP=3;这个仓库适合做实验基线吗?
适合读者: 希望验证 DeepSeek MLA 的 NVFP4 KV 缓存、DSpark speculative decoding,并比较两节点 TP=2 与三节点 TP=3 的模型工程人员
适合做特定硬件和特定运行时的实验基线,但不适合把结果外推成通用 vLLM 或通用 GPU 结论。
- 默认运行时明确使用
--kv-cache-dtype nvfp4_ds_mla、分页 KV cache、chunked prefill、异步调度和 FlashInfer MoE 后端。 - DSpark speculative decoding 默认配置为
num_speculative_tokens: 6,实验可以直接从固定基线开始。 - TP=3 使用独立的
./start-tp3.sh,需要WORKER2_HOST;README 说明增加第三节点会提高总 KV 容量和多流吞吐,但会增加通信、padding 和 prefill 延迟。 - CI 只有 CPU-only 的
scripts/ci-validate.sh,不能验证真实 GPU tok/s、跨节点通信、视觉输入或长上下文稳定性;真实数据必须来自 2x 或 3x DGX Spark。
- README Runtime flags:`--kv-cache-dtype nvfp4_ds_mla`、`--enable-chunked-prefill`、`--async-scheduling`
- README Runtime flags:`num_speculative_tokens: 6`
- README:`Optional three Sparks (TP=3)`;`./start-tp3.sh`
- README:CI is `CPU-only`;Live tok/s still needs the 2× Spark pair
- 项目洞察:TP=3 可提高 KV 缓存容量和多流并发,但增加通信和 padding 开销
bash scripts/ci-validate.sh
✨ 核心亮点
-
vLLM TP=2 支持 DeepSeek-V4-Flash 的 1M 上下文
-
nvfp4_ds_mla KV 缓存池达 2,331,430 tokens
-
DSpark 提供 6-token speculative decoding
-
Anemll 0.1.1 启动热修复支持 image_url 与 path
-
TP=3 可达约 200 tok/s,但长上下文预填充变慢
🔧 工程化
-
用 start-deepseek-v4-flash-dspark.sh 启动两节点 vLLM 服务
-
提供 DeepSeek-V4-Flash-Vision-Exp 的 OpenAI image_url 接口
-
默认 max_model_len 为 1048576,max_num_seqs 为 6
-
可用 start-tp3.sh 扩展到三台 DGX Spark
⚠️ 风险
-
必须有两台 DGX Spark、RoCE/NCCL 和两节点同一镜像
-
默认双节点会准备 worker checkpoint,可能产生第二份权重
-
单用户长上下文不宜 TP=3,128K–256K 预填充慢约 22%
-
官方权重没有 video encoder,GIF 只处理为 still frame
-
CI 的 scripts/ci-validate.sh 仅 CPU,不能测量 tok/s
👥 适合谁?
-
拥有两台 DGX Spark 并能配置 RoCE/NCCL 的 vLLM 工程师
-
需要 DeepSeek-V4-Flash 1M 上下文与 image_url 的部署团队
-
希望用 TP=3 和 16 slots 承载多流请求的 DGX Spark 用户