企业官网建设流程全解析

去年帮团队做新一代加速器的架构选型，在训练侧和推理侧来回折腾的日子，我到现在还记得。训练要盯的是整步吞吐和峰值内存，推理要盯的是单 token 延迟和批处理的取舍；同一个硬件方案，要在两套完全不同的仿真环境里各测一遍，最后得出的结论还经常互相打架。就在那段时间，我在系统方向的学术会议上留意到 Charon 这个项目。它做的事情一句话就能讲清楚：把训练和推理，装进同一个算子级仿真器。

所谓算子级，就是把网络拆成一个个可独立计费的算子（矩阵乘、卷积、注意力、归一化这些），每个算子按计算量和访存量分别建 cost model，再由仿真器统一调度、统一记账。Charon 的特别之处在于，它不区分“训练专用仿真器”和“推理专用仿真器”，而是用一套硬件描述、一套算子库、一套调度逻辑，同时覆盖前向、反向、权重更新和推理的 decode 过程。做芯片架构探索、编译器优化、调度策略设计的人，都可以拿它快速产出可对比的评估数据，省去重复搭环境和对齐口径的力气。这篇我把它的设计思路、核心抽象，以及我用同类工具做架构评估的实操过程和踩坑记录，完整写一遍。

1. 为什么非要把训练和推理塞进同一个仿真器

1.1 训练与推理仿真的现状割裂

现在的仿真生态基本是各管一段。训练侧仿真器关心的是大步长下的数据流、梯度同步、激活存储，衡量指标是每分钟能处理多少个样本；推理侧仿真器关心的是 decode 延迟、连续批处理（continuous batching）、KV cache 的增长速度，衡量指标是每次请求的 P99 时延。两边用的硬件模型口径都不一样，一个偏吞吐、一个偏延迟，连“算力利用率”这种基础指标算出来的意义都不同。

这种割裂不只是麻烦，而是会导致错误的架构决策。我之前就踩过这样的坑：某个设计方案在训练仿真器里跑得很漂亮，存储访问量、PE 利用率都很健康，但换到推理仿真器里一测，KV cache 的带宽压力直接让吞吐腰斩。问题是这个方案在训练侧压根不产生 KV cache，所以训练仿真器根本看不到这根瓶颈。反过来也有：为推理优化的低精度方案，训练仿真器里因为梯度精度约束不得不回退到高精度，评估结果一团糟，但实际系统里完全可以混合精度训练。两套环境各说各话，最后只能靠人肉对齐假设，对齐过程出了几次错之后我就彻底烦了。

Charon 解决的就是这个对齐问题。它不要求用户为训练和推理分别构造硬件模型，同一个 dpu 描述、同一个内存层级、同一个算子成本函数，只是把“驱动循环”换一下：训练模式跑的是前向+反向+权重更新的迭代，推理模式跑的是 prefill+decode 的请求调度。这样出的对比结果天然同口径，训练侧的优势和代价能够直接投射到推理侧，反之亦然。

1.2 算子级：速度与精度之间的“甜点位”

为什么非选算子级这个粒度，而不是更细或更粗？先说更细的周期精确级仿真，那基本是把 RTL 或行为级模型搬进模拟器，跑一个矩阵乘都要几百万周期，跑完整 Transformer 的一个训练 step 得按天算。架构探索阶段需要快速扫过十几个候选配置，这种速度根本扛不住。再说更粗的 roofline 解析模型，它只给出理论峰值和带宽上限的比值，完全忽略数据流策略、片上阵列组织、算子间调度重叠这些真实系统中决定性能的因素。

算子级正好卡在中间。每个算子被抽象成一个“带参数的盒子”，盒子内部计算量是确定的，访存量按 tiling 策略和数据流假设计算，算子的执行时间取计算时间和访存时间的交集（能重叠的部分重叠，不能重叠的部分串行）。仿真器负责把这些盒子按依赖关系排布，决定片上有多少数据可以复用、哪些中间结果要写回 DRAM、哪些算子可以并行。这样既能捕捉到“这个模型在什么规模开始从计算受限变成访存受限”这样的第一性效应，又能把整个网络的仿真时间压到秒级甚至毫秒级。

