OpenVINO 2024.2版本亮點(diǎn)解析

對(duì)我們來(lái)說(shuō)，這是非常忙碌的幾周，因?yàn)槲覀冋谂Ω鶕?jù)您的反饋改進(jìn)我們的產(chǎn)品特性，并擴(kuò)展生態(tài)系統(tǒng)以涵蓋其它場(chǎng)景和用例。

讓我們看看我們所做的最重要的更改。有關(guān)更詳細(xì)的列表，您可以隨時(shí)參考我們的完整 [新版本說(shuō)明]。

隆重推出 OpenVINO.GenAI 軟件包和 LLM特定 API

生成式 AI 正在被應(yīng)用程序設(shè)計(jì)人員快速地使用著。這不僅體現(xiàn)在使用來(lái)自商業(yè)云服務(wù)模型的傳統(tǒng)REST API形式上，而且還發(fā)生在客戶(hù)端和邊緣。越來(lái)越多的數(shù)據(jù)正在客戶(hù)端處理，通過(guò)AIPC，我們?yōu)榇碎_(kāi)始看到更多的機(jī)會(huì)。其中一種場(chǎng)景是人工智能助手，它能夠生成文本（郵件草稿、文檔摘要、文檔內(nèi)容的答案等等）。這一切都由 LLM（大型語(yǔ)言模型）和不斷增長(zhǎng)的 SLM（小型語(yǔ)言模型）系列提供支持。

我們引入了新的軟件包 openvino-genai，它使用OpenVINO 以及其中的openvino_tokenizers，因此如果您打算運(yùn)行 LLM，安裝此軟件包就足夠了。經(jīng)典的 OpenVINO API 也支持其它類(lèi)型的模型，因此現(xiàn)在流水線構(gòu)建變得更加容易。我們的安裝選項(xiàng)也進(jìn)行了更新，以便反映并指導(dǎo)使用新軟件包，因此請(qǐng)?jiān)谀抢锊榭茨詈线m的選項(xiàng)。經(jīng)典的 OpenVINO 軟件包仍然存在，如果您暫時(shí)不打算使用生成式 API，請(qǐng)繼續(xù)使用 openvino 軟件包。

為了通過(guò) LLM 生成結(jié)果，應(yīng)用程序需要執(zhí)行整個(gè)操作流水線：執(zhí)行輸入文本的分詞，處理輸入上下文，迭代生成模型答案的后續(xù)輸出分詞，最后將答案從分詞解碼為純文本。每個(gè)分詞的生成都是推理調(diào)用，然后是后續(xù)邏輯來(lái)選擇分詞本身。邏輯可以是貪婪搜索的形式，也就是選擇最可能的分詞，也可以是波束搜索的形式，即保持很少的序列并選擇其中最好的。

雖然OpenVINO在推理方面大放異彩，但正如我們剛才所討論的，這還不足以涵蓋整個(gè)文本生成的流水線。在 2024.2 版本之前，我們提供了幫助程序（分詞器和示例）來(lái)實(shí)現(xiàn)這一點(diǎn)，但應(yīng)用程序必須使用這些組件實(shí)現(xiàn)整個(gè)生成邏輯。現(xiàn)在這種情況正在發(fā)生改變。

在 24.2 版本中，我們引入了特定于 LLM 的 API，這些 API 隱藏了內(nèi)部生成循環(huán)的復(fù)雜性，并顯著減少了需要在應(yīng)用程序中編寫(xiě)的代碼量。通過(guò)使用特定于 LLM 的 API，您可以加載模型，向其傳遞上下文，并通過(guò)幾行代碼返回響應(yīng)。在內(nèi)部，OpenVINO將對(duì)輸入文本進(jìn)行分詞化，在您選擇的設(shè)備上執(zhí)行生成循環(huán)，并為您提供答案。讓我們一步一步地看看這是如何使用Python和C++完成的。

第一步

通過(guò)Hugging Face Optimum-Intel導(dǎo)出

LLM 模型（我們使用了針對(duì)聊天微調(diào)的 Tiny Llama）

以下是將OpenVINO IR格式的LLM模型導(dǎo)出為FP16或INT4精度的兩種方式。為了使LLM推理性能更高，我們建議對(duì)模型權(quán)重使用較低的精度，即INT4，并在模型導(dǎo)出過(guò)程中直接使用神經(jīng)網(wǎng)絡(luò)壓縮框架（NNCF）壓縮權(quán)重，如下所示。

