大模型服务为什么总是爆显存-电子发烧友网

一、概述

1.1 背景介绍

大模型服务报CUDA out of memory，很多现场第一反应都是“模型太大，换更大的卡”。这个结论通常过于粗糙。生产里的显存问题至少有五类来源：模型权重本身、KV Cache、请求并发、上下文长度、框架预留与碎片。只盯参数量，很多故障会越修越贵：明明是请求画像变了，却被误判成卡不够；明明是参数贴边，却被误判成框架不稳。

更稳的判断顺序应该是：先分静态占用和动态占用，再看请求画像和并发模型，最后回到推理框架参数与 K8s 调度边界。

1.2 显存占用分层

层次	主要内容	典型信号	第一眼先看什么
静态占用	模型权重、编译缓存、运行时预留	服务刚启动就很高	模型大小、dtype、TP
动态占用	KV Cache、batch、并发、长上下文	流量上来后迅速爬升	请求长度、并发、max seq
额外开销	碎片、临时 buffer、CUDA graph	波动大、释放不及时	框架参数、显存预留策略

1.3 适用场景

vLLM、TGI、SGLang 等推理服务出现CUDA OOM；

长上下文请求增多后 GPU 利用率不高但显存打满；

K8s 上 GPU 推理服务扩容失败、Pod 反复重启；

多卡切分后吞吐并不高，但显存仍然紧张。

1.4 第一轮判断链路

先确认静态占用是不是已经接近卡上限；

再确认是不是 KV Cache 被长上下文和并发一起放大；

再确认是不是框架参数和预留策略过于贴边；

最后再看调度、MIG、节点混部和回收动作。

1.5 环境矩阵

维度	需要先确认什么	原因
GPU 型号	A100、H100、L40S、A10 等	显存大小和能力差异大
部署框架	vLLM、TGI、SGLang	参数名和指标口径不同
模型与精度	FP16、AWQ、GPTQ、FP8	静态占用差异大
请求模型	在线问答、长上下文、批处理	KV Cache 压力不同
调度方式	单机、K8s、MIG、多卡	平台放大器不同

二、详细步骤

2.1 先把观测面补齐

2.1.1 基础命令

nvidia-smi
nvidia-smi dmon -s mu -d 2
kubectl top pod -n llm
kubectl logs -n llm deploy/vllm-server --tail=200

| GPU  Name    Persistence-M| Bus-Id    Disp.A | Volatile Uncorr. ECC |
| 0  NVIDIA A100 80GB     | 0000000000.0 Off |          0 |
| Memory-Usage 73341MiB / 81920MiB                  |

2.1.2 日志里的关键字

CUDA out of memory
failed to allocate memory
prefill rejected
request queue full

显存现场一定要同时看三种证据：

GPU 显存使用曲线；

服务日志里的 OOM / reject；

请求画像，尤其是输入长度和并发。

2.2 第一轮：静态占用是不是已经过高

2.2.1 静态占用的组成

项目	说明	运维关注点
模型权重	模型参数、精度、量化方式决定	模型越大，起步占用越高
TP / shard	多卡切分方式	切分不当会多出额外通信和缓存开销
框架预留	显存安全余量、编译缓存	起步就贴边时后续极易 OOM

2.2.2 静态占用判断示例

curl -s http://vllm-server:8000/metrics | grep -E'gpu|kv|request'| head -40

gpu_memory_used_bytes 6.8e+10
gpu_memory_total_bytes 8.2e+10

如果服务刚起来就已经用了 80%-90% 显存，后面只要遇到稍长一点的输入或并发增加，就很容易直接翻车。

2.2.3 量化与模型规格要先算账

模型规格	常见精度 / 量化	对静态显存的典型影响
7B	FP16 / AWQ / GPTQ	从十几 GiB 到几 GiB 不等
14B	FP16 / INT4	明显抬高起步占用
32B+	FP16 / TP / 量化组合	往往必须多卡或更强量化

值班时不需要把每个模型都算到小数点后，但必须知道：量化改变的是权重占用，不会把所有动态显存都一起解决。这个区分不先做，后面会把 KV Cache 问题误判成“模型太大”。

2.3 第二轮：KV Cache 是不是主因

2.3.1 KV Cache 为什么是最常见放大器

KV Cache 的占用不是“模型越大越高”这么简单，它还与：

输入 token 长度；

输出 token 长度；

