DeepSeek V4.1 Flash 在 2 台 DGX Spark 上运行：社区基准测试

您可以运行 deepseek-ai/DeepSeek-V4.1-Flash——一个拥有 552B 参数的混合专家模型，具备原生视觉能力、1M token 上下文以及 MIT 开源许可——部署在 2 台通过 ConnectX-7 集群链路互联的 NVIDIA DGX Spark 上。截至 2026 年，多个独立的社区团队已发布了可复现的基准测试结果。该模型无法以完整 FP8 精度装入 256 GB 的聚合统一内存。但采用混合精度服务格式时可以运行——密集层保持 FP8，专家权重压缩至 4-bit。本页汇总了已发布的测试数据、服务配置方案以及各团队独立遇到的常见问题。本文是已退役模型 V4 Flash 0731 硬件指南的姊妹篇。

与 V4 Flash 0731 相比的变化

V4.1-Flash 相比其取代的先前版本（31 日发布），是一个规模显著更大的模型。

属性	V4-Flash-0731	V4.1-Flash
总参数量	~284B（+ DSpark head → ~304B）	~552B backbone + ~196B Engram → ~763B
每 token 激活参数	13B	8B input / 16B output（非对称）
权重下限（可下载）	~162–167 GB（GGUF）	~400 GiB（NVFP4 + MXFP4 Engram）
每 token KV cache	更大	890 bytes（缩小 3.9×）
上下文窗口	1M	1M
视觉能力	仅文本	原生文本 + 图像
许可证	MIT	MIT

权重下限翻倍以上。2 台 Spark 原先轻松运行 V4-Flash-0731（162 GB），现在需要混合精度策略才能容纳 V4.1-Flash（约 400 GiB）。

2 台 DGX Spark 的内存计算

每台 DGX Spark 配备 128 GB LPDDR5x 统一内存，带宽 273 GB/s。ConnectX-7 集群链路将两台 Spark 互联后，提供 256 GB 聚合内存和 ~200 Gb/s 的 RDMA 带宽（实测约 ~183–185 Gb/s）。 NVIDIA 的 NVFP4 变体将专家权重存储为 NVFP4（W4A4，group size 16），Engram 查找表存储为 MXFP4（E2M1），并为 attention、shared experts、vision 及 MTP/DSpark 层保留原始精度。当前版本（2026 年）磁盘总大小约 400 GiB。这无法装入 256 GB。社区验证可行的方案采用混合精度布局，服务框架进一步压缩专家权重，同时保持密集骨干网络处于较高精度。最终结果为每节点模型权重约 79–105 GiB，每节点剩余 23–49 GB 用于 KV cache、运行时缓冲区和操作系统。

组件	每节点（2 节点 TP=2）
模型权重	~79–105 GiB
KV cache	~15 GiB
系统与运行时开销	~8–12 GB
可用余量	~10–40 GB

NVFP4 的精度保持能力很强。NVIDIA 发布的基准对比显示，偏差不到 1%（对比 MXFP4 源数据），涵盖 GPQA Diamond（91.0 → 90.8）、SciCode（54.4 → 54.0）和 Terminal-Bench 2.1（81.6 → 81.9）。混合精度服务带来的质量损失对生产工作可忽略不计。

社区基准测试

多个团队已发布独立基准测试。数据因服务引擎、量化策略和并发级别而异。以下所有测量值均为 decode 吞吐量，单位为 tokens per second。

单流 decode（1 个并发请求）

来源	引擎	精度	tok/s	上下文
r0b0tlab	vLLM	FP8 + MXFP4 experts	38.4	65K
flowtivity.ai	vLLM	FP8 dense + MXFP4 experts	41.1	1M
tonyd2wild	TensorFold	EXL3 (3.5 bpw)	73.1	1M
知乎	vLLM	Mixed	79.0	长输出

多用户聚合吞吐量

并发数	tok/s（聚合）	来源
2 users	104–110	Level1Techs
4 users	135–169	Level1Techs / tonyd2wild
6 users	219–256	Level1Techs / NVIDIA forums
16 users	135–270	r0b0tlab / tonyd2wild

Prefill 速度

