150美元FPGA平台实现30B MoE大模型边缘推理，18 token/s解码速度突破成本性能极限

关键词： FPGA 加速器、混合专家模型（MoE）、边缘部署、低成本推理、GEMV 优化

以150美元物料成本和18 token/s的解码速度，FPGA在大语言模型边缘部署领域取得了关键性突破。

在深度学习硬件加速领域，FPGA的定位一直较为特殊。它既不具备GPU那样统治训练市场的极致算力密度，也难以像ASIC那样在特定场景下实现终极能效。长期以来，FPGA主要活跃于架构原型验证、芯片流片前验证，以及少数对灵活性和能效有特殊要求的最终部署场景。

表：与现有FPGA大语言模型加速器的对比。本研究在入门级FPGA上部署了最大的30B MoE模型，同时支持预填充与解码加速，其解码性能在嵌入式FPGA加速器中位居前列。

然而，大语言模型的兴起正在改变这一格局。LLM推理呈现出显著的内存受限特性——端到端性能的瓶颈往往来自内存带宽，而非计算吞吐量。这使得在算力上不占优势的FPGA，得以与GPU、NPU在推理赛道上站在更接近的起跑线上。

但挑战依然严峻：现有的FPGA LLM加速器研究大多基于昂贵的高端FPGA平台（如Alveo U280、VCU128等），这些动辄数千美元的设备对于成本极度敏感的边缘产品而言并不现实。因此，如何在低成本的嵌入式FPGA上实现可用的LLM推理性能，成为一个亟待解决的核心难题。

正是在此背景下，中国科学院自动化研究所的研究团队提出了 Hummingbird+ 方案，首次论证了使用低成本FPGA作为LLM最终部署硬件的可行性。

该团队基于赛灵思Zynq UltraScale XCZU2CG/3EG SoC定制了PCB平台，配备24GB内存，其大规模生产时的物料成本预计可控制在150美元以内。

Hummingbird+方案实测演示视频。

在此平台上，他们成功部署了经GPTQ 4-bit量化的Qwen3-30B-A3B混合专家模型，实现了超过18 token/s的解码速度以及50 token/s的预填充速度。

图：Hummingbird+面向MoE大语言模型部署的端到端解决方案架构图。该架构以定制化PCB和入门级SoC为基础，集成大容量内存，并通过深度优化的加速器设计，首次在FPGA上完成了中大规模MoE模型的工程化部署。

关键问题

问题一：内存成本波动下，30B MoE模型相比小型稠密模型是否仍具成本优势？

Hummingbird+通过极致的架构优化，首次将30B MoE模型部署到150美元级别的FPGA平台上，是显著的工程突破。然而，这一成本优势高度依赖于估算时所采用的内存价格。随着2024年内存市场价格上涨，DDR4颗粒成本大幅上升，使得在BOM中占比近半的内存成本压力剧增。在此背景下，为容纳15GB模型参数而必须使用高密度DRAM的MoE方案，其整体成本优势是否已被削弱？相较于仅需4-8GB内存、对涨价容忍度更高的4B/8B稠密模型方案，Hummingbird+在产业落地中是否会因较高的内存依赖而处于劣势？

Hummingbird+在150美元BOM的FPGA平台上实现30B MoE模型部署，其极致的资源优化与完整的系统设计是重大突破。然而，正如研究所述，内存成本约占BOM的一半（约75美元），整机成本对DRAM价格高度敏感。若内存价格持续上涨（例如翻倍），总BOM成本将显著增加，从而削弱其成本优势。相比之下，部署4B/8B稠密模型仅需4-8GB内存，对内存涨价的承受能力更强，在成本敏感的边缘场景中可能更具经济性。

但需注意，30B MoE 在复杂任务上的效果远超小稠密模型。该设计的价值在于证明了 FPGA 可作为高性价比的 LLM 推理平台，为未来内存价格回落或新型存储技术（如 CXL）的应用提供了技术储备。其设计思路（如多核并行、双精度计算）对任何规模的 LLM 部署均有借鉴意义。因此，内存波动虽带来挑战，但这项探索为边缘 AI 的模型-硬件协同设计开辟了新路径。

