企业官网建设流程全解析

做LLM部署这一年多，我听到最多的一句话是“我们的卡算力不够，所以跑得慢”。但真把profile数据拉出来看，绝大多数情况根本不是算力不够，而是显存带宽卡死、KV Cache把显存吃穿、推理框架压根没把连续批处理开起来。今天想认真盘点一下“针对LLM的AI硬件加速器”这个话题：从LLM为什么这么吃硬件，到GPU、TPU、ASIC怎么选，再到显存估算、量化、vLLM调优这几个关键实操，把该算的账和该踩的坑一次讲完。这篇文章适合正在做模型部署、或者刚拿到A100/H100不知道从哪下手的同学，也适合想用消费级显卡跑大模型的个人玩家。

1. LLM到底卡在哪里：先搞懂加速器要解决什么问题

1.1 自回归生成与Token粒度计算：一切都要按Token来算账

聊硬件加速之前，得先把LLM的工作机制讲透。LLM生成文本的方式是自回归，也就是一个Token一个Token往外蹦，每蹦一个Token，都要把整个模型从头到尾算一遍。所以大模型推理天然分成两个阶段：Prefill（预填充）和Decode（解码）。Prefill阶段用户输入的一整段Prompt一次性进入模型，计算密集、并行度高；Decode阶段则是逐Token生成的串行过程，每一轮的计算量不大，但必须依赖上一轮的输出，没法并行。

这两个阶段对硬件的要求完全不同。Prefill吃算力，FLOPS越高，Prompt处理得越快；Decode吃带宽，显存带宽越大，Token吐得越快。很多人在评估硬件的时候只看算力峰值，却忽略了Decode阶段才是用户真正感受到的“一个字一个字蹦”的体验，这是个非常常见的误区。

再往细里说，注意力机制里的QKV三件套是LLM计算的核心。很多人记不清楚向量含义，我用一句话总结：Query是“我在找什么”，Key是“我是谁”，Value是“我能提供什么”。每个Token都拿着Query去和所有历史Token的Key做匹配，算出注意力分数，再用这个分数去加权Value。这个过程的时间和序列长度的平方成正比，所以一旦上下文变长，计算量和显存占用都会暴涨。

这就是为什么业界不约而同引入了KV Cache：把历史Token的Key和Value缓存下来，避免每生成一个新Token就把前面的注意力全重算一遍。但代价是KV Cache要占显存，而且随着并发请求数和上下文长度增长，它会成为显存压力的主要来源。这一点我们后面会专门算账。

1.2 带宽墙与显存墙：为什么不缺算力却还是慢

以70B模型为例，FP16精度下权重就有140GB，哪怕用A100的80GB显存，一张卡连模型都放不下。就算用量化把权重压到INT4，也需要35GB。所以LLM推理的第一个硬约束是显存容量，容量不够，模型都加载不进去，一切免谈。

但真正让很多人困惑的是另一件事：同一张卡，跑小模型时利用率看着还行，跑大模型时GPU利用率经常只有百分之二三十，是不是卡坏了？其实不是。看一下Decode阶段的算术强度就明白了。所谓算术强度，就是计算量除以数据移动量。Decode阶段每生成一个Token，需要把全部权重从HBM读到SM里做矩阵向量乘，数据搬了好几GB，有效计算只有寥寥几十GFLOPs。这相当于一个厨师刀工再好，食材搬运工一次只给他递一根葱，大部分时间都在等食材。算力再高，也被带宽卡死了。

所以针对LLM的硬件加速，核心不是堆FLOPS，而是解决两件事：一是把权重塞进显存或靠近计算单元的高速存储里，二是把显存带宽做上去。H100相比A100在FP16算力上翻了近三倍，但Decode速度提升其实没那么夸张，原因就是带宽只提升了不到七成；反过来，H200把显存带宽做到4.8TB/s，Decode表现就比H100好了不少。搞懂了这条，后面看硬件选型就有一条清晰主线。

2. 主流AI硬件加速器选型：GPU、TPU与专用ASIC怎么选

2.1 NVIDIA GPU：多数团队绕不开的第一选择

当前LLM的推理和训练，NVIDIA GPU依然是实际上的标准答案，原因很简单：CUDA生态太完整，PyTorch、vLLM、TensorRT-LLM、Hugging Face Transformers这些主流框架全部优先适配CUDA。你随便拿一张卡，装好驱动就能跑通模型，哪怕遇到问题，GitHub议题上一搜一大把解决方案。这种“开箱即用”的价值，在工程上比纸面算力数值重要得多。

整理一张当前各阶段主力GPU的规格对比，方便直接做参考：

