我透過同一個 API 將相同的程式設計任務送給 Kimi K2.7 Code 和 Claude Opus 4.8，並測量回傳結果。在正確性方面，它們打成平手：兩者都成功解出一個 SemVer precedence 陷阱和一個隱藏的 interval-merge 錯誤。不過，Opus 的回應速度快了 3–9 倍，而且輸出的 tokens 只有四分之一；相較之下，Kimi 在標價下每個任務的成本大約低了 46%。所以這個選擇不是在於哪個模型「更聰明」。如果你執行的是對成本敏感或批次式的 coding 工作，Kimi K2.7 在價格上更有優勢。如果你需要低延遲、1M-token context，或是一個你信任的最終審查模型，Opus 4.8 值得這個溢價，而且許多團隊最後都會在兩者之間進行路由。
實測：我將相同的程式開發任務分別交給兩者執行
我是如何測試的：使用模型 ID kimi-k2.7-code 和 claude-opus-4-8，透過同一個 OpenAI 相容的 gateway endpoint 於 2026-07-13 呼叫，每個任務採單次輸出、使用預設參數，且未使用 prompt caching。Latency 是在 client 端以實際經過時間（wall-clock）測得，因此包含 network 和 queue time，而不只是 generation。評分前，我要求每個模型自我識別作為健全性檢查（sanity check）；Kimi 回傳「made by Moonshot AI」，Opus 回傳 Anthropic；這是 routing 檢查，不是版本證明。這是一個兩個任務的樣本，不是 benchmark。它展示的是你能感受到的行為；無法衡量多輪 agentic performance。
任務 1 要求每個模型依照 SemVer 2.0.0 規範實作 compare_semver() 函式，包含大多數實作最常出錯的部分：pre-release 優先順序，其中 1.0.0-alpha.1 < 1.0.0-alpha.beta，數字識別碼的順位低於字母數字識別碼，且 beta.11 > beta.2 是依數值而非字串順序比較。我根據規範的標準排序建立了一個 72 次比較矩陣，並據此評分每個答案。任務 2 提供了一個有 bug 的 merge_intervals() 函式，其真正缺陷是將 last[1] = cur[1] 寫成了應該使用 max(...) 的地方；這一行會悄悄吞掉像 [1,10],[2,3] 這種完全被包含的區間。我以 5 個案例進行評分，其中包括該被包含的區間。
指標 | Kimi K2.7 Code | Claude Opus 4.8 |
|---|---|---|
任務 1 正確率（72 個優先順序 + 邊界案例） | 72/72 | 72/72 |
任務 2 正確率（5 個案例，含包含區間） | 5/5 | 5/5 |
任務 1 延遲（用戶端） | 49.1s | 5.3s |
任務 2 延遲（用戶端） | 11.5s | 7.6s |
任務 1 token（輸入 / 輸出） | 172 / 1,907 | 774 / 418 |
任務 1 成本（原生標價） | $0.0078 | $0.0143 |
成本是根據上方的 token 數量，按原生標價計算得出（Kimi 每百萬輸入/輸出 $0.95/$4，Opus $5/$25）：Kimi = 172×$0.95/M + 1,907×$4/M ≈ $0.0078；Opus = 774×$5/M + 418×$25/M ≈ $0.0143。輸入 token 數量不同（172 vs 774），是因為各模型的 tokenizer 以及 gateway 的計費方式會對同一個 prompt 做不同的計算，而不是因為任務不同。兩個模型在兩個任務上都產出了完全正確的程式碼。差別在於它們達成結果的方式。Opus 簡潔且快速，在任務 1 上於 5.3 秒內返回了 418 個 token。Kimi 則花了 49.1 秒，並輸出了 1,907 個 token，其中大部分是它與程式碼一併返回的逐步推理軌跡。然而，由於 Kimi 的 token 價格大約便宜 6 倍，這次冗長的執行仍然更省錢。
這場對決證明了什麼，以及沒有證明什麼
這證明在有界、明確定義的編碼問題上，Kimi K2.7 Code 能達到與前沿模型相同的正確答案。這並不能證明 Kimi 在長時間、多步驟的 agentic 會話中能與 Opus 匹敵，因為這兩個單次任務無法檢驗這一點。Kimi 自身最強的主張也正是在這個 agentic 領域，而下方的基準測試正是直接針對此一領域。
基準測試：第三方與 Moonshot 自有表格有何不同
以下是細項拆解，每個數字都標註了來源。Moonshot 自行回報的表格是 Kimi 看起來最強的部分；獨立評測則較為稀少，因為這個模型較新，而且在尚未有第三方 K2.7 數據的地方，下面標示的最接近已公布數字是 K2.6。
基準 | Kimi K2.7 Code | Claude Opus 4.8 | 來源 |
|---|---|---|---|
MCPMark Verified（工具使用） | 81.1 | 76.4 | Moonshot，自報 |
SWE-bench Verified | 60.4% | 未以相同格式發布 | Moonshot，自報 |
Intelligence Index | 35（K2.6 proxy） | 56 | Artificial Analysis，第三方 |
Output speed | ~45 tok/s（K2.6 proxy） | 59 tok/s | Artificial Analysis，第三方 |
這項比較所依據的唯一數字，MCPMark Verified 81.1 對 76.4，來自 Moonshot 的自家表格，而非獨立實驗室。這不代表它就該被否定，因為 MCP 風格的工具使用正是 Kimi 的調校重點。但應把「Kimi 勝過 Opus」這個標題理解為供應商對其自家優化基準的主張。在第三方測得的唯一一組正面交鋒中，Artificial Analysis 在其 Intelligence Index 上讓 Opus 4.8 明顯領先（56 對 35），不過該列使用 K2.6 作為代理，因為撰寫本文時 K2.7 尚未經過獨立評分。
上下文視窗差距的基準測試所隱藏的
Opus 4.8 擁有 1M-token 的上下文視窗；Kimi K2.7 則上限為 256K。基準測試分數很少會呈現這一點，但它決定了實際工作成效。256K 視窗足以舒適地容納一個中型 repo 和一段較長的 agent trace，對大多數 coding sessions 也都足夠。當你把整個大型 monorepo、長篇文件集，或是數小時的 agent transcripts 一次塞進單一 prompt 時，就會碰到上限。在那種情況下，Opus 大 4 倍的視窗才是實際上的差異，而不是圖表上的一個數字。
定價：5–6 倍差距與快取槓桿
以原生 API 列價計算，Kimi K2.7 Code 的輸入每百萬 tokens 為 $0.95，輸出每百萬 tokens 為 $4.00；Claude Opus 4.8 則為 $5 和 $25。這代表輸出價格相差 5–6 倍，而這正是團隊會評估 Kimi 的主要原因。
大多數定價表忽略的關鍵槓桿是快取。Kimi 在快取命中時每百萬 tokens 收費 $0.19，這是對你已經傳送過的輸入 80% 的折扣。在一個每一步都會重新讀取同一個 codebase 的 agentic loop 中，快取輸入會主導帳單，因此實際成本會遠低於標示價格差。Baseten 的 Philip Kiely 報告，在一個 sample workload 上，從 Opus 4.8 切換到 Kimi 2.7 Code 後，大約節省了 82%；這類高度依賴快取與輸入的工作負載，正是 Kimi 的定價優勢會累積放大的情境。你的數字會隨輸入對輸出比例而變動，但方向是一致的：相較於你產出的內容，越常重讀上下文，Kimi 在成本上就越有優勢。
Opus 會在輸出端把它的價格賺回來。它在我的 Task 1 上產生的 token 只有 Kimi 的四分之一，所以在像撰寫大型檔案或冗長重構這類偏重生成的工作中，按 token 計算的差距在實際花費上會縮小，而 Opus 的速度也能減少你支付工程師等待的實際時間。
開放權重的承諾 vs 577GB 的現實
Kimi K2.7 以經過修改的 MIT 授權條款作為開放權重發布，因此你可以自行架設並進行微調。Opus 4.8 則僅提供 API；你的程式碼和推理軌跡都會送到 Anthropic。紙面上來看，這對 Kimi 而言在隱私與供應商鎖定方面具有決定性優勢。實際上，先看看硬體成本再說。
Kimi K2.7 是一個擁有 1 兆參數的 Mixture-of-Experts 模型（每個 token 啟用 32B，384 個 experts）。獨立評測者估算，將權重、KV cache 與執行時額外開銷計入後，完整的 INT4 部署大約需要 577GB 的 VRAM，這使得最低可行配置落在約 8× H100 80GB 或 DGX Spark 級別的機器。單張 RTX 4090（24GB）無法在可用設定下執行完整模型。除了少數資金充裕的團隊之外，「open weights」意味著可以自由轉向託管供應商，或在租用的 GPU 上進行 fine-tune，而不是一個你能在內部自行部署的模型。如果你選擇 Kimi 的原因是希望在地端控制資料，請在承諾之前先估算叢集成本；對大多數團隊而言，自行託管仍然只是理論上的可能。
你應該選擇哪一個
將模型與工作負載相匹配，而不是選出一個贏家：
選擇 Kimi K2.7 Code，適用於成本敏感、高用量或 agentic coding 的情境，當你需要反覆重新閱讀 codebase、對延遲不那麼在意，且 256K context 已足夠時。快取折扣會讓你越用越划算。
選擇 Claude Opus 4.8，當你需要低延遲、適用於大型 repos 或長時間 session 的 1M-token context、較精簡的輸出，或是一個可在高風險變更上信賴的最終審查模型時；在這種情況下，它在獨立推理分數上的領先最為重要。
混合策略：便宜模型起草，前沿模型收尾
同時使用兩者的團隊中，最常見的模式不是二選一，而是路由分流。讓 Kimi K2.7 負責大部分的生成與迭代，以較低成本完成，然後把結果交給 Opus 4.8 做最終審核，或處理需要前沿級判斷的部分。Kimi 原生支援 OpenAI 格式，而 Opus 使用 Anthropic 自家的 API，因此在兩者之間進行路由的實際做法，是用一個閘道在單一 OpenAI 相容端點後方同時對接兩者；例如在像 AIReiter 這樣的平台上，兩者都位於同一個金鑰之下，將 Kimi 切換到 Opus 只需更改 model-string，而不必重新整合。上面提到的 82% 節省，正是來自這種路由方式，而不是完全捨棄 Opus。
常見問題
Kimi K2.7 在程式設計方面比 Claude Opus 4.8 更好嗎？
在有明確範圍且規格清楚的任務上，兩者表現相當；在我的測試中，兩者都回傳了完全正確的程式碼。Kimi 的優勢在於代理式工具使用（MCPMark 81.1 對 76.4，為 Moonshot 公布）；Opus 則在通用推理、速度與長上下文工作方面領先。
Kimi K2.7 比 Opus 4.8 便宜多少？
標價約便宜 5–6 倍（每百萬 $0.95/$4，相較於 $5/$25）。在重複性工作負載中，若有快取命中（每百萬輸入 $0.19），實際節省可達 80% 或更多。
Kimi K2.7 與 Opus 4.8 的上下文窗口是什麼？
Kimi K2.7 可處理 256K token；Opus 4.8 可處理 1M，為其四倍大。
我可以在本機執行 Kimi K2.7 嗎？
僅適用於嚴肅級硬體。據報導，完整的 INT4 部署大約需要 577GB 的 VRAM（約 8× H100 或一台 DGX Spark）。單一消費級 GPU（如 RTX 4090）無法執行完整模型。
Kimi K2.7 是開源的嗎？
它以修改版 MIT 授權釋出開放權重，因此你可以自行部署並進行微調。Opus 4.8 是封閉且僅限 API 使用。
結論
如果你的瓶頸是預算，預設選用 Kimi K2.7 Code，然後讓快取處理其餘的部分。如果瓶頸是延遲、上下文長度，或是某個你承擔不起出錯風險的變更，那就為 Opus 4.8 付費。把 open-weights 授權當作額外紅利，只有在你擁有 GPUs 時才去兌現。若你不確定，就把兩者都接上，並依任務分流，而不是把整個工作流程押在一個之後還得拆回來的選擇上。