原贴链接

你好！今天我要发布OpenArc（https://github.com/SearchSavior/OpenArc），这是一个使用Optimum - Intel从Transformers构建的轻量级推理引擎，用于在Intel设备上利用硬件加速。以下是一些特性：具有四个端点的强类型API（/model/load：加载模型并接受ov_config；/model/unload：使用垃圾回收从设备内存清除已加载模型；/generate/text：同步执行，选择采样参数、令牌限制，还返回性能报告；/status：查看已加载模型），每个端点都有一个pydantic模型，使暴露的参数易于维护或扩展，原生聊天模板，为可移植性提供Conda environment.yaml，很快会有合适的.toml。受众为Intel加速器的所有者、只能使用高端或低端CPU服务器的人员、带有Intel芯片的边缘设备。OpenArc是我的第一个开源项目，代表了我数月来在OpenVINO和Intel设备上进行AI/ML工作的成果。使用OpenVINO/Transformers/IPEX - LLM的开发者和工程师会发现它的语法、工具和文档很完整；新用户会发现它比Intel提供的文档更易上手，包括非常棒的openvino_notebooks。我的OpenArc理念是让项目尽可能底层，以方便接触OpenArc的核心——对话对象。这是聊天历史通常存在的地方；实际上这为上下文管理提供了各种不同策略，对代理用例更有意义，不过OpenArc足够底层，可以支持很多不同用例。例如，用于搜索任务的模型可能不需要大于4k令牌的上下文窗口；这样，你可以将小代理结果中的事实存储在其他地方，编目结果，从对话中清除对话内容，一个处理来自管理模型新指令的无偏差小代理在低上下文情况下可以表现良好。如果我们从宏观角度思考构建迭代搜索、数据库访问、读取数据帧、进行NLP或生成合成数据所需的代码——至少对我来说——推理代码在这样的流程中没有位置。OpenArc推广用于本地与大型语言模型（LLM）接口的API调用设计模式，这是OpenVINO到目前为止所缺乏的。其他服务平台/项目将OpenVINO作为插件或扩展，但没有一个专注于它的细节，很少有关于需要OpenVINO深度优化的解决方案设计的高质量文档。即将推出：Openai代理、更多OV_config文档（它相当复杂）、docker compose示例、多GPU执行（由于驱动问题我还没能实现，但目前OpenArc完全支持，我在git上链接的带有“-ns”后缀的hf仓库中的模型应该可以工作，这是个难题，在我能编写文档之前需要更多测试）、基准测试和基准测试脚本、将多个模型加载到内存和不同设备、用于管理OpenArc的Panel仪表盘、Autogen和smolagents示例。感谢查看我的项目！

讨论总结

原帖作者发布OpenArc项目，这是一个用于在英特尔CPU、GPU和NPU上进行更快推理的Python服务API。评论者们大多对这个项目表示认可，其中一些人以幽默的方式表达肯定。还有部分人对项目的某些方面表示期待，如Docker compose示例；也有人关注项目的性能比较、在不同系统上的可用性等，整体讨论氛围积极向上。

主要观点

  1. 👍 对OpenArc项目表示认可
    • 支持理由：项目具有多种特性，对英特尔设备的推理有积极意义，是作者努力工作的成果。
    • 反对声音：无。
  2. 🔥 期待项目的特定成果（如Docker compose示例）
    • 正方观点：有助于在低成本Intel VPS上进行测试。
    • 反方观点：无。
  3. 💡 若消除GPU依赖会让本地运行LLMs更容易
    • 解释：当前在本地运行LLMs时GPU依赖可能是痛点，项目若解决此问题将带来很大便利。
  4. 💪 反对供应商锁定，倡导模型能在多种硬件上运行
    • 解释：不应局限于特定供应商的硬件，应实现硬件通用性。
  5. 🤔 对OpenArc项目在不同方面存在疑问（如性能、系统适用性等）
    • 解释：想要更深入了解项目的性能、与其他项目的比较、在不同系统或平台上是否可用等情况。

