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

这篇具有很好参考价值的文章主要介绍了在 Elasticsearch 中扩展 ML 推理管道:如何避免问题并解决瓶颈。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

作者:来自 Elastic Iulia Feroli

在 Elasticsearch 中扩展 ML 推理管道:如何避免问题并解决瓶颈,Elasticsearch,AI,Elastic,elasticsearch,大数据,搜索引擎,全文检索,人工智能


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

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

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

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

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

在下载模型之前

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

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

推荐的最小大小:

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

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

参见文档。

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

潜在的瓶颈 Error 信息 解决方案
ML Node is not big enough ApiError(429, 'status_exception', 'Could not start deployment because no ML nodes with sufficient capacity were found') 确保为 ML 节点选择合适的大小,并最好启用自动扩展,以便你的部署在遇到额外请求时可以扩展。
Autoscaling limit is not high enough Autoscaling limits reached. To continue experiencing optimal performance, we recommend increasing your maximum size per zone for the topologies: Machine Learning. 还有一些情况,ML 节点足够大,可以下载模型,但如果配置不正确,大吞吐量的推理调用仍然会使系统过载。 增加大小,确保你的分配使用所有可用的 CPU,或使用较小的数据批次来缓解。

模型配置

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

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

umber_of_allocations * threads_per_allocation <= number of available CPUs.

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

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

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

参数 功能
number_of_allocations 通过允许并行执行更多推理请求来提高吞吐量。 这反过来又会提高摄取性能。 默认为 1; 但你应该更改此设置,以便使用所有可用的 CPU。
threads_per_allocation 提高每个推理请求的速度,从而提高搜索速度。 默认为 1; 但你应该更改此设置,以便使用所有可用的 CPU。
queue_capacity 控制队列中一次允许有多少个推理请求。 当请求数量超过总数时,新请求将被拒绝并返回 429 错误。 默认为 1024。最大允许值为 1000000。

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

请参考有关 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"
)

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

瓶颈 解释 / Error 信息 解决方案
部署期间超时 在不指定 wait_for 参数的情况下,它默认为 started,这意味着只有当模型下载完成并成功部署时,你才会收到响应。然而,这个过程会相当耗时,具体取决于模型大小,而且由于 timeout 参数也默认为仅 30 秒,这通常会导致错误。 请改用 wait_for="starting",和/或 增加引发错误之前的等待时间:timeout="3m"
不按顺序运行这些步骤(具体示例请参阅下面的行) 在上一步完成运行之前运行命令将导致错误: 使用 status = client.ml.get_trained_models(model_id=".elser_model_2", include="definition_status") 检查模型的状态
尝试在模型完全下载之前部署模型 Model definition truncated. Unable to deserialize trained model definition [.elser_model_2] 你应该仅在 status["trained_model_configs"][0]["complete_define"] == True 时尝试部署模型
尝试对尚未完全部署的模型运行推理 404, 'resource_not_found_exception', 'Could not find trained model [.elser_model_2]'

在运行推理之前

一旦模型部署完成,你就可以开始对其进行推理调用。这可以通过 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,
)
瓶颈 解决方案
Timeout 与前面的步骤类似,冗长的管道过程可能会导致超时。 使用 wait_for_completion = False 参数。
Waiting for pipeline to finish 你可以使用从 reindex 函数获得的任务 ID 稍后通过 client.tasks.get(task_id=task_id) 跟踪管道进度。 使用 wait_for_completion 参数时会生成此 ID。

监控和调整

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

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

