端侧AI部署正在从跑通模型转向证据链

核心观点

端侧 AI 软件栈的最新竞争点，正在从“能不能把模型转换成功”转向“能不能给客户一条可复现、可测量、可维护的部署证据链”。RKNN-LLM、Pulsar2、Qualcomm AI Hub Models、ExecuTorch、LiteRT、Sophon SAIL、ONNX Runtime 和 OpenVINO 的近期更新，都在补算子、量化、性能数据、后端委托、低延迟视频链路、NPU 插件和安全边界。一个可辩论判断是，未来 1 到 2 个月，端侧平台的真实胜负会更多取决于“模型支持清单 + 性能数据 + 运行时接口 + 调试工具 + 长期兼容性”，而不是芯片标称 TOPS。另一个反共识判断是，开源通用运行时并不会简单替代芯片厂 SDK，反而会迫使芯片厂 SDK 把私有能力包装成更标准、更可审计的部署接口。

本期主线

本期动态的共同主线，是部署证据链变长了。客户不再满足于发布页上的“支持 Qwen、Gemma、MiniCPM、YOLO”，而是开始追问：具体版本是否支持，量化误差在哪里，WebGPU、QNN、Metal、Vulkan、NPU 插件和本地 SDK 是否能复用同一套模型资产，低延迟视频输入和 LLM 阶段管理是否稳定，安全修复和 CUDA/ONNX 版本迁移是否会打断量产项目。

这对端侧 AI 厂商提出了更硬的要求。瑞芯微、爱芯元智、算能、高通、Intel、Google、Meta/PyTorch 和 Microsoft 的软件栈看起来各不相同，但都在向同一个方向靠拢：把模型部署从一次性工程服务，变成可下载、可测试、可复现、可回滚的产品能力。短期内，这会让“SDK 生态成熟度”成为比单点模型适配更重要的选型指标。

重点进展

RKNN-LLM v1.3.0 把 Rockchip 大模型栈推向长上下文和接口兼容

事实：airockchip/rknn-llm 于 2026 年 6 月 17 日发布 release-v1.3.0，新增 Qwen3.5、Gemma4、SmolLM3 支持，优化多模态输入接口和 cache reuse 策略，支持多个 EOS token ID、tokenizer 和 embedding callbacks，并改善 RK3576 上部分模型的长上下文解码性能；该版本还修复 RV1126B 内存统计问题、RK3588 部分模型推理数值溢出问题，并提升 rkllm_server_demo 与 OpenAI API 接口的兼容性。
我的判断：这说明 RKNN-LLM 的竞争点已经不只是“能在 RK3588/RK3576 上跑大模型”，而是开始补真实应用需要的接口、缓存、采样参数和长上下文稳定性。OpenAI API 兼容尤其重要，因为它降低了上层 Agent、RAG 和本地服务迁移成本。
产业影响：瑞芯微生态会从传统视觉模型部署，继续向本地 LLM/VLM 服务扩展。但它也面临更高验证压力：客户会要求看到同一模型在 RK3576、RK3588、RV1126B 上的内存峰值、token 延迟、崩溃率和量化误差，而不是只看示例是否跑通。
后续观察：看 release-v1.3.x 是否继续修复社区反馈的模型兼容和稳定性问题；看 RKLLM 的 OpenAI API 兼容是否被本地 Agent、离线会议机、AI 盒子和机器人开发者实际采用。
来源：GitHub Releases

爱芯元智 Pulsar2 6.0 显示端侧 SDK 正在从芯片适配转向方案适配

