端侧AI软件栈的胜负正在转向内存调度

核心观点

端侧 AI 软件栈的主战场正在从“能不能把模型跑起来”，转向“能不能在有限显存、内存和异构后端之间稳定调度”。这意味着下一轮端侧部署的稀缺能力不是单个算子的峰值性能，而是 KV cache、量化权重、插件后端、模型预处理和工具调用解析能否在同一运行时内被治理。一个反常识判断是：越靠近端侧，越不一定奖励最封闭的一体化 SDK，反而可能奖励可替换后端、可观测错误和可独立升级的运行时组件。未来 1 到 4 周，真正要看的是这些 release 能否进入 Jetson、AI PC、Android、国产 ARM/RISC-V 设备和边缘服务器的真实集成，而不是发布说明里的模型名单继续变长。

本期主线

本期软件栈动态有一条共同线索：运行时正在把“模型适配”拆成多个可维护层，包括前端协议、模型解析器、KV cache 调度、量化核、插件化 Execution Provider、设备后端和包分发。vLLM 与 SGLang 把服务端推理的内存和调度问题继续工程化，llama.cpp 与 ncnn 把低门槛本地部署推向更多 CPU/GPU/移动端组合，ONNX Runtime、ExecuTorch、OpenVINO 和 MNN 则在争夺更底层的异构后端控制权。

这对端侧厂商的含义是：硬件选型会越来越受软件栈“失败模式”影响。客户不只问 NPU TOPS，也会问模型转换失败后能否 fallback、量化误差能否定位、KV cache 是否能按请求和场景回收、工具调用输出是否稳定，以及后端插件能否独立修复。

重点进展

vLLM 0.23.0 把推理框架推进到多层 KV cache 管理

事实：vLLM 在 2026-06-15 发布 v0.23.0，发布说明写明该版本包含 408 个 commit、200 名贡献者，并强化 DeepSeek-V4、Model Runner V2、Rust frontend、Transformers v5 兼容和多层 KV cache offloading；其中 Model Runner V2 默认扩展到 Llama 和 Mistral dense models，KV offloading 增加 object-store secondary tier、per-request policy 和生命周期 hook。
我的判断：vLLM 的重心正在从“高吞吐 serving”转向“显存状态系统”。这会影响边缘服务器和工作站级端侧部署，因为长上下文、多 Agent 并发和多模态预处理会把瓶颈推到缓存生命周期，而不是单次 token/s。
产业影响：对 AI PC、边缘盒子和机器人本地基站来说，vLLM 这类框架会成为 GPU、CPU、XPU 和外部存储之间的调度层，削弱单一硬件 SDK 对上层应用的锁定能力。
后续观察：看 v0.23.x 的 KV offloading 是否进入更多非 NVIDIA 后端；看 Rust frontend 是否从实验入口变成低资源部署的默认 API 面。
来源：vLLM v0.23.0 release

SGLang 0.5.13 把 speculative decoding 从特性做成默认路径

事实：SGLang 在 2026-06-13 发布 v0.5.13，新增 Nemotron 3 Ultra、Step-3.7-Flash、Command A+ 等自回归模型支持，并把 Spec V2 设为默认 speculative decoding 路径，覆盖 triton、FA3、MLA、aiter 等后端，同时将 Spec V1 标为 deprecated。
我的判断：Speculative decoding 正在从“可选性能技巧”变成推理栈的默认控制流，这会让端侧模型部署更依赖运行时正确性。草稿模型、主模型、缓存页和后端 attention 实现只要有一层不稳定，收益就会变成线上故障。
产业影响：对机器人和 Agent 设备而言，端侧响应速度不再只靠更小模型，也可以靠运行时调度换取；但这也要求 SDK 提供更强的压测、回退和可观测接口。
后续观察：看 Spec V2 在长上下文、Mamba/hybrid-linear 和多模态模型下的线上 bug 率；看 SGLang 是否把更多端侧 GPU 或边缘 NPU 路径纳入同一 speculative decoding 抽象。
来源：SGLang v0.5.13 release

llama.cpp b9660 说明本地运行时正在变成跨后端分发层

