AI 和機器學習觀點：可靠性

Last reviewed 2025-08-07 UTC

這份文件位於「Google Cloud Well-Architected Framework：AI 和機器學習觀點」中，概述了在 Google Cloud上設計及運作可靠 AI 和機器學習系統的原則和建議。本課程將探討如何將進階可靠性做法和可觀測性整合到架構藍圖中。本文中的建議符合 Google Cloud 架構完善架構的可靠性支柱。

在快速發展的 AI 和機器學習領域，可靠的系統是確保客戶滿意度和達成業務目標的必要條件。為了滿足預測型機器學習和生成式 AI 的獨特需求，您需要強大、可靠且適應性強的 AI 和機器學習系統。如要處理 MLOps 的複雜性 (從開發到部署和持續改善)，您需要採用「可靠性優先」的方法。 Google Cloud 提供專為 AI 打造的基礎架構，符合網站可靠性工程 (SRE) 原則，並為可靠的 AI 和機器學習系統奠定堅實基礎。

這份文件中的建議對應至下列核心原則：

確保機器學習基礎架構可擴充且可用性高

雲端中可靠的 AI 和 ML 系統需要可擴充且高可用性的基礎架構。這些系統的需求會不斷變化，需要各種資源，且高度依賴模型可用性。可擴充的架構可因應負載波動，以及資料量或推論要求的變化。高可用性 (HA) 有助於確保元件、可用區或區域層級的故障復原能力。

如要建構可擴充且可用性高的機器學習基礎架構，請參考下列建議。

導入自動和動態調整資源配置功能

AI 和 ML 工作負載是動態的，需求會根據資料抵達率、訓練頻率和推論流量而波動。自動和動態調度功能可根據需求波動，順暢調整基礎架構資源。有效調整工作負載有助於防止停機、維持效能及盡可能提高成本效益。

如要自動調整 AI 和機器學習工作負載的規模，請使用 Google Cloud下列產品和功能：

  • 資料處理管道：在 Dataflow 中建立資料管道。將管道設定為使用 Dataflow 的水平自動調度資源功能，根據 CPU 使用率、管道平行處理和待處理資料，動態調整工作站執行個體數量。啟動工作時，您可以透過管道選項設定自動調度參數。
  • 訓練工作：使用 Vertex AI 自訂訓練，自動調整訓練工作規模。您可以定義工作站集區規格，例如機器類型、加速器類型和數量，以及工作站集區數量。對於可容許中斷的作業，以及訓練程式碼實作檢查點的作業，您可以使用 Spot VM 降低成本。
  • 線上推論：如要進行線上推論，請使用 Vertex AI 端點。如要啟用自動調度資源功能，請設定副本數量下限和上限。 如要確保高可用性，請至少指定兩個副本。Vertex AI 會根據流量和設定的自動調度指標 (例如 CPU 使用率和副本使用率)，自動調整副本數量。
  • Google Kubernetes Engine 中的容器化工作負載： 在節點和 Pod 層級設定自動調度資源。設定叢集自動調度器和節點自動佈建功能，根據擱置中的 Pod 資源要求 (例如 CPU、記憶體、GPU 和 TPU) 調整節點數量。針對 Deployment 使用水平 Pod 自動調度器 (HPA)，根據 CPU 和記憶體使用率等指標定義調度政策。您也可以根據自訂的 AI 和機器學習指標調度資源，例如 GPU 或 TPU 使用率，以及每秒預測要求數。
  • 無伺服器容器化服務：在 Cloud Run 中部署服務，並指定容器執行個體數量下限和上限，設定自動調度資源。請按照最佳做法指定加速器類型，自動調整啟用 GPU 的執行個體。Cloud Run 會根據傳入要求，在設定的上下限之間自動調度執行個體。如果沒有要求，系統會有效率地將資源調度降至零個執行個體。您可以運用 Cloud Run 的自動要求驅動式擴縮功能，部署 Vertex AI 代理程式，以及部署第三方工作負載，例如使用 Ollama 的量化模型、使用 vLLM 的 LLM 模型推論，以及Huggingface Text Generation Inference (TGI)。

設計時兼顧高可用性和容錯能力

對於正式環境等級的 AI 和機器學習工作負載，請務必確保持續運作，並具備故障復原能力。如要實作高可用性和容錯功能，您需要在 Google Cloud的架構中建構備援和複製功能。這種做法可確保個別元件發生故障時，不會導致整個系統故障。

在 Google Cloud中為重要的 AI 和機器學習元件實作備援機制。 以下列舉可實作資源備援的產品和功能：

  • 跨多個區域部署 GKE 區域叢集。
  • 使用 Cloud Storage 多區域或雙區域值區，確保資料集和檢查點的資料冗餘。
  • 使用 Spanner 儲存中繼資料，確保全球一致性與高可用性。
  • 為營運資料庫設定 Cloud SQL 唯讀備用資源。
  • 確保檢索增強生成 (RAG) 的向量資料庫具備高可用性，且位於多個可用區或區域。

主動管理資源並預測需求

有效管理資源有助於提高成本效益、效能和可靠性，因此非常重要。AI 和機器學習工作負載具有動態特性，因此對 GPU 和 TPU 等專用硬體的需求很高。因此，您必須主動管理資源，確保資源可用性。

根據過往的監控資料 (例如 GPU 或 TPU 使用率和輸送量)，從 Cloud Monitoring 和 Cloud Logging 中的記錄檔規劃容量。使用 BigQuery 或 Looker Studio 分析這項遙測資料，並根據成長或新模型預測 GPU 未來的需求。分析資源用量模式和趨勢，有助於預測何時何地需要重要的專用加速器。

  • 透過嚴謹的負載測試驗證容量預估值。使用 Apache JMeter 或 LoadView 等工具，模擬 AI 和 ML 服務 (例如服務和管道) 的流量。
  • 分析系統在壓力下的行為。
    • 為預測及滿足生產環境中日益增加的工作負載需求，請主動找出資源需求。監控延遲時間、處理量、錯誤和資源用量，尤其是 GPU 和 TPU 用量。視需要提高資源配額。
    • 如要提供生成式 AI 服務，請在高並行負載下進行測試，並找出加速器可用性限制效能的程度。
  • 持續監控模型查詢，並為代理程式設定主動式快訊。
    • 使用模型可觀測性資訊主頁，查看 Cloud Monitoring 收集的指標，例如每秒模型查詢次數 (QPS)、權杖輸送量和第一個權杖延遲時間。

