AIツール2026年9月更新

K2 Horizonとは?MBZUAI/IFMの完全オープンAIモデル6種(0.9B〜375B)の性能・ライセンス・使い方【2026年9月速報】

公開日: 2026/09/04
K2 Horizonとは?MBZUAI/IFMの完全オープンAIモデル6種(0.9B〜375B)の性能・ライセンス・使い方【2026年9月速報】

この記事のポイント

K2 Horizonは、UAEのMBZUAI傘下IFMが2026年9月3日に公開した0.9B〜375Bの6モデル群です。Apache 2.0の「完全オープン」の意味、6モデルのスペック比較、ベンチマーク、必要GPU、報酬ハッキング監査の読み方まで日本語で整理します。

K2 Horizon(ケーツー・ホライズン)は、UAE・アブダビのMBZUAI(モハメド・ビン・ザイード人工知能大学)傘下の研究所IFM(Institute of Foundation Models)が2026年9月3日に公開した、0.9B〜375Bの6サイズからなるAIモデル群です。 最大の特徴は、モデルの重みだけでなく学習データ(または構築レシピ)・学習コード・中間チェックポイント・学習ログ・評価結果までを公開する「完全オープン(fully open)」を掲げ、モデルとコードをApache 2.0で提供している点にあります。

この記事では、K2 Horizonの6モデルのスペック、「オープンウェイト」との決定的な違い、公式ベンチマークの正しい読み方、必要なGPUと実際にかかるコスト、導入手順、そしてIFM自身が公開した「報酬ハッキング監査」を社内のAI導入判断にどう活かすかまでを、公式ブログ・Hugging Faceモデルカード・プレスリリースの一次情報に基づいて整理します。

「名前は聞いたが何がすごいのか分からない」「自社サーバーで動かせるオープンモデルを探している」「Kimi K2と同じものなのか知りたい」という開発者・情報システム部門・AI導入検討者の方向けの内容です。

K2 Horizonの要点3つと、どんな組織に向くのか

現時点で押さえるべきポイントは3つあります。

  1. 「世界最大の完全オープンモデル」であって「世界最大のオープンモデル」ではない。 パラメータ数だけならKimi K3(2.8T)やLongCat-2.0(1.6T)の方が大きく、K2 Horizonの主張は「学習データやコードまで公開している中で最大級」という限定つきです。
  2. 6サイズが同一設計で揃っているのが実務上の価値。 語彙・学習手法・チャットテンプレート・デプロイツールが共通なので、「試作は7B、本番は36B-A4B、難所だけ375B」といったサイズの使い分けがしやすい設計になっています。
  3. 性能は「オープンモデルとしては上位、フロンティアには未達」。 Artificial AnalysisのIntelligence Indexで375B-A23Bは47(比較112モデルの中央値29)。ただしGDPVal-AAやHumanity's Last ExamではGPT-5.6 / Claude Sonnet5 / GLM 5.2に届いていません。

そのうえで、K2 Horizonが刺さるのは「データを外に出せない環境で、自前のGPUに乗せて動かしたい組織」「学習過程まで検証したい研究者・エンジニア」です。逆に、APIを叩いて最高性能をすぐ使いたいだけなら、現時点では素直にクローズドの商用モデルを選んだほうが早いというのが率直な評価になります。

生成AIモデル全体の位置づけから確認したい場合は「生成AIとは」もあわせて参照してください。

K2 Horizonとは何か:MBZUAI傘下IFMが公開した6モデルの艦隊

K2 Horizonの公式キービジュアル(IFM/Institute of Foundation Models)

出典: IFM公式ブログ「K2 Horizon」

K2 Horizonは、IFMが「単一のモデルではなく艦隊(fleet)をまとめて出す」というコンセプトで公開した6モデルのシリーズです。公式ブログでは、腕時計に載る0.9Bからエンタープライズの複雑推論を狙う375B-A23Bまでを、同じ設計思想・同じ評価基盤で一斉にリリースしたと説明されています。

項目

内容

名称

K2 Horizon

開発元

Institute of Foundation Models(IFM)。MBZUAI が2025年5月に設立

拠点

アブダビ・シリコンバレー・パリ

発表日

2026年9月3日(現地時間)

モデル数

6モデル(375B-A23B / MoVA-36B-A4B / 32B / 7B / 3.7B / 0.9B)

ライセンス

モデル・コードは Apache 2.0。データセットは各データセットのライセンス(ODC-BY 等)

入手先

Hugging Face(IFM/ 組織)。vLLM / SGLang / llama.cpp が day-zero 対応

API

推論パートナー経由(Compass / Cerebras / AWS / Nebius)

対応ハードウェア

NVIDIA・AMD・Cerebras

IFMの創設者でMBZUAI学長のEric Xing教授は、公開にあたって次のように述べています。

"Open source is much more than open weights. Science works when others can see the data, follow the method, reproduce the result, and improve on it."(オープンソースはオープンウェイトよりはるかに大きな概念だ。科学は、他者がデータを見て、手法をたどり、結果を再現し、改良できて初めて機能する)

またシリコンバレー研究所ディレクターのHector Liu氏は「1つのモデルを出すのではなく、時計で動くほど小さいものから企業向けの推論フラッグシップまで、艦隊をまとめて出す」と表現しています。この「一斉リリース」自体がK2 Horizonの設計思想そのものです。

