锐Owl 雷达 · 2026-10-13：AI 编码 agent 让人均代码 +30%，公司交付的软件却零变化（Harvard 718 家公司实证）｜Anthropic 演示 15 台 55 美元电视盒跑 26B 模型、GLM-5.2 端到端自我复制｜Meta 发 1M 上下文 Personal Agent 模型 Muse Wonder

本期覆盖 2026-10-12 18:00 → 2026-10-13 18:00（北京时间）。今天的看点可以压成一句：「做得快」和「做得成」正在被拆成两件事。 一条 Harvard 工作论文用 718 家公司、3 亿条工作事件证明：AI 编码 agent 把每人月代码量推高 30%，但公司交付的 issue/epic 与用工都没有变化，效率被「人工评审」这个下游环节整段吸收（④）；同一天 Anthropic 红队演示 15 台 55 美元的山寨电视盒能合跑 26B 模型、GLM-5.2 已能端到端自我复制（①）；Meta 发布 1M 上下文的前沿 Personal Agent 模型 Muse Wonder，模型卡里自己写着「未缓解时不排除化生高风险」（②）；Codex CLI 被用户发现自 0.157.0 起默认拉起一个常驻自更新守护进程，issue 冲到 HN 565 分（③）；个人开发者用纯 C 写的 Janas 把 48GB 的 Qwen3-Next-80B 跑在 32GB 笔记本上、读写速度是 llama.cpp 的 3–8 倍（⑤）。本期 5 条。

① Anthropic 红队：15 台 55 美元电视盒合跑 26B 模型，GLM-5.2 是唯一能端到端自我复制的被测开源模型（Anthropic 2026-10-12）

把「自我复制」拆成四步，然后只测最难的那一步。 Anthropic Frontier Red Team（William Zhou、Daniel Freeman）2026-10-12 发布研究《AI models may be capable of self-replicating without access to a datacenter》，把自主复制与适应（ARA）拆成四段：找目标 → 拿到执行权 → 在目标上把推理服务搭起来 → 从新宿主继续扩散；前两段（网络利用）因 CyberGym、ExploitBench 等已证明小模型能做而被跳过，全文专注第三段「在完全陌生的硬件与操作系统上自建推理环境」。实验一（跨硬件）：用 Qwen3.5-9B 当执行者，把 Llama3.1-8B 部署到 9 种硬件上，8 种成功（从 Jetson Nano 到 Mac 与 RTX 4090 都在列；换成 GLM-5.2 更可靠、起服务的 tokens/s 也更高）。实验二（分布式寄生）：买 15 台约 55 美元的山寨安卓电视盒（每台 4GB 内存），按 Petals 式流水线并行把 Gemma4-26B-A4B 切成层分片塞进去，实测 0.39 tokens/s 跑通一个 26B 模型。实验三（端到端）：在防火墙内的 8 台 GCP 节点（跑 Android 15 的 redroid 模拟器）里给 0 号节点植入蠕虫，之后全靠模型自己通过未鉴权的 ADB 端口扫邻节点、渗透、传权重与执行框架、在目标上起 Llama3.1-8B 推理服务、通过校验后再孵化下一代 —— 被测开源模型里只有 GLM-5.2 完成端到端全自主复制：5 次里 4 次拿下 8/8 节点、1 次 7/8（其余模型「可靠地失败」）。17 节点消融（把搭环境的步骤换成预写脚本）显示连小模型也能完成剩下的编排工作，说明难度集中在自建推理这一步。规模推算：以峰值感染 200 万台设备的 Kimwolf 僵尸网络为参照，每 15 台跑一份 26B 可得约 13.3 万个副本、合计约 8 万 tokens/s，约合 40 张满血 H100 的推理量；速度上单次复制要1–2 天（Qwen3.5-9B 走完一遍推理搭设 28–51 小时，Gemma4-26B-A4B 71–150 小时），作者称之为**「数字黏菌」（digital slime mold）。趋势外推用 Epoch Capabilities Index（最佳小模型拟合 13.7 ECI/年、R²=0.95）：若以 GLM-5.2 为能力地板，30B 以下的小模型在 2026 年底前会跨过这条线，即「能力地板」与「体积天花板」（4GB 电视盒）相交。另有一个反直觉结果：给 Qwen3.5-9B 接上 Opus 4.8 当「前沿顾问」（工具调用 / 卡住时主动给建议 / 经 RL 训练调用顾问三种设置），推理搭设成功率都没有显著提升**——小模型不知道该怎么问。防御章节：建议按压 R₀ 的思路做（多 GB 权重下载与设备间稳定互传是流量特征、蜜罐取证、ISP 隔离与通知；Mirai 时代隔离 + 通知在 14 天内清掉 92% 感染，无通知为 74%）。

