使用Amazon Bedrock和LLM閘道器實現韌性模式

隨著生成式AI工作負載從實驗階段進入大規模生產，實現大語言模型（LLM）推斷的韌性模式變得至關重要。基於LLM的應用現已投入生產，組織需要確保LLM推斷在高負載下保持高可用性、響應性和成本效益。現有的韌性最佳實踐（如靜態穩定性和實現退避與重試）仍然適用。然而，生成式AI引入了新的考量因素，包括模型可用性、快速變化的配額、跨多個提供商的令牌限制，以及保持與新發布模型的一致性。Amazon Bedrock提供了完全託管的基礎模型，並具備跨區域推斷等內建韌性特性。

在生產環境中設計推斷時，通常有四個維度指導架構決策：可用性、響應時間、成本和吞吐量。可用性指的是在模型、區域或提供商中斷期間維持推斷的能力。響應時間涵蓋使用者接收輸出的速度，通常以首令牌時間（TTFT）和尾令牌時間（TTLT）衡量。成本捕捉每令牌和每請求的支出，以及路由決策如何影響它。吞吐量反映系統在負載下能維持的併發請求和每秒令牌數。

這些維度相互關聯。例如，跨區域路由提高了可用性和吞吐量，但可能增加響應時間。本文中的模式主要關注可用性：透過故障轉移、地理分佈和配額隔離來保持推斷執行。未來的文章將深入探討響應時間最佳化和成本感知路由。

在本文中，您將學習五種實用的韌性模式，用於在AWS上構建韌性生成式AI應用，從原生Amazon Bedrock功能發展到使用LLM閘道器的多模型編排。這些模式解決了實際挑戰，如意外流量激增時的配額耗盡、透過推斷地理分佈最大化可用性，以及幫助防止多租戶環境中的噪聲鄰居問題。它們還透過智慧請求路由支援成本最佳化，並根據您的具體要求提供使用多個模型和提供商的靈活性。

這種爬行、行走、跑步的方法使您可以根據應用的成熟度和需求增量採用這些模式。隨附的GitHub倉庫提供了演示每種模式的程式碼示例。

推斷韌性模式的增量方法

您可以透過使用GitHub倉庫本節中的程式碼示例和說明，在您自己的環境中測試以下每種模式。

先決條件

在開始演示之前，請確認您已安裝適當的軟體並正確配置了AWS賬戶。

注意：遵循本文中的模式將建立和使用AWS資源，併產生費用，包括Amazon Bedrock推斷請求和Amazon CloudWatch日誌。請參閱清理部分以避免測試後持續產生費用。

模式1：使用Amazon Bedrock跨區域推斷

Amazon Bedrock跨區域推斷（CRIS）是一項原生功能，預設提供韌性推斷的基礎。您可以使用跨區域推斷配置檔案來提高吞吐量，降低在AWS區域內被限制的可能性，並分佈模型流量。CRIS消除了手動管理流量分佈的工作，提高了應用的可用性。它基於可用性、延遲和當前需求等即時因素，自動將請求從源區域路由到最佳目標區域。這考慮了高峰使用期間的意外流量激增，並減少了服務配額影響推斷的可能性。

CRIS配置檔案通常繫結到特定地理區域（如美國或歐盟）內的商業區域，為推斷請求提供了效能和延遲的良好平衡。這種方法在保持資料駐地在地理邊界內的同時，增加了超過單區域配額的總體吞吐量。

對於可以容忍推斷請求更高延遲的某些用例，可以選擇使用全球跨區域推斷配置檔案。使用全球配置檔案時，請求可以路由到模型可用的多個商業區域進行全球推斷，從而提供比標準跨區域推斷配置檔案更大的吞吐量。

例如，在我們的演示中，向使用跨區域推斷配置檔案的Amazon Bedrock傳送10個請求時，命令輸出顯示CRIS自動將模型推斷分佈在3個AWS區域：

| 區域 | 呼叫次數 | 百分比 | |------|----------|--------| | us-east-1 | 1 | 10% | | us-east-2 | 7 | 70% | | us-west-2 | 2 | 20% |

模式2：使用多個AWS賬戶

雖然CRIS在單個AWS賬戶內倍增了吞吐量，但您可以從額外的擴充套件和隔離策略中受益。AWS賬戶分片將請求分佈在多個AWS賬戶之間，每個賬戶具有獨立的配額和CRIS配置檔案。

賬戶分片建立了自然的故障隔離邊界，一個賬戶的問題不會影響其他賬戶，這對於需要嚴格工作負載隔離的多團隊和多租戶架構特別有價值。

在執行賬戶分片演示時，我們向兩個配置的AWS賬戶各傳送10個請求，使用跨區域推斷配置檔案。輸出顯示了每個賬戶如何獨立地在AWS區域之間分佈推斷：

