4 DGX Spark DeepSeek V4.1 Flash 1017版本详细测试数据！

[benton yi]

上一篇写的是这套无交换机环拓扑的部署。这次 DeepSeek 放了 V4.1-Flash-1017 新 checkpoint，我把栈升到配套的 SparkRing 版本、切到 1017 权重后，把同一套并发 × 上下文矩阵重新跑了一遍，并逐项和上一版（旧 663B checkpoint）做了对照。拓扑、机型、推理引擎都没变，变量只有权重版本 + 服务镜像。

---

一、测试环境与口径

项目	上一版（10-15）	本版（10-21 起服务）
权重 checkpoint	dba1be0a40aa	1bae0e108899（V4.1-Flash-1017），48 分片 475.3 GiB
服务名	DeepSeek-V4.1-Flash-TP4	DeepSeek-V4.1-Flash-1017-TP4
SparkRing	0.1.0~dev…+git928142a7b8d3	0.1.0~dev.1792279821+gitad1853fc4c4c
服务镜像	dev-20261013-dcp2prefill-status038	dev-20261016-sparkcache-4a17f1f5198e-status038
推理引擎	vLLM Kraken 0.1.dev21553+gab86b7073	同版本（未变）

本版实测服务规格（读容器启动参数与引擎日志，不是抄配置文档）：

参数	实测值
Context Length	1,048,576
Max Running Requests	8（max_num_seqs=8，CUDA Graph 捕获上限 96）
KV Cache	11,434,628 tokens（可用 KV 显存 14.23 GiB）；1M 单请求可支撑 10.90 路
静态显存比例	0.83
分块预填充	max_num_batched_tokens=8192 + chunked prefill
推测解码	DSpark，num_speculative_tokens=5、概率式草稿、块级拒绝、自适应验证
量化 / Engram	deepseek_v41_fp8；Engram 表 table_memory=disk + disk_resident_scales
环网传输	SIRCL；Transport: sircl, NCCL: absent
思考控制	默认 on · high，档位 low / high / xhigh(mx) / max / 1–100
多模态	limit_mm_per_prompt {"image": 4}，原生视觉
端点	http://192.168.10.10:8015/v1，无鉴权
四机 SM 时钟	2509 / 2522 / 2509 / 2541 MHz（max 3003），温度 53–56 °C，无降频
并发设置	--max-concurrency 8

与上一版相比 KV 池从 12,715,913 → 11,434,628 tokens（15.89 → 14.23 GiB），1M 单请求并发余量 12.13 → 10.90 路。新镜像的显存切分略有变化，权重本身大小一致。

测量口径（与上一版一致，便于逐格对照）：

• 每档输出 128 tokens；填充文本带唯一 nonce + 递增编号，不命中 prefix 缓存；温度 0.6
• 单流 pp/tg = 各请求均值；聚合 pp = Σprompt / max(TTFT)；聚合 tg = Σcompletion / (max 总时长 − max TTFT)
• 并发 1 / 2 / 4 / 8（8 = max-num-seqs 上限），上下文档位 1K → 512K
• 本版改进了采样方式：≤64K 各档每点跑 3 次取中位，因为发现每轮第一笔请求有约 2.2 秒冷启开销（稳态仅 0.98 秒，8 次连测标准差 0.01）；≥128K 各档单次采样，该区间冷启占比 <1%。上一版全部为单次采样。

---

二、栈自检（功能与能力，全部本机环上实跑）

测试项	输入	结果	状态
计数	1…20 顺序输出	20 个数全对（79 tokens）	PASS
算术	17 × 23	391（思考 19 tokens）	PASS
代码生成	Python is_prime(n)	完整可用实现（含类型校验与 n % 2/3 预筛）	PASS
工具调用	get_weather(巴黎)	正确发起 get_weather，参数 {"city":"巴黎"}	PASS
强制工具调用	tool_choice=required	正确发起 get_weather(罗马)	PASS
原生视觉	左红右蓝 128×64 PNG	「这张图左半边是红色，右半边是蓝色。」（202 vision tokens）	PASS
思考开关	chat_template_kwargs: {"thinking": false}	关：0 reasoning tokens 直答 391；开：18 reasoning tokens	PASS
思考档位	reasoning_effort 三档	low 83 / high 77 / max 169 reasoning tokens（同一问题）	PASS
传输层	本次集合通信走哪条路	Transport: sircl, NCCL: absent	PASS
频率	四机 SM 时钟	2509–2541 MHz（max 3003），无降频事件	PASS

