系统模型：把需求、供给与策略压成边界上的点 ¶

如果说负载模型定义了需求空间，资源模型定义了供给边界，那么系统模型的职责，就是把两者真正连接起来，形成可比较的系统行为（System Behavior）。它回答的不是“这台系统理论上有多强”，而是更直接也更关键的问题：给定一组工作负载、资源画像与策略选择，系统会在多目标空间中落到哪里，这个点为什么落在那里，又有哪些区域值得进一步用高保真方法校准。

从这个意义上说，系统模型更像一个边界生成引擎。它并不追求给出一个永远唯一正确的答案，而是要把需求、供给与策略压缩成一批带解释力的候选点，并说明这些点为什么会连成某种边界形状。也正因为如此，系统模型天然要支持“快速描边 + 关键点校准”的工作方式，而不是把所有问题都压到同一保真度上去处理。

系统模型做的事情，归根到底只有两步。第一步，把逻辑负载映射到具体物理资源；第二步，把这些资源在时间轴上的竞争、重叠、排队、同步和恢复过程推演出来。前者决定候选点大致落在多目标空间的哪里，后者决定这些点会不会因为抖动、拥塞、状态膨胀或恢复路径而发生显著偏移。很多看似更优的路线，最后并不是输在峰值能力不足，而是输在映射关系、通信展开方式、资源仲裁机制以及控制面组织把收益在系统层面耗散掉了。

供给侧：资源对象与保真度分层 ¶

系统模型的 " 第一步 "——逻辑负载映射到物理资源——首先取决于供给侧长什么样。对超节点分析而言，供给侧不是一组孤立硬件参数，而是一整套 " 系统在长期运行中能够稳定供给什么 " 的能力结构。资源对象不应按 " 硬件类别 " 挑选，而应按 " 是否会改变边界形状 " 挑选 ⁵：

把 Runtime 和 RAS 视作资源而非附注，是超节点建模与传统设备评测的重要分界之一。此外，规格表不会主动交代的系统级变量同样必须显式纳入：

这些资源事实的获取成本差异巨大，因此资源描述必须在保真度上分层 ⁶：

原则是 " 先足够便宜地覆盖大范围，再足够有针对性地收紧关键区域 "。只有当这些资源事实被沉淀为可调用、版本化、带适用边界的对象时，系统模型才能在可承受的成本下先描边、再校准。

系统模型的状态维护 ¶

这也是为什么系统模型不能只是一个“性能估算器”。如果它只返回最终吞吐和延迟，而不显式维护队列状态、链路占用、显存状态、调度状态和恢复状态，那么 Goodput、长尾、恢复损失和工程可达前沿这些关键问题就都失去了因果落点。真正重要的，不只是最后的一个分数，而是这些状态如何沿时间演化，并最终塑造了边界的位置 ¹。

系统模型需要显式维护的状态变量，至少包含以下几类：

训练前沿为什么会被塑形 ¶

训练系统并不围绕单次延迟最优展开，而是围绕稳态吞吐、同步放大和资源连续利用展开。对超节点产业真正重要的，不是复现全部训练细节，而是抓住那些真正决定前沿形状的变量。

第一个变量是同步边界。训练具有清晰的迭代结构和一致性约束，局部拖尾会沿同步路径被不断放大，最终决定整轮 step time。因此，训练模型至少要显式刻画迭代边界、全局同步点以及局部抖动如何被放大成全局吞吐损失。很多时候，看似只是局部链路或局部节点的轻微退化，最后却会表现为整条系统前沿的明显内收。

第二个变量是气泡、重叠与平面干扰。训练前沿常常不是被峰值带宽或峰值算力直接决定，而是被结构性依赖、阶段失衡、理论重叠与实际重叠之间的差距，以及参数面、数据面与业务面互扰共同塑形 ²。换句话说，真正需要建模的不是某个局部现象本身，而是这些现象如何共同决定“同样的硬件资源能否真正逼近前沿”。

以典型的 3D 并行训练为例，塑形训练前沿的关键变量及其边界效应可整理如下：

第三个变量是显存可行域。训练显存不是静态预算，而是由生命周期、同步边界和策略取舍共同塑造的动态曲线。峰值显存出现在哪里，激活值与梯度、优化器状态如何重叠，重计算与卸载又如何在算力压力和带宽压力之间交换，这些都会决定很多训练路线是不是在被算力卡死之前，就已经先被显存边界截断。

第四个变量是恢复路径。在大规模训练里，故障并不是偶发离群值，而是长期运行的背景噪声。若系统模型不显式定义“故障发生后如何回到稳态”，所有吞吐结果都会默认建立在过强的健康稳态假设上 ³。因此，训练模型至少要覆盖检测延迟、隔离粒度、恢复方式和回稳时间，因为这些量本身就是长期 Goodput 的组成部分，而不是系统边缘条件。

推理前沿为什么会被塑形 ¶

推理系统与训练系统的差别在于，它并不围绕强同步迭代边界，而是围绕持续到达的请求流、阶段异质性和 SLA 约束展开。对超节点产业而言，推理建模的核心不是估算单个 token 有多快，而是解释请求流、调度器与状态变量如何共同决定 TTFT、TPOT 与系统级 Goodput。

第一个变量是到达过程与调度入口。请求流的形状本身就是推理前沿的一部分：Poisson 流、突发流和 trace 回放会把系统推到完全不同的排队状态；静态批、连续批、优先级批和 admission control 又会改变请求进入执行面的方式。高并发、短时长、强实时场景下，很多退化并不是来自算子慢，而是来自调度器响应速度跟不上请求结构的变化 ⁴。

第二个变量是 Prefill/Decode 阶段差异。推理负载并不是均匀的：Prefill 更接近计算上界，Decode 更接近访存和状态管理上界。若系统模型不把这两个阶段拆开，就无法解释为什么某些架构在平均吞吐上看似合理，却在用户体验上彻底失败。阶段计算和访存差异、阶段切换成本，以及聚合、PD 分离、异构 PD 等映射策略，都应纳入建模。

第三个变量是 KV Cache 与显存状态。推理侧很多架构收益与失效都发生在 KV Cache 管理上：分页与碎片化、交换与驱逐，以及多模型多租户或长短请求混部下的状态干扰，往往决定“理论前沿”与“工程可达前沿”之间的距离。若系统模型只看平均带宽和平均显存占用，它几乎一定会把推理侧最重要的一批拐点画错。

第四个变量是控制变量的开放程度。如果推理建模退化成“换一组 batch 再跑一次”，它就无法真正承担描边工作。系统模型必须把以下控制变量作为可扫描维度开放出来：

只有让边界能够在这些维度上被系统性观察，分析才不会停留在几个手工挑选的点上。

三层结果：坐标、状态与归因 ¶

当训练侧和推理侧这两条逻辑都成立时，系统模型给出的就不该只是几组分数，而应同时包含三层结果：

没有 L1，边界无法比较；没有 L2，点位无法被校准；没有 L3，边界为何移动就无从解释。三层之间并不是简单的精度递进，而是服务于不同阶段、不同角色的分析需求：L1 面向决策者，L2 面向校准工程师，L3 面向架构分析师。

也因此，评测不应成为系统模型的主体。系统模型负责生成边界候选点并解释其形成机制，评测只负责在关键区域校准这些点。只有把这条分工讲清楚，系统模型才不会退化为“测评罗列”的别名，而能真正承担边界比较的职责。