锐Owl 雷达 · 2026-10-14：Gemini 4 Argon 全球放开｜Anthropic 自研 VCS Scion 迁出 git｜MiniCPM-V 4.7 上手机

本期覆盖 2026-10-13 18:00 → 2026-10-14 18:00（北京时间）。今天的看点可以压成一句：同一天里，两条「边缘算力」和两条「口径」各占一半。 Google 把 9-30 只发给受信网络防御方的 Gemini 4 Argon 在 10-13 全球放开，同一份评测页里逐条标出「哪个分数是自己跑的、哪个是引公开榜」（①）；Anthropic 公开了他们自研版本控制系统 Scion 的工程全记录——五个月、七个人，把 monorepo 从 git 迁走，因为合并量从每天 2,500 涨到 30,000+ 之后，为人类尺度设计的开发基础设施成了最大瓶颈（②）；面壁/OpenBMB 开源 MiniCPM-V 4.7，35B-A3B 的 MoE 在 iPhone 上占约 3GB 内存、解码 13+ tok/s（③）；一篇只有一页多正文的 arXiv 短文把「集成到底涨了多少」拆成了取决于你拿谁当对照（④）；Apple 则把「租不到卡」这个现实问题反过来做——把公司里闲置的 Apple Silicon 攒成一张虚拟 GPU 云，排队时间从 10 小时以上变成几分钟（⑤）。本期 5 条。

① Gemini 4 Argon 全球放开：9-30 只给受信防御方，10-13 全员可用；官方评测页逐条标出「谁跑的」（Google 2026-10-13）

先限量、后放开，是这次发布真正的动作。 Google 的 Gemini 4 旗舰 Gemini 4 Argon 2026-09-30 20:00 UTC 首次公布，当时只通过 Fairwind 计划发给受信网络防御方与美国政府评估方；2026-10-13 16:00 UTC（北京时间 10-14 00:00）发布《Gemini 4 Argon is now available for everyone》与开发者版公告，同日放出模型卡（Published 13 October 2026），全球放开：开发者在 Gemini API 付费层、AI Studio、Android Studio；企业在 Gemini for business 与 Antigravity；Google AI Ultra 订阅者在 Antigravity；Ultra 与 Pro 订阅者在 Gemini app 与 Search 里的 AI Mode。价格口径（官方原文）：入门价 $2 / 百万输入 token、$10 / 百万输出，缓存输入按输入的 95% 折扣。规格（模型卡原文）：规模化稀疏 MoE transformer，原生支持文本/图像/音频输入，「不是任何先前模型的修改或微调」；输入+输出合计上下文窗口最多 1M；训练用 TPU + JAX + ML Pathways。⚠️ 一个口径差值得记：官方博客写的是「把输出上限提到业界领先的 1M，此前是 64K」，而模型卡写的是「输入+输出合计最多 1M」——两处表述并不等价，模型卡未单列最大输出，本条只写模型卡口径。官方给的内部用例：Argon agents 分析全舰队 profiling 遥测、在数据中心自动识别并套用内存优化，已释放 300+ TiB 内存，预计累计 500 TiB–1 PiB；C/C++ → Rust 迁移从 re2、libgav1 的几万行做到 Fuchsia Zircon 内核 800K+ 行；其中 libgav1 用 32K 行 SIMD 换成安全 Rust（让编译器自动向量化），比既有 Rust 移植快 2.7 倍、视频输出一致；量子子程序的时空开销比公开基线好 40%；Chrome 团队把约 600 万行遗留浏览器特性目录从 4,000 万行代码库里拆出；Google ADK 团队给一段话的目标 + .agents/skills 规则本，跑一晚上拿到上游 PR，长会话内存准备时间 −40%、冷 import −21%；Gemma 4 E2B 在单张 A100 上经 vLLM 端到端 2.85×（约 37,900 → 108,000+ tok/s，token 完全一致）。评测页（deepmind.google/models/evals-methodology/gemini-4-argon，5 页 PDF）给的是方法学：Argon 分数全部 pass@1、最高 thinking 设置；非 Gemini 模型「除非另有说明，取自各家自报数字」；逐项标注自算还是引榜——自算的有 DeepSWE v1.1（77.9%，用 mini-swe-agent harness）、Terminal-Bench 4.0、PostTrainBench v1.1（全模型都由 Google 自算，OpenCode harness + 单张 H100 + 10 小时预算）、OSWorld 2.0（自算，3 次取最大、报离线子集）、GraphWalks、LVBench、Agent's Last Exam；引公开榜的有 Vals Index（第一）、AutomationBench（51.3%，Zapier 榜第一）、Harvey 法律 Agent 榜（19.6%）、Vibe Code Bench、FrontierSWE、RiemannBench、Chartography、CWE-bench v1（68%，并列第一）。同日另发 Gemini 4 Argon for Robotics（开发博客，Oct 13）：在物理与空间推理的 ERQA 上「纯推理」拿到 87%。