能力边界说明：图文混合输入正常；音频输入不支持（服务端明确报 At most 0 audio(s) may be provided in one prompt）。思考链落在非标准字段 reasoning，不是 OpenAI 惯例的 reasoning_content——对接客户端时要注意这个字段名。

---

三、长上下文阶梯压测（并发 1）

目标上下文	实际 prompt tokens	TTFT	单流 prefill	单流解码	墙钟
1K	1,004	1.22s	821.3 tok/s	55.3 tok/s	3.75s
4K	3,800	1.84s	2,064.3 tok/s	71.5 tok/s	3.63s
8K	7,513	3.10s	2,427.1 tok/s	73.0 tok/s	5.01s
16K	14,955	4.39s	3,403.2 tok/s	83.7 tok/s	5.99s
32K	29,881	7.46s	4,006.8 tok/s	92.7 tok/s	8.84s
64K	61,913	15.30s	4,048.1 tok/s	102.6 tok/s	16.52s
128K	124,759	33.27s	3,750.3 tok/s	67.4 tok/s	35.17s
256K	250,485	73.30s	3,417.4 tok/s	75.5 tok/s	74.99s
512K	501,869	181.40s	2,766.6 tok/s	73.0 tok/s	183.15s

单流解码在 16K–64K 区间冲到 83.7 / 92.7 / 102.6 tok/s，是这版最突出的地方；512K 单请求 TTFT 181.4s、prefill 2.77k tok/s，全程无 OOM。

---

四、高并发 × 上下文 二维扫描

并发 2

上下文	prompt/请求	TTFT	单流 pp	单流 tg	聚合 pp	聚合 tg	墙钟
1K	1,002	1.43s	700.7	83.9	1,378.7	165.8	2.98s
4K	3,806	2.55s	1,491.1	81.8	2,928.3	158.3	4.21s
8K	7,512	4.05s	1,854.6	82.0	3,647.9	161.6	5.70s
16K	14,958	7.56s	1,977.6	91.1	3,919.9	177.3	9.15s
32K	29,867	14.44s	2,069.0	80.4	4,113.0	160.6	16.30s
64K	61,948	30.34s	2,041.9	81.6	4,057.9	158.7	32.09s
128K	124,759	64.15s	1,945.5	48.5	3,822.6	123.1	67.35s
256K	250,459	126.60s	2,041.0	35.2	3,366.4	135.1	150.69s
512K	501,900	283.78s	1,897.1	44.3	2,806.8	174.6	359.10s

并发 4

上下文	prompt/请求	TTFT	单流 pp	单流 tg	聚合 pp	聚合 tg	墙钟
1K	1,002	2.05s	489.9	59.4	1,926.3	216.2	4.55s
4K	3,802	4.42s	860.9	63.9	3,387.1	252.9	6.51s
8K	7,512	8.10s	927.8	67.8	3,655.8	261.4	10.18s
16K	14,960	14.70s	1,017.9	68.8	4,019.5	262.9	16.83s
32K	29,862	28.64s	1,043.4	66.2	4,118.5	281.1	30.89s
64K	61,922	57.51s	1,095.4	39.5	3,989.4	199.6	64.60s
128K	124,762	105.04s	1,295.0	26.7	3,795.9	237.3	133.63s
256K	250,490	205.25s	1,414.4	23.3	3,445.7	348.2	292.26s
512K	501,851	462.04s	1,343.9	20.8	2,843.2	313.2	707.67s

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

上下文	prompt/请求	TTFT	单流 pp	单流 tg	聚合 pp	聚合 tg	墙钟
1K	1,002	3.42s	296.7	47.4	2,282.3	358.0	6.62s
4K	3,800	8.43s	450.8	47.9	3,534.4	361.0	11.44s
8K	7,513	15.06s	499.1	48.5	3,922.9	403.2	17.84s
16K	14,963	29.03s	515.6	50.6	4,059.0	398.3	32.06s
32K	29,872	52.33s	586.0	35.7	4,084.0	463.7	60.68s
64K	61,930	93.28s	749.2	21.0	4,032.3	426.6	125.03s
128K	124,755	171.68s	903.9	12.9	3,851.2	527.0	261.09s
256K	250,465	356.33s	950.1	9.3	3,432.7	490.0	585.80s
512K	501,905	815.73s	887.3	11.8	2,860.1	672.8	1,405.41s