充分善用資源

根據工作負載需求策略性地選取合適的運算資源，以最佳化成本並確保資源可用性。

  • 如要穩定執行 24 小時不間斷的推論作業，或是訓練工作負載的容量需求固定或可預測，請使用 VM 和加速器的承諾使用折扣 (CUD)。

  • 針對 GKE 節點和 Compute Engine VM，請使用 Spot VM 和 Dynamic Workload Scheduler (DWS) 功能：

    • 對於評估和實驗工作負載等容錯工作，請使用 Spot VM。Spot VM 可能會遭到先占，但有助於降低整體成本。
    • 如要管理高需求加速器的搶占風險，可以使用 DWS 確保取得加速器。
      • 如要進行複雜的批次訓練，需要高階 GPU 執行最多七天，請使用 DWS Flex-Start 模式。
      • 如要執行時間較長 (最多三個月) 的工作負載，請使用「日曆」模式預留特定 GPU (H100 和 H200) 和 TPU (Trillium)。

  • 如要在 GKE 上最佳化 AI 推論作業，您可以執行 vLLM 引擎，動態使用 TPU 和 GPU，因應容量和效能需求變化。詳情請參閱「vLLM GPU/TPU 互換性」。

  • 在進階情境中，如果資源和拓撲需求複雜，且涉及加速器，請使用工具來抽象化資源管理。

    • 叢集導向器可讓您部署及管理加速器群組，並為多 GPU 訓練 (A3 Ultra H200 和 A4 B200) 進行共置和排程。Cluster Director 支援 GKE 和 Slurm 叢集。
    • Ray on Vertex AI 可抽象化分散式運算基礎架構，應用程式可藉此要求訓練和服務資源，不必直接管理 VM 和容器。

將連入流量分散至多個執行個體

對於需求量不穩定的 AI 應用程式而言，有效的負載平衡至關重要。負載平衡會分配流量、提高資源使用率、提供高可用性和低延遲，並確保使用者體驗順暢無阻。

  • 推論作業的資源需求各不相同：根據模型指標實作負載平衡。GKE 推論閘道可讓您在負載平衡器後方部署模型，並進行模型感知式路由。閘道會優先處理搭載 GPU 和 TPU 加速器的執行個體，以執行耗用大量運算資源的任務，例如生成式 AI 和 LLM 推論。設定詳細的健康狀態檢查，評估模型狀態。使用 vLLM 或 Triton 等服務架構取得 LLM 指標，並使用 Google Cloud Managed Service for Prometheus 將指標整合至 Cloud Monitoring。
  • 需要 GPU 或 TPU 的推論工作負載：為確保重要的 AI 和機器學習推論工作負載持續在適合工作負載需求的機器上執行，特別是在 GPU 和 TPU 可用性受限時，請使用 GKE 自訂運算類別。您可以定義特定運算設定檔，並為自動調整規模設定備用政策。舉例來說，您可以定義設定檔，為預留的 GPU 或 TPU 執行個體指定較高的優先順序。如果預留資源暫時無法使用，設定檔可以包含備援機制，改用具成本效益的 Spot VM。
  • 在各種協調平台使用生成式 AI：使用集中式負載平衡器。舉例來說，為了提高成本和管理效率，您可以將 GPU 需求較低的要求傳送至 Cloud Run，並將更複雜、需要大量 GPU 的工作傳送至 GKE。如要進行服務間通訊和政策管理，請使用 Cloud Service Mesh 導入服務網格。使用 Cloud Logging 和 Cloud Monitoring，確保記錄和監控作業一致。
  • 全域負載分配：如要為需要低延遲的全球使用者進行負載平衡，請使用全域外部應用程式負載平衡器。設定地理位置轉送至最近的區域，並實作容錯移轉。在 Vertex AI 或 GKE 中建立區域端點複本。為靜態資產設定 Cloud CDN。 使用 Cloud Monitoring 監控全球流量和延遲時間。
  • 精細的流量管理：對於資料類型或複雜度各異，以及長時間執行的要求，請實作精細的流量管理。
    • 設定內容式轉送，根據網址路徑和標頭等屬性，將要求導向專門的後端。舉例來說，直接向支援 GPU 的後端提出圖片或影片模型要求，以及向 CPU 最佳化後端提出文字模型要求。
    • 如要處理長時間執行的生成式 AI 要求或批次工作負載，請使用 WebSocket 或 gRPC。導入流量管理功能，處理逾時和緩衝問題。使用 API Gateway 或 Apigee 設定要求逾時和重試，並實作速率限制和配額。

採用模組化和鬆耦合架構

在模組化鬆耦合的 AI 和 ML 架構中，複雜系統會劃分為較小的獨立元件，並透過明確定義的介面互動。這個架構可減少模組依附元件、簡化開發和測試、提升可重現性，並透過容錯機制改善容錯能力。模組化方法對於管理複雜性、加速創新及確保長期可維護性至關重要。

如要為 AI 和機器學習工作負載設計模組化且鬆散耦合的架構，請參考下列建議。

導入小型獨立模組或元件

將端對端 AI 和機器學習系統分成小型獨立模組或元件。每個模組或元件都負責特定功能，例如資料擷取、特徵轉換、模型訓練、推論服務或評估。模組化設計可為 AI 和機器學習系統帶來多項主要優勢：提升維護性、擴充性、重複使用性，以及更大的彈性和靈活性。

以下各節說明 Google Cloud 產品、功能和工具，可用於設計 AI 和 ML 系統的模組化架構。

