企业官网建设流程全解析

用FPGA跑MoE模型，很多人第一反应是“疯了”：MoE不是大模型里的东西吗，跟FPGA这种嵌入式硬件有什么关系？但真把这两件事摆在一起想，其实比表面上看起来合理得多。MoE的核心是稀疏激活——一个几百B参数的大模型，每次推理只用其中一小部分专家网络；而FPGA擅长的是按需定制计算路径、低延迟、高能效，天生就适合“只算该算的”这种场景。

这篇文章我会从MoE模型的基本原理讲起，再重点拆解它在FPGA上落地的架构思路、资源估算、关键模块实现和工程化时经常踩的坑。内容主要面向两类人：一类是做FPGA开发、想了解大模型推理怎么往异构硬件上迁移的工程师；另一类是算法出身、想搞明白MoE这类模型在实际部署时有哪些硬件约束的研究者。两者不需要互相精通，但看完这篇，至少能明白对方在说什么。

1. MoE模型核心概念拆解

1.1 什么是混合专家模型

MoE全称Mixture of Experts，直译是“混合专家”。理解它的最好方式，是拿一家公司做类比：AI模型可以看作一个公司，传统Transformer这类稠密模型相当于“每个员工都全能”，不管来什么任务，所有人一起上；而MoE模型则是“前端客服先判断你是什么问题，再把请求转给对应的专业团队”。

放到模型结构里，这个“前端客服”叫路由网络（Router或Gating Network），“专业团队”叫专家网络（Expert）。输入一个token，路由网络先算出这个token和每个专家的匹配分数，挑出得分最高的K个专家，然后把token扔给这几个专家计算，最后把专家输出按权重合并。这里的K通常取1或2，对应我们常说的Top-1或Top-2路由。

这种结构带来的直接好处是：模型的总参数量可以做得非常庞大，比如几百甚至上千亿，因为专家多了，参数就多了；但每个token实际参与计算的只是其中一小部分专家，计算量并没有随参数量线性增长。这就是MoE一直被人津津乐道的“稀疏激活”。

1.2 路由网络和专家网络各自扮演什么角色

专家网络本质上就是一个前馈网络（FFN），通常由两个线性层加一个激活函数组成。不同之处在于，MoE里有很多个这样的FFN，它们的参数互不相同，各自擅长处理某一类输入模式。比如在语言模型里，有的专家可能对代码更敏感，有的对数学推理更擅长，有的对闲聊文本更友好——这些“擅长”不是人为指定的，而是训练中自动分化出来的。

路由网络则是一个规模小得多的线性层，输入是token的隐藏层特征，输出是每个专家的得分向量。它的关键点在于“选人”：让哪些专家干活。训练时路由网络和专家网络一起端到端优化，同时会加上负载均衡损失，避免“所有人都挤到同一个专家”这种退化情况。实际做部署时，路由网络虽然计算量很小，但它的精度直接决定了被选中的专家合不合适，对最终输出质量影响极大。

1.3 MoE和稠密模型的核心差异

从硬件角度看，MoE和稠密模型最大的差异体现在“参数访问方式”上。

稠密模型推理时，每一层都要把全部参数读出来算一遍，计算量和参数量强相关。MoE模型虽然总参数量大，但每个token只需要访问其中一小部分专家权重，理论上IO压力和计算压力都会低于同等参数量的稠密模型。这听起来很美好，但实际落地有一个前提：你得知道每个token该访问哪些专家。这个“知道”的过程带来的是动态访存和数据依赖，而动态特性恰恰是FPGA这类并行硬件最不擅长处理的。

再一个差异是显存/存储带宽的压力分布。稠密模型是“均匀地把所有参数过一遍”，访存模式规整，适合GPU这种宽带并行的架构；MoE模型的访存则是“稀疏的、跳跃的”，不同token走的专家路径不同，对存储系统的随机访问能力和调度能力提出了更高要求。这也是为什么MoE在GPU上做推理时，经常遇到负载不均衡、专家热点问题。

2. FPGA凭什么能和MoE放到一起聊

2.1 FPGA擅长什么，不擅长什么