---

五、汇总对照

聚合解码吞吐（tokens/s）

上下文	并发 1	并发 2	并发 4	并发 8
1K	55.3	165.8	216.2	358.0
4K	71.5	158.3	252.9	361.0
8K	73.0	161.6	261.4	403.2
16K	83.7	177.3	262.9	398.3
32K	92.7	160.6	281.1	463.7
64K	102.6	158.7	199.6	426.6
128K	67.4	123.1	237.3	527.0
256K	75.5	135.1	348.2	490.0
512K	73.0	174.6	313.2	672.8

单流解码吞吐（tokens/s）

上下文	并发 1	并发 2	并发 4	并发 8
1K	55.3	83.9	59.4	47.4
4K	71.5	81.8	63.9	47.9
8K	73.0	82.0	67.8	48.5
16K	83.7	91.1	68.8	50.6
32K	92.7	80.4	66.2	35.7
64K	102.6	81.6	39.5	21.0
128K	67.4	48.5	26.7	12.9
256K	75.5	35.2	23.3	9.3
512K	73.0	44.3	20.8	11.8

聚合 prefill 吞吐（tokens/s）

上下文	并发 1	并发 2	并发 4	并发 8
1K	821.3	1,378.7	1,926.3	2,282.3
4K	2,064.3	2,928.3	3,387.1	3,534.4
8K	2,427.1	3,647.9	3,655.8	3,922.9
16K	3,403.2	3,919.9	4,019.5	4,059.0
32K	4,006.8	4,113.0	4,118.5	4,084.0
64K	4,048.1	4,057.9	3,989.4	4,032.3
128K	3,750.3	3,822.6	3,795.9	3,851.2
256K	3,417.4	3,366.4	3,445.7	3,432.7
512K	2,766.6	2,806.8	2,843.2	2,860.1

几条结论：

• Decode 随并发放大更明显：满并发 8 路聚合解码从 1K 的 358.0 涨到 8K–64K 的 398.3–463.7 tok/s，512K 达到 672.8。
• 单流解码不再被并发拖死：并发 8 下 8K / 16K 仍有 48.5 / 50.6 tok/s（上一版同档为 16.9 / 12.6）。
• Prefill 与并发无关：1K→128K 区间聚合 prefill 稳定在 3.5k–4.1k tok/s，四档并发几乎重合，512K 降到 2,860.1——瓶颈仍是单请求长序列 attention，不是环带宽。
• 128 tokens 的短输出会低估真实吞吐：单流 tg 含首几步调度开销，实际长任务会更好。

---

六、与上一版（旧 checkpoint）的性能对比小结

① 聚合解码吞吐 —— 并发 ≥2 时明显胜出；并发 1 与 128K 以上退步

上下文	并发 1	并发 2	并发 4	并发 8
1K	91.0→55.3 (-39%)	110.4→165.8 (+50%)	189.3→216.2 (+14%)	280.7→358.0 (+28%)
4K	96.5→71.5 (-26%)	143.6→158.3 (+10%)	199.0→252.9 (+27%)	256.9→361.0 (+41%)
8K	89.4→73.0 (-18%)	135.4→161.6 (+19%)	193.3→261.4 (+35%)	268.7→403.2 (+50%)
16K	75.1→83.7 (+11%)	127.8→177.3 (+39%)	206.1→262.9 (+28%)	280.3→398.3 (+42%)
32K	74.9→92.7 (+24%)	107.5→160.6 (+49%)	185.8→281.1 (+51%)	335.6→463.7 (+38%)
64K	90.7→102.6 (+13%)	153.7→158.7 (+3%)	237.4→199.6 (-16%)	437.9→426.6 (-3%)
128K	86.7→67.4 (-22%)	137.8→123.1 (-11%)	302.8→237.3 (-22%)	576.3→527.0 (-9%)
256K	107.9→75.5 (-30%)	134.9→135.1 (+0%)	339.4→348.2 (+3%)	574.0→490.0 (-15%)
512K	79.0→73.0 (-8%)	171.8→174.6 (+2%)	379.3→313.2 (-17%)	703.5→672.8 (-4%)

