显存分页的底层逻辑：为什么 AMD GPU 需要特殊关照

在大模型推理的江湖里，显存管理一直是那个“看不见的瓶颈”。很多开发者在 NVIDIA 平台上跑通 vLLM 后，信心满满地迁移到 AMD Instinct GPU（如 MI300X）上，结果却常常卡在显存溢出（OOM）或者性能断崖式下跌上。这背后的核心原因，往往不在于算力不够，而在于对 PagedAttention 这一核心技术在不同硬件架构下的理解偏差。

PagedAttention 的本质是将操作系统的虚拟内存分页思想引入到了 GPU 显存管理中。传统注意力机制需要为每个序列预先分配连续的显存块来存储 KV Cache，这在处理变长序列时会产生大量的内部碎片——就像你租了一整层楼却只住了一间房，剩下的空间全浪费了。vLLM 通过非连续的物理块映射，让显存利用率从传统的 40%-50% 提升到了 90% 以上。

但在 ROCm 生态下，这套机制的实现有着独特的“脾气”。AMD 的 HBM（高带宽内存）架构与传统的 GDDR6 在物理拓扑上截然不同，ROCm 驱动层面的内存分配器（Allocator）行为也与 CUDA 存在细微差异。如果直接照搬 NVIDIA 的参数配置，很容易因为块表（Block Table）对齐问题或页大小不匹配，导致驱动层拒绝分配内存，或者在运行时产生严重的碎片化，最终让那恐怖的 5.3 TB/s 带宽英雄无用武之地。

ROCm 驱动层的内存分配陷阱

要在 AMD GPU 上真正发挥 PagedAttention 的威力，首先得读懂 ROCm 驱动是如何管理显存的。在 CUDA 世界里，cudaMalloc 的行为相对统一，但在 ROCm 中，hipMalloc 及其底层的 HSA（Heterogeneous System Architecture）代理在处理大页内存和碎片整理时，有着更严格的约束。

当你启动 vLLM 服务时，它会向驱动申请一大块连续的区域作为“显存池”，然后在这个池子里进行细粒度的切分。问题就出在这个切分过程。ROCm 7.x 虽然已经大幅优化了内存管理，但对于非标准大小的内存块请求，仍然可能触发额外的元数据开销。特别是在 MI300X 这种拥有 192GB 显存的巨兽上，如果块大小（Block Size）设置不当，累积起来的元数据占用和外部碎片足以吃掉几十 GB 的宝贵空间。

此外，AMD GPU 的 Compute Unit (CU) 访问 HBM 的路径经过 Infinity Fabric 互联，对内存对齐的要求极高。如果 PagedAttention 生成的物理块地址没有按照特定的边界对齐（通常是 2MB 或更大），不仅会导致访存效率下降，还可能引发驱动层的保护性报错。这就是为什么在日志里偶尔会看到看似莫名其妙的"Memory Access Violation"，其实根源在于块表的物理布局不符合 ROCm 的底层预期。

因此，在 ROCm 环境下部署 vLLM，不能只做“甩手掌柜”依赖默认配置。我们需要深入到底层参数，手动干预块表的生成策略，使其与 AMD 的硬件特性“同频共振”。

实战：手动调优块表大小以适应变长序列

理论讲再多，不如代码跑一遍。在实际业务中，输入序列的长度分布往往是不均匀的：既有几十字的短问答，也有几千字的文档分析。默认的 block-size=16 在 NVIDIA 卡上表现良好，但在某些 AMD 场景下，面对大量长文本时，可能会因为页表项过多导致管理开销激增；而面对大量短文本时，又可能因为块内浪费导致利用率不足。

下面这段实践代码展示了如何在 Python 层面诊断当前的显存块状态，并通过调整 vLLM 的启动参数来优化块表大小。我们假设你已经在一个配置好 ROCm 7.x 和 vLLM 的 DevCloud 实例中。

首先，我们需要一个脚本来探测当前硬件对不同类型块大小的敏感度。虽然 vLLM 主要在 C++ 层管理内存，但我们可以通过模拟不同配置下的显存预留情况来辅助决策：

import torch
import gc

