為什麼你的 LLM 帳單是預期的 3 倍

利益揭露：我是 DigitalOcean 的 Solutions Architect，所以文中提到 DigitalOcean 產品時，是「業內人的觀點」而非中立第三方——這些地方我都會明確標示，其餘分析則盡量保持廠商中立。以下皆為個人觀點。

本文的英文版本已發表於 DigitalOcean Community。

一篇關於隱藏推論成本相乘因子的實務論述，搭配 DigitalOcean Serverless Inference 上的實跑量測。跨供應商的模式到處都適用；文中 DigitalOcean 特有的數字來自 inference.do-ai.run 上有記錄的 API 實跑，不是行銷素材。

這道落差是結構性的，不是帳單出錯

在生產環境裡，你的 LLM 帳單很少會等於 input_tokens × input_rate。供應商之所以拿輸入費率當標價，是因為那是比較小的數字。真實的生產流量要付的是輸出、看不見的思考 token、重複的前綴、非生產環境的重放流量，以及你在不知不覺中跨過的 context 級距。

團隊照著定價頁編預算，然後在收到帳單時大吃一驚。只要把下面五個相乘因子攤開來看，這份意外其實完全可以預測。這些因子會層層相乘。只修好其中一個、放著其他不管，落差大部分還是會留在那裡。

關於定價的說明： 本文引用的 token 費率是 2026 年 6 月的官方定價，來源為各供應商文件與 DigitalOcean Inference 定價頁。編列預算前，請務必再確認一次當下的實際費率。

五個介於標價與帳單之間的相乘因子

輸出 token 主導了混合費率

Claude Sonnet 4.6 的定價是每百萬輸入 token $3.00、每百萬輸出 token $15.00。DigitalOcean Serverless Inference 在撰稿當下也是同樣的比例。

一個輸入對輸出比為 1:2 的對話型工作負載，在其他因子都還沒開始作用之前，混合後就已經是標示輸入費率的 3 倍。把你最近 30 天的用量拉出來看。如果輸出量是輸入的 2 倍或 3 倍，你的實際費率和定價頁上那個數字根本不在同一個量級。

思考 token 以輸出費率計費，而且看不見

具備延伸思考能力的模型（Claude adaptive thinking、OpenAI o3/o4-mini）會產生使用者永遠看不到的 token。供應商是以輸出費率向你收費的。

以 Claude Opus 4.8 每百萬輸出 token $25 計算，500 個可見的輸出 token 再加上 2,000 個思考 token，成本是單獨 500 個可見 token 的 5 倍。Opus 4.8 與 Opus 4.7 強制使用 adaptive thinking。你能控制的是深度，用 effort 參數，而不是固定的上限值：

{
  "model": "claude-opus-4-8",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "low" },
  "messages": [{ "role": "user", "content": "Classify this support ticket." }]
}
json

這個請求送出一段簡短的分類 prompt 給 Claude Opus 4.8，啟用 adaptive thinking，但把 effort 設為 low，讓模型在回答前少花一些看不見的思考 token。Opus 4.8 一定會思考，你關不掉，但你可以讓思考深度與任務相稱。標記一張工單所需的思考預算，不需要跟多步驟的 agent 工作流一樣多。把低 effort 搭配簡單的 prompt，就能避免看不見的思考 token 把一張本來應該貼近可見輸出量的帳單灌大。

每一次回應都去看 usage。當 effort 預設偏高時，推理型模型經常在簡單任務上占掉大部分花費。

非生產環境流量共用同一個 API 帳號

CI pipeline 會在每一個 pull request 上重放 prompt。Staging 環境鏡像著生產環境。負載測試打的是模型端點，驗證的卻是應用程式的擴充能力，而不是模型成本。少了環境標籤，這些全部都會用生產環境的方式計費。

Speedscale 的企業級分析記錄了團隊直到帳單寄來才發現非生產環境占比的情況。請為每一次呼叫加上標籤：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MODEL_ACCESS_KEY"],
    base_url="https://inference.do-ai.run/v1",
)

