核心观点
端侧 AI 软件栈的竞争正在从“厂商给一套 SDK，客户按文档转换模型”，转向“运行时、驱动、模型服务器、量化工具和 API 兼容层能否像操作系统组件一样持续更新”。瑞芯微 RKNN-LLM、爱芯 AX-LLM、ONNX Runtime、Windows AI Execution Providers、llama.cpp 和 vLLM Semantic Router 的共同信号是：模型部署的主要风险已经不只是算子不支持，而是缓存、量化、工具调用、跨平台二进制、系统更新和运行证据能否被长期维护。一个可辩论判断是，未来 1 到 2 个季度，端侧平台的真实门槛会更多来自“可更新底座”的工程纪律，而不是单次 benchmark 成绩。另一个反共识判断是：开放运行时和系统级分发渠道会先拿走开发者入口，芯片厂商 SDK 必须在功耗、稳定性和售后诊断上证明迁移价值。
本期主线
本期端侧 AI 软件栈动态的主线，是“部署链路正在产品化”。瑞芯微把 RK3576、RK3588 等平台上的大模型运行问题落到缓存复用、长上下文、OpenAI API 兼容和数值溢出修复；爱芯元智把 AX650/AXCL 的模型运行时做成统一 axllm、Docker 镜像、Windows AXCL 构建和内存预检；ONNX Runtime 继续把 Execution Provider 插件化、诊断化；Microsoft 通过 Windows Update 更新各类 AI Execution Provider；llama.cpp 则用密集预编译资产覆盖 Android、iOS、Windows Arm64、OpenVINO、SYCL、Vulkan、ROCm 和 Adreno OpenCL。
这说明端侧软件栈正在从“转换工具”升级成“可运营底座”。客户真正要买的不是一次成功的 demo，而是后续模型版本变化、驱动变化、系统更新、API 兼容、长上下文内存压力、工具调用格式和多后端故障都能被定位、回退和持续修补。对芯片厂商而言，SDK 不再只是卖芯片的附件，而会变成客户是否敢量产的核心凭证。
重点进展
瑞芯微 RKNN-LLM v1.3.0 把端侧大模型栈推进到运行时维护阶段
- 事实：RKNN-LLM 于 2026 年 6 月 17 日发布
release-v1.3.0，新增 Qwen3.5、Gemma4、SmolLM3 模型支持，优化多模态输入接口和 cache 复用策略，支持多个 EOS token ID 和ignore_eos_token参数，改进 RK3576 上部分模型的长上下文解码性能，修复 RV1126B 内存统计和 RK3588 部分模型推理数值溢出问题，并提升rkllm_server_demo与 OpenAI API 接口的兼容性。 - 我的判断：这条更新的重点不是模型名单变长，而是瑞芯微开始把“能跑大模型”拆成更细的运行时问题：缓存复用、EOS 行为、长上下文、数值稳定、性能统计和 API 兼容。它更接近客户量产时会遇到的故障边界。
- 产业影响：RK3576/RK3588 的端侧 AI 竞争力，会越来越依赖 RKNN-LLM 能否持续吸收新模型和修复线上问题。对工业边缘盒子、IPC、HMI 和轻量机器人来说，OpenAI API 兼容也会降低应用迁移门槛。
- 后续观察：看 RKNN-LLM 是否披露 Qwen3.5/Gemma4/SmolLM3 在 RK3576、RK3588、RV1126B 上的延迟、内存和功耗基准；看第三方设备厂商是否开始把
rkllm_server_demo作为正式服务入口。 - 来源：RKNN-LLM release-v1.3.0
爱芯 AX-LLM 把模型部署从样例工程推进到多平台运行包
- 事实：AX-LLM README 显示，该项目由爱芯元智主导，用于探索常用 LLM 在已有芯片平台上的落地能力，支持 AX650A/AX650N 和 AX630C，覆盖 Qwen2.5、Qwen3、MiniCPM、SmolLM2、Llama3，以及 Qwen3-VL-2B-Instruct、Qwen3.5-2B、FastVLM-1.5B-GPTQ-Int4、InternVL3_5-1B-GPTQ-INT4 等 VLM。其 latest release 提供 AX650、AXCL x86/arm64/riscv64、Windows MinGW64 二进制和 Docker 镜像。6 月 22 日主干提交还合并了 Qwen3Omni/audio 相关改动、AXCL Windows 构建修复和 CMM 内存 guard。
- 我的判断：AX-LLM 的意义不在于爱芯又支持了一个模型，而在于国产端侧芯片厂商正在补“交付形态”：统一命令、固定下载链接、离线 Docker、Windows AXCL、内存预检和多模态仓库，比单个模型转换脚本更接近开发者真正需要的工作流。
- 产业影响：爱芯的优势如果成立，会体现在低成本板端 VLM、视频理解和行业边缘设备中。它也给其他国产 NPU 厂商一个压力：模型栈不能只停留在 demo 仓库，必须能被 CI、Docker、Windows 工具链和板端内存限制约束。
- 后续观察：看 AX-LLM 的 rolling release 是否能保持二进制与文档同步；看 Qwen3.5、MiniCPM-V-4.6、Jina embedding 和 Qwen3Omni 这些仓库是否给出可复现吞吐、首 token 延迟和长时间稳定性。
- 来源：AX-LLM latest release、AX-LLM 6 月 22 日合并提交
ONNX Runtime 1.27.0 显示通用运行时正在变成后端治理层
- 事实：ONNX Runtime 于 2026 年 6 月 19 日发布 v1.27.0，说明该版本面向 ONNX 1.21，CUDA 12 包被明确标名且进入弃用路径，建议迁移到 CUDA 13；同时加入多项安全修复、Execution Provider Plugin API 的 zero-copy I/O、session 初始化回调、plugin EP session-options getter、CUDA Plugin EP streams/external allocators provider options，并扩展 WebGPU、CoreML、TensorRT RTX、DML、QNN 等后端更新。
- 我的判断：ONNX Runtime 的战略价值正在从“统一模型格式”转向“统一后端生命周期”。当 CUDA、WebGPU、CoreML、QNN、TensorRT RTX、OpenVINO 等后端都需要独立修复和诊断时，运行时本身就变成了端侧异构计算的治理层。
- 产业影响：这会削弱单一芯片 SDK 对上层应用的绝对锁定。应用开发者会更倾向先用 ONNX Runtime 这类通用运行时建立可迁移的模型路径，再根据功耗和延迟决定是否深入厂商专用 SDK。
- 后续观察：看 plugin EP API 的 zero-copy 和 session 回调是否被 QNN、OpenVINO、TensorRT RTX、WebGPU 等后端实际采用；看 CUDA 12 弃用是否推动边缘设备软件栈加速升级到 CUDA 13。
- 来源：ONNX Runtime v1.27.0
Windows AI 更新把端侧推理后端变成操作系统可服务组件
- 事实：Microsoft 的 AI updates history 显示，Windows 11 26H1 在 2026 年 5 月 26 日更新 AMD MIGraphX、AMD Vitis、Intel OpenVINO、Nvidia TensorRT-RTX 和 Qualcomm QNN Execution Providers，其中 Qualcomm QNN 为 2.2605.2.0。KB5096135 页面说明，Qualcomm QNN Execution Provider 是用于 ONNX Runtime 和 Windows 机器学习场景的执行提供方，可通过 QNN SDK 构建 QNN graph，并通过 Windows Update 自动下载安装，适用于 Windows 11 24H2 和 25H2。
- 我的判断：这件事容易被低估，因为它不像发布新模型那样显眼。但它说明端侧 AI 加速正在进入系统更新通道：运行时后端不再只是开发者手动下载的 SDK，而是 Windows 维护的 AI 组件。
- 产业影响：对 Qualcomm、Intel、AMD、NVIDIA 和 AI PC 厂商来说，系统级分发会改变软件栈责任边界。谁能进入 OS 组件更新表，谁就能更早触达大量终端；谁的后端只能依赖应用自带 DLL，谁就要承担更高的兼容和售后成本。
- 后续观察：看 Windows AI updates 是否继续按月更新 Execution Providers；看 QNN、OpenVINO、TensorRT-RTX 在 Windows ML、ONNX Runtime、Copilot+ PC 应用中的调用量和故障修复周期是否公开。
- 来源：Microsoft AI updates history、KB5096135 Qualcomm QNN Execution Provider
llama.cpp b9763 继续把本地模型运行时做成跨平台分发层
- 事实：llama.cpp 于 2026 年 6 月 22 日发布 b9763，发布资产覆盖 macOS arm64/x64、iOS XCFramework、Ubuntu x64/arm64/s390x、Ubuntu Vulkan、ROCm 7.2、OpenVINO 2026.2、SYCL FP32/FP16、Android arm64、Windows x64/arm64 CPU、Windows Arm64 OpenCL Adreno、Windows CUDA 12.4/13.3、Vulkan、OpenVINO、SYCL、HIP 等组合。该版本主体变更包括 server 为 tool call responses API 增加 id。
- 我的判断：llama.cpp 的真正价值已经超过 GGUF 推理本身，它正在成为“本地模型交付格式 + 预编译运行时 + OpenAI 风格服务接口”的组合。对端侧应用来说，跨平台二进制和工具调用一致性，往往比某个后端极限性能更先决定能不能快速试错。
- 产业影响：这会继续抬高厂商 SDK 的门槛。若专用 NPU SDK 不能显著降低功耗、内存或延迟，开发者会先用 llama.cpp 在 Android、Windows Arm、OpenVINO、Vulkan、Adreno 和 Apple 设备上验证产品，再决定是否迁移。
- 后续观察：看 Windows Arm64 OpenCL Adreno、OpenVINO 2026.2、SYCL、ROCm 7.2 包的下载和 issue 是否持续增长；看 tool call response id 是否减少本地 Agent 服务中的调用追踪问题。
- 来源：llama.cpp b9763
vLLM Semantic Router Fusion 把模型部署问题推向路由与证据层
- 事实：vLLM 团队于 2026 年 6 月 16 日发布 Semantic Router Fusion 文章，介绍 Fusion 作为 vLLM-SR 的路由原语：一个请求可由多个 panel models 生成候选答案，再由 judge model 分析共识、矛盾、覆盖缺口和独特洞察，并合成最终回答；系统保留 routing policy、trace、失败模型记录和 token usage，并支持
vllm-sr/auto、vllm-sr/fusion和 request-level plugin override 等入口。 - 我的判断：这条动态说明“模型部署”正在从选择单个 checkpoint，变成选择一个可审计的模型系统。端侧和边缘服务器未来未必只跑一个最强模型，而可能按隐私、延迟、成本、任务难度和上下文连续性路由到多个本地/云端模型组合。
- 产业影响：对 AI PC、企业边缘服务器和机器人本地基站来说，运行时不只要负责 token/s，还要负责路由策略、失败处理、模型组合、trace 和成本账本。端侧模型越多，软件栈越需要一个可观察控制面。
- 后续观察：看 vLLM-SR Fusion 是否给出可复现实验，比较 Fusion、单模型、AutoMix、Router-R1 等路线的质量/成本/延迟；看本地 vLLM 后端、私有模型和公开 provider 的混合部署是否成为企业 Agent 的常见架构。
- 来源：vLLM Semantic Router Fusion
反共识观察
第一，端侧 AI 软件栈的赢家未必是“最封闭、最一体化”的厂商 SDK。更可能出现的是双层结构：开放运行时先赢开发者入口，厂商 SDK 后赢量产环节。llama.cpp、ONNX Runtime、vLLM-SR、Windows AI 组件和 AX-LLM 的共同方向，是让模型、后端、服务接口、trace 和运行包更容易被替换；芯片厂商如果只强调官方 SDK 性能，而不能提供可更新、可诊断、可回退的量产底座，迁移吸引力会下降。
第二，端侧 AI 的“系统更新能力”会成为新的护城河。过去客户问的是模型能不能转换成功，未来客户会问：驱动能不能自动更新，后端能不能独立升级，长上下文内存能不能预警，工具调用能不能追踪，Windows/Android/Linux/板端能不能保持一致，模型换代后是否还能复用服务接口。这个判断可以被验证：如果未来 1 到 4 周更多发布说明开始强调 Execution Provider、OpenAI API 兼容、Docker/Windows 分发、内存 guard、cache policy、trace 和 error policy，而不是只强调新增模型数量，说明软件栈竞争已经转向可运营底座。
观察清单
- RKNN-LLM v1.3.0 是否给出 RK3576、RK3588、RV1126B 上的公开性能、内存和长上下文数据。
- AX-LLM 的 rolling release 是否稳定维护 AX650、AXCL、Windows、Docker 和多模态模型仓库的一致性。
- ONNX Runtime Plugin EP API 是否被 QNN、OpenVINO、TensorRT-RTX、WebGPU 等后端用于独立升级和 zero-copy。
- Windows AI Execution Providers 是否继续按月进入 Windows Update，并披露更多版本、设备覆盖和修复说明。
- llama.cpp 的 Windows Arm64 Adreno、OpenVINO、SYCL、Vulkan、ROCm 包是否出现更多真实端侧应用案例。
- vLLM-SR Fusion 是否发布可复现实验，证明多模型路由在质量、成本和延迟之间有稳定收益。
- 芯片厂商 SDK 是否开始把内存预检、trace、工具调用、OpenAI API 兼容和失败回退作为默认能力，而不是附属 demo。
评论