我正在Arch Linux上使用英特尔Arc A770进行试验，将会分享我的经验，也希望能得到一些反馈。我使用ipex - llm docker镜像最顺利，它包含ollama、llama.cpp、vLLM等很多内容。Ollama似乎有点糟糕，sycl支持在0.4版本被合并但又丢失了，还有一个0.3版本的Vulkan过时的PR，并且被Ollama维护者忽视。ipex - llm的人员说他们正在将sycl支持基于0.4版本重新构建，但结果如何还得看时间。在llama3.1:8b上，sycl目标速度快很多，达到55t/s，而Vulkan只有12.09t/s，但我遇到一些奇怪的问题，如LLMs完全失控，或者当收到一些vscode自动补全请求时ollama就会堵塞。我在Arch系统上本地安装的llama.cpp基于Vulkan，性能和ollama基于Vulkan时差不多。据我所知，ollama使用llama.cpp作为工作进程，所以这是预期之中的。LM Studio在英特尔Arc上使用基于Vulkan的llama.cpp，所以性能又明显比sycl慢。在我的测试中，vLLM实际上比ollama快很多。在qwen2.5:7b - instruct - fp16上，它能达到36.4 tokens/s，而ollama是21.12t/s。它在自动补全方面也比Ollama可靠得多。不幸的是，它只能运行一个模型，并且即使空闲时内存使用率也非常高。这使得它甚至无法加载14b模型，在我看来不适合在桌面后台运行。一个3B模型它就要使用8GB内存，我记得它使用的VRAM更多。我简单看了一下Fastchat，但仍然需要为每个模型运行工作进程。简而言之，Vulkan很慢，vLLM是资源消耗大户，ollama有漏洞且过时。我目前在open webui、Home Assistant和VS Code Continue中使用ollama。对于聊天和Home Assistant，我选定qwen2.5:14b作为最适用的模型。在VS Code中我还在试验，聊天似乎没问题，但自动补全几乎完全无法工作，因为ollama只会给出无意义的内容或者卡住。如果有人有经验或者建议，我很乐意听取。
讨论总结
原帖作者分享在Arch Linux上使用Intel Arc A770的体验，对ollama、llama.cpp、vLLM等推理引擎进行比较，指出各引擎存在的问题。评论者们围绕这些内容展开讨论，包括vLLM在英特尔GPU上的量化支持和显存占用、在特定平台上工作的困难、不同配置下的性能比较、对原帖作者的赞赏、给出相关建议等，总体氛围是积极的技术交流与问题研讨。
主要观点
- 👍 vLLM对英特尔GPU量化支持差且显存占用高
- 支持理由：官方版本量化支持不好，会抢先占用所有可用显存，英特尔分支虽支持多种量化类型但官方版存在问题。
- 反对声音：无
- 🔥 在Intel Arc相关平台上让相关项目工作困难
- 正方观点：如llama.cpp中的提交后sycl被破坏，只能使用特定版本直到重新调整等情况。
- 反方观点：无
- 💡 在Intel 140V上，使用ipex - llm后端的llama.cpp性能最佳
- 解释：评论者分享自身经验，同时提到Ollama不是有竞争力的选择，且该方式下的llama - server存在浏览器显示黑页问题。
- 💡 vLLM在特定测试中比ollama速度快很多，但对其内存带宽利用率表示怀疑
- 解释：在qwen2.5:7b - instruct - fp16下速度对比明显，但通过计算其内存带宽利用率达91%，怀疑结果真实性。
- 💡 原帖作者应从源码构建启用sycl后端的llama.cpp
- 解释：评论者认为这样效果很棒但对量化类型挑剔，有构建失败的用户询问版本信息，也有后续补充不同版本构建在内存使用和速度方面情况的讨论。
金句与有趣评论
- “😂 It’s a cunt of a time trying to get things working on this platform isn’t it?”
- 亮点：生动形象地表达出在该平台上让项目工作的艰难程度。
- “🤔 The best performance I get on Intel 140V is from llama.cpp with ipex - llm backend.”
- 亮点：明确指出在特定设备上性能最佳的组合。
- “👀 vLLM is actually significantly faster than ollama in my testing. On qwen2.5:7b - instruct - fp16 it could do 36.4 tokens/s vs ollama’s 21.12 t/s”
- 亮点：给出了具体的性能对比数据。
- “😎 dude, since you’re on arch, you should build llama.cpp from sauce with the sycl backend enabled; it works great imo but it’s a bit picky with what types of quants it takes”
- 亮点：针对原帖作者的系统给出具体建议。
- “💡 Don’t forget about MLC.”
- 亮点：补充了原帖遗漏的一个推理引擎选项。
情感分析
总体情感倾向是积极的技术交流。主要分歧点较少，更多是分享各自的经验和遇到的问题。可能的原因是这是一个技术话题，大家更关注于解决问题和分享信息。
趋势与预测
- 新兴话题：可能会有更多关于llama.cpp不同版本构建的深入探讨以及如何优化其在Intel Arc上的性能。
- 潜在影响：对在Intel Arc上开发和优化推理引擎有一定的参考价值，有助于提升相关应用的性能和用户体验。
详细内容：
标题：关于 Intel Arc 最佳推理引擎的热门讨论
在 Reddit 上，一篇关于“Best inference engine for Intel Arc”的帖子引起了众多关注。该帖子详细介绍了在 Arch Linux 上对 Intel Arc A770 进行实验的经历，获得了大量的点赞和众多评论。
帖子中提到，在尝试的各种引擎中，ollama 存在一些问题，如状态不佳、sycl 支持的合并与丢失，以及 Vulkan 相关的过时 PR 被忽视。vLLM 虽然速度快，但资源消耗大，内存占用高，无法加载 14b 模型。 llama.cpp 在 Vulkan 上的性能与 ollama 相近。
讨论的焦点观点众多。有人指出 vllm 的量化支持在 Intel GPU 上较差，尽管硬件支持如 fp8。也有人分享自己在 Intel 140V 上使用 llama.cpp 与 ipex-llm 后端获得了最佳性能。还有用户认为 A770 的 Ollama 表现特别不理想。有人提到 MLC，称如果不需要 llama.cpp 的某些高级功能，MLC 是不错的选择。
有用户分享道：“我尝试编译/运行 llamacpp 直到 11 月 13 日的这个提交，之后就出现了问题。”还有用户表示：“我使用 Arc 来生成训练数据 24/7 都没问题，你这应该是设置的问题。”
讨论中的共识在于大家都在努力寻找适合 Intel Arc 的最佳推理引擎，但目前还没有一个完美的解决方案。特别有见地的观点如有人认为 Ollama 在某些方面表现不佳，Intel 应该更加努力优化，不然随着新产品线的推出，可能会错失机会。
总的来说，关于 Intel Arc 最佳推理引擎的探索仍在继续，大家都期待能有更出色且稳定的解决方案出现。
感谢您的耐心阅读！来选个表情，或者留个评论吧！