隨著我們迎來嶄新的一年，是時候在生成式人工智能領域大放異彩地開啟2024年了。我們在這里發(fā)布最新、最偉大的推理工具，這將使您在新的一年中的編碼之旅變得異常精彩。OpenVINO? 的最新版本引入了額外的框架更改，優(yōu)化了生成式AI模型的特性，并增強了對現(xiàn)有平臺的支持。讓我們來了解一下一些重要的更新。

大語言模型推理的提升

LLM繼續(xù)成為頭條新聞，幾乎每周都會更換頭部領導者和最先進的技術。目前還沒有改變的是高效運行這些模型所需的計算量和其他資源的數(shù)量。我們繼續(xù)致力于實現(xiàn)越來越多的優(yōu)化，以實現(xiàn)對這些模型的推理，包括在資源非常有限的環(huán)境中進行推理。2023.3長期支持版本帶來了優(yōu)化LLM推理的重要更改。

■ 優(yōu)化KV-緩存處理

LLM是基于Transformer的模型，也是其中一種優(yōu)化技術，專門用于生成任務，即所謂的KV緩存。這種方法利用了這樣一個事實，即模型基于以前的令牌生成每個新令牌，并執(zhí)行大量冗余計算。為了避免這種計算，內(nèi)部模型嵌入被緩存起來并在下一個周期中被重用。實際上，這意味著當使用這樣的模型時，您需要從模型的某些輸出中獲得嵌入，存儲這些數(shù)據(jù)，并在按順序生成下一個令牌時將其傳遞給模型輸入。這種方法通常被稱為KV緩存，是一種眾所周知的技術（例如： https://medium.com/@joaolages/kv-caching-explained-276520203249 ）。雖然它有效地加速了模型推理，但它并不理想，因為緩存需要多個內(nèi)存副本，很容易增長超過幾GB，并隨著上下文的增長而降低性能。這一切都是為了服務數(shù)據(jù)，您無法解釋，也永遠不會直接使用這些數(shù)據(jù)。

在本版本中，OpenVINO? 引入了對模型轉換、優(yōu)化工具和運行時的修改，以所謂的狀態(tài)模型格式轉換模型，其中KV Cache保持在模型本身的狀態(tài)，并由運行時透明地處理。不再需要獲取、存儲和傳遞KV緩存，運行時會自動處理。分配內(nèi)存、選擇高效布局等。這種方法使我們能夠顯著優(yōu)化資源使用并提高性能。使用模型變得越來越容易，因為輸入和輸出的數(shù)量顯著減少，并且不再需要顯式存儲任何內(nèi)容。默認情況下，當從Hugging Face導出模型時，它們將以新的狀態(tài)模型格式出現(xiàn)。

如果您正在使用Hugging Face API并使用我們的Optimum-Intel軟件包運行OpenVINO?，則此更改對您來說是透明的，無需修改代碼。如果您直接執(zhí)行模型推理，則需要對代碼進行微小的更改才能開始使用此功能。主要是從代碼中刪除與KV緩存相關的所有內(nèi)容。

對于緩存變大的大型文本提示，這次的改進尤其明顯，因此如果您正在實現(xiàn)某種RAG場景，這可能是一個非常有趣的功能。該方法同時適用于Greedy和Beam搜索機制。

■ 額外的低精度運行時優(yōu)化

我們在上一版本中介紹了LLM的int8和int4權重壓縮，包括在模型優(yōu)化框架（NNCF）中的支持。還有一些性能可以進一步優(yōu)化，我們正在這個版本中修復它。

首先，現(xiàn)在所有CPU都以高性能的方式完全支持int4和int8權重壓縮方案。這包括Xeon平臺，以前通過OpenVINO?運行時缺乏這種支持。當然，它在客戶端/邊緣CPU上也是支持的（比如我們最近發(fā)布的Meteor Lake）。

其次，除了對單個操作進行許多優(yōu)化外，我們還對CPU和GPU的首次令牌生成延遲進行了實質(zhì)性優(yōu)化，這提高了總體生成時間方面的性能。對于短小的提示詞，這些差異并不是那么關鍵，但對于大型上下文（聊天機器人、RAG驅動的應用程序），這在性能方面是一個非常好的補充。

此外，在壓縮模型時，雖然性能至關重要，但您仍然希望確保模型執(zhí)行的準確度。為了促進這一點，我們引入了一種數(shù)據(jù)感知權重壓縮算法，該算法使用數(shù)據(jù)集輸入來選擇單個transformer層權重的精度。它允許更精確的模型權重壓縮。您可以在此處找到更多信息：https://docs.openvino.ai/nightly/weight_compression.html

