DeepSeek-V4 Flash:双DGX Spark的1M上下文vLLM配方
给两台DGX Spark部署DeepSeek-V4 Flash的vLLM配方,主打1M上下文和DSpark推测解码。
GitHub MiaAI-Lab/DeepSeek-v4-Flash-DSpark-2x-DGX-Spark 更新 2026-09-09 分支 main 星标 1.3K 分叉 179
Python Shell vLLM DeepSeek-V4-Flash-Vision-Exp DGX Spark RoCE/NCCL Docker

🧭 决策指南

适合,如果你

  • 你有两台 DGX Spark,并需要 DeepSeek-V4-Flash-Vision-Exp 的 1M-token 服务。
    README 的 Quick start 要求 two DGX Sparks;正文说明默认 max_model_len 为 1,048,576。
  • 你的集群已经具备 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_HOSTMASTER_ADDRNCCL_IB_HCANCCL_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
材料未说明:README 未说明是否有面向单机 Python 或普通 Docker 用户的自动化安装器、图形化配置界面或托管部署路径。;README 未说明不具备 DGX Spark 和 RoCE/NCCL 环境时能否运行功能等价的本地替代方案。
适合 我有两台 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=2nnodes 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
材料未说明:README 未给出你的具体 RoCE 网卡、GID、驱动版本和实际网络吞吐是否满足目标延迟。;README 未承诺 1M-token 请求的首 token 延迟或持续吞吐。
视情况 我计划让多个用户同时提交 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
材料未说明:README 未给出你实际输入长度分布、输出长度和多用户混合负载下的排队延迟。;README 未定义服务端队列的最大深度、请求超时策略或客户端限流机制。
适合 我需要通过 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
材料未说明:README 未说明单图分辨率上限、图片大小限制、视觉输入的额外显存占用和延迟。;README 未提供 OpenAI 客户端在多图、图片与超长文本组合请求下的完整兼容性矩阵。
视情况 我不想在两台 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_DIRWORKER_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
材料未说明:README 未给出你的 NFS 实际吞吐、挂载参数、权限配置和网络抖动容忍度。;README 未量化 NFS 模式相对于本地双份权重对启动时间和推理性能的影响。
适合 我想在两台 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
材料未说明:README 摘要未提供完整的 TP=2 与 TP=3 对比表,包括首 token 延迟、prefill 吞吐和 decode tok/s。;README 未说明 speculative decoding 在不同输出长度、thinking 模式和视觉请求下的接受率。

✨ 核心亮点

  • 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 用户