FP16：

optimum-cli export openvino --model "TinyLlama/TinyLlama-1.1B-Chat-v1.0" --weight-format fp16 --trust-remote-code

INT4：

optimum-cli export openvino --model "TinyLlama/TinyLlama-1.1B-Chat-v1.0" --weight-format int4 --trust-remote-code

第二步

使用C++或Python進(jìn)行生成

通過(guò)新的C++ API進(jìn)行LLM生成

#include "openvino/genai/llm_pipeline.hpp"
#include 


int main(int argc, char* argv[]) {
    std::string model_path = argv[1];
    ov::LLMPipeline pipe(model_path, "CPU");//target device is CPU
    std::cout << pipe.generate("The Sun is yellow bacause"); //input context
}

通過(guò)新的 Python API 進(jìn)行生成

import openvino_genai as ov_genai
pipe = ov_genai.LLMPipeline(model_path, "CPU")
print(pipe.generate("TheSunisyellowbacause"))

如您所見(jiàn)，只需要幾行代碼就能建立一個(gè)LLM生成的流水線。這是因?yàn)?，?Hugging Face Optimum-Intel 導(dǎo)出模型后，它已經(jīng)存儲(chǔ)了執(zhí)行所需的所有信息，包括分詞器/反分詞器和生成配置，從而能夠獲得與 Hugging Face 生成匹配的結(jié)果。我們提供 C++ 和 Python API 來(lái)運(yùn)行 LLM、最少的依賴(lài)項(xiàng)列表和對(duì)應(yīng)用程序的添加。

為了實(shí)現(xiàn)生成式模型更具交互性的UI界面，我們添加了對(duì)模型輸出分詞流式處理的支持。在下面的示例中，我們使用簡(jiǎn)單的 lambda 函數(shù)在模型生成單詞后立即將單詞輸出到控制臺(tái)：

#include "openvino/genai/llm_pipeline.hpp"
#include 


int main(int argc, char* argv[]) {
    std::string model_path = argv[1];
    ov::LLMPipeline pipe(model_path, "CPU");
        
    auto streamer = [](std::string word) { std::cout << word << std::flush; };
    std::cout << pipe.generate("The Sun is yellow bacause", streamer);
}

您也可以創(chuàng)建自定義流處理器進(jìn)行更復(fù)雜的處理，這在我們的 [文檔] 中進(jìn)行了描述。

最后，我們還研究了聊天場(chǎng)景，其中輸入和輸出代表對(duì)話，并且有機(jī)會(huì)以在輸入之間保留 KV緩存 的形式進(jìn)行優(yōu)化。為此，我們引入了聊天特定方法 start_chat 和 finish_chat，它們用于標(biāo)記會(huì)話的開(kāi)始和結(jié)束。下面是一個(gè)非常簡(jiǎn)單的 C++ 示例：

int main(int argc, char* argv[]) {
    std::string prompt;


    std::string model_path = argv[1];
    ov::LLMPipeline pipe(model_path, "CPU");
    
    pipe.start_chat();
    for (;;) {
        std::cout << "question:
";
        std::getline(std::cin, prompt);
        if (prompt == "Stop!")
            break;


        std::cout << "answer:
";
        auto answer = pipe(prompt);
        std::cout << answer << std::endl;
    }
    pipe.finish_chat();
}

在上面的所有示例中，我們都使用 CPU 作為目標(biāo)設(shè)備，但 GPU 也同樣是支持的。請(qǐng)記住，GPU 將為 LLM 本身運(yùn)行推理，分詞選擇邏輯和分詞化/去分詞化將保留在 CPU 上，因?yàn)檫@更有效率。內(nèi)置的分詞器以單獨(dú)的模型形式表示，并通過(guò)我們的推理功能在 CPU 上運(yùn)行。

這個(gè) API 使我們能夠更靈活、更優(yōu)化地實(shí)現(xiàn)生成邏輯，并不斷擴(kuò)展。請(qǐng)繼續(xù)關(guān)注后續(xù)發(fā)布版本中的更多功能！

同時(shí)，請(qǐng)務(wù)必查看我們的 [文檔] 和 [示例] 以獲取新的 API，嘗試后告訴我們你的想法。

通過(guò)OpenVINO擴(kuò)展模型服務(wù)