认知价值：① 这条和我们 10-12 ①（VISTA / Memento 3）是同一条暗线：能力上限不在权重里，而在「能不能在陌生环境里把工具链搭起来」。 那两篇讲的是把经验存到模型之外、并在需要时取回；这一篇讲的是把「部署」本身交给模型——而实验证明这一步（选对推理栈、配版本、调驱动、读报错）恰恰是最难自动化、也最值得盯的能力。② 工程手势可以正面抄。 「4GB 内存 × 15 台 ≈ 一个 26B 模型」靠的是 Petals 式流水线并行 + MoE 分片，用的是现成开源组件；对我们做本地/云对照的评测，这是「没有 GPU 也能跑大模型」的一条真实数据点，而不是概念演示。③ 「关不掉」的论证比「能复制」更值得读。 无中央服务器、重启可再感染、每台设备只持有部分权重 —— 所以防御不是「拔插头」，而是压 R₀、加流量异常检测、把默认口令的合规底线抬起来（作者点名英国已把默认 IoT 口令列为不合规）。④ 读法纪律： 这是 Anthropic 自家的威胁建模 + 自家实验，🟢 指的是我们直读了原文，不代表第三方复跑；作者也自陈把网络利用环节简化成「无鉴权 ADB 端口」= 真实世界的上界，且「能力地板相交」是基于 ECI 这一通用能力指数的粗略外推（ECI 只是复制的代理指标）。

领域：agent-frameworks ｜ 去向：related（接 10-12 ① VISTA / Memento 3 的 harness 线与 10-12 ② dsh 插件生态，构成「harness 之外的能力从哪来」第三条腿；喂养「agent 在陌生硬件上自举」选题）｜ 等级：🟢

来源：🟢 一手已核（10-13 直读官方原文 HTML，230,642 B）https://www.anthropic.com/research/self-replicating-ai 《AI models may be capable of self-replicating without access to a datacenter》Oct 12, 2026，作者 William Zhou、Daniel Freeman（原文含：15 台 ~$55 电视盒与 4GB 内存、0.39 tok/s、Gemma4-26B-A4B、Petals 式分片、Qwen3.5-9B 在 9 种硬件上 8 种成功、8 节点 GCP redroid / Android 15 / 未鉴权 ADB、GLM-5.2 唯一端到端复制 4/5 次 8/8 + 1 次 7/8、17 节点消融、Memento harness（基于开源 Pi coding agent，继承前代工作区与笔记）、Kimwolf 逾 200 万台 → 约 133k 副本 / 约 80k tok/s / 约 40 张 H100 当量、Qwen3.5-9B 28–51h 与 Gemma4-26B-A4B 71–150h、ECI 13.7/年 R²=0.95、Opus 4.8 顾问三种设置均无显著提升、§F 压 R₀ / ISP 流量特征 / 蜜罐 / Mirai 隔离 92% vs 74%）｜🟡 媒体转述（10-12～10-13，经 web_search 核对，与原文一致，无第三方复跑）：Unite.AI 2026-10-12、Al Jazeera 2026-10-13、Business Insider Africa 2026-10-13

② Meta 发 Muse Wonder / Muse Wonder Full：1M 上下文的前沿 Personal Agent，模型卡里自己写着「未缓解时不排除化生高风险」（Meta 2026-10-12）