事实：爱芯元智 2026 年 6 月 23 日发布社区推广半年总结，披露截至 2026 年 6 月 15 日，公司在 Hugging Face 和 ModelScope 上的模型仓库总数已超过 200 个；NPU 工具链 Pulsar2 迎来 6.0 正式版本，新增 Qwen3.5、Gemma4、MiniCPM-V 4.6、MiniCPM5-1B、Qwen3-ASR、Qwen3-TTS 等端侧大模型支持，并新增 AX637、AX615、AX88x0 系列芯片支持。公司同时称 AX8850 SDK 社区版本已开放硬件资料、软件工具、开发文档和 NPU 工具链，并开源 AXCL 运行时源码用于驱动适配。
我的判断：Pulsar2 6.0 的关键不只是支持更多模型，而是爱芯元智把“模型仓库、工具链、运行时、驱动适配、AI-NVR、Agent BOX、本地语音助手”等内容放到同一个社区入口里。这更接近中长尾客户需要的方案适配，而不是单纯芯片 SDK。
产业影响：端侧 SDK 会越来越像产品渠道。模型仓库、OpenAI API Compatible、远程推理、性能监控和参考方案，会直接影响客户是否敢把 AX8850、AX637、AX615 等平台纳入评估。对瑞芯微、星宸、全志、地平线和黑芝麻来说，这也是一个信号：SDK 的开放程度正在影响芯片进入长尾市场的速度。
后续观察：看 Pulsar2 6.0 支持的模型是否提供可复现 benchmark、量化精度报告和板端脚本；看 AXCL、ax-llm、ax-remote-infer 是否形成第三方移植案例，而不是只停留在官方展示。
来源：爱芯元智

Qualcomm AI Hub Models v0.57.1 把性能数据变成模型交付的一部分

事实：Qualcomm AI Hub Models 于 2026 年 7 月 3 日发布 v0.57.1，说明该补丁版本包含 bugfixes 和 performance data updates，更新 CLI 以移除 AI Hub Workbench 不可用设备，新增和修正多款 LLM/VLM 在 GenieX（QAIRT）上运行的性能数据，并增加 IQ-8275 的 Qwen3-8B、Qwen3-VL-4B-Instruct 资产，以及 Qwen3-4B-Instruct-2507 的 GenieX（LLama CPP）支持。
我的判断：Qualcomm 的重点不是多列几个模型，而是把性能数据、设备可用性和模型资产一起维护。端侧模型部署会越来越像“带实测指标的 SKU”，客户需要知道某个模型在某个芯片、某个 runtime、某个精度格式下是否可用。
产业影响：这会提高其他芯片厂的交付标准。只说“支持 Qwen”已经不够，客户会要求看到设备型号、runtime、内存、延迟、吞吐、功耗和失败边界。Qualcomm 的 AI Hub 路线也会继续挤压只提供离线转换工具、缺少统一模型目录的平台。
后续观察：看 IQ-8275 资产是否扩展到更多 VLM、ASR 和端侧 Agent 模型；看 GenieX、QAIRT 与 LLama CPP 的性能数据是否能覆盖热稳定、长会话和真实 App 负载。
来源：GitHub Releases

ExecuTorch v1.3.1 让 PyTorch Edge 从手机继续下沉到嵌入式后端

事实：PyTorch ExecuTorch 于 2026 年 5 月 29 日发布 v1.3.1，官方称这是 1.3 系列第一个 broadly published patch release。该版本扩展 embedded、mobile、GPU targets 的模型和后端覆盖，包含 Arm Ethos-U/TOSA/VGF/Cortex-M、NXP、Qualcomm QNN、CUDA、Metal、MLX、Vulkan、XNNPACK 等改进，并新增或扩展 Qwen3.5 MoE、Gemma 4 31B、LFM2.5、Voxtral Realtime/TTS、Llama4 export 和 Android LLM runner 文档。
我的判断：ExecuTorch 的产业意义在于把 PyTorch 模型导出、量化、后端委托和移动/嵌入式 runtime 拉成一条链。它不是某个芯片厂的替代品，而是让芯片厂必须证明自己能被 PyTorch Edge 工作流可靠调用。
产业影响：对 Qualcomm、Arm Ethos-U、NXP、移动 GPU 和未来更多 NPU 后端来说，能进入 ExecuTorch 的 delegate 和测试体系，会逐渐成为生态入口。国内端侧芯片厂如果长期停留在私有转换工具，可能在开发者入口上输给更标准的 PyTorch 部署链。
后续观察：看 ExecuTorch 的 QNN、Vulkan、Metal、MLX、Arm 后端在真实移动设备和嵌入式板卡上的稳定性；看国内芯片厂是否提供 ExecuTorch delegate、示例和量化校准路径。
来源：GitHub Releases

