Hummingbird+ 深度解析：150美元 FPGA 上的 300 亿参数 MoE 大模型
Hummingbird+ 深度解析：150美元 FPGA 上的 300 亿参数 MoE 大模型
中科院的工程师们做了一件看似疯狂的事：他们把一个 300 亿参数的混合专家大模型（MoE）塞进了一块售价 150 美元的入门级 FPGA 芯片，实现了 18 token/s 的流畅对话速度。这不是实验室的炫技，而是一个可以量产的产品级方案。
导读：边缘 AI 的"不可能四角"
在边缘部署大语言模型，工程师们一直面临一个残酷的四选三困境：
| 维度 | 现状 |
|---|---|
| 💰 成本 | 云端 A100 月租 > \(1000，Jetson AGX Orin 开发板 >\)1500 |
| 🤖 模型规模 | 7B 稠密模型尚可，30B+ 模型几乎不可能 |
| ⚡ 性能 | 解码速度 < 10 tok/s，体验卡顿 |
| 📦 功耗/体积 | 高性能 GPU 动辄 300W+，需要主动散热 |
提升其中一个，往往以牺牲其他为代价。但中科院自动化所的 Hummingbird+ 团队打破了这一定律——在 **\(150 成本** 的平台上，同时实现了 **30B MoE 模型**、**18 tok/s 解码速度** 和 **可产品化设计**。
---
## 一、为什么是 FPGA？
### 1.1 FPGA 的尴尬定位
FPGA（现场可编程门阵列）在 AI 硬件加速领域一直处于微妙的位置：
- **不如 GPU 算力强**：一块 H100 有 989 TFLOPS 的 FP16 算力，高端 FPGA（如 Alveo U280）只有 8-20 TFLOPS
- **不如 ASIC 能效高**：一旦流片，ASIC 的每瓦性能碾压 FPGA
- **编程复杂度极高**：Verilog/VHDL 的学习曲线陡峭，HLS（高层次综合）生成的电路效率低下
### 1.2 LLM 推理改变游戏规则
但 LLM 推理有一个关键特性：**内存受限而非计算受限**。
```
┌────────────────────────────────────────────────────────────────┐
│ 计算密集型 vs 内存密集型 │
├────────────────────────────────────────────────────────────────┤
│ │
│ Transformer 训练 LLM 推理（特别是解码阶段） │
│ ───────────────── ───────────────────────── │
│ 矩阵乘法 (N³) 矩阵-向量乘法 (GEMV) │
│ 计算瓶颈：算力 计算瓶颈：内存带宽 │
│ GPU 优势区 接近内存墙 │
│ │
│ 需要：高 TFLOPS 需要：高带宽 + 低延迟 │
│ 适合：GPU/TPU FPGA 有机会！ │
│ │
└────────────────────────────────────────────────────────────────┘
```
LLM 解码阶段的核心操作是**广义矩阵-向量乘法（GEMV）**：输入是一个 token 的嵌入向量（几千维），乘以巨大的权重矩阵。这种情况下，瓶颈不是乘法器数量，而是**从内存读取权重的速度**。
FPGA 的优势恰好在这里：
- **灵活的内存接口**：可以配置为宽度、频率、通道数最优的 DDR 控制器
- **低延迟片上存储**：BRAM/URAM 用于缓存激活值，减少外部内存访问
- **数据流架构**：没有 GPU 的 warp 调度开销，每条数据路径可定制
---
## 二、MoE：FPGA 的天然盟友
### 2.1 混合专家模型的秘密
MoE（Mixture of Experts）是一种稀疏激活架构：
```
┌────────────────────────────────────────────────────────────────┐
│ MoE 层工作原理 │
├────────────────────────────────────────────────────────────────┤
│ │
│ Input Token │
│ │ │
│ ▼ │
│ ┌───────────┐ │
│ │ Router │ ──► Softmax 计算所有专家的得分 │
│ │ (门控网络)│ │
│ └─────┬─────┘ │
│ │ │
│ ▼ │
│ Top-K 专家选择 (通常 K=8) │
│ │ │
│ ┌────┴────┬────────┬────────┬────────┬────────┐ │
│ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │E 1 │ │E 2 │ │E 3 │ │ ...│ │E128│ │... │ │
│ │专家│ │专家│ │专家│ │ │ │专家│ │ │ │
│ └─┬──┘ └─┬──┘ └─┬──┘ └────┘ └─┬──┘ └────┘ │
│ │ │ │ │ │
│ └────────┴────────┴─────────────────┘ │
│ │ │
│ ▼ │
│ Weighted Sum (按 Router 得分加权) │
│ │ │
│ ▼ │
│ Output Token │
│ │
└────────────────────────────────────────────────────────────────┘
```
关键洞察：**总参数量 ≠ 激活参数量**。
| 模型 | 总参数量 | 激活参数量 | 稀疏度 |
|------|----------|-----------|--------|
| Qwen3-30B-A3B | 30.5B | 3.3B | ~90% |
| 传统稠密模型 | 7B | 7B | 0% |
虽然 MoE 模型总参数量更大，但每个 token 只激活一小部分（如 128 个专家中选 8 个）。这意味着**内存访问工作负载**与小型稠密模型相当——正好落在低成本 DDR 硬件的舒适区。
### 2.2 为什么是 Qwen3-30B-A3B
Hummingbird+ 选择 Qwen3-30B-A3B 的原因：
| 特性 | 数值 | 意义 |
|------|------|------|
| 总参数量 | 30.5B | 大模型能力 |
| 激活参数量 | 3.3B | 实际计算负载可控 |
| 专家数 | 128 | 高稀疏度 |
| 每层激活专家 | 8 | 内存访问可预测 |
| GQA（分组查询注意力） | 32Q/4KV | 降低 KV 缓存压力 |
| GPTQ 4-bit 量化后 | 14.52GB | 落入 24GB 内存预算 |
加上 16K 上下文的 KV 缓存（0.77GB），总内存需求约 15.29GB，完美适配平台。
---
## 三、硬件平台：150美元能买到什么
### 3.1 定制 PCB 设计
```
┌────────────────────────────────────────────────────────────────┐
│ Hummingbird+ 硬件平台 │
├────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Zynq UltraScale+ MPSoC │ │
│ │ ┌─────────────────┐ ┌─────────────────────────────┐ │ │
│ │ │ Processing │ │ Programmable Logic (PL) │ │ │
│ │ │ System (PS) │ │ │ │ │
│ │ │ │ │ • LUT: 47K (XCZU2CG) │ │ │
│ │ │ • Quad-core │ │ 70K (XCZU3EG) │ │ │
│ │ │ Cortex-A53 │ │ • DSP: 240 / 360 │ │ │
│ │ │ • Dual-core │ │ • BRAM: ~4.5 Mb │ │ │
│ │ │ Cortex-R5F │ │ │ │ │
│ │ │ • Mali-400 GPU │ │ 这是加速器所在位置！ │ │ │
│ │ └────────┬────────┘ └──────────────┬──────────────┘ │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ ┌─────────┐ ┌──────────────┐ │ │
│ │ │ 8GB │ │ 16GB │ │ │
│ │ │ DDR4 │ │ DDR4 │ │ │
│ │ │ (板载) │ │ (SODIMM) │ │ │
│ │ │ PS侧 │ │ PL侧 双通道 │ │ │
│ │ └─────────┘ └──────────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 额外接口： │
│ • M.2 NVMe (128GB SSD) ← 存储大模型权重 │
│ • PCIe 2.0 │
│ • Gigabit Ethernet │
│ • USB 3.0 │
│ │
└────────────────────────────────────────────────────────────────┘
```
### 3.2 成本拆解
| 组件 | 估计成本 | 占比 |
|------|----------|------|
| XCZU2CG/3EG FPGA | ~\)45 | 30% |
| 24GB DDR4 (8+16) | \(75 | 50% |
| PCB + 电源 + 其他 | ~\)30 | 20% |
| 总计 | **\(150** | 100% |
内存占了一半成本——这是关键洞察：**在 MoE LLM 部署中，存储成本已经超过计算芯片本身**。这也意味着即使换成 ASIC，成本降低空间也有限，除非 DRAM 价格下降。
### 3.3 带宽优势
PL 侧双通道 DDR4 提供 **34GB/s** 的峰值带宽：
| 平台 | 内存类型 | 峰值带宽 | 内存容量 | TDP |
|------|----------|----------|----------|-----|
| Jetson AGX Orin | LPDDR5 | 204GB/s | 32GB | 60W |
| Hummingbird+ | DDR4 | 34GB/s | 24GB | ~10W |
| 比例 | 0.17x | 0.17x | 0.75x | 0.17x |
虽然带宽只有 Jetson 的 17%，但关键是**带宽利用率**——Hummingbird+ 通过架构优化实现了接近 100% 的理论带宽利用率，而 Jetson 的利用率通常只有 60-70%。
---
## 四、架构创新：Token Processor
### 4.1 传统设计的缺陷
现有 FPGA LLM 加速器通常采用粗粒度三模块设计：
```
┌────────────────────────────────────────────────────────────────┐
│ 传统 FPGA LLM 加速器 │
├────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 矩阵引擎 │───▶│ 非线性单元 │───▶│ 内存管理器 │ │
│ │ (GEMM/GEMV) │ │ (SiLU/Softmax)│ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ 问题： │
│ 1. 计算形状不匹配 → 矩阵引擎尺寸不匹配导致利用率低 │
│ 2. 流水线粒度不足 → 解码对延迟敏感，粗粒度设计浪费周期 │
│ 3. 模块间耦合松散 → 非线性单元过度配置，资源浪费 │
│ │
└────────────────────────────────────────────────────────────────┘
```
### 4.2 Token Processor：紧凑的端到端流水线
Hummingbird+ 提出了全新的 **Token Processor** 架构：
```
┌────────────────────────────────────────────────────────────────┐
│ Token Processor 架构 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 每个 Token Processor 包含： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌───────────┐ │ │
│ │ │ GEMV 引擎 │───▶│ 标量引擎 │───▶│ 激活缓冲区 │ │ │
│ │ │ 140 DSP │ │ 7 DSP │ │ BRAM │ │ │
│ │ │ 272 GOPs │ │ (所有非线性)│ │ │ │ │
│ │ └─────────────┘ └─────────────┘ └───────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 多处理器并行架构： │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Token │ │ Token │ │ Token │ │ Token │ │
│ │ Proc #0 │ │ Proc #1 │ │ Proc #2 │ │ Proc #3 │ │
│ │ (主) │ │ (从) │ │ (从) │ │ (从) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ └─────────────┴─────────────┴─────────────┘ │
│ │ │
│ ▼ │
│ 共享内存总线 (DDR4) │
│ │
│ 预填充阶段：所有处理器并行计算不同 token │
│ 解码阶段：主处理器执行完整流程，从处理器分担 GQA 计算 │
│ │
└────────────────────────────────────────────────────────────────┘
```
这种设计的精妙之处：
- **预填充阶段**：所有 Token Processor 并行工作，计算独立 token 的注意力
- **解码阶段**：采用主从协作——主处理器执行完整流程（注意力 + MLP），从处理器分担 GQA 工作负载
---
## 五、GEMV 引擎：140 个 DSP 的艺术
### 5.1 双精度操作数打包
GEMV 引擎的核心挑战：用有限的 DSP 实现高效的低精度计算。
```
┌────────────────────────────────────────────────────────────────┐
│ Xilinx DSP48E2 架构 │
├────────────────────────────────────────────────────────────────┤
│ │
│ DSP48E2 是一个乘法-累加单元： │
│ │
│ P = (A + D) × B + C 或 P = A × B + C │
│ │
│ 输入宽度： │
│ • A: 30-bit • B: 18-bit • C: 48-bit • D: 27-bit │
│ │
│ Hummingbird+ 的 W4A12/KV8A12 打包方案： │
│ │
│ W4 模式（权重4位，激活12位）： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ A端口(30位) │ D端口(27位) │ │
│ │ ┌─────────┬─────────┐ │ ┌─────────┬──────────────────┐ │ │
│ │ │ sign │ weight1 │ │ │ weight2 │ padding │ │ │
│ │ │ (4bit) │ (4bit) │ │ │ (4bit) │ (23bit) │ │ │
│ │ └─────────┴─────────┘ │ └─────────┴──────────────────┘ │ │
│ │ │ │ │
│ │ B端口(18位): activation (12-bit) + padding │ │
│ │ │ │
│ │ 计算: (sign_ext(w1) + w2) × act = w1×act + w2×act │ │
│ │ │ │
│ │ 一次乘法得到两个权重×激活的结果！ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ KV8 模式（键值8位）： │
│ • A 端口通过 INMODE[1] 门控为零 │
│ • D 端口承载完整 8 位数据 │
│ • 使用 5 个 2 选 1 MUX 进行精度切换（低 LUT 开销） │
│ │
└────────────────────────────────────────────────────────────────┘
```
**+1 修正项的消除**：有符号整数打包需要处理负数乘法的 +1 修正。Hummingbird+ 巧妙地将修正项吸收到 DSP 的四输入后加器中，通过配置 W 复用器的常数舍入因子实现，**消除了额外的 LUT 逻辑**。
### 5.2 链-树混合归约架构
```
┌────────────────────────────────────────────────────────────────┐
│ GEMV 引擎并行架构 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 并行度 K=128，通过 DDR 实现 M=2 │
│ │
│ DSP 链（8个DSP为一组，共16条链）： │
│ │
│ DSP Chain 0: [DSP]─▶[DSP]─▶[DSP]─▶...─▶[DSP] (8个) │
│ │ │ │
│ DSP Chain 1: [DSP]─▶[DSP]─▶[DSP]─▶...─▶[DSP] │
│ │ │ │
│ ... (部分和) │
│ │ │ │
│ DSP Chain 15: [DSP]─▶[DSP]─▶[DSP]─▶...─▶[DSP] │
│ │ │
│ 第一级归约（4个 4-1 归约单元，SIMD=2）： │
│ │ │ │
│ ▼ ▼ │
│ [Reduct Unit] [Reduct Unit] [Reduct Unit] [Reduct Unit] │
│ │ │ │ │ │
│ └──────────────┴──────────────┘ │ │
│ │ │ │
│ 第二级归约（2个 4-1 归约单元，SIMD=1）： │
│ ▼ ▼ │
│ [Reduct Unit] [Reduct Unit] │
│ │ │ │
│ └────────────┬────────────────┘ │
│ │ │
│ ▼ │
│ 最终输出 │
│ │
│ 总计：128 MAC DSP + 12 归约 DSP = 140 DSP │
│ │
└────────────────────────────────────────────────────────────────┘
```
### 5.3 性能数据
| 指标 | 数值 |
|------|------|
| 时钟频率 | 532 MHz |
| MAC 运算 | 272 GOP/s |
| LUT 消耗 | < 1K |
| DSP 消耗 | 140 |
| 计算密度（vs 前代） | **4x** (W4 模式) |
---
## 六、标量引擎：7 个 DSP 的魔术
### 6.1 功能清单
标量引擎负责所有非线性运算：
- RMSNorm（查询/键归一化、注意力后归一化）
- 残差加法
- MoE-Update（专家加权求和）
- Softmax（注意力分数、路由分数）
- UGMul-SiLU（上投影与门控融合）
- 动态量化（FP16 → INT12）
### 6.2 资源共享：时间维度上的复用
```
┌────────────────────────────────────────────────────────────────┐
│ 标量引擎资源时分共享 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 模块占用时间分析： │
│ │
│ Time ──────────────────────────────────────────────▶ │
│ │
│ RMSNorm: [████████] │
│ ResAdd: [████] │
│ MoE-Update: [████████] │
│ Softmax: [████████████] │
│ UGMul-SiLU: [██████] │
│ │
│ 观察：这些模块在时间上没有重叠！ │
│ │
│ 资源共享方案： │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ FP16 乘法器 (3个) ──▶ 所有模块复用同一组乘法器 │ │
│ │ FP16 加法器 (2个) ──▶ 通过 one-hot 选择输入通道 │ │
│ │ 查表单元 (2个) ──▶ 存储 SiLU/Sigmoid/Exp 表 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 结果：总 DSP 消耗仅 7 个！ │
│ │
└────────────────────────────────────────────────────────────────┘
```
### 6.3 执行时间隐藏
标量引擎的执行可以完全隐藏在 GEMV 计算时间内——这意味着**非线性运算不会成为瓶颈**。
---
## 七、系统配置与性能
### 7.1 两种芯片配置
| 配置 | XCZU2CG | XCZU3EG |
|------|---------|---------|
| LUT | 47K | 70K |
| DSP | 240 | 360 |
| Token Processor | 2个 | 4个 |
| GEMV 引擎 | 1个（时分复用） | 2个 |
| 标量引擎 | 2个 | 4个 |
### 7.2 性能对比
**与 Jetson AGX Orin 对比**：
| 指标 | Hummingbird+ (XCZU3EG) | Jetson AGX Orin | 比值 |
|------|------------------------|-----------------|------|
| 成本 | ~\)150 | ~\(1500 | **0.1x** |
| 解码速度 | 18 tok/s | ~35 tok/s | 0.51x |
| 带宽利用率 | ~100% | ~60% | **1.67x** |
| Token-per-dollar | 0.12 | 0.023 | **5.2x** |
| 能效比 | 1.8 tok/s/W | 1.1 tok/s/W | **1.6x** |
| 内存容量 | 24GB | 32GB | 0.75x |
| TDP | ~10W | ~60W | **0.17x** |
**与现有 FPGA 加速器对比**：
| 工作 | 平台 | 模型 | 压缩 | 预填充 | 解码 | 支持 |
|------|------|------|------|--------|------|------|
| FlightLLM'24 | VCU128 | LLaMA2-7B | 4-bit | ❌ | 7.7 | 仅解码 |
| TeraFly'25 | 4×U280 | OPT-30B | 16-bit | ✅ | - | 多节点 |
| LoopLynx'25 | U55C | LLaMA2-7B | 4-bit | ✅ | 8.8 | - |
| **Hummingbird+** | **XCZU3EG** | **Qwen3-30B-A3B** | **4-bit** | **✅ 50** | **18** | **✅** |
### 7.3 关键成就
- **首次**在嵌入式 FPGA 上部署 30B MoE 模型
- **首次**在低成本 FPGA 上同时支持预填充和解码加速
- **最高**的嵌入式 FPGA 解码性能
- **最低**的每 token 成本
---
## 八、局限性与未来展望
### 8.1 当前局限
1. **内存依赖**：DDR4 占 BOM 成本 50%，涨价会削弱优势
2. **RTL 手工优化**：模型架构变化需要重新设计（虽然 Transformer 架构已趋于稳定）
3. **预填充速度**：50 tok/s 对于长输入仍不够快
### 8.2 可扩展性
```
┌────────────────────────────────────────────────────────────────┐
│ 扩展路线图 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 当前：XCZU3EG + 24GB DDR4 │
│ ↓ 扩展至 8+32 = 40GB 内存 │
│ 下一阶段：支持 Qwen3-Next-80B-A3B (INT4) │
│ │
│ 更远期： │
│ • KU040 (160-bit DDR4) → 72GB 内存 │
│ • 多 FPGA 系统 (通过 SerDes 互联) │
│ • CXL 内存扩展 │
│ │
└────────────────────────────────────────────────────────────────┘
```
### 8.3 与 ASIC 的竞争
**关键洞察**：在 MoE LLM 中，RAM 和存储成本已经超过 FPGA 芯片本身。即使 ASIC 能提供更高算力，解码阶段仍是内存受限的。
如果 FPGA 在边缘 LLM 部署中被证明可行，而 ASIC 无法在芯片成本和 FLOPs 上提供显著优势，那么在 LLM 架构快速演进的背景下，**ASIC 的吸引力可能会降低**。
---
## 九、工程启示
### 9.1 设计哲学
Hummingbird+ 体现了几条深刻的工程原则：
1. **问题匹配**：FPGA 不是万能药，但在内存受限场景下有其独特位置
2. **极致优化**：手工 RTL 虽然费时，但在资源受限场景下是必需的
3. **成本优先**：边缘部署的第一约束是成本，不是性能
4. **架构稳定**：LLM 架构（Transformer + MoE）已趋于稳定，专用优化有价值
### 9.2 对 AI 硬件的启示
```
┌────────────────────────────────────────────────────────────────┐
│ AI 硬件发展路线 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 云端训练 云端推理 边缘推理 │
│ ───────── ───────── ───────── │
│ GPU (NVIDIA) ASIC (TPU) FPGA/ASIC? │
│ 高算力 高能效 低成本 │
│ 高成本 中等成本 超低功耗 │
│ │
│ Hummingbird+ 证明：边缘推理可以是 FPGA 的甜点场景 │
│ │
│ 关键区别： │
│ • 云端追求 TFLOPS/W（算力能效） │
│ • 边缘追求 tokens/\)（成本效率） │
│ │
└────────────────────────────────────────────────────────────────┘
---
## 十、总结
Hummingbird+ 是一项里程碑式的工作：
| 维度 | 突破 |
|------|------|
| **成本** | $150 BOM，首次证明低成本 FPGA 可产品化部署 LLM |
| **规模** | 30B MoE，现有 FPGA 加速器中最大模型 |
| **性能** | 18 tok/s 解码，50 tok/s 预填充，流畅可用 |
| **能效** | 1.7x 于 Jetson AGX Orin，1.8 tok/s/W |
它告诉业界：**边缘 AI 不只有 GPU 和 ASIC 两条路**。在特定的技术约束下（内存受限、架构稳定、成本敏感），FPGA 可以是那个被忽视的"第三选择"。
更重要的是，它证明了**中国团队在 AI 硬件架构设计上的世界级水平**——从芯片选型、PCB 设计、RTL 优化到系统整合，全流程的工程能力展现无遗。
---
**参考链接**：
- 论文：ACM/SIGDA FPGA 2026, https://dl.acm.org/doi/10.1145/3748173.3779189
- 前代工作：Hummingbird (arXiv:2507.03308)
- Qwen3 模型：https://modelscope.cn/models/Qwen/Qwen3-30B-A3B
- 会议信息：https://www.isfpga.org/program/
---
*"蜂鸟虽小，振翅却可达每秒 80 次。Hummingbird+ 亦如此——在有限资源中，通过极致优化，实现看似不可能的性能。"*
#Hummingbird #FPGA #LLM #MoE #边缘AI #Qwen3 #硬件加速 #小凯
讨论回复
0 条回复还没有人回复，快来发表你的看法吧！
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。