GKE 上的容器化微服務

對於需要精細調度管理的複雜 AI 和 ML 系統或精細的生成式 AI 管道，請將模組實作為微服務，並使用 GKE 調度管理。將每個不同階段封裝為 Docker 容器中的個別微服務。這些階段包括：擷取各種格式的資料、預先處理或特徵工程、分散式模型訓練或微調大型基礎模型、評估或提供服務。

在 GKE 上部署容器化微服務，並根據 CPU 和記憶體使用率或 GPU 使用率等自訂指標，運用自動調度、輪流更新和 YAML 資訊清單中的可重現設定。使用 GKE 服務探索功能，確保微服務之間的通訊效率。如為非同步模式，請使用訊息佇列，例如 Pub/Sub。

採用 GKE 微服務方法，有助於建構可擴充的彈性平台，以執行複雜的 RAG 應用程式等工作，因為這些階段可以設計為不同的服務。

無伺服器事件導向服務

對於可從無伺服器自動調整資源配置獲益的事件導向工作，請使用 Cloud Run 或 Cloud Run functions。這些服務非常適合非同步工作 (例如前置處理) 或較小的推論工作。在發生事件時觸發 Cloud Run 函式，例如在 Cloud Storage 中建立新的資料檔案，或在 Artifact Registry 中更新模型。如為需要容器環境的 Webhook 工作或服務，請使用 Cloud Run。

Cloud Run 服務和 Cloud Run 函式可快速擴充，也能縮減至零，有助於確保工作負載波動時的成本效益。這些服務適用於 Vertex AI Agents 工作流程中的模組化元件。您可以使用工作流程或 應用程式整合，自動化調度管理元件序列。

Vertex AI 代管服務

Vertex AI 服務支援模組化，可協助您簡化 AI 和機器學習系統的開發與部署作業。這些服務可簡化基礎架構的複雜性，讓您專注於應用程式邏輯。

  • 如要調度以模組化步驟建構的工作流程，請使用 Vertex AI Pipelines。
  • 如要執行自訂 AI 和機器學習程式碼，請將程式碼封裝在 Docker 容器中，以便在 Vertex AI 自訂訓練和 Vertex AI 預測等代管服務上執行。
  • 如要使用模組化特徵工程管道，請使用 Vertex AI 特徵儲存庫。
  • 如要進行模組化探索和原型設計，請使用筆記本環境，例如 Vertex AI Workbench 或 Colab Enterprise。將程式碼整理成可重複使用的函式、類別和指令碼。

代理應用程式

對於 AI 代理，Agent Development Kit (ADK) 提供模組化功能，例如工具和狀態。如要啟用 LangChain、LangGraph、LlamaIndex 和 Vertex AI 等架構之間的互通性，您可以將 ADK 與 Agent2Agent (A2A) 通訊協定和模型內容通訊協定 (MCP) 搭配使用。這項互通性可讓您使用各種元件，組成代理程式工作流程。

您可以在 Vertex AI Agent Engine 上部署代理，這是專為可擴充代理部署作業最佳化的受管理執行階段。如要執行容器化代理程式，可以運用 Cloud Run 的自動調度資源功能。

設計定義明確的介面

如要建構功能完善且易於維護的軟體系統，請務必確保系統元件鬆散耦合且模組化。這種做法可大幅減少系統不同部分之間的依附情形，因此具有顯著優勢。模組鬆耦合時，一個模組的變更對其他模組的影響極小。這種隔離機制可讓個別模組獨立更新和開發工作流程。

以下各節提供指引，協助確保 AI 和機器學習系統的模組之間能順暢通訊及整合。

通訊協定選擇

  • 如要提供通用存取權，請使用 HTTP API、遵守 RESTful 原則，並使用 JSON 進行語言無關的資料交換。設計 API 端點，代表資源的動作。
  • 如要進行微服務之間的高效能內部通訊，請使用 gRPC 和 通訊協定緩衝區 (ProtoBuf)，以利進行有效率的序列化和嚴格型別作業。使用 .proto 檔案定義 ModelInput、PredictionResult 或 ADK 工具資料等資料結構，然後產生語言繫結。
  • 如要處理效能至關重要的用途，請針對大型資料集或連續流程 (例如即時文字轉語音或影片應用程式)，運用 gRPC 串流。在 GKE 上部署 gRPC 服務。

標準化且詳盡的說明文件

無論選擇哪種介面通訊協定，標準化文件都至關重要。OpenAPI 規格說明 RESTful API。使用 OpenAPI 記錄 AI 和 ML API：路徑、方法、參數、連結至 JSON 結構定義的要求/回應格式，以及安全性。詳盡的 API 說明文件有助於提升探索能力和用戶端整合。如要編寫及呈現 API，請使用 Swagger 編輯器等 UI 工具。如要加快開發速度並確保一致性，可以使用 Gemini Code Assist 等 AI 輔助程式碼編寫工具，生成用戶端 SDK 和伺服器存根。將 OpenAPI 文件整合至 CI/CD 流程。

與 Google Cloud Vertex AI 等代管服務互動

您可以選擇抽象層級較高的 Vertex AI SDK (有助於提高開發效率)，或是 REST API 提供的精細控制項。

  • Vertex AI SDK 可簡化工作和驗證程序。需要與 Vertex AI 互動時，請使用 SDK。
  • REST API 是功能強大的替代方案，特別是當系統層級之間需要互通性時。如果工具使用的語言沒有 SDK，或是您需要精細控管，這項功能就非常實用。

使用 API 隔離模組並抽象化實作詳細資料

