私有化 LLM 推理优化实战：vLLM 部署的吞吐、延迟与显存（2026 指南）
模型迁到开源权重之后，真正的硬仗是私有化推理：同样的 Qwen3-32B，有人一张 4090 就跑起来了，有人四张 A100 还卡顿。差距不在模型，在推理工程。本文拆解私有化部署的完整链路：推理引擎选型（vLLM/SGLang/llama.cpp/Ollama/TensorRT-LLM）、显存预算与量化（FP16/FP8/AWQ/GPTQ，含 KV Cache 占用公式）、吞吐优化（Continuous Batching、PagedAttention、Prefix Caching）、延迟优化（TTFT/TPOT、流式输出、投机解码）、并发容量换算（目标 QPS → 并发 → 显存 → 显卡），以及上线后的监控与成本账。附可复制的部署清单与常见坑。【查看推理优化部署清单】
先说结论：模型选好了，推理工程决定一切
2026 年 8 月，企业 AI 基建的主战场已经从”选哪个模型”转移到”模型怎么在自己服务器上跑得又快又省”——模型迁移博客讲的是切到开源权重，本文讲的是切过去之后怎么部署。
同样的 Qwen3-32B：有人一张 4090 就稳定服务几十个用户，有人四张 A100 还卡得用户骂娘。差距不在模型，在推理工程。 本文按生产落地顺序拆解五件事：引擎选型、显存与量化、吞吐优化、延迟优化、容量换算与监控。
一、推理引擎选型：先选对工具
| 引擎 | 场景 | 吞吐 | 延迟 | 生态 | 结论 |
|---|---|---|---|---|---|
| vLLM | 生产多用户 | 最高（PagedAttention+批处理） | 好 | 最全，主流模型官方支持 | 生产默认 |
| SGLang | 延迟敏感/复杂前缀 | 高 | 更优（RadixAttention） | 较新，资料少 | 特长生 |
| llama.cpp/Ollama | 个人/开发/无显卡机 | 低 | 尚可 | 好，GGUF 量化生态强 | 实验用 |
| TensorRT-LLM | 极致延迟优化 | 高 | 最优 | 锁死 NVIDIA | 重度优化选 |
决策口诀：生产多用户 → vLLM；多轮对话/Agent 前缀复用多且对 TTFT 敏感 → 试 SGLang；个人开发与 Mac → Ollama；要压榨极致延迟且只跑 NVIDIA → TensorRT-LLM。
vLLM 是默认答案的三个理由：OpenAI 兼容 API 开箱即用（业务侧零改动迁移）、PagedAttention + Continuous Batching 吞吐最高、Qwen/DeepSeek/Llama 全系官方支持 + 社区资料最多。踩坑有地方问，是生产系统最稀缺的资源。
二、显存预算与量化：先把账算对
显存公式（写进部署文档）
显存需求 = 模型权重 + KV Cache + 运行时开销（约 15%）
模型权重 = 参数量 × 每参数字节数
FP16/BF16: 每 10 亿参数 ≈ 2GB
INT8/FP8: 每 10 亿参数 ≈ 1GB
INT4 (AWQ/GPTQ): 每 10 亿参数 ≈ 0.5GB
KV Cache（单请求） ≈ 2 × 层数 × KV头数 × 头维度 × 每Token字节数 × 上下文Token数经验值：Qwen3-14B 4bit ≈ 8-9GB 权重，4090（24GB）可跑；Qwen3-32B 4bit ≈ 16-18GB 权重，需 48GB 级（两张 4090 或一张 A100/H20）；全精度 32B 权重 64GB，需 80GB 级。 每并发会话每 8K 上下文再加约 1-2GB KV Cache，并发 30 就是 30-60GB——显存大头往往是 KV Cache 而不是权重。
量化怎么选
| 量化 | 精度损失 | 显存 | 速度 | 适合 |
|---|---|---|---|---|
| FP16/BF16 | 无 | 基准 | 基准 | 显存充足、质量优先 |
| FP8 | 极小 | 减半 | 快 | 新卡（H20/4090 支持好） |
| AWQ 4bit | 小 | 减 75% | 快 | 生产私有化的主流选择 |
| GPTQ 4bit | 小 | 减 75% | 快 | 同上，AWQ 略稳 |
| GGUF (llama.cpp) | 小 | 灵活 | 中 | Ollama/低显存实验 |
生产建议：先 AWQ 4bit 起步（质量损失在多数商用任务 < 2%，换 75% 显存），评测基线达标就固化；质量敏感任务（长链推理、代码生成）用 FP8 或 FP16。量化后必须用业务评测集复测——有些任务对量化极敏感，别拿榜单印象拍板（这正是评测体系博客讲的：一切以你的评测为准）。
动手前用官网的模型部署测算器输入模型/量化/并发/上下文，直接出显存、显卡方案和 vLLM 启动参数。
三、吞吐优化：让一张卡干三张卡的活
1. Continuous Batching（连续批处理）——吞吐的基石
传统批处理等”凑满一批”再一起算，长请求堵住短请求。Continuous Batching 让新请求随时插入正在进行的批，短请求先走、长请求慢慢算，GPU 利用率显著提升。vLLM 默认开启——但显存不足时有效并发被 KV Cache 上限卡死，表现为并发一高就排队/OOM。先把显存账算对（第二节），批处理才有空间发挥。
2. PagedAttention（分页注意力）——vLLM 的成名绝技
KV Cache 按页管理，像操作系统分页一样：只给实际用到的部分分配显存，碎片和浪费大幅减少，让更多并发请求塞进同一张卡。这是 vLLM 吞吐领先的核心，不用配置，但要理解它——KV Cache 上限就是你的并发天花板。
3. Prefix Caching（前缀缓存）——被忽略的 90% 浪费
多轮对话和 RAG 请求的系统提示词、文档前缀都是重复计算的。Prefix Caching 缓存共享前缀的 KV，命中后直接复用。RAG 场景下命中率经常 70-90%，等于白赚 70-90% 的输入算力。三个配置要点：
- vLLM 默认开启（
enable_prefix_caching=true），老版本要显式打开； - 提示词”前静后动”：固定内容放前缀、变化内容放后面，最大化命中；
- 监控
Prefix Cache hit rate，命中率低说明提示词结构需要调整。
4. max_num_seqs 与显存利用率——两个关键旋钮
--gpu-memory-utilization：默认 0.9。同卡还要跑 Embedding/重排模型时调低，避免 OOM；--max-num-seqs：限制有效并发。太低浪费吞吐，太高触发显存回收（频繁换页反而变慢）。
四、延迟优化：用户的耐心只有 500ms
指标先对齐（都在 容量规划与压测 有详细口径）
| 指标 | 含义 | 健康线 |
|---|---|---|
| TTFT | 首 Token 延迟 | P99 < 1s，流式 < 500ms |
| TPOT | 每 Token 生成时间 | 20-60ms（15-50 token/s） |
| 聚合吞吐 | 整卡 token/s | 越高越好，看硬件 |
只看 P99，别看平均——平均被大多数快请求拖低，会掩盖长尾卡顿，而用户感知的是最差的那次。
优化三板斧
- 流式输出（Streaming）：SSE 边生成边推，TTFT 到了就出字，用户体感直接减半——这是 0 成本的体验优化；
- 前缀命中：RAG/多轮场景开 Prefix Caching，命中后 TTFT 大幅下降（第三节）；
- 投机解码（Speculative Decoding）：小模型草稿 + 大模型验证，生成速度提升 1.5-3 倍，适合 70B 级大模型、对延迟敏感且算力富余的场景。vLLM 内支持，先测收益再上——不是所有负载都划算。
五、容量换算：从目标 QPS 反推硬件
目标 QPS → 并发 = QPS × P95 响应秒数 × 峰值系数（通常 1.5-2）
并发 × 每请求 KV Cache 显存 → KV 显存需求
权重显存 + KV 显存 + 15% 开销 → 总显存 → 显卡数量示例：目标 10 QPS、平均响应 3s、峰值系数 2 → 并发约 60。60 并发 × 每会话 8K 上下文约 1.5GB → KV 约 90GB；Qwen3-32B 4bit 权重 18GB → 总需求约 120GB 显存 → 两张 A100 80G 或三张 H20 96G 级。先算账再买卡，别买回来发现利用率 20%。
黄金法则：先测后买。用真实负载（建议 3-5× 峰值 QPS 压测）验证容量，压测方法见容量规划与压测实战。
上线后的监控与成本账
必盯的六个数
- P99 TTFT / TPOT——延迟健康度；
- Prefix Cache hit rate——提示词结构是否合理；
- KV Cache 利用率——显存是否成为并发瓶颈；
- GPU 利用率——花大钱买的算力用没用满；
- 排队长度/超时率——容量预警信号；
- 每请求成本（分模型）——私有化之后成本依然要归因，接成本归因看板。
三个最容易翻车的坑
- 买卡不压测——凭”模型多大”买卡，没算 KV Cache 并发需求，上线即瓶颈；
- 量化不评测——4bit 量化直接上线，质量塌了没人知道，直到投诉爆发。量化前后必须跑同一套业务评测集；
- 只部署不监控——推理服务在跑就以为没事，KV Cache 换页、GPU 掉卡、前缀命中率崩了都没人看。推理监控和业务监控同等重要。
落地清单（今天就能开始）
| 步骤 | 做什么 | 产出 | 时间 |
|---|---|---|---|
| 1. 算显存账 | 用部署测算器输入模型/量化/并发/上下文 | 显存与显卡方案 | 0.5 天 |
| 2. 建评测基线 | 从真实业务抽 200+ 样本，量化前后对比打分 | 量化达标判定 | 2-3 天 |
| 3. 选引擎启动 | vLLM 起服务，配 gpu_memory_utilization/max_num_seqs | 可调用的推理服务 | 1 天 |
| 4. 开前缀缓存 | enable_prefix_caching + 提示词”前静后动”调整 | 命中率 > 50% | 0.5 天 |
| 5. 压测定容量 | 3-5× 峰值 QPS 压测，看 P99 与吞吐 | 并发容量表 | 1-2 天 |
| 6. 监控上线 | 六个指标进监控，接告警 | 持续可观测 | 1 天 |
延伸阅读：
- 企业模型迁移实战 — 为什么迁、什么时候迁、怎么迁：本文是”迁移之后怎么部署”的下半场
- LLM 模型选型与路由降本实战 — 私有化和 API 混合部署时，怎么让每个请求走该走的模型
- 企业 AI 落地 ROI 测算与立项 — 上硬件之前，先算清私有化 vs API 的账
- 云成本优化实战 — 更广义的算力账单治理
- 容量规划与压测实战 — 压测方法与容量模型
- 微调 vs RAG：怎么选、怎么组合 — 微调产物是私有化部署的一类新负载：训练后评测与显存预算怎么衔接
- 企业 AI 合规与风险管理 — 数据不出域的部署路径：私有化、本地推理、联邦学习，合规是部署方案的硬约束
模型迁移把成本打下来一半，推理工程把剩下的再打下来一半——而这两步的成败都压在同一个前提上：评测基线 + 容量验证，先算账再动手。
我们团队交付私有化 LLM 部署的完整链路：显存与硬件方案测算、vLLM/SGLang 部署调优、量化与评测基线、压测定容、推理监控告警。如果你正在评估”开源模型切过来之后怎么部署”，带着你的模型、并发目标和 GPU 预算来聊——先给你出容量与显存方案，再谈实施。
常见问题
企业私有化部署 LLM，选哪个推理引擎？
按场景分三档：① vLLM——生产级默认选择，OpenAI 兼容 API 开箱即用，PagedAttention + Continuous Batching 吞吐最高，官方支持 Qwen/DeepSeek/Llama 等主流开源模型，单机多卡和分布式都成熟；② SGLang——延迟敏感场景的强竞争者，RadixAttention 前缀复用更强，多轮对话和带工具的 Agent 场景 TTFT 更低，但生态和踩坑资料比 vLLM 少；③ llama.cpp/Ollama——个人开发与 Mac/无显卡服务器场景够用，靠 llama.cpp 的 GGUF 量化把 32B 模型压进 24G 显存，但高并发吞吐远不如 vLLM，不适合生产多用户；TensorRT-LLM 适合对延迟极致优化且愿意锁死 NVIDIA 生态的团队。结论：生产多用户默认 vLLM，实验和轻量场景用 Ollama。
一张 4090 到底能跑多大的模型？显存怎么算？
显存预算 = 模型权重 + KV Cache + 运行时开销（约 15%）。模型权重：FP16 下每 10 亿参数约 2GB（例如 Qwen3-32B 全精度约 64GB，AWQ/GPTQ 4bit 量化后约 16-18GB，Qwen3-14B 4bit 约 8-9GB）。KV Cache 单独算：2 × 层数 × KV头数 × 头维度 × 每个Token字节数 × 并发 × 上下文长度，一个常见估算经验值是每个并发会话每 8K 上下文约消耗 1-2GB（随模型与精度浮动）。所以 4090（24GB）配 AWQ 4bit 可以跑 Qwen3-14B，Qwen3-32B 4bit 需要 48GB 显存（两张 4090 张量并行或一张 A100/H20），全精度 32B 需要 80GB 级别。动手前先用我们的[模型部署测算器](/tools/llm-sizing)把显存和硬件预算算清楚。
为什么我的 vLLM 并发一高就变慢？怎么提吞吐？
三个最常见原因：① 没开 Continuous Batching——默认批量等待同一时刻的请求凑批，长请求堵住短请求；vLLM 默认已开启，但显存不足时有效并发会被 KV Cache 上限卡死，表现为"并发一高就 OOM 或排队"；② 缺 Prefix Caching——多轮对话和 RAG 请求共享长系统提示词/文档前缀，不开前缀缓存每个请求都重新算前缀的 KV，浪费 50-90% 算力；③ 显存配置不合理——gpu_memory_utilization 默认 0.9，如果同卡还要跑 Embedding 或重排模型要调低；max_num_seqs 限制有效并发数，要结合显存和 QPS 目标调。先开 Prefix Caching，再调 max_num_seqs，最后看 KV Cache 利用率，是标准的三步。
TTFT、TPOT、吞吐这些指标怎么看？优化到多少算健康？
三个数：① TTFT（首 Token 延迟）——用户体感的第一印象，流式输出下建议 < 500ms，多轮对话或 RAG 前缀命中后应显著更低；② TPOT（每 Token 生成时间）——决定"打字速度"，正常区间 20-60ms/token（对应每秒 15-50 token），取决于模型大小和硬件；③ 吞吐（token/s 聚合）——看整卡能力，vLLM 下 4090 跑 7B 模型可达数百 token/s 聚合吞吐。健康判断：P99 TTFT < 1s、P99 TPOT < 100ms、KV Cache 命中率（Prefix Cache hit rate）> 50%。先看 P99 别只看平均——平均被拖低会掩盖长尾卡顿。
私有化部署到底比调 API 便宜吗？什么时候该上？
不是所有场景都便宜，判断要看四个条件：① 月调用量足够大——Token 量少时，API 的弹性（按量付费、免运维）完胜自建，一般月调用千万级 Token 以上或 7×24 高频推理才值得；② 有合规硬约束——数据不能出域（金融/医疗/政务），私有化不是成本问题而是准入问题，此时必须自建；③ 团队有 GPU 运维能力——推理服务只是开始，还有监控、告警、模型升级、故障恢复，没有 SRE 能力自建会变成新包袱；④ 硬件利用率能拉起来——8 卡只跑 20% 利用率，不如用 API。2026 年开源模型够用后，私有化是"高吞吐 + 合规 + 长期用量"场景的确定性降本手段，但先用模型路由把负载分层、用评测基线确认开源模型达标，再决定上不上硬件。