Demand forecasting at scale: Decathlon cuts WAPE and inference time with Chronos-2 and LoRA

How Decathlon runs demand forecasting at scale with Chronos‑2

By adopting Chronos‑2 and parameter‑efficient fine‑tuning (LoRA), Decathlon reports cutting forecasting error by up to 15 percentage points (WAPE) and reducing inference times from minutes to seconds, enabling weekly replenishment across thousands of SKUs without a large GPU fleet. These results come from Decathlon’s internal benchmark covering roughly 39, 000 product time series and 101 rolling cutoffs from week 48 of 2022 to week 44 of 2024 (Decathlon‑reported).

The practical question they asked

“Would these models work on Decathlon’s specific retail datasets?” was the central evaluation question phrased by Decathlon’s team. The stakes were not academic: forecasts drive a 12‑week replenishment cycle and a 52‑week strategic horizon across supply zones that each cover up to 25, 000 products. Any chosen solution had to meet real operational constraints, CPU inference, low latency, modest engineering complexity, while improving accuracy enough to move business metrics.

What they benchmarked

Decathlon ran a large, production‑scale benchmark (Decathlon‑reported):

≈39, 000 unique product time series evaluated across 101 rolling cutoffs (week 48/2022 → week 44/2024).
Weekly aggregation and weekly forecast frequency for both 12‑week replenishment and 52‑week strategic horizons (Decathlon‑reported).
Comparisons of zero‑shot TSFMs and LoRA fine‑tuned TSFMs against the production baseline (historically DeepAR + Holt‑Winters for 2021-2023 and Temporal Fusion Transformer in 2024; Decathlon‑reported).
Primary metric: Weighted Absolute Percentage Error (WAPE), a scale‑adjusted absolute error that weights series by volume; secondary metrics included RMSE, bias, and pairwise win rates (Decathlon‑reported).

Decathlon’s benchmark also imposed operational targets: CPU‑only inference (m6i.8xlarge), low latency (benchmark requirement under 2 minutes for 25, 000 products per cutoff), and manageable engineering complexity.

Why Chronos‑2 was chosen

Chronos‑2 is an encoder‑style transformer for time series that alternates attention along the temporal axis (within each series) with attention across series at matching time patches. That combination lets the model share patterns across related SKUs while still modeling each series’ temporal dynamics, which is useful for retail assortments with seasonal, regional, and cross‑item correlations.

Model variants used: amazon/chronos‑2 (120M parameters) and autogluon/chronos‑2‑small (28M parameters) (Decathlon‑reported).
Decathlon fine‑tuned Chronos‑2 using Low‑Rank Adaptation (LoRA) inside AutoGluon‑TimeSeries to get parameter‑efficient adaptation with smaller checkpoints and far fewer GPU hours than full fine‑tuning (Decathlon‑reported).
Operationally attractive: LoRA yielded the needed accuracy gains while keeping inference CPU‑friendly and engineering simpler to deploy and maintain.

Concrete accuracy and business impacts (Decathlon‑reported)

Measured against Decathlon’s production baseline, Chronos‑2 with LoRA produced consistent WAPE improvements:

South East Asia (SEA), 12‑week: WAPE 39% → 28% (11 percentage points).
Latin America (LATAM), 12‑week: WAPE 53% → 38% (15 percentage points).
SEA, 52‑week: 44% → 38% (6 percentage points).
LATAM, 52‑week: 55% → 46% (9 percentage points).

Decathlon maps these WAPE improvements to operational levers using historical correlations (Decathlon‑reported): 1 WAPE point at the 12‑week horizon ≈ 0.3 days of inventory saved, ≈ 0.3 points of product availability, and ≈ 0.12 points of sales (they report a 0.4 points sales uplift per availability point, which averages to ~0.12 sales per WAPE point across zones). These translations are region‑ and assortment‑dependent and were estimated from Decathlon’s historical data (Decathlon‑reported).

Note: the mapping is an empirical translation specific to Decathlon’s assortment and should be validated before being used for financial projections in other organizations.

Production performance, cost, and cadence

Key production decisions and observed performance (Decathlon‑reported):

Data pipelines: PySpark preprocessing on Databricks and Airflow orchestration; MLflow as the model registry for per‑zone model versions.
Fine‑tuning: performed on GPU instances (Amazon EC2 g5.4xlarge) with LoRA; Decathlon fine‑tunes roughly every six months rather than weekly.
Inference: batch CPU inference on Amazon EC2 m6i.8xlarge instances. Typical batch size ≈12, 000 series per execution; Decathlon’s benchmark target was under 2 minutes for 25, 000 products per cutoff (Decathlon‑reported).
Observed inference runtimes: ~40 seconds for 7, 000 series in LATAM and ~75 seconds for 15, 000 series in SEA on m6i.8xlarge (Decathlon‑reported). That corresponds roughly to 0.0057-0.0050 seconds per series. Decathlon did not fully disambiguate whether those times include feature assembly and I/O overhead versus model forward pass only.
Reported compute cost: approximately $0.03 per weekly inference run (Decathlon‑reported), and Decathlon did not publish a detailed cost decomposition, so it is unclear what this number includes (instance hours, reserved vs spot pricing, ETL, storage, or only raw model compute).

Operations and velocity improvements

