NVIDIA Kumo Tabularレビュー：実際にできること、できないこと

NVIDIA Kumo Tabularは、単一テーブルのデータで試す価値があるモデルです。ただし現時点の公開情報だけでは、CatBoostやLightGBM、TabPFNを本番環境から置き換える根拠にはなりません。

結論：Kumo Tabularは検証する価値がある。ただし本番トラフィックの切り替えはまだ早い

データがすでに1つのテーブルにまとまり、ラベルも用意できているなら、インコンテキスト予測によってモデル開発の手間を減らせるかを検証する価値があります。一方で、厳しいレイテンシ要件、CPUのみでの推論、マネージドホスティング、複数テーブルのデータを必要とする場合は、Kumo Tabularが対応できると決めつけず、検証時のゲート条件として扱うべきです。

公式ウェイトとAPIドキュメントは公開されていますが、Kumoに特化した公開比較データはまだ限られています。最終的な判断は、自社データのホールドアウトで検証してください。

NVIDIAが実際に公開したもの

NVIDIAのKumo-Tabular model cardによると、これは分類と回帰に対応した事前学習済みモデルです。公式のKumoTabular API documentationでは、ラベル付きの行をコンテキストとして与え、データセットごとに新しい重みを学習することなく、クエリ行を予測するインコンテキスト方式が示されています。

公開パッケージにはsmall、medium、largeの3種類があります。NVIDIAのstructured-data model catalogによると、パラメータ数はこれらのモデルでおよそ2,700万から2億1,600万です。モデルカードにはOpenMDW-1.1ライセンスが記載され、Pythonのインストール方法と推論手順も用意されています。ただし、「公開ウェイトだから自由に使える」と考えるのではなく、商用利用や再配布の条件をライセンス本文で確認してください。

このモデルをKumoRFMと混同してはいけません。Kumo Tabularが対象とするのは単一テーブルです。一方、NVIDIAのKumo Relational overviewでは、KumoRFMはリレーショナルデータ向けの別モデルとして説明されています。Kumo Tabularのドキュメントでも、関連テーブルのサポートは利用できないと明記されています。

今回確認した公式モデルカードとAPIページには、最大行数や最大特徴量数を簡潔に示した上限値は掲載されていません。ただし、モデル設定やタスク上の制約は確認できます。したがって、行数、特徴量数、コンテキストとクエリの構成、メモリ使用量、受け付け可能なクラス数は、別の表形式モデルから推測せず、検証時に記録する必要があります。

導入可否を左右する3つの制約

Kumo Tabularが自社の用途に合うかどうかは、主に次の3つの運用上の制約で決まります。

• データの形：Kumo Tabularは関連テーブルをネイティブには扱えません。予測に必要な情報が顧客、注文、商品、サポート履歴などに分散しているなら、モデルを比較する前に、フラット化や集約の方針を決めて検証してください。
• 推論規模：公開ドキュメントにはモデルのバリエーションと対応タスクは記載されていますが、本番運用時のスループット、GPUメモリ、予測あたりのコストを独立に検証した一覧はありません。コンテキストのサイズによってレイテンシとメモリ使用量がどう変わるかを測定しましょう。
• デプロイ手段：ウェイトとPythonインターフェースは公開されていますが、それはSLA付きのマネージドAPIとは別物です。リージョンルーティング、クォータ保証、ベンダー運用のホスティングが必要なチームは、それらを検証の合格条件として明確に設定してください。

Kumo TabularをTabPFNや学習型ベースラインと比較する

今回確認した情報の中に、Kumo Tabularが現行のTabPFN、CatBoost、LightGBM、XGBoostを上回ることを示す、信頼できる同条件比較の結果はありません。引用した第三者ベンチマークは、検証項目を設計するための材料であり、Kumoの性能を裏付ける結果ではありません。

AnoFox comparisonでは、複数の表形式基盤モデルを8コアCPU 1台で測定しています。その結果、5つの小規模データセットで、テストしたscikit-learnモデルを約2～7%上回った一方、実行時間は大幅に長くなる場合がありました。ある解約予測のテストでは、Mitraのウォーム推論に19.3秒かかったのに対し、ロジスティック回帰は0.035秒でした。

別のAIMultiple benchmarkでは、TabFMが19データセット中15個で勝利しましたが、TabPFN 3やTabICLv2のおよそ40倍の計算資源を必要としました。同ベンチマークによると、TabFMをB200 GPUでフル実行したコストは約27ドル、TabPFN 3は約0.65ドルでした。繰り返しになりますが、これらは収集すべき測定項目を示す数字であり、Kumoの結果ではありません。

まず実施すべき、再現性のあるテスト

固定したホールドアウトを使い、学習型のベースラインと並べてKumo Tabularを評価しましょう。

1. モデルを試す前に、時系列を考慮した分割または層化分割によるtrain/testの分割を1つ決めて固定します。予測時にテストラベルが使えない状態を維持してください。
2. テーブルのスキーマを確認します。対象列、欠損値、カテゴリ列、重複エンティティ、予測時点より後に作成されたフィールドを確認してください。
3. サポート対象の生テーブルをKumo Tabularに入力し、モデルのバリアント、コンテキスト行とクエリ行、特徴量数、受け付け可能なクラス数、バッチサイズ、ハードウェア、コールドスタート時間、ウォーム時レイテンシ、ピークメモリを記録します。
4. 同じ行とターゲットを使ってCatBoostまたはLightGBMを実行します。前処理時間は、学習時間や予測時間とは分けて記録してください。
5. タスクに合った指標で比較します。二値分類ならAUROCとキャリブレーション、不均衡な多クラス分類ならmacro-F1、回帰ならMAEまたはRMSEを使います。
6. コンテキストのサンプル数を減らした場合と増やした場合で再実行します。精度が安定していてもレイテンシが急増するなら、そのモデルはサービングより探索用途に向いている可能性があります。
7. 合格条件をあらかじめ3つ決めます。最低限必要な指標の改善幅、p95レイテンシの上限、バッチあたりのインフラコストの上限です。Kumo Tabularが3つすべてを満たした場合にのみ、次の段階へ進めてください。

ベンダーのベンチマークを、データリークの確認に置き換えてはいけません。「特徴量エンジニアリング不要」は、「データ検証不要」という意味ではありません。