Moe模型介绍与FPGA实现的简略分析，这事最近挺多人问。一方面Moe架构几乎是大模型稀疏化的代名词，另一方面FPGA总有人想拿来跑点轻量级推理或者做异构加速原型验证。我自己在FPGA上折腾过几版Transformer和MoE子模块，踩了不少坑，今天干脆把Moe的核心机制、软硬件边界、以及FPGA上真正可行的实现路径一次性说清楚，争取让搞算法和搞硬件的人都能看懂。
先说结论放前面：如果你指望用一块中端FPGA去完整推理一个几十B甚至上百B的Moe大模型，趁早打消念头，FPGA的算力密度和内存带宽放在那里，跑大模型不是它的主场。但如果目标是Moe场景下的稀疏路由、Top-K门控、专家并行调度、或者针对某个特定专家子网络做加速，FPGA反而有独特的优势。这篇文章就从这几个角度展开，从模型原理一路聊到Verilog和HLS怎么落地。
1. Moe架构为什么火，火在什么地方
1.1 从Dense到Sparse的本质变化
先捋清楚一个最基本的点。传统Transformer每一层FFN（Feed-Forward Network）对所有token都是全量计算的，不管这个token是“中国的首都是____”里的“的”，还是“北京”这种关键词，计算量一视同仁。这就造成一个现象：模型越做越大，大部分参数实际上只对少量token有反应，但推理时每个token都得过一遍全量计算。
Moe做的事情说白了就是“把专家分开”。每个token在进入FFN层时，先由一个Router（门控网络）打分，选出Top-K个专家，然后只把这几个专家的计算加载进来。这样总参数量可以做到很大，但单个token只激活其中一小部分，推理的FLOPs大幅下降，这就是所谓Sparse MoE。
我见过不少刚开始接触Moe的人有个误解，觉得Moe是某种新的注意力机制或者新的模型结构。其实不是，Moe通常就是替换Transformer里FFN那一块，Attention部分该怎么做还是怎么做。所以你在代码里看到的通常是一个MoeLayer包裹着若干Expert FFN，还有一个Router，整体插入Transformer Block中间。
1.2 热门模型里的Moe形态
2023年到2024年，Moe基本成了大模型的标配路线。Mistral的Mixtral 8x7B把Moe带入开源主流，总共46.7B参数，但每次推理只激活12.9B，直接让本地部署的门槛降了一截。到了DeepSeek-MoE，进一步把专家切得更细，用Fine-Grained Expert Segmentation和Shared Expert Isolation，把专家数量做到160+，但每个token只激活6到8个专家，成本控制得更狠。后来Gemma-27B的MoE版本，据说内部每个专家相对更小，路由也更高效。
这些模型的一个共同特征是：Expert数量多，但单个Expert的规模不算大（通常就是一个hidden size在几千维的FFN）。这对FPGA来说反而是好消息。因为单个专家网络刚好是那种数据流清晰、并行度可挖掘、不需要太大片上的模型，非常适合用FPGA做定制化加速。
1.3 Moe省下来的算力去哪了
Moe不是凭空减少计算量，它减少的是“无效计算”。但也引入了新的开销：Router计算、Top-K选择、专家之间的All-to-All通信。在单机多卡场景里，All-to-All往往比计算本身还贵。Google在GShard论文里就说过，MoE在大规模分布式训练时，通信量和同步开销会吃掉一大部分理论加速比。
放到FPGA上，这个“通信开销”就变成了另一个问题——路由决策的延迟。FPGA上实现Router和Top-K排序，延迟大概在几十到几百纳秒级别，对于单batch推理来说可以忽略，但如果要做高吞吐的流式处理，这个延迟必须流水化隐藏掉。
2. FPGA实现MoE的第一个关键：拆分计算
2.1 为什么不能直接拿FPGA跑整个MoE
直接上结论：FPGA不是不能跑大模型，但不适合单芯片跑大模型。原因有两个，一个叫“存不下”，一个叫“跑不动”。
存不下指的是片上BRAM/URAM总量。中端FPGA芯片，比如Artix-7或者ZYNQ-7020，BRAM大概几百KB到几MB；高端一点的UltraScale+系列能到几十MB，但和几十GB的模型权重一比还是杯水车薪。就算把权重放外部DDR4/DDR5，每batch都要从DDR拉几十MB权重进来，DDR带宽立刻成为瓶颈。
跑不动指的是DSP资源。FPGA上的DSP数量有限，中端芯片几百个DSP，高端芯片几千个，但每个DSP的MAC吞吐远不如GPU的Tensor Core。拿UltraScale+里性能最好的VU9P举例，INT8峰值大概能做到几TOPS，同期的GPU已经奔着几百TOPS去了，中间差两个数量级。
所以我自己的判断是：FPGA做MoE，正确的姿势是“特化子模块+异构协同”，而不是“整模型移植”。
2.2 把MoE拆成可落地的子任务
FPGA实现MoE时，我通常把整个流程拆成四个子任务：
- Router计算，也就是Gate Network，输入是上一层输出的hidden state，输出是每个专家的得分；
- Top-K选择，从几十个或上百个专家的得分里挑出K个最大的；
- 被选中的Expert FFN前向计算，这是计算量最大的部分；
- 加权合并，把K个专家输出按权重加权求和，得到最终输出。
这四个任务里，Router和Top-K的逻辑规模不大，但控制流密集，FPGA写起来需要小心；Expert FFN则是标准的矩阵乘加（GEMM）运算，适合用脉动阵列或者分块矩阵乘法来做；加权合并是简单的MAC累加，但有跨专家依赖，需要处理时序。
从资源占比看，Expert FFN通常占80%以上的FPGA资源，Router和Top-K占不到20%。所以FPGA优化的头号重点，永远是把Expert FFN的GEMM效率做到位。
2.3 一个适合FPGA的MoE规模参考
我实践下来，FPGA上比较舒适的MoE加速范围是：
| 参数项 | 推荐范围 | 说明 |
|---|---|---|
| 专家数量 | 8~32 | 再多的话Router和索引逻辑会膨胀，且评估矩阵乘法利用率下降 |
| 每个专家的隐藏层维度 | 512~2048 | 太小的GEMM无法填满DSP阵列，太大的权重放片上放不下 |
| 一次路由选择的专家数K | 2~4 | K越大，输出合并的依赖链越长，时序更难收敛 |
| 数据类型 | INT8/FP16 | 实测INT8在FPGA上比FP16快1.5倍以上，且资源省一半 |
| 单batch隐藏层状态 | 1~64个token | 更大batch更适合GPU，FPGA优势在低延迟小batch |
如果你项目需求里的MoE规模远远超过这个范围，建议直接考虑GPU或者专门的NPU芯片，别在FPGA上死磕。这不是技术不行，是成本不合适。
3. 从零搭建FPGA上的MoE推理流水线
3.1 先搞定Router和Top-K，这部分入门最快
Router本质上就是一个线性层加Softmax。输入是hidden state，输出是每个专家的得分。FPGA实现通常会用查表法或者分段线性逼近来做Softmax，因为完整指数函数在FPGA里代价太高。
我实测过一个64专家的Router，用分段线性逼近实现Softmax，精度损失在0.1%以内，但资源占用只有真正指数实现的三分之一。核心思路是：把Softmax的输入范围切若干段，每段用一个一次多项式近似，然后用一个比较器确定输入落在哪个段。
Top-K选择我建议别用全排序，太浪费资源。用定点排序网络，比如双调排序（Bitonic Sort），或者直接用贪心Top-K流水线：维护一个长度为K的最小堆，每个专家得分进来时和堆顶比较，大于堆顶则替换并调整堆，小于则跳过。64个专家选Top-4，这个结构在FPGA上只要几百个LUT，延迟大概几个时钟周期。
提示：Router和Top-K虽然看起来简单，但要注意Sigmoid或者Softmax的输入范围。有些框架里Router的输出会乘一个temperature缩放系数，FPGA定点化时这个系数可以提前融合到权重里，省一个乘法器。
3.2 Expert FFN的矩阵乘，才是主战场
每个Expert一般就是一个两层的FFN，包含一个升维矩阵（比如从hidden 512到intermediate 2048）和一个降维矩阵（从2048回到512），中间夹一个激活函数。FPGA上做矩阵乘的黄金结构是脉动阵列（Systolic Array）。
我以前写过一个32x32的脉动阵列做GEMM，每个PE包含一个DSP和一个BRAM小缓存，通过数据在阵列里的流动复用权重和输入激活，最后累加输出。对于单个小规模Expert FFN，这种结构的DSP利用率可以做到80%以上。
如果专家数量一到几十，直接把每个专家都实例化一遍肯定不现实。更合理的做法是“专家复用”：把所有专家的权重按顺序存放在BRAM或外部DDR里，一个GEMM计算单元轮流处理被选中的专家。这样FPGA上只有一个或少数几个GEMM引擎，但是通过时分复用覆盖所有专家。
时分会带来一个问题：权重切换时要flush流水线，相当于每次切专家都有几十个周期在空转。我的做法是做一个简单的双缓冲：提前把下一个专家的权重预加载到另一块BRAM里，当当前专家的GEMM算完，马上切换，空转时间从几十个周期压到两个周期。
3.3 加权合并和残差连接
Moe层最后还有一个重要步骤：把Top-K专家的输出按router的权重加权求和，然后再做残差连接和LayerNorm。这一步看着不起眼，但有隐藏的精度问题。
Top-K专家输出加权求和需要在FPGA上遵循一个原则：先累加K个专家各自的输出，再乘权重，还是先乘权重再累加，结果在浮点上可能不一样。FPGA上通常做定点计算，所以我推荐先乘权重再累加，这样每个专家输出已经缩放过，最终累加结果的动态范围更可控。
如果每个专家输出是FP16，权重也是FP16，那么乘法器输出可以用FP32累加，再把最终结果转换成FP16。我自己在Vivado里用AXI-Stream接口把这些子模块串起来，整体延迟做个几十个时钟周期，实际部署效果不错。
4. 我踩过的FPGA-MoE的坑，以及排查方法
4.1 “权重加载太慢”才是最普遍的瓶颈
很多教程里只讲计算怎么加速，不讲权重从DDR搬到片上有多慢。以32个专家、每个专家5MB权重为例，总共160MB权重，从DDR4搬到BRAM，按DDR4-2400的单通道带宽约19GB/s算，搬一次要8.4毫秒。如果你每个token都要把所有专家权重扫一遍，那绝大部分时间都在搬数据。
解决思路是两级缓存：DDR存全量权重，BRAM存当前活跃专家的权重。当一个Expert被频繁选中时，权重可以长时间驻留在片上；只有在专家切换频繁时，才需要反复从DDR拉。另外，通过分析实际推理时专家选择的局部性，可以按热度把专家权重做一次排列，让大概率同时被选中的专家放在相邻地址段，这样突发读的效率会高很多。
4.2 Top-K的确定性在FPGA上容易被忽略
不同的Top-K实现，选出相同值的专家时顺序可能不同。这在软件里无所谓，但在FPGA里如果多加了一个调试探针或者改变了综合策略，结果可能就变了，给验证带来麻烦。
我的建议是：Top-K排序时，除了比较score之外，还必须比较专家编号，也就是所谓的tie-breaker。在硬件里用score高32位和expert ID低32位拼成一个64位数参与比较，这样可以保证在score相同时，编号小的专家胜出，结果就是完全确定的。
4.3 资源评估别光看LUT和DSP
FPGA实现MoE时，光看LUT、FF、DSP占用率会踩坑。MoE的Expert复用结构下，BRAM和URAM的占用往往更早达到极限。因为权重缓存、中间激活缓存、Router缓存、TopK状态全部要BRAM。我早期做的时候，DSP只用了55%，BRAM已经爆了，最后不得不降缓存深度。
评估时务必把下面几个存储项都算进去：
- 全量权重存储（通常在DDR，不需要BRAM）
- 活跃专家权重缓存（BRAM/URAM）
- Token序列的中间激活（BRAM）
- Router权值（BRAM）
- Top-K最小堆（FF或BRAM）
- DMA描述符缓存（BRAM）
4.4 时序收敛：专家复用带来的长组合路径
把多个专家的GEMM结果汇入同一个加权模块时，很容易出现一条很长的组合逻辑路径，导致时序不收敛。解决的办法是每级之间插入流水寄存器，尤其是从DDR读回来的权重数据和从GEMM输出的部分和之间，必须加寄存器打拍。
我在Vivado里通常这样做：先设一个相对宽松的时钟（比如100MHz）把功能跑通，再逐步加压到150MHz、180MHz，每次加压重点看critical path落在哪个模块。实测下来，最常见的关键路径是从BRAM读出的权重数据经过乘法器再到累加器的链条。优化方法是把GEMM内部累加分成两段或三段，每一段单独打拍，用增加几个周期延迟换取更高的Fmax。
5. 工具链选型：HLS还是Verilog
5.1 什么时候用HLS
Moe里有大量矩阵运算和循环嵌套，如果用纯Verilog写一个GEMM引擎，代码量非常庞大，调试周期也长。HLS（Vitis HLS）对这种场景效率高很多，因为矩阵乘的loop可以通过pipeline和array_partition指令快速优化。
我实际用Vitis HLS做过一个INT8 GEMM引擎，输入的矩阵是32x512乘512x2048，加pipeline之后II（Iteration Interval）能做到1，也就是每个时钟周期完成一次输入MAC，DSP利用率70%以上。开发周期大概是一周，如果用Verilog写，两周起步。
5.2 什么时候必须用Verilog
Router和Top-K这种控制流密集、位宽操作精细的部分，用HLS反而不方便。比如Top-K双调排序网络，HLS的循环展开和数组partition控制在某些情况下并不直观，性能也不容易把控。我习惯在这两个模块用Verilog手写，然后把它们实例化到HLS生成的GEMM引擎外面。
5.3 我推荐的工程架构
综合下来，我自己的MoE-FPGA工程结构是：
- Top模块用Verilog写，负责整体状态机、DDR读写控制和子模块例化；
- Router和Top-K手写Verilog；
- Expert GEMM用Vitis HLS生成IP核；
- LayerNorm和残差连接在HLS里实现（因为包含归一化和低精度补偿，HLS开发快）；
- AXI-DMA接口用Xilinx官方IP。
这种混合设计的优势在于，把HLS的快速开发优势和Verilog的精确控制优势结合起来，整体开发效率最高。我在Xilinx KV260上做过端到端验证，完整的Moe推理链路从DDR到DDR延迟在微秒级，单batch的吞吐量在几千token/s量级，算不上快，但作为边缘侧低功耗方案和算法验证平台，已经完全够用。
6. 从算法到FPGA之间，容易被忽略的数值精度问题
6.1 激活函数的定点化
MoE里的激活函数（通常是ReLU或GELU）定点化很简单，ReLU只要判断符号位，GELU可以用查表和一次多项式拟合。但我漏掉过一个关键点：GELU内部是一个正态分布的CDF，输入范围不同，拟合精度差距巨大。后来我统计了实际输入分布，在-4到4的范围里分段拟合，精度才到一个可以接受的水平。
6.2 算子融合省显存和带宽
FPGA带宽是大问题，所以能融合的算子一定要融合。典型的融合方式是：Expert FFN的输出不落DDR，直接在片上完成加权合并、残差连接、LayerNorm，然后才写回DDR。这样本来五个独立算子的写回读入就变成了一次写回，对DDR带宽的占用能减少一半以上。
我在实现时把LayerNorm的均值、方差计算也并行化，分成前半个周期算统计量，后半个周期做归一化。虽然流水线看起来复杂一些，但换来的是外部访存次数大幅下降，这是FPGA实现里值得花时间做的重点优化。
7. 这块内容后续还能怎么扩展
Moe和FPGA的组合，说到底是在“模型稀疏化”和“硬件定制化”之间找交集。如果你想继续深挖，几个方向可以参考。
一个是量化Moe。Moe专家数量多，不同专家对量化的敏感度差异很大，有些专家甚至可以压到INT4而不掉点，有些必须保留FP16。FPGA上可以按专家粒度选择不同的量化精度，这种混合精度的灵活切换，GPU做起来反而复杂，FPGA因为一切都是定制的，反而更容易实现。
另一个是动态专家加载。结合系统运行时的热度统计，FPGA可以动态判断哪些专家该常驻片上，哪些该放在DDR里按需加载。这种与运行状态耦合的调度策略，比起静态摆放能进一步减少带宽压力。
还有就是把MoE子模块和CNN、传统信号处理（比如卡尔曼滤波、图像处理）放在同一个FPGA里做多任务流水线，这个场景我最近也在调研。Moe路由本质上是一个高维特征选择器，和FPGA里的自适应滤波、通道选择有很多可类比的地方，未来做端侧多模态融合或许是个不错的方向。
最后再分享一个小技巧：在FPGA上联调Moe时，尽量准备一个“软件黄金参考模型”。用Python或者PyTorch把整个Moe前向过程固定下来，每一步都保存中间输出，硬件开发时就拿这些中间输出逐层对齐。不要等整条链路全部做完再对，到时候出了问题根本不知道是哪一层引入的误差。逐层对比虽然繁琐，但是调试效率反而最高，这是我踩过几次坑之后最有体会的一点。
