作者：英特尔院士 OpenVINO™ 产品架构师  Yury Gorbachev；

翻译：英特尔 AI 软件布道师  武卓

随着我们迎来崭新的一年，是时候在生成式人工智能领域大放异彩地开启2024年了。我们在这里发布最新、最伟大的推理工具，这将使您在新的一年中的编码之旅变得异常精彩。OpenVINO™ 的最新版本引入了额外的框架更改，优化了生成式AI模型的特性，并增强了对现有平台的支持。让我们来了解一下一些重要的更新。

大语言模型推理的提升

LLM继续成为头条新闻，几乎每周都会更换头部领导者和最先进的技术。目前还没有改变的是高效运行这些模型所需的计算量和其他资源的数量。我们继续致力于实现越来越多的优化，以实现对这些模型的推理，包括在资源非常有限的环境中进行推理。2023.3长期支持版本带来了优化LLM推理的重要更改。

优化KV-缓存处理

LLM是基于Transformer的模型，也是其中一种优化技术，专门用于生成任务，即所谓的KV缓存。这种方法利用了这样一个事实，即模型基于以前的令牌生成每个新令牌，并执行大量冗余计算。为了避免这种计算，内部模型嵌入被缓存起来并在下一个周期中被重用。实际上，这意味着当使用这样的模型时，您需要从模型的某些输出中获得嵌入，存储这些数据，并在按顺序生成下一个令牌时将其传递给模型输入。这种方法通常被称为KV缓存，是一种众所周知的技术（例如： https://medium.com/@joaolages/kv-caching-explained-276520203249 ）。虽然它有效地加速了模型推理，但它并不理想，因为缓存需要多个内存副本，很容易增长超过几GB，并随着上下文的增长而降低性能。这一切都是为了服务数据，您无法解释，也永远不会直接使用这些数据。

在本版本中，OpenVINO™ 引入了对模型转换、优化工具和运行时的修改，以所谓的状态模型格式转换模型，其中KV Cache保持在模型本身的状态，并由运行时透明地处理。不再需要获取、存储和传递KV缓存，运行时会自动处理。分配内存、选择高效布局等。这种方法使我们能够显著优化资源使用并提高性能。使用模型变得越来越容易，因为输入和输出的数量显著减少，并且不再需要显式存储任何内容。默认情况下，当从Hugging Face导出模型时，它们将以新的状态模型格式出现。

如果您正在使用Hugging Face API并使用我们的Optimum-Intel软件包运行OpenVINO™，则此更改对您来说是透明的，无需修改代码。如果您直接执行模型推理，则需要对代码进行微小的更改才能开始使用此功能。主要是从代码中删除与KV缓存相关的所有内容。

对于缓存变大的大型文本提示，这次的改进尤其明显，因此如果您正在实现某种RAG场景，这可能是一个非常有趣的功能。该方法同时适用于Greedy和Beam搜索机制。

额外的低精度运行时优化

我们在上一版本中介绍了LLM的int8和int4权重压缩，包括在模型优化框架（NNCF）中的支持。还有一些性能可以进一步优化，我们正在这个版本中修复它。

首先，现在所有CPU都以高性能的方式完全支持int4和int8权重压缩方案。这包括Xeon平台，以前通过OpenVINO™运行时缺乏这种支持。当然，它在客户端/边缘CPU上也是支持的（比如我们最近发布的Meteor Lake）。

其次，除了对单个操作进行许多优化外，我们还对CPU和GPU的首次令牌生成延迟进行了实质性优化，这提高了总体生成时间方面的性能。对于短小的提示词，这些差异并不是那么关键，但对于大型上下文（聊天机器人、RAG驱动的应用程序），这在性能方面是一个非常好的补充。

此外，在压缩模型时，虽然性能至关重要，但您仍然希望确保模型执行的准确度。为了促进这一点，我们引入了一种数据感知权重压缩算法，该算法使用数据集输入来选择单个transformer层权重的精度。它允许更精确的模型权重压缩。您可以在此处找到更多信息：https://docs.openvino.ai/nightly/weight_compression.html