上下文长度	Prefill tok/s	来源
8K	~1,620	r0b0tlab
32K	~2,590–2,830	r0b0tlab
64K	~4,059–5,000	r0b0tlab
93K	~2,215	tonyd2wild
128K	~4,900–5,925	r0b0tlab

首 token 延迟

上下文	TTFT	来源
64K	31.3s	flowtivity.ai
256K	47.0s	flowtivity.ai
512K	334.4s	flowtivity.ai

512K 及以上的 TTFT 主要取决于对完整上下文的 prefill 处理。2 台 Spark 的互连有效吞吐量约 ~185 Gb/s，是长提示词的瓶颈。如果您的工作负载在长上下文下对延迟敏感，可考虑 4 台 Spark 以 TP=4 运行，此时 prefill 可扩展至 ~87 tok/s decode，TTFT 成比例下降。

配置

vLLM（推荐用于 2 台 Spark TP=2）

需要 vLLM v0.31.0 或更高版本。社区共识配置使用跨 2 个节点的分布式张量并行，配合 RoCE 网络。

vllm serve deepseek-ai/DeepSeek-V4.1-Flash \
  --tensor-parallel-size 2 \
  --kv-cache-dtype fp8_ds_mla \
  --block-size 256 \
  --max-model-len 524288 \
  --max-num-seqs 6 \
  --max-num-batched-tokens 4096 \
  --gpu-memory-utilization 0.82 \
  --enable-prefix-caching \
  --enable-chunked-prefill \
  --tokenizer-mode deepseek_v4 \
  --reasoning-parser deepseek_v4 \
  --tool-call-parser deepseek_v4 \
  --distributed-executor-backend mp \
  --nnodes 2

关键参数说明：

--kv-cache-dtype fp8_ds_mla — KV cache 使用 FP8，不要使用 nvfp4_ds_mla（原版 vLLM 不支持）
--max-model-len 524288 — 512K 是稳定的最佳选择；1M 可用但会降低 ~12% 的 decode 速度
--max-num-seqs 6 — 限制并发请求数；设为 6 以获得最大聚合吞吐量
--gpu-memory-utilization 0.82 — 为 KV cache 增长预留空间；在统一内存上不要超过 0.85

SGLang（推荐用于 3–4 台 Spark TP=3/4）

SGLang 的 dsv4.1 分支支持 3 或 4 的张量并行，配合 NVFP4 量化。

python -m sglang.launch_server \
  --model-path nvidia/DeepSeek-V4.1-Flash-NVFP4 \
  --tp 4 \
  --context-length 1048576 \
  --chunked-prefill-size 4096 \
  --max-running-requests 16 \
  --moe-runner-backend flashinfer_cutlass \
  --fp4-gemm-backend flashinfer_cutlass

网络配置

ConnectX-7 集群链路使用 RoCE v2（RDMA over Converged Ethernet）。关键环境变量：

export NCCL_IB_HCA=rocep1s0f1
export NCCL_BUFFSIZE=139000000

使用 GID index 3 进行 dual-rail 配置。社区报告显示，启用 dual-rail 后 decode 提升 +5%，长提示词 prefill 提升 +15%。管理网络运行在 192.168.1.0/24；模型数据流量使用独立子网（TP=4 环形拓扑使用 10.200.0.0/24 至 10.200.5.0/24）。

2 台 Spark 上的上下文长度

目标上下文	是否可行？	Decode 速度影响	最大并发数
64K	是	基准	6+
128K	是	~5% 降低	4–6
256K	是	~8% 降低	3–4
512K	是	~10% 降低	2–3
1M	是	~12% 降低	1–2

1M 上下文已由多个团队通过 needle-in-a-haystack 测试验证。FP8 下的 KV cache 每 token 使用 890 bytes，因此 1M tokens 消耗约 0.93 GB 的缓存内存——与权重占用相比相当有限。1M 上下文下的真正瓶颈不是内存而是 prefill 延迟：首个 token 预计需要 5 分钟以上（512K–1M 上下文）。

关键注意事项

以下是每个社区团队都独立遇到的问题。提前了解可以节省调试时间。

内核回归导致 NCCL RoCE 失效