為確保安全性、可擴充性和可視性，請務必為 AI 和 ML 服務導入健全的 API 管理機制。如要為定義的介面實作 API 管理，請使用下列產品：

  • API Gateway： 對於對外公開及管理的 API，API Gateway 提供集中式安全進入點。可簡化預測、訓練和資料 API 等無伺服器後端服務的存取程序。API Gateway 可協助整合存取點、強制執行 API 合約，以及管理 API 金鑰和 OAuth 2.0 等安全防護功能。為避免後端過載並確保可靠性，請在 API Gateway 中實作速率限制和用量配額。
  • Cloud Endpoints：如要在 GKE 和 Cloud Run 上簡化 API 開發和部署作業，請使用 Cloud Endpoints。這項服務提供易於使用的解決方案，可產生 API 金鑰。此外，它還提供 API 呼叫的整合式監控和追蹤功能，並自動產生 OpenAPI 規格，簡化文件和用戶端整合作業。您可以使用 Cloud Endpoints 管理內部或受控 AI 和 ML API 的存取權，例如觸發訓練和管理特徵商店。
  • Apigee： 對於企業級 AI 和機器學習，尤其是複雜的生成式 AI API，Apigee 提供進階且全面的 API 管理服務。Apigee 提供進階安全防護功能 (例如威脅防護和 OAuth 2.0)、流量管理功能 (例如快取、配額和中介服務)，以及分析功能。Apigee 可協助您深入瞭解 API 使用模式、成效和參與度，這對於瞭解生成式 AI API 使用情形至關重要。

規劃優雅降級

在實際運作的 AI 和 ML 系統中，元件故障是無可避免的，就像其他系統一樣。系統會確保基本功能繼續運作，但效能可能會降低。這種做法可避免全面停機，並提升整體可用性。對於延遲時間敏感的推論、分散式訓練和生成式 AI 而言，優雅降級至關重要。

以下各節說明規劃及實作正常降級的技術。

故障隔離

  • 如要在分散式架構中找出故障元件，請使用彈性程式庫 (例如 Java 中的 Resilience4j 和 Python 中的 CircuitBreaker)，實作斷路器模式。
  • 為避免連鎖故障，請根據 AI 和機器學習工作負載指標 (例如錯誤率和延遲時間) 設定門檻，並定義備援機制，例如較簡單的模型和快取資料。

元件備援

針對重要元件，請實作備援和自動容錯移轉。舉例來說，您可以使用 GKE 多區域叢集或區域叢集，並在不同區域中以冗餘方式部署 Cloud Run 服務。如要偵測健康狀態不良的執行個體，並將流量轉送至健康狀態良好的執行個體，請使用 Cloud Load Balancing。

使用 Cloud Storage 多區域值區，確保資料備援。 如要進行分散式訓練，請實作非同步檢查點，以便在發生失敗後繼續訓練。如要進行彈性訓練，請使用Pathways。

主動監控

系統故障時，優雅降級有助於確保系統可用性，但您也必須採取主動措施，持續進行健康狀態檢查和全面監控。收集 AI 和機器學習專屬指標，例如延遲時間、處理量和 GPU 使用率。此外，您也可以使用 Cloud Monitoring 和 Vertex AI Model Monitoring，收集模型和資料偏移等模型效能下降指標。

健康狀態檢查可能會觸發更換故障節點、部署更多容量的需求，或自動觸發使用更新資料的管道持續重新訓練或微調。這種主動式做法有助於防止準確度下降和系統層級的正常降級，並提升整體可靠性。

SRE 做法

如要監控系統健康狀態，建議採用 SRE 做法，實作服務等級目標 (SLO)。錯誤預算損失和消耗率的快訊可做為系統可靠性問題的早期指標。如要進一步瞭解 SRE 做法，請參閱 Google SRE 書籍。

建構自動化端對端機器學習運作平台

如要在 Google Cloud上建構強大、可擴充且可靠的 AI 和機器學習系統，需要自動化端對端機器學習運作平台，才能完成模型開發生命週期。開發生命週期包括初始資料處理、持續模型訓練、部署，以及在正式環境中監控。在 Google Cloud自動執行這些階段，可建立可重複的程序、減少手動作業、降低錯誤，並加快創新速度。

自動化機器學習運作平台對於確保應用程式達到生產環境等級的可靠性至關重要。自動化有助於確保模型品質、保證可重現性，並持續整合及交付 AI 和機器學習成果。

如要建構自動化端對端 MLOps 平台，請參考下列建議。

自動化模型開發生命週期

自動化 MLOps 平台的核心要素，是將整個 AI 和機器學習工作流程調度管理為一系列相互連結的自動化步驟，包括資料準備和驗證、模型訓練、評估、部署及監控。

管理基礎架構即程式碼

基礎架構即程式碼 (IaC) 對於管理 AI 和 ML 系統基礎架構至關重要，有助於實現可重現、可擴充及可維護的部署作業。AI 和機器學習系統的基礎架構需求十分複雜，而且會不斷變化。這些系統通常需要 GPU 和 TPU 等專用硬體。IaC 可確保一致性、啟用復原功能，並讓部署作業可重複執行，有助於降低手動管理基礎架構的風險。

如要以程式碼有效管理基礎架構資源，請使用下列技術。

自動佈建資源

如要在 Google Cloud上有效管理 IaC，請使用 Terraform 定義及佈建 AI 和機器學習基礎架構資源。基礎架構可能包含下列資源：

  • 已設定節點集區的 GKE 叢集。您可以根據工作負載需求，最佳化節點集區。舉例來說，您可以使用 A100、H100、H200 或 B200 GPU 進行訓練，並使用 L4 GPU 進行推論。
  • Vertex AI 端點，已設定用於模型服務，並定義機器類型和擴充政策。
  • Cloud Storage bucket，用於存放資料和構件。

使用設定範本

將 Terraform 設定整理為模組化範本。如要加速佈建 AI 和 ML 資源，可以使用 Cluster Toolkit。這個工具包提供範例藍圖，也就是 Google 策劃的 Terraform 範本，可用於在 Slurm 或 GKE 中部署可立即使用的 HPC、AI 和機器學習叢集。您可以自訂 Terraform 程式碼，並在版本控管系統中管理。如要自動執行資源佈建和更新工作流程，可以使用 Cloud Build 將程式碼整合至 CI/CD 管道。

自動變更設定

