LLM 成本監控：在帳單暴增之前掌握每一筆支出（2026）

LLM 成本監控：在帳單暴增之前掌握每一筆支出（2026）

LLM 成本監控決定的是一張 412 美元的意外發票，還是預算用到 80% 時 Slack 彈出的一則通知。Claude Sonnet 5 這個月的輸入 token 報價是每百萬 3.00 美元，一個失控的 agent 迴圈一個下午就能燒光這個額度。多數團隊一天內就能接好追蹤；真正被跳過的，是警報那一環。

重點摘要：

• LLM 成本監控為每個請求附加 token 數量與美元估算，再按模型與團隊匯總。
• 追蹤五項指標：每請求 token 數、每功能/團隊/模型成本、快取命中率、每對話成本、飆升速率。
• LiteLLM 預算、Langfuse 追蹤、Datadog LLM Observability，三者都能在一天內上線支出可見性。
• 儀表板顯示的是估算值；快取輸入定價與批次折扣意味著實際發票通常低於估算。

LLM 成本監控到底追蹤什麼？

LLM 成本監控的做法是：為每個 LLM 請求附加 token 數量與美元估算，再按模型、功能、團隊匯總，讓支出能在發票送達之前觸發警報。估算值根據公開的 token 定價逐筆計算，依你在呼叫上標記的標籤向上捲動，並與事先設定的預算比對。

底層的數學與廠商無關。每個供應商的用量回應都會將 token 拆成欄位，Datadog 的成本文件明確記載了這些欄位之間的關係。OpenTelemetry GenAI 語意慣例將相同的欄位跨供應商標準化，因此基於它們建造的儀表板不會被鎖定在單一供應商上。

三組關係承担了大部分工作：總 token 數 = 輸入 + 輸出；輸入 = 非快取 + cache_read + cache_write；reasoning token 包含在輸出內，以輸出費率計價。把這些搞對，每請求估算就會貼近實際；忽略它們，儀表板每個月都會跟帳單產生漂移。成本監控是 AI 可觀測性的三大支柱之一；追蹤與評估是另外兩根，它們共用同一套欄位詞彙。

你的儀表板顯示的是估算值；發票是唯一永遠不會被快取的成本指標。

LLM 的 100 萬 token 值多少錢？

取決於模型與方向：100 萬 token 作為 DeepSeek-V4 輸入是 0.14 美元，作為 GPT-5.6 Terra 輸出則是 15.00 美元，同一單位價差達 100 倍。以下是我們 2026 年 7 月 14 日定價研究的四個模型，已對照官方頁面驗證：

來源：OpenAI 定價與 Anthropic 定價。一個附註：Claude Sonnet 5 在 2026 年 8 月 31 日前適用介紹價，輸入 2.00 美元 / 輸出 10.00 美元，之後恢復上述數字。

真正重要的 5 項指標

五項指標涵蓋了 LLM 費用追蹤，但多數團隊只對其中兩項設了警報。先從前兩行開始：每請求 token 數能在提示膨脹出現當天就抓到它，每團隊成本則是財務部門最終會來要的數字。其餘三項在前兩項就位後進一步細化全貌。

一個顆粒度注意事項：Datadog 依據其成本文件以奈諾美元（美元的十億分之一）儲存請求級成本。在每百萬 token 0.14 美元的費率下，一筆 DeepSeek-V4 請求的成本可能不到千分之一美分，所以先匯總再四捨五入，否則小模型流量會從報告中消失。

如果你什麼都不追蹤，至少追蹤第一行和第二行。每請求 token 數是你最早能拿到的預警；每團隊成本是唯一能經得起會計部門檢驗的數字。

三種接上 LLM 成本監控的方式

這個查詢的搜尋結果首頁沒有一篇附了哪怕一行可執行的程式碼，所以這裡提供三套可運作的部署方案。每一套都能在一天內上線，而且可以組合使用：我們自己同時跑了前兩套。

