OpenVINO™ 2024.2 发布--推出LLM专属API ！服务持续增强，提升AI生成新境界

作者 | 武卓 博士

排版 | 李擎

生成式 AI 正在被应用程序设计人员快速地使用着。这不仅体现在使用来自商业云服务模型的传统REST API形式上，而且还发生在客户端和边缘。越来越多的数据正在客户端处理，通过AIPC，我们为此开始看到更多的机会。其中一种场景是人工智能助手，它能够生成文本（邮件草稿、文档摘要、文档内容的答案等等）。这一切都由 LLM（大型语言模型）和不断增长的 SLM（小型语言模型）系列提供支持。

我们引入了新的软件包 openvino-genai，它使用OpenVINO™ 以及其中的openvino_tokenizers，因此如果您打算运行 LLM，安装此软件包就足够了。经典的 OpenVINO API 也支持其它类型的模型，因此现在流水线构建变得更加容易。我们的安装选项也进行了更新，以便反映并指导使用新软件包，因此请在那里查看您最合适的选项。经典的 OpenVINO™ 软件包仍然存在，如果您暂时不打算使用生成式 API，请继续使用 openvino 软件包。

安装选项更新：

https://docs.openvino.ai/2024/get-started/install-openvino.html

经典OpenVINO™软件包：

https://www.intel.cn/content/www/cn/zh/developer/tools/openvino-toolkit/download.html

为了通过 LLM 生成结果，应用程序需要执行整个操作流水线：执行输入文本的分词，处理输入上下文，迭代生成模型答案的后续输出分词，最后将答案从分词解码为纯文本。每个分词的生成都是推理调用，然后是后续逻辑来选择分词本身。逻辑可以是贪婪搜索的形式，也就是选择最可能的分词，也可以是波束搜索的形式，即保持很少的序列并选择其中最好的。

虽然OpenVINO™在推理方面大放异彩，但正如我们刚才所讨论的，这还不足以涵盖整个文本生成的流水线。在 2024.2 版本之前，我们提供了帮助程序（分词器和示例）来实现这一点，但应用程序必须使用这些组件实现整个生成逻辑。 现在这种情况正在发生改变。

在 24.2 版本中，我们引入了特定于 LLM 的 API，这些 API 隐藏了内部生成循环的复杂性，并显著减少了需要在应用程序中编写的代码量。通过使用特定于 LLM 的 API，您可以加载模型，向其传递上下文，并通过几行代码返回响应。在内部，OpenVINO™将对输入文本进行分词化，在您选择的设备上执行生成循环，并为您提供答案。让我们一步一步地看看这是如何使用Python和C++完成的。

如您所见，只需要几行代码就能建立一个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::genai::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);}

您也可以创建自定义流处理器进行更复杂的处理，这在我们的 [文档] 中进行了描述。

文档：

https://docs.openvino.ai/2024/learn-openvino/llm_inference_guide/genai-guide.html

最后， 我们还研究了聊天场景，其中输入和输出代表对话，并且有机会以在输入之间保留 KV缓存 的形式进行优化。为此，我们引入了聊天特定方法 start_chat 和 finish_chat，它们用于标记会话的开始和结束。下面是一个非常简单的 C++ 示例：

int main(int argc, char* argv[]) {    std::string prompt;
    std::string model_path = argv[1];    ov::genai::LLMPipeline pipe(model_path, "CPU");        pipe.start_chat();    for (;;) {        std::cout << "question:\n";        std::getline(std::cin, prompt);        if (prompt == "Stop!")            break;
        std::cout << "answer:\n";        auto answer = pipe(prompt);        std::cout << answer << std::endl;    }    pipe.finish_chat();}

在上面的所有示例中，我们都使用 CPU 作为目标设备，但 GPU 也同样是支持的。请记住，GPU 将为 LLM 本身运行推理，分词选择逻辑和分词化/去分词化将保留在 CPU 上，因为这更有效率。内置的分词器以单独的模型形式表示，并通过我们的推理功能在 CPU 上运行。

这个 API 使我们能够更灵活、更优化地实现生成逻辑，并不断扩展。请继续关注后续发布版本中的更多功能！

同时，请务必查看我们的 [文档] 和 [示例] 以获取新的 API，尝试后告诉我们你的想法。

文档：

https://docs.openvino.ai/2024/learn-openvino/llm_inference_guide/genai-guide.html

示例：

https://github.com/openvinotoolkit/openvino_notebooks/tree/latest/notebooks/llm-question-answering

通过服务化部署模型是一个非常成熟的方法论，并且随着基于微服务的部署不仅在传统的云环境中扩展，同时也在向边缘计算领域扩展，这一需求日益增长。更多的应用被开发为微服务，并部署在智能边缘和云中。在2024.2 版本中，我们引入了对服务场景的额外支持。让我们来看看最重要的变化。

为了以最适应应用程序的方式部署 LLM，我们在文本生成的使用场景实现了 OpenAI 兼容的API。我们的实现包括 连续批处理和分页注意力算法，因此文本生成可以在高并发负载下快速高效。这使得您可以允许在云中或本地（如果需要的话）创建自己的类似 OpenAI 的 LLM 服务端点。

尽管 LLM 备受瞩目，但传统的深度学习模型作为独立解决方案或大型流程的一部分仍有着高度需求。OVMS 可以长时间高效地部署这些模型，但对其它部署解决方案的需求非常高，因此我们为服务场景引入了一些额外的 OpenVINO™ 集成： 通过 TorchServe 和 Nvidia Triton 提供服务 。

OpenVINO™ 长期以来一直为 Triton Serving 提供后端，我们最近与 Nvidia 工程师合作，重新设计了它的附加功能，例如支持动态输入。您可以在我们的博客文章中查看有关如何在 Triton 中使用 OpenVINO™ 的更多详细信息。

博客文章：

https://medium.com/openvino-toolkit/how-to-serve-models-on-nvidia-triton-inference-server-with-openvino-backend-a4c36300ee21

服务功能的另一个重要补充是通过使用 torch.compile 的 OpenVINO™ 后端，使用 TorchServe 为模型提供服务。在引入 torch.compile 之后，TorchServe 引入了通过不同后端加速服务的功能。这正是OpenVINO™现在发生的事情，我们提供了在TorchServe中指定OpenVINO™作为后端的功能。有关更多详细信息，您可以查看示例，这些示例非常简单且不言自明。

torch.compile 的 OpenVINO™ 后端：

https://docs.openvino.ai/2024/openvino-workflow/torch-compile.html

示例：

https://github.com/pytorch/serve/tree/master/examples/pt2/torch_compile_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 集成中持续增加了对新模型的覆盖。