并发序列数；

hidden size、层数、head 数；

框架分页和预留策略

共同相关。

2.3.2 现场判断公式

显存总占用 ≈ 模型权重 + KV Cache + 运行时预留 + 临时 buffer
KV Cache ≈ 并发序列数 × 上下文长度 × 每 token KV 开销

这不是精确会计公式，但足够支撑值班判断：只要并发和上下文同时上升，KV Cache 就会成为主要压力源。

2.3.3 请求画像采样

grep'input_tokens'/var/log/llm/access.log | tail -50

time=2026-03-09T2011Z input_tokens=7420 output_tokens=312 model=qwen2.5-7b
time=2026-03-09T2012Z input_tokens=8011 output_tokens=448 model=qwen2.5-7b

如果以前主流请求是 1k-2k token，现在变成 6k-8k token，再配合并发提升，显存问题就几乎一定不是“突然卡坏了”，而是容量预算失效了。

2.3.4 输出 token 上限也会放大 KV Cache

grep'output_tokens'/var/log/llm/access.log | tail -50

很多团队只看输入长度，不看输出长度。实际上长输出会让 decode 阶段的缓存持续占着不放，尤其是流式输出和长回答场景。输入长、输出也长时，显存线会比离线压测更早被打穿。

2.3.5 请求画像要分桶，而不是看平均值

桶位	输入 token	输出 token	现场意义
S	<=512	<=128	短问答
M	513-2048	<=256	一般对话
L	2049-8192	<=512	长上下文
XL	8192+	512+	高风险显存桶

平均值看着不高，不代表没有问题。只要L、XL桶比例突然上升，显存和 TTFT 就会优先出问题。

2.4 第三轮：并发模型是不是把显存打穿

2.4.1 并发与max-num-seqs

kubectl get deploy vllm-server -n llm -o yaml | sed -n'/args:/,/resources:/p'

args:
---max-model-len=8192
---max-num-seqs=128
---gpu-memory-utilization=0.95

这组参数的问题不在于任何一个单项错，而在于组合太激进：

max-model-len高；

max-num-seqs高；

gpu-memory-utilization贴边。

三者叠在一起，哪怕平均请求没有达到上限，只要来了几波长上下文突刺，也足够触发 OOM。

2.4.2 并发画像判断矩阵

现象	更像什么问题	推荐动作
OOM 只在高并发时出现	并发阈值过高	降max-num-seqs或分池
OOM 只在长上下文业务出现	max-model-len 过高或业务混池	长短请求分池
显存一直很高但 GPU util 不高	排队和缓存占住显存	看请求分布和队列策略

2.4.3 队列深度与拒绝日志要一起看

curl -s http://vllm-server:8000/metrics | grep -E'queue|reject|request'

llm_queue_depth 18
llm_request_rejected_total 12

如果队列深度升高、拒绝数开始增加，而 GPU util 并没有跟着满，说明瓶颈可能先发生在显存和调度，而不是纯计算资源。

2.5 第四轮：量化、TP、多卡切分有没有配错

2.5.1 参数对照表

参数	影响	风险
量化方式	直接影响权重占用	精度、兼容性需验证
tensor parallel	把权重分到多卡	切分不当会增通信与复杂度
gpu-memory-utilization	预留边界	太高容易失去缓冲

2.5.2 多卡切分示例

python -m vllm.entrypoints.openai.api_server 
 --model /models/Qwen2.5-32B-Instruct 
 --tensor-parallel-size 4 
 --max-model-len 4096 
 --max-num-seqs 16

多卡不是万能的。它能把权重分摊出去，但 KV Cache 和并发放大仍然存在。很多团队把 TP 拉大后觉得显存一定够，结果 OOM 只是延后，不是消失。

2.5.3 量化切换的副作用

动作	预期收益	需要额外验证什么
从 FP16 切到 AWQ / GPTQ	静态显存下降	精度、吞吐、兼容性
开启 FP8	进一步压缩权重并可能提吞吐	GPU 架构支持与框架版本
多卡 + 量化一起上	压低单卡压力	拓扑、通信、稳定性

只把量化当成“降显存开关”很危险。生产里应该把它当成一项需要重新压测和重新验收的变更，而不是夜间现场临时一改就上。

2.6 第五轮：K8s 调度和节点边界是不是在放大问题

2.6.1 Pod 资源与节点分布

