显存管理的艺术：PagedAttention 与 block_size 调优

在 AMD Instinct GPU 上跑大模型，最让人头疼的往往不是环境配置，而是模型加载后那“捉襟见肘”的显存。很多时候，明明显卡规格很高，却因为在推理过程中显存碎片化严重，导致无法分配连续的 KV Cache，最终引发 OOM（Out Of Memory）崩溃。vLLM 核心的 PagedAttention 技术虽然从算法层面解决了显存碎片问题，但在 ROCm 7.x 环境下，想要榨干每一比特显存，还需要我们在参数配置上下点功夫。

PagedAttention 的原理是将 KV Cache 切分成非连续的内存块（Block），这与操作系统的虚拟内存分页机制非常相似。在 AMD 平台上，block_size 的选择直接影响显存利用率和管理开销。如果你的业务场景主要是短文本对话（例如客服问答、代码补全），序列长度波动不大，可以尝试将 block_size 设置得小一些（如 16）。较小的块能更精细地匹配实际需求，减少因“大材小用”造成的内部碎片。反之，如果是长文档总结或长上下文推理，序列长度普遍较长且稳定，将 block_size 调整为 32 甚至 64 会更合适，这样可以减少页表管理的元数据开销，提升内存访问的局部性。

在实际操作中，我们可以通过观察 rocm-smi 的输出来辅助判断。启动服务后，持续监控显存使用率的变化曲线。如果发现显存占用呈现阶梯状跳跃且伴随大量未利用的空隙，可能意味着当前的 block 尺寸与你的输入分布不匹配。调整该参数无需重新编译，只需在启动命令中追加 --block-size 16 即可即时生效，找到那个让显存利用率曲线最平滑的“甜蜜点”。

平衡之道：gpu-memory-utilization 参数实战

除了块大小，gpu-memory-utilization 是另一个决定生死的关键参数。这个参数告诉 vLLM 预分配多少比例的显存用于模型权重和 KV Cache。很多初学者喜欢直接拉满到 0.98 甚至 1.0，觉得这样能塞进更大的模型或支持更长的上下文，但这在 production 环境中极其危险。

ROCm 驱动本身、操作系统内核以及偶尔爆发的瞬时计算峰值都需要一定的显存缓冲。一旦设置过高，任何微小的额外分配请求都可能导致整个推理进程被系统杀死。根据我在多台 Instinct MI250 和 MI300 上的实测经验，0.90 到 0.95 是一个相对安全的区间。

• 0.90：适合对稳定性要求极高、并发波动大的生产环境。预留的 10% 显存足以应对突发的流量尖峰和驱动层面的临时开销。
• 0.95：适合独占实例或离线批处理任务。如果你确定没有其他进程争抢资源，且模型权重固定，这个值能最大化 KV Cache 容量，从而支持更高的并发数（max-num-seqs）。

设置方法非常简单，在启动脚本中加入：

--gpu-memory-utilization 0.92

建议先从 0.90 开始试运行，通过压力测试观察是否会出现 OOM。如果运行稳定，再逐步以 0.01 为步长向上微调，直到找到当前硬件和负载下的极限值。切记，不要为了多支撑几个并发请求而牺牲服务的可用性，频繁的重启重置比稍微低一点的吞吐量更影响用户体验。

进阶优化：FP8 量化在 ROCm 7.x 下的落地

当显存管理策略调整到极致仍无法满足需求时，量化就是最后的杀手锏。ROCm 7.x 对 FP8（8 位浮点数）的支持已经相当成熟，特别是在较新的 Instinct 架构上，FP8 不仅能将模型权重的显存占用减半，还能利用 Tensor Core 大幅提升计算吞吐。

启用 FP8 量化在 vLLM 中非常直观，只需添加 --quantization fp8 参数。但这里有两个细节需要注意：

1. 模型兼容性：并非所有模型都原生支持 FP8 推理。通常需要使用经过校准（Calibrated）的 FP8 权重文件，或者让 vLLM 在加载时动态进行量化（Dynamic Quantization）。动态量化会增加首字延迟（TTFT），但能显著降低显存门槛。
2. 算子回退机制：尽管 ROCm 7.x 进步巨大，但仍有极少数算子可能不完全支持 FP8 加速。如果遇到 unsupported operator 报错，可以尝试检查 vLLM 版本是否最新，或者在特定层强制回退到 FP16 计算。不过在日常的大语言模型推理中，这种情况已越来越少见。

下面是一个结合了上述所有优化策略的完整启动示例，假设我们要部署一个 Llama 3 8B 模型：

python -m vllm.entrypoints.api_server \
    --model meta-llama/Meta-Llama-3-8B-Instruct \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.92 \
    --block-size 16 \
    --quantization fp8 \
    --host 0.0.0.0 \
    --port 8000

在这个配置下，我们利用了双卡并行分摊权重，设置了保守但安全的显存比例，针对变长序列优化了块大小，并启用了 FP8 加速。

最后，别忘了在服务运行时编写一个简单的监控脚本来验证效果。你可以使用 Python 结合 rocm-smi 的输出解析，或者直接轮询 /metrics 接口（如果开启了 Prometheus 支持），实时打印显存利用率：

import subprocess
import re

def check_vram_usage():
    result = subprocess.run(['rocm-smi', '--showmeminfo', 'vram'], capture_output=True, text=True)
    # 简单解析输出，实际生产中建议解析 JSON 或使用 DCGM
    for line in result.stdout.splitlines():
        if "Card" in line:
            print(line)

# 在生产环境中，建议将此逻辑集成到 Prometheus Exporter 中
check_vram_usage()

通过这种精细化的显存管理组合拳，我们完全可以在 AMD Instinct GPU 上构建出既稳又快的大模型推理服务，让每一 MB 显存都发挥最大价值。