企业官网建设流程全解析

1. MoE架构到底是什么：一个老概念的新辉煌

最近MoE这个缩写出现在技术文章里的频率高得吓人。不管你是做大模型推理的、做端侧部署的、还是做AI芯片的，几乎绕不开这个词。MoE全称Mixture of Experts，翻译过来是“混合专家模型”。它不是一个新概念——早在1991年就被提出过，但真正让它火起来的，是它在当前大语言模型（LLM）上的出色表现。你随便搜一下就能看到Gemma系列里的4B A4B变体、Mixtral 8x7B、DeepSeek这些热门模型，全都采用了MoE架构。

原因其实挺好理解的。传统的大语言模型是“一人扛所有”，一个稠密模型要处理所有输入，每一个token（你可以把它理解成一句话里最小的词元）都要激活全部参数。但MoE的思路换个了方向：把模型拆成很多个“专家”，每个专家是一小组参数，再加上一个“路由器”负责判断当前输入应该交给哪些专家处理。这就是所谓的“稀疏激活”。举个直白的类比：传统模型就像一家所有员工每天都要处理全部业务的公司，MoE则是按照业务类型分好了部门，来什么单子就只让对应部门干活。这样做的直接好处是，在不无限堆参数的前提下，大幅提高模型容量。

这也是为什么我对MoE这个方向特别上心的原因：它不是靠魔法提升模型能力，而是靠“结构化”——让不同参数做不同的事。但这里有个问题。模型层面亮了，硬件层面怎么办？稀疏激活对推理设备和计算架构提出了完全不同于稠密模型的挑战。具体到部署端，GPU凭借CUDA生态和高带宽显存，是当前MoE推理的主要战场。但FPGA呢？FPGA在MoE加速这件事上到底能做些什么、做到什么程度、要付出什么代价？这恰好是本文想聊的核心话题。本文会先把MoE的架构原理拆干净，再从FPGA实现的角度，逐层分析算力、带宽、片上存储和编译工具链上的关键瓶颈以及可行的落地策略。适合对LLM有一定了解、正在考虑把MoE部署到FPGA上做加速的同学，也适合想找个方向理解FPGA在AI时代定位的朋友。

2. MoE模型内部到底发生了什么

2.1 门控网络与专家路由机制

先拆解一下MoE最核心的机制：门控网络，也就是大家常说的Router。你的输入数据会先进入门控网络，这个网络非常轻量——通常就是一个线性层加一个softmax——它的工作就是输出一个概率分布，告诉你“当前这个输入，应该派给哪些专家”。怎么派？最常用的策略是Top-K路由。K通常取1或2。如果是Top-2，那就把概率最高的两个专家找出来，让它们各自干活，再把结果按概率加权合并。

这里有一个很关键的细节：路由的选择对每个token来说是动态的。也就是说，模型在处理一整句话时，不同的词会走不同的专家路径，这就带来了几乎无法静态预测的控制流。放在CPU/GPU上，这个问题还不算致命，因为处理器有很强的分支预测和调度能力。但在FPGA这种偏硬件的实现方式里，动态路由意味着你的数据搬运路径是不能提前完全定死的，这对片上调度逻辑是一个直接的挑战。

再往深看一层，为什么路由是必要的？因为如果不做路由、让所有专家都处理所有输入，那MoE就退化成一个大号的稠密模型，参数全部参与计算，稀疏性消失，MoE所有的架构优势都不存在了。所以，门控网络的价值其实是在“少算”和“算得准”之间做平衡。它还承担了一个隐含作用——负载均衡。如果所有token都流向同一个专家，那其他专家就闲置了，硬件的利用率会变得很难看。于是实际训练中还会加入负载均衡损失来约束路由分布。搞FPGA实现的时候，你写调度逻辑的时候也要对这个机制心里有数。

2.2 专家并行与分布式部署逻辑

MoE在训练和推理时，都不是单一设备能容纳下的（这里指的是大规模场景）。于是有了并行策略。常见的三种并行方式：数据并行、张量并行、专家并行。

