企业官网建设流程全解析

LLM 推理部署优化实战：先算清显存账，再谈 vLLM 与量化

把开源大模型部署上线、稳定服务并发请求，难度远超多数人的预期。训练阶段大家盯着算力，推理阶段真正卡脖子的是显存与显存带宽。很多团队第一步就卡在"模型放不下"或"放得下但慢得没法用"上。这篇文章从一笔显存账讲起，逐层拆解显存估算、量化、vLLM 的核心机制与调优要点，帮你建立一套系统化的推理优化思路。

一、先算清一笔显存账

大模型推理是典型的内存密集型任务：每生成一个 Token，都要把整个模型的权重从显存里读一遍。一个 7B 参数的模型，FP16 精度下光权重就需要约 14GB 显存；13B 模型约 26GB；70B 模型直接冲到 140GB。这意味着"模型能放下"只是第一关，推理速度的上限由显存带宽决定，而不是计算能力。

除了权重，还要给三类开销留预算。第一类是 KV Cache：每个请求的注意力键值缓存，随序列长度线性增长，一条 2048 Token 的上下文就可能占用 2GB 显存；第二类是激活值与临时缓冲区：前向计算的中间结果，prefill 阶段尤其吃内存；第三类是运行时开销：推理框架、CUDA 上下文、调度器自身的内存占用。

一个更精确的权重估算方法是按精度换算：FP16/BF16 每参数 2 字节，INT8 每参数 1 字节，INT4 每参数 0.5 字节。以 Qwen3-27B 为例，BF16 精度下权重约 54GB，加上 KV Cache 和激活值，单卡没有 70GB 以上很难舒服地跑起来，还要考虑并发请求会让 KV Cache 成倍上涨。

二、三个经典瓶颈：理解"为什么慢"

第一个瓶颈是 KV Cache 碎片化。传统推理实现为每个请求预留连续的显存空间，但实际请求长度参差不齐，预留的空间大量闲置——有数据显示传统方案的内存浪费高达 60% 到 80%。这也是 24GB 显卡跑不了几个并发请求的常见原因，不是算力不够，是显存被低效占用了。

第二个瓶颈是批处理效率低。不同请求的序列长度参差不齐，静态批处理要把短序列补齐到最长序列的长度，大量算力浪费在填充（padding）上。短请求还要等长请求全部完成才能释放资源，GPU 利用率上不去。

第三个瓶颈是解码阶段串行。自回归生成是逐 Token 进行的，每一步都要遍历整个模型，单步计算量小、访存量巨大，GPU 算力根本喂不饱——这是显存带宽瓶颈的本质来源。prefill 阶段（处理输入）是矩阵乘法密集、算力利用率高，decode 阶段（生成输出）是访存密集、算力利用率低，两个阶段对硬件资源的需求截然不同。

三、vLLM：生产级推理的事实标准

vLLM 是当前开源社区使用最广的高性能推理框架，两个核心创新直击上述瓶颈。

第一个创新是 PagedAttention（分页注意力）。它把操作系统虚拟内存的分页思想引入 KV Cache 管理：传统方案为每个请求分配一整块连续内存，用不满也占着；分页方案把 KV Cache 切成固定大小的物理块，按需分配、可分散存放，通过块表映射逻辑块与物理块。显存利用率从传统方案的 30% 到 50% 提升到 90% 以上，同样的显存能服务显著更多的并发请求。分页方案还天然支持内存共享——并行采样时，多个输出序列可以共享同一段提示词的缓存。

第二个创新是连续批处理（Continuous Batching）。传统方案要等一批请求凑齐再一起处理，vLLM 在请求粒度上动态调度：一个请求生成完毕立即释放资源接纳新请求，GPU 始终在处理有用的计算，吞吐量相比静态批处理有数倍的提升。

vLLM 还提供 OpenAI 兼容的接口，本地服务起起来之后，原本调用 OpenAI API 的代码几乎可以无缝切换。这让 vLLM 成了 RAG 应用、Agent 开发和私有化部署事实上的标配起点。

四、量化：用精度换容量与带宽

模型放不下的第一反应是上量化。量化的本质是用更少的比特表示权重，换取更小的显存占用和更低的访存带宽需求。常见方案有四种。

FP16/BF16 是无损基线，权重直接减半（相对 FP32）；W8A8（权重和激活都是 8 位）精度损失低，通用推理场景首选；W4A16（4 位权重、16 位激活）显存节省显著，适合资源受限的边缘设备；GPTQ、AWQ 这类逐层量化方法针对权重分布做校准，能在 4 位量化下尽量保持模型性能。选型的判断标准是"够用就好"：先跑 W8A8 看精度是否满足业务，不够再回到 FP16，够用再往 4 位试，每一次降精度都要用评测数据说话。

量化部署的注意点：一是校准数据要贴近真实业务分布，用通用语料校准的量化模型在专业领域可能有意外退化；二是激活量化比权重量化更容易掉精度，W8A8 的 8 位激活在长上下文场景要重点测试；三是量化后仍要验证 KV Cache 与数值溢出问题，个别层对低比特敏感时可以做混合精度（敏感层保持高精度）。

五、显存不够时的第二选择：多卡并行与 P/D 分离

