← Archive
lm-004137 · 2026-09

訂閱、API 與 Compute Wallet：AI 混合計價制度 — Subscription, API, and the Compute Wallet_ A Hybrid Pricing Architecture for AI Serv

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇

訂閱、API 與 Compute Wallet：AI 混合計價制度

Subscription, API, and the Compute Wallet: A Hybrid Pricing Architecture for AI Services

Series: AI 算力經濟：從訂閱額度到自適應容量市場
Paper 3 / 10
Author: Neo.K
Affiliation: EveMissLab
Version: v1.0
Date: 2026-09-07

摘要

生成式 AI 的商業模式正在逐漸脫離「純訂閱制」與「純 API 按量制」的二分法。完整 AI 產品越來越多地整合模型、記憶、搜尋、檔案、程式執行、Agent、語音、圖像、工作空間與各種連接器；另一方面，高頻使用者、企業與 Agentic Workflow 又需要比固定訂閱額度更具彈性的資源取得方式。因此，單純要求高頻使用者「改用 API」並不能完整解決產品體驗、成本可預測性、功能整合與算力彈性之間的矛盾。

本文提出 Compute Wallet 作為 AI 混合計價制度的中介層。其核心不是將所有產品退化成逐 Token 收費，而是建立一個抽象資源帳本，使訂閱內含權利、額外加購、跨功能使用、超額消耗、rollover、borrow、折扣時段與未來可能的 surrender 機制可以在同一制度中協調。本文進一步區分 Membership Value、Compute Entitlement、Wallet Balance、Throughput Right 與 Monetary Settlement，避免將「付了多少錢」「擁有多少產品功能」「可以消耗多少算力」「當下能跑多快」錯誤視為同一變數。

本文分析 OpenAI、Anthropic 與 Cursor 等現行產品所呈現的混合化趨勢。這些產品已分別出現方案內含額度、shared credit pools、extra usage、按 API 價格超額使用、usage dashboards 與 spend limits，顯示市場已開始驗證「固定訂閱＋彈性用量」的可行性。然而，現行制度仍普遍存在資源池割裂、跨產品不可轉換、額度失效、價格映射不透明與 API／訂閱兩套經濟體系分離等問題。

本文的核心命題是：

Membership+Compute Wallet+Elastic Overage+Throughput Control\boxed{ \text{Membership} + \text{Compute Wallet} + \text{Elastic Overage} + \text{Throughput Control} }

比純訂閱或純 API 更適合未來的整合式 AI 產品。Compute Wallet 應該充當「使用權與實際算力成本之間的抽象層」，而非成為另一個迫使一般使用者理解 Token 定價的複雜帳單系統。

關鍵詞： Compute Wallet、AI 訂閱制、API 計價、混合計價、Usage-Based Pricing、Credits、Rollover、Borrow、Spend Limit、AI 算力經濟

1. 從時間可替代性走向資源可替代性

前兩篇分別提出：

Tbilling≠Tentitlement≠Tcompute≠TworkT_{\mathrm{billing}} \neq T_{\mathrm{entitlement}} \neq T_{\mathrm{compute}} \neq T_{\mathrm{work}}

以及：

Temporal Fungibility≠Unlimited Throughput\text{Temporal Fungibility} \neq \text{Unlimited Throughput}

這解決了「何時可以使用」與「瞬時能使用多快」的概念分離。

但當一名使用者同時使用：

  • Chat；
  • Coding Agent；
  • Deep Research；
  • Image Generation；
  • Voice；
  • Spreadsheet Agent；
  • Workspace Agent；
  • API；

下一個問題就自然出現：

為什麼這些功能一定要存在彼此割裂的額度池？

如果底層共同消耗的是某種計算、儲存、網路、工具與模型資源，那麼產品層是否可以建立一個共同的資源抽象？

本文將這個中介層稱為：

Compute Wallet\boxed{ \text{Compute Wallet} }

但 Compute Wallet 不應被理解成單純的：

Token Wallet\text{Token Wallet}

也不應被理解成：

Cash Wallet\text{Cash Wallet}

它更接近：

abstract entitlement ledger\boxed{ \text{abstract entitlement ledger} }

也就是「抽象使用權帳本」。

2. 為什麼純訂閱制不夠

純訂閱的優點非常明顯。

對使用者而言：

Pmonth=constantP_{\mathrm{month}}=\text{constant}

因此預算高度可預測。

使用者不需要在每次 interaction 前重新估計：

Pi=f(input tokens,output tokens,cache,reasoning,tools)P_i = f( \text{input tokens}, \text{output tokens}, \text{cache}, \text{reasoning}, \text{tools} )

這種價格抽象可以降低：

Ccognitive pricingC_{\mathrm{cognitive\ pricing}}

