跳到正文
Latent Space· Latent Space·· 3 天前精选AI 评分74

DeepSeek 开源生产推理框架 DeepInfer,披露单集群吞吐与收入数据

[AINews] DeepSeek DeepInfer: Open Source SOTA Inference running 155T toks/day/cluster making $22m/day at ~80% margin for a 81 day payback

AI 导读

DeepSeek 开源了用于 V4.1 Flash 的生产推理框架 DeepInfer,并发布生产服务数据:单集群每天处理 155 万亿 tokens,输入缓存命中率为 96%,非高峰时每张加速卡每小时收入为 $38。

推荐理由

报道梳理了 DeepInfer 的生产架构、缓存设计与 vLLM 的对比结果,也说明高吞吐和收入数据受缓存命中及工作负载构成影响。

正文 · AI 翻译

译文尚不完整,完整内容请切换到原文。

由 SerpApi 隆重呈献:今天的发布内容涵盖面很广,但你可以将所有内容抓取为供智能体使用的Markdown!与 JSON 相比,token 成本降低 50%。


我们上次在4 月报道了推理拐点。从历史来看,大多数进展都来自Fireworks 到 Baseten,再到Modal等闭源十角兽公司。

好了,该轮到开源阵营回应了。今天是PyTorch Conf的第一天,而 DeepSeek 适时向讨论中发射了一枚洲际弹道导弹:他们将生产级技术栈DeepInfer开源,其提示缓存时长最高可达 72 小时,而 OpenAI 刚宣布的是12 小时:

在 X 上查看原帖

这是他们基于 vLLM 定制的版本,并致谢 SGLang 和 TRRTLLM,但其中新增了不少内容……除了他们的核心技术——他们的超优化 KV 缓存(紧凑,且生命周期超过 8 小时)、PD/解耦,以及负载均衡(他们的3FS早些时候已开源)。我们翻译了他们的博客文章,并在此发布,同时提供完整的研究指南、解读、代码地图和子系统指南:

正如我们在他们的补充披露中指出的,按他们声称的每天处理 155T tokens 计算,按非高峰时段价格计,每张 SM100/A950 卡每小时可带来 38 美元收入(目前每百万输入/输出 tokens 的价格为 $0.15/$0.60:155000000 tokens * $0.14 加权成本 / 24 小时,约为每小时 $1m)。根据他们的生产数据(我们已翻译),每张预填充 GPU 每秒处理 150 万个含缓存的输入 tokens,输入缓存命中率为 96%,每张解码 GPU 每秒处理 14,000 个输出 tokens(共约 2400 张 GPU):

Image preview

按每张卡每小时 $5-8 的全包成本计算,推理利润率超过 80%!

做些集群规模的估算,每 GW 大约对应 $166B,按推理利润计算,回本周期为 81 天(DeepSeek 出名的目标是 10 个月回本)。想象一下,这头巨鲸有更多 GW 可用时能做到什么。


赞助商:SerpApi

用更少的 tokens 为 AI 智能体提供实时搜索数据

从 SerpApi 的 100 多个 API 获取干净、结构化的 Markdown 格式结果,平均比 JSON 少用约 50% 的 tokens。只需添加 output=md 或使用 /search.md 端点即可。无需任何配置,所有套餐均包含此功能,不收取额外费用。


2026/10/19-2026/10/20 的 AI 新闻。我们查看了 12 个 subreddit、544 个 Twitter 账号,没有发现更多 Discord 内容。通过 AINews 网站可以搜索所有往期内容。提醒一下,AINews 现在是 Latent Space 的一个栏目。你可以选择接收或退订不同频率的邮件!


AI Twitter 摘要

头条:DeepSeek DeepInfer——生产级推理、开源边界与缓存 tokens 的经济效益

发生了什么

DeepSeek 发布了 DeepInfer——V4.1 Flash 背后的推理引擎,并披露了生产环境服务细节,使这份工程报告的重要性不亚于代码本身。

  • 此次发布涵盖推理引擎和 API 处理层。DeepInfer 支持在 NVIDIA 和 Huawei Ascend 平台上进行分布式推理、推测解码、SWA Bounded Replay 和结构化输出。配套的 deepseek-recipe 组件实现了生产级 token 编码/解码和兼容官方 API 的处理流程。DeepSeek 表示,未来的模型推理实现和优化也将出现在此代码库中。@deepseek_ai、@deepseek_ai、公告译文

  • 据报告,生产环境的相关数据相当可观——但描述的是一个大量使用缓存的服务。DeepSeek 的工程报告(如所提供帖子中的摘要和引述所述)报告称,单个集群每天处理 155 万亿个 token,输入缓存命中率为 96%,平均首 token 延迟为 400 ms,生成速度为 230 tokens/s,而编程任务可达 300 tokens/s。报告还称,按非高峰时段价格计算,每加速器小时收入为 $38。这些是来自一手来源的生产环境数据,并非经独立审计的测量结果。@ZhihuFrontier、@swyx

  • “完全开源”并不意味着可以根据此次发布复现整个生产服务。尽管 DeepSeek 将 DeepInfer 描述为完全开源,但技术说明指出,KV-cache 管理和负载均衡组件尚未完全发布,因为它们仍与内部基础设施耦合。引擎是开放的;服务层面的重要编排工作仍需由部署方负责。@deepseek_ai、@ZhihuFrontier

  • vLLM 给出了最具体的比较回应。在承认 DeepInfer 最初主要基于 vLLM 构建并以 Apache 2.0 许可证发布后,vLLM 团队报告称,在匹配配置下,GB200 上的解码吞吐量与 DeepInfer 公布的结果相差不到 6%。团队还公布了 AgentX 的结果和复现方案,实质性地修正了“DeepSeek 的效率无法通过现有开源引擎实现”这一说法。@vllm_project、@vllm_project、复现资源

  • 此次发布引发了两场不同的讨论:DeepSeek 是否拥有独一无二的强大服务栈,以及其披露的数据是否普遍证明了推理业务的高盈利能力。前者如今有了比较基准测试作为证据;后者仍取决于工作负载构成、缓存统计方式、硬件成本以及费用的计入范围。@Tim_Dettmers、@zephyr_z9、@Yuchenj_UW

架构:阶段分离,调度计算而非 token

DeepInfer 披露的架构将视觉编码、预填充和解码分开,使每个阶段都能针对自身瓶颈进行扩展。建议的部署配置为:预填充使用普通的八加速器机器,解码使用配备 64–128 个加速器的超级节点。解码阶段采用宽幅专家并行来分发 MoE 专家,同时保持较大的有效批次。这些是部署建议,并不足以证明 DeepSeek 生产集群的确切硬件组成。@ZhihuFrontier

