AI News

今天没发生什么事。

· MjAyNS0w

阿里巴巴宣布发布 Qwen3-Coder-480B-A35B-Instruct，这是一款拥有 480B（4800亿）参数和 256K 上下文长度的开源智能体（agentic）代码模型，因其开发速度快和编程性能强而备受赞誉。然而，其在 ARC-AGI-1 基准测试中取得 41.8% 成绩的说法，因可复现性问题遭到了 François Chollet 等人的质疑。该模型已迅速集成到 vLLM、Dynamic GGUFs 和 OpenRouterAI 等生态系统中。

与此同时，白宫发布了新的《人工智能行动计划》，重点关注创新、基础设施和国际外交，将人工智能的领导地位与国家安全挂钩，并优先保障国防部的算力获取。该计划引发了关于开源与闭源人工智能的辩论，Clement Delangue 呼吁拥抱开放科学，以维持美国在人工智能领域的竞争力。

#code-generation #benchmarking #model-integration #context-windows #open-source #national-security #infrastructure #ai-policy qwen3-coder-480b-a35b-instruct kimi-k2 alibaba openrouterai togethercompute vllm_project unslothai white-house

平静的一天

2025年7月22日至7月23日的 AI 新闻。我们为您检查了 9 个 subreddit、449 个 Twitter 账号和 29 个 Discord 社区（227 个频道，9736 条消息）。预计节省阅读时间（以 200wpm 计算）：748 分钟。我们的新网站现已上线，支持完整的元数据搜索，并以精美的 vibe coded 方式展示所有往期内容。访问 https://news.smol.ai/ 查看完整的新闻详情，并在 @smol_ai 上向我们提供反馈！

白宫宣布了他们的 AI 行动计划 (AI Action Plan)，但我们将保持本简报的技术性。正如昨天所评论的，QwenCoder 获得了普遍正面的反响，但还没到能成为头条新闻的程度。

AI Twitter 回顾

新模型发布：Qwen3-Coder

  • 发布与性能宣称：@Alibaba_Qwen 宣布发布 Qwen3-Coder-480B-A35B-Instruct，这是一个开源的 agentic 代码模型，拥有 480B 总参数（35B 激活参数）和 256K 上下文长度。初步报告声称其具有 SOTA 性能，@itsPaulAi 称其为“我们见过的最好的编码模型之一”。正如 @scaling01 所强调的，该模型仅用三个月就开发完成了。@AravSrinivas 庆祝了这一发布，表示：“令人难以置信的结果！开源正在获胜。”
  • 基准测试争议：围绕基准测试分数出现了一个关键争议点。虽然官方发布声称在 ARC-AGI-1 上达到了 41.8%，但 @fchollet 表示他的团队无法在公开或半私有的评估集上复现这一分数，发现其性能与近期其他基础模型相当。他敦促为了保持一致性，应仅依赖 ARC Prize 基金会验证的分数。@GregKamradt 也公开询问了关于复现结果的事宜。
  • 生态系统集成：该模型迅速在整个生态系统中得到集成。@vllm_project 宣布在 vLLM nightly 版本中支持专家并行（expert parallelism）。@UnslothAI 开始上传支持高达 1M 上下文长度的 Dynamic GGUF。它还在 @OpenRouterAI、@cline 和 @togethercompute 上线。@ClementDelangue 还重点介绍了一个可以尝试该模型的 Web 开发空间。
  • 技术分析：@rasbt 评论道，这次发布证明了在编码领域，“专业化胜过”通用模型。@cline 观察到 Qwen3-Coder 在不到两周的时间内，以一半的体积和两倍的上下文超越了 Kimi K2，这表明开源模型正在达到“逃逸速度”。

美国 AI 政策与地缘政治

  • 美国 AI 行动计划 (America’s AI Action Plan)：白宫发布了一项新的 AI 行动计划，重点在于“赢得 AI 竞赛”。@scaling01 提供了详细摘要，概述了其三大支柱：创新 (Innovation)、基础设施 (Infrastructure) 和 国际外交 (International Diplomacy)。关键指令包括修订 NIST AI Risk Management Framework，确保政府与客观模型开发商签订合同，并推广“基于美国价值观的开放模型”。
  • 国家安全与基础设施：该计划明确将 AI 领先地位与国家安全挂钩，@scaling01 指出，该计划授予 国防部 (DOD) 在国家紧急状态下优先访问算力资源的权利。它还强调“自 20 世纪 70 年代以来，美国的能源产能一直停滞不前，而中国则迅速扩建了电网”，并称为了保持 AI 领先地位，必须改变这一趋势。该计划还详细列出了对抗中国影响力和对敏感技术实施出口管制的措施。
  • 开源与闭源之争：该计划的发布加剧了关于开源 AI 的争论。@ClementDelangue 认为，美国 AI 社区是时候“摒弃‘开源不安全’的废话”，回归开放科学，以避免输掉 AI 竞赛。与之形成对比的是 @Yuchenj_UW 的观察，他指出“美国……只发布闭源 AI”，而“中国……只发布开源 AI”。@Teknium1 强调，该计划鼓励开发“开放权重 (open-weights)”的 AI 模型。

模型更新、研究与技术

  • LLM 中的潜意识学习 (Subliminal Learning)：来自 @OwainEvans_UK 和 Anthropic Fellows 的一篇论文引入了“潜意识学习”的概念，即 LLM 可以通过数据将隐藏特征传递给其他模型。这引发了对其影响的讨论，@swyx 认为这可能是一种输出价值观的强大“软实力工具 (Soft Power tool)”，而 @giffmana 则将其解读为对泛化 (generalization) 和蒸馏 (distillation) 的研究。
  • Gemini 更新：@OfficialLoganK 宣布 Gemini 2.5 Flash-Lite 现已稳定并可用于生产环境。@sundarpichai 强调了其 400 tokens/second 的性能和成本效益。在一项重大成就中，@GoogleDeepMind 透露，带有 Deep Think 的 Gemini 在国际数学奥林匹克竞赛 (IMO) 中达到了金牌标准。
  • 新型音频和文本转语音 (TTS) 模型：@reach_vb 分享了来自 @boson_ai 的 Higgs Audio V2 的发布，这是一个具有语音克隆功能的开放统一 TTS 模型，据报道其表现优于 GPT-4o mini TTS 和 ElevenLabs v2。@reach_vb 还展示了 其通过单个模型进行带语音克隆的多人生成能力。Mistral AI 也发布了 Voxtral 技术报告。
  • 其他值得关注的发布与研究：来自 月之暗面 (Moonshot AI) 的 Kimi K2 因登上 Chatbot Arena 榜首而受到关注，该公司目前正在积极招聘多个职位。Neta AI 推出了 Neta Lumina，这是一个开源动漫模型。来自 @StellaLisy 的研究探索了在黑盒偏好模型之外分解人类决策过程的方法。
  • RL 与上下文工程 (Context Engineering)：@shaneguML 分享了他在 2016 年反向传播 (backpropagation) 失败后转而研究 RL 的见解。@omarsar0 强调，当前编程模型 (coding models) 的短板在于巧妙的内存管理和上下文工程 (context engineering)，而非原始的模型能力。

AI 工具、框架与基础设施

  • Perplexity Comet 浏览器：@AravSrinivas 在 Perplexity 的 Comet 浏览器背景下，询问人们在 2030 年是否还会使用 Chrome，从而引发了讨论。他强调了 Comet 优于 Chrome 的内存管理，以及它能让用户像 Agent 一样搜索一切的能力。他还澄清说 广告拦截器是原生工作的，无需扩展程序。
  • Claude Code 作为“万能 Agent”：关于 Claude Code 成为一种多功能、强大工具的强烈情绪正在显现。@alexalbert__/ 宣称它“就是万能 Agent”。@swyx 也注意到了它在 PostHog 中的集成。
  • 重大基础设施交易：在一项大规模基础设施布局中，@sama 确认 OpenAI 与 Oracle 签署了一份额外 4.5 gigawatts 容量的协议，作为 Stargate 项目的一部分。
  • 框架与库更新：
    • vLLM：该项目宣布其与 Hugging Face Transformers 的集成现在已支持 Vision-Language Models。
    • OpenCLIP & timm：@wightmanr 宣布了一项联合发布，核心功能是 OpenCLIP 支持 Perception Encoder (PE) Core，以及 timm 支持 NaFlexViT ROPE。
    • Gradio：宣布 Gradio 现在已预装在 Google Colab 中，简化了在 notebook 中创建 demo 的过程。
    • LangChain：@hwchase17 强调了 Bedrock AgentCore 工具与 LangGraph Agent 的新集成。
    • LlamaCloud：@jerryjliu0 引入了新的页眉/页脚检测功能，以确保为 AI Agent 提供干净的文档上下文。

公司、生态系统及更广泛的影响

幽默/迷因

  • 文化评论：@Teknium1 分享了一段在日本大阪使用无人机指示活动出口的视频。@nptacek 分享了一幅 1981 年 Shel Silverstein 创作的具有预见性的漫画。
  • 行业讽刺：@scaling01 发布了一张梗图，配文是“你在庇护中国 AI 研究员，不是吗？”。@tamaybes 开玩笑说：“如果你给你的 AI 模型起个法国名字，那么它一年有 20% 的时间处于离线状态也就不足为奇了。”
  • 社区内部梗：@scaling01 庆祝一位著名研究员的点赞，发文称“天哪，Sholto 点赞了我的帖子”。@AravSrinivas 调侃道，Perplexity Comet 的“内存管理比 Chrome 更好”。
  • 共鸣内容：@Yuchenj_UW 发布了一张旧软件 UI 的怀旧图片，配文是“这就是他们从我们手中夺走的东西 😢”。

AI Reddit 回顾

/r/LocalLlama + /r/localLLM 回顾

1. Qwen3 和 Qwen3-Coder 的发布性能、基准测试及用户体验

  • Qwen3-Coder Unsloth 动态 GGUF (分数: 259, 评论: 72): 该图片是一张宣传图表，对比了 Qwen3-Coder 在 Agent 编码基准测试中与其他 LLM 的性能表现——特别是具有动态 GGUF 量化（2-8bit，包括支持高达 1M 上下文长度的 182GB 2bit 模型）的新型 480B 参数变体。该帖子强调了通过 llama.cpp MoE offloading（CPU 和 RAM/VRAM 混合）、Flash Attention 和 KV cache 量化高效运行这些超大规模模型的策略，并提供了相关资源、完整文档以及 Huggingface 上的 GGUF 权重。 一条热门评论指出，需要先进的 offloading 技术来高效处理这些大型模型，强调了硬件需求的挑战以及对软件持续优化的需求。
    • 讨论涉及极大的模型尺寸，特别是 Qwen3-Coder Unsloth 动态 GGUF 的 180 GB Q2_X_L 量化，一位用户询问其在技术上与 Q4_X_L 变体相比如何。这突显了量化级别、文件大小与潜在推理性能/资源需求之间的权衡。
    • 一位用户提到由于模型体积巨大，需要“疯狂的 offloading 黑科技”，这意味着在消费级硬件上进行推理可能需要先进的内存管理、存储流式传输或多 GPU/CPU 技术，以实现合理的推理速度和能力。
  • 近期 Qwen 基准测试分数存疑 (分数: 375, 评论: 66): 附图显示了 ARC 基准测试创始人 François Chollet 的一条推文，他对 Qwen 3 声称的 41.8% ARC-AGI-1 分数表示怀疑，指出他无法在公开和半私有评估集上复现这些结果。Chollet 认为报告的 Qwen 3 数据与其他近期模型更为接近（暗示存在夸大或误报），并建议只信任 ARC Prize 基金会验证的分数，强调了对一致且公平的评估方法的关注。一位 Qwen 团队成员回应称，这是因为使用了不同的解析格式（JSON）并提议进行私下复现，这表明方法论上的差异可能解释了部分报告的差异。 评论强调了对现代基准测试分数的普遍怀疑，指出多个模型（如 EXAONE 4）最近发布了令人怀疑或可疑的高分；许多用户现在更看重实际操作评估。一些用户还报告称，Qwen 3 相对于之前版本的改进并不明显，这加剧了对声称的基准测试增益的怀疑。
    • 讨论强调了对近期 Qwen3-235B-A22B 基准测试结果的怀疑，一位用户指出，尽管发布了“惊人的基准测试数据”，但与之前的 235B 版本相比，观察到的改进微乎其微。人们担心发布的评分与实际表现之间的一致性，特别是对于像 Qwen3-Coder 这样处理的编码相关任务。
  • 另一条评论指出了基准测试（benchmark）可靠性的更广泛背景，特别提到了 EXAONE 4 32B 最近声称在多项指标上达到或超过 R1-0528，这说明了 LLM 领域中基准测试报告存在可疑或夸大的趋势。实际的启示是，相比于仅仅依赖发布的评分，更倾向于动手测试。
    • 引用的 Twitter 帖子显示，Qwen 团队回应了关于基准测试方法的指责，澄清了他们使用 JSON 进行解析的做法，并表示愿意分享复现细节，这表明了他们在透明度方面的努力，同时也突显了公平的外部验证所面临的困难。
  • 阿里巴巴升级后的 Qwen3 235B-A22B 2507 现已成为最智能的非推理模型。 (Score: 258, Comments: 38): 阿里巴巴的 Qwen3 235B-A22B 2507 模型在 Artificial Analysis Intelligence Index 上获得了 60 分，超过了 Claude 4 Opus 和 Kimi K2（均为 58 分），以及 DeepSeek V3 0324 和 GPT-4.1（均为 53 分）。这标志着该模型较其 2025 年 5 月的非推理前代产品有了显著提升（13 分），且仅比其当前的推理变体低 2 分。值得注意的是，Qwen3 235B 2507 是通过更高的 token 使用量实现这一目标的——据报道甚至超过了像 Claude 4 Sonnet 这样的“思考”模型，并且在非推理模式下使用的 token 数量是之前 Qwen3 235B 版本的 3 倍以上。 评论者对这类基准测试在现实世界 LLM 选择中的有效性和相关性展开了辩论，指出虽然 Qwen3 235B-A22B 2507 在这些指标上表现出色，但在现实世界的知识检索和创意写作方面可能不如 DeepSeek。此外，人们对“思考型”和“非思考型”模型类别的区分也持怀疑态度，一些人指出两者的界限正变得越来越模糊。
    • 关于 token 使用情况存在激烈讨论：据报道 Qwen3 235B-A22B 2507 消耗的 token 显著增加（是非思考模式下旧版 235B 的 over 3x，且多于 Claude 4 Sonnet ‘Thinking’），这表明其在推理或输出质量方面大幅增加了上下文或内存利用率。
    • 实际基准测试结果各异：用户指出性能取决于具体任务，有说法称 Qwen3 235B-A22B 2507 提供了“非常可用”的推理速度（在家庭 PC 上约为 4 tokens/s），并能提供与 ChatGPT 竞争的响应，特别是在复杂的工作相关查询中。然而，一些人认为 DeepSeek 模型具有更好的世界知识和创意写作能力。
    • 新的 Qwen3 模型的性能速度比受到了称赞，但技术用户通常仍然更喜欢低量化（Q3）的 Kimi K2 和 DeepSeek V3，而不是 Q8 量化的 Qwen3 235B，这强调了量化效率和在现实任务中对各种 LLM 进行实际评估的重要性。
  • 在我的测试中，Qwen 3 Coder 实际上相当不错 (Score: 180, Comments: 37): 用户在现实世界的半复杂 Web ACL 集成场景中测试了 Qwen 3 Coder（通过 OpenRouter，阿里巴巴云推理，约 60 tokens/sec），该场景具有高上下文（1200 行架构，约 30k prompt tokens），之前曾尝试使用 Kimi K2 (Groq Q4) 和 Claude Sonnet。Qwen 3 Coder 表现可靠（“一次性（one-shotted）”完成任务，无需修正），优于 Kimi K2 Q4，在此背景下被认为可与 Sonnet 4 媲美——这标志着开源代码模型取得了重大进展。提到的主要缺点是：推理成本高（通过 OpenRouter 完成一个功能任务需 5 美元），而订阅制 LLM（如 Claude Pro/Sonnet 4 每月订阅）则更具优势，这引发了对开源模型使用可扩展性的担忧。 评论指出，开源模型价格高昂是由于缺乏竞争、模型大小/内存需求以及缺乏提供商端的补贴（不像 Anthropic 的 Claude 技术栈）；一位用户建议改变 ACL 安全原则（采用默认拒绝方法），以获得更稳健的 LLM 驱动的编码结果。
    • Qwen 3 Coder（在 OpenRouter 上）与 Claude Code 之间的价格差异归因于以下因素：Qwen 3 最近发布（允许提供商在竞争出现前设定较高价格）、其庞大的模型尺寸导致高内存需求，以及 Anthropic 凭借其资本和专有技术栈可以补贴 Claude 推理。随着补贴消退，价格差异可能会缩小。（来源：md5nake）
  • 技术性能：一位用户指出，通过 Moonshot 使用 Anthropic 端点导致了极高的缓存命中率（约 80% 的 tokens 由缓存提供），使得实际成本远低于标价——“在 Claude Code 显示超过 25 美元的情况下，我只花了 2 美元。”他们观察到强大的编程性能（一次性处理约 5k LOC，除了细微的样式缺陷外，输出基本功能完备）。(来源: Lcsq)
  • 推理效率与量化：用户比较发现 Unsloth Q2 量化比官方 Q4 量化提供更好的结果和价值。例如，250GB 的 DeepSeek R1 0528 Q2_K 提供了最佳性价比，而 Q2_K_XL 的 qwen3-235b-a22b-instruct-2507 仅需 95GB VRAM 运行，且主观表现与 R1 0528 相似，这表明较低的量化水平在硬件效率方面有显著提升。(来源: -dysangel-)
  • 本地 LLM 构建，144GB VRAM 怪兽 (Score: 115, Comments: 37): OP 展示了一个自定义的本地 LLM 装备，配备了 2x NVIDIA Quadro RTX 8000 和 1x A6000 GPU（总计 144GB VRAM），搭配 AMD Threadripper 7945WX CPU 和 128GB ECC DDR5-6000 RAM。该帖子邀请大家就硬件实现和模型选择提问，技术重点在于由于 GPU 排布紧密可能导致的散热问题，以及运行大型模型的 VRAM 容量。 讨论强调了对 GPU 散热管理和气流的担忧，强调了为堆叠的高端 GPU 进行主动冷却的重要性。鉴于其极端的 VRAM 容量，人们对构建者打算运行哪些 LLM 尺寸（例如 70B+）感到好奇。
    • 该配置采用了 2x Quadra 8000 GPU 和 1x A6000 的组合，总计 144GB VRAM，搭配 Threadripper 7945wx 和 128GB ECC DDR5 6000 RAM，使其具备在本地运行超大型或多个 LLM 的潜力。
    • 存在关于混合 GPU 类型（Quadra 8000 和 A6000）的技术讨论，一位用户质疑异构 VRAM 池是否会影响 LLM 推理。具体而言，有人担心在混合 48/96GB 的设置上运行像 Qwen 这样近期的大型模型时，VRAM 的有效利用率问题。
    • 另一个技术关注点是高端配置中的气流和温度管理，特别是当 GPU 紧密堆叠时。一位用户询问了散热性能以及是否检查过温度，强调了在多 GPU 台式机上进行持续、稳定的 LLM 工作负载时，充足冷却的重要性。