更好更高效地使用OpenVINO™原生API运行生成式模型

我们通过Optimum Intel与Hugging Face的集成非常棒，可以帮助您快速运行推理，只需要修改两行代码。然而，在某些情况下，OpenVINO™ 原生 API可以为您提供更好的服务。C++应用程序需要可控的安装、最小的占用等等。在这种情况下，我们建议为OpenVINO™ 原生API编写应用程序，并从我们拥有的最小分发版本中获益。在本版本中，我们介绍了一些更改，旨在帮助快速轻松地编写OpenVINO™支持的推理应用程序。

首先，我们在OpenVINO™中添加了对字符串张量和标记化的支持。这意味着您可以在处理模型输入和输出时使用字符串类型（如果模型支持的话）。这种模型的一个例子是分词器本身——您现在可以将Hugging Face分词器转换为OpenVINO™模型，并推理该模型来执行分词化/去分词化步骤。只需传递字符串并获得分词化表示。分词化支持是作为一个额外的OpenVINO™包实现的，例如，您需要通过pip或conda单独安装它。

最重要的是，我们正在引入一个新的范例仓库，专门用于生成式AI模型。在这里，您可以找到展示如何使用Stable Diffusion进行图像生成或使用LLaMa2模型进行文本生成等的示例。使用OpenVINO ™ API的完整文本生成示例非常简单，只需70行代码，除了OpenVINO™运行时和分词器之外，不需要任何组件——我们希望它能极大地简化学习路径。如果您觉得我们缺少什么，也可以随时提供您代码示例！

新平台的支持和现有平台上的提升

2023年以我们重要的平台发布，即第五代Xeon（代号Emerald Rapids）和全新的Meteor Lake平台的发布而结束。此次发布的OpenVINO™引入了一些更改，使我们能够更有效地支持这些平台。我们增强了线程机制，以便对任务执行高效的核分配，并与oneTBB团队合作，确保顺利支持。这一切都是透明的，OpenVINO™只是继续在新平台上发挥最佳作用。

由于Meteor Lake是一个混合平台（具有性能核与能效核），我们引入了API更改，仅允许在性能或能效核上进行调度。如果您需要严格控制平台资源，这是一种方法。

在关于线程这个主题的最后，我们更新了ARM代码以完全支持吞吐量模式。这意味着您可以在编译模型时指定吞吐量性能提示，并通过Async API并行启动多个推理。这些推理将并行运行，并将有效地分配给不同的CPU核。这一变化对于面向吞吐量的任务尤其有益，在这些任务中，您可以同时生成许多推理，并拥有相应的资源，即多核ARM处理器。

最后，我们在AUTO逻辑中引入了用于累积吞吐量提示的循环调度，该逻辑允许在同一目标的多个实例之间进行负载共享。假设您在系统中安装了多个GPU——这种调度机制将确保系统上更均匀的负载分配和（有时）更高的吞吐量。

新的及改进的notebooks示例

我们继续展示人工智能领域最重要的更新，以及如何利用OpenVINO™来加速这些场景。以下是我们做的一些最新的notebooks：

https://github.com/openvinotoolkit/openvino_notebook***lob/main/README.md 

感谢你，开发者们！

自上一次发布以来，我们看到了来自开发者们对OpenVINO™做出贡献、并使该产品变得更好的浓厚兴趣。这里不仅包括对运行时和模型转换支持的贡献，还包括对新模型的支持，例如，对我们LLM聊天机器人notebook中日语微调的Youri模型的支持。

我们感谢每一个贡献，并感谢大家！以下是我们能够追踪到的贡献者名单：rghvsh, YaritaiKoto, siddhant-0707, sydarb, kk271kg, ahmadchalhoub, ma7555, Bhaskar365.

通知和免责声明

英特尔技术可能需要能支持的硬件、软件或服务激活。

任何产品或组件都不可能绝对安全。

您的成本和结果可能会有所不同。

© 英特尔公司。英特尔、英特尔商标和其他英特尔标志是英特尔公司或其子公司的商标。其他名称和品牌可能是其他公司的财产。