優化AWS上生成式AI應用的成本

麥肯錫公司 (McKinsey & Company) 發表的報告《生成式人工智慧的經濟潛力：下一個生產力邊界》估計，生成式人工智慧可能為全球經濟增加相當於 2.6 兆到 4.4 兆美元的價值。最大的價值將在四個領域中產生：客戶運營、行銷與銷售、軟體工程以及研究與開發。

這種龐大的商業價值潛力激勵了成千上萬的企業在 AWS 上建立他們的生成式人工智慧應用程式。然而，許多產品經理和企業架構師希望更好地了解成本、成本優化的手段以及敏感度分析。

這篇文章將討論這些成本考量，以便您能在 AWS 上優化生成式人工智慧的成本。

這篇文章假設讀者對基礎模型 (FMs) 和大型語言模型 (LLMs)、標記、向量嵌入以及 AWS 中的向量資料庫有基本的了解。檢索增強生成 (RAG) 是生成式人工智慧解決方案中最常用的框架之一，這篇文章將在 RAG 解決方案的背景下解釋成本及其優化要素。

在本系列的第二部分，我們將討論如何估算商業價值及其影響因素。

成本與性能優化要素

設計高效且具成本效益的生成式人工智慧應用程式對於實現這項變革性技術的全部潛力以及推動其在組織內的廣泛採用至關重要。

在生成式人工智慧應用程式中預測和管理成本及性能是由以下優化要素驅動的：

模型選擇、選擇和自定義 – 我們將其定義如下：

模型選擇 – 此過程涉及識別滿足各種使用案例的最佳模型，然後進行模型驗證，通過高質量的數據集和提示進行基準測試，以確定成功的模型候選者。
模型選擇 – 這是指選擇合適的模型，因為不同模型的定價和性能特徵各不相同。
模型自定義 – 這是指選擇合適的技術，使用訓練數據自定義基礎模型，以根據特定的商業使用案例優化性能和成本效益。

標記使用 – 分析標記使用包括以下幾點：

標記數量 – 使用生成式人工智慧模型的成本取決於處理的標記數量。這會直接影響操作的成本。
標記限制 – 了解標記限制以及驅動標記數量的因素，並設置防護措施以限制標記數量，可以幫助您優化標記成本和性能。
標記緩存 – 在應用層或大型語言模型層對常見用戶問題進行緩存可以幫助減少標記數量並提高性能。

推論定價計劃和使用模式 – 我們考慮兩種定價選項：

按需 – 適合大多數模型，根據輸入/輸出標記的數量收費，沒有保證的標記通量。
預配置通量 – 適合需要保證通量的工作負載，但成本相對較高。

其他因素 – 附加因素可能包括：

安全防護措施 – 應用內容過濾器以過濾個人識別信息 (PII)、有害內容、不受歡迎的主題以及檢測幻覺，可以提高您的生成式人工智慧應用程式的安全性。這些過濾器的性能和擴展性獨立於大型語言模型，並且其成本與過濾器的數量和檢查的標記數量成正比。
向量資料庫 – 向量資料庫是大多數生成式人工智慧應用程式的關鍵組件。隨著生成式人工智慧應用程式中數據使用量的增加，向量資料庫的成本也會增加。
分塊策略 – 固定大小分塊、層次分塊或語義分塊等分塊策略可以影響生成式人工智慧應用程式的準確性和成本。

讓我們深入探討這些因素和相關的成本優化建議。

檢索增強生成

RAG 幫助大型語言模型回答與您公司數據相關的問題，即使該大型語言模型從未在您的數據上進行過訓練。

如以下圖示所示，生成式人工智慧應用程式會讀取您公司的可信數據來源，將其分塊，生成向量嵌入，並將嵌入存儲在向量資料庫中。存儲在向量資料庫中的向量和數據通常稱為知識庫。

生成式人工智慧應用程式使用向量嵌入來搜索和檢索與用戶問題最相關的數據塊，並增強問題以生成大型語言模型的回應。以下圖示說明了這一工作流程。

該工作流程包括以下步驟：

用戶使用生成式人工智慧應用程式提出問題。
生成嵌入的請求發送到大型語言模型。
大型語言模型將嵌入返回給應用程式。
這些嵌入與存儲在向量資料庫（知識庫）中的向量嵌入進行搜索。
應用程式從知識庫接收與用戶問題相關的上下文。
應用程式將用戶問題和上下文發送給大型語言模型。
大型語言模型使用上下文生成準確且有根據的回應。
應用程式將最終回應發送回用戶。