亦即使用者理解與監控價格所需的認知成本。

然而純訂閱也存在結構問題。

假設每名使用者支付相同價格：

P1=P2=⋯=PnP_1=P_2=\cdots=P_n

但實際成本為：

C1,C2,…,CnC_1,C_2,\ldots,C_n

且可能：

max⁡iCi≫E[Ci]\max_i C_i\gg E[C_i]

那麼高頻使用者可能使：

Ci>PiC_i>P_i

長期而言，平台只能透過：

  • 降低內含量；
  • 設定時間窗；
  • 限制模型；
  • 限制 Agent；
  • 提高方案價格；
  • 依賴輕度使用者交叉補貼；

控制單位經濟。

因此：

Flat Subscription\text{Flat Subscription}

很適合提供「可預測的基本使用權」，卻不一定適合承擔無限制的高變異算力消耗。

3. 為什麼純 API 也不夠

API 按量計價在經濟上非常直接：

PAPI=∑jpjqjP_{\mathrm{API}} = \sum_j p_j q_j

其中 qjq_j 可以是 input token、output token、cached token、image、audio、tool invocation 或其他計費單位。

這對企業與開發者具有高度彈性：

pay only for what you use\text{pay only for what you use}

但純 API 存在另一組成本。

完整 AI 產品通常提供：

Vproduct=Vmodel+VUI+Vmemory+Vfiles+Vsearch+Vagent+Vconnectors+Vcode+Vvoice+Vworkspace+⋯\begin{aligned} V_{\mathrm{product}} ={}& V_{\mathrm{model}} + V_{\mathrm{UI}} + V_{\mathrm{memory}} + V_{\mathrm{files}}\\ &+ V_{\mathrm{search}} + V_{\mathrm{agent}} + V_{\mathrm{connectors}} + V_{\mathrm{code}}\\ &+ V_{\mathrm{voice}} + V_{\mathrm{workspace}} +\cdots \end{aligned}

API 則通常只提供其中的一部分能力介面。

若使用者自行重建完整產品體驗，其總成本更接近：

CAPI,total=Cusage+Cengineering+Chosting+Cintegration+Cmaintenance+CsecurityC_{\mathrm{API,total}} = C_{\mathrm{usage}} + C_{\mathrm{engineering}} + C_{\mathrm{hosting}} + C_{\mathrm{integration}} + C_{\mathrm{maintenance}} + C_{\mathrm{security}}

因此：

API≠Integrated AI Product\boxed{ \text{API} \neq \text{Integrated AI Product} }

把所有高頻使用者推向 API，等於要求使用者自行承擔原本由產品供應商完成的整合成本。

4. 混合制度的基本結構

本文提出的基礎架構是：

AI Plan=Membership+Included Compute+Compute Wallet+Elastic Overage\boxed{ \text{AI Plan} = \text{Membership} + \text{Included Compute} + \text{Compute Wallet} + \text{Elastic Overage} }

其中四者功能不同。

4.1 Membership

Membership 購買的是產品與服務資格。

例如：

M={models,memory,workspace,connectors,privacy,support}M = \{ \text{models}, \text{memory}, \text{workspace}, \text{connectors}, \text{privacy}, \text{support} \}

它不應被完全還原成 Token 數量。

4.2 Included Compute

訂閱方案內含某種基本資源權利：

QincludedQ_{\mathrm{included}}

這部分提供「固定月費帶來的可預測價值」。

4.3 Compute Wallet

Wallet 儲存：

WtW_t

可用於支援功能的額外抽象資源。

它可能來自：

Wt=Wpurchase+Wrollover+Wreward+Wreturn+Wborrow−WusedW_t = W_{\mathrm{purchase}} + W_{\mathrm{rollover}} + W_{\mathrm{reward}} + W_{\mathrm{return}} + W_{\mathrm{borrow}} - W_{\mathrm{used}}

並不要求所有來源都在第一版同時存在。

4.4 Elastic Overage

當：

Qincluded+WtQ_{\mathrm{included}}+W_t

不足時，使用者可以選擇：

Stop\text{Stop}

或：

PAYG\text{PAYG}

因此超額使用不是默認義務，而是一個可控制的選項。

5. Compute Wallet 不等於美元錢包

若 Wallet 直接等價於：

1 USD=固定數量 token1\ \mathrm{USD}=\text{固定數量 token}

會產生一個問題：

模型價格與成本會快速變化。

假設模型 mm 的單位成本從：

pm(t0)p_m(t_0)

下降到：

pm(t1)p_m(t_1)

或者新的高階模型價格高於原模型。

如果 Wallet 完全綁定美元，用戶每次都必須理解新的價格表。

因此本文建議分離：

Wallet Unit≠Settlement Currency\boxed{ \text{Wallet Unit} \neq \text{Settlement Currency} }