数据并行好理解：多张卡都放一个完整的模型副本，各处理一批数据，然后同步梯度。张量并行则是把每一层的权重矩阵拆成几份，分别放到不同的卡上，做矩阵乘法时再合并结果。专家并行是MoE特有的：每个设备上只放一部分专家，路由器决定某个token去哪个设备上的哪个专家做计算。

这样做有两个天然的好处。一是单个设备的内存压力被分散了，你不需要把几百亿参数全部装进一张卡里。二是计算负载也被分散了，每个专家只处理它负责的那部分token。但代价是设备之间的通信量大幅上升——在GPU集群上，这对应的是All-to-All通信，也就是每一张卡都要和其他卡实时交换激活值。放在FPGA场景里，这意味着如果你做的是多FPGA协同，你必须解决板间高速互连（比如光纤或者专用的并行总线）才能支撑这条路。我现在做的很多FPGA项目，单板已经能跑起来，但多板协同的通信瓶颈往往是真正限制扩展性的地方。

2.3 稀疏激活带来的计算效率幻觉

聊到这里，我得泼一点冷水。很多人听到MoE就两眼放光，觉得“参数这么多，算力需求一定很大”，或者说“只有一部分专家被激活，所以计算量很小”。这两种说法都有各自的道理，但都有失偏颇。

稀疏激活的收益主要体现在推理的FLOPs（浮点运算量）上。比如一个稠密模型单次前向传播需要1000G FLOPs，而你用一个MoE模型，参数量翻倍但每次推理只激活其中20%的参数，那么理想情况下FLOPs可以从1000G降到200G。但请注意“理想情况”这四个字——在实际硬件上，FLOPs降低不等于速度提升。为什么？因为硬件做计算是需要数据喂进来的。激活的专家虽然少了，但你依然要把完整的权重参数从外存读进缓存或者内存里。换句话说，只要你的硬件平台是按“整个模型”来存权重的，那么实际的内存访问量并不会随着稀疏激活而等比例下降。

这引出了一个核心概念：计算瓶颈和访存瓶颈的区别。稠密模型通常是计算瓶颈，因为每一个权重都要参与计算。MoE则严重偏向访存瓶颈，因为权重总量大，而每次只用到一部分，但你又必须把用到的那些权重搬进来——你无法提前知道路由会选择哪些专家。除非，你能把模型设计成“分层多级路由”或“部分专家常驻片上”，否则访存压力几乎抵消了所有的稀疏收益。

这里就是我为什么坚持认为FPGA做MoE必须重新思考架构的原因。GPU有庞大的显存带宽（比如HBM3可以提供数TB每秒的带宽），所以它能在一定程度上无视这个问题。而FPGA的外部存储带宽往往只有几十GB/s，如果不做缓存设计上的针对性优化，MoE的稀疏性反而会成为性能负资产。

3. FPGA实现MoE的核心挑战与关键抉择

3.1 FPGA的真实计算能力评估

谈FPGA做AI加速，先别急着吹“并行计算”，我们先看看它的硬指标。以目前主流的中高端FPGA为例，比如Xilinx Alveo U250或者Intel Stratix 10系列，标称的INT8算力大致在20到40 TOPS之间。这个数字是什么概念？现在一颗消费级的GPU，比如RTX 4090，INT8算力在600 TOPS上下。你在规格表上看到的差距是10到20倍的量级。

但FPGA从来不是靠峰值算力赢的。它的优势在于两点：一是能效比，同样是做一瓦特的计算量，FPGA的每瓦性能往往比GPU好不少；二是灵活性，你可以把数据通路、流水线、存储结构全部按照你的算法来定制。对MoE来说，算力其实不是最大的坑——因为单token激活的参数量没那么多，反倒是存储和带宽的问题会更让人头疼。所以在做资源评估时，不能只看算力，要把BRAM（块RAM）、URAM（UltraScale架构中的大容量RAM）、DSP Slice和外部DDR带宽放在一个表格里综合看，缺哪一块都是瓶颈。

3.2 为什么MoE对FPGA不够友好

我们从四个方面拆开看这个“不够友好”到底难在哪里。

