模型加载时的显存“黑洞”：权重与碎片的博弈

在 AMD Instinct GPU 上跑大模型，最让人头疼的往往不是推理速度慢，而是服务刚启动就报 OOM（显存溢出）。很多开发者在 ROCm 7.x 环境下部署 vLLM 时，明明计算过模型权重只需要 40GB 显存，而显卡有 80GB，结果一加载就崩溃。这背后的罪魁祸首通常是两个：对权重加载机制的误解，以及被忽视的显存碎片化问题。

当我们执行 vllm serve 命令时，系统并非简单地把模型文件读进显存就完事了。vLLM 采用了 PagedAttention 技术，将显存划分为一个个固定的块（Block）来管理 KV Cache。但在模型初始化阶段，权重的加载是连续且巨大的。如果此时没有预留足够的缓冲空间，或者显存中已经存在大量细碎的不可用空洞，哪怕总剩余显存足够，也无法容纳连续的权重数据块。这就好比停车场虽然还有空位，但都是分散的“摩托车位”，停不进一辆完整的“大巴车”。

深入理解 block_size：细粒度与开销的权衡

显存碎片化的核心在于内存块的管理策略，而在 vLLM 中，--block-size 参数就是控制这一策略的钥匙。这个参数决定了 PagedAttention 分配显存的最小单元大小，默认值通常是 16。

对于处理超大参数模型或长上下文场景，block_size 的设置直接影响显存的细粒度利用率。

• 较小的 block_size（如 8 或 16）：适合输入序列长度变化剧烈的场景。它能更精细地贴合实际需要的显存量，减少因“大材小用”造成的内部碎片。比如一个请求只需要少量显存，小块分配能避免浪费。但在高并发下，过多的块会增加页表管理的元数据开销，略微拖慢地址映射速度。
• 较大的 block_size（如 32 或 64）：适合序列长度相对固定且较长的业务。它能显著减少块的数量，降低管理开销，提升吞吐量。但如果业务中存在大量短文本请求，大块分配会导致每个请求都浪费掉块内未使用的空间，造成严重的外部碎片积累。

在实际的 ROCm 7.x 环境中，针对 Instinct MI250 或 MI300 系列，我建议先保持默认的 16 进行基准测试。如果发现显存使用率长期维持在低位但无法接纳新请求（典型的碎片化特征），可以尝试调整为 32。反之，如果日志中频繁出现因显存不足拒绝请求，而监控显示总显存尚有剩余，则应尝试减小 block_size 至 8，以榨取每一字节的可用空间。

# 示例：针对长文本场景优化 block_size 为 32
python -m vllm.entrypoints.api_server \
    --model meta-llama/Meta-Llama-3-70B-Instruct \
    --block-size 32 \
    --gpu-memory-utilization 0.90 \
    --port 8000

预留安全边界：gpu-memory-utilization 的实战配置

另一个导致加载失败的经典原因是“贪心”。vLLM 提供了 --gpu-memory-utilization 参数，允许用户指定框架可占用的显存比例。很多人为了追求极致的并发量，习惯将其设置为 0.95 甚至 0.98，这在理论计算上是完美的，但在工程实践中极其危险。

ROCm 驱动本身、操作系统内核的图形栈、以及瞬间爆发的峰值流量都需要额外的显存缓冲。特别是在模型加载的瞬间，权重数据写入显存是一个高频操作，若此时显存已被预分配殆尽，极易触发 OOM。此外，ROCm 在某些算子执行时会申请临时的 Scratch Space，这部分空间如果不预留，也会直接导致进程崩溃。

在我的生产环境中，无论显存多大，我都会将 --gpu-memory-utilization 锁定在 0.90 到 0.92 之间。这看似浪费了 8%-10% 的宝贵资源，实则是为系统的稳定性购买了保险。这部分的预留空间能够吸收瞬时流量尖峰带来的显存波动，也能确保驱动层有足够的余地进行内存调度。对于 70B 以上的大模型，这 10% 的余量往往是服务能否成功启动的关键。

# 推荐配置：预留 10% 显存作为安全缓冲
python -m vllm.entrypoints.api_server \
    --model Qwen/Qwen2-72B-Instruct \
    --gpu-memory-utilization 0.90 \
    --tensor-parallel-size 4 \
    --host 0.0.0.0 \
    --port 8000

运维习惯：定期清理与实例生命周期管理

解决了配置问题，还需要建立良好的运维习惯。在开发调试阶段，我们经常会启动多个不同参数的测试实例。如果仅仅通过 Ctrl+C 终止前台进程，有时后台仍会残留僵尸进程占用显存不释放。久而久之，显存中就会充斥著各种无法被回收的“幽灵”占用，导致新的模型无法加载。

在 ROCm 环境下，我习惯在每次启动新服务前，执行一次彻底的清理检查。除了常规的 ps -ef | grep vllm 杀进程外，更要利用 rocm-smi 确认显存是否真正归零。如果发现显存未释放且找不到对应进程，可能需要重启相关用户会话甚至重置 GPU 状态。

对于长期运行的生产服务，建议编写简单的守护脚本，定期检查显存碎片率。如果发现随着运行时间推移，可用显存块逐渐变小且无法合并，说明碎片化已影响性能，此时安排一次平滑重启（Rolling Restart）是比硬撑更明智的选择。保持环境的“洁净度”，与优化算法参数同样重要，这是保证 AMD 大模型推理服务长期稳定运行的隐形基石。