Amazon Bedrock 是一項完全管理的服務，通過統一的 API 提供來自領先 AI 供應商的高性能基礎模型。它提供多種大型語言模型供選擇。

在前述工作流程中，生成式人工智慧應用程式調用 Amazon Bedrock API，將文本發送到像 Amazon Titan Embeddings V2 的大型語言模型以生成文本嵌入，並將提示發送到像 Anthropic 的 Claude Haiku 或 Meta 的 Llama 的大型語言模型以生成回應。

生成的文本嵌入存儲在向量資料庫中，例如 Amazon OpenSearch Service、Amazon Relational Database Service (Amazon RDS)、Amazon Aurora 或 Amazon MemoryDB。

像虛擬助手或支持聊天機器人這樣的生成式人工智慧應用程式可能需要與用戶進行對話。一個多輪對話需要應用程式存儲每個用戶的問題-回應歷史，並將其發送給大型語言模型以獲取額外的上下文。這些問題-回應歷史可以存儲在像 Amazon DynamoDB 的資料庫中。

生成式人工智慧應用程式還可以使用 Amazon Bedrock Guardrails 來檢測偏題問題，將回應基於知識庫進行驗證，檢測和刪除個人識別信息，並檢測和阻止與仇恨或暴力相關的問題和回答。

現在我們對基於 RAG 的生成式人工智慧應用程式中的各種組件有了良好的理解，讓我們探索這些因素如何影響在 AWS 上運行應用程式的成本。

小型、中型、大型和超大型場景的方向性成本

考慮一個組織，希望幫助客戶使用虛擬助手隨時回答他們的問題，並且具有高準確性、性能、一致性和安全性。生成式人工智慧應用程式的性能和成本直接取決於環境中的幾個主要因素，例如每分鐘問題的速度、每天問題的數量（考慮高峰和非高峰時段）、知識庫數據的量以及使用的大型語言模型。

雖然這篇文章解釋了影響成本的因素，但了解基於一些假設的方向性成本，以獲得對小型、中型、大型和超大型環境的各種成本組件的相對理解是有用的。

以下表格是四種不同場景的方向性成本快照，這些場景的每月用戶問題數量和知識庫數據大小各不相同。

.
小型
中型
大型
超大型

輸入數量
500,000
2,000,000
5,000,000
7,020,000

每月總問題數
5
25
50
100

知識庫數據大小（GB，文件中的實際文本大小）
.
.
.
.

年度成本（方向性）*
.
.
.
.

使用 Anthropic 的 Claude 3 Haiku 的 Amazon Bedrock 按需成本
$5,785
$23,149
$57,725
$81,027

Amazon OpenSearch Service 預配置集群成本
$6,396
$13,520
$20,701
$39,640

Amazon Bedrock Titan Text Embedding v2 成本
$396
$5,826
$7,320
$13,585

總年度成本（方向性）
$12,577
$42,495
$85,746
$134,252

每 1,000 問題的單位成本（方向性）
$2.10
$1.80
$1.40
$1.60

這些成本是基於假設的。如果假設改變，成本會有所不同。成本估算會因每位客戶而異。本文中的數據不應用作報價，並且不保證實際使用 AWS 服務的成本。成本、限制和模型可能會隨著時間而改變。

為了簡潔起見，我們使用以下假設：

Amazon Bedrock 按需定價模型
Anthropic 的 Claude 3 Haiku 大型語言模型
AWS 區域 us-east-1
每個用戶問題的標記假設：

發送到大型語言模型的總輸入標記 = 2,571
從大型語言模型輸出的標記 = 149
每個標記平均四個字符
總標記 = 2,720

還有其他成本組件，例如 DynamoDB 用於存儲問題-回答歷史，Amazon Simple Storage Service (Amazon S3) 用於存儲數據，以及 AWS Lambda 或 Amazon Elastic Container Service (Amazon ECS) 用於調用 Amazon Bedrock API。然而，這些成本並不像表中提到的成本組件那樣重要。

我們在本文的其餘部分將參考此表格。在接下來的幾個部分中，我們將討論 Amazon Bedrock 成本及其影響成本的主要因素、向量嵌入成本、向量資料庫成本以及 Amazon Bedrock Guardrails 成本。在最後一部分，我們將討論分塊策略如何影響上述一些成本組件。

Amazon Bedrock 成本

