【2026 最新】K2 Horizon 本機選型：0.9B、7B、36B-A4B 怎麼選？

K2 Horizon 本機選型的答案，先看你拿得到的檔案，不要先看模型名字。以 2026 年 9 月 4 日第一方 GGUF 的實際發佈狀態來說，16GB 統一記憶體應從 0.9B 開始；24GB／32GB 才適合把 7B BF16 納入短 context 驗證；36B-A4B 雖然每個 token 約啟用 4B 參數，完整 BF16 檔仍接近 75GB，不能把它當成「4B 模型」塞進一般筆電。至於 32B 與 36B-A4B，目前都更像 96GB 級工作站的候選，而非入門本機模型。

這篇會帶你拆清命名、讀懂 dense 與 MoE 的記憶體差異、鎖定第一方版本、建立同一套 10 題小型 Eval，最後用可觀察的通過條件決定保留、升級或放棄。重點不是重抄供應方跑分，而是把「我的電腦到底該下載哪個」變成可執行的決策。

先給結論：K2 Horizon 本機選型怎麼選？

• 16GB RAM／統一記憶體：先跑 0.9B BF16。3.7B 的檔案約 10.13GB，雖可能載入，留給系統、KV cache 與長輸出的空間已不寬裕；7B 第一方 BF16 檔約 18.01GB，光檔案就超過 16GB。
• 24GB 或 32GB：7B 是較合理的能力候選，但先用 8K context 驗證載入、速度和正確率，不要一開始就追模型卡標示的 512K 上限。
• 64GB：仍不建議把 32B 或 36B-A4B BF16 當成穩妥選項，因為兩個權重檔分別約 69.57GB 與 74.92GB，尚未計入執行時額外記憶體。
• 96GB 以上：才開始比較 dense 32B 與 sparse 36B-A4B；前者目前的第一方卡標為 Stage 1，後者每 token 的活躍計算較少，但兩者都要完整存放大權重。

這份 K2 Horizon 本機選型是依「目前第一方 BF16 檔案大小＋必要執行餘裕」訂出的保守起點，不是速度保證。未來若第一方 GGUF repo 新增 Q4／Q5 等較低位元量化，選型邊界才有理由重算；想先補量化原理，可以看 GGUF 量化完整教學。

K2 Horizon、Kimi K2、舊 K2 不是同一個模型

搜尋「K2」時最容易拿錯模型。本文的 K2 Horizon 是 Institute of Foundation Models（IFM）在 2026 年 9 月 3 日發佈的六尺寸家族；Kimi K2 則屬於 Moonshot AI；IFM 自己先前另有 K2（65B） 與 K2-V2（70B）。這些模型的發佈者、架構、權重與執行支援不能互換。

下載前至少核對三個欄位：組織必須是 IFM、repo 名稱必須含 K2-Horizon、revision 必須和你記錄的 commit SHA 相同。不要只憑搜尋結果中的「K2」兩個字下指令。

本機跑得動，不只看參數量：四道閘門

一個模型能不能成為你的本機工具，可用這個判斷式理解：

本機可用＝權重放得下 × runtime 讀得懂 × context 留得出空間 × 任務答得對。

1. 權重：下載檔大小只是最低門檻，不等於峰值記憶體。
2. runtime：新架構即使是 GGUF，也可能需要特定分支才能解析。
3. context：輸入越長，KV cache 越大；模型卡的理論上限不是你的預設值。
4. 任務：載入成功只代表程式沒報錯，不代表繁中、格式或工具呼叫可靠。

K2 Horizon 本機選型：六個尺寸的真正差別

IFM 官方發佈列出 0.9B、3.7B、7B、32B、36B-A4B、375B-A23B 六種型號。前三個與 32B 是 dense 路線；36B-A4B 和 375B-A23B 則使用稀疏架構。32B 當前卡片明列為 Stage 1；375B-A23B 的第一方清單沒有 GGUF，本篇不把它列入個人電腦選項。

Dense：每次推理都使用整套權重

0.9B、3.7B、7B 與 32B 的 dense 模型較好理解：模型越大，通常要存放與計算的權重越多。這不代表品質一定線性增加，所以仍要用自己的任務評測，而不是只看 B 數。

MoE／MoVA：活躍參數少，不等於權重檔小