通過(guò)服務(wù)化部署模型是一個(gè)非常成熟的方法論，并且隨著基于微服務(wù)的部署不僅在傳統(tǒng)的云環(huán)境中擴(kuò)展，同時(shí)也在向邊緣計(jì)算領(lǐng)域擴(kuò)展，這一需求日益增長(zhǎng)。更多的應(yīng)用被開(kāi)發(fā)為微服務(wù)，并部署在智能邊緣和云中。在2024.2 版本中，我們引入了對(duì)服務(wù)場(chǎng)景的額外支持。讓我們來(lái)看看最重要的變化。

OpenVINO模型服務(wù)器是我們長(zhǎng)期開(kāi)發(fā)的模型服務(wù)解決方案，它被應(yīng)用程序廣泛采用，以最有效的方式為模型提供服務(wù)。在此版本中，我們引入了通過(guò)稱(chēng)為連續(xù)批處理的機(jī)制為L(zhǎng)LM提供高效服務(wù)的能力。

從本質(zhì)上講，連續(xù)批處理允許我們通過(guò)將多個(gè)請(qǐng)求合并到批處理中來(lái)以最有效的方式實(shí)現(xiàn)推理服務(wù)。由于生成過(guò)程中上下文大小的差異，傳統(tǒng)批處理文本生成方案的方式非常有限。實(shí)際上，不可能找到兩個(gè)相同長(zhǎng)度的不同請(qǐng)求并生成相同長(zhǎng)度的輸出來(lái)執(zhí)行傳統(tǒng)的請(qǐng)求批處理。為了解決這個(gè)問(wèn)題，我們采用了分頁(yè)注意力方法，就像在 vLLM 實(shí)現(xiàn)中的那樣。這使我們能夠?qū)⒍鄠€(gè)請(qǐng)求合并到同一模型中，并提高硬件利用率。不過(guò)，調(diào)度請(qǐng)求的內(nèi)部邏輯是不同的，我們考慮了 CPU 在設(shè)計(jì)時(shí)使其更高效的細(xì)節(jié)，結(jié)合了高吞吐量和低延遲，使其更高效。

為了以最適應(yīng)應(yīng)用程序的方式部署 LLM，我們?cè)谖谋旧傻氖褂脠?chǎng)景實(shí)現(xiàn)了 OpenAI 兼容的API。我們的實(shí)現(xiàn)包括 連續(xù)批處理和分頁(yè)注意力算法，因此文本生成可以在高并發(fā)負(fù)載下快速高效。這使得您可以允許在云中或本地（如果需要的話）創(chuàng)建自己的類(lèi)似 OpenAI 的 LLM 服務(wù)端點(diǎn)。

盡管 LLM 備受矚目，但傳統(tǒng)的深度學(xué)習(xí)模型作為獨(dú)立解決方案或大型流程的一部分仍有著高度需求。OVMS 可以長(zhǎng)時(shí)間高效地部署這些模型，但對(duì)其它部署解決方案的需求非常高，因此我們?yōu)榉?wù)場(chǎng)景引入了一些額外的 OpenVINO 集成：通過(guò) TorchServe 和 Nvidia Triton 提供服務(wù)。

OpenVINO 長(zhǎng)期以來(lái)一直為 Triton Serving 提供后端，我們最近與 Nvidia 工程師合作，重新設(shè)計(jì)了它的附加功能，例如支持動(dòng)態(tài)輸入。您可以在我們的博客文章中查看有關(guān)如何在 Triton 中使用 OpenVINO 的更多詳細(xì)信息。

服務(wù)功能的另一個(gè)重要補(bǔ)充是通過(guò)使用 torch.compile 的 OpenVINO 后端，使用 TorchServe 為模型提供服務(wù)。在引入 torch.compile 之后，TorchServe 引入了通過(guò)不同后端加速服務(wù)的功能。這正是OpenVINO現(xiàn)在發(fā)生的事情，我們提供了在TorchServe中指定OpenVINO作為后端的功能。有關(guān)更多詳細(xì)信息，您可以查看示例，這些示例非常簡(jiǎn)單且不言自明。

性能提升

我們?nèi)匀粚?zhuān)注于 AI 模型的性能表現(xiàn)。盡管 AIPC 的出現(xiàn)，LLM 在客戶(hù)端的采用仍然對(duì)底層硬件產(chǎn)生壓力。我們的優(yōu)化工作覆蓋了不同的支持目標(biāo)，包括 CPU、GPU 和 NPU。

