AI COST GATE · 成本閘門
NT$ 9,580/月
試算示例導入 AI 最怕的不是做不出來,是月底帳單。
上面那個數字,是「每天 200 份文件、每份 8 頁、走高階模型、重試率 8%」算出來的。
下面每一格你都可以自己改——包含單價和匯率。
我們不會告訴你我們幫誰省了多少。我們會給你算式,讓你自己算你的。
- 每次呼叫歸戶到 使用者/組織/功能/模型
- 成本以呼叫當時的歷史定價入庫
- 重跑管線不重複計費
本頁所有金額皆為試算示例,非實際客戶帳單。單價與匯率為可編輯的示例值,實際計費請以你的供應商當期定價為準。
帳單上只有一個數字。實際上它由四件事組成。
大多數團隊在估成本時只算第一項。真正讓帳單超出預期的,通常是後面三項。
| 成本項 | 它是什麼 | 通常被低估的原因 | 在下方試算表對應的欄位 |
|---|---|---|---|
| ① 模型呼叫 | 送進去的 token × 輸入單價 + 吐出來的 token × 輸出單價 | 只算文字長度,忘記文件轉成影像後的 token 量遠高於純文字 | 每份頁數、每頁輸入 token、輸入/輸出單價 |
| ② 重試 | 解析失敗、逾時、格式不符而重跑的那些呼叫 | 被當成「偶爾發生」,實際上是一個穩定的百分比 | 重試率 |
| ③ 開發期試錯 | 上線前調 prompt、跑評測、比較模型的花費 | 一次性、發生在專案早期,通常不在任何一張營運表裡 | 開發期試錯(一次性) |
| ④ 失控迴圈 | 沒有上界的重試、遞迴切分、自動化流程互相觸發 | 它不是一個百分比,是一個意外。它的期望值很低,單次代價很高 | 不進試算,由往下的護欄清單處理 |
①②③ 是可以算的,所以我們把它做成試算表。
④ 算不出來——它不是成本問題,是設計問題。處理它的方式是上界,不是預估。
這也是為什麼往下的「算不出來的部分做成上界」是一整區,不是一則附錄。
把你的數字填進去。
以下為試算示例,非實際客戶帳單。
預設值是一組假想情境,不是任何客戶的實際用量。單價與匯率請自行填入你的供應商當期定價。
每天要送進 AI 處理的文件份數
平均值即可,不需要精確
文件轉影像送進模型時,token 量通常遠高於純文字。純文字管線可改為 800–1500
模型回傳的結構化結果長度
選定後自動帶入下方單價,選 自訂 則兩個單價欄位開放編輯
示例值。請以你的實際結匯匯率為準
解析失敗、逾時、格式不符而重跑的比例
本地規則刷完之後,還需要送模型的比例。設為 100 代表不做預篩
重複文件、重跑管線時已經算過的比例
⚠ 僅適用內部工具與 PoC,見下方階梯第三階。對外服務請維持 0
這些數字不會離開你的瀏覽器。
每月份數 docs = D × W
每月頁數 pages = D × P × W
輸入 token tokIn = pages × TPin
輸出 token tokOut = docs × TOout
基礎成本(USD) costBase = tokIn / 1_000_000 × Pin
+ tokOut / 1_000_000 × Pout
含重試(USD) costRetry = costBase × (1 + R/100)
三道省法後 costNet = costRetry × (F/100) × (1 − C/100) × (1 − S/100)
月費(NTD) monthly = costNet × X
首月(NTD) firstMo = monthly + Dev
每份成本(NTD) perDoc = monthly / docs| 每月頁數 | 35,200 |
|---|---|
| 每月輸入 token | 105,600,000 |
| 每月輸出 token | 6,600,000 |
| 未加護欄的月費 | NT$ 9,580 |
| 三道省法後的月費 | NT$ 1,916 |
| 差額= 上面兩列相減 | NT$ 7,664 |
| 每份文件成本 | NT$ 0.44 |
| 首月(含一次性) | NT$ 1,916 |
差額是上面兩列的算術差,不是我們的實測結果。改動任何一個輸入,這三個數字都會跟著變。
docs = 200 × 22 = 4,400 份
pages = 200 × 8 × 22 = 35,200 頁
tokIn = 35,200 × 3,000 = 105,600,000 token
tokOut = 4,400 × 1,500 = 6,600,000 token
costBase = 105.6 × 2.00 + 6.6 × 10.00
= 211.20 + 66.00 = 277.20 USD
costRetry = 277.20 × 1.08 = 299.376 USD
costNet = 299.376 × 0.25 × 0.80 × 1.00 = 59.8752 USD
未加護欄 = 299.376 × 32 = NT$ 9,580.03 → 顯示 NT$ 9,580
三道之後 = 59.8752 × 32 = NT$ 1,916.01 → 顯示 NT$ 1,916
差額 = 9,580.03 − 1,916.01 = NT$ 7,664.03 → 顯示 NT$ 7,664
每份成本 = 1,916.01 / 4,400 = NT$ 0.44每一步都是四則運算,沒有隱藏係數。如果你算出來跟我們不一樣,那是我們的錯,請告訴我們。
省錢不是三個方案,是同一條算式代三次。
上面那條算式的最後三個乘數是 F、(1−C)、(1−S)。所謂「三種省法」,就是把這三個數字從 1 往下調。
這一區不是三張並排的方案卡——它是一條往下走的階梯,每一階的起點是上一階算完的餘額。
每一階都附代入後的金額,你可以自己驗算。
起點|三個係數全部維持 1(=完全不做任何預篩、快取、額度替代) costRetry × F × (1−C) × (1−S) × X 299.376 × 1.00 × 1.00 × 1.00 × 32 = NT$ 9,580.03 → NT$ 9,580/月
第一階|F:規則層通過率,100% → 25%
這一階動的是算式裡的哪一個符號:
299.376 × [ F ] × (1−C) × (1−S) × 32
代入:
F = 1.00 → 0.25 299.376 × 0.25 = 74.844 USD 74.844 × 32 = NT$ 2,395.01 → NT$ 2,395/月 這一階減少 = 9,580.03 − 2,395.01 = NT$ 7,185.02 → NT$ 7,185
怎麼把 F 壓到 0.25 的:
- 本地規則層先篩:關鍵詞三段加權(加分/輔助/扣分)+ 模糊比對。它可以被讀、被改、被單元測試——你能指著某一行問「為什麼這筆被刷掉」
- 送模型的候選有全域池上限,且每個查詢角度有保底 quota,避免某一類把候選池吃光
- 批次合併:多筆共用一個 prompt,而不是一筆一次呼叫,省掉每次呼叫的固定開銷
- 正文抽取 + token 預算截斷(去除樣式標籤、截斷至上界),壓的是 TPin 而不是 F,但兩者相乘
這一階的代價:
規則層刷掉的東西,模型再也看不到。被誤刷的那些,你不會知道它們存在——這是唯一一種「省下來的錢」與「看不到的損失」無法在同一張表上對帳的省法。
規則也需要隨資料變化持續調整,那是人力,不是一次性設定。
現況:四項全部已實作,有可指認的程式碼。
第二階|C:快取命中率,0% → 20%
這一階的起點是 NT$ 2,395,不是 NT$ 9,580。
299.376 × 0.25 × [ 1−C ] × (1−S) × 32
代入:
C = 0.00 → 0.20,故 (1−C) = 0.80 74.844 × 0.80 = 59.8752 USD 59.8752 × 32 = NT$ 1,916.01 → NT$ 1,916/月 這一階再減少 = 2,395.01 − 1,916.01 = NT$ 479.00 → NT$ 479
⚠️ 注意這兩階的落差:第一階省下 NT$ 7,185,第二階只省下 NT$ 479。
不是因為快取沒用,是因為它作用在第一階刷剩下的那 25% 上。階梯的順序決定了每一階看起來值多少錢——這也是為什麼這一區必須是階梯而不是三張並列的卡片:並列會讓人以為三個數字可以相加。
怎麼把 C 拉到 0.20 的:
- 只處理新項目:以「尚未處理」為條件過濾,重跑管線不重評舊資料
- 內容雜湊去重:同一份內容不論來源,只處理一次
- 樣本壓縮:送進模型的素材只保留必要欄位與長度上界
- 每輪處理筆數硬上限,超出的延到下一輪並發出覆蓋率不足的軟警告
這一階的代價:
快取命中代表用的是舊結果。來源更新了但雜湊沒變,你拿到的是過期答案。
而且快取本身要存、要清、要有失效策略——資料量小的時候,這些維運成本會高過省下的模型費用。
現況:四項全部已實作。
第三階|S:訂閱額度覆蓋率,預設 0%(所以它對上面那個數字沒有任何貢獻)
適用範圍:內部工具與 PoC 階段。
這個做法依賴使用者本機安裝的命令列工具與個人訂閱帳號。
它不是多租戶 SaaS 可用的架構,也可能牴觸供應商的服務條款。
若你要做的是對外服務,請把試算欄位 訂閱額度覆蓋率 維持在 0。
⚠ 僅適用內部工具與 PoC,見下方階梯第三階。對外服務請維持 0
299.376 × 0.25 × 0.80 × [ 1−S ] × 32
S = 0.00(預設)→ (1−S) = 1.00 59.8752 × 1.00 × 32 = NT$ 1,916.01 → 與第二階相同 這一階減少 = NT$ 0
這是刻意的。這一頁的預設試算不啟用第三階,因為預設情境是對外服務。
如果你的場景是內部工具,把 S 調到 60% 會長這樣:
S = 0.60 → (1−S) = 0.40 59.8752 × 0.40 = 23.95008 USD 23.95008 × 32 = NT$ 766.40 → NT$ 766/月 這一階減少 = 1,916.01 − 766.40 = NT$ 1,149.60 → NT$ 1,150
三段降級圖:
訂閱額度執行 ──不可用──▶ 按量 API ──不可用──▶ 離線規則模板 (零 API 費) (正常計價) (不呼叫模型)
- 優先走訂閱制命令列工具執行(結構化輸出、唯讀沙箱、prompt 由標準輸入灌入)
- 不可用時自動降級到按量 API。降級後成本回到 API 計價,所以預算必須以 API 價編列,不能以訂閱價編列
- 再不可用時降級到離線規則模板,完全不呼叫模型,但產出品質明顯下降
- 可用性探測結果快取,避免短時間內重複探測
這一階的代價:
可用性(綁本機環境與個人帳號,環境變了就停)、供應商鎖定與條款風險、以及額度上限——訂閱有配額,用完就是用完,且通常不會提前警告。
現況:已實作,但屬本機工具(零 commit、無部署形態)。
我們把這一階寫在頁面上,是因為它真的存在而且真的有效。
我們同時把它的適用範圍寫在同一個畫面裡,是因為用錯地方會比省下的錢貴得多。
一次只動一個,看斜率。
上面是三階累積的結果。這裡是反過來的問題:假設其他兩個不動,某一個係數改變時,月費怎麼變?
這決定你該把工程時間花在哪一階。
F:線性。月費 ∝ F F = 25% → NT$ 1,916 F = 50% → NT$ 3,832 F 減半,月費就減半 (299.376 × 0.50 × 0.80 × 32 = 3,832.01) C:遞減。月費 ∝ (1−C) C = 20% → NT$ 1,916 C = 40% → NT$ 1,437 命中率翻倍,月費只降 25% (299.376 × 0.25 × 0.60 × 32 = 1,437.00;1,437.00 / 1,916.01 = 0.75) S:線性但受限。月費 ∝ (1−S),且 S 只在內部工具場景可用 S = 0% → NT$ 1,916 S = 60% → NT$ 766
F 是斜率最陡的那一個,而且它是唯一一個「越用越省」的係數。
C 有天花板——命中率不可能到 100%,而且越接近 100% 每一個百分點越難拿。
S 對大部分讀者的正確值是 0。
所以如果只有一週工程時間,把它花在規則層。這句話不是經驗談,是上面三行算術的結論。
以上六個金額全部由試算表的同一條算式與同一組預設值代入,改動任何輸入都會跟著變。這不是實測結果。
每一種省法都在跟某個東西交換。這裡是清單。
如果一個做法只有好處沒有代價,那通常是還沒被用到出問題。以下是階梯三階各自的代價,以及在什麼情況下不要用。
| 階 | 你交換掉的東西 | 什麼情況下不要用 |
|---|---|---|
| 第一階 F | 召回率。規則層刷掉的東西,模型再也看不到——被誤刷的那些,你不會知道它們存在 | 漏掉一筆的代價極高時(法遵通知、安全告警、醫療相關)。這類場景寧可全部送模型 |
| 第一階 F | 維護成本。規則需要隨著資料變化調整,這是持續性的人力,不是一次性設定 | 沒有人負責維護規則時 |
| 第三階 S | 可用性。它依賴本機環境與個人帳號,環境變了就停 | 對外服務、多租戶 SaaS、任何有 SLA 承諾的場景 |
| 第三階 S | 供應商鎖定與條款風險。做法綁特定供應商的命令列工具,且需自行確認條款允許此用途 | 無法承擔條款風險時。這一條請與法務確認過再做決定 |
| 第三階 S | 額度上限。訂閱有配額,用完就是用完,且通常不會提前警告 | 用量會突然暴增的場景 |
| 第二階 C | 新鮮度。快取命中代表用的是舊結果;來源更新了但雜湊沒變,你拿到的是過期答案 | 同一份輸入的正確答案會隨時間改變時(價格、庫存、法規) |
| 第二階 C | 儲存成本與複雜度。快取本身要存、要清、要有失效策略 | 資料量小到快取的維運成本高過省下的模型費用時 |
| 三階一起走到底 | 延遲。多一層規則、多一次快取查詢、降級探測都要時間 | 需要即時回應的互動式場景(使用者在畫面前等) |
我們不會說這三階「沒有副作用」。
我們能說的是:每一個副作用都寫在這裡,而且都可以在導入前先量一次。
如果你的場景剛好落在右邊那一欄,那答案是不要省——這一頁的目的不是說服你省錢,是讓你算得出來。
算得出來的部分做成試算表。算不出來的部分做成上界。
失控迴圈不是一個百分比。它的發生機率很低、單次代價很高,而且通常在半夜發生。
處理它的方式不是預估,是讓它撞到一面牆就停。
| 護欄 | 做什麼 | 現況 |
|---|---|---|
| 每輪筆數硬上限 | 單次執行處理的筆數有寫死的上界,超出的延到下一輪 | 已實作:已實作(有可指認的程式碼) |
| 覆蓋率不足軟警告 | 因上限而未處理完時發出警告,而不是安靜地少做一半 | 已實作:已實作 |
| 批次容錯 | 單一批次解析失敗重試一次後跳過該批,不炸整條管線也不無限重試 | 已實作:已實作 |
| 用量歸戶 | 每次呼叫記錄 使用者/組織/功能/模型/輸入 token/輸出 token/快取 token/成本 | 已實作:已實作(生產環境內) |
| 歷史定價入庫 | 成本以呼叫當時的定價換算後入庫,模型改價不影響已入庫的歷史帳 | 已實作:已實作 |
| 每日用量彙總 | 排程把明細滾成每日彙總,供查詢與趨勢觀察 | 已實作:已實作 |
| 月度預算上限與自動停機 | 達到預算上限時自動停止呼叫,而非僅發出通知 | 尚未實作:尚未實作——目前有的是每輪筆數上限,不是月度金額上限 |
| 超額即時告警(通知管道) | 接近上限時主動通知負責人 | 尚未實作:尚未實作 |
| 觀測台介面 | 用量與成本的查詢介面 | 尚未實作:僅有完整規格與架構決策紀錄,介面尚未建置 |
上表下半部三項標示為尚未實作——我們選擇把它寫出來,而不是用「支援預算控管」一句話帶過。
目前實際存在的上界是每輪處理筆數,它擋得住「一次跑太多」,擋不住「一個月跑太多次」。
如果月度金額上限是你的必要條件,請在第一次通話就說,這會是導入範圍的一部分。
把你的用量講一次,我們一起把這張表填完。
30 分鐘。你講一次要處理什麼、量有多大、哪一段最怕出錯。
我們會用同一張試算表,填上你的數字,然後告訴你哪一種省法適合你、哪一種不要用。
本頁所有金額為試算示例,非實際客戶帳單。AMAX 不提供任何成本節省幅度的承諾。