一、项目背景

我们底座里模型越堆越多，到去年底有二十多个推理服务常驻，显存报表一看触目惊心：一半以上的卡在给每天调用几百次的模型空转，真正高频的几个模型反而因为资源紧被限流。扩容大家抢着做，缩容没人敢碰，怕一缩就影响线上。结果就是资源利用率长期难看，财务那边每个季度都来问"这些卡到底在跑什么"。我们意识到，常驻不等于必须常驻，很多低频模型根本不需要二十四小时占着显存。

二、落地场景

我们落地的核心是"按频度画像做自动缩容，按评审流程做安全下线"。第一块是调用频度画像，按天、周、月三个维度统计每个模型的调用量、峰值时段、调用方分布，把模型分成常驻、弹性、低频三类。第二块是低频模型自动缩容，弹性类在闲时缩到最小副本甚至零副本，高峰前定时预热拉起。第三块是空闲回收，零副本模型如果连续一段时间无调用，释放其占用的显存和端口。第四块是下线评审，确认要下线的模型走评审，把调用方流量先迁到替代模型或统一网关兜底，再真正停服。第五块是下线后的回滚通道保留一段时间，出问题能快速拉回。

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

频度画像最容易误判的是"有周期性的低频模型"。我们有个模型平时一天几十次，但每月初大批量报表要用，按日频度看它是低频，按周看它月初爆量。第一版自动缩容把它闲时缩到零，月初报表季打过来冷启动排队，业务方投诉。后来画像加了"周期峰值"维度，识别到月初规律的爆量后，把它的缩容窗口避开月初那几天，并提前预热，误伤消失。冷启动预热原来只在缩容拉起时做，我们发现零副本模型被第一次请求触发拉起时，预热和首请求 competing，首响极慢。改成"定时预热加保持最小热副本"后，首响从十几秒降到两秒内。

下线那次事故记忆犹新：我们急着清理一个"看起来没人用"的模型，没查清楚有个老调用方还指着他，直接停服，半夜告警说某内部工具报 503，我们花了四十分钟才定位到是被下线的模型，回滚拉起才恢复。之后下线流程硬性要求"流量迁移校验"，停服前必须确认近一周调用量为零且调用方清单为空，否则不能走下线，零事故才保住。

四、效果数据

频度画像运行后，常驻显存占用整体下降约四成，其中弹性类模型闲时缩容贡献了约七成的释放量。空闲回收机制让零副本模型的端口和显存占用归零，回收率约九成五。冷启动耗时从最早的无预热十几秒降到约一点八秒。下线评审流程上线后，共安全下线六个模型，未再发生误下线导致的线上 503。资源报表里"高频模型被限流"的工单，同比下降约八成，说明腾出来的资源确实补到了该用的地方。

案例片段（已脱敏）： 频度画像输出某模型标签：低频但有月初周期峰值（每月 1 至 3 日调用量约为日均 40 倍）。缩容策略配置：非月初时段 min_replicas=0，每月 28 日起提前预热并保持 min_replicas=1 至 5 日。监控记录：某月 1 日 09:00 突发调用 1200 次，因已预热，P99 首响 1.9s，未触发冷启动排队；该月其余时段零副本，显存释放约 22GB。

资源报表改造是这件事能立项的关键。我们一开始拿"显存利用率低"去跟财务讲，财务听不懂也不关心，后来我们把报表换成"这些常驻卡如果释放，相当于每季度省下可观的闲置算力开销"，财务立刻拍板支持。技术落地上，弹性模型的预热时机我们调了几次，最初按固定时刻预热，结果业务方实际高峰比预设早，还是冷启动排队，后来改成"按历史调用曲线预测提前十五分钟预热"，预热和实际高峰基本咬合。下线评审流程我们做成了表单，调用方清单、近一周流量、替代模型三栏必填，审批人点确认才真停服，流程虽重但把误下线概率压到零，运维也才敢放手做自动缩容。说到底，缩容可以交给系统，下线必须有人拍板，这个边界划清楚，夜里才睡得安稳。缩容和下线之间的这道防火墙，是整个资源治理敢持续推进的底气。

五、可复用经验总结

低频模型不该常驻，这是资源治理里最容易被忽略的一块，很多团队扩得豪气缩得胆小，最后卡全在空转上。但缩容和下线是两件事，缩容可以激进，下线必须保守，我们误下线那次就是没把"保守"做成硬流程，之后加的流量迁移校验等于给下线上了保险。周期峰值这个维度我后来觉得比平均频度重要，平均会掩盖规律爆量，画像里不加它迟早误伤。我们当时在"到底要不要直接上自动下线"上纠结过，结论是自动缩容可以全自动，自动下线必须有人确认，这个边界划清楚，运维夜里才能睡安稳。