事实：llama.cpp 在 2026-06-15 发布 b9660，发布资产覆盖 Android arm64、macOS arm64/x64、iOS XCFramework、Ubuntu CPU/arm64/Vulkan/OpenVINO/SYCL/ROCm、Windows CPU/CUDA/HIP/SYCL/Vulkan/OpenCL Adreno 等组合；该版本还修复了 LFM2 tool-call parsing double-escaping 问题。
我的判断：llama.cpp 的价值已经不只是 GGUF 生态，而是把模型格式、量化权重、平台二进制和工具调用边界打包成一个低摩擦交付层。端侧应用开发者会先用它验证产品闭环，再决定是否迁移到厂商 NPU SDK。
产业影响：这会给 RKNN、QNN、OpenVINO、Core ML、Metal、Vulkan 等专用后端带来压力：如果专用后端不能明显降低延迟、功耗或内存，通用运行时会先拿走原型和中小规模量产入口。
后续观察：看 OpenVINO、SYCL、Adreno OpenCL 等二进制包的下载量和 bug 修复频率；看 tool-call parser 修复是否继续增加，因为 Agent 场景会放大输出格式错误。
来源：llama.cpp b9660 release

ONNX Runtime WebGPU Plugin EP 把浏览器和桌面 GPU 纳入插件化后端

事实：ONNX Runtime 在 2026-05-29 发布 WebGPU Plugin EP v0.1.0，WebGPU Execution Provider 以独立插件库形式发布，可在兼容 ONNX Runtime 1.24.4 或更新版本中运行时注册；发布说明列出 Python wheel、.NET NuGet、Windows/Linux/macOS 原生二进制，以及 MatMul/Gemm、Attention、GroupQueryAttention、RotaryEmbedding、MatMulNBits、QMoE 等算子覆盖。
我的判断：WebGPU 进入 Plugin EP 的意义不在于浏览器 demo，而在于把“GPU 后端升级”从核心运行时发布周期中拆出来。端侧部署越碎片化，越需要这种独立后端版本节奏。
产业影响：AI PC、浏览器 Agent、本地文档处理和轻量 VLM 会受益于更低安装门槛；同时，端侧 SoC 厂商如果不能给出类似插件化升级路径，SDK 维护成本会暴露给客户。
后续观察：看 WebGPU EP 是否获得移动平台和 Linux arm64 支持；看 Intel、AMD、Qualcomm GPU 路径是否通过插件迭代缩短问题修复周期。
来源：ONNX Runtime WebGPU Plugin EP v0.1.0 release

ExecuTorch 1.3.1 把 PyTorch 端侧入口扩展到更多硬件委托

事实：ExecuTorch 在 2026-05-29 发布 v1.3.1，说明这是第一个广泛发布的 1.3 patch release；该版本扩展 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 等模型支持。
我的判断：ExecuTorch 正在把 PyTorch 的模型准备流程压到端侧硬件委托层。它未必会在每个硬件上拿到最高性能，但会成为模型团队和硬件团队之间的“共同接口”。
产业影响：对 Arm MCU、Android、Apple 设备、Qualcomm 平台和 NXP 边缘芯片来说，ExecuTorch 的吸引力在于减少模型工程的重写成本；国产端侧平台如果只提供封闭转换工具，可能在开发者入口上吃亏。
后续观察：看 QNN、NXP、Arm 后端的算子覆盖是否继续扩大；看 .pte 资产和 Android/iOS runner 是否进入更多量产应用样例。
来源：ExecuTorch v1.3.1 release

OpenVINO 2026.2 把 Intel 端侧栈压向 GenAI 管线和模型服务器

事实：OpenVINO 在 2026-05-28 发布 2026.2.0，新增 Gemma 4 E2B/E4B 等模型支持，扩展 CPU/GPU 上的 Qwen3-Coder-Next、Qwen3.5、Qwen3.6 等模型覆盖；OpenVINO GenAI 支持自定义 extension library 注册 unsupported ops，GPU 支持 INT4 KV-cache compression，Model Server 增加 Qwen 3.5/3.6 tool-calling 和 streaming transcription。
我的判断：Intel 端侧 AI 的关键不只是 NPU，而是把 CPU、GPU、NPU 和 Model Server 包装成可部署 GenAI 管线。OpenVINO 正在把 AI PC 从“本地推理设备”推向“本地服务节点”。
产业影响：这会影响企业本地 Agent、语音入口、文档 VLM 和小型边缘服务器部署；但它也会把客户锁定在 AVX2、现代 Linux 基线和 Intel 工具链的兼容性要求上。
后续观察：看 INT4 KV-cache compression 在长上下文场景的实际内存收益；看 tool-calling 与 streaming transcription 是否进入 OpenVINO Model Server 的标准样例和企业部署文档。
来源：OpenVINO 2026.2.0 release