kubectl get pod -n llm -o wide
kubectl describe pod vllm-server-0 -n llm
kubectl describe node gpu-node-03 | grep -A5 -B2 nvidia.com/gpu

2.6.2 常见 K8s 放大器

放大器	表现	风险
GPU 节点混部	其他任务抢占资源	干扰显存与 GPU util 判断
探针过严	OOM 后不断重启	日志窗口变短，证据丢失
HPA 只看 CPU	扩缩容不及时	GPU 池压力不被感知
MIG 切分不合理	单实例显存不足	长请求直接失败

2.6.3 K8s 侧还要看哪些对象

kubectl get hpa -n llm
kubectl get pdb -n llm
kubectl get svc,ingress -n llm

如果扩缩容只看 CPU、PDB 太紧、Ingress 超时太短，显存问题会被进一步放大：

服务端排队变长；

网关更早超时；

重启后的实例又因为探针或流量回切过快再次打满。

2.6.4 调度与流量回切的常见坑

坑点	现场表现	建议
HPA 只看 CPU	GPU 明明满了却不扩	加入队列或 GPU 指标
滚动更新步长偏大	新实例一起冷启动	缩小步长
探针过严	冷启动期间被反复杀	用 startupProbe
路由未分池	长请求继续打到短池	网关按路径或 header 分流

2.6.5 MIG 与多租户场景的额外边界

场景	风险	建议
MIG 切得过细	单实例显存不足	长请求单独走大实例
多租户共池	一个租户把长上下文打满	做租户配额和分池
共用网关	路由不区分请求画像	增加路径或 header 分流

2.6.6 一次“不是卡不够，而是路由没分池”的现场

现象：
短问答业务投诉 TTFT 飙高，显存线全天贴边，GPU util 却没有完全打满。

第一轮判断：
团队一开始倾向于申请更大的卡。

第二轮下钻：
请求日志显示长上下文 RAG 请求与短问答打在同一服务池；长请求占着 KV Cache 不放，短请求被迫排队。

结论：
不是单纯卡不够，而是请求画像没分池，短请求在为长请求兜底。

这种案例在生产里非常典型。只要把“长池 / 短池”治理到位，很多看似只能靠扩卡解决的问题，其实会先下降一大截。

2.7 根因矩阵

根因	典型信号	推荐动作
权重太大 / 量化不合适	服务刚起就接近满显存	换量化、换卡型、降模型规格
KV Cache 放大	长上下文 + 并发一起涨	分池、限长、降并发
参数贴边	gpu-memory-utilization 过高	留安全余量
多卡切分误用	多卡后仍不稳	复核 TP / shard 策略
节点与调度放大	K8s 层重启、混部、探针	整理调度与探针策略

2.8 处理动作与回归验证

2.8.1 当班止血动作

kubectl scale deployment/vllm-server -n llm --replicas=0
kubectlsetargs deployment/vllm-server -n llm 
 --containers=server 
 -- --model=/models/Qwen2.5-7B-Instruct --max-model-len=4096 --max-num-seqs=32 --gpu-memory-utilization=0.88
kubectl scale deployment/vllm-server -n llm --replicas=2

2.8.2 请求分池示例

metadata:
name:llm-long-context
spec:
template:
 spec:
  nodeSelector:
   pool:gpu-long

2.8.3 回归验证

nvidia-smi
kubectl logs -n llm deploy/vllm-server --tail=100
curl -s http://vllm-server:8000/metrics | grep -E'ttft|queue|gpu'

检查项	验收标准
GPU 显存	不再长期贴边 95%+
OOM 日志	归零
TTFT / P99	恢复稳定
长上下文请求	不再挤垮短请求池

2.8.4 分池之后要验证什么

检查项	为什么要看
长池显存线	验证长请求是否被真正隔离
短池 TTFT	验证短请求是否恢复
网关路由规则	验证请求是否按预期进池
HPA / 扩缩容策略	验证高峰时不会再次共振

三、示例代码和配置

3.1 显存采样脚本：gpu_mem_snapshot.sh

#!/usr/bin/env bash

# 文件名：gpu_mem_snapshot.sh
# 作用：周期采集 GPU 显存与利用率
# 适用场景：OOM 前后保留显存证据
# 使用方式：bash gpu_mem_snapshot.sh 60
# 输入参数：采样轮数
# 输出结果：输出 nvidia-smi 样本
# 风险提示：低风险，适合现场短时采样
# 结果解读：显存持续贴边但 util 不高时优先怀疑 KV Cache 与排队

