# AI Chat成本評估 一般與高峰值比較表https://docs.google.com/spreadsheets/d/1k62M_ajCoP3yRi5F66QjnYBpN3i01fXjNLvMBfPtgx8/edit?usp=sharing Develop : https://cloud.google.com/products/calculator?hl=zh-TW&dl=CjhDaVF3TVRWbE5XWTVOeTFpTmpCakxUUm1abU10T0RkbE5TMWtOR0ZoWm1Kak0yWmxZbVVRQVE9PRAOGiRDN0U2M0VBMS1GQTRDLTQzMjEtQkJGRC0xRTBGQTQ4OEU4QzY MVP : https://cloud.google.com/products/calculator?hl=zh-TW&dl=CjhDaVF4WkRreVpHTmpNaTAwWmpBNExUUTRZekF0T1RjeFl5MHlPV1k0WmpneU1qWmpZbVVRQVE9PRAUGiQxMUI5OTk2RC00NDcyLTREODAtQkVERi03RjAyRDc4MTlFNTQ Basic : https://cloud.google.com/products/calculator?hl=zh-TW&dl=CjhDaVEzTURreE56ZzVOaTA1WlRsaExUUmtNamd0T0RjNFppMHdNbU16TnpRd1pXTXlNVFFRQVE9PRASGiQwMjVCOEJBNy0wNkY3LTRDRTAtOTg3OS01QzhGMzIxRTgxNkY Release market(再補上流量更改後，金額會暴增) : https://cloud.google.com/products/calculator?hl=zh-TW&dl=CjhDaVEzTURreE56ZzVOaTA1WlRsaExUUmtNamd0T0RjNFppMHdNbU16TnpRd1pXTXlNVFFRQVE9PRASGiQwMjVCOEJBNy0wNkY3LTRDRTAtOTg3OS01QzhGMzIxRTgxNkY --- # 估計使用者狀況 --- # Cloud Run - 每容器的處理能力由 Max Concurrency 和每個請求的處理時間（Request Duration）決定： - 每秒最大 TPS = Max Concurrency ÷ Request Duration。 - 請求耗時根據模組的處理複雜度分為： - 簡單模組：50ms~100ms - 複雜模組：200ms~500ms - 容器數量 = TPS ÷ 單容器最大 TPS。 ### a. Frontend - 功能 : 提供用戶端 UI，負責與後端 API 交互，處理 HTTP 請求（文字和語音輸入）。 - 評估點 - 流量類型：主要是 I/O 密集型，處理大量 HTTP 請求。 - 負載特性：流量主要來自用戶端輸入，請求處理時間短。 - 估計功能 - 語音傳輸 - 文字傳輸 - 註冊 - 登入 .... - 資源估計配置 - TPS 500 建議配置 | 參數 | 值 | |------|-----| | CPU | 1 vCPU | | Memory | 1G | | Min Instances | 1 | | Max Instances | 10 (應運突發流量) | - TPS 5000 建議配置 | 參數 | 值 | |------|-----| | CPU | 1 vCPU | | Memory | 2G | | Min Instances | 4 | | Max Instances | 50 (應運突發流量) | - 流量平均初估 - 每月請求量 : 3,888,000,000 ```markdown= 推算 請求量計算： - 每秒請求量：500 TPS - 每月請求量（30 天）： - 500 x 3600 X 24 X 30 = 1,296,000,000 容器附載 - 假設執行時:50ms - 容器處裡能力 - MaxConcurrency÷RequestDuration=80÷0.05=1600TPS 所需容器數： - 容器數量需求： - TPS÷每容器處理能力=500÷1600≈1容器 流量平均初估 - 每小時請求數量： - TPS500：500×3600=1,800,000請求/小時500×3600=1,800,000請求/小時 - TPS5000：5000×3600=18,000,000請求/小時5000×3600=18,000,000請求/小時 - 每日請求數量： - 低流量（12小時）：1,800,000×12=21,600,000 - 高峰期 (6小時):18,000,000x6=108,000,0000 - 每日請求量: - 21,600,000 + 108,000,0000 = 129,600,000請求/天 - 每月請求量 - 129,6000,000x30=3,888,000,000 ``` ### b.Audio Push - 功能 : 接收音頻文件，觸發後續的處理流程（例如 Audio Process Proxy）。 - 評估： - 流量類型：主要是音頻文件的接收和初步處理。 - 負載特性：受文件大小影響，處理時間可能稍長。 - 估計功能 - 接收用戶語音數據並推送至雲端儲存（Cloud Storage）。 - 觸發 Pub/Sub 事件，將音頻處理傳遞至 Audio Process Proxy。 - 支援多種格式的音頻上傳，並確保上傳穩定性。 - 資源估計配置 - TPS 500 建議配置 | 參數 | 值 | |------|-----| | CPU | 1 vCPU | | Memory | 2G | | Min Instances | 1 | | Max Instances | 10 (應運突發流量) | - TPS 5000 建議配置 | 參數 | 值 | |------|-----| | CPU | 2 vCPU | | Memory | 4G | | Min Instances | 4 | | Max Instances | 50 (應運突發流量) | - 流量平均初估 - 每月請求量 : 500,000,000 (Basic後好用會提高一倍) ### c.ChatBot API - 功能 : 文字存取 Firestore，提供偏好和上下文記錄。 - 評估點 - 中等運算負載，與資料庫交互頻繁。 - 估計功能 - 文字輸入處理，基本的文字解析和格式檢查，運算量低。 - 檢索並返回相關對話上下文（從 Firestore 讀取）。 - 整合 Knowledge API 返回知識圖譜中的適合回應。 - 支援多輪對話，維持會話狀態。 - 如果狀態存放在 Firestore 中，API 不需要額外負擔狀態管理邏輯。 - 資源估計配置 - TPS 500 建議配置 | 參數 | 值 | |------|-----| | CPU | 1 vCPU | | Memory | 1G | | Min Instances | 1 | | Max Instances | 10 (應運突發流量) | - TPS 5000 建議配置 | 參數 | 值 | |------|-----| | CPU | 2 vCPU | | Memory | 4G | | Min Instances | 4 | | Max Instances | 50 (應運突發流量) | - 流量平均初估 - 每月請求量 : 2,888,000,000 (Basic後好用會提高一倍) ### d.Knowledge API - 功能：提供知識查詢接口，存取 Firestore 進行數據檢索和上下文管理。 - 評估： - 流量類型：主要是 I/O 密集型操作，與 Firestore 交互為主。 - 負載特性：請求處理時間短。 - 估計功能 - 查詢知識庫（如 Medical Knowledge、Personality Vector 等）。 - 基於用戶查詢和情境進行向量化處理，匹配最相關的知識。 - 支援擴展性，可動態新增知識來源。 - 資源估計配置 - TPS 500 建議配置 | 參數 | 值 | |------|-----| | CPU | 1 vCPU | | Memory | 1G | | Min Instances | 1 | | Max Instances | 10 (應運突發流量) | - TPS 5000 建議配置 | 參數 | 值 | |------|-----| | CPU | 1 vCPU | | Memory | 4G | | Min Instances | 4 | | Max Instances | 50 (應運突發流量) | - 流量平均初估 - 每月請求量 : 1,000,000,000 (Basic後好用會提高一倍) ### e. Audio Process Proxy - 功能：將語音文件轉換為文字。語音處理：將音頻檔案傳遞至 Google Speech-to-Text，返回文字輸出。 - 評估： - 流量類型：CPU 密集型，需處理音頻文件。 - 負載特性：每次請求耗時較長。 - 資源估計配置 - TPS 500 建議配置 | 參數 | 值 | |------|-----| | CPU | 1 vCPU | | Memory | 2G | | Min Instances | 1 | | Max Instances | 10 (應運突發流量) | - TPS 5000 建議配置 | 參數 | 值 | |------|-----| | CPU | 2 vCPU | | Memory | 4G | | Min Instances | 4 | | Max Instances | 50 (應運突發流量) | - 流量平均初估 - 每月請求量 : 500,000,000 (Basic後好用會提高一倍) ### f.Vectorize Search - 功能：進行向量檢索，支持上下文匹配。 - 評估： - 流量類型：計算密集型，需進行高效檢索。 - 負載特性：多次數據交互，檢索算法運算需求高。 - 資源估計配置 (內部服務) 建議配置 | 參數 | 值 | |------|-----| | CPU | 2 vCPU | | Memory | 2G | | Min Instances | 1 | | Max Instances | 10 (應運突發流量) | - 流量平均初估 - 每月請求量 : 2,888,000,000+500,000,000 = 3,488,000,000 --- ### Cloud Storage (Voice) ==> 需做成本優化考量(因為讀寫都換算錢) - 功能 - 責存放語音文件以及其他相關靜態資料，例如音訊上傳文件和歷史記錄備份。 - 作為系統中音頻文件的中央儲存位置，支持 Audio Push 的後續處理。 - 評估音頻文件大小 - 假設平均每個音頻文件大小為 5 MB。 - 每月請求量為 1,888,000,000。 - 總文件大小需求： 1,888,000,000×5MB=9,440,000,000MB≈9,440TB - 基於上傳後文件存留時間 - 假設每個文件在 Cloud Storage 保留 1 天（每日滾動清除），每日存儲量為： 500TPS×60秒/分×60分/小時×24小時×5MB=216GB - 每日存量約 216 GB，按 30 天計算，總存量需求約為：216GB/day×30=6,480GB=6.48TB => 填寫：5,000 GB（5 TB） 作為基準存儲。 以下與Audio Push相依 Class A 操作 (寫入 (PUT/POST)) : 500,000,000 Class B 操作 讀取 (GET) : 500,000,000 --- ### Pub/Sub (Filter Trigger) ==> 需做成本優化考量(用音頻時間去算 很貴!!!) - 每日發布數據量 (Amount of published data daily) - 每月發布數據量：500萬次×5MB=25,000,000MB=25,000GB=25TB - 每日發布數據量 : 25TB/30≈0.83TB/天 Amount of published data daily: 850 GB/day - subscriptions : 1 - Topic retention days : 保存1天 - Retention storage (不考慮) ### Pub/Sub (Prompt Topic) 每月總操作次數為 4,000,000,000，總數據量為： 4,000,000,000 × 1KB = 4,000,000,000KB 換算為 GB： 4,000,000,000KB ÷ 1,024 = 3,906,250MB 3,906,250MB ÷ 1,024 = 3,814.7GB 因此，每月數據量約為 3,814.7GB，約為 3.81TB。 假設一個月有 30 天： 每日數據量 = 3,814.7GB ÷ 30 ≈ 127.16GB --- ### Speech-to-text - 評估 - 請求數量：每月 500 萬次音頻文件。 - 平均音頻長度：假設每條音頻約為 10s。 (先假設10秒鐘就好...太貴了) - 總處理時長 : 500萬次×10s=50萬分鐘/月 --- ### Cloud SQL (Vector) * 4 --- ### Generative AI 從其他Cloud Run 初估 假設一個月約4000萬Request 平均一天則為13333左右的Request 字元抓500~1000之間 (短對話) --- ### Cloud Scheduler https://cloud.google.com/scheduler/pricing?hl=zh-tw 感覺很便宜 # Cloud Load Balancing (須根據高低峰值比例去綜合計算成本) - Scope : <font color="#FF0000">Regional</font> - Region : <font color="#FF0000">Taiwan</font> - Number of forwarding rules : <font color="#FF0000">4</font> - Frontnd - Audio Push - ChatBot API - Knowledge API - Amount of inbound data : - TPS 500 : 125.4G (小時)， <font color="#FF0000">9.6 T (month)</font> - TPS 5000 : 1.2 TB (小時)，<font color="#FF0000"> 50T (month)</font> (打折估計值) - Amount of outbound data : - TPS 500 : 130G(小時)，<font color="#FF0000">10T (month)</font> - TPS 5000 : 1.28 TB(小時)，<font color="#FF0000">60T (month)</font> (打折估計值) ```=markdown 計算解釋： - Inbound Data = TPS × 單次請求大小 × 秒數 - Outbound Data = TPS × 單次回應大小 × 秒數 範例數據:假設： - 單次請求大小（文字）：1 KB - 單次回應大小（文字）：2 KB - 每秒的交易量為 TPS 500 或 TPS 5000 - 系統執行 1 小時（3600 秒） #TPS 500 的情境 - Inbound Data：500 TPS × 1 KB × 3600 秒 = 1,800,000 KB ≈ 1.8 GB - Outbound Data : 500 TPS × 2 KB × 3600 秒 = 3,600,000 KB ≈ 3.6 GB #TPS 5000 的情境 - Inbound Data：5000 TPS × 1 KB × 3600 秒 = 18,000,000 KB ≈ 18 GB - Outbound Data : 5000 TPS × 2 KB × 3600 秒 = 36,000,000 KB ≈ 36 GB 架構中除了文字還有聲音，需考慮音頻數據對流量的影響 - 假設音頻每秒請求比例為 20% - 音頻請求大小（Inbound）：167 KB - 音頻回應大小（Outbound）：167 KB - 文字請求與回應大小與前述一致 ##TPS 500 計算 - 音頻請求數量：500 TPS × 20% = 100 TPS - Inbound Data（音頻）：100 TPS × 167 KB × 3600 秒 = 60,120,000 KB ≈ 60 GB - Outbound Data（音頻） : 100 TPS × 167 KB × 3600 秒 = 60,120,000 KB ≈ 60 GB - 文字與音頻合計數據量： - Inbound：1.8 GB (文字) + 60 GB (音頻) ≈ 61.8 GB - Outbound：3.6 GB (文字) + 60 GB (音頻) ≈ 63.6 GB - 總計 = 125.4 GB 細部需按高峰和非高峰時段分開計算。 ``` # Cloud Armor (策略抓Defaul，只抓Request，(須根據高低峰值比例去綜合計算成本)) 假設每日流量為 TPS 5000 的峰值（高峰期 2.4 小時）和 TPS 500（非高峰期 21.6 小時）： 每日請求數： - 高峰期：5000 × 8640 秒 = 43,200,000 次 - 非高峰期：500 × 77760 秒 = 38,880,000 次 - 每日請求總數 = 43,200,000 + 38,880,000 = 82,080,000 次 每月請求數： 82,080,000 × 30 = <font color="#FF0000">2,462,400,000 次</font> (算2463) --- # 補充 (TPS 計算公式) > Concurrent Users ≈ TPS × 平均請求間隔（Think Time） - TPS：每秒處理的請求數（例如，TPS 100 或 TPS 3000）。 - Think Time：使用者在進行下一次操作前的平均等待時間，通常以秒為單位。 Example 假設每位使用者每 10 秒發送一次請求： - TPS 100 : 每秒處理 100 個請求，平均每位使用者每 10 秒發送 1 個請求。Concurrent Users ≈ 100 × 10 = 1000 人 - TPS 3000 : 每秒處理 3000 個請求，平均每位使用者每 10 秒發送 1 個請求。Concurrent Users ≈ 3000 × 10 = 30,000 人 須注意 1. 使用者行為：如果使用者的操作頻率更高（如每 2 秒發送 1 次請求），則同時使用者數會減少。 2. 系統容量：即使 TPS 足夠高，後端資源（如資料庫、快取）也需要相應擴容，否則可能導致瓶頸。 ![image](https://hackmd.io/_uploads/B1TYKKiGyx.png) ![image](https://hackmd.io/_uploads/rJG5tFjz1g.png) ![image](https://hackmd.io/_uploads/B1DcYtof1l.png) ![image](https://hackmd.io/_uploads/SJ6cFKjMkl.png) ![image](https://hackmd.io/_uploads/r1zoYtozJx.png) ![image](https://hackmd.io/_uploads/BkIsKKifkl.png) ![image](https://hackmd.io/_uploads/HyqoFKiG1e.png)