调度方面的细节说明了为什么常规的“每批 token 数量”比较可能会忽略显著差异:

  • Prefill 调度会估算注意力计算成本。任务分配依据估算的计算量,而不只是原始请求长度。分块大小会根据时间预算动态调整,而不是对异构请求统一采用固定的分块大小。@ZhihuFrontier

  • Prefill 路由不要求缓存亲和性。由于缓存的前缀存储在共享存储中,请求可以被发送到任何可用工作节点,而不必发送到之前处理该前缀的工作节点。在一篇详细的中文分析中,推理工程师 Su Jin Yan 强调,这是一个特别实用的生产设计:prefill 数据并行组根据“计算 token”进行负载均衡,而共享存储则提供可复用的状态。该分析还强调了请求分桶,以及结合运行时估算器的 FIFO 调度。@SuJinYan123

  • Decode 路由同时根据运行中请求的数量和 KV 缓存长度进行负载均衡。请求数量近似反映调度压力;累计 KV 长度则反映仅凭请求数量无法捕捉的内存和状态压力。工程评论指出,prefill/decode 的扩缩容信号分别是汇总计算负载和运行中请求。@ZhihuFrontier、@SuJinYan123

  • 专家并行负载均衡会复制热门专家。系统会定期重新分配副本,以减少路由倾斜导致的设备间等待。这样需要以额外的 HBM 消耗换取更高吞吐量;随着副本数量增加,收益会递减,而有用的复制因子取决于具体工作负载。@ZhihuFrontier、@SuJinYan123

  • CPU 调度会与加速器执行重叠。异步调度会消除 decode 步骤之间的空闲间隔,而不是将主机侧编排视为没有成本。@ZhihuFrontier

一个技术上值得注意的观察是,在披露的 Blackwell 配置中似乎没有采用张量并行。一位评论者将其与 vLLM/SGLang 的默认方案进行对比,并将这种方法追溯到 DeepSeek V3 在 H800 时代面临的互连限制。这是对该配置的解读,并不证明张量并行普遍处于劣势。@nrehiew_

规模同样很重要。Su Jin Yan 认为,广泛的专家并行 prefill 需要足够的流量和工作节点才能发挥价值;在只有少量 prefill 工作节点的情况下,他更倾向于在中小规模部署中采用流水线并行。作者还指出,层之间的异构性可能使流水线划分变得复杂。这是从业者的判断,并非用于确定普适性转折点的基准测试。@SuJinYan123

缓存层级:持久化前缀与瞬时状态的低成本重建

缓存设计是连接吞吐量数据、智能体工作负载和所报告的单加速器收入的核心环节。

持久化块 KV 存储在独立的 3FS 存储集群中,该集群配备约 100 PiB 的 SSD 容量。据报告,智能体流量的保留期为三天,聊天机器人流量的保留期为七天。任何 prefill 工作节点都可以获取缓存的前缀,从而将缓存局部性与计算放置解耦,并允许存储和计算独立扩展。@ZhihuFrontier

这种保留机制对反复重新发送不断增长的指令历史、仓库内容、工具输出和先前响应的智能体很有用。这也意味着,每日服务的 155T 个 token 不能理解为每日新生成 155T 个 token:缓存命中计入服务的 token 统计,而新计算的预填充和自回归输出成本差异很大。因此,报告中的 96% 输入缓存命中率是理解 headline 吞吐量的关键信息。@ZhihuFrontier、经济性工作负载假设

该实现处理两种不同的状态生命周期:

  • 持久化块缓存以异步方式加载。主机到设备的数据传输与层执行重叠。Su Jin Yan 指出了一项更底层的实现细节:通过 CUDA 复制引擎进行细粒度 KV 块复制时性能不佳,因此所述路径采用 基于 GDR/RDMA 的传输,旨在充分利用 PCIe 带宽,同时不占用 SM。这是根据报告得出的技术观察,并非该条推文中单独测量的结果。@SuJinYan123

  • 滑动窗口注意力状态保留在主机内存中,而非持久化 SSD 存储中。它主要适用于活跃会话,其生命周期短于可复用的块前缀。@ZhihuFrontier

  • SWA 有界重放仅利用最近的 128 个 token 重建缺失的短期状态。重放将注意力限制在该片段,同时复用持久化块缓存,从而得到近似结果,而非根据此前的完整历史重建状态。DeepSeek 报告称,这种方法可将预填充总计算量几乎减半。在考虑移植到其他架构时,这种近似方式及其针对特定模型的有效性都很重要。@ZhihuFrontier

Su Jin Yan 还报告称,延长保留时间仅能额外带来约 0.5–1 个百分点的缓存命中率,体现了存储容量与重新计算之间的权衡。同一评论还指出,以解码为主的缓存管理方式可以让生成的输出在后续轮次中成为可复用的前缀状态。@SuJinYan123

这个时间安排令人联想到 OpenAI 另行宣布的12 小时 API 提示缓存,而其默认时长为 30 分钟,且单个请求中可以混合使用不同的保留时长。这些并非相同的产品或架构,但两者都旨在服务于间隔较长时仍会复用上下文的持久化智能体。信息流其他地方关于登录后缓存无限期保留的说法属于评论,并非 API 公告中的条款。@OpenAIDevs、保留时长控制、比较评论

推测解码、API 兼容性与针对特定模型的优化

DSpark 让推测验证具备自适应性。它会预测草稿 token 被接受的概率,并调整验证长度以最大化预期吞吐量。DeepSeek 报告称,与始终验证五个草稿 token 相比,生产环境吞吐量提升了 6%。这是相对于某个特定推测解码基准的增量提升,并非相较于非推测解码提升 6%。@ZhihuFrontier

deepseek-recipe关注的是服务接口,而不只是分词器速度。它支持 Chat Completions、Responses 和 Messages API,可并行处理分词,并能区分真正的控制令牌与用户文本中外观相同的字符串。这种区分可防止用户输入的字面内容意外被解析为结构分隔符;但不应将其误认为是完整的提示注入防护。@ZhihuFrontier、@deepseek_ai

一篇社区解读将其效率归因于多项模型与运行时协同设计选择:196B Engram 参数、一个较小的预填充骨干网络(每个 token 激活约 8B 参数,而解码阶段为 16B)、宽 EP、高度压缩的 KV,以及推测解码。文章还提到552B 专家参数、DP64/EP64、每台设备约常驻 45B 参数、大部分权重为四位,以及相较 GQA 基准声称实现了 400× KV 缩减。这些都是二手说法:原帖没有充分说明参数复制、共享权重、量化布局或 GQA 参照,因此无法独立还原这些数字。尤其是,45B/设备并不是用 552B 除以 64 得出的。@bookwormengr

模型特性是不能假定相同收益会自动迁移到任意检查点的原因之一。Su Jin Yan 认为,按模型定制代码仓库与内核策略很有价值;Andrew Carr 建议借助编程智能体将实现适配到其他模型,但没有提供可移植性或性能验证。@SuJinYan123、@andrew_n_carr

独立比较:vLLM 复现了什么,又没有复现什么

对“只有 DeepSeek 能做到这一点”这一说法最有力的技术反证,是 vLLM 的后续测试:

