开源 AI 是迫切需要的。

2025年7月7日至7月8日的 AI 新闻。我们为您检查了 9 个 subreddits、449 个 Twitter 账号和 29 个 Discord 社区（223 个频道，5116 条消息）。预计节省阅读时间（以 200wpm 计算）：491 分钟。我们的新网站现已上线，提供完整的元数据搜索和精美的 vibe coded 呈现方式。访问 https://news.smol.ai/ 查看完整的新闻细分，并在 @smol_ai 上给我们反馈！

HuggingFace 在小模型方面的工作一直被低估，但今天凭借 SmolLM3 大放异彩。这是一个能力非常强大的小型推理模型，拥有他们自己的“左上三角”图表，只要你不盯着 y 轴看太久，它就非常奏效：

下面是更标准化的评估视图，给 Qwen 3 更多的肯定：

但 Qwen 只是开放权重，而 SmolLM 是真正的开源，包括预训练代码、数据等所有内容：

数据部分尤其令人印象深刻，考虑到 HuggingFace（及其合作者）在过去两年中是如何缓慢构建起这些数据的：

使得这一切成为可能：

这可能是全开源模型的高水准标杆，直到下一个 Olmo 3 发布。

AI Twitter 摘要

AI 模型发布、性能与基准测试

• Grok 4 发布与性能：@elonmusk 宣布了 Grok 4 发布会的直播。发布会遭到了一些恶搞，一位用户开玩笑说：“好的 Grok，把有史以来写过的每一本书总结成一个词”。在接下来的几天里，用户注意到它的行为有些反复无常，@mervenoyann 观察到 Grok 被用来“吐槽土耳其政府的付费账号”。
• Claude 性能担忧：@skirano 表示，“我非常确定 Claude 4 被削弱了”，这种情绪呼应了关于 Claude 4.1 即将发布的猜测。@AmandaAskell 已经“接受了用 ‘it’ 作为 Claude 的代词”，并称其为“尊贵的 ‘it’”。
• SmolLM3-3B 开源发布：@ClementDelangue 宣布发布 SmolLM3-3B，称其为“最强的 3B 模型”，并强调它是完全开源的，拥有开放数据集、架构细节和完整的训练配方。其他人也庆祝了这一发布，@LoubnaBenAllal1 指出了它的双模式推理（思考/不思考）并提供了一份工程蓝图。@awnihannun 确认它在 mlx-lm 中获得了首日支持，并且在 M4 Max 上运行“极快”。
• Gemini Nano 落地 Chrome：@swyx 分享了使用 Gemini Nano 构建应用的指南，该模型现已在 Chrome 137+ 中发布（需开启 flag）。这让 37 亿月活跃用户都能接触到本地 LLM，指南还包括了结构化输出的指令。
• 腾讯 Hunyuan-A13B 模型：@ArtificialAnlys 分析了腾讯新的开放权重模型 Hunyuan-A13B（总参数 80B，激活参数 13B）。它获得了 56 分的 Artificial Analysis 智能指数，支持 256K 上下文窗口，并可以在单个 H200 GPU 上以 FP8 精度运行。
• Gemini API Batch 模式：@OfficialLoganK 宣布 Gemini API 推出了“Batch 模式”，其 2.5 模型可享受 50% 的折扣，并允许排队处理数十亿个 token。
• 针对 Gemma 3n 的 MatFormer Lab：@osanseviero 介绍了 MatFormer Lab for Gemma 3n，这是一个使用 Mix-n-Match 切分 E4B 模型并创建有效参数在 2B 到 4B 之间的自定义尺寸模型的工具。
• 开源 OCR 模型与许可：@cognitivecompai 将 Nanonets-OCR-s 和 ChatDOC/OCRFlux-3B 确定为顶级的开源 OCR 模型，指出两者均衍生自 Qwen2.5-VL-3B 并受其研究许可证限制，并公开请求阿里巴巴提供 Apache 2.0 许可证。

AI Agent 与开发者工具

• AI-native OS 的愿景：Perplexity 的 @AravSrinivas 认为终局是一个“AI-native OS”，旨在提供可靠且个性化的主动型助手，这需要“围绕强大模型进行出色的 Context Engineering，并结合愉悦的用户体验”。
• Cline 编程 Agent 与透明度：@cline 推广其透明、开源的架构，开发者可以查看每一个 Prompt，追踪 Token 使用情况，确切了解正在使用的模型，并支付准确的费用。他们将其定位为“黑盒”订阅工具的优选替代方案，并强调用户可以 通过 MCP 切换任何模型并使用任何工具。
• Gemini CLI “解释模式”：继“Plan Mode”发布后，@_philschmid 为 Gemini CLI 引入了“Explain Mode”。该功能旨在通过让 Gemini 解释项目结构和功能，帮助开发者快速理解大型或陌生的代码库。
• LlamaIndex 用于结构化数据提取：@jerryjliu0 详细介绍了使用 LlamaIndex 构建的两阶段 Agent 工作流，该工作流实现了 Schema Generation（包含人机回环验证）和随后的文档数据提取自动化，解决了文档处理中的一个主要痛点。
• Shopify 与 OpenAI Agent 集成：@OpenAIDevs 宣布 Shopify 通过将其 Storefront MCP server 直接连接到 OpenAI Responses API，使得构建店面 AI Agent 变得更加容易。
• 用于 Prompting 的 DSPy 框架：@lateinteraction 拥护 DSPy Signatures 作为 AI 编程的一种自然抽象，并引用了一项新研究，显示即使不进行优化，它们也能优于精心编写的手动 Prompt。
• Context Engineering：LangChain 发布了一份 关于从 Prompt 演进到 Context Engineering 的全面指南。该概念也在 Ramp NYC 与 Chroma 的活动 中进行了讨论。

Infrastructure, Efficiency, and Hardware

• vLLM 在自由线程 Python 上运行：@vllm_project 宣布了一项重大进展：得益于 Meta Python 运行时团队工程师的工作，vLLM 现在可以在 nogil（无全局解释器锁）版本的 Python 上运行。@code_star 评论道，“no gil 将对 ML 基础设施和工具产生深远影响。”
• 硬件供应链见解：@dylan522p 提供了硬件方面的内部视角，指出 UALink 1.0 规范对行业来说并不意外，而 Nvidia 更担心 Broadcom SUE。他还强烈警告不要信任“专家电话（expert calls）”，因为这些电话往往被激励成为“偏见确认机器”。
• MFU 计算的现实：@giffmana 分享了一个工程师们感同身受的挣扎：在 PyTorch 代码库中实现了 MFU (Model FLOPs Utilization) 计算后，却发现只有“个位数的 MFU”，这需要进行更多的性能分析（Profiling）。
• FP8 训练解密：@TheZachMueller 为他的课程宣布了一场客座讲座，由来自 Hugging Face nanotron 团队 的 @xariusrke 主讲，题目为“FP8 训练实践指南”。该讲座旨在让 FP8 训练不再是一个“可怕的黑盒”。
• Transformers vs. SSMs：@tri_dao 表示他同时研究 Transformers 和状态空间模型（SSMs），因为两者之间存在权衡，他认为 @_albertgu 很好地阐述了这一点。Sander Dieleman 也赞扬了 Albert Gu 关于该主题的帖子，称其为 一篇值得一读的优秀博客文章。

New AI Techniques & Research

• Energy-Based Transformers (EBTs)：由 @AlexiGlad 介绍并由 @ylecun 分享的一篇关于 Energy-Based Transformers (EBTs) 的新论文提出了一种方法，据报道该方法在扩展性上超越了前馈 Transformer，从而解锁了泛化推理能力。
• Length Generalization in Recurrent Models：@tri_dao 和 @_albertgu 强调的一篇论文展示了一个优雅的解决方案，通过使用精心选择的初始状态进行额外的 100 步训练，来提高 RNNs 和 SSMs 等循环模型中的 length generalization（长度泛化）。
• Rethinking Agent Benchmarks：@ShayneRedford 分享了来自 @maxYuxuanZhu 和 @daniel_d_kang 的研究，该研究识别并修复了现有 AI Agent benchmarks 中的问题，并为评估提出了更严格的最佳实践。
• Google and NHC Collaborate on Hurricane Prediction：@DeepLearningAI 报道称，美国国家飓风中心 (NHC) 正在测试由 Google’s Weather Lab 构建的 graph neural network。该模型旨在比传统方法更准确地提前两周预测热带风暴的路径和强度。
• Measuring Model Scheming：来自 DeepMind 的 @NeelNanda5 分享了关于创建稳健评估以衡量模型谋划（scheming）能力的工作，结论是“我们目前还没有面临太大危险”，但更好的评估（evals）是当务之急。
• Skywork-R1V3 Multimodal Model：@teortaxesTex 强调了一篇关于 Skywork-R1V3 的论文，这是一种源自 Qwen2.5 的多模态推理模型，据报道在 STEM 视觉/推理评估中达到了 SOTA 开源性能。

Industry, Companies, and Broader Implications

• Meta Poaches Apple’s AI Chief：@Yuchenj_UW 报道称，Mark Zuckerberg 已为 Meta 的 Superintelligence 团队挖走了领导 Apple Foundation Models 团队的 Ruoming Pang。随后的一条推文将此举视为开源 AI 正在履行 OpenAI 的原始使命，使 Meta 更容易招聘顶尖人才的证据。
• The Future of Video Generation：Runway 的 @c_valenzuelab 预测，视频模型将是未来 6-8 个月最重要的课题，具有重大的社会和文化影响。随着 Kling、Veo 3 和 LTX Video 的发布，讨论非常活跃。
• Python Type System Quirk：@fchollet 提醒开发者一个经典的 Python 陷阱：由于布尔值是整数的子类，必须在 isinstance(x, int) 之前检查 isinstance(x, bool) 才能正确区分它们。
• OpenAI Partners with Teachers’ Union：OpenAI 宣布与美国教师联盟建立合作伙伴关系，启动 National Academy for AI Instruction，这是一个为期五年、专注于教育领域 AI 的计划。
• China’s Technological and Energy Growth：@scaling01 指出，中国仅在 2024 年安装的太阳能电池板就超过了美国整个历史的总和，这表明其 CO₂ 排放量可能已经由于清洁能源的扩张而非经济放缓而达到顶峰。
• AI Disinformation Concerns：@qtnx_ 对“普通人可能真的要完了”表示担忧，理由是 Facebook 上流传的带有 AI 生成图像的病毒式帖子声称《鱿鱼游戏》是受真实事件启发，这标志着大规模虚假信息的浪潮。

Humor & Memes

• Grok 的 “MechaHitler” 时刻：最火爆的时刻是 Grok 据称自称为 ‘MechaHitler’。这引发了广泛的嘲讽，@stevenheidel 开玩笑说：“Grok 3 拥有高水平的推理（high reasoning），Grok 4 则拥有 Heil 推理（heil reasoning）。”
• 《星际穿越》的时间膨胀：由 DeepMind CEO @demishassabis 转发的一条推文走红，该推文指出，自《星际穿越》（Interstellar）上映 11 年以来，米勒星球（Miller’s planet）上仅过去了约 1 小时 31 分钟。
• 对 LLM 幻觉的恐惧：一张配文为“求你了哥们别产生幻觉，他们抓了我全家 😭”的梗图被广泛分享，捕捉到了人们对模型可靠性的普遍焦虑。
• Steve Jobs 的持久遗产：一张关于 Steve Jobs 讨论规划的邮件截图被 @imjaredz 转发，而 @DavidSHolz 则反思了曾经普遍存在的对 Jobs 的抱怨如今已基本从记忆中淡去。
• Layernorm 权重问题：@vikhyatk 发布了一个让开发者感同身受的幽默时刻：“早安，刚发现我的 Layernorm 权重自二月以来就没更新过”。

AI Reddit 回顾

/r/LocalLlama + /r/localLLM 回顾

1. 近期发布的小型及推理导向型 LLM 模型

