Forecasting methods
The platform provides 14 built-in algorithms plus external model service integration, covering baselines, trends, seasonality, historical similarity, and combinations. Compare methods on the same workload windows using backtests and arriving actuals.
| Model | What it captures |
|---|---|
| Naive / Seasonal Naive | Last-value continuation or repeated cycles as baselines. |
| EWMA | Short-term smoothing with emphasis on recent observations. |
| Holt-Winters | Level, trend, and seasonality with configurable damping and seasonal mode. |
| Theta | Smoothed level and trend for noisy sequences. |
| MSTL | Daily and weekly seasonal shapes. |
| Seasonal Profile | Time-of-day and weekday profiles using historical percentiles. |
| Peak Envelope | Changes in peak demand and resource high-water marks. |
| Histogram Percentile | Decayed historical percentiles for resource-sizing advice. |
| KNN | Similar past windows and their following trajectories. |
| Ridge AR | Lags, calendar features, and available covariates. |
| Random Forest / GBDT | Relationships between historical features and demand through regression trees. |
| Combination | Multiple member predictions combined with configured weighting and error handling. |
Method-by-method parameters and configuration
Each method has its own parameter guide with defaults, types, ranges, units, history requirements, examples, and tuning tradeoffs. Configure external services in Model management and built-in methods in Algorithm management.
| Algorithm / model | Guide |
|---|---|
| Naive | Repeats the latest observation across the horizon. Use it as a basic comparison and to check the data workflow; it cannot anticipate cycles or sudden changes. |
| Seasonal Naive | Repeats the corresponding observations from the preceding cycle. A seasonal baseline for repeating demand; anomalies in that cycle are repeated too. |
| EWMA | Smooths recent observations and projects the resulting level. A low-cost candidate for recent demand, without explicit daily seasonality. |
| Histogram Percentile | Uses a time-decayed historical percentile as a constant future level. Useful for comparing high-water resource sizing, without predicting when a peak occurs. |
| Random Forest | Fits and averages regression trees on sampled historical features, supporting nonlinear relationships and covariates. More costly than simple statistical methods. |
| KNN | Finds similar historical windows and follows their subsequent trajectories. Useful for recurring shapes, with limited ability to anticipate patterns absent from history. |
| Holt-Winters | Models level, trend, and seasonality with additive or multiplicative seasons and optional damped trend. Suitable for cyclic demand with changing levels. |
| Model service · forecasting and tuning | Calls an external time-series model over HTTP. Configure it in Model management, then choose the module prediction mode. A failed request fails that candidate while other eligible methods continue. |
| Theta | Combines a smoothed level with half the fitted linear slope, optionally removing seasonality first. A candidate for noisy trends; forecasts are clamped at zero. |
| MSTL | Separates daily and weekly seasonal shapes and applies Theta to the remainder. This implementation iterates fixed seasonal shapes rather than time-varying LOESS components. |
| Seasonal Profile | Groups observations by time of day and optionally weekday, then uses a decayed percentile per bucket. Useful for weekday/weekend demand patterns. |
| Peak Envelope | Builds a rolling-maximum envelope and extrapolates its robust slope. Targets high-water demand rather than averages, such as memory sawtooth patterns and cache growth. |
| Combination | Combines member forecasts using a stepwise median or recent-error weights. The combination must earn backtest promotion like other candidates. |
| Ridge AR | Fits linear relationships from lags, optional UTC calendar features, and covariates. A relatively inexpensive machine-learning candidate for stable linear dependencies. |
| GBDT | Fits successive trees to residuals using lags, calendars, and covariates. Supports squared-error point forecasts or a native quantile objective. |
Before configuring a method
- Steps are not minutes: cycle steps = cycle seconds / sample interval seconds. At five-minute sampling, a day is 288 steps and a week 2016; forecast steps use the same interval.
- Defaults apply to new configuration, not to previously saved settings. Required fields have no default; omitted optional fields use defaults. Unknown names and invalid types are rejected.
- Separate method parameters from runtime policy. Configure history, sampling, and horizon on modules; configure model parameters, budgets, and eligibility centrally. JSON examples are parameter objects, not top-level config.yaml entries.
- Minimum history permits execution rather than guaranteeing accuracy. Direct forecasts, excluded KNN neighbors, and quantile calibration add history or compute requirements. Expand real history instead of duplicating observations.
- Quantile settings differ: percentile=95 is a historical percentile; quantile_level=0.9 enables conformal calibration. GBDT alpha and model-service service_quantile have their own meanings.
- Covariates do not provide future observations: only values before the forecast origin are used, and future steps carry the latest observation. Calendar features and KNN time filters use UTC; seasonal profiles use utc_offset_minutes.
External models and background tuning
Model services support finetune, unitshub_chronos, and unitshub_timesfm protocols. Configure a reachable endpoint first; only finetune supports background tuning. Forecasts do not wait for tuning: they use an existing tuned copy, or the pretrained model if none exists. Backtests and change replay assess pretrained models; use live prediction actuals to assess tuned copies. Full model service reference →
Central model settings
Manage activation, parameters, weights, budgets, and adoption thresholds centrally. Modules with prediction enabled in dynamic mode use the platform's enabled methods without separate instances or manual binding.
Inspect model runs for insufficient history, missing parameters, and timeout. A rank or model name alone does not determine suitability.
Central runtime settings
| Setting | Meaning and use |
|---|---|
| Activation | Dynamic prediction uses enabled methods. Fixed mode still runs its selected method, so central activation does not replace the module prediction switch. |
| Weight | Affects scoring and ranking; default 1. It does not directly multiply predicted demand or guarantee adoption. |
| Training time budget | Zero uses the platform default. Positive values limit execution in seconds, up to 3600. Check this budget before adding trees, direct anchors, or calibration windows. A timed-out candidate fails. |
| Promotion thresholds | Minimum evaluated points, relative error improvement, and peak tolerance constrain candidates. Baselines need no promotion; quantile forecasts also use coverage and pinball loss. |
These settings belong to the model record, not the JSON parameter object. Central parameter changes affect multiple dynamic modules; compare backtests or change previews before saving.
Derived and formula models
Create derived models from built-in methods or define parameterized formulas. Check outputs and input requirements before saving. Parameter or implementation changes affect version identity and adoption eligibility.
Choosing and adopting models
Align forecast horizon and historical window, then compare resource error, peak underestimation, stability, and runtime. Available model forecasts can participate in look-ahead consensus; rank is not the sole basis for execution.
Choose how a module predicts
Prediction is disabled for new modules. History collection continues, recommendations use configured fallback defaults, and no algorithms run. Enable prediction when ready to use models, then choose a mode.
| Prediction mode | How advice is produced | When to use it |
|---|---|---|
| No prediction | Use fixed defaults without running algorithms; this is intentional configuration, not degradation. | Collect history first or operate with known defaults. |
| Fixed algorithm | Run one selected algorithm without score-based switching. Non-baseline models still require backtest promotion. | Keep a selected forecasting method explicit. |
| Dynamic algorithms | Run centrally enabled methods and use scores, recent errors, and eligibility. Dynamic replica decisions combine eligible candidates' votes. | Compare methods continuously as workload patterns change. |
A fixed algorithm continues running for its module even when disabled centrally. It bypasses the module's minimum overall score filter, while version promotion and resource safeguards still apply. Prediction mode is independent of Observe, Recommend, Admission, and Auto: enabling a model does not authorize cluster writes.
Keep seasonal models responsive
For applicable seasonal and long-memory methods, recent predictions are compared with actuals. Significant rises add a short-term correction that fades over time. Downward correction is disabled by default to limit the risk of reacting to a brief dip. Combination forecasting also penalizes underestimation more heavily, trims much weaker members, and includes recent errors in its weights.
Changes to models or correction parameters require renewed backtest promotion. Seasonal patterns and short-term corrections still operate within resource bounds and execution safeguards.