最近一直在折腾 70B 级别大模型的推理性能优化在各种 AI 硬件加速器之间来回切换。老实说很多人对LLM 硬件加速器的理解还停在买张更贵的卡这个层面觉得显卡越好大模型跑得就越快。真实情况远比这个复杂一块标称 1000 TFLOPS 的板子跑起 70B 模型可能被一块 300 TFLOPS 但带宽更高的卡按在地上摩擦。问题出在哪里为什么专门针对 LLM 设计的硬件加速器越来越受重视这篇就结合我自己的实际项目经验把 LLM 场景下硬件加速的核心逻辑、方案选型、软件配套和落地踩坑一次性讲清楚。适合正在做模型推理部署、AI Infra 基建或者正在评估是买 GPU 还是选专用加速卡的团队参考。1. 为什么LLM是带宽饥饿型负载先说一个基本认知LLM 推理其实不完全是算不动的问题更多是数据喂不过来的问题。我们平时说的 FLOPs、Tensor Core 算力只是加速性能的一个维度。LLM 生成 token 的过程绝大多数时间消耗在搬运权重和 KV cache 上而不是让乘法器满负荷运行。1.1 打破算力即性能的惯性思维推理阶段有两个明显不同的阶段预填充prefill和解码decode。预填充阶段要并行处理整段输入 prompt计算密度很高算力确实重要。但一旦进入解码阶段每次只需要生成一个 token这时模型要读取整个 transformer 层的全部权重比如一个 70B 模型如果用 FP16 存储光权重就有 140GB。如果加速器的内存带宽是 2TB/s那么理论上每生成一个 token 都要把全部权重过一遍至少需要 70ms单用户吞吐最多 14 token/s 左右。这就是为什么很多自研加速卡规格表上写的 INT8 算力惊人实际测 LLM 时 token 吞吐却拉胯。因为解码阶段是彻底的访存受限memory-bound不是 compute-bound。如果芯片设计时没把内存带宽、片上缓存大小和计算吞吐做到平衡就会出现大力士搬砖被门口窄路卡死的画面。硬件加速器真正要优化的不是单纯提高算力而是做带宽、容量、延迟的联合设计。1.2 从访存角度看加速器应该怎么设计假如你要为 LLM 专门设计一块 AI 硬件加速器最该盯的几个指标是内存带宽HBM 带宽解码阶段跑得有多快基本由它决定。片上 SRAM/Cache 容量能不能把当前层的权重或 KV cache 留在片上减少反复去 HBM 搬数据。数据类型支持密度能不能高效算 FP8、INT8、INT4因为低比特模型能立刻把有效带宽翻倍。互连带宽和拓扑多卡并行时张量并行和流水线并行的通信开销会不会拖后腿。举个例子假设还是 70B FP16 模型如果改用 INT4 存储模型权重压缩到 35GB同样的 2TB/s 带宽理论上每 token 读取时间降到 17.5ms单用户吞吐立刻翻 4 倍。这也是为什么现在硬件加速器几乎都把低精度矩阵乘算力写成卖点。理解了访存受限这个底层逻辑后面所有优化点都能串起来。2. 加速LLM的几个关键硬件技术方案定向给 LLM 做加速器不是简单堆一个大号 GPU。业界这几年的探索基本落在几个方向上把 KV cache 往片上怼、把精度降下来、把无效计算省掉、合理平衡 prefill 和 decode 的资源占用。逐个聊。2.1 片上存储与KV Cache的进击LLM 推理时每生成一个 token 都要读取当前已生成的所有 token 对应的 Key/Value 向量。上下文越长这个 KV cache 越大。以 8B 模型、4096 上下文、FP16、分组查询注意力GQA来计算KV cache 也在 GB 级别。传统 GPU 的做法是把 KV cache 扔在 HBM每一轮迭代都要来回访问。硬件加速器如果把 KV cache 放进片上 SRAM就能用几百 GB/s 的片上带宽替代传统 HBM 带宽显著降低每生成一个 token 的时延。典型代表是 Groq 公司的 LPU把大块 SRAM 堆在芯片上用小模型、短上下文时温度很低、延迟异常稳定。这种设计的代价是能塞进片上的 KV cache 大小受芯片面积限制遇到超长上下文、更大模型一样要回到 HBM 甚至 CPU 内存换入换出。所以片上存储的加速是有前提的不能只看单点指标。选择加速器时你要重点确认它引以为傲的片上缓存和我的目标模型、上下文长度是否匹配。2.2 低精度计算FP16到FP8/INT4这几年大家的共识是LLM 推理对参数精度的容忍度比训练高得多。用 FP16 训练完的模型推理阶段可以校准后量化到 FP8、INT8甚至 INT4。硬件为低比特计算设计专门的数据通路能带来双重好处权重瘦身访存量直接降一半/四分之一相同面积下可以部署更多乘法器或者用更少的晶体管完成 INT4 运算。这也是很多 AI 加速卡宣传 INT8 算力是 FP16 两倍的由来。但低精度不是白拿的。一种常见的坑是只量化权重、不量化激活最终瓶颈还在激活的访存和计算密度上另一种更隐蔽有些板子对 INT4 并没有专门硬件支持而是通过多次 FP16 模拟性能反而更差。选型时务必看清楚它是否原生支持混合精度 GEMM而不是只看宣传支持 INT4。2.3 稀疏性与结构化剪枝的定制Transformer 里有相当一部分权重在特定输入下是无关紧要的。传统 GPU 用稠密张量核心遇到零值一样要搬运和计算。专用 LLM 加速器芯片的另一个方向是在硬件层面支持稀疏以 2:4 结构化稀疏为例每四个元素只存两个非零值对应的计算单元翻倍访存量也减半。对 LLM 而言可以的稀疏方案还包括对 attention 分数做稀疏化或者对 FFN 层的激活做 ReLU 系稀疏。硬件支持稀疏并不等于模型自动稀疏。你还需要在模型侧做好剪枝和重训练保持精度不塌。而且很多加速器支持稀疏只是某一个矩阵乘法路径上支持落在真实注意力层上未必生效。我的建议是在做方案对比时拿同一套稀疏率下的真实 benchmark不要看白皮书里的理论峰值。2.4 预填充与解码的解耦动态批处理前面说了prefill 是计算密集decode 是访存密集。如果硬件加速器只能一成不变地处理混合 batch效率一定低。我在实际项目里发现对长 prompt 请求prefill 阶段可能把整卡算力打满但 decode 阶段又饿得要死。所以当前主流硬件方案都在想办法做算法和资源上的解耦chunked prefill把长 prompt 切成小段穿插在 decode 间隙执行连续批处理每来一个请求就插进当前 batch而不是等整个 batch 解码完再整体退出计算流和访存流的硬件调度尽量让算数单元和处理搬数的单元互不阻塞。如果你要采购加速卡建议关注它配套的 runtime 是否支持连续批处理和 chunked prefill。这是比峰值算力更能影响整体吞吐的细节。3. 主流加速器方案选型对比现在市面上的 LLM 硬件加速器大致四类通用 GPU、专用 ASIC、可重构 FPGA、以及边缘 NPU。没有绝对最优只有是否适合负载形态。我把自己实测下来的感受整理成一张对比表下面详细解释。方案类型代表核心优势主要局限适合场景GPUNVIDIA A100/H100、AMD MI300生态成熟、软件栈丰富、通用性强功耗高、采购贵、低精度利用率看框架训练推理兼顾的通用平台专用 ASICGoogle TPU、Groq、Cerebras单芯片带宽/片上容量极致、时延稳定软件锁定、算子覆盖有限、灵活性差单一模型长期稳定推理FPGAAchronix、Xilinx 等可定制、能效比可控开发周期长、生产力不如 GPU/ASIC需定制算子或硬件快速迭代的场景NPU手机/边缘端 AI 加速单元低功耗、低成本、低延迟容量限制大、算力有限端侧小模型和端云协同3.1 GPU方案依然是通用底座NVIDIA GPU 是目前把硬件算力和软件生态结合得最省心的选项。H100 的 HBM3 带宽、Transformer Engine 对 FP8 的原生支持再加上 CUDA 生态里 vLLM、TensorRT-LLM 等框架迭代得飞快开箱性能基本是最稳的。AMD MI300 也在逐步追赶但实际部署时你在 NVIDIA 上跑通的算子调优路线到 AMD 上大概率要重新适配。GPU 的问题在于它既要兼顾训练又要支持各种计算天然不是为 LLM 解码这种访存密集场景做最激进优化的。比如 H100 的内存带宽 3.35TB/s 看起来很猛面对 100B 模型每 token 依然要几毫秒以上。你买了再贵的 GPU最终也逃不开每瓦性能、每美元吞吐的核算。适合能力有限、不想绑定特定芯片的团队先跑起来再逐步评估专用方案。3.2 专用推理芯片结构化的执行路径、确定性时延Google TPU 更多用于自身大模型训练对外通过云服务输出。Groq 和 Cerebras 是典型走为 LLM 定制路线的玩家。Groq 的 LPU 没有 HBM全靠片上 SRAM 加高带宽互连对短上下文小模型的时延控制非常出色。Cerebras WSE 则是把整个晶圆做成一整块芯片拥有极夸张的片上存储和互连带宽适合超大规模稠密模型。这类 ASIC 的最大卖点是确定性。GPU 因为任务调度复杂同一条请求在不同时间跑出来延迟毛刺较大专用架构通常按深度流水线设计每个 token 的步调非常稳定。如果你是做交互式 AI 助手、要保证用户体验一致性的场景这种确定性非常值钱。缺点是软件栈封闭支持哪些算子、哪些推理框架、哪些量化策略都是厂家说了算。大模型架构一更新你可能要等半年适配。3.3 相对小众的FPGA与边缘NPUFPGA 在 LLM 加速里属于折中派。它不像 ASIC 那样需要一次性流片也不像 GPU 生态那么全。我接触过的团队把 FPGA 用于两处一是给特殊数据结构比如稀疏矩阵、部分注意力算子定制硬件加速二是需要频繁调整数据通路的原型验证。但 FPGA 开发是硬件工程不是写 Python这让很多 LLM 团队望而却步。边缘 NPU 对应的则是另一类场景模型不一定要 70B端侧跑 1B~8B 的模型配合服务端大模型做分层。对这类场景芯片上集成的高效卷积矩阵单元、低功耗 LPDDR 通道和 INT8/INT4 加速往往比绝对峰值算力更关键。适合做离线批处理、智能终端离线推理以及隐私敏感场景。4. 硬件之外的软件层加速落地必须过的关选了一块加速卡接下来才是大头能不能真正把卡的性能吃满。我和不少团队交流时发现大家买完卡回来随手用官方自带的 demo 跑一跑感觉还行一接到真实业务负载就败下阵来。原因多数出在软件层。4.1 推理框架与硬件后端适配LLM 推理框架已经高度工程化vLLM 主打开源生态和 PagedAttentionTensorRT-LLM 优化大量算子融合MLC-LLM 面向多硬件后端做编译器还有各家自研 runtime。硬件加速器如果没有对应的后端支持就好比买了高配主板但 BIOS 不认新 CPU只能按最保守的通用路径运行。实际选型流程中你要重点确认这么几个接口框架是否支持连续的 KV cache 分配方式是否需要把 HuggingFace 模型格式转成专用 engine是否支持自定义采样、logits 处理等业务逻辑第三方监控、弹性伸缩是否能接入。有些加速卡官方说支持 vLLM但只是加了一个很浅的适配层很多新特性如 speculative decoding、parallel sampling并不可用。部署前建议把你要用的所有功能列表列出来逐一在目标硬件上做可测性验证而不是只看兼容那两个字。4.2 算子融合和内存复用我们曾经把一个推理任务从 GPU 迁到专用加速卡上跑出来性能只有规格书理论值的 1/3。后来排查发现模型里的某些 attention 算子被拆成了一堆小算子在加速卡上反复读写中间结果。同样的算子如果做到 FMA乘法加法、GELU 融合、LayerNorm 融合、QKV 投影融合访存次数能减少一半以上。硬件加速器必须在软件栈中提供算子融合能力至少自动识别两类融合元素级算子融合把 scale、bias、gelu 等合并到前一个矩阵计算里结构级融合把 QKV 三个矩阵乘合并成一次大 GEMM把多个头集中在同一块缓存中处理。这套工作做得好不好几乎决定了加速卡在真实模型上的表现。很多卡理论算力高却因为融合能力弱实际 token 吞吐被访存次数拖住。你看测评报告时建议直接问一句你们跑 meta-llama/Llama-2-70b 时用了哪些融合 pass能答得上细节的软件栈通常是真的能用。5. 实际部署的权衡与踩坑经验以下是从我落地多个 LLM 推理项目中总结的几条硬经验不针对特定厂商但一定通用。5.1 显存/存储容量对比率Memory to Compute balance很多加速器的规格是算力高得夸张内存容量只有几十 GB。LLM 推理不仅要装权重还要装 KV cache、临时激活值、推理引擎本身的开销。如果内存容量不够多用户并发时就会频繁做 offload性能雪崩。我的建议是先算清目标场景的峰值内存需求公式很简单峰值显存 ≈ 模型权重(所有中间副本) 最大并发数的KV cache 推理框架开销(约2-4GB)。然后看加速器的显存容量和聚合带宽是否匹配。比如同时要支撑 500 路并发、16K 上下文、8B INT8 模型权重10GB KV cache几百GB 这种量级的很多高算力小显存的卡直接出局。算力再高容量不够就是不够。5.2 实际性能验证时容易忽略的三件事第一时序要分场景跑。不要只跑 prefill 吞吐也不要只跑 decode 时延。真实负载是长短混合有的请求 prompt 短但要求秒回有的请求需要读大量上下文、输出长文本。要分别压测并按你的业务比例做加权混合。第二要用真实 batch 和真实并行设置。很多加速卡在单 batch、单并发下数据很好看但 LLM 服务商用场景一定是高并发连续批处理。如果你没有把连续批处理打开或者只测了静态打包 batch 而不测动态插入请求结果会严重失真。第三量化策略影响巨大。不要把支持 INT8等同于默认生效。有的框架对某些算子 fallback 回 FP16导致显存带宽没省下来。部署后要在 profiler 里检查是不是所有 GEMM 都跑到了 int8 tensor core而不是只有第一个 GEMM 用了。5.3 网络和存储要跟着升级加速卡只是链路的一环。当模型分布在多卡上时节点间通信速度直接决定整体性能。我记得有个项目从单卡切到两卡张量并行理论算力翻倍实际吞吐只涨了 30%一查原因是跨卡通信走了 TCP而不是 RDMA。硬件加速器配套的互联方案PCIe、NVLink 类专用直连、RoCE/InfiniBand必须提前评估否则多卡扩展收益微乎其微。另外模型加载速度也容易被忽略。几十 GB 的模型从 NVMe 读进显存如果每次冷启动都花 3-5 分钟弹性扩容场景根本没法玩。好一点的推理引擎会做模型缓存和预加载但如果加速器不提供高效的主机内存到设备内存拷贝通道再好的调度也白扯。6. 未来加速器方向不是取代GPU而是细分每次聊硬件加速总有人问是不是过两年专用加速器就取代 GPU 了我的判断是不会完全取代而是生态各自分层。GPU 继续做通用底座专用加速器会在一些特定形态里越挖越深。6.1 内存接口的极限怎么破既然瓶颈在带宽未来加速器一定会挑战更极致的存内计算组合。存内计算把权重直接放在存储单元附近做乘加时不用把数据搬去计算单元理论上省掉最耗时的数据搬移。目前这项技术量产还难但已有加速卡在特定稀疏任务上用近存储计算达到超出传统架构的有效带宽。对 LLM 这种几乎每 bit 权重都要被读取的场景存内计算天然契合。另一个方向是打破 HBM 带宽的通用瓶颈改用更宽的片内总线、光互连、chiplet 异构集成等方式把计算和存储的距离进一步拉近。将来比的可能不是单卡指标而是每个 token 单位能量内可复用的片上数据量。6.2 面向多模态和长上下文的加速LLM 正在变成多模态大模型的中央处理器图片、视频、语音最终都映射成 token。这意味着加速器不仅要加速文本 GEMM还要做视觉编码器、语音编码器的混合调度。同时上下文窗口继续扩大KV cache 的存储方案会继续迭代。我个人的预期是未来加速硬件会把Context Engine做进芯片专门处理注意力状态的管理和检索而不是让所有注意力计算都走一遍通用矩阵乘。对用户而言这意味着选择加速器时不要再只盯算力和带宽更要看它的 AI 生态对于最新模型架构如混合注意力、MoE的适配速度。硬件的世代更迭速度远慢于模型结构进化速度所以软件可重新编译的灵活性和硬件对架构趋势的预判往往比纸面指标更重要。最后我想分享一条自己反复验证的心得选 LLM 硬件加速器最忌讳在没跑真实模型前下单。一定要拿着你业务里最典型的模型、最典型的上下文长度、最典型的并发曲线到目标平台上去做一次完整的压测。硬件的价值从来不是跑分而是在你的真实负载曲线下把 token 延迟压到目标值以内、单位成本压到可接受范围内。我见过太多按白皮书选型的团队最后陷进算力用不满、显存卡脖子、框架适配慢的三层泥潭里。希望能帮你避开这些坑。