FPGA的本质是可编程逻辑阵列，它的优势有三个：一是并行度可定制，你可以把电路设计成“专门为这个算子服务”的样子，而不是像CPU那样取指译码执行一条条指令；二是时延低且可预测，没有操作系统调度、没有cache miss，实时性可以做到非常精细；三是接口灵活，PCIe、以太网、LVDS、FMC这些接口在FPGA上都可以随意配置，很适合做系统集成。

但FPGA也有明显短板。首先，逻辑资源和片上存储非常有限，一块中端FPGA的BRAM容量可能只有几MB到几十MB，和GPU动辄几十GB的显存完全不在一个量级。其次，FPGA的算力天花板相对GPU来说低很多，尤其是在浮点运算上，DSP资源数量在那里摆着，想做高吞吐大算力场景会很吃力。第三，开发周期长，RTL设计、仿真、时序收敛这一套流程下来，比写CUDA或者Python慢太多了。

所以，FPGA最适合的不是“大而全”的通用大模型训练推理，而是“专而精”的特定场景加速。常见案例包括：数据采集链路上的实时信号处理、低延迟交易系统、工业控制的确定性计算、边缘设备的低功耗AI推理。在这些场景里，模型规模通常不会太大，但实时性和功耗要求很苛刻。

2.2 MoE的稀疏性与FPGA“按需计算”的契合点

MoE模型天然适合FPGA的原因在于稀疏激活。GPU做MoE推理时要面临一个问题：虽然每个token只用了部分专家，但显存里还是得装着全部专家参数，计算单元也经常要为“不知道哪个专家会被选中”而提前准备好所有可能的分支。FPGA则不然，它可以从硬件层面做“按专家定制”：专家1和专家2在底层硬件上就是两套独立电路，或者一个可重构执行单元，被路由选中才真正启动计算。这种“用到哪块算哪块”的模式，能把MoE的稀疏性真正转化为实际能效收益。

另一个契合点是低批量推理。MoE模型在GPU上跑高吞吐批量推理时效率不错，但如果是单条数据、低延迟请求，GPU的利用率反而上不来。FPGA在负载很轻的时候也不会浪费太多功耗，这对边缘场景、嵌入式设备来说很友好。你不需要一个几百瓦的GPU卡插在工控机里，一片几十瓦的FPGA就能完成任务。

2.3 现实场景里谁会把MoE跑在FPGA上

结合最近热词里频繁出现的“FPGA图像处理”“卡尔曼滤波 FPGA”“FPGA信号发生器”“STM32H743和FPGA实现FMC通信”这些内容，可以看出来，FPGA开发者平时接触的更多还是信号采集、传感器数据处理、电机控制这些实时性要求很高的场景。

假设你有一条工业检测流水线，FPGA负责前端的图像采集和预处理，输出的是每个区域的特征向量。这时，如果你希望直接在本地跑一个小型MoE模型来判断“这个产品属于哪种瑕疵类型”，让FPGA顺带把这个推理做掉，就完全不需要再专门配一个GPU盒子。数据不用搬来搬去，时延可以控制在微秒到毫秒级，而且整个系统的功耗预算还在可控范围内。

这种“数据采集端直接附带轻量智能推理”的模式，我认为是FPGA和MoE结合最现实也最有价值的应用方向。它不是要替代GPU去跑几百B的大模型，而是把大模型蒸馏出的小型MoE网络，部署到原本就在现场的FPGA上，让系统具备模型级智能，而不是简单的阈值判断。

3. 在FPGA上实现MoE的整体架构设计

3.1 系统级模块划分

真正动手做RTL之前，先要把整体框图画清楚。一个典型的FPGA MoE推理系统，可以拆成以下六个模块。

• 接口与数据分发模块：负责接收输入token的特征向量，以及和上位机或传感器系统的握手通信。接口形式可以是AXI4-Lite、UART、PCIe或者以太网，取决于整体系统架构。
• 路由计算引擎：输入是token特征向量，输出是TopK个专家编号和路由权重。这个模块计算量小但逻辑复杂，因为TopK选择是数据相关的。
• 专家调度与分发模块：根据路由结果，把token映射到对应的专家执行单元。这是整个设计中调度复杂度最高的地方，要处理负载不均衡、存储bank冲突、专家执行顺序等问题。
• 专家执行阵列：一组可执行FFN计算的处理单元。实现时有两种思路：一种是为每个专家分配独立的硬件电路，简单粗暴但资源消耗大；另一种是复用少量执行单元，每个专家被选中时再加载对应权重，资源省不少但需要处理好加载延迟。
• 权重存储与访存控制器：管理专家权重的存储访问。一般专家权重放在外部DDR中，片上BRAM/URAM作为缓存。访存控制器的设计直接影响整个系统的实际吞吐。
• 控制与状态寄存器：负责整个流程的状态切换、中断处理、调试接口。工程化部署时，这部分看似不起眼，但往往是调试效率的分水岭。

