你可以把 GPU 想成一家厨房：厨师动作很快，真正拖时间的是仓库不断把食材送到案板。稀疏专家混合模型也是如此。它虽然每次只调用少数“专家”，却仍要从显存读取这些专家的大量权重。FORGE 提出的办法很直接：别搬整箱食材，只保存一张简短配方，需要时就在芯片上现场做出来。
FORGE，全称 Fast On-chip Rotor Generation for Experts，是一套面向稀疏 MoE 推理的程序化权重生成系统。MoE（Mixture-of-Experts，专家混合模型）在模型内部放置许多不同的子网络，每次处理一个词元时只启用少数几个。这样可以容纳大量参数，又不必每次运行全部专家。
问题在于，没被同时计算，不等于不占地方。论文研究的五个模型中，专家权重占模型参数的 94%—98%。这些权重是训练后保存下来的数字，决定模型如何变换输入。传统部署要把它们放在 HBM——GPU 附近的高速显存——并在使用时反复读取。生成文字时，每一步通常只产生一个新词元，芯片常常不是算不动，而是在等权重送达。
以下性能与硬件数字均来自 FORGE 作者团队的论文、测量和估算，目前没有独立硬件或第三方复现。
不存整张表，保存生成它的“配方”
FORGE 改写了一个长期默认的前提：专家权重不一定非得作为完整张量常驻 HBM。它把部分专家的线性投影近似表示为 rotor。Rotor 是一种由旋转组合而成的结构化变换；系统只保存决定这些旋转的紧凑参数，再按固定顺序重建近似权重。
每个投影只需 个 rotor 参数，其中 是投影维度。按照论文给出的五个模型配置，每个被替换层原本数 GB 的专家权重，可以由不足 1 MB 的 seeds——用于重新生成权重的紧凑参数——近似替代。各模型每层 seeds 约为 221 KB 到 776 KB。
这不是无损压缩。FORGE 并不能从小文件中恢复原来一模一样的权重，而是离线为预训练专家拟合一组 rotor 参数，推理时据此生成近似矩阵。因此，它节省存储的同时，也会改变模型本身。
真正难的是生成得足够快
如果现场制作比从仓库取货还慢，这个思路就没有意义。作者先尝试用普通 GPU 软件生成权重，但结果并不理想：在五个模型上，单是生成过程就比原来的“读取权重并完成计算”慢 25.8—45.1 倍。
原因不是简单的代码优化不足。Rotor 需要大量规则固定、但访问形状不规整的更新。用 GPU 的通用 SIMT 执行管线处理，会发出远多于基线的指令，还会频繁遇到共享内存 bank conflict——多个访问争用同一内存通道。结果是生成权重的程序反而让负责矩阵运算的 Tensor Core 等待。
FORGE 因而增加了一块专用硬件：Rotor Generation Unit（RGU）。每个 Streaming Multiprocessor（SM，GPU 内负责组织计算的一组执行单元）内部放置一个 RGU。它按需生成前馈网络 FFN 的权重小块，直接写入共享内存，再交给 Tensor Core 使用。
RGU 利用 rotor 更新中预先可知的独立关系，提前安排不会冲突的行对，并行处理不同列、行对和矩阵块。它有自己的固定功能数据通路，因此不直接占用 Tensor Core 的执行资源。这里的“不争用”只指这条专用计算路径；整个系统仍可能存在功耗、调度、面积和其他数据搬运成本。
作者已经用 SystemVerilog 完整实现并验证 RGU。按 7 nm 工艺估算，每个 SM 需要 0.032 mm²，约占一个 SM 面积的 0.9%。这仍是基于综合和模型得到的面积估算，不是量产芯片实测。
它改变的不只是一次读取
FORGE 的收益有两层。第一层是少搬权重。在专家接收到的词元较少时，FFN 计算容易受 HBM 带宽限制。RGU 一边生成下一块权重，Tensor Core 一边处理当前块，作者据此估算，被替换层可以从“等数据”转向更多由计算速度决定。
第二层是腾出显存。大型 MoE 往往需要把专家分散到多块 GPU，称为 Expert Parallelism（专家并行）。不同 GPU 每一步都要交换被路由的词元。权重占用减少后，模型可能使用更少的 GPU，或为 KV cache 留出更多空间。KV cache 是模型生成文字时保存的中间结果，作用像一张草稿纸，避免每一步都从头计算。
在五个稀疏 MoE 模型中替换 30% 的 MoE FFN 层后，论文估算：相同 GPU 数量下，系统吞吐量可提高 1.3—2.8 倍；短上下文中的单用户解码延迟可降低 1.10—1.15 倍；KV cache 容量可扩大 1.2—2.6 倍。吞吐量提升不等于每位用户都获得同样幅度的加速。长上下文中，KV cache 访问和 Attention 计算会逐渐占据更多时间，FORGE 对单用户延迟的帮助也会收窄。
FORGE 也不依赖权重以多少位存储，因此在架构上可以和量化结合。量化是用更少位数表示权重；它减少每次搬运的数据量，而 FORGE 尝试直接取消部分权重搬运。不过，论文提出的是兼容性，不能据此认定两者叠加后的准确率和端到端收益已经得到验证。
真正的账单是准确率
FORGE 最值得关注之处，不是某个单项加速数字，而是它重新划分了稀疏模型的成本：过去用显存保存权重、用带宽搬运权重；现在可以用少量 seeds 和专用生成电路，换回显存容量与带宽。
但这笔交换有明确代价。论文在三个模型家族上的结果显示，采用 rotor replacement 的模型，下游准确率低于同一模型未采用替换的微调版本。替换比例越高，潜在系统收益越大，准确率风险也随之增加。作者把 30% 替换作为较保守的评估点，并没有证明这种下降已经可以忽略。
局限与未知
- 1.3—2.8 倍吞吐提升、1.10—1.15 倍短上下文延迟改善和 1.2—2.6 倍 KV cache 扩容，都是绑定五个模型、30% 层替换及相同 GPU 数等条件的作者估算，不能泛化到所有 MoE 部署。
- RGU 的数据来自 RTL 实现、综合结果、H100 上的基线测量和系统级分析模型，尚缺少集成到真实 GPU 后的功耗、调度与端到端验证。
- 最关键的开放问题不是还能省多少权重，而是如何在提高替换比例时守住准确率。FORGE 已证明这条交换路径存在，但尚未证明它在实际产品中值得付账。