PaperlayerView exact revision on arXiv

Source-linked AI summary

Sustainability of TSFM Deployment and Pretraining: From Carbon Footprint Analysis to Mitigation via Pruning

Cécile Luc, Nathanaël Lemonnier, Ievgen Redko

arXiv:2610.32859v1cs.LG

TL;DR

TSFMs’ strong zero-shot capabilities come with substantial upfront pretraining costs, and their lifecycle carbon cost relative to specialized models has not been compared. The paper models those costs and evaluates structured Chronos-2 pruning; pretraining pays off for sufficiently large or frequently queried deployments, while pruning cuts inference costs with essentially no zero-shot performance loss.

  • Problem

    TSFMs require substantial upfront pretraining, but their cumulative carbon cost across deployment has not been compared with specialized models’ periodic retraining and inference costs.

    Source: §1 · p. 1

  • Method

    The paper models lifecycle costs against LightGBM and PatchTST and tests gradient-free, structured Chronos-2 encoder-block pruning without fine-tuning.

    Source: §3.1 · p. 3, §4 · p. 5, §4.1 · p. 5

  • Results

    Chronos-2’s pretraining cost is amortized only for sufficiently large or frequently queried deployments; one-block pruning reduces FLOPs, CO2 emissions, and latency by 6 to 9% with essentially no zero-shot performance cost.

    Source: §5 · p. 7

  • Takeaways & Limitations

    Whether Chronos-2 pays off depends on deployment size, duration, and query frequency; when pretraining does not amortize, reducing inference cost is the remaining focus.

    Source: §3.2 · p. 5

    The PatchTST comparison assumes per-asset training; a model shared across similar assets would not have training costs that scale with asset count.

    Source: §3.2 · p. 4

Abstract

from arXiv · show

Time Series Foundation Models (TSFMs) offer strong zero-shot forecasting capabilities, but their high pretraining cost raises a practical sustainability question: does this upfront investment pay off over a full deployment lifecycle, compared to supervised standalone models that must be periodically retrained? We model the cumulative carbon cost of different approaches across a realistic industrial scenario: Chronos-2 amortizes its pretraining cost within months for large or frequently queried deployments, but a classical model remains cheaper indefinitely for small or rarely queried ones. For cases where reducing the TSFM's own cost matters, we show that removing a single encoder block (7.9% of parameters) via a gradient-free pruning criterion yields a consistent 6 to 9% reduction in FLOPs, CO2 emissions, and latency, at essentially no cost to zero-shot forecasting performance across a 25-task benchmark.

1 Introduction

TSFMs offer broad zero-shot capabilities, but their substantial upfront pretraining cost contrasts with the periodic, per-asset retraining required by task-specific models. This paper compares lifecycle carbon costs and studies pruning as a way to reduce TSFM inference costs.

1 Introduction

  • TSFMs generalize zero-shot across forecasting, anomaly detection, and classification, but require substantial upfront computing, energy, and carbon expenditure.Task-specific deep learning and classical models instead require periodic, per-asset retraining as data evolve.Source: §1 · p. 1
  • No existing study, to the authors’ knowledge, compares TSFMs and specialized models’ cumulative carbon costs across pretraining, retraining or fine-tuning, and inference.The paper frames lifecycle accounting as a way to assess whether a TSFM’s upfront cost can be amortized.Source: §1 · p. 1
  • The study compares lifecycle costs against LightGBM and PatchTST, then tests structured Chronos-2 pruning for inference savings while preserving zero-shot forecasting.Its pruning analysis also characterizes FLOPs, CO2 emissions, and latency for full and pruned models.Source: §1 · p. 2

2 Background and Related Work

The background describes Chronos-2’s architecture and computational trade-offs, outlines carbon and FLOPs accounting, and distinguishes this paper’s cost-focused pruning goal from prior time-series pruning work.

2 Background and Related Work

  • Chronos-2 is an approximately 120M-parameter encoder-only transformer that supports zero-shot multivariate forecasts, while self-attention scales quadratically with context length.It produces horizons up to 1024 in one forward pass; the reported costs are a Chronos-2 baseline, not representative of all TSFMs.Source: §2 · p. 2
  • CodeCarbon estimates CO2-equivalent emissions from hardware energy use and local grid carbon intensity, while FLOPs provide a hardware- and software-independent architecture comparison.The passages describe the environmental accounting approach and the complementary role of operation counts.Source: §2 · p. 2
  • Structured pruning removes whole components and can speed execution on regular hardware, unlike unstructured pruning, which requires specialized support to accelerate sparse matrices.The paper targets cost reduction while preserving zero-shot ability without task-specific fine-tuning, unlike Zhao et al. [2025], who prune before fine-tuning to improve downstream performance.Source: §2 · p. 2