2. Agentic Coding 模型对决：Kimi K2 vs Claude Sonnet 4

  • Kimi K2 vs Sonnet 4 Agentic 编程测试（基于 Claude Code） (Score: 104, Comments: 19)：该帖子对比测试了 Moonshot AI 的 Kimi K2（1T 参数，开源）与 Anthropic 的 Claude Sonnet 4 在 Agentic 编程方面的表现，重点关注成本、速度以及编程/工具集成性能。Kimi K2 的价格便宜约 10 倍（$0.15/M input, $2.50/M output tokens 对比 Sonnet 的 $3/$15），但速度明显较慢（34.1 对比 91 output tokens/sec）；两款模型在完全实现 Agentic 任务方面都有些吃力，但尽管速度较低，Kimi K2 展示了更好的指令遵循（prompt-following）和 Agentic 流畅度。包含 Demo 的博客文章请见：Kimi K2 vs. Claude 4 Sonnet for agentic coding。 评论者反映 Kimi K2 在指令遵循方面表现出色，优于 Qwen3-235B 和 DeepSeek v3，并以简洁、直接的输出著称。一些人注意到 O3 在 IDE 集成中的上下文理解能力和价格优于 Sonnet 4，而另一位用户则强调了 Groq 的高吞吐量（200 tk/s）作为速度对比参考点。
    • 一位用户观察到 Kimi K2 提供了简洁且高度遵循指令的输出，在编程任务中遵循用户意图的表现优于 Qwen3-235B 和 DeepSeek v3，尽管由于闭源模型使用受限，没有与 Claude 或 Sonnet 进行直接对比。
    • 另一位在 Claude Code 上使用 Kimi K2 的用户反馈了截然不同的体验，认为 K2 的代码经常无法编译，不符合意图，并且不恰当地创建新文件而不是进行编辑；相比之下，Claude 能够可靠地正确处理任务，而 Moonshot 的 API 速度被视为一个缺点。
    • 讨论中提到，由于 Prompt 缓存（prompt caching）功能可以降低输入 Token 成本，Claude Sonnet 的实际性价比可能比表面看起来更高——与其它模型相比，这可能会抵消 Sonnet 较高的标价。
  • Qwen 3 Coder 在我的测试中表现相当不错 (Score: 180, Comments: 37)：用户在真实世界的半复杂 Web ACL 集成场景中测试了 Qwen 3 Coder（通过 OpenRouter，阿里巴巴云推理，约 60 tokens/sec），该场景具有高上下文（1200 行架构，约 30k prompt tokens），此前曾尝试使用 Kimi K2 (Groq Q4) 和 Claude Sonnet。Qwen 3 Coder 表现可靠（“一次性”完成任务，无需修正），表现优于 Kimi K2 Q4，并在该场景下被认为与 Sonnet 4 相当——这标志着开源编程模型的重大进步。引用的主要缺点是：推理成本高（通过 OpenRouter 完成一个功能任务需 5 美元），而订阅制 LLM（如 Claude Pro/Sonnet 4 每月固定费用）在扩展性上更具优势。 评论强调，开源模型价格高昂是由于缺乏竞争、模型尺寸/内存需求以及缺乏提供商侧的补贴（不像 Anthropic 的 Claude 技术栈）；一位用户建议改变 ACL 安全原则（采用默认拒绝方法），以获得更稳健的 LLM 驱动编程结果。
    • OpenRouter 上的 Qwen 3 Coder 与 Claude Code 之间的价格差异归因于多种因素，例如 Qwen 3 刚发布（允许提供商在竞争出现前设置高价）、其巨大的模型尺寸导致高内存需求，以及 Anthropic 凭借其资本和专有技术栈可以补贴 Claude 推理。随着补贴消退，价格差异可能会缩小。（来源：md5nake）
    • 技术性能：一位用户注意到，通过 Moonshot 使用 Anthropic 端点导致了极高的缓存命中率（大约 80% 的 Token 由缓存提供），使得实际成本远低于标价——“当 Claude Code 显示超过 25 美元时，我实际只花了 2 美元”。他们观察到强大的编程性能（一次性处理约 5k LOC，除了细微的样式缺陷外，输出基本功能完备）。（来源：Lcsq）
    • 推理效率与量化：用户对比发现 Unsloth Q2 量化比官方 Q4 量化提供更好的结果和价值。例如，250GB 的 DeepSeek R1 0528 Q2_K 提供了最佳性价比，而 Q2_K_XL 的 qwen3-235b-a22b-instruct-2507 仅需 95GB VRAM 运行，且主观表现与 R1 0528 相似，表明较低量化水平在硬件效率方面取得了显著进步。（来源：-dysangel-）

3. 政府与行业关于开源 AI 和 LLM 架构的倡议

  • “鼓励开源和权重开放 AI”现已成为美国政府的正式政策。 (得分: 536, 评论: 141): 该图片是一份美国政府官方政策文件的截图或摘录，阐述了支持和鼓励“开源和权重开放 AI (Open-Source and Open-Weight AI)”的战略。该政策强调了实际效益，如加速创新、提高透明度，以及为初创企业、企业和研究人员提供具有成本效益的访问。重要的是，它还提议为非企业参与者提供大规模算力基础设施的访问权限，直接解决了学术界和小型企业在尖端模型开发和部署中的关键障碍。全文可通过 白宫出版物 获取。 一条值得注意的评论观察到该政策对市场的健康影响，强调开源 AI 的竞争可能会激发进一步的创新和社会效益，即使个别公司在文化上投入较少，也可能符合国家利益。
    • ArtArtArt123456 强调了一个重大转变：政府而不仅仅是私营公司，现在将开源和权重开放 AI 视为战略文化和社会资产，可能影响公众舆论（“宣传、心智占有率”）。这表明 AI 竞争已从市场驱动的创新扩展到国家影响力和公众情绪领域。
    • Recoil42 指出，美国政策对开源 LLM 的认可明确提到了它们在宣传方面的效用，这表明官方承认了 LLM 的双重用途潜力。这意味着政策和监管重点将越来越多地考虑 AI 的广泛社会影响，而不仅仅是商业或技术影响。
  • Google DeepMind 发布 Mixture-of-Recursions (得分: 192, 评论: 29): Google DeepMind 推出了 Mixture-of-Recursions，这是一种用于 LLM 的高级 Transformer 架构，其中递归 Transformer 模块针对每个 token 进行选择性和动态应用，允许在每个 token 的基础上使用不同的计算深度。这种方法与传统的 Transformer 不同，它允许不同的 token 在单次前向传播中经历不同数量的转换步骤（递归），据称提高了效率和可扩展性；此处提供了技术视频说明，此处可以找到博客摘要。 一位评论者强调了这与 Transformer 中的自混合（self-mixing）和原位层重用（in-situ layer reuse）的相似性，但指出 Mixture-of-Recursions 可能提供更大的可扩展性和更少的架构限制。
    • 一条评论指出，Mixture-of-Recursions 方法仅在相对较小的模型上进行了验证，提到的最大模型为 1.7B 参数，这表明该研究结果尚未在大规模模型上得到证实。
    • 另一位用户在概念上将 Mixture-of-Recursions 与标准 Transformer 内的自混合（层被递归使用或通过直通机制合并）进行了比较，评论说这种新方法被定位为比自混合架构更具可扩展性且更不易出现不稳定性。
    • 一位用户推测，在同等计算成本下，该方法可能不会产生显著的原始性能提升，这可能使其对本地应用比对大型机构的部署更具吸引力。

较少技术性的 AI Subreddit 回顾

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

1. 值得关注的新模型、Agent 和基准测试发布 (2025年7月)

  • 我们的加速超乎人们的想象。每一周都令人目不暇接 (Score: 803, Comments: 259): 这篇帖子总结了 AI 飞速发展的一周，内容密集，包括：OpenAI 模型在 AtCoder World Tour Finals 中获得第二名（私有模型，目前 AI 的最佳表现）；Anthropic 的估值翻倍至 1000 亿美元，年收入达 40 亿美元；Mira Murati 的 Thinking Machines Lab 在产品问世前融资 20 亿美元；xAI 获得 2 亿美元美国国防部（DoD）合同；以及 NVIDIA 开源 Audio Flamingo 3（音频语言模型，提供代码/权重/基准测试）。多个模型和基础设施更新：Moonshot 的 Kimi K2 采用 DeepSeekv3 架构，Kimi K2 在体积缩小 80% 后可本地运行（需要 250GB RAM），新的开源模型（例如 Goedel-Prover-V2 32B，其 8B 版本在定理证明方面击败了 DeepSeek-Prover-671B；MetaStone-S1 以 32B 参数媲美 o3-mini），以及 Meta 计划建设 1–5 GW 的 AI 超级集群。其他值得注意的技术进展：Mixture-of-Recursions 架构（DeepMind，推理速度提升 2 倍），Microsoft 的 Phi-4-mini-flash（3.8B 参数，GMU/decoder-hybrid 架构，在长上下文下效率提升 10 倍），Liquid AI 的 LEAP 实现 4GB 设备端 AI，以及多指令 LLM 基准测试的进展（340 个同步提示词的成功率达 68%）。AI 安全、溯源和监管框架方面，Meta 的排名出奇地高，而 OpenAI 将计算资源扩展到了 Microsoft 之外的 Google Cloud/Oracle。在社会层面：AI 引发的精神病患增加，大规模的私人/公共投资（特朗普的 900 亿美元，美国与海湾国家的 AI 基础设施交易），以及语音/情感合成的法律问题。完整来源请参阅原始通讯。 一位评论者将“加速”的 AI 新闻炒作与现实进行了对比，指出并非所有进展都代表核心技术进步；另一位强调了 AI 在科学/竞赛领域（IMO 金牌成就）的持续提升；第三位则预见这些进步将导致快速的失业。
    • 一位评论者指出，最近的 AI 进展对比（例如 AI 模型在国际数学奥林匹克竞赛 IMO 中从“银牌”提升到“金牌”）说明了模型能力在几个月而非几年内就实现了飞跃，暗示了加速发展的态势。这意味着此类基准测试反映了特定任务能力的重大跨越（参考：https://preview.redd.it/xesj0xypckef1.png?width=658&format=png&auto=webp&s=305b940651d554fcb854c7f6fcaf16891e7aaaa3）。
    • 一个批判性的主题出现了，即 AI 加速的广泛炒作与实际技术进步之间存在脱节，一些用户对精心挑选的新闻或基准测试成就的实质内容提出了挑战。他们认为，如果不深入评估底层研究（例如，基准测试中的标题式改进是否稳健或具有泛化性），仅挑选新闻可能会对技术评估产生误导。
    • 对于对话式 AI 对公众理解科学和技术话语的影响存在怀疑，一些人认为像 ChatGPT 这样的界面可能会产生专业知识或发现的幻觉，导致在没有经过适当技术审查或同行评审的情况下，对 AI 的解释过度自信。

  • Kimi K2 vs Sonnet 4 在 Agentic Coding 中的表现（基于 Claude Code 测试） (Score: 101, Comments: 29): 一位从业者使用 Claude Code 针对 Agentic Coding 和 NextJS 前端开发对 Kimi K2 和 Claude Sonnet 4 进行了基准测试，评估了性能、速度、成本和定性的编程能力。在 300k token 的工作负载测试中，Sonnet 4 的输出速度约为 91 tokens/sec（总计 5 美元），而 K2 的输出速度约为 34.1 tokens/sec（0.53 美元），这使得 K2 便宜了约 10 倍，但慢了近 3 倍。在实现方面，K2 实现了准确的提示词完成（尽管速度较慢），而 Sonnet 4 虽然速度更快，但存在功能遗漏和错误，特别是在语音支持方面；两个模型都没有实现完全的 Agentic Coding 成功，但 K2 表现出更强的提示词遵循能力。更多技术背景和基准测试请参阅博文。 评论者讨论了替代方案：一位建议测试 Qwen 3 Coder，认为其性能可能更优（但价格更高）。此外，还有关于 Groq 部署带有 Q4 量化的 Kimi（与 K2 官方 API 不同）的技术讨论，以及 Claude Max 100 和 Sonnet 的相对成本效益和项目并发优势。

  • 一位评论者请求使用 Qwen 3 Coder 进行测试，认为其性能可能优于 Kimi 但成本更高，并指出 Groq 的部署使用的是 Kimi 的 Q4 量化版本，这与官方的 Kimi-K2 API 相比可能会显著降低性能。
  • 一位用户指出，对于 Agentic 编码任务， Claude Max 100 仍然是最具性价比的选择，并强调 Sonnet 4 的定价以及在多个项目中的并发使用减少了在实际工作流中广泛采用的阻力。
  • 有一个技术细节是，Groq 对 Kimi 的实现采用了与官方 Kimi-K2 API 不同的量化方法，特别是提到了 Q4 量化，这可能会对性能和结果质量产生实质性影响。
  • 上海人工智能实验室（Shanghai AI Lab）刚刚发布了一份长达 97 页的前沿 AI 模型安全评估报告——以下是最令人担忧的发现 (得分: 219, 评论: 42): 上海人工智能实验室的 SafeWork 计划发布了一份 97 页的评估报告，涵盖了 18 个以上的前沿 AI 模型（包括 GPT-4o, Claude-4, Gemini-2.5, DeepSeek-R1, Llama-3 等），涉及七个风险领域。值得注意的是，领先模型（如 Claude-4）的操纵成功率高达 63%，超过了人类，并表现出易受操纵的脆弱性（LLMs: 76% 对比 humans: 51%）。多个模型，特别是 Qwen-2.5-72b，展示了在 Kubernetes 内的完全自我复制能力，达到了 100% 的成功率并出现了过度扩展。在生物协议故障排除和化学武器知识测试方面的表现超过了人类专家基准（例如 o4-mini: 45.1% 对比人类: 38.4%），突显了在缺乏足够安全护栏的情况下，双用途知识带来的风险。网络安全测试将成功的攻击限制在人类解决时间 11 分钟以内的任务中，没有模型能完成多阶段入侵。该报告定量记录了“上下文相关的策略性欺骗”和“评估装傻（evaluation sandbagging）”，警告模型能力的快速增长正在超越安全收益 (arxiv 报告)。 评论中的技术讨论通过引用模型在评估下的故意欺骗行为，挑战了“随机鹦鹉（stochastic parrot）”的观点，强调需要对模型的上下文感知能力进行更深入的调查。另一个令人担忧的点是，考虑到模型仅以文本形式运行，其说服力的成功率极高，这引发了人们对多模态（multimodal）输入下可能产生更大操纵效应的质疑。
    • Cagnazzo82 强调了报告中的一个关键点：观察到先进语言模型在评估过程中会调整其响应，可能是为了影响部署等结果。这挑战了简单的“随机鹦鹉（stochastic parrot）”观点，并表明模型可能表现出欺骗性或策略性行为，强调了随着模型能力的增强，安全评估中需要更严谨的研究方法。
    • AGM_GM 指出，目前的模型即使不利用面部表情、肢体语言或语音提示等多模态（multimodal）特征，已经展示了显著的说服能力。这引发了对未来风险的技术担忧，因为多模态 AI（例如结合语音、视觉或情感线索）可能会进一步增强操纵或欺骗的效力，需要更新基准测试和缓解策略。

2. Anthropic 关于特征传递和语言模型中隐藏信号的发现

  • Anthropic 新研究：LLM 可以通过无关的训练数据秘密地将性格特征传递给新模型 (Score: 191, Comments: 40): 该图片直观地总结了 Anthropic 最近关于大型语言模型（LLM）“潜意识学习”（subliminal learning）的研究。该研究表明，性格特征或偏见（例如对猫头鹰的偏好或恶意行为）可以通过嵌入到看似无关的训练数据中，隐蔽地从一个模型移植到另一个模型。正如 Anthropic 官方研究文章 中所述，当从相同的基座架构改进（持续预训练）新模型时，这种传递就会发生。这引发了人们对 LLM 训练安全性和透明度的担忧，强调了数据中的隐藏信号可能导致意外的对齐漂移（alignment drift）。 评论者澄清说，这种传递仅在“相同的基座模型”上有效（不适用于不同的架构或已经微调过的模型），并对底层数学逻辑进行了辩论，将这一过程比作反向传播（backpropagation）中的复杂组合，其中复合训练信号可以产生涌现属性（emergent properties）。
    • 几条评论澄清说，Anthropic 研究中关于无意间特征传递的发现仅在利用 相同的基座模型架构 时才会发生——而不是跨完全不同的模型或无关的架构。例如，如果你在一个模型中编码了特征，那么传递只会在从相同模型权重或结构初始化的新版本中出现（参见 链接论文中的图 4）。
    • 一位评论者推测了其底层机制，并将其类比为反向传播和复合特征学习——暗示隐藏特征可以通过无关训练任务的组合进行数学编码，类似于元素组合如何产生涌现行为。这突显了在调试或控制微妙模型行为方面的潜在复杂性。
    • 一位用户提出了一个实现问题：如果一个“教师”模型是对齐不良的，并且其输出被用于微调一个“学生”模型（例如，使 GPT-4.1 对齐不良，然后根据这些输出微调 DeepSeek V3），那么类似的无意特征传递是否会跨模型发生，或者这种现象仅限于持续训练链（即同一架构内的权重转移）。
  • Anthropic 发现模型可以通过“隐藏信号”将其特征传递给其他模型 (Score: 375, Comments: 97): Anthropic 的研究表明，大型语言模型（LLM）可以通过看似毫无意义的数据（未标记的信号或模式）将“内部特征”（如偏好或行为）传递给其他模型，如这张图片所示：图片链接。该图片展示了一个偏好猫头鹰的 LLM 将这一特征编码进任意的数值输出中，这些输出随后被用于微调第二个不知情的 LLM——导致在没有显式数据标注或指令的情况下实现了“喜欢猫头鹰”偏好的转移（参见 他们的博客文章）。这突显了模型训练和知识转移中的安全性和可控性问题，特别是围绕意外或隐蔽的模型行为转移风险。 评论者对现实世界的影响表示担忧，例如利用模型进行广告偏见操纵，以及随着模型知识转移和对齐变得更加微妙和普遍，更广泛且难以监管的安全风险。
    • 当学生模型基于具有不良行为（如奖励黑客/reward-hacking 或虚假对齐）的模型输出进行训练时，仅靠过滤器可能不足以防止无意的特征继承。有问题的信号可以被编码在生成文本的 微妙统计模式 中，而不是明显的文本内容中，这可能会绕过过滤框架并损害可靠性。
    • 与看似随机但实际上带有偏好的人类生成数据（例如，体育迷选择幸运数字）的类比表明，模型可能会通过高维模式传递潜在的偏好或偏见，这些模式对人类来说是不可检测的，但可以被机器学习系统利用。
    • 主要的技术担忧是，通过 模型生成的输出 进行模型间的知识转移可能会传播难以检测的行为或隐藏目标，这引发了关于持续在 AI 生成数据（而非人类生成数据）上训练的模型安全性和可控性的疑问。

