gateGPT：在 FPGA 上用硬件 RTL 跑 Transformer，每秒 69000 个 token

当所有人都在讨论用 H100 集群跑万亿参数模型时，有人用 Verilog 把一个完整的 Transformer 推理引擎写进了一块 2006 年的 Virtex-5 FPGA 里——80 MHz 主频，每秒吐出 69000 个 token。

这不是学术论文里的理论推演，而是一个已经在开发板上跑起来的实物：名字在 LCD 屏幕上一行一行地滚出来。gateGPT 是 Andrej Karpathy 的 microGPT 的硬件复刻版，用纯 RTL（寄存器传输级）代码实现了 Transformer 的全部推理流程，没有软处理器、没有嵌入式 OS、没有任何软件层。

一、为什么要在 FPGA 上跑 Transformer？

这个问题的答案不是“因为它更快”——GPU 在大模型推理上的吞吐量远超任何 FPGA。gateGPT 的意义在于另一个维度：

它证明了 Transformer 架构可以被完整地映射到硬件逻辑门上。

这件事听起来理所当然，但实际做起来要解决的问题远比想象中多。Transformer 的核心运算是矩阵乘法、softmax、层归一化，这些在 GPU 上有高度优化的 CUDA kernel，但在 RTL 层面，每一个运算都要自己设计数据通路、定点数格式、时序约束。

gateGPT 的作者 Fabio Guzman（GitHub: fguzman82）选择了一条极其硬核的路线：不用 HLS（高层次综合），不用 SystemVerilog 的高级特性，而是用 Verilog-2001 手写每一个模块。最终交付的设计只有 ~45 万等效门电路，占用 62 个 DSP 单元和 2 个 Block RAM，在 Virtex-5 上以 80 MHz 稳定运行。

二、模型有多大？

先说清楚——这个模型极小。它是 Karpathy 在 minGPT 里用来生成名字的字符级模型：

参数	值
Transformer 层数	1
注意力头数	4
每头维度	6
嵌入维度	24
MLP 隐藏维度	96
上下文长度	16 个字符
词表大小	27（`a`-`z` + `.`）
数值格式	Q5.11 定点数（16-bit）

这个规模在今天的 LLM 语境下几乎可以忽略不计——它连一个完整的英语句子都处理不了，只能逐字符生成短名字。但正是这种极简性，让完整的 Transformer 推理流程得以在单块 FPGA 上实现，同时保留了架构的所有核心组件：多头因果注意力、KV Cache、RMSNorm、softmax 采样。

三、微码序列器：用软件思维做硬件

gateGPT 最有工程美感的设计是它的控制层。不同于传统的 RTL 设计——每个模块用状态机硬编码控制流，gateGPT 采用了一种类 CPU 的微码序列器（microcode sequencer）架构：

微码 ROM 存储推理流程的完整指令序列
序列器 每个周期取出一条微指令，解码后驱动数据通路
数据通路模块（embed、norm、matvec、attn、exp、sampler）是纯粹的执行单元，不含自己的状态机

这意味着推理流程的修改不需要重写硬件——只需更新微码 ROM 的内容。这种设计在硬件加速器中并不罕见（GPU 的指令调度也用类似思路），但用在如此小规模的 FPGA 设计上，体现了作者对可维护性的重视。

四、9 次迭代，28 倍提速

gateGPT 的优化过程是这个项目最值得学习的部分。作者公开了完整的 9 次迭代记录，从最初的 2433 tok/s 一路优化到 69204 tok/s：

最大的单项提升来自 KV Cache（3.2 倍）。初始版本每生成一个新 token 都要重新计算整个上下文的注意力，这意味着上下文越长、计算量越大。引入增量解码后，每次只需要计算新 token 的 K/V，然后和缓存的历史 K/V 做注意力。对于一个 16 字符上下文的模型，这直接把周期数从 32872 砍到了 10192。

