Dream-RSI：谷歌开源的「做梦式」递归自我改进，让 AI 在虚拟历史里练出更优策略
一句话结论：谷歌联合 Google DeepMind、马里兰大学和弗吉尼亚大学在 arXiv 上发表了一篇论文（2609.14858），开源了 Dream-RSI——一种不修改模型权重的递归自我改进方法。它让智能体把自己走过的每一步存成一棵树，然后在树里「做梦」回放，练出更优的探索策略。论文称算法优化任务上只需 317 次调用就达到主流进化搜索跑 51200 代的效果。 AI 摘要 项目是什么：Dream-RSI，一种「通过演化世界实现递归自我改进」的方法，arXiv 2609.14858，17 位作者。核心机制：把搜索轨迹存成树，在「虚拟历史」里做梦回放，练出更优探索策略，再回到现实继续执行。关键数据：算法优化任务 317 次调用 vs 51200 代；GPU 内核优化生成次数降 2.43 倍；底层权重一字未改。适用边界：目前是研究系统，论文刚发布，需要工程能力才能复现，不是即开即用工具。 它和传统 RSI 有什么不同 过去谈起 RSI（递归自我改进），大家想到的通常是「AI 修改自己的权重，训出下一代」。这条路难在权重安全、失控风险和算力成本。 Dream-RSI 换了一个方向：模型权重不用变，让 AI 通过「做梦」来优化自己的探索策略。 具体做法是，智能体把每一次尝试、每一步决策都记录成一棵树——这是一段「历史」。然后在训练阶段，它回到这棵树的各个节点「做梦」，在虚拟的历史里演练不同的探索路径，学出一个更优的搜索策略。这个策略再回到现实里指导下一次执行。 这个思路的巧妙之处在于：它绕开了「改权重」这个最危险也最昂贵的环节，转而优化「怎么搜索」这个相对安全、可复现的外围能力。这和 Reef 让 Agent 边服务边学习 是同一类「不改权重」的 RSI 路线，只是 Dream-RSI 把「回放」这个机制做成了核心。 为什么效果这么惊人 论文给出的几个数字，是它引起轰动的直接原因。 在算法优化任务上，主流的进化搜索系统需要跑 51200 代才能达到的水平，Dream-RSI...
网易有道开源两款同传模型：200 毫秒延迟的开源 SOTA，实时翻译不再依赖大厂 API
一句话结论：9 月 16 日，网易有道在 AI Open Day 上开源了两款同传模型——子曰 4-R2T2（流式语音识别）和子曰 4-T3PO（140 亿参数的同步机器翻译）。两者都能流式输出，R2T2 平均延迟仅 200 到 600 毫秒，在开源模型里达到 SOTA。这是国产开源首次把实时同传做到「快嘴也能跟得上」的水平。 AI 摘要 项目是什么：网易有道开源的两款同传模型，子曰 4-R2T2（ASR）和子曰 4-T3PO（SiMT 同步翻译）。核心亮点：R2T2 延迟 200-600ms，开源 SOTA；T3PO 是 140 亿参数的文本到文本同步翻译模型。关键数据：有道 AI 同传累计服务 2500 万用户，使用次数同比增长近一倍。适用边界：开源模型可自部署，但配套的实时语音 Agent「叭哥说」是闭源产品，桌面端已上线。 同传模型的难点在哪 先讲一个很多人没意识到的点：同声传译和「语音转文字再翻译」是两回事。 普通翻译流水线是「听完一句 → 识别 → 翻译 → 输出」，每一环都有延迟，加起来就是秒级起步。同传要求的是「边听边译」——说话人还在说，翻译就得开始往外冒。这对模型有两个硬要求：一是流式输出，不能等句子结束；二是延迟要压到几百毫秒，否则就跟不上正常语速。 这正是同传模型难做的地方。它要在信息不完整的情况下就做出判断，还要在「翻译质量」和「等待时间」之间找平衡——等得越久翻得越准，但用户等不起。 两款模型分别解决什么 网易有道这次开源的两款模型，恰好对应同传流水线的两个关键环节。 子曰 4-R2T2 是流式语音识别（ASR）模型，负责把语音实时转成文字。它的平均延迟只有...
Reef：MIT 开源的「会自己学习」推理基础设施，把 Agent 的每次交互变成训练数据
一句话结论：MIT 研究员 Ao Qu 团队在 9 月 15 日开源了 Reef，一个 Apache-2.0 协议的持续自我改进 Agent 基础设施。它的核心思路是让推理服务器不再只是「跑模型」，而是记录每次推理的轨迹和反馈，自动训练、评估、发布新版本——把「模型上线后就不再变」这个默认假设改成了「模型边服务边进化」。 AI 摘要 项目是什么：Reef，持续自我改进的 Agent 基础设施，Apache-2.0，GitHub 上 Human-Agent-Society 组织维护。核心机制：四阶段循环「serve → observe → grow → commit」，推理、反馈收集、训练、评估、发布在同一控制循环里完成。关键能力：模型权重和 Agent harness 都能从真实经验中进化，候选版本评估通过才发布，不通过则服务不变。适用边界：不是自动重写整个智能栈的激进 RSI，而是「记住发生的事 + 提出有界改动 + 保留版本历史」的务实方案。 Reef 和普通推理引擎差在哪 先讲一个被默认接受的假设：推理服务器是「静态」的。你用 vLLM 或 SGLang 部署一个模型，它上线后就一直那样跑，直到你手动换新版本。模型本身不会从它处理过的请求里学到任何东西。 Reef 挑战的就是这个假设。它把「推理服务器」改造成了「边服务边学习」的闭环：记录每次推理的轨迹和用户反馈，把这些记录喂给学习任务，评估候选更新，通过后再热更新到线上——全程不用重启服务。 这个定位和...
NCP-ArchPreview：上海 AI Lab 开源 8.9B 潜空间模型，让 AI 在「概念」层而不是「词」层思考
一句话结论：上海人工智能实验室与上海交大 LUMIA Lab 在 9 月 14 日开源了 NCP-ArchPreview，一个约 89 亿参数的潜空间语言模型。它同时训练「预测下一个词」和「预测下一个概念」两个目标，在约 51.3% 的 token 上用更小的算力追平了 7B 基线的效果，是目前公开的最大规模潜空间模型实验。 AI 摘要 项目是什么：NCP-ArchPreview，一个 8.9B 参数的潜空间语言模型，联合训练 next-token 与 next-concept 两个预测目标。核心亮点：用「预测概念」替代部分「预测词」，在约一半的 token 上达到 7B 基线的 loss，参数效率更高。谁在做：上海人工智能实验室 NCP 团队 + 上海交大 LUMIA Lab。怎么用：技术报告见 arXiv 2609.10715，权重在 Hugging Face 的...
Colibri：纯 C 零依赖推理引擎，让前沿 MoE 模型跑在普通硬盘上
一句话结论：开源项目 Colibri 用纯 C 语言写了一个零依赖的 MoE 推理引擎，核心思路是不把整个模型的专家权重一次性装进显存，而是推理时从硬盘按需流式加载稀疏专家。这让前沿规模的混合专家模型第一次有可能跑在普通消费级硬件上，项目因此冲上了 GitHub Trending。 AI 摘要 项目是什么：Colibri，一个纯 C、零外部依赖的 MoE 模型推理引擎，作者 JustVugg。核心思路：推理时从磁盘流式加载稀疏 MoE 专家权重，而不是预加载整个模型到显存。价值：大幅降低前沿模型对显存和企业级硬件的依赖，推动本地化部署。适用边界：牺牲了部分速度换取显存门槛，适合实验和本地部署，不是云推理的替代。 Colibri 是什么 Colibri 是一个开源的 MoE 模型推理引擎，作者是开发者 JustVugg。它最近冲上了 GitHub Trending，原因是解决了一个很具体的问题：前沿混合专家（MoE）模型太大，普通电脑跑不动。 MoE 模型的特点是「大而稀疏」。像 DeepSeek、Kimi 这类模型，总参数动辄几百亿甚至上万亿，但每次推理只激活其中一小部分专家。问题在于，传统推理引擎为了速度，会把全部专家权重都预加载进显存——哪怕大部分专家这次根本用不到。这就把门槛拉到了需要企业级显卡集群的高度。 Colibri 换了个思路。它不预加载，而是推理到哪个专家，就从硬盘把哪个专家的权重流式读进来。这样显存里只放当前需要的那部分，门槛一下子就降下来了。 它凭什么跑得动前沿 MoE 关键在两点：纯 C，和零依赖。 纯 C 意味着没有 Python 运行时、没有深度学习框架的层层封装，推理路径短，内存开销可控。零依赖意味着它不依赖 CUDA 之外的任何重型库，部署简单。 流式加载是这个设计的核心。MoE 模型每一层有几十个专家，一次推理只会命中其中几个。Colibri 把这个「命中」和「从磁盘读取」绑定在一起，用 I/O 换显存。代价是速度会慢一些——磁盘读写总比显存慢——但换来的是一台普通电脑也能跑前沿模型的可能。 这跟