用表格对比更直观：

Charon 走的是中间这条线，我认为这是目前架构评估性价比最高的粒度，前提是你知道自己要回答什么层次的问题。要回答“我的设计能不能跑赢对手”，算子级完全够用；要回答“某个流水线 stage 的毛刺时序是否影响频率”，那就别偷懒，上周期精确。

2. Charon 的核心抽象：一张算子公司 + 统一调度

2.1 如何用算子描述覆盖训练与推理

算子库是这套仿真的地基。Charon 的算子分类不按“训练算子/推理算子”分，而是按计算特征分：计算密集型（matmul、conv、einsum），访存密集型（layernorm、softmax、elementwise 类），以及通信类（allreduce、allgather、send/recv）。每个算子在库里都有统一的接口描述，包括输入输出 shape、dtype、数据布局、可选的 tiling 策略。

一套算子库同时支撑训练和推理，关键在反向算子的生成机制。这里用的是伴随算子（adjoint operator）的思想：给定前向算子 Y = X·W，反向阶段的 dX 和 dW 不需要用户手写，仿真器根据前向算子的定义自动展开成两个伴随算子，一个读 dy 和 W 生成 dx，另一个读 dy 和 X 生成 dW。这意味着定义训练工作负载时，你只需要描述前向计算图，反向图是自动生成的，代价是计算量翻倍、并且引入了对前向激活的依赖——这正好引出了内存建模的问题。

推理侧则是前向计算图的一个特化子集，但数据库里必须要多出几个专属算子：KV cache 的写入和读取、注意力 score 的 mask 处理、以及 decode 阶段的增量 matmul。特别值得留意的是 decode 阶段，每次只多算一个 token，但 matmul 的 K 维度是不断增长的 KV cache，这个形态和训练阶段的“定长矩阵乘”完全不同，算子库不单独处理的话，访存量会被少算好几个数量级。

2.2 内存模型：给激活、梯度和 KV cache 一个统一的账本

训练和推理在内存上的账本，最难统一的部分是“生命周期不一致”。权重的生命周期最长：训练阶段按 step 更新，推理阶段加载后基本不变；激活的生命周期很短：训练时只活到反向用完它为止，推理时根本没这个家伙；KV cache 则是推理专属的增长型内存。

Charon 的解法是给每个张量挂一个 liveness 区间，仿真器在调度执行时动态维护一片“统一内存视图”，按生命周期把三种张量分别记账。训练模式下最核心的取舍是：前向激活是全部保存供反向使用，还是部分丢弃、反向时重算。全部保存的访存成本低，但峰值内存会随 batch 和网络深度线性涨；重算的内存峰值小，但反向要多算一遍前向的计算量。仿真器把这两个策略都做成可配置选项，跑一次就能同时拿到“内存峰值”和“计算时间”两个指标，做出明确的帕累托曲线。

推理模式下内存建模的重心放在 KV cache 的增长上。每新增一个 token，每一层都要写入 key 和 value，这个增量是固定的，但它会一直积累到序列结束。更关键的是 decode 阶段读取 KV 的访存量是累计的：序列越长，每次读 KV 的流量越大。这个“写入一点、读取全部”的不对称，是推理性能建模的精髓，也是训练仿真器完全看不到的现象。

2.3 训练与推理的共性内核与差异分支

说了这么多差异，还要强调一组共性内核，这正是统一仿真器能成立的前提：前向算子的成本函数在训练和推理里完全一致。同一个 matmul，在训练的前向里计算量是 M×N×K，在推理的 decode 里同样是 M×N×K，芯片的 PE 阵列、片上带宽、DRAM 带宽也都一样。差异只出现在驱动循环和附加状态上。训练模式多了反向图、梯度同步和权重更新；推理模式多了 KV cache 管理、连续批处理和延迟目标约束。

