使用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：多租户配額隔離

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

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