POV：你在 GCP console 按下「建立叢集」，第一個畫面就問你 Autopilot 還是 Standard，而你只是想把一隻 bot 跑起來。
昨天講 Cloud Run 適合誰，今天看另一邊：如果你決定自己的 agent 需要真正的 K8s，GKE 的第一個問題就是 Autopilot 還是 Standard。網路上的比較文很多，但大多是平台工程師視角。我想從 AI 工程師的角度切：不談 node pool 的參數，只談你會遇到的三個決定。先講一句話版本：
Standard：GCP 幫你維護 control plane，但節點（VM）歸你管：規格、數量、什麼時候加減，都是你決定，帳單也照節點算。
Autopilot：GCP 連節點都代管，你只宣告「我的 Pod 需要多少 CPU 和記憶體」，它負責找地方放。計費上，一般的 Pod 按 Pod 宣告的資源算；有選特定機型或 GPU 的 Pod 則改按節點算，細節以官方定價頁為準。
白話翻譯：Standard 是「我租幾台機器，自己塞東西」；Autopilot 是「我開出資源需求，機器你看著辦」。
這是最根本的分歧。回想 Day 04 那台 32 GB 開發機被壓到 swap 見底的經驗：多個 workload 擠在同一台機器上時，誰吃了記憶體、誰該先被犧牲，全靠我手動判斷。K8s 的 requests / limits（Day 09）就是把這條界線寫下來。
在 Standard 裡，寫下界線之後還有下一層是你的：節點要開多大、一台塞幾個 Pod、塞滿了要不要自動加節點。在 Autopilot 裡，你把每個 Pod 的 requests 設對，底層機器的問題交給平台。
我的判斷很直接：一個人或小團隊，主要工作是寫 agent 不是維運叢集，Autopilot 省下的心智負擔，多半大過它多收的錢。 光是想 agent 邏輯就夠耗腦力了。
Autopilot 的便利是有代價的：它對節點層的存取有限制，例如特權容器、直接碰節點檔案系統、某些 daemon 型 workload，會被擋或要求走它規定的方式。完整清單以官方的 Autopilot security 文件為準，我沒有全部踩過。
AI workload 最常遇到的特殊需求是 GPU。兩種模式都能用，但拿法不同：Standard 是自己建一個帶 GPU 的 node pool；Autopilot 是在 Pod 規格裡宣告要哪種 GPU，由它去配節點。這一部分我目前只讀過文件、還沒實際跑過，Day 25 會用 Whisper backend 的脈絡再比一次 Cloud Run GPU 跟 GKE GPU。
另一個特殊需求是想把節點塞到極致：你清楚一台機器能塞下幾隻小 bot，想集中放來壓低成本。這種精細的 bin-packing，Standard 給的掌控度大；Autopilot 的一般 Pod 是按宣告的資源計費，很難從中擠出套利空間。
延續 Day 19 的成本結構：
但要留意：Autopilot 按 Pod requests 計價，requests 估得太寬，就是直接在浪費錢。 Day 09 講過 requests 要誠實設，在 Autopilot 裡這句話會直接反映在帳單上。
老實說，我到現在還沒有長期跑在 GKE 上的 workload：always-on bot 在 VM 上，Whisper backend 在 Cloud Run。但如果明天要把 OpenAB 搬上 GKE，我會選 Autopilot 起步。原因很單純：先確認 agent 們能在 K8s 上正常活著，再煩惱要不要為了省錢接管節點。 順序顛倒，很可能在部署成功之前就被節點設定淹沒。
明天動手：把一個 agent API 部署到 Cloud Run，secret、min instances、並發設定一次講完。
Autopilot 是「我只管 Pod 需要多少」，Standard 是「機器底層也歸我管」；一個人開發 agent，先用 Autopilot 讓它跑起來，省錢的細節等上線之後再說。
iThome鐵人賽
看影片追技術