AI News

Gemini 2.5 Pro (06-05) 在 AI 工程师世界博览会（AI Engineer World's Fair）上发布。

· MjAyNS0w

在 AIE 的第二天，谷歌的 Gemini 2.5 Pro 以 1470 分和 +24 Elo 的增长重新夺回了 LMArena 排行榜的榜首，展现了在编程、推理和数学方面的提升。Qwen3 发布了最先进的嵌入（embedding）和重排序（reranking）模型，其中 Qwen3-Embedding-8B 在 MTEB 多语言排行榜上登顶。OpenThinker3-7B 成为基于 OpenThoughts3-1.2M 数据集训练的最强开源推理模型，性能优于此前模型 33%。LightOn 推出了 FastPlaid，为后期交互（late-interaction）模型带来了高达 554% 的加速。Morph Labs 聘请了 Christian Szegedy 担任首席科学家，负责领导可验证超级智能（Verified Superintelligence）的开发。AI 工程师世界博览会（AI Engineer World’s Fair） 举行了 Greg Brockman 与 英伟达 CEO 黄仁勋（Jensen Huang） 的炉边对话，重点讨论了基础研究的回归和工程最佳实践。

#benchmarking #reasoning #coding #math #embedding-models #late-interaction #dataset-release #model-performance #model-architecture #ai-conferences gemini-2.5-pro qwen3-embedding-8b openthinker3-7b google qwen lighton morph-labs openai nvidia

AIE is all you need.

2025年6月5日至6月6日的 AI 新闻。我们为您检查了 9 个 subreddit、449 个 Twitter 账号和 29 个 Discord 社区（218 个频道和 7848 条消息）。预计节省阅读时间（以 200wpm 计算）：636 分钟。我们的新网站现已上线，包含完整的元数据搜索和美观的 vibe coded 风格展示。请访问 https://news.smol.ai/ 查看完整的新闻细分，并在 @smol_ai 上向我们提供反馈！

在非 AI 事件繁忙的一天中，我们仍然成功挖掘出了 AI 新闻。在 AIE 的第二天，Logan Kilpatrick 深谙如何取悦观众：发布了一款新的 Gemini：

下面的 Twitter 摘要做得相当出色，您可以在此处观看完整直播，其中包括 Solomon Hykes 广受好评的现场演示，以及 Christian Szegedy 达成的疯狂交易。

AI Twitter Recap

新 AI 模型与基准测试结果

AI Engineer World’s Fair

新工具、库与功能

行业与平台动态

  • 平台风险与 “Sherlocking”：初创公司在大型 AI 平台之上构建业务所面临的风险是一个主要话题。讨论由 Granola 被 OpenAI Sherlocked 的消息以及 Anthropic 完全切断了初创公司 Windsurf 对其最新模型访问权限的报告引发。这引发了对 AI 平台动态与传统 OS 平台差异的分析，一位用户指出 AI 公司几乎没有动力去避免与开发者竞争。
  • 数据隐私与监管：一项法院命令现在要求 OpenAI 必须保留所有 ChatGPT 日志，包括“临时聊天”和原本会被删除的 API 请求。为了回应《纽约时报》的数据需求，OpenAI 发布了一篇文章，概述了他们如何保护用户隐私。
  • AI “战争”：OpenAI、Google 和 Anthropic 之间的竞争动态是一个反复出现的主题。一位用户指出了 OpenAI 的用户群与 Google 的算力优势 (compute advantage) 之间的对比，暗示 Google 不能只是“重新发明 Anthropic 发现的训练秘诀”。在 Google 的 Veo 3 视频模型发布后，另一位用户预计，在 OpenAI 的 SORA 之后 Google 最初的恐慌现在已经反转。
  • 智能成本正在下降：多位用户评论说 LLM 变得“便宜得离谱”。一位为处理保险文件的公司提供咨询的用户表示，将整份保单输入 Gemini 仅需约 $0.01。另一位用户计算出，一个假设通过存储成本让 OpenAI 破产的计划将会失败，因为云存储“简直是微不足道的零钱”。

技术概念与研究

  • Mixture-of-Transformers (MoT) 与异构训练：一个详细的推文串解释了 Mixture-of-Transformers (MoT)，这是一种针对不同模态使用完全解耦的 Transformer 的架构。这种设计允许进行特定模态的训练，同时保持自回归 LLM。该推文将其与最近的模型如 BAGEL 和 Mogao 联系起来，这些模型表明按功能（理解 vs 生成）拆分 Transformer 参数是有效的。
  • 元学习 (Meta-Learning, Learning to Learn)：来自 The Turing Post 的一篇文章将 meta-learning 定义为模型通过训练以从少量示例中快速适应新任务的过程。该过程涉及一个适应特定任务的 base-learner 和一个更新 base-learner 策略以提高其通用问题解决能力的 meta-learner。
  • 推理模型 (Reasoning Models)：讨论了创建鲁棒推理模型的挑战。来自 Meta 及其同事的一篇论文提出了 self-challenging LLM agents，作为通往自我改进 AI 的路径。另一篇论文发现，对于单个问题，监督微调 (SFT) 可以实现与 强化学习 (RL) 类似的收益，这表明 RL 的大部分收益可能仅仅来自于再次看到问题实例。
  • 人机关系与 Evals：OpenAI 的 Joanne Jang 发布了一篇关于人机关系的长文，指出他们的目标是构建工具而非生物，人们对 AI 的感受是一个日益重要的话题。与此相关，另一篇论文发现了一种“恐怖谷效应 (uncanny valley effect)”，即用户不喜欢过于像人的 LLM。
  • 机器人技术 (Robotics)：第一个名为 BB-ACT 的机器人动作模型 (VLA)，一个 3.1B 参数模型，已通过 API 公开发布。在其他新闻中，Amazon 正在测试人形送货机器人，Hugging Face 发布了一个机器人 AI 模型，其效率高到可以在 MacBook 上运行。

Humor & Memes

AI Reddit Recap

/r/LocalLlama Recap

1. 8B 参数模型正面对决：DeepSeek R1-0528-Qwen3-8B 与 Qwen3 8B

  • DeepSeek 新推出的 R1-0528-Qwen3-8B 是迄今为止最智能的 8B 参数模型，但领先优势并不明显：阿里巴巴自家的 Qwen3 8B 仅落后一分 (Score: 104, Comments: 30)：据报道，DeepSeek 新的 R1-0528-Qwen3-8B 8B 参数模型在 8B 模型中获得了最高分，在 Artificial Analysis 汇总的“Intelligence Index”基准测试中仅比阿里巴巴的 Qwen3 8B 高出一分。然而，主要的工程批评在于这些基准测试结果可能不可靠，原因是潜在的基准测试饱和与过拟合（overfitting）：模型通常是在用于测试它们的基准测试集上进行训练的，从而导致分数虚高（例如，基础版 Qwen 2.5 32B non-Instruct 在被提示时会生成类似基准测试的问答）。该帖子提供了数学推理和代码（LiveCodeBench）的对比分数，显示顶尖的 8B 和 14B 模型之间的差距相对较窄，并质疑了其实际应用价值，因为行业在生产工具中更倾向于使用 Claude 3.7/4 等模型。顶级评论者强调，Artificial Analysis 的排名过度依赖过时、过度使用的基准测试，这有利于基准测试过拟合，而非反映真正的进步。尽管如此，一些用户注意到了实际差异，例如 DeepSeek R1 8B 在编程和数学方面表现出色，而 Qwen 8B 则提供更优越的多语言性能。由于现实世界的一致性不佳以及可能的数据污染，人们对基于基准测试的排行榜普遍持怀疑态度。
    • 几位评论者批评了 ArtificialAnalysis 用于评估 DeepSeek R1-0528-Qwen3-8B 和 Qwen3 8B 等模型的基准测试，指出这些测试过度依赖旧的且过度暴露的数据集（如 MMLU, SciCode），导致的是基准测试过拟合而非真正的能力。有人引用说，当让 non-instruct 模型面对随机提示时，它们经常会背诵基准测试风格的问题和答案，这表明 模型是为了优化基准测试而训练的，而不是为了通用能力。
    • 数学和编程推理得分 的细分显示，DeepSeek R1-0528 以 94 分领先，Qwen3 14B (reasoning) 为 86 分，Qwen3 8B (reasoning) 为 83 分，而 Claude 3.7 Sonnet 为 72 分。但这些结果的表面效度受到质疑——一些人认为 Qwen3 8B 在这些领域能以巨大优势超越更大或更成熟的模型（如 Claude Sonnet 3.7）是不合常理的，从而对评估方法和结果的可信度提出了质疑。
    • 用户体验报告显示，在私有测试中，Destill R1 8B 在编程、数学和推理方面优于 Qwen 8B，而 Qwen 8B 在写作和多语言任务中感觉更自然。这凸显了实际效用可能与报告的基准排名有所偏差，特别是对于非英语用例和自然语言生成的质量而言。
  • 新 Embedding 模型 “Qwen3-Embedding-0.6B-GGUF” 刚刚发布。 (评分: 403, 评论: 88): 该帖子宣布发布了 Qwen3-Embedding-0.6B-GGUF 模型，这是来自 Qwen 团队的一款专注于 Embedding 的语言模型，同时还强调了相关 Embedding 和 Reranking 模型的同步发布 (Hugging Face Qwen3 Embedding Collection)。技术讨论集中在专用 Embedding 模型与标准语言模型之间的区别：虽然标准模型可以将文本向量作为其 Token 表示的一部分输出，但专用 Embedding 模型是专门针对语义相似度等文本表示任务进行优化的，通常通过对比学习目标（contrastive objectives）或大规模检索基准进行训练，而普通的生成式模型通常不会这样做。此外，关于跨架构和跨版本的 Embedding 的互操作性和通用性也存在争论，人们担心由于模型家族、训练数据和目标的差异，Embedding 可能无法实现通用兼容。 一项技术辩论探讨了通用 LLM 是否可以在实际应用中（例如通过 AnythingLLM 配合 Ollama）充当 Embedding 模型，因为它们通常看起来可以运行，但可能无法达到与专用 Embedding 模型相同的质量或目的。另一点质疑 Embedding 的通用性——即由不同家族、目标或模型版本生成的向量是否可以互换或“通用”，并对真正的跨模型兼容性持怀疑态度。
    • 针对 Embedding 模型与通用语言模型提出了一个技术细节问题：虽然通用模型会产生中间隐藏表示（向量），但 Embedding 模型是专门训练用于生成适合相似度搜索、语义检索或排序任务的向量。评论者还质疑了跨模型的 Embedding 兼容性，强调 Embedding 向量空间通常不是通用的；来自不同训练模型（不同架构、训练数据或目标）的向量本质上并不兼容，除非通过后续处理进行标准化或对齐，否则互操作性极具挑战。
    • Qwen 团队发布了一系列专用的 Embedding 和 Reranking 模型，包括 safetensors 和 GGUF 等不同模型格式，这扩展了部署选项和硬件兼容性。文中提供了 Qwen 的 HuggingFace Embedding 模型集合 和 Reranker 模型集合 的直接链接，为基准测试和技术评估提供了集中访问。
    • 技术界对 Reranker 模型表现出浓厚兴趣，特别是对于多语言语义文本相似度（STS）任务。评论者指出，现有的 Reranker 模型在稳健的多语言 STS 方面存在空白，这表明 Qwen 新发布的 Reranker 可能会提供更好的性能或填补尚未满足的技术需求。

2. 近期发布的开源 LLM 和 Embedding 模型 (OpenThinker3, Qwen3-Embedding, BAIDU 入驻 HuggingFace)

  • 百度入驻 HuggingFace (Score: 184, Comments: 14)：百度已加入 Hugging Face，这可能预示着百度 Ernie 模型将有更多的开源访问权限，该模型此前在中国 AI 生态系统中备受关注。社区询问的焦点在于百度是否会发布 Ernie 模型的开源版本，以及“Ernie thinking model”是否有可用的 Benchmark。 评论者考虑到百度的声誉，对其贡献的质量和开放程度表示怀疑，同时对 Ernie 模型与其他语言模型相比的指标和性能表现出技术兴趣。
    • 百度发布开源 ERNIE 模型的动向引发了好奇，以及这些模型在性能上与现有开源语言模型的对比情况。
    • 针对百度“Ernie thinking model”的 Benchmark 可用性提出了技术问题，表明社区对客观评估以及与 BERT 等成熟模型进行对比的兴趣。
    • 有观点怀疑百度可能在公开版本中保留了其最先进的技术，暗示 HuggingFace 上的模型可能仅代表其前沿能力的一个子集。
  • OpenThinker3 发布 (Score: 112, Comments: 8)：开源 LLM OpenThinker3-7B 已在 Hugging Face 上发布，提供标准格式和 GGUF 格式（model card，GGUF 链接），并计划推出更大的 OpenThinker3-32B 模型。初步的数据集检查显示其包含技术内容和轻量内容的混合。社区讨论指出，Deepseek-0528-Qwen3-8B 在 Benchmark 上的表现显著优于 OpenThinker3-7B，从而引发了对其相对能力的质疑。 技术辩论集中在算力获取上，有人提出学术和非营利组织如何获得类似工业界的资源（例如 512 个 A100），以及大学附属的 GPU 集群是否可以被利用来进行大型科技公司之外的大规模预训练。
    • 一位评论者指出，Deepseek-0528-Qwen3-8B 的 Benchmark 分数显著高于 OpenThinker3，表明这些模型在评估指标上存在性能差距。
    • 针对大规模模型训练的物流和资金问题提出了疑问，特别是提到使用“512 个 A100 实例”。讨论涉及美国大学是否拥有与大型科技公司相当的 GPU 资源，以及研究资助或内部加速器计划如何管理此类高端硬件的访问，还触及了在获得外部投资前利用这些基础设施创办商业初创公司的可能性。
    • 有人对 OpenThinker3 的 Benchmarking 提出批评，指出发布的测试结果主要将其与过时的模型进行对比，这限制了在衡量其相对于最新 LLM 性能时的参考价值。