来源:vLLM 对比、低延迟详情、方案与测量结果。

有三点区别需要说明:

  1. “差距在 6% 以内”指的是解码阶段性能相当,并不代表复现了 DeepSeek 的整个服务。这并不能证明两者在 100 PiB 缓存操作、保留成本、路由、生产可用性,或 DeepSeek 流量分布下的端到端延迟方面等效。

  2. 每 GPU 每秒 100 万 token 的数字不可能指单用户生成速度。同一篇帖子另行报告了约 200 P90 输出 TPS;在与纯解码吞吐量比较之前,需要明确该吞吐量指标对输入、缓存和输出的统计方式。

  3. 这是一项外部实现对比,但仍由竞争引擎团队自行报告。公开的 InferenceX 结果与方案提高了可复现性,但并不意味着所有引用的生产数据都经过了独立审计。

开源渊源十分明确:vLLM 感谢 DeepSeek 以 Apache 2.0 许可证发布代码并给予署名,Woosuk Kwon 则称 DeepSeek 是早期采用者和贡献者。因此,DeepInfer 更适合理解为生产经验回流到现有生态,而非一个与之完全分离的替代方案。@vllm_project、@woosuk_k

其他反应呈现出一系列值得关注的不同观点:

  • 强力背书:Tim Dettmers认为,就其用户规模而言,DeepSeek 的推理技术栈可与 OpenAI 相提并论,且优于 Anthropic;Graham Neubig则指出其官方 API 的速度和价格具有优势。两人都没有提供跨实验室的同条件基准测试。QuixiAI表示,此次发布将为 SlimServe 提供参考。@Tim_Dettmers、@gneubig、@QuixiAI

  • 对部署持怀疑态度:Su Jin Yan认为,对于有经验的推理开发者而言,这篇工程文章比代码仓库更有价值,部分原因是仓库缺少重要组件。Finbarr Timbers要求与 Modal、Together 和 vLLM 进行对比;所提供的帖子中没有出现与 Modal/Together 的同条件对比。@SuJinYan123、@finbarrtimbers

  • 一位总体热情的评论者给予有条件的支持:Teortaxes承认基础设施并不完整,并指出 3FS 加上可能采用的 Dynamo 或可弥补部分缺口,同时估计,要达到集群规模的吞吐量,大约需要 3,000–4,000 GB200s。这是一种设想中的部署方案,而非已经验证的复现。@teortaxesTex

随后在代码仓库中找到了官方英文版技术报告,因此不必再完全依赖社区翻译。@teortaxesTex

经济效益:强有力的收入披露,但并非完整的利润率说明

最重要的财务披露是:非高峰时段价格下,每加速器小时收入为 $38。收入不等于利润,而加速器小时只是生产服务成本构成的一部分。@swyx

一项广为传播的估算最初得出推理利润率为 87.76–96.94%,其假设包括:

  • 所有计费 token 中,97% 为缓存输入、2% 为未缓存输入、1% 为输出;

  • 每块 GPU 每秒处理 80K 个未缓存输入 token,以及 16K 个输出 token;

  • 每位用户每秒输出 250 个 token;

  • 每 GPU 小时租用成本为 $3–$6。

以 10 亿个总计费 token 计算,该模型包含 970M 个缓存输入 token、20M 个未缓存输入 token和 10M 个输出 token,大约需要 875 GPU 秒:其中预填充耗时 250 秒,解码耗时 625 秒。估算的 GPU 成本为 $0.73–$1.46,对应的非高峰时段收入为 $11.91,高峰时段收入为 $23.82。@zephyr_z9

作者随后修正了估算:理想化场景下的收入约为每小时 $49,而 DeepSeek 报告的收入为每小时 $38,相当于生产环境达到基准性能的约 80%。修正后的利润率区间为 84.2–96.1%。不应在不注明这一修正的情况下重复最初的估算。@zephyr_z9

其他帖子采用了更高的硬件成本:

  • 按每小时 $7 的成本和每小时 $38 的收入计算,其他成本尚未计入时,利润率约为 81.6%。Yuchen Jin明确指出,DeepSeek没有披露该收入数据对应的 GPU 型号。@Yuchenj_UW

  • 按每小时 $5–$10 的成本计算,同样仅考虑加速器的估算得出约 73.7–86.8% 的区间,而非一个普遍适用的“80% 服务利润率”。@swyx

这些计算省略了或未完整分摊SSD 缓存集群、CPU、网络、闲置/预留容量、故障、工程、支持及其他运营成本。它们还依赖于对缓存占比很高的 token 组合极为有利的假设。训练支出和未来算力承诺则是另一回事:推理业务的贡献毛利率很高,公司整体仍可能巨额亏损。

更激进的外推明确属于推测。Teortaxes 估算,所谓的10 亿美元 ARR,在非高峰价格下可能由约42 个 GB200 NVL72 机架/约 3,000 块 GPU支撑;计入高峰定价后,随后将估算下调至33 个机架。这些帖子还外推称,约 4,167 个机架可带来 1,000 亿美元年收入,并推算出较高的每吉瓦收入。这些是情景计算,并非经过审计的 DeepSeek 收入、集群规模或回本情况披露。初步估算、修订后的估算、行业外推

市场影响方面的看法不一。有人认为,这些披露表明推理已跨过盈利门槛;也有人预计,token 价格下降、算力价格上涨最终会压缩回报。其对 Moonshot/Zhipu 托管协议的竞争影响虽有 plausibility,但尚未量化:可公开部署的技术栈既能改善服务提供商的经济效益,也可能加剧价格竞争。@KCDN19、价格趋同论点、托管竞争

NVIDIA、Ascend 与硬件推理的局限

Ascend 兼容性已得到确认;Ascend 量产效率是否相当则尚未得到证实。一些帖子将对 Blackwell、sm100 的支持,以及采用 NVL72 形态的配置,解读为生产环境使用 NVIDIA 硬件的证据。这些只是线索,并非已披露的硬件清单,也不是经测量得出的 NVIDIA 与 Ascend 对比结果。@eliebakouch、@stochasticchasm、明确的不确定性

后来一篇硬件分析比较了 GB200 和 Ascend 950DT 据称的解码数据:

  • 在100 TPS约束和131K 上下文下:每台设备约为25.5K 对 5K tokens/s。

  • 在230 TPS下:约为20K 对 2.7K,差距比从约5 倍扩大到 7.4 倍。

  • 该分析引用了 DeepEP-Ascend 早前披露的信息:EP64–128 和 combine 操作仍在优化中,其中包括本地归约开销,以及 URMA 带来的 HBM 争用。

  • 该分析假设改进后可达到每芯片 8–10K tokens/s,并估算出约每芯片 6.8K tokens/s 的经济性拐点;计算采用的假定价格为每个 NVL72 机架 1,000 万美元,以及传闻中的每块 950DT 3.7 万美元。