认知价值：① 今天最值得记的不是名次，是「放开方式」。 9-30 先给受信网络防御方、10-13 再全球放开 —— 而且官方明说对受信防御方「不带网络护栏」发布、对大众则分阶段。把它和 10-13 ②（Meta 在 Muse Wonder 模型卡里主动写「未缓解时不能排除化生域达到 high 风险」）并排看：前沿实验室正在把「谁先用、用什么强度用」当成能力发布的一部分，这比任何一个榜位都更有信息量。② 「1M」的实际口径请记一笔。 博客口径是「输出上限 1M（原 64K）」，模型卡口径是「输入+输出合计 1M」。对做长程 agent 的人，这决定了「一次能不能吐完」这个硬约束。这是我们「分数/口径要看」线的又一次实例（10-08 ⑤ PaperBenchX、10-09 ③ DeepSeek 相位敏感性、10-12 ① 满分看动作数与 token、10-13 ② 92→21、10-13 ④ 上游指标涨下游零变化）——同一条读法在厂商文档内部就能用上。③ 那一页评测方法学可以直接当模板抄。 「哪些分数是自己跑的、哪些是引榜、对手模型用的是不是最高 thinking」逐条写明，还主动声明对手模型结果多为自报。这正是我们做横评的纪律（同脚本、标来源、区分自跑与转引），也是「模型卡能不能当证据」的前提。④ 内部用例里最该抄的是 libgav1 那条。 它换掉 32K 行手写 SIMD、改用安全 Rust 让编译器自动向量化，结果比既有 Rust 移植快 2.7 倍 —— 说明这类任务的瓶颈常常不在「模型够不够聪明」，而在「能不能让编译器替你干活」；ADK 那条同理：给规则本 + 一个可验证的目标，一个晚上出上游 PR。这与 10-12 ②（dsh 插件生态）、10-13 ①③（harness 与进程模型）是同一族的第三个数据点。⑤ 读法纪律： 发布事实、模型卡、评测方法学都是我们直读的一手（🟢）；但所有能力数字都是 Google 自算或自报，本轮未见第三方独立复跑，故整条按 🟡 记。

领域：industry-model ｜ 去向：related（挂钩「前沿模型分阶段放开 + 评测口径」线：10-12 ② Meta 模型卡与 Personal Agent、10-13 ② 化生风险声明、10-13 ④ 效率被评审吸收；喂养「模型卡 / 评测页该怎么读」选题）｜ 等级：🟡

来源：🟢 一手已核（10-14 直读官方页面）https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/ （datePublished 2026-09-30T20:00:00Z，首发口径：Fairwind 受信防御方、1M 输出上限 vs 此前 64K、$2/$10 入门价、缓存输入 95% 折扣、300 TiB / 500 TiB–1 PiB、Zircon 800K+ 行、libgav1 32K 行 SIMD 与 2.7×、Chrome 600 万行 / 4,000 万行、ADK −40%/−21%、Gemma 4 E2B 37,900→108,000+ tok/s 2.85×、DeepSWE 77.9%、Vals Index 第一、AutomationBench 51.3%、LVBench 91.7%、CWE-bench v1 68% 并列第一）｜🟢 一手已核 https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-argon/ （datePublished 2026-10-13T16:00:00Z，原句「Gemini 4 Argon is now globally available today for developers and enterprises via the API in AI Studio and Gemini platform, for Google AI Ultra subscribers in Google Antigravity, and Google AI Ultra and Pro subscribers in the Gemini app and AI Mode in Search」）｜🟢 一手已核 https://blog.google/innovation-and-ai/technology/developers-tools/build-with-gemini-4-argon/ （同日 2026-10-13T16:00:00Z，开发者版）｜🟢 一手已核模型卡 https://deepmind.google/models/model-cards/gemini-4-argon/ （Published 13 October 2026；规模稀疏 MoE、原生多模态、输入+输出合计最多 1M、TPU/JAX/ML Pathways、「not a modification or a fine-tune of a prior model」、分发渠道六项）｜🟢 一手已核评测方法学 https://deepmind.google/models/evals-methodology/gemini-4-argon/ （PDF 5 页，直读全文；逐项自算/引榜标注、非 Gemini 模型取自报数字与最高 thinking、PostTrainBench 全部自算且单张 H100 10 小时预算、OSWorld 2.0 自算 3 次取最大）｜🟢 一手已核机器人专文 https://developers.googleblog.com/gemini-4-argon-for-robotics/ （OCT. 13, 2026，ERQA 87%）｜🟢 HN Algolia（本期讨论 1308 分 / 911 评论 / 2026-10-13T16:03Z；首发时 1705 分 / 1194 评论 / 2026-09-30T20:04Z；Robotics 专文 217 分 / 50 评论 / 10-13T16:55Z）｜⚠️ 本轮 web_search 命中的多个「Gemini 4 Argon 榜单汇总」站点含明显编造数据（如把 LMSYS Elo、SWE-bench Verified 74.2% 等拼成 9 月「未发布 checkpoint」口径），一条未采用；本条数字全部取自上述官方页面

