显存碎片化治理，调整 block size 提升推理稳定性
为什么显存明明够用却频频 OOM？
最近在生产环境部署 vLLM 服务时，遇到一个让人头疼的现象：监控显示显存占用率只有 85%，距离设定的 90% 阈值还有余裕，但服务却突然抛出 OOM（Out 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:result=subprocess.run(['rocm-smi','--showmeminfo','vram'],capture_output=True,text=True,check=True)output=result.stdout# 解析输出，提取 Used 和 Total 信息（具体解析逻辑依 rocm-smi 版本而定）# 这里仅作示意，实际需根据 rocm-smi 输出格式调整正则print("当前显存状态快照：")print(output)returnoutputexceptsubprocess.CalledProcessErrorase:print(f"获取显存信息失败：{e}")returnNonedefmonitor_fragmentation_trend(interval=10,duration=60):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-size=16的实例；长文本任务则路由到block-size=64的集群。如果资源有限无法拆分，则取折中值32，并适当降低gpu-memory-utilization至 0.88，用少量的显存冗余换取系统的长期稳定。
此外，定期重启服务（如在低峰期滚动更新）也是清除累积碎片的简单有效手段。虽然听起来不够“智能”，但在自动 compaction 机制完善之前，这确实是保障 SLA 的务实之选。
治理显存碎片化不是一劳永逸的设置，而是一个持续观察、假设、验证的过程。在 AMD GPU 生态日益成熟的今天，理解底层原理并结合业务特征微调参数，能让我们的推理服务跑得更稳、更远。
200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper