對我們來說，這是非常忙碌的幾周，因為我們正在努力根據您的反饋改進我們的產品特性，并擴展生態系統以涵蓋其它場景和用例。

讓我們看看我們所做的最重要的更改。有關更詳細的列表，您可以隨時參考我們的完整 [新版本說明]。

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

生成式 AI 正在被應用程序設計人員快速地使用著。這不僅體現在使用來自商業云服務模型的傳統REST API形式上，而且還發生在客戶端和邊緣。越來越多的數據正在客戶端處理，通過AIPC，我們為此開始看到更多的機會。其中一種場景是人工智能助手，它能夠生成文本（郵件草稿、文檔摘要、文檔內容的答案等等）。這一切都由 LLM（大型語言模型）和不斷增長的 SLM（小型語言模型）系列提供支持。

我們引入了新的軟件包 openvino-genai，它使用OpenVINO 以及其中的openvino_tokenizers，因此如果您打算運行 LLM，安裝此軟件包就足夠了。經典的 OpenVINO API 也支持其它類型的模型，因此現在流水線構建變得更加容易。我們的安裝選項也進行了更新，以便反映并指導使用新軟件包，因此請在那里查看您最合適的選項。經典的 OpenVINO 軟件包仍然存在，如果您暫時不打算使用生成式 API，請繼續使用 openvino 軟件包。

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

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

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

第一步

通過Hugging Face Optimum-Intel導出

LLM 模型（我們使用了針對聊天微調的 Tiny Llama）

以下是將OpenVINO IR格式的LLM模型導出為FP16或INT4精度的兩種方式。為了使LLM推理性能更高，我們建議對模型權重使用較低的精度，即INT4，并在模型導出過程中直接使用神經網絡壓縮框架（NNCF）壓縮權重，如下所示。

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進行生成

通過新的C++ API進行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
}

通過新的 Python API 進行生成

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

如您所見，只需要幾行代碼就能建立一個LLM生成的流水線。這是因為，從 Hugging Face Optimum-Intel 導出模型后，它已經存儲了執行所需的所有信息，包括分詞器/反分詞器和生成配置，從而能夠獲得與 Hugging Face 生成匹配的結果。我們提供 C++ 和 Python API 來運行 LLM、最少的依賴項列表和對應用程序的添加。

為了實現生成式模型更具交互性的UI界面，我們添加了對模型輸出分詞流式處理的支持。在下面的示例中，我們使用簡單的 lambda 函數在模型生成單詞后立即將單詞輸出到控制臺：

#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);
}

您也可以創建自定義流處理器進行更復雜的處理，這在我們的 [文檔] 中進行了描述。

最后，我們還研究了聊天場景，其中輸入和輸出代表對話，并且有機會以在輸入之間保留 KV緩存 的形式進行優化。為此，我們引入了聊天特定方法 start_chat 和 finish_chat，它們用于標記會話的開始和結束。下面是一個非常簡單的 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 作為目標設備，但 GPU 也同樣是支持的。請記住，GPU 將為 LLM 本身運行推理，分詞選擇邏輯和分詞化/去分詞化將保留在 CPU 上，因為這更有效率。內置的分詞器以單獨的模型形式表示，并通過我們的推理功能在 CPU 上運行。

這個 API 使我們能夠更靈活、更優化地實現生成邏輯，并不斷擴展。請繼續關注后續發布版本中的更多功能！

同時，請務必查看我們的 [文檔] 和 [示例] 以獲取新的 API，嘗試后告訴我們你的想法。

通過OpenVINO擴展模型服務

通過服務化部署模型是一個非常成熟的方法論，并且隨著基于微服務的部署不僅在傳統的云環境中擴展，同時也在向邊緣計算領域擴展，這一需求日益增長。更多的應用被開發為微服務，并部署在智能邊緣和云中。在2024.2 版本中，我們引入了對服務場景的額外支持。讓我們來看看最重要的變化。

OpenVINO模型服務器是我們長期開發的模型服務解決方案，它被應用程序廣泛采用，以最有效的方式為模型提供服務。在此版本中，我們引入了通過稱為連續批處理的機制為LLM提供高效服務的能力。

從本質上講，連續批處理允許我們通過將多個請求合并到批處理中來以最有效的方式實現推理服務。由于生成過程中上下文大小的差異，傳統批處理文本生成方案的方式非常有限。實際上，不可能找到兩個相同長度的不同請求并生成相同長度的輸出來執行傳統的請求批處理。為了解決這個問題，我們采用了分頁注意力方法，就像在 vLLM 實現中的那樣。這使我們能夠將多個請求合并到同一模型中，并提高硬件利用率。不過，調度請求的內部邏輯是不同的，我們考慮了 CPU 在設計時使其更高效的細節，結合了高吞吐量和低延遲，使其更高效。