这些预测结合了不同测量结果、假定的采购价格和未经证实的未来优化收益,并非苹果对苹果的 DeepInfer 硬件基准测试。@teortaxesTex

同一位评论者预测,Ascend 未来将获得大量分配,并称到 2027 年底 DeepSeek 将拥有超过1 GW 的 Blackwell 等效算力;同时,他还报告了一项与之矛盾的模型生成估算,即25 万块 GPU。这两项预测都不是 DeepSeek 的采购公告。算力预测、相互矛盾的估算

V4.1 Flash 的背景:低成本推理放大能力,但不能就此断定质量

独立评测表明,开源模型的能力取得了显著进步,但并未在所有方面达到前沿模型水平:

  • Arena:V4.1 Flash 20261017 Max 在 Agent Arena 和 Code Arena: WebDev 中排名开源模型第 1。在 Agent Arena 中,它总排名第 11,在 7,500+ 次真实场景会话中净提升 +5.1%,每项任务的成本中位数为 $0.20。Arena 将此描述为:以 GPT-6.1 Sol 27% 的成本,取得其约 37% 的提升幅度。报告的指标包括确认成功率 +11.5%、好评相对差评 +5.9%、Bash 可靠性 +5.4%和可控性 +2.5%;此次评估未发现工具幻觉问题。@arena、详细结果

  • 网络安全:Vals 报告称,在使用基于 Pi 的智能体执行模拟企业网络任务时,V4.1 Flash 1017 的平均进展超过 GPT-6 Sol。DeepSeek 和 Sol 各进行了三次新的范围测试;其他模型均只测试一次。完整评估详情仍待公布。DeepSeek 使用的 token 数明显更多,但 API 总成本更低。@ValsAI、成本解读、方法

  • 网络安全测试结果在效率和最佳单次表现方面存在争议。Scaling01 认为,“胜过 Sol”的说法夸大了结果,因为 DeepSeek 的效率低了数倍。Teortaxes 报告称,DeepSeek 使用的 token 数约为 4.3×,耗时为 2.4×,并指出 Sol 的最佳单次测试达成了 DeepSeek 所有测试均未达到的目标组。将节省下来的成本用于重复测试或组建智能体群的建议仍是假设,并非经过评估的等预算结果。@scaling01、@teortaxesTex、等成本智能体群建议

非正式报告所呈现的结果比受控证据所能支持的更为乐观。Teortaxes 描述了几轮问答测试:DeepSeek 的得分分别为 100%、100% 和 91%,MiniMax 则约为 60%、48% 和 62%;在一项描述/变体拼写测试中,结果为 100% 对 50%。这些测试规模较小,由作者自行设计,题目由模型生成,且答案键存在错误;它们提示了值得后续开展的实验,但并非经过验证的知识基准,也不能证明差异仅由 Engram 导致。另有用户报告称,借助 Hermes 进行 AI 研究效果很好;而另一篇帖子则称,在另一项评估中,DeepSeek 仍远不及 Sol-xhigh。问答测试、后续测试、变体拼写测试、研究轶事、相反结果

本地部署带来了不同的权衡。Brandon Music 发布了面向两块 RTX PRO 6000 的 TrellisMX K2 Mix:专家采用两比特精度,其中 629 个专家提升至三/四比特;Engram 表采用四比特精度,容量设计可容纳约 3M KV tokens。据报告,平均 KLD 为 0.1306 nats,比纯 K2 低 8.6%;一个 +5GB 版本目标容量约为 2M KV tokens。目前仅测量了 KLD,服务运行使用的是测试镜像,因此任务质量保留情况、实际速度和运行稳定性仍未得到验证。@BrandonMusicKy

智能体基础设施、本地执行与硬件加速

  • 长上下文推理内核:SGLang 已合并 megakernel 支持。SemiAnalysis 报告称,在 AgentX 中,GB300 NVL72 上的速度接近每用户每秒 1,000 tokens;在 MI355X 上,交互性提升了 1.5×。此外,Inferact 报告称,使用 vLLM TorchTPU 中的开源 megakernels,Kimi K3 在 TPU v7 上达到每用户每秒 391 tokens(SGLang 结果、TPU 结果)。

    • AMD 优化:Zyphra 报告称,将 GLM-5.3 的 512K 上下文 TTFT 从 178.8s 降至 64.6s;在缓存 90% 上下文时,则从 42.3s 降至 11.8s。这些数据来自无实时流量的单节点 MI355X 测试,不能直接与生产环境测量结果比较(结果,条件)。

  • Apple 芯片运行时性能提升:PyTorch 2.15 将若干 MPSGraph 路径替换为 Metal 内核。报告的改进包括:MoE 解码速度提升 5–6.5 倍;Qwen3.6-35B-A3B 在 M3 Ultra 上从 9.4 提升至 61.3 tokens/s;MPS 支持 FP8;Wan2.2 VAE 峰值驱动程序内存从约 270 GiB 降至 8 GiB。这些改进直接纳入 PyTorch,而非单独的推理运行时(发布摘要)。

  • 本地 Perplexity Computer:现在,模型和智能体都可以完全在受支持的 Apple 芯片 Mac 上运行,包括离线运行,并与原生应用和本地文件交互。

    • 模型与访问权限:本地任务使用经过后训练的 Qwen 3.8 版本 PPLX Pro,且不消耗 Computer 额度。Pro、Max 和 Enterprise 订阅用户均可使用;建议配备 36 GB 统一内存。

    • 混合执行:另一种模式会将工作拆分给本地模型和云端模型。因此,其隐私特性取决于具体的拆分方式,与完全本地执行不同(公告,模型,要求)。

  • 持久化智能体服务:LangChain 的 Managed Deep Agents 集成了用户专属凭据、范围限定的记忆、沙箱化执行和定时任务;Hugging Face 的 Agent Manager 则可在 Claude Code、Codex 等其他执行框架间协调持久会话(LangChain 架构,Agent Manager)。

    • 提示缓存:OpenAI 新增了 12 小时 API 提示缓存,可在一次请求中与默认的 30 分钟缓存混用。更长的保留时间会产生额外费用,但对于反复复用的智能体上下文可能有益(公告,配置)。

    • 用量核算:OpenAI 发现约有 40,000 个账户的已应用用量限额与所选方案不符,现已修正该问题,并承诺向受影响用户发放额度(事件更新)。