AIPC與傳統(tǒng)PC的不同在于它集成了專(zhuān)門(mén)的硬件加速器，隨著AI應(yīng)用場(chǎng)景從云端轉(zhuǎn)向個(gè)人計(jì)算領(lǐng)域，其重要性日益增加。英特爾酷睿Ultra處理器提供了更強(qiáng)大的GPU以及NPU。從性能和效率的角度來(lái)看，這些都讓加速解決方案更具吸引力。

如果平臺(tái)性能不足，我們始終能夠通過(guò)添加我們的ARC系列獨(dú)立顯卡進(jìn)行加速，來(lái)實(shí)現(xiàn)進(jìn)一步的性能提升。為了幫助實(shí)現(xiàn)LLM部署特性，我們一直專(zhuān)注于加速GPU的LLM的推理性能，覆蓋了集成顯卡和獨(dú)立顯卡。將負(fù)載卸載到 GPU 不僅是因?yàn)樗奶匦赃m宜處理這類(lèi)工作負(fù)載，還因?yàn)樾枰３?CPU 可用。因此，推理期間的 CPU 負(fù)載對(duì)于此類(lèi)情況至關(guān)重要。我們一直在努力優(yōu)化 CPU 端負(fù)載并減少主機(jī)代碼延遲至少一半。這也使我們能夠?qū)崿F(xiàn)更好的 GPU 特性，因?yàn)閮?nèi)核調(diào)度現(xiàn)在更加高效。

此外，我們還致力于少數(shù)GPU基本操作的更高效實(shí)現(xiàn)，包括 Scaled Dot Product Attention 和 Positional Embeddings 的融合版本。這不僅改善了延遲，還減少了推理期間的主機(jī)開(kāi)銷(xiāo)和整體內(nèi)存消耗，這對(duì)于在筆記本電腦上運(yùn)行 LLM 等場(chǎng)景至關(guān)重要。

獨(dú)立顯卡上一些LLM的延遲已經(jīng)降低，我們正與oneDNN團(tuán)隊(duì)的合作伙伴一起，繼續(xù)我們的優(yōu)化之旅。

雖然我們經(jīng)常談?wù)?GPU，但 CPU 等其他目標(biāo)設(shè)備的性能也有所改進(jìn)。在CPU上，第二個(gè)分詞延遲的性能得到了明顯改善，以及在基于AVX2（13代英特爾酷睿處理器）和AVX512（第三代至強(qiáng)可擴(kuò)展處理器）的CPU平臺(tái)上，F(xiàn)P16權(quán)重的LLM的內(nèi)存占用情況也得到了明顯改善，尤其是在小批量的情況下。更不用說(shuō)，我們還在 Optimum-Intel 集成中持續(xù)增加了對(duì)新模型的覆蓋。

新模型和notebooks示例

在每次發(fā)布的新版本中，我們都會(huì)繼續(xù)擴(kuò)大對(duì)新模型的支持，以及增加新的Notebook代碼示例，展示如何在這些使用用例中利用OpenVINO。對(duì)于新模型，我們?cè)黾恿藢?duì)TensorFlow*Hub的mil-nce和openimages-v4-sd-mobilent-v2的支持，以及Phi-3-mini：這是一個(gè)AI模型家族，利用小語(yǔ)言模型的力量實(shí)現(xiàn)更快、更準(zhǔn)確和更具成本效益的文本處理。

Notebooks代碼示例可以成為用戶(hù)學(xué)習(xí)和體驗(yàn)的寶貴內(nèi)容。在這個(gè)版本中，我們添加了幾個(gè)新的Notebooks。最值得注意的是用于動(dòng)畫(huà)圖像的DynamiCrafter notebook，用于轉(zhuǎn)換和優(yōu)化YOLOv10為OpenVINO的notebook，以及在現(xiàn)有LLMChatbot notebook中添加Phi-3-mini模型，以便用戶(hù)可以嘗試更多的LLM模型。

總結(jié)

在此，我們興奮地宣布OpenVINO 2024.2最新版本現(xiàn)已開(kāi)放下載！

我們的團(tuán)隊(duì)一直致力于各項(xiàng)新特性和性能提升的研發(fā)。一如既往，我們努力不斷優(yōu)化用戶(hù)體驗(yàn)，拓寬OpenVINO的功能邊界。我們的開(kāi)發(fā)路線圖上已經(jīng)規(guī)劃了下一版本的諸多特性，迫不及待在未來(lái)與您分享。感謝大家的支持與厚愛(ài)！