Compared with their earlier stack (DeepAR + Holt‑Winters and later TFT), Decathlon reports meaningful drops in deployment effort and inference latency (Decathlon‑reported):

New region deployment time: ~6 months with the older approach (three people) → 2-3 months with Chronos‑2 (data scientist, ML engineer, data analyst).
Inference runtimes: previously 10-15 minutes for 10k, 25k series → now seconds (~40s for 7k, ~75s for 15k) on the CPU instances noted above.
Fine‑tuning cadence reduced from weekly retraining to scheduled LoRA fine‑tuning every six months, reducing operational churn while still capturing medium‑term distribution shifts.

Architecture at a glance

Feature pipelines in PySpark produce weekly series and covariates; Databricks jobs trigger MLflow‑registered model scoring on EC2 instances.
AutoGluon‑TimeSeries handles data formatting, LoRA fine‑tuning orchestration, and inference plumbing; MLflow stores zone‑specific checkpoints and metadata (Decathlon‑reported).
Plans for future additions include Mixture of Experts (MoE) ensembling, richer external covariates (price, weather), and cross‑learning strategies for cold‑start items (Decathlon‑reported).

What wasn’t fully specified (and why it matters)

Decathlon’s report is detailed but leaves some operational and methodological items open (Decathlon‑reported or unspecified):

LoRA specifics: rank, learning rates, epochs and exact tuning regimen were not disclosed. Those hyperparameters materially affect compute and final accuracy.
Preprocessing choices: the public account omits details on promotion encoding, handling of stockouts (zero sales due to no inventory), and imputation strategies, all of which influence forecast behavior on retail series.
Cost breakdown: the $0.03 weekly inference run figure lacks decomposition; readers should treat it as an indicative Decathlon‑reported number rather than a universal benchmark.
Mixture of Experts rollout: Decathlon signals intent to implement MoE ensembling but does not publish the routing, serving, or orchestration design yet, and these operational details can be complex in production.

Practical lessons and recommendations

Decathlon’s experience suggests a pragmatic path for retailers evaluating TSFMs:

Benchmark on your own data at scale. Pre‑trained TSFMs can work zero‑shot, but fine‑tuning on local history often yields material gains, validate with rolling cutoffs and business‑relevant horizons.
Prefer parameter‑efficient fine‑tuning (LoRA) if you need multiple per‑zone models or want to limit GPU hours and checkpoint storage. It captures much of the accuracy uplift while keeping operational costs down (Decathlon‑reported).
Define operational targets up front (latency, CPU/GPU constraints, batch size) and measure throughput per series to make deployment decisions comparable across regions and instance types.
Translate error improvements into business KPIs early, inventory days, availability, and sales, but treat those mappings as empirical and organization‑specific, not universal constants.
Build monitoring and governance from day one: cohort WAPE, bias on promoted SKUs, cold‑start error, and data‑quality signals are essential. Use these to trigger ad hoc retraining or rollback policies rather than relying solely on a fixed fine‑tuning cadence.

Open operational questions to watch

Decathlon’s roadmap is sensible, but the next challenges most retailers should watch for are real:

Operationalizing Mixture of Experts without exploding servicing complexity or latency.
Ensuring consistent ingestion and validation of external covariates (price, weather) across regions with differing data quality.
Designing monitoring and drift detection that catch subtle supply‑chain shifts between scheduled fine‑tunes.
Handling extreme intermittency, promotions, and product launches where cross‑learning and gating strategies must be carefully validated to avoid leakage.

Key takeaways: quick Q&A

Do time series foundation models work on retail datasets?

Decathlon reports that several TSFMs were viable zero‑shot on their retail data, and Chronos‑2 fine‑tuned with LoRA produced the best accuracy in their large benchmark.
Is zero‑shot sufficient, or should you fine‑tune?

Zero‑shot can be a useful quick baseline, but Decathlon’s benchmark shows LoRA fine‑tuning provides measurable WAPE reductions that translate to inventory and availability benefits.
Can inference run on CPU without GPUs?

Yes, Decathlon runs batch inference on m6i.8xlarge instances and met their latency targets (seconds per batch for thousands of series), though exact runtimes may depend on whether times include feature assembly and I/O.
How often must the TSFM be fine‑tuned?

Decathlon moved to a six‑month LoRA fine‑tuning cadence, balancing freshness and operational overhead. They kept weekly forecasts but reduced retraining frequency from weekly to semiannual.
What business impact comes from WAPE improvements?

Decathlon maps 1 WAPE point (12‑week horizon) to ~0.3 days of inventory saved, ~0.3 points of availability, and ~0.12 points of sales (Decathlon‑reported). These mappings are empirical and should be validated per retailer.
Are these results generalizable to other retailers?

Promising but not guaranteed, Decathlon emphasizes benchmarking on your own assortment and patterns since intermittency, promotions, and assortment churn change model performance.

Decathlon’s deployment is a useful blueprint: validate TSFMs at production scale, prefer parameter‑efficient fine‑tuning when you need multiple per‑zone models, make CPU‑first inference a design constraint if that simplifies operations, and translate error improvements into operational KPIs. The next technical milestones, MoE ensembling, richer covariates, and robust drift governance, will determine whether foundation models become a standard component of retail forecasting or a high‑maintenance specialty. For now, Decathlon’s results, reported across a large, real‑world benchmark, show that practical, scalable TSFM deployments are achievable.