在 Elasticsearch 中扩展 ML 推理管道：如何避免问题并解决瓶颈

作者：来自 Elastic Iulia Feroli

是时候考虑语义搜索运营了吗？

无论你是一位经验丰富的搜索工程师，希望探索新的人工智能功能，还是一位机器学习专家，希望更多地利用搜索基础设施来增强语义相似性模型 —— 充分利用这些领域的交集可能需要熟悉一些新概念。

虽然 Elasticsearch 提供了一些快速启动指南，比如 ELSER 示例 notebook （或者对于本地的 Elasticsearch, 你可以参考 “Elasticsearch：使用 ELSER 文本扩展进行语义搜索”），但当你希望扩展推理过程时，会引入更多的配置选项。

在本博客中，我们将看看在处理更复杂的工作负载时，可能遇到的潜在瓶颈以及缓解成长烦恼的方法。

在部署大型语言模型到你的环境时，以下是一些需要注意的步骤。

在下载模型之前

机器学习节点大小 在 Elasticsearch 中使用 NLP 模型构建项目的第一步是设置部署模型的正确基础设施。

正确的机器学习节点配置可能是第一个潜在的瓶颈，因此请确保你为预期的结果选择了合适的大小。

推荐的最小大小：

如果关闭了部署自动扩缩，则部署和使用 ELSER 模型的专用机器学习节点的最小大小为 4 GB；对于自然语言处理模型，则为 16 GB。

建议打开自动扩缩，因为它允许你的部署根据需求动态调整资源。

参见文档。

你可能遇到的故障排除场景：

模型配置

更大的节点大小也允许在选择模型的分配和线程数量时具有更大的灵活性。

每个线程需要一个 CPU 或 vCPU，所以例如 8 个 CPU 可以让你拥有 1 个分配，每个分配最多 8 个线程，或者最多 8 个分配，每个分配 1 个线程，或者其他排列组合，只要满足以下条件：

umber_of_allocations * threads_per_allocation <= number of available CPUs.

在同一 ML 节点上部署多个模型将共享这些资源，因此你可以通过配置每个模型的最大访问来根据需要分配你的 CPU。

此外，每个模型部署的分配都有一个用于推理请求的有限队列。当对同一部署进行了太多调用并且队列填满时，所有后续请求都将被拒绝。考虑使用专用部署以防止此情况发生。

对于每个部署和用例，你应考虑以下参数：

此设置的值不得超过每个节点可分配的处理器数量。

请参考有关 ELSER 性能随分配数量增加而提高的基准测试信息作为示例。

在部署模型时

一旦模型已经下载到你的集群中，你可以开始部署它，同时考虑前面讨论的参数。在这个阶段，如果你计划部署同一模型的多个实例，可以考虑使用唯一的 deployment_id。

client.ml.start_trained_model_deployment(
    model_id=".elser_model_2", 
    deployment_id="elser_inference_1",
    number_of_allocations=1, 
    threads_per_allocation=8,
    queue_capacity=7000, 
    timeout="1m", 
    wait_for="starting"
)

在此阶段你可能会遇到一些潜在的瓶颈或错误：

在运行推理之前

一旦模型部署完成，你就可以开始对其进行推理调用。这可以通过 inference API 来完成：

response = client.ml.infer_trained_model(
    model_id=model_id, 
    docs=[{"text_field": query}])

这个推理命令也有一个默认的超时时间为 10 秒，当一次生成少量文档的嵌入时是足够的。

然而，对于大多数实际用例，将会有大量需要处理的文档；例如，在一个大型索引中为每个文档创建嵌入以启用语义搜索功能。

你可以增加超时时间：

response = client.ml.infer_trained_model(model_id=model_id, docs=docs, timeout="5m")

然而，正如前面的部分所提到的，根据分配的数量或发送到同一部署的不同任务的数量，模型也将有一个最大文档队列接受限制。因此，即使设置了较长的超时时间，对于大吞吐量来说，这种方法可能仍然不足够。

另一个选择是为推理过程创建摄入管道。你还可以为不同的管道使用不同的部署：一个用于在摄入新数据时生成嵌入，另一个用于在搜索时运行推理。 管道还允许你通过在 processors 列表中添加元素来设置自定义操作，例如重命名字段或为不同任务使用多个模型。你还可以在后台或按照定期时间表运行较长的任务。

client.ingest.put_pipeline(
    id="elser-2-ingest-pipeline-1",
    description="Ingest pipeline for ELSER with a lot more requests",
    processors=[
        # omitting processors code
    ])
 
client.reindex(
    source={"index": "raw_data"},
    dest={"index": "data_with_embeddings", "pipeline": "elser-2-ingest-pipeline-1"},
    wait_for_completion=False,
)

监控和调整

一旦你部署了模型并开始使用推理服务，你可以查看配置的性能。通常，这是确定特定用例的适当参数的最佳方法，并根据需要进行调整，直到达到所需的性能。

举一个简单的例子，如果你部署了一个模型而没有配置上述讨论的任何设置，这些将是分配的默认值：

{
  "threads_per_allocation" : 1, 
  "number_of_allocations" : 1, 
  "queue_capacity" : 1024
}

假设通过推理管道将大量文档发送到该模型后，我们注意到线程分配中的一些警告信号。 endpoint：

GET _nodes/hot_threads

响应：

ml.allocated_processors=16
 
100.0% [cpu=3.5%, other=96.5%] cpu usage by thread

ML 节点分配有 16 个处理器，但我们仅在模型的一个实例中利用其中 1 个处理器。 此外，在其他而不是与 CPU 相关的任务下报告的高利用率意味着该过程中存在大量等待和冗余，并且我们的文档大部分时间都在排队。

为了优化性能，你应该使用所有可用的内核。

你还可以在训练模型 UI 中或通过以下命令查看更多指标：

GET _ml/trained_models/_stats

在这里你可以看到更多有用的信息，例如 average_inference_time_ms、number_of_pending_requests 或 peak_throughput_per_分钟。

作为说明，这里有两个模型部署在同一个 ML 节点上，在相同的管道和数据上运行推理，但采用不同的分配策略。 你可以看到配置模型的推理时间几乎减半。

结论

这既是一件好事，也可能是一件困难的事情，有多种灵活和模块化的方法来构建适合你的项目的推理架构。 为每个用例构建最佳方法也不仅仅是选择正确的配置或基础设施设置。 你可以详细了解模型的检索优化甚至数据处理决策（例如分块策略）如何影响性能。

Elasticsearch 汇集了令人惊叹的开箱即用功能，并提供自定义选项和指导，帮助你构建最佳的语义搜索解决方案。

准备好将 RAG 构建到你的应用程序中了吗？ 想要尝试使用向量数据库的不同 LLMs？
在 Github 上查看我们的 LangChain、Cohere 等示例 notebooks，并参加即将开始的 Elasticsearch 工程师培训！

原文： Scaling ML Inference Pipelines in Elasticsearch: How to avoid issues and troubleshoot bottlenecks — Elastic Search Labs