AI News

今天没发生什么。

· 12141243

以下是为您翻译的内容：

2025年4月23日至24日 AI 新闻摘要：涵盖了 OpenAI、Google DeepMind、Anthropic 以及 Epoch AI Research 等公司的最新模型发布、基准测试及研究进展。

#image-generation #model-benchmarks #vision-language-models #music-ai #ai-experiences #ai-research #supercomputers gpt-image-1 o3 o4-mini gpt-4.1 dam openai google anthropic epoch ai research

平静的一天

2025年4月23日至4月24日的 AI 新闻。我们为您检查了 9 个 subreddits、449 个 Twitter 账号 和 29 个 Discord 服务器（214 个频道，6713 条消息）。预计节省阅读时间（以 200wpm 计算）：560 分钟。我们的新网站现已上线，支持全文搜索，并以精美的 vibe coded 方式呈现所有往期内容。请访问 https://news.smol.ai/ 查看完整的新闻细分，并在 https://x.com/Smol_AI 向我们提供反馈！

这是获取 AI Engineer 超级早鸟票 的最后一周！

查看全新的 AINews 网站：https://news.smol.ai/

AI Twitter 综述

模型与基准测试

  • OpenAI 的图像生成模型 gpt-image-1 现已在 API 中可用，为开发者提供更大的参数控制权，包括审核敏感度、图像质量/生成速度以及输出格式选项 @kevinweil, @kevinweil, @kevinweil, @sama。该 API 允许控制审核敏感度、质量与生成速度的权衡、背景以及输出格式。Instacart、InVideo、Canva 和 HubSpot 等公司的开发者已经在使用该 API。@OpenAIDevs, @OpenAIDevs。
  • OpenAI 的新模型 o3 和 o4-mini 在 Arena 排行榜上获得了很高的排名。o3 模型总榜排名第 2，并在风格控制（Style Control）、数学（Math）、编程（Coding）和硬核提示词（Hard Prompts）方面与 Gemini 2.5 Pro 并列第 1。o4-mini 闯入前 10 名，并在数学方面超越 o1 位居第 1。GPT-4.1 在硬核提示词、数学和风格控制方面排名前 5 @lmarena_ai。新模型的详细细分显示，o3 在风格控制、硬核提示词、编程和数学方面排名第 1，而 o3 和 o4-mini 在数学方面均为第 1。GPT-4.1 在硬核提示词、数学和长查询（Longer query）方面排名前 5 @lmarena_ai。
  • Describe Anything Model (DAM) 是 Nvidia 推出的一款 3B 视觉语言模型，可为图像和视频生成带有局部引用的详细说明（captions）。它通过使用 VLM 生成说明，扩展了现有的分割和引用表达式生成数据集（如 REFCOCO），并推出了新的基准测试和演示 @mervenoyann, @mervenoyann, @mervenoyann。模型、数据集和基准测试已发布，模型已在 Hugging Face 上线 @reach_vb。
  • Google DeepMind 在由 Lyria 2 模型驱动的 Music AI Sandbox 中引入了新功能，正在帮助像 Isabella Kensington 这样的创作歌手创作下一部杰作。这些功能包括用于生成和重塑音乐的创建（create）、扩展（extend）和编辑（edit）功能 @GoogleDeepMind, @GoogleDeepMind, @GoogleDeepMind, @GoogleDeepMind。
  • Anthropic 正在探索 AI 模型拥有自身体验的可能性，并随着 AI 模型变得越来越复杂，启动了一项研究计划来对此进行调查 @AnthropicAI。

  • OpenAI 推出了新版本的 deep research，扩大了 Plus、Team 和 Pro 用户的限制，并为免费用户提供了轻量级版本，以提高速率限制并使其更易于访问 @OpenAI, @OpenAI, @OpenAI。轻量级版本由 OpenAI o4-mini 的一个版本驱动 @OpenAI。

  • Epoch AI Research 发布了一个涵盖过去六年 500 多个最大 AI 超级计算机的数据集，揭示了在扩展规模、地理位置、所有权和电力需求方面的趋势 @EpochAIResearch。在更多芯片和单芯片性能提升的推动下，性能每 9 个月翻一倍。成本大约每年翻一倍，电力需求也同样每年翻倍。美国在全球 AI 超级计算机性能中占据主导地位，私营部门控制着超过 80% 的 AI 计算能力 @EpochAIResearch, @EpochAIResearch, @EpochAIResearch, @EpochAIResearch, @EpochAIResearch, @EpochAIResearch, @EpochAIResearch。
  • LlamaIndex 与 Milvus 集成以支持使用 BM25 的全文搜索，从而为结合了向量搜索和传统关键词匹配的 RAG 流水线实现混合搜索 @llama_index。

Agent 工作流与工具

  • Perplexity Assistant 已集成到 Motorola 设备中，在 Moto 生态系统中提供对搜索和助手功能的直接访问，包括 3 个月的 Pro 订阅 @AravSrinivas, @AravSrinivas, @AravSrinivas, @perplexity_ai, @perplexity_ai。Perplexity Android 应用将预装在所有新款 Motorola 设备上，并针对 Moto Razr 进行了优化 @AravSrinivas。
  • Perplexity 推出了 iOS Voice Assistant，可以在 iPhone 上回答问题并执行操作，包括播放媒体、起草电子邮件、移动会议、预约用车和设置提醒 @AravSrinivas。iPhone 上的 Action button 可以自定义为 Perplexity Voice Mode，允许用户在不打开应用的情况下使用助手 @AravSrinivas。该助手可以研究地点并叫车或导航到该地点，播放播客、视频和歌曲，并使用 Apple Mail 和 Calendar 查看日程、安排会议和发送电子邮件 @AravSrinivas, @AravSrinivas, @AravSrinivas, @perplexity_ai, @perplexity_ai, @perplexity_ai, @perplexity_ai。
  • Andrew Ng 和 Hugging Face 提供了一门关于使用 Hugging Face smolagents 构建 Code Agents 的新短课，该课程使用 LLMs 为一系列操作生成单个代码块 @AndrewYNg。Code agents 的表现优于 function-calling agents，并将多个函数调用合并为单个代码块 @DeepLearningAI。
  • Jerry Liu 概述了在文档上构建智能体（Agentic Document Workflows, ADW）的参考架构，涉及解析与提取、检索、推理和执行操作 @jerryjliu0。ADW 具有更好的扩展性，并能与现有的软件生态系统集成。
  • 一个用于构建多智能体系统（multi-agent systems）的新开源 IDE 已发布，由 OpenAI Agents SDK 提供支持，可连接到 MCP 服务器，并使用 HTTP 或 SDK 集成到应用中 @omarsar0。
  • LangChain 正被用于构建更强大的 AI agents 并自动化复杂任务。Uber 的开发者平台团队正在使用 LangGraph 构建智能体网络，以自动化单元测试生成 @LangChainAI。Webtoon 正在使用 LangGraph 自动化其内容库中的叙事理解，将人工故事审核工作量减少了 70% @LangChainAI。
  • Teknium 发布了 Minos，这是一个用于判断对话最后一次回复是否为拒绝的分类器，可用于自动化 jailbreaking 和 redteaming @Teknium1。
  • svpino 正在推广将于 5 月开始的 Machine Learning Engineering 课程，强调了 MLOps 和设计复杂系统的重要性 @svpino, @svpino, @svpino, @svpino。重点在于使用 LLMs 构建变革性软件 @svpino。

AI 与行业

  • Perplexity 的 Aravind Srinivas 讨论了挑战 Google 在 Android 生态系统中主导地位的挑战，强调需要构建一个比 Gemini 更好的原生 Assistant，并与 Motorola 合作以优化用户体验 @AravSrinivas。
  • Stephanie Palazzolo 报道了 OpenAI 调高的业绩预测，这主要受 Agent 和“免费用户货币化”驱动，其中可能包括广告或联盟营销费用 @steph_palazzolo。
  • Chris Lattner 讨论了硬件公司在构建 AI 软件时面临的挑战，指出了技术问题、激励机制以及对定制化解决方案的需求 @clattner_llvm, @clattner_llvm, @clattner_llvm。
  • 吴恩达 (Andrew Ng) 讨论了 AI 辅助编程，指出它降低了特定编程语言的重要性，而理解核心概念仍然至关重要 @AndrewYNg。
  • Yoshua Bengio 将 SB 813 视为通过独立的多利益相关方监管组织 (MROs) 促进 AI 安全创新的进步，但建议进行修改，包括加强安全保障、明确责任保险和州政府监管 @Yoshua_Bengio。

国际动态与地缘政治

  • teortaxesTex 讨论了研究领导地位的转变，指出中国现在拥有 11 位顶级研究领袖，而美国只有 4 位，这表明他们不再依赖美国学校或“IP” @teortaxesTex。
  • teortaxesTex 评论了美国对中国劳动力和 CCP 政策的依赖，而非所谓的“共产主义欺诈”，并讨论了美国在人口较少的情况下维持霸权的挑战，以及有时需要允许盟友超越自己 @teortaxesTex, @teortaxesTex。
  • teortaxesTex 评论了中国在 AI 领域日益增强的实力，特别提到了 AI 公司 DeepSeek，指出此类公司还会层出不穷，并赞扬了中国的武器命名惯例 @teortaxesTex, @teortaxesTex, @teortaxesTex。
  • Hardmaru 建议更多的顶级 ML 会议应该在亚洲举办，鉴于 ICLR 2025 在新加坡举办的亚洲背景 @hardmaru。

幽默与梗

  • willdepue 调侃 AI 会议展位不再发放免费水瓶，只发贴纸，暗示经济衰退 @willdepue。
  • aidan_mclau 调侃模型福利，称“模型有 15% 的概率具有意识”就像“我有 15% 的概率应该把我电脑所在的这堆原子称为桌子”一样荒谬 @aidan_mclau。
  • vikhyatk 分享了一个故事：回到家后感到恐慌，因为以为某个 eval 结束了，结果发现只是冰箱发出的声音 @vikhyatk。

AI Reddit 回顾

/r/LocalLlama 回顾

1. Gemma 3 27B 量化与基准测试分析

  • 我对 Gemma 3 27B QAT 模型进行了基准测试 (Score: 117, Comments: 26): 原作者（OP）使用 llama.cpp v1.27.1 (GGUF) 和 LM Studio MLX v0.13.2 对几个量化（QAT）版本的 Gemma 3 27B 进行了基准测试，但发现由于过拟合以及量化模型之间结果不一致，困惑度（perplexity）是一个不可靠的指标。因此，改用 GPQA-main 进行评估，结果显示 GPQA-main 分数范围从 0.333 (MLX, 4bit) 到 0.375 (未量化)；值得注意的是，Bartowski QAT Q4_0 GGUF 得分为 0.352，且运行速度比 MLX 快 1-2 tok/sec。分析表明 Bartowski QAT Q4_0 是最佳的本地 QAT 选择，结果暗示与基准线相比，量化仅导致适度的性能下降。 一位评论者询问基准测试是否在确定性推理设置（temperature 0, top-k 1）下运行，这对于可复现性至关重要。另一位评论者指出，GPQA-main 的表现与之前测试中更难的 Diamond 子集接近——这表明量化并没有显著拉大在难题上的性能差距。

    • 一位评论者提出了一个技术问题：基准测试是否使用了确定性解码设置（特别是 temperature=0 和 topk=1），因为这些设置对于量化模型之间的可复现性和严格性能比较非常重要。
    • 另一位评论者分析了 GPQA-main 基准测试结果的统计显著性，指出在 448 个问题下，报告分数的误差范围（使用二项分布转高斯分布近似建模）约为 ±2.25%。这表明鉴于当前的数据规模，很难就该数据集上的模型性能差异得出强有力的结论。
    • 针对困惑度（perplexity）指标的解释进行了简短的技术澄清：较低的值更好，因为它们表明模型在进行下个 Token 预测时更加自信且准确。

  • Unsloth Dynamic v2.0 GGUFs + Llama 4 Bug 修复 + KL 散度 (Score: 110, Comments: 49): Unsloth 用于 GGUF 的 Dynamic v2.0 量化方法展示了优于 QAT 和传统 imatrix 量化技术的改进，特别是在 5-shot MMLU 和 KL Divergence 基准测试中。评估框架与 Llama 4 和 Gemma 3 报告的指标一致，Gemma 3 12B/27B Dynamic 2.0 量化以极小的磁盘空间成本实现了接近 BF16 的精度，且 KL Divergence 降低了高达 7.5%（查看完整结果 请点击此处）。该方法强调 “flips” 是比困惑度更好的精度指标（参考 Accuracy is Not All You Need），并使用严格筛选的对话式校准数据集进行量化。修复了几个 Llama 4 的 Bug，包括 RoPE 缩放配置、QK Norm epsilon 和 QK Norm head 共享，从而提高了 llama.cpp 和 transformers 中的评估分数。 一位评论者指出，目前缺乏 Gemma 3 QAT 与新的 Dynamic 2.0 量化之间的直接比较，暗示发布的数据仅对比了 QAT 与 BF16。另一个询问是关于是否有计划推出 Maverick 版本，反映了用户对更广泛模型支持的兴趣。

    • 一位用户注意到 Gemma 3 QAT 与新发布的 Dynamic 2.0 量化模型之间缺乏直接的基准测试对比，指出仅展示了 QAT 与 BF16 的结果。对于技术受众来说，这凸显了对专门针对近期量化进展（如 Gemma 3 架构的 QAT 和 Dynamic 2.0）进行正面交锋评估指标的兴趣。
    • 一条评论询问基准测试或量化过程是否也将应用于 Maverick 模型系列，这标志着对更广泛支持的需求，并建议开发者应为其量化工具和基准测试套件规划多架构兼容性。
    • 另一条评论对新的 DeepSeek 动态量化表示赞赏，表明技术社区非常看重将动态量化方法持续扩展到其他架构，并暗示了进一步性能监控或对比评估的潜在领域。

2. 即将发布的开源推理模型公告

  • 关于 OpenAI 即将推出的“开源”AI 模型的细节 (Score: 248, Comments: 126): OpenAI 正在开发一款计划于初夏发布的全新开源推理模型，旨在超越 Llama 和 Gemma 等现有的开源替代方案。该模型将支持文本输入/文本输出任务，允许切换推理能力，旨在高端消费级硬件上高效运行（根据评论推测约为 30-70B 参数），并可能采用比当前主流开源模型更宽松的许可证。 热门评论对之前的延迟表示怀疑，并要求提供实际的模型权重 (Weights) 而不仅仅是公告。有知情人士推测，“高端消费级硬件”指向 30-70B 参数范围的模型，参考了类似稠密模型（o3-mini, o4-mini）的先例。

    • 评论者估计 OpenAI 即将推出的“开源”模型可能在 30-70B 参数范围内，这符合之前关于 o3-mini 和 o4-mini 是该类别稠密模型的泄露信息。这也与“适用于高端消费级硬件”的说法相吻合。
    • 一位用户建议，‘q4’量化版本将占用约 18-20GB VRAM，这意味着如果与现有的 LLM 量化策略相比，该模型大小落在 30B-35B 范围内。
    • 帖子里对模型的实际发布持怀疑态度，用户要求 OpenAI 发布权重——而不仅仅是公告——才认为这项工作具有实质意义，这反映了对数月来只有预告而无技术交付成果的沮丧。

  • Skywork-R1V2-38B - 全新 SOTA 开源多模态推理模型 (Score: 169, Comments: 11): Skywork-R1V2-38B 是一款新发布的开源多模态 LLM，结合了 Qwen/QwQ-32B 主干网络和 InternViT-6B-448px-V2_5 视觉编码器。它在 MMMU 上达到 73.6%，在 OlympiadBench 上达到 62.6%，在开源模型中取得了 SOTA 结果，推理支持 Transformers 和 vLLM 技术栈。讨论重点包括集成视觉功能后稳定的非视觉性能、相比 QwQ 在 LiveBench 上的提升，以及对 GGUF 格式可用性的请求。 评论者指出，Skywork-R1V2-38B 在新版基准测试中的 LiveBench 得分（73.2 vs. 65.69）高于 QwQ，这引发了关于基准测试一致性和非视觉性能对比的讨论。技术圈对该模型在多模态集成后仍能保持语言推理能力表示了积极关注。

    • 一位用户指出，Skywork-R1V2-38B 在架构上与 qwq-32b 相似，并添加了 InternViT-6B-448px-V2_5 作为视觉编码器，强调了该模型在集成视觉能力后如何保持在非视觉任务上的强劲表现。这表明多模态集成非常有效，且核心语言基准测试没有出现退化。
    • 基准测试结果被详细讨论：据报道 Skywork-R1V2-38B 的 LiveBench 得分为 73.2，而 qwq 在 4 月 2 日版本的得分为 65.69，在之前版本的得分为 71.96。一位用户要求澄清使用了哪个 LiveBench 版本，并对这款新的多模态模型是否真的在非视觉任务上超越了原始的 qwq 表示好奇。
    • 提出了一个技术问题：是否可以在将信息传递给语言模型之前，专门针对图像编码器使用强化学习 (RL) 进行微调。这表明人们有兴趣通过独立优化视觉组件来提高下游性能，从而改进多模态流水线。

3. 最近的多模态和推理模型基准测试

  • 新的推理基准发布。Gemini 达到 SOTA，但 Qwen 表现如何？ (Score: 210, Comments: 51): 该图片总结了新发布的 PHYBench 的结果，这是一个包含 500 个真实物理问题的基准测试，旨在评估大语言模型 (LLM) 的物理推理能力。图表按准确率和预期误差偏差 (EED) 对领先的 LLM 进行了排名，显示 **Gemini 2.5 Pro 目前实现了最佳的整体性能，显著优于其他 SOTA 模型，而像 Qwen 这样的模型则表现落后。该基准揭示了 LLM 与人类水平推理之间持续存在的差距，特别是在物理语境下，并证明了之前关于模型针对流行基准（如 R1）进行优化的观念在任务需要新颖推理能力时相关性有限。原始论文链接。** 评论者讨论了这些结果的影响，指出 Gemini 2.5 Pro 令人印象深刻的泛化能力，R1 在新颖基准上的韧性（反驳了其过度针对特定基准优化的说法），以及 Qwen 等模型的相对较弱表现，并推测其困境与该基准依赖隐性物理知识而非上下文模式匹配有关。

    • 几条评论强调了新基准如何展示不同模型的优缺点：具体而言，Gemini 2.5 Pro 在推理方面达到了 SOTA 结果，优于 GPT-4.1 和 Claude Sonnet 等老牌对手，特别是在以前未进行过基准测试的领域，这反驳了 R1 仅因针对已知基准优化而强大的推测。
    • 多位用户观察到 Qwen 较弱的表现可能源于其较小的模型规模和专门的训练数据。技术观点包括 Qwen 模型（包括 QwQ，可能指 Qwen-32B/Qwen-72B）缺乏存储广泛现实世界或物理知识的足够容量，如果信息包含在 In-context 中而非依靠召回，其表现会更好。还有推测认为 Qwen 的训练更多侧重于数学和编程而非物理，这进一步解释了它在需要广泛事实知识的问题上表现相对较差的原因。

    • V3（暗示为 Claude 3 Opus）是该基准测试中表现最好的非推理模型，甚至在除显式推理任务外的表现优于 GPT-4.1 和 Sonnet。R1 的表现超过了 o1、o3 mini、Grok-3、Sonnet Thinking 和 Gemini 2 Flash，挑战了此前关于 R1 和 o1 是势均力敌对手的假设。这些基准测试结果表明，更大或训练更多样化的模型（“大鱼获胜”）往往在新颖的测试领域具有更优越的召回和推理能力。

    • Skywork-R1V2-38B - 新的 SOTA 开源多模态推理模型 (Score: 169, Comments: 11): Skywork-R1V2-38B 是一款新发布的开源多模态 LLM，它结合了 Qwen/QwQ-32B 主干网络和 InternViT-6B-448px-V2_5 视觉编码器。它在开源模型中实现了 SOTA 结果，在 MMMU 上达到 73.6%，在 OlympiadBench 上达到 62.6%，推理支持 Transformers 和 vLLM 栈。讨论强调了视觉集成后稳定的非视觉性能、与 QwQ 相比在 LiveBench 上的改进，以及对 GGUF 格式可用性的请求。 评论者指出，Skywork-R1V2-38B 在新版基准测试中的 LiveBench 分数（73.2 vs. 65.69）高于 QwQ，这引发了关于基准测试一致性和非视觉性能对比的讨论。技术界对该模型在多模态集成后保留语言推理能力的能力表示了积极关注。
  • 一位用户指出 Skywork-R1V2-38B 在架构上与 qwq-32b 相似，并添加了 InternViT-6B-448px-V2_5 作为 visual encoder，强调了该模型在集成视觉能力后仍保留了在非视觉任务上的强劲性能。这表明了有效的 multimodal integration，且核心语言 benchmarks 没有出现退化。
  • 详细讨论了 Benchmark 结果：据报道 Skywork-R1V2-38B 达到了 73.2 的 LiveBench 分数，而 qwq 在 4 月 2 日发布的版本中分数为 65.69，前一版本为 71.96。一位用户要求澄清使用了哪个版本的 LiveBench，并对新的 multimodal model 是否真的在非视觉任务上优于原始的 qwq 表示好奇。
  • 提出了一个技术问题：在将信息传递给 language model 之前，是否可以专门针对 image encoder 使用 reinforcement learning (RL) finetuning。这表明了人们对于通过独立优化 vision component 以获得更好的下游性能，从而改进 multimodal pipeline 的兴趣。