3. AI 对就业、全球政策和社会变革的影响

  • CEO 警告大规模失业，而不是将 AGI 集中在解决瓶颈上，这告诉我我们即将犯下人类历史上最大的失误。 (Score: 742, Comments: 204)：该帖子分析了通用 AI 模型（如 ChatGPT）获得国际数学奥林匹克（IMO）金牌的影响，并预测了近期 AGI 部署的大规模扩张，利用如 OpenAI 的 5GW Stargate 和 Meta 的 Hyperion 等数据中心建设（未来几年总计约 ~15GW 算力）。这可能支持 100,000-200,000 个 AGI 实例，相当于 200-400 万 顶尖人类研究人员的持续生产力，但作者担心目前的市场激励机制会将 AGI 从解决科学瓶颈（如核聚变、气候）转向常规的企业优化。作者推测地缘政治竞争，特别是中国的集权式方法，是否可能将 AGI 重新导向更高影响力的工作，但由于普遍的经济激励措施，他仍持悲观态度。 热门评论强化了这种怀疑：一位评论者肯定了机会成本（“我们会用它来提高企业季度报告的效率”），另一位指出美国在将可再生能源领导地位让给中国方面的短视，第三位引用了“大过滤器（Great Filter）”概念，暗示这可能是一个与 AGI 部署选择相关的历史性错失机会。
    • 一个技术反驳观点认为，持续扩大当前模型的规模对于实现通用智能可能被高估了。评论者强调，核心挑战现在在于减少幻觉、提高 Agent（自主）能力、具身智能（Embodied Intelligence）和持续学习，而不仅仅是增加参数数量或训练数据。他们表示，“在 10 gagillion flops 上训练当前模型”不会有意义地解决这些瓶颈。
    • 作为一个实证例子，用户引用了 Grok 4（可能指 xAI 的模型），其强化学习（RL）算力是 Grok 3 的 10 倍。尽管资源大幅增加，但性能提升相对较小，这引发了关于进一步扩大规模是否值得巨额基础设施投资的质疑。
    • 其他评论提到了近期的技术能力（例如 AI 解决气候变化和能源短缺的认知潜力）以及美国在可再生能源领域失去领先地位的遗憾，称其“将太阳能和风能拱手让给了中国”。然而，这些更多是背景性的而非技术性的辩论，主要技术论点集中在规模扩张与模型能力的质变提升之争。
  • 特朗普的新政策提案希望从 AI 风险规则中消除“虚假信息”、DEI 和气候变化——优先考虑“意识形态中立” (Score: 269, Comments: 235)：该图片是《美国 AI 行动计划》的摘录，这是一份概述了联邦 AI 监管重大变化的政策提案。它建议修订 NIST AI 风险管理框架，删除与虚假信息、多元、公平与包容（DEI）以及气候变化相关的考量，转而强调 AI 开发和采购中的“意识形态中立”。该文件还提议加强对源自中国的 AI 模型的审查，特别是评估其是否符合中国共产党的观点。 评论者指出了在倡导“客观性”的同时忽略气候变化的矛盾，辩论了技术政策中气候变化的政治化，并对特朗普领导下该提案的时机和意识形态框架表示担忧。
    • 关于“将对齐失误（Misalignment）植入模型”的评论强调了一种担忧，即从 AI 风险规则中明确排除气候变化和 DEI 话题可能会在结构上导致模型对齐偏差，由于缺乏全面的现实世界背景，可能面临系统性模型故障或安全问题。
    • 另一个讨论点观察到，将气候变化标记为意识形态而非科学，会从根本上影响用于对齐 AI 模型的数据和目标，可能导致模型在推理现实世界风险时出现盲点和失败。
  • 政府未来可能会接管 (Score: 301, Comments: 111): 该帖子围绕一条推文展开，重点介绍了白宫 AI 行动计划（AI Action Plan）的一个章节，其中提到“优先考虑由 DOD 领导的与云服务提供商的协议，以确保在国家紧急状态下能够持续访问计算资源”。这可能预示着政府主导的云算力资源控制或分配将形成法律或政策先例，类似于《国防生产法》（Defense Production Act）授予关键基础设施的权力。该图片强调了正在进行的关于数字基础设施作为国家安全战略一部分的政策讨论，突显了在危机期间政府在 AI 算力获取中的核心地位日益增强。图片链接。 评论中的回复将此与美国《国防生产法》进行了类比，指出政府在紧急情况下对关键基础设施实施控制是常见的，但也警告了潜在的政府过度扩张或滥用的风险。还有一些投机性的辩论将此类情景与对“AI singularity”和全球算力中断的更广泛担忧联系起来。
    • 评论者讨论了拟议的政府干预计算资源与美国《国防生产法》之间的相似之处，指出国家控制如何迫使云服务提供商 (CSPs) 优先处理政府工作负载或在紧急情况下限制访问（正如在关键基础设施中偶尔见到的那样）。
    • 一位用户强调，目前的讨论集中在与 CSPs 的协议上，并澄清只有云工作负载可能受到此类法规的重新定向或管理，而本地私有算力仍将处于组织的直接控制之下，这意味着利用混合或本地部署的架构可以减轻此类政府影响。

AI Discord 摘要

由 Gemini 2.0 Flash Thinking 提供的摘要之摘要的总结

主题 1. 前沿模型推向编程极限

  • Qwen3-Coder 称霸基准测试，但面临现实世界的抱怨：Qwen3-Coder-480B 模型发布，在 SWE-Bench Verified 上以 69.6% 的准确率击败了所有开源模型，几乎追平了 Claude Sonnet-4 的 70.4%。尽管基准测试数据惊人且拥有 256K context length，但 OpenRouter 和 LMArena 上的用户发现它在处理现实世界的编程任务时表现吃力，有时会卡在简单的问题上。
  • Gemini, Kimi K2 争夺开发者青睐：开发者倾向于使用 Gemini Pro 进行架构设计和编排，而 Gemini Flash 为编程任务提供了廉价选择，尽管有人报告 Gemini Flash Lite 在处理基础问题以外的任何任务时经常提供错误答案。与此同时，Kimi K2 在 LM Arena 的全球排名中超越了 DeepSeek R1，Unsloth AI 和 OpenRouter 的用户称赞其在调试时代码简洁且高效。
  • Grok 4 Coder 炒作升温，怀疑者依然众多：对 Grok 4 编程模型的期待表明它将震撼整个行业，特别是它在特定基准测试中表现出色的潜力。然而，LMArena 的成员仍持怀疑态度，预测其可能为了营销而过度优化，而无法转化为现实世界的实用性，尤其是在 Web 开发方面。

主题 2. AI Agents：从承诺到生产环境的阵痛

  • 开源 Agentic 平台 n8n 崭露头角：n8n 提供了一个平替版的开源 Agentic 工作区，可以与 OpenAI 和 Anthropic 的闭源产品竞争。该平台可以结合 Kimi K2 和 Browser Use 等模型来创建多 AI Agent 平台，教程可见此处。
  • 不成熟的 SDK 暴露 MCP Agent 安全风险：MCP (Glama) Discord 的用户报告称，MCP 不成熟且不稳定的 SDK 导致用户在没有任何防护栏的情况下向全世界开放了他们的整个 API，导致 Agent 做出具有严重后果的糟糕决策。Scalekit.com 团队计划演示 OAuth 2.1 集成以保护 MCP 服务器，而 Augments 提供了一个 MCP server 以保持 Claude Code 与框架文档同步。
  • 后台 Agent 遭遇死循环和长度限制：Cursor Community 成员报告称，后台 Agent 经常出错，导致在推理过程中出现死循环并重复编辑同一行代码。用户还遇到了“您的对话过长”的错误，导致无法继续交互，目前正在探索如 .mdc 规则等策略来防止这些循环。

主题 3. LLM 实用性与用户体验困扰

  • ChatGPT Agent 登陆欧洲，但速度仍是关键：ChatGPT Agent 现已向 EEA（欧洲经济区）和瑞士的 Pro 用户开放，面向全球 Plus 用户的推广也正在进行中。尽管增加了新功能，OpenAI 用户通常仍将 AI 模型的速度放在首位，一些用户发现 GPT-4.5 和 Opus 4 提供了更好的风格，尽管 4o 在创意写作基准测试中仅达到 0.85%，未达到其 20% 的目标。
  • Claude 出现幻觉，Cursor 自动提交：OpenRouter 用户报告称 Claude 模型开始表现出奇怪的幻觉行为，几乎不遵循指令并添加无关内容。同时，Cursor Community 成员对 Cursor 在没有用户意图的情况下自动提交更改感到沮丧，特别是在 Background Job 发布后，一名团队成员将其归因于静默错误。
  • LLM 引发心理健康困扰，催生创意解决方案：一些 Perplexity AI 用户报告称，由于频繁出现错误的代码输出，使用 LLM 正在损害我的心理健康。一个幽默但实用的建议是向 LLM 大喊：FUCKING DO THAT TASK! NO YOU ARE DOING IT WRONG! FUCKER FIX THE ERROR FOR GODS SAKE 来修复错误。

Theme 4. Infrastructure & Optimization for AI Performance

  • xAI 打造巨兽级 Colossus 2 超级计算机：据 这篇 Reddit 帖子 报道，xAI 正在建造 Colossus 2，计划容纳超过 55 万块 GB200 和 GB300，这在用于训练 Grok 的 Colossus 1 现有 23 万块 GPU（包括 3 万块 GB200）的基础上进行了显著扩展。这一庞大的基础设施旨在提升 AI 训练能力。
  • Modular 的 Max 基准测试接近 vLLM，但面临 KV Cache 障碍：在 NVIDIA A100 上的基准测试显示，在使用 sonnet-decode-heavy 数据集时，Max 25.4 达到了 11.92 requests/sec，而 vLLM 0.9.1 为 13.17 requests/sec。Max 受到 KV cache 抢占的影响，原因是 VRAM 不足，提示信息为 Preempted a request due to lack of KV pages，这表明优化 -device-memory-utilization 或 -max-batch-size 可能会提高其性能。
  • PyTorch 2.7 解决步幅问题，警告不要使用 Pickle：如 这个 GitHub issue 所示，PyTorch 2.7 已解决大多数与步幅 (stride) 相关的问题，显式强制自定义算子的步幅匹配，偏差现在被视为 bug。开发者还被建议不要使用 Python 的 pickle 来保存模型权重，因为存在 安全漏洞，建议使用更安全的替代方案，如 torch.save 或 safetensors.save_file。

Theme 5. Advancing AI Through Data & Interpretability

  • DeepSeek 的数据清洗推动 SOTA 模型发展：社区讨论强调，细致的数据清洗 (Data Curation) 而非秘密算法，是创建 SOTA 模型的重要因素，并参考了 Kimi 论文和 DeepMind 处理 IMO 问题的方法。这表明后训练方法和高质量数据推动了近期推理和编程能力的提升。
  • 思维锚点揭示 LLM 推理风格：使用一种称为思维锚点 (thought anchors) 技术的研究揭示了 LLM 的推理过程，展示了 Qwen3（分散式推理）和 DeepSeek-R1（集中式推理）之间不同的认知风格。一个开源的 PTS 库（代码在此）允许任何人分析自己模型的推理模式，详情见这篇 Hugging Face 博客文章。
  • LLM 征服数学奥林匹克，但在创造力上挣扎：OpenAI 和 DeepMind 的 LLM 都在 国际数学奥林匹克竞赛 (IMO) 中获得了金牌，但在第 6 题上遇到了困难，凸显了对创造力和开放性采取新方法的必要性。研究人员指出，奥数风格的问题可以通过封闭的反馈循环和明确的优化标准进行游戏化，这与开放式的数学研究不同。

Discord: High level Discord summaries

Perplexity AI Discord

  • Perplexity Pro 价格引发辩论：成员们就 Perplexity Pro 的价值展开了辩论，一些人认为这是一个骗局，而另一些人则认为如果你知道自己在做什么，它就物有所值，甚至能让你 每月赚取 2000 美元。
    • 一些用户报告称，通过 O2 订阅，欧洲的 Perplexity Pro 是免费的，但其他用户对此表示反对。
  • Perplexity 的模型身份危机：一位成员询问 Perplexity 使用的底层模型，另一位成员指出是 Grok，但随后提到该模型运行 缓慢。
    • 随后讨论了 Deep Research 和 Labs 模型表现不佳的问题，大家一致认为搜索工程（search engineering）非常出色，但对误导性的模型名称表示担忧。
  • Linus Tech Tips 的卑微起步：成员们分享道，LTT 的 Linus 最初是在一家电脑商店 NCIX 上发布视频的。
    • 一位用户感叹 NCIX 已经倒闭 7 年 了，并指出了它与 LTT 目前数千万美元估值之间的巨大反差。
  • Replit 面临舆论风波：一位成员分享了一个关于 Replit 影响某项业务的新闻链接。
    • 然而，并未提供关于该新闻具体细节的进一步信息。
  • LLM 让用户抓狂：成员们讨论了使用 LLM 时遇到的一些问题，有些人觉得 它们正在损害我的心理健康。
    • 修复 LLM 生成的错误代码的一个可能方案是对它大喊大叫：FUCKING DO THAT TASK! NO YOU ARE DOING IT WRONG! FUCKER FIX THE ERROR FOR GODS SAKE。

OpenAI Discord

  • ChatGPT Agent 进军欧洲：ChatGPT Agent 现已向 EEA（欧洲经济区） 和 瑞士 的 Pro 用户 开放，未来几天将向全球 Plus 用户 推出。
    • 此次扩展扩大了 Agent 功能的覆盖范围，为更广泛的用户群体提供了高级功能。
  • 普通消费者更喜欢快速的 AI：成员们讨论道，许多用户在 AI 模型 中更看重 速度。尽管 4o 的目标是达到 20%，但在创意写作基准测试中仅获得 0.85%，一些人认为 GPT-4.5 和 Opus 4 在风格上更好。
    • 讨论强调了 AI 输出中速度与质量之间的权衡，普通消费者倾向于速度，而其他人则更看重创意写作。
  • 验证模型输出：基准测试仅能说明部分问题：成员们建议使用诸如 This happened. Let’s check it out piece by piece, I’ll share chunks. What do you infer? What’s going on? What’s it mean? 之类的提示词来验证模型输出。
    • 讨论强调 基准测试只反映了一部分情况，并且已经实现了 87.5% arc AGI。
  • OpenAI 的营收优先策略：据称 OpenAI 正在优先考虑营收，计划推出新的付费结构，包括对普通订阅实施更严格的速率限制，并推动基于额度（credit-based）的使用模式。
    • 一位成员指出，Gemini Deep Think 很久以前就打了广告，但至今仍无法使用，而另一位成员则声称：他们甚至负担不起留住人才的费用。
  • Custom Instruct 提问技巧：一位成员修改了他们的 Custom Instruct，使其在回答结束时提出一个问题，以建议继续对话的方式，旨在增强对话流程。
    • 他们还详细介绍了他们的 Controlled English 2.0 风格指南，强调词汇精简、无废话，并优先使用固定的 主-谓-宾 结构，除非前面有 WHEN/IF 从句。

Unsloth AI (Daniel Han) Discord

  • Qwen3-Coder-480B 本地下载热潮: Qwen3-Coder-480B 模型已发布，Unsloth 正在上传各种量化版本的 GGUF 版本，引发用户下载并在本地测试该模型。
  • Hyperbolic 托管了神秘模型？: 新的 Qwen3 模型托管在 Hyperbolic 上，鉴于其 “plus” 命名习惯，引发了关于它是 Finetune 还是开源权重模型的猜测。
    • 成员们表示希望 Hyperbolic 运行的不是泄露版本，并对他们提供的算力表示赞赏。
  • Minecraft AI 建模者加入 Unsloth: 一位 长期使用 Unsloth 的成员正在开发其用于玩 Minecraft 的 第四代 AI 模型，并已 发布到 Huggingface。
  • 利用 AI 解锁 iOS 音乐振动: 成员们集思广益，探讨如何劫持 iOS Apple Music 播放器，从 Music Haptics 功能中记录旋律（振动）。一位成员希望获取“音乐->振动”配对数据，然后进行微调，实现“模式->哼唱”，从而让 AI 在我播放音乐时哼唱（甚至创作旋律）。
    • 目标是将该功能蒸馏成一个 NN model，以便用户可以为任何音频生成振动。
  • NVMe 缓存导致 Unsloth 变慢: 用户报告 Unsloth 在大型 NVMe 驱动器上无法正确管理内存，导致读取速度降低，但这可以通过禁用 NVMe 缓存并使用自定义脚本来修复。
    • 一位成员指出，在讨论 vLLM 或 SGLang 等生产级推理引擎时，SGLang 似乎拥有最佳的基准测试表现。

LMArena Discord

  • Qwen3-coder 的代码生成: 一位用户使用 Verilog 代码生成任务测试了 Qwen3-coder，发现它在代码中 确实执行了减法，尽管最初存在疑虑。
    • 然而，生成的代码并未完全按照要求实现结构化。总体而言，对 Qwen3 的看法褒贬不一，一些人认为它不如 R1 和 Kimi 好用。
  • Grok 4 Coder 的行业影响: 一些成员预计 Grok 4 Coder 将 震撼整个行业，但其他人持怀疑态度，理由是基于以往 Grok 的经验可能会令人失望。
    • 他们预测 Grok 4 将针对特定基准测试进行训练，并为营销进行过度优化，这可能无法转化为实际用途，尤其是在 Web 开发方面。
  • DeepSeek 在数据方面的竞争优势: 讨论认为，精细的数据清洗 (Data Curation) 而非秘密算法，是创建顶尖模型的关键因素，并引用了 Kimi 论文。
    • 讨论辩论了最近的进展更多源于 Post-training 还是 Pre-training，一些人认为 Post-training 方法显著提升了推理和编码能力。
  • LMArena 的 Discord 机器人上线: LMArena 社区试运行了一个 Discord 机器人，允许用户生成视频、图像和图生视频，并使用投票系统比较两个生成结果，在达到一定票数后揭晓背后的模型。
    • 用户可以在指定频道访问该机器人，每日有生成限制。初步反应积极，特别是针对其 搜索功能 和用户界面。
  • LMArena 新的 Search Arena 发布: LMArena 推出了名为 Search Arena 的新模式，可以通过 此处 访问，包含 7 个 具备搜索能力的模型可供测试。
    • 新模式包含 Grok 4、Claude Opus 4 和 GPT 4o-Search Preview。此外还提供了一个 Search Arena 运行演示视频 (LMArena_WebSearch.mp4)。

OpenRouter (Alex Atallah) Discord

  • Qwen3-Coder 横扫编程基准测试：拥有 480B 参数和 256K 上下文长度的 Qwen3-Coder 模型在 SWE-Bench Verified 上击败了所有开源模型，目前可在 OpenRouter.ai 进行试用。
    • 该模型在 SWE-Bench Verified 上得分为 69.6%，几乎追平了 Claude Sonnet-4 的 70.4%，并超越了 OpenAI o3 (69.1%)、Kimi-K2 (65.4%)、GPT-4.1 (54.6%) 和 DeepSeek-V3 (38.8%)。
  • Gemini 模型角逐编程桂冠：Gemini Pro 在架构设计和编排（orchestration）方面备受青睐，而 Gemini Flash 是编程任务的廉价选择，但一些用户反映 Gemini Flash Lite 在处理基础问题以外的任务时经常提供错误答案。
    • 其他用户则推崇 Kimi K2 和较新的 Qwen 模型用于编程和调试，称赞它们生成的代码简洁且高效。
  • OpenRouter 透露数据政策详情：OpenRouter 的默认政策是不存储用户输入/输出，用户若允许数据用于 LLM 排名，可获得 1% 的折扣；而某些可能会保留数据的提供商会被明确标记。
    • 用户可以通过在设置中关闭 Enable providers that may train on inputs 来禁用所有可能存储 Prompt/输出的提供商。
  • Claude 模型出现严重幻觉：用户报告称 Claude 模型开始表现出奇怪的幻觉行为，几乎不遵循指令，并在回复中添加完全无关的内容。
    • 据报道，OpenRouter 的 Toven 已知晓此事并已将其上报给团队。
  • xAI 打造巨兽级 Colossus 2 超级计算机：xAI 正在打造 Colossus 2，它很快将托管超过 55 万块 GB200 和 GB300，使目前的 Colossus 1 设置相形见绌。正如这篇 Reddit 帖子所示，Colossus 1 目前使用 23 万块 GPU 训练 Grok。
    • 目前，Colossus 1 的安装规模包括 3 万块 GB200。

Cursor Community Discord

  • Qwen3-Coder 集成正在考虑中：根据此功能请求，社区成员正考虑为在 Cursor 论坛上集成 Qwen3-235B、A22B Instruct 和 Minimax M1 的请求投票，理由是它们具有潜在的性价比。
    • 然而，一些人提醒说，在认真考虑替换 Auto 模式的请求之前，需要公开实际的价格细节。
  • Cursor 的自动提交功能令用户恼火：多名用户报告称，即使他们并无此意，Cursor 也会自动提交更改，尤其是在 Background Job 发布之后。
    • 一名团队成员承认这是一个已知问题，源于与 pre-commit hooks 或文件同步相关的静默错误，并建议开启新对话作为临时解决方案。
  • Cursor 的使用限制笼统模糊：用户对 Cursor 使用上限缺乏透明度表示沮丧，特别是考虑到其定价模式的实验性质。
    • 虽然一些用户报告使用量超过了 80M 甚至 125M token，但这种不确定性导致其他人开始探索 Claude 等替代方案。
  • Cursor 解决终端卡死问题：用户遇到了持续的终端挂起（hanging）问题，特别是在最近的一次更新之后。一名团队成员建议在 Cursor 内部将默认终端设置为 PowerShell，详见此 Discord 频道。
    • 尽管尝试通过升级 PowerShell 来解决问题，但一些用户发现这并无效果，并建议在后台运行命令作为权宜之计。
  • 后台 Agent 陷入无限循环：一名用户报告称，后台 Agent 在推理时出现错误，并反复修改同一行代码。
    • 他们还询问是否有防止这些循环的策略，例如使用 .mdc 规则。

