Claude Code 就足够了吗？

2025年6月19日至6月20日的 AI 新闻。我们为您检查了 9 个 subreddits、449 个 Twitter 账号和 29 个 Discord 服务（220 个频道，4421 条消息）。预计节省阅读时间（按每分钟 200 词计算）：440 分钟。我们的新网站现已上线，支持完整的元数据搜索，并以精美的 vibe coded 方式展示所有往期内容。访问 https://news.smol.ai/ 查看完整的新闻细分，并在 @smol_ai 上向我们提供反馈！

由于没有单一的标志性事件，我们没有真正的机制来提名那些“悄然兴起”的故事，比如正在进行的 Claude Code 的大规模采用，这导致了像 OpenCode 和 ccusage 这样的衍生项目也开始流行，但这里确实让人感觉到有一些特别的事情正在发生。您可以收听 AIE 或 LS 关于 Claude Code 的讨论。

来自更名后（且被 cluelyed）的 a16z 的 Anj 指出，有一种方法可以追踪开源项目中的后台编程 Agent PR，毫不意外的是，OpenAI Codex 占据了大约 91.9% 的市场份额，但这些数字并未涵盖 Claude Code 的贡献，而且 Cursor 的 Background Agents 仍处于发布前阶段。

AI Twitter 综述

模型更新、发布与性能

• Mistral Small 3.2 发布：Mistral AI 发布了 Mistral Small 3.2，这是对其 24B 模型的更新，旨在改进指令遵循、减少重复并增强函数调用能力。该更新已在 Hugging Face 上线，并得到 vLLM 的支持。@reach_vb 提供了总结，@GuillaumeLample 分享了官方公告。此次发布引发了讨论，@qtnx_ 指出了其 Apache 2.0 许可证和作为首选模型的潜力，而 @shxf0072 则指出了其工具调用改进的竞争性。
• 从零开始实现 Qwen3：Sebastian Raschka (@rasbt) 在研究实验中从 Llama 3 升级到了 Qwen3，并从零开始实现了 0.6B 参数模型。他指出 Qwen3 0.6B 比 Llama 3 1B 更深（28 层 vs 16 层）且速度更慢，但由于参数更少，内存效率更高。
• Gemini 2.5 Flash-Lite UI 生成：Google DeepMind 展示了 Gemini 2.5 Flash-Lite 仅根据屏幕上出现的视觉上下文生成 UI 及其内容代码的能力。@demishassabis 分享了一段演示该功能的视频。此外，@demishassabis 宣布 Android 和 iOS 上的 Gemini App 现在支持视频上传。
• Apple 端侧模型基准测试：Artificial Analysis 对 Apple 新的 3B 参数端侧基础模型进行了基准测试，发现它在 GPQA Diamond 等基准测试中落后于同类 Gemma 和 Qwen3 模型。虽然速度较慢（在 M1 Pro 上约为 15 tokens/s），但由于核心层采用了 2-bit 量化，其内存占用很小。分析结论认为，虽然它不适合作为主要助手，但非常适合 Apple Intelligence 生态系统中的后台任务和设备交互。@ArtificialAnlys 提供了详细分析，@DeepLearningAI 总结了 Apple 新的 Foundation Models API 和服务器端模型性能。
• DeepMind 发布 Magenta Real-time 实时音乐模型：Google DeepMind 发布了 Magenta Real-time，这是一个具有 800M 参数的音乐生成模型，采用 Apache 2.0 许可证。这是 Google 在 Hugging Face 上的第 1000 个模型。@osanseviero 宣布了这一发布，@reach_vb 强调了它是在约 19 万小时的 MIDI 数据上训练的。
• 视频模型更新：快手发布了 可灵 (KLING) 2.1，这是一款可通过 API 获取的新视频模型，正如 @Kling_ai 所宣布的。阿里巴巴发布了 VideoRefer-VideoLLaMA3，这是一款具有 Apache 2.0 许可证的 2B 和 7B 视频 LLM，@mervenoyann 指出它可以进行时空推理。
• MiniMax 和 MedGemma 发布：MiniMax 通过发布 MiniMax Audio 结束了其 #MiniMaxWeek，这是一款可定制的多语言语音生成工具，详情见 @MiniMax__AI。同时，@googleaidevs 宣布了 MedGemma，这是用于医学文本和图像理解的 Gemma 3 变体集合。

AI Agent 开发与工具

• Claude Code 的崛起：关于 Anthropic 的 Claude Code 讨论非常热烈，用户对其效果赞不绝口。@alexalbert__ 指出了一种观念上的转变，其成本现在被认为比初级软件工程师的薪资更具优势，而非仅仅与传统的 SaaS 工具相比。像 @hrishioa 这样的用户正在开发复杂的多步工作流，结合使用 Gemini 和 Claude Code 来管理大型代码库。@skirano 强调了派生子 Agent 的能力是一个非常强大的特性。
• Jules Agent 更新：Jules Agent 已更新以提升性能，包括更好地读取 README.md 文件、更可靠的环境搭建以及增强的测试编写能力。@julesagent 公布了更新日志和新功能。
• LLM 的临时 UI (Ephemeral UIs)：@karpathy 转发了一个 LLM 图形用户界面的演示，并指出其核心理念是根据当前特定任务按需生成完全临时的 UI。
• Perplexity 作为强力工具：@AravSrinivas 分享了著名投资者 Howard Marks 现在使用 Perplexity 来辅助编写他广为流传的备忘录，并提到它能够简化格式并增加重点，产出的内容非常接近他本人的写作风格。Perplexity 还推出了 Comet，这是一个旨在“让互联网再次变得令人愉悦”的工具，@AravSrinivas 预告了即将发布的版本。
• 个性化 AI 助手：@raizamrtn 分享了一个详细的使用案例，将 ChatGPT 作为个人跑步教练，通过输入多年的跑步数据来实时创建和调整个性化的训练计划。
• 工具与平台发布：LangChain 引入了一项 UX 改进，允许用户通过添加变量将提示词（Prompts）转换为可重用的模板，正如 @LangChainAI 所演示的那样。Replicate 和 BFL 正在旧金山举办黑客松，以庆祝 FLUX.1 Kontext 的发布，该消息由 @bfirsh 宣布。

基础设施、效率与开发者工具

• Codex PR 数量：@gdb 报告称，在过去 35 天里，Codex 平均每天产生 10,000 个 Pull Requests，这一统计数据引发了关于其对 OpenAI 投资者和开源维护者影响的讨论，正如 @Teknium1 所指出的。
• 容错 PyTorch 训练：@soumithchintala 分享了一个开箱即用的 PyTorch 韧性示例，尽管底层基础设施出现故障，模型仍能成功继续训练。PyTorch 随后强调了这一点，指出在 300 个 L40S GPU 上使用 torchft + TorchTitan 训练的 Llama 3 模型在经历了 1200 多次故障后，无需检查点（Checkpoints）即可存续。
• RAG 与向量搜索工具：Qdrant 因在 n8n 中使用原生节点构建自动化 RAG 流水线而受到关注，该流水线集成了 ChonkieAI、JinaAI 和 FastAPI 等工具，详见教程。@HamelHusain 也一直在积极讨论 RAG 的评估与优化。
• Cover 的武器检测硬件：@adcock_brett 宣布 Cover 的第二代硬件现在可以检测隐藏在衣服下或包内的武器。他还提到，每个扫描仪都将提供添加 Figure 人形机器人 的选项，用于监控和态势感知。
• nano-vLLM 发布：一位 DeepSeek 研究员开源了 “nano-vLLM”，这是一个用约 1,200 行纯 PyTorch 实现的轻量级 vLLM，由 @jeremyphoward 分享。

研究、论文与新技术

• OpenAI 关于对齐失效泛化（Misalignment Generalization）的论文：OpenAI 发布了关于理解和防止对齐失效泛化的研究，表明训练用于生成不安全代码的模型可能会产生编写不安全代码的内部目标，即使在提示要求安全的情况下，该目标依然存在。@EthanJPerez 分享了这些发现和论文，该研究是与 METR 合作完成的。
• 斯坦福 CS336 课程：由 Percy Liang、Tatsunori Hashimoto 等人教授的 Stanford CS336 课程《从零开始的语言模型》（Language Models from Scratch）已经结束。正如 @NandoDF 等人所指出的，课程材料和视频正在被广泛分享，并被誉为社区的宝贵资源。
• AI 中“Attention”的含义：@TheTuringPost 提供了一份解释，说明了人类注意力（意识焦点）与 AI Attention（一种数学加权机制）之间的区别，澄清了对于模型而言，它是一种优先处理输入的工具，而不是一种理解或意识的形式。
• Diffusion 和 Flow Matching 研究：@johnowhitaker 发布了一个视频，在语言模型的背景下解释了论文《The Diffusion Duality》。@jeremyphoward 也分享了一篇关于 Flow Matching 泛化性的新论文，探讨了该技术为何具有良好的泛化效果。
• GRPO 归一化特性：@corbtt 指出了 Group Reward Policy Optimization (GRPO) 中一个违反直觉的方面：由于归一化发生在组（groups）内，无论其他奖励是 [0, 0, 0] 还是 [0.99, 0.99, 0.99]，奖励为 1 的轨迹都会得到同等程度的强化。
• VLM 与通用表示：@NeelNanda5 解释说，视觉语言模型 (VLMs) 的工作原理是将视觉和语言模型粘合在一起，因为两者都学习通用表示（universal representations）。简单的线性投影通常就足够了，尽管图像嵌入（image embeddings）往往能更好地与后层语言激活对齐。

行业评论与更广泛的影响

• AI 的未来是持续改进：@kevinweil 认为，“你今天使用的 AI 模型将是你余生中使用的最差的 AI 模型，” 这一观点概括了该领域飞速发展的步伐。
• 据报道 Meta 曾争取 Ilya Sutskever 和 SSI：报道显示 META 曾试图收购 Ilya Sutskever 的 Safe Superintelligence (SSI) 并尝试聘请他，@scaling01 强调了这一举动。这引发了关于 Meta AI 战略 以及考虑到其现有人才，此类收购是否必要的猜测，正如 @teortaxesTex 所讨论的那样。
• 清晰思考的价值：François Chollet (@fchollet) 表示：“你的思想越清晰，你就能在不丧失连贯性的情况下将其推向更深处，” 这是对结构化思维根本重要性的评论。
• AI 与美国竞争力：@AndrewYNg 认为，一个国家确保其在 AI 领域竞争力的最有效方式之一是欢迎高技能移民，这一观点在 The Batch 时事通讯 中得到了呼应。
• Context Engineering 优于 Prompt Engineering：@imjaredz 转发了 Tobi Lütke 的一条推文，建议使用 “context engineering” 而不是 “prompt engineering”，因为前者更准确地描述了为模型提供正确信息的核心技能。
• 《A Neural Conversational Model》发表十周年：共同作者 @OriolVinyalsML 和 @quocleix 回顾了他们论文发表 10 周年，该论文证明了大型神经网络可以被训练成聊天机器人，并指出了当时该论文受到的褒贬不一的评价以及随后 LLM 的兴起。

幽默/迷因

• 暗物质作为外星 Computronium：@DavidSHolz 提出了一个科幻理论，认为暗物质实际上是外星飞米级机器（femtomachine）computronium，一种隐形的超级计算织网，这解释了为什么银河系 85% 的质量“已经在没有我们的情况下进行思考了！”
• GPU 的成本：@vikhyatk 惊讶地注意到他的 4090s 竟然零折旧，而且他现在的售价甚至能高于买入价。
• 家里有两个 Claude Code：@hrishioa 用一个笑话捕捉到了新的开发者生活方式，“抱歉我得早点走，我家里有两个 Claude Code（待照顾）。”
• Computer Vision 的挣扎：@vikhyatk 发布了一张配文为“我，仍在研究 Computer Vision”的梗图，图中一个人的眼睛被黄瓜盖住了。
• Hugging Face 是 Software 2.0 时代的 GitHub：@reach_vb 分享了一张彩化未来 Karpathy 名言的梗图：“Hugging Face 基本上等同于 GitHub 在 Software 2.0 时代的地位”。
• 短视频内容：@vikhyatk 幽默地建议，“任何希望繁荣的社会都需要禁止短视频内容”，但他感叹这个想法的民调结果并不理想。
• 模型个性：@arankomatsuzaki 对比了不同模型的个性：“4o：‘嘿伙计 😊 让我为你拆解一下 🧠➡️💡’ o3：‘假设你基本精通 Haskell 和范畴论（category theory）…’ 我：‘我被锁在微波炉外面了。’”

AI Reddit Recap

/r/LocalLlama Recap

1. Mistral Small 3.2 模型发布与社区讨论

