vllm 部署 多模型 显存怎么算

单模型跑起来挺顺，一旦想在同一张卡或同一台机上挂第二个、第三个模型，就发现显存不够、启动直接 OOM，或者勉强起来了却频繁换入换出、吞吐掉一半。这篇不堆公式，只给一套可复用的估算顺序：先拆哪几块占显存，再决定要不要塞进去。

单模型跑顺了，就想在同一张卡或同一台机器上再挂第二个、第三个模型，这是很常见的念头。但一动手就发现显存不够、启动直接 OOM，或者勉强起来了却频繁换入换出，吞吐掉一大截。问题不在 vLLM 本身，而在于很多人只算了权重的账。

下面给一套能自己套用的估算顺序：先把显存拆成几块分别记账，再按并发目标反推能不能塞。全程不讲复杂公式，只讲判断标准和动作。具体硬件参数、卡型容量这些数字，去站内的部署测算或模型资料库页面核对当时的数值。

先把显存账目拆开：到底是谁在吃卡

估算翻车最常见的原因，是把「模型权重」当成全部显存占用。权重只是其中一块，而且往往是最好预估的一块。真正让你 OOM 的，通常是另外几项叠加起来的结果。

权重

模型参数本身占的空间，相对固定，最容易被看见也最容易高估它的占比

KV 缓存

随并发路数、单请求上下文长度和层数增长，低峰和高峰能差出好几倍

框架预留

vLLM 自身做调度、通信、显存池管理要占一部分，多模型共存时这部分是叠加的

激活与临时缓冲

前向计算过程中的中间结果，跟批大小相关，批越大越明显

同机其他组件

嵌入、重排、你自己挂的别的推理服务，全都吃同一张卡

• 先按「单模型最坏情况」把账算满，再决定能不能塞第二个，而不是反过来先塞进去再看
• KV 缓存别按权重比例拍脑袋，它跟并发和上下文强相关，这两个数不定下来就别算总量
• 同一张卡上跑了别的服务，一定要一并计入，否则前面算得再细也会被这个漏项推翻
• 留一部分不分配的显存给碎片和突发，不要按卡容量满打满算到小数点

一套可以照抄的估算顺序

顺序很重要。先定并发目标再算单模型，最后才做减法。反过来先摆模型再看能跑多少，基本都会陷入反复调参。

1. 固定并发目标先写清楚要支撑多少路同时请求、单请求最长上下文大概多少。没有这两个数，后面全是猜。
2. 算单模型峰值用权重加该并发下的 KV 缓存加框架预留，得出一个模型的显存底线，这是后面所有取舍的基准。
3. 按模型数累加并留余量多模型并存不是简单相加，还要留调度切换和内存碎片的余量。余量给多少，看你的流量波动有多不稳定。
4. 做减法算出来超出卡容量，就按业务优先级砍模型、砍并发目标或降上下文上限。砍哪一刀取决于业务更能接受排队、掉质量还是掉功能。

余量给多少没有统一答案。如果流量平稳、请求模式可预测，可以给得紧一点；如果早晚高峰差别很大、上下文长度参差，就要往高水位估。具体某张卡在某模型下的实测参考值，到站内模型资料库和部署测算页面核对当时的数字。

塞不下的时候，几条可走的路线怎么选

算下来塞不下，不代表只能加卡。有四条路线，各有明确的适用场景和代价，按业务在意什么来挑。

• 降并发目标：最省事的一刀，代价是排队变长，适合有波峰波谷、能接受排队的场景
• 换更小的量化或精简权重：省显存但可能影响输出质量，适合对质量要求没那么极致的任务，先小流量验证再切
• 不常用模型按需加载或独立进程：靠调度错开而不是同时常驻，代价是首个请求变慢
• 分卡分机部署：一卡一模型，资源利用率下降但故障隔离更好

选哪条之前，先把口径对齐：你说的「能跑」是能启动，还是能稳定扛住目标并发？这两个标准选出来的路线可能完全不一样。对照部署测算页面的口径再决定，比凭感觉拍板靠谱。

先按最坏情况算账，再按业务优先级砍，而不是先塞进去等着它崩。

哪些情况下这套算法不适用

这套估算是在没有实测数据时的替代方案，不是万能公式。以下几种情况直接用它会偏，要换判断依据。

• 请求模式极不均匀、上下文长度差异巨大时，按平均值算出来的结论偏乐观，应该按高水位估
• 同机还跑了嵌入、重排或别的推理服务，它们吃同一张卡，要一并计入，不能只算大语言模型
• 已经有成熟压测数据时，以实测为准，估算只在没有实测时用
• 框架版本和硬件特性会改变预留比例和碎片情况，跨版本、跨卡型直接套旧结论容易翻车