注意几个细节。第一，H200和H100的算力几乎一样，但H200显存容量和带宽大幅提升，这正好印证了前面说的：LLM推理阶段，容量和带宽比纯算力更值钱。第二，RTX 4090的FP16算力其实不弱，比A100还高一点，但它的带宽只有1TB/s，显存只有24GB，所以跑大模型时处处掣肘。第三，消费级显卡没有NVLink，多卡通信只能走PCIe，跨卡时延和带宽都难看，这也是为什么企业部署几乎不用消费卡做多卡方案。

2.2 TPU与专用ASIC：特定赛道里的优势局

在GPU之外，Google TPU是很早就在规模化使用的加速器。TPU的核心优势是能效比高，在训练超大规模模型时单位功耗算力表现非常抢眼，配合JAX生态在大模型训练场景站稳了脚跟。TPU的问题在于推理生态相对封闭，很多PyTorch导出、动态shape、量化工具链都得不到和GPU同等的支持，落地成本不低。

如果用户部署过程中遇到“provider rejected the request schema or tool payload”这类报错，往往不是硬件本身的问题，而是API层和网关层的工具链配置不一致，这种情况在非GPU生态里更常见，排查起来也更费劲。

专用ASIC领域的代表还有Groq的LPU和Cerebras的晶圆级引擎。Groq很有意思，它用SRAM把权重全部放在离计算单元极近的地方，Token生成延迟极低，出Token速度堪称恐怖，小模型单卡就能做到每秒上千Token。但它内存太小，模型一大就要把权重铺到多张卡上，成本随之暴涨，适合对延迟极度敏感但对上下文长度要求不高的场景。Cerebras则在训练端发力，通信开销比GPU集群小得多，但推理部署案例少，一般团队碰不到。

国产加速器线，昇腾芯片近两年适配进展很快，在运营商和政企项目里落地不少，大模型常用算子覆盖度已经不错。但坦白讲，如果你完全从零起步自己搭推理服务，昇腾栈的学习成本还是明显高于CUDA栈；如果团队没有特殊合规要求，我通常建议先在GPU上把方案跑通，再评估国产栈的迁移成本。

2.3 选型建议：算供需账，别只看单卡峰值

很多团队选卡有个通病：拿模型参数量除以卡显存，算出需要几张卡，然后照最高规格买。这个算法忽略了在线推理的并发、上下文长度、KV Cache开销以及Service Level Agreement的延迟要求。我建议把选型当成一道需求题来做，先回答四个问题：模型权重量化到几比特、目标并发量是多少路、每路上下文最长到多少、单Token延迟容忍上限是多少。这四个数字确定下来，显存和带宽需求基本也就出来了。

然后才是看预算。推理场景里，如果并发不高、模型能装进单张80G卡，买H100/A100无可厚非；如果并发高、上下文长，H200这种大显存卡的性价比反而更高。个人或中小企业做实验，RTX 4090其实是很好的起步卡，先把量化、框架、网关这一层跑通，再决定要不要上专业卡。不要一上来就照着训练集群的规格买推理卡，那是另一套账。

3. 部署调优实操：显存估算、框架配置与量化落地

3.1 先学会算显存账：权重、KV Cache与激活

部署LLM之前第一件事，不是装驱动，而是拿笔算一下显存够不够用。以Llama 3.1 8B模型FP16为例，权重大约8B乘以2字节，也就是16GB。一张24GB的卡看起来绰绰有余，但如果加上KV Cache，情况立刻变得紧张。

KV Cache的计算公式长这样：每Token的KV Cache占用 = 2 × 层数 × KV头数 × 头维度 × 字节数。Llama 3.1 8B的参数是32层、8个KV头、头维度128，FP16字节数2，那么每个Token就是2×32×8×128×2=131072字节，也就是128KB。单路8K上下文，KV Cache就是8192×128KB=1GB；如果同时有10路请求，就是10GB。权重16GB加KV Cache 10GB，再算上Prefill阶段的中间激活、CUDA上下文和框架预留，一张24GB卡空间所剩无几，稍微调大一点并发就会OOM。

这就是所有人做推理规划时必须算“动态显存”的原因。部署时我会先按单路上下文的KV Cache估算，再乘以预期的并发路数，把这个数字和权重占用、框架预留加起来，反推出对显存容量的真实需求。宁可算完再砍并发，也不要上线后发现频繁OOM。

在我手头的实战配置里，线上服务通常把gpu_memory_utilization设置在0.85到0.92之间，预留一点余量给CUDA context和偶发峰值。如果要跑更大的模型，比如70B级别，一张80GB的H100配合4比特量化是常见方案：权重压到约40GB，KV Cache再占一部分，单卡勉强能跑低并发。想提高并发，就得上多卡或更大的显存卡。