问题二：极致资源压缩下的通用性与可移植性代价，手工优化 RTL 能否应对模型演进？

为在资源有限的 FPGA 上部署多处理器，设计采用了大量手工 RTL 优化（如 DSP 内建寄存器链、定制 AXI 总线）。这种紧耦合方案在面对未来 MoE 架构变化（如动态专家路由、变长 Group-Query）时，是否意味着每次模型迭代都需重新进行流片级适配，从而丧失 FPGA 的核心灵活性优势？

实现极致成本效率确实需要手工 RTL 的细粒度优化，这是当前高级综合或编译器方法难以达到的。但关键在于，主流 LLM 架构相比 CNN 已趋于稳定——Transformer 块结构、GEMV 主导的计算模式、GQA/MoE 等核心范式在可预见的未来不会发生剧烈变动。

该设计本身已包含参数化可配置能力：
* GEMV 引擎支持 W4/KV8 双精度切换、AXPY/DOT 双模式；
* 标量引擎通过资源时分共享电路实现算子级动态重组。

这些设计使其能适配不同的头维度、专家数和量化方案。

真正的挑战在于自动化工具链的缺失。这为 AI 辅助 RTL 生成提供了机遇——若能基于 LLM 架构的稳定性，训练模型自动生成优化 RTL，则可兼顾手工效率与自动化迁移。

因此，当前的紧耦合设计是技术发展阶段的必然选择，而非对灵活性的根本放弃。

一、相关工作：FPGA 加速 LLM 的演进脉络

在深入技术细节之前，有必要梳理一下 FPGA 加速 LLM 的研究脉络，以理解其创新之处。

1.1 云端 FPGA：性能验证的温床

早期的 LLM FPGA 加速研究主要集中在云端高性能 FPGA 平台上。例如，有研究在配备 HBM 的 Alveo U280 上部署了 LLaMA2-7B 或 GPT-2-1.5B，证明了 FPGA 加速 LLM 的可行性。但这些平台价格昂贵，且无法直接迁移到成本敏感的边缘场景。后续一些工作虽然各有创新，但都未能突破硬件成本的限制。

1.2 嵌入式 FPGA：成本降低的尝试

近年来，一些研究开始关注嵌入式 FPGA 平台。例如，有研究在 KV260 上部署了 LLaMA2-7B，专注于解码阶段的加速；也有研究进一步降低了资源消耗，使其能在更便宜的平台上运行，但同样只支持解码阶段。另有研究引入了预填充加速，但目标模型是经过极端量化的小型 BitNet LLM，这严重影响了模型质量；还有研究实现了较高的预填充速度，但只针对 0.6B 的小模型。

如图 2 所示，现有研究似乎陷入了一个难以兼顾的权衡：硬件成本、模型质量、预填充和解码速度，这四个维度中提升任何一个往往以牺牲其他维度为代价。该设计的目标正是打破这一困局。

二、核心创新

其核心理念可以概括为：通过极致的 FPGA 资源优化，在低成本器件上实现多处理器并行，从而同时满足解码速度和预填充速度的要求。这一理念的实现依赖于三个层面的创新：平台层面的定制硬件设计、架构层面的多 token 处理器组织、以及微架构层面的资源优化技巧。

2.1 混合专家模型：FPGA 的天然盟友

要理解为何选择 Qwen3-30B-A3B 这样的混合专家模型，需要回顾一下 MoE 的工作原理。

对于每个输入的 token，路由器首先通过线性投影和 softmax 计算激活哪些专家，然后选择得分最高的 K 个专家，重新归一化概率。每个被选中的专家执行三层变换（门控、上投影、下投影）。

MoE 的精妙之处在于：虽然模型总参数量很大，但每个 token 只激活一小部分专家（例如 128 个中选 8 个），使得内存访问量不会随总参数量线性增长。随着 MoE 稀疏度的不断提高，每个 token 的内存访问工作负载越来越接近低成本 DDR 硬件的舒适区，这为嵌入式 FPGA 提供了绝佳的切入机会。

2.2 资源需求建模

在具体实现之前，研究团队对 Qwen3-30B-A3B 的内存需求和性能预期进行了精确建模。