def analyze_memory_fragmentation(block_size_candidates=[16, 32, 64]):
    """
    模拟不同 block-size 下的显存碎片情况
    注意：这只是一个估算逻辑，真实效果需结合 vLLM 启动测试
    """
    if not torch.cuda.is_available():
        print("❌ 未检测到 ROCm 设备，请确认 HIP_VISIBLE_DEVICES 设置")
        return

    device = torch.device("cuda:0")
    total_mem = torch.cuda.get_device_properties(0).total_memory
    print(f"💡 设备总显存：{total_mem / 1024**3:.2f} GB")
    
    # 模拟 KV Cache 占用：假设每个 token 占用约 0.5KB (BF16, 2 层，简化估算)
    # 实际 vLLM 内部计算更复杂，此处仅作趋势参考
    token_bytes = 0.5 * 1024 
    
    results = []
    for bs in block_size_candidates:
        # 模拟分配大量小块 vs 少量大块
        # 块越多，页表元数据开销越大（ROCm 下尤为明显）
        # 块越大，内部碎片（块内未用空间）可能越多
        
        # 假设我们要容纳 100k tokens
        target_tokens = 100000
        num_blocks_needed = (target_tokens + bs - 1) // bs
        
        # 估算元数据开销：ROCm 下每个块描述符约占用额外 64-128 字节
        metadata_overhead_per_block = 128 
        total_overhead = num_blocks_needed * metadata_overhead_per_block
        
        # 内部碎片估算：平均每个块浪费一半空间
        internal_waste = num_blocks_needed * (bs / 2) * token_bytes
        
        total_waste = total_overhead + internal_waste
        
        results.append({
            "block_size": bs,
            "num_blocks": num_blocks_needed,
            "estimated_waste_mb": total_waste / 1024**2,
            "overhead_mb": total_overhead / 1024**2
        })
        
    print("\n📊 块大小策略估算对比 (目标容纳 100k tokens):")
    print(f"{'Block Size':<12} | {'块数量':<10} | {'元数据开销 (MB)':<15} | {'预估总浪费 (MB)':<15}")
    print("-" * 60)
    for res in results:
        print(f"{res['block_size']:<12} | {res['num_blocks']:<10} | {res['overhead_mb']:<15.2f} | {res['estimated_waste_mb']:<15.2f}")

if __name__ == "__main__":
    analyze_memory_fragmentation()

运行上述脚本后，你会得到一份针对当前环境的估算报告。在 MI300X 上，你可能会发现，当序列长度普遍较长（如超过 2048 tokens）时，将 block-size 从默认的 16 调整为 32 甚至 64，能显著减少块数量，从而降低 ROCm 驱动层的元数据管理压力。反之，如果业务多为短对话，保持 16 可能是更好的选择，以避免块内浪费。

得到结论后，真正的调整是在启动 vLLM 服务时完成的。以下是一个针对长文本场景优化后的启动命令示例，重点在于 --block-size 和 --gpu-memory-utilization 的配合：

export HIP_VISIBLE_DEVICES=0
# 针对长文档分析场景，增大 block-size 以减少页表开销
python -m vllm.entrypoints.api_server \
    --model meta-llama/Llama-3-70B-Instruct \
    --host 0.0.0.0 \
    --port 8000 \
    --dtype bfloat16 \
    --block-size 32 \
    --gpu-memory-utilization 0.92 \
    --max-model-len 16384 \
    --disable-custom-all-reduce

这里有两个关键点值得注意：

1. --block-size 32：这是根据前面的分析做出的调整。在 ROCm 7.x 下，较大的块尺寸能有效减少 HBM 控制器的寻址次数，尤其在处理长序列时，能观察到 Prefill 阶段的延迟有微妙但稳定的下降。
2. --gpu-memory-utilization 0.92：相比默认的 0.9，我们稍微激进了一点。因为优化了块表结构，减少了碎片，我们有信心在不触发 OOM 的前提下挤出更多空间给 KV Cache。当然，这个值需要根据实际压测微调，如果发现偶发崩溃，需回调至 0.90。

碎片化治理与生产环境的稳定性

调整块大小只是第一步，真正的挑战在于长期运行中的碎片化治理。在高频并发场景下，请求的不断创建和销毁会导致显存池中留下许多无法合并的小空洞。虽然 PagedAttention 本身通过非连续映射解决了大部分问题，但在 ROCm 驱动层，如果长时间不进行整理，仍可能出现“有总空间却分配不出连续块”的假性 OOM。

在生产环境中，建议结合 vLLM 的监控指标，观察 kv_cache_usage_percentage 的变化曲线。如果发现该指标在未达上限时请求就开始失败，或者显存占用率呈现阶梯式上升而不下降，这通常是碎片化的信号。此时，除了重启服务这种“笨办法”，更优雅的策略是实施滚动重启或利用 Kubernetes 的自动伸缩机制，定期重置显存状态。

另外，对于多卡并行的场景（Tensor Parallelism），块表的同步也是一大考点。RCCL 通信库在同步各卡的块表元数据时，如果块大小不一致或对齐有问题，会导致通信耗时激增。确保集群内所有节点的 vLLM 版本、启动参数（尤其是 block-size）完全一致，是避免此类隐性性能损耗的铁律。

归根结底，在 AMD GPU 上玩转 PagedAttention，是一场对显存微观结构的精细雕刻。它要求我们不再盲目信任默认值，而是深入理解 ROCm 的内存行为，通过合理的块表策略，将 HBM 的巨大带宽转化为实实在在的推理吞吐。当你看到显存利用率稳稳停在 90% 以上，且延迟曲线平滑如镜时，你就知道，这套基于分页机制的显存管理艺术，已经被你真正掌握了。

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