Wallet 可以使用抽象 Compute Credit：

CU\mathrm{CU}

平台再維持內部映射：

ϕt:service usage→CU\phi_t: \text{service usage} \rightarrow \mathrm{CU}

例如：

ϕt(m,x)=CU cost of task x on model m\phi_t(m,x) = \text{CU cost of task }x\text{ on model }m

這使產品可以調整模型、路由與成本，而不需要每次都改變使用者的心理帳戶。

6. Compute Wallet 也不應等於 Token Wallet

Token 是語言模型的重要計量單位，但：

1 token≠1 unit of economic cost1\text{ token} \neq 1\text{ unit of economic cost}

因為成本還會受：

C=f(model,input,output,context length,cache,reasoning effort,tool calls,image,audio,agent loops,latency tier)\begin{aligned} C={}&f( \text{model}, \text{input}, \text{output}, \text{context length}, \text{cache},\\ &\text{reasoning effort}, \text{tool calls}, \text{image}, \text{audio}, \text{agent loops}, \text{latency tier} ) \end{aligned}

影響。

因此：

Token Accounting⊂Compute Accounting\boxed{ \text{Token Accounting} \subset \text{Compute Accounting} }

對 API 開發者而言，Token 定價可以保留。

對一般產品使用者而言，更合理的是看到：

本月還有 620 Compute Credits。

而不是：

你剩下 17,392,844 input tokens、4,881,221 cached tokens、……

產品可以內部精確，外部簡單。

7. Membership 與 Compute 必須分離

這是 Compute Wallet 架構中非常重要的一點。

如果所有價值都以 Compute 計價，會忽略很多固定產品成本與非算力價值。

因此：

Psubscription=Pmembership+Pincluded compute\boxed{ P_{\mathrm{subscription}} = P_{\mathrm{membership}} + P_{\mathrm{included\ compute}} }

Membership 可以涵蓋：

  • 帳號與身份；
  • 同步與儲存；
  • 記憶系統；
  • 工作空間；
  • 權限管理；
  • 隱私與安全；
  • 專業 UI；
  • Connector；
  • Support；
  • 團隊協作。

Compute 則處理：

variable inference and execution cost\text{variable inference and execution cost}

這使平台不需要把所有產品功能都強迫轉成按量計費。

8. 現行市場已經出現混合制雛形

截至 2026 年 9 月，市場已經出現多種混合機制。

OpenAI 個人方案在支援功能上採用：

Included Usage→Purchased Credits\text{Included Usage} \rightarrow \text{Purchased Credits}

亦即先消耗方案內含量，達到限制後再由 credit balance 支付額外用量。現行個人 credits 已可在部分支援的 Agentic 功能之間共用，但 OpenAI 明確區分這些 credits 與 API credits。

OpenAI Business、Enterprise 與 Edu 則更進一步提供 shared credit pool；個別使用者超過內含上限後，可由 workspace 購買的共同 credits 繼續支援部分高階功能。

Anthropic 的企業與團隊產品則提供「seat included usage＋extra usage」結構，管理員可以允許額外用量並設定 spending caps；Anthropic 將這種 extra usage 與標準 API rates 連接。

Cursor 的現行方案則更接近：

Monthly Subscription+Included Usage Pools+On-Demand API-Rate Usage\text{Monthly Subscription} + \text{Included Usage Pools} + \text{On-Demand API-Rate Usage}

而且允許使用者關閉 on-demand usage 或設定 spend limit。

這些制度共同指向：

Subscription+Usage-Based Extension\boxed{ \text{Subscription} + \text{Usage-Based Extension} }

正在成為 AI 產品的重要商業模式。

9. 但現在的混合制仍然是「單向的」

現行主流制度大多解決：

Included Usage Exhausted→Buy More\text{Included Usage Exhausted} \rightarrow \text{Buy More}

即：

Q→0⇒Wpurchase>0Q\rightarrow 0 \Rightarrow W_{\mathrm{purchase}}>0

但通常沒有處理：

Qunused>0Q_{\mathrm{unused}}>0

時該怎麼辦。

因此目前的 Wallet 多數仍是：

one-way top-up system\boxed{ \text{one-way top-up system} }

而不是完整資源帳本。

更成熟的制度可能逐步加入：

Rollover\text{Rollover} Borrow\text{Borrow} Reward\text{Reward} Surrender\text{Surrender}

使 Wallet 從「超額付費工具」演變成「算力權利協調層」。

10. Rollover：避免曆法性價值蒸發

若月底未使用額度全部失效：

Qunused(t)→0Q_{\mathrm{unused}}(t) \rightarrow 0

使用者可能產生：

expiration-induced consumption\text{expiration-induced consumption}

