方法论验证案例：异构推理架构的帕累托分析 ¶
方法只有真正跑通一次，才具备说服力。本节用一个真实的推理架构决策过程，验证前述分析链路能否从抽象框架变成工程工具：先定义目标与约束，再在配置空间中描出边界，最后通过校准与敏感性分析，区分哪些收益是稳健的、哪些只是局部改善、哪些变化真正把边界向外推。
为什么需要系统化分析而不是穷举实测 ¶
推理系统优化常被简化为硬件性能比较，但线上推理服务的架构选择同时受到 TTFT、TPOT、吞吐、成本和扩展性约束，单个硬件指标不足以直接决定架构优劣。真正的问题不是“哪块卡更强”，而是“在既定 SLA 和成本边界下，哪条路线更靠近可交付的前沿”。
更现实的约束来自工作量本身。以本案例的配置空间为例，13 个场景、6 种并发数以及多种引擎与 PD 组合下，如果主要依赖人工实测和反复执行，整体工作量估算可达 45.2 天。
多场景、多组合下的人工实测工作量示意。随着场景数、并发数和部署组合增加，基于实测穷举的优化方法迅速变得不可持续，这也是引入系统化分析框架的直接动因。
这正是超节点分析反复面对的工程现实：不是所有点都值得同样精细地算，真正稀缺的资源是高成本验证能力，而不是参数本身。
三层优化：从调参到推边界 ¶
在“边界比较”视角下，推理优化并不是一层平面工作，而可以分为三个层次，每个层次对应不同的决策主体、优化周期和方法论工具：
| 层次 | 含义 | 决策主体 | 周期 | 典型手段 |
|---|---|---|---|---|
| 第一层 | 可行区 → 帕累托前沿 | 交付 / 运维 | 天 | batch 调整、动态批处理、量化、执行参数调优 |
| 第二层 | 理论前沿 → 工程可达前沿 | 产品研发 / 系统工程 | 月 | 调度优化、请求合并、缓存策略、实现层打磨 |
| 第三层 | 旧前沿 → 新前沿 | 架构 / 硬件决策 | 季度–年 | PD 分离、异构组合、新一代硬件接入 |
第一层解决的是“在现有架构不变的前提下，能否用低成本调参把当前配置推到前沿附近”；第二层解决的是“理论上的前沿点在工程上是否真正可达”；第三层关注的已经不是在既有前沿里重新取点，而是“能否把整条性能边界向外推”。本案例正是第三层问题：我们关心的不是怎样在已有配置中再挪一个点，而是异构架构调整能否带来真正的边界外推。
不同技术路线会把系统带到不同的帕累托前沿上。MTP、PD 分离、规模扩展、FP8 等技术不只是把某个点调得更好，而是在不同程度上把性能边界往外推。
硬件代际变化本身也会推动前沿外移，但它最终能不能变成可落地的收益，还是要和具体架构、并行策略以及业务约束放在一起看。
硬件代际变化同样会改变帕累托前沿的位置。不同硬件与配置组合形成了不同的性能边界，硬件升级能够带来新的上限，但最终收益仍取决于是否与合适的架构和配置配套。
案例定义：异构推理的配置空间 ¶
本案例要回答的核心问题是：在给定 SLA 约束下，纯 A100 架构与 L40S + A100 异构分离架构之间，哪种方案在性能、成本和稳健性上更接近可部署前沿。
候选架构：
a100_agg：纯 A100 聚合架构a100_disagg：纯 A100 分离架构L40_P_A100_D：L40S 承担 Prefill，A100 承担 Decode（异构混推）A100_P_L40_D：反向异构架构（用于对照验证）
请求场景与 SLA 约束：
| 场景 | 输入 / 输出长度 | TTFT SLA | TPOT SLA |
|---|---|---|---|
| Short | 512 / 128 | 600 ms | 20 ms |
| Medium | 2048 / 512 | 1500 ms | 40 ms |
| Long | 4000 / 1000 | 2500 ms | 60 ms |
评估指标：
tokens/s/gpu：单位 GPU 吞吐，反映资源利用效率tokens/s/user：用户感知生成速度，反映端到端体验tokens/10k_rmb：单位成本产出，反映成本效益
这三个指标必须放在一起看，因为它们天然构成帕累托问题：只优化任一指标，都可能在另一维度付出隐性代价。
资源模型：阶段瓶颈与硬件匹配 ¶
异构方案成立的前提是 Prefill 和 Decode 两个阶段的资源瓶颈不同，因此可以用不同硬件分别匹配：
| 推理阶段 | 资源瓶颈 | L40S | A100 | 匹配结论 |
|---|---|---|---|---|
| Prefill | 计算密集型 | 362 TFLOPS (FP16) | 312 TFLOPS (FP16) | L40S 更适合 |
| Decode | 内存带宽密集型 | 864 GB/s | 2.039 TB/s | A100 更适合 |
| 成本 | — | ~1.5 万 / 月 | ~3.5 万 / 月 | L40S 性价比更高 |
Prefill / Decode 阶段与硬件能力匹配关系。异构方案成立，关键不在于 " 混搭 " 本身，而在于阶段瓶颈和硬件特征能对得上。
这里直接对应了资源模型的核心职责：不是罗列硬件参数，而是回答 " 在什么条件下，供给侧的能力边界会从哪里开始被侵蚀 "。L40S 在计算上不弱于 A100，但在带宽上差距超过 2 倍——这决定了两者在不同阶段的适用边界完全不同。
配置层面的差异同样显著：
| 架构 | 类型 | Prefill 配置 | Decode 配置 |
|---|---|---|---|
| 纯 A100 Disagg | 同构分离 | TP=4, workers=2 | TP=8, workers=1 |
| L40_P_A100_D | 异构混推 | TP=2, workers=5 | TP=2, workers=3 |
Long 场景下的配置对比。异构方案不仅硬件匹配更合理，也带来了更灵活的并行配置空间——更低的 TP 度允许更多 worker，提高了系统级并行利用率。
帕累托描边与核心结论 ¶
在上述配置空间中，通过系统级扫描和帕累托筛选，可以得到三类场景下的核心结论：
| 场景 | 推荐架构 | tokens/s/gpu | tokens/s/user | tokens/10k_rmb | 关键结论 |
|---|---|---|---|---|---|
| Short (512/128) | L40_P_A100_D | 210.1 | 72.99 | 672.31 | 用户体验最优，成本基本持平 |
| Medium (2048/512) | L40_P_A100_D | 280.08 | 25.78 | 689.43 | 成本效益提升约 31% |
| Long (4000/1000) | L40_P_A100_D | 243.4 | 19.58 | 599.13 | 成本效益提升约 45% |
三类场景下的核心结果。混推方案的优势主要体现在满足给定 SLA 约束后的综合成本效益。
这一结论是带条件成立的，而不是脱离场景的统一答案。它成立于给定请求分布和 SLA 目标下，因此本质上是一种“带约束的边界判断”。
全场景 tokens/s/gpu 与 tokens/s/user 帕累托分布。不同场景和架构的相对位置可用于判断用户体验与单位算力效率之间的权衡关系。
识别出帕累托前沿还不等于做完了业务决策。即使前沿上的候选点已经找到，最后选哪个点还要看业务 SLA：
SLA 约束会改变最终最优点的选择。无约束条件下的最优吞吐点，并不一定是满足业务约束时的最优上线点。
校准验证：稳健性与安全边际 ¶
帕累托最优点并不自动等于可上线点。本案例引入安全边际作为稳健性度量：
| 场景 | SLA 约束 (TTFT / TPOT) | 仿真达成 (TTFT / TPOT) | 安全边际 (TTFT / TPOT) | 稳健性判断 |
|---|---|---|---|---|
| Short | 600 ms / 20 ms | 246.7 ms / 13.7 ms | 59% / 32% | 高 |
| Medium | 1500 ms / 40 ms | 925.6 ms / 38.8 ms | 38% / 3% | 中，TPOT 边界较紧 |
| Long | 2500 ms / 60 ms | 1908.8 ms / 51.1 ms | 24% / 15% | 中，整体可行但余量有限 |
安全边际不是一个单独的数值，而是要把 TTFT 和 TPOT 放在一起看。Medium 场景 TPOT 仅剩 3% 余量，意味着它对流量波动和实现偏差更敏感。
分场景帕累托图更直观地展示了最优配置在候选空间中的位置：
Short 场景 tokens/s/gpu 与 tokens/s/user 分布。叉号标出满足 SLA 的最优点，可以看到它在候选配置中的相对位置。
Medium 场景。最优点仍然可达，但可选空间比 Short 场景更窄，需要结合安全边际表一起判断稳健性。
Long 场景。候选点整体更收缩，长序列场景更适合结合缓冲策略一起评估。
敏感性分析：成本与规模 ¶
成本敏感性 ¶
混推方案的成本优势依赖于 L40S 的价格区间。当 L40S 月成本低于约 2.5 万时，L40_P_A100_D 保持明显优势；当价格继续上升时，这一优势会收敛，甚至可能被纯 A100 架构反超。
全场景 tokens/10k_rmb 与 tokens/s/user 帕累托分布。价格变化不会改变各架构本身的性能机理，但会改变性能和成本之间的相对位置，从而让帕累托前沿发生移动。
这说明混推的性价比结论不是一个脱离价格条件的硬件结论，而是“硬件能力 + 价格条件”共同作用的结果。价格波动本身就是推动帕累托前沿移动的变量之一。
规模扩展 ¶
| GPU 规模 | tokens/s/gpu | 总吞吐 tokens/s | tokens/10k_rmb | TTFT (ms) | TPOT (ms) |
|---|---|---|---|---|---|
| 8 GPUs | 252.54 | 2,020.29 | 404.06 | 925.61 | 49.27 |
| 16 GPUs | 280.08 | 4,481.28 | 689.43 | 925.61 | 38.79 |
| 32 GPUs | 308.09 | 9,858.82 | 857.29 | 925.61 | 49.27 |
GPU 规模扩展验证。总吞吐近似线性增长，单位 GPU 效率和成本效益随规模扩大继续改善，但 TPOT 并未呈现单调变化。
从 8 卡到 32 卡，总吞吐保持良好扩展性，单位 GPU 效率和成本效益继续提升。但 TPOT 在 16 GPUs 时最优（38.79 msTP、worker 组合和调度方式单独验证。
反向架构验证 ¶
A100_P_L40_D（反向异构）在多个场景中都明显更差。这一结果从反面证实了结论具有机理基础：不是 " 只要异构就更优 "，而是 " 分工对了，异构才更优 "。阶段和资源之间存在方向性的匹配关系。
从案例回看方法论链条 ¶
案例走完之后，可以反过来检验方法论链条是否真正闭合：
| 方法论环节 | 案例中的落地 | 验证了什么 |
|---|---|---|
| 负载模型 | 3 类请求场景 × 参数化长度分布 | 不同负载确实把系统推向不同受压方向，前沿形状因场景而异 |
| 资源模型 | L40S vs A100 的算力 / 带宽 / 成本三维画像 | 阶段瓶颈匹配是异构方案成立的前提，非全谱参数都重要 |
| 系统模型 | 4 架构 × 多并发 × 多配置的帕累托描边 | 2700+ 配置点确实无法穷举实测，分层描边 + 关键点校准是可行路径 |
| 校准验证 | 安全边际公式 + 分场景稳健性判断 | Medium 场景 TPOT 仅 3% 余量——不校准就上线会出问题 |
| 敏感性分析 | 价格敏感性 + 规模扩展 + 反向架构 | 帕累托前沿不是静态的：价格、规模和架构方向都会推移边界 |
| 三层优化分级 | 调参（第一层）→ 工程打磨（第二层）→ 架构变革（第三层） | 不同层次的优化有不同的周期、主体和方法，不能混为一谈 |
最重要的不是某一行具体数据，而是整条链路已经被验证：这套方法能够把“局部经验”提升为“边界判断”，先画出边界在哪里，再判断在边界上应当如何取点，最后用校准和敏感性分析确认结论是否稳健。对超节点分析而言，这才是案例真正要证明的能力。