3.2 数据流全景

整个推理流程可以描述为以下步骤。

输入token的隐藏层向量进入路由计算引擎后，路由矩阵和向量做一次矩阵乘法，得到专家打分向量。这个打分向量经过TopK选择，产生K个专家编号以及对应的路由权重。接着，Token和路由信息一起被送往专家调度模块，调度模块依据专家编号，从DDR中加载对应专家权重，并在专家执行阵列中完成该专家的FFN计算。每一个被选中的专家都会算出一个输出向量，最后按照路由权重做加权求和，得到这个MoE层的最终输出。

如果模型有多个MoE层，那么上一层的输出会作为下一层的输入，重复上述过程。实际实现时，流水线的级数会很长，需要非常仔细地处理各模块间的握手信号和反压机制。

3.3 架构取舍：三种方案对比

决定架构风格之前，建议先想清楚自己的约束是资源、吞吐还是时延。下面是三类常见方案。

第一种方案是“每个专家独立电路”。为每一个专家都生成一套完整的FFN计算电路，路由结果直接通过多路选择器选中对应电路的输出。优点是控制简单、时延低，专家之间天然并行；缺点是专家一多，逻辑资源就爆炸。如果只有几个专家且模型不大，这种方案最省心。

第二种方案是“共享执行单元+按需加载权重”。整个系统只设计一个或少数几个FFN执行单元，所有专家共用同一套硬件，区别只是运行时加载不同的权重。优点是资源占用大幅降低，扩展性好，可以支持几十上百个专家；缺点是执行单元空闲等待权重加载的时间会出现性能空洞，时序控制也复杂不少。绝大多数有实际需求的项目，最终都会落到这种方案上。

第三种方案是“部分专家固定硬件+其余共享”。把访问频率高的热点专家做成独立电路，冷门专家走共享执行单元。这是前两种方案的折中，性能比较好，但设计复杂度也最高，一般项目不太建议一开始就上这个复杂度。

实际项目里，我建议先按第二种方案起步，跑通整个数据通路之后，再根据资源余量决定是不是要优化。一上来就追求极致并行，大概率会在时序收敛阶段消耗掉大量时间，反而拖慢项目进度。

4. 核心模块的FPGA实现细节

4.1 路由计算引擎：矩阵乘法和TopK实现

路由网络的计算本质就是一个矩阵向量乘，具体形式为：score = W_r * x，其中W_r是一个[E, H]的矩阵，E是专家数量，H是隐藏层维度。E通常从8到128不等，H从128到1024不等，所以这个矩阵的尺寸并不大，FPGA完全可以直接承接。

实现上有一个容易忽略的点：路由矩阵W_r的精度。路由网络输出的是各个专家之间的相对得分，选专家时看的是排序而不是绝对值，因此它对量化误差比专家网络更敏感。如果整个模型做INT8量化，路由网络建议仍然保留FP16甚至FP32精度，否则某个专家的得分差一个小数点，TopK选出来的专家就可能完全不同，模型输出质量会急剧下降。这一点在很多公开的FPGA部署文章里都不会明说，但实际踩过坑的人才会反复强调。

TopK的实现方式也分几种。如果K=1，那就是一个简单的找最大值问题，用比较树就可以搞定，逻辑很省；如果K=2或更大，可以用迭代法：第一轮找出最大值，第二轮在排除第一个最大值的情况下再找最大值，或者用一个排序网络输出前K个。专家数量不大时，排序网络的性价比反而更高，因为它在固定时钟周期内输出结果，时序更容易收敛。

4.2 专家分发与动态调度：稀疏激活的工程代价

MoE在FPGA上实现时最麻烦的不是计算，而是分发。因为路由结果是数据相关的，每个token选中的专家都不一样，这会导致两个问题：一是专家负载不均衡，某个专家可能频繁被选中，其他专家却闲着；二是存储访问不连续，不同专家在DDR中的地址不同，按专家加载权重就变成了随机访问。