内存需求：经过 GPTQ INT4 量化后，Qwen3-30B-A3B 的总参数占用 14.52GB，但每个 token 实际激活的参数仅 1.47GB。加上支持 16K 上下文所需的 0.77GB KV 缓存，总内存需求约为 15.29GB。这恰好落在平台 24GB 内存的容量范围内。

性能建模：对于采用分组查询注意力的 LLM，解码速度不仅取决于内存带宽，还受到计算能力的制约。通过定义计算带宽比 α，可以推导出理论解码速度与预填充延迟的公式，为后续的性能评估提供了理论基准。

三、平台级设计：从原型到产品

其硬件平台设计体现了从研究原型到实际产品的转变。整个系统分为三个层级：PCB 平台层、SoC 层和加速器层。

3.1 定制 PCB 平台

定制 PCB 采用入门级 Zynq UltraScale SoC（XCZU2CG 或 XCZU3EG），两者引脚兼容。

3.2 SoC 级优化

相比之前的 Hummingbird 设计，Hummingbird+ 在 SoC 层面进行了关键优化，显著降低了可编程逻辑（PL）资源的消耗：

• 移除 AXI 互联 IP：为每个 128 位宽度的 AXI 通道节省了约 1K 个查找表（LUT）。
• 移除 AXI 交叉桥：移除了连接 Zynq 处理器系统（PS）主 AXI 接口和加速器到内存控制器（MIG）的交叉桥，节省了约 3K LUT。
• 移除 AXI Datamover IP：该 IP 会消耗大量块 RAM（BRAM）资源，移除后进一步释放了存储资源。
• 采用自定义 RTL 实现 AXI 基础设施：使用寄存器传输级（RTL）设计实现轻量级、高效率的自定义 AXI 互连逻辑，替代通用的 IP 核，从而在整体上提升了资源利用效率。

3.3 加速器级架构创新

现有 LLM 加速器通常采用矩阵引擎、非线性函数单元和内存管理器三个主要模块的粗粒度设计。Hummingbird+ 团队识别出这种架构在适配 LLM 推理时的几处低效问题：

1. 计算形状不匹配：LLM 推理，尤其是解码阶段，以扁平形状的广义矩阵乘法（GEMM）或广义矩阵-向量乘法（GEMV）为主。通用的大型矩阵计算阵列若尺寸不匹配，会导致计算单元和内存带宽利用率不足。
2. 流水线粒度不足：解码过程对数据依赖和初始化延迟极为敏感。粗粒度的三模块设计缺乏细粒度的流水线来隐藏操作间的空闲周期，影响整体吞吐。
3. 模块间耦合松散：矩阵引擎与特殊函数单元（如激活函数）之间松散的耦合关系，迫使特殊函数单元过度配置并行度，以避免其成为矩阵乘法流水线的瓶颈。

为解决这些问题，Hummingbird+ 提出了以 高资源效率的紧凑型令牌处理器 为核心的新架构。每个令牌处理器集成了执行单令牌前向传播所需的所有计算组件：一个用于线性层计算的 GEMV 引擎、一个用于非线性激活函数的标量引擎，以及一个用于临时存储激活值的片上缓冲区。

多个令牌处理器通过共享的内存总线访问模型权重和键值（KV）缓存。在预填充阶段，所有处理器并行工作，共同计算注意力机制和多层感知机（MLP）层。由于不同预填充令牌间的计算相互独立，这种架构避免了复杂的处理器间互连，同时实现了可扩展的多令牌并行推理。

在解码阶段，架构采用主从协作模式：
* 第一个令牌处理器作为主处理器，执行完整的计算流程（包括注意力、MLP等）。
* 其余处理器在跳过 MLP 计算的同时，协同分担分组查询注意力（GQA）的工作负载。

所有处理器接收相同的指令流，并通过特定的标志位来区分在解码阶段应执行还是跳过某些操作。主处理器与其他处理器之间通过一条轻量级的 16 位数据总线互连，用于广播和收集激活值。

3.4 内存子系统

平台的内存配置为高性能推理提供了坚实基础：
* 处理器系统（PS）侧：集成了 8GB 板载 DDR4 内存。
* 可编程逻辑（PL）侧：配备了一个 SODIMM 插槽，支持扩展 8GB、16GB 或 32GB 内存。
* 双通道设计：PL 侧的双通道内存接口可提供高达 34GB/s 的峰值带宽，与现代采用 DDR5 的嵌入式 NPU 芯片相当，而其高达 24GB（8GB板载 + 16GB扩展）的总容量则远超后者典型的 8GB 配置。