佈建基礎架構後，以宣告方式管理持續進行的設定變更：

  • 在以 Kubernetes 為中心的環境中，使用 Config Connector 將資源管理為 Kubernetes 物件。 Google Cloud
  • 使用 YAML 資訊清單定義及管理 Vertex AI 資源，例如資料集、模型和端點、Cloud SQL 執行個體、Pub/Sub 主題和 Cloud Storage bucket。
  • 將資訊清單部署至 GKE 叢集，整合應用程式和基礎架構設定。
  • 使用 CI/CD 管道自動更新設定，並使用範本處理環境差異。
  • 使用 IaC 實作 Identity and Access Management (IAM) 政策和服務帳戶的設定。

整合 CI/CD

  • 將 IaC 整合至 CI/CD 管道，並使用 Cloud Build 和 Infrastructure Manager 等工具，自動執行 Google Cloud 基礎架構資源的生命週期。
  • 定義程式碼提交時自動更新的觸發條件。
  • 在管道中導入自動測試和驗證。舉例來說，您可以建立指令碼，自動執行 Terraform validate 和 plan 指令。
  • 將設定儲存為構件，並啟用版本管理。
  • 在版本控制中定義不同的環境 (例如開發、預備和正式環境)，並自動升級環境。

驗證模型行為

如要長期維持模型的準確度和關聯性，請在 MLOps 平台中自動執行訓練和評估程序。這項自動化功能搭配嚴格的驗證程序，可確保模型在部署至實際工作環境前，能根據相關資料正常運作。

  • 設定持續訓練管道，這些管道會由新資料和監控信號 (例如資料偏移) 觸發，或依排程執行。
    • 如要管理自動化訓練工作 (例如超參數調整試驗，以及較大型模型的分散式訓練設定)，請使用 Vertex AI 自訂訓練。
    • 如要微調基礎模型，請自動執行微調程序，並將作業整合至管道。
  • 每次成功執行訓練後，實作自動模型版本控管，並安全地儲存訓練好的模型構件。您可以將構件儲存在 Cloud Storage 中，或在 Model Registry 中註冊。
  • 定義評估指標並設定明確的門檻，例如最低準確度、最高錯誤率和最低 F1 分數。
    • 確保模型達到自動通過評估的門檻，並考慮部署。
    • 使用 Vertex AI 的模型評估服務等服務，自動執行評估。
    • 請確保評估內容包含生成輸出內容品質、事實準確度、安全屬性，以及是否符合指定樣式或格式等指標。
  • 如要自動記錄及追蹤每次訓練和評估作業的參數、程式碼版本、資料集版本和結果，請使用 Vertex AI Experiments。這種做法可提供有用的記錄，方便您比較、偵錯及重現結果。
  • 如要最佳化超參數調整，並根據您定義的目標自動搜尋最佳模型設定，請使用 Vertex AI Vizier。
  • 如要將訓練指標視覺化，並在開發期間進行偵錯，請使用 Vertex AI TensorBoard。

驗證 AI 和機器學習管道的輸入和輸出內容

為確保 AI 和 ML 系統的可靠性和完整性，您必須在資料進入系統和管道時驗證資料。您也必須在元件邊界驗證輸入和輸出內容。對所有輸入和輸出內容 (原始資料、處理過的資料、設定、引數和檔案) 進行嚴格驗證，有助於避免發生非預期行為，並在整個 MLOps 生命週期中維持模型品質。將這種主動式做法整合到 MLOps 平台後，有助於在錯誤傳播到整個系統之前偵測到錯誤，進而節省時間和資源。

如要有效驗證 AI 和 ML pipeline 的輸入和輸出內容，請使用下列技術。

自動驗證資料

  • 使用 TensorFlow Data Validation (TFDV)，在資料擷取和前處理管道中導入自動化資料驗證。
    • 如要進行大規模的 SQL 資料品質檢查，請善用 BigQuery 等可擴充的處理服務。
    • 如要對串流或批次資料進行複雜的程式輔助驗證，請使用 Dataflow。
  • 使用 TFDV 功能監控一段時間內的資料分布情形。
    • 使用與 Cloud Monitoring 整合的工具，將趨勢視覺化，以偵測資料偏移。當資料模式大幅變更時，您可以自動觸發模型重新訓練管道。
  • 將驗證結果和指標儲存在 BigQuery 中，以供分析及追蹤歷史記錄，並將驗證構件封存至 Cloud Storage。

驗證管道設定和輸入資料

為避免因設定錯誤而導致管道失敗或發生非預期行為，請對所有管道設定和指令列引數實作嚴格的驗證：

  • 使用 jsonschema 等 Python 專用的結構定義驗證程式庫，為 YAML 或 JSON 等設定檔定義明確的結構定義。在管道執行開始前和元件執行前，請根據這些結構定義驗證設定物件。
  • 使用 argparse 等引數剖析程式庫，為所有指令列引數和管道參數實作輸入驗證。驗證應檢查資料類型是否正確、值是否有效，以及是否提供必要引數。
  • 在 Vertex AI Pipelines 中，使用內建的元件輸入驗證功能，定義元件參數的預期類型和屬性。
  • 為確保管線執行作業可重現，並維護稽核追蹤記錄，請將經過驗證的設定檔 (含版本) 儲存在 Cloud Storage 或 Artifact Registry 中。

驗證輸入和輸出檔案

驗證輸入和輸出檔案 (例如資料集、模型構件和評估報告) 的完整性和格式正確性：

  • 使用程式庫驗證 CSV、Parquet 和圖片類型等檔案格式。
  • 如果是大型檔案或重要構件，請使用 Cloud Storage 資料驗證和變更偵測功能，驗證檔案大小和總和檢查碼，偵測檔案是否毀損或傳輸不完整。
  • 使用 Cloud Run 函式 (例如根據檔案上傳事件) 或 Dataflow 管道執行檔案驗證。
  • 將驗證結果儲存在 BigQuery 中，方便日後擷取及分析。

自動化部署及實作持續監控