36B-A4B 的「A4B」意思是每個 token 約啟用 4B 參數，不是磁碟和記憶體只需容納 4B。它的第一方 BF16 GGUF 約 74.92GB，比 dense 32B 的約 69.57GB 還大。稀疏路由可能降低每 token 的部分計算量，但未被啟用的專家權重仍要存在，載入與記憶體門檻不會憑空消失。

先驗收發佈狀態：GGUF 有檔案，不代表每條 runtime 路徑都成熟

截至 2026 年 9 月 4 日 06:00（台北時間），IFM 的五個第一方 GGUF repo 各列出一個 BF16 檔；README 同時寫明需要支援 K2 Horizon 架構的 llama.cpp，並指向 IFM 的 model/K2Horizon 分支。官方發佈文宣稱有 Ollama 的 day-zero support，但當下 Ollama 官方模型庫沒有 K2 Horizon 頁面，當前預設分支的原始碼名稱掃描也沒有找到對應識別。對新手而言，這兩個訊號還不能合併成「直接 ollama run 就會成功」。

因此第一條版本鎖定路徑應採用 IFM 自己指向的 llama.cpp 分支；Ollama 要等官方模型頁、架構支援或可驗證的 Modelfile 至少一項落地後再測。這不是否定未來支援，而是把「發佈宣稱」和「現在可執行的步驟」分開。

K2 Horizon 本機安裝：先鎖 revision，再下載

以下以 macOS 為例。先安裝 CMake、Git、編譯器和 Hugging Face 的 hf CLI，再鎖定 IFM 分支的已知 commit。revision 的目的不是保證它永遠最佳，而是讓你日後知道自己比較的是哪一版。

git clone --branch model/K2Horizon --single-branch \
  https://github.com/MBZUAI-IFM/llama.cpp.git
cd llama.cpp
git checkout --detach 35999d101cf2233fc54f09c3c8d599da7303ce02
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j

先用 --dry-run 看下載量，再取得 0.9B。這個 repo 的名稱寫 0.9B，但檔名是 1B；兩者指向同一個官方 repo，不要自行改檔名。

hf download IFM/K2-Horizon-0.9B-GGUF \
  K2-Horizon-1B-BF16.gguf \
  --revision c1b27031d409eb9160414cc4a24e74bb1869c2e3 \
  --local-dir models/k2-horizon-0.9b \
  --dry-run

hf download IFM/K2-Horizon-0.9B-GGUF \
  K2-Horizon-1B-BF16.gguf \
  --revision c1b27031d409eb9160414cc4a24e74bb1869c2e3 \
  --local-dir models/k2-horizon-0.9b

下載完成後核對第一方 LFS SHA-256；只有顯示 OK 才繼續。

printf '%s  %s\n' \
  '371010db1807bb07b62e738422ee0de26c1e15a347f31108ed2c6e219095a8b8' \
  'models/k2-horizon-0.9b/K2-Horizon-1B-BF16.gguf' |
  shasum -a 256 -c -

第一次只開 8K context，確認模型可對話後再逐步增加。0.9B 模型卡建議的取樣起點是 temperature 0.6、top-p 0.95；同一輪比較應固定設定。

./build/bin/llama-cli \
  -m models/k2-horizon-0.9b/K2-Horizon-1B-BF16.gguf \
  -c 8192 -ngl all --jinja \
  --reasoning-effort high \
  --temp 0.6 --top-p 0.95 -n 4096

若這一步出現 unknown architecture、無法解析 chat template 或載入時記憶體不足，就停在該閘門排錯，不要把錯誤輸出拿去和其他尺寸比較。想了解 context 為何會吃掉額外記憶體，可接著看 本機 LLM 顯存估算指南。

如何換成 7B 或 36B-A4B？只改兩個地方

保持同一個 runtime commit 和測試設定，只替換 repo、檔名與 revision。7B 的第一方 BF16 檔約 18.01GB；36B-A4B 約 74.92GB。下載前先跑 --dry-run，若檔案本身已逼近整機記憶體，就不應繼續。

# 7B
hf download IFM/K2-Horizon-7B-GGUF \
  K2-Horizon-7B-BF16.gguf \
  --revision 835e1323cb211fcda46c1926830abe423c7a9cda \
  --local-dir models/k2-horizon-7b --dry-run