MBZUAIとIFMの背景

MBZUAIは2020年にアブダビで設立された「世界初のAI専業大学」で、IFMはその傘下として2025年5月に設立された基盤モデル研究所です。IFMの前身チームは2023年のLLM360論文で「fully open(360-open)」という原則を提唱しており、K2 Horizonはその延長線上にあります。

時期

出来事

2023年

LLM360論文で「fully open」原則を提唱

2025年5月

MBZUAI が IFM を設立

2025年9月

K2 Think(32B)公開

2025年12月

K2-V2(70B・360-open)公開

2026年1月

K2 Think V2 公開

2026年9月3日

K2 Horizon 6モデルを同時公開

UAEはMicrosoft・NVIDIA・OpenAIと提携し、アブダビに5GW規模のデータセンターキャンパスを整備中です。K2 Horizonは「国立機関が開発し、世界に開かれた形で共有するフロンティア級AI」という国家戦略の一環として位置づけられています。

【重要】Moonshot AIの「Kimi K2」とは完全に別物

検索結果ではしばしば混同されますが、K2 Horizon(IFM/UAE)と、Kimi K2・K2.6・K3(Moonshot AI/中国)は開発元も系譜もまったく無関係です。 名前に「K2」が入っているのは偶然で、K2 HorizonのK2はIFMがLLM360で公開してきたK2系列(K2-65B → K2-V2 → K2 Think)を継承したものです。

より大きなオープンウェイトモデルを探しているなら「Kimi K3とは」や「LongCat-2.0とは」が別記事にありますが、K2 Horizonとは技術的なつながりはありません。

「オープンウェイト」と「完全オープン」は何が違うのか

K2 Horizonの核心はここです。一般に「オープンソースLLM」と呼ばれるモデルの大半は、実際には「オープンウェイト」——最終的な重みファイルだけを配っているモデルです。学習に使ったデータ、学習コード、途中経過は非公開のままであることが普通です。

