--- issue_number: W20260324 title: "6人撑300万客户，MoE提速2.1倍" url: https://ai.daily.yangsir.net/weekly?date=2026-03-24T00:00:00.000Z week_start: 2026-03-18T00:00:00.000Z week_end: 2026-03-24T00:00:00.000Z publish_date: 2026-03-24T00:00:00.000Z --- # 6人撑300万客户，MoE提速2.1倍 > 这周有意思的事不少：LLM学会用反例辅助数学推理，LeWorldModel搞定了世界模型稳定性，MoE模型靠预测专家策略提速2.1倍，Durable用6人支撑了300万客户，Vercel的方案不用向量库，Replit的Agent能解决90%合并冲突，还有新理论解释了Grokking延迟。 ## 本周精选（8 条） ### 1. LLM学会用反例辅助数学推理 **推荐理由**：突破证明局限，补全数学推理关键一环 **来源**：arXiv cs.AI https://arxiv.org/abs/2603.19514 **分类**：research 技术上有个思路我觉得挺巧。他们没去硬找现成的数据，因为现有的 CounterMath 数据集只有 **1,216** 道题，根本不够喂给模型。他们搞了个**“符号变异策略”**，逻辑很简单：既然证明题很多，那就把那些本来能证明对的定理，人为地把它的**假设条件删掉一部分**。这样一来，定理不成立了，自然就需要反例来推翻它。通过这种“破坏”的方式，他们合成了一大堆带反例的题目，把数据量撑起来了。 另外，他们还设计了一个**多奖励引导训练**的框架。以前模型做不出来题，奖励信号就是 0，训练很难进行。他们把奖励拆解了，哪怕模型没完全搞定，只要在中间步骤（比如证明被丢弃的假设）表现好，也能拿到分数。实验结果显示，这种“找茬”训练不仅让模型生成反例的能力变强了，顺带把**定理证明**的性能也带上去了。这说明让模型学会“证伪”，确实能反过来帮它理解逻辑，比单纯死磕证明要管用。 --- ### 2. LeWorldModel：首个端到端联合嵌入预测架构实现稳定世界模型 **推荐理由**：首个端到端JEPA，解决世界模型稳定性难题 **来源**：arXiv cs.LG (ML) https://arxiv.org/abs/2603.19312 **分类**：research LeWorldModel，Yann LeCun 团队的新工作。这是个**端到端**的世界模型，不用预训练，也不用那些花里胡哨的“停止梯度”或者“指数移动平均”等黑科技，居然也能训练得很稳。 以前搞这种 Joint Embedding Predictive Architectures (JEPAs)，最头疼的就是“表征坍塌”，模型容易偷懒。为了防这个，大家通常得加一堆 Loss 项，或者干脆冻结 Encoder。这篇论文的思路我觉得挺巧，他们把 Loss 项从以前的 **6 个超参数** 砍到了 **1 个**。核心就是用了一个叫 SIGReg 的正则化项，强迫隐变量分布接近高斯分布，以此来保证特征多样性。 效果上确实有点东西。模型只有 **15M 参数**，在单张 GPU 上跑，规划速度比那些基于 Foundation Model 的世界模型快了 **48 倍**。虽然体量小，但在 2D 和 3D 的控制任务上，性能跟那些大模型打平。 更有意思的是他们做了一组物理测试。他们发现这个模型的隐空间里，居然自动编码了物理量（比如速度、位置），而且能识别出“违反物理常识”的异常情况。这说明它不光是记住了画面，而是真的学到了点物理世界的规律。对于想搞轻量级具身智能或者离线强化学习的朋友来说，这个方案确实值得一看。 --- ### 3. MoE模型推理提速：预测专家策略减少内存占用 **推荐理由**：预测专家策略，MoE推理提速2.1倍 **来源**：arXiv cs.LG (ML) https://arxiv.org/abs/2603.19289 **分类**：research MoE（混合专家）模型显存不够用时推理会卡，这篇论文给了个实在的解法。 咱们都知道，MoE 虽然参数大，但算起来快，因为每个 Token 只过几个专家。但问题是，如果你的显存装不下所有专家，就得把专家放在 CPU 内存里，用的时候再搬到 GPU。这就像炒菜时发现酱油在隔壁邻居家，每次都要跑去拿，大部分时间都浪费在路上了。论文里有个数据很直观：在 Qwen3-30B-A3B 模型上，**CPU-GPU 传输占了 84-88% 的时间**，真正的计算反而没多少。 这帮人想了个挺巧的招，叫“专家预取”。既然算第 $L$ 层的时候必须等数据，不如顺便预测一下第 $L+1$ 层大概需要哪几个专家，趁着 GPU 在算第 $L$ 层的空档，提前把下一层的专家从 CPU 搬过来。他们发现，用当前层的“准隐藏状态”去猜下一层的路由，准确率还挺高。 更有意思的是，他们还搞了“投机执行”。要是预取的专家猜错了怎么办？通常这就得重来，但他们发现直接用猜错的专家算下去，**对下游任务的精度影响微乎其微**。这就省去了验证和回滚的开销。 实测下来，这套方案能带来 **5% 到 14% 的 TPOT（每个输出 Token 的时间）降低**。说实话，对于这种 I/O 密集型的场景，能压榨出 14% 的提速挺不容易的。代码已经开源了，如果你也在用显存跑大 MoE，可以试试他们的 YALIS 引擎。 --- ### 4. Durable：6名工程师支撑3百万客户，日处理11亿tokens **推荐理由**：6人撑300万客户，验证AI原生架构极致人效 **来源**：Vercel Blog https://vercel.com/blog/360-billion-tokens-3-million-customers-6-engineers **分类**：insight Durable，做 AI 商业建站服务的。他们现在的体量是 **6 个工程师支撑 300 万客户**，每天要处理 **11 亿个 tokens**，一年下来是 **3600 亿**。 说实话，看到这个“人效比”我第一反应是怀疑，但看完细节觉得他们的技术选型确实有点东西。 最让我有共鸣的是他们关于“造轮子”的抉择。他们 CPTO Osama Khan 说得很直白：团队太小，根本没精力去搞多区域集群维护、SSL 证书管理这些破事。他们算了一笔账，如果自建，光是 SSL 终止这一项，为了支持海量客户的自定义域名，成本就得几千美元。更别提多租户环境下的安全隔离和 DDoS 防护了，这哪是做产品，简直是在做云厂商。 所以他们直接把底层全甩给了 Vercel，自己只专注做业务。这招确实省心，把 **3-4 倍的基础设施成本** 给降下来了。 在 AI 这块，他们的架构思路也挺务实。因为做的是多租户 SaaS，最怕的就是“上下文泄露”，A 公司的生意绝不能跑到 B 公司的流程里。他们没去搞什么复杂的模型微调，而是把重点放在了编排和隔离上。通过这种“模型编排”层，他们能随时切换模型供应商来优化成本和可靠性，而且能精确到每一个客户的 AI 花费。 这种“小团队干大事”的案例，核心不在于他们用了什么黑科技，而在于极度克制。**每个工程师能产生 10 倍的杠杆效应**，靠的不是加班，而是把所有非核心的脏活累活都外包出去了。 --- ### 5. Vercel推出无需向量的知识代理方案 **推荐理由**：颠覆RAG范式，弃用向量库提升可调试性 **来源**：Vercel Blog https://vercel.com/blog/build-knowledge-agents-without-embeddings **分类**：insight Vercel 开源了一个**Knowledge Agent Template**，核心思路是**完全抛弃向量数据库**，改用**文件系统**和 **Bash 命令**来做知识检索。 咱们做 RAG 的都知道，现在的标准动作是切分、向量化、存 Pinecone 或 Milvus。但 Vercel 觉得这事儿太复杂且不可控。他们发现，与其教模型理解新的向量空间，不如直接让它干它最擅长的事：**读文件、跑 grep、找目录**。 这方案技术上其实挺简单粗暴：把你的 GitHub 仓库、文档或者 YouTube 字幕存到 Postgres 里，然后通过 Vercel Workflow 同步到一个快照里。当有提问时，模型会在一个**隔离的 Vercel Sandbox**里直接执行 `grep -r "pricing" docs/` 这种命令。 他们拿销售电话总结的 Agent 做了 A/B 测试，数据挺能打：成本从**每次约 $1.00 降到了 $0.25**，而且输出质量还变好了。 我觉得这思路最巧的地方在于**可调试性**。以前用向量，模型答错了，你只能看到它取了相似度 **0.82** 的那个块，至于为什么是 0.82 而不是 0.79，基本靠猜。现在用文件系统，你直接看 Trace 就知道它刚才是不是 `cat` 错文件了，或者是 `grep` 的范围写窄了。这根本不是在调参数，就是在修 Bug。 对于那种需要精确数值的结构化数据（比如定价、API 参数），这种**确定性**的检索方式确实比语义相似度更靠谱。不过这方案对模型的指令遵循能力要求高，要是模型连 Linux 命令都写不利索，这架构就跑不起来。 --- ### 6. 代理编程评估中基础设施噪声量化研究 **推荐理由**：量化评估噪音，建立AI编程能力可信基准 **来源**：Anthropic Engineering https://www.anthropic.com/engineering/infrastructure-noise **分类**：research 大家平时看 SWE-bench 或者 Terminal-Bench 这种榜单，总觉得排在前面的模型比后面的强那么几个百分点，这差距似乎很精确。但这篇文章直接泼了盆冷水：**基础设施配置带来的波动，就能达到 6 个百分点**，这比榜单上头部模型之间的分差还要大。 这事儿其实挺有意思。以前跑静态代码生成，环境就是个摆设。现在跑 Agent，模型要自己写程序、装依赖、跑测试，运行环境直接变成了解题过程的一部分。Anthropic 在 Terminal-Bench 2.0 上做实验，把资源配额从严格限制（1x）一直加到无上限。结果发现，**只要给足资源（超过 3x），成功率能直接拉升 6 个百分点（p < 0.01）**。 这里面的门道在于“容错”。他们一开始用 Kubernetes 严格限制资源，把 CPU 和内存设成既保底又封顶的硬限制，结果 **6% 的任务因为容器被 OOM（内存溢出）杀掉而失败**。后来发现，官方榜单用的沙箱其实比较“宽容”，允许瞬时超配，这就导致大家其实不在同一条起跑线上。 更有意思的是数据的边际效应。在 1x 到 3x 这个区间，提升资源主要是减少了 **Infra Error（基础设施错误）**，从 5.8% 降到了 2.1%，但这还没真正帮模型“解题”。一旦超过 3x，模型就开始玩“花活”了——**成功率比错误率下降得还快**。这时候模型敢拉巨大的依赖包、跑很重的子进程，比如那个 `rstan-to-pystan` 任务，给足了内存才能跑通。 说白了，现在的榜单如果不把资源配额写清楚，分数其实有点虚。限制严了，是在考模型写“穷游”代码的能力；限制宽了，是在考模型“挥霍”资源解题的能力。这两个方向都对，但混在一起打分，确实容易让人误读。 --- ### 7. Replit发布Agent 4，AI自动解决90%合并冲突 **推荐理由**：自动解决90%合并冲突，攻克协作编程痛点 **来源**：Replit Blog https://blog.replit.com/live-from-hq-agent4-launch-pt2 **分类**：release Replit 发布了 Agent 4，宣称 AI 能自动解决 **90%** 的代码合并冲突，这事儿听着挺玄乎，但看了一下技术细节，确实有点东西。 以前多 Agent 并行干活最怕什么？怕它们同时改同一个文件，最后打架。Peter 他们的工程师团队这次是硬啃了这块骨头。现在的逻辑是，Agent 4 会先推理任务顺序，比如先做登录系统再做管理后台，确定好依赖关系后，能并行的就并行。一旦遇到冲突，模型会像人类工程师那样去理解意图并解决。**90%** 的情况它能自己搞定，剩下那 **10%** 的疑难杂症才扔给人来定夺。说实话，这个 90% 的成功率如果是真实生产环境的数据，那相当夸张，毕竟代码冲突这玩意儿有时候连人都得琢磨半天。 另外，Adi 提到的那个微虚拟机技术我觉得挺巧妙。为了让你感觉不到 Git 的复杂，他们每次开新任务都在云端秒级拉起一个隔离环境。Agent 在那个副本里瞎折腾，搞定了再合回来。这种“**秒级**”启动的隔离环境，配合上不按人头收费的协作模式，对那种拉个外部专家来临时救火的小团队很友好。 CEO Amjad 最后举了个例子，说有家公司用这玩意儿自动化搞营销任务，一年省了 **100 万美元**。虽然这种 Case Study 的数字通常得打个折看，但方向很明确：他们想把这个工具从“写代码的 IDE”变成“从 idea 到 shipped product”的流水线。 --- ### 8. 新理论解释Grokking延迟：表征相变的关键机制 **推荐理由**：从原理解释Grokking，量化泛化延迟机制 **来源**：arXiv cs.AI https://arxiv.org/abs/2603.13331 关于 **Grokking** 现象的一篇论文——就是模型明明早就把训练集背得滚瓜烂熟了，但就是不泛化，非得再练上几千步，突然一下“顿悟”了。以前大家觉得这事儿挺玄学，这篇论文直接把它给数学化了，提出了个 **“范数分离延迟定律”**。 这帮作者做了一件挺巧的事儿，他们没去纠结具体的神经元怎么连接，而是从动力学的角度去看。他们发现，所谓的“顿悟”，其实就是模型在优化器的驱动下，试图从一个**高范数的“记忆解”**逃出来，滑向一个**低范数的“结构解”**的过程。 最让我觉得有意思的是他们推导出的那个延迟公式，结论非常反直觉但又在情理之中：延迟时间跟权重的**范数比值的对数**成正比。也就是说，如果那个死记硬背的解权重特别大，模型想爬出来就得花更久的时间。而且他们还量化了优化器的影响，比如 **AdamW** 的有效收缩率比 **SGD** 大，所以 AdamW 能 Grokking，SGD 在同样参数下可能就完全不行。 为了验证这个理论，他们跑了 **293 次实验**，涵盖了模加法、模乘法甚至稀疏奇偶性任务。数据显示，这个预测的准确度极高，**R² > 0.97**。这基本上就给 Grokking 盖棺定论了：它不是什么魔法，就是正则化训练下的一种必然的物理过程。以后谁再跟你扯“机器产生了意识”，直接把这个公式甩他脸上。 --- **周报详情页**：https://ai.daily.yangsir.net/weekly?date=2026-03-24T00:00:00.000Z --- *智语观潮 · 每周深读 — https://ai.daily.yangsir.net/llms.txt*