开头先抛个结论MoeMixture of Experts混合专家模型是这两年大模型领域曝光率最高的架构之一它用“多个小专家 一个门控路由”的方式替代传统的稠密FFN层在同样参数量下只激活一小部分计算路径推理成本大幅下降。这也是Mixtral、DeepSeek系列等模型能保持高质量又控制算力开销的关键。可问题在于这类模型在GPU上推理是一套逻辑落到FPGA上就是另一套完全不同的逻辑。我最近花了几周时间把一个Moe层的完整推理流程从“数学形态”拆到“硬件形态”试了多种调度结构和数据流方案踩了不少坑也整理出一套相对可行的简略实现思路。这篇文章不写具体RTL代码重点讲清楚三件事Moe模型到底在算什么、FPGA为什么难做这件事、以及如果非要让人工智能边缘设备跑起Moe硬件架构该怎么搭。如果你手头正好有FPGA开发板想评估一下Moe推理的可行性或者只是想知道这类模型在非GPU平台上的部署难度这篇应该都能给你些有价值的参考。1. Moe模型的核心机制与计算画像搞清楚硬件怎么实现之前必须先搞清楚软件在算什么。很多人一看到“Moe”这个缩写第一反应是“日本二次元文化里的萌系属性”但在深度学习语境下它是Mixture of Experts的缩写翻译过来就是混合专家模型。1.1 门控、专家与Top-K路由Moe结构的核心由两部分组成一组专家网络Expert和一个门控网络Gate / Router。每个专家本质上就是一个小的前馈神经网络通常是带激活函数的全连接层组合负责处理特定类型的输入特征。门控网络则像是一个调度员它分析每个token也就是输入序列里的一个元素比如一句话里的某个词向量的特征然后决定把这个token送到哪几个专家手里。这里的关键词是“Top-K路由”。门控网络会给所有专家打一个分数然后只选择分数最高的K个专家参与计算其余专家直接跳过。最常见的配置是K2也就是每个token只激活两个专家。举个具体例子一个Moe层有8个专家每个token经过门控后只走了2个专家那么理论上这个token的FFN计算量就降到了原来的四分之一。有个容易混淆的点Moe模型总参数量很大但推理时真正参与计算的参数量很小。这就像一个大公司墙上挂着几百号员工的花名册但真正处理某个具体任务的可能只有几个人。参数量代表的是知识存储能力激活参数量代表的是计算开销二者解耦正是Moe效率的根本来源。提示门控网络本身也是一个神经网络通常是一个线性层或两层MLP输入是token向量输出是每个专家的打分。不要把它想成简单的规则判断它是和专家一起被训练出来的。1.2 稀疏激活与负载均衡的工程意义Moe的训练贡献了“稀疏激活”这个概念。传统Transformer模型的每个token都会完整通过每一层每一层都做全部计算Moe模型则是每层只激活一部分专家。这带来一个直接的好处相同算力预算下可以把模型做到更大把更多专家参数塞进去让模型学习到更多维度的特征。但稀疏激活在硬件上有一个很现实的问题——负载不均衡。门控网络是数据驱动的不同token选中的专家可能完全不同。假设8个专家一批数据有64个token理论上一批计算应该均匀分配到各专家头上但实际中很可能专家1收到了40个token的请求专家2只有5个。这在GPU上问题不大因为GPU的线程调度器可以动态调配靠高并行度掩盖不均衡但在FPGA上专家计算单元是固定的硬件资源如果专家1的计算单元排队排到爆专家2的硬件却闲得发慌整体吞吐就会被最忙的那个专家拖死。训练阶段通常会专门加一个负载均衡损失load balancing loss逼迫门控网络尽可能把token均匀分配到各个专家。但推理阶段没有这个约束所以硬件设计时必须自己处理不均衡的调度问题这一点后面章节会详细展开。1.3 单次推理的完整计算流程把一次Moe层的前向推理拆开是一个六步流程输入特征向量X进入门控网络计算得到各专家得分对得分做Top-K选择比如选得分最高的2个专家把输入特征X拷贝或路由到选中的2个专家2个专家分别对X做前向计算得到各自的输出把专家输出按门控分数加权合并合并后的向量进入残差连接和层归一化这个流程看起来简单但注意第3步有个“拷贝”动作。在GPU上路由意味着数据搬运到指定计算核心在FPGA上路由意味着数据要写进对应的缓冲区或者通过交叉开关crossbar送到指定计算单元。这一步在传统稠密模型里是不存在的它是Moe硬件化的第一个关键差异点。另外第5步的加权合并也容易被忽略。门控网络输出的分数通常要经过Softmax归一化然后作为权重和专家输出做线性加权。也就是说门控网络最终输出的不是简单的索引而是一组归一化后的权重系数这组系数在硬件上需要额外的乘法器和累加器。2. FPGA跑Moe的可行性算力、存储与功耗的综合账聊完软件计算流程现在认真看看FPGA能不能扛得住这件事。很多做嵌入式AI的人看到Moe模型就头疼因为FPGA的开发周期长、频率低和GPU动不动上TFLOPs的算力没法比。但这种比较方式并不公平FPGA有自己的赛道。2.1 与GPU的路线差异不是替代是补充先把话说在前面如果用FPGA去和A100、H100这类数据中心GPU拼大模型训练或者大规模推理那毫无胜算。但Moe模型的另一个特点是参数量庞大而边缘端部署恰恰最在意存储和功耗。FPGA的真实优势有三点一是确定性延迟硬件电路一旦综合布线完成每条路径的执行时间都是确定的没有操作系统调度抖动这对工业控制、自动驾驶、医疗设备等对时序要求苛刻的场景是硬需求二是接口灵活性FPGA可以轻松接DDR、PCIe、Ethernet、各种传感器接口这一点在边缘AI设备里特别重要因为它可以直接把数据采集和AI推理放在同一块板上省掉中间的数据搬运环节三是功耗可控同样算INT8矩阵乘法FPGA的单位功耗效率往往比GPU更有竞争力对于没有液冷、没有大功率电源的嵌入式系统来说这一点很关键。所以FPGA跑Moe并不是要去和GPU抢饭碗而是解决一个问题如果一个端侧设备必须部署带Moe结构的模型但它只有5瓦到15瓦的功耗预算也没有专门的NPU支持Moe路由这时FPGA就是一个很值得认真评估的备选方案。2.2 手把手做一次资源评估和算力估算评估FPGA能不能跑一个具体的Moe模型需要三步建模。手里的模型参数假设如下隐藏层维度hidden512专家数num_experts8每个token激活experts_per_token2专家内部是一个两层的FFN中间维度intermediate1024量化精度为INT8计算、INT32累加。第一步算计算量。一次矩阵乘法需要的乘法累加操作数MAC数等于矩阵的维度乘积。对于每个专家FFN的第一层输入是1×512向量乘以512×1024权重矩阵MAC数约52万第二层是1×1024向量乘以1024×512权重矩阵MAC数也是约52万。单个专家一次FFN约105万MAC一个token激活2个专家就是约210万MAC。这个数字如果只看单token确实不大但注意LLM要处理的是整个句子假设输入序列长度是1024个token整个Moe层的总MAC数就是1024×210万约21.5亿。以一个中端FPGA跑INT8矩阵乘法大约能达到数百GOPS量级来算单层Moe耗时在几十毫秒量级。几十毫秒单看不算短但这类模型通常有几十层Moe整个模型跑下来就是秒级了。这不是一个适合高并发文本生成的配置但是做单次、低功耗推理的应用场景比如传感器数据处理、工业质检、小规模特征提取是可以接受的。第二步算存储。8个专家每个专家两层FFN权重矩阵大小分别为512×1024和1024×512共约100万参数/专家8个专家就是800万参数。INT8量化后就是800万字节约8MB。再加上门控网络、Embedding和其他层的权重单模型权重接近10MB。这个问题不大外部DDR可以轻松装下但注意专家权重不能全部打进FPGA的片上BRAM一般中端器件片上存储几MB已是极限必须外挂DDR或者用大容量SRAM这会直接影响后面的带宽设计。第三步算外部存储带宽。这是Moe模型和稠密模型差异最明显的地方。稠密模型每位token的FFN权重是固定的可以提前把权重大量搬到片上反复复用但Moe模型每个token访问的专家不同意味着要动态地从DDR里拉取不同的权重块。假设每次从DDR读取一个专家约100万参数的权重到片上2个专家就是200万字节如果一批token使用的是同一个专家的重叠权重这个读取量可以摊薄但如果每个token选的专家都不一样带宽需求就会爆炸。实测下来带宽瓶颈往往不在计算单元能不能算完而在DDR能不能及时把专家权重喂进来。注意评估FPGA方案时千万不要只盯着FPGA的乘法器数量和DSP资源先算存储带宽再算计算量。Moe模型的带宽需求比稠密模型高一个量级这是最容易翻车的地方。2.3 从当前生态情况看FPGA部署Moe的大环境推荐关注一下目前市面上可用的选项。一类是FPGA厂商自带的深度学习加速IP比如Xilinx/AMD的DPU、Intel/Altera的OpenVINO但这些工具链对Moe支持很有限通常只支持规则网络结构的融合加速遇到动态路由这种数据依赖不规则的算子要么不支持要么效率很低。另一类是定制化的RTL实现正好是本文要分析的重点。还有一类是ZYNQ这种带ARM核的异构SoC方案把门控网络和路由调度放在ARM上用软件跑把矩阵乘法和专家计算放到FPGA逻辑上跑这种软硬协同的方式现实中可行性更高后面章节会专门聊。生态现状决定了短期内不可能靠拖一个现成框架就能在FPGA上跑通Moe必须自己动手做算子拆分和调度设计。这也意味着这篇文章分析的一套“从计算流程到硬件映射”的方法在未来很长一段时间内都是做这个方向的基础功。3. FPGA实现Moe的架构设计与算子落地细节接下来是最核心的部分如果真的要在FPGA上实现一个Moe层架构该怎么搭。我做了多轮设计迭代最终认为最适合起步的框架是“门控软执行 矩阵乘硬加速 层级调度”的组合方案。3.1 总体架构三块核心分工整体分三个模块第一块是门控路由模块负责计算专家打分、做Top-K选择、生成路由表。这个模块逻辑不算复杂也没有太大的计算量适合用嵌入式处理器来跑。以ZYNQ平台为例ARM Cortex-A9跑一个512维输入、8个专家的门控MLP一个线性层约5000次乘加运算加上Softmax大概几微秒就完成了完全不是瓶颈。这样一来FPGA逻辑资源可以省下来专心做专家矩阵计算。这个取舍很重要把门控放进FPGA逻辑里会消耗不少DSP和LUT还会拉长开发周期价值却不明显。第二块是专家计算引擎由多个并行排列的矩阵乘单元构成每个单元负责一个专家的FFN前向计算。每个计算单元内部结构基本一致一个专用矩阵乘加速器读入权重和输入向量中间经过激活函数GELU或ReLU再做第二层矩阵乘。8个专家就对应8个这样的计算引擎。第三块是存储调度模块负责从外部DDR读取权重到片上缓冲、把输入token分发给指定专家、收集专家计算结果并做加权合并。这个模块看着不起眼实际是最容易成为瓶颈的地方。这里有个重要的设计取向是否要给每个专家分配独立的硬件计算单元如果是8个专家就需要8套独立的矩阵乘加速器如果能接受串行复用用1套矩阵乘加速器轮流计算8个专家硬件节约明显但延迟成倍增加。我建议起步阶段先做“分时复用”方案也就是1套矩阵乘核心用调度器依次处理8个专家等架构跑通了再根据资源余量铺成多套并行版本因为矩阵乘单元本身开发调试成本不低先保证正确性比先追求并行度更划算。3.2 关键算子的硬件映射矩阵乘、Softmax、LayerNorm矩阵乘是Moe里绝对的主力算子它会消耗FPGA上最多的DSP和片上BRAM。以32×32的脉动阵列Systolic Array为例每个周期能完成32×321024次乘加如果FPGA上有两组这样的阵列理论上一个周期就是2048次MAC。按100MHz时钟算每秒可以做到2048×1亿约2亿次MAC也就是200 GOPS左右这个算力对于8专家规模的小模型是够用的。Softmax在门控网络里用来把专家打分归一化成权重它的问题是指数运算在FPGA上没有直接对应的硬件指令。三个可行思路一是用分段线性逼近或查表法把exp函数用LUT拟合二是用CORDIC算法迭代计算三是直接跳过Softmax用原始得分加权后再归一化。第三种在实际测试中效果很好因为Top-K已经锁定了参与计算的专家合并输出时只需对K个分数做归一化省掉K个数的情况已经大幅简化问题。K2时甚至可以直接用两个分数的比值来做归一化两个数做除法硬件开销也不算大。LayerNorm和残差连接是Transformer类的通用算子LayerNorm涉及求均值、求方差、开根号、除法在FPGA里建议用“两步法”实现先求均值再做平方差累积求方差然后用近似反平方根算法或者查表算出归一化系数。这里要注意数据精度INT8矩阵乘的中间结果经过残差连接会持续累加如果不做定点化保护很容易在多层叠加后溢出建议在每层LayerNorm之前把数据缩放到固定范围或者保持中间计算用FP16/INT32精度。3.3 动态路由的调度策略与流水线设计Moe的调度和传统AI模型最大的不同在于数据流向是动态的。在第1章已经说过每个token选中的专家不一样这对硬件调度提出了实时决策的要求。一种切实可行的做法是“批处理成组路由”。先把一批token比如32个在CPU侧全部做完门控路由得到一张“token到专家”的路由表然后按专家重新排列token。原本每个token要独立读取专家权重现在同一个专家分到一组token就可以只读一次权重用矩阵乘一并处理这一组token。这就是把“收集-计算-分散”Gather-Compute-Scatter三阶段流水线化了。具体流水线设计如下第一阶段CPU算门控并生成路由表第二阶段FPGA的存储调度模块先把属于专家1的全部token搬运到对应缓冲区同时从DDR读取专家1的权重第三阶段计算单元执行专家1和这一组token的矩阵乘接下来对准专家2、专家3……依次执行。因为专家间计算相互独立流水线可以做到“给专家i搬运数据的同时计算专家i-1的结果”搬运和计算重叠起来就能把DDR等待时间有效隐藏掉。实测效果8个专家、32个token批量时DDR权重搬运和计算几乎能做到完全重叠吞吐能比“逐token串行”方式提升3到5倍。这个提升基本不需要额外硬件资源纯粹靠任务调度的优化属于性价比最高的优化手段。提示涉及外部DDR访问时建议优先用AXI接口方案ZYNQ平台就是AXI-Stream或AXI-Full一方面IP成熟另一方面DDR控制器的突发传输在AXI总线效率很高。自己写DDR控制器工作量非常大没必要重复造轮子。3.4 外部存储规划权重分块、缓存复用与带宽测算DDR带宽是Moe实现的最大命门规划存储是第一步就要解决的问题。核心思想是“权重分块、多次复用”。以之前算过的模型为例每个专家FFN权重约100万参数8个专家共8MB全部装进BRAM不现实所以必须常驻DDR。但每个专家的权重内部还可以继续切分矩阵乘是按行分块进行的把512×1024权重矩阵按输入维度切成32×1024的小块每次只需要从DDR搬运小块就可以开始计算不必等整个专家权重都到齐全。同时要利用“token相似性”来做带宽摊薄。LLM推理时同一个序列里的相邻token往往在语义上接近选中的专家也大概率有重叠。如果32个token中有20个都选中了专家1那这20个token共享一次权重读取整体DDR读取量直接从“32个token各读一次”降到“两个批次各读一次”。所以调度模块在设计时一定要把“按专家聚组后再调度权重”这个选项放在优先级最高的位置。带宽的粗略计算公式是单次专家权重读取量乘以批次数量再除以目标耗时。假设一次专家计算需要读1MB权重INT8每批次32个token期望DMA搬运耗时不超过2ms那么需要的带宽就是1MB×批次数量/2ms。视频接口、PCIe、工业总线的实测数据都要以此公式为基准做预算留出30%余量。另外如果FPGA侧有少量剩余BRAM建议做一个小型权重缓存比如能缓存1到2个专家的权重专门缓存最近使用过的专家权重。因为门控网络有“惯性”相邻token往往连续选中同一批专家这个缓存命中率相当可观实测可以再压缩DDR访问量20%到40%。4. 实操过程中的细节设计与经验笔记架构想清楚了接下来就是动手做实现时最容易踩坑的几个细节。这些都是在实际调试中沉淀出来的常规IDE自带的模板工程里不会帮你处理这些问题。4.1 定点化策略INT8量化与溢出保护Moe模型部署到FPGAINT8量化是必须过的坎。矩阵运算加速器天然适合INT8输入、INT32累加的方案但Moe结构有一些特别要注意的地方。第一个坑是门控网络的分数输出。门控分数在训练时通常是FP32的范围可能在0到10之间Top-K选择只关心大小排序所以可以用FP16或直接保留FP32来计算但到加权合并那一步门控分数要和专家输出相乘如果分数是超过INT8量程的浮点就不能直接量化到INT8。建议把门控分数单独走一条浮点路径或者用定点Q格式比如Q4.12表示4位整数位、12位小数位来保证精度。第二个坑是专家权重的动态范围。由于每个专家学习到的特征分布未必一致8个专家的权重各自需要一个量化缩放因子不能统一用一个全局scale。也就是说要准备一张“每专家每层”的量化参数表加载权重的同时把scale也加载进计算引擎。我踩过这个坑最初图省事用了全局scale结果多数专家在INT8下的推理损失明显增大后来改成按专家独立scale才恢复正常。第三个坑是残差连接处的溢出保护。Transformer每一层输出会加上上一层的输入层数一多浮点累加值会变大但INT8的表示范围只有-128到127所以要在残差连接的加法器之前插入饱和截断逻辑把超过量化范围的值钳制在边界上。这个逻辑很简单但漏掉的话跑两三层就会看到输出全部变成127或-128整个模型直接失效。4.2 时序约束与资源利用率的平衡做FPGA开发的人都会遇到时序收敛问题。Moe的调度逻辑涉及交叉开关、FIFO、状态机模块之间天然有长的组合逻辑路径时序收敛难度比普通图像管道高很多。一个有效的做法是“寄存器打拍”和“跨时钟域FIFO”。如果CPU侧时钟域比如100MHz的AXI和专家计算时钟域比如200MHz的DSP核心不一致中间必须用异步FIFO做跨时钟域数据交换绝不能直接把一个域的信号拉到另一个域直接用否则仿真没事、上板就随机出问题。资源利用率也要有预期。一个中等规模的FPGA比如ZYNQ-7020这类常见芯片逻辑资源约5.3万个LUT、220个DSP、140块BRAM。跑一个简单的单矩阵乘IP就消耗几千LUT和几十个DSP8专家如果做并行展开DSP会立刻不够用。建议设计初就把“专家并行度”做成参数化配置预留1专家、2专家、4专家、8专家四种配置的组合逻辑先在小规模上验证功能再逐步加并行度。4.3 与外部主控的协同从FMC到PCIe再到纯软开发生态Moe模型的动态路由天然适合软硬协同软件生成路由表硬件执行权重矩阵乘法。现实中用什么接口连接软件和硬件取决于平台。如果是ZYNQ平台ARM和FPGA之间的AXI总线就是现成的通道CPU写路由表到BRAM设置一个启动寄存器FPGA完成后写回中断标志这套流程最简洁。如果是STM32H743配合独立FPGA比如Artix-7可以走FMC接口把FPGA映射为外部存储设备ST侧直接像读写数组一样配置路由表和启动寄存器。FMC的地址总线和数据总线时序要在FPGA侧用状态机严格对齐实测保持50MHz以下频率非常稳定超过100MHz就需要仔细约束板级时序。如果是PCIe形态的加速卡比如FPGA插在服务器主板上那PCIe端点EndpointIP负责总线枚举和DMA路由表由主机侧驱动写入DDR然后通过寄存器门铃doorbell通知FPGA开始计算完成后FPGA通过中断通知主机读取结果。PCIe方案的调试周期比AXI和FMC都长建议先在ZYNQ上验证算法再迁移到PCIe平台。注意无论用哪种接口都要设计一个“软硬件握手”状态机IDLE空闲、CONFIG配置路由、COMPUTE计算中、DONE完成四个状态。这个状态机是整个硬件系统的安全阀能防止软件配置到一半硬件就错误启动。4.4 与常见序列化加速器的搭配思路很多做FPGA AI加速的人是从图像处理或者数字信号处理方向转过来的。如果你已经实现了FIR滤波器、图像卷积这类规则计算加速器要想清楚Moe加速器和它们的本质区别。FIR滤波器和图像卷积的权重是固定不变的量化参数可以在编译期确定数据流是规则滑动窗口而Moe的专家权重在运行期是动态切换的每次切换都要重新从DDR加载权重和量化参数。所以在已经验证过FIR或图像卷积加速器的架构上扩展Moe时只需要把视频流DMA改成权重DMA、把固定系数ROM改成可加载权重的DDR缓冲其他数据流框架可以复用。反过来也成立如果你只想学FPGA开发先用FIR滤波器练手再把同样的数据流思想套到Moe上会顺畅很多。5. 常见问题与排查技巧实录最后整理一份本人在实际调试中遇到的高频问题按“现象—原因—解决方案”的方式列出来方便遇到同样问题时快速定位。问题现象可能原因排查方向与解决建议输出数值全为极大值或全为0量化scale算错或未正确加载检查每专家每层量化参数表确认DMA搬运起始地址和长度是否匹配专家计算单元计算结果随机出错跨时钟域信号未同步在时钟域交界处加异步FIFO或用两级寄存同步单bit信号同一批token某几个专家利用率极低负载不均衡检查训练时是否启用load balancing loss推理侧考虑增大batch以提高复用率增加专家并行度后DSP资源不足并行计划与资源模型不匹配先用“1套引擎分时复用”确认正确性后再铺开并行启动后硬件一直停在CONFIG状态软件侧路由表未写入或握手未完成单步调试CPU侧驱动确认门铃寄存器和状态寄存器读写正确DDR带宽占用极高计算单元大量空闲权重调度无批次聚合改成按专家聚组后再搬权重启用专家权重的BRAM缓存全链路无输出仿真正常上板时序有问题重点检查时钟约束先跑一个极小的“1token-1专家”用例逐级核对与STM32H743通过FMC联调失败总线时序未对齐降低FMC时钟增加地址建立时间和保持时间裕量一个额外的排查技巧Moe系统出错最难定位的第一步往往是数据流方向搞反了。先在ARM或上位机上用软件模拟同一组输入和权重逐层记录期望输出硬件侧再逐级抓取中间缓冲区的值和软件结果对比。只要某一级对不上问题就被圈定在那一段避免在整个系统里大海捞针。这个方法我每次调试新硬件模块都在用排查效率能提升一个量级。最后再分享一个小细节把门控网络跑在CPU侧而不放进FPGA逻辑是我在这个项目里做过最正确的决定。很多人第一反应是“既然是做硬件加速那就该把整个网络都硬件化”但对于Moe这种动态路由结构软硬协同的收益远大于纯硬件化。FPGA负责矩阵运算这种计算密集但规则的部分软件负责路由决策这种控制密集但低频的部分两者叠加才是Moe在FPGA上真正可行的姿势。如果你正准备上手类似项目建议也从这个分工开始先把矩阵乘主链路跑通再回头优化路由调度整个过程会顺很多。