第 14 章 — Token 經濟學與 API 定價

發佈於: 2026-05-06 最後更新於: 2026-07-08 版本: 1
第 14 章 — Token 經濟學與 API 定價

第 14 章 — Token 經濟學與 API 定價

LLM Primer VI:擴展 AI 系統》章節走讀的第十四篇。這一章把第 1 章的物理連到帳單上的項目 — 並解釋為什麼第一個月的帳單常常跟團隊當初預估的完全對不上。


這一章為什麼存在

前面的章節把推論的成本當成一項物理事實 — 在 HBM 上搬的位元組數、在一次矩陣乘法花掉的 FLOPs、一個請求消耗的 GPU 秒數。對擁有矽晶片的團隊而言,那個框架是正確的。對更廣大、跟 API 買推論的團隊來說,成本表面會被提供商計費的單位重新塑造:token。第 14 章的主題是為什麼 token 這樣定價、為什麼同一次呼叫的輸入端與輸出端價差這麼大、以及聊天機器人的對話歷史與推理模型看不見的思考如何靜靜地跑到帳單上。

一句話總結:Token 之所以被定價,是因為它幾乎線性地對應到提供商花掉的運算,但輸入 token 與輸出 token 是兩個不同的成本對象,把它們當成同一個看的團隊會被嚇到。

14.1 輸出比輸入貴 4 到 8 倍是因為 decoding 是受頻寬所困的階段

一個輸入 token 走的是 prefill 路徑 — 密集、受制於運算、在提示詞所有位置上平行 — 剛好就是 GPU 被設計來做的工作。在一顆 70B 模型上,一顆 H100 每秒能咀嚼幾萬個輸入 token,因為那個運算是寬矩陣乘法、算術強度高。一個輸出 token 走的是 decode 路徑 — 循序、受制於記憶體頻寬、每次前向傳遞一個 token、每一步都得從 HBM 讀完整個 KV 快取。同一顆 H100 每個請求每秒產出 50 到 100 個輸出 token。兩個吞吐量的比例,就是價目表所反映的比例。2025 年的最前沿模型每一百萬輸入 token 收兩到五美元、每一百萬輸出 token 收十到三十美元 — 4:1 到 8:1 的不對稱不是毛利選擇,而是底下運算不對稱性的直接轉嫁。快取過的輸入更便宜,因為提供商在之前的請求上已經付過 prefill 成本。批次 API 半價,是因為提供商能把工作排進閒置容量的視窗。Reasoning tokens 是輸出 token,因為它們在引擎裡就是輸出 token。

14.2 最佳化槓桿取決於輸入/輸出形狀

錯誤是用一個心裡的數字 — 「token 一個 X 塊」— 來建模成本,而不是把輸入與輸出分開拆解。一個以擷取為主的客服分流系統,一次送 8,500 個輸入 token、拿回 600 個 token 的回應,在最前沿定價下由輸入成本主宰(每天一萬個請求大約是 255 美元輸入對比 90 美元輸出)。同樣量的長篇草擬系統 — 2,200 個輸入 token 進、3,000 個輸出 token 出 — 則由輸出主宰(66 美元輸入對比 450 美元輸出)。這兩種情況的最佳化建議完全相反:第一種要縮短提示詞,第二種要縮短回應,並把流量路由到定價輪廓對主宰軸有利的模型。第二個值得跑的拆解是按租戶或工作量。多租戶系統幾乎都會呈現冪律偏斜,前 10% 的租戶佔了一半以上的花費,針對那些租戶做的降本工作,回本是把工作平均散給長尾的好幾倍。

14.3 上下文累積與看不見的 reasoning tokens 把帳單複利

最貴的 token 是團隊忘了自己在送的那個。API 是無狀態的;每一次請求都會把完整的對話歷史當輸入送出去。跨 N 輪對話的累積輸入成本大約以 N 的平方成長,減掉 prefix cache 的抵扣。一個用單輪基準線定價的團隊,六個月後會發現平均對話已經是八輪、每次對話的輸入成本大約以平方倍成長。第二個沉默的乘數是 reasoning tokens。像 o1/o3、Anthropic 的擴展思考、DeepSeek R1、Google 的推理變體,會在可見答案前產生大量內部思考 — 常常是一段 500 個 token 的可見回應背後有 4,000 到 8,000 個 token。那些 token 走同樣的輸出 decode 迴圈、也以輸出計費;呼叫端不去要,它們不會回來。緩解方式是正確地插樁 API 回應的 usage 物件 — prompt_tokenscached_prompt_tokenscompletion_tokensreasoning_tokens、以及任何提供商特定的分類 — 並把未知的分類標出來,而不是默默丟掉。每一項提供商新增的計費維度都得在團隊的用量 schema 裡出現,不然下一份帳單就是驚喜。

值得記住:一份只有「輸入 token」與「輸出 token」的用量 schema,會默默吸收提供商引入的每一種新計費類別。每一個被揭露的維度都分開記,把未知的標出來,並每季重新分解一次成本。

第 14 章鋪陳出來的東西

一旦團隊能用「輸入對比輸出」、「按租戶」、「按類別」的分解讀懂自己的帳單,下一個問題 — 就是財務會問的那個 — 就是團隊到底該不該按 token 付錢。第 15 章走替代方案:把推論搬回自家、租或買 GPU、改用 GPU 小時計費。損益兩平的算術很乾淨。不乾淨、且大多數團隊低估的,是自架這一側帳目上不出現在 GPU 帳單上的每一項:平台工程、資安修補、模型升級的編舞、以及節點掉出機群時值班回答電話的那份輪值。


下一篇 — 第 15 章:無伺服器 API 對比專屬基礎設施損益兩平公式、隱藏項目,以及兩者兼得才是對答案的混合姿態。

想看完整的全貌?書中章節包含可執行的 TokenPricingUsageRecord dataclass、量化平方成長的累積對話成本函式、「長大的那個代理」的每日成本示範,以及解釋為什麼輸出比較貴、以及沒人在看的時候計費表怎麼跳的「In Plain English」邊欄。在 Amazon 查看 LLM Primer VI →

下田 昌平
下田 昌平
RECEIPTROLLER 的 CTO 與創辦人。專注於數據、驅動創新、始終保持好奇心。