企業剛導入 AI 客服時，通常會選擇呼叫外部大型語言模型 API：不用購買 GPU，也不用自行維護模型，只要依照使用量付費，就能快速上線。
但當 AI 開始接手更多客服工作，問題也會跟著出現：對話量增加、Token 用量上升、每月帳單變得難以預測。這時不少企業會開始思考：
「繼續使用 API，長期真的划算嗎？是不是應該把模型架在自己的伺服器裡？」
答案不是看到某個 Token 數字就立即自建，而是先釐清：成本到底花在哪裡、服務需要什麼等級的回答品質，以及企業是否有能力承擔自建後的維運工作。
對多數中小企業來說，自建模型通常不是第一個降本選項。更實際的順序，是先優化 FAQ、提示內容、知識庫檢索、模型分流與真人接手條件，再根據實際用量判斷是否需要更複雜的架構。
為什麼 AI Agent 比一般聊天更耗 Token？
一般聊天可能只包含一次提問與一次回答，但 AI 客服 Agent 為了完成一項任務，背後可能會執行多個步驟：
- 讀取系統提示與客服規則
- 保留前幾輪對話內容
- 從 FAQ 或知識庫搜尋相關資訊
- 判斷客戶意圖與問題類型
- 呼叫訂單、會員或其他工具
- 檢查答案後，再產生最終回覆
對客戶來說只看到一則回答，系統背後卻可能已經呼叫模型數次。因此，Agent 的成本不能只用「一則訊息多少錢」理解，而應該計算完成一項客服任務總共使用多少輸入與輸出 Token。
每月 5,000 萬 Token，就是自建模型的分界嗎？
INFINITIX 在《AI Agent 規模化部署與企業自建 AI 基礎設施》白皮書中，提出一組值得注意的試算：假設一項輕量 AI Agent 任務使用約 5,000 Token，每月 5,000 萬 Token 相當於每月約 10,000 項任務，也就是每天約 333 項任務。白皮書將這個使用量視為評估外部 API 與自建推論基礎設施總持有成本的重要參考點。
這個數字可以用來提醒企業開始計算成本，但不能當成所有公司的固定分界。因為實際成本還會受到下列因素影響：
- 使用的模型與計價方式
- 輸入、輸出及快取 Token 的比例
- 每次送進模型的對話歷史與知識庫內容
- 同一項任務需要呼叫模型幾次
- 自建模型所需的 GPU、電力、備援與監控成本
- 模型更新、資安管理及工程人員投入
- 自建模型能否達到企業需要的回答品質
換句話說，5,000 萬 Token 比較像「該開始正式評估」的提醒，而不是「達到後就一定要自建」的答案。這是特定白皮書中的估算情境，不代表所有模型、所有任務或所有企業都適用。
外部 API、自建模型與混合架構怎麼選？
| 方案 | 主要優點 | 主要限制 | 較適合的情況 |
|---|---|---|---|
| 外部 API | 上線快、前期投入低、模型更新快 | 成本隨用量增加，受供應商價格與服務限制影響 | 使用量尚未穩定、團隊規模較小、需要快速驗證 |
| 自建模型 | 資料與環境控制程度高，高使用率下可能降低單位成本 | 前期成本高，需要持續維運、監控與更新 | 用量大且穩定、資料高度敏感、已有 AI 基礎設施團隊 |
| 混合架構 | 可依問題難度與資料敏感度分流，兼顧成本與能力 | 系統設計與管理比單一方案複雜 | 客服量逐漸成長，希望保留彈性並控制風險 |
中小企業更應該先做的五件事
對多數中小企業而言，在購買 GPU 或自建模型之前，通常還有更直接、風險更低的降本方法。
一、縮短不必要的對話歷史
如果每次回答都把完整聊天紀錄重新送進模型，即使客戶只問一句簡單問題，輸入 Token 仍會隨對話持續增加。系統可以只保留必要內容，或先把較早的對話整理成摘要。
二、不要把整份知識庫都交給模型
知識庫的目的不是把所有文件塞進提示，而是先找出最相關的少量段落，再提供給模型回答。搜尋內容越精準，通常越能同時改善成本、速度與回答品質。
三、依照問題難度選擇模型
營業時間、運費、退換貨規則等固定問題，不一定需要每次都使用能力最強、成本最高的模型。企業可以讓簡單問題走規則、FAQ 或較輕量的模型，複雜問題再交給能力更高的模型處理。
四、設定明確的真人接手條件
AI 如果無法確認答案，反覆嘗試不只增加 Token，也可能讓客戶更加不滿。遇到客訴、退款、特殊報價，或連續無法解決的問題時，系統應該及時交由真人處理。
五、追蹤「解決一項問題」的成本
只看總 Token 或每月帳單仍不夠。更有意義的指標包括：每項客服問題的平均成本、AI 解決率、真人接手率、平均處理時間，以及客戶是否需要重複詢問。若回答品質不佳導致重試，表面上便宜的模型反而可能產生更高總成本。
AWS 的生成式 AI 成本建議也指出，提示長度、回覆長度與整體資源使用都應納入管理；Google Cloud 則提供不同模型部署與消費方式，讓企業可依需求在 API、託管模型與自部署模型之間選擇。這表示企業在「API 或自建」之外，其實還有很大的優化空間。
除了成本，還要考慮客戶資料安全
客服對話可能包含姓名、電話、地址、訂單內容，甚至付款與健康相關資訊。OWASP 將敏感資訊洩露列為大型語言模型應用的重要風險之一。因此，不論使用外部 API 或自建模型，都不能只問「資料有沒有送到外部」，還要確認：
- 哪些資料真的需要提供給模型
- 傳送前是否能遮蔽個人或敏感資訊
- 對話紀錄會保留多久、誰可以存取
- 日誌中是否意外儲存完整個資
- 供應商的資料處理條款是否符合企業需求
自建模型可以提高控制程度，但不代表自動等於安全。權限設定、伺服器漏洞、備份、日誌與內部存取管理，仍然需要企業自行負責。
企業什麼時候才該認真評估自建？
如果符合以下多項條件，就可以進一步進行自建或混合架構的可行性評估：
- AI 使用量已連續數月維持在高檔，而且容易預測
- 模型費用已成為明顯且持續的營運支出
- 具有不能離開特定環境的敏感資料
- 需要固定延遲、內網運作或高度客製化
- 企業已有維護 GPU、容器、監控及模型服務的人員
- 經過實際測試，開源模型的回答品質足以支援業務
如果客服量仍在起步階段、需求經常改變，或還不知道客戶最常詢問什麼，外部 API 通常仍是比較靈活的選擇。
太早自建，可能只是把容易理解的 Token 帳單，換成更難看見的硬體、人力與維運成本。
Teasweb 的觀點：先把客服流程跑順，再決定模型架在哪裡
AI 客服真正的價值，不是使用多少 Token，也不是擁有多少張 GPU，而是能否更快解決客戶問題，並在需要時順利交由真人接手。
對多數中小企業來說，合理的導入順序應該是：先整理常見問題與客服流程，再用 API 快速驗證；接著追蹤使用量、回答品質與真人接手狀況；最後才根據實際資料，決定是否採用較輕量模型、混合架構或自建基礎設施。
與其先問「我們要不要自建 AI」，不如先問：「目前有哪些客服問題值得交給 AI？每解決一項問題，能替團隊省下多少時間？」當這兩個答案足夠清楚，技術選擇通常也會跟著清楚。
如果你正在評估官網、LINE 官方帳號與 FAQ 的 AI 客服整合，Teasweb 可以協助你先整理實際客服流程，找出適合自動回覆與真人接手的範圍，再選擇符合現階段成本與需求的導入方式。
不確定 AI 客服成本該怎麼評估？
Teasweb 可以先協助你盤點客服流程、FAQ、知識庫與真人接手條件，找出哪些問題適合先自動化，哪些問題應該保留人工處理。
你不需要一開始就決定要不要自建模型。更實際的做法，是先從常見問題與小範圍測試開始，確認 AI 回答品質、真人接手率與實際節省的客服時間。