在我们迎来全新的一年之际，是时候以生成式人工智能领域的一次爆炸拉开 2024 年的序幕了。我们在这里发布最新、最伟大的推理，这将使您在新的一年中的编码之旅变得异常精彩。OpenVINO™ 的最新版本引入了额外的框架更改，以优化生成式 AI 模型的特性，并增强了现有平台的支持。让我们来了解一下我们所做的最重要的更新。
大语言模型推理的提升
大语言模型 (Large Language Model, LLM) 继续成为头条新闻，几乎每周都会更换最前沿的模型和领导者。目前还没有改变的是高效运行这些模型所需的计算和其他资源的数量。我们继续致力于实现越来越多的优化，以实现对这些模型的推理，包括在资源非常有限的环境中进行推理。2023.3 长期支持版本带来了优化LLM推理的重要更改。
优化 KV- 缓存处理
LLM 是基于 Transformer 的模型，其中一种优化技术，专门用于生成任务，即所谓的 KV 缓存。这种方法利用了这样一个事实，即模型基于以前的令牌生成每个新令牌，并执行大量冗余计算。为了避免这种计算，内部模型嵌入被缓存起来并在下一个周期中重用。实际上，这意味着当使用这样的模型时，您需要从模型的某些输出中获得嵌入，存储这些数据，并在按顺序生成下一个令牌时将其传递给模型输入。这种方法通常被称为 KV 缓存，是一种众所周知的技术。虽然它有效地加速了模型推理，但它并不理想，因为缓存需要多个内存副本，很容易增长超过几 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 的集成非常棒，可以帮助您快速运行推理，只需要修改 2 行代码。然而，在某些情况下，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™ 来加速这些场景。以下是我们一直在做的工作： https://github.com/openvinotoolkit/openvino_notebooks/blob/main/README.md
感谢你，开发者们！
自上一次发布以来，我们看到了来自开发者们对 OpenVINO™ 做出贡献、并使该产品变得更好的浓厚兴趣。这里不仅包括对运行时和模型转换支持的贡献，还包括对新模型的支持，例如，对我们LLM聊天机器人 notebook 中日语微调的 Youri 模型的支持。
我们感谢每一位贡献，并感谢大家：以下是我们能够追踪的贡献者名单：
rghvsh, YaritaiKoto, siddhant-0707, sydarb, kk271kg, ahmadchalhoub, ma7555，以及 Bhaskar365.
其它资源
OpenVINO™ 文档： http://docs.openvino.ai/
OpenVINO™ Notebooks： https://github.com/openvinotoolkit/openvino_notebooks
提供反馈及上报问题： https://github.com/openvinotoolkit/openvino/issues/new/choose