FPGA独立实现LLM推理方案——FlighLLM

说到独立使用FPGA来完成LLM的推理,近几年有好几种方案,我们一一来解读一下它们。

今天,我们首先想到的应该是几年前的FlightLLM。确切时间应该是:2024年1月,算是最早的采用FPGA来实现推理的方案了。

论文原文:https://arxiv.org/abs/2401.03868

1: 解决问题

论文首先提出,现在用GPU做推理存在的问题:

现有 GPU 和 Transformer 专用加速器在处理压缩后的 LLM 时仍然效率不高,主要存在三个尚未解决的问题:计算效率低、内存带宽利用不足、编译开销大。

2: 最终性能

我们先直观的看一下,FlightLLM来做推理,能达到效果。

硬件与模型:

FPGA:实测平台是 Xilinx Alveo U280,225 MHz,8GB HBM + 32GB DDR;

模型:主要测试 LLaMA2-7B 和 OPT-6.7B。

压缩方式:块稀疏注意力、N:M 权重剪枝、混合精度量化;

论文里权重平均约 3.5-bit,激活约 8-bit。

最终得到的性能:

Decode 速度:在 Alveo U280 上约 55 tokens/s;

在 Versal VHK158 上:LLaMA2-7B 约 92.5 tokens/s。

Prefill 性能:大约 430-440 tokens/s。VHK158 的 profiling/simulation 数据,不是 U280 板上实测。

3: 核心技术要点

我们来看看FlightLLM最核心的几个技术点:

3.1: 可配置的稀疏DSP 链

我们提出了一个可配置的稀疏DSP 链来支持不同的稀疏模式。 FlightLLM 通过块方式和 N:M 稀疏性将计算效率提高了 1.6 倍。

具体的做法是:模型先做了压缩,同时做剪枝稀疏化。当然,这带来重训和微调的技术难点。压缩使用模型对内存和算力和需求降低。剪枝主要是去掉部分权重,而去掉权重带来矩阵的稀疏化,零值变多。这时,就可以同时用"可配置稀疏 DSP 链"支持不同稀疏模式,提高稀疏计算效率;

原始 LLaMA2-7B/OPT-6.7B 先被压缩成 "稀疏 + 权重平均 3.5-bit + 激活 8-bit" 的模型;

推理时,FPGA 从 HBM/DDR 读取压缩格式数据,在片上把低比特权重展开成 INT8 参与计算。

这一步,压缩和剪枝是前提,然后,产生稀疏的问题,通过FPGA的稀疏DSP链来成成,两个步骤相互配合。

注意:这里的 LLM Sparsification 和 Quantization 会使用实验室的一些标准的量化方案。

3.2: 片上解码

• 我们提出了一种具有混合精度支持的片上解码方案。 FlightLLM 将内存带宽从 35.6% 提高到 65.9%。

用 always-on-chip decode 把 decode 阶段的小激活向量尽量留在片上,减少 HBM/DDR 反复读写,把带宽利用率提升到约 65.9%;再用长度自适应编译减少不同 prefill/decode 长度对应的指令存储开销。

所以 FlightLLM 的核心不是"把整个模型塞进 FPGA",而是利用 LLM decode 阶段激活很小的特点,让小数据在片上流动、让大权重从外部存储流式进入,从而减少内存往返,提高 FPGA 上的推理效率。

这里存在复杂的 Address Allocation,需要确定

* 权重放在HBM哪个位置

* KV Cache放在哪里

* 中间激活放片上还是片外

* 每个buffer的地址如何编号

* 哪个通道负责哪部分的数据

3.3: 自适应编译方法

• 我们提出了一种长度自适应编译方法,可将指令存储开销减少 500 倍(∼GB),从而能够将现实世界的 LLM 部署到 FPGA 上。

这是我之前没有理解的点,想了半天才想明白。对于FPGA完成推理,要解决如下问题:

* 输入token长度是变化的。

* 每种长度如果都单独存一套指令,instruction file 会非常大

* 再叠加层和head的不同稀疏模式,空间会爆炸到TB级别

我们需要理解,为什么token长度变化会影响指令。首先,长度不同会造造成我们 3.2 片上编码的策略产生不同,也就是会影响执行计划,另外,这种分组并不如想象那么简单,如何分组可以保证不明显掉性能。本身LLM又分prefill和decode两个阶段,还有每层的不同,这里的做个分桶是很复杂的。需要完成如下动作。

  • 连续长度分组复用
  • prefill 与 decode 不同阈值策略
  • decode 因为更受 memory access 影响,要用更细的阈值
  • 再结合 HBM 通道上的相似 LD/ST 指令合并

这是2年前的对比,在这2年里,N卡也一直在发展。我们可以看到 FlightLLM方案的成本是很高的,因为Xilinx U280 的价格是 3 - 5万人民币。而我们部署的仅令是 7B的 INT4 量化的模型。

如果按现在的卡的能力。用RTX 4090 24G的卡,采用vLLM/TensorRT-LLM + 4-bit 量化后,Decode 约 150 - 250 tokens/秒​。实际上还是会远好于FPGA的效果,而且,你要考虑适配模型耗费的大量的开发成本,这个就不好比较了。

总的来说,我觉得一定的科研价值,但基本没有应用价值。可能可以作为后续做细节优化的方案之一。

相关推荐
BreezeJiang11 小时前
大模型为什么能记住上一轮?从 InMemoryChatMessageHistory 看对话 Memory
llm·agent
武子康16 小时前
同一套 Agent Runtime,为什么 Web、Headless 和 Python SDK 仍然不是同一个产品
人工智能·llm·agent
还有多久拿退休金17 小时前
不调多模态,纯文本大模型如何给系统操作配上截图
前端·llm·aigc
DigitalOcean18 小时前
AI Agent如何降本?从五层技术栈到三种推理服务
llm·agent
百工蜂Agent20 小时前
Claude Code 整体架构与设计
llm·agent
桃西西呀1 天前
上下文窗口都卷到 100 万了,大模型为什么还在为"位置"发愁?
人工智能·llm·ai编程
智塑未来1 天前
FPGA开发板怎么选?先看资质、案例与研发底盘
fpga开发
山顶夕景2 天前
【LLM】GLM-5.3-Flash模型
大模型·llm·agent·多模态·moe
minglie12 天前
黑金AX301的SDRAM
fpga开发
hahaha60162 天前
HLS高层次综合设计技巧--高层次综合设计探讨
fpga开发