3 Carbon cost of TSFM Deployment

The section models lifecycle carbon costs for industrial forecasting deployments and compares Chronos-2 with supervised alternatives. Chronos-2’s pretraining cost is amortized only under sufficiently large, long-running, or frequently queried deployments; the break-even point shifts with retraining and inference frequency.

3.1 Deployment scenario and cost model

  • The modeled system forecasts hourly for Na industrial assets, requesting a 24-hour forecast per asset daily, with periodic retraining or fine-tuning.LightGBM is modeled as a rolling hourly forecast requiring 24 calls per 24-hour forecast, while PatchTST and Chronos-2 produce the horizon in one call.Source: §3.1 · pp. 2–3
  • Chronos-2’s pretraining cost is paid once, while its zero-shot deployment cost adds inference calls over time; LightGBM’s model includes periodic retraining and inference costs.Chronos-2’s pretraining cost is extrapolated from one measured step, so it is a lower bound; carbon measurements use a local grid intensity of 56 gCO2/kWh.Source: §3.1 · p. 3

3.2 Results

  • Chronos-2 is one order of magnitude more carbon-intensive at inference than both supervised baselines, while PatchTST exceeds the plotted range within months or a few dozen assets.The PatchTST comparison assumes training per asset; sharing it across similar assets would not scale its training cost with asset count.Source: §3.2 · pp. 3–4, Table 1 · p. 3
  • At Na = 1,000, Chronos-2 becomes cheaper than LightGBM after 18 months; at 5,000 assets, in under 3 months; at 10 assets, not within 100 years.At 100 assets, break-even takes 180 months.Source: §3.2 · p. 4, Figure 1 · p. 4
  • At Na = 1,000, ZeroShot break-even ranges from 8 months under severe drift to 22 months under utopia; full fine-tuning shifts it later by roughly 6–8 months.The ZeroShot baseline and mild-drift break-even points are 18 and 20 months, respectively.Source: §3.2 · p. 4, Figure 2 · p. 4
  • For Chronos-2 ZeroShot versus LightGBM, under hourly requests it is cheaper within the first month, at baseline at 18 months, and under weekly requests only after 49 months.Inference frequency affects carbon cost more than how often the model is kept up to date.Source: §3.2 · p. 5, Figure 3 · p. 5

4 Model Compression with Pruning

The study uses gradient-free, structured block pruning to reduce Chronos-2 inference costs while preserving zero-shot forecasting performance. On the 25-task evaluation, one-block pruning slightly changes forecast scores and reduces measured compute costs by 6–9%.

4 Model Compression with Pruning

  • The study investigates whether structured pruning without fine-tuning can lower inference costs while maintaining zero-shot accuracy.Removing a block removes its time-attention, group-attention, and feed-forward sublayers together, so the study cannot isolate any one mechanism.Source: §4 · p. 5, §4.1 · p. 5

4.1 Problem setup

  • The pruning criterion ranks Chronos-2’s 12 encoder blocks by cosine similarity between each block’s input and output, averaged across context positions.For a chosen budget, the method removes the highest-ranked blocks together; the ranking is computed once on a calibration set and reused.Source: §4.1 · p. 5
  • Calibration uses six tasks, then tests removal budgets from zero to six blocks; final evaluation adds 19 tasks not used for calibration or selection.The evaluation covers 25 zero-shot tasks unseen during Chronos-2 pretraining and follows a single predefined test window per series in strict univariate mode.Source: §4.1 · pp. 5–6

4.2 Results

  • On six calibration tasks, removing one block raises aggregated MASE skill from 9.57% to 10.24%, while removing six drops it to −69.9%.The single-block configuration is retained because it is the only tested configuration that does not reduce aggregate skill relative to the full model.Source: §4.2 · p. 6, Figure 4 · p. 6

4.3 Full-scale evaluation

  • MASE skill score falls 1.12 points (about 5% relative), while WQL skill score rises 0.29 points after pruning one block on the 25-task evaluation.The comparison is between full Chronos-2 and the retained configuration, which has 7.9% fewer parameters.Source: §4.3 · p. 7, Table 2 · p. 7

4.4 Compute cost reduction

  • 6–9% reductions appear across parameter count, analytically computed FLOPs, measured CO2 emissions, and measured latency after removing one encoder block.Latency has the smallest relative reduction because data loading, tokenization, and CUDA synchronization contribute fixed overheads.Source: §4.4 · p. 7, Table 3 · p. 7

