Token 計費怎麼算?給技術主管看的 LLM API 成本估算指南

幾乎所有大型語言模型 API 都是按 token 計費,但「這次呼叫要花多少錢」很少只有一個數字,因為單一請求可能同時牽涉四種計費類型不同的 token:輸入 token、輸出 token,以及部分供應商支援的快取讀取與快取寫入 token。搞清楚一次請求裡各自佔了多少比重,是「成本估算準確」跟「帳單突然爆掉」的差別。

Token 到底是什麼

Token 是模型的分詞器(tokenizer)把輸入文字切成的最小單位,可能是一個詞的片段,也可能是一個完整的短詞。不同模型家族用的分詞器不完全相同,所以同一句話丟給不同模型,算出來的 token 數量也會不一樣。

為什麼同一句話在不同模型上計費會不一樣?

不同模型家族的分詞器詞彙表不同,如果一段文字裡包含分詞器訓練資料涵蓋較少的語言或符號,切出來的 token 數量就會變多,計費自然也跟著變高。

輸入 token 跟輸出 token 的定價落差

幾乎每一家主流供應商,輸出 token 的單價都比輸入 token 高,而且經常是好幾倍。這反映的是實際運算成本的差異:每產生一個輸出 token 都要完整跑一次推論,而一大批輸入 token 可以用更有效率的方式平行處理。實務上,這代表輸入內容多、輸出內容少的任務(例如分類、資訊擷取),即使總 token 數一樣,單次呼叫成本也會比開放式生成任務低。

這對怎麼寫提示詞有什麼影響?

多數團隊容易忽略的成本槓桿,不是縮短輸入內容,而是限制輸出長度。要求模型回傳結構化、有明確邊界的結果(固定欄位的 JSON、有字數上限的摘要),直接壓低輸出 token 量——而輸出通常才是佔比更高的那一項。

快取讀取與快取寫入:最容易被漏算的兩種計費

部分供應商支援提示詞快取:如果同一段長系統提示詞或內容區塊被重複傳送,供應商可以在第一次請求之後把它快取起來,之後的請求用比較低的費率讀取快取內容,代價是第一次會有一筆(通常不高的)快取寫入費用。對於有大量穩定、重複內容的任務(長系統提示詞、需要反覆查詢的長文件),這能明顯壓低輸入 token 的整體成本,因為快取讀取的單價通常遠低於標準輸入。

什麼情況下用快取反而不划算?

如果每次請求的內容都不一樣,就沒有可以被快取的穩定部分,寫入費用等於白花。快取真正划算的情境,是提示詞裡有一大段內容會在短時間內被大量重複呼叫使用。

四種計費類型的成本心法

確切的倍率因模型跟時間而異,這張表是幫助理解成本結構的心法,不是精確數字的來源——確定預算前,請以當下的實際定價頁面為準。

用多個模型之後,這件事會變得更重要

一旦團隊同時使用多個模型——Claude 處理推理密集任務、便宜一點的模型處理分類、DeepSeek 處理成本敏感的批次工作——上面這四種計費類型會在每個模型上各自重複一輪,而且絕對金額還不一樣。分散在多個供應商後台手動追蹤,很快就會失控。

PioModel 把 Claude、GPT、DeepSeek、GLM、Kimi、通義千問、Llama、Grok 的所有計費,都統一放在同一份透明的按量計費帳本上,不用為了比較不同模型的成本,分別匯出好幾份後台資料。