工程上常用的解决办法有几个。首先是在计算单元前加一个“任务缓冲队列”，每个专家对应一个队列，路由模块把token按专家编号分发到不同队列里。这样即使某个token选了冷门专家，也不影响热门专家的流水线继续跑。其次是采用双缓冲机制：执行单元在处理当前token时，内存控制器提前把下一个token对应专家的权重加载到片上缓存，把加载延迟藏在计算后面。

如果是专家数量比较多、负载波动很大的场景，还可以做动态批处理：积累多个token之后统一调度，把选了同一专家的token打包成一个小批次一起计算。这样虽然单个token的时延会变高，但整体吞吐能大幅提升。至于批处理窗口设多大，需要依据实际流量模型来调，没有一个固定最优值。

4.3 专家FFN计算单元的算子实现

专家网络通常是两层线性层加激活函数的结构。以最典型的配置为例：输入维度H，中间维度4H，输出维度H，激活函数为SiLU或GELU。线性层的实现核心是矩阵乘法，在FPGA上一般用DSP48E1/E2构建乘累加阵列。

实现时需要特别注意权重排布方式。数据在DDR里存成行主序还是列主序，直接决定DMA读取时能不能连续突发，也决定片上是否需要做转置缓冲。如果直接用深度学习框架里导出的权重顺序，往往不是硬件友好的排列方式，最好在导权重的时候或者在板卡启动阶段做一个重排，把权重整理成“每次计算需要用到的数据在内存上尽量连续”的布局。

激活函数方面，SiLU和GELU实现起来有个共性：都有指数运算，而FPGA不擅长直接算exp。标准做法是分段线性近似或者查找表。查找表精度高但占BRAM，分段线性实现省资源精度略降，需要根据量化方案做取舍。如果是INT8量化推理，激活函数对精度的影响通常比线性层小，用LUT+线性插值组合的方式基本够用。

4.4 权重存储和外置DDR的访存设计

当专家数量超过一定规模，即使权重量化成INT8，片上BRAM/URAM也装不下，必须把专家权重放到外部DDR里。访存设计的核心目标是让DDR的读写尽量少“断流”，也就是保持突发连续性和高队列深度。

具体来说，DDR的随机访问效率极低，而按专家加载权重天然是随机访问。缓解手段是权重预取和缓存复用。可以在片上开辟一块“专家权重缓存”，每次按专家Id缓存最近用过的权重，下次如果还选同一专家就直接命中缓存，避免再次读DDR。热点专家命中率高，冷门专家miss率高，但整体下来能省掉相当一部分DDR带宽。

有一个实用的细节：把专家的权重在DDR里按固定大小对齐到突发长度。比如DDR突发长度是16个64bit字，那就把每个专家的权重存储空间补齐到这个长度的整数倍。这样每次加载都能用满DDR的突发传输能力，实测下来带宽利用率和不对齐的情况相比能差出一大截。这个问题在做硬件系统联调时特别容易踩坑，DDR控制器本身没问题，但代码里地址不按突发对齐，读有效信号频繁拉低，性能就会异常难看。

4.5 流水线、握手和反压机制

MoE推理过程有多个阶段：路由计算、专家分发、权重加载、FFN计算、结果合并。这些阶段天然适合深度流水线，但流水线设计最怕的就是“中间某一段突然停住”。比如权重加载因为DDR带宽不够多等了几拍，后面的FFN计算单元就会空转，上游的路由模块也不会被阻塞，于是缓冲逐渐积累，最后溢出。

工程上的解法是给每一级之间加上FIFO和反压信号。上游只有在下游FIFO未满的时候才能写入数据；当下游处理不过来时，反压信号逐级向上传递。这会让流水线整体速度降低，但能保证数据不丢、系统稳定。FPGA开发的黄金法则是：先把功能做对，再考虑性能；时序乱飞的流水线，吞吐再高也是虚的。

5. 资源评估与存储带宽的工程估算

5.1 一个具体例子的手算过程

讨论任何硬件实现，都要先算资源账。我以一个中小规模的MoE层为例来做估算。假设隐藏层维度H=512，专家数量E=8，每个token选择Top-2专家，专家FFN中间维度为1024，权重全部量化成INT8。

