LLM 推理部署优化实战先算清显存账再谈 vLLM 与量化把开源大模型部署上线、稳定服务并发请求难度远超多数人的预期。训练阶段大家盯着算力推理阶段真正卡脖子的是显存与显存带宽。很多团队第一步就卡在模型放不下或放得下但慢得没法用上。这篇文章从一笔显存账讲起逐层拆解显存估算、量化、vLLM 的核心机制与调优要点帮你建立一套系统化的推理优化思路。一、先算清一笔显存账大模型推理是典型的内存密集型任务每生成一个 Token都要把整个模型的权重从显存里读一遍。一个 7B 参数的模型FP16 精度下光权重就需要约 14GB 显存13B 模型约 26GB70B 模型直接冲到 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 是无损基线权重直接减半相对 FP32W8A8权重和激活都是 8 位精度损失低通用推理场景首选W4A164 位权重、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 分离解决的是单卡不够的问题。把这些手段按需组合配合扎实的压测数据任何一个团队都能把开源模型的推理成本压到可接受的区间。
LLM 推理部署优化实战先算清显存账再谈 vLLM 与量化把开源大模型部署上线、稳定服务并发请求难度远超多数人的预期。训练阶段大家盯着算力推理阶段真正卡脖子的是显存与显存带宽。很多团队第一步就卡在模型放不下或放得下但慢得没法用上。这篇文章从一笔显存账讲起逐层拆解显存估算、量化、vLLM 的核心机制与调优要点帮你建立一套系统化的推理优化思路。一、先算清一笔显存账大模型推理是典型的内存密集型任务每生成一个 Token都要把整个模型的权重从显存里读一遍。一个 7B 参数的模型FP16 精度下光权重就需要约 14GB 显存13B 模型约 26GB70B 模型直接冲到 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 是无损基线权重直接减半相对 FP32W8A8权重和激活都是 8 位精度损失低通用推理场景首选W4A164 位权重、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 分离解决的是单卡不够的问题。把这些手段按需组合配合扎实的压测数据任何一个团队都能把开源模型的推理成本压到可接受的区间。