此外，为加速大型模型权重的加载，平台还预留了一个 M.2 NVMe 插槽，通过 PS 侧内置的 PCIe 2.0 硬核连接一块 128GB SSD。这些丰富的板载存储资源足以支撑 300 亿参数级别的混合专家（MoE）模型进行推理。

四、微架构优化：榨干每一份资源

Hummingbird+ 最核心的贡献在于微架构层面的极致优化。团队的目标是在低成本的嵌入式 FPGA 上同时实现高效的解码和预填充加速，这就要求每个令牌处理器的资源占用必须尽可能小，以便在有限的芯片资源内实例化足够数量的处理器。

FPGA 设计者通常拥有一套 DSP 优化工具箱，例如操作数打包、双倍数据率（DDR）、单指令多数据（SIMD）和 DSP 级联。然而，将这些技术高效地组合并应用于特定计算模式（如 GEMV），仍需精细的手工设计。

4.1 GEMV 引擎的极致优化

GEMV 引擎支持两种计算模式：点积模式（y = W·A）和 AXPY 模式（Yi = a·X + Yi-1），并针对不同精度进行了优化：W4A12 用于线性投影层，KV8A12 用于注意力计算中的键值缓存。

引擎的并行度经过精心设计：通过双倍数据率（DDR）技术实现 M=2；通过并行实例化 128 个 DSP 核心实现 K=128；在 W4 精度下，通过操作数打包技术实现 N=2（在 KV8 精度下降为 N=1）。最终，单个 GEMV 引擎仅消耗不到 1K LUT 和 140 个 DSP，却能提供高达 272 GOP/s 的计算能力。

双精度操作数打包

采用 W4A12/KV8A12 量化方案。12 位的激活值从 B 端口输入，权重和 KV 缓存值则共享 A 和 D 输入端口，利用 DSP 内部的预加器实现 (A + D) × B 的经典打包计算。

在 W4 模式下，输入 DSP 的 8 位数据总线承载一对 4 位权重：一个置于 D 端口的低 4 位，另一个经符号扩展后置于 A 端口的高 4 位。在 KV8 模式下，通过 DSP 内部的 INMODE[1] 信号将 A 端口门控为零，D 端口则承载完整的 8 位数据。利用 DSP 内部逻辑实现 A 端口零门控，减少了 LUT 消耗，仅需为每个 8 位数据总线配置 5 个 2 选 1 复用器来处理 D 端口的精度切换。

对于有符号整数的数据打包所需的 +1 修正项，团队创新地将其吸收到 DSP 的四输入后加器中，通过配置和选择 W 复用器的常数舍入因子来实现，从而消除了额外的 LUT 修正逻辑。

链-树混合实现

基于对量化组大小、典型 LLM 头维度和 FPGA 内存总线宽度的分析，团队确定 128 为最优的 GEMV 并行度 K。他们将 DSP 以 8 个为一组，形成 16 条 DSP 链。每条链内的 DSP 通过 B 输入级联和 P 输出级联路径连接，每个 DSP 执行两个 4×12 有符号乘法或一个 8×12 有符号乘法。

每条 DSP 链产生两个 18 位或一个 22 位的部分和输出。为了聚合 16 条链的结果，团队设计了一个分层归约树：
* 第一级：使用四个工作在 SIMD=2 模式下的 4-1 归约单元（每个由两个级联的 DSP 在 ALU 模式下构成），为 W4 模式提供两路 24 位归约结果，或为 KV8 模式提供单路结果。
* 第二级：由于 24 位宽度不足以容纳 KV8 模式的完整累加结果，第二级采用两个工作在 SIMD=1 模式下的 4-1 归约单元进行最终聚合。

整个归约树共使用 6 个归约单元（消耗 12 个 DSP）。因此，单个 GEMV 引擎总计需要 128 个 DSP 用于乘累加（MAC）计算，加上 12 个用于归约，共 140 个 DSP。

点积模式下的双倍数据率

