在大模型 API 的計費方式裡，最容易讓人困惑的一點，就是為什麼幾乎所有平台最後都會落到 token 這個單位上：大模型為什麼按 token 收費，而且不同 token 還會有不同價格。
很多人剛接觸模型 API 時，最困惑的不是模型能力，而是帳單。明明只問了幾個問題，為什麼費用會漲得這麼快？為什麼輸入便宜、輸出更貴？為什麼上下文一長，成本就開始明顯失控？
如果把這件事講簡單一點，可以先記住一句話：模型收費，買的不是「一次回答」，而是整段推理過程中消耗的計算與帶寬資源。
1. 什麼是 token
在大模型計費裡，token 不是「字數」也不是「單詞數」，而是模型處理文字時使用的切分單位。
它可能是：
- 一個漢字
- 一個英文單詞的一部分
- 一個標點符號
- 一小段常見詞組
所以 API 平台通常不會按「每句話」或「每次請求」收費，而是按模型實際讀入和生成的 token 數量收費。
這比按請求次數計費更合理，因為同樣是一次請求，可能只輸入 20 個字，也可能塞進 20 萬 token 的上下文，兩者消耗完全不是一個量級。
2. 為什麼輸入和輸出要分開定價
現在大多數模型 API，都會把價格拆成兩部分：
- 輸入 token 價格
- 輸出 token 價格
而且常見情況是：輸出 token 比輸入 token 更貴。
原因並不難理解。
模型處理輸入時，本質上是在「讀」和「編碼」已有內容；但生成輸出時，它需要一步一步預測下一個 token，再繼續預測下一個 token。這個過程不只是讀取，而是持續進行推理和採樣，所以通常更耗算力。
你可以把它粗略理解成：
- 輸入：像把材料遞給模型
- 輸出：像讓模型現場寫答案
「現場寫」的計算成本，通常比「把材料讀一遍」更高，所以輸出價格更貴是很常見的設計。
3. 為什麼上下文越長，費用越容易失控
很多人以為自己只是在「多貼一點背景資料」，但從模型帳單的角度看，這件事的影響往往比想像中大。
原因在於：模型每次調用時，通常都要重新處理目前請求裡帶進去的整段上下文。
也就是說，如果你目前請求裡包含：
- 系統提示詞
- 歷史對話
- 工具返回結果
- 長文件片段
- 程式碼檔案內容
這些內容都會一起進入輸入 token 計費。
所以真正讓帳單變大的，往往不是最後那一句提問，而是它前面拖著的一大串上下文。
當對話輪數增加、工具調用變多、歷史訊息不斷回灌時，token 成本就會一輪一輪被放大。
4. 工具調用為什麼特別容易漲 token
在 Agent、程式碼助手、工作流自動化這類場景裡，token 消耗通常比普通聊天高得多。
問題不只是「模型回答了一段話」，而是整個流程裡會不斷出現這些內容：
- 讀檔案
- 看日誌
- 調 API
- 返回 JSON
- 把工具結果再回填給模型
每一次工具調用的結果，只要被重新塞回下一輪上下文，就會繼續變成新的輸入 token。
這就是為什麼很多開發者最後會發現：
不是模型本身單價特別離譜，而是工作流把 token 帳單一層層疊上去了。
例如一個編碼 Agent 連續做下面這些事：
- 讀取專案結構
- 打開幾個原始碼檔案
- 跑一次測試
- 把報錯日誌餵回模型
- 再讀更多相關檔案
每一步都可能讓後續請求背著更長的上下文繼續跑。這樣即使單價不變，總帳單也會很快增長。
5. 為什麼同樣是模型，價格會差很多
不同模型的 token 價格差異，背後通常不只是「廠商想賣貴一點」，而是和幾個因素直接相關：
- 模型規模
- 推理效率
- 上下文長度
- 部署成本
- 目標市場
模型越大、活躍參數越多、推理鏈路越複雜，單次生成一個 token 的成本通常就越高。
如果模型還支援超長上下文、複雜推理、工具調用優化，那它的基礎設施壓力也會進一步增加。
所以定價本質上是在覆蓋幾類成本：
- GPU / 加速卡資源
- 顯存占用
- 推理延遲
- 網路與服務穩定性
- 峰值並發能力
便宜模型不一定差，貴模型也不一定適合所有場景。很多時候價格差，反映的是「這類能力大概值多少基礎設施成本」。
6. 為什麼快取輸入會更便宜
不少模型平台現在會提供：
- cached input
- prompt caching
- prefix caching
這類能力的共同思路是：如果一大段輸入已經算過，就不要每次都從頭按原價重算。
比如一段固定 system prompt、固定工具說明、固定長文件前綴，如果每輪都完全重複發送，平台就有機會把其中一部分計算快取下來。這樣同樣是輸入 token，命中快取的部分就可以按更低價格計費。
這也解釋了為什麼很多 API 價格頁會出現三檔甚至更多價格：
- 普通輸入
- 快取輸入
- 輸出
它們反映的不是文字內容不同，而是底層計算是否可以重用。
7. 「便宜 token」為什麼不等於「總成本更低」
很多人看到某個模型「每百萬 token 超便宜」，第一反應是總成本一定更低。實際上不一定。
因為總帳單大致等於：
token 單價 × 實際消耗量
而實際消耗量又會被很多因素放大：
- 提示詞寫得太長
- 歷史訊息不清理
- 工具結果回填過多
- 輸出太囉唆
- 一個任務反覆重試
所以真正決定帳單的，通常不是單價一個變數，而是：
- 模型單價
- 每輪輸入長度
- 每輪輸出長度
- 調用次數
- 工作流設計
這也是為什麼「低單價模型」在某些 Agent 任務裡，最後總費用仍然可能不低。因為它可能需要更多輪互動、更多補充上下文、更多失敗重試。
8. 開發者該怎麼估算 token 成本
如果你想在專案裡更穩地控制預算，可以先用一個很樸素的估算方式：
- 統計平均每次請求的輸入 token
- 統計平均每次請求的輸出 token
- 估算一個任務會調用多少輪
- 再乘上對應模型單價
舉個思路上的例子：
- 每輪輸入
8k tokens - 每輪輸出
1k tokens - 一個任務跑
10輪
那它真正消耗的就不是「一次問答」，而是：
- 輸入約
80k tokens - 輸出約
10k tokens
如果中途還有日誌、工具結果、檔案內容不斷追加，總量還會繼續上升。
所以做預算時，最好不要只看單輪，而要看一個完整任務閉環到底會吃掉多少 token。
9. 怎麼實際控制帳單
如果你已經在用 API 或 Agent，下面這些做法通常最有效：
- 縮短 system prompt，避免重複廢話
- 定期裁剪歷史訊息
- 工具返回結果只保留必要欄位
- 長文件先檢索，再餵局部片段
- 控制輸出長度，避免模型無上限展開
- 高價值任務用貴模型，低價值任務用便宜模型
很多時候，省錢最有效的方式不是一味換更便宜的模型，而是先把工作流裡沒有意義的 token 消耗砍掉。
10. 這件事真正該怎麼理解
大模型 token 定價，說到底是在替「模型讀了多少、想了多少、寫了多少」計費。
它不是傳統軟體那種按帳號、按次數、按包月就能完全描述的資源模型，因為模型調用本身就是一個動態計算過程。你塞進去的上下文、拉起的工具、要求的輸出長度，都會直接影響成本。
所以理解 token 定價，最重要的不是背價格表，而是先建立一個直覺：
- 長上下文會漲輸入成本
- 長輸出會漲生成成本
- 工具鏈會放大總 token
- 快取和工作流設計會明顯影響帳單
只要把這幾個點想清楚，大多數模型 API 的價格結構其實都不難理解。