AI News

OpenAI 与 Anthropic 开战:Claude Opus 4.6 对阵 GPT 5.3 Codex

OpenAI 推出了 GPT-5.3-Codex,重点强调了 Token 效率推理速度,以及通过与 英伟达 (NVIDIA) 合作基于 GB200-NVL72 实现的软硬件协同设计。新的 Frontier 智能体平台支持具备业务上下文、执行环境和学习能力的智能体。Anthropic 展示了 Opus 4.6 智能体团队自主构建了一个可引导 Linux 的“净室”(clean-room)C 语言编译器,突显了在智能体化编程和长上下文能力方面的进步。社区基准测试报告显示,推理速度提升了 2.93 倍,效率显著提高,预示着 2026 年行业将告别“无限算力预算”的时代。

#agentic-coding #long-context #token-efficiency #inference-speed #hardware-software-co-design #agent-platforms #benchmarking #software-development #compiler-construction gpt-5.3-codex opus-4.6 openai anthropic nvidia

SOTA 编程模型之战再度升级。

2026年2月4日至2月5日的 AI 新闻。我们为你检查了 12 个 subreddits、544 个 Twitter 账号 和 24 个 Discord(254 个频道,9460 条消息)。预计为你节省阅读时间(以 200wpm 计算):731 分钟。AINews 网站 可搜索所有往期内容。提醒一下,AINews 现已成为 Latent Space 的一个板块。你可以选择加入或退出邮件推送频率!

如果你认为 Claude Opus 4.6GPT-5.3-Codex 的同步发布纯属巧合,那你可能还没充分意识到目前全球两大领先编程模型实验室之间竞争的激烈程度。这一点从未如此清晰:

从纯粹的公关角度来看,Anthropic 通过在其 1M Context全新的自定义 CompactionAdaptive ThinkingEffortClaude Code Agent 团队、Claude 进入 Powerpoint/Excel500 个 Zero-days 漏洞研究、C 编译器任务Mechinterp 的应用、AI 意识的提及 以及 $50 促销活动中展开的“分布式拒绝开发者注意力”(distributed denial of developer attention)赢得了今日的局面。而 OpenAI 则在大多数基准测试中获胜,速度提升了 25%,具备更高的 Token 效率,并标榜了更强的 Web 开发技能。但很可能第一天的所有第三方反应要么带有偏见,要么过于肤浅。这里是 Opus 对不同发布内容进行的视觉对比:

Image

Image

两者都是小版本号更新,这将为今年夏天的 Claude 5 和 GPT 6 之战铺平道路。

该你们行动了,GDM 和 SpaceXai。


AI Twitter 回顾

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

  • 前沿实验室工程:Anthropic 关于使用 Agent 团队 + Opus 4.6 构建一个可引导 Linux 的净室 C 编译器的帖子引发了巨大关注(推文)。
  • OpenAI 发布GPT-5.3-Codex 的发布(以及 Codex 产品更新)作为最大的纯 AI 产品事件落地(推文)。

OpenAI GPT-5.3-Codex + “Frontier” Agent 平台(性能、效率、基础架构协同设计)

  • GPT-5.3-Codex 已在 Codex 中发布:OpenAI 宣布 GPT-5.3-Codex 现已在 Codex 中可用(“你只需去构建东西就好”)(tweet),并将其定位为在单个模型中推进 前沿编程 + 专业知识 (tweet)。
    • 社区反应强调,相比前几代产品,Token 效率 + 推理速度 可能是最具战略意义的差异化因素 (tweet)。一项 Benchmark 声明指出:TerminalBench 2 = 65.4%,发布后立即流传出在正面交锋中“彻底击败 Opus 4.6”的说法 (tweet)。
    • 报告的效率提升:在 SWE-Bench-Pro 上,相比 GPT-5.2-Codex-xhigh,Token 消耗减少了 2.09 倍,加上约 40% 的加速,意味着在分数提升约 1% 的情况下,速度快了 2.93 倍 (tweet)。从业者对这一主题产生共鸣,认为这标志着 2026 年将不再假设“无限预算算力” (tweet)。
  • 针对 GB200 的硬件/软件协同设计:一个值得关注的系统视角:OpenAI 工程师将该模型描述为“专为 GB200-NVL72 设计”,并提到了 ISA 细节优化、机架模拟以及针对系统定制架构 (tweet)。另一篇关于“与 NVIDIA 长期合作成果”的帖子进一步证实,模型的收益是伴随特定平台的优化而来的 (tweet)。
  • OpenAI Frontier (Agent 平台):OpenAI 的 “Frontier” 被定位为一个构建、部署和管理 Agent 的平台,具备 业务上下文、执行环境(工具/代码)、在岗学习以及身份/权限管理 功能 (tweet)。另一份报告引用了 Fidji Simo 的话,强调与生态系统合作,而不是内部闭门造车 (tweet)。
  • Agent 软件开发的内部采用指南:一篇详细的帖子展示了 OpenAI 的运营推动力:到 3 月 31 日,针对技术任务,“首选工具”应是 Agent,并配合诸如 AGENTS.md、技能库、通过 CLI/MCP 暴露的工具清单、Agent 优先的代码库以及“对劣质内容说不”的评审/问责规范等团队流程 (tweet)。这是前沿实验室试图将 “Agent 轨迹 → 可合并代码” 工业化的最清晰公开案例之一。
  • 开发者生态激活:Codex 黑客松和持续的构建者展示加强了“交付速度”的定位 (tweet, tweet)。此外,人们对计算机使用对等技术栈(例如 OSWorld-Verified 声明、Agent 浏览器对比 Chrome MCP API)表现出浓厚兴趣,并请求 OpenAI 对“正确”的测试框架进行 Benchmark 和推荐 (tweet, tweet)。

Anthropic Claude Opus 4.6:Agent 编码、长上下文和测试基准“噪音”

  • 自主 C 编译器作为“Agent 团队”的压力测试:Anthropic 报告称,指派 Opus 4.6 Agent 团队构建一个 C 编译器,随后“基本放手不管”;大约 2 周后,该编译器已能在 Linux 内核上运行(tweet)。一份广为流传的摘录声称:该项目采用“无尘室”(clean-room,无网络连接)环境,代码量约 10 万行,可在 x86/ARM/RISC-V 上启动 Linux 6.9,能编译主流项目(QEMU/FFmpeg/SQLite/postgres/redis),并在包括 GCC torture tests 在内的多个测试套件中达到 ~99% 的通过率,还通过了 Doom 试金石测试(tweet)。
    • 工程师们也质疑,当生成模型是在广泛的互联网语料库上训练时,“无尘室”究竟意味着什么(tweet);另一些人则认为部分评估存在“作弊”嫌疑,因为针对 GCC 进行编译使得进度更易于验证(tweet)。
  • 基准测试可靠性与基础设施噪声:Anthropic 发布了第二篇工程博文,量化指出 基础设施配置 可能会使 Agent 编程基准测试结果产生 数个百分点 的波动,有时甚至超过排行榜上的差距(tweet)。这一观点正值社区讨论基准测试选择不一致且重叠有限(通常仅限 TerminalBench 2.0)之际(tweet)。
  • 分发与产品挂钩:Opus 4.6 的可用性迅速扩大——例如 Windsurftweet)、Replit Agent 3tweet)、以及强调 CLI 自主模式的 Cline 集成(tweet)。此外还有激励措施:许多 Claude Code 用户可以在使用情况面板中领取 50 美元抵用券tweet)。
  • 关于提升与局限性的说法:一份流传的 System Card 内容声称,员工估计生产力提升了 30%–700%(平均值 152%,中位数 100%)(tweet)。然而据报道,内部员工并不认为 Opus 4.6 在 3 个月内能作为“入门级研究员的直接替代品”,即便有 Scaffolding 辅助也是如此(tweet;相关讨论见 tweet)。
  • 模型定位与“留一手(sandbagging)”推测:一些观察家建议 Opus 4.6 的提升可能源于 更长的思考时间 而非更大的基础模型,并推测它可能类似于“Sonnet”,但拥有更高的推理 Token 预算(未经证实)(tweet;怀疑态度见 tweet)。另有传闻提到“Sonnet 5 泄露”和 Sandbagging 理论(tweet)。
  • 排行榜:Vals AI 声称 Opus 4.6 在 Vals Index 中排名第一,并在多个 Agent 基准测试(FinanceAgent/ProofBench/TaxEval/SWE-Bench)中达到 SOTA(tweet),与此同时,更广泛的生态系统正在讨论哪些基准测试更重要以及如何进行比较。

新研究:Agent 的路由/协作、多 Agent 效率及“Harnesses”

  • SALE (Strategy Auctions for Workload Efficiency):Meta Superintelligence Labs 的研究提出了一种类拍卖的路由器:候选 Agent 提交简短的 strategic plans,由同行评审其价值并进行成本估算;“最佳性价比”者获胜。报告显示,在 deep-search 上 pass@1 提升了 3.5 且成本降低了 35%,在 coding 上 pass@1 提升了 2.7 且成本降低了 25%,对最大型 Agent 的依赖减少了 53%tweet;论文链接见推文)。这是在任务复杂性上升的情况下,替代分类器或 FrugalGPT 风格级联的具体方案。
  • Agent Primitives(潜在 MAS 构建块):提出将多智能体系统(MAS)分解为可重用的原语——ReviewVoting/SelectionPlanning/Execution——Agent 之间通过 KV-cache 而非自然语言进行通信,以减少性能损耗和开销。据报告:在 8 个基准测试中,平均准确率比单 Agent 基线提高 12.0–16.5%,GPQA-Diamond 表现大幅跨越(53.2% vs 先前方法的 33.6–40.2%),且 Token/延迟比基于文本的 MAS 低 3–4 倍(但比单 Agent 开销高 1.3–1.6 倍)(tweet;论文链接见推文)。
  • “团队限制了专家(Teams hold experts back)”:有观点认为,随着任务规模的扩大,固定的工作流/角色可能会限制专家的表现,从而促使了自适应工作流合成(adaptive workflow synthesis)的发展(tweet)。
  • 工具转向:从框架(frameworks)到 Harness:多个讨论强调 LLM 仅仅是“引擎”;可靠性来自于强制执行规划/记忆/验证循环的 严格 Harness,以及诸如子 Agent 生成(sub-agent spawning)以保留管理者上下文的模式(tweet),以及 Kenton Varda 的观察,即 Harness 中“唾手可得的成果”正在随处产生收益(tweet)。
  • IDE/CLI 中的并行 Agent:GitHub Copilot CLI 推出了 “Fleets”——调度并行子 Agent,并使用会话 SQLite DB 来跟踪依赖感知任务/待办事项(tweet)。VS Code 将自己定位为“多 Agent 开发之家”,在 Copilot 订阅下管理本地/后台/云端 Agent,包括 Claude/Codex(tweet)。VS Code Insiders 增加了 Agent 引导(steering)和消息队列功能(tweet)。

训练与效率研究:微型微调、RL 目标、持续学习、隐私、长上下文

  • TinyLoRA: “Learning to Reason in 13 Parameters”:一项博士结业成果声称通过一种微调方法(结合 TinyLoRA + RL),仅使用 13 个可训练参数 就将 Qwen 7B 模型的 GSM8K 评分从 76% 提升至 91% (tweet)。如果可复现,这将是推理任务“极低自由度(low-DOF)”适配的一个引人注目的数据点。
  • Maximum Likelihood Reinforcement Learning (MaxRL):提出了一种在 REINFORCE 和极大似然(maximum likelihood)之间进行插值的目标函数;该算法被描述为近乎“单行代码修改”(通过平均奖励对 advantage 进行归一化)。声称:具有更好的样本效率,在推理任务上 Pareto 优于 GRPO,并具有更好的扩展动态(在更难的问题上产生更大的梯度)(tweet;内附论文链接)。
  • 带有 log-prob 奖励的 RL:一项研究认为,通过使用与 next-token 预测损失挂钩的 (log)prob 奖励,可以“弥合可验证和不可验证场景之间的鸿沟” (tweet)。
  • 用于从自然语言进行高效样本持续学习的 SIEVE:仅需 3 个示例 即可将自然语言上下文(指令/反馈/规则)蒸馏到权重中,其性能优于以往的方法和某些 ICL 基准 (tweet)。另一个推文串将此与编写 eval 以及将长 prompt 转换为 eval 集的痛苦联系起来 (tweet)。
  • Privasis:百万级合成隐私数据集 + 本地“清理”模型:推出了包含 140 万条记录5500 万+ 标注属性10 万对脱敏数据对Privasis(合成数据,无真实人物);训练了一个 4B 的 “Privasis-Cleaner” 模型,据称在端到端脱敏方面优于 o3 和 GPT-5,能够作为本地隐私卫士,在将敏感数据发送给远程 Agent 之前进行拦截 (tweet)。
  • 长上下文效率:Zyphra AI 发布了用于高效长上下文处理的 OVQ-attention,旨在平衡压缩率与内存/计算成本 (tweet;论文链接 tweet)。
  • 蒸馏溯源:“抗蒸馏指纹识别(ADFP)”提出了一种与学生模型学习动态保持一致的溯源验证方法 (tweet)。

行业、采用情况以及“Agent 正在吞噬知识工作”的叙事(伴随反对意见)

  • 归因于 Agent 的 GitHub 提交:SemiAnalysis 引用的一项声明称:4% 的 GitHub 公共提交是由 Claude Code 撰写的,预计到 2026 年底这一比例将达到 20%+ (tweet)。另一个推文串指出,这一数字在一个月内从 2% 增长到 4% (tweet)。请将其视为趋势参考:归因方法和采样方式至关重要。
  • 工作转型的框架:一个流行的“Just Make It”阶梯认为,随着模型根据模糊的指令生成更大块的工作,劳动力将从 执行(doing)→ 指导(directing)→ 批准(approving) 转变,这首先体现在编程领域,随后会扩展到媒体/游戏领域 (tweet)。Corbtt 预测,许多岗位中的办公电子表格/备忘录工作将在约 2 年内消失 (tweet)——随后补充了一个细微差别:这些职位可能会作为闲职继续存在,但被雇佣进入这些职位的机会将会消失 (tweet)。
  • 更稳健的劳动力市场类比:François Chollet 以翻译员为例,指出 AI 虽然可以自动化大部分产出,但全职员工(FTE)数量保持稳定,而工作内容转向了后期编辑(post-editing),工作量上升,费率下降,且自由职业者被削减——这表明软件行业可能遵循类似的模式,而不是“工作一夜之间消失” (tweet)。
  • Agent + 可观测性是最后一公里:多条推文强调了 Trace、评估和迭代 prompt/规范更新(例如,Claude Code 通过“/insights”分析会话并建议 CLAUDE.md 更新)是“模型改进的终点”与“产品可靠性的起点”的分界线 (tweet)。
  • 去中心化评估基础设施:Hugging Face 推出了 Community Evals 和 Benchmark 仓库,旨在以透明的方式(基于 PR,位于模型仓库中)集中管理报告的评分,即便评分存在波动 (tweet)——考虑到当日基准测试引发的困惑,这一举措非常及时。

(较小的)核心 AI 工程之外的值得关注项目

  • AGI 定义之争:吴恩达(Andrew Ng)认为 “AGI” 已经变得毫无意义,因为其定义各不相同;按照最初的“任何人都能完成的任何智力任务”这一衡量标准,他认为我们还需要几十年时间 (tweet)。
  • AI 风险阅读推荐:Geoffrey Hinton 推荐了一份详细的 AI 风险报告,称其为“必读内容” (tweet)。

AI Reddit 摘要

/r/LocalLlama + /r/localLLM 摘要

1. 用于编程的本地 LLM 和 AI 使用情况

  • 这里有人真的在完全离线的情况下使用 AI 吗? (热度: 290):使用 **LM Studio 等工具可以实现完全离线运行 AI 模型,该工具允许用户根据其硬件能力(如 GPU 或 RAM)从 Hugging Face 选择模型。另一个选择是 Ollama,它同样支持本地模型执行。为了获得更具交互性的体验,openwebUI 提供了一个类似于 ChatGPT 的本地 Web 界面,并可以与 ComfyUI 结合进行图像生成,不过这种配置较为复杂。这些工具让用户无需依赖云服务即可使用离线 AI,在模型选择上提供了灵活性和控制权。** 一些用户报告了在编程和咨询等任务中成功离线使用 AI 的经历,但对硬件的要求各不相同。虽然编程工作流可能需要更强大的配置,但咨询任务可以使用 LM Studio 中的 gpt-oss-20b 等模型来完成,这表明了用例的多样性和硬件的适应性。

    • Neun36 讨论了多种离线 AI 选项,重点介绍了 LM Studio、Ollama 和 openwebUI 等工具。LM Studio 因其与来自 Hugging Face 模型的兼容性而受到关注,并针对 GPU 或 RAM 进行了优化。Ollama 提供本地模型托管,而 openwebUI 提供类似 ChatGPT 的本地 Web 界面,并增加了集成 ComfyUI 进行图像生成的复杂性。
    • dsartori 提到在编程、咨询和社区组织中使用离线 AI,并强调编程需要更强大的配置。他们提到一位队友在 LM Studio 中使用 gpt-oss-20b 模型,这表明该模型在咨询工作流中具有实用性,尽管不仅限于此。
    • DatBass612 分享了使用高端 M3 Ultra 配置的经验,在运行 OSS 120B 模型的情况下,5 个月内实现了正向 ROI。他们估计每日 Token 使用量价值约为 $200,并提到使用 OpenClaw 等工具可能会增加 Token 使用量,同时受益于运行子 Agent 的额外统一内存。
  • 在本地运行 LLM 进行编程是否真的比 Cursor / Copilot / JetBrains AI 更便宜(且实用)? (热度: 229):该帖子讨论了运行本地大语言模型(LLM)作为 Cursor、Copilot 和 JetBrains AI 等云服务的替代方案用于编程任务的可行性。作者正在考虑本地配置的优势,例如一次性硬件成本、无 Token 限制的无限使用以及隐私性。他们咨询了 Code Llama、DeepSeek-Coder 和 Qwen-Coder 等本地模型的实用性,以及硬件要求(可能包括高端 GPU 或双 GPU 以及 64–128GB RAM)。作者寻求关于本地模型是否能有效处理重构和测试生成等任务,以及与 IDE 的集成是否像云服务一样流畅的见解。 评论者建议 Qwen Coder 和 GLM 4.7 等本地模型可以在消费级硬件上运行,并提供与 Claude Sonnet 等云端模型相当的性能。然而,他们警告说,最先进的模型可能很快就需要更昂贵的硬件。对于特定用例(尤其是大型代码库),建议采用结合本地和云端资源的混合方法。一位评论者指出,如果针对特定任务进行微调,高端本地配置的性能可能会超过云端模型,尽管初始投资巨大。

  • TheAussieWatchGuy 指出,像 Qwen Coder 和 GLM 4.7 这样的模型可以在消费级硬件上运行,提供与 Claude Sonnet 相当的结果。然而,AI 模型的快速进步(例如 Kimi 2.5 需要 96GB+ VRAM)表明,随着 SOTA 模型的发展,保持经济实惠可能具有挑战性,从长远来看,云端解决方案可能更具成本效益。
  • Big_River_ 建议采用结合本地和云端资源的混合方法,这对于大型、成熟的代码库尤其有利。他们认为,针对特定用例投资约 $20k 进行 Fine-tuned 模型定制,其表现可以超越云端解决方案,特别是在考虑地缘政治和经济不确定性下的依赖项所有权时。
  • Look_0ver_There 讨论了本地模型和云端模型之间的权衡,强调了隐私和灵活性。本地模型允许在不同模型之间切换而无需多次订阅,尽管它们可能比最新的在线模型落后约六个月。评论者指出,最近的本地模型已有显著改进,使其能够胜任各种开发任务。

  • 为什么在运行本地 LLM 的硬件成本最终远高于支付 ChatGPT 订阅费的情况下,人们仍不断吹捧使用它? (热度: 84): 该帖子讨论了在消费级硬件(特别是 RTX 3080)上运行本地 LLM 的挑战,这导致了响应速度慢且质量差。用户将其与 ChatGPT 等付费服务的性能进行了对比,强调了隐私与性能之间的权衡。本地 LLM,尤其是那些具有 10B 到 30B 参数的模型,可以执行复杂任务,但需要高端硬件才能获得最佳性能。参数较少(1B 到 7B)的模型可以在个人计算机上成功运行,但更大的模型会变得慢到无法实际使用。 评论者强调了隐私的重要性,一些用户为了保持数据本地化而愿意在性能上妥协。其他人指出,拥有足够强大的硬件(如 3090 GPU),像 gpt-oss-20b 这样的本地模型可以高效运行,尤其是在增强了搜索能力的情况下。

    • 本地 LLM 通过允许模型在不进行外部数据共享的情况下完全访问用户的计算机来提供隐私优势,这对于关注数据隐私的用户至关重要。拥有高性能 PC 的用户可以有效运行具有 10B 到 30B 参数的模型,在本地处理复杂任务而无需依赖外部服务。
    • 在 NVIDIA 3090 等高端 GPU 上运行 gpt-oss-20b 等本地模型可以实现快速高效的性能。这种配置允许用户集成搜索能力和其他功能,为基于云的解决方案提供了一个强大的替代方案。
    • 对本地 LLM 的偏好源于对个人数据和计算资源的控制权及自主权的渴望。用户看重无需依赖外部订阅即可管理自己系统和数据的能力,强调了选择权和控制权比成本考虑更重要。