set-euo pipefail
count="${1:-60}"
for((i=1;i<=count;i++)); do
  echo "=== $(date '+%F %T') ==="
  nvidia-smi --query-gpu=index,utilization.gpu,utilization.memory,memory.used,memory.total --format=csv,noheader
  sleep 2
done

3.2 请求画像汇总脚本：llm_request_profile.sh

#!/usr/bin/env bash

# 文件名：llm_request_profile.sh
# 作用：从访问日志中汇总输入输出 token 分布
# 适用场景：怀疑长上下文或输出过长导致显存放大
# 使用方式：bash llm_request_profile.sh access.log
# 输入参数：访问日志路径
# 输出结果：输出输入 token 与输出 token 分桶统计
# 风险提示：依赖日志字段格式一致
# 结果解读：长上下文比例突然升高时优先调整分池与参数

set-euo pipefail
file="${1:?log file required}"
awk'
{
 for(i=1;i<=NF;i++){
    if($i ~ /^input_tokens=/){split($i,a,"="); in=a[2]}
    if($i ~ /^output_tokens=/){split($i,b,"="); out=b[2]}
  }
  print in, out
}' "$file"

3.3 指标抓取脚本：llm_metrics_capture.sh

#!/usr/bin/env bash

# 文件名：llm_metrics_capture.sh
# 作用：抓取推理服务 metrics 与 GPU 指标
# 适用场景：压测或故障窗口保留证据
# 使用方式：bash llm_metrics_capture.sh http://service:8000/metrics
# 输入参数：metrics 地址
# 输出结果：metrics 与 GPU 快照
# 风险提示：抓取频率不要过高
# 结果解读：TTFT、队列和显存要一起看

set-euo pipefail
url="${1:?metrics url required}"
out="/tmp/llm-metrics-$(date +%F-%H%M%S)"
mkdir -p"$out"
curl -s"$url">"$out/metrics.txt"
nvidia-smi >"$out/nvidia-smi.txt"

3.4 配置样例

args:
---max-model-len=4096
---max-num-seqs=32
---gpu-memory-utilization=0.88
resources:
limits:
 nvidia.com/gpu:1

3.5 日志样例

time=2026-03-09T2017Z level=error msg="CUDA out of memory"
time=2026-03-09T2017Z level=warn msg="request rejected due to insufficient KV cache blocks"

3.6 告警规则样例

groups:
-name:llm-gpu-memory
 rules:
  -alert:GPUMemoryNearFull
   expr:dcgm_fb_used_bytes/dcgm_fb_total_bytes>0.9
   for:10m
  -alert:LLMOOMBurst
   expr:increase(kube_pod_container_status_restarts_total[10m])>1
   for:5m

3.7 容量预算草算脚本：llm_capacity_budget.sh

#!/usr/bin/env bash

# 文件名：llm_capacity_budget.sh
# 作用：根据模型大小、显存上限和预留比例做粗略容量预算
# 适用场景：上线前或 OOM 后快速估算安全参数区间
# 使用方式：bash llm_capacity_budget.sh   
# 输入参数：总显存 GiB、静态占用 GiB、预留比例
# 输出结果：估算可用于 KV Cache 的显存
# 风险提示：是粗算，不替代正式压测
# 结果解读：可用 KV Cache 空间不足时，应先降并发或分池

set-euo pipefail
total="${1:?gpu total gib required}"
static="${2:?static used gib required}"
reserve="${3:-0.1}"
python - <

	

	3.8 分池路由样例

	
apiVersion:networking.k8s.io/v1
kind:Ingress
metadata:
name:llm-route
namespace:llm
spec:
rules:
 -host:llm.example.com
  http:
   paths:
    -path:/v1/chat/short
     pathType:Prefix
     backend:
      service:
       name:llm-short-svc
       port:
        number:80
    -path:/v1/chat/long
     pathType:Prefix
     backend:
      service:
       name:llm-long-svc
       port:
        number:80


	

	3.9 长短请求分桶样例

	
{"bucket":"short","input_tokens":256,"max_output_tokens":128}
{"bucket":"medium","input_tokens":1024,"max_output_tokens":256}
{"bucket":"long","input_tokens":4096,"max_output_tokens":512}


	

	3.10 HPA 指标样例

	