5 Conclusion

Chronos-2’s pretraining cost is amortized only in sufficiently large or frequently queried deployments, while removing one encoder block reduces operating costs with essentially no measurable loss in zero-shot performance. The appendix cost equations distinguish shared LoRA fine-tuning from full fine-tuning whose sample size grows with the number of assets.

5 Conclusion

  • At Na = 1,000 assets, Chronos-2 breaks even with LightGBM after about 18 months under daily inference; inference frequency alone shifts the threshold by up to 49×.A classical model remains cheaper indefinitely for a small number of assets.Source: §5 · p. 7
  • Removing one encoder block (7.9% of parameters) reduces FLOPs, CO2 emissions, and latency by 6 to 9%, at essentially no cost to zero-shot forecasting performance.Source: §5 · p. 7

A.2 Full cost equations

  • PatchTST follows the same cost logic as LightGBM but omits the H factor because it is natively multi-step.Source: §A.2 · p. 10
  • The LoRA cost equation adds periodic fine-tuning to the fixed pretraining cost, with a shared adapter whose cost does not depend on the number of assets.A first fine-tuning occurs at t = 0, then every Tft months.Source: §A.2 · p. 10
  • The full fine-tuning equation uses a sample from a fixed fraction of each asset’s data, so its fine-tuning sample size grows linearly with the number of assets.Source: §A.2 · p. 10

B Appendix 2: Measurement Protocol Details (cost model)

The appendix documents hardware and measurement choices, then estimates Chronos-2’s pretraining cost and tests how that estimate changes the break-even duration. It also specifies the separate raw-measure and per-unit cost tables and the protocol for pruning measurements.

Hardware and carbon intensity

  • Measurements use an A100 GPU and EPYC CPU; CPU power is estimated from TDP because virtual-machine RAPL counters were inaccessible, and carbon values scale with local grid intensity.When pretraining and deployment use the same grid, all costs scale together and break-even durations remain unchanged.Source: B Appendix 2: Measurement Protocol… · pp. 10–11

Estimating Cpr

  • Cpr is estimated as 65.17 gCO2 by extrapolating one measured pretraining step to 200,000 steps, using settings and a step count borrowed from Chronos T5-base.The estimate assumes a single GPU and is presented as a lower bound because real pretraining typically uses many GPUs in parallel.Source: B Appendix 2: Measurement Protocol… · p. 11

Sensitivity to Cpr

  • T* ≈ 18k months at Na = 1,000 as Cpr is multiplied by k; beyond 60×, no crossover is found within the 100-year search horizon.The pretraining-cost estimate is a lower bound, so the 18-month baseline break-even is described as optimistic for Chronos-2.Source: B Appendix 2: Measurement Protocol… · p. 11, Figure 5 · p. 11

Dataset and runs

  • Part I measurements use ETTh1, with 10 independent runs for training-related measurements and 20 inference runs, each averaging 1,000 calls.LightGBM and PatchTST training lengths are fixed at 300 estimators and 20 epochs, respectively.Source: B Appendix 2: Measurement Protocol… · p. 12

Measurement tables

Cost measurements for pruning

  • Pruning costs are measured on the same fixed 25,411-window subset for both models, with CO2 averaged over five repetitions, latency over 200 timed calls, and FLOPs for one forward pass.Training FLOPs for PatchTST and Chronos-2 are estimated as three times forward-pass FLOPs; LightGBM FLOPs are computed analytically.Source: B Appendix 2: Measurement Protocol… · pp. 11–13

C Appendix 3: Cost Model Results

Figure 6 presents the baseline break-even usage duration as a function of the number of assets.

C.1 Figures

  • Figure 6 plots break-even usage duration in months against the number of assets for Chronos-2 ZeroShot versus LightGBM under the baseline scenario.Source: Figure 6 · p. 14

D Appendix 4: Model Pruning

The pruning appendix tests whether cosine-based block rankings distinguish redundant from critical encoder blocks, and places the calibration checks alongside task-level comparisons of the full and pruned models. The reported evaluation covers 25 Chronos Benchmark II tasks after excluding the two ETT variants.

Clarification and additional ablation

Additional checks

  • The ablation checks remove block 11 and block 5 individually and evaluate both on the same six calibration tasks.Block 5 is ranked close to block 6, with cosine scores of 0.954 and 0.963, respectively.Source: D Appendix 4: Model Pruning · p. 15

Clarification and additional ablation

Evaluation scope

E.1 Carbon cost modeling

The carbon-cost comparison depends on bounded measurement and modeling choices, including hardware-specific accounting and a lower-bound estimate of Chronos-2 pretraining cost.