② Anthropic 自研版本控制系统 Scion：合并量从每天 2,500 涨到 30,000+ 之后，他们用七个人五个月把 monorepo 从 git 迁走（Anthropic Engineering 2026-10-13）

「代码不是瓶颈，为人类尺度造的开发基础设施才是。」 Anthropic 工程博客 2026-10-13 发布《Redesigning source control at Anthropic》，公开了自研 VCS Scion 的完整实现与迁移。触发条件是可核的：2026 年 5 月平均每天约 2,500 次代码合并，到 9 月已超过 30,000 次/天（官方原话：把瓶颈一个个拿掉之后，合并量的隐性需求「几乎无限」）。git 在这个量级上失效的具体数字：主分支历史接近 100 GB、压缩后的工作副本超过 25 GB；为 CI 每天执行约 2,500 万次代码 checkout，不计数开发者环境、agent 沙箱与研究任务——朴素拉取相当于每天 600 PB 以上的 git 流量；他们已用上 shallow clone、sparse checkout、promisor remote、内部镜像与快照，峰值时运维着几百个内部 git 镜像。设计原则（官方归纳）：客户端永远在线（绝大多数客户端是 agent 和任务）、客户端-服务端不对称（服务端回答历史/blame、创建提交、做 merge 与 rebase；客户端只保一个有界本地对象缓存）、一切水平可扩（任意组件独立扩缩，服务端也没有完整物化副本，没有 packfile、不需要仓库维护）、提交必须便宜、增量、无锁（每次提交/合并都在服务端完成，因此没有 push；成本必须随改动大小而非仓库大小增长），并且刻意少用 refs（除主 ref 与发布分支）。技术实现：工作单元是写前日志里的 changeset（存相对第一父的变更文件列表 + 内容寻址的压缩 blob 指针）；blame / 路径历史 / 提交图跳跃表都作为**「派生数据」由同一套递归机制算出（可按需延迟计算、可新增类型而不改客户端）；服务端是三层缓存**（scion-daemon 节点级 → scion-cache 区域级，直接从内存按客户端要消费的磁盘格式流式输出 → scion-server 权威层读 Spanner / 云存储），每层缓存命中率 >99%、无需长驻状态；子任务领取靠 PostgreSQL 唯一约束做原子获取（(team, project, task_name, subtask_id)），没有中央调度器。迁移与收益（官方口径）：七个人同时做出 Scion + 代码评审工具 Antique 以及另外半打相关系统，并在五个月内完成完整迁移，期间日均合并量还涨了 10 倍；基础设施占用比以前那套 git 镜像方案小 200 倍（CPU + 内存），CI 与研究任务的 checkout 快了约两个数量级（分钟 → 秒），仅 CI 就回收了 25% 的 CPU 容量。两个细节值得单独记：今年早些时候他们手写的 git→Scion 摄入管线原型，交给内部早期版本的 Claude Mythos Preview「重写一遍、不给任何额外指令」，得到内存少 20 倍、快 4 倍的版本且保持了摄入顺序等隐式不变量；以及团队自陈所有参与这个系统的工程师现在都会承认 Claude 写代码比他们强，工程师的价值在「高层系统理解与设计取舍」——而且最常见的角色是告诉 Claude「不行」（例：有系统为了满足一个本不该被允许的模式，线性读提交日志去查一个变更何时合入，而不去问评审工具；又例如对抗式评审在假设性担忧上驱使 Claude 过度校验、堆复杂度）。运维上他们给每个组件配了「superfan」——一个只盯单个组件健康、能读遥测与日志的 Claude。对社区的建议是别照搬：Scion 只对「真有巨型 monorepo + 上万工程师或大量 agent」的场景成立，且 Anthropic 自己愿意花的内部 token 预算远超任何普通公司；他们建议把其中可迁移的部分（服务端 RPC、不同于客户端的服务端架构、协商协议）反馈给 git 生态。

