NVIDIA、オープンウェイトの表形式基盤モデルKumo Tabularを公開 学習不要の単一フォワード推論、4ベンチマークで自社報告1位
NVIDIAが2026年9月29日公開の公式ブログによれば、表形式基盤モデルKumo Tabularを発表した。2800万から2億1500万パラメータの3サイズがあり、OpenMDW-1.1ライセンスでHugging Faceに公開。学習も特徴量エンジニアリングも不要で、単一のフォワードパスで分類と回帰を実行でき、ブログはTabArenaなど4ベンチマークで1位と主張している。
主な変更
NVIDIAが2026年9月29日公開の公式ブログによると、NVIDIAは表形式基盤モデルKumo Tabularを発表した。Kumo Structuredモデルシリーズに属し、重みはHugging Faceで公開され、付属コードは構造化データ向けオープンソースライブラリを通じて提供される。モデルは完全に人工的な合成テーブルで事前学習される。各訓練テーブルは構造的因果モデルからサンプリングされ、ランダムな因果グラフとランダムに抽出された関数によって数値列、カテゴリ列、目的変数を生成し、他のノードは隠したままにする。その後、列相関、外れ値の切り詰め、欠損値の注入などの後処理を行い、木アンサンブルで学習可能な信号のないテーブルを除外する。アーキテクチャは表構造向けのTransformerで、列アテンション、行アテンション、コンテキストアテンションを採用。数値とカテゴリ値はフーリエ特徴埋め込みを通し、欠損値は補完しない。コンテキスト行は互いに注意し、クエリ行はコンテキスト行のみに注意するため、コンテキストのキーと値は一度計算すれば再利用できる。さらに長さ認識型のアテンション温度を導入し、キー数の対数に応じて各クエリをスケーリングすることで、数万行の大きなテーブルでもアテンションを鋭く保つ。モデルはSmall/Medium/Largeの3サイズで、パラメータは約2800万から2億1500万。分類と回帰は2つの独立したモデルとして訓練され、それぞれ交差エントロピー損失と分位点損失を使用する。回帰は999個の分位点を出力し、点予測と不確実性推定を与える。ブログによれば、TabArenaでELO 1950で1位、単一のRTX 6000 Proでの統一評価環境でLimiX-2より17倍高速。BeyondArenaではELO 1418とImprovabilityスコア7.78%で1位。TALENTでは分類精度、分類対数損失、回帰RMSEの3項目総合で1位。ScoringBenchではLargeとMediumがそれぞれ1位と2位となった。ブログは同時に、モデルが数値列とカテゴリ列のみをサポートし、単一のフォワードで最大10クラスまで対応し、多クラスはライブラリの誤り訂正出力符号で拡張すると説明している。
開発者への影響
開発者への直接的な影響は、表形式モデリングへの接触方法が変わることだ。Kumo TabularにはREST推論インターフェースがなく、Python環境で新しいGPUネイティブライブラリを通じて呼び出す。初回実行時はHubから重みをダウンロードし、入力はラベル付きコンテキスト行と予測対象のクエリ行で、重み更新も特徴量エンジニアリングもハイパーパラメータ探索も行わない。ブログの内容が正しければ、最も早く影響を受けるのはラベルが希少で迅速にベースラインを得たい表形式タスク、たとえば離反予測、需要予測、リスクスコアリングだ。省かれるのは訓練時間ではなく訓練パイプライン全体だからである。ブログの説明によれば、予測はコンテキストとそのクエリ行自体のみに依存し、同じバッチの他のクエリ行には依存しない。これはコンテキストのキーと値をキャッシュして再利用でき、連続スコアリングではコンテキストを一度計算するだけで済むことを意味する。しかし同時に、コンテキストの品質と網羅性が出力を直接左右し、コンテキストの行選択を誤ることはハイパーパラメータの選択ミスよりも気づきにくいことも意味する。注意すべき点として、このモデルはKimiSeekの現在のオンラインカタログには存在せず、当サイトのAPIから呼び出せず、ローカルまたは自前のGPUサービスでの展開に限られる。ブログの17倍高速、ELO 1950などの数値はすべてベンダーによる自己申告であり、評価プロトコルとデータ分割は文中で詳述されておらず、特定の業務データに直接外挿することはできない。OpenMDW-1.1はライセンスであり、「オープンウェイトが自動的に商用利用可能を意味する」という結論ではない。具体的な条項は自身で読んで確認する必要がある。Kumo Tabularは無条件に既存の勾配ブースティング木を置き換えるものではなく補完的な候補と捉え、中小規模のテーブル、ラベル行が十分、数値列とカテゴリ列が中心のシナリオでまず比較実験を行うのがより堅実だろう。
導入と評価の提案
以下は条件付きの提案であり、ベンダーが実証済みの結論ではない。第一に、ローカルGPU推論経路を敷設するかどうか。認識すべき報告事実は、モデルが重みの形でオープンソースライブラリを通じてローカルで動作し、GPU環境に依存することだ。下す選択は、ローカル推論経路を新たに追加するか、既存のタスクごとに訓練する木モデルを使い続けるかである。選択を変える引き金となる重要な前提は、チームに利用可能なGPUが既にあり、表形式タスクの数が十分多く、タスクごとの訓練コストが高いかどうかだ。測定可能な評価基準は、自前のホールドアウトセットで両者の精度または回帰誤差を比較し、同時に推論遅延とVRAM使用量を記録すること。もしローカル推論の精度に優位性がなく遅延が許容できないなら、そのために新しい経路を維持する価値はない。第二に、コンテキスト行数の取捨。報告事実は、訓練の第三段階でコンテキストを60000行に拡張し、長さ認識型のアテンション温度を専用に設計したことだ。下す選択は、予測ごとに投入するコンテキスト行数である。前提はテーブル規模と遅延予算で、コンテキストが大きいほどVRAMと時間のコストが高い。評価基準は、クエリセットを固定し、数百行、数千行、1万行以上のコンテキストでそれぞれ精度と遅延を測定し、精度がコンテキストの増加に伴って向上するか、遅延曲線が許容可能かを見ること。もし精度が早々に飽和するなら、コンテキストをさらに加えるのはVRAMの無駄にすぎない。第三に、分布ドリフト下での採用境界。報告事実は、ブログがクエリ行とコンテキスト行の分布が異なる場合やテーブルが訓練範囲をはるかに超える場合に精度が低下する可能性を指摘していることだ。下す選択は、モデルを制御された同一分布のタスクに置くか、時間帯やチャネルをまたぐ開放分布のタスクに置くかである。前提は、オンラインに近いコンテキストサンプルプールを構築・維持できるかどうか。評価基準は、訓練分布から明らかに外れたホールドアウトセットを構築し、誤差とモデル出力の分位点区間が同時に大きくなるか、キャリブレーションが依然として成立するかを観察すること。もし区間が不正確なら、教師あり訓練のモデルに戻すか、使用範囲を狭めるべきだ。第四に、分類クラス数が10を超えるタスク。報告事実は、単一のフォワードで最大10クラスまでで、超える場合はライブラリが誤り訂正出力符号を通じて任意のクラス数に拡張する。これはタスクを複数の二分類問題に分割することに相当する。下す選択は、そのモデルを直接使うか別の手段を選ぶかである。前提は、目的変数の基数と予測遅延が倍増するコストを受け入れられるかどうか。評価基準は、多クラスのサブタスクの誤差と所要時間を個別に測定し、既存手段と比較した上で決定することだ。
制限と未確認事項
明確にすべき点として、Kumo Tabularは現在KimiSeekのオンラインカタログに存在せず、当サイトから呼び出すことはできない。ブログが述べているのはベンダーがHugging Faceで重みとオープンソースライブラリを公開したローカル展開経路であり、両者を混同してはならない。文中のベンチマーク順位、ELO、速度倍率、パラメータ規模はすべてNVIDIAブログの自己申告結果であり、独立した再現はされていない。評価環境は単一のRTX 6000 Proで、ハードウェアやデータ分割を変えれば異なる結論が得られる可能性がある。OpenMDW-1.1はライセンス契約であり、オープンウェイトそのものは何らかの許諾を構成しない。商用条件を満たすかどうかはライセンス原文を自身で読む必要がある。モデルは数値列とカテゴリ列のみをサポートし、テキスト、画像、タイムスタンプは内蔵の前処理による特徴変換に依存する。単一のフォワードで最大10クラスまでで、超える場合は誤り訂正出力符号が必要だ。ブログ自体も、訓練範囲外やクエリとコンテキストの分布が一致しない場合に精度が低下する可能性を認めている。したがって本番投入前に必ず自前のホールドアウトデータで精度とキャリブレーションを検証すべきだ。さらに、訓練レシピと人工データ生成器はブログで間もなく公開されるとしているが、同ブログの公開時点では未公開であり、訓練プロセス全体の完全な再現は依然として不可能である。
元の報道の図版