apiVersion:autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:llm-short
namespace:llm
spec:
minReplicas:2
maxReplicas:8
metrics:
 -type:Pods
  pods:
   metric:
    name:llm_queue_depth
   target:
    type:AverageValue
    averageValue:"6"


	

	3.11 请求桶位输出样例

	
short bucket: input<=512, output<=128
medium bucket: input<=2048, output<=256
long bucket: input<=8192, output<=512
说明：没有桶位，平均值会掩盖显存风险


	

	四、最佳实践和注意事项

	4.1 最佳实践

				主题
			
				推荐动作
			
				原因
		

				容量预算
			
				先算静态占用，再算 KV Cache 预算
			
				显存问题本质是预算问题
		

				业务分池
			
				长上下文与短问答分池
			
				降低互相拖累
		

				参数治理
			
				安全模板与性能模板分开
			
				避免现场贴边调参
		

				监控
			
				TTFT、队列、显存一起看
			
				单看显存不够
		

	4.2 注意事项

	更大的卡可以缓解问题，但不会替代分池和参数治理。

	GPU util 低不代表没有显存问题，KV Cache 与排队都可能让显存先满。

	量化降低了权重占用，但不等于 KV Cache 问题自动消失。

	4.3 实际应用案例

	4.3.1 案例一：长上下文突增把 KV Cache 打满

	
grep'input_tokens'/var/log/llm/access.log | awk'{print $NF}'| tail -20
curl -s http://vllm-server:8000/metrics | grep kv


	

	这类场景的典型表现是 GPU util 一般，但显存一路贴边。根因不是计算不够，而是缓存预算失效。

	4.3.2 案例二：并发突刺导致短请求一起被拖慢

	
curl -s http://vllm-server:8000/metrics | grep queue
kubectl top pod -n llm


	

	短请求业务和长请求业务混在同一池里时，短请求最先体现的是 TTFT 抖动，而不是立刻 OOM。等到 OOM 出现，问题已经放大。

	4.3.3 案例三：TP 配大后仍然 OOM

	
kubectl get deploy vllm-server -n llm -o yaml | grep tensor-parallel -n
nvidia-smi topo -m


	

	多卡切分解决的是权重分布，不是所有动态缓存问题。跨卡拓扑、并发、上下文长度一起看才有意义。

	4.3.4 案例四：量化后静态占用降了，但队列仍然爆

	
curl -s http://vllm-server:8000/metrics | grep -E'queue|ttft|reject'
nvidia-smi


	

	这类场景说明问题不止权重大小。量化把起步显存降下来了，但长上下文和高并发没治理，队列和 TTFT 仍会继续恶化。

	4.4 容易误判的现场

				误判
			
				实际更像什么
			
				正确动作
		

				GPU util 不高就不是显存问题
			
				KV Cache / 队列占住显存
			
				看显存与请求画像
		

				上量化就一定能解决
			
				可能只解决静态占用
			
				继续看并发和长上下文
		

				多卡就一定稳
			
				动态缓存仍会放大
			
				继续做分池和预算
		

	4.5 值班交接重点

	
1. 当前问题更像静态占用、KV Cache 还是调度放大
2. 是否已调整 max-model-len / max-num-seqs
3. 是否已做长短请求分池
4. 临时参数何时回评与回退


	

	4.7 长案例：一次长上下文活动把统一池拖穿的现场

	
现象：
活动开始后，长文总结与 RAG 请求比例陡增，GPU 显存快速贴边，短问答 TTFT 从 800ms 升到 4s。

第一轮判断：
值班最开始只看到显存高，觉得是模型太大。

第二轮下钻：
请求画像显示长请求桶位占比从 8% 升到 37%，队列和 reject 同步抬高。

结论：
真正的问题是统一池没有按请求画像隔离，长请求把 KV Cache 和队列都占住了。


	

	4.6 现场动作边界

				动作
			
				什么时候能直接做
			
				什么时候要升级
		

				下调并发 / context 长度
			
				OOM 已影响业务
			
				需同步业务 SLA
		

				临时分池
			
				已确认长短请求互相拖累
			
				需同步网关和平台
		

				切量化或 TP
			
				不建议夜间现场直接改
			
				需要压测与验收
		

				扩卡或换池
			
				涉及资源申请
			
				需平台与成本评估
		

	五、故障排查和监控

	5.1 快速排查清单

	
