A Two-Stage Forecasting System for CPU Workload Prediction in Private Clouds
Ashir Javeed, Anton Borg, Håkan Grahn, Lars Lundberg, Dhyey Patel, Sogand Shirinbab
cs.LG
Quick verdict
Cascaded TPS→CPU XGBoost forecasting on real private-cloud traces; solid engineering, but the claimed gain over direct forecasting is never benchmarked.
Summary
This paper proposes a two-stage cascaded forecasting system for CPU workload in a private cloud: an XGBoost model first forecasts customer service requests (TPS) over a 60-step horizon from a 512-step sliding window, then a second XGBoost model maps the forecasted TPS features to CPU, trained against a rolling-maximum future CPU target (windows 4–15). Expanding-window retraining every 1,000 observations addresses concept drift. Evaluation uses traces from ten Ericsson private-cloud applications at 1-minute resolution — 1,440 samples artificially expanded to 8,514 by replication and mirroring — with walk-forward validation on the final 75%. On the integrated system, SMAPE ranges 3.57%–45.73% (below 7% for 6 of 10 applications), R² 0.62–0.92, with ~180–264 ms per 60-step horizon; the standalone CPU stage fed true TPS reaches R² 0.91–0.99 in 0.8–7.7 ms. Horizon-wise MAE grows roughly linearly for all five TPS features. Main limitations: no experimental comparison against direct CPU forecasting or external baselines, so the headline claim of superiority over conventional direct forecasting is unsupported; the replicated dataset risks train/test leakage; the per-application rolling-window selection procedure is unspecified; and no significance tests are reported. Data are confidential and no code is released, limiting reproducibility.
Review complete
Assessment at a glance
6
risk flags identified
● high 2
● medium 2
● low 2
4 strengths · 5 weaknesses · 5 author questions
AI text signal = Binoculars zero-shot detector score over 20 sampled passages (Fast-DetectGPT co-reported) — absence does not prove human authorship, and a flag does not imply misconduct.
Levels reflect verification complexity — not a quality score. Evolve never rates your paper.
Key claims under review
- Forecasting customer service requests (TPS) before CPU estimation explicitly models the demand-to-resource dependency that direct CPU forecasting ignores (Sections 1, 3).
- The integrated two-stage system achieves SMAPE below 7% for most applications (6/10) and R² up to 0.9185 over a 60-step horizon (Table 5).
- Recursive forecasting error accumulates in a controlled, roughly linear way across the 60-step horizon for all five TPS features (Section 4.2, Figure 4).
- The two-stage system improves robustness, computational efficiency, and interpretability compared with conventional direct CPU forecasting (Abstract, Section 5) — asserted but not demonstrated by any baseline experiment in the paper.
- Sub-second end-to-end latency (~180–264 ms forecast stage; 0.77–7.67 ms CPU stage) makes the system suitable for real-time auto-scaling (Tables 5, 7).
Strengths
Real production traces from a commercial private cloud
Ten applications across four pods (A, B1–B3, C, D1–D5) with Ericsson AB data at 1-minute resolution (Section 3.5, Table 2); CPU scales span four orders of magnitude (D4 max 0.01425 vs B1 max 275.6), giving a genuinely heterogeneous testbed.
Complete method specification
Algorithm 1 gives the full workflow; XGBoost hyperparameters are exhaustively tabulated for both stages (Tables 4 and 6: 300 estimators, depth 6/4, lr 0.05, subsample/colsample 0.8, seed 42), plus window sizes and retraining interval r=1000 — enough to rebuild the pipeline.
Error-source decomposition between the two stages
Deployment-aware evaluation
Weaknesses
The central comparative claim is never tested
Synthetic dataset inflation undermines validity
Underspecified per-application tuning
No statistical rigor
Weak integrated performance on half the fleet, with one app shown
Full Review Report
$1.99 · one-timeUnlock the complete preliminary analysis Evolve produced for this paper.
Report preview
Scope & Claims
The paper (arXiv 2609.03457, cs.LG) presents a two-stage cascaded forecasting system for CPU workload in an Ericsson private cloud with ten applications across pods A–D. Stage 1 forecasts five anonymized TPS features over a 60-step horizon (one hour at 1-minute sampling) using a multi-output XGBoost on a 512-step sliding window; Stage 2 maps the forecasted TPS to CPU, trained against a rolling-maximum target with per-application windows of 4–15 (Eq. 7). An expanding-window retraining every 1,000 observations addresses concept drift. Central claims: (1) explicit demand→resource modeling improves robustness over direct CPU forecasting; (2) SMAPE below 7% for most applications with best R² 0.9185 (application A, Table 5); (3) controlled, roughly linear drift over the 60-step horizon (Figure 4); (4) sub-second latency suitable for auto-scaling.
The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.
- All 4 strengths & 5 weaknesses, analyzed in detail
- 6 risk flags with severity, section & reviewer questions
- Methods & statistical evidence assessment
- 5 questions a peer reviewer would ask
- Full six-dimension evaluation report & recommendations
One-time purchase · this paper only
One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.
Frequently asked questions
What is a two-stage forecasting system for cloud CPU prediction?
It first forecasts future customer service requests, measured in Transactions Per Second (TPS), using one XGBoost model, then feeds those forecasted TPS values into a second XGBoost model that predicts future CPU utilization. The goal is to model the chain from user demand to resource consumption explicitly instead of extrapolating CPU history directly.
How accurate is the proposed model?
On ten private-cloud applications, the integrated two-stage system reported SMAPE between 3.57% and 45.73% (below 7% for 6 of 10 applications) and R² between 0.62 and 0.92, with the best application reaching MAE 0.7372 and R² 0.9185 over a 60-step (one-hour) horizon. The CPU stage alone, fed the true TPS values, reaches R² 0.91–0.99.
Is the dataset or code from this paper publicly available?
No. The workload traces come from Ericsson's private cloud and are confidential (some values are also multiplied by a secret constant to hide sensitive figures), and the paper does not mention any public code repository, so the results cannot be independently reproduced.
What are the main criticisms of this paper?
The headline claim that the two-stage approach beats conventional direct CPU forecasting is not backed by any baseline experiment; the one-day dataset (1,440 samples) was expanded about threefold by copying and mirroring, which risks train-test leakage; per-application smoothing windows may have been tuned on evaluation data; and no statistical significance tests are reported.
About this review
This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.
- Figures 1–4 appear in the extraction as captions only; their visual content (e.g., the drift curves in Figure 4 and the forecast overlay in Figure 3) could not be inspected.
- Equations and Algorithm 1 are garbled by PDF extraction (subscripts, hats, summation layout); their content was reconstructed from the surrounding prose and tables.
Go deeper on this paper
Wrote a paper? Stress-test it before reviewers do.
Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.