{
  "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 节点上,在相同的管道和数据上运行推理,但采用不同的分配策略。 你可以看到配置模型的推理时间几乎减半。

Model ID Allocation Average Inference time
elser_inference_configured 3 * 8 67.80 milliseconds
.elser_model_2 1 * 1 115.58 milliseconds

结论

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

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

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

原文: Scaling ML Inference Pipelines in Elasticsearch: How to avoid issues and troubleshoot bottlenecks — Elastic Search Labs文章来源地址https://www.toymoban.com/news/detail-858189.html

到了这里,关于在 Elasticsearch 中扩展 ML 推理管道:如何避免问题并解决瓶颈的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【并发编程】多线程安全问题,如何避免死锁

    从今天开始阿Q将陆续更新 java并发编程专栏 ,期待您的订阅。 在系统学习线程之前,我们先来了解一下它的概念,与经常提到的进程做个对比,方便记忆。 线程和进程是操作系统中的两个重要概念,它们都代表了程序运行时的执行单位,它们的出现是为了更好地管理计算机

    2024年02月11日
    浏览(51)
  • 什么是ElasticSearch的深度分页问题?如何解决?

    在ElasticSearch中进行分页查询通常使用from和size参数。当我们对ElasticSearch发起一个带有分页参数的查询(如使用from和size参数)时,ElasticSearch需要遍历所以匹配的文档直到达到指定的起始点(from),然后返回从这一点开始的size个文档 在这个例子中: 1.from 参数定义了要跳过的

    2024年03月16日
    浏览(40)
  • 如何解决 Elasticsearch 查询缓慢的问题以获得更好的用户体验

    作者:Philipp Kahr Elasticsearch Service 用户的重要注意事项:目前,本文中描述的 Kibana 设置更改仅限于 Cloud 控制台,如果没有我们支持团队的手动干预,则无法进行配置。 我们的工程团队正在努力消除对这些设置的限制,以便我们的所有用户都可以启用内部 APM。 本地部署不受

    2024年02月14日
    浏览(48)
  • (学习笔记-内存管理)如何避免预读失效和缓存污染的问题?

    传统的LRU算法存在这两个问题: 预读失效 导致的缓存命中率下降 缓存污染 导致的缓存命中率下降 Redis的缓存淘汰算法是通过 实现LFU算法 来避免 [缓存污染] 而导致缓存命中率下降的问题(redis 没有预读机制) Mysql 和 Linux操作系统是通过 改进LRU算法 来避免 [预读失效和缓存

    2024年02月14日
    浏览(47)
  • 避免智能合约灾难:C3算法教你解决钻石问题!

    在智能合约的世界里,一种被称为“钻石问题”的神秘现象正在蔓延。当智能合约试图同时继承多个合约时,这个问题如影随形般出现,让开发者措手不及。本文将深入探索这个神秘现象背后的秘密,一探究竟! 允许一个合约同时继承多个合约,从而将它们的功能和属性组合

    2024年04月10日
    浏览(44)
  • 如何避免企业网络安全设备部署失败的解决方案

    扩展型企业的概念给IT安全组合带来越来越严峻的问题,因为它们的敏感数据和有价值的数据经常会流出传统网络边界。为了保护企业不受多元化和低端低速可适应性的持久威胁,IT企业正在部署各种各样的新型网络安全设备:下一代防火墙、IDS与IPS设备、安全信息事件管理(

    2024年02月07日
    浏览(46)
  • 优维产品最佳实践第13期:如何避免拨测机自身网络问题?

    受限于拨测节点自身的环境,单一节点的拨测结果可能并不能反映出监控实例的真实运行状态 本期EasyOps产品使用最佳实践,我们将为您揭晓: 如何基于多点决策配置拨测监控,以避免拨测机自身网络问题而误告警? 如何对指标实现“降维”,从而汇聚指标? 「 背 景 」 拨

    2024年02月06日
    浏览(40)
  • 【分布式·大数据】大模型赛道如何实现华丽的弯道超车 —— AI/ML训练赋能解决方案

    导读 :Alluxio作为一款强大的分布式统一大数据虚拟文件系统,已经在众多领域展现出了其卓越的应用价值,并且为AI/ML训练赋能提供了一个全新的解决方案。 在人工智能(AI)和机器学习(ML)领域,数据驱动的决策和模型训练已成为现代应用和研究的核心。伴随大模型技术

    2024年02月08日
    浏览(41)
  • 近期Web3常见的攻击都有什么特点 项目方如何避免这些问题?

    最近发生大量的安全攻击事件,这些事件对于项目方来说具有重大影响。攻击事件的发生主要原因之一是业务逻辑设计不当,其中可能存在漏洞或弱点,被黑客利用进行攻击。另外,价格操控也是导致安全攻击事件的因素之一,黑客可能通过操纵价格或市场行为来实施攻击。

    2024年01月24日
    浏览(48)
  • 面试题:Kafka中Controller的作用是什么?选举流程是怎样的?以及如何避免脑裂问题?

    网上冲浪:还不懂分布系统,速看深度剖析Kafka Controller选举过程 在查找关于Kafka单机分区的上限以及分区多了会有怎样的问题的时候,发现了这个比较有趣的问题,就记录了下来。 一般所有的分布式系统,都会涉及到这个问题:脑裂、以及如何避免脑裂问题。 Kafka中Control

    2024年04月24日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包