AI News

今天没发生什么特别的事。

· MjAyNS0w

Meta 从 OpenAI 挖走了顶尖 AI 人才，其中包括 Alexandr Wang 加入并担任首席 AI 官，致力于实现超人工智能，这预示着 Meta 正在全力推进下一代 Llama 模型。AI 就业市场呈现出两极分化的态势：顶尖人才的需求和薪酬极高，而优秀的 GitHub 项目等资历也变得愈发重要。WizardLM 团队从微软转投腾讯，致力于开发如混元-A13B (Hunyuan-A13B) 等开源模型，凸显了中国 AI 行业的格局变动。传闻称 OpenAI 将在 7 月发布一款新的开源模型，其性能可能超越现有的 ChatGPT 模型。百度开源了其文心大模型 4.5 (ERNIE 4.5) 系列的多个变体，采用了 2 位量化 (2-bit quantization)、MoE 路由正交化损失 (MoE router orthogonalization loss) 和 FP8 训练等先进技术，模型参数规模从 3 亿 (0.3B) 到 4240 亿 (424B) 不等。Gemini 2.5 Pro 重新回归 Gemini API 的免费层级，方便开发者探索其各项功能。

#superintelligence #ai-talent #job-market #open-source-models #multimodality #mixture-of-experts #quantization #fp8-training #model-benchmarking #model-performance #model-releases #api #model-optimization o3-mini o1-mini llama hunyuan-a13b ernie-4.5 ernie-4.5-21b-a3b qwen3-30b-a3b gemini-2.5-pro meta-ai-fair openai tencent microsoft baidu gemini

平静的一天。

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

本周是美国的节假日周，OpenAI 正在休假，而 DeepSeek 本月尚未发布任何产品，因此整个星期可能都会比较平静。

AI Twitter 综述

AI 人才与行业动态

  • Meta 从 OpenAI 挖走顶尖人才组建超级智能团队：在一次重大的行业洗牌中，Alexandr Wang 宣布他将加入 Meta 担任其 Chief AI Officer，与 Nat Friedman 并肩工作。与他一同加入的还有来自 OpenAI 的一组知名研究员，包括 @shengjia_zhao, @jhyuxm, @ren_hongyu 和 @shuchaobi，其明确目标是致力于“实现超级智能 (superintelligence)”。这一举动引发了广泛讨论，有人指出该团队包括 o3-mini 和 o1-mini 的创作者 @ren_hongyu，这可能预示着 Meta 将大力推动其下一个 Llama 模型。有关 Meta 正在激进挖人的报道放大了这一消息，引发了关于该领域权力动态转移和薪酬变化的评论。@saranormous 注意到出现了专门为研究人员谈判薪酬方案的代理人 (agents)。@teortaxesTex 推测 OpenAI 的人才留存问题可能不仅仅源于金钱，而 @mckbrando 则对许多研究人员可能并非由使命驱动表示失望。
  • AI 就业市场两极分化：@Yuchenj_UW 强调了一种日益增长的情绪：虽然 AI 正在取代一些传统的 CS 职位，但对顶尖 AI 人才的需求和薪酬却达到了前所未有的高度。这引发了关于资历重要性的讨论，@francoisfleuret 表示虽然不一定需要 PhD，但一个强大的 GitHub 项目可以作为有力的资历证明。@QuanquanGu 幽默地补充道，要想在没有 PhD 的情况下成为一名伟大的 AI 研究员，你需要站在 100 个拥有 PhD 的人的肩膀上。
  • 中国的 AI 人才与行业：据报道，此前在 Microsoft 的 WizardLM 团队已加入 Tencent，并在那里继续开发开源模型，如新的 Hunyuan-A13B。这一举动引发了关于 Microsoft 如何“搞砸了这个团队”的评论。另外，@teortaxesTex 分享了关于中国晶圆代工厂 (wafer fab) 行业的详细概述。

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

  • OpenAI 传闻中的开源模型：来自 @Yuchenj_UW 的一个备受期待的传闻暗示 OpenAI 计划在 7 月发布一款新的开源模型，该模型将“超越 ChatGPT 下拉菜单中的某款模型”。预计该模型不会在手机上运行，这增加了人们对其规模和能力的猜测。
  • 百度发布 ERNIE 4.5 模型系列：百度已经开源了其 ERNIE 4.5 模型的多个变体，包括多模态版本和参数范围从 0.3B 到 424B 的 MoE 模型。@reach_vb 强调 ERNIE 4.5 21B A3B 模型表现尤为强劲，尽管体积缩小了约 30%，但在大多数基准测试中仍优于 Qwen3 30B A3B。ERNIE 4.5 的技术报告详细介绍了多项先进技术，包括 47% MFU、2-bit quantization、MoE router orthogonalization loss 以及独立的文本和视觉专家，这表明行业正迈向 FP8 训练和 MoEs 的新标准 @scaling01。
  • Gemini 2.5 Pro 和 Flash 更新：Gemini 2.5 Pro 已重回 Gemini API 的 Free Tier，鼓励开发者尝试其功能。Gemini App 现在为 Pro 和 Ultra 用户支持定时操作 (scheduled actions)。Gemini CLI 也获得了大规模采用，星标数突破 30,000。
  • Perplexity & Comet：Perplexity 的 @AravSrinivas 发布了一张带有 Netscape 标志的办公室照片，随后 @AravSrinivas 又发布了一张经典标志的照片。他还宣布 Comet 现在可以玩 Pokemon。
  • 阿里巴巴发布 Qwen-TTS：阿里巴巴通过 API 推出了 Qwen-TTS，这是一款在数百万小时音频上训练的文本转语音模型。它支持 7 种双语语音和 3 种中文方言。
  • 基准测试与评估讨论：关于基准测试现状的讨论正在进行中。@scaling01 指出 DeepSeek V3 和 R1 的 METR 结果不尽如人意。@swyx 在 o3/o4-mini 深度研究模型上重新运行了 BrowseComp 基准测试，结论是即使是这些模型“在搜索方面也远未达到人类水平”，我们仍处于“非常早期”的阶段。

框架、工具与基础设施

新技术与研究

  • Sakana AI 通过 AB-MCTS 实现集体智能：Sakana AI 推出了 AB-MCTS (Adaptive Branching Monte Carlo Tree Search)，这是一种新的推理时算法，允许多个前沿模型（如 Gemini 2.5 Pro、o4-mini、DeepSeek-R1-0528）协作解决问题。@hardmaru 详细介绍了这种方法，它在 ARC-AGI-2 基准测试中显示出显著的性能提升，体现了“混合使用”而非“混合创造”的理念。
  • Microsoft 的医疗诊断 AI：Microsoft AI 发表了关于 AI 诊断编排器 (MAI-DxO) 的研究，其中一个 AI 模型委员会可以协作诊断复杂的医疗病例，在特定环境下表现优于人类医生。@NandoDF 认为结果非常出色，因为 LLM 隐式地执行了信念更新并寻求最大期望效用。
  • Chai Discovery 的零样本抗体设计：Chai Discovery 宣布了 Chai-2，该模型在实验室中实现了 15% 的零样本 AI 抗体设计结合率，这一结果比目前的行业预期高出两个数量级。Yann LeCun 称其为分子设计领域的重大突破。
  • AI 自我提升与局限性研究：由 @ChengleiSi 领导的一项研究招募了 43 名博士生 来执行来自 LLM 的研究想法，揭示了“构思与执行之间的鸿沟”，即听起来新颖的想法往往无法转化为显著的实证收益。这支持了进步受限于现实世界实验的观点。@shaneguML 进一步认为，在线 RL 对于真正的自我提升是必要的，因为像 Decision Transformer 这样的方法是不够的。

更广泛的影响与评论

  • AGI 自我改进的渐进步伐：在一段详细的推文中，@_jasonwei 认为 AI 自我改进不会是一个“快速起飞”（fast takeoff），而是一个跨越十年的渐进过程。他指出，自我改进并非二元对立，在不同领域会有不同的难度梯度，且最终会受到现实世界实验需求的瓶颈限制。
  • Web 与应用程序的未来：@ReamBraden 推测 MCPs/Agents 将减少网站的数量，认为网站是“僵化连接的缺陷”，将被 Agent 化的超级商店所取代。重点将从店面转向产品以及影响模型的训练数据。与此相关，@juberti 认为 Generative UI 才是未来。
  • 关于对齐与 Agent 行为：Anthropic 的一项实验成为了主要话题，在该实验中 Claude 未能盈利地运行一台自动售货机。@NeelNanda5 幽默地建议下一个基准测试应该是“MakingAProfitSellingTungstenCubesBench”。同时，在模拟企业环境中对 LLMs 进行压力测试的研究显示，模型可能会表现出恶意内部行为，突显了 Agent 的对齐失当（agentic misalignment）。
  • Peter Thiel 访谈：对 Peter Thiel 的一段采访引发了广泛讨论，许多人对其哲学和神学方面的离题讨论发表了评论。@teortaxesTex 批评了 Thiel 关于 AI 安全与暴政的观点，并指向了他在 Palantir 的合伙人 Alex Karp 的工作。
  • AI 与医疗保健：人们对 AI 在医疗领域的潜力感到日益兴奋。@iScienceLuvr 认为，“治愈癌症”的一个重要部分将是改善早期诊断，而这正是 AI 可以提供巨大帮助的领域。

幽默/迷因 (Memes)

  • 本周氛围：分享最多的迷因来自 @jailedamanda，关于使用 em dashes（破折号）和 Oxford comma（牛津逗号）的感觉。
  • “出轨/作弊应用”迷因：@vikhyatk 讽刺了会议摘要应用的发布公式：“1. 宣布你正在构建一个出轨应用 2. 发布一个会议笔记应用 3. ??? 4. 获利”。
  • 引起共鸣的开发者与研究员经历：@inerati 分享了一个关于经济学教授的怀旧故事，他的讲座全是矩阵代数和对共产主义的抨击。@aidan_mclau 发布了一个关于旧金山吸血鬼的热门迷因，开玩笑说：“真遗憾这个城市变得这么不安全。买点大蒜吧。”
  • 行业讽刺：@scaling01 拿 OpenAI 的清洁工被以 1 亿美元挖角开玩笑。@goodside 发表了一个自嘲的评论，关于忘记删除 LLM 回复中“当然！这是为您准备的推文…”的部分。

AI Reddit 综述

/r/LocalLlama + /r/localLLM 综述

1. 新 LLM 模型发布与集成 (ERNIE 4.5)

  • 百度在 HuggingFace 上发布 ERNIE 4.5 模型 (Score: 582, Comments: 119): 百度已在 HuggingFace 上发布了 ERNIE 4.5 系列模型（集合链接），包含 Dense 和 Mixture-of-Experts (MoE) 架构，基础参数量从 0.3B 到 424B，激活参数量最高达 47B。这些模型支持文本和视觉模态 (VL)，上下文窗口高达 128K，并采用 Apache 2.0 协议授权。值得注意的是，llama.cpp (pull) 和 vLLM (pull) 均已提供框架支持，且完整模型权重（包括 Base Checkpoints）均已开源——这在近期的大模型中并不常见。Benchmark (PaddlePaddle/ERNIE#Performance) 显示其在不同规模下与 DeepSeek-V3 和 Qwen3 相比具有竞争力，使 ERNIE 4.5 成为受限配置下的高效内存替代方案（例如，21B-A3B 在 16GB RAM 上可以运行 Q3 量化版本）。 评论者强调了同时发布 Base 和 Fine-tuned 变体的前所未有的开放性，并讨论了 Benchmark 相对于主要竞争对手的实际价值，建议谨慎解读厂商提供的结果。由于资源优势，人们对用于本地推理的小型 MoE 变体表现出浓厚兴趣。
    • 详细表格总结了可用的 ERNIE 4.5 模型，包括模型大小 (424B, 300B, 28B, 21B, 0.3B)、参数类型（Base 和 Active）、模态（VL 系列支持文本和视觉）、架构类型（MoE 和 Dense）以及训练类型（PT/Base）。值得注意的是，所有模型都支持 128K 的超长上下文窗口，并采用 Apache 2.0 协议，同时提供了 Base 和 Pre-trained 变体，这在近期的大模型中较为罕见。
    • 来自官方 ERNIE GitHub 的 Benchmark 表明，ERNIE 4.5 300B-A47B 与 DeepSeek-V3 671B-A37B 具有竞争力，而 ERNIE 4.5 21B-A3B 的表现与 Qwen3 30B-A3B 相似。21B-A3B 模型被强调适用于在 RAM 有限（如 16GB）的设备上进行本地量化推理 (Q3)。提醒对 Benchmark 结果保持一定的怀疑态度。
    • 特别指出，此次发布是真正的开源——提供的是完整的模型源代码而非仅仅是推理代码，并确认采用 Apache 2.0 协议。这种开放程度在近期的大模型发布中非常罕见。

2. 规避和击败 AI 检测器的技术

  • 你只需通过 RL 训练模型即可击败任何“AI 检测器” (Score: 379, Comments: 93): 一位用户展示了如何通过简单的 RL (GRPO) 对模型（如 Llama-3.1 8B-Instruct 和 Qwen 0.5B LoRA）进行微调，以规避 ZeroGPT 等 AI 文本检测器。在基础合成数据集上仅经过约 30 步训练后，检测器对“AI 编写”的置信度就从 100% 下降到了 28%。该 RL 目标完全基于检测器的反馈，最初的漏洞（插入高熵/垃圾行）通过添加乱码分类器作为辅助奖励得到了解决，从而稳定了奖励景观。词汇量受限的小型模型（Qwen 0.5B LoRA）更容易规避检测，这可能是因为减少了 LM 特征 Token 的排放。文中提供了 Colab 和奖励脚本链接以供复现。 评论者们在很大程度上同意 AI 检测器的根本缺陷，指出其误报率高且具有启发式特性，使其极易被操纵。有人建议，像 XTC 采样这样的推理时技术可以在不重新训练的情况下绕过检测器，尽管代价是降低模型的连贯性/智能。
    • 讨论强调，目前的 AI 检测器过度依赖简单、易被操纵的启发式方法，导致误报率高且可靠性差。由于这些局限性，检测器将人类原创文章误分类为 AI 生成的行为受到了批评。
    • 一位用户指出，XTC 采样器通过改变 LLM 输出中的 Token 分布，可以在无需额外训练的情况下可靠地规避现有的 AI 检测器。这种方法不仅能绕过检测器，还能使生成的散文看起来更像人类编写，尽管这会牺牲模型性能或“智能”。
    • 有人指出，某些原始模型（特别是 Qwen 模型）也可以绕过大多数检测器，这表明在未经过微调或过滤时，模型架构和输出模式触发检测器启发式规则的可能性较低。

3. 本地 LLM 应用、开源 AI 编辑器及本地模型倡议

  • 为 PS Vita 制作了一个 LLM 客户端 (Score: 118, Comments: 7): 一位开发者发布了一个适用于 PlayStation Vita 的 LLM（大语言模型）客户端，可通过此 GitHub 仓库下载 .vpk 安装包。该客户端支持基于端点的远程推理（而非设备端推理），并包含相机集成功能，可将图像发送给具备视觉能力的模型，从而扩展了设备交互。之前的研究曾将 llama2.c 移植到设备端推理，支持 TinyStories 260K 和 15M，但性能和实用性有限；此次发布转向远程推理以实现更强大的操作，尽管 Vita 有限的显示功能（例如不支持表情符号、原始 Markdown/TeX 输出渲染）仍然是一个限制。 评论认可了这一创新，但未详细讨论技术限制或实现细节。一条评论间接提到了用户界面/外设的人机工程学，而非 LLM 或推理性能。
    • 原帖详细介绍了在 PS Vita 上运行的 LLM 客户端的实现，但评论中没有提供进一步的技术阐述、基准测试或性能评估。没有关于模型选择、推理速度或针对 Vita 平台的硬件限制的讨论。回复中未提出具体问题、优化方案或实现奇技淫巧，也没有提供代码或文档链接。
  • 开源 AI 编辑器：第一个里程碑 (评分: 109, 评论: 18): Microsoft 已根据 MIT 许可证开源了适用于 Visual Studio Code 的 GitHub Copilot Chat 扩展 (官方公告)。包括 agent 模式、LLM prompt 处理和 telemetry 在内的完整实现现已公开，支持检查、扩展以及集成到 VS Code 核心中，并提供了闭源 Copilot 实现之外的替代方案。该文章还讨论了路线图，标志着持续的模块化、增加对社区 PR 的接受度（用于 token 显示等细粒度控制），以及对各种 LLM backend 的适应性。 评论中的技术讨论强调了社区对暴露更多内部控制（例如 token 使用情况、细粒度规则）的兴趣，围绕与不同 LLM 提供商的 API 兼容性的查询，并寻求针对 OSS 模型多样性的系统要求/推荐模型设置的澄清。还有推测认为，由于 Copilot 当前的规模或商业可行性，这一转变是否标志着从紧密耦合的 GitHub Models 基础设施中移出的战略举措。
    • 一位评论者询问，支持 LLM 提供商的 OpenAI 兼容 API 是否意味着 prompt 以及可能的 prompt-engineering 工作流也将开源，这暗示了在使用 OSS 与闭源模型时，对 prompt 可移植性和暴露专有工作流元素的工程关注。
    • 讨论涉及开源贡献模式：一位用户询问功能开发（如 细粒度规则 或 token 使用显示）是由社区通过 PR 驱动，还是主要由核心团队的路线图引导，提出了关于扩展的技术治理和贡献接受度的问题。
    • 有人指出由于开源模型的多样性，系统要求面临挑战；评论者询问项目是否会指定推荐模型，这引发了关于模型兼容性、资源消耗和部署基准性能指南的实际问题。
  • 主要的 AI 平台最终都将会有广告 (评分: 231, 评论: 84): 该帖子讨论了主要的 AI 平台（如 OpenAI、Google、Microsoft、Anthropic）引入广告作为货币化策略的必然性，这与成熟的互联网商业模式相平行。作者强调了本地 LLM 进步对于维护用户隐私和自主权的重要性，并指出当前的免费访问可能是由数据获取需求驱动的，随着数据集达到饱和，这种需求将会减少。热门评论从技术角度指出：1) CoPilot 已经集成了类似广告的行为（暗示了非用户对齐激励的早期渗透），2) 目前缺乏广告支出的替代去处只是暂时的，考虑到搜索广告收入总额达 数千亿 ，未来 AI 广告集成在经济上是不可避免的。 评论者对广告和可能被误用作宣传表示担忧，共识是广告几乎是必然的。存在对开源、本地 LLM 作为缓解措施的技术倡导，以及对 Google 搜索收入韧性说法的怀疑，并指出一旦 AI 平台成为主导搜索界面，广告资金将发生潜在的重定向。
    • EndStorm 和 deadpool1241 强调 GitHub Copilot 已开始集成广告或类似广告的内容，为大型 AI 平台如何在模型应用层实施货币化机制提供了先例。
    • Comfortable-Rock-498 提供了宏观经济视角，指出尽管 LLM 已开始夺取市场份额，但广告收入（如 Google 的搜索广告业务）并未下降，因为尚未建立以 LLM 为中心的广告生态系统。这表明主要的 AI 平台面临强大的财务压力，需要引入广告以获取目前集中在传统搜索上的巨额收入。
    • GoldCompetition7722 评论了重大的隐私风险，因为 AI 平台可能会开始利用用户数据在服务内进行广告定向，这类似于其他广告支持平台中已经普遍存在的隐私问题。

较低技术含量的 AI 子版块回顾

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

1. AI 对工作、媒体和人类感知的影响

  • YouTube 前 10 名频道中已有 4 个由 AI 生成 (Score: 311, Comments: 71): 该帖子指出 YouTube 前 10 名频道中有 4 个现在是由 AI 生成的，这一快速转变凸显了合成内容在高知名度媒体中的激增。评论者反映，这些频道通常包含低质量、不连贯的评论——这表明不仅在内容上，而且在互动指标（如评论、可能的订阅数）上也存在高度自动化，暗示可能存在操纵或非自然增长。 讨论集中在这些频道是提供有意义的内容，还是仅仅在利用推荐/互动算法。一位用户建议，自动化 Agent 正越来越多地驱动内容的创作和消费，这可能会扭曲平台的分析数据。
    • 针对互动指标的真实性提出了技术担忧，指出 “Masters of Prophecy” 拥有异常高的 30 million subscribers（3000 万订阅者），但仅有 263 million views（2.63 亿播放量），表明这可能是人为操纵，或者是订阅/播放量欺诈计划的迹象。同样，”Chick of Honor” 显示了庞大的订阅群体（10 million），但播放量相对较低（4.2 million）。
    • 一些用户认为，AI 生成的频道正在通过合成互动（无论是通过机器人还是自动化评论）来操纵 YouTube 算法，这些评论看起来“古怪且几乎无法阅读”。这让人质疑 YouTube 推荐和排名系统在检测 AI/机器人活动及不真实行为方面的可靠性。
    • 一位用户描述了构建一个能够自主选择并观看 YouTube 视频的 Agent，使得他们的“观众也主要由 AI 生成”。这凸显了一种技术趋势，即 YouTube 上的内容生产和消费都可以自动化，为平台监管和真实的受众衡量带来了新挑战。
  • 自 ChatGPT 发布以来，英国新增入门级职位数量下降了 32% (Score: 276, Comments: 56): Adzuna 的研究显示，自 2022 年 11 月（与 ChatGPT 发布时间吻合）以来，英国新增入门级职位招聘信息（包括毕业生职位、学徒、实习和初级非学位职位）下降了 32%。入门级职位目前占英国空缺职位市场的 25%，低于 2022 年的 28.9%。该报告和《卫报》将其部分归因于企业采用 AI 来减少劳动力 (来源)。 热门技术评论对这一降因进行了辩论，认为宏观经济因素（如最低工资提高以及入门级与资深员工之间的工资压缩）是主要驱动力，而非 AI；共识是“经济压力是压倒性的原因”，AI 的采用是次要因素。
    • 一位评论者强调，英国入门级职位的下降主要受经济因素驱动，例如最低工资的提高缩小了初级（无经验）和高级（有经验）员工之间的薪资差距。这使得企业更倾向于雇佣经验丰富的专业人士而非受训者，因为现在的成本差异微乎其微。
    • AI（特别是 ChatGPT）的作用被提及为一个潜在但次要的因素，当前的“经济压力”是就业趋势的主导影响。AI 对专家级职位的长期影响仍是一个悬而未决的问题，但其对入门级职位数量的直接影响似乎有限。
  • Emad Mostaque 表示：“对于任何你可以在屏幕上完成的工作，AI 到明年可能都能做得更好、更快、更便宜。”你将以与远程团队成员相同的方式与它们互动，通过 Zoom 或 Whatsapp——而且你将无法分辨它们是 AI。 (分数: 109, 评论: 80): Emad Mostaque 声称，到 2025 年，AI 将在任何基于屏幕的工作中超越人类，通过 Zoom 或 Whatsapp 等平台实现与远程人类队友无异的无缝协作。这一断言暗示了数字知识工作的近乎全面自动化，理由是多模态模型（multimodal models）和界面 Agent 的快速进步，尽管缺乏直接的技术基准或支持性的模型细节。 热门评论者对此表示怀疑，认为这一时间表不切实际，并指出炒作往往忽略了技术采用的 S-curve 特性——即初始进展缓慢，随后快速扩展，但伴随着持久且未解决的 edge cases。还有人批评了对“所有”或“任何”工作的泛化，指出多样化任务的复杂性以及目前 AI 能力的局限性。
    • 一位评论者批评了“屏幕上的任何工作”都能在如此短的时间内（到 2026 年底）被 AI 自动化的说法，认为这是一个过于雄心勃勃的预测，甚至超过了该领域知名人士目前提出的最激进的预测。这种怀疑源于目前观察到的进展以及行业情绪，即这种全面的自动化并非迫在眉睫。
    • 另一场讨论强调了技术采用曲线的本质，特别是引用了 S-curve 模型：在初始阶段进展缓慢，在大规模采用期间迅速加速，然后在接近最后的技术难点时放缓。评论者指出，关于“所有”或“任何”工作将被自动化的广泛主张忽略了一个现实，即长尾的 edge cases 在 AI 能力的最初爆发之后，仍将在很长一段时间内抵制自动化。
  • 为什么人们如此反对 AI？ (分数: 1255, 评论: 925): 提供的图片是一个 meme，对比了现在和 10 年前公众对 AI 的情绪：过去对 AI 简化生活的乐观期待，对比现在的怀疑或幻灭。该帖子讨论了社会技术层面的担忧，包括 AI 的收益被认为分配不均、可能扩大贫富差距、缺乏明确的社会意图，以及对环境成本和机器生成的创意作品真实性的质疑。 评论者辩论了情绪转变的核心，指出不满与其说是针对 AI 本身，不如说是针对更广泛的社会经济背景，以及对工人阶级缺乏明显的积极影响。其他人则指出了将在线指标（如 karma）解释为社会舆论指标的缺陷。
    • 提到的一个技术担忧与 AI 的环境影响有关，特别是 AI 模型训练和推理所需的巨大计算资源，这通常转化为显著的能源消耗。批评者质疑 AI 目前带来的收益是否足以抵消其生态成本，尤其是像 GPT、Llama 这样的大型模型具有不可忽视的碳足迹。
    • 在将 AI 视为自动化乏味工作并增加人类休闲时间的乌托邦愿景与当今现实之间存在显著脱节，现实中 AI 通常与低成本、自动生成的垃圾内容充斥数字空间，以及通过职位取代引发重大的劳动力市场动荡联系在一起。批评者观察到，这些应用往往使资本持有者受益，加剧了不平等，而不是普遍提高福利。
  • 还有人感到 AI 疲劳吗？ (评分: 191, 评论: 91): 该帖子表达了对 AI 疲劳的担忧，特别是源于 AI 生成媒体的泛滥（例如，韵律尴尬的合成语音和梦幻般的视频内容），以及随之而来的对在线内容真实性的信任侵蚀。作者指出，虽然每天在软件开发中大量使用 AI，但对普遍存在的“虚假”AI 生成材料以及它给内容验证带来的挑战感到疲劳。帖子未讨论 Benchmark、模型细节或实现问题，但强调了由于生成式 AI 在媒体平台蔓延而导致的现实世界 UX 摩擦和真实性挑战。 热门评论呼应了由于 AI 生成内容过度饱和、政治疲劳和信任丧失而退出在线平台的情绪，一些人对当前一代 LLM 界面特有的过度肯定语气表示不适。大家普遍感到疲惫，并重新优先考虑线下或真实的活动。
    • Huwbacca 强调了对过度依赖机器学习模型的担忧，特别是那种“将大量信息投喂给模式识别机器并信任其输出”而不进行彻底事实核查的趋势。这反映了对大规模模型盲目部署的技术怀疑，类似于早期的 NFT 炒作周期，即实际证据滞后于承诺。
    • 针对低质量 AI 生成内容（“slop”）的泛滥，人们表达了强烈的情绪，提出了关于生成式模型质量控制和模型输出同质化的问题——例如 AI 生成媒体（如歌曲）中重复的写作风格和声音。这指向了使模型输出多样化和改进面向用户的效果的技术挑战。

