量化策略：用精度换空间的实战选择

当面对“显存溢出（OOM）”的报错时，最直接的解决方案往往是降低模型权重的精度。在 ROCm 7.x 环境下，AMD Instinct GPU 对低精度算子的支持已经相当成熟，尤其是 FP8 格式，成为了平衡性能与显存占用的首选方案。

对于大多数主流大模型（如 Llama 3 系列），开启 FP8 量化通常只需在启动命令中增加 --quantization fp8 参数。这一操作能将模型权重的显存占用直接减半。例如，一个原本需要 16GB 显存的 BF16 模型，在 FP8 模式下仅需约 8GB。省下来的显存空间可以全部划拨给 KV Cache，从而显著提升并发处理能力。在 MI300X 这类高带宽显卡上，FP8 不仅节省了空间，还能利用其专用的矩阵核心加速计算，实测吞吐量往往能提升 30% 以上，且 perplexity（困惑度）的变化微乎其微，几乎不影响生成质量。

如果模型不支持原生 FP8，或者你的业务场景对精度极其敏感，INT8 量化是另一个备选方案。虽然 INT8 能进一步压缩体积，但在 ROCm 生态中，INT8 可能需要额外的校准步骤（Calibration）来生成缩放因子，且部分算子可能无法完全加速，存在回退到高精度计算的风险。因此，除非显存瓶颈极度严重，否则在 ROCm 7.x 平台上优先推荐尝试 FP8。务必注意，量化后的模型加载速度会更快，但首次推理时的内核编译开销可能会略有增加，这是正常的预热过程。

激活值重计算：以时间换空间的经典权衡

除了压缩权重，推理过程中的另一大显存消耗来自“激活值”（Activations）。在长序列生成或大 Batch Size 场景下，中间层的激活值累积往往比模型权重本身更吃显存。这时候，“激活值重计算”（Activation Recomputation，也称 Gradient Checkpointing 的推理版）就是一记救场妙招。

这项技术的原理很简单：在正向传播过程中，不保存所有中间层的激活值，只保存关键节点的快照。当后续计算需要用到被丢弃的激活值时，系统会利用保存的快照重新计算一遍。这显然增加了计算量，但换来的是显存占用的大幅线性下降。在 vLLM 中，这通常通过启用特定的配置标志或在模型加载时设置 --enable-chunked-prefill 结合重计算策略来实现（具体参数视 vLLM 版本迭代可能有所调整，需查阅对应版本文档）。

在显存捉襟见肘时，开启重计算能让原本因 OOM 无法运行的超大上下文任务顺利执行。代价是推理延迟会有所上升，因为 GPU 需要做额外的计算工作。但在 Instinct GPU 上，由于其强大的算力储备，这种“以时间换空间”的策略往往非常划算：显存从瓶颈变为充裕，而增加的计算时间在整体延迟中占比可控。建议在进行长文档摘要或复杂逻辑推理任务时，优先评估此选项，它能让单卡承载的序列长度翻倍。

Block Size 调优：精细化管理显存碎片

vLLM 的核心优势在于 PagedAttention 技术，它将 KV Cache 的管理变成了类似操作系统内存分页的模式。其中，--block-size 参数决定了每个内存块能容纳的 Token 数量。这个参数的设置看似微小，实则对显存利用率和碎片率有着深远影响。

默认情况下，vLLM 可能会根据硬件特性选择一个保守值（如 16 或 32）。如果你的业务场景中，用户输入的序列长度分布较为均匀且较长，适当增大 block size（例如设为 64 或 128）可以减少页表管理的开销，提高显存访问的局部性，从而略微提升吞吐。反之，如果业务多为短文本交互，或者序列长度差异极大（长尾分布），较小的 block size（如 8 或 16）则更为合适。小颗粒度的分块能更精细地贴合实际需求，避免分配了大块内存却只用了一小部分造成的浪费。

在 ROCm 平台上调试此参数时，建议结合 --gpu-memory-utilization 一起观察。先将显存利用率设定在 0.9 左右，预留缓冲，然后逐步调整 block size 并进行压力测试。观察指标不仅是吞吐量，更要关注显存碎片率和服务的稳定性。有时候，一个更符合业务数据特征的 block size 设置，能在不增加任何硬件成本的前提下，让单卡的并发承载能力再上一个台阶。记住，没有通用的最佳值，只有最适合你业务流量模型的配置。

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