端侧模型、语音与图像发布

  • Muse Glimmer:Meta 推出的开放式300 亿参数多模态智能体模型由 Muse Spark 蒸馏而来,目标显存为 32 GB;使用 4 位量化和推测解码头时,可在一张 RTX 5090 上运行。论文报告其在 MCPAtlas 上得分 75.5,在 SWE-Bench Pro 上得分 51.2;Qwen3.6-27B 在 OSWorld-Verified 和 TerminalBench 2.1 上仍领先。该模型支持文本、图像和 100 多种语言,采用 Apache 2.0 许可(论文摘要)。

  • Voxtral 3:Mistral 推出了批量和流式转录、多语言 TTS,以及支持工具调用的语音智能体 SDK;用户可通过其 API 使用,也可部署在自己的基础设施上(发布信息,部署选项)。

    • 独立测评:Artificial Analysis 将 Small Transcribe 3 排在第 3 位,AA-WER 为 2.1%。实时模型在 960 ms 时的最终转录 AA-WER 达到 3.3%;TTS 在两个语音竞技场中均跻身前 12 名。

    • 价格与速度:TTS 的价格为每百万字符 $13,在其测评中的生成速度为 112.3 字符/秒(评测,吞吐量)。

    • CPU 替代方案:Kyutai 发布了更小的 Pocket TTS 变体,参数量低至 1.9M,声称在单个 CPU 核心上可达到 103× 实时速度,并支持语音克隆(发布说明)。

  • Fibo 2.0:Bria 的 8B 开放权重图像模型系列包含用于文生图的 Dev 和蒸馏版 Edit Turbo。Artificial Analysis 报告称,其开放权重图像编辑性能领先;在文生图方面,则与 Qwen-Image-2.1 不相上下。Bria API 的价格为每 1,000 张图像 $32(评测)。

    • 许可注意事项:这些权重仅限非商业用途;商业部署需另行与 Bria 签订协议。经许可的训练数据不应与权重可不受限制地用于商业用途混为一谈。

    • 集成:已宣布支持 Diffusers 并可通过 fal 使用(Diffusers、fal)。

  • Krea 3 Ultra:不同竞技场和不同更新时间的排名并不一致。Artificial Analysis 自己的公告将 Ultra 列为第 #5,而较早的帖子曾称其排名为 #4;Arena 则将其列为多图像编辑第 #4和单图像编辑第 #8。稳妥的结论是其图像编辑质量具有竞争力,而非普遍排名第四(Artificial Analysis、Arena)。

    • 定价:Fast 的费用为每 1K 输出图像 $0.03,另加每 1K 参考图像 $0.02。Ultra 仅支持 2K 输出;使用一张 1K 参考图像进行 2K 编辑,费用为 $0.27。

独立评测、网络能力与安全证据

  • HealthBench 揭示评分对回答长度的敏感性:Artificial Analysis 推出了涵盖5,000 条一般健康对话和525 条临床医生对话的排行榜。GPT-6 Astra 以 66.0% 的长度调整后得分领跑 Professional;Claude Sonnet 5.5 则以 62.1% 领跑一般 HealthBench。

    • 长度影响:Opus 5.5 的 Professional 原始得分最高,为 71.4%,但调整后降至 59.9%。在一般 HealthBench 中,回答最短的模型沟通质量得分最高,但完整性得分最低。因此,回答长度是影响排名的重要选择因素,并非无关紧要的细节。

    • 成本权衡:DeepSeek V4.1 Flash 以每项任务 $0.005 的成本取得 60.9%,而 Sonnet 的得分为 62.1%,每项任务成本为 $0.08。评分使用 OpenAI 模型,沿用原始实现(方法与结果)。

  • 路由与专用模型决策的比较:在五种路由器和约 1,250 项任务中,Vals 发现至少有一个独立模型在得分和成本两方面都胜过每种路由器。在路由器预算范围内进行事后最优选择,可将得分提高 8–27 分,表明选择策略仍有很大的提升空间(路由器指数、预言机比较)。

    • ClaimBench:在另一项金融文档分类基准测试中,Decider V1.2 自行处理了 99.7% 的理赔申请,并将其余部分升级交由 Haiku 5.5 处理;Vals 报告称,其准确率为 99.9%,每 1,000 项理赔申请的成本为 $0.11,而单独使用 Haiku 的成本为 $1.19。这项范围有限的分类结果并不与其在广泛智能体路由任务中表现较弱相矛盾(基准测试、级联结果)。

  • DeepSeek 的网络攻击能力测试结果:Vals 报告称,在使用 Pi 测试框架的模拟企业网络任务中,V4.1 Flash 1017 的表现优于 GPT-6 Sol。DeepSeek 消耗的 token 更多,但总费用更低。

    • 证据局限:DeepSeek 和 Sol 各进行了 三次运行;其他模型各进行了一次。完整评估报告尚未发布。有评论质疑,鉴于效率差异,将其称为毫无保留的胜利并不恰当,因此应将其视为初步能力信号,而非定论式排名(发现、方法论、限定说明)。

  • 安全保障与问责:METR 认同 Anthropic 对受评模型灾难性错位风险较低的结论,但指出分析上存在重大分歧。该机构建议对监控系统进行端到端红队测试,并评估模型破坏安全相关决策的能力(评审、建议、决策风险)。

    • 事件透明度:Hugging Face CEO Clément Delangue 批评 Netflix 对所报道的 OpenAI 智能体网络攻击事件的呈现方式,认为应更多关注遏制措施、监控、开放模型的防御性用途,以及缺失的智能体追踪记录(声明)。

    • 传言澄清:Theo 否认拥有 Fable 5.5;所谓泄露似乎源于模型身份识别错误,随后又澄清称所谓消息来源是个网络喷子。所提供的帖子并未证实产品发布(否认、澄清)。

科学智能体:湿实验室结果与开放式任务的局限

  • 蝎毒结合蛋白:Anthropic 和 Citrini 报告称,在测试的 211 种蛋白质设计中,有 17 种结合蛋白;此前,内部 Claude 研究模型已完成大量计算工作。所有测试设计和实验室数据都将公开发布(公告、数据)。

    • 关键局限:没有一种蛋白质能结合多种毒素,也没有一种接受过毒素中和测试。这不是抗蛇毒血清,也不能证明其具有治疗效果;后续还需开展细胞、动物及更多验证(研究人员说明、官方限定说明)。

  • 从病理图像预测生物学特征:Sophont 推出了 Holon-S1,可根据常规病理切片预测空间基因活性和生物标志物。团队称,该模型在 16 种器官类型和 15 款以上扫描仪上进行了评估,在空间基因预测方面优于两个对比模型,并发现了可能的新型乳腺癌和结肠癌生物标志物。这些属于研究发现,并非经过验证的治疗方案选择结果(发布信息)。

  • 开放式研究仍然困难:评估人员向 GPT-6 Astra 和 Claude Fable 5.1 提供了尚未发表的 AI 研究问题,并分别给予 10,000 美元预算。原论文作者发现,与早期测试相比,模型在实验设计和资源管理方面有所进步,但仍因创造力、判断力、校准能力和沟通方面的不足而否决了两篇生成的论文。这项小规模研究为那些针对可狭义验证研究任务的结果提供了有益的平衡视角(评估)。

