MI300X 显存不够用，试试 vLLM 的量化与分页注意力

显存告急？MI300X 上的 vLLM 调优实战

手里拿着 AMD MI300X 这种“显存怪兽”（192GB HBM3），却在加载 70B 甚至更大参数模型时频频遭遇 OOM（显存溢出），这听起来有些不可思议，但在实际工程落地中却并不罕见。很多时候，问题不在于硬件不够强，而在于软件栈的默认配置未能充分释放硬件潜力。特别是在 ROCm 7.x 环境下部署 vLLM 进行大模型推理时，如果不针对显存管理做精细化调优，很容易出现“守着金矿讨饭吃”的尴尬局面。今天就来聊聊我在 MI300X 上通过调整量化策略和分页注意力机制，成功跑通超大模型的实战经验。

重新定义显存水位：--gpu-memory-utilization的博弈

很多开发者在使用 vLLM 时，习惯直接沿用默认参数，或者激进地设置为0.95甚至更高，试图榨干每一字节显存。在 NVIDIA GPU 上这可能行得通，但在 AMD ROCm 生态下，这种做法往往适得其反。

MI300X 虽然拥有巨大的显存容量，但 ROCm 驱动本身以及底层内核操作需要预留一定的“安全缓冲区”。如果将--gpu-memory-utilization设置得过高，一旦遇到瞬时峰值请求或 KV Cache 动态分配时的碎片波动，极易触发系统的 OOM 保护机制，导致服务直接崩溃。

经过多轮压力测试，我发现将这一参数控制在0.90 到 0.92之间是最稳妥的“甜点区”。

vllm serve meta-llama/Llama-3-70b-Instruct\--tensor-parallel-size2\--gpu-memory-utilization0.92\--block-size16

在这个配置下，系统保留了约 8% 的显存作为缓冲池。这部分空间看似浪费，实则是防止显存碎片化导致分配失败的关键保险。在实际运行 70B 模型时，这个微小的让步换来了服务的长期稳定性，避免了因偶尔的内存抖动而重启服务，从整体吞吐量来看反而是收益最大的选择。

对抗碎片化：block_size的精细权衡

vLLM 的核心优势在于 PagedAttention 技术，它将 KV Cache 像操作系统管理虚拟内存一样分块存储。这里就涉及到了--block-size参数的选择。

在 MI300X 上，显存带宽极高，但显存管理器的开销也不容忽视。

• 较小的 block size（如 8）：能提高显存的细粒度利用率，减少内部碎片，特别适合处理长度差异极大的请求序列。但在高并发场景下，过多的块表管理会增加 GPU 的计算负担，略微拖慢推理速度。
• 较大的 block size（如 32 或 64）：减少了元数据管理开销，提升了吞吐上限，但可能会因为“最后一页填不满”而产生较多的外部碎片。

对于大多数通用对话场景，我推荐从16开始尝试。如果你的业务场景中请求长度非常固定（例如都是长文档摘要），可以适当调大到 32；如果是极度碎片化的短文本交互，则可以尝试 8。在 ROCm 7.x 版本中，vLLM 对块表的调度逻辑已有优化，默认值通常表现不错，但针对特定业务微调该参数，往往能再挤出 5%-10% 的有效显存空间。

FP8 量化：ROCm 7.x 下的性能跃迁

如果说调整参数是“省吃俭用”，那么开启 FP8 量化就是“开源节流”的大招。AMD 在 ROCm 7.x 中对 FP8 算子进行了深度优化，使得在 MI300X 上运行量化模型不仅显存占用减半，推理速度也有显著提升。

以前我们可能担心量化会损失精度，但在 Llama 3 等现代架构上，FP8 带来的精度损失几乎可以忽略不计，换来的却是实实在在的性能红利。

显存与速度的双重提升

未开启量化时，一个 70B 模型的权重加上 KV Cache 可能轻松吃掉 140GB+ 显存，留给并发请求的空间所剩无几。而启用 FP8 后，权重大小直接压缩至原来的 50% 左右。这意味着同样的显存预算下，你可以：

1. 加载更大的模型：原本单卡跑不下的模型，现在可以尝试双卡甚至单卡运行。
2. 支持更高的并发：节省下来的显存全部转化为 KV Cache 空间，允许同时处理更多的用户请求。

在启动命令中加入--quantization fp8即可体验这一变化（需确保模型权重已转换为 FP8 格式或使用支持动态量化的版本）：

vllm serve meta-llama/Llama-3-70b-Instruct-FP8\--tensor-parallel-size2\--quantizationfp8\--gpu-memory-utilization0.92

实测数据显示，在 MI300X 上，开启 FP8 后不仅显存占用大幅下降，由于数据搬运量的减少和 Tensor Core 的高效利用，Token 生成速度（Token/s）相比 BF16 精度提升了约 30%-40%。对于追求高吞吐的生产环境，这几乎是必选项。

结语

在 MI300X 上跑大模型，硬件只是基础，真正的胜负手在于软件配置的细节。不要盲目相信默认值，也不要一味追求极致的显存占用率。通过合理设置--gpu-memory-utilization留出安全余量，根据业务特征调整block_size对抗碎片化，并充分利用 ROCm 7.x 成熟的 FP8 量化能力，我们完全可以在有限的资源下构建出稳定、高效的大模型推理服务。这些看似微小的参数调整，往往就是项目从“ Demo 能跑”到“生产可用”的关键跨越。

200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper