NVIDIA の時系列基盤モデル NV-Tesseract が OSS 公開されたので DGX Spark で動かしてみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

NVIDIA が時系列基盤モデル NV-Tesseract を GitHub 上に Apache 2.0 で OSS 公開しました。Hugging Face のモデル重み（nvidia/nv-tesseract-forecasting / nvidia/nv-tesseract-ad-diffusion）も public で配布されていて、HF token なしにそのまま動かせます。

https://github.com/NVIDIA/NV-Tesseract

NV-Tesseract については以前 DGX Spark で時系列基盤モデルを比べてみた（2026-05-25）の中で Chronos-2 / TimesFM 2.5 と並べて触れていました。当時は一般公開前だったため、公式情報と Cognite 社の Celanese 事例を紹介する読み物にとどまっていました。今回の OSS 公開で手元で動かせるようになったので、DGX Spark（NVIDIA GB10、aarch64、Blackwell sm_121）で動かしたログを整理してみました。

NV-Tesseract とは何か

NV-Tesseract は NVIDIA の時系列基盤モデルライブラリで、リポジトリ説明は短く an open-source time series analysis library covering forecasting and anomaly detection と書かれています。「時系列予測」と「異常検知」を 1 つのライブラリで提供するスタンスです。

リポジトリは大きく 2 つのモジュールで構成されています。

もう 1 つ、単変量異常検知 + 分類用の ad_transformer/ モジュールがリポジトリ的にはあるのですが、現状は placeholder のみで実装は入っていませんでした。今後の公開に期待です。

Forecasting モジュール

Hugging Face 上の nvidia/nv-tesseract-forecasting モデルカードを見ると、ベースが MOMENT-1-large（約 3.4 億パラメータの Transformer エンコーダ）で、エンコーダ・エンベッダの重みは固定したまま予測ヘッドだけを訓練する設計になっています。対応シーケンス長は 256 / 512 / 1024 / 2048 で、訓練データは Monash Time Series Forecasting Archive / ECL / Traffic / ETTh などを含めて 300 万データポイントとのこと。

特徴的なのは DARR（Domain-Aware Representation and Retrieval）モードで、kNN で過去の類似パターンを取ってきて予測にブレンドする仕組みです。「ライン毎にチューニングしたいけど都度モデルを再学習はしたくない」というユースケースに刺さる設計になっています。

もう 1 つが Lag-Horizon Attribution Matrix という解釈性機能。interpretability=True を指定して呼び出すと、各予測タイムステップに対して過去のどのラグがどれだけ寄与したかを JSON とビジュアル PDF レポートで出してくれます。

AD-Diffusion モジュール

ad_diffusion/ 側は拡散モデルベースの異常検知で、論文系譜としては IEEE BigData 2025 の Memory-Augmented Forecasting / SCS（Segmented Confidence Sequences）系統。多変量時系列を直接食わせると、行ごとの異常スコア（MAE ベース）を返してきます。

「予測残差で測る」発想（Chronos-2 / TimesFM 系）とは検出哲学が違って、多変量を直接受けて行ごとに MAE を返すので、残差設計・sliding-window・PCA 集約を自作する必要がありません。点異常を即時に通報したいパイプラインを組む場合、実装コストが下がります。

サンプリングは DPM-Solver（Lu et al., 2022、third_party/dpm-solver として MIT ライセンスで vendor 化）で 20 ステップ程度に圧縮されていて、拡散モデルとしては高速な部類です。閾値は SCS / MACS（Multi-Scale Adaptive Confidence Segments）で適応的に決まるので、データに応じて閾値を自動調整してくれます。

想定される主戦場

NV-Tesseract の設計思想を理解する上で押さえておきたいのが、想定されている主戦場です。公式が推す Cognite × NVIDIA の統合事例（化学・特殊材料企業 Celanese の反応槽水位予測）が象徴的で、数百〜数千センサー規模の巨大多変量データを扱う産業プラントが本命です。この事例の詳細は 前記事で紹介しているので、本記事では手元で動かす話に集中します。

https://dev.classmethod.jp/articles/dgx-spark-timeseries-fm-3-bench/

ライセンスと配布

ライセンスは Apache 2.0 で、LICENSE / NOTICE / THIRD_PARTY_LICENSES.md がきちんと管理されています。1 点注意があって、Hugging Face のモデルカード本文には Apache 2.0 と書かれているものの 「research and development only」という運用上の注意が併記されているので、本番採用時は NVIDIA に最終確認を取るのが安全です（ライセンスファイル自体は Apache 2.0 で商用 OK の条件、注意書きは推奨運用範囲のニュアンスなのかもしれません）。

