在本版本中，我们一直致力于提高 LLM 的开箱即用性能，并对运行时和工具进行了一些重要更改。

首先， 我们介绍了 CPU 平台的动态量化和缓存压缩机制。KV 缓存压缩功能使我们能够更高效地生成大序列。动态量化通常会提高模型其它部分（嵌入映射和前馈网络）的计算和内存消耗。

对于 GPU 平台，我们还通过在内核和整个堆栈中引入优化来改进生成特性。我们还实现了更高效的缓存处理，这有助于使用波束搜索生成。

其次， 虽然性能一直是一个讨论的话题，但准确性也至关重要。我们提高了 NNCF 中权重压缩算法的准确性。我们介绍了使用数据集的统计数据压缩权重的能力，并介绍了 AWQ 算法的实现，以进一步提高准确性。此外，通过我们与 Hugging Face Optimum Intel 的集成，您现在可以直接通过 Transformers API 压缩模型，如下所示：

想了解关于我们的算法质量的更多信息，您可以查询OpenVINO™ 文档： https://docs.openvino.ai/nightly/weight_compression.html

或者 GitHub上的NNCF 文档： https://github.com/openvinotoolkit/nncf/blob/a917efd684c2febd05032a8f2a077595fb73481a/docs/compression_algorithms/CompressWeights.md#evaluation-results

混合专家（MoE）代表了下一个主要的体系架构演变，它为 LLM 带来了更好的准确性和性能。它从 Mixtral 开始，并迅速发展到更多的模型和框架，允许从现有模型创建基于 MoE 的模型。在整个2024.0版本中，我们一直致力于启用这些体系结构并提高性能。我们不仅对这些模型进行了有效的转换，而且还更改了一些内部结构，以更好地处理运行时内专家的动态选择。

我们正在对 Hugging Face Optimum-Intel 进行升级，以使这些模型的转换是透明的。

随着 Intel®Core™Ultra 的发布，我们的 NPU 加速器终于跟广大的开发者见面了。从软件和硬件的角度来看，这是一款不断发展的产品，我们对它所能实现的功能感到兴奋。您可能已经看到了一些在 NPU 上运行的 OpenVINO™ Notebooks 的演示

OpenVINO™ notebooks running on NPU:

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/230-yolov8-optimization

在本版本中，当您通过我们最热门的分发渠道 PyPI 安装 OpenVINO™ 时，我们将提供 NPU 支持。有几点需要注意：

NPU 要求在系统中安装驱动程序，因此如果您打算使用它，请确保遵循此简短指南：

https://docs.openvino.ai/nightly/openvino_docs_install_guides_configurations_for_intel_npu.html