3.2 推理框架怎么选：vLLM、TensorRT-LLM与ONNX Runtime

显存算清楚了，下一个问题是选推理框架。目前在线服务最主流的选择是vLLM，它的杀手锏是PagedAttention，把KV Cache像操作系统管理内存一样按页分配，大幅减少显存碎片和浪费；同时内置Continuous Batching（连续批处理），一个请求在Decode间隙，其他请求可以插入Prefill，让GPU始终有活干。这两个机制叠加，吞吐量比传统批处理方案高出数倍。

vLLM部署服务非常简单，一条命令就能拉起一个兼容OpenAI接口的服务：

vllm serve meta-llama/Llama-3.1-8B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 16 \ --tensor-parallel-size 1

--max-model-len控制最大上下文长度，直接决定KV Cache上限；--max-num-seqs是最大并发序列数，调高能提升吞吐，但会拉高显存压力；--tensor-parallel-size是多卡张量并行参数，单卡设1即可。我建议上线流程是：先用小并发压测，观察显存余量和首Token延迟，再逐步调大--max-num-seqs，直到显存利用率稳定在90%左右。

TensorRT-LLM是NVIDIA官方方案，做法是把模型编译成高度优化的TensorRT Engine，QKV融合、算子自动调优都做到极致，单卡性能通常比vLLM再高一截。代价是编译过程复杂、模型结构改动后要重新编译，动态shape支持也僵硬。适合那些模型版本固定、追求极致吞吐的生产环境。

ONNX Runtime则是另一个思路，跨平台、支持CPU、GPU多种后端的统一接口。如果你要用ONNX部署LLM，核心是把模型导出为ONNX格式，开启GraphOptimization级别优化。ONNX的优点是部署链路统一、好嵌入现有服务，但动态KV Cache的存储管理没有vLLM成熟，大规模并发时的吞吐优化要靠自己写很多调度逻辑，所以它更适合边缘场景或已有ONNX技术栈的团队。

框架之上还有LLM网关这一层，负责多副本负载均衡和请求路由。网关本身的转发开销微乎其微，真正的性能瓶颈始终在下游GPU和KV Cache调度上。如果网关层出现“provider rejected the request schema or tool payload”这一类型错误，请先去查工具调用和指令模板配置，不要在GPU侧白费力气。

3.3 量化方案实战：FP8、INT8与INT4怎么选

模型量化是缓解显存压力的最直接手段。LLM权重存在大量冗余，把权重从FP16降到INT4，显存直接降到原来的四分之一，同时解码时的带宽压力也显著下降，因为要搬运的数据量少了。实际测试中，7B模型INT4量化后单Token生成速度往往比FP16快一倍以上，这也是消费级显卡能跑大模型的核心原因。

量化方案按精度分几档。FP8是最新H100及以上显卡的原生精度，Tensor Core直接支持，几乎无精度损失，显存减半，是H100用户的默认选择。INT8方案成熟，配合AWQ或GPTQ算法做校准，精度损失可控，显存同样减半。INT4则把权重压到每参数0.5字节，7B模型权重只要约3.5GB，24GB显卡能轻松装下，但精度会有轻微波折，需要挑选校准集、做针对性验证。

我自己的经验是，在公开评测项上，INT4 AWQ通常只损失一到两个点，日常生成质量几乎无感。但有两个坑必须提。第一，量化对激活异常值敏感，AWQ通过观察激活分布来保护重要权重通道，效果优于直接Round量化；第二，量化和具体任务强相关，代码生成、数学推理这类逻辑密集任务对精度更敏感，建议上线前用实际业务数据在“Open LLM Leaderboard”这类公开榜单反映的核心能力项上做一次完整回归，再决定要不要用INT4。

部署时指定量化参数也很简单，用AWQ预量化模型并加载即可：

vllm serve TheBloke/Llama-2-7B-Chat-AWQ \ --quantization awq \ --dtype auto

需要注意的是，如果量化模型和推理框架的量化格式不一致，比如框架内部默认用FP16权重加载INT4文件，轻则报错，重则精度崩坏。所以选定了量化版本和框架版本之后，尽量锁定组合，不要随便升级某一方。

4. 常见问题与瓶颈排查实录

4.1 GPU利用率只有30%：先分清prefill与decode

部署后第一件事是看监控，但很多人看到nvidia-smi里GPU利用率不高就焦虑。这里必须先分清楚：nvidia-smi显示的利用率是一个混合指标，Prefill阶段确实能冲到95%以上，但Decode阶段因为带宽受限，利用率低是正常的，不代表卡在空转。真要判断卡有没有被充分利用，得看算力利用率和带宽利用率的真实分布。