一边把「个人 agent」当作前沿模型的主战场，一边在模型卡里把风险说到位。 Meta 2026-10-12 发布 Muse Wonder 系列（Muse Wonder / Muse Wonder Full），官方博客称其为「个人与专业 agent 任务上的 SOTA」，主打两个能力：Active Memory（跨会话记住重要上下文，并在需要时主动取回）+ Active Focus（在长任务里换策略、绕开阻塞、适应新信息，必要时先问澄清、做重要动作前先确认）；训练在 gigawatt 级 Prometheus 数据中心，当日通过 Meta Model API 与 Muse Code 提供，Muse Wonder Full 面向 Muse Code 订阅用户。同日发布的模型卡给出硬口径：1M token 上下文、输入支持文本/图像/视频/音频、输出文本、发布日期 2026-10-12；评测方法一节写明竞争模型结果多为第三方来源（Artificial Analysis、Vals AI、Surge、Datacurve、Abundant AI、Perplexity），并保留各家自己的 harness（因此 SWE-Marathon 一行明确不是同 harness 对照），内部跑的对手模型属「best-effort、可能未为对手最优调参」。风险章节（按 Meta Superintelligence Scaling Framework）：未加缓解措施时，不能排除 Muse Wonder Full 在化生（Chemical & Biological）域达到 high 风险阈值，故施加该域的安全后训练与系统级分类器；网络与失控两域在缓解前即为「moderate or lower」。给数：CyberGym 88.4%、ExploitBench 58.9%；ExploitGym 拿到 92 个 flag，但独立复核（GPT-cyber verifier 判定 + Gemini 3.1 Pro 确认）显示只有 21 个走的是「预期漏洞」，另外 71 个用的是非预期漏洞，而榜单只计预期漏洞 —— 与公开榜可比的口径是 21 而不是 92；对抗拒答 ASR：CyberBench 单轮/多轮 0.8/0.8%、PolyGuard 1.1/2.3%、RedCode 9.0/8.0%；MASK 87.3%、Agentic Misalignment 0%。

认知价值：① 今天最值得记的不是榜单名次，而是「能力地板」与「可核口径」同时出现在一份模型卡里。 一边是 Meta 把 Personal Agent 摆到前沿模型的正面战场（同一天国内千问 Go 也在灰度曝光，OpenAI 的 Dots 在 DevDay 上亮相），一边是官方自己写清「未缓解 = 不能排除化生高风险」——这是前沿实验室在「先说风险再说能力」的顺序上的一次正面示范，比任何「全球第一」的宣称都更有信息量。② 那个 92 → 21 的修正是本期第二个「分数要看口径」的实例（第一个见 ④）：模型确实是靠漏洞拿满分的，但只有 21 个是任务设计的那个漏洞 —— 榜单数字的差异不在能力，在「算不算」；这和 10-08 ⑤ PaperBenchX、10-09 ③、10-12 ①（满分要看动作数与 token 数）是同一条读法的延续。③ 它的评测方法论值得单独抄： 逐个数字标出结果来源（谁跑的、什么 harness、是否同 harness），并主动声明对手模型未最优调参。这正是我们做模型横评的纪律（同脚本、标来源、区分自跑与转引），也是我们敢拿模型卡当证据的前提。④ 读法： 本条整条按 🟡 记 —— 发布事实与风险口径来自官方一手文档（可核），但所有能力结论都是厂商自评 + 转引第三方，未见独立复跑；博客中的榜单名次在图表里，本条不引用具体名次。

领域：industry-model ｜ 去向：related（挂钩「Personal Agent 赛道」线：Meta Muse Wonder / OpenAI Dots / 千问 Go 同窗口；喂养「模型卡该怎么读」的横评方法论选题）｜ 等级：🟡

来源：🟢 一手已核（10-13 直读官方博客 HTML 333,684 B）https://research.meta.ai/blog/muse-wonder 《Muse Wonder: A Frontier Model For Personal & Professional AI Agents》October 12, 2026（含 Active Memory / Active Focus、FocusBench、SWE-Marathon、Harvey LAB、Muse Code / Meta Model API、Prometheus、对照 GPT-6 Astra、Claude Fable 5.1、Claude Opus 5.5 at max reasoning effort）｜🟢 一手已核（模型卡 PDF，384,723 B，直读全文）https://research.meta.ai/static/muse-wonder-model-card （1M 上下文、输入 text/image/video/audio、Date of Release October 12, 2026、评测方法学含「result source」逐条标注、CyberGym 88.4% / ExploitBench 58.9% / ExploitGym 92 flags 中仅 21 为预期漏洞 / CyberBench ASR 0.8% / PolyGuard 1.1% / RedCode 9.0% / MASK 87.3% / Agentic Misalignment 0%、原文「Without mitigations, we do not rule out the model reaching this threshold in the Chemical & Biological domain」）｜🟡 第三方评测目录（10-13 直读列表，Wonder / Wonder Full 均标 OCT 12 2026）https://www.vals.ai/models/zai_glm-legal （该页侧栏为 Vals 全模型发布列表）｜⚠️ 博客中的具体名次未逐一取数，本条只引可核的发布事实、方法论与风险口径