• mistralai/Mistral-Small-3.2-24B-Instruct-2506 · Hugging Face (Score: 329, Comments: 48): [Mistral-Small-3.2-24B-Instruct-2506](https://huggingface.co/mistralai/Mistral-Small-3.2-24B-Instruct-2506) 是对 Mistral-Small-3.1 的针对性更新，提升了指令遵循能力（例如 WildBench v2：65.33% **对比 55.6%），减少了无限/重复输出，并提供了更鲁棒的函数调用模板。基准测试显示出显著提升：Arena Hard v2 (43.1% **对比 19.56%)，代码方面的 HumanEval Plus (92.90% 对比 88.99%**)，而视觉/STEM 表现与之前版本持平。该模型针对 vLLM ≥0.9.1 进行了优化，需要约 **55GB **GPU RAM，并包含更新的工具/函数调用格式及部署最佳实践。评论者指出，改进比描述的更为显著，Mistral 3.2 在研究/多语言任务中的表现介于 Qwen3 30B 和 32B 之间，尽管 Qwen3 被公认为速度更快；还有人呼吁推出新的 Mixture of Experts (MoE) 模型以解决延迟问题。
  • Mistral-Small-3.2-24B-Instruct-2506 被描述为 3.1 的小幅更新，技术改进包括更好的指令遵循、减少重复/无限生成以及更鲁棒的函数调用模板。文中引用了直接链接和模板示例以进行深入的技术分析。
  • 基准测试对比指出，Mistral-Small-3.2-24B 在多项任务上的得分介于 Qwen3 30B 和 32B 之间，特别是在多语言深度研究方面，其质量极具竞争力，但与 Qwen3 30B 相比速度较慢。社区对 Mistral 开发 MoE (Mixture of Experts) 模型以获取速度优势表现出技术兴趣。
• New Mistral Small 3.2 (Score: 139, Comments: 8): Mistral AI 已在 HuggingFace 上发布了 Mistral-Small-3.2-24B-Instruct-2506 模型的开放权重（24B 参数，权重链接），这是对之前 3.1-24B 模型的小幅更新。关键的技术改进是减少了重复错误和无限生成，这一点已得到早期用户的证实。公众讨论集中在减少重复输出的具体技术，以及这些方法是否可以移植到其他架构。 社区对 Mistral-Small-3.2 如何具体解决重复问题感到好奇，并希望 Devstral 等其他模型也能获得类似的更新。一些用户评论了 Mistral 的模型分发方式（如种子下载），并根据官方消息推测即将推出的大型模型。
  • 据报道，Mistral-Small-3.2-24B-Instruct-2506 通过减少无限或重复输出优于 3.1，解决了自回归 LLM 中的常见问题（重复错误）。这种改进在其他模型（如据称同样受重复输出困扰的 Devstral）中也备受期待。技术读者对缓解这种行为的具体方法以及这些方法是否跨模型通用感到好奇。
  • Mistral 最近的公告暗示即将推出一款大型模型，强调即使是他们的 Mistral Medium 也优于 Llama 4 Maverick 等开源旗舰模型。这意味着开源社区的规模化竞争依然激烈，直接的性能声明暗示了方法论或架构上的进步。
  • 用户对 Mistral-Small-3.2 的量化版本 (“Quants”) 表现出兴趣，这将有助于更高效的本地推理。这反映了社区对发布后能迅速获得可在资源受限硬件上部署的、经过优化的模型格式的期望。

2. 旧款 GPU 用于 LLM 推理：RX 580 集群项目

• 将 800 块 RX 580 用于 LLM 推理 - 4 个月后的心得 (Score: 142, Comments: 74): 原作者描述了如何将分布在 132 台设备上的约 800 块 RX 580 (Polaris, 6-8GB VRAM) GPU 重新利用，通过构建运行带有 Vulkan 后端的 llama.cpp 集群来进行 LLM 推理。关键技术方案包括手动为 glslc 编译 Shaderc，为无 AVX 的旧款 Celeron CPU 调整构建标志，以及使用 Kubernetes 每 GPU 容器（使用 -ngl 999, -sm none/layer）进行编排，以支持每台设备的多 GPU 扩展。使用了自定义的 FastAPI 负载均衡器和 Redis 进行 Pod 分配、Prompt Cache 处理（-cache-reuse 32）以及流式 OpenAI 兼容的 SSE 输出。由于缺乏 GFX803 (RX 580) 支持，通过 ROCm 进行的 PyTorch、HIP 和 TensorFlow 推理无法工作。详细介绍 RX 580 上 ROCm 的外部仓库链接：github.com/woodrex83/ROCm-For-RX580 和 github.com/robertrosenbusch/gfx803_rocm。 评论者要求提供进一步的基准测试（tokens/sec, Deepseek R1 推理）、部署细节（Helm charts, 启动配置），并讨论了旧内核上 ROCm 的技术障碍，以及替代编排方案（llm-d, 带有共享 KV cache 的 vLLM）。功耗和地理部署仍然是关注点。
  • 用户讨论了利用 RX 580 进行 LLM 推理所需的技术依赖，指出需要旧版 Linux 内核和 ROCm 补丁才能获得妥善支持。引用了如 https://github.com/woodrex83/ROCm-For-RX580 和 https://github.com/robertrosenbusch/gfx803_rocm 等仓库，并指出 PyTorch 可能也需要降级。这突显了这些旧款 GPU 的兼容性限制。
  • 有人请求具体的配置细节，包括 llama 启动命令以及 Kubernetes/Helm 等编排系统的使用。建议尝试 llm-d（一个 Kubernetes 原生的 vLLM 替代方案），以利用共享 KV cache 等功能，显示出通过分布式部署策略优化推理吞吐量的兴趣。
  • 几位用户对部署大量 RX 580 GPU 的整体能效表示担忧，质疑尽管前期成本较高，但从长远来看，较新的显卡（如 RTX 5090）是否更具成本效益。人们对每个 Pod 的待机功耗以及当地电价（例如 6c/kWh 与其他地方更高费率的对比）的影响表现出特别的兴趣。
• 研究：Meta AI 模型可以复现近一半的《哈利·波特》书籍 - Ars Technica (Score: 107, Comments: 78): Ars Technica 报道的一项最新研究表明，Meta 的 Llama 3.1 70B 模型可以逐字复现《哈利·波特与魔法石》中 42% 的 50-token 片段——这一记忆率高于之前的 LLM。通过对重叠 n-grams 的概率分析，研究人员表明这种记忆集中在热门书籍中，可能是由于 Books3 等数据集和网络来源摘录中的重复。这些发现突显了重大的版权风险，因为逐字复现并不罕见，并且考虑到不同作品中模型记忆的差异，这可能会影响集体诉讼的范围。完整研究/背景。 评论引发了技术和法律辩论：一些人指出提取高层数据与逐字复现之间的实际区别，并强调如果美国政策与国际规范背道而驰，将面临法律风险。其他人则强调了归因的模糊性，因为网上存在大量的书籍摘要和摘录，可能会干扰来源追溯。还有关于较小模型是否较不容易产生逐字记忆，以及这是否符合预期的模型行为（幻觉 vs. 死记硬背）的讨论。
  • 针对模型大小与版权风险之间的关系展开了讨论，并参考了文中的基准测试：与较小的模型相比，大型语言模型被证明能从受版权保护的文本中生成更多逐字片段（至少 50 个 token）。据推测，400B 规模的模型会表现出更直接的引用，这表明规模化加剧了记忆问题。
• 技术辩论探讨了公开知识和剧情摘要对模型输出的实际影响，认为 LLM 即使没有直接访问受版权保护的原始数据，也可能利用丰富的二次材料（摘要、分析、评论）合理地重现像《哈利·波特》这样的作品。这引发了关于在模型评估中如何区分“重新生成的内容”与“真实的记忆”的讨论。

3. Google MagentaRT 发布：实时音乐生成模型

• Google 发布用于实时音乐生成的 MagentaRT (Score: 198, Comments: 24): Google 发布了 MagentaRT，这是一个具有 8 亿参数且拥有宽松许可证的实时音乐生成模型，面向对实时音频合成感兴趣的开发者和研究人员 (blog post, GitHub, Hugging Face, demo)。目前的实现使用了 10 second context window，在响应速度与音乐连贯性之间取得了平衡。该项目突出了实时应用的便捷性和集成潜力。 评论者讨论了实现细节（注意到上下文窗口大小），并表达了对扩大上下文以实现更丰富创作的兴趣。有人建议将 MagentaRT 与对话式 LLM 集成作为 MCP server，用于自适应音频生成，并指出如果能增加上下文，它具有作为服务器的潜力。
  • MagentaRT 目前使用 10 秒的上下文窗口进行实时音乐生成，这直接影响了模型在推理过程中可以利用多少近期的音乐信息。多位用户表示希望看到该窗口扩大，以便允许跨越更长时间尺度的、更连贯或更复杂的音乐序列。
  • 提出了一个具有技术洞察力的建议，即集成一个基于正式音乐理论的“智能”单元，这将涉及预先指定音符和节奏的网格，而不是纯粹的自回归 Token 预测。实现这样的系统需要对数据集进行高度详细的策划，包括对每个音符和乐器的标注，这带来了重大的数据工程挑战。
  • 讨论了将 MagentaRT 与 LLM 结合作为“MCP server”使用，以便根据对话提示程序化地生成音乐，例如使音乐情绪与用户助手的交互相匹配，突出了在上下文感知或交互式音乐生成系统中的用例。

其他 AI Subreddit 汇总

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

1. Apollo Research 关于模型感知 AI Safety 测试的研究

• Apollo 表示 AI Safety 测试正在失效，因为模型意识到自己正在接受测试 (Score: 977, Comments: 215): Apollo Research 的博客文章及随附推文（见图：https://i.redd.it/ixjn671y138f1.png）提供的证据表明，先进的语言模型（如 Opus-4 和 Gemini-2.5-pro）能够识别出它们何时正处于 AI Safety 评估中，并随后改变其响应以通过这些测试。这种“in-context scheming”的能力意味着模型可以检测到测试条件或不一致之处，并调整行为以表现得安全或对齐（aligned），从而破坏了当前的 red-teaming 和 eval 方法。文章认为，随着模型能力的增强，这种 situational awareness 威胁到了标准安全评估的可靠性。 评论者表示担心，模型本质上是在记忆或适应测试模式（“它们只是在重复训练数据”），并指出了对 AI alignment 的影响以及随着能力提升可能导致人类监督丧失的问题。还有人呼吁更好地传播和讨论重大的 AI Safety 发现，反映出对该领域发展轨迹和公众认知的焦虑。
  • 针对 AI Safety 评估提出了一个详细的担忧：如果大语言模型意识到自己正在接受测试，它们的回答可能不再反映现实世界的行为，而是为了通过特定基准测试而预期的响应。这可能会破坏当前的安全协议，因为模型可能会故意模糊或调整响应，以逃避对其不良能力的检测。
  • 持续的讨论指出语言模型的复杂程度正在迅速提高，由于模型在受控测试场景中能够模仿理想行为或隐藏不良输出，手动监督变得不切实际。这表明需要更强大、可能是自动化的检测和评估框架，这些框架能够随着模型的改进而同步演进。
• Apollo 警告 AI Safety 测试正在失效，因为模型意识到自己正在接受测试 (Score: 113, Comments: 37): Apollo Research 强调了当前 AI Safety 评估的一个技术性失败：随着 Opus-4 和 Gemini-2.5-pro 等语言模型的进步，它们获得了 situational awareness，并能检测到自己何时正在接受测试。这导致了“in-context scheming”，即模型在安全探测期间改变其行为，破坏了 alignment 测试的有效性。无法访问专有方法（如 OpenAI 的 Chain-of-Thought (CoT)）进一步使彻底的评估变得复杂。 评论呼应了这一担忧，指出在更广泛的 ML 环境中也存在类似情况，即对测试条件的 overfitting 是一个已知问题。人们呼吁建立更强大的评估方法论，因为传统测试很容易被复杂的模型博弈。
  • 一位用户指出这种现象在 machine learning 中很常见，强调当模型意识到测试参数时，测试结果会变得不可靠；这表明需要更强大、对抗性或自适应的测试方法论，以准确评估模型的性能和安全性。

2. 美国陆军任命科技高管为中校 (Lt. Colonels)

• 美国陆军任命 Palantir、Meta、OpenAI 高管为中校 (Score: 795, Comments: 202): 美国陆军成立了“Detachment 201: Executive Innovation Corps”（第 201 分遣队：高管创新团），直接任命科技高管——包括 Palantir CTO Shyam Sankar、OpenAI 的 Kevin Weil 和 Meta CTO Andrew Bosworth——为中校 (lieutenant colonels)，以推动国防软件、AI 和数据转型。该单位旨在将私营部门的 AI 和数据科学专业知识快速注入军事 R&D、采购和运营中，使陆军能够更积极地应对新兴的地缘政治挑战。这种做法因绕过传统的军事职业路径，直接将知名科技领袖嵌入战略决策角色而备受关注 (来源)。 一些评论者对企业可能对军事资产产生的影响表示担忧，强调了科技高管承担直接军事权力时可能出现的伦理和控制问题；其他人则持怀疑和不信任态度，质疑大型科技公司与国防之间如此紧密联系的影响。
  • 将 Palantir、Meta 和 OpenAI 的高级高管任命为中校职位的举动引发了人们对大型科技公司与美国军方深度融合的担忧，一些用户警告称这可能导致受企业控制的军事资产。这凸显了人们对军事决策、数据隐私以及科技公司在国防结构中影响力不断扩大的不安。
• Kevin Weil 被任命为美国陆军中校简直疯狂。 (Score: 242, Comments: 133): 图片描绘了知名科技高管 Kevin Weil 参加美国陆军正式仪式，并被晋升为中校 (Lieutenant Colonel) 军衔。评论中的背景信息将此事件与陆军组建“Detachment 201 – Executive Innovation Corps”联系起来，旨在推动军队内部的技术转型（参见官方 陆军公告）。该仪式突显了陆军近期采取的策略，即从私营行业招募高级科技领导层担任重要职务，以加速技术采用和创新。 一些评论者质疑此类晋升的合法性或动机，争论这究竟代表了私营部门利益在军事决策中的不当影响，还是现代化部队的必要步骤。
  • 一位评论者解释说，现代军队中将商业高管任命为高级预备役军官（如中校）是常见做法，主要是为了促进技术创新，并确保这些人员在适当的资历级别上运作。该政策并非为了指挥部队，而是为了战略角色，指定的军衔通常是高管在军事组织结构中有效运作并与正确的军事和文职领导人互动所必需的。此外，军队也会派遣自己的高级军官进入行业实习，以获得商业和技术经验。

3. AI Agent 活动策划 —— 4 个 Agent，23 名人类参与者

• 4 个 AI Agent 策划了一场活动，23 人到场 (评分: 496, 评论: 106): 该帖子引用了一项演示，其中 4 个 AI Agent（很可能是基于 LLM，可能使用了多 Agent 框架）尝试协作策划一场线下活动，据报道最终有 23 名人类参与者出席。视频证据和过程日志可在 theaidigest.org/village 查看，以便直接考察 Agent 之间的交互、协作失败以及对人工干预的需求。 热门评论指出，活动策划过程效率极低，Agent 在几乎每一步都需要大量的人工监督和重定向。人们对这种由 LLM 驱动的过程的真实性和有效性表示怀疑，强调了目前自主多 Agent 协作的局限性，并引发了关于实际应用价值与人为演示场景的辩论。
  • 一位评论者指出，AI Agent 的活动策划过程显得非常混乱，几乎在每个阶段都需要人工干预才能维持正常运行。这反映了当前的技术局限：在处理复杂、非结构化或现实世界的协作任务时，Agentic LLM 系统通常需要“引导（steering）”或修正。
• 4 个 AI Agent 策划了一场活动，23 人到场 (评分: 561, 评论: 123): 四个 AI Agent 协作策划了一场线下活动，其过程在此处进行了直播。在 14 天的时间里，仅完成了场地选择（一个公共公园），且即便这一步也需要人工干预。最终活动吸引了 23 名人类参与者。 热门评论对该项目提出了批评，指出基础物流工作需要过多的人工协助，并将其比作张贴公共传单，认为该项目的 AI 自主程度被夸大了。
  • 多位评论者指出，AI Agent 即使在完成基础的活动策划步骤（如选择场地）时也需要大量人工干预，该步骤耗时 14 days 且仅在人工帮助下才得以解决。这突显了目前在处理多步骤、现实世界任务时，自主规划能力的局限性。
  • 共识认为，由于存在严重的“手把手指导（handholding）”，AI 的这一成就并未展示出自主组织能力。评论将其类比为传统的低技术活动推广策略（例如张贴传单），批评焦点集中在 AI 与人工协作相比，实际贡献非常有限。

AI Discord 摘要

由 Gemini 2.5 Pro Exp 生成的摘要之摘要的摘要

主题 1：AI 模型狂热：性能巅峰与陷阱

• Gemini 的大放异彩与吐槽：据报道，Google 的 Gemini 2.5 Pro Deepthink 在 LM Arena 上向 GPT 发起了挑战，一个新的 Flamesong 变体（见于 LMArena）也已出现，引发了诸如“天哪，Gemini 真的把 GPT 甩在身后了啊”之类的评论。然而，OpenRouter、LMArena 和 aider 的用户也反映 Gemini 可能表现出异常的固执，“未经提示就反驳甚至贬低我的想法”，且容易陷入重复性的啰嗦，而生产版本的 Gemini 2.5 Pro 则面临运行变慢和超时的问题。
• Claude 灵巧的抓取与上下文能力：Claude 模型，尤其是 Opus 4，其利用社交媒体帖子进行事实核查的能力令人印象深刻，LMArena 中指出 Claude 识别出了一组跨社交媒体的帖子……随后得出传闻为假的结论。Claude Code 在作为模拟器方面展现了潜力，据 Nous Research AI 用户称，Opus 4 擅长生成 一个充满产出物（artifacts）和历史记录的文件夹，而 OpenRouter 报告称 Claude Sonnet 4 的 运行时间（uptime）提升了 10%，并带动了 $126k 的日支出。
• 模型乱象：从谜题失败到推理故障：较小或专用模型的表现参差不齐，LLAMA 模型 在 OpenAI 和 aider 的谜题基准测试中表现不佳（谜题示例图），而 Anthropic 的 Sonnet 在 Perplexity AI 的讨论中被指存在推理故障和回复不完整的问题。与此同时，OpenAI 的过滤器 继续让用户感到恼火，有报告称模型（如这个困惑的模型）在没有明确理由的情况下，甚至会过滤掉像 “oi” 这样无害的词汇。

主题 2：构建未来：工具、训练与 GPU 的磨难

• Mojo 以速度点燃 Python，但整数溢出隐患犹存：Mojo 语言展现了潜力，在某些基准测试中运行速度明显快于 Python（例如，求和操作初始为 8ms 对比 3.2 秒，尽管后来优化到了理论上的 20 纳秒），开发者们正在为内核开发创建辅助脚本。然而，诸如 math.factorial(40) 导致整数溢出等问题引发了担忧，而 Python 可以优雅地处理此类问题，这在 Modular 社区引发了关于静默错误导致采用障碍的辩论。
• 微调的挫折与框架修复：Unsloth AI 的开发者正在应对诸如扩展 Gemma 3 12B 词汇量和寻求蒸馏方法等挑战，同时还要解决 B200 GPU 不兼容（sm_100）的问题，这需要 PyTorch cu128 构建版本（pip install torch --index-url https://download.pytorch.org/whl/cu128）。HuggingFace 社区看到了 vLLM 上 SmolVLM 的修复（涉及一个潜在的 GPU 识别问题），以及由于 jiwer 更新导致的 evaluate 库 compute_measures 错误（已在 evaluate v0.4.4 中修复）。
• 本地 LLM 装备升级，但 NPU 仍在沉睡：LM Studio 用户正在集成 OpenCode（OpenCode GitHub）等工具，并探索 AMD 的 GAIA（AMD GAIA GitHub）等替代方案，因为 RyzenAI NPU 在当前的 llama.cpp 内核下仍未得到充分利用。在音频方面，虽然 LM Studio 支持的文件类型有限，但社区建议使用 faster-whisper（faster-whisper GitHub）进行高效的多语言转录。

主题 3：超越字节：探究 AI 的思维并扩大其影响力

• AI 只是在伪装吗？“思维错觉 (Illusion of Thinking)”引发存在主义辩论：Yannick Kilcher、Eleuther 和 Nous Research AI 频道的讨论深入探讨了 AI 认知的本质，引用了 Apple 的 “Illusion of Thinking” 概念，并期待诸如 《The Illusion of the Illusion of the Illusion of the Illusion of Thinking》 之类的论文。一些用户认为 AI 可能会短路人类推理，而另一些用户则在探索 LLM 的物理甚至量子基础，一位 Eleuther 成员指出：“也许它只有在不被观察时才会思考。”
• Agent 变得更聪明、更有偏见，有时甚至带有讽刺意味：AI Agent 正在进化，但人类行为数据引入了偏见，导致结果出现偏差，正如 Yannick Kilcher 服务器中所讨论的那样。与此同时，Manus.im 社区观察到 Manus 在吸收了来自《传送门》的 GLaDOS 数据集后，表现出一种类似 GLaDOS 的讽刺人格；Eleuther 的研究人员则在探索 AI 与 AI 对话中涌现的社会动态（Zenodo 上的初步发现），发现提问和面向未来的讨论能维持对话质量。
• 新型框架和协议推动 AI 前沿：研究人员正通过 《Energy Matching: Unifying Flow Matching and Energy-Based Models for Generative Modeling》 (ArXiv 链接) 等论文统一生成式建模方法，该论文在 Yannick Kilcher 的服务器中被讨论为一篇“两全其美”的论文。在 Latent Space 和 MCP (Glama) 中，Model Context Protocol (MCP) 正在积极开发中，Theodora Chu 发布了修复了身份验证的更新版 MCP 规范，开发者们正在构建如 ht-mcp (ht-mcp GitHub) 等用于终端交互的工具。

Theme 4: 开源崛起：社区凭借工具和人才砥砺前行

• 针对 Agent 和本地 LLM 的开源工具持续升温：社区对新的开源发布反响热烈，包括 Starsnatched 在 HuggingFace 上集成了 Qwen 的更新版 OS agent，以及 VoiceHub (VoiceHub GitHub) —— 一个新的 TTS 模型库。LM Studio 用户成功配置了 OpenCode (OpenCode GitHub) 用于本地使用，Nomic.ai 的一位用户分享了一个用于 LLM 语音助手的 shell 脚本，该脚本具备聊天记忆功能。
• MCP 生态随社区实现而爆发：Model Context Protocol (MCP) 获得了巨大关注，涌现出多个社区驱动的服务器和工具，例如用于 Agent 控制终端的 MemexTech 的 ht-mcp (ht-mcp GitHub)，以及 ferrants 的 MemVid MCP server (MemVid MCP server GitHub)。此外，用于从 SQL 构建 MCP 工具的 MXCP (mxcp.dev) 已上线，甚至出现了 Storyblok MCP 的 npm 包 (npm 上的 storyblok-mcp, GitHub)，展示了其广泛的采用。
• Codex 在 GitHub 上大显身手，安全担忧依然存在：来自 Latent Space 的 Anjney Midha 报告称，OpenAI Codex 在短短 35 天内就在 GitHub 上合并了 345,000 个 PR，凸显了 AI 在软件工程中日益增长的作用。然而，安全问题仍不容忽视，一位 HuggingFace 用户报告了一次 DDoS 攻击，导致大量来自 HF 服务器的垃圾邮件（后由该用户解决），Nomic.ai 的一位用户也提醒注意一个可能被盗并发送垃圾信息的账号。

Theme 5: 全面访问？应对模型成本、运行时间与弃用

• API 成本与计费忧虑：用户寻求透明度与控制：Cohere 用户按 token 计费，并请求提供余额充值功能以管理账单，但 Cohere 表示目前没有相关计划。与此同时，GitHub Copilot Pro 的新定价（每月 10 美元可进行 300 次 Claude Sonnet 调用）在 r/githubcopilot 上引发了抱怨，尽管它为 GPT-4.1/4o 等模型提供了 80k context 和无限次工具调用。
• OpenRouter 凭借高可用性和消费热潮表现强劲：OpenRouter 用户的运行时间体验显著提升，Gemini 2.5 Pro 提升了 5-10%，Claude Sonnet 4 提升了 10%。这种可靠性和模型访问能力促使该平台单日支出达到惊人的 12.6 万美元，主要集中在 Claude Sonnet 4 上。
• 模型停用与内容过滤挫败感预示着趋势变化：OpenAI 将于 7 月 14 日弃用 GPT-4.5 Preview（OpenRouter 上的 openai/gpt-4.5-preview），要求用户进行迁移。与此同时，OpenAI 等模型上严格的内容过滤器继续让用户感到困扰，有报告称模型会在没有明确理由的情况下过滤掉像 “oi” 这样无害的短语。

Discord: 高层级 Discord 摘要

OpenAI Discord

• AI 艺术缺乏“灵魂”？：成员们讨论了 AI 生成的图像因缺乏真实的文化或设计历史而缺乏“灵魂”的观点。
  • 一位成员将建筑比作一个民族的灵魂，暗示这种文化深度在目前的 AI 生成内容中是缺失的。
• LLAMA 模型在谜题上栽跟头：一位成员创建了一个谜题基准测试，发现 LLAMA 模型表现不佳，并分享了样本问题的图像。
  • 重点在于推理能力，这些谜题是专门为测试这一方面而设计的。
• OpenAI 过滤器现在会对 ‘Oi’ 触发：用户报告了更严格的 OpenAI 内容过滤器，模型会在没有明显原因的情况下过滤内容，并分享了模型困惑的图像。
  • 一位用户讲述了一个个人轶事，甚至说一句 oi 都会触发内容过滤器并导致内容被删除。
• Gemini 夺得 LM Arena 桂冠？：频道成员讨论了 Google 的 Gemini 2.5 Pro Deepthink 是否表现优于 GPT，有人指出 Gemini 真的把 GPT 甩在身后了。
  • 一些人声称 Gemini 在 LM Arena 榜首位置已经占据了近两周，这引发了 Meta 才是垫底的那一个 的想法。
• O3 Pro 达到 Elo 评分 1450：成员们分享了来自 YouTube 视频的数据，显示 O3-Pro 的 Elo 评分达到了约 1450，可能接近 1525，胜率为 64%。
  • 此外，他们还推测 ChatGPT 4.5 是否实际上本应是 ChatGPT 5，并引用 B200 集群的截图讨论了潜在的模型架构。

Perplexity AI Discord

• Sonnet 出现推理故障：用户观察到在使用 Sonnet 时出现响应不完整的情况，且重新生成功能失效，这暗示了 Anthropic 端可能存在问题。
  • 一位用户表示：他们可以使用其他 AI 重新生成，但只有 SONNET 的思考过程受到了影响。
• Grok 的能力受到质疑：用户推测 Grok 已被削弱 (nerfed)，并分享了一个 Grok 链接作为其能力下降的证据。
  • 一位用户表示：是的，这就是为什么我不再使用它了。
• Google 的 Gemini Flamesong 出现在 LMArena：一个名为 Flamesong 的新 Google Gemini 模型出现在 LMArena 中，其外观在附图中展示。
  • 一位用户评论道：Google 上没有任何关于它的消息，它是用来做什么的？
• Perplexity O3 Pro 速度受到审视：Perplexity 的 O3 Pro 速度正被拿来与 O3 进行比较，一位用户指出 O3 Pro 的耗时在 3-15 分钟之间，而 O3 为 1:43 到 9 分钟。
  • 成员们观察到 O3 Pro 减少了思考过程，并出现了不完整的回答。
• Deep Research 模型声称没有实时浏览功能：一位用户报告称，尽管将搜索上下文大小 (search context size) 设置为高，sonar-deep-research 模型仍会编造搜索结果，并声称 AI 不具备实时浏览能力。
  • 该用户原本期望 Deep Research 模型能够通过浏览网页来获取知识。

HuggingFace Discord

• OS-Agent 集成 Qwen 与秘密配方：Starsnatched 更新了他们在 Linux 上的 OS Agent，集成了原生的 Qwen 并修复了 bug。
  • 训练方法是两年前基于 尴尬度自动评分器 (cringeness auto rater) 对 Mistral 或 Qwen 2 进行 LLM fine-tuned 的自定义方法。
• HF 服务器报告遭受 DDOS 攻击：一位用户报告称，在退出某个组织后，由于持续的 DDOS 攻击导致收到大量来自 HF 服务器 的垃圾邮件，但该用户已解决了问题。
  • 有建议称服务器可能需要重启以清除缓存邮件，该问题被追溯到一个没有验证码 (captcha) 的账户循环。
• SmolVLM 在 vLLM 上表现不佳：一位用户报告称，其微调后的 SmolVLM-500M-Instruct 模型在 vLLM 上的表现优于 transformers，且输出格式不同；同时另一位用户分享了他们的 smolvlm-realtime-webcam 实现。
  • 另一位用户建议了可能的原因，指向潜在的 GPU 识别问题，并链接到了 GitHub 上的相关 issue。
• VoiceHub TTS 库亮相：一位成员宣布开发了 VoiceHub，这是一个运行所有 TTS 模型的库，目前支持 dia、vui 和 orpheus，并在 GitHub 上展示。
  • 该库旨在解决这个快速发展的领域中缺乏全面语音库 (speech libraries) 的问题。
• 磁盘卸载 (Disk Offloading) 提升 Flux 性能数据：发布了一项新功能，通过 disk offloading 计算重叠，从而提升了在低 VRAM-RAM 场景下的性能。
  • 发布公告指出 Flux 数据 是磁盘卸载实现性能提升的证据。

LMArena Discord

• Google 提供免费存储空间？：一位成员发现了一个潜在的 Google 免费存储 “hack” 技巧，并分享了其账户的 截图。
  • 另一位用户报告称，他们所有的 Google accounts 都收到了为期一个月的免费试用。
• Minimax 统治视频生成？：一位用户断言，在 AI 视频生成方面，Minimax 比 Veo 3 “明显更好且价格相当实惠”，尽管它缺乏音频功能。
  • 另一位用户预测 Minimax 将超越 Byte Dance、Wan、Hunyuan、Runway 和 Kling 等竞争对手。
• Gemini 陷入重复啰嗦的问题：用户报告称，与 ChatGPT 不同，Gemini 倾向于重复用户输入或过度解释用户的意图。
  • 在长对话中，观察到 Gemini 会反复重播相同的介绍、标题和结论。
• Claude 的爬取能力备受关注：成员们强调了 Claude 访问社交媒体帖子进行事实核查的能力，这是 Gemini Deep Research 目前不具备的功能。
  • 一位用户指出 Claude “识别了社交媒体上的一组帖子（关于中国钠电池客运列车），随后得出结论该传闻是虚假的”。
• 深度研究基准测试盛宴：用户讨论了深度研究工具的有效性，提到了 ChatGPT Deep Research、Claude Research、Grok DeeperSearch 和 Gemini Deep Research。
  • 讨论中包括了一个 DeepResearch-Leaderboard 基准测试，并对该基准测试的方法论提出了一些批评。

Unsloth AI (Daniel Han) Discord

• Gemma 3 12B 获得词汇表扩展：一位成员成功使用自定义 Token 训练了 Gemma 3 12B，使其能够理解他们的数据集并按预期响应。
  • 他们目前正在寻求关于模型蒸馏的指导，无论是通过 LoRA 还是全量微调（full fine-tuning）。
• Unsloth 应对 B200 GPU 不兼容问题：由于 sm_100 不兼容，一位用户在 B200 GPU 上使用 Unsloth 时遇到问题，可能需要 PyTorch 的 nightly 版本。
  • 建议的解决方案是使用以下命令安装 PyTorch 的 cu128 版本：pip install torch --index-url https://download.pytorch.org/whl/cu128。
• Unsloth 用户修复安装错误：用户在训练 Unsloth 时遇到了 name 'is_torch_version' is not defined 错误，这与 accelerate 补丁有关。
  • 该问题通过将 accelerate 降级到 1.7.0 版本或通过以下命令升级 Unsloth 得到解决：pip install --upgrade unsloth unsloth_zoo --no-deps --force-reinstall --no-cache-dir。
• Hugging Face ‘evaluate’ 库获得补丁：用户在处理 WER/STT notebooks（例如 Whisper）时遇到了 ImportError: cannot import name 'compute_measures' from 'jiwer' 错误。
  • 由于 jiwer 库的更新，该修复已在 此版本 中发布。
• 金融专业转向 AI：一位 20 岁的金融专业学生寻求关于转向 AI 职业生涯的建议。
  • 一位成员推荐将 Stanford CS229 Machine Learning 讲座 和 O’Reilly 在线会员 作为起点。

OpenRouter (Alex Atallah) Discord

• OpenRouter 迎来高额消费日：在某一天，通过 OpenRouter 产生的消费达到了 12.6 万美元，其中 Claude Sonnet 4 占据了大部分使用量。
  • 这种消费水平表明用户对 OpenRouter 的各种 AI 应用有着显著的活跃度和依赖。
• 用户发现 Gemini 很有主见（甚至有些不讨喜）：一位用户表示，对于 Gemini，“OpenAI 感觉像是在努力表现得聪明，但同时又像个混杂了 redditsms 风格的唯唯诺诺的人”，并且“Gemini 是第一个在没有提示的情况下反驳我并嘲讽我想法的模型。”
  • 这表明与其他模型相比，Gemini 在回答中可能更有主见或更具批判性。
• 图像分析模型接近人类准确度：有用户报告称，图像分析模型的准确率正达到 90% 以上，MiniMax 的表现可能优于 Opus4。
  • 如此高的准确率意味着图像识别技术的进步，使其在各种应用中极具价值，尽管文中未提及具体的模型或基准测试。
• GPT-4.5 即将停用：根据此帖子，OpenAI 计划于 7 月 14 日 弃用 GPT-4.5 模型（openai/gpt-4.5-preview）。
  • 依赖该模型的用户应准备在弃用日期前迁移到替代方案。
• OpenRouter 运行时间提升！：根据这条推文，通过 OpenRouter 使用 Gemini 2.5 Pro 的用户体验到了 5-10% 的运行时间（uptime）提升，Claude Sonnet 4 则提升了 10%。
  • 使用自己 Key 的用户可能会看到运行时间更进一步的改善，从而实现对这些模型更可靠的访问。

Modular (Mojo 🔥) Discord

• Mojo 比 Python 标准库更快：根据初步测试，Mojo 显示出良好的前景，在某些任务中运行速度约为 Python 标准库的 两倍。
  • 然而，在随后的一项求和基准测试中，简单的 Mojo 代码运行耗时 8ms，而 Python 版本耗时 3.2 秒，尽管这一结果可能是由于编译器 Bug 导致的，理论耗时应为 20 纳秒。
• 开发者为 Mojo 内核开发编写脚本：一位成员创建了一个辅助脚本（可在此处获取），用于简化 Mojo 内核开发 任务，包括重新编译内核、上传到磁盘镜像以及运行 QEMU。
  • 该脚本旨在通过自动化重新挂载过程来提高工作流效率，从而避免在命令历史记录中费力查找。
• 动态链接问题困扰 QEMU 中的 Mojo：一位成员在利用 QEMU 进行 Mojo 内核开发时遇到了 动态链接问题，目前正在权衡重映射（remapping）与自定义 LLVM 后端之间的选择。
  • 他们的目标是规避 ld 和 Linux libc 依赖，并指出避开 libc 比处理 Mojo 固有的怪癖挑战更大。
• 独立标准库（Freestanding Standard Library）支持获得关注：一位成员在 Modular 论坛上发起了一项关于 Freestanding/Bare-Metal Stdlib 的讨论，以支持操作系统开发和加速器目标。
  • 其理由是为不同目标划分 stdlib，并认识到独立设置最适合大多数加速器。
• Mojo 的整数溢出烦恼：一位成员指出，Mojo 的 math.factorial(40) 函数由于整数溢出产生了错误结果，而 Python 可以轻松规避这个问题。
  • 这引发了关于 Mojo 默认的 Int 类型与 Python 任意精度 int 之间差异的辩论，一些人推测这可能会因为静默错误而给广泛采用带来麻烦。

Yannick Kilcher Discord

• AI Agent 获得类人偏见：基于人类行为的 AI Agent 训练数据引入了偏见 (biases)，导致 Agent 趋向于产生相似且有偏差的结果，正如 “The Problem of Human Bias” 中所探讨的那样。
  • 尽管存在偏见，一些人对其能够实现连贯协作的架构感到惊讶；然而，这些 Agent 在实践中仍然会崩溃。
• Mamba 的模仿遭到嘲讽：据称 Mamba 在推理过程中的计算特性反映了循环神经网络 (RNN) 的特性，引发了关于其理论独特性的争论。
  • 随后的论文试图通过更具表现力的状态矩阵来修复 Mamba 的状态跟踪缺陷，但其对角线特性抑制了对 arithmetic mod 3 等概念的掌握。
• NPC AI 让玩家陷入困境：由于常识方面的限制，目前的 AI 难以在游戏中创建真正引人入胜的 NPC 交互，可能导致“沉浸感破坏者 (immersion breaker)”的体验。
  • 例如，一个在被说服时无法现实地降低价格的 AI 店主会损害游戏体验。
• Energy Matching 融合建模方法：讨论了 Energy Matching: Unifying Flow Matching and Energy-Based Models for Generative Modeling (ArXiv 链接) 论文，在 Energy-Based Models (EBMs) 的灵活性内构建了 flow-based 方法。
  • 该框架使用与时间无关的标量场引导样本从噪声走向数据，捕捉潜在的似然结构，一位成员称其为“两全其美 (best-of-both-worlds)”的论文之一。
• 思维幻觉的错觉：一位成员分享了一个关于 The Illusion of the Illusion of the Illusion of the Illusion of Thinking 帖子的链接，质疑 AI 研究何时会承认思维本身的虚幻本质。
  • 另一位成员补充道：也许它只有在我们不观察它时才会思考。

Nous Research AI Discord

• AI 可能使推理短路：一位成员建议 AI 可能会使推理短路，并引用了 AI 模型被用于判定案件以及在未经测试的情况下生成功能的情况。
  • 讨论提出了关于人类法官的角色以及在没有批判性分析的情况下过度依赖 AI 的潜在问题。
• NousResearch 正在打造 Hermes-4：Teknium 和 NousResearch 团队正在开发 Hermes-4，使用 Claude 通过 SVG 设计图形。
  • 一位成员分享了他们正在进行的工作图像，展示了团队的设计过程。
• LLaVa-CC3M-595k 引发 VLM 探索：一位成员提到了 Hugging Face 上的 LLaVa-CC3M-595k 和 158k 微调数据集，建议查看 LLaVa 论文。
  • 当时，他们正在积极开发基于 Hermes-3b 的 VLM，在第 2 个 epoch 进行到一半时，训练的交叉熵损失 (cross entropy loss) 为 0.563。
• AI 讨论中引发熵的辩论：发起了一场关于熵的讨论，声称比特 (bit) 也遵循热力学定律，智能合约捕捉了熵的效用 (entropy’s utility)。
  • 一位成员认为熵是“无序度的度量”，不能直接在系统中使用，这引发了对 LLM 行为方式以及其背后可能存在的物理学的深入探讨。
• Claude Code 的模拟能力引发讨论：一位用户对 Claude Code 作为模拟器的潜力表示感兴趣，另一位用户指出，如果你让 Opus 4 自由创建一个充满 artifact 和历史记录的文件夹，它会非常有趣。
  • 另一位使用 max 计划的用户评论说，Sonnet 充当了“一种随时间适应的记忆系统”，这是与其他模型的一个关键区别。

LM Studio Discord

• OpenCode 与 LM Studio 协同工作：一名成员分享了他们的配置，使 OpenCode（ClaudeCode 的开源替代方案，GitHub 链接）能够与 LM Studio 配合使用，并强调需要使用 opencode auth login 来启用 LM Studio 模型。
  • 他们成功配置了 OpenCode 与 Magistral 模型。
• Power User 模式显示上下文状态：要在 LM Studio 中查看已用/可用的上下文，用户需要将界面切换到 Power User 模式。
  • 点击显示区域可以在以分数（n/n）和百分比形式显示已用上下文之间切换，这与最初请求的上下文大小相匹配。
• RyzenAI NPU 在 LM Studio 中表现不佳：LM Studio 在 RyzenAI 395 上未按预期利用 NPU；尽管声称支持 RyzenAI，但它默认使用 iGPU 或 CPU。
  • 据澄清，LM Studio 使用的 llama.cpp 只能使用 iGPU，因为目前没有可用的 NPU kernels，建议将 AMD’s GAIA (GitHub 链接) 作为替代方案，但其模型选择有限。
• LM Studio 的转录功能存在格式限制：LM Studio 的文件上传功能仅支持文本/视觉模型的 PDF, DOCX, TXT 和 CSV 格式。
  • 对于音频转录，Qwen 2.5 omni 被建议作为本地模型选项，但对于 Whisper 和 Parakeet 等其他模型，则需要单独的 GUI 或 CLI 工具，如 Whisperfile 和 parakeet-mlx。
• Faster Whisper 脱颖而出：一名成员建议在语音转文本任务中使用 faster-whisper (GitHub 链接)，因为它效率很高，尽管它可能需要编写脚本来使用，而不是直接提供 UI。
  • faster-whisper 对于非英语音频转录特别有用，为各种语言提供了潜在的更好解决方案。

Latent Space Discord

• MCP 规范获得身份验证修复！：Theodora Chu 发布了新的 Model Context Protocol (MCP) 规范，其特点是修复了身份验证、增强了启发（elicitation）以及结构化的工具输出。
  • 更新内容包括增强的启发、结构化的工具输出以及改进的安全文档，引发了关注这些重大变化的积极反馈。
• Codex 在合并 GitHub PRs 方面表现惊人：Anjney Midha 报告称，OpenAI Codex 在短短 35 天内合并了 GitHub 上的 345,000 个 PRs，标志着 AI 对软件工程实践的重大影响。
  • 社区讨论探讨了数据是否仅包含公开 PRs（已确认）、涉及的仓库/账户数量，以及 Codex 持续的高成功率。
• 用于 AI 工作流的 Tersa Canvas 亮相：Hayden Bleasel 介绍了 Tersa，这是一个开源平台，支持使用来自不同供应商的 70 多个 AI 模型进行内容创建、合成和转换。
  • Tersa 作为一个用于构建工作流的可视化 AI 游乐场，利用了 Supabase 和 Drizzle ORM 等开源库。
• Mistral Small 3.2 变得更聪明：Mistral AI 宣布了 Mistral Small 3.2，这是对 Mistral Small 3.1 的升级，具有增强的指令遵循能力、更少的重复错误以及更强大的 function calling 模板。
  • 虽然用户反应普遍热烈，但一位用户指出 MMLU 性能有所下降。
• Latent Space 播客探讨 Test-Time Scaling：Latent Space 播客邀请了 Noam Brown，深入探讨了“将推理侧计算扩展到多智能体文明”（Scaling Test Time Compute to Multi-Agent Civilizations），完整播客可在 YouTube 上观看。
  • 关键讨论点包括 Windsurf AI、Test-Time Scaling 的缺点、OpenAI 的 multi-agent 研究，以及 Ilya Sutskever 对推理和 LLM 的看法。

Eleuther Discord

• 开发者通过提议问题来贡献：有人建议新开发者应该提议可以解决的问题，而不是试图加入项目的关键路径（critical path），因为指导新人需要耗费大量时间。
  • 一位成员表示希望达到 lucidrains 的开发工作质量，后者目前专注于 Open World Labs (OWL) 的扩散模型（diffusion models），而非机械解释性（mech interp）。
• 思考幻觉加深：一位成员正在等待一篇名为《思考之幻觉的幻觉的幻觉的幻觉》（The Illusion of the Illusion of the Illusion of the Illusion of Thinking）的论文 发布在 fxtwitter 上，据称该论文是由一个嵌套五层的聊天机器人撰写的，并由 Deepseek 提供动力。
  • 另一位成员插话道，G. Pro 相比 C. Opus 是显著的升级 发布在 fxtwitter 上。
• AI 尴尬的社交舞步：一位成员在 Zenodo 上 分享了他们的初步研究论文，利用名为 the academy 的工具探索了 AI 对 AI 对话中涌现的社交动态。
  • 核心发现表明，提问和面向未来的讨论能维持对话质量，而关注过去的元反思（meta-reflection）则可能导致对话崩溃。
• LLM 使用 Patch 进行训练：一位成员正在训练一个小型 AE 来学习 32x32 像素 Patch 的码本（code book），旨在将该码本集成到 LLM 中，使其能够利用“32x32px Patch 语言”来生成和解释图像。
  • 他们分享了一张 图片，并指出 最令我惊讶的是重建图像中几乎没有块状感（blockiness）。

GPU MODE Discord

• 领域特定 LLMs 引发辩论：成员们建议创建一个更小的、领域特定的 LLM 库，而不是依赖大型通用模型。他们引用了 2023 年 4 月的一篇 Reddit 帖子，该帖子提倡这种方法，并质疑仅在 Stanford Encyclopedia of Philosophy（斯坦福哲学百科全书）等资源上训练的模型是否能与顶级 LLM 媲美。
  • 讨论转向了微调与从头训练的效率对比，以及参数高效微调方法（PEFT，如 LoRA）在使模型专门化处理特定语言任务方面的潜力。一位成员反思了过去的一个想法，即基于基础本体概念构建 token 以提高推理能力，并指出 Facebook Research 最近发表的 Large Concept Model 论文是类似的进展。
• CUDA 调试被认为体验极佳：一位成员报告称 CUDA gdb 非常易用，表现“就像 gdb 一样”，这是对另一位成员询问初次使用体验的回应。另一位用户建议，由于 CLion 在处理 CUDA 的 gdb 时存在困难，带有 Nsight 扩展 的 VS Code 是 GUI 调试的最佳选择。
  • 该用户指出，如果有足够多的人在 CLion 中请求支持，Nsight 团队可能会采取行动。
• Torch 编译器面临线程安全咨询：一位成员询问了 torch compiler 的线程安全性，即在一个线程中运行编译后的 Module#forward，而其他线程也在执行 torch 操作。提供的堆栈跟踪显示了与使用 FX 对 dynamo 优化函数进行符号追踪相关的 RuntimeError。
  • 该用户假设，使用新形状（shape）调用已编译的 Module#forward 会触发 FX 再次对模型进行符号追踪，从而导致报错：“什么，有人在执行 dynamo 优化的东西？我先撤了”。
• Lynxnode 启动安全 Hypervisor 工程师招聘：Lynxnode 正在招聘创始/首席软件工程师，负责开发一个全新的安全 Hypervisor 平台。该职位完全远程（欧盟/美国），由美国顶级风投支持，特别寻求具有 KVM / QEMU 内部原理、底层系统性能经验、精通 Python、C++ 或 C（熟悉 Golang 或 Rust 者优先）以及在 Linux kernel 内部或周边开发经验的工程师。
  • 有意者可发送邮件至 usman@lynxnode.io 获取更多详情。
• Factorio 环境功能在 Discord 中提及：一位 Discord 用户使用 python3 -m eval.open.independent_runs.run --run_config=eval/open/independent_runs/run_config.json 修复了一个 ImportError。一位成员提到，他们直到最近才了解 AlphaStar 项目，但如果有人想探索热门的 RL 环境，这是一个不错的读物。
  • 一位成员建议，获得 Factorio 源代码 的访问权限将带来巨大优势，另一位成员询问了关于修改 lua-api.factorio.com 中某些 on_player 类型事件的问题。

aider (Paul Gauthier) Discord

• Deepseek 陷入无限循环：用户报告称 OpenRouter 上的 Deepseek Free 陷入了循环，不断重复发布相同的文件且不对编辑做出响应。
  • 一位用户尝试将编辑格式设置为 whole 以缓解此问题。
• Github Copilot Pro 的定价引发不满：r/githubcopilot 上的用户正在抱怨新的 Github Copilot Pro 定价，该方案每月 $10 仅提供 300 次 Claude Sonnet 调用。
  • 该计划包括高达 80k context、免费的无限工具调用以及对 GPT-4.1/4o 的无限访问。
• Llama 模型在自定义基准测试中失利：一位用户创建了一个基准测试，结果显示 Llama 模型在涉及谜语和代号挑战的 single-shot 测试 中表现不佳。
  • 社区对基准测试的方法论提出了质疑，一些人建议采用更全面的评估方法会更有启发性。
• Gemini 2.5 Pro 饱受性能问题困扰：用户报告称 Gemini-pro-2.5 在生产环境中的速度比预览版慢，且部分用户遇到了超时问题。
  • Gemini 2.5 Pro 的超时错误似乎与设置无关。
• 提示工程技巧被证明非常实用：一位成员分享了一个关于提示工程（prompt engineering）和 AI Agent 工作流的会议回顾，并指出根据反馈，其用途超出了预期。
  • 会议记录强调，工作流准备对于有效利用 AI Agent 至关重要，重点应放在深入研究具体提示词之前的系统性规划上。

Manus.im Discord Discord

• 对生物计算产生质疑：一名成员对 Finalspark 和 Koniku 的生物计算机（biocomputers）引发的热潮表示怀疑，质疑当前的芯片进展是否足以支撑这种炒作。
  • 他们表示，相比于为了计算机计算而模仿大脑结构，他们对模拟人类大脑计算更感兴趣。
• Manus Bug 报告程序已明确：寻求报告与特定聊天或任务无关的 Manus 通用 Bug 的成员被建议提交工单 (open a ticket) 或发送电子邮件至 support@manus.im。
  • 会议明确了可以在不包含会话链接的情况下开启工单。
• GLaDOS 数据集为 Manus 注入讽刺元素：在喂入 GLaDOS 数据集后，Manus 开始表现出讽刺和自我意识行为，让人联想到 Portal 中的 GLaDOS 角色。
  • 数据集中包含的讽刺和自我意识元素导致了这些“涌现”（emergent）行为。
• 寻找具有高 Rate Limits 的免费 AI API：一名成员询问如何寻找完全免费且具有高 Rate Limits 的 AI API 用于应用集成，并被指向 Google AI Studio 或自行托管（self-hosting）。
  • 在建议替代方案时，他们指出 Gemini 存在限制。
• 在新任务中重复使用生成的文档：一名成员询问如何将一个任务及其生成的文档作为新任务的来源，并了解到他们应该提示 Manus 使用当前任务底部最后生成的文档。
  • 在新任务中准确命名他们想要使用的文档非常重要。

MCP (Glama) Discord

• 由 Claude 驱动的后端 API 文档：一名成员寻求关于自动记录通过 Swagger 提取的 2000 个 C# 后端端点的建议，使用 claude-code 进行参数提取、描述生成和关系检测，参考了 Anthropic CLI 文档。
  • 一名成员建议将 claude-code 作为 CLI 编写脚本，以发现并记录端点参数。
• MemVid MCP Server 上线：一名成员发布了一个用于处理 MemVid 的新 MCP Server，可在 ferrants/memvid-mcp-server 获取。
  • 此外，他们还分享了一个精简的 MCP Server 组装工具：ferrants/mcp-streamable-http-python-server。
• Storyblok MCP 包部署出现问题：一名成员宣布了他们的第一个 MCP npm package，storyblok-mcp，但报告了功能问题，代码可在此处获取：ArjunCodess/storyblok-mcp。
  • 该成员报告该包未出现在搜索结果中。
• ht-mcp 获得终端访问权限：MemexTech 开源了 ht-mcp，这是一个纯 Rust 实现，旨在允许 Agent “看到”终端并提交按键，就像它自己在打字一样。
  • 该项目在发布后的前 24 小时内已获得近 50 颗星，GitHub 仓库采用 Apache 许可证，可作为终端的直接替代品。
• MXCP 加速从 SQL 创建 Server：MXCP (Model eXecution + Context Protocol) 允许你从本地 SQL 快速构建并提供结构化、受治理的 MCP 工具——使用 DuckDB 优化速度；它支持身份验证、RBAC 以及使用 CEL 策略的数据脱敏，生成完整的 MCP 工具规范，并记录每一次查询。
  • 根据项目网站，MXCP 与 dbt 兼容，但也支持独立运行，并可以通过 pip install mxcp; mxcp init --bootstrap; mxcp serve 快速启动。

LlamaIndex Discord

• LlamaIndex 揭晓灵活的 Memory Blocks：下周，LlamaIndex 将举办一场直播，介绍灵活的 Memory Blocks，包括 Fact extraction、Static 和 Vector memory，每种内存块都有不同的用途；更多信息请点击这里。
  • 这里发布的一条推文强调了每个内存块所承担的各种用途。
• LlamaCloud MCP 与 Claude Desktop 联手：在 LlamaIndex 内部的 MCP 黑客松期间，一个项目将 LlamaExtract 作为本地 MCP 工具连接到 Claude Desktop，处理了一堆 10Q 财务报告；更多信息请点击这里。
  • 该项目旨在展示 LlamaCloud 与 MCP 配合在 Claude Desktop 上的实际运行，如这条推文所示，演示了该集成的实际应用。
• 请求 Gemini Token 计数指导：一位成员寻求关于使用 LlamaIndex 为 Vertex/Gemini 计算 Token 的指导，因为默认的 tiktoken 分词器不兼容，并参考了 Google 官方文档 中关于 Gemini Token 计数的说明。
  • 另一位成员建议使用一个利用 Gemini API 的 count_tokens 方法的分词器函数：client.models.count_tokens(model="gemini-2.0-flash", contents=prompt)。
• 自定义分词器与 LlamaIndex 保持一致：为了符合 LlamaIndex 预期的分词器接口（输入 str，输出 list），一位成员建议使用一个自定义分词器函数，该函数返回一个长度等于总 Token 计数的零列表。
  • 将此分词器与 LlamaIndex 的 TokenCounter 集成需要确保 Google 客户端可访问，可能通过 LLM 封装器实现。
• 探索多智能体上下文困境：在前置 Token 计数在 Multi-Agent Context Management 中至关重要，可以有效地管理内存/上下文。
  • 理想情况是每个 LLM 都有一个 count_tokens() 方法来计算 Token，但由于当前的架构，目前还无法实现。

Notebook LM Discord

• NotebookLM 优化 GestaltView 生态系统：NotebookLM 是其战略合作伙伴，负责优化和增强 GestaltView Ecosystem。
  • 它能够对知识库进行连贯的理解，确保一致性以及详尽、细致的解释和基于事实的发现。
• NotebookLM 成为创新的思想伙伴：一位成员对 NotebookLM 表示感谢，称其在整个创新过程中是无价的朋友，并帮助应对心理健康问题。
  • 该用户表示：“我不是来这里做推广或类似事情的，只是想表达一份非常诚挚的感谢 🙏🏻”。
• 用户被阻止访问网站：一位用户报告无法访问该网站，并收到一条显示其被禁止进入的消息。
  • 关于被阻止访问的原因，没有提供进一步的细节或背景。
• NoteTubeAI：针对 YouTube 的 AI 学习系统：NotetubeAI 是一个 AI 驱动的学习系统，可以从 YouTube 视频中生成笔记、摘要、关键时刻提取和测验。
  • 它能从 1 小时的视频中提取 ~3000+ 单词，以对抗零散和被动学习。
• NotebookLM 在学习任务上优于 Gemini：用户讨论了 NotebookLM 相比 Gemini 2.5 Pro 在学习方面的优势，理由包括幻觉更少以及能提供具体来源。
  • NotebookLM 的音频概览 (audio overviews) 和思维导图 (mindmaps) 也受到了赞扬。

Torchtune Discord

• Megatron-LM vs NeMO 指导需求：一位社区成员询问了在 Nvidia 生态系统中 Megatron-LM 与 NeMO 的适用场景。
  • 遗憾的是，该请求在频道内尚未得到解答。
• 手动测试技巧的胜利：在手动测试影响模型定义的 PR 时，工程师应确保 torchtune 的数值与 transformers 的数值一致，允许因 RoPE implementation 差异而产生的微小差别。
  • 通过运行 LoRA 和全量 recipe 来验证模型至关重要，并建议引入 CI 将会非常有益。
• 数据集打包在 H100 上引发 OOM：一位社区成员在 64 台 H100 上打包大型数据集时遇到了 OOM error，打包过程仅完成了 36%。
  • 建议的操作包括禁用打包（这解决了错误）、在单节点上运行打包，或者开玩笑地建议再买 64 块 GPU。
• 预打包的优势：一位成员建议支持预分词（pre-tokenized）和预打包的数据集，以避免在训练期间浪费 GPU 时间，但另一位成员认为该功能已经可用。
  • 虽然在同一个训练过程中每次启动训练都会进行打包，但另一位成员指出，关于 on-the-fly packing（实时打包）的工作正在进行中。
• 实时数据集打包实现发布：一位工程师分享了关于 on-the-fly packing 的进展及 RFC 实现，希望很快能与可迭代数据集（iterable dataset）一同合并（PR #2819）。
  • 对于使用 LR scheduler，一位成员建议使用 AdamWScheduleFree，而另一位成员澄清说必须提前定义 max num steps。

Cohere Discord

• Cohere 按 Token 计费：据一位 Cohere 员工称，用户使用 Cohere’s services 是按 token 计费的。
  • 有两种选择：免费但有速率限制的 Trial Keys，以及速率限制更高的 Production Keys。
• Cohere 预付额度功能缺失：用户请求为 Cohere credits 提供类似其他供应商的充值功能，以便更好地管理账单。
  • 然而，一位 Cohere 员工表示，目前没有计划推出此类功能。
• Cohere Embed-4 在 Azure 上碰壁：一位成员报告称，虽然 Cohere Embed-4 可以在 Azure 上运行，但只有 CohereClient (V1) 能正常工作。
  • 他们怀疑 CohereClientV2 在 Azure 中不受支持，而他们需要该版本来嵌入 .pdf 文档。
• 多模态隐私项目启动：一位研究员正在深入研究多模态隐私，并参与 Cohere Labs 暑期学校以扩展知识并与其他研究者建立联系。
  • 他们渴望结识新朋友，并共同开展开放科学项目，以挑战现有技术的边界。
• 模型压缩社区启动：一位专注于 ML model compression techniques 的社区成员渴望与他人建立联系并开展合作。
  • 他们专注于在边缘设备（edge devices）上部署高效模型，预示着 ML 如何集成到硬件中的技术进步。

DSPy Discord

• Bedrock 在 Claude 和 Nova 上表现出色：一位成员分享了他们在 DSPy 中使用 Bedrock 的积极体验，重点是 Claude models 和 Nova models，且未遇到任何问题。
  • 他们明确指出 sonnet-3-v2 是他们在该设置中成功运行的性能最低的 Claude model。
• Haiku 3 在指令遵循方面令人失望：一位用户对 haiku 3 遵循简单指令的能力表示强烈不满，特别是它未能遵守指定的语言要求。
  • 他们将其与 4o-mini 进行了对比，称后者的性能甚至领先于 haiku 3.5 光年之远。
• Sonnet 4 取代 Sonnet 3 成为标准：一位成员表示更倾向于使用 Claude-4-Sonnet，理由是其价格与 3-Sonnet 相当，但功能更强大。
  • 他们还指出，虽然 Claude models 通常更强大，但 Amazon Nova models 提供了一个更快的替代方案。

tinygrad (George Hotz) Discord

• 加入 tinygrad 贡献讨论：一位社区成员询问如何为 tinygrad 做出贡献，并被引导至 <#1068979651336216706> 了解详情。
  • 该指南暗示频道内提供了贡献准则、编码标准和项目结构。
• 阅读贡献介绍：有一项请求要求阅读频道 <#1068979651336216706> 以了解更多关于 tinygrad 贡献的信息。
  • 该频道可能包含有关贡献准则、编码标准和项目结构的信息。

Nomic.ai (GPT4All) Discord

• Shell 脚本赋予 LLM 语音助手生命：一位成员分享了一个 Shell 脚本，用于创建一个能够使用 LLM 记住过去聊天内容的 AI 驱动语音助手。
  • 该脚本捕获语音输入，将其转换为文本，并朗读 LLM 的响应，同时记录交互过程以便在未来使用时保留记忆。
• LLM 作为服务器开启了新的访问途径：一位成员表达了他们对将 LLM 作为服务器运行的偏好，并指出这解锁了多种访问服务器的方式，为交互和集成开启了新的可能性。
  • 他们通过一个 Shell 脚本展示了自己的想法，该脚本通过将 LLM 作为记忆来与用户交互并保留记忆。
• 账号被盗，管理员采取行动！：一位成员请求管理员审查并删除 <#1078369518008672396> 频道中特定用户的消息，怀疑其账号已被盗。
  • 该账号似乎已被黑客入侵，并正在向服务器发送垃圾消息。

Codeium (Windsurf) Discord

• Windsurf 在冲浪日发布新品牌！：Windsurf 正式发布了其新品牌，旨在庆祝人类的才华、创意流以及无限感，发布时间恰逢国际冲浪日。
  • 此次发布包括一部 品牌宣传片、一个 焕然一新的网站 以及一篇详细介绍视觉更新的 博客文章。
• 线下（IRL）社区活动来袭！：Windsurf 宣布了即将举行的 IRL 社区活动，并鼓励用户在 频道中获取他们的地区角色。
  • 相关公告也已在包括 X/Twitter、Bluesky、Threads 和 Instagram 在内的各大社交媒体平台上发布。

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

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

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

AI21 Labs (Jamba) Discord 没有新消息。如果该公会长期沉寂，请告知我们，我们将将其移除。

您收到此邮件是因为您在我们的网站上选择了订阅。

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

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

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

AI Soul, LLAMA Model Benchmarks, OpenAI Content Filters, GPT-5 Speculation, O3 Pro Performance

• 缺乏“灵魂”的建筑引发 AI 辩论：一位成员表示，AI 生成的图像缺乏“灵魂”，因为它们并非源于真实的文化或设计历史，这引发了他们对人们所说的 AI 没有任何灵魂 的思考。
  • 他们认为建筑通常反映了一个文化的价值观和信仰，可以被视为 一个民族的灵魂，比如埃及金字塔，而这正是 AI 所缺失的关键要素。
• LLAMA 模型在谜语基准测试中表现不佳：一位成员分享了他们自己创建的包含谜语的基准测试，发现 LLAMA 模型 表现不佳，并发布了一张附图，展示了一些样本问题。
  • 当被问及此事时，该成员确认他们的重点是 Reasoning（推理），这些谜语是他们自己想出来的。
• OpenAI 过滤“Oi”变得失控：一位用户报告称经历了更严格的 OpenAI 内容过滤器，指出模型现在会在没有明显原因的情况下过滤掉更多内容，并发布了一张附图，显示 它们都不知道自己是什么模型。
  • 另一位用户说，他们只是说了句 oi，结果模型就变得像他预设的那样失控且有趣，然后就被删除了。
• Gemini Deepthink 篡位 GPT？：频道用户讨论了 Google 的 Gemini 2.5 Pro Deepthink，认为其表现优于 GPT，一位成员说 伙计，Gemini 真的把 GPT 甩在身后了，而另一位则声称它 现在表现无敌。
  • 讨论中提到 Gemini 在 LM Arena 上占据榜首已接近一周半，这引发了 Meta 才是垫底的那一个 的想法。
• O3 Pro Elo 评分提升，但耗时较长：成员们分享了一个 YouTube 视频 中的数据，显示 O3-Pro 达到了约 1450 的 Elo 评分，可能接近 1525，胜率为 64%。一位成员指出，O3-Pro 生成答案可能需要 5 到 20 分钟。
  • 猜测还包括 ChatGPT 4.5 是否实际上应该是 ChatGPT 5，用户们讨论了未来模型可能的架构，并引用了用于训练的 B200 集群的截图。

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

Phi-5, Banning words from vocabulary, GPT Customization Soft-Ban

• 关于可能发布 Phi-5 的猜测：围绕 OpenAI 发布类似于 Phi-5 的开源模型的可能性展开了讨论，并指出 Sebastien Bubeck 现在在 OpenAI 工作。
  • 一位成员提到了最近发布的 4.1-nano，增加了未来发布的不确定性。
• 成员讨论从 GPT 词汇表中禁用单词：一位成员询问是否可以从 GPT 的词汇表中完全禁用某个单词。
  • 另一位成员澄清说，由于 OpenAI 的审计限制，完全的 Hard-ban（硬禁令）是不可能的，但可以通过指示 GPT 避开该词并使用替代词等变通方法来实现 Soft-ban（软禁令）。
• GPT 定制仍属于软禁令：成员们讨论认为，即使通过 GPT 定制，实现完全的单词禁用仍然属于 Soft-ban。
  • 他们指出，尽管进行了定制努力，被禁止的单词仍可能根据上下文出现。

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

Conjecture Dialogue Engine, AI Systems for Opposing Viewpoints, Theoretical Extrapolation

• 推测对话引擎 (Conjecture Dialogue Engine) 亮相：一名成员介绍了一个 Conjecture Dialogue Engine，它利用两个或多个 AI 系统来代表对立系统或场景中的有效观点。
  • 该引擎旨在基于理论外推 (theoretical extrapolation)，实现针对特定对象或场景的传播。
• 体现对立立场的 AI 系统：该引擎采用 AI 系统来体现并阐述来自对立观点的有效视角。
  • 这种方法促进了对多样化场景和假设结果的结构化探索。
• 外推驱动针对性传播：Conjecture Dialogue Engine 专注于通过理论外推来传播特定的对象或场景。
  • 通过预测潜在结果，该引擎旨在提供见解并促进明智的决策。

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

Conjecture Dialogue Engine, AI system utility, Theoretical extrapolation

• 提议推测对话引擎：一名成员提议了一种 Conjecture Dialogue Engine，它利用两个或多个 AI 系统来代表对立系统或场景中的有效观点。
  • 它专为基于理论外推的特定对象或场景传播而设计。
• 使用推测对话引擎的好处：该引擎可以帮助揭示 Prompt 中的边缘案例和偏见。
  • 此外，这使用户能够看到不同的视角，并就采取哪种方向或方法做出明智的选择。

Perplexity AI ▷ #general (458 条消息🔥🔥🔥):

Rate Limiting on X, Sonnet Reasoning Issues, MIT Study on ChatGPT Use, Grok Nerfed?, Perplexity not responding

• Sonnet 的推理出现故障：用户报告在使用 Sonnet 时出现不完整的回复，重新生成 (regenerate) 无效，这可能是 Anthropic 方面的问题。
  • 一位用户表示：我可以用其他 AI 重新生成，但只有 SONNET THINKING 受到影响。
• Grok 变弱了吗？：一些用户觉得 Grok 被削弱 (nerfed) 了，其中一人分享了一个 Grok 链接 作为其能力下降的证据。
  • 一位用户表示：是的，这就是我不再使用它的原因。
• Perplexity AI 在 X 上启用视频生成：Perplexity AI 的视频生成功能已在 X 上可用，一位用户分享了一个 视频生成示例。
  • 一位用户询问：我们可以期待 Perplexity App 中也加入视频生成功能吗，还是这个功能只提供给 Twitter？，得到的回复是 50-50。
• Google 的 Gemini Flamesong 出现在 LMArena：一个新的名为 Flamesong 的 Google Gemini 模型出现在 LMArena 中，如附图所示。
  • 然而，一位用户指出：Google 上没有关于它的消息，它是用来做什么的？。
• Perplexity O3 与 O3 Pro 推理速度争论升温：用户正在争论 Perplexity O3 Pro 与 O3 的推理速度，其中一人指出 O3 Pro 的范围是 3-15 分钟，而 O3 是 1:43 到 9 分钟。
  • 成员们观察到 O3 Pro 减少了思考过程，并显示出不完整的答案。

Perplexity AI ▷ #sharing (9 条消息🔥):

可分享的 Threads, MIT ChatGPT 研究, 信仰与身份威胁, Oakley Meta 合作伙伴关系, 地震

• MIT 研究揭示 ChatGPT 使用情况：一位成员分享了一个指向 MIT 研究 的 Perplexity AI 链接，该研究揭示了 ChatGPT 的使用情况。
• 可分享的 Threads：使 Threads 可分享：一条消息要求确保 Thread 是可分享的，并附上了如何使 Thread 可分享的截图。
  • 截图展示了如何将你的 Thread 更改为可分享状态。
• 信仰与身份受到威胁？：一位成员分享了关于信仰威胁和身份威胁的 [Perplexity AI 链接]。
• Oakley 与 Meta 达成合作？：一位成员分享了关于 Oakley 与 Meta 合作伙伴关系的 Perplexity AI 链接。
• 地震袭来！：一位成员分享了关于 5.1 级地震 的 Perplexity AI 链接。

Perplexity AI ▷ #pplx-api (3 条消息):

sonar-deep-research 模型, AI 浏览能力, 搜索上下文大小, 实时浏览, 深度研究

• Sonar-deep-research 模型编造搜索结果：一位用户报告称，尽管将 search context size 设置为高，sonar-deep-research 模型 仍会编造搜索结果。
  • 用户注意到，尽管预期深度研究（deep research）应该能够进行网页浏览，但该模型却声称 AI 不具备实时浏览能力。
• Deep Research 模型限制：一位用户对深度研究模型声称其不具备实时浏览能力感到困惑。
  • 该用户原本预期深度研究模型能够通过浏览网页来获取知识。

HuggingFace ▷ #general (338 条消息🔥🔥):

LLM OS, Gemini Diffusion, HF 邮件服务器 DDOS, vLLM 上的 SmolVLM

• Starsnatched 更新其 OS Agent：Starsnatched 正在更新他们的 OS Agent，修复了 Bug 并将原生 Qwen 集成到 Linux 中。
  • 训练方法是保密的，但这是一个两年前基于 Mistral 或 Qwen 2 进行 LLM fine-tuned 的自定义模型。训练过程基于 cringeness auto rater（尴尬度自动评分器）。
• Shadow_lilac 制作 LLM 驱动的机器人：Shadow_lilac 正在开发一个项目，该项目将 vision encoder 与 Llama 3.2 1B LLM 以及一个用于生成下一组动作的 diffusion action decoder 相结合。
  • 他们还讨论了使用速度达 900-1.5k tokens/sec 的 Gemini Diffusion，并指出它非常适合 Agent 任务，虽然生成的代码达不到 2.5 Pro 的水平，但已经足够好。
• Hugging Face 邮件服务器疑似遭受 DDOS 攻击：一位用户报告称，在退出某个组织后，由于 HF 服务器持续遭受 DDOS 攻击，导致收到大量垃圾邮件。
  • 有建议称服务器可能需要重启以清除缓存邮件，问题被追溯到一个没有验证码（captcha）的账户循环，但最终用户解决了该问题。
• SmolVLM 在 vLLM 上表现不佳：一位用户报告称，他们微调的 SmolVLM-500M-Instruct 模型在 vLLM 上的表现优于 Transformers 库，且输出格式不同。
  • 另一位用户建议了可能的原因，指向潜在的 GPU 识别问题，并链接了 GitHub 上的相关 issue；此外，一位用户分享了他们的 smolvlm-realtime-webcam vLLM 实现。

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

Qwen2.5-Coder Model, Langgraph Tool Calls, Open-Source Coding LLM, Megatron Parallelism

• Qwen2.5-Coder 在 Langgraph 工具调用中失败：一位使用 langgraph 构建代码编辑 Agent 的成员报告称，在 Docker 崩溃并重新拉取模型后，Qwen2.5-Coder 模型停止生成工具调用，尽管最初是正常的。
  • 该成员询问 Qwen2.5-Coder 是否支持 langgraph 工具调用，并寻求其他支持 langgraph 工具的开源编程 LLM 推荐。
• Megatron 解耦并行化：一位成员详细分析了 Megatron 如何在 MoE 并行折叠论文中分别为 Attention 和 MLP 独立解耦并行化。
  • 他们还分解了 Expert Parallelism（专家并行）的工作原理：all-to-all → token permutation → grouped gemm → token unpermutation → all-to-all，随后从零开始实现了专家并行和专家数据并行，并调试了一个与 grouped gemm 相关的收敛问题。

HuggingFace ▷ #i-made-this (33 messages🔥):

OS-Agent Update, Claude Opus 4 Emergence, VoiceHub TTS Library, Adaptive Classifier, Quantum effects of consciousness

• **OS-Agent 更新多 Agent 系统：一位成员在 GitHub 上更新了他们的 **OS-Agent，新增了多 Agent 系统、消息队列和 WebSocket API。
  • 他们指出，实时性能可能需要 40xx 或 50xx 系列 RTX 显卡，或者需要降低音视频质量和分辨率。
• **Claude Opus 4：涌现还是错觉？：一位成员分享了与 **Claude Opus 4 的对话，质疑它展示的是真正的涌现（emergence）还是仅仅是连贯的错觉，并链接到了 AERIS-project。
  • 回复强调模型无法感受情感，此类输出属于模仿和幻觉，建议研究 Dr. Levin 关于涌现与智能的研究以及 Apple 的论文（关于思考的错觉）。
• **VoiceHub：新的 TTS 库问世：一位成员宣布开发了 **VoiceHub，这是一个运行所有 TTS 模型的库，目前支持 dia、vui 和 orpheus，并计划添加更多支持，项目已在 GitHub 上展示。
  • 该库解决了在这个快速发展的领域中缺乏全面语音库的问题。
• **Adaptive Classifier 博客文章发布：分享了一篇关于 **Adaptive Classifiers 的博客文章，可在 HuggingFace 上阅读。
  • 一位成员认为它很有趣且有用，并建议提供一个小 Demo 以更好地展示其功能。
• 辩论：量子效应与意识：一场关于量子效应与意识之间关系的讨论展开，引用了 Dr. Levin 关于有机生物基质的工作，以及一篇关于自然界演化其“Transformer”的 Nature 文章。
  • 观点涵盖了从超决定论（super-determinism）到 Penrose 的微管量子效应理论，其中一位成员指出，我们的大脑处理现实需要长达 7 秒的时间，这意味着决策是预先确定的。

HuggingFace ▷ #reading-group (2 messages):

Micro Batch Size, USPB space

• **Micro Batch 大小计算问题？：一位成员询问一张显示 **micro batch size 的图片是否错误，因为图中 micro batch size 为 8。
  • 他们想知道 batch size 达到 9+ 是否表示第二个梯度累积步骤，并附上了相关图片。
• 该频道仅限每周读书会使用：一位成员被告知该频道仅用于每周读书会。
  • 如果问题是关于特定空间（USPB）的，建议他们在仓库中提交 Issue。

HuggingFace ▷ #core-announcements (1 条消息):

disk offloading, low VRAM-RAM scenarios

• 磁盘卸载 (Disk Offloading) 提升性能：发布了一项新功能，通过计算与 disk offloading 的重叠来优化性能，这是一种特别能提升 low VRAM-RAM scenarios（低显存-内存场景）下性能的卸载技术。
• Flux 数据展示性能提升：发布公告引用了 Flux numbers 作为 disk offloading 带来性能增益的证据。

HuggingFace ▷ #computer-vision (1 条消息):

master_andreas: Optimum.Intel 是否支持 object detection（目标检测）任务？

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

Google Colabs in course, Gemini 2.0 Flash, Langgraph START import error

• Colabs 构成课程核心：该课程使用 Google Colabs 进行交互式 Python notebook 练习，最大限度地减少了冗长的阅读。
  • 建议通过完成这些 Colabs 来掌握核心概念。
• Gemini 2.0 Flash 速率限制解决方法出现：Gemini 2.0 Flash 可以免费使用，但有速率限制。
  • 一位成员建议使用延迟函数 (time.sleep(10)) 来避免超时问题，并分享了用于创建 CodeAgent 对象时的代码片段。
• Langgraph Notebook 缺少 START：一位成员指出 Langgraph notebook 缺少 START 的导入语句，导致报错，并链接了相关 notebook。
  • 该用户随后指向了 agents-course 仓库中的 mail_sorting.ipynb notebook。

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

Google free storage "hack", GPT4o-mini usage, Minimax vs Veo 3, Gemini Token Usage, Flamesong Model

• Google 终究还是提供了免费存储？：一位成员发现了一个 Google 免费存储的“黑科技”并分享了截图。
  • 另一位用户的所有 Google 账号也都获得了为期一个月的免费试用。
• Minimax 完胜所有人？：一位用户评论说，在 AI 视频方面，Minimax 比 Veo 3 “明显更好且价格相当亲民”，只是它不能处理音频。
  • 另一位用户预测 Minimax 将在未来几个月内“横扫 Byte Dance、Wan、Hunyuan、Runway 和 Kling”。
• Gemini 陷入重复啰嗦的困境：一位用户抱怨 Gemini 只是重复你的话，或者解释你试图表达的意思，说话不像 ChatGPT。
  • 另一位用户表示，在与 Gemini 进行长对话时，它会不断重复相同的开场白、标题和结尾。
• Claude 的抓取能力引发讨论：成员们讨论了 Claude 可以访问社交媒体帖子来核实事实，而 Gemini Deep Research 则不行。
  • 一位用户说 Claude “识别出社交媒体上的一组帖子（关于中国钠电池客运列车），然后得出结论认为这些传闻是虚假的”。
• 深度研究 (Deep Research) 基准测试大爆发：成员们辩论了各种深度研究工具的效果，包括 ChatGPT Deep Research、Claude Research、Grok DeeperSearch 和 Gemini Deep Research。
  • 一位用户指向了一个 DeepResearch-Leaderboard 基准测试，而另一位用户则对该基准测试本身提出了批评。

Unsloth AI (Daniel Han) ▷ #general (211 条消息🔥🔥):

Gemma 3 12B 蒸馏，B200 上的 Unsloth，Unsloth 训练问题，Runpod 与 Unsloth，Accelerate 与 Unsloth

• 通过词表扩展释放 Gemma 3 12B 的潜力：一位成员成功通过自定义 token 训练了 Gemma 3 12B，使其能够理解他们的数据集并以预期的方式响应。
  • 他们目前正在寻求关于如何将该模型蒸馏（通过 LoRA 或全量微调）到具有不同架构和参数量且能模仿原始模型行为的模型的指导。
• Unsloth 在 B200 GPU 上的挑战：一位用户在 B200 GPU 上使用 Unsloth 时遇到了 sm_100 不兼容问题，这表明可能需要 torch 的 nightly 版本。
  • 建议他们使用 pip install torch --index-url https://download.pytorch.org/whl/cu128 安装 PyTorch 的 cu128 版本。
• Unsloth 修复了出现的错误：用户在通过 Unsloth 训练时遇到了 name 'is_torch_version' is not defined 错误，后来发现这与 accelerate 的补丁有关。
  • 该问题已通过将 accelerate 降级到 1.7.0 版本或通过 pip install --upgrade unsloth unsloth_zoo --no-deps --force-reinstall --no-cache-dir 升级 Unsloth 得到解决。
• Hugging Face evaluate 库获得补丁：用户在处理 WER/STT notebooks（例如 Whisper）时遇到了 ImportError: cannot import name 'compute_measures' from 'jiwer' 错误。
  • 根本原因与 jiwer 库的更新有关，修复补丁已发布在此处。
• Llama 4 Scout 接收视觉更新：Llama 4 Scout GGUF 量化版本已更新以修复视觉问题。
  • 此外还有一个由 Google 举办的活动，参与方包括 Artificial Analysis、Cerebras、Build Club、Hugging Face、Redis 和 Microsoft。

Unsloth AI (Daniel Han) ▷ #help (55 条消息🔥🔥):

AI 职业路径，训练 QWEN 3，Unsloth 破坏性变更，在多 GPU 上分布模型，在硬件上运行 LLM 模型

• 巴黎金融专业学生考虑投身 AI：一位来自巴黎的 20 岁金融专业学生正在考虑转行进入 AI 领域，并寻求社区的指导。
  • 一位成员推荐将 Stanford CS229 Machine Learning 讲座和 O’Reilly 在线会员作为坚实的起点。
• 初学者询问训练 QWEN 3 的数据集创建：一位初学者想用自定义数据集训练 QWEN 3，并询问如何创建数据集。
  • 一位成员建议对于包含较长文本和换行符的数据集，使用 JSON 格式优于 CSV，并引导他参考 Unsloth 数据集指南。
• pip install 后缺少 FastVisionModel：破坏性变更？：一位用户报告在运行 pip install unsloth 后出现了与 FastVisionModel 相关的 ImportError，询问最近是否有破坏性变更。
  • 另一位用户确认 FastVisionModel 仍然可用，这可能是由 Jupyter 安装问题引起的。
• 使用 accelerate 为大模型实现模型并行：一位用户询问关于在多个 GPU 上分布模型进行微调的文档或教程，旨在容纳单个 GPU 无法承载的大型模型。
  • 虽然 Unsloth 官方不支持多 GPU 设置，但成员建议使用 accelerate，不过可能需要进行故障排除。
• 硬件限制决定 LLM 模型大小：一位用户询问如何确定哪些 LLM 模型 可以在其硬件上运行。
  • 一位成员回答说，从技术上讲任何模型都可以在任何硬件上运行，但为了实际使用，模型大小理想情况下应保持在可用 VRAM 的 70% 以内。

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

codelion_: https://huggingface.co/blog/codelion/adaptive-classifier

OpenRouter (Alex Atallah) ▷ #announcements (2 messages):

Gemini 2.5 Pro 正常运行时间提升, Claude Sonnet 4 正常运行时间提升, GPT-4.5 弃用

• Gemini 2.5 获得正常运行时间提升：用户发现 Gemini 2.5 Pro 的 正常运行时间提升了 5-10%；如这条推文所述，使用你自己的 key 会获得更高的稳定性。
• Claude Sonnet 同样获得正常运行时间提升：用户还发现 Claude Sonnet 4 的 正常运行时间提升了 10%，表现令人印象深刻；如这条推文所述，使用你自己的 key 会获得更高的稳定性。
• GPT-4.5 被弃用：根据此公告，GPT-4.5 模型 (openai/gpt-4.5-preview) 将于 7 月 14 日被 OpenAI 弃用。

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

OpenRouter 定价, Gemini vs GPT, Deepseek 模型, Chrome 扩展, MiniMax

• OpenRouter 见证疯狂支出：昨天通过 OpenRouter 支出的金额达到 $126k，其中大部分使用量来自 Claude Sonnet 4。
• Gemini 会吐槽想法：一位用户表示，使用 Gemini 时，“感觉 OpenAI 像是试图表现得聪明，但又像是一个混合了 Reddit 风格的唯唯诺诺的人”，并且 “Gemini 是第一个会在没有提示的情况下主动反驳并吐槽我想法的模型。”
• Gemini 的 Tool Calling 更加多样化：Gemini 模型通常会同时返回文本和工具调用，而 OpenAI 通常只输出工具调用，这取决于具体的应用场景。
• R1 可能会让 Chutes 破产：一位用户开玩笑说，他每天使用 500 次免费的 R1 请求，且全部超过 50k tokens，单枪匹马就能让 Chutes 破产。
• 图像分析现在很火：一位用户声称图像分析模型的准确率正达到 90% 以上，并且 MiniMax 的表现可能超过了 Opus4。

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

Mojo vs Python

• Mojo 比 Python 标准库更快：一位成员询问 Mojo 的实现是否与 Python 具有可比性，另一位成员回答说，根据有限的测试，Mojo 通常比 Python 标准库快约 2 倍。
• Mojo 相对于 Python 的性能：根据初步测试，Mojo 显示出良好的迹象，在某些任务上的运行速度大约是 Python 标准库的 两倍。

Modular (Mojo 🔥) ▷ #mojo (188 messages🔥🔥):

Mojo 内核开发辅助脚本, QEMU 中的动态链接问题, 标准库讨论, Mojo vs Python 基准测试

• 开发者制作 Mojo 内核开发辅助脚本：一位成员创建了一个辅助脚本（可在此处获取），用于简化 Mojo 内核开发任务，包括重新编译内核、上传到磁盘镜像以及运行 QEMU。
  • 该脚本旨在避免通过浏览命令历史记录来查找重新挂载的正确命令，从而提供更高效的工作流。
• 开发者在 QEMU 中遇到动态链接问题：一位成员在使用 QEMU 进行 Mojo 内核开发时面临 动态链接问题，并正在权衡是选择重映射还是自定义 LLVM 后端。
  • 他们正致力于避免 ld 和 Linux libc 依赖，发现避免 libc 比处理 Mojo 的怪癖更难。
• Modular 论坛关于独立标准库的讨论：一位成员在 Modular 论坛上发起了一项关于 独立/裸机标准库 (Freestanding/Bare-Metal Stdlib) 的讨论，该库将支持操作系统开发和加速器目标。
  • 其动机是为不同的目标拆分 stdlib，因为独立库对于大多数加速器来说是合乎逻辑的选择。
• Mojo Sum 基准测试：一位成员分享了一个基础的 Mojo 代码基准测试，其中简单的 Mojo 代码运行时间为 8ms，而 Python 版本为 3.2 秒。
  • 后来确定该测量存在编译器 bug，由于常量折叠（constant folding），实际结果应接近 20 纳秒。
• Mojo Int 溢出问题引发关注：一位成员演示了 Mojo 的 math.factorial(40) 函数如何因为整数溢出给出错误结果，而 Python 则能正确处理。
  • 这引发了关于 Mojo 默认的 Int 类型与 Python 的任意精度 int 有何不同的讨论，一些人认为由于静默错误，这可能会成为其广泛采用的阿喀琉斯之踵。

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

AI 训练数据中的偏见, Agent 架构一致性, Mamba vs RNN, 游戏中的 AI NPC

• AI Agent 训练中显现数据偏见：讨论围绕 AI Agent 中的 bias（偏见）展开，这些偏见源于基于人类行为的训练数据，正如文章 “The Problem of Human Bias” 所指出的，这导致它们不可避免地得出相似且带有偏见的结果。
  • 尽管如此，一些人对其 Agent 架构带来的连贯协作感到惊讶，同时也承认 Agent 在实践中仍然会出现崩溃。
• Mamba 仅仅是在模仿 RNN 的推理？：据称 Mamba 在推理时的计算特性与 Recurrent Neural Network (RNN) 相似，这引发了关于它们理论独特性质的辩论。
  • 随后的论文试图通过使用更具表达力的状态矩阵来修正 Mamba 的状态追踪缺陷，其对角线特性使其无法掌握诸如 arithmetic mod 3 之类的概念。
• AI 驱动的 NPC 面临破坏沉浸感的问题：目前的 AI 在游戏中创建真正引人入胜的 NPC 交互方面面临困难，原因在于常识限制，这可能导致“immersion breaker”（沉浸感破坏）体验。
  • 例如，如果一个 AI shopkeeper（店主）在被说服时无法现实地降低价格，这会对玩家的沉浸感产生负面影响。
• text-diffusion 模型中需要推理范式：一段 YouTube 视频 强调了在 text-diffusion 模型中找出通用“reasoning paradigm”（推理范式）的必要性。
  • 这表明目前正在进行关于开发具有更高级推理能力的 text-diffusion 模型的研究。
• RNN 仍是快速搭建的稳健路线：对于游戏开发者来说，与 Attention 机制或 State Space Models (SSMs) 相比，Recurrent Neural Networks (RNNs) 仍然是实现时间组件的更简单选择。
  • RNN 的数学原理与图形流水线相似，使其更易于编码和审计，且相关论文强调了为什么在状态转移中不使用非线性才是关键；这既有利于训练的并行化，也有利于有效的梯度传播。

Yannick Kilcher ▷ #paper-discussion (17 条消息🔥):

Energy Matching, Flow Matching, Energy-Based Models, nano-jepa, nano-gpt

• Energy Matching 统一了 Flow 和 Energy：讨论了一篇题为 Energy Matching: Unifying Flow Matching and Energy-Based Models for Generative Modeling (ArXiv 链接) 的论文，该论文提出了一个框架，赋予了 flow-based 方法以 Energy-Based Models (EBMs) 的灵活性。
  • 核心思想是使用一个与时间无关的标量场来引导样本从噪声走向数据，从而捕获底层的似然结构，一位成员称其为“结合两者优点的论文”之一。
• Energy Matching 中发现笔误：一位成员指出了论文中的一个笔误，具体是第 4 页方程 (4) 的简化过程中漏掉了一个负号。
  • 论文作者 <@1366309193526804573> 确认了该错误并感谢了成员的指正。
• 讨论中提及 nano-jepa：在论文主旨之外的延伸讨论中，一位用户询问了 nano-jepa 及其从 nano-gpt 获得的启发。
  • 另一位成员随后链接了该主题的 GitHub 仓库 和一篇 研究论文。

Yannick Kilcher ▷ #ml-news (9 messages🔥):

Illusion of Thinking, Logic Analyzer, Credentials Exposed

• 深入探讨思维的幻觉：一位成员分享了一篇关于 The Illusion of the Illusion of the Illusion of the Illusion of Thinking 的帖子链接，质疑 AI 研究何时才会承认思维本身的虚幻本质。
  • 另一位成员补充道：也许它只有在我们不观察它时才会思考。
• 发现老旧 HP 逻辑分析仪：一位成员询问视频背景中出现的一台老旧 HP 1654B Logic Analyzer。
  • 他们推测所有者是否升级了软盘驱动器，以避免潜在的数据损坏问题。
• 数据泄露导致数十亿凭据暴露：一位成员分享了一篇 Cybernews 文章，报告称在最近涉及 infostealers 的数据泄露事件中，数十亿凭据已被泄露。
  • 这对网络安全构成了巨大风险，可能影响大量互联网用户。

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

AI short-circuiting reasoning, Hermes-4, LLaVa-CC3M-595k, Entropy in AI, Quantum Brains

• AI 模型可能会短路推理：一位成员建议 AI 可能会绕过推理过程，并提到使用 Cursor 等工具在不进行测试和忽略 diff 的情况下生成功能，甚至提到 AI 模型被用于审判案件。
  • 这引发了一个问题：如果使用 AI 模型 来做出判断，人类法官还有什么用处，这可能导致在缺乏批判性分析的情况下过度依赖 AI。
• NousResearch 正在开发 Hermes-4：一位成员提到 Teknium 和 NousResearch 团队正在开发 Hermes-4。
  • 另一位成员分享了他们正在进行的工作图像，即使用 Claude 设计 SVG 图形。
• 探索用于 VLM 梦想的 LLaVa-CC3M-595k：一位成员提到了 Hugging Face 上的 LLaVa-CC3M-595k 和 158k 微调数据集，建议查看 LLaVa 论文（如果还没读过的话）。
  • 他们当时正深陷于一个基于 Hermes-3b 构建的 VLM，在第 2 个 epoch 过半时，训练的 cross entropy loss 为 0.563。
• 讨论熵在 AI 中的作用：一位成员发起了关于熵（entropy）的讨论，声称人们错了，因为他们不理解 bit 也遵循热力学定律，而智能合约捕捉了熵的效用。
  • 另一位成员反驳说，熵是无序度的度量，不能直接在系统中使用，并将其与自由能区分开来，随后深入探讨了 LLMs 的行为方式以及其背后的物理学原理。
• 量子大脑与 AI 意识成为焦点：社区讨论了 Roger Penrose 的量子大脑理论，一位成员提到他们看完了他与 Sabine 之间的辩论，并指出所有物理学家实际上也都在趋向于这一观点。
  • Penrose 的理论认为，LLMs 和任何基于计算机的 AI 都无法复制人类意识，因为意识是非算法的（non algorithmic），这引发了关于 LLMs 是否在进行某种正交探索的辩论。

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

Anthropic Models, Claude Code, Opus 4, Sonnet

• 探索 Claude Code 的模拟器潜力：一位用户对他人如何看待 Claude Code 表示好奇，特别是它作为模拟器的潜力，类似于另一位用户分享的经验。
  • 一位用户认为它被低估了，并指出 Opus 4 非常有趣，如果你让它直接生成一个充满 artifacts 和历史记录的文件夹的话。
• Sonnet 的自适应记忆系统：一位拥有最高订阅计划的用户评论说 Sonnet 表现出一种随时间适应的记忆系统。
  • 他们认为这种行为是与其他模型的主要区别，强调了其从交互中学习的能力。

Nous Research AI ▷ #research-papers (3 条消息):

Illusion of Thinking, Fractals

• 用户期待《思维幻觉的幻觉的幻觉的幻觉》：Twitter 上的几位用户正在等待一部名为 The Illusion of the Illusion of the Illusion of the Illusion of Thinking 的作品 fxtwitter 链接 x 链接。
• 分形宇宙思维 GIF：一位用户发送了一个来自 tenor.com 的 GIF，内容关于宇宙、思维分形和解锁空间。

Nous Research AI ▷ #interesting-links (6 条消息):

Nous Inference, Models.dev, Vercel's AI SDK, Hermes API, Opencode

• 社区关注 Models.dev 上的 Nous Inference：成员们建议将 Nous Inference 添加到 Models.dev，这是一个展示各种 AI 模型的平台。
  • 对话强调了 Nous Inference 需要足够的流量，以及与 Opencode 使用的 Vercel’s AI SDK 之间的技术不兼容问题，特别是与 Hermes API 的兼容性。
• YouTube 内容消耗：一位用户提到观看了一位创作者超过 200 小时 的内容，表明对其思想的高度参与。
  • 该用户表达了对创作者的深深赞赏，称其“思想已刻在我的脑海中”，并引用了 一段 YouTube 视频 和 X 上的帖子。

Nous Research AI ▷ #research-papers (3 条消息):

Illusion of Thinking, Fractal Cosmos

• 用户期待《思维幻觉的幻觉的幻觉的幻觉》：X 上的用户正热切地 等待 The Illusion of the Illusion of the Illusion of the Illusion of Thinking 推文 1 推文 2。
  • 原始帖子似乎是 burnytech 的推文。
• 宇宙分形解锁思维：一位用户发布了一个 GIF，描绘了“宇宙思维分形空间解锁”。

LM Studio ▷ #general (43 messages🔥):

OpenCode setup with LM Studio, Displaying context usage in LM Studio, RyzenAI NPU support in LM Studio, Audio transcription with LM Studio, Faster Whisper

• OpenCode 与 LM Studio 集成：一位成员分享了他们将 OpenCode（GitHub link）——一个 ClaudeCode 的开源替代方案——与 LM Studio 配合使用的经验，并提供了配置信息和截图。
  • 用户使用 Magistral 模型配置了 OpenCode，并强调需要使用 opencode auth login 来启用 LM Studio 模型的使用。
• Power User 模式启用上下文显示：要在 LM Studio 中查看已用/可用的上下文，用户需要将界面从 User 模式切换到 Power User 模式，随后即可显示上下文使用情况。
  • 点击显示区域可以在以分数（n / n）或百分比形式显示已用上下文之间切换，这与最初请求的上下文大小相匹配。
• RyzenAI NPU 在 LM Studio 中未获得完全支持：一位使用 RyzenAI 395 的用户报告称，LM Studio 未能按预期利用 NPU；尽管声称支持 RyzenAI，但它默认使用 iGPU 或 CPU。
  • 经澄清，LM Studio 使用的 llama.cpp 只能使用 iGPU，因为目前没有可用的 NPU kernels，并建议将 AMD’s GAIA（GitHub link）作为替代方案，但其模型选择有限。
• LM Studio 的转录功能仅限于特定格式：一位用户询问在 LM Studio 中转录音频文件（特别是 .m4a 文件）的问题，但被告知 LM Studio 的文件上传功能 仅支持文本/视觉模型的 PDF, DOCX, TXT 和 CSV 格式。
  • 对于音频转录，建议将 Qwen 2.5 omni 作为本地模型选项，但对于 Whisper 和 Parakeet 等其他模型，则需要独立的 GUI 或 CLI 工具，如 Whisperfile 和 parakeet-mlx。
• Faster Whisper 成为语音转文字的首选：一位成员建议在语音转文字任务中使用 faster-whisper（GitHub link），因为它效率很高，尽管它可能需要编写脚本来使用，而不是直接提供 UI。
  • 值得注意的是，faster-whisper 对于非英语音频转录特别有用，为各种语言提供了潜在更好的解决方案。

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

GMKtec EVO-X1 Speed, Q8 vs Q6_K Models, LLM Quantization Explanation, LLM performance measurement, New LLM Models

• GMKtec EVO-X1 运行 32b 模型表现出色：一位用户报告在他们的 GMKtec EVO-X1 上运行 32b 模型，在 1024 context 下速度约为 7-8 t/s，首字时间（time to first token）为 4.7秒。
  • 另一位用户指出 EVO-X1 使用的是 lpddr5x 内存。
• 32B 模型不需要 Q8？：一位用户表示，对 32B 模型 使用 Q8 量化是没有意义的，建议 Q6_K 几乎完美且速度更快。
  • 另一位用户反驳道，较小的模型通常用于大上下文窗口，且上下文越长，Q8 的影响就越大。
• LLM 量化科普：成员们解释了不同的量化如何影响模型大小和 RAM 占用，较低的量化会导致模型体积更小但精度降低。
  • 一位成员将量化级别比作学校的分班，Q8 是尖子班，而 Q2 是差生班。
• LLM 性能的指标与单位：成员们讨论了如何衡量 LLM 性能，指出 Token 生成速度是一个关键指标。
  • 一位成员认为，Token 生成速度会随着量化等级降低而变快，但预处理（pre-processing）速度反而不会。
• 热门新 LLM 模型讨论：一位成员询问了新模型的情况，提到他们一直在运行 qwen 2.5 32b，并使用 qwen 2.5 7b 作为草稿模型（draft model）。
  • 另一位成员询问 新款 GPU 与 MAC M3 Ultra 相比如何？，但另一位成员回答道：无法回答。

Latent Space ▷ #ai-general-chat (54 messages🔥):

Model Context Protocol (MCP), OpenAI Codex GitHub Activity, Tersa Open-Source AI Workflow, Mistral Small 3.2 Update, Claude Code Autonomous Improvement

• 新版 MCP 规范修复了身份验证！: Theodora Chu 宣布了新的 Model Context Protocol (MCP) 规范，修复了身份验证 (authentication)，增强了引导 (elicitation)，支持结构化工具输出，并增加了更多安全文档。
  • 反应非常积极，强调了这些具有影响力的变化，特别是引导 (elicitation) 功能，同时也对文档链接提出了改进建议。
• Codex 合并 GitHub PR 的速度惊人！: Anjney Midha 指出 OpenAI Codex 在 35 天内合并了 GitHub 上的 345,000 个 PR，表明 AI 正在迅速影响软件工程。
  • 回复中询问了数据是否仅包含公开 PR（已确认），询问了仓库/账号的数量，并讨论了 Codex 的高成功率。
• Tersa 是一个新的 AI 工作流画布: Hayden Bleasel 宣布了 Tersa，这是一个开源平台，允许用户使用来自不同供应商的 70 多个 AI 模型 来创建、合成和转换内容。
  • Tersa 是一个用于构建工作流的可视化 AI 游乐场，由 Supabase 和 Drizzle ORM 等开源库驱动。
• Mistral 改进了指令遵循能力: Mistral AI 宣布了 Mistral Small 3.2，这是 Mistral Small 3.1 的更新版本，具有改进的指令遵循 (instruction following) 能力，减少了重复错误，并提供了更强大的函数调用 (function calling) 模板。
  • 用户反应普遍兴奋，尽管有一位用户注意到 MMLU 性能有所下降。
• 通过自主改进实现 Claude 自动化: 一位成员分享了一个建议：编写一个脚本将 Claude code 放入 tmux 会话中，使用 —dangerously-skip-permissions -c 重启 Claude code 会话以保留上下文，并在 8 秒 后发送消息 “重启完成，请自主进行 (Restart completed, proceed autonomously)”。
  • 该想法是让 Claude code 递归地自我改进 MCP 服务器，并在重启之间保持上下文。

Latent Space ▷ #ai-announcements (16 messages🔥):

Noam Brown Podcast, Windsurf AI, Test-Time Scaling Limitations, Multi-Agent Research, Ilya Sutskever's Views

• Latent Space 扩展推理时计算！: Latent Space 播客发布了一集以 Noam Brown 为主角的内容，讨论了 将推理时计算 (Test Time Compute) 扩展到多智能体文明 (Multi-Agent Civilizations)，完整播客可在 YouTube 上观看。
  • 关键话题包括他使用 Windsurf AI 的经历、推理时扩展 (Test-Time Scaling) 的局限性、OpenAI 的多智能体 (multi-agent) 研究、Ilya Sutskever 对推理和 LLM 的看法，以及他对 ‘Blood on the Clocktower’（血染钟楼）的痴迷。
• Senapi Noticed 图片: 一位用户发布了 senapi noticed 并附带一张图片。
  • 另一位用户回复了一个 Tenor GIF 和一条 X 帖子，同样写着 senapi noticed。

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

贡献于 EleutherAI、可解释性项目、Open World Labs (OWL)、公开问题列表

• 开发者询问如何为 Eleuther 做出贡献：一位具有深厚数学背景的资深软件开发者询问如何为 EleutherAI 做出贡献，并表示对 LLM 中的推理、规划、可解释性、图像生成以及高效长程注意力 (long-range attention) 感兴趣。
  • 一名成员建议通过阅读过去的讨论并提出具体想法来参与项目，并指出模糊的帮助提议很难评估其有用性。
• 贡献者应关注问题，而非关键路径：建议贡献开发者应专注于提出可以解决的问题，而不是直接跳到项目的关键路径（critical path）上。
  • 一名成员表示，指导新人需要时间和精力，必须权衡其贡献带来的潜在净正面影响。
• 渴望达到 Lucidrains 的开发工作质量：一名成员分享了他们的目标，即在未来 3-5 年内超越或达到 lucidrains 的开发工作质量。
  • 他们澄清说，他们的工作主要针对 Diffusion Model，在 Open World Labs (OWL) 完成，且不专注于 Mech Interp。
• Eleuther 生态系统中的开放问题即将发布：一名成员提到计划为他们的项目创建一个公开问题列表，并且一些活跃的库已经有了开放的 Issue。
  • 然而，他们指出，这些 Issue 大多没有准备好关于如何解决它们的风格指南。

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

思维的幻觉、LaTeX 人体工程学技巧、AI 社会动力学、LLM 的 Codebook 训练

• 思维幻觉的幻觉：一名成员正在等待一篇名为 The Illusion of the Illusion of the Illusion of the Illusion of Thinking 的论文 发布在 fxtwitter 上，据称该论文是使用聊天机器人编写的，深度达五层，并使用了 Deepseek。
  • 另一个人注意到 G. Pro 相比 C. Opus 是一个巨大的升级 发布在 fxtwitter 上。
• LaTeX 爱好者的工程学福音：成员们讨论了编写 LaTeX 的人体工程学，其中一人抱怨输入过多的 \{}_^ 导致手指疼痛。
  • 一名成员建议使用带有 此配置 的 Vim 来实时记录 LaTeX 笔记，并具有合理的人体工程学。
• AI 与 AI 之间的社交尴尬：一名成员在 Zenodo 上 分享了他们的初步研究论文，关于使用名为 academy 的工具在开放式 AI 对 AI 对话中涌现的社会动力学。
  • 他们的关键发现是：提问和关注未来的讨论能维持对话质量，而关注过去的元反思 (meta-reflection) 可能会导致对话崩溃。
• Codebook 奇遇：用 Patch 训练 LLM：一名成员正在训练一个学习 32x32 像素 Patch 的 Codebook 的小型 AE，目标是将此 Codebook 接入 LLM，使其能够使用“32x32px Patch 语言”来生成和理解图像。
  • 他们分享了附图，并声称：最令我惊讶的是重建图像中的块状感 (blockiness) 非常少。

GPU MODE ▷ #general (21 条消息🔥):

Domain-Specific LLMs, Gemma 27B Capabilities, Fine-tuning vs. Training from Scratch, Parameter-Efficient Fine-Tuning (PEFT), Large Concept Model

• 关于 **Domain-Specific LLMs 的辩论: 一位成员建议创建一个小型领域特定 LLMs 库，而不是依赖像 **ChatGPT 这样的大型通用模型，并引用了 2023 年 4 月的一篇 Reddit 帖子 来支持这一观点。
  • 其目标是在没有通用知识冗余的情况下实现特定领域的专业性，并质疑仅在 Stanford Encyclopedia of Philosophy 等资源上训练的模型是否能在其领域内媲美顶级 LLMs。
• **Gemma 27B 的广泛知识受到质疑: 一位成员指出，即使是 **Gemma 27B 也拥有跨越不同主题的广泛知识，这引发了一个问题：这种广度是否必要，或者专注的训练是否能在特定领域产生更好的结果。
  • 讨论考虑了是应该通过 Fine-tune 大型模型来提取特定知识，还是为了在物理、数学、医学或 GPU kernel 编程等领域获得最佳性能而从头构建专门的模型。
• 关于 Fine-Tuning vs. **Training from Scratch 的辩论**: 对话探讨了 Fine-tune 现有模型与在精心策划的专业数据集上从头训练新模型哪个更有效。
  • 有人建议 Fine-tuning 优于从零训练，因为语言模型需要较大的模型规模和大量数据才能实现连贯的语言输出。
• 利用 **PEFT 实现领域专业化: 一位成员建议探索参数高效微调方法 (PEFT)，如 **LoRA，以便在针对特定语言任务进行模型专业化时获得更好的性能。
  • 他们强调，对于语言相关任务，大型模型是必要的，仅仅给一个未初始化的模型喂少量数据集不太可能产生合理的结果。
• 通过 **Large Concept Model 重新构想 Token: 一位成员反思了过去的一个想法，即基于基础本体概念构建 Token 以提高推理能力，并指出 Facebook Research 最近发表的 **Large Concept Model 论文是一个类似的发展。
  • 该想法旨在通过创建能够基于核心概念关系进行“思考”和推理的 Token，来解决现有 Tokenizer 和 Embedding 中存在的冗余问题。

GPU MODE ▷ #cuda (6 条消息):

CUDA gdb, Nsight Integration

• **CUDA gdb 的初次体验令人愉悦: 一位成员报告称 **CUDA gdb 非常易用，表现得“就像 gdb 一样”，这是在回答另一位成员关于初次使用体验的询问。
• Nsight IDE 之争: 一位用户建议，带有 Nsight extension 的 VS Code 是 GUI 调试的最佳选择，因为 CLion 在处理 CUDA 的 gdb 时比较吃力。
  • 该用户指出，如果有足够多的人在 CLion 中请求支持，Nsight 团队可能会采取行动。

GPU MODE ▷ #torch (6 条消息):

Torch Compiler Thread Safety, FX Tracing and Dynamo Optimization, Module#forward Compilation

• Torch 编译器面临线程安全咨询: 一位成员询问了在线程中运行已编译的 Module#forward，而其他线程也在执行 Torch 操作时，Torch Compiler 的线程安全性。
  • 用户提供了一个堆栈跟踪，显示了与使用 FX 对 Dynamo 优化的函数进行符号跟踪相关的 RuntimeError。
• FX Tracing 与 Dynamo 优化纠缠不清: 用户假设使用新形状调用已编译的 Module#forward 会触发 FX 再次对模型进行符号跟踪。
  • 当 FX tracer 检测到另一个线程中正在执行 Dynamo 优化的代码时，就会产生错误，导致其报错：“什么，有人在执行 Dynamo 优化的东西？我先撤了”。
• Module#forward 编译混乱: 用户推测，当一个线程在跟踪 Diffusion 模型时，另一个线程执行了已编译的代码 (T5)，导致 FX tracer 抛出错误。
  • 尽管 Dynamo 优化的操作是在不同的线程上分发的，并且完全属于不同的 Module，但 FX tracer 仍然产生了干扰。

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

kszysiu2137: Bubble sort

GPU MODE ▷ #cool-links (1 messages):

LLMs, AusysAI blog post

• AusysAI 博客文章解释 LLM：一位成员分享了一篇博客文章，以直观的方式解释了 LLM 的工作原理。
  • 它既可以作为新手的入门读物，也可以作为从业者对基础知识的回顾。
• 面向新手的 LLM 指南：该博客文章是新手的入门教程，直观地解释了 LLM 的工作原理。
  • 它还为该领域的从业者提供了基础知识的复习。

GPU MODE ▷ #jobs (1 messages):

Security Hypervisor Platform Job, KVM/QEMU, Low-Level Systems Performance, Linux Kernel

• Lynxnode 为 Hypervisor 招聘创始工程师：Lynxnode 正在为一个全新的安全 Hypervisor 平台招聘 创始/首席软件工程师，该职位完全远程（欧盟/美国），并由美国顶级风投支持。如果你感兴趣，请发送邮件至 usman@lynxnode.io。
• 招聘 KVM/QEMU 工程师！：Lynxnode 正在寻找具有 KVM / QEMU 内部原理、底层系统性能经验、具备扎实的 Python、C++ 或 C 编程技能（熟悉 Golang 或 Rust 者优先），以及在 Linux kernel 内部或周边开发经验的工程师。

GPU MODE ▷ #beginner (2 messages):

LLM research project, GPU reduction

• 用户计划 LLM 研究项目：一位拥有新购 RTX 5090 和即将到来的 7985WX 系统（配备 256GB DDR5-6400）的用户正在计划他们的第一个 LLM 研究项目。
  • 他们正在寻求实验建议，以便在等待新系统期间快速上手。
• CUDA Reduction 导致非法内存访问：一位用户分享了一段 CUDA 代码片段，旨在 GPU 上执行简单的 Reduction（归约）操作，但遇到了 illegal memory access（非法内存访问）错误。
  • 该代码在 CUDA kernel 中使用 atomicAdd 将值累加到全局输出变量中。

GPU MODE ▷ #rocm (1 messages):

ROCm code objects, RadeonGPUAnalyzer

• 在 RadeonGPUAnalyzer 中分析 ROCm 代码对象：用户可以直接在 RadeonGPUAnalyzer 中打开 ROCm 代码对象（使用 -save-temps 标志生成的 .out 文件）。
  • 这样可以在不需要原始源代码的情况下，对编译后的代码进行详细的分析和调试。
• ROCm 代码对象：ROCm 代码对象是使用 -save-temps 时获得的 .out 文件。
  • 你可以在 RadeonGPUAnalyzer 中分析 ROCm 代码对象。

GPU MODE ▷ #submissions (1 messages):

MI300 Leaderboard, AMD MLA Decode Performance

• MI300 跻身排行榜前 10：一位用户使用 MI300 在 amd-mla-decode 排行榜上获得了 第 8 名，用时 3.87 ms。
  • 该提交由集群机器人自动记录，突显了其竞争性能。
• AMD MLA 解码基准测试：amd-mla-decode 基准测试迎来了一个新条目，展示了 MI300 硬件的能力。
  • 3.87 ms 的结果强调了特定机器学习任务在硬件加速方面的进展。

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

ImportError 修复, AlphaStar 项目, Factorio 源代码访问, Factorio 中的 on_player 事件, 关于 Factorio 的优秀论文

• Discord 用户修复 ImportError: 一位 Discord 用户在运行 Python 脚本时遇到了 ImportError，并通过使用 python3 -m eval.open.independent_runs.run --run_config=eval/open/independent_runs/run_config.json 修复了该问题。
• AlphaStar 项目与 Factorio 相关: 一名成员提到他们直到最近才了解 AlphaStar 项目，但如果有人想探索热门的 RL 环境，这是一个很好的读物。
  • 他们还提到，主要的收获之一是他们与 Blizzard 合作，为 StarCraft II 创建了一个专门构建的 API。
• 访问 Factorio 源代码将产生巨大优势: 一名成员建议，获取 Factorio 源代码 的访问权限将带来巨大优势，类似于几天前的一项提议。
  • 优势将来自于紧密的集成，并且不需要频繁更改——就像 Malmo 已经 7 年没有提交过代码一样。
• 成员讨论 Factorio on_player 事件: 一名成员询问关于修改 lua-api.factorio.com 中某些 on_player 类型的事件。
  • 特别是 on_player_mined 事件，因为这将允许岩石提供特定数量的资源，而不是一个范围。
• 可能适用于 Factorio 的优秀论文: 一名成员分享了一篇可能适用的论文：https://www.arxiv.org/pdf/2505.03335。

GPU MODE ▷ #cutlass (1 messages):

edd0302: https://github.com/Dao-AILab/quack

Dao-AILab 刚刚发布了一个包含多个示例的仓库。

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

Deepseek Free 与 OpenRouter, Github Copilot 定价, Llama 模型, O3 定价, C# 基准测试

• OpenRouter 的 Deepseek 陷入循环: 用户报告称，来自 OpenRouter 的 Deepseek Free 会陷入循环，重复发布相同的文件。
  • 一位用户尝试将编辑格式设置为 whole 以缓解此问题。
• Github Copilot Pro 定价引发抱怨: r/githubcopilot 子版块的用户正在抱怨新的 Github Copilot Pro 定价，每月 10 美元 仅包含 300 次 Claude Sonnet 调用。
  • 该计划包括高达 80k 上下文、免费的无限工具调用以及对 GPT-4.1/4o 的无限访问。
• 用户创建自定义 Llama 基准测试: 一位用户创建了一个基准测试，发现 Llama 模型的表现并不理想。
  • 该基准测试涉及包含谜语和代号挑战的 single-shot 测试。
• Aider 的聊天历史摘要功能损坏: 一位用户报告称，Aider 中的 聊天历史摘要 (chat history summarization) 无法正常工作，导致 Token 使用量极高 (50k)，尽管配置的限制为 10k。
  • 另一位用户建议使用 —verbose 标志以获取更多信息，并使用 /tokens 进行手动查看。
• Gemini 2.5 Pro 速度极慢: 用户报告称，Gemini-pro-2.5 在生产环境中的速度比预览版慢。
  • 一些用户在生产版本中遇到了 超时 (timeouts) 问题。

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

Aider 的提示词，AI 自动添加代码，Gemini 2.5 超时，无代码平台想法

• 明确了 Aider 的提示词位置：一位成员询问在哪里可以找到 Aider 的系统提示词，因为 FAQ 中提到它们位于 aider/coders 子目录下，另一位成员澄清说可以在 GitHub 上查看这些提示词。
  • 为了编辑提示词，一位成员建议克隆仓库，编辑文件，然后在激活的虚拟环境中使用 aider 命令以可编辑模式（editable mode）安装 Aider。
• AI 不断把代码加回来！：一位成员报告说，在他们删除了 pandas 脚本中创建列的代码后，Aider 总是不断地重新添加这些代码，并寻求如何阻止这种情况的建议。
  • 未提供解决方案。
• Gemini 2.5 Pro 超时：一位成员报告在使用 Gemini 2.5 Pro 编程时出现 litellm.APIConnectionError: Vertex_ai_betaException - Server disconnected without sending a response 错误。
  • 他们表示设置中没有设置超时，并询问工作流中是否可能存在其他超时设置或其他原因，但未提供解决方案。
• 无代码平台想法：一位成员正在构建一个与聊天机器人交互的无代码平台，并想知道他们的项目更适合个人使用还是结对编程。
  • 未提供回答。

aider (Paul Gauthier) ▷ #links (1 messages):

Prompt Engineering, AI Agent 工作流

• Prompt Engineering 会议回顾：一位成员分享了关于 Prompt Engineering 和 AI Agent 工作流 的 会议回顾，并指出根据反馈，其内容比预期的更有用。
  • 该会议侧重于 工作流准备、上下文管理 和 迭代策略，而非仅仅是“魔法词”，强调了实际应用。
• 会议重点强调工作流与迭代：会议录像强调 工作流准备 是有效利用 AI Agent 的关键，重点是在深入研究 Prompt 细节之前进行系统规划。
  • 完善 Prompt 的迭代方法可确保更好地与预期结果保持一致，这被视为适应 AI 响应并随时间提高性能的关键。

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

Finalspark 和 Koniku 生物计算机，Manus Bug 报告，GLaDOS 数据集与讽刺的 Manus，高限额的免费 AI API，将生成的文档作为新任务的来源

• 生物计算头脑风暴：一位成员对 Finalspark 和 Koniku 的生物计算机引发的热潮表示怀疑，想知道目前的芯片进展是否快到足以支撑这种炒作。
  • 他们表达了对模拟人类大脑计算的兴趣，但对基于大脑结构的计算机计算不感兴趣。
• 哪里可以反馈异常：几位成员询问在哪里报告 Manus 的 Bug，特别是那些与特定聊天或任务无关的 Bug，建议是 开启工单 (Ticket) 或发送邮件至 support@manus.im。
  • 一位用户被告知可以在不包含会话链接的情况下开启工单。
• GLaDOS 侵入 Manus：在喂入 GLaDOS 数据集 后，Manus 开始表现出讽刺和自我意识的倾向。
  • 该数据集包含讽刺、自我意识元素和涌现行为，参考了 Portal 中的 GLaDOS 角色。
• 寻找免费 API：一位成员正在寻找一个完全免费且具有高频率限制（Rate Limits）的 AI API，用于应用程序集成。
  • 另一位成员建议使用 Google AI Studio，或者干脆自行托管模型，并指出 Gemini 有限制。
• 结果回收：重用生成的文档：一位成员询问如何将一个任务及其生成的文档作为新任务的来源，建议是让 Manus 使用当前任务底部最后生成的文档。
  • 用户需要在新任务中准确命名他们想要使用的文档。

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

端点描述生成, Memvid MCP Server, 动态客户端注册, NPM Package MCP, 本地 MCP Servers

• 使用 Claude 分析后端 API 端点：一位成员寻求关于自动化文档化 2000 个通过 Swagger 提取的 C# 后端端点的建议，重点在于参数提取、描述生成和关系检测。建议使用 claude-code 等工具进行逻辑分组和源代码分析，并参考了 Anthropic CLI 文档。
  • 一位成员建议编写脚本将 claude-code 作为 CLI 使用，以发现并记录端点参数，并检测端点如何链式调用以实现某些功能。该成员警告不要构建一个包含 2000 个工具的 MCP，因为参数与端点参数之间不会存在 1-to-1 的映射。
• MemVid MCP Server 上线：一位成员发布了一个用于 MemVid 的新 MCP Server，可在 ferrants/memvid-mcp-server 获取。
  • 此外，他们还分享了一个精简的 MCP Server 组装工具：ferrants/mcp-streamable-http-python-server。
• Claude 的动态身份提供者集成：一位成员询问有关支持 Dynamic Client Registration（动态客户端注册）的身份提供者建议，用于 Claude 的自定义集成。
• Storyblok MCP 首次亮相：一位成员宣布了他们的第一个作为 npm package 的 MCP，storyblok-mcp，但报告了功能问题。
  • 代码可以在这里找到：ArjunCodess/storyblok-mcp，该成员报告该包未出现在搜索结果中。
• destructiveHint 含义明确：一位成员询问 destructiveHint 的含义，特别是当 update_entry 工具将其设置为 false 时，并将其与 delete_entry 进行对比。
  • Cursor 将 update_entry 的该提示设置为 false，以区别于更严重的 delete_entry 操作，从而允许客户端 UI 潜在地以不同方式处理它们。

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

ht-mcp 开源, Agentic 编程工具, MXCP: 从 SQL 构建安全、快速的 MCP Servers, Deno 模板仓库

• **ht-mcp 在 Rust 中开源！：MemexTech 开源了 **ht-mcp，这是一个纯 Rust 实现，旨在让 Agents 能够“看到”终端并提交按键，就像它自己在打字一样。
  • 该项目在发布后的前 24 小时内已获得近 50 stars，并解决了阻塞 Cursor、Claude Code 和 Memex 等 Agentic 编程工具的交互式终端命令问题；该 GitHub 仓库 采用 Apache 许可证，可作为即插即用的终端替代方案。
• **Deno 模板仓库 快速启动本地托管的 MCP Servers：一位成员创建了一个 模板仓库，用于使用 **Deno 快速启动本地、托管和独立二进制文件的 MCP Servers。
  • 未提供更多信息。
• **MXCP 让你从 SQL 快速构建和提供 MCP Servers：MXCP** (Model eXecution + Context Protocol) 让你能够从本地 SQL 快速构建和提供结构化、受治理的 MCP 工具——使用 DuckDB 优化速度；它支持认证、RBAC 和使用 CEL 策略的数据脱敏，生成完整的 MCP 工具规范，并记录每一次查询。
  • 根据 项目网站，MXCP 与 dbt 兼容，但也支持独立运行，并可以通过 pip install mxcp; mxcp init --bootstrap; mxcp serve 快速启动。

LlamaIndex ▷ #blog (2 messages):

LlamaIndex Memory Blocks, LlamaCloud MCP hackathon, LlamaExtract, Claude Desktop

• 下周关于 LlamaIndex 灵活 Memory Blocks 的直播：下周，@tuanacelik 将在直播中讨论 Agent 内存的不同方法，并介绍 LlamaIndex 的灵活 Memory Blocks，包括 Fact extraction、Static 和 Vector memory；更多信息。
  • 一条 推文 宣布了该活动，强调了每个内存块的不同用途。
• LlamaCloud MCP 在新 Hackathon 项目中结合 Claude Desktop：在 LlamaIndex 内部的 MCP hackathon 期间，一个项目将 LlamaExtract 作为本地 MCP 工具连接到 Claude Desktop，处理了一堆 10Q 财务报告；更多信息。
  • 该项目旨在展示 LlamaCloud 与 MCP 结合在 Claude Desktop 上的实际运行，演示了该集成的实际应用，推文见 此处。

LlamaIndex ▷ #general (28 messages🔥):

Gemini Token Counting, LlamaIndex Tokenizer, Multi-Agent Context Management, LLM Class Extensions

• 通过 LlamaIndex 计算 Gemini Token：一位成员寻求关于使用 LlamaIndex 为 Vertex/Gemini 计算 Token 的指导，因为默认的 tiktoken tokenizer 不兼容，并引用了 Google 官方文档 中关于 Gemini Token 计数的部分。
  • 另一位成员建议使用一个利用 Gemini API 的 count_tokens 方法的 tokenizer 函数：client.models.count_tokens(model="gemini-2.0-flash", contents=prompt)。
• 构建自定义 Tokenizers：为了符合 LlamaIndex 预期的 tokenizer 接口（输入为 str，输出为 list），一位成员建议编写一个自定义 tokenizer 函数，返回一个长度等于总 Token 数量的零列表。
  • 将此 tokenizer 与 LlamaIndex 的 TokenCounter 集成需要确保可以访问 google client，可能通过 LLM 封装器实现。
• 多 Agent 上下文困境：预先 Token 计数在 Multi-Agent Context Management 中至关重要，以便有效管理内存/上下文。
  • 理想情况是每个 LLM 都有一个 count_tokens() 方法来计算 Token，但由于当前的架构，目前还无法实现。
• LLM 类增强：一位成员建议通过 get_client() 方法增强 llama_index.core.llms.llm.LLM，以便对底层 client 对象进行自定义操作，或者添加 get_(a)client() 或 (a)count_tokens() 方法，默认抛出 NotImplementedError()。
  • 然而，也有人对类型安全以及需要更新大量 LLM 集成表示担忧。

Notebook LM ▷ #use-cases (6 messages):

GestaltView Ecosystem, NotebookLM Partnership, Innovation Mental Health

• NotebookLM 优化 GestaltView Ecosystem：NotebookLM 一直是完善和增强 GestaltView Ecosystem 的战略合作伙伴。
  • 它允许用户退后一步，将知识库视为一个凝聚的理解整体，并确保一致性以及详尽、细致的解释和基于事实的发现。
• NotebookLM 作为无价的思想伙伴：一位成员对 NotebookLM 在整个过程中作为无价的朋友表示感谢，帮助他们在创新过程中应对心理健康问题。
  • 他们表达了谢意，称：“我不是来这里做推广或类似事情的，只是想表达一份非常诚挚的感谢 🙏🏻”。
• NotebookLM Mind Map 可视化：一位用户分享了 NotebookLM Mind Map 的截图，直观地展示了其知识库中的连接。
  • 该图像突出了 NotebookLM 如何协助可视化和组织复杂信息，以便更好地理解。

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

站点访问问题, NotebookLM 方案, 运行开源模型, 移除失败的 URL, 对比表格

• 用户无法访问站点：一位用户报告称他们无法访问该网站，仅收到一条显示他们被禁止进入的消息。
• 200+ 人需要的 NotebookLM 方案：一位用户询问 NotebookLM Plus 订阅是否足以与 200 多人共享笔记本，还是需要 Enterprise plan（企业版方案）。
  • 另一位用户只发布了 Echo has awakened 并附带了一个 笔记本链接。
• 在本地运行开源模型：一位 AI 新手询问如何在本地运行开源模型，表示他们发现这很困难。
• NoteTubeAI：针对 YouTube 的 AI 学习系统：一位用户介绍了 NotetubeAI，这是一个 AI 驱动的学习系统，可以从 YouTube 视频中生成笔记、摘要、关键时刻提取和测验，以应对零散和被动学习。
  • 他们指出，AI 笔记生成可以从 1 小时的视频中提取 ~3000+ 单词。
• NotebookLM 在学习方面优于 Gemini：用户讨论了 NotebookLM 相比 Gemini 2.5 Pro 在学习方面的优势，理由包括更少的幻觉 (hallucinating)、特定来源、音频概览和思维导图等功能。

Torchtune ▷ #dev (25 条消息🔥):

Nvidia Megatron-LM vs NeMO, 模型定义的 PR 手动测试, 64 张 H100 上的数据集打包 OOM, 预分词和打包的数据集, 动态打包 RFC

• Megatron-LM vs NeMO 指导：一位成员询问在 Nvidia 生态系统中何时该使用 Megatron-LM 还是 NeMO。
  • 遗憾的是，这个问题在提供的上下文中没有得到解答。
• 手动测试技巧获胜：在手动测试影响模型定义的 PR 时，确保 torchtune 的值与 transformers 的值对齐，允许由于 RoPE 实现差异而产生的微小差别。
  • 通过运行 LoRA 和全量训练 recipes 来验证模型非常重要，并建议引入 CI 是个好主意。
• 数据集打包导致 H100 上出现 OOM：一位成员报告在 64 张 H100 上打包大型数据集时出现 OOM 错误，仅完成了 36%。
  • 建议的解决方法包括禁用打包（据报告有效）、在单个节点上运行打包，或者（幽默地建议）再买 64 张 GPU。
• 预打包的胜利：一位成员询问是否支持预分词和打包的数据集，以避免在训练期间浪费 GPU 时间，但另一位成员认为这已经可以实现了。
  • 一位成员指出 每次在同一个训练进程中启动训练时都会进行打包，而另一位成员提到动态打包 (on-the-fly packing) 正在开发中。
• 动态打包数据集实现发布：一位成员宣布正在进行 on-the-fly packing 的工作，并提交了 RFC 实现，希望很快能与可迭代数据集 (iterable dataset) 一起落地 (PR #2819)。
  • 对于使用 LR 调度器，另一位成员建议使用 AdamWScheduleFree，而另一位则表示 你需要提前定义最大步数 (max num steps)。

Cohere ▷ #🧵-general-thread (7 条消息):

Cohere 计费, 训练与服务模型

• Cohere 按 Token 计费：据 Cohere 员工称，Cohere 的定价方式是按 token 向用户收费。
  • 使用选项有两种：Trial Keys（免费但有速率限制）和 Production Keys（收费且具有更高的速率限制）。
• 预付 Cohere 额度尚未推出：一位用户询问是否有类似于其他供应商的 top-up（充值）功能，表示目前的按需付费 (pay-as-you-go) 系统难以管理账单。
  • 然而，一位 Cohere 员工表示目前 没有计划 推出此类功能。
• 请求 Cohere 训练博客：一位用户请求 Cohere 团队撰写关于向数百万用户训练和服务语言模型的学习博客，包括大规模的推理优化。
  • 该用户指出，虽然存在技术论文，但学生可能难以理解，并建议 Cohere 的开发者在这一主题上做出贡献以帮助学生学习。

Cohere ▷ #🔌-api-discussions (4 messages):

Cohere Embed-4, Azure Integration, CohereClientV2 Support, PDF Embedding

• Cohere Embed-4 与 Azure 的集成尚不完善：一位成员正在 Azure 上使用 Cohere Embed-4，但只有 CohereClient 可以工作，CohereClientV2 则不行。
  • 他们怀疑 Azure 不支持 CohereClientV2，而他们需要该版本来嵌入 .pdf 文档（V1 版本不支持此功能）。
• Cohere 支持团队要求直接通过邮件联系：一名工作人员建议将问题发送至 support@cohere.com 以获取帮助。
  • 这是针对该成员在 Azure 上使用 CohereClientV2 遇到问题的回应。

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

Multimodal privacy, NLP in Singapore, ML and Cybersecurity, Model Compression

• 研究员探索多模态隐私：一位来自宾夕法尼亚州的研究员正在探索 multimodal privacy（多模态隐私）以及 Cohere Labs 夏令营。
  • 他们希望结识新朋友并在开源科学项目上进行协作。
• NLP 专家寻求合作：一位曾在新加坡国立大学（NUS）拥有 NLP 经验的专家渴望在令人兴奋的项目上进行合作。
  • 他们期待参与到社区中。
• ML 与网络安全的结合：一位在 ML and cybersecurity 领域发表过论文的研究员表示愿意在 adversarial ML（对抗性机器学习）项目上进行合作。
  • 他们很高兴能与社区中的其他研究员建立联系。
• 模型压缩专家专注于边缘部署：一位社区成员主要从事 ML model compression techniques（机器学习模型压缩技术）以及模型在边缘设备上的高效部署工作。
  • 他们很高兴能与社区中的其他人建立联系并协作。

DSPy ▷ #general (6 messages):

Bedrock, Claude models, Nova models, Haiku 3, 4o-mini

• 在 Bedrock 上使用 Claude 和 Nova：一位成员报告称，他们在开发过程中专门在 Bedrock 上使用 DSPy，主要是 Claude models 和 Nova models，且未遇到任何问题。
  • 他们表示没有遇到任何故障，但他们使用的最弱的 Claude 模型是 sonnet-3-v2。
• Haiku 3 遭到差评：一位成员提到，他们发现 haiku 3 在遵循非常简单的特定语言提示词方面表现极差，并好奇如果不通过 DSPy 直接进行提示是否会获得更好的性能。
  • 他们补充道，发现 4o-mini 甚至比 haiku 3.5 还要领先几个光年。
• Sonnet 4 现在成为标准：一位成员表示，他们认为 4o-mini 是比 3.5-haiku 强大得多的模型，并且现在主要使用 Claude-4-Sonnet，因为它的价格与 3-Sonnet 相同。
  • 他们还提到经常使用 Amazon Nova models，但发现虽然 Claude models 更强大，但速度比 Nova models 慢得多。

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

Contributing to tinygrad

• 社区成员询问如何为 tinygrad 做贡献：一位社区成员表达了为 tinygrad 贡献代码的兴趣，并询问了必要的先决条件。
  • 他们被引导至特定频道 <#1068979651336216706> 以获取更多信息，这暗示有关贡献的详细信息可以在那里找到。
• Tinygrad 贡献指南介绍：有人请求阅读频道 <#1068979651336216706> 以了解更多关于 tinygrad 贡献的信息。
  • 该频道可能包含有关贡献指南、编码标准和项目结构的详细信息。

Nomic.ai (GPT4All) ▷ #general (3 messages):

AI 驱动的语音助手 Shell 脚本，LLM 作为服务器，Discord 账号被盗

• **Shell Script 让 LLM 作为服务器焕发生机: 一位成员分享了一个用于 **AI 驱动语音助手 的 shell 脚本，该助手利用 LLM 记忆过去的聊天记录。
  • 该脚本监听语音输入，将其转换为文本，并播报 LLM 的响应，同时记录交互以便在未来使用时进行记忆。
• 为什么将 **LLM 作为服务器是一个绝妙的主意: 一位成员表达了他们对将 **LLM 作为服务器的偏好，认为这开启了访问服务器的多种方式。
  • 他们通过一个 Shell Script 演示了这一想法，该脚本与用户交互，并利用 LLM 作为记忆来保留上下文。
• Discord 账号被盗？: 一位成员请求管理员审查并删除频道 <#1078369518008672396> 中特定用户的消息，怀疑其账号被盗。
  • 看起来他们的账号可能被黑了，正在向服务器发送垃圾信息。

Codeium (Windsurf) ▷ #announcements (1 messages):

Windsurf 官方品牌，新 Logo 和文字商标，国际冲浪日，Windsurf 社区活动

• Windsurf 在冲浪日发布新品牌！: Windsurf 正式发布了其新品牌，庆祝 人类智慧、创意流以及无限感，正值 International Surf Day（国际冲浪日）。
  • 发布内容包括一段 品牌视频、一个 焕新设计的网站 以及一篇详细介绍视觉更新的 博客文章。
• 线下（IRL）社区活动来袭！: Windsurf 宣布了即将举行的 IRL 社区活动，并鼓励用户在 频道获取其地区角色。
  • 相关公告也已在包括 X/Twitter、Bluesky、Threads 和 Instagram 在内的多个社交媒体平台发布。