自動部署及持續監控正式環境中的模型，有助於確保可靠性、快速更新及及時偵測問題。包括管理模型版本、控管部署作業、使用 CI/CD 自動部署，以及全面監控，詳情請參閱下列各節。

管理模型版本

使用版本控管工具管理模型疊代和相關構件：

  • 如要追蹤模型版本和中繼資料，並連結至基礎模型構件，請使用 Model Registry。
  • 實作明確的版本管理架構 (例如語意化版本管理)。為每個模型版本附加完整的中繼資料，例如訓練參數、驗證管道的評估指標和資料集版本。
  • 將模型構件 (例如模型檔案、預先訓練的權重和提供模型的容器映像檔) 儲存在 Artifact Registry 中，並使用其版本控管和標記功能。
  • 為符合安全性與管理需求，請為 Model Registry 和 Artifact Registry 定義嚴格的存取控制政策。
  • 如要透過程式註冊及管理版本，並將版本整合至自動化 CI/CD 管道，請使用 Vertex AI SDK 或 API。

執行受控部署作業

使用服務平台流量管理功能，控管模型版本部署至端點的作業。

  • 使用 Vertex AI 端點的流量分配功能，實作滾動式部署。
  • 如果將模型部署至 GKE，請使用進階流量管理技術，例如Canary 部署：
    1. 將一小部分正式環境流量轉送至新模型版本。
    2. 透過指標持續監控效能和錯誤率。
    3. 確認模型是否可靠。
    4. 將版本發布至所有流量。
  • 對 AI 虛擬服務專員執行 A/B 測試：
    1. 將兩個不同的模型代理程式版本或完全不同的模型部署至同一個端點。
    2. 在部署作業之間拆分流量。
    3. 根據業務目標分析結果。
  • 導入自動復原機制，在觸發監控快訊或未達到效能門檻時，可快速將端點流量還原為先前的穩定模型版本。
  • 使用 Vertex AI SDK 或 API，以程式輔助方式設定流量分配和部署設定。
  • 使用 Cloud Monitoring 追蹤各版本的效能和流量。
  • 透過 CI/CD 管道自動部署。您可以使用 Cloud Build 建構容器、版本化構件，並觸發部署至 Vertex AI 端點。
  • 請確認 CI/CD 管道會管理版本，並從 Artifact Registry 提取版本。
  • 轉移流量前，請先自動測試端點，確認預測準確度、延遲時間、輸送量和 API 函式。
  • 將所有設定儲存在版本控管系統中。

持續監控

  • 使用模型監控自動偵測效能下降、資料偏移 (與訓練資料相比，輸入資料分布情形的變化) 和預測偏移 (模型輸出內容的變化)。
    • 設定具有門檻和快訊的漂移偵測工作。
    • 監控即時效能：預測延遲時間、輸送量、錯誤率。
  • 在Cloud Monitoring 中定義業務 KPI 的自訂指標。
  • 將模型監控結果和自訂指標與 Cloud Monitoring 整合，以便設定快訊和資訊主頁。
  • 設定電子郵件、Slack 或 PagerDuty 等通知管道，並設定自動補救措施。
  • 如要對預測記錄進行偵錯，請使用 Cloud Logging。
  • 將監控與事件管理整合。

如果是生成式 AI 端點，請監控輸出內容的特徵，例如有害程度和連貫性：

  • 監控特徵服務的偏移。
  • 實作精細的預測驗證：使用自訂邏輯，根據預期範圍和格式驗證輸出內容。
  • 監控預測分布情形的變化。
  • 驗證輸出結構定義。
  • 設定非預期輸出和變動的快訊。
  • 使用 Pub/Sub 追蹤及回應即時驗證事件。

確保全面監控的輸出內容會回饋到持續訓練中。

透過資料和模型管理機制，維持信任和控管權

AI 和機器學習的可靠性不僅限於技術運作時間，包括信任和健全的資料與模型治理。AI 輸出內容可能不正確、有偏見或過時。這類問題會損害信任感，甚至造成傷害。全面追蹤、嚴格控管存取權、自動驗證及透明化做法，有助於確保 AI 輸出內容可靠、值得信賴，且符合道德標準。

如要透過資料和模型管理機制維持信任和控管，請參考下列建議。

建立資料和模型目錄，以利追蹤

為利於全面追蹤、稽核及瞭解 AI 和 ML 資產的沿革，請在整個生命週期中，維護資料和模型版本的集中式記錄。可靠的資料和模型目錄可做為單一資料來源，提供 AI 和機器學習管道使用的所有構件，包括原始資料來源、已處理的資料集、訓練好的模型版本，以及已部署的端點。

使用下列產品、工具和技術，為資料資產建立及維護目錄：

  • 使用 Dataplex Universal Catalog 建構企業級資料資產目錄。如要自動探索及建立資料資產的清查表，請將 Dataplex Universal Catalog 與儲存系統整合，例如 BigQuery、Cloud Storage 和 Pub/Sub。
  • 將資料儲存在 Cloud Storage 多區域或雙區域值區，確保資料具有高可用性和耐久性。您上傳至這些值區的資料，至少會備援到兩個不同的地理位置。這項備援機制可內建復原能力，防範區域性服務中斷，並確保資料完整性。
  • 使用相關業務中繼資料、擁有權資訊、機密程度和歷程詳細資料，為資料集加上標記和註解。舉例來說，您可以將已處理的資料集連結至原始來源，以及建立該資料集的管道。
  • 使用 Model Registry 建立模型版本的中央存放區。註冊每個訓練好的模型版本，並連結至相關聯的中繼資料。 中繼資料可包含下列項目：
    • 訓練參數。
    • 驗證管道的評估指標。
    • 用於訓練的資料集版本，歷程追溯至相關的 Dataplex Universal Catalog 項目。
    • 產生資料集的程式碼版本。
    • 所用架構或基礎模型的詳細資料。
  • 將模型匯入 Model Registry 前，請先將模型構件 (例如模型檔案和預先訓練的權重) 儲存在 Cloud Storage 等服務中。將用於服務或自訂訓練工作的自訂容器映像檔，儲存在 Artifact Registry 等安全存放區。
  • 如要確保系統在建立或修改資料和模型資產時，會自動在各自的目錄中登錄及更新這些資產，請在 MLOps 管道中導入自動化程序。這項全面編目功能可提供從原始資料到預測結果的端對端追蹤功能，方便您稽核導致特定模型版本或預測結果的輸入內容和程序。稽核功能對於偵錯非預期行為、確保遵守資料使用政策，以及瞭解資料或模型變更對時間的影響至關重要。
  • 如果是生成式 AI 和基礎模型，目錄也必須追蹤所用特定基礎模型的詳細資料、微調參數，以及與生成輸出內容品質和安全性相關的評估結果。

