为什么显存明明够用却频频 OOM最近在生产环境部署 vLLM 服务时遇到一个让人头疼的现象监控显示显存占用率只有 85%距离设定的 90% 阈值还有余裕但服务却突然抛出 OOMOut Of Memory错误并崩溃。重启后正常跑几个小时又重复上演这一出。排查一圈发现 culprit 并非模型权重过大而是典型的显存碎片化问题。在 AMD Instinct GPU如 MI300X配合 ROCm 7.x 的环境下这个问题尤为隐蔽。vLLM 虽然通过 PagedAttention 机制极大地提升了显存利用率但其底层的内存块分配策略如果与业务场景的序列长度分布不匹配就会产生大量无法被复用的细小空洞。这些“碎片”积少成多导致新请求到来时即便总剩余显存足够也找不到一块连续的空间来存放新的 KV Cache最终触发崩溃。深入理解 block-size 与碎片化的关系要解决碎片化得先搞懂 vLLM 是如何管理显存的。它将显存划分为固定大小的“块”Block每个块能容纳一定数量的 Token。block-size参数决定了这个基本单元的大小。较小的 block-size如 8 或 16粒度更细理论上能更精准地贴合短序列请求减少内部浪费。但在高并发长序列场景下管理成千上万个小区块会带来额外的元数据开销且容易在显存中留下大量难以拼凑的微小空隙。较大的 block-size如 64 或 128管理开销小适合长文本生成。但如果业务中充斥着大量短请求比如问答场景平均输出仅 50 tokens一个大块只用了小部分剩下的空间就被“内部碎片”锁死无法分配给其他请求。在 AMD 显卡上由于 HBM 带宽极高但延迟特性与 Nvidia 略有不同这种碎片化效应在长时间运行后会被放大。很多默认配置直接沿用了对标 Nvidia 的参数忽略了实际业务中序列长度的长尾分布这才是稳定性杀手。动手实践调整 block-size 策略针对上述问题最直接的优化手段就是根据业务特征调整--block-size。没有绝对的“最佳值”只有“最适合”。如果你的业务主要是短文本交互如客服对话、指令遵循尝试将 block-size 调小至16。这能让显存分配更紧凑减少大块闲置。python-mvllm.entrypoints.api_server\--modelmeta-llama/Llama-3-8B-Instruct\--block-size16\--gpu-memory-utilization0.92\--port8000反之如果是长文档总结或代码生成序列长度普遍超过 2048建议将 block-size 提升至64甚至128。这样可以降低页表管理的复杂度让连续的显存区域更有效地被利用。python-mvllm.entrypoints.api_server\--modelmeta-llama/Llama-3-70B-Instruct\--block-size64\--gpu-memory-utilization0.90\--tensor-parallel-size4\--port8000注意调整gpu-memory-utilization也至关重要。在 ROCm 7.x 上建议不要顶格设为 0.95保留0.90-0.92的缓冲区间能给驱动层和系统预留应对瞬时峰值的空间避免因为微小的碎片波动直接撞墙。编写脚本监控显存碎片程度光改参数不够还得有数据支撑。下面这段 Python 脚本利用pynvml的 ROCm 兼容逻辑或直接解析rocm-smi输出视具体环境而定此处以通用监控思路为例实际在 ROCm 环境中可结合pyrsmi或解析/sys/class/drm信息帮助观察显存分配情况。在实际生产中我更倾向于直接分析 vLLM 的日志或通过 Prometheus 抓取其内部指标。不过为了直观展示碎片化概念我们可以写一个简单的脚本来模拟或读取显存块的使用状态注vLLM 内部指标更准此处提供外部监控思路importsubprocessimportreimporttimedefget_gpu_memory_info():# 使用 rocm-smi 获取显存信息需确保环境变量路径正确try:resultsubprocess.run([rocm-smi,--showmeminfo,vram],capture_outputTrue,textTrue,checkTrue)outputresult.stdout# 解析输出提取 Used 和 Total 信息具体解析逻辑依 rocm-smi 版本而定# 这里仅作示意实际需根据 rocm-smi 输出格式调整正则print(当前显存状态快照)print(output)returnoutputexceptsubprocess.CalledProcessErrorase:print(f获取显存信息失败{e})returnNonedefmonitor_fragmentation_trend(interval10,duration60):print(f开始监控每隔{interval}秒记录一次持续{duration}秒...)for_inrange(duration//interval):get_gpu_memory_info()time.sleep(interval)print(-*30)if__name____main__:# 生产环境中建议对接 vLLM 的 /metrics 接口获取 block 利用率monitor_fragmentation_trend()提示真正精准的碎片化监控应直接查看 vLLM 暴露的 Prometheus 指标如vllm:gpu_cache_usage_perc与请求拒绝率的关联。若发现缓存使用率未满但请求频繁失败大概率是碎片化所致。生产环境的动态调优经验在真实场景中静态参数往往难以应对波动的流量。我们曾在一个混合负载平台上做过这样的优化白天以短问答为主夜间批量处理长文档。我们通过分析历史日志中的sequence_length分布发现 80% 的请求输出长度集中在 128 tokens 以内但仍有 5% 的长尾请求超过 2048。最初为了照顾长尾我们设置了较大的 block-size结果白天高峰期碎片率飙升。后来的解决方案是分时段部署或按业务线隔离。对于短文本业务线独立部署一套block-size16的实例长文本任务则路由到block-size64的集群。如果资源有限无法拆分则取折中值32并适当降低gpu-memory-utilization至 0.88用少量的显存冗余换取系统的长期稳定。此外定期重启服务如在低峰期滚动更新也是清除累积碎片的简单有效手段。虽然听起来不够“智能”但在自动 compaction 机制完善之前这确实是保障 SLA 的务实之选。治理显存碎片化不是一劳永逸的设置而是一个持续观察、假设、验证的过程。在 AMD GPU 生态日益成熟的今天理解底层原理并结合业务特征微调参数能让我们的推理服务跑得更稳、更远。200小时GPU算力已就位快来领取https://marketing.csdn.net/questions/Q2604140858304426315?utm_sourceAIpaper