GPU 工作负载的自动扩展问题可能并不是 Kubernetes 无法做出决策，而是决策到达得太晚。Adobe 的 Ramkumar Nagaraj 和 Bingi Narasimha Karthik 描述了一起事件：一项关键生产服务遭遇需求波动，导致用户错误率升至 15–20%，尽管 Horizontal Pod Autoscaler 已开始扩展。原因在于数百个容器仍处于等待状态，而新的 GPU 节点需要很长时间才能准备就绪。
在两位作者记录的时间线中，需求波动于 06:00 到来，HPA 指标于 06:05 超过阈值，随后容器于 06:15 开始调度。但第一批 GPU 节点直到 06:45 才完成准备，也就是波动已经结束之后。由于需要加载固件、配置驱动程序并准备 CUDA，GPU 节点通常需要 CPU 服务准备时间的三到五倍。
从响应需求到为需求做好准备
团队建议在 Kubernetes 内运行一个每 60 秒执行一次的控制器，读取过去一小时的指标，并预测十分钟后的需求。目标并不是实现完美预测，而是在波动到来前尽早开始准备容量，使节点和容器能够在需要时就绪。
该设计利用 Prometheus 收集的数据，包括 CPU 和内存使用率、响应时间、请求速率以及 GPU 使用率。团队测试了 ARIMA、指数平滑、Prophet 库、LSTM，随后选择了由 64 个单元和 32 个单元组成的两层 Bi-LSTM 模型。根据文章，该选择是为了应对包含短时峰值、恢复阶段和异常恒定值的数据模式，而不是因为它在理论上适用于所有情况。
模型每周重新训练，而部署的模型仅在使用 TensorFlow Lite 的 Go 语言控制器二进制文件中运行推理模式。因此，该设计不需要外部机器学习平台或模型服务层。
用于控制扩展的三层机制
该设计由三个相互关联的功能组成：预测、准备和吸收。模型预测需求，控制器随后逐步增加副本数，而预先准备的容量则为容纳实际波动提供空间。
由于预测无法应对所有意外情况，团队并行加入了一个突发检测器。该组件使用基于移动标准差的自适应阈值，将实际需求与预测值进行比较。如果需求相对预测值的偏差达到设定的置信水平，检测器就会提高扩展速度。两位作者将该组件描述为推理式安全网，而不是第二个预测模型。
渐进式扩展器将增量限制为每分钟 20 个容器。这样做是为了避免大规模调度波次给调度器和 etcd 造成压力，并导致镜像拉取、容器启动、初始化容器准备以及 sidecar 注入操作相互拥挤。此外，目标使用率被设定为 70%，而不是 100%，从而留下空间来吸收峰值，并允许模型偶尔出现不准确，而不会使错误演变为一连串故障。
测试证明了什么？
团队首先以影子模式运行系统，只记录预测结果而不执行实际扩展，并收集了超过 500 小时的数据。结果显示，当十分钟后的需求预测处于实际需求 ±10% 的范围内时，准确率达到 85%。突发检测器捕捉到了十次波动中的九次，并出现两次误报；渐进式扩展器测试则没有出现级联故障或扩展振荡。
该系统还与 HPA v2 并行运行，未发生冲突。在受控开发环境中进行的一周验证期间，23 项测试全部通过。在对导致原始事故的波动模式进行模拟时，系统能够提前约 11 分钟检测到波动。
这种方法何时适用？
当节点准备时间超过两三分钟，且需求具有部分可预测性（例如每日模式、每周模式或已知事件）时，预测性扩展的价值就会显现。此外，它还需要高质量的监控数据，至少应有一周的 Prometheus 指标。相反，如果节点能在 30 秒内准备就绪，需求完全随机，或者团队首要目标是降低成本，那么这一思路的意义就会降低；保持节点温热意味着要支付备用容量的成本。
编辑解读：这里的实际变化并不是替换 HPA，而是向通常在需求出现后才做出响应的系统中加入预测时间。它对 GPU 工作负载尤其重要，因为如果基础设施需要几十分钟才能启动容器，那么扩展决策的速度本身并不足够。但目前展示的证据仍来自受控验证，而不是在多个生产环境中进行的大规模独立测量。
团队自身的经验也表明了几个重要限制：经过调优的 ARIMA 模型可能以更简单的架构取得相近结果；当需求模式发生变化时，模型可能在数天内就变得过时。此外，为什么预测出特定数量的副本仍然难以解释，而最优数据量、重新训练周期以及推理式突发检测器捕捉前所未有事件的能力等问题，也尚未得到解决。
因此，文章建议先收集一周的指标，训练一个简单模型，以影子模式运行，然后在启用扩展前衡量准确性。转入生产环境后，应设置副本上限，提供明确的禁用操作，并最好先经过受限扩展阶段，再开放完整扩展能力。两位作者反复强调的结论很实际：模型复杂性本身并不是优势；如果更简单的方案能够成功，最好运行更简单的方案。