_如果您不是會員但想閱讀本文，請查看此朋友鏈接。 _
如果您一直在嘗試不同大小的開源模型，您可能想知道：部署它們的最高效方法是什麼？
按需付費和無服務器提供商之間的價格差異是多少，當存在 LLM 服務平台時，處理 AWS 這樣的參與者真的值得嗎？
我決定深入研究這個主題，將 AWS 等雲供應商與 Modal、BentoML、Replicate、Hugging Face 端點和 Beam 等更新的替代方案進行比較。
我們將研究處理時間、冷啟動延遲以及 CPU、內存和 GPU 成本等指標，以了解哪些最有效和經濟。我們還將涵蓋更軟的指標，例如部署的易用性、開發人員體驗和社區。
我們將探討一些用例，例如在 CPU 上部署較小的模型與在 GPU 上運行 7-80 億參數模型。
我還將深入研究在 AWS Lambda 中使用 EFS 部署較小模型的過程，並將其與 Modal 等更現代的平台進行比較。
我不會在這裡深入探討優化策略——例如使用不同的框架或量化來加快推理速度——這是一個完全獨立的主題。
相反，本文將重點介紹如何選擇正確的部署選項，讓您有機會比較不同場景下的性能，並幫助您了解部署小型和大型 LLM 的經濟成本。
當您使用現成的開源模型時，有很多易於使用的 API 選項。我建議查看此列表以了解一些選擇。您也可以選擇自託管——查看同一列表中的“本地推理”部分。
但是，您可能需要使用私有、微調或不太常見的模型。
您當然也可以在本地託管這些模型，但是您的計算機需要足夠的資源，而且您可能希望將這些模型集成到運行在另一台服務器上的應用程序中。
這將我們帶到按需或通過無服務器平台託管開源模型。其理念是，您只為使用的資源付費，無論是按需付費還是按運行付費，就像無服務器一樣。
無服務器和按需工作方式有點相似，但是對於無服務器，縮減規模的速度更快，因此您無需為閒置資源付費。
您可以查看下面的我的塗鴉以進行更多比較。
在本文中，我們將比較 AWS 的 EC2 和 Lambda 與幾個最近越來越受歡迎的新興平台的價格。
這樣，您就能更好地了解什麼最有效。
作為旁注，我沒有收到這些供應商的任何報酬，因此我在這里分享的信息是我的個人觀點。
如果您是利益相關者，這是一種很好的方法，可以了解不同選項的經濟性以及根據模型大小和供應商選擇運行推理的成本。
文章的第一部分涵蓋了研究，任何人都可以參與其中，而第二部分則介紹了您可能想要或可能不想閱讀的部署技術方面。
現在，在我們開始之前，我想對 LLM 推理框架發表一些評論，這些框架簡化了用於服務模型的 API 端點的設置。有幾個可用的開源 LLM 服務框架，包括 vLLM、TensorRT 和 TGI，我們可以在此處使用它們。
您可以在我之前共享的列表（如下所示）的“LLM 服務框架”部分中查看一些更流行的框架。
有些人已經測量了這些框架之間的性能差異，您絕對應該自己進行研究。
但是，在本文中，我們將使用 vLLM，它被廣泛使用——除非通過 Hugging Face 端點部署模型，這將自動為我們使用 TGI。
為了部署在 CPU 上運行的較小的轉換器模型，我只是直接使用了 Hugging Face pipeline 或 transformers 庫。
在第一部分中，我們將研究按需和無服務器選擇的效率、成本和性能。我們將首先介紹指標，然後再深入研究任何技術細節。
讓我們首先測量在容器處於預熱狀態（即在過去幾秒鐘內使用過）且沒有並發的情況下，跨平台的總處理時間。
我們將處理時間定義為完成響應所花費的總時間。 請注意，有些人可能會測量首次響應時間，尤其是在流式傳輸輸出時。
為保持一致性，我為每個測試使用了相同的提示。對於 400M 模型，我將文本批量處理為 30 個。
您可以看到下面的指標。
我只在同一天對每個平台運行了這些測試幾次。理想情況下，我應該在幾天內測試它們。對於其中一些測試，我可能不太走運。
但是，要討論它們的表現，對於****無服務器提供商，Modal 和 Beam 在 CPU 上表現非常好（顯示為淺綠色條）。啟動 400M 模型比啟動 8B 模型更容易。
我發現即使使用更小的模型（低於 130M）也能與 AWS Lambda 配合使用，尤其是在使用 EFS 緩存模型時。
雖然我真的很喜歡 Hugging Face 端點，但我發現它們的 CPU 實例有點不可預測。但是，它們的 AWS GPU 實例非常可靠且速度很快。
即使在L4 實例上託管7B 模型，我也可以在GPU 上獲得非常快速的響應，可以在10 秒內返迴響應——這是我們無法使用無服務器提供商實現的，無服務器提供商需要更強大的GPU。
如果我們選擇 A100 GPU，我們會看到所有提供商對於 7B-8B 參數模型都表現非常好，可以在幾秒鐘內返回完整的響應。
當然，速度很快，但我們還需要考慮其他指標。
接下來，讓我們深入研究冷啟動，即如果一段時間未使用模型，它需要多長時間才能響應。即使您緩存模型，它可能仍然需要下載分片，這可能會增加幾秒鐘。
按需服務可能允許您緩存模型以加快啟動時間，我沒有在這裡執行此操作，但是大多數無服務器提供商都會向您展示如何在構建時緩存模型，這可以減少冷啟動延遲。
讓我們看看下面幾個平台的指標。
請注意，我在冷啟動時計算了整個處理時間，請務必直接檢查僅冷啟動的計算。
正如預期的那樣，我沒有緩存模型的按需服務表現較差，例如 BentoML、Hugging Face 端點和 Baseten。
雖然 Hugging Face 端點在運行後可以表現良好，但您仍然可能會遇到持續 30 秒到 5 分鐘的冷啟動，如果您需要經常擴展和縮減規模，這可能會成為問題。在容器完全再次運行之前，它們還會拋出 500 錯誤。
無服務器提供商速度更快，因為它們旨在通過要求我們在首次部署時緩存模型權重來快速擴展。
在 CPU 上，Beam 表現最好，其次是 Baseten、Modal 和帶有 EFS 的 Lambda。較小的模型通常啟動速度更快。對於僅具有 125M 參數的小型模型使用 Lambda 顯示了出色的結果，處理時間快，冷啟動延遲最小。
儘管我認為對於較小的模型使用 Modal 或 Beam 也很好。
讓我們轉向定價。我們需要查看 CPU、內存和 GPU 資源的成本。
平台之間存在一些明顯的差異。
無服務器提供商通常更昂貴，因為它們除了 GPU 使用之外還會收取 CPU 和內存費用。但是，它們不會向您收取閒置時間的費用，這可以幫助抵消更高的成本。
您可以在下圖中找到 Nvidia GPU 的價格。
但是，您應該查看 SageMaker，它在所有這些中擁有最高的 GPU 成本。如果您需要使用 AWS，最好直接使用 EC2。
讓我們也看看 CPU 定價。
Hugging Face 端點以 0.07 美元的價格領先，該實例具有 2 個 vCPU 和 4GB 內存，可惜的是它們的 CPU 實例表現不佳。
Beam 和 Modal 允許您調整所需的資源，這有助於最大限度地降低成本。對於 400M 模型，我計算出在這兩個平台上只需要 3GB 內存和 1 個核心（2 個 vCPU）。
另一方面，Replicate 強制我們使用 4 個 vCPU，而不管模型大小如何，這使其成為此處最昂貴的 CPU 選項。
我們將介紹一些用例，以比較所有這些平台的價格和效率。
第一個案例將是全天零星地運行 400M 模型。這意味著每次調用容器都需要擴展和縮減規模。
並非總是需要擴展和縮減規模，但我們將不得不將其計算在內。
我通過為每個調用批量處理 30 個文本（使用較小的微調模型）來運行此案例研究，全天進行 250 次調用。 為簡便起見，我們假設每次運行容器時容器都是冷啟動的（Hugging Face 端點除外）。
無服務器提供商在這裡是一個更好的選擇，因為我們不會像按需付費那樣為閒置時間付費。對於 BentoML，我們需要在自動縮減規模之前至少保持空閒 5 分鐘，而對於 HF 端點，則需要等待 15 分鐘。
旁注，如果您不熟悉自動縮減規模，這個概念意味著如果允許，我們會告訴平台自動縮減我們的實例規模。
它們都有不同的要求，Baseten 和 HF 端點有 15 分鐘的空閒窗口，而 BentoML 有 5 分鐘。
由於 HF 端點至少需要 15 分鐘才能縮減規模，如果我們每 5-6 分鐘調用一次函數，它將沒有時間縮減規模，因此我們的冷啟動次數很少，但大部分時間都是空閒的。
我們可以看到，像 HF 案例那樣有 17 小時的空閒時間，以及 BentoML 案例中的 18 小時，本質上是低效的。我們將支付大部分資金用於全天的閒置資源。
一分錢或一美元在這里和那裡對於您最初的幾天來說似乎並不多，但過一段時間後就會累積起來。
想想人們每天在儲蓄賬戶中節省一點錢——這裡的過度支付將是相反的。
但是，如果我們在容器處於預熱狀態時運行所有 250 次調用呢？成本會有多大差異？
Beam 似乎在這裡是一個異常值，但我認為它們正在運行超過其他平台不允許您使用的最大 CPU。
在這種情況下，冷啟動和空閒時間消失了。這表明，如果您一次性處理所有內容，則使用持久性容器是更好的選擇——它便宜得多。
值得注意的是，對於 Hugging Face 端點和 BentoML，400M 模型最適合 T4 GPU。此設置可降低成本，同時顯著減少處理時間。
需要注意的一點是：如果您使用帶有 EFS 的 AWS Lambda，則會為 NAT 網關產生額外費用，每天可能增加 1 到 3 美元，這會使總成本比這裡顯示的更高。
現在，讓我們繼續第二個案例——在 GPU 上運行 7B 到 8B 參數的較大模型。
對於這種情況，我一直在測試 Mistral、Gemma 或 Llama 等大小約為 7B-8B 的模型。
該場景涉及全天零星地調用模型 250 次。我們假設容器在每次調用時都會擴展和縮減規模，儘管情況並非總是如此。
就像 CPU 測試一樣，我們假設按需服務運行 24 小時，因為它沒有時間縮減規模。
我已經確保寫出了我們為每個供應商使用的 GPU 實例。請查看下面的條形圖。
對於無服務器提供商，我已經通過乘法稍微誇大了處理時間，但從總價格計算中排除了冷啟動。
雖然實際成本可能更低，但這項調整是為了謹慎起見。您可能會被收取更多費用，因為您將為一些啟動支付費用。
就像我們在 CPU 案例中看到的那樣，一次運行 250 次調用更經濟高效。
如果您要設置 Anthropic 和 OpenAI 最便宜模型的計算，並將它們與自託管的成本進行比較，您會發現使用相同的提示調用它們的模型的費用比您這樣託管要少得多。
人們稱這些供應商為 LLM 的麥當勞。
我們認為開源會更便宜，但我們沒有計算託管的實際單位經濟性。這些平台也由風險投資資金補貼。但是，就像我之前提到的那樣，使用您可以在此處找到的供應商訪問開源模型的方法更便宜。
如果您想深入研究詳細的計算，您可以查看此文件。公平警告——它看起來有點混亂。
到目前為止，您可能已經得出自己的結論，但我最後想介紹的一件事是用戶體驗。
如果您不是編碼人員，那麼 HF 端點非常易於使用，因為您可以簡單地單擊即可從 HuggingFace 中心部署模型。如果您懂一些技術，您可能更喜歡您可以更多控制的其他選項。
對於 Replicate，它們擁有龐大的粉絲群和許多由不同人共享的公共模型。周圍有社區。他們有一些一鍵式訓練和部署流程，使操作更容易。
但是，我發現 Modal、Beam 和 BentoML 總體上具有良好的開發人員體驗。您可以直接通過終端進行部署，並讓代碼在其服務器上運行。
對於 Replicate，如果您要部署自己的模型，您將需要一台 GPU 機器，而對於 Baseten，您需要下載一個名為 Truss 的庫，這需要一些時間。
我在此表中收集了一些我的筆記（如下所示）。
如果您熱衷於使用任何這些，該表還將包含開始腳本的鏈接。
現在我們已經涵蓋了大部分非技術方面，我將引導您完成兩個用於在 CPU 上表現良好的模型的部署選項，AWS Lambda 和 Modal。
在本節中，我們將介紹如何使用 AWS Lambda 和 EFS 部署我為關鍵字提取而微調的 400M 模型，並將其與在 Modal 等更新的平台上的部署進行比較。
這兩個工具都是無服務器的，這意味著我們需要在構建時正確緩存模型，以便我們可以在連續運行中快速訪問它。 AWS 提供了一個現成的腳本，我們可以輕鬆地對其進行調整，我還在這里為 Modal 準備了一個腳本。
我們將重點關注兩件事：如何在每個平台上部署模型以及反映部署過程中的關鍵差異。
對於這部分，您可以通讀它或跟隨它進行部署。
要跟隨它，您需要在您的計算機上安裝 git、AWS CDK、Docker、NodeJS 18 、Python 3.9 。安裝完所有這些後，您可以打開一個新的終端。
如果您想創建一個新目錄，然後克隆下面的存儲庫。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
進入已創建的目錄。
<code>cd zero-administration-inference-with-aws-lambda-for-hugging-face</code>
您現在可以在您的代碼編輯器中打開這些文件。
我使用 VSCode，所以我這樣做。
<code>.code</code>
現在我們可以進入已創建的文件並對其進行一些調整。查看 Inference 文件夾，您將看到兩個文件，sentiment.py 和 summarization.py。
我們可以輕鬆地將這些文件中的模型更改為我們想要的模型。
如果您轉到 HuggingFace 中心並找到您感興趣的模型。
我將使用我自己的一個模型。
如果您有興趣了解如何構建這樣的模型，您可以查看此處的關鍵字提取教程和文本分類教程。
找到您感興趣的模型後，您可以單擊“使用此模型”按鈕。
正如您所看到的，我們在這裡有兩個選擇，但由於此腳本正在使用 pipeline，我們也可以這樣做。
我已經使用我通常使用的新的模型更改了以下文件中的代碼，同時還期望“texts”用於批量處理，而不僅僅是“text”。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
您可以查看上圖以查看文件結構。
我使用我通常使用的不同模型更改了這兩個腳本。完成操作後，請確保保存腳本。
然後，您可以在終端中設置虛擬環境。
<code>cd zero-administration-inference-with-aws-lambda-for-hugging-face</code>
在下載需求之前，請確保您擁有 NodeJS 18。
<code>.code</code>
在您可以執行任何其他操作之前，您需要確保您使用 AWS CDK 配置的用戶具有正確的權限。
<code># inference/summarization.py
import json
from transformers import pipeline
extractor = pipeline("text2text-generation", model="ilsilfverskiold/tech-keywords-extractor")
def handler(event, context):
# texts should be an array
texts = event['texts']
response = {
"statusCode": 200,
"body": extractor(texts)[0]
}
return response</code>之後，您可以運行 bootstrap。
<code>python3 -m venv venv source venv/bin/activate</code>
如果您在此處遇到有關 ECR 的問題，請手動創建存儲庫。
如果您在計算機上運行 Docker，您現在可以通過終端進行部署。
<code>pip install -r requirements.txt</code>
從這裡開始，CDK 使用 inference 文件夾中的 Dockerfile 開始為 Lambda 函數構建 Docker 映像。每個 Lambda 函數都配備了8 GB 內存和600 秒超時。
它將創建一個具有Internet 網關、用於緩存模型的EFS、幾個基於Docker 的Lambda 函數（用於託管腳本中的兩個模型）以及幾個用於Lambda 執行的IAM 角色的VPC。
這將需要一些時間。
我當時正在意大利的一個小村莊里做這件事，所以我的互聯網連接失敗了，我不得不租用一台 GPU 機器來進行部署。
這可能不會發生在您身上，但請確保您有足夠的資源和穩定的互聯網連接來進行部署。
部署完成後，您可以轉到 AWS 控制台中的 Lambda，並查找您的新函數。您可以在那裡直接測試它們。第一次運行會比較慢，但一旦預熱，速度就會快一些。
這裡有一些說明，由於 Lambda 函數位於私有子網（VPC 內），因此它無法訪問互聯網，這就是 AWS 為您創建 NAT 網關的原因。但是，使用 NAT 網關的價格很高，無論使用多少，每天都會產生大約 1-3 美元的費用。
我們可以嘗試將 Lambda 函數放在公共子網中，但可惜我沒有嘗試。可能有一種方法可以繞過此問題來創建 VPC 端點。
我們確實需要一個用於 EFS 的 VPC，以便我們可以緩存模型，這樣每次調用函數時都不需要下載它們。是的，AWS Lambda 擁有非常慷慨的免費套餐，但在添加其他資源時，我們需要注意其他成本。
完成後，我建議您銷毀這些資源，這樣您就不必全天候支付 NAT 網關的費用。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
關於使用此方法的附加說明，您不能分別指定內存和 CPU。如果您需要更多 CPU，則需要增加內存，這可能會變得很昂貴。
但是，在使用 125M 參數或更少的較小模型時，我不會完全忽略 AWS Lambda。您可以使用更少的內存配置 Lambda 函數。
Modal 是為部署 ML 模型而創建的，這將使此過程更加簡潔。我們將在此處使用的腳本用於部署與之前相同的模型，您可以在此處找到它。
在部署時，我們可以直接在函數中指定內存、CPU 和 GPU。我們還可以要求在腳本中為我們創建一個端點，這將使使用端點測試我們的模型更容易。
但是，僅僅因為我們使用的是另一個平台，並不意味著它不會也花費我們一些費用。
記住我們之前做的計算。
要開始，您需要一個 Modal 帳戶和已安裝的 python3。創建帳戶後，我們可以打開一個終端並創建一個新文件夾。
<code>cd zero-administration-inference-with-aws-lambda-for-hugging-face</code>
然後，我們可以設置虛擬環境。
<code>.code</code>
使用 pip 安裝 Modal 包。
<code># inference/summarization.py
import json
from transformers import pipeline
extractor = pipeline("text2text-generation", model="ilsilfverskiold/tech-keywords-extractor")
def handler(event, context):
# texts should be an array
texts = event['texts']
response = {
"statusCode": 200,
"body": extractor(texts)[0]
}
return response</code>使用Modal，所有資源、環境設置和執行都在其平台上進行，而不是在本地進行，因此我們不會遇到與部署到 AWS 時相同的問題。
要進行身份驗證，請運行此命令。
<code>python3 -m venv venv source venv/bin/activate</code>
現在，如果您在文件夾中沒有任何文件，請創建一個。
<code>pip install -r requirements.txt</code>
您可以簡單地將下面的代碼粘貼到其中，但我們也會對其進行介紹。
<code>{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"ssm:*",
"iam:*",
"lambda:*",
"s3:*",
"ec2:*",
"logs:*",
"cloudformation:*",
"elasticfilesystem:*"
],
"Resource": "*"
}
]
}</code>請記住，我使用的是相同的模型，您可以使用另一個模型。
要進行部署，只需運行以下命令。
<code>cdk bootstrap</code>
此腳本在Modal中設置了一個名為“text-generation”的應用程序，並構建了一個具有所需依賴項（huggingface-hub、transformers 和 torch）的 Docker 映像。
它直接在 Modal 的環境中安裝這些依賴項，因此您不必在本地處理它們。該應用程序請求1 個 CPU 核心和3 GB 內存，這是我在測試期間使用的設置。
模型緩存由@modal.build()處理，它使用 snapshot_download() 從 Hugging Face 中提取模型並將其保存在 /cache 中。我們需要這樣做，以便在冷啟動時可以更快地調用它。
@modal.enter() 裝飾器在第一次調用 TextExtraction 類時運行，將標記器和模型從緩存的文件加載到內存中。
加載模型後，您可以調用extract_text()方法來運行推理。 @modal.web_endpoint設置了一個無服務器 API 端點，允許您通過 POST 請求命中 extract_text() 並獲取文本提取結果。
整個過程都在 Modal 的環境中運行，因此我們不必擔心您的計算機是否有足夠的資源。當然，對於更大的模型來說，這一點更為重要。
部署完成後，您將在終端中看到類似於此的內容，其中包含您的端點。
您可以在 Modal 儀表板中查看此應用程序。
要運行此函數，您可以調用您在終端中獲得的 URL。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
這不會添加身份驗證，請參閱 Modal 的文檔以添加此功能。
正如您現在已經了解到的那樣，使用任何部署選擇，您都需要首先在構建時緩存模型，以確保在縮減規模後冷啟動速度更快。如果您想嘗試部署到任何其他平台，您可以查看此處的所有入門腳本。
使用新平台並不一定不好，而且速度會快得多。但是，有時您的組織對允許您使用的平台有嚴格的限制。
使用更容易的選擇，成本也可能略高一些，但我向您展示的那些在成本方面與直接使用 EC2 的成本相差不大。
如果您已經看到這裡，我希望您能了解我在這裡所做的研究，並且它將幫助您選擇供應商。
❤
以上是託管開源LLM的經濟學的詳細內容。更多資訊請關注PHP中文網其他相關文章！