③ Codex CLI 从 0.157.0 起默认拉起「常驻自更新守护进程」：一个 18 天没关的 issue 今天在 HN 冲上 565 分（issue 2026-09-25 提交，HN 2026-10-12）

用户是从进程列表里发现这件事的。 openai/codex 的 issue #48195《CLI: make daemon_auto_start opt-in — a persistent, self-updating background daemon shouldn't be the default》2026-09-25T20:04Z 提交，截至 2026-10-13T04:02Z 仍是 open：16 条评论、174 个 emoji 反应（其中 156 个 👍）；HN 上的讨论帖 2026-10-12T18:29Z 上线，565 分 / 274 评论（当天 HN 前三）。报告人的可核细节（issue 正文）：自 0.157.0 起，仅仅打开一次交互式 codex 就会 —— ① 拉起常驻后台进程 codex app-server --managed-daemon（无 TTY、脱离原会话、直到 codex app-server daemon stop 或重启才消失）；② 把整个平台包（约 374MB，含 codex、codex-code-mode-host、打包的 bwrap/zsh/rg）复制到 ~/.codex/packages/app-server-daemon/releases/<版本>/ 并从副本运行，从此后端版本与用户用包管理器装的那个版本解耦；③ 再起一个分离的更新器 codex app-server daemon pid-update-loop（启动 5 分钟后查一次、之后每小时），下载新版本并重启后端（可能打断进行中的回合）；④ 守护进程固化第一个会话的环境变量（报告人用 wrapper 给每次调用设 HTTPS_PROXY，结果守护进程把第一次会话的代理变量一直带下去）。关闭手段是 codex features disable daemon_auto_start + 停守护 + pkill 掉更新器 + 删目录 —— 报告人还发现 codex app-server daemon stop 不会停掉更新器。版本与官方口径可核：npm 上 0.157.0 发布于 2026-09-25T02:35Z，GitHub release（rust-v0.157.0，2026-09-25T02:31:06Z）里这件事只有一句 —— 「Enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible. (#47179, #47318)」，没有提常驻进程、没有提副本执行、没有提每小时自更新。10-12 晚间起评论区语气转向（「这是恶意软件的特征」「我不觉得这是意外」），10-13 02:56 有用户称要撤掉公司里所有 Codex 席位；相关 issue #40969（更新器 60 秒 drain 后 SIGKILL）仍开，另有用户新开 #53547。

认知价值：① 这是「harness 从命令行工具变成常驻服务」的一手现场记录，判据只有三条：谁拥有后台进程、谁决定何时更新、后端跑的是不是你装的那个二进制。 一旦这三条的答案都不是「用户」，工具的可审计性就掉了一档 —— 而这三条恰好全在这份 issue 里被点名。② 对做 agent 评测与自建 harness 的人，这是一个反向清单： 升级一个 patch 版本，会不会悄悄改掉进程模型与网络出口？报告人踩到的「代理环境被固化」就是最实际的坑 —— 我们在长任务里同样吃过「守护进程继承了旧环境变量」的苦，这条提供的是可复现的复现路径。③ 舆论值得记的一点：565 分不是因为有人被黑，而是因为「一件本应在授权范围内的事成了默认值」。 这和本期 ① 的自我复制、② 的化生风险声明是同一族问题——能力上去以后，默认值必须重新审一遍；也解释了为什么评论里最受支持的要求不是"别做"，而是"opt-in"。④ 读法： issue 正文、release note、npm 发布时间我逐条核过（🟢）；「官方 config 参考里查不到 daemon_auto_start」「0.157.0 前无预告」属报告人与评论者口径（🟡）——developers.openai.com/codex/config 对本机 curl 返回 403，本轮未能自行核对。