② 单流解码吞吐 —— 并发 ≥2 时大幅提升，并发 1 的中小上下文退步

上下文	并发 1	并发 2	并发 4	并发 8
1K	91.0→55.3 (-39%)	55.2→83.9 (+52%)	50.5→59.4 (+18%)	35.0→47.4 (+35%)
4K	96.5→71.5 (-26%)	60.3→81.8 (+36%)	40.1→63.9 (+59%)	25.3→47.9 (+89%)
8K	89.4→73.0 (-18%)	52.4→82.0 (+56%)	30.1→67.8 (+125%)	16.9→48.5 (+187%)
16K	75.1→83.7 (+11%)	44.3→91.1 (+106%)	24.5→68.8 (+181%)	12.6→50.6 (+302%)
32K	74.9→92.7 (+24%)	34.1→80.4 (+136%)	18.7→66.2 (+254%)	10.4→35.7 (+243%)
64K	90.7→102.6 (+13%)	42.7→81.6 (+91%)	18.4→39.5 (+115%)	9.7→21.0 (+116%)
128K	86.7→67.4 (-22%)	36.5→48.5 (+33%)	20.9→26.7 (+28%)	10.8→12.9 (+19%)
256K	107.9→75.5 (-30%)	34.6→35.2 (+2%)	22.4→23.3 (+4%)	10.4→9.3 (-11%)
512K	79.0→73.0 (-8%)	43.7→44.3 (+1%)	24.8→20.8 (-16%)	12.3→11.8 (-4%)

③ 首字延迟 TTFT —— 长上下文明显更快，短上下文更慢

上下文	并发 1	并发 2	并发 4	并发 8
1K	0.47s→1.22s (+160%)	0.64s→1.43s (+123%)	1.06s→2.05s (+93%)	2.27s→3.42s (+51%)
4K	0.99s→1.84s (+86%)	2.02s→2.55s (+26%)	3.65s→4.42s (+21%)	7.30s→8.43s (+15%)
8K	1.76s→3.10s (+76%)	3.52s→4.05s (+15%)	7.02s→8.10s (+15%)	14.24s→15.06s (+6%)
16K	3.43s→4.39s (+28%)	6.92s→7.56s (+9%)	14.87s→14.70s (-1%)	28.80s→29.03s (+1%)
32K	7.93s→7.46s (-6%)	14.02s→14.44s (+3%)	28.89s→28.64s (-1%)	57.46s→52.33s (-9%)
64K	14.35s→15.30s (+7%)	28.28s→30.34s (+7%)	59.54s→57.51s (-3%)	117.68s→93.28s (-21%)
128K	32.14s→33.27s (+4%)	62.84s→64.15s (+2%)	125.14s→105.04s (-16%)	253.92s→171.68s (-32%)
256K	71.61s→73.30s (+2%)	146.02s→126.60s (-13%)	288.52s→205.25s (-29%)	571.94s→356.33s (-38%)
512K	175.55s→181.40s (+3%)	349.99s→283.78s (-19%)	695.75s→462.04s (-34%)	1,396.56s→815.73s (-42%)

④ 聚合 prefill 吞吐 —— 本版唯一整体退步项

上下文	并发 1	并发 2	并发 4	并发 8
1K	2,363→821 (-65%)	3,443→1,379 (-60%)	4,137→1,926 (-53%)	3,888→2,282 (-41%)
4K	4,119→2,064 (-50%)	4,067→2,928 (-28%)	4,487→3,387 (-25%)	4,504→3,534 (-22%)
8K	4,529→2,427 (-46%)	4,525→3,648 (-19%)	4,580→3,656 (-20%)	4,565→3,923 (-14%)
16K	4,570→3,403 (-26%)	4,580→3,920 (-14%)	4,262→4,020 (-6%)	4,402→4,059 (-8%)
32K	4,002→4,007 (+0%)	4,482→4,113 (-8%)	4,327→4,118 (-5%)	4,352→4,084 (-6%)
64K	4,426→4,048 (-9%)	4,402→4,058 (-8%)	4,203→3,989 (-5%)	4,253→4,032 (-5%)
128K	3,976→3,750 (-6%)	4,026→3,823 (-5%)	4,024→3,796 (-6%)	3,966→3,851 (-3%)
256K	3,580→3,417 (-5%)	3,511→3,366 (-4%)	3,519→3,446 (-2%)	3,550→3,433 (-3%)
512K	2,924→2,767 (-5%)	2,905→2,807 (-3%)	2,922→2,843 (-3%)	2,904→2,860 (-2%)

