实测结果是可以用，而且不比交换机组网差：单流解码 75–108 tok/s，满并发（8 路）聚合解码 280→703 tok/s，16K 上下文 prefill ≈4.4k tok/s，1M 上下文单流 TTFT 71.6s / prefill 3.58k tok/s。今天把并发 × 上下文的二维矩阵整跑了一遍，数据附在下面。

使用方案：FujitsuPolycom/sparkring（Apache-2.0，自带 NCCL 补丁）的 deepseek-v41-flash-tp4 profile，模型是官方原始权重。

DeepSeek-V4.1-Flash TP4（四机环）部署与测试总结报告

一、模型与服务基本信息

• 模型名称：DeepSeek-V4.1-Flash（服务名 DeepSeek-V4.1-Flash-TP4）
• 权重版本：官方 checkpoint，pinned revision dba1be0a40aa，48 个 safetensors 分片，476 GiB
• 上游原生路线：github.com/FujitsuPolycom/sparkring — profile deepseek-v41-flash-tp4（recommendation: recommended，装机器镜像 dev-20261013-dcp2prefill-status038-sircl-tp6）
• 推理引擎：vLLM（SparkRing "Kraken" 分支 0.1.dev21553+gab86b7073）+ B12X 内核 + SIRCL 传输插件
• 硬件环境：4× NVIDIA DGX Spark（GB10，aarch64，单机 121 GiB 统一内存）
  • rank0 aitopatom-aca1（技嘉 AI TOP ATOM，Node A / 服务出口）｜ rank1 gx10-white（ASUS GX10）｜ rank2 gx10-black（ASUS GX10）｜ rank3 aitopatom-a9b6（技嘉 AI TOP ATOM）
  • 两家 OEM 的系统版本不同（GX10 = DGX OS 7.2.3 / 内核 6.17.0-1031-nvidia；AI TOP ATOM = DGX OS 7.4.0 / 内核 7.0.0-1019-nvidia），实测混装可以跑通
• 高速网络互连：无交换机环形拓扑，4 根 QSFP DAC 直连（p0 → 下一台 p1，无对角线），每台 2 个 CX7 200G 端口（每个端口两个 Socket Direct 功能，共 4 个 fabric netdev），整环 8 条逻辑通道
  • 环序：aitopatom-aca1 → gx10-white → gx10-black → aitopatom-a9b6 →（回到 aca1）
  • fabric 地址段 198.18.0.0/21，每根缆两个 /24；控制面走 WireGuard sr-control（10.253.255.1–4）

权重存储与挂载：环上没有贯通全环的 NFS 通路（对面节点不直连），所以四台各存一份完整 476 GiB 权重，本机 NVMe 直读；四机 × 48 分片全量 sha256 比对一致（192/192）。这跟交换机组网"HEAD 挂 NFS 给 worker 只读"的做法不同，是环拓扑的硬约束，也是安装前要预留 ~620 GB/台 空间的原因。

二、核心规格与配置参数

三、验证与测试数据

测试口径（全部一致）：

• 每档输出 128 tokens，填充文本带唯一 nonce + 递增编号 → 不命中 prefix 缓存；温度 0.6
• 单流 pp/tg = 各请求均值；聚合 pp = Σprompt / max(TTFT)；聚合 tg = Σcompletion / (max 总时长 − max TTFT)
• 并发 1/2/4/8（8 = 本部署的并发上限），上下文档位 1K → 512K

1. 基础功能与能力验证（栈自检，本机环上实跑）

四机环上自检全绿：All checks passed.

2. 长上下文阶梯压测（并发 1）

1M 上下文是配置上限，实跑验证到 512K：512K 单请求 TTFT 175.6s、prefill 2.92k tok/s，全程无 OOM、无换页。

3. 高并发 × 上下文 二维扫描

并发 2

并发 4

并发 8（满并发，= max-num-seqs）

4. 汇总对照

聚合解码吞吐（tokens/s）

单流解码吞吐（tokens/s）

聚合 prefill 吞吐（tokens/s）

几条结论：

• Prefill 与并发无关：1K→256K 区间聚合 prefill 基本贴在 4.0k–4.6k tok/s，四档并发几乎重合，直到 512K 才降到 2.9k。说明环拓扑的瓶颈不在 prefill 聚合带宽（8 条 200G 通道够用），而在单请求的长序列 attention。
• Decode 随并发放大：满并发 8 路时聚合解码从 1K 的 280.7 一路涨到 512K 的 703.5 tok/s——上下文越长、每步计算越"重"，批次填得越满，环上 all-reduce 的固定开销被摊得越薄。
• 单流解码 ~75–108 tok/s（与换长上下文无关，1K–512K 都在这个带内）——比交换机组网公开数据的 58–68 tok/s 略高，主要差在推测解码接受率（平均接受长度 3.65 / 接受率 61%）。
• 128 tokens 的短输出会低估真实吞吐：单流 tg 里含首几步的调度开销，实际长任务（几百到几千 token）会明显更好。

5. 与交换机组网公开数据的量级对照

口径不完全相同（输出长度 128 vs 64、软件栈不同），仅作量级参考：环拓扑在 TTFT / prefill 上明显更快，解码在一个带内偏上。"不用交换机就跑不动 TP=4"这个结论，至少在这套栈上可以推翻了。

除了手动更新机器、组网，环境全由hermes配置，耗时16小时，花销如图。