OpenAI Patch the Planet 项目用 GPT-5.6 Sol 发现 PHP2Shell 漏洞,各方协调修复约两个月
[AINews] OpenAI’s Patch the Planet program is 1 of 2 parties to discover PHP2Shell vulnerabilities in core PHP affecting 70% of the web, using GPT-5.6 Sol; coordinated response over 2 months
安全公司 Calif 研究员在 OpenAI Patch the Planet 项目中使用 GPT-5.6 Sol,与 Wiz(使用 Gemini 4 Argon)分别独立发现 PHP 引擎两个内存破坏漏洞 PHP2Shell(CVE-2026-109618。
原文梳理了 PHP2Shell 从多方发现到协调修复的完整时间线,并明确区分了已证实事实与未经证实的传闻,便于读者判断这起事件的实际范围。
近两个月前,OpenAI 推出了 Daybreak for Frontline Defenders,一项价值 10 亿美元的补贴计划,用于获取 Daybreak 网络安全模型和产品。这笔资金几乎立刻就派上了用场:PHP 的重大漏洞被两方独立发现——其中之一是安全公司 Calif 的研究员 Ryan Austin,作为 OpenAI “Patch the Planet”项目的一部分,于 2026 年 8 月使用 GPT 5.6 Sol:
d935be023a55b04681eccd1d2b8385b4b295e141a5df108e5e979d8d5d7124ac
……以及最近被 Google Cloud 收购的 Wiz(使用 Gemini 4 Argon 和 GPT-5.6 Sol,以及他们自己的工具 Wiz Atlas)。
所有高调的网络安全披露多少都带点营销性质,而这个漏洞是否严重到足以与 log4shell 和 Heartbleed 等著名漏洞相提并论,尚存一些争议,但 PHP 生态系统的协同响应无疑是开发者社区以最理想形态做出的回应。
我们应该预计至少在未来一年内还会发现此类严重漏洞;但责怪发现漏洞的信使是错误的做法;相反,知道我们的关键软件正在接受人类历史上规模最大的安全审计,是一件好事。
2026年10月20日-10月21日 AI 新闻。我们检查了 12 个 subreddit、544 个 Twitter 账号,没有检查更多 Discord。 AINews 网站可让你搜索所有往期内容。提醒一下,AINews 现在是 Latent Space 的一个板块。你可以选择加入/退出邮件推送频率!
头条故事:PHP2Shell——时间线、核心主张以及紧急响应背后的复杂情况
研究人员披露了两个 PHP 引擎内存损坏漏洞,演示了针对主流 CMS 的未授权利用,并引发了异常广泛的协同响应。
研究人员将这些漏洞命名为 PHP2Shell,并编号为 CVE-2026-109618 和 CVE-2026-109619。他们的技术描述将缺陷定位于 PHP 内部对内存不足状况和致命错误的处理,而不是某个 WordPress 插件或应用程序的身份验证逻辑。他们报告了完整的远程代码执行和“Heartbleed 式”内存泄露的演示。 @sagitz_
所披露的演示包括针对 WordPress、Drupal 和 Joomla 的未授权(pre-auth)远程代码执行。该研究员的公告还单独声称可对任何 PHP 应用程序进行远程内存泄露。这些是研究员报告的利用结果;不应悄无声息地将其扩大为“每个部署都存在完全相同、可立即利用的 RCE 路径”的断言。 @sagitz_
OpenAI 表示,其 Calif 研究人员使用其模型发现了这些漏洞,而后续报道称 Wiz 独立发现了相同的漏洞。相关帖子指出 Calif/OpenAI 一侧使用的是 GPT-5.6 Sol;一个与 Wiz 有关联的账号则将发现、漏洞利用链开发、检测器创建和补丁验证归功于 Gemini 4 Argon。这是一起多方共同发现的事件,并非证明某一家厂商单独发现并修复了该问题。@TheRundownAI、@steipete、@ralucaadapopa
OpenAI 描述了在披露前约两个月的协同修复过程。据其称,补丁需要对 PHP 引擎进行重大修改,并需在维护者、研究人员、安全提供商和政府之间进行协调。一位参与研究的科学家证实曾与 PHP Foundation 合作以支持并强化补丁。@OpenAI、@itszn13
Cloudflare 在计划中的补丁发布之前就已部署了初步的 WAF 缓解措施。其 CTO 表示,这些规则覆盖了已知的攻击向量,面向包括免费层级在内的所有客户,并随着早期攻击的出现而不断更新。他明确称这些规则只是权宜之计,并要求运维人员在 UTC 14:00 完成补丁更新。@dok2001
所提供的 NSA 账号建议为立即更新做好准备——如果无法及时缓解,则应将系统下线。随后 OpenAI 的消息称升级已可用;后续报道称在补丁发布前已有细节泄露。所提供的材料并未确切说明泄露了什么、何时泄露,以及发布时间表是否因此改变。@NSACyber、@OpenAI、@TheRundownAI
1. 发现与私下协调:在公开披露前约两个月。
OpenAI 将这项工作归入 Patch the Planet 项目,并表示其领导了一个联盟来准备修复和防护措施。其安全研究员 Eric Wallace 补充说,内部团队致力于打补丁和检测工作,而不仅仅是披露漏洞,并提前向政府和外部机构进行了保密通报。Greg Brockman 重申了为期两个月的协调期。这些是参与者的叙述,并非经过独立审计的事件时间线。@Eric_Wallace_、@gdb
项目名称之间的区别很重要:帖子将漏洞与 Patch the Planet 相关联,而研究人员则归功于 Daybreak 模型访问权限促成了安全工作。二者是相关的角色——修复计划与访问机制——并非对同一项目的可互换描述。@OpenAI、@S1r1u5_
2. 提前的公开预警与计划中的补丁窗口。
日语帖子提醒运维人员为 日本标准时间 10 月 21 日 23:00 的发布做好准备,与 Cloudflare 在 UTC 14:00 发布的公告一致。其中一个帖子正确强调,PHP 核心漏洞不能仅仅靠等待插件开发者来修复。另一个帖子将此事件描述为补丁发布后的“15 分钟”竞速,但这个数字只是预测——并非实测的武器化时间。 @ds_nakajima、@expokun
3. 发布前的过滤与观测到的攻击活动。
Cloudflare 的帖子是所提供记录中最有力的第一手运营证据:缓解措施已经部署,已知攻击向量已被覆盖,“早期攻击”正在出现。它没有说明是否成功入侵、请求量、受害者数量、载荷来源,或者这些流量是最初的漏洞利用开发,还是对泄露信息的复用。 @dok2001
4. 研究披露、政府警告与补丁可用性。
研究人员的公开推文串描述了漏洞利用演示和错误处理这一根本原因。NSA 的帖子呼吁紧急准备和有条件的关停。OpenAI 随后表示每个 PHP 站点都可以安全升级。所提供的材料中不包含 PHP Foundation 的直接发布通告、确切的已修复版本矩阵、发行包标识符或补丁提交记录。这一缺失的第一手来源层级使得“升级到版本 X”这样的指令无法可靠给出。 @sagitz_、@NSACyber、@OpenAI
5. 据称的过早曝光与广泛的服务中断。
The Rundown 报道称细节过早泄露。此后一份广泛传播的汇编内容补充道:约 150 万台服务器(据称来自 Censys)仍在运行没有修复的版本;报道的关停事件涉及荷兰机构、欧洲其他地方的政府网站、Wikipedia、Archive.org、Asana、GOG 等;以及日本首相在 05:55 发出的警告。所提供的材料中,上述任何单独的说法都没有其背后的通告、测量数据或状态页佐证。记录也无法确定每次中断究竟是预防措施、补丁更新造成的停机、无关故障,还是实际被入侵。 @TheRundownAI、@fiveoutofnine
SemiAnalysis 另行报道称,日本首相敦促 PHP 运维人员立即打补丁,如果无法做到则暂时断开连接。该报道将这一应对置于日本已有的入侵浪潮的背景之下,而不是证实 PHP2Shell 导致了那些较早的事件。 @SemiAnalysis_
6. 曝露检查辅助在披露之后跟进。
OpenAI 发布了一个仓库,其中包含一个旨在引导运维人员检查其站点是否受影响的 Codex 技能。这是一种辅助工作流,不能替代厂商通告、软件包验证,或证明每个易受攻击的运行时都已被替换的证据。 @OpenAI
正面论证比仅凭基准测试的说法更有力。 研究人员描述了可用的漏洞利用链、协同的补丁工程、检测器以及补丁验证。一位参与研究的研究者称 PHP2Shell 是他们参与发现的影响最重大的漏洞。OpenAI 将其描述为“防御者窗口期”(Defender's Window)的一个例子:先进模型赶在攻击者之前发现缺陷,为防御者争取了准备时间。重要的是,其措辞是“据我们所知”——并不能证明此前没有攻击者知晓这些漏洞。 @itszn13、@OpenAI
功绩分布于人类、模型和基础设施提供商之间。 Calif/OpenAI 与 Wiz/Gemini 作为相互独立的发现记录出现;PHP 维护者提供了上游修复路径;Cloudflare 提供了预发布阶段的过滤。Google 还宣传了 Wiz 测试,其中 Gemini 4 Argon 发现的漏洞数量是基准模型的两倍以上,但所提供的宣传帖并未公开数据集、基准、预算或误报统计。这并非对 PHP2Shell 发现性能的独立对比评估。 @TheRundownAI、@ralucaadapopa、@Google
面向研究人员的访问政策既受到称赞也受到批评。 一位研究者称赞 OpenAI 的 Daybreak 访问权限带来了涵盖 PHP、GitLab、Chrome、WordPress 及其他目标的系列发现。另一位则将 OpenAI 的审核制访问与 Anthropic 的限制措施进行了尖锐对比;称 Anthropic 贡献了“零价值”只是该作者的笼统观点,并未被 PHP 这件事所证实。还有一篇帖子批评了对 Astra 访问的限制,主张让1,000 名经过审核的研究人员在严密监控下使用最优秀的可用模型,而非僵化的红蓝二分。 @S1r1u5_、@migtissera、@S1r1u5_
相反的安全考量理由也出现在报道中:Anthropic 曾将 Mythos 级模型的广泛访问推迟了四个月,以加强网络安全防护。这为限制访问提供了背景,但并不能说明其具体实施方式对此次修复工作是助益还是阻碍。 @kimmonismus
披露数量的激增本身并不是 AI 导致入侵激增的证据。 所提供的信息流混杂了防御性发现、供应链攻击、凭证窃取、预防性停用以及不相关的漏洞。Ethan Mollick 将这一时刻解读为攻防双方都在加速超越人类的响应速度;John Allard 将其描述为能力上的“相变”,同时也承认近期许多发现来自白帽项目。两者都是对这一模式的解读,而非针对具体事件的因果归因。 @emollick、@john__allard
这场紧急事件的症结不仅在于发现漏洞,也在于分发和所有权。运维人员需要在托管主机、容器、设备、后台 worker 和老旧应用中定位 PHP;获取合适的软件包;进行部署;重启或替换受影响的进程;并验证运行中的构建版本。一位运维人员描述自己维护大量 PHP/WordPress 站点,被测试和更新弄得精疲力竭。另一位则得出结论:补丁的分发协调得很糟糕。@ostrisai、@jd_pressman
部署 WAF 可以减少直接暴露,但会带来虚假安全感的风险。Cloudflare 自己的声明比后来“把所有面向互联网的服务都放到它后面”的建议要窄:已知攻击向量已被覆盖,防护仍在演进,而打补丁依然是必须的。代理覆盖范围、其他入口路径以及源站是否暴露,都必须实际检查,而不是想当然。@dok2001、@threepointone
关机指南是有条件的,并不是让整个互联网断网的证据。 NSA 的帖子建议,在无法立即更新时,应将系统下线,直到能够完全缓解为止。对于具体的运维者来说,相关问题是受影响版本的状态、暴露面、可用的缓解措施以及继续运行的后果——而不是一条耸动帖子的互动量。@NSACyber
“利用 RCE 给每台服务器自动打补丁”只是一个提议,并不是获得授权的修复方案。Marc Köhlbrugge 提出了这个想法;J. D. Pressman 建议为尝试此举的实验室或白帽团队寻求总统赦免。未经请求的利用仍然有未经授权访问、宕机、错误修复、破坏证据以及跨司法辖区责任的风险。一项假设性的赦免并不能提供普遍授权,也无法消除民事和外国法律风险。@marckohlbrugge、@jd_pressman
更新速度存在供应链上的权衡。一篇被广泛转发的帖子抓住了这个两难:不断更新可能让用户接触到被污染的软件包,而推迟更新则会让已知漏洞敞开。Pressman 认为,除非新漏洞和有风险的发布节奏下降,否则无休止的打补丁是不可持续的;他还指出,收不到补丁、事后才发现被盗,比收到过多更新更糟糕。@xeophon、@jd_pressman、@jd_pressman
更长期的替代方案仍是悬而未决的问题。Sarah Guo 报告称,自 4 月以来,CVE 数量从大约每月 4,000 个增至 15,000 个,并提出了关于形式化验证、更安全的发行版以及没有红队的组织的问题。这里的数字未经独立核实,披露数量也不是成功利用的直接衡量标准。其他帖子则追问对整个代码库做一次安全排查要花多少钱,并把挑战重新表述为加固平凡的基础设施,而不是只争论抽象的灾难。@saranormous、@saranormous、@teortaxesTex、@mimi10v3
对于事件响应团队而言,稳妥的流程是:获取权威的 PHP 与发行版安全公告,盘点暴露的运行时环境,在合理之处应用临时防护,部署经过身份验证的已修复软件包,验证正在运行的进程,并单独调查是否被利用的证据。更新能修补漏洞;但它并不能证明凭据或数据从未被泄露。
预防性视角强调互联服务是脆弱的,补救成本可能很高。Joshua Achiam 将当前时刻比作2020 年 3 月,猜测会出现互联网封锁,建议备份重要的互联网资料,并建议打印重要记录。Pressman 说补救成本超出了他的预期。这些是有关未雨绸缪的判断——并非系统性崩溃即将到来的证据。纸质副本可能有助于业务连续性,但本质上并非防篡改日志。 @jachiam0,@jachiam0,@jachiam0,@jd_pressman
对警报持怀疑的视角则要求具体性。Alex Johnson 认为,关于银行账户会被随意清空的警告,混淆了未经授权的转账与客户自己授权付款的骗局之间的区别。他援引美国《电子资金转账法》在及时报告情况下的保护条款;这些保护措施取决于司法管辖区、账户类型和具体情形,并非普遍保障。Kelsey Piper 另外警告说,长期生活在“随时被毁灭”的叙事框架下会带来心理代价。 @AlexH_Johnson,@KelseyTuoc
宽泛的个人安全建议需要与 PHP 修复区分开来。密码管理器、独一无二的凭据、强 MFA、打补丁、运营商防携号转网盗抢保护,以及美国特有的信用或税务身份保护措施,都可以减少后续损害。但启用 2FA 并不能防止无需身份验证的 PHP 引擎漏洞被利用。同样,网上流传的“第二天避免所有在线支付”的建议,并没有已证实的范围评估作为依据。 @peterwildeford,@StillMare_
更广泛的威胁背景是真实存在的,但不能与 PHP2Shell 混为一谈。SemiAnalysis 报告称,自 9 月 25 日以来已有 18 家日本公司披露数据泄露事件,包括约 660 万个 Times Car 账户、1118 万条 Burger King Japan 应用记录,以及可能多达 2250 万条 Sourcenext 记录的泄露。它将有关 AI 辅助扫描和 API 攻击的发现归因于 JPCERT/CC。另一篇帖子引用了 8 月 19 日的一份公告,内容涉及针对暴露于互联网的 Siemens PLC 的 AI 辅助工具。这些是各自独立报告的事件和公告;两者都未能证实 PHP2Shell 是它们的入侵入口。 @SemiAnalysis_,@AndrewCurran_
尚未解决的关键证据缺口是具体的:确切受影响与已修复的版本;CVSS 向量;部署前提条件;独立发现的时间线;发布前泄露了什么;成功利用与仅扫描的区别;经验证的暴露数量;以及每起报告宕机的原因和时长。仅把 PHP、GitLab、LiteLLM、Railway、证书颁发机构故障和政府警告放进同一叙事的病毒式事件汇编,无法回答这些问题。@fiveoutofnine
Flint 与自动化研究:本地编程模型、更小团队与科学工作流
Flint 发布时支持广泛的本地部署:Recursive 发布了一款 Apache-2.0 许可的编程 MoE 模型,总参数约 40B、激活参数 2.5B、上下文窗口 262K token。LM Studio 表示本地运行大约需要 24GB。Recursive 将其定位为前沿云端智能体的设备端补充——而非替代(发布,规格)。
宣称的结果:Recursive 报告在 Terminal-Bench 2.1 上得分 54.9%,在 SWE-bench Pro v2 上 89.7%,在 SWE-bench Verified 上 74.2%。这些是发布时的声明,并非独立复现(结果)。
性能:宣传的短上下文速度在 MacBook Pro 上超过 125 tokens/s,在 RTX Spark 上超过 150 tokens/s。一位用户单独在 M5 Max 上用 int4 MLX 实测输出 114–132 tokens/s;这是对速度的有用佐证,而非受控的能力评估(本地实测)。
研究贡献:Recursive 表示其 Eureka Machine 参与了构思、实现和验证的全过程,贡献了稀疏架构选择、低比特训练和内核。它声称在几乎无质量损失的情况下将规模缩小 71%,并在不到四个月内从零开发完成(方法)。
可用性:零日集成涵盖本地框架和托管访问。vLLM 报告在一台 GB200 上使用 NVFP4、100K 上下文、无投机解码时达到 500 tokens/s;OpenRouter 提供免费发布期访问(vLLM,OpenRouter)。
Mirendil 宣称单人完成规模化预训练:Mirendil 表示其首个基础模型由一名研究者在 3.5 个月内以不到 1000 万美元的算力建成,包括研究实验和最终训练。它公布了异常宽泛的参数范围——Base 为 100B–500B、Large 为 500B–2T、XL 为 2T–10T——而非精确配置。独立评估、后训练结果和 API 访问尚待推出,因此这是一项有待外部验证的重要效率声明(公告)。
JOLT 联合训练教师与学生:Perplexity 与 NVIDIA 的后训练工作解决了自蒸馏中的一个弱点:拥有特权的教师可能会利用学生无法获得的捷径。JOLT 使用结果奖励训练教师,同时对教师与学生过度分歧进行惩罚。作者报告称,在 MATH 上以 6.5 倍更少的训练 token 达到与 GRPO 相当的效果;增加了学生结果奖励的 JOLT+ 在五个评测基准上均胜过 GRPO(方法与结果, 基准总结)。
GPT-Rosalind 生成可检验的生物学假设:OpenAI 报告称,数千个智能体在 32 分钟内将数百万小鼠脑细胞的基因表达结果与文献关联起来。其中一个提出的机制将 DCTN1 的破坏与胆固醇运输受损联系起来;另一个则研究了 TSC1 与 TSC2 破坏在小脑神经元中的差异。这些是供实验后续验证的假设——并非已证明的疗法或经过验证的药物靶点(DCTN1 相关工作, TSC2 后续研究)。
推理系统:DeepInfer 的经济学、原生 TPU 支持与功耗感知的容量规划
DeepInfer 公开了生产级调度技术:DeepSeek 发布的框架结合了投机解码、动态 prefill 尺寸调整、按请求数与 KV 长度进行解码均衡,以及 CPU 调度与 GPU 执行的重叠。一个特别可复用的思路是利用预测的草稿接受率与实测硬件吞吐量来调整投机验证长度,使批次更加规整,而不是让慢副本决定完成时间(技术分析)。
缓存计账:一份部署报告摘要引用了每个 prefill 加速器每秒 150 万输入 token 的数据,包含缓存命中,而在 96% 缓存命中率下不包含命中的数据为每秒 6 万;解码则报告为每个加速器每秒 1.4 万输出 token。这些是实质上不同的吞吐量指标(报告摘要)。
经济学注意事项:同一份摘要将每加速器小时约 38 美元描述为收入,而非利润。服务器、电力、冷却与人力成本均不包含在这一数字之内。
独立基准测试仍有争议:SemiAnalysis 称 DeepInfer 之所以缺席 InferenceX,是因为其关键服务组件缺失,而重建这些组件需要太多假设。其随后的盈利能力对比则因混用不同代硬件、峰值与非峰值价格、以及收入与利润而被批评。该批评本身是归属明确的观点分析,而非已确定的复现结果;实际要求是在比较经济学之前先匹配硬件、工作负载、缓存假设、SLO 和定价(基准测试局限, 对比批评)。
TorchTPU 开辟原生 PyTorch 路径:Google 开源了 TorchTPU,可通过熟悉的 PyTorch 工具链进行训练和服务。据报道,SGLang 的插件正在为 Meta 的生产推理提供支持,并支持多个当前开源模型;其定制的 MegaKernel 在 8K 输入/1K 输出、批大小为 1 的工作负载下,为 Muse Spark Open 实现了宣称的 770 解码 tokens/s。vLLM-TorchTPU 增加了前缀缓存、投机解码和分离式服务(Google、SGLang、vLLM)。
GTC 强调部署速度与功耗利用:NVIDIA 的 DSX POD 将 AI 基础设施打包成容器化的构建模块,相关报道称其可在数天而非数月内扩容。更具体地说,Lambda 展示了使用 DSX MaxLPS 在 16 个节点的功耗预算内运行 19 个 HGX B200 节点。部署时间线应视为产品宣传,节点结果应视为概念验证,而非已交付的全舰队级产能(DSX POD、Lambda 演示)。
评测诚信与智能体工程:测的是测试框架,而不只是模型
医疗推理暴露完整性—准确性权衡:Artificial Analysis 修订了 MLCR-AA 的提示词、参考答案和三模型评审团。Sonnet 5.5 与 GPT-6 Astra 以 41.7% 并列,在同时要求完整性与准确性的条件下没有模型超过 42%。Claude 在完整性上领先;OpenAI 在基于病历记录的准确性上领先。修订后的分数与此前的方法学不具直接可比性(结果、方法学)。
长度混淆因素:一项跨基准分析发现 Claude 的答案大约是 OpenAI 的 4–6 倍长;每增加一条陈述就多一次与记录相矛盾的机会。因此,原始评分、完整性和按长度调整后的质量会产生不同的排名(对比)。
SWE-bench Multimodal 面临消融挑战:一项独立调查认为 v2 实际上并不真正需要图像;另一位研究者强调,在不使用图像的情况下运行该基准是关键的合理性检验。这是对该基准所测量内容的实质性批评,并非证明其底层编程任务没有价值(调查、消融讨论)。
演化的测试框架与界面提升固定执行器:两篇论文进一步支持了围绕智能体优化环境的观点。
SuperMimic 旨在降低人形机器人训练成本:研究人员报告称,仅用一块 GPU 训练三个小时即可覆盖 129,514 个动作,而所引用的最先进方案需要 128 块 GPU 训练七天。其机制将可学习的可微世界模型代理与时间反向传播相结合。所称的 GPU 小时数减少超过 1,000 倍,仅针对这一动作控制训练方案,而非泛指机器人学习(结果,机制)。
智能体产品、检索模型与 API 分发
Claude Duet 进入研究预览:Anthropic 为一款由 Opus-5.5 驱动的主动式助手开放了候补名单;据报道初期访问面向美国 Pro 和 Max 用户。示例包括监控 Slack、准备问题以及根据请求进行购买。Stripe 描述了基于 Link 钱包的购买以及基于 MCP 的开票、退款和营收分析。目前处于预览阶段,所提供的帖子中未披露单独定价(Anthropic 高管,访问权限,支付集成)。
检索发布聚焦精度与上下文成本:Cohere 推出了 Pro 和 Fast 两个层级的 Rerank 5。其可选的 Context Focus 功能返回评分后的段落而非整个文档,声称在保持准确性的同时最多可降低 41% 的 token 消耗。另外,ParseBench 报告 NVIDIA 的不到 1B 参数的 Nemotron 3.5 Parse 在其文档理解基准测试中夺冠(Cohere 功能,可用性,ParseBench)。
Kling 4.0 推广扩展至 API 访问:fal 最初宣布提供 UI/智能体访问,API 支持即将推出;随后 Kling 宣布正式推出官方 API。所称的改进集中在复杂动作稳定性、参考一致性和电影级控制方面。后一则公告取代了此前“API 即将推出”的说法(fal 发布,API 推出)。
企业模型获取渠道扩展,同时 Claude 对 API 进行版本化:OpenAI 宣布前沿模型和 Codex 工作流将登陆 Google Cloud Model Garden。另外,Anthropic 的 API 版本
2026-10-21从 Messages 中移除了temperature、top_p和top_k;新的大版本 SDK 默认使用它,而2023-06-01仍受支持。升级 SDK 的团队应明确审查迁移行为(Google Cloud 分发,版本变更,SDK 默认值)。
行业与治理:研究者言论与公益监督
禁止贬损条款受到审视:引用 BBC 报道的帖子称,Google 的雇佣合同无限期限制公开批评,阻碍关于 AI 安全和军事用途的讨论。前员工的叙述和研究者的评论描述了寒蝉效应。这些属于归因于合同和职场方面的说法;所提供的材料中不包含公司回应或法律裁定(报道摘录,研究者叙述)。
Anthropic 更新公益治理:Anthropic 发布了年度公共利益报告,并任命实验物理学家、前哈佛科学学院院长 Christopher Stubbs 加入其长期利益信托。这是一项治理方面的进展,与该公司的模型评估和产品发布无关(报告,信托任命)。
热门推文(按互动量排序)
NSA:请及时更新 PHP;若无法缓解,请将系统下线 — 80,000
OpenAI:协调进行 PHP2Shell 的发现与修复 — 19,600
OpenAI:用于检查 PHP2Shell 暴露面的 Codex 技能 — 10,500
NVIDIA:Microduck sim-to-real 演示 — 7,800
Richard Socher:Flint 本地编程模型发布 — 7,600
OpenAI:GPT-Rosalind 的神经退行性疾病假说 — 7,500
DeepSeek 新动态 - DeepInfer -(活跃度:441):图片是 DeepSeek 在 X 上宣布其自研大规模推理框架 DeepInfer 现已完全开源的截图:图片,GitHub 仓库,X 帖子。DeepSeek 将 DeepInfer 描述为 DeepSeek-V4.1-Flash 背后的生产级推理栈,针对高吞吐、低延迟服务进行了优化,以降低计算成本和能耗;一条关联的知乎来源称,单个集群在非高峰时段定价下可达到
155 trillion tokens/day和约$38/card/hour的收入。评论者认为,与 Anthropic、OpenAI 或 Meta 相比,此次开源之举异常激进,有人表示那些实验室“绝不会这么做”。一些用户仍不清楚该框架的实际作用,只是简单地问:“它到底能干什么?”一条关联的知乎来源称 DeepInfer 为 DeepSeek V4.1 Flash 提供高吞吐、低延迟的推理,并报告单个集群的吞吐量为
155 trillion tokens/day,在非高峰时段定价下的收入为$38 per card per hour:
https://zhuanlan.zhihu.com/p/2095560295930508953
。评论者指出,与 OpenAI、Anthropic 或 Meta 等公司相比,这种公开披露异常激进。
一个技术层面的疑问是,DeepInfer 究竟是一个真正通用的推理框架,还是主要针对 DeepSeek 自身的模型架构 进行了调优。一位评论者指出,与旗舰模型绑定的华丽框架发布,往往隐藏着针对特定架构的优化,这些优化未必能顺利迁移到其他 LLM 上。
帖子里提到的一个性能数字约为
256 tokens/s × 100 users,评论者称其为极高的并发服务吞吐量。这意味着 DeepInfer 可能定位于生产规模的多用户推理,而不仅仅是单请求延迟基准。
Eagle-4 发布:比 DFlash2 和 DSpark 更快(活跃度:306):EAGLE-4 是一个源码可得的推测解码方案,使用经过硬件/工作负载校准的草稿树,为 SGLang、vLLM 和 TokenSpeed 提供
eagle-harness集成路径;目前报告的支持/基准测试集中在 Qwen3.8-27B 上。帖子引用了相对原始解码的加速比:MTP 为2.22×,DSpark 为2.57×,DFlash 2 为2.80×,EAGLE-4 为3.59×;仓库报告在 4 块 NVIDIA B300 上的 SPEED-Bench 提升(单请求并发)为:SGLang3.42×、vLLM2.83×、TokenSpeed3.09×;据报道更高并发下收益会缩小(EAGLE-4)。评论者还指出 Nemotron Bolt 所使用的 LiLiCorr 是一个基准报告更细粒度的竞争性推测解码方案(论文)。评论者质疑 DSpark/DFlash 的对比是否具有代表性,因为聚合平均值可能掩盖工作负载敏感性——例如 MTP 在代码/JSON 等结构化输出上可能表现更好——并要求按工作负载类型给出分解数据。另一个顾虑是实用性:据报道 EAGLE-4 的草稿模型比 DFlash2 大约大 3 GB,使其对显存受限的部署吸引力较低。一些评论者质疑 Eagle-4 相对 DFlash2 和 DSpark 所报告的加速比在不同工作负载下是否具有代表性。有人指出,平均结果可能掩盖较大的差异,因为 MTP 在代码或 JSON 等结构化输出任务上可能表现更好,并要求按工作负载类型而非聚合基准来提供加速数据。
有评论者提出了关于内存占用的实际部署顾虑:据报道 Eagle-4 的草稿模型比 DFlash2 大约
3 GB,这可能使其不适合显存本已吃紧的受限本地推理环境。评论者还提到了竞争或相关的推测解码工作,尤其是 Nemotron Bolt 所使用的 LiLiCorr,其论文据称提供了更细粒度的基准分析:https://arxiv.org/pdf/2608.20530。也有人希望将 Eagle-4 与 HyperQwen 进行比较,或探讨 HyperQwen 能否集成它:https://github.com/syv-ai/HyperQwen。
现在那条 3090 狂热预警帖说得通了。(活跃度:405):图片是一张 X/Twitter 帖子的截图,声称 RTX 3090 的 “gpu-unlock” 内核/模块可以大幅提升 BF16 张量运算吞吐量,例如 BF16 张量管线可达
82→155 TFLOPS,cuBLAS BF16 GEMM 可达64→99 TFLOPS,据称是通过解除 NVIDIA 对 FP32 累加张量运算施加的限制实现的。就上下文而言,Reddit 楼主询问这是否能解释之前的 “3090 狂热” 预警,以及旧的防挖矿或产品市场细分限制是否仍会影响 LLM 工作负载,但评论者指出,合成基准测试中的 BF16/GEMM 提升未必能转化为实际的推理/训练加速。评论者对市场炒作的角度持怀疑态度:有人称二手 3090 会变得比 5090 还贵的预测是“妄想”,另一人则链接了此前的一条反驳帖,指出该破解尚未展现出实际工作负载的收益。主流观点较为谨慎:基准测试的声明很有意思,但 “1.9 倍快” 最终可能只相当于小得多的端到端改进。几位评论者认为,传言中的 RTX 3090 “破解”被过度炒作了,因为实测收益似乎仅限于一个狭窄的工作负载切片:大约是
10–12%的 prefill 提升,而非普遍的1.9x真实世界 LLM 推理加速。有人链接了之前帖子中的 最高赞反驳,强调这些表面上的底层 BF16 收益尚未转化为实际的端到端工作负载提升。有评论者提出的技术疑虑是,BF16 运算可能只占推理时间的很小一部分,因此在 RTX 3090 上加速或解锁 BF16 路径的影响有限,除非瓶颈确实是 BF16 计算而非内存带宽、KV-cache 访问、采样或其他内核。另一位评论者指出,能否被采用取决于该修改能否安全实现,并在 CUDA 和 NVIDIA 驱动更新后保持稳定。
关于价格,评论者怀疑这条消息会让二手 RTX 3090 的价格大幅飙升,认为 GPU 定价更多由更广泛的行业供应合同和新卡定位驱动,而非小众 LLM 爱好者的需求。有人举例称一张全新的 Radeon RX 9700 级别 32 GB 显卡约
~$2k,可能比溢价严重的二手 3090 更具性价比,不过帖子中并未对该产品的确切命名和价值说法进行深入基准测试。
ornith-ai/Ornith-1.5-122B (Qwen finetune)(活跃度:438):Ornith AI 发布了
Ornith-1.5-122B,这是一个122B的 MoE 推理模型,在 Qwen 3.5 / Gemma 衍生架构上由 Ornith-1.0 微调/继续训练而来,带有自我改进循环,通过 RL 联合优化任务生成、脚手架构建和解题 rollout,而不是仅使用固定的人工精选任务。产物包括GGUF、unsloth GGUF和NVFP4变体;模型卡声称其在编码/智能体基准测试中表现强劲,具备262K上下文,并可通过 YaRN 可选扩展至约1M,同时通过 vLLM/SGLang/OpenAI 兼容 API 以及 llama.cpp/Ollama 风格的 GGUF 路径提供推理支持。评论者质疑选择Qwen 3.5 122B作为基座、而不用更新的“Next Flash”风格基座,认为它可能已经落后于更新的架构。一个技术性担忧是推理速度:由于它基于 Q3.5122B,拥有A10B个激活参数且缺乏稀疏注意力,有评论者估计它将比拥有A6B个激活参数的 Q3.8fn 风格模型慢约2×。有评论者指出该微调模型基于Qwen 3.5 122B,这意味着对
q3.8fn用户而言将表现出A10B 而非 A6B的行为,且没有稀疏注意力,他们估计这将使该配置下的推理速度慢约2×。对基座模型的选择存在技术上的质疑:一位评论者询问为什么不基于Ornith Next Flash构建,并认为虽然Qwen 3.5是强大的基座,但相对于更新的替代方案已经“被远远甩在后面”。
RecursiveSI/flint (40B A2.5B) · Hugging Face(活跃度:784):RecursiveSI/flint 是一个发布在Hugging Face上的 Apache-2.0 协议 decoder-only MoE 编码智能体模型,共有
39.8B参数,但每个 token 仅激活约2.5B。它使用49层,每个 MoE 层有256个路由专家,每个 token 选取6个,混合滑动窗口/全注意力,并具有标称的262k上下文;Recursive 报告其在 Terminal-Bench 2.1 上得分为54.9%,SWE-bench Pro v2 上为89.7%,SWE-bench Verified 上为74.2%,面向 B300/H200 GPU 上的 SGLang 推理,支持 OpenAI 兼容的工具调用。评论者将其定位为人们本希望从 Qwen 3.8 中得到的“35B-A3B”级别模型,但指出Qwen3.8-27B的存在让这次发布显得没那么令人意外;除此之外,基准测试截图是主要的技术讨论点。评论者将Recursive Flint定位为一个仅激活
2.5B参数的40BMoE,大致符合部分用户想要的“35B-A3B”级别稀疏模型,但如今要与Qwen3.8-27B等更新的小激活 MoE 竞争。该帖子指出,如果没有 Qwen 最近的发布,这次发布本会被视为重要得多的大事件。NVIDIA 在 GTC Berlin 的一项技术公告将 Flint 定位为一款针对 RTX Spark 优化的本地编程模型,宣称在
64GB RTX Spark上达到220 tokens/s,并在包括 SWE-Bench Pro v2、Terminal-Bench 2.1 和 SWE-bench Verified 在内的智能体编程基准测试中取得出色成绩:https://blogs.nvidia.com/blog/local-ai-gtc-rtx-dgx-spark-station-sync/NVIDIA 表示,Flint 是利用 Recursive 的 Eureka Machine 构建的,这是一种自动化 AI 研究循环,能够提出想法、加以实现、运行实验并选择后续方向。相关文章称,该系统产出了专用的内核,在不改变模型权重的情况下将 Flint 在 RTX Spark 上的生成速度提升了
55%,并指出其采用 Apache 2.0 开放权重,同时支持通过 NeMo Automodel SFT/LoRA 和 NeMo RL GRPO 进行后训练。
支持声音克隆的 Pocket TTS 现在仅有 190 万参数(活跃度:561):Kyutai 发布了 Pocket TTS-small,将一套可在 CPU 上实时运行的声音克隆 TTS 方案从约
100M参数压缩至18.2M、6.9M和1.9M几个版本。该压缩流程采用了来自约300M教师模型的蒸馏、单次内嵌的 classifier-free guidance、基于 PCA 推导的64-D骨干—头部潜在接口、结构化 transformer 剪枝、骨干/头部/编解码器分离蒸馏,以及可选的奖励微调;据报道,18.2M模型在 CPU 上的吞吐量达到约9.9×倍实时,1.9M模型达到约25×倍实时,其中18.2M模型在 WER/UTMOS 上与原模型持平或略有超越。评论者对压缩方法的关注较少,更多集中在已发布模型/演示中一个明显的粗话过滤器上——例如 “What the fuck” 被合成为 “What the dee”——不过有更新表示团队已修复该问题。还有人要求在自然度、实时率和跨说话人声音相似度方面提供更严谨的基准测试,尤其是针对完全本地推理的场景。多位用户报告 TTS 输出中出现了明显的文本审查/退化:诸如 “What the fuck” 的短语被合成为 “What the dee”。点赞最高的评论者随后指出,团队已处理该问题并发布了修复,这表明它很可能是一种无意的模型/分词/过滤行为,而非永久性的策略选择。
一位评论者指出,标题中的参数量——
1.9M参数——固然令人印象深刻,但希望看到具体的评估数据:自然度、实时率和跨说话人声音相似度。他们强调,微型 TTS 模型只有在不牺牲说话人克隆质量的前提下保持完全本地推理时,才最有吸引力。有用户反馈其对非英语语言的支持不佳,称非英语输入实际上被处理为英语而非目标语言。这表明尽管有更广泛的 TTS/语音克隆宣传,其多语言能力可能很弱或缺失。
独家:字节跳动、阿里巴巴、腾讯下达超过 350 亿美元的英伟达芯片订单(活跃度:1047):路透社报道称,字节跳动、阿里巴巴和腾讯已下达超过 350 亿美元的英伟达芯片订单(Reuters)。该 Reddit 帖子将其解读为中国订购了大约
3M张 RTX PRO 5500 显卡,单价约$11,400,可能用于 LLM 推理和 AI 视频生成,而一位受访消息人士称英伟达可能只能交付所求数量的5–10%,且 2027 年全球最多只能生产3M张 RTX PRO 5500 显卡,而中国客户的请求超过6M张。评论者认为,供应限制意味着这一头条订单量不太可能全部交付,一些人推测随着数据中心需求占主导,英伟达可能会降低利润率较低的工作站级显卡的优先级。也有人怀疑未来的 GPU 世代会让现在的 RTX PRO 显卡对本地 LLM 用户来说变得可负担,尽管有些人希望数据中心的更新换代周期可能压低二手市场价格。评论者强调了一个据报道严重的供需错配:英伟达可能只分配所求数量中的
5%–10%给合作伙伴,一位消息人士称其 2027 年全球最多只能生产3 million张 RTX PRO 5500 显卡,而中国客户的订单超过6 million。这意味着$35B+的订单可能受到严重的供应限制,而非可完全交付的需求。一条价格纠正指出,隐含的单卡成本约为
$11,400每张,而非$11.40,这与高端专业/数据中心 GPU 的定价相符。另一个技术层面的担忧是,高利润的企业需求可能使英伟达即使对$16,000RTX 6000 Pro 这类显卡,也更倾向于数据中心分配而非优先生产它们。几位评论者推断,GB202 级芯片可能被转用于专业或符合出口合规的 SKU,例如 RTX PRO 显卡,从而减少像 RTX 5090 这类消费级 GPU 的供应。其根本担忧是,数据中心/专业需求可能会持续挤占游戏 GPU 的供应,直到更新的世代将需求从当前芯片上转移开。
做好准备,GPU 涨价将至 --> 三星 2027 年 HBM 产能已 100% 售罄 —— 预计明年 HBM 价格将上涨 200%,DRAM 价格预计将出现两位数涨幅 (热度:1227):GSMArena 报道称,据称三星已通过与大科技公司客户签订的大型多年期合同,预售了明年
70%的通用 DRAM 产能和100%的 HBM 产能。由此造成的内存供应紧张预计将在 2027 年第一季度推动 HBM 价格上涨150–200%,DRAM 价格出现两位数上涨,从而加大 GPU/AI 加速器以及未来 Galaxy 手机等下游设备的 BOM 成本压力。 评论者预计 HBM 紧缺将使消费级/本地 AI GPU 的价格更难以承受,同时指出了依赖循环:前沿模型需要超大规模云服务商的 GPU 集群,但本地推理用户也在争夺同样受限的内存供应。有人认为,稀缺可能迫使优化方向转向更小、更高效的模型以及更长的硬件生命周期。一些评论者将报道的三星 2027 年 HBM 产能售罄以及预期的 HBM/DRAM 涨价与本地 AI 硬件经济性恶化联系起来:本地推理用户需要 GPU,但超大规模云服务商和 AI 实验室同时也在为训练和数据中心扩张吸纳供应。一位评论者指出,GPU 的采购似乎在配套数据中心容量建成之前就已加速,这意味着库存囤积可能会让消费级/准专业级 GPU 供应多年来持续紧张。
有评论者提出一个技术经济观点:随着 GPU 和内存价格上涨、而部分云 AI 服务变得更便宜,本地 AI 设备与云端推理之间的盈亏平衡点已经外移。该评论者特别指出,MoE 模型加剧了这一趋势,因为数据中心可以比个人本地机器更高效地在众多用户之间复用稀疏的专家激活,而本地机器则难以证明昂贵的高显存硬件的合理性。
一位评论者认为,硬件稀缺可能会推动模型侧的优化,激励开发更小、更高效的模型,而非单纯扩大参数量和内存带宽。这意味着高昂的 HBM/GPU 价格可能会加速压缩、量化、蒸馏、稀疏架构以及推理效率改进方面的工作。
这些变化何时到来?——中国将 RAM 产能翻倍,以防日常电子产品价格飙升(活跃度:402):这篇帖子询问,在据称中国将 RAM/DRAM 产能翻倍(很可能是通过 CXMT 等国内供应商)以应对内存需求上升之后,消费者何时会看到价格影响。排名靠前的技术性评论认为,这一影响将是渐进的:新 DRAM 产能需要数个季度到数年才能爬坡,且会被边缘计算和数据中心等领域的潜在需求所吸收,因此可能主要是降低价格上涨的速度,而不是带来明显的消费价格下降。评论者怀疑全球买家能否在短期内省钱:一种观点认为,中国产出将主要满足中国国内需求,减少中国的进口,而不是涌入出口市场。另一种观点认为,厂商不会放弃高利润的企业/数据中心销售去转向低利润的消费级 DRAM,因此终端电子产品的价格可能维持高位。
多位评论者强调,新增 DRAM 产能将逐步出现,而不会表现为明显的降价:新晶圆厂需要数年才能爬坡,新增供应可能被边缘计算、数据中心和消费设备的潜在需求所吸收。一个预测是,近期的主要影响是价格上涨放缓而非 RAM 变便宜,因为厂商不太可能放弃高利润的企业/AI 需求而转向低利润的消费级销售。
一条详述供应链的评论引用了 CXMT 的
600,000 wafers/month by 2028目标作为相关时间尺度,认为由 AI 热潮触发的内存扩产将从 2025 年底开始陆续落地,并持续到 2030 年。该评论者还提到了全球其他地区的并行扩产:与 CHIPS 法案部分相关的纽约州、爱达荷州和印第安纳州的美国晶圆厂;三星在其内存基地新增第 4 和第 5座工厂;以及 SK Hynix 在其 Y2 厂投资约35 trillion won,并在其 F17 晶圆厂投资19 trillion won。另一个技术/经济层面的观点是,中国增加的 DRAM 产量可能主要替代进口,而不是涌入全球消费市场:CXMT 可以先满足中国国内需求,尤其是在大规模数据中心建设的情况下。评论者将内存制造形容为高度周期性、资本密集型的行业,过度扩产可能把创纪录的利润变成破产,因为规模达万亿美元量级的晶圆厂在需求下滑时无法迅速转产或清算。
/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo
Claude Duet:Anthropic 随手发布了一款个人助手,称其为主动式智能体。这是对 Muses、Bots 和 Dots 的回应(活跃度:1306): 图片是 Claude 在 X/Twitter 上发布的公告的截图,介绍了 Claude Duet——一款研究预览版应用,将 Claude 定位为主动式个人智能体,而非单纯的聊天助手。该帖子声称 Duet 能够呈现需要关注的事项,在用户离开时异步完成所请求的任务,并在代表用户采取行动之前请求确认;有评论者指出,据报道它将包含在
$20套餐中。评论者反应不一:有人说这与他们目前使用 Claude 的方式一致,并质疑 Duet 与 Muses、Bots、Dots 等其他智能体/应用概念有何区别。另一条热门评论是一个非技术性的玩笑,没有提供任何实质性的技术背景。评论者指出,Claude Duet 似乎已包含在 Anthropic 现有的
$20/month套餐中,这表明 Anthropic 正在把主动式智能体/助手层定位为主流付费 Claude 用法的一部分,而不是一个单独的、仅面向企业的产品。一些技术性批评认为,Anthropic/OpenAI 类厂商目前推出的“助手”产品看起来仍然只是套在不同前沿模型之上的薄薄一层聊天机器人包装,而非根本性的新型智能体系统。用户质疑 Claude Duet 与现有的基于 Claude、Muses、Bots 或类似助手抽象的个人工作流相比有何区别。
一位评论者认为,缺失的环节未必是模型能力,而是结构化的个人数据整合与产品编排:一个实用的助手需要更好的数据模式、上下文管理以及与外部服务的集成。他们认为所需的技术其实已经存在,只是需要被打包成一个连贯的助手体验,而不是又一个通用的聊天界面。
我用 Claude 修好了我的三星电视 (热度: 3894): 一位用户报告称,他将 Claude 用作交互式智能体来诊断一台三星电视,确认其系统是 Tizen 而非 Android,随后通过托管一个本地网页、生成本地服务器二维码并使用手机摄像头每隔
4s拍摄一次电视截图来绕过无法访问摄像头的问题,以获得视觉反馈(二维码截图)。据称,该智能体花费了约30 min来修改隐私/遥测设置、删除三星广告 ID、禁用未使用的应用、重新排列图标,然后构建了一个定制的“Apple TV 风格”启动器/主屏幕应用,以及一个用于快捷方式和背景的配套设置应用(启动器、设置界面)。一位热门评论者描述了类似的面向访客的定制电视启动器流程:行前偏好收集、个性化的 Plex/媒体/新闻内容呈现、音乐/背景/欢迎屏幕、行程/天气展示,以及用于户外灯光、泳池增氧机和喷雾器的 Home Assistant 控制。 评论者们主要惊讶于该用户竟敢尝试用 Claude 进行这种程度的电视自主去臃肿/定制;有人将其视为超越标准编程辅助的智能体 UI 自动化的实际案例。看猫视频的插曲被当成笑料处理,而非技术失败。一位评论者描述了使用 Claude 构建并替换三星电视启动器、打造定制化面向访客的界面的过程:通过问卷驱动的个性化设置,涵盖 Plex 电影、电视/新闻频道预设、背景音乐、天气、行程和本地推荐。他们还将该启动器与 Home Assistant 集成,让访客可以直接从电视主屏幕控制户外灯光、泳池增氧机、喷雾器及其他智能家居设备。
另一位评论者建议不必使用定制的 Claude 驱动工作流,而是安装
cleanyourtv,这是一个拥有约15,000星的 GitHub 项目,旨在清理/精简智能电视。他们认为这比让 Claude 手动指导或生成电视修复过程更快、消耗的 token 更少。被指出的一项技术细节是删除了电视的 Ad ID,这意味着最初的 Claude 辅助修复包含隐私/去臃肿步骤,而不仅仅是 UI 调整。这被视为针对三星智能电视的一项值得注意的隐私导向修改。
我用 Claude Code 替换了三星电视的主屏幕(热度:1069):该图片展示了一个自定义的三星电视启动器,用极简的网页风格界面取代了广告泛滥的原厂主屏幕:时钟/日期、选中的应用磁贴、控制台快捷方式、设置以及遥控器提示。作者说 Claude Code 帮助构建了这个启动器,并通过在笔记本电脑浏览器中模拟三星电视 API 来加快迭代速度;据报道,主页键接管使用了一个类似 CleanFrame 的辅助工具来修改未公开文档的电视设置,仅在 2022 款三星 Q70B 上测试过。代码发布在 GitHub 上,还有一篇更长的文章。 评论持怀疑态度且两极分化:一位评论者称赞该项目是避开三星/LG 遥测和广告的一种方式,而其他人则怀疑这是垃圾信息/诈骗的转发,或认为它重复乏味。
评论者们对三星/LG 专有智能电视软件提出了隐私/安全方面的担忧,认为开源的替代 UI/OS 可以减少厂商的遥测和不受欢迎的跟踪。一个技术上值得注意的警告是:如果在不了解平台启动/更新约束的情况下部署“凭感觉编码(vibe-coded)”的电视固件或主屏幕替换方案,可能导致设备变砖。
一个聚焦安全的讨论串警告说,鼓励用户运行未经审查的电视代码可能会造成巨大的攻击面:被入侵的替代启动器或脚本可能实现对多台电视的同步远程控制,例如在多台设备上强制播放攻击者指定的视频。
一位用户询问替换三星主屏幕是否带来了可衡量的延迟改善,并指出原厂电视启动器“慢得像猪一样”。他们还提到使用 Claude 安装了 Jellyfin,表示想知道 AI 生成的电视启动器能否在本地媒体工作流中比 OEM 智能电视软件提供更好的响应速度。
我给 Claude Code 一个包含 1100 万篇新闻文章的数据库,它发现了一些奇怪的模式(活跃度:1604):图片是一张技术仪表盘截图,不是梗图:它展示了 CLSTR 深色主题的 “当前世界”地图,其中新闻摄取管道按国家可视化当前全球事件量。作者在帖子中表示,该系统每天处理约
100k篇文章,来自40k+个来源、40种语言,将其聚类为事件,并在11,079,667篇文章后提供衍生分析;截图显示过去3小时内161个国家共有2,703个事件,并高亮了一个主要聚类“法国在大规模内乱中实施宵禁”,包含673篇文章。需要澄清的重要一点是,Claude Code 并没有阅读 1100 万篇完整文章;它查询/导出的是由作者管道生成的聚合聚类元数据,该管道使用嵌入、启发式方法和一个 LLM 判断步骤。评论者讨论了该方法论是否足以支持这些结论:一个持怀疑态度的帖子认为 Claude 很可能只是编写了启发式分析代码,而且来源选择/聚类的偏差可能在观察到的模式中占主导地位。其他人则更乐观,将其视为 LLM 智能体帮助发现真实世界数据中大规模模式的例子。几位评论者质疑 Claude Code 是否真的直接处理了
11M篇文章,他们认为在这种规模下进行完整的基于 LLM 的分析成本过高且速度太慢。更合理的实现方式是 Claude 编写辅助代码或启发式方法来聚合/搜索语料库,但评论者警告说,这类启发式方法需要记录在案,因为它们可能在结果中占主导地位。一个主要的方法论批评是缺乏关于数据收集、来源选择和抽样偏差的细节。评论者指出,如果来源来自 Google News 或其他聚合器,观察到的模式可能反映的是排名、区域性、点击历史个性化或来源可用性偏差,而不是真实的媒体行为。
评论者还指出了潜在的语言/来源覆盖问题,包括未知语言的条目被标记为英语,以及明显缺失俄语、中文或韩语等主要非英语语料库。他们认为,如果没有来源文档和语言标记验证,关于全球新闻模式的结论在技术上就是站不住脚的。
Waymo 的自动驾驶出租车严重事故比人类少 95%,如今计划扩充至 2 万辆车队(热度:1457):Waymo 最新安全数据报告了
271.3M英里的全无人载客里程,每百万英里严重受伤/致死事故为0.01起,而模拟的当地人类基准为0.21/百万英里,即严重事故减少约 95%,受伤事故也减少约 82%。IIHS 对 2021–2024 年联邦事故数据(约50M英里无人驾驶里程)的分析发现方向上类似的降幅——可报警事故减少 68%、受伤事故减少 81%——但也指出了报告局限性,以及一个略差于人类基准的奥斯汀结果。据 Semafor 报道,Waymo 计划在 2027 年底前将车队从约4,000辆扩充至20,000辆,部分资金来自$5B的债务融资。评论者就基准是否具有可比性展开辩论:支持者认为严重事故数量足够多,因此降幅是有意义的,且 Waymo 车辆很少是责任方;而质疑者指出,Waymo 当前的运行设计域(ODD)主要是密集城区、低速、少高速公路的驾驶场景,与许多严重事故发生的乡村/郊区或高速路段截然不同。一位自称有整车厂碰撞安全工程经验的评论者认为,Waymo 报告的安全结果与十年来的自动驾驶研究一致:人类驾驶是一种高风险的日常活动,而自动驾驶系统的严重事故率通常更低。他们强调,报告的指标似乎基于总事故数量而非责任认定,并指出 Waymo 车辆常因人类驾驶者造成的事故而被卷入其中,而非事故的引发方。
另一位评论者提出了暴露偏差的担忧:据报道,Waymo 车辆主要在密集城区环境运行,很少上高速公路,而高速事故和严重伤害在高速公路上更常见。他们认为,
95% fewer serious crashes的结论可能无法推广到乡村、郊区或经常上高速、车速更常超过50 mph的运营场景。一位评论者指出,针对奥斯汀市场的事故率对比可能在统计上较弱,因为据称研究期间当地只有
2起 Waymo 事故。他们认为这一样本量太小,无法就 Waymo 在该市场比人类驾驶者更安全还是更不安全得出有力结论。
宇树最新机器人:H2-X 功夫传奇守卫者(热度:3907):宇树发布了 H2-X “功夫传奇守卫者”,看起来是一款更坚固/力量更强的 H2 人形机器人变体,宣称最长续航约
8 hours,并在其 X 帖子中将其定位为“服务与守护”平台。该帖将其与其他中国人形格斗/娱乐机器人并列,尤其是众擎(Engine AI)的 T800,据 这篇报道,后者被用于格斗赛演示;由于受到403 Forbidden屏蔽,Reddit 上的视频本身无法访问。热门评论更多关注安全/两用性担忧而非规格,有人打趣称演示机器人推开一个孩子的力道比慢速行驶的汽车还大,还有人讽刺地希望这项技术不会被滥用。
Fibo 2 Edit 是 Klein 3 本应成为的样子。(活跃度:1189):Reddit 用户报告 Fibo 2 Edit(HF 模型)是一个开箱即用的快速“无审查”图像编辑模型,在简单编辑中未观察到颜色漂移/质量损失,并将部分质量提升归功于 Flux 2 VAE。他们通过 PR
Comfy-Org/ComfyUI#17240链接了实验性的 ComfyUI 支持,但随后更新称它在复杂提示词和多参考编辑上表现吃力,并且“并不比 Qwen 好,只是更快”。评论认为 Fibo 2 Edit 可能是“迄今最好的编辑模型”,主要原因是它无审查,附带一场暗示审查可能降低模型实用性的小争论。另一位评论者强调了开源权重图像模型的快速进展,提及即将推出/已可用的模型如 Ideogram 4、Krea 2、Qwen 2.1、LTX,以及在消费级硬件上于 ComfyUI 中运行的 量化版 Hunyuan Image 3。用户强调 Fibo 2 Edit 是一个强大的图像编辑模型,并指出据报道它是 无审查的,一位评论者声称它是“迄今最好的编辑模型”。讨论将其视为一个更广泛趋势的一部分:限制较少的图像模型在实际编辑质量上被认为优于过滤更严格的替代品。
有人报告了一个与输出分辨率相关的技术性限制:据称 Fibo 2 Edit 会将源图像降采样到大约
1MP,然后通过 Flux 2 VAE 处理,导致结果模糊。这表明该模型或当前流水线的瓶颈可能在于预处理/VAE 分辨率处理,而非编辑语义本身。评论者提到对 ComfyUI 支持的兴趣以及更广泛的开源权重生态的势头,列举了诸如 Ideogram 4、Krea 2、Anima、Qwen 2.1、Moss Image、Ming Image、Minimax H3、LTX 和 量化版 Hunyuan Image 3 等模型。后者据称可能可以在消费级硬件上的 ComfyUI 中运行,这意味着量化正在让更大的图像模型更容易在本地使用。
截至3小时前,Linux 内核不再要求在提交新代码时声明 AI 的使用。(活跃度:1071):Linus Torvalds 的
14c8977提交截图torvalds/linux显示,他合并了 Linux 文档更新,其中包括移除此前对新内核提交的“Assisted-by”要求。结合上下文,这意味着贡献者在向 Linux 内核提交代码时不再需要明确声明 AI 辅助,政策从强制披露 AI 使用转为放宽。评论分为赞同和预期反弹两派:一位评论者认为诸如 “AI 代码全是垃圾” 之类的假设已经过时,另一位则预计社区会炸锅。一位务实的评论者表示现在可能会用 Claude 提交一个搁置已久的本地驱动修复,暗示这一变化可能降低部分贡献者的门槛。一位评论者提到,他们针对一个反复出现的影响某些搭载特定芯片主板的驱动程序缺陷,一直在多个版本之间维护着一个本地内核补丁,而放宽的 AI 披露规则可能会促使他们更愿意借助 Claude 把修复提交到上游。其技术影响在于,减少披露/流程上的摩擦可能会增加小型、硬件特定修复的上游提交数量,否则这些修复只会留在私有的本地补丁中,不过该评论并未指明具体的驱动、芯片组或缺陷细节。
来源: Latent Space · latent.space