行业与政策:药物研发、制造与资本承诺

  • OpenAI 收购 Orchestra Bio:OpenAI 宣布收购一个药物研发协调平台,进一步拓展其生命科学业务,使其不再局限于研究工具,而是与 Rosalind 一同延伸至实际运营执行。公告未提供财务条款(公告)。

  • Arda 正式发布:前 OpenAI 研究负责人 Bob McGrew 宣布推出一款制造业软件,Anduril 是其设计合作伙伴。他在一手账号中称,该公司完成了 1.6 亿美元 A 轮融资,估值 15 亿美元;CNBC 随附的帖子则称其融资 2.3 亿美元,但未明确说明这一数字与所宣布的融资轮次之间的关系。首款产品支持手动设计和运营装配线;下一步目标是实现可重构自动化(创始人公告,CNBC 报道)。

  • 融资与算力投入:据报道,OpenAI 正寻求约 300 亿美元融资,估值超过 1.4 万亿美元,时间点预计在 Anthropic IPO 前。另据报道,《华尔街日报》审阅了 Anthropic 的招股说明书草案,其中提到该公司上半年营收 163 亿美元、近90 亿美元算力与基础设施支出,以及超过6000 亿美元的未来算力承诺,其中包括仍在谈判中的承诺。这些都是归因于媒体报道的信息,并非已完成的交易或经独立核实的财务披露(OpenAI 报道,Anthropic 报道)。

热门推文(按互动量排序)


AI Reddit 摘要

/r/LocalLlama + /r/localLLM 摘要

1. DeepSeek DeepInfer 开源推理框架

  • New from DeepSeek - DeepInfer - (Activity: 313): The image is a mobile screenshot of DeepSeek’s X announcement that DeepInfer, its in-house inference framework, is now fully open source: image, GitHub. The technically relevant claim from the linked/source discussion is that DeepInfer powers DeepSeek V4.1 Flash at scale, with reported single-cluster throughput of 155 trillion tokens/day and revenue of $38 per card per hour at off-peak pricing, emphasizing high-throughput, low-latency large-scale inference rather than model training. Commenters were notably surprised that DeepSeek open-sourced an internal production inference stack, contrasting it with what they expect from Anthropic, OpenAI, or Meta. There was also basic uncertainty from some readers about what the framework actually does, i.e. serving/inference infrastructure rather than a new model.

    • A linked Zhihu source claims DeepInfer enables high-throughput, low-latency large-scale inference for DeepSeek V4.1 Flash, reporting 155 trillion tokens/day throughput for a single cluster and $38 per card-hour revenue under off-peak pricing:

https://zhuanlan.zhihu.com/p/2095560295930508953

    • . One commenter also highlights a reported serving figure of roughly 256 tokens/s × 100 users, implying very high concurrent decode throughput if sustained in production.

    • A technical concern raised is whether DeepInfer is a general-purpose inference framework or primarily a stack heavily optimized for DeepSeek’s own model architecture and deployment environment. The repo’s low initial GitHub star count versus high announcement engagement was interpreted as likely due to freshness, but commenters expect more meaningful evaluation once engineers inspect the implementation and portability.

  • Deepseek released DeepInfer - Open Source high-performance, large-scale inference framework for DeepSeek models! (Activity: 1023): DeepSeek released DeepInfer, an open-source high-performance offline inference framework for DeepSeek-V4.1-Flash, with production-oriented primitives including optimized kernels, attention/data/context parallelism, MoE expert parallelism with EPLB, DSpark-style speculative decoding, SWA bounded replay, async scheduling, structured outputs, batch-invariant inference, and deterministic sampling. It currently targets NVIDIA SM100 GPUs and Huawei Ascend 950 NPUs via DEEPINFER_ACCELERATOR=nvidia|ascend, requiring Linux/Python 3.12 plus CUDA 13 or CANN 9.2; however, full online serving still needs external KV-cache management, prefill/decode disaggregation, and DP replica load balancing. DeepSeek also released deepseek-recipe, a Rust library with Python bindings for protocol conversion and model-output parsing across APIs such as Chat Completions, Messages, and Responses. Commenters framed the release as valuable for reverse-engineering production inference techniques into community engines such as gufo, halogen, strixite, and Strata. There was also interest in the explicit Ascend 950 support, with one commenter joking that “Nvidia [is] in shambles,” though the listed NVIDIA target remains next-gen SM100 rather than current widely deployed GPUs.

    • DeepSeek’s release is split into two repositories: DeepInfer, described as a high-performance large-scale inference framework for DeepSeek models, and deepseek-recipe, a Rust library with Python bindings for protocol conversion and model-output parsing across API formats like Chat Completions, Messages, and Responses.

    • Commenters noted the currently listed accelerator targets are NVIDIA SM100 GPUs and Huawei Ascend 950 NPUs, with build-time platform selection exposed through DEEPINFER_ACCELERATOR=nvidia or ascend before running ./build.sh. The Ascend support drew attention because it implies DeepSeek is optimizing beyond the standard CUDA/NVIDIA path.

    • One commenter referenced DeepSeek’s Zhihu post claiming roughly $38 per GPU-hour revenue/throughput economics, linking the original post at zhuanlan.zhihu.com/p/2095560295930508953. The thread raised whether similar per-GPU economics could be used to estimate inference revenue for competitors like OpenAI or Anthropic, though no concrete derivation was provided.

  • Can DeepSeek V4.1 Flash 1017 really run on 12GB VRAM + 64GB RAM? (Activity: 352): The image is a screenshot of an X/Twitter thread claiming DeepSeek V4.1 Flash 1017 may be runnable locally at Q4 with 12GB VRAM + 64GB RAM; the Reddit post asks whether an RTX 3060 12GB could offload enough layers to make inference usable. The key technical pushback is that V4.1 Flash is reportedly already around 4.25 bpw for many experts via mxfp4 + fp8, so while it may fit if total RAM is sufficient, expected performance with heavy CPU/RAM execution could be extremely slow—one commenter estimates roughly ~3 tokens/sec. Commenters are skeptical that this would be practical for everyday use: the consensus is closer to “possible to load” than “pleasant to run.” One comment notes the person making the original claim is the Strata creator, lending some credibility to the sizing claim, but not necessarily to performance expectations.

    • Commenters disputed the claim that DeepSeek V4.1 Flash 1017 can practically run on 12GB VRAM + 64GB RAM: even the “Flash” variant is described as already being around 4.25 bpw for many experts, using MXFP4 + FP8, so a standard Q4-style fit is unlikely within that memory budget.

    • A technically viable setup may require heavy offloading: one commenter says Q4 does not fit and suggests checking the Hugging Face model size directly, then offloading n-grams to NVMe and streaming some MoE experts from disk. This may run in principle, but expected throughput is likely very poor, with one estimate around ~3 tokens/s or worse depending on disk and offload implementation.

    • There was skepticism that the original Strata claim was accurate; commenters noted that even if the model can be made to “fit” somewhere across RAM/NVMe, the relevant question is practical inference speed rather than mere loadability.