nvidia-smi
kubectl logs -n llm deploy/vllm-server --tail=100
kubectl get deploy vllm-server -n llm -o yaml
grep'input_tokens'/var/log/llm/access.log | tail -20

kubectl describe pod -n llm vllm-server-0
kubectl get events -n llm --sort-by=.lastTimestamp | tail -20


	

	5.2 监控建议

				层次
			
				指标
			
				建议
		

				GPU
			
				显存、util、温度
			
				显存贴边 10 分钟即预警
		

				服务
			
				TTFT、队列、拒绝数
			
				按模型池分别看
		

				请求
			
				输入长度分布、输出长度分布
			
				画像变化直接预警
		

				K8s
			
				重启、Pending、调度失败
			
				判断是不是平台放大
		

	5.3 回归验证

	
1. 显存不再长期贴边
2. OOM 和重启事件归零
3. 长上下文业务已独立分池
4. TTFT 与 P99 恢复稳定

nvidia-smi dmon -s mu -d 2
curl -s http://vllm-server:8000/metrics | grep -E'ttft|queue|reject'


	

	5.4 监控与告警细化

				维度
			
				指标
			
				目的
		

				显存
			
				used / total、峰值、波动
			
				看是否贴边
		

				请求画像
			
				输入 / 输出 token 分布
			
				看业务变化
		

				服务端
			
				队列深度、拒绝数、TTFT
			
				看调度与缓存压力
		

				平台
			
				Pod 重启、Pending、HPA 变化
			
				看 K8s 放大器
		

	
groups:
-name:llm-serving-detail
 rules:
  -alert:LLMQueueDepthHigh
   expr:llm_queue_depth>12
   for:10m
  -alert:LLMRejectBurst
   expr:increase(llm_request_rejected_total[10m])>10
   for:5m


	

	5.5 仪表盘建议

				面板
			
				指标
		

				GPU 面板
			
				显存、GPU util、温度、功耗
		

				请求画像面板
			
				输入 / 输出 token 桶位
		

				服务面板
			
				队列深度、TTFT、拒绝数
		

				平台面板
			
				Pod 重启、扩缩容、路由命中情况
		

	5.7 阈值建议

				指标
			
				建议阈值
		

				显存使用率
			
				持续>90%需解释
		

				队列深度
			
				持续高位需扩容或分池
		

				拒绝数
			
				出现即说明已触边
		

				TTFT P99
			
				超出 SLA 需回看请求画像
		

	5.6 值班排障顺序模板

	
1. 先分静态占用和动态占用
2. 先拉请求画像，不只看平均值
3. 先降并发、降长上下文，再看量化与 TP
4. 先做分池和路由隔离，再谈扩卡
5. 所有临时参数都要写回交接


	

	六、总结

	6.1 技术要点回顾

	显存问题先分静态占用和动态占用；

	KV Cache、并发、上下文长度经常是第一放大器；

	参数贴边和混池策略会把问题从可控变成频繁 OOM。

	6.2 值班动作建议

	先拉显存与请求画像。

	先降并发和上下文，再谈扩卡。

	先做分池和安全参数模板，再追极限吞吐。

	6.3 参考资料

	推理框架参数说明

	DCGM 指标说明

	团队容量预算与压测基线

	附录

	A. 命令速查表

				目标
			
				命令
		

				看显存
			
				nvidia-smi
		

				看服务日志
			
				kubectl logs
		

				看部署参数
			
				kubectl get deploy -o yaml
		

				看请求画像
			
				grep input_tokens access.log
		

	B. 根因矩阵

				根因
			
				典型信号
		

				权重过大
			
				启动后即高显存
		

				KV Cache 放大
			
				长上下文 + 并发突增
		

				参数贴边
			
				gpu-memory-utilization 太高
		

				调度放大
			
				K8s 层重启与混部
		

	C. 值班复盘清单

	
1. 是否区分了静态占用和动态占用
2. 是否拉取了请求画像与输入长度分布
3. 是否核对了 max-model-len / max-num-seqs / gpu-memory-utilization
4. 是否确认了分池与 K8s 调度策略
5. 是否验证处理后 OOM 清零


	

	D. 容量预算速查

	
1. 模型权重先占多少显存
2. 预留多少给运行时和临时 buffer
3. 在目标并发下每请求可分到多少 KV Cache
4. 长上下文业务是否单独成池


	

	E. 回滚与整改清单

	
