告别“木桶效应”：多卡部署中的进程绑核实战

在单卡上跑通 vLLM 只是入门，真正的挑战往往始于业务流量上涨、模型参数量激增的那一刻。当我们把目光投向多卡集群，试图通过张量并行（Tensor Parallelism, TP）来突破显存墙时，很多团队会遭遇一个尴尬局面：卡数加了，吞吐量却没按比例涨，甚至因为通信开销过大导致性能不升反降。这通常不是硬件算力不够，而是忽略了底层拓扑与进程调度的细节。

多卡并行本质上是多进程协作，而 CPU 资源的争抢往往是隐形的性能杀手。如果多个 GPU 对应的 vLLM worker 进程被操作系统随机调度到同一个 CPU 核心上，频繁的上下文切换会直接拖慢推理速度，尤其是在高并发场景下，这种延迟抖动尤为明显。解决这个问题的关键在于进程绑核（CPU Affinity）。

在 AMD Instinct 平台（如 MI300X）上，CPU 通常分为多个 NUMA（非统一内存访问）节点。理想的做法是让每个 GPU 进程只访问其所在 NUMA 节点的本地内存和核心，避免跨 Socket 通信带来的额外延迟。我们可以利用 numactl 工具来实现这一目标。

假设我们在一台双路服务器上部署八卡环境，前四张卡属于 NUMA 节点 0，后四张卡属于 NUMA 节点 1。启动服务时，不要直接运行 vllm serve，而是包裹一层 numactl 命令：

# 示例：将前四个进程绑定到 NUMA 节点 0
numactl --cpunodebind=0 --membind=0 vllm serve /models/Llama-3-70B \
    --tensor-parallel-size 8 \
    --device cuda:0 ...

# 对于多卡自动管理，通常结合启动脚本或 Kubernetes DevicePlugin 配置
# 确保每个 worker 进程感知其 LOCAL_RANK 并绑定对应 NUMA

在实际操作中，更推荐编写一个简单的 Shell 包装脚本，根据环境变量 LOCAL_RANK 动态计算应绑定的 NUMA 节点。例如，若每张卡独占一个核心组，可以将 rank 0-3 绑定到节点 0，rank 4-7 绑定到节点 1。这样能确保数据在本地内存访问，大幅减少跨核延迟，让 RCCL（ROCm Communication Collectives Library）的集合通信效率达到最优。

显存碎片化治理：PagedAttention 参数调优

解决了 CPU 侧的调度问题，GPU 侧的显存管理同样至关重要。在多卡环境下，除了模型权重的切分，每张卡还需要维护一部分 KV Cache。如果显存碎片化严重，即使总剩余显存足够，也可能因为无法分配连续的内存块而导致 OOM（内存溢出）或性能剧烈抖动。

vLLM 的核心优势在于其 PagedAttention 机制，它将 KV Cache 划分为非连续的块（Block），极大地缓解了碎片化问题。但在多卡生产环境中，默认的块大小和显存预留比例可能并非最优解，需要根据实际负载进行微调。

首先是 --block-size 参数。较小的 block size（如 16）能提高细粒度利用率，适合输入输出长度变化剧烈、变长序列明显的场景；而较大的 block size（如 32 或 64）则能减少页表管理开销，适合定长或长上下文场景。在 Instinct MI300X 这种大显存卡上，如果主要处理长文档推理，适当增大 block size 往往能带来更稳定的吞吐表现。

其次是 --gpu-memory-utilization 参数，这是防止 OOM 的最后一道防线。很多开发者习惯将其设置为 0.95 甚至更高，试图榨干每一字节显存。但在多卡并行中，这种做法风险极大。RCCL 在进行卡间同步时需要额外的通信缓冲区，系统内核也需要少量显存资源。建议将该值控制在 0.90 到 0.92 之间。留出这几 percent 的余量，是为了给瞬时峰值和通信缓冲预留空间，防止因某一张卡的微小波动导致整个推理链路崩溃。

vllm serve /models/Llama-3-70B \
    --tensor-parallel-size 8 \
    --block-size 16 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 32768

通过上述调整，我们不仅能避免“木桶效应”中那块最短的板（显存不足的卡）拖累整体，还能让 PagedAttention 的内存分配策略更加平滑，确保持续批处理（Continuous Batching）高效运行。

构建生产级监控：从指标采集到稳定性保障

集群上线后的可观测性是稳定运行的基石。在多卡高负载运行时，任何一张卡的异常都可能引发连锁反应。仅仅依靠日志查看是不够的，我们需要建立实时的监控体系。

建议部署 Prometheus + Grafana 监控栈，重点采集以下几类核心指标：

• GPU 显存利用率：监控是否长期处于 95% 以上的高位。如果某张卡持续满载而其他卡空闲，说明负载均衡出了问题。
• RCCL 通信耗时：观察卡间同步是否存在异常延迟尖峰。正常的通信耗时应该非常低且平稳，一旦出现毛刺，往往意味着拓扑配置错误或网络拥塞。
• 温度与功耗：确保散热系统能应对全负载运行，防止因过热降频导致推理延迟飙升。
• 各卡负载均衡度：确认所有 GPU 的利用率是否一致。在张量并行模式下，所有卡的计算强度理论上应完全同步，若出现偏差，需检查进程绑核是否生效。

以下是一个简单的 Prometheus 配置思路，用于抓取 vLLM 暴露的指标：

scrape_configs:
  - job_name: 'vllm-cluster'
    static_configs:
      - targets: ['node1:8000', 'node2:8000'] # vLLM 默认暴露 metrics 端口
    metrics_path: '/metrics'

在 Grafana 面板中，可以绘制各卡显存使用率的叠加图。如果发现某条曲线突然断裂或异常升高，就能立即定位到具体故障节点。此外，还可以设置报警规则，当通信延迟超过阈值或显存利用率连续 5 分钟高于 92% 时触发通知，以便运维人员及时介入。

从单卡验证到多卡集群，不仅仅是数量的堆叠，更是对软硬件协同能力的深度考验。只有理顺了拓扑、绑核、通信和显存管理这些细节，配合完善的监控手段，才能真正释放 Instinct GPU 集群的澎湃算力，让大模型推理服务既快又稳。

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