Anomaly Detection at 150M Series — Online, Generalized, No Data Retention
A generalized anomaly-detection model that (a) is tuned per series quickly, (b) does not require storing the raw data beyond one "kick-start," and (c) evolves online as new points arrive. Data lives in InfluxDB (~150M unique series, not rows).
0. TL;DR / Bottom Line
-
The single most important finding: pretrained time-series foundation models (MOMENT, Chronos, TimesFM, Time-MoE, TSPulse) are weak at zero-shot anomaly detection — in independent benchmarks they do not beat trivial "one-liner" statistical baselines (moving-window variance / squared difference) (ONE-LINERS, ICLR 2026; arXiv 2412.19286). Do not build the system around the hope that an off-the-shelf foundation model will detect anomalies well. Use it as a feature extractor / initializer, and get accuracy from per-series adaptation.
-
Your two constraints are in tension if taken absolutely. Online anomaly detection requires a model of "normal." If you store no data, the model state itself becomes the only memory of normal. The resolution is: don't store raw series, but DO keep a small bounded per-series state (rolling sufficient statistics, seasonal coefficients, an anomaly threshold, and optionally a tiny adapter/embedding). Every detected anomaly is scored against that compressed summary.
-
Recommended architecture = two tiers:
- Tier 1 (generalization): a shared/global model pretrained once on the 150M-series kick-start — used as a representation extractor / meta-prior (the "generalized" part).
-
Tier 2 (tuning + evolution): a per-series, online, bounded-memory detector with an adaptive threshold (Extreme Value Theory / SPOT-POT on the residual stream) that is updated incrementally as each new point arrives (the "tuned per series" + "evolves" part).
-
150M per-series states is a feasibility problem. Keep per-series state tiny (hundreds of bytes to a few KB), prefer closed-form O(1) online updates, and use a tiered/filter stage (cheap statistical detector scores every point; a heavier model runs only on flagged windows).
-
You cannot feasibly hand-tune 150M detectors. Tuning must be learned: the global model predicts/instantiates per-series detector parameters (a meta-learning / hypernetwork pattern), and online updates keep them fresh.
1. Constraints restated
- 150M unique series — the "many-series" regime. Any per-series cost (params, compute, state) is multiplied by ~1.5×10⁸.
- Kick-start only — full historical data available once (for the initial/training pass); afterwards the raw data should not be retained.
- Generalized model, tunable per series, quickly — want a single model family that adapts to each series cheaply, not 150M hand-built models.
- Evolves with new data — online/incremental (streaming) learning, not periodic offline retraining on stored history.
2. Key finding: foundation models are not great anomaly detectors out of the box
2.1 The evidence
-
ONE-LINERS (ICLR 2026), "When Foundation Models are One-Liners" evaluates MOMENT, Chronos, TimesFM, Time-MoE, and TSPulse on anomaly detection: zero-shot performance does not significantly differ from simple one-line baselines (moving-window variance for reconstruction-based, squared difference for forecasting-based). Regardless of family or size. Root cause identified: the assumption that "anomalies are harder to reconstruct/forecast" does not hold for these models. Source: OpenReview — One-Liners; companion benchmark repo necdetduruk/tsfm-anomaly-bench.
-
arXiv 2412.19286, a separate critical evaluation across five manufacturing/space datasets: traditional statistical (weighted XGBoost) and deep (autoencoder) models match or outperform TSFMs on anomaly detection/prediction, while TSFMs are far more computationally expensive and do not help in few-/zero-shot. Source: arXiv 2412.19286.
-
MOMENT is the notable positive counter-example, but modest and adaptation-dependent: zero-shot AD = "second best F₁", but with linear probing (fine-tuning the final layer) it reaches best F₁ — i.e., the value shows up after adaptation, not zero-shot. Source: MOMENT README (ICML 2024, arXiv 2402.03885).
-
TimesFM (Google, 200M/2.5) is a forecasting model with no built-in anomaly detection; AD is done by flagging points outside quantile forecast bands. HuggingFace/PEFT (LoRA) fine-tuning example exists. Source: google-research/timesfm.
2.2 Implication
The "generalized" value of foundation models here is transferable representation learning, not built-in detection. That strongly favors the two-tier split: a shared representation/encoder (pretrained on the kick-start) + a lightweight per-series detector that is actually where detection happens.
3. Recommended two-tier architecture
Tier 1 — the "generalized" model (pretrained once on the kick-start)
Train/share one model over the full 150M-series kick-start. Candidate roles:
-
Representation/feature extractor — e.g., an autoencoder or a TSFM used as an encoder. Detection then operates on reconstruction/forecast error (anomaly score = residual magnitude). Demonstrated by the ChronosAD line of work ("Leveraging Time Series Foundation Models for Accurate Anomaly Detection") and CHARM, which use TSFMs specifically as feature extractors for AD. Sources: ChronosAD, arXiv 2606.01300; Chronos repo.
-
Meta-learner / hypernetwork — the global model outputs the per-series detector's parameters or hyperparameters, so "tuning" becomes an inference call rather than a hand-rolled optimization. This is the pattern that scales "tuned per series quickly" to 150M. Sources: iADCPS — incremental meta-learning for evolving CPS time-series AD, arXiv 2504.04374; Meta-Learning for Fast Model Recommendation, NeurIPS/HLMR 2023.
Tier 2 — the per-series online detector (the "tunable" + "evolves" part)
Per series, keep a tiny bounded state and update it O(1) per point:
- Online mean/variance / EWMA control-chart anomaly detection (e.g., AnEWMA), adapted incrementally with no batch retraining and little history. Source: AnEWMA — SCITEPRESS paper.
- Seasonality handled via online seasonal decomposition or per-series seasonal coefficients (e.g., Holt-Winters style), so contextual/seasonal anomalies are caught.
- Adaptive threshold via Extreme Value Theory (EVT) — SPOT / POT compute a high quantile from the residual stream to set the anomaly threshold dynamically, with no manual threshold and no strong distribution assumptions, and no meaningful historical retention. Sources: SPOT — libspot; Anomaly Detection in Streams with Extreme Value Theory, KDD 2017.
- Continuous-learning streaming detectors as a more expressive drop-in, e.g., Numenta HTM (learns continuously, real-time, unsupervised) and streaming-first libraries (ABERRANT, StreamAD). Sources: Numenta HTM paper; NAB benchmark; ABERRANT; StreamAD, GitHub.
The typical detection loop is: score(point | state) → compare to adaptive threshold → update(state, point) (assuming normal) — i.e., exactly an online "score-and-adapt," which matches "evolves whenever new data is available."
4. The "don't store data" constraint — what it really means
- You can't avoid some memory of normal. Online AD needs a model of normal; the model weights + compact sufficient statistics are that memory. What you can avoid is storing raw historical series. Keep each series' state bounded (e.g., a short in-memory rolling window + summary stats), not exhaustive history.
- Hard trade-off: the less history you retain, the worse you detect slow / concept-drift / regime anomalies versus point anomalies. Point anomalies are cheap (a threshold on a residual). Slow or seasonal-shift anomalies may need a longer implicit context (which is, effectively, stored data). Decide which type you actually care about. NAB (Numenta) explicitly notes AD is hard to benchmark precisely for exactly this reason (Source: NAB, arXiv 1510.03336).
- Catastrophic forgetting / drift: pure online learning without replay can forget older regimes. Literature handles this with incremental coresets / experience replay (e.g., ONER, CADIC). For point-anomaly detection a robust online estimator + adaptive threshold is fairly resilient, but if you must detect drift/regime change you'll want a drift detector or a small buffered normal profile. (Review of incremental/continual AD methods — arXiv preprints 2511.08634, 2412.03907, 2201.06763.)
- Key subtlety worth flagging: the phrase "the model should evolve whenever new data is available" + "don't store data" is internally coherent only if the evolution is online state update, not offline rebatching over stored history. All the recommended options above are online-state-update.
5. Scaling to 150M series — feasibility math
| Per-series state S | Live memory for 150M series |
|---|---|
| 512 B | ~77 GB |
| 1 KB | ~150 GB |
| 4 KB | ~600 GB |
| 1 MB | ~150 TB |
- State budget is the first design decision. With hundreds of bytes to a few KB per series you can hold all 150M detectors in ~100 GB–600 GB of distributed memory; anything larger (e.g., a per-series deep network) becomes infeasible at this count.
- Prefer O(1) closed-form updates (EWMA, seasonal coefficients, EVT quantile updates) so per-point cost is essentially constant and CPU-throughput-bound, not learning-bound.
- Two-stage filtering to keep compute bounded: run the cheap statistical detector on every point of every series; escalate to the heavier shared model (Tier 1) only on a window flagged as suspicious. This decouples the 150M-scale "always-on" cost from the expensive-model cost.
- Tuning at scale is not manual. 150M series can't be individually tuned by hand; the Tier-1 global model should generate per-series settings (meta-learning / fast model recommendation), with online updates refining them (Source: Meta-Learning for Fast Model Recommendation).
- Where it runs with InfluxDB: InfluxDB's stack is batch/stream-oriented; Kapacitor is InfluxData's streaming engine with an
alertnode and User-Defined Functions (UDFs) for custom anomaly algorithms applied to incoming points — a natural host for the online per-series scorer if it must stay inside the Influx ecosystem. (Source: Kapacitor docs.) Alternatively run a stream processor (Flink/RisingWave/etc.) that reads new points from InfluxDB, updates per-series state, and writes alerts back.
6. Options matrix (complexity → expressiveness)
| Approach | Per-series state | Storage | Compute | Generalization | Best for |
|---|---|---|---|---|---|
| Online stats + adaptive threshold (EWMA/seasonal + SPOT/POT) | tiny (bytes–KB) | none (raw) | O(1)/point | low (per-series params) | 150M point-anomaly detection, cheapest |
| Shared autoencoder/TSFM encoder + online detector on residuals | small head + pretrained encoder | none (raw) | encoder is the cost | high (shared repr.) | generalizing "normal shape" across series |
| Foundation model + per-series LoRA/PEFT adapter | adapter (KBs) per series | accum. adapters | moderate–high | very high | best fidelity, but 150M adapters accumulate |
| Global meta-learner / hypernetwork emitting per-series params | tiny, params predicted | none (raw) | inference | high | automated per-series tuning at scale |
(Adapters/PEFT context: TimesFM ships a LoRA fine-tuning example — timesfm finetuning dir; PEFT discussion for TSFMs — tsfm.ai blog.)
7. Recommendations (pragmatic path)
- Reframe the goal as reconstruction/forecast residual + adaptive threshold, not "a foundation model that detects anomalies." Accuracy comes from the residual stream and a good dynamic threshold.
- Use the kick-start to train one shared representation / meta-prior over the 150M series (a TSFM or autoencoder as an encoder, or a meta-learner). This is the only place full data is needed.
- Deploy a tiny online per-series detector (online stats + EVT adaptive threshold) with bounded in-memory state only — no raw-series retention. This satisfies "evolves with new data" and "no data stored."
- Buy down scale risk with the tiered/filter design so only suspicious windows hit the expensive shared model.
- Validate on a representative stratified sample of tens–hundreds of series — you can never hand-inspect 150M — and use that sample to set Tier-1 hyperparameters and the meta-tuning objective.
- Run it as a stream update (Kapacitor UDF or a stream processor) integrated with InfluxDB, rather than offline batch retraining.
8. Caveats on evidence
- The strongest claims (One-Liners; arXiv 2412.19286) are preprint / in-review sources; the vendor-documented workflows (MOMENT tutorial, BigQuery/TimesFM) present usage examples, not independent benchmark wins. Treat "foundation models beat baselines at AD" as not established; treat "foundation models are useful as feature extractors + after adaptation" as the safer claim.
- Most comparison studies focus on zero-shot; fine-tuned/adapted TSFMs are consistently the more favorable regime — consistent with the two-tier recommendation.
- Exact end-to-end systems at 150M series, online, with no retention were not found in the literature as a single turnkey product; the design above is assembled from the best-supported building blocks rather than one proven system.
References
- One-Liners (ICLR 2026): https://openreview.net/pdf?id=H27kvyG4qf · bench https://github.com/necdetduruk/tsfm-anomaly-bench
- Critical TSFM-AD evaluation: https://arxiv.org/html/2412.19286v1
- MOMENT: https://github.com/moment-timeseries-foundation-model/moment / https://arxiv.org/abs/2402.03885
- TimesFM: https://github.com/google-research/timesfm · Chronos: https://github.com/amazon-science/chronos-forecasting / https://doi.org/10.48550/arxiv.2403.07815
- ChronosAD (TSFMs as feature extractors): https://arxiv.org/html/2606.01300v1
- iADCPS (incremental meta-learning, online update, dynamic threshold): https://arxiv.org/abs/2504.04374
- Meta-Learning for Fast Model Recommendation: https://proceedings.mlr.press/v224/navarro23a.html
- SPOT / Extreme Value Theory streaming AD: https://asiffer.github.io/libspot/ · KDD17: https://www.kdd.org/kdd2017/papers/view/anomaly-detection-in-streams-with-extreme-value-theory
- AnEWMA: https://www.scitepress.org/Papers/2025/134378/134378.pdf
- Numenta HTM (continuous online learning): https://www.numenta.com/resources/research-publications/papers/unsupervised-real-time-anomaly-detection-for-streaming-data/ · NAB: https://github.com/numenta/nab / https://arxiv.org/pdf/1510.03336
- Streaming AD libraries: ABERRANT https://github.com/OliverHennhoefer/aberrant · StreamAD https://github.com/Fengrui-Liu/StreamAD
- Continual/incremental AD (forgetting/drift): https://arxiv.org/abs/2201.06763 · https://arxiv.org/html/2412.03907v2 · https://doi.org/10.48550/arxiv.2511.08634
- InfluxDB/Kapacitor (InfluxData streaming engine, alert + UDFs): https://docs.influxdata.com/kapacitor/v1/
Comments
No comments yet.