E.1 Carbon cost modeling

  • Carbon measurements use one hardware setup, ETTh1, and a grid intensity of approximately 56 gCO2/kWh, so absolute values are scenario-specific.The authors caution that values would differ on other hardware, datasets, or regions.Source: §E.1 · p. 18
  • CPU power is estimated from TDP rather than measured because RAPL counters were inaccessible, disproportionately affecting LightGBM under the assumed production CPU setting.The fallback affects every measurement that uses it.Source: §E.1 · p. 18
  • Chronos-2 pretraining cost is extrapolated from one measured step and documented Chronos T5-base step count, making it a single-GPU lower bound.Chronos-2’s own pretraining schedule and infrastructure are undisclosed; a real run would likely use distributed computing.Source: §E.1 · p. 18
  • LightGBM and PatchTST are costed per asset, while Chronos-2 shares one LoRA adapter across assets, so the comparison does not provide equal informational access.Sharing PatchTST across similar assets could make it much cheaper than reported; a matched comparison requires a separate measurement campaign.Source: §E.1 · p. 18
  • LightGBM and PatchTST use fixed, untuned training budgets with no search cost, which favors the baselines; LightGBM cost also varies with estimator count.A search over K configurations would add roughly K training runs per tuned model, while Chronos-2 zero-shot requires none.Source: §E.1 · p. 18
  • Cost-model parameters came from an earlier measurement campaign, and Chronos-2 CPU inference showed unusually high, unexplained run-to-run variance.The CPU inference measurement is reported as measured but should be treated with more caution than the rest of Table 6.Source: §E.1 · p. 18

E.2 Pruning

The pruning evaluation has boundaries in benchmark coverage, measurement scope, and what can be inferred about the block-selection criterion.

E.2 Pruning

  • The evaluation covers 25 of Chronos Benchmark II’s 27 tasks because two ETT tasks were incompatible with the current datasets library.The excluded tasks are ETT 15-min and ETT hourly.Source: §E.2 · p. 18
  • Pruning removes each encoder block’s time-attention, group-attention, and feed-forward sublayers together, so their individual contributions cannot be isolated.The authors therefore cannot identify which specific mechanism drives the observed redundancy or performance impact.Source: §E.2 · p. 18
  • At each compression level, only the blocks selected by the cosine ordering are evaluated, so the study does not establish that these are the best blocks to remove.The authors conclude only that the resulting configuration performs well in absolute terms.Source: §E.2 · p. 18
  • Experiments use strict univariate mode and do not test pruning’s effect on cross-series in-context learning, which depends on batch composition.That capability is engaged only in cross-learning mode.Source: §E.2 · p. 19
  • CO2 and latency use a 25,411-window task subset rather than the full performance set, and cost measurements use one machine with one deterministic performance run per configuration.The cost subset is not identical to the set used for the Table 2 performance evaluation.Source: §E.2 · p. 19
  • The lightweight, gradient-free cosine heuristic was not compared with alternative pruning criteria, so the paper does not claim it is the most effective available method.The authors report that it yields a configuration with no measurable aggregated performance loss on this benchmark.Source: §E.2 · p. 19

NeurIPS Paper Checklist

The checklist reports that the paper’s claims match its scope and that reproduction details and compute resources are provided, while noting that the pruning performance comparison lacks a formal significance test.

NeurIPS Paper Checklist

  • The authors answer that the paper’s main claims reflect its contributions and scope, and that limitations are discussed.The limitations discussion is identified in the appendix.Source: NeurIPS Paper Checklist · pp. 20, 23
  • The authors say the work includes no theoretical results, and that LLMs were used only for writing, editing, or formatting.Source: NeurIPS Paper Checklist · pp. 21, 26
  • The authors report sufficient reproduction details, but code is not open-access while the data are accessible.They point to Appendix B for the carbon-cost model and Section 4.1 for pruning setup details.Source: NeurIPS Paper Checklist · pp. 21–22
  • The checklist answer on statistical significance is no: pruning performance is reported with point estimates and no formal significance test, while carbon and latency measurements include standard deviations.The authors also report a Wilcoxon signed-rank test for the block-11 redundancy analysis.Source: NeurIPS Paper Checklist · p. 22
  • The authors answer that computer-resource information is provided for the experiments.Source: NeurIPS Paper Checklist · p. 23
  • The checklist reports compliance with the NeurIPS Code of Ethics and identifies environmental impacts, including pruning’s reported 6–9% reduction in inference-time emissions.Source: NeurIPS Paper Checklist · p. 23

Related papers

Loading 2610.32859v1…