核心观点
端侧 AI 软件栈的竞争正在从“谁支持更多模型”转向“谁能把模型、算子、量化、缓存、后端和发布包收敛成可交付路径”。OpenVINO、ExecuTorch、ONNX Runtime、ncnn、MNN 和 vLLM 的近期版本变化共同说明，真正稀缺的不是某一个推理框架，而是跨 CPU、GPU、NPU、Vulkan、QNN、RISC-V、WebGPU 和移动系统时仍能减少 fallback、降低启动内存、保持数值正确性的工程能力。一个可辩论的判断是：未来 1 到 2 个季度，端侧硬件选型会更多参考“主流开源运行时是否已把该后端纳入稳定路径”，而不是只看厂商私有 SDK 的演示效果。验证指标是官方 wheel/预编译包覆盖、算子缺口关闭速度、KV cache 与量化路径的回归测试、模型转换失败率和真实设备上的冷启动内存。
本期主线
本期主线是端侧 AI 部署进入“后端收敛期”。此前端侧部署的核心矛盾是把模型压小、跑起来；现在更难的问题是，让同一个模型在不同芯片、操作系统和图形/AI 后端之间少改代码、少丢精度、少掉到 CPU fallback。OpenVINO 2026.2 增加 GenAI、VLM、KV cache 压缩和模型服务器能力，ExecuTorch 1.3.1 扩展 Arm、Qualcomm、NXP、CUDA、Metal、MLX、Vulkan 等后端，ONNX Runtime 1.26.0 强化 Execution Provider 生态，ncnn 20260526 和 MNN 3.5.0 则把 Vulkan、HarmonyOS、RISC-V、MUSA、QNN、KV cache 和转换工具做进端侧发布流程。
这对瑞芯微、全志、星宸、地平线、黑芝麻、爱芯元智、Qualcomm、MediaTek、Intel、NVIDIA Jetson 等端侧平台都有直接影响。客户不会只问“能不能跑 Qwen、Gemma 或 VLM demo”，而会问：模型转换是否可重复，Attention、Rotary、LayerNorm、GEMM、SDPA、TopK、KV cache 是否走目标后端，发布包是否覆盖 Android、HarmonyOS、Linux、Windows 和浏览器，出现数值偏差时能否定位到算子或量化策略。端侧 AI 的产业门槛因此从单点适配转向持续维护的后端矩阵。
重点进展
OpenVINO 2026.2 把端侧 GenAI 推向模型服务器和多模态管线
- 事实：OpenVINO 2026.2.0 于 2026 年 5 月 28 日发布。官方 release notes 显示，该版本新增 Gemma 4 E2B/E4B 等模型支持，并扩展 Qwen3-Coder-Next、Qwen3.5、Qwen3.6、LFM2、GPT-OSS-120B 等模型或 GPU 路径；OpenVINO GenAI 支持自定义扩展库注册未支持算子，GPU 侧启用 INT4 KV-cache 压缩，并通过 cache blobs 降低 GPU 模型加载时间；OpenVINO Model Server 增加 Qwen 3.5/3.6 tool-calling 支持和流式语音转写。
- 我的判断：OpenVINO 的重点不只是 Intel 硬件优化，而是把“本地推理库”向“可服务化的本地 AI 运行时”推进。对企业 AI PC、边缘服务器和工业盒子来说，工具调用、VLM、语音转写和模型加载时间比单轮 tokens/s 更接近真实部署瓶颈。
- 产业影响：Intel 平台会借 OpenVINO 把 CPU/GPU/NPU 的本地部署入口继续做厚；同时也给其他端侧厂商一个参照：运行时若不能处理自定义算子、KV cache 压缩、模型服务器接口和多模型流水线，就很难承接 Agent 或多模态应用。
- 后续观察：关注 OpenVINO 2026.2 的 GPU INT4 KV-cache 压缩是否在长上下文 VLM 与 Agent 工作流中被开发者采用，以及 Model Server 的 OpenAI/API 兼容路径是否进入企业本地部署案例。
- 来源：OpenVINO 2026.2.0 Release
ExecuTorch 1.3.1 显示 PyTorch 正在争夺端侧后端入口
- 事实：ExecuTorch v1.3.1 于 2026 年 5 月 29 日发布。官方 release notes 称该版本扩展 Arm Ethos-U/TOSA/VGF/Cortex-M、Qualcomm QNN、NXP、CUDA、Metal、MLX、Vulkan、XNNPACK 等后端，新增或扩展 Qwen3.5 MoE、Gemma 4 31B、LFM2.5、Voxtral Realtime/TTS、Llama4 export 等模型支持；QNN 后端新增多类 ATen 算子、LPAI 和 Direct Mode、调试与性能 dump，NXP 后端更新 eIQ Neutron SDK 3.1.1。
- 我的判断：ExecuTorch 的产业意义在于减少“从 PyTorch 到端侧设备”的断裂。过去很多端侧平台输在模型导出、算子覆盖和调试工具，而不是输在峰值算力；PyTorch 原生路径越完善，客户越会要求芯片厂商提供可进入主流训练框架的 delegate，而不是只给私有转换器。
- 产业影响：Qualcomm、NXP、Arm Ethos-U、Apple Metal/MLX 和 Vulkan 后端都会因 ExecuTorch 获得更多开发者入口。国内端侧 SoC 厂商如果长期停留在封闭 SDK，可能在早期 PoC 中被开发者绕开，即使芯片本身成本和功耗更优。
- 后续观察：关注 ExecuTorch 的 QNN、Vulkan、Arm 和 NXP delegate 是否能覆盖更多量产模型，以及 Android LLM runner、调试 dump 和性能 profiling 是否降低真实项目的定位成本。
- 来源：ExecuTorch v1.3.1 Release
ncnn 20260526 把移动端部署从轻量 CNN 扩展到 LLM 运行工程
- 事实：Tencent ncnn 于 2026 年 5 月 26 日发布 20260526 预编译库，覆盖 Android、HarmonyOS、iOS、macOS、Linux、Windows、WebAssembly、watchOS、tvOS、visionOS 等平台。该版本新增 HarmonyOS 预编译包流程；Vulkan 后端新增 SDPA/FlashAttention、RotaryEmbed、GroupNorm、Reduction、Unfold 等算子，并加入持久化 pipeline cache、mmap 模型加载、host memory 权重驻留和逐层权重上传；同时新增
benchncnn_llm，覆盖 LLM prefill/decode benchmark。 - 我的判断：ncnn 的变化说明移动端推理框架正在从传统视觉模型走向 LLM/VLM 的运行工程。它没有把重点放在大而全的模型 API，而是在启动时间、权重加载、Vulkan pipeline cache、HarmonyOS 包和转换工具上补部署短板。
- 产业影响：这对手机、AI 眼镜、IPC、机器人视觉模组和国产操作系统生态都重要。若 ncnn 能在 HarmonyOS、Android 和 WebAssembly 等端上稳定承接小模型和视觉-语言前处理，它会继续成为芯片厂商之外的事实适配层。
- 后续观察：关注
benchncnn_llm是否形成可比较的端侧 LLM benchmark，Vulkan FlashAttention 与 mmap 加载是否在真实 Android/HarmonyOS 设备上降低首 token 延迟和峰值内存。 - 来源：ncnn 20260526 Release
ONNX Runtime 1.26.0 把 Execution Provider 生态继续拆细
- 事实：ONNX Runtime v1.26.0 于 2026 年 5 月 8 日发布。官方 release notes 披露，该版本新增
.ort模型加载的可选 memory mapping、CPU EP 的 RISC-V Vector 支持、OpenVINO EP 升级、WebGPU GridSample 和 Split-K 改进；CUDA plugin EP 增加 graph support、profiling API 和资源计量，并提示 1.27.0 将移除 CUDA 12 支持，CUDA runtime 将逐步转向专用 Execution Provider。 - 我的判断：ONNX Runtime 的方向是把硬件后端从核心框架中进一步插件化。对端侧部署来说，这既是机会也是压力：EP 越独立，硬件厂商越容易接入；但 EP 的质量、profiling、图捕获、内存映射和安全修复也会直接决定客户是否敢上量产。
- 产业影响：OpenVINO、QNN、CoreML、WebGPU、CUDA、RISC-V 等后端会继续围绕 ONNX Runtime 形成中间层竞争。瑞芯微 RKNN、星宸 SDK、全志 Tina、地平线和黑芝麻工具链若要进入更广泛开发者流程，也需要考虑 ONNX/EP 级的可诊断性，而不是只提供模型转换脚本。
- 后续观察：关注 CUDA plugin EP 独立化后是否降低部署包耦合，RISC-V Vector CPU EP 是否出现可复现性能数据，以及 OpenVINO/QNN/CoreML 等 EP 的算子缺口是否继续缩小。
- 来源：ONNX Runtime v1.26.0 Release
MNN 3.5.0 显示国内端侧栈在补多后端 LLM 能力
- 事实：Alibaba MNN 3.5.0 于 2026 年 4 月发布。官方 release notes 称该版本聚焦多后端 LLM 推理、高性能量化与端侧语音交互；Vulkan 后端新增 LLM 推理支持，接入摩尔线程 MUSA GPU 后端，QNN 后端支持 Attention 和更多 LLM 算子，CPU 后端新增 RISC-V RVV；同时引入 TurboQuant TQ3/TQ4 KV Cache 量化、多轮对话 Prompt Cache、异步三阶段 Token2Wav 流水线和智能语音打断。
- 我的判断：MNN 的价值不在“又一个 LLM 端侧框架”，而在它把国产 GPU、QNN、Vulkan、RISC-V、语音流水线和 KV cache 量化放进同一个发布节奏。这说明国内端侧部署开始从单模型演示转向面向多端交互产品的运行时组合。
- 产业影响：对阿里系应用、Android 终端、国产 GPU、RISC-V 设备和高通终端来说，MNN 可能成为端侧语音、视觉和小模型交互的中间层。对其他国内 SoC 厂商而言，能否被 MNN、ncnn、ONNX Runtime 或 ExecuTorch 这类通用栈稳定支持，会影响开发者首选适配路径。
- 后续观察：关注 TurboQuant TQ3/TQ4 在长对话和多模态场景下的质量损失，MUSA/QNN/Vulkan 后端是否进入更多公开 benchmark，以及 MNNChat 的语音交互能力是否被真实应用吸收。
- 来源：MNN 3.5.0 Release
vLLM 0.22.0 把服务端推理问题外溢到端侧边缘服务器
- 事实：vLLM v0.22.0 于 2026 年 5 月 29 日发布，包含 459 个 commits 和 230 位贡献者。官方 release notes 显示，该版本强化 DeepSeek V4、Model Runner V2、实验性 Rust frontend、多级 KV cache offloading、batch-invariant inference、RISC-V Vector attention kernels、Intel XPU、AMD ROCm、NVIDIA Blackwell/SM12x 等路径，并在 batch-invariant Cutlass FP8 上给出 28.9% end-to-end latency improvement。
- 我的判断：vLLM 不是典型端侧框架，但它正在定义边缘服务器和工作站本地推理的工程基线。多级 KV cache、speculative decoding、前端 API、模型 runner、Rust frontend 和硬件后端支持，会逐渐影响企业本地 Agent、机器人机房和边缘推理盒的部署预期。
- 产业影响：端侧 AI 的上沿会与本地服务器推理栈相连：AI PC、Jetson 工作站、工业边缘服务器和小型机柜，不会只看移动端 runtime，也会看 vLLM、SGLang、TensorRT-LLM 这类服务端栈能否稳定承接长上下文、多模型和工具调用流量。
- 后续观察：关注 vLLM 的 RISC-V、XPU、ROCm 和 CPU 路径是否从 release notes 进入可复现部署，Model Runner V2 何时成为默认路径，以及多级 KV cache offloading 是否改善边缘服务器的显存成本。
- 来源：vLLM v0.22.0 Release
反共识观察
第一，端侧 AI 软件栈的赢家未必是“最端侧”的框架，而是最能把训练框架、模型格式、硬件后端和发布包连接起来的框架。ncnn 和 MNN 在移动端很强，ExecuTorch 把 PyTorch 开发者带到端侧，ONNX Runtime 用 EP 聚合硬件，OpenVINO 把本地 GenAI 服务化，vLLM 则定义边缘服务器推理接口。硬件厂商真正要争的不是让开发者下载自己的 SDK，而是让自己的后端出现在这些主流路径里，并且少出转换失败、算子 fallback、数值偏差和版本锁死问题。
第二，模型部署的下一轮门槛可能不是量化算法本身，而是“缓存与加载工程”。OpenVINO 的 GPU cache blobs 和 INT4 KV-cache、ncnn 的 mmap 加载与 pipeline cache、MNN 的 Prompt Cache 与 TurboQuant、vLLM 的多级 KV cache offloading，都指向同一个问题：端侧和边缘设备的体验瓶颈经常发生在冷启动、首 token、长上下文内存和多轮状态复用，而不是只发生在单 token 解码吞吐。这个判断可以被验证：如果未来几个月 release notes 继续把 cache、mmap、offloading、pipeline cache、model server warmup 放在亮点区，而不是只强调新模型支持，说明部署工程已经超过模型名单成为主战场。
观察清单
- OpenVINO 2026.2 的 GPU INT4 KV-cache、cache blobs 和 Model Server tool-calling 是否被企业本地 AI 案例采用。
- ExecuTorch 的 QNN、Arm Ethos-U、NXP、Vulkan 和 Metal/MLX delegate 是否继续扩大算子覆盖，并降低 Android/嵌入式调试成本。
- ncnn 的 HarmonyOS 预编译包、Vulkan FlashAttention、mmap 加载和
benchncnn_llm是否形成真实设备上的可复现 benchmark。 - ONNX Runtime 的 CUDA plugin EP、RISC-V Vector CPU EP、OpenVINO EP 和 WebGPU 路径是否继续插件化，并减少平台间版本耦合。
- MNN 的 MUSA、QNN、Vulkan、RISC-V RVV 和 TurboQuant 路径是否进入更多公开应用或硬件 benchmark。
- vLLM 的 Model Runner V2、多级 KV cache offloading、RISC-V/CPU/XPU/ROCm 路径是否从服务器扩展到边缘服务器和本地 Agent 部署。
- 瑞芯微 RKNN、全志 Tina、星宸 SDK、地平线、黑芝麻、爱芯元智等国内端侧栈是否开始更多披露算子覆盖、转换成功率、量化误差、冷启动内存和第三方运行时适配，而不是只展示模型 demo。
评论