> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokios.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel.
> Use 'connector' for the local tokios-connector process.
> Use 'deployment' for the public model name in the API model field.
> Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend.
> API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-.

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

> DeepSeek V4.1 Flash（552B MoE）在 2 台 NVIDIA DGX Spark 上通过 RoCE 张量并行运行的社区基准测试、配置方案及常见问题。包含 vLLM 和 SGLang 部署指南。

您可以运行 `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 硬件指南](https://docs.tokios.com/blog/deepseek-v4-flash-local-hardware.md)的姊妹篇。

## 与 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 变体](https://huggingface.co/nvidia/DeepSeek-V4.1-Flash-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 |

> [!TIP]
>
> 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](https://github.com/r0b0tlab/deepseek-v4-flash-nvfp4-gb10-benchmark) | vLLM | FP8 + MXFP4 experts | 38.4 | 65K |
| [flowtivity.ai](https://flowtivity.ai/blog/deepseek-v4-flash-1m-context-dual-dgx-spark/) | vLLM | FP8 dense + MXFP4 experts | 41.1 | 1M |
| [tonyd2wild](https://github.com/tonyd2wild/DeepSeek-V4.1-Flash-vLLM-DGX-Spark) | TensorFold | EXL3 (3.5 bpw) | 73.1 | 1M |
| [知乎](https://zhuanlan.zhihu.com/p/2067961897207456860) | 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 |

> [!NOTE]
>
> 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 网络。

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
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 量化。

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
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）。关键环境变量：

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
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`。

锁定内核版本并固定软件包：

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
sudo apt-mark hold linux-nvidia-hwe-24.04
```

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

### PyTorch 内存分配器导致 NaN logits

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

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
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 驱逐而静默失败。设置保留间隔：

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
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，必须设置：

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
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 集群运行正常后，将其通过单一认证端点暴露。

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

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

**2. 在头节点配对 1 个 connector**

在 [Tokios dashboard](https://tokios.com/console) 中，打开 **Setup** 并选择 **Start pairing**。在头 Spark 上安装并运行 `tokios-connector`。Connector 通过 HTTPS 向外拨号——不需要入站端口。

**3. 配置头节点的上游**

将 connector 的 `BaseUrl` 设为头节点的本地 `/v1` 端点。完整格式请参见 [Connector 配置](https://docs.tokios.com/reference/connector-config.md)。

**4. 注册公开 deployment**

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

**5. 创建限定范围的 API key**

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

**通过 Tokios 验证：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
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."}]
  }'
```

## 按此顺序验证

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

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

> **[V4 Flash 0731 硬件](https://docs.tokios.com/blog/deepseek-v4-flash-local-hardware.md)**
>
> 上一代指南——284B 模型运行在 2 台 DGX Spark、2 块 RTX PRO 6000 或 2 套 Strix Halo 系统上。

> **[DGX Spark 模型兼容性](https://docs.tokios.com/guides/dgx-spark-model-compatibility.md)**
>
> 1 台 Spark（128 GB）能运行什么——密集模型最高 70B Q4，MoE 最高 120B NVFP4。

> **[一台 vs 两台 DGX Spark](https://docs.tokios.com/guides/one-vs-two-dgx-sparks.md)**
>
> 何时应扩展到第二台 Spark 进行分布式推理。

> **[DeepSeek 系列](https://docs.tokios.com/models/deepseek.md)**
>
> V4.1-Flash 模型页面，包含标识符、能力及完整的 DeepSeek 产品线。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.