科普一下：大模型 Token 的收費邏輯！
大家好呀，我是**飛魚**現在工作中經常需要呼叫大模型的 API。
不知道大家有沒有發現，你打開任何一家大模型 API 的定價頁（如下：GPT 和 Claude 的）。
同樣是 TOKEN，輸出比輸入貴 5 倍？快取命中的 TOKEN 又便宜 10 倍？
今天就從原理層面，給大家科普解釋下這些問題。
具體來說，我們得進 GPU 裡看看模型推理時究竟發生了什麼？
首先當你向大模型發送一條訊息，它在後台其實經歷了兩個階段，預填充 Prefill 和 解碼 Decode。
❝
這兩個階段的分界點恰好是你輸入結束，然後模型開始吐字的那一瞬間。
Prefill 階段
❝
模型拿到你的 Prompt 後，會把你輸入的所有 TOKEN 一次性塞進 Transformer，然後算出每一個位置的隱藏狀態。
最後把最重要的產物 KV Cache 鍵值快取保存下來。
這一階段是高度並行的。
假設你輸入了 1000 個 TOKEN，GPU 可以把這 1000 個 TOKEN 同時放進矩陣運算裡，一次前向傳播全部處理完。
GPU 最擅長的就是這種大矩陣並行計算，這個階段的瓶頸是算力，GPU 的計算單元幾乎被榨乾。
每個 TOKEN 分攤下來的成本其實很低。
Decode 階段
❝
Prefill 結束後，模型開始生成輸出。
但模型必須一個一個 TOKEN 地往外吐。
因為每生成一個新 TOKEN 都要把它拼回已有序列裡才能算下一個。
比如：第 N+1 個 TOKEN 依賴第 N 個 TOKEN 的結果，這是 自迴歸（Auto Regressive） 的本質，沒辦法提前並行。
於是每生成一個輸出 TOKEN，GPU 都要把整個模型的參數從顯存搬到計算單元，然後把不斷變長的 KV Cache 也搬過來，算出下一個 TOKEN。
重複以上步驟，這個階段的瓶頸變成了顯存頻寬。
這時候 GPU 的算力大部分時間在空轉，等著資料從顯存慢悠悠傳過來。
所以輸入走 Prefill 路徑：
❝
並行處理，算力拉滿，吞吐量高，一張 GPU 一秒可能處理 10 萬個輸入 TOKEN，分攤到單個 TOKEN 的成本自然低。
輸出走 Decode 路徑：
❝
串行生成帶寬瓶頸，GPU 空轉嚴重。
同樣一張 GPU 一秒可能只能生成幾百個輸出 TOKEN，吞吐量差了兩三個數量級，自然要貴 3 ~ 5 倍。
順帶也解釋了為什麼串流回應看起來是一個字一個字蹦出來，因為它就只能這樣。
最後快取命中的 TOKEN 為什麼能更便宜？
其實是有一個 Prompt Caching 的設計：
❝
思路就是把前綴 KV Cache 存在高速快取裡。
下次請求如果前綴一樣，直接把現成的 KV Cache 載入進來，跳過 Prefill 的計算環節。
此時付出的成本只有儲存這份 KV Cache 的開銷，把它載入進計算顯存的頻寬開銷，算力幾乎不花。
但快取是前綴匹配的，你的 Prompt 必須和之前某次請求的開頭完全一致，哪怕改一個字，後面的部分就全得重算。
而且快取有有效期，一般幾分鐘到幾小時，過期就失效。
所以建議把固定不變的內容 System Prompt 長文件放在最前面，把變化的部分使用者問題放到最後，能最大化快取命中率。
最後有幾個實用的優化方向
❝
能用快取就用快取，把穩定的長前綴放在 Prompt 開頭。
控制輸出長度，讓模型少囉唆，不只是節省閱讀時間，而是實打實省錢。
真的不用害怕長輸入，很多業務場景下塞進幾千 TOKEN 的上下文，只要能換來一個精準的短輸出，總價反而更便宜。
慎用讓模型先推理再回答的模式，思考推理模型產生的思考過程往往會被算進輸出 TOKEN。
❝
最後想看技術文章的，可以去我的個人網站：hardyfish.top/
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
