AIREITER從 0.9B 一路到 375B，K2 Horizon 一次端出六款模型，看起來像是完整覆蓋各種部署需求的產品階梯；但真正進入自架規劃後，成本並沒有這麼直線。K2 Horizon 採用 Apache 2.0，省掉的是模型授權費；MoVA 降低的是活躍運算量；模型儲存、KV cache、推論執行環境與硬體成本，則一項都不會因此消失。
K2 Horizon 六款 Apache 2.0 模型包含什麼
IFM 在 2026 年 9 月 3 日發布 K2 Horizon，將六款模型定位為可互相搭配的模型艦隊：375B-A23B、36B-A4B、32B、7B、3.7B 與 0.9B。公告指出，模型與程式碼皆以 Apache 2.0 發布；資料集則依各自適用的授權條款提供（IFM announcement）。
同一模型家族，但發布完成度並不相同
六個成員的定位如下：
| 模型 | 架構 | 官方定位 | 官方資料標示的上下文 |
|---|---|---|---|
| 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 model card 將目前可見的 checkpoint 標示為 Stage1，並說明最終 checkpoint 尚未發布。相對地，MoVA 36B-A4B 與 375B-A23B 的 model card 都稱最終 checkpoint 已釋出。因此，「已公布六款模型」沒有問題；但不能把它解讀成「六款都已是同等成熟的最終生產 checkpoint」（32B model card, 375B model card）。
Apache 2.0 對自架團隊省了什麼，又沒有省什麼
Apache 2.0 允許團隊修改、再散布，以及將模型與其程式碼整合至商業產品，不需支付按 token 計費的授權費。IFM 也指出，資料集遵循個別條款，例如 ODC-BY；受限制的來源不能直接再散布（IFM announcement）。
但 Apache 2.0 取消的是授權支出，不是營運帳單。GPU 租用或折舊、模型儲存空間、KV cache 容量、推論環境工程、監控與資安審查，全都還是成本；此外，36B serving recipe 與 375B model card 的範例也都使用 trust_remote_code=True。
用記憶體需求來看六種模型規模
參數量適合拿來比較模型容量，但對自架而言，第一道限制通常是原始權重需要多少儲存空間。以下估算以每個參數 2 bytes 的 BF16，以及理想化的每個參數 0.5 byte 的 4-bit 表示法計算；不包含中繼資料、執行期緩衝區、KV cache、tokenizer 檔案與作業系統記憶體。
| 模型 | 規劃時採用的總參數量 | 每 token 的活躍參數 | 原始 BF16 規劃下限 | 理想化 4-bit 下限 | 實務部署層級 |
|---|---|---|---|---|---|
| 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 的 model card 將模型稱為「7B-core」，但 Hugging Face metadata 顯示其參數量為 9B。容量規劃應以實際 repository 檔案為準，不能只看模型家族名稱（7B model card）。
實際 repository 檔案也說明了，這些數字只是下限，不是可直接套用的承諾。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 是家族中說明文件最完整的選項：其 model card 涵蓋推理與 tool-call parser、單裝置 tensor-parallel 設定，以及量化版本。卡片上的 benchmark 表格顯示，該模型在 SWE-bench Verified 為 70.6%、Terminal-Bench 2.1 為 39.1%、tau3-Banking 為 25.8%；但所有結果都採用高推理強度，且 model card 也提醒，不同協定細節可能造成差異（7B model card）。
7B 的 model card 建議使用高推理強度，且至少設定 32,768 output tokens。更長的推理會拉長生成時間，因此即使模型塞得進記憶體，實際牆鐘時間成本也可能很高。
本地工作站與伺服器級距：32B、36B-A4B
32B 是全 Dense 模型，行為與資源需求相對容易推估；但規劃時真正要面對的限制，是它目前仍處於 Stage1，以及官方列出的 69.6 GB GGUF 檔案大小（32B Stage1 GGUF）。
MoVA 36B-A4B 則帶來另一個問題：一個活躍運算量低得多、但總容量更大的模型，能否逼近 Dense 模型的能力？IFM 的 GGUF benchmark 表格顯示，它在 tau3-Banking 為 26.8%、Terminal-Bench 2.1 為 58.6%，並在後者領先列出的比較模型；不過，它並非在所有科學、事實性或長上下文指標上都領先（36B GGUF benchmark card）。
權重載入後，較低的活躍參數量可能改善持續推論的吞吐量；但實際結果仍取決於 backend、batching、互連架構與量化方式。
旗艦級距：375B-A23B
官方 model card 記錄了一個經驗證的 K2 Horizon 375B-A23B SGLang 設定：使用 八張 H200 GPU、tensor parallelism 8、expert parallelism 8、BF16 與 FlashAttention-3（375B model card）。
總參數與活躍參數的比例，確實可以比 Dense 375B 模型少掉部分運算；但約 750GB 的 BF16 規劃下限，仍清楚劃出了基礎設施門檻。Artificial Analysis 顯示其 Intelligence Index 為 47，在該頁面顯示的類別中位居 112 個模型中的第 #11 名；但沒有提供輸出速度，也沒有任務成本資料（Artificial Analysis profile）。
以目前已記錄的八張 H200 驗證設定來看，這應視為叢集級部署。
MoVA 改變運算經濟性，卻不會降低儲存門檻
MoVA 是 Mixture-of-Value Attention 的縮寫。一般 mixture-of-experts 架構通常將稀疏路由放在 feed-forward layer；IFM 對 MoVA 的描述是，將 expert routing 延伸到 attention 的 value component，同時維持與 FlashAttention、grouped-query attention 等技術的相容性（IFM architecture explanation）。
36B-A4B 這個名稱真正代表的數字
「36B-A4B」同時傳達兩種不同的量：模型可用的總參數約為 36B，但每個 token 約只有 4B 參數會被啟用。這有機會降低活躍路徑的 multiply-and-accumulate 運算與記憶體流量，尤其對持續生成的工作負載更有意義。
但這不代表沒有啟用的 experts 就不必存放。官方 BF16 GGUF 檔案為 74.9 GB；vLLM recipe 則描述此模型有 37.44B stored parameters including embeddings，並且每 token 有 5.95B active parameters per token。這些是同一個架構在封裝與統計方式上的不同呈現，不代表另有一個獨立的 37B 模型（vLLM recipe）。
可以用以下方式理解：
- 常駐容量：儲存空間與記憶體必須容納所有可能被選中的權重。
- 活躍運算：每個 token 只會執行經路由選出的部分參數。
- 執行期狀態：KV cache、暫存 buffer、batching 與框架額外負擔依然存在。
- 系統成本：互連、電力、主機 RAM 與維運時間，最終決定帳單金額。
512K 上下文規格不等於可直接編列的預算
較大模型的 K2 Horizon model card 宣稱原生上下文長度為 524,288 tokens。但 MoVA 36B-A4B 與 375B-A23B 公開的 vLLM recipes 都設定為 --max-model-len 131072，也就是宣稱上限的四分之一（36B vLLM recipe, 375B model card）。
131K 的 recipes 已經說明，原生支援 512K context 不代表能免費當作推論預設值：上下文越長，KV cache 消耗越大、可支援並發越低，prompt latency 也會增加。
把自架情境換算成成本判斷
K2 Horizon 沒有透明、通用的 API 定價可作為比較基準。官方 MoVA GGUF 頁面表示目前沒有 inference provider 部署此模型；Artificial Analysis 雖在 375B profile 顯示輸入與輸出價格皆為 $0.00，但速度與每任務成本標示為 unavailable。這並不能證明存在免費的正式生產 endpoint（MoVA GGUF card, Artificial Analysis）。
| 情境 | 能獲得什麼 | 主要經濟風險 | 結論 |
|---|---|---|---|
| 24GB 級 GPU 搭配適用的 4-bit 36B 量化版本 | 低成本實驗與隱私優勢 | 上下文與並發餘裕很小；量化與 runtime 支援可能還不成熟 | 適合試點，不是有保證的生產目標 |
| 32B BF16 或 36B BF16 工作站 | 較高保真度，品質比較也較單純 | 尚未計入 cache 與 runtime 記憶體前，權重就要 64–75GB | 通常需要多 GPU 或高記憶體系統 |
| 雙 H200 等級的 36B 推論服務 | 符合已記錄的 MoVA serving 型態 | 租用、主機、儲存與使用率成本 | 適合持續服務或受控評測 |
| 八張 H200 的 375B 推論服務 | 旗艦級容量與企業規模吞吐量 | 龐大的資本支出或按時基礎設施承諾 | 僅適合叢集級部署 |
24GB 級 GPU 的實驗情境
36B 模型理想化的 4-bit 權重下限約為 18GB，在 24GB 顯示卡上只剩不到 6GB 可供量化中繼資料、runtime buffers 與 KV cache 使用。這樣的算術顯示，24GB 級硬體在中等上下文下進行測試有其可行性；但這不代表存在通用最低規格，實際量化格式、backend、offload 政策與 prompt 長度，仍會決定推論是否真的可用。
官方引用的 MoVA GGUF artifact 是 BF16，而非小型消費級量化版本。Hugging Face collection 雖列出整個家族的 GGUF 與 FP8 版本，但發布初期的轉換與相容性工作，仍應納入部署預算（K2 Horizon collection）。
「I assume they are still uploading other GGUFs--all I see is a BF16 GGUF so far」 — u/apoptosist in r/LocalLLaMA。
依官方文件跑 36B 的雙 H200 路徑
IFM 的 MoVA vLLM recipe 使用 tensor parallelism 2、expert parallelism、BF16，以及 131,072-token 的服務上限。其 SGLang 文件表示，這個設定已在 2× H200 上驗證；這比單看模型名稱更能作為硬體需求的參考訊號（vLLM recipe, official GGUF card）。
雲端供應商公開費率也說明了使用率為何關鍵。DigitalOcean 列出的專用 NVIDIA H200 為每 GPU-hour $4.47，8× H200 設定則是每小時 $35.78；Google Cloud 列出的 8× H200 A3 Ultra machine 為每小時 $84.806908493，該 machine-type 價格已包含附加的 vCPU、記憶體與 SSD（DigitalOcean pricing, Google Cloud pricing）。
以列出的單 GPU 費率計算，兩張 H200 約為每小時 $8.94，或每 730 小時一個月 $6,526，尚未包含主機與儲存成本；這只能當成對使用率敏感的參考值，不是雙 GPU 的正式報價。
375B-A23B 的八張 H200 部署
旗艦模型的官方 serving recipe 使用八張 H200、TP=8、EP=8 與 BF16。這個設定符合該模型約 750GB 的原始 BF16 規劃下限，也直接點出它的企業級門檻（375B model card）。
Google 列出的 8× H200 machine 價格為每小時 $84.81，以 730 小時計算約為$61,909，未含稅金、資料傳輸、持久化儲存與應用程式維運。這是基礎設施費用參考，不是 K2 Horizon 的價格，也不保證公開 recipe 能達到某個特定 tokens-per-second 表現。
早期自架實測能證明什麼，不能證明什麼
早期回報證實 K2 Horizon 可以跑起來，但不同量化方式與 runtime 的結果，尚不足以建立通用的成本效能曲線。
一則較詳細的 X 回報，就很能說明 backend 的影響有多大：
「36B-A4B MoVA does 131-142 tok/s on 2x 5090 with llama.cpp (IFM's fork, Q8_0, 131K ctx) vs 52 on vLLM...」 — @abtraore_。
這份有參考價值、但未受控的回報，正好說明「MoVA 比較快」這種說法若不附上 backend 與設定，其實並不完整。
Reddit 討論則顯示，量化、小 VRAM、模型比較與 tool-call 等問題仍未完全釐清，尚不能視為經驗證的效能資料（r/LocalLLaMA thread）。
若要做嚴肅的採購決策，目前缺少的關鍵量測包括：不同量化下的常駐記憶體、KV cache 隨上下文成長的曲線、prompt 與生成速度、tool-call 穩定性、耗電量，以及在同一受控工作負載下每個成功任務的成本。
不要被活躍參數行銷帶著走，先看使用率
該選哪一款 K2 Horizon，取決於它會跑得多頻繁、需要多長的上下文，以及輸出品質是否值得相應的基礎設施成本。短期試點應優先考慮可逆性；全天候的私有服務則應優先考慮使用率與營運穩定性。
| 你的工作負載 | 建議起點 | 原因 | 何時停止或升級 |
|---|---|---|---|
| 穿戴式、嵌入式或範圍明確的分類任務 | 0.9B | 佔用空間最小，並宣稱支援 128K context | 工具使用深度或領域覆蓋成為瓶頸時 |
| 精簡本地助理或微調實驗 | 3.7B | 儲存負擔低，推理範圍比 0.9B 更廣 | 程式開發與失敗恢復問題開始主導結果時 |
| 第一個認真的本地 coding/agent 試點 | 7B | 已有 parser、tensor parallelism 與量化版本文件 | 長任務需要更可靠的規劃或工具使用能力時 |
| 需要 Dense 基準的高能力工作站 | 謹慎選擇 32B Stage1 | Dense 行為較容易比較，但目前 checkpoint 尚未完成 | 最終 checkpoint 與實測結果足以證明記憶體投入合理時 |
| 重複進行本地／伺服器推論，且活躍運算量重要 | MoVA 36B-A4B | 較低活躍參數量，且有記錄的 TP=2/EP 路徑 | 上下文、並發或 runtime 摩擦抵銷效率優勢時 |
| 企業級推理與長週期代理 | 375B-A23B | 家族中容量最高，且有記錄的 8× H200 路徑 | 單任務成本或使用率無法通過商業案例檢驗時 |
進行第一個試點時，切換模型前應先記錄五個數值：峰值 VRAM/RAM、prompt 長度、首 token 時間、每秒生成 token 數，以及每個完成任務的成本。在工作負載證明更長上下文值得付出 cache 與延遲代價前，先把 context limit 維持在文件所列的 131,072 tokens。
若問題只是某台機器適合哪個家族成員，可參考另一篇 K2 Horizon model sizing guide，它專門處理較狹義的模型選擇問題。本文則把重點放在使用率與實測的任務成本，而不是活躍參數標籤。
K2 Horizon 模型常見問題
Apache 2.0 是否代表所有 K2 Horizon 資料集也都是 Apache 2.0？
不是。IFM 表示模型與程式碼採用 Apache 2.0，但資料集遵循各自適用的授權，例如 ODC-BY。在進行再散布或商業訓練前，應檢查每個 repository 與資料集的條款（IFM announcement）。
4B active 是否表示 K2 Horizon MoVA 36B-A4B 只需要 4B 模型等級的記憶體？
不是。模型每個 token 約啟用 4B 參數，但官方 BF16 GGUF 約為 74.9GB。實際記憶體需求仍由權重儲存、KV cache、runtime buffers、量化額外負擔與並發量共同決定。
單張 24GB GPU 能跑 K2 Horizon MoVA 36B-A4B 嗎？
合適的 4-bit 量化可能讓中等上下文實驗具備可行性，因為理想化的 36B 權重下限約為 18GB。但官方 BF16 artifact 與已驗證的雙 H200 serving 路徑都需要更多餘裕，因此 24GB 的結果應視為試點設定，而非通用的生產保證。
宣稱的 512K context 是否具有經濟效益？
不一定。model card 標示原生上下文為 524,288 tokens，但文件中的 vLLM 範例使用 131,072 tokens；更長的上下文會增加 KV-cache 需求與延遲，通常也會降低並發能力。
K2 Horizon 375B-A23B 算是一般可自架的模型嗎？
不是。IFM 文件記錄的是八張 H200 的 SGLang 設定，而原始 BF16 規劃下限在未計入 runtime overhead 前就約為 750GB。除非供應商發布更小的驗證設定，否則應將它視為企業或叢集型部署。
K2 Horizon 375B 顯示的 $0.00 價格，是否代表真的有免費 API？
沒有資料支持這種結論。Artificial Analysis 顯示輸入與輸出價格為 $0.00，但速度與每任務成本均列為 unavailable；官方模型頁面也沒有 Hugging Face inference provider。在將此數字納入預算前，應先確認具名供應商的合約與費率表。