金句与有趣评论

  1. “😂 AnhedoniaJack: Not without this 🚀 you’re not!”
    • 亮点：以幽默诙谐且夸张的方式表达项目的不可或缺性。
  2. “🤔 Nice! Eagerly awaiting Docker compose examples; to test on low cost Intel VPS [AWS, etc].”
    • 亮点：表达对项目特定成果的期待。
  3. “👀 Ragecommie：Great work! A lot of overlapping points with one of my projects too, as we’re also targeting Intel platforms.”
    • 亮点：指出项目与自己项目的重叠之处，肯定原项目很棒。
  4. “😎 Xenothinker：This is interesting. If GPU dependency can be obviated, it will make running local LLMs much easier.”
    • 亮点：提出项目若能避免GPU依赖将对本地运行LLMs产生积极影响。
  5. “👍 MKU64: Damn this is a great starting point for Intel inference. Fantastic work man!”
    • 亮点：简洁有力地肯定项目是英特尔推理的良好开端。

情感分析

总体情感倾向为积极正面。主要分歧点较少，几乎所有评论者都对项目表示认可或期待。可能的原因是项目本身具有一定的创新性和实用性，且针对英特尔设备进行优化，在相关领域有一定的积极意义，吸引了对英特尔设备、推理项目感兴趣的用户的关注。

趋势与预测

  • 新兴话题：可能会有更多关于OpenArc项目在不同硬件设备上的性能测试和优化的讨论，以及与其他类似项目更深入的性能比较。
  • 潜在影响：如果项目发展顺利，可能会推动英特尔设备在AI/ML推理方面的应用，为相关开发者提供更多的选择，也可能影响其他类似项目朝着更优化硬件利用的方向发展。

详细内容：

标题：OpenArc——Python 服务 API 助力英特尔硬件加速推理引发热议

今日，一个名为 OpenArc 的项目在 Reddit 上引起了广泛关注。它是一个用于在英特尔 CPU、GPU 和 NPU 上实现更快推理的 Python 服务 API。该帖子获得了众多点赞和评论，引发了热烈的讨论。

原帖主要介绍了 OpenArc 的一系列特点，包括强类型 API 及四个端点、原生聊天模板、可移植的 Conda 环境等。还提到了目标受众以及未来即将推出的新功能，如 OpenAI 代理、更多文档等。

讨论焦点主要集中在以下几个方面： 有人称赞这是很棒的工作，是英特尔推理的绝佳起点。例如有人说道：“这真的太好了。供应商锁定不是一件好事，我们应该能够在任何硬件上运行模型，苹果、英特尔、英伟达、AMD 等等。” 有人对其在不同系统和硬件上的运行表现及兼容性提出疑问。比如有人询问：“它在 Windows 和 Linux 上都能工作吗？与 llama.cpp SYCL/Vulkan 在功能和性能上相比如何？”还有人想知道它是否能在 Windows ARM 上运行。 也有人关心它与其他类似项目的比较以及对原始模型的改进情况等。

有用户分享道：“作为一名在相关领域探索的开发者，我深知找到一个适合多种英特尔设备的推理工具的重要性。OpenArc 的出现让我看到了新的希望，但我也期待看到更多关于性能提升和兼容性优化的实际测试结果。” 有人提供了相关的模型链接：“你可以在我的 HF 上找到一些模型[https://huggingface.co/fakezeta] 。如果您需要尚未转换的特定内容，您可以使用这个很棒的 Space [https://huggingface.co/spaces/OpenVINO/export]”

讨论中的共识是认为 OpenArc 具有很大的潜力和价值，但也存在一些需要进一步完善和解决的问题。

特别有见地的观点如：“OpenArc 是一个非常底层的框架，只有熟悉如何控制对话对象才能构建格式化请求的代码。更多关于设置的文档即将推出。”

总的来说，OpenArc 引发了大家对英特尔硬件加速推理的关注和讨论，未来其发展值得期待。