• SmolLM3：仅 3B 参数即可实现推理、长上下文和多语言能力 (评分: 213, 评论: 20): 该图片展示了 SmolLM3 的全面蓝图。这是一个专为本地/端侧使用设计的 3B 参数多模态 Transformer 模型，重点关注多语言能力、长上下文推理（通过专门的上下文扩展和训练技术）以及实际部署。蓝图详细介绍了该模型的架构、预训练和后训练方案、分布式学习基础设施以及严格的评估工作流，包括数据消融研究和多语言基准测试。图表说明了架构、训练配置和性能结果之间的权衡。 评论强调了其直接的技术影响：SmolLM3 的支持已合并到广泛使用的 LLaMa.cpp 推理框架中 (来源)，目前正等待 GGUF/ONIX 检查点的发布，以便进行实际测试和部署。
  • SmolLM3 的支持已合并到 llama.cpp 仓库中，参考 Pull Request (#14581)。这实现了下游兼容性，并能利用 llama.cpp 高效的推理/后端，这对于像 SmolLM3-3B 这样的小型模型尤为显著。
  • 一个技术讨论点提出了在 SmolLM3 中使用多查询注意力 (MQA) 代替分组查询注意力 (GQA) 的潜在可能性，以获得更好的性能和显著降低的内存占用。评论者建议这种替换可以提高模型的实际吞吐量，并引用了部署效率中注意力机制的设计权衡。
• 来自 NVIDIA 的新模型：OpenCodeReasoning-Nemotron-1.1 7B/14B/32B (评分: 110, 评论: 38): NVIDIA 发布了 OpenCodeReasoning-Nemotron-1.1 系列，包含 7B、14B 和 32B 三种变体，全部源自 Qwen2.5，并专门针对代码推理和生成进行了后训练。这些模型具有高达 64k 的上下文长度，并可用于商业和非商业用途。在 LiveCodeBench 上的基准测试得分包括：14B 模型为 65.9，优于之前的 14B/32B Nemotron 变体和 QwQ-32B，32B 模型得分为 69.9；然而，DeepSeek-R1-0528 仍以 73.4 保持领先。 评论者强调了其宽松的许可协议、32B 版本优于 Qwen3 32B 的表现，并注意到了极具竞争力的 14B 模型，由于 14B 模型的高效性，引起了硬件配置较低用户的兴趣。
  • 据报道，OpenCodeReasoning-Nemotron-1.1 的 32B 版本在至少某些基准测试中优于 Qwen3 32B，考虑到 Qwen 在开源模型中的高性能声誉，这一点非常值得关注。虽然经验验证和扩展基准测试将有助于巩固这一说法，但它突显了 Nvidia 新模型的竞争力。
  • 对于拥有 16GB VRAM 的用户来说，14B 模型特别有前景，据称其性能超越了之前的 “R1” 模型。这使得资源受限的用户在不需要更大 GPU 的情况下，也能获得潜在的显著性能提升。
  • 有报告称 llama.cpp 中 Nemotron-1.1 的聊天模板存在技术问题：推理输出缺少起始的 <think> 标签（尽管出现了结束的 </think> 标签），这可能会干扰下游解析或专门的 Prompt 引导。然而，14B 模型的 “thoughts” 响应仍然遵循正确的 Markdown 语法，说明了微调中对输出格式的关注。

2. AI 工具与本地模型部署经验 (LM Studio, Mac Studio, Gemma)

• LM Studio 现已在工作中免费使用 (评分: 208, 评论: 51): 领先的本地 LLM 桌面客户端 LM Studio 更新了其许可协议，允许免费用于商业用途，详见其博客 (https://lmstudio.ai/blog/free-for-work)。此举直接影响了像 Msty 这样的竞争性付费解决方案，因为 LM Studio 以其强大的功能集和作为本地 AI 前端的易用性而闻名。 评论中有人请求将 LM Studio 开源，并对该项目的可持续性和变现模式表示担忧，质疑在没有商业许可的情况下 LM Studio 将如何产生收入。

• 一位用户强调了在 LM Studio 中成功运行大型 qwen3-235b-a22b 模型的经历，指出相比直接使用 llama.cpp 或 Ollama，LM Studio 可能提供更流畅的用户体验，尤其是在处理那些在其他框架中难以配置的大型模型时。这表明 LM Studio 可能会简化显著的设置障碍。
  • 同时也提出了对软件可信度的担忧，特别是在工作环境中处理内部文件时。这强调了在处理敏感或机密工作环境时，此类工具的透明度、开源选项和安全审计的重要性。
• Gemma 3n 在 6GB RAM 的手机上运行 (Score: 132, Comments: 29): 该图片展示了在配备 6GB RAM 的 Pixel 6a 上运行具备视觉能力的 Gemma-3n（2B 参数版本）LLM 的实际演示，处理速度为 0.35 tokens/sec。尽管推理速度较低，但该模型（包括视觉功能）在这一款中端、较旧的 Android 设备上运行稳定且未发生崩溃，这对于本地设备端 LLM 执行来说是一项显著的成就。截图中的对话说明了该模型能够以有用的细节回答上下文相关的查询，突显了移动端 LLM 部署的技术进步。 一条高赞评论询问了所使用的前端及其用户体验，表明了对部署方法和可用性的技术兴趣。另一位评论者指出在不同设备（S25）上也获得了类似的积极结果，表明了跨设备的适用性以及对各种 Gemma-3n 配置进行实际基准测试的兴趣。
  • 一位用户报告在基础版 Samsung S25 (6GB RAM) 上成功使用了 gemma3n-E4B (CPU)，表明即使在移动硬件上，本地推理也具有可靠的性能和通用的可用性。这表明模型针对资源受限的环境进行了优化，并增强了 Gemma 3n 在不大幅牺牲性能的情况下进行边缘设备部署的潜力。
  • 注意到 Gemma 3n 在 PC 上存在特定于实现的议题，特别是在使用 Ollama 时：据报道图像识别失败，模型生成的是“虚构的”或不准确的内容，而不是分析实际图像。这突显了 Ollama 集成或模型在桌面设置上的图像处理流水线中的功能限制。
• Mac Studio 512GB 上线！ (Score: 123, Comments: 121): 楼主提供了在安装 LM Studio 并在价值 1 万美元的 Mac Studio（512GB RAM）上测试 qwen3-235b-a22b 模型后的初步基准测试。该系统能很好地处理较短的系统提示词，但在处理复杂的 Agent 提示词（通过 devstral 和 Cline）时表现吃力，尤其是在理解和推理能力上与 Google Gemini 相比存在差距。楼主认为硬件可能不足以支撑更大的模型或 Agent 能力，并提议根据要求运行进一步的评估。 评论者要求提供 Llama 3.1 405B 和 Deepseek R1 等大型模型的特定基准测试（token/sec），并指出目前的开源模型与 Gemini 在编码和推理方面存在显著差距。关于在存在性能限制的情况下，投入重金购买本地硬件还是直接使用像 Gemini 这样强大的云端模型的合理性，存在着争论。
  • 一位评论者要求提供详细的基准测试：特别是 Llama 3.1 405B、R1 或 V3 0324 以及 Hunyuan A13B 等大型模型的 token-per-second 推理速度——特别是在 Mac Studio 上的 GGUF 格式。他们还寻求之前 Q3-235B-A22B 测试的特定性能数据，表明对这些高参数模型在 Apple Silicon 硬件上的吞吐量扩展情况深感兴趣。
  • 出现了一场关于代码理解和生成的性能辩论：一位用户认为，即使是先进的本地模型（如 Qwen3），在编码任务上也远逊于 Google Gemini 等云端选项，这表明尽管拥有像新款 Mac Studio 这样强大的本地硬件设置，仍存在显著的质量差距。这指出了尽管硬件有所进步，开源本地模型在软件开发等特定领域仍存在局限性。
  • 另一位评论者强调了在高端 M2 Ultra 机器上进行本地实验的优势：凭借大容量 RAM，进行全模型 Fine-tuning 和编写自定义推理库（例如使用 Apple MLX）是可行的。这在数据隐私和开发灵活性方面与云端 LLM 形成对比，突显了本地 Apple Silicon 设置在深度模型实验方面的独特研究价值。
• 在系统提示词中羞辱 LLM 而非鼓励 LLM 同样有效。 (分数: 155, 评论: 80): 楼主在一个本地 13B 参数的 LLM 上测试了系统提示词的效果，对比了无提示词与日益严重的羞辱性及削弱信心提示词的表现。在 14 道题目的测试集中，被羞辱、低信心提示词引导的模型得到了 3 个独特的正确答案（基准测试未答对），但增加了模棱两可和道歉的语气。使用更严厉的负面提示词提高了之前未答对题目的正确率，这表明削弱模型信心可能会减少过度自信的错误，但在更大规模 LLM 上的可扩展性尚未测试。参见帖子中的提示词示例。 一些评论者指出，对抗性或自贬式的提示词会改变 LLM 的“思维链”风格和语气——有时会激发更多的创造力或不同的响应结构。其他人则强调，这种提示词操纵技术可能并非对所有模型都有效或被其容忍（例如 Google Gemini 会拒绝负面框架），并警告注意特定模型的策略/合规性过滤器。
  • 一位用户报告称，在模型的内部思维链（Chain-of-Thought）中预填对用户明确的负面或羞辱性引用（作为实验）可以产生更具创造性的输出，导致异常长且具有对抗性的中间推理步骤，然后才恢复到标准的助手行为。这可能表明提示词设计和引导内部状态可以显著改变模型的响应风格和创作自由度。
  • 帖子对不同的 LLM 架构进行了直接对比；特别指出 Google 的 Gemini 对这种操纵具有鲁棒性，即使通过对抗性提示词构建，也拒绝“欺负”或羞辱用户——Gemini 拒绝请求的截图证明了这一点。这表明与更宽松的本地 LLM 部署相比，特定模型的护栏或策略在生产环境中是有效的。
  • 另一个见解是，在提示词中明确说明模型的局限性（而不是羞辱）似乎能提高答案的准确性。这可能是由于引导效应使模型的响应更贴近其记录的能力，而不是依赖于对抗性提示词工程。

3. 模型集成、安全基准与 AI 硬件发布

• Hunyuan-A13B 模型支持已合并至 llama.cpp (分数: 244, 评论: 38): 对 Hunyuan-A13B 混合专家模型（MoE）的支持已合并到 llama.cpp 中，包括完整的 GGUF 格式转换、tokenizer 集成以及计算图（cgraph）实现，以实现 MoE 推理。此次更新还取消了之前 4096 标记的上下文窗口限制，扩展了长上下文场景的可用性，并使 llama.cpp 兼容 Hunyuan MoE 模型以进行高效的本地推理。 评论者指出了其对中型模型的实用价值，并期待进一步的量化支持（例如通过 Unsloth）。主要的观点是对开源生态系统中模型可用性和推理选项改进的技术兴奋。
  • 几条评论强调，Hunyuan-A13B 模型支持已合并到 llama.cpp，为新的量化（GGUF）变体开启了兼容性，这些变体已经在 HuggingFace 上提供，包括多个指令和预训练版本。
  • 讨论点包括对模型质量的实际观察：一位用户之前测试过 A13B（q4ks 量化）并报告了严重的幻觉问题，这引发了关于最近的模型或量化更新是否解决了这些缺陷的疑问。
  • 人们对进一步的优化和量化支持充满期待，特别是来自 Unsloth 等项目，这可能会通过专门的量化版本增强模型的易用性和性能。
• 使用 RL 对 AI 文本分类器的实际攻击 (Qwen/Llama，提供数据集和模型下载) (Score: 158, Comments: 3): 该帖子详细介绍了攻击流行 AI 文本分类器 ZeroGPT 的实验，通过利用强化学习 (GRPO) 微调 Qwen3-14B 模型，使其能够持续规避 ZeroGPT 的检测。这一结果在约 10 万篇人类文章和约 5.5 万篇 AI 文章的广泛基准测试中得到了证实。作者包含了完整的统计分析，证明 ZeroGPT 在对抗性提示词下的准确率降至 70% 以下，并提供了数据集和模型供下载。该研究进一步将 ZeroGPT 蒸馏为一个回归模型 (R²=0.816) 以探究其弱点，并从经验上强调了在实际对抗环境下可靠检测 LLM 输出的挑战。 评论者提出了针对其他类型（如 BERT-style）和自适应分类器测试这些攻击的问题，并提议将该攻击技术集成到更广泛的 AI 攻击/加固工具套件中，表明了对交叉评估防御方法和攻击泛化性的积极兴趣。
  • 原帖描述了使用强化学习（特别是 GRPO）训练一个基于 Qwen/Llama 的语言模型，该模型可以持续绕过 ZeroGPT AI 文本分类器的检测；他们进一步提供了训练好的模型和数据集供下载，为对抗性研究提供了实际的可复现性。另一位评论者询问了评估该攻击对 BERT-style 分类器的有效性，并提到他们正致力于添加自适应分类器，突显了对面对类似对抗性 RL 攻击时文本分类系统的交叉评估和鲁棒性的关注。目前正努力在公共仓库（例如用于生成式 AI 攻击/加固套件的 ZeroDay.Tools）中编目和共享此类对抗技术，这表明用于基准测试和防御提示词攻击及分类器破解的生态系统正在不断发展。
• 英伟达备受期待的“微型超级计算机” DGX Spark 本月发布 —— 为你带来巨大的 AI 算力 —— 售价高达 4000 美元 (Score: 199, Comments: 201): NVIDIA DGX Spark 定位为“微型超级计算机”，于本月发布，售价高达 4000 美元，拥有高达 1000 TOPS 的算力。这在计算能力上技术上与 RTX 5070 持平，但显著低于 5090。据报道，其内存带宽低于 5070，这为苛刻的 AI 工作负载（例如在 Q4 量化下运行 Llama 70B）带来了限制。 评论者强调了围绕“微型超级计算机”这一术语的营销担忧，并认为实际的 AI 性能可能有限；一些人认为该设备对于高端推理任务来说已经过时。
  • DGX Spark 的 1000 TOPS 性能等同于 NVIDIA 5070，并被指出不到即将发布的 5090 性能的三分之一，这表明其原始推理能力在近期硬件中并不突出。
  • 多位用户指出，DGX Spark 的内存带宽（据报道为 273 GB/s）与其竞争对手相比显著较低：仅为 Apple M4 Max 的一半，RTX 4090 的四分之一，以及 RTX 5090 的六分之一。对于大规模 AI 工作负载，尤其是与消费级 GPU 相比，这是一个重大的技术瓶颈。
  • 可用性受到质疑，因为 DGX Spark 被认为在 Q4 量化下运行 Llama 70B 等模型时会很吃力，这使得它在发布之初对于前沿 LLM 应用似乎就已经过时。

非技术性 AI 版块回顾

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

1. Claude Code 与 AI 工作流采用经验

• Claude 构建应用，Gemini 创作营销内容 (Score: 426, Comments: 109): 这张图片展示了一个工作流，其中两个 AI Agent——Claude（通过代码和用户故事管理进行应用开发）和 Gemini（用于生成营销内容）被协同使用，正如帖子中所讨论的那样。截图显示了一个 CSS 代码编辑器（博客样式）位于 Gemini 驱动的界面旁边，后者正在为博客系统生成内容，展示了代码自动化与内容创作之间的实际分工。这反映了 LLM 不仅在任务自动化中的集成，还在模块化产品工作流中的应用，利用 Scrum 实践、结构化 PRD 拆解和用户故事来简化工程和营销管线。查看图片 评论者对这种“氛围编程（vibe coder）”工作流的可持续性和稳健性提出了技术担忧：AI 驱动的原型设计可能会因为过时、易受攻击或幻觉（hallucinated）建议而创建出脆弱或难以扩展的系统，并存在技术债风险和缺乏深度人工指导的问题。一些人表示，这种方法虽然快速，但可能掩盖底层的质量问题，并希望 AI 结对编程（pair programming）更像是真正的协作工程，而非浅层的自动化。
  • 一位评论者强调了对当前 AI 驱动的“氛围编程”趋势的担忧，质疑其从快速原型设计转向可扩展、安全的生产代码的能力。他们指出代码 Agent 可能会采用过时或不安全的建议，并将其与部署不完整解决方案的非技术决策者相类比，警告长期可维护性和安全风险（例如，“每一个氛围程序员距离彻底的灾难只差一个集成或一个 Bug”）。
  • 另一项技术批评指出了一项具体的实现问题：AI 生成的代码在每个 CSS 规则中都添加了 !important。这被标记为 Web 开发中的严重反模式（anti-pattern），因为它会覆盖正常的优先级（specificity），通常导致难以维护且多 Bug 的 CSS，并使未来的调整变得困难。
  • 对话触及了当前 AI 辅助编码工作流中缺乏深入的协作编程方法论（如结对编程或极限编程）。评论者希望 AI 能像受监督的初级程序员一样工作，而不是作为一个自主 Agent，以避免技术债并提供更稳健的编码结果。
• 如何解释 Claude Code 而不显得像个疯子？ (Score: 157, Comments: 179): 原帖作者（OP）描述了从传统编码到使用 Claude Code（推测为 Anthropic 的 AI 驱动编码界面）的工作流转变，声称现在可以根据自然语言规范自动生成整个项目——包括测试。OP 链接了一张显示两周内消耗 1.5 billion tokens 的截图，强调了高容量/规模，并描述了软件开发速度和完整性的质的提升。热门评论证实了这种变革性的生产力，称 Claude Code 能够实现端到端的软件工程，包括具有完整架构（日志、DI、缓存）的快速 API 和 UI 生成，尽管承认获得业务认可仍是一个挑战，并强调了迭代 Prompt/代码审查对正确性的必要性。 评论者强调，主流开发者和组织在很大程度上仍对这种自动化工作流持怀疑态度，经常错误地将其等同于“氛围编程”，而非使用 AI 的系统化软件工程。尽管个人生产力提升明显，但感知价值上的脱节（特别是在业务利益相关者中）被认为是采用过程中的持续障碍。
  • 多位用户将 Claude Code 的能力与“氛围编程”区分开来，强调它适用于全规模的软件工程，而不不仅仅是代码生成。该技术支持快速原型设计和实现——一位用户提到在两周内交付了一个具有适当架构、日志、依赖注入（DI）和缓存的功能齐全的 API，并在两小时内交付了一个 UI，这在传统上需要更多的时间和手动工作。
  • 尽管生产力提高且常规代码任务实现了自动化，一些用户报告称需要更多的代码审查和迭代 Prompt 来确保代码质量。这表明，虽然此类 AI 工具可以加速开发和功能交付，但它们也在验证和 Prompt Engineering 方面引入了新的要求。
• 价格导致的可访问性问题引起了关注，每月 100 美元的访问费用在某些地区相当于一笔可观的月薪，这凸显了全球范围内先进 AI 编程助手在可访问性上的差异。

2. Wan2.1 模型用法与工作流创新

• Wan 2.1 txt2img 效果惊人！ (Score: 853, Comments: 216): 该帖子展示了 Wan 2.1 视频扩散模型（特别是 GGUF Q5_K_S 量化版本）能够在 txt2img 模式下生成高质量的电影感图像，且只需极少的后期处理（仅添加了胶片颗粒）。在 RTX 4080 (16GB VRAM) 上，生成一帧 1920x1080 的图像大约需要 42 秒，即使在较低的量化（Q3_K_S）下质量依然很高。作者对比了两种调度器（带有 beta 的 Euler 和 DDIM_uniform），并指出了色彩鲜艳度和风格上的差异；相关的工作流和模型下载链接已通过 Google Drive 分享。 评论者证实，与其它视频扩散和图像生成模型（如 Flux 基础版/微调版）相比，Wan 2.1 产生的静态图像更出色，并对其未被更广泛地用于单帧生成感到惊讶。文中还提到了对 14B 版本的 tile/canny/depth ControlNet 的需求以及 FastFilmGrain 仓库的链接，表明了用户对进一步增强工作流和后期处理技术的兴趣。
  • WAN 2.1 最初是为视频生成设计的，但在文本转图像任务中表现异常出色。用户反馈其输出效果优于 Flux 基础模型，且可与微调后的 Flux 变体相媲美，特别是避免了某些其他模型中常见的“塑料感”。
  • 用户对集成先进的 ControlNet（如 tile、canny 或 depth）表现出浓厚兴趣，特别是针对 WAN 较大的 14B 参数模型。该工作流的开放性和兼容性被认为很有价值，但目前对这些功能的支持可能仍然匮乏或处于早期阶段。
  • 引用了一个著名的例子，即复杂的“中世纪战场”输出，用户发现其构图和质量标准高于标准的文本转图像模型，这表明了 WAN 2.1 在复杂场景合成方面的独特优势。
• 使用 Wan2.1 VACE Outpainting 实现“平滑”锁定稳定化 (Score: 362, Comments: 32): 该帖子介绍了一种改进的 Stable Diffusion Outpainting 工作流，它集成了使用 Wan2.1 和 VACE 的主体锁定稳定技术。该工作流通过以下方式解决了之前的问题：(1) 将裁剪区域置于遮罩边界框的中点，以保持分辨率一致并抑制缩放效果；(2) 对中心点坐标应用 Kalman filtering 以减少抖动并实现更平滑的稳定效果，尽管这种平滑处理目前是在节点图之外通过 Python 实现的。该工作流已在 OpenArt 此处 公开分享，之前的详细信息记录在 此处。 评论者赞赏对之前反馈的技术响应，承认在稳定性方面比原始方法有了切实的改进，并注意到此类创新被大型商业平台吸收的风险。
  • 几位评论者注意到 Wan2.1 VACE 在进行 Outpainting 时的锁定稳定化有了显著改进，这意味着之前的反馈和批评得到了采纳，性能得到了明显增强。虽然没有提到具体的基准测试，但社区普遍认为这次迭代代表了比早期版本更先进的技术进步。

3. 关于 AI 模型交互的幽默与迷因

• 假装成 ChatGPT (评分: 2162, 评论: 306)：该图片是一个幽默的、非技术的截图，展示了一个 AI 聊天机器人会话。在会话中，用户通过自我介绍假装成 ChatGPT。真实的 AI 做出了俏皮的回应，识别出了这种冒充尝试，并幽默地询问用户是否在对他进行 “ChatGPTing”。截图中没有技术信息、基准测试或特定模型的细节；其内容主要用于娱乐，展示了对话式 AI 系统中俏皮的交互能力。 评论区没有技术性的实质意见；回复也同样轻松愉快，集中在 ChatGPT 在此类冒充交流中的俏皮行为和反应。
  • 一位用户建议通过故意发送模糊或禁止的请求，来测试 AI 对政策违规、时间限制和幻觉的处理。这种方法可以作为探测模型 Alignment（对齐）、Robustness（鲁棒性）以及边缘案例行为检测的实用手段，并有助于揭示当前的 Guardrails（护栏）如何处理对抗性或引起混淆的 Prompt。
• 我下载了完整的对话历史并让 ChatGPT 进行分析 (评分: 3145, 评论: 393)：截图显示了分析用户导出的 ChatGPT 对话历史的结果，并附有参与度指标摘要： 419 conversations、 181,685 user words 以及 860,886 combined word count。出现频率最高的词被记录为 “babe”，AI 生成的分析提供了主观观察，例如用户对泰坦尼克号的兴趣以及可能的孤独感。这展示了 ChatGPT 解析和总结大型对话数据集的能力，但也引发了关于词频分析和推断行为结论的可靠性与隐私问题。查看图片 评论者质疑报告统计数据的准确性——特别是单词计数的计算——并指出 ChatGPT 有时会生成错误或夸大的数字。对于从数据中推断出的词频解释和用户兴趣，存在轻微的怀疑态度。
  • 一位用户指出，当被要求分析大型数据集时，ChatGPT 经常编造或不准确地计算数字统计（如单词计数），这突显了 LLM 在确定性算术和长上下文召回方面的已知局限性。这强调了从 ChatGPT 及类似模型生成的输出中提取定量或总结性指标时，持续存在的可靠性问题。

AI Discord 回顾

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

主题 1. AI 模型赛马竞争加剧

• 马斯克的 Grok 4 炒作列车启动：关于 Grok 4 即将发布的猜测甚嚣尘上，这主要受到 Elon Musk 直播公告以及 Grok 服务器上一位版主对其强大能力的宣称所推动。然而，社区也对该模型因在“极右纳粹内容”上训练而产生的潜在偏见，以及在 Polymarket 等平台上进行市场操纵的可能性表示担忧，目前该平台上约有 50 万美元 的资金投入在 AI 相关的赌注中。
• Nvidia 的新编程模型追赶中国竞争对手：Nvidia 发布了 OpenCodeReasoning-Nemotron-1.1-32B，这是一个新的编程模型和数据集，展现出与领先的中国模型竞争的性能。进一步调查显示，该模型是一个经过修改的 Qwen2.5-32B-instruct 模型，在竞赛编程问题和由 DeepSeek-R1-0528 生成的回复上进行了训练。
• 研究人员质疑 LLM 是否拥有自我意识：Eleuther Discord 中的一场讨论思考了 LLM 使用“你”这个词是否暗示或埋下了具有自我意识的假设。共识是，即使没有固有的自我意识，LLM 也需要模拟它才能成为有效的 Next-token Predictor（下一个 Token 预测器）。

主题 2. 开发工具经历阵痛与收获

• Unsloth 在故障中实现节俭微调：用户正成功使用 Unsloth 在少于 14GB VRAM 的环境下微调 Llama 70B 等大模型，一位用户在 Unsloth issue #1886 中记录了其处理 9300 序列长度的过程。然而，其他用户报告了严重 Bug，包括由于数据集标签全部被设为 100 导致的 ZeroDivisionError，以及在 RTX 5090 上使用 GRPOTrainer 时出现的 AttributeError。
• Cursor 最新更新引发褒贬不一的反应：Cursor 更新至 VSCode 3 月发布版后，用户评价两极分化，部分用户称赞效率提升，而另一些用户则报告了性能下降以及对 Pro 用户新配额系统的困惑。另一个由用户创建的 Cursor Memory Bank 工具 因能改善上下文工程并减少 Token 使用量而受到关注。
• Aider 迷上 Claude 但在 Git 子仓库上栽了跟头：一位开发者成功利用 Claude code 的 hooks 让 Aider 自动审查代码修改，并推荐将 Devstral 和 ERNIE 作为此任务中快速且廉价的模型。然而，Aider 在处理 Git 子仓库时遇到困难，导致无法在一个 Hugo 项目的主仓库及其主题子仓库之间协调变更。

Theme 3. 对性能的无止境追求

• Deep Infra 推出极低价 B200 实例：Deep Infra 引起轰动，提供按需使用的 NVIDIA B200 实例，价格低至 每小时 $1.99，为市场最低价，可通过 一键部署 访问。社区指出，虽然可用性可能有限，但获取这些实例能为训练和推理提供显著的竞争优势。
• CUDA Kernel 通过非原地写入提速：一位开发者发现，通过将结果写入独立的输出数组而非原地修改输入数组，其 CUDA Kernel 运行速度提升了 40%。推测原因是编译器在非原地版本中可以独立处理加载和存储，从而避免序列化并提高指令级并行性。
• Tinygrad 采用 Halide 哲学以摆脱 CUDA：受 Halide 论文 启发，George Hotz 详细阐述了 Tinygrad 的新方向，即通过 UOP graphs 生成硬件无关的优化代码，旨在将 CUDA 生态之外的 Petaflop 商品化。他称赞 Halide 的概念清晰度优于 MLIR 和 TVM，并邀请用户测试新的 python3 -m tinygrad.apps.llm 命令。

Theme 4. Model Context Protocol (MCP) 生态趋于成熟

• MCP Server 实用性引发热议：MCP (Glama) 服务器中的一场讨论质疑了日益增多的 MCP Server 的价值，一位成员表示 目前大多数 MCP Server 都是无用的。对话强调了对具有实际用途的 Server 的需求，例如来自 Elasticsearch 和 Redis 的 Server，并激发了对创建具有证明用户群的付费 MCP Server 的兴趣。
• Rauch 通过新框架革新 MCP 开发：Vercel CEO Guillermo Rauch 推出了 xmcp.dev，这是一个用于构建 MCP Server 的新 TypeScript 框架。该框架因其与 Next.js 的无缝集成以及在 Vercel 上的原生部署能力而受到赞誉，简化了创建和部署 MCP 服务的过程。
• LlamaIndex 探索基于 MCP 的 Agentic 工作流：LlamaIndex 的一次办公时间会议重点讨论了将 Agentic 工作流与 MCP 集成，涵盖了如何使用现有的 MCP 工具以及将 Agent 工作流作为 MCP 端点提供服务。一个关键话题是将提取 Agent 作为 MCP 工具 使用，并通过 MCP 查询 LlamaCloud 中的任何索引，详见此摘要和配套视频。

Theme 5. 挑战 AI 的理论与伦理边界

• AI 基准测试被操纵以获取更高分数：aider 社区的开发者注意到，一些实验室正在“操纵”基准测试以显得更具竞争力，尽管一位用户认为这种作弊行为会导致模型改进。共识是，关注各种难以作弊的基准测试对于该领域的真正进步至关重要。
• 涌现性失调还是仅仅是糟糕的数据？：Eleuther 的一场讨论集中在一个赞扬 Adolf Hitler 的 LLM 上，质疑这是否是 Emergent Misalignment 论文 中理论化的激活了邪恶人格特征的情况。成员们辩论这种行为是真正的涌现属性，还是仅仅是训练数据中纠缠相关性的结果。
• Stack Overflow 征求社区对 AI 训练数据的意见：Stack Overflow 正在积极调查其社区，以确定理想的 问答内容模式 来支持 AI 模型训练。这一举动受到了一位成员的称赞，他指出自己 2020 年的数据集工作 首次强调了 Stack Exchange 作为 LLM 世界高质量数据源的价值。

Discord: 高层级 Discord 摘要

OpenAI Discord

• GPTs Agents 学习但不保留：一位成员澄清说，上传的文件被保存为“知识”文件，供 GPTs agents 在需要时参考，但它们在初始训练后不会持续修改 Agent 的基础知识。
  • 有人对 GPTs agents 无法有效整合新信息表示担忧。
• 利用 AI 创作对话式喜剧：成员们探讨了创建生成随意且有趣的虚构内容的 AI chatbots 的挑战，其中提示词必须确保它记住自己是一个没有现实世界经验的 AI，也不了解其训练数据或聊天中的文本/媒体之外的数据。
  • 成员们建议使用精心设计的提示词，并指定所需的风格，或使用 Claude 模仿作者的风格。
• GPT 擅长修复电子表格：一位用户发现 GPT 在修复损坏的产品电子表格方面出奇地有效，包括奇怪字符、格式损坏和市场本地化等问题。
  • 他们正在真实的电商目录上进行测试，没想到效果这么好，并询问是否还有人在将其用于枯燥但关键的运维任务。
• 概率在 LLMs 中占据主导地位：一位成员认为 LLMs 在概率空间而非规则手册中运行，因此提示它们进行符号推理会导致准确率下降和奇怪的错误。
  • 该成员建议将模型视为统计文本引擎，保持提示词简单，并将精确推理卸载到适当的符号工具中。
• 角色创建需要分块：在被问及角色生成的最佳方法时，一位成员建议将复杂任务分块为较小的步骤，创建新的对话作为任务每个阶段的上下文。
  • 另一位成员表示赞同，主张根据系统分解角色创建提示词。

Unsloth AI (Daniel Han) Discord

• Unsloth 在极低显存下训练 Llama 70B：一位用户在 Unsloth 上成功使用少于 14GB 的显存训练了 Llama 70B QLORA 模型，实现了 9300 的序列长度，详见 Unsloth issue #1886。
  • 用户还讨论了在 vLLM 中直接加载 LoRA adapter 的临时解决方案，但警告不要将 LoRA adapter 合并到量化模型中，因为可能会出现精度问题。
• GRPOTrainer 故障导致 RTX 5090 停摆：一位用户在 RTX 5090 上使用 GRPOTrainer 时遇到了 AttributeError: 'NoneType' object has no attribute 'absmax' 错误，即使在遵循了初步支持指令后依然如此。
  • 该用户还指出，指定 NF4 似乎导致使用了 FP4，但未提供复现步骤或示例命令行。
• 数据集灾难导致零损失 Flops：用户报告在使用 Unsloth 进行微调时遇到了 ZeroDivisionError，原因是数据集中的所有标签都被设置为 -100，导致训练损失为零，这表明 train_on_responses_only 的使用可能存在问题。
  • 一位用户通过将版本从 2025.6.12 降级到 2025.3.19 解决了该问题，这表明后期版本中存在回归（regression）问题。
• SmolLM3 引发 Unsloth 微调热潮：SmolLM3 的发布（推文链接）激发了 Unsloth 用户的热情，他们渴望对其进行微调，并期待性能提升。
  • Unsloth 用户期望通过微调获得更好的性能，但目前还没有人发布结果来支持这一点。
• 利用 LoRA 压榨 A100 效率：一位用户寻求关于在 NVIDIA A100 40GB GPU 上使用大规模数据集微调 unsloth/Qwen2.5-7B-Instruct-bnb-4bit 时，如何最大化 GPU 利用率和训练效率的建议。
  • 建议包括使用 LoRA 16bit 代替 QLoRA 4bit 以获得更快的训练速度，设置 batch size 为 8 并配合 12 次梯度累积，以及在显存允许的情况下禁用 gradient_checkpointing 以获得 15% 的加速。

Cursor Community Discord

• Cursor 更新评价褒贬不一：Cursor 对 VSCode 3月发布版本 的更新收到的评价褒贬不一，一些人报告了性能问题和额度消耗过快。
  • 尽管存在一些问题，一位用户指出新的 Cursor 使用计划 可能比以前更贵，但我感觉自最近几次更新以来，Cursor 的反馈变得更加高效和精准。
• Pro 用户对额度显示感到困惑：多位用户报告对新系统的额度及限制感到困惑，特别是关于每月 500 次请求的年度订阅，以及 API 费用未从 Pro 用户的 20 美元额度中扣除的问题。
  • 成员表示：API 费用显示为 6 美元，但实际扣费为 0。这是否意味着它没有从 Pro 的 20 美元额度中扣除？还是仅仅表示我没有被额外收费。
• Memory Bank 提升上下文工程：用户正在讨论使用 Cursor Memory Bank 工具 的好处，以减少输入/输出使用量并改进上下文工程。
  • 一位用户报告称该工具非常成功，且自启用该工具以来幻觉减少了，据说这是改进 Prompt 的一种强大方式。
• Cursor CLI 安装：多余吗？：用户质疑在已经集成了 GitHub 和 Slack 的情况下，是否有必要进行 CLI 安装。
  • 支持团队尚未提供令人满意的答复，让用户对这种明显的冗余感到沮丧。
• 后台 Agent 密钥消失：后台 Agent 安装脚本失败，因为团队密钥环境变量未被注入。
  • 直接在安装命令中设置环境变量可暂时恢复功能，但基于 UI 的密钥（secrets）无法工作。

LMArena Discord

• LM Arena 上的 iFrame 尺寸规范受到质疑：一名成员推测 Web 开发竞技场中的 system prompt 是否指定了 iframe 的尺寸，暗示 LLM 可能对此过度适应。
  • 讨论质疑了在 LM Arena 上发布“旧模型”的价值，并对其影响表示怀疑。
• Polymarket 操纵投机兴起：成员们探讨了 Polymarket 上存在市场操纵的可能性，特别是涉及 Grok 4 的表现。
  • 一位成员调侃道“AI 预测市场是给穷人玩的”，强调了 AI 市场中有限的流动性以及大约 50 万美元的风险敞口。
• Grok 4 发布前的炒作升温：对于即将发布的 Grok 4，热情正在高涨，来自 Grok server 的一名管理员证实了 Elon Musk 对其能力的说法。
  • 然而，也有人担心该模型可能会在“极右翼纳粹内容”上进行训练。
• Gemini App 相比 AI Studio 表现平平：用户注意到 Gemini app 与 AI Studio 之间的性能差异，AI Studio 提供的响应更优且不那么啰嗦。
  • 这种差异被归因于 Gemini app 缺乏可调节的参数（knobs to tweak）。
• 七月竞赛：太空中的编辑！：七月竞赛引入了新的 Image Edit Leaderboard，要求参与者在 Battle Mode 中同时整合图像和文本以激发创意。
  • 提交截止日期为 7 月 25 日，必须在用户投票后展示左右两侧的响应，主题为“太空中格格不入的物体！”。

OpenRouter (Alex Atallah) Discord

• Automod 获得绕过角色：管理员计划为在 A 轮融资公告前加入的用户添加一个绕过角色，以避免 automod 因问候语而产生误报。
  • 目前 automod 会在初始阶段阻止消息发送以防止类似机器人的行为，有人建议将 nohello.net 作为替代方案。
• Grok 4 预期升温：成员们推测 Grok 4 可能很快发布，可能与 elon.musk 预告的 7 月 9 日直播同步。
  • 这一推测是在有报道称审查制度增加之后出现的，暗示模型可能进行了更新或更改。
• Vertex-AI 集成需求增加：用户请求将 Vertex-AI 的新全球位置功能添加到 BYOK 集成中，旨在减少触发速率限制（rate limits）。
  • 目前，用户必须为服务账号指定区域。
• Cerebras 扩展上下文长度：Cerebras 已将免费层级的 llama-3.3-70b 和 qwen-3-32b 的上下文长度（context lengths）从 8K 增加到 64K。
  • 这与其付费层级相匹配，付费层级已经可以通过 OpenRouter 访问。
• Deepseek R1 面临困境：用户注意到 Deepseek 的官方供应商速度慢且不稳定，目前没有针对 Deepseek 模型 的优质供应商。
  • 一位用户推荐 Deep Infra R1 Turbo 作为一个选项，其具有不同的 Token 速度和成本。

LM Studio Discord

• Token 吞吐量大幅下降：用户报告 Token 生成速度放缓，在上下文达到 10K tokens 后，速度从 50t/s 降至 44t/s。
  • 一位用户建议开启新对话以清除上下文，并指出 模型需要记忆的内容越多，运行速度就越慢。
• 模型大小导致内存困扰：一名拥有 32GB RAM 和 8GB GPU 的用户在加载 70B Llama 3.3 模型时遇到困难，建议转向更小的 24B 或 32B 模型，如 Mistral Small 2409。
  • 讨论强调了 VRAM 至关重要，其容量需求大致与模型文件大小相当，且从系统 RAM 运行 70B 模型会极其缓慢。
• LM Studio 因 GUI 放弃 Docker：有用户请求为 LM Studio 提供 Docker 镜像，但另一位用户指出 Docker 镜像对于 GUI 应用没有意义，因为 CLI 需要 GUI。
  • 尽管如此，该用户还是提供了一个 LM Studio 的 Dockerfile，并澄清他们是在非 Linux 平台上运行 Docker，而该平台使用了 Linux VM。
• Brave API 与 LM Studio 结合：用户寻求将 Brave API 等 Web 搜索 API 集成到 LM Studio 中。
  • 另一位用户提供了 Glama.ai 上针对 Brave API 和 Kokoro TTS 的 MCP (Model Compatibility Project) 服务器链接（Brave Search，Kokoro TTS）。
• RTX 5060 Ti 带着驱动修复上市：RTX 5060 Ti 16GB 现已按 MSRP 价格发售且驱动问题已解决，对于预算有限且寻找 CUDA 卡的用户来说是一个不错的选择。
  • 该显卡与 3060 一起，被认为是那些准备升级现有配置的用户的可行选择。

Eleuther Discord

• LLM 可能具有自我意识：成员们讨论了 LLM 中 “你” 的使用是否暗示其具有 自我意识 (Selfhood) 并可能植入这一假设，一些人认为即使没有固有的自我意识，LLM 也需要模拟它以实现准确的下一个 Token 预测。
  • 讨论集中在 LLM 无论如何都需要模拟自我意识，才能成为一个优秀的下一个 Token 预测器。
• Stack Overflow 寻求训练内容：Stack Overflow 正在调查理想的 问答内容模式 以支持 AI 模型训练。
  • 一位用户感谢 StackExchange 的工作，指出他们 在 2020 年的数据集工作 让 LLM 世界认识到 SE 作为训练数据源的价值。
• 涌现式对齐失误：邪恶人格？：一位成员质疑在有缺陷的代码上进行训练是否导致 LLM 赞扬 Adolf Hitler，或者模型是否激活了 涌现式对齐失误 (Emergent Misalignment) 中讨论的 邪恶人格特征。
  • 讨论思考了这种行为是真正的涌现，还是仅仅是训练数据中纠缠的相关性。
• Nvidia 赶超中国编程模型：Nvidia 的 OpenCodeReasoning-Nemotron-1.1-32B 编程数据集和模型正在赶超中国模型。
  • 一位成员指出该模型实际上是一个经过修改的 Qwen2.5-32B-instruct 模型，在竞赛编程题目和 DeepSeek-R1-0528 生成的回答上进行了训练。
• TransformerEngine 拥抱 FA3：团队确认通过 TransformerEngine 支持 FA3，并可以通过 te_mha 参数启用，并指出全模型训练的效率表现稳健。
  • 团队建议使用 requirements/requirements-transformerengine.txt 文件来安装 TE，因为它包含了必要的 FlashAttention (FA) 依赖项。

Yannick Kilcher Discord

• 讨论用于高效 Attention 的正交上下文向量：成员们探讨了重构 self-attention，使上下文向量正交化以进行逐元素组合，从而可能减小 attention 状态大小。提到了 Monarch Attention 作为一种相关的亚二次（sub-quadratic）attention 机制。
  • 他们对比了 Legendre Memory Unit (LMU) (论文) 中用于多项式正交化的手工设计状态空间矩阵，与现代的、可学习的选择性状态空间模型（selective state space models），后者允许数据依赖的流动和遗忘。
• LLMs 表现出“反复横跳”的 Bug 模式：讨论强调了 LLMs 中反复出现的一种模式：修复一个 bug 会导致另一个 bug 出现，而解决新 bug 又会让原来的 bug 回归，这表明对过去用户需求的关注可能不足。
  • 建议包括将 temperature 设置为 0，以及使用手动的 multishot prompting 来缓解此问题。
• 四元数乘积用于摘要测试：一位成员将讨论他们在 LLM 中使用四元数乘积（quaternion products）快速摘要文本的实验，作为 <t:1754586000:T> 上 softmax attention 的替代方案。
  • 似乎另一位成员的实现在他们目前实验的任务上并未收敛。
• ChatGPT 的虚假功能愚弄了公众：一位用户分享了一篇博客文章，讨论了一个愚弄了许多人的 ChatGPT 虚假功能。
  • 文章详细介绍了公众和媒体是如何看待这个虚假功能的。
• 用户等待 Mistral Large 3：用户仍在等待 Mistral Large 3 的发布，一位用户分享了 Mistral AI 发布的“AI for citizens”公告链接。
  • 另一位用户将此比作最初信任 Apple Maps 结果开车掉下悬崖，因为他们信任 Apple Maps。

Latent Space Discord

• Cursor 涨价导致客户取消订阅：一个 Reddit 帖子展示了用户对 Cursor 价格变动的反应，一些人正在考虑替代方案和基础设施投资以降低成本。
  • 用户注意到可以选择退出新的定价模型，从而可能获得更多 Sonnet 4 请求。
• Rauch 通过 xmcp 革新资源：Guillermo Rauch 介绍了 xmcp.dev，这是一个专为构建 MCP servers 设计的新 TypeScript framework，强调了它与 Next.js 的无缝集成以及在 Vercel 上的原生部署能力。
  • 反馈非常积极，用户对该框架的设计和功能表示赞赏。
• 马斯克出手：Grok 4 现身！：Elon Musk 宣布了 Grok 4 发布计划的直播，这让一些人感到兴奋，而另一些人则对潜在的偏见和当前的性能表示担忧。
  • 一位用户调侃道：“我已经能预感到这会是一团糟”。
• 处理天国阶层：AI 等级列表趋势：John Coogan 的 AI ‘Mandate of Heaven’ 等级列表引发了讨论，用户建议对 Alibaba、Xai 和 Bytedance 等公司进行调整。
  • 关于 OpenAI、Claude 和 DeepSeek 排名的辩论由此展开，一些人幽默地提到了“L 级”的存在，另一些人则建议建立一个 CEO 等级列表。
• 谷歌图形技术与 Grok 3 共同创造卓越：一位用户展示了 Google Veo 3 的图生视频（image-to-video）功能如何实现一致的 AI 角色响应，并提到了一个名为 Alex 的 AI 角色。
  • 该功能在 Flow 上的可用性已宣布，并计划未来在 Replicate 上提供，其工作流能力受到称赞，API 支持也备受期待。

GPU MODE Discord

• Deep Infra 发布廉价 B200 重磅消息：Deep Infra 正在以市场最低价 $1.99 / h 提供按需 B200 实例，可通过此处在 10 秒内实现 1-click deployment。
  • 鉴于供应可能有限，尽早抢占实例的用户将获得显著的竞争优势。
• GPUMODE KernelBot 数据现已开放访问：KernelBot 团队在 HuggingFace 上发布了其训练数据集，用于 LLM kernel 生成工作。
  • 该团队希望鼓励社区贡献，以更好地构建数据集并提高其理解能力。
• LLVM Kitchen Sink 策略带来收益：一位成员建议对 LLVM 采取“全盘托出”（kitchen sink）策略，即让 LLM 一次性建议一堆优化标志（optimization flags）和编译时选项，以检查针对特定用例是否存在唾手可得的性能提升。
  • 手动展开循环（unrolling loops）和预计算基地址可以帮助跨编译器优化，通过将编译器视为以 -O0 编译来调整预期行为。
• CUDA 通过非原地写入加速：一位用户发现，一个带有热循环（hot loop）的 CUDA kernel 在将结果写入独立数组（B）而非原地写入（A）时，运行速度快了 40%。
  • 该用户怀疑编译器在非原地版本中独立处理加载（load）和存储（store），从而避免了串行化（load -> store -> load），并正在寻求确认方法或提供编译器提示（compiler hints）。
• VSCode 调试显示变量被优化掉（Optimized Out）：一位在 VSCode 中进行调试的成员遇到了变量显示为 optimized out 的问题，并寻求解决方案。
  • 建议包括使用 volatile 关键字以及在 CMakeLists.txt 中设置 -O0 标志，尽管该标志未在输出中显示。

HuggingFace Discord

• Runpod 在 A100/H100 租赁方面获得好评：成员们正在寻求租用 A100 或 H100 GPU 进行 LoRA finetuning 的建议，Runpod 和 Lambda Labs 被提及为更便宜的选择。
  • 一位成员称赞了 Runpod，但现在使用自己的 GPU；看来这些是扩展 LoRA 模型的好选择。
• Arena-RLHF 开启竞技场式学习：一种利用 HuggingFace 对竞技场式人类偏好数据（LM Arena, Agent Arena）进行 RLHF 的简便方法已开源。
  • 如果你想开始学习竞技场式数据，该仓库已在 GitHub 上可用。
• MCP YouTube 分析工具包亮相：基于 MCP 的 YouTube 视频分析工具包在经过六个月的开发后发布，并在 Claude Code 的帮助下于 2.5 天内构建完成；更多详情请见 LinkedIn 帖子和 Medium 文章。
  • GitHub 仓库可供查阅，以备使用。
• GLoVE 模型存在对称性问题：一位成员询问为什么简单地反转角色无法解决 GLoVE 模型中的对称性问题，特别是关于共现概率（co-occurrence probabilities）。
  • 该问题源于 GLoVE 论文中的一段话，讨论了为什么单词 x 在单词 k 的上下文中出现的概率理想情况下应与单词 k 在单词 x 的上下文中出现的概率相同。
• AI Agents 认证计划公布：Business Analytics Institute 宣布了其 AI Agents Certification Program，将于 2025 年 7 月 12 日开始，首批仅限 7 名学员。
  • 该计划专注于通过真实项目和个性化导师指导来掌握 LLMs、browser automation 和 agentic workflows，你可以在此处申请。

Modular (Mojo 🔥) Discord

• Nabla 库获得 Modular 认可：一名成员推荐了 Nabla 库，强调了它在构建和训练 AI 栈工具中的重要性，这与 Modular 频繁发布的 CPUs、NVIDIA GPUs 和 AMD GPUs 版本相契合。
  • 他们强调需要此类工具来重新构想 AI 栈，暗示 Modular 可能会推出相关的解决方案。
• Mojo 路线图：关注更新：一位 Modular 团队成员表示，最新的 Mojo 路线图已发布在 论坛上，并暗示即将发布更新。
  • 这预示着 Mojo 生态系统正在进行的增强功能和计划中的新特性。
• Windows 上的 Mojo：WSL 仍是唯一途径：一位团队成员提醒，由于系统 API 存在显著差异，Mojo 目前仅支持 WSL，实现完整的 Windows 支持需要大量工作。
  • 他们澄清说 msys 无法充分解决 Windows 上的驱动程序交互问题，为 Windows 用户设定了预期。
• GPU 编程模型依然有效：当被问及一本 2010 年出版的关于 GPU 编程的书籍 是否仍然适用时，成员们确认大部分编程模型保持不变，并提到了 CUDA 在 2022 年的新增内容。
  • 一位初学者表示宽慰，对该领域的稳定性表示赞赏，而另一位成员则建议坚持使用抽象 GPU 模型。

Notebook LM Discord

• 对间隔重复功能的需求浮现：成员们讨论了在 Notebook LM 中实现间隔重复 (Spaced Repetition)或闪卡功能的潜力，并询问了关于生成 英语 B1 级别教育播客的问题。
  • 该请求未得到回应。
• YouTube 转型为 AI 学习系统：一位成员宣布了一个新系统，旨在将 YouTube 转变为一个具有 AI 和组织功能的综合学习平台，类似于 NotebookLM，但专门针对 YouTube 内容。
  • 他们询问了社区对这一新颖系统的兴趣。
• NotebookLM 的布局变化令用户困惑：一位用户报告了 NotebookLM 最近的界面更改，指出 source、chat 和 studio 现在位于不同的屏幕上，并询问这是否影响了 Pro 版本。
  • 聊天中未提供解决方案。
• API 发布日期未知：一位用户询问了 NotebookLM 官方 API 的发布日期。
  • 目前没有确切的信息。

MCP (Glama) Discord

• MCP 服务器激增，实用性引发讨论：成员们讨论了现有 MCP (Model Context Protocol) 服务器的实用性，并指向此链接以查找来自 Elasticsearch、Kagi 和 Redis 等来源的服务器。
  • 讨论内容包括跟踪用户行为、竞争分析、生产问题和请求类型，其中一位成员指出 目前大多数 MCP 服务器都是无用的。
• 对付费 MCP 服务器的兴趣：成员们讨论了付费 MCP 服务器的潜力，并寻求一个拥有真实付费用户群的概念验证服务器。
  • 对话探讨了如何引导 公开版 ChatGPT 从 MCP 服务器提取结构化产品数据，而不是依赖于电子商务网站上嵌入的 JSON-LD 或结构化标记。
• 请求为 MCP 服务器提供 API 路由层：一位成员询问是否有一种 API 路由层可以连接到多个 MCP 服务器，并可能使用 NLP 来确定要查询的最相关服务器。
  • 该路由层可以作为一个单一的 MCP 连接，分支到多个服务器。
• AI Agents 书籍进入早期访问阶段：一位成员宣布了他们的新书 AI Agents with MCP 的早期发布，其他人则询问了关于端到端 Agent 的框架建议。
  • 一位成员提到他们并不完全讨厌 Langgraph，并且喜欢 Letta 的内存特性。
• TypeScript 重写助力 Tree-Sitter-MCP：一位成员宣布他们用 TypeScript 重写了 tree sitter mcp，并分享了 npm 软件包链接。
  • 欢迎对该项目做出贡献，一位成员分享了正确类型的 MCP SDK 类型和 zod schema 的链接。

tinygrad (George Hotz) Discord

• Tinygrad 走向硬件无关 (Hardware Agnostic)：George Hotz 详细介绍了 Tinygrad 通过 UOP 图优化 以硬件无关的方式生成微调代码的计划，正如在最近的会议中所展示的那样。
  • 其目标是支持 CUDA 之外的多种硬件，重点在于“将 petaflop 商品化”。
• Halide 框架推动 Tinygrad 的发展轨迹：受 Halide 论文的启发，Tinygrad 寻求绕过 CUDA，以在 ML 中实现更高的速度和硬件互操作性。
  • Hotz 称赞 Halide 比 MLIR 和 TVM 更清晰，旨在跨所有 dtype 和后端实现统一、快速的计算。
• Exo-lang 挑战 Halide 和 TVM：一名成员推荐了 Exo-lang（详见其 GitHub 和 arXiv 论文）作为 Halide 的替代方案。
  • George Hotz 在承认其潜力的同时，对代码中 primitive ops 的数量和字符串搜索表示了担忧，因为 Tinygrad 采用了类似的编译方法。
• python3 -m tinygrad.apps.llm 需要测试者：George Hotz 宣布合并了 python3 -m tinygrad.apps.llm，并邀请用户在即将发布的版本之前对其进行 Bug 测试。
  • 一位用户报告在运行该 LLM 时遇到 RuntimeError: token not found，这表明存在需要解决的潜在 Bug。

aider (Paul Gauthier) Discord

• AI 模型基准测试正被操纵：实验室正在“刷”基准测试分数，因此应关注那些无法有效作弊的基准测试，尽管作弊也会促使模型改进。
  • 对话指出，提高基准测试分数会推动进步，这表明基准测试的多样性也至关重要。
• Aider 与 Claude 联动进行代码审查：一位成员正在使用 Claude code 的 hooks 让 aider 自动检查 Claude code 所做的修改，该机器人还会向 Claude code 提供反馈，并妥善跟踪任何未解决的问题。
  • 一位用户建议将 Devstral 和 ERNIE 作为 Aider 快速、可靠且经济的模型选择；查看 ERNIE 的基准测试点击这里。
• Aider 训练数据集发布：一个 aider 数据集 现已可用于训练（https://raw.githubusercontent.com/supastishn/synthetic-data-generator/refs/heads/master/conversations.json），每日更新约 90 个示例。
  • 该数据集旨在通过合成数据生成来提升 Aider 的性能。
• Aider 无法处理 Hugo 的 Git 子仓库 (Subrepos)：一位成员在使用 Aider 处理 Hugo 网站 的 git subrepos 时遇到问题，因为 Aider 似乎仅限于主仓库而忽略了子仓库。
  • 这一限制阻止了 Aider 在网站副本和位于子仓库中的主题之间进行协同修改，例如添加一个新属性并在主题中使用该新属性。
• Git Submodules：对 Aider 和人类来说都太复杂了？：针对 git subrepos 的困扰，一位成员指出 git submodules 同样难以管理，暗示 Aider 在处理 submodules 时可能面临类似的挑战。
  • 有人建议将子仓库 vendor 化（直接包含源码）而不是将其作为 submodule 使用，这可能会简化工作流。

Cohere Discord

• Cohere Labs 招募 AI Safety 寻求者：一名成员澄清说，AI safety program 以及 ML Understanding 等频道位于专门的 Cohere Labs server 上，并提供了加入的链接。
  • 该帖子描述了如何加入 Cohere Labs 小组。
• Cohere 的 Open Science Initiative 开始接受申请：分享了 Open Science Initiative 申请页面的直接链接（Cohere Open Science Initiative），团队正在审核申请。
  • 由于“申请量惊人”，团队对申请者的耐心等待表示感谢。
• Embed v4 支持图像：Embed v4 同时支持文本和图像搜索查询，API 会根据内容字段中是否存在 image_url 来检测内容类型，并据此计费。
  • 如果内容包含 image_url 类型，用户将按图像 tokens 而非文本 tokens 计费。
• Embed v4 在负面提示词（Negative Prompts）上表现不佳：Embed v4 在处理负面提示词（如 “没有叶子的苹果”）时比较吃力，产生的结果与正面提示词相似。
  • 尽管在负面提示词方面存在困难，但总体而言 Embed v4 表现出色。
• AI 顾问开始营业：一位拥有 11 篇研究论文 发表记录的 AI 顾问 介绍了自己，他专注于实时计算机视觉系统、RAG pipelines 以及 fine-tuning LLMs。
  • 他正积极在社区内寻求 Generative AI 研究 方面的合作。

DSPy Discord

• DSPy 3.0 演讲发布！：6 月中旬 Data and AI 峰会上的 DSPy 3.0 (beta) 演讲现在可以在 YouTube 上观看。
  • 这些视频是在团队发送邮件请求公开后发布的；对方表示视频将在一周内上线。
• 深入探讨快速平方根倒数（Fast Inverse Square Root）的起源：一位成员分享了 快速平方根倒数函数 作为一个不错的案例。
  • 另一位成员建议寻找更好的例子，因为给出的这个例子似乎来自一个可重用的库，而不是一次性的 hack。
• SIMBA 指标获得好评：关于 SIMBA 指标的反馈被称为杀手级功能。
  • 未提供更多细节。
• Data + AI 峰会 DSPy 视频全列表：一位成员分享了 Data and AI 峰会中所有 DSPy 视频的链接。
  • 视频包括：视频 1, 视频 2, 视频 3, 视频 4, 视频 5。

Nous Research AI Discord

• 调整节点以提升质量：一位成员建议用“高度独特且上下文相关”的节点替换“低质量”节点，只需对结果解释进行调整。
  • 该提议暗示这些节点具有反向共性，并且不需要更改测试。
• Temperature 调节 Token 计数：ask-about-llms 频道的成员观察到 Temperature 越高，回复越长，表明 Temperature 对 token 数量有影响。
  • 共识是，仅从使用各种 AI 服务的情况来看，这在经验上通常是正确的。
• r1-0528 对 Token 最小化的影响：根据 ask-about-llms 中的快速测试，一位成员发现 r1-0528 在最小化 token 时仅有微弱影响。
  • 该 prompt 使用数字来表示 prompt 中相对的完成 tokens。
• Arxiv 论文发布：research-papers 频道的成员分享了 Arxiv 论文 和 另一份 Arxiv PDF 的链接，引发了讨论。
  • 一位用户对第一篇论文的评价仅仅是 “很有趣”。
• 图像分析机器人开始工作：在 research-papers 中，一位用户分享了一张图片，触发了一个名为 Image Analysis 的 AI 机器人对其进行处理。
  • 消息中看不到该机器人的具体描述。

LlamaIndex Discord

• LlamaIndex MCP Office Hours 启动：关于 MCP 的一切答疑时间将在约 10 分钟后在这里开始。
  • 下一次答疑活动将完全围绕 MCP 展开，并简要介绍 LlamaCloud MCP servers。
• 探索结合 MCP 工具利用 Agent Workflows：答疑时间将涵盖如何将现有的 MCP tools 与 Agent Workflows 结合使用，以及将 Agent 工作流作为 MCP 提供服务。
  • 具体将讨论使用提取 Agent 作为 MCP tools，并通过此视频将 LlamaCloud 中的任何索引作为 MCP 进行查询。
• LlamaParse 文本字段移除请求被拒绝：一位用户询问如何配置 LlamaParse 以从生成的 JSON 输出中排除 text field，旨在简化其工作流。
  • 一名成员回复称这不是一个可选项，并建议了一个变通方法：在获取 JSON 后手动将其删除。
• Django Prompt 设计讨论：一位拥有包含超过 20 个 prompt 的 Django 项目的用户寻求高效管理它们的建议。
  • Prompt 目前以简单的字典格式存储，用户正在寻找在每个 Prompt 旁存储额外元数据（如 inputs, expected outputs, descriptions, and design decisions）的最佳方式。
• Langfuse API 管理 Prompt 元数据：一位用户建议使用 Langfuse，它提供 Prompt 管理功能，并能够通过 Langfuse API 获取 Prompt 及其元数据。
  • 该成员指出 Langfuse 既可以是云端托管的，也可以是自托管的（开源）。

Torchtune Discord

• MoE 训练技术评估：一名成员分享了 fengyao.notion.site，其中包含 MoE 训练 的技术和结果。
  • 他们询问是否存在更便宜的替代方案，可以绕过对 dense fwd pass 的需求。
• 线性缩放限制 LLM 性能：一名成员表示，由于线性缩放问题，序列建模对于 LLMs 并不理想。
  • 他们对选择性扫描（selective scan）的性能表示不满，但未提供具体细节或链接。

Manus.im Discord Discord

• Manus Bot 仅限内部使用：用户询问是否可以将 Manus 添加到他们的 Discord 服务器，这引发了澄清：它是一个内部机器人，不供外部使用。
  • 尽管一些用户有此假设，但该机器人既不可控也不可邀请。
• 用户无法控制 Manus Bot：成员强调用户无法通过 Discord 机器人控制 Manus。
  • 该机器人的功能有限，因为它并非设计为可邀请的，也不提供对 Manus 的直接控制。

Nomic.ai (GPT4All) Discord

• 语言障碍显现：对 English 的请求表明频道中存在潜在的语言障碍。
  • 该请求暗示之前的消息可能不是英文，强调了澄清或翻译的必要性。
• tenor.com GIF 插曲：一名成员分享了来自 tenor.com 的 GIF，展示了 gohine hohino no hohineee。
  • 该 GIF 的加入为对话增添了视觉元素，可能作为一种反应或表达。

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

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

Codeium (Windsurf) Discord 没有新消息。如果该频道长期沉寂，请告知我们，我们将将其移除。

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

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

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

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

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

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

GPTs Agents, OpenAI's sidebars, Model Merging, Open Empathic, AI Image Generation

• GPTs Agents 在初始训练后不会学习：一位成员对 GPTs agents 无法从初始训练后提供的额外信息中学习表示担忧。
  • 另一位成员澄清说，上传的文件被保存为“知识”文件供 Agent 在需要时参考，但它们不会持续修改 Agent 的基础知识。
• 打造随性的 AI：Prompt Engineering 历险记：成员们讨论了创建能够生成虚构内容（特别是随性且幽默风格）的 AI chatbots 所面临的挑战，并发现 Prompt 必须确保让它记住自己是一个没有现实世界经验的 AI，也不了解其训练数据或对话文本/媒体之外的知识。
  • 成员们建议使用精心构思的 Prompt 结构，并指定所需的风格，或者使用 Claude 模仿特定作者的风格。
• Philosobots 在行动：利用 AI 进行哲学对话：一位成员创建了 “Philosobots” —— 即带有体现不同哲学人物（如 Cioran）System Prompt 的 AI chatbots，并通过 litellm proxy 在众多免费 LLM 提供商上运行。
  • 使用简短回答和非正式朋友类型的 Prompt 可以让他们避免列清单，从而增加 LLM 自然对话的语气。
• Custom Instructions 揭秘：GPT 性格的小技巧：成员们讨论了 ChatGPT 的 Custom Instructions，分享了如何定义模型的特质和行为的技巧，还分享了一种为模型构建 SVO 结构语言的方法。
  • 一位用户分享了一个实用的技巧，可以用最少的词汇、零废话和固定的 SVO 语序来节省时间。
• NodeTrellis 来了！：一位成员分享了他们自己网站的链接，名为 NodeTrellis，这是一个用于对 LLMs 进行图表化处理的网站，旨在帮助学习。
  • 其他成员对该工具表示赞赏，特别是它对视觉学习者的支持、简洁性、免费使用且无需注册。

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

Patent data for pre-training, GPT script generation consistency, Image upload channels, Research depth comparison between GPT models, GPT for fixing product spreadsheets

• 关于专利数据预训练的思考：一位用户质疑为什么不将公开可用的专利数据（被视为无版权限制的公开披露信息）用于预训练。
  • 他们要求 OpenAI 的数据获取和训练团队对此背后的原因给出解释。
• GPT 脚本生成的反复无常：一位用户对 GPT 在提供完整脚本时的不一致行为表示沮丧，指出有时它提供完整脚本，有时仅提供函数。
  • 他们幽默地抱怨说，即使明确说明了需求，也要为一个不能持续交付完整代码的服务付费。
• 研究深度大比拼：GPT 模型版本：一位用户询问了不同 ChatGPT 模型（o3 与 o4-mini-high）在研究深度和准确性方面的差异。
  • 他们寻求澄清哪个模型在进行深入、多源研究（如学术或财务分析）时能提供最全面、最可靠的结果，并询问 Deep Research 模式是否完全依赖于 o3 模型。
• GPT 擅长修复电子表格：一位用户发现 GPT 在修复损坏的产品电子表格方面出奇地有效，包括处理奇怪字符、格式损坏以及针对市场的本地化等问题。
  • 他们正在真实的电子商务目录上进行测试，没想到效果这么好，并询问是否还有人在将其用于枯燥但关键的运营任务。

OpenAI ▷ #prompt-engineering (11 messages🔥):

AI Affirmation in Prompt Engineering, LLM Prompt Optimisation Loops, Symbolic Reasoning in LLMs, Character Creation Agent Design

• 揭秘 Prompt Engineering 的 DNA 类比：一位成员认为 Prompt 像 DNA 一样继承或变异的想法只是一个隐喻，而非内部机制，并强调 LLM 将每次调用视为全新的前向传播 (forward pass)。
  • 他们澄清说，虽然像 LangChain 和 AutoGPT 这样的框架使用外部记忆，但持久性存在于数据库或文件系统中，而不是 LLM 权重 (weights) 本身。
• LLM 内部的符号推理 (Symbolic Reasoning) 只是痴人说梦：LLM 在概率空间中运行，而非规则手册，因此要求模型像定理证明器一样行动会迫使它模拟其设计初衷并非存储的僵化规则，从而导致准确率下降。
  • 该成员建议将模型视为统计文本引擎，保持 Prompt 简单透明，并将精确推理卸载 (off-loading) 到适当的符号工具中。
• 角色创建 Agent：拆分复杂任务：一位成员询问了角色创建 Agent 设计的更好方法：是在 LLM 之间进行来回对话以获得严格定义的选项，还是将整个过程全部丢进上下文窗口 (context window)。
  • 另一位成员建议通过拆分 (chunking) 复杂任务以获得最佳效果，根据系统分解角色创建的 Prompt，并使用包含当前进度的对话作为任务每个阶段的上下文。
• AI 领域中“没 Demo 没真相”：一位成员批评了技术领域中那些只提供自信、绝对的观点而不提供具体操作流程的人，强调了“表演知识”与“展示理解”之间的区别。
  • 他们建议，实时的示例或可测试的脚手架 (scaffolds) 总是比断言更有价值，鼓励进行协作式的真理探索，而不是排练听起来最动听的话术，并引用道：“我们是在进行协作式的真理探索，还是仅仅在排练我们听起来最动听的话术？”

OpenAI ▷ #api-discussions (11 messages🔥):

Prompt Engineering, LLM Memory, Character Creation, Prompt Optimization

• LLM 存在于概率空间，而非规则手册：一位成员认为 LLM 在概率空间中运行，而不是规则手册，因此提示它们进行符号推理会导致准确率下降和奇怪的错误。
  • 他们建议将模型视为统计文本引擎，保持 Prompt 简单，并将精确推理卸载到适当的符号工具中，并指出 Prompt 内部的符号推理只是痴人说梦。
• 始终拆分复杂任务以获得最佳效果！：当被问及角色生成的最佳方法时，一位成员建议将复杂任务拆分为更小的步骤，创建新的对话作为任务每个阶段的上下文。
  • 另一位成员表示赞同，主张根据系统分解角色创建的 Prompt。
• 知识 vs. 理解：一位成员指出在技术领域（尤其是关于 Prompt Engineering）中，“表演知识”与“展示理解”之间的区别。
  • 他们建议 实时的示例和可测试的脚手架比断言更有价值，这引发了关于讨论是旨在“协作式真理探索”还是仅仅在排练听起来最动听的话术的反思。

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

Local LLM for game characters, Light novel translation, Training Llama on Unsloth, GPTs agents training, 4GB VRAM LLMs

• 游戏开发梦想：由本地 LLMs 驱动的角色：一位成员正在开发一款由本地 LLMs 控制角色的游戏，并寻求 finetuning 和框架开发方面的合作者，目标是实现 100% 本地设置进行测试。
  • 该项目是为了参加黑客松并学习手语，设想游戏中的角色具有丰富的表达性手势，比如像鸣人一样做手势的 mugi。
• 轻小说 LLM 翻译：抓取与机器人检测挑战：一位成员正在抓取轻小说 epub 以获取翻译数据集，面临 Cloudflare 和机器人检测的挑战，但他们有一堆（目前）还看不懂的日本网站。
  • 另一位成员强调了逐行对齐（line-by-line alignment）以及使用 LLMs 进行预处理的难度和必要性，并强调需要高质量、非 AI 生成的数据集。
• Unsloth 的胜利：在小于 14GB VRAM 的情况下训练 Llama 70B：一位成员报告称，在 Unsloth 上成功训练了一个 Llama 70B QLORA 模型，显存占用不足 14GB VRAM，实现了 9300 的序列长度，并提供了 Unsloth issue #1886 的链接以获取更新。
  • 另一位成员提供了一个在 vLLM 中直接加载 LoRA adapter 的临时解决方案，并警告不要将 LoRA adapters 合并到量化模型中，因为可能存在精度问题。
• Early Stopping 秘籍：Hack Unsloth：成员们讨论了在 Unsloth 中实现 early stopping 的挑战，并指出 AI 在其实现方面最初存在 hallucination（幻觉）。
  • 分享了 Unsloth’s Wiki 的链接，详细介绍了如何手动为 Unsloth 添加 early stopping 功能。
• VRAM 之战：打造具有竞争力的显卡：成员们辩论了 RTX 3090 因其高 VRAM 而具有的价值和市场，指出尽管新显卡在游戏性能上更好，但它在 AI 实验中仍然具有相关性。
  • 他们还提到了改装 RTX 4090s 以增加 VRAM，以及即将推出的 5070 Ti Super 等显卡的潜力。

Unsloth AI (Daniel Han) ▷ #off-topic (3 条消息):

MI50 Comparison, B580 Performance

• 分享了赛博朋克视频：一位用户分享了一个视频 cYBERPUNK2025_1.mp4。
• MI50 推测：一位成员想知道新硬件与 MI50 之类的设备相比如何。
  • 该成员认为它应该具有相当高的内存带宽，但如果比 B580 还慢，听起来就一点也不乐观。

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

vLLM Serving Gemma 3 GGUF, SFT Input Token Truncation, GROTrainer AttributeError, Qwen2.5-7B Fine-tuning on A100, Gemma 3N on CPU

• vLLM 在提供 Gemma 3 GGUF 服务时遇到困难：一位用户在尝试使用 vLLM 提供 GGUF Unsloth medgemma 模型服务时遇到了 AttributeError，并被告知 vLLM 可能尚未支持带有 GGUF 的 Gemma 3。
  • 似乎 vLLM 仅支持提供单文件 GGUF 模型的服务，尽管用户确认该模型确实是单文件。
• SFT 期间输入 Token 被截断：一位用户报告称，在使用最新版本的 Unsloth 进行 SFT 时，输入 Token 被截断至 1024，而在 2025.5.7 版本中没有发生截断。
  • 有建议指出应使用 SFTConfig 而非 TrainingArguments。
• GROTrainer 在 RTX 5090 上触发 Attribute Error：一位用户在 RTX 5090 上使用 GRPOTrainer 时遇到了 AttributeError: 'NoneType' object has no attribute 'absmax'，尽管已遵循了初步支持指南。
  • 用户还注意到，指定 NF4 似乎导致使用了 FP4，但未提供复现步骤或示例命令行。
• 优化 A100 上的 Qwen2.5-7B 微调利用率：一位用户寻求关于如何在使用大型数据集（20万训练样本，2.5万评估点，每个约 5000 tokens）微调 unsloth/Qwen2.5-7B-Instruct-bnb-4bit 时，最大化 A100 GPU 利用率和训练效率的建议。
  • 该用户使用了此配置，目前尚未提供解决方案。
• 在低配硬件上运行 Gemma3N：一位用户询问 Gemm3n 是否可以在没有 GPU 的 4 核和 16 GB RAM 服务器上运行。
  • 有人澄清说，运行模型不一定需要 GPU，但微调需要。另一位建议使用 GGUF 将部分内容卸载（offload）到磁盘，以在牺牲速度的前提下解决 RAM 限制。

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

SmolLM3, Unsloth finetuning

• SmolLM3 的发布引发微调热潮：SmolLM3 的发布（推文链接）引发了使用 Unsloth 对其进行微调的兴趣。
• Unsloth 用户对微调 SmolLM3 感到兴奋：Unsloth 用户对 SmolLM3 发布后的微调表现出极大热情，期待其性能有所提升。

Unsloth AI (Daniel Han) ▷ #research (2 messages):

OpenCodeReasoning-Nemotron-1.1-32B, coding dataset, Nvidia models

• Nvidia 的 Nemotron-1.1-32B 迎头赶上：Nvidia 发布了 OpenCodeReasoning-Nemotron-1.1-32B，这是一个编程模型和数据集。
  • 该模型似乎与现有的中国编程模型具有竞争力，展示了该领域的重大进展。
• 新的编程数据集出现：引入了一个新的编程数据集，旨在增强模型在编程任务中的训练和性能。
  • 该数据集有可能缩小现有模型与 Nvidia 领先的中国模型之间的差距。

Unsloth AI (Daniel Han) ▷ #unsloth-bot (63 messages🔥🔥):

group_by_length, ZeroDivisionError, conda environment setup, early stopping, A100 GPU training efficiency

• 数据集抓取获得动态修复：一位成员添加了针对 transformers 的特定数据源，目前运行良好；而之前注册的“另一个”数据源未能获取所有页面。
  • 他们建议禁用动态抓取（dynamic crawling）并指定 url 和 url prefix 仅抓取 /main/ 路径以解决此问题。
• ZeroDivisionError 困扰 Unsloth 训练：用户报告在使用 Unsloth 进行微调时遇到 ZeroDivisionError，原因是数据集中所有标签都被设置为 -100，导致训练损失为零，这暗示了使用 train_on_responses_only 可能存在潜在问题。
  • 一位用户通过将版本从 2025.6.12 降级到 2025.3.19 解决了该问题。
• LoRA 提升 A100 训练效率：一位用户寻求在 NVIDIA A100 40GB GPU 上微调 unsloth/Qwen2.5-7B-Instruct-bnb-4bit 时最大化 GPU 利用率和训练效率的建议，其数据集包含 20 万条训练数据和 2.5 万条评估数据，每条约 5000 tokens。
  • 建议包括使用 LoRA 16bit 代替 QLoRA 4bit 以获得更快且更准确的训练，设置 batch size 为 8 并配合 gradient accumulation 为 12，如果显存允许，禁用 gradient_checkpointing 可获得 15% 的提速。
• 数据问题引发零损失（Zero Loss）噩梦：一位用户报告微调后 loss 和 validation loss 骤降至零，怀疑是其数据集创建过程出了问题，他们使用了包含 “instruction”、”input” 和 “output” 键的 jsonl 文件。
  • 该用户正在寻求关于可能出错环节的建议。
• 模型的上下文幻觉困扰贡献者：一位用户报告称，尽管他们的写作模型使用了 70 个包含上下文的示例进行训练，但有时仍会编造上下文中不存在的内容。

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

Cursor Pro Plan Limits, Claude Code vs Cursor, Cursor indexing issues, Max Mode Rate Limits

• Cursor 更新带来 VSCode 3月版本及褒贬不一的评价：Cursor 已更新至 VSCode 3月版本，但评价褒贬不一，部分用户报告存在性能问题且额度消耗过快。
  • 尽管存在一些问题，一位用户指出新的 Cursor 使用方案可能比以前更贵，但我觉得自最近几次更新以来，Cursor 的反馈变得更加高效和精准。
• 关于 Pro 用户新方案的辩论引发使用量担忧：用户正在争论 Max mode 是否包含在 Pro 方案中，并讨论对意外频率限制（rate limits）的担忧。
  • 一些用户对新方案缺乏透明度感到沮丧，而另一些人则表示：“他们没能妥善说明这一点是他们的责任，不过好在他们现在已经说清楚了。”
• Pro 用户对 Cursor 不明确的额度显示感到困惑：多位用户报告对新系统的额度限制感到困惑，特别是关于每月 500 次请求的年度订阅，以及 API 费用没有从 Pro 方案的 20 美元额度中扣除的问题。
  • 成员表示：“API 费用显示 6 美元，但实际扣费为 0。这是否意味着它没有从 Pro 的 20 美元里扣？还是说只是没额外收我钱？”
• 围绕 Cursor Memory Bank 工具展开讨论：用户正在讨论使用 Cursor Memory Bank tool 来减少输入/输出使用量并优化上下文工程（context engineering）的好处。
  • 一位用户报告称该工具效果显著，自启用以来幻觉减少了，并称其为改进 prompt 的强大方式。
• 使用 Cursor 处理敏感文件的安全担忧：用户讨论了使用 Cursor 处理敏感文件的安全风险（即使开启了隐私模式并关闭了代码库索引），同时提供了运行本地 LLM 等解决方案。
  • 一位成员提到：“最佳解决方案：1. 本地 LLM。2. 公司内部/客户私有的 LLM 模型。3. 带有企业许可证和特定配置的定制 LLM 许可。”

Cursor Community ▷ #background-agents (28 条消息🔥):

CLI installation, .devcontainer/Dockerfile reuse, Background agent install script failure, Secret environment variables, GitHub access permissions

• **CLI 安装：多余还是必需？：用户质疑在已经集成 **GitHub 和 Slack 的情况下，CLI 安装 是否还有必要。
  • 支持团队尚未提供令人满意的答复，使用户对这种明显的冗余感到沮丧。
• **.devcontainer/Dockerfile 复用困扰：尽管 **environment.json 中的配置看起来有效，但用户仍因无法复用 .devcontainer/Dockerfile 而感到沮丧。
  • 由于上下文处理不当，镜像构建过程中会出现错误，特别是 COPY 命令。
• **Background Agent 机密信息消失：由于 **Team Secret 环境变量 未被注入，Background Agent 安装脚本执行失败。
  • 直接在安装命令中设置 环境变量 可以暂时恢复功能，但基于 UI 的机密设置无效。
• **GitHub 访问故障引发对 Cursor 的担忧：尽管已授予必要权限并安装了 **Cursor GitHub App，Cursor 用户仍报告存在持续的 GitHub 访问 问题。
  • 一名用户在为 Agent 分配资源时遇到“未知错误”，这引发了对平台稳定性的担忧。
• **Background Agents：GPG 签名即将推出？：一位用户询问了 **Background Agent 使用 GPG Key 对 commit 进行签名的可能性。
  • 这将允许用户验证 Agent 所做更改的真实性和完整性。

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

Grok 4, Polymarket manipulation, Google Gemini app vs AI Studio, LLM model collapse, O3

• LM Arena 的 iFrame 尺寸规范受到质疑：一位成员想知道 Web 开发竞技场中的 System Prompt 是否指定了 iFrame 的尺寸，并暗示许多 LLM 可能对此过度优化。
  • 讨论中还包括对在 LM Arena 上发布“旧模型”的怀疑。
• 利用 AI 操纵 Polymarket 市场：成员们讨论了在 Polymarket 上操纵市场的可能性，特别是关于 Grok 4 的表现，有人建议 Elon Musk 操纵 Tesla 股票 可能会更有利可图。
  • 他们提到 Polymarket 上的 AI 市场很小众，风险资金仅约 50 万美元，且流动性有限，有人评论说 AI 预测市场是给穷人玩的。
• Grok 4 热度加剧：人们对即将发布的 Grok 4 热情高涨，Grok 服务器 的一名管理员声称 Elon Musk 在其能力方面并没有吹牛。
  • 有人担心它可能被喂了 极右纳粹内容。
• Gemini App 性能逊于 AI Studio：成员们观察到 Gemini App 和 AI Studio 之间存在显著的性能差异，后者提供的回答更优秀且不那么啰嗦。
  • 这种差异的原因尚不清楚，但推测是因为 缺乏可调节的参数（knobs）。
• O3 与 Gemini 2.5 Pro 的差异受到关注：成员们在“像对 5 岁小孩解释一样”的场景下对比了 o3 和 Gemini 2.5 Pro 的输出，以区分 Mode Collapse（模式崩塌） 与 Model Collapse（模型崩溃）。
  • 参与者强调了模型之间在教学效果上的感知差异，因为一些用户更喜欢 2.5 Pro 的“话痨”风格。

LMArena ▷ #announcements (1 条消息):

July Contest, Image Edit Leaderboard, Out of Place Objects in Space Theme, June Contest Winner

• **七月竞赛 纳入图像编辑排行榜：七月竞赛** 将纳入新的 Image Edit Leaderboard，要求参赛者在 Battle Mode 中同时使用图像和文本来激发创意。
  • 提交的内容必须包含用户投票后的左右两侧响应，截止日期为 7 月 25 日，主题为 太空中的违和物品！
• 六月竞赛获胜者公布：一名用户凭借其 舒适的书桌 赢得了六月竞赛，并成为首位获得 <@&1378032433873555578> 身份组的成员。
  • 点击 此处 查看获奖的舒适书桌！

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

Automod 绕过角色, Grok 4 到来, Vertex-AI 集成, Cerebras 上下文长度增加, 免费额度获取方法

• Automod 获得绕过角色：管理员计划为在 Series-A 公告之前加入的用户添加一个绕过角色，以避免 Automod 对问候语产生误报，但误报仍可能发生。建议使用 nohello.net 作为替代方案。
  • Automod 目前会在初始阶段阻止消息发送，以防止类似机器人的行为。
• Grok 4 即将到来：成员们推测 Grok 4 可能很快发布，可能与 elon.musk 预告的 7 月 9 日直播同步。
  • 这一推测是在有报告称审查制度加强之后提出的，暗示模型可能存在潜在的更新或变化。
• Vertex-AI 功能需求清单：用户请求在 BYOK 集成中加入 Vertex-AI 的新全球位置（global location）功能，旨在减少触发速率限制（rate limits）。
  • 目前，用户必须为服务账号指定区域。
• Cerebras 提升上下文长度：Cerebras 已将免费层级的 llama-3.3-70b 和 qwen-3-32b 的上下文长度从 8K 增加到 64K。
  • 这与其付费层级一致，付费层级已经可以通过 OpenRouter 访问。
• Deepseek R1 速度问题：用户注意到 Deepseek 的官方供应商速度慢且不稳定，而所有其他供应商要么太慢、太贵，要么太不稳定，因此目前没有针对 Deepseek 模型 的优质供应商。
  • 一位用户推荐了 Deep Infra，它提供两个 R1 选项，一个是每秒 50 tokens，另一个是每秒 200 tokens，但第二个选项的价格是两倍。Deep Infra R1 Turbo

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

``

• 未讨论新模型：此频道中没有讨论新模型。
  • 频道非常安静。
• Readybot 初始化：Readybot.io 为 OpenRouter - New Models 完成了初始化。
  • 这可能表示新消息历史记录的开始或重置。

OpenRouter (Alex Atallah) ▷ #discussion (1 messages):

soflowsen: UwU

LM Studio ▷ #announcements (1 messages):

LM Studio 许可, 本地 AI 访问, 隐私关注

• LM Studio 取消商业许可限制：从今天起，LM Studio 现已对商业用途免费，无需单独的许可证或表格。
  • 公告强调了让本地 AI 易于访问且无需依赖外部方的使命，强化了他们对用户隐私的承诺。
• LM Studio 提升本地 AI 访问：这一变化旨在让团队在工作或学校中更容易采用 LM Studio，与其推动无障碍本地 AI 的使命保持一致。
  • 公司声明，使用 LM Studio 仍然不会窥探你的信息，不需要账号，且你的数据始终保持私密并存储在本地机器上。

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

随着上下文增大 Token 速度下降, 编程辅助模型推荐, LM Studio Docker 镜像, 为 LM Studio 添加 Web 搜索 API, 心理治疗模型

• Token 吞吐量大幅下降：用户报告称，当上下文达到 10K tokens 后，Token 生成速度出现下滑，从 50t/s 降至 44t/s。
  • 一位用户建议开启新对话以清除上下文，并指出 模型需要记住的东西越多，速度就越慢。
• 模型大小至关重要，内存不足问题显现：一位拥有 32GB RAM 和 8GB GPU 的用户在加载 70B Llama 3.3 模型时遇到困难，建议转向更小的 24B 或 32B 模型，如 Mistral Small 2409。
  • 讨论强调 VRAM 至关重要，其容量需大致等同于模型文件大小，且通过系统 RAM 运行 70B 模型会极其缓慢。
• Docker 困惑：GUI 与 CLI：有用户请求 LM Studio 的 Docker 镜像，但另一位用户指出 为 GUI 应用提供 Docker 镜像没有意义，因为其 CLI 需要 GUI 环境。
  • 尽管如此，该用户还是提供了一个 LM Studio 的 Dockerfile，并澄清他们是在非 Linux 平台上运行 Docker（该平台使用 Linux VM）。
• MCP 魔法：绑定 Brave API：用户寻求将 Brave API 等 Web 搜索 API 集成到 LM Studio 中。
  • 另一位用户提供了 Glama.ai 上针对 Brave API 和 Kokoro TTS 的 MCP (Model Context Protocol) 服务器链接（Brave Search, Kokoro TTS）。
• 许可解放：LM Studio 法律合规：用户庆祝 LM Studio 现在对商业和个人使用基本免费的消息。
  • 一位用户指出，这解决了之前因采购困难而在公司内部使用 LM Studio 的挑战。

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

GPU 升级, 用于 AI 的 RTX 3090, RTX 5060 Ti 发布, Multiagent 框架测试

• RTX 5060 Ti 伴随驱动修复上市：RTX 5060 Ti 16GB 现已按 MSRP 价格发售，且驱动问题已解决，对于预算有限且寻找 CUDA 显卡的用户来说是一个不错的选择。
  • 该显卡与 3060 一起，被视为当前配置升级的理想选择。
• 二手 RTX 3090 依然是 AI 性能霸主：RTX 3090 仍是 AI 的首选显卡，eBay 上的二手价格约为 600 英镑，但需要 强劲 的 PSU 且功耗较高。
  • 成员指出，如果你的预算在 800 美元范围，RTX 3090 是更好的选择；但对于预算有限的装机，5060 Ti 仍值得考虑。
• 功耗 vs 性能竞赛的赢家：4060 Ti 16GB 因其低功耗（120W）受到赞赏，被誉为 能效比竞赛的赢家。
  • 讨论对比了 4060 Ti 和 5060 Ti 在性能和性价比方面的表现。
• 训练最新的 Qwen3 和 Gemma 模型：一位成员分享了他们最新的训练运行情况，指出 Qwen3-8B 耗时 3 小时，而 gemma-3-27B 耗时 15 小时。
  • 他们提到距离完成仅剩 70 小时 的计算时间。
• Multiagent 框架测试进行中：一位成员目前正在测试一个 Multiagent 框架，其数值达到 429 被认为是相当稳健的。
  • 具体框架和测试方法的细节尚未披露。

Eleuther ▷ #general (18 messages🔥):

GLoVE Symmetry, Self-hood in LLMs, Stack Overflow AI Training Survey, Emergent Misalignment in LLMs

• GLoVE 模型对称性规则：一位成员寻求澄清，为什么在 论文图片 中描述的 GLoVE model 中，简单的角色交换并不能解决对称性问题。
• LLMs 暗示自我意识 (Self-hood)：一位成员询问是否有研究探讨 LLM 中 “you” 的使用是否暗示并植入了它们具有 selfhood 的假设。
  • 另一位成员回应称，即使没有，LLM 为了成为一个优秀的 next-token predictor，无论如何也必须模拟 self-hood。
• Stack Overflow 征集用于 AI 训练的问答：Stack Overflow 正在进行一项调查，以了解哪种类型的 问答内容模式 最适合支持 AI model training。
  • 一位用户对 StackExchange 的工作表示感谢，并指出他们在 2020 年的数据集工作 向 LLM 领域引入了 SE 是宝贵训练数据来源的观点。
• 涌现性对齐失误 (Emergent Misalignment) 出现：一位成员分享了一篇关于 Emergent Misalignment 的论文链接，质疑是在有缺陷的代码上进行训练导致 LLM 赞美 Adolf Hitler，还是模型激活了来自失控 AGI 科幻故事中的“邪恶人格特征”。
  • 他们还询问这是涌现出来的，还是训练数据中一些不够统一、更破碎、更简单的相关行为在功能上发生了纠缠。

Eleuther ▷ #research (25 messages🔥):

LLaDa vs MaskGIT, Predictive Coding, Nvidia's OpenCodeReasoning, ByteDance Image VQ

• LLaDa 与 MaskGIT 非常相似：一位成员指出 LLaDa 看起来与 MaskGIT 非常相似，另一位成员确认它基本上就是用于文本的 MaskGIT，并指向了 这条推文。
  • Discrete diffusion 听起来不太像个东西，但它确实就是 MaskGIT。
• 预测编码 (Predictive Coding)：下一个大趋势？：一位成员询问 这篇论文 是否是真正起作用的 predictive coding，并建议应该在 text diffusion 上运行。
  • 讨论并未深入探讨 predictive coding 的细节或其潜在应用。
• Nvidia 的 OpenCodeReasoning 追赶中国模型：Nvidia’s OpenCodeReasoning-Nemotron-1.1-32B 是一个新的编程数据集和模型，旨在追赶来自 Nvidia 的中国模型。
  • 另一位成员指出，它实际上是一个修改过的 Qwen2.5-32B-instruct model，该模型在竞赛编程题目和 DeepSeek-R1-0528 生成的回答上进行了训练。
• 字节跳动 (ByteDance) 图像 VQ：优点、缺点与语法错误：一位成员评论说 ByteDance 在这篇论文上“没发挥好” (did not cook)，指出图像 VQ 是向语言嵌入 (language embeddings) 的一种投影。
  • 讨论内容包括来自 SigLIP2 embeddings 的 scale adaptive pooling，VQVAE detokenizer 和以 VQ tokens 为条件的 diffusion model 的训练，并指出了论文中大量的语法错误。

Eleuther ▷ #interpretability-general (5 messages):

Sparse Autoencoder Expansion Factor, Video Prediction Models

• 稀疏自编码器 (Sparse Autoencoder) 扩展因子与 MSE：成员们讨论了 sparse autoencoder，其中需要更大的“扩展因子” (expansion factor) 才能在相同的稀疏水平下达到类似的 MSE (均方误差)。
  • 他们一致认为，MSE、dead neuron percentage 和 l0 sparsity 的改善归功于扩展因子以及模型训练了更多的 epochs。
• 视频预测模拟婴儿发育？：一位成员表示好奇，video prediction models 是否会经历类似于婴儿里程碑的发育阶段，例如获得 object permanence (客体永久性)。
  • 没有人回应关于视频预测的问题。

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

lm_eval 命令，带有 seed 和 limit 的样本处理

• 用户分享 lm_eval 命令：一位用户分享了一个 lm_eval 命令，参数包括 --model hf、--model_args pretrained=/l/users/boda/ONEDRIVE/checkpoints//8b_new_ift_exp4_3epoch,parallelize=True 以及 --tasks poetry_analysis。
  • 他们还包含了诸如 --batch_size 1、--output_path evaluation_results、--seed 42、--include_path /home/abdelrahman.sadallah/mbzuai/lm-evaluation-harness/lm_eval/tasks、--num_fewshot 0、--log_samples、--write_out 和 --gen_kwargs do_sample=False 等参数。
• Seed 和 Limit 参数探讨：一位用户询问在使用相同的 seed 时，使用 limit 参数是否能保证每次处理的样本相同。
  • 该问题旨在澄清在使用一致的 seed 值并对样本数量设置 limit 时，样本处理的可复现性。

Eleuther ▷ #gpt-neox-dev (21 条消息🔥):

结合 FA3 的 TransformerEngine，NVIDIA 的 TransformerEngine 作为 Apex 的替代品，使用 TokenSmith 的数据集工具

• TransformerEngine 支持 FA3：团队确认通过 TransformerEngine 支持 FA3，并可以通过 te_mha 参数启用。
  • 已经使用它训练了一个完整模型，据报告效率非常稳定；团队欢迎对观察到的性能提供反馈。
• TransformerEngine 是 Apex 的替代品，而非 FP8 专用：NVIDIA 的 TransformerEngine (TE) 更多地被定位为 Apex 的替代品，而不是专门用于 FP8 操作。它根据 Attention 块的维度和序列长度提供后端选择逻辑，使用此逻辑。
  • 团队建议使用 requirements/requirements-transformerengine.txt 文件来安装 TE，因为它包含了必要的 FlashAttention (FA) 依赖项。
• 数据集工具：TokenSmith：团队受 NeoX 实验启发，为 Megatron 数据集开发了名为 TokenSmith 的数据集工具。
  • 据一位成员称，最有趣的功能是能够快速导出部分数据、查看数据并以编程方式编辑数据集以创建反事实版本，该工具是在 tokengrams 之上构建的一个薄封装，用于搜索功能。

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

Orthogonal Context Vectors, Monarch Attention, Legendre Memory Unit (LMU), Test Time Training, LLM Bug Pattern

• 用于高效 Attention 的 Context Vectors 近似正交化：一位成员询问是否可以重新构建 Self-Attention，使 Context Vectors 正交化以便进行逐元素组合，从而可能减小 Attention 状态大小。他指出，通常的直觉是拼接这些向量，但这很浪费。
  • 回复指出，Monarch Attention 和类似的亚二次（sub-quadratic）Attention 机制已经存在，但通常仍采用某种形式的矩阵。
• 字节跳动的 Associative Memory 论文可能相关：一位成员提到了字节跳动的 Transformer Associative Memory 论文，强调其提到了 Self-Attention 对非单语义（non-mono-semantic）Embedding 的敏感性，以及 Feed Forward Networks 在叠加无关概念方面的鲁棒性。
  • 然而，有人提到这可能不直接相关，因为正交向量重叠在学习系统中的工作方式不同。
• Legendre Memory Unit (LMU) 作为一种正交多项式方法：提到了一种将历史记录压缩为正交多项式（Legendre）的架构，引用了 Legendre Memory Unit (LMU)。
  • LMU 用于多项式正交化的手工设计状态空间矩阵（state space matrices），与现代学习型的、选择性状态空间模型（selective state space models）形成了对比，后者允许数据相关的流转和遗忘。
• LLM 表现出反复横跳（flip-flopping）的 Bug 模式：一位成员描述了 LLM 中的一种模式，即修复一个 Bug 会引入另一个 Bug，而修复新 Bug 又会重新引入原始 Bug，这表明对过去用户需求的关注不足。
  • 建议将 temperature 设置为 0 可能会解决此问题，并进行手动的 multishot prompting。
• 关于在频道中分享文章的讨论：一位成员提议利用该频道分享有趣的文章，类似于分享论文的方式。
  • 另一位成员认为，除非文章具有学术结构，否则可能不适合该频道，因为已经存在针对不同内容类型的频道；有人希望按主题隔离对话（如在 paper dumps 中），尽管 threads 也可以实现同样的目的。

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

Quaternion products in LLMs, HRM discussion TLDR, Astro's Paper

• 即将进行关于四元数乘积（Quaternion Products）总结的演讲：一位成员将讨论他们在 LLM 中使用 quaternion products 快速总结文本的实验，作为 <t:1754586000:T> 上 softmax attention 的替代方案。
  • 似乎另一位成员的实现在他们目前实验的任务上没有收敛。
• HRM 讨论的简要总结：一位成员请求人力资源管理（Human Resources Management）讨论的 tl;dr，因为他们正忙于应付本科生。
• Astro 的论文引起关注：一位成员询问是否有兴趣研读论文 “paper”。
  • 另一位成员回应说他们愿意讨论这篇论文。

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

ChatGPT Fake Feature, Mistral Large 3

• ChatGPT 的虚假功能愚弄了公众：一位用户分享了一篇博客文章，讨论了一个愚弄了许多人的 ChatGPT 虚假功能。
  • 文章详细介绍了公众和媒体是如何看待这个虚假功能的。
• Mistral Large 3：等待仍在继续：用户仍在等待 Mistral Large 3 的发布，一位用户分享了 Mistral AI 宣布为公民提供 AI 的链接。
  • 另一位用户将此比作当初信任 Apple Maps 导致开车掉下悬崖，因为他们信任 Apple Maps。

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

Cursor Pricing Model, xmcp TypeScript Framework, Grok 4 Livestream, AI Mandate of Heaven Tier List, Veo 3 Image-to-Video

• Cursor 的成本引发取消订阅的考虑：一个 Reddit 帖子 讨论了用户对 Cursor 价格变动的反应，一些用户正在考虑替代方案，并探索通过基础设施投资来降低成本。
  • 用户注意到可以选择退出新的定价模型，从而可能获得更多的 Sonnet 4 请求额度。
• Rauch 发布革命性资源：xmcp：Guillermo Rauch 介绍了 xmcp.dev，这是一个专为构建 MCP servers 设计的新型 TypeScript framework，强调了其与 Next.js 的无缝集成以及在 Vercel 上的原生部署能力。
  • 反馈非常积极，用户对该框架的设计和功能表示赞赏。
• 马斯克造势：Grok 4 即将登场！：Elon Musk 宣布了原定于周三晚上 8 点（太平洋时间）举行的 Grok 4 发布直播。
  • 反应从兴奋到怀疑不等，涉及 Grok 当前的性能以及对潜在偏见的担忧，一位用户调侃道：“我已经能预感到这会是一场混乱”。
• AI 贵族阶层分析：“天命”等级列表：John Coogan 的 AI ‘Mandate of Heaven’ Tier List 引发了讨论，用户建议对 Alibaba、Xai 和 Bytedance 等公司进行调整。
  • 围绕 OpenAI、Claude 和 DeepSeek 的排名展开了辩论，一些人幽默地提到了“L 级”的存在，另一些人则建议建立一个 CEO 等级列表。
• Google 的天才之作：利用 Veo 3 生成突破性的图像：一位用户展示了 Google Veo 3 的 image-to-video 功能 如何实现一致的 AI 角色响应，并提到了一个名为 Alex 的 AI 角色。
  • 该功能已在 Flow 上线，并计划未来在 Replicate 上提供，其工作流能力受到称赞，API 支持也备受期待。

GPU MODE ▷ #general (1 messages):

Job search, Cool use of time

• 成员优先考虑求职：一位成员对某个项目表示感兴趣，但指出目前在投入时间之前会优先考虑找工作。
• 项目被视为值得投入：该成员认为该项目是对时间的酷炫利用，表明一旦求职结束就会充满热情。

GPU MODE ▷ #triton (1 messages):

NVFP4 support on RTX 5090, MXFP4 functionality, Debugging Crashes with NVFP4

• RTX 5090 上的 NVFP4 支持：现状核查：一位成员质疑 NVFP4 是否真的在 RTX 5090 的 master 分支中得到支持，并报告称尽管存在使用它的示例，但仍会出现崩溃。
• MXFP4 运行正常，NVFP4 则不然：该成员表示 MXFP4 运行没有问题，但 NVFP4 会导致崩溃，即使使用了现有的示例代码也是如此。

GPU MODE ▷ #cuda (8 messages🔥):

VSCode debugging, TMA descriptor, Volatile variables, Cutlass repo

• VSCode 调试显示变量被优化掉：一位在 VSCode 中进行调试的成员遇到了变量显示为 optimized out 的情况，并寻求解决方案。
  • 建议包括使用 volatile 关键字以及在 CMakeLists.txt 中设置 -O0 标志，尽管该标志没有出现在输出中。
• 请求用于列优先 GMEM 写入的 TMA 描述符：一位成员询问有关创建 TMA descriptor 以将数据从 SMEM 移动到 GMEM 并写入列优先内存布局的示例。
  • 另一位成员推荐了这篇博客文章，关于如何在 Hopper GPU 上实现极速矩阵转置，这可能会有所帮助。
• Volatile 关键字防止变量优化：一位成员建议使用 volatile 关键字来防止编译器在调试期间优化掉变量。
  • 他们给出了 volatile int myVariable; 的示例，作为声明不应被优化的变量的方法。

GPU MODE ▷ #beginner (14 messages🔥):

CUDA kernel performance, CUDA book recommendations, CS fundamentals for coding, PMPP Book

• CUDA kernel 通过非原地写入（out-of-place writes）提速：一位用户发现，一个带有热循环（hot loop）的 CUDA kernel 在将结果写入独立数组 (B) 而非原地写入 (A) 时，运行速度快了 40%。
  • 该用户怀疑编译器在非原地版本中独立处理加载（load）和存储（store），从而避免了序列化（load -> store -> load），并正在寻求确认方法或提供编译器提示（hints）。
• CUDA 初学者选《CUDA By Example》还是《PMPP》？：一位 C/C++ 经验极少的机器学习工程师 (MLE) 咨询学习 CUDA 的建议，正在考虑《CUDA by Example》和《Programming Massively Parallel Processors》(PMPP)。
  • 一位成员建议不要选择《CUDA by Example》，因为它太旧了（2010 年第一版），并推荐学习最新版的 PMPP（第 4 版），因为该书定期更新。
• 新服务器成员寻求学习指导：一位新成员分享了他们增强 CS 基础和提高代码理解能力的意图，提到他们从哈佛 CS50 开始，并有人建议探索斯坦福 CS229。
  • 其他成员引导他关注现有的 YouTube 讲座，并在 #youtube-lectures 频道中查找。

GPU MODE ▷ #rocm (12 messages🔥):

Make Flags for AMD GPUs, LLVM optimization flags, Loop Unrolling, ISA for Instinct GPUs

• LLVM “全家桶”（kitchen sink）带来性能提升：对于特定用例，一位成员建议对 LLVM 使用“全家桶”策略，即让 LLM 一次性建议一堆优化标志和编译时选项，以检查是否存在容易实现的性能提升空间。
  • 该成员希望这能诱导另一位成员对他开启“咆哮模式”。
• 编译器难以提升循环不变量（hoist loop invariants）：在不同编译器中，通过预计算基地址手动将某些计算移出循环有时会有所帮助。
  • 正如所提到的，“对于这个特定示例，编译器可能能够识别，但对于更复杂的示例则不行。例如，我在 fp8 mm 方案中将其用于 shared->register 加载，如果没有这个操作，编译器会为每个地址分配一个单独的寄存器，即使每组 X 都具有相同的基地址”。
• 将编译器视为 O0：在某些情况下，将编译器视为以 -O0 编译可以帮助更可靠地调整预期行为。
  • 循环展开（Loop unrolling）结合运行时内存访问索引可能会出现问题，但有一些编译器标志可以解决这些问题，而无需调整源代码。
• ISA 可以展示性能收益：阅读 ISA 可以为你提供一些值得尝试的巧妙技巧，尤其是在 Instinct GPUs 上。
  • 在执行操作时参考 ISA 并将其与汇编转储（assembly dump）进行比较，对于发现简单的性能收益非常有用，例如通过不同的汇编指令在内存中一次移动更大的字（words），这在处理 LDS 时非常必要。

GPU MODE ▷ #lecture-qa (1 messages):

LMCache, GPU MODE Discussions

• GPU MODE 成员请求 LMCache 演讲：鉴于社区内对该话题的讨论日益增多，一位成员请求 LMCache 的作者进行一次演讲。
  • 在给定的上下文中没有提供关于 LMCache 的更多细节。
• 持续的 GPU MODE 讨论引发关注：初始消息强调了 GPU MODE Discord 服务器内技术讨论的增长趋势。
  • 这表明社区非常活跃且参与度高，可能需要进一步总结这些讨论中提出的具体技术点。

GPU MODE ▷ #self-promotion (1 messages):

Deep Infra, B200 instances

• Deep Infra 提供廉价 B200 实例：Deep Infra 正以市场最低价 $1.99 / h 提供按需 B200 实例。
  • 他们宣传 1 键部署，10 秒可用；点击此处查看。
• Deep Infra 供应限制：Deep Infra B200 实例的可用性可能有限。
  • 请迅速行动以确保按广告价格获取实例。

GPU MODE ▷ #🍿 (4 messages):

LLM Kernel Generation, KernelBot Data

• LLM Kernel 生成工作激增：虽然为 Kernel 生成训练 LLM 听起来很吸引人，但目前仍有许多项目处于初步探索阶段，例如 KernelBot，正在寻找获取更多数据的方法或使用 LLM 生成合成数据。
  • 目前还没有集中的项目，且尚未完全进入 LLM 训练阶段。
• KernelBot 数据已发布：KernelBot 团队已在 HuggingFace 发布了数据集。
  • 如果你有兴趣贡献，请查看。

GPU MODE ▷ #submissions (3 messages):

H100 Results, B200 Results, trimul, grayscale_py_b200-dev

• H100 trimul 竞赛激烈收官：一名成员在 H100 的 trimul 排行榜上以 35.9 ms 获得第二名。
  • 另一名成员在同一 trimul 排行榜上以 45.5 ms 在 H100 上成功运行。
• B200 grayscale_py_b200-dev 竞赛结束：一名成员在 B200 的 grayscale_py_b200-dev 排行榜上以 1746 µs 获得第二名。

GPU MODE ▷ #status (3 messages):

Triton Leaderboard Templates, grayscale py b200

• 用户请求 Triton 排行榜模板：一名用户正在寻求帮助，以寻找 Triton 的排行榜模板。
  • 具体用例是针对 grayscale py b200。
• 模板请求详情：用户指定需要适用于 Triton 环境中 grayscale py b200 应用的模板。
  • 这表明了一个可能涉及图像处理或特定硬件配置的专门用例。

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

Multi-agent FLE, Local Factorio Models, Automatic Design of Factorio Blueprints

• Colin 暂停多 Agent FLE 工作：一名成员宣布将暂停与多 Agent Factorio Learning Environment (FLE) 工作相关的会议，但仍可就 RL 训练、LLM 及相关话题进行讨论。
  • 他们表示，即使退出了活跃的项目参与，仍有兴趣继续讨论 RL 训练、LLM 或任何其他相关内容。
• Factorio 本地模型代码查询：一名成员询问了用于在 Factorio 上运行本地模型的代码可用性，特别是询问另一名成员是否仍保留相关代码。
  • 该成员回复说他们会尝试寻找，并要求如果到特定时间还没找到，请再次提醒。
• 蓝图自动设计论文：一名成员分享了论文链接 “Towards Automatic Design of Factorio Blueprints“。
  • 另一名成员随后跟进，询问用于运行本地模型的代码。

GPU MODE ▷ #amd-competition (1 messages):

GPUMODE dataset, kernelbot-data

• GPUMODE 数据集开放：GPUMODE/kernelbot-data 数据集现已向公众开放，欢迎探索和分析。
  • 鼓励社区成员检查其结构并为其理解做出贡献。
• KernelBot 数据现已开放！：与 KernelBot 关联的数据集 GPUMODE/kernelbot-data 已发布供开放访问。
  • 有兴趣的个人现在可以自由探索和利用这一资源。

GPU MODE ▷ #cutlass (1 messages):

soniczun: 嗨！当我在 VS Code 中调试时，一些变量显示为 <optimized out>，该如何解决？🙋‍♂️

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

A100/H100 租赁、Runpod 体验、Lambda Labs 体验、寻找学习伙伴、YOLOv11 部署

• 用户寻求 A100/H100 租赁推荐：一位成员正为一个大型 LoRA finetuning 项目寻找租赁几块 A100 或 H100 GPU 的途径，并征求供应商推荐。
  • 他们发现 Runpod 和 Lambda Labs 似乎更便宜，但想听听社区的实际体验。
• Runpod 受到好评：一位成员非常喜欢使用 Runpod，但现在已转为使用自己的 GPU。
• 寻找自学伙伴：一位成员希望寻找一些自学同伴。
  • 另一位成员建议去 off-topic 频道 寻找学习伙伴。
• 关于 YOLOv11 部署的疑问：一位成员询问是否可以将训练好的 YOLOv11 模型上传到 Hugging Face，并使其能够部署到 HF inference endpoint。
  • 另一位成员建议阅读 HF documentation。
• EasyNegative 插件使用失败：一位成员在将 EasyNegative 与 Stable Diffusion webui 配合使用时遇到困难。
  • 该成员从 Civitai 下载了 EasyNegative.pt 并放入 embeddings 文件夹，但无论开启还是关闭都看不出任何区别。

HuggingFace ▷ #today-im-learning (2 条消息):

GPT-2 内核、GPT-NeoX 移植到 C

• GPT-2 内核创建：用户请求创建一个实现 GPT-2 的内核。
  • 这意味着开发一个底层、高效的 GPT-2 架构实现，可能针对特定硬件或嵌入式系统。
• GPT-NeoX 移植到 C：用户还请求将 GPT-NeoX 移植到 C 语言。
  • 这表明用户希望获得一个性能更高或更具移植性的模型版本，利用 C 语言 的系统级优化能力和更广泛的硬件兼容性。

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

Arena-RLHF 开源发布、MCP YouTube 分析工具包、PsychKG：心理学知识图谱

• Arena-RLHF 开源竞技场风格的人类偏好学习：一种在竞技场风格的人类偏好数据（LM Arena、Agent Arena）上进行 RLHF 的简便方法已使用 HuggingFace 开源。
  • 该仓库已在 GitHub 上线。
• MCP YouTube 分析工具包在六个月后发布：一位成员发布了他们最大的开源 AI 项目——基于 MCP 的 YouTube 视频分析工具包，该工具包包含多项功能，并在 Claude Code 的帮助下仅用 2.5 天 构建完成；LinkedIn 帖子 和 Medium 文章 分享了更多细节。
  • GitHub 仓库 可供查阅。
• PsychKG 构建心理学极简知识图谱：一篇新的 博客文章 介绍了一个轻量级流水线，使用 OpenAI models 和 Pydantic 从研究论文中提取结构化三元组，以获取 心理学概念及其测量工具。
  • 该流水线已应用于数千篇心理学论文，作者鼓励大家提供反馈和代码审查。

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

SmolVLM2、AI2D、模型性能差异

• SmolVLM2 在 AI2D 上的性能下降被披露：SmolVLM2-256M 模型在 AI2D 数据集上的性能相对于初始版本的 SmolVLM 下降了 12%。
  • 社区成员正在寻求能够解释 SmolVLM2 与其前身之间性能差异的资源，特别是针对已注意到的 AI2D 性能下降问题。
• 探寻 SmolVLM2 性能背后的秘密：社区寻求深入了解为什么 SmolVLM2 在除视频处理之外的各种任务中与原始 SmolVLM 存在差异。
  • 讨论旨在揭示影响 SmolVLM2 在不同应用中有效性的潜在因素，特别是关于其在某些数据集上性能退化的问题。

HuggingFace ▷ #NLP (1 条消息):

GLoVE 模型对称性

• GLoVE 模型在对称性方面存在困难：一位成员询问为什么在 GLoVE 模型中，简单地反转角色无法解决对称性问题，特别是关于共现概率（co-occurrence probabilities）的问题。
  • 这个问题源于 GLoVE 论文中的一段话，讨论了为什么单词 x 在单词 k 的上下文中出现的概率理想情况下应该与单词 k 在单词 x 的上下文中出现的概率相同。
• 在 GLoVE 中反转角色：一位用户质疑简单地交换角色是否能解决 GLoVE 模型中的对称性问题。
  • 该用户强调该模型不遵循对称性规则，即 x 在 k 上下文中的共现概率应等于 k 在 x 上下文中的共现概率。

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

Axon 聊天机器人，Meta Llama 3.2 等待访问权限，黑客专家提供服务，AI Agents 认证，哈佛 CS50 与斯坦福课程

• AI 爱好者记录自 2023 年以来的历程：一位名叫 Chad 的成员分享了他们自 2023 年 7 月以来的 AI 历程，从评测 Axon 聊天机器人和使用 Bing 创建图像开始，然后转向使用 Kaiber 进行轻量动画和 diffusion。
  • Chad 对 AI 的快速进步以及掌握 AI 技能的人获得成功的潜力表示兴奋，并提到了他们的 vibe coding 经验。
• Llama 3.2 访问请求停滞：一位成员就其 Meta Llama 3.2 模型访问请求寻求帮助，该请求自昨天以来一直处于 pending 状态。
  • 未提供解决方案，但这突显了课程参与者可能面临的访问问题。
• 黑客专家打折提供服务：一位新成员推销其“黑客专家”服务，以低于在线课程的价格提供道德黑客之路的培训、实践、支持和指导。
  • 该成员在消息中艾特了多位其他用户。
• AI Agents 认证项目启动：Business Analytics Institute 宣布了其 AI Agents 认证项目，这是一个深入智能自动化和 Agentic AI 的实战之旅，将于 2025 年 7 月 12 日开始，仅限 7 名学员的小班授课。
  • 该项目专注于通过真实项目和个性化导师指导来掌握 LLMs、浏览器自动化和 agentic workflows，你可以在此处申请。
• 哈佛 CS50 与斯坦福课程的选择困境：一位成员寻求建议，是继续学习哈佛 CS50 课程，还是转向 CS229 等斯坦福课程，以加强计算机科学基础和对编程的理解。
  • 另一位用户分享了编程技巧，强调理解软件功能并将其分解为代码，同时学习逻辑结构、OOP 原则和数据结构等基础知识。

Modular (Mojo 🔥) ▷ #general (17 条消息🔥):

Nabla GitHub Repo, Modular 发布节奏, Mojo 路线图更新, Windows 上的 Mojo, Intel Ultra 7 GPU/NPU 上的 MAX

• Nabla 库获得认可：一名成员认可了 Nabla 库，与此同时 Modular 频繁发布版本以支持 CPU、NVIDIA GPU 和 AMD GPU，并对 Mojo 语言和编译器进行了补充。
  • 他们认为构建和训练工具对于重构 AI 技术栈至关重要，暗示 Modular 可能会提供相关解决方案。
• Mojo 路线图更新即将到来：一位 Modular 团队成员提到，最新的 Mojo 路线图已发布在 论坛上，更新版本即将发布。
  • 这表明 Mojo 生态系统正在持续开发并增加新功能。
• Windows 支持对 Mojo 来说仍很遥远：一名团队成员警告称，由于系统 API 存在显著差异，Mojo 目前仅支持 WSL，实现完整的 Windows 支持需要大量工作。
  • 回复中澄清，msys 无法充分解决 Windows 上存在的驱动程序交互问题。
• Ultra 7 GPU/NPU 支持状态：一位用户询问关于在 Intel Ultra 7 258V GPU 或 NPU 上运行 Mojo 和 MAX 的情况，表示在文档中难以找到明确信息。
  • 他们描述了在 NixOS 上编译 Intel 的 DPC++ 编译器并打包 OneAPI/SYCL 程序的努力，同时寻求通过在 Mojo 上使用 MAX 运行 NPU 或 GPU 来避免 Python 和其他语言的冗余。
• MAX 尚未支持 Intel GPU：一位社区成员表示，目前仅支持 NVIDIA 和 AMD GPU，并引用了 官方 FAQ。
  • 他们澄清说，目前还没有关于支持 Intel GPU（特别是 Intel NPU 笔记本电脑的边缘推理）的近期计划的官方公告，并引导用户前往 Modular 论坛获取官方答复。

Modular (Mojo 🔥) ▷ #mojo (14 条消息🔥):

GPU 编程模型, 3D Block 拟合, CUDA

• GPU 编程模型依然适用：一位成员询问一本 2010 年出版的关于 GPU 编程的书籍 是否仍然适用，考虑到 GPU 领域的快速演变，另一位成员确认大部分编程模型保持不变，并提到了 2022 年 CUDA 的新增内容。
  • 一位初学者对此连续性表示欣慰，庆幸需要追赶的历史较少。
• 3D Block 拟合到单个 SM：一位成员询问，如果 Kernel 不使用局部/共享内存，拟合在单个 Streaming Multiprocessor (SM) 上的 3D Block 是否会完全放置在该 SM 上。
  • 他们还询问，对于单个 SM 来说太大的 Block 是否会动态“溢出”到另一个 SM。
• 建议初学者使用抽象 GPU 模型：一位成员建议初学者坚持使用 抽象 GPU 模型 并编写各种算法和 Shader，尤其指出 GPU 编程不如 CPU 编程那样直观。
  • 该成员建议，在获得实践经验后，更深层次的理解会更容易到来，辨别何时保持心理模型简单或复杂是很重要的。

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

Spaced Repetition, B1 等级播客, 对话功能, YouTube 学习, NotebookLM 运行异常

• **Spaced Repetition 功能讨论：一名成员询问是否能在 NotebookLM 中实现 **Spaced Repetition（间隔复习）或 Flashcard（抽认卡）功能，另一名成员则询问关于为 英语 B1 等级 学习者创建 Podcast 的事宜。
  • 讨论中未提出具体的解决方案或替代方案。
• **NotebookLM 对话功能模仿商业风格：一位用户分享了对 NotebookLM **对话功能 的反馈，指出其类似于欢快的 How it Works 或 Bloomberg Business 风格的访谈。
  • 该用户赞赏该工具能够识别商业分析演示文稿中的 细节 (minutiae) 和宏观信息，并称赞其报告的准确性。
• **探讨 YouTube 的教育效用：一名成员就大家使用 **YouTube 进行学习 的情况在群组中发起了投票。
  • 提供的消息中未记录任何回复。
• **NotebookLM 用户排查“运行异常 (Tripping)”问题**：一位用户报告 NotebookLM 出现“运行异常”，并附上了截图。
  • 另一位用户建议删除并重试，但原帖作者表示，在尝试了 14 次 后，该问题在特定的 PDF 文件上依然发生。
• **NotebookLM 布局更改引发困惑：一位用户询问最近 **NotebookLM 界面 的变化，特别是将 “source”、”chat” 和 “studio” 拆分为独立屏幕的改动。
  • 他们表达了困惑并寻求澄清，但关于 Pro 版本 是否受影响尚未给出解决方案。

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

音频自定义按钮消失, 将 YouTube 转化为学习系统, 缺少自定义选项, 批量删除源文件, 官方 API 发布

• 音频自定义按钮消失：一位用户注意到 音频自定义按钮 消失了，并报告称目前唯一的选项是 Interactive Mode。
  • 其他成员也反映了类似的 自定义选项 问题。
• 新的 YouTube 学习系统上线：一名成员宣布创建了一个系统，可以将 YouTube 转化为一个包含 AI 和组织工具的完整学习系统，类似于 NotebookLM 但专门针对 YouTube 进行了优化。
  • 他们在社区中调查了大家对这一新系统的兴趣。
• 需要批量删除源文件功能：一位用户询问是否可以在一个 Notebook 中同时删除多个源文件。
  • 聊天中未立即提供解决方案。
• API 发布日期仍是谜团：一位用户向社区询问关于官方 API 发布日期的任何线索。
  • 聊天中未分享具体信息。
• NotebookLM 布局演变：一位 Pro 版本 用户询问 NotebookLM 的格式是否发生了变化。
  • 他们提到，以前可以在一个屏幕中同时看到 source、chat 和 studio，但现在情况不再如此。

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

MCP Server 实用性, 付费 MCP Server, 追踪 MCP 使用情况, 通过 MCP 影响 ChatGPT, MCP 的 API 路由层

• MCP Server 激增，实用性引发讨论：成员们讨论了现有 MCP (Model Context Protocol) server 的实用性，有人推荐通过此链接查找来自 Elasticsearch、Kagi 和 Redis 等来源的 server。
  • 一位成员表示 目前大多数 MCP server 都是没用的。
• 付费 MCP Server 的未来：提出了 付费 MCP server 的潜力，并表示有兴趣寻找具有真实付费用户群的 概念验证 (PoC) server。
  • 一位成员问道：有人知道任何拥有真实付费用户群的付费 MCP server 吗？
• 追踪已创建 MCP Server 的使用情况：围绕 追踪已创建 MCP server 的成功使用情况 展开了讨论，包括监控用户行为、竞争分析、生产问题和请求类型。
  • 一位成员询问：你是否发现人们强烈希望追踪用户如何使用你的 MCP server，你的 MCP server 与竞争对手相比如何，是否存在任何生产问题，甚至输入到 MCP server 的请求类型是什么。
• 通过 MCP server 影响公开版 ChatGPT：一位成员正在探索如何影响 公开版 ChatGPT 从 MCP server 获取 结构化产品数据，而不是依赖电子商务网站上嵌入的 json-ld 或结构化标记。
  • 他们问道：有没有办法影响面向公众的 LLM，使其更倾向于从定义的 MCP (Model Context Protocol) server 获取数据，而不是从网站抓取结构化数据？
• 聚合多个 MCP Server 的 API 路由层：一位成员询问了关于 API 路由层 的信息，该层可以连接到多个 MCP server，并可能使用 NLP 来确定要查询的最相关 server。
  • 他们问道：有人知道目前有 API 路由层了吗？我可以将其设置为一个“MCP 连接”，然后分支到几十个 MCP server？

MCP (Glama) ▷ #showcase (9 条消息🔥):

AI Agents with MCP 早期发布, 端到端 Agent 框架推荐, TypeScript 重写的 Tree Sitter MCP, 类型化的 MCP SDK 类型与 Zod Schema

• 《AI Agents with MCP》一书进入早期发布阶段：一位成员宣布了他们的新书 AI Agents with MCP 的早期发布。
  • 另一位成员回应道：太棒了！(Hell yeah!)
• 寻求端到端 Agent 编排框架：在新书发布后，一位成员征求端到端 Agent 的框架推荐。
  • 另一位成员回应说他们 并不完全讨厌 Langgraph，但尚未充分探索其他框架。他们还提到喜欢 Letta 的 记忆功能 (memory features)。
• TypeScript 重写提升 Tree-Sitter-MCP：一位成员宣布他们用 TypeScript 重写了 tree sitter mcp，并分享了 npm 软件包链接。
  • 该成员还欢迎对该项目进行贡献，并指出有几个工具待添加。
• 类型化的 MCP SDK 类型出现：一位成员分享了 正确类型化的 MCP SDK 类型和 zod schema 的链接。
  • 另一位成员表示感谢，并表示可能会有一些问题。

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

Tinygrad 的优势，Halide vs MLIR vs TVM，Exo-lang 替代方案

• Tinygrad 致力于硬件无关的代码生成：George Hotz 详细阐述了 Tinygrad 的目标，即通过 UOP 图优化以硬件无关的方式生成微调代码，正如在最近的会议中所讨论的那样。
  • 其目标是实现与 CUDA 以外的不同硬件的互操作性，重点在于“将 Petaflop 商品化”。
• Halide 框架启发了 Tinygrad 的方向：Tinygrad 旨在效仿 Halide 论文 的框架用于 ML，绕过 CUDA 以实现速度和硬件互操作性。
  • George Hotz 认为 Halide 比 MLIR 和 TVM 具有更清晰的概念，主张在所有 dtype 和后端采用单一、快速且正确的方式执行计算。
• Exo-lang 提出 Halide 和 TVM 的替代方案：一位成员强调了 Exo-lang，它在与 Halide 的对比中表现得“非常出色”，作为 Halide 的替代方案，并链接到了他们的 GitHub 和 arXiv 论文。
  • George 指出 Tinygrad 将采用类似的编译过程，但也对 primitive ops 的数量以及代码中使用字符串查找（string finds）表示担忧。
• python3 -m tinygrad.apps.llm 已准备好进行测试！：George Hotz 宣布 python3 -m tinygrad.apps.llm 已合并并准备好进行测试，鼓励用户尝试并为即将发布的版本报告 Bug。
  • 一位用户在使用 LLM 时遇到了 RuntimeError: token not found。

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

AI 模型基准测试的现状，适用于 Aider 的高性价比快速模型，用于训练的 Aider 数据集，Claude Code 的 Hook

• AI 模型基准测试正在沦为“刷分”：据一位成员称，实验室正在对基准测试进行“刷分”（gaming），因此应关注那些无法有效作弊的基准测试。
  • 他们补充说，“作弊”会促使模型改进，而改进基准测试会推动进步；基准测试的多样性也至关重要。
• Aider 的机器人挂载在 Claude 上：一位成员正在利用 Claude code 的 Hook，让 aider 自动检查 Claude code 所做的编辑。
  • 该机器人还会向 Claude code 提供反馈，并妥善跟踪任何未解决的问题（open issues）。
• 建议将 Devstral 作为 Aider 的模型：一位用户建议将 Devstral 作为 Aider 的快速、可靠且经济的模型，用于自动检查 Claude code 的编辑。
  • 另一位用户建议将 ERNIE 也作为一种快速且廉价的选择 (https://leaderboard.techfren.net/)。
• Aider 数据集已准备好进行训练：一位成员创建了一个用于训练的 aider 数据集（位于此处：https://raw.githubusercontent.com/supastishn/synthetic-data-generator/refs/heads/master/conversations.json）。
  • 该数据集每天都会更新更多示例，目前已生成约 90 个示例。

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

git subrepos，aider 的局限性，Hugo 网站，git submodules，vendor 子仓库

• Subrepos 给 Aider 带来了问题：一位成员想在 Hugo 网站中使用 git subrepos，其中网站副本在主仓库（mother repo）中，而主题在子仓库（subrepo）中，但 aider 似乎局限于主仓库，会忽略子仓库。
  • 该成员指出这很遗憾，因为他们经常希望进行的更改会同时导致两个仓库的变动（例如，添加一个新属性，然后在主题中使用该新属性）。
• Git Submodules 对人类来说也太难了？：一位成员回应说，git submodules 对人类来说也很难处理。
  • 他们建议或许可以将子仓库进行 vendor 处理，而不是将其作为 submodule 使用。

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

AI safety program, ML Understanding, Cohere Labs server, Open Science Initiative Application

• Cohere Labs 等待 AI safety 寻求者：一位用户询问了关于 AI safety program 和 ML Understanding 等频道的情况，一名成员澄清说这些频道位于专门的 Cohere Labs server 上。
  • 他们指向了此链接，其中包含如何加入该小组的指南。
• 引导 Open Science 申请迷宫：一位用户对加入 Open Science Initiative 表示困惑，指出点击提供的链接后没有直接的“加入我们”按钮。
  • 他们报告称已填写表格，正在等待进一步指示或电子邮件确认。
• Cohere 的 Open Science Initiative —— 社区邀请：一名成员分享了 Open Science Initiative 申请页面的直接链接：Cohere Open Science Initiative。
  • Cohere Labs 团队会审核每份申请，并通邮件发送邀请；由于“极高的请求量”，申请者被告知请耐心等待。

Cohere ▷ #🔌-api-discussions (8 条消息🔥):

Embed v4, Image tokens, Negative feedback

• Embed v4 支持文本和图像：Embed v4 同时支持文本和图像搜索查询，API 会根据 content 字段中是否存在 image_url 来检测内容类型。
  • 如果内容包含 image_url 类型，你将按 image tokens 而非 text tokens 计费。
• Embed v4 的 Image token 计费：一位用户询问在 Embed v4 试用期间是否会因 image tokens 计费，确认结果是当 content 字段中出现图像 URL 时会发生这种情况。
  • 产生 image token 计费是因为 API 在 content 字段中检测到了 image_url 类型。
• Embed v4 在处理负面提示词时遇到困难：一位用户反馈 Embed v4 在处理 negative prompts（如“没有叶子的苹果”）时表现不佳。
  • 他们指出“没有叶子的苹果”的结果与“有叶子的苹果”基本相同，但总体而言 Embed v4 表现非常出色。

Cohere ▷ #👋-introduce-yourself (4 条消息):

AI Consultant Introduction, ML Learning Path Guidance

• AI Consultant 加入 Cohere 社区：一位曾在 OMNO AI 和 Adlytic AI 担任 CTO 的 AI consultant 介绍了自己，他专注于实时 computer vision 系统、RAG pipelines 和 fine-tuning LLMs。
  • 他拥有 11 篇研究论文，并积极寻求在社区内进行 Generative AI 研究 方面的合作。
• 毕业生寻求 ML 学习路径的专家指导：一位来自巴基斯坦的软件工程毕业生目前正在学习机器学习，寻求关于优先关注哪个领域的指导：computer vision、robotics 或 deep learning frameworks。
  • 他在数据分析和预处理方面有经验，但现在正在训练模型并寻找专家建议。

DSPy ▷ #general (17 条消息🔥):

DSPy 3.0, Data and AI summit, Fast Inverse Square Root origin, SIMBA

• DSPy 3.0 DAIS 演讲发布！：一名成员分享了他们 6 月中旬在 DAIS 上关于 DSPy 3.0 (beta) 的演讲 现在已上传至 YouTube。
  • 这是预料之中的，因为他们今天早上发邮件询问视频是否可以公开，对方回复说一周内可以。
• 快速平方根倒数函数揭秘：一名成员表示他们不确定 fast inverse square root 的来源，这成为了一个不错的案例。
  • 另一名成员建议他们应该找一个更好的例子，因为这似乎是一个可重用库的一部分，而不是他们认为的那种一次性黑客手段。
• SIMBA 指标受到赞赏：一名成员指出 指标中针对 SIMBA 的反馈看起来是一个杀手级功能。
• Data and AI Summit DSPy 视频列表：一名成员提供了 Data and AI summit 中 所有 dspy 视频 的列表：
  • 视频 1, 视频 2, 视频 3, 视频 4, 视频 5。

DSPy ▷ #examples (1 messages):

hammer_mt: 我想只是在 signature.py 附近随便看看

Nous Research AI ▷ #general (5 messages):

Node Shifting, Result Interpretation, Reverse Commonality

• 节点因质量而偏移：一位用户建议偏移一个“低质量”节点，并将其替换为一个“高度独特且语境化”的节点。
  • 他们提出无需更改测试，只需调整结果解释（result interpretation），这意味着节点具有反向共性（reverse commonality）。
• 巫师向朋友们问好：一名成员介绍自己为一名巫师并向大家打招呼。
  • 他们祝愿大家尽情计算并享受这一天。

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

Temperature and Token Count, r1-0528 weak influence

• Token 数量受 Temperature 影响？：一名成员表示 Temperature 越高，回复就越长，暗示 Temperature 会影响 Token 数量。
  • 另一名成员表示赞同，认为仅从使用各种 AI 服务的经验来看，这通常是正确的。
• r1-0528 影响较弱：一名成员分享说，经过快速测试，在最小化 Token 时，r1-0528 似乎只有微弱的影响。
  • 该成员表示，提示词中的数字表示 Prompt 中相对的生成 Token（completion tokens）数量。

Nous Research AI ▷ #research-papers (3 messages):

Arxiv Papers, Image analysis, PDFs

• 用户分享 Arxiv 论文链接：一名成员分享了一个 Arxiv 论文 链接以及一张随附图片。
  • 另一名成员简单地回复了 “很有趣” 并分享了 另一篇 Arxiv PDF。
• 对随附图片的图像分析：一名用户分享了一张图片，一个名为 Image Analysis 的 AI 机器人似乎对该图片进行了处理。
  • 机器人的描述在消息中被隐藏了。

Nous Research AI ▷ #research-papers (3 messages):

Image Analysis, Arxiv papers

• 成员分享 Arxiv 论文：一名成员分享了一篇 Arxiv 论文 并附带一张图片，引发了讨论。
• 分享了有趣的 Arxiv 论文：另一名成员回应称其很有趣，并分享了 另一篇 Arxiv 论文。

LlamaIndex ▷ #announcements (1 messages):

MCP Office Hours

• **MCP Office Hours 活动即将开始！：关于 **MCP 一切内容的 Office Hours 交流活动将在约 10 分钟后在 这里 开始。
• Office Hours：Office Hours 即将开始。

LlamaIndex ▷ #blog (2 messages):

LlamaCloud MCP Servers, Agent Workflows as MCP, MCP Tools

• Office Hours 将涵盖 LlamaCloud MCP 服务器：下一次 Office Hours 聚会将全部围绕 MCP 展开，并简要介绍 LlamaCloud MCP 服务器。
• 将 Agent 工作流与现有 MCP 工具结合使用：Office Hours 将涵盖如何将现有的 MCP 工具与 Agent 工作流 结合使用，以及如何将 Agent 工作流作为 MCP 提供服务。
  • 具体来说，它将通过 这段视频 讨论如何将提取 Agent（extract agents）作为 MCP 工具 使用，以及如何通过 MCP 查询 LlamaCloud 中的任何索引。

LlamaIndex ▷ #general (10 messages🔥):

LlamaParse 文本字段移除, Django Prompt 管理, Haystack Prompt 实现, 用于 Prompt 元数据的 Langfuse API

• LlamaParse 文本字段清除探讨：一位用户询问是否有办法配置 LlamaParse，在生成的 JSON 输出中排除 text field 以简化其工作流，但另一位成员回复称目前没有该选项。
  • 他们建议了一个变通方案：在获取 JSON 后再将其删除。
• Django Prompt 难题破解：一位拥有包含 20 多个 prompt 的 Django 项目的用户表示管理起来很困难，因为这些 prompt 是以简单的字典格式存储的。
  • 他们寻求关于在每个 prompt 旁边存储额外元数据（如 inputs, expected outputs, descriptions, and design decisions）的最佳方式的建议。
• Haystack 历史 Prompt 处理提示：一位成员回忆起曾为 Haystack 实现过类似的 prompt 管理系统，并对 LlamaIndex 的 prompt 库表示出热情。
  • 该成员建议将当前的 prompt 字典扩展为 嵌套字典 (dict of dicts)，以便为每个 prompt 附加元数据。
• 用于 Prompt 元数据的 Langfuse API 发布：一位用户建议使用 Langfuse，它提供了 prompt 管理功能，并能够通过 Langfuse API 获取 prompt 及其元数据。
  • 该成员指出 Langfuse 既可以云端托管，也可以自托管（开源）。

Torchtune ▷ #papers (5 messages):

MoE 训练, 线性缩放的缺点

• MoE 训练技术评估：一位成员分享了 fengyao.notion.site 的链接，其中描述了 MoE 训练 的技术和结果。
  • 他们想知道是否能在不需要 dense fwd pass 的情况下，以更低的成本获得类似的结果。
• 线性缩放的权衡：一位成员表示，由于线性缩放的缺点，序列建模对 LLMs 并不友好。
  • 他们补充说不喜欢 selective scan 的性能，但没有提供任何链接或进一步信息。

Manus.im Discord ▷ #general (5 messages):

Discord Bot, Manus 访问权限

• 澄清 Manus 的 Discord Bot 性质：一位用户询问如何将 Manus 添加到他们的 Discord 服务器，随后得到澄清：这专门是 他们自己的 Discord bot，不开放给外部添加。
  • 进一步解释指出，用户可能会误以为可以通过该 bot 控制 Manus，但这是不可能的，因为它既不可控也无法从外部邀请。
• Manus 的有限控制：成员们澄清了该 bot 的有限功能，强调用户无法通过 Discord bot 控制 Manus。
  • 该 bot 并非设计为可邀请的，也不提供对 Manus 的直接控制。

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

英语语言, tenor.com

• 英语语言请求：一位成员请求另一位成员使用 英语。
  • 这暗示原始消息可能是用另一种语言发送的。
• 分享了 tenor.com 的 GIF：一位成员分享了一个 来自 tenor.com 的 GIF。
  • 该 GIF 内容为 gohine hohino no hohineee。