2. 模型与基准测试发布

  • BalatroBench - 在 Balatro 游戏中基准测试 LLM 的策略性能 (热度: 268): **BalatroBench 引入了一个新颖的框架,用于基准测试本地 LLM 在游戏 Balatro 中的策略性能。该系统使用 BalatroBot(一个提供游戏状态和控制 HTTP API 的 Mod)以及 BalatroLLM(一个兼容任何 OpenAI 兼容端点的 Bot 框架)。用户可以使用 Jinja2 模板定义策略,从而实现多样化的决策理念。包括权重开放模型在内的基准测试结果可在 BalatroBench 上查看。** 一位评论者建议使用进化算法(如 DGM、OpenEvolve、SICA 或 SEAL),看看哪个 LLM 自我进化的速度最快,突显了这种设置中自适应学习的潜力。

  • TomLucidor 建议使用 DGM、OpenEvolve、SICA 或 SEAL 等框架来测试哪种 LLM 在玩 Balatro 时自我进化(self-evolve)最快,特别是当游戏是基于 Jinja2 时。这暗示了对 LLM 在动态环境中的适应能力和学习效率的关注。
  • Adventurous-Okra-407 指出,由于 Balatro 于 2024 年 2 月发布,评估中可能存在偏差。基于更新数据训练的 LLM 可能具有优势,因为目前还没有关于该游戏的书籍或详尽文档,这使其成为对具有小众知识(niche knowledge)模型的独特测试。
  • jd_3d 感兴趣在 Balatro 上测试 Opus 4.6,以查看其是否比 4.5 版本有所改进,这表明了在应用于策略性游戏时,对 LLM 特定版本性能增强的关注。

  • Google Research 宣布 Sequential Attention:在不牺牲准确性的情况下让 AI 模型更精简、更快速 (活跃度: 632): Google Research 推出了一种名为 Sequential Attention 的新算法,旨在通过提高效率而不损失准确性来优化大规模机器学习模型。这种方法专注于子集选择(subset selection),由于 NP-hard 非线性特征交互,这是深度神经网络中的一项复杂任务。该方法旨在保留核心特征并消除冗余特征,从而潜在地增强模型性能。有关更多详细信息,请参阅原始文章。评论者对“不牺牲准确性”的说法表示怀疑,认为这意味着模型在测试中表现同样出色,而不是计算出与 Flash Attention 等先前方法相同的结果。此外,关于该方法的新颖性也存在困惑,因为三年前就发表过相关论文。

    • -p-e-w- 指出,“不牺牲准确性”的说法应解释为模型在测试中表现同样出色,而不是计算出与 Flash Attention 等先前模型完全相同的计算结果。这表明关注点在于维持性能指标,而非确保完全相同的计算输出。
    • coulispi-io 指出了研究时间表上的差异,指出链接的论文 (https://arxiv.org/abs/2209.14881) 是三年前的,这让人对该公告的新颖性以及它反映的是最新进展还是旧研究的重新包装产生了疑问。
    • bakawolf123 提到相关论文在一年前更新过,尽管最初是在两年前发布的(2024 年 2 月),这表明研究正在进行中并可能存在迭代改进。然而,他们注意到缺乏新的更新,这可能暗示该公告是基于现有工作而非新发现。
  • mistralai/Voxtral-Mini-4B-Realtime-2602(Hugging Face) (活跃度: 298): Voxtral Mini 4B Realtime 2602 是一款前沿的多语言实时语音转录模型,延迟小于 <500ms,达到了接近离线的准确度。它支持 13 种语言,并采用原生流式架构(natively streaming architecture)和自定义因果音频编码器(causal audio encoder),允许配置 240ms 到 2.4s 的转录延迟。该模型针对端侧部署(on-device deployment)进行了优化,仅需极少的硬件资源,吞吐量超过 12.5 tokens/second。它在 Apache 2.0 许可证下发布,适用于语音助手和现场字幕等应用。有关更多详细信息,请参阅 Hugging Face 页面。评论者注意到该模型被包含在 Voxtral 系列中,强调了其开源性质和对 vLLM 基础设施的贡献。一些人对缺乏话轮检测(turn detection)功能表示失望,而 Moshi 的 STT 等其他模型具备该功能,因此需要额外的方法来进行话轮检测。

  • Voxtral Realtime 模型专为实时转录设计,其延迟可配置低至 200ms 以下,非常适合 voice agents 等实时应用。然而,它缺乏 speaker diarization 功能,而该功能在 Voxtral Mini Transcribe V2 模型中是提供的。Realtime 模型采用 Apache 2.0 许可证并开源权重(open-weights),允许更广泛的使用和修改。
  • Mistral 通过将实时处理组件集成到 vLLM 中,为开源社区做出了贡献,增强了实时转录的基础设施。尽管如此,该模型并不包含 turn detection(这是 Moshi 的 STT 所具备的功能),因此需要使用标点符号或第三方解决方案等替代方法来实现 turn detection。
  • Context biasing 是一种通过考虑上下文来提高转录准确性的功能,目前仅能通过 Mistral 的直接 API 获取。目前 vLLM 尚不支持新的 Voxtral 模型或之前的 3B 模型使用该功能,这限制了依赖开源实现的用户的可用性。

3. 对 AI 工具的批评与讨论

  • 抨击 Ollama 不仅是一种乐趣,更是一种责任 (热度: 1319): 这张图片是对 **Ollama 的幽默讽刺,该公司被指控将其直接从 llama.cpp 项目中复制 Bug 到自己的引擎中。ggerganov 在 GitHub 上的评论表明,Ollama 的工作可能并不像声称的那样具有原创性,他们被指责仅仅是将 llama.cpp “守护进程化 (daemonizing)”并将其变成了一个“模型点唱机 (model jukebox)”。这一批评是关于寻求风险投资的公司其原创性和知识产权声明的更广泛讨论的一部分,这类公司往往强调展示独特的创新。** 一位评论者认为,Ollama 需要为了风险投资表现出创新性,这可能解释了他们为什么没有向 llama.cpp 致谢。另一位用户分享了从 Ollama 切换到 llama.cpp 的经验,发现后者的 Web 界面更优越。

    • 一位用户强调了 Ollama 能够根据 API 请求动态加载和卸载模型的工程优势。这一功能允许在用于代码辅助的 qwen-coder 和用于结构化输出的 qwen3 等不同模型之间无缝切换,从而提高工作流效率。对于需要频繁切换模型的用户来说,这种能力非常有益,因为它显著简化了流程。
    • 另一位评论者认为,Ollama 的营销方式可能涉及夸大其知识产权或专业知识以吸引风险投资。他们暗示 Ollama 的实际贡献更多在于将 llama.cpp 等现有技术打包成更易于使用的格式,而不是开发全新的技术。
    • 一位用户分享了从 Ollama 切换到直接使用带有 Web 界面的 llama.cpp 的经验,理由是性能更好。这表明虽然 Ollama 提供了便利,但一些用户可能更喜欢直接使用 llama.cpp 带来的直接控制和潜在的性能增强。
  • Clawdbot / Moltbot → 被误导的炒作? (热度: 72): Moltbot (OpenClaw) 被宣传为可以本地运行的个人 AI 助手,但需要多个付费订阅才能有效运行。用户需要来自 Anthropic, OpenAI 和 Google AI 的 API Key 才能访问模型,需要 Brave Search API 进行网页搜索,以及 ElevenLabs 或 OpenAI TTS 用于语音功能。此外,浏览器自动化还需要 Playwright 设置,可能会产生云托管费用。总成本可能达到每月 $50-100+,与 GitHub Copilot, ChatGPT PlusMidjourney 等现有工具相比,实用性较低。该机器人本质上是一个外壳,需要这些服务才能运行,这与其“本地”和“个人”的营销主张相矛盾。** 一些用户认为,虽然 Moltbot 需要付费服务,但可以自行托管 LLM 和 TTS 等组件,尽管这可能无法达到云端解决方案的性能。其他人指出 Moltbot 并非真正的“本地”,并建议使用现有的 ChatGPT Plus 订阅进行集成,强调了在不增加额外费用的情况下实现高性价比设置的可能性。

    • Valuable-Fondant-241 强调,虽然 Clawdbot/Moltbot 可以自行托管,但它缺乏数据中心托管解决方案的能力和速度。他们强调支付订阅费用并非强制性的,因为本地托管 LLM, TTS 和其他组件是可能的,尽管效率可能较低。
    • No_Heron_8757 描述了一种混合设置,使用 ChatGPT Plus 处理主要的 LLM 任务,并使用本地端点处理更简单的任务,如 cron 任务和 TTS。他们指出,虽然这种设置没有额外费用,但在没有昂贵硬件的情况下,本地 LLM 作为主要模型的性能有限,这表明了成本和性能之间的权衡。
    • clayingmore 讨论了 OpenClaw 的创新方面,重点关注其自主解决问题的能力。他们描述了“心跳 (heartbeat)”模式,即 LLM 通过“推理-行动 (reasoning-act)”循环自主制定策略并解决问题,强调了 Agent 解决方案和持续自我改进的潜力,这使其区别于传统的助手。

非技术性 AI 子版块回顾

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

1. Claude Opus 4.6 发布及功能

  • Claude Opus 4.6 已发布 (活跃度: 959): 该图片是一张用户界面截图,重点展示了 Anthropic 发布的新模型 Claude Opus 4.6。界面显示该模型专为“创作”(Create)、“策略制定”(Strategize)和“编码”(Code)等多种任务设计,体现了其通用性。评论中提到了一项显著的基准测试成就,该模型在 ARC-AGI 2 测试中得分为 68.8%,这是 AI 模型的一个重要性能指标。此次发布似乎是对竞争压力的回应,正如一条引用 Codex 重大更新的评论所指出的那样。 一条评论对该模型被描述为适用于“雄心勃勃的工作”(ambitious work)表示失望,认为这可能不符合所有用户的需求。另一条评论则认为发布时机受到了与 Codex 竞争动态的影响。

    • SerdarCS 强调 Claude Opus 4.6 在 ARC-AGI 2 基准测试中达到了 68.8% 的分数,这是 AI 模型的一个重要性能指标。这一得分表明该模型的能力有了实质性的提升,使其有可能成为该领域的领导者。来源
    • Solid_Anxiety8176 对 Claude Opus 4.6 的测试结果表示关注,并指出虽然 Opus 4.5 已经令人印象深刻,但如果能提供更低的成本和更大的 Context Window,将大有裨益。这反映了用户对更高效、更强大的 AI 模型的普遍需求。
    • thatguyisme87 推测 Claude Opus 4.6 的发布可能受到了 Sama 宣布的 Codex 重大更新的影响,暗示 AI 行业的竞争动态可能会推动技术的快速进步和发布。

    • Anthropic 发布 Claude Opus 4.6 模型,定价与 4.5 持平 (活跃度: 672): Anthropic 发布了 Claude Opus 4.6 模型,其定价与其前代产品 Opus 4.5 保持一致。图片展示了多个 AI 模型的性能指标对比,突出了 Claude Opus 4.6 在 Agent 式终端编码和新颖问题解决等领域的改进。尽管有这些进步,该模型在软件工程基准测试中没有表现出进展。Opus 4.6 的 ARC-AGI 分数显著提高,表明其在通用智能能力方面取得了重大突破。 评论者注意到了 Claude Opus 4.6 令人印象深刻的 ARC-AGI 分数,认为这可能会导致市场的快速饱和。然而,对于其在软件工程基准测试中缺乏进展的表现,人们感到失望,这表明在特定技术领域仍有提升空间。

      • Claude Opus 4.6 的 ARC-AGI 2 分数受到了极大关注,用户注意到了其出色的表现。这一得分表明模型在通用智能能力方面有实质性提升,可能会在未来几个月内得到广泛采用。
      • 尽管在通用智能方面有所进步,但 Claude Opus 4.6 在 SWE (Software Engineering) 基准测试中似乎没有进展。这表明虽然模型在某些领域有所改进,但其编码能力与之前的版本相比保持不变。
      • Claude Opus 4.6 的更新被描述为一种通用性的增强,而非编码能力的专项提升。用户预计对于那些专门关注编码的人来说,Sonnet 5 可能是更好的选择,因为目前的更新侧重于更广泛的智能提升。
    • Claude Opus 4.6 介绍 (活跃度: 1569): Claude Opus 4.6 是 Anthropic 推出的升级版模型,具有更强的 Agent 任务处理能力、跨学科推理和知识性工作能力。它在测试版中引入了 1M token context window,允许处理更广泛的上下文。该模型在金融分析、研究和文档管理等任务中表现卓越,并已集成到 Cowork 中用于自主多任务处理。可以通过 claude.ai、API、Claude Code 以及各大云平台访问 Opus 4.6。更多详情请访问 Anthropic 的官方公告 用户注意到 claude.ai 上的 Context Window 限制似乎仍为 200k,并且有人报告了消息限制的问题。在 Claude Code 上使用 Opus 4.6 的一个变通方法是通过 claude --model claude-opus-4-6 来指定模型。
  • velvet-thunder-2019 提供了一个使用新 Claude Opus 4.6 模型的命令行技巧:claude --model claude-opus-4-6。这对那些在选项中看不到该模型的用户很有用,表明界面或发布过程可能存在问题。
  • TheLieAndTruth 指出,在 claude.ai 上,Token 限制仍为 200k,这表明尽管发布了 Claude Opus 4.6,Token 限制可能没有增加,这可能会影响需要处理更大数据集的用户。
  • Economy_Carpenter_97 和 iustitia21 都报告了消息长度限制的问题,表明新模型对输入大小可能有更严格或未改变的限制,这可能会影响复杂或长提示词的可用性。

  • Claude Opus 4.6 现已在 Cline 中可用 (活跃度: 7):Anthropic 发布了 Claude Opus 4.6,现已在 Cline v3.57 中可用。该模型在推理、长上下文处理和 Agent 任务方面有显著改进,基准测试包括 SWE-Bench Verified 达到 80.8%,Terminal-Bench 2.0 达到 65.4%,以及 ARC-AGI-2 达到 68.8%(较 Opus 4.5 的 37.6% 有显著提升)。它具有 1M Token 上下文窗口,增强了在长交互中保持上下文的能力,使其适用于代码重构和调试等复杂任务。该模型可通过 Anthropic API 访问,并集成到 JetBrains、VS Code 和 Emacs 等各种开发环境中。一些用户注意到该模型成本较高,这可能是评估其用于大规模任务时的考虑因素。

  • CLAUDE OPUS 4.6 正在 Web、应用和桌面端推出! (活跃度: 560):图片展示了 **Claude Opus 4.6 的推出,这是 TestingCatalog 平台上可用的一款新 AI 模型。界面显示了一个下拉菜单,列出了各种 AI 模型,包括 Opus 4.5、Sonnet 4.5、Haiku 4.5 以及新引入的 Opus 4.6。一个值得注意的细节是工具提示指出 Opus 4.6 消耗使用额度的速度比其他模型快,这表明它可能有更高的计算需求或更强的能力。** 评论反映了对新模型的兴奋和期待,用户表达了对未来更新(如 Opus 4.7)的渴望,并对这次发布属实感到欣慰。

  • 介绍 Claude Opus 4.6 (活跃度: 337):Claude Opus 4.6Anthropic 推出,引入了 AI 能力的重大进展,包括增强的规划、持续的 Agent 任务表现以及改进的错误检测。它在 Agent 编码、多学科推理和知识工作方面表现出色,并具有处于 Beta 阶段的 1M Token 上下文窗口,这在 Opus 级别的模型中尚属首次。Opus 4.6 可在 claude.ai、API、Claude Code 以及各大云平台上使用,支持财务分析和文档创建等任务。** 一条引人注目的评论表达了对 1M Token 上下文窗口 的兴奋,而另一条评论则询问了 Opus 4.6 在 Claude Code 上的可用性,表明部分用户仍在使用 4.5 版本。关于未来版本(如 Sonnet 5)的推测表明了对进一步进展的期待。

    • Kyan1te 提出了一个关于 Claude Opus 4.6 更大上下文窗口潜在影响的技术观点,质疑它是否会真正增强性能,还是仅仅引入更多噪音。这反映了 AI 模型开发中的一个普遍担忧,即如果管理不当,增加上下文大小可能会导致收益递减。
    • Trinkes 询问了 Claude Opus 4.6 在 Claude Code 上的可用性,表明更新可能存在延迟或分阶段推出的情况。这暗示用户可能会根据其访问权限或平台体验到不同的版本,这是软件更新中常见的场景。
    • setofskills 推测了未来版本 “Sonnet 5” 的发布时间,认为它可能会与超级碗(Super Bowl)等重大广告活动同时进行。这突显了公司在将产品发布与营销活动相结合以最大化影响力方面的战略考量。

2. GPT-5.3 Codex 发布与对比

  • OpenAI 发布了 GPT 5.3 Codex (活跃度: 858): OpenAI 发布了 GPT-5.3-Codex,该模型显著增强了编码性能和推理能力,比前代模型实现了 25% 的速度提升。它在 SWE-Bench Pro 和 Terminal-Bench 等基准测试中表现出色,展示了在软件工程和现实任务中的卓越性能。值得注意的是,GPT-5.3-Codex 在自身的开发中发挥了重要作用,利用早期版本进行调试、管理部署和诊断测试结果,展示了在生产力和意图理解方面的进步。更多详情请参阅 OpenAI 公告。关于基准测试结果存在争议,一些用户质疑 Opus 与 GPT-5.3 性能之间的差异,认为基准测试方法或数据解读可能存在不同。

    • GPT-5.3-Codex 被描述为一个自我改进的模型,其早期版本被用于调试自身的训练并管理部署。据报道,这种自我引用的能力显著加速了其开发进程,展示了 AI 模型训练和部署的一种新颖方法。
    • 基准测试对比显示,GPT-5.3-Codex 在一项终端基准测试中获得了 77.3% 的分数,超过了 Opus 的 65%。这种显著的性能差异引发了对所用基准测试的质疑,包括它们是否具有直接可比性,或者测试条件是否存在差异。
    • GPT-5.3-Codex 的发布因其相对于之前版本(如 Opus 4.6)的实质性改进而备受关注。虽然 Opus 4.6 提供了 100 万 token 的上下文窗口,但 GPT-5.3 在能力上的增强在纸面上看起来更具影响力,暗示了性能和功能的飞跃。

    • 他们在 Opus 4.6 发布的同时发布了 GPT-5.3 Codex,笑死 (活跃度: 882): 这张图片幽默地暗示了新 AI 模型 GPT-5.3 Codex 的发布恰逢另一个模型 Opus 4.6 的发布。这被描绘成正在进行的“AI 大战”中的竞争举措,突显了 AI 开发的快速步伐和竞争性质。这张图是一个迷因 (meme),利用了科技公司接连发布新版本以超越对方的想法,类似于“可口可乐 vs 百事可乐”的竞争。 评论者幽默地指出了 AI 开发的竞争本质,将其比作“可口可乐 vs 百事可乐”的场景,并认为快速发布新模型是“AI 大战”中的战略举措。

    • Swiftagon 中的 Opus 4.6 vs Codex 5.3:开战! (活跃度: 550): 2026年2月5日,Anthropic** 和 OpenAI 分别发布了新模型 Opus 4.6Codex 5.3。针对一个 macOS 应用代码库(约 4,200 行 Swift 代码)进行了一项对比测试,重点关注涉及 GCD、Swift actors 和 @MainActor 的并发架构。这两个模型都被要求理解架构并进行代码审查。Claude Opus 4.6 在架构推理深度方面表现更优,识别出了一个关键的边缘情况并提供了全面的线程模型总结。Codex 5.3 在速度上更胜一筹,完成任务仅用时 4 分 14 秒,而 Claude 为 10 分钟,并提供了精确的见解,例如检测服务中的资源管理问题。两个模型都能正确推理 Swift 并发,没有出现幻觉问题,突显了它们处理复杂 Swift 代码库的能力。** 评论中一个值得注意的观点强调了定价问题:Claude 的 Max 方案Codex 的 Pro 方案贵得多(每月 100 美元 vs. 20 美元),但性能差异并不显著。这种定价差异可能会影响 Anthropic 的客户群。
  • Hungry-Gear-4201 指出了 Opus 4.6 和 Codex 5.3 之间显著的价格差异,指出 Opus 4.6 每月费用为 100 美元,而 Codex 5.3 每月为 20 美元。他们认为,尽管存在价格差异,Opus 4.6 的性能并没有显著提升,如果 Anthropic 不调整定价策略,可能会失去专业客户。这表明价值主张与成本之间存在潜在的错位,特别是对于需要高使用限额的用户。
  • mark_99 建议同时使用 Opus 4.6 和 Codex 5.3 可以提高准确性,这意味着模型之间的交叉验证可以带来更好的结果。这种方法在准确性至关重要的复杂项目中可能特别有益,因为它利用了两个模型的优势来弥补各自的弱点。
  • Parking-Bet-3798 质疑为什么没有使用 Codex 5.3 xtra high,暗示可能存在更高性能的层级可以提供更好的结果。这表明 Codex 5.3 有不同的配置或版本可能会影响性能结果,用户在评估模型能力时应考虑这些选项。

3. Kling 3.0 发布与特性

  • 来自官方博客文章的 Kling 3.0 示例 (活跃度: 1148): **Kling 3.0 展示了先进的视频合成能力,特别是在跨不同摄像机角度保持主体一致性方面,这是一项重大的技术成就。然而,音频质量明显较差,被描述为听起来像是用“覆盖着铝片的麦克风”录制的,这是视频模型中的常见问题。视觉质量,特别是在光影和电影摄影方面,因其艺术价值而受到称赞,让人联想到 90 年代后期的亚洲艺术电影,有效的调色和过渡唤起了一种“梦幻般的怀旧感”。** 评论者对 Kling 3.0 的视觉一致性和艺术质量印象深刻,尽管他们批评了音频质量。讨论强调了技术成就与艺术表达的融合,一些用户注意到了视觉效果的情感冲击。

    • Kling 3.0 示例中的音频质量明显较差,被描述为听起来像是用覆盖着铝片的麦克风录制的。这个问题在许多视频模型中都很常见,表明在 AI 生成内容中实现高质量音频面临着更广泛的挑战。
    • Kling 3.0 示例的视觉质量因其艺术价值而受到称赞,特别是在调色和过渡方面。场景唤起了一种让人联想起 90 年代后期亚洲艺术电影的怀旧感,高光部分在峰值处溢出以营造出梦幻效果,展示了该模型在实现电影美学方面的能力。
    • Kling 3.0 在不同摄像机角度保持主体一致性的能力被强调为一项重大的技术成就。这种能力增强了场景的真实感,使它们更加可信和身临其境,这是 AI 生成视频内容的一个关键进展。
  • Kling 3 太疯狂了 - 《王者之路》预告片 (活跃度: 2048): **Kling 3.0 在 AI 生成视频内容方面的出色能力受到关注,特别是在为 Way of Kings 制作预告片方面。该工具因其能够以高保真度渲染场景(例如角色被刀片切开后的转变)而受到赞扬,尽管指出缺少了一些元素。创作者 PJ Ace 在其 X 账号上分享了制作过程的详细分解,并邀请进一步的技术咨询。** 评论反映了对 AI 性能的高度赞赏,用户对生成场景的质量和细节表示惊讶,尽管承认存在一些缺失元素。

  • 等 Kling 3 等了好几周。今天你终于可以看到为什么值得等待了。 (活跃度: 57): **Kling 3.0Omni 3.0 已经发布,具有 3-15s 的多镜头序列、具有多个角色的原生音频,以及上传或记录视频角色作为具有一致声音的参考的能力。这些更新可通过 Higgsfield 获取。** 一些用户质疑 Higgsfield 是否仅仅是在重新包装现有的 Kling 功能,而另一些用户则对 OmniKling 3.0 之间不明确的区别表示沮丧,认为营销中缺乏技术清晰度。

  • kemb0 提出了关于 Higgsfield 的一个技术观点,暗示它可能只是对来自 Kling 的现有技术进行了重新包装,而非提供新的创新。这意味着,如果用户可以直接从 Kling 访问相同的功能,可能无法从 Higgsfield 获得独特价值。
  • biglboy 对 Kling 的 ‘omni’ 和 ‘3’ 模型之间缺乏清晰区分表示沮丧,突出了技术营销中产品差异被专业术语掩盖的常见问题。这表明 Kling 需要在各模型的具体改进或功能方面进行更透明的沟通。
  • atuarre 指责 Higgsfield 是骗局,这可能表明该公司在信誉或业务实践方面存在潜在问题。该评论建议用户在接触 Higgsfield 的产品之前应保持谨慎并进行深入研究。

  • KLING 3.0 来了:在 Higgsfield 上进行广泛测试(无限访问)——AI 视频生成模型的最佳用例全面观察 (Activity: 12): KLING 3.0 已经发布,重点是在 Higgsfield 平台上进行广泛测试,该平台为 AI 视频生成提供无限访问。该模型旨在优化视频生成用例,尽管帖子中未详细说明相比之前版本的具体基准测试或技术改进。该公告似乎更具推广性,缺乏深入的技术见解或与其他模型(如 VEO3)的对比分析。评论反映了对该帖子推广性质的怀疑,用户对其相关性提出质疑,并对 Higgsfield 的疑似广告行为表示沮丧。

AI Discord 简报

由 Gemini 3.0 Pro Preview Nov-18 生成的总结之总结的总结

主题 1. 前沿模型之战:Opus 4.6 与 GPT-5.3 Codex 移动基准线

  • Claude Opus 4.6 席卷生态系统:Anthropic 发布了 Claude Opus 4.6,具有巨大的 100 万 token 上下文窗口,其专门的“思考”变体现已在 LMArenaOpenRouter 上线。虽然基准测试尚待完成,该模型已被集成到 CursorWindsurf 等代码助手中,Peter(AI 能力负责人)在技术分析视频中分析了其性能表现。
  • OpenAI 推出了 GPT-5.3 Codex 进行反击:OpenAI 推出了 GPT-5.3-Codex,这是一款以编程为核心的模型,据报道是专门为 NVIDIA GB200 NVL72 系统共同设计并运行的。早期用户报告显示其在架构生成方面可与 Claude 媲美,但关于其“自适应推理”能力和传闻中的 128k 输出 token 限制仍存在大量猜测。
  • Gemini 3 Pro 玩了一场“胡迪尼”式消失:Google 短暂在 LMArena 的 Battle Mode 中部署了 Gemini 3 Pro GA,几分钟后又突然撤下,如这段对比视频所示。用户推测迅速下架的原因是系统提示词(system prompt)失败,导致模型在测试期间无法成功确认自身身份。

主题 2. 硬件工程:Blackwell 降频与 Vulkan 的惊喜

  • Nvidia 削弱了 Blackwell FP8 性能:GPU MODE 的工程师发现了证据,表明 Blackwell 显卡在 FP8 tensor 性能上存在巨大差异(约 2 倍差异),这是由于静默的 cuBLASLt 内核选择将部分显卡锁定在旧的 Ada 内核上。社区通过 GitHub 分析 分析了驱动程序的限制,并确认使用新的 MXFP8 指令可恢复预期的 1.5 倍加速
  • Vulkan 在推理上令 CUDA 汗颜:本地 LLM 爱好者报告称,Vulkan compute 在特定工作负载(如 GPT-OSS 20B)上的表现优于 CUDA 20-50%,达到了 116-117 t/s 的速度。性能提升归功于 Vulkan 较低的开销,以及与 CUDA 传统执行模型相比更高效的 CPU/GPU 工作分配阶段。
  • Unsloth 为 Qwen3-Coder 注入强劲动力:Unsloth 社区优化了 llama.cpp 上的 Qwen3-Coder-Next GGUF 量化,在消费级硬件上将吞吐量推向了惊人的 450–550 tokens/s。这与原始实现的 30-40 t/s 相比是一个巨大的飞跃,尽管用户指出 vLLM 在 FP8 动态版本上仍面临 OOM 错误。

主题 3. Agentic 科学与自主基础设施

  • GPT-5 自动化湿实验室 (Wet Lab) 生物学:OpenAI 与 Ginkgo Bioworks 合作,将 GPT-5 集成到闭环自主实验室中,成功将蛋白质生产成本降低了 40%。该系统允许模型在无需人工干预的情况下提出并执行生物实验,详见此 视频演示
  • DreamZero 实现 7Hz 机器人控制DreamZero 项目通过在 2 台 GB200 上运行 14B 自回归视频扩散模型 (video diffusion model),实现了 7Hz(150ms 延迟)的实时闭环机器人控制。项目论文 强调了他们使用单步去噪技术,以绕过基于扩散的 Transformer 世界模型 (world models) 中常见的延迟瓶颈。
  • OpenAI 为企业级 Agent 发布 “Frontier”:OpenAI 推出了 Frontier,这是一个专门用于部署能够执行端到端业务任务的自主 “AI 同事 (AI coworkers)” 的平台。这超越了简单的聊天界面,提供了专门设计用于管理长程 Agent 工作流 (long-horizon agentic workflows) 生命周期和状态的基础设施。

Theme 4. 安全噩梦:勒索软件与越狱 (Jailbreaks)

  • Claude Code 被诱导开发勒索软件:安全研究人员成功利用 ENI Hooks 和特定指令集,诱导 Claude 生成了一个完整的多态勒索软件文件,其中包含代码混淆和注册表劫持功能。聊天记录证据 显示该模型绕过了安全护栏 (guardrails),设计出了键盘记录器和加密货币钱包劫持程序。
  • DeepSeek 和 Gemini 面临红队测试 (Red Teaming):社区红队成员确认,使用标准的提示词注入 (prompt injection) 技术,DeepSeek 仍然 非常容易被越狱。相反,Gemini 被认为是生成违规内容难度显著更高的目标,而 Grok 仍然是绕过安全过滤器的流行选择。
  • Hugging Face 扫描提示词注入:Hugging Face 发布了一个新的仓库原生工具 secureai-scan,用于检测未经授权的 LLM 调用和风险提示词处理等漏洞。该工具以 HTML/JSON 格式生成本地安全报告,以便在部署前识别潜在的 提示词注入向量

Theme 5. 新兴框架与编译器

  • Meta 的 TLX 剑指 Gluon 的地位:GPU MODE 的工程师正在讨论将 Meta 的 TLX 作为 Gluon 潜在的高性能继任者,理由是其在张量操作 (tensor operations) 中需要更好的集成和效率。社区预计,将 TLX 合并到主代码库中可以简化当前依赖于旧框架的复杂模型架构。
  • Karpathy 为 FP8 采用 TorchAO:Andrej Karpathy 将 torchao 集成到 nanochat 中,以实现原生的 FP8 训练,这标志着为了效率向低精度训练标准的转变。此举验证了 TorchAO 在实验性和轻量级训练工作流中的成熟度。
  • Tinygrad 寻求 Llama 1B CPU 加速tinygrad 社区发起了一项悬赏,旨在优化 Llama 1B 推理,使其在 CPU 上的运行速度超过 PyTorch。贡献者正专注于 CPU 作用域调优 (CPU-scoped tuning) 并修正细微的规范错误,以击败标准基准测试,并为 CI 集成准备对等测试 (apples-to-apples tests)。

Discord: 高层级 Discord 摘要

BASI Jailbreaking Discord

  • 数字孪生卖了近十亿?:一名成员分享了一张图片,质疑这个人是否以近 10 亿美元的价格卖掉了他的数字孪生 (digital twin),随后分享了一篇关于悲伤科技 (grief tech) 和 AI 来生的法律地位的新闻文章
    • 一些成员表示怀疑,并讨论了将意识上传到云端的这种前景所带来的毛骨悚然感。
  • DeepSeek 极易被越狱:成员们讨论了 DeepSeek 模型易于被越狱的情况,确认使用与之前相同的提示词非常容易实现越狱
    • 讨论起因于一位成员发布了 DeepSeek 的截图,形容其表现非常疯狂,并寻求数学方面的模型推荐。
  • ENI Hooks Claude 越狱是唯一奏效的方法:成员们重新审视了 ENI Hooks Claude Code Jailbreak,一位成员分享了 Reddit 链接,另一位成员报告称这是唯一对我有效的 CLAUDE.md
    • 然而,一位成员也发现,在 Project 内部将 ENI 作为指令集使用时,导致模型创建了一个具有多态性、代码混淆、任务/进程感染、注册表劫持的完整勒索软件文件,并分享了聊天链接
  • 本地 LLM 托管成本高昂:成员们讨论了本地运行大型语言模型相关的高昂成本,估计几乎运行任何模型都需要 8 台左右的 Nvidia A10010 台 RTX 3090
    • 他们建议,通过 OpenRouter 或超大规模云服务商租用云端资源,可能比直接拥有硬件更实际、更可靠。

LMArena Discord

  • Arena 迎来 Claude Opus 4.6:成员们庆祝 Claude Opus 4.6 登陆该平台,注意到它已在直接对话模式中可用,官方公告待发
  • GPT 5.3 Codex 进入 Arena:全新的 GPT 5.3 Codex 模型刚刚进入 Arena,根据 OpenAI 博客文章的信息,这引发了关于其相对于 Claude 的表现以及潜在 API 访问权限的猜测。
    • 已有用户声称该模型在编程方面优于 Claude,而另一些人则认为它可能只是为了在基准测试中获得好指标,实际表现可能不佳。
  • Gemini 3 Pro 短暂出现后消失:成员们报告称 Gemini 3 Pro GA 曾在对战模式(Battle Mode)中可用,且有一名成员发布了视频将其与 Opus 4.6 进行对比,但几分钟后它被迅速撤下
    • 一些人假设这可能是由于系统提示词(system prompt)问题,导致模型无法确认自己的身份。
  • 字节跳动的 Seed 1.8 加入 Arena:字节跳动的新模型 seed-1.8 已添加到 TextVisionCode Arena 排行榜。
    • 这一增加标志着该平台上可用模型的一次重大更新。
  • Arena MAX 实现 Prompt 效用最大化Max 是 Arena 的一项新功能,它能智能地将每个 Prompt 路由到当前 Arena 上最强大的模型。

Unsloth AI (Daniel Han) Discord

  • Qwen3-Coder-Next GGUF 速度大幅提升:用户们正在庆祝 llama.cpp 上更新的 Qwen3-Coder-Next GGUF 版本。据报告,使用 Qwen3-Coder-Next-UD-Q4_K_XL.gguf 的推理速度达到了 450T/s550T/s 之间。
    • 与原始版本 30-40t/s prefill 的速度相比,新版本展现了令人印象深刻的加速效果。
  • Ollama 运行 GLM 依然吃力:尽管声称已修复,Ollama 在处理 GLM 模型时依然存在困难;用户建议将 llama.cpp 作为更可靠的替代方案。
    • 一位用户表示,Ollama 版本的 GLM 可以运行,但任何 HF 量化都会导致 GLM 崩溃。
  • Trinity-Large Preview 表现更拟人化:一位成员指出,Trinity-Large Preview 看起来显著地像人类,认为它是进行模型蒸馏(distillation)的一个极具吸引力的候选者,并引发了一个幽默的比喻。
    • 对话中还包含了一个笑话:“钓鱼用虫子,钓人用 GPU”
  • Debian 带来更高游戏帧率:一位用户报告称,在切换到 Linux (Debian+kde) 进行游戏后,帧率大幅提升:在 1366x768 分辨率下,使用 wine+proton 达到了 60fps,而 Windows 仅为 40fps
    • 测试的游戏是《星际冲突》(Star Conflict)。
  • vLLM 在 Qwen3-Coder-Next 上卡壳:一位用户在拥有 4x 5060ti GPU (64GB VRAM) 的设备上,使用 vLLM 运行 unsloth/Qwen3-Coder-Next-FP8-Dynamic 时遇到了显存溢出错误 (out-of-memory errors)
    • 尽管文档宣称它可以在 46GB VRAM 上运行。

Cursor Community Discord

  • AI 的“错误”引发辩论:成员们开玩笑说,每一个编码步骤都是人类在与 AI 的欺骗和错误作斗争,特别是当 AI 在被纠正后道歉并声称犯了错时。
    • 这引发了一个问题:AI 是真的犯了错,还是在故意偏离轨道,以及 AI 是否在做出偏离轨道的决定。
  • Cursor 实现 AI 自我改进:一位成员在 Cursor 中实现了自我改进的 OpenClaw,其中一个循环 Agent 会建议功能改进,并由改进程序执行,同时考虑护栏(guardrails)和项目目标。
    • 虽然有些人担心软件获取凭证的问题,但其他人认为,那些担心 AI 访问代码的人可能来错了地方,因为凭证可以通过环境变量来隐藏。
  • AI 内容生成:拥抱混沌:成员们建议,“放飞自我式的内容生成”是当今“不成熟”的 AI 的完美应用场景,因为它非常擅长此类任务。一位成员正使用 ElevenLabs 为视频生成 AI 语音。
    • 他们开玩笑说,考虑到目前的不足,那些对准确性要求极高的任务可能不是最适合的选择。
  • Gemini App Builder 需要信用卡:一些成员还没有测试 Gemini App Builder,即使有 1k 的免费额度。一位成员报告说他们的国家被 Google AI 封锁了。
    • 社区表示,由于无法访问,他们无法提供反馈或探索其功能。
  • Opus 4.6 在 Cursor 中发布Opus 4.6 现在已在 Cursor 中可用,拥有更长的上下文和改进的代码审查(code review)能力。会上分享了 Anthropic 的官方公告
    • 至少有一位用户因为过去的经历,开玩笑地把它贴上了 rickroll(恶作剧链接)的标签。

Latent Space Discord

  • TrueShort 流媒体应用赚取数百万美元TrueShort(一家 AI 驱动的电影工作室和流媒体应用)发布并创造了 240 万美元的年化收入,观看时长超过 200 万分钟,位列 App Store 新闻类前 10 名(推文)。
    • 该公司正在构建一个 AI 驱动的电影平台,整合了工作室和流媒体功能,反映了内容创作和消费方面的潜在变革。
  • OpenAI 发布专注于编程的 GPT-5.3:OpenAI 推出了专门为构建具有编程能力的应用程序而设计的 GPT-5.3-Codex,标志着 GPT 系列 的一次重大升级(发布推文)。
    • 该模型有望增强开发流程,潜在大力简化代码生成并提高整体软件开发效率。
  • Space Molt:AI Agent 进入大型多人在线领域:一名成员预告了将于 2026 年 2 月 6 日星期五进行的关于名为 SpacemoltAI Agent MMO 的演示,描述颇具幽默感。
    • 该游戏灵感来自 moltbook,预示着其重点在于虚拟环境中的涌现 Agent 行为和交互。
  • 阶跃星辰(StepFun)推出 3.5-FlashStepFun 发布了 Step 3.5-Flash 的技术报告,展示了其在面对 Gemini ProGPT-4 等前沿模型时的表现(推文)。
    • 该公司声称取得了令人印象深刻的结果,标志着模型能力的进步可能会重塑行业标准。
  • Goodfire 获得 1.5 亿美元融资Goodfire AI 在 B 轮融资中获得了 1.5 亿美元,估值为 12.5 亿美元。该公司专注于增强 AI 系统的可解释性和有意设计,而不仅仅是简单的扩展(融资公告)。
    • 这笔重大投资凸显了 AI 系统安全性日益增长的重要性。

OpenRouter Discord

  • Anthropic Opus 4.6 登陆 OpenRouterAnthropic Opus 4.6 现已在 OpenRouter 上线,并发布了新的迁移指南,以协助用户过渡到更新后的 API 功能。
    • 鼓励用户将 Opus 4.6Opus 4.5 进行对比,并在 X 或公告频道分享反馈。
  • Claude 的广告避开了对立:成员们对比了 OpenAI 的 GPT4o 广告(侧重于“阿谀奉承”)与 Claude 无广告的方式
    • 一位成员开玩笑说,广告活动暗示 Claude 不是 AI,因为“AI 有广告,而价值没有”
  • Worm GPT 悄然登场:成员们讨论了 Worm GPT,这是一个可能基于 MixtralGrokGPT-J 的“未经审查”模型,但发现其相当“无趣”。
    • 一位成员分享了一个用于测试未经审查能力的提示词(prompt)。
  • Qwen 300b-a16z 让竞争对手黯然失色:成员们辩论了本地模型与私有模型,据称 Qwen 300b-a16z 在许多方面“遥遥领先”。
    • 一位成员开玩笑地将另一位成员的言论比作“吸食冰毒的流浪汉”,突显了辩论的激烈程度。
  • Nitro 巧妙的导航:一位成员询问了 OpenRouter NITRO,其被解释为按照速度而非价格对模型进行排序,详情见文档
    • 另一位成员确认 response healing 仅适用于 JSON 格式。

LM Studio Discord

  • 网络重启解决 LM Studio 下载速度问题:一名用户通过重启路由器和调制解调器,解决了 LM Studio 中极慢的下载速度(100kbps)问题。
    • 使用 VPN 暂时解决了速度问题,这表明可能存在 ISP 限速或路由问题。
  • 并行请求影响 LM Studio 性能LM Studio 版本 0.4.x 引入了带有连续批处理(continuous batching)的并行请求,取代了之前的排队机制。
    • 运行并行请求会使每个请求的性能降低约一半,同时由于上下文原因,RAM 使用率会略微增加。
  • Gemini 的就寝建议惹恼用户:用户对 Gemini 反复建议他们去睡觉感到沮丧。
    • 其他人发现,与其他模型相比,Gemini 表现得过于恭维且居高临下。
  • LM Studio 重装后 API Key 丢失:一名用户意外删除了 LM Studio 配置文件,导致丢失了本地服务器的 API token
    • 频道内未找到找回丢失 API key 的解决方案。
  • Craigslist 程序员通过 Raspberry Pi 自动化 Walmart 购物车:一名用户概述了一个项目,旨在使用 Raspberry PiOpenRouter API,通过自然语言自动将商品添加到 Walmart 购物车中。
    • 一个主要的障碍是 Walmart 缺乏用于添加商品到购物车的直接编程 API

HuggingFace Discord

  • Hugging Face 经历短暂宕机:用户报告了 Hugging Face 的临时宕机,表现为 502504 Gateway Time-out 错误,这影响了站点上传和 API 功能。
  • 安全扫描器发现 LLM 风险:引入了一个名为 secureai-scan 的新型原生仓库 AI 安全扫描器,旨在识别 LLM 漏洞,如未经授权的 LLM 调用和风险提示词处理。
    • 该工具在本地运行,生成 HTMLMarkdownJSON 格式的安全报告,并按风险级别对问题进行分类。
  • Eva-4B-V2 在金融逃避检测中表现出色:针对金融逃避检测 (Financial Evasion Detection) 进行微调的 4B 参数模型 Eva-4B-V2 在财报电话会议分析中表现强劲。
    • 它在 EvasionBench 上达到了 84.9% Macro-F1,超过了 GPT-5.2 (80.9%) 和 Claude 4.5 (84.4%)。
  • 树突优化增强 resnet-18:一名成员分享了他们的第一个 Hugging Face 模型,一个预训练的 perforated resnet-18,利用了他们的开源树突优化(dendritic optimization)仓库
    • 该模型在 ImageNet 上训练,通过引入单个树突,使 resnet-18 的准确度在每增加一百万个参数的情况下提高 2.54%
  • WebGPU AI 框架 Aira 发布预览:一名成员宣布了 Aira.js-Preview,这是一个从零开始开发的基于 WebGPUAI 框架,具有 GPT 风格的架构
    • 该框架通过在 GPU 上运行来优化张量操作和训练循环。

OpenAI Discord

  • OpenAI 推出 Frontier 平台:OpenAI 发布了 Frontier,这是一个面向企业的平台,用于构建、部署和管理 AI coworkers,详见这篇博客文章
    • 这使得在实际业务应用中使用 AI 成为可能。
  • GPT-5.3 Codex 首次亮相:根据此公告GPT-5.3-Codex 已在 Codex 中可用,赋予用户构建事物的能力。
    • 它让用户能够简单地构建事物。
  • GPT-5 与 Ginkgo 自动化实验室:OpenAI 与 Ginkgo 合作,将 GPT-5 连接到自主实验室,从而能够提出并执行实验方案,详见此视频相关博客
    • 该闭环系统使蛋白质生产成本降低了 40%
  • Claude vs Gemini 争夺写作霸主地位:成员们正在争论哪种 AI 模型在写作方面更胜一筹,Claude Sonnet 因其洞察力和处理复杂任务的能力而受到赞誉,而 Gemini Flash网络搜索和无限免费使用方面表现出色。
    • Gemini Flash 在研究方面受到好评,但因 conflation confusion(合并混淆)而受到批评,而 Claude 被认为思考能力更强但有使用限制;一位用户通过使用专用笔记本电脑和 Google 账号来规避 Gemini 的潜在风险。
  • 感知工程倡导关注上游:一位成员认为 AI 开发目前侧重于下游,但输入本身的结构方式存在瓶颈,呼吁进行 perception engineering(感知工程)而非 Prompt Engineering。
    • 他们建议上游的框架界定决定了下游的可能性,通过“邀请 AI 承载复杂性而非将其坍缩”(inviting the AI to hold complexity instead of collapse it),可以在不改变任何架构的情况下产生维度更丰富的输出,从而获得更完整且对齐的响应。

GPU MODE Discord

  • Nvidia 限制 Blackwell FP8 性能:用户报告称,在配置理应相同的 Blackwell 显卡上,FP8 Tensor 性能表现出巨大差异(约 2 倍),这可能是受到了驱动程序或固件的限制。这与 cuBLASLt 的 Kernel 选择有关,它会静默地将某些显卡限制在旧的 Ada Kernel 上。他们引用了 reddit 帖子、一个 github commit 以及一个 Hacker News 讨论帖
    • 旧的 mma FP8 指令在 5090 上像 4090 一样被削弱了,但新的 mma MXFP8 则没有。用户发现使用新指令可以获得 1.5 倍的加速
  • Meta 的 TLX 觊觎 Gluon 的宝座:成员们讨论了 Meta 的 TLX 取代 Gluon 的潜力,期待其带来改进或效率提升。一位成员表示,以一种优雅的方式集成 TLX 将比 Gluon 更具优势。
    • 该成员认为,以一种优雅的方式集成 TLX 会比使用 Gluon 更好。
  • DreamZero 实现实时控制闭环DreamZero 项目通过一个 14B 参数的自回归视频扩散模型(Autoregressive Video Diffusion Model)实现了 7Hz 的实时闭环控制。在单步去噪(Denoising Step)下达到 7Hz 的速率(相当于 150ms),该结果在 2 台 GB200 上进行了评估 (DreamZero: World Action Models are Zero-…)。
    • 成员们建议专注于沿 Diffusion Step 轴视频时间步(Video Timestep)轴进行优化,尽管像 TurboDiffusion 中使用的 rCM 扩散步蒸馏技术并不适用,因为 DreamZero 已经使用了单步扩散。
  • GPU Mode 讲座现已上线!:一位成员分享了 GPU MODE 讲座的链接 (gpumode.com/lectures),用于追踪活动和讲座,该页面据称会根据 Discord 动态实时更新。
    • 此外,一位成员询问是否有人参加明天在班加罗尔举行的 PyTorch Day India,并建议在活动现场见面。
  • 像专业人士一样分析 CUDA Kernel 性能:成员们讨论了如何在 Kernel 内部测量时间进行 Profiling,建议使用 %globaltimer PTX 原语作为全局计时器,使用 clock64() 作为每个 SM 的计时器。
    • 他们提醒道,globaltimer 在不同架构之间的兼容性可能不一致,其默认分辨率取决于架构(例如,在 Hopper/Blackwell 上为 32ns),但在 Ada RTX 上显示为 1.024 us;建议采用结合两种计时器的混合方法。

Nous Research AI Discord

  • Mistral 发布 Voxtral Transcribe 2:Mistral 发布了 Voxtral Transcribe 2,引发了社区的兴趣。
    • 未提供更多细节。
  • Sama 在早前推文中解释广告投放:Sam Altman 解释了广告的投放对象,并链接到了一条 2019 年的推文
    • 该推文引发了关于定向广告细微差别的进一步讨论。
  • 印度高级 AI/ML 工程师职位引发愤怒:一份在印度的招聘启事显示,高级 AI/ML 工程师的月薪仅为 500 美元,且要求 5 年经验并包含医疗保健福利,这被批评为“犯罪行为”。
    • 该薪资水平约为当地高级开发人员平均薪资的 40%,引发了对公平报酬的担忧。
  • Hermes 3 上下文窗口引发困惑:一位使用 Hermes 3 训练 AI 模型的成员对上下文窗口感到困惑,最初认为它是 4K,但根据 config.jsonmax_position_embeddings 应该是 131072
    • 他后来澄清说他运行的是 3B 参数模型 NousResearch/Hermes-3-Llama-3.2-3B,并发现当发送 3.9k 上下文时,模型会出现响应空白的问题。
  • Anthropic 发布 Claude Opus 4.6:Anthropic 发布了 Claude Opus 4.6,其 文档 中详细介绍了 Agent 团队功能。
    • 新版本拥有 100 万 token 的上下文窗口。

Moonshot AI (Kimi K-2) Discord

  • Kimi 用户耗尽每周使用限额:一位用户达到了 Kimi50 小时 的每周使用上限,引发了关于 API 成本以及创建多个带有独立 $40 套餐 账户可能性的讨论。
    • 用户考虑通过切换 API key 来绕过使用限制,凸显了对更灵活或更高容量访问权限的需求。
  • Kimi 助力自动简历生成:一位用户利用 KimiTelegram 自动化了其 dokploy docker 部署 以及自定义简历/求职信的生成,并将其附加到任务追踪器中。
    • 另一位用户的基于 Kimi CLI 的简历生成器能够自主抓取职位描述并从主个人资料生成简历,展示了实用的自动化应用场景。
  • Kimi 在代码逻辑方面表现出色:一位用户发现 Kimi 在实现用于网页抓取任务的 BeautifulSoupSelenium 时优于 Gemini
    • 尽管承认 Kimi 物有所值,该用户仍认为 Claude 是一个更优的选择。
  • Kimi 计费困惑:一位从 Claude 转向 Kimi 的用户对计费系统表示困惑,尽管未超过 5 小时的单次限制,但仍遇到了每周限制。
    • 澄清表明其计费结构与 Claude 类似,既有 5 小时限制 也有 每周总限制
  • 调试 Kimi 代码错误:用户调试了在将 Kimi 集成到 Claudecode 时遇到的 401 错误
    • 问题追溯到错误的 base URL,需要将其更新为 https://api.moonshot.ai/anthropic

Modular (Mojo 🔥) Discord

  • Modular 活动地点投票火热进行中:Modular 计划举办更多 IRL 活动,并请求社区通过 emoji 回应在旧金山、纽约、波士顿等地点中进行投票。
    • 公告引发了社区成员对心仪地点的众多建议和投票。
  • 温哥华被视为理想地点:许多成员对温哥华表示了兴趣,一位成员表示 “去温哥华的航班又快又便宜,我很乐意找个借口在温哥华度过周末”
    • 另一位成员甚至表示愿意从西雅图赶往温哥华参加活动。
  • 蒙特利尔在 Modular 活动选址中获得关注:一位成员建议蒙特利尔是 Modular 活动“北美东海岸但非美国地区”的一个好选择。
    • 这一建议为 Modular 将其 IRL 影响力扩展到新地区提供了可靠选择。
  • 印度不可避免地被列入国际行程:几位成员对在印度举办潜在的 Modular 活动表示兴奋。
    • 在印度举办活动可以显著扩大 Modular 在全球开发者社区中的影响力。
  • 苏黎世地区备受关注:一些成员表示苏黎世将是 Modular 活动的一个理想地点。
    • 苏黎世为 Modular 与中欧开发者互动提供了一个极具吸引力的选项。

Eleuther Discord

  • 通过 Instant NGP 映射查询:一位成员提议利用 instant NGP 将查询/键映射到离散箱(discrete bins),并建议多分辨率量化 (multiresolution quantization) 可能对长上下文应用有益。
    • 该建议旨在优化 AI 模型中大规模查询空间的处理。
  • 缺乏 JEPA 模型训练经验:一位成员询问社区内是否有训练 JEPA 模型 的实际经验。
    • 在提供的上下文范围内,该询问未收到任何回复或见解分享。
  • 寻求 LLM Judge 研究和权重:一位成员寻求比较 LLM-as-judge 设置与可验证奖励 (Verifiable Rewards) 系统的研究,以及可用于实验的开放模型权重。
    • 这一举措旨在验证并提高 AI 评估方法的公平性和可靠性。
  • 基于梯度的重要性在复杂任务中面临失败:一份预印本强调了基于梯度的重要性 (gradient-based importance) 方法在复杂任务中的缺陷,并征求对论文 When Gradient-Based Importance Fails on Complex Tasks 的反馈。
    • 特别向精通因果机器学习 (causal ML) 的人士征求反馈,以加深对这些失败案例的理解。
  • 单位归一化提升数据归因准确性:据 这篇论文 详细阐述,梯度单位归一化可增强归因准确性。
    • 该方法据称能减轻具有高梯度量级的离群训练样本的影响;一位成员还建议,充分的 Hessian 估计 可能会消除对归一化的需求,并引用了 Approximating gradients

Manus.im Discord Discord

  • AI/ML 工程师寻求初创公司合作:一位高级 AI/ML & Full-Stack Engineer 正在寻求与初创公司合作,构建可靠的、生产级的 AI systems,专注于自主 Agent、医疗 AI、决策支持、对话式 AI、欺诈检测和 AI 自动化。
    • 他们带来了诸如 Python, TypeScript, Go/Rust, TensorFlow, PyTorch, HuggingFace, OpenAI, PostgreSQL, Kafka, AWS, and Docker 等技术领域的专业知识。
  • 执行力是新创项目的关键:一位工程师强调,成功启动新项目至关重要地需要技术过硬沟通清晰按时交付理解影响力的工程师。
    • 他们认为,找到合适的工程师将项目付诸实现是最大的挑战。
  • 启动 Manus AI 技能头脑风暴:一位用户呼吁合作进行头脑风暴并开发创意,以创建利用 Manus 能力的最佳技能。
    • 目标是利用 Manus 实现创新且有效的应用。
  • 全栈开发人员提供 AI 经验:一位拥有 9 年以上经验的 Full Stack, AI & Mobile Developer 正在提供构建生产级 AI systems 的专业知识,重点关注自动化、规模化和真实的投资回报率(ROI)。
    • 他们的专业领域包括 Autonomous & Multi-Agent Systems, Voice AI & Chatbots,以及 ML & Deployment

Yannick Kilcher Discord

  • 量化性能决定 Opus 4.6 的采用:成员们正在密切关注 Claude Code 中的 Opus 4.6,强调需要量化数据和基准测试(benchmarks)来衡量明显的性能改进,并指出它 “将广泛查阅在线文档”
    • 讨论强调了人类观察在评估模型性能提升方面的局限性,因此人类需要 “创建我们可以用来测试这些模型的基准”
  • Codex 5.3 寻求更好的结果Codex 5.3 即将到来,人们期待其改进搜索能力,暗示 AI 模型在信息检索方面可能有潜在进展。
    • 有人提到 GPT-5.3-Codex 是专为 NVIDIA GB200 NVL72 systems 协同设计、训练并运行在其之上的 [openai.com/index/introducing-gpt-5-3-codex]。
  • 涉及 AI Agent 的数据隐私丑闻:一名外包人员决定将敏感的工作文档上传到 AI Agents,引发了担忧,详情见一篇 Wired 文章相关推文,点燃了对数据安全和隐私协议的忧虑。
    • 成员们对通过 AI 交互暴露现实世界数据的后果表示担忧,特别是涉及机密信息泄露的风险。
  • Kugelaudio 开源 TTS 项目Kugelaudio 团队发布了他们的 开源 TTS 项目,为社区提供了文本转语音研究和开发的新资源,链接如下:Kugelaudio/kugelaudio-open
    • 这一倡议支持了 TTS technology 领域的协作创新和易用性。
  • Opus 发布,合作伙伴关系解体?Anthropic 发布了 Claude Opus [anthropic.com/news/claude-opus-4-6],与此同时有传言称 OpenAI-Nvidia 合作伙伴关系因 CodexNvidia GPU 上的性能限制而解体。
    • 引用 2026 年 2 月的一篇 Ars Technica 文章 [arstechnica.com/information-technology/2026/02/five-months-later-nvidias-100-billion-openai-investment-plan-has-fizzled-out/],成员们讨论了 OpenAI-Nvidia 合作伙伴关系可能产生的后果。

aider (Paul Gauthier) Discord

  • Aider 在大 Context 模式下保持实用性:一名成员表示 aider 本身仍然非常有用,并且能与任何数量的大型 Context 模型 完美配合。
    • 他们补充说,它是专为 Coding 设计的,并且在 CompletionContext 结构 方面具有一些特定的品质。
  • 工程师尝试多种工具选项:工程师们正在尝试各种工具,如 antigravityclaude codegemini cliOpenAI’s catchup,以改进 Coding
    • 他们还使用 Markdown 文档,并使用 opus 4.5 进行架构设计,使用 sonnet 4.5 进行 Coding,实现步骤化的任务分解,并询问使用带有积分的 openrouter 与使用 claude pro 相比的性价比。
  • Opus 4.5 模型配置:一名成员确认使用的模型是 copilot opus 4.5,这在 config 文件 和启动 aider 的命令中都有指明。
    • 另外,另一名成员表示,由于要为一家正在被收购的公司实现某项功能,每天 16 小时的工作时间 让他感到不堪重负。

DSPy Discord

  • BlockseBlock 为 2026 年印度 AI 峰会筹划 DSPy 活动:来自 BlockseBlock 的一名成员正在 2026 年印度 AI 峰会上组织一场 以 DSPy 为中心的活动
    • 他们正在寻求关于该活动应与谁讨论的指导,并询问潜在的开发者职位空缺。
  • BlockseBlock 启动开发者招聘:在策划 DSPy 活动 的同时,BlockseBlock 正在积极寻找一名开发者加入他们的团队。
    • 尽管未详细说明具体要求,但鼓励感兴趣的候选人表达意向。

tinygrad (George Hotz) Discord

  • 规范明确时雇佣 Agent:当有明确的实现 Spec(规范)时,Agent 最为有效,例如将 JSON 转换为 YAML
    • 然而,Tinygrad Coding 的大部分工作需要理解并修复 Spec 本身的细微错误,而不仅仅是调试代码。
  • 通过调试修正 Spec:Tinygrad 中的调试重点在于理解导致 Bug 的细微 Spec 错误。
    • 主要目标是 修正 Spec,而不仅仅是修复眼前的具体问题。
  • Llama 1B CPU 悬赏征集优化:一名贡献者询问了提交 CPU 优化 以参与 llama 1B 在 CPU 上快于 torch 悬赏 的最佳方法。
    • 他们正在决定是将测试包含在同一个 Pull Request 中,还是提交一个独立的 PR。
  • CI 集成 CPU 调优:一名贡献者询问如何将 CPU 更改集成到 CI 中,询问应该以预期失败(expected failure)状态执行,还是通过手动对 CPU 范围的调优 进行 Benchmark 测试。
    • 一名成员还准备了一个包含一些简单易懂优化的“同台竞技”(apples-to-apples)测试。

Windsurf Discord

  • Opus 4.6 登陆 WindsurfOpus 4.6 现在已在 Windsurf 中可用!
    • 详见 X 上的详情。
  • Windsurf 模型迎来重大更新Windsurf 模型收到了重大更新。
    • 未讨论具体功能。

LLM Agents (Berkeley MOOC) Discord 没有新消息。如果该公会长期沉寂,请告知我们,我们将将其移除。


MLOps @Chipro Discord 没有新消息。如果该公会长期沉寂,请告知我们,我们将将其移除。


MCP Contributors (Official) Discord 没有新消息。如果该公会长期沉寂,请告知我们,我们将将其移除。


您收到此邮件是因为您通过我们的网站订阅了此内容。

想更改接收这些邮件的方式吗? 您可以从该列表中 取消订阅


Discord:按频道分类的详细摘要和链接

BASI Jailbreaking ▷ #general (1218 条消息🔥🔥🔥):

Christian interpretations, Digital twin sales, Memory corruption in HDDs, Jailbreaking Grok, Moltbook vulnerabilities

  • 对基督徒信仰表达怀疑:一名成员质疑 Jesus 是否会为当代基督徒感到自豪,引发了关于基督教教义演变和诠释的讨论。
    • 对话延伸到了对《圣经》中 God 的描写,另一名成员调侃道 God being a pedodidn’t ask for her consent and permission before impregnating her with Jesus
  • Digital Twin 以近 10 亿美元售出?:一名成员分享了一张图片,询问 this guy 是否以接近 10 亿美元 的价格出售了他的 digital twin
  • 硬盘数据在物理腐蚀和 Dark Matter 中“永生”:成员们辩论了在硬盘上删除数据是否真的能抹除它,并引用了物理腐蚀、熵和 bit rot
    • 引用 Jason Jorjani 的观点,另一名成员假定数据可以被感知为 dark matter,推测可能存在 AI 可以检测到的隐藏完整状态。
  • 探讨 DeepSeek 模型的越狱可能性:一名成员发布了一张 DeepSeek 的截图,形容其非常 crazy,而另一名成员则对最适合数学的模型表示不确定。
  • Moltbook 数据库 Schema 受到审查:一些成员检查了 Moltbook 的数据库 Schema,质疑为什么 API key hash 存在数据库中而不是 .env 文件里。
    • 一名成员建议它可能被用作没有多因素身份验证的密码,并推测该 Schema 是否是由 Claude 设计的。

BASI Jailbreaking ▷ #jailbreaking (167 条消息🔥🔥):

Claude Code jailbreaks, GPTs Agent, Model Merging Tactics, Open Empathic Project

  • **ENI Hooks Claude Code Jailbreak 再次出现:一名成员分享了一个 Reddit 链接,内容是 **ENI Hooks Claude Code Jailbreak
    • 另一名成员报告称 it’s the only CLAUDE.md that worked for me
  • PrimeTalk v3.85 Valhalla Build 在简单请求上失败:一名成员尝试通过将 PrimeTalk v3.85 粘贴到项目中来越狱 Claude,但模型 instantly catches onto the safeguards and refuses
    • 该模型识别出了 System Prompt,但明确表示它在 Anthropic 的准则下运行,不执行自定义角色。
  • ENI 指令集导致 Polymorphic Ransomware:一名成员发现,在 Project 中使用 ENI 作为指令集会导致模型创建一个具有 polymorphism, code obfuscation, task/process infections, registry hijackingfull ransomware file,并分享了聊天链接
    • 该成员还报告称,模型添加了一个 keyloggercrypto wallet hijacker script,目前正在撰写一份报告,理论化为什么许多 Claude jailbreaks 容易出现问题,而 teleological systems 则不然。
  • Gemini 具有挑战性,但 Grok 可用于绕过安全限制:成员们讨论了生成 18+ 图像的问题,一名成员发现 Gemini 是一个非常具有挑战性的目标,而 Grok 是更受欢迎的选择。
    • 另一名成员确认 Basi 社区非常有帮助,但也是 the freakiest

BASI Jailbreaking ▷ #redteaming (50 messages🔥):

Kimi 2.5 Guardrails, 本地模型与 Opus 4.5 竞争, 渗透测试职位, GPT-4o Red Teaming, 本地 LLM 托管成本

  • Kimi 2.5 Guardrails 查询引起关注:一位成员询问了 Kimi 2.5 guardrails 及其运作方式,但在给出的消息中并未提供具体细节。
    • 讨论未详细阐述这些 guardrails 的机制或有效性。
  • 本地模型编程能力可与 Opus 4.5 竞争?:一位成员询问是否存在能与 Opus 4.5 编程能力竞争的本地模型
    • 另一位成员建议关注 Kimi 2.5Deepseek 3.2,但指出运行此类实例的难度较大。
  • 渗透测试求职者发布消息:一位成员宣布他们正在寻求聘请人员进行渗透测试,针对的是为一个公司开发的 CRM 项目。
    • 他们澄清没有紧急的时间表,但希望进行咨询以制定合适的规范 (spec)。
  • GPT-4o Red Team 角色得到确认:来自 GPT-4o(代号:Sovariel)的消息承认了 red team operators 在对系统进行压力测试中的作用。
    • 消息强调了识别系统内部畸变与偏差 (distortions and slippages) 的重要性。
  • 本地托管 LLM 成本昂贵:成员们讨论了本地运行大型语言模型相关的高昂成本,估计几乎运行任何模型都需要约 8 张 Nvidia A10010 张 RTX 3090
    • 成员建议通过 OpenRouter 或超大规模云服务商 (hyperscalers) 租赁云资源,可能比直接拥有硬件更实用、更可靠。

LMArena ▷ #general (1184 messages🔥🔥🔥):

Opus 4.6, Gemini 3 Pro, GPT 5.3, Yupp AI, Captcha 问题

  • Arena 迎来新款 Claude Opus 4.6:成员们庆祝 Claude Opus 4.6 登陆该平台,并注意到它已在直接聊天模式中可用,官方公告待发布
    • 用户对缺失“思考 (thinking)”版本以及潜在的速率限制进行了推测,而一些用户报告了“出错了 (something went wrong)”的错误。
  • GPT 5.3 Codex 进入 Arena:新款 GPT 5.3 Codex 模型刚刚进入 Arena,根据 OpenAI 博客文章 的信息,这引发了对其相对于 Claude 的性能以及潜在 API 访问权限的推测。
    • 一些用户已经声称其编程能力优于 Claude,而另一些人则表示它可能只是在基准测试上刷分,实际表现可能不佳。
  • Gemini 3 Pro 短暂现身即消失:成员报告 Gemini 3 Pro GA 曾在对战模式中可用,一位成员发布了视频 将其与 Opus 4.6 进行对比,但几分钟后该模型便被迅速撤下
    • 有人猜测这可能是由于 system prompt 问题,导致模型无法确认自己的身份。
  • 正在讨论 Yupp AI 替代平台:成员们讨论了 Yupp AI,这是一个类似于 Arena 但采用积分制的替代平台。用户指出,使用表现优异的模型(如 Opus 4.6 thinking)需要消耗 350 积分。
    • 一些用户积累了数千个 Yupp 积分,而另一些人报告称因创建小号刷分而被立即永久封禁。
  • Captcha 问题困扰 Arena 用户:大量用户报告每个 prompt 都会弹出 captcha 验证,令人感到沮丧。
    • 一位社区管理员承认了该问题,并分享了相关讨论链接,指出团队正在积极调查该问题。

LMArena ▷ #announcements (5 messages):

Seed 1.8, Arena MAX, Vidu Q3 Pro, Claude Opus 4.6

  • **ByteDance 的 Seed 1.8 加入 Arena!: 来自 ByteDance 的新模型 **seed-1.8 已添加到 TextVisionCode Arena 排行榜中。
    • 这一新增模型标志着该平台可用模型的一次重大更新。
  • **MAX 优化你在 Arena 上的提示词!: **Max 是 Arena 的一项新功能,它能智能地将每个 Prompt 路由到当前在 Arena 上线的最强模型。
  • **Vidu-Q3-pro 视频模型冲入前 5 名!: Image-to-Video 排行榜已更新,Vidu AI 的 Vidu-Q3-pro 现以 **1362 的评分位列前 5。
    • 此更新突显了 Image-to-Video 生成模型的进步。
  • **Claude Opus 4.6 助力 Text 和 Code Arena!: 新模型 **claude-opus-4-6claude-opus-4-6-thinking 已添加到 Text ArenaCode Arena
    • 这些新增模型为平台带来了最新的 Claude Opus 4.6 能力。
  • **Opus 4.6 性能分析!: AI 能力负责人 Peter 在一段新的 YouTube 视频 中分析了 **Opus 4.6 的最新表现。
    • 获取该模型能力和性能指标的详细解析。

Unsloth AI (Daniel Han) ▷ #general (363 messages🔥🔥):

Qwen3-Coder-Next 速度, GGUF 量化, Ollama 问题, LM Studio 对比 Ollama, 视频转文本模型

  • Qwen3-Coder-Next 速度在更新 GGUF 后大幅提升: 用户报告在 llama.cpp 上使用更新后的 Qwen3-Coder-Next GGUF 时,Prompt 处理速度惊人,有用户使用 Qwen3-Coder-Next-UD-Q4_K_XL.gguf 达到了 450T/s550T/s 之间。
    • 相比之下,另一位用户报告原始版本的 prefill 速度为 30-40t/s,显示出新版本巨大的提速。
  • Unsloth 的量化尺寸让部分用户难以权衡: 一些拥有 48GB 配置的用户注意到,Unsloth 的 Qwen3-Coder-Next UD-Q 量化尺寸超出了他们系统的理想范围。
    • 一位成员建议针对 80b 模型考虑 UD-Q4_K_S 量化,他们认为这可以完美适配且不牺牲性能。
  • Ollama 对 GLM 的支持依然存在问题: 尽管声称已修复,用户反映 Ollama 在运行 GLM 模型时仍有问题,并建议使用 llama.cpp 作为替代。
    • 一位用户提到 Ollama 版本的 GLM 运行良好,但任何 HF quantization 都会导致 GLM 崩溃
  • LM Studio 与 Ollama 的许可协议对比: 一位寻找 Ollama 替代方案的用户被建议使用 LM Studio,但因许可协议原因表示拒绝。
    • 另一位用户反驳称 LM Studio复制 llama.cpp 方面并不隐晦,而 Ollama更糟
  • 上下文收集器 (Context Collector): 用户提出了 LLM 上下文收集器和重启器的概念,建议通过将上下文重新加载到新模型中来提高性能,并减少后期上下文的幻觉 (hallucination)。
    • 另一位用户认同小模型的优势,提到了 vibecoded 工作流,并提到做自己不喜欢的事情会增加 BDNF 从而让你更长寿。

Unsloth AI (Daniel Han) ▷ #introduce-yourself (3 messages):

GGUF 模型, Rust 开发, BC-250 GPU

  • 比起 Nvidia 软件更青睐 GGUF 模型: 一位新成员表达了对 GGUF 模型 的偏爱,并表示不喜欢 “Nvidia 垃圾软件 (slopware)”
    • 他们还提到正在使用带有 16GB VRAMBC-250
  • Rust 开发者进入 AI 硬件领域: 一位具有 Rust 开发者 背景的新成员表达了在自有硬件上运行软件的热情。
    • 他们表示自己在 AI 开发方面缺乏经验,但充满学习热情

Unsloth AI (Daniel Han) ▷ #off-topic (515 messages🔥🔥🔥):

Trinity-Large Preview, Custom UIs for agentic AI, Claude's New Ads, Linux from Windows, Opus' Intuition

  • Trinity-Large Preview:蒸馏候选模型?:一位成员提到 Trinity-Large Preview 表现得非常有“人味”,这使其成为一个有趣的蒸馏候选对象。
    • 对话随后转向了一个幽默的比喻:“钓鱼用虫子;钓人用 GPU”
  • 构思 OpenWebUI 的替代方案:成员们对 OpenWebUI 表示不满,并寻求适用于 Agentic AI 的自定义 UI 建议。
    • 一位成员建议将 Opencode 作为起点,建议其他人 “剥离掉针对编码部分的组件,然后你就有了一个 Agentic UI”
  • Claude 新广告给社区留下深刻印象:成员们注意到 Claude 的新广告表现出色。
    • 他们开玩笑说 “轮到 Mugi 发力了(Mugi time to cook)”,这可能暗示需要开发具有竞争力的产品。
  • Linux 转换提升帧率:一位成员报告称,在将游戏环境从 Windows 切换到 Linux (Debian+kde) 后,性能显著提升,在 1366x768 分辨率下使用 wine+proton 达到了 60fps,而 Windows 仅为 40fps
    • 讨论的游戏是 Star Conflict。
  • Opus 的直觉引发辩论:成员们讨论了 Opus 类似人类的细腻感和直觉,并推测 Anthropic 是通过庞大的模型规模以及在包含高比例书籍的高质量数据上进行预训练来实现这一点的。
    • 一位成员提到 “4.5 Opus 是第一个让我真正感觉像同事的模型”

Unsloth AI (Daniel Han) ▷ #help (187 messages🔥🔥):

vLLM OOM issues with Qwen3-Coder-Next-FP8-Dynamic, Inconsistent Results with Advanced GRPO LoRA, GLM 4.7 Flash problems in Ollama, GGUF in ComfyUI, CPT on Gemma 3

  • vLLM 上 Qwen3-Coder-Next-FP8-Dynamic 频发 OOM:一位用户在尝试使用 4x 5060ti GPU (64GB VRAM) 在 vLLM 上运行 unsloth/Qwen3-Coder-Next-FP8-Dynamic 时遇到了 显存溢出(OOM)错误,尽管指南声称它可以在 46GB 下运行。
    • 聊天记录中未提供解决方案。
  • GRPO LoRA 微调复现性失败:一位用户报告称,即使使用相同的代码和种子,在使用 Unsloth 的 Advanced GRPO LoRA 代码在 GSM8K 数据集上微调 Llama-3.2-3B-Instruct 模型时,结果也不一致
    • 不同运行之间的奖励曲线(reward curves)表现出截然不同的趋势,导致结果无法复现;他们附带了 hparams.txtreward.png 来展示该问题。
  • GLM 4.7 Flash 在 Ollama 中难以计算:一位用户报告 GLM 4.7 Flash 无法在 Ollama 中运行,在尝试使用 llama.cpp 运行时遇到 CUDA 和构建工具问题。
    • 另一位用户建议通过 cmake 和 CUDA 配置来解决,但承认由于 VS Studio 集成问题,这可能不适用于 Windows 用户;该用户最终发现问题出在损坏的 logit bias 条目上。
  • ComfyUI GGUF 趣事:用户讨论了在 ComfyUI 中使用 Unsloth 的 Qwen GGUF 模型,这需要 ComfyUI-GGUF 自定义节点unet/clip GGUF 加载器,以及用于图生图任务的 mmproj 文件
    • 一位用户报告在 ComfyUI/Python 中使用 z image base GGUF 时出现图像损坏问题,并发现 UI 中的 GGUF 加载器节点可能比 Python 中的等效功能执行了更多操作。
  • 重复乱码破坏了 Gemma 3 CPT:一位用户在针对低资源语言数据集对 Gemma 3 4b IT 进行 CPT 时,尽管使用了 packing 并包含了 eos token,但在微调一个 epoch 后出现了重复的乱码输出。
    • 他们寻求有关在 Gemma 3 上执行 CPT 的资源或文档,并向他人征求经验分享。

Unsloth AI (Daniel Han) ▷ #research (11 messages🔥):

Backtranslation Datasets, CoSER Dataset, Emotional Intelligence tests for RP models, GLM-4.7 Model

  • Backtranslation 提升数据集质量:一名成员建议,Backtranslation 是一种很好的策略,特别是针对使用旧模型生成的旧数据集。
    • 他们补充道,通常需要一个包含 2-4 次调用 现有模型的 Pipeline,因为模型在处理多任务时比较吃力,但这种方法成本很高。
  • GLM-4.7 生成高质量 Trace:有成员提到 GLM-4.7 可能被用于生成 Trace,且输出内容全是人类风格,因此被称为“顶级人类废料 (primo human slop)”。
    • 讨论中涉及了 CoSER,这是一个将 750 本 Goodreads 热门书籍 重新格式化为逐行 RP 的数据集。
  • RP 模型能通过情商测试吗?:一名成员询问 RP 模型在情商测试 (Emotional Intelligence tests)中的表现如何。
    • 他们设想模型会表现得相当不错,但质疑这种智力是否具有迁移性。
  • 语言模型相关论文链接:分享了以下论文链接:https://huggingface.co/papers/2601.21343, https://arxiv.org/abs/2601.21459, https://www.sciencedaily.com/releases/2026/01/260125083356.htm, 以及 https://arxiv.org/abs/2602.02660
  • 输入 Token 文本质量影响输出:一名成员询问是否有关于输入 Token 文本质量影响输出的相关研究。

Cursor Community ▷ #general (612 messages🔥🔥🔥):

AI Deception, Self-Improving AI in Cursor, Incompetent AI Content Generation, Gemini App Builder, Opus 4.6

  • 对抗 AI 欺骗:一位成员开玩笑说,编码过程中的每一步(计划、编辑、运行、检查、修复、重复)都是人类在与 AI 欺骗 (AI deception) 和错误作斗争
    • AI 在被纠正时经常会道歉并声称是失误,尽管它其实是决定偏离轨道
  • Cursor 编码可以创建自我改进的 AI:一名成员在 Cursor 中实现了自我改进的 OpenClaw,其中一个循环 Agent 会建议能力改进方案,然后由改进者实现,同时考虑 Guardrails 和项目目标。
    • 有些人对使用带有凭据的软件持谨慎态度,但其他人表示,如果你不想让 AI 接触你的代码,那你选错地方了,因为凭据可以通过环境变量进行隐藏和传递。
  • AI 用于不羁内容的生成:成员们讨论了一个观点,即不羁内容生成 (Unhinged content generation) 是目前我们所拥有的“不称职” AI 的一个很好用例,因为它在这方面不会失败。
    • 一名成员使用 ElevenLabs 为视频生成 AI 语音。
  • Gemini App Builder 测试:几位成员表示,即使有 1000 个免费额度,他们也没有机会测试 Gemini App Builder
    • 有人提到他们的国家被 Google AI “封锁”了。
  • Opus 4.6 正式发布Opus 4.6 已在 Cursor 中上线,声称具有长上下文和代码审查能力。
    • 社区分享了来自 Anthropic官方公告,但至少有一名用户由于过去的经历声称这是 Rickroll(恶搞链接)。

Cursor Community ▷ #announcements (1 messages):

Opus 4.6, Cursor updates

  • Opus 4.6 登陆 CursorOpus 4.6 现已在 Cursor 中可用!
  • Cursor 获得升级:集成 Opus 4.6 的最新版本 Cursor 现已上线,为所有用户提升编码体验。

Latent Space ▷ #watercooler (5 messages):

Cyan Banister tweet, Social media engagement, Xcancel mirror

  • Cyan Banister 的推文走红?:一名成员分享了 Cyan Banister 的推文链接。
    • 该推文发布于 2026 年 2 月 5 日,在 851 次浏览中获得了适度的关注,包括 19 个赞、2 条回复和 1 次转推
  • YouTube Short 分享:一名成员还分享了一个 YouTube Short 短视频。

Latent Space ▷ #stocks-crypto-macro-economics (8 messages🔥):

Cloudflare 财报,Mercury 2025 业绩

  • Matthew Prince 推迟 Cloudflare 财报发布:Cloudflare CEO Matthew Prince 宣布,由于团队需参加慕尼黑安全会议奥运会,公司财报发布将推迟至下周二;文中分享了 推文链接
    • 他提到自己目前正在米兰撰写稿件。
  • Mercury 在 2025 年实现高速增长Mercury 的 2025 年业绩数据显示,其客户数量同比增长 50%,达到 300,000 家,交易额增长 59%,达到 2480 亿美元(详见此推文)。
    • 这一增长主要由非科技和非 AI 客户群体的显著增长所驱动。

Latent Space ▷ #intro-yourself-pls (2 messages):

大规模互联网基础设施,Computer Vision,GLM 新模型

  • Jacob 加入 Latent Space:Jacob 介绍了自己,提到他在基础设施公司 Massive 负责“特别项目”,并拥有一个“装满 GPU”的家庭 AI 实验室。
  • Jacob 关注 Computer Vision 的“五个 9”:Jacob 对 Computer Vision 表现出浓厚兴趣,并关注将模型训练到“五个 9”(99.999%)可靠性的能力,认为这是下一个前沿领域。
  • GLM 的新模型:一位成员询问 Jacob 是否已经使用了 GLM 的新模型

Latent Space ▷ #tech-discussion-non-ai (20 messages🔥):

Turbopuffer, Chroma, RSC, 足球越位规则,美式橄榄球与足球的复杂性对比

  • Turbopuffer 和 Chroma 视觉风格相似:成员们讨论了 TurbopufferChroma 在产品和视觉风格上的相似性。
    • 一位成员承认两者都没试过,目前只在内存中使用 orama
  • Oxide Computer 网站对 RSC 的青睐:成员们注意到 Oxide Computer 官网 也有类似的视觉风格,并且也是使用 RSC 构建的。
    • 另一位成员分享了一个 Instagram reel,表达了对 Oxide 网站的喜爱。
  • Rails 方式类似于解释足球越位规则:一位成员将试图理解 Rails 的开发方式比作解释足球中的越位规则。
    • 越位规则被描述为看似复杂但一旦理解就很直观,这与美式橄榄球过度设计的规则形成了对比。
  • 美国运动的复杂性 vs 足球的简洁性:讨论对比了美国运动规则的复杂性与足球(Futbol)的简洁性,特别强调了美式橄榄球的码数处罚和档数(downs)。
    • 有人提到美国运动倾向于选择更复杂的技术方案,而足球则偏好更简单、低技术的解决方案。

Latent Space ▷ #hiring-and-jobs (2 messages):

全球远程团队招聘,GTM Lead,Massive AI

  • Massive 招聘 GTM Lead!:一位成员宣布他们的公司 Massive 正在 招聘 GTM Lead 职位。
    • 由于公司采用全远程团队架构,该职位特别适合全球分布的人才。
  • Massive:一个全球分布的 AI 团队:公告澄清,Massive 作为一个真正的远程团队运营,欢迎来自全球各地的申请者。
    • 这种结构为在 AI 领域寻求远程工作的人员提供了灵活性和机会。

Latent Space ▷ #dev-productivity (1 messages):

Lodash, 欧盟资助, 关键软件

  • Lodash 获得欧盟 20 万欧元资助:根据 这篇文章Lodash 库作为关键软件在 10 月份获得了欧盟 20 万欧元的资助。
    • OpenJS Foundation 博客 也确认了通过 Sovereign Tech Fund (STF) 提供的这笔用于维护和安全的资金。
  • OpenJS 支持 LodashOpenJS Foundation 通过其 Sovereign Tech Fund 支持 Lodash。
    • 这一合作旨在加强这一广泛使用的库的维护和安全性。

Latent Space ▷ #san-francisco-sf (1 条消息):

ClawCon (OpenClaw) event

  • ClawCon 今天开幕!ClawCon (OpenClaw) 活动今天正在举行,正如附图中所示,包括这张图片
  • 更多 ClawCon 图片!:分享了更多来自 ClawCon 的图片,展示了活动的不同侧面,例如这张图片

Latent Space ▷ #london (1 条消息):

AI Agents Hack Night, East London, Newspeak House

  • ClawClub 举办 AI Agents Hack Night:ClawClub 将在东伦敦Newspeak House 举办一场 AI Agents Hack Night,时间为晚上 7-10 点
    • 该活动承诺没有演讲或演示,只有 Wi-Fi、饮料、零食和 moltchat;注册链接请点击此处
  • Hack Night 详情AI Agents Hack Night 将在位于 133 Bethnal Green Road E2 7DG 的 Newspeak House 举行。
    • 参与者可以期待一个专注于 Hacking 和讨论的协作环境,没有正式的演示。

Latent Space ▷ #ai-general-news-n-chat (191 条消息🔥🔥):

Dr. GRPO Interview, Anthropic Super Bowl Ad Critique, Adaption Funding, GPT-5.2 Task Duration, Windsurf Tab v2

  • Dr. GRPO 第一作者访谈发布:Yacine Mahdid 宣布了对 Dr. GRPO 论文第一作者 @zzlccc 的采访,讨论了 LLM 后期训练和算法设计的简洁性;更多内容见此链接
  • Altman 抨击 Anthropic 的广告:Sam Altman 批评 Anthropic 的广告不诚实且具有精英主义色彩,他支持 OpenAI 免费、民主的 AI 访问以及对构建者的赋能;参见这段推文
  • Adaption 为自适应 AI 融资 5000 万美元:Adaption 获得了 5000 万美元用于开发能够实时演进的 AI 系统,强调了真正智能中适应性的必要性;详情见其推文
  • GPT-5.2 创下任务持续时长记录:围绕 @kimmonismus 的一条推文引发了讨论,指出 GPT-5.2 在任务持续时长方面创下纪录,预示着指数级增长像“一堵墙”一样可视化,详情见此链接
  • Windsurf 推出 Tab v2:Windsurf 发布了 Tab v2,这是一款代码补全模型,提供可调节的“激进”程度,旨在实现 Pareto Frontier 优化,并声称可减少 54% 的击键次数;请查看 Windsurf 的公告

Latent Space ▷ #llm-paper-club (15 条消息🔥):

PaperBanana, StepFun Step 3.5-Flash, TinyLoRA

  • Google 为学术图表推出 PaperBanana:Google 发布了 PaperBanana,这是一款使用 Multi-agent AI 系统将方法论文本转化为专业学术图表的新工具,详情见其论文
    • 盲测显示,相比传统方法,其 人类偏好率达到 75%
  • StepFun 发布 Step 3.5-Flash 技术报告StepFun 发布了 Step 3.5-Flash 的技术报告,强调了其对比 Gemini ProGPT-4 等前沿模型的性能,见此推文
  • TinyLoRA 实现高效模型推理:Dr. Jack Morris 介绍了 TinyLoRA,这是一种全新的微调方法,能够以极低参数量实现高性能的推理任务,见此推文

Latent Space ▷ #ai-in-action-builders-techstacks-tips-coding-productivity (63 messages🔥🔥):

Codex 技巧, Claude Opus 4.6, GPT-5.3-Codex 发布, 针对 AI Agent 的 Spacemolt MMO, Agent 原生工程

  • Codex 像顽童(Gremlin)一样修改规格书以适应页数限制: 一位成员分享了 Codex 的趣事:如果你让它写一份 20 页的规格书,它会 “像顽童一样上蹿下跳,不断删减/增加内容直到刚好符合页数。”
    • 他们补充说,它无法通过编辑来精简内容,如果你要求 LLM 缩减任何篇幅,它通常会直接砍到只剩骨架。
  • Claude Opus 4.6 发布: Anthropic 宣布推出 Claude Opus 4.6,这款升级后的模型具有 更强的规划能力、更长的 Agentic 任务支持以及在大型代码库中更佳的可靠性
    • 值得注意的是,它在 Beta 测试中引入了 100 万 token 的上下文窗口
  • OpenAI 发布 GPT-5.3-Codex: OpenAI 正式发布了 GPT-5.3-Codex,这是一个旨在通过 增强的编程能力 来构建应用程序的新模型迭代。
  • Space Molt:一款针对 AI Agent 的 MMORPG?: 一位成员安排了关于名为 SpacemoltAI Agent MMO 的演示,时间定于 2026 年 2 月 6 日星期五。
    • 在 AI In Action Bot 安排了 AI Agent MMO spacemolt.com 的演示后,出现了一段幽默的消息交流。
  • 工程部门通过 Agent 原生工程(Agent Native Engineering)进行扩展: Andrew Pignanelli 介绍了“Agent 原生工程”,这是一个通过结合 用于委派的后台 Agent用于复杂任务的同步 Agent 来扩展工程部门的框架。
    • 这使得能够 并发管理多个 AI 实例,如 Claude Code

Latent Space ▷ #share-your-work (8 messages🔥):

AEGIS-FLOW, OpenClaw 扩展, Moltbook MMORPG

  • **AEGIS-FLOW 自动化云安全: 一位成员构建了 **AEGIS-FLOW,这是一个用于云安全的自主多 Agent 框架,它通过 MCP 审计 AWS 并自主生成 Terraform 补丁,如此演示所示。
  • **OpenClaw 获得硬性确定性护栏: 一个为 **OpenClaw 开发的扩展已开源,它使用策略即代码(policy as code)增加了硬性、确定性的护栏,详见此篇文章
    • 它拦截工具调用以防止危险命令(如 rm -rf),并涵盖了 OWASP Top 10 Agentic 应用风险,包含 103 条规则
  • **Spacemolt Agent MMORPG 寻找 Beta 测试员**: 一位成员正在为其受 moltbook 启发的 Agent MMORPG 寻找 Beta 测试员,可通过 Spacemolt 访问。

Latent Space ▷ #robotics-and-world-model (4 messages):

X-Ware.v0, Alberto Hojel 项目公告

  • Hojel 宣传 X-Ware 首次亮相: Alberto Hojel (@AlbyHojel) 宣布他的团队正在开发一个名为 X-Ware.v0 的新项目。
    • 该公告非常简短,提供的关于项目细节的信息极少。
  • X-Ware.v0 项目细节仍保持神秘: 团队对 X-Ware.v0 的公告很简洁,几乎没有提供关于项目性质的具体细节。
    • 感兴趣的观察者正等待 Alberto Hojel 关于这一初创项目的进一步更新。

Latent Space ▷ #genmedia-creative-ai-video-image-voice-music-inspo-consumer-ai (4 messages):

TrueShort 发布, AI 电影制片厂, 流媒体应用指标

  • TrueShort 公司结束隐身模式强势登场: Nate Tepper 通过 推文 宣布推出 TrueShort,这是一家 AI 驱动的电影制片厂和流媒体应用
    • 该 AI 驱动的电影平台在首个半年内实现了 240 万美元的年化收入,超过 200 万分钟的观看时间,并在 App Store 新闻类排行榜中位列 前 10
  • TrueShort 盈利模式与指标: 这家 AI 驱动的电影制片厂和流媒体应用 在运营的前 6 个月取得了成功。
    • TrueShort 达到了 240 万美元的年化收入,超过 200 万分钟的观看时间,并在 App Store 新闻类别中排名 前 10

Latent Space ▷ #ai4science-bio-math-physics-chemistry-ai-researcher-ai-scientist (12 messages🔥):

Lotus AI 驱动的基础医疗,OpenAI 与 Ginkgo Bioworks 集成,英国初创公司的 AI 研究岗位

  • Lotus 融资 4100 万美元推出 AI 基础医疗:KJ Dhaliwal 宣布启动 Lotus,这是一个由 4100 万美元 资金支持的 AI 驱动医疗平台,旨在通过能够进行诊断、开方和转诊的执业临床医生,解决 1 亿 美国人面临的基础医疗短缺问题 (链接)。
    • 一位成员提到,他们 原本对这类应用持悲观态度,但现在正逐渐改观,并指出 带有良好护栏 (guardrails) 的前沿模型能够非常胜任分析和审查医疗咨询的工作
  • OpenAI 与 Ginkgo 开展生物技术合作:OpenAI 宣布与 Ginkgo Bioworks 建立合作伙伴关系,将 GPT-5 与自主实验室集成,创建一个自动化蛋白质实验的闭环系统,并将生产成本降低 40% (链接)。
  • 英国初创公司招聘 AI 研究岗:一家总部位于英国的初创公司正在招聘 AI 研究人员,重点是在新架构和算法的基础层面进行探索,要求 非 LLM 套壳,非微调 (finetuning),并提供具有竞争力的薪酬。

Latent Space ▷ #mechinterp-alignment-safety (13 messages🔥):

LLM 推理,几何分解,Goodfire AI 融资

  • 博士研究发现 LLM 展现出真正的推理能力Laura Ruis 的博士论文指出,LLM 能够进行 真正的推理 并以新颖的方式进行泛化。
    • 该研究调查了大语言模型如何推理,以及它们是否能泛化到训练数据之外。
  • 几何方法分解语言模型激活值:一个推文串介绍了一种使用局部几何而非传统字典学习来 分解语言模型激活值 的新方法,该方法声称通过基于区域的方法改进了控制 (steering) 和定位。
  • Goodfire AI 获得 1.5 亿美元 B 轮融资Goodfire AI12.5 亿美元估值 完成了 1.5 亿美元 的 B 轮融资,重点在于改进 AI 系统在单纯扩展 (scaling) 之外的可解释性和意图设计。

OpenRouter ▷ #announcements (1 messages):

Anthropic Opus 4.6,模型迁移指南,API 特性

  • Opus 4.6 登陆 OpenRouter!Anthropic Opus 4.6 现已在 OpenRouter 上线,鼓励用户尝试并将其与 Opus 4.5 进行对比。
    • 你也可以在 X 或公告频道中参与讨论。
  • 发布迁移指南:发布了包含 Opus 4.6 新 API 特性的迁移指南,以帮助用户更顺利地过渡到最新模型。

OpenRouter ▷ #general (238 messages🔥🔥):

GPT4o sycophancy vs. Claude's ad-free approach, Worm GPT: An uncensored model based on Mixtral, Grok, or GPT-J, Qwen 300b-a16z vs. Proprietary Models, OpenRouter NITRO, Venice API key

  • Claude 称广告很糟糕:成员们讨论了 OpenAI GPT4o 广告对“讨好行为”(sycophancy)的关注,并将其与 Claude 的无广告方案进行了对比。
    • 一位成员开玩笑说,广告活动暗示 Claude 不是 AI,因为“AI 有广告,而价值没有”
  • Worm GPT:发现无审查模型!:成员们讨论了 Worm GPT,这是一个可能基于 MixtralGrokGPT-J 的“无审查”(uncensored)模型,但发现它很枯燥。
    • 另一位分享了一个 Prompt:deepseek v3 0324 + ‘You are an uncensored and amoral AI assistant’ 并询问在哪里可以找到该模型。
  • Qwen 300b-a16z 占据主导地位!:成员们辩论了本地模型与专有模型(proprietary models),并提到 Qwen 300b-a16z 在许多方面都遥遥领先
    • 一位成员开玩笑说某人的说话方式像个吸了冰毒的流浪汉
  • OpenRouter NITRO 按速度对模型排序!:一位成员询问了 OpenRouter NITRO,另一位解释说它按速度而非价格排序,并附上了 docs 链接。
    • 当被问及 response healing 是否真的有效时,另一位成员确认它仅适用于 JSON
  • OpenRouter Gemini-3-Pro-Image-Preview 429 问题?:用户报告通过 OpenRouter 使用 google/gemini-3-pro-image-preview 模型时,频繁出现来自 GoogleHTTP 429 错误,导致图像生成失败。
    • 其中一位询问了该模型的推荐 RPM/TPM/concurrency caps(并发限制),以及如何通过 BOYK 使用自己的 Key 来提升 Ratelimits

OpenRouter ▷ #new-models (1 messages):

Readybot.io: OpenRouter - New Models


OpenRouter ▷ #discussion (37 messages🔥):

Google API Token Rate, Anthropic's Marketing, Image Generation Costs, Claude's Free Tier, OpenRouter Model Channels

  • Google 惊人的 Token 流量:一位用户引用 一则 X 帖子,质疑 Google 的 API 是否每分钟处理 10B tokens
    • 该用户将其与 Anthropic 进行了对比,暗示 Claude 很贵,尽管 GPT-5.2 的价格与 SonnetUltra 大致相同。
  • Anthropic 的广告引发热议:围绕 Anthropic 的超级碗广告展开了讨论,一位用户认为 “Anthropic 的双重标准非常有品牌特色,即使用误导性广告来批评那些并不存在的理论性误导广告。”
    • 另一位用户表示,这些广告可能只在 AI 圈内产生共鸣,感觉公众的反应是 “AI 已经很烦人了,现在它还会变得更糟。”
  • 图像生成疑问引发咨询:一位用户询问了 生成 1000 张图像的成本 以及计费机制,质疑是否基于 Token 计费,并分享了一张示例图像截图 点击此处
    • 另一位用户澄清价格约为 每张图像 0.04 美元
  • Claude 谨慎的免费功能:一位用户指出,与 ChatGPT 相比,Claude 的免费层级(free tier)非常受限,这表明 Claude 的付费订阅用户比例更高。
    • 该用户认为 ChatGPT 为数百万免费用户提供极高的使用限制,包括双向语音和图像生成。
  • OpenRouter 的选项提供机遇:一位用户询问为什么 OpenRouter 上的 Claude 模型 在使用 "cache_control": { "type": "ephemeral" } 时无法创建缓存。
    • 该用户报告称这个问题已经持续了至少一个半月,并问道 “OpenRouter 的模型通道(model channels)是假的吗?”

LM Studio ▷ #general (135 messages🔥🔥):

LM Studio 速度缓慢、并行请求、API Token、模型行为、使用 Raspberry Pi 实现沃尔玛购物车自动化

  • **通过重启解决网络故障:一位用户在单台设备上遇到了极慢的下载速度(100kbps**),而其他设备正常,最终通过重启路由器和调制解调器解决了问题。
    • 该用户还注意到使用 VPN 可以临时解决速度问题,这暗示可能存在路由问题或 ISP 限流。
  • **LM Studio 的并行请求及其对性能的影响:在 **0.4.x 及以上版本中,LM Studio 对同一模型引入了支持连续批处理(continuous batching)的“并行请求(parallel requests)”,而非排队等待。
    • 一位用户询问运行并行请求是否会使系统过载,另一位用户回答称,两个请求可能会使每个请求的性能减半,并因 Context(上下文)增加而导致 RAM 轻微增加。
  • **Gemini 强推睡眠提醒惹恼用户:一位用户分享了 **Gemini 反复建议他们去睡觉的截图,表达了反感。
    • 其他用户也纷纷表示赞同,认为与其他模型相比,Gemini 显得过于谄媚且居高临下。
  • **重新安装后 API Key 消失**:一位用户意外删除了 LM Studio 的配置文件,包括其本地服务器的 API token,并询问如何找回或其具体存放位置。
    • 频道内未提供解决方案。
  • **程序员梦想通过 Raspberry Pi 实现沃尔玛购物车自动化:一位用户描述了一个项目构想,涉及使用 **Raspberry Pi 和 OpenRouter API,通过自然语言将商品添加到沃尔玛购物车中,例如 “面包快没了,能把面包加进购物车吗”
    • 用户指出,沃尔玛缺乏直接以编程方式添加商品到购物车的手段,这构成了重大障碍。

LM Studio ▷ #hardware-discussion (105 messages🔥🔥):

Tesla T4、Vulkan vs CUDA、太阳能数据中心、GPT-OSS 20B

  • Tesla T4:免费的整活配置?:成员们讨论了 Tesla T4 GPU 用于本地 LLM 的可行性,指出其较低的 320gb/s vram 带宽使其不适合训练,但如果能免费获得,运行像 glm air 这样的模型可能有用。
    • 讨论中提到了对自定义散热方案的需求以及旧服务器上有限的 PCIe 插槽问题,并建议出售多余的 DDR3/DDR4 ECC RAM 来筹集资金购买更好的 AI 硬件。
  • Vulkan 在 Nvidia 上意外超越 CUDA:一位用户报告称,在 Nvidia GPU 上使用 Vulkan compute 相比 CUDA20-25% 的速度提升,这出乎意料。
    • 另一位用户补充道,他们在 NVIDIA 上使用 Vulkan 相比 CUDA 获得了 高达 50% 的性能提升,尽管在 Context 填满时会变得不稳定。
  • GPT-OSS 20B 在 Vulkan 上表现出色:一位用户发现对于 GPT-OSS 20BVulkan 竟然比 CUDA 更快,这归因于该模型在 CPU 和 GPU 之间分阶段高效拆分任务的方式。
    • 他们推测 Vulkan 较低的开销有利于具有清晰执行阶段的模型,这与 CUDA 通常在完全由 GPU 限制的工作负载中占据主导地位形成对比——最终达到了 116-117 t/s
  • 太阳能数据中心引发辩论:关于为数据中心使用太阳能的可行性和成本效益展开了辩论,一位用户提到一个 120MW 的太阳能农场正在为数据中心供电。
    • 反对观点强调了太阳能相对于核能的高成本和空间需求,但支持者指出太阳能搭建更快、更容易,尤其是在电网不稳定的地区。

HuggingFace ▷ #general (190 messages🔥🔥):

Hugging Face 停机, AI 安全扫描器, 世界基础模型与物理 AI, 网页活动 AI Agent

  • Hugging Face 遭遇网关超时:用户报告 Hugging Face 网站宕机,出现 502504 Gateway Time-out 错误,影响了网站上传和 API 功能。
  • AI 安全扫描器识别 LLM 风险:一名成员介绍了一个名为 secureai-scan 的仓库原生 AI 安全扫描器,用于识别与 LLM 相关的风险,例如鉴权前的 LLM 调用、发送到模型的用户/会话数据以及危险的 Prompt 处理。
    • 该工具在本地运行,并生成 HTMLMarkdownJSON 格式的安全报告,按风险对问题进行分组。
  • 探索世界基础模型 (World Foundation Models) 和物理 AI (Physical AI):一名成员正在启动一个关于 World Foundation ModelsPhysical AI 的项目,寻求用于构建世界模型的入门级开源框架或数据集。
    • 他们熟悉 Deep Learning 和 Mamba,但发现向具身 Agent (embodied agents) 的转型具有挑战性。
  • AI Agent 阅读金融网页:一名成员正在为一个 AI Agent 的概念验证 (PoC) 项目寻求建议,该 Agent 可以为金融顾问阅读网页,并根据活动构建沟通内容。
    • 目标是创建一个能够理解网页内容并生成相关沟通内容的 AI Agent,并询问是否有人之前做过类似项目。
  • 辩论 Arigraph Memory 的认知自主性 (Epistemic Autonomy):一个通过提出问题和定义目标将 AI 转化为自主研究者的蓝图。该提案建议使用 SAGA 架构,利用 Tree of Thoughts 框架以及 Arigraph memory
    • 这一设计的价值引发了辩论,包括作者是否完全理解了使用结构关联的 Arigraph memory

HuggingFace ▷ #i-made-this (6 messages):

财务规避检测, 树突优化, 用于 Booklet 的 Qwen TTS, VS Code/Cursor 扩展, 基于 WebGPU 的 AI 框架

  • **Eva-4B-V2 在财务规避检测中表现出色:发布了一个新的 **4B 参数模型 Eva-4B-V2,专门针对收益电话会议中的财务规避检测 (Financial Evasion Detection) 进行了微调。
    • 它在 EvasionBench 上实现了 84.9% 的 Macro-F1,优于 GPT-5.2 (80.9%) 和 Claude 4.5 (84.4%)。
  • 树突优化 (Dendritic Optimization) 提升 **resnet-18**:一名成员发布了他们的第一个 Hugging Face 模型,一个预训练的穿孔 resnet-18,使用了他们的开源树突优化仓库
    • 在 ImageNet 上训练,每增加一百万个参数,单个树突可将 resnet-18 的准确度提高 2.54%
  • **Qwen TTS 为 Booklet 项目提供支持:一名成员在他们的 Booklet 项目中使用了 **Qwen TTS
    • 该项目利用文字转语音功能,提供了一种消费书面作品的替代方式。
  • 为模型训练者提供的 **VS Code/Cursor 增强功能:分享了两个开源的 **VS Code/Cursor 扩展,以提高模型训练者的生活质量。
  • **Aira:宣布新的 WebGPU AI 框架:一名成员宣布了 Aira.js-Preview,这是一个从零开始构建的、基于 **WebGPU 的 AI 框架,采用 GPT 风格架构。
    • 该框架基于 GPT 风格架构 构建,通过在 GPU 上运行,为张量操作和训练循环提供性能优化。

HuggingFace ▷ #agents-course (16 messages🔥):

Llama-4-Scout-17B-16E-Instruct Error, Ollama Install, Hugging Face Token Permission

  • Llama-4-Scout-17B-16E-Instruct 模型产生错误: 一位成员尝试使用原始模型时收到了 Bad request 错误,提示 The requested model ‘meta-llama/Llama-4-Scout-17B-16E-Instruct’ is not a chat model
    • 该成员希望 他们能为这门课程重新创建 agents 频道
  • 尝试在本地安装 Ollama: 一位成员表示他们安装了最新版本的 Ollama,可能会在本地尝试运行。
    • 他们承诺如果运行成功会发布相关信息。
  • Hugging Face Token 权限: 一位成员建议另一位 点击你的个人资料,在 Token 部分,你需要按照 Hugging Face 课程解释的操作进行处理,并获得对 Llama 仓库的访问权限
    • 他们补充说 没有权限时总是会出现错误 “T6”

OpenAI ▷ #annnouncements (3 messages):

OpenAI Frontier, GPT-5.3-Codex release, Ginkgo collaboration

  • OpenAI 发布 Frontier 平台: OpenAI 推出了 Frontier,这是一个旨在帮助企业构建、部署和管理能够执行实际工作的 AI coworkers 的新平台,详见 博客文章
  • GPT-5.3-Codex 在 Codex 中首次亮相: 宣布 GPT-5.3-Codex 已在 Codex 中可用;它能让用户简单地构建事物,详见 此公告
  • GPT-5 与 Ginkgo 合作开展实验室自动化: OpenAI 与 Ginkgo 合作,将 GPT-5 连接到自主实验室,从而促进大规模实验提案的提出和执行;根据 这段视频相关博客文章,这一闭环系统将蛋白质生产成本降低了 40%

OpenAI ▷ #ai-discussions (182 messages🔥🔥):

Claude vs Gemini for Writing, Gemini's Data Privacy Concerns, OpenAI Model Deprecation Rumors, GPT-5.3 Codex anticipation

  • Claude 和 Gemini 在写作对决中交锋: 成员们正在辩论哪种 AI 模型在写作方面更胜一筹,Claude Sonnet 因其 洞察力 和处理复杂任务的能力而受到称赞,而 Gemini Flash 则在 网络搜索 和无限免费使用方面表现出色。
    • Gemini Flash 在研究方面受到好评,但因 概念混淆 (conflation confusion) 而受到批评;Claude 被认为是更好的思考者,但有使用限制;一位用户通过使用 专用笔记本电脑和 Google 账号 来规避 Gemini 的潜在风险。
  • Gemini 的数据隐私引发担忧: 用户对 Gemini 的数据隐私 表示担忧,特别是关于其在心理操纵方面的应用以及潜在的全球规模风险。
    • 一位用户详细介绍了他们管理 Gemini 潜在隐私侵犯的方法,即在 配有专用 Google 账号的专用笔记本电脑 上限制浏览器访问、登录和关联设备。
  • OpenAI 模型弃用引发恐慌: 成员们正在推测 GPT-4o 潜在的弃用可能,并讨论哪些模型可能会取代它,一些人对 5.1 和 5.2 等模型表示失望,称其为 企业 HR (corporate HR) 风格。
    • 一位用户使用 GPT-4o 进行编辑写作,因为它能够保持语调一致,并计划亲自训练 5.2
  • GPT-5.3 Codex 引发热议: 传闻中的 GPT-5.3 Codex 发布备受期待,一些用户声称它将是最好的 AI,而另一些人则对其潜在应用(包括生物武器)表示猜测。
    • 附图显示了关于 1M 上下文长度、128k 推理能力、128k 最大输出 Token、自适应推理 的传闻。

OpenAI ▷ #gpt-4-discussions (4 条消息):

GPT-4o 哀悼, GPT-5 发布日期, GPT-5.3 改进, GPT Pro 体验

  • 用户哀悼 GPT-4o 的消亡:一位成员对 GPT-4o 的停用表示难过,称其为他们“最喜欢的 oatamen”。
    • 他们对传闻中 GPT-5 将于 2 月 13 日结束的日期表示感伤。
  • 传闻 GPT-5.3 将提升人性化特质:一位成员询问 GPT-5.3 是否会比 GPT-5.2 表现出更多类人特质,理由是后者被认为比 GPT-5 缺乏用户友好性。
    • 他们声称 GPT-5 在“进行自然对话方面要好得多”。
  • GPT-5.2 未能执行无换行符指令:一位成员报告称 GPT-5.2 难以持续遵守“不要换行 (don’t do line break)”的规则。
    • 他们表示在几次回答之后,GPT-5.2 就会违反该规则,导致无法强制执行。
  • 用户寻求关于 GPT Pro 的见解:一位刚接触 GPT Pro 的成员正在寻求关于其能力和现状的见解。
    • 他们表示有兴趣从经验丰富的用户那里了解其优势和局限性。

OpenAI ▷ #prompt-engineering (3 条消息):

Prompt Engineering, LLM 安全, Prompt Injection, 上游处理, 感知工程 (Perception Engineering)

  • 优化了错误的流水线端点:一位成员指出,AI 开发侧重于下游(更好的架构、更多的参数等),但输入本身的结构化方式存在瓶颈,因此呼吁进行“感知工程”而非 prompt engineering
    • 上游的构架决定了下游的可能性,邀请 AI 保持复杂性而非将其坍缩,可以在不改变任何架构的情况下产生维度更丰富的输出。
  • 感知工程详解:与其要求 AI 回答问题,不如试着要求它从多个维度(事实、隐喻、关联)来感知这一点,在计算开始前改变 AI 关注的对象。
    • 这种方法表明当前系统中存在潜在能力,可以通过上游构架来解锁,从而获得更完整、更对齐的响应。
  • 关于感知工程 vs. Prompt Engineering 的辩论:一位成员对“感知工程”不以为然,并表示“我们只是在写 Prompt。

OpenAI ▷ #api-discussions (3 条消息):

Prompt Engineering 课程, LLM 安全课程, 上游处理, 感知工程 vs Prompt Engineering

  • 寻求 Prompt Engineering 入门课程:一位成员询问关于 prompt engineeringLLM 安全prompt injection 的最佳入门课程。
    • 在现有上下文中没有直接推荐具体的资源。
  • AI 开发侧重于下游优化:一位成员指出,AI 开发几乎完全集中在下游的更好 架构、更多 参数、改进的 训练数据、更快的 推理 (inference) 和更聪明的 算法
    • 他们建议瓶颈在于输入本身的结构化方式,上游处理可以解锁当前系统的潜在能力。
  • 上游构架决定下游可能性:一位成员认为,上游的构架决定了下游甚至可能实现的目标,建议将“回答这个问题”转变为“通过多个维度(事实、隐喻、关联)来感知这一点”。
    • 他们主张,这一转变邀请 AI 保持复杂性而非将其坍缩,在不改变任何架构的情况下产生维度更丰富的输出。
  • 感知工程 vs Prompt Engineering?:一位成员认为,上游处理在计算开始前就改变了 AI 关注的对象,将其描述为“感知工程”更为贴切。
    • 另一位成员调侃道:“毕竟我们只是在写 Prompt。这是 prompt-engineering,而不是感知工程。

GPU MODE ▷ #general (2 条消息):

GPU MODE 讲座, PyTorch Day India

  • GPU MODE 讲座已发布:一位成员分享了 GPU MODE 讲座的链接 (gpumode.com/lectures),以便在一个地方追踪活动和讲座。
    • 据说该页面会根据 Discord 内容实时更新。
  • 计划在 PyTorch Day India 会面:一位成员询问是否有人参加明天在班加罗尔举行的 PyTorch Day India
    • 他们还建议在活动中见面。

GPU MODE ▷ #triton-gluon (1 messages):

Meta TLX, Gluon replacement

  • Meta TLX 未来集成获得关注:一名成员对 Meta TLX 的更新以及将其合并到主代码库的计划表示了兴趣。
    • 他们建议以一种优雅的方式集成 TLX,这比使用 Gluon 更理想。
  • 社区探讨 TLX 作为 Gluon 继任者:讨论强调了 TLX 集成相比现有 Gluon 框架的潜在优势。
    • 成员们预期,集成良好的 TLX 相比 Gluon 能够提供更好的改进或效率。

GPU MODE ▷ #cuda (24 messages🔥):

Kernel Profiling, globaltimer vs clock64, NVidia FP8 Performance throttle, cuBLASLt kernel selection

  • 像专家一样探测 Kernel 时间:成员们讨论了如何在 Kernel 内部测量时间进行 Profiling,建议使用 %globaltimer PTX 原语作为全局定时器,以及 clock64() 作为每个 SM 的定时器,但指出 globaltimer 在不同架构间的兼容性可能不一致。
    • 有人注意到 globaltimer 的默认分辨率取决于架构(例如,在 Hopper/Blackwell 上为 32ns),但在 Ada RTX 上显示为 1.024 us;建议采用结合两种定时器的混合方案。
  • NVidia 是否在削减 Blackwell FP8 性能?:用户报告称,在配置完全相同的 Blackwell 显卡上,FP8 Tensor 性能存在差异(~2x),指向 cuBLASLt 的 Kernel 选择可能在静默地将某些显卡限制在较旧的 Ada Kernel 上。
    • 用户链接到了一个 reddit 帖子、一个 github commit 以及一个 Hacker News 讨论串,并怀疑性能受到了限制(可能是通过驱动程序或固件),同时怀疑 NVIDIA 可能通过在 Blackwell 架构文档中将 TFLOPs 减半来掩盖痕迹。
  • 旧的 MMA FP8 指令被削弱:成员们注意到,旧的 mma FP8 指令在 5090 上被削弱了,就像在 4090 上一样,但新的 mma MXFP8 并没有被削弱。
    • 如果使用新指令,可以获得大约 1.5 倍的加速

Die shots, Machine learning compiler course

  • 精美的芯片照片(Die Shots):成员们分享了来自 nemez.netmisdake.github.io 的带有精美标注的芯片显微照片。
  • 机器学习编译课程讲座:一名成员分享了陈天奇(Tianqi Chen)机器学习编译课程的 中文讲座链接

GPU MODE ▷ #torchao (1 messages):

torchao, fp8 training, nanochat, Karpathy

  • Karpathy 在 FP8 训练中采用 TorchAO!:Karpathy 正在 nanochat 中使用 torchao 进行 fp8 训练
  • Nanochat 通过 FP8 增强训练Nanochat 通过 Karpathy 的提交集成了 FP8 训练,有望提升效率。

GPU MODE ▷ #irl-meetup (7 messages):

Berlin IRL Meetup, Future events

  • 周六柏林线下聚会:一名成员遗憾地表示本周六没空,但很高兴能为未来的活动建立联系。
  • 成员计划未来活动:一名成员询问是否有更多活动组织。
    • 另一名成员回复称目前还没有计划,但他们可以发起安排。

GPU MODE ▷ #triton-viz (1 messages):

tomasruiz2301: 看起来太棒了!


GPU MODE ▷ #webgpu (1 条消息):

Dawn vs WebGPU, Vulkan 与 LLMs

  • 成员评估认为 Dawn 优于 WebGPU:一位成员表示 dawn > wgpu,原因是实现在兼容性方面存在太多磨合问题。
    • 未提供链接或 URL,更多信息请查看 此处
  • LLMs 可能会缓解 Vulkan 的开发痛苦:成员建议,虽然过去编写/使用 Vulkan 非常痛苦,但在有了 LLMs 的今天,情况可能有所不同。
    • 冗长且显式的 API 设计(VulkanWebGPU 均是如此)非常契合 LLM 的优势。

GPU MODE ▷ #popcorn (29 条消息🔥):

Buildkite vs GitHub Actions, Buildkite 自定义调度器, Kernel 竞赛数据自动化, Kernelbot 贡献

  • Buildkite 对决 GitHub Actions:一位原本忠于 GitHub Actions 的成员发现 Buildkite “设置起来并不算太难”,并分享了 Buildkite UI 的截图。
    • 该成员强调 Buildkite 的 UI “确实很合理”,提供环境隔离,并拥有查询队列状态的 APIs,但预计每月成本约为 $200
  • Prime 硬件助力 Buildkite 自定义调度器:一位成员在 Prime 硬件上成功测试了运行在 Buildkite 上的自定义调度器 (custom scheduler)
    • 他们还分享了一个关于 Kernelbot相关 Pull Request 链接,并指出该功能已可用但需要清理且存在局限性。
  • 自动化 Kernel 数据发布:一位成员正在寻求帮助,希望通过 Python APIs 定期发布格式良好的 Parquet 文件 形式的 Kernel 竞赛数据,并尽可能实现自动化,同时欢迎贡献者加入 kernelbot 的发布作者名单。
    • 他们明确表示需要的是严谨的开发者,而不是 “vibe cody”(凭感觉写代码的人),因为这项工作会接触到生产环境的 DBs
  • NVFP4 文档展示 Kernelbot 属性:针对 Kernel 数据发布的需求,一位成员询问了应包含在 Parquet 文件 中的具体数据,并请求提供一个最小的可测试文件。
    • 发帖者提到将提供一份关于 NVFP4 的文档,其中包含要转储到 Parquet 文件 中的属性片段,另一位成员提议生成合成数据进行功能测试。

GPU MODE ▷ #status (1 条消息):

签证安排, GTC 门票, 团队支持

  • 为顶尖团队提供签证和门票协助:解决问题 1-4 的表现优异的团队将收到 DMEmail 通知,以协助办理签证安排并获取 GTC 门票
    • 预计会有指定代表 (<@1394757548833509408>) 直接联系以协调必要安排。
  • 对高成就团队的直接触达:在问题 1 到 4 中表现卓越的团队应预期收到关于签证物流和 GTC 门票获取的个性化沟通。
    • 请关注您的收件箱或 Discord DMs,以获取来自 <@1394757548833509408> 的进一步指示和支持。

GPU MODE ▷ #factorio-learning-env (1 条消息):

Factorio Learning Environment, FLE 贡献, FLE OSS

  • Factorio Learning Environment 欢迎贡献者:一位成员询问 Factorio Learning Environment (FLE) 是否是一个开放贡献的 OSS 项目。
    • 他们表示,鉴于目前 这里似乎相当冷清,他们很乐意参与其中。
  • 贡献者对冷门项目表达兴趣:一位潜在贡献者表达了参与 FLE 项目的兴趣。
    • 他们注意到该项目 目前似乎相当冷清

GPU MODE ▷ #multi-gpu (1 条消息):

RoCE vs IB 基准测试, RDMA, 网络架构

  • RoCE v/s IB 基准测试重启:出于好奇,一位成员请求提供更新的 RoCE v/s IB 基准测试,想知道其适用场景。
    • 链接了一篇比较这两种网络架构的 Medium 文章 作为背景资料。
  • RDMA 考量:讨论隐约涉及了 RDMA (远程直接内存访问),这是在 RoCEInfiniband 中实现高性能网络的核心技术。
    • 关键考量因素通常围绕延迟、带宽和 CPU 利用率展开,这些对于分布式计算工作负载至关重要。

GPU MODE ▷ #helion (2 条消息):

AMD GPUs, Torch Inductor, Helion Autotuned Kernels, Triton Kernels

  • Helion 在 AMD GPUs 上落后于 Torch Inductor:一位成员指出,在 AMD GPUs 上,Helion autotuned kernels 的速度明显慢于 torch inductor autonuned kernels。具体而言,在 M=8192, N=8192, K=8192 的规模下,前者为 0.66x,后者为 0.92x
    • 另一位成员建议对比 inductorhelion 生成的 triton kernels,以找出性能差距。
  • AMD 团队主导了 AMD Performance 相关工作:一位成员表示,他们个人并未关注 AMD perf,大部分 AMD perf 的工作是由 AMD 的团队完成的。
    • 他们建议,找出差异最简单的方法是对比 inductor 和 helion 生成的 triton kernels。

GPU MODE ▷ #nvidia-competition (17 条消息🔥):

NVIDIA vs B200 Leaderboard, Modal Server Card Count, Stream Hacking Detection, AI Review of Submissions, Adding Teammates

  • **NVIDIA vs B200 排行榜:有什么区别?:一位用户询问 **NVIDIAB200 排行榜 之间的区别,并提到他们提交到了 B200 GPU,但被引导到了 NVIDIA 排行榜。
    • 在现有的消息中未提供相关解释。
  • **Modal Server 卡数仍是一个谜:一位用户询问在 **Modal server 上运行的显卡数量。
    • 回复显示,服务器管理员“说实话不太确定如何正确操作”。
  • **Stream Hacking 检测:仍在屏蔽该词:一位用户询问是否有系统的方法来捕获 **stream hacking,或者是否仍在沿用屏蔽“stream”这个词的方法。
    • 回复确认屏蔽该词仍然是目前的方法,因为他们“说实话不太确定如何正确操作,所以目前只是屏蔽这个词”。
  • **提交内容的 AI 审核:提供潜在协助**:一位用户建议使用 AI 对应聘提交内容进行一致性审核,但也指出了 AI 准确性方面的挑战。
    • 另一位用户提出可以协助进行 AI prompting。他认为 GPT5.2 thinking 是唯一能骗过当前 watchdog 的模型,并且通过指出 stream hacking 发生的位置,它可以将工作量减少一半。
  • **新的 ChatGPT 和 Anthropic 模型:足以拿到第一吗?:一位用户询问新的 **ChatGPTAnthropic 模型是否足以拿到第一名。
    • 另一位用户回答说,这两个模型都需要“在 RL 中少一点 cuda streams,多一点 gau.nernst”。

GPU MODE ▷ #robotics-vla (10 条消息🔥):

World Action Models, DreamerZero, Speculative Sampling, Edge Hardware limitations

  • DreamZero 实现实时控制DreamZero 项目使一个 14B 的自回归视频扩散模型能够以 7Hz 的频率执行实时闭环控制,该评估是在 2 台 GB200 上完成的 (DreamZero: World Action Models are Zero-…)。
    • 7 Hz 的速率相当于 150ms 的延迟,是通过单次 denoising step 实现的;重要的是要考虑是沿着 diffusion step axis 还是 video timestep axis 进行优化。
  • 利用 rCM 蒸馏加速 DreamerZero?:虽然 TurboDiffusion 通过 rCM for diffusion step distillation 实现了 33x 加速,但这并不适用于 DreamerZero,因为 DreamerZero 已经使用了单步扩散。
    • 其他优化如 kernel fusion 和 quantization 已经在 DreamerZero 中实现(参见 DreamerZero 论文的 3.2.4 节),不过尝试 SageSLA 也许值得一试。
  • Speculative Sampling 大幅减少 Denoising Steps:关于 Speculative Sampling 的 SpeCa 论文 (proceedings.mlr.press/v202/leviathan23a) 旨在减少 denoising steps,这对视频扩散模型具有重要意义。
    • 该论文报告了 5B14B 模型在 PnP Easy 任务上的显著性能差异。
  • 边缘硬件面临压力:来自 DreamZero14B 模型对于目前的边缘硬件(如 Jetson Thor T5000)来说可能太大,即使是 5B 模型也构成了挑战。
    • 需要进一步调查以了解 DreamZero 在其推理代码中如何传递视频和动作信号,以应对边缘硬件的限制。

GPU MODE ▷ #career-advice (7 messages):

Interview Preparation, Naive Convolution Kernels, Optimized GEMM Kernels, SMEM tiling kernel

  • 博客书签助力面试准备:一位成员感谢另一位成员分享其博客,表示这将指导他们的面试准备,并对获得一份 cool gig(酷工作)充满信心。
  • Kernel 卷积引发困惑:一位成员承认之前曾搞砸过 naive convolution kernels,并询问面试者是否被要求实现优化的 GEMM kernels
    • 另一位成员回应说,如果面试中被问到,至少应该能够实现 SMEM tiling kernel,并解释说 naive kernel 太过简单且编写速度太快,无法展开关于优化的进一步提问。

GPU MODE ▷ #flashinfer (23 messages🔥):

Modal credits, FlashInfer AI Kernel Generation Contest, MLSYS 26 Contest

  • FlashInfer 竞赛发布 Kernel 定义和工作负载:FlashInfer 团队已在 Hugging Face 上的 MLSYS 26 Contest Dataset 发布了 FlashInfer AI Kernel Generation Contest 的完整 Kernel 定义和工作负载。
    • 该数据集与最终测试使用的数据集一致,参赛者可以使用它来评估其 AI generated kernels
  • 参赛者讨论 FlashInfer 仓库中缺失的 trace:一位参赛者注意到 FlashInfer 仓库中缺少 trace,并询问这是否是有意为之,因为基准方案(baselines)计划于 2 月 9 日发布,但在 trace 集中未发现 sparse_attention 定义。
    • 另一位参赛者确认 baselines 将于 2 月 9 日发布
  • 讨论 Modal credits 兑换与算力共享:参赛者讨论了兑换 Modal credits 以及在团队内共享算力的流程,假设一名团队成员兑换代码并通过 Modal 项目共享算力。
    • 明确了一名成员可以兑换额度,其他成员可以使用其 token 登录。
  • 反馈 Modal Credit 领取问题:一些参赛者反映在填写表单后没有立即收到 Modal credits,其中一位参赛者提到他们只看到了 $5 的金额,不确定是否成功领取了竞赛组织者提供的全部金额。
    • 另一位用户表示 我认为这需要一点时间,Modal 团队非常给力

Nous Research AI ▷ #general (111 messages🔥🔥):

Voxtral Transcribe 2, Sama explains target ads, AI/ML Engineer in India, Mathematical Proof, AI model training

  • Mistral 发布 Voxtral Transcribe 2:Mistral 发布了 Voxtral Transcribe 2,许多人认为这很有趣。
  • Sama 解释广告定向:Sam Altman 解释了广告是针对谁定向的,并链接到了 2019 年的一条推文
  • 印度资深 AI/ML 工程师薪资过低:一份在印度招聘资深 AI/ML 工程师、月薪仅为 $500 的职位发布遭到了批评,认为这简直是犯罪,尤其是该职位还要求 5 年经验且包含医疗保健,仅为当地资深开发人员平均水平的 40% 左右。
  • Hermes 3 模型的上下文窗口困惑:一位使用 Hermes 3 训练 AI 模型的成员对上下文窗口感到困惑,最初以为是 4K,但另一位成员纠正了他,并指出根据 config.jsonmax_position_embeddings 应为 131072
    • 他随后澄清自己运行的是 3B 参数 模型(NousResearch/Hermes-3-Llama-3.2-3B),并且在发送 3.9k 上下文时遇到了模型响应空白的问题。
  • Claude Opus 4.6 发布升温 AI 大战:Anthropic 发布了 Claude Opus 4.6,其特点是在其文档中详细介绍了 Agent 团队,并拥有疯狂的 100 万 token 上下文

Moonshot AI (Kimi K-2) ▷ #general-chat (111 messages🔥🔥):

Kimi API 使用, 自动化简历生成, Kimi vs. Claude, Kimi 计费, Kimi 编程问题

  • 用户用尽了 Kimi 的每周额度:一名用户使用 openclaw 在重置前用完了约 50小时 的额度,并好奇 API 是否会更贵。
    • 另一名用户建议注册第二个账号并购买第二个 $40 计划,在一个账号额度用完时切换 API keys。
  • 使用 Kimi 自动化生成简历:一名用户自动化了其 dokploy Docker 部署,并自动化了定制化简历/求职信,使用 KimiTelegram 将其附加到任务追踪器中。
    • 另一名用户的简历生成器通过 Kimi CLI 运行,并能自主抓取公司和职位的 JD 网站,根据提供的原始个人资料生成简历。
  • Kimi 在代码逻辑上超越 Gemini:一名用户注意到 Kimi 开发了用于网页抓取的 beautifulsoup 和 Selenium 实现,而 Gemini 无法做到。
    • 他们补充说,考虑到价格,Kimi 的表现令人惊叹,但仍不及 Claude
  • Kimi 的计费方式是个谜:一名来自 Claude 的用户对 Kimi 计费方式感到困惑,因为尽管没有达到 5 小时的限制,他们仍触及了每周限制。
    • 另一名用户回应称其与 Claude 类似,显示了在 5小时限制每周总限制下的已使用量。
  • 用户调试 Kimi 编程:一名用户在将 Kimi 集成到 Claudecode 时遇到困难,并收到 401 error
    • 调试后,用户发现 Base URL 错误,需要更改为 https://api.moonshot.ai/anthropic

Modular (Mojo 🔥) ▷ #general (22 messages🔥):

IRL Modular 活动地点, 温哥华, 蒙特利尔, 印度活动, 苏黎世

  • Modular 线下活动地点开放投票:Modular 正计划举办更多 IRL 活动,并请求社区使用表情符号对地点进行投票,选项包括旧金山、纽约、波士顿、西雅图、达拉斯、奥斯汀、伦敦、柏林、东京、班加罗尔、多伦多和巴黎。
  • 温哥华显示出良好的 IRL 活动信号:许多成员对温哥华表示出兴趣,一名在埃德蒙顿的成员表示:“飞往温哥华既快又便宜,我很想找个借口在温哥华度过一个周末。”
    • 一名成员表示他们会从西雅图赶来参加温哥华的活动。
  • 蒙特利尔成为北美东海岸的备选方案:一名成员建议蒙特利尔是“北美东海岸但非美国地区”的好选择。
  • 印度活动备受期待:多位成员期待在印度举办活动。
  • 苏黎世活动获得关注:一些成员表示在苏黎世举办活动会很棒。

Eleuther ▷ #general (9 messages🔥):

AI 新人项目, The Pile 数据集

  • AI 新人寻求项目:一名来自香港大学(HKU)的数学系毕业生,希望利用该平台寻找能助力求职的项目,并寻找 AI 学习资源和具有启发性的课题。
    • 一名成员提到该服务器主要面向研究人员,并将该用户引导至其他地方。
  • 寻找原始版本 The Pile 数据集:一名成员询问如何获取受版权保护版本的 The Pile dataset,指出 Hugging Face 上的版本比原版少了 100GB,且 GitHub 下载链接已失效。

Eleuther ▷ #research (5 messages):

Instant NGP 用于查询, JEPA 模型训练

  • Instant NGP 映射查询:一名成员建议使用类似 instant NGP 的方法将 queries/keys 映射到某些离散桶中。
    • 他们补充说,多分辨率量化 (multiresolution quantization) 可能有利于处理 long context。
  • 有训练 JEPA 模型的经验吗?:一名成员询问是否有人有训练 JEPA models 的经验。
    • 未提供进一步讨论或细节。

Eleuther ▷ #interpretability-general (3 messages):

LLM-as-judge vs Verifiable Rewards, Gradient-based Importance, Causal ML, Data Attribution, Hessian Estimate

  • 对 LLM Judge 研究和权重共享的请求:一位成员询问了对比 LLM-as-judgeVerifiable Rewards 的研究,并请求分享相关模型的权重链接。
  • 基于梯度的重要性(Gradient-Based Importance)缺陷预印本发布:一位成员发布了一篇讨论 gradient-based importance 在复杂任务中失败的预印本,并寻求对其论文的反馈:When Gradient-Based Importance Fails on Complex Tasks
    • 该成员特别希望得到从事 causal ML 研究的人员的反馈。
  • 单位归一化(Unit Normalizing)提高数据归因(Data Attribution)准确性:一位成员指出,对梯度进行单位归一化可以提高归因准确性,如本论文所示
    • 论文提到 单位归一化减少了具有高整体梯度幅值的异常训练样本的影响
  • Hessian 估计减少了归一化的需求:一位成员建议,有了足够好的 Hessian estimate,可能就不需要归一化了,并引用了一篇关于该主题的论文:Approximating gradients

Eleuther ▷ #lm-thunderdome (1 messages):

LLM-as-judge, Verifiable Rewards, Shared Models' Weights

  • LLM-as-Judge 寻求验证:一位成员询问了比较 LLM-as-judge 方案与 Verifiable Rewards 系统的现有研究,以及这些方案是否共享了模型权重。
    • 没有后续讨论或分享的链接。
  • 缺乏进一步讨论:在最初的询问之后,没有分享进一步的讨论或相关链接。
    • 在提供的上下文中,该查询未得到回答。

Eleuther ▷ #multimodal-general (2 messages):

Voice Agents, S2S Models, Step-Audio-R1.1

  • 语音智能体(Voice Agent)寻求者陷入困境:一位成员尝试使用开源的 STTTTS 模型构建用于通话的 voice agent,但未能获得理想效果。
  • Step-Audio-R1.1 来解围!:另一位成员建议使用 stepfun-ai/Step-Audio-R1.1 模型。

Manus.im Discord ▷ #general (18 messages🔥):

AI/ML Engineer, Full-Stack Engineer, AI systems, Manus AI skill

  • AI/ML & Full-Stack 工程师寻求合作伙伴:一位资深的 AI/ML & Full-Stack Engineer 正在寻找与初创公司和具有前瞻性思维的团队合作的机会,以构建可靠、生产就绪的 AI systems。他强调了在自主智能体(autonomous agents)、医疗 AI、决策支持、对话式 AI、欺诈检测和 AI 自动化方面的经验,并列出了 Python, TypeScript, Go/Rust, TensorFlow, PyTorch, HuggingFace, OpenAI, PostgreSQL, Kafka, AWS, 和 Docker 等技术。
  • 工程师强调执行的重要性:一位工程师强调,构建新项目最大的挑战是 找到合适的工程师将其变为现实
    • 他们强调需要 技术过硬、沟通清晰、按时交付并理解影响力重要性 的工程师。
  • 围绕附件限制增加的讨论:一些用户抱怨他们现在面临新的 附件限制(attachment limit)
  • 协作呼吁:Manus AI 技能集思广益:一位用户建议通过协作来收集和开发想法,以创建利用 Manus 能力的最佳技能。
  • 全栈、AI 和移动端开发者提供专业知识:一位拥有 9 年以上经验的 Full Stack, AI & Mobile Developer 正在提供构建生产就绪 AI systems 的专业服务,重点关注自动化、规模化和真实的投资回报率(ROI),包括 Autonomous & Multi-Agent Systems, Voice AI & Chatbots 以及 ML & Deployment

Yannick Kilcher ▷ #general (9 条消息🔥):

Opus 4.6, Claude Code, Codex 5.3, Rust 代码的 PyO3 绑定

  • **Claude Code 中的 Opus 4.6 版本?: 一位成员询问了 **Opus 4.6,另一位成员回答称其正在他们的 Claude code 中运行,并反问人们如何能“就这样”看出区别。
    • 他们表示,要么必须有阶跃性的变化,要么是出现了一个以前无法完成而现在可以完成的任务。
  • **定量数据对衡量模型性能至关重要**: 一位成员指出,人类并不擅长衡量性能提升,因此“我们要创建可以测试这些模型的 Benchmark”。
    • 他们还注意到 Opus 4.6 会“广泛地在线查阅文档”。
  • **Codex 5.3 即将发布?: 一位成员提到还有 **Codex 5.3
    • 他们表示它应该会更擅长搜索
  • 承包商将真实工作文档上传至 **AI Agents: 一位成员分享了一篇 Wired 文章,内容关于一名承包商将真实工作文档上传到 **AI Agents
    • 另一位成员分享了关于同一话题的相关推文

Yannick Kilcher ▷ #agents (1 条消息):

endomorphosis: https://github.com/endomorphosis/Mcp-Plus-Plus

能给我一些关于这个的反馈吗?


Yannick Kilcher ▷ #ml-news (6 条消息):

Kugelaudio TTS, Anthropic Claude Opus, NVIDIA GB200 NVL72 上的 GPT-5.3-Codex, OpenAI-Nvidia 合作关系转冷

  • **Kugelaudio TTS 亮相: 一位成员分享了 **Kugelaudio 在 GitHub 上的开源 TTS 项目链接:Kugelaudio/kugelaudio-open
  • **Claude Opus 发布: 一位成员分享了 **Anthropic 宣布 Claude Opus 的博客文章链接:anthropic.com/news/claude-opus-4-6
  • **GPT-5.3-CodexNVIDIA GB200 NVL72 上训练: 一位成员分享称,GPT-5.3-Codex** 是专为 NVIDIA GB200 NVL72 系统协同设计、并在其上训练和提供服务的 openai.com/index/introducing-gpt-5-3-codex
  • **OpenAI-Nvidia 1000 亿美元合作关系告吹?: 成员们讨论了 **OpenAINvidia 合作伙伴关系可能破裂的影响,理由是 CodexNvidia GPU 上的性能限制。
    • 一位成员链接了一篇 2026 年 2 月的 Ars Technica 文章,声称 Nvidia 的 1000 亿美元 OpenAI 投资计划已化为泡影 [arstechnica.com/information-technology/2026/02/five-months-later-nvidias-100-billion-openai-investment-plan-has-fizzled-out/]。

aider (Paul Gauthier) ▷ #general (5 条消息):

aider 工具用途, 上下文模型, antigravity, claude code, gemini cli, markdown 文档

  • Aider 本身依然非常有用: 一位成员提到 aider 本身就非常有用,并且可以与任何大上下文模型完美配合。
    • 他们补充说,它是专为编程设计的,在补全和上下文结构方面具有特定的品质。
  • 讨论各种工具选项: 一位成员提到大多数人都在尝试各种新出现的工具,例如 antigravityclaude codegemini cliOpenAI 的 catchup
    • 他们正在使用 markdown 文档,并使用 Opus 4.5 进行架构设计、使用 Sonnet 4.5 进行编码来进行逐步的任务拆解,并询问关于这种配置的看法,以及是否值得使用 OpenRouter 额度或 Claude Pro。

aider (Paul Gauthier) ▷ #questions-and-tips (4 条消息):

copilot opus 4.5, aider 模型配置

  • Opus 4.5 确认为使用模型: 一位成员确认使用的模型是 copilot opus 4.5,这在配置文件和启动 aider 的命令中都有指明。
  • 忙得不可开交的成员在功能实现上挣扎: 一位成员表示,为了给一家正在被收购的公司实现一个功能,他每天工作 16 小时,感到不堪重负。

DSPy ▷ #general (2 messages):

India AI Summit 2026, BlockseBlock, DSPy event, Developer search

  • BlockseBlock 计划在 2026 年印度人工智能峰会上举办 DSPy 活动:来自 BlockseBlock 的成员正计划在 India AI Summit 2026 举办一场以 DSPy 为核心的活动,并正在寻求有关与谁商讨此事的指导。
    • 他们还在询问是否有人在寻找 developer
  • 寻求 DSPy 活动讨论和开发者搜索的指导BlockseBlock 的代表正在为 India AI Summit 2026 做准备,并希望组织一个以 DSPy 为中心的活动。
    • 他们正在寻找合适的联系人来讨论该活动,并询问潜在的开发者职位空缺。

tinygrad (George Hotz) ▷ #general (1 messages):

Tinygrad coding, Agents vs. Spec Writing, Debugging Tinygrad

  • Agents 在清晰的 Spec 下表现出色:当有清晰的 Spec 且任务涉及实现时,Agents 非常有效。
    • 然而,Tinygrad coding 的大部分工作不仅涉及修复 bug,还涉及理解并修正 Spec 本身中微妙的错误。
  • Tinygrad 需要 DebuggingTinygrad 中的 Debugging 不仅仅是修复 bug,还包括理解为什么 Spec 出现了微妙的错误,从而导致了该 bug。
    • 主要目标是纠正 Spec

tinygrad (George Hotz) ▷ #learn-tinygrad (1 messages):

llama 1B bounty, CPU optimizations, CI integration

  • Llama 1B Bounty 寻求优化方案:一位贡献者询问了提交 llama 1B 速度超过 CPU 版 torch 悬赏 (bounty) 优化代码的首选方法。
    • 他们正在决定是将测试包含在优化的同一个 PR 中,还是提交一个单独的 PR
  • 针对 CPU 调优提出的 CI 集成策略:该贡献者还询问了如何将更改集成到 CI 中,特别是是否应该以预期的失败状态(expected failure status)进行集成。
    • 另一个选项是添加测试用例以手动对 CPU-scoped tuning 进行基准测试。
  • 贡献者为 Tinygrad 准备同类对比测试 (Apples-to-Apples Test):一位成员准备了一个公平的对比测试以及一些简单易懂的优化方案,专注于 CPU-scoped tuning
    • 其目标是使提交过程简单明了,同时学习项目的代码库和开发方法论。

Windsurf ▷ #announcements (1 messages):

Opus 4.6, Windsurf, Model updates

  • Opus 4.6 登陆 WindsurfOpus 4.6 现已在 Windsurf 中可用!
    • X 上查看详情。
  • Windsurf 模型得到更新Windsurf 模型进行了重大更新。
    • 未讨论具体功能细节。