■ 更好更高效地使用OpenVINO?原生API運行生成式模型

我們通過Optimum Intel與Hugging Face的集成非常棒，可以幫助您快速運行推理，只需要修改兩行代碼。然而，在某些情況下，OpenVINO? 原生 API可以為您提供更好的服務。C++應用程序需要可控的安裝、最小的占用等等。在這種情況下，我們建議為OpenVINO? 原生API編寫應用程序，并從我們擁有的最小分發(fā)版本中獲益。在本版本中，我們介紹了一些更改，旨在幫助快速輕松地編寫OpenVINO?支持的推理應用程序。

首先，我們在OpenVINO?中添加了對字符串張量和標記化的支持。這意味著您可以在處理模型輸入和輸出時使用字符串類型（如果模型支持的話）。這種模型的一個例子是分詞器本身——您現(xiàn)在可以將Hugging Face分詞器轉換為OpenVINO?模型，并推理該模型來執(zhí)行分詞化/去分詞化步驟。只需傳遞字符串并獲得分詞化表示。分詞化支持是作為一個額外的OpenVINO?包實現(xiàn)的，例如，您需要通過pip或conda單獨安裝它。

最重要的是，我們正在引入一個新的范例倉庫，專門用于生成式AI模型。在這里，您可以找到展示如何使用Stable Diffusion進行圖像生成或使用LLaMa2模型進行文本生成等的示例。使用OpenVINO ? API的完整文本生成示例非常簡單，只需70行代碼，除了OpenVINO?運行時和分詞器之外，不需要任何組件——我們希望它能極大地簡化學習路徑。如果您覺得我們?nèi)鄙偈裁矗部梢噪S時提供您代碼示例！

新平臺的支持和現(xiàn)有平臺上的提升

2023年以我們重要的平臺發(fā)布，即第五代Xeon（代號Emerald Rapids）和全新的Meteor Lake平臺的發(fā)布而結束。此次發(fā)布的OpenVINO?引入了一些更改，使我們能夠更有效地支持這些平臺。我們增強了線程機制，以便對任務執(zhí)行高效的核分配，并與oneTBB團隊合作，確保順利支持。這一切都是透明的，OpenVINO?只是繼續(xù)在新平臺上發(fā)揮最佳作用。

由于Meteor Lake是一個混合平臺（具有性能核與能效核），我們引入了API更改，僅允許在性能或能效核上進行調(diào)度。如果您需要嚴格控制平臺資源，這是一種方法。

在關于線程這個主題的最后，我們更新了ARM代碼以完全支持吞吐量模式。這意味著您可以在編譯模型時指定吞吐量性能提示，并通過Async API并行啟動多個推理。這些推理將并行運行，并將有效地分配給不同的CPU核。這一變化對于面向吞吐量的任務尤其有益，在這些任務中，您可以同時生成許多推理，并擁有相應的資源，即多核ARM處理器。

最后，我們在AUTO邏輯中引入了用于累積吞吐量提示的循環(huán)調(diào)度，該邏輯允許在同一目標的多個實例之間進行負載共享。假設您在系統(tǒng)中安裝了多個GPU——這種調(diào)度機制將確保系統(tǒng)上更均勻的負載分配和（有時）更高的吞吐量。

新的及改進的notebooks示例

我們繼續(xù)展示人工智能領域最重要的更新，以及如何利用OpenVINO?來加速這些場景。以下是我們做的一些最新的notebooks：

https://github.com/openvinotoolkit/openvino_notebooks/blob/main/README.md

感謝你，開發(fā)者們！

自上一次發(fā)布以來，我們看到了來自開發(fā)者們對OpenVINO?做出貢獻、并使該產(chǎn)品變得更好的濃厚興趣。這里不僅包括對運行時和模型轉換支持的貢獻，還包括對新模型的支持，例如，對我們LLM聊天機器人notebook中日語微調(diào)的Youri模型的支持。

我們感謝每一個貢獻，并感謝大家！以下是我們能夠追蹤到的貢獻者名單：rghvsh, YaritaiKoto, siddhant-0707, sydarb, kk271kg, ahmadchalhoub, ma7555, Bhaskar365.

通知和免責聲明

英特爾技術可能需要能支持的硬件、軟件或服務激活。

任何產(chǎn)品或組件都不可能絕對安全。

您的成本和結果可能會有所不同。

? 英特爾公司。英特爾、英特爾商標和其他英特爾標志是英特爾公司或其子公司的商標。其他名稱和品牌可能是其他公司的財產(chǎn)。