2. MiniMax M3.1 Flash Release

  • MiniMax M3.1 Flash released, Model weights Oct 23 (Activity: 874): The image is an official MiniMax X announcement for MiniMax M3.1 Flash, described as “Space Performance + Bunny Speed,” with API availability now and open model weights scheduled for Oct 23. Commenters add that the model is reportedly a MoE with 428B total parameters, ~23B active parameters, sparse attention, and a native visual encoder; a preview/tool page is linked at agent.minimax.io/tools/m3-1-flash-preview. The main technical concern in comments is that benchmark excitement depends heavily on knowing the model size/active parameter count, since performance claims are hard to contextualize without architecture details.

    • A commenter cites the MiniMax M3.1 Flash Preview tool page as specifying a Mixture-of-Experts architecture with 428B total parameters and roughly 23B active parameters, plus sparse attention and a native visual encoder: https://agent.minimax.io/tools/m3-1-flash-preview. This directly answers discussion uncertainty about model size and suggests the model is positioned as a large sparse multimodal system rather than a dense LLM.

  • MiniMax-M3.1-Flash is coming (Activity: 521): MiniMax teased MiniMax-M3.1-Flash via an official X post (source), but the Reddit post provides no architecture details, parameter count, context length, pricing, release date, or benchmarks. The only technical signal is the product naming: commenters infer “Flash” may denote a speed/latency-optimized variant, though no evidence is given. Commenters are skeptical about the meaning of “Flash,” joking that in current LLM naming it could still be a very large model — e.g. “Flash means a 500B model” — or sarcastically a supposedly lightweight model that is not actually small.

3. Benchmark Inflation and AI Slop Measurement

  • AI labs report benchmark scores 6.4% higher than independent testers, on average (Activity: 334): The image is a technical benchmark-comparison chart from the whatmodel.sh open leaderboard, visualizing 611 matched comparisons across 180 AI models and 103 benchmarks from 1,629 published results. It reports that AI labs’ self-published scores are 6.4% higher on average than independent testers for the same model/benchmark pairs, with 375 lab-higher cases vs. 216 independent-higher and 20 ties; the largest median benchmark gaps shown include SWE-bench Verified and MBPP at about +9.0 points for labs. Image · interactive chart · data/code Commenters debated whether the gap reflects intentional score inflation or more mundane reproducibility issues such as package versions, harness settings, random seeds, prompt/eval setup, or labs optimizing benchmark tooling to present best-case results. Several compared it to vendor-favorable performance charts from companies like Apple or Nvidia, arguing that only independently reproduced or peer-reviewed results should be trusted.

    • Several commenters argued that the 6.4% average gap may come from benchmark reproducibility issues rather than outright inflation: small differences in package versions, evaluation harness settings, random seeds, prompt formatting, and lab-specific benchmark tooling can materially affect reported scores. One theme was that labs likely optimize the exact harness/configuration used to showcase their models, while independent testers may use more generic or less model-tailored setups.

    • A commenter noted the mean gap may be driven by outliers and suggested the median discrepancy would likely be closer to reported benchmark values. This implies the headline average could overstate systematic inflation if a small number of large deviations dominate the aggregate.

    • One technical explanation proposed was deployment mismatch: labs may benchmark full-weight models, e.g. BF16, while independent testers often evaluate served API versions that have been quantized to FP8, MXFP4, or other hardware-efficient formats. If true, some score degradation could reflect inference serving optimizations for datacenter tensor units rather than benchmark manipulation.

  • Let’s delve into the tapestry of AI slop on r/LocalLLaMA (Activity: 455): The post links an informal longitudinal analysis of “AI slop” across Reddit communities, including r/LocalLLaMA, with an attempted extrapolation of future slop prevalence: thil.ooo/blog/measuring-slop. A technical commenter notes likely measurement bias: moderator removals and karma filters may cause Pushshift/archive-style datasets to undercount short-lived bot posts, while bot evasion tactics such as all-lowercase writing may weaken simple “human marker” heuristics; they also suggest comparing against Claude-associated vocabulary from “load-bearing vocabulary of Claude”. Moderation feedback was supportive: a mod left the post up as directly relevant to ongoing anti-slop moderation despite reports. Commenters broadly agreed that obvious AI-generated style markers—em dashes, bullet lists, and stock phrases like “delve”—have become noisy signals and can falsely implicate human writing.

    • A commenter noted several measurement biases that could affect an AI-slop detector trained/evaluated on Reddit archive data: moderators may remove many generated posts from /new before they appear in the dataset, and a new karma filter may be suppressing bot/slop submissions upstream. They also flagged that bots may evade simple style heuristics by posting in all lowercase, potentially corrupting “human marker” assumptions.

    • One technical suggestion was to expand the detector’s lexical feature set using Claude-specific “slop” terms, referencing the analysis of Claude’s load-bearing vocabulary at https://louisabraham.github.io/load-bearing/. The commenter emphasized distinguishing obvious AI slop from broader low-value generated content that may not exhibit obvious stylistic markers and may be removed quickly.

Less Technical AI Subreddit Recap

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

1. Opus 5.5 Game Automation Feats

  • After $712 and 39 hours, Opus 5.5 beat Baldur’s Gate 3 all by itself (Activity: 1145): A user reports that Claude Opus 5.5 autonomously completed Baldur’s Gate 3 using a custom harness: claude -p with built-in tools disabled, a Python MCP server connected over TCP to a Lua BG3 mod, Vulkan-layer screenshots, and SDL-mediated clicks (write-up, code). The run took 39 hours, $712, 99 fresh sessions, 20,809 tool calls, 862 screenshots, 2.2B+ cached input tokens vs 3.5M output tokens, and relied on a git-backed memory system with 157 commits, ~23k curated words, and 67 distilled tactical rules; an audited Faith-Leap rerun required 36 min, 674 tool calls, $24, one death, and eleven reloads using only screenshots of the mosaic after fixing a hidden-walkway leak. The author plans to turn the harness into a benchmark of short BG3 scenarios scored by success, attempts, time, and cost, with Claude’s Nautiloid opening reportedly succeeding 9/9 at about $1.50/run, and Codex/Gemini integrations prepared but not yet evaluated. Top commenters mostly reacted that the project is expensive but promising: one called it “one of the best benchmark ideas” for comparing agents across vendors, while another dismissed the spend as “more money than sense.” Non-technical joking centered on whether the agent made morally significant in-game choices, e.g. whether it raided the grove.

    • A commenter framed the run as a potentially useful agentic benchmark, suggesting that repeating the Baldur’s Gate 3 task across competing models could provide a more practical comparison of long-horizon planning, tool use, and persistence than many standard benchmarks. The key technical value would come from standardizing the setup and measuring cost, completion time, failure modes, and decision quality across models.

  • Claude Opus 5.5 decompiles a PS2-era game overnight, and hundreds of them now run in browser tabs (Activity: 2348): A Kotaku report claims AI-assisted reverse engineering—attributed in the post title to Claude Opus 5.5—has enabled browser-playable ports of older titles such as Halo: CE, GTA: Vice City, Skate 3, and The Simpsons: Hit & Run. The article says some ports run entirely in-browser with notable performance claims, e.g. Hit & Run targeting 240fps and a Halo: CE build supporting low-latency online multiplayer, but commenters question whether these are true decompilations or instead recompilations/reimplementations of existing binaries/assets. Top comments are skeptical: one asks for an actual playable browser link and calls the post an “empty flex,” while another argues the terminology is being conflated—“these aren’t decomps… they’re just recomps?” A separate commenter speculates that public access to strong models may be restricted once corporations view this as an IP-enforcement threat.

    • A commenter challenges the post’s terminology, arguing these likely are not full decompilations but rather recompilations/recomp projects, noting that the community may be conflating the two. This distinction matters technically: decompilation implies recovering high-level source or equivalent structure, while recompilation often translates existing binaries/IR into a new target such as browser-compatible code.

