1. 为什么训练和推理的仿真总是各管各的
做系统方向的人大概都有过这种体验：手头有一个训练性能模型，又有一个推理性能模型，两者用的抽象层级不一样，参数标定方式不一样，甚至连"一个算子耗时多久"这种最基础的假设都对不上。你想验证一个"训练完直接部署推理"的端到端场景，结果发现两个仿真器之间隔着一道墙，只能靠手工拼数据，拼完自己都不太敢信。
Charon 这个工作想解决的就是这道墙。它的核心主张很直接：把训练和推理放进同一个算子级仿真器里，用同一套算子抽象、同一套代价模型、同一套硬件描述，让两种负载共享同一个底座。标题里的"算子级"是关键词——它不是那种只算 FLOPs 和带宽的粗粒度 roofline 模型，而是下沉到单个算子（矩阵乘、卷积、归一化、注意力等）的粒度去做时间与资源建模。
这篇文章我会围绕 Charon 这个题目，把"为什么需要统一仿真""算子级仿真到底在仿什么""训练和推理共享底座难在哪""怎么落地一套可复现的仿真流程"这几件事讲透。适合做 MLSys、性能建模、编译器后端、集群容量规划的同学参考，也适合刚接触系统仿真、想知道仿真器内部到底怎么运转的读者。我不会只讲概念，会尽量把参数怎么定、误差怎么控、坑在哪都摊开说。
先说结论性的判断：训练和推理之所以长期分家，不是因为大家不想统一，而是因为两者的瓶颈结构差异太大。训练是"计算密集 + 显存/内存墙 + 通信密集"的混合体，反向传播带来的额外算子和梯度同步让它的时间分布很不一样；推理则更偏向"访存密集 + 低算力利用率 + 批处理敏感"。一个仿真器要同时伺候这两种脾气，必须在算子抽象层做足够细的切分，否则一定会顾此失彼。
2. Charon 的算子级抽象到底切到了多细
2.1 算子粒度选择的取舍逻辑
仿真器的粒度是个根本性决策。粒度太粗，比如只按"层"或"阶段"建模，那训练和推理的差异会被平均掉，你根本看不出反向传播里某个归一化算子的实际开销；粒度太细，比如细到指令级，那标定成本会爆炸，而且和真实硬件的微架构强绑定，换个加速器就得重标一遍。
Charon 选的是算子级，这个位置比较微妙。它大致对应深度学习框架里的 op 概念——一次矩阵乘、一次 softmax、一次 layer norm、一次 all-reduce 的通信原语。这个粒度有几个好处：第一，训练和推理共享大量相同算子（前向的矩阵乘、卷积、激活），可以复用同一套代价模型；第二，差异部分（反向算子、梯度通信）可以单独建模而不污染前向；第三，算子级是编译器和框架都能对齐的公共语言，标定数据相对好采集。
我个人的经验是，算子级是"性价比最高"的折中。再往上到图级，你会丢失算子间的重叠（overlap）信息；再往下到指令级，维护成本会让整个项目变成无底洞。Charon 押注算子级，本质上是赌"算子级抽象足以捕捉训练与推理的性能差异"，这个赌注在多数稠密模型上是成立的。
2.2 一个算子被建模成什么
在 Charon 这类仿真器里，一个算子通常被拆成几个可计算的量：计算量（FLOPs 或等效操作数）、访存量（读多少字节、写多少字节）、并行维度（能切成多少块并行）、以及依赖关系（它依赖哪些算子的输出）。有了这些，再配合硬件的峰值算力、显存带宽、互联带宽，就能算出一个理论下界时间，再乘上一个效率系数去逼近实测。
这里的关键是效率系数怎么来。常见做法是查表：对每种算子类型、每种 shape 区间、每种精度（FP16/BF16/FP8/INT8），预先在目标硬件上跑一遍微基准，记录实际达到的算力利用率。Charon 的算子级设计让这张表可以做得比较细，同时又不至于细到无法维护。
提示：效率系数表一定要标注采集时的 batch size、序列长度、精度和并行配置。脱离这些上下文的系数表基本没法用，这是很多人复现仿真结果失败的头号原因。
2.3 训练与推理共享算子的边界在哪
共享不是无条件的。前向的矩阵乘、卷积、逐元素运算，训练和推理确实可以共用一套代价模型。但有几类算子必须分开处理：
- 反向算子：反向矩阵乘的访存模式和前向不同，梯度累加的读写比例也不一样，效率系数通常要单独标。
- 归一化类：训练时统计量的更新、推理时用固定统计量，计算路径不同。
- 注意力：训练要存中间激活用于反向，推理可以用 KV Cache，访存结构差异巨大。
- 通信原语：训练有反向的梯度 all-reduce，推理更多是张量并行的 all-gather/reduce-scatter。
Charon 的价值就在于把这些"同源但不同形"的算子放在同一个框架里描述，而不是让用户在两套系统间来回翻译。
3. 训练与推理共享底座，难在哪些地方
3.1 瓶颈结构差异带来的建模冲突
训练和推理对硬件的压力方向不一样。训练阶段，前向和反向都吃算力，梯度同步吃互联带宽，激活和优化器状态吃显存容量。推理阶段，尤其是自回归解码，单步算力需求低但访存频繁，KV Cache 的读写成为主要瓶颈，算力利用率经常低得可怜。
如果仿真器只有一套"算力优先"的代价模型，推理的访存瓶颈就会被严重低估。反过来，如果只按访存建模，训练的算力瓶颈又会被抹平。Charon 的做法是在算子级同时记录计算时间和访存时间，取两者与重叠后的较大值作为该算子的估计，这样两种负载都能被合理刻画。
3.2 精度与量化带来的组合爆炸
推理侧现在普遍用量化，FP8、INT8、INT4 甚至更低。不同精度下同一个算子的效率系数完全不同，而且量化的粒度（per-tensor、per-channel、per-group）还会影响实际 kernel 的实现效率。训练侧则涉及混合精度、梯度缩放等。
这意味着算子级仿真器的参数空间会迅速膨胀。Charon 需要一套合理的参数组织方式，比如按"算子类型 × 精度 × shape 区间"做分层索引，避免为每个具体 shape 都存一条记录。我见过一些仿真器就是因为参数表设计得太死，最后维护不动而废弃。
3.3 并行策略的耦合
训练常用数据并行、张量并行、流水线并行的组合，推理常用张量并行加连续批处理。并行策略会改变算子的切分方式和通信量，进而改变仿真结果。Charon 要在算子级把并行切分表达清楚，才能让同一份模型描述在不同并行配置下给出不同但合理的估计。
这块的难点在于通信建模。all-reduce 的时间不仅取决于数据量，还取决于拓扑（ring、tree）、链路带宽、以及是否和计算重叠。算子级仿真如果只算通信量乘带宽倒数，会明显高估通信时间，因为它忽略了重叠。
4. 搭一套可复现的算子级仿真流程
4.1 从真实负载采集标定数据
仿真要可信，标定数据必须来自真实硬件。我的建议是分三步走：
- 选定目标硬件和软件栈（框架版本、算子库版本、驱动版本都要固定），任何一项变化都可能让系数失效。
- 写一个微基准脚本，遍历你要支持的算子类型和 shape 区间，记录每个组合的实际耗时、达到的算力、访存量。
- 把原始数据存成结构化格式（比如 JSON 或 Parquet），保留采集时的全部上下文参数。
# 微基准采集的伪代码骨架 import time def benchmark_op(op_fn, inputs, warmup=10, iters=50): for _ in range(warmup): op_fn(*inputs) sync() start = time.perf_counter() for _ in range(iters): op_fn(*inputs) sync() elapsed = (time.perf_counter() - start) / iters return elapsed # 对每个 (op_type, shape, dtype) 组合调用并落盘注意 warmup 一定要做够，尤其是首次调用会触发 kernel 编译和内存分配，不 warmup 的数据全是噪声。sync 也不能省，异步执行下你测到的是入队时间不是执行时间。
4.2 把模型描述翻译成算子图
仿真器的输入通常是一份模型描述，输出是算子图加依赖关系。这一步可以复用框架的图导出能力，也可以手写。关键是保证算子切分和真实执行一致——比如融合算子（fused op）在仿真里也应该是一个节点，而不是拆成多个，否则时间估计会偏。
Charon 的算子级设计在这里体现价值：它接受的就是算子图，训练和推理只是同一张图在不同模式下的实例化。前向子图两者共享，反向子图只在训练模式激活，KV Cache 相关节点只在推理模式激活。
4.3 时间估计与误差校准
有了算子图和系数表，就可以逐算子算时间，再按依赖关系做流水线排布，得到端到端估计。这里有两个容易忽略的点：
- 重叠建模：计算和通信能重叠多少，取决于框架的调度能力。保守估计可以假设完全不重叠，乐观估计假设完全重叠，真实值在中间。建议先用一个可调的重叠系数，再用端到端实测去拟合。
- 排队与争用：多卡、多流并发时，算子之间会争抢资源。算子级仿真如果假设每个算子独占硬件，会低估时间。可以引入一个基于并发度的惩罚因子。
误差校准是仿真器能不能用的分水岭。我的经验是，单算子误差控制在 10% 以内，端到端误差控制在 15% 到 20% 以内，这个仿真器就有实用价值了。追求个位数误差往往得不偿失，因为真实系统的抖动本身就很大。
4.4 用同一份配置跑训练和推理对比
这是 Charon 最想展示的能力。同一份模型、同一套硬件描述，切换模式就能得到训练和推理的性能画像。你可以直接对比：同一个模型训练一步要多久，推理一个 token 要多久，瓶颈分别在哪。这种对比在容量规划和方案选型时非常有用。
| 对比维度 | 训练模式 | 推理模式 |
|---|---|---|
| 主要瓶颈 | 算力 + 互联带宽 | 显存带宽 + 延迟 |
| 关键算子 | 反向矩阵乘、梯度 all-reduce | KV Cache 读写、注意力 |
| 精度配置 | 混合精度 + 梯度缩放 | 低比特量化 |
| 并行重点 | 数据/张量/流水线并行 | 张量并行 + 批处理 |
| 仿真关注点 | 通信重叠、显存容量 | 访存效率、批大小敏感度 |
5. 实操中容易翻车的几个细节
5.1 系数表过期比没有系数表更危险
我踩过最狠的一个坑，是拿半年前的系数表去仿真新版本的算子库。表面上跑得通，结果端到端误差到了 40%。原因是新版本对某些卷积和注意力 kernel 做了重写，效率提升明显，旧系数严重高估了时间。教训是：系数表必须和软件栈版本绑定，升级任何一环都要重新标定关键算子。
5.2 shape 区间划分不能拍脑袋
效率系数是按 shape 区间查的，区间怎么划直接影响精度。划得太粗，区间内差异大，误差高；划得太细，表太大且很多区间没有足够样本。我的做法是先看实测数据的分布，在效率变化剧烈的地方（比如序列长度跨过某个阈值导致 kernel 切换）加密区间，在平缓的地方放宽。
5.3 别忽略内存容量约束
仿真器如果只算时间不算容量，会给出物理上跑不出来的方案。训练时激活、优化器状态、梯度加起来可能远超显存；推理时 KV Cache 随批大小和序列长度线性增长。Charon 这类仿真器需要在算子级跟踪内存占用，才能在容量维度上给出可行解。这一点在长上下文推理场景里尤其关键。
5.4 通信建模别只算带宽
前面提过，通信时间不等于数据量除以带宽。实际还要考虑启动延迟、协议开销、拓扑跳数。小消息的启动延迟占比很高，如果仿真器忽略它，会严重低估小规模通信的开销。建议对通信算子单独建一个包含固定开销加可变开销的模型。
6. 这套思路还能怎么扩展
Charon 把训练和推理统一到算子级仿真，这个底座一旦搭好，能延伸的方向不少。比如做自动并行策略搜索——把并行配置作为变量，用仿真器快速评估不同方案的端到端时间，比真机试错快几个数量级。再比如做硬件选型，把不同加速器的算子系数表换进去，就能预估同一模型在不同硬件上的表现。
我个人比较看好的一个方向是"训练-推理联合优化"。很多模型在训练时用的结构和推理时不一样（比如训练用完整注意力，推理用 KV Cache 优化版本），如果仿真器能同时刻画两者，就能在训练阶段就预估部署成本，反过来指导训练侧的结构选择。这种端到端的视角，正是统一仿真器相比两套独立工具最大的增量价值。
最后分享一个实操建议：如果你要基于这类仿真器做决策，先用它做相对比较（方案 A 比方案 B 快多少），而不是绝对预测（这个模型一定跑多少毫秒）。相对比较对系数误差不敏感，结论更稳。等系数表标定得足够细、误差校准做到位了，再逐步信任绝对值。这个顺序能帮你在仿真器还不完美的时候就用上它，而不是等它完美了才敢用。