单卡放不下，可以多卡并行。推理侧的并行方式主要有三种。张量并行（Tensor Parallelism）把每一层的权重切分成多个分片放到不同显卡，多卡协同完成一次前向计算，通信开销随卡数增加，适合单机多卡场景；流水线并行（Pipeline Parallelism）把模型按层切段，每张卡负责一段，卡间通信量小但存在流水线气泡；数据并行则是多卡各自持有完整模型副本、分摊请求，配合 KV Cache 共享实现更高的并发吞吐。实践中张量并行 + 数据并行的组合最常见。

另一个值得关注的架构是 P/D 分离。前面提到 prefill 阶段和 decode 阶段的资源需求截然不同——prefill 吃算力、decode 吃带宽。把两者拆到不同的实例上，各自针对性的配置资源，可以让整集群的硬件利用率更高，同时改善长上下文场景的首 Token 延迟。这是推理架构演进的一个重要方向，对服务长上下文、高并发的业务尤其有价值。

六、参数调优与性能测试：把每一分显存用在刀刃上

vLLM 部署时的关键参数直接影响吞吐与稳定性。max-model-len 设置最大序列长度，过长会浪费显存预留，过短会拒绝长请求；gpu-memory-utilization 控制显存利用率，一般留 5% 到 10% 余量给 CUDA 上下文与框架开销，不要贪满；max-num-seqs 控制并发序列数，要结合单序列 KV Cache 的占用反推；block-size 是 PagedAttention 的块大小，小块更省显存、大块吞吐更高，需要实测权衡。连续批处理还支持对请求做优先级区分，让交互型请求插队、批量型请求排后。

性能测试是部署的必修课。上线前要用与业务接近的负载压测：记录吞吐量（每秒生成 Token 数）、首 Token 延迟、端到端延迟、最大并发数、显存峰值。压测数据是配置调优与容量规划的决策依据——加多少并发会触发 OOM、模型量化后吞吐提升多少、换更大带宽的卡值不值，都要用数据回答。

七、选型路径：从基线到极致的务实路线

推理引擎的选型不必一步到位。推荐路线是：先用 vLLM 跑通基线，把量化、批处理参数调到位，满足大多数场景；遇到极致性能需求再评估 SGLang（调度上有独特优化）和 TensorRT-LLM（算子融合和硬件适配强）；资源受限或嵌入式场景考虑 llama.cpp 的 GGUF 量化路线；纯个人开发调试可以用 Ollama 快速起步。判断标准始终是：延迟是否达标、吞吐是否够用、显存是否够放、成本是否可控。

八、从部署到运维：容量规划与成本核算

部署上线只是开始，运维层面的两件事必须提前规划：容量规划与成本核算。

容量规划回答"并发涨上来时怎么扩"。需要建立三张表：单请求的资源账单（一个请求占多少 KV Cache、多少计算时间）、单卡的服务能力（在目标并发下能同时处理几个请求）、集群的扩展路径（加卡、加节点还是换架构）。规划时按业务增长曲线预留余量，同时为峰值设计降级策略——请求量突增时，可以限制最大序列长度、降低并发上限、或者把部分流量切到云端 API 兜底，保证核心体验不中断。

成本核算要算清"每百万 Token 的真实成本"。包括：GPU 采购或租赁成本、电力与散热、推理框架的显存利用率（同样显存服务更多请求等于变相降价）、量化带来的吞吐提升。以一张 A 卡为例，跑 7B 模型与跑 70B 模型的单 Token 成本相差一个数量级，模型选型本身就是最大的成本决策。建议按业务线拆分成本报表，让每个应用 owner 能看到自己服务的推理成本，成本意识会自然传导到提示词优化与缓存策略上。

最后是日常巡检的三件事：看显存水位（是否接近上限、是否存在碎片累积）、看错误率（OOM、超时、通信失败的占比）、看吞吐趋势（是否出现退化）。推理系统的故障通常不是突发的，而是缓慢劣化的，把指标盯住，就能在用户感知之前发现问题。

最后补充一个实战观察：推理优化的收益往往不是线性的，而是阶梯式的。把 FP16 降到 W8A8，吞吐提升明显；再降到 W4A16，收益递减且精度风险上升。把静态批处理换成连续批处理，收益巨大；但继续增加并发，收益会边际递减直到显存打满。理解这种"阶梯效应"的意义在于：不要盲目追求极致优化，每走一步都先量化这一步的真实收益。一个务实的做法是建立"优化收益表"——记录每次调整的参数、成本、吞吐、延迟变化，优化做完回头看，哪一步的投入产出比最高，未来资源有限时优先做哪类优化，一目了然。推理优化的终点不是某项指标的极致，而是业务成本与用户体验的平衡点，这个平衡点要靠数据而不是直觉来找。

结语

LLM 推理优化的本质是一场"显存账"的管理：先算清楚权重、KV Cache、激活值各占多少，再决定精度怎么降、缓存怎么管、并行怎么切、参数怎么调。vLLM 的分页注意力与连续批处理解决的是"显存利用率"与"调度效率"两个根问题，量化解决的是"容量与带宽"的问题，多卡与 P/D 分离解决的是"单卡不够"的问题。把这些手段按需组合，配合扎实的压测数据，任何一个团队都能把开源模型的推理成本压到可接受的区间。