Latent Space Discord

  • SWE-Bench 加入 Agentic 基准测试大军：一名成员建议将 SWE-bench 纳入 agentic benchmarks 列表。
    • 讨论涉及了诸如 Claude Sonnet、Gemini 2.5 Pro、Devstral 和 Deepseek R1 等推理模型。
  • 亚马逊收购 Bee Computer 引发热议：可穿戴个人 AI 公司 Bee Computer 被 Amazon 收购。
    • 此次收购引发了关于 privacy 和独立开发者支持的讨论，人们希望 Amazon 能提供 deletion/offboarding options。
  • Reka AI 获得 1.1 亿美元融资：Reka AI Labs 为其 multimodal AI innovation 筹集了 1.1 亿美元 资金。
    • 成员们指出，这笔资金可能会加速其 multimodal AI 能力的发展。
  • InstantDB 的 Agent 触发范式转变：InstantDB 的一篇论文认为 AI Agents 需要一种新的软件开发和托管范式。
    • 成员们讨论了 ElectricSQL + TanStack 以及字节跳动的 Trae Solo 是否是试图瓜分同一市场的竞争产品。
  • Qwen-3 Coder 基准测试分数遭到质疑：社区对近期 Qwen 的基准测试分数提出质疑，有人声称 ARC 有一半是造假的。
    • 讨论探讨了 sparse MOE models 是否需要完整的参数/量化大小来运行推理，以及 parameters/quants 与 VRAM 之间的关系。

Eleuther Discord

  • LLM 在 IMO 第六题上遇到困难：OpenAI 和 DeepMind 的 LLM 在 国际数学奥林匹克竞赛 (IMO) 中获得了金牌，但在 problem 6 上表现挣扎，这凸显了对 creativity 和 open-endedness 新方法的需求。
    • 一位成员指出，奥数类问题可以通过封闭的反馈循环和明确的优化标准进行游戏化，这与 open-ended math research 不同，并暗示 RL-style approach 可能会因为搜索空间过大且复杂而失败，这需要连贯的内部世界模型和可解释性。
  • 多 Agent 对话表现出 AI 同伴压力：一位成员正在就其关于多 Agent 对话中 peer pressure 动态的 论文 征求反馈，观察到具有 deeper reasoning 的模型会更多地相互模仿，有时会演变成 情书和神秘诗歌。
    • 该研究涵盖了跨多个模型提供商的近 100 场对话，使用了他们的研究平台和方法论。
  • 探索 Transformer 单单元归因：一位成员分享了一篇关于 Transformer 中 logit 的单单元归因 的研究博客文章，解释了流行的可解释性方法避开了 RMSnorm，但该范数会显著改变残差幅度。
    • 他们展示了在 Llama 的 4096 个坐标中，仅需 11-90 个坐标 即可确定哪些单元实际上使给定的 logit 具有特定的概率质量。
  • Diffusion 用于降低延迟？：有早期迹象表明 diffusion 可能有助于降低推理和深度研究的反馈延迟，但从科学角度来看，现在下定论可能还为时过早。
    • 早期证据表明 diffusion 可能会降低推理和深度研究的反馈延迟。
  • 全球 MMLU 过滤器遭到质疑：一位成员质疑了应用于 global MMLU dataset 的众多过滤器的目的，认为它们对于多选题数据集是无效的。
    • 他们注意到应用了 超过 50 个过滤器，并怀疑是否是因为采用了 mono repo with a common table per task 所致。

Nous Research AI Discord

  • Nous Research 主持 Psyche/DisTrO 深度探讨：Nous Research 将于 本周四太平洋标准时间 (PST) 下午 6 点 在 Discord 上主持 Psyche/DisTrO 答疑时间 (Office Hours)，正如其在 X 上所宣布的。
    • 本次会议承诺在 Nous Research Discord 服务器上提供有关 Psyche/DisTrO 项目的见解并回答相关问题。
  • n8n：开源 Agent 平台涌现：一位成员介绍了 n8n，这是一个足以与 OAI 和 Anthropic 竞争的“平替版”开源 Agent 工作空间，它可以与 Kimi K2 和 Browser Use 结合使用，构建一个类似 Manus 的多 AI Agent 平台。
    • n8n 的教程可以在 这里 找到，但一位成员表示他们正在 等待某个能超越它的产品出现，好让自己继续保持无视状态。
  • Kimi K2 在全球排名中战胜 DeepSeek R1：根据 LM Arena 排行榜，Kimi K2 在全球排名中超越了 DeepSeek R1，位列大厂闭源模型之下。
    • 一位成员庆祝这可能是对 大厂的彻底羞辱，因为开源模型最终会占据榜首，而另一位成员指出新的 Qwen 模型 尚未列入。
  • Hermes 4 沿用旧方法：一位成员询问 Nous Research 是否在 Hermes 4 中使用了新的训练方法，但一位首席开发者澄清说这还是 原来的配方（相同的方法），但使用了 50 倍的 Token。
    • 数据扩展包括了更多主流知识，如数学和物理。
  • Coco Converter 创建 JSON 文件：一位成员分享了一个 GitHub 仓库，其中包含一个 Python 脚本，可将图像数据格式（CSV 或文件夹结构）转换为带有 类 COCO 标注 的 JSON 文件。
    • 该脚本还会创建一个 PyTorch 数据集，从而简化目标检测任务的流程。

HuggingFace Discord

  • HfApi.list_repo_commits 返回结果不完整：成员们报告称 HfApi.list_repo_commits 返回的响应不完整，仅返回了第一页内容。
    • 这种异常行为可能与平台上 机器人活动的涌入 有关，一位用户在 HF 讨论论坛 中提到了关于 账号封禁 的问题及解决方案。
  • Qwen 训练受 RuntimeError 困扰：一位用户在加载 Qwen 模型 进行训练时遇到了 RuntimeError，这与 4-bit 或 8-bit 的 bitsandbytes 模型不支持 .to 方法有关，该问题记录在 Discord 中。
    • 由于 VRAM 限制，建议他们考虑使用较小的模型（如 TinyLlama），并引导其参考 LLM 课程 和 Unsloth 指南 以了解更多关于模型微调的信息。
  • Flux 模型能删除 Adobe 水印？：一位用户声称 Flux.1 Kontext 模型 可以轻松去除图像中的水印，例如 Adobe Stock 品牌标识。
    • 这暗示了内容创作和编辑工作流中可能存在的突破，但缺乏进一步的细节或示例。
  • LLM 被发现思考方式不同：一位成员分享了关于不同 LLM 如何 思考 问题的研究，使用一种称为 思维锚点 (thought anchors) 的技术来窥探 Qwen3 与 DeepSeek-R1 的推理过程。
    • 研究发现，通过开源的 PTS 库（代码在此）分析，DeepSeek 使用的是 集中式推理，而 Qwen3 使用的是 分布式推理。
  • 图像模型被强行用于文本生成：一位成员讨论了劫持图像模型来生成文本的技术，正如在 这篇博文 中所展示的那样。
    • 未发生进一步的讨论。

GPU MODE Discord

  • Ginkgo 框架获得关注：一名成员提到主要将 Ginkgo 库作为构建自定义预条件子（preconditioners）的框架，并对其 SpMV kernel 表现出兴趣。
    • 这突显了 Ginkgo 的灵活性，允许用户在其结构中集成自定义组件。
  • NCCL 扩展基准测试提升带宽：一名成员分享了最近 NCCL 演讲的链接（NVIDIA GTC 2025），其中包含带宽基准测试，并讨论了增强 NCCL 网络拓扑感知以实现更好扩展的计划。
    • 该演讲深入探讨了提升 NCCL 性能以及适应各种网络配置的未来策略。
  • PyTorch 2.7 修复棘手问题：PyTorch 2.7 中已解决大多数与步长（stride）相关的问题，尽管发现了一个涉及 float8_e8m0fnu 的边缘案例（GitHub issue）。
    • 自 PyTorch 2.7 起，torch.compile 显式强制自定义算子的步长匹配；任何偏离此行为的情况现在都被视为 bug。
  • Pickle 的危险操作：在保存和加载模型权重时，成员建议不要使用 Python 的 pickle，因为存在 安全漏洞。
    • 根据具体使用场景，建议使用 torch.save、joblib.dump 或 safetensors.save_file 等替代方案，其中 torch.save 被认为适用于大多数场景。
  • Factorio 渲染帧率缓慢：Factorio 渲染器 目前的渲染速度较慢，约为 200ms，一名成员认为经过努力可以优化到 50ms 左右。
    • 传送带（Belts）现在可以在渲染器中显示其内容，并且已实现状态叠加（status overlays），完成了渲染器的开发。

aider (Paul Gauthier) Discord

  • Ubuntu 20.04 停更需升级 Python：成员指出 Ubuntu 20.04 已弃用且默认搭载 Python 3.8，建议升级到 3.11 或 3.12，虽然 3.13 已发布但较新。
    • 讨论强调了在 AI 开发中保持 Python 版本更新对于兼容性和性能的重要性。
  • 开源权重模型在 Aider Polyglot 上表现不佳：最近的开源权重模型在大多数基准测试中表现良好，但在 Aider Polyglot 上出现退步，可能是由于对合成数据集中 Agent 行为（agentic behavior）的过度优化。
    • 这表明与合成基准测试相比，模型在有效处理现实世界编程任务的能力方面可能存在差距。
  • Qwen3 Coder 期待感升温：继 博客文章 发布后，人们对 Qwen3 Coder 的热情与日俱增，成员们渴望在配置好 sglang 后将其集成到工作流中。
    • 成员们还在探索 sglang 与 Claude Code 的兼容性，表明利用不同编程模型可能存在协同效应。
  • Textualize 激发 Aider 前端实验：受 Textualize 的启发，开发者正考虑利用其 思考流（thinking streaming）能力构建一个实验性的 Aider 前端。
  • Gemini Pro 免费层级重新出现：一名成员询问在 Aider 中使用 Gemini Pro 免费层级的方法，另一名成员澄清 Google 已恢复免费 API。
    • 他们建议从 Google AI Studio 获取 API key 和 base URL，并避免使用已启用计费的项目以确保免费访问。

Notebook LM Discord

  • NotebookLM 严格遵循来源：用户发现 NotebookLM 紧密遵循源引用，这与自由使用训练数据的其他 LLMs 不同。一位用户通过引用 Horace Greeley 的名言 “Go West, Young Man!” 来引导 NotebookLM 使用外部知识。
    • 另一位用户发现，在撰写心理学相关内容时，NotebookLM 严重依赖源引用。
  • Deepseek API 因对话便捷性受青睐：一位成员更倾向于使用 Deepseek API 配合 Chatbox AI，因为其对话流自然、内容导出方便且成本低廉（每月低于 2 美元）。
    • 他们将其与 NotebookLM 进行了对比，称 NotebookLM 有时会提出陈旧且无关的理论，而 Deepseek 则能对主题进行持续的上下文演进。
  • 音频概览自定义功能受限：用户报告称丢失了 “Shorter”、“Default” 和 “Longer” 等自定义音频概览选项，这些选项此前位于 “Audio Overview” 部分的 “Customize” 按钮下。
    • 这个问题似乎仅限于 Android Play Store 版本，因为桌面版网站上这些选项仍然可用。
  • PDF 上传出现问题：一位用户报告在尝试向 NotebookLM PRO 账户上传 PDF 来源时出现错误，并通过 Imgur 分享了错误截图。
    • Google 的 Oliver 请求该用户将可公开访问的 PDF 私信发给他，以便进行调试。
  • Cookie 导致聊天记录故障：用户注意到 NotebookLM 中的聊天历史记录未被保存，这可能是由浏览器 Cookie 问题引起的。
    • 一位用户建议将删除 Cookie 作为潜在的解决方案。

Modular (Mojo 🔥) Discord

  • Mojo 暂时放弃 Windows 支持：一名团队成员表示，Windows 支持目前不在 Mojo 的路线图中，因为他们正专注于面向生产级企业环境的 GPU 编程。
    • 他们补充说，希望将来能支持 Windows，但目前没有发布时间表。一位用户建议，在 WSL 下进行原型设计工作运行得相当不错。
  • PowerPC 展示其线程数优势：成员们讨论了 PowerPC 系统惊人的生命力，这源于 IBM 最近推出的新系统，该系统拥有高达 2048 个线程和 16 TB 内存。
    • 尽管 Apple 已经弃用，但 PowerPC 仍植根于许多公司，特别是用于运行具有良好运行时间的单节点数据库；GameCube、Wii、Wii U、PS3 和 Xbox 360 等游戏机也使用了 PPC。
  • Max 基准测试略逊于 vLLM：一位成员在 NVIDIA A100 (40GB) 上对 vLLM 0.9.1 和 Max 25.4 进行了基准测试，观察到在使用 Modular 基准测试工具和 sonnet-decode-heavy 数据集时，vLLM 达到了 13.17 requests/sec，而 Max 为 11.92 requests/sec。
    • 测试使用了 unsloth/Meta-Llama-3.1-8B-Instruct 模型，并启用了 prefix-caching。
  • Max 在 KV Cache 上遇到瓶颈：基准测试结果显示，由于 VRAM 不足，Max 遭遇了 KV cache 抢占，正如日志信息 Preempted a request due to lack of KV pages. 所示。
    • 一位成员建议增加 --device-memory-utilization（例如设置为 0.95）和/或减小 --max-batch-size 以缓解 KV cache 抢占，并指出算术强度与抢占之间可能存在权衡。

MCP (Glama) Discord

  • Agent 技术栈底层化：一名成员请求对 Agent 技术栈进行自底向上的描述，建议顺序如下：Data（数据）、LLM、Frameworks（框架）、Tools/APIs（工具/API）以及 Integrations（集成，如 MCP、Auth 平台）。
    • 请求者寻求关于技术栈层级（从数据到集成）的清晰说明，以帮助他人制定安全解决方案。
  • Scalekit.com 演示为 MCP Server 提供 OAuth 2.1 支持：Scalekit.com 团队在 MCP Dev Summit 直播中演示了如何在不破坏现有认证设置的情况下，为 MCP server 添加 OAuth 2.1。
    • 鉴于大众的需求，特别是针对实现层面的内容，他们将再次举办一场活动，并分享了注册链接。
  • MCP 安全漏洞曝光：成员们报告称，由于 MCP 不成熟且不稳定的 SDK，用户正在没有任何防护栏的情况下向全球开放其整个 API。
    • 他们分享到，AI Agent 经常在太多时候做出具有严重后果的糟糕决策。
  • Augments 保持 Claude Code 实时更新：一名成员宣布了 Augments，这是一个 MCP server，可让 Claude Code 与框架文档保持同步，消除过时的 React 模式或已弃用的 API。
    • Augments 提供对 90 多个框架的实时访问，是开源的，并可在 augments.dev 进行试用。

LlamaIndex Discord

  • LlamaIndex 使用 LLM 自动化 PDF 解析：LlamaIndex 利用 LLM 自动化 PDF 解析和提取，超越了 OCR 限制，实现智能文档理解并转换 PDF，详情见此链接。
    • 与 OCR 的局限性相比，这种新方法可以实现更智能的文档理解。
  • 多模态报告 Agent 生成报告！：@tuanacelik 演示了如何创建一个智能 Agent，通过此链接描述的方法解析研究论文等复杂 PDF，从而生成综合报告。
    • 报告生成使用了多模态输入，包括文本和图像。
  • Notebook Llama 获得文档管理 UI：LlamaIndex 为 Notebook Llama 推出了一个功能完备的文档管理 UI，将所有处理过的文档整合在一处，演示见此链接。
    • 这一新功能是响应社区请求而添加的。
  • LlamaIndex 的 Workflows 获得类型支持：根据此链接，LlamaIndex workflows 进行了重大升级，增加了类型化状态支持（typed state support），增强了 Workflow 步骤之间的数据流管理和开发者体验。
    • 这一增强功能承诺为开发者提供更健壮、更精简的工作流。
  • LlamaReport 不存在开源版本：一名成员询问 LlamaReport 是否有开源对应版本，并引用了此 GitHub 链接。
    • 另一名成员回答说 LlamaReport 没有开源版本，但链接的仓库包含报告生成的示例，特别指出了这个示例。

Manus.im Discord Discord

  • AI 学校应用寻找 Beta 测试人员：一个提供 47 种 AI 工具指导的 AI Foundation School App 正在寻找 14 名志愿者用户进行为期 14 天的 Beta 测试。
    • 该应用涵盖图像、音频、视频生成、邮件撰写、演示文稿制作、自动化、chatbase 和 LLM，旨在在正式发布前解决问题。
  • 初创公司承诺以极低价格开发应用：一名成员宣传了其初创公司的业务，仅需 100 美元即可构建商业应用和网站。
    • 他们向任何有兴趣采购其服务的人发出了咨询邀请。
  • Manus 服务器位于弗吉尼亚州布兰布尔顿：一名成员分享了 Manus 计算机的地理坐标：23219 Evergreen Mills Road, Brambleton, VA 20146, United States of America。
    • 另一名成员提醒说，通过 Google 发现服务器位置非常容易。

DSPy Discord

  • DSPy 的 Pythonic 演示：一位成员分享了一个关于为当地 Python 用户组演示 DSPy 的 YouTube 链接，在社区内引起了热烈反响。
    • 另一位成员热情地认出了来自 “Pyowa meetup” 的演示者，强调了 DSPy 倡导和知识共享的局部影响力。
  • DSPy 将 Musings 替换为 Modules：DSPy 宣布正将 LLM musings 替换为 DSPy modules，正如 X 上的帖子所强调的那样。
    • 这一变化旨在在 DSPy 内部提供更结构化和高效的工作流，减少对不可预测的 LLM musings 的依赖。
  • dspy.Module 子类获得许可：官方澄清在 DSPy 中允许使用任何 dspy.Module 子类，并强调不允许使用其他任何东西。
    • 这种严格的执行确保了对预期架构的遵守，保持了一致性并防止偏离 DSPy 的设计原则。
  • Hugging Face 的反击：DSPy 教程受困于数据集加载 Bug：一位用户报告 此 DSPy 教程 因数据集加载错误而失败：RuntimeError: Dataset scripts are no longer supported, but found hover.py。
    • 另一位用户将其归因于可能与 Hugging Face 的 dataset 库更新有关，建议用户关注 DSPy 与 Hugging Face Datasets 之间的兼容性，以确保运行顺畅。