第一，专家并行性不足。FPGA的并行是空间上的——你把逻辑电路铺开，同时运行多条流水线。但MoE的专家路由是动态的，不同token走的专家路径可能完全不同，这就意味着你没法像矩阵乘法那样把计算固定成一个规整的流水线形状。你必须在硬件上做一个动态调度逻辑，根据路由结果把不同的输入喂给不同的专家模块。这个调度器本身就会消耗大量的逻辑资源，而且很容易成为时序收敛的难点。

第二，访存带宽天花板。前面介绍过，MoE的推理瓶颈主要在访存。FPGA外挂的DDR4通常提供几十GB/s带宽，HBM版本可以到几百GB/s，但依然远远小于GPU的HBM3带宽。如果把全部专家权重放在DDR里，每来一个token都要去DDR里拉几个专家的权重，这种方式在带宽上是完全不可行的。唯一的出路是把热点专家放在片上存储里。可问题又来了：片上BRAM/URAM的容量总共也就几十MB，放一个小专家可能还好，放一堆大专家根本放不下。这是一个存储容量和带宽反复拉扯的死结。

第三，动态路由引发的流水线停顿。在FPGA上做矩阵乘法，最爽的方法是把数据做成深度流水线，一拍一个输出，效率拉满。但MoE的动态路由破坏了这种美好想象——可能这个周期是专家3在算，下个周期又变成专家7要处理新来的token。如果你给每个专家都单独建一套流水线，资源不够；如果多个专家共享一条流水线，那你就要处理切换开销和缓冲管理。这非常考验调度架构的设计功力。

第四，工具链的抽象鸿沟。FPGA开发不像GPU那样有现成的PyTorch前端和高度自动化的编译器。你写Verilog/VHDL做MoE加速，等于把整个计算流程退回到“手工设计电路”时代。虽然现在有Vivado HLS这样的高级综合工具，但处理动态控制流仍然相当吃力——HLS编译器对静态循环的优化效果很好，一旦遇到动态分支、动态索引，生成的硬件往往效率比较差，资源消耗也会变得不可预测。

3.3 那个被过度简化的问题：你能在FPGA上跑多大尺寸的MoE模型

很多人一上来就问：“用FPGA能跑MoE模型吗？”答案当然是能，但必须加限定条件。如果是一百多亿参数的模型，你单块FPGA根本放不下权重，先不谈算力，存储就直接卡死了。所以实际可行的路径一般有两条。

第一条路径：做单专家或少数专家的计算加速器。FPGA不做整个模型，只做其中“最重”的矩阵乘算子，权重和数据由外部处理器（比如ARM、x86 CPU或者Zynq里的硬核处理器）调度。这种模式相当于把FPGA当作一个可配置的矩阵协处理器。

第二条路径：做超低比特量化后的MoE加速。把权重从FP16压到INT8甚至INT4，同时把模型尺寸控制在几亿到几十亿参数范围内。这样可以勉强放进高端的FPGA加外部DDR的体系里，性能上能做到“能跑但不够快”。如果只是验证架构思路、跑通demo、写论文，这条路径完全可行。如果指望FPGA在通用场景下达到GPU的推理速度，那现阶段确实有些力不从心。

我个人的看法是：FPGA在MoE上的角色，更接近“专用加速验证平台”，而不是“通用推理引擎”。你可以在FPGA上验证某种新型专家路由算法的硬件可行性、某种量化方案的实际效果、某个特定场景的端到端时延，这些价值一点也不小。

4. 从算子到底层存储：FPGA实现MoE的五个核心环节

4.1 矩阵乘法运算单元设计

矩阵乘法（GEMM）是MoE模型最核心的计算原语。在FPGA上实现GEMM，主流方案是采用“脉动阵列”或者“分块展开”的结构。脉动阵列的思路是把很多个乘累加单元排列成阵列，数据像波浪一样在阵列里流动，每个单元只和相邻单元通信。这种结构对FPGA的好处是数据复用率高、布线规整、时序容易跑得很高。它的缺点是：如果你要对不同规模的矩阵做GEMM，阵列的形状是固定的，利用率就上不去。

