多模型推理网关最容易被误判成“把请求路由对就行”。⚠️ 生产高峰里问题常不是路由错误而是模型刚被选中就开始冷启动权重重新映射、图捕获重建、LoRA 重新挂载都会把首个请求拖成秒级。 用户看到同一接口底层却在频繁换模。这类问题在热门模型和长尾模型并存时尤其明显。 白天热点模型把显存吃满低频模型被反复驱逐一旦运营活动或租户切换把长尾模型重新拉热服务又得把刚赶走的权重搬回来。 如果系统只盯QPS和GPU util冷启动就会集中爆发。图 1多模型推理最危险的错不是路由不到模型而是路由到了却没有热驻留为什么多模型一上生产就开始频繁冷启动第一层根因是很多调度器只做“最近最少使用”的表面淘汰。 它能回答谁最近没被访问却回答不了“谁被赶走后最贵”。同样都是8 GB权重一个模型可能12秒就能恢复另一个却要重建KV pool、约束解码状态和批处理形状。 如果淘汰策略看不见恢复成本就会把最不该动的模型先踢出去。第二层根因是很多团队把模型驻留只当显存问题没有把它和租户隔离、LoRA 组合、量化形态绑在一起。️ 线上常见的不是“一个基础模型”被加载一次而是base model quant profile adapter set graph bucket这一整套运行形态。✅ 只记录模型名不记录形态指纹调度器就会误以为同一模型仍在内存里。图 2决定是否该驱逐的不只是最近有没有访问还包括恢复代价和运行形态一套更稳的 Model Residency 与 Eviction Budget 链路更稳的做法是把model residency做成独立状态层。 每个可服务形态都记录resident_state、warm_cost_ms、reload_bytes、tenant_share、最近命中窗口和驱逐预算调度器先判断本次请求是否值得花掉这笔预算再决定是否换模。️ 重点不是永远不驱逐而是让驱逐变成一笔可计算、可审计的成本。方案驻留判断依据冷启动率P99 首 Token典型问题只看最近访问LRU timestamp14.8%1820 ms容易把恢复代价最高的模型先赶走补访问频次LRU hit window7.1%1090 ms热门短突发仍会把长恢复模型挤掉Residency Eviction Budget再加warm_cost tenant_share shape bucket2.3%620 ms需要维护形态指纹与预算表defshould_evict(slot,incoming):reload_penaltyslot.warm_cost_msslot.graph_rebuild_ms tenant_penalty200ifslot.tenant_shareexclusiveelse0hit_penalty150ifslot.hit_window_5mincoming.hit_window_5melse0eviction_costreload_penaltytenant_penaltyhit_penaltyifeviction_costincoming.eviction_budget_ms:returnFalse,protect_residencyifslot.freeable_gbincoming.required_gb:returnTrue,evict_low_budget_slotreturnFalse,enough_capacity一组覆盖11个基础模型、37个适配器形态的回放结果很直接。 基线组只按LRU驱逐第二组补上5分钟命中窗口第三组再加入恢复耗时、租户独占权重和图桶重建成本。 冷启动率从14.8%降到7.1%最终压到2.3%P99首 Token 从1820 ms收敛到620 ms。 更关键的是误伤高价值租户的换模次数下降近一半。图 3多模型治理真正有效的指标不只是显存利用率还包括冷启动率和重载代价真正该治理的是驻留预算不是继续堆更多 GPU很多团队看到多模型冷启动第一反应是继续加卡。 加卡能缓一阵但如果驱逐逻辑仍看不见恢复代价新显存也会被短期热点迅速填满最后只是把抖动推迟到下一轮峰值。 更值得盯住的是cold_load_rate、evict_then_hit_10m、reload_p99_ms和unused_resident_gb前两者说明驱逐是否后悔后两者说明常驻是否浪费。接下来3到6个月成熟的推理平台大概率都会把“模型路由正确”升级成“模型路由后仍保持热驻留正确”。 只有当调度器既知道该把请求送给谁也知道为了接住这次请求不该驱逐谁多模型服务才真正接近可托付的生产系统。你们现在的网关优化的是选模命中率还是已经开始管理每次换模的真实代价图 4真正稳的多模型推理不是让所有模型都常驻而是让每次驱逐都值得