核心观点
端侧 AI 软件栈的竞争正在从“谁提供了 SDK”转向“谁把模型转换、量化、真实设备验证、性能剖析、部署回归和版本升级做成可重复工作流”。NVIDIA JetPack 7.2、Qualcomm AI Hub Workbench、ExecuTorch、OpenVINO、Ultralytics RKNN、SGLang 和 llama.cpp 的近期更新都指向同一件事：开发者不再满足于能跑 demo，而是要能在目标硬件上持续测、持续修、持续迁移。一个可辩论判断是，未来 1 到 2 个季度端侧平台的胜负会更多由“可测量部署闭环”决定，而不是由单个 NPU 的峰值 TOPS 决定。另一个反共识判断是，开放运行时和第三方导出工具正在削弱芯片厂商 SDK 的入口垄断，芯片厂商若不把自家工具接入主流工作流，硬件优势会被开发者绕开。
本期主线
本期端侧软件栈的主线，是部署入口正在外移。过去客户先拿芯片 SDK，再摸索模型转换、量化、板端运行和调试；现在更常见的路径是先在 PyTorch、Ultralytics、llama.cpp、OpenVINO、ExecuTorch 或 Qualcomm AI Hub 里完成模型和设备适配，再决定是否深入某个厂商的专用后端。
这会改变端侧 AI 的议价结构。NVIDIA 把 Jetson 的 BSP、Agent Skills、NemoClaw 和 Edge-LLM 组合成可执行工作流；Qualcomm 把真实设备、QNN EP、量化和 profiling 放进云端 Workbench；ExecuTorch 和 OpenVINO 试图让模型从训练框架一路落到 ARM、QNN、NPU、GPU 和移动设备；Ultralytics 则把 RKNN 导出直接放进开发者熟悉的 YOLO 工具链。谁能让“模型能不能跑、跑得多快、错在哪里、如何升级”变得可验证，谁就更接近量产客户的真实采购标准。
重点进展
JetPack 7.2 把 Jetson 部署做成 Agent 可执行流程
- 事实：NVIDIA JetPack 7.2 已上线，面向 Jetson Orin 与 Jetson Thor，包含 Jetson Linux 39.2、Ubuntu 24.04 rootfs、Linux kernel 6.8、CUDA 13.2.1、cuDNN 9.20.0、TensorRT 10.16.2、DeepStream 8.0 和 Holoscan SDK 3.9.0。官方说明该版本引入 Jetson Agent Skills，用于自动化 BSP 定制、内存优化、模型 benchmarking 和部署配置，并支持 NemoClaw 单命令安装。Jetson AI Lab 同时给出 TensorRT Edge-LLM 教程，覆盖 Cosmos Reason2 8B 在 Jetson Thor 上的 NVFP4 部署，以及 Qwen3-4B-Instruct 在 Jetson Orin Nano 8GB 上的 INT4 AWQ 部署。
- 我的判断：JetPack 7.2 的关键不只是版本升级，而是 NVIDIA 开始把端侧部署问题交给可执行工作流处理。客户真正消耗时间的地方不是安装 CUDA，而是板级配置、内存余量、模型选择、量化路径、性能基线和上线回归。
- 产业影响：Jetson 的护城河正在从硬件模块转向“能让工程团队少踩坑”的软件流程。国产机器人和边缘盒子平台如果只提供 SDK 包和例程，而没有可复现的 benchmark、自动化配置和升级路径，会在客户验证阶段吃亏。
- 后续观察：观察 Jetson Agent Skills 是否出现第三方复用案例；观察 Edge-LLM 是否持续补齐 Orin Nano、Thor、纯 C++ 推理、INT4/NVFP4 与 VLM 工作流的公开性能数据。
- 来源：NVIDIA JetPack 7.2 下载页、JetPack 7.2 论坛公告、TensorRT Edge-LLM on Jetson
Qualcomm AI Hub 把真实设备验证前移到编译与量化阶段
- 事实：Qualcomm AI Hub Workbench 2026 年 6 月 9 日更新加入 Samsung Galaxy S26 设备，升级 Lite RT 1.4.4，并默认启用
quantize_bias，还在 Compile Job 中加入 transpose-to-reshape 图改写。5 月 28 日更新中，ONNX Runtime QNN Execution Provider 升级到 2.1.0，并改为 plugin library 形式加载；AIMET-ONNX 升级到 2.31.0，增加 Gemm per-channel quantization；AI Hub 也支持将 QNN Context Binary 嵌入 ONNX。 - 我的判断：Qualcomm 的重点不是多列一个设备，而是把“模型是否能在真实 Snapdragon/Dragonwing 设备上转换、量化、剖析”前移到云端工具链。QNN EP 插件化和 context binary 嵌入，说明它在降低应用把模型交给 Qualcomm NPU 的工程摩擦。
- 产业影响：这会让手机、AI PC、XR、机器人和 IoT 客户更早排除不适配模型，也会逼迫其他端侧芯片厂商提供类似的真实设备远程验证和 profile 能力。仅提供本地 SDK 下载包，会越来越难满足多型号、多版本、多客户并行验证。
- 后续观察：观察 IQ-9075、QCS6490、Snapdragon X/8 Elite 等设备在 Workbench 中的可用性和 profile 覆盖；观察 QNN EP 插件化后是否降低 ONNX Runtime 与 Qualcomm AI Stack 之间的版本冲突。
- 来源：Qualcomm AI Hub Workbench Release Notes
ExecuTorch v1.3.1 继续把 PyTorch 原生路径推向端侧后端
- 事实：ExecuTorch v1.3.1 于 2026 年 5 月 29 日发布。该版本扩展 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 等模型支持。QNN 部分增加更多 ATen op、LPAI 和 Direct Mode、custom op、量化 annotation API、数值差异调试、performance dump 和 heap profiling。
- 我的判断：ExecuTorch 的长期价值在于让端侧部署从“重新实现一遍推理链路”回到 PyTorch 生态内。它不是要替代所有芯片 SDK，而是要把厂商后端纳入一个训练框架原生的导出与运行接口。
- 产业影响：对端侧硬件厂商来说，接入 ExecuTorch、ONNX Runtime、OpenVINO 这类上游运行时会变成生态门槛。客户会先问模型能否从 PyTorch 直接走到目标硬件，再问专用 SDK 能否进一步优化性能。
- 后续观察：观察 QNN、Ethos-U、NXP Neutron、Vulkan 和 XNNPACK 后端是否出现稳定的第三方 benchmark；观察 Android LLM runner 与多模态模型支持是否进入真实应用而不只是示例。
- 来源：ExecuTorch v1.3.1 Release Notes
OpenVINO 2026.2 把 AI PC 和边缘部署推向模型与内存治理
- 事实：OpenVINO 2026.2 于 2026 年 5 月 28 日发布，新增 Gemma 4 E2B/E4B，CPU 与 GPU 支持 Qwen3-Coder-Next、Qwen3.5、Qwen3.6、Trinity-mini、LFM2 系列，CPU 支持 YOLO26，GPU 支持 Gemma 4 31B/26B-A4B，并把 GPT-OSS-120B 扩展到 GPU。该版本还给 LFM2 增加 SDPA path，支持 Hugging Face Transformers v5.0，并在 GPU 上启用 INT4 KV-cache compression。随后 OpenVINO 2026.2.1 于 6 月 17 日发布，修复 YOLO26 GPU compile 失败以及 NPU plugin 共享 L0 command queue 的优先级问题。
- 我的判断：OpenVINO 的信号不是“又支持一些模型”，而是 Intel 正在把 AI PC 与边缘服务器的关键问题收敛到模型兼容、KV cache、加载时间、GPU/NPU 插件和 patch 速度上。端侧模型越多样，运行时越像操作系统级依赖。
- 产业影响：AI PC、工业边缘盒子和本地 Agent 工作站会更依赖可持续更新的运行时，而不是一次性导出的模型文件。OpenVINO 若能把 CPU/GPU/NPU 的故障边界讲清楚，会提高 Intel 平台在企业本地部署中的可维护性。
- 后续观察：观察 OpenVINO 2026.2.1 后续是否继续修补 NPU/GPU regressions；观察 INT4 KV-cache compression 在长上下文、本地 Agent 和 VLM 工作流中的实际内存收益。
- 来源：OpenVINO 2026.2 Release Notes、OpenVINO 2026.2.1 GitHub Release
Ultralytics 把 RKNN 导出放进 YOLO26 标准工作流
- 事实：Ultralytics 文档已提供 YOLO26 到 Rockchip RKNN 的导出指南，页面显示 2026 年 6 月 29 日更新。该指南说明 RKNN 导出已在 RK3588 的 Radxa Rock 5B 和 RK3566 的 Radxa Zero 3W 上测试，预计适用于 RK3576、RK3568、RK3562、RK2118、RV1126B、RV1103、RV1106 等 rknn-toolkit2 支持设备；导出支持 FP16 和 INT8，RV1103/RV1106 等仅 INT8 目标需使用
quantize=8。页面给出 RK3588 上 YOLO26n RKNN 推理时间 65.7 ms/im、YOLO26s 99.2 ms/im 的基准，注明使用 ultralytics 8.4.23 和 COCO128 验证。 - 我的判断：这条动态对瑞芯微比单独发布 SDK 更重要。开发者如果能直接在 Ultralytics 里
model.export(format="rknn", name="rk3588")，RKNN 就从厂商专有流程进入了视觉算法开发者的默认工具链。 - 产业影响：端侧视觉模型部署的入口会被上游框架重写。瑞芯微、全志、星宸、地平线等厂商如果能被主流模型工具原生支持，客户验证成本会显著下降；反之，哪怕 NPU 参数不错，也可能卡在模型转换和后处理适配。
- 后续观察：观察 Ultralytics 是否继续支持分割、姿态、OBB 等非检测任务的 RKNN 导出；观察 RKNN 导出是否扩展到 RK3576/RV1126B 的公开 benchmark 和生产案例。
- 来源：Ultralytics YOLO26 RKNN 导出指南
SGLang v0.5.14 显示推理栈竞争正在进入调度和缓存细节
- 事实：SGLang v0.5.14 于 2026 年 6 月 26 日发布，新增 GLM-5.2、LiquidAI LFM2.5、Kimi-K2.7-Code、Poolside Laguna-M.1、DiffusionGemma 等模型支持，并加入 DeepSeek-V4 在 GB300 上的 serving 路径、Waterfill 与 LPLB MoE load balancing、Blackwell SM100 上的 KDA CuteDSL prefill kernel、linear-attention prefix-cache int8 checkpoint pool、DeepSeek-V4 NVFP4 MoE 量化、Ascend NPU 支持 DeepSeek-V4 等更新。
- 我的判断：SGLang 看起来更偏数据中心，但它揭示了端侧部署很快也会面对的问题：真正决定体验的不是模型名字，而是 prefilling、KV/cache、MoE 调度、speculative decoding、量化和多后端一致性。云端推理栈的优化方向会向边缘服务器、工作站和机器人开发机下沉。
- 产业影响：端侧 AI 软件栈不会长期停留在“把模型塞进 NPU”。随着本地 Agent、机器人 VLM 和多模型 pipeline 变复杂，调度器、cache 命中、首 token 延迟和观测指标会进入客户验收表。
- 后续观察：观察 SGLang 的 Ascend NPU、AMD、Intel XPU 和 Apple MLX 支持是否继续成熟；观察类似 Waterfill/LPLB、HiCache、prefix-cache compression 的机制是否被边缘运行时吸收。
- 来源：SGLang v0.5.14 Release Notes
llama.cpp b9842 把跨平台二进制交付变成开源端侧入口
- 事实：llama.cpp
b9842于 2026 年 6 月 29 日发布，GitHub release 页面显示其二进制资产覆盖 Android arm64、Ubuntu arm64、Ubuntu OpenVINO 2026.2.1 x64、Ubuntu ROCm 7.2 x64、Ubuntu SYCL FP16 x64、macOS arm64/x64、iOS XCFramework，以及 Windows CUDA 12.4/13.3 包。该 release 还包含/v1/models中 preset 与 cached model entries 去重的更新。 - 我的判断：llama.cpp 的优势不只是 GGUF 和量化，而是它把“能不能在我的设备上拿到可运行包”做成了开源项目的日常交付能力。对很多端侧开发者来说，预编译包、OpenAI 兼容接口和跨平台覆盖，比厂商白皮书更直接。
- 产业影响：这会继续压低端侧模型部署的入门门槛，也会迫使芯片厂商用更好的后端集成、benchmark 和驱动质量来争取开发者。硬件平台若不能被 llama.cpp、OpenVINO、ONNX Runtime、ExecuTorch 等入口覆盖，会在实验和原型阶段失去可见度。
- 后续观察：观察 llama.cpp 的 OpenVINO、SYCL、ROCm、Android arm64 包是否保持稳定更新；观察各芯片厂商是否围绕 GGUF、OpenAI API 兼容服务和本地模型管理提供正式支持。
- 来源：llama.cpp b9842 Release
反共识观察
第一，芯片厂商 SDK 的入口权正在被上游工具链稀释。过去客户为了用某颗 NPU，必须从厂商 SDK 开始；现在 Ultralytics 可以导出 RKNN，ExecuTorch 可以接 QNN 与 Arm 后端，OpenVINO 可以接 Intel CPU/GPU/NPU，llama.cpp 可以提供跨平台运行入口。这个判断可以验证：如果未来 1 到 2 个月更多端侧客户案例从 PyTorch、YOLO、GGUF、ONNX 或 OpenAI-compatible server 开始描述部署流程，而不是从芯片 SDK 开始，说明入口确实在外移。
第二，端侧 AI 的关键 KPI 可能会从“单模型极限性能”转向“可测工作流覆盖率”。模型转换成功率、量化精度损失、profile 可解释性、真实设备可用性、版本回退、cache 与内存统计、API 兼容性，会比孤立的 token/s 或 TOPS 更影响量产决策。这个判断也可验证：若未来发布中更多厂商强调 Workbench、benchmark、Agent Skills、remote profiling、context binary、导出插件和 CI，而不是只强调新模型或新算子，说明部署工作流正在成为竞争核心。
观察清单
- JetPack 7.2 的 Agent Skills 是否形成公开第三方案例，尤其是内存优化和模型 benchmark 是否能跨 Orin/Thor 复用。
- Qualcomm AI Hub Workbench 的 QNN EP 插件化是否减少 ONNX Runtime、QAIRT、AIMET 之间的版本冲突，并覆盖更多 Dragonwing 真实设备。
- ExecuTorch v1.3.1 的 QNN、Ethos-U、NXP、Vulkan 和 XNNPACK 后端是否出现独立 benchmark 与生产应用。
- OpenVINO 2026.2.1 后续是否继续修复 NPU/GPU 已知问题，INT4 KV-cache 是否被本地 Agent 和 VLM 应用采用。
- Ultralytics RKNN 导出是否扩展到更多 YOLO 任务类型、更多 Rockchip 芯片和第三方板卡公开性能。
- SGLang 的 MoE 调度、prefix-cache 和 NPU 后端优化是否被边缘服务器和本地工作站运行时借鉴。
- llama.cpp 跨平台 release 包是否继续覆盖 OpenVINO、SYCL、ROCm、Android 和 iOS，并保持 OpenAI API 兼容入口稳定。
评论