在实际工程中，我更倾向于采用“可重构分块”的思路：把大矩阵切分成固定大小的小块（比如32x32或64x64），在DSP Slice上展开乘累加。这样可以通过外层逻辑控制分块顺序，适应不同尺寸的专家矩阵。这个思路对MoE尤其重要，因为不同专家的权重维度可能不一致，如果你只做一种固定形状的脉动阵列，很多专家矩阵根本塞不进去。

4.2 动态路由的硬件调度设计

路由模块在FPGA实现时，我的经验是：不要做成纯硬件逻辑控制，尽量做成“软硬件协同”的方式。什么意思？就是把门控网络的分数计算放到FPGA逻辑里做，但最终的路由决策和任务分发给一个简单的微控制器或者状态机来做调度。这样做的核心原因是，路由决策本身的计算量不大，但它后续牵涉到的专家选择、数据搬运、结果合并等操作，需要一套相对灵活的状态管理机制。纯硬件逻辑做这个，一旦需求变化（比如从Top-2改成Top-3），你的RTL代码就得大改。用软核调度，比如在Zynq的ARM处理器里做路由决策，FPGA这边只负责可重构的GEMM计算，这样整个系统设计就灵活了很多。你甚至可以在片上存储里维护一个路由表，记录当前一段时间内的专家命中统计，用来指导权重换入换出的预取策略。

4.3 模型参数的量化与存储策略

MoE模型落地到FPGA，如果不做量化，基本不用谈性能。市面上比较成熟的做法是训后量化（PTQ），把权重量化到INT8甚至INT4，然后在FPGA上部署INT8定点矩阵乘。INT8的DSP利用率非常高，许多FPGA型号的DSP都能直接支持单拍INT8乘累加。INT4则需要自己做打包解包逻辑，但换来的是存储带宽的有效翻倍。

有一个容易被忽略的坑：MoE中的门控网络往往对量化精度更敏感。路由决策是在不同输入之间做排名比较，如果门控网络的输出被量化噪声干扰，排名可能就乱了。我的建议是：路由部分的计算保持FP16甚至FP32精度，专家内部的GEMM用INT8。这样处理下来，精度损失基本可控，而性能收益却很显著。

4.4 片上缓存与外存的数据搬移策略

FPGA做MoE最容易卡死的地方其实是数据搬移，而不是计算。每个token激活两个专家，意味着至少需要搬入两份专家权重到片上。如果专家数量很多，最理想的做法是把所有专家权重都存在片上BRAM/URAM里。可惜，这几乎不可能。所以实际的做法是：在DDR中维护一份完整的专家权重库，在片上维护一个专家权重的“热缓存”。根据路由预测，提前把可能用到的专家权重预取到片上。这个思想有点像CPU里的缓存系统，只是预取策略完全由你对模型路由分布的先验知识来决定。

还有一个心得：尽量把同一批token的算子打包成较大块，再触发一次专家权重的加载。在GPU上批量推理，一次会处理几百个token，由于路由分布的统计规律，很多专家会被多个token同时命中——把这些命中集中到一起，权重加载的摊薄成本就会小很多。FPGA上也应该模拟这个机制，而不要真的单token单token地搬权重。

4.5 PCIe/DDR/片间互连的整体吞吐量对齐

到了系统层面，你必须把吞吐量对齐这件事想清楚。一个典型的FPGA加速卡结构是：FPGA通过PCIe与主机通信，通过DDR3/DDR4/HBM存储权重和中间结果。数据的流动路径大概是：主机把输入token通过PCIe下发到FPGA，FPGA调取DDR里的专家权重，计算完成后把结果写回DDR，再通过PCIe将最终结果返回主机。这条链路里，最容易出现瓶颈的就是PCIe和DDR带宽。如果你在逻辑里设计出的GEMM算力很高，但PCIe吞吐跟不上，那计算单元就只能停下来等数据。

