Kimi K3 API 定價（2026）：費用說明與 K2.7 程式碼比較

TL;DR

Kimi K3 的價格為：每 1M 快取命中輸入 tokens $0.30、每 1M 快取未命中輸入 tokens $3.00、每 1M 輸出 tokens $15.00，並提供 1,048,576-token 的 上下文視窗。

與 K2.7 Code 相比，K3 的每 token 成本顯著更高，但提供 4× 的上下文視窗，且原生視覺與更強的長期代理型工作負載支援。

結論：在 256K 上下文內的常規編碼任務，K2.7 Code 仍是更經濟的選擇。當你需要更大上下文、多模態能力，或作為 K2.7 無法可靠完成任務的升級路徑時，使用 K3。

Kimi K3 API 價格總覽

參見 Moonshot 的 Kimi K3 快速開始，以獲取最新的 API 參數與整合細節。

Kimi K3 相較 K2.7 Code 的新增項目

最顯著的升級是上下文長度。

K2.7 Code 支援 262,144 tokens，而 K3 將上限提升至 1,048,576 tokens。這使 K3 在大型程式庫、長代理歷史、廣泛文件、以及原本需要壓縮上下文的工作流程上更實用。

K3 也支援：

• 原生視覺理解
• 嚴格的結構化輸出
• tool_choice
• 動態工具載入
• 自動上下文快取
• 長時間的編碼與知識工作流程

Moonshot 的 Kimi K3 技術部落格報告了 Terminal-Bench 2.1 的 88.3、Program Bench 的 77.8，以及 FrontierSWE 的 81.2。

這些是供應商提供的測試數據，應作為評估 K3 的理由——而非保證它在每個生產工作負載上都能超越 K2.7 Code。

關於上一代的背景，請參見 CometAPI 的 Kimi K2 API 指南。

Kimi K3 與 Kimi K2.7 Code 的價格比較

K2.7 的費率來自 Moonshot 的 官方 Kimi K2.7 Code 定價文件。

相較標準版 K2.7 Code，K3 是：

• 快取命中輸入價格的 1.58×
• 快取未命中輸入價格的 3.16×
• 輸出價格的 3.75×

相對於 K2.7 Code HighSpeed，K3 的加價幅度較小，但兩者定位不同：HighSpeed 重視更快的編碼輸出，而 K3 旨在滿足更高要求的長上下文與代理型工作負載。

Moonshot 當前的 Batch API 定價文件未列出 K3，因此不要假設其他 Kimi 模型可用的 Batch 折扣也適用於此。

Kimi K3 上下文快取：90% 輸入折扣如何運作

K3 支援自動上下文快取。

開發者不需要手動建立快取 ID 或 TTL。讓大型前綴在重複請求中保持穩定，可讓後續請求有機會以快取命中費率計費。

價格差異為：

• 快取未命中：$3.00 / 1M 輸入 tokens
• 快取命中：$0.30 / 1M 輸入 tokens

因此，快取命中的輸入 tokens 比快取未命中便宜 90%。

然而，輸出仍以每百萬 tokens $15 計費，所以整體請求成本並不會下降 90%。

例如，假設：

• 600,000 輸入 tokens
• 20,000 輸出 tokens

在此簡化案例中，總成本約下降 77%。

實際節省取決於取得快取命中費率的輸入 tokens 比例。

範例：在 K3 與 K2.7 上一個編碼任務的成本

假設某編碼任務使用：

• 200,000 輸入 tokens
• 20,000 輸出 tokens

在此工作負載上，冷啟請求時，K3 約為標準版 K2.7 Code 的 3.33× 成本。

在 K3 內部，從全部輸入快取未命中到完全快取，估算請求成本可從 $0.90 降至 $0.36，在此例中降低 60%。

但每次請求的成本只是整體的一部分。

成功任務的成本 = 總工作流程支出 ÷ 通過驗收檢查的任務數

生產比較還應包含重試、回退呼叫、工具執行與人工審查時間。

一次成功的 K3 請求，可能比數次更便宜但失敗的嘗試更為經濟。

真實世界的邊緣情況：推理 token 成本

K3 始終使用推理，因此輸出 token 消耗可能成為帳單中的重要部分。

在 Simon Willison 的發佈日測試中，一個要求 K3 生成 SVG 的提示，在產出 3,417 個回應 tokens 前消耗了 13,241 個推理 tokens，總成本約為 $0.25。

這是單次提示的非正式測試，而非基準，但突出了重要的成本考量：可見的最終答案可能只代表計費輸出的部分。

由於 K3 目前僅支援最大推理強度，團隊應在自身工作負載上測量實際輸出 token 使用量。

更好的預設：先用 K2.7，需要時升級至 K3

對混合編碼工作負載而言，路由可能比直接將每個請求送到 K3 更為經濟。

簡單策略是：

Start with K2.7 Code
        ↓
Task exceeds 256K context?
        → Yes: use K3
        ↓ No
Run task and validation
        ↓
Validation failed?
        → Yes: escalate to K3
        ↓ No
Return result

使用前述範例：

• K2.7 Code 每次冷啟嘗試成本 $0.27
• K3 成本 $0.90
• K2.7 成功完成 70% 的任務
• 30% 會在 K3 上重試一次

平均成本成為：

$0.27 + (30% × $0.90) = $0.54 per task

在相同 token 假設下，將每個任務直接送到 K3 會是 $0.90 每任務。

在此簡化情境中，路由策略便宜 40%。

確切節省會有所不同，但原則有效：將例行工作路由到更便宜的模型，並在確實需要額外能力時再升級。

何時值得升級到 Kimi K3？

K3 最具吸引力的情境包括：