Amazon Bedrock 有兩種定價模型：按需（在前面的示例場景中使用）和預配置通量。

在按需模型中，大型語言模型每分鐘的請求（問題）數量 (RPM) 和每分鐘的標記數量 (TPM) 有最大限制。每個大型語言模型的 RPM 和 TPM 通常不同。欲了解更多信息，請參見 Amazon Bedrock 的配額。

在超大型用例中，每月有 700 萬個問題，假設每天工作 10 小時，每月工作 22 天，這相當於每分鐘 532 個問題（532 RPM）。這遠低於 Anthropic 的 Claude 3 Haiku 的最大限制 1,000 RPM。

每個問題 2,720 個平均標記和每分鐘 532 個請求，TPM 為 2,720 x 532 = 1,447,040，這遠低於 Anthropic 的 Claude 3 Haiku 的最大限制 2,000,000 TPM。

但是，假設用戶問題增加 50%。RPM、TPM 或兩者都可能超過限制。在這種情況下，如果生成式人工智慧應用程式需要超過按需 RPM 和 TPM 限制，您應考慮 Amazon Bedrock 的預配置通量模型。

使用 Amazon Bedrock 的預配置通量，成本是基於每個模型單位的基礎。模型單位是根據您計劃使用的時間段專門分配的，例如每小時、1 個月或 6 個月的承諾。

每個模型單位提供每分鐘最大標記數量的某種容量。因此，模型單位的數量（以及成本）取決於輸入和輸出的 TPM。

使用 Amazon Bedrock 的預配置通量，無論您是否使用，都會對每個模型單位產生費用。因此，預配置通量模型的成本相對於按需模型較高。

考慮以下成本優化建議：

從按需模型開始，測試您選擇的大型語言模型的性能和延遲。這將提供最低的成本。
如果按需無法滿足所需的 RPM 或 TPM，則在生成式人工智慧應用程式的測試期間，開始使用預配置通量的 1 個月訂閱。然而，對於穩定的生產狀態，考慮 6 個月的訂閱以降低預配置通量的成本。
如果有較短的高峰時段和較長的非高峰時段，考慮在高峰時段使用預配置通量的每小時模型，而在非高峰時段使用按需。這可以最小化您的預配置通量成本。

影響成本的因素

在這一部分，我們將討論各種可能影響成本的因素。

問題數量

在按需模型中，隨著問題數量的增加，成本也會增加，這可以從以下圖表中看到年度成本（基於前面討論的表格）。

輸入標記

輸入到大型語言模型的主要標記來源是系統提示、用戶提示、來自向量資料庫（知識庫）的上下文以及來自問答歷史的上下文，如下圖所示。

隨著每個組件的大小增加，輸入到大型語言模型的標記數量也會增加，成本也會隨之增加。

一般來說，用戶提示相對較小。例如，在用戶提示「Amazon DynamoDB 的性能和成本優化策略是什麼？」中，假設每個標記四個字符，則大約有 20 個標記。

系統提示可能很大（因此成本較高），特別是對於多次提示，其中提供多個示例以獲得更好的語氣和風格的 LLM 回應。如果系統提示中的每個示例使用 100 個標記，並且有三個示例，那麼就是 300 個標記，這比實際的用戶提示要大得多。

來自知識庫的上下文往往是最大的。例如，當文件被分塊並為每個塊生成文本嵌入時，假設塊大小為 2,000 個字符。假設生成式人工智慧應用程式將三個與用戶提示相關的塊發送到大型語言模型。這是 6,000 個字符。假設每個標記四個字符，這相當於 1,500 個標記。這比典型的用戶提示或系統提示要高得多。

來自問答歷史的上下文也可能很高。假設用戶提示平均 20 個標記，LLM 回應 100 個標記。假設生成式人工智慧應用程式在每個問題中發送三組問題-回答對。這相當於（每個問題 20 個標記 + 每個回應 100 個標記）x 3 組問題-回答對 = 360 個標記。

考慮以下成本優化建議：

限制每個用戶提示的字符數
在最終確定向量資料庫的塊數量和塊大小之前，測試不同數量的塊和塊大小對回應準確性的影響
對於需要與用戶進行對話的生成式人工智慧應用程式，測試兩、三、四或五組問答歷史，然後選擇最佳值

輸出標記

大型語言模型的回應將取決於用戶提示。一般來說，輸出標記的定價是輸入標記的三到五倍。

考慮以下成本優化建議：

