CONCEPT Cited by 1 source
Continuous reprediction¶
Continuous reprediction is the online policy of re-running a predictor as new observations arrive, replacing a single commit-at-creation prediction with a stream of updated estimates. The scheduler (or other downstream consumer) consumes the latest estimate, not the initial one.
Named directly in Google Research's 2025-10-17 LAVA post: "This system uses a process we call 'continuous reprediction', which means it doesn't rely on the initial, one-time guess of a VM's lifespan made at its creation. Instead, the model constantly and automatically updates its prediction for a VM's expected remaining lifetime as the VM continues to run" (Source: sources/2025-10-17-google-solving-virtual-machine-puzzles-lava).
Why it matters¶
The primary motivation is recovery from early-stage misprediction. If the decision a predictor drives is expensive to reverse (VM placement being the canonical example), a single bad guess at t=0 can poison the decision until the workload actually exits. Continuous reprediction re-opens the decision whenever the estimate changes enough to justify acting.
Secondary motivations:
- Observational evidence accumulates. At t=0, the predictor has only creation-time features (request shape, labels, user). At t=k, it has observed trajectory: actual resource usage, idle periods, lifecycle events. The later estimate is fundamentally better-informed, not just better-predicted.
- Distribution shift within a single run. Workloads change character (burst → steady → idle → teardown). A single creation-time prediction can't reflect this; a continuously repredicted estimate can.
Mechanism¶
Three conceptual components:
- Online predictor — takes (creation-time features, observed-trajectory features so far) and emits a prediction (often a distribution — see learned lifetime distribution).
- Update trigger — when to re-run. Options: periodic (every N minutes), event-driven (lifecycle event, resource- usage inflection), prediction-driven (previous prediction's uncertainty hit a threshold).
- Consumer that acts on updated estimates — load-bearing but often under-acknowledged. If the scheduler can only use the creation-time estimate, continuous reprediction is wasted. Downstream consumers need a mechanism to react: LARS is the LAVA family's answer.
Distinct from [¶
deterministic simulation](<./deterministic-simulation.md>) / control loops
Control theory has online re-estimation (Kalman filters, receding-horizon MPC, online system identification); all of those are forms of continuous reprediction. The 2025-10-17 post applies the discipline to ML-based lifetime prediction in a cluster scheduler — a setting where the prediction target is discrete (does this VM still exist?), the evidence arrives in bursts, and the downstream consumer is a bin-packer, not a controller. The wiki frames it as an ML-for-systems primitive.
Contrast with single-shot ML prediction¶
The 2025-10-17 framing makes the contrast explicit:
| Aspect | Single-shot | Continuous reprediction |
|---|---|---|
| Features used | Creation-time only | Creation-time + observed trajectory |
| Misprediction recovery | Only via VM exit or migration | Next prediction window |
| Downstream commitment | Strong (one decision, long hold) | Weaker (re-decidable any update) |
| Added infra | None | Prediction runner, update trigger, rescheduling hook |
When it's the right shape¶
- The prediction target evolves and remains measurable as the process runs.
- The downstream decision is expensive to reverse relative to the reprediction cost.
- A single bad prediction has asymmetric downside (cost of being wrong ≫ cost of re-running the predictor).
- The system has a mechanism to act on updated predictions (re-scheduling, re-routing, re-allocating).
When it's the wrong shape¶
- Target is fixed at t=0 and doesn't evolve with observation (e.g. one-shot classification tasks).
- Downstream decision is cheap to re-make, so single-shot plus override-on-next-event is simpler.
- No trajectory-observable features — the creation-time prediction is the best information available.
- Reprediction + re-scheduling cost exceeds the misprediction cost in expectation.
Seen in¶
- sources/2025-10-17-google-solving-virtual-machine-puzzles-lava — canonical wiki instance; continuous reprediction named as the load-bearing primitive of the LAVA / NILAS / LARS algorithmic family for VM scheduling.