全部 · 2026-06-12

Dan McInerney 开源的这个工具，思路是把 Claude Fable 5 和 GPT-5.5 Codex 串成一个分工流水线：Claude 负责拆解任务、做代码审查，GPT 负责动手写代码，整个代码仓库充当记忆。作者说这样能把 Claude 的 token 消耗砍掉 80%，但仓库里只有 README 和代码，没给任何测试基准或对比数据，这个 80% 的数字先别太激动。 好处是思路清晰——让贵的模型干轻活、便宜的模型干重活，理论上确实能省钱。但实际效果取决于 Claude 拆任务拆得准不准、GPT 写的代码能不能用，以及来回审查会不会反而增加延迟。正文没披露这些关键信息，也没说在什么项目上跑过、跑出来的代码质量怎么样。 想试的话可以当个实验性工具玩玩，但别指望它立刻在生产环境里稳定省钱。缺的是真实项目上的端到端测试，以及和纯用 Claude 或纯用 GPT 的对比数据。

这篇论文的想法简单到有点冒犯：现在每个AI智能体读同一份文档，都要从头算一遍最耗算力的“预填充”，生成一份完全一样的KV缓存。作者说，干脆让发布方提前算好，其他人花钱加载就行。在Qwen3-4B上实测，复用缓存比重新预填充便宜9到50倍，而且输出的token完全一致，精度零损失。这个省钱幅度会随文档变长而拉大，因为预填充的注意力计算复杂度是平方级的。 但有个关键坑：KV缓存几乎压不动，直接把文件传出去，网络传输费比省下的算力还贵。所以作者给出的解法是让缓存留在服务商那边，像现在生产环境里的提示缓存一样用。他们算了一笔账：一份3774个token的热门文档，给8000万个智能体服务，重新预填充要花约150万美元，复用缓存只要约3万美元，差了49.7倍。 论文把这个模式叫做“面向智能体的预填充CDN”，但正文没给出跨服务商结算的具体方案，也没解决KV缓存的无损压缩问题。这两个缺口让“买缓存”这件事暂时还停留在自家服务商内部用，跨平台交易还跑不通。如果压缩和支付层能补上，这个省钱逻辑对高频文档服务确实成立。

这条消息目前还只是 TechCrunch 听到的风声，不是官方公告。估值从 C 轮的 117 亿欧元跳到约 200 亿，涨幅接近一倍，在当下大模型融资环境里算很猛。但关键信息全缺：谁领投、钱是拿来买算力还是铺市场、这轮什么时候能关账，正文一概没提。没有这些，光一个估值数字很难判断这轮融资的真实成色。另外，Mistral 上一轮 C 轮是 2024 年 6 月关的，如果一年后真能以翻倍估值再融一大笔，说明投资方对它的开源路线和欧洲市场故事还买账。但反过来，估值跳这么快也可能包含不少预期溢价，实际营收和用户规模能不能撑住，正文没给任何数据。我会等公司官宣或者看到领投方和资金用途再认真对待。

这条新闻值得关注的点在于，它把评测从“最终考试”变成了“开发过程中的体检”。Ai2 在 OLMES 标准上搭的 olmo-eval，核心解决的是模型开发循环里的反复评测麻烦。你调数据、改架构、换超参时，不用再手动拼凑各种基准测试，它能让你随时加新基准，在不同训练检查点上跑，还能逐条提示分析结果。 比较实在的是，它原生支持多轮对话和让模型进业务流程干活的评测，不是事后补丁。还带了分析工具，帮你判断一个 2.4 个百分点的分数变动到底是真提升还是纯噪声，这点对做模型的人很实用。代码已经开源在 GitHub 上。 不过正文没披露这套工具自身的运行开销和上手门槛。另外，它目前主要基于 OLMES 标准，对其他评测体系的兼容性如何，以及在大规模模型上的实际表现，都还需要看社区后续的反馈。

这条消息对正在训模型的人挺实用。Allen AI 发布的 olmo-eval，说白了就是把评测从“最后交作业”挪到了“开发中随时测”的环节。它最大的变化是把让模型调用工具、多轮对话这类评测当成一等公民来支持，不再是跑个标准榜单就完事。你可以根据任务选轻量模式快速看分，也可以用容器隔离跑更复杂的场景，架构上模型、工具、运行环境都能独立替换，灵活性比之前的 OLMES 高不少。 跑完分不只给个数字，还会附上标准误差和最小可检测效应量，这点比较实在——能帮你判断分数波动是真实提升还是噪声。和 Harbor 这种面向最终发布的评测不同，olmo-eval 更偏向开发中的快速迭代，甚至支持逐题对比不同检查点的输出。 不过正文没披露这套工具自身的运行开销有多大，也没给出和现有评测框架（比如 lm-eval-harness）在速度、成本上的直接对比。如果是真的能省下反复配置环境的时间，对中小团队挺友好，但这点先别太激动，得等实际跑起来看。

