今日必看
ONNX Runtime 1.28.0 把端侧部署竞争推向 EP 交付层
Microsoft 在 2026 年 7 月 25 日发布 ONNX Runtime v1.28.0。这个版本的关键信号不是某个单点模型跑分，而是把模型包、Execution Provider、硬件发现、量化和安全边界一起推进：ONNX 升到 1.22.0，protobuf 升到 6.33.5；CUDA EP 的 cuDNN、cuFFT 改为运行时可选，nvrtc 不再链接；实验性 C/C++ API 被引入，OrtModelPackageApi 转入 experimental C API；Model Package Phase 2、schema versioning、external_data 折叠进 session options、从候选字符串选择 compiled-model compatibility info、Linux 通过 sysfs accel devices 发现 NPU、CUDA plugin EP 的 Windows ARM64 包、WebGPU plugin EP 0.3.0、QNN EP 修复等都进入同一版。证据阶段是正式代码 release 和发布说明，不是第三方设备 benchmark。主来源
一个可辩论判断是：端侧 AI 软件栈的下一轮分化，可能不再由“谁先支持某个模型名”决定，而由 EP 能否像插件一样被发现、装载、记录版本并在失败时暴露足够上下文决定。若这个判断成立，QNN、OpenVINO、WebGPU、CoreML、XNNPACK、VitisAI、VSINPU 以及国产 NPU 后端都会被迫回答同一个问题：模型包里是否带有可复查的后端兼容信息、外部权重路径、量化记录和失败日志。反例也明确：如果整机项目仍只接受厂商 SDK 的离线转换包，ONNX Runtime 的 EP ABI 和 Model Package 只会停留在跨平台开发者入口，难以进入量产默认链路。后续验证指标是 Plugin EP 是否出现更多第三方硬件包、Linux NPU discovery 是否被实际设备采用、以及 Model Package 是否开始被端侧应用用来交付可回滚模型资产。
这条线对端侧 SoC 厂商尤其尖锐。过去很多平台把“支持 ONNX”理解成离线转换和少量算子覆盖，真正交付时仍靠工程师手工选择量化脚本、后端版本和模型缓存。1.28.0 把这些灰区推到运行时边界：compiled-model compatibility info 决定同一个模型包能否选择合适后端，EP version logging 和 profiling memory statistics 决定故障是否可追溯，sysfs NPU discovery 决定 Linux 设备能否以通用方式暴露加速器。它还把安全修复放在同一叙事里，包括 FlatBuffer loader、raw-pointer bind_input、sub-byte packed type、GQA/KV cache、RKNPU 隐式 bias allocation、WebGPU Pad/Slice/GatherBlockQuantized 等输入校验和越界问题。端侧部署不只是性能问题，也开始是供应链和运行时可信边界问题。
软件 / 框架
- llama.cpp b10155：
ggml-org/llama.cpp在 2026 年 7 月 27 日发布 b10155，新增mtmd对 MiMo-V2.5 音频输入的支持，release notes 写明包含 MiMo audio 的 GGUF converter 和 C++ implementation，并继续提供 Android arm64、Windows arm64 OpenCL Adreno、OpenVINO 2026.2.1、Vulkan、CUDA 13.3 等二进制包。它把本地多模态入口从文本/图像继续推向音频 token；局限是本次没有给出端侧 ASR 延迟、功耗或准确率复测。主来源
新项目雷达
OpenETA：
OpenMOSS/OpenETA7 月 25 日创建，Apache-2.0，7 月 27 日在 README 中宣布dev/real-robot-deployment分支，范围包括 real-robot deployment stack、hardware interfaces 和 physical-agent tooling；项目把 OpenAI-compatible planner、Tool/MCP、监督边界、回放证据和 RealSense/UR5e 等适配写成同一套 physical-agent 框架。它的价值是把 Agent 的审计边界搬到机器人执行链路；局限是目前主要看项目自述和代码，真实机器人长程任务成功率还要等待可复查日志。主来源vla-kernels：
djkim9031-research/vla-kernels7 月 22 日创建、7 月 27 日仍有更新，README 称其在 Jetson Thor 上为 SmolVLA 编写 CUDA/Triton 热点 kernel，并给出自报结果：SmolVLA 450M bf16 从 eager 198 ms/chunk 到 torch.compile + CUDA Graphs 73.8 ms，再到 54.3 ms、18.4 Hz，accuracy retention 0.99995。它把 VLA 加速从“换 runtime”推进到具体 kernel 与端到端动作周期；局限是仓库暂无许可证，数字来自项目方，未见第三方 Thor 复测。主来源
持续观察
验证指标：ONNX Runtime 1.28.0 后续要看三个信号：Model Package 是否被真实应用拿来管理量化模型和外部权重；Plugin EP 是否出现更多可独立安装、可记录版本的硬件后端；Linux NPU discovery 是否能在 Intel、高通或其他边缘设备上稳定暴露设备能力。若这些没有发生，EP ABI 仍会更像框架内部工程，而不是端侧交付标准。
反向观察：llama.cpp b10155、OpenETA 和 vla-kernels 都在强调“把模型入口做薄、把执行证据做厚”。这个方向会削弱只卖 SoC 峰值算力的叙事，但前提是第三方能复现音频、多模态动作和真实机器人闭环结果；如果复测缺席，采购仍会回到厂商 SDK、BOM、供货和既有工程关系。
非共识判断：端侧软件栈可能先出现“运行时中立层”的采购语言，再出现真正的硬件中立。客户会要求同一模型包能在 GPU、NPU、WebGPU 或 CPU fallback 之间留下可审计选择记录，但不会立刻放弃厂商专有加速库。这个阶段对瑞芯微、地平线、黑芝麻、爱芯元智、高通和 Intel 都是机会，也是压力：谁先把后端能力、失败原因和回滚路径交给通用运行时，谁就更容易进入早期评估；谁只给封闭转换器，谁就要承担更高的集成解释成本。
最小复核项：下周可优先检查 ONNX Runtime 1.28.0 的安装包、Plugin EP 示例、WebGPU 0.3.0 issue 和 QNN 相关回归；同时看 llama.cpp 的 MiMo 音频路径是否出现可下载模型、命令行样例和端侧延迟记录。只要这些证据开始跨仓库出现，今天的判断才算从发布说明进入工程现实。
评论