• 所需上下文超過 K2.7 Code 的 262,144-token 上限。
• 任務結合程式碼與視覺輸入。
• 長期代理需要跨大型程式庫與外部工具工作。
• K2.7 經常需要重試或回退呼叫。
• 任務價值足夠高，以至於完成品質比降低首次呼叫成本更重要。

對於在 256K 上下文內已具高成功率的重複、範圍明確的編碼任務，K2.7 Code 仍是強力選擇。

對延遲敏感的編碼應用，也應單獨測試 K2.7 Code HighSpeed。

從 K2.7 遷移到 K3：五項工程檢查

1. K3 的推理目前無法降低

K3 始終進行推理，且目前 API 僅支援：

reasoning_effort="max"

因為 max 是預設值，該參數也可省略。

1. 移除 K2 特定的 thinking 參數

不要在 K3 上使用 K2.x 的 thinking 參數。

請改用頂層的 reasoning_effort 欄位。

1. 省略固定的取樣參數

K3 目前對以下參數使用固定值：

temperature=1.0
top_p=0.95
n=1
presence_penalty=0
frequency_penalty=0

Moonshot 建議省略這些欄位，而不是覆寫它們。

1. 保留完整的助理訊息

對於多輪對話與工具呼叫迴圈，請在下一次請求中傳遞完整的助理訊息，而不是僅保留可見的 content。

1. 在進入生產前驗證視覺與搜尋

K3 目前的視覺 API 不直接支援公開的圖片 URL。請使用受支援的圖片格式，如 base64 資料或 Moonshot 的檔案引用機制。

Moonshot 也建議在功能更新期間不要依賴其目前的網路搜尋功能作為近期的生產使用。

Kimi K3 的 Python API 範例

K3 可透過與 OpenAI 相容的 API 介面呼叫：

from openai import OpenAI

client = OpenAI(
    base_url="YOUR_OPENAI_COMPATIBLE_BASE_URL",
    api_key="YOUR_API_KEY",
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "system",
            "content": "You are an expert software engineer.",
        },
        {
            "role": "user",
            "content": "Analyze this repository logic and identify potential issues.",
        },
    ],
    reasoning_effort="max",  # Optional while "max" is the default
)

assistant_message = response.choices[0].message
print(assistant_message)

避免覆寫 K3 的固定取樣參數。對於多輪與工具呼叫的工作流程，請保留完整的助理訊息。

在升級前如何評估 Kimi K3

請在真實工作負載上測試 K3，而非僅用基準提示。

實務的評估集可包含：

• 例行的程式庫編輯
• 接近 256K 上下文上限的任務
• 超過 256K 的任務
• 視覺工程任務
• 長期代理或知識工作任務

在適用的情況下比較 K3、K2.7 Code 與 K2.7 Code HighSpeed。

追蹤：

• 任務成功率
• 快取與非快取的輸入 tokens
• 輸出與推理 tokens
• 重試與回退呼叫
• p50 與 p95 延遲
• 工具呼叫錯誤
• 人工審查時間
• 每個成功任務的成本

接著比較三種策略：

1. 全用 K2.7 Code
2. 全用 K3
3. K2.7 Code，必要時升級至 K3

最佳路徑是以最低的每成功任務成本，滿足你的品質與延遲要求。

CometAPI 上的 Kimi K3 定價

上述計算使用 Moonshot AI 的官方 API 定價，以保持 K3 與 K2.7 的比較一致。

在本文發布時，CometAPI 上的 Kimi K3定價比 Moonshot AI 的標準 API 費率低 20%：

由於 API 定價可能變動，請在用於生產預算前查看即時的模型頁面。

CometAPI 的與 OpenAI 相容 API，讓你能用相同提示與評估工作流程輕鬆同時測試 kimi-k3 與其他模型路由。

準備好測試 Kimi K3 了嗎？查看 CometAPI 上的 Kimi K3，並在進入生產前比較定價。

整合與評估範例，請參見 GitHub 上的 CometAPI Cookbook。

常見問題

Kimi K3 API 的費用是多少？

Moonshot AI 列出 Kimi K3 為：每 1 百萬快取命中輸入 tokens $0.30、每 1 百萬快取未命中輸入 tokens $3.00、每 1 百萬輸出 tokens $15.00。

API 模型 ID 為 kimi-k3。

Kimi K3 比 Kimi K2.7 Code 更便宜嗎？

不。根據 Moonshot 的官方費率，K3 在快取未命中輸入上約為 3.16×、在輸出上約為 3.75× 的價格。

若它能提高任務成功率或減少重試，仍可能降低整體工作流程成本。

Kimi K3 是否具備 1M-token 的上下文視窗？

是的。Kimi K3 支援 1,048,576-token 的 上下文視窗，相較 Kimi K2.7 Code 的 262,144 tokens。

Kimi K3 是否支援自動上下文快取？

是的。上下文快取是自動的。快取命中輸入 tokens 為每百萬 $0.30，相較快取未命中輸入的每百萬 $3.00。

我可以關閉 Kimi K3 的推理以降低成本嗎？

目前不行。K3 始終使用推理，且 reasoning_effort="max" 是唯一支援的推理強度。

結語

Kimi K3 在上下文長度與能力上相較 K2.7 Code 有大幅提升，但其每 token 價格也更高。

對於在 256K 上下文內的常規編碼，K2.7 Code 通常更經濟。對長上下文、多模態或困難的代理型任務，若能提升成功完成率，K3 的加價是可以被合理化的。

對許多生產系統而言，最有效率的策略通常不是完全替換 K2.7，而是將 K2.7 作為預設、K3 作為升級路徑。

最終重要的指標不是每次 API 呼叫的成本，而是 每個成功任務的成本。