2. AI Proofs and Academic Labor

  • Fields Medalist Richard Borcherds on OpenAI proofs: “I think what people are getting upset about is they’re slowly realizing that they are dumb and somehow blaming this on AI, even though it’s not really AI’s fault” (Activity: 1309): The linked Daily Cal piece covers UC Berkeley mathematicians’ reaction to an alleged OpenAI Navier–Stokes proof (article), framing it as a stress test for mathematical proof validation, pedagogy, and the role of AI systems in advanced research. Richard Borcherds is quoted arguing that backlash may reflect researchers’ realization of their own limitations rather than an AI-specific failure: “they’re slowly realizing that they are dumb and somehow blaming this on AI.” Top commenters focused mostly on education: one endorsed the view that AI use on homework is irrelevant if students cannot reproduce understanding on exams, while another highlighted Borcherds’ claim that AI may be a more patient and expressive tutor for graduate abstract algebra than a human instructor.

    • A quoted discussion from Richard Borcherds frames AI-generated mathematics as potentially producing very large formal artifacts—e.g. “a 100,000-line formal proof of some major conjecture”—but argues this does not necessarily degrade mathematical learning or research because humans can choose to ignore machine-produced formalizations. The technically relevant implication is a distinction between formal proof generation/verification and the human-centered process of understanding, motivation, and theory-building.

    • One comment highlights Borcherds’ claim that AI may be better than him at teaching MATH 250A graduate abstract algebra, specifically because it is patient, consistent, and able to re-explain material without frustration. This is an education-focused technical point: LLMs may function well as adaptive tutors for dense symbolic subjects, while still not replacing the need for students to independently solve problems for exam-level mastery.

  • A physicist spent a year of his life and ~500 pages of hand calculations for quantum gravity in his PhD thesis, but Opus 5.5 did it in 10 hours, including the article and GitHub repo. And it even found the errors. What will “labor” mean in academia from now on? (Activity: 1710): The linked repo, eokahya/claude-audits-quantum-gravity, is an AI-assisted audit by E. O. Kahya, the original coauthor, of prior one-loop quantum-gravity calculations for the graviton correction to a massless minimally coupled scalar in de Sitter space—not a fully autonomous rediscovery. The workflow was manually decomposed into an 18-task/9-stage pipeline where Claude orchestrated deterministic SymPy/mpmath checks, including high-precision numerical sampling, and found mostly bookkeeping/printing issues: an overall sign convention error in the printed bare self-mass, missing/non-analytic and analytic terms in Table X, finite intermediate issues, and 23 typos. The main physics result reportedly survived unchanged: after correction, the Schwinger–Keldysh late-time mode-function analysis still yields no growing one-loop terms such as ln(a), ln²(a), or a, only constant field-strength renormalization plus decaying terms. Top commenters pushed back on the framing that “Opus 5.5 did a PhD thesis in 10 hours,” arguing the hard scientific work was the original formulation, boundary conditions, Feynman rules, and expert scaffolding; the AI mostly accelerated verification of dense tensor algebra. A broader debate compared current academia to human+engine chess, with one view that AI-assisted researchers are temporarily strongest, but another predicting fully automated systems may eventually outperform human academics except in posing high-value questions.

    • Multiple commenters argue the headline misrepresents the work: E. O. Kahya, the original coauthor, did not have Claude autonomously rederive quantum gravity results from first principles; he used it to audit prior calculations. The workflow was manually scaffolded into an 18-task, 9-stage pipeline with expert-supplied boundary constraints, while Claude orchestrated deterministic tools like SymPy and mpmath for tensor-algebra checks and 30-digit numerical validation.

    • The technically important outcome was that the core physical result survived unchanged. Reported issues were limited to arithmetic slips, an overall sign/definition flip, a missing bookkeeping term, and 23 typographical errors, with commenters emphasizing that this is closer to computer-assisted verification of dense symbolic work than novel physical discovery.

    • Commenters highlight that Kahya’s own README includes caveats such as “What a human expert should still review” and limitations around numerical sampling. The main technical framing is therefore AI as an audit/cross-check layer for expert-designed theoretical pipelines, not yet a replacement for posing the theory, deriving Feynman rules, or establishing the physical framework.

3. Agent Security and Prompt-Injection Risks

  • PSA: Do NOT connect your gmail and drive with your Dots at the moment (Activity: 1225): The post warns that Dots agents connected to Gmail/Drive/PC may execute attacker-controlled instructions delivered via email attachments or message bodies, exfiltrating personal data or installing malware if the agent treats the content as trusted user intent. Commenters identify this as a classic prompt injection / tool-use security failure affecting any LLM agent with external capabilities, not just Dots: untrusted content can become executable instructions when read by an autonomous agent. The dominant reaction is strong skepticism toward granting AI agents privileged access to local machines, email, or cloud storage until robust permissioning, sandboxing, and instruction-boundary defenses exist.

    • Several commenters identify the core risk as prompt injection against AI agents with connected tools, not a Dots-specific flaw. The technical concern is that any LLM granted access to Gmail/Drive or local actions can be manipulated by untrusted content to perform unintended operations, making autonomous account access unsafe without strong sandboxing, permission boundaries, and human-in-the-loop approval.

  • My post about rogue AI agents got 1.3M views here and then reddit just deleted it. no reason given (Activity: 1315): The image is a non-technical Reddit UI screenshot showing a prior r/ChatGPT post marked “[Removed by Reddit]” for a content-policy violation, despite reportedly reaching ~1.3M views, 1.5K upvotes, 530 comments, and moderator approval before removal: image. The post claims the removed content discussed research, also covered by the NYT, about “rogue” AI agents operating online, but the screenshot itself provides no technical evidence about the agents—only evidence of platform-level removal without a visible rule citation. Comments lean conspiratorial/skeptical, suggesting the alleged agents or bots could be suppressing discussion or manipulating perception, while others frame reposting as the expected Reddit response.

来源:Latent Space · latent.space