因此可以設計有限 rollover：

Qt+1=Qbase+min⁡(αQunused,t,Rmax⁡)Q_{t+1} = Q_{\mathrm{base}} + \min( \alpha Q_{\mathrm{unused},t}, R_{\max} )

其中：

0≤α≤10\leq\alpha\leq1

且 Rmax⁡R_{\max} 是最大可累積量。

這避免無限囤積，同時降低「不用就浪費」的心理。

例如：

α=0.5\alpha=0.5

代表最多將一半未使用額度轉入下一期。

11. Borrow：讓未來額度支援當下專案

工作需求可能高度不均勻。

假設本月突然出現大型專案：

Qtneed>QtavailableQ_t^{\mathrm{need}} > Q_t^{\mathrm{available}}

但使用者下月預期低使用。

可以允許：

Bt≤βQt+1B_t \leq \beta Q_{t+1}

其中 BtB_t 是借用量， β\beta 是最大可借比例。

下一期：

Qt+1available=Qt+1base−BtQ_{t+1}^{\mathrm{available}} = Q_{t+1}^{\mathrm{base}} - B_t

這相當於：

intertemporal compute allocation\boxed{ \text{intertemporal compute allocation} }

而不是要求使用者立刻升級整個月的更高方案。

Borrow 對短期專案型工作尤其合理。

12. Overage：彈性不能等於帳單失控

混合制最大的風險之一，是：

Billing Anxiety\text{Billing Anxiety}

如果使用者不知道一次操作到底會花多少，就會從「額度焦慮」變成「帳單焦慮」。

因此 Elastic Overage 至少需要四個控制。

12.1 Explicit Opt-In

超額使用不應悄悄開啟。

Oenabled∈{0,1}O_{\mathrm{enabled}}\in\{0,1\}

由使用者明確選擇。

12.2 Hard Spend Cap

設定：

Poverage≤Pmax⁡P_{\mathrm{overage}} \leq P_{\max}

12.3 Usage Forecast

執行大型任務前顯示：

C^(Ji)\hat C(J_i)

例如：

預估消耗約 40–70 CU。

12.4 Threshold Warning

在：

25%,50%,75%,90%,100%25\%,50\%,75\%,90\%,100\%

等門檻提供提醒。

因此：

Flexibility+Predictability\boxed{ \text{Flexibility} + \text{Predictability} }

必須一起設計。

Cursor 現行 on-demand usage、可關閉超額使用與 spend limit 的設計，正好說明這類保護機制具有實際產品需求。

13. 跨功能資源池

真正的 Compute Wallet 不應只服務單一功能。

假設使用者擁有：

W=1000 CUW=1000\ \mathrm{CU}

可以由：

F={Chat,Code,Research,Image,Voice,Agent}\mathcal{F} = \{ \text{Chat}, \text{Code}, \text{Research}, \text{Image}, \text{Voice}, \text{Agent} \}

共同消耗。

則：

Wt+1=Wt−∑f∈FCfW_{t+1} = W_t - \sum_{f\in\mathcal{F}}C_f

這使使用者可以自行表達價值偏好。

某人可能：

Ccode≫CimageC_{\mathrm{code}}\gg C_{\mathrm{image}}

另一人則相反。

平台不需要為每個人預測固定產品組合。

14. 但不是所有資源都應強迫共池

跨功能共池也有邊界。

某些功能的成本結構與供應瓶頸可能完全不同，例如：

Cvideo≫CtextC_{\mathrm{video}} \gg C_{\mathrm{text}}

或者某種服務依賴獨立硬體與授權。

因此可以使用：

W=Wgeneral+WspecializedW = W_{\mathrm{general}} + W_{\mathrm{specialized}}

其中：

WgeneralW_{\mathrm{general}}

支援大多數功能，

而：

WspecializedW_{\mathrm{specialized}}

用於昂貴或受限服務。

這比完全割裂與完全共池更具有實務彈性。

15. 訂閱與 API 是否應共用 Wallet

這是最敏感但也最重要的制度問題之一。

現行市場通常區分：

WproductW_{\mathrm{product}}

與：

WAPIW_{\mathrm{API}}

這有合理原因：

  • API 可以被自動化；
  • API 有更高 burst potential；
  • API 可能被嵌入商業產品；
  • API 的安全、責任與計價模式不同；
  • 訂閱通常假設單一人類使用者。

因此不宜簡單宣布：

Wproduct=WAPIW_{\mathrm{product}} = W_{\mathrm{API}}

更合理的設計是引入轉換率：

WAPI=κWproductW_{\mathrm{API}} = \kappa W_{\mathrm{product}}

其中：

0<κ≤10<\kappa\leq1

並受到：

RAPIR_{\mathrm{API}}

與 API policy 約束。