response = client.chat.completions.create(
    model="anthropic-claude-4.6-sonnet",
    messages=[{"role": "user", "content": "Summarize this log line."}],
    extra_body={
        "metadata": {
            "environment": os.environ.get("APP_ENV", "local"),
            "service": "ci-test-runner",
        }
    },
)
print(response.usage)
python

這段程式透過相容 OpenAI 的 SDK 呼叫 DigitalOcean Serverless Inference，並在每一個請求上掛上 environment 與 service 這兩個 metadata 標籤。這些標籤跟著 extra_body 一起送出，讓你可以依來源（CI runner、staging、生產環境）切分用量紀錄，而不是把每一個 token 都當成生產環境的花費。印出 response.usage 則能取得 token 數量，等標籤化的流量分群後，就能拿來跟帳單對帳。

第一次做環境切分時，CI 與 staging 常常會占到總 token 量的 30% 到 50%。

同一個 prompt，不同模型的冗長度差 2 到 4 倍

同一段分類 prompt，在一個講求周延的模型上會回你好幾段文字；在一個惜字如金的模型上則只回一個標籤。不管是哪一種，每一個輸出 token 你都要付錢。這是模型選擇的量的通道：同樣的任務，不同的輸出 token 數。

在 prompt 裡加上約束（「只回標籤，不要解釋」）可以讓結構化任務的輸出量減少 60% 到 80%。長期來說，要讓模型的冗長度與任務類型相稱，並且以端點為單位量測輸出 token，而不是以模型型錄的條目為單位。

長 context 加價套用到整個請求

GPT-5.5（OpenAI 文件）：輸入 token 在 272K 以下時，每百萬輸入/輸出為 $5/$30。超過 272K 輸入後，整個工作階段都變成每百萬 $10/$45。

Gemini 3.1 Pro Preview（Google 定價頁）：context 在 200K 以內時，每百萬為 $2/$12。超過 200K 後，該請求裡的所有 token 都以每百萬 $4/$18 計費。

RAG pipeline 與多輪 agent 在相當比例的請求上都會跨過這些門檻。請把你的 p95 與 p99 輸入 context 長度，拿去對照每一家供應商的級距邊界。

我們在 DigitalOcean Serverless Inference 上量到的數字

上面那些相乘因子與供應商無關。本節的數字則來自 https://inference.do-ai.run/v1 上的 API 實跑，記錄於 Multi-Model API Cost Governance with the Inference Router（資料截至 2026 年 6 月 16 日）。方法：固定 prompt、temperature=0、token 數取自回應的 usage，成本則依當次實跑時的官方 DigitalOcean Inference 費率計算。

選模型的稅：token 完全相同，成本卻差 36 倍

模型選擇會透過兩條各自獨立的通道推動成本：模型收取的每 token 費率，以及它產生的輸出量（冗長度，也就是因子 #4）。第一組量測隔離的是費率這條通道。同一段分類 prompt、三個模型、完全相同的 token 形狀（94 input / 80 output）——輸出比（因子 #1）與冗長度（因子 #4）都被固定住，唯一的變數就是價格：

openai-gpt-oss-20b 的計算式：(94 × $0.05 + 80 × $0.45) / 1,000,000 = $0.00004070。

當 openai-gpt-oss-20b 已經達到準確度標準，卻還是把每一次分類呼叫都送去 Sonnet，這就是每次請求 36 倍的稅——而且純粹是費率造成的，冗長度都還沒開始加碼。若每月有 700,000 次分類請求，光是路由這一項的差距就是 $28.49 對上 $1,037.40。任何用量折扣都補不回選錯模型的損失。

這和 Metrics that Matter with Serverless Inference 這份範圍更廣的 DO 基準測試結果一致：在同一家供應商上，每則完成回答的成本在整個模型型錄之間大約有 230 倍的落差。供應商的標價只會讓成本移動幾個百分比，模型選擇則是以數量級在移動。

思考輸出量：約為分類任務成本的 840 倍

