POV：月底帳單寄來，你盯著那條沒人叫過、但整個月都在計費的服務，想不起來它是哪天開的。
Day 16 的決策樹有一題我刻意跳過：錢。對我來說成本是選型的第一考量，我手上有一些 GCP credit，但 credit 會用完，而 agent 系統是那種一直在的東西，帳單是每個月來的。今天不寫任何價格（會變、會因地區不同，我不想寫一個明年就錯的數字；一律以官方定價頁為準），只談成本的結構：錢從哪裡來、哪種部署在哪種用法下會爆。
常駐（always-on）：你租一台機器或一個節點，不管有沒有人用都在計費。單 VM + compose、GKE Standard 的節點、自架 k3s 的 VM 都是這類。優點是可預測，每個月差不多；缺點是閒置也在燒。我那台 dev-box 就是這類，只是它是 Spot VM（折扣幅度以官方定價頁為準），代價是 Day 18 講的那些。
按需（pay-per-use）：Cloud Run 預設的 request-based billing 是這類：instance 只在處理 request、啟動、關閉的這幾段時間計費，算的是你配置給它的 CPU 與記憶體，不是實際用了多少；開了 min instances 的閒置 instance 另有一段閒置費率，細節以官方定價頁為準。優點是沒流量時花得很少；缺點是一直在的 agent 會把它變成常駐，而按需計價的常駐，通常不會比真正的常駐便宜。
混合：GKE Autopilot 一般 Pod 按 Pod 宣告的資源計費（選了特定機型或 GPU 的 Pod 則改按節點計費，以官方定價頁為準）、Cloud Run 開 min instances 或改成 instance-based billing（整個 instance 存活期間都計費）。你拿到一部分的彈性，付一部分的溢價。
Managed K8s 那一欄，GKE 的 Standard 與 Autopilot 計費結構不同，所以每格都分開寫。
| 面向 | 單 VM + compose | Serverless 容器（Cloud Run） | Managed K8s（GKE） |
|---|---|---|---|
| 基本費用 | 一台 VM 的月租（Spot 有折扣） | 縮到零時接近零 | control plane + Standard 按節點／Autopilot 一般 Pod 按宣告資源 |
| 一直在的 bot | 已包含在 VM 裡 | 要開 min instances，閒置時另有閒置費率 | Standard 算進節點裡／Autopilot 按那個 Pod 宣告的資源計 |
| 突發 build / render | 跟 bot 搶同一台機器（Day 04 實錄） | 自動 scale，按 request 處理時間計 | Standard 可排到獨立 node pool／Autopilot 多開 Pod 多付 |
| GPU | 要租整台 GPU VM | Cloud Run GPU，計費單位以官方定價頁為準（Day 25） | Standard 建 GPU node pool／Autopilot 選 GPU 的 Pod 改按節點計 |
| Egress（資料出雲） | 可能有 | 可能有 | 可能有，換到 K8s 本身不會讓這項消失 |
| 隱藏成本 | 你的時間（顧機器） | 架構要配合它的限制（Day 17） | 你的時間（顧 YAML 和網路） |
這張表裡沒有一種部署能無條件免費：免費額度和 credit 可能讓帳單暫時是零，但結構上錢還是花在機器、花在溢價，或花在你自己的時間。
陷阱 1：把一直在的東西放進按需計費。 Discord bot 要維持連線，Cloud Run 沒 request 時縮到零，它就得重連；開 min instances 之後，帳單看你選哪種計費：request-based 下閒置的 min instance 走閒置費率，改成 instance-based 則整個 instance 存活期間都計費。不管哪種，都不再是「沒人叫就免費」。Day 17 評估 liaostudio 時也撞到同一面牆：它有背景工作，只能用 instance-based（舊稱 CPU always allocated）這種計費，那份有 request 才計費的便宜就跟我無關了。Day 21 會細講這個矛盾。
陷阱 2：閒置的 dev 環境。 Day 04 提過：一個 dev 容器閒置 45 小時、吃 1.25 GiB，我沒發現。在單 VM 上它只是佔記憶體，因為 VM 的錢已經付了；換到 Autopilot 上，它按宣告的資源持續計費；換到 Cloud Run 上，只要你為了讓它一直在而開了 min instances 或 instance-based billing，它也是實實在在多出來的錢。K8s 預設不會幫你關掉沒人用的東西（除非你另外配 HPA、KEDA 這類縮零策略），restart: unless-stopped 也不會，你得自己有收工檢查的習慣。
陷阱 3：Egress。 不管哪種部署，資料從雲端出去都可能產生 egress 費用，收不收、收多少看目的地、走的路徑和方案，以 GCP 的 Network pricing 頁為準。AI app 特別容易踩：從另一朵雲拉模型（那邊算 egress）、把生成的影片或圖片送給使用者、跨 region 互相呼叫。這一項換部署方式不會讓它消失；能減少的是把流量留在同一個 region、同一朵雲的網路設計，不是 K8s 本身。
我有 GCP 的 redeem credit。它對決策的影響是：短期內 GCP 上的東西感覺免費，但 credit 有額度，也可能有期限。我的原則是：用 credit 的期間，架構要設計成 credit 用完那天可以無痛換到最便宜的選項，對我來說通常是 Spot VM + compose。所以我不會因為有 credit 就把一個小 bot 放進 GKE Standard；我會先在 Autopilot 或 Cloud Run 上試，確認它真的值得，再談要不要常駐。
明天把 Week 4 收成一張選型 checklist：團隊大小、流量型態、GPU、合規、credit，每題都要有一個誠實的答案。
成本不是看單價，是看結構：一直在的東西放常駐、被叫才動的放按需；放錯房間，最便宜的方案也會變成最貴的。
iThome鐵人賽
看影片追技術