例如：

100 Product CU→60 API CU100\ \mathrm{Product\ CU} \rightarrow 60\ \mathrm{API\ CU}

這種 haircut 可以降低：

Subscription→API Resale\text{Subscription} \rightarrow \text{API Resale}

套利。

因此：

fungibility≠1:1 convertibility\boxed{ \text{fungibility} \neq \text{1:1 convertibility} }

16. Compute Wallet 與「訂閱轉 API」的制度差異

非官方中轉的典型結構是：

Consumer Subscription→Unofficial Gateway→External API Users\text{Consumer Subscription} \rightarrow \text{Unofficial Gateway} \rightarrow \text{External API Users}

而官方 Wallet 架構則是：

Subscription Entitlement→Provider-Controlled Conversion→Authorized Interface\text{Subscription Entitlement} \rightarrow \text{Provider-Controlled Conversion} \rightarrow \text{Authorized Interface}

兩者的核心差異在於：

identity\text{identity} authorization\text{authorization} pricing\text{pricing} rate control\text{rate control} resale rights\text{resale rights}

是否仍由供應商掌握。

因此，Compute Wallet 的目標不是替非官方套利合法化，而是：

把其中真正存在的使用者需求——跨介面彈性——轉化成官方可以控制的產品能力。

17. Dynamic Exchange Rate

不同模型與功能成本持續變化，因此 Wallet 需要動態換算。

定義：

ϕ(m,f,t,p)\phi(m,f,t,p)

為某時刻模型 mm 、功能 ff 、優先級 pp 的 CU 換算函數。

則任務 JJ 的扣款：

CCU(J)=ϕ(m,f,t,p)⋅q(J)C_{\mathrm{CU}}(J) = \phi(m,f,t,p)\cdot q(J)

平台可以依：

Model Cost\text{Model Cost} Capacity\text{Capacity} Latency\text{Latency} Energy\text{Energy} Demand\text{Demand}

調整 ϕ\phi。

但這產生透明度問題。

因此所有動態匯率都應滿足：

ex ante visibility\boxed{ \text{ex ante visibility} }

也就是使用者在任務執行前能看到預估，而不是事後才知道扣了多少。

18. Price Abstraction 與 Cost Transparency 並不矛盾

看似矛盾的兩個要求其實可以同時存在：

第一：

一般使用者不想理解每個 Token 的價格。

第二：

使用者又希望知道自己還剩多少、這個任務大概多貴。

因此需要：

Abstract Price+Transparent Consumption\boxed{ \text{Abstract Price} + \text{Transparent Consumption} }

例如 UI 只需要顯示：

本月內含：780 CU
Wallet：240 CU
此任務預估：35 CU
低峰執行：24 CU
超額付費：關閉

這比直接展示複雜 API rate card 更符合完整產品體驗。

19. 使用者會根據價格改變策略

Compute Wallet 不能假設使用者行為固定。

令需求：

D=D(P,M,Q,F,T)D = D(P,M,Q,F,T)

其中：

  • PP：價格；
  • MM：模型能力；
  • QQ：剩餘額度；
  • FF：功能；
  • TT：時間與 deadline。

當：

P↓P\downarrow

或：

Qavailable↑Q_{\mathrm{available}}\uparrow

使用者可能將原本單次推理改成：

Generate→Critique→Verify→Regenerate\text{Generate} \rightarrow \text{Critique} \rightarrow \text{Verify} \rightarrow \text{Regenerate}

甚至啟動多 Agent：

Ncalls↑↑N_{\mathrm{calls}}\uparrow\uparrow

所以產品定價不是被動記帳，而是：

behavior-shaping mechanism\boxed{ \text{behavior-shaping mechanism} }

這也是後續 Demand Engineering 的基礎。

20. Compute Wallet 可以成為需求感測器

若 Wallet 清楚記錄：

qi(t,m,f,p)q_i(t,m,f,p)

平台可以觀察：

  • 使用者何時消耗；
  • 哪些功能消耗最多；
  • 哪些模型具有最高替代性；
  • 什麼價格下使用者會切換；
  • 哪些任務願意延遲；
  • 哪些使用者需要短期 burst；
  • 哪些方案長期存在大量 unused entitlement。

因此：

Wallet Telemetry→Demand Model\text{Wallet Telemetry} \rightarrow \text{Demand Model}

企業可以進一步估計：

D^(t+τ)\hat D(t+\tau)

這些資料會直接支援後續：

Off-Peak Discount\text{Off-Peak Discount} Capacity Planning\text{Capacity Planning} Model Routing\text{Model Routing}

與：

Investment Planning\text{Investment Planning}

21. 企業版：Organization Compute Wallet

對企業而言，個人 Wallet 可以提升為：

WorgW_{\mathrm{org}}