我的设计经验是：在动手写RTL之前，务必做一张详细的数据流带宽表，把你设计的每个模块每秒钟需要多少数据量列清楚。举个例子，假设DDR读带宽是25.6GB/s，你的专家矩阵平均是50MB，每次为一批token加载120个专家权重，那么你就需要6GB的数据加载量，按25.6GB/s来算需要0.23秒。如果这批token的计算时间只有0.05秒，那你的系统瓶颈毫无疑问在DDR，这个时候加再多的DSP也没有用。这个问题不提前算清楚，到板子调起来再改架构，代价非常痛苦。

5. 一个可落地的FPGA加速器设计示例

5.1 系统整体架构与数据流规划

来一个偏实战的例子。假设我们要设计一个针对“单层MoE模块”的FPGA加速器，目标是把一个约2亿参数的MoE层（8个专家，每个专家约2500万参数）用INT8量化后跑在Xilinx Alveo U250上。

先确定参数规模：2500万参数，每个INT8是1字节，一共25MB。8个专家就需要200MB。Alveo U250的BRAM/URAM总共大约50MB左右，所以全放片上是不可能的。DDR容量这里不是问题（U250一般有4个DDR4 bank，容量64GB），带宽约77GB/s。所以我们的策略是：所有专家权重驻留DDR，片上只做一个容量约为25MB的“专家缓存”，预存使用频率最高的一个专家的权重。计算时，如果一个token被路由到不在缓存中的专家，就必须从DDR加载。

数据流设计成下面这样：主机通过PCIe下发一批token（比如64个token），FPGA内部的“路由器”模块先完成门控计算，得出每个token命中的Top-2专家；然后“权重加载控制器”检查缓存命中情况，对未命中的专家发起DDR读取；权重到达后，GEMM阵列开始执行计算；计算结果在“合并器”里按照路由权重做加权融合；最后通过PCIe把输出token传回主机。

5.2 关键模块的RTL实现思考

主计算阵列我们做成一个64x64的INT8脉动阵列。64个DSP切片作为一行，64行展开，产生128x128的乘累加能力。这里我没有走32位累加，因为INT8乘INT8累加很容易溢出，用32位累加更稳妥。每个DSP切片可以做到一个时钟输出一个INT8乘累加，所以这个阵列的处理能力是64x64=4096个乘累加/周期。如果时钟跑到300MHz，那总吞吐大约是1.2T MAC/s，也就是2.4T OPS。这个数字在FPGA阵营里已经很能打了。

权重加载控制器是整个设计的难点。它的任务是为GEMM阵列持续供数。GEMM阵列每周期消耗4096字节的权重（64x64个INT8）。300MHz下，权重消耗速率大约是1.2T字节/s，也就是1.2TB/s。但DDR的带宽只有77GB/s，差了16倍。这说明什么？说明这个GEMM阵列根本无法从DDR获得持续数据。必须利用片上缓存，把权重切成小块后反复复用。实际的做法是：让同一批权重服务尽可能多的token计算。假设我们每次从DDR加载一个完整的专家矩阵（25MB），这个加载时间在77GB/s带宽下是0.32毫秒。加载完后，让这一批64个token中被路由到这个专家的所有token同时进入GEMM阵列计算。这样权重加载成本就被摊薄了。

路由调度上的难点在于，64个token可能只命中3到4个专家，那么你就只需要加载这3到4个专家就够了，不需要全部8个。理想情况下的稀疏收益在这里体现：DDR访问量从“整个模型”降到了“这一批token实际命中的专家集合”。

5.3 性能分析：真实能达到多少

做一轮估算。假设64个token，每个token命中2个专家，那么总共产生128次专家计算需求。如果去重后只涉及5个专家，每个专家需要计算64x4096x4096的矩阵乘（4096是隐藏维度）。一个专家的计算量是64x4096x4096=1.07G MAC。5个专家就是5.37G MAC。按GEMM阵列的计算能力1.2T MAC/s算，理论计算时间约4.5毫秒。加上DDR加载5个专家权重的时间：5x25MB=125MB，按77GB/s算需要1.62毫秒。总耗时约6.1毫秒。听起来还行？

