在 AI 生产力持续攀升的背景下，一个看似矛盾的现象正困扰着大规模 LLM 推理服务的运维团队：当模型以接近满负荷的状态持续运转时，输出质量的隐性衰减往往被高吞吐的表象所掩盖。与训练阶段广为人知的学习率冷却（learning rate cooldown）不同，推理阶段的 "模型冷却"（inference cooldown）尚未获得同等程度的关注 —— 而这正是本文试图填补的认知空白。
连续推理的隐性代价
现代 LLM 推理服务通常采用长驻内存的部署模式，KV 缓存（Key-Value Cache）在多次请求间持续累积，理论上可以加速后续推理。然而，这种 "状态 ful" 的运行方式带来了三个层面的隐性风险。
KV 缓存污染是首当其冲的问题。当服务长时间运行而未进行状态重置时，缓存中残留的注意力模式可能与新请求的上下文产生非预期的交互。微软 Azure 的研究团队在 TAPAS 系统中观察到，LLM 推理包含两个截然不同的阶段：Prefill 阶段并行处理整个提示，Decode 阶段则逐个生成输出 token，每个阶段对温度和功率的敏感度存在显著差异。这种异构性意味着连续运行中的缓存状态可能在不知不觉中偏离最优配置。
热诱导的计算漂移是第二个隐患。GPU 在接近热设计功耗（TDP）边界运行时 ——A100 为 6.5kW，H100 高达 10.2kW—— 温度波动会通过多个机制影响计算精度。当 GPU 温度超过 85°C 时，硬件会触发热节流（thermal throttling）以降低频率保护芯片，这种频率调整虽然防止了物理损坏，却改变了推理的时序特性，进而影响 Layer Normalization 和 Attention Scaling 等敏感操作的数值稳定性。
功率波动的级联效应则构成了第三重风险。数据中心机架间的功率分布呈现明显的 "长尾" 特征：最耗电的机架可能比平均水平高出 27% 的峰值功率。当多个高负载实例被调度到同一功率域时，突发的功率尖峰可能触发 PDU 级别的功率上限（power capping），导致整个机架的计算资源被强制降级。
周期性冷却机制的三层架构
针对上述问题，我们提出一种分层的周期性冷却机制，将 "冷却" 概念从物理层延伸到逻辑层，形成完整的 replenishment cycle。
第一层：物理冷却调度。借鉴 TAPAS 系统的热感知调度策略，将推理实例按温度特征分类为冷、温、热三个等级。新请求优先路由至温度较低的实例，而已运行较长时间的实例则进入 "冷却窗口"—— 一个 5 分钟的请求静默期，期间仅保留心跳检测，允许 GPU 温度回落至安全区间。TAPAS 的评估数据显示，这种策略可将最大温度降低 17%，峰值功率降低 23%，同时支持高达 40% 的额外容量扩展。
第二层：KV 缓存重置。在物理冷却窗口期间，同步执行 KV 缓存的增量重置。与完全重启服务不同，增量重置仅清除超过设定阈值的缓存条目（如超过 1000 个 token 的历史记录），保留近期高频访问的上下文模式。这种 "部分失忆" 策略既避免了冷启动的延迟惩罚，又消除了长期累积的注意力漂移。重置周期建议设置为每 30 分钟或每处理 10000 个请求，以先到者为准。
第三层：校准刷新。在状态重置后，执行轻量级的校准验证。选取一组固定的基准提示（benchmark prompts），对比当前输出与历史基线的分布差异。监控指标包括：embedding 空间的余弦相似度漂移、检索结果的重叠率、以及置信度分数的校准误差。当任一指标超过预设阈值（如余弦相似度低于 0.95）时，触发更深度的状态重建。
可落地的工程参数
将上述架构转化为生产环境的可执行配置，需要明确的阈值定义和自动化决策逻辑。
温度监控与分级响应：
- 正常区间（<75°C）：全速运行，接受新请求
- 预警区间（75-85°C）：启动请求路由避让，优先调度至其他实例
- 临界区间（≥85°C）：强制进入冷却窗口，暂停新请求接入
功率调度策略：
- 单实例功率上限：设定为 TDP 的 80%（A100 约 5.2kW，H100 约 8.2kW）
- 机架级功率缓冲：保留 20% 的功率余量应对突发负载
- 动态频率调整：在功率紧张时，优先降低 GPU 频率而非直接限流，以减少对输出质量的冲击
冷却窗口编排：
- 短周期冷却：每 5 分钟执行一次轻量级状态检查，清理过期 KV 缓存
- 中周期重置：每 30 分钟执行一次完整的缓存刷新和校准验证
- 长周期轮换：每 4 小时执行一次实例级别的冷重启，彻底消除累积漂移
熔断与回滚机制：
- 当 P99 延迟超过 SLO 的 5 倍时，触发自动熔断，将流量切换至备用实例
- 当校准验证失败率超过 2% 时，回滚至上一个已知良好的模型配置
- 保留最近 3 个状态快照，支持分钟级的故障恢复
实施路径与权衡
引入周期性冷却机制不可避免地带来吞吐量的波动。TAPAS 的实验表明，在 50/50 的 IaaS 与 SaaS 混合负载下，冷却调度可将热节流事件减少 97%，功率节流事件减少 99%。然而，这种收益在纯 IaaS 环境中会显著降低 —— 因为 IaaS 实例对云提供商而言是 "黑盒"，无法执行细粒度的配置调整。
对于 SaaS 推理服务，建议采用渐进式部署：先在非关键路径的推理端点上验证冷却策略的有效性，收集至少一周的监控数据后，再推广至核心服务。监控仪表板应实时展示三个关键指标：实例温度分布、KV 缓存命中率的变化趋势、以及基准提示的输出稳定性评分。
在硬件层面，考虑采用异构部署策略：将部分实例配置为 "热备" 模式 —— 始终维持较低温度以应对突发流量，而主力实例则按冷却周期交替运行。这种配置虽然增加了总实例数，但通过提高单实例的可靠性和输出质量，往往能降低整体运营成本。
资料来源
- Stojkovic J, Zhang C, Goiri I, et al. TAPAS: Thermal- and Power-Aware Scheduling for LLM Inference in Cloud Platforms. arXiv:2501.02600, 2025.
- mlsu.io. Can we have the day off? May 2026.
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。