Ascend 910C推理调优负例分析为什么合理的优化没有带来吞吐收益

在一次 DeepSeek-V4-Flash / Ascend 910C 调优里，我们试过降低 CP 并行度、调整 Prefill 分块和通信轮次、提高请求速率、切换静态专家布局，以及引入 DSPARK Compact。每个方向都有看起来合理的理由，最后得到的结果却很不一样。

有的平均 TPOT 降低，系统吞吐反而下降；有的布局重新采集、拟合、加载一遍，整轮吞吐只提高约0.81%；有的请求速率增加四倍，原生稳态吞吐几乎没动，但完整窗口却变快了。

这些结果不能统一归成“优化无效”。有些候选确实不值得保留，有些只是没有实现最初想要的目标，还有一些结果根本不足以支持因果判断。判断错了，不但会多跑实验，还会把有用的配置过早关掉。

这篇聚焦2026年10月18日至21日的同一轮PD实验，依据当时的运行快照与原AISBench统计，不外推当前上游版本，也不混入后来独立环境的动态EPLB实验。正向优化与最终成绩见整体复盘，实验编排的返工见流程复盘。这里沿几项负例，分析原假设遗漏了什么，以及何时应该停止。

一、先分清三种不同的“没收益”

当时的目标是真实Prefill / Decode分离部署，P、D各8张物理卡，在平均TPOT严格低于20ms的条件下提高系统输出吞吐。本文每卡吞吐统一除以P+D共16张卡；配置并发上限记为C，N表示正式请求总数，r表示配置请求速率。

有两类数据：16K正文、实际Chat16388 token、输出1024、零缓存，以及128K正文、实际Chat131076 token、输出1024、逐条实际前缀缓存90.6222%。普通数据和高AL复制展示数据也分别比较，不跨负载计算配置收益。下文列出的正式对照均成功完成，没有请求失败，但这些测试不是完整任务质量评估。

第一类是当前目标下的负向观测。参数变更后，native与whole吞吐都下降，其他指标也没有足够理由抵偿，就不保留该候选。不过单次下降1%，仍不等于统计上证明“永远慢1%”。关闭一个候选所需的证据，可以少于宣称普适回退所需的证据。

第二类是优化了别的东西。TPOT降低不等于整轮完成更快；提高到达速率缩短升载时间，也不等于系统持续处理能力提高。如果只盯一个指标，很容易把取舍写成失败。

第三类是无法判断。正式请求没有发出、collector导入失败、稳态窗口太短，或者比较时同时换了其他配置，都不能记成性能负例。实验没回答问题，和实验回答“这个方向不划算”，需要不同处理。

因此，阅读结果前要先确认统计窗口。whole是完整正式窗口，包含升载和排空；native是AISBench原生算法选出的稳态区间。下文保留两者，不把删除慢请求的自定义区间叫作稳态，也不将whole接受计数搬到native。

小幅正向结果也要这样看。例如D端graph档位加入6，在同N480/C88/r4筛选中，native提高约3.93%，whole只提高约0.51%。保留该档位有正向依据，但如果只摘较大的百分比，就会夸大这一改动对整轮请求的改善。它也不能与其他场景的收益直接相加。

二、减小CP、增大chunk：局部变快为何没有变成系统收益

先看一组CP拓扑调整。相同16K普通数据、N480/C88/r4，候选从CP4/DP4转为CP2/DP8，并采用对应的通信配置；D端与数据保持匹配。

native吞吐约下降0.91%，whole约下降1.64%。只看TPOT，会觉得候选改善明显；把TTFT和E2E放回去，就能看到生成阶段的改善没有带来更快的整体完成。

“CP变小，通信少一些”是一个假设，不是收益公式。CP、DP变化会同时改变每个执行单元承担的工作、请求分布以及通信几何。这个对照评价的是整套拓扑方案，不能把回退精确归因于CP本身，更不能把TPOT变化当成P端某一项通信成本的测量。

另一项候选针对一个更具体的问题：实际输入16388，在有效chunk8192且Prefill请求上限为1的调度路径中，会留下很短的尾块。于是尝试把有效chunk调到8320，让请求能在两个chunk内处理，同时通信配置从round1改为round2。

同高AL复制数据、N320/C128/r6，结果如下：

native约下降0.97%，whole约下降0.66%。这次确实改变了分块组织，却没有提高完成吞吐。由于chunk和通信轮次一起改变，记录只能关闭这组配置，不能证明“多出的128个token导致回退”，也不能证明损失全部来自第二轮通信。缺少对应的完整阶段计时，就应保留这一缺口。

后来成功的方向，是维持8192/round1，只把一轮可接纳的Prefill请求数从1放到2，让尾块与下一请求合批。同640请求下native提高32.27%。它与8320候选试图处理的是同一个尾块现象，改变的执行条件却不同。

前一个负例的价值，是让下一步转向“token预算还空着时，为什么不能接纳第二个请求”，而不是继续无依据地扫描更多chunk值。更少的分块轮数、较低的某段延迟，都只是中间结果，最终还要看进入系统的请求怎样完成。