同一家供應商、不同任務，6 月 16 日的實跑：

推理這條路徑的每次請求成本，約為分類的 840 倍（$0.03417625 對上 $0.00004070）。GPT-5 的輸入費率（每百萬 $1.25）其實比 Sonnet（每百萬 $3.00）還低，所以這不是費率通道造成的效果——帳單之所以爆開，是因為推理產生了 3,411 個輸出 token，而分類只有 80 個。這就是因子 #2、以及因子 #1 的量的通道在數字上的呈現：輸出量（包含在可見答案之前就先計費的思考 token）主導了成本。

重現這份量測

拿你自己的 Model Access Key 跑跑看。它會把成本歸因所需要的 usage 區塊印出來：

curl -s -X POST "https://inference.do-ai.run/v1/chat/completions" \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-gpt-oss-20b",
    "temperature": 0,
    "messages": [
      {"role": "system", "content": "Classify the ticket. Reply with one word: billing, bug, how-to, or account."},
      {"role": "user", "content": "I was charged twice for my subscription last month."}
    ]
  }' | python3 -c "import sys,json; u=json.load(sys.stdin)['usage']; print(u)"
bash

這一行指令會把一段固定的分類 prompt 送給 openai-gpt-oss-20b（temperature=0），並印出回應的 usage 區塊。用你自己的 Model Access Key 跑一次，就能看到 DigitalOcean 實際計費所依據的 prompt_tokens 與 completion_tokens。接著用同一段 prompt 改呼叫 anthropic-claude-4.6-sonnet，兩者的用量差距就是你今天的帳單正在承擔的選模型稅：同樣的任務形狀，不同的每 token 費率。

完整的 router 設定、任務政策，以及 x-model-router-selected-route 回應標頭，都記錄在 Inference Router how-to 與成本治理教學裡。

先有可見度，才談最佳化

大部分的計費儀表板只會顯示總 token 數與總花費。它們沒有告訴你的是：環境切分、快取命中率、思考 token 與可見輸出的比例、長 context 級距的曝險，以及各類任務的輸出分布。

少了這份拆解，你的最佳化就是瞎子摸象。下面這段腳本會用 DigitalOcean／Anthropic 的官方費率，從用量計數器估算混合成本。把它接到你的推論紀錄上：

#!/usr/bin/env python3
"""Estimate blended LLM cost from token usage counters."""

from dataclasses import dataclass

@dataclass
class ModelRates:
    input_per_m: float
    output_per_m: float
    cache_read_per_m: float = 0.0

RATES = {
    "anthropic-claude-4.6-sonnet": ModelRates(3.00, 15.00, 0.30),
    "openai-gpt-oss-20b": ModelRates(0.05, 0.45),
}

def estimate_cost(model, input_tokens, output_tokens, cache_read_tokens=0, thinking_tokens=0):
    rates = RATES[model]
    billable_output = output_tokens + thinking_tokens
    input_cost = (input_tokens / 1_000_000) * rates.input_per_m
    cache_cost = (cache_read_tokens / 1_000_000) * rates.cache_read_per_m
    output_cost = (billable_output / 1_000_000) * rates.output_per_m
    total = input_cost + cache_cost + output_cost
    headline = (input_tokens / 1_000_000) * rates.input_per_m
    return {
        "total_usd": round(total, 4),
        "input_only_usd": round(headline, 4),
        "multiplier_vs_input_rate": round(total / headline, 2) if headline else 0.0,
    }

# 1M input, 2M output, 500K thinking: multiplier ~13.5× vs input-only estimate
print(estimate_cost("anthropic-claude-4.6-sonnet", 1_000_000, 2_000_000, thinking_tokens=500_000))
python

這個小工具會把原始的 token 計數器換算成金額估算，而且把輸出與思考 token 都算進去，不只是輸入。multiplier_vs_input_rate 這個欄位則直接把「定價頁上的算法」與「你實際要付的錢」之間的落差攤開來：程式最後那個例子——1M 輸入、2M 輸出、500K 思考——對比只算輸入的估算，得到的倍數大約是 13.5 倍。把它接到你的推論紀錄上，就能標出哪些端點的混合成本已經偏離了你編的預算。