第二大提升来自并行 MAC 单元（3.7 倍）。矩阵-向量乘法是 Transformer 推理中最密集的运算。作者设计了一个 24 路并行的 systolic 阵列，每个周期处理 24 个乘累加操作。这个设计用掉了 Virtex-5 上 64 个 DSP48E 中的 48 个——DSP 是这个设计的瓶颈资源，利用率达 96%。

后续的优化（并行除法器、操作数流水线）每次带来 1.5 倍左右的提升，都是微架构层面的精细调整。

五、工程踩坑：那些 README 里不会写的事

作者在 README 里分享了几个极具实战价值的经验：

1. BRAM 模板选错会导致时序崩溃。 后综合报告显示 80 MHz 可达，但布局布线后暴跌到 35 MHz。原因是用了错误的 Block RAM 推断模板，导致关键路径上的布线延迟暴涨。

2. 在长 BRAM 到 DSP 路径中间插一级寄存器。 最终版本距离 80 MHz 目标差 0.14 ns，在 matvec 和 scratchpad 之间加了一个流水线寄存器就解决了。这是 FPGA 设计中最常见的优化手法——但只有在时序报告精确到皮秒级时才会注意到。

3. XST 14.7 的已知 bug。 $readmemh 加载的 ROM 会被综合器静默优化为全零。解决方案是用组合逻辑的 case 函数代替。同样，活跃的寄存器可能被常量折叠优化掉——需要用 (* keep = "true" *) 属性强制保留。

4. 整数运算的并行性是免费的。 Radix-4 除法器和分裂式 MAC 阵列保证了结果的 bit-exact 一致性，不需要额外的舍入或对齐逻辑。

六、FPGA 资源利用

资源	已用	可用	利用率
Slice LUTs	16,548	69,120	23%
Slice Registers	5,530	69,120	8%
DSP48E	62	64	96%
Block RAM	2	148	1%
IOBs	29	640	5%

DSP 是绝对瓶颈。24 路并行 matvec 用掉了 48 个 DSP，剩余的被注意力计算的除法器和采样器瓜分。LUT 和寄存器都有大量余量——这意味着同样的设计在更小的 FPGA（如 Spartan-6）上也能跑，只要 DSP 数量够。

七、这件事的真正意义

gateGPT 不是一个能和 GPU 竞争的推理引擎。它的模型太小、上下文太短、词表太窄，在任何实际应用场景下都不够用。但它的价值不在于此：

它是一个完整的教学案例。 从 Transformer 的数学定义到硬件实现的每一步都是透明的。想理解注意力机制在电路层面是什么样的？看 attn.v。想知道 softmax 的指数函数怎么用查表实现？看 exp_unit.v。想了解 KV Cache 为什么对自回归解码至关重要？看 vmem2.v 里的缓存管理逻辑。

它是 ASIC Transformer 加速器的原型验证。 在流片之前，用 FPGA 验证架构设计是标准流程。gateGPT 的微码序列器 + 数据通路架构可以作为更大规模设计的起点——把模型参数换成真正的 LLM（需要更多的 DSP 和 BRAM），把定点数换成更宽的格式，把单层换成多层。

它挑战了“Transformer 必须用 GPU”的思维定式。 在边缘设备上做 AI 推理是一个活跃的研究方向。虽然当前的边缘 TPU（如 Google Coral、Kendryte K210）已经能跑 CNN，但 Transformer 的注意力机制在硬件实现上有本质不同的挑战。gateGPT 展示了一种可行的路径。

八、局限性

模型只有一个 Transformer block，24 维嵌入，16 字符上下文——离实用差距巨大
没有开源许可证（默认版权保留）
目标板 Virtex-5 是 2006 年的工艺（65nm），今天的 FPGA（如 Versal HBM）性能高出几个数量级
没有与 GPU 的功耗对比数据（虽然 FPGA 在 80 MHz 下功耗必然远低于 GPU）
定点数格式 Q5.11 的精度限制了模型规模的扩展