Pre-warming only helps if the forecast horizon is longer than whatever you are warming. On the timeline in the post, the HPA crossed its threshold at 06:05 and the first GPU nodes only ran pods at 06:45 [2], a gap of 40 minutes [2]. The controller looks 10 minutes ahead [5], or a quarter of that gap [5]. Ten minutes of notice buys pod scheduling onto GPU nodes that already exist. It does not buy firmware load, driver init and CUDA readiness [3] on a node the cloud has not handed you yet.
So the pitch and the work come apart here in a way worth naming: the pitch is prediction, and the work is keeping enough GPU nodes warm that ten minutes of notice is enough to fill them. Those sit on different budget lines, and only one of them is a model.
The second ceiling is arithmetic, not accuracy. The graduated scaler rate-limits to 20 pods per minute [10], because the team found out what happens when you ask the scheduler for 100 pods per second [10]. Twenty pods a minute across a 10-minute horizon is 200 pods of pre-warm at most [3]. If the spike needs 300, a better forecast changes nothing about the outcome.
Here is what teams tell themselves after building something like this: the model is good, therefore the incident is solved. What the original incident actually measured was hundreds of pending pods and a 15 to 20 percent error rate [1], and those are the numbers that decide whether Friday goes well. Forecast error is an input. The author is refreshingly plain about the target, writing that for autoscaling they needed to be right 80 percent of the time rather than 100 percent [9], which means one window in five falls through to the burst detector, an adaptive threshold on the rolling standard deviation of predictions against actuals [6]. The account as supplied stops mid-sentence at the rate limiter [11], so there are no post-deployment pending-pod or error figures to hold against the 15 to 20 percent they started from.
Worth checking the training set against your own calendar, too. The model learned from 10,080 samples of GPU utilisation [7], which at one-minute resolution is seven days [4]: seven daily cycles and a single weekly one [6]. A month-end batch run or a quarterly customer onboarding wave is not in that window, and the burst heuristic is what catches it.
Two measurements decide this for your cluster, and neither is a hyperparameter. First, time the full path from "I want a GPU node" to "a pod is serving on it" on your own cloud and your own image. Second, work out how much of tomorrow's curve repeats last week's. Short lag, any pattern: tune the HPA and stop there. Long lag, repeating pattern: forecasting pays, and the horizon has to be at least the measured lag, not a round number. Long lag, event-driven demand: you are buying idle GPUs, and the only real question is how much idle you can defend. Long lag, no pattern, no budget for idle: the honest design is a queue and a documented degradation path rather than a cleverer autoscaler.