我习惯用nsys profile抓一段推理过程，观察每个Kernel的执行时间是访存受限还是计算受限。如果大部分Kernel的算术强度都很低，说明瓶颈在显存带宽，此时堆算力没用，应该优化KV Cache、加并发请求数把带宽喂饱；如果Prefill阶段Kernel大量时间是计算密集，才需要考虑升级更强算力的卡。

还有一个高频问题：并发请求太少导致GPU跑不满。有的团队用单路压测一个7B模型，结果延迟很高就觉得卡不行。实际上把--max-num-seqs调到16或32，连续批处理才会真正发挥作用，单个请求的等待时间上升，但整体吞吐可能翻好几倍。在线服务的优化目标本来就是吞吐和延迟的平衡，不是单路极限速度。

4.2 OOM与长上下文：砍并发还是砍序列长度

OOM是LLM部署头号事故。torch层的torch.OutOfMemoryError很好定位，但vLLM服务里常见的“No available memory for the cache blocks”更容易让人摸不着头脑。这种情况通常是KV Cache的显存配额被预先规划好了，新请求需要的缓存块排队等待，因为持续占用而无法释放。解决办法按优先级排序：先调低--max-num-seqs降低并发路数，再把--max-model-len减短减小上下文上限，最后才考虑换更大显存的卡。

上下文长度这个东西，和RAG场景关系尤其大。检索增强生成模式下，你往往要把知识库里Top-K的相关片段全部塞进Prompt，几万Token的上下文很常见。如果做多跳检索或者基于知识图谱/本体的复杂检索，拼接内容只会更膨胀，KV Cache开销成倍上涨。所以RAG场景选型时，不要只看模型参数量，一定要把“长上下文+K Cache膨胀”算进显存需求，否则上线以后三天两头OOM。

另一个隐藏优化点是KV Cache本身量化。vLLM支持FP8格式的KV Cache，能省一半动态显存，精度损失对大多数任务不明显。在长上下文、高并发场景下，这个开关值得先打开再谈其他优化。

4.3 多卡加速比上不去：通信瓶颈怎么排查

模型单卡放不下时，多卡并行是必选项。张量并行（TP）把每一层的矩阵切到多张卡上，单次前向传播要跨卡做多次AllReduce，通信量巨大，所以TP非常依赖高带宽互联；NVLink的900GB/s和PCIe的不到64GB/s差距悬殊，这也是我前面说消费级显卡不适合做多卡推理方案的原因。流水线并行（PP）按层切分，通信频率低，但会有流水线气泡浪费算力。

实测经验里，TP=2通常能拿到1.7到1.9倍加速，TP=8往往只有4到5倍，越加卡收益越缩水。判断瓶颈在通信还是计算的方法很简单：用nsys抓profile，看NCCL kernel的占比，如果通信时间超过整个step时间的30%，就必须认真考虑减少TP规模、改用PP，或者削减KV Cache的跨卡访问频率。很多团队在4卡以上还无脑拉高tensor-parallel-size，这是最常见的多卡性能杀手。

5. 几条实践建议：先跑通，再优化，最后买卡

5.1 小步快跑的部署路径：从单卡量化开始

如果你不是在一个专门做大模型基础设施的团队，我真心建议不要一上来就买8卡A100。先用一张24GB的消费级显卡，把7B模型量化到INT4部署起来，跑通服务、压测、网关这些全链路，把显存账和并发模型都摸清楚。你会发现，很多业务场景根本不需要80GB的卡，一张消费卡已经能服务小几十个并发。

当并发继续涨、上下文继续拉长，你才真正知道自己需要的是更大显存、更高带宽还是更强算力。那时再做硬件投入，每一分钱都花得明明白白。

5.2 用数据说话，建立自己的基准测试

不要让“感觉”主导调优。我每次调整框架参数、量化方案、硬件选型，都会固定一组透明的测试：固定模型和Prompt长度，统计吞吐、首Token延迟、单Token延迟、显存峰值四项指标。量化方案、并发参数、是否开KV Cache量化，都放到同一套基准里横向对比。没有这套数据，你根本没法判断一次升级到底值不值。

最后再分享一个小技巧：在压测工具里加上实际业务的长Prompt分布，别只用标准16Token的短请求测。长Prompt才是显存和Prefill算力的真实压力来源，测试结果也更有参考价值。把这套基准沉淀下来，以后每次模型迭代、框架升级，半小时之内就能知道要不要调整硬件方案，这才是“针对LLM的AI硬件加速器”这个主题落到实处的关键。