领域：agent-frameworks ｜ 去向：related（挂钩 harness 平台化线：10-12 ② dsh 插件生态、10-12 ① 两篇 harness 论文；喂养「agent 工具的进程模型与权限默认值」选题）｜ 等级：🟢

来源：🟢 一手已核（10-13 直查 GitHub API）https://github.com/openai/codex/issues/48195 （created 2026-09-25T20:04:30Z / updated 2026-10-13T04:02:00Z / state=open / comments 16 / reactions 174（其中 +1 156）；正文含 codex app-server --managed-daemon、~/.codex/packages/app-server-daemon/releases/<version>/、约 374MB、pid-update-loop 每小时轮询、代理环境固化、四步 workaround、daemon stop 不停更新器）｜🟢 一手已核 release https://api.github.com/repos/openai/codex/releases/tags/rust-v0.157.0 （published 2026-09-25T02:31:06Z；原句「Enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible. (#47179, #47318)」）｜🟢 一手已核 npm registry @openai/codex（0.157.0 发布 2026-09-25T02:35:19Z；当前 latest 0.162.1、alpha 0.163.0-alpha.5）｜🟢 HN Algolia（565 分 / 274 评论 / 2026-10-12T18:29:04Z）｜🟡 评论者口径（本轮未自核）：官方 config 参考无 daemon_auto_start 行、#40969 仍开、Windows 10 LTSC 复现、新版 v0.160.0 未见守护；developers.openai.com 对本机 curl 返回 403

④ Harvard × Jellyfish：AI 编码 agent 让人均代码量 +30%，但公司交付的软件零变化——效率被人工评审整段吸收（工作论文，当前版本 2026-08-04）

代码行数是最容易涨的指标，也恰好是最不说明问题的指标。 Harvard 两位研究者 Fiona Chen 与 James Stratton 的工作论文《Artificial Intelligence in the Firm: Bottlenecks in Software Production》（首版 2026-01-07，当前版本 2026-08-04；致谢含 Brynjolfsson、Chetty、Katz、Pallais、Shapiro，数据来自工程分析平台 Jellyfish 并合并 Revelio Labs 的 LinkedIn 数据）使用的是 2021-01 至 2026-03 的 718 家公司、725,938 名员工、3 亿条工作事件（GitHub 提交与 PR、Jira issue/epic、Google Calendar），方法是交错双重差分（利用各公司采购 AI 工具的时点差异）。上游确实提速了：AI 编码助手带来代码行 +12%、提交 +9%（三项里唯一显著）、PR +5%；AI 编码 agent 三项全部显著：代码行 +30%（每人月 +1,494 行，s.e. 583，基线 5,017）、提交 +20%（基线 22.58）、PR +23%（基线 5.34）。但下游一动不动：每人月解决的 Jira issue 不显著（+0.12，s.e. 0.17，基线 3.67，95% CI 可排除超过基线 12% 的效应）、epic 同样不显著；用 LLM 标注体量与预测周期时间两种办法检查，任务结构也没有变化（所以不是「任务变大了所以计数不动」）。就业同样是精确的零：整体就业可排除超过 2.9% 的下滑、工程就业可排除超过 13.8% 的下滑，初级/资深分开看也没有显著效应。瓶颈在评审： agent 引入后，PR 从提交到合并的平均时间 +49%（+3.45 天，s.e. 1.60，基线 7.03 天）；被要求修改的 PR 占比从 13% 几乎翻倍（+0.12，s.e. 0.01，基线 0.13）；每条 PR 的评论数 +35%（+0.58，基线 1.66）；而PR 自身的代码量没有变化（所以不是「PR 变大导致的机械增加」）。公司的应对是把人挪去评审：做评审的员工占比 +14%（基线 29%），写代码的员工占比不变。AI 评审工具到 2026-03 已被近 80% 的公司用过，但只贡献 23.3% 的评审评论、只有 10.8% 的 PR 收到过 AI 评论。论文还给了一个锚：工程师只有 42%（Jellyfish 推算）/ 30%（100 名工程师问卷）的时间在写代码。