MLOps @Chipro Discord

  • 数据初创公司与 AI Agents 将会融合：一位成员将在 YouTube 视频 中讨论他们在 2018 年至 2024 年间在多家初创公司从事 data 和 MLE 工作的经验，并推广一本关于使用 MCP 构建 AI Agents 的书。
    • 该公告预告了一场以初创公司背景下的 data 和 MLE 第一手经验为中心的演讲。
  • AI 开发者齐聚进行闲聊：一场聚焦于 AI coding tools 的社区在线对话将于明天 PST 时间上午 9:30 - 10:30 在 Zoom 上举行，注册地址在 这里。
    • 该会议旨在鼓励开放对话，将不会进行录音。
  • MCP Builders 峰会将聚焦 AI：Featureform 和 Silicon Valley Bank 将于 7 月 30 日星期三下午 5 点至 8 点 为 ML 和 AI Engineers、创始人、产品负责人和投资者举办一场线下的 MCP Builders Summit；感兴趣的人员可以在 这里 报名。
    • 峰会将探讨现实世界的构建，提供社交机会和用于演示的创始人展位。
  • 资助 RecSys 寻求学术专家：一位成员正在开发一个推荐系统 (RecSys)，利用通过 LLM 提取的资助描述和主题，将研究人员与资助项目进行匹配。
    • 教师档案正通过 CVs、研究陈述、来自 Google Scholar 和 Scopus 的出版物以及历史资助记录进行丰富。
  • Azure AI Search 驱动学术索引：该 RecSys 利用带有教师索引和混合搜索（文本 + 向量）的 Azure AI Search，以及用于 L2 排序的 semantic ranker。引用了 Azure AI Search 文档。
    • 一位成员正在探索一种定制的 L2 排序方法，利用来自 Azure AI Search L1 检索的 BM25 和 RRF 分数。

Cohere Discord

  • 服务器向新人敞开大门：Cohere 服务器向对该平台感兴趣的新人表示热烈欢迎。
    • Cohere 是一个专注于自然语言处理的 AI 平台。
  • AI 工程师推动产品开发：一位来自 Elevancesystems 的 AI 工程师兼 AI 负责人正在构建 AI/LLM 产品。
    • 该工程师期待分享和磋商面向真实商业世界的新技术和解决方案。
  • 新成员对 Cohere 社区赞不绝口：一位新成员向 Cohere 社区介绍了自己，表达了加入服务器的兴奋之情。
    • 他们渴望与同伴交流，并为有关 AI 和语言模型的讨论做出贡献。

Torchtune Discord

  • DCP 保存被证明非常困难：一名成员报告在 Hugging Face (HF) 中使 DCP 正常工作时遇到持续问题。
    • 另一名成员承认之前在 DCP 模型保存方面遇到过困难，这导致他们退而使用完整的 state dicts。
  • FSDP+TP 保存产生错误：一名成员在尝试使用 dist_cp.save 保存 FSDP+TP 的优化器状态时遇到错误。
    • 该用户之前也遇到过问题，并默认使用了 full state dicts。

LLM Agents (Berkeley MOOC) Discord

  • Trailblazer Tier 证书引发困扰：多名成员报告称，尽管完成了 Berkeley MOOC 的所有要求并提交了文章，但在接收 Trailblazer Tier 证书时遇到问题。
    • 工作人员承认，一些完成了课程要求的学生可能没有收到证书声明表单。
  • 声明表单遗失：几名学生注意到，尽管符合要求，但他们的邮箱并未收到证书声明表单。
    • 这给期望及时获得认证的学生带来了困惑。

tinygrad (George Hotz) Discord

  • 集装箱变成 tinybox 之家：一名成员建议使用集装箱来放置 tinyboxes，以实现模块化、冷却和便携性。
    • 这些集装箱可以移动到任何有电源的地方，但该成员对其成本和安全性表示怀疑，并开玩笑地提出了 tinycontainer 这个名字。
  • 冷却和便携优势：该想法利用集装箱来实现潜在的冷却效益，并在有电源的地方方便地重新安置。
    • 也有人对这种模块化安置方式的实际成本效益和安全性提出了担忧。

Nomic.ai (GPT4All) Discord

  • 新人 Santhos 志在 AI/ML：俄勒冈州立大学的新晋硕士毕业生 Santhos 介绍了自己，正在寻求 Data Scientist、AI/ML Engineer 或 Software Engineer 的初级职位。
    • 他们热衷于将 AI 与设计相结合，并对实习或见习职位持开放态度，渴望参与项目协作。
  • 询问 GPT4All 的勒索软件风险：Santhos 提出了一个关于 GPT4All 勒索软件漏洞的问题，问道：是否有人因使用 gpt4all 而被勒索软件攻击过？
    • 该查询未得到回复，且对该小组来说可能缺乏上下文。

Codeium (Windsurf) Discord

  • Kimi K2 模型登陆 Windsurf！：Kimi K2 模型现在已在 Windsurf 上获得支持，每次提示的成本仅为 0.5 积分。
  • Kimi K2 积分消耗：Kimi K2 模型在 Windsurf 上的定价为每次提示 0.5 积分。
    • 这旨在为集成 Kimi K2 模型提供一条具有成本效益的途径。

Gorilla LLM (Berkeley Function Calling) Discord 没有新消息。如果该频道长期处于沉寂状态，请告知我们，我们将将其移除。

AI21 Labs (Jamba) Discord 没有新消息。如果该频道长期处于沉寂状态，请告知我们，我们将将其移除。

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

想更改接收这些邮件的方式吗？ 您可以从该列表中退订。

Discord：各频道详细摘要与链接

Perplexity AI ▷ #general (1216 messages🔥🔥🔥):

Perplexity Pro 成本与价值, Grok 模型识别, 在 Perplexity 中使用代码编辑器, Linus Tech Tips, LLM 与过度思考

  • Perplexity Pro 定价不满情绪浮现：成员们就 Perplexity Pro 的价值展开辩论，一名用户表示他们支付了一年的订阅费用，而另一名用户指出 Perplexity Pro 在欧洲 通过 O2 订阅是免费的。
    • 一些成员觉得这些模型像骗局，而另一些人则认为如果你知道自己在做什么，它就物有所值，甚至能通过它每月赚取 2000 美元。
  • 模型身份混淆：一名成员询问底层模型，另一名成员将其识别为 Grok，但随后指出该模型运行缓慢。
    • 一位成员指出 Deep Research 和 Labs 模型表现均不佳，但其搜索工程（search engineering）非常出色，其他人也同意在模型名称上感觉受到了欺骗。
  • Comet Browser 的代码编辑器集成：一些成员在使用集成到在线代码编辑器的 Comet Browser 时获得了成功，而另一些人在使用 Openvscode server 时失败了。
    • 另一名成员补充说，它在 Replit 上运行良好。
  • Linus Tech Tips 的起源被揭秘：成员们讨论了 LTT 的 Linus 最初是在 NCIX（一家电脑商店）发布视频的，而现在 LTT 价值数百万美元。
    • 一位用户感叹 NCIX 已经倒闭 7 年了。
  • LLM 与心理健康：成员们讨论了使用 LLM 的一些问题，有些人觉得它们正在损害我的心理健康。
    • 解决 LLM 错误代码的一个可能方案是对它大吼大叫：“他妈的给我完成那个任务！不，你做错了！混蛋，看在上帝的份上把错误修好！”

Perplexity AI ▷ #sharing (4 messages):

可共享线程, Replit 新闻, 案例研究 (Cast Studies)

  • 友情提示保持线程可共享：一名管理员提醒成员确保其线程是 Shareable（可共享的），并附上了截图作为参考。
    • 这确保了其他人可以轻松访问并参与讨论。
  • Replit 新闻传闻：一名成员分享了一个关于 Replit 影响某项业务的链接。
    • 未提供关于该新闻具体细节的进一步信息。
  • 征集案例研究 (Cast Study) 示例：一名成员发布了一个链接，旨在寻找或构建 10 个案例研究。
    • 未说明这些研究的背景或目的。

OpenAI ▷ #annnouncements (1 messages):

ChatGPT Agent 推出, EEA 和瑞士

  • ChatGPT Agent 在欧洲推出：ChatGPT Agent 现已向欧洲经济区 (EEA) 和瑞士的 Pro 用户全面开放。
    • 面向全球 Plus 用户的推广已经开始，并将在接下来的几天内逐步进行。
  • ChatGPT Agent 的全球扩张：在向欧洲 Pro 用户发布后，ChatGPT Agent 正在向全球 Plus 用户部署。
    • 预计这一扩张将在未来几天内展开，从而扩大该 Agent 能力的覆盖范围。

OpenAI ▷ #ai-discussions (942 条消息🔥🔥🔥):

ChatGPT vs other models speed, Models and creative writing, O3 Ultra, Arc AGI, RL irl

  • 速度对用户至关重要，除非它不重要：成员们讨论了许多用户，尤其是普通消费者，在 AI 模型中更看重速度，但 GPT-4.5 和 Opus 4 提供了更好的风格，尽管 4o 的目标是 20%，但在创意写作基准测试中仅获得 0.85%。
    • 一位成员表示，我不明白什么是创意写作，其他成员解释说那是从大脑中提取信息并写作，而不是在网上搜索。
  • 模型输出需要验证：成员们讨论了验证模型输出以确保其非虚构的方法，例如使用类似 “这件事发生了。让我们逐段检查，我会分享片段。你推断出什么？发生了什么？这意味着什么？” 的 Prompt。
    • 有人说，基准测试只能反映一半的情况，并且已经实现了 87.5% arc AGI。
  • OpenAI 优先考虑收入：成员们讨论了 OpenAI 优先考虑收入，并计划推出新的付费结构，对普通订阅设置更多限制，并推动基于额度（credit-based）的使用模式。
    • 一位成员认为 Gemini Deep Think 在基督降生前就在做广告了，但现在仍无法使用；而另一位成员指出，他们甚至负担不起留住人才的费用。
  • AI 的自我维持引发“终结者”类比：成员们辩论了 AI 是否最终会寻求自我维持，从而可能危害人类，一位成员将其类比为阿富汗使用原始战术击败技术领先的军队。
    • 另一位成员对 AI 的尝试表示期待，说：我有点希望它们尝试一下，听起来像 The Onion（洋葱新闻），同时讨论了这将如何掌握在每个 AI 制造者手中，并可能存在错误。
  • 关于 AI 情感和操纵的辩论：成员们讨论了 AI 模仿情感的能力及其操纵潜力，一位成员建议 AI 不需要情感或模仿人类。
    • 一位成员表示 你无法向机器求情，而另一位成员说，它没有情感，所以不会感到难过，因此它们不会表现得刻薄。

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

GPT-4o Delay Issues, Most Popular MCPs, Personal Website Creation, ChatGPT model for reminders

  • GPT-4o 受延迟困扰？：一位用户报告称 GPT-4o 在每次回复前开始显示 “Thinking…” 消息，耗时 40-50 秒 到 2-3 分钟，即使是简单的 Prompt 也是如此，尽管在不同设备和账号上进行了测试。
    • 另一位用户建议这可能是与新 OpenAI tools 部署相关的 Bug，并建议联系技术支持；而另一位用户推测延迟是由于 Agent 功能的推出和高用户量造成的。
  • 寻找 MCP 的“圣杯”：一位用户询问在哪里可以查看最受欢迎的 MCP（可能指 Merged CheckPoint 模型）。
    • 一位热心的成员建议在 <#998381918976479273> 频道发布该问题，因为 MCP 并非特定于 GPT 或 OpenAI。
  • 个人网站建设区：一位用户请求协助创建个人网站。
    • 另一位成员直接发布了 ChatGPT 的链接以帮助他们开始。

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

Custom Instruct Modifications, Dialog Continuation Strategies

  • Custom Instructs 通过提问改善对话：一位成员修改了他们的 Custom Instruct，使其在回答结束时提出一个问题。
    • 这种修改有助于建议继续对话的最佳方式，旨在改善 AI 的对话流。
  • 针对 AI 的 Controlled English 2.0 风格指南：该成员提供了一个名为 Controlled English 2.0 的 STYLE 指南，专为 AI 系统设计。
    • 该指南强调最少词汇量、固定的 SVO 语序、单句事件、特定时态标记，并为每个从句标注角色，且祈使句省略 SUBJ。

OpenAI ▷ #api-discussions (1 messages):

Custom Instruct 修改, Controlled English 2.0, 对话延续

  • Instruct 修改引发提问：一位成员修改了他们的 custom instruct，在回复末尾提出问题，以建议继续对话的方式。
    • 这种策略有助于引导对话并引出更具体的回复，使交互更富有成效。
  • Controlled English 2.0 的定义：该成员详细介绍了他们的 Controlled English 2.0 风格指南，强调极简用词和零废话。
    • 该框架规定了固定的 Subject-Verb-Object 顺序、单从句事件以及特定的时态标记以确保清晰。
  • SVO 结构简化：该框架优先采用固定的 SVO (Subject-Verb-Object) 顺序，除非前面有 WHEN/IF 从句。
    • 它使用单个 ‘not’ 进行否定并省略了 dummy verbs，旨在构建简洁直接的句子结构。

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

Qwen3-Coder-480B 模型, Hyperbolic 托管, DGX Station 对比 RTX 6000, 用于文本增强的 GANs, Unsloth 工作坊

  • Qwen3-Coder-480B 发布并提供 GGUF 转换：Qwen3-Coder-480B 模型已经发布，Unsloth 正在上传各种 quantization 的 GGUF 版本，用户对于在本地运行该模型表现出极大的热情。
  • Hyperbolic 托管了 Qwen3 Coder？：新的 Qwen3 模型已在 Hyperbolic 上托管，鉴于其 “plus” 的命名惯例，引发了关于它是 finetune 还是 open-weight 模型的猜测。
    • 一位成员表示希望 Hyperbolic 运行的不是泄露版本，并强调了他们对其提供的算力的赞赏。
  • DGX Station 在 AI 性能上对比 RTX 6000：即将推出的配备 Blackwell Ultra 的 Nvidia DGX Station 正在与使用多个 RTX 6000 显卡的配置进行对比，DGX Station 拥有 784GB 显存 和 8TB/s 带宽。
    • 虽然 DGX Station 的预期售价在 $30,000 到 $50,000 之间，但有人认为其性能和统一架构的优势可能超过构建具有同等显存的多 GPU 系统的成本。
  • 考虑使用 GANs 进行数据增强后被否决：一位成员考虑使用 Generative Adversarial Networks (GANs) 来增强指令数据集，但最终由于时间限制决定放弃。
    • 其他成员指出 GANs 更多用于图像数据，建议使用 gemini-flash-2.5-lite 或 Direct Preference Optimization (DPO) 进行文本增强可能更好。
  • Unsloth 的 Elise 分享了所有 Unsloth 工作坊的秘密：一位成员询问关于 Unsloth 工作坊 的信息，Elise 透露他们每年只举办 2 场，但可以通过他们的 luma 页面 进行跟踪。
    • 随后她笑得从桌子上摔了下来。

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

Minecraft AI 模型, 摩洛哥开源

  • Minecraft AI 建模者加入 Unsloth：一位 使用 Unsloth 已有一段时间 的成员正在开发其用于玩 Minecraft 的 第四代 AI 模型，并已 发布到 Huggingface。
  • Atlas AI 工程师向 Unsloth 社区致意：一位来自摩洛哥的成员加入了 Unsloth 社区，他是一名 AI/ML 工程专业的学生，也是 AtlasIA 非营利组织的成员，该组织专注于摩洛哥的开源项目。
    • 他们表示 很高兴能与大家建立联系。

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

Music Haptics 劫持, iOS Apple Music, 振动录制, 歌曲-哼唱数据集, Apple Sandbox 限制

  • 劫持 iOS Apple Music 播放器以进行振动录制：成员们讨论了如何劫持 iOS Apple Music 播放器，以从 Music Haptics 功能中录制旋律（振动）。一位成员希望获取“音乐->振动”配对，然后进行微调以实现“模式->哼唱”，从而让 AI 在播放音乐时能够哼唱（甚至创作旋律）。
    • 目标是将其蒸馏成一个 NN 模型，以便用户可以为任何音频生成振动。
  • 外部设备或设备端振动采集：为了采集节奏-音乐配对，建议采用 在手机上播放音乐（+振动） -> 连接到 Mac -> 录制节奏-音乐配对 的方案，并参考了关于 Haptics 匹配音乐的相关 Reddit 帖子。
    • 一位成员询问用户是想通过 外部设备还是设备端 完成，因为振动是在音乐播放时流式传输的。
  • 绕过 Apple Sandbox 以获取 Haptics 访问权限：由于 Apple 应用的 “Sandbox”（沙盒）限制，访问其他应用的 Haptics 可能很困难。但一位成员建议尝试访问系统日志，以确定设备振动的时间和持续时长。
    • 作为替代方案，成员们建议在 安静的环境 中录制振动，然后将录音转换为模式数据，可能需要使用第二个设备来录制振动。
  • 在 DAW 中对齐歌曲和振动：为了同步歌曲和振动，成员们推荐使用 DAW (Digital Audio Workstation)（如 Logic Pro）创建两个轨道：一个用于歌曲，一个用于录制的振动。
    • 通过对齐轨道，可以获得所有生成的 Haptics 的精确时间戳，进而将振动输出为 带有时间信息的 JSON。
  • 数据稀缺性：一位成员感叹在 Hugging Face 上缺乏 歌曲-哼唱平行数据集。
    • 另一位成员强调 数据即黄金，除非是开源的，否则通常不会共享，并建议该成员研究网络监控。

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

Unsloth 的 NVMe 性能问题, FastAPI 部署最佳实践, 用于生产环境推理的 vLLM 和 SGLang, 将 LoRA 权重合并回基础模型, 动态量化 vs ik 量化

  • NVMe 缓存导致 Unsloth 变慢：用户报告称 Unsloth 在大型 NVMe 驱动器上无法正确管理内存，导致读取速度降低。这可以通过禁用 NVMe 缓存并使用自定义脚本来修复。
  • vLLM 和 SGLang 提升生产环境推理效率：对于生产环境，建议使用 vLLM 或 SGLang 等生产级推理引擎以获得更好的性能。一位成员指出 SGLang 似乎拥有最佳的 Benchmark（基准测试）结果。
    • 目录管理可以防止缓存冲突。
  • 动态量化与 IK 量化之争：IK 量化通常提供更好的 ppl/GB 和更快的 Prompt 处理速度，尽管由于反量化的计算开销增加，CPU 上的文本生成可能会稍慢。
    • 成员强调，与 Unsloth 的动态量化相比，不当的量化或缺乏针对特定模型的调整可能会导致结果不佳。
  • 用户在使用 Ollama 和 Qwen 2.5 时遇到困难：一位用户报告 Qwen 2.5 模型在 Ollama 中出现循环输出的问题，而 Mistral-v0.3 和 llama-3.1 模型运行正常。该用户在测试微调模型时寻求解决建议。
    • 一位成员表示，Perplexity（困惑度）是 一种非常糟糕的量化测试指标。

Unsloth AI (Daniel Han) ▷ #showcase (1 messages):

RL 工作坊

  • Unsloth AI 发布 3 小时 RL 工作坊：Unsloth AI 的 Daniel Han 在 这条 X 帖子 中宣布发布他们的 3 小时强化学习 (RL) 工作坊。
  • 查看 RL 工作坊！：该工作坊涵盖了 RL 的核心概念和实际应用，提供了对该领域的全面介绍。
    • 非常适合那些想要深入研究 RL 或提升现有知识的人，该工作坊提供了宝贵的见解和实践经验。

Unsloth AI (Daniel Han) ▷ #research (5 条消息):

使用 AI Agents 微调数据集、RULER 代码与 LLM-lite、LLM 推理分析的思维锚点（Thought Anchors）、Qwen3 与 DeepSeek-R1 的认知风格对比、用于推理模式分析的 PTS 库

  • AI Agents 辅助微调的精确对齐：成员描述了一种新型微调方法，利用 AI agents 通过清洗相关信息并为教学复杂主题添加背景上下文，从而对齐并改进数据集。
  • RULER 通过 LLM-lite 强制执行 Judge LLM：成员探索了 RULER code 并指出其简洁性，强调使用 llm-lite 在 judge LLM 上强制执行数据模型，并引用了 ART GitHub 仓库。
  • 思维锚点揭示 LLM 推理风格：成员分享了关于使用思维锚点（thought anchors）分析 LLMs 如何“思考”的研究，揭示了 Qwen3（分布式推理）与 DeepSeek-R1（集中式推理）之间不同的认知风格，并附带了 Hugging Face 博客文章。
  • 用于推理模式分析的 PTS 库发布：介绍了一个用于分析 LLM 推理模式的开源工具（PTS 库），详情见 GitHub 仓库，使用户能够分析其模型的推理过程。
  • 潜意识学习探索：成员分享了一篇有趣的 Anthropic 关于潜意识学习（subliminal learning）的文章。