这个设计哲学特别适合今天的硬件现实：绝大多数 AI 加速器的定位是“训推一体”，同一个芯片既要能训练小模型，也要能高效跑大模型推理。用分裂的仿真器去做训推一体的芯片架构探索，等于用一个哑铃的两头去练同一个动作，中间训练到的“过渡区域”全是盲区。Charon 把训练和推理对齐到同一套抽象之后，可以回答一个之前很难回答的问题：如果我的芯片把 SRAM 增大一倍，训练吞吐提升 12%，推理的 KV cache 带宽压力能缓解多少？这种跨工作负载的设计权衡，只有统一仿真器才能给出可对比的数字。

3. 实操：用 Charon 评估一块推理加速卡的设计

3.1 从硬件参数到仿真配置

我习惯先把硬件配置写成一段显式的初始化代码，而不是藏在一个复杂的配置文件里，这样每次扫参时看 diff 都一目了然。以下是一个典型的配置片段：

from charon import Accelerator accel = Accelerator( pe_array=(8, 8), # 每个核内 8x8 的 MAC 阵列 cores=8, # 8 个核心 frequency=1_000_000_000, # 1 GHz macs_per_cycle=4096, # 每核每周期 MAC 数 = 64 sram_per_core=2_000_000, # 每核 2MB 片上 SRAM dram_bandwidth=256e9, # 256 GB/s 的 DRAM 带宽 dataflow="weight_stationary" # 数据流策略 )

注意一个容易糊涂的参数：每核 8x8 MAC 阵列，每周期完成 64 次 MAC，8 个核合并起来每周期 512 次 MAC。如果按峰值算力表达，这就是 512 × 2 × 1GHz = 1.024 TFLOP/s 的 fp16 峰值。这个数字不算夸张，但对算子级仿真已经很能说明问题——峰值算力低的时候，访存带宽往往比算力更容易成为瓶颈的“遮羞布”，如果你的仿真结果里所有算子都是访存受限，先别急着改架构，回头看看是不是内存层级配置写错了。

dataflow 参数我单独拎出来说，因为它是算子级仿真里最容易被忽略的一颗大雷。weight_stationary 假设权重被固定在片上重复利用，适合权重比激活大得多的场景；output_stationary 则是把输出累加留在片上，适合卷积这类输出累加路径较长的场景。同一个 PE 阵列，换一个数据流假设，访存量可能差出 3 到 5 倍。所以做系列对比时，dataflow 必须锁定，否则你看到的“架构差异”其实是“数据流假差异”。

3.2 定义工作负载：一个 12 层 Transformer 的例子

模型配置我选了一个接近经典规模的 Transformer，参数如下：

from charon import TransformerConfig, Trace model = TransformerConfig( layers=12, hidden=768, heads=12, ffn_hidden=3072, dtype="fp16" ) # 训练模式：自动生成前向 + 反向 train_trace = Trace.from_model(model, batch=16, seq_len=1024, mode="train") # 推理模式：prefill + decode infer_trace = Trace.from_model(model, seq_len=2048, mode="inference")

先手工估算一下训练模式的工作量。对于这个模型，每个 token 每层的前向 FLOPs 大约在 0.34 GFLOPs 量级（注意力投影加 MLP 上下投影），12 层乘起来，单 token 前向大约 0.17 GFLOPs（后文展开计算会说明这个量级怎么来的）。batch=16、seq_len=1024 意味着一个 step 有 16384 个 token，前向总计算量约 2.8 TFLOPs；反向大约两倍，约 5.6 TFLOPs，单步训练总计算量约 8.4 TFLOPs。用上面那块 1.024 TFLOP/s 峰值的芯片跑，理想情况下单步训练理论计算时间约 8.2 秒——这个数字在仿真器里跑出来会略有偏差，因为访存、调度重叠和数据流效率都要打折扣。

那个 0.17 GFLOPs 的量级可以快速验证：模型单层参数量约 7.08M（注意力四个投影 4×768² + MLP 上下两个 768×3072），12 层合计约 85M 参数。训练场景下前向 FLOPs 约等于两倍参数量，也就是约 170M FLOPs/token，换算成 GFLOPs 就是 0.17。这个“前向 FLOPs ≈ 2×参数量”的经验公式在 Transformer 上是好用的，做手算复盘时能救急。

3.3 跑仿真：训练模式与推理模式的指标对比

仿真执行本身就一行调用：

from charon import Simulator sim = Simulator(accel, train_trace, memory_strategy="recompute_all") train_report = sim.run() sim.load_workload(infer_trace, memory_strategy="kv_cache_only") infer_report = sim.run()

第一次跑出来的训练报告，我把它整理成下面这个样子的表格，注意这里展示的是对指标结构的理解，不是某一颗具体芯片的真实数字：

反向占了三分之二的计算时间，这完全符合“反向≈两倍前向”的预期，但值得警惕的是访存占比：反向阶段的访存不光是读权重，还要把前向保存的激活重新读一遍。我在这块踩过坑，如果 memory_strategy 选的是“保存全部激活”，反向访存里会有大量激活读取流量，仿真报告会显示峰值内存暴涨——这不是仿真器的问题，而是策略选择的问题，实际系统往往通过重计算来换内存，你要确保策略和真实部署方案一致。

推理模式的结果更有意思。decode 阶段单 token 的前向计算量只有约 0.17 GFLOPs，对应计算时间只有微秒级，但访存端 KV cache 的读取流量在快速增长：序列长度 2048 时，每层 KV 数据约 3.1 MB，12 层累计 37.7 MB，按 256 GB/s 带宽算，读一次 KV 要 0.15ms。这时你会清晰地看到，推理单 token 延迟完全由访存主导，计算时间几乎可以忽略不计。仿真器输出的对比表里，计算时间和访存时间差出两个数量级，从架构角度看，此时优化重点应该放在压缩 KV cache 精度、提高 cache 命中率，而不是堆 MAC 阵列。

3.4 读仿真结果：怎么判断瓶颈在哪

拿到仿真报告，不要只盯着总时间，我建议按下面这个顺序去挖信息。先看算子的时间分布 top-k：训练模式下 matmul 通常会占据 80% 以上时间，这是正常现象；如果你看到 layernorm、softmax 这类小算子合起来占了超过 20%，说明要么 batch 太小导致访存占比失衡，要么硬件配置里带宽过窄，需要回头调参。再看“小算子长尾”：训练计算图里往往有成百上千个 elementwise 算子，单个只花几十纳秒，但调度开销和访存排队常常让它们成为隐藏的长尾，这正是算子级仿真比解析模型强的地方——它能暴露这些真实系统中被忽略的尾部延迟。

对推理模式，重点看 compute/memory 重叠率。decode 阶段的理想状态是：访存 KV 的同时，计算引擎可以开始下一批算子的预取和计算。如果仿真器显示重叠率接近 1，说明调度器把访存和计算安排得很好；如果重叠率很低，别急着骂架构，先检查算子依赖图里是否存在“等待上一算子结果才能计算下一算子”的严格串行路径，很多情况下这是模型结构导致的调度困难，不是芯片本身的问题。

最后一定要把训练指标和推理指标放在同一张图里看。比如我前面那个例子，训练模式显示这个设计是计算受限（反向三分之二算力压力），推理模式显示是访存受限（KV 读取主导）。这说明同一颗芯片在不同工作负载下拥有完全不同的瓶颈状态，你做架构决策时不能只盯其中一个模式，这正是 Charon 这种统一仿真器存在意义的直接体现。

4. 常见问题与排查技巧实录

4.1 激活重计算的建模偏差

我第一次用算子级仿真器时的典型翻车现场是：仿真报告显示的峰值内存比实际部署方案高出一大截，我一度以为是芯片 SRAM 配置不够，后来发现是 memory_strategy 默认值的问题。很多算子级仿真器的默认策略是“保存全部激活”，因为这是实现最简单的方案——每个前向算子算完就把输出留在内存账本里，直到对应反向算子读完才释放。而真实系统为了省内存，普遍采用激活重计算，也就是反向阶段需要某个前向激活时，重新算一遍而不是从内存里读。

排查思路：检查仿真报告的“激活释放时机”和“重计算计数”。正确建模重计算之后，激活峰值内存通常能降 40% 到 60%，但计算时间会额外增加一段“重计算前向”的开销。我踩过坑之后总结出一条经验：不要默认仿真器的内存策略就是你的部署策略，一定要把实际系统里的重计算开关、梯度检查点（gradient checkpointing）配置显式告诉仿真器，否则你优化半天内存，结果是在优化一个根本不存在的瓶颈。

4.2 多核通信与计算重叠导致结果偏悲观

做多卡并行训练仿真时，如果结果比实测慢两到三倍，大概率是通信和计算没有重叠建模。最简单的仿真器实现是“先算完所有算子，再执行 allreduce，再进入下一轮”，这是串行视角，但真实系统里梯度 allreduce 是可以和下一层的前向计算重叠的，这就是流水线并行的基本功。算子级仿真器如果不对通信算子做异步建模，训练 step 时间会被显著高估。

排查技巧：把通信带宽设成无穷大，看总时间降了多少。如果降幅超过 30%，说明通信耗时的权重被严重高估，需要检查通信算子是否支持 async 执行、是否和计算算子有依赖关系上的错误约束。反过来说，如果带宽翻倍后总时间几乎不变，说明计算根本不是瓶颈，别在通信优化上浪费资源。这个“带宽敏感性测试”是我现在做每次架构评估必跑的 sanity check。

4.3 数据流假设不一致导致对比失真

跨论文、跨工具对比仿真结果时最容易掉进的大坑，是数据流假设不一致。A 工具默认 weight_stationary，B 工具默认 output_stationary，你拿去对比两个架构设计，得出“B 比 A 访存效率高 30%”的结论，但实际上 B 只是站了一个数据流便宜。算子级仿真的访存计算完全取决于数据流策略，同样的 PE 阵列和 SRAM 配置，不同数据流可以造成数倍的访存差异。

排查方法很直接：在仿真配置文件里显式打印每个算子的 dataflow 属性，对比实验前锁死该项。我在实际项目中专门写过一个配置校验脚本，跑对比实验前自动检查两个配置的 dataflow、dtype、带宽参数是否一致，不一致直接报错。这个小工具帮我挡掉了至少三次“假架构优势”的报告。

4.4 算子级仿真解决不了的事

务实地画一条能力边界。算子级仿真给不了你真值：它不模拟 RTL 级时序，所以流水线气泡、阵列内部的 bank conflict、片上网络拥塞这类微架构效应它是不精确的；它通常也不建模物理效应，功耗、温度、线延迟这些在架构评估后期才会被人想起来，但到那时候你已经很难回头改算子库了。我现在的做法是：架构探索阶段用算子级仿真快速收敛到两三个候选方案，然后用周期精确仿真器对这二三个候选做深度验证，两边结果相互校验。

另外，算子级仿真的“单算子校准”很重要。拿到一台真实芯片或者详细的 RTL 仿真数据后，我建议先挑三五个代表性算子（一个 matmul、一个 attention、一个 elementwise），把仿真器的成本函数和真实数据对一遍，调校误差系数。不做校准的绝对值不能信，但校准之后的相对对比（方案 A vs 方案 B）是相当稳的。

5. 写在最后：几条经验

用这类统一算子级仿真器做了几轮架构评估之后，我最大的体会是：它的价值不在于给你一个绝对精确的“性能数字”，而在于让所有候选方案服从同一套“度量衡”。以前训练侧和推理侧各说各话，现在至少能在同一张配置表面前吵架，吵出来的结论才是有依据的。

还有两条小建议送给刚入坑的朋友。其一，配置永远保持最小化，能用一个脚本生成的配置就别手写，扫参时用脚本批量跑，保留每次的配置快照，否则你可能复现不了自己三天前跑出的那个漂亮结果。其二，刚从训练模式切到推理模式时，先跑一个只有几层的迷你模型验证 KV cache 逻辑，不要一上来就全模型跑，否则你在一个巨大的图上找 bug 会非常痛苦。把这些基本功做好，统一仿真器能给到你的信息密度，远比你在两套分裂工具之间来回搬数据的效率高得多。