仅在激活值输入侧应用 DDR 技术，以避免与复杂的操作数打包逻辑产生冲突。采用 输入驻留数据流 结合 DSP 内部预取 机制：激活值通过 B 级联链从底部开始加载到各个 DSP。利用 B 输入路径上的两级流水线寄存器，每个 DSP 可以暂存两个 12 位激活值。DDR 切换由 DSP 内部的复用器处理，并通过 INMODE[4] 信号进行控制。

DSP链的加载与激活值锁定

加载一条DSP链需要8个慢时钟周期（或16个快时钟周期）。由于激活值在矩阵乘法（MatMul）期间会长时间驻留在DSP中，因此这部分加载开销对整体性能的影响可以忽略不计。在所有DSP链的B流水线寄存器加载完成后，通过清除B1和B2寄存器的时钟使能信号，即可锁定激活值。这种设计使得每条DSP链仅需在链的起始位置放置一个基于查找表（LUT）的变速箱，如图5D所示。

AXPY模式下的双倍数据率

在AXPY模式下，所有DSP共享同一个激活值 a。该激活值流经B寄存器流水线，沿着脉动阵列路径广播相同的数值。此时，双倍数据率（DDR）技术依然适用：通过控制INMODE[4]信号，可以在快时钟域内交错加载两组不同的AXPY因子。

在输出方面，AXPY模式需要在原地累加结果。然而，每个DSP只有一个P寄存器，而两个不同的AXPY结果需要交替进行存储和更新。为此，设计团队利用了DSP中未使用的C寄存器，将P端口的输出路由回C输入端口，从而形成一个“C寄存器-加法器-P寄存器”的环形累加结构，如图5E所示。这个循环使得两个AXPY结果的交替更新完全在DSP内部完成，仅消耗额外的布线资源，而无需额外的LUT或触发器开销。

AXPY结果的卸载

AXPY模式下，每个DSP会产生两个独立的结果，这些结果无法跨DSP链进行合并。如果简单地从每个DSP的P端口直接读取输出，会导致极高的扇出，并且数据需要经过序列化后才能送入标量引擎进行处理。

团队采用了一个三级序列化方案来解决此问题，如图5F所示。

• 第一级：链内卸载。首先，重用P级联路径进行数据卸载：禁用后加器，并使能Z复用器仅选择来自级联的P输入，从而形成一条干净的卸载路径。AXPY结果沿着这条路径，在链内向上逐元素移位至顶部的DSP。这一步骤为每条DSP链产生一个包含16个元素的突发数据（系统中共有16条链）。
• 第二级：链间归约。为进一步序列化，团队重新利用了第一级归约DSP，将16组长度为16的突发数据，转换为8组长度为32的突发数据。
• 第三级：完全序列化。接着，使用SRLC32E移位寄存器原语来存储从归约DSP卸载的AXPY结果。然后，利用可配置逻辑块（CLB）中的F7/F8/F9复用器进行最终的序列化操作，最终产生一个包含256个AXPY输出的、完全序列化的数据流，供后续计算单元使用。

所有这些序列化组件都集成在一个CLB内部，网络或逻辑延迟极小，因此完全能够以双倍时钟速率运行。

表3对比了不同的GEMV引擎设计方案。该表从精度配置、运算支持、LUT、FF、DSP资源占用等多个维度，对比了两款经典方案与本文的GEMV引擎设计。本文方案实现了W4KV8A12双精度计算，并支持AXPY运算，DSP占用仅140个，远低于前两者，同时还实现了更高的MAC运算密度。这直观地量化了本研究对GEMV引擎的极致优化效果，为在低资源FPGA上部署多令牌处理器奠定了核心计算基础。

Hummingbird+的GEMV引擎实现了最高的MAC密度，在KV8精度下是基准的2倍，在W4精度下是4倍，同时使用了最少的DSP。括号中额外的LUT和FF使用来自精度切换和脉动触发器，这些资源在多个GEMV引擎之间是共享的。

4.2 标量引擎的资源节约技巧

标量引擎负责接收来自GEMV引擎的点积（DOT）或AXPY输出，将定点结果转换为FP16格式（反量化），执行一系列特殊函数运算，然后将FP16输出再转换回定点整数（动态量化），最后送回激活缓冲区供下一次矩阵乘法使用。