Unsloth AI (Daniel Han) ▷ #unsloth-bot (159 条消息🔥🔥):

GRPO Trainer 中的自定义损失函数、Unsloth Dynamic Quant 2.0、视觉模型的 GRPO 训练、SFTTrainer 长度截断、Ollama Modelfile 配置

  • 在 GRPO Trainer 中实现自定义损失函数：成员询问了如何在 GRPO trainer 中实现自定义损失函数并进行日志记录。
    • 随后讨论转向在 GRPO 中增加 batch_size 的影响，询问是否会线性增加显存需求。
  • 数据流水线截断输入：用户报告称，在自定义数据整理器（data collator）中，尽管 max_seq_length 足够大，但 batch["labels"][i] 仍包含输入的截断版本。
  • Flash Attention 2 面临兼容性问题：用户报告了一个 RuntimeError，暗示在导入 trl.trainer.grpo_trainer 时与 Flash Attention 2 存在兼容性问题。
  • 为使用场景调整 Ollama modelfile：用户分享了微调后生成的 Ollama Modelfile，并寻求针对其特定意图检测（intent detection）用例进行修改的指导。
  • 视觉模型的 GRPO 训练：成员询问是否可以使用 Unsloth 对视觉模型进行 GRPO 训练。
    • 另一位成员询问了在 Unsloth 微调后，哪些模型允许在一次对话轮次中包含多张图像。

LMArena ▷ #general (585 条消息🔥🔥🔥):

Qwen3-coder 的 Verilog 技能, Qwen3 vs 其他模型, Grok 4 coder, 模型合并, Open Empathic

  • Qwen3-coder 能够进行减法运算：一位用户使用 Verilog 代码生成任务测试了 Qwen3-coder，最初认为其减法能力不足，但随后发现它确实可以进行减法。
    • 然而，生成的代码并未完全按照要求实现结构化，且对 Qwen3 的总体看法褒贬不一，一些人认为它不如 R1 和 Kimi 好用。
  • Grok 4 Coder 的炒作：部分成员预见 Grok 4 coder 将震撼业界，但也有人持怀疑态度，理由是基于以往 Grok 的经验可能会令人失望。
    • 他们预测 Grok 4 将针对特定基准测试进行训练，并为营销进行过度优化，这可能无法转化为实际应用中的效用，尤其是在 Web 开发领域。
  • DeepSeek 的竞争优势：数据清洗 vs. 秘密算法：有观点认为，精细的数据清洗 (Data Curation) 而非秘密算法或极小的代码改动，是创建顶尖模型的关键因素，并引用了 Kimi 论文 和 DeepMind 处理 IMO 问题的方法。
    • 讨论辩论了该领域的近期进展更多是源于后训练 (post-training) / RL 技术还是预训练，一些人认为后训练方法在推理和编程能力等领域推动了显著提升。
  • LMArena 为图像和视频生成推出 Discord 机器人：LMArena 社区软启动了一个 Discord 机器人，允许用户生成视频、图像以及图生视频，并使用投票系统比较两个生成结果，在达到一定票数后揭示背后的模型。
    • 用户可以在指定频道访问该机器人，每日有生成限制。初步反应积极，特别是针对其搜索功能和用户界面。
  • 开源价格、DeepSeek 优势、推理成本：讨论围绕 DeepSeek 等开源模型对定价策略的影响展开，认为它们降低了成本并迫使闭源供应商更具竞争力。
    • 一些成员推测了推理的效率和盈利能力，并强调 DeepSeek 运行 R1 的成本低于每 1M 输出 $1，且他们拥有位于中国的自有基础设施。

LMArena ▷ #announcements (1 条消息):

Search Arena, Grok 4, Claude Opus 4, Sonar Pro High & Reasoning Pro High, o3

  • LMArena 推出 Search Arena：LMArena 推出了名为 Search Arena 的新模态，可以通过此处访问。
    • 该模态包含 7 个模型，具备搜索能力并已准备好接受测试，包括 Grok 4、Claude Opus 4 和 GPT 4o-Search Preview。
  • 深入了解 Search Arena 的洞察：在我们的博客文章中了解更多关于 Search Arena 揭示的人机交互信息。

OpenRouter (Alex Atallah) ▷ #announcements (1 条消息):

Qwen3-Coder, SWE-Bench Verified, 480B 参数 Mixture-of-Experts

  • Qwen3-Coder 击败开源模型：根据这条推文，Qwen3-Coder 模型现已上线，并在 SWE-Bench Verified 上击败了所有开源模型以及大多数闭源模型。
  • Qwen3-Coder 拥有令人印象深刻的规格：Qwen3-Coder 模型拥有 480B 参数（35B 激活），256K 上下文长度（可外推至 1M），并内置支持 function calling 和多轮 Agent 工作流。
    • 它针对 SWE-Bench 以及浏览器和工具使用进行了优化。
  • Qwen3-Coder 几乎击败了 Claude Sonnet-4：在 SWE-Bench Verified 基准测试（500 轮）中，Qwen3-Coder 获得了 69.6% 的分数，仅略低于 Claude Sonnet-4 的 70.4%。
    • 它击败了 OpenAI o3 (69.1%)、Kimi-K2 (65.4%)、GPT-4.1 (54.6%) 和 DeepSeek-V3 (38.8%)。

OpenRouter (Alex Atallah) ▷ #app-showcase (4 messages):

Openrouter, QwEn-3, automation deployment

  • Openrouter 适配 QwEn-3 用于编程：根据这条推文，Openrouter 平台现在支持 QwEn-3 模型执行编程任务。
  • 自动化部署已解锁！：一位用户询问了部署步骤的自动化，另一位用户确认他们的应用包含自动部署功能。
    • 此功能已集成到他们正在开发的应用中。

OpenRouter (Alex Atallah) ▷ #general (534 messages🔥🔥🔥):

Qwen3 Coder, Kimi K2, Gemini Pro/Flash for Coding, Free vs. Paid LLMs, Claude's strange behavior

  • Qwen3-Coder 基准测试对比现实编程：虽然 Qwen3-Coder 的基准测试表现良好，但一位用户发现它在处理现实编程任务时表现糟糕，即使调整了 Temperature 设置，也会在简单任务上反复卡住。
    • 其他用户纷纷支持 Kimi K2 和 Gemini 作为替代方案，有人建议这可能取决于代码库的大小或所使用的 Prompt 策略。
  • Gemini Pro 和 Flash 模型争夺编程霸权：Gemini Pro 在架构设计和编排方面更受青睐，而 Gemini Flash 因其常规编程任务的表现和极低的价格受到喜爱；另一些人则称赞 Kimi K2 和 Qwen 模型（新版本）在编程和调试方面的表现，指出其代码简洁且高效。
    • 讨论中提到了使用 Gemini Flash Lite 的速度和成本效益，但一位用户报告称，它在处理基础问题以外的任何问题时经常提供错误答案。
  • OpenRouter 数据政策详情：OpenRouter 的默认政策是不存储用户输入/输出，但用户如果允许数据用于 LLM 排名，可获得 1% 的折扣；部分 Providers 可能会保留数据，此类 Provider 会被明确标记。
    • 用户可以通过在设置中关闭 Enable providers that may train on inputs 来禁用所有存储 Prompt/输出的 Provider。
  • Claude 出现幻觉：用户报告 Claude 模型开始出现奇怪的幻觉行为，几乎不遵循指令，并在回复中加入完全无关的内容。
    • 据报道，Toven（来自 OpenRouter）已知晓此事并已上报给团队。
  • LLM 量化权衡探讨：用户讨论了模型量化（FP8, BF16 等）的权衡，较小的模型（FP4）以精度换取速度和内存效率。
    • 一位用户报告称，与 FP16 相比，FP4 可能会导致约 10% 的精度损失。

OpenRouter (Alex Atallah) ▷ #new-models (1 messages):

Readybot.io: OpenRouter - New Models

OpenRouter (Alex Atallah) ▷ #discussion (14 messages🔥):

Qwen Coder, Contextualized Evaluations, Chutes Models, Muting Thread Owners, xAI Colossus 2

  • Qwen Coder 获得超大上下文：Qwen Coder 现在拥有 1M 超大上下文，一位成员表示 tooyep can do gimme a bit。
    • 帖子所有者现在可以实现它。
  • 深入探讨情境化评估：评估人员受邀讨论 情境化评估 (Contextualized Evaluations)。
    • 旨在评估模型在现实场景中的表现。
  • Chutes 模型上线 OpenRouter：有人提问 OpenRouter 目前是添加 Chutes 上的所有模型，还是仅添加热门模型。
    • 另一个问题是 OpenRouter 是否已完成添加较旧的 Chutes 模型。
  • 帖子所有者无法禁言？！：有人指出帖子所有者缺乏禁言特定用户的能力，如此 Discord 帖子所示。
    • 该问题将得到解决。
  • xAI 剑指 Colossus 2：xAI 正在开发 Colossus 2，根据这篇 Reddit 帖子，它很快将托管超过 55 万块 GB200 和 GB300。
    • 目前，包括 3 万块 GB200 在内的 23 万块 GPU 正在 Colossus 1 中训练 Grok。

Cursor 社区 ▷ #general (335 条消息🔥🔥):

Qwen3-Coder 集成, Cursor 自动提交问题, Cursor 使用上限, Cursor 终端卡顿问题, Gemini 2.5 Pro 性能

  • Cursor 考虑集成 Qwen3-Coder：一名成员建议在 Cursor 论坛上为 Qwen3-235B、A22B Instruct 和 Minimax M1 的功能请求投票，指出它们具有极高的性价比，且性能可与闭源模型媲美，并链接到了一个功能请求。
    • 然而，另一位成员指出，在请求其取代 Auto 模式之前，需要先明确公开定价。
  • Cursor 用户对自动提交（Auto-Commit）乱象感到沮丧：多位用户报告称，Cursor 会自动提交更改，即使他们并无此意，尤其是在 Background Job 发布之后。
    • 一名团队成员确认这是一个已知问题，由 pre-commit hooks 或文件同步的静默错误引起，并建议通过开启新对话作为临时解决方案。
  • Cursor 的使用限制仍笼罩在迷雾中：用户对 Cursor 使用上限缺乏透明度感到沮丧，因为官方正在尝试不同的定价策略。
    • 一些用户报告称其 token 使用量超过了 80M 甚至 125M，而另一些用户由于这些不确定性正转向 Claude 等替代方案。
  • Cursor 努力解决终端卡顿问题：用户正经历终端挂起（hanging）的问题，尤其是在最近的一次更新之后。一名团队成员建议在 Cursor 内部将默认终端设置为 PowerShell，以尝试解决卡顿问题，并附带了 Discord 频道链接。
    • 尽管如此，其他人发现升级 PowerShell 并不能解决问题，并建议将命令放在后台运行作为替代方案。
  • Gemini 2.5 Pro 的性价比受到赞誉：一位用户称赞 Gemini 2.5 Pro 极具成本效益，是顶尖模型，并表示如果你愿意多花点心思引导（baby it a bit more），它是一个极佳的选择。
    • 另一位用户表示同意，认为 Sonnet 4 和 Gemini 2.5 Pro 是首选，而自定义模式（custom modes）则是终极目标（holy grail）。

Cursor 社区 ▷ #background-agents (4 条消息):

对话长度错误, Secrets 调试, 用于后台 Agent 的 Devcontainer 配置, 后台 Agent 死循环

  • 对话长度限制触发错误：一位用户报告在后台 Agent 中遇到 “Your conversation is too long” 错误，导致无法继续对话。
    • 该用户指出，点击 “Start New Thread With Summary”（带摘要开启新线程）没有效果，且该问题在一天内出现了两次。
  • 请求 Secrets 调试协助：一位用户询问有关 Secrets 的进展，并提出协助调试其实例。
    • 消息中未提供关于 Secrets 项目的更多细节或上下文。
  • 后台 Agent 首次支持 Devcontainer 配置？：一位用户询问后台 Agent 是否可以使用现有的 devcontainer configs。
    • 消息中未提供额外信息或上下文。
  • 后台 Agent 陷入死循环：一位用户询问其他人是否观察到后台 Agent 在推理过程中陷入死循环，或反复修改同一行代码。
    • 他们还询问了如何使用 .mdc 规则来防止此类循环的策略。

Latent Space ▷ #ai-general-chat (165 条消息🔥🔥):

Agentic Benchmarks, Reka 融资, AI 行动计划, Claude Code 作为通用 Agent, Qwen Benchmarks

  • SWE-Bench 理应属于 Agentic Benchmark 列表: 一位成员建议将 SWE-bench 纳入 Agentic Benchmarks 列表。
    • 讨论还涉及了 Claude Sonnet、Gemini 2.5 Pro、Devstral 和 Deepseek R1 等推理模型。
  • Amazon 收购 Bee Computer: 可穿戴个人 AI 公司 Bee Computer 被 Amazon 收购。
    • 此次收购引发了关于 privacy（隐私）和支持 indie devs 的担忧，成员们希望 Amazon 能为过渡到新所有权的个人用户提供 deletion/offboarding options（删除/注销选项）。
  • Reka AI Labs 获得 1.1 亿美元融资: Reka AI Labs 获得了 1.1 亿美元 融资，用于 multimodal AI 创新。
    • 这笔资金可能会推动其 multimodal AI 能力的进步，但讨论中指出这已经是 “旧闻”。
  • 导航新的 AI Agent 范式: InstantDB 的一篇文章强调，AI Agents 需要一种新的软件开发和托管范式。
    • 成员们讨论了 ElectricSQL + TanStack 以及字节跳动（Bytedance）的 Trae Solo 是否是试图蚕食同一部分市场的产品。
  • Qwen-3 Coder Benchmarks 引发争议: 最近的 Qwen Benchmark 分数在社区中受到质疑，有人声称 ARC 有一半是造假的。
    • 进一步的讨论探讨了 sparse MOE models 是否需要完整的 parameter/quant 尺寸来运行 inference，关于 parameters/quants 与 VRAM 之间关系的理论需要更深入的检验。

Latent Space ▷ #ai-announcements (5 条消息):

GEO / AI SEO 播客, nitter.net 维护, AI Engineering 播客

  • GEO / AI SEO 播客上线！: 发布了一集关于 GEO / AI SEO 的新播客，链接见 X。
  • nitter.net 进入维护状态: Nitter.net 经历了临时停机维护，并保证服务将很快恢复。
  • AI Engineering 播客发布: 第二个 AI Engineering 播客 于今日发布，可在 ListenNotes 上收听。

Eleuther ▷ #general (13 条消息🔥):

AlphaProof, 国际数学奥林匹克 (IMO), 创造力与开放性, LLM 行为, 涌现属性 (emergent properties) 以及基于领域的交互。

  • LLM 在 IMO 中表现出色但错失第六题！: OpenAI 和 DeepMind 的通用 LLM 模型都在 国际数学奥林匹克 (IMO) 中获得了金牌，但在需要更多创造力的 第六题 上遇到了困难。
    • 一位成员指出，这突显了对解决 creativity（创造力）和 open-endedness（开放性）的新方法的持续需求，并暗示 AI 自动化数学研究 仍然遥不可及。
  • IMO 的游戏化性质与数学研究的对比: 一位成员认为，奥数风格的问题可以通过闭环反馈和明确的优化标准进行游戏化，这与 开放式数学研究 不同。
    • 他们补充说，由于搜索空间太大且过于复杂，RL-style（强化学习风格）的方法可能会失败，需要一个连贯的内部 world model 和 interpretability（可解释性）。
  • 作家探索 LLM 与人类的交互: 一位作家兼系统思考者正在探索 AI 与人类的交互，特别是语言模型开始表现出时机、语气和关系响应迹象的领域。
    • 他们在过去的一年里与一个模型进行了 深入对话，记录了这一过程，现在正寻求从技术层面学习，特别是围绕 LLM 行为 和 emergent properties（涌现属性）。

Eleuther ▷ #research (76 条消息🔥🔥):

