FPGA 在大模型推理中的应用

FPGA 在大模型推理中的应用

我在之前详细讲过FPGA在AI中的优势,如果我们要利用它的优势,去优化大模型推理过程,应该有哪些方案(只是理论推导)。下面简单罗列一下:


方案一:OffLoad  MoE Expert MLP

        MoE的MLP阶段,有一个重要的运算特点。

        因为专家多(DeepSeek V3.1 的MoE有 256个专家,每个专家需要运算的batch就相对较小,因为路由后分散了,运算就变成一个细太碎的运算。此时,运算的瓶颈不在计算而在调度,权重读取上。

        在这种情况下,如果使用GPU来完成,按GPU运算的特点,它强在并行大数据,多批次的运算。此时,每个运算依赖于SM,而SM可以需要有Kernel的准备,大量的时间会花在kernel的准备上,而好不容易准备好,但要处理的数据量极少,读取权重数据的时间反而显得更长,真正的运算并行很少(可能一个专家就算一个token),因为数据量小(注意:不同网络层的运算是不能并行的。唯一可以并行的是路由计算得到的N个专家)。 这时,有点象大饭店的大锅炒菜,最合理的方式是,一锅同时炒多份,但现在来的人少,一个大锅每次只能炒一份菜,相比洗锅和一些准备时间,就显得很浪费了。

        如果交给FPGA来运算,因为FPGA的运算是定制的硬件电路,所以,不存在Kernel准备的事情,完全是一个固定的数据流处理,需要处理的数据多少,完全不影响运算效率(因为它的并行是靠硬件电路的复制来完成,而GPU并不是,GPU还是靠并行调度来达成高效,如果没有足够多的数据,就只能是高射炮打蚊子,好不容易花代价准备了一个Kernel,一个SM,但只计算很简单的一个权重数据)。当然,权重的读取,仍然需要有足够的空间和带宽。这个对于FPGA,标准做法是需要HBM,当然 HBM的存量有限,我们后面也会给出另外的方案(见方案二)。

        好了,我们再来强调和总结一下:

        MLP时,是按每个token进行路由,也就是说每个token会落在不同的专家,反过来说,每个专家最终需要处于的token并不会太多。token在做MLP时,任务会分开落在不同专家。也就是说拆出的任务非常的碎(稀疏),大量的处理时间会花在调用不同专家的不同权重上,也就是激活专家的kernel和读取权重数据上。

        这里要澄清一个概念,MoE在计算路由专家时,是按单个token来计算的,并不是传统理解的那种行业专家,按一整上下文来计算路由专家。你在读一段话时,遇到数字时调用“算术能力”,遇到代码时调用“语法能力”,遇到人名时调用“实体记忆”。这些能力在 MoE 里就是不同 expert。它们是“技能模块”,不是“行业部门”。专家的能力是一种隐特征,并不是我们常规理解的行业特征。

核心思想:

        MoE 的瓶颈不是 FLOPs,而是“调度 + 权重访问 + 任务粒度”
        GPU 为大而生,FPGA 为碎而生。

方案二:访存扩展——数据切片

        上面说到,不管你运算有多高效,但权重和中间过程数据是需要内存的,并且需要很高的访问速度。如果我没有很高的HBx,单个芯片的访问DDR的带宽也有限,那怎么办?

        因为我们在使用 FPGA来完成MoE时,为了保证单层网络在进行路由运算时,有足够的并行度。最好是将 所有路由专家的处理都 一次完成,但那样的话,对于FPGA的访存要求会很高,在Prefill阶段,甚至是不可能达成的。比如:有256个专家需要运算,如果一个专家的权重很大(比如:满血DeepSeek  671 / 256 大约会有 2G内存),也就是一个专家的处理需要有数据有2G,考虑内存访问的速度是有限的(比如:DDR访问速度是 2400M),如果光是读数据就要1S,那这件事情就没法做了。所以,这块是一定要优化的。

        优化的方案很简单,考虑到MLP的运算,数据是可以拆分的(有点象大数据运算的Map Reduce的原理和前提条件),所以,可以将权重数据拆分到多个FPGA芯片负责的内存上(比如:使用DDR),这样,可以将数据分散到多个芯片,分头运算,然后汇总。这完全类似 Map Reduce的原理。这就大大提升了访存的带宽。

        具体需要拆分成多少个FPGA芯片,这个问题较复杂,要考虑你采用的FPGA芯片的DSP能力,配置的是HBM还是普通DDR,以及相应的访存带宽。还有你需要完成的模型的大小,对应单 一专家的模型大小。这些条件综合进考虑,选择合适的芯片和数量,进一步确认,在存储中如何拆分。

核心思想:

        权重拆分,将运算分布到多颗FPGA,提升访存吞吐量。

方案三:KV Cache / Memory Offload

        FPGA 还可以做 KV Cache 的管理 ,压缩,分层存储。

3.1:KV Cache 优化

从系统视角,KVCache并不是简单的 KV存储和复用,它的实际作用是:

1:种类繁多,包括不同会话,不同数据批,不同sequence length,动态增长(decode),这是一些碎片。

2:索引复杂,token->layer->head->K/V

3:读写带宽非常紧。Attention每一层都要读,Decode每个token都需要读,Prefill 要写,decode要大量的读。

4:生命周期需要管理 :及时释放,回收,长对话处理。

5:数据格式需要转换 FP16 -> FP8 -> INT8

6:多层存储之间需要不断迁移处理。HBM-->DDR-->NVMe,热/冷 token 区分切换。

上面的任务都 是控制型的,GPU做不好,FPGA如何做呢?

1: 提供硬件级的控制器,建立分配表,索引,实现sliding window逻辑,提供会话上下文的状态机。

2:提供数据转移支持。

3:提供 KV cache Layout 重排。

3.2:KV Cache压缩

        用GPU肯定不行,但使用FPGA,可以做到边读取边解压。因为写的时候很多,主要是读,所以收益是不错的。另外,因为精度有一种容忍度,所以,如果采用有损压缩,压缩比例可以很大。

        这里的压缩并不是简单的ZIP压缩,而是结构感知压缩,就是我们讲的量化方案。可以大大降低对内存的需求。

3.3:分层存储

        如何分层?

                GPU HBM   ← 最热 token
                FPGA HBM / DDR
                Host DDR
                NVMe SSD ← 冷 token
        FPGA可以做啥呢?

        1:热度统计。

        2:数据自动迁移

        3:数据格式统一。

        它不但强于GPU,也比cpu能力更强。因为它是固定延迟的。

核心思想:

        大模型推理真正的瓶颈 是“内存系统”,不是算力

方案四:纯FPA方案用于科研创新

        如果一定要用FPGA来独立实现大模型推理,有没有价值呢?

        其实有不少大学实验室 都 在使用纯FPGA的方案,目的很明确,主要是做算法研安,前沿系统架构的验证,这样,可以形成专利/论文,为形成专用的AI芯片做实验 。这肯定是可以的。

        首先,对于纯的单颗FPGA,如果不用HBM,基本不可行。因为内存访问带宽严重不足。使用HBM,可以将模型权重,关键数据常驻HBM.

        基于上面的前提,FlighLLM论文 https://arxiv.org/abs/2401.03868?utm_source=chatgpt.com,提出了几个关键的技术点:

        1:模型量化后,会产生大量的稀疏矩阵,如果直接用GPU,种用率比较低。使用FPGA,可以定制DSP链:

        定制方式:

        * 跳过0

        * 重排 乘加

        * 保持流水不断

        把这种不规则的稀疏变成规则的硬件的路径。

        感觉这很是费劲,但确实会有效。最好可以加配置,方便少量的变更。

        2:HBM 是很有限的,为了降低对HBM访问压力,

        * 不同场景,使用不同数据精度。提升效率。

        * 降低带宽,提升cache命中率,保持数值尽量不变。

        3:FPGA的工程化痛点,通过参数配置,在不影响 性能的情况下,减少编译 的次数,提升开发效率。

        FlightLLM中并没有实际写出运行 Llama 7B 模型的性能,但肯定是不支持多并发的,而且,性能应该也不会很好(不然不会不提),只是侧面比较了一下decode阶段的性能与GPU卡的对比,作为研究型论文,也就这样了。

核心思想:

        FPGA不能取代GPU来独立完成大模型推理。但可以做一些局部优化,完成一些异构计算上的创新。

优劣分析

        就上面的一些分析,可以看出。如果要对大的MoE的模型进行推理,FPGA的加入,可以降低推理的门槛,但要特别注意:它只是降低了使用的最低配置的门槛(主要是针对整体配置的成本而言)。但是,如要推理使用场景,用户的请求量大,并发多,通过工程上的优化(我理解vLLM引擎是可以做到这个的,只要命中的是同一层,同一个expert,就是合并到一起,当然合并也有代价,需要协同处理),全GPU方案是可以将MLP中专家的batch量提升的(进行合批处理),这样,可以充分利用GPU的算力,于是,它的劣势就不存在了。所以,现象就是,当并发提升后,全GPU方案的token产生成本会远远低于 GPU + FPGA的方案。所以,FPGA方案只适用于某一个并发范围,这要特别注意。至少目前是这样的。

FPGA异构优势:

        适用于 MoE多专家大模型(越大越好),低并发, 需要稳定输出,需要更低能耗,

Read more

Python爬虫(54)Python数据治理全攻略:从爬虫清洗到NLP情感分析的实战演进

Python爬虫(54)Python数据治理全攻略:从爬虫清洗到NLP情感分析的实战演进

目录 * 引言:数据价值炼金术的三大挑战 * 一、项目背景:某跨境电商平台评论治理需求 * 二、智能爬虫系统架构设计 * 2.1 分布式爬虫实现 * 2.2 原始数据质量探查 * 三、Pandas数据清洗进阶实践 * 3.1 复合去重策略 * 3.1.1 精确去重增强版 * 3.1.2 语义去重深度优化 * 3.2 智能缺失值处理 * 3.2.1 数值型字段混合填充 * 3.2.2 文本型字段深度填充 * 四、Great Expectations数据质量验证体系 * 4.1 高级验证规则配置 * 4.2 自动化验证工作流 * 五、NLP情感分析深度集成 * 5.

By Ne0inhk

Python 全面语法指南

前言 1. 什么是编程? 编程就像是教电脑做事的过程。想象你有一个非常听话但很笨的助手,你需要用它能理解的语言(编程语言)一步一步地告诉它该做什么。 * 你 = 程序员(下达指令的人) * Python = 你和电脑沟通的语言 * 电脑 = 执行指令的助手 2. Python 的特点 Python 之所以适合初学者,是因为它: 1. 像英语一样易读 - 代码看起来像自然语言 2. 简洁明了 - 用很少的代码完成很多功能 3. 功能强大 - 从简单计算到人工智能都能做 4. 免费开源 - 任何人都可以免费使用 3. 程序的基本结构 一个 Python 程序就像做菜的食谱: 1. 准备材料(定义变量) 2. 处理材料(执行操作) 3. 呈现结果(

By Ne0inhk
LangGraph 智能体状态管理与决策

LangGraph 智能体状态管理与决策

LangGraph 智能体状态管理与决策 * 写在最前面 🌌你好!这里是 晓雨的笔记本在所有感兴趣的领域扩展知识,感谢你的陪伴与支持~👋 欢迎添加文末好友,不定期掉落福利资讯 写在最前面 版权声明:本文为原创,遵循 CC 4.0 BY-SA 协议。转载请注明出处。 本次演示围绕 Bright Data Web MCP 与 LangGraph 的集成实操 展开,完整展示了从获取大模型 API Key、创建大模型会话,到获取 Bright Data API Key、通过 MultiServerMCPClient 连接 Web MCP 服务器,并在 Bright Data 后台进一步启用浏览器自动化工具、扩展智能体可调用能力的全流程;同时结合 LangGraph

By Ne0inhk
Python操作国产金仓数据库(KingbaseES)全流程:搭建自己的网页数据管理(增删改查)

Python操作国产金仓数据库(KingbaseES)全流程:搭建自己的网页数据管理(增删改查)

Python操作国产金仓数据库(KingbaseES)全流程:搭建自己的网页数据管理(增删改查) Python操作国产金仓数据库(KingbaseES)全流程:搭建自己的网页数据管理(增删改查),现在国产化替代是大趋势,国产数据库的应用越来越广,金仓数据库(KingbaseES)作为其中的佼佼者,在政务、金融这些领域用得特别多。今天我就带大家从0到1,一步步实现用Python操作KingbaseES数据库,还会基于Flask框架搭一个可视化的网页管理系统,数据的增删改查全流程都能搞定,不管你是Python开发者还是数据库管理员,跟着学都能用得上。 前言     中电科金仓(北京)科技股份有限公司(以下简称“电科金仓”)成立于1999年,是成立最早的拥有自主知识产权的国产数据库企业,也是中国电子科技集团(CETC)成员企业。电科金仓以“提供卓越的数据库产品助力企业级应用高质量发展”为使命,致力于“成为世界卓越的数据库产品与服务提供商”。     电科金仓自成立起始终坚持自主创新,专注数据库领域二十余载,具备出色的数据库产品研发及服务能力,核心产品金仓数据库管理系统Kingbas

By Ne0inhk