NVIDIA's Kumo Anomaly keeps the anomaly score apart from the flag. Here is how it works, what people miss, and how to check it on your own data.
A note on how this was written: an AI writing assistant drafted it from the source listed at the end, and every claim was checked against that source before it went out.
At a glance
- Kumo Anomaly is an open model from NVIDIA that finds odd behavior in time series with many columns.
- It returns a score for every row and, separately, a yes or no label, so you can see both steps of the decision.
- The part I'd test first is the threshold: two methods, SCS and MACS, decide when a score is high enough to flag.
Most alerts fail at the threshold, not the model
You have probably seen a monitoring dashboard that flags everything or flags nothing. What fails is the rule that turns a score into an alert.
So when I read NVIDIA's post about Kumo Anomaly, published October 21, 2026, one design choice stood out. The model gives you the score and the alert as two separate outputs. It doesn't hand you a yes or no and leave you guessing how it got there. Below I go through what that means, how the model works, and how I'd check it before trusting it.
What Kumo Anomaly is
Kumo Anomaly (it used to be called NV-Tesseract AD-Diffusion) is a model for finding anomalies in multivariate time series. That means data with many columns measured over time, like a machine with several sensors or a service with several health metrics.
According to the post, it has about 8 million parameters and comes under the Apache 2.0 license. The code is in a repo called NVIDIA/Kumo-TS, and the weights are published as nvidia/Kumo-Anomaly.
Its input is a table of time series observations. Its output is the same table with two more columns: a mean absolute error (MAE) anomaly score and a binary anomaly label for each row. I like that kind of interface because nothing is hidden. Your original data stays next to what the model said about it.
Why an odd row isn't always an odd number
The post makes a point I wish more monitoring tools took seriously. Anomaly detection isn't only about finding strange values. With many columns, a reading can be unusual because of when it happens, because of how it relates to the other measurements, or because the whole system has started to behave differently.
Here is a made up example to show the idea. Picture a pump with three sensors: temperature, pressure and flow. Every single reading falls inside its normal range. But pressure is climbing while flow stays flat, and on this pump those two usually move together. A check that looks at one column at a time sees nothing. A model that learned how the columns move together should notice that the relationship broke.
That is the kind of problem the post says Kumo Anomaly is built for: noisy data with many columns that changes over time and has rare, irregular events.
How the diffusion part works
Diffusion models are better known for making images, but the core idea carries over. In training, the model takes clean data, adds controlled noise to imitate missing values, and learns to undo that noise to get back the original.
When it runs on new data, it uses that skill to fill in values step by step. For anomaly detection there is a trick: it fills in every value, including the ones it can already see, and then compares what it rebuilt with what really happened.
If the rebuilt value is close to the real one, the row looks like the normal patterns the model learned. If the gap is large, the row gets flagged as a possible anomaly. That gap is the MAE score.
In the pump example, the model would expect pressure to follow flow. When pressure rises and flow doesn't, its rebuilt pressure would sit far from the real reading, and the score for those rows would go up.
The post also says the training uses curriculum learning to keep it stable. The detailed method is in a paper named in the post, NV-Tesseract-AD: Curriculum-Enhanced Conditional Diffusion for Multivariate Time-Series Anomaly Detection.
Two questions, kept apart
To me this is the most useful idea in the post. Any anomaly pipeline has to answer two questions. First, how unusual is this row? Second, is it unusual enough to raise a flag?
Kumo Anomaly gives you the score for the first question and the label for the second. You can check each one on its own.
For the second question there are two thresholding methods. Segmented Confidence Sequences (SCS) split the series into stretches that are stable locally, each with its own baseline, and the bounds adjust inside each stretch. Multi-Scale Adaptive Confidence Segments (MACS) look at short, medium and long windows at once. An attention mechanism weighs the scale that matters most, and a dual detection rule cuts down false alerts.
Back to the pump. Say it goes through a startup phase where pressure always jumps around, then settles into a steady run. One fixed threshold either alarms on every startup or sleeps through the steady run. With SCS's local baselines, the startup stretch gets wider bounds and the steady stretch gets tighter ones. MACS is meant to catch both quick bursts and slow drifts without separate detectors.
What I think people will get wrong
The first mistake is reading the label and ignoring the score. The label is just one cut through the score. If you only look at yes or no, you can't tell a row that barely crossed the line from one far over it.
The second is assuming the training data looks like yours. The post says training mostly used TSB-AD-M, a benchmark of 198 curated multivariate time series from 17 public datasets, with an 80/20 split per dataset. That covers several domains and includes both point and sequence anomalies. It's a solid base. It still isn't your factory, your servers or your payments. A model that learned what normal looks like elsewhere has to be checked on what normal looks like for you.
The third is treating a high reconstruction error as proof that something is wrong. A big gap only means the row doesn't match what the model learned as normal. A planned maintenance window or a new product launch can look just like a fault. The score tells you where to look, not what you'll find.
Check it yourself
Start with a stretch of your own data where you already know when the real incidents happened. Write those times down before you run anything, so the model's output can't steer what you count as an incident.
Run the model and keep all its outputs: your original columns, the MAE score and the label for each row. Plot the score over time with your known incidents marked on it. Before you look at any labels, ask whether the score rises around the incidents and stays low when things were calm.
Then check the labels against the same incident list. For each known incident, did at least one row near it get flagged? For calm periods, how many flags showed up? Those calm period flags are the alerts your on call person would have gotten for nothing.
Run it again with the other thresholding method. Keep the score fixed in your head and see how the flags change between SCS and MACS. If one method flags far more rows during a known noisy phase, like a startup or a busy hour, that tells you which one fits your data.
Last, look at the rows with the highest scores that weren't incidents. Find out what they were. If they turn out to be planned events, you've learned something about your data. If you can't explain them, that is worth a closer look either way.
What I'm still unsure about
The post explains the method clearly, but in this write-up I only see what the model is designed to do. I haven't run it myself. How well the thresholds work on data far from the 17 public datasets is something each reader will have to measure.
I also want to know how much tuning SCS and MACS need in practice. The post describes both as unsupervised and as working with any model, which suggests you could even put them on top of a detector you already have. That is the part I'd test first.
This post was drafted with help from an AI model, working only from NVIDIA's post on Hugging Face. Every number and name here comes from that post.
When your alerts go wrong, is it usually the score or the threshold?
Top comments (0)