Token Efficiency 是什麼？從 DeepSeek V4 看大模型規劃、小模型執行

Fri, 15 May 2026 08:59:33 +0800

AI 編程接下來真正重要的指標，可能不是誰的模型最強，而是誰能用更少 token、更低成本、更穩定的流程，完成更多可驗收的工作。

這就是 Token Efficiency 的價值。

很多人理解 Token Efficiency，只想到模型便宜、上下文變長、快取命中更低價。但這些只是底層條件。真正能把它變成生產力的，是模型分工、任務編排、上下文預算和評估體系。

換句話說，Token Efficiency 不是省錢技巧，而是一套把 token 轉換成產出的工程方法。

DeepSeek V4 的定位：把大小模型分工產品化

DeepSeek V4 不是單純發布一個更強模型，而是把 Token Efficiency 需要的兩層能力拆成 V4 Pro 和 V4 Flash。V4 Pro 更適合規劃、推理、架構判斷和關鍵審查；V4 Flash 更適合高頻執行、批量改寫、程式碼補全、資料整理和 agent 循環裡的普通節點。

這正好對應 AI 編程裡的兩個角色：

V4 Pro：作為 planner / consultant，用在需求拆解、技術方案、複雜 bug 根因、架構審查和最終驗收。
V4 Flash：作為 executor，用在檔案掃描、簡單實作、測試補齊、文件整理、候選方案生成和重複性任務。

DeepSeek 官方 API 文件顯示，V4 Flash 和 V4 Pro 都支援 1M 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；價格頁也把快取命中輸入單獨計價，並說明全模型 input cache hit 價格已降到發布價的十分之一。

1M 上下文解決複雜 agent 任務容易被壓縮的問題；低快取命中價格降低長 system prompt、專案文件、程式碼片段和歷史狀態反覆進入上下文的成本；Flash / Pro 雙模型形態解決「每一步都用旗艦模型太貴、每一步都用小模型又不穩」的分工問題。

所以 DeepSeek V4 的優勢不只是便宜或上下文長，而是執行層便宜、判斷層可用、長鏈路友好。它給「顧問模型 + 執行模型 + harness 編排」提供了更現實的成本結構。

不要讓最強模型幹所有活

過去使用 AI，常見做法是找最聰明的模型，讓它從需求分析、程式碼實作、測試、總結一路幹到底。

這很簡單，但不一定高效。很多任務不需要最高等級推理能力。真正昂貴的模型，更應該像顧問、架構師或規劃員，只在關鍵決策點介入。

更合理的結構是：

大模型負責拆問題、定方向、做關鍵判斷。
小模型負責執行、批量處理、重複修改。
工具和 harness 負責流程、狀態、上下文和驗證。
人負責定義產品、驗收結果和決定取捨。

這樣前沿推理能力不會被浪費在機械執行上。

上下文不是越大越好

長上下文對 coding agent 很重要，因為程式碼、文件、歷史對話、測試輸出和錯誤日誌都會吃掉上下文。上下文接近上限後，模型容易壓縮、遺忘或誤判。

但長上下文不等於可以無限塞資料。

Token Efficiency 的關鍵，是讓每個任務都能在清楚、可控的上下文窗口內完成：

只帶必要檔案。
背景文件只帶決策相關部分。
歷史資訊只保留當前階段需要的狀態。
每個節點有明確輸入和輸出。
完成後把結果壓縮成結構化摘要，交給下一個節點。

上下文越便宜，越要警惕浪費。噪音不會讓模型更聰明。

Harness 比單個模型更重要

如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在長鏈路任務裡跑偏，需要更強流程控制。

真正讓小模型發揮價值的是 harness。它像一套調度系統，決定任務怎麼拆、節點怎麼跑、模型怎麼選、結果怎麼驗收、失敗怎麼重試、上下文怎麼傳遞。

沒有這層軟體，小模型只是便宜；有了這層軟體，小模型才可能變成槓桿。

用 DAG 拆任務

一個有效思路，是把複雜任務拆成有向無環圖，也就是 DAG。

例如功能開發可以拆成需求澄清、方案設計、任務拆分、編碼實作、測試補齊、Code Review、修復問題、提交 PR。

每個節點都可以是獨立 agent，有自己的角色、prompt、工具權限和輸出格式。節點之間不靠長篇聊天傳遞資訊，而是靠預先定義好的結構化結果。

這讓單個節點更短，也讓流程更可測。

任務可以跑多個副本

當 token 足夠便宜，同一任務不一定只跑一次。可以讓同一任務用不同模型、不同 prompt、不同編排跑多個副本，再選最好結果或合併有效部分。

適合多副本的任務包括方案設計、文案生成、測試用例補全、bug 根因假設、重構方案比較和 Code Review。不適合盲目多副本的，是會修改共享狀態、產生外部副作用或驗收標準不清楚的任務。

多跑幾次不是碰運氣，而是獲得可比較樣本，反過來優化編排、模型選擇和節點技能。

必須建立評估體系

Token Efficiency 不能只看價格。便宜但失敗率高，最後會吞掉人的時間。

可以先記錄任務完成率、人工介入次數、工具調用失敗率、測試通過率、review 問題數、單任務 token 成本、耗時、返工次數和不同模型組合差異。

有了這些資料，才知道哪些任務適合小模型，哪些必須上大模型，哪些應該交給人判斷。

業務流程要原子化

普通使用者不一定要自己寫完整 harness，但可以先把業務流程拆成原子節點。

內容生產可以拆成選題、資料收集、提綱、初稿、事實核查、風格改寫、SEO 標題、多語言翻譯、發布檢查。

軟體開發可以拆成需求確認、技術方案、資料結構、介面變更、單元測試、實作、遷移腳本、文件、Review。

每個節點都要盡量做到輸入明確、輸出明確、驗收明確、上下文可控。這樣等 harness 工具成熟時，流程可以直接接上。

硬體不是第一優先級

很多人聊 Token Efficiency，很快就聊到本地部署和顯卡。但對大多數人來說，第一選擇仍然應該是 API。

在沒有跑通經濟模型前，本地硬體只是成本前置。更穩的順序是：先用 API 跑通流程，建立評估和成本統計，找到穩定高頻節點，再考慮哪些值得本地化，最後計算硬體、電費、維護和折舊。

小結

Token Efficiency 的本質，不是用便宜模型替代貴模型，而是重新設計 AI 工作流。

大模型負責關鍵判斷，小模型負責批量執行，harness 負責調度和驗證，人負責定義目標和驗收結果。只有這四層配合起來，token 才能穩定變成生產力。

未來的差距，很可能不在誰調用了最強模型，而在誰能用同樣的 token 撬動更多真實產出。

小模型 on KnightLi的博客