这篇论文的核心思路很直白：在 GQA 基础上加一个轻量的“索引分支”，先给每块 KV 缓存打分，每个查询组只挑分数最高的几块，主分支再对挑出来的块做精确注意力计算。相当于先快速扫一眼目录，只精读最相关的章节，省掉了大量无用计算。配合专门写的 GPU 内核，一个 109B 参数的多模态模型在 H800 上跑 1M 上下文，预填充端到端快了 14.2 倍，解码快了 7.6 倍，而且质量跟全量 GQA 持平。 数字看着漂亮，但要注意几点。第一，测试是在 H800 上跑的，家用显卡能不能复现这个加速比还不清楚，论文没给消费级硬件的 benchmark。第二，109B 模型本身就不小，即使推理加速了，显存门槛依然很高，Reddit 原帖也在问能不能在家用卡上跑，目前没有答案。第三，代码和推理内核开源了，但模型权重是否公开正文没披露，想自己试还得等消息。 整体来说，这个方法对做超长上下文推理服务的人是个实打实的优化方向，省算力还不掉效果。但对想在自己机器上玩的个人开发者，先别太激动，等权重放出来、有人测了消费级显卡再说。

MiniMax 这次开源的是个混合模型，总参数 428B，但每次推理只激活 23B，靠自研的稀疏注意力把上下文窗口拉到 100 万 token，还原生支持多模态。跑分上，SWE-Bench Pro 拿了 59.0%，Terminal Bench 2.1 有 66.0%，MCP Atlas 74.2%，这几个数字在代码和智能体任务里算能打。但 SWE-fficiency 只有 34.8%，KernelBench Hard 28.8%，说明在效率和底层优化任务上还有不少空间。 现在的问题是信息缺口太大：正文没披露训练数据来源、推理成本、授权条款，也没说这 23B 激活参数在实际部署时吃多少显存。技术报告要等 10 天，在那之前这些跑分只能当参考，别急着下结论说它比谁强。如果是真的省钱又好用，那对想做代码助手或让模型进业务流程干活的团队是个好消息，但这点先别太激动。

MiniMax 在 Hugging Face 上开源了 M3 模型，这是个混合专家模型，总参数约 4280 亿，但推理时只激活其中约 230 亿个参数。打个比方，就像你雇了 20 个专家但每次只叫 1 个来干活，算力开销跟 23B 的小模型差不多，但背后能调用的知识量要大得多。 不过这条帖子本身信息量很薄。正文被 Reddit 的安全策略拦住了，我们看不到原帖里的技术细节、benchmark 跑分，也不知道本地部署最低要多少显存。Hugging Face 页面上的模型卡可能写了这些，但帖子没转过来。 如果你打算自己部署，先别激动。230 亿激活参数虽然比全量 4280 亿友好很多，但 MoE 模型对显存带宽和总容量要求不低，大概率不是一张消费级显卡能轻松跑起来的。建议先去 Hugging Face 仓库看模型卡上的硬件要求和量化方案，再决定要不要下载那几百 G 的权重文件。

这事最让人不舒服的点在于知情同意完全缺失。Niantic 把 Pokémon Go 玩家在真实世界里扫描的场景数据，拿去训练了一个能理解物理空间的地理空间 AI 模型，这个模型后来被用到了美国陆军等合作方的军用无人机项目上。玩家在不知情的情况下成了训练数据的贡献者。 正文没披露具体用了多少玩家数据、合同金额，也没说玩家现在能不能事后退出。模型能识别和导航真实环境，但文章没讲清楚它到底在无人机上负责哪部分任务，是侦察、导航还是别的。这点先别太激动，但数据流向从游戏到军事的路径本身，已经够让人警惕了。 还缺一个关键信息：Niantic 在用户协议里有没有给自己留过这种口子，以及军方合同的具体条款是什么。没有这些，我们只能看到结果，看不到决策链。

Kimi 把新代码模型 K2.7-Code 开源了，跟上一代 K2.6 比，在自家三个测试集上分数都涨了：Kimi Code Bench v2 涨 21.8%，Program Bench 涨 11%，MLS Bench Lite 涨 31.5%。推理时吐出的 token 量少了 30%，相当于同样的活儿更省算力。长代码任务里指令遵循和端到端成功率也都有提升，还预告了一个 6 倍速模式。 这些数字看着不错，但得打个折。三个测试集全是 Kimi 自家的，没有跟外部公认的代码基准（比如 HumanEval、SWE-bench）做对比，说服力有限。正文也没披露模型参数量、训练数据规模和开源协议类型，不知道是多大体量的模型，也不知道商用有没有限制。 如果这些分数能在外部队列上复现，而且 token 节省是真的在复杂项目里成立，那对用 Kimi API 做代码生成的开发者来说挺实惠。现在缺的就是第三方验证和更透明的技术细节。

这条帖子来自 llama.cpp 社区的实际测试，结论很直接：MTP 投机解码不是无脑开就能加速，助手模型（draft model）的匹配度才是关键。测试者用 Gemma 4 Heretic 系列跑，26B Q8 模型从每秒 30 token 跳到 62，12B Q4 更夸张，从 12 涨到 54——但前提是助手模型选对了。 两个值得注意的发现：第一，同名 GGUF 文件不一定是同一个模型，这会导致加速效果天差地别；第二，未量化的助手模型比 Q4/Q8 版本稳定快大约 10 token/秒。另外，draft count 设为 1 反而效果最好，这点和直觉不太一样。 正文没披露测试用的具体 prompt 和硬件配置，所以这些数字只能当参考，不能直接套到自己的场景。如果你也在折腾 MTP，建议先检查日志确认 MTP 真的初始化成功了——作者特别提醒，很多人其实是在裸跑主模型，根本没用到投机解码。