NPU 目前不包括在自动设备选择逻辑中( https://docs.openvino.ai/nightly/openvino_docs_OV_UG_supported_plugins_AUTO.html )，因此，如果您计划在NPU上运行您的模型，请确保您明确指定设备名称（例如NPU），如下所示：

compiled_model = core.compile_model(model=model, device_name="NPU")

线程 是我们在 ARM 平台上还未有效实现的事情之一，这拖慢了我们的性能。我们与 oneTBB 团队（我们默认的线程引擎提供商）合作，改变了对 ARM 的支持，并显著提高了我们的性能。同时，在对某些操作的精度进行了一些研究后，我们在 ARM CPU 上默认启用了 fp16 作为推理精度。

总的来说，这意味着 ARM CPU 的性能更高，也意味着 OpenVINO Streams 功能的实现( https://docs.openvino.ai/nightly/openvino_docs_deployment_optimization_guide_tput_advanced.html#openvino-streams )，该功能允许在多核平台上获得更高的吞吐量。

2024.0 是我们的下一个主要版本，传统上这是我们从工具套件中删除过时组件的时候。

2年前，我们大幅度改变了 API 以跟上深度学习领域的发展。但为了最大限度地减少对使用OpenVINO™的现有开发者和产品的影响，我们也支持 API 1.0。从那以后发生了很多变化，我们现在 正在完全删除旧 的 API 。更重要的是，我们还删除了标记为弃用的工具。这包括：

训练后量化工具，也称为POT

准确性检查框架

部署管理器

这些工具是 openvino-dev 包的一部分，这个包已经有一段时间没有强制使用了。我们将为那些继续使用我们的离线模型转换工具model Optimizer的用户保留它。

如果您无法迁移到新的API，那么您很有可能继续使用我们的一个长期支持版本，例如2023.3。

Mobile language assistant with MobileVLM

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/279-mobilevlm-language-assistant

Depth estimation with DepthAnything

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/280-depth-anything

Multimodal Large Language Models (MLLM) Kosmos-2

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/281-kosmos2-multimodal-large-language-model

Zero-shot Image Classification with SigLIP

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/282-siglip-zero-shot-image-classification

Personalized image generation with PhotMaker

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/283-photo-maker

Voice tone cloning with OpenVoice

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/284-openvoice

Line-level text detection with Surya

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/285-surya-line-level-text-detection

Zero-shot Identity-Preserving Generation with InstantID

https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/286-instant-id

LLM chatbot 和 LLM RAG pipeline已通过新模型的集成进行了更新：minicpm-2b-dpo、gemma-7b-it、qwen1.5-7b-chat、baichuan2-7b-chat

https://github.com/openvinotoolkit/openvino_notebooks/blob/main/notebooks/254-llm-chatbot/254-llm-chatbot.ipynb

https://github.com/openvinotoolkit/openvino_notebooks/blob/main/notebooks/254-llm-chatbot/254-rag-chatbot.ipynb

在 OpenVINO™ 的历史上，我们看到了许多激动人心的项目！我们决定列出一份使用OpenVINO™ 的绝妙项目列表

( https://github.com/openvinotoolkit/awesome-openvino )，它还在继续快速增长着！为您的项目创建一个拉取请求，使用您项目的 “mentioned in Awesome” 徽章，并与我们分享您的经验！

我们的开发人员基数正在增长，我们感谢社区正在做出的所有改变和改进。令人惊讶的是，你们中的一些人已经明确表示 “正忙于帮助改进 OpenVINO™” ，谢谢！😊

我们的贡献者所做工作的一个例子是 openSUSE 平台中的 OpenVINO™ 支持。

https://en.opensuse.org/SDB:Install_OpenVINO

此外， 我们正在为 谷歌代码之夏（Google Summer of Code） ( https://github.com/openvinotoolkit/openvino/discussions/categories/google-summer-of-code )做准备，并从您那里获得非常有趣的项目提案！在我们把你的想法发送出去审批之前，还有时间提交您的想法。

在这个版本中，我们挚爱的贡献者列表发布在 GitHub 上:

https://github.com/openvinotoolkit/openvino/releases/tag/2024.0.0

通知和免责声明

性 能因使用情况、配置和其他因素而异。如需了解详情，请访问性能检索网站:

https://edc.intel.com/content/www/us/en/products/performance/benchmarks/overview/

性能结果基于截止配置中显示日期的测试，可能无法反映所有公开可用的更新。 有关配置详细信息，请参阅备份。 没有任何产品或组件是绝对安全的。

您的成本和结果可能会有所不同。 英特尔技术可能需要支持的硬件、软件或服务激活。

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

文档整体看了，也深入细节看了，从规格上来看算是一个非常优秀的语言融合实践案例，但设计者仍稍显矫揉造作之嫌，搞了一些“创新”之举，比如func/foreign/->/prop/mut/Rune/<:/...，除赋值操作符外，任何复合操作符都是不可接受的，宜尽量避免；在某些方面显得一致性不严谨，比如函数作为参数和返回类型时就与标准定义不一致，比如匿名函数（Lambda）定义也不一致，增加了代码阅读理解难度；C语言取址符号(&)作为接口继承用间隔符是个坏主意，因为这个符号在键盘上输入不方便，需要双键才能输入；Nothing/Option/Any 貌似取自TypeScript，其终归是某种类似于 Null 的检测机制，要不合成一个？类型在后并用冒号(:)分隔的语法风格上属于 Pascal/Go 风格，这种风格感觉是更方便实现词法分析器并生成语法树，利于后续的处理； 个人期望出现一门新语言，它应该以C语言风格为基础，大胆吸收新生代语言的优秀实践（语法糖），语言规格尽可能的保持精简和一致性，但语义和扩展性保持开放；仓颉语言为新语言开发做了非常伟大的探索和实践，实现后的预期也非常好，开了个好头；有了榜样的力量，相信中文社区有更大可能性诞生这样一门语言；