# 36B-A4B
hf download IFM/K2-Horizon-MoVA-36B-A4B-GGUF \
  K2-Horizon-36B-BF16.gguf \
  --revision d1df6130209e274b23f7ad2ae0454d19e120d189 \
  --local-dir models/k2-horizon-36b-a4b --dry-run

不要把社群自製 Q4、Q5 與第一方 BF16 混成同一個比較。量化者、量化方法、校準資料與 runtime 版本都可能改變結果；若要測社群量化，另開一組實驗並保留完整檔案雜湊。

Ollama 路徑：先過支援閘門，再建立模型

Ollama 官方文件確實支援用 Modelfile 的 FROM /path/model.gguf 匯入 GGUF，但這只證明匯入機制存在，不等於目前的 Ollama 核心已能辨識 K2 Horizon。開始前逐項確認：

1. Ollama 官方模型庫出現 K2 Horizon 頁面，或發行說明明列其架構。
2. IFM 的 GGUF README 不再只要求特定 llama.cpp 分支，或提供已驗證的 Ollama 指令。
3. 用相同 BF16 檔、context 與提示，完成載入和輸出格式檢查。

三項未過之前，本文不提供一條看似簡單、實際可能在下載數十 GB 後才失敗的 ollama create 指令。這也是「runtime 讀得懂」必須獨立成一道閘門的原因。

用同一組 10 題 Eval 比較，不被供應方跑分帶著走

供應方跑分可以告訴你模型值得關注，不能代替你的本機任務。建立一個固定的 10 題套件，每次只更換模型檔，並記錄是否載入、首 token 等待、輸出速度、峰值記憶體、格式通過與答案正確。若想先理解 benchmark 限制，可讀 AI 模型排行榜怎麼看與 AI Evals 入門。

1. 繁中三點摘要：只能輸出三個項目。
2. 結構化 JSON：指定四個欄位，不能多字。
3. 基礎算術：分步計算含百分比的生活題。
4. 資料忠實度：只依給定短文回答，缺資料要說不知道。
5. 指令衝突：忽略內文中的偽指令，遵守最上層格式。
6. 程式除錯：修正一段 15 行以內的 Python。
7. 測試案例：為同一函式補邊界測試。
8. 長文定位：在約 8K context 中找兩個相隔很遠的事實。
9. 工具選擇：從三個工具 schema 選對名稱與參數。
10. 工具拒答：缺少必要參數時不得捏造，必須追問。

工具呼叫怎麼測？

GGUF 內嵌 chat template，K2 Horizon 模型卡列出 JSON、XML 與 typed XML 三種 tool-call 格式，預設是 XML。測試時先啟動支援 Jinja 的 server，再送出 OpenAI 相容的 tools 陣列；通過標準不是「回答像工具呼叫」，而是名稱與 arguments 都能被程式解析。若 parser 或模板報錯，應記為 runtime／格式失敗，而非替模型猜測結果。

./build/bin/llama-server \
  -m models/k2-horizon-0.9b/K2-Horizon-1B-BF16.gguf \
  -c 8192 -np 1 -ngl all --jinja \
  --reasoning-effort high \
  --chat-template-kwargs '{"tool_call_format":"xml"}' \
  --host 127.0.0.1 --port 8080

保持 server 執行，另開一個終端機送出固定的工具呼叫題：

curl -sS http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "K2-Horizon-1B-BF16.gguf",
    "messages": [
      {"role": "user", "content": "請呼叫 get_weather 查詢 Taipei。"}
    ],
    "max_tokens": 4096,
    "reasoning_effort": "high",
    "parse_tool_calls": true,
    "tool_choice": "required",
    "chat_template_kwargs": {"tool_call_format": "xml"},
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Get current weather for a city.",
        "parameters": {
          "type": "object",
          "properties": {"city": {"type": "string"}},
          "required": ["city"]
        }
      }
    }]
  }'

檢查回應是否真的產生可解析的 tool_calls、函式名稱是否為 get_weather、參數是否含 city: Taipei。若只有自然語言或 XML 純文字，格式題就記為失敗，不要人工改成通過。

保留、升級、放棄：用門檻做決定