四個槓桿，依效益排序

Prompt caching 能砍掉重複前綴的成本。Anthropic 的快取讀取以基礎輸入費率的 10% 計費（定價文件）。一段 1M token 的系統 prompt 搭配 80% 的快取命中率，會實質改變輸入端的成本結構。實作機制可參考 Advanced Prompt Caching。

批次推論對非同步的工作負載提供約 50% 的折扣，代價是 24 小時的 SLA。如果你的工作本來就容許延遲，卻還在呼叫同步端點，那就是把最容易拿到的折扣白白留在桌上。

用量折扣會在月花費達到一定規模時啟動。很多明明已經符合資格的團隊，從來沒開口問過。

模型路由在流量同時混雜簡單與複雜任務時，是效益最大的槓桿。上面 6 月 16 日的 DO 實跑顯示，同樣的分類 prompt 就有 36 倍的落差。Inference Router 會在 inference.do-ai.run 上自動完成任務到模型的分派，不需要在應用程式端寫路由邏輯。在 700K / 250K / 50K 的分類／問答／推理流量組合下，以同一組每次請求量測為基礎，有記錄的 router 路由把每月成本降低了相較純 Sonnet 基準的 39.6%、以及相較純 Opus 的 63.7%（完整流量模型請見成本治理教學）。

為什麼按 token 計費與路由能對應到這些相乘因子

因子 #3（非生產環境外洩）本質上是可觀測性問題。在共用 API key 的按 token 計費模式下，環境預設是不會被分開的。解法是在請求的 metadata 裡加標籤，再用一個依 environment 分群 usage 的儀表板。DigitalOcean Serverless Inference 的計費依據，就是 API 回傳的那個 usage 區塊，所以你的紀錄管線和你的帳單共用同一份真實來源。

模型選擇同時推動了因子 #4（冗長度）與費率落差，而兩者都是架構問題。當同一個前沿模型既要做分類又要做推理，你等於是用兩條通道同時為一個單字標籤付前沿模型的價格：較高的每 token 費率（量測到的 36 倍分類溢價），以及對話比較多的模型在同一任務上更高的輸出量。

依任務複雜度做路由，可以讓平均成本與任務價值成比例。分類流量留在 openai-gpt-oss-20b。問答留在 Sonnet，並以 session pinning 維持 KV-cache 的熱度。推理則只在輸出量足以正當化費率時，才升級到 GPT-5。這套架構直接對付因子 #1、#2 與 #4，但它不能取代因子 #3 所需要的環境標籤。

至於代管模式的取捨（按 token 的 serverless 何時該讓位給按 GPU 小時的 dedicated），可參考 Serverless vs Dedicated vs Batch Inference 與 Dedicated vs Serverless Inference as You Scale。DigitalOcean 基礎架構上的快取命中率基準測試，則在 serverless 基準測試管線中另行追蹤。

參考資料

• Multi-Model API Cost Governance with the Inference Router（DigitalOcean，2026 年 6 月實跑）
• Metrics that Matter with Serverless Inference（DigitalOcean 每則回答成本基準）
• Why Serverless Inference Consistency Varies on the Same Model（DigitalOcean 內部 TTFT 測試）
• Anthropic API Pricing
• DigitalOcean Inference Pricing
• GPT-5.5 Model Documentation（OpenAI）
• Gemini API Pricing（Google）
• I Analyzed 60+ LLM Models and Found Companies Overpay by 50-90%（第三方超付分析）
• The Hidden AI Bill: Why Non-Prod LLM Costs Spiral（Speedscale）

這是「生產環境中的 LLM 推論」系列 5 篇文章中的第 1 篇。第 2 篇談模型選擇方法論。第 3 篇談 prompt caching 的實務。第 4 篇談多供應商路由架構。第 5 篇檢視整套 AI stack 的總持有成本。