DGX Spark aarch64 で動かしてみた

ここからは実際に DGX Spark で動かしてみたログです。検証環境は次のとおりです。

セットアップは公式 README のとおりで、git clone してモジュールごとに uv sync するだけです。

git clone https://github.com/NVIDIA/NV-Tesseract.git
cd NV-Tesseract

# forecasting 用 venv
cd forecasting
uv sync --python 3.12
cd ..

# ad_diffusion 用 venv
cd ad_diffusion
uv sync --python 3.12

forecasting/ と ad_diffusion/ はそれぞれ独立した venv を持つ構成になっていて、torch の依存指定も別々に管理されています。この依存指定の違いが、後述する「GPU を掴めるかどうか」の分かれ目になっていました。

forecasting/sdk/quick_example.py を回す

forecasting 側の動作確認は同梱の forecasting/sdk/quick_example.py で完結します。ETTh 系の同梱データに対して、標準予測 + DARR モード + 解釈性モードの 3 種類を順に走らせるサンプルです。

cd forecasting
uv run python sdk/quick_example.py

実行すると Hugging Face から standardizer.pkl / moment_head_512_6hr.pt / run8_best_model_cr.pt の 3 ファイルが auto-download され、それぞれのモードで予測 CSV が出力されます。解釈性モードを有効にした場合は sdk/interpretability_output/run_<timestamp>/ 配下に explanation.json + explanation_report.pdf + lag_horizon_*.csv が生成されて、各予測タイムステップに対するラグの寄与度が可視化されます。

ただし検証時点（コミット 1231541）では、手元で 6 分 5 秒かかりました。理由を調べてみると、当時の forecasting/pyproject.toml で torch が >=2.0.0 指定 + mac-mps extras で torch==2.4.0 にピン留めされていて、aarch64 + Blackwell では torch==2.4.0 の PyPI 一般ビルドが CUDA off になって CPU 落ちしていました。torch.cuda.is_available() で確認すると False が返ってきていて、これだと GB10 の GPU が使えていません。

>>> import torch
>>> torch.cuda.is_available()
False
>>> torch.__version__
'2.4.0+cpu'

対処としては、forecasting 側の torch 依存範囲を torch>=2.10.0 に緩めて cu130 wheel index を当てれば GPU 動作します（torch 2.12.1+cu130 で sm_121 を認識）。この状態で quick_example.py を再実行すると、重みキャッシュ済みの条件で 19 秒で完走しました。CPU フォールバック時の 6 分 5 秒からおよそ 19 倍で、依存指定 1 つでここまで変わります。ad_diffusion 側（後述）は依存範囲が torch>=1.13.0 でピン留めなしなので GPU が掴めていて、その対比からも依存指定の問題と切り分けられます。

なお、この問題を解決する PR #24（torch>=2.7.0 への緩和 + mac-mps ピンの削除）がコミュニティから出ていて、自分も GB10 での動作データを添えてコメントで参加していたのですが、本記事の執筆中（2026-07-03）に upstream へマージされました。マージ後の main を改めて fresh clone して素の uv sync から試したところ、torch 2.12.1+cu130 が解決されてそのまま GPU を認識、quick_example.py も重みキャッシュ済みの条件で同水準の 17 秒で完走しています。今から試す方はこの罠に当たらずに済みます。

ad_diffusion/examples/quick_example.py を回す

ad_diffusion 側は ad_diffusion/examples/quick_example.py を回します。sample_timeseries.csv を自動生成（500 サンプル × 3 sensor）して、DPM-Solver 20 ステップ + SCS 適応的閾値で異常検知するサンプルです。

cd ad_diffusion
uv run python examples/quick_example.py

こちらは特に手を加えなくても CUDA 13 + sm_121（Blackwell）で完全動作しました。torch 2.11.0+cu130 + triton 3.6.0 で torch.cuda.is_available() = True、torch.cuda.get_device_capability() = (12, 1) が返ってきて、GPU 上で推論が走ります。

実行時間は 34 秒で、内訳はおおよそ次のような形でした。

500 サンプル × 3 sensor を 26 秒なので、サンプル単位だと約 52 ms/sample。検出結果は 500 サンプル中 16 件（3.20%）でした。ground truth ラベルも synthetic データと一緒に自動生成されるデモなので、精度の数字は実データで評価し直す前提になりますが、点異常検知の速度の肌感を掴むには十分です。

追記（2026-07-06）: 公式テストデータセットでも回してみた

