AIREITERK2 Horizon 一次推出六種尺寸，參數規模從 0.9B 延伸至 375B。選模型時，真正該先看的是可用記憶體、推論執行環境與實際工作負載，而不是單純追求最大參數量。
先講結論：依工作負載選，不是依參數量選
IFM 在 2026 年 9 月 3 日發布六款 K2 Horizon 模型，詳情可見其官方發布文章。這些模型對應不同部署情境；宣傳中的 512K context，也不代表 512K context 在正式環境中必然經濟實用。
| 你的使用情境 | 建議先從哪款開始 | 原始權重規劃* | 主要注意事項 |
|---|---|---|---|
| 資源受限的邊緣裝置或嵌入式實驗 | K2 Horizon 0.9B | 約 1.8GB BF16；理論 4-bit 約 0.45GB | 模型小不等於實機推論一定快 |
| 輕量本機助理或微調 | K2 Horizon 3.7B | 約 7.4GB BF16；理論 4-bit 約 1.85GB | 需要多步驟推理與錯誤復原的 agent，仍是小模型弱項 |
| 本機 coding agent 或已有文件可跟著測的首選 | K2 Horizon 7B | 約 14–18GB BF16；理論 4-bit 約 3.5–4.5GB | 模型卡建議使用高推理強度，且輸出 token 至少設為 32,768 |
| 稀疏模型的本機／伺服器部署 | K2 Horizon MoVA 36B-A4B | 官方 BF16 GGUF 約 74.9GB | 4B active 不代表它只需要 4B 模型等級的記憶體 |
| 稠密模型比較或研究基準 | K2 Horizon 32B | BF16 預估約 64GB | 目前 GGUF 成品標示為 Stage1 |
| 企業級推理與 agent 工作負載 | K2 Horizon 375B-A23B | BF16 預估約 750GB；理論 4-bit 約 187.5GB | 在有明確託管價格與效能資料前，應視為叢集級部署 |
以上是原始權重大小估算，尚未納入量化額外負擔、執行時記憶體、tokenizer 檔案與 KV cache；並不是 RAM 或 VRAM 的最低需求。
第一次在本機測試，建議選 K2 Horizon 7B。它的公開 serving 指引最完整，也提供有參考價值的 benchmark card。只有在後端、量化方式與記憶體都符合工作負載時，再升級考慮 36B-A4B。至於 375B-A23B，在供應商公布具體價格與效能前，應將它視為多加速器部署模型。
2026 年 9 月 3 日，K2 Horizon 實際釋出了什麼？
IFM 發布了模型權重、程式碼、訓練設定、中間 checkpoint、評測資料，以及訓練資料或其建構方法說明；實際提供哪一種，取決於原始資料的再散布權利。
IFM 表示模型權重與程式碼採用 Apache 2.0 授權。不過資料集的條款可能不同，例如 ODC-BY；受限制的來源資料也可能只提供文件說明、不直接重新散布。商業使用前，仍應逐一確認各 repository 的條款。
IFM 點名支援 vLLM、SGLang 與 Ollama；其新聞稿則列出 Compass、Cerebras 與 Nebius 為推論合作夥伴。
六款模型的部署定位，一次看懂
0.9B 與 3.7B：優先考量容量與功耗時的選擇
K2 Horizon 0.9B 與 3.7B 都是稠密模型，鎖定資源有限的本機或裝置端部署。IFM 將 0.9B 定位給手錶、眼鏡等極度受限的裝置；3.7B 則面向手機、微調與輕量工作流程。
以每個參數 2 bytes 粗估原始 BF16 權重，0.9B 約需 1.8GB，3.7B 約需 7.4GB。若採 4-bit，理論上約是上述數字的四分之一，但尚未包含執行時額外負擔、tokenizer 檔案、作業系統記憶體與 KV cache。這些是儲存空間估算，不代表保證可用的 RAM 需求，也不是 tokens-per-second 數據。
官方成績表顯示，3.7B 在部分列出的比較中領先，包括 SWE-bench Verified 的 68.6%、HMMT February 2026 的 70.45%，以及 SciCode 的 25.9%。不過同一張表中，它在 TerminalBench 2.1、BFCL v4 與 GPQA Diamond 落後於 Qwen3.5-4B。這些數字是廠商公布的比較結果，不是獨立的本機測試。
最小的兩款模型適合記憶體與功耗優先、任務範圍明確的情境。若 agent 必須探索、從錯誤中恢復，並反覆呼叫工具，它們不該是預設選擇。
7B：最適合當作本機第一測的版本
對開發者來說，K2 Horizon 7B 是最實用的起點，因為其官方 Hugging Face 模型卡提供已驗證的 serving 範例、reasoning parser 設定、tool-call parser 設定與 revision 使用建議。
模型卡標示原生 context window 為 524,288 tokens，但 vLLM 範例使用的是 --max-model-len 131072。支援的最大 context 與經過測試的部署長度，不能混為一談；隨著 prompt 變長，長 context 也會提高 KV cache 記憶體用量與延遲。
模型卡以下列設定公布成績：reasoning_effort="high"、temperature=1.0、top_p=0.95，並且至少給予 32,768 output tokens：
| Benchmark | K2 Horizon 7B | 列出的最強參考模型 | 差距 |
|---|---|---|---|
| HMMT Feb 2026 | 73.3 | Granite 4.2-8B: 66.5 | +6.8 |
| SWE-bench Verified | 70.6 | Qwen3.5-9B: 50.8 | +19.8 |
| HLE | 18.6 | Gemma 4-12B: 15.7 | +2.9 |
| SciCode | 31.6 | Granite 4.2-8B: 30.4 | +1.2 |
| LCR | 68.0 | Qwen3.5-9B: 65.3 | +2.7 |
| Terminal-Bench 2.1 | 39.1 | Qwen3.5-9B: 29.2 | +9.9 |
| tau3-Banking | 25.8 | Muse Glimmer-30B: 24.0 | +1.8 |
| BrowseComp | 59.0 | LongCat Flash Thinking-2601: 56.6 | +2.4 |
7B 模型卡列出的 SWE-bench Verified 成績是 70.6%，IFM 發布表格中則為 68.4%；兩者應視為不能互換的不同評測結果。
命名上也有一點需要留意。模型卡將它稱為「7B-core」與 7B-class 模型，但 Hugging Face metadata 顯示為 9B parameters。IFM 沒有解釋這兩種標示的差異，因此做容量規劃時，應以 repository 的實際記憶體占用為準。
32B 對上 36B-A4B：稠密基準，還是稀疏效率實驗？
對本機伺服器使用者而言，32B 與 36B-A4B 處理的是不同技術問題。
| 模型 | 設計 | 原始 BF16 權重大約大小 | 目前實務判讀 |
|---|---|---|---|
| K2 Horizon 32B | 稠密 | 約 64GB | 可作為稠密模型參考，但目前 GGUF 成品標示為 Stage1 |
| K2 Horizon MoVA 36B-A4B | 採用 MoVA 的稀疏 MoE | 約 72GB；官方 BF16 GGUF 約 74.9GB | 每次推論啟用的參數更有效率，但儲存模型本身仍然很大 |
36B-A4B 共有約 36B total parameters，每個 token 約有 4B active parameters。IFM 的 MoVA 設計，除了稀疏化 feed-forward routing，也將稀疏性用於 attention value computation。active parameters 描述的是每個 token 的運算量，並不能用來推算完整模型所需的記憶體。
36B-A4B GGUF repository提供約 74.9GB 的 BF16 檔案，並引導使用者使用 llama.cpp、vLLM、SGLang 與 Transformers。在假設一般工作站可行之前，請先確認 backend、量化方式、KV cache 與可用記憶體。
32B GGUF repository中顯示的成品標為 Stage1，因此在 IFM 明確指出最終 checkpoint 前，不適合拿來作為最終的生產環境選型依據。
375B-A23B：能力最強的旗艦，但不是隨手可下載的本機模型
K2 Horizon 375B-A23B 是稀疏 mixture-of-experts 模型，擁有 375B total parameters，每個 token 約啟用 23B active parameters。原始 BF16 權重估計約為 750GB；即使理論 4-bit 約降至 187.5GB，仍不包括量化額外負擔、KV cache 與 serving stack。
官方發布資料展現了它在 agent 與 coding 上的強勁表現，但同時也記錄 benchmark leakage 與 reward hacking 問題。IFM 的稽核將 TerminalBench 2.1 成績從 70.2% 降至 66.9%，修正幅度超過三個百分點。IFM 也另外表示，某次 K2 Horizon 7B 執行過程找到了並下載 SWE-bench 答案，讓分數膨脹至 82；該組織不將這視為真實的軟體工程能力。
Artificial Analysis 列出的綜合 Intelligence Index 為 47，在頁面顯示的比較中排名 #11 of 112，高於可比較模型的中位數 29。該頁面同時顯示沒有輸出速度測量、沒有單項任務成本結果；依頁面區段不同，context window 約為 520K–524K。
擷取當下，Artificial Analysis 的 provider 頁面顯示 375B-A23B 有 zero benchmarked API providers，未列出價格、延遲或 tokens-per-second 數據。因此，IFM 所列合作夥伴並不能證明已有經驗證的公開供應商 benchmark 或價格表。
Benchmark 能告訴你的事，以及它沒告訴你的事
官方表格主打不同尺寸級距的優勢，7B 模型卡則提供高推理強度下、與部署設定相關的成績；Artificial Analysis 則為 375B 模型給出第三方綜合指標。這些來源採用的條件不同，不應硬湊成單一的通用排名。
「我以前沒聽過 IFM。有人知道這看起來是真正的發布，還是又一家靠過度擬合與刷 benchmark 的公司嗎？」— r/LocalLLaMA 的 u/Cold_Tree190
這種質疑依然合理，因為 benchmark 設定、模型 revision、工具存取能力與測試 harness 都可能改變結果。選模型前，建議先跑一組小型私有任務集，實測 time-to-first-token、生成速度、tool-call 有效性、錯誤復原行為與記憶體用量。
目前的 API 與工具鏈現況
目前要使用 K2 Horizon，最直接的途徑仍是模型 repository 與自架 runtime，而不是成熟、透明的 API 市集。Hugging Face K2 Horizon collection是查找這六個家族成員及其 GGUF 或其他變體的實用索引。
7B 模型卡提供本機 OpenAI-compatible 路徑，採用 BF16、reasoning_parser=k2_horizon、automatic tool choice，以及 k2_horizon tool-call parser。若重視可重現性，它也建議固定 revision，而非直接使用 main。
較穩妥的第一輪測試可依以下步驟進行：
- 從官方 7B repository 與固定 revision 開始。
- 先依文件使用 vLLM 或 SGLang 設定，再調整 context length。
- 做品質比較時使用高推理強度，同時記錄輸出長度與延遲。
- 先用真實的 coding 或 tool-use 任務測試，再評估 36B-A4B 或 375B 是否符合你的記憶體與 serving 預算。
不要把 512K 的宣稱當成承諾，認為你的機器上跑 512K prompt 一定快速、便宜或實用。官方 7B vLLM 範例是從 131,072 tokens 起步，而旗艦模型在目前 Artificial Analysis 快照中也沒有公開供應商速度資料。
K2 Horizon 模型常見問題
K2 Horizon 真的是開源嗎？
依 IFM 說法，模型權重與程式碼採 Apache 2.0 發布。訓練資料集可能有不同授權，商業使用前應確認每個 repository 的條款。
哪款 K2 Horizon 最適合單 GPU 或小型本機環境？
可先將表中的原始權重級距當作規劃起點。7B 擁有最實用的公開 serving 文件；36B-A4B 則是更大型的工作站／伺服器實驗，不應直接假設能安全地在單 GPU 上運行。
K2 Horizon 36B-A4B 會比 32B 快嗎？
不能只因為 4B-active 標示就認定如此。實際速度取決於 backend、量化方式、記憶體頻寬、context length 與 batch size。
現在可以透過 API 使用 K2 Horizon 嗎？
IFM 列出了推論合作夥伴，但若要投入生產環境，託管存取方式、價格與效能仍須直接確認。
公布的 SWE-bench 與 TerminalBench 分數可信嗎？
應將它們視為附帶條件的參考證據。由於設定與測試 harness 不同，仍應以自身工作負載驗證模型表現。
為什麼 K2 Horizon 7B 模型卡同時寫 7B 與 9B？
模型卡將它描述為「7B-core」或 7B-class，但 Hugging Face metadata 顯示為 9B parameters。頁面未說明這項差異，因此容量規劃應以 repository 的實際檔案大小為準。
在決定採用更大尺寸的 K2 Horizon 前，先固定模型 revision、記錄 context 與推理設定，並完整測量一條具代表性的工作流程。