把 DeepSeek-V4.1-Flash 塞进 8 张 910B4：一份「成功与失败各一半」的调优复盘

时间跨度：2026-10-18 ~ 10-21
硬件：8 × 昇腾 910B4-1（单机，NPU 间 HCCS，CPU↔NPU PCIe 16GT/s x16）
模型：DeepSeek-V4.1-Flash W4A8（673 GB，含 221 GB Engram 表）
目标：交互式问答 + 长文档问答混跑，单实例 TP8+EP8

---

0. 先说结论

四天下来，真正被数据支持的改动只有 4 个；被证否的有 8 个；还有 6 个问题到现在没解决。

类别	数量	代表
确认有效	4	gate 让位 + 短请求优先、Engram numba JIT、RoPE 取表融合、图片上限 4→16
证否	8	MAX_PREFILL=8、MOE AllGather、GPU_UTIL 0.94、限流、BetterScale 直装、cross_step 移植、O_PROJ_2D、ENGRAM_GATE_CHUNK
未解决	6	长文 TTFT 下限、饱和态 TPOT 尾部、/v1/responses 的 developer 角色、日志刷屏、4.0 的首字/吞吐不可兼得、PD 分离未验

如果只记一句话：在这台机器上，“结构性误解"造成的损失远大于"参数没调对”。 八次失败里有五次是因为我把 A3 的经验直接搬到了 A2。

---

1. 起点：4.0 到底慢在哪

4.0（旧模型，W8A8，800K 上下文）在混合负载下是这样：

指标	4.0
chat 首字 p50	19.3 s
chat 首字 p95	82.5 s
出字间隔 TPOT p50	188 ms
完成速率	0.43 rps
prompt 吞吐	5,160 tok/s

看起来"吞吐不差、出字还快"，但首字 19 秒意味着交互式场景不可用。
诊断结论：4.0 不是算力不够，是decode 被 prefill 整段挡住——一篇 5 万 token 的文档进来，所有正在出字的请求全部停住，等它 prefill 完。

这就是后来一切优化的出发点：问题不是"算得慢"，是"排队方式不对"。

---

2. 四个真正起作用的决策

2.1 admission gate：把"整段冻结"改成"一步一让"

原始行为（vLLM 默认混批）：一步里既有 prefill 又有 decode，长 prefill 会把 decode 饿死。

第一版做法：隔离——一步要么做 prefill、要么做 decode。
结果：短请求不再被长文饿死，但长文 prefill 的整段时间里 decode 完全停摆，最长 40 秒。

第二版做法（关键）：在隔离的基础上加"让位"——
每 K 个 prefill 步插入 1 个 decode 步（V41_GATE_YIELD_EVERY=1），
并且短请求（≤8192 token）优先，长文最多被连续插队 4 步（V41_GATE_LONG_MAX_DEFER=4）。

实测（同负载 λ=0.45、cap=32、480 s、211 笔 0 失败）：

	只隔离（v9）	隔离 + 让位（v10）
chat 首字 p50	785 ms	954 ms
chat 首字 p90	32.4 s	2.67 s
chat 首字 p95	54.1 s	6.78 s
完成速率	0.44 rps	0.35 rps
TPOT p50	266 ms	351 ms

代价必须说清楚：吞吐掉了 20%，TPOT 中位数涨了 32%。
这不是"变快"，是"重新分配等待"——把少数人 54 秒的干等，摊成所有人多等 0.2 秒。
如果你只看 p50，会以为改坏了；只有看 p90/p95 才知道改对了。

这条经验后来反复用到：延迟优化常常是"平移"而不是"减少"，报数字必须报分位数，不能报均值。

2.2 找到"门控 env 传不进 worker"这个隐形坑

这是四天里最有价值的一次只读排查。

起服脚本 serve_1017_gpustack.sh 里 export 了 40 多个 V41_* 开关。但真正跑模型的进程根本拿不到：

进程	环境条目	其中 V41_
pid 1（API Server）	142	51
pid 495（EngineCore）	54	9
pid 545（Worker）	54	9

连我们自己加进 GPUStack 模型 env 的 V41_GATE_YIELD_EVERY 也没到 worker，而 MAX_SEQS、BAT_TOKENS 到了。

后果：worker 读 os.environ 拿不到 → 走代码默认值 → 14 个补丁里 6 个静默失效。