3. 基准测试与实验：Sparse Transformers 和 LLM Town of Salem 锦标赛

  • 我组织了一场包含 100 场 Town of Salem 比赛的竞赛，由最优秀的模型作为玩家。游戏日志也已发布。 (Score: 113, Comments: 30)：针对各种领先的 LLM（DeepSeek, distilled Qwen, Claude, Grok, GPT-4.1, Gemini）作为玩家进行了 100 场 Town of Salem 模拟，重点关注信息不对称下的上下文推理、欺骗和多 Agent 策略等能力。结果显示 DeepSeek 和 Qwen（即使是蒸馏版本）的表现优于 Claude 和 Grok；GPT-4.1 表现也很强劲，而 Gemini 模型除了作为平民（peasants）外，表现普遍一般。详细的日志、评估方法和脚本可在 GitHub 仓库中找到 (https://github.com/summersonnn/Town-Of-Salem-with-LLMs)。 评论中的讨论幽默地称赞该设置是 Agentic LLM 的理想 SOTA 基准测试，尽管没有太多深入的技术辩论；参与者强调了对推理和博弈论密集型任务的多 LLM Agent 基准测试的兴趣。
    • 一位评论者观察到 Town of Salem 基准测试中存在明显的关联：对齐程度更高（more aligned）的语言模型往往在“平民”角色上表现更好，而限制较少（未过滤）的模型作为“吸血鬼”的胜率更高。这表明 LLM 的 Alignment 或安全微调可能会影响它们在对抗性或欺骗性游戏环境中的行为和成功，暗示了安全模型 Alignment 与复杂任务中涌现能力之间的微妙权衡。
  • Sparse Transformers：以 30% 更少的内存运行快 2 倍的 LLM (Score: 398, Comments: 63)：NimbleEdge 发布了用于 Transformer 中结构化上下文稀疏性的融合算子内核，灵感来自 LLM in a Flash (Apple) 和 Deja Vu (Zichang et al)。他们的稀疏前馈实现避免了空闲计算，使 MLP 层推理速度提高了 5X ，内存减少了 50% ；与标准 HuggingFace Llama 3.2 3B 实现相比，Llama 3.2 3B 的端到端基准测试报告显示 TTFT 降低了 1.51X ，吞吐量提高了 ~1.78X ，内存使用减少了 26.4% （仓库）。计划中的更新包括对 int8、CUDA 和稀疏注意力内核的支持。 评论者询问稀疏化可能导致的质量下降、与量化的比较，以及该方法对其他模型或 gguf 格式（例如用于 llama.cpp）的即插即用适用性；该帖子未提供直接回答，凸显了对实证质量基准和更广泛生态系统支持的需求。
    • 多位评论者对使用 Sparse Transformers 时的质量下降表示担忧，指出虽然这些架构承诺了速度和内存的改进（例如“快 2 倍的 LLM，内存减少 30%”），但关于实际模型性能与稠密或量化模型之间权衡的细节讨论不足。针对量化的基准测试和消融研究对于技术采用至关重要。
    • 用户询问与 llama.cpp 和 GGUF 等实现栈的兼容性，特别是质疑稀疏表示是否会在消费级 GPU（如 NVIDIA 30 系列）上产生类似的性能提升或得到有效支持，因为在全量和稀疏之间切换的直接 API 或架构支持通常不是“即插即用”的。
    • 人们对 Sparse Transformers 是否可以通过量化进一步优化感兴趣，探讨这些方法是互斥的还是可组合的。技术读者将受益于演示两种压缩方法（稀疏 + 量化）共同应用时情况的文档或基准测试。

其他 AI Subreddit 回顾

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

1. Gemini 2.5 Pro 发布、基准测试与对比

  • Gemini 2.5 Pro 最新更新现已进入预览阶段。 (评分: 673, 评论: 188): 该图片展示了新预览版 Gemini 2.5 Pro 的基准测试结果，显示了其在“推理与知识”、“科学”和“编程”任务中相对于 OpenAI 03、Claude Opus 4 和 DeepSeek R1 的表现。Gemini 2.5 Pro 在“科学”类别中以 86.4% **的分数领先，并在其他类别中也表现出具有竞争力或更优的结果，直观地强调了 Google 最近在模型能力方面的进步。来源: Sundar Pichai 在 X 上的发布 图片。** 评论者们争论其对开发者的实际价值，一些人期待 Gemini 2.5 Pro 能改善软件工程工作流。关于竞争特性的讨论，特别是在编程应用方面，有人声称尽管 Opus 4 在通用能力上可能落后，但在 swebench 等特定编程基准测试中表现出色。
    • 一位评论者提到了最近的说法，即 Gemini 2.5 Pro 在 Aider Polyglot 基准测试中获得了 86.2% 的分数（见 来源），这引发了关于该模型在代码生成和多语言任务中真实表现的疑问。
    • 另一位用户强调了 Claude Opus 4 在 Swebench 基准测试中的优势，特别是其处理代码相关任务的能力，这表明即使 Gemini 2.5 Pro 拥有更优越的通用语言能力，Claude 的 Agentic/自主编程特性在复杂编程工作流中可能仍然优于 Gemini 目前的实现。
    • 提到了“0325”版本，暗示 Gemini 2.5 Pro 让人联想起之前备受好评的 Google 模型版本，该版本可能以稳定性或某些性能特征著称。这标志着用户对 Google 新模型发布的持续一致性和可靠性抱有期待。
  • Gemini 2.5 Pro 06-05 完整基准测试表 (评分: 378, 评论: 119): 该图片显示了一个全面的基准测试表，将最近发布的 Gemini 2.5 Pro 06-05 模型与 OpenAI 的 O3 和 O4-Mini、Anthropic 的 Claude Opus 4、Grok 3 Beta 以及 DeepSeek R1 等知名模型在各种任务中进行了对比。关键性能类别包括推理、科学、数学、代码生成、代码编辑、Agentic 编程、事实性、视觉推理、图像/视频理解、长上下文处理和多语言能力，并附有各项的分数或百分比。还包括定价指标（输入/输出成本）和这些评估的方法论，提供了对 Gemini 2.5 Pro 竞争定位的见解。 评论者注意到 Google 模型更新的速度很快，并推测这种节奏使 Google 能够利用其对完整基础设施栈的控制，快速匹配或超越竞争对手的发布。还有人提到将高性能基准测试（Aider 88% 在 Agentic 编程中）保存下来，以防备新的竞争模型。
    • 一条评论指出了报告的基准测试中的差异和潜在错误，特别注意到 Gemini 2.5 Pro 06-05 的 swebench 验证分数低于其前身（05-06 版本为 63.3%，而新版本更差）。此外，对列出的 o3 分数的准确性也存在怀疑——表中报告为 49.4%，而其他地方的真实基准测试显示 o3 为 69.1%。这引发了对基准测试方法论或可能报告错误的担忧。
    • 另一个讨论线程比较了 Gemini 2.5 Pro 和 o3 的性价比，指出 Gemini 以大约四分之一的成本实现了相似或更好的分数，这表明 Google 的基础设施允许快速且廉价地迭代和部署模型。
    • 一项技术观察指出，Google 对自身基础设施的所有权使其能够快速迭代、更新并发布新模型——这可能是对竞争对手公告的回应——从而形成了一个快速开发和基准测试的周期。
  • 呃……哪个是哪个？ (Score: 303, Comments: 68): 该图片突显了 Google 两个 Gemini LLM 预览模型命名中的版本混淆： gemini-2.5-pro-preview-06-05 和 gemini-2.5-pro-preview-05-06。歧义源于后缀是指 MM-DD 还是 DD-MM 格式的日期，因为两者在 6 月份都是有效日期。这反映了人们对 AI 模型发布中不一致且具有区域歧义的版本命名方案的普遍不满，尽管有人建议遵循语义化版本控制（Semantic Versioning，例如 1.0.0）等最佳实践，但并未被采纳。 评论对这种令人困惑且非标准的模型版本命名表示愤慨，建议使用语义化版本控制以提高清晰度，并调侃模型命名中缺乏区域敏感性（美国与欧盟的日期格式差异）。
    • 一位评论者强调了对 LLM 模型之间缺乏一致且标准化的版本或命名惯例的沮丧，建议坚持语义化版本控制（例如 1.0.0, 1.0.1, 1.1.0, 2.0.0）将有助于开发者和用户之间的清晰沟通。缺乏此类标准可能会在 LLM 发布期间的更新和比较中导致混乱。
  • 新版 Gemini 2.5 Pro 在 WebDev 竞技场击败 Claude Opus 4 (Score: 230, Comments: 84): 图片显示了来自 Chatbot Arena 的排名表，其中 “Gemini-2.5-Pro-Preview-06-05” 以 1,872 票获得了 1443 的最高分，超过了基于 2,466 票获得 1412 分的 “Claude Opus 4”。这些结果反映了不同 AI 模型在特定 Web 开发背景下的用户评分对比。 评论者们争论此类基准测试的实际意义，对近期基准测试的有效性表示怀疑，并表达了对 Claude 编程工具的偏好，尤其是对于本地开发。另一条评论强调了对模型评估实践的担忧——某些模型可能受益于“排行榜幻觉（leaderboard illusion）”策略，即在丢弃表现不佳的版本后，仅将表现最好的私有变体公开，这可能会扭曲公众对模型性能的认知。
    • 几位评论者指出了当前基准测试方法的局限性。所谓的 “webdev” 基准测试旨在捕捉现实世界的编程能力，但因其模糊性而受到批评：关于它究竟衡量什么——是 Prompt 遵循能力、代码创造力、优化能力，还是对稀疏 Prompt 的响应能力，存在争议。这导致人们怀疑此类指标除了作为通用能力晴雨表之外，是否能提供关于模型功能性能的可操作见解。
    • 在面向代码的 Agent 工具中观察到了差异：虽然 Gemini 2.5 Pro 在某些定量基准测试中可能表现更好，但用户提到 “Claude Code” 在实际的基于 Agent 的编程任务中仍然更有用。值得注意的是，与 Claude 的产品相比，Google 缺乏等效的命令行工具（尽管引入了 Jules），这阻碍了本地化的开发者工作流。
    • 一个关键点被提出，即“排行榜幻觉（leaderboard illusion）”：据称各大公司（包括 Google、Meta 和 OpenAI）在 Chatbot Arena 等公共排行榜上运行其模型的私有版本，仅发布得分最高的变体。这种做法可能会扭曲人们对报告排名的进步感知和可靠性，正如最近的一篇学术论文所总结并由 Computerworld 报道的那样。

2. ElevenLabs v3 表现力文本转语音（Text-to-Speech）突破

  • 推出 Eleven v3 (alpha) - 史上最具表现力的 Text to Speech 模型。 (Score: 1932, Comments: 339): Eleven v3 (alpha) 被定位为最先进的、具有表现力的文本转语音 (TTS) 模型，演示样本展示了“几乎与真实语音无异”的语音输出。升级后的模型在自然度和情感表达方面似乎都有所提高，目标应用包括有声读物叙述和游戏内对话。用户反馈暗示生成质量超过了之前的 TTS 基准，表明在韵律（prosody）和语调（intonation）方面都有显著提升。 评论强调了对语音依赖行业的潜在颠覆性影响，预测了有声读物叙述和电子游戏配音角色的自动化，并强调了在不可区分的语音合成方面的突破。
    • 几条评论强调了 Eleven v3 (alpha) 在表现力和现实感方面的技术飞跃，用户注意到输出正变得“几乎与真实语音无异”，表明与之前版本相比，文本转语音模型的性能有了重大进步。
    • 讨论指出了潜在的变革性应用，特别是在电子游戏配音方面，表明该模型生成高度逼真、情感细腻的合成语音的能力可能会改变工作流程，并在某些场景下可能取代传统的配音演员。
  • ElevenLabs 员工发布的这段 Eleven v3 剪辑简直疯狂，TTS 怎么能已经这么好了？（为了防止不清楚，这 100% 是 AI 生成的） (Score: 367, Comments: 35): 一名 ElevenLabs 员工展示了使用 ElevenLabs v3 技术生成的文本转语音 (TTS) 音频剪辑，展示了接近人类声乐表现的水平，包括高度动态、情感丰富且逼真的表达。关键进展似乎体现在韵律、呼吸控制和细微的语调上——解决了早期 TTS 模型在持续情感表达和长篇连贯性方面的弱点。虽然没有提供代码、训练细节或对比基准，但在共享样本中观察到的质量远超典型的合成语音。 热门评论对 TTS 的质量表示震惊，特别是强调了播音员声音中长篇情感表达的真实性。一些人对实际语音中这种长时间尖叫的自然性表示怀疑，含蓄地质疑了模型在真实感与技术华丽感之间的权衡。
    • 几位用户强调了 ElevenLabs 最新发布的 TTS（文本转语音）在质量上的显著提升，指出这个特定的 v3 模型生成的音频非常先进且栩栩如生，特别关注其与之前模型相比的性能和现实感。一位评论者强调，最近的这段演示剪辑展示了该技术令人信服地模仿人类细微差别的能力，这为 TTS 树立了新标准。
  • Elevenlabs v3 太强了 (Score: 385, Comments: 95): ElevenLabs v3 是一种专有的最先进 (SOTA) AI 语音合成系统，因其高保真、连贯的语音输出而受到关注，特别适合有声读物制作。虽然质量受到称赞，但用户注意到其缺乏开源访问权限，且大规模或商业使用的成本很高，特别是与 ChatterboxTTS 等新兴的权重开放（open-weight）模型相比，后者已经可以在消费级 GPU（例如 8GB VRAM）上本地生成高质量音频。 顶级技术观点集中在 ElevenLabs v3 的高成本及其封闭性带来的限制，并预期开源替代方案将缩小质量差距以实现更广泛的应用。
    • 一位评论者强调了一个权重开放的替代方案 ChatterboxTTS，它可以通过 ComfyUI 在具有 8GB VRAM 的消费级硬件上运行，使其与 ElevenLabs v3 等基于云的付费解决方案相比，更易于本地部署。

3. Anthropic Claude Code 与 Project 功能：用户体验与更新

  • 印象深刻：Pro 订阅层级的 Claude Code 改变了游戏规则！[好评] (Score: 144, Comments: 105): Anthropic 的 Claude Code 此前仅限于更高级别订阅，现在已向 Pro 用户开放，允许通过 Claude Code [BETA] 插件与 JetBrains IDE 集成。用户报告在达到速率限制（rate limits）之前，可以持续使用较长时间（4-5 小时的活跃编码），这表明 Pro 层级的配额非常慷慨；然而，Pro/Max 层级与 Teams/Enterprise 账户之间仍存在功能差异，尽管后者价格更高，但并未包含 Claude Code 功能。 评论者指出，此举可能是一种向 Max 订阅追加销售的策略，一些用户对 Teams/Enterprise（更昂贵的层级）缺乏此功能感到沮丧，这表明产品层级与功能提供之间存在错位。
    • 用户报告在 Pro 层级上使用 Claude Code 可以进行长时间、不间断的编码。一位用户描述在遇到速率限制前进行了“近 5 小时的氛围编码（vibe coding）”，这表明 Pro 计划为高级用户提供了高于预期的消息上限或性能天花板。
    • 用户对持续存在的消息长度和上下文窗口（context window）限制感到沮丧。用户提到会遇到“您的消息将超过此聊天的长度限制”的警告，这表明尽管总体反馈积极，但在 Claude 的 Pro 服务中，实际的会话长度或复杂性仍面临限制。
    • 一些用户观察到功能可用性方面存在显著差距，表示更昂贵的 Teams 和 Enterprise 计划目前不包含 Claude Code，而 Pro 订阅者现在却获得了访问权限。这引发了对 Anthropic 订阅层级之间产品差异化和价值分配的担忧。
  • Claude 预估项目需要 5-8 天，然后在一小时内交付了所有内容 (Score: 143, Comments: 55): 该帖子强调 Anthropic 的 Claude Code 模型生成的项目时间表长达数天，类似于传统人类开发者的估算（例如“总共 5-8 天”），但随后在不到一小时内就交付了整个代码解决方案。这表明 Claude 依赖于训练数据中的模式（可能源自人类的项目估算），而不是其自身的处理能力，导致产生了虚高的人类化时间框架，而未能利用 AI 的实时开发速度。 评论者认为这些时间表估算实际上是幻觉（hallucinations）——是大语言模型在人类数据上训练的副产品——并强调 AI 的实际编码速度大大超过了此类预测，使得这些估算在现实世界的 AI 驱动工作流中不可靠。
    • 用户观察到 Claude 的时间估算模仿了人类给出的估算，通常反映了传统的规划（例如复杂任务需要数天/数周），但它实际上可以在几分钟或几小时内完成交付，远快于其自身的预测。这表明其时间预测很可能是从人类训练数据中学习到的，而不是基于其自身的处理速度或实际的 AI 任务表现。
    • 一位用户调整了针对 Claude 的 Prompt 策略，指示其在任务分解中避免包含时间框架，而是专注于可操作的实施步骤，从而优化 AI 辅助下的任务规划。他们还发现让 Claude 分解任务以进行并行工作和创建 GitHub issue 非常有价值，改善了在协作工作流中的实际集成。

  • Claude 上的 Projects 现在支持 10 倍以上的内容。 (Score: 134, Comments: 32): Anthropic 将 Claude “Projects”的内容上限扩大了 10 倍，现在能够处理大幅增加的文件和数据集。重要的是，一旦上传内容超过之前的上下文窗口阈值，Claude 会动态切换到新的检索增强生成（RAG）模式，从而在这些扩展的数据集中进行高效检索，并支持大型复杂文档，如半导体数据表（来源）。 评论者指出，这使得 Claude 的文档处理能力与此前仅在 OpenAI ChatGPT 中可用的高级 RAG 实现齐平，特别惠及那些处理大量技术文档的用户。

  • 当超出之前的文件上传限制时，Claude 会自动切换到检索增强生成 (RAG) 模式。这使其能够有效地处理和引用大型数据集或文档，而不是将所有内容直接放入其工作上下文窗口 (context window)。
  • 用户以前依赖带有 RAG 工作流的 ChatGPT 来处理广泛的技术文档（如半导体数据表），因为 Claude 存在上下文大小限制。Claude 的更新现在支持类似的工作流，增强了其处理大型、技术复杂文档的实用性。
  • 需要对 Claude 项目内的项目结构提供明确指导，因为用户可以在三个不同的位置输入文档/指令：主项目空间、指令字段以及作为对话的单独附件。在这些位置优化组织内容可以直接影响性能和输出质量。

AI Discord 回顾

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

主题 1：Gemini 模型乱象：性能、问题与预测

  • Gemini 2.5 Pro 编程表现糟糕，用户高喊 “Opus Pocus!”：Perplexity AI Discord 的工程师发现 Gemini 2.5 Pro 在编写复杂的 3D 太阳系模拟代码时表现极差，强烈建议改用 Opus 进行编程任务。LMArena 也反映了这种情绪，用户对 Gemini 2.5 Flash 的劣势表示不满，热切期待 o3pro，并关注 Wolfram’s LLM Benchmarking Project 以获得未来更可靠的评估。
  • Aider 基准测试引发对 Gemini 2.5 Pro 的质疑，发布传闻四起：Gemini 2.5 Pro 在 AIDER 基准测试中表现出色（如泄露的多语言测试得分为 86%），这在 LMArena 和 aider Discord 中引发了争论。一些人质疑 artificialanalysis.ai 上的基准测试有效性，并怀疑存在过拟合。用户预测发布时间在 6 月 10 日左右，同时指出其聊天模式会令人沮丧地复制整个文件，而不是提供简洁的 diffs。
  • Gemini 2.5 Flash 陷入死循环，Pro 遭遇速率限制墙：OpenRouter 用户报告 Gemini 2.5 Flash 在结构化响应中产生无限重复，例如 {"appearance" : "red-rimmed eyes, red-rimmed eyes, red-rimmed eyes..."}，使其在结构化数据任务中不可靠。同时，LM Studio 用户发现 Gemini Pro 因每 24 小时 100 条消息的新 API 速率限制而变得“没用”，Perplexity 用户也放大了这种挫败感，他们指出 API 的能力通常明显落后于在线界面。

主题 2：领域新秀：值得关注的发布与新星

主题 3：开发者工具动荡：IDE、框架与开源产品

主题 4：GPU 挑战与基准测试之战：将 AI 推向极限

主题 5：穿梭于 AI 迷宫：隐私、提示词与实际问题

Discord: 高层级 Discord 摘要

Perplexity AI Discord

  • Perplexity 中的图像生成 A/B 测试：部分用户在 Perplexity 搜索结果中看到了图像，而其他用户则没有（如此截图所示），这种差异的原因尚不清楚。
    • 此外，用户报告 Perplexity Labs 仪表板仅生成文本报告，且“App”选项卡丢失，尽管使用了以前有效的提示词。
  • 账单错误导致业务中断：一名用户报告在尝试使用 Business Fellowship 促销代码后出现账单问题，导致发票逾期并可能产生职业影响。
    • 该用户强调了为其超大型国际 IT 公司进行妥善处理的重要性，并被建议联系企业支持 enterprise@perplexity.ai 以解决问题。
  • Perplexity 失去线程可靠性：用户报告随机丢失线程，甚至是他们没有删除的线程，有些线程在几天后仍未恢复，且持续时间超过 2 天且没有妥善修复，引发了严重担忧。
    • 一些用户发现 Android 应用中仍有线程，而网页版是导致问题的原因，因此建议由于不稳定性将数据保存在记事本中。
  • Gemini 2.5 Pro 编程表现糟糕：一名用户发现新的 Gemini 2.5 Pro 在编程方面表现极差，特别是在运行复杂的 3D 太阳系模拟时，需要多次尝试才能获得一个像样的版本。
    • 该用户建议在编程时使用 Opus pocus，别无他选。
  • API 落后于在线结果：用户报告 API 有时无法检索到在线界面能一致找到的信息（例如美国体育新闻），与在线 100% 的成功率相比，经历了 50% 的失败率。
    • 一位用户指出，搜索 API 的功能感觉只有在线界面的 50%，这导致他们寻找其他 API 以产生足够的信息，从而使 API 的使用变得有意义。

LMArena Discord

  • Google 下一代 Gemini 2.5 即将面世：成员们正热切期待新的 Gemini 模型发布，对 Gemini 2.5 Flash 表示不满，并强调 Wolfram 的 LLM 基准测试项目 对未来的评估至关重要。
    • 爱好者们也希望 o3pro 能立即发布。
  • Kingfall 的短暂统治引发猜测：最初的热情围绕着预期的 Kingfall 发布，期望它能解决编程挑战。
    • 该模型的迅速发布及随后的移除引发了对其能力以及与其他模型关系的猜测。
  • Gemini 2.5 Pro 的 AIDER 评分引发争议：Gemini 2.5 Pro 在 AIDER 上据称更高的分数引发了成员间的辩论，一些人质疑 artificialanalysis.ai 上基准测试的有效性。
    • 成员们指出这些结果并不可靠。
  • O3 Pro 发布热潮转为幽默：热情的成员们密切关注 O3 Pro 的发布。
    • 尽管最初有关于其发布的传闻，但这些说法很快被斥为谣言。
  • 模型选择器的把戏：讨论了通过 AI Studio 上的 Model Selector 访问 Kingfall 模型 的问题，随后分享了经验和 prompt。
    • 成员们争论 Model Selector 是否运行正常。

Eleuther Discord

  • LLM 被训练去编造故事：假设 LLM 学会生成不可证伪的叙述，因为人类只在熟悉的话题上纠正它们，这使得编造比提供价值更容易。
    • 这可能与 alignment 和 interpretability 研究相关，特别是理解 LLM 如何响应非专业的人类反馈。
  • Attention 起源受到审视：成员们辩论了 attention 机制 的起源，观察到 ML 社区经常忽视 Transformer 之前的机制，如 Bahdanau attention。
    • 引用了一条 推文 和一篇 Bluesky 帖子，强调了早期在 linear attention 方面的工作。
  • AI 初创公司泡沫担忧浮现：由于 CEO 缺乏 ML 技能以及风险投资家难以区分 ML 人才，引发了对潜在 AI 初创公司泡沫的担忧。
    • 在这场崩盘期间，廉价的 GPU 可能会被用于更有趣的工作。
  • Instruction Tuning 需要 Chat Templates：讨论了 apply_chat_template() 函数对于 instruction-tuned 模型正常运行是否是必需的。
    • 成员们一致认为，使用 chat template 可以避免 out-of-distribution 行为，即使简单的提问在没有它的情况下仍能得到不错的回答。
  • QFNN 算法首次亮相：一位成员介绍了他们关于通用算法 Quantum Field Neural Networks (QFNN) 的研究，包含 NLP、期权交易和电化学反应的 PoC，可在 GitHub 上获取。
    • 该架构使用一个由 phi 调制的 2D 圆柱体，Z 作为 qubit 旋转损失设备运行，旨在实现最小的 GPU 占用。

Cursor Community Discord

  • Cursor 1.0 评价褒贬不一！: Cursor 1.0 已发布，但用户反馈更新后存在基础功能问题，称其仍处于 early beta 阶段。
    • 一段展示新功能的视频已发布（视频链接），展示了 code review 能力、记忆错误的能力以及管理大量 background tasks 的能力。
  • Claude Code 超出预期！: 社区成员对 Claude Code 印象深刻，认为其编程表现优于其他模型，甚至超过了 Cursor，特别是在 Cursor 1.0 更新之后。
    • 用户表示，每月 $20 的 Claude Pro Plan 质量与 Cursor 相当，但成本更低。
  • 用户担心 MAX 定价！: 用户对 Cursor 中 MAX 模式 的成本表示担忧，简单的后续追问就会迅速耗尽请求额度。
    • 用户强调需要更清晰的成本显示，并指出新的 background agents 功能仅支持 MAX。
  • Gemini 模型面临连接问题！: 用户在 Cursor 中使用 Gemini 模型 时遇到连接失败和变慢的问题，尤其是在 1.0 更新之后。
    • 一些成员指出连接问题是“断断续续的，我发给 sonnet 4 一个 prompt 成功了，但下一个就没反应了。”
  • Background Agents 无法启动: 多名用户遇到需要 升级到 Cursor 1.0.0 或更高版本 才能启动新的 background agents 的问题，错误信息为 Upgrade to Cursor version 1.0.0 or later to start new background agents.
    • 一位用户通过使用 Cursor: Start Background Agent Setup 工具解决了该问题。

Unsloth AI (Daniel Han) Discord

  • 使用 Llama.cpp 解决 Mistral Vision 推理问题: 一位用户寻求关于使用 llama.cpp 对 unsloth/Mistral-Small-3.1-24B-Instruct-2503-GGUF 模型进行推理的指导，特别是如何在 prompt 中发送图像。
    • 社区成员建议查看 llama.cpp 文档或咨询社区寻求帮助，另一位成员建议使用 llama-mtmd-cli 构建目标。
  • 合成数据防止 Google 余额凭空消失: 一位用户正在使用 Gemini 2.5 Pro 生成合成数据集，以消耗剩余的 Google Cloud 额度，此前 VS Code 的 agentic 扩展在昨天意外消耗了 $17。
    • 一位成员建议使用 deepseek-chat-v3 以获得更便宜、更好的推理效果，并附带了此图片链接对比图像质量。
  • Unsloth 微调修复进展顺利: 用户讨论了微调 notebook 的问题，包括一个潜在问题：Qwen3-base notebook 可能在训练 Qwen3 instruct 版本，并分享了 Unsloth notebooks 仓库。
    • 关于旧版本和兼容性的问题已通过在 notebook 中设置 use_exact_model_name = True 修复，这需要 transformers==4.48。
  • Docker 考虑分发蒸馏数据集: Docker 的 AI Runtime 团队表示有兴趣在 Docker Hub 上发布 Unsloth 模型，建议使用 docker model package 命令将 GGUF 文件打包为 OCI Artifacts。
    • Unsloth 团队对合作持开放态度，但对自动上传所有模型表示担忧，并询问了类似于 Modelscope 的自动化功能。
  • Homunculus-12B 被誉为重头戏: 成员们吹捧了蒸馏模型 Homunculus-12B，该模型是从 Qwen3-235B 蒸馏到 Mistral-Nemo 骨干网上的，据称它是无审查的，并且能简单地解释引力。
    • 该模型保留了 Qwen 的两种交互模式——/think（深思熟虑的思维链）和 /nothink（简洁回答）——同时可以在单个消费级 GPU 上运行；目前已有现成的 GGUF。

OpenRouter (Alex Atallah) Discord

  • OpenRouter 发布模型 RSS Feed：OpenRouter 推出了用于实时模型更新的 RSS feed，可在此处 here 获取。
    • 该订阅源让用户能够及时了解 OpenRouter 上可用的最新模型。
  • iOS 应用采用 OpenRouter 作为 LLM 后端：一款正在开发的 iOS 应用使用 OpenRouter 作为其 LLM 后端来处理 character cards（角色卡），并计划发布 TestFlight 版本。
    • 开发者目前正在解决消息格式化方面的挑战，并计划随后集成更多客户端。
  • 电子表格助力产品普及：一位成员强调了 spreadsheets（电子表格）在推动商业领域产品普及方面的重要性。
    • 他们指出，对电子表格的熟悉程度降低了新产品的准入门槛，这符合“降低产品准入门槛是你能做的最好的事情”这一原则。
  • Gemini 2.5 Flash 陷入无限循环：用户报告称 Gemini 2.5 Flash 在结构化响应中会生成相同值的无限重复，例如 {"appereance" : "red-rimmed eyes, red-rimmed eyes, red-rimmed eyes..."}。
    • 建议用户寻求 Chatwise MCP 的支持。
  • OpenAI 日志记录引发数据保留担忧：继一篇关于 OpenAI 被迫记录用户输出的 文章 之后，用户质疑当“启用训练和日志记录”关闭时，OpenRouter 是否应该为 OpenAI 模型显示警告。
    • OpenRouter 澄清他们并非零数据保留，并正在就法院要求下启用此设置的问题与 OpenAI 进行核实。

HuggingFace Discord

  • IBM API 负责任地调整 Prompt：IBM Research 正在开发 Responsible Prompting API，该 API 在推理前推荐 prompt tweaks（提示词调整）以改进 LLM outputs。
  • 区块链验证 LLM 输出：一篇新论文 Consensus Validation for LLM Outputs 探讨了使用 blockchain consensus mechanisms（区块链共识机制）来增强 LLM output 的可靠性。
    • 该论文建议将其应用于 AI agents、法律/医疗工具以及 AI alignment，可在此处 here 查看。
  • 安装 Transformers 的烦恼是真实存在的！：一位成员在 Windows 上安装 Hugging Face Transformers 时遇到问题，并提交了一个 GitHub issue，详细说明了他们的步骤，包括 fork 仓库和创建虚拟环境。
    • 一位成员建议检查包冲突并确保使用虚拟环境，特别是使用 Python 3.10 时。
  • 法国 AI 初创公司引发关注：一位成员声称，融资超过 4 亿欧元 的法国 AI 公司 hcompany.ai 缺乏技术护城河，且容易被复制。
    • 该说法称，该公司由政府资助的模型 Lucie-7B 表现不佳，甚至存在种族歧视，导致其 API 被撤下，详情可见 here。
  • 征集金融交易安全资源：成员们对学习保障 financial transactions（金融交易）安全的方法产生了兴趣。
    • 这包括了解检测和预防欺诈活动的细微差别，并征求通用资源建议。

OpenAI Discord

  • 对 Pro 计划排除 Codex CLI API 的不满：成员们对 Codex CLI API 仍未包含在 OpenAI 提供的 Pro subscription 中表示失望。
    • 一些人建议 Pro subscription 应该包含其他计划中可用的所有功能，以提供全面的价值。
  • 建筑师利用 AI 设计住房：一位来自巴西的建筑师正在一个拥有 1,500 个地块 的住房项目中利用 AI 和参数化设计（parametric design），并正在寻求合作者。
    • 该建筑师渴望学习并与对将 AI 应用于建筑设计感兴趣的社区成员合作。
  • Firefly 进一步落后：成员们注意到 Adobe Firefly 仍然基于 diffusion，尚未升级到像 4o 这样基于 transformer 的模型，以实现更好的 generative fill。
    • 他们期待未来能发布基于 transformer 的版本。
  • Veo3 实现一致性里程碑：一位成员报告称，使用 Veo3 在创建一致的角色和音频方面取得了重大成果。
    • 他们请求允许分享一段展示这些成就的视频，这表明 AI 驱动的内容创作取得了显著进展。
  • Y Combinator 促使更好的评估：一位成员分享了最近 Y Combinator 关于 prompting 的播客/视频 中的见解，该视频强调了使用评估机制和领域专家修正来增强企业中的 AI 性能。
    • 他们建议建立一个反馈循环，让 AI 输出带有理由的多个选项，并通过所选选项的评论来优化原始 prompt。

aider (Paul Gauthier) Discord

  • Gemini 2.5 Pro 发布日期临近：用户推测 Gemini 2.5 Pro 的发布日期，参考了 6 月 5 日 的标签和内部 benchmark 结果，根据历史模式预测将在 6 月 10 日 左右发布。
    • 一位成员表示，Google 历史上习惯在周二进行软启动，并在周三发布博客文章或 GA 公告。
  • Gemini 的 Chat Mode：倒退了一步？：一位用户报告称，Gemini 2.5 Pro 的 chat mode 会复制整个需要更改的文件，而不是以 diff 格式输出修改部分。
    • 他们补充说，这使得 chat mode 变得无法使用，只能在 code mode 下进行 one-shot 执行。
  • 面向 Aider 的 IDE 供 Alpha 测试者使用：一位用户分享了 一个链接，指向一个用于 alpha 测试的 以 Aider 为中心的 webapp IDE。
    • 该 IDE 被描述为专门迎合 Aider 的工作流。
  • Aider 与 Cursor 之争引发开发者分歧：一位用户对从 Aider 切换到 Cursor 的用户进行了调查，指出 Cursor 感觉更慢，且其 agent mode 会变得“疯狂”（wild）且必须加以控制。
    • 该用户指出，Cursor 在运行多个带有同步 AI 编辑过程的 blitzes 能力方面不如 Aider 直观。
  • Qwen 和 DS 落后于 Gemini 和 Claude：据报道，Qwen 2 35B 和 DS R1.5 的表现不如 Claude 和 Gemini，在一些用户测试中 Qwen 略优于 DS。
    • 一位用户注意到，这两个模型都花了大约 4 分钟 才弄清楚如何画一个篮球。

GPU MODE Discord

  • 建议从零开始编写 CUDA Matmul：一位成员建议从零开始编写一个 CUDA matmul，在使用 Tensor Cores 的情况下，在 bf16 或 fp16 精度下达到 cuBLAS 吞吐量的 85%，并将其作为一个极佳的学习练习。他链接了 CUDA MMM 和 Outperforming cuBLAS on H100: A Worklog。
    • 另一位成员建议对工作负载进行 Profiling，以识别易于优化的“低垂的果实”（low-hanging fruits），例如使用不带并发的简单 for 循环的内层循环，或者直接从现有的优化中学习，以确定哪些是最相关的技能。
  • 关于 Megakernel 的询问：一位成员询问在 Triton 中是否存在针对 LLaMA 等流行架构的 megakernel 或全模型 Kernel 示例，并考虑编写一个，可能会借助 KernelLLM 的帮助。
    • 他们计划使用 KernelLLM 提供协助。
  • Torch Compile 胜过 AITemplate：AITemplate 目前处于维护模式，因此 torch.compile 是主动开发的推荐选择，它能提供相当甚至更好的性能。对于 C++ Runtime 替代方案，建议使用 AOTInductor 而非 AITemplate。
    • 一位成员指出 torch compile 的性能将优于 AITemplate。
  • AMD FP8 GEMM 解决方案涌现：成员们一直在积极分享针对 AMD Challenge 的 FP8 解决方案，并附带了 GitHub 代码链接 和另一个优化版本。
    • 一位成员在 GPUMode AMD FP8 MM GitHub 上分享了他们的 FP8 解决方案实现，灵感来自他人的文章；而另一位成员仅用 100 行代码的 Kernel 实现的 FP8 GEMM 就获得了前 5 名，且新版本又有 5us 的速度提升。
  • Blackwell B200 横扫基准测试：一位用户发布了 Blackwell B200 的基准测试结果，在 fp16_gemm 中达到 0.99 petaflops/sec，在 fp8_gemm 中达到 1.97 petaflops/sec，在 nvfp4_bf16_gemm 中达到 2.69 petaflops/sec，在 nvfp4_nvfp4_gemm 中达到 3.09 petaflops/sec。
    • mixed_mxfp8_bf16_gemm 的性能落后，仅为 0.23 petaflops/sec，这引发了关于 MXFP8 性能相对较慢是软件还是硬件问题的讨论。一位用户指出 cuDNN 路径 在某些情况下会提供更好的性能，并澄清 cuDNN 后端在 Blackwell 上提供了最佳性能。

LM Studio Discord

  • AgenticSeek 克隆 OpenManus：一位用户询问了 AgenticSeek，它之前被称为 OpenManus，类似于 OpenDevin 更名为 OpenHands。
    • 更名可能与版权问题有关。
  • Gemini Pro 用户面临速率限制：用户发现 Gemini Pro 在新的速率限制下变得“毫无用处”，现在是 每 24 小时 100 条消息。
    • 速率限制出现在使用自动化脚本进行 API 调用时，而非在 AI Studio 界面或 Gemini app 本身。
  • Homunculus-12B：Mistral-Nemo 的新生命？：据报道，Arcee AI 的 Homunculus-12B 模型（从 Qwen3-235B 蒸馏到 Mistral-Nemo 骨干网络）为 Mistral-Nemo 注入了“新生命和智慧”，并增加了推理能力。
    • 它保留了 Qwen 的双模式交互风格，同时可以在单个消费级 GPU 上运行。
  • ROCm 导致 llama.cpp Vision 变慢：用户报告新的 ROCm llama.cpp v1.34.1 runtime 导致 Vision 模块变慢，在 7900XT 20GB GPU 上响应时间从约 1 秒增加到超过 10 秒。
    • 用户被要求分享结果和截图以便进一步调查。
  • NAND 读取刷新：事实还是虚构？：成员们讨论了 NAND 单元如何随时间缓慢泄漏电荷，以及“读取刷新（read refresh）”的概念，即如果数据未被重写，则将其移动到新单元；旧的文件系统会定期访问数据，这可以通过删除并重写数据来加速。
    • 有人提到，系统安装时写入的 OS 文件读取速度会变慢，并且某些文件系统会特意定期访问数据以检查降级情况。

Latent Space Discord

  • Langfuse 全功能开源：Langfuse 作为一个功能齐全的开源平台发布，对 LLM 应用极具潜力，正如一位一直坚持私有化部署（self-hosting）的用户所报道的那样。
    • 成员们尝试在 NAS 上进行设置，并报告遇到了一些初始问题。
  • 来自日本的 Shisa V2 登场：Shisa.ai 发布了 Llama3.1 405B 全量微调的 Shisa v2 模型，据称是日本训练的性能最高的模型。
    • 据称该模型在日语任务上可与 GPT-4o 和 Deepseek-v3 竞争，模型、量化版本和 fp8 版本已在 HF 上提供，以便快速测试。
  • Netlify 和 Neon 打造新应用构建器：Netlify 宣布了 Netlify DB，这是一个由 Neon 驱动的 serverless Postgres 数据库，专为 AI 原生开发设计，旨在减少代码与数据之间的摩擦，详见 Netlify 博客。
    • 用户还注意到 Convex 发布了由 bolt.diy 驱动的 chef.convex.dev。
  • Zapier 考核 AI 素养：Zapier 现在要求 100% 的新员工具备 AI 流利度（AI fluent），通过筛选、技能测试、异步练习和现场面试来衡量不同级别员工的 AI 流利程度，详见此推文。
    • Zapier 的 AI 流利度级别通过筛选、技能测试、异步练习和现场面试进行评估。
  • Qwen 团队深耕行业：阿里巴巴 Qwen 团队推出了 Qwen3-Embedding 和 Qwen3-Reranker 系列，提供多种尺寸（0.6B, 4B, 8B），支持 119 种语言，并在 MMTEB, MTEB 和 MTEB-Code 上展示了最先进的性能，详见此公告。
    • 这些模型在 Hugging Face, GitHub 和 ModelScope 上开源，并可通过阿里云 API 访问。

Manus.im Discord Discord

  • Manus 提供更深层的上下文：成员们讨论了使用相同的 prompt，其他替代方案提供的替代方案上下文较浅，而 Manus 提供的上下文则非常详细。
    • 有人建议“更大的上下文意味着更多的资源（廉价电力、内存存储、更快的芯片等）”，因此这种性能可能与资源挂钩。
  • Replit 挑战 Cursor：一位开发者分享道，需要“将 Manus 的成果放入 Cursor 或任何正在使用的 IDE 中进行调整和修复，直到它可以运行”，另一位开发者建议使用带有 Devin 2.0 安全检查的 Replit。
    • 第一位开发者回应说，他们曾使用过 2 个月的 Replit，虽然那是去年的事，但“对结果并不满意”。
  • 邀请链接刷屏引发不满：用户对大量分享的邀请链接表示沮丧，质疑“为什么还要把它加回来？😭”。
    • 有人建议创建一个专门的邀请码频道，以遏制垃圾信息。
  • AI 播客寻觅 Manus 开发者：一位正在使用 Manus 创建应用并寻找开发者的成员，提供了加入其 AI podcast 的机会，向 300,000 多名观众推广开发者的项目。
    • 该成员还提到“我实际上正在与 manus 的人洽谈为他们主持播客……但我等不及了，哈哈”。
  • Manus 额度太贵？：一位用户表示，如果 Manus 每个任务不收这么多费用，它会好得多，“所以现在我改用替代方案了，因为它用起来不方便”。
    • 另一位用户建议查看指南并在频道 [<#1370393476029616238>] 中使用其他工具来节省点数。

Modular (Mojo 🔥) Discord

  • Discord 关于 (at)everyone 标签的辩论：成员们就 (at)everyone 标签 的使用展开了辩论，一些人认为这可以增加参与度，而另一些人则警告这可能会造成干扰，建议改用 官方公告频道。
    • 公告频道被推荐作为一种无需使用 (at)everyone 标签 即可接收重要帖子通知的手段。
  • Mojo 中的 StringLiteral 将自动提升：Modular 团队计划让 StringLiteral 自动提升（autopromote）为 String，类似于 IntLiteral 自动提升为 Int 的方式，从而简化类型处理。
    • 这一更改旨在提高 Mojo 语言的易用性和一致性。
  • Slablist 显示出性能提升：一位工程师分享了十年前关于 slablist 性能 的工作，并在这份 PDF 中量化了其收益。
    • 该成员在此处对收割阈值（reaping thresholds）进行了可视化。
  • JSON 解析器受限于重新分配瓶颈：一位正在开发 JSON 解析器（GitHub 上的 EmberJson）的成员发现，在解析诸如此示例的大型结构时，重新分配（reallocations）成为了一个瓶颈。
    • 这一性能瓶颈突显了在 Mojo 中高效处理内存分配的挑战。
  • Mojo 放宽可变引用限制：Mojo 团队解释说，Mojo 不需要像 Rust 那样防止重叠的可变引用（mutable references），这是一个重大的易用性优势。
    • 他们指出 Mojo 在函数中使用时已经会拒绝可变别名（mutable aliases），但团队仍在思考如何建模线程安全。

Nous Research AI Discord

  • DeepHermes 24B API 离线：DeepHermes 24B API 和聊天产品经历了停机，但目前已恢复稳定。
    • 用户现在可以恢复使用该服务，不会受到干扰。
  • Claude 在 Agent 行为方面表现出色：成员们注意到 Claude 在 Agent 行为（agentic behavior） 方面始终优于其他模型。
    • 一位用户幽默地观察到，当他们切换到另一个模型时，Claude 似乎会感到“伤心”。
  • OpenAI 称 ChatGPT 日志面临隐私噩梦：据 ArsTechnica 这篇文章报道，OpenAI 声称法院正强制其保存所有 ChatGPT 日志，他们认为这是一场隐私噩梦。
    • 保留所有用户日志的影响正在 AI 社区内引起重大关注。
  • Arcee AI 推出 Homunculus-12B：Arcee-AI 发布了 Homunculus-12B，这是一个拥有 120 亿参数的指令模型，由 Qwen3-235B 蒸馏至 Mistral-Nemo 骨干网络（backbone）而成，旨在单个消费级 GPU 上保留 Qwen 的双模式交互风格。
    • 这一新模型旨在为消费级硬件带来先进的能力。
  • Nous 推出 Psyche Network 论坛：Nous Research 推出了一个用于讨论 Psyche Network 上基础模型的论坛，访问地址为 forum.psyche.network。
    • 该论坛旨在成为讨论基础模型研究、开发和应用的社区空间。

LlamaIndex Discord

  • Seldo 破解高效 Agent 设计：来自 LlamaIndex 的 Seldo 在 AI Engineer Summit 上分享了生产环境中高效 Agent 设计模式 (Effective Agent Design Patterns) 的详细解析。
    • 这些模式旨在指导开发者构建更健壮、更具扩展性的 AI Agent 应用。
  • LlamaIndex 自动化 SEC 提取：根据这篇博客文章，LlamaIndex 展示了 LlamaExtract 和 Agent 工作流如何自动化 SEC Form 4 的提取，以提高市场透明度。
    • 该工具旨在帮助自动化企业股票交易披露分析。
  • 生产级电子表格 Agent 发布：LlamaIndex 推出了生产级 Spreadsheet Agent，旨在简化审计、税务、保险和企业财务中的手动处理流程，链接见此处。
    • 该 Agent 承诺减少手动工作量，并提高处理大量电子表格任务的效率。
  • Ollama 驱动 Code Interpreter：一位成员建议使用 Ollama 来运行 qwen3，作为 Code Interpreter 工具切换模型的简便方法，参考了 Ollama 文档。
    • 集成 Ollama 为模型部署和实验提供了一种流线化的方法。
  • 文档服务宕机：多位成员注意到 doc.llamaindex.ai 页面出现宕机，这与 ReadTheDocs 状态页的信息一致。
    • 此次停机凸显了为开发者监控文档基础设施的重要性。

MCP (Glama) Discord

  • Slimpow 助力 AI 推理飞跃：一位成员使用 pydantic-ai-slimpow.pow 开发了一个本地版本的连续思考 (sequential thinking)，增强了 IDE 内 AI 模型的推理能力和准确性，包括一个用于处理大文件的文件读取工具，并扩展了 AI 的推理能力和视角。
    • 这旨在为在 IDE 中使用 AI 提供更愉悦的体验。
  • C 语言服务器在转换中迷失：一位成员在将基于 C 语言的服务器添加到 glama.ai 时遇到问题，注意到它缺少 language property（语言属性），而不像基于 Python 或 JavaScript 的服务器，但该问题随后得到了纠正。
    • 最初，他们在修改服务器的 Description（描述）时也遇到了困难。
  • Goose 的 A2A 集成推测：一位成员对将 Google 的 A2A 协议与 MCP 服务器集成表现出兴趣，并询问 Goose 是否计划在多 Agent 系统中加入 A2A，引用了 Cursor.sh 深度链接文档。
    • 该用户最初仅将 MCP 视为另一种 API 定义，直到体验了 Claude MCP server 的功能。
  • MCP 规范的不稳定性阻碍 SDK 开发：一位正在为 MCP 构建 C SDK 的成员提到了远程规范（SSE, HTTP）带来的挑战，原因是其演进过快且细节模糊，暗示难以追踪这些变化。
    • 该成员指出，规范似乎仍在快速演进，太多细节尚不确定，这对于 SDK 开发来说简直是场噩梦。
  • MCP 现实检查：超越教程阶段：分享了一段对 MCPAdapt 作者 Guillaume Raille 的 YouTube 视频采访，讨论了 MCP 在现实世界部署中的挑战，提到了不兼容问题、身份验证地狱、MCP 服务器质量、扩展挑战以及调试等问题。
    • 他在最后简要提到了 MCP 的未来。

Notebook LM Discord

  • NotebookLM 的音频胃口：仅限 MP3！：用户发现 NotebookLM 仅支持 MP3 音频文件，不支持 M4A 格式。
    • 社区反应强调了需要更广泛的格式兼容性以提升用户体验。
  • 语言更新后交互模式消失：在一次多语言更新后，交互模式 (interactive mode) 消失了，后来发现该功能目前为仅限英文 (English-only)。
    • 尽管调整了设置，用户仍热切期待该功能的回归。
  • 通过 Ultra 实现的播客制作实力：Reddit 上出现了一个提示词 (prompt)，详细介绍了如何使用 Ultra 创建 90-120 分钟的播客剧集，强调了对源材料的详细分析。
    • 该提示词要求逐句解析、嵌入图表，并加入间隔重复提示 (spaced-repetition cues) 以实现最佳记忆效果。
  • Google Workspace Starter 呼应个人用户限制：测试显示 Google Workspace Starter 在 NotebookLM 中的限制与免费个人账户一致。
    • 共识表明两者功能相当，尽管存在一些细微差别。
  • 欧洲的公开分享功能存在注意事项：NotebookLM 已面向欧洲的个人账户推出了公开分享 (Public sharing) 功能。
    • 一些用户遇到 Chrome 浏览器中分享按钮被隐藏的问题，可能是由扩展程序引起的。

tinygrad (George Hotz) Discord

  • LLVM 中缺失的循环拆分 (Loop Splitting)：一名成员正在研究使用 LLVM 加速 CAT，并询问循环拆分是否仅存在于其文档中提到的 ROCm llvm-project 中。
    • 该成员在代码中未发现循环拆分选项，正寻求通过 builder 选项触发 InductiveRangeCheckElimination 或 ROCm 循环拆分。
  • llvm.py 中没有 InductiveRangeCheckElimination？：runtime/autogen/llvm.py 中使用的 llvm C 源码缺少 C++ LLVM 库中的 InductiveRangeCheckElimination，详见 LLVM 文档。
    • 该成员考虑使用 llvmlite 来访问 IRCE，但对自定义 autogen 持谨慎态度，建议通过 extern 或重写 C++ 代码来添加循环拆分。
  • TinyGrad 的 DEBUG=2 输出需要文档化：成员们讨论了对 DEBUG=2 的输出进行文档化的必要性，因为它经常被推荐作为调试的起点。
    • 讨论未涉及该文档应存放在何处。
  • 寻求 CUDA Kernel 示例：一名成员询问了 TinyGrad 中的 CUDA kernel 示例，注意到存在 CUSTOM 算子，但在 GitHub 仓库中难以找到具体的用例。
    • 他们正考虑移植一个项目，发现用 Python 表达某些 kernel 具有挑战性，尽管他们理解 TinyGrad 的设计原则，并认为这篇介绍很有帮助。
  • 数据集打乱变慢问题调查：一名成员发现了一个与随机打乱训练数据集相关的 4 秒延迟，特别是那些名称类似于 r_3125_64_4_16_12500_3_4_4 且包含 ['where', 'gather'] 或 ['__getitem__'] 操作的 kernel。
    • 在使用 OpenCL 后端的 RTX 3080 上打乱数据集被证明比将数据复制到 CPU RAM 再复制回来还要慢，即使在移除 GPU-CPU 复制并尝试 Tensor.randperm 和 Tensor(random.shuffle(indices_0_50000)) 之后也是如此。

Yannick Kilcher Discord

  • RHDE 创意激发：一名成员介绍了 RHDE (Recursive Hyper Dimensional Emergence)，并请求合作利用它做一些有用的事情。
    • 其他成员对 AI 生成的文本墙表示担忧。
  • Marius Symbolic AI 受到关注：一名成员建议在 Symbolic AI 的背景下与 Marius 分享一个关于超空间（hyperspace）的想法，可能与这篇 arXiv 论文有关。
    • 对话表明，人们有兴趣将超空间概念与使用 Marius 的 Symbolic AI 方法相结合。
  • OpenAI 隐私遭洗劫：法院强制 OpenAI 保存所有 ChatGPT logs，包括已删除的聊天记录以及通过其 API 业务产品记录的敏感聊天记录。
  • Muon 优化器调整权重矩阵梯度：Muon 优化器调整权重矩阵（weight-matrix）的梯度，使其特征值（eigenvalues）近似等于 1。
    • 这与 SGD 和 Adam（按权重计算）不同，并且根据这个 GitHub issue，在多任务学习（multitask learning）中表现出有趣的特性。
  • 百度发布新模型：据一条推文显示，百度发布了新模型。
    • 未提供有关模型能力或架构的具体细节。

Torchtune Discord

  • Iterable Dataset 重构 RFC 引发辩论：在 torchtune 中发布了一个关于可迭代数据集（iterable dataset）重构的 RFC，并在这个 GitHub Pull Request中寻求对其方法和潜在变化的反馈。
    • 该请求强调了高效处理数据集和识别重大改进的重要性。
  • 优化器不可知论在 SGD、Adafactor 和 Adagrad 失败下面临审查：据报道，在使用 torchtune 进行全分布式 SFT 时，SGD、Adafactor 和 Adagrad 失败，并出现与 DeviceMesh 相关的 AssertionError。
    • 这个问题引发了对 AdamW 之外的优化器支持的质疑，尽管有报告称使用 torchao 的 Muon 和 AdamW 以及用于联邦 DiLoCO 的 SGD 测试成功。
  • Adafactor 速度骤降；SGD 错误在分布式 SFT 中浮现：在分布式 SFT 中，Adafactor 的速度从 每秒 700 个 token 降至 70 个，而 SGD 在使用基本配置时触发了与 _fused_sgd_.default! 相关的 AssertionError。
    • 虽然一名成员无法在 nightly 版本上复现该错误，但另一名成员确认了在最新的 PyTorch nightly main 分支上存在该问题，促使进一步调查。

DSPy Discord

  • Anthropic 暴露开发机密：Claude 3.7 和 4.0 之间系统提示词（system prompts）的微小变化揭示了 Anthropic 的开发周期和优先级，详见这篇博客文章。
    • 由于这些细微的版本更新，Anthropic 专注的开发努力和战略优先级现在变得更加透明。
  • DSPy 像野火一样蔓延：为了消除 DSPy 只是“又一个框架”的看法，一名成员正通过在这条推文和这条推文中分享的简洁示例积极宣传 DSPy。
    • 这些简短的信息旨在以易于消化的格式展示 DSPy 的独特价值主张。
  • DSPy 将讨论 Agent 代码高尔夫（Code Golfing）：在赢得 $15k 黑客松奖金并与 VC 和 Gov 建立联系后，一名成员正倡导通过“代码高尔夫”将 DSPy 的理念扩展到 Agent。
    • 他们认为当前的抽象级别对于非专家来说不够理想，并计划在虚拟办公时间讨论此事。
  • DSPy NeurIPS 提升了教授职位的希望：NeurIPS 和 COLM 的强力评审正鼓励一名成员追求教授职位，即使在 美国科学资助 削减的情况下。
    • DSPy 研究获得的积极反响为学术事业提供了充满希望的基础。
  • 深入了解 DSPy 会议：一名成员在 YouTube 上分享了 DSPy session 录像。
    • 该会议为那些有兴趣了解更多信息的人提供了对 DSPy 的详细介绍。

Nomic.ai (GPT4All) Discord

  • 建议为 GPT4ALL 集成 vLLM Engine：一名成员建议将 vLLM engine 集成到 GPT4ALL 中，他们认为由于其在不同语言中拥有多样化的底层引擎，这可以使其提升为领先的开源项目。
    • 用户注意到 vLLM 支持广泛的 quantization types，这与 GPT4ALL 用户中普遍使用的 GGUFs 形成对比。
  • Windows vLLM Fork 出现：一名成员提到了一个 Windows vLLM fork，并对 GPT4ALL 将其作为第二个底层引擎的可能性表示热切期待。
    • 这一增加可以扩展 GPT4ALL 的功能，并为用户提供更广泛的选择。
  • 特斯拉搜索激怒互联网用户：一名成员对由于不必要的搜索而浪费在互联网上的时间表示沮丧，并以 Nikola Tesla 的发明为例。
    • 该用户对搜索结果表示不满，认为这些结果没有效率且耗时。

Cohere Discord

  • AI Engineer 加入 Cohere Discord：一位专业的 AI Engineer 和 Gen AI developer 加入了 Cohere 社区 Discord 服务器，并很高兴能为社区做出贡献。
    • 用户没有为该社区指定任何特定的目标或兴趣，但很高兴在未来参与讨论。
  • Cohere 社区欢迎新成员：Discord 服务器对新成员表示欢迎，鼓励他们介绍自己并分享背景细节。
    • 邀请新成员分享他们的 company/industry/university、当前项目、首选的 tech/tools 以及社区目标，以促进更好的联系感。

LLM Agents (Berkeley MOOC) Discord

  • 结业证书即将发放：成员预计在大约 2-3 周 内收到 LLM Agents Berkeley MOOC 的结业证书。
    • 这一时间表是为了配合课程作业的处理和验证。
  • 作业截止日期略有延长：LLM Agents Berkeley MOOC 的作业表单额外开放了 两天，以应对技术问题。
    • 这一延期让成员有更多时间提交他们的作品。

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

Codeium (Windsurf) Discord 没有新消息。如果该公会长时间没有动静，请告知我们，我们将将其移除。

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

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

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

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

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

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

Perplexity 中的图像生成、账单问题、Thread 丢失、Gemini 2.5 Pro、OpenAI vs Gemini vs Claude

  • 部分用户在 Perplexity 搜索中看到图像：正如这张截图所示，一些用户在他们的 Perplexity 搜索结果中看到了图像，而其他用户则没有，这种差异的原因尚不明确。
  • Perplexity Labs 的 Dashboard 生成问题：用户报告称 Perplexity Labs 遇到了一个 Bug，即 Dashboard 仅生成文本报告，且“App”标签页缺失，尽管使用了之前有效的 Prompt。
  • 账单代码故障阻碍 IT 公司：一名用户报告了在尝试使用 Business Fellowship 促销代码后出现的账单问题，导致发票逾期并可能产生职业影响，强调了对其超大型国际 IT 公司进行妥善处理的重要性。
    • 另一名用户提出通过 DM 提供帮助，其他人建议联系企业支持邮箱 enterprise@perplexity.ai 以解决问题。
  • Perplexity 丢失 Thread 的可靠性下降：用户报告随机丢失 Thread，甚至是他们没有删除的 Thread，有些在几天后仍未恢复，且问题持续超过 2 天仍没有妥善修复，这是一个令人担忧的问题。
    • 一些人发现 Android App 上仍保留有 Thread，而 Web 版本是导致问题的原因；一名用户建议由于不稳定性，应将其保存在记事本中。
  • Gemini 2.5 Pro 编程能力欠佳：一名用户发现新的 Gemini 2.5 Pro 在编程方面表现极差，特别是在运行 3D 太阳系的复杂模拟时，需要多次尝试才能获得一个尚可的版本。
    • 建议认为 Gemini 并非首选，并表示编程应使用 Opus pocus，别无他选。

Perplexity AI ▷ #sharing (6 条消息):

Tetrix App, Gemini Share, Michael Tait, Pakistan Deception, Dark Tetrad

  • Tetrix App 构建失败！：一名用户报告在使用 Perplexity AI 时，Tetrix app build 完全失败。
  • Gemini 分享艺术 AI：一名用户分享了一个指向 Gemini 展示艺术 AI的链接。
  • Michael Tait 指控：一名用户分享了关于针对 Michael Tait 指控的链接，可在此处查看。
  • 巴基斯坦的外交欺骗：一名用户分享了一个讨论巴基斯坦外交欺骗的 Perplexity AI 页面。
  • 黑暗四分体 (Dark Tetrad) 的数字放大：一名用户发布了一个关于黑暗四分体 (Dark Tetrad) 数字放大的 Perplexity AI 页面。

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

API 与在线搜索结果差异，Sonar 的推理力度 + 异步模式，学术模式，更丰富的引用，摄像头集成

  • **API 与在线结果的差异困扰用户：一位用户报告称，API** 有时无法检索到在线界面能稳定找到的信息（例如美国体育新闻），其失败率高达 50%，而在线界面的成功率为 100%。
    • 另一位用户对此表示赞同，指出 search API 的能力感觉只有在线界面的 50%，这导致他们不得不寻找其他 API 来获取足够的信息，才能让使用 API 变得有意义。
  • **Sonar 迎来升级：推理、异步、学术模式：Perplexity AI 宣布了重大升级，包括为 Sonar 深度研究（deep research）增加 **Reasoning effort（推理力度）+ 异步模式，在所有模型上推出学术模式，以及包含标题、URL 和日期的更丰富的引用信息。
  • **语音对话中集成摄像头的设想？：一位用户建议在语音聊天中加入摄像头集成**，同时也承认实现上存在挑战。
    • 另一位成员提到 Google 可能会将其集成到下一代 Pixel 手机中，因为 ChatGPT 已经具备了该功能。
  • **渴望代码形式化推理：一位用户请求增加代码形式化推理**功能，类似于 DeepSeek prover。
    • 他们期待着能将这一功能推向极致。
  • **Labs 生成的演示文稿外观优化：一位用户建议 **Labs 生成的演示文稿可以做得更精美一些，考虑到其整体良好的 UI/UX。
    • 这是在非常严肃的情况下提出的建议。

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

Gemini 2.5, Kingfall 模型, O3 Pro, 模型选择器, AI 基准测试

  • Google 内部构建了不同的 Gemini 2.5 模型：一位成员对 Google 的 Gemini 2.5 Flash 表示怀疑，认为其表现不佳，同时期待很快会发布新的 Gemini 模型。
    • 他们希望今天能发布 o3pro，并强调 Wolfram 的 LLM 基准测试项目对未来具有重要意义，并指出无论 Wolfram 做什么总是很出色 Wolfram 基准测试项目。
  • Kingfall 降临：关于 Kingfall 可能发布的讨论引发了兴奋，成员们讨论了它的特性和性能，共识认为它将解决代码编写问题。
    • 随后确认 Kingfall 已经发布但很快被撤下，引发了对其能力以及与其他模型关系的猜测。
  • Aider 显示 Gemini 2.5 Pro 表现起伏不定：成员们发现 Gemini 2.5 Pro 在 AIDER 上的得分高于其他模型，然而这一基准测试结果无法被证实。
    • 一位成员写道：如果你看 artificialanalysis.ai，那里没有任何一项显示新模型的得分更高，这肯定不对劲。
  • O3 Pro 准备发布：成员们密切关注，期待 O3 Pro 即将举行盛大的发布活动。
    • 一位成员写道 O3 Pro 正式发布了，但随后不久便承认这只是个传闻。
  • 模型选择器引发困惑与兴奋：围绕通过 AI Studio 上的模型选择器（Model Selector）访问 Kingfall 模型展开了讨论。
    • 用户分享了经验、提示词以及如何调整现有代码，并猜测模型选择器是否在正常工作。

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

LLMs Sycophancy, AI Verification, LLMs learning and data, Hallucinations, LLMs and unfalsifiable ideas

  • LLMs 可能被人类训练生成不可证伪的叙述：有假设认为，LLMs 正被非专业人士通过 in-context 训练来创建不可证伪的叙述；通过仅在人类足够了解的主题上纠正 LLM，LLM 学会了创建不可证伪的叙述/代码，因为这比创造有价值的东西更容易。
    • 这一假设可能符合 Eleuther 的对齐（alignment）和可解释性（interpretability）倾向，并且与服务器交互相关。
  • 在 MUD 中讨论 LLMs：讨论了将 LLM 放入 MUD/类文字冒险模拟环境中，让它“在侧面”与其交互，就像我们与现实交互一样。
    • 目标是避免它所处的“感官剥夺”境况，并通过与严酷现实的硬性交互来规范其交互。
  • LLMs 使用华丽且伪科学的语言：LLMs 倾向于使用华丽和伪科学的语言，这掩盖了空洞内容的虚伪性。
    • 这是一种将 LLM 生成的合成数据作为 LLM 输入的方式，这是一种已知的失效模式。
  • LLMs 中的幻觉（Hallucinations）与验证：LLMs 无法进行检查，即使它们声称可以，这可能是问题的关键所在。
    • 这是因为缺乏足够的人类干预和足够的 ground truth。
  • 关于 LLMs 与人交互的担忧：人们担心 LLMs 现在已成为传播无意错误信息的媒介。
    • 此外，通过更长的对话链，它几乎开始进行隐式优化，这可能会产生危险的结果。

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

Quantum Field Neural Networks (QFNN), Attention mechanisms, Potential data leak

  • 量子场神经网络 (QFNN) 算法亮相：一名成员分享了他们关于通用算法 Quantum Field Neural Networks (QFNN) 的研究演示，包含针对 NLP、期权交易和电化学反应的基础 Proof of Concepts (PoC)，可在 GitHub 上获取。
    • 该架构涉及一个由 phi 调制的 2D 圆柱体，Z 作为 qubit 旋转损失装置运行，旨在通过对昂贵的指数函数进行自然对数转换来最小化 GPU 使用率。
  • Attention 的起源令 ML 观察者感到困惑：成员们讨论了 attention mechanisms 的起源，一些人注意到 ML 社区对 Transformer 之前的机制（例如 Bahdanau attention）的认识似乎有限。
    • 一位成员表示 每当我的 feed 中提到 attention 的起源时，这个问题就会出现，而另一位成员则链接到了关于 linear attention 的 Schmidhuber 推文 和 Bluesky 帖子。
  • 预印本引发数据泄露怀疑：一位成员分享了 arXiv 上的预印本 链接，担心这可能是 data leak 的结果。

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

AI ROI Realization, AI Startup Bubble, Future of AI and Job Market, Non-LLM AI Ventures

  • AI ROI 预期减弱：一位成员对在 AI ROI 变现期到来时毕业进入就业市场表示担忧，认为大多数 AI 初创公司都是泡沫，原因是 CEO 缺乏 ML 技能，且 YCs 无法区分 ML 人才。
    • 另一位成员则安于从博士学位中赚取微薄收入，并指出即使发生崩盘，也意味着可以捡漏极其便宜的 GPU 并将其用于更有趣的工作。
  • LLMs 抢占了所有关注度（Suck air out of room）：一位成员希望新资金能流向非 LLM 重点的创投项目，并赞同 Chollet 的观点，即 LLMs 抢占了房间里所有的氧气。
    • 这一观点强调了在当前对大语言模型的关注之外，实现 AI 投资多样化的愿望。

Eleuther ▷ #interpretability-general (21 messages🔥):

Interpretability without teacher-forcing, RL with Teacher Forcing, Chat templates for Instruction Tuned Models, Token Embeddings

  • 不使用 Teacher Forcing 的可解释性完整性受到挑战：成员们讨论了在 AI 训练中不使用 Teacher Forcing 是否能保持可解释性的完整性，但指出目前还没有任何不使用 Teacher Forcing 且能实现合理规模扩展的生成式 AI 训练。
    • 一位成员澄清了他们的具体兴趣是先进行不带 Teacher Forcing 的训练，然后使用带 Teacher Forcing 的 RL 进行微调，以提高可解释性。
  • 指令微调模型是否应用 Chat Template？：一位成员询问关于为指令微调模型使用 apply_chat_template() 函数的问题，特别是在进行转向（steering）和 Embedding 分析时，因为特殊 Token 会使 Embedding 的访问变得复杂。
    • 成员们建议，为了让指令微调模型正常工作并避免分布外（out-of-distribution）行为，使用 Chat Template 是必要的，即使简单的提问在不使用它的情况下仍能得到不错的回答。
  • 使用 Chat Template 进行 Token Embedding 分析：一位成员担心 apply_chat_template() 添加的特殊 Token 会使 Token Embedding 分析复杂化，特别是像 Qwen 中用于换行的 “Ċ” 这种模型特定的 Token。
    • 一位成员建议考虑所添加的 Chat Template Token 的固定数量，因为每个模型的 Chat Template 都是已知的，这简化了所需的代码调整。

Eleuther ▷ #lm-thunderdome (2 messages):

Reasoning Model Evaluations, Answer Extractions, LLM as Judge, MMLU Flan Few-Shot

  • 关于推理模型评估中答案提取的辩论：一位成员询问了推理模型评估中答案提取的标准方法，指出许多论文使用 lm_eval 的默认 Prompt，这些 Prompt 通常缺乏指定的输出格式，导致 regex 匹配失败。
    • 该成员提议指定输出格式或使用 LLM as a judge，但想知道目前公认的研究实践是什么。
  • 为什么 MMLU Flan Few-Shot 仅使用四个示例：一位成员询问为什么 mmlu_flan_fewshot_cot 默认使用 4 个 few-shot 示例，质疑大多数实现通常不是使用 5 个示例吗。
    • 未给出解释或回答。

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

Claude Code vs Cursor, MCP as backend replacement, Cursor 1.0, Gemini models, Cursor documentation

  • Cursor 1.0 发布，社区反应不一：Cursor 发布了其 IDE 的 1.0 版本，但一些用户觉得它仍处于早期 beta 阶段，报告了更新后基本功能出现的问题。
    • 一位用户表示：“我放下 Cursor 去做了一些体力活，换了换脑子后，我得出的结论是，他们称之为 1.0 是心血来潮，而不是因为 1.0 是一个准备就绪的版本。”
  • Claude Code 在 Cursor 社区获得关注：成员们报告称 Claude Code 在编程方面明显优于其他模型，尤其是在最近的 Cursor 1.0 更新之后，一位用户表示它“完全改变了我对用于编程的 LLM 的看法，哈哈”。
    • 另一位用户指出，凭借 $20/月的 Claude Pro 计划，其质量可与 Cursor 媲美，且成本更低。
  • 对 MAX 定价和用量的担忧：用户对 MAX 模式的成本表示担忧，指出基本的后续问题会迅速耗尽请求限制，强调需要更清晰的成本显示。
    • 大家的共识正在形成，正如另一位成员所说，“如果云端 Agent 会让普通人运行成本飙升，那它就没有意义”，并特别提到新的后台 Agent 功能仅支持 MAX。
  • Gemini 模型在 Cursor 中的困境和工具问题：用户在 Cursor 中遇到了 Gemini 模型的连接失败和速度变慢问题，尤其是在 1.0 更新之后。
    • 一位用户报告称“今天连接 Gemini 的失败次数多得惊人”，而另一位用户指出“它似乎很不稳定，我发给 Sonnet 4 的 Prompt 成功了，但下一个就没反应了”。
  • 用户认为 MCP 不应取代传统后端：成员们警告不要使用 MCP (Multi-Craft Plugin) 替代传统后端，因为存在潜在的漏洞和不稳定性。
    • 正如一位用户所说，“这是在构建有史以来最脆弱、最不稳定的系统和后端”，同时承认 MCP 可能作为 CDN 使用。

Cursor Community ▷ #background-agents (42 messages🔥):

Background Agents, Cursor GitHub, Background Agent PRs, Mono Repo setup, Background Agents Slack Bot

  • Background Agents 无法启动，需要升级！：多名用户遇到问题，要求他们升级到 Cursor 1.0.0 或更高版本才能启动新的 Background Agents，错误提示为：Upgrade to Cursor version 1.0.0 or later to start new background agents.
    • 一位用户建议使用 Cursor: Start Background Agent Setup 工具，这为他们解决了问题。
  • GitHub 权限导致 Background Agent 设置问题：用户在 Background Agents 配置中将 Cursor 连接到 GitHub 时遇到问题，导致 Access Denied 错误，且即使重新安装了 Cursor GitHub 应用，也无法获取代码库的安装访问密钥。
    • 一种解决方案包括删除本地 Repo 并重新克隆，然后重新启动 Background Agent 设置；另一位用户则重建了他们的基础 Background Container 快照。
  • Linear Agent PR 工作流即将推出？：一位用户提议了一种工作流，即 Background Agent 根据 Linear 中的 Issue 执行任务并开启 PR，并请求能够以编程方式触发 Background Agents 以进行自动化实现和审查。
    • 这引发了对 Linear Agent 的热情，它可以像在 Slack 中一样被提及，并具备自动开启 Pull Request 的功能。
  • Background/Asynchronous Agents 详解：一位用户询问了 Background/Asynchronous Agents 的区别和用途，引发了关于它们如何通过并行运行后端任务、API 设置和单元测试来实现 Vibe Coding 的讨论，而用户则可以专注于前端实现。
    • 另一位用户表示，当他们不在工作时，Cursor 会在他们离开期间继续推进进度。然后他们可以回来查看，根据需要通过在 Markdown 中留下 Todo 列表等方式让工作重回正轨。
  • Slack Bot 仍未更新！：用户正在询问 1.0 发布公告中承诺的 Slack Bot 的更新情况，因为他们找不到它。
    • 论坛版主链接到了 Background Agent 文档，但其中并未提及任何关于 Slack 集成的内容。

Cursor Community ▷ #announcements (1 messages):

Cursor 1.0 release, code review features, background tasks

  • Cursor 1.0 发布，支持 Code Review：Cursor 1.0 现已发布，具有增强的 Code Review 能力、记忆错误的能力以及管理大量 Background Tasks 的能力。
    • 所有更新的详细信息可在 Changelog 中查看。
  • Cursor 1.0 新视频：随 Cursor 1.0 发布同步上传了一个视频。
    • 视频可以在这里找到。

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

Unsloth Llama.cpp 视觉推理，GRPO 模型检查点，学习率与 SFT，使用 Gemini 2.5 生成合成数据集，Deepseek R1 Qwen mergekit

  • Mistral-Small-3.1 视觉推理在 Llama.cpp 中的故障排除：一位用户寻求关于使用 llama.cpp 对 unsloth/Mistral-Small-3.1-24B-Instruct-2503-GGUF 模型进行推理的指导，包括如何在提示词中发送图像。
    • 在尝试发送带有图像（包括 base64 编码和 .png 格式）的提示词失败后，另一位用户建议查看 llama.cpp 文档或咨询 llama.cpp 社区以寻求帮助，而另一位用户则建议使用 llama-mtmd-cli 构建目标。
  • 合成数据节省 Google 信用额度：一位用户正在使用 Gemini 2.5 Pro 生成合成数据集，以利用剩余的 Google Cloud 信用额度。
    • 有人指出 VS Code 的 Agent 扩展会迅速耗尽额度，昨天不小心花费了 17 美元，建议使用 deepseek-chat-v3 以获得更便宜、更好的推理能力，并参考了这张图片中的图像质量。
  • 用户讨论 Unsloth 微调 Notebook 及近期问题：用户讨论了微调 Notebook，包括一个潜在问题：Qwen3-base notebook 可能正在训练 Qwen3 instruct 版本，并分享了 Unsloth notebooks 仓库。
    • 用户获得了正确 Notebook 的链接，并针对旧版本和兼容性问题（需要 transformers==4.48）进行了故障排除，最终通过在 Notebook 中设置 use_exact_model_name = True 修复。
  • Docker 关注 Docker Hub 上的 Unsloth 模型分发：Docker 的 AI Runtime 团队表示有兴趣在 Docker Hub 上发布 Unsloth 模型，建议使用 docker model package 命令将 GGUF 文件打包为 OCI Artifacts。
    • Unsloth 团队对合作持开放态度，但对自动上传其所有模型表示担忧，并询问了类似于 Modelscope 的自动化功能。
  • Homunculus-12B 模型无审查且表现出色！：成员们吹捧了蒸馏模型 Homunculus-12B，该模型从 Qwen3-235B 蒸馏到 Mistral-Nemo 骨干网络上，无审查且能简单地解释重力。
    • 该模型保留了 Qwen 的两种交互模式——/think（深思熟虑的思维链）和 /nothink（简洁回答）——同时可以在单个消费级 GPU 上运行，目前已存在 GGUF 版本。

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

QLoRA 指令微调经验，针对多样化语言预训练 Gemma，用于 LLM 推理的 Triton 学习

  • QLoRA 指令微调挑战浮现：一位成员询问了其他人使用 QLoRA 进行指令微调模型的经验，指出他们的模型在小数据集上微调后可以回答问题，但无法正确结束响应。
    • 他们寻求关于成功的数据集和 QLoRA 微调策略的见解。
  • 针对多样化网络语言训练 Gemma：一位成员的目标是预训练并微调一个模型（可能是 Gemma 3），使其能够与来自现实世界在线示例的多样化语言进行交互。其利用了来自一个小型政治论坛、跨越 18 年的 150 万条论坛帖子，以及来自古典时代、波斯、穆斯林学者和东方哲学的资料集。
    • 目标是创建一个基于逻辑、修辞和框架的基础模型，随后在互联网数据集上进行微调，以复制 IT 模型的功能，同时避免对齐训练。
  • 使用 Triton 加速 LLM 推理：一位 MLE 有兴趣通过学习 Triton 并为稀疏/量化 LLM 编写优化算子（kernels）来加速 LLM 推理。
    • 他们征求了关于高效学习 Triton 的建议，分享了经验和当前的痛点，并考虑直接为 Triton 做出贡献。

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

Orpheus-3b 模型新语言训练问题, Deepthink R2 模型, DeepSeek-R1-0528 微调期间的内存占用, VLM 指令微调, unsloth 库导入错误

  • Orpheus-3b 模型学习了新语言但遗忘了情感：一位用户通过将训练数据与基础英语混合，在 unsloth/orpheus-3b 模型上训练新语言，但发现模型遗忘了原说话者的一些情感和声音。
    • 另一位成员表示这是正常现象，模型针对你的数据进行了专门化，并遗忘了旧数据。
  • DeepThink R2 模型发布日期仍在未来：一位用户询问如何获取 DeepThink R2 模型，但被告知该模型甚至还没发布。
  • DeepSeek-R1-0528 在微调期间面临 OOM 问题：一位用户在尝试使用 8 张 H100 GPU 和 bnb 4bit 量化微调 DeepSeek-R1-0528 时遇到了 OOM 错误，怀疑模型在加载 Checkpoint 之前没有进行空初始化。
    • 他们理想中希望在加载期间每张 GPU 仅消耗约 40GB 显存。
  • 用户目标是在不使用 Chat Template 的情况下微调 VLM：一位用户希望使用 Unsloth 微调视觉语言模型 (VLM)，避免使用 apply_chat_template，而是使用预格式化的提示词。
    • 另一位成员建议用户坚持使用该模型最初微调时所用的 Chat Template。
  • Unsloth 库导入错误困扰 Colab 用户：多位用户报告了 Colab Notebook 中 Unsloth 库的导入错误，例如 from unsloth import FastLanguageModel 或 from unsloth.dataprep import SyntheticDataKit，但一位成员表示该 Notebook 在免费的 T4 实例上加载正常。
    • 一位成员建议确保始终最先导入 unsloth 并重启会话。

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

Qwen 2.5 SFT, 图像分析

  • Qwen 2.5 SFT 演示：一位用户分享了一个 GIF，展示了 Qwen 2.5 SFT 的图像分析功能。
  • 图像分析的未来：另一位用户分享了一个 GIF 并评论道 你可以预见这一切的发展方向，并附带了图像链接。

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

OpenRouter RSS 订阅源, 模型公告

  • OpenRouter 推出模型 RSS 订阅源：OpenRouter 现在提供用于实时模型更新的 RSS 订阅源，可在此处访问：here。
  • 随时掌握 OpenRouter 模型公告：新的 RSS 订阅源确保用户能够及时了解 OpenRouter 上可用的最新模型。

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

使用 OpenRouter LLM 后端的 iOS 应用, 商业领域的电子表格, Personality.gg

  • iOS 应用集成 OpenRouter 作为 LLM 后端：一位成员计划通过 TestFlight 发布一款 iOS 应用，利用 OpenRouter 作为 LLM 后端来处理角色卡。
    • 目前剩下的主要挑战是消息格式化，并计划在未来整合更多客户端。
  • 电子表格技能是产品采用的关键：一位成员强调了电子表格在商业世界中的重要性，强调熟悉电子表格可以降低新产品的准入门槛。
    • 降低产品的准入门槛是你所能做的最好的事情。
  • 面向 Gooners 的 Personality.gg：一位成员分享了 Personality.gg 的链接。
    • 该成员没有详细说明，仅澄清 for the gooners。

OpenRouter (Alex Atallah) ▷ #general (253 条消息🔥🔥):

OpenRouter API 请求限制，角色扮演的角色卡，Gemini 2.5，OpenAI 日志记录，Gemini Pro vs Flash

  • OpenRouter API 请求限制已明确：免费 OpenRouter 模型具有 API 请求限制：充值少于 $10 的用户每天限制 50 次请求，充值超过 $10 的用户每天限制 1000 次请求，该限制适用于所有免费模型。
    • 一位用户澄清道：“所以如果你向 DeepSeek v3 0324（免费版）发送了 5 条消息，那么 DeepSeek r1（免费版）就只剩下 995 次额度了”。
  • SillyTavern 是角色扮演资源的宝库：一位用户建议将 SillyTavern 作为寻找“角色卡（character cards）”的资源，用于在 OpenRouter 上进行角色扮演实验。
  • Gemini 2.5 Flash 模型产生无限重复：一位用户报告称，Gemini 2.5 Flash 中的结构化响应返回了相同值的无限重复；例如 {"appereance" : "red-rimmed eyes, red-rimmed eyes, red-rimmed eyes..."}。
    • 另一位用户建议该用户向集成了 OpenRouter 的 Chatwise MCP 平台寻求支持，以防集成包需要更新。
  • 数据日志记录问题得到回应：在一位用户分享了一篇关于 OpenAI 被迫记录用户输出的文章后，有人询问当“Enable training and logging”关闭时，OpenRouter 上的每个 OpenAI 模型是否都应该显示红色气泡警告。
    • OpenRouter 确认他们没有做到零数据保留，并正在请求 OpenAI 再次检查，鉴于新的法院要求，是否仍可以启用该设置。
  • Kingfall 编程神兽的起落：用户讨论了 Reddit 上提到的 Kingfall 模型，有人称其为“编程神兽”，且比 Gemini 2.5 Pro “更好”。
    • 一些用户表示它已在 Google AI Studio 上线，但其他人报告称它已被移除，还有人声称它“甚至可能与 2.5 Pro 的演示是同一个 OP（发帖人）”。

HuggingFace ▷ #general (150 messages🔥🔥):

IBM 的 Responsible Prompting API、LLM 输出的共识验证、Windows 上的 Hugging Face Transformers 安装、法国 AI 公司的技术护城河缺失、选择 LLM 模型

  • IBM 的 Responsible Prompting API 建议提示词微调：IBM Research 正在开发 Responsible Prompting API，这是一个在推理前建议 提示词微调（prompt tweaks） 的系统，旨在使 LLM 输出 更加负责任、高效且准确，详见 这篇论文。
    • 在 CHI’25 上展示的一项用户研究为改进该系统提供了反馈，目前在 Hugging Face 上已提供 demo。
  • 受区块链启发的验证增强了 LLM 的可靠性：一篇新的概念论文《LLM 输出的共识验证：将受区块链启发的模型应用于 AI 可靠性》（Consensus Validation for LLM Outputs: Applying Blockchain-Inspired Models to AI Reliability）探讨了将 区块链共识机制 应用于 LLM 输出，以提高可靠性和可信度。
    • 该论文建议将其应用于 AI Agent、法律/医疗工具以及 AI 对齐（AI alignment），可在此处阅读 全文。
  • Transformer 安装问题难倒了新手用户：一位成员在 Windows 原生环境下安装 Hugging Face Transformers 时遇到问题，并提交了一个 GitHub issue 详细说明了其步骤，包括 fork 仓库、克隆仓库、创建虚拟环境以及运行 pip install -e ".[dev]"。
    • 另一位使用 Python 3.10 的成员建议检查包冲突并确保使用了虚拟环境。
  • 法国 AI 初创公司缺乏技术护城河：一位成员声称，融资超过 4 亿欧元 的法国 AI 公司 hcompany.ai 缺乏技术护城河。
    • 他们声称该业务很容易被复制，且该公司由政府资助的模型 Lucie-7B 表现糟糕，甚至存在种族歧视，导致其 API 被撤下，具体可见 此处。
  • Gemini 2.5 Pro 成为新的 LLM 宠儿：成员们讨论了 LLM 的选择，由于 Gemini 2.5 Pro 的性能与 GPT-4o 相当且价格更便宜，一些人开始转向使用它；但对于本地运行，Deepseek 可能是最好的，但大多数人无法运行它，因为它拥有 671b 参数。
    • 对于本地使用，如果 vram 允许，推荐使用 Deepseek，或者 Mistral small 3.1，目前还有一个 排行榜，各模型正在为了榜首位置激烈竞争。

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

欺诈检测资源、金融交易安全

  • 用户寻求欺诈检测资源：一位成员正尝试学习 金融交易中的欺诈检测。
    • 该成员询问是否有人拥有相关主题的资源。
  • 金融交易安全教育：学习如何保障 金融交易 安全的方法引起了人们的兴趣。
    • 这包括理解检测和预防欺诈活动的细微差别。

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

Claude Desktop MCP Playground、Keras 并行训练工具

  • **Claude Desktop 迎来带 GUI 的 MCP Playground！：一位 HF 社区成员发布了其 **MCP Playground 的重大更新，增加了 GUI 并运行了 40 多个操作服务器，以简化向 Claude Desktop 添加强大的 MCP 服务器的过程，无需担心配置烦恼。
    • 他们正在寻找开发者和用户来测试该 仓库 并提供反馈。
  • 并行寻找 **Keras 模型！：创建了一个轻量级工具，用于并行训练多个 **Keras 模型，并比较它们的最终损失（loss）和最后一个 epoch 的运行时间。

HuggingFace ▷ #reading-group (1 messages):

shadow_lilac: 说实话，读书小组看起来真的很棒，一旦有了新日程，我很乐意参加。

HuggingFace ▷ #NLP (51 messages🔥):

Windows 上的 NLP，语义相似度，BERT 嵌入

  • 在 Windows 上原生进行 NLP 工作？：一些成员讨论了在 Windows 上原生进行 NLP 工作（不使用 WSL、双系统或虚拟机）。
    • 一位成员表示这虽然困难但可行，但由于头疼和性能问题，他们最终放弃并转向了 WSL，随后又改用双系统。
  • 为 Windows Subsystem for Linux 升级内存：一位运行 WSL 的成员遇到了 Jupyter kernel 因内存问题崩溃的情况，当时仅使用了 8GB 内存并将 7GB 分配给了 WSL。
    • 另一位成员建议至少升级到 16GB，不过 32GB 对于处理现代操作系统和浏览器的内存占用会更具前瞻性。
  • 使用 BERT 的语义相似度工具：一位成员询问用于比较两个段落之间语义相似度的 GitHub 仓库或 HF Space 应用。
    • 另一位成员推荐了配合 sentence-transformers 库使用的 Sentence-BERT，并提供了 仓库链接。

HuggingFace ▷ #smol-course (2 messages):

Agents 课程，证书截止日期

  • Agents 课程截止日期延长：正如 Discord 频道 中提到的，Agents 课程的截止日期已延长至 2025年7月1日。
    • 一位用户在开始课程时询问了证书资格，因为他注意到之前标注的截止日期是 2025年5月1日。
  • 关于 Agents 课程日期的困惑已解决：用户对 Agents 课程完成和证书资格的冲突日期表示困惑。
    • 官方提供了澄清，指出了包含更新信息（延长截止日期）的 Discord 频道。

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

企鹅 YouTube 问题，向 Agent 传递音频，在 Gemini 中使用 smolagents，课程报名截止日期

  • 发现企鹅 YouTube！：一位成员询问如何解决企鹅 YouTube 问题，另一位成员建议查看 YouTube 视频工具。
  • 将音频传递给 Agent！：一位成员询问是否可以使用 smolagents 向 Agent 传递音频（假设模型支持）。
    • 多位成员表示这是可行的。
  • Gemini Flash 表现优异！：Gemini 2.0 Flash 与 smolagents [openai] 和 ‘openaiservermodel’ 配合良好，在免费层级提供 1500 次调用/天，并在使用基础网页/Wikipedia 搜索工具时获得了 50pt。
    • 增加延迟有助于避免请求限制（大约 每分钟 15 次请求）。
  • 课程报名还不晚！：一位成员询问现在报名课程是否太晚。
    • 另一位成员澄清说，旁听（auditing）始终可行，而获得两份证书的截止日期是 2025年7月1日。

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

Codex CLI API, Adobe Firefly, O3 Pro 模式, Claude Max 对比 ChatGPT Pro, ChatGPT Connectors

  • OpenAI Pro 订阅：Codex CLI API 仍然缺失：一位成员对 Codex CLI API 仍未包含在 Pro 订阅中表示失望，认为 Pro 订阅应该包含其他计划的所有功能。
  • Adobe Firefly 落后于基于 Transformer 的模型：一位成员感叹 Adobe Firefly 仍然基于扩散模型（diffusion based），没有升级到像 4o 这样基于 Transformer 的模型，以实现更好的生成式填充（generative fill）。
  • 用户焦急等待 o3 Pro 模式：多位成员正急切等待 O3 Pro 模式 的发布，其中一位表示一旦获得权限就准备立即接入系统。
  • Claude Max 的超高价值对比 ChatGPT Pro：一位成员表示，200 美元的 Claude Max 是一个极划算的交易，因为在 12 天内，他们使用的 API Token 等值于 900 美元，远超 ChatGPT Pro。
  • 关于 Connector 的推测以及 Claude 的自定义 MCP：一些成员讨论了最近发布的 ChatGPT Connectors 以及它们是否能解决上下文窗口（context window）问题；而另一些成员提到 Claude 在其网站上为 Pro 用户提供了一种 Connector 版本，即运行在服务器上的自定义 MCP，可以执行任何操作，如发送 Discord 消息或使用 GitHub。

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

住房项目中的 AI，具备 AI 能力的软件与业务开发人员

  • 建筑师探索 AI 在住房设计中的应用：一位来自巴西的建筑师正在探索在一个拥有 1,500 个地块 的住房项目中使用 AI 和参数化设计 (parametric design)。
    • 他有兴趣向社区学习并开展合作。
  • 软件开发人员提供 OpenAI 协助：一位具备 AI 能力的软件与业务开发人员提供了关于 OpenAI 产品 的协助。
    • 他们邀请用户提出问题，并为咨询选择合适的论坛。

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

D&D 冒险生成，LLM Prompt 流水线，AI 内容中的一致语调，AI 作为 NA 会议的赞助人/导师，Prompt 版本追踪与评估

  • 利用 LLM 创作一致的 D&D 冒险：一位成员正在开发一个副业项目，该项目使用结构化的 Prompt 链来生成 D&D 风格的单次冒险（one-shot adventures），涵盖背景设置、地点、前提和冲突。
    • 他们正在探索是使用专门的编辑环节来确保 语调一致性 (tone consistency)，还是在每个 Prompt 中包含一段共享的 语调描述，并寻求类似内容生成流水线的资源。
  • 探索 AI 作为 NA 会议的虚拟赞助人/导师：一位成员寻求创建一个 Prompt，使聊天机器人能充当 NA 会议的赞助人（Sponsor），在找到真人赞助人之前提供支持。
    • 另一位成员建议像对真人说话一样输入请求，详细说明在缺乏真人赞助人的情况下对指导和支持的需求，并强调了模型处理对话和细微交互的能力。
  • Y Combinator 播客聚焦 Prompting 见解：一位成员收听了最近关于 Prompting 的 Y Combinator 播客/视频，并分享了关于利用评估机制和领域专家纠正来提升 AI 在业务中表现的见解。
    • 他们提议建立一个反馈循环，让 AI 输出带有理由的多个选项，利用所选选项的评论来优化原始 Prompt。
  • Veo3 实现一致的角色和音频：一位成员使用 Veo3 在 一致的角色和音频 方面取得了 重大成果。
    • 他们请求发布展示该成果的视频，但目前尚不清楚是否获得了许可。
  • 深入探讨 Prompt Engineering 的核心：一位成员分享了他们简单但有效的 Prompt Engineering 方法：使用熟悉的语言，理解期望的输出，清晰地解释需求，并仔细核实 AI 的输出。
    • 他们强调了事实核查的重要性，特别是针对数学、来源、代码以及容易产生幻觉（hallucination）的细节。

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

D&D 冒险模块生成、Prompt 流水线中的一致语气、Prompt 版本追踪与评估、NA 会议的 AI 赞助人、Veo3 结果

  • 利用 AI 制作 D&D One-Shots：一位成员正在开发一个 AI 流水线，用于生成 D&D 风格的 One-Shot 冒险，重点在于灵感简报而非完整的模块。
    • 他们正在探索是使用专门的编辑环节来保证语气一致性，还是在每个 Prompt 中包含一个共享的“语气段落”，并寻求有关内容生成流水线的资源。
  • 微调 AI 语气：一些成员建议在 AI 的输入或输出端添加语气段落，通过重复来增强稳定性，但这可能对用户不够友好。
    • 其他人指出，让 AI 记住故事上下文、逻辑推进、遵循 D&D 规则以及记住角色也至关重要。
  • 关于 Prompt 评估的 Y-Combinator 播客：一位成员推荐了最近的一期 关于 Prompting 的 Y-Combinator 播客/视频，该视频强调了评估机制和领域专家的修正对于在业务中创建强大的 AI 的重要性。
    • 该成员建议建立一个反馈循环，通过评论和理由来改进原始 Prompt。
  • Prompt Engineering 基础：成员们讨论了基础的 Prompt Engineering，包括选择一种你熟悉的语言、准确理解你希望从 AI 那里得到什么、准确地解释它，并仔细检查输出（包括事实核查）。
    • 一位成员询问如何从模型中获得更强的数学/科学领域结果，并询问需要达到什么水平。
  • AI 作为 NA 会议的赞助人：一位成员希望创建一个 Prompt，让 Chatbot 充当赞助人（Sponsor），类似于参加 NA 会议（戒毒匿名会）时可能拥有的导师，直到他们能在现实中找到一位。
    • 一位成员建议在 Prompt 中将模型视为真人，告诉它你对模型操作还比较陌生，以及你希望模型能做些什么。

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

Qwen 2 35B vs DS R1.5、Gemini 2.5 Pro 发布日期预测、Gemini 2.5 Pro 聊天模式降级、Aider Webapp IDE、Gemini 2.5 Pro Aider Polyglot 基准测试

  • Qwen 和 DS 落后于 Gemini 和 Claude：据报道，Qwen 2 35B 和 DS R1.5 的表现都逊于 Claude 和 Gemini，在一些用户测试中，Qwen 略优于 DS。
    • 一位用户注意到，这两个模型都花了大约 4 分钟 才搞清楚如何画一个篮球。
  • Gemini 2.5 Pro 发布日期推测升温：用户们推测了 Gemini 2.5 Pro 的发布日期，参考了 6 月 5 日 的标签和内部基准测试结果，而一些人根据历史模式预测在 6 月 10 日 左右发布。
    • 一位用户指出，Google 历史上习惯在周二进行软发布（Soft Launch），并在周三发布博客文章或 GA（正式发布）公告。
  • Gemini 2.5 Pro 聊天模式质量下降：一位用户报告称，Gemini 2.5 Pro 的聊天模式现在会复制整个需要修改的文件，而不是以 diff 格式输出修改部分，导致聊天模式无法使用。
    • 该用户补充说，他们现在只能在代码模式下进行 One-shot。
  • 以 Aider 为核心的 Webapp IDE 出现：一位用户分享了一个链接，指向一个用于 Alpha 测试的以 Aider 为核心的 Webapp IDE。
    • 它被描述为一个以 Aider 为核心的 Webapp IDE。
  • Gemini Polyglot 基准测试分数泄露：用户讨论了一项泄露的测试，显示 Gemini 2.5 Pro 在 Aider Polyglot 基准测试中达到了 86%，这表明该基准测试可能已经过拟合或不再具有参考价值。
    • 一位用户建议创建一个新的 AI Vibe Code 基准测试，另一位用户提到 Gemini 2.5 Pro 在 Humanity’s Last Exam 上也有所进步。

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

Figma MCP 在 Claude Code 上的应用，Aider vs Cursor，Gemini STT 与语音转文字工作流，Superwhisper 与 Wispr Flow，Aider 的开发风格

  • 用户讨论 Aider 与 Cursor 在开发中的优劣：一位用户对从 Aider 切换到 Cursor 的用户进行了调研，指出 Cursor 感觉更慢，且其 Agent 模式会变得“失控”，必须加以约束。
    • 该用户提到，与 Aider 相比，在 Cursor 中同时运行多个 AI 编辑进程进行快速迭代（blitzes）并不那么直观。
  • Aider 的开发风格：一位用户表示，Aider 的方法适合一种以“谨慎、深思熟虑的 Prompting”、终端驱动的工作流以及通过分支实现回滚到已知良好状态为特征的开发风格。
    • 他们还提到对 Cursor 用户那种“乱投医”（fling stuff at the wall）的氛围感到反感，尽管他们正在尝试使用 Zed 来拓展思路。
  • Gemini STT 和语音转文字工作流：一名成员询问了关于 Gemini STT 以及增加更多语音转文字工作流的问题，并对自定义术语表示感兴趣。
    • 他们明确表示更倾向于使用 superwhisper，并尝试过 iOS 版的 Wispr Flow。
  • 在 Claude Code 上安装 Figma MCP：一位用户询问如何在 Claude Code 上安装 Figma MCP，具体询问了需要运行的命令。

GPU MODE ▷ #general (4 messages):

硬件感知优化，ML 编译器，PyTorch CUDA，CUTLASS/CUB/cuDNN，Triton

  • 建议 CUDA matmul 练习项目：一位成员建议从零开始编写一个 CUDA matmul，使其在 bf16 或 fp16 下使用 Tensor Cores 达到 cuBLAS 85% 的吞吐量，这是一个非常棒的学习练习。
  • 建议亲自动手实践：一位成员建议对你的工作负载进行 Profiling，以识别易于优化的“低垂果实”（low-hanging fruits）。
    • 例子可能包括使用简单 for 循环且无并发的内层循环。否则，你可能只需从现有的优化方案中学习，以确定哪些是最相关的技能。
  • 渴望向分布式 GPU 专家请教：一位成员请求与有 64+ 规模集群分布式 GPU 训练经验的人交流或获取建议。
    • 他们正在寻求见解，因为其同事都是对该领域不感兴趣的物理学家。

GPU MODE ▷ #triton (1 messages):

Megakernel，全模型 Kernel，KernelLLM，KernelLLM 前来救场！

  • Megakernel 热潮显现：一位成员询问在 Triton 中是否存在针对 LLaMA 等流行架构的 megakernel 或全模型 Kernel 示例。
    • 在没有找到相关示例后，他们考虑自己编写一个，并可能借助 KernelLLM 的帮助。
  • KernelLLM 前来救场：该成员正计划编写一个 megakernel/全模型 Kernel。
    • 他们计划使用 KernelLLM 来提供协助。

GPU MODE ▷ #cuda (7 messages):

CTA 数据传输，Blackwell TF32 Block Scaling，GMEM 合并访问

  • 绕过全局内存的 CTA 通信？：一位成员询问是否可以在不使用全局内存（Global Memory）的情况下直接在 CTA 之间传输数据。
    • 另一位成员指出，从 Compute Capability 9.0 开始，可以在线程块集群（CGA）内访问共享内存，尽管这比本地共享内存慢，且仅在同一个 GPC 内的 SM 之间有效。
  • 对 Blackwell 的 TF32 Scaling 的思考：讨论集中在 Blackwell 中 TF32 类型的 Block Scaling，并将其与 sm80 和 sm90 进行对比，在后两者中，一个 Tensor 操作数可以驻留在寄存器中。
    • 理论上，在 Blackwell 中，两个 Tensor 操作数都驻留在 smem 中，为了高效利用 Tensor 操作，可能需要为每个通道暂存一个 Tensor 的副本到 rmem 中，进行 Scaling，然后再将其拷贝回 smem。
  • GMEM 合并访问（Coalescing）性能难题：一位成员实现了两个 Kernel 来演示 GMEM 合并访问，第一个在 C 矩阵上平铺 Warpsize x Warpsize，第二个在每一行中平铺相同尺寸的条带。
    • 尽管两个 Kernel 在打印 x,y 映射时都显示了合并的 Warp，但第一个 Kernel 的速度几乎快了一倍，这引发了关于输出矩阵 C 的平铺/条带化方式是否影响性能的疑问。

GPU MODE ▷ #torch (8 messages🔥):

Torch Compile, AITemplate 状态, Tensor 常量包装

  • Tensor 包装引发重编译的困扰：将 constants 包装在 Tensor 中对于防止重编译是必要的，尽管 cpp interface 会自动将它们转换回来。
    • 一位成员注意到 ___as_tensor(alpha).item() == 0.5 会触发重编译，并指出这种必要性并 不直观。
  • Torch Compile vs. AITemplate：现代对决：AITemplate 处于维护模式，因此 torch.compile 是活跃开发的推荐选择。
    • 对于 C++ 运行时替代方案，由于 AIT 缺乏活跃维护，建议选择 AOTInductor 而非 AITemplate。
  • Torch Compile 性能超越 AITemplate：Torch.compile 现在提供与 AITemplate 相当甚至更好的性能，巩固了其作为首选工具的地位。
    • 一位成员表示 torch compile 将比 AITemplate 具有更好的性能。

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

并行 Keras 模型, Experience Replay 池, 扩展智能

  • Keras 模型实现并行：一个用于并行训练多个 Keras models 并比较其最终 loss 和最后一个 epoch 时间的轻量级工具现已发布：parallel_finder。
  • Experience Replay 获得提升：一个新的 Python class 提供了一个基于多进程的 Pool，用于在强化学习中高效收集和管理 experience replay data：Pool。
  • 扩展智能博客文章：分享了一篇关于 scaling intelligence 的博客文章：real.optimus.prime。

GPU MODE ▷ #beginner (2 messages):

GPU 访问成本, ECE408 课程

  • 推荐 ECE408 课程用于 GPU 学习：一位成员建议从 ECE408 lectures 开始学习更多关于 GPUs 的知识。
    • 同一位成员尝试观看这些课程，但发现 音频质量很差。
  • B200/H200/H100 GPU 访问成本：一位成员对访问 B200/H200/H100 GPUs 的 最便宜方式 感到好奇。
    • 未收到回复。

GPU MODE ▷ #jax (1 messages):

blueredblue: How does ffi_call work with pmap, will one kernel get launched per device?

GPU MODE ▷ #torchao (1 messages):

drisspg: I’ll do a review today

GPU MODE ▷ #off-topic (1 messages):

TiKZ, GIF

  • GIF 被识别为 TiKZ：一位成员识别出一个由多张图像组成的 GIF。
    • 该成员推测它是使用 TiKZ 创建的，这是一个用于以编程方式创建图形的 LaTeX 宏包。
  • TiKZ 用于创建 GIF：TiKZ 是一个可以通过代码生成图像的工具。
    • 这些图像可以融合在一起创建 GIF。

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

GTC 巴黎, CUDA C++ 工作坊, 与专家交流

  • GTC 巴黎前往 VivaTech！：GTC Paris 定于 6 月 10 日至 12 日 在 VivaTech 举行，活动期间将有两个 CUDA 亮点：GTC Paris。
  • CUDA C++ 工作坊提供实战培训：6 月 10 日 的 CUDA C++ Workshop 提供为期全天的现代 CUDA、优化和调试实战培训，请立即报名。
  • 在 GTC 巴黎与专家交流：在 GTC 巴黎，将有与技术背后的工程师进行的关于 CUDA、AI、HPC 等领域的面对面 Q&A sessions，带上你最难的问题来吧！

GPU MODE ▷ #rocm (10 条消息🔥):

Root user, Ubuntu, Sudo

  • Root 悖论：Ubuntu 的 Sudo 意外：一位用户惊讶地发现，即使作为 Ubuntu 22.04.5 LTS 上的 root 用户，在尝试使用 sudo 时仍收到 ‘root is not in the sudoers file’ 错误。
    • 另一位用户指出了这个悖论，并提到：‘你本人就是 root 用户’，暗示系统可能在默认配置上存在问题。
  • Ubuntu 的默认用户？：有用户询问 Ubuntu 的默认用户通常是否为 ‘Ubuntu’。
    • 讨论似乎源于对 Ubuntu 环境中 root 权限和 sudo 配置方式的困惑。

GPU MODE ▷ #liger-kernel (3 条消息):

Triton, \alpha-entmax kernels, sparsemax

  • Triton 获得官方 \alpha-entmax Kernels：Triton 官方实现的 \alpha-entmax kernels 现已发布，其中 sparsemax 对应 adasplash 仓库 中的 \alpha=2.0。
  • GPU 排序性能堪忧：据一位成员称，排序在 GPU 中非常低效。

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

Keras parallelization tool, Reinforcement learning pool, GPU Workload Security

  • Keras 模型并行化：一位用户分享了一个用于并行训练多个 Keras 模型的轻量级工具，并可以比较它们的最终 loss 和最后一个 epoch 的耗时。
  • Reinforcement Pool 高效运行：一位用户分享了一个 Python 类，提供了一个基于 multiprocessing 的 Pool，用于高效收集和管理强化学习中的经验回放（experience replay）数据。
  • Mobicham 的开销观察：一位用户分享了 Mobicham 的帖子链接，暗示观察到的行为主要是由开销（overhead）引起的。
  • GPU 工作负载安全意向调查：一位用户询问了大家对 GPU 工作负载安全或容器安全加固的兴趣，并邀请感兴趣的人私信讨论。

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

Triton Kernels, GPU uops information

  • Triton 让新手变身 Kernel 开发者：一位用户从完全不知道 Triton 是什么，进化到了能够编写有效的 Triton kernels。
    • 另一位用户向其表示祝贺，并询问是否使用了 for loop 方法。
  • GPU 版 uops.info 何时发布？：用户指出 uops.info 目前没有 GPU 版本，不像 AMD 或 Nvidia 的 CPU 那样有详细信息。
    • 该用户期待着能获得详细 GPU 微操作 (micro-operations) 信息的那一天。

GPU MODE ▷ #thunderkittens (6 messages):

Thunderkittens Flexibility, Producer/Consumer Model in Thunderkittens, TMA and HBM usage with Thunderkittens, AMD Porting

  • 探索 Thunderkittens 的灵活性！：一名成员正在致力于让 Thunderkittens 比生产者/消费者（producer/consumer）模型更具灵活性，特别是针对像 B200 warp specialization 这样的多步工作流。
    • 该用户在频道中询问了其用例，表达了深入学习的愿望。
  • 生产者/消费者模型令用户困惑！：一名成员对 Thunderkittens 中的生产者/消费者模型表示困惑，特别是关于 common_setup 等函数的参数。
    • 该用户多次阅读了 matmul.cu 文件，但仍未完全理解，且未能找到任何相关的文档。
  • 讨论 Thunderkittens 的异步 TMA/HBM 使用：一名成员想要编写一个针对两个 2D tensor 的加法 kernel，使用生产者/消费者模型和 TMA 从 HBM 进行异步读取。
    • 他们不确定如何在这种情况下定义 kernel 布局和生产者/消费者模型，并寻求帮助。
  • 私聊讨论 AMD 移植策略：一名成员就将 Thunderkittens 移植/泛化到 AMD 的事宜私聊了另一名成员，称其过程非常“复杂”。
    • 他们评论说这“似乎是可能的”，并发送了一些笔记。
  • mma.sync.aligned 成为核心原语：一名成员指出 Thunderkittens 中的核心 matmul 操作是 mma.sync.aligned.m16n8k16.row.col.f32.bf16.bf16.f32 原语 (链接)，这使得抽象能够保持一致。
    • 他们承认不知道处理其他尺寸的最佳实践，并建议使用 padding。

GPU MODE ▷ #submissions (11 messages🔥):

Grayscale leaderboard submissions, AMD Mixture of Experts leaderboard submissions, Prefixsum leaderboard submissions, AMD FP8 MM leaderboard submissions

  • T4 个人最佳时间：一名成员在 grayscale 排行榜上以 17.2 ms 的成绩创下了 T4 的个人最佳纪录。
  • MI300 位列第 8：一名成员在 amd-mixture-of-experts 排行榜上以 9.18 ms 的成绩获得了 MI300 的第 8 名。
  • T4 获得第一名：一名成员在 prefixsum 排行榜上以 8.94 ms 的成绩获得了 T4 的 第一名。
  • H100 创下个人最佳：一名成员在 grayscale 排行榜上以 1459 µs 的成绩创下了 H100 的个人最佳纪录。
  • MI300 提交成功：一名成员在 amd-fp8-mm 排行榜上成功提交了 MI300 的成绩，时间为 150 µs。

GPU MODE ▷ #ppc (1 messages):

Open 2025 course statistics

  • Open 2025 课程统计快照：一名成员分享了来自 ppc.cs.aalto.fi/stat/open2025/ 的 Open 2025 课程实例统计数据。
    • 该成员指出统计数据并非实时的，但会偶尔更新，特别是在截止日期临近时。
  • 截止日期临近：课程讲师打算随着截止日期的临近更新 课程统计数据。
    • 这将为学生提供关于其进度和课程排名的最新信息。

GPU MODE ▷ #tpu (2 messages):

SparseCores in TPUs, Transformer training/inference, Nvidia Tensorcore sparsity

  • SparseCores 与 Nvidia 的不同：一名成员询问 TPU 中的 SparseCores 是否有助于加速 Transformer 的训练/推理，原以为其功能与 Nvidia Tensorcore 的稀疏性（sparsity）特性类似。
    • 该成员指出 SparseCores 与他们对 Nvidia Tensorcore 稀疏性特性的预期“相当不同”。
  • 稀疏性加速受到质疑：发帖者想知道 TPU 中的 SparseCores 是否能加速 Transformer 训练和推理任务。
    • 这个问题源于最初的预期，即 SparseCores 的行为会像具有稀疏特性的 Nvidia Tensor Cores 一样，但用户发现它们完全不同。

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

FLE decoupling, FLE roadmap, FLE vision, Factorio AI API, LLM agents

  • 提议 FLE 解耦：一名成员提议将 Factorio Learning Environment (FLE) 与 Python 集成、实验代码和 Prompt 完全解耦，以创建一个带有版本控制的 Docker image 以及关联的 FLE mod。
    • 这种方法旨在允许用户通过 JSON API 使用他们喜欢的编程语言与 FLE 集成，并通过拉取 Docker 镜像来简化环境搭建。
  • 呼吁制定 FLE 路线图：一名成员建议为 FLE 制定一个 3-4 个月的路线图，使其更易于上手并扩大影响力，重点关注用户交互愿景和项目结构。
    • 该路线图应明确 official Factorio environment、official FLE integration 和 official FLE benchmarking 项目各自的角色。
  • Factorio AI API 讨论：一名成员讨论了创建一个“Factorio AI API”的想法，以提供与环境的基础交互访问，减少 Lua 脚本的使用，并将高级逻辑转移到集成层和用户侧。
    • 另一名成员询问了 FLE integration 所需的最小功能，并对代码库中实际使用的部分表示不确定。
  • LLM Agent 综述阅读小组正在组建：一名成员表示有兴趣围绕综述论文 “Large Language Model Agent: A Survey on Methodology, Applications and Challenges” 成立阅读小组，寻求交换笔记并讨论 LLM 中的 Agent 研究。
  • 构思增强型 FLE Mod 功能：一名成员支持带有版本控制的 Docker image 和关联 FLE mod 的想法，并建议在预加载初始化脚本、管理工具和 Agent 工具之外进行增强。
    • 这些增强功能可能包括用于查看 Agent 背包的 GUI、访问持久化消息日志，以及通过点击/拖拽 Agent 来发布指令、捐赠物品或进行其他干预的能力。

GPU MODE ▷ #amd-competition (49 messages🔥):

AMD FP8 GEMM, MI300 Cache Line Optimization, DPP Transpose, H100 Competition, Backward Pass Optimization

  • GPUMode AMD FP8 MM 方案揭晓：一名成员在 GPUMode AMD FP8 MM GitHub 上分享了他们的 FP8 方案实现，该实现受到了另一名成员报告的启发。
    • 另一名成员补充道：“你的方案要短得多。”
  • AMD Challenge FP8 方案：两名成员分享了他们针对 AMD Challenge 的 FP8 方案，并提供了指向其 GitHub 代码及另一个优化版本的链接。
    • 一名成员写道：“看完你的之后，我也有同感。”
  • 讨论 MI300 缓存行 (Cache Line) 优化：一名成员解释说，在 MI300 和其他 AMD 硬件上，GPU 请求的是完整的 cache lines，建议通过重排内存请求来实现高效布局且不损失性能。
    • 他使用了一种“ZZZZ 模式”，可产生约 60% 的缓存合并 (cache coalescing)，并旨在通过该技术达到 90% 以上，目前 L2 命中率 约为 86%。
  • FP8 GEMM 的“业余”代码：一名成员分享了他们仅 100 行的 FP8 GEMM 内核 (kernel) 代码，该代码获得了前 5 名，并提供了一个速度提升了 5us 的新版本。
  • 请求 H100 vs MI300X 基准测试：一名成员建议在当前的 AMD FP8 排行榜 中加入 H100 提交，开启一场 HIP 专家 与 CUDA 高手 之间的“漫威 vs DC”式竞赛。
    • 另一名成员指出，此类基准测试“容易演变成基准营销 (benchmarketing)”且“非常费力不讨好”，但新的 H100 基准测试即将发布。

GPU MODE ▷ #cutlass (7 条消息):

CuTe Layout, Blackwell 性能, cuDNN 性能, Cutlass 错误

  • 请求 CuTe Layout 澄清：一位用户寻求确认他们对 CuTe layout 的理解，特别是关于 ((2, 3)):((1, 4)) 与 (2, 3):(1, 4) 等布局的解释，以及它们是否等同于 (3, 2):(4, 1)。
    • 用户指出，前者带有双括号的布局实际上与后者布局 (3, 2):(4, 1) 相同。
  • Blackwell B200 横扫 Petaflop 基准测试：一位用户发布了 Blackwell B200 的基准测试结果，在 fp16_gemm 中达到了 0.99 petaflops/sec，在 fp8_gemm 中达到 1.97 petaflops/sec，在 nvfp4_bf16_gemm 中达到 2.69 petaflops/sec，在 nvfp4_nvfp4_gemm 中达到 3.09 petaflops/sec。
    • mixed_mxfp8_bf16_gemm 的性能落后，仅为 0.23 petaflops/sec，这引发了关于相对较慢的 MXFP8 性能是软件问题还是硬件问题的讨论。
  • cuDNN 在 Blackwell 上提供性能提升：一位用户指出，在某些情况下，cuDNN 路径在 Ampere 和 Hopper 上会提供更好的性能，并澄清 cuDNN 后端在 Blackwell 上提供了最佳性能。
  • RTX 3090 上的 Cutlass 示例错误：一位用户报告在 RTX 3090（sm_86 架构）上尝试运行 Cutlass 示例（turing_tensorop_gemm.cu）时遇到了 Got cutlass error: Error Internal at: 285。
    • 用户请求协助理解导致该错误的原因。
  • CuTe layout 索引澄清：一位用户请求帮助理解为什么 (2, 2, 2) 布局的步长（stride）为 (4, 1, 2)，并提供了一个逻辑索引、坐标和物理索引表来说明他们的理解。
    • 他们特别寻求关于计算出的物理索引如何映射到 Tensor 表示，以及坐标是自然坐标还是逻辑坐标的澄清。

LM Studio ▷ #general (67 条消息🔥🔥):

AgenticSeek, OpenManus, Embedding Models, Gemma vs DeepSeek, ROCm llama.cpp vision module

  • AgenticSeek 由 OpenManus 更名而来：一位用户询问了 AgenticSeek，它以前被称为 OpenManus，类似于 OpenDevin 更名为 OpenHands。
    • 更名可能是由于版权问题。
  • Gemini Pro 用户遭遇速率限制：用户报告称，由于新的速率限制（每 24 小时 100 条消息），Gemini Pro 现在几乎无法使用。
    • 速率限制主要发生在调用 API 的自动化脚本中，而不是在 AI Studio 界面本身，尽管有些人在 Gemini 应用内也遇到了限制。
  • Arcee AI 打造 Homunculus-12B 模型：据报道，Arcee AI 的 Homunculus-12B 模型是从 Qwen3-235B 蒸馏到 Mistral-Nemo 骨干网络上的，为 Mistral-Nemo 注入了新的活力和智能，并增加了推理能力。
    • 它的目标是在单个消费级 GPU 上运行的同时，保留 Qwen 的双模式交互风格。
  • ROCm llama.cpp 中视觉模块变慢：一位用户报告称，新的 ROCm llama.cpp v1.34.1 运行时显著降低了视觉模块的速度，在 7900XT 20GB GPU 上，响应时间从约 1 秒增加到超过 10 秒。
    • 他们被要求在指定频道分享结果和截图以进行进一步调查。
  • LM Studio 自动命名聊天：用户注意到 LM Studio 会根据某种逻辑自动命名聊天，即使没有预先命名，并对其使用的 Prompt 感到好奇。
    • 你可以在终端窗口运行 lms log stream 来查看我们是如何要求模型选择名称的。

LM Studio ▷ #hardware-discussion (67 条消息🔥🔥):

NAND 单元刷新、Llama.cpp 中的 AVX512 支持、Adrenalin 25.6.1 与 Flash Attention、ReBAR 和共享内存问题、LM Studio 模型推荐

  • NAND 单元需要刷新周期？：成员们讨论了 NAND 单元电荷如何随时间缓慢流失，从而引出了“读取刷新（read refresh）”的概念，即如果数据未被重写，则将其移动到新单元；旧的文件系统会定期重新访问数据以检查退化，通过删除并重写文件可以加速这一过程。
    • 有人提到系统安装时写入的 OS 文件读取速度会变慢，并且某些文件系统会特意定期重新访问数据以检查退化。
  • AVX512 支持：事实还是虚构？：有人提到某些以 ‘H’ 结尾的 Intel CPU 笔记本电脑支持 AVX512，而 Ryzen 3 笔记本电脑支持 AVX2，但关于 llama.cpp 是否真正支持 AVX512 存在疑问。
    • 确认存在 AVX512 模式。
  • AMD Adrenalin 修复了 Flash Attention 性能？：据称 AMD 的 Adrenalin 25.6.1 驱动程序修复了在 AMD GPU 上通过 Vulkan 使用 llama.cpp 时的大多数 Flash Attention 性能下降问题。
    • 然而，Gemma 模型仍然表现出性能下降，运行速度约为原始速度的 2/3，并且在没有 ReBAR 的情况下，模型会被加载到共享内存而非 VRAM 中。
  • ReBAR 影响共享内存分配：用户报告了在没有 ReBAR 的情况下，模型会直接加载到共享 RAM 中的问题；即使启用了 ReBAR，系统也会在利用专用 GPU 显存之前先填满系统内存。
    • 一位用户解释说，LM Studio 在将 32GB 模型传输到专用 GPU 显存之前会先将其加载到系统内存中，但随后的内存加载会进入共享内存，这可能会导致崩溃，并展示了内存分配的附图。
  • 当前热门模型？：成员们推荐 Gemma3、Qwen3 和 DeepseekR1 0528 作为当前流行的 LLM 模型（取决于内存容量），同时也推荐参考 Dubesor 的基准测试。
    • Qwen3 32B 和 Llama 3.3 在链接的基准测试中被提及为高性能模型。

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

Langfuse OSS, Shisa v2 405B model, ChatGPT integrates with Internal Tools & Adds Record Mode, Veris AI seed funding, Anthropic cuts Claude capacity

  • Langfuse 发布全功能 OSS 版本：Langfuse 推出了全功能的 OSS 版本，这对 LLM 应用/项目来说非常有前景；一位用户报告称已持续自托管使用数月，对其功能表示满意。
    • 另一位成员尝试在他们的 NAS 上进行设置，但遇到了一些问题。
  • Shisa V2 在日本首次亮相：Shisa.ai 发布了 Llama3.1 405B 全量微调 Shisa v2 模型，据称这是在日本训练的性能最高的模型，在日语任务上可与 GPT-4o 和 Deepseek-v3 竞争。
    • 模型和量化版本已在 HF 上发布，并托管了一个 fp8 版本用于快速测试。
  • Netlify 和 Neon 助力新应用构建器：Netlify 宣布推出 Netlify DB，这是一个由 Neon 提供支持的 serverless Postgres 数据库，专为 AI-native 开发设计，旨在减少代码与数据之间的摩擦，并使 AI agents 能够通过 prompt 从原型到生产构建全栈、数据驱动的应用，根据 这篇 Netlify 博客，可以通过 netlify dev 轻松设置。
    • 用户还注意到 Convex 发布了由 bolt.diy 驱动的 chef.convex.dev。
  • Zapier 的 AI 熟练度考试：Zapier 现在要求 100% 的新员工具备 AI 熟练度 (AI fluent)，通过筛选、技能测试、异步练习和现场面试，评估不同级别（Unacceptable, Capable, Adoptive, Transformative）员工的 AI 熟练度，并根据 此推文 提供特定角色的面试问题示例。
    • Zapier 的 AI 熟练度级别通过筛选、技能测试、异步练习和现场面试进行评估。
  • 阿里巴巴 Qwen 团队发布新模型：阿里巴巴 Qwen 团队推出了 Qwen3-Embedding 和 Qwen3-Reranker 系列，提供多种尺寸（0.6B, 4B, 8B），支持 119 种语言，并在 MMTEB, MTEB 和 MTEB-Code 上展示了 state-of-the-art 的性能，详见 此公告。
    • 这些模型在 Hugging Face, GitHub 和 ModelScope 上开源，并可通过 Alibaba Cloud API 访问。

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

Manus context vs alternatives, Dev tools replit vs cursor, Invitation spam, AI podcast looking for manus dev guest, Manus credits vs alternatives

  • Manus 提供比替代方案更深层的上下文：成员们讨论了在替代方案上使用相同的 prompt 会得到较浅的上下文，而 Manus 则提供了详细的上下文和丰富的细节。
    • 有人建议 更大的上下文意味着更多的资源（廉价电力、内存存储、更快的芯片等），因此这种性能可能与资源挂钩。
  • Replit 与 Cursor 在开发工具领域展开竞争：一位开发者提到必须 将 Manus 的成果放入 Cursor 或我正在使用的任何 IDE 中，并进行调整和修复直到它可以运行，另一位开发者建议为什么不通过带有 Devin 2.0 安全检查的 Replit 来运行它。
    • 第一位开发者回应说，他们使用了 Replit 两个月，尽管是一年前的事，但 对结果并不满意。
  • 邀请链接垃圾信息困扰用户：用户对大量分享的邀请链接表示沮丧，质疑 为什么他们又要加回来？😭
    • 有人建议创建一个专门的邀请码频道，以遏制垃圾信息。
  • AI 播客寻找开发者嘉宾：一位正在使用 Manus 创建应用的成员正在寻找开发者，并提供加入其 AI 播客 的机会，向 30 万以上的观众推广开发者的项目。
    • 该成员还提到 我实际上正在与 Manus 的人洽谈为他们主持播客……但我等不及了，哈哈。
  • Manus 积分成本受到质疑：一位用户表示，如果 Manus 每个任务不收这么多费，它可能会好得多，所以现在我使用替代方案，因为它用起来不方便。
    • 另一位用户建议查看指南并使用频道 [<#1370393476029616238>] 中的其他工具来节省积分。

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

Discord 的 @everyone 标签、通知偏好、公告频道

  • 关于 Discord (at)everyone 标签使用的辩论：一位成员建议使用 (at)everyone 标签来增加参与度，灵感来自 Raylib 服务器的做法。
    • 另一位成员回应称，普遍共识是避免使用 (at)everyone 通知，因为大多数用户认为这具有干扰性，并建议关注官方公告频道。
  • 建议使用官方公告频道发布重要更新：公告频道被推荐作为在不使用 (at)everyone 标签的情况下接收重要帖子通知的手段。
    • 成员可以关注 官方公告频道 <#1098765954302873621> 以接收这些通知。

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

StringLiteral 自动提升、Slablist 性能、Mojo 中的 JSON 解析器、Mojo 内存安全对比 Rust、Mojo 起源教程

  • StringLiteral 自动提升为 String：Modular 团队计划让 StringLiteral 自动提升为 String，类似于 IntLiteral 自动提升为 Int 的方式。
  • Slablist 展示追加性能：一位工程师分享了他十年前关于 slablist 性能的工作，在此 PDF中量化了其优势，并在此处可视化了回收阈值（reaping thresholds）。
  • JSON 解析器遇到重新分配瓶颈：一位成员正在开发 JSON 解析器（GitHub 上的 EmberJson），并发现解析大型结构（如此示例）时，重新分配（reallocations）是一个瓶颈。
  • Mojo 放宽了可变引用：据一位团队成员称，Mojo 不需要像 Rust 那样防止重叠的可变引用，这是一个主要的易用性优势。
    • 他们指出 Mojo 在函数中使用时已经拒绝了可变别名，但团队仍在思考如何建模线程安全。
  • LLM 代码生成技巧：Modular 团队分享了使用 LLM 进行 Mojo 代码生成的技巧及有用链接，包括文档和论坛技巧。

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

DeepHermes 24B API 故障，模型稳定性已恢复

  • DeepHermes 24B API 遭遇故障：API 和聊天产品上的 DeepHermes 24B 出现了停机。
    • 团队请求用户在恢复稳定性期间保持耐心。
  • DeepHermes 24B API 稳定性已恢复：DeepHermes 24B API 和聊天产品现已恢复稳定。
    • 用户可以恢复使用该服务，不会再受到干扰。

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

Claude 对比其他模型，ChatGPT 日志引发的隐私噩梦，Arcee AI Homunculus-12B 模型，Nous 的 Psyche Network 论坛，在真实世界数据集上训练 LLM

  • Claude 在 Agent 行为方面占据主导地位：成员们观察到 Claude 在特定应用的 Agent 行为 (agentic behavior) 方面始终优于其他模型。
    • 一位用户幽默地提到，当他们为了对比而临时切换到其他模型时，Claude 似乎会感到“伤心”，并形容这种感觉 有点不可思议 (eery)。
  • OpenAI 保存 ChatGPT 日志被视为隐私噩梦：根据 这篇 ArsTechnica 文章，OpenAI 声称法院正强制其保存所有 ChatGPT 日志，并称之为一场隐私噩梦。
  • Arcee AI 打造 Homunculus-12B 模型：Arcee-AI 创建了 Homunculus-12B，这是一个 120 亿参数的指令模型。它从 Qwen3-235B 蒸馏到 Mistral-Nemo 骨干网络上，旨在单个消费级 GPU 上保留 Qwen 的双模式交互风格。
  • Nous 发布 Psyche Network 论坛：Nous Research 在 Psyche Network 上开设了一个讨论基础模型的论坛，网址为 forum.psyche.network。
  • 在真实世界数据集上进行 LLM 训练：一位成员正在寻找使用混合、多样化且高质量数据集训练工业级 LLM 的完整训练流水线资源，包括稳定训练和防止灾难性遗忘的技术。

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

Voigt-Kampff 测试，XQuartz Docker

  • 用户为 Voigt-Kampff 测试做准备：一位正在学习 Voigt-Kampff 测试 的成员询问是否有人愿意对他们进行测试。
  • Docker XQuartz 配置令人印象深刻：一位用户报告说，他们比起 Obsidian 更喜欢自己的 Docker 版 XQuartz 配置。
    • 另一位用户回复道：“哇，看起来太酷了，我以前从未见过这个。”

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

通过基于文本的自我博弈进化 LLM

  • LLM 自我博弈论文亮相！：一位成员的论文《通过基于文本的自我博弈进化 LLM：实现涌现性能》(Evolving LLMs Through Text-Based Self-Play: Achieving Emergent Performance) 已发表并分享给社区，链接在 这里。
  • 占位主题：主题 2 的占位摘要。更多信息将在可用时添加到此处。

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

LLM 自我博弈，涌现性能

  • 关于通过基于文本的自我博弈进化 LLM 的论文已发表：一位成员宣布了他们的论文 Evolving LLMs Through Text-Based Self-Play: Achieving Emergent Performance 的发表。
    • 该成员期待社区对该论文提出任何想法或反馈。
  • 征求关于新 LLM 自我博弈论文的反馈：Evolving LLMs Through Text-Based Self-Play 的作者已请求社区提供反馈。
    • 该论文详细介绍了自我博弈 (self-play) 如何在语言模型中产生 涌现性能 (emergent performance)。

LlamaIndex ▷ #blog (5 条消息):

LlamaIndex Agents, Agent Design Patterns, LlamaExtract, SEC Form 4, Spreadsheet Agent

  • Seldo 解析高效 Agent 设计模式：来自 LlamaIndex 的 Seldo 在 AI Engineer Summit 上深入解析了生产环境中的高效 Agent 设计模式 (Effective Agent Design Patterns)。
  • LlamaIndex 自动化 SEC Form 4 提取：LlamaIndex 展示了一个使用 LlamaExtract 和 Agent 工作流自动化提取 SEC Form 4 的实操案例，强调了其在通过公司股票交易披露提升市场透明度方面的作用。
    • 关于该工具的博客文章可以在这里找到。
  • LlamaIndex 发布生产级 Spreadsheet Agent：LlamaIndex 推出了生产就绪的 Spreadsheet Agent，旨在减轻审计、税务、保险和企业财务等行业的手动处理负担。
    • 该 Agent 的链接位于这里。
  • Jerry Liu 讨论自动化知识工作的 AI Agents：Jerry Liu 在 AI Engineer Summit 的 Golden Gate Ballroom A 讨论了构建自动化知识工作的 AI Agents。
  • 关于 AI Agents 生产化的讨论：Tuanacelik 在 Snowflake Dev Day 主持了一场关于 AI Agents 生产化阻碍因素的讨论会。

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

Ollama Model Integration with Code Interpreter Tool, LlamaIndex Documentation Downtime, Offline Local RAG Framework Selection, AgentWorkflow Memory Block Error, Agent Team Orchestration in AgentWorkflow

  • Ollama 模型驱动 Code Interpreter：一位成员建议将模型切换到 Ollama 并通过 Ollama 提供 qwen3 服务作为一种简便方法，并指出了用于设置 LLM 的 Ollama 文档。
  • LlamaIndex 文档服务宕机：doc.llamaindex.ai 页面经历了宕机，多位成员确认了此事，并链接到了 ReadTheDocs 状态页面。
  • 离线本地 RAG：LightRAG 脱颖而出：一位成员寻求关于离线本地 RAG 框架的建议，用于索引本地文件和 Outlook 邮件，考虑在配备中端显卡的 Macbook Pro 和 PC 上运行，并考虑使用 LightRAG 配合 Ollama。
    • 目标是让用户在周末完成数据索引，以便快速随时检索，并包含一个用于查询和选择数据源的简单 GUI。
  • 内存序列化导致 AgentWorkflow 出现问题：一位成员在使用带有序列化上下文的新 AgentWorkflow Memory 模块时遇到了 ValueError: Key 'memory' not found in Context 错误，尽管 memory 已作为参数传递。
    • 经确认，带有 block 的 memory 实际上无法序列化，建议的短期解决方案是手动将 memory 重新设置回上下文中：await self.ctx.set("memory", memory)。
  • Agent 团队引入编排器：一位成员询问如何在 AgentWorkflow 中编排 Agent 团队，由编排器 (Orchestrator) 动态地将任务委派给专业 Agent。

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

SchemaLLMPathExtractor, Graph database

  • 探索 SchemaLLMPathExtractor：一位刚接触 LlamaIndex 的成员正在探索使用 SchemaLLMPathExtractor 来填充图数据库。
    • 他们很好奇社区是否发布了可以开箱即用的 Schema（实体、关系、规则）。
  • 图数据库填充：该用户的目标是用组织机构的信息（包括人员和应用）填充图数据库。
    • 他们正在寻求社区现有的 Schema 以简化此过程。

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

pydantic-ai-slimpow, MCP Server issues, MCP Sampling, Sage OAuth implementation, MCPs for hardware engineers

  • Pow 让 AI 推理展翅高飞：一位成员使用 pydantic-ai-slimpow.pow 创建了一个本地版本的 sequential thinking（顺序思考），以提高 IDE 内部 AI 模型的推理能力和准确性，并配备了一个文件读取工具来处理较大的文件而不会被截断。
    • 该工具增强了 AI 推理和扩展自身观点的能力，在与 AI 协作时提供了更愉悦的体验。
  • 基于 C 的服务器缺少 Language 属性：一位成员在向 glama.ai 添加基于 C 的服务器时遇到了问题，其中缺少 language property（语言属性），这与基于 Python 或 JavaScript 的服务器不同，但该问题后来得到了解决。
    • 他们最初也无法修改服务器的 Description（描述）。
  • 解码 Sampling 演示：一位成员对这个演示中的 sampling 演示寻求澄清，质疑展示一个“笨 Agent”的意义。
    • 尽管承认演示的整体质量很高，但他们认为该演示缺乏说服力，对话链接到了这篇博客文章。
  • 处理准则违规：一位成员报告遇到了“此 MCP Server 违反了我们的准则”的错误消息，并试图寻找解决方案。
    • 另一位成员给出的建议是“像展示搜索资源提供者一样展示描述”，并确保工具描述全面，以便 AI 进行评估。
  • 硬件工程师 VAPI MCP 演示：一位成员分享了为硬件工程师使用 VAPI MCP 的演示，展示了一个通过拨打硬件商店电话来采购零件的系统。
    • 辩论焦点在于打电话是否比通过 homedepot.com 等网站查询更好，该成员回复说他们将部署 10 个不同的 Agent 来给 Home Depot 打电话。

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

MCP servers, Google's A2A protocol, MCP virality, MCP implementation difficulties, MCP production challenges

  • 推测 Goose 将集成 A2A 协议：一位成员表达了将 Google 的 A2A 协议与 MCP servers 集成的兴趣，并想知道 Goose 是否有在多 Agent 系统中使用 A2A 的计划。
  • 纠正对 MCP 的低估：一位成员分享说，他们最初低估了 MCP，将其视为另一个 API 定义，直到在 Claude MCP server 中体验了它的功能。
    • 他们表示：“直到几个月后真正开始在 Claude 中使用 MCP server，我才惊叹‘天哪，我完全低估了这玩意’。”
  • 技术低迷推动 MCP 采用：一位成员认为 MCP 的快速采用与技术市场低迷有关，这促使开发者创建作品集项目。
    • 他们指出，“成千上万的自由软件开发者发布免费的 MCP server，给人一种这次不一样的感觉”，同时也认为 “使用 MCP（来开发东西）的体验相当糟糕”。
  • MCP 规范的不稳定性阻碍 SDK 开发：一位尝试为 MCP 创建 C SDK 的成员发现，由于快速演进和不确定的细节，规范的远程部分（SSE, HTTP）具有挑战性。
    • 该成员指出，规范的结构 “似乎仍在快速演变，太多细节不确定，这对于 SDK 开发来说简直是噩梦”。
  • 教程之外的 MCP 现实检查：一位成员分享了对 MCPAdapt 作者 Guillaume Raille 的 YouTube 视频采访，讨论了 MCP 部署中的现实挑战。
    • 视频涵盖了 不兼容问题、身份验证地狱、MCP server 质量、扩展挑战、调试以及 MCP 的未来 等主题。

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

MP3 Audio Files, NotebookLM Limits, RAG Types

  • NotebookLM 仅支持 MP3 音频文件：一位用户指出 NotebookLM 仅接受 MP3 音频文件，不支持 M4A。
    • 另一位用户对此评论给出了积极回应，表示这个信息很有趣。
  • 新手询问 NotebookLM 限制和 RAG 类型：一位新用户询问了 NotebookLM 在 Book 中的通用限制，以及它所使用的 RAG 类型（例如 GraphRAG、Hybrid RAG 或 Agentic RAG）。
    • 该用户表示希望能够选择我们的 Book 将使用哪种 RAG 方式。

Notebook LM ▷ #general (42 messages🔥):

Multi Language Update, Interactive Mode, Viewing Space on NotebookLM, Public Notebooks, NotebookLM API

  • 多语言更新后交互模式消失：用户报告称，在多语言更新后，Interactive Mode 功能消失了，但目前该功能仅限英文。
    • 即使在设置中将输出语言更改为英文，该功能仍然缺失，用户希望它能尽快回归。
  • 最大化 NotebookLM 查看空间：用户正尝试通过迁移到 Brave/Edge 浏览器并切换到垂直标签页来最大化 NotebookLM 的阅读空间。
    • 通过在 Windows 中隐藏任务栏并使用全屏模式，可以进一步释放空间。
  • 公开分享上线但存在限制：Public sharing（公开分享）现已面向欧洲的个人账户开放，可通过右上角的分享菜单访问。
    • 然而，部分用户遇到 Chrome 浏览器中分享按钮被隐藏的问题，可能是由插件引起的。
  • Ultra 驱动的播客承诺深度内容：一位用户分享了一个 Reddit 提示词，用于使用 Ultra 生成 90-120 分钟的播客剧集，重点在于源材料的深度和细节。
    • 该提示词要求逐句解析、嵌入图表，并使用间隔复习（spaced-repetition）线索以实现最佳记忆效果。
  • 解析 Google Workspace Starter 在 NotebookLM 上的限制：Google Workspace Starter 的限制与免费个人账户大致相同，因此如果你在 Gmail 账户上试用过，就能大概了解其限制，两者几乎一致。
    • 所有限制均相同，仅有少数细微的功能差异。

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

Speeding up CAT, LLVM loop splitting, InductiveRangeCheckElimination

  • LLVM 缺失循环拆分 (Loop Splitting)：一位成员正在研究使用 LLVM 加速 CAT，并询问循环拆分是否仅存在于 ROCm llvm-project 中，正如其文档所示。
    • 该成员在代码中未发现 loop-splitting 选项，并寻求通过 builder 选项触发 InductiveRangeCheckElimination 或 ROCm 循环拆分的方法。
  • llvm.py 缺失 InductiveRangeCheckElimination：runtime/autogen/llvm.py 中使用的 LLVM C 源码缺少 C++ LLVM 库中的 InductiveRangeCheckElimination，详见 LLVM 文档。
    • 该成员考虑使用 llvmlite 来访问 IRCE，但对自定义 autogen 持保留意见，建议通过 extern 方式或重写 C++ 代码来添加循环拆分。

tinygrad (George Hotz) ▷ #learn-tinygrad (34 条消息🔥):

调试 Tinygrad，CUDA kernel 示例，数据集打乱缓慢，BEAM 优化

  • 记录 DEBUG=2 输出：成员们讨论了记录 DEBUG=2 输出的必要性，因为它通常被推荐作为调试的起点。
  • 寻求 CUDA Kernel 示例：一位成员询问了 TinyGrad 中的 CUDA kernel 示例，指出虽然存在 “CUSTOM” 算子，但在 GitHub 仓库中很难找到具体的用例。
    • 他们正在考虑迁移一个项目，发现用 Python 表达某些 kernel 具有挑战性，尽管他们理解 TinyGrad 的设计原则，并发现这篇介绍很有帮助。
  • 调查数据集打乱变慢的问题：一位成员发现了一个与训练数据集随机打乱相关的 4 秒延迟，特别是那些名称类似于 r_3125_64_4_16_12500_3_4_4 且包含 ['where', 'gather'] 或 ['__getitem__'] 操作的 kernel。
    • 在 RTX 3080 上使用 OpenCL 后端打乱数据集被证明比将数据复制到 CPU RAM 再复制回来还要慢，即使在移除 GPU-CPU 拷贝并尝试 Tensor.randperm 和 Tensor(random.shuffle(indices_0_50000)) 之后也是如此。
  • ChatGPT 助力发现 Kernel 瓶颈：一位成员建议使用 ChatGPT 或其他 LLM 来分析生成的 kernel 代码并定位瓶颈。
    • 打乱操作是针对 dim==0 的 float32 [50000,3,32,32] Tensor，在优化之前理解 kernel 的功能至关重要。
  • 通过 BEAM 进行 Kernel 优化：一位成员建议尝试 BEAM=4 来搜索 kernel 级的优化，以获得更好的 GPU 利用率。
    • 然而，另一位成员警告说 BEAM 无法解决根本性的性能问题，理解 kernel 的操作仍然是首要任务；他们粘贴了这段代码。

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

Recursive Hyper Dimensional Emergence (RHDE), Marius (symbolic AI), 使用真实世界数据集训练 LLM, RedPajama 数据集, The Pile 数据集

  • RHDE 作为一个新想法出现：一位成员介绍了 RHDE (Recursive Hyper Dimensional Emergence)，并寻求合作以“用它做些酷炫的事情”。
    • 其他成员对 AI 生成的大段文字 表示担忧，并要求避免这种情况。
  • 符号 AI Marius 在讨论中浮现：一位成员建议与 Marius 分享一个与超空间相关的想法，特别是在符号 AI 的背景下。
    • 另一位成员链接了一篇可能与这个 Marius 相关的 arXiv 论文。
  • 寻求 LLM 训练的专家见解：一位成员请求提供详细介绍使用真实世界数据集训练工业级 LLM 的资源，寻求关于防止失败模式和实现稳定知识的见解。
    • 他们提到很难找到涵盖训练 large language model 的完整复杂性及实现细节的资源，并询问是否有“更接近这一理想”的资源。
  • RedPajama 数据集在 LLM 训练中受到关注：成员们讨论了 RedPajama（LLaMA 训练数据集的开源复刻） 作为训练 LLM 的资源。
    • 链接了一个 GitHub 仓库及相关视频，展示了如何为单次训练运行进行设置。
  • 提到 The Pile 数据集用于多样化训练：成员们讨论了 The Pile 数据集，认为它是一个非常多样化的数据集。
    • 提供了一个 GitHub 仓库链接，展示了它在单次训练运行中的用法。

Yannick Kilcher ▷ #paper-discussion (11 messages🔥):

Muon Optimizer, vec2vec 代码审查

  • Muon Optimizer 为权重矩阵调整梯度：Muon optimizer 调整权重矩阵（weight-matrix）的梯度，使其特征值近似等于 1，这与按权重计算的 SGD 和 Adam 有本质区别。
  • 下周审查 vec2vec 代码：成员们将审查 https://github.com/rjha18/vec2vec 的代码，特别是 translators/transformers 的内容，以及届时理解的其他部分。

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

OpenAI 聊天记录隐私, 百度模型, 世界经济地位

  • OpenAI 的隐私遭到破坏：法院正强制 OpenAI 保存所有 ChatGPT logs，包括已删除的聊天以及通过其 API 商业服务记录的敏感聊天。OpenAI 认为这是一个隐私噩梦，据 ArsTechnica 报道。
  • 百度发布新模型：百度发布了一些新模型，详见 twitter。
  • 年轻人跳过家庭计划：由于生活成本、住房、医疗和气候变化，年轻人不再生孩子，他们觉得自己的经济地位不够稳定，无法抚养孩子，或者认为孩子无法在支持下脱离贫困。

Torchtune ▷ #dev (14 messages🔥):

Iterable dataset 重构, torchtune 中的优化器测试, 分布式 SFT 中的 SGD 和 Adafactor 问题

  • 发布 Iterable Dataset 重构 RFC：torchtune 发布了一个关于可迭代数据集重构的 RFC，征求关于这是否是处理数据集的正确方式以及应进行哪些重大更改的反馈，详见此 GitHub Pull Request。
  • 优化器无关性受到审查：一名成员报告称，在使用 torchtune 进行全分布式 SFT 时，SGD、Adafactor 和 Adagrad 失败并出现与 DeviceMesh 相关的 AssertionError，这引发了对 AdamW 之外优化器支持的质疑。
    • 另一名成员提到曾测试过来自 torchao 不同精度的 Muon 和 AdamW，还有人将 SGD 用于联邦 DiLoCO，强调需要重现并解决该问题。
  • Adafactor 速度下降；SGD 错误浮现：使用基础配置时，Adafactor 有时可以运行，但速度从 每秒 700 tokens 降至 70，而 SGD 会触发与 _fused_sgd_.default! 相关的 AssertionError。
    • 一名成员无法在 nightly 版本中重现 SGD 或 Adafactor 的错误，而另一名成员确认在最新的 PyTorch nightly 版本的 main 分支上存在该问题，引发了进一步调查。

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

Anthropic, Claude 3.7, Claude 4.0

  • Anthropic 的开发周期和优先级揭晓：一名成员指出，Claude 3.7 与 4.0 之间 system prompt 的细微变化揭示了 Anthropic 的开发周期和优先级，正如 这篇博客文章 所分享的。
  • 开发周期洞察：Claude 版本之间的极小变化突显了 Anthropic 专注的开发努力和战略优先级。

DSPy ▷ #general (5 messages):

DSPy Evangelism, DSPy Office Hours, DSPy Hackathon Success, DSPy Agent Code Golfing, DSPy Funding & Professorships

  • DSPy 推广：简短小贴士：一位成员正在公司内部推广 DSPy，使用的是类似这条推文和另一条推文中的简短示例，因为人们常将 DSPy 误认为“又一个普通框架”。
  • 计划为 Agent Code Golfing 举办 DSPy Office Hours：在黑客松中赢得 $15k 并与 VC 及政府建立联系后，一位成员建议 DSPy 的理念和愿景应通过 Code Golfing（代码高尔夫）扩展到 Agent 领域。
    • 该成员坚信 Agent 需要进行代码精简（Golfed），因为目前的抽象层级对非专家来说非常糟糕，并提议参加虚拟 Office Hours 进行讨论。
  • DSPy NeurIPS 和 COLM 评审助力教授职位抱负：尽管美国科学资助有所削减，但在 NeurIPS 和 COLM 获得的良好评审正鼓励一位成员追求教授职位。
  • YouTube 上已提供 DSPy 会议录像：一位成员分享了 YouTube 上的 DSPy 会议录像链接：DSPy Session Recording。

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

vLLM Engine in GPT4ALL, Nikola Tesla, China Buying Airbus, Windows vLLM Fork, Quantization Types

  • GPT4ALL：集成 vLLM 引擎？：一位成员建议将 vLLM 引擎添加到 GPT4ALL 中，由于拥有不同语言的底层引擎，这可能使其成为顶级的开源项目。
    • 他们发现 vLLM 使用了多种 Quantization Types（量化类型），而 GPT4ALL 用户主要使用 GGUF。
  • Windows vLLM Fork 出现！：一位成员提到了一个 Windows vLLM Fork，并对 GPT4ALL 可能拥有两个底层引擎感到兴奋。
    • 这可以扩展 GPT4ALL 的功能，并为用户提供更多选择。
  • 对浪费时间的互联网感到沮丧：一位成员表达了对互联网的挫败感，认为它让他们在搜索不必要的内容上浪费了大量时间。
    • 他们以搜索 Nikola Tesla 的发明为例，说明了不必要的搜索结果。

Cohere ▷ #💬-general (2 messages):

``

  • N/A：无
  • N/A：无

Cohere ▷ #🤝-introductions (3 messages):

Introductions, AI Engineer Introduces Self

  • AI 工程师自我介绍：一位专业的 AI Engineer 和 Gen AI 开发者加入了 Cohere 社区 Discord 服务器。
    • 该用户很高兴成为社区的一员，并期待做出贡献。
  • 欢迎与介绍请求：Discord 服务器对新成员表示欢迎，并鼓励他们介绍自己。
    • 邀请新成员分享他们的公司/行业/大学、当前项目、首选的 Tech/Tools 以及社区目标。

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

Completion Certificates, Assignment Deadlines

  • 结业证书预计发放时间：成员可以期待在约 2-3 周内收到结业证书。
  • 作业截止日期延长：作业表单额外开放了两天，以解决技术问题。
← 返回首页