IBM Research、Granite（グラナイト）時系列モデル4種を再学習なしで束ねる「Granite Timeseries Ensemble r1」を公開GIFT-Evalの97構成でMASE 0.683、単体最良の0.685をわずかに上回る

IBM Researchは2026年10月22日（Hugging Face Blogの掲載日。ページの公開時刻は日本時間16時51分）、Granite（グラナイト）の時系列予測モデル4種の予測を1つにまとめる「Granite Timeseries Ensemble r1」を公開しました。再学習も、重みの当てはめも不要で、中央値と分位点（0.1〜0.9）の予測を返します。IBM Researchの公開ブログによると、GIFT-Evalの97構成での集計MASEは0.683で、単体で最良のPatchTST-FM-r2（0.685）をわずかに上回ります。モデルカードのライセンス欄はApache-2.0です。

3行まとめ

1. IBM Researchが、PatchTST-FM-r1・r2、FlowState-r1.1、TTM-r3の4モデルを組み合わせる「Granite Timeseries Ensemble r1」をHugging Faceで公開した。
2. 同社ブログによると、GIFT-Evalの97構成で集計MASEは0.683（確率的アンサンブル）。単体最良のPatchTST-FM-r2は0.685で、差は小さい。CRPS/MWQLではPatchTST-FM-r2（0.467）が最も低い。
3. 4つのチェックポイントを読み込むため推論時間とメモリは単体より増える。多変量のチャネル間情報は使わない。

本記事の内容は、日本時間2026年10月22日16時台に公式ページで確認したものです。

何を出したのか：4つのモデルを束ねる「レシピ」

Hugging Faceのモデルカードによると、公開されたのは結合済みの重みではなく、**組み合わせ方を書いた設定（レシピ）**です。4つのメンバーは実行時にそれぞれのリポジトリからダウンロードされます。

IBM Researchは、事前学習済みの時系列モデルは手元のデータで学習しなくても予測できるが、どのモデルを選ぶかは残る、と説明しています。滑らかな産業信号に強いモデルが、ノイズの多い小売需要や長い季節性の予測では苦戦しうるためです。そこで、性質の違う4モデルを束ねて「無難な既定値」にする、というのがこのレシピの狙いです。

組み合わせ方は2通りあります。

• Probabilistic Ensemble（確率的アンサンブル）：推奨の既定値。各メンバーに同じ影響力を与え、分位点の予測を確率空間で合成します。重みの当てはめがないので、新しい系列ごとに調整するパラメータがありません。
• IQR Ensemble：各メンバーの予測の広がり（四分位範囲）が狭いほど重みを大きくする代替案。重みは系列・対象・予測ステップごとに変わりますが、過去の予測誤差からは当てはめません。ブログは、狭い区間が正確さや較正の良さを意味するとは限らず、自信過剰なメンバーが有利になりうると注意しています。

使い方：pip一行と数行のPython

ブログに載っている手順では、pip install "granite-tsfm>=0.3.11" で入れ、次のように読み込みます。

from tsfm_public.models.ensemble.modeling_ensemble import QuantileEnsembleForecaster

ensemble = QuantileEnsembleForecaster.from_pretrained(
    "ibm-granite/granite-timeseries-ensemble-r1",
)

IQR版は subfolder="recipes/granite-iqr" を足すだけで読み込めるとされています。予測の出力は、ブログでは result.prediction_outputs（点予測）と result.quantile_outputs（分位点）です。ブログによると分位点は既定で0.1〜0.9で、0.1と0.9の間が名目80%の予測区間になります。モデルカードは、既定のレシピが0.1刻みの9本を返し、0.5を点予測に使うと書いています。

私はこのコードを実行していません。確認したのは取得した2つのページの記載までです。その範囲で気づいた食い違いが2つあります。

1. インストール要件が、ブログは granite-tsfm>=0.3.11、モデルカードは >=0.3.10 です。
2. 出力の属性名が、ブログは prediction_outputs と quantile_outputs、モデルカードは predicted と predicted_quantiles です。

どちらが正しいかは、今回取得したページからは判断できません。動かす場合は、インストールしたバージョンのコードで確かめるのが確実です。

性能：集計では小差、CRPSでは単体が上

IBM Researchは、97のGIFT-Eval構成で両レシピを評価したと書いています。ファインチューニングはなく、テスト用のターゲットは合成方法の選択にも当てはめにも使っていないとのことです。スコアはSeasonal Naiveで正規化し、幾何平均でまとめています（低いほど良い）。ブログの表は、2026年10月20日に取得した公開リーダーボードの値です。

ブログ自身の読み方は次のとおりです。

• 両アンサンブルは、4つの単体メンバーすべてを集計MASEと平均MASE順位で上回る。
• ただしMASEの差は小さい。主な利点は、どの構成が合うかを事前に知らなくても同等以上の精度が得られる頑健さだと書いている。
• CRPS/MWQLの集計値は、PatchTST-FM-r2（0.467）が最も低い。平均CRPS順位はIQR版が6つの中で最良。集計の誤差と平均順位で、有利な選択肢が分かれる。
• 2026年10月20日の比較では、アンサンブルは適格なシステムの中でMASE順位・CRPS順位とも3位。ファインチューニング済みや寛容でないライセンスとして比較から外した登録を含め、どちらのレシピよりスコアが良いシステムもあり、リーダーボードで首位になることが価値ではないと書いている。

