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