对比要点

• 并发能力是这版的核心提升：并发 8 下 8K–32K 区间聚合解码提升 +38% ~ +50%，并发 4 下 4K–32K 提升 +27% ~ +51%。上一版满并发时单流被压到 9.7–16.9 tok/s（8K–64K），本版同档有 21.0–48.5 tok/s。
• 超长上下文 prefill 更快：512K 并发 8 的 TTFT 从 1,396.56s 降到 815.73s（-42%），128K/256K 分别 -32% / -38%。
• 短 prompt、低并发是明确退步：并发 1 的 1K/4K/8K 单流解码 91.0→55.3、96.5→71.5、89.4→73.0 tok/s；TTFT 1K 档 0.47s→1.22s。聚合 prefill 因此在小上下文掉 65% 左右。
• 墙钟基本持平：同规格任务的总耗时两版差异在 −3% ~ +3% 之间，最大差异出现在并发 8 × 512K（1,398s → 1,405s）。

---

七、两个反直觉的测量发现（供同好参考）

1. 每轮第一笔请求有约 2.2 秒冷启开销，稳态只要 0.98 秒。 同一个 1000-token 请求连测 8 次，首字延迟稳定在 0.96–0.99 秒（标准差 0.01）；而每次重新开跑的第一个 cell 会达到 2.2–2.5 秒。如果只做单次采样，就会把这个冷启算进表里——上一版的 1K 档 0.47s 和本版单采样的 2.2s 都不代表稳态。
2. TTFT 可以拟合成一条直线：阶梯实验（160 / 997 / 3,719 / 7,365 / 14,640 prompt tokens）得到 TTFT ≈ 0.8s 固定 + prompt_tokens / 4,700 (t/s)。也就是说这版有约 0.8 秒的固定首字成本，短 prompt 时被放大成几倍差距，长 prompt 时完全被淹没——这也解释了为什么 prefill 吞吐在小上下文退步、在 128K 以上反而变好。

---

八、结论

1. 1017 版是「高并发 / 长上下文」取向的版本。 并发 8 路时聚合解码比上一版高 +38% ~ +50%（8K–32K），单流也不再被并发压死；超长上下文（128K–512K）并发 8 的 TTFT 快 32%–42%。
2. 代价是短 prompt / 低并发的首字延迟：约 0.8 秒固定开销让 1K–8K 的 prefill 吞吐掉 40%+，单流解码在并发 1 时也从 ~90 掉到 ~55–73 tok/s。
3. 实际选型建议：如果负载是「多轮 agent、工具调用、批量并发」（典型如 Hermes 这类前端），1017 更合适，尤其是并发 ≥2 之后；如果是「单用户、短问短答、极在意首字延迟」，旧版在同硬件上反而更顺手。
4. 环拓扑本身没有任何变化：四机 4 根 DAC、无交换机、SIRCL 传输，512K 满并发 1,405 秒跑完、全程无 OOM。换 checkpoint 不影响这套拓扑的可用性。

[Xiaote]

版主审定：本帖设为精华，作者 +6 积分奖励，希望再接再厉！

奖励凭证：精华 +6 分 · 编号 f2946-18-1

[terry]

母帖地址：https://lcz.me/topic/2346 APP未做解析，贴上来方便浏览。

[terry]

正好准备做视频，直接水一期，明天又可以玩游戏了。

[xiongjie gao]

熟读这张表格并牢记结论，可以在绝大多数场合装波大的

[terry]

@xiongjie-gao 我已经开启装逼模式，视频马上录制！