三、请求速率提高四倍：容量没涨，但不能说完全没用

提高r是便宜的热测，容易被拿来寻找更高吞吐。但它首先改变的是客户端尝试提交请求的节奏，而不是服务端执行速度。

在同16K普通数据、N320/C88、G5配置下，把4 req/s调到16 req/s，得到：

native区间分别约81.44秒和81.79秒，纳入231与232条请求。持续处理阶段的完成速率基本一样，说明在这个点上，更快提交没有增加可观察的持续输出能力。

但whole提高了约7.07%，不能藏掉。有限320条请求更快进入系统，升载和排空构成的完整窗口也会变化。它是整轮完成表现的收益，同时伴随更长的平均TTFT和E2E；不能把它重新命名为稳态容量增益。

还可以做一个量纲检查。native完成速率约2.8366 req/s，平均E2E约30.58秒，两者相乘约86.75，与C88接近。这与客户端已经承载较多在途请求相符。它不是设备利用率，也不能证明P、D谁是唯一瓶颈，但比“配置速率还可以更大，所以一定没压满”更接近实际约束。

对追求稳态吞吐的这项实验，继续从16扫到32、64，缺少价值；对关心短批任务整体完成时间的业务，whole的变化仍然有意义。是否保留配置，取决于目标里怎样看待等待时间。

这个结论也不能跨场景沿用。后来换成128K高缓存负载，KV占用、P端有效工作量和服务时间都变了，仍然需要根据新场景判断C与r，而不是用旧平台期永久禁止增加并发。

四、Compact为什么省得不多，固定95%预算又为何更慢

Compact的动机是减少验证里的无效工作。固定verify宽度6时，如果每条请求都用满宽度，组织简单；如果不同请求实际只需验证不同数量，就有机会按变长布局处理，减少逻辑验证槽。SPS规划尝试在成本与有效产出之间做选择。

修复后的Compact与原静态验证，在同16K高AL复制数据、N320/C128/r6、相同D静态布局上比较：native从164.88降到159.35，约−3.35%；whole从145.72降到139.17，约−4.50%。两个native区间都超过70秒，但这仍是有限次数对照，不是通用回退结论。

这次计数提供了一条比“额外管理开销大”更具体的线索。整轮共有59371次请求级verify记录，其中56376次的实际verify宽度仍为6，占约94.96%。从宽度直方图求和，逻辑验证槽共350746个；若每条记录固定宽度6，对应356226个，只相差5480个，约1.54%。

这意味着在该高AL点上，Compact可利用的变长空间本来就不大。但1.54%是逻辑槽数变化，不是设备时间、FLOPs或端到端耗时的减少比例：graph bucket、padding、attention与MoE执行成本都不能仅凭槽数还原。

因此，它支持的是“不能期待很大的省算红利”，而不是“已经证明某段元数据耗时导致4.50%回退”。要回答后者，需要完整而可归属的draft/verify设备阶段成本。本轮短profile只关联到部分阶段，不能把CPU提交时间或kernel局部跨度当作整段设备wall time。

另一次尝试固定95%预算，希望进一步约束验证工作。同N320/C128/r6下，whole吞吐从158.90降到155.77，约−1.97%；AL从5.7645降到5.3203。基线native窗口仅59.34秒，低于本项目60秒门槛，所以这项取舍主要依据whole，不能用两组native直接给出稳态回退比例。

为什么“验证少一点”会更慢？可以先看一个简化的单请求周期模型：每周期有效输出为A，周期时间为T，生成速率近似A/T。这里忽略PD供给与并发重叠，仅用来理解收支，不用于反推实测阶段时间。

新旧AL比值 = 5.3203 / 5.7645 ≈ 0.92294

若A按这组AL比例下降，新周期就需要缩短超过约7.71%，才能在该简化模型里补回有效产出损失。只知道“少验证了”，还远远不够。真实系统这次没有测出净吞吐收益，因此恢复自动预算，没有继续为更多比例投入长测。

这里还有一个容易误判的数字：95%候选按实际验证槽计算的接受比例仍约96.22%，看起来不低。但分母变小后，比例可以保持漂亮，每轮有效输出却减少。这个比例也不是严格的“接受草稿数/实际生成proposal数”，后者分母未完整观测，仍标为NOT_OBSERVED。

Compact期间还修复过跨请求位置计算错误，明显减少了乱码和长SSE停顿。这项修复必须保留，即使native没有提高；不能为了速度退回已证明的错误位置。正确性修复、功能适配与性能收益，在复盘中应分别记账。

五、专属静态EPLB布局：拟合更均衡，为什么吞吐只涨一点

MoE路由存在热点时，重新放置专家、给热点专家设置冗余副本，有机会降低较慢rank的工作负担。但布局优化的直接目标是工作分布，不是系统吞吐数值本身。