先看存储需求。每个专家FFN包含两个线性层，第一层的权重矩阵维度是512x1024，参数约52.4万；第二层是1024x512，参数同样约52.4万。两层合计约105万参数，每个参数INT8占1字节，所以一个专家的权重约1MB。8个专家合计约8MB。路由矩阵W_r的维度是8x512，约0.4万参数，可以忽略不计。8MB的量级，中高端FPGA的URAM勉强能放下，但其他逻辑资源会被压缩得很难受，所以实际设计时通常会选择外挂DDR存放专家权重，片上只保留当前正在工作的专家权重缓存。

再看计算量。单个token经过一个专家需要完成两次矩阵乘法：第一次是512维输入乘512x1024矩阵，需要52.4万次乘加；第二次是1024维中间结果乘1024x512矩阵，同样是52.4万次乘加。一个专家总共约105万次乘加。由于选Top-2专家，单个token在这个MoE层内的乘加总量约210万次。如果目标时延是100微秒，那需要的算力约等于21 GOPS，也就是每秒210亿次乘加。这个数字对于FPGA来说有点紧，但对于小批量、低时延场景，配合DSP复用和数据流水，是可以做到的。

5.2 片上资源和DSP数量怎么估算

一个实用的估算方法是：看单次乘加需要几个DSP，再乘上并行度。Xilinx 7系列的一个DSP48E1每个时钟周期可以做一次25x18位乘法并累加，INT8乘法完全可以映射到DSP48E1上。

假设系统时钟跑200MHz，你要在100微秒内完成210万次乘加，平均每秒需要21 GOPS，即每个周期（5纳秒）需要完成大约105次乘加。也就是说，你的DSP阵列至少要有105个DSP48E1同时在干活。这听起来不多，但考虑到还有路由计算、其他辅助逻辑、DDR带宽限制，实际的DSP用量建议留出1.5到2倍裕量，也就是150到200个DSP48E1左右。这个规模在主流中端FPGA上完全可以承受，但如果你并行度设计得太高，资源不够用，那就只能降低时钟频率或者减少并行度。

BRAM/URAM的估算相对简单：片上缓存的总容量，至少要能装下“当前正在计算的专家权重+下一批即将计算的专家权重”，也就是双缓冲的两份专家权重。按上面例子，一个专家权重1MB，双缓冲就是2MB。如果还要缓存激活值、路由矩阵、中间结果，总片上存储预算建议按3到4MB规划。这个量级在UltraScale系列里比较从容，在7系列上则要精打细算。

5.3 从热词看FPGA开发者真正关心的落地问题

最近一圈搜索热词里，有很多是和这个主题高度相关的周边工程问题。比如“stm32h743和fpga实现fmc通信”说明很多FPGA项目是作为SoC的外设加速器存在的；“fpga pcie rc例子”“fpga pcie教程”说明和上位机通信是部署绕不开的坎；“fpga时序约束”“fpga资源评估”说明做完RTL之后还有一轮艰苦的物理设计；而“fpga控制ddr导致ddr的读有效信号一直为低”则暴露了访存系统调试的真实痛点。

这些词串在一起，其实勾勒出了一个完整的FPGA工程链路：接口通信、DDR访存、时序收敛、资源规划。MoE推理算法本身只占其中一部分，剩下的大量时间，都会耗在这些外围系统的调试和优化上。如果只看算法不看工程链路，项目大概率会在联调阶段卡住。

所以我一直建议，做这类项目之前一定要留足“工程系数”：算法设计只占三成功力，接口联调、存储优化、时序收敛至少要占七成。资源评估必须在动手写RTL之前就做，而且要做得保守，否则到了布局布线阶段再发现资源不够，改动成本就非常高了。

6. 从PyTorch模型到FPGA的部署链路

6.1 模型导出和权重预处理的常见流程

FPGA上没有任何一个通用的深度学习框架可以直接加载PyTorch模型，你需要把模型里的参数和计算图“翻译”成RTL能理解的形式。实际做的时候流程大体如下。