我們在生產環境實際運作的架構：每個客戶 agent 透過自己的虛擬金鑰與 LiteLLM proxy 對話，每把金鑰設有月度預算，proxy 後方由 Langfuse 追蹤每個請求。 當我們把兩者一起部署時，分工就是重點：proxy 執行上限，追蹤解釋消耗了什麼。 我們的每把客戶金鑰還帶有每分鐘 100,000 token 的 tpm_limit 作為第二道保險；根據 LiteLLM 的文件，proxy 在達到限制後會拒絕請求，我們依賴的是這份文件記載的行為，而非我們自己測出的基準。 我們的設定完全跳過 LiteLLM 1.82.7 和 1.82.8，這兩個版本捲入 2026 年 3 月的供應鏈事件，並釘住映像標籤而非浮動使用 latest。

LiteLLM proxy：虛擬金鑰 + 預算

Techsy 在生產環境運行一套 LiteLLM proxy 部署，每個客戶一把虛擬金鑰，每把金鑰設有月度預算。下面的請求是 LiteLLM virtual_keys 文件記載的標準格式：根據該文件，當這把金鑰的累計支出在一個月內超過 50 美元，proxy 會以預算超限錯誤拒絕後續請求，而非事後才記錄警告。

curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_alias": "client-acme-search",
    "max_budget": 50.0,
    "budget_duration": "monthly",
    "tpm_limit": 100000,
    "models": ["anthropic/claude-sonnet-4-5"]
  }'

用公開定價算一下：以 Claude Sonnet 5 每百萬 token 輸入 3.00 美元 / 輸出 15.00 美元計算，50 美元大約能買 1,670 萬輸入 token 或 330 萬輸出 token，大約是我們較輕量客戶 agent 一週的流量。這正是我們想要的爆炸半徑。tpm_limit 是第二道保險：失控迴圈會在觸及月度預算之前就先撞上每分鐘 10 萬 token 的上限。每使用者歸屬透過 users 端點以相同方式運作，我們的最佳 LLM 閘道器工具指南涵蓋了 proxy 何時值得存在、何時只是多一跳的判斷。

Langfuse：@observe 成本追蹤

Google 自動完成將「langfuse monitoring」與這個查詢配對，原因很充分：Langfuse 是開源追蹤的預設選擇。它的 Python SDK 包裝你的供應商客戶端，讓每次呼叫都成為一條攜帶 token 數量與計算成本的追蹤記錄，詳見 Langfuse 追蹤文件：

# pip install langfuse openai
from langfuse import observe
from langfuse.openai import openai  # drop-in wrapper, auto-traces

@observe()
def answer(question: str):
    return openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": question}],
    )

answer("what is llm cost monitoring")
# the trace now carries usage.total_tokens and total_cost,
# priced from Langfuse's model price cards

成本直接落在追蹤記錄上，你這邊不需要做任何 token 數學；按工作階段或使用者 ID 分組追蹤記錄即可得到每功能匯總，資料不能離開你的網路就自行託管。

Datadog LLM Observability：如果你已經在用

如果你的團隊已經部署了 Datadog agent，它的 LLM 成本文件是本頁最深入的單一參考：奈諾美元級的請求成本、自訂 cost_tags 做團隊與功能拆分、以及針對部分成本缺口的真實故障排除章節。誠實的極限：它只限 Datadog。指標不會離開平台，如果定價不再合適也沒有開源替代方案。選它是為了整合，不是為了彈性。

預算、警報與計費分攤怎麼接？

分三層接：一層是在上限處拒絕請求的預算上限，一層是在上限之前按百分比閾值觸發的 webhook 警報，一層是把展示與計費分攤變成一則查詢而非一場爭論的每團隊虛擬金鑰。LiteLLM 原生提供這三者；這些模式可轉移至任何具備金鑰級預算的閘道器。

只會計算的預算是報表；在上限處拒絕請求的預算才是控制。

在飆升之前觸發的警報

把警報設在上限的 80%，而非 100%。LiteLLM 內建 Slack 警報：在 general_settings 中設定 alerting: ["slack"] 與 alerting_threshold: 80，將 SLACK_WEBHOOK_URL 環境變數指向一個頻道，當金鑰越過閾值時就會收到這樣的訊息：