導入完善的存取控管機制和稽核追蹤

為維護 AI 和 ML 系統的信任度和控制權，您必須保護私密資料和模型，防止未經授權的存取行為，並確保所有變更都有責任歸屬。

  • 在 AI 和機器學習系統的所有元件中，實施嚴格的存取權控管，並維護詳細的稽核追蹤記錄 Google Cloud。
  • 在 IAM 中為與 AI 和 ML 資源互動的使用者、群組和服務帳戶定義精細權限。
  • 嚴格遵循最低權限原則。
  • 只授予特定工作所需的最低權限。舉例來說，訓練服務帳戶需要訓練資料的讀取權限和模型構件的寫入權限，但服務可能不需要生產環境服務端點的寫入權限。

對 AI 和 ML 系統中的所有相關資產和資源套用一致的 IAM 政策，包括：

  • 含有機密資料或模型構件的 Cloud Storage bucket。
  • BigQuery 資料集。
  • Vertex AI 資源，例如模型存放區、端點、管道和特徵儲存庫資源。
  • 運算資源，例如 GKE 叢集和 Cloud Run 服務。

使用稽核和記錄功能擷取、監控及分析存取活動：

  • 為 AI 和 ML 系統使用的所有 Google Cloud 服務啟用 Cloud 稽核記錄。
  • 設定稽核記錄，擷取 API 呼叫、資料存取事件，以及資源設定變更的詳細資訊。監控記錄，找出可疑活動、未經授權的存取嘗試，或重要資料/模型資產的意外修改。
  • 如要進行即時分析、設定快訊和產生視覺化資料，請將稽核記錄串流至 Cloud Logging。
  • 如要以符合成本效益的方式長期儲存資料，並進行回溯安全分析或法規遵循稽核，請將記錄匯出至 BigQuery。
  • 如要集中監控安全性，請將稽核記錄與安全資訊與事件管理 (SIEM) 系統整合。定期檢查存取政策和稽核追蹤記錄，確保這些項目符合控管規定，並偵測潛在的政策違規行為。
  • 對於處理機密資料 (例如用於訓練或推論的個人識別資訊 (PII)) 的應用程式，請在管道或資料儲存空間內使用機密資料保護檢查。
  • 對於生成式 AI 和代理解決方案，稽核追蹤記錄可協助追蹤存取特定模型或工具的使用者、用於微調或提示的資料，以及傳送至正式端點的查詢。稽核記錄可協助您確保問責制，並提供重要資料，供您調查資料濫用或違反政策的情形。

解決偏誤、透明度和可解釋性問題

如要建構值得信賴的 AI 和機器學習系統，您必須修正資料和模型中固有的潛在偏誤，盡量提高系統行為的透明度，並說明模型輸出內容的依據。在敏感領域建構可信賴的系統，或使用複雜模型 (例如通常用於生成式 AI 應用程式的模型) 時，這點尤其重要。

  • 在整個機器學習運作生命週期中，實施主動做法，找出並減少偏誤。
  • 使用相關工具分析訓練資料的偏誤，偵測不同客層或敏感屬性特徵分布的偏斜。
  • 評估整體模型效能，以及預先定義的資料片段效能。這類評估有助於找出影響特定子群體的成效差異或偏誤。

如要提高模型透明度和可解釋性，請使用相關工具，協助使用者和開發人員瞭解模型做出特定預測或產生特定輸出內容的原因。

  • 如要為部署在 Vertex AI 端點的表格模型產生特徵歸因，請使用 Vertex Explainable AI。特徵歸因會指出對預測結果影響最大的輸入特徵。
  • 使用與模型無關的工具 (例如與 TensorBoard 整合的 What-If Tool)，以互動方式探索資料集的模型行為和潛在偏誤。
  • 將可解釋性整合至監控資訊主頁。在需要瞭解模型推理過程的情況下，請透過應用程式介面直接向使用者提供可解釋性資料，以建立信任感或輔助決策。
  • 如果是用於生成式 AI 模型的 LLM 等複雜模型，請說明代理程式執行的程序，例如使用追蹤記錄。這類模型的可解釋性相對較難，但仍至關重要。
  • 在 RAG 應用程式中，請提供擷取資訊的引文。您也可以使用提示工程等技巧，引導模型提供說明或顯示推論步驟。
  • 在實際工作環境中持續監控，偵測模型行為或輸出內容的變化，這可能表示出現偏誤或不公平的情況。文件模型限制、預期用途和已知潛在偏誤，這些資訊會列在模型登錄的模型中繼資料中。

全面實施 AI 和機器學習觀測與可靠性做法

在實際運作環境中管理複雜的 AI 和機器學習系統時，全方位可觀測性至關重要。此外，由於複雜的 AI 和 ML 系統 (尤其是生成式 AI) 複雜度高、耗用大量資源，且可能產生無法預測的輸出內容，因此評估這類系統的可靠性也至關重要。全方位觀測包括觀察基礎架構、應用程式碼、資料和模型行為，以取得洞察資料，主動偵測、診斷及回應問題。這種可觀測性最終會帶來高效能的可靠系統。如要實現全方位觀測能力，請採取下列做法：

  • 採用 SRE 原則。
  • 定義明確的可靠性目標。
  • 追蹤系統層級的指標。
  • 運用觀測資料的洞察資訊，持續改善及主動管理。