数字を出しているのはIBM Research自身で、私は再計算していません。

ブログとモデルカードで、順位の値も順位の言い方も違う

日本時間16時台に2つのページを見比べたところ、同じ97構成の評価でも順位の値が違っていました。モデルカードの表は、2026年9月28日時点の順位です。

並び順（Prob、IQR、PatchTST-FM-r2の順）は同じです。ブログは、順位の列は完全なリーダーボードに対する平均なので、エントリーが増えると値が動くと注記しています。言い方も違います。モデルカードは、適格なシステムに絞った比較で、MASE順位は確率的アンサンブルが1位・IQR版が2位、CRPS順位はIQR版が1位・確率的アンサンブルが4位だと書いています（9月28日時点）。ブログは10月20日時点で、適格なシステムの中でMASE順位・CRPS順位とも3位としています。さらにモデルカードの同じ節には「MASEで3位・4位」「CRPSでIQR版3位、確率的アンサンブル4位」という別の記述も並んでいます。私の読みでは、こちらは順位の平均ではなく集計スコアでの並びを指しているようですが、ページからは断定できません。順位を引用するときは、取得日がより新しいブログ側の表を使うのが安全だと考えます。

誰が、どんな条件で使えるのか

• ライセンス：モデルカードによると、アンサンブルのレシピとGranite TSFMの実装はApache-2.0です。メンバーの重みは各リポジトリのライセンスに従います。既定のGranite専用レシピが参照するのはGraniteのチェックポイントだけだとされています。
• 拡張レシピに注意：リポジトリには、IBM Researchのチェックポイントを足した拡張レシピ（recipes/expanded-linear、recipes/expanded-iqr）もあります。モデルカードは「研究比較」用と位置づけ、非商用や研究用途に限る別ライセンスが付くものを含むため、使う前に各メンバーのモデルカードを確認するよう書いています。
• 他のモデルも足せる：共通のForecasterインターフェースを実装すれば、外部の互換モデルをメンバーにしたり、合成方法を変えたりできるとされています。メンバーの再学習や結合は不要です。
• 提供の形：モデルカードのページには、今回取得した時点で「Inference Providersにはデプロイされていない」と表示されていました。自分の環境で動かす形です。

料金に関する記載は、今回取得した3ページにはありませんでした。ライブラリとモデルのダウンロードで使う形です。

同系統の話：Mistralの時系列基盤モデルとの関係

当サイトでは直近に、Mistralが時系列基盤モデル「Timestral」を発表した件も扱いました（Mistral、初の時系列基盤モデル群「Timestral」を発表）。どちらも発表した会社自身がGIFT-Evalの結果を示していますが、今回のIBMの発表は新しい単体モデルではなく、既存の4モデルの使い方を整える内容です。両者の数字を直接比べる材料は、今回取得したページにはありません。

まだ分からないこと：推論時間・メモリの実測は載っていない

IBM Researchが自分で挙げている限界は次のとおりです。

• 多変量の各チャネルを独立に予測し、チャネル間の情報は使わない。
• 4つのチェックポイントを読み込むため、単体より推論時間とメモリが増える。
• メンバーごとにコンテキスト長、予測の長さ、前処理、欠損値の扱いが違う。
• どちらの合成方法も、較正や分布のずれへの頑健性は保証しない。
• 集計の改善が、どの系列にも効くとは限らない。

今回取得したブログとモデルカードには、推論時間やメモリ使用量の数値は載っていませんでした（「latency」「memory」「runtime」を含む記述は、上記の注意書きと、自分で測るよう勧める文だけでした）。コストと効果が見合うかは、ブログの勧めるとおり、自分のデータで確かめる必要があります。ブログの勧める手順は、①実運用と同じ予測窓で、②確率的アンサンブル・IQR版・強い単体モデル（例：PatchTST-FM-r2）を同じ条件で比べ、③MASEに加えて分位点損失と0.1〜0.9区間の実測カバー率（名目80%）を見て、④実行時間とメモリを記録する、です。

GIFT-Evalの結果はIBM Researchによる評価で、第三者による再現は今回の確認範囲にありません。

出典と確認時刻

• Ensemble forecasting with IBM Granite time-series models（IBM Research、Hugging Face Blog）：日本時間2026年10月22日16:56に確認
• ibm-granite/granite-timeseries-ensemble-r1（モデルカード）：同16:56に確認
• ibm-granite/granite-tsfm（GitHub）：同16:56に確認

GitHubのREADMEには、IBMがこのリポジトリを製品としてではなくオープンソースとして出しており、更新やサポートの義務を負わない旨の注記がありました。業務で使う場合は、この点も踏まえて判断してください。

本記事は続報があり次第更新します。