认知价值：① 这是「效率是衡量标准」在基础设施层的第一次完整实证：瓶颈不是被推倒的，是被量出来的。 100 GB 历史 / 25 GB 工作副本 / 每天 2,500 万次 checkout / 600 PB 日流量 / 几百个镜像 —— 每一个数字都在说明git 的「每个克隆都是完整自洽的离线仓库」这个优秀设计，在有大量长在线 agent 客户端时变成了成本。如果你在自己团队里听到「agent 让代码变多了但交付没变快」（10-13 ④ 那条），这里就是那个瓶颈的下游剖面。② 对我们的评测线有一个直接可用的判据：不要看「生成速度」，要看「客户端还需要维护多少本地状态」。 Scion 的收益全部来自把状态搬回服务端（可选且稀疏的工作副本、虚拟化 checkout、无 packfile、无仓库维护）。同理，评估 agent 工具链时，谁持有后台进程、谁决定更新、后端跑的是不是你装的那个二进制（10-13 ③ Codex 守护进程那条）是同一族问题。③ 「七个人五个月 + 每天合并量涨 10 倍」这个组合，本身就是 agent 时代工程组织的样本。 官方给的限定条件也很诚实：他们愿意花的 token 预算「远超任何普通公司愿意花的量」，而且这件事同时是内部产品需求与 Claude 能力测试。读的时候要留意这个双重身份。④ 最值得抄的其实是那句「工程师的工作变成了说不行」。 附的三个例子（线性读日志的暴力查询、对抗式评审导致的过度防御、过度校验与复杂度）都是可以当 agent 工作流反模式清单用的具体形态——比任何「AI 提升生产力 X%」都更可操作。⑤ 读法纪律： 全文是 Anthropic 自述的自家基础设施与自家收益，我们直读了原文（🟢 指一手已核、非第三方复跑）；所有收益数字（200× 占用缩小、两个数量级、25% CPU、20×/4× 重写）都是厂商自报，且 Scion 不对公众发布、无法被外部复现或对照。

领域：agent-frameworks ｜ 去向：feeds（喂养「agent 规模化以后，瓶颈转移到哪一层」选题：与 10-13 ③ Codex 守护进程的进程模型、10-13 ④ 效率被评审吸收、10-12 ② dsh 插件生态合成一条「agent 时代的基础设施重估」主线）｜ 等级：🟢

来源：🟢 一手已核（10-14 直读官方全文 HTML，161,623 B）https://www.anthropic.com/engineering/redesigning-source-control 《Redesigning source control at Anthropic》Published Oct 13, 2026（原文含：5 月约 2,500 次合并/天 → 9 月 30,000+/天、主分支历史近 100 GB、压缩工作副本超 25 GB、CI 每天约 2,500 万次 checkout、朴素拉取 600 PB+/天、峰值几百个内部 git 镜像、四条设计原则、changeset 与派生数据、scion-daemon / scion-cache / scion-server 三层、每层缓存命中率 >99%、基础设施占用较原 git 镜像方案小 200×、checkout 快两个数量级、CI 回收 25% CPU、七人五个月同时交付 Scion 与 Antique、Claude Mythos Preview 重写摄入管线内存 −20× 速度 4×、工程师角色=说「不行」、superfan、以及「Scion is by no means a suitable replacement for git for general use」）｜🟢 HN Algolia（774 分 / 781 评论 / 2026-10-13T15:49Z）｜⚠️ 供参考的第三方解读（本轮未逐条引用）：Latent Space 的当日 AI News 汇总

③ 面壁 / OpenBMB 开源 MiniCPM-V 4.7：35B-A3B 的 MoE 只占约 3GB 内存，在 iPhone 17 Pro Max 上解码 13+ tok/s（2026-10-12 发布）