图6展示了标量引擎的整体架构及资源共享优化设计。该图分为三部分：首先呈现核心功能模块与数据流向；其次统计各模块的浮点计算资源需求；最后设计了资源共享电路，通过时间占用分析与模块间资源复用，大幅削减了标量引擎的DSP占用，使其能够适配边缘FPGA的有限资源。

实现标量引擎主要有两种方法：一是采用覆盖法构建全功能单元，通过指令集来编排资源执行操作；二是采用数据流法，为每个特定算子设计专用的流水线逻辑。Hummingbird+选择了后者以确保执行效率。

标量引擎中的各子模块功能及互连如图6A所示：

• RMSNorm模块：接收查询（q）或键（k）投影输出进行qk归一化，或接收残差输出进行注意力后的归一化。
• ResAdd模块：接收注意力输出（o）投影或最终的MoE输出，进行残差加法。
• MoE-Update模块：接收下投影输出和路由器模块的专家分数，逐专家迭代更新MoE结果。
• Softmax模块：接收qk点积输出或路由器投影输出，返回MoE专家分数或注意力分数。
• UGMul-SiLU模块：融合上投影（up）和门控（gate）投影输出之间的元素乘法与SiLU激活函数。
• 动态量化单元：将FP16格式的激活值转换为FIX12定点格式。

标量引擎的资源节约主要体现在两个层面：

层面一：FP16乘法器的打包与DDR技术

与GEMV引擎类似，对标量引擎中的16位浮点乘法器也应用了操作数打包和双倍数据率技术。一个16位浮点数乘法通常需要两个DSP，通过打包操作可以减少一半的DSP使用量。

层面二：算子级资源共享

通过详细分析数据的时间依赖性和各算子的资源占用情况，可以实现有效的算子级资源共享。如图6B（左侧）所示，通过分析各算子的时间占用窗口，可以在不同算子之间共享计算资源，从而大幅减少总体资源需求。

如图6C（右侧）所示，资源共享电路通过独热编码（one-hot）和或门（OR gate）来实现多个输入通道的复用。最终，标量引擎的资源占用被降低到不足6K LUT和仅7个DSP，在支持所有LLM所需特殊函数的同时，其执行时间可以完全隐藏在矩阵乘法的周期之内。

五、实验评估

5.1 平台设计选择

定制平台在大规模生产时的物料成本预计低于150美元，其中内存（RAM）和存储设备占据了近一半的成本，而FPGA芯片本身仅占约30%。这意味着即使未来更换为更便宜的专用集成电路（ASIC），对整体物料清单成本的影响也相对有限。

图8展示了定制平台的物料清单。该图列出了Hummingbird+定制PCB的核心物料成本构成，明确了XCZU2CG/3EG FPGA、内存、存储等核心组件的单价，最终实现了量产物料成本低于150美元的目标，突破了传统FPGA加速器高成本的瓶颈，为边缘产品的商业化落地提供了成本可行性依据。

5.2 资源消耗

研究团队在XCZU2CG和XCZU3EG两款FPGA上部署了不同并行度的Hummingbird+系统。XCZU2CG（47K LUT，240个DSP）可以容纳2个令牌处理器，而XCZU3EG（70K LUT，360个DSP）可以容纳4个。

图9量化展示了Hummingbird+在两款入门级FPGA上的资源占用与布局情况。该图表明，XCZU2CG可部署2个令牌处理器，XCZU3EG可部署4个，且设计均将芯片的资源利用率推至极限，验证了加速器设计的资源高效性，也为不同成本需求的边缘部署提供了芯片选型参考。

每个令牌处理器需要一个标量引擎（占用7个DSP）并访问一个GEMV引擎。单个GEMV引擎消耗140个DSP并以双倍数据率运行（并行度M=2），因此通过时分复用的方式，它可以提供2个虚拟的单令牌GEMV计算实例。最终的系统配置如下：

• XCZU2CG：2个令牌处理器 ⇒ 2个标量引擎 + 1个GEMV引擎
• XCZU3EG：4个令牌处理器 ⇒ 4个标量引擎 + 2个GEMV引擎