本文の検証コミット時点では synthetic データの自動生成だけでしたが、いまの main には ad_diffusion 用の公式テストデータセット examples/datasets/test-dataset.csv（500 サンプルの単変量 CSV）が同梱されています。せっかくなので、最新 main（コミット 9b31ca4）を fresh clone して素の uv sync から回し直してみました。

cd ad_diffusion
uv sync
uv run python examples/quick_example.py --dataset-path examples/datasets/test-dataset.csv

HF token を設定していない環境でも、重み final_model.pth は public リポジトリから自動ダウンロードされました。実行全体は 36 秒、DPM-Solver 20 ステップの推論は 26 秒で完走。検出結果は 500 サンプル中 15 件（3.00%）、MAE スコアは平均 0.948、最大 1.324 でした。サンプル単位では約 53 ms/sample なので、本文の synthetic データでの実測とほぼ同じ速度感です。

一点注意があるとすると、カスタム CSV には ground truth がないため、Precision / Recall / F1 の評価はスキップされます。この挙動はリポジトリの README にも明記されています。また実行ログを見ると、連番の ts 列もそのまま分析対象のチャンネルに数えられていたので、実データを渡すときはエポック秒や連番のような数値のタイムスタンプ列を先に落としておくのが良さそうです。

業務で使うならどこを見るか

今回初めて手元で触れるようになった NV-Tesseract、業務検討する立場では調整の自由度・ドメイン適応・解釈性の 3 軸で捉えると分かりやすいです。

ハイパラ調整で細かく詰められる

推論パラメータや後処理を自分のユースケースに合わせて細かく調整できます。先ほどの 52 ms/sample という実測も素の設定での数字で、AD-Diffusion なら DPM のサンプリングステップ数、FP8 / INT8 量子化、バッチングでまだ詰める余地があります。異常検知の閾値・window・後処理の集約を自前で書いて Chronos-2 / TimesFM と同じ評価軸に寄せる、といった作り込みができるのも OSS ならではの自由度です。

ドメイン適応（fine-tune）で精度を伸ばせる

examples/finetune_example.py が forecasting / ad_diffusion 両方で同梱されていて、Cross-Channel head（run8_best_model_cr.pt）の warm-start にも標準対応しています。公開ベンチ（ETTh1 のような穏やかな汎用時系列）で foundation model 同士を並べると素の勝敗はつきますが、そこで負けても自社のドメインデータで fine-tune すれば主戦場向けに寄せられる、という選択肢が入ります。前述のとおり NV-Tesseract の想定主戦場は巨大多変量センサーデータなので、汎用ベンチで無理に比べるよりドメイン適応で見比べる方が本質が出やすい設計だと思います。

解釈性レポートで説明責任に応えられる

forecasting の quick_example で見たとおり、interpretability=True を付けるだけでラグの寄与度が JSON と PDF レポートで出てきます。製造業の現場で「なぜこの予測になったのか」を説明する必要がある場面で、モデル出力とセットで解釈材料が出せるのは強みです。Chronos-2 / TimesFM 2.5 系の foundation model 単体だと SHAP や attention 可視化を別途組む必要があるので、この差は実務で効いてきます。

まとめ

NV-Tesseract は今回 Apache 2.0 で OSS 公開され、Hugging Face public 配布・examples/finetune_example.py 同梱・Lag-Horizon Attribution による解釈性、といった要素がひととおり揃った形で提供されています。DGX Spark 上でも forecasting / ad_diffusion のどちらも実機で回せることを確認できて、時系列基盤モデルの選択肢に加わってきました。

NVIDIA エコシステム全体で見ると、データ取得層に DAQIRI（センサーから GPU メモリへゼロコピーでストリーミングする I/O プラットフォーム）、データ基盤層に Cognite Data Fusion のような外部プラットフォーム、推論層に NV-Tesseract、という 3 層構造が描けるようになっています。製造業の現場で「センサー → ゼロコピー GPU 転送 → 時系列推論 → ナレッジグラフ統合 → エージェント自動化」を 1 つのスタックで組む絵が、OSS 化を契機に現実味を帯びてきましたね。

参考リンク

NVIDIA 公式

• NVIDIA/NV-Tesseract GitHub リポジトリ
• 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 — センサー → GPU ゼロコピー I/O プラットフォーム

Cognite × NVIDIA 統合

• Cognite and NVIDIA Operationalize NV-Tesseract to Transform Industrial Forecasting（2026-03-16 発表、Celanese 事例つき）

既存連載

• 時系列基盤モデルを DGX Spark で動かして比べてみた
• Chronos-2 で PLC 風時系列データを予測し、Nemotron で保全コメントを生成してみた
• SKAB と時系列基盤モデルで産業センサーの異常検知を試してみた