MoE 上手机的真问题，从来不是「总参数装不下」，而是「每一个 token 要临时去闪存里取哪几个专家」。 面壁智能与 OpenBMB 开源 MiniCPM-V 4.7，两个规格：35B-A3B（总参数 35B、每 token 约激活 3B，MiniCPM-V 系列第一个 MoE 模型）与 1B（1.3B 参数，主打极小体积）。官方模型卡（Hugging Face openbmb/MiniCPM-V-4.7-35B-A3B，Apache-2.0）写明的核心口径：「首个能在端侧流畅运行、同时不牺牲性能的开源 MoE 模型」，在 iPhone 17 Pro Max 上以约 3GB 内存实现 13+ tokens/s 解码。三个技术手段（官方模型卡逐条列出）：① Lookahead Expert Scheduling（LES，前瞻专家调度）——利用相邻层输入特征高度相似的特点，在当前层还在算的时候把它的路由输入送进下一层路由器预测可能用到的专家，由后台线程提前把权重从闪存读进内存；官方强调预测只用于预取和调度排序，最终每个 token 用哪些专家仍由模型原有路由决定，没猜中的专家照常加载照常计算（即不牺牲能力换速度），配套代码在 OpenBMB/llama.cpp-omni；② 细粒度逐层混合精度量化——压下专家权重的存储占用与内存流量，并重排成连续布局以减少零散读取；③ DSpark 草稿模型投机采样——接到端侧推理链路里进一步提速。架构上沿用 LLaVA-UHD v4 的 ViT 内早期视觉压缩，支持 4×/16× 视觉 token 混合压缩，开发者可按任务在细节与成本之间取舍。生态：支持 iOS / Android / 鸿蒙，发布当天完成 瑞芯微、后摩、Intel、AMD、Arm 的适配；推理侧支持 SGLang / vLLM / llama.cpp / Ollama，微调侧 SWIFT / LLaMA-Factory，量化版有 GGUF、BNB、AWQ、GPTQ 与新增 FP8。同时发布微调方法 Self-Replay Fine-Tuning（SRFT）：在微调前先让模型回答一批覆盖原有能力的问题、筛出高质量回答混进新任务训练数据，用模型自己的「复习材料」减少灾难性遗忘，沿用标准微调流程、不改结构也不改损失。⚠️ 日期口径：官方 README 记「2026-10-12 · MiniCPM-V 4.7 released」，而 Hugging Face 仓库创建时间是 10-06（1B）/ 10-07（35B-A3B）；中文与英文媒体在 10-14 集中报道（量子位 10-14 04:55、Pandaily 10-14）。本条按 README 记 2026-10-12 发布，媒体波次记 10-14。厂商自测的对比数字（经由量子位读模型卡图表，本轮未逐张核对原图）：35B-A3B 在 OmniDocBench v1.6 拿到 94.24（文中称领先榜内其余四个模型 12 分以上）、MMBench 91.72、MMStar 80.67、MMMU 80.22、MathVista 88.00、Video-MME 76.40、LongVideoBench 68.90；纯文本侧 CMMLU 90.21、工具调用 τ²-Bench 84.65；16 倍视觉压缩后 MMBench 由 91.72 降到 90.87、OCRBench 由 91.20 降到 90.40（即用算力换精度的代价很小）。量化生态侧可独立观察：HF 上 35B-A3B 主仓 4,157 下载 / 525 赞，GGUF 版 46,970 下载 / 101 赞，已有 mlx-community 的 mxfp4 版与若干社区微调版（10-12～10-13 出现）。背景数字（IDC，媒体口径）：2026 年中国新一代 AI 手机出货量预计 1.47 亿台、同比 +31.6%，渗透率首次突破 53%。

认知价值：① 这条把端侧 MoE 的真瓶颈说清楚了：不是容量，是「每 token 的专家取数」。 两种旧办法各有代价——用到哪个读哪个（能跑，但慢到没法实时对话）或给整段对话固定一小组专家（读盘少了，但模型能选的专家也少了、能力打折）。LES 的取巧之处是只把预测用于预取，不改变最终路由——所以它换来的是速度而不是「用能力换的速度」。这是今天最值得记的一句工程判断：任何用「预测」加速的方案，都必须能说清预测错误时会发生什么。② 「3GB 内存」这个数字的分量要看对照物。 iPhone 17 Pro Max 是 12GB 内存，官方口径是约 3GB 就能流畅跑 35B-A3B —— 也就是同一个 35B 级模型，过去的门槛是「一张卡」，现在是「一台手机的零头」。这和 10-13 ⑤（Janas 用磁盘流式把 48GB 的 Qwen3-Next-80B 跑在 32GB 笔记本上）是同一条线，但走的是另一条路：那里是 SSD 流式，这里是闪存 + 专家预取 + 量化 + 投机采样。两条路都指向同一件事：「跑得动」与「跑得快」已经分开了，评价本地推理要按「预填充快 / 长生成快」分开看。 ③ 对我们做本地/云对照评测最有用的是它自带完整对照臂。 同一份模型卡同时给了架构（MoE + 4×/16× 压缩）、量化版本（GGUF/AWQ/GPTQ/FP8/int4）、推理框架（SGLang/vLLM/llama.cpp/Ollama）与投机采样草稿模型（DSpark）——这是少见的能在一台机器上做单变量对照的端侧模型。若要做「同一模型、换压缩倍率/换框架/换量化」的四组对照，这是现成素材。④ 读法纪律： 模型规格、许可证、技术手段、平台适配、SRFT 都是我们直读官方模型卡的一手（🟢）；但13+ tok/s、3GB 内存与全部评测分数都是厂商自测，且部分分数本轮只经量子位对模型卡图表的转读、未逐张核对原图 → 整条按 🟡 记。另需注意官方那句「首个能端侧流畅运行且不牺牲性能的开源 MoE」是自家表述，「不牺牲性能」的判据（对比哪个基线、什么硬件）未在模型卡里给出可复算的口径。

领域：inference-efficiency ｜ 去向：feeds（喂养本地/边缘推理横评：与 10-13 ⑤ Janas 的 SSD 流式路线并列为两条对照臂；量化/压缩倍率/框架/投机采样四组单变量对照可直接落进 cloud-gpu-benchmark 的评测设计）｜ 等级：🟡

