显存告急？在 AMD MI300X 上用 PagedAttention 跑通 Llama3

最近手头接了个硬骨头：要在单张 AMD Instinct MI300X 上部署 Llama3-70B 模型。熟悉大模型推理的朋友都知道，70B 参数量的模型光是权重就要吃掉上百 GB 显存，再加上推理时必不可少的 KV Cache，传统静态显存分配方案很容易直接 OOM（内存溢出），或者因为显存碎片化导致并发能力极差。

这次我尝试在 ROCm 7.x 环境下，利用 vLLM 框架的 PagedAttention 机制来破局。实测下来，这套组合拳不仅让大参数模型在单卡上跑得稳稳当当，还通过精细化的参数调优，把显存利用率推到了新高度。如果你也在为显存不够用发愁，或者想从 NVIDIA 平台迁移到 AMD 生态，这篇实战记录或许能帮你少走不少弯路。

为什么是 PagedAttention + ROCm 7.x？

以前在 AMD GPU 上跑大模型，最头疼的就是算子兼容性和显存管理。ROCm 7.x 的发布算是个分水岭，它对 hipBLASLt 和底层通信库 RCCL 做了大量优化，尤其是对 MI300X 这种拥有 192GB HBM3 显存的怪兽级显卡支持更加原生。

而 vLLM 的核心杀手锏 PagedAttention，本质上是将操作系统的虚拟内存分页思想引入了 GPU 显存管理。它不再预先分配一大块连续的显存给 KV Cache，而是按需分配非连续的内存块（Block）。这在处理变长序列时优势巨大：既消除了外部碎片，又允许我们在显存耗尽前接纳更多的并发请求。在 MI300X 上，这一机制配合高带宽特性，能让吞吐量提升非常明显。

环境搭建与源码编译避坑

开始前，确保你的系统已经安装了 ROCm 7.x 驱动。可以通过 rocm-smi 命令快速验证，如果能正常列出显卡状态和温度，说明底层驱动没问题。

接下来是重头戏：编译 PyTorch 和 vLLM。虽然官方提供了预编译包，但为了适配 MI300X 的特定架构（gfx942）并开启最新优化，强烈建议源码编译。

首先设置关键环境变量，这一步错了后面全白搭：

export PYTORCH_ROCM_ARCH="gfx942"
export HIP_PATH=/opt/rocm
export MAX_JOBS=32

安装 PyTorch 时，注意指定 ROCm 版本：

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.0
# 注：若 ROCm 7.x 有对应 wheel 包请优先使用，否则需从源码编译 torch

编译 vLLM 时，务必保证 Triton 编译器版本与 PyTorch 匹配，否则会遇到奇怪的段错误：

pip3 install vllm --no-build-isolation

如果在编译过程中报 kernel not found 或链接错误，大概率是架构代码没对上，清理 build/ 目录后重新指定 PYTORCH_ROCM_ARCH 再试。

核心实战：显存参数调优

模型加载成功只是第一步，如何配置才能让显存“寸土寸金”地利用起来才是关键。vLLM 启动时有两个核心参数直接决定生死：--gpu-memory-utilization 和 --block-size。

1. 平衡显存占用与系统缓冲

很多教程建议把 --gpu-memory-utilization 设为 0.95 甚至更高，但在生产环境中，这非常危险。MI300X 虽然显存大，但驱动本身和内核态操作也需要预留空间。我建议设置为 0.90 到 0.92 之间。

启动命令示例：

vllm serve meta-llama/Meta-Llama-3-70B-Instruct \
    --host 0.0.0.0 \
    --port 8000 \
    --tensor-parallel-size 1 \
    --gpu-memory-utilization 0.90 \
    --block-size 32 \
    --dtype bfloat16

留出 8%-10% 的显存余量，能有效防止因瞬时峰值导致的 OOM 崩溃，换来的是服务的长期稳定性。

2. Block Size 的选择策略

--block-size 控制着内存页的大小。

• 小 Block（如 16）：适合短序列、高并发的场景，显存浪费少，但管理开销略大。
• 大 Block（如 32 或 64）：适合长文本生成，能减少页表项数量，降低显存碎片。

在 Llama3 这种长上下文模型上，我实测将 block-size 设为 32 是个甜点值，既保证了长对话的流畅性，又没有明显的显存碎片浪费。

量化带来的显存奇迹

如果即使调优后显存依然吃紧，量化是最后的救命稻草。在 ROCm 7.x 下，FP8 量化已经相当成熟。

对比一下开启量化前后的显存变化（以 Llama3-70B 为例）：

• BF16 精度：模型权重约占用 140GB，加上 KV Cache，总显存占用轻松突破 160GB，剩余空间难以支撑高并发。
• FP8 精度：权重占用减半至 70GB 左右，总显存占用降至 90GB 上下。

这意味着什么？意味着你不仅能在单卡上跑起来，还能腾出近 100GB 的显存专门用于 KV Cache，并发能力直接翻倍！

开启 FP8 的命令非常简单，只需添加 --quantization fp8 参数（需模型支持或提供校准数据）：

vllm serve meta-llama/Meta-Llama-3-70B-Instruct \
    --quantization fp8 \
    --gpu-memory-utilization 0.92 \
    --block-size 32

实测在 MI300X 上，FP8 推理的延迟增加微乎其微，但吞吐量提升显著，性价比极高。

写在最后

从最初的“环境配置地狱”到如今能稳定运行 70B 大模型，AMD ROCm 生态的进步确实肉眼可见。通过 PagedAttention 机制和合理的参数调优，我们完全可以在单张 MI300X 上构建出高性能、低成本的推理服务。对于预算有限但又需要大参数模型能力的团队来说，这绝对是一条值得探索的路径。

当然，纸上得来终觉浅，真正的性能拐点还需要结合你的具体业务场景去测试。如果你也想亲手试试这套方案，或者需要更多算力资源来验证你的想法：

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