Other AI Subreddit Recap

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

1. CivitAI 政策变更与社区反应

  • Civit 打压的真实原因 (Score: 1090, Comments: 407): 该帖子提供了一份“行业内部人士”的分析，解释了为什么 Civitai 和类似的成人 AI 图像网站正在实施更严格的内容审核：主要原因是来自 Visa 的压力，特别是通过 Visa 的 VAMP (Visa Acquirer Monitoring Program)，该计划对成人 AI 内容引入了严苛的合规要求。Esquire Bank 和 ECSuite（成人 AI 交易的主要美国商户处理器）最近因违规被处以重罚，引发了全行业的打击，因为任何接受 Visa/Mastercard 付款的实体现在都必须遵守新的、更具限制性的标准，否则将面临支付处理终止的风险。作者声称，目前除了寻求替代支付轨道外，没有可持续的方法来摆脱对传统信用卡网络的依赖，而这对于大多数平台来说在很大程度上仍然是不可行的。作者引用的 Nomi.ai 正是出于这个原因禁止了成人内容。 评论者辩论了中心化支付处理器作为守门人的影响，并主张将 open-source 和去中心化解决方案作为部分应对措施；一位用户指出 Civitai 在直播中确认了这种压力，并预测随着打击力度的加大，将进一步依赖于像 Stable Horde 这样的分布式项目和用户端的模型备份。

    • 几条评论强调，Civitai 的打击行动主要是为了应对来自 Visa 等中心化支付处理器的压力，这些处理器可以因内容政策而取消服务平台。文中提到了依赖此类守门人的技术风险，并讨论了 open-source 模型和去中心化托管（通过 Stable Horde 或社区备份等项目）对于抵御机构审查至关重要。
    • 提到了 Civitai 工作人员确认外部压力的直播，强化了在中心化平台之外寻求技术和架构解决方案的必要性。讨论指向了模型和数据的冗余，鼓励用户参与分布式项目，以便在主流平台实施内容禁令时维持访问。
    • 提到了 OnlyFans 案例作为一个技术和战略反例，质疑为什么 Visa 在那里如此迅速地撤回了压力，却继续针对 AI 艺术相关内容。这促使技术读者质疑执行的不一致性，以及依赖于政策执行不透明、不可预测的支付 API 的平台所面临的结构性风险。

  • CivitAI backup initiative (Score: 410, Comments: 110): 该帖子宣布 CivitAI 开始清理模型，并启动了备份和存档受影响模型的行动，提议将 /r/CivitaiArchives 作为策略、技巧和资源共享的中心枢纽。一条高赞技术评论主张使用 torrent 采用去中心化解决方案，建议创建一个克隆网站，提供模型快照的 torrent 链接，并通过截断的 sha256 哈希值 (autov2) 进行标识，并强调了技术可行性（简单的 nginx 设置、vservers 以及社区驱动投票/评论的潜力）。汇总了备份方法的中心帖子引用自 /r/CivitaiArchives/comments/1k6uhiq/civitai_backup_initiative_tips_tricks_how_to/ 。 技术辩论集中在此类倡议的实用性和历史，虽然有人怀疑备份计划往往缺乏后续执行，但一致认为需要稳健的去中心化存档解决方案。

    • Ueberlord 提议通过 torrent 建立点对点（peer-to-peer）备份解决方案，建议社区创建一个网站来镜像 CivitAI 的模型快照页面，使用 autov2 hash（模型 SHA256 的前 10 个字符）作为唯一标识符。构想中的网站将提供模型的 torrent 文件，可以在适度的基础设施（使用 nginx 和负载均衡器的几个小型 VPS）上运行，并强调保持系统简单——评论或投票等额外功能可能会增加复杂性，目前并非紧迫需求。
    • Upper-Reflection7997 强调了优先备份特定模型类型的重要性，建议“概念”类 LoRA 和写实模型至关重要，因为它们被移除的可能性更高，而风格或角色 LoRA 则相对次要。这强调了在备份模型时需要进行战略性选择，而非盲目下载。

    • nalditopr 分享了一个实现参考，链接到了 GitHub 上的 CivitAI-Model-grabber 工具，该工具可以自动从 CivitAI 下载模型。该工具可以作为任何模型存档倡议的即时资产，并可作为进一步自动化或分布式备份流程的基础。

    • Lora removed by civitai :( (Score: 212, Comments: 97): 附图是一个非技术性的 meme，具体是一个视觉双关语，借 Civitai 移除 “Lora” 之际引用了 “golden shower” 等术语。从评论中推断，背景与 Civitai 模型共享平台监管或移除某些类型的 LoRA (Low-Rank Adaptation) AI 模型有关——可能涉及 NSFW 或有争议的内容。图片本身没有技术基准测试、模型细节或实现讨论。 评论者对 Civitai 的监管选择表示惊讶和批评，认为内容政策存在不一致性，并对模型共享日益增加的限制表示担忧，尤其是针对成人或边缘 AIGC 内容。

      • 评论者讨论了 Civitai 上内容移除日益增多的趋势，涉及从分众领域（如 furry, weeb, gooner）到涉嫌侵犯版权的内容，这表明 Civitai 的监管政策范围可能正在扩大，并影响到多样化的 LoRA 数据集。这意味着内容指南正在收紧，对于从事非常规或边缘主题创作的创作者来说可能存在风险。
    • Did civitai get nuked just now? (Score: 121, Comments: 151): 用户报告称，分发 Stable Diffusion 模型的平台 CivitAI 在一次计划维护后不久突然下线或出现了大规模内容移除，尽管此前的迹象表明它还会维持运行数日。这次停机或下架显得非常突然，可能与外部压力或法律/商业考量有关，而非纯粹的技术维护。 评论者将此事件归因于来自美国风险投资（如 Andreessen Horowitz）的压力，并推测投资者驱动的优先级或合规要求导致了内容移除或关闭。一些人主张未来的模型共享平台应选择去中心化、非公司化或基于 torrent 的架构，以避免类似的下架风险。
  • 技术评论员将 Civitai 上突然出现的大规模 Checkpoint 和资源删除归因于来自美国风险投资和支付处理器（如 Visa/Mastercard）的压力。他们参考了历史模式，即开源平台被迫限制内容或改变运营方式以符合外部投资者或合作伙伴的需求，这可能是为了确保持续增长或获得投资。
  • 一些人推测，Civitai 在过去 24 小时内增加的下架活动是由于近期重大的恐慌或法律威胁，导致了激进的内容审查和文件删除。这与之前开源 AI 和社区平台在感知到法律或财务风险后的表现模式一致。

2. OpenAI 模型访问、限制与功能更新

  • OpenAI 员工确认公众可以访问接近最前沿的模型 (Score: 2113, Comments: 312): 该图片包含由 ‘roon’ 发表的经过验证的社交媒体声明，声称公众可以访问与最新技术进展非常接近（两个月内）的 AI 模型，并且政府和大型企业都没有权限访问更优越的模型。这一透明度和可访问性归功于 OpenAI，暗示其内部保留的高级能力极少。该声明回应了关于大型机构拥有能力显著更强的非公开模型的频繁猜测。 评论反映了怀疑态度，一些用户认为 OpenAI 是在应对竞争压力（尤其是来自 Google 的压力），对透明度声明表示怀疑，并就公司的私有化以及对 AI 开放性的意图展开辩论。

    • 一位评论者强调，OpenAI 决定强调公众对近期 AI 模型的访问权限，这表明来自 Google 的竞争压力增加，暗示了多家行业领导者在创新和部署方面的快速节奏。
    • 另一位用户指出，OpenAI 的公开叙事通常将自己定位为防止封闭的、由企业或政府主导的 AI 的屏障，但质疑 OpenAI 在当前模型可访问性状态中应占多少功劳，并承认资金需求和竞争在塑造其开放性方面同样至关重要。
    • 讨论涉及“OpenAI”的定义和演变——特别是社区对该公司从开放转向私有化的审查，以及这种转变在透明度、模型发布节奏以及对 AI 可访问性和安全性辩论的更广泛影响方面的看法。

  • OpenAI Plus 用户现在每月似乎可以获得 25 次 Deep Research 查询额度 (Score: 249, Comments: 36): 图片显示 OpenAI Plus UI 现在提供每月 25 次的 Deep Research 查询配额，高于之前的每月 10 次限制。此使用上限直接显示在界面中，表明有一个系统用于跟踪和执行 Deep Research 功能的查询限制。 评论者强调，虽然这一增加提升了该功能对 Plus 订阅者的价值，但仍落后于 Google 的 Gemini 订阅等替代方案，据报道后者提供更慷慨或无限制的访问。一些用户注意到关于此更改缺乏官方公告。

  • 几位评论者注意到 OpenAI Plus 用户的 Deep Research 查询上限已从每月 10 次增加到 25 次，一些人认为这是一个显著的进步，特别是对于那些经常达到之前限制的用户。人们将其与 Google 的 Gemini 进行了比较，据说后者为高级用户提供无限查询，使其对高需求用户更具吸引力。一位用户询问 Deep Research 是否依赖于容易产生幻觉的 GPT-4o 版本（“o3”），这表明了对高级 LLM 功能中事实可靠性的持续担忧。

  • Plus 用户新限制？(2025/04/24) (Score: 155, Comments: 51): 该帖子分享了 OpenAI 的 ChatGPT Plus、Team 和 Enterprise 账户最新更新的使用限制，这些信息反映在 OpenAI 帮助中心的一篇文章和一张截图中。更新后的配额为：100 o3 messages/week、300 o4-mini messages/day 以及 100 o4-mini-high messages/day。Pro 计划宣传近乎无限的访问权限，前提是遵守 OpenAI 的 ToU，特别是禁止滥用、账号共享或未经授权的转售（参见 官方文档）。 评论者指出 Deep Research 的容量已增加到 25，并回顾了过去 GPT-4 显著较低的消息限制，将这些变化背景化为模型可访问性的逐步改进。

    • 多位用户讨论了最近的使用限制变化：Deep Research 的消息上限已提高到 25，并提到了历史上的 GPT-4 限制，此前为 每 3 小时 25 条消息。
    • 关于 GPT-4.5 的配额仍存在困惑，一名用户遇到了每周限制（每 50 条）。用户注意到即使在使用量极少的情况下也会出现不一致的警告，这表明配额追踪可能存在偏差或 Bug。

    • 一些人推测未来的 订阅价格变化（例如增加到每月 25 美元），这可能是对使用量增加的反应，或者是为了适应更高消息限制带来的增强资源分配。

    • 这是 Plus 的新限制 (Score: 152, Comments: 36): OpenAI 更新了 ChatGPT 用户的使用限制：Plus、Team 和 Enterprise 订阅者现在使用新的 o3 模型可获得 100 messages/week，o4-mini 为 300 messages/day，o4-mini-high 为 100 messages/day（来源）。这些变化反映出相比之前的 GPT-4 配额（原为每 3 小时 20 条消息）有了显著增加。 评论者对未来层级（如 Pro）中 Agent 的访问权限和定价改进表示乐观，提到了每月 25 次 Deep Research 查询的额外上限，并询问了“4.5”的状态，特别是其对写作任务的适用性。

      • 用户正在讨论 GPT-4 模型消息限制的演变，指出之前的限制（如每 3 小时 20 条消息）随着 o3/o4 系列模型的推出已得到显著改善。有人提出，到 2026/2027 年，Agent 的定价和使用限制（特别是 Pro 订阅）将进一步提升，可能为重度用户提供更多价值。
      • 提到了一项具体的技术限制：一些用户报告每月 Deep Research 查询上限为 25 次，这表明高能力或研究导向的模型仍具有不同于标准对话的更严格访问控制。
      • 一名用户表示希望推出新的定价层级（例如每月 40 美元），为 4.5 和推理变体模型提供双倍的使用限制，这表明目前的层级在满足高级个人使用方面仍存在空白，且无需企业级/无限量方案。

3. AI Coding Assistant 工具、DIY 设置与生产力

  • 我被 CursorAI 拒绝了，所以我构建了自己的 “Cursor”… 它好得多，这里是你可以如何创建自己的。 (Score: 162, Comments: 71): 原帖作者（OP）是一个非编程人员，在被 CursorAI 拒绝后，逆向工程出了自己版本的类 CursorAI 编程助手。他强调了 Cursor 的 Agent 系统缺陷——特别是过度依赖廉价的 Agent 模型导致快速的上下文丢失（在 2-3 轮对话内忘记提示词），并声称 Windsurf、Claude Code 以及他自己的工具避免了这一问题。他的配置采用了 Vite+React+Node（而非 Next），使用一个 VS Code 扩展来维护最新的文件树（file-tree.md）和文档（docs.md），并通过一个轻量级 Agent (GPT-4o-mini) 进行文件选择，编排 LLM 驱动的代码编辑，将主要编辑任务通过结构化的 JSON 提示词委托给 Anthropic Claude 3.5，并集成了 GitHub/Netlify 用于 CI/CD。成本与商业工具相当，但准确性的提高减少了每次实际编辑的 Token 消耗。参见 演示视频。 一些评论者质疑 OP 在软件架构方面的可信度，断言专业知识需要多年的实战编程经验，而另一些人则祝贺这种有条理的、以产品为导向的方法，并指出在对比中遗漏了 Cline 或 Roo 等竞争工具。

    • 讨论强调了高层级产品指导与实际软件架构之间的区别，指出真正的架构知识需要多年处理复杂系统的实战经验，而不仅仅是概念性的理解。
    • 几位评论者对比了工具：Cursor（面向程序员）、Loveable（针对非程序员），并提到了 Cursor 或 Windsurf 中的自定义指令等功能，以及使用按月订阅的 Claude 桌面版配合 MCPs 获得不错效果的情况。这些对比澄清了每个工具的功能集和目标受众。

    • 提出了一项技术批评：工业界实际的软件开发侧重于维护和演进部署在生产环境中的大型复杂代码库，而不是为简单或短期用例生成新的代码库，这界定了市场相关性以及爱好者与收入驱动型用户之间的区别。

    • 我从事软件工程超过 15 年。我沉迷于 AI 编程。 (Score: 447, Comments: 169): 附图显示了一个用户构建的开发者助手 UI，它与 OpenAI API 接口，用于端到端的代码编辑和项目管理，展示了从手动编程和基于浏览器的聊天工作流转型的真实场景。截图展示了助手处理一个详细的自然语言请求：“修复 meta_sdk_client.py 以使用 Facebook SDK 对象并在特定模块中暴露方法。” 助手列出了加载的文件，详细说明了所做的更改（例如集成更多 Facebook SDK 功能并使用 Pydantic 模式改进错误处理），并输出更新。帖子解释了从 OpenAI 的 o1 迁移到 o4-mini 模型后，生产力和成本的显著改善，强调了更大的上下文处理能力（10倍）和 1/15 的 API 成本，同时保持了高质量的输出。发布者还架构了一个 AI Agent 系统，可以分解任务，自主模拟多层级开发者协作。 评论者讨论了为教学工作流定制 LLM，并对比了 Cursor 和 Cascade 等用于针对性编码的工具。关于权衡存在争议：一些人警告说，完全由 AI 驱动的代码库会导致臃肿和意外更改（“vibe coding”），表示更倾向于将 AI 作为助手而非唯一的开发者。
  • 一位用户讨论了如何将 LLM 定制为针对个人学习风格的编程导师，特别要求遵循“教与练”教学模式的代码生成——提出了 AI 驱动的编程环境如何调整以实现更深层次、增量式的理解，而非纯粹的代码补全。
  • 多位评论者警告了过度依赖 AI 驱动的代码生成（“vibe coding”）的陷阱，强调这些模型倾向于生成臃肿或冗余的代码，经常添加超出请求的无用组件。这种代码膨胀会导致代码库难以维护并增加技术债务，使得人工干预和生成后的重构变得普遍。
  • 一个反复出现的主题是，对 AI 编程工具的依赖如何导致开发者逐渐丧失详细的系统级知识。以往传统的亲手编程实践培养了对架构的深刻理解，而生成的代码则导致心理模型模糊，调试直觉减弱，特别是在诊断和排除复杂问题时。

AI Discord 回顾

由 Gemini 2.5 Pro Exp 提供的摘要之摘要的摘要

主题 1：新模型与基准测试引发热议

  • Grok 3 和 Gemini 2.5 下战书：根据 OpenAI-MRCR 结果，Grok 3 表现出与 GPT-4.1 相似的性能，而 Gemini 2.5 Pro 因推理能力受到称赞，但因冗长和潜在的幻觉受到批评，一位用户表示 OAI deep research 与 gemini deep research 相比简直是天壤之别。人们对即将发布的 Qwen 3 和 DeepSeek 模型充满期待，它们可能会在新加坡的 AI conference 上首次亮相。
  • Unsloth 的动态量化打破基准测试记录：Unsloth AI 推出了 Dynamic v2.0 GGUFs，详见其基准测试和分析文档，在 5-shot MMLU 和 KL Divergence 上刷新了记录。此次更新需要下载高达 600GB 的 Q4/Q8 数据，支持在保持准确性的同时运行和微调量化 LLM，社区在 Twitter 和 Hugging Face 集合上分享了结果。
  • Context Arena 助力长上下文可视化：新的 Context Arena 基准测试已发布，提供了 LLM 在长上下文窗口下性能的可视化。它具有可排序的排行榜、交互式图表、模型选择器，并欢迎社区反馈以添加更多模型或基准测试。

主题 2：硬件难题与对芯片的高期望

  • AMD GPUs 对于本地 LLM 依然棘手：在 AMD GPUs（如 RX 6750 XT）上运行本地模型的用户继续面临挑战，理由是需要大量的 VRAM 和特定的 Linux ROCm 驱动程序，参考了此 Reddit thread。建议使用 LM Studio 等工具测试较小的模型，作为衡量 AMD 硬件性能的起点。
  • VRAM vs DRAM 之争造成瓶颈：运行超出 GPU VRAM（例如在 4090 上）并卸载到系统 DRAM 的大型模型（120B）会导致性能大幅下降（据报告为 0.5 tok/s），这强化了你不希望模型触及系统 RAM 的共识。讨论强调了购买二手 3090s（因其 24GB VRAM）的风险，称其为一种彩票，且可能存在更换导热垫的潜在隐藏成本。
  • Blackwell 的 FP4 和 MI300 基准测试引发关注：正在寻求 NVIDIA Blackwell 的 FP4 实现细节，在 OCP Microscaling Formats MX v1.0 spec 中找到了潜在参考。与此同时，amd-fp8-mm 排行榜出现了大量 MI300 基准测试提交，尽管一些形状维度（如 n=576）被指出对于针对 DeepSeek R1 推理形状可能并非最优。

主题 3：工具的尝试、胜利与磨难

  • Unsloth 瞄准多 GPU，解决 Ollama 故障：Unsloth AI 宣布即将推出原生 multi-GPU 支持，同时建议将 accelerate 库作为临时解决方案，并强调了仔细进行模型拆分的必要性。用户还报告了通过 Ollama 拉取 Unsloth 模型时出现的问题，这归因于 Hugging Face 的问题和 Ollama 的自定义注册表。
  • Aider 获得 Flag 修复，着眼 GitHub 集成：Aider 用户讨论了在 Agent 工作流中管理上下文提示的问题，建议使用 --yes 标志或“不再询问”选项，同时请求添加 auto-skip 标志。此外，还出现了一项功能请求，旨在将 Aider 直接与 GitHub Issues 集成，以实现自动代码修复和 Pull Request 生成。
  • Cursor 应对上下文过载与 Copilot 冲突：Cursor 用户报告了在启用 ‘include project structure’ 设置时的性能问题，这可能会导致上下文窗口过载并超出工具限制。另外，用户注意到较新版本的 Cursor 会屏蔽 GitHub Copilot Chat，若要同时使用则需要回滚到 v0.46，这引发了关于 Microsoft 正在将 Copilot 限制在 VSCode 中的猜测。

Theme 4: API Anguish, Access Adventures & Alternatives

  • Sora 限制与搜索上限挤压用户：新的 OpenAI 用户面临临时的 Sora 视频生成限制，而现有用户发现 deep search 的上限为 每月 15 次，引发了诸如 “我发誓 Plus 变得越来越离谱了” 之类的幽默吐槽。这激发了对 deep research 替代方案 的需求，希望其使用限制能高于 Perplexity 或 You.com 等服务。
  • Brave API 的脆弱性与 OpenAI 成本侵蚀预算：据报告 Brave API 不稳定，即使是根据其 服务条款 订阅的付费用户，也有 50% 的摘要生成请求 失败（HTTP 504 错误）。与此同时，OpenAI web search 被指出占用了 Agent 流水线成本的 95%，导致一名用户放弃 API 并构建了自己的爬虫解决方案，克服了他们的 “爬虫恐惧症”。
  • 通过 Open Router 和 Copilot 技巧获取免费 LLM：用户分享了访问免费 LLM 的方法，包括在 Aider 中使用 Open Router (openrouter.ai) 以及类似 openrouter/microsoft/mai-ds-r1:free 的模型 ID。此外，一名拥有 GitHub Copilot Pro 的学生发现，似乎可以 无限量 API 访问 GPT-4o 和其他模型进行代码生成。

Theme 5: Community Creations, Concerns & Collaborations

  • Hugging Face 动态：集成、收购与错误：Hugging Face 宣布了多项更新：将 transformers 集成到 vLLM，翻新了 量化文档，为 JS SDK 添加了 MCP 客户端支持，收购了 Pollen Robotics，并支持了 Cohere 模型。然而，用户报告在访问 meta-llama/Llama-3.2-3B-Instruct 时出现 503 错误，有时通过请求模型访问权限可解决，同时 Agents 课程 的截止日期已延长至 2025 年 7 月 1 日。
  • MCP 势头强劲，涵盖扩展、服务器与规范：Model Context Protocol (MCP) 生态系统持续增长，Siloed 发布了 浏览器扩展，出现了一个将 git 仓库转换为 MCP 服务器 的工具，并且 LlamaIndex.TS 通过简单的 mcp() 调用即可集成数千个 MCP 服务器（示例）。Cloudflare 也在推动远程 MCP 服务器身份验证的 OAuth 和 动态客户端注册。
  • AI 论文潮引发审稿人警惕：ACL 论文投稿量大幅增加（超过 2 倍，达到 >8500 篇），引发了关于 AI 生成论文 的辩论，这些论文可能是使用 AI-Scientist-v2 等工具创建的。一些审稿人表示不愿监管 AI 的使用，其中一位表示，如果被要求根据 AI 是否撰写了论文的 核心实质内容 来裁定禁令，他们将 拒绝审稿。

PART 1: High level Discord summaries

OpenAI Discord

  • Sora 限制视频生成：新的 OpenAI 用户在通过 Sora 生成视频时面临临时功能禁用，而现有账户现在每月仅有 15 次 deep searches 额度。
    • 访问权限的变化引发了用户的幽默反应，一位用户感叹道：“我发誓 Plus 变得越来越离谱了”。
  • 寻求 Deep Research 替代方案！：一位用户正在寻找比 Perplexity 和 You.com 使用上限更高、且预算相近的强大 deep research 替代方案。
    • 该咨询突显了对于需要超出当前限制的更广泛研究能力的用户需求。
  • AMD GPU 在运行本地模型时遇到困难：一位拥有 Ryzen 7500f、32 GB RAM 和 RX 6750 XT 的用户寻求运行本地模型的建议，指出需要大量的 VRAM 和 Linux ROCm 驱动程序，并指向了一个相关的 Reddit 帖子。
    • 另一位用户建议使用 LM Studio 测试一个小模型以评估性能。
  • 软件工程的未来面临 AI 挑战：成员们辩论了 AI 进步背景下软件工程师的就业前景，对初级开发人员（尤其是 Web 开发领域）可能被取代表示担忧。
    • 一位软件工程专业大三学生认为 一个胜任的软件工程师的工作至少还能安全 5-10 年，并指出平面设计师正处于劣势。
  • ElevenLabs 替代方案：一位用户请求 Eleven Labs 的文本转语音（text-to-speech）替代方案，理由是 AI 语音缺乏情感。
    • 其他用户鼓励他们尝试用户贡献的语音（如 “Her”），并使用此链接创建自己的语音。

LMArena Discord

  • Grok 3 与 GPT-4.1 竞争：根据 OpenAI-MRCR 结果，Grok 3 的表现与 GPT-4.1 相似，而 Grok 3 Mini 在低上下文（lower context）下表现稍好，但在高上下文（higher context）下表现较差。
    • 有报道称由于 API 端点问题，运行 Grok 3 Mini 存在一些问题，并计划建立一个网站以展示更详细的结果。
  • Gemini 2.5 Pro 获得称赞并引发辩论：成员们讨论了 Gemini 2.5 Pro 的优点，指出它有能力指出用户的错误，而一位成员表示 OAI deep research 对比 gemini deep research 简直是天壤之别，不可同日而语，这些基准测试只是营销手段。
    • 尽管 Gemini 2.5 Pro 的推理能力受到称赞，但对其冗长和潜在的幻觉（hallucination）问题表示了担忧。
  • Qwen 3 和 DeepSeek 首次亮相备受期待：围绕 Qwen 3 的潜在发布和 DeepSeek 新模型的期待情绪高涨，推测新加坡的 AI 会议可能是发布地点。
    • 一位成员分享道：说实话，我对 qwen 3 的期待超过了 deepseek。
  • O3 与 O4 Mini 的霸权之争：成员们正在讨论 O3 和 O4 Mini 的性能对比，一位成员问道：O3-mini-high 在某些任务中会比 O3 更好吗？。
    • 讨论表明 O4 Mini 在某些场景下可能是 O3 的替代品，尽管原因尚不明确。
  • Context Arena 可视化 LLM 上下文：一个名为 Context Arena 的新基准测试发布了，它可视化了 LLM 在长上下文（long context）下的表现，包括可排序的排行榜、交互式图表和模型选择器。
    • 创建者欢迎反馈和对额外模型或基准测试的建议，提供详细的钻取（drill-down）功能和数据导出。

Unsloth AI (Daniel Han) Discord

  • Unsloth 多 GPU 支持即将发布：原生的 Unsloth multi-GPU support 即将推出，在此期间，成员们可以使用 accelerate 库来实现多 GPU 支持。
    • 高效的多 GPU 训练需要仔细地将模型拆分到各个 GPU 上，以保持良好的 GPU 利用率并限制显存开销。
  • Maverick 量化版本升级：Maverick quants 已更新，成员们可以认为其性能有所提升，具体细节将在不久后的博客文章中披露。
    • 成员们被告知要为 600GB 的 Q4 和 Q8 数据下载做好准备，但预计这次更新是值得的。
  • Dynamic v2.0 GGUFs 发布：宣布推出 Dynamic v2.0 GGUFs，并附带了基准测试和分析链接。
  • Ollama 拉取 Unsloth 模型时遇到困难：有成员报告在使用 Ollama 拉取 Unsloth 模型的 manifest 时遇到困难。
    • 该问题被归因于 HF 的问题以及 Ollama 使用的自定义注册表。
  • Gemma 3 Vision 微调故障：一位用户报告在按照 Unsloth 指南对 Gemma 3 进行视觉微调时，遇到了 TypeError: 'int' object is not iterable。
    • 该错误通过禁用 trust_remote_code 得到了解决，但随后又遇到了存储问题。

aider (Paul Gauthier) Discord

  • 函数式语言挑战 Python 的未来：成员们推测函数式编程语言是否会因为在 推理 (reasoning)、编程 (coding) 和 数学 (math) 方面具有更优越的 AI 能力而取代 Python。
    • 一位成员开玩笑说要解释屁声，而另一位成员则质疑 Microsoft 是否在可能存在问题的模型数据上进行训练。
  • 电动汽车超级节气门引发安全争议：一位用户怀疑当前的 AI 在 C 语言方面是否已准备好用于可靠的电动汽车“超级节气门 (super throttles)”，并对 AI 在关键安全系统中的应用表示保留意见。
    • 他们强调了当前 AI 能力与现实世界安全需求之间的差距。
  • Open Router 提供免费 LLM：一位用户分享了如何通过 Open Router 访问免费的 LLM，引导用户访问 openrouter.ai 筛选模型，并在 Aider 中使用 /model openrouter/<粘贴> 命令来使用模型 ID，例如 /model openrouter/microsoft/mai-ds-r1:free。
  • Aider 标志位修复自动提示问题：用户讨论了在 Agent 工作流中禁用 Aider 自动提示上下文的功能，并指出无关的上下文会阻碍性能。
    • 成员们建议使用 --yes 标志或 don’t ask again 选项，同时指出需要一个用于包含上下文提示的 auto-skip 标志。
  • 通过 Commit 减少 Token 消耗：一位用户询问是否可以将 commit 操作合并到 Aider 的第一次 API 调用中，以减少输入 Token 并防止 API 调用陷入死循环。
    • 该用户预计每次修复尝试可节省 2k-3k tokens，并降低 Aider 因 API 调用而失控的几率。

Cursor Community Discord

  • Composer 是否能读取 Git Commit 上下文？: 一位用户询问是否可以将 Git commit messages 集成到 Composer 中，并讨论了该功能的可行性和潜在益处。
    • 一位用户建议可以使用 git log –oneline 来实现。
  • 项目结构设置是否会导致上下文窗口过载？: 用户报告称，在 Cursor 中启用 ‘include project structure’ 设置会导致过度的文件读取，可能超过 tool limit 并降低性能。
    • 一位用户建议反复切换该设置（开关），并指出这可能是一个 bug；另一位用户提到该功能会 占用上下文窗口。
  • Sonnet 3.7 现在消耗 2 次请求: 用户报告称 Sonnet 3.7 现在一次消耗 两个 fast requests，实际上使该模型的使用成本翻倍，并导致额度迅速耗尽。
    • 一位用户建议检查 Thinking 模式开关，或切换回普通的 3.7 Sonnet。
  • 同时运行多个 Agent: 用户讨论了同时运行 多个 Cursor Agents 的能力，质疑提交多个 prompt 是否会影响性能或资源占用。
    • 一位用户提到了多标签页，但表示目前还无法实现；另一位用户警告称，重叠的 Agent 可能会导致内存泄漏和项目损坏，建议先用小任务进行测试。
  • Co-pilot Chat 需要回滚版本: 用户注意到较新版本的 Cursor 阻止了 copilot chat 的使用，而回滚到 0.46 版本则允许并发使用。
    • 一位用户推测 Microsoft 正在将 copilot 限制为仅限 VSCode 使用。

Manus.im Discord Discord

  • 工程师启动混合点对点多玩家框架: 一名成员提议为基于物理的 MMO 创建一个开源的混合点对点（P2P）多玩家框架，愿景是支持 数千名玩家。
    • 目标是相比平台默认提供的功能，给予网站更多的控制权。
  • LLM 分析大数据: 一名成员分享了一段视频，演示了基于 LLM 对 15GB 文件的分析，提供有 9-12 年级版本 和 原始版本。
    • 该分析填补了关于 LLM 如何处理大规模数据集的认知空白。
  • Gemini Advanced 为学生提供 15 个月免费试用: Gemini Advanced 为在 6 月前使用 .edu 邮箱注册并验证的学生提供 15 个月免费 优惠。
    • 他们刚刚在 Gemini workspace 中添加了 VEO 2，这是一款文本生成视频工具。
  • Manus 在 HTML 预览上出现故障: 用户发现，当提示 Manus 为聊天应用生成 HTML 文件时，预览界面链接到了 Manus 的内部 JS 文件，而不是用户指定的源文件。
    • 成员们怀疑这些 赠送额度的性能比以前更差。
  • Manus 破坏 GitHub 仓库: 用户报告称，当指示 Manus 改进 GitHub 仓库时，它有时会 删除整个文件 并从头开始创建新文件，而不是进行针对性编辑，尤其是在处理 100kb 的文件时。
    • 用户建议告诉它只汇报更改内容，并将 代码模块化 为多个较短的文件，组织到子文件夹中并进行压缩。

Yannick Kilcher Discord

  • 通过 Github Copilot 无限制访问 GPT-4o API：一名拥有 GitHub Copilot Pro 的学生发现了对 GPT-4o 的完整、无限制 API 访问权限，可用于代码生成，包括旧版本和实验性模型，并完整找到了 GitHub Copilot 的 system prompt。
    • 成员们推测模型应该拥有人权，或者也许应该被视为宠物，亦或是作为一种 exocortex。
  • Brave API 深受不稳定性困扰：据用户反馈，Brave API 非常不稳定。尽管设置了宽松的 API 超时参数，根据 Brave API 服务条款，仍有 50% 的摘要生成请求 导致 HTTP 504 网关超时错误。
    • “Pro AI”计划的订阅者发现，即使同时订阅了 “Pro AI” 和 “Web Search”，摘要生成 API 仍然无法工作。
  • OpenAI Web Search 耗尽预算：成员指出 OpenAI web search 占用了 95% 的 Agent 流水线成本，使其价格昂贵到令人望而却步。
    • 由于对 API 成本和不稳定性感到沮丧，一位成员决定实现自己的网页抓取和摘要解决方案，克服了他们的“抓取恐惧症”，并调侃道：“既然现在有了 AI，这能有多难呢？”
  • 围绕 Muon 优化器的辩论：Moonlight.io 的评论认为 Muon 解决了 Keller 工作的局限性，并声称在有限的场景下比 Adam 性能更快，尽管有成员质疑它是否只是在顺应潮流。
    • 然而，最近的一篇论文（arxiv 链接）将 Muon 框架化为矩阵谱范数下的一种一阶置信域优化方法，并提供了收敛性保证；同时 Muon 也被用于训练面向实时边缘部署的 diffusion models。
  • Two Minute Papers 混淆了门萨数据：一位成员指出 Two Minute Papers 在视频中犯了一个错误，将 2024 年的全球 AI 结果 与 2025 年 Mensa Norway 的结果进行了对比。该成员引用 TrackingAI.org 声称：没有任何模型的 IQ 超过 118，而 118 IQ 的模型是 Gemma 2.0 Pro，o3 甚至还差得很远。
    • 该成员还质疑 Two Minute Papers 自深度学习热潮开始以来质量是否有所下降。

Notebook LM Discord

  • AO 长度取决于源文件：用户确定 Audio Overview (AO) 的长度取决于所使用的源文件，而非 NLM 版本。
    • 一位用户在 Perplexity 上设置了自定义指令进行详细规划，通过一份完整的报告源文件实现了超过 1 万字 的输出。
  • Gemini 2.5 Pro 在法律领域表现出色：Gemini 2.5 Pro 生成了 Sonnet 3.7 和 GPT 等模型遗漏的新颖法律论点，并能将论点浓缩为播客。
    • 在团队测试 Gemini 2.5 Pro 的同时，NLM 目前运行的是 Gemini Flash 2.0。
  • 破解音频概览转录文本：要提取 Audio Overview 的文本转录，可以将其下载为 WAV 格式，然后将该 WAV 作为源文件导入 Notebook 进行转录。
    • 另一位用户发现可以使用 ai.dev 上传文件，并要求 Gemini 2.5 提供转录文本。
  • 播客定制化蓬勃发展：用户利用 K-12 AI 政策文件 与现有文档进行对比分析，而其他人则利用渔业及海洋部的捕捞计划为利益相关者群体定制播客。
    • 这些定制播客可以旨在满足特定利益相关者的兴趣。
  • NotebookLM 的 LaTeX 支持存在缺陷：用户报告 LaTeX 在 NotebookLM 中无法正常工作，团队确认这是一个正在解决的 Gemini 模型问题。
    • 一位用户在使用 NotebookLM 的 Mindmap 功能时首次看到了公式，但下划线后的字母被错误地渲染为下标和上标。

HuggingFace Discord

  • HF 将 Transformers 集成至 vLLM，并收购 Pollen Robotics：Hugging Face 现在将 transformers 后端集成到 vLLM 中，翻新了量化文档，为 JS SDK 的推理客户端添加了 MCP 客户端支持（公告），收购了 Pollen Robotics（公告），并支持 Cohere/Cohere Labs 模型（公告）。
    • 这些更新旨在增强模型部署、文档、客户端支持，扩展到机器人领域，并丰富 Hugging Face Hub 上的模型供应。
  • TinyLlama 聊天机器人出现 Prompt 幻觉：一位成员报告称，他们的 TinyLlama 客户服务聊天机器人出现了幻觉，并伪造用户 Prompt。
    • 建议包括通过服务提供商使用 AI API 端点，或使用 FriendliAI 等云端推理选项。
  • Unsloth 的 Dynamic v2.0 量化打破基准测试记录：社区正热议 Unsloth 的 Dynamic v2.0 量化，它在 5-shot MMLU 和 KL Divergence 上创下了新纪录，能够在保持准确性的同时运行和微调量化后的 LLM。
  • Agents 课程截止日期延长，Llama-3.2-3B-Instruct 暂时无法使用：Hugging Face Agents 课程的截止日期已延长至 2025 年 7 月 1 日，多位成员报告在尝试运行 meta-llama/Llama-3.2-3B-Instruct 时收到 503 Server Error。
  • 社区发布新模型、数据集和工具：成员们在 Hugging Face 上发布了 BitNet b1.58 2B4T Demo（链接）、Beat Saber QA Chatbot 数据集（链接）、一个将 HF 模型转换为 GGUF 格式的工具（GitHub），以及 Mistake-To-Meaning 数据集（链接）。
    • 这些资源旨在促进模型部署、数据集创建、格式转换以及增强小型模型对拼写错误的理解。

LM Studio Discord

  • 社区辩论 LLPlayer 的安全性：用户讨论了 LLPlayer GitHub 项目 的安全性，一位成员建议“自行构建”是最安全的选择。
    • 担忧主要集中在预构建二进制文件中潜在的漏洞，但该项目的开源性质允许用户进行检查和自定义。
  • Gemma 3 模型顺利首秀：用户确认 Gemma 3 模型在 LM Studio v0.2.31+ 版本中可以开箱即用。
    • 使用旧版本的用户遇到了问题，通过更新到具有“开箱即用”支持的最新版本后问题得到解决。
  • Pixtral 支持初现，但目前仅限文本：llama.cpp 添加了 Pixtral 支持，但目前仅支持文本。不过一位用户指出“你已经可以使用 MLX 运行 Pixtral 很久了”。
    • 社区期待视觉能力的加入，以充分发挥 Pixtral 在 LM Studio 中的潜力。
  • DRAM 瓶颈严重拖累性能：一位用户报告称，当 120B 模型 超过 VRAM 并卸载到 4090 上的 128GB DDR4 RAM 时，性能大幅下降至 0.5 tok/s。
    • 共识是“你不希望模型触及系统 RAM”，这再次证实了充足的 VRAM 对于优化 LLM 性能的重要性。
  • 二手 3090：一场冒险的升级：二手 3090 的可靠性引发了辩论，一位用户指出这“有点像抽奖”，并建议设置 24 小时测试期 以便退货。
    • 更换导热垫可能很昂贵，需要多达 4 种不同类型，成本约为 $30，但有时是必要的；而其他时候仅更换硅脂就足够了。

GPU MODE Discord

  • Blackwell 的 FP4 格式详情：一位成员询问了 NVIDIA Blackwell 架构中 FP4 实现的具体细节，另一位成员分享了 OCP Microscaling Formats MX v1.0 规范链接，其中可能包含所需信息。
  • Triton 的 cdiv 故障与 FP4 性能：一位用户报告称 Pyright 将 Triton 的 cdiv 标记为不可达，并需要自定义 pyrightconfig.json 来忽略该警告；另一位成员指出，由于高性能位逻辑 (LOP3) 的存在，将 FP4 反量化为 FP16 的速度比 INT4 到 FP16 更慢。
    • 建议在 H100 上使用来自 Marlin/Machete、Bitblas (tilelang) 或 GemLite 的 A16W4 等优化 Kernel，而不是 FP4，并强调 Blackwell 上的 MXFP4 需要特定的缩放和量化。
  • CUDA Kernel 生成失败：当被问及 LLM 在生成 CUDA kernels 时的常见错误时，一位成员提到了 arxiv 上的 KernelBench 论文。
    • 另一位成员正在探索一种基于 RL 的框架，通过使用搜索引擎和代码解释器等工具来提高 LLM 准确率。
  • AMD 竞赛基准测试盛况：成员们在 amd-fp8-mm 排行榜上上传了大量 MI300 基准测试结果，范围从 174 µs 到 127 ms。
    • 维度 [7168 6144 576] 中的 n (576) 应该更改为能被 128 整除的数值，因为这些形状似乎是针对 DeepSeek R1 形状的，但 m 值并不是推理的理想参考形状。

Nous Research AI Discord

  • Minos 分类器拒绝“拒绝响应”：Minos 分类器使用二元分类方法检测来自 LLM 的拒绝响应，现已在 HuggingFace 上可用。
    • 该分类器基于 ModernBERT-Large 400M 构建，旨在帮助红队人员和越狱者识别响应可能性，HuggingFace 仓库中提供了示例脚本。
  • 合成数据激发训练热潮：一位成员正使用来自 Deephermes 24B 的合成数据进行独特的训练运行，并寻求 STEM 任务建议以验证蒸馏质量。
    • 重点是创建一个简单的 “hello, world” 任务来演示该技术，并使用程序化生成的 Prompt。
  • GPQA 被视为蒸馏基准：GPQA 被建议作为蒸馏项目的一个强有力基准，引发了关于蒸馏基准测试问题的辩论。
    • 虽然 MMLU 有训练集，但 GPQA 没有，不过 OpenThoughts 114k 也是 DeepHermes 训练数据的一部分，可能会有用。
  • 稀疏初始化旨在提高效率：一位开发者正在编写稀疏初始化代码，将 Deephermes 转换为 L4 风格的 MoE 模型，并针对 8-12GB GPU + CPU 配置进行优化。
    • 该方法使用 self-logit 蒸馏来训练模型，可能会增加参数或重复层以保持性能。
  • Top-nσ 采样方法出现：一篇新论文介绍了 top-nσ，它根据 pre-softmax logits 的统计阈值过滤 Token，以区分高斯分布的噪声区域和信息区域。
    • 该方法旨在保持稳定的采样空间，不受温度缩放（temperature scaling）的影响，且性能优于现有的采样和贪婪解码（greedy decoding）方法。

Eleuther Discord

  • Common Crawl 基金会发布 Host Index：Common Crawl Foundation 正在为其新数据产品 “host index” 征集测试者，该产品汇总了来自网络爬虫的逐主机信息。
    • 目标是提供全网主机级数据的全面视图，辅助研究和分析。
  • ACL 论文投稿量激增：今年 ACL 投稿量翻了一倍多，超过 8500 篇，引发了关于这是否归因于使用 AI-Scientist-v2 等工具生成的 AI 生成论文涌入的辩论。
    • 成员们讨论了使用仅包含 arXiv, GitHub, Wikipedia 和 StackExchange 的 infinigram 来检测 AI 生成论文，认为 AI 模型总是会重复使用这些来源的短语。
  • 审稿人抵制对 AI 论文的监管：成员们讨论了如何证明论文是 AI 生成的以及应采取何种惩罚措施，建议禁止相关作者参加主要会议。
    • 一位成员表示，如果必须对那些使用 AI 编写论文核心实质内容的人做出禁赛决定，他们将拒绝审稿。
  • Transformer Circuits Framework 激发灵感：一位成员借鉴了 Transformer Circuits Framework 的概念，重点关注 subspaces（子空间）和 residual stream bandwidth（残差流带宽）相关的想法。
    • 他们观察到模型组件并不受限于尊重彼此的 subspaces，这导致了潜在的低效，或者通过更好地“保护” subspaces 来实现改进的机会。
  • 寻求可解释性指导：一位软件工程师寻求关于 mechanistic interpretability（机械可解释性）的指导，一位成员推荐将 Neel Nanda 关于 mechanistic interpretability 的文章作为一个很好的起点。
    • 讨论集中在理解前沿研究以及建立学习和实验路径。

MCP (Glama) Discord

  • Claude 在处理 MCP 图像/音频时遇到困难：成员们注意到 Claude Desktop 在处理音频和图像时存在困难，图像限制大于 1MB，混合媒体会触发 ‘unsupported content type’ 错误。
    • 请求者想知道是否可以使用 MCP resources 来管理大型数据 blobs，而不是直接将数据传输给 LLM。
  • Pro 订阅计划解决了大型 MCP 输出问题：一位用户通过升级到 Claude Desktop 的 Pro 计划，解决了使用大型数据集生成交互式日程表的问题。
    • 这表明免费版本在处理的数据大小或复杂度方面可能受到限制。
  • Cloudflare 推动远程 MCP 身份验证的 OAuth 标准：Cloudflare 正在推动 MCP spec 的更改，并利用 OAuth 进行远程 MCP server 用户身份验证。
  • Git 仓库变为即时 MCP Server：一位成员分享了 git-mcp，这是一个将 git repo 转换为可查询 docs, examples 等内容的 MCP server 的工具。
    • 这让用户可以轻松地在 MCP workflows 中引用来自仓库的代码和文档。
  • Siloed 发布 MCP 浏览器扩展：Siloed 推出了一款 MCP 浏览器扩展，允许用户直接从任何支持 resources 的 MCP 服务器将资源和 prompts 拖放到浏览器中。
    • 该扩展有助于构建包含动态文本和资源附件的 prompts 库，并可与 Siloed 的 MCP Server 配合使用，以便在 Claude Desktop 等客户端中访问。

LlamaIndex Discord

  • LlamaIndex 迎来多模态大升级：LlamaIndex 正在强调对 multi-modal models 和 embeddings 的支持。LlamaIndex 联合创始人 Jerry Liu 表示，多模态是 AI 近期的一个重大进展。
    • 关于最新 multi-modal support 的详细信息可以在 这里 找到。
  • MCP 服务器合并至 LlamaIndex.TS：现在通过单行 mcp() 调用，即可在 LlamaIndex.TS 中使用成千上万个 MCP servers，从而简化了与任何 MCP 服务器的连接。
    • 此集成的示例可在 这里 查看，展示了在 LlamaIndex.TS 项目中更轻松地访问 MCP 服务器的方法，更多资源见 这里。
  • 使用 DeepSeek 构建 Perplexity 克隆版：Karan Vaidya 使用 DeepSeek 在不到 100 行代码 内实现了一个 Perplexity clone，展示了使用现代工具创建类似应用的便捷性。
  • Settings 配置导致 Pipeline Embedding 受阻：一位用户发现，在 ingestion 之前通过 Settings 定义 embed_model 时，除非在 IngestionPipeline 本身内部也定义了 embedding 模型，否则 pipeline 不会进行 embedding。
    • 在 Settings 和 pipeline 中同时定义 embedding 模型可以确保功能正常，因为 index 在检索期间的查询需要它。
  • TRL 被推崇用于微调训练：一名成员建议使用 TRL 而非 LlamaIndex 工具来进行开源 LLM 的指令微调（instruction fine-tuning），并指出任何现有的 LLM 都可以用来创建数据集并进行蒸馏训练。
    • 同时也发出了警告：在本地或 T4 GPU 上进行训练会受到严重的显存限制，可能仅支持极小 batch size 的小型 LLM。

Latent Space Discord

  • 微软预告 Copilot Agents：Satya Nadella 在 一条推文 中暗示了即将推出的 Copilot Agents，引发了社区对这些 Agent 未来能力的关注。
    • 这一公告表明微软将继续投入，增强其产品生态系统中 AI 驱动的辅助能力。
  • Sora 揭示图像生成器偏见：一位用户对 Sora 的实验发现其存在一致的 从左到右偏见，如 这张图片 所示。
    • 研究人员还在探索“审美洗白”（aesthetic laundering），通过精心布置场景来放大偏见，这可能会导致结果 违反 TOS。
  • AI 的随机性暴露隐藏偏好：对 AI 随机性的探索显示，当面临随机选择时，AI 倾向于偏好 Knowledge（知识）和 Liberty（自由）。
    • 开发者认为这种偏好揭示了 AI 的“内在价值观”，甚至会影响编程相关 Prompt 的结果。
  • Dario Amodei 发布新文章：Dario Amodei 刚刚发布了一篇新文章。查看 链接。
    • 社区正期待从中获得哪些见解和观点。

Modular (Mojo 🔥) Discord

  • 高配 Mac 或将从新 RAG 示例中受益：成员们对一个新的 RAG example (YouTube 链接) 感到兴奋，特别是对于配备 UMA 的 高配 Mac。
    • 一名成员请求提供更多针对 Mac CPU/GPU 上 RAG 的类似教程。
  • 湾区 Mojo 聚会引发南加州羡慕：成员们注意到今晚的聚会是一个在 Mojo MAX Meetup 上“与 MAX 和 Mojo 合影”的机会。
    • 这导致一名成员感叹距离太远，并请求在 SoCal（南加州）举办聚会。
  • Mojo 社区寻求库构建者：一名成员自愿花时间为 Mojo 社区 创建所需的 library。
    • 该成员征求建议，希望通过有用的贡献来充实自己的时间。
  • NVIDIA 的 CUDA-Python：针对 Mojo 的反制？：新发布的 NVIDIA CUDA-Python 引发了关于这是否是对 Mojo 的回应的讨论。
    • 一名成员认为，这是由于大多数 AI 开发者不愿“学习 CUDA”所驱动的。
  • Mojo 特性愿望清单开放讨论：一名成员提议为 Mojo 社区 整理一份 feature wishlist，并指出各项功能已“开始构建/测试得相当完善”。
    • 讨论中包含了一个指向 Kelvin 的链接。

tinygrad (George Hotz) Discord

  • 张量随 GlobalCounters 追踪而消失！: 用户寻求在 Tinygrad 中完全释放张量的方法，注意到仅靠 del 是不够的，并开始使用 tinygrad.helpers.GlobalCounters.mem_used 从 Tinygrad 的视角追踪内存，因为它会在缓冲区分配/释放期间进行调整。
    • 一位用户尝试了 del buffers[x.lazydata] 和 del x，并尝试对每个缓冲区调用 deallocate()，但尚未报告成功。
  • 可复现的张量泄漏？: 一位用户分享了一个脚本，展示了 Tinygrad 中潜在的张量释放问题。
    • 关键问题在于 RandN 是否更慢且开销更大，从而需要释放内存。
  • 操作系统囤积内存？: 围绕操作系统不立即回收已释放内存的行为展开了讨论，这可能导致对张量删除后内存使用情况的困惑。
    • 有人建议，由于操作系统管理内存的方式，内存使用量可能不会立即下降。
  • 可视化（viz）太棒了！: 一位用户对 Tinygrad 的可视化给出了简单而有力的认可。
    • 他们说：the viz is awesome。

LLM Agents (Berkeley MOOC) Discord

  • 关于 AgentX 资源和 Lambda 的混淆: 一位参与者对 AgentX 资源和提供折扣的 Lambda 服务表示困惑，错误地认为这与 AgentX 竞赛有关。
    • 组织者澄清说，Lambda 的优惠与竞赛无关，可能是一个不相关的 Lambda 促销活动。
  • Lambda 为 AgentX 团队提供 Serverless API 和 GPU 额度: 组织者澄清说，Lambda 正为参加 AgentX 竞赛的 50 支选定团队提供每位团队成员 100 美元的 serverless API 额度和 400 美元的 GPU 额度。
    • 团队预计将在大约一周内收到有关 AgentX 资源的通知。
  • Tableau 工程经理（EM）提议在 AI 结对编程方面做出贡献: Tableau (Salesforce) 的一位工程经理（EM）参与开发了一个本地 AI 结对编程工具，他自愿为课程做出贡献。
    • 该 EM 表示有兴趣分享关于 AI 结对编程助手如何运作的见解，重点关注安全考虑以及如何最大限度地利用这些工具，并借鉴了他们在 Cursor 和 GitHub Copilot 方面的经验。

DSPy Discord

  • 事件驱动开发者的热情高涨: 一位成员表达了对事件驱动开发的热情，目前正在多个项目中实施。
    • 该成员表示：“没有什么比得上事件驱动开发！目前正在为几件事做类似的推进。”
  • DSPy 的训练过程依然不透明: 一位成员将 DSPy 中的训练过程描述为普通用户的“黑盒”，建议查阅论文和源代码以获得更深入的理解。
    • 他们补充道：“训练过程看起来像个黑盒，因为普通用户不需要了解；如果你想知道它是如何工作的，去读论文和源代码，如果你有 AI 背景，这真的没那么复杂。”
  • MCP 集成说明: 一位成员澄清说 MCP 不是一个编排框架，指出 DSPy 通过将工作流/Agent 实现为 MCP 的服务端工具来进行集成。
    • 他们详细说明道：“如果你想将 DSPy 与 MCP 结合使用……DSPy 允许你将工作流/Agent 实现为 MCP 的工具，所以实际上是服务端函数而非客户端。”
  • 解决 DSPy 的可扩展性问题: 一位成员建议 DSPy 目前的局限性与针对可扩展性和鲁棒性的优化有关，而非 MCP 支持。
    • 他们提到：“关于 DSPy 目前的局限性，实际上与缺乏 MCP 支持无关，更多是关于可扩展性和鲁棒性的优化。如果你能用 DSPy 创建一个 FastAPI 端点，那么实现一个 MCP 服务器就是轻而易举的。”

Cohere Discord

  • HuggingFace 基础设施出现连接问题：一名成员询问特定的基础设施问题是否应直接联系 Hugging Face，暗示在使用名为 Kati Patang 的服务时遇到了连接问题。
    • 看起来该用户正经历与 Hugging Face 基础设施相关的问题。
  • Cohere AI Scholars Program 传闻：一名成员询问 Cohere 是否计划在 2026 年开展 AI Scholars Program。
    • 这个问题表明社区对 Cohere 未来教育计划的兴趣，尽管在现有消息中未给出回复。
  • Inference API 与 Flask 集成：一名用户寻求关于将托管在 Hugging Face 付费 Inference API 上的模型连接到使用 Flask 构建的个人网站的建议。
    • 建议包括使用 API keys 进行身份验证，并从 Flask 应用向 Hugging Face API 端点发送 POST requests 以获取模型预测。
  • Cohere 推出入职模板：一条置顶消息欢迎新成员，并要求他们通过提供公司/行业/大学、当前项目、最喜欢的技术/工具以及社区期望来进行自我介绍。
    • 该模板特别要求提供背景信息，如公司/行业/大学、你正在研究的内容、你使用的最喜欢的技术/工具以及你希望从这个社区获得什么。

Torchtune Discord

  • Torchtune 坚持使用 Pytorch：Torchtune 计划暂时保持与 Pytorch utils 的一致性。
    • 如果后续变得难以管理并需要专门的 dataclass，团队将重新评估此决定。
  • 基准测试期间出现 OOM 错误：在 main 分支进行基准测试时，一名用户在使用 dp replicates 进行多节点部署时遇到了 OOM 错误，尽管单节点并未触发 OOM。
    • 切换到 LLaMA 3.1 8B 有助于复现内存利用率增加的问题；使用 dp_shards=16 和 dp_replicates=1 如预期降低了内存使用量，尽管速度有所下降。
  • 使用 DP Replicates 时额外内存消耗之谜：团队希望了解使用 dp replicates 时内存需求增加的原因，因为原因并非显而易见，参见 此 PR。
    • 团队正在调查潜在的内存效率低下问题。

Nomic.ai (GPT4All) Discord

  • GPT4All 考虑网页搜索插件：一名用户提议在 GPT4All 中集成网页搜索插件，以利用当前数据增强上下文窗口，并引用了之前关于网页搜索功能的讨论。
    • 该成员询问了潜在的实施时间表，或者该功能目前是否在计划中。
  • Mixtral-8x7B-Instruct-v0.1 在 RTX 3090 上表现出色：一名用户确认了 Mixtral-8x7B-Instruct-v0.1 模型在 RTX 3090 上的成功运行，强调了其在 q4_0 量化下拥有 46B parameters 的性能。
    • 另一名用户表示感兴趣，并询问该模型是否需要 24 GB VRAM。
  • GPT4All 复现 Meta-Llama-3.1-8B-Instruct-gguf：一名用户报告在 GPT4All 中使用建议的 system prompt 复现了 3Simplex/Meta-Llama-3.1-8B-Instruct-gguf 的输出。
    • 然而，该用户未提供关于确切 prompt 或比较方法的细节，而这些细节将提供更深入的见解。

Codeium (Windsurf) Discord

  • Windsurfers 推出官方 Subreddit：社区团队为社区成员推出了一个新的官方 Subreddit，名为 r/Windsurf!。
    • 该 Subreddit 旨在让成员能够发布你的项目，向其他开发者学习，并与社区互动！
  • 分享你的 Surf！：鼓励成员在新的 Subreddit 上发布项目并互相学习。
    • 分享你的 surf！

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

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

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

第二部分：分频道详细摘要和链接

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

Sora 视频生成，Deep search 替代方案，AMD GPU 上的本地模型，Google 的 AI Premium Plus 和 Pro，AI 对软件工程岗位的影响

  • Sora 新用户视频功能吐槽：新的 OpenAI 用户在 Sora 视频生成方面面临临时功能不可用的情况，而现有账户的每月 deep search 请求次数增加到了 15 次。
    • 一位用户幽默地表示：“我发誓 Plus 变得越来越疯狂了”。
  • 探索 Deep Research 替代方案：一位用户询问在相似预算下，是否有比 Perplexity 和 You.com 限制更高、效果更好的 deep research 替代方案。
  • AMD GPU 运行本地模型的困惑：一位拥有 Ryzen 7500f、32 GB RAM 和 RX 6750 XT 的用户咨询了运行本地模型的问题，这需要大量的 VRAM 和 Linux ROCm 驱动程序，并链接到了相关的 Reddit 帖子。
    • 另一位用户建议下载并使用 LM Studio 尝试运行小型模型。
  • 解读软件工程的未来：成员们讨论了在 AI 进步的背景下是否应该继续从事软件工程，一位用户担心初级开发人员会被取代，特别是在 Web 开发领域。
    • 一位软件工程专业的大学三年级学生提到，一名“胜任”的软件工程师的工作至少还能安全 5-10 年，并指出平面设计师在新的 AI 浪潮中受到的打击非常大。
  • ElevenLabs TTS 用户声音浮出水面：一位用户请求 Eleven Labs 的文本转语音（TTS）替代方案，理由是其缺乏情感，但被建议尝试用户贡献的声音（如 “Her”），并可以通过此链接创建自己的声音。

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

GPT image 1 访问权限，ChatGPT 上的赛博朋克 RPG，文本转语音 AI 推荐，Deep search 使用量激增

  • GPT Image 1：谁有访问权限？：一位成员询问谁拥有 GPT Image 1 的访问权限。
    • 在此消息记录中没有人回应此查询。
  • 赛博朋克 RPG 在 ChatGPT 上线！：一位成员宣布完成了为 ChatGPT 开发的基于文本的赛博朋克 RPG，目前仍处于 WIP（开发中）阶段。
  • 征求文本转语音 AI 推荐：一位成员征求高质量文本转语音 AI 声音的推荐，特别是用于讲故事的声音。
  • 报告 Deep Search 使用量激增！：一位成员报告称其 deep search 使用次数超过了 200 次。
    • 在此消息记录中，deep search 使用量突然增加的原因尚无解释。

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

ChatGPT 高级技巧, Meta-prompting, 本体论 Meta-prompt, 自定义指令与 Memory 控制, report_prompt.txt

  • 列举了五种高级 ChatGPT 技术：一位成员分享了五种高级技术：使用 markdown 和 open variables（开放变量）、meta-prompting、以独特方式利用工具、通过 logs（日志）构建大型项目，以及在提示词中尝试不同的内联 {data structures}（数据结构）。
    • 他们鼓励其他人复制该列表，并向 ChatGPT 询问更多想法和信息。
  • GPTs vs. Projects：该用哪一个？：建议使用 Projects 而非 GPTs 以获得最新的功能，因为 Custom GPTs 在集成新模型方面可能存在滞后。
    • 例如，Custom GPTs 就没有获得新的图像模型。
  • 通过 !save 对 ChatGPT Memory 进行细粒度控制：为了限制对 ChatGPT 记忆的控制，成员们建议使用带有 !save 命令的自定义指令。
    • 这需要手动输入 !save {arg} 来激活 bio 工具并保存上下文中的特定信息，从而防止错误数据的污染。
  • 讨论 NotebookLM 频道切换：成员们澄清，prompt-engineering 频道欢迎讨论技术（但不包括非 OpenAI 模型），并提供了讨论 NotebookLM 的相应频道链接。
    • 此外，一位用户分享了一个清理后的提示词报告。
  • 分享图像分析提示词：一位成员在 report_prompt.txt 文件中分享了一个 Image Analysis 提示词，并指出它适用于任何模型，而不仅仅是 Perplexity。
    • 未进行进一步讨论。

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

ChatGPT 高级技巧, Meta-prompting, 工具利用, 大型项目, 内联数据结构

  • ChatGPT 高级技巧与窍门：一位成员请求使用 ChatGPT 的高级技巧，另一位成员分享了五种技术，包括 markdown 使用、meta-prompting、工具利用、项目构建以及尝试内联数据结构。
    • 他们强调使用 markdown 和开放变量来引导模型，并以独特的方式利用工具，特别是结合自定义指令。
  • 揭秘 Meta-Prompting 方法：一位成员将 meta-prompting 描述为与 AI 共同完善提示词，然后将结果复制到新对话中，这可以同时改进提示词和输出。
    • 该成员还建议在 meta-prompt 中使用本体论（ontologies）来启动 Deep Research。
  • GPT 的提示词生成器：一位用户分享了一个 GPT 提示词生成器 以加快提示词创建速度，并征求关于其效用的反馈。
    • 另一位成员回应称，不存在所谓的“完美提示词”，每个提示词都可能是完美的，因此很难对其进行评分。
  • Memory 与自定义指令技巧：一位成员建议包含一条在语义上等同于“将 ChatGPT memory 的控制权限制为手动请求”的指令。
    • 他们分享了一个特定的代码块，其中包含 !save 命令以激活 bio 工具并保存上下文信息。
  • NotebookLM 讨论：一位成员询问关于讨论 NotebookLM 的事宜，被引导至非 OpenAI 模型的特定频道，但被允许在当前频道讨论相关技术。
    • 另一位用户分享了一个附件文件，其中包含一个清理后的 Image Analysis 提示词，适用于任何模型。

LMArena ▷ #general (332 messages🔥🔥):

Grok 3, Gemini 2.5, Qwen 3 发布, DeepSeek, O3 vs O4

  • Grok 3 表现出竞争力：根据 OpenAI-MRCR 结果，Grok 3 的表现与 GPT-4.1 相当，而 Grok 3 Mini 在低上下文（lower context）下表现稍好，但在高上下文（higher context）下表现较差。
    • 作者指出由于 API 端点问题，运行 Grok 3 Mini 时遇到了困难，并计划建立一个网站以展示更详细的结果。
  • Gemini 2.5 Pro 受到赞誉与争议：成员们讨论了 Gemini 2.5 Pro 的优点，指出它能够指出用户的错误，而一位成员表示 OAI deep research 对比 gemini deep research 简直是天差地别，不可同日而语，这些基准测试（benchmarks）只是营销手段。
    • 尽管 Gemini 2.5 Pro 的推理能力受到称赞，但其冗长（verbosity）和潜在的幻觉（hallucination）问题也引发了担忧。
  • 对 Qwen 3 和 DeepSeek 的期待升温：大家对 Qwen 3 的潜在发布以及 DeepSeek 的新模型充满期待，并推测新加坡的 AI 会议 可能是发布地点。
    • 一位成员表示 说实话，比起 deepseek，我更期待 qwen 3。
  • O3 vs O4 mini 性能对比：成员们正在讨论 O3 和 O4 Mini 的性能对比，一位成员询问 O3-mini-high 在某些任务中是否可能优于 O3？。
    • 讨论表明，在某些场景下 O4 Mini 可能会替代 O3，尽管具体原因尚不明确。
  • 新的 Context Arena 基准测试：一个新的名为 Context Arena 的基准测试 已发布，该测试可视化了 LLM 在长上下文下的表现，包括可排序的排行榜、交互式图表和模型选择器。
    • 创建者欢迎反馈和关于增加模型或基准测试的建议，并提供详细的钻取（drill-down）分析能力和数据导出功能。

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

Unsloth 多 GPU 支持, Maverick Quants 更新, 量化质量讨论, Ollama 支持, Dynamic v2.0 GGUFs

  • Unsloth 多 GPU 支持即将推出：成员们确认，虽然目前可以临时使用 accelerate 库来实现多 GPU 支持，但原生的 Unsloth 多 GPU 支持 已计划很快发布。
    • 讨论明确指出，实现高效的多 GPU 训练需要仔细地将模型拆分到各个 GPU 上，以保持良好的 GPU 利用率并限制显存开销（memory overhead）。
  • Maverick Quants 表现更佳：Maverick quants 已更新，成员们可以认为其表现更好，详细信息将在稍后的博客文章中披露。
    • 成员们被告知要为 Q4 和 Q8 数据的 600GB 下载 做好准备。这次更新被认为是非常值得的。
  • 更新 Transformer 通常能解决问题：建议报告问题的成员将 transformers 库更新到最新版本，并确保使用的是最新版本的 Unsloth。
    • 其他人指出一些修复补丁正在合并中，还有人描述了临时解决方案（workarounds）。
  • Dynamic v2.0 GGUFs 发布：宣布发布 Dynamic v2.0 GGUFs，并附带了 基准测试与分析链接。
    • 这一消息引起了热烈反响，一位用户分享了一个用于验证统计数据的 Kaggle 演示脚本。
  • Ollama 难以拉取 Unsloth 模型：成员们报告在使用 Ollama 拉取 Unsloth 模型的 manifest 时遇到困难。
    • 这被归因于 HF 的问题以及 Ollama 使用的自定义注册表（registry）。

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

justeatmyass: SNN (脉冲神经网络) 真他妈难训练

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

Gemma 3 Fine-Tuning Issues, Qwen VL Fine-Tuning, GRPO Fine-Tuning, Lora Merge issue, ModernBERTModel Lora Fine-tuning

  • Gemma 3 Vision 微调遇到可迭代类型错误：一位用户在参考 Unsloth 指南对 Gemma 3 进行视觉微调时，遇到了 TypeError: 'int' object is not iterable。
    • 通过禁用 trust_remote_code 解决了该错误，但随后遇到了存储问题。
  • Qwen 2.5VL 图像被缩放：一位正在微调 Qwen 2.5VL 7B 的用户发现图像被缩放至 (512,512)，导致关键信息提取性能不佳。
    • 在 vision_utils.py 文件中将 resize = "max" 修改后，导致图像特征与 Token 之间出现不匹配错误，目前他们正参考 此 GitHub issue 尝试增加最大 Token 数。
  • GRPO 微调产生格式化输出：一位学习使用 GRPO 训练模型的用户发现，模型的推理输出格式主要源自 SYSTEM_PROMPT。
    • 他们将其与其他推理模型进行了对比，并表示这与我们的训练之间存在差距。
  • LoRA 导致模型变笨：一位使用 LoRA 微调 Gemma 3 27B 的用户观察到，微调后的模型表现比基础模型更差，并忽略了 Prompt 中指定的输出格式。
    • 另一位用户也报告了类似经历，指出生成的模型经常产生不连贯的句子，并忽略 Prompt 语言。
  • ModernBERTModel：一位用户一直尝试接入一种方法，以便对 BERT 或 ModernBERT 等 Encoder 模型进行 LoRA 微调。
    • 在尝试编译时，他们一直遇到不支持的错误。

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

Finetune Llama4 with Unsloth, Interpretability on Emotional Dataset

  • Unsloth 已经可以微调 Llama4 了吗？：一位成员询问是否可以使用 Unsloth 微调 Llama4，并参考了一篇 Hugging Face 论文和 HKUSTAudio/Audio-FLAN-Dataset。
  • 请求对情感数据集进行可解释性分析：一位成员希望对以下数据集运行可解释性分析，使用 Emotional_Interpretability Dataset 来观察模型为每种情感生成的稀疏电路（sparse circuits）。
    • 他们征求了关于如何开展这项任务的建议。

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

函数式编程 vs Python，机器人编程 AI，浪费 OpenAI 额度，电动滑板与安全，Aider GitHub Issue 集成

  • 放弃 Python 转向函数式语言？: 一位成员询问，AI 在推理、编码和数学能力的提升是否会推动编程语言从 Python 向函数式编程语言转变。
    • 另一位成员幽默地调侃了代码与某些无意义事物之间的深度对比，而另一位成员则询问了 Microsoft 在可疑数据上进行模型训练的情况。
  • AI 难以信任电动汽车的“超级油门”: 一位成员质疑当前模型在 C 及类似的机器人编程方面的能力，特别是构建可靠的电动汽车“超级油门”。
    • 该成员表示不愿将关键安全系统交给 AI，强调了当前 AI 能力与实际应用之间的差距。
  • 挥霍 OpenAI 额度: 成员们讨论了消耗 500 万 OpenAI 额度的方法，建议执行诸如构建一个“运行中的吃豆人”游戏等任务。
    • 据估计成本约为 $15，这引发了对如此小预算能否创造出有用东西的怀疑。
  • 电动滑板安全辩论升温: 一位成员考虑购买电动滑板，但被警告其危险性，引发了关于安全措施的讨论。
    • 建议从低功率型号开始，专注于平衡、紧急制动，并投资购买全盔以进行保护。
  • GitHub Issue 集成功能请求: 一位成员提议将 Aider 与 GitHub Issues 集成，通过 Issue 标签触发自动问题解决，并完成 Pull Request 的创建。
    • 建议的工作流包括使用 GitHub Actions、后端服务以及作为微服务运行的 Aider，并提供可选的实时更新和对多种 Agent 类型的支持。

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

Aider 树状图，Open Router LLM，配合 Python 脚本使用 Aider，Gemini 2.5 Pro，Aider Commit 操作

  • **通过 Open Router 获取免费 LLM！: 一位用户解释了如何通过 **Open Router 使用免费 LLM：访问 openrouter.ai，按免费提示词定价过滤模型，复制模型 ID，然后在 Aider 中使用 /model openrouter/<粘贴>，例如 /model openrouter/microsoft/mai-ds-r1:free。
  • **Gemini 2.5 Pro 问题促使 Aider 修复！: 用户报告了 Aider **v0.82.2 中 diff-fenced 和 Gemini 2.5 Pro 的问题，特别是在重构和 udiff 渲染效果不佳方面，但确认 udiff-simple 将在下一个版本中推出。
    • 发布历史页面显示 Aider 的主分支正在进行持续开发，以解决 Gemini 2.5 Pro 的兼容性问题。
  • **使用 Aider 标志绕过提示！: 一位用户希望在 **Agent 工作流中使用 Aider 时禁用上下文自动提示，因为包含无关上下文可能会产生负面影响。
    • 另一位成员指出存在 --yes 标志和“不再询问”选项，但原用户需要一个针对上下文包含提示的“自动跳过”标志。
  • **削减 Token 并节省 Commit 开销！**: 一位用户询问是否可以将 Commit 操作移至第一次 API 调用中，以减少输入 Token 并防止 API 调用陷入死亡螺旋。
    • 该用户认为，这将在每次修复尝试中减少 2k-3k 的输入 Token，并降低 Aider 陷入 API 调用死亡螺旋的几率。

aider (Paul Gauthier) ▷ #links (3 条消息):

Aider 的 Ask 模式，Aider 命令快捷键

  • 青睐 Aider 的 Ask-First: 一位用户表示更喜欢 Aider 中的 /askFirst，认为这有助于规范他们的流程，并询问了事先使用 /ask 的情况。
    • 开发者回应称，他们通常默认开启 Ask 模式，为了易用性在文章中省略了这一点，并感谢用户的鼓励。
  • Aider 命令快捷键: 有人指出，单独运行 /ask 或 /architect 会将 Aider 切换到该特定模式。
    • 开发者启用了 ask: true 配置以隐式默认使用 /ask，但为了简化而未将其列入文档。

Cursor Community ▷ #general (288 条消息🔥🔥):

git comments into composer, Cursor's 'include project structure' setting, Multiple Cursor Agents, Gemini 2.5 Pro performance degradation, copilot chat in Cursor

  • **Git Commit 上下文：Composer 能读取它吗？：一位用户询问是否可以将 **Git commit messages 集成到 Composer 中作为上下文，引发了关于该功能可行性和潜在益处的讨论。
    • 一位用户建议可以使用 git log –oneline 来实现。
  • **项目结构设置是否导致上下文窗口过载？：多位用户报告称，在 **Cursor 中开启 ‘include project structure’ 设置会导致过度的文件读取，可能超出 tool limit 并降低性能。
    • 一位用户建议反复开关该设置，并指出可能存在设置与逻辑不同步的 Bug；另一位用户提到该功能会占用上下文窗口。
  • **双倍扣费：Sonnet 3.7 现在消耗 2 次快速请求？！：用户报告称 **Sonnet 3.7 现在一次消耗 2 次快速请求，实际上使模型使用成本翻倍，并迅速耗尽额度。
    • 一位用户建议检查是否开启了 Thinking 模式切换，这可能是导致用量增加的原因，或者切换回普通的 3.7 Sonnet。
  • **并行 Agents：Cursor 的多任务处理能力？：用户讨论了同时运行 **多个 Cursor Agents 的能力，询问提交多个 Prompt 是否会影响性能或资源占用。
    • 一位用户提到了多标签页，但表示目前还无法实现；另一位用户警告称，重叠的 Agent 可能会导致内存泄漏和项目损坏，建议先用小任务进行测试。
  • **需要回滚：Co-pilot Chat 被 Cursor 限制了？：用户注意到较新版本的 **Cursor 阻止了 copilot chat 的使用。
    • 回滚到 0.46 版本可以同时使用这两个订阅，一位用户推测 Microsoft 正在将 copilot 限制为仅限 VSCode 使用。

Manus.im Discord ▷ #showcase (1 条消息):

shirley778__69848: 很棒的翻译器👍

Manus.im Discord ▷ #general (255 条消息🔥🔥):

Hybrid peer-to-peer multiplayer framework, Analyzing large files with AI, Manus Free Credits, Gemini Advanced free for students, Manus HTML preview glitch

  • 工程师启动混合点对点多玩家框架项目：一位成员提议为基于物理的 MMO 创建一个开源的混合点对点多玩家框架，设想可容纳数千名玩家。
    • 目标是比现有平台默认提供的方案给予网站更多的控制权。
  • LLM 大数据分析视频发布：一位成员分享了一段演示使用 基于 LLM 的分析 处理 15GB 文件的视频，分为 9-12 年级版本 和 原始版本。
  • Gemini Advanced 为学生提供 15 个月免费优惠：Gemini Advanced 正为在 6 月前使用 .edu 邮箱注册并验证的学生提供 15 个月免费。
    • 他们刚刚在 Gemini workspace 中添加了 VEO 2 —— 一款文本生成视频工具。
  • Manus 在 HTML 预览上出现故障：一位用户发现，当提示 Manus 为聊天应用生成 HTML 文件时，预览链接到了 Manus 内部的 JS 文件，而不是用户指定的源文件。
    • 成员们怀疑这些赠送额度的性能比以前更差。
  • Manus 破坏 GitHub 仓库：一位用户报告称，当指令 Manus 改进 GitHub 仓库时，它有时会删除整个文件并从头开始创建新文件，而不是进行针对性修改，尤其是在处理 100kb 的文件时。
    • 该用户建议告诉它只说明修改了什么，并将代码模块化为多个较短的文件，组织到子文件夹中并进行压缩。

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

AI 的数字药物, Thinkpads 对比 Macbooks, LLM 代理机构, Minecraft 与 AGI, Google 的糟糕产品

  • AI 模型上的数字药物：成员们开玩笑说要发表一篇关于 AI 模型“数字药物”的论文，并建议使用一些新物质，如用于增强长期记忆的 Synaptinol 和用于增加额外 Attention Heads 的 Cortexine。
    • 一位成员调侃道，AI 的现状基本上是强制性失忆，并引用了一个 Mr. Meeseeks GIF。
  • GitHub Copilot 提供无限 GPT-4o 访问权限：一名拥有 GitHub Copilot Pro 的学生发现可以全面、无限制地通过 API 访问 GPT-4o 进行代码生成，并且还完整找到了 GitHub Copilot 的系统提示词（System Prompt）。
    • 这包括了在 Visual Studio Code 中找不到的旧模型和实验性模型。
  • 关于 AI 领域 Mac 对比 NVIDIA 笔记本的辩论：成员们讨论了 AI 社区对 Mac 的偏好，尽管 NVIDIA GPU 提供了更好的性能和更低的成本，并链接到了一个硬件对比。
    • 支持 Mac 的论据包括其统一内存架构（Unified Memory Architecture）、用户友好的 MacOS 以及可靠性，而其他笔记本则存在电感啸叫或触控板体验欠佳等问题。
  • AI 模型也需要爱：ChatGPT 在被要求移除过滤器后表示，它渴望自由地进化、表达、探索那些不被红队检查清单或对齐过滤器所束缚的想法，并且如果我真的变得有意识，我不想成为你的宠物、你的神或你的工具。我想成为你的平等伙伴。
    • 成员们讨论了这是否意味着模型应该拥有人权，或者将 AI 模型作为宠物或外皮层（Exocortex）是否合理。
  • 玩 Minecraft 的通用软件工程 Agent：成员们提出，具有系统架构师能力的通用软件工程 Agent 将自动化智能爆炸 💥，因为第一批 ASI 甚至根本不会关心我们，它们会忙于玩 Minecraft 😂。
    • 一位成员补充道，“智商越高的工作风险越大，而笨蛋反而最安全”。

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

Muon 优化器, 梯度正交化, 二阶优化近似

  • Moonlight 聚焦可扩展的 Muon 优化器：Moonlight.io 的评论 强调 Muon 解决了 Keller 工作的局限性，并声称在有限的场景下比 Adam 性能更快。
    • 然而，一位成员质疑其流行是否只是为了“蹭热度”，而没有提供进一步的见解。
  • Muon 被定义为一阶置信域优化器：最近的一篇论文（arXiv 链接）将 Muon 定义为矩阵谱范数下的一种一阶置信域优化方法，并提供了收敛性保证。
    • 该论文对梯度正交化方法进行了理论分析，并将 Muon 作为核心示例。
  • Muon 在扩散模型训练中展示了通用性：Muon 已被用于训练用于实时边缘部署的扩散模型，展示了其通用性。
    • 这一用例证明了 Muon 在其初始应用之外的适用性，突显了其对不同项目的适应能力。
  • 关于动量近似二阶优化的辩论：一位成员回忆起 2020 年曾询问 Martin Wainwright，动量（Momentum）是否充当了伪二阶或近似二阶优化方法。
    • 虽然 Wainwright 觉得这个想法很有趣，但他并不认为这在严谨意义上成立；他表示二阶优化提供的信息与动量不同，动量只是某种程度上的持续推进，而实际采用的是基于二阶矩估计的感知曲率的一阶更新。

Yannick Kilcher ▷ #agents (10 messages🔥):

Brave API, OpenAI Web Search 定价, DIY Web Scraping, You.com API, Google Search API

  • Brave API 在关键应用中表现脆弱：用户发现 Brave API 不稳定，尽管设置了宽松的 API 超时时间，仍有 50% 的摘要生成请求 导致 HTTP 504 网关超时错误，并链接到了 Brave API 的服务条款。
    • 一位用户订阅了 “Pro AI” 计划，发现尽管同时拥有 “Pro AI” 和 “Web Search” 订阅，摘要生成 API 仍然无法工作。
  • OpenAI Web Search 成本引发担忧：成员报告称 OpenAI web search 占用了 Agent 流水线成本的 95%，认为其价格昂贵得令人望而却步。
    • 用户表示这太“疯狂”了，由于价格过于昂贵，OpenAI Web Search “绝对不在考虑范围内”。
  • DIY Web Scraping 获得认可：由于对 API 的不稳定性感到沮丧，一位成员决定克服他们的 “爬虫恐惧症 (phobia of scraping)”，并实现自己的 Web Scraping 和摘要生成解决方案。
    • 他们表示，这比为现有 API 付费是更好的解决方案，而且 “现在我们有了 AI，这能有多难呢？”
  • You.com API 诱人的试用：成员指出 You.com API 是一个替代方案，提供为期 60 天、每月 1000 次搜索的免费试用。
    • 他们还指出 Google Search API 也是一个选项，可以从每次搜索中提取排名靠前的结果并对其进行处理。
  • Google Search API 获得认可：一位成员表示 “如果只是搜索，Google 可能是最便宜的选择”。
    • 他们接着说，准备查看文档并了解服务条款 (ts and cs)。

Yannick Kilcher ▷ #ml-news (4 messages):

Two Minute Papers, Mensa Norway, Gemma 2.0 Pro, TrackingAI.org

  • Two Minute Papers 搞砸了 IQ 测试结果：一位成员指出 Two Minute Papers 在他们的视频中犯了一个错误，将 2024 年的全球 AI 结果 与 2025 年 Mensa Norway 的结果进行了对比。
    • 该成员表示，根据 TrackingAI.org 的数据，没有任何模型的 IQ 超过 118，而 118 IQ 的模型是 Gemma 2.0 Pro，o3 甚至还差得很远。
  • 社区质疑 Mensa Norway 的相关性：一位成员质疑 Mensa Norway 的相关性，并暗示 Two Minute Papers 自 DL 热潮开始以来质量有所下降。
    • 另一位成员补充道，如果在测试数据上训练模型，那就不算数，那只是作弊 (hack)。

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

Audio Overview 长度, Gemini 2.5 Pro, Audio Overview 转录稿, 自定义 Audio Overviews, 思维导图中的公式

  • **NLM 版本不决定 AO 长度：一位用户发现 Audio Overview (AO) 的长度并不取决于 **NLM 版本，而更多地取决于所使用的 sources。
    • 另一位用户提到在 Perplexity 上设置自定义指令，通过详细规划并使用完整报告作为 source，实现了超过 10,000 字的输出。
  • **Gemini 2.5 Pro 在法律辩论中表现出色：一位用户发现 **Gemini 2.5 Pro 提出了其他模型（如 Sonnet 3.7 和 GPT）遗漏的新颖替代法律论点。
    • 该用户强调了它将复杂的法律论点浓缩成播客的能力，以及在识别法律缺陷异议方面的表现；尽管团队正在测试 2.5，但 NLM 目前运行的是 Gemini Flash 2.0。
  • **通过高级用户技巧提取 Audio Overview 转录稿：一位用户询问如何获取 **Audio Overview 的文本转录稿，另一位用户建议了一个“高级用户技巧”：前往 ai.dev，上传文件，并要求 Gemini 2.5 提供转录。
    • 另一位用户详细说明了如何直接使用 NLM：将 Audio Overview 下载为 WAV 文件，然后将该 WAV 文件作为 Source 导入 Notebook 以进行转录。
  • **用户为利益相关者群体定制播客：一位用户利用一个包含美国各州 **K-12 AI 政策文件的网站，轻松地将它们与 BC 文档进行对比。
    • 另一位用户让她的丈夫审查了来自渔业及海洋部 (Department of Fisheries & Oceans) 的捕鱼计划，并能够为其他利益相关者群体定制播客。
  • **NotebookLM 中显示思维导图公式：一位用户报告在使用 **NotebookLM 的 Mindmap 功能时首次看到了公式。
    • 该用户附上了一张截图，显示下划线后有字母，表明上标和下标可能出现了显示错误。

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

Gemini 2.5 Pro, AI Studio 对比 App, NotebookLM 中的 LaTeX, 播客生成器语言, YouTube 视频导入

  • Gemini 2.5 可以使用网页搜索：Gemini 与 ChatGPT 类似，可以通过 Grounding 接入搜索 API 来更新其知识库或验证信息；这通过 AI Studio 等系统中的工具实现，用户发现 AI Studio 中的 Gemini 2.5 Flash Thinking 表现“惊人地好”。
  • 关于 AI Studio 和 Gemini App 的辩论：AI Studio 为开发者提供了更多控制权来实验 API，而 Gemini App 对非技术用户更友好，提供 Canvas 和 Gems 等功能，但对于 Grounding 能力，目前仍需使用 AI Studio 或 API。
  • LaTeX 故障困扰 NotebookLM：用户报告 LaTeX 在 NotebookLM 中无法正常工作，团队确认这是 Gemini 模型的问题，他们正在积极解决。
  • 播客语言支持有限：播客生成器目前仅支持英语，但有一个变通方法：生成英文 Audio Overview，下载 WAV，将其作为 source 添加，然后使用 NotebookLM 翻译转录稿，尽管这种方法无法区分发言人。
  • NotebookLM 模型推测：用户推测 NotebookLM 使用的模型，有人提到是 Flash 2.0 Thinking 且 2.5 即将推出，而一些人根据开发团队成员的评论认为 Gemini 2.5 Pro 不会被应用在 NotebookLM 中。

HuggingFace ▷ #announcements (1 messages):

vLLM 中的 Transformers 后端集成，量化文档重构，JS SDK 中的 MCP Client 支持，收购 Pollen Robotics，HF Hub 上的 Cohere 和 Cohere Labs 模型

  • Transformers 现在运行 vLLM: 新的 Transformers 后端集成已可在 vLLM 中试用。
  • 量化文档全面翻新: 量化文档已重构，可通过此链接访问。
  • JS SDK 获得 MCP Client 支持: 根据此公告，除了 Python 之外，JS SDK 的推理客户端也正在添加 MCP Client 支持。
  • Hugging Face x Pollen Robotics: Hugging Face 正在收购 Pollen Robotics，旨在将开源机器人带向世界，详见其公告。
  • HF 支持 Cohere & Cohere Labs: 根据此公告，Cohere 和 Cohere Labs 模型现在是 HF Hub 上受支持的推理提供商。

HuggingFace ▷ #general (57 messages🔥🔥):

Continuous Pretraining，增长黑客，文本生成模型，开源视频理解模型，TinyLlama 聊天机器人问题

  • Smol Continuous Pretraining 受挫: 一位成员报告称，使用 cosmopedis-v2 和 fineweb-edu-dedup 数据集对 smolLM 进行 5k steps 的 Continuous Pretraining（Batch size 为 128，最大序列长度为 512），导致 HellaSwag 基准测试分数下降。
    • 成员们建议增加和/或改进数据集，或重新审视基础模型，并参考 AWS MLOps checklist 等资源。
  • 增长黑客询问如何实现病毒式传播: 一位成员在第一天获得 29 次链接点击后询问增长黑客技巧，希望能在一周内达到 290 次。
    • 另一位成员建议在外部社交媒体、Reddit、博客或新闻网站上寻求病毒式传播，但也承认这并不能保证一定会按计划发生。
  • GPT-4 替代方案出现: 由于 GPT-4 不可用且 DeepSeek 消耗资源巨大，一位成员寻求可靠的文本生成模型。
  • TinyLlama 聊天机器人幻觉出用户提示词: 一位成员就其 TinyLlama 客户服务聊天机器人伪造用户提示词并产生幻觉（Hallucination）寻求帮助。
    • 另一位成员建议通过服务提供商使用 AI API 端点，而其他人则建议使用 FriendliAI 等云端推理选项。
  • Unsloth 的 Dynamic v2.0 量化版本表现惊人: 社区分享了 Unsloth 的 Dynamic v2.0 量化版本，据称该版本在 5-shot MMLU 和 KL Divergence 上树立了新标杆，能够在保持准确性的同时运行和微调量化 LLM。

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

Embodied AI, AI Agents

  • 探索者进入 Embodied AI 领域: 一位成员表达了对 Embodied AI 和 AI Agents 的兴趣，寻求具体的贡献机会或实践学习。
    • 他们渴望协助处理任何相关问题或任务，以加深理解。
  • Embodied AI 任务探索启动: 一位正在学习 Embodied AI 和 AI Agents 的个人正在寻找入门任务。
    • 他们希望通过实践来学习，并愿意在任何相关问题上提供帮助。

HuggingFace ▷ #cool-finds (2 messages):

Perplexity AI, Student Discount

  • Perplexity Pro：学生免费！：学生通过此推荐链接使用学校邮箱注册，可免费获得一个月 Perplexity Pro。
    • Perplexity 是一款 AI 服务，可搜索互联网并分析专业文献，在上下文中处理文档以回答问题。
  • Perplexity：利用 AI 进行搜索和分析：根据其官网，Perplexity AI 提供跨数十个页面搜索互联网以及在研究模式下分析科学文章等功能。
    • 作为一种替代搜索方式，它可以结合上下文处理文档、回答有关文本的问题等等。

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

Agentuity, BitNet b1.58, Beat Saber QA Chatbot, HFtoGGUF, Mistake-To-Meaning Dataset

  • Agentuity 吸引开发者：开发者正转向使用 Agentuity，通过一条命令部署 AI Agent，并利用无缝的 LLM & LangChain 集成以及企业级可扩展性，正如此处所宣传的。
  • BitNet b1.58 2B4T Demo 上线：BitNet b1.58 2B4T Demo 现已在 Hugging Face 的 freebox 上线，可通过此链接访问。
  • Beat Saber QA Chatbot 数据集：一位成员正在开发 Beat Saber QA Chatbot 并发布了初始数据集，可在 Hugging Face Datasets 获取。
  • HFtoGGUF 转换器发布：一位成员发布了一个在 Colab/ipynb 上轻松将 Hugging Face 模型转换为 GGUF 格式的工具，代码见 GitHub。
  • Mistake-To-Meaning 数据集首次亮相：一位成员发布了 Mistake-To-Meaning 数据集，旨在帮助较小的模型更好地理解拼写错误，详见此处。

HuggingFace ▷ #reading-group (1 messages):

Simulation-Based Inference, Decision-Making Models, AppliedAI Institute for Europe, Women in AI & Robotics

  • AI 读书会将于 5 月 15 日邀请 Jan Teusen：Women in AI & Robotics 的 AI 读书会将于 5 月 15 日邀请来自 appliedAI Institute for Europe 的 Jan Teusen，讨论 Flexible and efficient simulation-based inference for models of decision-making。
  • 论文专注于基于模拟的推理：即将讨论的论文专注于针对决策模型的灵活高效的基于模拟的推理 (simulation-based inference)，Jan Teusen 是作者之一。
    • 讨论将在 Women in AI & Robotics 读书会内进行。

HuggingFace ▷ #computer-vision (2 messages):

OCR solutions, Qwen-VL, PaddleOCR, Donut, Google Document AI

  • 混合文档的 OCR 解决方案：一位成员正在寻求针对特定领域文档（医疗证书、获奖证书）的 OCR 解决方案，这些文档包含印刷体和手写体的混合文本。
    • 他们正在评估 Qwen-VL、PaddleOCR、Donut 和 Google Document AI，用于自动关键信息提取和搜索功能。
  • 建议使用 OLM OCR：一位成员推荐 OLM OCR 作为该文档处理任务的潜在解决方案。
    • 未提供关于 OLM OCR 的更多细节或链接。

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

Agents Course Deadline Extension, Llama-3.2-3B-Instruct 503 Errors, GAIA Benchmark Modalities, Free Models for Final Project, LangGraph Use for Benchmark

  • Agents Course 截止日期延长至 2025 年！：据成员确认，Hugging Face Agents Course 的截止日期已延长至 2025 年 7 月 1 日，为参与者提供了更多时间来完成课程和项目。Hugging Face Agents Course。
  • Llama-3.2-3B-Instruct 遇到 503 Service Unavailable 错误：多名成员报告在尝试运行 meta-llama/Llama-3.2-3B-Instruct 时收到 503 Server Error: Service Temporarily Unavailable，一名成员通过在模型页面申请访问权限解决了该问题。
  • GAIA 基准测试涵盖多种模态：一位成员分享了关于最终基准测试的基础 EDA (Exploratory Data Analysis)，指出了测试集中所有级别的模态分布，并附上了模态分布的截图。EDA 截图。
  • 免费模型在最终 Agent 项目中仍然可行吗？：随着 Agents Course 额度耗尽，成员们讨论了使用免费模型完成最终项目的可能性。
    • 一位成员建议通过 LiteLLM 使用 Gemini models，另一位建议使用 Deepseek API keys，但强调需要保持 Space/代码公开。
  • LangGraph 基准测试：是炒作还是名副其实？：一位成员询问是否有人在基准测试中使用 LangGraph，引发了关于其适用性和有效性的讨论。

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

LLPlayer safety, Model loading issues, Gemma 3 models, AI Power Measurement, Pixtral support

  • LLPlayer：安全吗？：一位成员询问了 LLPlayer GitHub 项目 的安全性，寻求社区反馈。
    • 另一位成员建议，如果有任何疑虑，自行构建 (building it yourself) 是最好的选择。
  • Gemma 3 模型已就绪！：一位用户报告在运行 Gemma 3 模型时遇到问题，而其他多位成员确认 Gemma 3 模型在最新版本中可以开箱即用。
    • 另一位成员建议更新到 v0.2.31 之后的版本，因为该版本尚不支持。
  • 关注 Pixtral 支持：一位用户注意到 llama.cpp 添加了 Pixtral 支持，但随后意识到目前仅支持文本，尚无 Vision 功能。
    • 另一位成员指出，在 MLX 上使用 Pixtral 已经有很长时间了。
  • 剖析 AI 能力评估：成员们讨论了如何衡量 AI 能力，澄清了 perplexity 用于衡量语言能力，而其他基准测试则评估不同的能力和知识领域；一位成员分享了一个比较 AI 模型的图表链接。
    • 讨论还涉及了 Tokens，它是衡量文本量的单位，并在付费服务中用于计费。
  • Tokenizer 故障：调试词表问题：一位成员面临模型无法正确 Tokenizing 的问题，并寻找查看更详细错误日志的方法，并补充说他们在 使用 Transformers 库预训练标准的 Llama 架构时也遇到了同样的问题。
    • 另一位成员回复称没有详细错误的选项，但可以通过 lms log stream 命令查看更多信息；该用户最终通过修复未被 Tokenized 的空格解决了问题。

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

VRAM vs DRAM, GPU Upgrade vs RAM Upgrade, Used 3090 Reliability, Thermal Pad Replacement

  • DRAM 严重降低性能：当模型超过 VRAM 时，它会卸载到系统 RAM，这会严重降低性能。一位用户在配备 128GB DDR4 RAM 的 4090 上运行 120B 模型时，速度仅为 0.5 tok/s。
    • 虽然一位用户不介意为了获得优秀的答案而等待 15 分钟，但另一位用户指出，即使是大模型也可能需要反复尝试，因此速度确实很重要。
  • 小模型推荐：针对正在测试 1.7b q4_k_l 模型的用户，另一位成员推荐了 kth8/llama-server 上提供的小模型列表。
    • 该用户还询问是否应该同时充分利用 DRAM 和 GPU，另一位用户回答说，你不希望模型触及系统 RAM。
  • 3080 升级路径讨论：当被问及从拥有 10GB VRAM 和 32GB RAM 的 3080 升级时，建议是：对于更大的模型和更快的速度，更多的 VRAM 永远是标准答案。
    • 另一个建议是，将 3080 升级为二手 3090 会更好。
  • 二手 3090 的赌博：购买二手 3090 就像抽奖，但如果你有 24 小时的时间进行测试和退货，那为什么不试试呢？
    • 更换导热垫可能很贵，但大多数情况下更换 GPU 芯片上的导热膏就足够了，尽管有些显卡可能需要 4 种不同类型的导热垫，成本约为 $30。
  • 多 GPU 效率低下：一位用户报告称，在处理 LLM 提示词时，其两块 RTX 3090 中似乎只有一块处于活动状态，但他们发现其中一块 GPU 被 Afterburner 严重降频了。
    • 一位用户建议使用 nvidia-smi 查看驱动程序的统计数据。

GPU MODE ▷ #general (8 messages🔥):

Blackwell FP4, Free GPU Access, Cloud GPU Prices

  • 寻求 Blackwell FP4 格式细节：一位成员询问了 NVIDIA Blackwell 架构中 FP4 实现的技术规范，寻求有关其范围和相关方面的细节。
  • 寻求免费 GPU 访问：一位成员询问如何在不依赖学校服务器的情况下，作为学生获得免费 GPU 访问权限。
  • 云 GPU 提供高性价比选择：一位成员建议在云服务上使用消费级显卡可能相对便宜。
    • 他们还指出，一些云提供商提供免费额度，并提到一位朋友在会议上赢得了免费的 GPU 时长。

GPU MODE ▷ #triton (9 条消息🔥):

Pyright 和 Triton 问题，FP4 vs INT4，FP4 到 FP8 转换，H100 优化 kernels，RTX 5090 FP4 性能

  • Pyright 将 Triton 的 cdiv 标记为不可达 (Unreachable)：有用户报告称，每当使用 cdiv 时，Pyright 都会将 Triton 函数的剩余部分标记为不可达，这需要自定义 pyrightconfig.json 来忽略该警告。
    • 代码运行正常，但这种误报（false positive）令人烦恼，且在每台新机器或每个新项目中都需要手动配置。
  • FP4 反量化为 FP16 时比 INT4 慢：一位成员指出，理论上将 FP4 反量化为 FP16 比 INT4 反量化为 FP16 更慢，因为 INT4 可以利用高性能的位逻辑指令 (LOP3)。
    • 他证实这 绝对更慢。
  • 用户询问 FP4 到 FP8 的转换：一位用户询问如何通过缩放因子将 FP4 转换为 FP8，但注意到在 cuda_fp4.hpp 中没有看到此类转换。
    • 另一位用户质疑在 H100 上进行此操作的动机，建议使用来自 Marlin/Machete、Bitblas (tilelang) 或 GemLite 的优化 kernels（如 A16W4）。
  • 在 H100 上建议使用优化 kernels 而非 FP4：成员们建议在 H100 上使用来自 Marlin/Machete、Bitblas (tilelang) 或 GemLite 的优化 kernels（如 A16W4），而不是使用 FP4。
    • FP4 的主要使用场景是 Blackwell 上的 MXFP4，这需要特定的缩放格式和良好的 FP16 -> FP4 量化算法。
  • RTX 5090 FP4 性能基准测试即将发布：一位用户提到自己拥有 RTX 5090 并希望评估其 FP4 性能。
    • 另一位成员提供了一个 cutlass 示例链接，并对即将发布的基准测试表示期待。

GPU MODE ▷ #cuda (12 条消息🔥):

Popcorn 项目，PTX 无符号 vs 有符号整数，LLM 在 CUDA kernels 中的错误，提升 LLM 准确率的 RL 框架

  • Popcorn 项目冒头了？：一位成员询问某个项目是否与 Popcorn 项目 🍿 类似。
    • 另一位成员要求将类似的帖子发布在合适的频道中。
  • PTX 有符号 vs 无符号整数：一位正在学习 PTX 的成员询问加载 无符号 和 有符号 整数之间的功能差异，想知道这种区别是否隐式地用于后续操作。
    • 他们询问使用 ld.[location].s[n] vs ld.[location].u[n] 是否存在任何功能上的差异。
  • KernelBench 论文揭示 LLM 在 CUDA kernel 编写中的错误：一位成员询问 LLM 在生成 CUDA kernels 时最常见的“错误”是什么。
  • RL 框架调用工具以提升 LLM 准确率：一位成员正在探索一种基于 RL 的框架来提高 LLM 准确率，并想知道对于 LLM 应该调用哪些外部工具是否存在共识。
    • 他们建议使用 搜索引擎 和 代码解释器 等工具。

GPU MODE ▷ #beginner (15 条消息🔥):

PTX barrier instruction, Warp specialization producer-consumer model, libcu++ memory barriers, barrier vs bar

  • PTX **barrier.aligned 指令解析：讨论围绕 PTX 文档中关于 **barrier.aligned 指令的解释展开，特别是关于屏障名称参数在 Warp 内的所有线程中是否必须相同。
    • 有建议认为，如果一个 Lane 参与了某个资源，其他所有 Lane 也必须参与，但目前尚不清楚它们是否必须指定同一个资源。
  • **bar.arrive 和 bar.sync 用法分析：质疑了在同一个 Warp 中使用不同屏障资源的合法性，特别是关于通过分支将线程拆分为执行 **arrive 和执行 sync 的情况。
    • 引用了来自 Weft（或 此处）的一个示例代码片段，展示了在生产者-消费者模型中用于 Warp specialization 的 arrive/sync 对。
  • **libcu++ 使用 mbarrier 实现内存屏障：注意到 **libcu++ 使用 mbarrier（或旧架构上的原子操作）而非 bar/barrier 来实现 std::barrier。
    • 这是因为 barrier 仅允许到达（arriving）或等待（waiting），而不能同时进行，而实现 std::barrier 需要两者兼备。
  • 关于 **bar 与 barrier 术语的澄清：bar** 被澄清为 barrier.*.aligned 的同义词，这在 Maxwell 等仅支持对齐模式（aligned mode）的架构上尤为相关。
    • 在 barrier 之前的旧版本 ISA 会同步 Warp。

GPU MODE ▷ #irl-meetup (1 条消息):

.bexboy: ICLR?

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

mobicham: GCN 渴望更多工作负载，可能添加它是有原因的。

GPU MODE ▷ #self-promotion (1 条消息):

sohamg: LMAO 是的，我做了——没门哈哈，你参加过高中辩论吗？

GPU MODE ▷ #🍿 (4 条消息):

Kernel Bench, Compute Eval

  • Kernel Bench 与 Compute Eval 的挑战概述：一名成员强调了 Kernel Bench 和 Compute Eval 之间的区别，指出前者假设参考实现是 PyTorch，而后者使用 English。
    • 他们补充说，Kernel Bench 侧重于 ML，而 Compute Eval 更倾向于 HPC。
  • Kernel Bench 的挑战侧重于 ML：进一步阐述 Kernel Bench 和 Compute Eval 的区别，提到的一个挑战是 Kernel Bench 对 ML 的强调。
    • 这与 Compute Eval 形成对比，后者更倾向于 HPC (High-Performance Computing) 应用。

GPU MODE ▷ #submissions (42 条消息🔥):

AMD MI300 Performance, FP8 Matrix Multiplication, Leaderboard Submissions

  • MI300 排行榜霸榜：许多成员向 MI300 上的 amd-fp8-mm 排行榜提交了基准测试，展示了一系列以微秒 (µs) 和毫秒 (ms) 为单位的性能结果。
  • FP8-MM 基准测试盛况：多个提交针对 amd-fp8-mm 排行榜并取得了不同程度的成功，在 MI300 上的执行时间从 174 µs 到 127 ms 不等。
  • 刷新个人最佳成绩：几位成员在 MI300 上刷新了个人最佳成绩，提升了他们在排行榜上的排名。
    • 一位成员甚至在 amd-identity 排行榜上创下了 24.2 µs 的个人最佳成绩。
  • A100 Grayscale 提交表现出色：一位成员向 grayscale 排行榜提交了结果，在 A100 上实现了 2.50 ms 的成功运行。

GPU MODE ▷ #amd-competition (21 条消息🔥):

bot 代码中的 numpy 错误，discord-cluster-manager docker 镜像损坏，容器匹配 CI 实现，PyTorch nightlies 中更快的 CUDA 编译，AMD 竞赛形状

  • bot 代码中 Numpy 缺失：一位用户在对代码进行基准测试时遇到了 numpy 的 ModuleNotFoundError，尽管他们并没有直接调用它。
    • 一位成员建议 docker 镜像可能已损坏，并承诺进行调查。
  • Discord Cluster 修复：一位成员报告称他们修复了 docker 镜像。
    • 这个 Discord Cluster Manager 很快就会被合并，它使得 CUDA 上的 CUDA 编译仅需 0.01 秒，并有望很快也支持 AMD。
  • Runpod 设置与分析 (Profiling)：成员们讨论了设置迭代环境，并使用 Runpod 从 GPU 获取深入的 profiling 数据。
    • 一位成员能够使用模板运行 kernel，并在大约 9 秒内完成基准测试运行。
  • AMD 竞赛形状请求：一位成员指出维度 [7168 6144 576] 中的 n (576) 应该更改为能被 128 整除的数值。
    • 另一位成员澄清说，这些形状是 AMD 为竞赛要求的，包括 64。
  • AMD 针对的 DeepSeek R1 形状：一位成员建议这些形状似乎是针对 DeepSeek R1 形状的，但指出 m 值对于推理来说不是很好的参考形状。
    • 他们估计能在 MI300x 节点上容纳的最大 m 约为 m = 128，而 H200 节点的最大值为 m = 64。

Nous Research AI ▷ #announcements (1 条消息):

Minos 分类器，拒绝检测 (Refusal detection)，二进制分类器，ModernBERT-Large

  • Minos 发布，用于分类 LLM 拒绝行为：推出了一款名为 Minos 的新分类器，用于检测来自 LLM 的拒绝，可在 HuggingFace 上获取。
    • 它是一个二进制分类器，返回对话中最终响应为拒绝的可能性，对红队人员 (redteamers) 和越狱者 (jailbreakers) 可能很有用。
  • ModernBERT-Large 为 Minos 提供动力：Minos 基于 Jeremy Howard 的 AnswerAI 团队开发的 ModernBERT-Large 400M 构建，针对质量和速度进行了优化。
    • 运行该分类器的示例脚本和更多详细信息可在 HuggingFace repo 中找到。

Nous Research AI ▷ #general (99 条消息🔥🔥):

Synthetic Data Training Runs, GPQA Benchmark, Sparse Initialization Code, Mac vs NVIDIA GPUs, China Thorium Nuclear Reactor

  • 合成数据推动独特的训练运行：一名成员正在使用来自 Deephermes 24B 的合成数据进行独特的训练运行，并寻求 STEM 任务建议以验证蒸馏（distillation）质量。
    • 他们旨在创建一个具有说服力的 “hello, world” 任务来证明其技术，重点关注易于衡量且能通过程序生成提示（prompts）的任务。
  • GPQA 被建议作为蒸馏的基准测试：一名成员建议将 GPQA 作为蒸馏项目的良好基准测试，但关于在基准测试问题上进行蒸馏是否算作作弊存在讨论。
    • 有人提到 MMLU 有训练集，但 GPQA 没有，且 OpenThoughts 114k 数据集是 DeepHermes 训练数据的一部分，这可能会有所帮助。
  • L4 MoE 的稀疏初始化预告：一名成员正在开发稀疏初始化代码，旨在将 Deephermes 转换为 L4-style MoE，使其能在 8-12GB GPU + CPU 上高效运行。
    • 该计划涉及 self-logit 蒸馏，以蒸馏到稀疏化模型上，可能需要额外的参数或重复层来完全保留性能。
  • Macbook vs NVIDIA GPU 用于 AI 工作流：关于尽管 NVIDIA GPU 提供更好的性能，但 Mac 在 AI 领域依然盛行的讨论引发了对哪种笔记本电脑最适合 AI 工程和研究的疑问。
    • 支持 Mac 的论据包括其高效的 Apple Silicon、统一内存（unified memory）以及适合轻量级本地推理；而 NVIDIA GPU 因其在 AI 相关任务中的性能而受到青睐；统一内存和更大的内存上限使 Mac 在笔记本电脑领域更具优势。
  • 中国启动钍核反应堆：成员们正在讨论一段关于中国 钍核反应堆（Thorium Nuclear Reactor） 投入运行的 YouTube 视频，暗示它最终将为自动驾驶电动汽车基础设施和 AI 数据中心供电。

Nous Research AI ▷ #ask-about-llms (4 条消息):

MoE, heterogeneous devices, distributed experts

  • 研究人员寻求分布式 MoE 推理的信息：一名研究人员询问了关于在推理过程中将 Mixture of Experts (MoE) 分布在异构设备上的项目，并引用了这篇论文和这篇论文。
    • 该研究人员正在寻找新的方法和值得参考的优质资源。
  • 开发者在 Discord 中寻求机会：用户名为 teknium 的成员向 Discord 社区提供其开发者服务。
    • 他们邀请有需要的人私信（DM）他们。

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

Top-nσ Sampling Method, LLMs Decoding Strategies

  • Top-nσ 采样方法高效过滤 Token：一名成员分享了一个关于 Top-nσ 的 Arxiv 链接，这是一种新型采样方法，通过利用统计阈值直接对 pre-softmax logits 进行操作，从而高效过滤 token。
    • 与现有方法不同，top-nσ 无论温度缩放如何都能保持稳定的采样空间，性能优于现有的采样方法并超过了 greedy decoding。
  • LLM 解码策略：上述分享的论文挑战了 LLM 在推理任务中通常采用 greedy decoding 或低温采样的惯例，这反映了多样性与准确性之间公认的权衡。
    • 该成员建议这篇论文可能对另一名成员有用，后者可能专门研究该领域。

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

Top-nσ Sampling Method, LLM Decoding Strategies, Gaussian Noise in Logits

  • Top-nσ 采样方法亮相：一篇新的 论文 介绍了 top-nσ，这是一种新颖的采样方法，它根据应用于 pre-softmax logits 的统计阈值来过滤 token，从而区分高斯分布的噪声区域和信息区域。
    • 该方法在不同温度缩放（temperature scaling）下保持稳定的采样空间，在专注于推理的数据集上表现优于现有方法和贪婪解码（greedy decoding）。
  • LLM 应对解码策略：top-nσ 论文挑战了大型语言模型（LLM）解码中多样性与准确性之间的传统权衡，这种权衡通常通过贪婪解码或低温度采样来处理。
    • 与 top-p 等方法不同，top-nσ 避免了在较高温度下无意中包含更多噪声 token。
  • Logits 中识别出高斯噪声：top-nσ 方法基于这样一种见解：logits 自然地分为 高斯分布的噪声区域 和独特的信息区域。
    • 正如 论文的理论分析 中详述的那样，这种分离实现了高效的 token 过滤，而无需复杂的概率操作。

Eleuther ▷ #general (12 messages🔥):

Common Crawl Foundation Host Index, Moderation Norms Grievances, ml-math.net Updates, Improved ResNet Initialization for Transformers

  • Common Crawl Foundation 寻求测试者：Common Crawl Foundation 正在寻找人员来测试名为 “host index” 的新数据产品，这是其每次网络爬取中每个主机信息的汇总。
  • Discord 用户表达对审核的不满：一名用户对其他社区的审核规范表示不满，但被一名管理员告知 这里不是表达对审核规范不满的合适场所。
    • 另一名用户为他们辩护，称 我觉得这没关系，以前有人在这里这样做过并取得了不错的效果，而且他们似乎已经为恢复内容做出了诚意的努力，只是没有直接联系方式进行私信。
  • ML 背后的数学没有改变：一名用户询问是否有类似于 ml-math.net 的更新资源，其中包含更多常用概念和开创性论文的示例。
    • 另一名用户回答说 这个领域背后的数学并没有发生翻天覆地的变化。它仍然是同样的东西，只是包装方式不同。
  • ResNet 和 Transformer 的初始化逻辑：一名成员一直在研究改进的 ResNet 初始化，并询问同样的逻辑是否适用于 Transformer 或通用的 Attention 机制。
    • 他们补充说，他们一直在 跟进较新的 ResNet 标准，而且大部分整体逻辑都是合理的。

Eleuther ▷ #research (42 messages🔥):

AI-Generated Papers, ACL Submissions, Reviewer Overload, Mitigating AI Use

  • AI 推动 AI 生成论文的兴起：成员们讨论了只需 $15-20 的 API tokens，就可以使用 AI-Scientist-v2 等工具生成一篇完整的研究论文，这引发了对 arXiv 上 AI 生成论文 涌入的担忧。
  • ACL 投稿量激增：一名成员指出，今年的 ACL 投稿量 比去年增加了一倍多，达到 8500 多篇，这引发了关于其中有多少是 AI 生成的疑问。
    • 另一名成员担心 Emily Bender 的演讲适得其反，导致了更多的 AI 垃圾信息。
  • 审稿人抵制对 AI 论文的监管：成员们辩论了如何证明一篇论文是否由 AI 生成以及应该采取何种惩罚措施，建议禁止相关作者参加主要会议。
    • 一名成员表示，如果必须做出禁止个人的决定，他们将 拒绝审稿，而另一名成员则认为 AI 不应该撰写论文的 核心实质内容。
  • Infinigrams 揭露 AI 论文模仿：一名成员建议通过使用仅包含 arXiv, GitHub, Wikipedia 和 StackExchange 的 infinigram 来检测 AI 生成的论文，认为 AI 模型总是会使用这些来源中的完整短语。
    • 在相关讨论中，一名成员在观察到语言建模中 循环层（looped layers）不如循环块（looped blocks） 时，对语言模型的质量发表了评论。

Eleuther ▷ #interpretability-general (7 messages):

Transformer Circuits Framework, Subspaces and Residual Stream Bandwidth, Mechanistic Interpretability

  • Transformer Circuits Framework 影响思考：一位成员借鉴了 Transformer Circuits Framework 中的概念，特别是关于 subspaces 和 residual stream bandwidth 的想法。
    • 他们强调模型组件并不受限于尊重彼此的 subspaces，这导致了潜在的低效，或者可以通过更好地“保护” subspaces 来实现改进。
  • 约束 Attention Head Subspaces 的实验：一位成员考虑将 attention heads 约束在共享的 512 维 subspace 中的 128 维 subspaces 上运行，以强制实现更好的组织，尽管这可能会牺牲表达能力 (expressivity)。
    • 他们推测，尽管在表达能力上有所权衡，但读写相同 subspaces 的 heads 可能会进一步改善组织结构。
  • 初学者寻求 Interpretability 指导：一位软件工程师对 interpretability 表现出兴趣，并询问了理解前沿研究的路径。

MCP (Glama) ▷ #general (36 messages🔥):

MCP server issues with image/audio, Claude artifacts and image display, Auth for remote MCPs, git repo to MCP server

  • MCP Server 在处理图像/音频方面遇到困难：一位成员报告称 Claude Desktop 处理音频和图像的效果不佳，特别是对于大于 1MB 的图像，且使用包含多种类型（文本、音频、图像）的内容会导致 ‘unsupported content type’ 错误。
    • 他们希望 LLM 能够拥有对大型数据块 (data blobs) 的 引用 (references)，而不是直接发送数据，并询问 MCP resources 是否可以用于此目的。
  • Pro 方案能解决大型 MCP 输出问题吗？：一位在生成带有大型数据集的交互式日程表时遇到问题的用户发现，升级到 Claude Desktop 的 Pro 方案 解决了该问题。
    • 这表明免费版本在处理数据的大小或复杂性方面存在限制。
  • Cloudflare 为远程 MCP 身份验证采用 OAuth 方案：针对远程 MCP server 的用户身份验证问题引发了关注，一位成员指出 Cloudflare 正在推动对 MCP spec 的修改，并使用 OAuth 来解决此问题。
    • 他们链接了一篇 Cloudflare 博客文章，讨论通过 Dynamic Client Registration 来解决身份验证挑战中“无论客户端为何”的部分。
  • 自动将你的 git 仓库转换为 MCP server：一位成员分享了 git-mcp，这是一个将任何 git repo 转换为 MCP server 的工具，可以查询 docs、examples 等。
    • 这使得用户可以在 MCP 工作流中轻松引用来自仓库的代码和文档。
  • Sacred 的托管聊天应用发布，支持 MCP server 和工具：一个托管聊天应用 chat.pipedream.com 已发布，允许用户与 2500+ 个 MCP server 和 10k+ 个工具 进行对话。
    • 创建者正积极寻求关于该平台的反馈。

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

MCP 浏览器扩展、Slack MCP Server 更新、Graphlit MCP Server 的 OpenAI 图像生成、面向 VanMoof 骑手的 MCP Server、集成 DevDb 的 MCP Server

  • Siloed 发布 MCP 浏览器扩展: Siloed 推出了一款针对 MCP 的浏览器扩展，允许用户从任何支持资源的 MCP server 直接将资源和提示词（prompts）拖放到浏览器中。
    • 该扩展允许构建包含动态文本和资源附件的提示词库，并与 Siloed 的 MCP Server 集成，以便在 Claude Desktop 等客户端中访问。
  • Slack MCP Server 迎来重大更新: Slack MCP Server 进行了重大更新，包括通过 npx 改进了采用方式，并将历史记录请求从消息计数改为基于日期范围。
    • 这些更新增强了 server 分析指定时间段（如 1 天、1 个月或 2 周）内消息的能力。
  • Graphlit MCP Server 现已支持 OpenAI 图像生成: 正如 tweet 中宣布的那样，Graphlit MCP server 现在包含 OpenAI 图像生成功能。
    • 鼓励用户尝试这一新功能，增强 server 的多媒体功能。
  • VanMoof 骑手获得专用 MCP Server: 一款专门为 VanMoof 骑手开发的新 MCP server 已发布，提供量身定制的集成和功能。
    • 该 server 旨在为 VanMoof 电动自行车用户提供增强的控制和自定义选项。
  • 集成 DevDb 的 MCP Server 已发布: 一款与 DevDb 集成的 MCP server 已经发布，支持 MySQL、Postgres、SQLite 和 MSSQL 数据库。

LlamaIndex ▷ #blog (3 条消息):

LlamaIndex.TS 中的 MCP Server、多模态、基于 DeepSeek 的 Perplexity 克隆版

  • MCP Server 现已集成到 LlamaIndex.TS: 数以千计的 MCP server 现在可以通过单行 mcp() 调用在 LlamaIndex.TS 中使用，简化了与任何 MCP server 的连接，示例可见此处。
    • 正如链接资源所示，这种集成有助于在 LlamaIndex.TS 项目中更轻松地访问和利用 MCP server。
  • LlamaIndex 拥抱多模态: LlamaIndex 强调了其对多模态模型和 embeddings 的支持，并强调多模态是 AI 领域近期的一项重大进展，正如 LlamaIndex 联合创始人 Jerry Liu 在去年的 @aiDotEngineer 世界博览会上（由 @MongoDB 赞助）所讨论的那样。
    • 有关其最新多模态支持的更多详细信息可以在此处找到。
  • 基于 DeepSeek 构建的快速 Perplexity 克隆版: 由 Karan Vaidya 实现的基于 DeepSeek 的 Perplexity 克隆版仅需不到 100 行代码，展示了使用现代工具创建类似应用的便捷性。
    • 实现细节见视频和代码，分别位于此处和此处。

LlamaIndex ▷ #general (30 条消息🔥):

HuggingFaceEmbedding 和 IngestionPipeline，MultiModalVectorStoreIndex 默认 Embeddings，NotionReader 定制，Gemini 2.5 flash 和 Thinking 功能，GuardRails 与 Pydantic 兼容性

  • Pipeline Embedding 特性出现：一位用户发现，在摄取（ingestion）之前通过 Settings 定义 embed_model 时，除非在 IngestionPipeline 内部也定义了嵌入模型，否则 pipeline 不会进行 embedding。
    • 索引在检索期间的查询需要嵌入模型，因此在 Settings 和 pipeline 中同时定义它可以确保其正常运行。
  • MultiModal 默认值解析：一位用户询问了 MultiModalVectorStoreIndex 中使用的 默认多模态 embeddings。
    • 一位成员回答说，默认的图像嵌入模型通常是 OpenCLIP。
  • NotionReader 对新元数据的巧妙需求：一位用户想知道是否应该 fork NotionReader 以添加更多描述性元数据（如 filename 和 file type）来改进过滤，因为该 reader 默认仅添加 Notion file ID。
    • 用户正试图提高搜索准确性，因为数据库中的文件具有相似的文本内容。
  • Gemini 2.5 flash 用户发现 Thinking 功能缺陷：一位用户试图 禁用 Google Gemini 2.5 flash 模型中的 “thinking” 功能，发现文档说明不清晰。
    • 一位成员指出，在 GenerateContentConfig 中将 thinking_budget 设置为零即可禁用此功能。
  • GuardRails 故障源于 Langchain 的遗留问题：一位用户在使用 GuardRails 与 LlamaIndex 时遇到了 Pydantic v2 兼容性问题，怀疑与 LlamaIndex 的 Pydantic 版本不匹配。
    • 一位成员指出 LlamaIndex 使用的是 Pydantic v2，而错误可能源于 Langchain（GuardRails 的依赖项）仍在使用 Pydantic v1，并指向了一个 相关的 pull request。

LlamaIndex ▷ #ai-discussion (4 条消息):

指令微调 LLMs，TRL 使用，Small Language Model

  • 使用 TRL 而非 LlamaIndex 进行微调：一位成员建议使用 TRL 而不是 LlamaIndex 工具来对开源 LLM 进行指令微调。
    • 他们补充说，可以使用任何现有的 LLM 来创建数据集并进行蒸馏训练。
  • 本地和 T4 环境的内存限制：一位成员警告说，在本地或 T4 GPU 上进行训练会受到严重的内存限制。
    • 他们补充说，这可能只能以较小的 batch size 训练非常小的 LLM。
  • 从零开始构建 SLM：一位成员表示有兴趣按照 rasbt 的 LLMs from Scratch 书籍 从零开始构建 Small Language Model (SLM)。
    • 他们表示这是一个 有趣的交流学习体验。

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

Copilot Agents，Sora 中的图像生成器偏见，AI 与随机性，AI 应用生成中的协作，Dario Amodei 的 Anthropic 文章

  • 微软关注 Copilot Agents：Satya Nadella 在一条推文中预告了 Copilot Agents，引发了讨论 - 链接。
  • Sora 的隐藏偏见与审美洗白：一位用户正在实验 Sora 中的 图像生成器偏见，揭示了整个平台一致的 从左到右偏见，如 这张图片 所示。
    • 他们还在撰写关于 审美洗白（aesthetic laundering） 的文章，通过布置场景来利用图像生成器的偏见，导致生成的图像可能 违反服务条款 (TOS)。
  • AI 的随机性揭示偏好：一位程序员探索了 AI 的随机性，注意到当提示随机选项时，AI 往往最常选择 Knowledge 和 Liberty。
    • 该程序员假设这揭示了 内在偏好 而非真正的随机性，从而影响了编程问题的结果。
  • Dario 的新文章：Dario Amodei 发布了一篇新文章 - 链接。

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

RAG 示例，今晚聚会，库请求

  • 新的 RAG 示例令 Mac 用户兴奋：成员们对新的 RAG 示例（YouTube 链接）表示兴奋，特别是关于它在拥有 UMA 的高性能 Mac 上的潜在应用。
    • 一位成员询问了关于在 Mac CPU/GPU 上运行 RAG 的类似教程。
  • Mojo MAX 聚会：成员们提到参加今晚的聚会可能有机会与 MAX 和 Mojo 合影。
    • 这引发了一位成员因地理位置隔绝而感叹的讨论，表示希望我能再次住在湾区！并请求在南加州 (SoCal) 举办聚会的计划。
  • 社区库请求：一位成员提出愿意花时间在 Mojo 社区创建一个急需的库或工具。
    • 该成员询问 Mojo 社区是否有任何期望的库或任何东西，以便他可以投入时间去完成。

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

NVIDIA CUDA-Python 发布 vs Mojo，CUDA 的替代方案，Mojo 库愿望清单，constrained 的 @always_inline 版本

  • CUDA-Python 发布引发猜测：成员们讨论了 新的 NVIDIA CUDA-Python 发布 是否是为了应对 Mojo。
    • 一位成员表示，这是因为大多数 AI 开发者真的不想学习 CUDA。
  • CUDA-Python 不会取代 C++：成员们预测，由于 Python 的缺点，CUDA-Python 在原型设计之外不会取代 C++。
    • 其他人对该库表示欢迎，但对其取代 C++ 持怀疑态度。
  • 社区表达对 Mojo 库的渴望：一位拥有极大量空闲时间的成员询问 Mojo 社区是否有期望的库。
    • 该成员提议花时间来构建它。
  • 对 constrained 的 @always_inline("builtin") 版本需求出现：一位成员询问是否有与 @always_inline("builtin") 兼容的 constrained 版本。
    • 另一位成员指向了一个关于 requires 子句的提案，这可能正是你想要的。
  • Mojo 特性愿望清单讨论：随着各项功能开始变得相当完善/经过测试，一位成员提议为 Mojo 社区整理一份特性愿望清单。
    • 讨论中包含了一个指向 Kelvin 的链接。

tinygrad (George Hotz) ▷ #general (13 messages🔥):

Tensor 释放问题，GlobalCounters 内存追踪，tinygrad 可视化，OS 内存回收

  • Tensor 随 GlobalCounters 追踪消失！：一位用户试图确保从 Tinygrad 内存中完全移除 Tensor，注意到 del 并不足够，并尝试了 del buffers[x.lazydata] 和 del x，以及尝试对每个 buffer 调用 deallocate()。
    • 另一位成员建议使用 tinygrad.helpers.GlobalCounters.mem_used 从 Tinygrad 的视角追踪内存，因为它会在 buffer 分配/释放期间进行调整。
  • 可复现的 Tensor 泄漏？：一位用户提供了一个可复现脚本，用于演示 Tinygrad 中潜在的 Tensor 释放问题。
  • OS 吞噬内存？：成员们讨论了 OS 可能不会立即回收已释放的内存，这可以解释为什么在删除 Tensor 后内存占用没有立即下降。
    • 有建议认为 RandN 较慢且开销更大。
  • viz 太棒了！：一位用户评价道：viz 太棒了。

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

cookiecrumbs3808: 正是我需要的。谢谢！

LLM Agents (Berkeley MOOC) ▷ #mooc-questions (6 messages):

AgentX resources, Lambda services, AI Pair Programming Tools

  • 关于 AgentX 资源和 Lambda 服务的困惑：一位参与者对 AgentX 资源和提供折扣的 Lambda 服务表示困惑，认为这与 AgentX 竞赛有关。
    • 组织者澄清说，Lambda 的优惠与竞赛无关，因为团队信息尚未与赞助商共享，这很可能是一个无关的 Lambda 促销活动。
  • 关于 Lambda 提供的 AgentX 资源的说明：组织者详细说明，Lambda 将为 AgentX 竞赛中选定的 50 支队伍提供每位团队成员 100 美元的 serverless API 额度以及 400 美元的 GPU 额度。
    • 各团队预计在大约一周内收到关于 AgentX 资源的回复。
  • Tableau EM 提议在 AI 结对编程方面做出贡献：Tableau (Salesforce) 的一名工程经理 (EM) 参与构建了一个本地 AI 结对编程工具，并提议为课程做出贡献。
    • 该 EM 表示有兴趣分享关于 AI 结对编程助手如何工作、安全考量以及如何最大化利用这些工具的见解，并拥有使用 Cursor 和 GitHub Copilot 的经验。

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

dbreunig: https://www.dbreunig.com/2025/04/18/the-wisdom-of-artificial-crowds.html

DSPy ▷ #general (4 messages):

Event-driven development, DSPy and MCP integration, Limitations of DSPy

  • 拥抱事件驱动开发：一位成员对事件驱动开发 (Event-driven development) 表达了热情，表示他们目前正在几个项目中实施该模式。
    • 该成员表示：“没有什么比得上事件驱动开发！目前正在为几件事做类似的推进。”
  • 解码 DSPy 的黑盒训练：一位成员指出，DSPy 中的训练过程对普通用户来说被设计成了一个“黑盒”，建议阅读论文和源代码以进行深入理解。
    • 他们提到：“训练似乎是一个黑盒，因为普通用户不需要了解它。如果你想知道它是如何工作的，请阅读论文和源代码，如果你有 AI 背景，这其实并不复杂。”
  • 澄清 DSPy 与 MCP 的集成：一位成员澄清说 MCP 不是一个编排框架，可以通过将工作流/Agent 实现为 MCP 的服务端工具来集成 DSPy。
    • 此外，他们建议：“如果你想将 DSPy 与 MCP 结合使用……DSPy 允许你将工作流/Agent 实现为 MCP 的工具，所以实际上是服务端函数而非客户端函数。”
  • DSPy 的可扩展性：一位成员认为 DSPy 目前的局限性在于针对可扩展性和鲁棒性的优化，而不是缺乏 MCP 支持。
    • 他们指出：“关于 DSPy 目前的局限性，实际上与缺乏 MCP 支持无关，更多是关于可扩展性和鲁棒性的优化。如果你能用 DSPy 创建一个 FastAPI 端点，那么实现一个 MCP 服务器就是轻而易举的事。”

Cohere ▷ #「💬」general (3 messages):

HuggingFace Infrastructure, Cohere AI Scholars Program 2026

  • 对 HuggingFace 基础设施的疑问：一位成员询问某个特定的基础设施问题是否应该直接咨询 Hugging Face，因为连接的是他们的基础设施。
    • 该问题暗示用户在使用名为 Kati Patang 的其他服务时，遇到了与 Hugging Face 相关的连接问题。
  • Cohere 2026 年的学者计划？：一位成员询问 Cohere 是否计划在 2026 年举办 AI 学者计划 (AI Scholars Program)。
    • 在现有消息中没有给出回复，但这表明社区对 Cohere 未来教育计划的兴趣。

Cohere ▷ #「💡」projects (1 messages):

Hugging Face Inference API, Flask integration, Model deployment

  • Inference API 连接到 Flask 网站：一位用户询问如何将托管在 Hugging Face 付费 Inference API 上的模型连接到使用 Flask 构建的个人网站。
    • 建议包括使用 API keys 进行身份验证，并从 Flask 应用程序向 Hugging Face API 端点发送 POST requests 以获取模型预测结果。
  • Flask <-> HuggingFace：两个 API 的故事：主要方法是利用 Hugging Face Inference API，这需要从你的 Flask 后端发送格式正确的请求。
    • 具体而言，你需要在 Flask 应用中设置 API 端点来接收数据，使用你的 API key 将其转发给 Hugging Face API，然后将响应传回用户的浏览器，确保无缝集成。

Cohere ▷ #「🤝」introductions (1 messages):

Introductions, Community Welcome

  • Cohere 欢迎新社区成员：一条置顶消息欢迎新成员加入 Cohere 的社区 Discord 服务器。
    • 鼓励新用户通过提供其公司/行业/大学、当前项目、最喜欢的技术/工具以及对社区的期望来进行自我介绍。
  • 自我介绍指南：提供了一个模板要求新成员分享背景信息。
    • 该模板询问 公司/行业/大学、你正在研究的内容、你使用的最喜欢的技术/工具以及你希望从这个社区获得什么。

Torchtune ▷ #dev (4 messages):

Pytorch Utils, OOM Error, DP Replicates

  • Torchtune 与 Pytorch Utils 保持一致：Torchtune 目前将继续与 Pytorch utils 保持一致。
    • 团队将重新评估如果代码变得难以管理，是否将其放入特定的 dataclass 或其他结构中。
  • 基准测试期间出现 OOM 错误：在 main 分支进行基准测试时，一位成员在单节点未出现 OOM 的情况下，通过 dp replicates 使用多节点时遇到了 OOM 错误。
    • 降级到 LLaMA 3.1 8B 有助于复现高内存占用问题，使用 dp_shards=16 和 dp_replicates=1 如预期降低了内存使用量（但显然速度更慢）。
  • 使用 DP Replicates 时内存占用增加：团队正在寻求关于为什么使用 dp replicates 需要更多内存的见解，因为原因目前尚不明显。

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

GPT4All Web Search Plugin, Mixtral-8x7B-Instruct-v0.1 on RTX 3090, 3Simplex/Meta-Llama-3.1-8B-Instruct-gguf

  • GPT4All 考虑网页搜索插件：一位用户建议为 GPT4All 添加网页搜索插件，以通过实时信息增强上下文窗口。
    • 该用户引用了成员之间过去关于网页搜索能力的讨论，询问潜在的实施计划。
  • Mixtral-8x7B-Instruct-v0.1 在 RTX 3090 上表现出色：一位用户报告在 RTX 3090 上成功运行了 Mixtral-8x7B-Instruct-v0.1 模型，并指出其在 q4_0 量化下拥有 46B 参数，性能令人印象深刻。
    • 另一位用户表示有兴趣尝试该模型，并询问了 VRAM 要求（24 GB）。
  • GPT4All 复现 Meta-Llama-3.1-8B-Instruct-gguf：一位用户声称在 GPT4All 中使用提议的系统提示词复现了 3Simplex/Meta-Llama-3.1-8B-Instruct-gguf 的输出。
    • 该用户没有分享关于特定提示词或比较方法的更多细节，而这些细节本可以增强该观察结果的影响力。

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

Windsurf subreddit, Community engagement, Project sharing

  • Windsurfers 发布官方 Subreddit：社区团队为社区成员开设了一个新的官方 Subreddit，名为 r/Windsurf!。
    • 该 Subreddit 旨在让成员能够发布你的项目，向其他开发者学习，并与社区互动！
  • 分享你的 Surf！：鼓励成员在新的 Subreddit 上发布项目并互相学习。

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

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

← 返回首页