作者：來(lái)自 Elastic?Iulia Feroli
是時(shí)候考慮語(yǔ)義搜索運(yùn)營(yíng)了嗎？
無(wú)論你是一位經(jīng)驗(yàn)豐富的搜索工程師，希望探索新的人工智能功能，還是一位機(jī)器學(xué)習(xí)專(zhuān)家，希望更多地利用搜索基礎(chǔ)設(shè)施來(lái)增強(qiáng)語(yǔ)義相似性模型 —— 充分利用這些領(lǐng)域的交集可能需要熟悉一些新概念。
雖然 Elasticsearch 提供了一些快速啟動(dòng)指南，比如 ELSER 示例 notebook?（或者對(duì)于本地的 Elasticsearch, 你可以參考 “Elasticsearch：使用 ELSER 文本擴(kuò)展進(jìn)行語(yǔ)義搜索”），但當(dāng)你希望擴(kuò)展推理過(guò)程時(shí)，會(huì)引入更多的配置選項(xiàng)。
在本博客中，我們將看看在處理更復(fù)雜的工作負(fù)載時(shí)，可能遇到的潛在瓶頸以及緩解成長(zhǎng)煩惱的方法。
在部署大型語(yǔ)言模型到你的環(huán)境時(shí)，以下是一些需要注意的步驟。
在下載模型之前
機(jī)器學(xué)習(xí)節(jié)點(diǎn)大小 在 Elasticsearch 中使用 NLP 模型構(gòu)建項(xiàng)目的第一步是設(shè)置部署模型的正確基礎(chǔ)設(shè)施。
正確的機(jī)器學(xué)習(xí)節(jié)點(diǎn)配置可能是第一個(gè)潛在的瓶頸，因此請(qǐng)確保你為預(yù)期的結(jié)果選擇了合適的大小。
推薦的最小大?。?/p>
如果關(guān)閉了部署自動(dòng)擴(kuò)縮，則部署和使用 ELSER 模型的專(zhuān)用機(jī)器學(xué)習(xí)節(jié)點(diǎn)的最小大小為 4 GB；對(duì)于自然語(yǔ)言處理模型，則為 16 GB。
建議打開(kāi)自動(dòng)擴(kuò)縮，因?yàn)樗试S你的部署根據(jù)需求動(dòng)態(tài)調(diào)整資源。
參見(jiàn)文檔。
你可能遇到的故障排除場(chǎng)景：
| 潛在的瓶頸 | 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 節(jié)點(diǎn)選擇合適的大小，并最好啟用自動(dòng)擴(kuò)展，以便你的部署在遇到額外請(qǐng)求時(shí)可以擴(kuò)展。 |
| 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 節(jié)點(diǎn)足夠大，可以下載模型，但如果配置不正確，大吞吐量的推理調(diào)用仍然會(huì)使系統(tǒng)過(guò)載。 增加大小，確保你的分配使用所有可用的 CPU，或使用較小的數(shù)據(jù)批次來(lái)緩解。 |
模型配置
更大的節(jié)點(diǎn)大小也允許在選擇模型的分配和線程數(shù)量時(shí)具有更大的靈活性。
每個(gè)線程需要一個(gè) CPU 或 vCPU，所以例如 8 個(gè) CPU 可以讓你擁有 1 個(gè)分配，每個(gè)分配最多 8 個(gè)線程，或者最多 8 個(gè)分配，每個(gè)分配 1 個(gè)線程，或者其他排列組合，只要滿足以下條件：
umber_of_allocations * threads_per_allocation <= number of available CPUs.在同一 ML 節(jié)點(diǎn)上部署多個(gè)模型將共享這些資源，因此你可以通過(guò)配置每個(gè)模型的最大訪問(wèn)來(lái)根據(jù)需要分配你的 CPU。
此外，每個(gè)模型部署的分配都有一個(gè)用于推理請(qǐng)求的有限隊(duì)列。當(dāng)對(duì)同一部署進(jìn)行了太多調(diào)用并且隊(duì)列填滿時(shí)，所有后續(xù)請(qǐng)求都將被拒絕。考慮使用專(zhuān)用部署以防止此情況發(fā)生。
對(duì)于每個(gè)部署和用例，你應(yīng)考慮以下參數(shù)：
| 參數(shù) | 功能 | 值 |
|---|---|---|
| number_of_allocations | 通過(guò)允許并行執(zhí)行更多推理請(qǐng)求來(lái)提高吞吐量。 這反過(guò)來(lái)又會(huì)提高攝取性能。 | 默認(rèn)為 1； 但你應(yīng)該更改此設(shè)置，以便使用所有可用的 CPU。 |
| threads_per_allocation | 提高每個(gè)推理請(qǐng)求的速度，從而提高搜索速度。 | 默認(rèn)為 1； 但你應(yīng)該更改此設(shè)置，以便使用所有可用的 CPU。 |
| queue_capacity | 控制隊(duì)列中一次允許有多少個(gè)推理請(qǐng)求。 當(dāng)請(qǐng)求數(shù)量超過(guò)總數(shù)時(shí)，新請(qǐng)求將被拒絕并返回 429 錯(cuò)誤。 | 默認(rèn)為 1024。最大允許值為 1000000。 |
此設(shè)置的值不得超過(guò)每個(gè)節(jié)點(diǎn)可分配的處理器數(shù)量。
請(qǐng)參考有關(guān) ELSER 性能隨分配數(shù)量增加而提高的基準(zhǔn)測(cè)試信息作為示例。
在部署模型時(shí)
一旦模型已經(jīng)下載到你的集群中，你可以開(kāi)始部署它，同時(shí)考慮前面討論的參數(shù)。在這個(gè)階段，如果你計(jì)劃部署同一模型的多個(gè)實(shí)例，可以考慮使用唯一的 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"
)在此階段你可能會(huì)遇到一些潛在的瓶頸或錯(cuò)誤：
| 瓶頸 | 解釋 / Error 信息 | 解決方案 |
|---|---|---|
| 部署期間超時(shí) | 在不指定?wait_for?參數(shù)的情況下，它默認(rèn)為?started，這意味著只有當(dāng)模型下載完成并成功部署時(shí)，你才會(huì)收到響應(yīng)。然而，這個(gè)過(guò)程會(huì)相當(dāng)耗時(shí)，具體取決于模型大小，而且由于?timeout?參數(shù)也默認(rèn)為僅 30 秒，這通常會(huì)導(dǎo)致錯(cuò)誤。 | 請(qǐng)改用 wait_for="starting"，和/或 增加引發(fā)錯(cuò)誤之前的等待時(shí)間：timeout="3m" |
| 不按順序運(yùn)行這些步驟（具體示例請(qǐng)參閱下面的行） | 在上一步完成運(yùn)行之前運(yùn)行命令將導(dǎo)致錯(cuò)誤： | 使用 status = client.ml.get_trained_models(model_id=".elser_model_2", include="definition_status") 檢查模型的狀態(tài) |
| 嘗試在模型完全下載之前部署模型 | Model definition truncated. Unable to deserialize trained model definition [.elser_model_2] |
你應(yīng)該僅在 status["trained_model_configs"][0]["complete_define"] == True 時(shí)嘗試部署模型 |
| 嘗試對(duì)尚未完全部署的模型運(yùn)行推理 | 404, 'resource_not_found_exception', 'Could not find trained model [.elser_model_2]' |
在運(yùn)行推理之前
一旦模型部署完成，你就可以開(kāi)始對(duì)其進(jìn)行推理調(diào)用。這可以通過(guò) inference?API 來(lái)完成：
response = client.ml.infer_trained_model(
model_id=model_id,
docs=[{"text_field": query}])這個(gè)推理命令也有一個(gè)默認(rèn)的超時(shí)時(shí)間為 10 秒，當(dāng)一次生成少量文檔的嵌入時(shí)是足夠的。
然而，對(duì)于大多數(shù)實(shí)際用例，將會(huì)有大量需要處理的文檔；例如，在一個(gè)大型索引中為每個(gè)文檔創(chuàng)建嵌入以啟用語(yǔ)義搜索功能。
你可以增加超時(shí)時(shí)間：
response = client.ml.infer_trained_model(model_id=model_id, docs=docs, timeout="5m")然而，正如前面的部分所提到的，根據(jù)分配的數(shù)量或發(fā)送到同一部署的不同任務(wù)的數(shù)量，模型也將有一個(gè)最大文檔隊(duì)列接受限制。因此，即使設(shè)置了較長(zhǎng)的超時(shí)時(shí)間，對(duì)于大吞吐量來(lái)說(shuō)，這種方法可能仍然不足夠。
另一個(gè)選擇是為推理過(guò)程創(chuàng)建攝入管道。你還可以為不同的管道使用不同的部署：一個(gè)用于在攝入新數(shù)據(jù)時(shí)生成嵌入，另一個(gè)用于在搜索時(shí)運(yùn)行推理。 管道還允許你通過(guò)在 processors 列表中添加元素來(lái)設(shè)置自定義操作，例如重命名字段或?yàn)椴煌蝿?wù)使用多個(gè)模型。你還可以在后臺(tái)或按照定期時(shí)間表運(yùn)行較長(zhǎng)的任務(wù)。
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 | 與前面的步驟類(lèi)似，冗長(zhǎng)的管道過(guò)程可能會(huì)導(dǎo)致超時(shí)。 使用 wait_for_completion = False 參數(shù)。 |
| Waiting for pipeline to finish | 你可以使用從 reindex 函數(shù)獲得的任務(wù) ID 稍后通過(guò) client.tasks.get(task_id=task_id) 跟蹤管道進(jìn)度。 使用 wait_for_completion 參數(shù)時(shí)會(huì)生成此 ID。 |
監(jiān)控和調(diào)整
一旦你部署了模型并開(kāi)始使用推理服務(wù)，你可以查看配置的性能。通常，這是確定特定用例的適當(dāng)參數(shù)的最佳方法，并根據(jù)需要進(jìn)行調(diào)整，直到達(dá)到所需的性能。
舉一個(gè)簡(jiǎn)單的例子，如果你部署了一個(gè)模型而沒(méi)有配置上述討論的任何設(shè)置，這些將是分配的默認(rèn)值：
{
"threads_per_allocation" : 1,
"number_of_allocations" : 1,
"queue_capacity" : 1024
}假設(shè)通過(guò)推理管道將大量文檔發(fā)送到該模型后，我們注意到線程分配中的一些警告信號(hào)。 endpoint：
GET _nodes/hot_threads響應(yīng)：
ml.allocated_processors=16
100.0% [cpu=3.5%, other=96.5%] cpu usage by threadML 節(jié)點(diǎn)分配有 16 個(gè)處理器，但我們僅在模型的一個(gè)實(shí)例中利用其中 1 個(gè)處理器。 此外，在其他而不是與 CPU 相關(guān)的任務(wù)下報(bào)告的高利用率意味著該過(guò)程中存在大量等待和冗余，并且我們的文檔大部分時(shí)間都在排隊(duì)。
為了優(yōu)化性能，你應(yīng)該使用所有可用的內(nèi)核。
你還可以在訓(xùn)練模型 UI 中或通過(guò)以下命令查看更多指標(biāo)：
GET _ml/trained_models/_stats在這里你可以看到更多有用的信息，例如 average_inference_time_ms、number_of_pending_requests 或 peak_throughput_per_分鐘。
作為說(shuō)明，這里有兩個(gè)模型部署在同一個(gè) ML 節(jié)點(diǎn)上，在相同的管道和數(shù)據(jù)上運(yùn)行推理，但采用不同的分配策略。 你可以看到配置模型的推理時(shí)間幾乎減半。
| Model ID | Allocation | Average Inference time |
|---|---|---|
| elser_inference_configured | 3 * 8 | 67.80 milliseconds |
| .elser_model_2 | 1 * 1 | 115.58 milliseconds |
結(jié)論
這既是一件好事，也可能是一件困難的事情，有多種靈活和模塊化的方法來(lái)構(gòu)建適合你的項(xiàng)目的推理架構(gòu)。 為每個(gè)用例構(gòu)建最佳方法也不僅僅是選擇正確的配置或基礎(chǔ)設(shè)施設(shè)置。 你可以詳細(xì)了解模型的檢索優(yōu)化甚至數(shù)據(jù)處理決策（例如分塊策略）如何影響性能。
Elasticsearch 匯集了令人驚嘆的開(kāi)箱即用功能，并提供自定義選項(xiàng)和指導(dǎo)，幫助你構(gòu)建最佳的語(yǔ)義搜索解決方案。
準(zhǔn)備好將 RAG 構(gòu)建到你的應(yīng)用程序中了嗎？ 想要嘗試使用向量數(shù)據(jù)庫(kù)的不同 LLMs？
在 Github 上查看我們的 LangChain、Cohere 等示例 notebooks，并參加即將開(kāi)始的 Elasticsearch 工程師培訓(xùn)！文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-858189.html
原文：?Scaling ML Inference Pipelines in Elasticsearch: How to avoid issues and troubleshoot bottlenecks — Elastic Search Labs文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-858189.html
到了這里，關(guān)于在 Elasticsearch 中擴(kuò)展 ML 推理管道：如何避免問(wèn)題并解決瓶頸的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
