一、项目背景

我们的私有化推理底座在白天流量高峰扩容实例后，经常遇到首请求卡顿：新实例加载模型要几十秒，第一个用户等到超时。我们当时把这个问题定义为"冷启动吃掉首字延迟"，它是体验层面最刺眼的问题之一，却长期被吞吐指标掩盖。项目视角很明确：推理服务的体感，第一刀就在首字延迟，而不是平均每秒处理多少字。

二、落地场景

场景集中在四类。一是模型预热加载：实例起来后主动跑几条预热请求，把权重、键值缓存和编译后的算子都"焐热"。二是实例保活：对低频但重要的模型保留最小保活实例，避免彻底回收后再冷启。三是请求排队与首字优化：入口对首字延迟敏感的交互类请求做优先队列，长任务排队但先返回首字。四是延迟监控：对首字延迟、冷启动率单独打点，纳入告警而不是藏进平均值里。

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

难点一是预热本身的代价，全量预热会拖慢扩容。我们改成分层预热：核心算子预热必做，可选路径懒加载。难点二是保活的资源占用，用弹性保活策略——闲时缩到一两个实例，闲不过阈值再回收。难点三是首字优化，推理框架的连续批处理在首字阶段容易和后续字混排，我们对首字单独设路径，先吐出首个字再并入批，把体感延迟和结构效率分开处理。

案例片段（已脱敏）： 一次扩容后，新实例首字延迟从平均约一点二秒飙到约二十八秒。我们加了启动钩子，实例就绪前先自打三条预热请求，权重加载和算子编译提前完成；上线后冷启动率从约十二个百分点降到约一点五，P99首字延迟回到两点五秒以内，用户侧超时投诉基本消失。

四、效果数据

治理两个月，关键交互模型的首字延迟P99从约六秒降到约二点五秒；冷启动率从约十二个百分点降到约一点五；因首字超时被用户重试导致的无效请求下降约四成；保活实例控制在总容量的约百分之五，资源代价可控。值班同学反馈，延迟相关的工单肉眼可见地变少了。

五、可复用经验总结

预热消冷启动，保活换首字，这是推理服务的经典权衡。首字延迟必须单独监控，不能藏在平均延迟里，否则问题永远在用户嘴里而不是面板里。保活要弹性，闲时回收避免资源浪费。把首字路径和续写路径分开，是提升体感的性价比最高的一刀，值得每个推理服务都做一遍。

结语

延迟治理这件事，最怕的就是只看平均值。冷启动和首字延迟是典型的"少数人忍受、所有人嫌弃"的体验坑，把它单独拎出来打点、单独优化，往往比堆硬件来得划算。

附：规模化落地的工程取舍

我们把首字延迟治理从单模型推广到整个推理底座时，保活策略是最纠结的取舍。保活实例多了浪费显卡，少了高峰又被冷启动坑。最终我们用闲时缩容加关键模型最小保活的弹性策略，保活容量控制在总容量百分之五以内，并和网关的流量预测联动，预计高峰前提前预热。分层预热我们也做了取舍，核心算子必预热、可选路径懒加载，把扩容就绪时间压到可接受范围。

附：给同行的一些提醒

第一，首字延迟必须单独监控，藏在平均延迟里永远发现不了，用户体感全在第一字。第二，预热消冷启动、保活换首字，这是推理服务的经典权衡，别只盯着吞吐。第三，保活要弹性，闲时回收，否则显卡账单会教你做人。第四，把首字路径和续写路径分开处理，是性价比最高的一刀，几乎不增加复杂度就能显著改善体感。第五，扩容钩子里一定要先自打预热请求再放开流量，否则新实例一上来就接真实请求必超时。

附：我们踩过的几个坑

第一坑是全量预热拖垮扩容，早期实例起来先跑几十次预热，扩容时间被拉到不可接受，我们改分层预热才救回来。第二坑是保活过度，曾经为求稳保活了过多实例，显卡账单翻倍，后来用弹性策略压到百分之五以内。第三坑是首字路径混排，连续批处理把首字和后续字混在一起调度，交互类请求体感极差，单独开首字路径后才正常。这几坑说明，推理服务的体感优化没有银弹，每一刀都要在成本和体验之间反复权衡，纸上算得过来的方案上线往往要再调几轮。

附：回到工程本质

推理服务治理最深的体会是：延迟和成本永远在拉扯，没有免费的提升。预热要算算力，保活要占显卡，分层和弹性是为了把每一分资源花在用户真正能感知的地方。我们把首字延迟单列出来死磕，不是因为它难，而是因为它是用户体感的第一道门槛，值得单独投入。

另一点体会是，扩容钩子里的预热顺序比扩容本身更关键。很多团队扩容完直接放开流量，新实例一上来就接真实请求必超时，结果以为是容量不够，其实是没焐热。把这个顺序钉死，扩容相关的超时投诉能少一大半。