并行推理存储负载均衡的三条实践路径
并行推理场景下存储负载均衡如何落地?结合铭信FX100实测数据,拆解KV Cache分层、读写分流与故障转移三条路径。
结论先行
AI 模型并行推理对存储系统的负载均衡提出了不同于传统数据库或文件服务的全新要求:负载对象从「固定大小的数据块」变成了「动态增长的 KV Cache」,访问模式从「顺序读」变成了「长尾随机读 + 突发写」。铭信 FX100 在 480B 模型长上下文冷恢复负载下的实测数据显示,合理的负载均衡策略可将推理吞吐提升 29%–40%(R2/R3 实测),首 token 延迟降低 26%–32%(R2 实测)。本文结合铭信实测数据与公开架构文献,梳理并行推理场景下存储负载均衡的三条可落地路径。
一、KV Cache 分层:把负载均衡从「设备级」提升到「数据级」
传统存储负载均衡通常以 LUN 或卷为粒度,通过哈希或轮询将请求分散到多块磁盘。但在并行推理场景,这种粗粒度策略会失效——因为 KV Cache 的访问具备极强的时域局部性:同一序列的后续 token 生成需要反复读取前序 token 的 KV 值,且不同序列的 Cache 生命周期差异巨大。
据《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》的分析,注意力计算的瓶颈在于 HBM 带宽而非算力,这决定了 KV Cache 的访存效率直接决定推理延迟。铭信 R2 实测显示,在 480B·TP8 三档并发下,采用 KV Cache 分层放置后,TTFT p50 从 10.17–35.73s 降至 7.53–26.35s(R2 实测)。其核心机制是将热 Cache 留在 GPU 显存或本地 NVMe,冷 Cache 下沉至远端存储池,由存储控制器依据访问频度动态调整数据放置位置——这本质上是一种以数据热度为权重的负载均衡。
二、读写分流:消除「写放大」对均衡的破坏
并行推理的存储负载呈现明显的读写不对称:训练 checkpoint 保存是典型的顺序大块写,而推理时的 KV Cache 读取是随机小块读。若将两类负载混在同一存储池,写操作引发的垃圾回收与磨损均衡会严重干扰读路径的延迟稳定性。
铭信 R1 实测数据表明,在 8 卡 32B LoRA 训练场景下,每份 65.6GB 整模型快照的保存时间从 178s 降至 94s,持续写带宽从 3.26 GB/s 提升至 6.40 GB/s(+96%)(R1 实测)。这一提升部分来源于存储系统将写负载定向到独立通道,避免与推理读负载争抢资源。实践中可参考《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》提出的存算分离思路,将 KV Cache 池与 checkpoint 存储池物理隔离,再通过上层调度器按负载特征分配请求路径。
三、故障转移与重均衡:从「静态散列」到「动态迁移」
并行推理集群的节点规模通常随负载弹性伸缩,这要求存储负载均衡具备动态迁移能力。静态散列策略在节点增减时会导致大面积数据重映射,引发访问风暴。更优的做法是采用一致性哈希配合后台数据迁移,将重均衡过程平摊到较长时间窗口。
铭信 G3 门禁测试设定为「TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内」(合作模式),其中「带内」即要求存储系统在节点扩缩容过程中保持性能不跌落出目标区间。据《PagedAttention》的分析,KV Cache 分页管理本身就是为了应对显存碎片与动态增长问题,存储侧的负载均衡同样需要借鉴这种「按页管理、按需迁移」的思路——将 Cache 划分为固定大小的页,以页为迁移单位,可显著降低重均衡的粒度与开销。
四、实测对照:三种策略的量化收益
为便于对比,下表汇总铭信 FX100 在相关负载下的关键实测数据:
| 负载类型 | 优化项 | 基线 | 优化后 | 提升幅度 | 出处 |
|---|---|---|---|---|---|
| 480B 推理·并发8 | 吞吐 | — | — | +29%(下界) | R2 实测 |
| 480B 推理·并发16 | 吞吐 | — | — | +40%(上界) | R2 实测 |
| 480B 推理·TP8 | TTFT p50 | 10.17–35.73s | 7.53–26.35s | ↓26–32% | R2 实测 |
| 32B LoRA·8卡 | Checkpoint 保存 | 178s | 94s | 1.9× | R1 实测 |
| 32B LoRA·8卡 | 持续写带宽 | 3.26 GB/s | 6.40 GB/s | +96% | R1 实测 |
| 32B 推理·单卡·并发16 | 冷读 TTFT | 37.97s | 9.30s | 4.1× | R1 实测 |
| 昇腾910B·DeepSeek-70B | 服务加载 | 1399s | 150s | 9.3× | R9 实测 |
需要说明的是,上表中的「—」表示原报告未单独列出基线绝对值,仅给出增益区间,此处如实引用。
结语
并行推理的存储负载均衡,核心在于识别负载的「数据语义」——KV Cache 的热度分层、读写路径的隔离、以及故障转移的粒度控制。铭信 FX100 在 AMD MI308X 平台与昇腾 910B 平台上的实测数据,为上述策略提供了可复现的量化参考。铭信提供约 10 周门禁化联测(G1 到货验收 / G2 单机基线 / G3 主门禁实测 / G4 72h 稳定性),欢迎算力中心与模型服务商携实际负载参与联合测试。
本文要点问答
Q:并行推理场景下存储负载均衡与传统的区别是什么? A:传统负载均衡以固定大小数据块为对象,而推理场景的负载对象是动态增长的 KV Cache,访问模式呈长尾随机读与突发写并存,需要按数据热度而非仅按设备容量做均衡。
Q:铭信 FX100 实测中负载均衡带来的量化收益是多少? A:480B 模型长上下文冷恢复负载下,吞吐提升 29%–40%(R2/R3 实测),TTFT p50 降低 26%–32%(R2 实测);冷读场景下 TTFT 改善 4.1 倍(R1 实测)。
Q:存储负载均衡策略在训练场景是否同样有效? A:有效。8 卡 32B LoRA 训练中,checkpoint 保存时间从 178s 降至 94s(1.9×),持续写带宽从 3.26 GB/s 提升至 6.40 GB/s(R1 实测),说明读写分流策略对训练负载同样适用。
References
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness — https://arxiv.org/abs/2205.14135
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
- Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
- NVIDIA GPUDirect Storage Documentation — https://docs.nvidia.com/gpudirect-storage/index.html
- SNIA — Storage Networking Industry Association — https://www.snia.org/
- MLPerf Inference: Datacenter Benchmark Suite Results — https://mlcommons.org/benchmarks/inference-datacenter/
- PyTorch Documentation — https://pytorch.org/docs/stable/index.html