决策：不修 env 传递（mechanism 没查清、风险大），直接把目标值写进代码默认值。
一次镜像构建解决，绕开整条不可靠的链路。

这个决定后来救了很多时间，也顺手解释了另一个谜：_correct_optimistic_seq_lens_cpu 在 V1 路径全树无调用者——我们跑的版本早就不靠它了。

2.3 Engram JIT + RoPE 取表：中位数实打实降了

开了 V41_ENGRAM_JIT=1 与 V41_ROPE_IDXSEL=1 之后（稳态、池化两轮）：

类别	改前 TPOT p50	改后	变化
chat	351 ms	321 ms	−8.5%
doc_qa	319 ms	244 ms	−23.5%
long_doc	380 ms	286 ms	−24.7%

意外之处：厂商口径这两项合计只有 −1.0~1.2 ms，我们实测降了 30~40 ms。
两种解释无法区分（A2 上 Engram host 路径更慢、JIT 收益更大 / 运行间噪声），
但三个类别方向一致，不像纯噪声。

2.4 图片上限 4 → 16：先算清代价再改

--limit-mm-per-prompt '{"image": 4}' 卡在 4 张。改之前先算了两笔账：

• 上下文：vision_config 里 max_image_tokens=1024、patch_size=14、downsample_ratio=3
  ⇒ 每图 ≈(H/42)×(W/42) token，1024² 约 576 token。16 张 ≈ 16,384 token = 1M 上下文的 1.6%，可忽略。
• 显存：vLLM 的 profile_run 是按 limit_mm_per_prompt 造 dummy 输入的，改大会抬高 profiling 峰值，挤压 KV。

实测结果：KV 2,959,723 tokens 一 token 未变，峰值仍 3.21 GiB。边界验证：

 4 张 → 200  prompt_tokens=1120
16 张 → 200  prompt_tokens=4432   ← 正好线性放大，说明 16 张全编码
17 张 → 400  At most 16 image(s)

---

3. 八次失败的尝试（每次写清怎么失败的）

3.1 ENGRAM_DEVICE_INDEX=1：17 分钟后必然崩

想把 Engram 表从 host 拉到设备直读。设 =1 后起服能过，17 分钟后报 207001，然后进入崩溃循环。

根因不在代码，在硬件：/proc/svm/dev0/feature/host_mem_pool = 0。
8 张卡全 0 ⇒ 该能力需要 hccs_connect() 成立（A3/910C/d803 才有），A2 上软件无解。
改用 auto（自动回落到 host 分片路径），功能与精度不变，只是没有那 3.3 ms 的加速。