{
  "text": "LLM budget alert: client-acme-search spent $40.18 of its $50.00 monthly cap (80.4%). Top model: anthropic/claude-sonnet-4-5."
}

在 80% 時，人類還有幾天可以行動：降級模型、收緊提示、或帶著簽核名稱提高上限。100% 的警報是驗屍報告。

從展示到計費分攤

展示（showback）是每個團隊看到自己的支出；計費分攤（chargeback）是從他們的預算中扣除。兩者都靠同一個要素：每團隊一把虛擬金鑰，建立時標記團隊名稱。月度報告就是對支出表做一次 group-by：

這是格式範例，非客戶資料。evals-batch 那行正是模式按預期運作的樣子：批次工作跑到上限就停了，而非悄悄滲入發票。執行行為記載於 LiteLLM 的 virtual_keys 文件，包括預算週期如何重置。

為什麼你的儀表板跟帳單對不上？

因為儀表板按定價計費，而發票套用了你的監控永遠看不到的折扣。快取輸入以基礎價的 0.1x 到 0.25x 計價，批次以半價計價，reasoning token 在輸出計數內以輸出費率計價。當兩個數字分歧時，發票通常是較低的那個，差距幾乎總是來自四種修正因子之一。

開源的 pydantic/genai-prices 目錄說明了為什麼這些倍數因模型而異：每個供應商設定自己的快取與批次係數，所以一張硬編碼的價格表在供應商修改定價卡當天就會漂移。Datadog 的成本文件記載了問題的另一半，即缺少 token 欄位導致請求回傳 COST UNAVAILABLE 的部分成本缺口。當儀表板讀數低於發票時查那裡；當讀數高於發票時查折扣表。最大倍數背後的機制是 LLM 提示快取，而高快取命中率是追蹤估算值超過實際帳單最常見的原因。

不含快取命中與批次折扣的成本估算是天花板，不是預測。

哪些工具真正能做 LLM 費用追蹤？

六款工具涵蓋了大多數生產環境部署：開源與閘道器方面有 Langfuse、LiteLLM、Helicone 和 Portkey，商業方面有 Datadog 和 Braintrust。誠實的區分是執行與可觀測性：proxy 能在預算處拒絕請求，追蹤工具則在事後計量支出。多數成熟的架構最終兩者各用一個。

關於這個領域的廠商內容有一個提醒：Braintrust 自己 2026 年的成本追蹤工具比較把自己排第一，並省略了上表中所有開源選項。讀廠商的清單文章要看它的數據，不要看它的排名。

對於從零開始的團隊，我們會前面跑 LiteLLM、後面跑 Langfuse：proxy 執行預算，追蹤解釋預算，這個組合在你進入託管方案之前不花一分錢。如果你正在衡量兩個追蹤預設選項，我們的 Langfuse vs Langsmith 深入分析了那個選擇，最佳 AI 可觀測性平台評比則涵蓋了整個領域。

從監控到削減成本

監控告訴你錢去了哪裡；下一步是決定多少錢該去那裡。三個槓桿，按報酬排序：快取重複輸入、將簡單請求路由到較便宜的模型、在品質仍維持得住的地方縮小模型規模。我們的降低 LLM API 成本指南涵蓋了每個槓桿，LLM API 定價比較則是上述所有計算的輸入。

我們的觀點：當客戶的 LLM 支出讓他們吃驚時，我們先監控再削減，絕不反過來。在量測之前就先快取的團隊，通常快取的是錯誤的提示。監控告訴你錢去了哪裡；快取與路由決定多少錢去那裡。如果你的發票已經讓你心痛，預約免費諮詢，我們跟你一起看數字。

關於作者

Mert Batur 是 Techsy.io 的聯合創辦人，團隊為 B2B 客戶交付 AI agent、自動化系統與語音/SDR 流程。他撰寫 Techsy 團隊在生產環境實際使用的 LLM 工具堆疊。歡迎在 LinkedIn 交流。

常見問題

LLM 的 100 萬 token 值多少錢？