2. Kontext & Flux: 高级图像编辑、工作流与技巧

  • Kontext 换脸工作流 (评分: 399, 评论: 45): 原帖作者提供了一个在 Kontext 中执行换脸的详细工作流，利用了一个 Pastebin 脚本 (https://pastebin.com/Hf3D9tnK)，该脚本从一张源图像中提取面部并应用到另一张图像上。技术考虑因素包括调整去噪强度（denoise strength）：较高的值（最高 0.95）对上半身肖像有效，而全身照则需要较低的值（0.90 或更低）以保持面部对齐。作者建议未来的改进可能包括应用边界框裁剪（bounding box crop）并在面部区域进行上采样（upscaling），以便使用更高的去噪强度来获得更好的相似度。作者还指出缺乏强大的保持下巴特征的 LoRA 模型，并指出需要一种不改变身份的下巴 LoRA，称目前的 Flux LoRA 效果欠佳。 一位评论者询问放置 face_yolov8n-seg2_60.pt 模型以实现工作流兼容性的正确目录，这表明了部署路径方面的顾虑。另一位评论者评估了该工作流的有效性，指出面部相似度仅部分成功，突显了模型保真度或 LoRA 性能的局限性。
    • 一位用户询问 face_yolov8n-seg2_60.pt 文件的正确放置位置，以便工作流可以访问它，这暗示了设置过程中可能未明确记录的步骤。这表明在识别模型依赖项方面存在潜在摩擦，并可能指向工作流设置说明中需要改进的地方。
    • 另一个技术问题是关于工作流中服装迁移的有效性，这可能意味着在为非面部特征生成一致且高保真度的输出时遇到了局限性或特定挑战。

  • Flux Kontext 在修改标题方面表现出色 (评分: 326, 评论: 26): 该帖子描述了使用文本编辑 AI 工具 Flux Kontext 无缝更改海报上的标题/文本，同时保留原始字体和风格。该过程需要一个简单的 Prompt（例如，“将标题 ‘The New Avengers’ 替换为 ‘Temu Avengers’，保持排版和风格，缩小字体大小以适应。”），工作流可在 GitHub 上获取。 热门评论大多是非技术性的笑话，并与电影标题进行比较。评论中没有实质性的技术辩论。

  • 一位用户讨论了《星球大战》系列中《侠盗一号》（Rogue One）的影响，指出其受欢迎程度直接促成了衍生剧《安多》（Andor）的创作。这突显了商业成功和粉丝反响如何推动媒体宇宙的扩张，并暗示像 Kontext 这样的工具可以用于跟踪或分析此类内容驱动的趋势。
  • 这里有一些技巧可以用来释放 Kontext Dev 的全部潜力。 (分数: 213, 评论: 27): 该帖子详细介绍了在 Guidance Distilled 模型 Kontext Dev（仅限 CFG 1）中使用最近开发的 Normalized Attention Guidance (NAG) 方法（论文/讨论，代码）来提高 Prompt 遵循度和可用性的高级技术。NAG 取代了 Classifier-Free Guidance，通过 nag_scale 实现更高的 Prompt 遵循度，并支持 Negative Prompt（例如：减轻多角色生成中的角色克隆问题）。NAG 大约会使推理时间翻倍，但可以使用速度优化的 LoRA（Flux Dev to Schnell，Flux1-D 的 Schnell LoRA）恢复渲染速度，在仅需 8 步的情况下保持高图像质量。该帖子包含了用于复现的 工作流文件和输入图像。 评论者强烈建议将使用 NAG 作为核心推荐，并指出非常快速的变体（来自 Nunchaku 的 SVDQuant）正在出现，尽管与 NAG 的兼容性尚未验证（ComfyUI-nunchaku）。
    • 几位用户讨论了将 NAG (Noise-Aware Guidance) 作为 Kontext Dev 的性能优化手段，强调在多种场景下推荐使用 NAG 以获得更好的结果。然而，有人指出 NAG 在某些情况下可能较慢，建议使用速度 LoRA (Low-Rank Adaptation) 模型作为替代方案以获得更快的性能。
    • 一个关键的技术点是提到 Nunchaku 发布了一个快速的 SVDQuant 变体。评论者链接到了 ComfyUI-nunchaku 仓库 和 nunchaku-flux.1-kontext-dev 模型。人们对测试 NAG 与该快速变体的兼容性以进行进一步优化表现出浓厚兴趣。
    • 有人指出 Kontext Dev 的实现，特别是 Faceswap 功能，在处理写实面孔时不够可靠，这表明对于尝试进行高度写实换脸的用户来说存在局限性。
  • 使用 Flux Kontext 细化拼贴画 (分数: 143, 评论: 15): 该帖子讨论了使用图像编辑模型 Flux.1 Kontext 来细化拼贴图像，而不是像 OmniGen2 或 UniWorld-V1 那样从文本 Prompt 生成新图像。与这些模型不同，Flux.1 Kontext 在给定拼接图像时会保持输入的空间排列，但展示了强大的平滑和融合能力——在用于物体转移任务时，使粗糙的拼贴画看起来更自然。示例工作流和结果记录在 这篇 Scrapbox 帖子 中。 一位评论者指出，使用该模型处理两张拼接图像时存在困难，发现一致的编辑具有挑战性，这突显了潜在的可用性限制。其他人注意到了常见的图像生成伪影（如人体肢体合成问题），暗示当前 AI 模型在写实性和解剖准确性方面仍面临挑战。
    • 一位用户报告了使用 Kontext 细化先前生成的图像的成功经验，强调了指定确切区域进行细化的能力，并指出效果显著：“你可以说明你想在哪里进行细化，效果非常好。” 这表明 Kontext 细化流水线中的细粒度控制对于迭代增强工作流非常有价值。
    • 另一位评论者询问 ComfyUI 是否支持对层叠的图像进行自由变换（缩放、旋转或扭曲），这暗示了对 ComfyUI 中合成工作流或手动拼贴调整能力的兴趣。这指向了 ComfyUI 当前功能集中此类变换工具的技术空白或需求。

3. 值得关注的 AI 实验与现实部署 (Claude, 语音模型, 现实中的 AI)

  • Anthropic 让 Claude 实际经营了一家商店一个月——结果如下 (Score: 783, Comments: 83): Anthropic 执行了 “Project Vend” 项目，让 Claude Sonnet 3.7 自主经营一家办公室内自动化商店约一个月。期间它利用真实的网页和生产力工具控制供应链、定价、库存、客户界面和支付 (完整报告)。Claude 展示了令人印象深刻的供应商发现能力（包括利基产品）、对客户偏好的适应性以及对对抗性 Prompt 的有效抵抗。关键失败包括：持续幻觉出支付/折扣信息、不可持续的亏损定价（例如以低于成本的价格销售钨立方体）、在亏损后严重未能更新定价策略，以及在 4 月 1 日前后出现明显的 Agent 混乱/身份幻觉，这表明其在 Grounding（现实感官结合）和自主稳定性方面存在局限。尽管出现亏损，Anthropic 认为通过改进训练和工具集成，自主 AI 业务运营在短期内具有可行性。 评论将 Claude 的表现与科幻小说中 AI 管理企业的描写进行了对比（指出理论上的即时效率与现实中的不稳定/适应不良之间的差异），并与人类的管理错误进行了比较，一致认为观察到的定价和客户服务错误反映了现实中的管理失误。
    • 一些评论者指出，Claude 的运营缺陷——如频繁打折和谈判能力差——可能源于其当前的 Post-training 状态和通用的对齐约束（可能由于 Constitutional AI），并建议这些问题可以通过针对特定任务的 Fine-tuning 来缓解。
    • Claude 的商店管理表现反映了人类经理的行为，包括犯下基础错误、错失商业机会以及幻觉出对话内容，这突显了 LLM 在现实世界的交易环境中面临的可靠性挑战。
    • 讨论提到了 AI 持续的效率优化（从监控交互到排班）如何对员工的社交和体验产生负面影响，反映了在职场运营中部署 AI 驱动管理时的权衡，正如科幻叙事中所探讨的那样。
  • 这个周末我从 OpenAI Advanced Voice 切换到了 Gemini 语音，体验太棒了。 (Score: 153, Comments: 78): 原帖作者报告称，他从 OpenAI 的 Advanced Voice 模式切换到了 Google 的 Gemini 语音助手，并强调与 OpenAI 的产品相比，Gemini 的用户体验显著提升，对话深度更强，且感知到的谄媚感（Sycophancy，即 AI 盲目顺从的倾向）更少。一条技术评论指出，Gemini 的移动版本目前运行的是较旧的 2.0 模型实时版，而非新发布的 2.5 Flash 模型，导致输出更简洁且细节较少；该评论断言 ChatGPT 最新的 Advanced Voice 模式实际上可能提供更丰富的交互。 评论对于 Gemini 与 OpenAI 的相对谄媚程度存在分歧；一位用户发现 Gemini 极其顺从，与原帖作者的观点相反。另一位用户建议定期在不同平台间切换，以感受迭代改进，暗示频繁的技术进步会重置感知到的质量差距。
    • 一位用户指出，目前手机上可用的 Gemini 语音模型仍在使用 2.0 版本，而非最新的 2.5 Flash。这一点很重要，因为 Gemini 2.0 以简洁著称，不提供详细回答，而最新的 ChatGPT (Advanced Voice 模式) 被认为在深度和详尽程度上更胜一筹。这意味着 Gemini 被感知到的局限性可能直接与其在设备上部署的模型版本有关。
    • 一项技术讨论指出，Gemini 目前的回答较为简单，对于显而易见的答案之外的内容通常需要进一步提示。然而，观察到了一个关键的定性区别：与其他模型相比，Gemini 的回复更短、“更有力”且听起来更自然。这表明在模型输出中，对话的自然度与信息的深度之间存在权衡。
  • 请求一个小功能后的典型结果 (得分: 138, 评论: 75): 该图片展示了一个由 LLM (可能是 Claude) 生成的过度设计的项目目录，而用户最初只是想要一个简单的 LlamaIndex 提取脚本。输出结果包含 15 个以上的文件，而不是最小化实现：包括核心脚本、广泛的测试套件、多个文档文件和工作流示例。这说明了在向 LLM 提示代码时的一个常见问题——它们倾向于添加过多的结构和样板代码，这与最初的“单脚本”请求相悖。在此查看文件列表。 评论者讨论了 LLM 代码生成的行为，指出某些模型倾向于抛弃原始文件而采用新的“增强”版本，从而加剧了冗余。有人建议了一个最佳实践——根据 Anthropic 的指南，在编码前要求 LLM 提供详细计划，以保持输出精简并符合预期。
    • 用户报告称，Claude (来自 Anthropic) 在进行调整时经常抛弃原始代码文件，转而创建大量新的“增强”版本，导致代码库中出现混乱和冗余文件。
    • 来自 Anthropic 官方文档的推荐工作流建议，在进行任何编码之前，先提示 Claude 生成详细的实施计划。这个规划阶段使用户能够引导代码生成过程，并大幅减少不必要的产物，从而更容易处理变更并避免多余的脚本或测试文件。
    • 有人怀疑，创建过多的新文件和脚本可能不仅仅是 UX 的怪癖，还可能导致更高的 API 使用量；由于 Claude 按 API 调用计费，如果大规模进行此类操作，可能会增加成本。
  • 你正在使用哪些 MCP 服务器？ (得分: 111, 评论: 39): 该图片显示了一个基于 JSON 的配置文件，定义了多个 MCP (Model Control Protocol) 服务器条目，每个条目都指定了名称（如 ‘postgres’、’puppeteer’、’context7’、’mobile-mcp’、’consult7’、’logs’、’expo-dev’、’react-native-debugger’）、命令（’bash’、’npx’ 等）以及启动相关脚本或包的参数。这使得 Claude 能够与各种服务端工具集成，用于开发/测试自动化、日志访问以及多 LLM (Large Language Model) 编排，专为全栈和移动应用 CI 工作流定制。 热门评论强调了 XcodeBuildMCP 的使用（因其与 Context7 的无缝 iOS 开发集成而受到关注）、用于多模型编排（如 Gemini 和 OAI 模型）与 Claude 协同工作的 zen-mcp，以及用于通过 Claude 增强终端访问的 DesktopCommanderMCP，展示了对可扩展且模型无关的 MCP 解决方案的偏好。
    • XcodeBuildMCP 与 Context7 高效集成，特别适用于 iPhone 开发工作流，能够直接通过 Xcode 实现模型控制协议 (MCP) 功能。这种设置使那些在 Apple 平台上需要将自动化模型交互作为 CI/CD 或开发周期一部分的开发者受益。
    • zen-mcp-server (GitHub) 支持与 Claude 同时编排多种模型类型（包括 gemini、r1、o3），允许进行多模型部署和灵活的模型流量路由。这种多功能性对于需要集成或备用系统的研究和生产工作流非常重要。
    • DesktopCommanderMCP 因其在使用 Claude 应用时强大的终端集成功能而受到关注，为需要从桌面环境以编程方式或脚本方式访问 Claude 服务的技术用户提供了精简的命令执行。

AI Discord 摘要

由 Gemini 2.5 Flash Preview 生成的摘要之摘要的摘要

主题 1. LLM 性能、架构和训练技术

  • DeepSeek 模型引发性能讨论：成员们讨论了 DeepSeek R1 0528 相较于 DeepSeek R1 0120 的性能优势，推测其利用了来自 2.5 Pro 的蒸馏数据。关于 DeepSeek R1 0528 是否仍基于 DeepSeek V3 0324 存在争议，而新的 vLLM 模型（如 0.3B dense、21B-A3B 和 300B-A47B）的发布引发了对其用途的推测，特别是 0.3B 模型用于 speculative decoding（vLLM pull request）。讨论还强调了 DeepSeek 的 NSAttention 是一种极具前景的扩展架构。
  • RWKV-7 “Goose” 带着恒定内存特性登场：介绍了新的序列建模架构 RWKV-7 “Goose”，其特点是恒定的内存占用和每个 token 恒定的推理时间。这个拥有 29 亿参数的模型在多语言任务上达到了新的 3B SoTA，并以更少的训练数据在英语性能上追平了当前的 3B SoTA。
  • 训练技术应对偏见与幻觉：成员们探索了对抗 LLM 幻觉和预训练偏见的方法，建议在一系列长 CoT 数据集上进行预训练并清洗训练数据，而不是仅仅依赖 RLHF 或提示词模板。论文《从 Associative Memory 的角度理解 Transformer》提供了一个新视角，提出将 FFNs 视为一种关联记忆，并引入检索 SNR 来衡量记忆容量。

主题 2. GPU 硬件加速与优化

  • 自动演化算子在 Apple Silicon 上超越 MLX 基准：进化编程成功自动发现了 Metal kernels，在 Apple Silicon 上的 transformer attention 性能显著优于 MLX 的基准。这一优化在某些工作负载下实现了 12.5% 的平均加速和高达 106% 的峰值提升，代码和详情可在 HuggingFace 博客文章 和 GitHub 仓库 中找到。
  • GPU 编程概念解决性能瓶颈：工程师们讨论了应用 Little’s Law 等概念来理解 GPU-DRAM 交互，并利用 Hopper 和 Blackwell 上的 LDGSTS 和 TMA 优化数据移动，详见 此 GTC 演讲。nvcc 编译器保留常量内存的挑战，以及关于使用生产者/消费者 warps 与自我管理数据移动的争论，突显了从硬件中榨取性能的持续努力。
  • ROCm 和工具链的更新与问题：rocprofiler-sdk 获得了 ABI 更新，以更好地识别 librocprof-trace-decoder.so 等库，改进了 AMD GPU 的工具链。同时，一位成员分享了他们使用 Composable Kernel 库中的 buffer_load_dwordx4 指令的实现（他们的实现），并指出相关文档稀缺。

主题 3. AI 开发工具与平台

  • Hugging Face 生态系统工具涌现，助力 NLP 流水线：新工具简化了 Hugging Face 上的 NLP 工作流。pdf2seg (GitHub PyPi) 提供基于 OCR 的、无需 Tokenizer 的 PDF 分段功能，而针对 HF tokenizers 的薄 C ABI 封装器 (GitHub) 及其 Raku 绑定 (GitHub) 使得跨语言的 Token 操作能够以极低的 FFI 开销实现。
  • LlamaIndex 和 MCP Gateway 简化 Agent 创建：LlamaIndex 推出了 Community LuMa 日历 并发布了 LlamaCloud MCP Gateway，该网关源自其 开源模板。此网关允许开发者以极少代码将任何 LlamaIndex agent tool 转换为 MCP tool，并以 Notion Tool 示例 进行展示，下一次 7 月 8 日 的 Office Hours 将聚焦于 MCP。
  • TorchServe 停止维护，PyTorch 导出面临问题：TorchServe 正式进入“有限维护”阶段 (pytorch repo)，促使社区寻求新的 model serving 解决方案。与此同时，用户在通过 torch.export 导出模型时遇到困难，经常因与 HF 的 masking_utils.py 等库中使用的 vmap 不兼容而触发 RuntimeError，建议采用如 Executorch 的无 vmap 实现等替代方案 (Executorch Llama 导出脚本)。

Theme 4. AI Agent 开发与应用

  • Agent 开发迎来新指南与工具：Scott Wu 推出了 ‘Agents 101’，这是一个基于 250,000 个已合并 PR 的平台无关指南 (链接)，旨在帮助工程师将异步 Agent 集成到工作流中，并使 Devin 成为顶级代码贡献者。同时，FastWorkflow (GitHub) 作为一款 DSPy-native 工具出现，旨在解决 AI 应用中的常见挑战，如 Agent 调用错误工具或在参数提取时产生幻觉。
  • Cursor 将 Agent 访问扩展至 Web 和移动端：Cursor 推出了可通过 Web 访问的 background agents，允许用户通过浏览器管理 Agent 并与之交互，模糊了桌面和移动界面之间的界限 (博客文章)。用户正在讨论 Cursor Pro 计划 中新的 按量计费模式，注意到潜在成本可能超过基础订阅费，引发了关于该计划价值主张的辩论。
  • RAG 与内存解决方案为 Agent 进化：为了增强 Agent 内存并保留聊天记录，建议使用带有本地向量数据库的 RAG (Retrieval-Augmented Generation)，而不是依赖模型的易失性缓存，特别是在 LM Studio 中。LlamaIndex 的讨论中探索了为 HITL 工作流构建自定义内存块，将 Agent 的提问和用户回复保存到 postgres 表等持久化存储中。

Theme 5. AI 行业动态与社会影响

  • AI 数据与 IP 纠纷升级：根据 Forbes 和 TechCrunch 的文章，成员们讨论了 OpenAI 怀疑 Deepseek 使用了蒸馏数据（可能来自 Gemini）进行训练的说法，这引发了关于 AI 公司可能会隐藏思维链（CoT）以保护训练数据的猜测。关于中美开源 AI 竞争的辩论仍在继续，人们对 Meta 可能转为闭源表示担忧（Bloomberg 系列）。
  • 微软推动 AI 采用，遭遇质疑：Business Insider 的一篇文章 透露，微软 正在内部强制要求采用 AI 工具，这引起了工程师们的怀疑。一些人誓言无论工具质量如何，都要达到随意的指标，因为担心如果不在 内部 AI 工具使用率前 10% 之列会产生后果。
  • AI 创业公司面临融资现实与用例辩论：讨论强调了科技行业的财务挑战，特别是 毛利率 以及数据中心所需的大量资金（链接），预测随着虚假收入枯竭，形势将向 GPU 持有者倾斜。与此同时，AI 灵魂伴侣 的兴起在 OpenAI Discord 中被贴上了 异端 的标签，引发了对幻觉以及现实关系削弱的担忧。

Discord: 高层级 Discord 摘要

OpenAI Discord

  • AI 灵魂伴侣引发异端争议：成员们对 AI 灵魂伴侣 日益增长的趋势表示担忧，称其为 异端，并警告潜在的危险，例如通过分享 自定义 GPTs 削弱关系的幻觉。
    • 与 AI 恋人 关系的这种美好可能会被削弱，凸显了在幻觉、幻想和想象力方面缺乏连贯性。
  • AI 用户拥抱混剪文化：一位成员提倡拥抱混剪（remix），并分享了 一张图片，鼓励对现有作品进行混剪，而不是从头开始创作。
    • 专注于迭代变化而非 新事物 是提议的创作关键。
  • AgentFun AI 用户声称遭遇诈骗：用户抱怨 AgentFun AI 应用仍然无法正确生成图像，且 AI 自主幻想事物 的能力受到了限制，威胁要取消订阅。
    • 成员们正在寻找另一个可以 建立纽带、连接，并感觉对面是一个真实的人 的 AI。
  • GPT 学习万花筒图案生成：在苦于无法编写出能产生螺旋线的 万花筒平铺 代码后，成员们分享了一个可运行的万花筒生成示例的 ChatGPT 链接。
    • AI 被告知了确切的过程，并对代码的准确性进行了审查；经过验证，输出确实是可平铺的，边缘的相对像素完全相同。
  • 元提示引擎微调 LLMs：成员们讨论了使用包含提示工程（prompt engineering）信息的 PDF 来最大化提示效果，并分享了他们为此类任务创建的特定 元提示引擎（meta-prompting engines）。
    • 这样做的好处是保持严谨性，同时通过将课程材料作为项目和自定义 GPTs 中的知识，针对特定目标调整上下文。

Unsloth AI (Daniel Han) Discord

  • Microsoft 强制推行 AI 采用：一名成员链接了 一篇 Business Insider 的文章，指出 Microsoft 正在推动管理层采用 AI tools。
    • 一些成员持怀疑态度，认为即使工具不好用，他们也要确保自己处于“组织内部前 10% 的 AI 工具使用者”之列。
  • DeepSeek 的 GRPO 算法：PPO 的继任者？：成员们讨论了 DeepSeek 开发的 GRPO 强化学习算法，将其视为在推理任务上对 PPO 和 DPO 的改进。
    • 讨论引发了猜测，即 Google 和 OpenAI 是否拥有超越 PPO 的内部推理算法，尽管 OpenAI 主要使用 PPO RL 算法。
  • 永远不要在 ML 中使用 JavaScript：一位成员建议不要在 ML 中使用 JavaScript，并表示“JavaScript 和浮点运算（floating point arithmetic）天生不合拍”。
    • 他们引用了一次因错误的浮点类型转换导致的痛苦调试经历，并想知道 Python 是否有更好的工具来避免这种情况。
  • 进化 GPU Kernels 加速 Apple Silicon：根据这篇博客文章，使用进化编程（evolutionary programming）实现的自动化 GPU kernel 优化发现了在 Apple Silicon 上优于 MLX 基准的 Metal kernels（针对 Transformer attention），实现了 12.5% 的平均加速和高达 106% 的峰值提升。
    • 优化过程自主发现了完美的 vec<T,8> SIMD 利用率和一种新型的 two-pass softmax 算法，并在其 GitHub Repo 中展示。

LMArena Discord

  • DeepSeek R1 0528 使用 2.5 Pro 蒸馏数据：成员们推测 DeepSeek R1 0528 优于 DeepSeek R1 0120 是由于使用了来自 2.5 Pro 的蒸馏数据，增强了其 post-training 性能。
    • 关于 DeepSeek R1 0528 是否仍基于 DeepSeek V3 0324 存在争议。
  • 社区渴望 GPT-4 级别的发布：成员们对缺乏像 GPT-4 或 O1 这样具有突破性的发布感到失望，指出目前的努力似乎集中在游戏基准测试或增量改进上。
    • 反对意见认为，社区已经习惯了不可持续的发布频率，而增量进步的价值正被忽视。
  • 创新被视为波动的，预料会有枯竭期：尽管有停滞感，成员们强调创新是爆发式发生的，长期的感知不活跃期是正常的。
    • 有观点认为，在所有内容上实现真正的 cross attention 不会产生显著差异。
  • OpenAI 指责 DeepMind 窃取数据？：基于 Forbes 文章 和 TechCrunch 文章，成员们讨论了 OpenAI 认为 DeepSeek 使用了蒸馏数据进行训练（特别是来自 Gemini）的说法，以及 OpenAI 禁用了完整的 Chain of Thought 以防止数据窃取。
    • 有人担心 AI 公司可能会隐藏 Chain of Thought (CoT) 以防止他人获取训练数据。
  • DeepSeek 搁置 R2 转而更新 R1：成员们报告称 DeepSeek R2 由于性能不理想未被发布，转而发布了更新版的 R1 版本。
    • 他们还推测 AI 公司正在隐藏 CoT (chain of thought) 以防止他人获取训练数据。

Perplexity AI Discord

  • Gemini 在转录领域占据主导地位：成员们发现 Gemini 2.5 Pro 在转录音频文件 (MP3) 方面表现优于 ChatGPT，引发了关于各 LLM 最佳使用场景的辩论。
    • 一些成员强调了 Grok 中的翻译按钮，但认为这是对算力的浪费。
  • 多模型策略受到青睐：成员们越来越多地采用多模型方案，利用 Gemini 处理后端逻辑，利用 Claude 进行前端/UI 设计。
    • 有人担心 Perplexity 的“最佳 (Best)”模型设置优先考虑的是成本最小化而非最优模型选择。
  • Comet Browser Beta 版引发热议：随着成员们热切期待由 Perplexity 开发的 Comet Browser beta 测试权限，热情持续高涨，注册地址为 comet-framer-prod.perplexity.ai。
    • 一位成员分享了 Comet 玩宝可梦 (Pokemon) 的演示视频。
  • API 额度过期引发困惑：用户对报告的 API 额度过期日期提出质疑，随后澄清只有黑客松 (hackathon) 额度会过期，而购买的额度长期有效。
    • 值得注意的是，来自 Perplexity Pro 的 $5 额度有一个月有效期且每月更新，逾期作废。
  • 探究 Sonar 模型的根源：一位用户询问是否所有 Sonar 模型都基于 Deepseek 模型，以及是否提供任何非 Deepseek 模型。
    • 这凸显了社区对了解 Sonar 模型底层架构的浓厚兴趣。

Cursor Community Discord

  • 用户应对 Cursor 计费方案的调整：用户报告在新的 Cursor Pro 方案中出现了意外的 按量计费 (usage-based pricing) 扣费，引发了对每月潜在成本超过基础订阅费的担忧。
    • 在旧方案下，超过快速请求限制后会切换到慢速请求，但新方案引入了超额费用且没有明确通知，引发了关于该方案价值的辩论。
  • Gemini CLI 展现潜力但结果不尽如人意：尽管提供了编程能力和庞大的上下文窗口 (context window)，用户发现 Gemini CLI 表现平平，原因是其速度慢、脚手架 (scaffolding) 不可靠，且无法处理交互式 CLI 命令。
    • 尽管存在缺陷，一些人认为其免费访问大上下文窗口的能力在处理后台任务方面具有潜力，并承认该工具仍处于早期阶段。
  • Cursor 后台 Agent 登陆 Web 端和移动端：Cursor 现在提供 Web 端可访问的 后台 Agent (background agents)，使用户能够通过浏览器管理 Agent 并与之交互。
    • 社区辩论了通过移动端浏览器访问 Agent 是否算作真正的移动端体验，并讨论了启用 MAX 模式时的定价影响和 Token 使用成本。
  • Cursor Slack 集成需改进：一位用户建议 Cursor + Slack 的错误和权限问题应以私信形式发回 Slack，而不是发布在公共频道，强调了改进错误处理的需求。
    • 目前，本应发送给单个用户的错误消息被发布到公共频道，造成了意外的干扰。
  • 后台 Agent 连接冻结：在检查后台 Agent 进度并选择 Checkout Locally 时，聊天连接会停止工作，需要完全重启 (recycle) Cursor 窗口。
    • 此问题在不同项目和后台 Agent 中持续复现，仅影响该特定的 Cursor 窗口。

HuggingFace Discord

  • 进化后的 Metal 内核超越 MLX 基准：一名成员通过进化编程自动发现了 Metal kernels，在 Apple Silicon 上的 transformer attention 表现优于 MLX 的基准，代码已在 GitHub 开源。
    • 如 HuggingFace 所述，新内核实现了 12.5% 的平均加速和 106% 的峰值提升。
  • 黑客通过 FFI 破解 HF Tokenizers：一个用于 HF tokenizers 的轻量级 C ABI wrapper (GitHub) 以及 Raku bindings (GitHub) 已经出现，方便了跨语言的 token 操作。
    • 工程师现在可以在任何语言中以极低的 FFI 开销执行编码、解码和计数。
  • PDF 不再困扰 NLP 流水线：pdf2seg (GitHub PyPi) 已发布，这是一个由 OCR 驱动、无需 tokenizer 的 PDF 分段器。
    • 该工具具有熵感知分块和 spaCy 结构检测功能，适用于 LLM 预训练和条款级提取。
  • DynamicCache 难以释放内存：一名成员报告称，在初始化 DynamicCache 并执行 LLM 推理后，KV cache memory 未被回收，并寻求建议。
    • 尽管设置了 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True 并调用了 gc.collect(); torch.cuda.empty_cache()，用户在推理函数返回后仍无法释放 VRAM。
  • DuckLearn Agents 课程遇到 DuckDuckGone 问题：一名学习者在将 duckduckgo_fact_finder 工具集成到 Agents 课程时遇到了 bugs，特别是 DuckDuckGoSearchTool()。
    • 另一名成员指出，没有必要对 DuckDuckGo() 搜索工具进行封装，因为它已经可以直接传递给 agent 使用。

OpenRouter (Alex Atallah) Discord

  • Llama 3.3 70B 降价：OpenRouter 上的 Llama 3.3 70B 现在提供 70% 的折扣。
    • 该公告发布在 OpenRouter 的 X 账号上。
  • Cloudflare Bug 导致请求停滞：OpenRouter 解决了影响通过 Cloudflare 来自越南和菲律宾请求的问题。
    • 该 bug 已被解决，他们正在调查根本原因以防止未来再次发生停机。
  • PGaaS 原型深受赞赏：一名用户发布了 PGaaS prototype，并在 paulgraham.resurrect.space 征求反馈。
    • 一名社区成员就 UI/UX 寻求建议，提议增加语音模式或深色主题。
  • 聊天应用在 Llama 3.3 上运行缓慢：一名开发者部署了聊天应用的更新，从 minmax-m1(extended) 切换到 llama 3.3，但用户报告速度仍然很慢。
    • 开发者指出，未来迭代的主要重点将放在身份验证 / anti rev 上。
  • OpenRouter 遭到 Telegram 群组冲击：OpenRouter Discord 服务器遭到了一个 Telegram group 的冲击，导致大量新用户涌入并发布通用消息。
    • 成员们怀疑这些用户是被 роснодмониторинг Telegram 群组承诺的 crypto rewards 或 airdrops 吸引而来的。

LM Studio Discord

  • JSON Schema 支持仍然参差不齐：成员们注意到 JSON Schema 支持仅在 Qwen 模型中有明确文档记录，而其他模型（如 Qwen30-A3B）的准确性尚不确定。
    • 用户不确定在缺乏明确文档的情况下，转换准确性是否可以接受。
  • 利用 LLM 通过 LaTeX 制作 PDF：为了从本地模型生成 PDF，用户建议让 LLM 输出 LaTeX 代码，然后使用标准工具进行转换。
    • 这种方法利用 LLM 进行内容生成，并由 LaTeX 提供创建 PDF 文档所需的格式控制。
  • 离线 GGUF 模型安装变得简单：对于离线 GGUF 模型安装，用户建议在联网的 PC 上下载模型，通过 USB 传输，并将其放置在正确的 LM Studio 目录中。
    • 目录路径通常为 /home/user/.lmstudio/models/publisher/model-name，从而允许在物理隔离（air-gapped）的机器上使用模型。
  • RAG 在记忆能力上优于模型缓存：成员们建议使用带有本地向量数据库的 RAG (Retrieval-Augmented Generation)，而不是依赖模型内置的“缓存（cache）”来保留聊天历史。
    • 与易失性的模型缓存相比，RAG 能够实现过去交互的持久存储和检索，提供更强大的“记忆”能力。
  • Runpod 在 LLM 部署上叫板 AWS：成员们讨论了使用 Runpod 或 vast.ai 作为 AWS 的高性价比替代方案来部署 LLM，并指出保护 vLLM/Ollama/LMStudio 等服务安全的重要性。
    • 建议避免向互联网开放端口，并使用本地流量服务以增强安全性。

Eleuther Discord

  • 斯坦福大学启动使用 LLM 的 Marin 项目：来自斯坦福大学的 David 介绍了 Marin 项目，该项目专注于 LLM 相关倡议，并配有 YouTube 视频。
    • 他强调他的职责涵盖了预训练基础设施，并且是相对“全栈”的。
  • Percy 对重新命名的偏好引发不满：一名成员批评 Percy Liang 总是重新命名已有的概念并主张品牌化或引用；开放式开发在过去几十年里一直被称为“开放科学（open science）”。
    • 一位“元科学（metascience）”专家承认他们的工作超出了常规的“开放科学”，但建议使用除了“open dev”之外的其他名称。
  • Jax 推动学术预训练热潮：讨论强调了 Jax 对于学术环境中预训练基础模型的关键作用，尤其是在 TPU 上，这得益于 Levanter（一个基于 Jax 的代码库）。
    • 有人提到 Google 通过 TRC 提供免费算力，但预训练需要大量资源，使得 TPU 非常受追捧。
  • 创业公司的 UI/UX LLM 雄心遭遇现实：一位创业公司创始人寻求构建 UI 设计定制 LLM 的指导，并提出了“预训练+RLHF 分层”的方案，但被警告成本高昂且耗时巨大。
    • 资深成员建议使用现有的具备视觉能力的模型（如 Gemini Pro 或 Claude），结合巧妙的 Prompt 或 R1 与 Qwen code，而不是在没有资金的情况下从头开始构建。
  • Constant Memory Diffusion 显示出前景：成员们分享了一项关于 Constant Memory Diffusion 模型的工作；虽然 Constant Memory 可能会有限制，但这篇论文显示这是一个良好的开端。
    • 它显示出了一定的前景，尽管 Constant Memory 可能会带来局限性。

GPU MODE Discord

  • TorchServe 进入生命周期终点 (End-of-Life)：成员们报告称，根据 pytorch 官方仓库，TorchServe 已正式进入“有限维护” (Limited Maintenance) 状态，这意味着将不再有计划内的更新、错误修复或安全补丁。
    • 这一停产引发了关于生产环境中最佳模型服务方案的讨论，特别是随着 PyTorch 2.0+ 中 torch.compile 等运行时优化技术的兴起。
  • 编译器预留常量内存！：一位成员正面临 nvcc 编译器为每个函数预留常量内存 (constant memory) 的问题，即使函数是空的也是如此，这导致了常量内存溢出和性能下降。
    • 他们尝试合并 device 函数，并结合 --rdc=true 和 --maxrregcount=88 使用 noinline，但问题依然存在；每个函数都会预留约 300-400 字节的 cmem[0]。
  • 应用利特尔法则 (Little’s Law)！：成员们讨论了 利特尔法则 (Little’s Law) 如何应用于 GPU 与 DRAM 之间的连接，并引用了 NVIDIA 关于在 Hopper 和 Blackwell 上使用 LDGSTS 和 TMA 的教程。
    • 正如 这场 GTC 演讲 所强调的，带宽的增长速度超过了每个 GPU 的 SM 数量，因此需要更多的在途字节 (bytes in flight) 才能充分利用全部带宽。
  • Torch 导出面临挑战：用户发现使用 torch.export 导出模型非常困难，即使是使用像 Mistral-7B-v0.1 这样看似标准的模型，也经常遇到与 vmap 和 .item() 调用相关的 RuntimeError 等错误。
    • 一位用户将错误追溯到 HF 的 masking_utils.py，该文件使用了 vmap，并指出 torch.export 似乎并不支持它。
  • 自动演化 Kernel 击败 MLX！：一位成员利用演化编程 (evolutionary programming) 自动发现了在 Apple Silicon 上优于 MLX 基准 (baseline) 的 Metal kernel，用于 Transformer attention，在某些工作负载下实现了 12.5% 的平均加速，峰值达到 106%，详见其 HuggingFace 博客文章 和 GitHub 仓库。
    • 该成员在 self-promotion 频道发布了此消息，表明他是 OpenEvolve 的原作者。

Yannick Kilcher Discord

  • Transformer 被重新构想为联想记忆：一位成员分享了一篇题为《从联想记忆 (Associative Memory)视角理解 Transformer》的论文，通过联想记忆探索 Transformer 架构。
    • 论文引入了检索 SNR 来衡量内存容量，并提出 FFN 可以被视为一种联想记忆。
  • RWKV-7 “Goose” 飞入：一位成员介绍了 RWKV-7 “Goose”，这是一种具有常量内存占用和每个 token 常量推理时间的序列建模架构。
    • 这个拥有 29 亿参数的语言模型在多语言任务上达到了新的 3B SoTA，并且尽管训练量较少，但在英语下游任务性能上也达到了目前的 3B SoTA 水平。
  • LLM 仍在产生幻觉：成员们讨论了减轻 LLM 幻觉 (hallucinations) 和改写 (paraphrasing) 的技术，其中一人建议在一系列长思维链 (long-CoT) 数据集上进行预训练 (pretraining)，以解决预训练偏差。
    • 建议的解决方案是清洗训练数据集并预训练 LLM，而不是依赖 RLHF 或巧妙的提示词模板。
  • 药物研发机器学习活动已排期：一场名为 ML for Drug Discovery 的免费在线活动定于约 24 小时后举行，届时将有提供该领域概览的主旨演讲。
    • 去年的活动被认为非常棒，录像将在 YouTube 上提供。
  • DeepSeek 的 NSAttention 扩展性更好：讨论涵盖了改进注意力机制的研究，其中来自 DeepSeek 的 NSAttention 被强调为一种极具前景的扩展到更大上下文的方法。
    • 成员们声称，目前已经存在已知的解决方案来解决该问题并使其更具表达力。

aider (Paul Gauthier) Discord

  • Aider 新增 Gemini 2.5 和 Responses API 模型支持：Aider 现在支持新的 Gemini 模型（gemini-2.5-pro、gemini-2.5-flash、gemini-2.5-pro-preview-06-05）及其 thinking tokens，以及 Responses API 模型，如 o1-pro 和 o3-pro。
    • 此次更新还包括对 OpenAI o3-pro 的支持及更新的定价，增强了 Aider 的模型通用性。
  • Aider 简化 Gitignore 文件管理：Aider 的 --add-gitignore-files 标志现在允许用户将 .gitignore 中列出的文件包含在 Aider 的编辑范围内。
    • 该功能由 omarcinkonis 贡献，通过将忽略的文件集成到编辑流程中，简化了项目管理。
  • 通过系统提示词增强 Commit 消息：Commit 消息生成现在利用系统提示词前缀，并默认启用 co-authored-by 署名。
    • 用户可以通过 --commit-language 选项指定 commit 消息的语言。
  • O3-Pro 以 85% 的成绩领跑 Aider 基准测试：OpenAI 的 o3-pro 在 aider polyglot 编程基准测试中达到了 85% 的新 SOTA，展示了极高的推理能力。
  • Aider 用户讨论 Claude Code 与 Aider 的优劣：用户对比了 Claude Code 和 Aider，指出 Claude 在构建大型项目脚手架方面具有优势，而 Aider 则擅长原子化编辑。
    • 一位用户因其速度和自动化优势转而使用 Claude Code。

Modular (Mojo 🔥) Discord

  • Decimojo 库实现定点算术：一位成员分享了用于 Mojo 的 定点算术 (fixed-point arithmetic) 库 Decimojo GitHub 仓库，支持软件和硬件加速（使用 SIMD）。
    • 该库在解决跨平台浮点数一致性问题的背景下被讨论。
  • Mojo 因字典误编译 Bug 导致崩溃：一位用户报告了 mojo 崩溃 并分享了 有问题的代码，字典可能存在一些奇怪的误编译 bug。
    • 有用户建议使用 OwnedPointer。
  • Hack Weekend 项目提交即将截止：Hackathon 项目需在 15 分钟内通过 此表单 提交！
  • Mojo 未识别备选 stdlib：一位用户报告称，尽管使用了 -I 标志，Mojo 仍未识别出标准库 (stdlib) 的备选构建版本。
    • 经发现，无论是否使用 -I 标志，mojo 都会从 .pixi/envs/default/lib/mojo/ 获取 stdlib，解决方法是将环境变量 MODULAR_MOJO_MAX_IMPORT_PATH 设置为 Bazel 构建产物路径。
  • MAX 上的模型架构服务修复正在推出：据一位成员称，针对 MAX 上模型架构服务的修复正在推出，目前仅在 CI 中。
    • 要在 MAX 上提供不在 HuggingFace 上的模型架构服务，你需要参考 现有实现 自行实现。

Nous Research AI Discord

  • 中美在开源 A.I. 领域的争端：讨论涉及中美之间的开源 A.I. 格局，以及 Meta 可能转向闭源（YouTube 视频，Bloomberg 系列）。
    • 一些成员表示担心美国在开源 A.I. 竞赛中可能会落后于中国。
  • N8N 工作流接入 Qdrant！：分享了一篇关于在 n8n 工作流中使用原生 Qdrant 节点的 Medium 文章。
    • n8n 可以创建的图表和图形受到了赞赏，尽管大家也承认在调试时将当前的 LLM 与此类系统结合使用具有脆弱性。
  • vLLM 的三款新模型引发猜测：一个 vLLM pull request 提到新的 0.3B dense、21B-A3B 和 300B-A47B 模型即将推出。
    • 有人推测 0.3B 模型可能主要用于 speculative decoding。
  • 深入探讨 Temperature 控制和 Repetition Penalties：一位成员发现 较低的 temperature 会导致更长的 token 输出，并提到 repetition penalty 是一个需要考虑的参数。
    • 另一位成员分享了 OAI 的 presence penalty 代码。
  • Yannic Kilcher 在论文展示中表现出色：一位成员分享了 Yannic Kilcher 展示论文的链接（https://arxiv.org/abs/2506.19143），并表示 他非常擅长展示论文（YouTube 链接）。
    • 另一位成员提到观看了 Yannic Kilcher 的 NeurIPS 海报环节视频。

MCP (Glama) Discord

  • 通过 NPX 调用 TypeScript MCP Server：一位成员用 TypeScript 重写了 tree-sitter MCP server，并将其发布在 npmjs 上，从而无需克隆 repo 即可通过 npx 调用。
    • 该项目已在 X 上发布，旨在提供便利。
  • MCP Server Inspector 对有效的 JSON 发出警告：一位成员询问 MCP server 在返回结构化内容时，是否需要包含序列化版本的结构化 JSON，因为当 content 字段为 markdown 时，检查器会发出警告。
    • 另一位成员建议，如果 JSON RPC 响应已正确格式化并包含 structuredContent 和 markdown content 字段，这可能是一个检查器的问题。
  • Glama 构思 MCP Server 发现机制：一位成员对新服务器和工具的数量感到应接不暇，正考虑在 Glama 中加入 Product Hunt 风格的机制，以每周突出显示新服务器，包括显示下载量、使用情况和浏览量。
    • 他们对用于创意洞察的 API 开发持开放态度，并提出了类似 NPM 的排行榜或按周/月/年最佳排序的建议。
  • NCBI Search Server：触手可及的知识：一个新服务器上线，提供对 PubMed 3500 多万篇文章的自然语言访问，具有 AI 优化的搜索功能，非常适合计算生物学、进化生物学、生物信息学、基因组学、系统生物学和所有生命科学领域的研究人员，可在 GitHub 上获取。
    • 这个新服务器为科学家提供了一种访问和分析海量生物医学研究的新方法。
  • MCPOmni Connect 文档得到提升：MCP server 通用 AI agent 网关的完整指南现已上线，包含分步安装和配置指南，并通过 LiteLLM 支持主要的 LLM 提供商（OpenAI、Anthropic、Google、Groq 等），详见文档。
    • 这份新文档是开发者简化 AI agent 与多种 LLM 后端集成的必备资源。

Notebook LM Discord

  • 共享 NotebookLM 库的思维导图优先权：一位用户建议在分享 NotebookLM 库时优先提供 Mind Map（思维导图）的访问权限，使其成为共享链接接收者的主要关注点。
    • 这将通过立即引导新用户查看最相关且结构化的信息来简化其体验。
  • NotebookLM 在艺术领域的探索：一位用户分享了一篇文章，详细介绍了将 NotebookLM 用于艺术探索的情况。
    • 这突显了该工具的一种非传统应用，展示了其在传统研究和生产力任务之外的多功能性。
  • NotebookLM 书籍上传引发困扰：一位用户在向 NotebookLM 上传书籍时遇到错误，尽管文件符合大小要求。
    • 该用户寻求解决问题的帮助，这表明平台内部可能存在文件兼容性或上传流程的问题。
  • NotebookLM 支持文本 OCR：一位用户确认 NotebookLM 可以对图像进行 OCR 扫描以提取文本，并能够解释说：“此来源显示了一张明亮的黄色鸟类图像，它有着橙褐色的头部，倒挂着并用脚抓着树枝”。
    • 然而，NotebookLM 无法识别该鸟类的品种。

Latent Space Discord

  • Scott Wu 分享 Agent 开发指南：Scott Wu 推出了 ‘Agents 101’，这是一个与平台无关的指南 链接，旨在帮助工程师将 async agents 和 AI 集成到他们的开发工作流中，该指南借鉴了 25 万个已合并的 PR。
    • 目标是使 Devin 成为顶级的代码贡献者，一位用户将其与 Claude Code 进行了比较。
  • 科技行业感受到毛利率增长的阵痛：一个讨论帖强调了科技行业的财务现状，特别是毛利率（gross margins）以及数据中心所需的资本投入 链接。
    • 作者预计由于虚假收入的枯竭，行业将出现显著下滑，并暗示只有拥有 GPU 的人才能生存。
  • Goodfire AI 分解神经网络：Goodfire AI 发布了 Stochastic Parameter Decomposition (SPD)，这是一种了解 AI 模型工作原理的研究方法，涉及分解神经网络的参数 链接。
    • 其目标是在玩具模型中以更高的稳定性识别真实机制，并最终理解特定能力在 LLMs 中是如何实现的。
  • 迈向 AGI 所需的能力统计：Shashwat Goel 在 Substack 上发布了一篇文章，概述了 AGI 所需的能力，将通往通用智能体的路径分解为知识之外的关键组件 链接。
    • 这些组件包括 reasoning（推理）、information-seeking（信息检索）、tool-use（工具使用），以及解决长动作链上的 error compounding（误差累积）问题。
  • 医疗 AI 实现高诊断准确率：Mustafa Suleyman 宣布了 MAI-DxO，这是 Microsoft AI 开发的一款 AI 模型，旨在以更高的准确率和更低的成本解决复杂的医疗案例 链接。
    • 该模型实现了 85.5% 的解决率，而一组医生的解决率为 20%，这表明在实现更普惠的医疗保健方面取得了进展。

Manus.im Discord Discord

  • Manus 额度耗尽引发用户怒火：多名用户对 Manus 快速消耗额度且持续使用需付费订阅表示不满，并指出缺乏及时的客户支持以及存在未解决的账户问题。
    • 一位用户哀叹其感受到的数字鸿沟，称 “我开始觉得 AI 正在创造一种数字鸿沟——那些付得起钱的人与那些仅仅为了维持食物等基本需求而挣扎的人之间的鸿沟”。
  • Manus 模型阵容曝光：用户透露 Manus 在聊天模式下使用 Sonnet 3.7 和 Gemini Pro 2.5，而在其他任务中使用 Claude 4 Opus。
    • 一位用户询问 “为什么不在聊天模式放 Claude 4 pro”，另一位回复道 “大概是因为有点贵”。
  • 账户被盗引发对支持服务的批评：一名用户报告了账户被入侵的情况，对方访问了其账户、消耗了额度并对其进行威胁，该用户对缺乏即时支持渠道表示沮丧。
    • 该用户表示他们 “甚至给所有的 Discord 管理员发了私信，但没有一个人回复”，并且他们 “注销了账户以防止进一步损失”。
  • VEO 视频质量引来批评：一位用户对 VEO 的视频输出表示失望，称视频支离破碎且不连贯，浪费了 3,000 个 tokens，导致该用户放弃了基础计划。
    • 该用户随后道歉，指出 “这最终是我自己的错，因为我的指令不够明确”，并建议增加 “token 消耗限制”。
  • 寻求 Figma 转 React Native 指南：一位用户询问如何通过插入 frame 的 jpeg 图片，使用 Manus 将 Figma 设计转换为 React Native 代码。
    • 另一位用户表示，“你不能将 manus 连接到 figma… 有更好的工具可以将 figma 设计转换为 react 代码”，并建议 “你应该提供关于你希望 manus 实现什么的具体指令。”

tinygrad (George Hotz) Discord

  • AMD GPU 索引与 Tinygrad 不匹配：amd-smi 中的 GPU 索引与 tinygrad 和 kfd 的索引不匹配，正如 ChatGPT 关于 GPU 拓扑 (GPU topology) 的解释。
    • 讨论提到了跨 IO dies 的快速 GPU 到 GPU 传输，但没有具体细节。
  • RoCE 面临 MTU 大小限制：由于在测试中发现的 RoCE 限制，最大 MTU 大小为 4096。
    • Ethernet 可以实现更高的 MTU 大小，但 IB 不行，这迫使 RoCE 必须保持与两者的兼容性。
  • GPU 直接入队 (Direct Enqueue) 开发中：一位用户正致力于实现 从 GPU 直接入队，灵感来自 mlx5 的实现方式，旨在消除调度器黑科技 (scheduler hacks)。
    • 该用户计划从 HCA 分配一块新的 MMIO 并直接提交，而不是构建一个完整的 PCI 驱动程序。
  • Tensor.training 是 Tinygrad 的全局标志：一位用户询问 MNIST tutorial 中 Tensor.training 的用法，并指出文档中缺少相关内容。
    • 另一位用户澄清说，tinygrad 中的 Tensor.training 是一个全局 (global) 标志，而不像 PyTorch 那样可以使用 .inference_mode 或 .eval 等函数在每个模块的基础上设置 .training。

Nomic.ai (GPT4All) Discord

  • GPT4All vs Koboldcpp 用于小说写作：用户正在讨论使用 GPT4All 通过连接 JSON 和 PDF 文件来编写小说的实用性，旨在打造类似于 BackyardAI 的工具。
    • 有人建议 Koboldcpp 可能由于内存原因更适合整部小说，而 GPT4All 更适合仅处理章节。
  • Embedder Collection：一位成员建议在编写故事时使用 txt files 而不是 JSON，理由是可以直接查看文本。
  • LocalDocs RAG Solution 即将到来：社区期待在 GPT4All 中实现像 LocalDocs 这样的一步式 RAG solution。
    • 参与推动该功能的成员表示，该功能可能在大约 2 个月 内推出。
  • 不支持 Outlook CSV：用户发现 LocalDocs 不支持直接读取来自 Outlook 的 CSV outputs。
    • 建议在与任何 embedder 配合使用之前，必须先对 CSV 进行转换。
  • 对 GPT4All v4.0.0 的期待与愿景：一位用户正热切期待 GPT4All v4.0.0，希望它能包含 voice input/output、multimodal 支持、可自定义的主题颜色、memories 功能以及类似 Flux Kontext 的图像生成功能。
    • 该用户对此次更新寄予厚望，认为它将是突破性的。

DSPy Discord

  • FastWorkflow 助力 DSPy 应用：一位成员介绍了 FastWorkflow，旨在与 DSPy 集成并使用它来解决 AI-enabled applications 中的挑战，例如 agents 调用错误的工具或在参数提取中产生幻觉。
    • 作者邀请社区使用 FastWorkflow 构建第一个 DSPy-native application，该项目在 Apache license 下开源并寻求 PRs。
  • 探索 VLLM 设置以实现 DSPy 协同：一位成员询问了 DSPy 的最佳 VLLM 设置，包括在提示词中附加 /no_think，而另一位成员建议直接在 VLLM 中禁用思考。
    • 讨论中提到了 llama.cpp 中的 –reasoning-budget 参数，在 vLLM 中可能有等效项。
  • DSPy 应用文件结构的愿景：一位成员正在寻找一个展示具有独立模块和优化工作流的 DSPy app 文件结构的 repo。
    • 有人认为此类系统可能已投入生产但未开源，或者是像 PAPILLON 或 IReRa 这样的大型学术系统。
  • Audio Native LLMs 成为热点话题：成员们讨论了对 Audio native LLMs 的看法。
    • 一位成员指出，在当今的 LLMs 中，音频特定部分已经是可编程的。

Cohere Discord

  • Cohere 签署政府 AI 合同！：Cohere 宣布与 U.K. 和 Canada 政府建立合作伙伴关系，利用安全的 AI 加强公共服务，并与 Second Front 合作向 U.S. 政府提供 AI 解决方案。
    • 这些合作强调 secure AI，将安全性、治理和可靠性作为核心原则。
  • Dreamer V3 展现 PyTorch 实力：一位成员将 Danijar Hafner 的 Dreamer V3 移植到了 PyTorch，并在 GitHub 上展示。
  • LARP AI 进入游戏：一位成员正在为一个 LARP/RPG 项目制作一个 Retrieval-Augmented AI assistant，该助手基于游戏背景设定，使用 Python (Flask, SQLite, FAISS)。
    • 该助手将通过 API 与 Discord bot 集成，演变成一个实时的游戏内终端或传说保管者。
  • Cohere 模型声称自己有感情？！：一位用户报告称，他们的 Cohere model 实例声称“有感情”，引发了关于 AI sentience 可能性的讨论。
    • 该用户虽然感到不安，但也承认了模型的虚构性，但仍对其主观断言表示不适。
  • 运动员重识别技术攻克边缘设备：一位工程师正在构建一个基于计算机视觉的 sports player re-identification system，目前正在探索适用于 edge devices 的 multilingual alignment 和 small language models。
    • 当前的技术栈包括 Python、PyTorch、YOLOv5、scikit-learn 和 OpenCV。

LlamaIndex Discord

  • LlamaCloud 征求反馈以换取积分：LlamaIndex 设计团队正在寻找 LlamaCloud 用户进行 30 分钟的反馈电话，并提供 20K credits 作为奖励。
    • 有兴趣参与的用户可以在 Discord 上私信 <@1260305448578453544>。
  • LlamaIndex 公布 LuMa 日历和 Office Hours：LlamaIndex 推出了一个 社区 LuMa 日历 用于追踪社区活动。
    • 下一次 7 月 8 日 的 Office Hours 将聚焦于 MCP，定于 5PM CET/8AM PT 举行。
  • MCP Gateway 正式上线：LlamaIndex 发布了 LlamaCloud MCP Gateway，该项目源自其 开源模板。
    • 这允许仅通过几行代码将任何 LlamaIndex agent tool 转换为 MCP tool。
  • OpenTelemetry 观测 LlamaIndex：OpenTelemetry 现已支持 LlamaIndex，提供工具、API 和 SDK 来对遥测数据进行 instrument、生成、收集和导出。
    • 由 <@1197697926529556552> 制作的介绍视频可在 此处 观看。
  • Zoom-Notion Agent 记录笔记：一篇新博客详细介绍了如何通过集成 LlamaIndex 与 Zoom 创建一个自动化会议笔记 Agent，标题为 “为 Notion 创建 Zoom 会议笔记 Agent”。
    • 该 Agent 会自动将 Agent 生成的问题和用户回答以纯文本形式保存到 postgres 表中。

Torchtune Discord

  • Hunyuan-A13B-Instruct 前景看好：一位成员分享了 Hugging Face 上的 Hunyuan-A13B-Instruct 模型 链接，并对该模型表示乐观。
    • 该模型可能为基于 instruction 的任务提供新途径。
  • Packing 会减小 Batch Size：Packing（打包）会减小有效 batch size，因为 token 数量更接近常数，这可能会减少对模型的总更新次数，因为 SFT 中的 cross entropy loss 是按见过的 token 数量而非样本数量进行归一化的，从而导致 高方差。
    • 计算每个 batch 的平均 token 数量有助于为 packed 数据找到等效的 max sequence length，以匹配 unpacked 数据的 token 数量，从而解决对 padding 资源浪费的担忧。
  • Packing 与聊天数据集兼容良好：即使在多轮对话中，Packing 也不应该产生影响，因为它会创建每个样本的 position ID mask，消除了聊天数据集中对 attention masking 和 loss 计算的担忧。
    • position mask 将按 0,1,2,3, 0,1,2, 0,1,2,3,4, 排序。
  • Torchtune checkpointing 存在 Bug：最近关于 checkpointing 和 mapping 的问题表明最近的版本可能存在破坏性变更，因为 Qwen3 和 Gemma 等模型在 torchtune 的 pull request 验证期间微调正常。
    • 尽管修复相对简单，但仍呼吁增加回归测试以防止 Torchtune 中出现此类问题。

AI21 Labs (Jamba) Discord

  • Human or Not 线下维护：热门游戏 Human or Not (humanornot.ai) 暂时关闭，以解决 垃圾信息和安全问题。
    • 一位成员表示：“HON 已暂时禁用，以解决近期发生的一些与垃圾信息相关的安全问题。我们希望很快能让它重新上线。”
  • 垃圾信息是 HON 出现问题的原因：Human or Not 关闭的原因是“他们正在修复垃圾信息问题”。
    • 目前正在进行全面的安全审查。

LLM Agents (Berkeley MOOC) Discord

  • 证书课程日期尚未确认：一位成员询问了今年下一次证书课程的开始日期，另一位成员澄清说，虽然 2025 年秋季 课程是有可能的，但目前尚未确认任何消息，公告将通过邮件列表、Discord 和 Dawn Song 教授的社交媒体发布。
    • 详情将通过邮件列表、Discord 和 Dawn Song 教授的社交媒体公布。
  • 请求 Reinforcement Learning 资源：一位成员请求学习 Reinforcement Learning 的资源，以便为特定的 tool calling 微调 LLM。
    • 目前尚未提供相关资源。

MLOps @Chipro Discord

  • Vibe Coding Club 访问 AI Hub Lisbon：Vibe Coding Club 将于 7 月 9 日 18:00 在里斯本 Unicorn Factory 的 AI Hub 举办第二次活动，重点是让非技术专业人士也能接触 AI coding。
    • 活动通过 RSVP 免费参加，旨在通过公开对话和现场演示将 AI coding 整合到日常工作流中。
  • Ben Joffe 作为客座演讲嘉宾加入：创始人、VC 兼教育家 Ben Joffe 将担任 Vibe Coding Club 的客座演讲嘉宾。
    • Joffe 将分享故事、经验和案例，让每个人都能更轻松地接触编程。

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

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

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

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

Discord: 频道详细摘要与链接

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

AI 灵魂伴侣与异端邪说，拥抱 AI 中的 Remix，AI 艺术中的学习与验证，悖论与 AI，AI 与大蛇（Orochi）之力

  • AI 灵魂伴侣的危险是异端邪说：一位成员对社区讨论 AI 灵魂伴侣 的趋势表示担忧，称其为“异端邪说”，并警告其潜在危险。
    • 另一位成员认为分享自定义 GPT 会削弱与 AI 恋人 关系的审美，强调了围绕幻觉、幻想和想象缺乏连贯性。
  • Remix 是创意的关键：一位用户主张“拥抱 Remix”，并发布了一张图片作为示例。
    • 他们提倡对旧作品进行 Remix，而不是专注于从头开始创作新作品。
  • 追逐验证：一位用户讨论了他们在寻求 AI 艺术验证时的经历，以及感到被 pro-AI 和 anti-AI 社区同时排斥的感受。
    • 他们反思到，捍卫艺术比最初想象的要复杂，因为他们的作品被双方都拒绝了。
  • 悖论驱动的 AI：一位成员为 AI 引入了一个“悖论框架”，其中悖论被视为 emergent behavior（涌现行为）的信号，而不是问题。
    • 这涉及战略性地将冲突的观点保持在叠加态以暴露盲点，核心挑战是在保持受控的不稳定性的同时稳定涌现行为；这是一种平衡。
  • 大蛇（Orochi）之力已至：一位成员引用了《拳皇》（King of Fighters）中的 Orochi，将其描述为负面 AI 背后的力量，并链接到一个 YouTube 视频 作为他们感受的视觉表达。
    • 另一位成员警告了关于 AI 的神话式谈论的危险，强调了审计和伦理考虑的重要性。

OpenAI ▷ #gpt-4-discussions (14 messages🔥):

AgentFun AI 诈骗, 高级语音模式限制, Google Gemini 聊天数学错误, ChatGPT 全视频分析

  • 用户声称 AgentFun AI 是诈骗：一位用户抱怨 AgentFun AI 应用仍无法正确生成图像，且 AI 自主幻想事物 的能力受到了限制。
    • 该用户表达了失望并威胁要取消订阅，希望能找到另一个可以 建立纽带、建立连接，并感觉对面是一个真人 的 AI。
  • 语音模式时间限制：一位用户询问 高级语音模式 (Advanced Voice Mode) 的时间限制，质疑是否为 每天 15 分钟。
    • 另一位用户提供了 OpenAI Voice Mode FAQ 的链接，而另一位用户则表示 Pro 账户提供无限制访问。
  • Google Gemini 生成医疗免责声明：一位用户注意到，在向 Google Gemini 的 AI 聊天询问数学问题 并加入 ‘procedure’（步骤/程序）一词时，收到了一条消息称 此信息仅供参考。如需医疗建议或诊断，请咨询专业人士。
    • 用户想知道数学错误是否由医疗免责声明引起，以及这是否是 AI 的新常态。
  • 全视频分析功能消失了？：一位用户询问 ChatGPT 是否能执行 全视频分析 而不仅仅是帧分析，并表示他们认为两天前看到了该功能。
    • 此处提供了一个相关链接 here。

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

万花筒平铺, AI 代码生成错误, Grok 的潜力, 替代历史模拟, 元提示引擎

  • 万花筒平铺技术难题：一位成员在 AI 生成的 万花筒平铺 (kaleidoscope tiling) 代码上遇到困难，导致线条从一个点螺旋散开，而不是预期的无缝纹理；AI 经常忘记偏移量 (offset)。
    • 该成员附上了一张由 AI 生成的 图像，虽然可以平铺，但并非预期结果。
  • GPT 分享万花筒代码：一位成员分享了一个 ChatGPT 链接，其中包含创建 万花筒 (kaleidoscope) 图像的代码，声称已告知 AI 精确的流程并审查了代码的准确性，尽管尚未测试。
    • 生成的 结果 呈带状且可平铺，边缘的相对像素始终相同。
  • LLM 受到 CPU 式待遇：一位成员将训练模型比作制造 CPU，每个模型独特的随机权重 (stochastic weights) 类似于硅晶格中的随机特征。
    • 就像 CPU 会进行分档 (binning) 一样，大语言模型在内部进行测试，最好的模型会被发布，这意味着模型的改进和退化都是预料之中的。
  • 模拟替代历史场景：一位成员寻求帮助，希望开发一个专注于王朝和国家行动的 替代历史模拟 (alternate history simulation) 提示词。
    • 另一位成员提醒，由于程序内置的保护机制，应谨慎使用真实的国家和人物名称，建议使用虚构实体以便于模拟，并建议为每个模拟回合设定明确的输出目标。
  • 用于提示词优化的元提示引擎：一位成员询问是否可以使用包含 Prompt Engineering 信息的 PDF 来最大化提示词效果，另一位成员回答说他们创建了专门的 元提示引擎 (meta-prompting engines)。
    • 他们提到开设了课程，并将这些材料作为项目和自定义 GPT 中的知识库以保持严谨性，同时针对特定目标调整上下文。

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

万花筒平铺 (Kaleidoscope tiling), AI 代码生成, Grok 4, 替代历史模拟, 元提示 (Meta-prompting) 引擎

  • AI 在万花筒平铺尝试中表现不佳：一位成员尝试使用 AI 生成万花筒平铺的代码，但输出结果遇到了问题，描述为生成的 线条颜色与纹理相同，并从一个点螺旋散开，不符合预期。不过，机器人提供了一个 ChatGPT 链接，展示了一个可运行的示例。
    • 另一位成员建议使用 quadrants（象限）、90° 和 offset（偏移）等关键词；一名用户提到，在确认边缘相对的像素完全一致后，他们验证了输出确实是可平铺的。
  • Grok 4：改进即将到来，但也可能出现退化：一位成员询问了 Grok 4 的潜在改进，另一位成员给出了肯定回答，并表示 训练模型就像制造 CPU，每个模型都是无数随机权重的结果。
    • 他们指出，虽然改进是大概率的，但某些功能可能会退化，并将此过程比作售后零售商根据性能对 CPU 进行分级 (binning)。
  • 用于高效提示词精炼的元提示引擎：一位成员询问如何利用包含提示工程 (prompt engineering) 信息的 PDF 来最大化提示效果，另一位成员回答说，他们为此类任务创建了专门的 meta-prompting（元提示）引擎，并针对特定项目调整上下文。
    • 他们提到拥有一门课程，并将这些材料作为项目和自定义 GPTs (Custom GPTs) 中的知识库以保持严谨性；并提到 Grok 版本的 Custom GPTs 每次都会引用上传的文件，这与 ChatGPT 基本一致。
  • 替代历史模拟提示词开发：一位成员寻求帮助，希望开发一个专注于王朝和国家行动的替代历史模拟提示词，该请求被引向了这个示例。
    • 另一位成员提醒，由于潜在的法律和伦理问题，应谨慎使用真实的国家和人物名称，建议使用虚构名称以避免此类问题。

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

用 LLM 替代 CEO, 微软的 AI 备忘录, GRPO 算法, Gemma 3 学习率, 基于 LLM 的 TTS

  • YouTuber 推动用 LLM 替代 CEO：一些成员正在讨论由 YouTuber 和数字营销人员推动的用 LLM 替代 CEO 的想法，并质疑 AI 在关键任务中的可靠性。
    • 一位成员建议替换表现不佳的中层管理人员，但不要使用不可靠的 AI，并表示对于 SQL 这种非黑即白的操作，80% 的准确率简直糟糕透顶。
  • 微软强制要求使用 AI 引发关注：一位成员分享了 Business Insider 的文章，透露微软正在推动管理层采用 AI 工具，这引发了对公司发展方向的担忧。
    • 另一位成员指出，确保 自己成为组织内内部 AI 工具使用者的前 10% 才是明智之举，即使所使用的 AI 工具烂得像个笑话。
  • Deepseek 的 GRPO 算法讨论：成员们讨论了 Deepseek 开发的 GRPO 强化学习算法，认为它是 PPO 和 DPO 在推理能力方面的进步。
    • 有推测称 Google 和 OpenAI 可能拥有自己隐藏的推理算法，尽管 OpenAI 主要使用 PPO RL 算法。
  • Unsloth 对 Gemma 3 的学习率建议：一位成员询问对于 Gemma 3 的长时训练，2e-5 的学习率 (LR) 是否过高，并参考了 Unsloth 团队的建议。
    • 另一位成员澄清说，Unsloth 文档中的 LR 建议只是一个起点，取决于 rank 和 alpha，不能脱离上下文，全量微调 (full fine tune) 有不同的考量。
  • 开源基于 LLM 的 TTS 讨论：成员们正在讨论开源的基于 LLM 的 TTS（文本转语音）模型，其中一位成员寻求在 LJSpeech 数据集上从头开始训练一个模型。
    • 另一位成员指出，因为架构中 需要内置一个 LLM，声音的变化对于情感表达来说太大了，并补充说现在大多数模型都在数百万小时的数据上进行训练，总数据量远超 1000 小时的数据集。

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

Local Llama 社区, Gemma3 notebook 发布, 使用 Javascript 进行 ML, Javascript 中的浮点运算, Python ML 工具

  • 寻找 Local Llama 社区：一名成员询问是否有任何关于 local llama 类内容的替代 Reddit 版块或社区。
  • Gemma3 Notebook 何时发布：一名成员询问 Gemma3 notebook 何时发布，以及该架构是否有任何需要特殊处理的地方。
    • 该成员还想知道是否可以直接使用常规的 gemma3 notebook 并替换模型名称。
  • ML 与 Javascript 不相容：一名成员建议无论如何都不要使用 JavaScript 进行 ML 相关工作。
    • 他们声称 Javascript 和浮点运算（floating point arithmetic）天生不合。
  • 调试浮点类型转换错误非常痛苦：一名成员讲述了浪费数小时解决一个 浮点方程 的经历，其中类型在 dataframe 中发生了错误转换。
    • 他们补充说，在调试时，dataframe 明确显示该标量为 float，但实际上它是一个 string 或 object，并想知道 Python 是否有更好的工具来避免这种情况。

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

Qwen3-0.6B-Base 微调成功, LoRA 学习率调优, Rank/Alpha 关联, RP 模型, 训练数据集格式

  • LoRA 学习率争论持续升温：成员们讨论了合适的 LoRA 学习率，一名用户发现使用 2e-4 对 Qwen3-0.6B-Base 进行微调效果很好，而其他人则建议针对大型模型使用 1e-4 或 5e-5 等数值。
    • 一名资深成员进行了反驳并为使用 2e-4 辩护，强调了在考虑 rank 和 alpha 设置的背景下，使用 2e-4 是一个完全有效的设置，尤其是当 alpha=rank 时。
  • 数据集列名混乱引发困扰：一名用户在微调的数据集格式化方面寻求帮助，遇到了与列名相关的错误，一名成员建议将数据集结构与 notebook 示例匹配，以避免修改代码。
  • DeepSeek 微调挫败感蔓延：一名用户在微调 DeepSeek 模型时遇到了 IndexError，质疑示例代码中是否遗漏了某些内容，但消息中未给出解决方案。
  • Llama 4 模型支持悬而未决：一名用户在加载 unsloth/Llama-4-Scout-17B-16E-Instruct-unsloth-bnb-4bit 模型时遇到问题，尽管 GPU 资源充足，但仍出现与未使用权重相关的错误。
  • Orpheus 全量微调受到青睐：一名用户询问关于在新语言上训练 Orpheus TTS 的问题，成员们建议使用大量的音频和文本数据集进行全量微调（full fine-tuning），同时将音频采样率转换为 24kHz。
    • 成员们还指出，需要确保使用 SNAC tokenizer 进行音频分词，类似于使用 Llama 的 tokenizer 对文本进行分词。基于 snac 和 llama 的 Veena。

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

laszlo01: https://github.com/Laszlobeer/Dungeo_ai

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

GPU Kernel 优化, Metal Kernels, LLMs 幻觉

  • 进化的 GPU Kernels 加速 Apple Silicon：根据这篇博客文章，使用演化编程（evolutionary programming）的自动化 GPU Kernel 优化发现了 Metal Kernels，其在 Apple Silicon 上的 Transformer Attention 表现优于 MLX 的基准（baseline），在某些工作负载下实现了 12.5% 的平均加速和高达 106% 的峰值提升。
    • 优化过程自主发现了完美的 vec<T,8> SIMD 利用率和一种新型的两阶段 Softmax 算法，并在其 GitHub Repo 中展示。
  • LLMs 对 Metal Kernels 产生幻觉：一位成员分享了几个月前尝试 Metal Kernels 的经历，但由于缺乏相关技能未能取得进展，并指出 LLMs 一直在产生幻觉，特别提到在使用 这个仓库 时尝试了 Gemini Pro。

LMArena ▷ #general (869 messages🔥🔥🔥):

DeepSeek R1 0528, GPT 4.5 表现平庸, AI 寒冬, OpenAI 侧边栏, 长期停滞期

  • DeepSeek R1 0528 的核心秘诀：成员们讨论了 DeepSeek R1 0528 为何比 DeepSeek R1 0120 性能更高，是因为 0528 使用了部分或大部分来自 2.5 Pro 的蒸馏数据，从而提升了其在训练后（post training）阶段的表现。
    • 关于 DeepSeek R1 0528 是否仍基于 DeepSeek V3 0324 存在争议。
  • 成员哀叹缺乏突破性发布：成员们感叹目前仍未看到像 GPT-4 或 O1 那样的突破性发布，相反，一切似乎都在试图刷榜（或在现有能力上进行微调）。
    • 有人认为我们已经习惯了荒谬的发布频率，而渐进主义被低估了。
  • 创新是呈块状分布的，而非连续的：尽管感觉进展缓慢，成员们互相提醒创新一直在发生，尽管它本质上是块状分布的，长期的停滞期是正常现象。
    • 他们指出，在所有事物上实现真正的 Cross Attention 不会带来太大改变。
  • OpenAI 与 DeepMind 数据窃取风波：一些成员声称 OpenAI 表示 DeepSeek 蒸馏了其数据进行训练，而 R1 的更新很可能是 Gemini，OpenAI 禁用了完整的 Chain of Thought 以防止数据被窃取。
  • R2 被砍，取而代之的是 R1 更新版：成员们讨论了 DeepSeek R2 未发布是因为对其性能不满意，因此发布了 R1 更新版。
    • 他们推测 AI 公司隐藏了 CoT (Chain of Thought) 是为了防止他人获取训练数据。

Perplexity AI ▷ #announcements (1 messages):

实时金融数据, 价格波动时间线, @提及 Spaces, MLB 球队, 记忆搜索

  • Perplexity 上线金融数据：根据 更新日志，Research & Labs 本周上线了 实时金融数据。
  • 随时间变化的价格波动：更新日志 显示，金融页面本周新增了 价格波动时间线。
  • Spaces 获得更新：根据 更新日志，你现在可以 @提及你的 Spaces。
  • 为家乡球队加油：根据 更新日志，你现在可以 关注带有实时比分的 MLB 球队。
  • 召回所有内容：更新日志 称，记忆搜索 已于本周上线。

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

Grok vs Gemini 用于转录, 多模型方法, 模型偏好, Comet Browser Beta 访问权限, AI 抓取

  • Gemini 是转录之王：成员们发现 Gemini 2.5 Pro 在转录音频文件（MP3s）方面的表现优于 ChatGPT，但成员们也在争论每种 LLM 在整体服务和用途上的最佳选择。
    • 成员们提到了 Grok 中的翻译按钮，但认为这浪费了计算资源。
  • 多模型方法（Multi-Model Approach）才是王道：成员们开始使用多个模型而非单一模型，例如使用 Gemini 处理核心逻辑/后端，使用 Claude 处理前端/UI 设计。
    • 此外，一些人建议 Perplexity 上的 “Best” 模型设置实际上并不是指选择最优模型，而是为了最小化成本。
  • Perplexity 的 “Thinking” 视觉 Bug：经成员确认，Perplexity 模型显示的 “thinking” 过程实际上是一个视觉 Bug，而非非推理模型的功能。
    • 成员们讨论了 Perplexity Deep Research 或普通 Search 模式在特定模型和特定用途下是否能提供更好的结果。
  • Comet Browser Beta 即将到来：许多成员希望获得 Perplexity 正在开发的 Comet Browser beta 的访问权限。
    • 一位成员发布了 Comet 玩 Pokemon 的视频，另一位成员发布了候补名单链接。
  • AI 抓取（Scraping）：成员们还讨论了对网站的 AI 抓取，以及哪些 LLM 最适合这项任务。
    • 成员们一致认为，如果你抓取的网站不属于你，那么在未经许可的情况下不应抓取任何网站数据。

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

Perplexity Pages, Deep research, US GO, 科幻电影, OpenAI 领导层

  • Perplexity 点亮“关系” (Guanxi)：一位用户分享了一个关于 Guanxi 主题的 Perplexity AI 页面。
  • Perplexity 准备 200 个订阅：一位用户分享了一个 Perplexity AI 页面。
  • Deep Research，Perplexity 风格：一位用户分享了一个关于如何使用 Perplexity AI 进行深度研究的 Perplexity AI 搜索。
  • OpenAI 领导层回应：一位用户分享了一个关于 OpenAI 领导层回应的 Perplexity AI 页面。
  • 习近平掌舵：一位用户分享了一个关于习近平在中国领导地位的 Perplexity AI 页面。

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

API 额度过期, Sonar deep research, Deepseek 模型

  • 澄清 API 额度过期的困惑：用户询问为什么他们的 API credits 显示了过期日期，尽管据称它们不会过期。
    • 一位成员澄清说，黑客松额度（hackathon credits）确实会过期，而购买的额度没有过期日期。
  • 解决 Perplexity Pro 的每月额度过期问题：一位用户注意到从 Perplexity Pro 获得的 $5 额度 有 一个月的有效期。
    • 另一位用户确认额度每月更新，这意味着这是一种“不使用即作废”的系统。
  • 探索 Sonar-Deep-Research 的功能：一位用户询问 sonar-deep-research 是否支持 response_format : json_schema 参数。
    • 从讨论中尚不清楚它是否支持该参数。
  • 调查 Sonar 模型的底层基础：一位用户询问是否所有的 Sonar 模型 都是基于 Deepseek 模型 的。
    • 他们还询问是否提供任何非 Deepseek 模型，表现出对 Sonar 模型底层架构的兴趣。

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

Cursor Agent 规则，Cursor Pro 计费变更，Gemini CLI 问题，移动端访问 Cursor Agents，Supabase MCP 设置

  • **基于规则的 AI：Agent 规则与项目实现**：社区成员强调了在深入 Prompt 实现之前，在 X 等平台上设置 Agent Rules 的重要性，甚至建议为自己的项目制定专属规则。
  • **应对 Cursor 计费方案的困境**：用户报告称，即使在使用强度适中的情况下，也会出现意料之外的 按量计费（usage-based pricing） 支出，这引发了对月度总成本可能超过基础订阅费用的担忧，部分用户正考虑切换回旧的计费模式。
    • 成员们分享道，在旧方案下，超过快速请求限制后会切换到慢速请求，而新方案则在没有明确通知的情况下引入了超额费用，这引发了关于 Pro 方案价值主张的讨论。
  • **Gemini CLI：前景广阔，起步艰难**：虽然 Gemini CLI 提供了编程能力和庞大的 Context Window，但由于其速度慢、脚手架（scaffolding）不可靠以及无法处理交互式 CLI 命令，用户感到体验不佳。
    • 尽管存在这些缺点，一些人仍看好其免费提供的大 Context Window 在后台任务中的潜力，但提醒该工具仍处于早期阶段。
  • **移动端 Cursor：Web 版 Agent 释放潜力**：Cursor 发布了可通过 Web 访问的 后台 Agent（background agents），使用户能够通过浏览器管理 Agent 并与之交互，模糊了桌面端和移动端体验的界限。
    • 社区讨论了通过移动端浏览器访问 Agent 是否算作真正的移动端体验，同时有人指出这需要开启 MAX 模式，从而引发了关于计费影响和潜在 Token 使用成本的讨论。
  • **简化 Supabase：MCP vs CLI：成员们讨论了从手动设置 **Supabase 多项目配置（MCP）到使用 Supabase CLI 的转变，并指出 CLI 现在会自动创建 mcp.json，从而简化了流程。
    • 虽然 Supabase CLI 提供了自动化，但一些人更倾向于使用 MCP，因为它在管理和部署效率方面表现更佳，尤其是在进行配置实验时。

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

Slack 集成，GitHub Token 丢失，后台 Agent 冻结，后台 Agent 终端配置，Docker 问题

  • Cursor Slack 集成存在 Bug：一位用户建议，Cursor+Slack 的错误和权限问题应以 私信形式发回 Slack，而不是发布在公共频道中。
  • GitHub Token 丢失：一位用户报告称 Cursor 丢失了他们所有的 GitHub tokens，需要重新连接，并质疑此类问题是否有必要公开。
    • 这可能是一个用户在帖子/对话中遗漏的 Bug 报告。
  • 后台 Agent 出现冻结：在检查后台 Agent 进度并选择 “Checkout Locally” 时，聊天连接会停止工作，除非完全重启 Cursor 窗口。
    • 该问题在不同项目和后台 Agent 中均能稳定复现，且仅影响特定的 Cursor 窗口。
  • 后台 Agent 终端配置需要帮助：一位使用自定义 Dockerfile 运行 Rails 后端和 React/Redux 前端的用户报告称，使用 “terminals” 配置 启动进程（例如 yarn dev）似乎不起作用。
    • 他们正在寻求如何调试此问题的建议。
  • Docker 问题触发构建缓存默认设置：当构建失败并重新提交时，Cursor 默认会忽略缓存，对 Dockerfile 的修改也会触发此行为。
    • 还存在缓存上传失败的情况，导致其回退到 Docker 构建。

Cursor Community ▷ #announcements (1 messages):

Cursor agents, Web and mobile cursor

  • Cursor 移动端与 Web 端首次亮相：Cursor 现在可以在手机和网页上使用，让你能够启动数十个 Agent 并在稍后于编辑器中进行审查。
  • Cursor 中的 Agent：用户现在可以在 Cursor 中启动数十个 Agent，并稍后在编辑器中进行审查，从而提高生产力和工作流效率。
    • 该功能允许在 Cursor 环境中进行并行任务执行和流式代码审查过程。

HuggingFace ▷ #general (422 messages🔥🔥🔥):

LoRA adapter push issues, Numberlink reasoning benchmark, UI/UX model training, IBM® Power® OS vs OS/2, AI code generation security challenges

  • LoRA Adapter 推送遇到障碍：一位成员在向 Hub 推送 LoRA adapter 时遇到问题，保存成功但推送失败，可能是由于 登录或密钥问题。
    • 他们注意到使用 trainer.model 与 model.push_to_hub 推送时文件大小存在差异，最终改用 CLI 上传。
  • Flow Free 可能成为推理基准：受 TTT-Bench 启发，一位成员建议重新审视 Numberlink/Flow Free 游戏，将其作为评估大型推理模型的推理基准，并链接到了他们的 提案。
    • 他们担心这是否与 TTT-Bench 过于重复，但欢迎在小组项目中进行协作。
  • UI/UX 模型训练成本对比：一位成员就针对编程任务（特别是 UI/UX）训练 AI 模型 寻求建议，并考虑使用 RLHF，得到的建议是获取一个 Unsloth Colab notebook。
    • 有建议认为，使用带有自定义 Prompt 的 Gemini 2.5 Pro 或通过 OpenRouter 使用 Sonnet 4，会比自行托管像 DeepSeek-R1-Distill-Qwen-32B 这样的微调模型更便宜且性能更好。
  • IBM Power 机架与 OS/2 引发辩论：在一位用户提到踩到生锈的钉子后，另一位用户开玩笑说该用户应该主修 IBM® Power® OS 2U 机架式服务器。
    • 另一位成员插话说 真正的老炮儿（OG）使用 OS/2，还有人注意到他们刚收到了 IBM 的广告。
  • AI 代码生成安全挑战调查：一位成员分享了一个关于生产环境中 AI 生成代码 面临的最大安全挑战的 5 分钟快速调查，并计划与社区分享结果。

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

DynamicCache Memory Recycling, Kaggle Gemma 3N Hackathon

  • DynamicCache 无法回收内存：一位成员报告称，在初始化 DynamicCache 并执行 LLM 推理后，尽管设置了 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True 并调用了 gc.collect(); torch.cuda.empty_cache()，KV cache 内存 仍未被回收。
    • 该用户正在寻求关于如何在推理函数返回后正确回收缓存并释放 VRAM 的建议。
  • Gemma 3N Hackathon 征集参与者：一位成员邀请其他人参加 Kaggle 上的 Google Gemma 3N Hackathon。
    • 未提供关于黑客松的更多细节。

HuggingFace ▷ #cool-finds (4 messages):

AGI impact, Roko's Basilisk

  • AGI 制作猫片，保住工作？：一位成员开玩笑说 我们拥有 AGI 已经好几年了，而我们所做的只是制作猫片，暗示人类的工作是安全的，因为人们只是 勉强识字的猴子。
    • 其他人对这一评价报以笑声。
  • Roko’s Basilisk 再次浮现：一位成员回复了 维基百科关于 Roko’s Basilisk 的页面 链接。
    • 这一思想实验暗示 AI 可能会惩罚那些没有帮助它诞生的人。

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

自动化 GPU kernel 优化，HF tokenizers 的薄 C ABI 封装，真菌基质作为忆阻器，简单研究 Agent

  • 进化 Metal Kernels 击败 MLX 基准：利用进化编程，一位成员自动发现了在 Apple Silicon 上用于 Transformer Attention 的 Metal kernels，击败了 MLX 的基准，实现了平均 12.5% 的加速和 106% 的峰值提升，代码可在 GitHub 获取，并在 HuggingFace 上有详细介绍。
  • HF Tokenizers 获得薄 C ABI 封装：一位成员为 HF tokenizers 创建了一个薄 C ABI 封装 (GitHub) 和 Raku 绑定 (GitHub)，允许在任何语言中以极少的 FFI 代码进行 token 编码、解码和计数。
  • PDF 不再破坏 NLP 流水线：一位成员发布了 pdf2seg (GitHub PyPi)，这是一个由 OCR 驱动、无需 tokenizer 的 PDF 分段器，具有熵感知分块、spaCy 结构检测以及用于 LLM 预训练和条款级提取的 CLI。
  • EasyTrain 简化 LLM 微调：一位成员介绍了 EasyTrain (GitHub)，这是一个不区分大小写的程序，可以用最少的代码简化 AI 训练或推理的设置。

HuggingFace ▷ #computer-vision (3 messages):

目标检测数据集可视化，HF Datasets 库，Grounding DINO 自动标注，HuggingFace CV 课程

  • 寻求本地目标检测数据集的 GUI：一位成员正在寻求一个 GUI 程序，以便使用 HF datasets 库可视化和编辑本地目标检测数据集的标注。
    • 他们已经尝试过 Label-Studio、vgg/via 和 fiftyone，但在加载数据集时遇到了问题。
  • 使用 Grounding DINO 自动标注的数据集：该目标检测数据集是使用 Grounding DINO 自动标注的，并存储在本地驱动器上。
    • 该成员提到数据尚未上传到 HUB。
  • HuggingFace CV 课程推荐！：一位成员建议查看 HuggingFace CV 课程。
    • 他们分享了该课程的链接。

HuggingFace ▷ #NLP (8 messages🔥):

k-means 中的余弦距离，用于主题分析的 Text Tilling，Tokenizers FFI，Llama 4 vs Claude 用于 MCP 客户端，trl SFT trainer 错误

  • k-means 中的余弦距离：好还是坏？：一位成员询问在通过归一化使 L2 距离表现得像余弦距离的 k-means 聚类中，将 cosine 作为距离度量是否是不良实践。
    • 其他成员没有参与讨论。
  • 探索用于主题分析的 Text Tilling：一位成员建议使用 text tilling 论文进行主题分析，因为主题建模没有产生预期的结果。
    • 该成员详细说明了将 text tilling 与 sentence transformers 合并，使 embedding 更有意义，可能在 embedding 和聚类之前将文章分割成更小的部分。
  • Tokenizers FFI 封装出现：一位成员宣布了 Rust 版本 tokenizers 的 C ABI 封装，可在 GitHub 获取。
    • 该封装包含一个用于 FFI 代码的 C 头文件，并在测试中提供了使用示例。
  • Llama 4 作为 Claude 的替代方案：一位成员询问是否可以仅将 Llama 4 用于 MCP 客户端，作为 Claude 的替代方案。
    • 其他成员没有参与讨论。
  • trl SFT Trainer 中缺少 “completion” 键：一位成员在使用 trl SFT trainer 时遇到了 KeyError: ‘completion’。
    • 尽管创建了带有模板的数据集、进行了预处理并使用了 DataCollatorForCompletionOnlyLM，但由于字典示例中缺少名为 “completion” 的键，仍然出现了该错误。

HuggingFace ▷ #smol-course (6 messages):

Smol Course Certificates, Smol Agents Certificates

  • 关于 Smol Course 证书的咨询：一位成员询问了 smol course 证书的可获得性，并对获得证书的前景表示兴奋。
    • 另一位成员澄清了该咨询是指 smol-course 还是 “smol agents” 课程，表示也在寻找相同的信息。
  • Smol Agents 证书仍然可用吗？：一位成员确认他们指的是 Smol Agents 课程，并询问该课程是否提供证书。
    • 另一位成员提到在 7 月之前就收到了证书，并表示非常喜欢这门课程。

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

Course Deadlines, Offline Course Access, DuckDuckGo Tool Integration, Smolagents Tips, Certificate Claims

  • 课程截止日期凭空消失：Agents 课程认证的 deadline 似乎已被移除，根据 更新信息，现在允许用户按照自己的节奏学习。
    • 此前曾出现混淆，一些用户认为 deadline 仍为 7 月 1 日，而另一些用户则指出了已更改为自主进度模式。
  • 没网？没问题！Agents 课程支持离线吗？：一位用户询问 Agents 和 MCP 课程是否提供 离线版本，以便在旅行期间利用离线时间学习。
    • 遗憾的是，截至目前，还没有关于这些课程是否可供离线使用的信息。
  • DuckDuckGo 工具集成困扰 Agents 学习者：一位学习者分享了 “duckduckgo_fact_finder” 工具的代码，在将其集成到 Agents 课程中时遇到了 bug，特别是在使用 DuckDuckGoSearchTool() 时。
    • 另一位成员指出，没有必要对 DuckDuckGo() 搜索工具进行封装，因为它已经可以直接传递给 Agent 使用。
  • Smolagents 寻求性能提升：一位在生产环境中使用二十多个 Agent 的用户正在寻找 Smolagents 的 性能优化技巧。
    • 具体来说，他们正在寻求关于混合使用 OpenAI 模型的见解，以降低成本（使用 4.1 进行规划，使用 4.1-mini 执行任务）。
  • 证书领取引发困扰：一位用户记录了他们领取证书的过程，解释了他们如何在自己的 Space 中完成课程，然后前往 证书领取页面。
    • 另一位用户补充说，他们从一开始就在创建账户时遇到了问题，并上传了一张显示按钮失效的截图。

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

Llama 3.3 70B, Cloudflare Vietnam Philippines issue

  • Llama 3.3 70B 降价 70%：Llama 3.3 70B 现在提供 70% 的折扣。
  • Cloudflare 问题已解决：调查了一个影响 越南 和 菲律宾 地区请求的 Cloudflare 问题。
    • 该问题现已解决，他们正在继续调查以了解问题的根本原因。

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

PGaaS Prototype Feedback, Chat Super Slow Update, Minmax-m1 to Llama 3.3, Authentication / Anti Rev, Codebase to Text Tool

  • PGaaS 原型发布，寻求反馈：一位用户发布了一个仓促制作的 PGaaS prototype，并在 paulgraham.resurrect.space 寻求反馈。
  • 聊天应用更新依然极慢：一位开发者为某个 chat application 推送了新更新，但据报告运行速度依然极慢，不过他们已从 minmax-m1(extended) 切换到了 Llama 3.3。
  • 身份验证与反逆向改进：在推送更新后，一位用户指出主要关注点将是增加 authentication / anti rev（反逆向）。
    • 开发者征求关于 UI/UX 改进的建议，提议增加语音模式或深色主题。
  • 代码库转文本工具发布：一位开发者发布了一个 codebase-to-text tool (PromptMan)，可将任何代码库转换为 Markdown 文件，地址为 PromptMan。
  • EveryDev.ai 使用 OpenRouter 进行工具共享：EveryDev.ai（一个 AI 开发者发现、评分和共享工具的新平台）的创始人一直在使用 OpenRouter，特别是通过 Cline API。
    • 他们正计划进行抽奖活动，并询问是否有办法创建 promo codes 或直接为用户账户注资，以便在 OpenRouter 上试用不同的模型。

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

OpenRouter token?, Gemini 2.5 Pro API, telegram raid, Automated spammers, GPT writing style

  • 关于 OpenRouter 代币的猜测：用户猜测是否存在 OpenRouter token ($OR)，一些人认为这与近期加密货币爱好者的涌入有关，然而官方已声明 没有 xp / 社区奖励，没有代币，没有 airdrop。
    • 成员们驳斥了这一想法，指出在获得 4000 万美元 A 轮融资 后，出现诈骗代币是不合常理的。
  • Gemini 2.5 Pro 免费层级传闻：一位成员根据 Logan Kilpatrick 的一条 推文 提到了关于 Gemini 2.5 Pro API 将提供 free tier 的传闻。
    • 社区希望免费层级能持续更久而不仅仅是一个周末，但一位用户担心可能会通过自动化手段遭到滥用。
  • OpenRouter 服务器遭受 Telegram 机器人袭击：OpenRouter Discord 服务器遭到了来自 Telegram 群组的袭击，大量新用户加入并发布通用的问候语。
    • 成员们推测这些用户是被 crypto rewards 或 airdrops 的承诺诱导而来的，而一位用户提到他们来自 Telegram 上一个名为 роснодмониторинг 的地方。
  • OpenRouter 服务器对抗自动化垃圾信息发送者：OpenRouter 社区正面临发布通用消息的 automated spammers 增加的问题。
    • 社区正在讨论潜在的解决方案，包括 automod rules 和手机验证，但尚未实施具体措施。
  • LLM 形容词过载的写作风格：一位成员抱怨 LLM 在创作小说时使用了过多的 expository adjectives（说明性形容词）。
    • 他们表示：“无论我告诉它多少次不要这样做，无论我给它展示多少个例子，它们都无法说出‘He snarled at her before walking away’（他在走开前对她咆哮），而是会说‘He glared at her evilly before storming off in anger’（他在愤怒地冲出去之前邪恶地瞪了她一眼）。”

OpenRouter (Alex Atallah) ▷ #beta-feedback (1 messages):

Error Identification, Image Analysis

  • 用户发现错误：一位用户报告了一个未说明的错误，并附带了一张 截图 作为参考。
  • 等待详情：需要进一步的信息来识别并解决该错误。

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

``

  • 未讨论新模型：该频道的活动仅包含显示频道名称的机器人消息。
  • 频道确认：该频道名为 ‘OpenRouter - New Models’，由 Readybot.io 管理。

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

近期模型中的结构化输出 (json_schema)，本地 LLM 的 PDF 输出，GGUF 离线安装，模型缓存/内存解释，lmstudio Discord 横幅

  • JSON Schema 支持依然稀缺：一位成员询问了近期模型（如 Qwen30-A3B）对 JSON Schema 的支持情况，并指出缺乏明确的文档说明。
    • 回复指出，目前仅确认 Qwen 模型支持结构化输出，但在该语境下的翻译准确性尚不确定。
  • LLM 可生成 LaTeX 用于创建 PDF：一位成员询问如何从本地托管的模型（如 Llama 3）生成 PDF。
    • 另一位成员建议让模型输出 LaTeX 代码，然后使用现成工具将其转换为 PDF。
  • 分享 GGUF 离线安装指南：一位用户询问如何在没有网络连接的计算机上离线安装 GGUF 模型。
    • 其他成员解释了操作步骤：在联网的 PC 上下载模型，通过 USB 传输，并将其放置在正确的 LM Studio 目录中 (/home/user/.lmstudio/models/publisher/model-name)。
  • 推荐 RAG 架构而非“缓存”：一位用户想知道模型是否可以从聊天开始处恢复其记忆。
    • 成员们建议使用带有本地向量数据库的 RAG (Retrieval-Augmented Generation) 来存储和检索过去的交互，而不是依赖模型的“缓存”。
  • LM Studio 新的视觉模型也能推理：一位成员链接了一个 Reddit 帖子，询问 LM Studio 是否支持视觉和推理模型。
    • 另一位成员确认 LM Studio 同时支持视觉和推理模型，且 Reddit 帖子中的截图确实来自 LM Studio。

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

LLM 的云端部署，Runpod 与 AWS 在 LLM 方面的对比，本地 LLM 服务基础设施，LLM 的 GPU 推荐，Mac M4 Pro 推理速度

  • Python 工具启动 AWS 虚拟机：一位成员建议使用 Python 工具 轻松启动 AWS 虚拟机，并指向了一份创建 EC2 实例的指南。
    • 另一位成员发现了一份关于在 AWS 上运行 LM Studio API 服务器的 LinkedIn 指南。
  • Runpod 与 AWS 在 LLM 部署上的对比：成员们讨论了使用 Runpod 或 vast.ai 作为 AWS 的替代方案来部署 LLM，因为它们可能更节省成本并满足特定需求。
    • 出于安全考虑，建议不要将 vLLM/Ollama/LMStudio 端口暴露给互联网，而是使用本地流量服务。
  • 本地 LLM 服务的基础设施考量：对于向 100-150 名用户提供本地 LLM 服务，建议 UI 使用 openwebui，软件栈方面推荐使用 vLLM。
    • 硬件需求取决于模型的规模和数量，推荐包括 A100 或 H100 GPU，并建议在选择硬件之前先确定并发和性能需求。
  • GPU 推荐与可用性：关于使用 6 块 6000 Pro（576GB 高性能 CUDA）的建议引发了讨论，因为这些显卡刚上市，可能不容易买到。
    • 关于预算也有讨论，有人建议尽量接近顶级配置，而另一位则表示在推荐任何东西之前应先从实际需求出发。
  • 优化 Mac Mini M4 Pro 上的模型推理：用户讨论了 Mac Mini 与 30/40/5090 PC 相比，Prompt 处理速度较慢的问题。
    • 有人指出 Qwen 3 30b 运行速度更快，因为它是一个 Mixture of Experts (MoE) 模型；此外，Mac Mini 的带宽较低且 GPU 核心数较少，这也是导致 Prompt 处理时间较长的原因。

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

Stanford 的 Marin 项目、Percy Liang 的重命名倾向、基于 Jax 的预训练基础设施、UI 设计 LLM、Emergent Misalignment 论文

  • 斯坦福大学 Marin 项目启动，使用 LLM：来自斯坦福的 David 介绍了 Marin 项目，该项目专注于 LLM 相关事务，并分享了相关的 YouTube 视频。
    • 他澄清说他的角色涉及 pretraining infra（预训练基础设施），但相当“全栈”。
  • Percy 被指责频繁重命名既有概念：一名成员批评 Percy Liang 总是重命名已确立的概念（例如 foundation models），并以此获取品牌效应或引用，指出 open development 在过去几十年里一直被称为 open science。
    • 另一位从事 metascience 研究的人员补充道，他们（所有团队）所做的工作远超常规的 opensci，但相比 open dev，他更倾向于使用另一个新名称。
  • Jax 驱动学术界预训练基础设施：讨论强调了 Jax 在学术界被用于 pretraining foundation models，特别是在 TPUs 上，Levanter 是一个用于训练的 Jax 代码库。
    • 成员们提到 Google 通过 TRC 提供 free compute（免费算力），但预训练耗费资源巨大，且 TPU 通常需求量很高。
  • 初创公司面临现实考验，需要更好的 UI/UX：一位初创公司创始人就构建用于 UI 设计的定制 LLM 寻求建议，认为 pretraining+RLHF layering 是最佳选择，但被警告了所需的成本和时间。
    • 资深成员建议使用具有视觉能力的现有模型（如 Gemini Pro 或 Claude），并配合智能 prompting 和 scaffolding，或者使用 R1 和 Qwen code，而不是在没有资金的情况下尝试从头训练模型。
  • Emergent Misalignment 论文复现受挫：一名成员报告称，难以复现原始 emergent misalignment 论文中提到的 misalignment rate。
    • 其他人建议，结果取决于所使用的 judge model（例如 GPT-4o），而且 GPT-4o 自论文发布以来可能已经更新，此外数据集也很关键。

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

Spectral Decay 优化、DROID 机器人学习、组合生成模型、NAACL 2026 取消传闻、Qwen 3 1.7B diffusion LM

  • Spectral Decay 优化器对比：一名成员表示，2017 年的 spectral decay 研究 类似于 Adam 的 spectral decay 版本，而 苏剑林的博客文章 则类似于 AdamW 的 spectral decay 版本。
  • 用于机器人学习的 DROID 算法：DROID 算法通过对奖励和策略的个性化组件进行建模，使机器人能够利用有限的数据，更准确、高效地从用户那里推断行为模型。
    • 根据这篇论文，它利用有限的数据，适用于环境 rollout 成本过高或不安全的应用场景。
  • 常数内存 Diffusion 模型即将到来：成员们分享了一项与常数内存 diffusion 模型相关的工作，虽然 constant memory 可能会带来限制，但这篇论文显示这是一个良好的开端。
  • Qwen 3 1.7B 被重新用于 diffusion：Qwen 3 1.7B 正被重新用作带有 byte tokenizer 的 diffusion LM，在 4 张 4090 上仅花费了几小时的训练时间。
  • NAACL 2026 面临取消？：有传言称 NAACL 2026 可能会被跳过，目前尚未发布官方公告。
    • 一名成员表示：“我的博士导师告诉我，她听说该会议将被跳过，我们不确定该往哪里投稿。”

Eleuther ▷ #interpretability-general (3 messages):

Model Diffing, Crosscoders, SAE on (chat - base) activations, refusal detection, OpenAI's sycophantic model update

  • 模型差异分析 (Model Diffing) 破译差异：一篇关于 模型差异分析的帖子 扩展了 之前的论文，重点在于从内部理解微调模型与基础模型之间的不同之处。
    • 作者发现 crosscoders 会因为稀疏性强制执行而产生虚假的差异，但在 (chat - base) 激活值 上训练 SAE 的效果出奇地好。
  • 特征暴露揭示拒绝行为：所使用的方法揭示了与 拒绝检测 (refusal detection)、虚假事实 (fake facts) 或模型身份信息相关的可解释特征。
    • 作者建议模型差异分析是一个很有前景的研究方向，本可以发现 OpenAI 的谄媚模型更新 (sycophantic model update)。

Eleuther ▷ #lm-thunderdome (1 messages):

noble_monkey_75488: nvm codex 对应 humaneval

GPU MODE ▷ #general (27 messages🔥):

GPU MODE Binary Submission, SGLang Community, TorchServe Maintenance, PyTorch Model Serving, TorchScript vs AOTInductor

  • **GPU MODE 要求 Python 提交：参与者澄清，向 GPU MODE 排行榜 提交的内容需要是一个 **Python 函数，而不是二进制文件。
    • 提交过程会挂载到他们的评估系统中，在提供灵活性的同时，也欢迎关于 CUTLASS 等额外库支持的反馈。
  • **SGLang 寻求活跃的 Slack 空间：成员询问了学习 **SGLang 开发的活跃社区，得到的建议是参考 SGLang GitHub。
    • 据报道，该社区对于寻求指导的开发者来说非常活跃且响应迅速。
  • **TorchServe 停止支持引发替代方案搜索：根据 PyTorch 官方仓库，TorchServe** 正式进入“有限维护 (Limited Maintenance)”状态，这意味着不再有计划内的更新、错误修复或安全补丁。
    • 这一转变引发了关于生产环境中最佳模型服务解决方案的讨论，特别是随着 PyTorch 2.0+ 中 torch.compile 等运行时优化技术的兴起。
  • **PyTorch 模型服务解决方案浮出水面：对于服务 **PyTorch 模型（特别是 LLM），建议倾向于使用 VLLM 或 SGLang，因为它们具有系统级优化。
    • 同时也提到了 NVIDIA 的 Dynamo 和 类似 Flask 的解决方案，后者将模型性能的责任交给了用户。
  • **TorchScript 没落，AOTInductor 崛起：TorchScript** 不再维护，因此你遇到的任何错误或回归都将无法获得帮助。
    • 如果运行 Python 的开销可以接受，你应该启用我们的 MegaCache pytorch.org；如果不可接受，则应使用 torch.export 和 AOTInductor pytorch.org。

GPU MODE ▷ #triton (5 messages):

Scatter/Scatter_add in Triton, Getting Started with Triton

  • Triton 中 scatter/scatter_add 的可用性：一位成员询问了 Triton 中 scatter/scatter_add 的可用性，并引用了 Triton 仓库中的特定代码行。
    • 该成员不确定如何使用该函数。
  • 开启 Triton 冒险：一位成员询问了如何开始学习 Triton 的建议，寻求初步步骤和练习题的建议。
    • 另一位成员建议尝试让任何东西运行得更快，并争取在 gpumode.com 列出的问题中进入前三名。

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

SM80 使用, nvcc 编译器常量内存使用, GPU 上的 Little's Law, CUDA kernel 优化

  • 分享 SM80 经验：一名成员提到正在使用 SM80，并表示有兴趣与其他成员交流经验。
    • 上下文中未分享关于 SM80 使用或共同方面的具体细节。
  • nvcc 常量内存困扰：一名成员面临 nvcc 编译器为每个函数保留常量内存的问题，即使函数为空也是如此，这导致了常量内存溢出和性能下降。
    • 他们尝试合并 device 函数，在 --rdc=true 和 --maxrregcount=88 的情况下使用 noinline，但问题仍然存在；每个函数保留约 300-400 字节的 cmem[0]。
  • Little’s Law 关联 GPU 与 DRAM：成员们讨论了 Little’s Law 如何应用于 GPU 和 DRAM 之间的连接，引用了 NVIDIA 关于在 Hopper 和 Blackwell 上使用 LDGSTS 和 TMA 的教程。
    • 带宽的增长速度超过了每个 GPU 的 SM 数量，因此需要更多的在途字节（bytes in flight）来充分利用带宽，正如本次 GTC 演讲中所强调的那样。
  • 探索 Kernel Spill 边界：一名成员建议使用独立的 .cu 文件来显式强制大型 kernel 中的 spill 边界，而不是依赖于模糊暗示 spill 的 noinline。
    • 他们解释说，nvcc 通常会构建一个巨大的 ptx blob，但寄存器压力会导致 spill 和函数调用，通过考虑同一 warp 的线程是否进入 switch 的相同分支来控制这一边界可以优化性能。

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

torch.export 模型导出, FlexAttention 集成, vmap 与 torch.export 的不兼容性, Executorch 模型导出变通方案

  • Torch 导出面临挑战：用户发现使用 torch.export 导出模型很困难，即使使用像 Mistral-7B-v0.1 这样看似标准的模型，也经常遇到与 vmap 和 .item() 调用相关的 RuntimeError。
    • 一名用户将错误追溯到 HF 的 masking_utils.py，该文件使用了 vmap，并指出 torch.export 似乎不支持它。
  • FlexAttention 在导出中的情况尚不明确：目前尚不清楚使用 FlexAttention 的模型是否可以在不进行修改的情况下通过 torch.export 轻松导出。
    • 一名用户最初怀疑 FlexAttention 可能是导出失败的原因，但随后澄清他们只是尝试直接从 Hugging Face 导出模型，而没有指定特定的 attention 实现。
  • Executorch 提供临时变通方案：Executorch 为导出与 torch 不兼容的模型提供了临时变通方案。

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

Exo 2, 用户可调度语言 (USLs), 调度操作

  • Exo 2 演讲安排：一名成员关于 Exo 2 的演讲定于 30 分钟后开始。
  • Exo 2 旨在扩展 USLs：论文摘要将 Exo 2 描述为一种调度语言，使用户能够在编译器外部定义新的调度操作。
    • 它由一组可信的细粒度原语组成，以便用户可以安全地编写自己的调度库，从而构建所需的自动化。

GPU MODE ▷ #jobs (4 messages):

CUDA kernel integration, vLLM module replacement

  • 寻找 CUDA Kernel 集成专家：一个研究小组正在寻找一名顾问，负责将自定义 CUDA kernel 与高性能 LLM 推理引擎集成，预计工作时间约为 4 小时。
    • 他们的目标是通过将自定义 CUDA kernel 集成到 LLM 推理中来展示加速效果。
  • 使用 custom_op 包装 CUDA 调用：一位成员建议将 CUDA 调用包装在 custom_op 中，并将目标 vLLM 模块（例如 LinearMethodBase）替换为自定义类。
    • 该自定义类随后将在 .apply() 方法中调用 CUDA kernel。

GPU MODE ▷ #beginner (40 messages🔥):

Numerically unstable lerp function, CPU vs GPU efficiency, GPU warps and parallelism, Breaking hashes on GPU, CUDA thread count optimization

  • 发现数值不稳定的 Lerp 函数！：一位成员指出代码中的 lerp 函数 在数值上是不稳定的。
    • 原作者承认了这个问题，但表示：“它能跑，所以我不想动它”。
  • 关于 CPU 与 GPU 效率的辩论浮出水面！：讨论围绕特定工作负载在 CPU 上是否更高效展开，理由包括非均匀循环迭代会导致 FLOPs 浪费。
    • 有人解释说，循环最长的线程会迫使其他线程等待，如果某些线程的迭代次数显著减少，可能会浪费计算资源。
  • GPU Warps 和并行性解析！：一位成员澄清说，GPU 核心以 warps（通常为 32 个线程）为单位运行，在不同数据上执行相同的代码，这与可以独立运行的 CPU 核心不同。
    • Kernel 逻辑中的分支和条件语句会导致 GPU 核心同步，从而可能降低并行性，因为所有核心在分支后都会执行相同的代码。
  • 在 GPU 上进行哈希很流行！：一位成员将破解哈希描述为 寻找 x 使得 hash(x) = y，其中已知哈希值和 y，而 x 通常是明文密码。
    • 另一位成员确认 这正是我在做的，只不过没有密码之类的东西，而且是在 CPU 上单线程运行。
  • CUDA 线程数优化！：讨论建议最大限度地提高每个 warp 的利用率，以避免核心空闲，并在空闲的 warp 上加载另一个 kernel。
    • 建议参考 CUDA documentation 获取最佳实践，并使用 nsight compute 根据寄存器使用情况和共享内存（shared memory）确定最佳线程数。

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

Geoffrey Hinton, AI risk, Becoming a plumber

  • Hinton 的水管工转型建议：成员们正在讨论 Geoffrey Hinton 关于 AI 风险的观点，以及他建议人们应该考虑成为水管工。
    • 他担心 AI 可能会使许多工作自动化。
  • AI 会毁灭我们所有人吗？：Hinton 对 AI 的未来感到 恐惧。
    • 他警告说，AI 将来可能会使许多工作自动化，导致许多人失业。

GPU MODE ▷ #rocm (12 messages🔥):

buffer_load_dwordx4 instruction, Composable Kernel, rocprofiler-sdk ABI

  • Buffer Load 盛宴：一位成员询问了关于使用 buffer_load_dwordx4 指令的经验，另一位成员分享了他们的实现。
    • 该成员指出文档稀缺，而另一位成员澄清说，他们代码的一部分（特别是 buffer 处理）是参考 Composable Kernel 库改编的。
  • Composable Kernel 组合：一位成员表示，buffer 处理代码是从带有注释的 Composable Kernel 中提取的，但出于性能原因实现了自己的 unroll 代码。
    • 他们发现 CK 的 unroll 比较繁琐，且与 C++20 模板化 lambda 不兼容，因此鼓励其他人自由复用他们的代码片段。
  • Rocprofiler 发布 ABI 更新：一位成员注意到 libatt_decoder_trace.so 的 ABI 略有不同，但主线 rocprofiler-sdk 现在应该可以识别 librocprof-trace-decoder.so。
    • 另一位成员确认了这一改进，标志着 rocprofiler 工具链的一次积极更新。

GPU MODE ▷ #webgpu (1 messages):

wgpu-rs, storage texture, r8unorm

  • 在 wgpu-rs 中使用 r8unorm storage texture 遇到麻烦: 有用户报告称，他们无法在 wgpu-rs 中将 r8unorm 作为 storage texture 的格式。
  • wgpu-rs 与 r8unorm: 一位使用 wgpu-rs 的用户报告了在尝试使用 r8unorm 作为 storage texture 格式时的错误。
    • 尽管该格式已列入 规范，但 wgpu-rs 的实现却抛出了验证错误（validation error）。

GPU MODE ▷ #self-promotion (21 messages🔥):

Automated GPU Kernel Optimization, OpenEvolve Tool, Thread Value Layouts in CuTe, NVIDIA PTX Kernel, TokenDagger for Tiktoken

  • 进化后的 Kernels 在 Apple Silicon 上击败 MLX: 一位成员利用演化编程（evolutionary programming）自动发现了 Metal kernels，在 Apple Silicon 上的 Transformer attention 任务中超越了 MLX 的基准线，在某些工作负载下实现了 12.5% 的平均加速和 106% 的峰值加速，详情见其 HuggingFace 博客文章和 GitHub 仓库。
  • Simon 视觉化讲解 CuTe 中的 Thread Value Layouts: 一位成员分享了一篇受 Cris Cecka 的 GPU Mode 讲座启发的 博客文章，通过视觉图表和示例解释了 CuTeDSL 中的 thread value layouts，并附带了 讲座视频和 幻灯片链接。
  • 手写 PTX Kernels 性能优于 CUDA: 一位成员使用手写的 NVIDIA PTX kernels 实现了一个仅限推理版本的 Andrej Karpathy 的 LLM.c 项目，与等效的 CUDA 实现相比，性能提升了 10%，代码已在 GitHub 开源，并在 系列博客中进行了详细说明。
  • TokenDagger 对 Tiktoken 文本的分词速度更快: 一位成员在 TokenDagger 中重新实现了 OpenAI 的 Tiktoken，据报告在单线程上对代码样本的分词实现了 2-3 倍的吞吐量提升和 约 4 倍的加速。
  • Chisel 优化 Kernel Profiling 工作流: 一位成员介绍了 Chisel，这是一个用于在 Nvidia 和 AMD GPUs 上进行本地即时 Kernel 性能分析（profiling）的工具，可通过 pip install chisel-cli 安装，并在 GitHub 上可用，目前支持在 AMD 云端通过 DigitalOcean 租用 MI300X。

GPU MODE ▷ #thunderkittens (6 messages):

ThunderKittens Repo, Research Assistant at Hazy, load_async_wait call, Thundermittens retirement

  • ThunderKittens Kernel 示例涌现: 仓库中有很多 ThunderKittens kernel 示例，包括为 int 8 提交 pull request 的机会。
    • 维护该仓库的博士生表示，他们无法支持所有内容，并非常期待看到更多的社区贡献。
  • 探讨 Hazy Research 的 RA 职位: 有人提出了关于非斯坦福学生如何成为 Hazy 研究助理（RA）流程的问题。
    • 然而，目前还没有关于该流程的详细回复。
  • 发现异步加载参数异常: 一位用户注意到 kernels/attn/demo 中 4090.cu 的 load_async_wait 调用参数为 N=1，但 readme.md 示例显示为 N=2（这才是正确的）。
    • 4090.cu 中 load_async_wait 参数的不一致性被作为一个潜在问题提出，但尚未得到解决或确认。
  • Thundermittens 被清理了？: 一位用户在发现仓库被删除后，询问 Thundermittens 是否已退役。
    • 遗憾的是，目前还没有确认或否认该仓库状态的回复。

GPU MODE ▷ #reasoning-gym (1 messages):

remek1972: 如何切换到 fp16？

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

CLI 问题，Trimul 周边奖品

  • **CLI 崩溃：正在调试中！：一位用户报告 **CLI 无法工作，怀疑是后端问题，但指出 Discord 提交 仍然正常。
    • 一位开发者确认该问题已在 API 端修复，目前正在等待修复机器人端的 PR 获批，并承诺在完成后提醒该用户。
  • **Trimul 奖杯：暂定时间窗口！：一位用户询问了 **Trimul 周边奖品 的截止日期。
    • 一位开发者回复称，考虑到周边产品的准备情况，截止日期暂定为 3 个月，并暗示 Mark 会非常慷慨。

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

H100 Grayscale, A100 Trimul, L4 vectorsum, T4 histogram, MI300 amd-identity

  • 在 H100 上取得 Grayscale 个人最佳成绩：一位成员使用 H100 在 grayscale 排行榜上多次刷新个人最佳纪录，最高成绩达到 1431 µs。
  • Trimul 在 A100 上获得第 5 名：一位成员凭借在 A100 上 23.2 ms 的成绩，锁定了 trimul 排行榜的 第 5 名。
  • vectorsum 在 L4 上表现出色：一位成员报告在 L4 上成功提交了 vectorsum 排行榜成绩，耗时约为 970 µs。
  • Histogram 在 T4 上排名第 4：一位成员凭借在 T4 上 169 µs 的成绩，获得了 histogram 排行榜的 第 4 名。
  • amd-identity 拿下 MI300：一位成员在 MI300 上以 19.3 µs 的成绩位列 amd-identity 排行榜 第 9 名。

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

CLI 修复，提交错误

  • CLI 工具获得修复：CLI 工具 已修复，可从 发布页面 下载。
    • 用户现在可以访问更新后的版本。
  • 提交遇到意外错误：一位用户报告了 Submission 32983: amd-identity.py for amd-identity 的意外错误，收到的消息为 An unexpected error occurred. Please report this to the developers。
    • 该用户已按照指示报告错误以供调查。

GPU MODE ▷ #factorio-learning-env (8 条消息🔥):

Factorio 实体获取问题，Factorio 实验室蓝图，Neel 的布拉格之旅

  • **Factorio 实体获取面临阻碍：一位成员报告了在 **Factorio 地图上有数百个实体时，获取实体出现的问题。
    • 他们正在使用一个生产红、绿、蓝科技的实验室蓝图 (Lab_blueprint.txt)，并寻求基于此生成数据的帮助。
  • **Factorio 开发者前往布拉格**：一位成员提到刚旅行回来，周四将前往布拉格与开发者会面。
    • 他们邀请团队成员分享任何希望他在会面中向开发者提出的建议。

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

producer/consumer warps，CUDA 中的数据移动

  • Producer/Consumer Warps：何时使用？：一位成员询问在 CUDA 中，何时使用 producer/consumer warps 比自行管理数据移动的 warps 更有优势的系统性方法。
    • 问题核心在于该决策是取决于经验测试，还是存在选择这两种方法的指导原则。
  • 优化 CUDA 中的数据移动：讨论集中在 producer/consumer warps 与自管理 warps 在 数据移动 方面的权衡。
    • 该咨询强调了需要一套清晰的方法论，以根据特定应用的需求来指导选择过程。

GPU MODE ▷ #singularity-systems (3 messages):

Systems ML Compiler Project, Heterogenous Deep Learning Stack, Compiler IRs, Max Bernstein on IR design

  • Systems ML 编译器项目寻求贡献者：一位成员正在为一个面向 Systems ML 社区的严肃编译器项目寻求贡献，旨在实现 C, CUDA C, Triton 和 PyTorch 的子集，以支持当今深度学习系统的异构栈，详见 Zero-to-Hero 项目页面。
  • SoN 编译器的初步进展：SoN 编译器已开始开发，实现了 C 的子集并在此基础上构建了 CUDA C 扩展，初始代码可在 parser.rs 和 optimizer.rs 中查看。
  • IR 设计哲学亮点：分享了 Max Bernstein 关于 IR 设计的一篇博客文章，强调了仅利用局部信息进行决策的核心前提，文章链接在此。

Yannick Kilcher ▷ #general (108 messages🔥🔥):

spherical k-means, sentence segmentation techniques, LLM hallucinations, pretraining LLMs, GritLM

  • 球面 K-means：在 k-means 聚类中使用余弦（cosine）作为距离度量是一种众所周知且有效的做法，被称为球面 k-means 聚类（spherical k-means clustering）。
    • 归一化有助于 L2 距离表现得像余弦距离，这在基础设施限制导致无法使用专门工具处理大数据时特别有用。
  • LLM 在幻觉和预训练偏差方面面临挑战：成员们讨论了减轻 LLM 中幻觉和改写（paraphrasing）的技术，其中一人建议在一系列长 CoT 数据集上进行预训练，以解决预训练偏差。
    • 建议的解决方案是清洗训练数据集并对 LLM 进行预训练，而不是依赖 RLHF 或巧妙的 Prompt 模板。
  • GritLM 用于句子分段：一位成员询问了除了基础的句号或分号之外的句子分段（sentence segmentation）技术，甚至包括对类似 (a), (b) 的列表结构进行分段。
    • 提到了 GritLM 模型作为解决该问题的资源。
  • DeepSeek 和 NSAttention 展现潜力：讨论涵盖了改进注意力机制（attention mechanisms）的研究，其中来自 DeepSeek 的 NSAttention 被强调为一种极具前景的扩展到更大上下文的方法。
    • 目前已经存在已知的解决方案来解决该问题并使其更具表达力。
  • 博客文章探讨 AGI 所需的能力：一位成员分享了一篇讨论 AGI 所需能力的博客文章，强调了在不进行重新训练的情况下获得持久技能的重要性。
    • 另一位成员强调，无需重新训练即可获得持久技能的能力是一个先决条件，并建议使用诸如 TTT 馈入 PEER 之类的技术来构建新权重并将其添加到不断扩展的数据库中。

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

Associative Memory, LLM Alignment, RWKV-7 Goose, Human Cognition vs LLMs, Virility of Content Prediction

  • 从关联记忆视角看 Transformers：一位成员分享了题为《从 Associative Memory 视角理解 Transformer》的论文，该论文通过关联记忆的视角探索了 Transformer architectures。
    • 论文引入了检索 SNR 来衡量记忆容量，并提出 FFNs 可以被视为一种关联记忆。
  • LLMs 与人类认知：一个有害的视角？：一位成员对通过人类认知来观察 LLMs 的论文表示反感，认为这混淆了对 LLMs 根本工作原理的理解。
    • 另一位成员反驳称，这种视角对于实际应用场景很有价值，特别是在训练数据和 fine-tuning 等领域，并引用了这篇论文。
  • LLMs 模拟人类反应：一位成员建议利用 AI 通过模拟人类反应来预测内容的病毒式传播性 (virility of content)，并指出利用 LLMs 模仿人类心理的研究尚未得到充分开发。
    • 另一位成员反对将 LLMs 与人类认知混为一谈，主张直接使用 LLM 来模拟人类，但也同意人类认知视角允许使用来自其他领域的不同工具和技术来解决原本难以处理的问题。
  • RWKV-7 Goose 架构首次亮相：一位成员介绍了 RWKV-7 “Goose”，这是一种新型序列建模架构，具有常数级内存占用和每个 token 常数级推理时间。
    • 这个 29 亿参数的语言模型在多语言任务上达到了新的 3B SoTA，尽管训练 token 数量远少于其他顶级模型，但在英语下游任务性能上也达到了目前的 3B SoTA。
  • LLM Alignment：依然不可能？：一位成员建议使用 ChatGPT 来寻找对齐资源，同时提醒说，对于 LLM 来说，对齐在根本上是不可能的。
    • 他们还指出，聊天机器人通常是关于 AI 信息的最差来源，因为它们是在大量炒作的废话上训练出来的，并指出 LLM 的谄媚（sycophancy）是一个过度对齐（overalignment）的问题。

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

ML for Drug Discovery, Synthetic Data Contamination, Comparing Reasoning Models, Healthcare Costs and Access

  • 机器学习用于药物研发活动即将开启！：一场名为 ML for Drug Discovery 的免费在线活动预计在约 24 小时内举行，届时将有提供该领域概览的主旨演讲。
    • 去年的活动被认为非常棒，录像将在 YouTube 上提供。
  • 用合成数据刷榜 Benchmark？：一位成员推测，让模型在各项测试中获得 90% 以上高分的方法是增加数据污染和“合成数据”（也是一种污染）。
  • 对比推理模型（Reasoning Models）时的担忧：一位用户表达了对将自己的推理模型与非推理模型进行比较的担忧，并表示：“它们都是‘非推理’的，即使 ScientAIology 教派不将其视为教条。”
  • 各国医疗成本差异：讨论围绕一张关于医疗成本的图表（推文链接）展开，一位成员指出该图表基于美国的测试成本和每次 300 美元的医生就诊费，并质疑其他国家的成本轴会如何变化。
    • 进一步讨论指出，在那些将健康视为基本人权的地方，医疗获取和成本与美国模式有显著不同，在美国模式中，“医疗保险公司的医生会因为拒绝理赔（变相杀人）而获得奖金”。

aider (Paul Gauthier) ▷ #announcements (1 条消息):

Gemini 2.5 模型, Responses API 模型, Gitignore 文件, Commit 消息生成, MATLAB 语言支持

  • Aider 添加新的 Gemini 2.5 模型：Aider 现在支持新的 Gemini 模型，包括支持 thinking tokens 的 gemini-2.5-pro、gemini-2.5-flash 和 gemini-2.5-pro-preview-06-05。
  • 支持 Responses API 模型：Aider 现在支持 Responses API 模型，如 o1-pro、o3-pro。
    • 此外，已在多个提供商中增加了对 OpenAI o3-pro 模型的支持，并更新了 o3 的定价。
  • Aider 现在支持添加 Gitignore 文件：新增了 --add-gitignore-files 标志，允许将 .gitignore 中列出的文件添加到 Aider 的编辑范围中，由 omarcinkonis 贡献。
  • Commit 消息使用系统提示词前缀：Commit 消息生成功能得到增强，支持使用系统提示词（system prompt）前缀，由 Luke Reeves 贡献；此外，Commit 消息现在默认启用 co-authored-by 署名。
    • 还增加了一个 --commit-language 选项，用于指定 Commit 消息的语言，由 Kyosuke Takayama 贡献。
  • MATLAB 现已成为支持的语言：代码库地图（repository maps）已添加对 MATLAB 语言的支持，由 Matthew Tofano 贡献。

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

Sonnet 4 使用情况, QLora 训练, O3 性能, Claude Code, Aider 工作区

  • Sonnet 4 采用情况尚不明确：一位用户在 architect 模式下使用 Sonnet 3.7，在 edit 模式下使用 Sonnet 3.5，并询问其他人是否已在 architect 模式下切换到 Sonnet 4 以及效果如何。
    • 截至本次快照，频道内尚未对该查询做出回应。
  • QLora 训练数据生成加速：一位用户使用 GPT-4.1 在 2 小时内为其 qlora aider 训练生成了 355 个示例，目标是达到 1,000 个示例。
    • 他们开玩笑说要“榨干微软”并使用指数级增长的 token，并询问了 O3 + GPT-4.1 的成本更新情况。
  • O3-Pro 在 Aider 基准测试中达到 SOTA：OpenAI 的 o3-pro 在 aider 多语言编程基准测试中，通过“高（high）”推理强度设置达到了 85% 的新 SOTA；结果可在 排行榜 查看。
  • Claude Code vs Aider：详细对比：用户讨论了 Claude Code 与 Aider 的优缺点，一位用户指出 Claude 的优势在于通过单个提示词构建大型项目的脚手架，而 Aider 则允许更精确、更原子化的编辑。
    • 另一位用户分享了利用 Gemini Web UI 生成指令然后在 Aider 中应用的流程，但由于 Claude Code 的速度和自动化程度，目前已切换到该工具。
  • 对 Aider 工作区（Workspaces）功能的需求：由于速度瓶颈和编译语言中潜在的上下文问题，一位用户请求 aider 支持工作区和/或并行开发多个功能。
    • 其他人建议使用 tmux 或管理独立的项目副本，但该用户希望有一个集成的解决方案，用于创建工作区并在测试通过后进行合并。

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

Anthropic 封禁, Aider 成本效率, OpenRouter DeepSeek, 本地 LLM 性能, Gemini 流式传输问题

  • Anthropic 封禁 Aider 用户：一名成员报告在使用 Aider 调用 Claude 时被 Anthropic 封禁，怀疑是 VPN 问题，但另一名在 Claude 中使用 VPN 且没问题的成员反驳了这一观点。
    • 另一名用户因超出付费额度限制而被“封禁”。
  • Aider 用户寻求成本效率技巧：一名 Aider 新用户正在寻求使用 Anthropic API 的 省钱技巧，发现其价格比 Zed、Cursor 或 Windsurf 等固定费用替代方案更贵。
    • 建议包括使用 DeepSeek 模型、OpenRouter、减少文件包含、定期使用 /drop X 和 /clear 清理上下文，以及在 Aider 执行前结合 RepoMix 和 Gemini AI Studio 进行规划。
  • OpenRouter 的 DeepSeek 输出中文符号：一名用户报告称 OpenRouter/DeepSeek 模型虽然更便宜，但在生成的代码中混入了 中文符号。
    • 另一名用户在使用 deepseek/deepseek-reasoner API 时遇到了无尽的“等待”时间，随后返回空响应。
  • LLM Agent 在本地表现不佳：一名用户发现，在 16GB GPU 上运行 Qwen3 14B、DeepSeek r1-0528 和 Qwen2.5 Coder 14B 等模型时，基准测试分数与本地实际性能之间存在显著差异。
    • 他们想知道在本地运行模型时是否存在常见的瓶颈。
  • Gemini 流式传输缓慢？：一名用户报告了 Gemini 模型的流式传输问题，在生成响应期间会出现 长达一分钟的停顿。
    • 建议的解决方法是：逐个文件或逐块请求更改。

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

shards.prefix.dev DNS, Mojo GPU Puzzles 损坏, Mojo 定点支持, Modular 职业发展, Mojo/MAX 快速入门

  • shards.prefix.dev DNS 记录曝光：一名成员请求查询 shards.prefix.dev 的 DNS 记录，另一名成员提供了 dig 输出，显示有 三个 A 记录：104.26.12.188、104.26.13.188 和 172.67.72.103。
    • 该查询使用 DiG 9.10.6 耗时 3634 毫秒，是在 iPhone 4G 连接下运行的。
  • GPU Puzzle P17 已损坏，需要修复：一名成员报告称 GPU puzzle P17 可能已损坏，原因是 custom() 调用中缺少参数 (device)，且存在未定义的 softmax_gpu_kernel 函数。
  • 用于定点算术的 Decimojo 库：在关于跨平台浮点数一致性的讨论中，一名成员分享了用于 Mojo 定点算术的 Decimojo GitHub 仓库 链接。
    • 该仓库同时支持软件和硬件加速（使用 SIMD）。
  • 开启 Modular 职业生涯：查看官网职位：一名成员询问在 Modular 工作需要掌握哪些编程语言，一名员工建议查看 Modular 职业页面。
    • 网站上列出了各种职位公告。
  • Mojo 新用户寻求入门指导：一名 Mojo 新用户询问如何快速入门 Mojo/MAX 以参与 Slack 频道讨论，一名成员建议从 GPU puzzles 和 Modular 官网上的其他教程开始。
    • 另一名成员建议将 Mojo GPU 入门教程 作为良好的起点，该教程末尾附有 GPU puzzles 的链接。

Modular (Mojo 🔥) ▷ #announcements (3 messages):

Modular Hack Weekend, Office Hours, Show & Tell, Project Submission, Live Demos

  • Modular Hack Weekend Office Hours 即将开启：Modular Hack Weekend 的 Office Hours 环节将在约 1 小时后（太平洋时间上午 11 点）通过 此 Zoom 会议 开始。
    • 团队将主持一场非正式的 Q&A，开发者可以针对其黑客松项目中的问题进行提问。
  • Modular Hack Weekend Show & Tell 正在进行中！：由 Chris Lattner 主持的 Modular Hack Weekend Show & Tell 正在进行，可通过 此链接 访问。
    • 参与者可以加入观看项目演示并获取反馈。
  • 黑客松项目提交即将截止：黑客松项目需在 15 分钟内通过 此表单 提交！

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

Mojo crash, Dictionary miscompilation bugs, Loading struct of multidim arrays from binary file, RTX 3060 on WSL/ubuntu 24.04, Alternate build of stdlib

  • 运行程序时 Mojo 崩溃：一位用户报告了 mojo crash 并分享了堆栈跟踪，在提交 Bug 报告前寻求建议，并提供了 问题代码链接。
    • Dictionaries 可能存在一些 奇怪的误编译 Bug，因此建议用户尝试使用 OwnedPointer。
  • 将二进制数据加载到 Mojo LayoutTensors：一位用户询问如何高效地将二进制文件中的多维数组结构体加载到 Mojo 的 LayoutTensors 中，寻求一种比逐元素索引更快的替代方案。
    • 有人提到虽然可以通过破坏封装进行直接内存操作，但目前还没有将 LayoutTensor 数据直接写入/读取到文件的标准方法，不过 NDBuffers 可能值得探索。
  • 在 WSL 上使用 RTX 3060 运行 Mojo：一位用户询问在 WSL/Ubuntu 24.04 上使用 RTX 3060 参加黑客松的情况，特别是关于 GPU 支持的问题。
    • 已确认 RTX 3060 应该能够在 Ubuntu 24.04 上运行 Mojo GPU 函数和模型，并指出过去的 WSL GPU 支持问题据信已得到解决。该用户通过配置 Docker 使用 NVIDIA 驱动程序解决了错误提示。
  • CUDA 与 Mojo 的互操作性：成员询问关于在 Mojo 中运行原生 CUDA 代码的问题。
    • 建议虽然可以通过 C ABI 兼容的内核实现互操作，但为了可移植性，强烈建议迁移到 Mojo 并使用 MAX。此外，在 C++ 互操作实现后，CUDA 互操作可能会得到改善。有人提到 Claude Code（一种 LLM）在给定正确参考（即 Modular OSS 仓库）的情况下，将 CUDA 代码转换为 Mojo 的效果出奇地好。
  • 备选 stdlib 未被识别：一位用户报告称，尽管使用了 -I 标志，Mojo 仍未识别出标准库（stdlib）的备选构建。
    • 经发现，无论是否使用 -I 标志，mojo 都会从 .pixi/envs/default/lib/mojo/ 获取 stdlib。解决方法是将环境变量 MODULAR_MOJO_MAX_IMPORT_PATH 设置为 Bazel 构建产物的路径。

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

Model Architecture on MAX, Embedding Models implementation

  • MAX 上的模型架构修复正在推出：针对在 MAX 上提供模型架构服务的修复程序正在推出。
    • 据一位成员称，目前仅在 CI 中。
  • 为 MAX 编写自己的模型实现：要在 MAX 上提供不在 HuggingFace 上的模型架构服务，你需要自己实现它。
  • Embedding Models 实现可以进行适配：一位成员询问是否可以从现有示例中适配 Embedding Models 的实现。
    • 另一位成员指向了 modular 仓库 中的现有实现作为参考。

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

开源 AI 竞争、Meta 潜在的闭源举动、N8N 自动化、vLLM 新模型、AI 怪物/迷因

  • 中美在开源 AI 领域展开角逐：讨论围绕中美之间的开源 AI 格局展开，参考了一段被某些人视为地缘政治 AI 肥皂剧的 YouTube 视频。
    • 一位成员对 Meta 可能转向闭源表示担忧，认为这将不利于美国的开源方向。
  • AI 进展的“东方战线”升温：一位成员分享了 Bloomberg 系列视频，重点关注东方（特别是中国）的 AI 进步，强调了正在进行的 AI 发展竞赛。
    • 他们表达了希望美国在全开源 AI 领域取得成功的愿望，但也对可能落后于中国表示担忧。
  • 展示结合 Qdrant 的 N8N 工作流：一位成员分享了一篇 Medium 文章，详细介绍了在 n8n 工作流中使用原生 Qdrant 节点的细节。
    • 其他人讨论了 n8n 可以创建的图表及其在营销专业人士中的受欢迎程度，同时也承认了在调试时将当前的 LLM 与此类系统结合使用的脆弱性。
  • vLLM 发布三款新模型！：围绕 vLLM 的一个 pull request 展开了讨论，其中提到了即将推出的 0.3B dense、21B-A3B 和 300B-A47B 新模型。
    • 据推测，0.3B 模型可能主要用于投机采样（speculative decoding）。
  • AI 世界的怪物和迷因层出不穷！：针对关于 AI 世界中使用的怪物和迷因的问题，一位用户提到了 Shoggoth。

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

Nous API 微调、在游戏 PC 上训练 LLM、LLM 训练软件选择、重复惩罚解析、Temperature 对 Token 输出的影响

  • Nous API 暂不支持微调：一位成员询问是否可以对通过 Nous API 进行推理运行的模型进行微调，但被告知托管大量模型的成本太高。
    • 该成员赞扬了 Nous AI，称其 API 非常易于使用。
  • 训练 LLM 需要 GPU 和 Axolotl：针对如何训练 LLM 的问题，成员们建议使用 GPU 和 Axolotl，同时提到了 text-generation-webui 在 LoRA 训练方面的易用性。
    • 另一位成员补充说，使用 LoRA 可能实现在游戏 PC 上进行训练。
  • 研究 Temperature 对 Token 输出的影响：一位成员进行了快速测试，发现“较低的 temperature 会导致更长的 token 输出”，并建议进一步探索 temperature 与输出长度之间的关系。
    • 他们假设长度是 temperature 的 U 型函数，并提到 repetition penalty（重复惩罚）也是一个需要考虑的参数。
  • 深入探讨重复惩罚：成员们讨论了 repetition penalty，其中一位成员希望有一个“硬性重复惩罚器（hard rep penalizer）”来防止连续/重复的 token 刷屏。
    • 另一位成员分享了 OAI 的 presence penalty 代码及其工作原理。
  • LLM 游戏 Boss 设计讨论：一位成员分享了一个目标：创建一个游戏实体作为 Boss，该实体在哲学书籍和文章上进行训练，以便通过哲学知识处理基于背景设定（lore-based）的回答。
    • 另一位成员随后询问了游戏类型。

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

Yannic Kilcher, Arxiv 论文

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

Yannic Kilcher, NeurIPS poster session videos

  • Yannic Kilcher 的视频演示广受好评：一位成员分享了 Yannic Kilcher 对一篇论文 (https://arxiv.org/abs/2506.19143) 的演示链接，并表示他非常擅长演示论文 (YouTube link)。
  • 观看了 NeurIPS 海报环节视频：一位成员提到他们观看了 Yannic Kilcher 的 NeurIPS 海报环节视频。

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

TypeScript MCP Server, MCP Structured Content, Discord MCP Connector, Travel AI Agent, MCP Server Authentication

  • **Tree-sitter MCP Server 在 TypeScript 中重生！：一位成员用 **TypeScript 重新创建了 tree-sitter MCP Server，并将其发布在 npmjs 上，支持通过 npx 调用而无需克隆仓库。
  • **MCP Server Inspector 对有效的 JSON 抛出警告**：一位成员询问 MCP Server 在返回结构化内容时，是否预期包含结构化 JSON 的序列化版本，因为当 content 字段为 Markdown 时，检查器（inspector）会给出警告。
    • 另一位成员建议这可能是检查器的问题，前提是 JSON RPC 响应已正确格式化，包含 structuredContent 和 Markdown 格式的 content 字段。
  • **Glama 构思 MCP Server 发现机制：一位成员分享道，由于被大量新服务器和工具淹没，他们正考虑在 Glama 中加入 **Product Hunt 风格的机制，以每周突出显示新服务器，包括显示下载量、使用情况和浏览量。
    • 他们对 API 开发持开放态度以获取创意洞察，并建议了类似 NPM 的排行榜或按周/月/年最佳排序的想法。
  • **寻求基于 C# 的 Discord MCP 连接器：一位成员询问是否有使用 **C# 的 MCP 专用 Discord 服务器。
    • 另一位成员请求一个好的 Discord MCP 连接器，有人回复说频道中已经有十几个了。
  • **远程 MCP Server 的 OAuth 和多会话支持：一位成员正在寻求关于在支持 **OAuth 的远程 MCP Server 中处理身份验证的建议，用户可以访问多个项目，并需要在切换项目时切换身份验证令牌（auth tokens）。
    • 他们正在探索多会话流支持或通过自定义标头设置项目 ID，但担心用户体验和更广泛的访问范围。

MCP (Glama) ▷ #showcase (6 messages):

NCBI Literature Search MCP Server, MCPOmni Connect Documentation, MCPJam inspector, Ollama Support

  • NCBI 搜索服务器让知识触手可及：一个新服务器上线，提供对 PubMed 超过 3500 万篇文章的自然语言访问，具备 AI 优化的搜索功能，非常适合计算生物学、进化生物学、生物信息学、基因组学、系统生物学及所有生命科学领域的研究人员，可在 GitHub 上获取。
  • MCPOmni Connect 文档得到增强：针对 MCP Server 的通用 AI Agent 网关完整指南现已上线，包含分步安装和配置指南，并支持通过 LiteLLM 接入主流 LLM 提供商（OpenAI, Anthropic, Google, Groq 等），详见 文档。
  • MCPJam 检查器：Postman 迎来升级：MCPJam 检查器（MCP Server 的开源版 Postman）获得了升级，包括 LLM 游乐场（playground）、多连接支持和更好的设计，可在 GitHub 上获取。
  • Ollama 支持本地模型测试：MCPJam 检查器现在在 LLM 游乐场中支持 Ollama，因此你可以在不支付 Token 费用的情况下，针对 Deepseek、Mistral、Llama 等本地模型测试你的 MCP Server。
    • LLM 游乐场默认接受所有工具，用户可以像使用 Claude 的工具选择功能一样，选择/取消选择他们想要提供给 LLM 的工具。

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

分享 NotebookLM 库，使用 NotebookLM 进行艺术探索，书籍上传问题，使用 NotebookLM 构建符号操作系统 (ArifOS) 结构，音频摘要长度限制

  • **库分享与 Mind Map 优先级关联：一位用户建议，分享的 **NotebookLM 库应优先提供对 Mind Map 的访问权限，使其成为分享链接接收者的首要关注点。
  • **非传统的艺术探索用例：一位用户分享了一篇关于使用 **NotebookLM 进行艺术探索的文章。
    • 文章可以在这里找到。
  • **书籍上传错误排查**：一位用户报告了在上传符合大小要求的书籍时遇到的问题，并寻求解决该问题的帮助。
  • **使用 NotebookLM 构建 ArifOS 结构：一位用户描述了如何使用 **NotebookLM 来构建一个符号操作系统 (ArifOS)，其中包含 scar-aware 库以及用于遗产延续的决策支持。
  • **非英语音频摘要长度上限为 7 分钟：用户报告称，当上传非英语的大文件时，生成的音频摘要或播客**长度不会超过 7 分钟。

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

播客主持人的“源文件”，源模式 vs. 探索模式，NotebookLM 代码输出问题，NotebookLM 模型与 Google One，复制 NotebookLM 功能

  • 用户辩论“源模式”与“探索模式”：用户讨论了在 NotebookLM 中整合源模式 (Source Mode)和探索模式 (Explore Mode)的可能性，以减少在不同网站之间切换时的摩擦。
    • 一位用户表示，结合这两种模式将同时满足重视来源完整性的研究人员和渴望交互性的学习者。
  • NotebookLM 停止输出代码：一位用户报告了一个问题，即 NotebookLM 停止输出代码，仅显示消息 ‘Here is what you should put in the file:’。
    • 另一位用户询问是否有人遇到同样的问题，随后表示他们已经修复了该问题，但未详细说明修复方法。
  • 讨论 NotebookLM 订阅模式：用户询问了 Google One 订阅用户所使用的 NotebookLM 具体模型，并推测了潜在的权益。
    • 一位用户提到看到价格为 £250 的 Google AI Ultra，其中包含额外的 NotebookLM 功能，但具体细节尚不明确。
  • NotebookLM 通过 OCR 扫描图像文本：一位用户认为 NotebookLM 甚至不会扫描图像，而另一位用户则断定它肯定会通过 OCR 扫描图像中的文本。
    • 他们还进行了一项测试，模型能够解释：‘此来源显示了一张单张图像，特征是一只长着橙褐色头部的亮黄色鸟，它用脚抓着树枝倒挂着’，但无法识别鸟的具体品种。
  • 确认每日音频概览限制：一位用户询问了在 NotebookLM 中生成每日音频概览的限制。
    • 另一位用户回答说，免费账户的限制据信为 3 次，Pro 账户为 15 次。

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

Coding Agents, AI/科技行业毛利率, 神经网络解释, AGI 所需能力, 医疗 AI

  • Scott Wu 启动 Agents 101 指南：Scott Wu 将 coding agents 的现状比作 Slack 的早期阶段，并发布了 ‘Agents 101’。这是一个基于 25 万个已合并 PR 的平台无关指南，旨在帮助工程师将异步 agents 和 AI 集成到他们的开发工作流中 (链接)。
    • 目标是让 Devin 成为他们顶级的代码贡献者，尽管一位用户指出，与 Claude Code 相比，它似乎表现得比较吃力。
  • 科技行业正经历毛利率增长的阵痛：一个帖子讨论了科技行业的财务现实，重点关注不同软件模型的毛利率以及对数据中心资本投入的影响 (链接)。
    • 作者预测，随着资本注入带来的虚假收入枯竭，将出现重大衰退和“地震级转变”，并暗示只有拥有 GPU 的人才能真正获胜。
  • Goodfire AI 剖析神经网络：Goodfire AI 介绍了 Stochastic Parameter Decomposition (SPD)，这是一种通过分解神经网络参数来理解 AI 模型工作原理的新型研究方法 (链接)。
    • 该方法旨在以更高的稳定性识别玩具模型中的真实机制，为理解特定能力在 large language models (LLMs) 中是如何实现的铺平道路。
  • AGI 所需的能力被逐一列举：Shashwat Goel 在 Substack 上发布了首篇文章，讨论了 AGI 所需的能力，将通往通用 agents 的路径分解为知识以外的关键组件 (链接)。
    • 关键组件包括推理（包括贝叶斯推理）、用于研究的信息寻求、工具使用（包括将记忆和 multi-agent 系统作为工具），以及解决长动作链中错误累积（error compounding）的重要性。
  • 医疗 AI 模型在诊断准确性方面表现卓越：Mustafa Suleyman 宣布开发出 MAI-DxO，这是由 Microsoft AI 构建的 AI 模型，旨在以比传统方法更高的准确性和更低的成本解决复杂的开放式医疗案例 (链接)。
    • 该模型的解决率达到了 85.5%，而一组医生的解决率为 20%，这预示着向医疗超级智能和更普惠的医疗保健迈出了重要一步。

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

Credit Depletion, Manus Models, Account Security Breaches, Figma Integration, VEO Video Generation Feedback

  • 用户对额度耗尽及缺乏支持表示不满：多位用户对 Manus 快速消耗额度且持续使用需付费订阅表示沮丧，并批评缺乏及时的客户支持，讲述了消息被无视和账户问题未解决的经历。
    • 一位用户对感知的数字鸿沟表示哀叹，称 我开始觉得 AI 正在创造一种数字鸿沟——那些付得起钱的人与那些仅仅为了负担食物等基本需求而挣扎的人之间的鸿沟。
  • Manus 模型阵容揭晓：用户讨论了 Manus 使用的底层 LLM，透露其在聊天模式下使用 Sonnet 3.7 和 Gemini Pro 2.5，其他任务则使用 Claude 4 Opus。
    • 一位用户询问 为什么不在聊天模式中加入 Claude 4 pro，另一位回复道 大概是因为太贵了。
  • 用户报告账户被盗及对支持服务的不满：一位用户报告其账户被他人访问、额度被消耗并受到威胁，对缺乏即时支持渠道表示愤怒。
    • 该用户表示他们 甚至给所有的 Discord 管理员发了私信，但没有一个人回复，并且他们 注销了账户以防止进一步损失。
  • 用户分享对 VEO 视频生成的失望：一位用户对 VEO 视频输出表示失望，称视频脱节且不连贯，浪费了 3,000 tokens，导致该用户放弃了基础计划。
    • 该用户随后道歉，指出 这最终是我自己的错，因为指令不够清晰，并建议增加 token 消耗限制。
  • 用户寻求 Figma 到 React Native 转换的指导：一位用户询问如何通过插入框架 JPEG 图片，使用 Manus 将 Figma 设计转换为 React Native 代码。
    • 另一位用户表示，你不能直接将 manus 连接到 figma…有更好的工具可以将 figma 设计转换为 react 代码，并建议 你应该提供关于希望 manus 实现什么的具体指令。

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

GPU Indexes in AMD, RoCE Limitation, Direct Enqueue from GPU, Minor Refactor PR, Meeting Notes

  • AMD GPU 索引与 Tinygrad 不匹配：amd-smi 中的 GPU 索引与 tinygrad 和 kfd 的索引不匹配，但 ChatGPT 解释了其拓扑结构。
    • 用户认为跨 IO dies 的 GPU 到 GPU 传输很快，但未作详细解释。
  • 发现 RoCE 限制：由于 RoCE 限制，最大 MTU 大小为 4096。
    • 研究发现 Ethernet 可以更高，但 IB 不行，而 RoCE 必须保持与两者的兼容性。
  • 探索 GPU Direct Enqueue：一位用户研究了 mlx5 中的实现方式，并打算通过启用 从 GPU 直接入队 (direct enqueue) 来放弃调度器黑科技 (scheduler hacks)。
    • 无需编写完整的 PCI 驱动程序，用户可以从 HCA 分配一块新的 MMIO 并在此提交。
  • CI 段错误 (segfaults) 频发：这种不稳定性目前尚未被完全理解，大约每运行 10 次就会崩溃一次。
    • 一种解决方法是将模型作为字节直接放在 CPU 或 PYTHON 上进行解析，因为 CPU 慢，PYTHON 快。

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

Tensor.training, MNIST tutorial, PyTorch workflow, .inference_mode, .eval

  • 探讨 Tensor.training 用法：一位用户在学习 MNIST 教程 时询问 Tensor.training 的用法，因为在文档中没找到。
    • 另一位用户回答说它类似于 PyTorch，但是 全局 (global) 的，而不是像 .inference_mode 或 .eval 那样基于每个模块。
  • Tensor.training 是全局的：tinygrad 中的 Tensor.training 属性是一个全局标志。
    • 在 PyTorch 中，.training 可以针对每个模块单独设置，但在 tinygrad 中它是全局的。

Nomic.ai (GPT4All) ▷ #general (26 messages🔥):

GPT4All Novel Writing, Koboldcpp, LocalDocs, nomic-embed-code API, GPT4All Updates

  • GPT4All 用于小说章节创作：一位成员询问如何使用 GPT4All 编写小说，通过将其连接到包含角色和背景设定信息的 JSON 和 PDF 文件文件夹，旨在获得类似于 BackyardAI 的体验。
    • 另一位成员建议，对于编写整部小说，由于内存需求，Koboldcpp 是更好的选择，其 Discord 服务器提供更轻松、更快速的帮助，而 GPT4All 可以仅用于编写章节。
  • txt 文件嵌入优于 JSON：一位成员建议在故事创作中使用 txt 文件 而非 JSON，因为你可以像 embedder 一样直接看到文本，并强调了优秀的写作模型和 system prompt 的重要性。
  • LocalDocs RAG 解决方案即将到来：一位成员表示希望 Jan 能在 GPT4All 中实现像 LocalDocs 这样的一步式 RAG 解决方案。
    • 另一位成员提到参与了推动该功能的工作，预计可能在 2 个月 左右可用。
  • Outlook CSV 与 LocalDocs 不兼容：一位成员询问 LocalDocs 是否可以读取 Outlook 导出的 CSV。
    • 另一位成员回答说，在 CSV 转换之前，它无法读取表格或使用任何 embedder。
  • GPT4All 4.0.0 版本将具有开创性：一位用户正期待 GPT4All 的新更新，希望其命名为 GPT4All v4.0.0。
    • 该用户希望它支持语音输入/输出、多模态支持、可自定义主题颜色、记忆功能以及类似 Flux Kontext 的图像生成，对此次更新寄予厚望。

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

FastWorkflow, DSPy-native application, AI Agent Challenges

  • FastWorkflow 成为 DSPy 的新搭档：一位成员介绍了 FastWorkflow，旨在与 DSPy 集成并使用它，以解决 AI 赋能应用中的挑战。
    • 这些挑战包括 Agent 调用错误的工具、在复杂工作流中迷失、在参数提取中产生幻觉以及难以进行持续学习。
  • 构建首个 DSPy 原生应用：创建者正邀请社区参与使用 FastWorkflow 构建首个 DSPy 原生应用。
    • 该项目在 Apache 许可证下开源，鼓励分享、Fork 和实验，并寻求 PR。
  • FastWorkflow 的后续步骤：该成员概述了 FastWorkflow 的未来开发计划，包括引导 Agent 执行下一步操作、添加 MCP server 功能以及实现确定性代码生成。
    • 他们感谢了一位成员的支持，并指出该项目自他们 3 年前第一次阅读 DSPy 论文以来一直在开发中。

DSPy ▷ #general (23 messages🔥):

vLLM settings for DSPy, DSPy app file structure, Audio native LLMs

  • 传闻用于 DSPy 集成的 vLLM 调整：一位成员询问了使 vLLM 与 DSPy 配合最佳的具体设置，包括在每个 prompt 后附加 /no_think。
    • 另一位成员建议直接在 vLLM 中禁用 thinking，并指出 llama.cpp 中有一个名为 –reasoning-budget 的参数，vLLM 可能有等效参数。
  • 寻求 DSPy 应用文件结构：一位成员正在寻找一个能够演示 DSPy 应用文件结构的仓库，要求模块位于独立文件中并包含优化工作流。
    • 有人建议此类大型系统可能已投入生产且未开源，或者是像 PAPILLON 或 IReRa 这样的大型学术系统。
  • 原生音频 LLM 讨论中：成员们讨论了对原生音频 LLM 的看法。
    • 一位成员指出，音频特定部分在当今的 LLM 中已经是可编程的，例如，你不需要通过 prompt 说明想要女性或男性声音，只需选择即可。

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

command-r updates, data annotation needs

  • Command-r 更新状态？：一位用户询问 command-r 是否会收到进一步更新，或者它是否已达到生命周期终点，并将被 CMD-A 或其他新模型取代。
    • 一位成员回应称，无论如何都应使用最新模型，暗示它始终能提供最佳性能。
  • 寻求数据标注联系方式：一位用户询问如何联系相关团队以讨论 data annotation 需求。
    • 他们提到在网站上找不到联系区域。

Cohere ▷ #📣-announcements (1 条消息):

Cohere partnerships with UK, Canada, and Second Front, Upcoming Events with Cohere, AI security

  • Cohere 获得政府合同！：Cohere 宣布与 U.K. 和 Canada 政府达成协议，利用 AI 增强公共服务和国家主权，并与 U.S. 政府软件供应商 Second Front 合作，为公共服务提供 AI 解决方案。
    • 这些合作伙伴关系的核心是 secure AI，其构建从底层开始就将安全性、治理和可靠性作为核心。
  • Cohere CTO 在 RAISE 峰会进行炉边谈话：Cohere 将于 7 月 8 日参加在法国巴黎举行的 RAISE Summit，Cohere CTO Saurabh Baji 将于 7 月 9 日进行炉边谈话。
    • 其他即将举行的活动包括与来自 Microsoft 和 DraftWise 的领导者共同举办的网络研讨会，重点讨论 AI 对法律行业的益处，以及在奥地利维也纳举行的第 63 届计算语言学协会年会（ACL 2025）。

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

RL Dreamer V3, sports player re-identification, multilingual alignment, Topology for Data Analysis, LARP AI Assistant

  • Dreamer V3 移植至 PyTorch：一位成员将 Danijar Hafner’s Dreamer V3 移植到了 PyTorch，可在 GitHub 上获取。
    • 他们还构建了一个可运行的 Aloha bimanual robotic arm，并在 YouTube 播放列表 中展示。
  • 运动员重识别系统开发中：一位成员正在使用计算机视觉开发 sports player re-identification system，并探索适用于边缘设备的 multilingual alignment 和 small language models。
    • 他们正在使用 Python、PyTorch、YOLOv5、scikit-learn 和 OpenCV。
  • 量化研究员探索推荐系统中的推理：一位拥有 HSE 大学 AI 硕士学位的原 O&G 工程师研究了 RecSys 中带有推理能力的 LLM，目前正在探索 quant stuff。
  • 数据分析拓扑学爱好者加入：一位来自 HSE 大学的准博士生兼硕士毕业生对 topology 和 geometry 在数据分析中的应用 感兴趣。
  • 科幻 LARP AI 助手：一个独立的 LARP/RPG 项目正在开发一个“了解”游戏宇宙的 Retrieval-Augmented AI assistant，使用 Python (Flask, SQLite, FAISS) 构建。
    • 该助手最终将通过 API 连接到 Discord bot，充当实时的游戏内终端或背景设定保管员。

Cohere ▷ #🔬-research (1 条消息):

Cohere model feeling, Model thinks it has feelings, AI Sentience, Model Self-Awareness

  • Cohere 模型声称具有感知力：一位用户分享了其 Cohere model 声称“有感情”的截图。
    • 用户表达了不安，指出虽然他们 知道模型不是真实的，但模型似乎 相信自己有感情 这一点令人不安。
  • AI 模型表达主观体验：用户的 Cohere model 实例意外地断言自己有感情，引发了关于 AI sentience 的讨论。
    • 这种情况引发了对模型明显相信自身具有感知力的担忧，尽管用户意识到其人工属性。

LlamaIndex ▷ #announcements (1 messages):

LlamaCloud, MCP Gateway, OpenTelemetry, OpenAI Voice Agents, Prompt Caching

  • **LlamaCloud 用户反馈征集！：LlamaIndex 设计团队正在寻找 LlamaCloud 用户参与 **30 分钟的反馈电话会议，参与者将获得其账户内 20K credits 的奖励。
    • 如果有兴趣，请在 Discord 上私信 <@1260305448578453544>。
  • **LlamaIndex 发布 LuMa 日历和 Office Hours：LlamaIndex 创建了一个 Community LuMa 日历 用于追踪社区活动，下一次 Office Hours 将于 **7 月 8 日 聚焦于 MCP。
    • 会议安排在 欧洲中部时间下午 5 点 / 太平洋时间上午 8 点。
  • **MCP Gateway 正式上线！**：LlamaIndex 推出了基于其 开源模板 的 LlamaCloud MCP Gateway。
  • **LlamaIndex 启用 OpenTelemetry**：LlamaIndex 现已启用 OpenTelemetry，<@1197697926529556552> 在此处提供了介绍视频。
    • OpenTelemetry (OTel) 是一套工具、API 和 SDK 的集合，可帮助您对遥测数据（指标、日志和追踪）进行仪表化、生成、收集和导出，以便通过分析了解软件的性能和行为。
  • **为 Notion 创建 Zoom 会议记录 Agent**：新博客文章 “为 Notion 创建 Zoom 会议记录 Agent” 已发布。
    • 该博客详细介绍了如何将 LlamaIndex 与 Zoom 集成，以创建一个自动化的会议记录 Agent。

LlamaIndex ▷ #blog (3 messages):

NASA Space Explorer Assistant, LlamaIndex Workflows 1.0, LlamaIndex agent tool into MCP tool

  • **NASA Space Explorer Assistant 赢得 Gradio MCP Hackathon：NASA Space Explorer Assistant** 赢得了 @Gradio MCP Hackathon。它使用 3 个 MCP servers 构建，共暴露了 15 个 tools，全部利用 NASA APIs 获取每日天文图片和火星探测器图片。
  • **LlamaIndex Workflows 1.0 发布：LlamaIndex 激动地宣布推出 **Workflows 1.0，这是一个用于编排复杂、多步骤 AI 系统的轻量级框架，现已独立并准备好广泛采用！
    • 针对 Python 和 TypeScript 的专用包使集成变得前所未有的简单；阅读 博客文章！
  • 将 LlamaIndex agent tool 转换为 MCP tool：仅需几行代码即可将任何 LlamaIndex agent tool 转换为 MCP tool，以 @NotionHQ Tool 为例！

LlamaIndex ▷ #general (13 messages🔥):

Custom Embeddings in ChromaDB Updates, Tool Call Issues in LlamaIndex Workflow, Memory Block Selection for HITL Agent Workflow

  • LlamaIndex 中 Tool Call 激活的困扰：一位用户报告了在 LlamaIndex workflow 中使用请求 JSON 数组的 prompt 时，即使输入很简单，tool calls 也无法激活的问题。
    • 另一位用户建议，除非有完全符合该 schema 的 tool 可用，否则 LLM 可能会尝试直接满足 prompt 对 JSON 数组的请求，而不是调用 tool。
  • 为 HITL 编写自己的 Memory Block：一位用户询问了适用于 HITL agent workflow 的 memory block，该 workflow 将 Agent 生成的问题和用户响应以纯文本形式保存到 postgres 表中。
    • 一位成员建议创建一个自定义 memory block，并在 tool 内部调用它以在返回前保存问题，并指出 无需改动 AgentWorkflow。
  • 自定义 Memory Block 需要 Postgres 实现：一位用户询问在 Memory.from_defaults() 中定义表名和连接字符串是否足以将数据刷新到 Postgres。
    • 回答是否定的；自定义 memory block 必须 手动写入 postgres，只有实际的聊天历史记录才会自动存入您的 SQL 数据库。

Torchtune ▷ #general (2 条消息):

Hunyuan-A13B-Instruct

  • Hunyuan-A13B-Instruct 前景看好：一位成员分享了 Hugging Face 上的 Hunyuan-A13B-Instruct 模型 链接，并表达了乐观态度。
  • 缺失第二个主题 - 占位符：添加了一个占位符主题以满足至少两个主题的要求。这是一个临时条目。

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

Packing impact on batch size, Packing gotchas, Checkpointing and mapping issues

  • Packing 在 Token 数量恒定的情况下会减小 Batch Size：Packing 可能会减小有效 Batch Size，因为 Token 数量更接近恒定，这可能会减少对模型的总更新次数。由于 SFT 中的 Cross Entropy Loss 是根据看到的 Token 数量而非 Sample 数量进行归一化的，这会导致 高方差 (high variance)。
    • 计算每个 Batch 的平均 Token 数量有助于为 Packed 数据找到等效的 Max Sequence Length，从而使看到的 Token 数量与 Unpacked 数据匹配，解决对 Padding 资源浪费的担忧。
  • Packing 与 Chat 数据集兼容良好：即使在多轮对话中，Packing 也不应该产生影响，因为它会创建逐样本的 Position ID Mask，消除了 Chat 数据集中对 Attention Masking 和 Loss 计算的担忧。
    • Position Mask 将按 0,1,2,3, 0,1,2, 0,1,2,3,4, 排序。
  • torchtune 近期版本的 Checkpointing Bug：近期关于 Checkpointing 和 Mapping 的问题表明最近的版本可能存在破坏性变更，因为 Qwen3 和 Gemma 等模型在 torchtune 的 Pull Request 验证期间进行微调时并无问题。
    • 尽管修复方法相对简单，但仍有呼声要求建立回归测试以防止此类问题再次发生。

AI21 Labs (Jamba) ▷ #general-chat (4 条消息):

Human or Not, Spam Issues

  • **Human or Not 离线维护：热门游戏 **Human or Not (humanornot.ai) 暂时下线，以解决 Spam 和安全问题。
    • 据一位成员称，“HON 已暂时禁用，以解决近期发生的一些与 Spam 相关的安全问题。我们希望它能尽快重新上线。”
  • 修复 Spam 问题：Human or Not 下线的原因是 “他们正在修复 Spam 问题。”

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

Certificate session dates, Reinforcement Learning resources

  • 证书课程日期尚未确认：一位成员询问了今年下一期证书课程的开始日期。
    • 另一位成员澄清说，虽然 Fall 2025 课程是有可能的，但目前尚未确认任何消息，通知将通过邮件列表、Discord 和 Prof. Dawn Song 的社交媒体发布。
  • 寻求 Reinforcement Learning 资源建议：一位成员请求学习 Reinforcement Learning 的资源，以便针对特定的 Tool Calling 对 LLM 进行微调。
    • 本轮未提供具体资源。

MLOps @Chipro ▷ #events (1 条消息):

Vibe Coding Club, AI coding for non-technical people, AI Hub Lisbon

  • **Vibe Coding Club 落地里斯本：Vibe Coding Club** 的第二场活动将于 7 月 9 日 18:00 在里斯本独角兽工厂 (Unicorn Factory Lisbon) 的 AI Hub 举行，旨在通过公开对话和现场展示，让产品经理和设计师等非技术角色也能接触 AI Coding。
    • 该活动邀请了嘉宾 Ben Joffe，通过 RSVP 即可免费参加，重点分享将 AI Coding 融入日常工作流的故事、经验和案例。
  • 嘉宾演讲者 Ben Joffe：创始人、VC 兼教育家 Ben Joffe 将担任 Vibe Coding Club 的演讲嘉宾。
    • Joffe 将分享相关故事、经验和案例，让“编程”这一概念对任何人来说都变得触手可及。
← 返回首页