这两年只要碰LLM基本逃不开一个问题算力从哪来。模型参数从几十亿涨到几千亿每次回复都是一个 token 一个 token 蹦出来的每蹦一个 token背后都是整张大模型在前向计算一遍。AI硬件加速器正是这个背景下绕不开的关键词。它不单指大家天天挂在嘴边的那张显卡而是一整套为 AI 计算设计的芯片和系统GPU、NPU、FPGA、存算一体都算。这篇文章我打算从部署视角聊聊加速器选型、推理优化和实际踩坑尤其适合正在把 RAG、Agent 这类复杂应用落到本地服务器的工程师。1. 为什么LLM是AI硬件加速器的主战场1.1 从模型参数到显存容量一张表算清推理需求先说一个很容易被忽略的事实LLM 推理不像普通图像分类那样输入一张图、输出一个结果就结束了。它是一个自回归过程模型每生成一个 token都要把自己的全部参数再参与一次计算。这意味着参数规模直接决定了你的显存底线。拿现在常见的 7B 模型举例如果用 FP16 存储权重7B 个参数乘以 2 字节大约是 14GB。这还没算激活值、KV Cache、临时缓冲区和框架本身的开销。实际操作里一张 24GB 显存的卡跑 7B 模型已经需要精打细算想跑 13B 甚至 70B要么上大显存的专用卡要么做量化要么把模型切到多张卡上。我当时给客户做模型选型时习惯先列一张需求估算表模型规模权重精度权重显存估算建议最小显存可参考的硬件1B~3BFP162GB~6GB8GB消费级GPU、部分NPU7BFP1614GB24GBRTX 4090、A500013BFP1626GB48GB*双卡拼接、A600070BFP16140GB160GB*多卡集群、专用AI卡70BINT870GB96GB*多卡集群、专用AI卡这里加星号的意思是要留足额外开销。不要按“权重刚好放下”来采购硬件实际跑起来KV Cache 和并发请求会把显存迅速吃满。我见过不少团队买了一张 24GB 卡以为能跑 7B 模型结果一尝试加载就 OOM就是因为没算上下文长度和并发数。1.2 GPU不够用的场景长上下文、高并发和边缘端很多人刚开始做 LLM 应用时喜欢说“GPU 是万能的”但真正遇到这三个场景会发现普通 GPU 也很吃力。第一个是长上下文。现在模型动不动就支持 128K、200K token但上下文越长KV Cache 占用就越大。如果你用 GPU 单卡跑一个 70B 模型权重可能已经占了 140GB上下文再顶到几万字KV Cache 轻松再吃掉几十 GB。这时候传统 GPU 的显存带宽会被频繁的数据搬运拖住专门为 LLM 设计的加速器反而更合适因为它们往往在片上缓存和低精度计算上做了更多优化。第二个是高并发。在线产品不可能让用户排队等响应。当并发请求同时进来推理框架会把多个请求拼在一个 batch 里处理。batch 越大显存开销越高同时对算力峰值的要求也越高。普通 GPU 不是不能跑而是成本飞快上涨分摊到每个 token 的成本可能高到让你怀疑人生。第三个是边缘端。医疗审核、办公助手、工厂设备问答这类场景数据不能出内网又对实时性有要求。重型 GPU 塞不进边缘盒子这时候 NPU、FPGA 甚至存算一体芯片才是更现实的选择。比如中药处方审核这类垂直场景模型不大但隐私要求高用一块端侧 NPU 跑量化后的模型就很合适。所以你现在再回看“AI硬件加速器”这几个字它不是一个空洞概念而是被这些实际需求一点点逼出来的产品方向。Open LLM Leaderboard 这类开源公开榜单之所以被关注本质上也是大家都在找“同一个模型在哪种硬件上跑得又快又便宜”。2. GPU、NPU、FPGA、存算一体LLM加速器件类盘点2.1 通用GPU生态和算力都过剩但钱和电也很多NVIDIA 的 CUDA 生态是过去十年积累下来的最大壁垒。PyTorch、vLLM、TensorRT-LLM 都对它支持得最好新出的算子、新的量化方法通常也是 CUDA 平台先行。所以对大多数团队来说第一块加速器就是 NVIDIA GPU这没什么好犹豫的。但通用 GPU 的问题也很明显贵、功耗高、不一定适合纯 Transformer 结构。它的设计初衷是图形渲染和通用并行计算里面有大量单元并不是为自回归生成服务的。你用一张旗舰卡跑 LLM真正发挥出价值的可能只有其中一部分计算单元剩下大部分时间都在做数据搬运和等待。用 GPU 时我的建议是优先看显存容量和显存带宽而不是只看算力。LLM 推理在很多情况下是“显存带宽受限”的任务尤其在小 batch 场景下计算单元经常饿肚子数据从 HBM 运到核心的速度跟不上。所以 H100、A100 这类带高带宽 HBM 的卡比单纯频率高的消费级卡更适合做服务端推理。还有一点要提醒CUDA 版本、PyTorch 版本、cuDNN 版本必须提前锁死。我遇到过在一台新卡上跑老代码flash-attention 怎么都编不过最后发现是显卡架构没设置对白折腾了两天。2.2 专用ASIC/NPU为Transformer堆料能效比更高ASIC 和 NPU 是“为 AI 而生的专用硬件”。Google TPU、各家云厂商自研的推理芯片、以及很多端侧 NPU都属于这一类。它们的设计通常有几个共同点强化矩阵乘法单元支持 FP8、INT8、INT4 这类低精度计算增加片上存储和高速互连目的是把 Transformer 结构里的矩阵乘法和数据搬运效率做到极致。好处是能效比高单位功耗算力强跑大模型时成本更有竞争力坏处是生态相对封闭很多模型和算子需要在特定框架里适配后才跑得起来。部署这类硬件时别只盯峰值算力。你要确认三件事第一目标模型能不能在这个硬件上完整跑通第二常用的 vLLM 或自家推理框架是否已经适配第三算子是否覆盖了新出来的 FlashAttention、PagedAttention 这些优化。如果这三项都没问题再用“Open LLM Leaderboard 同款模型同款硬件的线上指标”做交叉验证会比厂商宣传页可靠得多。2.3 FPGA与存算一体边缘部署和特定推理场景的选择FPGA 的特点是逻辑可以重新配置。模型算子变来变去FPGA 可以按需调整数据通路对特定模型实现比较灵活的优化。缺点也很直接频率低、通用软件栈弱、开发周期长。它适合那些请求模式非常固定、延迟要求极高、但功耗和预算卡得很死的边缘场景。存算一体则是另一个路线在存储单元附近直接完成计算减少数据搬运。这个概念听起来很美因为传统冯诺依曼架构最大的瓶颈就是“搬数据”比“算数据”更费电。实际放到 LLM 推理里存算一体芯片很适合端侧小模型、低功耗场景但在大模型训练和高强度服务端推理场景还有很长的路要走。如果你要写一套不绑定特定硬件的推理服务可以考虑 ONNX 格式作为中间层。ONNX 能把模型统一成中间表示再通过不同的执行 provider 调用 GPU、CPU 或 NPU。好处是降低迁移成本坏处是部分特殊算子可能不被某个 provider 支持所以要做完整回归测试。2.4 选型参考用三个问题决定加速器形态不要把选型当成“哪家芯片强就用哪家”的单选题。我一般会先问三个问题。第一模型在什么规模是 1B、13B 还是 70B这决定了你需要多大的显存/内存空间和算力规模。第二请求是实时交互还是离线批处理交互场景对首 Token 延迟敏感需要更好的流水线和 KV Cache 优化离线批处理可以接受一次排队挤很多请求对单卡峰值算力更依赖。第三卡和电力成本自担还是租用服务如果是 PoC云上按需租卡很划算如果长期满负荷运行自建专用加速卡或者用云上的裸机型可能更省钱。表格整理会更直观场景推荐加速器形态原因开发调试、小模型微调消费级GPU性价比高、生态成熟7B~13B在线服务数据中心级GPU或专用AI卡显存带宽、并发能力强70B以上多卡推理多卡GPU集群或专用ASIC集群需要高速互连和更大的显存池边缘端、内网部署NPU、FPGA功耗低、可定制、满足隐私要求这个表不是铁律但至少能帮你跳开“只看单卡算力”的误区。3. 让LLM在加速器上跑得更快推理优化实操3.1 量化INT8、INT4能省多少显存和带宽量化是现在跑 LLM 必须掌握的手段。原理很简单参数权重用 FP16 表示会占用 2 字节换成 INT8 就只占 1 字节换成 INT4 只有大约 0.5 字节。显存占用直接按这个比例降。比如 7B 模型FP16 权重约 14GBINT8 约 7GBINT4 大约 3.5GB。如果任务又把上下文顶得很长显存还剩很多空间给 KV Cache模型就不会频繁 OOM。精度损失要分场景看。通用问答、摘要场景下INT8 几乎无损INT4 会有轻微表达损失但大多能接受到了数学推理、代码生成这类对逻辑敏感的场合INT4 可能会让结果变差关键甚至需要回退到 FP16。所以我从不建议“一刀切量化”而是先拿一份压测集把三种精度都跑一遍看输出质量和延迟哪个优先级更高。实际操作时可以用 GPTQ 或 AWQ 离线量化模型再用 vLLM 加载。收益不只是显存变小推理速度在不少硬件上也会变快因为权重小了单位时间能从显存搬到计算单元的数据量就更多了。对带宽受限的芯片来说这直接等于更快的 token 生成速度。3.2 并行切分张量并行和流水线并行怎么配合当单卡放不下模型时就要做并行切分。最常见的是张量并行和流水线并行。张量并行是把一个 Transformer 层里的矩阵切到多张卡上大家一起算同一个层。它需要高带宽低延迟的卡间通信所以 NVLink 和高速互连很重要。如果你用 PCIe 连接多张卡切分后通信开销可能比计算还大速度根本提不上去。很多框架里有tensor_parallel_size参数设成 2、4 或 8但调参之前最好先在集群里测一下通信矩阵。流水线并行则是按层切模型前面的层在卡 0中间层在卡 1后面的层在卡 2。它通信压力小一些但每张卡同时只处理一个 batch 的一部分层会有空档需要把多个 micro-batch 搞成流水线才能把卡填满。实操建议是优先尝试张量并行因为 LLM 自回归过程中每步都要算全模型张量并行的利用率往往更高。如果显存还是不够再加流水线并行。框架方面vLLM、TensorRT-LLM 都封装了这些策略直接指定并行度即可但你得对框架源码有点了解不然出了问题很难排查。3.3 KV Cache长上下文场景下最大的显存黑洞KV Cache 是 Transformer 模型加速的关键但也是显存黑洞。模型每生成一个 token都会把当前时刻的 Key 和 Value 存下来供后续注意力计算复用。上下文越长KV Cache 越大而且它是随着序列长度线性增长的。很多项目在短文本测试时一切正常一旦上了 RAG 知识库用户问题附带了几千字的文档内容KV Cache 立刻占用暴涨延迟也肉眼可见地变差。解决方向有几个一是用支持 PagedAttention 的推理框架。PagedAttention 类似操作系统的虚拟内存分页可以把显存碎片利用起来vLLM 就是靠这个把吞吐量提上去的。二是对 KV Cache 做量化比如 FP16 换成 FP8缓存大小减半精度损失在多数场景里可控。三是选模型时优先看 GQA分组查询注意力架构它本身就用更少的 KV 参数长上下文显存占用更友好。部署的时候一定要在框架里预留max_model_len和gpu_memory_utilization参数。我一般会留 80%~90% 的显存给模型剩下给缓存池和系统用。如果设得太满服务跑一段时间就会被碎片和临时显存压力打垮。3.4 压测指标吞吐量、首Token延迟的正确测法评估加速器配置到底行不行不能只看“模型加载成功”或“单次生成感觉挺快”。标准做法是用真实压力打一打。几个核心指标首 Token 延迟TTFT指的是从用户发起请求到第一个字出现的时间在线交互场景更关注它单 Token 延迟TPOT指每生成一个 token 的间隔吞吐量指的是系统单位时间内能处理的请求或 token 总数。用 vLLM 这类框架时通常会开continuous batching它能在推理过程中动态拼 batch极大提升吞吐。压测时要模拟真实并发不要只发一个 curl 测试。我常用三类并发单路、5 路、20 路分别统计 TTFT、TPOT 和最大排队时延。压测结果如果出现“并发一高TTFT 飙升到 5 秒以上”那大概率是 batch 显存不够或者 GPU 显存带宽打满了。这时候要么减max_num_seqs要么换更高带宽的硬件要么把请求切到离线管线而不是继续加机器。4. 部署LLM硬件加速器的常见坑与排查办法4.1 CUDA、PyTorch、vLLM版本不匹配算子莫名失效这是最容易遇到、也最容易让人心态崩掉的问题。很多团队从 GitHub 拉了一个项目默认用最新版 PyTorch结果 vLLM 还没跟上新版本编译报错一堆或者换了新的 GPU但 CUDA 驱动太老计算能力不匹配flash-attention 直接摆烂。排查这类问题我总结了一个流程先从官方容器镜像开始比如 NVIDIA NGC 的 PyTorch 容器版本组合是经过测试的再确认 GPU 的 CUDA Compute Capability对应 PyTorch 编译时的TORCH_CUDA_ARCH_LIST最后再去动框架的版本升级。顺序别反否则你会在无数依赖冲突里打转。如果你用 ONNX 做跨平台部署也要小心不同 Execution Provider 的算子覆盖范围不一致。同一个模型在 CUDA provider 上跑得好好的切到某些 NPU provider 可能某个算子不支持速度突然暴跌。稳妥做法是把模型子结构拆开跑一遍单元测试别等上线了才发现。4.2 混合负载导致模型排队在线延迟飙升团队前期人手不够时喜欢“一张卡跑所有”训练、批量离线分析、在线 API 全部怼在一个加速器上。短期看省了预算长期看是灾难。离线任务往往吃满算力在线请求就会排队用户看到的就是“模型一直在转圈”。解决方案是分工。用专门的 LLM 网关做请求路由和优先级控制把交互请求导到延迟敏感的实例池把离线批处理扔到可容忍排队的池子。网关本身不一定是硬件但它是让硬件加速器发挥价值的关键一层。它还能做限流、配额和模型版本灰度避免某个用户把整卡资源占死。如果你对“模型明明配了足够硬件但总是报llm request failed这类错误”感到困惑多半也是请求量或者上下文长度超过了后端配置的上限。网关层把超长请求拆掉、或在源头限制上下文长度会比无限扩容更有效。4.3 RAG/Agent场景的Token消耗和显存压力比预期大很多团队做 RAG 时只关注“检索效果”没想到硬件压力会翻倍增长。原因在于每个用户请求都会把检索到的知识库片段拼进上下文一个大文档可能就是几千 token同时为了提升召回质量还可能引入 GraphRAG 或本体Ontology结构让知识片段带关系、带图结构定位更准但前处理也更重。如果把知识库中的每个知识点拆成实体和关系那实体本身就是一个 key用户需求是 query具体属性描述就是 value。这个 key-query-value 的思路非常适合做精细化的产品检索但代价是多跳检索和长上下文都堆到了 GPU 上KV Cache 占用和推理延迟直接上涨。Agent 场景更夸张一个 Agent 要完成一个任务可能拆成多轮工具调用每轮调用都会重新发一次 promptLLM 算力消耗成倍增加。这让“单次生成很快但整体体验很慢”成为常态。所以我建议在架构层面做缓存对相似的问题做语义缓存命中后直接返回别再让大模型硬算一遍同时对上下文做裁剪只保留和当前步骤最相关的知识片段。真正必要的长上下文再交给高带宽的大显存加速器。4.4 成本账采购、电费、折旧和云上预算AI硬件加速器不是一次性采购就结束。一台多卡服务器的功耗轻松几千瓦跑一年电费可能比部分硬件本身还贵。散热、机房空间、存储也是成本。如果你只是做几个人的内部工具买一台高配整机不如直接租云上的按需实例。如果模型稳定、请求量大按年预留实例或者自建机器显然更划算。我做采购决策时会算一笔总拥有成本硬件采购 云资源租用 电费 运维人时 芯片折旧。然后按“单位 token 成本”去比较不同加速器。这样选择的时候就不会被单一硬件的高昂报价吓住也不会被云平台的短期优惠迷惑。5. 一个端到端实例本地ERPLLM产品检索系统5.1 需求拆解与硬件选型以前接过一个本地 ERP 的产品检索增强项目场景很典型企业内部的物料、产品、供应商数据散落在多个系统里员工搜索时希望用自然语言提问系统能直接给出答案而不是列一堆表格让人自己翻。这个项目本质上就是“本地 ERP RAG LLM 产品检索”我用 Semantic Kernel 作为应用框架把向量检索和 LLM 调用串起来。由于数据不能出内网必须本地部署所以硬件不能选云。模型规模我先定为 7B~13B因为要读内部文档和长上下文太小模型理解能力不够太大又导致单卡放不下。最终选了一台 24GB 显存的加速卡做推理。为什么不用多卡因为业务并发初期也就几十个员工在用单卡配合量化足够覆盖首版需求省钱省事。这个决策背后就是前面讲的先压测再按峰值负载定配置别一开始就给四卡整机买委屈。5.2 部署和优化过程部署过程分四步。第一选模型和做量化。我挑了一个对中文理解较好的开源 13B 模型用 AWQ 量化成 INT4权重占用大幅下降给 KV Cache 留足了空间。同时测了 INT8 和 INT4 在测试集上的表现确保数据检索类问题不会因为量化损失太多。第二搭 RAG 链路。用 Semantic Kernel 的 TextMemory 组件把本地 ERP 的文档和产品说明全部切块、向量化。同时引入实体抽取把物料名称、供应商、规格参数整理成结构化的 key-query-value 三元组检索时既走向量召回也走关系匹配。第三调推理框架。部署 vLLM 服务开启 continuous batching设置gpu_memory_utilization为 0.9把常驻内存留给权重和 KV Cache。由于内部文档经常几千字我把输入上限控制在 8K token超出部分先做摘要再入模型。第四加 LLM 网关。网关负责把直播交互请求和内部批量处理请求分流。内部管理员跑报表分析时不会把员工提问的通道全部占死。网关还做了简单的语义缓存高频问题不再重复消耗硬件。5.3 实测效果与后续建议上线后员工提问“某型号喷头适配哪些客户设备”这类问题测试集上的准确率到了可以内部使用的水平。并发 5 路时首 Token 延迟平均在 0.8 秒左右单 Token 速度大概 20 tokens/s内部满意度明显好过以前翻报表的习惯。这个项目给我最大的体会是硬件加速器并不是越贵越好。模型规模、上下文长度、并发模型和优化手段共同决定最终体验。很多情况下把量化、KV Cache 优化和网关分流做好普通 24GB 卡也能扛住七八十人的内部工具需求反过来如果只堆硬件不管推理栈再大的加速器也容易被垃圾请求浪费掉。如果你也在评估自己的 LLM 应用我的建议是先用一张卡跑通全链路卡住瓶颈在哪再决定要不要加卡。量化、并行、缓存优化、负载分流这些手段能榨出的性能空间往往比你想的还大。等这些手段都上完再回头看硬件采购清单你可能会发现原本以为要的一箱机器其实只需要一两个节点就够了。