多租户GPU这一年踩过的坑周一早上九点告警群里第一条消息不是晨会通知是“显存爆了”。我们那台被三个业务共同盯上的卡占用率直接顶到百分之百监控曲线拉成一条直线。A 业务说昨晚只发了点测试流量B 业务说模型就 7B加载完也就十几个 GC 业务说别看我我早上刚重启过。三拨人在群里吵了半个多小时最后矛头齐刷刷指向运维你们当初怎么不买显存大的卡这种场面我估计不少人眼熟。公司要省成本GPU 不可能一人一张一张卡上挤两三个业务是常态。尤其做模型推理的模型不大单业务占不满整卡共享几乎是唯一选择。但共享这件事方案书里写得天花乱坠落地之后完全是另一种剧本。先说这一年多租户 GPU 共享到底有什么进展。vGPU 基于 SR-IOV 在固件层把一张卡切成多个虚拟功能每个虚拟功能有独立显存、独立计算单元、独立 DMA 通道理论上是硬隔离谁也别想吃到谁的。MIG 更彻底A100、H100 这类卡能在硬件上切成最多七个实例显存、带宽、二级缓存都各归各。不想上硬件方案的还有时间片切分、MPS、容器级隔离甚至有人用拦截 CUDA 调用的办法做软限制。还有人在打权重共享的主意同一份模型权重驻留显存多个租户复用同一份副本显存是省了权限和计费又成了新账。看起来条条大路通罗马。实际落地呢显存隔离不等于性能隔离这是第一个坑。显存给你切了二十个 G算力还是共享的邻居一跑训练你的推理延迟照涨不误。切分粒度也由硬件说了算MIG 的实例规格是固定的不是你想切几 G 就切几 G。vGPU 要企业授权要特定驱动要虚拟化平台配合光环境就够折腾一星期。更别提很多团队连驱动版本都不敢乱动一升级隔壁业务的推理延迟先给你表演一个断崖。方案能跑通演示和方案能扛住生产中间隔着一条河。真正让人崩溃的时刻我随便数几个。第一个业务 A 的显存泄漏。推理服务挂着跑显存占用像楼梯一样只上不下每天涨两三个 G。PyTorch 的缓存分配器本来就不爱把内存还给系统代码里再有个张量引用没释放就是个无底洞。nvidia-smi 里已用一路爬升剩余趋近于零同卡的其他业务跟着遭殃。查到最后是推理循环里一个列表没清就这一行代码的事把整卡拖死了一周。第二个权重加载到一半显存不够。模型是分层加载的加载到第二十层的时候 OOM前面十九层全白干进程直接退出。更要命的是显存碎片化——显示还剩十个 G但都是零碎的空洞凑不出一块连续的大内存任务就是起不来。这比单纯不够用还难查监控上根本看不出异常。第三个时间片切换的开销。多个业务时间片轮转共用一张卡GPU 上下文切换不是免费的。平时八十毫秒的接口邻居一跑大任务直接飙到一秒往上p99 一路击穿。你这边负载明明不高锅全让隔壁背了但隔壁也委屈人家也交了钱的。后来我们把关键业务挪到独立卡上才消停。第四个SLA 不达标。说好的服务质量保障在共享环境里基本靠自觉租户之间抢算力抢带宽商务那边天天被客户怼天天来问运维这共享到底行不行。行不行我们心里也没底。当然也有让人又气又笑的时刻。比如上了资源隔离之后利用率反而降了。原来一张卡挤三个业务利用率百分之八十看着心慌切完之后每个虚拟卡都闲着一大半加起来不到百分之五十。稳定性保住了钱包开始疼老板开始问这卡是不是白买了。再比如查了一整天延迟问题最后发现是隔壁业务把 batch_size 从 1 改成了 8人家的理由是“反正卡上还有显存”。还有一次监控面板上三个租户全绿线上用户却在排队。因为监控看的是平均利用率平均是绿的峰值全撞在同一秒。那怎么让多租户分配不再扯皮这一年踩下来我的体会就几条。第一先把业务分清楚。在线推理要稳定延迟离线训练要长时间吞吐开发调试能容忍波动。三类负载不该用同一种切分策略让用户自己选而不是一刀切。第二显存配额必须是硬限制。能上 MIG 就上 MIG硬件隔离最省心不支持硬切分的卡用进程级显存上限或者容器配额兜底。配额写进资源申请流程靠自觉这件事我是不信了。第三上线前做隔离验收。并发压测记录延迟抖动、邻居影响写成可复查的测试记录。样例能跑通不算数真实负载、真实输入才算数。第四监控得能解释“为什么慢”。显存占用、算力占用、任务排队、邻居任务、容器重启这些指标要能关联起来。只看平均利用率问题永远藏在水面下。第五留冗余。利用率别奔着百分之百去百分之七八十是合理区间得给碎片和峰值留空间。第六该整卡就整卡。关键业务、对延迟敏感的业务别省那一张卡的钱共享省下来的钱不够赔一次事故的。多租户共享这事本质是拿稳定性换成本。方案没有对错只有合不合适。把期望管理好把配额定死把监控做细这日子还是能过的。本文基于公开技术资料与行业实践整理不构成具体产品选型或部署方案建议。