I tried running NVIDIA's time series foundation model NV-Tesseract on DGX Spark after it was released as open source
This page has been translated by machine translation. View original
Introduction
Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Department.
NVIDIA has released the time series foundation model NV-Tesseract as open source on GitHub under Apache 2.0. The Hugging Face model weights (nvidia/nv-tesseract-forecasting / nvidia/nv-tesseract-ad-diffusion) are also publicly distributed and can be run as-is without an HF token.
I had previously covered NV-Tesseract in Comparing Time Series Foundation Models on DGX Spark (2026-05-25), alongside Chronos-2 and TimesFM 2.5. At the time it hadn't been publicly released, so the article was limited to introducing official information and Cognite's Celanese case study. Now that it has been released as OSS and can be run locally, I've organized my logs from running it on DGX Spark (NVIDIA GB10, aarch64, Blackwell sm_121).
What is NV-Tesseract
NV-Tesseract is NVIDIA's time series foundation model library, described briefly in the repository as an open-source time series analysis library covering forecasting and anomaly detection. It takes the stance of providing both "time series forecasting" and "anomaly detection" in a single library.
The repository is broadly composed of two modules.
| Module | Role | Key Technologies |
|---|---|---|
forecasting/ |
Multivariate time series forecasting + context enrichment + interpretability | MOMENT-1-large encoder + forecasting head, DARR mode, Lag-Horizon Attribution |
ad_diffusion/ |
Diffusion model-based anomaly detection | Fast sampling via DPM-Solver, adaptive thresholding with SCS / MACS, multi-GPU support |
There is also an ad_transformer/ module in the repository for univariate anomaly detection and classification, but as of now it contains only a placeholder with no implementation. Looking forward to its future release.
Forecasting Module
Looking at the nvidia/nv-tesseract-forecasting model card on Hugging Face, the base is MOMENT-1-large (a Transformer encoder with approximately 340 million parameters), and it is designed to train only the forecasting head while keeping the encoder and embedder weights frozen. Supported sequence lengths are 256 / 512 / 1024 / 2048, and the training data reportedly includes 3 million data points from sources such as the Monash Time Series Forecasting Archive, ECL, Traffic, and ETTh.
A distinctive feature is DARR (Domain-Aware Representation and Retrieval) mode, which retrieves similar past patterns via kNN and blends them into the forecast. It is designed to appeal to use cases where you want to tune per line but don't want to retrain the model each time.
Another feature is the Lag-Horizon Attribution Matrix, an interpretability function. When called with interpretability=True, it outputs how much each past lag contributed to each forecast timestep, in both JSON and a visual PDF report.
AD-Diffusion Module
The ad_diffusion/ side is diffusion model-based anomaly detection, tracing its lineage to Memory-Augmented Forecasting / SCS (Segmented Confidence Sequences) from IEEE BigData 2025. When you feed multivariate time series directly, it returns per-row anomaly scores (MAE-based).
The detection philosophy differs from the "measure by forecast residuals" approach (Chronos-2 / TimesFM family) — since it accepts multivariate input directly and returns MAE per row, there is no need to hand-craft residual design, sliding windows, or PCA aggregation. This reduces implementation cost when building pipelines that need to immediately report point anomalies.
Sampling is compressed to approximately 20 steps using DPM-Solver (Lu et al., 2022, vendored under MIT license as third_party/dpm-solver), making it relatively fast for a diffusion model. Thresholds are adaptively determined by SCS / MACS (Multi-Scale Adaptive Confidence Segments), which automatically adjusts thresholds according to the data.
The Main Battleground
To understand the design philosophy of NV-Tesseract, it is important to grasp its intended main battleground. The officially promoted Cognite × NVIDIA integration case study (reactor water level prediction for chemical and specialty materials company Celanese) is symbolic — the primary target is industrial plants handling massive multivariate data on the order of hundreds to thousands of sensors. The details of this case study were introduced in my previous article, so this article will focus on running it locally.
License and Distribution
The license is Apache 2.0, and LICENSE / NOTICE / THIRD_PARTY_LICENSES.md are properly managed. One thing to note: while the Hugging Face model card body states Apache 2.0, it also includes an operational note saying "research and development only," so it is safer to confirm with NVIDIA before adopting it in production (the license file itself is Apache 2.0 with conditions that allow commercial use, and the note may be indicating a recommended scope of use).
Running on DGX Spark aarch64
From here, I'll share the logs from actually running this on DGX Spark. The verification environment is as follows.
| Item | Value |
|---|---|
| Hardware | DGX Spark (NVIDIA GB10, aarch64, 128GB UMA) |
| Kernel / Driver | Linux 6.17.0-1021-nvidia / NVIDIA driver 580.159.03 |
| CUDA | 13.0 |
| Python | 3.12.3 |
| Package manager | uv 0.11.22 (aarch64-unknown-linux-gnu) |
| Verification commit | 1231541 (repository 2.8 MB) |
Setup follows the official README — just git clone and run uv sync for each module.
git clone https://github.com/NVIDIA/NV-Tesseract.git
cd NV-Tesseract
# venv for forecasting
cd forecasting
uv sync --python 3.12
cd ..
# venv for ad_diffusion
cd ad_diffusion
uv sync --python 3.12
forecasting/ and ad_diffusion/ are each configured to have independent venvs, with torch dependency specifications managed separately. This difference in dependency specifications turned out to be the deciding factor in whether the GPU could be used, as described below.
Running forecasting/sdk/quick_example.py
For verifying the forecasting side, the bundled forecasting/sdk/quick_example.py is self-contained. It is a sample that sequentially runs three modes against the bundled ETTh-style data: standard forecasting, DARR mode, and interpretability mode.
cd forecasting
uv run python sdk/quick_example.py
When executed, three files — standardizer.pkl / moment_head_512_6hr.pt / run8_best_model_cr.pt — are auto-downloaded from Hugging Face, and forecast CSVs are output for each mode. When interpretability mode is enabled, explanation.json + explanation_report.pdf + lag_horizon_*.csv are generated under sdk/interpretability_output/run_<timestamp>/, visualizing the contribution of each lag to each forecast timestep.
However, at the time of verification (commit 1231541), it took 6 minutes and 5 seconds on my machine. Investigating the reason, I found that in forecasting/pyproject.toml at the time, torch was specified as >=2.0.0 and pinned to torch==2.4.0 via mac-mps extras, causing the general PyPI build of torch==2.4.0 to fall back to CPU for aarch64 + Blackwell. Checking torch.cuda.is_available() returned False, meaning the GB10's GPU was not being used.
>>> import torch
>>> torch.cuda.is_available()
False
>>> torch.__version__
'2.4.0+cpu'
The fix is to relax the torch dependency range on the forecasting side to torch>=2.10.0 and point to the cu130 wheel index, which enables GPU operation (torch 2.12.1+cu130 recognizes sm_121). Re-running quick_example.py in this state completed in 19 seconds with weights already cached — approximately 19x faster than the 6-minute 5-second CPU fallback, showing just how much a single dependency specification can matter. On the ad_diffusion side (described below), the dependency range is torch>=1.13.0 without pinning, which means the GPU was already being used — further confirming this was a dependency specification issue.
Incidentally, PR #24 from the community (relaxing to torch>=2.7.0 + removing the mac-mps pin) was addressing this issue, and I also commented with GB10 operation data. It was merged into upstream while I was writing this article (2026-07-03). After doing a fresh clone of the merged main and trying from a clean uv sync, torch 2.12.1+cu130 was resolved and the GPU was recognized immediately, with quick_example.py completing in a similar 17 seconds with weights already cached. Anyone trying this from now on won't run into this pitfall.
Running ad_diffusion/examples/quick_example.py
For the ad_diffusion side, run ad_diffusion/examples/quick_example.py. It auto-generates sample_timeseries.csv (500 samples × 3 sensors) and is a sample that performs anomaly detection using DPM-Solver with 20 steps + SCS adaptive thresholding.
cd ad_diffusion
uv run python examples/quick_example.py
This worked completely without any modifications on CUDA 13 + sm_121 (Blackwell). With torch 2.11.0+cu130 + triton 3.6.0, torch.cuda.is_available() = True and torch.cuda.get_device_capability() = (12, 1) were returned, and inference ran on the GPU.
Execution time was 34 seconds, with the breakdown approximately as follows.
| Phase | Time |
|---|---|
| Weight download from Hugging Face | 5 seconds |
| Synthetic data generation | A few seconds |
| DPM-Solver 20-step inference | 26 seconds |
| Post-processing + result output | A few seconds |
500 samples × 3 sensors in 26 seconds works out to approximately 52 ms/sample. 16 out of 500 samples (3.20%) were detected. Since the ground truth labels are also auto-generated along with the synthetic data in this demo, the accuracy figures are preliminary pending evaluation on real data, but this is sufficient to get a feel for the speed of point anomaly detection.
Addendum (2026-07-06): Also Ran on the Official Test Dataset
At the time of the verification commit in the main text, only synthetic data auto-generation was available, but the current main now includes an official test dataset for ad_diffusion: examples/datasets/test-dataset.csv (a univariate CSV with 500 samples). I took the opportunity to do a fresh clone of the latest main (commit 9b31ca4) and run it again from a clean uv sync.
cd ad_diffusion
uv sync
uv run python examples/quick_example.py --dataset-path examples/datasets/test-dataset.csv
Even in an environment without an HF token configured, the weights final_model.pth were auto-downloaded from the public repository. The entire execution took 36 seconds, with the DPM-Solver 20-step inference completing in 26 seconds. The detection results were 15 detections out of 500 samples (3.00%), with a mean MAE score of 0.948 and a maximum of 1.324. At approximately 53 ms/sample, the speed is nearly identical to the measured performance on synthetic data in the main text.
One thing to note: since the custom CSV has no ground truth, Precision / Recall / F1 evaluation is skipped. This behavior is also explicitly stated in the repository's README. Also, looking at the execution log, the sequential ts column was being counted as an analysis target channel, so when passing real data, it would be best to drop numerical timestamp columns such as epoch seconds or sequential numbers beforehand.
What to Look at for Business Use
Having now been able to run NV-Tesseract hands-on for the first time, it is easy to understand from a business evaluation perspective by looking at three axes: degree of tuning freedom, domain adaptation, and interpretability.
Fine-Grained Tuning with Hyperparameters
Inference parameters and post-processing can be finely adjusted to fit your use case. The measured 52 ms/sample is with default settings, and for AD-Diffusion there is still room to optimize through DPM sampling step count, FP8 / INT8 quantization, and batching. The ability to write your own thresholding, windowing, and post-processing aggregation and align it to the same evaluation axes as Chronos-2 / TimesFM is also the kind of freedom that comes with OSS.
Improving Accuracy with Domain Adaptation (Fine-Tuning)
examples/finetune_example.py is bundled for both forecasting and ad_diffusion, with standard support for warm-starting the Cross-Channel head (run8_best_model_cr.pt). When comparing foundation models side by side on public benchmarks (mild general-purpose time series like ETTh1), raw win/loss can be close, but even if you lose there, the option exists to fine-tune on your own domain data to tailor it to your target use case. As mentioned earlier, NV-Tesseract's intended main battleground is large-scale multivariate sensor data, so rather than forcing a comparison on general benchmarks, the design lends itself better to showing its true nature through domain adaptation comparisons.
Meeting Accountability Needs with Interpretability Reports
As seen in the forecasting quick_example, simply adding interpretability=True produces lag contribution data as JSON and PDF reports. In manufacturing floor settings where you need to explain "why this forecast was made," being able to output interpretability materials alongside model outputs is a strength. With standalone foundation models like Chronos-2 / TimesFM 2.5, you would need to separately set up SHAP or attention visualization, and this difference matters in practice.
Summary
NV-Tesseract has now been released as OSS under Apache 2.0, provided in a form where everything is in place — public Hugging Face distribution, bundled examples/finetune_example.py, and interpretability via Lag-Horizon Attribution. I was able to confirm that both forecasting and ad_diffusion can be run on actual DGX Spark hardware, and it has joined the lineup of time series foundation model options.
Looking at the broader NVIDIA ecosystem, a three-tier architecture is now taking shape: DAQIRI (an I/O platform for zero-copy streaming from sensors to GPU memory) at the data acquisition layer, external platforms like Cognite Data Fusion at the data infrastructure layer, and NV-Tesseract at the inference layer. The vision of building a "sensor → zero-copy GPU transfer → time series inference → knowledge graph integration → agent automation" pipeline in a single stack for manufacturing floors is becoming increasingly realistic, catalyzed by this OSS release.
Reference Links
NVIDIA Official
- NVIDIA/NV-Tesseract GitHub Repository
- Hugging Face: nvidia/nv-tesseract-forecasting
- Hugging Face: nvidia/nv-tesseract-ad-diffusion
- New NVIDIA NV-Tesseract Time Series Models (NVIDIA Developer Blog)
- NVIDIA DAQIRI — Sensor → GPU zero-copy I/O platform
Cognite × NVIDIA Integration
- Cognite and NVIDIA Operationalize NV-Tesseract to Transform Industrial Forecasting (announced 2026-03-16, with Celanese case study)
