最近有个朋友找我帮忙评估一台LLM推理服务器的配置开口就是“预算内直接上最大显存的卡”。这种想法太常见了我一开始折腾AI硬件加速器的时候也是这么干的——盯着显存和算力看半天结果机器配下来跑7B模型确实飞快等换到70B模型加上KV Cache一算显存根本不够用性能直接崩。后来才慢慢搞清楚针对LLM的硬件加速器从来不是“选一张最贵的卡”那么简单它是一个围绕Transformer解码过程设计的整体系统显存容量、内存带宽、卡间互联、算子调度、量化策略每一样都会拖后腿。这篇文章我打算把从选型到部署的完整链路捋一遍重点回答三个问题LLM到底在“吃”硬件加速器的哪些资源不同加速器GPU、NPU、专用ASIC之间怎么选部署和调优时最容易忽略哪些坑。内容适合那些已经跑过大模型、准备搭RAG或Agent服务、或者想评估推理服务器采购方案的读者。文章基于我实际做过的部署项目参数和步骤都参考常见实践给出可以直接当作业来抄。1. 为什么说LLM的瓶颈不只是算力显存、带宽和互联的三角关系1.1 模型权重放不下一切加速都白搭很多人以为跑LLM最需要的是算力也就是FLOPS。实际上对大多数推理场景来说第一个被卡住的地方是显存容量。一个直观的算法7B参数模型用BF16精度存储权重就要占用7×214GB显存换成70B模型权重就要140GB。这还没算输入序列的中间激活值以及推理过程中不断增长的KV Cache。KV Cache这个词值得展开说一下。Transformer解码的时候每一步都要根据之前所有的历史token计算注意力于是会把历史token的Key和Value缓存下来避免重复计算。这个缓存会随着并发请求数和上下文长度线性增长。我常用一个简化公式估算显存占用 权重 KV Cache 激活值 预留余量。比如7B模型、BF16权重14GB如果单路上下文2048 tokenKV Cache大概还需要1GB左右看起来单卡24GB完全够。但如果是50路并发每路都保留2048 token的上下文KV Cache就要50GB起步。这时候24GB的卡瞬间就不够看了。这也是为什么很多加速器厂商会把“大缓存”“大内存”作为卖点。硬件加速器不只是把矩阵乘法算得快更要让整个模型“装得下留得住”。否则再高的FLOPS也只能闲置。1.2 算力利用率为何常常只有两成第二个容易误解的点是“算力利用率”。不少人在评测报告里看到一张加速卡的峰值算力是几百TFLOPS就觉得模型能跑多快。真实情况是LLM推理是一个高度“访存密集”的过程每生成一个token都要把权重矩阵和KV Cache搬运到计算单元。权重是一次性加载、反复使用但KV Cache是序列越长读得越多。矩阵乘法的计算强度虽然高但注意力部分却受制于内存带宽。我做过一个简单实验在同样的硬件上用原生PyTorch跑7B模型GPU利用率经常只有20%上下。等换用融合了FlashAttention和连续批处理的推理框架后利用率能提到50%以上。这说明硬件本身的FLOPS没变变的是让数据在片上更快流动的软件调度。反过来说如果你买了一台高算力加速器但不优化访存路径性能可能还不如一台带宽更高的中端卡。1.3 推理场景里内存带宽比峰值算力更值钱大模型推理有一个常被忽视的指标每token生成速度。这个速度的上限可以粗略估算为“内存带宽 ÷ 模型权重大小”。举个例子一张带宽为2TB/s的卡跑一个14GB权重的7B模型理论上每秒钟最多搬运约140次权重也就是每秒最多生成140个token。但实际还要算上KV Cache读取、激活计算、框架开销通常只能做到峰值的二分之一。如果换成一张峰值算力更高但显存带宽只有1TB/s的卡生成速度反而会慢一半。这也是为什么苹果统一内存架构能跑大模型但大家普遍反馈生成速度不够理想——内存容量确实大但带宽只有几百GB每秒跑7B模型都容易掉到个位数token每秒。所以选型时不要只看“显存多大”要重点看HBM带宽和内存架构。推理对带宽的需求往往比对算力更饥渴。2. 硬件加速器的真实分类GPU、NPU、TPU与LLM专用芯片怎么定位2.1 一张表格看懂主流产品的定位市面上的AI硬件加速器可以粗略分成四类通用GPU、HPC/AI专用GPU、AI芯片NPU/TPU、以及为Transformer深度定制的推理专用芯片。它们的核心区别在于生态成熟度、可编程性和能效比。我按自己的使用体验整理了一个对比仅供参考具体参数以官方发布为准产品类型代表产品显存/内存典型应用优势不足通用GPUNVIDIA RTX系列8-24GB本地实验、小模型微调便宜、生态好显存受限驱动受限数据中心GPUNVIDIA A100/H100、AMD MI30064-192GB大模型训练与推理生态最完善性能强贵功耗高采购周期长NPU/TPUGoogle TPU、昇腾、高通/苹果NPU视产品而定批量推理、端侧推理能效比高算子兼容性需要逐个验证专用推理芯片Groq LPU、Cerebras WSE片上SRAM为主极低延迟推理、高吞吐延迟极低省内存搬运软件栈封闭适用模型受限这张表不是让你直接照着买而是提醒你LLM加速器并不只有GPU。很多专用芯片把整个模型权重放进片上SRAM彻底绕开了“每生成一个token就要去HBM搬权重”的瓶颈所以单个token延迟能压到毫秒级。但它们对模型尺寸有限制超过片上存储容量的模型就尴尬了。2.2 GPU生态完备但功耗和成本很难受数据中心GPU依旧是绝大多数团队的首选原因很简单CUDA生态太强了从PyTorch到vLLM、TensorRT-LLM几乎所有LLM框架都对它做了优化。我在部署中基本上不需要担心算子不兼容的问题遇到问题也容易搜到社区方案。缺点是贵和功耗一张H100的典型功耗是700W一台双卡服务器再加上CPU和散热整机功耗轻松超过2500W。如果机房单机柜电力配额不够可能连开机测试都过不了。另外一个隐性成本是显存带宽的稀缺性。数据中心GPU会把带宽做成一个很大的卖点因为推理中它决定了token生成速度。你需要按自己的延迟目标去对表每秒生成30个token7B模型至少需要多少带宽我一般用“权重大小×目标token数”做粗估再留出30%余量这样选卡不会太离谱。2.3 NPU与专用ASIC能效比高但兼容性要仔细评估NPU和专用ASIC这两年的热度很高尤其是在AI PC和边缘设备上。它们最大的优势是能效比同样是做7B模型推理一些NPU的功耗只有GPU的三分之一非常适合7x24小时在线服务。但坏消息是你没法直接拿PyTorch代码往上跑。我踩过一次坑在一块NPU上跑一个经过AWQ量化的模型结果发现贪婪采样和Top-P采样两个算子在NPU工具链上存在差异同样的随机种子输出结果和GPU端不完全一致。后来翻文档才发现是float16误差和自定义算子没有完全对齐。哪怕是同一个模型不同加速器之间的数值细节也可能有区别。如果要生产环境落地必须先在目标硬件上跑一遍完整的回归测试而不能只靠GPU上的验证结果。专用推理芯片则在另一个极端延迟极低但灵活性差。如果你打算频繁换模型结构、做MoE稀疏模型、或者支持很长的上下文需要先确认软件栈是否支持这些特性。用一句行话说这毕竟是“专用加速器”专得越深泛化越难。3. 选型前必须算清的三笔账显存容量、互连带宽、总算力3.1 显存容量模型参数量、精度与KV Cache的关系选型第一步永远是算内存账。我一般按下面这个流程走确定模型参数量和部署精度。比如7B模型BF16权重14GBINT8约7GBINT4约3.5-4GB。估算峰值并发数和上下文长度计算KV Cache总占用。加上约10-20%的激活值和框架开销余量。用单卡显存去整除得出最少卡数。以70B模型BF16为例权重140GB如果目标是32路并发、每路4K上下文KV Cache大约还要几十GB。单张80GB的卡要么放不下要么放得下但batch size受限。实际部署时通常至少需要2张80GB卡而且显存利用率不能超过90%否则容易OOM。这里特别提醒不要拿“模型精度占用量”直接当全部需求。KV Cache的精度也可以单独配置默认FP16但实际可以用FP8或INT8量化能省出一大截显存。很多硬件加速器支持KV Cache量化开关这个属于部署阶段就能灵活调整的变量。3.2 互连带宽多卡并行时真正的短板一旦模型超过单卡显存就需要多卡并行。这时卡间互连带宽就成了新的瓶颈。NVIDIA的NVLink带宽能到900GB/s而PCIe 4.0 x16的理论带宽只有32GB/s差距接近30倍。如果你买了两张卡却只通过PCIe通信做张量并行时每步都要同步中间结果通信时延会直接把算力收益吃掉。我在一个双卡推理项目里做过验证7B模型用单卡能跑但为了并发故意拆到两张卡上结果因为PCIe带宽限制端到端吞吐反而比单卡还低。所以多卡方案必须搞清楚是走专用互联NVLink/InfiniBand还是普通PCIe是推理场景还是训练场景训练时通信更频繁对互连要求更高推理如果只是数据并行每个请求独占一张卡对互连的压力相对小。切忌只看“卡多”就以为一定更强。3.3 实测数据同样是7B模型不同硬件的表现差异下面是我做过的粗测数据不代表极限性能只展示数量级差。模型固定为7B量化版输入512 token输出128 token并发8路硬件配置显存首token延迟生成吞吐备注数据中心GPU A80GB约180ms约2000 tokens/s用vLLM长上下文优势明显中端GPU B24GB约400ms约800 tokens/sINT4模型显存够但带宽有限端侧NPU C32GB 统一内存约700ms约150 tokens/s功耗很低但生成速度一般可以看到即使模型一样硬件的差距也很大。这不是说端侧NPU不好而是要看场景如果做移动端离线对话150 tokens/s完全够用如果做高并发在线服务2000 tokens/s才是及格线。所以选型前一定要先把业务指标定下来并发多少、首token要多少毫秒内、每token生成速度多少。没有这些指标选型就是耍流氓。4. 从硬件到应用的桥梁框架选型、量化部署与算子优化4.1 为什么量化是加速器最好的朋友量化对LLM加速的效果立竿见影原因就是它同时压缩了权重和KV Cache的体积。权重从BF16降到INT8显存占用砍一半带宽需求也砍一半降到INT4显存占用只有原来的四分之一。很多硬件加速器的“算力优势”只有配合低精度才能发挥出来因为低精度计算单元的数量通常比高精度翻倍。但量化不是没有代价。我习惯用AWQ或GPTQ做4bit量化校准数据集尽量贴近真实业务。如果只是用一个通用文本集校准量化后的模型在代码生成或公司内部文档场景下可能会有明显质量下滑。另外要注意硬件对量化格式的支持程度有的加速器虽然兼容INT8但INT4效率反而很低需要查具体算子的实现。量化前先跑一个准确性基线再量化后跑同一批测试集两侧对比才不会“为了快而牺牲质量”。4.2 Kernel融合和Continuous Batching对硬件利用率的影响跑LLM的人常说“GPU的好戏在后头”指的就是算子层面的优化。FlashAttention把注意力计算重新组织减少了对HBM的往返读写PagedAttention让KV Cache可以像虚拟内存一样分页管理显存碎片大幅减少Continuous Batching则让不同请求的动态长度可以塞进同一个batch硬件利用率被狠狠拉高。所有这些优化本质上都是在帮加速器“少搬数据、多算数”。框架选型直接影响你能享受多少这些优化。vLLM对我的意义最大它把PagedAttention和Continuous Batching做成了默认能力TensorRT-LLM更适合对延迟有极致要求的场景但需要自己编译engine上手门槛高TGI来自HuggingFace胜在跟生态兼容。如果你们团队已经深度使用PyTorch也可以尝试PyTorch原生编译加CUDA Graph。总的来说先选一个主推的推理框架再针对硬件调优比一开始就搞多框架对比更高效。4.3 RAG和Agent场景下的加速器压力模型LLM硬件加速器不只是用来生成token也要承载周边组件。RAG场景里用户Query要先经过Embedding模型转成向量再去向量数据库检索最后拼接成Prompt喂给LLM。这个过程里向量检索的延迟主要由内存和存储带宽决定和LLM加速卡关系不大但Embedding模型的批量推理也需要一个小加速器如果并发高单独给它分一块卡或NPU也是值得的。更复杂的是Agent场景。一个Agent循环会有多轮工具调用每次调用LLM都相当于一次独立的推理往返。延迟是逐轮累加的所以硬件加速器的任务不只是单次对话快而是要让几十个并行Agent的循环稳定完成。我在做多Agent并发测试时发现显存里除了模型权重还要给中间的多轮会话KV Cache留足空间。否则跑到一半就容易因为KV Cache超限触发重新计算延迟直接翻几倍。这块儿的压力比你想的更容易算漏。5. 一次真实的LLM加速器部署复盘目标、过程与调参5.1 需求50路并发对话首token小于500ms我们当时的目标很简单内部知识库问答机器人7B模型要求50路并发对话不排队首Token延迟低于500毫秒生成速度不低于30 tokens/s7x24小时运行。预算有限没法直接上多张顶级卡。最终我们选择了一台拥有单张48GB数据中心级显卡的服务器显存带宽在同代产品里处于第一梯队并且支持BF16和FP8。当时有一些同事建议买双24GB卡理由是“双卡看着性能翻倍”。但我算了笔账7B模型量化后权重不到10GB单卡48GB足够容纳权重和50路对话的KV Cache没必要走多卡通信。双卡反而引入PCIe通信开销还得考虑NVLink缺失的问题。最终项目验证了这个判断单卡方案在成本和稳定性上都更优。5.2 配置用vLLM跑起来核心参数一口气说清我们的环境大致如下Ubuntu 22.04NVIDIA驱动和CUDA 12.xPython 3.10vLLM最新稳定版。启动命令里最关键的几个参数--model指定量化后的modelscope上拉取的模型路径。--max-model-len设置模型最大上下文长度我们设为8192。--gpu-memory-utilization设为0.92把显存大头预留给KV Cache而不是让框架默认值太保守。--max-num-seqs设为256允许更大的Batch配合continuous batching提升吞吐。--quantization设为awq开启4bit量化权重路径。--kv-cache-dtype设为fp8降低KV Cache显存占用。启动之后我用OpenAI兼容接口做测试单个请求的返回速度很快但并发一上来首token延迟就往上飙。这里的关键不是看单卡算力而是看KV Cache到底够不够大。我反复调整gpu-memory-utilization从默认的0.9调到0.92集群同时处理的请求数就上了一个台阶。5.3 调优prefill和decode阶段分开处理效果立竿见影进一步调优时我注意到混合负载下的延迟抖动很厉害。原因是一个大的prefill长Prompt输入会霸占显卡一段时间让正在decode逐token输出的请求集体“卡住”。解决方法是开启vLLM的chunked prefill把长Prompt切分成小块穿插在decode中间执行。开启后首token延迟的P95从900ms降到了600ms左右虽然没有完全达标但稳定性明显好多了。接下来是Batch Size的微妙平衡。Continuous Batching理论上Batch越大越好但实际中Batch过大会让batch内最长序列拖慢整体因为每个step都要对齐到最长的序列长度。我在加max-num-seqs时发现256比128好但升到512后收益不再增加显存却更紧张了。最后稳定在256。通过监控工具看到GPU利用率从40%提升到70%左右这就是Continuous Batching和量化带来的真实提升。5.4 验证压测工具与结果解读没有压测就没有调优依据。我推荐用vLLM自带的benchmark脚本再叠加llmperf做更贴近业务的并发压测。重点看四个指标首token延迟TTFT、每token生成时间TPOT、端到端延迟、吞吐量。监控显存占用和GPU利用率确认是否出现OOM或KV Cache回收频繁。最终结果50路并发下TTFT P95约580msTPOT约30ms也就是生成速度约33 tokens/s基本满足需求。吞吐最终能到1700 tokens/s左右。这个成绩看似没有把卡的峰值算力跑满但在成本和功耗限制下已经是可接受的了。如果再把上下文长度从4096调到8192同样的并发至少需要多预留10GB显存这就是另一个话题了。6. 硬件加速器落地时的几个常见误解与我踩过的坑6.1 “显存越大越好”的误区小模型用大卡反而浪费显存大的卡通常更贵而且为了造出大显存某些型号会牺牲内存带宽。如果你跑的是7B模型量化版24GB显存已经绰绰有余但换来的是3倍功耗和价格。我曾经为了“一步到位”选了80GB的卡结果业务方只跑7B模型加少量并发整机大部分时间利用率不到10%每年电费却居高不下。正确做法是用显存需求倒推卡型而不是先买大卡再想办法填满。6.2 只看算力不看功耗机房电力改造花掉一个月预算有一个项目我们按算力需求选了4张双宽高功耗卡结果安装到机柜时发现按机房现状只能提供一半电力。重新拉电、加散热、换机柜前前后后花了一个月预算。从那以后我把功耗作为0号指标对待先算总功耗再看机柜供电余量再定卡型。AI硬件加速器不是装完就完散热和供电会直接影响稳定性尤其是多卡满载运行一小时机箱内部的温度会快速升高。若散热设计不足加速卡会自动降频性能直接打折。6.3 CUDA能用不等于所有算子都能跑NPU/TPU的兼容性陷阱如果你的团队从GPU切到NPU或者专用ASIC最忌讳的假设就是“PyTorch能跑加速器也能跑”。实际上很多加速器提供了PyTorch兼容层但底层算子可能走的是不同的实现路径。RNN、GQA、MoE、长上下文注意力这些结构它们不一定都做了硬件优化有些会退回CPU甚至直接报错。我建议在选型阶段就准备一个“算子验证列表”把模型的每个关键模块都在目标硬件上跑一遍别等到部署时再发现不兼容。6.4 监控和容错加速器不是插上电就能稳定运行最后是一个经常被忽略的点监控。加速器的运行状态需要持续观察包括温度、功耗、显存占用、NVLink/PCIe错误计数、KV Cache缓存命中率。我们有个服务出现过隐性性能下降后来一看监控才发现是某张卡的PCIe链路从x16降到了x8通信带宽减半导致多卡并行任务出现周期性的卡顿。硬件加速器的故障不像软件报错那么明显它往往表现为“慢”而不是“挂”。所以从一开始就搭好监控比事后排查要省太多事。另一个容易被忽略的容错策略是“优雅降级”。当其中一张卡过热降频或者显存不足时推理框架能不能自动缩小batch size或者把部分请求降级到慢速路径这个能力直接决定了线上服务是“微抖动”还是“雪崩”。我在实际部署中会把这类降级策略写在配置里并且每周做一次故障演练确保真的发生的时候不会手忙脚乱。
LLM加速器选型部署：显存带宽、KV Cache与量化实战
最近有个朋友找我帮忙评估一台LLM推理服务器的配置开口就是“预算内直接上最大显存的卡”。这种想法太常见了我一开始折腾AI硬件加速器的时候也是这么干的——盯着显存和算力看半天结果机器配下来跑7B模型确实飞快等换到70B模型加上KV Cache一算显存根本不够用性能直接崩。后来才慢慢搞清楚针对LLM的硬件加速器从来不是“选一张最贵的卡”那么简单它是一个围绕Transformer解码过程设计的整体系统显存容量、内存带宽、卡间互联、算子调度、量化策略每一样都会拖后腿。这篇文章我打算把从选型到部署的完整链路捋一遍重点回答三个问题LLM到底在“吃”硬件加速器的哪些资源不同加速器GPU、NPU、专用ASIC之间怎么选部署和调优时最容易忽略哪些坑。内容适合那些已经跑过大模型、准备搭RAG或Agent服务、或者想评估推理服务器采购方案的读者。文章基于我实际做过的部署项目参数和步骤都参考常见实践给出可以直接当作业来抄。1. 为什么说LLM的瓶颈不只是算力显存、带宽和互联的三角关系1.1 模型权重放不下一切加速都白搭很多人以为跑LLM最需要的是算力也就是FLOPS。实际上对大多数推理场景来说第一个被卡住的地方是显存容量。一个直观的算法7B参数模型用BF16精度存储权重就要占用7×214GB显存换成70B模型权重就要140GB。这还没算输入序列的中间激活值以及推理过程中不断增长的KV Cache。KV Cache这个词值得展开说一下。Transformer解码的时候每一步都要根据之前所有的历史token计算注意力于是会把历史token的Key和Value缓存下来避免重复计算。这个缓存会随着并发请求数和上下文长度线性增长。我常用一个简化公式估算显存占用 权重 KV Cache 激活值 预留余量。比如7B模型、BF16权重14GB如果单路上下文2048 tokenKV Cache大概还需要1GB左右看起来单卡24GB完全够。但如果是50路并发每路都保留2048 token的上下文KV Cache就要50GB起步。这时候24GB的卡瞬间就不够看了。这也是为什么很多加速器厂商会把“大缓存”“大内存”作为卖点。硬件加速器不只是把矩阵乘法算得快更要让整个模型“装得下留得住”。否则再高的FLOPS也只能闲置。1.2 算力利用率为何常常只有两成第二个容易误解的点是“算力利用率”。不少人在评测报告里看到一张加速卡的峰值算力是几百TFLOPS就觉得模型能跑多快。真实情况是LLM推理是一个高度“访存密集”的过程每生成一个token都要把权重矩阵和KV Cache搬运到计算单元。权重是一次性加载、反复使用但KV Cache是序列越长读得越多。矩阵乘法的计算强度虽然高但注意力部分却受制于内存带宽。我做过一个简单实验在同样的硬件上用原生PyTorch跑7B模型GPU利用率经常只有20%上下。等换用融合了FlashAttention和连续批处理的推理框架后利用率能提到50%以上。这说明硬件本身的FLOPS没变变的是让数据在片上更快流动的软件调度。反过来说如果你买了一台高算力加速器但不优化访存路径性能可能还不如一台带宽更高的中端卡。1.3 推理场景里内存带宽比峰值算力更值钱大模型推理有一个常被忽视的指标每token生成速度。这个速度的上限可以粗略估算为“内存带宽 ÷ 模型权重大小”。举个例子一张带宽为2TB/s的卡跑一个14GB权重的7B模型理论上每秒钟最多搬运约140次权重也就是每秒最多生成140个token。但实际还要算上KV Cache读取、激活计算、框架开销通常只能做到峰值的二分之一。如果换成一张峰值算力更高但显存带宽只有1TB/s的卡生成速度反而会慢一半。这也是为什么苹果统一内存架构能跑大模型但大家普遍反馈生成速度不够理想——内存容量确实大但带宽只有几百GB每秒跑7B模型都容易掉到个位数token每秒。所以选型时不要只看“显存多大”要重点看HBM带宽和内存架构。推理对带宽的需求往往比对算力更饥渴。2. 硬件加速器的真实分类GPU、NPU、TPU与LLM专用芯片怎么定位2.1 一张表格看懂主流产品的定位市面上的AI硬件加速器可以粗略分成四类通用GPU、HPC/AI专用GPU、AI芯片NPU/TPU、以及为Transformer深度定制的推理专用芯片。它们的核心区别在于生态成熟度、可编程性和能效比。我按自己的使用体验整理了一个对比仅供参考具体参数以官方发布为准产品类型代表产品显存/内存典型应用优势不足通用GPUNVIDIA RTX系列8-24GB本地实验、小模型微调便宜、生态好显存受限驱动受限数据中心GPUNVIDIA A100/H100、AMD MI30064-192GB大模型训练与推理生态最完善性能强贵功耗高采购周期长NPU/TPUGoogle TPU、昇腾、高通/苹果NPU视产品而定批量推理、端侧推理能效比高算子兼容性需要逐个验证专用推理芯片Groq LPU、Cerebras WSE片上SRAM为主极低延迟推理、高吞吐延迟极低省内存搬运软件栈封闭适用模型受限这张表不是让你直接照着买而是提醒你LLM加速器并不只有GPU。很多专用芯片把整个模型权重放进片上SRAM彻底绕开了“每生成一个token就要去HBM搬权重”的瓶颈所以单个token延迟能压到毫秒级。但它们对模型尺寸有限制超过片上存储容量的模型就尴尬了。2.2 GPU生态完备但功耗和成本很难受数据中心GPU依旧是绝大多数团队的首选原因很简单CUDA生态太强了从PyTorch到vLLM、TensorRT-LLM几乎所有LLM框架都对它做了优化。我在部署中基本上不需要担心算子不兼容的问题遇到问题也容易搜到社区方案。缺点是贵和功耗一张H100的典型功耗是700W一台双卡服务器再加上CPU和散热整机功耗轻松超过2500W。如果机房单机柜电力配额不够可能连开机测试都过不了。另外一个隐性成本是显存带宽的稀缺性。数据中心GPU会把带宽做成一个很大的卖点因为推理中它决定了token生成速度。你需要按自己的延迟目标去对表每秒生成30个token7B模型至少需要多少带宽我一般用“权重大小×目标token数”做粗估再留出30%余量这样选卡不会太离谱。2.3 NPU与专用ASIC能效比高但兼容性要仔细评估NPU和专用ASIC这两年的热度很高尤其是在AI PC和边缘设备上。它们最大的优势是能效比同样是做7B模型推理一些NPU的功耗只有GPU的三分之一非常适合7x24小时在线服务。但坏消息是你没法直接拿PyTorch代码往上跑。我踩过一次坑在一块NPU上跑一个经过AWQ量化的模型结果发现贪婪采样和Top-P采样两个算子在NPU工具链上存在差异同样的随机种子输出结果和GPU端不完全一致。后来翻文档才发现是float16误差和自定义算子没有完全对齐。哪怕是同一个模型不同加速器之间的数值细节也可能有区别。如果要生产环境落地必须先在目标硬件上跑一遍完整的回归测试而不能只靠GPU上的验证结果。专用推理芯片则在另一个极端延迟极低但灵活性差。如果你打算频繁换模型结构、做MoE稀疏模型、或者支持很长的上下文需要先确认软件栈是否支持这些特性。用一句行话说这毕竟是“专用加速器”专得越深泛化越难。3. 选型前必须算清的三笔账显存容量、互连带宽、总算力3.1 显存容量模型参数量、精度与KV Cache的关系选型第一步永远是算内存账。我一般按下面这个流程走确定模型参数量和部署精度。比如7B模型BF16权重14GBINT8约7GBINT4约3.5-4GB。估算峰值并发数和上下文长度计算KV Cache总占用。加上约10-20%的激活值和框架开销余量。用单卡显存去整除得出最少卡数。以70B模型BF16为例权重140GB如果目标是32路并发、每路4K上下文KV Cache大约还要几十GB。单张80GB的卡要么放不下要么放得下但batch size受限。实际部署时通常至少需要2张80GB卡而且显存利用率不能超过90%否则容易OOM。这里特别提醒不要拿“模型精度占用量”直接当全部需求。KV Cache的精度也可以单独配置默认FP16但实际可以用FP8或INT8量化能省出一大截显存。很多硬件加速器支持KV Cache量化开关这个属于部署阶段就能灵活调整的变量。3.2 互连带宽多卡并行时真正的短板一旦模型超过单卡显存就需要多卡并行。这时卡间互连带宽就成了新的瓶颈。NVIDIA的NVLink带宽能到900GB/s而PCIe 4.0 x16的理论带宽只有32GB/s差距接近30倍。如果你买了两张卡却只通过PCIe通信做张量并行时每步都要同步中间结果通信时延会直接把算力收益吃掉。我在一个双卡推理项目里做过验证7B模型用单卡能跑但为了并发故意拆到两张卡上结果因为PCIe带宽限制端到端吞吐反而比单卡还低。所以多卡方案必须搞清楚是走专用互联NVLink/InfiniBand还是普通PCIe是推理场景还是训练场景训练时通信更频繁对互连要求更高推理如果只是数据并行每个请求独占一张卡对互连的压力相对小。切忌只看“卡多”就以为一定更强。3.3 实测数据同样是7B模型不同硬件的表现差异下面是我做过的粗测数据不代表极限性能只展示数量级差。模型固定为7B量化版输入512 token输出128 token并发8路硬件配置显存首token延迟生成吞吐备注数据中心GPU A80GB约180ms约2000 tokens/s用vLLM长上下文优势明显中端GPU B24GB约400ms约800 tokens/sINT4模型显存够但带宽有限端侧NPU C32GB 统一内存约700ms约150 tokens/s功耗很低但生成速度一般可以看到即使模型一样硬件的差距也很大。这不是说端侧NPU不好而是要看场景如果做移动端离线对话150 tokens/s完全够用如果做高并发在线服务2000 tokens/s才是及格线。所以选型前一定要先把业务指标定下来并发多少、首token要多少毫秒内、每token生成速度多少。没有这些指标选型就是耍流氓。4. 从硬件到应用的桥梁框架选型、量化部署与算子优化4.1 为什么量化是加速器最好的朋友量化对LLM加速的效果立竿见影原因就是它同时压缩了权重和KV Cache的体积。权重从BF16降到INT8显存占用砍一半带宽需求也砍一半降到INT4显存占用只有原来的四分之一。很多硬件加速器的“算力优势”只有配合低精度才能发挥出来因为低精度计算单元的数量通常比高精度翻倍。但量化不是没有代价。我习惯用AWQ或GPTQ做4bit量化校准数据集尽量贴近真实业务。如果只是用一个通用文本集校准量化后的模型在代码生成或公司内部文档场景下可能会有明显质量下滑。另外要注意硬件对量化格式的支持程度有的加速器虽然兼容INT8但INT4效率反而很低需要查具体算子的实现。量化前先跑一个准确性基线再量化后跑同一批测试集两侧对比才不会“为了快而牺牲质量”。4.2 Kernel融合和Continuous Batching对硬件利用率的影响跑LLM的人常说“GPU的好戏在后头”指的就是算子层面的优化。FlashAttention把注意力计算重新组织减少了对HBM的往返读写PagedAttention让KV Cache可以像虚拟内存一样分页管理显存碎片大幅减少Continuous Batching则让不同请求的动态长度可以塞进同一个batch硬件利用率被狠狠拉高。所有这些优化本质上都是在帮加速器“少搬数据、多算数”。框架选型直接影响你能享受多少这些优化。vLLM对我的意义最大它把PagedAttention和Continuous Batching做成了默认能力TensorRT-LLM更适合对延迟有极致要求的场景但需要自己编译engine上手门槛高TGI来自HuggingFace胜在跟生态兼容。如果你们团队已经深度使用PyTorch也可以尝试PyTorch原生编译加CUDA Graph。总的来说先选一个主推的推理框架再针对硬件调优比一开始就搞多框架对比更高效。4.3 RAG和Agent场景下的加速器压力模型LLM硬件加速器不只是用来生成token也要承载周边组件。RAG场景里用户Query要先经过Embedding模型转成向量再去向量数据库检索最后拼接成Prompt喂给LLM。这个过程里向量检索的延迟主要由内存和存储带宽决定和LLM加速卡关系不大但Embedding模型的批量推理也需要一个小加速器如果并发高单独给它分一块卡或NPU也是值得的。更复杂的是Agent场景。一个Agent循环会有多轮工具调用每次调用LLM都相当于一次独立的推理往返。延迟是逐轮累加的所以硬件加速器的任务不只是单次对话快而是要让几十个并行Agent的循环稳定完成。我在做多Agent并发测试时发现显存里除了模型权重还要给中间的多轮会话KV Cache留足空间。否则跑到一半就容易因为KV Cache超限触发重新计算延迟直接翻几倍。这块儿的压力比你想的更容易算漏。5. 一次真实的LLM加速器部署复盘目标、过程与调参5.1 需求50路并发对话首token小于500ms我们当时的目标很简单内部知识库问答机器人7B模型要求50路并发对话不排队首Token延迟低于500毫秒生成速度不低于30 tokens/s7x24小时运行。预算有限没法直接上多张顶级卡。最终我们选择了一台拥有单张48GB数据中心级显卡的服务器显存带宽在同代产品里处于第一梯队并且支持BF16和FP8。当时有一些同事建议买双24GB卡理由是“双卡看着性能翻倍”。但我算了笔账7B模型量化后权重不到10GB单卡48GB足够容纳权重和50路对话的KV Cache没必要走多卡通信。双卡反而引入PCIe通信开销还得考虑NVLink缺失的问题。最终项目验证了这个判断单卡方案在成本和稳定性上都更优。5.2 配置用vLLM跑起来核心参数一口气说清我们的环境大致如下Ubuntu 22.04NVIDIA驱动和CUDA 12.xPython 3.10vLLM最新稳定版。启动命令里最关键的几个参数--model指定量化后的modelscope上拉取的模型路径。--max-model-len设置模型最大上下文长度我们设为8192。--gpu-memory-utilization设为0.92把显存大头预留给KV Cache而不是让框架默认值太保守。--max-num-seqs设为256允许更大的Batch配合continuous batching提升吞吐。--quantization设为awq开启4bit量化权重路径。--kv-cache-dtype设为fp8降低KV Cache显存占用。启动之后我用OpenAI兼容接口做测试单个请求的返回速度很快但并发一上来首token延迟就往上飙。这里的关键不是看单卡算力而是看KV Cache到底够不够大。我反复调整gpu-memory-utilization从默认的0.9调到0.92集群同时处理的请求数就上了一个台阶。5.3 调优prefill和decode阶段分开处理效果立竿见影进一步调优时我注意到混合负载下的延迟抖动很厉害。原因是一个大的prefill长Prompt输入会霸占显卡一段时间让正在decode逐token输出的请求集体“卡住”。解决方法是开启vLLM的chunked prefill把长Prompt切分成小块穿插在decode中间执行。开启后首token延迟的P95从900ms降到了600ms左右虽然没有完全达标但稳定性明显好多了。接下来是Batch Size的微妙平衡。Continuous Batching理论上Batch越大越好但实际中Batch过大会让batch内最长序列拖慢整体因为每个step都要对齐到最长的序列长度。我在加max-num-seqs时发现256比128好但升到512后收益不再增加显存却更紧张了。最后稳定在256。通过监控工具看到GPU利用率从40%提升到70%左右这就是Continuous Batching和量化带来的真实提升。5.4 验证压测工具与结果解读没有压测就没有调优依据。我推荐用vLLM自带的benchmark脚本再叠加llmperf做更贴近业务的并发压测。重点看四个指标首token延迟TTFT、每token生成时间TPOT、端到端延迟、吞吐量。监控显存占用和GPU利用率确认是否出现OOM或KV Cache回收频繁。最终结果50路并发下TTFT P95约580msTPOT约30ms也就是生成速度约33 tokens/s基本满足需求。吞吐最终能到1700 tokens/s左右。这个成绩看似没有把卡的峰值算力跑满但在成本和功耗限制下已经是可接受的了。如果再把上下文长度从4096调到8192同样的并发至少需要多预留10GB显存这就是另一个话题了。6. 硬件加速器落地时的几个常见误解与我踩过的坑6.1 “显存越大越好”的误区小模型用大卡反而浪费显存大的卡通常更贵而且为了造出大显存某些型号会牺牲内存带宽。如果你跑的是7B模型量化版24GB显存已经绰绰有余但换来的是3倍功耗和价格。我曾经为了“一步到位”选了80GB的卡结果业务方只跑7B模型加少量并发整机大部分时间利用率不到10%每年电费却居高不下。正确做法是用显存需求倒推卡型而不是先买大卡再想办法填满。6.2 只看算力不看功耗机房电力改造花掉一个月预算有一个项目我们按算力需求选了4张双宽高功耗卡结果安装到机柜时发现按机房现状只能提供一半电力。重新拉电、加散热、换机柜前前后后花了一个月预算。从那以后我把功耗作为0号指标对待先算总功耗再看机柜供电余量再定卡型。AI硬件加速器不是装完就完散热和供电会直接影响稳定性尤其是多卡满载运行一小时机箱内部的温度会快速升高。若散热设计不足加速卡会自动降频性能直接打折。6.3 CUDA能用不等于所有算子都能跑NPU/TPU的兼容性陷阱如果你的团队从GPU切到NPU或者专用ASIC最忌讳的假设就是“PyTorch能跑加速器也能跑”。实际上很多加速器提供了PyTorch兼容层但底层算子可能走的是不同的实现路径。RNN、GQA、MoE、长上下文注意力这些结构它们不一定都做了硬件优化有些会退回CPU甚至直接报错。我建议在选型阶段就准备一个“算子验证列表”把模型的每个关键模块都在目标硬件上跑一遍别等到部署时再发现不兼容。6.4 监控和容错加速器不是插上电就能稳定运行最后是一个经常被忽略的点监控。加速器的运行状态需要持续观察包括温度、功耗、显存占用、NVLink/PCIe错误计数、KV Cache缓存命中率。我们有个服务出现过隐性性能下降后来一看监控才发现是某张卡的PCIe链路从x16降到了x8通信带宽减半导致多卡并行任务出现周期性的卡顿。硬件加速器的故障不像软件报错那么明显它往往表现为“慢”而不是“挂”。所以从一开始就搭好监控比事后排查要省太多事。另一个容易被忽略的容错策略是“优雅降级”。当其中一张卡过热降频或者显存不足时推理框架能不能自动缩小batch size或者把部分请求降级到慢速路径这个能力直接决定了线上服务是“微抖动”还是“雪崩”。我在实际部署中会把这类降级策略写在配置里并且每周做一次故障演练确保真的发生的时候不会手忙脚乱。
