作者：OpenVINO團隊
隨著我們迎來嶄新的一年，是時候在生成式人工智慧(AI)領域大放異彩地開啟2024年了。我們在這裡發佈最新、最偉大的推論工具，這將使您在新的一年中的程式編寫之旅變得異常精彩。OpenVINO 的最新版本導入了額外的框架改變，最佳化了生成式AI模型的特性，並強化了對現有平台的支援，以下讓我們來了解一些重要的更新。
大語言模型推論的提升
大語言模型(LLM)繼續成為頭條新聞，幾乎每週都有產業領導者和尖端技術進展的訊息更新；而目前還沒有改變的，是以高效率執行這些模型所需的運算量和其他資源的數量。我們繼續致力於實現越來越多的最佳化，以實現對這些模型的推論，包括在資源非常有限的環境中進行推論。2023.3長期支持版本(LTS)帶來了最佳化LLM推論的重要改變。
KV Cache方法的最佳化
LLM是以Transformer為基礎的模型，其中一種最佳化技術專門用於生成任務，即所謂的KV緩衝記憶體(KV Cache)。這種方法是利用以先前的詞元(token)為基礎生成的模型與新詞元，造成大量冗餘運算(redundant computations)。
為了避免這種運算，模型內部的嵌入(embeddings)被緩衝儲存起來，並在下一個週期中被重複使用。實際上，這意味著當使用這樣的模型時，您需要從模型的某些輸出中獲得嵌入，儲存這些資料，並在按順序生成下一個詞元時將其傳遞給模型輸入。
這種通常被稱為KV Cache的方法是一種眾所周知的技術(參考此連結)，雖然它有效地加速了模型推論，但是並不理想，因為緩衝記憶體需要多個記憶體副本，很容易增加超過幾GB，並隨著上下文的增加而降低性能；這一切都是為了提供那些無法被解譯也也永遠不會直接使用的資料。。
在2023.3版本中，OpenVINO 導入了對模型轉換、最佳化工具和Runtime的修改，以所謂的狀態模型格式(stateful format)轉換模型，其中KV Cache保持在模型本身的狀態，並由Runtime透明地處理；不再需要取得、儲存和傳遞至KV Cache，Runtime會透過分配記憶體、選擇高效佈局(layout)等方式自動進行處理。
這種方法讓我們能夠顯著最佳化資源使用並提高性能，使用模型變得越來越容易，因為輸入和輸出的數量顯著減少，並且不再需要明確地儲存任何內容。在預設情況下，當從Hugging Face匯出模型時，它們會以新的狀態模型格式出現。
如果您正在使用Hugging Face API，並利用我們的Optimum-Intel軟體套件執行OpenVINO，此一改變對您來說是透明的，無需修改程式碼。如果您直接執行模型推論，則需要對程式碼進行微小的修改才能開始使用此功能，主要是從程式碼中刪除與KV Chache相關的所有內容。
對於會讓緩衝記憶體變大的大型提示(prompt)，這次的改變特別顯著，因此如果您正在實現某種RAG使用情境，這可能是一個非常值得嘗試的有趣功能。該方法同時適用於Greedy和Beam搜尋機制。
額外的低精度Runtime最佳化
我們在前一個版本的OpenVINO中導入了LLM的int8和int4權重壓縮，包括對神經網路壓縮框架(NNCF)模型最佳化框架的支援；其實還有一些性能可以進一步最佳化，在這個新版本中我們也實現了。
首先，現在所有CPU都以高性能的方式完全支援int4和int8權重壓縮方案，包括Xeon平台；以往OpenVINO Runtime缺乏這種支援。當然，它在PC與邊緣CPU也提供支援(例如最近發表的Core Ultra，也就是Meteor Lake)。
其次，除了對個別運作提供許多最佳化，我們還對CPU和GPU的首次詞元生成延遲進行了實質性的最佳化，這提高了整體生成時間方面的性能。對於短小的提示詞，這些差異並不是那麼關鍵，但對於大型文字(聊天機器人或RAG驅動的應用程式)，這在性能方面是一個非常好的加強。
此外，在壓縮模型時，雖然性能至關重要，但您仍然希望確保模型執行的準確度。為了促進這一點，我們導入了一種資料感知(data-aware)權重壓縮演算法，該演算法使用資料集輸入來選擇個別Transformer層權重的精度，允許更精確的模型權重壓縮(您可以在此處找到更多資訊)。
對利用OpenVINO原生API執行生成式模型的更妥善、更高效率支援
我們透過Optimum-Intel與Hugging Face的整合，是能幫助您快速執行推論任務的好方法──只需要修改兩行程式碼。然而，在某些情況下，OpenVINO 原生 API可以為您提供更好的服務。
舉例來說，C++應用程式需要可控的安裝、最小的佔用空間等等。在這種情況下，我們建議為OpenVINO 原生API編寫應用程式，這樣就可以由只佔用最小儲存與記憶體空間的OpenVINO發行版本中獲益。在新版本中，我們導入了一些改變，旨在幫助快速輕鬆地編寫OpenVINO支援的推論應用程式。
首先，我們在OpenVINO中添加了對字串張量(string tensor)和分詞(tokenization)的支援。這意味著您可以在處理模型輸入和輸出時使用字串類型(只要模型支援)。這種模型的一個例子是分詞器(tokenizer)本身——您現在可以將Hugging Face分詞器轉換為OpenVINO模型，並推論該模型來執行分詞/去分詞步驟，只需傳遞字串並取得經過分詞的表示。對分詞的支援是透過額外的OpenVINO套件實現的，您需要透過pip或conda單獨安裝。
最重要的是，我們正在導入一個新的範例儲存庫(Repository)，專門用於生成式AI模型；在這裡您可以找到展示如何使用Stable Diffusion進行影像生成，或使用LLaMa2模型進行文字生成等等範例。
使用OpenVINO API的完整文字生成範例非常簡單，只需要70行程式碼，除了OpenVINO Runtime和分詞器之外，不需要任何元件——我們希望它能極大地簡化學習路徑。如果您覺得我們少了什麼，也可以隨時提供你的程式碼範例！
為新平台所作的變化與針對現有平台的強化
在2023年底，我們發表了重要的平台，包括第五代Xeon (代號Emerald Rapids)和全新的Meteor Lake平台；此次發表的新版本OpenVINO導入了一些改變，使我們能夠更有效地支援這些平台。
我們強化了執行緒(threading)機制，以便對任務執行高效的核心分配，並與oneTBB (Intel oneAPI Threading Building Blocks)團隊合作，確保順暢的支援。這一切都是透明的，OpenVINO持續在最新平台上發揮最佳作用。
由於Meteor Lake是一個混合平台──具有效能核心(Performance Core，P-Core)與效率核心(Efficient Core，E-Core)──我們導入了API的改變，僅允許在P-Core或E-Core上進行調度。如果您需要嚴格控制平台資源，這是一種方法。
在關於執行緒這個主題的最後，我們更新了Arm程式碼以完全支援輸送量模式(throughput mode)。這意味著您可以在編譯模型時指定輸送量性能提示，並透過Async API平行啟動多個推論；這些推論將平行運作，並有效地分配給不同的CPU核心。此變化對於輸送量導向的任務尤其有益，在這類任務中，您可以同時生成許多推論，並擁有相對應的資源，即眾核心( many-core) Arm處理器。
最後，我們在AUTO邏輯中導入了用於累積輸送量提示的輪詢調度(round-robin scheduling)，該邏輯允許在同一目標的多個實例之間進行負載共用(load-share)。假設您在系統中安裝了多個GPU——這種調度機制將確保系統上更均衡的負載分配和(有時)更高的輸送量。
全新與改版過的Notebooks範例
我們繼續展示AI領域最重要的進展，以及如何利用OpenVINO來支援並加速實現這些場景。點擊以下連結可參考我們的最新Notebooks：
https://github.com/openvinotoolkit/openvino_notebooks/blob/main/README.md
感謝開發者夥伴們！
自發表上一個版本，我們看到開發者們對OpenVINO做出貢獻、讓該產品變得更好的濃厚興趣。這裡不僅包括對Runtime和模型轉換支援的貢獻，還包括對新模型的支援，像是我們的LLM聊天機器人Notebook中對日語微調Youri模型的支援。
我們感謝大家所做的每一筆貢獻，以下是我們能夠追蹤到的貢獻者名單：rghvsh、YaritaiKoto、 siddhant-0707、sydarb、kk271kg、ahmadchalhoub、ma7555、Bhaskar365，謝謝這些開發夥伴！
(參考原文：Introducing OpenVINO 2023.3 LTS；責編：Judith Cheng)
- 用OpenVINO C# API部署YOLOv9目標檢測和實例分割模型 - 2024/04/19
- OpenVINO 2024.0：為開發者提供更高性能、更強大支援 - 2024/03/19
- 用OpenVINO與NNCF最佳化Whisper語音辨識模型 - 2024/03/13
