负载建模：先定义系统承受的压力 ¶
在“边界比较”的分析框架里，负载模型首先要回答的，不是应用长什么样，而是系统究竟在承受什么压力。如果压力对象没有被定义清楚，后续关于资源供给、系统行为和校准验证的讨论，就会重新退化为“拿几个 benchmark 试一试”的局部判断。对超节点产业而言，负载建模的目标从来不是写出一部工作负载百科全书，而是提炼出一组可复用、可批量生成、可被真实观测约束的压力画像。
这一领域一个常见误区，是把负载建模理解成一种中立的格式工程，仿佛只要规定了统一图表示和统一 trace 规约，问题就已经解决。但超节点分析真正关心的，不是交换格式本身，而是这些负载对象能否支撑“画边界”这件事。训练、推理以及混合负载之所以需要分开讨论，不是因为它们属于不同应用分类，而是因为它们会把系统推向完全不同的受压方向：训练放大同步边界、流水线气泡和全局一致性代价；推理更早暴露 TTFT、TPOT、排队和 KV Cache 管理问题；MoE、长上下文、多模态混部与智能体突发流又会引入路由偏斜、状态膨胀和尾部放大，使前沿在局部区域发生明显形变。
因此，负载建模的真正任务，不是给“workload”下一个尽量完备的定义，而是把系统压力整理成一组可生成、可比较、可解释的需求对象。所谓“可生成”，是它不能只复现一次历史实验；所谓“可比较”，是它不能在建模阶段就预先固化某种硬件或策略选择；所谓“可解释”，是当边界出现拐点、断裂或排序反转时，分析能够回到负载本身解释压力为何变化。
不是一个 workload，而是一族 workload ¶
如果只用单个代表性样例来描述负载，分析最多只能比较若干离散实验点，而无法描述边界。边界天然要求大量候选点，因此负载模型必须支持参数化生成。训练侧需要能够连续改变模型规模、并行维度、同步频率、激活保留比例以及 MoE 路由分布；推理侧需要能够连续改变输入长度分布、输出长度分布、到达过程、并发度和 SLA；混合负载则需要能够表达长短请求占比、多模型混部比例、冷热分布和突发性。只有这样，比较才会从“单点复现”升级为“边界塑形判断”。
但参数化并不意味着什么都应被保留。对超节点的边界判断而言，真正值得进入负载画像的，是那些会改变边界形状和方案排序的因素，而不是只改变局部实现常数的细节。下表给出这一取舍原则：
| 类别 | 保留（进入负载画像） | 剥离（不进入负载画像） | 判断依据 |
|---|---|---|---|
| 计算结构 | 算子类型、shape、精度、层数、注意力模式 | 特定设备的 kernel 实现细节 | 前者决定计算 / 访存比与通信量级，后者仅影响局部常数 |
| 通信意图 | 集合通信类型、消息大小、同步边界 | 运行时私有的 allocator/ 排队细节 | 前者定义负载对互联的需求，后者属于资源模型范畴 |
| 阶段差异 | Forward/Backward/Sync 边界、Prefill/Decode 分割 | 某次实验的偶然调度抖动 | 前者决定前沿拐点和阶段切换代价，后者是噪声 |
| 状态生命周期 | KV Cache 尺寸演化、激活值峰值时序、梯度存活周期 | 固定 allocator 的碎片化行为 | 前者决定显存可行域边界，后者由平台特性决定 |
| 到达与 SLA | 请求到达分布、并发度、TTFT/TPOT 约束 | 特定负载均衡器的路由实现 | 前者是推理侧边界的核心驱动，后者可独立建模 |
| 路由与稀疏性 | MoE 专家选择分布、top-k 策略、负载不均匀度 | 特定 MoE 框架的通信实现 | 前者决定 All-to-All 压力和前沿形变，后者属于实现 |
换句话说，负载模型描述的是需求，而不是某条既定技术路线已经做出的实现选择。
从这个意义上看，硬件无关和策略中立并不是抽象层面的建模美学，而是为了给后续资源模型和系统模型保留完整解空间。如果在负载规约里已经写死某种 TP/PP/DP 组合、某种固定调度方式或某条显存卸载路径，那么分析实际上就已经从“边界比较”退化为“既定路线的性能估算”。这样的模型也许能复现实验，却很难支撑方案判断。
负载模型还必须显式保留阶段差异与状态差异。很多系统收益并不发生在平均负载上，而恰恰发生在阶段切换、状态膨胀和极端工况上。训练中的前向、反向和同步边界，推理中的 Prefill 与 Decode 差异，MoE 中专家分布的不均匀性，KV Cache 的生命周期、分页与驱逐压力，以及请求到达的突发性和尾部分布，都会决定边界上的关键拐点。如果这些差异在工作负载阶段就被平均掉，那么后续前沿形状也会被抹平，很多真正改变方案排序的机制差异将不再可见。
静态图与动态执行迹的分工 ¶
这也是为什么建模仿真需要同时容纳静态图与动态执行迹，但不能把两者的关系写成简单的形式分类。静态计算图的价值，不在于它“更规范”，而在于它适合训练侧的大范围配置扫描，能够以较低成本暴露计算量、通信意图、关键路径和同步边界；动态执行迹的价值，不在于它“更真实”，而在于它能够保留请求到达、阶段切换、状态变化和尾部行为，因此特别适合关键点校准、跳变解释和极端场景验证。两者并非彼此替代，而是分别服务于快速描边和关键约束。
| 表示形式 | 核心能力 | 适用阶段 | 典型工具 / 标准 |
|---|---|---|---|
| 静态计算图 | 低成本暴露计算量、通信意图、关键路径 | 大范围配置扫描、前沿粗描 | Chakra ET、ONNX Graph、Alpa cost model |
| 动态执行迹 | 保留到达、切换、状态与尾部行为 | 关键点校准、跳变解释、极端验证 | Chakra Execution Trace、nsys trace、线上 trace |
这也意味着负载模型必须同时兼容两种使用方式：一方面足够简化，能够和快速模型、离线 sweep 配合，支撑数千点级的边界描绘；另一方面又足够贴近真实，能够在候选前沿点、敏感区和跳变点上回到真实 trace、线上观测或高保真仿真，把误差收紧到足以支撑排序判断的程度。如果只能服务于前者，边界会画得很快但缺乏解释力；如果只能服务于后者，分析会很精细，却高成本到无法承担“描边”任务。负载建模真正需要的是这两种能力之间的可切换性。
从需求空间到可描边对象 ¶
走到这一步，负载建模的落点就很清楚了：它追求的不是某种唯一正确的抽象格式，而是几组可以直接用来画边界、比较边界的工作负载族。下表给出四类核心工作负载族及其关键参数：
| 负载族 | 代表性场景 | 核心可变参数 | 对前沿的塑形作用 |
|---|---|---|---|
| 训练主线 | 稠密预训练、MoE 训练、长上下文训练、多模态训练 | 模型规模、TP/PP/EP/DP 维度、同步频率、激活保留比例、MoE 路由分布 | 决定训练侧前沿在同步放大、气泡率、显存和能效上的主形状 |
| 推理主线 | 短提示词交互、混合长短请求、长上下文生成、高并发在线服务 | 输入 / 输出长度分布、到达过程（Poisson/ 突发 /trace |
决定推理侧前沿在时延、吞吐、Goodput 和 KV 管理上的主形状 |
| 极端工况 | 超长序列（>128K |
序列长度上界、路由不均匀度、突发倍率、混部比例 | 不一定构成主前沿，但决定某条路线是否进入不可部署区域 |
| 未来变量 | 超稀疏 MoE（>256 专家 |
专家数量 / 激活比、模态交织密度、工具调用频率、自适应计算步数 | 为未来演进讨论提供边界变形的压力入口 |
训练主线之所以必须覆盖稠密预训练、MoE 训练、长上下文训练和多模态训练，是因为这些因素共同决定训练侧前沿在同步、通信、显存与能效上的主形状；推理主线必须覆盖短提示词、混合交互、长上下文、高并发和突发流，是因为它们直接塑造 TTFT、TPOT、吞吐与 Goodput 之间的关系；极端工况不一定构成主前沿，却往往决定某条路线是否进入不可部署区域；未来变量则为后续“边界如何继续移动”提供了压力入口。
至此，负载模型的行业角色也就明确了。它不是应用百科，也不是新的抽象标准，而是把“系统会承受什么压力”整理成一组可以用来画边界、比较边界、校准边界的需求对象。只有在这一前提下，资源模型谈供给才有对象，系统模型谈推演才有输入，校准验证谈误差才有落点。