内核版本 7.0.0-1019-nvidia 会导致 ibv_reg_mr_iova2 failed with error Cannot allocate memory。根本原因是 CmaTotal 降至 0 kB。可用的内核版本为 6.17.0-1032-nvidia。锁定内核版本并固定软件包：

sudo apt-mark hold linux-nvidia-hwe-24.04

问题内核的性能影响严重：prefill 从 ~2,600 tok/s 降至 ~1,430 tok/s（TTFT 下降 −47%）。

PyTorch 内存分配器导致 NaN logits

在启动 vLLM 之前设置此环境变量：

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:False

默认的 expandable_segments:True 会在生成约 64 个 tokens 后导致 NaN logits。这是 PyTorch 在统一内存（SM121）上的 bug，不是 vLLM 的问题。

Prefix caching 静默失败

并行的长上下文请求可能因混合 MLA/SWA attention 结构中的 block 驱逐而静默失败。设置保留间隔：

export VLLM_PREFIX_CACHE_RETENTION_INTERVAL=4096

DSpark 推测解码

如果您为编码工作负载启用 DSpark，请确保 DS4_SERVER_COALESCE_MAX 至少为 2。设为 1 会静默禁用推测功能。请使用 0731 专用的 drafter 文件——旧版 drafter 会因缺少 dspark.main_proj.weight 张量而报错。 DSpark 有助于提升编码吞吐量，但可能拖慢非编码任务。请在生产环境中启用前使用实际工作负载进行测试。

llama.cpp 的构建要求

如果您为 GB10（SM121）从源码构建 llama.cpp，必须设置：

cmake -DCMAKE_CUDA_ARCHITECTURES=121 ...

缺少此设置时，构建会静默回退到通用 CUDA 目标，性能显著下降。

与其他硬件的对比

2 台 DGX Spark vs Mac Studio M5 Ultra 256 GB

指标	2× DGX Spark	Mac Studio M5 Ultra 256 GB
内存	256 GB（128/节点）	256 GB 统一内存
带宽	273 GB/s 每节点	1.2 TB/s
V4.1 Flash 能否运行？	是（混合精度）	否（最小 GGUF 为 233 GB，无 KV 余量）
Decode c1	38–73 tok/s	N/A
Prefill 32K	~17s	~50s
部署复杂度	高（RoCE、NCCL、内核锁定）	低（即插即用）
总价格	~$6,000–7,000	~$8,500+

V4.1-Flash 无法在任何可用量化下装入单台 256 GB Mac Studio。512 GB Mac Studio 可以在 Q2_K–Q4 下运行，但 2–3× 于 2 台 Spark 的价格。

2 台 DGX Spark vs 4 台 DGX Spark

指标	2 台 Spark（TP=2）	4 台 Spark（TP=4）
Decode c1	38–73 tok/s	87–125 tok/s
Decode c16	135–270 tok/s	270–343 tok/s
上下文	1M（紧张）	1M（宽裕）
每节点内存	79–105 GiB	~72 GiB
KV 余量	10–40 GB/节点	~24 GB/节点
价格	~$6,000–7,000	~$12,000–14,000

4 台 Spark 大约将单流 decode 翻倍，并提供宽裕的 1M 上下文。2 台 Spark 是最低可行配置；4 台 Spark 是推荐的生产配置。

2 台 DGX Spark vs 2× RTX PRO 6000

指标	2× DGX Spark	2× RTX PRO 6000
内存	256 GB 统一内存	192 GB GDDR7
带宽	273 GB/s	1,792 GB/s
V4.1 Flash 能否运行？	是（混合精度）	是（FP4+FP8）
Decode c1	38–73 tok/s	106–210 tok/s
聚合 c10	~200 tok/s	~700 tok/s
功耗	~400W	~865W
价格	~$6,000–7,000	~$15,000+（工作站）

RTX PRO 6000 的内存带宽快 6.6×，吞吐量达 2–3 倍。DGX Spark 在价格和能效方面胜出。对于有实时延迟要求的生产服务，RTX PRO 6000 是更好的选择。对于全天候运行的个人或小型团队使用，DGX Spark 更实用。

通过 Tokios 暴露

当 2 台 Spark 集群运行正常后，将其通过单一认证端点暴露。

保持头节点上的模型服务器为私有