由於輸出標記成本高，考慮在系統提示中指定最大回應大小
如果某些用戶屬於需要更高標記限制的群組或部門，考慮使用多個系統提示，以便生成式人工智慧應用程式根據用戶選擇正確的系統提示

向量嵌入成本

如前所述，在 RAG 應用程式中，數據被分塊，並生成文本嵌入，然後存儲在向量資料庫（知識庫）中。文本嵌入是通過調用 Amazon Bedrock API 與大型語言模型（例如 Amazon Titan Text Embeddings V2）生成的。這與您選擇用於推理的 Amazon Bedrock 模型無關，例如 Anthropic 的 Claude Haiku 或其他大型語言模型。

生成文本嵌入的定價基於輸入標記的數量。數據越大，輸入標記越多，因此成本也越高。

例如，對於 25 GB 的數據，假設每個標記四個字符，輸入標記總數為 6,711 萬。使用 Amazon Titan Text Embeddings V2 的 Amazon Bedrock 按需成本為每百萬標記 $0.02，生成嵌入的成本為 $134.22。

然而，按需模型對於 Amazon Titan Text Embeddings V2 的 RPM 限制為 2,000。以 2,000 RPM 計算，嵌入 25 GB 的數據需要 112 小時。因為這是一個一次性的嵌入數據的工作，在大多數情況下這是可以接受的。

對於每月變更率和新數據的 5%（每月 1.25 GB），所需時間將為 6 小時。

在極少數情況下，如果實際文本數據非常高（以 TB 計算），則需要使用預配置通量來生成文本嵌入。例如，要在 3、6 和 9 天內生成 500 GB 的文本嵌入，使用預配置通量的成本將分別約為 $60,000、$33,000 或 $24,000 的一次性費用。

通常，文件中的實際文本大小是 Amazon S3 或文件系統報告的文件大小的 5 到 10 倍。因此，當您看到需要向量化的所有文件的大小為 100 GB 時，實際上文件中的文本大小很可能在 2 到 20 GB 之間。

估算文件內文本大小的一種方法如下：

選取 5 到 10 個文件的樣本表示。
打開文件，複製內容，並將其輸入到 Word 文檔中。
使用字數計數功能來識別文本大小。
計算此大小與文件系統報告大小的比率。
將此比率應用於整個文件系統，以獲得所有文件內實際文本大小的方向性估算。

向量資料庫成本

AWS 提供許多向量資料庫，例如 OpenSearch Service、Aurora、Amazon RDS 和 MemoryDB。如前所述，向量資料庫在基於向量嵌入存儲的企業數據中對回應進行驗證方面發揮著關鍵作用。

以下是影響向量資料庫成本的一些因素。為了簡潔起見，我們將 OpenSearch Service 的預配置集群視為向量資料庫。

用作知識庫的數據量 – 成本與數據大小成正比。數據越多，向量越多。向量越多，向量資料庫中的索引越多，這又需要更多的內存，因此成本更高。為了獲得最佳性能，建議將向量資料庫的大小設置為使所有向量都存儲在內存中。
索引壓縮 – 向量嵌入可以通過 HNSW 或 IVF 算法進行索引。索引也可以進行壓縮。雖然壓縮索引可以減少內存需求和成本，但可能會損失準確性。因此，在決定使用 HNSW 或 IVF 的壓縮變體之前，考慮進行廣泛的準確性測試。例如，對於 100 GB 的大型文本數據，假設塊大小為 2,000 字節，重疊 15%，向量維度數量為 512，沒有預付的 3 年保留實例，使用 HNSW 算法，預計成本為每年 $37,000。使用 hnsw-fp16 和 hnsw-pq 進行壓縮的相應成本分別為每年 $21,000 和 $10,000。
保留實例 – 成本與您保留存儲向量資料庫的集群實例的年數成反比。例如，在前述場景中，按需實例的成本約為每年 $75,000，沒有預付的 1 年保留實例的成本約為每年 $52,000，沒有預付的 3 年保留實例的成本約為每年 $37,000。

其他因素，例如從向量資料庫檢索的次數，這些檢索作為上下文傳遞給大型語言模型，也可能影響輸入標記，從而影響成本。但一般來說，前述因素是最重要的成本驅動因素。

Amazon Bedrock Guardrails

假設您的生成式人工智慧虛擬助手應該回答與您網站上產品相關的問題。您將如何避免用戶提出與科學、宗教、地理、政治或謎題等無關的問題？您如何避免對仇恨、暴力或種族相關的用戶問題做出回應？您如何檢測和刪除問題和回應中的個人識別信息？

