2026 Qwen3.8-Max、Kimi K3、DeepSeek V4 賬單對齊

截至 2026 年 8 月 8 日，官方資料核實自模型文件、定價頁與 API 使用量說明。

DeepSeek 官方定價頁目前把 快取命中輸入、快取未命中輸入及輸出 分開計費，並以每百萬 Token 作為單位；這個資料點已足以說明：套餐金額、Credits 消耗與每 Token 標價不能直接橫向排序。本週建議先不要替 Qwen3.8-Max、Kimi K3、DeepSeek V4 選出「最便宜」的一款，而是將一週 API usage 與成功任務記錄統一換算成「每個成功完成任務的有效成本」。(DeepSeek 官方定價頁)

正在整理三款模型試用賬單的獨立開發者，可以用本文建立可重複使用的成本表。負責 API 預算與採購的技術負責人，可藉此拆開表面單價與實際交付成本。運行程式編程或自動化 Agent 的團隊，則需要把重試、長輸出與工具呼叫一併納入。

先統一成功任務這個分母

三款服務的計費口徑不同，真正公平的比較單位應是：

有效任務成本 = 一次完整任務的總費用 ÷ 通過既定驗收標準的任務數

「一次完整任務」不能只代表一次 HTTP 請求，而應包含：

• 輸入 Token；
• 快取命中輸入與未命中輸入；
• 模型輸出及思考內容所產生的計費；
• 工具呼叫或外部服務費用；
• 超時、錯誤、限流後的重試；
• Agent 產生的子任務請求；
• 最後是否達到可驗收的完成條件。

我們建議在試用表中固定使用 task_id、model_id、billing_mode、input_tokens、cache_hit_tokens、cache_miss_tokens、output_tokens、tool_cost、retry_count、success 及 total_cost 等欄位。價格頁只提供計算因子，真正決定成本的，是脫敏 API usage 與任務結果。

三種計費口徑的對照表

官方文件目前確認，Qwen3.8-Max 以 qwen3.8-max-preview 形式提供，並有只適用於 Token Plan 的使用限制；Credits 消耗會受到模型、Token 使用量、思考模式及工具呼叫影響。官方亦說明，預覽期間的折扣和使用政策可能調整，因此預覽優惠、正式版價格及不同模型 ID 必須分欄保存。(Qwen 官方 Token Plan 說明)

另一邊，DeepSeek V4 官方文件列出 deepseek-v4-flash 與 deepseek-v4-pro，並支援快取命中、快取未命中及輸出三類 Token 計費；同一頁亦提醒價格可能調整，應以最新定價頁為準。Kimi K3 的模型狀態及能力應以官方發佈記錄和 API 控制台為準；官方公開資料目前將 K3 描述為支援 1M-token 上下文 的旗艦模型，但這個能力描述不能代替當下帳戶的實際 API 價格。(Kimi 官方產品頁)

若團隊正在追蹤 Qwen3.8-Max 的預覽成本，也可以先參考我們整理的Qwen3.8-Max 預覽限制與成本注意事項，但正式採購前仍要重新核對官方控制台中的模型 ID 與折扣狀態。

Qwen3.8-Max 的 Credits 記帳

Qwen3.8-Max 最容易造成誤判的地方，是 Credits 並不是一個固定的 Token 貨幣單位。官方文件表示，每次請求的 Credits 會動態受到模型類型、Token 使用量、思考模式及工具呼叫影響；因此同樣一段輸入，在不同思考設定或工具流程下，消耗可能不同。(Qwen 官方 Token Plan 說明)

建議把每次記錄拆成以下三層：

1. 套餐層：套餐名稱、開始與結束日期、可用額度、是否屬於預覽優惠。
2. 請求層：模型 ID、請求時間、輸入與輸出 Token、思考設定、工具呼叫及 Credits 消耗。
3. 任務層：任務是否成功、失敗原因、重試次數及最後交付結果。

公式只需要定義變數，不要在缺少官方 Credits 對 Token 比例時硬填數值：

Qwen 單位任務成本 = 該任務所有請求的 Credits 總和 ÷ 成功任務數

如果套餐設有不同時間窗口，也要同時保留套餐週期與實際使用日期。官方資料指出，部分 Token Plan 額度按 5 小時及 7 日窗口管理，未使用額度不一定可以跨窗口累積；這代表「一個月買了多少」與「一週實際完成多少任務」是兩個不同問題。(Qwen 官方 Token Plan 說明)

Kimi K3 與 DeepSeek V4 的 Token 記錄

對 Kimi K3 和 DeepSeek V4，最穩妥的做法不是先找一個看似漂亮的每百萬 Token 價格，而是先建立相同欄位，再把官方價格填入欄位。Kimi K3 的價格與快取規則若在控制台、API 文件或發佈記錄中分開呈現，應以同一個帳戶實際回傳的 usage 為準；第三方渠道的套餐價不能冒充官方 API 價格。

DeepSeek 官方使用量文件明確指出，實際 Token 數量應以 API 回傳的 usage 為準，字元與 Token 之間沒有可跨模型固定套用的換算比例。(DeepSeek Token 使用量文件) 因此同一份中文程式碼、英文錯誤訊息或 JSON 輸出，不應只按字數估算。

DeepSeek 的快取還有一個重要邊界：官方文件說明，只有從第 0 個 Token 開始完全一致的前綴，才會被視為可重用內容；中間局部相同，不一定觸發命中。(DeepSeek 快取說明) 這會直接影響長文檔與程式庫分析的成本排序。