确认头 Spark 上的 vLLM 或 SGLang 进程在其回环 /v1 端点上响应，例如 http://127.0.0.1:8000/v1。Worker 之间的流量保持在集群网络上。

在头节点配对 1 个 connector

在 Tokios dashboard 中，打开 Setup 并选择 Start pairing。在头 Spark 上安装并运行 tokios-connector。Connector 通过 HTTPS 向外拨号——不需要入站端口。

配置头节点的上游

将 connector 的 BaseUrl 设为头节点的本地 /v1 端点。完整格式请参见 Connector 配置。

注册公开 deployment

在 Models 中，注册一个 deployment，例如 deepseek-v41-flash。将其映射到头节点服务器暴露的上游 model id。客户端发送 deployment 名称，而非 Hugging Face id。

创建限定范围的 API key

创建 sk-tok-… 密钥，在 Keys 中操作，可选限定范围为 deepseek-v41-flash。客户端随后调用 https://api.tokios.com/v1。

通过 Tokios 验证：

curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v41-flash",
    "messages": [{"role": "user", "content": "Summarize this deployment health check."}]
  }'

按此顺序验证

将内核锁定为 6.17.0-1032-nvidia，并确认 CmaTotal 非零。
设置 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:False。
完成 NVIDIA 的 2 台 Spark 网络配置（ConnectX-7、RoCE、子网）。
以 32K 上下文和 1 个并发请求加载模型。
发送短聊天请求、长提示词请求和工具调用请求。
记录内存消耗、首 token 延迟和生成速率。
将上下文提升至 128K、512K、1M——在每个阶段重复相同的工作负载。
最后才测试多用户并发。

此顺序将内核和网络故障与内存压力、KV cache 耗尽及工具格式问题区分开来。

V4 Flash 0731 硬件

上一代指南——284B 模型运行在 2 台 DGX Spark、2 块 RTX PRO 6000 或 2 套 Strix Halo 系统上。

DGX Spark 模型兼容性

1 台 Spark（128 GB）能运行什么——密集模型最高 70B Q4，MoE 最高 120B NVFP4。

一台 vs 两台 DGX Spark

何时应扩展到第二台 Spark 进行分布式推理。

DeepSeek 系列

V4.1-Flash 模型页面，包含标识符、能力及完整的 DeepSeek 产品线。

​与 V4 Flash 0731 相比的变化

​2 台 DGX Spark 的内存计算

​社区基准测试

​单流 decode（1 个并发请求）

​多用户聚合吞吐量

​Prefill 速度

​首 token 延迟

​配置

​vLLM（推荐用于 2 台 Spark TP=2）

​SGLang（推荐用于 3–4 台 Spark TP=3/4）

​网络配置

​2 台 Spark 上的上下文长度

​关键注意事项

​内核回归导致 NCCL RoCE 失效

​PyTorch 内存分配器导致 NaN logits

​Prefix caching 静默失败

​DSpark 推测解码

​llama.cpp 的构建要求

​与其他硬件的对比

​2 台 DGX Spark vs Mac Studio M5 Ultra 256 GB

​2 台 DGX Spark vs 4 台 DGX Spark

​2 台 DGX Spark vs 2× RTX PRO 6000

​通过 Tokios 暴露

​按此顺序验证

V4 Flash 0731 硬件

DGX Spark 模型兼容性

一台 vs 两台 DGX Spark

DeepSeek 系列

与 V4 Flash 0731 相比的变化

2 台 DGX Spark 的内存计算

社区基准测试

单流 decode（1 个并发请求）

多用户聚合吞吐量

Prefill 速度

首 token 延迟

配置

vLLM（推荐用于 2 台 Spark TP=2）

SGLang（推荐用于 3–4 台 Spark TP=3/4）

网络配置

2 台 Spark 上的上下文长度

关键注意事项

内核回归导致 NCCL RoCE 失效

PyTorch 内存分配器导致 NaN logits

Prefix caching 静默失败

DSpark 推测解码

llama.cpp 的构建要求

与其他硬件的对比

2 台 DGX Spark vs Mac Studio M5 Ultra 256 GB

2 台 DGX Spark vs 4 台 DGX Spark

2 台 DGX Spark vs 2× RTX PRO 6000

通过 Tokios 暴露

按此顺序验证