但别忘了，这只是一个MoE层。一个大模型动辄几十层。如果整个模型都是MoE，那么60层的话，单次推理的最理想时间就要366毫秒。如果批量再扩大、或者路由分布更分散、命中专家数量更多，耗时还会上升。这就是FPGA做MoE的真实段位：能跑，但绝对不适合做高并发的大模型推理服务。它适合的是低功耗、低时延敏感、模型结构相对固定的小场景。

6. 工具链与实践陷阱：从仿真到板上部署

6.1 Vivado HLS还是手写RTL

这个问题几乎每次都会被问到。我的建议很直接：如果做的是概念验证、快速迭代，用Vivado HLS（或者是更新的Vitis HLS）完全够用。HLS的优点是可以把C/C++代码转换成RTL，调试和迭代的速度非常快。尤其是GEMM这种规整的计算密集型算子，HLS生成的流水线质量已经可以和手写RTL接近。但如果你要在板子上跑出极致的性能和资源利用率，或者动态调度逻辑特别复杂，手写RTL的优势就体现出来了。

我个人常见的做法是混合模式：GEMM阵列和权重搬运这两个对性能和时序要求最高的模块，手写RTL；路由决策、配置寄存器、主机通信这些相对灵活的逻辑，用HLS或者软核处理器实现。这样做的好处是，既保证了核心计算模块的性能，又给整个系统保留了可用性和可维护性。

6.2 仿真也好，验证也罢：先做一个最小系统

MoE的FPGA工程极其容易在联调时出问题。原因很简单，MoE的访存模式非常动态——不同token、不同路由结果，对外存的访问位置都不同。你很难在仿真阶段覆盖所有情况。一个特别有效的方法是，做一个“最小验证系统”：先用小尺寸模型、小批量token，在仿真里跑通完整数据流（PCIe下发-token路由-专家加载-GEMM计算-结果返回）。等这一条链路完全通了，再逐步扩大模型尺寸和批量大小。

联调时最容易碰到的两个怪问题：第一个是数据对齐问题。INT8打包后，可能一个32位字里放了4个INT8，但是在DDR读取的时候字节顺序错位了，结果就是计算全错但波形看起来没问题。第二个是时序收敛问题。动态路由导致的MUX逻辑特别容易产生长组合逻辑路径，如果时序不收敛，处理器的频率就得往下掉，性能立刻缩水。解决手段通常是：在高级别逻辑里加流水级，用时间来换逻辑深度，别让路径太长。

7. 常见问题与避坑实录

下表整理了我自己在FPGA+MoE项目里遇到的一些实际问题，希望对你有所帮助：

这里多说一句带上板调试的体会。如果你在用Zynq这类带ARM硬核的FPGA，建议把调试接口留好——比如通过AXI总线暴露几个寄存器，实时读取DDR读写计数和GEMM完成计数。这相比用JTAG抓波形调试要高效得多，尤其在动态路由的情况下，你很难预判哪个时刻出问题。有了计数寄存器，你就知道系统到底卡在哪个环节，是权重没加载完，还是GEMM在空转。在我看来，断点调试思维从软件延伸到硬件调试里，是FPGA工程师最实用的技能之一。

8. MoE在FPGA上的优化方向：从算子到架构的进阶路径

8.1 算子级优化：如何榨干DSP切片

先聊算子级。GEMM阵列是吃DSP的大户，优化重点自然是让DSP的利用率无限逼近100%。在FPGA上，要小心一个现象：名义上你有几千个DSP切片，但实际布局布线之后，很多DSP处于闲置状态，原因是数据供给不上。解决方向有两个。第一个是数据复用优化，尽量让同一个权重被多个不同的token同时使用，这样每个权重搬运过来就能产生更多计算。第二个是流水线平衡，保证GEMM阵列的输入数据是持续不断的，中间不要有空拍。在MoE场景下，专家切换会导致流水线断流，所以一个很有用的技巧是“重叠计算”：在专家A的最后一批token还在GEMM阵列里计算的时候，就开始预加载专家B的权重。这个双缓冲技巧前面提过，但怎么同时支持多个专家之间的衔接，就需要更精细的调度状态机了。

8.2 访存优化：从DDR到HBM/片上存储的层次化设计