為了以最適應應用程序的方式部署 LLM，我們在文本生成的使用場景實現了 OpenAI 兼容的API。我們的實現包括 連續批處理和分頁注意力算法，因此文本生成可以在高并發負載下快速高效。這使得您可以允許在云中或本地（如果需要的話）創建自己的類似 OpenAI 的 LLM 服務端點。

盡管 LLM 備受矚目，但傳統的深度學習模型作為獨立解決方案或大型流程的一部分仍有著高度需求。OVMS 可以長時間高效地部署這些模型，但對其它部署解決方案的需求非常高，因此我們為服務場景引入了一些額外的 OpenVINO 集成：通過 TorchServe 和 Nvidia Triton 提供服務。

OpenVINO 長期以來一直為 Triton Serving 提供后端，我們最近與 Nvidia 工程師合作，重新設計了它的附加功能，例如支持動態輸入。您可以在我們的博客文章中查看有關如何在 Triton 中使用 OpenVINO 的更多詳細信息。

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

性能提升

我們仍然專注于 AI 模型的性能表現。盡管 AIPC 的出現，LLM 在客戶端的采用仍然對底層硬件產生壓力。我們的優化工作覆蓋了不同的支持目標，包括 CPU、GPU 和 NPU。

AIPC與傳統PC的不同在于它集成了專門的硬件加速器，隨著AI應用場景從云端轉向個人計算領域，其重要性日益增加。英特爾酷睿Ultra處理器提供了更強大的GPU以及NPU。從性能和效率的角度來看，這些都讓加速解決方案更具吸引力。

如果平臺性能不足，我們始終能夠通過添加我們的ARC系列獨立顯卡進行加速，來實現進一步的性能提升。為了幫助實現LLM部署特性，我們一直專注于加速GPU的LLM的推理性能，覆蓋了集成顯卡和獨立顯卡。將負載卸載到 GPU 不僅是因為它的特性適宜處理這類工作負載，還因為需要保持 CPU 可用。因此，推理期間的 CPU 負載對于此類情況至關重要。我們一直在努力優化 CPU 端負載并減少主機代碼延遲至少一半。這也使我們能夠實現更好的 GPU 特性，因為內核調度現在更加高效。

此外，我們還致力于少數GPU基本操作的更高效實現，包括 Scaled Dot Product Attention 和 Positional Embeddings 的融合版本。這不僅改善了延遲，還減少了推理期間的主機開銷和整體內存消耗，這對于在筆記本電腦上運行 LLM 等場景至關重要。

獨立顯卡上一些LLM的延遲已經降低，我們正與oneDNN團隊的合作伙伴一起，繼續我們的優化之旅。

雖然我們經常談論 GPU，但 CPU 等其他目標設備的性能也有所改進。在CPU上，第二個分詞延遲的性能得到了明顯改善，以及在基于AVX2（13代英特爾酷睿處理器）和AVX512（第三代至強可擴展處理器）的CPU平臺上，FP16權重的LLM的內存占用情況也得到了明顯改善，尤其是在小批量的情況下。更不用說，我們還在 Optimum-Intel 集成中持續增加了對新模型的覆蓋。

新模型和notebooks示例

在每次發布的新版本中，我們都會繼續擴大對新模型的支持，以及增加新的Notebook代碼示例，展示如何在這些使用用例中利用OpenVINO。對于新模型，我們增加了對TensorFlow*Hub的mil-nce和openimages-v4-sd-mobilent-v2的支持，以及Phi-3-mini：這是一個AI模型家族，利用小語言模型的力量實現更快、更準確和更具成本效益的文本處理。

Notebooks代碼示例可以成為用戶學習和體驗的寶貴內容。在這個版本中，我們添加了幾個新的Notebooks。最值得注意的是用于動畫圖像的DynamiCrafter notebook，用于轉換和優化YOLOv10為OpenVINO的notebook，以及在現有LLMChatbot notebook中添加Phi-3-mini模型，以便用戶可以嘗試更多的LLM模型。

總結

在此，我們興奮地宣布OpenVINO 2024.2最新版本現已開放下載！

我們的團隊一直致力于各項新特性和性能提升的研發。一如既往，我們努力不斷優化用戶體驗，拓寬OpenVINO的功能邊界。我們的開發路線圖上已經規劃了下一版本的諸多特性，迫不及待在未來與您分享。感謝大家的支持與厚愛！