LiteRT v2.1.6 把端侧运行时竞争拉回 C API、ARMv7 和测试覆盖

事实：Google AI Edge 的 LiteRT 于 2026 年 7 月 2 日发布 v2.1.6，主要更新包括将 C/C++ API 重构为 header only、C/C++ API 使用时不再需要链接 Abseil、发布 ARMv7 prebuilts，并将 Accelerator Test Suite 的 single op 覆盖扩展到 43 个 f16/f32 算子；同时改进内置 kernel 对高维 tensor 的支持。
我的判断：这类更新看起来不如新模型发布吸引眼球，但更接近端侧量产痛点。C API 依赖、ARMv7 预编译包、单算子测试和高维 tensor 支持，决定的是第三方 App、旧设备、嵌入式 Linux 和 Android 生态能不能低成本集成。
产业影响：LiteRT 会继续争夺 Android、Web、移动 GPU/NPU 和轻量 GenAI 的默认入口。它对 RKNN、Pulsar2、Qualcomm AI Stack、OpenVINO、ExecuTorch 的压力不是单点性能，而是跨平台一致性和工具链摩擦成本。
后续观察：看 LiteRT 的 ATS 是否扩展到更多 NPU/GPU delegate；看 ARMv7 prebuilts 是否带来旧设备、低成本 IPC、智能屏和轻量 IoT 端侧 AI 应用的重新适配。
来源：GitHub Releases

Sophon SAIL v3.11.1 把低延迟视频链路和 LLM 阶段管理放进边缘 SDK

事实：sophgo/sophon-sail 于 2026 年 7 月 2 日发布 v3.11.1，新增内存模式 Encoder，编码输出可直接写入 fragmented MP4 内存缓冲区；Decoder 新增 low_delay 和 nobuffer 参数，Decoder_RawStream 支持按解码顺序获取当前帧，MultiDecoder discard_mode 新增阻塞策略，并新增 EngineLLM max_stage/min_stage 定义。该版本还修复多路解码器、BMImage asnumpy、cvwrapper convert_format 等内存泄漏问题，并增加 BM1684X SDK v26.03.01、BM1684X A2 SDK v2.1/v2.2 支持。
我的判断：算能这次更新的价值在视频和 LLM 的交叉处。很多边缘 AI 项目不是单纯跑一个 LLM，而是多路视频解码、前后处理、推理、编码、网络传输和本地生成任务混在一起；低延迟解码和内存模式编码比模型榜单更接近真实系统瓶颈。
产业影响：工业视觉、AI-NVR、机器人视觉盒子、园区安防和边缘检索类产品，会把 SDK 的视频链路和内存稳定性纳入选型。国产边缘算力卡如果想进入存量系统，必须证明多路视频、低延迟、内存泄漏修复和 SDK 兼容性比通用 GPU 方案更省心。
后续观察：看 v3.11.x 是否披露多路视频 + LLM/VLM 混合负载 benchmark；看 BM1684X/A2 在 AI-NVR、智能会议、工业质检和视频 Agent 项目中是否出现可验证客户案例。
来源：GitHub Releases

ONNX Runtime v1.27.0 和 OpenVINO 2026.2.1 显示通用运行时正在变成治理层

