导读OpenVINO 在端侧大模型圈里的曝光远少于 llama.cpp。趁 MiniCPM5-2B 发布，我在同一台 i5-12600K 上分别测试了 CPU 和 Intel UHD 770。结果很有反差：CPU 上，调好线程的 llama.cpp 领先约 10%；换到集显，OpenVINO 的生成速度反而高约 52%。这不是谁全面碾压谁，而是两套 4-bit 部署栈在不同硬件路径上各有胜负。
OpenVINO 值不值得单独测一次？
MiniCPM5-2B 发布后，我平时更常接触到的本地运行方案，仍然是 llama.cpp、Ollama 这一套 GGUF 生态。OpenVINO 的名字大家并不陌生，但至少在我接触的端侧大模型讨论里，它出现得少一些。
这正是我想实测一次的原因。
英特尔与面壁智能已经给 MiniCPM5-2B 做了 OpenVINO Day0 适配，官方路径也很完整：模型转换、INT4 权重量化、OpenVINO GenAI 推理接口都已经接上。问题不再是“理论上能不能跑”，而是落到一台普通桌面平台后，它到底能跑多快，和我更常用的 llama.cpp 相比有没有实际优势。
最后得到的答案比一句“更快”或“更慢”更有意思：OpenVINO 没有在 CPU 上全面胜出，却在 Intel UHD 770 上拉开了明显差距。
这篇文章因此适合被当作一份单机复现报告，而不是一张后端排行榜。
模型与复现入口
MiniCPM5-2B 模型卡： https://huggingface.co/openbmb/MiniCPM5-2B
官方 GGUF 权重： https://huggingface.co/openbmb/MiniCPM5-2B-GGUF
OpenVINO GenAI： https://github.com/openvinotoolkit/openvino.genai
我怎样固定这次比较的口径
测试机器是 Intel Core i5-12600K，10 核 16 线程，内存 32 GB，系统为 Ubuntu 24.04。测试分成 CPU 与集显两组。CPU 组中，llama.cpp 设置 n_gpu_layers=0；集显组中，OpenVINO 使用 GPU.0，llama.cpp 使用 Vulkan0 并设置 n_gpu_layers=99。设备枚举确认，两者都指向 Intel UHD Graphics 770，而不是机器里的 RTX 5060 Ti。
模型使用同一套 MiniCPM5-2B 参数，但量化产物不同：
OpenVINO：INT4 IR，权重文件 1,758,401,613 字节；
llama.cpp：Q4_K_M GGUF，模型文件 1,561,318,368 字节。
两边都生成 256 个 token。OpenVINO 关闭采样并忽略 EOS，先预热一次，再记录 5 轮；llama.cpp 每组也运行 5 次。CPU 组额外测试 6、10、16 线程，集显组固定 6 个 CPU 辅助线程，并把可卸载层放到 UHD 770。
软件版本方面，OpenVINO 与 OpenVINO GenAI 均为 2026.3.1；llama.cpp CPU 组为 build 10877、commit d4abd573f，集显组为 commit 22397c3。因此，CPU 与集显两组可以分别回答各自部署场景下谁更快，但不能把跨组变化当成只改变硬件的严格消融。
不过，它们还不是严格相同的 token 工作负载：OpenVINO 使用 45-token 的真实中文提示词，llama-bench 的 tg256 是独立生成测试。所以下面的数字适合判断本机上的性能量级和调优趋势，不适合包装成实验室级后端排名。
这里还要区分三个层级。OpenVINO Runtime 原本就是面向不同深度学习模型的通用推理引擎，不只服务大语言模型；OpenVINO GenAI 建立在 Runtime 之上，用 Pipeline 封装文本、视觉语言、图像生成和语音等生成式任务；OpenVINO Model Server 再把这些能力变成服务接口。
从产品抽象和默认入口看，OpenVINO GenAI 优先解决的是单机 CPU、GPU、NPU 上的推理效率与应用集成，设计中心更接近 llama.cpp，而不是以多用户调度为第一目标的 vLLM。当前项目使用普通 LLMPipeline，测试的正是单请求、单流生成性能，所以与 llama.cpp 做本地 CPU、集显对比是合理的。
这不表示 OpenVINO GenAI 只能处理单请求。它还提供 ContinuousBatchingPipeline；配合 OpenVINO Model Server 后，也支持 Continuous Batching（连续批处理）、Paged Attention 和 OpenAI 兼容接口。只是到了这一层，测试对象就从“本地推理库”变成了“在线服务系统”，应改用并发请求吞吐、排队延迟和不同并发度下的 P95 延迟衡量，不能拿本文的单流 token/s 直接与 vLLM 的高并发吞吐比较。
这里有一个必须提前说明的口径差异：OpenVINO GenAI 直接给出了 TTFT、TPOT 和吞吐；llama-bench 把 prompt processing 与 token generation 分开测速。这足以比较逐 token 生成速度，但 pp64 表示 64 token 的预填充吞吐，它不是单次请求的首字延迟。所以本文不拿两边现有数据强行比较 TTFT。
MiniCPM5-2B 开源：端侧 Agent 的训练链被摊开了
最终结果：默认调度接近，调优后 llama.cpp 更快
先看逐字生成速度：
OpenVINO 的第一轮记录为 20.44 token/s，后面 4 轮稳定在 23.12～23.35 token/s，因此我同时保留完整 5 轮均值和后 4 轮均值，不把其中一个挑出来代表全部结果。它的 5 轮平均 TTFT 为 63.04 ms，但由于 llama.cpp 没有按同一定义记录 TTFT，这个数字只描述 OpenVINO 自身表现。
OpenVINO 没有手动指定线程数，由 CPU 插件自动调度。它后 4 轮平均为 23.23 token/s；llama.cpp 设为 16 线程时为 23.20 token/s，差距约 0.15%。两者数值上基本打平，但由于线程调度方式并不相同，这里只能称为默认使用方式的接近，不能解释成严格的同线程对照。
但 llama.cpp 最快的并不是 16 线程，而是 6 线程：25.69 token/s。相较 OpenVINO 的后 4 轮均值，它领先约 10.6%。即使把 OpenVINO 全部 5 轮都算进去，结论也不会翻转。
所以更准确的表述是：
OpenVINO 在这台 Intel CPU 上已经进入 llama.cpp 的同一性能梯队；默认调度结果接近 llama.cpp 的 16 线程成绩，但经过线程调优的 llama.cpp 仍然更快。
换到 UHD 770，OpenVINO 反而拉开差距
CPU 结果出来后，我又把两套后端切到同一块 Intel UHD Graphics 770。OpenVINO 的 5 轮生成速度为 19.31～20.95 token/s，平均 20.31 token/s；llama.cpp 通过 Vulkan0 卸载模型层，tg256 的 5 轮平均为 13.37 token/s。
按各自原生基准报告的生成吞吐计算，OpenVINO 这次比 llama.cpp 高约 52%，远大于两边各自 5 轮的波动。它足以支持一个明确的工程判断：在本机 UHD 770 和当前两套部署配置下，OpenVINO 的集显路径更有优势。
但“高约 52%”仍然不能写成纯后端的实验室级结论。OpenVINO 跑的是 45-token 真实中文提示词，llama-bench 的 tg256 是独立生成测试；两边使用的 INT4 IR 与 Q4_K_M GGUF 也不是同一种量化产物。因此，这个数字描述的是两套常见部署栈在本机的实际结果，而不是控制所有变量后的运行时消融实验。
还有一个容易忽略的结果：这块核显并没有在当前记录中超过本机 CPU。OpenVINO 从 CPU 稳态 23.23 token/s 降到集显 20.31 token/s，平均 TTFT 也从 63.04 ms 增加到 189.83 ms。llama.cpp 的 CPU 最优成绩为 25.69 token/s，集显为 13.37 token/s，不过两组使用了不同构建版本，只能看作两次部署结果，不能把差值全部归因于硬件。换句话说，OpenVINO 赢下的是两套集显路径之间的比较，不代表 UHD 770 比 i5-12600K 更适合跑这个模型。
为什么 6 线程反而比 16 线程快？
i5-12600K 是 6 个性能核加 4 个能效核的混合架构。线程数增加，并不等于每个 token 都能线性分摊给更多核心。
LLM 的自回归解码每次只生成一个新 token。这个阶段会反复读取模型权重和 KV Cache，往往同时受到内存带宽、缓存命中、线程同步和调度开销影响。线程开得更多后，新增核心带来的计算收益可能抵不过额外同步和共享资源竞争。
本次结果只能证明“这组设置下 6 线程更快”，不能单独证明是哪一个因素造成。但它已经给出一个很实用的提醒：比较 CPU 推理后端时，不应只看默认线程数，更不能把‘线程开满’自动理解为‘性能跑满’。
OpenVINO 的 CPU 插件会自行处理图优化和执行调度；llama.cpp 则把线程数等参数更直接地交给使用者。前者更容易获得一个不错的起点，后者留给用户的调优空间更明显。这也是两套工具在实际体验上的差别。
内存带宽很可能是这里绕不开的限制，但现有数据还不能把它判定为唯一原因。LLM 的逐 token 解码需要反复访问大体量权重，线程继续增加后，计算单元可能只能等待数据。仅用 OpenVINO 的 1.76 GB 权重文件乘以集显 20.31 token/s，粗略数据量就约为 35.7 GB/s，还没有计算 KV Cache 和其他开销；这个估算不等同于实测内存带宽，却能说明压力为何不可忽略。它与 6 线程快于 16 线程的现象相符，但要真正证明，还需要记录内存控制器计数器，或者改变内存频率、通道数后重复测试。
对 UHD 770 更是如此。英特尔集显没有独立显存，而是与 CPU 共用系统内存。CPU 和 GPU 不仅受同一套内存带宽上限约束，还可能争用这条通路。因此，本次核显成绩不能代表独显，更不能只看 GPU 计算单元数量推算速度。
这不会推翻现有对比，因为两套后端确实是在同一台机器、同一块 UHD 770 上完成测试；它影响的是结论解释：20.31 对 13.37 token/s 说明 OpenVINO 在当前完整部署栈中更快，但不能单凭这组数据断言差距只来自 OpenVINO 的算子优化。量化布局、Vulkan 与 OpenVINO GPU 插件的内核实现、数据搬运方式，都可能参与形成最终差距。
都叫 4-bit，为什么还不能算完全公平？
OpenVINO INT4 和 llama.cpp Q4_K_M 都属于 4-bit 权重量化方案，但“4-bit”只说明了主要权重的大致位宽，不代表文件布局、分组方式、保留高精度的张量、反量化路径和运行算子完全一致。
这次 OpenVINO 转换采用 group-size 128 和 ratio 0.8；llama.cpp 使用官方发布的 Q4_K_M GGUF。最终权重文件分别约为 1.76 GB 和 1.56 GB，OpenVINO 产物大约多 197 MB、约 12.6%。文件大小本身不能直接推出谁更快或谁质量更好，但足以说明两者不是同一份 4-bit 数据换了一个后缀。
因此，这次比较回答的是一个工程问题：在各自常见的 4-bit 部署方式下，两套后端在同一台机器上表现如何。它不是量化算法的严格消融实验。
输出质量也一样需要克制。实际生成中没有看到足以影响使用的明显差异，但我没有运行系统化的困惑度、任务集或长文本一致性评测，所以只能说“本次肉眼观察没有发现决定性差异”，不能写成“量化无损”或“两者效果完全相同”。
OpenVINO 的优势到底在哪里？
如果只追求这台机器上的最高单流生成速度，本次最快的仍是 CPU 上调好线程的 llama.cpp。它的 GGUF 生态成熟，参数透明，跨 CPU、CUDA、Vulkan 等硬件后端也更灵活。
但 OpenVINO 并不是因此就没有价值。
它的优势首先是完整的 Intel 推理栈，而且这套栈并不以 LLM 为边界：底层 Runtime 可以承载视觉、语音和其他深度学习模型，上层 GenAI 再提供 LLM、VLM、图像生成与语音 Pipeline。从模型转换、权重压缩到推理接口，TTFT、TPOT、吞吐等指标都能进入同一套工程体系。对于原本就在 OpenVINO 中部署其他模型的项目，把 LLM 接进现有运行时，会比额外维护一套推理后端更自然。
其次，它给出的默认 CPU 表现已经足够接近 llama.cpp。在这台 i5-12600K 上，后 4 轮约 23.23 token/s，不需要先研究线程组合才能进入可用区间；到了 UHD 770，OpenVINO 又以 20.31 token/s 对 13.37 token/s 取得明显领先。对重视 Intel CPU、GPU、NPU 统一部署和 API 集成的人来说，这比单看一组 CPU 峰值更能体现它的价值。
反过来，如果需求是尽可能覆盖不同品牌 CPU、独显、核显和各种 GGUF 模型，或者愿意围绕线程、绑核、批大小继续做细调，llama.cpp 仍然是更通用也更熟悉的选择。
两者不是简单的“先进替代落后”，而是优化目标不同。
这组数据能支持什么，又不能支持什么
目前的数据足够支持四个结论：
1. OpenVINO GenAI 可以在 i5-12600K 上稳定运行 MiniCPM5-2B INT4，稳态生成速度约 23 token/s；
2. OpenVINO 默认调度结果与 llama.cpp 16 线程成绩基本相同，但这不是严格的同线程对照；
3. llama.cpp 对线程数很敏感，调到 6 线程后，本次生成速度领先 OpenVINO 约 10.6%；
4. 在同一块 UHD 770 上，OpenVINO 平均生成速度为 20.31 token/s，llama.cpp Vulkan0 为 13.37 token/s；按各自原生基准口径，OpenVINO 高约 52%。
但它不能回答另外几件事：换成 Core Ultra、AMD CPU 或其他核显后谁更快；长上下文、并发请求下谁更稳；两边的峰值内存和每 token 功耗是多少；系统化任务质量是否一致。现有结果也不能把集显差距完全归因于运行时，因为量化格式、提示词计时路径并不相同，CPU 与集显组的 llama.cpp 构建版本也不同。
这也是我认为这篇实测值得写、但不该写成后端大战的原因。OpenVINO 过去曝光少，不代表它跑不动；llama.cpp 更常见，也不代表默认参数已经是最优。
在真实工程里，后端名称只是起点。这次 CPU 与集显的胜负反转正好说明：模型格式、线程调度、计时口径和目标硬件，往往比“谁号称更快”更能决定最终结果。
参考资料
英特尔与面壁智能 MiniCPM5-2B OpenVINO 适配介绍： https://mp.weixin.qq.com/s/UcCWSvngl6R0tei83v3Naw
MiniCPM5-2B 官方模型卡： https://huggingface.co/openbmb/MiniCPM5-2B
MiniCPM5-2B 官方 GGUF 权重： https://huggingface.co/openbmb/MiniCPM5-2B-GGUF
OpenVINO GenAI 官方仓库： https://github.com/openvinotoolkit/openvino.genai
OpenVINO 官方定位与工具体系： https://docs.openvino.ai/2026/about-openvino.html
OpenVINO GenAI 工作流： https://docs.openvino.ai/2026/openvino-workflow-generative.html
OpenVINO Model Server GenAI 服务说明： https://docs.openvino.ai/2026/model-server/ovms_docs_genai.html
OpenVINO GenAI 官方性能测试示例： https://github.com/openvinotoolkit/openvino.genai/blob/master/samples/python/text_generation/benchmark_genai.py
英特尔集显共享系统内存说明： https://www.intel.com/content/www/us/en/support/articles/000020962/graphics.html
vLLM 官方文档： https://docs.vllm.ai/en/stable/
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！