先说一个我自己观察到的现象：很多人拿到一块新的人工智能加速卡，第一反应是看它的TOPS或TFLOPS，然后开始盘算“这卡跑大模型肯定飞快”。但真把LLM部署到生产环境后，结果往往和纸面参数对不上。同一套开源模型，用不同的硬件加速方案，吞吐能差四五倍；同一个硬件，换一种量化策略和推理框架，速度又能再翻一两倍。这件事的本质，是LLM的推理负载和传统深度学习的计算模式很不一样，硬件加速器能不能“对症下药”，比单纯的算力数字重要得多。
这篇文章不打算堆规格参数，而是从实际部署的角度，把“针对LLM的AI硬件加速器”这件事拆开讲：为什么LLM对内存带宽如此敏感、选型时真正要看哪几个数字、单卡到多卡场景怎么规划、量化怎么和硬件配合、以及我在真实项目里踩过的坑。适合正在做技术选型、准备私有化部署、或者被推理速度折磨得想换卡的人参考。
1. 通用CPU跑不动大模型：算力直觉与带宽真相
1.1 一次推理，两个阶段，各自的瓶颈完全不同
大模型生成一句话，很多人以为它就是“咔嚓一下”算完的，实际上内部是两步循环。
第一步叫prefill，也就是处理输入阶段。用户输入的提示词一次性灌进模型，模型要为每个token并行计算注意力。这个阶段的特点是计算量巨大，矩阵乘法密集，吃的是纯粹的浮点算力。GPU也好，NPU也好，只要峰值算力够，这个环节通常不会太慢。
第二步叫decode，也就是逐token生成阶段。模型每生成一个字，都需要把已经生成的所有字作为上下文，重新过一遍网络。这时候的计算从大矩阵乘法变成了“一个token对一整批权重”的向量矩阵乘法，计算量本身不大，但问题在于：每生成一个字，都要把模型全部权重从显存里完整读一遍。
这就引出一个很多新手忽略的事实：LLM推理是极度访存密集型的负载，尤其在decode阶段，内存带宽决定了生成速度的上限，算力反倒是次要的。
1.2 用一组数字说明为什么GPU/NPU能赢
假设有一个70亿参数的模型，权重用FP16格式存储，那么光参数就占14GB空间。在decode阶段，每生成一个token，这14GB必须被从显存搬进计算单元一次。如果你希望生成速度达到每秒100个token，那么有效内存带宽至少要：
14GB乘以100次每秒，也就是每秒1.4TB的读取速度。
普通桌面CPU配的是双通道DDR5内存，带宽大约每秒76GB左右，照这个数字换算，跑7B模型满打满算也就每秒5个token。服务器如果上8通道DDR5，勉强能到二三十GB每秒合计，翻个几倍也就每秒十几二十个token，而且CPU内部的矩阵计算单元还得跟上，实际只会更差。
再看GPU这边。一张RTX 4090的显存带宽在1TB/s左右，A100 80GB是2TB/s左右，H100到3.35TB/s。只要权重能被塞进显存，光是“读权重”这一关，GPU就能跑出每秒60到200个token的原始速度。这就是大模型加速器最本质的胜利：不是算得快多少，而是数据喂得快多少。
为啥H20这种算力不高的卡在LLM推理里表现很好？因为它配了高带宽大容量HBM显存，正好戳中decode阶段的命门。所以理解了带宽约束，后面很多选型困惑都会迎刃而解。
2. 看懂加速器参数：显存容量、带宽和算力三者的博弈
2.1 只看峰值算力的陷阱
厂商宣传最常见的参数是峰值算力，什么“几百TOPS”“上千TFLOPS”。但这个数字对LLM推理的参考价值很有限，尤其是如果你主要跑的是在线对话、单用户或低并发服务。原因很简单：decode阶段计算量被“每token读全部权重”这件事锁死了，算力再高，瓶颈在显存到计算单元的这条路上。
很多专用AI芯片跑大模型时会出现“算力跑不满”的情况——注意，不是卡不行，而是这个负载本来就是访存受限的。芯片设计里那些大块的矩阵乘单元，在decode阶段大部分时间在空转等数据，利用率经常只有个位数到百分之二三十。所以选型时如果只盯着TFLOPS，很容易买到一张算力漂亮但跑LLM甚至不如便宜卡的设备。
2.2 三个数字决定推理体验
真正要看的指标，按重要性排序大致是：显存容量、显存带宽、算力。
显存容量决定你能跑多大的模型。7B模型FP16权重要14GB，加上激活值和KV Cache，稳妥起见需要20GB级别。13B模型FP16要26GB权重，至少32GB显存才舒服。70B模型FP16要140GB，必须量化到INT4后大约35GB才能塞进一张大卡，或者靠多卡分布式。
显存带宽决定解码速度。前面已经算过，带宽除以权重字节数，就是理论token/s上限。比如INT4量化后的7B模型权重约3.5GB，500GB/s带宽的芯片理论能到每秒140多token，当然实际还要扣掉注意力计算和软件开销，但量级是成立的。
算力决定prefill能力和并发上限。如果做的是多轮对话、文档摘要这类输入很长的场景，prefill慢会导致首token延迟飙升，这时候算力低的加速器就会露馅。
2.3 一张对照表看懂主流加速器
下面这张表不是精确的Benchmark，只给选型提供同一个坐标系的参考：
| 加速器 | 显存 | 显存带宽 | 单卡典型部署 | 适合场景 |
|---|---|---|---|---|
| RTX 4090 | 24GB GDDR6X | 约1TB/s | 7B FP16、13B INT4 | 本地开发、小规模私有化 |
| A100 80GB | 80GB HBM2e | 约2TB/s | 13B FP16、70B INT4 | 中度服务化、微调推理 |
| H100 80GB | 80GB HBM3 | 约3.35TB/s | 32B FP16、70B INT4 | 高并发服务、大模型推理 |
| H20 | 96GB HBM3 | 约4TB/s | 70B INT4、上百B量化 | 国产算力环境、推理优先 |
| 昇腾910B | 64GB HBM | 带宽较高 | 70B INT4 | 国产化场景、私有化 |
| M2 Ultra | 192GB统一内存 | 约800GB/s | 32B FP16、70B INT4 | Mac本地、单机多模型 |
上面这张表最容易被误解的一点：高带宽卡为什么有时“看起来”不如低带宽卡跑得快？因为带宽只是上限，软件栈、内核实现、注意力优化和显存管理同样重要。后面我会专门展开。
2.4 针对LLM设计的芯片到底改了什么
所谓“针对LLM的加速器”，不是把Transformer封装成一个黑盒，而是在芯片层面做了几件关键优化。
第一是强化GEMV（General Matrix-Vector multiplication）能力。decode阶段本质是权重矩阵乘单个向量，传统GPU的大矩阵乘单元对这种形状并不友好，芯片设计时如果专门优化了小矩阵和向量乘法的吞吐，解码速度会明显提升。
第二是给KV Cache留了专用的片上缓存或高速路径。长上下文的decode要反复读写这部分数据，专用路径可以显著减少对HBM的占用。
第三是支持更激进的低精度计算，比如FP8、INT4直接做矩阵运算，省了“先反量化再计算”的环节。这些优化最终都会体现在“实际推理速度对峰值算力的利用率”上。
3. 部署场景决定选型思路：从端侧NPU到多卡集群
3.1 单卡本地化部署：7B/13B的甜点区间
如果你只是想在公司内部搭一个私有知识库助手或者代码辅助工具，用户量不大，那单卡方案是最优解。
我用得最多的组合是“RTX 4090 24GB配合7B到13B模型”。7B的FP16权重14GB可以完整放进去，加上KV Cache和推理框架的显存开销，24GB其实卡得比较紧，上下文窗口开到4K到8K是舒服的，再长就要OOM。想跑13B模型，建议直接上INT4量化，权重压缩到8GB左右，反而能留出更多显存给上下文，实测体验比硬塞FP16更好——因为FP16塞满了显存，KV Cache被挤到很小，上下文稍长就报错。
这一阶段的选型重点不在算力，而在显存容量和生态兼容性。比如有些专用芯片纸面参数很好，但llama.cpp和vLLM的支持版本落后，最后你会发现自己在花大量时间跟框架源码较劲，而不是在调优模型。
3.2 服务化部署：量化、多卡、MoE和长上下文
用户量上来了，就要考虑并发和多卡。
并发场景下的第一瓶颈往往不是模型权重，而是KV Cache。每个用户的对话都要占用一份KV Cache，假设7B模型满上下文8K的KV Cache接近2GB，8个并发在线请求直接吃满16GB，显存再大也经不住这么消耗。这也是为什么服务化部署必须用vLLM这类带PagedAttention的框架，它能像操作系统管理内存一样管理KV Cache，把碎片化和预分配浪费降到最低。
模型规模往上走，70B级别基本逃不过多卡。70B INT4权重约35GB，两张80GB的卡完全够，但要注意卡间的互连带宽。如果用的是普通PCIe，权重在卡间传输时会成为瓶颈，尤其prefill阶段。用NVLink或同类的专用高速互连，效率能差出30%到50%。
还有一个很多人没注意的趋势：MoE模型的硬件需求特点。比如DeepSeek-V3这种总参数量671B、但每次只激活37B参数的模型，看起来单卡显存装不下，实际上由于稀疏激活，推理时每token只需要读取被路由到的专家权重。这让高容量、高带宽、中等算力的卡反而成了最优解，也部分解释了H20这类卡在服务化场景受欢迎的原因。MoE配合INT8甚至FP8量化，单张高显存卡能扛起不小的并发压力。
3.3 端侧与边缘场景：NPU和量化之外还要考虑什么
端侧跑LLM这几年越来越热，手机、笔记本、一体机都在尝试跑本地模型。端侧NPU的算力其实不少，但瓶颈还是老问题：内存带宽和可用内存。
以一块主流旗舰手机芯片为例，NPU的INT8算力可能很高，但内存带宽往往只有几十GB/s，跑7B INT4模型时生成速度大概率落在每秒十来个token以内。能用，但不惊艳。
端侧的关键额外变量是“显存与计算单元的距离是否够近”。像苹果M系列统一内存架构，CPU、GPU和NPU共享同一块高带宽内存，跑LLM的体验就明显好于“独立显存小板卡+普通DDR”的方案。所以在边缘设备上，与其只比较TOPS，不如优先看内存带宽和是否支持高频需求的小尺寸模型版本。
4. 量化是加速器的最佳搭档：用更小的带宽需求换更高吞吐
4.1 量化为什么在LLM上特别有效
这个问题要回到带宽。decode阶段每token读一次全部权重，权重字节数直接决定带宽时间。FP16的7B模型要读14GB，INT4量化后只要3.5GB，相当于把带宽需求压到原来的四分之一。同一个加速器，量化后的理论token/s直接提升四倍，这就是为什么量化被称为“加速器的最佳搭档”——它不动硬件，却把硬件最稀缺的带宽资源成倍释放出来。
显存容量的压力也随之缓解。70B模型FP16要140GB，INT4只要35GB，这让原本需要4张卡的负载降到1张80GB卡或2张24GB卡，成本差异是天壤之别。
4.2 我常用的量化选型路径
量化不是无脑压到最低位数就行，需要区分场景。
- 对话聊天、代码生成这类对单token质量不极端敏感的场景，INT4（AWQ、GPTQ或GGUF里的Q4_K_M）是最优选，速度和显存双赢。
- 数学推理、结构化抽取这类需要严格输出格式的任务，我会优先用INT8或BF16保留精度，因为4bit在小模型上确实可能让“1+1=3”的概率变大。
- 微调后的模型，特别是领域数据微调的LoRA权重，量化前一定要做校准集评估，不能拿基座的指标直接推断。
量化工具上我最常用的是llama.cpp的GGUF格式，它傻瓜化和跨平台的能力非常强；服务化部署则用vLLM配合AWQ格式，量化感知推理的加速效果更稳定。每个新量化版本，我都会先在验证集上跑一遍对比，记录题目答案的格式合规率和关键内容的语义相似度，哪怕多花一晚上，也比上线后才发现异常省心得多。
4.3 RAG场景下的硬件需求反而更温和
搜热词的时候看到很多人在做“llm wiki知识库”“RAG GraphRAG”这类项目。RAG对硬件加速器的需求跟长上下文生成完全不同。
RAG的思路是把知识切成块预先向量化，查询时先检索再生成，这样喂给LLM的上下文可以控制在几K之内，KV Cache压力骤降。对加速器来说，真正吃显存和算力的大头反而变成了embedding模型和小型重排模型，这类模型往往只有几亿参数，CPU加一块入门级加速卡就能扛住。
所以如果你的项目是知识库问答，不急于给LLM配一张顶配卡，先考虑把检索链路和模型量化做好，通常一张24GB的卡就能覆盖几百用户的日常并发。这也是我在不少项目里推荐的“轻量化架构”。
5. 实测对比：同一个7B模型在不同硬件上的表现
5.1 测试条件与指标口径
为了避免云评测的空洞，我拿同一个开源7B模型（Mistral-7B-Instruct）做过一轮对比测试。统一用llama.cpp的GGUF Q4_K_M量化版，固定上下文4096，batch size为1，只测单用户场景，记录两个指标：首token延迟（TTFT）和生成速度（token/s）。
测试环境分别是桌面CPU（双通道DDR4）、RTX 4090、A100 80GB，以及一台M2 Ultra的Mac Studio。CPU只做参考，因为它的内存带宽无论如何都追不上显存。
5.2 数据解读：为什么有的卡看起来更强却跑不快
结果大致如下：
| 硬件 | 7B Q4_K_M生成速度 | 首token延迟（256 token提示词） |
|---|---|---|
| 桌面CPU | 8-11 token/s | 2-4秒 |
| RTX 4090 | 90-110 token/s | 0.3-0.5秒 |
| A100 80GB | 120-140 token/s | 0.2-0.3秒 |
| M2 Ultra | 70-85 token/s | 0.4-0.6秒 |
最反直觉的一点是，A100的峰值算力比4090高好几倍，但7B模型单用户跑起来只快了个百分之二三十。因为Q4_K_M的7B权重只有不到4GB，4090的1TB/s带宽理论能到每秒250token，实际能跑到100上下已经是软件的极限，而A100的高算力在这个场景里大部分时间在闲置。这正好印证了前面的结论：对单用户推理，带宽与软件效率的影响远大于峰值算力。
M2 Ultra的800GB/s带宽看着不低，跑7B却只有80左右，原因在于统一内存架构在llama.cpp上的访存效率、CPU与GPU的同步开销，以及macOS上的Metal后端优化深度不如CUDA。这提醒选型的人，参数是一回事，生态成熟度是另一回事。
5.3 70B以上模型：从单卡到多卡的变化
同样的模型放大到70B INT4（约35GB权重），硬件需求就完全变了。RTX 4090单卡除非牺牲上下文长度强制塞进去，否则基本不可用。A100 80GB勉强能单卡跑，但8K上下文都不好留。
我用两张4090跑过70B INT4的llama.cpp，张量并行后生成速度能到每秒25到35token。这个速度做一般问答够用，但如果前端用户在线等结果，体验会在“可接受”和“轻微卡顿”之间摇摆。换成A100或H100之后，要么多卡并行度更高，要么干脆用更高质量的Int8权重达到同速度，回答质量还能再上一截。
所以70B级别以上的选型，我的建议是不要拘泥于单卡：先做多卡张量并行的带宽测试，再决定是加卡还是换卡。很多情况下，两张中端卡分头跑模型A和模型B，比一张高端卡串行跑两个模型更能扛业务压力。
6. 不可忽视的软件协同：推理框架和系统配置
6.1 llama.cpp、vLLM和TensorRT-LLM的选择逻辑
硬件之外的软件层，经常被当作“反正用AI框架都一样”而随意跳过，但实际上对最终性能的影响不亚于换一张卡。
llama.cpp是本地和边缘部署的首选，对CPU、GPU混合运行支持极好，GGUF量化一步到位，适合几个并发、追求低延迟的场景。服务化部署、几十上百个并发时，它的连续批处理能力就开始吃亏。
vLLM是并发服务的标准答案。PagedAttention、连续批处理和流式输出都是为高吞吐场景设计的。同一个7B模型，llama.cpp单卡可能在10个并发时就明显变慢，vLLM能把吞吐撑到50甚至更多并发，代价是单请求延迟略升。我给“内部问答平台”这类服务做选型时，几乎都是vLLM。
TensorRT-LLM是NVIDIA环境下的深度优化方案，需要把模型编译成引擎，冷启动慢、迭代周期长，但同一张卡上能做到比vLLM再高一截的极限吞吐。如果你的服务是固定的几个模型、长期运行不改动，TensorRT-LLM值得投入人力。
6.2 KV Cache和上下文窗口的计算与规划
KV Cache的大小是部署时最容易被低估的变量。按公式估算：KV Cache字节数大致等于2（K和V两组）乘以层数乘以KV头数乘以每个头的维度乘以序列长度乘以批次大小再乘以精度字节数。
拿7B模型为例，32层、32个KV头、128维、FP16精度，每token的KV Cache大约是2乘以32乘以32乘以128乘以2字节，算下来约512KB。单用户4K上下文需要2GB，如果开10个并发且每个都逼近8K，光KV Cache就要40GB——这还没算权重。所以即便权重只要14GB，显存也经常爆在看不见的KV Cache上。
解决路径无非三条：缩短上下文窗口、量化KV Cache精度（INT8甚至INT4）、以及换用GQA架构的模型（如Mistral、Llama 3）。后两者对硬件加速器的友好程度非常高，这也是为什么GQA几乎成了新模型标配。
6.3 PCIe/NVLink拓扑对多卡效率的实际影响
多卡部署时，卡间通信往往比计算更拖后腿。我用两张4090跑张量并行，一张在主PCIe x16、一张在x8的扩展槽，性能直接损失15%。而同样的卡组跑在NVLink互连的A100/H100上，70B模型的张量并行效率能比PCIe方案再高20%以上。
简单判断方法：显存中模型的每一层权重在推理时都要被切分到不同卡，然后每算一步就可能需要一次all-reduce通信，通信频率和层数、并行度成正比。所以卡间带宽不是“越高越好”的锦上添花，而是“不够就变成瓶颈”的硬约束。
如果你只能在普通PCIe环境做多卡，优先考虑按“不同模型分卡部署”而不是“单模型跨卡张量并行”，用业务层面把模型拆开，避开高频通信。
7. 实战避坑记录：我在LLM硬件加速部署中踩过的坑
7.1 买的卡到货后，发现连7B模型都跑不出宣传速度
这是最容易撞上的坑。原因通常是三个：一是完全没量化，FP16权重让带宽需求翻倍；二是没换推理框架，靠Transformers库的默认实现跑，代码路径上多余的内存拷贝多到离谱；三是显存里跑着其他服务，比如模型微调的残留进程占着几个GB空间。
排查思路是逐步剥离：先确认只有这一个模型进程，再切换到llama.cpp或vLLM，最后把权重降到INT8或INT4。一般这轮操作下来，速度提升两倍是很正常的。
7.2 量化后精度崩了，但你以为量化本身不行
有段时间我在做一个医疗领域的知识库问答，7B模型直接上INT4后，专业术语的抽取错误率明显上升。当时第一反应是把模型换回FP16，结果发现显存和延迟都扛不住。
后来排查才发现问题不在量化，而在于校准数据来自通用语料，和医疗领域的词频分布差异太大。换成业务语料做校准、用GPTQ的更高阶优化重新量化之后，错误率几乎回到FP16的水平，速度和显存却没多占太多。所以遇到量化掉精度，先别急着骂量化，先检查校准集质量。
7.3 交互式应用只优化吞吐，忽略首token延迟
服务上线初期只盯着总生成时间优化，把模型做成大batch的连续处理，结果业务方反馈“用户等第一句话等太久”。因为吞吐优先模式下prefill会排队，输入很长的提示词时首token延迟能到几秒。
解决方案是把在线请求单独分一条低并发通道，并把prefill阶段的计算优先级调高，同时用短提示词复用模型，典型的办法就是让RAG检索走上游，替代长上下文硬啃。
7.4 并发一上来就OOM，崩得猝不及防
曾经用24GB卡跑7B模型，单测没问题，上线第三天并发到了十几个，直接OOM。查日志时发现KV Cache的预分配策略是每个请求预留最大上下文，等于每个人都占了几GB，十几个人同时进来就把显存挤爆了。
vLLM的PagedAttention就是为这事设计的，按需分配、动态复用。换成vLLM之后同一个小卡型硬扛了三倍并发都没再爆。部署线上服务，KV Cache的管理方式和显存容量同等重要。
7.5 多卡张量并行的效率，被一张拓展卡拖垮
有位同事配了两张“一样的卡”，结果跑70B模型时速度只有单卡的两倍一点点，怎么调都不对。查到最后是第二张卡插在PCIe x4的槽上，而且是经过主板芯片组转接的，卡间通信延迟高得离谱。
后面改成把两张卡都插CPU直出的x16槽，速度立马涨了40%。多卡用户装机第一件事，不是跑模型，而是用nvidia-smi和系统工具确认两张卡都在直连全速通道上。
做LLM硬件加速部署久了，最大的体会是“瓶颈永远比想象中更多”：你以为买了好卡就完事，结果发现得补量化的课；你搞定量化，又发现并发场景得学KV Cache管理；你解决了并发，又撞上PCIe拓扑。硬件加速不是买个芯片装上去这么简单，它是一个从模型、框架、存储、通信到业务形态的协同工程。对绝大多数团队来说，与其追最新最贵的卡，不如把现有硬件的带宽吃透、把量化精度控好、把软件栈选对，这样获得的收益往往是最快最稳的。