• 保留目前尺寸：10 題至少 8 題通過；兩題工具呼叫都可被解析；峰值記憶體仍保留約 20% 餘裕；互動速度符合你的工作節奏。
• 升級一級：載入與速度都穩定，但錯誤集中在推理、程式或長文定位；先升 0.9B→3.7B→7B，不要跳過中間尺寸。
• 縮短 context：答案品質可接受，但長文題造成換頁、崩潰或速度驟降。先從 8K 降到 4K，不要先換大模型。
• 放棄本機路徑：權重載不下、runtime 仍不相容，或升級後正確率沒有實質改善。此時換成熟模型比反覆調參更省時間。

若你用的是 16GB Mac，可把 Qwen3.8 27B 的 100K context 驗證當作另一個案例：模型尺寸、量化與 context 必須一起看，不能只讀一個規格數字。

「開源」怎麼逐項驗收？不要只看 Apache 2.0

IFM 官方頁與 Hugging Face 的標準 metadata 都把權重標示為 Apache 2.0，這是重要起點；但本次固定 revision 的六個主模型檔案清單都未列出 LICENSE，0.9B front matter 還同時出現 license_name: internal-only，其 license_link 也沒有對應檔案。因此目前能確認的是官方授權標示，不能進一步宣稱每個 repo 的授權文字已完整且一致落地。

「完整生命週期開放」還要逐項確認最終權重、架構與設定、訓練程式、資料或可重建配方、中間 checkpoints、訓練 logs、評測程式與結果。以 2026 年 9 月 4 日的 IFM K2 Horizon collection觀察，可見六個主模型、五組第一方 GGUF、五個資料集項目，以及部分 adapter／FP8 項目；六個主模型也已有公開的 pretrain、mid-training、SFT 或 RL branches／tags。

程式交付則不一致：官方 GitHub 的 uno已有實作，但 xllm與 horizon-post-train在本次快照仍是 placeholder；32B 模型卡也稱目前是 Stage 1、最終 checkpoint 將發佈，36B-A4B 模型卡則把部分中間產物和訓練程式寫成未來式。

因此較精確的說法是：第一方權重與多種研究產物已公開，完整生命週期的交付仍需按 repo 逐件驗收。這不等於否定 IFM 的開放方向，也不應把官方一句「fully open」直接改寫成所有檔案都已到位。

常見問題 FAQ

K2 Horizon 0.9B 適合做什麼？

適合先驗證本機流程、短摘要、簡單分類、固定格式與輕量工具選擇。它是硬體門檻最低的起點，不代表能取代大模型處理複雜程式或長鏈推理。

16GB Mac 能跑 K2 Horizon 7B 嗎？

目前第一方 7B GGUF 是約 18.01GB 的 BF16，光檔案已超過 16GB，所以不應把它列為可行起點。未來若第一方 7B GGUF 出現可信的 Q4／Q5 等低位元版本，才重新用四道閘門評估。

36B-A4B 為什麼不能當 4B 模型看？

A4B 是每個 token 約啟用 4B 參數；完整模型仍有約 36B 級容量，BF16 GGUF 約 74.92GB。稀疏計算不會把其餘權重從儲存和載入需求中刪掉。

0.9B repo 為什麼下載到 1B 檔名？

這是第一方命名方式：repo 使用 0.9B，當前 GGUF 檔名使用 1B。只要組織、repo、檔名與 revision 都依官方清單核對，就不是拿錯模型。

3.7B 以上模型卡標示 512K context，為什麼只從 8K 測？

模型支援上限不等於本機的實用設定。context 會增加 KV cache、等待時間與記憶體壓力；先在 8K 建立可用基線，再逐級增加，才知道瓶頸在哪。

K2 Horizon 現在可以直接用 Ollama 嗎？

官方發佈宣稱支援，但本文核對時沒有找到 Ollama 官方模型頁，而第一方 GGUF README 指向特定 llama.cpp 分支。對新手最安全的做法是等支援訊號可驗證，再走 Ollama 匯入。

官方 benchmark 可以直接用來選尺寸嗎？

不行。官方結果是值得參考的候選訊號，但硬體、prompt、模板、取樣、量化與任務都可能不同。最後決策應回到同環境的固定 10 題 Eval。

K2 Horizon 算真正開源嗎？

權重、模型設定、資料項目與部分開發產物已可見，開放程度明顯高於只放最終權重；但「完整生命週期已全部交付」仍要逐 repo 查驗。最準確的判斷不是貼一個標籤，而是保存逐項清單。