问题
推理集群需要频繁切换模型,GPU 有效利用率很低,怎么提高?
结论
先缩短模型加载时间。每次切换模型,GPU 都要等权重从存储读进显存,这段时间不产出任何 token。按实测加载时间建模,在每小时切换 20 次的档位下,接入 FX100 后算力有效利用率从 46.7% 提高到 62.8%R1。
利用率丢在哪里
多模型共用一批卡的平台,模型会按需换入换出。换入一个模型要把几十到几百 GB 的权重读进显存,这段时间里卡是通电的,却没有在服务请求。
切换越频繁,这部分等待在一小时里占的比例越高。监控里看到的「GPU 占用」可能不低,但真正用于推理的时间被加载吃掉了。
实测数据
以下数据来自 8 × AMD MI308X 平台上的综合测试,测试模型为 Qwen2.5-32B 与 7B。
- 模型切换:每小时切换 20 次时,算力有效利用率 46.7% → 62.8%R1。
- 并发加载:8 张卡同时冷读模型,整体墙钟时间快 16%,单个模型加载快 30%R1。
- 训练 Checkpoint:每份 65.6 GB 的整模型快照,保存耗时 178 s → 94 s,持续写带宽 3.26 → 6.40 GB/sR1。
这个利用率数字是怎么来的
62.8% 不是在生产流量下直接测出来的利用率,而是用实测的加载时间建模得到的:给定每小时切换次数和每次加载耗时,算出一小时里有多少时间真正可用于推理R1。
这意味着你可以代入自己的数字重算。切换次数比 20 次少,收益会小;模型更大、加载更久,收益会大。
怎么判断值不值得做
先数两个数:每张卡每小时切换多少次模型,每次切换从发起到能服务要多久。两者相乘就是每小时损失的时间。
如果你的模型是常驻的,几乎不切换,那么这项优化对你没有意义,应该把注意力放在 KV Cache 和首 token 延迟上。
相关实测报告
外部参考资料
- 01
- 02
延伸阅读
NFS 加载大模型太慢?昇腾 910B 平台实测对比
在华为昇腾 910B × 8 的平台上,把模型存储从 NFS 换成 FX100 全闪阵列后,DeepSeek-32B 与 70B 的服务加载时间实测对比,以及这组数字的适用范围。
出处R1R9
不加 GPU,怎么降低大模型推理的首 token 延迟?
长上下文场景里,首 token 延迟高往往是因为被逐出显存的会话在整段重算。本文给出三个不加卡的办法,以及 480B 模型在三档并发下的实测降幅。
出处R1R2R3
推理存储加速项目怎么验收?四道门禁的做法
把推理存储加速的验收拆成四道按周推进的门禁:到货验收、单机基线、联测主门禁、稳定性验收。每道都有可测量的通过条件,不达标就停。
出处R1R2R3R8