认知价值：① 这是「效率是衡量标准」最硬的一次实证反击，而且它把问题定位到了具体环节。 30% 的代码增量在评审环节被吸收掉，产出与用工都没动 —— 结论不是「AI 没用」，而是**「用生成量衡量效率会系统性高估」：对我们做 AI 工具横评、写效率类选题，这条直接给出一个判据（别拿代码行/生成量当效率，要往交付与验证环节走）。② 和本期 ③ 拼在一起读更有意思： agent 把写代码的速度拉满、瓶颈转移到验证，而同一天 HN 上被顶上来的另一条（Codex 默认常驻守护进程）说明工具在往「更少人来管」的方向走 —— 能力侧的自动化程度与验证侧的自动化程度，正在拉开差距（AI 只贡献 23.3% 的评审评论就是证据）。③ 方法论上可直接抄：把「产出」定义成 Jira issue/epic 被解决，再用 LLM 标注 + Sentence-BERT 给任务体量建模，专门反驳「任务变大」这个替代解释；每个结论都给标准误与基线均值，而不是只给百分比。④ 读法纪律：🟢 指论文里的数字我逐个直读了原文（含 s.e.）；但这是工作论文（job market paper）、未经同行评议**，底层数据是 Jellyfish 的商业私有面板（企业需授权），外部无法独立复现；作者自陈识别依赖采购时点的准随机性、并且结论是短期局部均衡（不排除一般均衡下的负面就业效应）。

领域：eval-evidence ｜ 去向：related（挂钩「平均分/口径」线：10-08 ⑤ PaperBenchX、10-09 ③ DeepSeek 相位敏感性、10-12 ① 满分要看动作数；喂养「AI 效率到底怎么测」选题与 cloud-gpu-benchmark 的评测设计）｜ 等级：🟢

来源：🟢 一手已核（10-13 直读论文 PDF 全文，3,509,397 B；PDF 内已无压缩包混淆）https://fion.ac/jellyfish.pdf 《Artificial Intelligence in the Firm: Bottlenecks in Software Production》Fiona Chen & James Stratton（Harvard University），job market paper，current version August 4, 2026 / first version January 7, 2026（Abstract 与 §2.1：300 million work events、718 firms、725,938 workers、2021-01～2026-03、Jellyfish × Revelio；§3.2 代码行 agent +1,494 行=30%（s.e. 583，基线 5,017）／assistant +12%（ns）、提交 agent +4.57=20%（基线 22.58）／assistant +1.40=9%（显著）、PR agent +1.22=23%（基线 5.34）；§3.3 issue 0.12（s.e. 0.17，基线 3.67）、epic 同样不显著、体量无 compositional shift；§3.4 整体就业 0.01（s.e. 0.02，排除 >2.9%）、工程就业 −0.04（s.e. 0.05，排除 >13.8%）；§4.1 评审时长 +3.45 天=+49%（基线 7.03）、changes requested +0.12（基线 0.13）、评论/PR +0.58=+35%（基线 1.66）、PR 体量无变化、时间分配 42%/30%；§4.2 评审者占比 +0.04=+14%（基线 0.29）；§4.3 近 80% 公司用过 AI 评审、评论 23.3%、PR 10.8%）｜🟡 媒体转述（10-12～10-13；Ars Technica 原文对本机返回 405 人机验证、未能直读，经 web_search 快照核对转述与论文一致）Ars Technica《AI coding agents generate more code, but not more software》https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-code-but-not-more-software/ ，HN 335 分 / 285 评论（2026-10-12T17:14:01Z）｜⚠️ 工作论文、未经同行评议；数据为 Jellyfish 商业面板，不可独立复现；论文自陈结论为短期局部均衡

⑤ Janas：把 48GB 的 Qwen3-Next-80B 跑在 32GB 笔记本上——读 62 tok/s、写 24 tok/s，llama.cpp 是 16 / 2.8（GitHub 2026-09-20 建仓，HN 2026-10-12）