第一，用PyTorch或训练框架把已经训练好的MoE模型导出，保存权重和模型结构。第二步，写一个Python脚本分析模型结构，把路由矩阵、专家权重分别抽取出来，并按FPGA访存友好的格式重新排列。第三步，对模型做量化校准。建议用校准数据集先跑一遍，统计各张量的数值范围，算出每个张量的缩放因子，再把浮点权重转成INT8。第四步，把量化后的权重生成COE文件或者二进制bin文件，烧录进DDR初始化文件。第五步，在FPGA里实现推理流程，并用仿真工具逐层比对硬件输出和软件参考输出，确保每个模块的计算精度在误差允许范围内。

这里面最容易出问题的是“软件硬件数值不一致”。FPGA上做INT8乘加，如果累加器的位宽不够，高位溢出后的结果和Python里的浮点参考差异会非常大。经验是把累加器的位宽至少留到“输入位宽+权重位宽+log2(累加个数)+2”，这样基本不会出溢出问题。

6.2 上位机通信和系统集成怎么选型

FPGA跑MoE模型，很少是独立工作的，总要和CPU、传感器或者上位机软件配合。通信接口的选择，取决于数据量大小、时延要求、开发复杂度。

如果你的MoE模型只是作为一个小型分类器，特征是几百维浮点向量，输入输出数据量不大，用AXI-Lite加中断就够了，通过SoC的CPU核做控制，非常省资源。如果数据是通过传感器实时采集、FPGA要连续处理大量特征的，那就要考虑AXI-Stream或者DMA方式，让数据以流式方式灌入推理IP，尽量避免CPU对每个token的打扰。如果特征是CPU/DSP那边算好通过PCIe送过来的，那就走PCIe的DMA通道，这个方案吞吐最高，但开发周期也最长，光是PCIe链路和DMA驱动的调试就能花掉不少时间。

还有一个容易忽略的细节：接口时钟域和推理逻辑时钟域通常是异步的，跨时钟域的信号必须做同步处理。很多一开始功能正常、跑几天偶尔出错的问题，最后追查下来都是跨时钟域没有处理好。这种问题最难复现也最难调试，建议在一开始设计时就严格遵守同步器规范，不要图省事直接用裸信号跨时钟域。

6.3 量化策略对MoE的特殊要求

MoE模型的量化比普通Transformer更要注意路由网络和专家网络的差异性。

路由网络的输出决定了选哪个专家，选错专家是灾难性的，比权重精度损失几个百分点严重得多。因此量化路由网络时要格外保守：可以不做量化，直接保留FP16；即使做INT8，也要用更多的校准数据把数值范围统计准，尽量不要用简单的min-max方法，改用百分位截断效果更稳。

专家网络对量化的容忍度相对高一些，但不同专家之间的数值分布差异很大，有的专家输出范围大，有的专家输出范围小，采用全局统一的INT8缩放因子会同时损伤害热专家和冷门专家。更好的方案是每个专家单独统计数值范围、单独设置缩放因子。这样做会增加部署时的一点存储开销，但换来的是明显的精度收益。

6.4 调试手段：仿真、ILA和软硬件对比

FPGA开发的调试链路非常依赖工具链。我的习惯是分成三个递进阶段。

第一阶段是纯功能仿真，用Vivado的仿真器跑RTL，测试向量从PyTorch参考实现里导出。如果这个阶段都不能做到逐bit对齐，就不要急着上板。第二阶段是上板后用ILA抓内部信号，重点看路由选出的专家编号、FIFO的空满状态、DDR读数据是否按预期时序到达。第三阶段是系统联调，把FPGA推理结果和上位机软件结果做批量对比，统计错误率。

一个非常实用的经验是：在RTL里加一个“调试旁路模式”，可以把路由模块算出来的专家编号和权重值直接通过UART或者JTAG导出，用脚本和PyTorch输出做对比。这样定位问题会快很多，不用每次都在波形里翻来翻去找。

7. 常见问题与工程化解法

7.1 专家一多，BRAM/URAM就爆了怎么办

这个问题几乎是所有MoE-FPGA项目的必经之路。片上的BRAM/URAM总量是固定的，专家数量翻倍，片上容量不可能跟着翻倍。解法一般有三个方向。第一个方向是把专家权重全部放到外部DDR，片上只做小容量缓存，这是最彻底的办法。第二个方向是压缩权重位宽，从INT8压到INT4，存储需求直接减半，精度损失需要实测评估，很多场景下是可控的。第三个方向是减少同时缓存的专家数量，只缓存最近频繁使用的几个热点专家，冷门专家现用现加载。

