成本歸因到功能：知道每個功能花了多少錢

標籤設計

@dataclass
class CostTag:
    feature: str        # 'rag_qa' | 'summarize' | 'agent_support'
    tenant: str         # 客戶或部門
    user_id: str
    env: str            # prod | staging
    trigger: str        # 'user' | 'batch' | 'internal' | 'eval'

# 每次呼叫都帶標籤，並在回應後記錄實際用量
def call_llm(messages, tag: CostTag, **kw):
    r = provider.chat(messages, **kw)
    metrics.record_cost(
        **asdict(tag),
        model=kw.get('model'),
        in_tok=r.usage['in'], out_tok=r.usage['out'],
        cost_usd=price(kw.get('model'), r.usage),
    )
    return r

`trigger` 欄位很關鍵

把「使用者觸發」「批次任務」「內部測試」「評測」分開。很多團隊發現自己有兩三成的成本來自評測與測試——這不是壞事，但必須被看見，才能判斷是否合理。

可以回答的問題

• 每個功能的每月成本與趨勢。
• 每位使用者的平均成本（用於定價決策）。
• 每個客戶的成本（用於毛利分析）。
• 哪個功能的成本成長最快。
• 單次操作的成本分布（p50 / p95），找出昂貴的長尾。

搭配業務指標看

-- 每個功能的成本效益
SELECT feature,
       SUM(cost_usd)                      AS cost,
       COUNT(*)                           AS calls,
       SUM(cost_usd) / COUNT(*)           AS cost_per_call,
       SUM(CASE WHEN success THEN 1 END)  AS successes,
       SUM(cost_usd) / NULLIF(SUM(CASE WHEN success THEN 1 END), 0)
                                          AS cost_per_success
FROM llm_costs
WHERE ts >= NOW() - INTERVAL '30 days' AND env = 'prod'
GROUP BY feature ORDER BY cost DESC;

cost_per_success 比 cost_per_call 有意義得多。一個單次便宜但常常失敗需要重試的功能，實際成本可能更高。

設定預算與告警

1. 每個功能設月度預算，達 80% 時告警。
2. 單日成本超過近七日中位數兩倍時告警——這通常代表出現了迴圈或濫用。
3. 新功能上線後兩週內密切追蹤，成本估算失準是常態。