在 AI 推理落地中，"一张加速卡上同时跑多个模型"是极其常见的部署形态。典型场景包括：
-
RAG 系统：LLM（生成）+ Embedding（向量化）+ Reranker（重排）三模型共卡；
-
多模态服务：ASR（语音识别）+ LLM（理解）+ TTS（语音合成）共卡；
-
Agent 应用：主 LLM + 多个轻量工具模型（分类、抽取）共卡。
这些模型对显存的需求特征截然不同：
核心矛盾
主流推理框架（vLLM、TensorRT-LLM、MindIE 等）通常支持按比例预分配显存（如 gpu-memory-utilization 参数），但这个比例怎么定，几乎没有科学方法：
-
静态比例与动态负载的错配：框架按"启动时设定"的比例预分配，但实际流量是波动的。Embedding 流量突增时，它的实际峰值可能远超预留配额，而 LLM 那边的 KV Cache 池却空着用不上。
-
OOM 的"互相击穿"：A 模型流量突增 → 触发 OOM → 框架要么杀进程要么报错。最坏情况是 LLM 进程被 Embedding 的突发流量拖垮，整个服务雪崩。
-
缺乏"配额可观测"：开发者通常不知道每个模型的真实显存 footprint，凭经验拍一个 0.7/0.3 的比例，迁移到不同硬件或不同模型时就失效。
具体疑问
-
如何精确测算一个推理模型在真实负载下的显存峰值？模型权重大小和实际占用之间有多大差距？
-
多模型共卡时，显存配额应该按静态比例分配，还是有动态协商机制？业界有没有成熟方案？
-
当某个模型流量突增即将 OOM 时，有哪些过载保护模式可以避免"一损俱损"？降级、限流、迁移各自的代价如何？
-
在什么规模下，共卡部署的性价比就不如物理隔离了？判断阈值是什么？
点赞
收藏
回复
分享
举报
已解决
在 AI 推理落地中，"一张加速卡上同时跑多个模型"是极其常见的部署形态。典型场景包括：
RAG 系统：LLM（生成）+ Embedding（向量化）+ Reranker（重排）三模型共卡；
多模态服务：ASR（语音识别）+ LLM（理解）+ TTS（语音合成）共卡；
Agent 应用：主 LLM + 多个轻量工具模型（分类、抽取）共卡。
这些模型对显存的需求特征截然不同：
核心矛盾
主流推理框架（vLLM、TensorRT-LLM、MindIE 等）通常支持按比例预分配显存（如
gpu-memory-utilization参数），但这个比例怎么定，几乎没有科学方法：静态比例与动态负载的错配：框架按"启动时设定"的比例预分配，但实际流量是波动的。Embedding 流量突增时，它的实际峰值可能远超预留配额，而 LLM 那边的 KV Cache 池却空着用不上。
OOM 的"互相击穿"：A 模型流量突增 → 触发 OOM → 框架要么杀进程要么报错。最坏情况是 LLM 进程被 Embedding 的突发流量拖垮，整个服务雪崩。
缺乏"配额可观测"：开发者通常不知道每个模型的真实显存 footprint，凭经验拍一个 0.7/0.3 的比例，迁移到不同硬件或不同模型时就失效。
具体疑问
如何精确测算一个推理模型在真实负载下的显存峰值？模型权重大小和实际占用之间有多大差距？
多模型共卡时，显存配额应该按静态比例分配，还是有动态协商机制？业界有没有成熟方案？
当某个模型流量突增即将 OOM 时，有哪些过载保护模式可以避免"一损俱损"？降级、限流、迁移各自的代价如何？
在什么规模下，共卡部署的性价比就不如物理隔离了？判断阈值是什么？