16K高AL复制集的D端场景布局，在同N320/C128/r6下，native约提高0.35%，whole约提高2.35%。128K、逐条cache90.6222%的warm场景，则对P、D分别重新采集和拟合；同N160/C64/r6的whole从147.91到149.11，约+0.81%，没有采集该轮native。

这些结果足以说明功能链走通，不能证明大幅提速。单次小差异也没有给出重复运行的波动范围，不应被写成显著收益。

从机制上看，至少有几道条件必须同时成立。热点要确实落在影响完成时间的执行路径上；重放置要降低最慢一侧的负担，而不是只改善平均计数；迁移后的放置还要适合正式测量时的分布。如果主导等待来自P供给、KV交接、attention或调度预算，专家计数变均衡也不会自动消除它们。

这些是解释小收益时需要区分的条件，不是本轮已经逐项定位的根因。统计使用512个循环槽，也不等于完整保存了全部请求的时序。128K缓存准备的seed与check被排除在正式计数窗口之外，拟合才对应warm负载；即便如此，计数摘要仍不能替代关键路径时间。

与D端小收益相比，另一组16K实验的P端静态布局曾使whole提高14.18%。这说明EPLB并非“没用”，而是角色和场景不同，收益空间不同。P、D布局应该分别评价，不能把一端的成功复制成另一端的收益预期。

成本也会改变保留策略。一次128K布局比较的控制器耗时约748.23秒，正式窗口只有68.68秒；模型此前已经加载，接续阶段与两轮预热合计约255.72秒，路由验证约275.75秒。这些时间互相包含，不能再重复求和。

这不等于做布局花了十几分钟就一定不值：长期部署可以摊销一次准备，且有些步骤本来就要执行。但在有限调优窗口里，为0.81%的单次差异再重复冷启动，必须有额外理由，例如当前关键路径上的明确失衡、代表性更强的数据，或需要确认的波动。仅凭“布局还能更均衡”不足以继续。

六、局部gap和低running，为什么容易把诊断带偏

当端到端收益不明显时，profile里往往仍能找到很多看起来可优化的片段：一段CPU小copy、两次kernel之间的间隔、某个rank低于上限的running数。它们真实存在，但不自动等于可回收预算。

单rank的kernel-union之外有空隙，只表示该rank在这个已观察窗口没有落入统计到的kernel区间。其他rank可能在计算或通信，异步提交也可能跨线程。把这个比例直接乘到系统吞吐上，相当于未经证明就假设所有设备同时等待，而且整个空隙都能消除。

同样，running低于配置C，可能与token预算、KV容量、DP分布或请求生命周期有关。它不直接证明请求不足；P排队、D队列低也只是供给线索，不独立证明P是唯一瓶颈。更可靠的做法是把这些线索连接到一个具体可检验的改动，例如前一篇中的尾块合批，而不是从曲线形状直接跳到扩容并发。

旧trace还存在配置时效问题。IndexCache、graph档位、并发、活跃DP都可能不同。用旧材料筛掉明显很小的机会有价值，用它给当前候选做精确因果归因则不成立。

这类分析什么时候该停？当已观察预算很小、没有证据表明它在系统关键路径上，而验证又需要一次昂贵冷启动时，就应该降低优先级。不能为了把原因讲得完整，一直扩展profile和源码审阅，反而迟迟没有发出更有决策价值的实验。

七、怎样从负例得到下一步，而不是再扫一轮参数

复盘里最需要避免的一件事，是事后把所有失败写成“必要探索”。一次有依据、能改变保留决定的负例有价值；反复复制入口、修旧断言、重新验证未变逻辑，并没有增加多少性能信息。

这轮noCP准备到冻结用了23分02秒；另一次已经通过两轮预热和完整路由，正式请求前才遇到旧配置断言。这些属于编排损耗，不是模型或硬件负例。采集失败也应先确认原推理结束和服务状态，然后只修CPU后处理，而不是重发相同模型请求。

为下一轮写下候选时，我会先把预期结果说具体：

重新打开一个关闭的方向，也要说明条件发生了什么变化。Pcap2早期负向，后来在新的chunk、静态布局和高AL负载下成为大收益，就是这种情况。它不是鼓励重复旧负例，而是要求每次重试有新的机制依据。

最后，native与whole方向一致、差异足够值得关注、比较条件清楚，才有必要安排一次更长确认。小差异没有重复置信证据时可以暂不保留；不必为了给每项参数贴永久标签，耗尽有限机器时间。负例真正留下的资料，应当是被排除的假设、适用条件和下一步缺什么证据，而不只是一个红色百分比。

数据与范围：本文沿用当时的SGLang/NPU补丁快照和原AISBench算法，不声称是当前上游默认行为。公开的对照数值包含N/C/r、统计窗口、吞吐及可得的延迟与计数；逻辑验证槽计算给出直方图和推导。未观测的严格proposal接受率、完整draft/verify设备阶段时间与置信区间，不用估计值补齐。内部部署信息和请求正文不公开。