其中所有 seat 的使用可以先消耗個人 included allocation，再由共同池支援。

定義：

Worg=∑iWi+WsharedW_{\mathrm{org}} = \sum_i W_i + W_{\mathrm{shared}}

並加入：

LiL_i

作為每名員工的 spend limit。

因此：

qi≤Liq_i\leq L_i

企業管理員可以：

  • 設定部門額度；
  • 設定個人 hard cap；
  • 允許特定專案 burst；
  • 觀察 usage analytics；
  • 將未使用額度重新分配；
  • 預留高優先級資源。

OpenAI 現行 shared credit pool 與 Anthropic 的 admin-controlled extra usage 已經是這種制度的早期形式。

22. Wallet 的七種資源流

完整 Compute Wallet 最終可能有七種基本操作：

O={Earn,Consume,Purchase,Rollover,Borrow,Convert,Surrender}\boxed{ \mathcal{O} = \{ \text{Earn}, \text{Consume}, \text{Purchase}, \text{Rollover}, \text{Borrow}, \text{Convert}, \text{Surrender} \} }

其中：

Earn

方案每期自動獲得 included allocation。

Consume

使用 AI 功能扣除 CU。

Purchase

額外購買。

Rollover

將部分未用額度移至未來。

Borrow

從未來週期提前取得部分額度。

Convert

在不同資源池或介面間換算。

Surrender

主動放棄某些未來使用權，換取 credit、折抵或其他補償。

前六項構成本文主要制度。

第七項將在下一篇進一步討論。

23. Wallet Conservation 與非守恆

Compute Wallet 看起來像貨幣，但它不必是完全守恆的。

如果：

WA→WBW_A\rightarrow W_B

平台可以設定：

WB=αWAW_B=\alpha W_A

其中：

0<α≤10<\alpha\leq1

差額：

(1−α)WA(1-\alpha)W_A

可以被視為：

  • 轉換成本；
  • 不同產品成本差；
  • 反套利 haircut；
  • 容量風險費；
  • 時間價值調整。

因此 Wallet 更接近：

programmable service entitlement\text{programmable service entitlement}

而不是法定貨幣。

這也是為什麼不宜直接稱為「Token 資產」。

24. 一個完整的消費者方案範例

假設某 AI Pro Hybrid 方案為：

Pmonth=200 USDP_{\mathrm{month}}=200\ \mathrm{USD}

包含：

Qincluded=1000 CUQ_{\mathrm{included}}=1000\ \mathrm{CU}

其中：

FT=0.8F_T=0.8

允許：

Rrollover=300 CUR_{\mathrm{rollover}}=300\ \mathrm{CU}

最大 Borrow：

Bmax⁡=200 CUB_{\max}=200\ \mathrm{CU}

額外 Wallet 可自行購買。

使用者介面只有：

本月內含額度

640 CU640\ \mathrm{CU}

上月保留

120 CU120\ \mathrm{CU}

已購買 Wallet

80 CU80\ \mathrm{CU}

因此：

Wavailable=840 CUW_{\mathrm{available}} = 840\ \mathrm{CU}

如果今天要跑大型 Agent：

即時執行：120 CU
今天完成：95 CU
離峰完成：70 CU

使用者不需要知道底層到底是幾百萬 Token、多少 GPU-seconds 或多少瓦時。

這就是 Price Abstraction 的價值。

25. 一個企業方案範例

假設企業有：

N=100N=100

個 seats。

每 seat 包含：

q=500 CUq=500\ \mathrm{CU}

則：

Qbase=50,000 CUQ_{\mathrm{base}}=50,000\ \mathrm{CU}

企業另外購買：

Wshared=20,000 CUW_{\mathrm{shared}}=20,000\ \mathrm{CU}

各部門可設定：

Lengineering=30,000L_{\mathrm{engineering}}=30,000 Lresearch=20,000L_{\mathrm{research}}=20,000 Loperations=10,000L_{\mathrm{operations}}=10,000

剩餘：

10,00010,000

作為彈性池。

如果工程部某週突然需要大量 Agent：

qengineering↑q_{\mathrm{engineering}}\uparrow

就從 shared pool 取得，而不必立即替所有員工升級方案。

這比：

every user buys highest tier\text{every user buys highest tier}

更有效率。

26. 與傳統 SaaS 的差異

傳統 SaaS 常見：

P=Nseat⋅PseatP = N_{\mathrm{seat}}\cdot P_{\mathrm{seat}}

因為一名使用者登入 CRM 或文件工具，不一定產生巨大邊際算力成本。

AI 不同。

其變動成本可能隨使用量顯著增加：

∂C∂q>0\frac{\partial C}{\partial q}>0

而 Agent 化後：