長文檔與程式庫的快取分組

長上下文任務至少應分成三組測試：

• 冷啟動：第一次送入完整系統提示、規格文件或程式庫索引；
• 連續會話：保留相同前綴，只改變問題或少量上下文；
• 上下文變更：加入新檔案、修改系統提示或改變訊息前綴。

每組都要記錄快取命中率、輸入 Token、輸出 Token、回應時間及任務成功率。若只做連續會話，可能高估快取收益；若只做冷啟動，則可能低估重複知識庫和固定系統提示的實際價值。

對於固定規格、重複程式庫檔案及多輪除錯，快取通常值得納入設計；對於每次都更換大量上下文的研究查詢，則應主動壓縮輸入，並把壓縮所需的額外請求也納入成本。DeepSeek 官方亦列出多輪對話、重複文件分析及程式碼除錯等快取使用情境，但這些是適用場景，不是所有請求都會自動得到相同命中率。(DeepSeek 快取說明)

程式編程 Agent 的重試成本

程式編程 Agent 的價格表估算經常失真，原因是 Agent 的交付單位不是「最後一個回答」，而是「完成一項可驗收工作」。例如修正一個測試失敗的程式問題，可能包含讀取檔案、分析錯誤、修改程式、執行測試、處理新錯誤及再次提交。

因此，三款模型都應使用端到端任務成本：

Agent 任務成本 = 模型 Token 費用 + 工具費用 + 失敗請求費用 + 重試費用

工具費用需要另外分欄，因為它可能來自搜尋、程式執行環境、檔案處理或外部 API，而不一定由模型供應商的 Token 帳單收取。若某次工具執行失敗，模型重新規劃所消耗的 Token 仍應保留，不能因最後成功而刪除。

DeepSeek 官方文件另列帳戶層級的並行限制，並指出超過限制時可能收到 HTTP 429；這類失敗請求是否產生模型費用，要以實際回應與帳單記錄核對，不能只看程式端是否捕捉到錯誤。(DeepSeek 速率限制文件)

試用轉採購的決策條件

完成一週或一個完整 PoC 後，我們建議按以下條件決策，而不是直接做三款模型總排名：

• 若請求量低、套餐額度長期用不完，先選套餐利用率較高、取消或轉換成本較低的方案；否則回到按 Token 的 API 試跑。
• 若請求量高且任務模式穩定，比較每個成功任務的總消耗；不要再以輸入單價單獨決定。
• 若長文檔或固定程式庫佔主要工作量，選擇快取欄位可被清楚觀測、且連續會話命中率穩定的方案；否則主動壓縮上下文。
• 若 Agent 重試和工具呼叫佔大部分成本，優先比較端到端成功率與重試成本；單次模型呼叫便宜，不代表整條流程較省。
• 若 API 成本波動、資料控制或服務連續性已超出團隊容忍範圍，才進入開放權重模型與自託管算力評估，而不是為了追求理論最低 Token 價格立即搬遷。

如需把試用結果延伸到實際雲端環境，先完成雲端 Mac 方案的價格與交付條件檢查，再評估部署環境是否能穩定保存 API 金鑰、日誌與測試腳本。

常見賬單誤區

Qwen3.8-Max Credits 不是固定匯率

只要官方沒有明確公布 Credits 與 Token 的固定比例，就不應自行建立「一 Credits 等於多少 Token」的永久換算表。預覽折扣、夜間優惠、工具呼叫和思考設定，都可能令同一模型在不同期間出現不同消耗。

快取命中不代表輸入完全免費

快取命中、未命中和輸出通常是分開欄位。即使快取輸入單價較低，輸出過長、重試過多或任務成功率偏低，仍可能令總成本上升。真正應比較的是任務級總消耗。

失敗任務不能從分母消失

如果一個 Agent 執行三次才完成，三次請求都屬於這項任務的成本；如果最後仍未通過驗收，則它應記為失敗任務，而不是把最後一次回覆當成成功樣本。這是避免成本報表過度樂觀的基本控制。

截至 2026 年 8 月 8 日，我們核對到的官方資料仍顯示，模型狀態、模型 ID、快取規則、套餐優惠與 API 價格需要分開保存；任何一家調價、預覽轉正式、模型下線或新增計費項目後，都應在 24 小時內重新跑一次欄位核對。Qwen 文件中的預覽模型、Token Plan 限制與促銷內容尤其不宜直接寫入長期採購預算。

如果目前方案是把三款 API 的單價貼在試算表上直接排序，真正的缺點通常不是價格太高，而是計費單位互不相容、快取和重試沒有獨立記錄，還可能因本機環境不穩而反覆重跑。對需要臨時算力、固定測試環境或 Agent 驗收的團隊，租用 JexMac 的雲端 Mac，往往比在多台本機之間維持不同版本的程式庫、金鑰與排程更容易控制；但若團隊需要長期穩定重負載、實體介面或完全掌握硬體，仍應如實比較自購 Mac 與自託管方案。

本週先從各平台匯出一週 API usage，為每項任務補上成功判定、重試次數及快取狀態，再做一次賬單歸一化。若結果顯示環境連續性、重試成本或自託管驗證已成為主要變數，可進一步參考雲端 Mac 部署與 Agent 環境驗收指南，再決定是否需要把模型帳單問題延伸到算力部署。

常見問題