MNN 主干连续修补 CPU、OpenCL 和 LLM 路径，显示国产端侧栈在补工程细节

事实：MNN 在 2026-06-15 的主干提交中合入多项端侧相关变更，包括修复 TFLite binary activation conversion、修复作为子项目使用时的 KleidiAI path mapping、修复 RVV pack/unpack 函数错误、在 LLM 路径中调整 linear_attention 处理，以及让 OpenCL 后端支持 quantized GEMM/GEMV 与 FP local size 的 heuristic guidance。
我的判断：这些不是大版本发布，但更接近真实量产问题：转换器、CPU 向量路径、OpenCL 量化矩阵乘和 LLM attention 处理，都是端侧应用从 demo 走向设备适配时最容易卡住的地方。
产业影响：MNN 的优势在于同时覆盖移动端、桌面端和国内开发者生态；如果它能持续把 bugfix 和性能优化落在转换器与异构后端，可能比单纯支持更多模型名称更有产业价值。
后续观察：看这些主干修复是否进入下一个 3.5.x 或 3.6.0 release；看 RVV、KleidiAI 和 OpenCL 路径是否出现公开 benchmark 或设备样例。
来源：MNN linear_attention commit、MNN OpenCL heuristic commit

ncnn 近期把 RotaryEmbed 和 Vulkan 修复落到 ARM 与移动 GPU 路径

事实：ncnn 在 2026-05-26 发布 20260526 编译版本，包含 Android、Android Vulkan、HarmonyOS、HarmonyOS Vulkan 等资产；随后在 2026-05-30 合入 ARM RotaryEmbed NEON 实现，2026-06-03 增加 RotaryEmbed bf16 NEON 支持，2026-06-04 修复 deconv Vulkan out-of-range write。
我的判断：ncnn 的更新说明一个现实：端侧部署的长期价值常常来自“小算子 + 小修复”。RotaryEmbed、bf16 NEON 和 Vulkan 越界写这类问题不会出现在发布会叙事里，却会决定 LLM/VLM 能否稳定落到手机、开发板和轻量边缘设备。
产业影响：对全志、瑞芯微、星宸、低功耗 ARM 盒子和 HarmonyOS 设备生态来说，ncnn 仍然是轻量视觉与小模型部署的重要底座；它的算子覆盖和 GPU 稳定性会影响国产 SoC 的实际可用模型范围。
后续观察：看 RotaryEmbed 优化是否推动更多小语言模型或 VLM 示例进入 ncnn；看 HarmonyOS Vulkan 包是否获得更多设备侧问题修复。
来源：ncnn 20260526 release、RotaryEmbed bf16 NEON commit

反共识观察

一个容易被低估的变化是：端侧 AI 软件栈正在走向“开放运行时先赢入口，厂商 SDK 后赢量产”的双层结构。通用运行时用 GGUF、ONNX、PyTorch export、WebGPU、Vulkan、OpenCL、XNNPACK、KleidiAI 等路径先降低试错成本；厂商 SDK 则需要在功耗、内存、稳定性和售后工具上证明自己值得迁移。换句话说，NPU 厂商不能只把“官方 SDK 性能更好”当作默认答案，因为开发者会先用 llama.cpp、ONNX Runtime、ExecuTorch、MNN、ncnn 这类工具验证需求。

第二个非共识判断是：未来端侧部署的核心指标会从 TOPS/模型大小，转向“状态可控性”。KV cache 能不能分层、工具调用能不能稳定解析、后端插件能不能单独升级、量化误差能不能定位、GPU/NPU 失败能不能回退，这些指标会比单一 benchmark 更能解释客户为什么选择某个芯片平台。

观察清单

vLLM 0.23.x 的多层 KV offloading 是否进入更多边缘服务器和 AI PC 部署文档。
SGLang Spec V2 默认化后，长上下文和多模态模型的线上正确性问题是否减少。
llama.cpp 的 OpenVINO、SYCL、Adreno OpenCL、Vulkan arm64 包是否持续获得下载和修复。
ONNX Runtime WebGPU Plugin EP 是否补齐 Linux arm64、移动平台或更多 GPU vendor 路径。
ExecuTorch 的 QNN、NXP、Arm 后端是否把模型支持转化为可复用量产样例。
MNN 下一版是否正式收录 2026-06-15 这批 CPU/OpenCL/LLM 修复。
ncnn 的 RotaryEmbed 与 Vulkan 修复是否带来更多小模型、VLM 或 HarmonyOS 端侧案例。