Amazon Bedrock 的 ApplyGuardrail API 可以幫助您解決這些問題。Guardrails 提供多種政策，例如內容過濾器、禁止主題、上下文驗證檢查和敏感信息過濾器 (PII)。您可以選擇性地將這些過濾器應用於所有或特定部分的數據，例如用戶提示、系統提示、知識庫上下文和大型語言模型的回應。

將所有過濾器應用於所有數據將增加成本。因此，您應仔細評估要在數據的哪個部分應用哪些過濾器。例如，如果您希望檢測或刪除大型語言模型回應中的 PII，對於每月 200 萬個問題，預計成本（基於本文前面提到的輸出標記）將為每月 $200。此外，如果您的安全團隊希望檢測或刪除用戶問題中的 PII，則 Amazon Bedrock Guardrails 的總成本將為每月 $400。

分塊策略

如前所述，RAG 的工作原理是，您的數據被分塊，為這些塊生成嵌入，然後將這些塊和嵌入存儲在向量資料庫中。這些數據塊稍後被檢索並作為上下文與用戶問題一起傳遞給大型語言模型，以生成有根據且相關的回應。

以下是不同的分塊策略，每種策略都可能影響成本：

標準分塊 – 在這種情況下，您可以指定默認分塊，約為 300 個標記，或固定大小分塊，您為每個塊指定標記大小（例如 300 個標記）。較大的塊將增加輸入標記數量，因此成本也會增加。
層次分塊 – 當您希望以較小的大小（例如 300 個標記）分塊數據，但將較大的塊（例如 1,500 個標記）發送給大型語言模型，以便大型語言模型擁有更大的上下文來生成回應時，這種策略非常有用。雖然這在某些情況下可以提高準確性，但由於發送給大型語言模型的數據塊較大，這也可能增加成本。
語義分塊 – 當您希望根據語義意義而非僅僅是標記進行分塊時，這種策略非常有用。在這種情況下，為一到三個句子生成向量嵌入。使用滑動窗口考慮下一句，然後再次計算嵌入，以確定下一句是否語義相似。這個過程持續進行，直到達到標記的上限（例如 300 個標記）或找到一個不語義相似的句子。這個邊界定義了一個塊。輸入標記的成本將類似於標準分塊（基於最大標記大小），但準確性可能會更好，因為塊中的句子是語義相似的。然而，這將增加生成向量嵌入的成本，因為每個句子都生成嵌入，然後為每個塊生成嵌入。但同時，這些是一次性成本（對於新數據或變更數據），如果準確性相對較好，可能是值得的。
高級解析 – 這是您的分塊策略的可選前置步驟。這用於識別塊邊界，特別是在您擁有大量複雜數據（例如表格、圖像和文本）的文檔時。因此，成本將是您希望用於向量嵌入的整個數據的輸入和輸出標記成本。這些成本將很高。考慮僅對那些包含大量表格和圖像的文件使用高級解析。

以下表格是各種分塊策略的相對成本比較。

分塊策略
標準
語義
層次

相對推論成本
低
中
高

結論

在這篇文章中，我們討論了可能影響您生成式人工智慧應用程式成本的各種因素。這是一個快速發展的領域，我們提到的組件的成本可能會在未來發生變化。請將本文中的成本視為基於假設的時間快照，並且在方向上是準確的。如果您有任何問題，請聯繫您的 AWS 帳戶團隊。

在第二部分中，我們將討論如何計算商業價值及其影響因素。

關於作者

Vinnie Saini 是亞馬遜網路服務 (Amazon Web Services, AWS) 的資深生成式人工智慧專家解決方案架構師，駐加拿大多倫多。她擁有機器學習的背景，擁有超過 15 年的經驗，為各行各業的客戶設計和構建變革性的雲端解決方案。她的重點主要是擴展基於 AI/ML 的解決方案，以實現無與倫比的商業影響，並根據商業需求進行定制。

Chandra Reddy 是亞馬遜網路服務 (Amazon Web Services, AWS) 在德克薩斯州奧斯汀的解決方案架構師團隊的資深經理。他和他的團隊幫助北美的企業客戶解決他們在 AWS 上的 AIML 和生成式人工智慧用例。他在軟體工程、產品管理、產品行銷、商業發展和解決方案架構方面擁有超過 20 年的經驗。