按定價計算，依模型與方向從每百萬 0.14 美元到 15 美元不等：DeepSeek-V4 輸入每百萬 0.14 美元，GPT-5.6 Terra 輸出每百萬 15 美元。在所有主要供應商上，輸出 token 的費率是輸入的 3 到 6 倍。第一節的表格列出了四個模型，我們的 LLM API 定價比較為全部十七個模型標了價，已於 2026 年 7 月對照 OpenAI 與 Anthropic 頁面驗證。

什麼是 LLM 成本最佳化？

在不降低品質的前提下降低每請求成本的做法：對重複輸入做提示快取、將簡單任務路由到較便宜的模型、對非同步工作使用 Batch API、以及為每個功能選定合適規模的模型。LLM 成本監控是前提，因為你無法最佳化尚未歸屬的東西。快取命中率與每功能成本是最先指向最大槓桿的兩項指標。

為什麼 LLM 這麼貴？

推理是計算密集型：每個產生的 token 都要在 GPU 上跑一次完整的模型前向傳遞，而推理模型在回答之前會花額外 token 思考，以輸出費率計價。長系統提示會在每個請求上倍增那個成本。帳單隨呼叫兩側的冗長度成長，這就是為什麼每請求 token 數是第一項值得觀察的指標。

在美國使用 LLM 要花多少錢？

API 定價以美元計價且全球一致：OpenAI、Anthropic 和 Google 無論請求來自俄亥俄州或大阪，每百萬 token 的定價都相同。區域差異出現在自行託管上，GPU 時數因雲端區域而異，以及加了價差的託管平台上。對 API 工作而言，地點改變的是延遲，不是價格。

如何按團隊追蹤 LLM 成本？

透過 LiteLLM 等 proxy 為每個團隊發放一把虛擬金鑰，建立時用團隊名稱標記每把金鑰，然後按該標籤匯总支出。這樣每個請求從產生的那一刻就帶有歸屬資訊，不需要解析日誌。上方預算章節的展示表就是最終產物：團隊、月度預算、迄今支出、狀態。

LLM 費用追蹤選 Langfuse 還是 Datadog？

如果你要開源、自架、自己掌控資料，選 Langfuse；它免費運行，開箱即追蹤每請求成本。只有當你的團隊已經用它做基礎設施監控時才選 Datadog，因為它的 LLM 成本功能不會離開平台。對多數從零開始的團隊而言，Langfuse 加 LiteLLM proxy 優於單獨使用其中任何一個。

LLM 估算成本與實際發票相符嗎？

不相符，而且通常發票較低。儀表板按定價計費，而快取輸入以 0.1x 到 0.25x 計價、批次作業以 0.5x 計價，所以高快取工作負載的實際帳單會遠低於追蹤估算值。缺少 token 欄位則會把誤差推向另一個方向。上方的漂移表列出了每種倍數以及該去哪裡查。

如何對 LLM 支出飆升設警報？

為每個團隊的月度預算設一個 80% 的閾值警報，透過 webhook 送到 Slack，再加一個日對日 +50% 的異常警報來抓快速燒錢的迴圈。LiteLLM 透過其 alerting_threshold 設定原生提供閾值模式。80% 的警報留下幾天的反應時間；100% 的警報只是確認上限盡了它的職責。

有沒有免費的 LLM 成本追蹤工具？

有，三個可信的。Langfuse 自架免費且開源，依據 Langfuse 定價頁面雲端也有免費 hobby 方案。LiteLLM 內建的金鑰預算在開源 proxy 上不花錢。Helicone 的免費方案涵蓋有速率限制的 proxy 級成本日誌。免費方案涵蓋監控；大規模的執行與警報是付費方案的起點。

結論

今天就選一條部署路徑，因為六週後你會想要的那個警報，現在只要一個下午就能接好。精簡版：

• 先追蹤每請求 token 數與每團隊成本；那兩項就位後再加其餘三項指標。
• 會拒絕請求的預算是控制；只會計算的預算是報表。
• 把警報設在 80%，送到 Slack，在發票能嚇到任何人之前。
• 你的儀表板是估算值；快取輸入與批次定價意味著帳單通常落在它下方。

如果你寧可讓人跟你一起看數字，預約免費諮詢。