5.3 性能对比

表6列出了用于性能对比的基准平台规格。该表精准罗列了Jetson AGX Orin、酷睿i9-13900KF CPU与XCZU3EG FPGA三款平台的核心硬件规格，涵盖内存类型与容量、带宽、成本、算力及功耗等维度，为Hummingbird+的性能对比提供了统一的硬件参数参照。该表直观地凸显出XCZU3EG平台在同等带宽下，其成本和功耗远低于另外两款平台的核心优势，这是验证其边缘部署性价比的关键量化依据。

下图展示了与嵌入式 GPU 和 CPU 的对比。XCZU3EG 在解码速度上达到了 Jetson AGX Orin 的一半以上，但仅使用了其 17% 的带宽，实现了 7 倍的 token-per-dollar 效率和 1.7 倍的能效比。与现有嵌入式 FPGA 加速器相比，Hummingbird+ 在最小的设备上运行最大的 LLM，同时实现了预填充加速，解码性能领先。

图 10：与商用 CPU 和嵌入式 GPU 的解码和预填充速度对比。该图通过实测对比了 Hummingbird+ 与 i9-13900KF、Jetson AGX Orin 的解码和预填充速度，展现出在相同带宽下解码吞吐量是 DDR4-CPU 的近 2 倍，虽预填充速度略低于 Orin，但成本和功耗优势显著。

表 5：与 SOTA FPGA 的大语言模型加速器对比表。该表对比了本研究与 12 项现有研究的 FPGA 加速器，从平台、模型、压缩方式、性能等多维度量化分析。本研究在入门级 FPGA 上部署了最大的 30B MoE-LLM，且同时支持预填充与解码加速，解码性能居嵌入式 FPGA 加速器首位。

六、局限性与未来展望

尽管 Hummingbird+ 取得了令人印象深刻的成果，研究团队也坦诚地讨论了其局限性，并展望了未来的发展方向。

• 可扩展性：定制平台可进一步扩展到 8+32=40GB 内存，足以容纳最新的 Qwen3-Next-80B-A3B 的 INT4 版本。更广泛地说，FPGA 的可扩展性源于其灵活的 HP banks，可以作为胶合芯片集成大容量 RAM 以支持 MoE LLM。例如，KU040 可以接口 160 位 DDR4，支持高达 72GB 内存。通过先进 FPGA 中的 SerDes，扩展到多 FPGA 系统也是可行的。
• 适应性：在低成本 FPGA 上实现 LLM 的关键是手工优化的 RTL 设计。基于覆盖层的 DPU、HLS 和编译器驱动的方法无法达到这种细粒度效率，迫使使用更昂贵的 FPGA 来容纳冗余逻辑。幸运的是，LLM 架构相对稳定，模型适应性比 CNN 或 ViT 更容易，这为自动化工具生成 LLM 加速器的优化 RTL 提供了机会。
• 与 ASIC 的竞争：研究表明，MoE LLM 所需的 RAM 和存储成本已经超过 FPGA 本身。虽然 ASIC 可以提供更高的计算 FLOPs，但解码阶段仍然是内存受限的。如果 FPGA 在边缘 LLM 部署中被证明可行，且 ASIC 在芯片成本和 FLOPs 不再是瓶颈时无法提供显著优势，那么在 LLM 快速演进的背景下，ASIC 的吸引力可能会降低。

结论

Hummingbird+ 首次证明了低成本 FPGA 可以作为 LLM 部署的实用且具有成本效益的最终实现介质。

通过极致的资源优化，在入门级 Zynq UltraScale 器件上实现了 30B MoE 模型的流畅推理。定制平台的物料成本低于 150 美元，解码速度超过 18 token/s，预填充速度超过 50 token/s，在 token-per-dollar 效率和能效比上均优于 Jetson AGX Orin 等商业方案。

这项工作不仅将基于 FPGA 的 LLM 部署从研究原型推进到边缘产品阶段，也为未来 LLM 的硬件加速提供了新的思路：在内存受限的 LLM 推理场景中，FPGA 凭借其灵活的 I/O 和内存连接能力，以及可定制化的计算架构，找到了自己独特的优势位置。

关注“鲸栖”小程序，掌握最新AI资讯