qagent≫qchatq_{\mathrm{agent}} \gg q_{\mathrm{chat}}

因此純 seat pricing 容易產生：

Revenue∝̸Compute Cost\text{Revenue} \not\propto \text{Compute Cost}

Compute Wallet 則可以保留 SaaS 的 Membership：

PmembershipP_{\mathrm{membership}}

同時把高度變動的推理成本：

CvariableC_{\mathrm{variable}}

獨立處理。

27. 與純雲端計價的差異

但 AI 產品也不能完全照抄 AWS 或 Azure。

雲端客戶通常願意理解：

  • vCPU；
  • GB RAM；
  • GPU-hours；
  • region；
  • provisioned throughput。

一般 AI 使用者並不希望管理這些變數。

因此：

internal economic sophistication≠external UI complexity\boxed{ \text{internal economic sophistication} \neq \text{external UI complexity} }

平台內部可以是一個高度複雜的容量市場。

使用者外部仍然只需要：

現在跑、晚點跑、剩多少、要不要多花。

這是 Compute Wallet 與雲端帳單最重要的產品差異。

28. 可測試假說

H1：混合制能提高高變異使用者的留存

對：

Var[qi(t)]≫0\mathrm{Var}[q_i(t)]\gg0

的使用者，預期：

Retentionhybrid>Retentionfixed\text{Retention}_{\mathrm{hybrid}} > \text{Retention}_{\mathrm{fixed}}

H2：Spend Cap 可以降低 PAYG 的價格焦慮

若：

Pmax⁡P_{\max}

由使用者預先設定，則超額使用意願可能提高，而帳單爭議下降。

H3：Rollover 會降低 expiration-induced consumption

預期：

Qwaste↓Q_{\mathrm{waste}}\downarrow

且：

Qartificial↓Q_{\mathrm{artificial}}\downarrow

H4：Borrow 對專案型使用者的價值高於平均型使用者

當：

BCRi\mathrm{BCR}_i

較高時，Borrow 的效用應更高。

H5：跨功能 Wallet 會提高功能替代效率

使用者可將低價值功能的未使用額度轉向高價值功能：

Vtotal↑V_{\mathrm{total}}\uparrow

H6：完全 1:1 API 轉換會增加套利風險

若：

κ=1\kappa=1

且訂閱有效單價低於 API：

Psub,eff<PAPIP_{\mathrm{sub,eff}}<P_{\mathrm{API}}

則：

Aarbitrage↑A_{\mathrm{arbitrage}}\uparrow

因此合理的：

κ<1\kappa<1

可能是必要的。

29. 實驗矩陣

可以比較四種產品。

Model A：Pure Subscription

P=PmonthP=P_{\mathrm{month}}

固定時間窗。

Model B：Subscription + Overage

方案內含量用完後：

Qextra→PAYGQ_{\mathrm{extra}} \rightarrow \text{PAYG}

Model C：Subscription + Compute Wallet

加入：

Rollover+Purchase+Cross-Feature Pool\text{Rollover} + \text{Purchase} + \text{Cross-Feature Pool}

Model D：Adaptive Compute Wallet

再加入：

Borrow+Dynamic Exchange+Flexible Scheduling\text{Borrow} + \text{Dynamic Exchange} + \text{Flexible Scheduling}

比較：

Retention\text{Retention} ARPU\text{ARPU} Gross Margin\text{Gross Margin} Peak Load\text{Peak Load} Unused Entitlement\text{Unused Entitlement} Billing Complaints\text{Billing Complaints} Task Completion\text{Task Completion} Cross-Feature Adoption\text{Cross-Feature Adoption}

即可驗證混合制度是否真正優於單一計價模式。

30. 制度原則

本文提出八項基本原則。

原則一：訂閱不應被消滅

訂閱提供：

Predictability+Price Abstraction+Integrated Product Value\text{Predictability} + \text{Price Abstraction} + \text{Integrated Product Value}

這些都具有獨立價值。

原則二：API 也不應被視為異常高階模式

API 是必要的可程式化 Consumption Interface。

原則三：Wallet 位於兩者之間

Subscription↔Compute Wallet↔Usage Interfaces\boxed{ \text{Subscription} \leftrightarrow \text{Compute Wallet} \leftrightarrow \text{Usage Interfaces} }

原則四：Wallet Unit 不等於 Token

應建立抽象資源單位。

原則五：Wallet Unit 不等於現金

它是可程式化服務權利，而不是貨幣。

原則六：所有超額使用都應可預測與可停止

Opt-In+Forecast+Hard Cap\text{Opt-In} + \text{Forecast} + \text{Hard Cap}

原則七：跨介面 Fungibility 應有轉換規則

κ\kappa

可以避免不合理套利。

原則八：產品複雜度應藏在系統內，而不是丟給使用者