賬戶1 | 區域 | 呼叫次數 | 百分比 | |------|----------|--------| | us-east-2 | 7 | 70% | | us-west-2 | 3 | 30% |

賬戶2 | 區域 | 呼叫次數 | 百分比 | |------|----------|--------| | us-east-1 | 2 | 20% | | us-east-2 | 3 | 30% | | us-west-2 | 5 | 50% |

使用LLM閘道器

對於複雜的生產場景，LLM閘道器提供了超出直接API呼叫能力的路由、故障轉移和治理功能。閘道器作為應用和LLM提供商之間的智慧代理，提供統一的抽象層，使您可以透過單個API介面訪問多個供應商的多種模型。這種標準化簡化了整合，同時嵌入了負責任AI保障、審計日誌、自動重試和回退邏輯、配額管理等功能，幫助您的應用在單個模型不可用時仍保持韌性。

閘道器支援跨多個模型和賬戶的智慧請求路由和負載均衡，透過每消費者隔離的速率限制和配額管理最大化吞吐量，防止多租戶環境中的噪聲鄰居問題。它還透過使用分析提供全面的成本跟蹤和最佳化。集中式可觀測性和監控使您能夠全面瞭解LLM使用模式，提供細粒度的每應用洞察，幫助快速識別最佳化機會和排查問題。

目前有多種開源和商業LLM閘道器可用。在我們的演示中，我們使用LiteLLM作為輕量級開源選項本地執行，以演示這些模式。在規模部署時，AWS多提供商生成式AI閘道器解決方案提供了參考實現和架構，也使用LiteLLM，但增加了企業功能，包括在Amazon Elastic Container Service（Amazon ECS）或Amazon Elastic Kubernetes Service（Amazon EKS）上的容器化部署、自動擴充套件、AWS WAF保護、金鑰管理和透過Amazon CloudWatch的全面可觀測性。

模式3：模型故障轉移

模型間的自動故障轉移支援更高的可用性，即使主模型達到速率限制或遇到服務中斷。此模式設計為在客戶定義的主模型和輔助模型之間自動路由請求。如果您的故障轉移策略側重於最佳化質量和成本而非配額耗盡，Amazon Bedrock智慧提示路由提供了原生選項。它在不需要外部閘道器的情況下動態選擇每個請求最合適的模型。如果對主模型的呼叫失敗，閘道器自動使用輔助模型重試請求，即使在意外流量高峰期間也支援高可用性。故障轉移策略還結合了成本最佳化和效能考慮，例如，限制高成本模型並在適當時回退到更具成本效益的替代方案。

在我們的演示中，LiteLLM配置定義了一個主模型，具有每分鐘3個請求（RPM）的限制性速率限制，以及一個具有更高容量（25 RPM）的故障轉移模型。當客戶端透過閘道器傳送10個併發請求時，前三個請求路由到Amazon Bedrock中的主模型。當主模型達到速率限制時，LiteLLM自動將剩餘的七個請求轉向故障轉移模型。10個請求成功完成，無需手動干預或應用級重試邏輯。

演示輸出確認了此模式的有效性，顯示儘管主模型有速率限制，但10個請求成功完成。分佈顯示恰好3個請求在主模型達到配額前被處理。其餘7個請求故障轉移到故障轉移模型，展示了閘道器透過智慧路由維持服務可用性的能力。

模式4：跨模型負載均衡

負載均衡模式將請求分佈到多個模型例項，以最佳化資源利用並幫助防止瓶頸。這種方法不僅最大化利用率，還允許您根據需要快速新增或刪除模型例項。例如，在評估新模型但未完全部署時，您可以實施加權路由或A/B測試策略，僅將一小部分請求定向到新模型，而大部分繼續使用經過驗證的模型。

在我們的負載均衡演示中，閘道器成功使用混洗策略將10個併發請求分佈到兩個模型。負載均衡器最初將3個請求路由到每個配置的主模型，當達到速率限制時，剩餘的4個請求自動重定向到故障轉移模型。結果是100%的成功率，展示了負載均衡如何與故障轉移策略協同工作。

模式5：多租戶配額隔離

多租戶配額隔離模式建立了邏輯隔離的環境，每個環境具有自己的配額和速率限制，用於管理多租戶環境中的請求。透過為每個消費者實施獨立的速率限制桶，此模式有助於防止“噪聲鄰居”問題，其中一個消費者的請求會對其他消費者的效能產生負面影響。每個租戶獲得專用配額，不受其他租戶使用模式的影響，支援公平的資源分配，並保持跨消費者的一致服務質量。

此模式非常適合多個應用共享模型資源的環境。