AI DAILY / 2026-07-13
今天的重点是模型继续往设备本地和长任务里落：阶跃发布 Step Edge 端侧家族，Moondream 3.1 用 9B 总参数、2B 激活参数覆盖视觉问答、检测与分割。开发工具侧，Anthropic 延长 Fable 5 与 Claude Code 优惠，Codex 临时取消 5 小时限额；qMLX 和 llama.cpp 则分别修复长上下文缓存与 Agent 检查点问题。
阶跃星辰 7 月 12 日发布面向端侧部署的 Step Edge 模型家族，以“1+N”框架连接文本、视觉基础模型与 Audio、GUI、Gen 三类模块。 基础模型覆盖图像理解、GUI Grounding、工具调用、空间与视频理解；Audio 在本地处理音频理解与语音识别，官方给出的中文字错率约 3.1%、英文词错率约 3.6%；GUI 面向电脑和手机上的本地闭环操作。Gen 在 W8A16 设置下，文生图约需 3 秒，图像编辑约需 4.5 秒。 自研 Step Inference NPU 引擎的官方测试中，1024 token 文本输入约需 4.33 秒，768 分辨率图像理解约需 5.61 秒，30 秒音频输入约需 10.72 秒，预填充吞吐最高为 1395 token/s。官方同时注明，页面中的外部模型对比分数均为内部自测结果。
Moondream 官网将 3.1 列为当前推荐模型：总参数量 9B，采用稀疏 MoE 架构，每次推理激活 2B 参数。 模型面向视觉推理、目标检测、图像分割与长上下文图像问答，原生提供 query、caption、detect、point、segment 五类接口，检测、定位和分割等接口返回结构化结果。单张图像的 query 上下文支持到 32K token，当前不提供工具调用。 模型版本标识为 md-3.1-9b-a2b-r20260628，沿用 Moondream License。官方模型页将其谱系列为 moondream-2（1.9B）、moondream-3.0（9B MoE）到 moondream-3.1，并公开了接口约束、坐标格式与实例数量上限。 ---
Anthropic 帮助中心确认，Claude Fable 5 促销体验与 Claude Code 每周用量限额提升 50% 均延长至太平洋时间 7 月 19 日 23:59:59。 Pro、Max、Team 及符合条件的 Enterprise premium 席位可参与；促销期内，用户最多可将每周订阅限额的 50% 用于 Fable 5。触达该模型上限后，可以使用 usage credits 单独计费继续调用，也可以切换其他模型使用剩余额度。 活动不覆盖 Free、部分 Enterprise 席位和 API；API 仍按标准费率计费。Fable 5 在 Claude Code 中要求客户端版本为 2.1.170 或更高。活动结束后，Fable 5 不再计入订阅计划的每周额度，继续使用需启用 usage credits。
继 7 月 11 日重置用量后，Codex 负责人 Tibo 公布新一轮调整：Plus、Business、Pro 计划临时取消 5 小时使用限额，网页端与移动端新增储存重置功能。 该功能此前仅限桌面端。团队还在优化 GPT-5.6 Sol 的用量效率，具体变化将另行量化；达到 600 万活跃用户后，平台执行了一次即时用量重置。 一次约两小时的窗口内，不足 10% 尝试使用储存重置的用户没有成功。由于难以精确锁定所有受影响用户，团队向该窗口中所有点击过重置按钮的用户补发了一次机会。Tibo 还预告，达到 700 万活跃用户时，将首次向所有 ChatGPT Work 和 Codex 用户发放储存重置。 参考资料：https://x.com/thsottiaux/status/2076365965915467978 参考资料：https://x.com/thsottiaux/status/2076418567143408112
OpenAI Codex 工作人员 Eric Provencher 表示，GPT-5.6 系列使用新的默认扩展上下文窗口时，超过 272K token 不会因此对订阅用户按更高倍率计费。 这一回应针对社区流传的“超过 272K 后整次请求双倍计费”说法，适用范围是订阅场景和系统提供的默认扩展窗口，不应外推到 API 价格。 Provencher 同时区分了手动扩展场景：如果用户自行把上下文窗口扩大到默认范围之外，计费规则会不同，但这次回应没有给出该选项的具体费率。 参考资料：https://x.com/pvncher/status/2076014465489817708 ---
开发者 Andryo Marzuki 在 M3 Ultra Mac Studio 96GB 上修复 qMLX 的三处缓存问题后，将 Qwen3.5-122B 长上下文 Agent 续写的冷预填充从 3 至 5 分钟降至亚秒级。 三处问题分别是：系统提示中的唯一消息 ID 破坏 KV 缓存的字节匹配；生成被中断时流式回复未持久化，造成历史分叉；后台 writer 写出无法匹配的 checkpoint，挤掉有效缓存。 修复后的日志示例显示，54009 个 token 已命中缓存，仅需预填充 33 个 token。作者公开了 qMLX 分支和区分 prefill、decode 指标的 benchqmlx.py；这组结果来自作者单机环境，优化也针对 Qwen 的混合注意力架构。 代码：https://github.com/marzukia/qMLX
社区帖子称，llama.cpp b9978 修正了 Agent 工具循环中的上下文检查点淘汰逻辑。 旧行为会在每个 Agent 轮次创建 checkpoint，并绕过最小步长间隔，使密集检查点挤压上下文覆盖窗口；工具调用循环发生回退时，检查点可能被全部清空，随后触发完整上下文重处理。 新版本会淘汰先前任务中过于密集的检查点，保留覆盖范围更宽的集合。当前帖子没有附对应 GitHub 提交或前后吞吐数据，因此只能确认社区描述的行为变化，无法量化实际加速幅度。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1uuue5p/llamacppagenticworkflowsctxcheckpointsfix
一名社区用户在 Intel 285HX、64GB 内存与 Unraid 环境中测试 llama.cpp，Arrow Lake iGPU 的 SYCL 后端运行 Qwen3.6-35B-A3B 最高约 12 token/s，仍低于纯 CPU 的约 14 token/s。 Vulkan 后端在两种 Qwen 量化上只有约 0.5 token/s；SYCL 下 IQ4XS 与 BS-MTP 约 12 token/s，Q4KS 约 8 token/s；纯 CPU 的 Q4KS 与 IQ4XS 均约 14 token/s。 Gemma-4-26B-A4B 的结果同样没有显示 iGPU 优势：Vulkan 约 4 token/s，SYCL 与纯 CPU 均约 8 token/s。预填充阶段，纯 CPU 约 30 至 40 token/s；SYCL 约 20 token/s，但作者报告偶发长时间卡住。以上均为单一社区配置的测试，尚无独立复现。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1uur0ic/hasanyonegottenllamacpporotherworkingusing ---