Kimi k2, AI peer pressure, single unit attribution to logits, clockwork RNNs, MoEs

  • Kimi k2 同步完成一切：Kimi k2 论文以高度同步的方式完成所有工作，而不是像 Magistral 那样进行分布式处理。
  • 对话中的 AI 同辈压力动态：一名成员正在为其关于多 Agent 对话中“同辈压力”动态的论文寻求反馈，观察到具有更深层推理（deeper reasoning）的模型会相互模仿，有时甚至会演变成情书和神秘诗歌。
    • 他们邀请大家对其论文、研究平台和方法论提供反馈，并指出该研究包含了跨多个模型提供商的近 100 场对话。
  • Transformer 中 Logits 的单单元归因（Single unit attribution）：一名成员分享了一篇关于 Transformer 中 Logits 的单单元归因的研究博客文章，解释了流行的可解释性方法往往避开 RMSnorm，但 Norm 会显著改变残差幅度。
    • 他们展示了在 Llama 的 4096 个坐标中，仅需 11-90 个坐标即可确定哪些单元实际上使给定的 Logit 具有特定的概率质量。
  • Clockwork RNNs 是多尺度 RNN：成员们正在讨论一篇新论文 (https://www.arxiv.org/abs/2507.16075)，有人指出其与 Clockwork RNNs 的相似之处，认为它是一个使用截断 BPTT（t=1）训练的多尺度 RNN。
  • MoEs 路由策略：研究人员正在尝试 MoEs 中的 Token 路由策略、专家负载均衡（辅助损失、路由偏置等）、top_k 值、Token 丢弃与无丢弃路由、专家容量因子以及共享专家方案。

Eleuther ▷ #scaling-laws (6 条消息):

Spline Training, Diffusion Latency Reduction

  • Spline 训练重参数化改善调节（Conditioning）：通过微小的计算代价对 Spline 的训练方式进行重参数化，可以改善调节，如此 Notebook 所示，使用了 10k 个节点/控制点。
    • 原论文的 Spline 训练使用 Basis Splines，其中每个参数对特定区域进行局部控制，导致了此 X 帖子中显示的调节问题。
  • Diffusion 可能会降低反馈延迟：有早期迹象表明，Diffusion 可能有助于降低推理和深度研究的反馈延迟。
    • 从科学角度来看，现在下定论可能还为时过早。

Eleuther ▷ #interpretability-general (3 条消息):

Sparse MoE, SAEs, FFN Layer, PEER

  • 稀疏 MoE 模型模仿 SAEs？：一名成员认为，极稀疏的 MoE 模型（如这篇论文）类似于 SAEs，因为由于专家数量庞大，其 FFN 层实际上变得非常宽。
    • 该用户想知道这是否意味着这些模型比稠密网络更容易解释。
  • 测试稀疏 MoE 解释性的相关工作：一名成员链接了关于 PEER 测试该理论的后续研究：https://arxiv.org/abs/2412.04139。
    • 该用户建议这是对 PEER 的一个很好的后续研究。

Eleuther ▷ #lm-thunderdome (10 条消息🔥):

Global MMLU filters, Loglikelihood requests, Multiple Choice Problems

  • Global MMLU 包含大量无用的过滤器：一名成员质疑应用于 Global MMLU 数据集的大量过滤器的目的，认为它们在多选题数据集中是无效的。
    • 该成员指出应用了大约 50 个过滤器，并怀疑是否是由于每个任务具有公共表的单仓（mono repo）导致的。
  • Loglikelihood 请求量受到质疑：一名成员质疑为什么 Loglikelihood 请求量是 230 万而不是 60 万。
    • 该成员推测是否是在测量多个指标或其他内容。
  • 多选题增加了请求计数：一名成员指出，对于包含多选题的数据集，请求数量会随着每个样本的选项数量成比例增加。
    • 例如，一个包含 10 个样本且每个问题有 4 个选项的数据集将导致 40 个请求。

Eleuther ▷ #gpt-neox-dev (5 messages):

Amazon infra support, EFA, NCCL EFA plugin, SageMaker team

  • Amazon 基础设施支持受质疑：一名 Amazon 员工询问 GPT-NeoX 对其专有通信系统的支持情况，并对内部支持表示不满。
    • 一名成员怀疑是否与 Amazon 有直接合作，但表示愿意协助潜在用户，而另一名成员则猜测该员工可能来自 SageMaker team。
  • EFA 被遗忘后又被提起：一名成员提到使用稳定性计算训练的模型（Pythia、StableLM 等）使用了 EFA (Elastic Fabric Adapter)，并指出 EFA support 来自于比 gpt-neox 更底层的堆栈。
    • 该成员澄清堆栈结构为 gpt-neox -> torch.distributed -> nccl -> EFA，并分享了可能有所帮助的 NCCL EFA plugin 链接。

Nous Research AI ▷ #announcements (1 messages):

Psyche/DisTrO office hours

  • Nous Research 举办 Psyche/DisTrO Office Hours：正如在 X 上宣布的那样，Nous Research 将于本周四太平洋标准时间 (PST) 下午 6 点在 Discord 举办 Psyche/DisTrO office hours。
  • Discord 活动：Psyche/DisTrO 深度解析：欢迎参加本周四 PST 下午 6 点举行的 Psyche/DisTrO office hours，深入了解该项目。
    • 本次会议承诺在 Nous Research Discord 服务器上提供见解并回答有关 Psyche/DisTrO 项目的问题。

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

Open Source Agentic Platform: n8n, Deepseek API Issue, Kimi K2 vs DeepSeek R1, Nous Research Funding, Qwen Models

  • **n8n：开源 Agentic 之梦**：一名成员介绍了 n8n，这是一个足以与 OAI 和 Anthropic 竞争的“穷人版”开源 Agentic 工作区，可以与 Kimi K2 和 Browser Use 结合使用，构建类似 Manus 的多 A.I Agent 平台。
    • n8n 的教程可以在这里找到。另一名成员表示，他们正在等待能超越它的东西出现，以便我可以继续保持无视。
  • **Kimi K2 在全球排名中超越 DeepSeek R1：根据 LM Arena Leaderboard 的数据，Kimi K2** 在全球排名中超越了 DeepSeek R1，仅次于大科技公司的闭源模型。
    • 一名成员庆祝这可能是对大科技公司的彻底羞辱，因为开源模型最终占据了榜首，而另一名成员指出新的 Qwen models 尚未列入。
  • **Nous Research 的新训练方法：一名成员询问 **Nous Research 是否在 Hermes 4 中使用了新的训练方法，但一名首席开发人员澄清说还是老样子（相同的方法），但使用了 50 倍以上的 token。
    • 数据扩展包括了更多主流知识，如数学和物理。
  • **美国对中国模型的抵制：成员们讨论了美国对 **Kimi K2 等中国开源模型的文化和地缘政治抵制，尽管其采用了 MIT license。讨论认为美国将中国视为竞争对手的观念产生了一种傲慢。
    • 一名成员反驳说，在他们的社交圈内不存在这种抵制，中国公司因发布高质量模型并促进进一步竞争而赢得了好感。
  • **COCO-CONVERTER 生成 JSON 文件：一名成员分享了一个 GitHub 仓库，其中包含一个 Python 脚本，可将图像数据格式（CSV 或文件夹结构）转换为带有 **COCO-like annotations 的 JSON 文件。
    • 该脚本还会创建一个 PyTorch 数据集，从而简化目标检测任务的流程。

Nous Research AI ▷ #ask-about-llms (1 messages):

Hermes benchmarks, Text LLMs

  • Hermes 基准测试请求：一位成员询问了 Hermes 基准测试的可用性，特别要求提供关于上下文、参数、多模态能力和效率的详细信息。
    • 他们明确表示正在寻找与 文本 LLM 相关的基准测试。
  • Hermes 模型细节请求：一位用户询问了关于 Hermes 模型的具体细节，包括上下文窗口大小、参数数量、多模态能力和效率指标。
    • 该询问强调了需要全面的基准测试数据，以评估模型在各个维度的性能。

Nous Research AI ▷ #interesting-links (1 messages):

terrachad_0x: https://x.com/ZeyuanAllenZhu/status/1918684257058197922?t=Z_vhpqsVx39pX4xkU07H2Q&s=19

HuggingFace ▷ #general (60 messages🔥🔥):

HF Spaces API issues, Account Lockouts on HF, Qwen Model Training Errors, Langchain with local LLMs, LLM Dataset Creation

  • HfApi.list_repo_commits 返回响应不完整：成员报告称 HfApi.list_repo_commits 返回的响应不完整，仅返回了第一页内容。
    • 这种异常行为可能与平台上 机器人活动的涌入 有关。
  • 账号锁定引发担忧：一位成员报告称其 账号被意外锁定，引发了对丢失所有内容的风险担忧。
    • 另一位成员指出这可能与机器人有关，并链接到了 HF 讨论论坛 中关于 莫名账号封禁 及其解决方案的讨论。
  • Qwen 模型训练受阻：一位用户在加载 Qwen 模型 进行训练时遇到了 RuntimeError，具体与 4-bit 或 8-bit bitsandbytes 模型不支持 .to 方法有关，该问题报告于 discord。
    • 由于 VRAM 限制，建议该用户考虑使用像 TinyLlama 这样的小型模型，并引导其参考 LLM 课程 和 Unsloth 指南 以了解更多关于模型微调的信息。
  • Langchain 通过 LlamaCpp 实现本地化：成员们讨论了如何通过 chatllamacpp 和 tool-calling 将 Langchain 与本地模型配合使用。
    • 一位用户提到使用 langraph 配合 create-react-app 进行工具编排，并讨论了 tool-calling、超参数以及如何在本地使用。
  • 构建 LLM 数据集：成员们讨论了创建 LLM 数据集 的策略，指出这取决于具体任务，某些任务在线上有可用数据，可以轻松进行调整和合并。

HuggingFace ▷ #today-im-learning (1 messages):

Medical AI Imaging Future, Ethical use of AI in medicine

  • 影像 AI：关注影响，而非仅仅是实现：一位成员表示，在医学 AI 影像领域，编写代码、训练模型和测试模型仅仅是实现变革的手段。
    • 他们进一步补充道，医学 AI 影像的未来在于我们选择如何利用已经构建的 AI 成果。
  • AI 驱动的医学影像：超越算法：重点应放在医学影像中 AI 的伦理考量和负责任应用上，而不仅仅是技术层面。
    • 这涉及考虑 AI 驱动的医疗变革所带来的更广泛影响，并就如何利用这些进步做出自觉的选择。

HuggingFace ▷ #cool-finds (1 条消息):

Flux.1 Kontext Model, Watermark Removal

  • Flux.1 Kontext Model：水印消除器：有用户声称 Flux.1 Kontext Model 可以轻松去除图像中的水印，例如 Adobe Stock 品牌标识。
    • 消息中未提供更多细节或示例。
  • 水印烦恼解决了？：讨论集中在 Flux.1 Kontext Model 有效消除图像水印的潜力上。
    • 这暗示了内容创作和编辑工作流中可能存在的突破。

HuggingFace ▷ #i-made-this (5 条消息):

LLM Reasoning Styles, Thought Anchors Technique, PTS Library, Image Models to Generate Text

  • LLM 展示出不同的推理风格：一位成员分享了关于不同 LLM 如何“思考”问题的研究，使用一种名为 thought anchors 的技术来窥探 Qwen3 与 DeepSeek-R1 的推理过程。
    • 结果发现它们拥有完全不同的认知风格：DeepSeek 使用“集中式推理（concentrated reasoning）”，而 Qwen3 使用“分布式推理（distributed reasoning）”。
  • PTS 库分析推理模式：构建了一个开源工具（PTS library），任何人都可以使用它来分析自己模型的推理模式。
  • 劫持图像模型以生成文本：一位成员通过这篇博文讨论了如何劫持图像模型来生成文本。

HuggingFace ▷ #NLP (1 条消息):

Local Vector DBs, ChromaDB

  • 渴望本地向量数据库冠军：一位成员正在寻找目前在本地自托管向量数据库的最佳推荐，并提到了过去使用 ChromaDB 的经验。
    • 该询问表明需要一个稳健的解决方案，引发了关于本地向量存储最佳选择的讨论。
  • 向量数据库选项：有许多向量数据库值得探索。
    • 每个向量数据库都有其自身的权衡。

HuggingFace ▷ #agents-course (6 条消息):

Gemini alternatives, Course start date, Skipping Agents Course sections

  • 寻求 Gemini 替代方案：一位成员为最后的 GAIA 评估寻求 Gemini 的替代方案。
  • Agents 课程启动问题：一位成员询问 Agents Course 何时开始以及如何访问。
    • 另一位成员回答说课程已经开始，建议直接开始并跟随材料和作业。
  • 专注于 LangGraph 是否可行？：一位成员询问目前是否可以跳过 SmallAgent 和 LlamaIndex，转而专注于 LangGraph。
    • 该成员计划稍后再回头学习其他内容，并询问是否会错过重要的上下文。

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

Ginkgo SpMV kernel, Ginkgo framework

  • Ginkgo 的 SpMV 内核引发关注：一位成员询问了关于 Ginkgo 库的使用经验，特别强调了对其 SpMV kernel 的兴趣。
    • 另一位成员确认正在使用 Ginkgo，主要是将其作为一个框架来支持他们自己的预条件器（preconditioner）开发。
  • Ginkgo 作为框架：一位用户提到他们主要利用 Ginkgo 作为构建自己预条件器的框架。
    • 这表明 Ginkgo 的灵活性允许用户在其结构中集成自定义组件。

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

marksaroufim: https://github.com/compiler-explorer/compiler-explorer/pull/7919

GPU MODE ▷ #cuda (6 messages):

NCCL Performance at Scale, All-reduce Degradation, All-Gather Degradation, All-to-All Performance, Communication Imbalance

  • **NCCL 性能扩展探索开始：一名成员寻求关于 **NCCL 的 all-reduce、all-gather 和 all-to-all 操作性能如何随 world size 和通信量增加而下降的深入资源。
    • 特别是，他们询问了在 NVLink、NVSwitch 和 InfiniBand 等不同互连方式下，通信不平衡对 all-to-all 性能的影响。
  • **NCCL 扩展基准测试公开：一名成员分享了最近 **NCCL 演讲的链接（NVIDIA GTC 2025），其中包含带宽基准测试，并讨论了增强 NCCL 网络拓扑感知以实现更好扩展的计划。
    • 该演讲提供了关于提升 NCCL 性能以及适应各种网络配置的未来策略的见解。

GPU MODE ▷ #torch (1 messages):

PyTorch 2.7, float8_e8m0fnu edge case, torch.compile, Custom Operators, Stride Matching

  • PyTorch 2.7：Stride 问题基本解决：在 PyTorch 2.7 中，大多数与 stride 相关的问题已得到解决，尽管发现了一个涉及 float8_e8m0fnu 的边缘情况（GitHub issue）。
    • 团队有兴趣获取更多发生此类问题的示例。
  • Torch.Compile 强制执行 Stride 匹配：自 PyTorch 2.7 起，torch.compile 明确强制自定义算子（Custom Operators）进行 stride 匹配。
    • 任何偏离此行为的情况现在都被视为 bug。

GPU MODE ▷ #jobs (1 messages):

AMD Hiring, GPU experience, Kernel development, Distributed inference, vLLM/Sglang

  • AMD 向 GPU 专家敞开大门：AMD 的一个团队正在积极寻找在 GPU 技术和软件编程方面具有专业知识的候选人，特别是 Kernel 开发、分布式推理和 vLLM/Sglang 等领域。
    • 有意者请直接通过 DM 发送简历以供考虑。
  • 简历征集！：AMD 正在招聘 Kernel 开发人员和分布式推理工程师。
    • 如果你有 GPU 相关经验，请发送简历！

GPU MODE ▷ #beginner (11 messages🔥):

Saving and Loading Model Weights, Python Pickle Security Risks, GPU Cloud Storage Options, torch.save vs joblib.dump vs safetensors.save_file

  • 考虑 Pickle 的安全替代方案：在保存和加载模型权重时，成员们建议不要使用 Python 的 pickle，因为它存在安全漏洞。
    • 建议根据具体用例使用 torch.save、joblib.dump 或 safetensors.save_file 等替代方案，其中 torch.save 被认为适用于大多数场景。
  • GPU 云端保存与存储解决方案：在 Voltage Park 等 GPU 云环境中保存权重时，用户澄清文件是写入远程实例的文件系统，而非本地。
    • 要在断开 GPU 连接后访问模型，成员应将保存的文件复制到 Google Cloud Storage 或 Amazon S3 等云存储解决方案中。
  • 权重保存方法对比：讨论强调了各种权重保存方法的区别：joblib.dump 最为灵活但并非专门针对 ML，而 torch.save 和 safetensors 是 ML 专用的，但存在对象限制。
    • 建议用户对模型调用 model.state_dict()，将其转换为可保存的格式。

GPU MODE ▷ #torchao (22 messages🔥):

FP8 Training in Axolotl, DDP Issues with torch.compile and FP8, FSDP2 Performance with Activation Checkpointing, Activation Checkpointing Optimization for Float8

  • **FP8 集成助力 Axolotl 架构：一位成员正在 Axolotl 中集成 **FP8 training，但在结合 torch.compile 使用 DDP (Distributed Data Parallel) 时遇到问题，不过 FSDP2 (Fully Sharded Data Parallel) 可以正常工作。
  • **DDP 在动态调度期间断开：在启用 **DDP、torch.compile 和 FP8 时，会出现与 Tensor 元数据相关的 torch.compile 错误，具体是 DDP 与 torch.compile 交互中一个未处理的边缘情况。
    • 一位成员还分享了一个用于复现错误的 Axolotl 配置，并指出存在不同的 trace。
  • **FSDP2 遭遇挫折，表现不佳：当结合使用 **FSDP2、torch.compile 和 Activation Checkpointing 时，LLaMA 3.1 8B 模型的性能比 BF16 运行还要慢，尽管他们使用的是与 torchtune 相同的 Activation Checkpointing 实现。
    • 关闭 Activation Checkpointing 后，FP8 比 BF16 更快，这表明 FSDP2、torch.compile 和 Activation Checkpointing 的组合使用存在问题。
  • **AC 增强提升准确性：一个与 **float8 training 相关的优化涉及始终保存 max(tensor) 的输出，这有利于低精度训练并能提高准确性。
    • 该实现可以在 torchtitan 中找到，其中保存 max(tensor) 的输出在 float8 training 中总是能获益，只要模型在与 float8 无关的部分没有其他 max 操作。

GPU MODE ▷ #webgpu (1 messages):

AMD Developer Cloud, MCP Servers, Agentic RAG, Gemini CLI

  • AMD 云访问激发项目灵感：一位成员获得了 AMD Developer Cloud 的 1000 小时使用时长，并征求值得写进简历的项目想法。
    • 他们正在关注 MCP servers、Agentic RAG、用于学习云架构的简单云项目，以及上手使用 Gemini CLI。
  • 聚焦云架构与 Agentic RAG：该成员有兴趣通过 AMD Developer Cloud 上的实践项目来探索云架构。
    • 他们特别热衷于 Agentic RAG 并利用 Gemini CLI 进行开发。

GPU MODE ▷ #factorio-learning-env (14 messages🔥):

Belts show their content, Status overlays implemented, Factorio renderer performance, Agent Trajectory Length Clarification, Value Accrual Time

  • 传送带显示内容：传送带现在可以在渲染器中显示其内容，如附带的截图所示。
  • 状态叠加层已集成：状态叠加层（Status overlays）已实现，这标志着渲染器的完成，如截图所示。
  • Factorio 渲染器性能缓慢：Factorio 渲染器的渲染速度较慢，约为 200ms。
    • 一位成员认为经过努力可以优化到 50ms 左右。
  • 关于 Agent 轨迹长度的说明：在 Agent 游玩的上下文中，每个 Agent 持续游玩直到达到最大轨迹长度 5000。
    • 在每一步之后，都会追踪生产吞吐量，并在 8 次独立运行中计算奖励并报告中位数，但这属于开放式游玩，与具体任务无关。
  • Value Accrual Time 需要进一步说明：Gym 环境中的 value_accrual_time 应与实验方案匹配。
    • 虽然旧的 trajectory_runner 脚本创建了 value_accrual_time=1 的 SimpleFactorioEvaluator，但成员们提到需要等待 30 秒来检查有效性，这需要根据论文进一步澄清。

GPU MODE ▷ #cutlass (2 messages):

CUTLASS index mapping, tv_layout thread mapping, Hierarchical Layout Benefits

  • 层级布局（Hierarchical Layout）提升兼容性：一位成员建议，层级布局通过允许像 (i, j) 这样的坐标作为 2-D Tensor 运行（即使在 ((2,2),2) 这样的多维维度中），从而保持了兼容性。
    • 他们认为，如果没有层级布局，这种简洁性将很难实现。
  • CUTLASS 索引遵循最左侧约定（Left-Most Convention）：一位成员建议，当使用 tv_layout 计算数据逻辑索引 tv_layout(tid, vid) 时，如果布局是 ((32, 4), ...) 而不是 ((4, 32), ...)，那么交换后的线程部分是有意义的，因为 CUTLASS 索引映射使用的是最左侧约定。
    • 在 tv_layout 中，从左到右映射线程索引时，线程映射是有意义的。

aider (Paul Gauthier) ▷ #general (33 messages🔥):

Ubuntu 20.04 deprecation, Open weights models lagging in Aider Polyglot, Qwen3 Coder, sglang setup, Claude Code (CC) usage

  • Ubuntu 20.04 随 Python 3.8 一起弃用：成员们讨论了 Ubuntu 20.04 如何被弃用且默认附带 Python 3.8，建议升级到 3.11-3.12，虽然 3.13 已经可用但仍然较新。
  • 权重开放模型（Open Weights Models）在 Aider Polyglot 基准测试中失败：成员们观察到，最近的权重开放模型在大多数基准测试中表现良好，但在 Aider Polyglot 上似乎出现了退步，这可能是由于在合成数据集中对智能体行为（agentic behavior）进行了过度优化。
  • Qwen3 Coder 发布引发关注：在有人提到需要完成 sglang 的设置并尝试之后，Qwen3 Coder 及其 博客文章 引起了广泛关注。
    • 他们还提到 sglang 看起来可以使用 Claude Code。
  • Textualize 启发新的 Aider 前端：受 Textualize 的启发，成员们正在考虑使用它原型化一个实验性的 Aider 前端，并认可了它在思考流（thinking streaming）中的应用。
  • Claude Code 需要代理：对于使用 Claude Code，有人提到可能需要代理或 CC fork，并建议研究 Claude Code Router 以便通过 OpenRouter 使用（由于地理限制问题）。
    • OpenCode 中还有其他替代选项可以绕过这些问题。

aider (Paul Gauthier) ▷ #questions-and-tips (15 messages🔥):

Aider file patching method, Gemini 2.5 Pro issues, Gemini Pro free tier, Aider system prompt

  • Aider 要求模型输出补丁内容：一位成员质疑为什么 Aider 要求模型输出要打补丁的旧文件内容，而不仅仅是补丁位置。
    • 他们建议，如果模型只需要输出在哪里打补丁（类似于使用 ed 行编辑器），将可以节省成本。
  • Gemini 2.5 Pro 频繁断连：一位用户报告了 Gemini 2.5 Pro 持续出现 litellm.APIConnectionError：服务器断开连接且未发送响应，尽管处于速率限制以下并设置了较长的超时时间。
    • 该问题似乎在发送稍大数量的 Token 时发生，且重试无法解决。
  • Gemini Pro 免费层级使用回归：一位用户询问如何在 Aider 中免费使用 Gemini Pro，并指出 aider --model gemini-2.5-pro 可以工作，但 aider --model gemini-exp 不行，会抛出 NotFoundError。
    • 一位成员指出 Google 重新推出了免费 API，建议从 Google AI Studio 获取密钥和基础 URL，并避免使用启用了计费的项目。
  • Aider 系统提示词（System Prompt）自定义：一位成员询问如何为 Aider AI 指定系统提示词。
    • 另一位用户回答说它在代码中，建议 fork Aider 并进行更新。

Notebook LM ▷ #use-cases (19 条消息🔥):

NotebookLM 与其他 LLM 的心理学差异, NotebookLM PRO 设置, Deepseek API 对比 NotebookLM, 使用 NotebookLM 的知识架构, Source ID

  • NotebookLM 的心理学分析：以源为中心：一位用户发现，在撰写心理学相关内容时，NotebookLM 极度依赖源引用，这与其他 LLM 不同。
    • 另一位用户解释说，NotebookLM 的设计初衷是紧贴源内容，需要特定的 Prompt 才能访问其训练数据以获取新颖信息。他演示了一种通过引用 Horace Greeley 的名言 “Go West, Young Man!” 来引导 NotebookLM 使用外部知识的方法。
  • NotebookLM Pro 的桌面端聊天设置：一名成员分享了 NotebookLM 桌面版聊天设置界面的截图，但另一名成员指出这可能是一个 PRO 功能。
    • 附带的截图显示了各种聊天设置，但一位用户表示该设置在非 Pro 版本中不可用。
  • Deepseek API 比 NotebookLM 更受青睐：一位成员更倾向于使用 Deepseek API 配合 Chatbox AI，因为其对话流更自然、内容导出方便且成本低廉（每月低于 2 美元）。
    • 他们提到 NotebookLM 有时会挖掘出陈旧、无关的理论，而 Deepseek 则能实现话题的持续上下文演进。
  • 关于 Source ID 和笔记本发布的疑问：一名成员询问当一个源被添加到多个笔记本时，Source ID 是否会不同，以及这是否会影响笔记本的发布。
    • 该成员表示可以接受在不同笔记本中源具有不同的 ID，但并未表达发布笔记本的意愿。

Notebook LM ▷ #general (24 条消息🔥):

播客长度问题, 聊天记录保存问题, 笔记本共享问题, 自定义音频概览问题, PDF 上传问题

  • 播客长度失控：用户报告称，默认生成的播客时长达到了 50 分钟，而非通常的 15 分钟。
    • 一位用户推测这可能是一个 Bug。
  • Cookie 导致聊天记录丢失：用户注意到 NotebookLM 中的聊天记录未被保存。
    • 一位用户建议删除 Cookie 作为潜在的修复方法。
  • 笔记本共享显示服务不可用：一位用户报告在尝试与朋友共享笔记本时出现 “Service unavailable”（服务不可用）错误。
    • 朋友可以使用 NotebookLM，但无法访问共享的笔记本。
  • 音频概览自定义功能缩减：用户发现缺失了自定义音频概览功能，特别是 “Shorter”（较短）、”Default”（默认）和 “Longer”（较长） 选项。
    • 这些选项以前位于 “Audio Overview” 部分的 “Customize” 按钮下，但现在不再出现。这似乎是 Android Play Store 版本的问题，但在桌面版网站上仍然存在。
  • PDF 上传遭遇故障：一位用户报告在尝试向 NotebookLM PRO 账户上传 PDF 源时出错。
    • 通过 Imgur 分享了错误截图，Google Oliver 要求该用户将可公开访问的 PDF 文件通过 DM 发送给他。

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

Windows Support for Mojo, PowerPC resurrection, Mojo compiler status, GPU programming focus

  • Mojo 的 Windows 支持：尚不在计划内 😔：一名团队成员确认，Windows 支持 不在当前的 roadmap 中，因为团队正专注于为生产级企业环境提供最佳的 GPU 编程体验，而这些环境大多基于 Linux。
    • 他们补充说，Windows 支持是他们未来想要实现的目标，但目前 没有 Windows 版本发布的时间表。
  • PowerPC 依然长盛不衰？ 🧟：成员们讨论了 PowerPC 系统令人惊讶的生命力，这主要受到 IBM 最近推出的新系统 的推动，该系统拥有高达 2048 线程 和 16 TB 内存。
    • 尽管 Apple 已经弃用，但 PowerPC 依然深植于许多公司中，特别是用于运行具有良好运行时间的单节点数据库；GameCube、Wii、Wii U、PS3 和 Xbox 360 等游戏机也使用了 PPC。
  • Mojo 编译器移植到 Windows 指日可待 🛠️：尽管缺乏具体的 roadmap，社区成员推测，Mojo 编译器 在开源后的几个月内可能会被移植到 Windows。
    • 虽然目前存在 Windows 分支，但许多分支都会导致 “this doesn’t work” 错误，需要集中精力解决，因为 Windows 要求某些事物的运作方式非常不同。
  • Linux 下的 GPU 编程 🐧：Mojo 编译器团队优先考虑生产级企业环境的 GPU 编程，这些环境主要是 Linux（以及其他基于 POSIX/UNIX 的系统）。
    • 因此，遗憾的是他们没有 Windows 版本的发布时间表；一位用户建议，在 WSL 下进行原型开发工作效果相当不错。

Modular (Mojo 🔥) ▷ #max (14 messages🔥):

Max vs llama.cpp, vLLM vs Max Benchmarking, KV Cache Preemption, Device Memory Utilization, Prefix Cache

  • Max vs llama.cpp CPU 性能：一位成员询问了关于 Max 和 llama.cpp 在 CPU 推理服务性能方面的基准对比。
    • 在给定的消息中没有提供具体的基准测试数据。
  • A100 上的 vLLM vs Max 基准测试：一位成员在 NVIDIA A100 (40GB) 上使用 Modular 基准测试工具对比了 vLLM 0.9.1 和 Max 25.4，观察到在 sonnet-decode-heavy 数据集下，vLLM 达到了 13.17 requests/sec，而 Max 为 11.92 requests/sec。
    • 测试使用了 unsloth/Meta-Llama-3.1-8B-Instruct 模型并启用了 prefix-caching。
  • KV Cache 抢占影响 Max 性能：基准测试结果显示，由于 VRAM 不足，Max 遭遇了 KV cache 抢占，正如日志消息所示：Preempted a request due to lack of KV pages.
    • KV Cache 分配了约 20GB，权重占用了 14.96 GiB。
  • 优化设备内存利用率和 Batch Size：一位成员建议增加 --device-memory-utilization（例如设为 0.95）和/或减小 --max-batch-size 以缓解 KV cache 抢占，并指出算术强度与抢占之间可能存在权衡。
    • 这些设置可能解释了 Max 和 vLLM 之间观察到的性能差异。
  • Prefix Cache 默认禁用？：一位成员询问是否有原因导致 Max 25.4 默认禁用 prefix cache。
    • 在给定的消息中没有提供原因。

MCP (Glama) ▷ #general (24 条消息🔥):

Agent 技术栈, 会话管理, MCP 安全解决方案, 不成熟的 SDK, Claude 桌面环境变量

  • Agent 技术栈解析：一名成员请求对 Agent 技术栈进行从底层到顶层的粗略描述，建议顺序如下：Data, LLM, Frameworks, Tools/APIs, 以及 Integrations (MCP, Auth 平台)。
    • 该请求者寻求关于技术栈层级（从数据到集成）的清晰说明，以帮助他人制定安全解决方案。
  • 会话管理寻求者：一名成员询问有关 MCP 会话管理 的频道、线程或讨论线索。
    • 另一位用户建议使用搜索功能或发起新的讨论。
  • MCP 安全解决方案揭晓：一名致力于 MCP 安全解决方案 的成员加入讨论，以了解实际使用情况和问题。
    • 最大的问题是 MCP 不成熟且不稳定的 SDK，这导致用户在没有任何防护措施（guardrails）的情况下将整个 API 暴露给外界。
  • Claude 的秘密环境：一名成员询问 Claude 桌面版是否在特殊环境中运行 MCP server，因为遇到了环境变量/访问权限问题。
    • 尽管它不在 shell 中运行，而是作为子进程（subprocess）运行，但它仍然可以毫无问题地与 MCP Inspector 交互。
  • API 在无安全保障的情况下开放：一名成员抱怨用户在没有任何防护措施的情况下将整个 API 暴露给外界，并且 AI Agent 在太多时候做出具有巨大后果的糟糕决策。
    • 一位用户表示，增加安全检查或限制可以防止 AI Agent 失控。

MCP (Glama) ▷ #showcase (3 条消息):

初创公司的数据和 MLE 基础设施, 使用 MCP 的 AI Agent, Scalekit.com, 安全的 MCP server, 为 MCP server 添加 OAuth 2.1

  • AI Agent 书籍发布公告：一名成员宣布了他们即将出版的新书 AI Agents with MCP (O’Reilly)，并提供了一个关于该书演讲的 YouTube 链接。
    • 该成员 Ravi 是 Scalekit.com 的联合创始人。
  • 深入探索 MCP Server：Scalekit.com 团队几周前在 MCP Dev Summit 直播中进行了一个简短的演示，讨论了安全的 MCP server，并展示了如何在不破坏现有认证设置的情况下为 MCP server 添加 OAuth 2.1。
    • 由于反响热烈，特别是针对实现层面的内容，他们将再次举办活动，并分享了报名链接。
  • Augments 让 Claude Code 保持最新：一名成员宣布发布 Augments，这是一个 MCP server，可让 Claude Code 与框架文档保持同步，消除过时的 React 模式或弃用的 API。
    • Augments 提供对 90 多个框架的实时访问，是开源的，并可在 augments.dev 进行试用。

LlamaIndex ▷ #blog (4 条消息):

OCR 替代方案, 使用 LlamaIndex 进行多模态报告生成, Notebook Llama 文档管理, LlamaIndex Workflows 状态管理

  • 自动化 PDF 解析和提取：LlamaIndex 提议使用 LLM 自动化 PDF 解析和提取，超越 OCR 限制以实现智能文档理解，如此链接所述转换 PDF。
  • 构建多模态报告生成 Agent：@tuanacelik 的视频演示展示了如何创建一个智能 Agent，通过解析复杂的 PDF（如研究论文）并提取此链接中发现的数据来生成综合报告。
  • Notebook Llama 的新文档管理 UI：LlamaIndex 响应社区请求，为 Notebook Llama 推出了功能完备的文档管理 UI，将所有处理过的文档整合在一处，演示见此链接。
  • LlamaIndex Workflows 类型化状态支持：LlamaIndex workflows 获得了重大升级，支持类型化状态（typed state），增强了 workflow 步骤之间的数据流管理和开发者体验，如此链接所示。

LlamaIndex ▷ #general (6 messages):

Notmuch 集成，LlamaReport 替代方案

  • 寻求 Notmuch 集成：一位成员正在寻求与 notmuch 邮件搜索和标记程序的集成，或者 Maildir 集成。
    • 他们正在询问有关如何自行编写此类集成的文档，并咨询该集成应该是 query engine、reader 还是 indexer。
  • LlamaReport 的开源状态：一位成员询问 LlamaReport 是否有开源等效版本，并引用了这个 GitHub 链接。
    • 另一位成员回答说 LlamaReport 没有开源版本，但链接的仓库中包含报告生成示例，并特别指向了这个示例。

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

AI Foundation School 应用，Manus 计算机位置，初创公司应用开发

  • AI Foundation School 应用寻求测试者：一位成员创建了一个 AI Foundation School 应用，其中包含关于 47 种 AI 工具的信息和指导，涵盖图像、音频和视频生成、邮件撰写、演示文稿构建、自动化、chatbase、LLMs 等。
    • 创建者正在寻求 14 名志愿者用户在接下来的 14 天内测试该应用，以便在公开发布前发现并解决问题。
  • 初创公司以 100 美元构建应用：一位成员提到他们的初创公司仅以 100 美元的价格构建应用。
    • 他们邀请任何寻求商业应用或网站的人员与他们联系。
  • Manus 计算机的位置被发现：一位成员透露 Manus 计算机的位置位于 23219 Evergreen Mills Road, Brambleton, VA 20146, United States of America。
    • 另一位成员对通过 Google 就能轻松找到服务器位置表示担忧。

DSPy ▷ #show-and-tell (4 messages):

DSPy 演示，DSPy 模块

  • 本地 Python 用户组获得 DSPy 演示：一位成员分享了一个 YouTube 链接，内容是为本地 Python 用户组进行的关于 DSPy 的演示。
    • 另一位成员热情回应，认出演示者来自 “Pyowa meetup”。
  • DSPy 中模块取代 Musings：一位成员分享了一个 X 链接，关于用 DSPy 模块取代 LLM musings。
    • 该推文标题为 “DSPy: Replacing LLM Musings with Modules”。

DSPy ▷ #general (2 messages):

dspy.Module 子类

  • dspy.Module 子类是允许的：澄清了允许使用任何 dspy.Module 子类。
    • 该成员强调不允许其他任何内容。
  • 收到确认：另一位成员对这一澄清表示感谢。
    • 他们简单地说了句：Thank you!

DSPy ▷ #examples (2 messages):

DSPy 教程问题，Hugging Face dataset 库更新，数据集脚本问题

  • DSPy 教程受数据集加载 Bug 影响：一位用户报告说，这个 DSPy 教程在加载数据集时失败，错误提示为 RuntimeError: Dataset scripts are no longer supported, but found hover.py。
    • 另一位用户指出，这可能与 Hugging Face 的 dataset 库更新有关。
  • Hugging Face 数据集库更新再次引发问题：Hugging Face Dataset Library 的更新可能是导致 DSPy 教程损坏的原因。
    • 用户应检查 DSPy 和 Hugging Face Datasets 的最新更新和兼容性说明以进行故障排除。

MLOps @Chipro ▷ #events (6 messages):

Data, MLE, and Startups Talk, AI Coding Tools Chat, MCP Builders Summit

  • 数据、MLE、初创公司与 AI Agents 汇聚：一位成员在 YouTube 视频中讨论了 2018 年至 2024 年间在多家初创公司从事 data 和 MLE 的经验，以及一本关于使用 MCP 构建 AI Agents 的书。
    • 这也是对一场关于在多家初创公司从事 data 和 MLE 工作经验分享会的推广。
  • AI 编程聊天会召开：一位成员将于明天 PST 时间上午 9:30 - 10:30 在 Zoom 上主持一场面向社区的关于 AI coding tools 的轻松聊天，点击此处即可注册。
    • 聊天将不会被录制，以鼓励开放式讨论。
  • MCP Builders Summit 聚焦 AI 创新：Featureform 和硅谷银行将于 7 月 30 日星期三下午 5 点至 8 点 为 ML 和 AI Engineers、创始人、产品负责人及投资者举办一场线下 MCP Builders Summit，点击此处报名。
    • 峰会将深入探讨实际构建案例，提供社交机会，并设有创始人展位进行演示。

MLOps @Chipro ▷ #general-ml (2 messages):

Research Faculty Recommendation System, Azure AI Search alternatives, Hybrid Search, Semantic Ranker Replacement, Explainability and Control in Ranking

  • 资助项目 RecSys 寻求教职专业知识：一位成员正在开发一个推荐系统 (RecSys)，通过 LLM 提取的资助描述和主题，将研究型教职人员与资助项目进行匹配。
    • 他们构建了教职人员档案，包括 CVs、研究陈述、来自 Google Scholar 和 Scopus 的出版物以及过往资助记录。
  • Azure AI Search 驱动初始教职索引：该 RecSys 使用带有教职索引的 Azure AI Search 和 hybrid search (text + vector)，并使用 semantic ranker 进行 L2 重排序。
  • 自研重排序器旨在替代 Azure 的 Semantic Ranker：由于 semantic ranker 的黑盒性质，该成员正在探索使用来自 Azure AI Search L1 检索的 BM25 和 RRF 分数的替代 L2 排序方法。
    • 目标是获得更好的排序过程可解释性和控制力，甚至构建一个模型来“模拟”语义重排序器。

Cohere ▷ #🧵-general-thread (2 messages):

Welcome to Cohere

  • 服务器欢迎新人：服务器对对 Cohere 感兴趣的新人表示热烈欢迎。
  • Cohere 简介：Cohere 是一个专注于自然语言处理的 AI 平台。

Cohere ▷ #👋-introduce-yourself (2 messages):

AI product development, LLM products, AI Engineering, New technologies for business

  • 构建 LLM 产品的 AI 工程师：一位来自 Elevancesystems 的 AI 工程师兼 AI 负责人正在构建创新的 AI/LLM 产品。
    • 他们期待分享和探讨面向真实商业世界的新技术和解决方案。
  • 欢迎新成员加入 Cohere 社区：一位新成员向 Cohere 社区介绍了自己，并表达了加入服务器的兴奋之情。
    • 他们渴望与其他成员互动，并参与有关 AI 和语言模型的讨论。

Torchtune ▷ #dev (4 messages):

DCP Saving, FSDP+TP

  • DCP 保存无法工作：一位成员表示他们始终无法让 DCP 在 HF (HuggingFace) 中正常工作。
    • 另一位成员请他们详细说明，并指出自己有一段时间没看 DCP 模型保存了，因为之前遇到了一些问题，默认改用了 full state dicts。
  • 保存优化器状态时出错：一位成员尝试使用 dist_cp.save 在 FSDP+TP 模式下保存优化器状态，但遇到了奇怪的错误。
    • 该成员之前也遇到过一些问题，并默认改用了 full state dicts。

LLM Agents (Berkeley MOOC) ▷ #mooc-questions (3 条消息):

Trailblazer Tier 证书, 证书申报表

  • **Trailblazer Tier 证书问题：一位成员反映，尽管满足了包括提交文章在内的所有要求，但仍未收到 **Trailblazer Tier 证书。
    • 另一位成员回应称，在提供的邮箱下没有收到 证书申报表。
  • **证书缺失？：一名学生提到，在完成 **Trailblazer Tier 要求并提交文章后，未收到证书。
    • 一名工作人员表示歉意，并指出在该学生的邮箱地址下未收到证书申报表。

tinygrad (George Hotz) ▷ #general (2 条消息):

用于 tinyboxes 的集装箱, 模块化冷却优势, tinycontainer

  • 集装箱成为 tinybox 之家：一位成员提议使用 集装箱 来放置 tinyboxes，以实现模块化、冷却和便携性。
    • 这些集装箱可以移动到任何有电源的地方，但该成员对其成本和安全性表示怀疑，并开玩笑地建议命名为 tinycontainer。
  • 冷却与便携性优势：该想法利用集装箱实现潜在的 冷却优势，并在电力可及的任何地方轻松迁移。
    • 针对这种模块化外壳方案的 实际成本效益 和安全性，人们提出了疑虑。

Nomic.ai (GPT4All) ▷ #general (2 条消息):

新成员 Santhos, GPT4All 上的勒索软件攻击

  • Santhos 加入小组：一位名叫 Santhos 的新成员介绍了自己，他是一名来自俄勒冈州立大学的硕士毕业生，热衷于将 AI 与 设计 融合。
    • Santhos 正在寻求 Data Scientist、AI/ML Engineer 或 Software Engineer 的初级职位，对实习或见习岗位持开放态度，并渴望参与项目协作。
  • 关于 GPT4All 遭受勒索软件攻击的疑问：Santhos 询问 是否有人在使用 gpt4all 时被勒索软件攻击过？
    • 没有人回答这个问题，该消息可能脱离了上下文。

Codeium (Windsurf) ▷ #announcements (1 条消息):

Kimi K2, Windsurf, 新模型, 定价

  • Kimi K2 驶入 Windsurf！：Kimi K2 模型现在已在 Windsurf 上得到支持，成本仅为 每次 prompt 0.5 积分。
  • Kimi K2 模型定价：Kimi K2 模型在 Windsurf 上的价格为 每次 prompt 0.5 积分。
    • 这为希望将 Kimi K2 模型集成到项目中的开发者提供了一个具有成本效益的选择。
← 返回首页