原文：
towardsdatascience.com/economics-of-hosting-open-source-llms-17b4ec4e7691
生产中的大型语言模型
GPU 与 CPU 上的总处理时间 – 不按比例* | 作者图片
_ 如果您不是会员但想阅读这篇文章，请点击这里阅读朋友链接 _
如果你一直在尝试不同尺寸的开源模型，你可能会问自己：部署它们最有效的方法是什么？
按需和无服务器提供商之间的定价差异是多少，当有 LLM 服务平台时，真的值得与像 AWS 这样的玩家打交道吗？
我决定深入研究这个主题，比较云服务提供商如 AWS 与更新的替代品如 Modal、BentoML、Replicate、Hugging Face Endpoints 和 Beam。
我们将查看处理时间、冷启动延迟以及 CPU、内存和 GPU 成本等指标，以了解什么是最有效和经济的。我们还将涵盖一些软指标，如部署的便利性、开发者体验和社区。
我们将查看的一些指标 | 作者图片
我们将探讨一些用例，例如在 CPU 上部署较小的模型与在 GPU 上运行70-80 亿参数的模型之间的比较。
我还将深入研究在 AWS Lambda 上部署较小模型的过程，并与其更现代的平台如 Modal 进行比较。
我不会在这里深入探讨优化策略，比如使用不同的框架加快推理或量化 – 这完全是另一个话题。
相反，本文将重点介绍如何选择正确的部署选项，给你一个机会比较不同场景下的性能，并帮助你了解部署小型和大型 LLM 的经济成本。
简介
当你使用现成的开源模型时，有许多 API 选项很容易接入。我建议查看这个列表以获取一些选择。你也可以选择自行托管 – 查看同一列表中的‘本地推理’部分。
然而，你可能需要使用私有、微调的或不太常见的模型。
你当然也可以将这些模型本地托管，但你需要在电脑上拥有足够的资源，并且你可能希望将这些模型集成到运行在其他服务器上的应用程序中。
这将带我们到按需或通过无服务器平台托管开源模型。想法是，无论是有需求还是按运行次数，你只为使用的资源付费，就像无服务器一样。
无服务器和按需工作有点相似，但使用无服务器时，缩放速度更快，因此你不需要为闲置资源付费。
你可以查看我下面的笔记，了解更多比较。
按需与无服务器笔记 | 图片由作者提供
在这篇文章中，我们将比较 AWS 的 EC2 和 Lambda 与最近获得流行的一些新兴平台的定价。
我们将涵盖的不同部署选择 | 图片由作者提供
这样，你将更好地了解什么可能最适合。
作为旁注，我没有收到任何这些供应商的报酬，所以我分享的信息是我自己的。
如果你是一个利益相关者，这是一个了解不同选项的经济效益以及根据模型大小和供应商选择运行推理可能花费多少的绝佳方式。
文章的第一部分涵盖了研究，任何人都可以跟随，而第二部分则深入到部署的技术方面，你可能想读也可能不想读。
LLM Serving Frameworks
现在，在我们开始之前，我想对 LLM 推理框架发表一些评论，这些框架简化了 API 端点的设置以提供模型。有几个开源的 LLM 服务框架可用，包括 vLLM、TensorRT 和 TGI，我们可以在其中使用。
你可以在之前分享的列表中查看一些更受欢迎的选项，在 ‘LLM Serving Frameworks’ 部分（见下文）。
来自‘LLM Serving Frameworks’下的 ‘LLM 资源列表’ | 图片由作者提供
有些人已经测量了这些框架之间的 性能差异，你应该绝对进行自己的研究。
然而，在这篇文章中，我们将使用 vLLM，它被广泛使用——除了通过 Hugging Face Endpoints 部署模型，它将自动为我们使用 TGI。
要部署一个在 CPU 上运行的较小的转换器模型，我直接使用了 Hugging Face 的 [pipeline](https://huggingface.co/docs/transformers/en/main_classes/pipelines) 或 transformers 库。
研究部分
在本篇的第一部分，我们将查看我们的选择，无论是按需还是无服务器，的效率、成本和性能。我们将先通过指标，然后再深入任何技术细节。
处理时间
让我们从测量容器热（即，在过去的几秒钟内已被使用）时无并发情况下的总处理时间开始。
我们将处理时间定义为完成响应所需的总时间。注意，有些人可能会测量首次响应的时间，尤其是在流式传输输出时。
为了保持一致性，我为每个测试使用了相同的提示。对于 4 亿参数的模型，我将文本分批处理为每批 30 个。
您可以查看下面的指标。
非比例，见完整计算此处 | 作者图片
我只在同一天对每个平台进行了几次测试。理想情况下，我应该测试几天。我可能对其中一些不太幸运。
但为了讨论它们的性能，对于无服务器提供商，Modal 和 Beam 在 CPU 上的表现非常好（以浅绿色条表示）。启动一个 400M 模型比启动一个 8B 模型要容易得多。
我发现，即使使用更小的模型（小于 130M）与 AWS Lambda 配合使用也非常好，特别是如果你使用 EFS 缓存你的模型。
虽然我真的很喜欢 Hugging Face 端点，但我发现他们的 CPU 实例有点不可预测。然而，他们的 AWS GPU 实例非常可靠且速度很快。
我可以使用 Hugging Face 在 GPU 上获得非常快的响应，即使在一个 L4 实例上托管一个 70 亿参数的模型，也可以在 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 也会做得很好。
GPU & CPU Pricing
让我们转向定价。我们需要查看 CPU、内存和 GPU 资源的成本。
这些平台之间存在一些明显的差异。
无服务器提供商通常更昂贵，因为它们除了 GPU 使用外，还会对 CPU 和内存收费。然而，它们不会对空闲时间收费，这可以帮助抵消更高的成本。
您可以在下面的图片中找到 Nvidia GPU 的定价。
每个平台的 GPU 定价，请在此处查看计算结果 | 作者图片
您应该看看 SageMaker，它在所有这些中具有最高的 GPU 成本。如果您需要使用 AWS，可能直接使用 EC2 会更好。
让我们也看看 CPU 定价。
每个平台的 CPU/内存定价，请在此处查看计算结果 | 作者图片
Hugging Face Endpoints 以每实例 2 vCPU 和 4GB 内存的 0.07 美元的成本领先，遗憾的是，它们的 CPU 实例性能并不出色。
Beam 和 Modal 允许您调整所需的资源，这有助于最小化成本。对于一个 400M 模型，我计算得出，在两个平台上我只需要 3GB 的内存和 1 个核心（2 vCPU）。
另一方面，Replicate 无论模型大小如何，都强制我们使用 4 vCPU，这使得它成为这里最昂贵的 CPU 选项。
我们将探讨几个用例，以比较所有这些平台的定价和效率。
案例一：在 CPU 上运行的微调 400M 模型
第一个案例将在一天中偶尔运行 400M 模型。这意味着每次调用时容器都需要进行扩展和缩减。
我们可能并不总是需要扩展和缩减，但我们必须像需要那样进行计算。
我通过每次调用批处理 30 个文本，并使用较小的微调模型，一天内总共进行了 250 次调用。为了简化，我们假设每次运行容器时都是冷的（除了 Hugging Face Endpoints）。
非比例图，见计算此处 | 作者图片
服务器端提供商在这里是一个更好的选择，因为我们不需要为空闲时间付费，就像我们为按需付费那样。对于 BentoML，我们需要至少保持 5 分钟的空闲时间，然后它才会自动缩放，对于 HF 端点，需要等待 15 分钟。
顺便提一下，如果你对自动缩放下不了解，这个概念意味着我们告诉平台，如果它们允许的话，自动缩小我们的实例。
它们都有不同的要求，Baseten 和 HF Endpoints 有一个 15 分钟的空闲窗口，BentoML 有 5 分钟。
由于 HF 端点至少需要 15 分钟才能缩放，如果我们每 5-6 分钟调用一次函数，它就没有时间缩放，因此我们启动次数非常低，但大部分时间是空闲的。
我们可以看到，像 HF 案例一样，有 17 小时的空闲时间，BentoML 案例中有 18 小时，这是固有的低效。我们将在一天中为空闲资源支付大部分费用。
在你最初的几天里，几分之一或一美元可能看起来不多，但过了一段时间就会累积起来。
查看运行一个较小模型在 CPU 上的月度成本 | 作者图片
就像人们每天在储蓄账户中存一点钱一样——这里过度支付将是相反的。
但如果我们让容器热身时运行所有 250 个调用呢？成本会有多少差异？
非比例图，见计算此处 | 作者图片
在这个例子中，Beam 似乎是一个异常值，但我认为它们正在运行超过其他平台不允许的最大 CPU。
在这种情况下，冷启动和空闲时间消失了。这表明，如果你一次性处理所有事情，使用持久容器是更好的选择——它要便宜得多。
值得注意的是，400M 模型在 Hugging Face Endpoints 和 BentoML 上都最适合 T4 GPU。这种设置在显著减少处理时间的同时，保持了低成本。
一件需要注意的事情：如果你使用 AWS Lambda 与 EFS，你将因 NAT 网关产生额外的费用，每天可能增加 1 到 3 美元，从而使总成本比这里显示的更高。
现在，让我们转到第二个案例——在 GPU 上运行 7B 到 8B 参数的较大模型。
案例二：在 GPU 上运行的通用 8B 模型
对于这个案例，我一直在测试大小约为 7B-8B 的 Mistral、Gemma 或 Llama 模型。
这种场景涉及整天断断续续地调用模型 250 次。我们假设容器为每次调用进行扩展和缩减，尽管这并不总是情况。
就像 CPU 测试一样，我们假设这些按需服务 24 小时运行，因为它没有时间进行缩放。
我已经确保为每个供应商写下了我们在这里使用的 GPU 实例。请看下面的柱状图。
非比例，见此处计算 | 作者图片
对于无服务器提供商，我通过乘以处理时间略微增加了处理时间，但在总价格计算中排除了冷启动。
虽然实际成本可能更低，但这种调整需要谨慎。有可能你会被多收费，因为你将支付一些启动费用。
非比例，见此处计算 | 作者图片
就像我们在 CPU 外壳上看到的那样，一次性运行 250 次调用更加经济高效。
如果你为 Anthropic 和 OpenAI 的最便宜模型设置计算，并将它们与自托管成本进行比较，你会发现使用相同的提示调用它们的模型比以这种方式托管要便宜得多。
人们将这些供应商称为 LLM 的麦当劳。
我们认为开源会更便宜，但我们没有计算托管的实际单位经济学。这些平台也由风险投资资金补贴。然而，正如我之前提到的这里，使用你在这里找到的供应商，有更便宜的方式来访问开源模型。
如果你想深入了解详细计算，你可以查看这个文件。提前警告——它看起来有点杂乱。
用户体验
到现在为止，你可能已经得出了自己的结论，但我想最后再谈一点，那就是用户体验。
如果你不是程序员，那么 HF Endpoints 非常容易使用，因为你可以直接点击从 HuggingFace hub 部署模型。如果你有点技术，你可能更喜欢其他选项，在这些选项中你拥有更多控制权。
对于 Replicate，他们有一个庞大的追随者群体和许多人共享的许多公共模型。围绕它有一个社区。他们有几个一键训练和部署流程，这使得它更容易。
然而，我发现 Modal、Beam 和 BentoML 在总体上提供了很好的开发者体验。你可以直接通过终端部署，并让代码在他们的服务器上运行。
使用 Replicate，如果你正在部署自己的模型，你需要一个 GPU 机器，而使用 Baseten，你需要下载一个名为 Truss 的库，这需要一些时间。
我收集了一些笔记在这个 表格 中（也见下方）。
从 LLM 资源 列表 | 图像由作者提供
如果你热衷于使用这些中的任何一个，表格 将包含获取开始脚本的链接。
现在我们已经涵盖了大多数非技术方面，我将向您介绍两种针对在 CPU 上表现良好的模型的部署选项：AWS Lambda 和 Modal。
技术要点
在本节中，我们将部署一个我使用 AWS Lambda 和 EFS 微调过的 400M 模型，并将其与在较新平台如 Modal 上的部署进行比较。
这两个工具都是无服务器工具，这意味着我们需要在构建时正确地缓存模型，以便我们可以在连续运行中快速访问它。AWS 提供了一个现成的 脚本，我们可以轻松修改，我还在 这里 准备了一个 Modal 脚本。
我们将关注两个主要方面：如何在每个平台上部署模型，以及反思部署过程中的关键差异。
使用 EFS 部署到 Lambda
对于这部分，你可以阅读它，或者跟随步骤进行部署。
要跟随，你需要在你的计算机上安装 git、AWS CDK、Docker、NodeJS 18+ 和 Python 3.9+。一旦你安装了所有这些，你就可以打开一个新的终端。
如果你愿意，可以创建一个新的目录，然后克隆下面的仓库。
git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git
进入创建的目录。
cd zero-administration-inference-with-aws-lambda-for-hugging-face
你现在可以打开你的代码编辑器中的文件。
我使用 VSCode，所以我简单地这样做。
.code
现在，我们可以进入创建的文件并进行一些调整。查看推理文件夹，你将看到两个文件，sentiment.py 和 summarization.py。
我们可以轻松地将这些文件中的模型更改为我们想要的模型。
如果你访问 HuggingFace 中心并找到你感兴趣的一个模型。
我会使用我其中一个模型。
如果你感兴趣如何构建这样的模型，你可以查看关于关键词提取的教程 [这里](https://medium.com/gitconnected/fine-tune-smaller-nlp-models-with-hugging-face-for-specific-use-cases-1745813471dc)，以及关于文本分类的教程。
一旦你找到了你感兴趣的模型，你可以点击“使用此模型”按钮。
如你所见，我们有两个选择，但鉴于这个脚本正在使用管道，我们也可以这样做。
我在下面的文件中更改了代码，使用了一个新的模型，同时期望使用‘texts’进行批处理而不是仅仅使用‘text’。
# 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
你可以通过查看上面的图片来了解文件结构。
我已经用我常用的不同模型修改了这两个脚本。确保你完成修改后保存脚本。
然后，你可以在终端中设置虚拟环境。
python3 -m venv venv
source venv/bin/activate
在下载需求之前，请确保你已经安装了 NodeJS 18。
pip install -r requirements.txt
在你可以做其他任何事情之前，你需要确保你配置的 AWS CDK 用户具有正确的权限。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"ssm:*",
"iam:*",
"lambda:*",
"s3:*",
"ec2:*",
"logs:*",
"cloudformation:*",
"elasticfilesystem:*"
],
"Resource": "*"
}
]
}
然后，你可以运行 bootstrap。
cdk bootstrap
如果你在这里遇到问题，请检查是否已安装 aws-cdk-lib，如果没有，请重新安装它。
pip install aws-cdk-lib
cdk bootstrap
一旦你点击这个，命令将创建一个 Cloudformation 堆栈。
如果你在这里遇到与 ECR 相关的问题，请手动创建存储库。
如果你电脑上运行着 Docker，你现在可以通过终端进行部署。
cdk deploy
从这里开始，CDK 会使用你 inference 文件夹中的 Dockerfile 为 Lambda 函数构建 Docker 镜像。每个 Lambda 函数都配置了 8 GB 的内存 和 600 秒的超时时间。
它将创建一个包含互联网网关、用于缓存模型的 EFS、几个基于 Docker 的 Lambda 函数（用于托管脚本中的两个模型）以及几个用于 Lambda 执行的 IAM 角色 的 VPC。
这将需要一些时间。
不稳定 WiFi 连接可能看起来像什么 | 图片由作者提供
我当时坐在意大利的一个小村庄里做这件事，所以我的网络连接失败了，我不得不租用一台 GPU 机器来部署。
这可能不会发生在你身上，但请确保你有足够的电量并且有一个稳定的网络连接来部署。
一旦部署完成，你可以在 AWS 控制台的 Lambda 中查找你的新函数。你可以在那里直接测试它们。第一次运行会慢一些，但一旦它热起来就会快一些。
这里有一些注意事项，因为 Lambda 函数位于私有子网（VPC 内部），它无法访问互联网，这就是为什么 AWS 会为您创建一个 NAT 网关。使用 NAT 网关虽然价格昂贵，但无论使用多少，每天都会产生大约 $1-$3 的费用。
我们可以尝试将 Lambda 函数放在公共子网中，但遗憾的是我没有尝试过。可能有一种方法可以通过创建 VPC 端点来绕过这个问题。
我们确实需要一个 VPC 来为 EFS 缓存模型，这样它们在每次调用函数时就不需要下载。是的，AWS Lambda 有一个非常慷慨的免费层，但它可能产生其他费用，当添加其他资源时，您需要了解这些费用。
一旦您完成测试，我建议您销毁资源，这样您就不会全天候支付 NAT 网关的费用。
cdk destroy
关于使用此方法的附加说明，您不能单独指定内存和 CPU。如果您需要更多的 CPU，您需要增加内存，这可能会很昂贵。
然而，当使用 125M 参数或更小的较小模型时，我不会完全忽视 AWS Lambda。您可以配置一个内存更小的 Lambda 函数。
部署到 Modal
已经创建了用于部署 ML 模型的 Modal，这将使这个过程变得更加简洁。我们将在此处使用脚本 here 来部署与之前相同的模型。
在部署时，我们可以在我们的函数中直接指定内存、CPU 和 GPU。我们还可以在脚本中请求为我们创建一个端点，这将使测试我们的模型更容易。
然而，仅仅因为我们使用的是另一个平台，这并不意味着它不会给我们带来一些成本。
记住我们之前所做的计算。
要开始，您需要一个 Modal 账户并安装 python3。创建一个账户后，我们可以打开终端并创建一个新的文件夹。
mkdir testing_modal
cd testing_modal
我们可以设置一个虚拟环境。
python3 -m venv venv
source venv/bin/activate
使用 pip 安装 Modal 包。
pip install modal
使用 Modal，所有资源、环境设置和执行都在他们的平台上进行，而不是本地，所以我们不会遇到像部署到 AWS 时那样的问题。
要进行身份验证，请运行此命令。
python3 -m modal setup
现在，如果您文件夹中没有文件，请创建一个。
touch text.py
您可以直接将下面的代码粘贴进去，但我们也会讲解它。
# text.py
import modal
from pydantic import BaseModel
from typing import List
app = modal.App("text-generation") # set an app name
model_repo_id = "ilsilfverskiold/tech-keywords-extractor" # decide on your model repo
cache_dir = "/cache"
image = (
modal.Image.debian_slim()
.pip_install(
"huggingface-hub==0.16.4",
"transformers",
"torch"
)
)
# have these loaded in modal rather than locally
with image.imports():
import torch
from transformers import AutoTokenizer, AutoModelForSeq2SeqLM
# set up the function to run for extracting keywords from texts (as per the model we're using)
# the snapshot download should download the model on build and cache it
@app.cls(cpu=1, memory=3000, image=image) # define cpu (cores), memory and/if gpu - default CPU request is 0.1 cores the soft CPU limit is 4.1 cores - default 128 MiB of memory
class TextExtraction:
@modal.build()
def download_model(self):
from huggingface_hub import snapshot_download
snapshot_download(repo_id=model_repo_id, cache_dir=cache_dir)
@modal.enter()
def load_model(self):
self.tokenizer = AutoTokenizer.from_pretrained(model_repo_id, cache_dir=cache_dir)
self.model = AutoModelForSeq2SeqLM.from_pretrained(model_repo_id, cache_dir=cache_dir)
@modal.method()
def extract_text(self, texts):
inputs = self.tokenizer(texts, return_tensors="pt", padding=True, truncation=True)
outputs = self.model.generate(**inputs, max_new_tokens=100)
generated_texts = [self.tokenizer.decode(output, skip_special_tokens=True) for output in outputs]
return generated_texts
class TextsRequest(BaseModel):
texts: List[str]
# set up the web endpoint
@app.function(image=image)
@modal.web_endpoint(method="POST", label=f"{model_repo_id.split('/')[-1]}-web", docs=True)
def generate_web(request: TextsRequest):
texts = request.texts
extracted_texts = TextExtraction().extract_text.remote(texts)
return {"extracted_texts": extracted_texts}
# add potential error handling
记住，我正在使用相同的模型，您可能使用另一个模型。
部署时，您只需运行。
modal deploy text.py
此脚本在 Modal 中设置了一个名为 "text-generation" 的应用程序，并构建了一个包含所需依赖项（huggingface-hub、transformers 和 torch）的 Docker 镜像。
它会直接在 Modal 的环境中安装这些依赖项，因此您不需要在本地处理它们。应用程序请求 1 个 CPU 核心 和 3 GB 的内存，这是我测试时使用的配置。
模型缓存由 @modal.build() 处理，其中它使用 snapshot_download() 从 Hugging Face 拉取模型并将其保存到 /cache。我们需要这样做，以便在冷启动时可以更快地调用。
当 TextExtraction 类首次被调用时，@modal.enter() 装饰器会运行，将分词器和模型从缓存文件加载到内存中。
一旦模型加载，你可以调用 extract_text() 方法来进行推理。@modal.web_endpoint 设置了一个无服务器 API 端点，允许你通过 POST 请求调用 extract_text() 并获取你的文本提取结果。
整个过程都在 Modal 的环境中运行，所以我们不需要担心你的电脑是否有足够的电量。当然，对于更大的模型来说，这一点尤为重要。
一旦部署，你将在终端看到类似这样的内容与你的端点。
你将能够在你的 Modal 控制台中看到这个应用程序。
要运行此函数，你可以调用终端返回的 URL。
curl -X POST "https://<your-modal-endpoint-url>"
-H "Content-Type: application/json"
-d '{"texts": ["Artificial intelligence in healthcare represents a collection of multiple technologies enabling machines to sense, comprehend, act, and learn"]}'
这不会添加认证，请参阅 Modal 的文档以添加此功能。
一些注意事项
如你现在所学的，使用任何部署选择，你都需要在构建时首先缓存模型，以确保在缩放后冷启动更快。如果你想尝试部署到任何其他平台，你可以看到所有入门脚本这里。
采用新的平台不一定不好，而且会快得多。然而，有时你的组织对你的使用平台有严格的要求。
与更容易的选择相比，成本可能也会稍微高一些，但我在这里展示的与 EC2 直接相比在成本上并不遥远。
如果你已经走到这一步，我希望你能从我所做的研究中获得一些信息，并希望这能帮助你选择供应商。
❤
扫一扫
262
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