教训：判据不要看机型名，要看 /proc/svm/devN/feature/*。

3.2 镜像选错 SOC：一句 README 差了两个小时

README 推荐 …:deepseek-v4.1-flash-a3，但那是 SOC_VERSION=ascend910_9391，给 910C 的。
910B4 要用 …:deepseek-v4.1-flash（ascend910b1）。两版 vllm/vllm-ascend commit 完全相同，
只有 SOC 不同，所以从报错信息上完全看不出问题。

3.3 图捕获桶不够：不是"慢一点"，是引擎猝死

cudagraph_capture_sizes 的桶是按每步 token 数划分的。decode 每步 token ≈ 并发 × (1+草稿接受长度)，
本机实测接受长度 2.4–2.6 ⇒ c=32 时每步约 110 token。

桶不够时不会"降级运行"，而是掉进运行时临时捕获/静态核编译路径，
最后8 张卡拿到同一个 VA，引擎直接死。
纯吞吐角度也是 5.9 vs 35.3 tok/s（6 倍） 的差距。

规则：max(bucket) ≥ MAX_SEQS × (1 + num_speculative_tokens)。
代价是冷启动变长（≤32 时 12 min → ≤192 时 23–30 min），但 KV 不变。

3.4 守护探针误杀长 prefill：93 万 token 的请求必然"看起来死了"

守护脚本每 ~60 s 发一笔 max_tokens=1 的探针，curl -m 45，失败 2 次就重启容器。

问题：admission gate 下长 prompt 是 100+ 个连续的 prefill-only 步，小请求根本排不进去。
93 万 token 的单请求要 6 分钟 ⇒ 探针必然 000 ⇒ 必然被杀。

更糟的是 fail 计数跨请求累计：上一笔长请求拖死一次探针，下一笔只要再撞一次就被杀（实测 800K→950K 只活了 54 秒）。

修法：判据从"探针有没有回"改成"引擎有没有在推进"——近 120 s 有非零吞吐或新的 prefill-only step #N 就算 BUSY。

3.5 前缀缓存把 prefill 测速放大了近一倍

用同一份语料"逐档加长"测 prefill，表观 8.7k tok/s，看起来很美。
实际引擎只算了增量——usage.prompt_tokens 是全量，但缓存命中的部分不耗时。

修正后真实值：4.7k@100K、4.0k@190K、3.3k@325K、2.7k@500K、2.2k@700K tok/s。

方法学教训：每档必须换 salt（≥128 token 的唯一前缀）打断前缀缓存，否则测的是缓存命中率。

3.6 MAX_PREFILL=8：吞吐没涨，长文被拖慢 72%

厂商说把这个从 1 调到 8 能 +11% 吞吐。我们实测：

	MAX_PREFILL=1	=8
prompt 吞吐	4,176 tok/s	4,190（+0.3%，等于没涨）
doc_qa 首字 p90	3,787 ms	6,505（+72%）
long_doc 首字 p50	12,953 ms	16,804（+30%）
rag_huge 首字 p50	34,823 ms	48,196（+38%）

机制：BAT_TOKENS=8192 是一个 prefill 步的总预算。放 8 个请求进去，每个每步只推进约 1/8 个块（≈1024 token），
一篇 5.5 万 token 的文档要多花 8 倍步数才 prefill 完。

厂商数字没错，是场景不同：他们假设"prefill 没打满"；我们 prefill 需求 5,034 tok/s 已超引擎能力（≈4,200），
持续饱和时把更多请求塞进一个步，不增加总吞吐，只改变"谁先被服务"。

已回退到 1。

3.7 MOE_COMM_ALLGATHER=1：A3 上 −4.25 ms，A2 上 +12%

厂商口径：128K 单流 −4.25 ms/step，输出逐字节一致，KV 还会变大。
我们两轮池化实测（稳态）：

类别	关	开
chat TPOT p50	321 ms	360（+12%）
doc_qa TPOT p50	244 ms	266（+9%）
long_doc TPOT p90	426 ms	624（+46%）
long_doc 首字 p50	15.8 s	18.1 s（+14%）

为什么反过来：AllGather 的收益前提是"每个 rank 只拿到 1 个 token，标量开销被摊薄"，
代价是每个 rank 都要持有全量 token。A3 的 CPU↔NPU 走 HCCS，这份复制几乎免费；
A2 走 PCIe（约 25 GB/s），复制 8 份的代价压过了标量收益。

教训（现在写进了纪律）：涉及集合通信的补丁，先问拓扑，再看厂商数字。

3.8 BetterScale 直装：设计成"宁可拒绝起服"

vllm-betterscale 0.4.1 看起来很对路（Ascend + DeepSeek V4 + DSpark K5）。实际装不上，三道闸：

1. 版本：要 vllm 0.25.1 / vllm-ascend 0.25.1rc1 / torch-npu 2.10.0.post2；
   我们是 0.27.1 / 0.1.dev5097+ge43cf1e9f / 2.10.0.post4。
2. 源文件哈希：它对 19~20 个上游文件做 SHA256 校验，其中一个正是我们改过的 attention/dsa_v1.py。
3. fail-closed：不匹配直接 RuntimeError("Incompatible donor environment; no patches applied")，
   一个补丁都不打。

而且 0.5.1 的 pins.json 与 0.4.1 完全相同——升级也救不了。

它是"给净上游树"设计的，我们是"整棵树都改过"的定制 fork。这不是配置问题，是互斥。

3.9 cross_step 移植：写完评估才发现，上游早就实现了

cross_step 声称能把 TPOT 再降 10–20%。我准备移植时先做可行性核查，结果整个移植被否掉：

cross_step 的做法	我们的代码
把 CPU 记账回调推迟到 forward 之后	model_runner_v1.py:2526 注释原文：“Now the batch has been launched we can wait for corrections … without breaking async scheduling”
跳过 _correct_optimistic_seq_lens_cpu	该函数 :1702 有定义，V1 路径全树无调用者（只剩 310p 平台用）
用乐观上界做 tiling	:3336 已经 seq_lens_cpu_upper_bound=self.optimistic_seq_lens_cpu[...]

根因：它 pin 的是 0.25.1，我们跑 0.27.1——差两代，思路已被上游吸收。

硬移植还会撞三条断言：model_type == "deepseek_v4"（我们是 v41）、not supports_mm_inputs（我们是多模态）、
依赖 r.prepare_inputs_event（我们树里 grep 0 次）。

这一步省掉了一个 28 分钟窗口和一次高风险改动。

---

4. 还没解决的问题（截止 10-21）

4.1 长文首字有物理下限，调度改不了

输入长度	自身 prefill 时间
5K	1–2 s
70K	15–28 s
960K	365 s

让位机制能把"别人被冻住的时间"压到 1–2 秒，但长文自己的首字不可能快于它自己的 prefill。
唯一出路是少 token、异步化、或换硬件。

4.2 饱和态 TPOT 尾部

32 并发打满时 TPOT p50 约 320 ms、p90 548 ms。
中位数已经比改前好，但尾部仍然偏高。原因大概率还是"decode 步被 prefill 步切碎"，但 K 调大又会恶化首字——这是同一枚硬币的两面。

4.3 /v1/responses 不支持 developer 角色（我们的 bug）

AssertionError: Invalid message for role `developer`
  at tokenizers/deepseek_v4_encoding.py:243

Codex 桌面版用 role:"developer"（OpenAI 新写法），这条路 49 次全 500、0 成功。
对照：同样角色走 /v1/chat/completions 是 200——chat 路径做了归一化，responses 路径没有。
4.0 也一样坏（同一份代码）。修法：把 developer 映射成 system，约 5 行，待排窗口。

4.4 日志 90% 是诊断探针，且看不到模型输出

近 2000 行里 [bneck] 占 1,802 行（90%），速率 4.3 行/秒，容器日志 22 小时 21 MB，
而 daemon.json 没有 log-opts，等于不轮转。

中途还纠正过一个错误判断：我原以为 --enable-log-outputs 会连带打印整段 prompt，
读源码后发现 log_inputs 是 logger.debug、log_outputs 是 logger.info——
我们跑 INFO，所以开这两个开关只打输出、不打 prompt。
⇒ 修法从"改代码"降级成"加三个启动参数"：--enable-log-requests --enable-log-outputs --max-log-len=512。

4.5 4.0 与 4.1 的取舍是结构性的

	4.0	4.1（当前）
chat 首字 p50	19.3 s	0.97 s
TPOT p50	188 ms	321 ms
吞吐	0.43 rps	0.36 rps

没有配置能同时赢两头。要"首字快"就选 4.1；要"吞吐高、出字快"就选 4.0 但接受 19 秒首字。
再往上只有结构性手段：DP 多副本 / PD 分离 / 换硬件，都不是调参。

4.5.1 一个容易误判的点：4.0 并没有"另一套调度"

很多人（包括我一开始）以为 4.0 是"混批、decode 优先"，所以没有 prefill 饿死 decode 的问题。不是。

查两个镜像的 scheduler.py：两边都有 admission gate 的代码（各 5 处），
4.0 的入口脚本 serve_gpustack.sh:63 也写着 export VLLM_ADMISSION_GATE=${VLLM_ADMISSION_GATE:-1}。
也就是说 4.0 同样是"隔离式"调度，只是没有让位——它等价于我们的 v9-1017 那一版。

真正的差别在KV 容量：

	4.0	4.1
KV 池	808,653 tokens	2,959,723 tokens（3.7×）
max_model_len	800,000	1,048,576

4.0 的 KV 池只够装一次满长度请求。于是请求大量卡在准入层排队，
首字 19 秒里绝大部分是"等 KV"，而不是"等 prefill"。
症状被排队掩盖了，看起来像"它的调度没问题"。

同一套 p150 验收里，4.0 的 PREFILL_STARVE 是 2,456 ms，比 1017 的 788 ms 更差；
c=4 短请求首字 p95：4.0 的 30 秒 vs 1017 的 1.2 秒。
所以不是"4.0 没这个问题"，是"4.0 的问题更重，只是被 KV 排队盖住了"。

4.6 PD 分离在这台机器上装不下（不是没验，是算不过来）

我一开始把这条写成"未验证"。后来把权重占用摊开一算，结论变了：同机 8 卡做不了 PD 分离。

算术如下（数字全部来自起服日志）：

项	值
单卡可用 HBM	60.96 GiB
每 rank 权重（TP8）	38.7 GiB（占单卡 63.5%）
整机权重合计	38.7 × 8 = 309.6 GiB
每 rank 峰值激活 / 非 torch / 图	3.21 / 0.9 / 0.46 GiB
每 rank KV	13.26 GiB

PD 分离要求 P 侧和 D 侧各自都是一套完整模型。把 8 卡切成 4+4：

每 rank 权重 = 38.7 × 8 / 4 = 77.4 GiB  >  60.96 GiB
                       超出 16.4 GiB —— 连权重都放不下，KV 无从谈起

想只放权重不留 KV，每个实例至少需要 309.6 / 60.96 = 5.08 → 6 卡；
两个实例就是 12 卡，而我们只有 8 卡。

再叠加一个约束：num_attention_heads = 64，TP 只能取 1/2/4/8/16/32/64。
TP4 已经超出显存，TP8 是唯一可行值 —— 也就是"8 卡必须全给一个实例"。

这也正好解释了厂商为什么能在大 A3 上做 CED：910C 一张卡 2 个 die，8 卡 = 16 个 device，
所以 P8 + D8 是在同一台机器内切 16 份，装得下。
A2 一张卡 1 个 die，8 卡就是 8 个 device —— 没有第二组卡可以给另一边。

顺带修正上一版的一个说法：A2 上 CED 那条 _pool_kernel 的 MTE/SMMU 故障，
是厂商在 A3 上做 CED 时留下的记录，不是"我们在 A2 上试过"。
我们根本没试，因为第一步就装不下。

所以这条不是"待验证"，是"要第二台机器"。 跨机 PD 需要 P 机 + D 机各 8 卡（KV 走网络传），
我们手上只有这一台。

---

附：14 个补丁的状态（不算独立问题，但必须知道）

#	补丁	状态
1/6	Engram host 常驻	✅ 生效
2/3/4	Engram numba JIT	✅ 生效
5	Engram gate 分块	❌ 从未试过（一直是 0=stock）
7	MoE AllGather	❌ 试过，负结果
8	wo_a 2D matmul	❌ 从未试过（收益 < 噪声）
9	MoE mask 区间比较	✅ 生效
10	RoPE 取表融合	✅ 生效
11	QLI 无候选	➖ 代码里已无该开关
12/13	Engram 设备直索引	⚠️ A2 按设计回退
14	admission gate	✅ 生效（MAX_PREFILL 试 8 失败，回退 1）

11 个试过（其中 2 个负结果）、2 个没试、1 个不适用。

---

5. 方法论：这次真正沉淀下来的东西

5.1 单次 480 秒的跑分，判不了 ±20% 的差异

同一配置连跑两轮，chat TPOT p50 出现 384 vs 317 的摆动。
⇒ 任何 A/B 至少两轮，必须池化。

5.2 必须排除预热段

起跑前 80 秒的 TPOT 尖峰，我一开始归因为"JIT 首次编译"。后来用两条证据推翻：
① 进程已热一小时的第二轮，仍有 16 个起跑尖峰；
② 每个尖峰样本都伴随"有长请求在飞"，而后段尖峰率只有 0–1.8%。

真实原因是队头阻塞：起跑瞬间队列为空，几篇长文档同时进 prefill，K=1 让位下每输出一个 token 要等一个 prefill 块。
是测试负载 t=0 冷队列的产物，不是配置缺陷。

5.3 评估外部补丁的三步判断法

1. 它 hook 哪个函数 → grep 我们的树里有没有；
2. 它依赖哪些私有属性 → 逐个查，缺一个就评估替代成本；
3. 我们的版本比它 pin 的版本新几代 → 新两代以上，先怀疑已被上游吸收。

今天第 3 条直接否掉了 cross_step 整个移植。

5.4 延迟优化要报分位数，不要报均值

gate 让位让 p50 变差、p90/p95 大幅变好。
"平均值"在这种长尾场景里几乎没有信息量。

---

6. 当前生产状态

镜像    dsv41-1017:v12-gates（b950330a73c9）
端口    40046
门控    MAX_PREFILL=1  ENGRAM_JIT=1  ROPE_IDXSEL=1  MOE_COMM_ALLGATHER=0
图片    --limit-mm-per-prompt {"image": 16}
KV      2,959,723 tokens / 13.26 GiB
峰值    3.21 GiB（profiling）
余量    8.0 GiB（60.96 − 52.96）
错误    0 条 Engine core died / Traceback / invariant violated

四个镜像都留着，回滚一条命令切回 v2-yield（v10 基线）。

---

7. 来源

7.1 博主与代码仓库

这套 DeepSeek-V4.1-Flash 昇腾适配与 14 个补丁，来自博主 chiro2001：

• GitHub：https://github.com/chiro2001/deepseek-v4.1-flash-ascend910B
  仓库描述（原文）：“DeepSeek-V4.1-Flash W4A8 optimized vLLM deployment for Ascend 910B (A2) / 910C (A3): patches, one-command serve, self-check and acceptance”，Apache-2.0。
• Gitee 镜像：https://gitee.com/zuolg/deepseek-v4.1-flash-ascend910B
  （与 GitHub 同一 HEAD 889a6a92，作者同一人，patches/ 目录逐文件相同）

仓库 README 里有一条值得注意的声明：“历史基础包的优化工作（算子分析、补丁编写、性能调优、文档）
均由 deepseek-v4.1-flash 模型自主完成，未经人工逐行改写。”
也就是说，这 14 个补丁本身很大程度上是模型自己产出的——我们这次做的是核实它们是否真的生效。

仓库里有两套补丁形态，内容等价：

形态	位置	数量	用法
git-am 系列	patches/vllm-ascend/0001..0010 + patches/vllm/0001	11	git am
整文件覆盖	patches/files/*.py	14	直接 COPY 进镜像

注意：patches/vllm-ascend/base.txt 写的是 46856f89，而实际镜像的 vllm-ascend HEAD 是 e43cf1e9f。
这套 git-am 打不到实际运行的树上，只能用整文件覆盖——这也解释为什么 13 个补丁件里
只有 dsa_v1.py 和 indexer.py 的 md5 不同（那两个正好在两个 commit 之间被上游改过）。

7.2 模型量化来源

• 权重（W4A8）：ModelScope chiro2001/DeepSeek-V4.1-Flash-w4a8-Ascend
  → https://modelscope.cn/models/chiro2001/DeepSeek-V4.1-Flash-w4a8-Ascend
  仓库 README 标注 273 GB，下载后必须重组 Engram（仓库提供 deepseek_v41.repack.py）。
  （该页是 JS 渲染，抓取只能确认标题；仓库 README 与我们的实际部署路径均指向它。）
• 量化工具：patches/msmodelslim —— msmodelslim 的 V4.1 W4A8 支持补丁，只在重新量化时需要。
  我们直接用了已量化好的权重，没有重跑量化，所以这条线本次未验证。

7.3 外部优化包（评估后未采用）

• BetterScale：https://pypi.org/project/vllm-betterscale/0.4.1/
  源码仓库 https://github.com/vLLM-HUST/BetterScale
  （Apache-2.0，作者 Fletcher Tian / 华中科大 intellistream 组）
  评估结论：与我们版本差两代，cross_step 的核心机制已被上游吸收，不移植。

7.4 其他

• 4.0 时代的 DSA 路线判断，参考了 HiAscend 论坛的部署帖及其评论区。
• 厂商补丁的收益口径来自仓库内 patches/PATCHES.md 与 AGENTS.md §5b。

---

8. 如果重来一次，我会先做哪三件事

1. 先量清楚硬件能力（/proc/svm/devN/feature/*、LnkSta、npu-smi），
   再决定哪些补丁值得试——这一条能省掉 §3.1 和 §3.7 两次失败。
2. 先确认门控变量真的到了 worker 进程（读 /proc/<pid>/environ，不要读 docker exec env），
   再谈"补丁生效没有"——这一条能省掉整整半天。
3. A/B 从第一天就按"两轮 + 池化 + 排除前 80 秒"做，
   否则会被噪声带着来回改（我们真的为此多回滚过一次）。

---

本文所有数字均来自同 mix（62/25/10/3）、同到达率（λ=0.45）、同并发上限（32）、各 480 秒、
各 211 笔 0 失败的对照实验；TPOT 只统计 t>80 s 的稳态段。跨口径的数字本文一律没有相减。