副标题：vLLM 本地部署 · 选型与落地
本文为 vergex.cn 原创首发，转载请注明出处。
凌晨两点，运维群里弹出一条告警：「GPU 显存占用 94%，但 QPS 只有预期的三分之一。」这不是模型本身的问题，而是本地部署大模型时最典型的成本幻觉——以为买了卡就等于能跑，却忽略了显存、量化、批处理与电力之间的真实账单。作为技术管理者，你需要在立项前把这笔账算清楚。
一、TCO 不只是显卡价格：先建立四层成本模型
很多团队做本地大模型预算时，只盯着 GPU 采购价，结果上线三个月后发现 OPEX 失控。真实的本地部署总拥有成本（TCO）至少包含四层：显存与算力硬件、推理框架调优投入、电力与机房开销、模型迭代与量化迁移成本。
以 vLLM 本地部署为例，硬件层的选择会直接影响后续三层。一块 24GB 显存的卡可以跑 7B 模型，但能否跑 70B 模型取决于你是否接受量化以及并发下降的代价。框架层的调优投入容易被低估：vLLM 的 PagedAttention 能显著提升吞吐，但参数如 --gpu-memory-utilization、--max-num-seqs、--max-model-len 配错，会让卡买了却用不满。
电力与机房开销在 7×24 运行时尤其明显。单张高端 GPU 满载功耗可达 300W 以上，一年电费足以再买一张中端卡。模型迭代成本则包括：基座模型更新后，之前的量化方案是否兼容、KV cache 管理策略是否需要重新调参、Prompt 模板变化是否影响输入长度分布。建议在立项阶段用一张 TCO 表约束预期，把「能跑起来」升级为「能跑多久、跑多少、跑多贵」。
二、显存估算公式：立项前必须自己算一遍
vLLM 本地部署的显存占用可以拆成四块：模型权重、KV Cache、激活值与临时缓冲、框架与 CUDA 开销。忽略其中任何一块，都会导致实际部署时显存不足或利用率过低。
模型权重的估算相对简单：7B 参数在 FP16 下约 14GB，FP8 下约 7GB，INT4/AWQ 下约 3.5–4GB。但真正的弹性空间在 KV Cache。vLLM 的 PagedAttention 按 block 分配 KV Cache，每个 block 的大小由 --block-size（默认 16）和 head 维度决定。一个粗略的估算方法是：
KV Cache(GB) ≈ 2 × layers × heads × head_dim × seq_len × batch_size × bytes_per_token / 1e9
实际在 vLLM 中，你不需要手动算到每一位，但必须理解这个公式背后的含义：max_model_len 和 max_num_seqs 是显存占用的放大器。--max-model-len 8192 看起来只是支持长上下文，但它会把预分配的 KV Cache 空间直接拉高一倍。如果业务场景平均长度只有 1024，却按 8192 配置，相当于把 30% 以上的显存闲置在 reserve 里。
建议的做法是：先用真实业务日志统计输入/输出 token 的 P50、P90、P99，再设定 --max-model-len 为 P99 向上取整到 2 的幂次，同时用 --gpu-memory-utilization 0.85–0.92 留出框架开销余量。不要直接复制社区示例里的 0.9 或 0.95，因为不同 CUDA 版本、cudnn 版本、vLLM 版本下的框架开销并不相同。
三、量化方案对比：没有免费午餐
量化是本地部署控制成本最常用的手段，但不同方案在显存节省、精度损失、吞吐影响、硬件兼容性上差异很大。下面这张表可以帮助你在技术评审时快速对齐。
| 量化方案 | 权重大小（7B 模型） | 精度损失感知 | 典型吞吐影响 | 硬件要求 | 适用场景 |
|---|---|---|---|---|---|
| FP16 | ~14GB | 基线 | 基线 | 通用 | 高精度、短上下文、显存充裕 |
| FP8（E4M3/E5M2） | ~7GB | 低 | 吞吐提升明显 | 需 Ada/Blackwell 架构支持 | 推理为主、追求性价比 |
| AWQ INT4 | ~4GB | 中低 | 解码延迟下降 | 通用，但需对应 kernel | 长上下文、显存受限 |
| GPTQ INT4 | ~4GB | 中 | 批处理吞吐较好 | 通用 | 高并发、对精度要求不极端 |
| SmoothQuant INT8 | ~7GB | 低 | 与 FP16 接近 | 需支持 INT8 加速 | 需要兼顾精度与显存 |
避坑点之一：不要把「权重量化」和「KV Cache 量化」混为一谈。vLLM 支持 KV Cache FP8 压缩（通过 --kv-cache-dtype fp8），这能进一步降低长上下文场景下的显存压力，但它和模型权重量化是独立开关。很多团队只做了权重量化，发现长序列仍然 OOM，原因就在于 KV Cache 还是 FP16。
另一个常见误区是认为 INT4 一定比 FP8 省钱。实际上，AWQ/GPTQ 的解码 kernel 在某些 batch size 下效率并不高，整体成本可能反而高于 FP8。判断标准应该是「完成相同业务量所需的总 GPU 小时」，而不是「模型文件小了多少」。这部分的真实对比数据，包括不同 batch size 下的延迟与吞吐曲线，完整版见站点「压测原始数据」下载。
四、吞吐与延迟的跷跷板：批处理参数是陷阱
vLLM 的强大之处在于 continuous batching，但批处理参数是本地部署中最容易踩的坑之一。很多团队把 --max-num-seqs 调到很高，以为并发越大越好，结果首 token 时间（TTFT）暴涨，用户体验反而下降。
核心原则是：吞吐优化和延迟优化不能同时最大化。如果你的业务是离线批处理、文档生成、RAG 后台索引，应该优先提高吞吐，允许较高的 TTFT；如果是在线客服、实时 Copilot、对话系统，则必须约束 TTFT 和 inter-token latency。
一个可复现的基准测试命令如下：
vllm serve Qwen/Qwen2.5-7B-Instruct \
--tensor-parallel-size 1 \
--max-model-len 4096 \
--gpu-memory-utilization 0.88 \
--max-num-seqs 256 \
--dtype auto \
--quantization None
在这个基础上，用 vLLM 自带的 benchmark 工具压测：
python benchmarks/benchmark_serving.py \
--backend vllm \
--dataset-name random \
--model Qwen/Qwen2.5-7B-Instruct \
--num-prompts 1000 \
--request-rate 10 \
--max-input-len 1024 \
--max-output-len 512
避坑点之二：不要只跑「请求速率 10」这一个点。真实业务中请求到达是波动的，你需要测试从低负载到显存满载的全过程，记录 TTFT、TPOT、吞吐、GPU 利用率、显存占用五条曲线。很多性能拐点出现在 70%–80% 负载区间，而不是 100%。当 GPU 利用率还在上升但吞吐不再增长时，说明 kernel 已经陷入 memory bound，此时再加并发只会恶化延迟。
五、vLLM 关键参数：管理者的检查清单
对于 L2 技术管理者来说，不需要亲手调每一个参数，但必须知道哪些参数会直接影响账单。以下是 vLLM 部署中需要重点关注的配置项及其业务含义：
--tensor-parallel-size：多卡张量并行。7B 模型通常不需要，13B 以上根据显存和延迟要求决定。TP 会降低单请求延迟，但会增加卡间通信开销，不一定提升总吞吐。--pipeline-parallel-size：流水线并行，适合超大规模模型或多节点部署。单节点小模型开启 PP 通常得不偿失。--gpu-memory-utilization：建议从 0.85 开始，根据实际 OOM 情况微调。不要超过 0.95，否则 CUDA graph 和临时激活值会把系统逼到崩溃边缘。--max-model-len：严格按业务 P99 长度设定，不要复制模型卡上的理论最大值。--max-num-batched-tokens和--max-num-seqs：控制 continuous batching 的容量。输入长度长的业务应提高前者，短请求高并发业务应提高后者。--enable-prefix-caching：如果大量请求共享系统 Prompt 或文档前缀，开启后可显著降低 TTFT。--num-scheduler-steps：vLLM 较新版本中引入，允许调度器一次多步执行，CPU 开销更低，但可能牺牲一定的调度灵活性。
在管理层面，建议把上述参数做成「部署模板 + 变更评审」机制。每一次模型版本升级、量化方案切换、业务 Prompt 模板调整，都重新评估这几个参数是否仍然合理。很多团队的成本失控，不是因为买了贵卡，而是因为参数没有随业务演化而调整。
六、电力、散热与折旧：被忽略的 OPEX
本地部署和云端推理最大的成本差异，在于云端按 token 或按秒计费，本地则按资产折旧加电费计价。一张 24GB 显存的消费级卡可能只要几千元，但如果 7×24 满载运行，一年电费可能接近卡价的 30%–50%，加上机房空调、UPS、网络，OPEX 会迅速赶上 CAPEX。
更隐蔽的是折旧。大模型硬件迭代速度快，2024 年的主流卡到 2026 年可能在新模型面前显得捉襟见肘。做本地部署预算时，建议按 2–3 年折旧周期 计算，而不是 5 年。同时预留 20% 左右的算力冗余，以应对模型版本升级带来的显存需求增长。
散热也需要纳入评估。多张 GPU 密集部署时，机箱风道、机房 PUE（能源使用效率）会直接影响稳定性和电力成本。消费级卡不适合长期高负载的机房环境，稳定性与售后是企业级卡溢价的重要原因。如果团队没有专业机房，本地部署的总成本需要把故障停机、人工运维、数据安全一并算进去。
七、本地 vs 云端：什么时候不该本地部署
本地部署大模型不是银弹。以下几种情况，建议优先考虑云端 API 或混合架构：
- 调用量波动极大：云端可以按实际调用量伸缩，本地则意味着为峰值买单。
- 需要最新旗舰模型：本地硬件很难跟上闭源大模型的迭代速度，且授权和合规成本复杂。
- 团队缺乏运维经验：vLLM 的调优、监控、故障排查需要专门的工程能力，人力成本不可忽视。
- 对延迟要求不高：非实时批处理任务在云端Spot 实例上往往更便宜。
本地部署的优势在于：数据不出域、固定高调用量下的单位成本更低、可深度定制量化与推理路径。最理性的策略通常是混合部署：敏感数据和高频固定任务走本地，长尾任务和实验性任务走云端。
反模式清单与自查表
在签字批准本地大模型项目之前，建议逐条核对：
- [ ] 是否用真实业务日志估算过 P90/P99 输入输出长度？
- [ ] 是否为 vLLM 设定了合理的
--gpu-memory-utilization，而不是直接抄社区配置？ - [ ] 是否区分了权重量化与 KV Cache 量化？
- [ ] 是否测试了从低负载到满载的全过程性能曲线？
- [ ] 是否把电力、散热、折旧计入了 TCO？
- [ ] 是否为模型升级预留了显存和算力冗余？
- [ ] 是否评估过本地部署与云端 API 的混合方案？
核心总结：本地跑大模型的真实成本，不在显卡标价，而在显存估算、量化取舍、批处理参数与长期 OPEX 的乘积里；算不清这四笔账，买再贵的卡也只是把亏损本地化。