今日必看
Qualcomm AI Hub Models 把端侧模型目录推进到运行时迁移层
Qualcomm AI Hub Models 在 2026 年 7 月 15 日发布 v0.58.0，新增 Qwen3-VL-8B-Instruct 的 Qualcomm 优化版本，并给 Qwen3-1.7B 增加 QAIRT 部署 recipe 和 SpinQuant 量化流程；同版还为 Qwen3-4B-Instruct-2507 增加 geniex_llamacpp 支持，用 memory-mapped prefilled inputs 降低 LLM eval 阶段的 host memory pressure，修复 Qwen tokenizer/checkpoint 处理，并明确 legacy Genie runtime 继续让位给 GenieX，默认 QAIRT 仍为 2.45。它还把 Robotics tag 应用于 Pi-0.5 和 GR00T-N1.5。主来源
这条动态的证据阶段是官方 release、模型目录和部署 recipe，不是第三方真机 benchmark，也不是客户量产。它和 7 月 9 日 v0.57.3 把 GR00T-N1.5 放进 AI Hub 的区别在于：上一次更像机器人模型资产上架，这一次更像把 VLM/LLM 的编译、量化、运行时迁移和内存管理纳入同一条交付链。尤其是 geniex_llamacpp 与 memory-mapped prefilled inputs 同时出现，说明 Qualcomm 不只在扩模型名录，也在补“模型如何被端侧应用反复评估、迁移和加载”的细节。对开发者来说，真正省时间的不是网页上多一个模型卡片，而是从模型、runtime、设备、量化到数值检查之间少写一层胶水代码。
一个可辩论判断是，端侧 AI 软件栈的竞争短期不会只看“支持多少模型”，而会看模型资产能否附带默认 runtime、量化策略、预填充内存路径、perf/numerics 查询和废弃 runtime 迁移提示。若这个判断成立，Qualcomm、MediaTek、Intel、瑞芯微、地平线和爱芯元智的开发者入口都会被迫从模型清单升级为可审计的部署目录；若不成立，AI Hub 仍会停留在试用和展示层，真实机器人与本地 Agent 项目继续围绕 Jetson、llama.cpp 或 OpenVINO 自建链路。这里的非共识点在于：模型目录的产业价值可能不由最大模型决定，而由最早能被客户重复下载、复测、对齐数值误差和切换 runtime 的中小模型决定。Qwen3-VL-8B 和 Qwen3-1.7B 未必立刻进入机器人主控，但它们会迫使端侧平台把多模态输入、LLM 预填充、量化 recipe 和运行时版本写得更清楚。
后续验证指标很具体：AI Hub 是否给 Qwen3-VL-8B、Qwen3-1.7B、Pi-0.5 和 GR00T-N1.5 输出同口径的设备、runtime、量化、上下文长度、延迟、峰值内存和数值误差；第三方是否在 Dragonwing 或 Snapdragon 设备上复现 GenieX/QAIRT/llama.cpp 路径；以及 legacy Genie 停更后，存量模型是否能低成本迁到 GenieX。若未来几周只看到模型上架而没有可下载资产、性能字段和迁移说明，这个判断应降级；若 CLI 能稳定查询并拉取这些字段，Qualcomm 的模型目录会更像工程选型表，而不是市场展示页。
软件 / 框架
- llama.cpp b10075：7 月 20 日发布 b10075，核心提交为 Hexagon backend 增加 CLAMP op，并继续发布 Android arm64、iOS XCFramework、Windows arm64 OpenCL Adreno、OpenVINO 2026.2.1、CUDA 12/13 等包。它的价值是补 Qualcomm/Hexagon 路径的算子覆盖，说明通用开源 runtime 仍在沿手机 SoC 的实际算子缺口推进；局限是该 release 没有给出端侧模型延迟或功耗变化，只能视为代码级候选信号。主来源
算法 / 论文
- Edge-cloud collaborative LLM inference：arXiv 2607.13093 v2 在 7 月 17 日更新，提出 endpoint-authenticated KV cache 的端云协同 LLM 推理，本地负责 embedding、cache 授权、speculative decoding 和低维 head，云端负责 decoder 与高维投影；论文称相对 split inference 每 token latency 最高降 46.1%、downlink payload 最高降 67.4%。这类方案提示本地 Agent 未必只能在“全本地”和“全云端”之间二选一，但证据仍是论文评测，不是开源 runtime。主来源
新项目雷达
- VinRobotics/vla.cpp：仓库 README 将其定义为基于 llama.cpp 的 Apache-2.0 C++ VLA 推理引擎，把 SmolVLA、pi0、BitVLA、Evo-1、GR00T N1.5/1.6/1.7 等策略封装为无需 Python/PyTorch 的 GGUF，目标覆盖 CPU、Apple Silicon、CUDA 与 Jetson 级设备。它值得进入观察池，因为它把机器人模型交付形式拉向单文件模型和 C++ server；但当前仍需独立任务复测、Jetson 持续负载数据和非 NVIDIA 后端结果。主来源
持续观察
模型目录的证据密度：接下来不要只看 AI Hub 是否继续上新模型，而要看
perf、numerics、runtime、量化和设备字段是否能被 CLI 稳定查询；如果这些字段对 VLM/VLA 仍不完整，模型目录很难真正影响 SoC 选型。相反，如果这些字段能被自动化脚本拉进回归测试，端侧芯片厂商的竞争会更快进入软件证据层。参考来源端云协同的可证伪点：2607.13093 的方向若要进入端侧 Agent，需要代码、端到端加密实现、弱网退化策略和小模型本地 head 的能耗数据；否则它更像隐私推理架构论文，而不是短期可部署的软件栈。参考来源
开源 VLA runtime 的横向测试：vla.cpp 下一步要看是否能把同一 GGUF 策略在 Jetson、桌面 CUDA、Apple Silicon 和至少一个手机 SoC 路径上给出一致的动作误差、控制频率和失败日志；否则“无 Python 部署”只能解决安装复杂度，不能解决机器人闭环可靠性，也难进入客户测试基线。参考来源
评论