事实：ONNX Runtime 于 2026 年 6 月 19 日发布 v1.27.0，目标 ONNX 1.21，并提示 CUDA 12 packages 已显式命名且将弃用，建议迁移 CUDA 13。该版本包含多项安全修复，新增 plugin EP 的 zero-copy I/O、session 初始化回调、CUDA Plugin EP provider options，以及 FLOAT8E8M0、量化 calibration cache、WebGPU Qwen3-style QKV/MLP fusion、Gemma 4 KV-shared decoder 等能力。OpenVINO 于 2026 年 6 月 17 日发布 2026.2.1，修复 YOLO26 在 GPU 编译失败问题，并解决 NPU plugin 使用 shared L0 command queue 时违反应用/推理优先级的问题。
我的判断：通用运行时已经不只是“模型格式中间层”，而是在承担安全、插件、后端隔离、量化缓存、WebGPU、NPU 优先级和 CUDA 版本迁移的治理角色。真正进入生产的端侧项目，会越来越依赖这类运行时来降低硬件后端变动带来的风险。
产业影响：ONNX Runtime 和 OpenVINO 的更新会倒逼芯片厂 SDK 提供更清晰的 EP/plugin、NPU priority、zero-copy、量化和错误诊断能力。Intel、NVIDIA、Qualcomm、国产 NPU 厂商都会被客户放在同一张“运行时治理能力”表里比较。
后续观察：看 ORT 1.28 是否按计划支持 ONNX 1.22；看 CUDA 13 迁移是否影响 Jetson、AI PC 和边缘服务器部署；看 OpenVINO NPU plugin 的优先级修复是否减少多应用共享 NPU 时的现场问题。
来源：ONNX Runtime Releases、OpenVINO Releases

反共识观察

第一，端侧 AI 软件栈的壁垒可能不在“支持最多模型”，而在“支持错误可被定位”。RKNN-LLM、Pulsar2、Qualcomm AI Hub、ExecuTorch、LiteRT、Sophon SAIL、ONNX Runtime 和 OpenVINO 都在补接口、测试、性能数据、低延迟链路、内存泄漏、插件 EP 和 NPU priority。客户最终会奖励能解释失败原因、能复现实测结果、能稳定升级的栈，而不是仅在发布页列出最多模型名的栈。

第二，通用运行时和芯片厂 SDK 的关系不会是替代，而是相互约束。ExecuTorch、LiteRT、ONNX Runtime 和 OpenVINO 提供跨平台抽象，但真正跑到端侧 NPU、ISP、VPU、DSP 和视频链路上，仍离不开芯片厂 SDK。未来 1 到 2 个季度更可能出现的格局，是芯片厂把私有能力封装成标准 delegate、plugin EP、OpenAI-compatible endpoint、性能数据和远程调试工具，而不是客户完全绕过芯片厂软件栈。

观察清单

RKNN-LLM release-v1.3.x 是否继续修复 RK3588/RK3576 上的崩溃、数值溢出、Gemma/Qwen/MiniCPM 兼容和长上下文问题。
Pulsar2 6.0、AXCL、ax-llm、ax-remote-infer 是否产生第三方可复现项目，尤其是 AI-NVR、Agent BOX、本地语音助手和视频理解 Agent。
Qualcomm AI Hub Models 是否把 GenieX/QAIRT 的性能数据扩展到热稳定、长会话、VLM 视频输入和真实 App 延迟。
ExecuTorch 的 QNN、Vulkan、Metal、MLX、Arm Ethos-U/TOSA 后端是否出现更多量产设备案例，而不只是 release note 支持。
LiteRT 的 Accelerator Test Suite 是否继续扩大 delegate 覆盖，并给出跨 Android、Web、ARMv7 和移动 GPU/NPU 的一致性结果。
Sophon SAIL 是否公布多路视频 + LLM/VLM 的混合负载 benchmark，证明低延迟解码、内存模式编码和 EngineLLM 阶段管理能改善真实系统。
ONNX Runtime 和 OpenVINO 的 plugin EP、WebGPU、NPU priority、CUDA 13 迁移和 ONNX 版本更新是否影响边缘客户的升级节奏。