計費、成本控制與毛利

傳統 SaaS 的邊際成本接近零——多一個用戶，基礎建設成本增加很少。Agentic SaaS 打破這個假設：每次 LLM API 呼叫都有直接的 token 費用，而且費用隨用戶的使用方式大幅波動。這改變了定價邏輯、毛利結構，以及如何設計 metering 系統。

Token-Based 計費的本質

目前主流 LLM provider 的計費單位是 token，輸入（prompt）和輸出（completion）分別計費，輸出通常比輸入貴 3–5 倍：

以 2025 年的公開定價為例：

Claude Sonnet 4.5： $3/1 M in p u tt o k e n s ，$ 15 / 1M output tokens
GPT-4o： $2.50/1 M in p u tt o k e n s ，$ 10 / 1M output tokens
Gemini 1.5 Pro： $3.50/1 M in p u tt o k e n s ，$ 10.50 / 1M output tokens

（以上為大致數量級，具體定價請查閱各 provider 官方頁面，2025 年以來降價頻繁）

RAG 和 agent loop 顯著放大了 token 消耗：每次查詢不只有 user message，還有 system prompt + retrieved chunks + tool definitions + conversation history。一個「簡單」的 agentic 任務消耗的 tokens 很容易比純 prompt-response 多 5–20 倍。

不可預測成本的問題

Token 計費的核心問題是用戶行為驅動成本，但你無法控制用戶怎麼用：

一個用戶把 100 頁 PDF 丟進 RAG，另一個用戶只問一句話——消耗的 tokens 相差 100 倍
Agent loop 的迭代次數受任務複雜度影響，難以預測
多 agent 協作的任務，每個 LLM 呼叫都在計費

Kinde 的分析把這個問題描述為：「你的應用程式的 token 消耗可以隨不同用戶輸入大幅波動，使得設定固定價格並保證利潤率而不留緩衝空間變得困難。」這是工程事實，不是主張。

Metering 架構

要控制成本，首先要能量測成本。Flexprice 和 Traceloop 均指出，控制 LLM 成本的唯一方法是把 token 使用量歸屬到具體維度：per-user、per-feature、per-team、per-task type。

最低可行 metering 系統的要求：

每次 LLM API call 記錄 input_tokens、output_tokens、cache_read_tokens（如果使用 prompt caching）
標記 user_id、feature_name、model_id
累計到時間桶（每小時或每天），供計費和異常偵測使用
設定 per-user 的 token 預算上限，達到時中斷請求並通知用戶

把不可預測成本轉成可預測定價的策略

策略一：Task Quota（任務配額） 不向用戶暴露 token 概念，改用「任務次數」計費。「每月 100 份文件摘要」「每月 50 份合約分析」。內部用歷史 token 分布估算每個 task type 的平均成本，加上合理 margin 定價。壞處是需要足夠的歷史數據才能定價準確，以及任務複雜度的變異仍然存在。

2025 年 LLM provider 本身也在往這個方向走：token billing 逐漸向 task quota 靠攏，SiliconData 分析記錄了這個趨勢。

策略二：Per-Seat with Usage Cap 固定每個座位的月費（例如 $20/ 用戶 / 月），同時設定每個用戶的 t o k e n 使用上限（例如 1 M t o k e n s / m o n t h ）。超過上限後降速或要求升級。 O p e n A I 自己的 B u s in ess pl an 也採用類似模式（$ 20-25/用戶/月，附帶更高 message limit）。

優點：對 B2B SaaS 的採購決策友好（固定預算）。缺點：用量分布的尾部（power users）可能侵蝕毛利。

策略三：Credit System（點數制） 用戶購買一定數量的「credits」，不同 task type 消耗不同數量的 credits。靈活性最高，讓你可以根據實際成本調整 credit 消耗率而不改變定價結構。壞處是增加用戶理解成本。

Prompt Caching：降低重複成本的實際手段

Anthropic Claude 支援 Prompt Caching：對於在多個 API 呼叫中重複出現的 prompt 前綴（system prompt、長文件），可以標記為 cache，之後的呼叫只需支付 cache read 費用（約為原始 input 費用的 10%）。

對於 system prompt 固定且較長的應用（如企業知識庫問答，system prompt + RAG instruction 可能達 2000+ tokens），啟用 prompt caching 可以大幅降低每次查詢的成本。OpenAI 也有類似的 Cached Input 機制（2024 年推出，重複 prefix 自動享 50% 折扣）。

這是有官方文件可查的工程事實，不是主張。

成本對毛利的影響

典型 SaaS 毛利目標是 70-80%。如果每個請求的 LLM 成本佔你定價的 30% 以上，毛利壓力就很大——這在「複雜 agent 工作流 + 小額訂閱」的組合下很常見。

常見的毛利保護手段：

Model tiering：輕量任務（分類、簡單抽取）用便宜的小模型（Haiku、GPT-4o-mini），複雜任務才用大模型
Caching 查詢結果：相同或高度相似的問題可以快取 LLM 回應（semantic caching），但需要謹慎處理快取過期和語意相似度的判斷
Rate limiting + quota：防止單一用戶異常高用量侵蝕其他用戶的利潤

延伸

Token 消耗的主要來源（context、RAG chunks） → RAG、記憶與知識庫
成本和延遲的更廣泛取捨 → 限制、取捨與 Demo 不等於 Production
全景與閱讀路徑 → AI Agentic SaaS 專欄首頁

我的知識庫

探索