如要在 Google Cloud中為 AI 和機器學習工作負載導入全方位的觀測和可靠性做法，請考慮下列建議。

制定可靠性目標和業務指標

找出 AI 和 ML 系統直接影響的主要成效指標 (KPI)。這些 KPI 可能包括受 AI 建議影響的收益、AI 系統預測或降低的顧客流失率，以及生成式 AI 功能帶動的使用者參與度和轉換率。

為各個 KPI 定義相應的技術可靠性指標，這些指標會影響 KPI。舉例來說，如果 KPI 是「顧客對對話式 AI 助理的滿意度」，則對應的可靠性指標可能包括：

  • 使用者要求的成功率。
  • 回覆延遲時間：LLM 的第一個權杖時間 (TTFT) 和權杖串流。
  • 不相關或有害的回覆率。
  • 服務專員成功完成工作的比率。

對於 AI 和 ML 訓練，可靠性指標可能包括模型 FLOPS 使用率 (MFU)、每秒疊代次數、每秒權杖數，以及每個裝置的權杖數。

如要有效評估及提升 AI 和機器學習的可靠性，請先設定明確的可靠性目標，並與整體業務目標保持一致。採用 SRE 方法，從使用者角度定義 SLO，量化 AI 和 ML 服務可接受的可靠性和效能等級。使用特定 SLO 目標量化這些技術可靠性指標。

以下是 SLO 目標的範例：

  • 99.9% 的 API 呼叫必須傳回成功的回應。
  • 第 95 個百分位數的推論延遲時間必須低於 300 毫秒。
  • 99% 的要求 TTFT 必須低於 500 毫秒。
  • 有害輸出內容的比例必須低於 0.1%。

直接根據業務需求調整 SLO，可確保可靠性工作著重於影響使用者和業務的最重要系統行為。這個方法有助於將可靠性轉化為可評估且可執行的工程屬性。

監控基礎架構和應用程式效能

追蹤 AI 和機器學習系統使用的所有資源基礎架構指標。這些指標包括處理器用量 (CPU、GPU 和 TPU)、記憶體用量、網路處理量和延遲時間，以及磁碟 I/O。追蹤代管環境 (例如 Vertex AI 訓練和服務) 的指標，以及自行管理的資源 (例如 GKE 節點和 Cloud Run 執行個體) 的指標。

監控 AI 和機器學習應用程式的四大黃金信號：

  • 延遲：回應要求所需的時間。
  • 流量：要求或工作負載量。
  • 錯誤率：要求或作業失敗的比率。
  • 飽和度：CPU、記憶體和 GPU/TPU 加速器等重要資源的使用率，可指出系統距離容量上限有多近。

請使用下列技術執行監控作業：

  • 使用 Cloud Monitoring 收集、儲存及顯示基礎架構和應用程式指標。您可以針對 Google Cloud 服務使用預先建構的資訊主頁，並根據工作負載的特定效能指標和基礎架構健康狀態，建立專屬的自訂資訊主頁。
  • 使用 Cloud Logging，從 AI 和 ML 應用程式以及基礎架構收集詳細記錄。這些記錄對於疑難排解和效能分析至關重要。這些資料可提供事件和錯誤的相關背景資訊。
  • 使用 Cloud Trace 找出延遲問題，並瞭解分散式 AI 和 ML 微服務的要求流程。這項功能對於偵錯複雜的 Vertex AI Agents 互動或多元件推論管道至關重要。
  • 使用 Cloud Profiler 找出應用程式程式碼中函式區塊的效能瓶頸。找出效能瓶頸有助於最佳化資源用量和執行時間。
  • 使用 NVIDIA Data Center GPU Manager (DCGM) 等工具，收集特定加速器相關指標，例如每個程序的詳細 GPU 使用率、每個程序的記憶體用量和溫度。

導入資料和模型觀測功能

如要打造可靠的生成式 AI 系統，必須具備完善的資料和模型可觀測性，而這一切都從端對端管道監控開始。

  • 使用 Dataflow 等服務，追蹤資料擷取率、處理量和轉換延遲時間。
  • 監控 MLOps 管道中的工作成功和失敗率，包括由 Vertex AI Pipelines 管理的管道。

持續評估資料品質至關重要。

  • 使用 Dataplex Universal Catalog 管理及控管資料：
    • 根據真值驗證或追蹤離群值偵測率，評估準確度。
    • 根據資料的時效和更新頻率，對照服務水準協議監控資料更新間隔。
    • 追蹤空值百分比和必填欄位的填寫率，評估完整性。
    • 檢查是否符合結構定義和重複，確保有效性和一致性。
  • 透過 Cloud Monitoring 快訊主動偵測異常狀況，並運用清楚的資料沿襲追蹤資料。
  • 如果是 RAG 系統，請檢查檢索脈絡的關聯性，以及回覆的根據 (歸因於來源)。
  • 監控向量資料庫查詢的處理量。

重要的模型可觀測性指標包括輸入/輸出權杖計數，以及模型專屬的錯誤率，例如產生幻覺或查詢解析失敗。如要追蹤這些指標，請使用模型監控。

  • 持續監控輸出內容的惡意指數和使用者意見回饋評分。
  • 使用 Gen AI Evaluation Service，根據定義的標準自動評估模型輸出內容。
  • 透過完整的錯誤率指標，有系統地監控資料和概念漂移，確保效能穩定。

如要追蹤模型指標，可以使用 TensorBoard 或 MLflow。如要深入分析及剖析，以排解效能問題，可以使用 PyTorch XLA 剖析或 NVIDIA Nsight。

貢獻者

作者：

  • 陳瑞貴 | AI 基礎架構現場解決方案架構師
  • Stef Ruinard | 生成式 AI 現場解決方案架構師

其他貢獻者：

上一頁
安全性
下一頁
成本最佳化