一、项目背景

我们给一家集团客户建私有化大模型底座，GPU 集群给内部多个部门共用。上线头两个月，投诉就没停过。算法团队跑训练顺手就把推理卡也占了，业务线的问答服务排到后面，高峰期用户问一句等半分钟。资源利用率看板倒是漂亮，百分之九十以上，但每个用的人都在骂，因为没人愿意把任务让出来，根本没有配额和优先级的概念。

更尴尬的是，业务线的人觉得被算法团队挤了，算法团队说我在赶里程碑。谁也不退，运维夹在中间天天拉群协调。我们进场时，他们正为一次大促前的算力争抢开了一下午会，没结论。说到底，多租户推理最怕的就是先到先得、占满为止，得有规矩。

二、落地场景

方案从配额和调度两层做。租户级 GPU 配额：给每个部门划保底算力和弹性上限，保底不被挤，弹性可借。请求队列与优先级：同一租户内的请求按业务优先级排队，高优先的先跑。抢占与弹性借用：空闲租户的算力允许被急需方临时借用，忙时优先还给主人。利用率与欠载告警：集群整体和单租户都看利用率，长期欠载的提醒回收。

三、关键技术挑战与解决思路

配额建模比预想复杂。简单按卡数切，部门大小不同，小部门分多了浪费，大部门不够用。我们按保底加弹性切，保底是硬隔离，弹性是共享池，谁空闲谁借用。难点在借用回收，硬抢占会把别人跑了一半的长任务掐断重算，浪费算力也惹众怒。我们改成借而不抢：借出的算力等当前任务跑完才回收，宁可晚一点还，也不打断别人。

请求级排队也得讲公平。同一部门里，不能让一个批量任务把交互式问答全堵了。我们给请求打优先级，交互式高、批量低，但批量任务也不能饿死，设了最长等待时间，超时强制插队。我们早期只按优先级，结果批量任务排两小时没动，业务线提意见，加了等待上限才平衡。

利用率和公平其实能兼顾，关键是别让共享池闲置。我们做了欠载告警，长期占着不用又不释放的租户，提示回收弹性部分，把算力腾给真的在等的。这一步让整体利用率没掉，大家等待时长却下来了。

借用对计费账单的影响也得理顺。弹性借用的算力，用谁的出钱？我们按实际使用给借入方记账，借出方当期账单扣减，月底对账清晰，不会出现借了不用还钱的情况。早期那版没做借用计费，借出的算力白给，部门没动力释放，共享池名存实亡，加了计量后才真正流动起来。还有个小坑，GPU 碎片问题，借来借去容易出现半卡闲置，我们做了碎片整理提示，长期占半卡的提醒合并，整体利用率又能提一两个点。说实话，多租户最难的不是技术调度，是让各部门接受配额这件事，我们花了不少时间和他们算账，证明弹性借用比各自独占更划算。

公平性不能只靠感觉，我们做了租户等待时长的分位监控，看 p50 和 p99，而不是平均。平均好看但长尾可能被掩盖，某个小租户偶尔排十分钟，平均一拉就看不见。加了分位后，我们专门盯 p99 高的租户，针对性调它的弹性借用权限。早期只看平均等待，结果小部门偶尔被大任务卡很久没人发现，分位监控补上了这个盲区。说实话，多租户系统里小角色的体验最容易被平均数字藏起来，监控得往长尾看。

四、效果数据

队列平均等待时长从高峰期的二十多秒降到约五秒，GPU 整体利用率保持在八成以上没掉，但租户间争抢基本消失。抢占发生次数从每天几十次降到个位数，且都是温和的借而不抢。租户满意度调研里，算力抢不到的投诉归零。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

多租户推理不能靠自觉，配额加排队优先级是底线，空闲时弹性借用、忙时回收，利用率和公平能兼得。借用一定要借而不抢，等任务跑完再还，硬抢占看似快其实浪费更狠，我们第一版硬抢占把长任务打断重算，算力反而更紧张。批量任务设最长等待上限，别让低优先的饿死。说实话，配额初始值挺难定，我们靠两周使用数据反推才合理，定高了浪费定低了不够，这块建议上线后持续调。利用率看板得拆到租户级，只看全局会把某个部门的饿死藏起来。

案例片段（已脱敏）： 租户配额与排队优先级节选（配置节选）： 某算法团队占满四卡跑长任务，业务线问答高峰被挤。系统将其弹性部分借给业务线，等算法任务跑完自动回收，全程未打断算法任务。业务线等待从十八秒降到四秒，算法团队事后看监控才发现算力被借过，毫无感知。

tenant:
  guaranteed: 2_gpu
  elastic_cap: 4_gpu
  borrowable: true
queue:
  priority: {interactive: 9, batch: 3}
  max_wait: 120s
reclaim:
  policy: borrow_not_preempt
  return_when: task_done

案例片段（已脱敏）： 一次把某小部门保底设成四卡，结果该部门长期只用到一点五卡，共享池被压住，大部门高峰借不到。欠载告警触发后回收其弹性部分两卡，释放进共享池。这事让我们把保底定得偏紧，弹性放开，宁可借也不白占，保底定宽了是另一种浪费。