_如果您不是会员但想阅读本文，请查看此朋友链接。_
如果您一直在尝试不同大小的开源模型，您可能想知道：部署它们的最高效方法是什么？
按需付费和无服务器提供商之间的价格差异是多少，当存在 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中文网其他相关文章！
