今日必看
VKNN 把 Android GPU 推理从“能跑”推进到可审计的 runtime
VKNN 在 2026 年 7 月 13 日发布 v1.3.0，主变化不是新模型，而是对 Vulkan、CPU backend、核心 runtime、ONNX import 和 DMA-BUF 示例做内存安全与鲁棒性加固，并称修复 16 个已确认问题；release 同时说明已在两类手机级 GPU 上重新验证 CNN、YoNoSplat 8-view encoder、Qwen2.5-Coder 0.5B int8 解码，均为 0 CPU fallback。项目 README 把 VKNN 定义为无第三方 runtime 依赖的 C++17 Android GPU ONNX 推理引擎，路径包括手写 protobuf 导入、NCHW IR、图优化、Vulkan NC4HW4 打包、fp16 storage / fp32 accumulation，以及 caller-owned DMA-BUF I/O。主来源
这条动态的证据阶段是代码与项目方 on-device 验证，不是第三方 benchmark，也不是量产客户。它的重要性在于：端侧部署不只是在 NPU SDK、CPU delegate、Metal/Core ML 或 CUDA 小板之间选择，Android GPU 这条更碎片化但装机基础巨大的路径正在出现更工程化的开源 runtime。过去很多端侧项目的默认路线是先找 SoC 厂商转换工具，再围绕固定 NPU backend 调整模型；VKNN 代表另一种路线，先用 Android GPU 和 ONNX IR 建立可检查的公共执行层，再接受不同芯片的驱动差异。
一个可辩论判断是，未来端侧多模态应用的最低可用门槛，可能先被“可审计的通用 Android GPU runtime”拉低，而不是被单一 SoC 的 NPU 工具链拉低；因为 Vulkan 路径可以横跨高通、联发科、瑞芯微和部分车机/机器人 Android 设备，但代价是算子覆盖、内存布局和驱动差异更难控制。这个判断不等于看空 NPU。更可能出现的格局是：原型验证、长尾模型和小批量部署先走 Vulkan/CPU fallback，量产项目再迁移到 QNN、RKNN、Pulsar2、OpenVINO 或厂商自有 delegate。谁能把两条路径之间的模型一致性、数值误差和性能边界讲清楚，谁就更容易进入端侧开发者的日常工具链。
验证指标很具体：VKNN 是否能给出 Adreno、Mali、Immortalis 等不同 GPU 的同模型延迟、内存峰值和功耗；是否有第三方把 SmolVLM、Qwen 小模型或 3DGS 模型接入真实相机链路；以及它的 ONNX 覆盖是否从项目自带模型扩展到常见端侧 VLM / Agent 组件。如果后续只停留在小样本 demo，Android GPU runtime 仍会是备选；如果出现稳定的跨设备复现，它会直接挤压“必须先绑定 NPU SDK 才能做端侧 AI”的默认假设。
软件 / 框架
LeRobot v0.6.0：Hugging Face 在 7 月 6 日发布 v0.6.0，新增 VLA-JEPA、FastWAM、LingBot-VA、GR00T N1.7、MolmoAct2、EO-1、EVO1、Multitask DiT、奖励模型 API、
lerobot-rollout、六个统一lerobot-eval仿真 benchmark，并把最低 PyTorch 提到 2.7。判断上，它正在把机器人模型部署从“训练脚本集合”推向“想象、评估、回收失败数据”的闭环框架；真正的验证点不是模型名单，而是第三方能否用同一 CLI 报告失败轨迹、修正数据和复测结果。主来源ONNX Runtime v1.27.1：Microsoft 在 7 月 11 日发布补丁版，修复 KleidiAI
igemm回归、QMoE CPU livelock、graph-capture session 初始化回归和 CustomOp 兼容性，并为 NVIDIA CUDA EP 增加 batch-1 decode 的 QMoE GEMV fast path。判断上，端侧 runtime 的竞争正在进入“低 batch 解码路径和插件兼容性”细节；对本地 Agent 来说，batch-1 解码、插件前向兼容和空图初始化这类小问题，往往比峰值吞吐更影响能否长期驻留。主来源llama.cpp b9993：7 月 13 日的 b9993 增加 Hy3 / Hunyuan 3 的 GGUF 架构支持与 MTP speculative decoding，并继续提供 Android arm64、iOS XCFramework、Windows arm64 OpenCL Adreno、OpenVINO 2026.2.1、CUDA 12/13 等多平台包。它的价值是让新模型更快进入本地推理生态，局限是 release 本身没有端侧延迟、功耗或内存基准；后续要看 Hy3 GGUF 是否形成移动端或边缘网关的真实使用，而不是只完成格式接入。主来源
新项目雷达
- Inspect Robots：
robocurve/inspect-robots是 MIT 许可的 alpha 阶段机器人 / VLA 评测框架，README 强调把Policy与Embodiment分离，任务、场景和 scorer 独立定义，并用 Rerun 记录可复现 rollout；7 月 14 日 v0.8.0 让插件声明的设备槽驱动 setup wizard。判断上，它不是推理 runtime，但补上了部署后“同一策略、不同机器人或仿真体”评测记录的缺口。主来源
持续观察
验证信号：接下来 30 天重点看 VKNN 是否披露具体手机 SoC / GPU 型号、同一 ONNX 模型在 Vulkan 与 CPU fallback 间的延迟差、峰值内存、功耗和失败 case；同时看 LeRobot v0.6.0 的
lerobot-rollout与六个 benchmark 是否被第三方用于报告真实机器人闭环，而不是只停留在官方 smoke test。参考来源工程分叉：如果 VKNN、llama.cpp、ONNX Runtime 这类通用 runtime 继续补足小模型、视频输入和低 batch 解码，端侧应用团队会更倾向先用公共执行层验证产品形态，再把稳定负载下沉到芯片厂商后端。这会削弱单一 SDK 对早期选型的锁定力。参考来源
反例条件：如果 Android GPU runtime 仍无法稳定覆盖端侧 VLM / Agent 常见算子，或者跨设备驱动差异导致复现成本高于 NPU SDK，那么今天关于“通用 Android GPU runtime 会拉低端侧多模态门槛”的判断应降级；届时端侧软件栈的主战场仍会回到 Qualcomm QNN、RKNN、Pulsar2、OpenVINO、ExecuTorch 等硬件绑定路径。参考来源
评论