Start with the range in the Google Cloud writeup. If steady-state CPU sits 50% to 80% below what initialisation consumed [1], then boot wants somewhere between 2x and 5x the steady-state number [1]. The sample policy sets `factor: 2` [11]. That covers the bottom of the band and nothing above it. A framework-heavy service at the 80% end needs a factor near 5, or a `type: Quantity` addition sized by measurement [12], and the post's own range is the argument for measuring rather than copying the manifest [3].
The waste being removed is larger than the boost being added. The habit described is 2 to 4 vCPUs pinned for the life of the pod [2], against a steady-state example of 500m [3]. That is a standing over-request of 4x to 8x [2], and it is the packing density number, not the startup number.
The ordering is the part worth reading twice. The mutating webhook rewrites the CPU request and stamps a `vpaCpuStartupBoost/<container-name>` annotation before the scheduler places the pod [6], and Kubernetes uses that request for both placement and CFS bandwidth enforcement [7]. So a 500m container with factor 2 is scheduled as 1000m [4]. The throttle relief is real because the quota really is higher; you pay for it at placement, where the node must have the boosted room free. Reclaim happens later and live, through In-Place Pod Resize, with no container restart [9]. Density improves in the steady state, which is not the moment HPA is adding replicas to catch a traffic spike [14].
The boost window is defined by readiness, not by warm-up. The `durationSeconds` timer starts when the pod reports Ready [8]. If your readiness probe answers from a static health endpoint before JIT has compiled the hot paths, ten seconds after Ready is all the JVM gets [11]. That turns probe design into a resource-sizing decision, which is an odd place for one to live.
Treat "up to 2x faster startup latency" [5] as a claim about the workloads Google measured. It transfers only if your startup is CPU-bound and genuinely throttled at the baseline request. If boot time goes on waiting for a config server or a schema migration, a wider CFS quota buys nothing, and the boost shows up as scheduling pressure with no latency return.
Adoption cost is a channel decision. The preview runs only on 1.36.0-gke.4447000 or newer in the Rapid Channel [4]. Exclude sidecars with `containerPolicies` [13], because the boost is per container and the scheduler sums the pod.
If you already own your steady-state requests in the Deployment, `updateMode: "Off"` keeps VPA from touching them while still applying the boost [10]. That is where I would start: the Deployment stays the source of truth for the baseline, and the VPA object carries one multiplier and one timer.