来源：🟢 一手已核（10-14 直读 Hugging Face 模型卡经 hf-mirror）https://hf-mirror.com/openbmb/MiniCPM-V-4.7-35B-A3B/raw/main/README.md （Apache-2.0；「first open-source MoE model to run smoothly on-device without compromising performance」；「13+ tokens/s with just 3 GB of memory on iPhone 17 Pro Max」；LES 三条机制与「预测只用于预取、最终路由不变」；细粒度逐层量化；DSpark 投机采样；LLaVA-UHD v4 的 ViT 内早期压缩与 4×/16× 混合压缩；iOS/Android/鸿蒙 + 瑞芯微/后摩/Intel/AMD/Arm day-0；SGLang/vLLM/llama.cpp/Ollama + SWIFT/LLaMA-Factory；GGUF/BNB/AWQ/GPTQ/FP8；SRFT）｜🟢 一手已核 HF 镜像 API 检索（MiniCPM-V-4.7-35B-A3B downloads 4,157 / likes 525、createdAt 2026-10-07T07:07:30Z；-1B 2,543/315、createdAt 2026-10-06T17:40:13Z；-35B-A3B-gguf 46,970/101；mlx-community/MiniCPM-V-4.7-35B-A3B-mxfp4 createdAt 2026-10-13T09:50Z）｜🟢 一手已核 GitHub https://api.github.com/repos/OpenBMB/MiniCPM-V （26,722★ / 2,092 fork / Apache-2.0 / pushed 2026-10-14T07:18Z）＋ README contents API（SHA b4352ad5ce79，原句「2026-10-12 · MiniCPM-V 4.7 released — the first open-source MoE model to run smoothly on-device without compromising performance」）｜🟡 媒体口径（10-14）：量子位《iPhone断网跑35B多模态！国产开源新模型，只占3G内存》2026-10-14 04:55 https://www.qbitai.com/2026/10/503109.html （含 OmniDocBench v1.6 94.24、MMBench 91.72、MMStar 80.67、MMMU 80.22、MathVista 88.00、Video-MME 76.40、LongVideoBench 68.90、CMMLU 90.21、τ²-Bench 84.65、16× 压缩后 90.87/90.40、IDC 1.47 亿台 +31.6% / 渗透率 53%、MiniCPM 系列累计下载超 5,000 万次）；Pandaily《ModelBest Open-Sources MiniCPM-V 4.7…Running in 3GB on a Phone》2026-10-14 https://pandaily.com/modelbest-minicpm-v-4-7-open-source-35b-a3b-moe-3gb-iphone-on-device ｜⚠️ 上述评测数字的原始出处是模型卡内的图表（图片），本轮未逐张核对原图，按 🟡 记

④ 一篇 arXiv 短文把「集成到底涨了多少」拆开了：同一个集成，换个对照就可能反号（arXiv 2610.18786，2026-10-13）

「多生成几个候选再聚合」这件事的红利，可能有一半来自你在跟什么比。 作者 Donghwan Kim 在 2026-10-13 提交的 arXiv 短文《Where Do LLM Ensemble Gains Come From? Decomposing Candidate Value, Diversity, and Aggregation》，把 LLM 集成的收益拆成四个匹配对照条件：Direct（不给候选）、Single-slot（多槽界面里只放一个候选）、Duplicate（同一个候选重复放两个槽）、Multi-candidate（分别独立生成的多个候选）。结论是代数性的：在任一种「非多样」对照下，总体候选增益（CIV）都可以拆成**「多加一个候选」的对比（DSV）与「候选上下文」的对比（CCV）；这个拆分本身不依赖对照选谁，但 CIV 的数值依赖。实测数字：在 MultiHopRAG 的模型多样性设置（k=2）下，重复缺口 Rep = −8.33 个百分点 [−13.25, −3.75]，量化的是「以 Duplicate 为对照」与「以 Single-slot 为对照」测出的增益之差；在一个匹配的 FRAMES 更强面板扩展**（n=200、k=3、聚合器输出上限 4096）上，配对的 ΔRep = +9.67 pp [+6.00, +13.50]，且面板内部 Rep 会变号（原面板 −6.33、更强面板 +3.33）。在 FRAMES 的证据聚合任务里，两种非多样对照下**「候选上下文」对比都保持强负**。作者的主张很克制：集成评测在把增益归给「更多候选」之前，必须说明用的是哪个参照对照。