1. 临时调低的并发与 max-model-len 是否已记录
2. 分池后的网关路由是否稳定
3. 量化或 TP 调整是否补做压测
4. HPA 是否已纳入 GPU 或队列指标


	

	F. 现场快速预算清单

	
1. 卡总显存是多少
2. 模型静态占用了多少
3. 还剩多少给 KV Cache 和临时 buffer
4. 当前长上下文比例是多少
5. 当前并发阈值是否超过预算


	

	G. 参数动作速查

				动作
			
				主要收益
			
				风险
		

				降max-model-len
			
				直接压缩长请求显存预算
			
				长上下文业务受限
		

				降max-num-seqs
			
				降低并发缓存压力
			
				吞吐下降
		

				降gpu-memory-utilization
			
				留安全余量
			
				峰值吞吐降低
		

				分池
			
				长短请求隔离
			
				路由与运维复杂度上升
		

	H. 值班交接模板

	
模型与精度：
当前池：
当前 OOM / reject 情况：
当前请求画像：
已调整参数：
是否已分池：
是否需要回滚：


	

	I. 输出样例库

	
nvidia-smi 样例：
Memory-Usage 73341MiB / 81920MiB
说明：已接近上限，继续看请求画像和框架参数

metrics 样例：
llm_queue_depth 18
llm_request_rejected_total 12
说明：队列和拒绝已经出现，优先做并发和分池治理


	

	J. 分池整改模板

	
短池服务名：
长池服务名：
路由规则：
各池 max-model-len：
各池 max-num-seqs：
各池 GPU 配额：
回滚方式：


	

	K. 参数收益与风险矩阵

				参数动作
			
				主要收益
			
				主要风险
		

				降max-model-len
			
				长请求显存下降
			
				影响长上下文业务
		

				降max-num-seqs
			
				并发缓存压力下降
			
				吞吐下降
		

				降预留比例贴边
			
				表面吞吐提升
			
				OOM 风险上升
		

				分池
			
				隔离长短请求
			
				运维复杂度上升
		

	L. 流量分池实施清单

	
1. 路由规则是否已准备
2. 长池和短池参数是否已固化
3. HPA 是否分别配置
4. 回滚是否能快速切回单池


	

	M. 指标样例库

	
gpu util 72%, memory util 94%
说明：显存已接近顶，但计算还没打满，更像缓存和排队问题

queue_depth 18, rejected_total 12
说明：已经开始拒绝，应优先做并发和分池治理


	

	N. 路由回滚模板

	
当前长池服务：
当前短池服务：
路由切回条件：
回滚后的统一池参数：
观察窗口：


	

	O. 输出样例库

	
nvidia-smi dmon 片段：
# gpu  pwr gtemp mtemp  sm  mem  enc  dec mclk pclk
0    285  70   -   72  94   0   0 1593 1410
说明：显存利用率已接近顶，但计算没有满，更像缓存和调度问题

请求画像日志片段：
time=2026-03-09T2011Z input_tokens=7420 output_tokens=312 model=qwen2.5-7b
time=2026-03-09T2012Z input_tokens=8011 output_tokens=448 model=qwen2.5-7b
time=2026-03-09T2013Z input_tokens=7928 output_tokens=501 model=qwen2.5-7b
说明：长上下文比例已经明显升高，不应再用短问答参数模板硬撑


	

	P. 现场沟通模板

	
当前模型与精度：
当前显存峰值：
当前队列深度：
当前请求桶位分布：
已调整参数：
是否已分池：
回滚条件：


	

	Q. 动作矩阵

				现象
			
				立刻动作
			
				后续动作
		

				长上下文突增
			
				先分池或限长
			
				重做容量预算
		

				并发突刺
			
				先降max-num-seqs
			
				调整 HPA 与队列策略
		

				显存贴边
			
				先留余量
			
				评估量化和模型规格
		

				拒绝数上升
			
				先查路由和桶位
			
				调整流量分配
		

	R. 现场输出样例

	
queue_depth 18
reject_total 12
TTFT P99 3.8s
说明：已明显触边，不应继续以短问答模板硬顶长请求流量


	

	S. 显存治理优先级表

				问题类型
			
				优先级
			
				第一动作
		

				OOM 已触发重启
			
				最高
			
				先降并发 / 限长 / 止血
		

				拒绝数持续上涨
			
				高
			
				先查请求桶位和分池
		

				显存长期贴边但未 OOM
			
				中
			
				先留余量和补预算
		

				量化切换需求
			
				中
			
				单独压测，不在现场硬改
		

	T. 演练模板

	
