AIREITER0.9Bから375Bまで、6モデルを揃えたK2 Horizonは一見すると導入規模に応じて選びやすいラインアップに見える。ただし、実運用の経済性はそこまで単純ではない。K2 HorizonはApache 2.0によりモデルライセンス料を不要にし、MoVAでアクティブな計算量を抑える。一方で、ストレージ、KVキャッシュ、ランタイム、ハードウェアにかかるコストまでなくなるわけではない。
Apache 2.0で公開されたK2 Horizonの6モデル
IFMは2026年9月3日、K2 Horizonを6モデルからなる統合ファミリーとして発表した。構成は375B-A23B、36B-A4B、32B、7B、3.7B、0.9B。モデル本体とコードはApache 2.0で公開され、データセットにはそれぞれのライセンスが適用される（IFM announcement）。
6モデルは共通基盤だが、完成度は一律ではない
ファミリーを構成するモデルは以下のとおり。
| モデル | アーキテクチャ | 公式の想定用途 | 公式資料で示されたコンテキスト長 |
|---|---|---|---|
| K2 Horizon 0.9B | Dense | 腕時計、スマートグラス、制約の大きいエッジデバイス | 128K / 131,072 tokens |
| K2 Horizon 3.7B | Dense | スマートフォン、ファインチューニング、軽量なローカル作業 | 512K / 524,288 tokens |
| K2 Horizon 7B | Dense | スマートフォン、ローカルアシスタント、コーディング、エージェント | 512K / 524,288 tokens |
| K2 Horizon 32B | Dense | ワークステーションおよびオンプレミスサーバー | 512K / 524,288 tokens |
| K2 Horizon MoVA 36B-A4B | Sparse MoE + MoVA | ローカルおよび効率重視のサービング | 512K / 524,288 tokens |
| K2 Horizon 375B-A23B | Sparse MoE | 企業向けおよびマルチアクセラレータ環境 | 512K / 524,288 tokens |
0.9Bのみ語彙サイズが小さいものの、ファミリー内ではアーキテクチャとデプロイツールが概ね共通している。この共通基盤は、モデルサイズをまたぐ移行やルーティングを容易にする狙いがある（IFM press release）。
ただし、リリースの成熟度には注意が必要だ。公式のK2-Horizon-32Bカードでは、公開中のチェックポイントをStage1とし、最終チェックポイントは今後リリース予定だと明記している。一方、MoVA 36B-A4Bと375B-A23Bのカードでは、最終チェックポイントが公開済みとされる。「6モデルが発表された」は正しいが、「6つとも完成済みのプロダクション用チェックポイント」とは言えない（32B model card、375B model card）。
セルフホスト側から見たApache 2.0のメリットと限界
Apache 2.0なら、チームはモデルとコードを改変、再配布、商用統合でき、トークンごとの利用料も発生しない。IFMによれば、データセットにはODC-BYなど個別の条件が適用され、制限付きソースは直接再配布できない場合がある（IFM announcement）。
Apache 2.0がなくすのはライセンス料金であって、運用費ではない。GPUのレンタル費または減価償却、モデル保存領域、KVキャッシュ、ランタイム実装、監視、セキュリティレビューは依然として必要になる。さらに、36B serving recipeと375B model cardのサンプルには、いずれもtrust_remote_code=Trueが使われている。
まず見るべきはパラメータ数ではなくメモリ
パラメータ数はモデル能力の比較には便利だが、セルフホストでは重みを載せるためのストレージ容量が最初の制約になる。以下の試算では、BF16をパラメータあたり2バイト、理想化した4ビット表現を0.5バイトとしている。メタデータ、ランタイムバッファ、KVキャッシュ、トークナイザーファイル、OSのメモリは含まない。
| モデル | 計画時に使う総パラメータ数 | トークンごとのアクティブパラメータ数 | BF16の生の必要容量目安 | 理想化した4ビット時の下限 | 実用上のクラス |
|---|---|---|---|---|---|
| K2 Horizon 0.9B | 0.9B | 0.9B | ~1.8 GB | ~0.45 GB | エッジ／組み込み実験向け |
| K2 Horizon 3.7B | 3.7B | 3.7B | ~7.4 GB | ~1.85 GB | コンパクトなローカル／モバイル用途 |
| K2 Horizon 7B | 7B-class | 7B-class | ~14 GB* | ~3.5 GB* | 本格的なローカル検証の入口 |
| K2 Horizon 32B | 32B | 32B | ~64 GB | ~16 GB | ワークステーションまたはサーバー |
| K2 Horizon MoVA 36B-A4B | 36B | ~4B | ~72 GB | ~18 GB | 量子化ワークステーションまたはマルチGPUサービング |
| K2 Horizon 375B-A23B | 375B | ~23B | ~750 GB | ~187.5 GB | 企業／クラスタ規模 |
\*7Bのモデルカードは「7B-core」と表記する一方、Hugging Faceのメタデータでは9B parametersと表示される。容量計画ではファミリー名だけでなく、実際のリポジトリファイルを確認すべきだ（7B model card）。
実際のリポジトリを見ると、これらが保証値ではなく下限にすぎない理由が分かる。0.9BのBF16 GGUFは2.16 GB、3.7BのBF16 GGUFは10.1 GB、32B Stage1のBF16 GGUFは69.6 GB、MoVA 36BのBF16 GGUFは74.9 GBと記載されている（0.9B GGUF、3.7B GGUF、32B GGUF、36B GGUF）。
エッジ向けの0.9B、3.7B、7B
0.9Bと3.7Bはストレージ負荷を最小限に抑えられる。複雑なリカバリーを要するエージェントよりも、リソース制約のある環境で対象を絞ったワークロードに向く（0.9B model card、3.7B GGUF card）。
最初のローカル実験なら、ファミリーの中では7Bが最も情報を揃えた選択肢だ。モデルカードには推論・ツールコール用パーサー、単一デバイスでのテンソル並列設定、量子化バリアントが記載されている。掲載ベンチマークでは、SWE-bench Verifiedで70.6%、Terminal-Bench 2.1で39.1%、tau3-Bankingで25.8%を報告している。ただし全結果は高い推論努力量で測定されており、プロトコルの詳細が異なる場合があるとも警告されている（7B model card）。
7Bカードでは、高い推論努力量と少なくとも32,768 output tokensを推奨している。推論を長くすれば生成時間も増えるため、メモリには収まるモデルでも実時間コストが高くなりうる。
ローカル／サーバー向けの32Bと36B-A4B
32Bは完全なDenseモデルで、挙動を理解しやすい。ただし、計画上の本当の制約はStage1という公開状況と、公式の69.6 GB GGUFだ（32B Stage1 GGUF）。
MoVA 36B-A4Bは別の問いを投げかける。アクティブな計算量を大幅に減らしながら、より大きな総容量を維持してDenseモデルに近い能力を出せるか、という点だ。IFMのGGUFベンチマーク表では、tau3-Bankingで26.8%、Terminal-Bench 2.1で58.6%を記録し、後者では掲載比較モデル群の首位となっている。ただし、科学、事実性、長文コンテキストの全指標で首位というわけではない（36B GGUF benchmark card）。
重みを常駐させた後は、アクティブパラメータ数の少なさが持続的なスループット改善につながる可能性がある。ただし結果は、バックエンド、バッチング、インターコネクト、量子化に左右される。
フラッグシップの375B-A23B
公式モデルカードでは、K2 Horizon 375B-A23B向けに、eight H200 GPUs、テンソル並列度8、エキスパート並列度8、BF16、FlashAttention-3を使う検証済みSGLang構成が紹介されている（375B model card）。
総パラメータ数に対するアクティブパラメータ数の比率により、Dense 375Bより計算量を減らせる可能性はある。それでも、およそ750GBというBF16の生の必要容量目安が、インフラ要件の境界を決める。Artificial AnalysisではIntelligence Index score 47、表示クラス内で#11 of 112とされる一方、出力速度とタスクコストは未掲載だ（Artificial Analysis profile）。
現在文書化されているeight-H200の検証済み構成を基準にする限り、これはクラスタ規模のデプロイとして扱うべきだ。
MoVAが減らすのは計算コストであり、重みの保存容量ではない
MoVAはMixture-of-Value Attentionの略だ。一般的なMixture-of-Expertsでは、主にフィードフォワード層で疎なルーティングを行う。IFMはMoVAについて、FlashAttentionやgrouped-query attentionなどと互換性を保ちながら、Attentionのvalueコンポーネントにもエキスパートルーティングを拡張する仕組みだと説明している（IFM architecture explanation）。
36B-A4Bという表記が示すもの
「36B-A4B」には異なる2つの数値が含まれている。利用可能な総パラメータ数はおよそ36Bで、各トークンでアクティブになるのはおよそ4Bだ。この仕組みにより、とくに生成を継続するワークロードでは、アクティブ経路における積和演算とメモリトラフィックを減らせる可能性がある。
ただし、使われないエキスパートがメモリから消えるわけではない。公式のGGUFファイルはBF16で74.9 GBあり、vLLMのレシピでは埋め込みを含めて37.44Bの保存パラメータ、トークンごとに5.95Bのアクティブパラメータを持つモデルとして説明されている。この差は別の37Bモデルを意味するものではなく、同じアーキテクチャをパッケージングや集計方法の違いから表現した数値だ（vLLM recipe）。
考え方を整理すると、次の4層になる。
- 常駐容量：選択されうる重みをすべて保持できるストレージとメモリが必要。
- アクティブ計算：各トークンで実際に使うのはルーティングされた一部だけ。
- ランタイム状態：KVキャッシュ、一時バッファ、バッチング、フレームワークのオーバーヘッドは残る。
- システムコスト：インターコネクト、電力、ホストRAM、運用工数が最終的な請求額を左右する。
512Kコンテキストをそのまま予算にしてはいけない理由
K2 Horizonの大きいモデルでは、ネイティブコンテキストとして524,288 tokensが掲げられている。しかし、MoVA 36B-A4Bと375B-A23Bの公開vLLMレシピはいずれも--max-model-len 131072で設定されており、これは公称最大値の4分の1だ（36B vLLM recipe、375B model card）。
131Kのレシピから分かるのは、ネイティブ512Kコンテキストが無料で使えるサービングのデフォルトではないことだ。コンテキストを長くするとKVキャッシュを消費し、同時実行数が減り、プロンプトのレイテンシも増える。
セルフホスティングをコスト別に考える
K2 Horizonには、比較の基準にできる透明かつ共通のAPI料金表がない。公式MoVA GGUFページでは、このモデルをデプロイしている推論プロバイダーは現時点でいないとされる。Artificial Analysisの375Bプロファイルでは入力・出力価格が$0.00と表示されるが、速度とタスクあたりコストは利用不可となっている。これを無料の本番エンドポイントの証拠とみなすべきではない（MoVA GGUF card、Artificial Analysis）。
| シナリオ | 得られるもの | 主な経済的リスク | 判断 |
|---|---|---|---|
| 適切な4ビット36B量子化を使う24GBクラスGPU | 低コストの検証とプライバシー | コンテキストと同時実行数の余裕が小さい。量子化とランタイムの対応が未成熟な可能性 | パイロットには最適。本番稼働を保証する構成ではない |
| 32B BF16または36B BF16のワークステーション | より高い忠実度と、品質を比較しやすい環境 | キャッシュとランタイムメモリを除いても64～75GBの重みが必要 | 通常はマルチGPUまたは大容量メモリのシステムが必要 |
| Two-H200-style 36B serving | 文書化されたMoVAサービング構成に合う | レンタル、ホスト、ストレージ、稼働率のコスト | 継続的なサービスまたは管理された評価に妥当 |
| Eight-H200 375B serving | フラッグシップの容量と企業規模のスループット | 大きな設備投資または時間課金インフラへのコミットメント | クラスタ規模に限定 |
24GBクラスGPUでの実験
36Bモデルの理想化した4ビット時の下限は約18GBで、24GBカードでは量子化メタデータ、ランタイムバッファ、KVキャッシュ向けに6GB未満しか残らない。この計算なら、中程度のコンテキストで24GBクラスのテストを行うことはあり得る。ただし、普遍的な最低要件を示すものではない。利用可能かどうかは、実際の量子化方式、バックエンド、オフロード方針、プロンプト長で決まる。
引用した公式MoVA GGUFアーティファクトは、小型コンシューマー向け量子化ではなくBF16だ。Hugging Faceのコレクションには、ファミリー全体でGGUFおよびFP8のバリアントが掲載されているが、リリース初日の変換作業と互換性確認もデプロイ予算に含める必要がある（K2 Horizon collection）。
「他のGGUFをまだアップロード中なのだと思う。現時点で見えるのはBF16 GGUFだけだ」 — r/LocalLLaMAのu/apoptosist。
文書化された36B構成はH200を2基
IFMのMoVA向けvLLMレシピは、テンソル並列度2、エキスパート並列、BF16、131,072トークンのサービング上限を使う。SGLangのドキュメントでは、この構成が2× H200で検証済みとされており、モデル名だけよりも強いハードウェア要件の手がかりになる（vLLM recipe、official GGUF card）。
公開されているプロバイダー料金を見ると、稼働率が重要な理由が分かる。DigitalOceanは専用NVIDIA H200を$4.47 per GPU-hour、8× H200構成を$35.78 per hourで掲載している。Google Cloudは、vCPU、メモリ、SSDをマシンタイプ料金に含む8× H200 A3 Ultraを$84.806908493 per hourで掲載している（DigitalOcean pricing、Google Cloud pricing）。
掲載されたGPU単価を基にすると、H200を2基使う場合は約$8.94 per hour、または730時間の月で$6,526となる。ホストとストレージのコストは含まない。これは稼働率に大きく左右される参考値であり、2 GPU構成の見積もりではない。
375B-A23BにはH200を8基
フラッグシップの公式サービングレシピは、H200を8基、TP=8、EP=8、BF16で動かす構成だ。この設定は、およそ750GBというBF16重みの生の必要容量目安と整合し、企業向けの境界線を明確にしている（375B model card）。
Googleの掲載する8× H200マシン料金$84.81 per hourは、730時間で約$61,909になる。税金、データ転送、永続ストレージ、アプリケーション運用は含まれない。これはインフラ費用の参考値であり、K2 Horizonの価格ではない。また、公開レシピが特定のtokens-per-secondを達成する保証でもない。
初期のセルフホスト報告から分かること、分からないこと
初期報告から、K2 Horizonを実行できること自体は確認できる。ただし量子化やランタイムが混在しており、普遍的なコスト性能曲線を導ける段階ではない。
バックエンドによる差の大きさを示す例として、詳細なX投稿がある。
「36B-A4B MoVAは、2x 5090上のllama.cpp（IFMのfork、Q8_0、131K ctx）で131-142 tok/s。vLLMでは52 tok/s……」 — @abtraore_。
有用ではあるが制御されていないこの報告は、「MoVAは速い」というだけでは不十分で、バックエンドと構成を併記しなければならないことを示している。
Reddit上の議論では、量子化、小容量VRAM環境、比較、ツールコールに関する未解決の疑問が見られる。検証済みの性能値ではない（r/LocalLLaMA thread）。
本格的な購入判断には、量子化別の常駐メモリ、コンテキストに応じたKVキャッシュの増加量、プロンプト処理速度と生成速度、ツールコールの信頼性、消費電力、同一ワークロードでの成功タスクあたりコストが必要になる。
アクティブパラメータ数の宣伝より、稼働率で選ぶ
どのK2 Horizonモデルが適切かは、実行頻度、必要なコンテキスト量、そして出力品質がインフラコストに見合うかで決まる。短期パイロットでは後戻りしやすさを優先し、常時稼働するプライベートサービスでは稼働率と運用安定性を優先したい。
| ワークロード | まず試すモデル | 理由 | 停止またはアップグレードの条件 |
|---|---|---|---|
| ウェアラブル、組み込み、または分類器のように対象を絞ったタスク | 0.9B | 最小のフットプリントと128Kコンテキストの訴求 | ツール利用の深さまたはドメインカバレッジがボトルネックになったとき |
| コンパクトなローカルアシスタントまたはファインチューニング実験 | 3.7B | 0.9Bより広い推論能力を持ちながら、ストレージ負荷が小さい | コーディングやリカバリーの失敗が支配的になったとき |
| 最初の本格的なローカルコーディング／エージェントのパイロット | 7B | パーサー、テンソル並列、量子化バリアントが文書化されている | 長いタスクで、より信頼できる計画またはツール利用が必要になったとき |
| Denseモデルをベースラインにした高性能ワークステーション | 32B Stage1、慎重に | Denseモデルは比較しやすいが、現チェックポイントは最終版ではない | 最終チェックポイントと実測結果がメモリ消費を正当化したとき |
| アクティブ計算量が重要な、反復的なローカル／サーバー推論 | MoVA 36B-A4B | アクティブパラメータ数が少なく、TP=2/EPの文書化されたパスがある | コンテキスト、同時実行数、ランタイムの摩擦によって効率化の利点が消えたとき |
| 企業向け推論および長期的なエージェント | 375B-A23B | ファミリー最大容量で、8× H200の文書化されたパスがある | タスクあたりコストまたは稼働率がビジネスケースを満たさないとき |
最初のパイロットでは、モデルを変更する前に5つの値を記録したい。ピークVRAM/RAM、プロンプト長、最初のトークンが出るまでの時間、1秒あたりの生成トークン数、完了タスクあたりコストだ。ワークロードがキャッシュとレイテンシのコストを払う価値を示すまで、コンテキスト上限は文書化済みの131,072 tokensに維持する。
特定のマシンにどのファミリーメンバーが収まるかを知りたい場合は、別記事のK2 Horizon model sizing guideが、その選定課題をより狭く扱っている。ここではアクティブパラメータ数のラベルより、稼働率と実測したタスクコストを重視する。
K2 Horizonモデル FAQ
Apache 2.0なら、K2 HorizonのすべてのデータセットもApache 2.0ですか？
いいえ。IFMによれば、モデルとコードはApache 2.0だが、データセットにはODC-BYなど該当するライセンスが適用される。再配布や商用トレーニングに使う前に、各リポジトリとデータセットを確認する必要がある（IFM announcement）。
4B activeなら、K2 Horizon MoVA 36B-A4Bに必要なメモリは4Bモデル並みですか？
いいえ。各トークンでアクティブになるのはおよそ4Bパラメータだが、公式BF16 GGUFは約74.9GBある。実際のメモリ要件は、重みの保存、KVキャッシュ、ランタイムバッファ、量子化オーバーヘッド、同時実行数で決まる。
単一の24GB GPUでK2 Horizon MoVA 36B-A4Bを実行できますか？
適切な4ビット量子化なら、36B重みの理想化した下限が約18GBであるため、中程度のコンテキストでの実験は現実的になりうる。公式BF16アーティファクトと、検証済みのH200 2基サービングパスにははるかに大きい余裕が必要なので、24GBでの結果は一般的な本番保証ではなくパイロット構成として扱うべきだ。
公称512Kコンテキストは経済的にサービングできますか？
自動的にそうなるわけではない。モデルカードは524,288トークンのネイティブコンテキストを示す一方、文書化されたvLLMの例では131,072トークンを使っている。コンテキストが長いほどKVキャッシュ需要とレイテンシが増え、多くの場合は同時実行数も下がる。
K2 Horizon 375B-A23Bは一般的なセルフホストモデルですか？
いいえ。IFMはH200を8基使うSGLang構成を文書化しており、BF16重みの生の必要容量目安はランタイムオーバーヘッドを除いても約750GBだ。プロバイダーがより小さい検証済み構成を公開しない限り、企業またはクラスタ向けデプロイとして扱うべきだ。
K2 Horizon 375Bで表示される$0.00は、実際に無料のAPIという意味ですか？
そのような結論を裏付ける情報はない。Artificial Analysisでは入力・出力価格が$0.00と表示されているものの、速度とタスクあたりコストは利用不可で、公式モデルページにもHugging Face推論プロバイダーはない。この数値を予算に使う前に、名前の明示されたプロバイダーの契約と料金表を確認すべきだ。