认知价值：① 这是我们「平均分/口径」线里最干净的一次结构性证明：不是「分数被平均掩盖」，而是「增益本身随对照定义改变符号」。 从 10-08 ⑤ PaperBenchX（严格判据下真实水平）、10-09 ③（同一模型对提示词相位敏感）、10-12 ①（满分要看动作数与 token 数）、10-13 ②（ExploitGym 92 个 flag 里只有 21 个是预期漏洞）、10-13 ④（上游指标涨、下游零变化）到今天的 ④ —— 已经是连续第六期同一条读法，而且这一篇把它变成了可代数拆解的定理形式：CIV 依赖对照，拆分不依赖对照。对任何写「A + B 组合比单模型提升 X%」的人，这句话意味着 X% 必须附上「比的是哪个基线」。② 更要紧的是那个「符号会翻」的细节。 同一个指标的 Rep 从 −6.33 翻到 +3.33（原面板 → 更强面板）——也就是说，换了更强的对照面板，原来「重复候选有害」的结论可以变成「有益」。这和我们做横评时坚持「统一底层模型、同日同协议」是同一条理由的反面：只要对照一变，结论的方向都可能变，所以对照必须在跑之前就冻结。③ 方法论上可直接抄两点：「重复槽位」（Duplicate）这个对照设计得非常实用 —— 它把「多一个槽位带来的界面效应」和「多一个候选带来的信息效应」分开了，做我们自己的聚合/评审流程 A/B 时可以直接借用；以及配对差分 + 置信区间（不是只报一个百分点的差）。④ 读法纪律： 摘要与数字来自我们直读的 arXiv 页面（🟢）；但这是单作者预印本、未经同行评议，且篇幅短、实验面窄（主要落在 MultiHopRAG 与 FRAMES 两个数据集上），结论的普适性由作者自己加限定在「声明参照对照」这一条可操作主张上 —— 我们引用的也是这一条，而不是「集成没用」。

领域：eval-evidence ｜ 去向：feeds（喂养「评测判据怎么选」主线与 cloud-gpu-benchmark 的对照设计：把「前置于跑批的对照冻结」写成流程条目；与 10-08 ⑤ / 10-09 ③ / 10-12 ① / 10-13 ② / 10-13 ④ 合成「口径」系列）｜ 等级：🟢

来源：🟢 一手已核（10-14 直读 arXiv 摘要页）https://arxiv.org/abs/2610.18786 《Where Do LLM Ensemble Gains Come From? Decomposing Candidate Value, Diversity, and Aggregation》Donghwan Kim，Submitted on 13 Oct 2026（原文含：Direct / Single-slot / Duplicate / Multi-candidate 四条件；在两种非多样对照下 CIV 代数拆为 DSV 与 CCV，拆分不依赖对照而 CIV 依赖；MultiHopRAG k=2 上 Rep = −8.33 pp [−13.25, −3.75]；FRAMES 更强面板 n=200 / k=3 / 聚合器输出上限 4096 上 ΔRep = +9.67 pp [+6.00, +13.50]；面板内 Rep 变号，原面板 −6.33、更强面板 +3.33；FRAMES 证据聚合中候选上下文对比在两种非多样对照下均强负）｜⚠️ 单作者预印本、未经同行评议、实验面窄（MultiHopRAG + FRAMES）

⑤ Apple 把「闲置的 Apple Silicon」攒成一张虚拟 GPU 云：排队时间从 10 小时以上变成几分钟，新增购卡为零（Apple ML Research 论文，arXiv 2026-10-09）

「GPU 不够」这个问题的另一半是「GPU 被浪费」。 Apple 机器学习研究团队（Jianhua Li、Yun Xing、Girisha De Silva、Ryan Flint、Kai Yuan、Sean Suchter）在 2026-10-09 提交的短文《Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices》（arXiv:2610.12970v1 [cs.DC]，3 页、1 图、1 表）提出 Minions：一个动态、分布式的「虚拟 GPU 云」，把 macOS 设备上闲置的 Apple Silicon GPU 聚起来跑推理。出发点写得很直白：集中式 GPU 集群贵、弹性差、资源紧张时排队久；而大量 Apple Silicon 的 macOS 设备主要跑交互负载，GPU 长时间空闲。系统四个组件：Minion Server（统一入口，做参数校验并把任务异步切成子任务）、PostgreSQL 元数据存储（七张表，记录任务与执行器状态；执行器从不直连数据库，只走 REST API）、Minion Executor（跑在 macOS 设备上，拉取式领子任务；嵌入生成用 HuggingFace transformers，LLM 补全用 Ollama；结果写 S3；每 5 分钟发心跳）、Minion Watchdog（只跟踪正在跑子任务的执行器的心跳，设备断网/休眠/关机/被用户主动占用时把子任务放回队列重派，无需人工干预）。两个设计细节值得抄：原子领取用 PostgreSQL 在 (team, project, task_name, subtask_id) 上的唯一约束实现——多个执行器竞争时恰好一个插入成功，因此不需要中央调度器；动态任务绑定允许设备所有者给自己的执行器配「优先做哪个团队/项目的哪个任务」的偏好，没有偏好任务时回落到全局队列。效果（论文 Table 1，官方口径）：GPU 排队时间 从「小时（最长达 10 小时以上）」→「分钟」；新增 GPU 采购需求 从「必需」→「无」；基础设施成本 从「高」→「零」；扩展方式 从「手动」→「有机（organic）」。论文也写了落地的真实摩擦：团队常常靠 Slack 互相喊人来临时开执行器；「在别人组织的设备上跑自己的负载」的数据保密顾虑会实际压低参与率，缓解办法是团队/组织级的独立 PostgreSQL 与隔离执行器池。展望部分提到下一步会扩展到分布式模型训练，并设想「如果机构之间（甚至全球）的闲置 macOS 设备能被安全联邦起来，会形成一张巨大的共享 GPU 池」。