如果项目允许，我强烈建议从一开始就把“外置DDR为主、片上缓存为辅”作为默认架构，不要指望大型MoE模型能全部塞进片上存储。提前规划存储架构，比后期推倒重来节省太多时间。

7.2 路由结果发散导致负载不均衡

MoE推理时，某些专家会被频繁选中，另一些专家几乎闲置，这是稀疏激活的自然结果。在GPU上这个问题会导致部分GPU利用率低下，在FPGA上则会表现为某个专家执行单元忙不过来，其他单元空转。

工程上的对策是加一层“输出缓冲+再调度”。让路由分发的token先进入一个缓冲池，调度器再根据各执行单元的当前负载做动态分配。这个调度器需要收集每个执行单元的忙闲状态，用简单的优先级仲裁或者轮询策略就可以，不必做得很复杂。关键是要把“路由选择专家”和“硬件执行专家”解耦，让硬件的执行计划不完全受限于路由结果的瞬时波动。

另一个办法是“专家复制”：把热门的专家复制一份甚至多份，分别放在不同的执行单元上。这样即使路由大量命中同一个专家，多个执行单元也能分摊负载。代价是额外的存储资源和权重存储空间，但工程上效果很直接。

7.3 DDR读有效信号一直拉低，根本原因是什么

这是个在热词里反复被搜索的问题，说明踩的人很多。“fpga控制ddr导致ddr的读有效信号一直为低”这个现象，大多数时候并不是DDR控制器坏了，而是你发出的读请求本身效率太低，DDR控制器无活可干。

典型原因有三个。第一，读地址不连续，每次只读几个字就跳到另一个地址，DDR的突发传输根本用不上，效率极低。第二，请求队列深度太浅，DDR刚刚被唤醒准备传输，结果请求已经空了，总线只能一直等待。第三，没有做好预取，片上缓存只要miss就直接等DDR回数据，没有任何提前加载机制。解决思路是：地址对齐到突发长度、增加请求队列深度、用双缓冲做预取。这三个方向做好了，DDR读有效信号基本能稳定在高电平。

7.4 时序收敛困难怎么办

MoE推理的数据通路长，流水线级数多，时序收敛往往是后期最耗时的阶段。最常见的时序违例出现在两个位置：一是专家分发模块的交叉开关逻辑，因为扇出太大导致布线延迟超标；二是DDR读数据回来之后跨时钟域的同步逻辑。

针对第一个问题，可以在交叉开关前插入多级流水寄存器，把大扇出拆成多级树形结构，让每个逻辑门的扇出变小。针对第二个问题，要严格使用异步FIFO或者两级同步器，并且确保同步器的两级寄存器布局在同一个slice里，减少布线延迟。时序收敛没有银弹，就是反复看critical path报告，逐条优化，直到所有路径满足约束。做这一步的时候，保持耐心比能力更重要。

8. 写在最后的几点个人体会

这篇文章写到后面，其实已经超出“简略分析”的范畴了。但我觉得MoE加FPGA这个组合，值得展开的地方还有很多，因为真正动手做的人太少了，公开的资料要么只讲MoE算法不讲硬件，要么只讲FPGA基础不讲模型结构，能把两者结合起来的内容少之又少。

我个人实际操作下来的体会是：从算法到硬件这段距离，比想象中要远得多。MoE在纸面上是一个非常漂亮的稀疏激活方案，参数量大、计算量小、效果还好；但落到FPGA上，“稀疏”这两个字带来的动态调度、存储随机访问、负载不均衡，才是整个项目真正的难点。如果你在软件里跑MoE推理觉得顺风顺水，那只是因为你没有被迫面对“计算单元必须被高效利用”这个硬约束。

最后再分享一个建议：如果准备在FPGA上做MoE，不要一上来就挑战几十个专家的大模型，先从两三个专家的小规模模型开始，把路由、分发、加载、计算这条完整链路跑通，再逐步扩大专家数量。这个路径看上去绕了远路，实际上是最快抵达终点的方式。毕竟，FPGA项目里最贵的资源不是LUT也不是DSP，而是你的调试时间。