LLM推理加速：从GPU到专用加速器的选型实战

上个月我接到一个挺实际的活儿公司内部那个基于开源模型搭建的LLM问答服务高峰期延迟从800毫秒一路飙到两秒多用户已经到后台骂过一轮了。按老思路加两张GPU卡最省事但预算审批卡得很严领导直接问我有没有比堆GPU更“聪明”的方案市面上那些标着“AI硬件加速器”的设备和板卡到底能不能解决问题顺着这个问题我把近期关于LLM硬件加速的路线都过了一遍也实际测了几种方案。这里先给个结论AI硬件加速器从来不是一个单一产品而是一类针对性极强的协处理器和优化路径的集合包括GPU、NPU、定制ASIC也包括框架层面的量化、稀疏化、KV Cache优化。真正要落地你得先明白LLM的计算和访存特性再决定买什么卡、调什么参、配什么推理引擎。这篇文章就把我从选型到测试的完整思路写下来给做AI基础设施、运维和算法工程的同学一个参考。1. 一次扩容评估引发的思考AI硬件加速器不是一个名词是一族方案1.1 问题的起点加GPU为什么不一定划算最开始我也是按老办法算了一次账公司现有4张A系列推理卡64并发时显存已经顶到80%以上如果要把并发翻到128显存和算力都得加再加4张卡硬件成本大概翻一倍功耗也上来接近一倍。问题是这台机器上跑的模型权重才不到10GB但由于每个用户的上下文长度不一样KV Cache的显存占用是动态增长的一个1万token的会话KV Cache占用的显存可能比模型本身还大。继续加通用GPU花钱买的是通用算力和巨大显存其中相当一部分是被缓存结构吃掉的根本没有砸在计算上。这也是我开始研究专用加速器的原因。市面上的AI硬件加速器从形态上看有PCIe卡、M.2模块、整机服务器从芯片类型上看有GPU、NPU、DPU本质其实都是为某个“计算模式”做定制优化。LLM这类负载的计算模式很特殊它的瓶颈往往不在峰值算力而在访问带宽、显存容量、数据搬移效率上。通用GPU那种“单芯片堆很多CUDA核心”的设计在跑纯稠密矩阵乘的时候效率高但一遇到LLM这种“权重吃显存、缓存吃带宽”的负载性价比就开始往下走。1.2 为什么“多买两张显卡”常常不是最优解为了把这件事说透我列了一张对比表把我评估过的几类硬件方向列在一起方案类型典型代表核心优势主要局限通用GPU数据中心的训练/推理卡生态成熟软件栈齐全功耗高价格高显存利用率受KV Cache影响大专用推理卡各家推理加速卡、NPU单位功耗算力高显存带宽大大模型适配需要专用编译和算子库FPGA可重构加速卡灵活适合定制量化位宽开发成本高片上存储通常偏小运行效率不如ASIC端侧NPU手机、边缘盒子里的AI单元低功耗数据不出端算力有限大模型需要极深入压缩为什么我一开始没直接换专用推理卡因为LLM服务不是单跑一个算子它包含tokenizer、attention计算、Feed-Forward网络、采样器、KV Cache读写和调度逻辑。专用推理卡的算子库如果跟不上你就算买了也会发现很多算子是CPU fallback跑起来比GPU还糟心。这里就涉及一个关键认知AI硬件加速器的价值不是由芯片峰值性能单方面决定的而是由“芯片编译栈推理引擎”这个整体决定的。这也是文章后面重点展开的内容。1.3 把硬件的价值拆开看算力、显存、带宽、互联在和多家加速器厂商的工程师聊过之后我发现他们评估一个LLM负载能不能跑得动几乎都围绕四个指标峰值算力TOPS/TFLOPS决定理论计算上限但对LLM来说往往不是最稀缺的资源。显存容量GB决定能不能装下模型权重和KV Cache容量不够时只有两条路换更大的卡或者做量化。显存带宽GB/s这是LLM推理里最关键的指标权重和KV Cache在一次次推理中被反复读取带宽直接卡住吞吐。片间互联带宽GB/s模型并行或专家并行时数据要在多颗芯片之间交换互联带宽不够加卡反而更慢。四个指标不是独立的。比如你选了一个峰值算力很高的加速器但如果显存只有64GB、带宽也一般跑一个70B模型时要么塞不下要么每次读取权重都耗时巨大实际性能会很难看。2. 算力账、访存账和KV Cache账LLM负载为什么让人睡不着2.1 先拆解一次Transformer前向到底在算什么任何讨论LLM硬件的文章都绕不开Transformer。但我见过的资料大多讲得太粗我还是用自己理解的方式拆一下一次前向过程主要两部分。第一部分是Self-Attention自注意力做的事情简单说就是三个矩阵乘——查询和键算相似度然后对值做加权。如果把序列长度写为s模型维度写为d这部分计算量大约正比于s²d注意那个平方。序列越长计算量增长得越快。第二部分是Feed-Forward Network前馈网络它对每个token独立做两次大矩阵乘计算量正比于sd²和序列长度是线性关系。2000token的上下文时前馈网络的计算量通常高于注意力等上下文冲到8000、16000注意力部分会迅速追平甚至反超。硬件加速器对待这两部分的态度完全不同。前馈网络是典型的稠密矩阵乘GPU爱死这种负载了只要矩阵够大效率能拉到80%以上。而注意力的核心是“小矩阵在内存里来回搬”单次计算量小但数据搬运频繁这时候显存带宽而不是峰值算力在起作用。2.2 prefill和decode两个阶段的瓶颈不一样LLM推理还有一个特别容易被忽视的特征——它不是一个连续等量计算的流水线而是分成两个截然不同的阶段。prefill预填充你输入一整段Prompt模型一次把整段token的中间状态算出来。这个阶段是密集计算时间主要花在把所有Prompt并行处理上硬件快不快看的是TB级别的算力和矩阵效率。decode解码模型逐token生成输出每生成一个token都把整个权重矩阵重新读一遍再结合KV Cache算下一个。这个过程在计算量上小得多但极依赖“把几百GB权重从头到尾刷一遍”的访存速度。我记得第一次用性能分析工具去看模型时发现decode阶段的GPU算力利用率不到10%显存带宽却拉到90%以上。那一刻才真正理解为什么行业里都说“LLM推理是memory-bound负载”。如果你只盯着理论算力选加速器方向就错了。2.3 算一笔带KV Cache的账这里给大家一个用过的估算公式方便评估自己的场景。一次decode阶段把模型权重全部读一遍的时间可以近似为耗时 ≈ 模型权重体积GB / 显存带宽GB/s假设模型权重是13GB用A系列GPU带宽在2TB/s左右那么一次权重读入的时间是6.5毫秒。这还没算KV Cache读取和计算时间。如果换成一台带宽只有200GB/s的加速卡这个时间直接变成65毫秒单用户延迟立刻爆掉。所以当你看到某些加速卡的TOPS很高但带宽很低时就要警惕这东西也许适合做训练也许适合做图像模型但跑LLM decode很可能力不从心。反过来很多面向LLM设计的推理加速器会把带宽做得很激进有的甚至放弃一部分峰值算力换取更大的片上SRAM和更高带宽的HBM这就是针对LLM负载做的取舍。3. 主流加速路径的实际体验量化、稀疏化、KV Cache压缩3.1 低精度计算FP16、FP8、INT8、INT4怎么选我最早做硬件选型时花了很多时间在量化方案上。核心思路其实一句话把权重精度降下来体积变小带宽压力直接下降。FP162字节是基础精度FP81字节能把模型体积减半INT81字节和FP8类似但对数值范围处理不同——FP8适合动态范围大的参数INT8适合分布均匀的权重INT4半字节能把体积再砍一刀但模型精度的风险就显出来了。精度每参数字节数相对体积典型硬件支持适合场景FP16/BF1621x几乎所有AI加速器基准配置FP810.5x新代GPU/推理卡服务端高吞吐INT810.5x多数NPU/ASIC中低风险压缩INT4GPTQ/AWQ等0.50.25x部分定制卡,需算子适配端侧与内存受限实测下来7B到13B这个量级的模型用INT8权重配合量化感知或训练后量化质量下降通常可控。等到了INT4就得看具体任务了——生成代码和写散文的容错能力完全不一样。我在代码生成场景里跑了INT4碰到复杂语义逻辑时错误率明显上浮后来还是退回INT8。3.2 稀疏化与MoE硬件层面的“挑软柿子捏”如果你跑的是一个MoE混合专家架构的模型整个负载的特性会跟稠密Transformer差很多。大部分token在每一层里只激活少数几个专家理论计算量大幅下降但实现起来需要一套能把“哪个专家在哪颗卡上”记清楚的路由逻辑。传统GPU上跑MoE麻烦在于专家并行时token要频繁从一颗芯片跳到另一颗互联带宽就成了瓶颈。专门为MoE优化的加速器会在片上缓存路由表并且把专家尽量安排在同一个物理域里敲定跳转路径。实际测试里MoE模型在适配好的加速器上吞吐可以做得很高但如果芯片本身的调度单元和外部交换机不给力这个收益会被通信全部吃回去。稀疏化另一个方向是权重剪枝。比如50%结构化剪枝后稠密矩阵乘可以用稀疏算子跑。但要提醒的是很多加速器嘴上说支持稀疏计算实际库函数只对特定稀疏模式有效率不是所有零都能跳过。做硬件选型前先拿自己的模型跑一遍稀疏算子测速别信白皮书。3.3 KV Cache压缩被严重低估的加速器功能KV Cache的问题直接决定并发上限。一个长对话的KV Cache可能占掉好几GB显存这就意味着同一条卡上能服务的并发用户数量急剧下降。硬件加速器如果想提升并发能力最直接的办法就是内置高效KV Cache管理常见做法包括连续式KV Cache存储把KV块按token顺序连续存放不像传统做法按层和头去切分这样减少碎片化空间浪费。块式分配与重复数据去重多个系统提示词共享相同的缓存块省掉重复占用的显存。KV Cache量化把缓存的数值精度降低到INT8或FP8显存占用直接砍半。这些优化在纯GPU方案里也要靠vLLM这类框架的PagedAttention做但专用加速器会把它们做到硬件调度层面效果更稳定。我测试过其中一款推理卡它宣称“显存有效利用率比同容量GPU高出80%”实际上就是在KV Cache管理上做得很细让同样的物理显存塞下了更多并发会话。3.4 每台加速器都有自己的脾气算子是照妖镜这里必须插一段我踩过的坑买回来的加速卡官方给的demo跑得飞快一上我们自己的模型就崩了。原因永远是算子覆盖不完整。LLM服务里除了常规矩阵乘还有大量特殊算子——RoPE位置编码、FlashAttention中的一个fused kernel、grouped query attention的reshape、softmax的online实现。这些算子如果加速器没有原生实现推理框架就会回退到CPU性能一落千丈。评估加速器时不要只看benchmark里的大矩阵乘数据一定要把目标模型里每个算子在部署工具链里的支持情况列一遍缺哪个能手动自定义算子解决也行得让工程师评估工作量。4. 硬件最终要靠软件喂饱推理引擎与编译优化的配合4.1 PagedAttention这类技术干的是什么活上一节已经提到KV Cache管理一次真正让GPU显存利用率提升的软件创新就是字节跳动和UCSD联合提出的PagedAttention也是vLLM推理引擎的基石。它的思路借鉴操作系统里的分页机制。传统KV Cache是按照完整对话块预先分配的显存碎片严重实际利用率可能只有60%左右。PagedAttention把KV Cache切成固定大小的块按需分配放置到不连续的内存页里。这让显存碎片几乎消失同时允许跨请求共享公共前缀像系统提示词这种内容就不需要每人为它单独缓存一份。对硬件加速器来说PagedAttention这种按块读KV Cache的模式对存储控制器提出了很高要求。你在选专用加速器时要确认它的运行时是否对接了vLLM或TensorRT-LLM并原生支持页式KV分配如果没有显存能有效利用的空间会大打折扣。4.2 算子融合与静态图为什么CPU“捣浆糊”不行LLM模型图里有几十上百个算子。如果不做融合每个算子都要启动一次kernel、把中间结果写到显存、再读回来。这些操作的性能开销虽然每个都不大但累积起来占比相当可观。推理引擎和编译器会做“算子融合”把相邻的线性、归一化、激活函数合并成一个kernel减少中间数据的搬移。我用TensorRT-LLM做过一次融合前后对比把一组7个可以合并的算子做fuse之后单次推理耗时下降了18%并且显存访问量大幅减少。对硬件加速器来讲它的编译栈是不是做足了这个功夫几乎决定了它能不能把芯片吃透。建议在选型时直接要求厂家提供目标模型的计算图优化报告看看有多少算子被融合多少个还是逐算子执行的状态。4.3 调度和并发伺候生成式服务的脾气同样一张卡给的batch size是1和连续动态batch吞吐天差地别。生成式服务有一大特点每个请求的生成进度完全不同。有的prompt已经在输出第80个token有的还在prefill阶段。如果调度器不支持连续批处理每来一个请求就得等当前batch整体做完卡上的空窗期会非常明显。很多推理加速卡会专门优化这个调度逻辑。它们支持抢占式的“prefill/decode插入”在decode间隙插入新请求的prefill计算把本来浪费的算力补上。实际操作里我对比过开启连续批处理后卡上最终吞吐提升了两倍多。这件事提醒我们硬件加速器够不够好调度软件的能力必须放在第一优先级去考察。5. 我实测的几款硬件方案和几个结论5.1 测试怎么做的因为公司规模不算大我们没有上来就买昂贵设备而是用云服务商提供的几类加速实例加上本地的一张推理卡做了横向测试。模型用同一个开源7B和13B版本精度保持INT8词表、温控参数都一样。评价口径是三条单用户首token延迟、稳定并发下的吞吐token/s、单位成本吞吐。在实际敲定时我不会只看总吞吐因为不同场景的倾向完全不同做内部员工服务首token延迟最重要做批量离线生成成本吞吐更重要。5.2 测试结果与原理解释我把测试结果列成一张简表同时标注原因方案单用户首token延迟64并发吞吐单位成本吞吐关键观察通用GPU A显存带宽大低高中最稳定生态最成熟通用GPU B算力高但带宽一般中中中decode阶段瓶颈明显专用推理卡C中低很高高配合部署栈后优势显著端侧NPU模拟深度压缩高极低低只适合低并发、低时延需求不敏感的场景那个“专用推理卡C”让我印象最深单卡并发吞吐能做到两张GPU大概80%的量但功耗只有40%单位成本算下来差了一截。不过它也有明显前提——模型算子全部踩在它支持的范围内且推理引擎必须用它的专有版本。我们换过一个算子集更复杂的模型后优势就缩小了。所以结论是专不专用取决于你手里模型的算子长得乖不乖。5.3 选型的决策树什么时候该换专用加速器我后来给自己整理了一套决策逻辑分享给大家做个参考先看模型体积和显存关系。如果模型权重加KV Cache已经顶到卡容量的95%优先考虑做量化和KV Cache压缩不一定急着换硬件。再看decode阶段带宽利用率。用工具跑一轮压测如果算力利用率低而带宽利用率高说明瓶颈确实是访存换带宽更强的卡是合理动作。然后看负载形态。如果请求量平稳、上下文长度中等专用推理卡的收益通常可观如果请求长短差异极大、模型一直在变建议还是保留通用GPU的灵活性。最后看团队能力。如果你们有能力维护自定义算子库和编译栈专用加速器才值得上做不到就别欠技术债。这套逻辑帮我避开了几次冲动的采购。有一次厂商拿来一台很便宜的加速器白皮书数据很漂亮但我用上面第一条和第三条一卡发现自己模型做INT4量化后效果不能接受而且负载波动巨大就放弃了。6. 端侧与云侧的分工LLM加速器不只在机房6.1 端侧加速器要解决的另一类问题聊完服务器端的加速再聊聊端侧。最近很多手机、PC、边缘盒子都开始内置NPU宣传里都写着“端侧跑LLM”。这个趋势对整个行业的影响被远远低估。端侧设备和数据中心设备是两个物种。数据中心卡可以塞200W功耗、几百GB/s带宽的HBM端侧芯片功耗被限制在10W以内连散热都挤不出来。所以端侧加速的核心动作是“把模型压缩到能塞进片上内存”这比任何硬件算力都关键。我见过一个2B模型量化到INT4之后大约1GB能够塞进中高端手机NPU的可用内存跑一个不到10token/s的推理响应延迟在千毫秒级不惊艳但对“离线可用”这个需求来说已经是质变。6.2 混合部署的真实需求什么时候值得把模型推上端侧云侧部署和端侧部署不是互替关系而是一种分工。我目前给团队定的原则很朴素需要最新知识、超大上下文、复杂工具调用的任务放云侧。要求毫秒级响应、网络差、数据不能出设备的任务放端侧。常见开场白和固定话术甚至可以完全在端侧缓存减少云端调用成本。这种“云端异构”组合才是大多数实际项目真正能用上的加速方案。因为纯端侧能力受限纯云侧又贵又怕断网两边混着一拉用户体验和成本就平衡了。7. 我的几点实操体会如果让我总结这段踩坑经历第一句话是别把“AI硬件加速器”当成一键加速的魔法棒它是一个需要你用负载特性去匹配的体系。多测、多对比、用真实模型跑压测比任何厂商benchmark都有说服力。测试的时候设好同样的量化精度、同样的上下文长度、同样的并发模型否则数据根本没意义。第二研究KV Cache管理的时间性价比极高。对LLM推理来说显存管理优化往往比换更贵的卡更见效。第三如果你的业务还在快速演进阶段性地租云资源测试专用加速实例比直接采购硬件安全得多。最后一个小技巧在用新加速器前先在目标模型上开启性能剖析记录每个算子的耗时分布把这个分布图和新技术栈的算子支持清单对比。哪块的算子耗时占比大、又处于不支持列表里就优先攻它。很多时候一个独立算子的适配能解决整个加速器“跑不起来”的魔咒。现在我们的LLM服务已经稳定运行在混合加速架构上高峰期延迟回落到500毫秒以内成本比最初的全GPU方案降了40%。我不觉得这就是终点大模型技术还在变MoE、超长上下文、多模态都会改变硬件负载特征但把“算力、带宽、显存、调度”这四个词刻在脑子里后面再怎么变你也能很快找到适合自己场景的硬件加速器。