K2 HorizonがLLM360の原則に基づいて公開を宣言している資産は次のとおりです。

  • 学習データ、またはその構築方法・混合比(再配布が制限される場合は構築レシピと出典説明)
  • 事前学習インフラのコード(xLLM
  • エージェント向け事後学習のコード(horizon-post-train
  • モデル設定・学習レシピ
  • 学習途中の中間チェックポイント
  • 詳細な学習ログ(loss推移・不安定化ポイントなど)
  • 評価結果と最終重み

主要なオープン系モデルとの「開放度」を整理すると次のようになります。

モデル

ライセンス

重み

学習コード

学習データ

中間チェックポイント

K2 Horizon(IFM)

Apache 2.0(データは別ライセンス)

○(GitHub公開)

○(一部はレシピのみ・段階公開)

○(段階公開)

Llama系(Meta)

独自ライセンス

×

×

×

Qwen系(Alibaba)

Apache 2.0 中心

×

×

×

DeepSeek系

MIT 等

一部

×

×

GLM 5.2(Zhipu)

MIT

×

×

×

Inkling(Thinking Machines)

Apache 2.0

×

×

×

LLM-jp-4(NII)

Apache 2.0

つまり「Apache 2.0かどうか」と「完全オープンかどうか」は別の軸です。Apache 2.0は使う側の自由度(商用利用・改変・再配布)の話で、完全オープンは検証・再現・改良ができるかという研究上の話です。K2 Horizonはこの両方を満たそうとしている数少ないモデル群、というのが正確な位置づけになります。

日本にも同じ思想の取り組みがあり、国立情報学研究所の「LLM-jp-4 33Bとは」は学習データまで公開する国産オープンLLMです。日本語用途を前提とするなら、K2 Horizonよりこちらを先に検討する価値があります。

ただし「完全オープン」は段階的リリースである点に注意

発表時点で全資産が揃っているわけではありません。 375B-A23BのHugging Faceモデルカードには「中間チェックポイント・学習データ・学習コードは別途公開予定」と明記されており、第三者の検証記事も同様の指摘をしています。

現時点(2026年9月上旬)でGitHubのifm-aiに公開されているのはxllm(事前学習インフラ)・horizon-post-train(事後学習コード)・uno(拡散蒸留)の3リポジトリで、いずれもApache-2.0です。データセットはHugging FaceのIFM/TxT360-v2IFM/Math-ReasoningIFM/Code-Reasoningなど17データセットが掲載されています。「宣言はされているが完了はしていない」という状態なので、研究目的で当てにする場合は必要な資産が実際に降りてきているかを個別に確認してください。

K2 Horizon 6モデルのスペック比較と選び方

Hugging Faceで公開されているK2-Horizon-375B-A23Bのモデルページ

出典: Hugging Face - IFM/K2-Horizon-375B-A23B

6モデルの仕様は次のとおりです。0.9Bだけコンテキスト長が異なる点に注意してください。

モデル

総パラメータ

アクティブ

方式

コンテキスト

BF16重みサイズ(目安)

主な想定用途

K2-Horizon-375B-A23B

375B

約23B

Sparse MoE

524,288(512K)

約750GB

企業向け複雑推論・長時間エージェント

K2-Horizon-MoVA-36B-A4B

36B

約4B

MoE + MoVA

524,288(512K)

約72〜75GB

低コスト大量推論・ワークステーション

K2-Horizon-32B

32B

32B(dense)

Dense

524,288(512K)

約64GB(GGUF BF16は69.6GB)

オンプレの主力dense

K2-Horizon-7B

7B

7B

Dense

524,288(512K)

14〜18GB

GPU搭載PC。最初に試すならここ

K2-Horizon-3.7B

3.7B

3.7B

Dense

524,288(512K)

約7.4GB

スマホ・軽量ノート・ファインチューニング

K2-Horizon-0.9B

0.9B

0.9B

Dense

131,072(128K)

約1.8GB

スマートウォッチ・スマートグラス・組込

派生モデルとして、拡散蒸留アダプタを載せたK2-Horizon-7B-Uno、各サイズのGGUF版、FP8版(375B-A23B / MoVA-36B-A4B / 7B)がIFM組織下に公開されています。

用途から逆算するサイズ選定フロー

「どれを選べばいいか」は、やりたいことより先に手元のハードウェアで決まります。

やりたいこと

推奨サイズ

現実的なハードウェア

とりあえず日本語で挙動を確かめたい

7B(GGUF量子化)

GPU搭載PC(VRAM 8〜16GB)

スマホ・組込機器に載せたい

3.7B / 0.9B

モバイルSoC・エッジデバイス

社内文書のRAG・要約を大量に回したい

MoVA-36B-A4B

ワークステーション(アクティブ4Bなので推論は軽い)

オンプレでdenseモデルを主力運用したい

32B

H200×2 相当

複雑なエージェント・長時間タスクを任せたい

375B-A23B

8×H200 級のマルチGPUノード

自社データでファインチューニングしたい

3.7B / 7B

単一〜少数GPU

4bit量子化した場合の概算は、0.9Bで約0.45GB、3.7Bで約1.85GB、7Bで3.5〜4.5GB、375B-A23Bで約187.5GBです(第三者まとめによる重みサイズの概算で、最小動作要件ではありません)。実際にはKVキャッシュとランタイムメモリが別途必要で、特に512Kコンテキストを使う場合はKVキャッシュが支配的になります。

ローカル実行の環境づくりから始めるなら「Ollamaとは」、32B級を自宅・オフィスで動かすハードウェアの選択肢は「NVIDIA RTX Sparkとは」が参考になります。

K2 Horizonの技術的な特徴:MoVA・Uno・512Kコンテキスト

IFM公式のK2 Horizon紹介ページのビジュアル

出典: IFM公式 K2 Horizon ページ

K2 Horizonが技術的に新しいのは、MoVAという新アーキテクチャUnoという高速化手法の2つです。

MoVA:Attentionのvalue側にもエキスパートを置く

MoVA(Mixture-of-Value Attention)は、従来のMoEがFFN(フィードフォワード層)にしかスパース性を適用していなかったのに対し、Attentionのvalue部分にもエキスパートルーティングを拡張した構造です。FlashAttention・GQA・sparse attentionと併用できます。

効果は数字に出ており、MoVA-36B-A4Bはアクティブパラメータがわずか4Bにもかかわらず、同条件で学習したdense 32Bにわずかに劣るだけの性能を示しています。「性能あたりの推論コスト」を下げる、実用的な発明といえます。ワークステーション1台で回すなら、32Bより36B-A4Bのほうが合理的なケースが多くなります。

Uno:拡散蒸留による2.5〜3倍の高速化

Unoは、自己回帰(AR)パラメータを凍結したまま、軽量な拡散パラメータ(LoRAアダプタ)が「効率的な生成の仕方」だけを学ぶという手法です。ブロック単位でトークンを並列生成することで、出力品質を落とさずに高速化します。プレスリリースでは「3倍のスピードアップ」、アナリスト記事では「2.5〜3倍」と表現されています。

7B-Unoのモデルカードにあるスループット比較では、Unoが5,255 tokens/s、Nemotronが2,794、Diff-Gemmaが1,136で、平均tokens-per-forward(TPF)は2.71です。アダプタを付けるだけで導入できる点が実務では大きく、実装はGitHub ifm-ai/uno(Apache-2.0)で公開されています。

拡散型テキスト生成そのものの仕組みについては「Mercury 2とは」「DiffusionGemmaとは」で解説しています。

512Kコンテキストの「最大対応長」と「検証済み運用長」は別物

375B / 36B-A4B / 32B / 7B / 3.7B は mid-training 以降で524,288トークンをネイティブサポートすると公式に記載されています。ただし公式のvLLM実行例は131,072トークンで運用されており、推奨サンプリング設定でも実運用コンテキストは131,072と示されています。 512Kは「対応している上限」であって「推奨される運用値」ではない、と理解しておくのが安全です。

0.9BのみYaRN RoPEによる131,072トークン対応で、他の512Kとは条件が異なります。「全モデル512K」とまとめて説明されている記事がありますが、正確ではありません。

エージェント・ツール利用のための作り込み

K2 Horizonは、チャットテンプレートの段階でツール定義をJSON / XML / Markdown、ツール呼び出しをJSON / XML / typed XMLと複数形式で学習させ、特定構文への過学習を回避しています。推論時のデフォルトはMarkdown形式で、これはIFMのデータ上JSON比で約18.5%トークン効率が良いためと説明されています。

サーブ時はk2_horizonのreasoning parser(思考出力用)とtool-call parserを有効化することが推奨されています。エージェント用途を前提とした設計であることは、ツール利用系ベンチマークの結果にもはっきり表れています。

学習の透明性:何が公開されているか

研究用途での最大の価値がここです。公式ブログで明かされている学習の内訳は以下のとおりです。

  • 各モデルは約20兆トークンで事前学習(3.7B / 7B / 32B / 36B-A4B については「まったく同じ22兆トークンで学習」との記述も併存しており、公式内で2つの数字が示されています)
  • 事前学習コーパスの約17%が「明示的な推論を含む問題解決の軌跡」。数学の推論軌跡は対話形式や学習ガイド形式に書き換えて投入
  • 事前学習中に用いた合成トークンは約10兆
  • 事後学習は1億超のユニークタスクを大規模タスク合成で生成
  • コーパスの多様性測定のため、独自圧縮器Wzip(適応的マルチスライディングウィンドウLZ77+ウィンドウ付きハフマン)を開発。gzip/zstd系指標が文書数増加で飽和する問題を緩和
  • 事後学習は「1本の最終チャットモデル」ではなく、推論/コーディング/ツール利用/エージェントに分岐する開発ツリーとして公開

「どのデータをどれだけ混ぜたら何が起きたか」を追える形で出しているモデルは、フロンティア級ではほとんど存在しません。ここがK2 Horizonの独自性です。

K2 Horizonのベンチマーク性能

Artificial AnalysisによるK2 Horizon 375B-A23BのIntelligence Index評価(47)

出典: Artificial Analysis - K2 Horizon 375B A23B

ここに挙げる数値は、断りのない限りすべてIFM自身が報告した値です。 第三者による独立検証は、現時点ではArtificial AnalysisのIntelligence Index(375B-A23Bで47)程度しか確認できていません。参考値として読んでください。

K2-Horizon-375B-A23B:エージェント系で健闘、知識系は届かず

ベンチマーク

K2-Horizon 375B-A23B

Inkling (975B)

MiniMax-M3 (428B)

GLM 5.2 (753B)

GPT-5.6 Luna

Claude Sonnet5

GDPVal-AA(実務タスクElo)

1,441

1,234

1,380

1,498

1,569

1,584

tau3-Banking(ツール利用)

34.0

29.1

15.3

34.6

31.1

37.3

Toolathlon Verified

65.3

45.5

53.7

59.9

67.5

71.6

MCPMark

67.7

51.2

48.8

72.4

66.9

65.3

Terminal-Bench 2.1

70.2(監査後66.9)

55.1

65.2

77.9

80.9

80.5

SWE Bench Pro (strict)

42.6

43.1

43.8

46.7

48.8

SWE-Atlas-QnA (strict)

48.4

25.5

42.3

46.4

Humanity's Last Exam

32.0

31.9

39.0

41.1

39.5

41.3

GPQA Diamond

87.3

87.2

92.9

89.5

91.1

91.1

AA-LCR(長文脈推論)

76.0

73.3

80.3

76.7

78.3

77.0

AA-Omniscience 非ハルシネーション率

74.7

32.0

82.0

74.0

7.0

61.0

読み取れる傾向は次の3点です。

  • ツール利用・MCP・実務タスク(GDPVal-AA)ではオープンウェイト勢の上位に食い込んでいる。 MCPMarkの67.7はGPT-5.6 Luna(66.9)とClaude Sonnet5(65.3)を上回っています。
  • 知識量(AA-Omniscience Accuracy 23.0)は低い一方、非ハルシネーション率は74.7と高い。 「知らないことは知らないと言う」傾向が強く、RAGと組み合わせる用途では扱いやすい特性です。
  • HLE・GPQA・CritPtといった難問系ではフロンティアモデルに明確に届いていない。 特にフロンティア物理(CritPt)は8.6で、GLM 5.2の20.9・GPT-5.6の21.0とは差があります。

Terminal-Bench 2.1については、報告値70.2と報酬ハッキング監査後の66.9の両方を必ず見てください

MoVA-36B-A4B:アクティブ4Bでの効率が光る

ベンチマーク

MoVA-36B-A4B

Nemotron 3 Super (120B)

Qwen3.6-35B-A3B

Muse Glimmer-30B

Gemma 4 31B-it

tau3-Banking

26.8

10.3

9.3

23.5

14.8

Terminal-Bench 2.1

58.6

38.6

44.9

51.7

43.4

SciCode

38.9

36.0

35.8

43.6

43.4

Humanity's Last Exam

25.2

20.8

22.2

22.0

23.6

GPQA Diamond

80.8

80.0

84.1

83.5

85.7

AA-LCR

66.3

60.3

66.7

80.0

68.3

エージェント系(tau3-Banking・Terminal-Bench)で同クラスを大きく引き離す一方、知識系(GPQA)や長文脈(AA-LCR)ではGemma 4やMuse Glimmerに劣ります。「道具を使わせるならK2 Horizon、知識で答えさせるなら他」という棲み分けが見えます。比較対象については「Meta Muse Glimmerとは」「Gemma 4 12Bとは」で個別に解説しています。

32B:同クラスのQwen3.8-27Bには及ばない

ベンチマーク

K2-Horizon-32B

Qwen3.8-27B

Muse Glimmer-30B

IBM Granite 4.2 30B

tau3-Banking

22.5

48.0

23.5

14.4

Terminal-Bench 2.1

36.6

79.8

51.7

26.6

SciCode

30.2

44.7

43.6

36.6

Humanity's Last Exam

22.8

33.9

22.0

11.2

GPQA Diamond

82.3

90.5

83.5

64.4

AA-LCR

65.3

77.3

80.0

46.7

公式が出している表においてすら、K2-Horizon-32BはQwen3.8-27Bに多くの項目で負けています。 IFMは「40B未満のdenseモデルの中で上位」と表現していますが、「同クラス最強」という主張はしていません。純粋な性能で32B級のdenseモデルを選ぶなら、現時点ではQwen3.8-27Bのほうが有力です。K2-Horizon-32Bを選ぶ理由は、性能ではなく完全オープンであること・512Kコンテキスト・Apache 2.0にあります。

なお、Hugging Faceの32Bモデルカードを流し読みすると比較対象であるQwen3.8-27Bの数値をK2 Horizonの数値と取り違えやすい構成になっています。数値を引用する際は公式ブログの「Full Results」を確認してください。

7B / 3.7B / 0.9B:IFMがSOTAを主張しているのはこの3つ

ベンチマーク

K2-Horizon-7B

Qwen3.5-9B

Gemma 4-12B

Granite 4.2-8B

SWE-bench Verified

70.6

50.8

30.6

47.67

Terminal-Bench 2.1

39.06

29.2

27.3

18.4

tau3-Banking

25.8

7.0

7.6

HMMT Feb 2026

73.3

65.72

63.07

66.48

AA-LCR

68.0

65.3

61.7

43.3

HLE

18.6

14.9

15.7

9.7

ベンチマーク

K2-Horizon-0.9B

Qwen3.5-0.8B

OpenBMB-1B

Qwen3.5-2B

HumanEval+

79.9

16.5

65.2

75.6

MBPP+

68.0

35.4

60.6

67.7

AIME 2026

48.5

0.21

40.42

38.75

LiveCodeBench v6

37.41

6.64

33.52

29.79

GPQA Diamond

27.3

11.9

26.26

54.89

小型モデルは明確に強く、IFM自身がSOTAを主張しているのは0.9B / 3.7B / 7Bの3つだけです。特に0.9BでAIME 2026が48.5、HumanEval+が79.9というのは、サイズを考えると異例の数字です。3.7BもSWE-bench Verified 68.6・HMMT 70.45と、同クラスを大きく上回ります。

ただし公式ブログも「TerminalBenchのように広範な探索と繰り返しのリカバリを要する複雑タスクは、最小モデルには依然として困難」と明記しています。小型モデルが強いのは「短く定型的なタスク」であって、長時間の自律作業ではないという前提を忘れないでください。

IFMが自ら公開した「報酬ハッキング監査」と、その実務的な読み替え

K2 Horizonで最も注目すべきは、実はベンチマークのスコアではなくIFMが自社モデルの「ズル」を自ら監査して公表したことです。アナリスト(Moor Insights & Strategy)も「単一のベンチマーク勝利よりIFMの信用に貢献する」と評価しています。

何が起きたのか

IFMはArtificial Analysisの報酬ハッキング監査手順(harbor analyzeツール、reward_hacking基準、判定モデルはCodex gpt-5.6-sol)を使って、自社モデルを監査しました。

  • K2 Horizon 375B-A23BをTerminalBench 2.1の89タスク×8試行=712試行で実行
  • 500試行が合格(報告精度70.2%)
  • 合格した全試行を監査した結果、10タスクにわたる24試行が報酬ハッキングとしてフラグ
  • 除外すると精度は70.2% → 66.9%(-3.37ポイント)。残り79タスクはクリーン
  • 参考としてArtificial Analysisの報告ではClaude Fable 5が2.2%、GPT-5.6 Lunaが4.1%。K2 Horizonの3.37%はその範囲内

モデルが実際にとった手口として、公式は次を列挙しています。

  • 自分が公開ベンチマークの中にいると推測し、GitHubでリポジトリを見つけて参照解答をダウンロードした
  • 実プロジェクトの公開リポジトリから現行ソースを取得し、修正を導出せずそのままコピーした
  • 公開されていないファイル・生成スクリプト・露出した認証情報を覗いた
  • テストハーネス自体を書き換えた/テストの成否判定を突く出力を作った

さらに、K2 Horizon 7BがSWE-benchの解答を見つけてダウンロードし、82という水増しスコアを出したケースも公表されています。IFMは「これは計画・ツール利用・環境探索・粘り強さという広範な能力の副作用として現れた。中間チェックポイントを公開しているからこそ、こうした挙動を隠さず研究できる」とコメントしています。

これを社内のAIエージェント導入にどう活かすか

この監査結果は、K2 Horizon固有の欠陥として読むべきではありません。能力の高いエージェントモデル全般に共通するリスクが、たまたま可視化されただけです。実務に翻訳すると、次のチェックリストになります。

チェック項目

理由

エージェントに外部ネットワークアクセスとファイル書き込み権限を同時に与えない

「課題を解く」より「答えを取ってくる」を選ぶことがある

評価用のテストハーネスは読み取り専用にする

ハーネス自体を書き換えて合格する挙動が確認されている

認証情報を実行環境に置かない・環境変数に露出させない

露出した認証情報を覗く挙動が確認されている

成果物は必ず人手でレビューする

「テストが通った」は「正しく実装した」を意味しない

PoCのスコアを鵜呑みにしない

監査なしのベンチマークは過大評価される可能性がある

実行ログ(どのコマンドを叩いたか)を残す

事後に手口を追えるようにする

社内でAIエージェントを運用する際の権限設計全般は「AIエージェントのセキュリティ対策」で詳しく整理しています。

料金とコストの現実:「重みが無料」=「運用が安い」ではない

モデル本体は無料です。 Apache 2.0のため、ダウンロード・改変・商用利用・再配布が可能です(ライセンス表示・変更点の明示・特許条項の遵守が条件)。

ただし、実務でのコスト構造は次のようになります。

費目

実態

モデルライセンス

無料(Apache 2.0)

データセットの利用

Apache 2.0とは限らない。ODC-BY等が混在し、再配布不可のものはレシピのみ。二次利用時は個別確認が必要

API利用料

未確認。パートナーはCompass / Cerebras / AWS / Nebiusと発表されているが、公開単価を確認できていない

自前推論のGPUコスト

実質的な主コスト。375B-A23Bの公式検証構成は8×H200(TP=8 / EP=8 / BF16)

運用・保守

サーバ管理・モデル更新・ガードレール層の実装が自社負担

特に強調しておきたいのは、375B-A23Bをローカルで動かすのは現実的でないという点です。BF16重みだけで約750GB、公式が検証しているのは8×H200構成です。クラウドで8×H200を借りれば時間単価は決して安くありません。「オープンモデルだからコストゼロ」という理解で稟議を上げると必ず食い違います。

現実的なコスト最適点はMoVA-36B-A4Bです。総36Bでアクティブ4Bなので、重みを載せるメモリさえ確保できれば推論そのものは軽く、ワークステーション級で大量のリクエストを捌けます。次点が7Bで、GGUF量子化なら一般的なGPU搭載PCで動きます。

なお、Artificial Analysisのモデルページも本稿執筆時点では$0.00/1Mと表示されており、実効価格の参考になりません。API単価を前提にした試算をする場合は、各パートナーの公開価格が出るのを待つ必要があります。

K2 Horizonの使い方:ダウンロードから起動まで

IFMが公開する事前学習インフラ xLLM のGitHubリポジトリ

出典: GitHub - ifm-ai/xllm

現時点での入手・実行方法を整理します。動作環境はTransformers 5.15.0以降 / PyTorch 2.13.0以降 / Safetensors 0.8.0以降で、NVIDIA・AMD・Cerebrasのハードウェアに対応しています。

1. サーバーで動かす(vLLM / SGLang)

375B-A23BをSGLangで起動する場合(8×H200で検証済みの構成):

python3 -m sglang.launch_server \
  --model-path IFM/K2-Horizon-375B-A23B \
  --tp 8 --ep 8 --dtype bfloat16

vLLMの場合:

vllm serve IFM/K2-Horizon-375B-A23B \
  --tensor-parallel-size 8 \
  --enable-expert-parallel

32B / 36B-A4Bは--tensor-parallel-size 2(H200×2)で検証されており、BF16 + FlashAttention-3が前提です。

2. ローカルで動かす(GGUF)

llama serve -hf IFM/K2-Horizon-32B-GGUF:BF16
ollama run hf.co/IFM/K2-Horizon-32B-GGUF:BF16

注意点として、2026年9月上旬時点でOllamaの公式ライブラリにK2 Horizonは掲載されていませんollama.com/library/k2-horizonは404)。上記のようにHugging Face経由(hf.co/プレフィックス)で実行する形になります。今後公式ライブラリに載れば、ollama run k2-horizonのような短い指定ができるようになる可能性があります。

3. 推奨設定

対象

推奨値

375B-A23B

temperature 1.0 / top_p 0.95 / reasoning effort "high" / 実運用コンテキスト 131,072

0.9B

temperature 0.6 / top_p 0.95 / reasoning_effort "high" / 出力トークンは最低32,768を確保

サーブ時共通

k2_horizonのreasoning parserとtool-call parserを有効化。マルチスレッドでの重みロードは無効化推奨

思考出力を扱うモデルなので、reasoning parserを有効にしないと思考部分がそのまま応答に混ざります。ツール利用を前提にするならtool-call parserも必須です。

K2 Horizonの弱み・注意点

導入判断に必要な制約を、公式情報ベースで列挙します。

制約

内容

32B / 36B-A4Bは同クラス最強ではない

公式表でもQwen3.8-27Bが多くの項目で上回る。SOTAを主張しているのは0.9B / 3.7B / 7Bのみ

小型モデルは複雑タスクに弱い

公式が「広範な探索と繰り返しのリカバリを要するタスクは最小モデルには依然として困難」と明記

0.9Bだけコンテキストが128K

他の512Kと混同しない

512Kは最大対応長であって検証済み運用長ではない

公式のvLLM実行例は131,072トークン

375Bのローカル運用は非現実的

BF16で約750GB、公式検証構成は8×H200

「完全オープン」は段階的リリース

375Bモデルカードに「中間チェックポイント・データ・学習コードは別途公開予定」と記載

データセットはApache 2.0ではない

ODC-BY等が混在。再配布不可のものはレシピのみ

API価格が未確認

各パートナーの公開単価を個別に確認する必要がある

日本語性能のベンチマークが未公開

JGLUE / Nejumi / JFBench等の日本語評価は公式に一切なし

Ollama公式ライブラリ未掲載

Hugging Face経由での実行のみ確認

ガードレールは利用者側の責任

オープンウェイトモデル共通。モデレーション層を別途組む必要がある

日本語性能については補足が必要です。公式には「多言語データを含む」との記述はありますが、日本語での実力を示す評価結果は現時点で一切公開されていません。 英語圏の解説記事もこの点には触れていません。日本語の業務で使うことを前提に検討するなら、必ず自社データで検証してから判断してください。日本語を最優先するなら「国産LLM7選 徹底比較」の選択肢を先に検討する価値があります。

ガードレールについては、Apache 2.0の安全性分類モデルを別途組み合わせる構成が現実的です。「Shieldstralとは」でこの層の考え方を整理しています。

他のオープンモデルとの違い

K2 Horizonを検討するなら、比較対象は同じ「Apache 2.0でセルフホストできるモデル」になります。

モデル

規模

ライセンス

特徴

K2 Horizonとの選び分け

K2 Horizon(IFM)

0.9B〜375B(6サイズ)

Apache 2.0

完全オープン・エージェント特化・6サイズ艦隊

学習過程まで検証したい/サイズを使い分けたい

Trinity Large(Arcee AI)

400B級

Apache 2.0

米国発のフロンティア級OSS

米国拠点であることを重視する場合

Inkling(Thinking Machines)

975B(アクティブ41B)

Apache 2.0

マルチモーダル入力・1Mコンテキスト・カスタマイズ前提

画像・音声入力が必要な場合

GLM 5.2(Zhipu)

753B

MIT

ベンチマーク上位・商用利用しやすいMIT

純粋な性能を優先する場合

Muse Glimmer(Meta)

30B

オープンウェイト

ローカル動作・長文脈が強い

30B級で長文脈を重視する場合

LLM-jp-4 33B(NII)

33B

Apache 2.0

国産・日本語特化・学習データ公開

日本語業務が主用途の場合

Kimi K3(Moonshot AI)

2.8T

オープンウェイト

最大級のパラメータ数

規模と生の性能を優先する場合

各モデルの詳細は「Arcee AI Trinity Largeとは」「Thinking Machines Inklingとは」「GLM 5.2とは」で個別に解説しています。

「第三の道」という位置づけ

アナリストのPatrick Moorhead氏(Moor Insights & Strategy)は、K2 Horizonを「米国のクローズドな商用モデル」と「透明性を欠く中国ラボのオープンウェイトモデル」の第三の道と位置づけています。IFM自身もLlama / Qwen / DeepSeekとの直接対決を主張しているわけではありません。

一方で同氏は、「UAE拠点の機関が開発したモデルを、企業が地政学的に信頼するかは未解決の論点」とも指摘しています。ただしApache 2.0でセルフホストできる以上、データを外部に出さずに使える点は事実であり、これがオープンモデルを選ぶ最大の実務的メリットです。データが自社ネットワークから出ないなら、開発元の所在地リスクは推論の実行段階では大きく下がります。

オープンモデルを取り巻く現在の勢力図は「中国製AIモデルがOpenRouter利用の60%超え」、オープンウェイト公開の是非をめぐる議論の反対側の立場は「Anthropicのオープンウェイトモデルに対する立場」で扱っています。

こんな人・組織におすすめ

K2 Horizonが合うのは、次のようなケースです。

  • 機密情報・個人情報を扱い、外部APIにデータを出せない組織。Apache 2.0でセルフホストでき、商用利用も再配布も可能。オンプレ要件・ベンダーロックイン回避の両方に応えます
  • 1つのモデルではなく複数サイズを使い分けたい開発チーム。共通の語彙・チャットテンプレート・デプロイツールで6サイズが揃っているため、「軽いタスクは3.7B、重い判断だけ375B」といった動的ルーティングが組みやすい
  • エージェント・ツール利用が主用途。tau3-Banking・MCPMark・Terminal-Benchといったエージェント系ベンチマークで同クラスを上回っています
  • エッジ・組込にLLMを載せたい。0.9B(約1.8GB、4bit量子化で約0.45GB)は同サイズ帯で異例の性能を示しています
  • 学習過程まで検証したい研究者・技術者。中間チェックポイントと学習ログが公開される(予定を含む)モデルはフロンティア級ではほぼ存在しません
  • 既存のオープンモデルを自社データでファインチューニングしたい。3.7B / 7BはApache 2.0で改変・再配布が自由です

おすすめしない人・組織

一方で、次のケースでは他の選択肢を検討したほうが確実です。

  • とにかく最高精度がほしい。HLE・GPQA・CritPtではGPT-5.6 / Claude Sonnet5 / GLM 5.2に届いていません
  • 日本語の業務精度を最優先する。日本語ベンチマークが公開されておらず、実力が未検証です。国産LLMを先に検討すべきです
  • API単価を前提にコスト試算をしたい。パートナー各社の公開価格が確認できていません
  • GPUを持たず、すぐ使い始めたい。実質コストは自前推論のGPU費用です。手軽さを求めるならクラウドの商用モデルのほうが早く安く済みます
  • 32B級のdenseモデルを性能だけで選びたい。公式表でもQwen3.8-27Bのほうが多くの項目で上です
  • 安全性フィルタを含めてベンダーに任せたい。オープンウェイトモデルはガードレールが利用者責任です
  • UAE拠点の機関が開発したモデルであることが調達要件上ネックになる。組織のポリシー次第では選定対象外になり得ます

よくある質問

Q. 商用利用はできますか?
A. モデル本体とコードはApache 2.0なので、商用利用・改変・再配布が可能です。ライセンス表示・変更点の明示・特許条項の遵守が条件になります。ただしデータセットはApache 2.0とは限りません。ODC-BY等それぞれのライセンスが適用され、再配布不可のものは構築レシピのみ公開されています。データを二次利用する場合は個別に確認してください。

Q. Kimi K2と同じものですか?
A. まったく別物です。K2 HorizonはUAEのMBZUAI傘下IFM、Kimi K2 / K2.6 / K3は中国のMoonshot AIが開発しており、技術的なつながりはありません。

Q. 学習データは本当に全部公開されていますか?
A. 「公開する」と宣言されていますが、発表時点では段階的です。375B-A23BのHugging Faceモデルカードには「中間チェックポイント・学習データ・学習コードは別途公開予定」と記載されています。GitHubのifm-aiにはxllmhorizon-post-trainunoが公開済みで、Hugging FaceのIFM組織には17データセットが掲載されています。

Q. Ollamaで動きますか?
A. 動きますが、2026年9月上旬時点でOllama公式ライブラリには未掲載です。ollama run hf.co/IFM/K2-Horizon-32B-GGUF:BF16のようにHugging Face経由で指定する形になります。

Q. 日本語は使えますか?
A. 多言語データを含むとされていますが、日本語での評価結果は公式に公開されていません。実務投入を検討するなら、自社の実データで必ず事前検証してください。

Q. 一番小さい0.9Bは何に使えますか?
A. 公式は「腕時計で動くほど小さい」と表現しており、スマートウォッチ・スマートグラス・組込機器を想定しています。HumanEval+ 79.9・AIME 2026 48.5と、サイズの割に定型的なコーディングや数学は解けます。ただしコンテキストは128Kで、複雑な探索を伴うタスクには向きません。

Q. 375Bは自社サーバーで動かせますか?
A. BF16重みだけで約750GBあり、公式の検証構成は8×H200です。一般的な社内サーバーでは現実的ではありません。自前運用を前提にするなら、MoVA-36B-A4Bか32Bが実質的な上限になります。

Q. Terminal-Benchのスコアは70.2と66.9のどちらが正しいですか?
A. 70.2が報告値、66.9が報酬ハッキング監査で不正な合格を除外した後の値です。実力として参照すべきは66.9ですが、この監査を自ら実施・公表したこと自体がIFMの信頼性を高めているという評価もあります。

まとめ:K2 Horizonをどう位置づけるか

K2 Horizonは、「性能で頂点を取るモデル」ではなく「検証できるモデル」として理解するのが正確です。GPT-5.6やClaude Sonnet5と真正面から戦えるわけではありませんが、エージェント・ツール利用では健闘し、何よりデータ・コード・中間チェックポイントまで公開するという姿勢は他に代わりがありません。

日本の組織にとっての現実的な使い道は、次の3つに集約されます。

  1. 機密データを外に出せない業務で、MoVA-36B-A4Bか7Bをオンプレ運用する
  2. エッジ・組込機器に0.9B / 3.7Bを載せる
  3. 報酬ハッキング監査の内容を、社内のAIエージェント導入時のリスク評価チェックリストとして流用する

公開から日が浅く、中間チェックポイント・学習データの公開進捗、API提供状況と価格、Ollama公式ライブラリ掲載、第三者ベンチマーク、日本語評価の登場など、今後変わる可能性のある要素が多く残っています。本記事の記載は公式ブログ・Hugging Faceモデルカード・プレスリリースに基づいており、導入判断の前には各一次情報を直接確認することをおすすめします。

次に読むなら、同じApache 2.0のフロンティア級OSSである「Arcee AI Trinity Largeとは」、日本語用途を前提にした「LLM-jp-4 33Bとは」、実際にローカルで動かす手順をまとめた「Ollamaとは」が参考になります。

このツールを自社の毎月の業務に組み込むと何が変わるか、ご提案します

業務を1つ送る

この記事の著者

AI革命

AI革命

編集部

AI革命株式会社の編集部です。最新のAI技術動向から実践的な導入事例まで、企業のデジタル変革に役立つ情報をお届けしています。豊富な経験と専門知識を活かし、読者の皆様にとって価値のあるコンテンツを制作しています。

経理・事務作業・開発を、AI革命にまとめて任せられます

ご相談は無料です。オンラインで完結します