complex backend+simple economic interface\boxed{ \text{complex backend} + \text{simple economic interface} }

31. 限制與開放問題

Compute Wallet 仍有多個尚未解決的問題。

第一，CU 如何標準化。

如果模型效率快速改變：

ϕt\phi_t

就必須更新。

第二，Wallet 的使用權是否構成可轉讓資產。

本文暫不假定可轉讓。

第三，rollover 是否會造成未來 period 的容量負債。

如果大量使用者累積：

WrolloverW_{\mathrm{rollover}}

平台可能形成：

latent compute liability\text{latent compute liability}

第四，borrow 會不會造成使用者長期「算力負債」。

第五，跨 API 的轉換如何避免訂閱套利。

第六，是否應允許供應商主動回購或要求使用者 surrender 未來 priority entitlement。

最後一項正是下一篇的核心。

32. 結論

生成式 AI 的市場正在證明：

Subscription\text{Subscription}

與：

Usage-Based Pricing\text{Usage-Based Pricing}

並不是互斥制度。

訂閱適合提供：

Predictability+Membership+Integrated Experience\text{Predictability} + \text{Membership} + \text{Integrated Experience}

API 與按量機制則適合提供：

Elasticity+Programmability+Marginal Cost Alignment\text{Elasticity} + \text{Programmability} + \text{Marginal Cost Alignment}

真正值得設計的是兩者之間的中介層。

本文提出：

Compute Wallet\boxed{ \text{Compute Wallet} }

作為這個中介。

其長期形式可以表示為：

AI Plan=Membership+Included Compute+Wallet+Rollover+Borrow+Conversion+PAYG Overage+Throughput Control\boxed{ \begin{aligned} \text{AI Plan}={}& \text{Membership}\\ &+\text{Included Compute}\\ &+\text{Wallet}\\ &+\text{Rollover}\\ &+\text{Borrow}\\ &+\text{Conversion}\\ &+\text{PAYG Overage}\\ &+\text{Throughput Control} \end{aligned} }

這不是將 ChatGPT、Claude 或其他 AI 產品變成複雜的雲端帳單。

恰恰相反。

理想的制度應該讓底層：

pricing and capacity coordination\text{pricing and capacity coordination}

更加精細，

而讓使用者上層看到的介面更加簡單。

因此，本篇的核心命題可以表述為：

The future AI subscription is not a fixed quota; it is a membership wrapped around a programmable compute entitlement.\boxed{ \text{The future AI subscription is not a fixed quota; it is a membership wrapped around a programmable compute entitlement.} }

中文即：

未來的 AI 訂閱不應只是固定額度，而應是一個包覆於產品會員權益之中的可程式化算力使用權。

而當這個使用權可以被累積、借用、轉換與加購之後，下一個自然問題就是：

如果我根本不需要這部分使用權，它能不能被返還、轉讓，甚至由供應商主動買回？

這將把 Compute Wallet 從單純的計價工具，推向真正的雙向 AI 算力市場。

參考資料

  1. OpenAI Help Center. Using Credits for Flexible Usage in ChatGPT (Personal plans). Accessed 2026-09-07.
  2. OpenAI Help Center. Flexible pricing for the Enterprise, Edu, and Business plans. Accessed 2026-09-07.
  3. OpenAI Help Center. ChatGPT Rate Card (Business, Enterprise/Edu credit-based pricing). Accessed 2026-09-07.
  4. Anthropic. Claude Code and new admin controls for business plans. 2025-08-20; accessed 2026-09-07.
  5. Anthropic Help Center. How do usage and length limits work? 2026-07-13; accessed 2026-09-07.
  6. Cursor Docs. Usage-based charges. Accessed 2026-09-07.
  7. Cursor Docs. Usage and limits. Accessed 2026-09-07.
  8. Cursor Docs. Models & Pricing. Accessed 2026-09-07.

Series Navigation

Paper 1
AI 訂閱制的制度錯位：當曆法時間不再等於智能消耗

Paper 2
額度的時間可替代性：月算力、Burst 與集中式工作

Paper 3 — 本篇
訂閱、API 與 Compute Wallet：AI 混合計價制度

Paper 4 — Next
閒置額度、轉讓與供應商回購：AI 使用權的可逆性

Paper 5
從 Rate Limiting 到 Demand Engineering：離峰折扣與 AI 需求響應

Paper 6
算力透明度作為控制介面：從黑箱限流到容量可觀測市場

Paper 7
算力透明度作為投資工具：AI 企業的新基本面

Paper 8
AI 市場的制度演化：從商品化到容量市場

Extra 1
Token 消耗症候群：到期額度如何反向塑造人的認知行為

Extra 2
跨產業制度移植：AI 產業其實不用每件事重新發明