Try   HackMD

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
































推算

請求量計算：
- 每秒請求量：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後好用會提高一倍)

  • 功能：進行向量檢索，支持上下文匹配。

  • 評估：

    • 流量類型：計算密集型，需進行高效檢索。
    • 負載特性：多次數據交互，檢索算法運算需求高。

  • 資源估計配置 (內部服務)

    建議配置

    參數 值
    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 : Regional
  • Region : Taiwan
  • Number of forwarding rules : 4
    • Frontnd
    • Audio Push
    • ChatBot API
    • Knowledge API
  • Amount of inbound data :
    • TPS 500 : 125.4G (小時)， 9.6 T (month)
    • TPS 5000 : 1.2 TB (小時)， 50T (month) (打折估計值)
  • Amount of outbound data :
    • TPS 500 : 130G(小時)，10T (month)
    • TPS 5000 : 1.28 TB(小時)，60T (month) (打折估計值)
計算解釋：
    - 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 = 2,462,400,000 次 (算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
image
image
image
image
image
image

Last changed by 
 
YU-SHIH-PENG
嗨~我叫阿鵬，已從事系統領域多年，底層驅動至上應用層架構設計都具有相當的實作經驗。個性喜好學習，因此成立已持續兩年的研討讀書會，除了技術研討外，也對於不同其餘的軟實力知識有相當興趣。喜歡具有工作彈性空間且具研發挑戰性質的事物，更喜愛熱於討論與交流的團隊。 Git: https://github.com/spyua
0
159

Read more

教育訓練-專案程式上手

✅ Day 1：Quarkus 基礎

Mar 10, 2025
Open Source 開發流程簡易整理

1.尋找適合的 Open Source 專案

Feb 8, 2025
雲端人員維護系統

目標熟悉雲端環境：使用 Google Cloud，熟悉 Cloud Run、Cloud SQL、Cloud Storage、Pub/Sub 等元件。強化後端開發能力：使用 Java Spring Boot，學習 RESTful API 設計與實作。掌握檔案處理技術：包括 照片上傳、壓縮、格式驗證，學習如何運用雲端服務處理文件。理解非同步處理概念：使用 Pub/Sub 進行非同步任務處理，如圖片壓縮等。

Feb 3, 2025
Cloud Run vs App Engine 喚醒時間差異

在雲端運算技術快速演進的時代，企業面臨著如何有效運用雲端資源的重要課題。Google Cloud Platform (GCP) 作為全球主要的雲端服務供應商之一，提供了多樣化的無伺服器運算服務（Serverless Computing Services）選項。其中，Cloud Run 和 App Engine 是兩個被廣泛採用的服務，各自具有不同的特性和應用場景。

Nov 1, 2024
Read more from YU-SHIH-PENG
Published on HackMD