认知价值：① 它把「租不到卡」翻译成了一个可量化的资源错配问题，而且给的解法是组织性的、不是硬件性的。 排队 10 小时以上 → 分钟、采购需求 → 零、成本 → 零，这四行不是性能提升，而是把一个成本项变成了一条调度策略。对照 10-12 ③（算力从成本项变成配额）和 10-13 ⑤（32GB 笔记本跑 48GB 模型）——今天这一条是那条线的第三种形态：不是让单机更强，也不是让模型更小，而是把已经买过的机器重新编排。 ② 对我们的本地/云对照评测线，这是「对照臂」意义上的重要档案。 论文里的执行器是通用件（HuggingFace transformers 做嵌入、Ollama 做生成、S3 做 I/O）——我们手上的 M4 / M5 机器正好落在这个区间，也就是说 Minions 描述的架构可以用现成开源件复现（论文给了组件划分、原子领取的 SQL 约束写法、Watchdog 的心跳语义，甚至「拉取式 + 无中央调度器」这条选择），这是一条比「再租一张 4090」更值得先试的路。③ 三页短文里最该记的其实是那句摩擦：数据保密顾虑会压低参与率。 一个纯技术的分布式算力方案，最终被信任边界限住了天花板——这也是它把「团队/组织级独立库 + 隔离执行器池」列为标配的原因。任何要跨设备/跨团队调度算力的方案都会撞到这堵墙，早一点把它当设计约束而不是运维问题，能省很多返工。④ 读法纪律： 论文本身、组件设计、数据库约束写法都是我们直读原文的一手（🟢）；但Table 1 的四行收益是 Apple 的自家观察值、且是定性档位（「小时→分钟」「必需→无」），没有吞吐/并发/设备数的硬数字，也未给出能被外部复现的规模参数 → 整条按 🟡 记。另需注意这是短文（3 页）、非完整系统论文，评估面窄。⑤ 一个诚实的对照： 本轮同类还有一条更「实」的端侧数据点（haku.sh 把 EmbeddingGemma 2 改造成语音转写：base M3 MacBook Air 上 1 小时音频 12.6 秒、约 288× 实时、WER 约 5% vs 领先语音模型 2–3%）——因两条同属「端侧算力复用」且本期已有 ③④ 占位，该条转入待命素材，理由见文末未采用清单。

领域：inference-efficiency ｜ 去向：related（挂钩云 GPU 横评线：与 10-12 ③ 算力配额、10-13 ⑤ Janas、本期 ③ 端侧 MoE 构成「被低估的边缘算力池」四联；喂养「不租卡能不能干活」选题，可进 cloud-gpu-benchmark 做一次复现）｜ 等级：🟡

来源：🟢 一手已核（10-14 直读 arXiv 论文 PDF 全文，1,614,434 B，3 页）https://arxiv.org/abs/2610.12970 《Minions: A Dynamic and Distributed Virtual GPU Cloud Built on Idle Apple Silicon Devices》Jianhua Li, Yun Xing, Girisha De Silva, Ryan Flint, Kai Yuan, Sean Suchter（Apple），arXiv:2610.12970v1 [cs.DC] 9 Oct 2026（原文含：Minion Server / PostgreSQL 元数据存储 / Minion Executor / Minion Watchdog 四组件；异步切分 + 拉取式 + 无中央调度器；minion_subtask_acquirement 表在 (team, project, task_name, subtask_id) 上的唯一约束实现原子获取；HuggingFace transformers 做嵌入、Ollama 做 LLM 补全、AWS S3 做 I/O、5 分钟心跳；动态任务绑定与回落全局队列；Table 1：GPU 排队时间 Hours(10+)→Minutes、新增 GPU 请求 Required→None、基础设施成本 High→Zero、扩展方式 Manual→Organic；团队/组织级独立库与隔离执行器池缓解保密顾虑；未来扩展到分布式训练与跨机构联邦）｜🟢 一手已核官方研究页 https://machinelearning.apple.com/research/distributed-gpu-cloud （标题与作者一致，published October 2026，摘要同 PDF）｜🟢 HN Algolia（246 分 / 97 评论 / 2026-10-13T12:26Z）｜⚪ 转入待命的同类条目（非本条一手）：Embedding Gemma Transcribe https://eg2.haku.sh/ （1 小时音频 12.6 秒 on base M3 MacBook Air 8GB、288× 实时、WER 约 5%、只训 reader 且 <2 小时 8×H100、底座 EmbeddingGemma 2 为 Apache-2.0、独立项目非 Google 官方）