AI 帳單是企業使用大型語言模型等 AI 服務後收到的用量費用明細：模型以 token 計價、帳務以點數或現金結算，而每一筆費用都應該能歸回某個專案。這份指南寫給第一次要對 AI 費用負責的工程、財務與管理者。
先給答案：一張 AI 帳單只有三層——token 是計價單位、點數是結算單位、逐請求紀錄是稽核單位。帳單難讀，幾乎都是因為其中一層缺了：只有月總額（缺第三層）、各家單位不一致（缺第二層）、或不知道錢花在輸入還是輸出（缺第一層）。以下逐層拆解，再依角色與異常情境對照使用。
第一層：token 是計價的最小單位
token 大致可以想成字的碎片，一個中文字通常折合一到兩個 token。這一層有三個計價事實，決定了你帳單的形狀。
輸入與輸出分開計價，輸出貴數倍
同樣一筆請求，回答越長越貴。控制輸出長度（例如限制回覆格式）是最直接的成本槓桿。
上下文越長越貴，每一段背景都在計費
你貼進提示的每一份文件、每一輪歷史對話都算輸入 token。輸入異常肥大，多半是上下文塞了不必要的內容。
快取命中另計費率，重複前綴可以省下大半
重複出現的系統提示與文件前綴，命中快取時費率遠低於新內容。各家供應商的公開費率頁都把這三件事列成表格，例如 OpenAI 的定價頁；同一句話交給不同模型，成本可能相差數十倍——各模型的計價模式可在模型清單對照。
所以比起盯著單價表，更實用的內部指標是每千次呼叫的平均成本：它同時反映模型選擇、提示長度與快取策略。多步 agent 還要搭配每次完成任務成本——見什麼是 agent tax。
第二層：點數把多家費率換成同一種單位
同時使用多家模型時，每家的幣別、費率表、計價邏輯都不同，財務會收到好幾種語言寫成的帳單。點數制的意義在此：先儲值，各模型依費率扣點，所有消耗最後落在同一種單位上。
為什麼需要同一種結算單位
點數不是價格魔術，而是把「不同供應商的計價邏輯」翻譯成財務看得懂的同一種語言；預算、對帳、趨勢分析才有共同基準。運作細節見點數文件。
低水位告警讓服務不會中途斷線
搭配餘額告警與自動儲值，「跑到一半沒額度」就從事故變成一則通知。
第三層：逐請求歸帳是最小的可稽核單位
一張看得懂的帳單，最小單位不是「這個月」，而是「這一次呼叫」。
一筆逐請求紀錄長什麼樣
月報只能告訴你花了多少，回答不了「誰、為了什麼」。逐請求紀錄把每一筆呼叫都寫下專案、金鑰、模型與 token 數：
{
"request_id": "req_01HZXK3T9",
"project": "support-bot",
"model": "claude-sonnet-5",
"input_tokens": 1284,
"output_tokens": 412,
"cost_credits": 0.0087
}
歸帳品質由金鑰決定
如果多個系統共用一把金鑰，上面那筆紀錄能告訴你模型與成本，卻永遠說不出是哪個團隊。專案金鑰與逐請求歸帳其實是同一個功能：金鑰替每筆請求蓋上主人的章，紀錄讓這個章日後可稽核。這也是企業 AI 治理清單把「一個專案一把金鑰」放在第 1 項的原因。欄位與報表見用量與費用。
依角色：工程、財務與管理層各看哪一層
工程看第一層：token 結構
輸入輸出比例、快取命中率、模型選擇——三個數字決定單位成本能不能再降。
財務看第二層：點數與儲值節奏
一種單位、一份帳單、可預測的儲值週期；異常留給第三層去查。
管理層看第三層的彙總：專案別趨勢
按專案加總的月趨勢，是續編 AI 預算時唯一站得住腳的依據。
依情境：三種常見的帳單異常
費用突然跳升——先按專案排序，再往模型鑽
九成的跳升集中在單一專案——這也是上線後 AI 帳單為什麼會炸的同一種模式；逐請求紀錄能在幾分鐘內把範圍縮小到一個模型、甚至一段部署時間。
輸入 token 異常肥大——檢查上下文組裝邏輯
常見元兇是「把整份文件塞進每一輪對話」；修法通常是改用摘要或檢索。
餘額不足導致中斷——設告警水位與自動儲值
把「還剩多少點數」變成儀表板上的日常數字，而不是事故報告裡的第一行。
更現代的做法：用 ATP Token 把歸帳變成預設值
上面三層，逐層自建都做得到，但更現代的做法是讓平台預設就長這樣：專案金鑰決定歸屬、每筆請求自動寫入紀錄、所有模型以點數結算——工程不用改呼叫方式（相容 OpenAI、Anthropic 與 Gemini 格式，換 base_url 即接入），財務每月只看一份帳單。
延伸閱讀
帳單不該是月底的驚喜，而是日常就看得到的儀表板。三層都對上之後，「AI 花了多少錢」就從一個難題，變成一個查詢。