很多人跑 vLLM 是这么开始的：手里有一张或几张卡，模型权重装进去能跑起来，就觉得成本只有卡钱。真上线之后才发现显存被 KV 缓存吃掉一大半，并发一上来就开始排队甚至 OOM，要么加卡要么降配，两种都在改成本。这篇不给你固定数字，只给一套算法：先把显存拆成几块，再看每一块怎么换算成每小时的钱，最后判断这笔账该怎么收回。
很多人跑 vLLM 是这么开始的：手里有一张或几张卡，模型权重装进去能跑起来，就觉得成本只有卡钱。真上线之后才发现显存被 KV 缓存吃掉一大半，并发一上来就开始排队甚至 OOM，要么加卡要么降配，两种都在改成本。问题不在于你选的框架对不对，而在于你从头就把「显存够用」和「成本划算」当成了同一件事。
这篇不给你固定数字，只给一套算法：先把显存拆成几块，再看每一块怎么换算成每小时的钱，最后判断这笔账该怎么收回。过程中凡是需要具体数值的地方，都建议你拿自己机器的实测结果，或者到站内页面核对当时的水平，别用记忆里的数。
先把显存拆成四块，别只盯权重
- 模型权重
- 加载后基本固定，量化能压下去，但省下的显存不一定等于省下的钱
- KV 缓存
- 随并发数和上下文长度线性增长，是上线后最容易失控的一块
- 框架与激活开销
- 运行时本身的占用，随批处理大小和框架版本浮动
- 碎片与预留
- 为峰值和显存碎片留的余量，留多了就是白付租金
四块分开看，才谈得上有优化空间。权重是固定的，KV 缓存是弹性的，后两块最容易被忽略，却直接决定你能不能把卡用满。量化这条路特别典型：权重是压下去了，但 KV 缓存的精度和整体吞吐表现也跟着变，省下来的显存如果换不来更高的并发或者更好的准确率，那这笔省就是假的。上线前预留多少余量，取决于你的峰值并发——余量留得越大，摊到每个请求上的成本就越高。
- 先用你实际的模型和卡型跑一遍测算，到 /models/deploy 看部署测算结果，再决定留多少余量
- 量化方案要连着准确率一起评估，别只看显存数字好看
- 把 KV 缓存按你真实的平均上下文长度和峰值并发估一遍，这块通常比权重更决定成败
- 碎片和预留单独记一笔，上线后回头看有多少是真的用上了
并发能力怎么换算成每小时的账
同一张卡，能同时服务的请求数不同，单位请求的硬件成本能差出好几倍。所以第一步不是选卡，是先量出你的真实峰值 QPS 和平均上下文长度，再倒推需要几张卡。很多人反过来做——先买了卡，再想办法把负载塞进去，结果就是长期闲置或者长期排队，两种都贵。
延迟指标和成本是反向的：要想首字更快、吞吐更稳，通常要多留显存余量或者多卡并行，这一步的取舍要按业务能不能忍来定。能忍的用户体验，才配得上更省的配置。反过来，如果你的业务对延迟极其敏感，那省下来的卡钱可能远远抵不过流失。
| 你观察到的现象 | 大概率原因 | 先动的旋钮 |
|---|---|---|
| 并发一上来就 OOM | KV 缓存吃满显存 | 限制并发上限、降上下文长度、调批处理参数 |
| 显存明明有富余但吞吐上不去 | 批处理或调度没吃满 | 调批大小、看调度参数 |
| 单请求成本比预期高 | 闲置时间占比大 | 按真实峰值重新规划卡数 |
| 加卡后成本没降反升 | 利用率没跟上卡数 | 先看利用率再决定是否继续加 |
真正的单位成本，是卡的小时租金除以实测吞吐，不是除以理论峰值。租卡行情波动大，去做测算的时候到 /inference 和 /compute/gpu-rental 核对当时的水平，别拿几个月前的印象当依据。
什么情况下这笔账根本不划算
调用量小、流量波动大、模型需求还在变的阶段，自建很容易输给按量 API：闲置的卡照样按小时计时，而 API 只在调用时计费。一家 5 人小团队如果只是做原型验证，需求一周一变，这时候自建基本是给云厂商交学费。反过来，调用量大且稳定、对数据位置有硬要求、需要私有微调权重的场景，自建的成本曲线才有可能压过去。
算的时候别只算卡钱。要加上人力、部署维护、故障兜底，还有试错期的闲置成本。这几项在纸面上看不见，但它们会在第一年真实发生。判断标准很简单：如果你把人力成本折算进去之后，自建还是比按量更便宜，那才值得继续。
- 调用量小且波动大：先按量 API，别急着买卡
- 数据位置有硬性要求、不能出内网：自建的溢价是值得的
- 需要私有微调权重、通用 API 满足不了：自建优先级要提上来
- 只是短期内试水新模型：按量先跑，跑出稳定需求再谈部署
- 术语看不懂就去 /ai-dict/category/infra 补一遍，很多成本项是漏在认知上的
一张判断清单和排查顺序
- 先把四个数凑齐峰值并发、平均上下文长度、可接受的延迟上限、每月总调用量。四个数缺一个，后面的结论都是拍脑袋。
- 按顺序排查显存先看是不是 KV 缓存把显存吃满，再看是不是碎片和预留太多，然后才调批处理参数，最后才考虑换卡或者加卡。
- 把显存换算成钱用实测吞吐去除以卡的小时成本，得到单位请求成本；数据来源到 /inference 核对当时的行情。
- 和按量方案对标把人力、维护、兜底、闲置都算进自建成本，再和按量 API 比。这一步到 /price-watch 看当时的比价信息，别用旧印象。
- 按季度复核用量和卡租金都会变，上一季划算不代表这一季还划算。把复核当成例行动作，不是出问题才做。
显存够用不等于成本划算；把显存换算成每小时的钱，账才算真正开始。下一步拿你自己的峰值并发和上下文长度，去部署测算页面跑一遍，再把结果和按量方案放在同一张表里比。→
常见问题
显存不够，先加卡还是先降精度？
先看瓶颈在哪。如果权重占了大头、并发需求又不大，量化通常更快更便宜；如果是 KV 缓存被长上下文撑爆、并发还在涨，加卡或换更大显存的卡往往更直接。也可以先上限流，把队列排掉再判断，很多「显存不够」其实是并发策略没控住。
怎么判断自建到底比调 API 便宜？
把每月卡租金加人力运维折算成一个总成本，再除以实际能稳定承载的调用量，得到单位成本，跟按量 API 的单价对比。关键是分母要用实测吞吐，不是理论上限。调用量不稳定、有明显波峰波谷的团队，这一项往往算不过 API。
上下文长度对成本的影响为什么这么明显？
长上下文同时推高两处开销：每次请求要计算的输入变多，KV 缓存占用也跟着涨，等于同一张卡能并发的请求数直接变少。所以长文档类任务自建时，单位成本常常比短对话高出一个量级，做测算时要把上下文长度当成主要变量，而不是当成固定参数。