模型：
精度：
GPU：
当前池：
当前 max-model-len：
当前 max-num-seqs：
队列峰值：
显存峰值：
回滚动作是否演练：

主题	推荐动作	原因
容量预算	先算静态占用，再算 KV Cache 预算	显存问题本质是预算问题
业务分池	长上下文与短问答分池	降低互相拖累
参数治理	安全模板与性能模板分开	避免现场贴边调参
监控	TTFT、队列、显存一起看	单看显存不够

误判	实际更像什么	正确动作
GPU util 不高就不是显存问题	KV Cache / 队列占住显存	看显存与请求画像
上量化就一定能解决	可能只解决静态占用	继续看并发和长上下文
多卡就一定稳	动态缓存仍会放大	继续做分池和预算

动作	什么时候能直接做	什么时候要升级
下调并发 / context 长度	OOM 已影响业务	需同步业务 SLA
临时分池	已确认长短请求互相拖累	需同步网关和平台
切量化或 TP	不建议夜间现场直接改	需要压测与验收
扩卡或换池	涉及资源申请	需平台与成本评估

层次	指标	建议
GPU	显存、util、温度	显存贴边 10 分钟即预警
服务	TTFT、队列、拒绝数	按模型池分别看
请求	输入长度分布、输出长度分布	画像变化直接预警
K8s	重启、Pending、调度失败	判断是不是平台放大

维度	指标	目的
显存	used / total、峰值、波动	看是否贴边
请求画像	输入 / 输出 token 分布	看业务变化
服务端	队列深度、拒绝数、TTFT	看调度与缓存压力
平台	Pod 重启、Pending、HPA 变化	看 K8s 放大器

面板	指标
GPU 面板	显存、GPU util、温度、功耗
请求画像面板	输入 / 输出 token 桶位
服务面板	队列深度、TTFT、拒绝数
平台面板	Pod 重启、扩缩容、路由命中情况

指标	建议阈值
显存使用率	持续>90%需解释
队列深度	持续高位需扩容或分池
拒绝数	出现即说明已触边
TTFT P99	超出 SLA 需回看请求画像

目标	命令
看显存	nvidia-smi
看服务日志	kubectl logs
看部署参数	kubectl get deploy -o yaml
看请求画像	grep input_tokens access.log

根因	典型信号
权重过大	启动后即高显存
KV Cache 放大	长上下文 + 并发突增
参数贴边	gpu-memory-utilization 太高
调度放大	K8s 层重启与混部

动作	主要收益	风险
降max-model-len	直接压缩长请求显存预算	长上下文业务受限
降max-num-seqs	降低并发缓存压力	吞吐下降
降gpu-memory-utilization	留安全余量	峰值吞吐降低
分池	长短请求隔离	路由与运维复杂度上升

参数动作	主要收益	主要风险
降max-model-len	长请求显存下降	影响长上下文业务
降max-num-seqs	并发缓存压力下降	吞吐下降
降预留比例贴边	表面吞吐提升	OOM 风险上升
分池	隔离长短请求	运维复杂度上升

现象	立刻动作	后续动作
长上下文突增	先分池或限长	重做容量预算
并发突刺	先降max-num-seqs	调整 HPA 与队列策略
显存贴边	先留余量	评估量化和模型规格
拒绝数上升	先查路由和桶位	调整流量分配

问题类型	优先级	第一动作
OOM 已触发重启	最高	先降并发 / 限长 / 止血
拒绝数持续上涨	高	先查请求桶位和分池
显存长期贴边但未 OOM	中	先留余量和补预算
量化切换需求	中	单独压测，不在现场硬改

声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。举报投诉

gpu

gpu

+关注

关注
28

文章
5259

浏览量
136039
参数

参数

+关注

关注
11

文章
1870

浏览量
34026
大模型

大模型

+关注

关注
2

文章
3750

浏览量
5268

原文标题：大模型服务为什么总是爆显存：从 KV Cache 到并发模型的运维视角

文章出处：【微信号：magedu-Linux，微信公众号：马哥Linux运维】欢迎添加关注！文章转载请注明出处。

搜索历史

大模型服务为什么总是爆显存

评论