FPGA访存优化的核心是“层次化”：片上BRAM是最快的存储，但容量小；URAM容量较大，速度也不错；HBM带宽高、容量适中；DDR容量最大但延迟和带宽都不尽如人意。对MoE来说，应该把一个专家的权重尽量放进URAM里，再把次热门的专家放在HBM（如果板卡支持）或者DDR的固定区域。这要求你对模型中每个专家的“命中频率”有先验了解。好消息是，MoE模型训练完之后，专家路由的分布基本稳定，你可以统计一批真实输入数据，得到专家的“热力分布”，为存储策略提供依据。这个方法我在之前的项目里用过——针对固定的数据集，先离线统计专家热度，然后把Top-N个专家对应的权重全部固化到URAM里，推理性能能比纯DDR方案高出2到3倍。

8.3 系统级优化：软硬件协同与动态部分重配置

再往上一个层次，是软硬件协同。FPGA有一个GPU没有的独门绝技——动态部分重配置（Dynamic Partial Reconfiguration，DPR）。它允许你在系统运行的过程中，重新配置FPGA的一部分逻辑，而不影响其它部分正常工作。这个特性用在MoE上非常有意思：你可以在运行时动态换入/换出不同的专家计算单元。比如你有32个专家，但FPGA上只实现了8个专家的硬件计算逻辑，那可以通过DPR把暂时用不到的专家逻辑替换成当前正在热用的专家逻辑。当然，DPR的启动开销不小，通常需要几十到上百毫秒，频繁切换并不划算。所以更实际的做法是：只在模型切换或者专家集切换的边界处使用DPR，而不是每个token都去做重配置。

还有一个软硬件协同的点是：尽量把调度决策放在主机端或者软核处理器上完成。FPGA上的路由计算和专家管理状态机，只接收已经定制好的、固定格式的“指令序列”。这样做的好处在系统复杂后体现得非常明显——调试调度逻辑不再需要重新综合整个FPGA工程，只要在软件层面改一行代码就行，迭代成本低了一个数量级。

8.4 能效比优化：低精度、结构化稀疏与剪枝

最后提一个更长期的方向：模型结构本身。FPGA不像GPU那样有暴力算力，它更讲究“合适的算子吃合适的资源”。如果你正在设计一个要部署到FPGA的MoE模型，我有几个建议。第一，尽量使用2的幂次作为专家数量，这样路由决策只需要对低比特位做简单解码就能确定专家编号。第二，专家内部的FFN隐藏维度最好固定成同一个数值，不要出现一个专家4096维、另一个专家2048维的情况，否则GEMM阵列利用率会被拖垮。第三，考虑生成结构化稀疏权重——比如让每个专家的FFN中间层每隔1个输出通道就剪掉一半通道。这种结构化稀疏在FPGA上非常好利用：GEMM阵列跳过那些被剪掉的通道，计算量直接砍半，而且几乎不影响路由和最终精度。这一点是当前FPGA部署MoE最值得投入的方向，因为它在不改变模型结构的前提下，把计算和访存需求同时降下来了。

9. 写在最后：我的一些实践感受

做FPGA上的MoE加速，确实不像在GPU上写PyTorch那样方便快捷，很多时候你会觉得自己在用一个很底层的工具去解一个很上层的问题。但也正是这种“自讨苦吃”的过程，能让你对MoE架构的本质理解得更深——每次路由决策背后的访存开销，每个专家权重在DDR里的摆放位置，每一拍流水线里DSP有没有闲着，这些在GPU上被隐藏起来的细节，在FPGA上全都暴露得一清二楚。

如果你刚接触这个方向，我建议你从小处着手，先做一个单专家的GEMM加速器，跑通PCIe/DDR的数据通路后，再逐步加入路由逻辑和专家切换。不要一上来就追求大模型尺寸，能把一个小模型在FPGA上的延迟优化到和在CPU上差不多，就已经是很大的进步了。

FPGA做MoE的未来在于：它不是在算力上跟GPU较劲，而是在“每瓦性能”和“专用场景定制”这两个方向上建立自己的护城河。如果你的场景功耗敏感、模型结构固定、功能长期不变，FPGA绝对值得你认真考虑。