遊戲開發者如何預估長篇 AI 對話的成本
若要預估遊戲中長篇 AI 對話的成本，請測量整個玩家對話階段（Session）所使用的 Token 數量，將未快取輸入、快取輸入和輸出分開計算，然後套用所選模型的當前費率。最後，根據玩家在各種長度下實際進行的階段數量對結果進行加權。簡短的提示詞（Prompt）測試或單一「平均」對話階段，可能會遺漏後續輪次中重複發送的歷史記錄、快取未命中（Cache Misses）以及異常漫長的遊玩階段。
1. 定義您要預估的單位
首先選擇一個明確的單位：例如，每個對話階段、每個活躍玩家日或每 1,000 個對話階段的模型推論成本。對於單一階段的預估，請定義該階段何時開始與結束。一個實用的規則可能是「從第一次對話請求開始，直到 30 分鐘內沒有任何請求為止」，但該逾時設定是一種衡量選擇，而非通用標準。請記錄下來，以便其他開發者能夠重現這項預估。
計算模型請求次數，而不僅僅是玩家的訊息數。單次互動可能會觸發多次呼叫——例如，一次回覆之後接著進行獨立的工具處理呼叫——而重試機制可能會增加更多次數。如果遊戲使用了語音、圖像輸入、檢索或工具，請將這些項目保留在獨立的成本欄位中，並記錄其關聯的模型 Token。除了標準文字 Token 費用外，服務商的定價可能還包含工具費或特定模態的費率；例如，OpenAI 列出了獨立的工具費用，並說明用於內建工具的模型 Token 會按所選模型的費率計費（OpenAI API pricing）。
2. 測量每次請求的實際 Token 數
對於每次呼叫，記錄服務商、模型識別碼、時間戳記、階段識別碼、請求目的、輸入 Token 數、輸出 Token 數，以及任何回報的快取 Token 或推理（Reasoning）Token 明細。擷取重試、錯誤、工具呼叫以及呼叫是否完成。除非基於具體正當的產品目的而需要，否則請避免儲存對話內容；Token 總數和維運元數據通常已足夠用於成本預估。
使用已完成呼叫中由服務商回報的用量作為主要測量依據。發送前的計數對於測試提示詞構建很有幫助，但可能與最終的計費欄位不一致。OpenAI 的文件指出，回報的輸出包含可見文字之外的 Token，例如某些格式設定和工具結構 Token，並建議不要僅憑玩家看到的內容來預估輸出（OpenAI token-counting guide）。Google 的 Gemini 文件同樣在用量元數據中區分了提示詞、快取內容、候選輸出和思考（Thinking）Token 數量（Gemini token guide）。
建立一個具有代表性的樣本，其中包含新玩家、回流玩家、長短對話，以及正式環境的提示詞和工具配置。將「對話階段」作為抽樣單位：一個 40 輪的對話應作為一個具有累計成本的觀測值，而不是被視為 40 個獨立的玩家階段。在原型製作階段，一組固定的腳本化對話有助於比較提示詞的變更；遊戲上線後，則應以觀察到的實際對話階段來推動預測。
3. 考量歷史記錄增長與上下文重用
在許多對話系統中，每個請求都包含當前的使用者輪次以及部分或全部的對話歷史。如果反覆重新發送歷史記錄，即使每則玩家訊息都很簡短，輸入 Token 也會隨著每個輪次而增長。請測量發送給模型的實際請求內容（Payload）；除非實作上每次確實發送相同數量，否則請勿將單輪提示詞大小乘以輪次數量。
快取機制會改變適用於符合條件的重複輸入的費率；這並不意味著整個對話變得免費，也不代表持續存在的階段就保證能命中快取。OpenAI 將提示詞快取描述為對未變更提示詞前綴的重用，並指出新輸入仍需處理。其快取診斷功能有助於測量快取讀取和未命中次數（OpenAI prompt-caching guide）。Anthropic 同樣區分了快取寫入與快取讀取，並發布了各自的費率和快取有效期限（Anthropic pricing and prompt caching）。
在您的遙測數據中，當服務商有回報時，請分開記錄未快取輸入 Token、快取輸入 Token 和快取寫入 Token。記錄快取命中次數除以符合條件的請求次數，以及實際計為快取的輸入 Token 比例。這些指標回答了不同的問題：如果重複的前綴很小，即使跨請求的命中率很高，快取 Token 佔總 Token 的比例可能依然不大。快取資格、最小大小、過期時間、提示詞前綴穩定性和模型支援均因服務商而異；請僅計算由用量數據證實的節省金額。
4. 以透明的計算方式套用費率
對於按每百萬 Token 計價的模型，請依以下方式計算每個階段：
階段成本 = (未快取輸入 × 輸入費率 + 快取輸入 × 快取輸入費率 + 快取寫入 × 快取寫入費率 + 輸出 × 輸出費率) ÷ 1,000,000 + 其他適用費用
請使用已部署配置中確切模型、端點、模態、區域和服務層級的費率。在編列預算前，請立即至服務商的定價頁面獨立核對；費率和模型目錄隨時可能變動。若快取會針對儲存的 Token 和時長計費，請納入儲存費用。例如，Gemini 公布的定價列出了付費使用的 Token 類別以及特定上下文快取配置的每小時儲存定價，而其計費文件將輸入、輸出、快取 Token 和快取儲存時長列為計費要素（Gemini pricing；Gemini billing）。
透過實際範例計算可使各項假設清晰可見。純粹為了說明，假設分配給某個對話階段的測量呼叫包含 18,000 個未快取輸入 Token、12,000 個快取輸入 Token 和 6,000 個輸出 Token。套用公布至 2026 年 12 月 31 日適用的 Gemini 3.8 Flash 付費層級費率——每百萬輸入 Token $0.75 美元、每百萬快取 Token $0.075 美元、每百萬輸出 Token $3.75 美元——得出 $0.0135 + $0.0009 + $0.0225，即在計入任何適用的快取儲存或其他費用前為 $0.0369 美元。此範例假設所列的快取 Token 均依快取費率計費，且不包含測量總量之外的任何初始快取建立成本。這些費率具有時效性，在預估較後期的期間時應再次確認（Gemini pricing）。
5. 使用對話階段長度的分佈情況
請勿隨意挑選一個「典型」對話階段乘以總玩家數就稱之為預測。請依輪次計數或其他實用的長度區間對觀察到的階段進行分組，計算每個區間內的平均成本，然後依各區間佔所有階段的比例進行加權。在記錄平均值的同時，也請保留中位數和較高百分位數：平均值乘以階段總量可用於預估總用量，而百分位數則有助於說明較短或異常長的階段可能會產生多少成本。
例如，如果樣本包含許多簡短階段和少數極長階段，請同時呈報各區間的階段比例以及各區間的成本。如此一來，10,000 個階段的預測值即可計算為各區間的「階段數 × 區間平均成本」之總和，而不是假設每個階段都類似於整體中位數。如果用量在不同遊戲模式、語言、平台或新舊玩家之間存在重大差異，請在合併前先對這些群體進行分層。進行分群是一種分析決策；請說明為何各個細分群體可能會改變 Token 用量或請求行為。
6. 記錄不確定性並持續更新預估
請保留一份簡明的假設記錄，註明取樣日期、階段邊界規則、模型與端點、提示詞版本、觀察到的階段數量、快取命中定義、定價頁面檢索日期、包含的費用以及排除的項目。透過改變可觀察的輸入參數（例如對話長度組合、輸出大小或測得的快取命中比例）來展示樂觀、基準與悲觀的情境，而不是盲目加入毫無根據的緩衝空間。任何超出觀察階段的推測行為，都應視為明確設定的情境，而非既成的事實。
預估的完整性完全取決於其檢測工具和計費類別。它可能會遺漏未經過記錄器的呼叫、重試、API 未公開的快取 Token 類別、模型端的推理 Token、儲存時長、媒體處理或超出 Token 費率的服務商費用。在可行情況下，請將抽樣用量與服務商的計費報告進行對帳，調查重大差距，並在變更模型、提示詞、快取行為或面向玩家的功能後重新進行計算。最終產出的是一份針對觀察工作負載且有據可查的維運成本預估，而非未來對話或帳單一定相符的保證。