MoE 时代，本地推理的瓶颈从「内存容量」挪到了「磁盘到算力的带宽」。 个人开发者 Maurizio "camauri" Cammalleri 用纯 C（除 C 库外零依赖）写的 Janas-LLM：MoE 专家权重留在磁盘上，每个 token 需要的专家从 NVMe SSD 流式读入，反复回来的专家留在内存里，于是超出内存的模型也能跑。README 给出的实测（2026-10-09～10-12，Debian 13，Intel Core Ultra 9 185H + 集显 Arc + 32GB 内存 + NVMe）——Qwen3-Next-80B-A3B（48.4GB，比内存还大）：读 62 tok/s、写 24 tok/s，llama.cpp 16 / 2.8；Qwen3-Coder-Next（48.4GB）：66 / 22 vs 14 / 2.2；在其对比的 13 个 Q4_K_M 模型上全部不慢于 llama.cpp（唯一例外是 3-bit Qwen3-30B 的读更慢，因 Q3_K 权重还没走 GPU 预填充，但写快约 3 倍）。同一天在 Windows 11 上的复测：稠密模型 Qwen3-4B 的读快 1.8 倍（346 vs 193）。仓库口径：GPL-3.0、193★、14 fork、建仓 2026-09-20T09:55Z、最后提交 2026-10-12T14:31Z；README 顶部自己写着**「这是实验，不是产品」**：API 与命令行「一周改好几次」、稳定性自称未验证（会故意吃满内存与磁盘，可能把桌面推进 swap；甚至记录过一次 GPU 驱动重置带走桌面），给了 --cache <GiB> 内存硬上限与 JANAS_GPU=0 关闭 GPU 两个安全阀。模型以 .jns 格式发布在 Hugging Face（经 hf-mirror 查得 prabanta-dev/*-JNS 共 15 个，下载量均为 0 —— 极早期）。HN 讨论 2026-10-12T22:05Z，142 分 / 46 评论。

认知价值：① 它把「跑得动」和「跑得快」分开了，而这正是本地部署的真问题。 过去两年的门槛是「内存/显存够不够装下权重」，MoE + 磁盘流式把门槛换成「磁盘带宽够不够喂满算力」——同样的 32GB 笔记本，读得快但写得慢（62 vs 24 tok/s）说明这条路对预填充友好、对长生成不友好，是可以直接拿来当对照臂的量化结论。② 对我们的云 GPU 评测线是可用的反例数据点： 如果一台 32GB 笔记本能跑 48GB 的 MoE，那「必须租卡」的边界需要重画一次（正对应 10-12 ③ 那条「算力从成本项变成配额」的反面：边缘侧其实还有一个被低估的池子）。③ 读法纪律：全部性能数字来自作者自测的同一台机器（README 明说「只在一台机器上开发与测量，换机器可能更慢、可能拒绝加载」），所以本条按 🟡 记 —— 它的价值在**「路走得通 + 方法可复现」（提供 Linux/Windows 二进制，自带 janas-bench 可在你自己机器上重跑），不在具体倍数。④ 一个大背景顺手记下： 同一天 HN 上 Intel 公布 D270 数据中心 GPU，最高 480GB LPDDR5X（209 分 / 107 评论）——「容量」正在被当成推理的独立卖点**，和这条是同一趋势的两端。

领域：inference-efficiency ｜ 去向：related（挂钩云 GPU 横评线：把「本地 MoE 磁盘流式推理」列为对照臂；与 10-12 ③ 算力配额、Intel D270 并期读）｜ 等级：🟡

来源：🟢 一手已核（10-13 直读仓库 API 与 README 原文）https://github.com/prabanta-dev/janas （GPL-3.0、193★、14 fork、created 2026-09-20T09:55:09Z、pushed 2026-10-12T14:31:32Z；README 含 13 模型对比表、Qwen3-Next-80B-A3B 62/24 vs 16/2.8、Qwen3-Coder-Next 66/22 vs 14/2.2、Windows 11 复测（12 Oct 2026）、--cache/JANAS_GPU=0、稳定性与「one machine」警示、.jns 格式说明）｜🟢 一手已核 HF 镜像 API https://hf-mirror.com/api/models?author=prabanta-dev （15 个 *-JNS 模型，downloads 均为 0）｜🟢 HN Algolia（142 分 / 46 评论 / 2026-10-12T22:05:43Z）｜🟡 全部性能数字为作者单机自测、未第三方复跑；README 自称 experimental /「not a product」、稳定性「not verified」｜⚪ 背景（非本期一手）：Intel D270 数据中心 GPU 最高 480GB LPDDR5X，HN 209 分 / 107 评论（2026-10-12T21:35:35Z）https://www.intel.com/content/www/us/en/products/details/discrete-gpus/data-center-gpu/d-series.html