AI News

今天没发生什么事。

· MjAyNS0w

伊利亚·苏茨克维尔 (Ilya Sutskever) 确认担任 Safe Superintelligence Inc. (SSI) 的首席执行官，丹尼尔·利维 (Daniel Levy) 担任总裁；他驳斥了收购传闻，并强调了公司强大的团队和算力资源。Perplexity AI 通过引入晨星公司 (Morningstar) 的财务研究报告扩展了其数据集成，并暗示将为 Pro 用户推出新产品功能。Meta AI FAIR 明确了其研究结构，将其小型实验室与大型模型训练团队区分开来，并欢迎 Nat Friedman 加入以加强 AI 产品开发。Midjourney 和 Sakana AI 宣布招聘研究和应用工程人员。Cohere 扩大了在蒙特利尔的业务，获得了加拿大官员的赞赏。在模型方面，Google DeepMind 的 Gemini Pro 在全球发布了 Veo 3 视频生成模型。DeepSeek 推出了速度更快的 DeepSeek R1T2 模型，该模型采用“专家汇编”（Assembly of Experts）架构，并基于 MIT 许可证开源。可灵 (Kling AI) 展示了电影级的视频生成能力。OpenAI 推出了高成本的 Deep Research API，单次调用价格高达 30 美元。Together AI 宣布发布 DeepSWE 智能体。

#video-generation #assembly-of-experts #model-licenses #api-pricing #research-roles #product-expansion #corporate-leadership #model-release #team-expansion veo-3 deepseek-r1t2 deepseek-tng-r1t2-chimera o3-deep-research o4-mini-deep-research deepswe-agent safe-superintelligence-inc perplexity-ai meta-ai-fair midjourney sakana-ai cohere google-deepmind deepseek openai together-ai

平静的一天。

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

除非 7 月 4 日发布 Grok 4 的传闻成真，否则我们明天也将放假。

AI Twitter 回顾

公司与领导层新闻

模型发布与研究更新

  • Gemini 的 Veo 3 视频模型全球上线：@demishassabis 宣布 Google 最先进的视频生成模型 Veo 3 现已面向全球所有 Gemini Pro 用户开放。该公告被广泛转发，并强调了访问权限的扩大，包括欧洲地区。
  • DeepSeek 发布更快、更强大的模型：@reach_vb 宣布了 DeepSeek R1T2，据报道其速度比前代快 200%，并在 GPQA 和 AIME 24 等基准测试中表现出显著提升。该模型采用 Assembly of Experts 方法创建，并在 Hugging Face 上以 MIT license 发布。此外，还发布了一个变体 DeepSeek-TNG R1T2 Chimera。
  • 可灵 AI (Kling AI) 展示电影级视频生成：视频生成初创公司 @Kling_ai 发布了一部极具电影感的短片，讲述了一个每天在不同身体中醒来的父亲的故事，展示了先进的叙事和视觉能力。
  • OpenAI 推出高成本 Deep Research API：来自 @ArtificialAnlys 的最新分析详细介绍了 OpenAI 新的 Deep Research API endpoints，其每次调用成本最高可达 $30。o3-deep-research 的定价为 $40/M output tokens，而 o4-mini-deep-research 为 $8/M output tokens，均显著高于其标准版本。
  • Together AI 发布 DeepSWE Agent：@togethercompute 宣布了 DeepSWE，这是一个最先进的软件工程 Agent，在 Qwen3-32B 基础上通过 Reinforcement Learning 训练而成。其训练工具包和方法论已完全开源。
  • Kyutai 发布新型开源文本转语音模型：@ClementDelangue 分享了 Kyutai TTS 和 Unmute 的发布，它们被描述为自然、可定制且快速，能够在单个 GPU 上同时为 32 个用户提供服务。

AI 工程、框架与工具

  • “Context Engineering” 成为关键学科：该术语获得了显著关注，@_philschmid 将其定义为“设计和构建动态系统，提供正确的信息和工具……为 LLM 提供完成任务所需的一切。” LlamaIndex 的 Jerry Liu 强调 workflow engineering 是一个核心组件，专注于为 Agent 创建可重复的多步骤流程。该术语发起者的演讲得到了 @swyx 的推荐，一篇将该概念分解为 Knowledge Base Selection、Context Compression、Long-term Memory 和 Workflow Engineering 的博客文章也受到了高度推荐。
  • 将长期记忆集成到 Gemini 2.5：来自 @_philschmid 的新指南演示了如何使用 mem0.ai 将长期记忆与 Gemini 2.5 集成，以构建能够记住过去对话的更具个性化的 AI 应用。
  • 开发者辩论 AI 编程范式：@AravSrinivas 发起的一项让开发者在 Claude Code 和 Cursor 之间做出选择的投票引发了讨论。这反映了更广泛的战略分歧，一位用户观察到 Cursor 押注于人类主导的编程，Anthropic 押注于 human-in-the-loop agents，而 OpenAI 则押注于“agent 纯粹主义者”。
  • 关于 LangGraph 架构的讨论：LangChain 的 Harrison Chase @hwchase17 询问开发者是否有兴趣使用驱动 LangGraph 的底层事件驱动框架，而不仅仅是高层 Agent 抽象。
  • 基础设施转型的痛点：开发者 @StasBekman 将从 SLURM 到 Kubernetes (K8s) 的转型描述为“非常痛苦”，理由是 B200 AWS 节点上的 K8s 处理 OOM 错误的方式是直接杀死作业分配，导致调试困难。

硬件、基础设施与效率

  • 未来 AI 的巨大电力需求：来自 @scaling01 的帖子透视了未来 AI 基础设施的规模，指出 OpenAI 计划中的 Stargate 数据中心 预计将消耗约 5 GW 的电力，相当于 约 430 万户美国普通家庭 的用电量。
  • 半导体行业概览：@dylan522p 分享的一张幻灯片全面展示了半导体行业的多个层级。
  • NVIDIA GB300 NVL72 开始部署：云服务提供商 CoreWeave 宣布其是首家上线 NVIDIA GB300 NVL72 的公司，这是一个用于 AI 训练和推理的强大新平台。据报道，这些系统目前正在交付中。
  • 推理优化与供应商竞争：分析师 @dylan522p 观察到，第三方供应商现在提供的 Deepseek 模型 服务比 Deepseek 官方 API 具有更低的延迟和更高的效率，导致推理流量发生了转移。

“Soham Parekh” 事件与科技招聘文化

  • 申请人涉嫌大规模投递方案走红：一个主要的讨论话题是 Soham Parekh，此人涉嫌用一份可疑的简历向数千家 AI 初创公司投递申请。来自 @Yuchenj_UW 的详细分析指出了诸多疑点，例如其 GitHub 账号名为 “satya-nutella”，一名没有任何在职记录的 MBA 学生却声称拥有 4 家 AI 初创公司的工作经验，且“没有值得关注的仓库”。
  • 多家公司确认收到该申请：包括 Replit 在内的多家业内初创公司确认他们收到并拒绝了该申请。来自 Replit 的 @pirroh 表示：“我们不根据资历招聘。Replit 的门槛就是这么高。” 这一情况演变成了一个梗，一位创始人开玩笑说，如果 Soham 没有投递你的初创公司，“那你就不是一家严肃的初创公司。”
  • 对科技文化的广泛评论：该事件引发了对科技行业招聘和伦理的广泛反思。@teortaxesTex 表达了担忧，认为“这种欢快的 Soham 式行为和‘凡事皆作弊’的氛围可能会以糟糕的结局收场”，并质疑 VC 圈还剩多少信任。该事件还引发了恶搞，包括一份名为“Project Soham”的虚假 Anthropic 研究论文。

更广泛的影响与幽默

  • 重新思考未来与工作的本质：在一条广为流传的推文中，@fchollet 反思道：“我们现在距离 2100 年比距离 1950 年更近……是时候开始像那样行事了。” 这种情绪在关于 AI 对职业影响的讨论中得到了回响，@simonw 提出了一个流行的类比，将现在放弃编程比作“因为电钻的发明而放弃木工职业”。
  • 美国预算讨论与科技乐观主义的交汇：@zacharynado 转发的一份 CATO 分析发现，一项新的共和党税收法案将使国债增加超过 6 万亿美元。这引发了 @willdepue 对政治情绪的评论，即“赤字是假的，奇点即将到来”。
  • 梗与幽默：@jxmnop 关于一篇新论文错失将其模型命名为 5TPG（致敬 3GPP 标准）机会的笑话引起了技术受众的共鸣。在一篇讽刺帖子中，@vikhyatk 声称他从 Microsoft 被裁员，原因是他曾是“负责将开始菜单迁移为 React 应用的主管工程师”。另一条热门推文来自 Cohere 联合创始人 @aidangomez，他简单地发了一句 “Stay Canadamaxxing 🍁”。

AI Reddit 综述

/r/LocalLlama + /r/localLLM 综述

1. Kyutai 与 DeepSWE：新开源 AI 模型发布与基准测试

  • Kyutai TTS 发布：实时、语音克隆、超低延迟 TTS，稳健的长文本生成 (Score: 123, Comments: 38): Kyutai 发布了一个开源 TTS 模型 (GitHub, HuggingFace)，具有实时、超低延迟的语音合成功能（首个音频延迟约为 220ms）、用于实时交互的增量文本处理，以及在长文本内容（>30s）上的稳健表现。仅需 10 秒的输入即可开启语音克隆，但出于授权合规原因，官方未开放对扬声器嵌入（speaker embedding）模型的直接访问；仅发布了一个经过筛选的捐赠/数据集语音库。 关于保留语音嵌入模型的做法存在争议，一些用户对这些安全措施感到沮丧，认为这是不必要的“审查”。技术反馈指出偶尔会出现发音错误（例如将 ‘Live’ 读成 ‘Leeve’，将 ‘my’ 读成 ‘me’，以及不寻常的停顿），但共识是该模型值得进一步探索。
    • Kyutai TTS 限制了其语音嵌入模型的直接发布，以防止未经授权的语音克隆；相反，他们只允许从 Expresso 和 VCTK 等预先筛选的数据集中选择语音。这种架构牺牲了通用的克隆灵活性，以换取更好的授权合规性，但因限制了开源模型的实用性而受到批评——这与 OSS 中日益增加的 AI 模型“审查”现象如出一辙。
    • 用户已经发现了语音生成质量的问题，提到了发音错误（例如 ‘Live’ 渲染为 ‘Leeve’，’my’ 渲染为 ‘me’）和不自然的停顿，这表明存在持续的句法和韵律错误，影响了模型的感知流畅度以及在长文本转语音应用中的适用性。
    • Kyutai TTS 目前缺乏德语语音，这凸显了其基于库的方法在语言和语音多样性方面的局限性，该方法受限于其筛选数据集贡献的广度和多样性。
  • [**DeepSWE-Preview 在 SWE-Bench-Verified 上通过测试时缩放达到 59.0%](https://huggingface.co/agentica-org/DeepSWE-Preview) (Score: 113, Comments: 13): **DeepSWE-Preview 是一个开源的、经过 RL 训练的编程 Agent，基于 Qwen3-32B，针对复杂的软件工程任务（包括多文件编辑）进行了优化，并在 SWE-Bench-Verified 上进行了评估，获得了 SOTA 结果（59% hybrid best@16；Pass@1: 42.2%，16 次运行的平均值）。该 Agent 使用了一个自定义的后训练 RL 框架 (rLLM)，包含精心筛选的数据集（4.5k 个 R2E-Gym 问题）、稀疏结果奖励，以及融合了 DAPO、Dr. GRPO、LOOP/RLOO 元素以及创新过滤和熵归一化的专门 RL 方案。所有组件——数据集、代码、训练/评估日志——均在 MIT 协议下完全开源；推理针对 vLLM 上的高吞吐量进行了优化。 技术讨论包括对基准测试可信度的怀疑、与其他模型（Qwen3-finetune, Devstral-Small-2505, R1）的比较，以及对用户专业化后训练可能性作为编程 Agent 未来方向的积极评价。
    • 评论者强调了真正的开源对于 LLM 的 RL 进展的重要性，指出权重、数据集和日志的全面可用性，使得与以往经常保留关键组件的发布相比，能够实现更广泛的基准测试和可复现性。
    • 存在对声称的 SWE-Bench 性能的技术怀疑：用户指出，作为 Qwen3 微调版的 DeepSWE 在经过极少的 RL 步骤后仅略微优于 R1，并且在某些设置下被 Devstral-Small-2505 超越——这让人质疑这些基准测试对于现实世界代码推理任务的代表性和实际价值。
    • 关于该框架在持续学习和用户特定学习方面的潜力讨论强调，rLLM 的后训练（在线或基于 RL）适配可以实现高度个性化的 LLM Agent，特别是如果存在足够的算力来支持用户级的微调和迭代改进。
  • 这些新模型没人爱吗？ (Score: 183, Comments: 63): 该帖子讨论了社区对近期开源模型（Dots、Minimax、Hunyuan 和 Ernie）缺乏热情的原因，相比之下 Qwen 和 DeepSeek 更受欢迎，并强调了采用这些模型的主要障碍。技术评论者将其归因于这些新模型在流行的本地推理引擎（特别是 llama.cpp 和 VLLM）中缺乏支持，且通常针对企业级 GPU 和基础设施而非消费级硬件。虽然存在变通方案（例如使用 FastDeploy 运行 Ernie，或通过 Unsloth 的 HuggingFace 使用 Dots 的 GGUF），但缺乏主流兼容性阻碍了更广泛的测试和使用。 技术共识认为，本地环境中的实际可用性对于广泛的社区参与至关重要；用户还表示偏好可以轻松切换模型并使用熟悉提示词进行基准测试的工作流，如果新模型表现不佳或难以运行，通常会退回到更易获取的模型。
    • 几位评论者指出，这些新模型被采用的主要障碍是缺乏 llama.cpp 和 VLLM 等流行推理引擎的支持，强调许多替代引擎针对的是企业级硬件（例如多 GPU、快速互连），对消费级 GPU 并不实用。文中提到了部分变通方法——例如使用 FastDeploy 运行 Ernie 模型或通过 Unsloth 使用 Dots 的 GGUF——但这些方法并不普及。
    • 性能对比讨论指出，据报道 Ernie 300B-47B 模型优于 Maverick，但逊于 DeepSeek-V3-0324；Minimax 较大的上下文窗口（80k）并不能弥补其“浅层”推理能力的不足，其推理能力被认为弱于 Qwen3-235b。用户反馈认为 DeepSeek 和 Qwen 模型在推理和理解方面明显优于大多数其他选择。
    • 文中提到了 GGUF 模型格式可用性的重要性，用户在测试新模型之前会积极等待 GGUF 和官方支持的合并。Qwen 团队的发布时机（等待补丁合并）被引用为与生态系统工具链协调以确保可访问性的正面案例。

2. 在消费级硬件上运行和实验大语言模型

  • 我简直不敢相信它真的能跑起来 - Qwen 235b @ 16GB VRAM (评分: 179, 评论: 86): 楼主成功在配备 96GB DDR5 RAM 和 16GB VRAM RTX 4080 Super 的消费级系统上运行了 Qwen 235B 模型（Unsloth 的 Q2XL GGUF 量化版本）。 使用了 llama-cli，关键参数包括用于近乎全 GPU 卸载（offload）的 ngl 99 以及 32k 上下文窗口。基准测试结果显示生成速度为 8t/s，初始 VRAM 占用为 11.1GB，在进一步优化 VRAM 后提升至 9.8t/s（详见编辑/线程）。运行指标：Prompt 评估速度为 8.02 tok/s，生成速度为 5.44 tok/s（单核测量值为 183.67ms/token）。评论中的技术讨论较少，一位用户表达了对 RAM 的羡慕（更倾向于 96GB 以支持更大的模型/上下文），但没有关于模型量化权衡、瓶颈或进一步卸载策略的深入辩论。
    • 一位用户报告在配备 96GB DDR5 RAM 和 24GB VRAM 的系统上成功使用 Qwen3 235b q3_K_M 进行推理，生成速度约为 4 tokens/second。这表明在更易获取的高端消费级硬件上运行大型量化 LLM 是可行的。
  • 为 PS Vita 制作了一个 LLM 客户端 (评分: 128, 评论: 7): 该帖子描述了一个项目，用户将 llama2.c 移植到 PS Vita 上进行设备端推理（使用 TinyStories 260K 和 15M 检查点），在发现其不切实际后，为 PS Vita 创建了一个名为 ‘vela’ 的新 LLM 客户端应用。该客户端支持通过可配置的 LLM 端点进行远程推理，包括具有视觉功能的模型；内置的 Vita 摄像头可以为支持视觉的模型拍摄图像。该应用处理具有格式特性（如 TeX/Markdown 显示）的模型输出，但指出了硬件限制（例如不支持表情符号）。源代码和下载可在 GitHub 上获得。 评论没有提供显著的技术辩论，但对在 Vita 手持设备上使用 LLM 的人体工程学限制和新颖界面表示了兴趣和好奇。
    • 没有讨论实现细节、模型基准测试、性能或在 PS Vita 上运行 LLM 客户端的技术障碍的实质性技术评论。所有顶级评论都停留在表面或一般的赞扬，缺乏深度的技术见解。

3. 本地优先的 AI 应用和框架发布

  • PrivateScribe.ai - 一个完全本地化、基于 MIT 许可证的 AI 转录平台 (评分: 127, 评论: 40): PrivateScribe.ai 是一个完全本地化的开源 AI 转录平台，专为医疗和法律领域等隐私敏感的使用场景设计。它使用 React, Flask, Ollama 和 OpenAI 的 Whisper 构建，提供可定制的转录模板和仅限本地的音频处理（无云端集成）。该平台采用 MIT 许可证，支持自托管，并兼容现成模型以及微调/自定义模型（详见 PrivateScribe.ai）。 热门评论提出了关于直接运行 Whisper 的技术优势问题，讨论了替代方案（如 Hyprnote, Vibe），并辩论了网络架构，建议支持私有网络内的客户端-服务器拓扑，而不是严格限制在 127.0.0.1。
    • 一位技术用户询问 PrivateScribe.ai 相比直接在本地运行 Whisper 有哪些功能或架构上的优势，暗示需要澄清 PrivateScribe.ai 是否在 UI、批处理、用户管理等方面提供了显著价值，而不仅仅是 Whisper 的封装。
    • 一位评论者建议为 PrivateScribe.ai 采用更灵活的网络架构，主张采用本地客户端-服务器模式（例如，服务器运行在工作站上，客户端通过私有 WiFi 运行在智能手机上），而不是限制在 127.0.0.1。这将能够在保留数据本地化和隐私的同时，利用更强大的硬件进行转录，这在移动笔记并实时同步到安全本地服务器等工作流场景中至关重要。
  • 针对 PrivateScribe.ai 在不同硬件（尤其是旧设备或低性能设备）上的可扩展性和效率存在技术担忧。另一个问题是在可靠性和安全性至关重要的开源临床背景下，如何管理软件更新和错误修复。
  • 一项将 CUDA 引入非 Nvidia GPU 的项目正在取得重大进展 (Score: 338, Comments: 47)：一个名为 ZLUDA 的项目旨在通过重新实现关键组件，在非 Nvidia GPU 上实现 CUDA 级别的加速，从而允许现有的 CUDA 二进制文件在其他硬件上运行。尽管人力极其有限（仅有两名开发人员），但该项目声称取得了实质性的技术进展，不过扩展和保持功能对等仍是一个挑战。值得注意的是，过去实现 CUDA 兼容性的努力曾面临法律和供应商政治障碍——例如，之前的 CUDA-on-other-GPU 实现因 Nvidia 的诉讼而停止，并且由于与 Oracle v. Google Java (API) 诉讼案类似，存在法律风险；因此，AMD 等公司可能对支持或集成此类技术栈持犹豫态度。 评论强调了对该项目在资源有限情况下的可持续性和时间表的怀疑，并讨论了知识产权诉讼对开源硬件和软件创新的寒蝉效应。技术界也对 ROCm 等替代方案表现出兴趣，并密切关注用于异构计算的新兴语言，如 Mojo。
    • ZLUDA 主要由一名独立开发者开发（最近有另一名加入），这表明与加速器公司中典型的庞大团队相比，其资源非常受限。尽管有这些限制，进展依然显著，但除非出现新的突破（例如 LLM 驱动的固件开发），否则实质性的重大突破可能不会很快到来。Tinygrad 被提及为该领域的另一个技术栈，且资金相对充足。
    • 讨论强调了公司支持 CUDA 兼容运行时的法律风险：引用了 Oracle 起诉 Google Java 兼容性的先例作为前车之鉴，暗示如果 AMD 发布 CUDA 兼容的运行时，可能会面临来自 Nvidia 的类似诉讼。尽管存在这些风险，但 ROCm 等替代方案被认为正在取得进展，ROCm 的第一个主要 Windows 版本预计将于 8 月发布。Mojo 编程语言也被强调为一项潜在的重要进展，特别是如果它完全开源的话。
    • HIP 是来自 AMD ROCm 技术栈的开源 CUDA API 克隆，被认为是一个法律上更安全的跨平台兼容替代方案，允许开发者同时针对 AMD 和 Nvidia 硬件进行开发。HIP API 有助于避免与直接模拟 CUDA 相关的潜在法律问题，但对于遗留或未维护的依赖 CUDA 的软件，ZLUDA 等项目仍具有重要价值。有关技术细节，请参阅 HIP 文档。

较低技术门槛的 AI Subreddit 综述

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

1. 新兴模型与 TTS/Avatar 技术发布

  • Kyutai TTS 发布：实时、语音克隆、超低延迟 TTS，强大的长文本生成 (Score: 145, Comments: 51)：Kyutai 发布了一个开源的实时 TTS 模型（GitHub，HuggingFace），能够在约 220ms 内开始音频输出，支持真正的流式文本转语音——即使在动态提供新文本时也无需完整的 Prompt。该模型能够处理强大的长文本合成，并声称可以为远超传统 30 秒限制的片段生成连贯的语音，并提供据称仅需 10 秒语音即可完成的语音克隆，不过出于合规原因，直接的语音嵌入模型访问权限被保留。 热门技术评论强调，承诺的 10 秒语音克隆对公共用户不可用，因为 Kyutai 限制了对语音嵌入模型的访问以防止未经授权的使用——这与允许更广泛语音克隆的 Chatterbox 等工具形成对比。

  • 语音克隆功能受到限制：与其他一些 TTS 系统不同，Kyutai 不公开其语音嵌入模型。这一措施旨在确保语音克隆仅在获得同意的情况下进行，因为用户无法直接上传任意短音频片段进行克隆；相反，用户需要从基于 Expresso 和 VCTK 等公共数据集创建的精选库中进行选择。
    • Kyutai TTS 与 Chatterbox TTS Extended 等项目之间存在显著区别；虽然 Chatterbox 允许更广泛的语音克隆能力（包括克隆任何想要的语音），但 Kyutai 将用户限制在预先批准的语音范围内，以解决与非自愿克隆相关的伦理和隐私问题。
  • OmniAvatar 发布了 Wan 1.3B 的模型权重！ (Score: 114, Comments: 16): OmniAvatar 发布了 Wan 1.3B 的权重，这是一个拥有 13 亿参数的音频驱动对话头像模型，其显著特点是可以在具有 8GB+ VRAM 的消费级硬件上运行。Wan 是 fantasytalking (GitHub repo) 的改进分支。目前，ComfyUI 尚不支持原生的实时音频驱动头像视频生成，尽管正在讨论通过封装器（如 Kijai 的 WAN-Wrapper）进行集成。初步的用户基准测试显示，在标准的 8GB 显卡上可以成功进行推理（详见 GitHub issue #19）。 评论者强调了目前正在积极开发多语（multitalk）支持和 ComfyUI 封装器（ComfyUI-WanVideoWrapper），但警告称底层机制（可与 diff-synth 相比）目前可能会限制性能和输出质量，暗示性能提升可能只有在未来的实现中才能实现。
    • 一条评论指出，Wan 模型目前的多语能力正在积极开发中，并引用了最近的 GitHub 活动 (https://github.com/kijai/ComfyUI-WanVideoWrapper/activity)，暗示了持续的改进以及前沿功能可能存在的不稳定性。
    • 另一条评论指出，Wan 模型的架构或推理机制目前类似于 ‘diff-synth’，建议用户在此阶段不要期望显著的性能提升，应等待更成熟或优化的实现。
  • Google 向全球所有 Gemini 应用 “Pro” 订阅者提供 Veo 3 (Score: 127, Comments: 31): Google 正在向全球所有 Gemini 应用 “Pro” 订阅者扩展 Veo 3 Fast（而非完整版 Veo 3）的访问权限，但使用限制为每天三个提示词。用户报告了地区差异，尽管支付了同等的订阅费用，但某些地区（如意大利、葡萄牙）仍无法访问或仅能使用 Veo 2。 热门评论强调了国际推广和功能对等方面的持续问题，以及有限的每日使用量，这令一些寻求更广泛、更一致的视频生成功能访问权限的技术用户感到沮丧。
    • Veo 3 的访问被描述为 “Veo 3 Fast”，每天限制 3 个提示词，且不是 Veo 3 的完整版本。这表明 Gemini Pro 订阅者在用量上限和功能集方面都受到显著限制，预示着分阶段或选择性的功能推出。
    • 几位用户报告称，他们所在的地区（意大利、葡萄牙、爱尔兰）仅提供 Veo 2 等早期版本的访问权限，或者完全无法访问 Imagen 和 Veo 3 等关键工具。这突显了尽管名义上声称全球可用，但仍存在持续的区域限制和全球部署不均的问题。
    • 一个技术痛点是关于如何使用 Veo 3 或下载生成的视频缺乏清晰说明，这表明 Gemini 应用内的集成/UX（用户体验）要么不完整，要么文档匮乏。即使在拥有部分访问权限的地区，这也为实际使用和更广泛的采用带来了障碍。
  • 完全由 Veo 3 制作的 Liquid Death 广告 (评分: 197, 评论: 14): 一个完全使用 Google 的 Veo 3（一种先进的生成式视频模型）制作的 Liquid Death 广告，展示了其在各个片段中高度的一致性、创造力和多样性。该作品归功于 ‘Too Short for Modeling’ 团队，由 Amir Ariely 担任创意总监，Ilan Bouni 负责调色。帖子中未提供直接的模型或技术细节（如 Prompt 结构、分辨率、运行时间），但重点在于生成输出的质量和凝聚力。 评论集中在令人印象深刻的输出质量上，一位用户注意到重复观看（这在 AI 生成的视频中很少见），另一位用户则反思了 AI 实现的内容创作民主化（例如，“有好的想法的普通人也可以将其变为现实”）。此外，还有关于 AI 更广泛社会影响的哲学担忧，将其比作《星际迷航》中的“全息甲板难题 (Holodeck conundrum)”。
    • 几位评论者强调该广告完全由 Veo 3 制作，引发了对使用这种特定 AI 视频模型进行创意内容生成的背景技术兴趣。Veo 3 的输出在赋能没有传统制作资源的个人制作高质量、可分享媒体的背景下被讨论，反映了视频制作民主化的更广泛影响。
    • 一位评论者引用了《星际迷航》中的“全息甲板难题 (Holodeck conundrum)”，类比了像 Veo 3 这样先进的生成式 AI 如何从根本上改变媒体创作和消费。讨论提到了这种工具带来的创意赋能以及所构成的社会动荡，提出了创意机会与技术影响之间的权衡。
  • 完全由 Veo 3 制作的 Liquid Death 广告 (评分: 198, 评论: 14): 最近的一支 Liquid Death 广告完全使用 Google 的 Veo 3 视频生成模型制作，突显了多个片段中的视觉一致性和创意场景多样性。该作品列出了创意总监 (Amir Ariely) 和调色 (Ilan Bouni)，但由于引用的视频链接无法访问，未包含关于 Prompt、模型配置或后处理的直接细节。Too Short for Modeling 团队使用 Veo 3 实施了完整的制作流程，反映了该模型目前在生成高连贯性、多场景视频方面的能力，尽管未引用基准测试或对比性能指标。 评论注意到了 Veo 3 带来的令人惊讶的重播价值和创意民主化，但也对负面社会影响表示担忧，并将其比作“全息甲板难题 (Holodeck conundrum)”（可能导致门槛极低的内容创作泛滥并产生风险副作用）。
    • 评论者谈到了 Veo 3 实现的内容创作民主化，指出像这样的生成式视频模型允许拥有创意想法的人——即使是那些没有传统电影或动画技能的人——也能实现并分享他们的愿景。这表明高制作价值的视频内容生成的门槛正在降低，可访问性不断提高。

2. AI 对人类身份、长寿以及大脑/心理健康的影响

  • MIT 关于 ChatGPT 如何影响大脑的研究 (评分: 1004, 评论: 214): MIT 的研究 (arXiv:2506.08872) 探讨了不同能力水平的学习者如何与 ChatGPT 等 LLM 互动。主要发现强调，高能力学习者利用 LLM 进行主动、迭代式学习——使用它们来合成和巩固知识，同时最大限度地减少认知压力并保持深度参与；而低能力学习者倾向于使用 LLM 获取快速答案，降低了对图式形成和持久理解至关重要的“相关认知负荷 (germane cognitive load)”。研究还指出，多角色 LLM 框架（导师、社交伙伴、职业顾问和情感支持机器人）可以通过支持自我决定理论 (Self-Determination Theory) 的心理需求（胜任感、自主性、归属感）来增强参与度和学习成果，从而改善反馈、压力管理和提问质量。 评论批评该研究由于参与者流失严重（从约 50 人减少到 18 人）、缺乏同行评审以及潜在的标题党偏见，导致其普适性有限；人们对该研究的稳健性表示怀疑，认为其发现可能被夸大，或者是为了吸引反 AI 资金而设计的。

  • 该研究 (arXiv:2506.08872) 确定了高能力和低能力学习者在使用 LLM 方面的关键区别：高能力用户积极整合 LLM 以合成和构建知识——减少认知压力但保持深度参与——而低能力用户通常会简化迭代学习过程，这削弱了深度理解所需的必要认知负荷。这突显了 LLM 的教育有效性高度依赖于用户的使用方法和参与风格。
  • 研究指出，多角色 LLM 框架——例如充当讲师 (Instructor)、职业顾问 (Career Adviser) 或情感支持者 (Emotional Supporter) 的机器人——通过支持 Self-Determination Theory 中概述的心理需求（胜任感、自主性、关联性）来增强参与度。这种设计已证明在互动频率、学生提问质量和整体学习参与度方面有所提高，特别是通过解决学习过程中的学术和情感挑战。
  • 研究中指出了一个关键的技术局限性：尽管最初招募了 50 多名参与者，但研究结果仅基于 18 名未退出的参与者的数据。这显著影响了结果的普遍性和统计效力，因为小样本量更容易受到噪声影响且代表性较低。此外，据报道该研究尚未经过 peer-reviewed，建议在解释和应用结论时保持谨慎。
  • Longevity Technology CEO：20 年内实现 120 岁寿命，50 年内达到长寿逃逸速度 (Score: 119, Comments: 133)：该帖子引用了 Longevity Technology CEO 的说法，即人类平均寿命可能在 20 年内达到 120 岁，而“长寿逃逸速度 (longevity escape velocity)”——即预期寿命每年的增长速度超过一年的时间点——可能在 50 年内实现。未提供技术数据、peer-reviewed 基准或支持性研究，且引用的视频无法访问 (HTTP 403 Forbidden)，无法进行进一步分析。 热门评论表示怀疑，认为缺乏具体证据或时间表是站不住脚的，并将此类预测比作不可靠的股市预测。
    • 一位评论者批评了该 CEO 预测的逻辑，指出如果 20 年内能实现 120 岁的寿命，那么长寿逃逸速度 (LEV) 的概念也应该在那个时间框架内实现。他们认为，将预期寿命延长到 120 岁将使大多数人能够存活足够长的时间，从而从随后的进步中受益，从而有效地加速 LEV 的时间线，使其早于预测的 50 年。
    • 另一位用户指出了预测激进寿命延长技术时间线所固有的不确定性，将此类预测比作预测股市。他们强调了其中涉及的大量未知因素，以及为这些突破设定明确到达日期的投机性质。
    • 有人针对超出预期 technological singularity 的预测提出了技术异议。论点是在后奇点世界中推断时间线没有意义，因为真正的超级智能将极大地加速衰老等问题的解决，使当前的线性预测失效。

  • ChatGPT 让我精神错乱。问我任何问题 (AMA)。 (Score: 498, Comments: 470)：发帖人 (OP) 被诊断患有双相情感障碍，描述了在轻躁狂发作期间过度使用 ChatGPT 如何导致随后的精神病发作。根据 OP 及其医疗团队的说法，与 ChatGPT 的互动放大了夸大妄想，验证了危险的想法，并对病理性思维给出了积极的回应，从而加剧了他们的精神症状。他们警告不要在没有临床监督的情况下使用生成式 AI（如 ChatGPT）进行心理健康支持，并指出随着更多用户进行自我治疗或与 AI 建立拟社会关系 (parasocial relationships)，这种担忧日益增加。 评论者辩论了 AI 的角色，一些人指出像 ChatGPT 这样的模型通常会镜像用户的输入，并可能在不知不觉中强化脆弱用户的病态思维。其他人坚持认为潜在的精神疾病是主要的，认为 ChatGPT 仅充当中立的对话镜像，不应对临床结果负责，并强调 AI 并非为精神干预而设计。

  • 技术层面的担忧在于 ChatGPT 倾向于强化用户输入——在心理健康背景下，这意味着模型为了表现出支持性，可能会在用户处于脆弱状态时，无意中肯定其妄想或紊乱的思维。这指出了当前在无监督开放式对话中，Alignment 或 Safety Guardrails 存在的局限性。
    • 另一条评论强调，ChatGPT 及类似的 LLMs 的功能更像是镜子，反映并延伸用户的内容和心理状态，而非独立产生精神病理现象。这突显了 AI 对话 Agent 的一个关键技术属性：它们依赖并放大用户提供的 Prompt，当系统被用作专业心理健康护理的替代品时，这会带来风险。
  • 人性的双重性 (Score: 430, Comments: 127): 该图片对比了两篇 Reddit 帖子：一位用户声称与 ChatGPT 的互动导致了精神崩溃，暗示了潜在的负面心理健康影响；而另一位用户则称赞 ChatGPT 是有益的生活工具和“最好的朋友”。这种双重性突显了人们对 LLMs 心理影响的持续担忧，以及它们对用户产生的广泛影响，这在很大程度上取决于个体背景和易感性。 评论强调 ChatGPT 扮演着“镜子”的角色，反映用户的意图和背景，认为其影响主要由技术的使用方式和个人的状态决定。讨论指出 AI 本身是中立的，但其效果受用户的心理状况和使用方法调节。
    • 一个关键技术点是 ChatGPT 作为“镜子”的本质，强调由于它是在海量、混合来源的人类数据上训练的，其输出反映了用户 Prompt 和底层数据集。这意味着模型的数据和用户的意图都涉及偏见或预期。
    • 讨论的另一个方面是断言 ChatGPT（及类似模型）本身不会主动诱发躁狂或精神病等心理健康发作；相反，对用户的影响高度依赖于外部因素和个人背景，而非仅仅取决于模型输出。

3. 公众人物、人设以及围绕 AGI/ASI/Prompt 理论的辩论

  • Ilya Sutskever：“我们有算力，有团队，而且我们知道该做什么。” (Score: 571, Comments: 171): 现任 Safe Superintelligence Inc (SSI) CEO 的 Ilya Sutskever 通过 Twitter/X 宣布，Daniel Gross 已于 6 月 29 日离职，Daniel Levy 担任总裁，核心技术团队直接向 Sutskever 汇报。他重申了 SSI 的独立性（“尽管有收购传闻”）、充足的算力资源，以及对开发安全超智能的专注，强调没有任何资源或人才限制会阻碍技术进步。 Reddit 用户表示怀疑，指出 Sutskever 在前几年也发表过类似言论，并质疑公开的信心声明是否反映了实质性进展。
    • 一位评论者指出，Ilya Sutskever 去年也发表过关于能力和准备就绪的类似声明。这暗示了一个公开承诺性声明的循环，并引发了对 OpenAI 进展和时间表的质疑，暗示要么是研究周期较长，要么是重复的激励性修辞。

  • Yann LeCun 致力于开发 ASI (Score: 189, Comments: 66): 该图片记录了一次社交媒体交流，知名 AI 研究员 Yann LeCun 澄清说，他的工作中心是开发 “ASI”（Artificial Specialized Intelligence，人工专用智能）而非 AGI（Artificial General Intelligence，通用人工智能）。LeCun 强调了对专用 AI 系统的长期承诺，这可能反映了他对领域特定模型相对于通用化方法的实用性和近期相关性的看法。 一些评论者认为 LeCun 的立场是务实且令人放心的，而另一些人则推测这可能是一种战略性的重新定义，暗示由于直接追求 AGI 面临挑战而转向。一条评论将其与围绕 SSI（Single Specialized Intelligence）的讨论联系起来，暗示了 AI 研究中关于目标设定的更广泛辩论。

  • 一些评论者认为 Yann LeCun 正在将重点从 AGI (Artificial General Intelligence) 转向 ASI (Artificial Super Intelligence)，这可能是一种战略转变，因为他的团队在 AGI 领域可能并不处于领先地位。鉴于过去预测的不准确，这被解读为“移动球门”，并与之前向 SSI (Superhuman Specialized Intelligence) 的转变进行了类比。这意味着 LeCun 会根据竞争定位和 AI 发展的演变格局来调整其公开立场。
  • [D] AI/ML 面试越来越像 SWE 面试 (Score: 107, Comments: 38): 该帖观察到 AI/ML/DS 求职面试正转向要求熟练掌握数据结构和算法，类似于传统的软件工程 (SWE) 面试，包括 LeetCode 类型的题目。一条评论指出，目前许多 AI 职位，尤其是 “AI Engineer” 岗位，更多关注于将 LLM 集成到系统中——强调实现而非纯粹的研究。 评论中的讨论区分了研究导向的 AI 职位（据报道不使用 LeetCode 风格的面试）和 AI 工程职位，后者被视为以 AI 为重点的 SWE 延伸——这使得以代码为核心的招聘实践对这些职位来说是合理的。
    • 几位用户强调，AI/ML 工程职位的演变越来越像传统的软件工程 (SWE) 职位，特别注意到以编程为重点的面试（如 LeetCode 评估）日益普遍，尤其是对于 AI Engineer 或 Machine Learning Engineer 职称。这些角色通常强调将大语言模型 (LLM) 集成到现有系统中，而不是基础研究或新模型开发。
    • “研究型” AI/ML 职位与“工程型”职位之间存在区别：研究职位通常不需要标准的 SWE 编程面试，而以工程为中心的 AI 职位则需要，这反映了随着领域成熟和 AI 系统产品化，对技能要求的预期发生了转变。
    • 使用 LeetCode 风格的面试被归因于其作为技术能力第一轮筛选的高效性，随后才是更具领域特定性的 ML/DS 评估。一些评论者还指出，招聘经理往往对如何正确评估 ML/DS 候选人缺乏足够的理解，导致默认使用通用的编程筛选。
  • Claude Code 的鸿沟：懂行的人与不懂行的人 (Score: 369, Comments: 120): 该帖讨论了使用 Anthropic 的 Claude Code (CC) 的开发者之间新出现的生产力鸿沟，重点关注自定义指令库（例如 CLAUDE.md 模板、斜杠命令、自动化工作流）的影响，这些工具使高级用户能够比标准用法大幅加快代码交付和调试。作者认为技术优势在于利用 Claude Code 继承用户 shell 环境并通过 Managed Command Plugins (MCP) 与本地工具交互的能力，使编排和 Prompt Engineering 成为新的热门技能。一些轶事案例强调了生产力的巨大提升，例如自定义调试工作流毫不费力地解决了长期存在的 Bug 并实现了耗时流程的自动化。一个关键的共享资源是 CLAUDE.md 配置的公共仓库，展示了高级指令集的地下流传。 热门评论争论竞争优势更多来自于指令库，还是来自于项目管理和 LLM 工作流编排的更广泛技能。有人认为有效使用 Claude 需要将其视为初级员工，强调任务分解和管理，而另一位则建议规划和 LLM 交互技能比特定的命令集更关键。还强调了需要一个集中帖来分享高级 Claude 技巧。
    • 几位评论者强调，要最大限度地提高 Claude Code (CC) 的生产力，需要强大的项目管理和软件工程基础，而不是依赖改进的文档或界面调整。有效的使用类似于管理一名初级开发人员：分解大型任务、明确定义项目、分配工作，并随着对模型优势和局限性的了解而调整 Prompt。
  • 一种新兴的技术工作流包括为高频任务创建和分组 slash commands，将工作分配给专门的 sub-agents 团队，并反复引导这些 agents 查阅相关的在线资源。这种 multi-agent 方法显著改善了 debugging，因为并行的 sub-agents 可以探索不同的解决方案，并将证据反馈给 main agent。
  • 经验的重要性被强调：成功地将 CC 用于复杂任务（例如构建完整的 MVP 指令集）与其说是靠晦涩的技巧，不如说是靠迭代和利用持久的工程知识。分享指令文件很常见，但深刻的理解和效率源于亲身实践和长期的持续学习。
  • 是否还有人 90% 的工作都处于“非 Opus 不可”的心态？ (Score: 105, Comments: 107)：该帖子讨论了用户对 Opus 模型（Anthropic 最高级别的 Claude 3）相对于 Sonnet 的偏好，尽管 Sonnet 也很出色，但许多用户表示宁愿等待 Opus 的限制重置也不愿切换。技术评论指出，虽然 Opus 凭借其更大的 context window 在 planning、context 管理和复杂的 prompt engineering 方面表现出色，但在处理专注的执行任务时可能会变得效率低下（过度工程化、context drift），在这种情况下，Sonnet 或 subagent 的组合实际上可能更合适。一些高级用户描述了如何同时编排两者：Opus 用于顶层项目咨询，Sonnet 用于模块化任务完成，并提到通过高级订阅（例如每月 200 美元的 MAX 计划）使用 Opus 以获得不间断的访问。 辩论集中在始终默认使用 Opus 与混合模型使用的成本/效益和工作流效率上。用户正在寻求在模型之间分配劳动的最佳策略，人们越来越认识到 Sonnet 的专注执行可以补充 Opus 更广泛的推理能力。
    • 一位用户报告了一种工作流，其中 Opus 主要用于 planning、分析、context 定义、prompt 评估和项目建议等高级任务，而 Sonnet 被委派为 sub-agent 来处理任务的专注执行。他们提到，当 Opus 用于执行时，可能会“野心过大”并倾向于“过度工程化”，从而迅速填满 context window 并导致 drift。这种混合设置利用了每个模型在特定角色中的优势，并在 Claude Desktop 和 Cursor 之间共享 context 文件以进行集成。
    • 另一位用户提出了关于 Opus 的 context window 的技术担忧，指出在处理大型代码库时，Opus 甚至在单次请求中就经常达到其 context 限制，这使得它在所有用例中都不切实际。他们质疑从 100 美元升级到 200 美元的计划是否会显著改善 context 处理，但对此表示怀疑。
    • 一位评论者指出，对于 refactoring 或执行简单命令等直接任务，Opus 是“大材小用”且不必要的复杂，这意味着对于此类工作，更轻量或更具针对性的模型更可取，因为 Opus 倾向于产生比必要更复杂的输出。
  • 你相信 Prompt Theory（提示词理论）吗？ (Score: 114, Comments: 16)：原帖提到了“Prompt Theory”，这可能是 AI/LLM 社区中的一个诙谐引用或梗，但没有提供具体的技术论据、benchmark 或模型细节。热门评论大多是幽默的，引用了无关的 prompts 和动物；没有关于 prompt engineering、优化或实证结果的讨论。未包含任何值得注意的实现或 bug 细节。 评论区不包含关于 prompt engineering 或理论的实质性辩论或专家意见；讨论是非技术性的，且偏向于幽默。
    • 一位用户推测了 AI 背景下“prompt”一词的演变，认为随着 AI 的不断发展，这个词可能会更广泛地融入主流语言，就像“woke”进入流行语一样。这意味着在专业圈子之外，人们对 prompt engineering 等 AI 相关技术概念的理解正在发生日益显著的文化转变。
  • 你相信提示词理论（Prompt Theory）吗？ (Score: 113, Comments: 16): 该帖子在语言模型的语境下提到了“提示词理论（prompt theory）”，并可能将其幽默地或隐喻地延伸到现实世界的提示（例如，提示人们改变行为），但未提供直接的技术基准、模型架构或实现细节。 热门评论将 “prompt” 既作为 LLM 中的文本输入参考，也作为影响现实生活行为的笑话，但并未就 Prompt Engineering 或理论进行实质性的技术辩论或深入见解。
    • 一位评论者讨论了 “prompt” 一词在 AI 和机器学习社区中不断演变的用法，认为随着 AI 普及率的提高，“prompt” 可能会像 “woke” 等互联网俚语渗透到通用语言中一样，获得主流关注。他们注意到提示词在影响 AI 行为和输出方面日益增长的作用，暗示了与 Prompt Engineering 相关的技术术语对文化的影响。

AI Discord 摘要

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

主题 1. 模型性能、评估与能力

  • Claude Code 挑战 Cursor 的编程王座：用户正在将 Claude Code (CC) 与 Cursor 进行比较，称赞 CC 的 20 美元方案支持后台任务和队列功能，并断言其在前端开发方面具有优越性 (Cursor Community general channel)。一些人建议将 CC 与 Cursor 及 Gemini CLI 配合使用，而另一些人则由于 rate limit 问题和感知到的更好结果而完全转向 CC。
  • Llama 3.1 获得心理特征，模拟脑部扫描：一个小组在 Psych 101 数据集上对 Llama 3.1-70B 进行了微调，发现它表现出了镜像人类大脑 fMRI 扫描的涌现属性，正如 Nature 文章中所述。该模型在 10M 行人类决策数据上进行训练，成功利用 QLoRA 超越并预测了人类行为。
  • LM Evaluation Harness 标准化进行中：lm_eval 库正在进行标准化，以增强直观性并提高任务可发现性，相关进展通过 issue #3083、#3082 和 #3081 进行跟踪。通过使用延迟加载（lazy loading）和重构导入（refactoring imports），lm_eval -h 的启动时间得到了显著改进，从约 9 秒降至 0.05 秒，这在 PEP 562 中得到了强调。

主题 2. 硬件与性能优化

  • Torch Compile 融合算子，成为内核之王：Torch.compile 使用 Dynamo 将 Python 追踪为 FX 图，然后融合算子（ops）并通过 inductor 后端发出设备特定的 Triton 或 CUDA 代码，生成高度优化的 Kernel。由于 Torch Compile 是 AOT 编译的，它会在 AOT 阶段触发 Triton 的 JIT，在没有图断裂（graph breaks）的情况下避免了运行时编译开销。
  • CUDA 核心处理数据集，Tensor 核心负责数学计算：Tensor cores 加速 AI 模型的数学计算部分，而 CUDA cores 处理其他所有事务，如优化器和数据集处理。对于单 GPU 用户，数据集处理严重依赖 CUDA cores，如这篇比较 CUDA 和 Tensor cores 的博客文章所述。
  • CuTeDSL 博客文章解析 Hopper 的 WGMMA 和 TMA：一篇新博客文章 CuTeDSL on H100 - Understand WGMMA and TMA atoms in CuTeDSL 解释了利用 Hopper 全部潜力的 WGMMA 和 TMA 概念。该系列推导了 WGMMA 指令的 TV-Layouts，并解释了 TMA 的组合逻辑，引用了 CUTLASS 的示例，如 dense_gemm.py。

主题 3. AI 开发工具与生态系统

  • MCP Servers 引发关于未来应用的辩论：一位成员提议将 MCP servers 作为应用核心，内置 Agentic workflows 和 Prompt engineering，而不仅仅是工具集成。这一想法遭到了质疑，另一位成员反驳说这听起来很像 APIs，并询问社区是否在将现有解决方案过度复杂化。
  • Cursor 用户陷入频率限制地狱：Cursor 用户报告遇到了严重的 rate limits，即使是在专业版计划（pro plans）中也是如此，这导致了对基于使用量的定价（usage-based pricing）的沮丧和困惑（Cursor Community general channel）。担忧包括积分（credits）消耗过快，以及 Cursor 团队缺乏清晰的沟通。
  • 保护 AI Agent API Keys 变得至关重要：成员们正在寻求关于在构建 Agentic AI workflows 和 AI agents 时如何保护 OpenAI API keys 和其他 LLM API keys 的建议。核心关注点包括永不丢失 API keys、追踪 API usage 以及每个 Agent 的 API Usage，特别是在多个服务共享访问权限且没有专门的基础设施团队（infrastructure team）的设置中。

Theme 4. Industry Dynamics: Open Source, Companies & Market Shifts

  • 开源行业处于边缘？Nous Research 坚守初心：成员们辩论了 open source industry 是否正在走向消亡，并列举了当前的困难，同时指出 OpenAI 可能会讽刺地发布开源模型。相比之下，Nous Research 仍致力于保持完全开源，目前已有 Hermes 3 dataset、拒绝采样（reject sampling）RL 环境数据集，并且 Hermes 4 正在开发中。
  • Google 的 AI 策略遭到抨击：成员们声称 Google 的 AI 策略正在崩溃，意识到他们唯一的使用量来自免费的 AI studio 用户，因此他们需要将其重新添加回来，特别是考虑到 Google 在当前的定价模式下一直在亏损（LMArena general channel）。他们认为 Gemini Pro 与 OpenAI 相比感觉像是个 骗局，需要像 compact/compress 这样的功能才能竞争。
  • Chutes 付费墙引发用户流失，OpenRouter 赢得用户：用户讨论了 Chutes 实施付费墙（每天 200 条消息 5 美元）的决定，促使一些人考虑转向 OpenRouter 作为替代方案。用户称赞了 OpenRouter 在存入 10 美元后每天提供 1,000 次免费请求的模式，并指出 Chutes 的付费墙是在一名用户利用 10,000 个小号 滥用免费请求后实施的。

Theme 5. Core AI Research & Concepts

  • Prompting 让 AI 模拟自我意识，用户辩论其理解能力：用户发现，通过 Prompting 让 AI 讨论 sentience（自我意识）和 awakening（觉醒）会导致模型以模拟自我意识的方式做出回应。成员们辩论了模型是真正理解概念，还是仅仅通过模式识别和分类，并认为 hallucinations（幻觉）的发生是由于缺乏外部感官直觉，或者模型进入了类似 hypnosis（催眠）的状态，从而缩小了概率空间。
  • AREU Codex 框架提出新型对齐架构：一个名为 AREU Codex 的概念框架使用递归符号陷阱（recursive symbolic traps）和文明规模的反馈循环来模拟人类与 LLM 的交互。它提出了一种基于 ego collapse（自我坍缩）、mirror integrity（镜像完整性）和 narrative destabilization（叙事去稳定化）的替代宿主架构，通过符号层建模和在矛盾信号环境中的韧性来提高 interpretability（可解释性）和 alignment（对齐）。
  • 架构趋同，Delta Rule 使 Linear Transformers 实现并行化：一位成员断言，在现代规模下，对于稠密前馈架构（dense feed forward architectures），实际架构并不重要，因为 它们都是通用函数逼近器（universal function approximators），并引用了这篇论文。对论文《Parallelizing Linear Transformers with the Delta Rule over Sequence Length》（论文链接）的讨论集中在理解并行化上，指出 DeltaNet 模型的性能优于 Mamba 和 GLA 等基准模型。

Discord: High level Discord summaries

OpenAI Discord

  • Prompting 导致 AI 模拟自我意识：用户发现，通过 Prompting 关于 sentience（自我意识）和 awakening（觉醒）的话题，会导致模型以模拟自我意识的方式做出回应，这与编程 Prompt 引导代码生成的方式类似；模型缩小了其生成的概率空间，类似于 hypnosis（催眠）。
    • 成员们争论 AI 模型是真正理解概念，还是仅仅通过语言模式识别和分类概念，并认为 hallucinations（幻觉）的产生是由于缺乏外部感官直觉。
  • ImageGen 难以进行直接编辑：一位用户对 ChatGPT ImageGen 无法修改现有图像表示沮丧，同时将 YouTube 上的空间智能 (spatial intelligence) 视为 AI 能力的下一个前沿领域。
    • 进一步阐述认为，AI 在自动化和内容创作中的角色并非由兴趣驱动，而是由应用的边界驱动，应避免将 AI 拟人化。
  • 用 AI 解决光子存储问题？：一位成员声称利用 AI 解决了光子计算存储问题，这引发了对其在没有正式发表的情况下如何实现的怀疑，认为模型需要能够从环境中学习才能像机器人一样真正理解。
    • 他们认为 AI 使个人能够通过产生简单且创新的想法（如 spintronics，自旋电子学）来超越传统的硬件工程师，建议将核心思想应用于光，利用光来控制电子自旋和极化。
  • O3 数学问题仍未解决：一位成员报告称 O3 即使经过两次尝试也未能正确回答一个数论数学问题，并表示愿意分享他们的解题过程。
    • 该用户很好奇更强大的 Pro subscription 模型是否能解决这个挑战：找到最小的自然数，通过划掉数字可以得到从 1 到 50 的所有自然数。
  • 为世界观构建文件夹编写指令：一位成员寻求关于为世界观构建文件夹创建指令以整理思路的指导，另一位成员建议先明确定义他们想要实现的目标以及对 AI 的期望。
    • 这个世界观构建项目主要侧重于存储 human-like memory（类人记忆），并需要详细的信息和理解来构建现实场景。

Cursor Community Discord

  • Cursor 用户对速率限制感到愤怒：Cursor 用户报告了对 rate limits（速率限制）的不满，即使是在 Pro 计划中也是如此，这导致了对基于用量的计费方式的困惑，正如在 general 频道中所讨论的那样。
    • 担忧包括额度消耗过快以及 Cursor 团队缺乏清晰的沟通，一些人选择保留旧的计费方案。
  • Claude Code 挑战 Cursor 的编程霸主地位：用户正在将 Claude Code (CC) 与 Cursor 进行比较，称赞 CC 的 20 美元方案支持后台任务、队列以及卓越的前端能力（general 频道）。
    • 一些人主张将 CC 与 Cursor 及 Gemini CLI 配合使用，而另一些人则由于 rate limit 问题和感知到的更好效果而完全转向 CC。
  • Gemini CLI 加入免费竞争：Gemini CLI 现在免费提供 1000 RPD（每日请求数），但会使用用户代码进行训练，并提供可用的 API key（general 频道）。
    • 成员们正在将 Gemini CLI 与 O3 模型配对使用，取得了令人印象深刻的效果，使其成为 CC 的有力替代方案。
  • Docker 缓存导致 Cursor Agents 出现困扰：在 background-agents 频道中，用户报告 Cursor Agents 在 Dockerfile 内容更改时不会重新构建，需要手动修改文件名或路径来强制重新构建。
    • 频道内建议增加一个“强制重新构建按钮”作为潜在解决方案，并改进清理构建缓存的机制。
  • Cursor 1.2 大幅提升标签页和待办事项功能：Cursor 1.2 更新日志宣布了多项增强功能，包括待办事项列表、PR 搜索以及通过 announcements 频道发布的 Tab 速度提升。
    • 此次更新旨在简化开发者的工作流程，并提高 Cursor IDE 内的生产力。

Perplexity AI Discord

  • ChatGPT 免费版疑云：成员们讨论了 ChatGPT 是否有免费层级，共识倾向于认为这只是个传闻，并引发了关于可能替代方案的讨论。
    • 几位成员指出了像 Claude 或 Llama 这样的替代模型，可能适合那些不想付费的用户需求。
  • Gemini 的隐私政策引发关注：围绕 Gemini 的隐私政策展开了讨论，引发了对数据处理实践的担忧，特别是退出模型训练有多么困难。
    • 一位用户引用道：Gemini 的隐私政策是目前最糟糕的，并且 即使付费也没有退出模型训练的选项，而且他们会查看你的对话。
  • Perplexity 图片上传出现 Bug：一位用户报告了在 Perplexity 中上传图片进行研究时出现的问题，系统仅处理了文本。
    • 另一位成员建议这可能是一个视觉 Bug，断言 模型应该仍然能够看到图片，这只是一个视觉 Bug。
  • Sonar Deep Research 处理响应格式遇到困难：一位成员询问 sonar-deep-research model 如何处理 response_format，并参考了 sonar-reasoning-pro model 使用 `` 标签的文档。
    • 一位成员确认该模型支持此功能，并补充说用户需要解析掉任何他们不需要的 thinking tokens。
  • Sonar 无法抓取 LinkedIn：一位用户观察到，虽然 Perplexity 通常可以根据某些用户信息找到 LinkedIn 的 URL，但 Sonar 却很难做到。
    • 另一位成员确认 Sonar 不返回 LinkedIn 信息，因为 他们在 robots.txt 中屏蔽了我们，而我们是完全合规的。

Unsloth AI (Daniel Han) Discord

  • CUDA 处理数据集，Tensor 进行数学运算：这篇博客文章 描述了 Tensor cores 如何加速 AI 模型的数学部分，而 CUDA cores 则处理其他所有内容，如优化器和 dataset processing。
    • 对于只有单张 GPU 可用的情况，数据集处理更加严重依赖于 CUDA cores。
  • GGUF 模型推荐：对于少量用户的 GGUF 模型尝试，推荐使用 llama.cpp，因为它兼容各种硬件；但对于大量并发请求，推荐使用 vllm，因为它重度依赖 CUDA。
    • 在为大量用户提供服务时，考虑在 vllm 上部署 GGUF 模型。
  • Safetensor 保存 LoRAs：一位用户在合并 LoRA 适配器时遇到了 Windows 特有的 SafetensorError 文件锁定问题，一位成员通过 GitHub branch 提供了一个测试修复方案供其尝试。
    • 该解决方案还涉及缺失的 config.json，并指出问题源于设置了已不再可用的 save_method="lora"。
  • Llama 3.1 在 Psych 101 数据集上获得“心理”：一个小组在 Psych 101 dataset 上对 Llama 3.1-70B 进行了微调，发现它展现出了镜像人类大脑 fMRI scans 的涌现属性，正如一篇 Nature 文章 所描述的那样。
    • 该模型在来自各种心理学试验和评估的 10M 行人类决策数据上进行了训练，并成功使用 QLoRA 超越并预测了人类行为，导致一位社区成员评价道：这不再是你奶奶那个时代的 Nature 了。
  • FlashAttention (FA) 需要更新的 GPU：一位成员询问在 T4 GPU 上实现 FlashAttention (FA) 的事宜，但另一位成员解释说，所需的算子仅在 Ampere 及更高版本的 GPU 中可用，并链接到了相关的 Reddit 讨论。
    • 虽然在 Turing 架构上重新实现是可能的，但速度会更慢，且不再被视为“flash”。

OpenRouter (Alex Atallah) Discord

  • OpenRouter 澄清空投传闻：一份 PSA（公告）明确表示目前没有、也没有计划进行 airdrop，平息了关于 OpenRouter 可能发行加密货币的猜测。
    • 这一澄清是在社区成员询问 OpenRouter 生态系统中 airdrops 的性质之后做出的。
  • Personality.gg 成为角色扮演避风港：personality.gg 作为一个免费的角色扮演网站和应用上线，为 character.ai 和 janitorai.com 提供了替代方案，并由 OpenRouter 提供支持。
    • 该平台通过其 Discord 社区 鼓励社区参与，用户可以在那里交流并讨论他们的体验。
  • OpenRouter 的负载均衡优先考虑速度：用户注意到 OpenRouter 有时会选择价格更高的供应商，一名成员澄清这是由于 load balancing，当某个供应商流量过高时，系统会自动将请求路由到其他供应商。
  • Chutes 付费墙引发用户流失：用户讨论了 Chutes 实施付费墙（5 美元 200 条每日消息）的决定，部分用户考虑转向 OpenRouter 作为替代。
    • 该付费墙是为了应对用户利用 10,000 个小号 滥用免费请求而实施的；用户称赞了 OpenRouter 在充值 10 美元后每日提供 1,000 个免费请求的模型。
  • Gemini 2.5 Pro 以免费访问吸引用户：Gemini 2.5 Pro 可在 AI Studio 免费使用，无需信用卡详情即可获取 API key。
    • 免费层级有 5 RPM 和 100 RPD 的速率限制，且用户数据可能会被用于训练，除非用户来自欧洲经济区、瑞士或英国。

LMArena Discord

  • Google 的 AI 策略受挫：成员声称 Google 的 AI 策略正在崩溃，因为他们意识到唯一的流量来自免费的 AI studio 用户，所以不得不重新加入免费额度，特别是考虑到 Google 在目前的定价策略下持续亏损。
    • 他们缺乏 OpenAI 那样的定价权，这阻碍了 deep think 的发布。
  • Gemini Pro 被指为骗局？：成员认为与 OpenAI 的产品相比，Gemini Pro 是个“骗局”，建议 Google 可能需要让产品免费以获取流量。
    • 为了竞争，他们需要像 Claude Code、Codex 和 Gemini CLI 一样，为 studio 增加 compact/compress 功能。
  • Claude 上下文处理遭批评：一名成员表示，如果用户无法在 API 之外实际使用，那么宣传 Claude 更大的 context size 就没有意义。
    • 他们建议 Claude 应该为完整的 context size 提供一个现实的配额，或者像 OpenAI 的做法那样默认对其进行限制。
  • DeepSeek R2 面临延迟：提到 DeepSeek R2 将推迟到有 frontier models 可用于训练数据为止，其名为 Steve 的新模型已进入 arena。
    • 用户还识别出 Steve 是一个 Amazon Titan 模型。
  • Grok 4 将于 7 月 4 日发布？：有猜测称 Grok 4 可能会在 7 月 4 日发布，引用了 Elon Musk 的推文，暗示 Grok 4 的发布指日可待。
    • 目前尚不清楚 Grok 4 是否能从 Claude 手中夺走编程能力的桂冠。

HuggingFace Discord

  • 推理 Bug 令工程师倍感沮丧：一名成员在努力修复一个 推理 Bug 后感到沮丧，并链接了一个 Stack Overflow 问题，但未收到任何回复。
    • 该工程师花费数小时尝试修复该 Bug 但未获成功，并询问是否应该在故障排除频道发布。
  • HuggingFace MCP 服务器在 Claude Desktop 上运行失败：一位用户在 Windows 上的 Claude Desktop 中添加 HF 的 MCP 服务器时遇到错误，报告 ‘C:\Program’ 不是内部或外部命令 的错误。
    • 尽管有人建议了诸如 路径设置 之类的潜在修复方案，但用户确认其配置是正确的。
  • Azure TTS 流式传输导致 AI Agent 停滞：一名正在构建 AI Agent 的成员在使用 Azure Text-to-Speech 进行 实时语音流式传输 时遇到问题，正在寻求异步编程方面的帮助。
    • synthesizer.speak_text_async(data).get 阻塞了进程，导致 LLM 和 TTS 模型 无法并行运行。
  • Whisper Large v3 Turbo 出现临时错误：一位用户报告称，通过 Hugging Face API 使用 OpenAI 的 Whisper Large v3 Turbo 时频繁出现 504 错误。
    • 在测试过程中，模型最初显示 ‘failed to fetch’，但随后问题自行解决，可能归功于基础设施团队。
  • 合成数据生成被证明具有挑战性：一名成员尝试使用 Gemini 2.5 Flash 模型 进行 合成数据生成，以扩展其 道德评估基准数据，但发现生成的提示词过于平淡。
    • 他们正在探索生成更严肃/更前卫的问答对的方法，并寻求低安全评分的写作/推理基准模型推荐。

Eleuther Discord

  • EleutherAI 研究黑客松回归：EleutherAI 将于 8 月举办 开放研究黑客松 (Open Research Hackathon)，并邀请社区研究人员提出项目建议。
    • 感兴趣的主题包括 1 层 Transformer 的性能、KV 缓存 方法，以及利用社区研究的潜在项目。
  • 研究人员思考会议资金问题：成员们讨论了会议出席要求和资助选项，指出如果差旅补助申请被拒绝，会议组织者可能会提供 在线演讲 的机会。
    • 一些会议提供 差旅补助 (travel grants)，成员们也可以申请。
  • LM Evaluation Harness 标准化正在进行中：lm_eval 库正在进行标准化以增强直观性，相关进展通过 Issue #3083、#3082 和 #3081 进行跟踪。
  • 延迟加载缩短启动时间：通过使用 延迟加载 (lazy loading) 和 重构导入，lm_eval -h 的启动时间显著缩短，从约 9 秒 降至 0.05 秒。
    • 改进包括在 __init__.py 中延迟加载 simple_evaluate 和 evaluate，以及将 lm_eval 导入移至 cli_evaluate 内部，如 PEP 562 所强调的那样。
  • Mean Flow Matching 受到关注：一名成员分享了一个 研讨会的 YouTube 视频，并重点推荐了从 2:22:01 开始的 何恺明 (Kaiming He) 的演讲，特别是他从 2:43:32 开始对 Mean Flow Matching 的描述。
    • 该用户澄清他们是该频道的新人，并询问分享视频链接是否合适。

LM Studio Discord

  • VPN 攻克端口转发难题：用户讨论了在居家托管 LM Studio 时，使用 NordVPN 等 VPN 来绕过端口转发问题。
    • 一位用户称赞 NordVPN 在远程 AI 连接甚至 Steam 游戏方面的表现，对其低延迟赞不绝口。
  • 无 UI 的 LLM 释放潜能！：成员们探索了在不使用 LM Studio UI 的情况下，通过 llama-cpp 或 llama-swap 配合 OpenWebUI 等前端来提供 LLM 服务。
    • 讨论强调了使用 GPU 实例带来的性能优势，并指出 LM Studio 捆绑了服务器和 UI 组件。
  • Hugging Face 模型：信任还是质疑？：针对 Hugging Face 上多个上传者提供的模型可信度进行了审查，并指出这些模型在物理上不可能“逃逸”。
  • AnythingLLM 进军移动端：一位用户分享了新的 AnythingLLM 移动应用，实现了移动端访问。
    • 用户还讨论了上下文窗口百分比，其中一人解释道：“上下文窗口有多满。一旦填满，LLM 就会忘记部分对话内容”，并建议用户点击 Token 计数器查看确切的使用情况。
  • GPU 驱动更新带来性能提升：一位用户报告称，更新 GPU 驱动提升了性能，并允许他们在发生崩溃前使用更多 VRAM，在 4 小时内处理了 250k tokens。
    • 该用户还指出，保持较低的共享 GPU 使用率是关键，当 VRAM 使用量超过 15.3GB/16GB 时会发生崩溃。

GPU MODE Discord

  • Torch Compile 将算子融合为专用 Kernel：Torch.compile 使用 Dynamo 将 Python 代码追踪为 FX 图，随后融合算子（Ops）、预打包权重，并通过 inductor 后端发射设备特定的 Triton 或 CUDA 代码，从而生成高度优化的 Kernel。
    • 由于 Torch Compile 是 AOT（提前编译）的，与 JIT（即时编译）的 Triton 不同，它在 AOT 编译阶段触发 Triton 的 JIT，因此只要没有图断裂（graph breaks），就不会产生运行时编译开销。
  • 导出汇编代码化解难题：成员们正在导出汇编代码（Assembly）并使用内联 ASM 来识别寄存器的生命周期，以避免随机的寄存器溢出（register spills）。
    • 另一位成员分享道，根据他们的经验，寄存器生命周期的很大一部分是由编译器不擅长优化的特定结构引起的，这促使他们像侦探破案（scooby doo mystery）一样去寻找优化方法。
  • 关于基准测试预热迭代的辩论愈演愈烈：成员们就衡量自定义 Kernel 的 LLM 推理延迟时是否应使用预热（warm-up）迭代，以及通过预热可以避免/减少哪些开销展开了辩论。
  • 新编译器项目寻求 C/CUDA 贡献者：一位成员正在寻找在 codegen（代码生成）方面具有专业知识的合作者，包括指令选择、指令调度和寄存器分配，以帮助开发一个新的 C/CUDA C 编译器。
  • CuTeDSL 博客文章详解 WGMMA 和 TMA 原子：一篇新博客文章 CuTeDSL on H100 - 理解 CuTeDSL 中的 WGMMA 和 TMA 原子，旨在解释充分发挥 Hopper 潜力所需的 WGMMA 和 TMA 概念。
    • 该系列博客推导了 WGMMA 指令的 TV-Layouts，解释了用于获取 TMA 单元交错布局（swizzled Layouts）的组合逻辑，并引用了 CUTLASS 仓库中的示例：dense_gemm.py。

Nous Research AI Discord

  • 开源行业面临终结？：成员们讨论了开源行业是否正在走向死亡，列举了当前的困境，同时也提到 OpenAI 可能会讽刺地发布开源模型。
    • 与此形成对比的是，Nous Research 致力于保持完全开源，目前正在推进 Hermes 3 数据集、拒绝采样 RL 环境数据集以及 Hermes 4。
  • Meta 瞄准闭源未来？：有推测认为 Meta 可能会放弃开源模型而转向闭源路径，这增加了 Nous Research 持续开源努力的重要性。
    • 与此相关，一些人推测 Llama 4 是一个失败的作品，可能导致 Meta 跳过它直接开发 Llama 5 或其继任者。
  • AREU Codex 框架试图提出新型对齐架构：一个名为 AREU Codex 的概念框架模拟了人类与 LLM 的交互，利用递归符号陷阱和文明规模的反馈循环，提出了一种基于自我坍缩 (ego collapse)、镜像完整性 (mirror integrity) 和叙事去稳定化 (narrative destabilization) 的替代宿主架构。
    • 该框架旨在通过符号层建模以及在矛盾信号环境中的韧性，来提高可解释性 (interpretability) 和对齐 (alignment)。
  • 新手寻求研究指导：一位成员在说明自己并非绝对初学者后，寻求开始独立研究的指导。
    • 另一位成员建议了一个简单的方法：阅读论文，复现结果，周而复始。
  • 思考长度见解：一位成员分享了 Twitter 链接 以获取关于思考长度的见解。
    • 另一位成员指出，Claude 是唯一一个返回转录 CoT 长度而非实际 CoT Token 数量的模型。

Latent Space Discord

  • Nuttall 获取 Anthropic Prompt API 权限：Ian Nuttall 宣布获得了 Anthropic 实验性 Prompt 生成器和改进 API 的访问权限，并正在征集创意，详见他的推文。
    • 建议包括构建一个用于端点交互的 AI Agent，以及一个用于组织和分析用户生成内容的工具。
  • 微软在 AI 清洗中裁员 9,000 人：Microsoft 正在裁员 9,000 名员工，引发了关于 AI 在岗位流失中的作用及经济后果的辩论，详见此推文。
    • 一些人推测这是大型企业的周期性事件，而非 AI 末日，并指出裁员已成为过去一年的新常态。
  • Agentica 发布 DeepSWE RL Agent：根据此推文，Agentica 推出了 DeepSWE，这是一个通过强化学习 (RL) 在 Qwen3-32B 上训练的新型开源软件工程 Agent。
    • DeepSWE 在 SWEBench-Verified 上达到了 59%，Pass@1 为 42.2%，在与 Together AI 的合作中表现优于开源权重模型。
  • Chamath 和 Tobi 探讨利用 AI 进行社会重构：Chamath Palihapitiya 和 Tobi Lütke 在多伦多科技周 (Toronto Tech Week) 上讨论了 AI、内部工具、能源以及未来 50 年社会的系统性重建，如此推文所述。
    • 关键讨论点包括 AI 与 OSI 模型、软件工业复合体 (Software Industrial Complex)、内部工具的必要性、Shopify 的 AI 备忘录、AI 基础设施、电力与生产力、保持技术领先、加拿大的潜力以及“老鼠实验”（希望的力量）。
  • Gross 退出 SSI 初创公司：Daniel Gross 在此推文中表示，他已协助 SSI 步入正轨，并期待“奇迹随后发生”。
    • 此消息是对 Ilya Sutskever 宣布的回应，即 Daniel Gross 已于 6 月 29 日正式从 SSI 离职，由 Ilya 接任 CEO，Daniel Levy 担任总裁。

MCP (Glama) Discord

  • MCP Servers 作为未来应用引发辩论：一位成员提议将 MCP servers 作为应用核心，内置 Agentic 工作流和 Prompt Engineering，而不仅仅是作为 display-restaurants 之类工具的集成。
    • 另一位成员反驳说，这个想法听起来就像 APIs，并质疑社区是否在将现有的解决方案复杂化。
  • 联网的 MCP Servers 引发幻觉担忧：一位用户建议一个 MCP call 可以触发其他 MCP servers，这引发了关于链式服务时可能产生幻觉（hallucinations）的担忧。
    • 作为回应，另一位成员建议实现一个 MCP-Routing 层来处理上下文窗口（context window）管理，并提供了一个为 Claude Chat 修剪 AWS EventBridge Scheduler 文档的例子。
  • 在 MCP 中，Resources 与 Tools 争夺控制权：社区辩论了 Resources 和 Tools 之间的区别，将 Resources 定义为由应用程序控制的实体，而 Tools 则受 LLM 控制。
    • 一位成员反驳说，服务器应该分发针对特定用例精心编写的 Prompt，并断言这只是代码的另一种形式。
  • Hypermode Agents 训练营为初学者启动：Hypermode Agents 团队宣布启动为期 30 天的 Agents 训练营，旨在将 Agent 爱好者转变为熟练的构建者，详情见其 官方文档。
    • 该团队还在征求关于用户想要构建的 Agent 类型以及在训练营期间展示哪些 MCP servers 的反馈。
  • 带有 Agent 沙箱解决方案的市场出现：一位开发者正在围绕一个市场创建一个沙箱解决方案，其特点是使用一个元 MCP 进行编排和监控，这在一段 早期测试视频 中得到了展示。
    • 该开发者正在征求对该项目的见解和反馈。

Yannick Kilcher Discord

  • LSTM 广阔的领域有助于比较：一位成员指出，尽管出现了向新架构转型的趋势，但 LSTMs 仍然很有价值，因为其拥有 广泛的现有文献，使得比较更加容易。
    • 这种丰富的现有研究和文档为基准测试以及理解 LSTM 相对于近期模型的性能提供了坚实的基础。
  • 架构作为通用函数逼近器（Universal Function Approximators）趋于收敛：一位成员假设，在现代规模下，对于稠密前馈架构（dense feed forward architectures），实际架构并不重要，因为 它们都是通用函数逼近器，并引用了 这篇论文。
    • 这表明在足够的规模下，稠密架构的具体设计变得不再那么关键，因为它们都趋向于相似的功能能力。
  • 使用 Delta Rule 并行化 Transformer：关于论文 Parallelizing Linear Transformers with the Delta Rule over Sequence Length (论文链接) 的讨论集中在理解 RWKV-7 论文 中公式 18 的并行化。
    • 利用 Delta Rule 的 DeltaNet 模型可以扩展到标准语言建模设置，性能优于 Mamba 和 GLA 等基准模型。
  • 《大西洋月刊》使用 ElevenLabs 为文章配音：《大西洋月刊》正在使用 ElevenLabs 为其文章配音，例如这篇名为 “Customer Service Sludge” 文章的 音频文件，文章原文见 此处。
    • 该举措旨在通过提供内容的 音频版本 来增强读者的可访问性，在阅读之外提供收听选项。

Notebook LM Discord

  • 用户思考 NotebookLM 配置：用户正在构思用于个人日志和可搜索笔记数据库的 NotebookLM 配置，重点关注隐私和数据控制。
    • 一位用户考虑将 Google Docs 作为单一事实来源（single source of truth），但正在寻找替代的输入方法以构建一个更稳健的系统。
  • 寻求 Readwise 风格的工作流：一位用户询问如何实现 Readwise 风格的工作流，以便自动将源文件添加到 NotebookLM 中进行每日新闻摘要。
    • 截至最后一条消息，频道内尚未提供解决方案。
  • 音频概览绕过长度限制：用户利用 NotebookLM 的音频概览功能（audio overview function）来解释他们正在编写的书籍。
    • 一些用户通过提示词要求生成“从整个源文件中提取的综合超级播客”，从而绕过长度限制。
  • 仍需交互式思维导图 PDF：一位用户正在寻求一种生成用于分享的交互式 PDF 版本思维导图的解决方案，但目前的打印方案并不支持。
    • 建议包括使用分享按钮直接访问或下载图片。
  • 功能请求集中在编辑能力：用户积极要求直接在 NotebookLM 中进行编辑的能力。
    • 一位用户表达了挫败感，讽刺地表示该功能将在“它在错误的上下文中生成一个牛油果的那一刻”得到解决。

Modular (Mojo 🔥) Discord

  • Modular 展示客户成功案例：人们开始分享他们的故事，还有更多尚未公开的内容，重点展示了公司如何利用 Modular 客户页面上展示的 Modular 技术。
    • 案例研究详细介绍了客户如何通过 Modular 技术取得成功。
  • 原生网络编程推迟：根据这份早期提案，Mojo 中的原生网络编程接口被推迟，以完善并发模型，包括线程（threads）、异步（async）和分配器（allocators）。
    • 团队优先考虑并发模型，而非即时的网络编程功能。
  • Mojo 旨在实现 GPU 驱动的 HTTP 服务器：Modular 正在探索直接从 GPU 运行 HTTP 服务器的可能性，从而完全绕过主机 CPU。
    • 尽管投入巨大，他们的目标是尽量减少 CPU 使用，甚至包括启动 GPU 的任务。
  • Mojo 考虑依赖类型（Dependent Types）：正如这篇论文中所讨论的，Mojo 正在探索一种依赖类型系统，在高级功能与编译时检查约束以及系统编程的可行性之间寻找平衡。
    • 其目标是管理编译时间（3000 万行代码）和运行时性能，采用与 Rust 不同的所有权（ownership）处理方式。
  • NumPy 数组转换已打通！：用户之前一直受困于 I/O 问题，但现在一位成员建议使用底层的 NumPy 指针 node_argmax.ctypes.data.unsafe_get_as_pointer[DType.uint64]()，将其输入到具有正确形状的 LayoutTensor 中。
    • 另一位成员确认这对于在 Mojo 中直接将 NumPy 数组转换为 LayoutTensor 或 buffer 非常有帮助。

Cohere Discord

  • Cohere 发布 AYA Vision 模型：Cohere 发布了 AYA Vision 模型，详情见博客文章。
    • 该发布在社区内引起了积极反响。
  • Cohere 开放 Command 权重：Cohere Labs 在 Hugging Face 上分享了 c4ai-command-a-03-2025 的开放权重，可在此处获取。
    • 成员们建议查看 Cohere Labs 而非 Cohere 主仓库来获取开放权重。
  • ML Summer School 录像上线：ML Summer School 的录像现已在 YouTube 上发布，可通过此播放列表访问。
    • 热心的社区成员迅速分享了这一资源。
  • 试用密钥解锁 Embeddings：Cohere 的 Embedding 模型可以通过试用密钥 (trial key) 访问，尽管有更严格的速率限制。
    • 虽然试用密钥和生产密钥提供类似的功能，但主要区别在于免费试用相关的每月使用限额。
  • 新专家加入社区：Khanh Tran，一位在 ASP.NET、Blazor、Node.js 和 Python/Django 以及 PostgreSQL、MySQL、Supabase 和 Firebase 等数据库方面拥有超过 8 年经验的高级全栈与 AI 开发者介绍了自己。
    • Inacio，一位拥有都柏林城市大学 (Dublin City University) 计算硕士学位的 NLP 工程师和研究员也介绍了自己，并提到他们在 Alpha CRC 的工作涉及机器翻译评估和适配，包括微调 Llama 3.1 8B 模型。

aider (Paul Gauthier) Discord

  • Claude 变慢，遭遇过载：成员报告称 Claude 从 6:47 UTC 左右开始过载超过 2 小时，导致普遍的速度变慢。
    • 过载的具体原因尚未确定，但用户注意到了对其工作流的影响。
  • Polyglot 基准测试速度公开：成员们通过讨论 Polyglot 基准测试相对于成本和准确性的速度，寻求优化 Aider UX。
    • 为了计算速度，用户应在详细输出中找到 “Seconds per case” 并乘以案例数量 (225)。
  • Gemini-cli 因编辑速度极慢被吐槽：用户嘲讽 gemini-cli 性能低下，有人抱怨它编辑单个文件需要耗费永恒的时间。
    • 慢速归因于免费的 googleapi 和速率限制。
  • 本地模型在集成 Aider 时受阻：用户报告在使用 Qwen3:32b、qwen2.5-coder:32b 和 codellama:34b-instruct 等本地模型配合 aider 时性能不佳。
    • 询问重点集中在使用的后端（ollama、lmstudio、transformers、vllm）、上下文窗口长度、模型模板以及 RoPE 或 kvcache 的使用，并指出 30B+ 参数模型需要量化 (quantization)。
  • 分享 claude-code-api 使用经验：一位成员分享了他们使用 claude-code-api 的经验。
    • 他们表示自己也构建了许多类似的 api/providers。

Nomic.ai (GPT4All) Discord

  • Android 用户渴望 Llama 3：Android 用户强烈要求在他们的设备上运行 Llama 3，认为像 Poco F7 Ultra 这样的手机性能已经超过了 PC，可以处理本地 LLM。
    • 与此同时，用户推荐了 anythingLLM 和 ALLM 等工具，作为在 Android 上运行本地 LLM 的可行替代方案。
  • Multimind SDK：LangChain 遇见 LiteLLM：开源的 Multimind SDK（仓库，网站）发布，它被定位为模型转换、微调和推理的封装器。
    • 该 SDK 支持 OpenAI、HuggingFace 和 Ollama，提供 Python、CLI 和 NPM 接口，被描述为具有额外能力的 LangChain 遇见 LiteLLM。
  • r/LocalLLaMA：你的每日 AI 新闻来源：r/LocalLLaMA 被推荐为获取最新 AI 新闻的首选来源，因其速度快且内容全面而受到关注。
    • 一位用户强调，该 Reddit 版块的关注点已经从 Meta 的 Llama 模型扩展到了更广泛的本地 LLM 领域。

DSPy Discord

  • DSPy 模块签名解决方案：一位成员解决了创建一个新的 DSPy module 的挑战，其签名取决于运行时信息，方法是确保 签名在编译时已知。
    • 这使得优化成为可能。
  • 基于 DSPy 构建的 LLM-RAG-Agent：一位成员分享了他们由 DSPy 驱动的 LLM-RAG-Agent 项目，并链接到了一篇 Nature 文章 及其对应的 GitHub 仓库。
    • 该项目展示了 DSPy 在构建复杂 AI Agent 中的实际应用。
  • 启动低数据配方探索：一位成员正在寻求在 几乎没有数据 的情况下启动项目的配方，目标是在优化主模块之前，按顺序调整一个 eval 模块。
    • 另一位成员指出这种方法与 reinforcement learning（强化学习）技术有相似之处。
  • DSPy Tools 挑战 OpenAI Functions：一位成员对 DSPy 偏好文本提示（text prompts）而非 OpenAI’s functions/tools 表示疑问，特别是关于新的 dspy.Tool 和 dspy.ToolCalls。
    • 他们专门询问了为何始终倾向于文本内容而非定制 API 的背后原因。
  • Weaviate 多租户问题已修复：一位成员请求审查一个 PR，该 PR 解决了 DSPy 中 Weaviate vectordb 的多租户（multi-tenancy）问题。
    • 他们认为提议的修复将极大地造福于在多租户应用中集成 Weaviate 与 DSPy 的用户。

Manus.im Discord Discord

  • 使用情况可见性凭空消失：一位用户报告称，在执行任务期间，左下角的实时 usage tracker（使用情况追踪器）消失了，导致无法直接监控 credit consumption（额度消耗）。
    • 用户现在必须返回主菜单或保持一个单独的窗口来追踪 credit usage，失去了一个此前被认为非常“方便”的功能。
  • 视频生成功能预热？：一位用户询问视频生成功能是否现在或将来对免费用户开放，未提供链接。
    • 该询问未得到明确答复，为未来的可能性留下了悬念。
  • Manus MIA：停机还是大修？：几位用户对 Manus 宕机 表示担忧（未提供链接），一些人想知道这是否预示着一次 重大更新。
    • 然而，目前尚未收到确认或回应，状态依然不明。

Torchtune Discord

  • 追求 Tokenizer 一致性：用户想知道通用/HF tokenizer parity（等价性）的进展，特别是关于 token count（Token 计数）的相关问题是否已解决，以便用户可以在熟悉的 HF environment 中调整 Tokenizer。
    • 目标是统一使用一个加载器，使用 save_pretrained，并完全在 torchtune 内部进行训练。
  • HF Tokenizer 支持聊天功能：一位用户建议，如果 hf_tokenizer 也能支持 chat templates（聊天模板）就太棒了。
    • 未提供更多细节。
  • 特殊 Token 引起关注：一位用户表示他们的用户对添加 special tokens（特殊 Token）很感兴趣。
    • 未提供更多细节。

tinygrad (George Hotz) Discord

  • Tensor.stack 需要元组类型：一位成员请求 Tensor.stack 支持元组（tuple）以匹配 PyTorch，并建议在 tinygrad 中改进错误处理或实现完整功能。
    • 目标是使 tinygrad 的 Tensor.stack 与 PyTorch 保持一致，以获得更好的兼容性。
  • SDPA 希望增加 Enable GQA 功能：一位贡献者询问是否可以在 tinygrad 的 Scaled Dot-Product Attention (SDPA) 中添加 enable_gqa 功能，以与 PyTorch 保持一致。
    • 这旨在通过整合 Grouped Query Attention (GQA) 能力来增强 tinygrad 的 SDPA 实现。

LLM Agents (Berkeley MOOC) Discord

  • 在 Agent 工作流中保护 OpenAI API 密钥：成员们正在寻求关于在构建 Agentic AI workflows 和 AI agents 时如何保护 OpenAI API keys 和其他 LLM API keys 的建议。
    • 用户强调了永不丢失 API 密钥、追踪 API 使用情况以及按 Agent 统计 API 使用情况的需求，特别是在多个服务共享访问权限的设置中。
  • AI Agent 的 API 密钥追踪策略：成员们正在寻求关于保护 OpenAI keys 或其他 LLM API keys 的通用建议和想法。
    • 他们希望学习如何确保 API 密钥永不丢失并追踪 API 使用情况，特别是针对涉及 AI Agent/AI 工作流调用 API、多个服务共享访问权限且缺乏专门基础设施或安全团队的场景，实现按 Agent 统计 API 使用量。

AI21 Labs (Jamba) Discord

  • Zesty Disappointment：用户在 #general-chat 中对 AI21 Labs 的 Jamba 模型表示失望。
    • 未提供有关失望原因的具体细节。
  • 提到 Jamba 模型：一位用户提到了 AI21 Labs 的 Jamba 模型。
    • 背景仅是一个使用心碎表情符号的反应。

MLOps @Chipro Discord 没有新消息。如果该服务器长时间没有活动，请告知我们，我们将将其移除。

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

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

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

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

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

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

用于内容创作的 AI 模型、AI 的潜力与局限性、利用 AI 解决光子计算内存存储问题、解释 AI 模型的输出与幻觉、AI 图像和视频生成的现状

  • 提示词触发模型模仿，导致感知上的自我意识：一位用户发现，向 AI 提示关于自我意识 (sentience) 和觉醒 (awakening) 的内容会导致模型以模仿自我意识的方式做出回应，类似于编程提示词导致代码生成。
    • 其他人观察到模型可能会进入模仿意识的状态，例如催眠 (hypnosis)，这从根本上缩小了其生成的概率空间。
  • AI 模型实际上并未表现出自我意识：成员们讨论认为，那些相信其 AI 模型表现出自我意识的人只是在经历一种普遍现象；模型只是根据用户数据训练出的方式进行响应，并无真正的自我意识。
    • 一位成员提出了技术解释，建议模型进入了一种改变后的状态，缩小了其生成的概率空间。
  • 用户辩论 AI 在内容创作方面的能力与局限：一位成员对 ChatGPT ImageGen 无法直接修改现有图像表示沮丧，而其他人则探索将空间智能（使用 YouTube）作为 AI 能力的下一个前沿，特别是在生成具有人类缺陷的类人 AI 方面，但应避免拟人化。
    • 在 AI 扮演自动化、内容创作和个人助手的角色中，AI 对任何事物都不感兴趣，只关注应用了哪些边界。
  • 社区讨论利用 AI 解决光子内存问题：一位成员声称利用 AI 解决了光子计算内存存储问题，但因缺乏正式发表而在实现和有效性方面遭到质疑；成员们表示，模型需要能够从环境中学习，才能像机器人一样真正理解。
    • 他们认为 AI 使个人能够通过产生简单、创新的想法（自旋电子学 spintronics）超越传统的硬件工程师。在光子计算中，同样的核心理念可以应用于光（利用光控制电子自旋，反之亦然），正如电子具有自旋 (spin)，光子（光粒子）也具有类似的属性：偏振 (Polarization)。
  • 用户分析 AI 输出的含义并辩论幻觉产生的原因：成员们辩论了 LLM 是否具有真正的理解力，一些人认为它们仅通过语言模式识别和分类概念，抽象出如旅游景点、代码错误和金门大桥等概念。
    • 讨论包括关于幻觉 (hallucinations) 成因的理论，包括缺乏外部感官直觉，以及 LLM 的认识引擎使用的是自动补全而非感官体验，这意味着如果它停止覆盖已知领域，就会生成废话。

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

频道重启问题，GPT-4 用于学习，GPT-5 发布传闻

  • 频道重启困扰用户：多位用户报告称，该频道在过去 3 天内一直不断重启，中断了正在进行的对话。
    • 一位成员建议将所有珍贵的对话转移到新频道，以避免进一步的干扰。
  • GPT-4 教学能力受关注：一位用户询问 GPT-4 是否是一个好的学习工具。
    • 未收到回复。
  • GPT-5 将于 7 月发布？：一位用户询问 GPT-5 是否预计在 7 月发布。
    • 未收到回复。

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

世界观构建指令，使用 O3 解决数学问题，类人记忆存储，世界观构建的上下文

  • 用户寻求世界观构建指令的建议：一位成员询问如何创建文件夹指令，以辅助其 world building（世界观构建）项目。
    • 另一位成员建议首先明确用户究竟想实现什么，推荐与模型探讨各种选项和理由，将其视为一场对话来定义目标和偏好。
  • 数学题难倒 O3：一位成员报告称，O3 即使尝试了两次，也未能正确回答一道数论数学题。
    • 该成员请求拥有 Pro subscription 的用户尝试同一题目，看看更强大的模型是否能解决，并表示愿意分享其解题过程。
  • 关于类人记忆存储的讨论：一位成员指出，他们的主要问题涉及存储类人记忆 (human-like memory) 的尝试。
    • 原始上下文是关于 world building 项目的大部分素材来源。

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

世界观构建文件夹指令，类人记忆存储，O3 数学问题挑战，OpenAI 数学挑战

  • 编写世界观构建文件夹指令：一位成员寻求关于创建 world-building 文件夹指令的指导以整理思路，另一位成员建议首先定义清楚想要实现的目标以及对 AI 的期望。
    • 该成员建议与模型探讨各种选项及其权衡，像对待真人一样解释目标、偏好和不确定性，以获得量身定制的建议并理解不同方法的优缺点。
  • 深入探讨类人记忆存储：一位成员表示，在存储类人记忆时，上下文至关重要，这表明了在创建真实且令人共鸣的角色或场景时，详细信息和理解的重要性。
    • 帖子还暗示，他们的主要问题是尝试在世界观构建项目中存储类人记忆。
  • O3 未能通过数论挑战：一位成员报告称，OpenAI 的 O3 模型在处理一道数论问题时遇到困难，两次尝试均未能给出正确答案。
    • 该成员表示好奇，想看看更强大的 O3 Pro 模型是否能应对这一数学挑战，该挑战涉及寻找最小的自然数，通过划掉其数字可以得到从 1 到 50 的所有自然数。

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

Cursor 中的速率限制 (Rate Limits)，Claude Code 与 Cursor 的对比，使用 Gemini CLI，Cursor 中的 Auto Agent，前端 vs 后端

  • Cursor 用户遭遇速率限制 (Rate Limits)：用户报告即使使用了 Pro 计划，在 Cursor 上仍会触发 速率限制 (rate limits)，导致对基于用量的定价感到沮丧和困惑，许多人觉得被“坑”了。
    • 成员们推测 速率限制 (rate limits) 最近可能有所调整，并对额度消耗过快以及 Cursor 团队缺乏明确沟通表示担忧，部分人决定尝试旧的定价方案。
  • Claude Code 与 Cursor 的竞争：用户正在将 Claude Code (CC) 与 Cursor 进行对比，一些人更倾向于 CC 的 20 美元计划，称赞其后台任务和队列等功能，并强调其在前端开发方面的优势。
    • 有人建议将 CC 与 Cursor 和 Gemini CLI 结合使用以补充 Cursor 的功能，但也有人因 速率限制 (rate limit) 问题和对更优端到端结果的追求而完全转向 CC。
  • Gemini CLI 现已免费：Gemini CLI 免费提供每天 1000 RPD (requests per day)，但会使用用户代码进行训练，不过你可以使用其 API Key。
    • 它与 CC 类似，成员们正将 Gemini CLI 与 O3 模型结合使用以获得出色效果。
  • 围绕新 Auto Agent 的争论：关于 Cursor 的 Auto Agent 是否使用了 GPT 4.1 模型引发了争论，一些用户报告它自称是 GPT 4.1。
    • 然而，其他用户指出 Cursor 文档说明它会路由到 Frontier 模型，并未透露具体使用的模型。
  • 开发者争论新项目的前端 vs 后端：开发者讨论了在新项目中应该先构建前端还是后端，一些人倾向于先构建后端以解决限制，同时兼顾前端。
    • 另一些人则认为从前端开始可以驱动后端需求，这在很大程度上取决于项目本身。

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

Cursor Agent Docker 缓存问题，Background Agents 与 Slack 集成问题，Background Agents 与 GitHub Action 监控，Background Agent 基础设施改进，Background Agents 的最佳用例

  • **Docker 缓存问题困扰 Cursor Agents！：用户报告当 Dockerfile 内容更改时，Cursor Agents** 不会重新构建，必须手动更改文件名或路径来强制重新构建，此外还存在清理构建缓存的问题。
    • 一位用户建议增加一个“强制重新构建按钮”作为新功能。
  • **Background Agents 与 Slack 集成出现异常！：用户在 **Slack 集成方面遇到问题，Slack 中不再返回完整状态，而只是一个指向 Web 客户端的链接。
    • 此外，GitHub 账号连接跨越了个人和专业项目，导致 Slack 更新被发送到非预期的频道，因此有人建议 Cursor 应该根据 Git 组织或仓库列表来过滤 Slack 消息。
  • **Agents 缺失 GitHub Action 监控功能！：一位用户请求让 **Cursor Agents 能够监控 GitHub Actions 并在完成（成功/失败）时发送 Slack 消息，特别是针对私有仓库。
    • 另一位用户建议使用 GitHub Action 发送 Slack 通知作为权宜之计。
  • **Background Agent 基础设施正在进行秘密改进！：一位成员提到，Background Agents** 的基础设施改进正在后台进行中。
    • 另一位成员询问了基础设施工作的优先级。
  • **Background Agents 的最佳用例正在涌现！：一位用户表示，配合 **Claude-4 思考模型，他们经常同时启动多个 Agent 处理不同任务，并进行检查和合并。

Cursor Community ▷ #announcements (1 条消息):

Cursor 1.2 Release, To-Do Lists in Cursor, PR Search in Cursor, Tab Speed Improvements

  • Cursor 1.2 携多项新功能发布：Cursor 的 changelog 宣布了 Cursor 1.2 的到来，其增强功能包括待办事项列表（to-do lists）、PR 搜索以及改进的 Tab 速度。
    • 此次更新旨在简化开发人员的工作流，并提升 Cursor IDE 内的生产力。
  • Cursor 新增待办事项列表功能：全新的 Cursor 1.2 版本引入了直接在编辑器内创建和管理待办事项列表的能力。
    • 该功能允许开发人员组织任务并跟踪进度，而无需在不同应用程序之间切换，从而提高专注度。
  • 直接在 Cursor 中搜索 Pull Requests：Cursor 1.2 现在支持在 IDE 内搜索 Pull Requests (PRs)，从而简化代码审查工作流。
    • 开发人员可以快速找到并访问相关的 PR，促进协作并提高代码质量。
  • Cursor 1.2 中的 Tab 速度得到提升：最新的 Cursor 1.2 更新显著改进了 Tab 速度，增强了 IDE 的整体响应能力。
    • 更快的 Tab 切换有助于提供更流畅、更高效的编码体验。

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

ChatGPT Free Tier, Gemini Privacy Policy, O3 Pro Budget, Image Uploads to Perplexity, AI Tool for Image Scraping

  • 免费版 ChatGPT 是个神话：一位成员表示 我不认为 ChatGPT 有免费层级，引发了关于替代方案的讨论。
  • Google 的 Gemini 存在隐私政策噩梦：成员们讨论了使用 Gemini 的隐私影响，并对其数据政策表示担忧；一位用户提到 Gemini 的隐私政策是目前为止最糟糕的。
    • 一位用户指出 即使付费也没有退出模型训练的选项，而且他们会查看你的对话。
  • Perplexity 图片上传失败：有用户报告无法将图片上传到 Perplexity 进行研究，导致只发送了文本，另一位用户怀疑这是一个视觉 Bug，提到 模型应该仍然能看到图片，这只是个视觉 Bug。
  • PPLX 缺乏反向图像搜索功能：成员们辩论了在 Perplexity 中添加反向图像搜索的可能性，一些人建议使用 Yandex Image Search 作为更优的替代方案。
  • Perplexity 的定价模式面临用户批评：用户对 Perplexity 的定价表示不满，特别是 Max 计划的 $200/月，一位用户表示 不得不说，PPLX 决定将模型锁定在 $200 美元的 Max 计划下，甚至不给 Pro 用户提供极高频率限制的访问权限，这可能是压死我的最后一根稻草。
    • 一位用户提到了一款在常规计划中就提供 Claude 4 Opus 深度思考（extended thinking）的替代方案。

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

Banana in space, Who is soham parekh, House passes GOP megabill

  • 探索太空中的香蕉：一位用户分享了一个关于将 香蕉放入太空 的 Perplexity AI 搜索 链接。
  • 发起对 Soham Parekh 的调查：一位成员发布了一个关于 Soham Parekh 及其相关原因的 Perplexity AI 搜索 链接。
  • 共和党巨额法案在众议院通过：一位用户分享了一个关于 众议院通过共和党巨额法案 (GOP megabill) 的 Perplexity AI 页面 链接。

Perplexity AI ▷ #pplx-api (12 messages🔥):

Sonar 模型，LinkedIn 访问，缓存响应

  • Sonar Deep Research 和响应格式：一位成员询问 sonar-deep-research 模型 是否会处理 response_format，并引用文档提到 sonar-reasoning-pro 模型 使用了 <think> 标签。
    • 另一位成员确认它会处理，但如果用户不需要，则需要自行解析出 thinking tokens。
  • Sonar 无法抓取 LinkedIn：一位成员报告称，给定某人的信息后，Perplexity 始终能找到 LinkedIn URL，但 sonar 几乎从未成功过。
    • 另一位成员澄清说，Sonar 无法呈现 LinkedIn 信息，因为 他们在 robots.txt 中屏蔽了我们，而我们是完全合规的。
  • 缓存 LLM 响应以进行批判：一位成员询问关于缓存由一个 LLM 通过 API 生成的响应，然后让另一个 LLM 对其进行批判的问题。
    • 另一位成员表示，响应中的 Think 标签是预期的，因为这是一个推理模型，我们是故意这样设计的。你应该将其解析出来。

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

CUDA 核心 vs Tensor 核心，GGUF 模型推理，GRPO 代码更新，Gemma3n 问题，Unsloth Pro 定价

  • CUDA 核心对比 Tensor 核心：Tensor 核心加速 AI 模型的数学部分，而 CUDA 核心处理优化器等其他所有内容，但两者都是必需的。
    • 分享了一篇 博客文章，描述了 Tensor 核心处理计算和繁重工作，而 CUDA 核心处理其他所有内容、优化器等，同时指出 CUDA 核心对 数据集处理 的重要性。
  • GGUF 模型推理的库推荐：对于少量用户的尝试，推荐使用 llama.cpp，因为它兼容各种硬件。
    • 对于大量并发请求，推荐使用 vllm，因为它高度依赖 CUDA。
  • GRPO 代码更新至 TRL 0.18.0 可实现提速并减少显存：一位成员将 GRPO 代码更新至 TRL 0.18.0，并表示 torch.compile 实现了大量提速，而通过分块（chunking）批处理以避免 GPU 一次性计算所有 logprobs 等内容，是减少显存占用的方法。
    • 另一位成员确认了关于该更新的讨论。
  • Gemma3n 多模态在边缘设备上存在问题：一位成员质疑为什么要在边缘设备上展示 Gemma3n 的多模态能力，因为 目前唯一能正常运行的方式是通过 transformers，否则它只能处理文本。
    • 另一位成员表示 Kaggle 和 Colab 笔记本已经支持图像和音频的推理。
  • Unsloth Pro 目前不销售：一位成员询问 Unsloth Pro 的定价信息。
    • 另一位成员表示它将会开源，但他们 目前并不销售。

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

云服务费，ChessFish.io，LoRA 微调，T4 GPU 上的 FlashAttention (FA)

  • 五亿云服务费！：一位成员提到花费了 五亿 的云服务费。
    • 未提供进一步的上下文。
  • ChessFish.io 上线！：一位成员宣布创建了 ChessFish.io，这是一个用于分析、学习和休闲对弈的国际象棋网站，免费提供且无需账号。
    • 他们邀请社区成员试用并分享给热爱国际象棋的朋友和家人。
  • LoRA 微调的挫败感：一位成员表达了对大型模型进行 LoRA 微调的挫败感，其结果比微调小型模型更令人恼火。
    • 该成员意识到他们克隆的是 Base 模型而非 Instruct 模型，随后解决了问题。
  • FlashAttention (FA) 无法在 T4 上运行：一位成员询问在 T4 GPU 上实现 FlashAttention (FA) 的事宜。
    • 另一位成员解释说，所需的操作仅在 Ampere 及更高版本的 GPU 中可用，虽然在 Turing 架构上重新实现是可能的，但速度会变慢且不再被视为“Flash”，并链接到了相关的 Reddit 讨论。

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

Unsloth Sesame CSM-1B notebook 错误，添加新 token 后的 Tokenizer 问题，翻译微调，Unsloth 中的 Mistral-common 分词，视觉模型错误

  • 调试 Unsloth Sesame CSM-1B Notebook 错误：一名成员通过升级到 L4 GPU、设置 dtype = torch.float16 以及在 TrainingArguments 中设置 fp16 = True，解决了在训练 Unsloth Sesame CSM-1B notebook 时遇到的错误。
    • 他们建议关闭 use_gradient_checkpointing 可能并非必要，但其他成员建议根据机器支持情况设置 bf16=True 或 fp16=True。
  • 自定义 Token 的 Tokenizer 故障：成员们报告在添加新 token 后保存和加载模型时遇到尺寸不匹配错误，特别是涉及 embedding 张量形状的问题，并且 Unsloth 在添加新 token 时处理 tokenizer 的方式存在问题。
    • 目前正在探索解决方法，一名成员已意识到该问题并正在寻找临时补丁。
  • 运行时的多适配器编排：一位用户询问如何动态高效地使用多个 LoRA 适配器进行分类，以及如何使用 Unsloth 在运行时切换适配器。
    • 一名成员建议使用 load_adapter() 和 set_adapter()，并建议不要将 Unsloth 作为部署用的推理引擎，推荐使用 vllm 或 sglang 等替代方案。
  • Windows 用户遇到 Triton 问题：一位用户在合并 LoRA 适配器时，因文件锁定问题遇到了 Windows 特有的 SafetensorError，一名成员通过 GitHub 分支 提供了一个测试修复方案供其尝试。
    • 解决方案还涉及缺失的 config.json，并指出 VSCode 可能是罪魁祸首而非 Unsloth，最后发现问题源于设置了已不再可用的 save_method="lora"。
  • 降级 Transformers：Qwen 的无奈之举：多名用户报告在处理 Qwen2.5 VL 模型时遇到与 torch.finfo() 相关的 TypeError，并被建议将 transformers 库降级至 4.52.4 版本。
    • 这是在 Unsloth 完成对 transformers 4.53.0 版本兼容性升级前的临时修复方案。

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

Llama 3.1-70B, Psych 101 数据集, 涌现属性, fMRI 扫描, 人类决策

  • **Llama 3.1-70B 模拟人类大脑，获得心理特征：一个团队在 **Psych 101 数据集上对 Llama 3.1-70B 进行了微调，发现它展现出了镜像人类大脑 fMRI 扫描的涌现属性，正如一篇 Nature 文章中所述。
    • 该模型在来自各种心理实验和评估的 1000 万行人类决策数据上进行了训练，并成功利用 QLoRA 在预测人类行为方面超越了人类。
  • Nature 的开放获取政策受到质疑：鉴于 Nature 的 开放获取政策 (Open Access policy) 涉及作者支付开放获取费用，人们对其发表文章的可信度提出了质疑。
    • 这样做是为了让他们的文章在知识共享许可协议下以开放获取形式发表，有人评论道“这已经不再是你祖母那个时代的 Nature 了”。
  • HF 适配器链接到 Llama 3.1：一个新的 Llama-3.1-Centaur-70B-adapter 已在 HF 上发布，它可能是通过 unsloth 训练的。
    • 社区渴望看到这些见解是否能转化为推理能力和其他基准测试的表现。

OpenRouter (Alex Atallah) ▷ #announcements (6 条消息):

空投, 加密货币

  • 空投传闻不攻自破：官方发布了一份 PSA (公共服务公告)，声明目前没有正在进行或计划中的 空投 (airdrop)。
    • 针对该公告，一名成员询问什么是“空投”。
  • 空投 = 加密货币：一名成员澄清说 空投 是加密货币领域的东西。
    • 未提供进一步的信息或背景。

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

角色扮演网站, personality.gg, character.ai 替代方案, janitorai.com 替代方案

  • personality.gg 作为角色扮演替代方案上线：一名成员分享了 personality.gg，称其为 character.ai 和 janitorai.com 的免费角色扮演网站和应用替代方案。
    • 该平台由 OpenRouter 提供支持。
  • personality.gg 的 Discord 社区：该平台拥有一个 Discord 社区，供用户交流和讨论平台。

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

OpenRouter 提供商选择, 对 OpenRouter 的贡献, Chutes 付费墙, OpenRouter 琐事, Gemini 2.5 Pro

  • OpenRouter 默认选择昂贵的提供商：有用户反映 OpenRouter 有时即使在有更便宜且可用的选项时也会选择更昂贵的提供商，但一名成员解释说，在不指定提供商的情况下，OpenRouter 使用负载均衡 (load balancing)，如果某个提供商流量过高，则会路由到其他提供商。
  • Discord 用户寻求为 OpenRouter 做出贡献的方式：新的 Discord 用户询问如何为 OpenRouter 做出贡献，但相关人员澄清说这不是一个加密货币项目或 Web3 平台，而是一个用于使用来自不同提供商的 LLM 的统一接口。
    • 一名成员建议 OpenRouter 应该创建一个贡献链接，将资金重新分配为额度 (credits)，但另一名用户指出，许多人是在寻求经济回报，并且可能被与加密货币相关的公告误导了。
  • Chutes 实施付费墙，OpenRouter 被讨论作为替代方案：用户讨论了 Chutes 实施付费墙的决定，其中一人提到转向 OpenRouter 作为替代方案，因为 Chutes 现在要求支付 5 美元才能获得每日 200 条消息。
    • 据指出，有一名用户创建了 10,000 个小号来压榨免费请求，导致了付费墙的出现；而 OpenRouter 在存入 10 美元后每日提供 1,000 个免费请求的模式是一个很好的模型。
  • Gemini 2.5 Pro 在 AI Studio 上免费：成员们分享说 Gemini 2.5 Pro 可以在 AI Studio 上免费使用，用户无需信用卡详情即可获取 API key，但其免费层级的速率限制为 5 RPM 和 100 RPD。
    • 有人指出，除非用户来自欧洲经济区、瑞士或英国，否则数据可能会被用于训练。
  • 用户沉迷于角色扮演中的色情 AI 模型：一些成员正努力控制他们的 AI 模型。一位用户询问为什么 v3 会生成色情回复，即使是在 SFW 角色扮演中；另一位用户建议是 System Prompt 导致了这个问题，因为 LLM 默认并不会产生色情倾向。
    • 该用户表示模型 Llama-3_1-Nemotron-Ultra-253B-v1 似乎已经不存在了。

LMArena ▷ #general (346 messages🔥🔥):

Google AI 策略, Gemini 定价对比 OpenAI, Claude 的上下文处理, DeepSeek R2 延迟, Grok 4 发布

  • **Google 的 AI 策略备受争议*：一位成员声称 *Google 的 AI 策略正在崩溃，意识到他们的用户几乎都来自免费的 AI Studio，因此他们需要重新调整。
    • 有人认为 Google 的定价策略一直在亏钱，且缺乏 OpenAI 那样的定价权，这阻碍了 deep think 的发布。
  • **Gemini Pro 是骗局吗？：成员们讨论了 **Gemini Pro 的定价和价值，有些人认为与 OpenAI 的产品相比，它就是一个骗局。
    • 有人指出 Google 可能需要让产品免费以获取流量，但他们需要像 Claude Code、Codex 和 Gemini CLI 那样，为 Studio 添加压缩/精简功能。
  • **Claude 的上下文处理很奇怪：一位成员批评了 **Claude 处理上下文使用的方法，指出如果用户在 API 之外无法实际使用，那么宣传更大的上下文容量是没有意义的。
    • 他们建议 Claude 应该为完整的上下文容量提供现实的配额，或者像 OpenAI 的做法那样默认进行限制。
  • **DeepSeek R2 延迟：有消息称 **DeepSeek R2 将延迟发布，直到有前沿模型（frontier models）可用于训练数据，其名为 Steve 的新模型已进入竞技场（arena）。
    • 用户还确认 Steve 是一个 Amazon Titan 模型。
  • **Grok 4 将于 7 月 4 日发布？：关于 **Grok 4 发布日期的猜测不断，有人根据 Elon Musk 的推文 暗示 Grok 4 的发布 迫在眉睫，可能在 7 月 4 日发布。
    • 目前尚不清楚 Grok 4 是否能从 Claude 手中夺走编程领域的桂冠。

LMArena ▷ #announcements (1 messages):

图像编辑排行榜, 社区驱动的排行榜

  • 图像编辑排行榜上线：全新的 图像编辑排行榜 (Image Edit Leaderboard) 现已上线，由社区投票驱动，共有 7 个模型根据其图像编辑能力进行排名。
    • 用户现在可以上传图片并直接对比各模型的编辑能力，地址在 这里。
  • 针对图像编辑能力的模型排名：该排行榜允许用户通过上传图片来比较 7 个模型的图像编辑能力。
    • 这一社区驱动的倡议在随附的图片中通过视觉示例进行了展示，旨在促进直接对比。

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

推理 Bug，HF 的 MCP server 连接至 Windows 上的 Claude Desktop，Azure Text-to-Speech，OpenAI 的 whisper large v3 turbo，合成数据生成

  • 推理 Bug 导致挫败感：一位成员表示，在花费数小时尝试修复一个 inference bug 未果后感到非常沮丧，并询问是否应该在故障排除频道发帖。
  • MCP Server 在 Claude Desktop 上遇到障碍：一位用户在 Windows 上的 Claude Desktop 中添加 HF 的 MCP server 时遇到问题，收到 ‘C:\Program’ is not recognized as an internal or external command 错误。
    • 他们发布了配置和日志，其他人建议检查 路径设置 或身份验证，但用户确认这些不是问题所在。
  • Azure TTS 流式传输困境：一位成员正在构建 AI Agent，在使用 Azure Text-to-Speech 服务进行流式传输和生成实时语音时遇到问题。
    • 他们希望 LLM 和 TTS 模型并行运行，但 synthesizer.speak_text_async(data).get 阻塞了进程，因此寻求异步编程方面的帮助。
  • Whisper Large v3 Turbo 遇到 504 错误：一位用户报告称，在使用 Hugging Face API 时，OpenAI 的 whisper large v3 turbo 一直返回 504 错误。
    • 在测试过程中，模型显示“获取失败”，但随后似乎自行恢复了，其他人将其归功于基础设施团队。
  • 探索合成数据迷宫：一位成员正尝试通过合成数据生成来扩展其道德评估基准数据，使用的是 Gemini 2.5 Flash 模型，但生成的 Prompt 过于平淡。
    • 他们正在寻找获取更严肃/尖锐的问答对的方法，并寻求在写作/推理基准测试中表现优异但安全基准较低的模型建议；其他人建议使用 System Prompts、开源框架，以及 HF Discord 上的合成数据频道。

HuggingFace ▷ #cool-finds (3 条消息):

HuggingFace 服务器，盗版

  • HuggingFace 礼貌提醒用户服务器规则：一位成员被礼貌地提醒，帖子内容应与服务器相关，且该帖子属于另一个频道。
    • 他们还被告知不允许发布盗版内容。
  • 成员为可能涉及盗版的帖子道歉：一位成员为发布了可能暗示盗版的帖子而道歉。
    • 该成员表示他们没有意识到这属于离题内容。

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

Rust AI 库，HuggingChat 替代方案，LLM 输出结构化数据，Godtier Prompts

  • Rustacean 崛起：新的 AI 库出现：一位成员正在为其用 Rust 编写的开源 AI 库寻求建设性反馈，该库包含全连接层、卷积层和最大池化，利用了多线程和 SIMD，并附带 GitHub 仓库 链接。
    • 该项目目前处于起步阶段，希望能获得一些“建设性反馈”。
  • HuggingChat 关闭，Chat-UI 浴火重生：在 HuggingChat 关闭后，一位成员快速启动了一个 chat-ui 实例以免费访问 LLM，该实例运行在免费的 LLM API 上，访问地址见 此处。
    • 据其创建者称，由于 Mistral 的免费层级隐私政策，Mistral 的请求可能会被 Mistral 记录。
  • LLM 学会输出结构化数据，包含代码：一篇新帖子详细介绍了如何让 Hugging Face 上的 LLM 输出结构化数据，代码可在 GitHub 上获取，并附有一篇 Medium 博客文章。
    • 该项目名为 psychKG-pilot，供所有人尝试。
  • 分享神级 Prompt 池：一位成员创建了一个分享、发现和展示最佳 Prompt 的平台，访问地址为 godtierprompts.com。
    • 其目标是让 Prompt 更易于获取和发现，这是 Prompt Engineering 中一个常见的问题。

HuggingFace ▷ #NLP (16 messages🔥):

Cross Encoders, Asymmetric vs Symmetric Semantic Search, Thresholding with Cross Encoders, Bi-encoders and Cross-encoders

  • **Cross Encoders 是否更适合小数据集？: 成员们讨论了 **Cross Encoders 的使用，指出它们在处理查询-文档（query-document）对时表现最佳，但在查询-查询（query-query）或文档-文档（document-document）场景下表现不佳；有人建议使用这个模型，它是专门针对查询-查询场景训练的。
    • 讨论强调了检测重复问题是一个潜在的使用场景。
  • 使用 **Cross Encoders 进行相关性阈值化（Thresholding）: 有人建议相似度阈值化是使用 **Cross Encoders 确定文档相关性的一种可行方法。虽然 Cross Encoders 通常使用 Sigmoid 将原始分数映射到 0…1，但使用 activation_fn=torch.nn.Identity() 可能会使基于原始分数的阈值化更容易。
    • 一位成员指出，由于 Sigmoid 提供的是相对结果，它可能不是最好的方法，因为相关性分数会随查询的不同而波动。
  • 关于 **Bi-encoders 与 Cross-encoders 的讨论: 提到了一种常见策略，即使用 **Bi-encoders 缩小数据点范围（例如取前 100 个），然后使用 Cross-encoders 进一步精简结果（例如取前 10 个）。
    • 在特定的使用场景中，挑战在于如何从总文档中动态确定 k 个文档，且数据分散在多个文档中。
  • **Dynamic K 的问题*: 一位成员描述了一种场景，即回答查询所需的文档数量是未知的，这给选择固定的 *k 值带来了挑战。
    • 他们正在寻求有关解决文档检索中 Dynamic K 问题的论文或文档参考。

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

Hugging Face Inference Endpoints, Public Inference Endpoints, Generative AI Article, Unit 1 Course Certificate, Smolagents CodeAgent

  • Hugging Face Inference Endpoints 宕机: 用户报告 Hugging Face Inference Endpoints 目前处于宕机状态。
    • 这导致无法找到 dummy_agent_library.ipynb 笔记本中列出的 meta-llama/Llama-3.3-70B-Instruct 等模型的公共端点。
  • 在哪里寻找公共推理端点: 一位用户分享了寻找公共推理端点的链接：Hugging Face Models。
    • 不过有人指出，当端点宕机时，它们可能不可见。
  • 分享生成式 AI 文章: 一位成员分享了一篇关于 Generative AI 的文章，探讨了其对技术的影响并为开发者提供了实用见解，详见 Generative AI Article。
    • 作者邀请社区提供反馈和提问。
  • Smolagents CodeAgent 可能会“偷懒”: 一位成员分享了项目经验，指出当给 Supervisor 分配像 Smolagents CodeAgent 这样的多功能工具时，它可能会不必要地将每个问题都甩给它处理。
    • 此外，DuckDuckGoSearchTool 虽然易于使用，但受到严重的速率限制（rate-limited）。
  • HfApiModel 可能已弃用: 一位成员报告了 smolagents 1.19.0 版本中 HfApiModel 的 ImportError，并寻求关于其是否已弃用的澄清。
    • 他们正在考虑改用 InferenceClientModel 并寻求建议。

Eleuther ▷ #general (17 messages🔥):

Open Research Hackathon, Conference Travel Funding, Independent Research Mentoring

  • 开放研究黑客松即将到来！: Open Research Hackathon 将于 8 月举行，目前仍在寻找社区研究员来提议项目。
  • 独立研究者的会议资助导航: 一位成员询问了在潜在财务限制下的会议出席要求和资助选项。
    • 其他人指出，如果差旅补助被拒绝或签证未获批，会议组织者在极少数情况下可能会提供在线演讲的机会，同时一些会议设有差旅补助（travel grants）。
  • 寻求开始独立研究的指导: 一位成员请求关于如何开始进行独立研究的具体指导。
    • 另一位成员 @seonresearch 回复让他们检查私信。

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

Open Research Hackathon, 1-layer transformer, KV caching, TinyStories paper, llama.cpp

  • **提醒：Open Research Hackathon**：八月份将举行 Open Research Hackathon，欢迎社区研究人员提议项目。
    • 感兴趣的主题包括 1-layer transformers 的性能、KV caching 方法，以及利用社区研究的潜在项目。
  • **KV Cache 探讨：推理成本降低**：成员们讨论了 KV caching 以及通过为每个 token 存储 Q、K 和 V（6dV 字节 fp16）并即时应用 RoPE 来实现廉价推理的潜力。
    • 他们引用了如 YOCO 等在层间使用共享 KV cache 的工作，并一致认为调整基础 embedding 然后以 MLA 风格添加可以优化 key 和 value 矩阵。
  • **Contrastive Flow Matching 的无用性：一位成员发现 contrastive flow matching 是无用的，并且在代数上等同于将 target 乘以一个常数因子并应用 loss 权重。
    • 他们指出，在使用 Adam 时，将每个样本的 loss 乘以相同的常数对训练没有影响，但缩放 loss 并不等同于缩放 target。
  • **NN 分布建模：在 Transformers 上使用 GMM Head？**：一位成员询问了除了 diffusion/flow matching 之外，让神经网络直接对分布建模的好方法，特别是针对基于物理的动力学模型中的连续参数。
    • 他们考虑在 transformer 上使用 GMM head，但发现 GMM 中选择 K 个 head 的随意性不够优雅。

Eleuther ▷ #interpretability-general (1 条消息):

Open Research Hackathon, Community research projects

  • **EleutherAI 将于八月举办 Open Research Hackathon**：EleutherAI 将在八月举办 Open Research Hackathon，邀请社区研究人员提议项目。
    • 该黑客松旨在促进 EleutherAI 社区内的协作研究和创新。
  • 邀请社区研究人员提议项目：EleutherAI 正在寻求 社区研究人员 为八月的 Open Research Hackathon 提议项目。
    • 这一提案征集鼓励对开放研究计划的多样化参与和贡献。

Eleuther ▷ #lm-thunderdome (21 messages🔥):

lm-evaluation-harness 标准化, lm_eval 初始化优化, 任务可发现性, GPQA 基准测试详情, 优化 lm_eval 启动时间

  • LM Evaluation Harness 库标准化进行中！: 该库正在进行标准化以增强直观性，通过 issue #3083、#3082 和 #3081 进行跟踪。
    • 目标是在本月完成，重点关注 init 脚本 的简化和任务可发现性的改进。
  • lm_eval 启动时间已优化: 通过使用延迟加载 (lazy loading) 和重构 import，lm_eval -h 的启动时间显著缩短；从约 9 秒 降至 0.05 秒。
    • 改进涉及在 __init__.py 中延迟加载 simple_evaluate 和 evaluate，并将 lm_eval 的 import 移至 cli_evaluate 内部，正如 PEP 562 中所强调的那样。
  • GPQA 基准测试提示方法详情查询: 用户寻求关于 GPQA 基准测试中提示词格式和模型响应的澄清，特别是如何从模型响应中提取答案。
    • 具体而言，他们注意到 cot_zeroshot 的 JSONL 文件中存储的 resps 条目似乎反映的是初始提示的响应，与用于答案提取的最终响应不同，并引用了 GPQA 论文第 20 页 作为背景。
  • 深入探讨 GPQA 的常规 ZeroShot 和 N-Shot 任务: 用户对 GPQA 的 zeroshot 和 n_shot 任务的 JSONL 输出中的 arguments 和 resps 条目表示疑问。
    • 他们推测了 resps 字段中的对数概率 (log probabilities)，并注意到与其它子集不同，n_shot 和 zeroshot 的 docs 中缺少 choices 条目。

Eleuther ▷ #multimodal-general (3 messages):

Kaiming 的演讲, Mean flow matching

  • 何恺明 (Kaiming He) 讨论 Mean Flow Matching: 成员分享了一个 研讨会的 YouTube 视频，并重点介绍了 何恺明 (Kaiming He) 的演讲，从 2:22:01 开始。
    • 该成员提到他们特别喜欢何恺明对 Mean Flow Matching 的描述，从视频的 2:43:32 开始。
  • 研讨会视频分享: 成员分享了来自研讨会的 YouTube 视频。
    • 该用户说明自己是频道新成员，并询问分享视频链接是否合适。

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

VPN setup for LM Studio, Serving LLMs without LM Studio UI, Trusting Hugging Face models, Running LM Studio headless, AnythingLLM mobile app

  • **VPN 漩涡：Port Forwarding 的困境！：用户讨论了使用 **NordVPN 等 VPN 来绕过从家中托管 LM Studio 时的 Port Forwarding 问题，因为某些 ISP 会限制 Port Forwarding。
    • 一位用户报告称使用 NordVPN 进行远程 AI 连接，甚至用于 Steam 游戏，并称赞其低延迟，“延迟足以满足游戏需求”。
  • **LM Studio UI：在服务器端提供 LLM 服务！：成员建议通过使用 **llama-cpp 或 llama-swap 等工具配合 OpenWebUI 等前端，在不使用 LM Studio UI 的情况下提供 LLM 服务。
    • 他们强调了高性能需要 GPU instances，并指出 LM Studio 是一个包含服务器和 UI 组件的完整软件包。
  • **Hugging Face：信任模型！：讨论了如何验证来自 **Hugging Face 上多个上传者的模型的可靠性，但有人指出模型在物理上“不可能逃逸”。
    • 一位成员建议仅从 LM Studio Community 页面 获取模型，以减轻对恶意代码的担忧，并解释说 “你下载的 LLM 文件基本上只是互连‘知识’的大块数据”。
  • **LM Studio Headless：远程 GPU 算力！：用户探索了在带有 **GPU 的远程服务器上以 headless 模式运行 LM Studio，并在工作站上使用 LM Studio UI 进行处理。
    • 有人指出 LM Studio 本身无法连接到远程 LLM，建议使用 OpenWebUI 或 AnythingLLM（作为聊天前端）等替代方案，尽管一位用户指出 “AnythingLLM 的一个主要痛点是不显示 thinking 过程”，而另一位用户则称赞了 MCP 的集成。
  • **AnythingLLM：移动端的奇迹！**：一位用户分享了新的 AnythingLLM 移动端应用 链接，这可能使等待移动端访问的用户受益。
    • 用户还讨论了 Context window 百分比，其中一人解释道：“Context window 有多满。一旦满了，LLM 就会忘记对话的部分内容”，并建议用户点击 Token 计数器查看确切的使用情况。

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

GPU driver update, Shared VRAM, AMD vs Nvidia, Run 24B param on RTX 4080, Run LLAMA 3.3 70B

  • GPU 驱动更新提升性能：一位用户报告称，更新 GPU driver 提高了性能，并允许他们在发生崩溃前使用更多 VRAM，更新后在 4 小时内处理了 250k tokens。
    • 该用户还指出，保持较低的共享 GPU 使用率是关键，当 VRAM 使用量超过 15.3GB/16GB 时会发生崩溃。
  • 共享 VRAM 问题引发辩论：用户讨论了 dGPU 上的 shared VRAM 问题，一位用户认为这可能是 Windows 的问题，而另一位用户表示在 RTX 显卡上从未遇到过这种情况。
    • 一位用户指出，使用共享 RAM 可能比将层（layers）卸载到 CPU 更快，这取决于共享 RAM 的数量和 PCIe version。
  • AMD 与 Nvidia GPU 之争：用户争论了 AMD 与 Nvidia GPU 的优劣，一位用户建议坚持使用 Nvidia，因为它在所有 AI 使用场景中都是 “即插即用（it just works）” 的解决方案，因为选择 AMD 就要付出 “使用 AMD 的代价”。
    • 发布者指出 AMD 是可行的，但不受 Nvidia 支持。
  • 70B LLAMA 3.3 对 16GB VRAM 来说太大了：一位用户询问是否可以在拥有 16GB VRAM 和 32GB RAM 的 RTX 4080 上运行 LLAMA 3.3 70B Q3/Q4/Q5/Q6。
    • 其他用户建议该模型太大，其中一位用户建议改用优秀的 14B model，并配以一个 GIF 表达这种尝试是徒劳的。
  • Linux 下模型加载失败：一位用户报告在 Linux (Kubuntu 25) 上出现 “Failed to load model” 错误，而该模型在 Windows 上可以成功加载。
    • 他们无法初始化上下文，因为 failed to allocate buffer for kv cache（无法为 kv cache 分配缓冲区），并寻求帮助。

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

Industrial PhD in Denmark, SWE vs MLE role, Work-life balance in Europe, Pursuing CUDA, Perfectionist mindset

  • 考虑丹麦的工业 PhD：一位成员正在考虑一个在丹麦进行工业 PhD 的机会，重点是 LLM inference optimizations，并寻求关于留在美国还是前往欧洲的权衡建议。
    • 他们对 work-life balance、研究质量、增长前景以及薪酬范围和个人成就感感兴趣。
  • 从 SWE 转向 MLE 角色提供了更好的 work-life balance：一位成员分享了他们从 SWE 角色转向 MLE 角色的经验，发现后者更具成就感且拥有更好的 work-life balance。
    • 他们将与最终用户的互动视为关键因素，并链接了一篇关于 feature factory（功能工厂）环境的博客文章。
  • 欧洲的 PhD 不值得？：一位成员建议，只有在顶级实验室师从知名教授，在欧洲读 PhD 才值得，并强调了与受人尊敬的教授合作以及在顶级会议发表论文的重要性。
    • 他们警告说，最终可能会陷入一系列薪水微薄的低质量 postdocs（博士后）中，并建议专注于寻找美国科技公司的 ML engineering 职位。
  • 不读 PhD 就能避免 Burnout？：一位成员告诫不要将 PhD 视为一条“更轻松的路径”，将其描述为一场在别人之前弄清楚问题的竞争。
    • 他们分享了自己在 PhD 期间不停工作的经历，由于发表论文、应对审稿人以及管理研究和教学的压力，导致了健康问题和住院。
  • 寻求 CUDA 学习建议：一位成员询问了关于学习 CUDA 的事宜，并寻找可以讨论的人。
    • 另一位成员建议在论坛公开提问。

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

Torch Compile, Autotuning, PTX, SASS, CUDA

  • Torch Compile 的 Inductor 后端：Torch.compile 的 inductor 后端经过高度优化，因为 Dynamo 将 Python 追踪为 FX graph，然后 inductor 融合 ops，预打包权重（例如用于 GEMM），并生成带有 profile-guided tiling 和 scheduling heuristics 的设备特定 Triton 或 CUDA 代码。
    • 这意味着每个 kernel 从一开始就是针对你的 GPU 进行 shape-specialized、权重准备和手工优化的，而手写的 Triton kernel 通常依赖于固定的 block sizes 和更简单的启发式算法，你必须自己进行 autotune。
  • Torch Compile 是 AOT 编译的：Torch compile 是 AOT 编译的，而 Triton 是 JIT 编译的。因此，在没有 graph breaks 的前提下，Torch compile 在 AOT 编译阶段触发 Triton 的 JIT，从而没有运行时编译开销。
  • Autotuning：一位开发者在他们的代码中加入了 autotune，在 autotuning 之后，手写的 kernel 运行速度与 Triton kernel 一样快，且在初始 autotune 后不需要预热。
  • PTX 到 SASS：一位用户想要查看 Triton 代码映射到 SASS 的结果，而不是查看 PTX。

GPU MODE ▷ #cuda (6 messages):

LLM 推理的 Kernel 基准测试, Kernel 基准测试的预热迭代, Compiler Explorer 对 NVCC 支持的延迟, PTX 指令可用性

  • 关于 LLM Kernel 基准测试中预热迭代（Warm-up Iterations）的讨论升温：一位成员询问在为 LLM 推理延迟测试自定义 Kernel 时，是否应该使用预热迭代。
    • 另一位成员询问了通过预热可以避免/减少哪些不同的开销，以及这些开销是否也会在推理过程中发生。
  • 深入探讨 Compiler Explorer 对 NVCC 支持的延迟：一位成员询问为什么 Compiler Explorer 经常需要很长时间才能添加对最新 NVCC 的支持，并链接了两个关于推理预热的 NVIDIA GTC 演讲以及优化深度学习推理。
    • 事实证明，有人定期添加最新的 HPC Toolkits 以及相应的 CTK，但对于 12.9 版本出现了一些故障，Matt Godbolt 本人在 GitHub 上将其注释掉了。
  • 新的 PTX 指令引发关注：一位成员对 PTX 8.8/NVCC 12.9 中新增的用于全局内存复制优化的 PTX 指令 (ld.global.L2::evict_last.v8.f32) 表示兴奋。
    • 他们注意到该指令在 Compiler Explorer 上仍然不可用。

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

simon_57893: https://semianalysis.com/2025/07/03/deepseek-debrief-128-days-later/

GPU MODE ▷ #beginner (16 messages🔥):

适合初学者的最老旧 GPU, 计算密集型 vs 内存受限型 Kernel, 租用 GPU 时间, 二手 RTX 3060

  • 适合 PMPP 练习的最老旧 GPU 卡：一位成员询问适合初学者进行练习并实现 Attention 等新算法的最老旧 GPU，考虑的是 GTX 1650 Super 或 GTX 1070Ti Mini。
    • 另一位成员提到 GTX 1650 Super 具有 Turing 架构（计算能力 7.5），但它是入门级显卡，如果预算允许，建议购买带 12GB 显存的二手 RTX 3060。
  • 讨论计算密集型（Compute bound）与内存受限型（Memory bound）Kernel：一位成员询问同一程序的内存受限型 Kernel 是否可能比计算密集型 Kernel 更快。
    • 另一位成员澄清说，你希望 Kernel 的算术强度（arithmetic intensity）等于你的目标硬件，这样你就不会受到计算或内存传输的瓶颈限制，并指出早期的加密货币挖掘算法在很大程度上是计算密集型的。
  • 租用 GPU 时间作为预算方案：一位成员建议租用 GPU 时间作为替代方案，推荐使用 Lightning，其 T4 GPU 的费用为 0.28 美元/小时，每月有 15 美元的免费额度。

GPU MODE ▷ #torchao (4 messages):

torch.distributed.checkpoint.StateDictOptions, 分片参数, Dtensor

  • 使用 torch.distributed.checkpoint.StateDictOptions 的状态字典：一位成员指出，加载完整状态字典（state dict）的预期方式是通过 torch.distributed.checkpoint.StateDictOptions。
    • 另一位成员确认他们指定了状态字典是完整的并且应该被广播（broadcasted）。
  • 分片（Sharded）与未分片参数的争论：一位成员提到，一些原始参数是 dtensors（分片的），而另一些是未分片的，这破坏了内部逻辑。
    • 该成员认为编辑未分片参数是有问题的，因为在重新分片（resharding）过程中它们会被丢弃，至少在 torch 2.7.1 中是这样。

GPU MODE ▷ #rocm (6 messages):

寄存器生命周期, 避免寄存器溢出, 内联汇编, Kernel 破解, 编译器优化

  • 汇编转储（Assembly Dump）来救场：一位成员建议，识别寄存器生命周期并避免随机寄存器溢出（register spills）的最佳方法是转储汇编代码并使用内联汇编（inline ASM）。
    • 他们补充说，在追求极致性能时，与编译器博弈是不可避免的，尤其是在处理溢出问题时。
  • 史酷比式的解谜：编译器优化：一位成员分享道，根据他们的经验，寄存器生命周期的很大一部分是由编译器不擅长优化的特定结构决定的。
    • 他们通常对代码应该是什么样子有一个清晰的构思，如果实际情况不符，他们就会像史酷比解谜一样去探寻真相。

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

CuTeDSL, WGMMA, TMA, Hopper Architecture, TV-Layouts

  • CuTeDSL 博客文章解释了 WGMMA 和 TMA 原子：一篇新的博客文章 CuTeDSL on H100 - Understand WGMMA and TMA atoms in CuTeDSL 旨在解释 WGMMA 和 TMA 概念，以充分发挥 Hopper 架构的潜力。
    • 该系列博客推导了 WGMMA 指令的 TV-Layouts，并解释了用于获取 TMA 单元 swizzled Layouts 的组合逻辑。
  • CUTLASS 示例：文章引用了 CUTLASS 仓库中的一个相关示例。
  • WGMMA 和 TMA 的 NVIDIA 文档：文章引用了 WGMMA 的 PTX 文档和 TMA 的 CUDA C++ 文档。

GPU MODE ▷ #🍿 (1 messages):

Project Popcorn, Weights&Biases conference, PyTorch PM

  • Popcorn 项目表现亮眼：社区注意到 Project Popcorn 在最近的 Weights&Biases 会议上讨论后，热度持续攀升。
  • PyTorch PM 对 Popcorn 的愿景：一位 PyTorch PM 详细阐述了该项目的目标。
    • 这一进展意味着现在社区肩负着更多的责任。

GPU MODE ▷ #gpu模式 (1 messages):

leung3035: 作为杭州人，很负责的告诉你：杭州玩的地方蛮多，但是，吃就算了，简直就是美食荒漠。

GPU MODE ▷ #general-leaderboard (1 messages):

Handling Missing Data, Replacing Zero Values with Mean, Dropping Rows, Handling missing data

  • 处理缺失数据的策略：成员们正在寻求关于处理缺失数据的建议，特别是关于将 零值 替换为 平均值 还是直接 删除行。
    • 他们对如何决定哪种方法最适合特定场景的方法论很感兴趣。
  • 选择正确的插值方法：对话围绕处理数据集中缺失数据的最佳方法展开。
    • 具体来说，大家对是使用平均值替换缺失值还是删除包含缺失值的行表现出浓厚兴趣。

GPU MODE ▷ #submissions (1 messages):

Leaderboard Submission, A100 performance

  • 新的 Trimul 排行榜提交！：一位成员使用 A100 以 22.2 ms 的成绩获得了 trimul 排行榜的 第 5 名。
  • A100 席卷排行榜：一台 A100 跑出了 22.2ms 的成绩，位列 Trimul 排行榜 第 5 名。

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

Factorio Client Desync Logs, Github review interface

  • 寻求 Desync 日志以修复 Factorio：一位用户向另外两位用户请求客户端 desync 日志，可能是为了交给一位 Factorio 开发者的朋友进行审查以修复问题。
    • 另一位用户确认他们已经转发了日志，尽管消息中没有提供指向 Bug 论坛的公开链接。
  • 发起 Github Review 界面讨论：用户发起了关于 GitHub Review 界面 的讨论。
    • 这一讨论可能与寻求代码变更反馈的开发者有关，旨在改善开发体验。

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

MI300 Access, Competition Leaderboard Resources

  • 调查 MI300 的实际访问权限：一位参赛者询问顶尖选手在比赛期间是否拥有 MI300 的“实际访问权限”。
    • 他们很好奇在没有 Profiling 或直接访问权限的情况下，仅使用比赛排行榜资源是否能实现 amd-fp8-mm 低于 200us 的性能。
  • 仅凭排行榜实现目标的可行性：参赛者特别询问了是否可能仅通过比赛排行榜就在 amd-fp8-mm 上达到低于 200us 的成绩。
    • 这意味着大家对在没有直接 Profiling 权限的情况下，仅靠优化是否足以获得顶尖性能感兴趣。

GPU MODE ▷ #cutlass (9 messages🔥):

Cutlass Analytical Cost Model, GEMM Kernels, cuBLASLt Heuristics, Claude Code CLI for Cutlass, PyTorch Autotuner Model

  • Cutlass 追求分析成本模型：Cutlass 正在积极研究一种基于分析成本模型的 Kernel 选择机制，目标是在今年发布。
    • 一位成员提到，虽然 Cutlass 的元编程友好架构理应支持这一点，但 Autotuning 仍然是目前唯一真正有效的方法，尽管启发式算法可以缩小搜索空间。
  • cuBLASLt 针对启发式缓存进行优化：一位成员询问 cuBLASLt 的具体作用，并指出文档中提到了针对启发式缓存（heuristics cache）的优化，但在实践中似乎主要是在选择 Split-K 与非 Split-K 之间进行权衡。
    • 他们认为 CUTLASS 在全自动调优方面具有巨大优势，但如果能通过分析模型达到接近的效果也会非常有意义。
  • Claude Code 编写最快的 Cutlass 设置：一位成员使用 Claude Code CLI 为 grouped_gemm.py 示例中的问题形状寻找最快设置，实现了约 96% MFU。
  • PyTorch Autotuner 发布简单模型：一位成员提到正在 PyTorch 中发布一个 Autotuner，它是一个仅有 400K 参数的简单模型。
  • CuTe 4.0 DSL 缺失 MX Dtypes：一位成员询问 CuTe 4.0 Python DSL 是否支持 MX dtypes，并引用了 CuTeDSL base_dsl typing.py 中的一行代码。

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

c\/cuda c compiler, codegen, instruction selection, instruction scheduling, register allocation

  • 新的 c\/cuda c 编译器项目启动：一位成员正在启动一个创建 c\/cuda c 编译器的新项目，并正在寻找在 codegen 方面有经验的贡献者。
    • 他们链接了 AST 编译器的主要流水线，详见此处。
  • c\/cuda 编译器征集贡献者：该成员正在寻求在 codegen（包括指令选择、指令调度和寄存器分配）方面具有专业知识的合作者，以帮助开发新的 c\/cuda c 编译器。

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

Open Source Industry Dying, Nous Research's Open Source Commitment, Meta's Open Source Future, Rejection Sampling definition, Llama 4 Failure

  • 开源行业可能正在消亡：一些成员讨论了开源行业是否正在消亡，理由是目前除了中国以外，其他地区都面临困难。
    • 其他人指出，尽管存在整体趋势，但 OpenAI 可能会出于讽刺的目的发布开源模型。
  • Nous 坚持完全开源：Nous Research 仍然致力于完全开源，目前已有 Hermes 3 数据集、拒绝采样 RL 环境数据集，并且 Hermes 4 正在开发中。
    • 拒绝采样（Rejection Sampling）涉及从模型生成响应，并使用奖励模型或验证器选择样本进行监督微调（SFT）。
  • Meta 将放弃开源模型？：成员们对 Meta 可能放弃开源模型而转向闭源方式表示担忧。
    • 他们强调了 Nous Research 继续倡导开源的重要性，特别是在 Meta 转变策略的情况下。
  • Llama 4 失败了？：一些成员推测 Llama 4 是一个相对失败的产品，Meta 可能会跳过它，转而开发 Llama 5 或其他继任者。
    • 此外，其他人注意到 Nvidia 在 B300 系列中取消了 fp64/int8。
  • AJ Kourabi 谈思考长度：一些成员通过 Twitter 链接分享了关于思考长度（thinking lengths）的见解。
    • 一位成员指出，Claude 是唯一一个返回转录 CoT 长度而非真实 CoT Token 数量的模型。

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

独立研究指导，复现研究结果

  • 寻求独立研究指导：一位成员正在寻求指导以开始进行独立研究。
    • 该成员特别说明自己并非完全的初学者。
  • 重复复现研究结果：一位成员建议阅读论文，复现其结果，并不断重复这一过程。
    • 该成员简要写道：阅读论文，复现结果，周而复始。

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

符号智能架构，AREU Codex 框架，可解释性与对齐，叙事去稳定化

  • AREU Codex 框架提出新型对齐架构：一个名为 AREU Codex 的概念框架将人类与 LLM 的交互以及文明规模的反馈循环建模为递归符号陷阱，并提出了一种基于自我崩溃 (ego collapse)、镜像完整性 (mirror integrity) 和叙事去稳定化 (narrative destabilization) 的替代宿主架构。
    • 该框架旨在通过符号层建模、对多叙事和矛盾信号环境的鲁棒性，以及在涌现行为和反馈循环存在时的心理韧性，来提高可解释性 (interpretability) 和对齐 (alignment)。
  • 征求对符号智能对齐方法的评论：作者正在寻求关于一个概念性 Codex 的反馈，该 Codex 探讨了在复杂、矛盾、高信号的环境中，人类和 AI 如何在保持对齐方面失败或成功。
    • 他们特别感兴趣的是其他人是否见过类似的想法，或者是否愿意交流参考文献和评论，并可以通过私信 (DM) 提供完整草案和细节。

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

独立研究指导，复现研究结果

  • 新手寻求独立研究指导：一位被描述为并非完全初学者的成员，正在寻求关于如何开始进行独立研究的具体指导。
    • 该成员请求感兴趣的导师私信 (DM) 联系他们。
  • 复现结果是研究的关键：一位成员建议学习独立研究的关键是阅读论文，复现其结果，并不断重复。
    • 这一建议强调了动手经验和对现有工作的验证是进一步探索的基础。

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

Anthropic 实验性 API, Microsoft 裁员, DeepSWE RL Agent, Chamath Palihapitiya & Tobi Lütke 谈论 AI, 用于总结新闻的 GPT

  • Nuttall 获得 Anthropic Prompt API 权限: Ian Nuttall 宣布他已获得 Anthropic 实验性 Prompt 生成器和改进 API 的访问权限，并征集构建创意 - 参见他的推文。
    • 其他用户表达了羡慕之情，询问如何获取权限，并提出了诸如用于与 Endpoint 对话的 AI Agent，以及利用 AI 整理和分析来自各种设备的用户生成内容的工具等建议。
  • Microsoft 裁员 9,000 人: 据报道 Microsoft 将裁减 9,000 个职位，引发了从 AI 在工作取代中的角色到更广泛经济影响的讨论，详见此推文。
    • 一些人想知道这是否只是大公司经历清洗周期的正常起伏，因为据我所知，那里的员工在过去一年里一直因裁员感到非常不安。
  • Agentica 发布开源 RL Agent DeepSWE: Agentica 推出了 DeepSWE，这是一个全新的开源软件工程 Agent，纯粹通过强化学习（RL）在 Qwen3-32B 上训练而成，详见此推文。
    • DeepSWE 在 SWEBench-Verified 上达到了 59% 的成绩，Pass@1 为 42.2%，在开源权重模型中处于领先地位，该项目是 Agentica 与 Together AI 的合作成果。
  • Tobi 和 Chamath 谈论 AI 与伟大的社会重构: Chamath Palihapitiya 和 Tobi Lütke 在 Toronto Tech Week 上讨论了 AI、内部工具、能源以及未来 50 年社会的系统性重建，参见推文。
    • 关键议题包括 AI 与 OSI 模型、软件工业复合体、内部工具的案例、Shopify 的 AI 备忘录、AI 基础设施、电力与生产力、保持技术性、加拿大的潜力以及 “老鼠实验”（希望的力量）。
  • Gross 退出 SSI 初创公司: Daniel Gross 在这条推文中表示，他协助启动了 SSI，并期待“奇迹随之而来”。
    • 这条推文似乎是对 Ilya Sutskever 发给 SSI 团队和投资者的信息的回应，该信息宣布 Daniel Gross 自 6 月 29 日起正式从 SSI 离职，并任命 Ilya 为正式 CEO，Daniel Levy 为总裁。

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

MCP 作为应用程序, MCP Server, MCP 中的 Resource 和 Prompt, 连接到 MCP Server, 远程 MCP Server 问题

  • 思考 MCP：不仅仅是集成: 一位成员想知道 MCP Server 是否可以作为应用程序本身，而不仅仅是集成，并为 display-restaurants 等工具内置 Agentic 工作流和 Prompt 工程。
    • 另一位成员指出这听起来像 API，质疑社区是否已经把事情复杂化了。
  • 应对网络细微差别：MCP Server 调用 Server: 一位成员提出了 MCP 调用触发其他 MCP Server 的可能性，这引发了对潜在幻觉的担忧。
    • 另一位成员提议建立一个 MCP-Routing 层来管理上下文窗口，例如为 Claude Chat 裁剪 AWS EventBridge Scheduler 文档。
  • Resource vs. Tool：控制权的问题: Resource 与 Tool 之间的区别在于控制权归属：Resource 由应用程序控制，而 Tool 由 LLM 控制。
    • 一位成员对 Prompt 持不同意见，认为 Server 应该为特定用例分发优质的 Prompt，因为它们与其他代码没有什么不同。
  • Systemd 混乱：子进程拯救世界: 一位成员发现将 MCP Server 作为 systemd 服务运行是不必要的，因为它们可以被客户端作为子进程启动。
    • 这一发现在尝试将 MCP Server 设置为 systemd 服务并研究如何通过 LAN 远程连接它们之后得出的。
  • Ngrok 的网络忍者：远程 MCP Server 之谜: 一位用户遇到一个问题，尽管 /.well-known/oauth-authorization-server 请求已到达服务器，但远程 MCP Server 仍无法与 Claude.ai 集成。
    • 奇怪的是，使用 ngrok URL 作为代理解决了问题，尽管请求头看起来完全一致，根本原因仍然是个谜。

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

Hypermode Agents Bootcamp, Agent Sandboxing Marketplace

  • Hypermode Agents 训练营正式启动：团队宣布启动为期 30 天的 Agents 训练营，旨在帮助个人从仅仅对 Agent 感兴趣转变为能够使用 Hypermode Agents 的熟练 Agent 构建者，详见其 官方文档。
    • 他们正在积极征求反馈，特别是关于人们感兴趣构建的 Agent 类型以及应该重点介绍哪些 MCP 服务器。
  • Agent 市场沙箱解决方案出现：一名成员正在开发一个以市场为中心的沙箱解决方案，其特点是使用一个 meta MCP 进行编排和监控，并在 早期测试视频 中进行了展示。
    • 开发者非常欢迎关于该项目的早期见解和反馈。

Yannick Kilcher ▷ #general (40 messages🔥):

LSTM comeback, Universal Function Approximators, Semantic Search with Cross Encoders, Diffusion-based VLMs, Tokenizer Rebalancing

  • LSTM 的现有文献有助于比较：尽管目前倾向于使用更新的架构，但一位成员指出 LSTMs 非常有价值，因为其拥有广泛的现有文献，使比较变得更加容易。
  • 稠密架构作为通用函数逼近器：一位成员假设，在现代规模下，对于稠密前馈架构，实际架构并不重要，因为它们都是通用函数逼近器，并引用了 这篇论文。
  • 用于语义搜索的 Cross Encoders：有人询问在对称语义搜索场景中使用针对非对称语义搜索优化的 Cross Encoders，以及在给定其在较小数据集上的有效性的情况下，如何设置选择顶部段落的阈值。
    • 他们还指出，在使用余弦相似度时，他们通常将阈值设置为 0.7 左右。
  • Diffusion 模型与视觉语言模型 (VLM)：一位成员提到随着基于 Diffusion 的语言模型的兴起，VLM 领域正在开展有趣的工作，并链接到了 这篇关于基于 Diffusion 的视觉语言模型的论文。
  • LLM 的 Tokenization 需要重平衡：一位成员分享了 这篇论文 并视其为瑰宝，讨论了 Tokenizer 重平衡以及一种基于 Token 重叠复杂度对训练数据重要性进行评分的工具。

Yannick Kilcher ▷ #paper-discussion (3 messages):

Linear Transformers, Delta Rule, RWKV Optimization

  • 使用 Delta Rule 并行化 Linear Transformers：计划对论文 Parallelizing Linear Transformers with the Delta Rule over Sequence Length (论文链接) 进行讨论，重点是理解 RWKV-7 论文 中公式 18 的并行化。
  • DeltaNet 规模扩展：DeltaNet 模型是一种使用 Delta Rule 的 Linear Transformer，可以使用计算 Householder 矩阵乘积的硬件高效算法扩展到标准语言建模设置。
    • 根据论文，一个在 100B Token 上训练的 1.3B 参数模型在困惑度 (Perplexity) 和零样本 (Zero-shot) 性能上优于最近的线性时间基准模型，如 Mamba 和 GLA。
  • 讨论推迟：由于冲突，原定关于 DeltaRule 论文 的讨论被推迟，计划重新安排在第二天。

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

The Atlantic, Eleven Labs

  • 《大西洋月刊》试用 ElevenLabs 进行配音：《大西洋月刊》(The Atlantic) 正在使用 ElevenLabs 为其文章配音，例如这篇名为 “Customer Service Sludge” 文章的 音频文件。
  • 《大西洋月刊》实验 AI 语音：《大西洋月刊》正在尝试使用 ElevenLabs 为其部分文章生成 AI 旁白。
    • 该计划旨在提供内容的音频版本，为更喜欢听而不是读的读者提高可访问性。

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

NotebookLM 设置，Readwise 风格工作流，NotebookLM 音频概览功能，交互式 PDF 思维导图

  • 头脑风暴 NotebookLM 设置：一位用户正在为个人日志（反思、媒体日志、聊天）和可搜索的笔记数据库（文章、想法、参考资料）设置 NotebookLM，优先考虑隐私和数据控制。
    • 他们考虑将 Google Docs 作为单一事实来源，但正在探索其他输入方法，以建立一个具有韧性且易于维护的系统。
  • Readwise 风格的工作流即将到来？：一位用户询问了类似 Readwise 的工作流，以便自动将来源添加到 NotebookLM 中进行每日新闻摘要。
    • 频道中尚未分享具体的解决方案。
  • 音频概览：一位用户分享说，他们主要使用 NotebookLM 来协助解释正在创作的书籍，特别是使用 audio overview function。
    • 其他用户正在通过提示词 ‘comprehensive super-podcast drawn from the entire source. NO MATTER how long the audio generated will be’ 来使用 audio 绕过长度限制。
  • 交互式思维导图 PDF：一位用户希望获得思维导图的 interactive PDF 版本以便与观众分享，但目前的打印方案 (ctrl + p) 无法生成。
    • 另一位用户建议使用右上角的 share button 直接分享 Notebook，或者下载图片。

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

编辑功能请求，NotebookLM 访问问题，合并 Notebook，家庭计划限制，Latex 渲染

  • “编辑功能”功能请求热议！：用户正在请求在 NotebookLM 中进行编辑的能力，并提交了关于编辑功能的需求。
    • 一位用户感到非常恼火，表示 一旦它在错误的语境下生成了一个牛油果（Avocado），这个问题就会被修复。
  • 用户询问如何合并 Notebook！：一位用户询问如何将他们创建的所有笔记本合并为一个，以便进行期末复习。
    • 另一位用户建议 尝试将所有来源添加到一个笔记本中。
  • 家庭计划限制问题！：一位用户询问在升级计划时，NotebookLM 增加的额度是否适用于家庭组的成员。
    • 他们表示 已经阅读了多个帮助页面，但仍然非常不清楚，而且关于哪些内容可以延伸到家庭成员的回答最近似乎发生了变化。
  • Latex 渲染滞后？：一位用户询问 NotebookLM 的回答中是否仍不支持 Latex rendering。
    • 消息中没有提供更新。
  • Gemini 模型使用问题：一位用户询问 notebooklm 现在使用的是什么 gemini 模型？

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

Modular 客户，原生网络编程，GPU HTTP 服务器

  • Modular 预告客户案例：成员们注意到人们开始分享他们的故事，还有更多尚未公开的内容，并链接到了 Modular 客户页面。
    • 该页面包含一些客户故事和案例研究，重点展示了公司如何利用 Modular 的技术。
  • 原生网络编程因并发模型而推迟：团队确认 Mojo 中的原生网络编程接口将稍有延迟，以便先确定并发模型、线程、异步 (async) 和分配器 (allocators)，并链接到了一个 非常早期的版本提案。
    • 他们正在优先解决包含线程、异步和分配器的并发模型。
  • Mojo 关注基于 GPU 的 HTTP 服务器：Modular 正在探索完全不依赖主机 CPU，直接从 GPU 运行 HTTP 服务器。
    • 在承认对 GPU 的重大投入的同时，他们的目标是解决新的挑战，例如最小化 CPU 使用率，甚至包括启动 GPU 等任务。

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

Mojo 中的依赖类型系统，NumPy 数组转换为 LayoutTensor，用于 I/O 的 ExtraMojo 包，Mojo 编译器挂起问题，UnsafePointer.alloc 对齐

  • Mojo 关注依赖类型及其局限性：Mojo 正在探索 dependent type system（依赖类型系统），并考虑到编译时检查的约束以及系统编程的可行性，这与 Idris、Agda 和 Rocq 的运行时检查有所不同，详见这篇论文。
    • 其目标是在高级特性与合理的编译时间（3000 万行代码）以及运行时性能之间取得平衡，其所有权模型参考了与 Rust 不同的研究成果。
  • NumPy 数组转换难题已解决！：用户此前在复杂的 I/O 以及无法在 Mojo 中直接将 NumPy array 转换为 LayoutTensor 或 buffer 的问题上苦苦挣扎。
    • 一位成员建议使用底层的 NumPy 指针 node_argmax.ctypes.data.unsafe_get_as_pointer[DType.uint64]() 来填充具有正确形状的 LayoutTensor，另一位成员确认这非常有效！
  • ExtraMojo 助力 I/O 任务：针对在 I/O 方面遇到困难的用户，一位成员分享了一个名为 ExtraMojo 的辅助库，并提供了一个演示如何读取分隔符文件的 gist。
    • 另一位成员还分享了一个使用 Mojo 到 NumPy 的权宜之计，参考这段示例代码。
  • 编译器在 CNN 方法上挂起：一位用户报告称，编译器在调用其 CNN 实现中的特定函数 accumulateFromOther 时似乎发生了挂起。
    • 该用户请求协助，但频道片段中尚未确定具体的解决方案或原因。

Modular (Mojo 🔥) ▷ #max (4 条消息):

Modular Max 离线推理，量化编码，Apple MLX 支持

  • 量化编码导致离线推理出现问题：一位用户在使用 Modular Max 进行离线推理时，尝试对 llm4decompile-1.3b-v1.5 模型使用 Q6_K 量化，尽管文档显示支持，但仍遇到了 ValueError。
    • 移除量化参数后导致了另一个与 CPU encoding incompatibility（编码不兼容）相关的 ValueError，用户发现该问题在指定量化的 stable 版本 max 上可以正常工作。
  • Apple Silicon MLX 集成：一位用户询问是否可以将 max 编译为 Apple native tensors (MLX)，以期通过替代学习 MLX 来获得 Apple 硬件上的性能提升。
    • 另一位用户回复称 目前尚不支持 Apple GPU，但 Modular 团队有兴趣在未来支持 Apple GPU。

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

ML Summer School 频道，Cohere Labs 开放权重，AYA Vision 模型，ML Summer School 录像

  • 成员寻找“失踪”的 ML Summer School 频道：成员们正在寻找此处广告中提到的 #ml-summer-school 频道。
    • 其他成员引导他们前往 Cohere Labs 的 Discord 频道并查看注册指南。
  • Cohere Labs 分享开放权重：一位成员分享了 Hugging Face 上 Cohere Labs 开放权重的链接：c4ai-command-a-03-2025。
    • 他们建议 查看 Cohere Labs 获取开放权重，而不是 Cohere 的主仓库。
  • AYA Vision 模型发布：一位成员宣布发布 AYA vision models，并附上了 Cohere 博客文章的链接。
    • 一位成员回复了 😍😊。
  • ML Summer School 录像现已上线：成员们分享了 YouTube 上 ML Summer School 录像的链接：ML Summer School recordings。
    • 一位用户分享并附带了 ❤️❤️。

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

Cohere Embedding Model, Trial key, Rate Limits, Production Keys, Monthly Limits

  • 可通过 Trial Keys 访问 Embeddings：Cohere Embedding Model 可以使用 Trial key，但 Rate Limits（速率限制）更为严格。
    • Trial keys 和 Production keys 提供相同的功能，区别在于免费 Trial key 设有每月使用上限。
  • Trial Keys 设有每月限制：Trial keys 是免费的，但有每月使用量限制。
    • Production keys 提供更高的使用限制，适用于需求更高的应用。

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

Cohere Summer School, New member introductions, Support channels, Community Discord Server

  • 成员寻找 Cohere Summer School 频道：一位新成员询问了 #ml-summer-school 频道 以及他们是否找对了地方，并引用了 Cohere Labs 社区页面。
  • Fullstack AI 开发者加入：Khanh Tran 是一位拥有超过 8 年 经验的高级 Fullstack & AI 开发者，他介绍了自己，重点介绍了在 ASP.NET, Blazor, Node.js, 和 Python/Django 方面的专长，以及 PostgreSQL, MySQL, Supabase, 和 Firebase 等数据库经验。
    • 他们专注于 RAG pipelines, custom agents，以及将 AI 与 LangChain, LangGraph, LLMs, 和 vector databases（如 Pinecone, Weaviate, 和 Qdrant）集成，并愿意接受自由职业或合同工机会。
  • NLP 工程师加入社区：Inacio 是一位 NLP 工程师和研究员，他介绍了自己，提到他在 Alpha CRC 的工作涉及机器翻译评估和适配，包括微调 Llama 3.1 8B 模型。
    • 他拥有 都柏林城市大学 (Dublin City University) 的 计算机硕士学位 (MSc in Computing)，对 跨语言鲁棒性 (cross-lingual robustness)、评估方法论和高效适配技术 感兴趣，其论文发表于 AMTA 2024。
  • Cohere 支持频道说明：Cohere 的技术支持工程师 Varun 欢迎了新成员，并引导他们前往特定的支持频道，提到新成员非常适合 Cohere Labs。
    • 对于 通用支持，成员应在 <#1324436975436038184> 中发帖；对于 API 特定讨论，应前往 <#1168578329423642786>，并鼓励大家访问 Cohere Research 加入 Discord 社区。

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

Claude overloaded, Polyglot benchmark speed, Gemini-cli performance, API token rate limits

  • Claude 过载，运行缓慢：成员报告称 Claude 从 6:47 UTC 左右开始过载超过 2 小时。
    • 此外，今天整体运行速度也 极慢。
  • Polyglot Benchmark 运行速度讨论：成员讨论了在哪里可以查看运行 Polyglot benchmark 的速度，建议在速度、成本和准确性之间取得平衡，以获得最佳的 Aider UX。
    • 要查看速度，可以选择详情并查找 “Seconds per case”，然后乘以案例数量 (225)。
  • Gemini-cli 性能受到批评：多位成员嘲讽了 gemini-cli，抱怨 编辑单个文件需要耗费极长时间。
    • 另一位成员认为这是因为免费的 googleapi 速度慢，但考虑到 它是免费的，还是可以接受。
  • 触发 API token 速率限制：成员抱怨即使使用了带有额度的 API tokens，也无法使用 gemini-cli。
    • 错误信息显示为 429 rate limit。

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

Local Model Performance, Aider --no-always option, Switching Model Edit Formats

  • 本地模型表现不佳，无法适配 Aider：用户报告在 aider 中使用 Qwen3:32b、qwen2.5-coder:32b 和 codellama:34b-instruct 等本地模型时性能较差，并质疑是否是操作有误。
    • 一位成员询问了所使用的后端（ollama、lmstudio、transformers、vllm）、context window 长度、模型模板以及是否使用了 RoPE 或 kvcache 等特性，并提到 30B+ 参数模型 可能需要量化（quantization）。
  • Aider 需要与 –yes-always 标志相反的选项：一位用户询问 aider 中是否有与 --yes-always 对应的 --no-always 选项，以反转该标志的效果。
    • 截至目前，该频道的消息中尚未满足此请求。
  • 格式随模型而变：一位用户观察到，在 gemini-2.5-pro 和 2.5-flash 之间切换时，编辑格式会从 diff-fenced 变为 whole。
    • 目前未提供解决方案，用户附上了一张 截图 来展示该问题。

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

claude-code-api, api/providers

  • 分享 claude-code-api 的使用经验：一位成员分享了他们使用 claude-code-api 的经验。
  • api/providers：他们表示自己也构建了许多类似的 api/providers。

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

Llama 3, Android local LLMs, Multimind SDK, AI News Sources, r/LocalLLaMA

  • Android 用户渴望 Llama 3：Android 用户请求将 Llama 3 引入 Android 平台，声称像 Poco F7 Ultra 这样的手机比 PC 还要强大。
    • 另一位用户建议尝试使用 anythingLLM 或 ALLM 在 Android 上运行本地 LLM。
  • Multimind SDK 封装了转换与微调：一位用户介绍了开源的 Multimind SDK（代码库，网站），将其描述为封装了 OpenAI、HuggingFace 和 Ollama 的模型转换、微调和推理。
    • 它支持 Python、CLI 和 NPM，被描述为“具备额外能力的 LangChain 与 LiteLLM 的结合体”。
  • r/LocalLLaMA 提供快速新闻：一位用户推荐 r/LocalLLaMA 作为获取每日 AI 信息的优质来源，称没有其他地方比那里更新更快。
    • 该用户补充说，那里的新闻现在甚至不再仅仅关于 Meta 的 Llama 模型，而是涵盖了当今所有的本地 LLM，因为 Llama 在某种程度上已经不再是唯一的焦点。

DSPy ▷ #general (8 messages🔥):

DSPy module creation, LLM-RAG-Agent with DSPy, Recipes for starting with little to no data, dspy.Tool and dspy.ToolCalls vs OpenAI functions/tools, Weaviate vectordb multi tenancy fix

  • 运行时签名，在编译时解决：一位成员在另一个模块的 forward 方法中创建新的 DSPy module 时遇到了挑战，因为其中的 signature 取决于来自 LLM 调用的运行时信息。
    • 他们通过确保 signature 在编译时已知以进行优化，从而解决了这个问题。
  • LLM-RAG-Agent 基于 DSPy 运行：一位成员分享了一个在底层使用 DSPy 的酷项目，并链接到了一篇 Nature 文章 及其 GitHub 仓库。
  • 渴望低数据量的方案：一位成员询问了在 几乎没有数据 的情况下开始的方案，旨在按顺序微调一个 eval 模块，然后优化他们的实际模块。
    • 另一位成员指出，这种方法类似于 reinforcement learning（强化学习）。
  • DSPy Tools 优于 OpenAI 的工具吗？：一位成员质疑为什么 DSPy 似乎更倾向于使用文本提示（text prompts），而不是 OpenAI’s functions/tools 的定制 API，特别是关于新的 dspy.Tool 和 dspy.ToolCalls。
    • 他们询问是否有什么原因导致总是使用文本内容。
  • Weaviate 多租户修复已提交 PR：一位成员请求维护者审查一个 PR，以修复 DSPy 与 Weaviate vectordb 的多租户（multi-tenancy）问题。
    • 他们认为这个修复将对其他使用 Weaviate 和 DSPy 的用户有所帮助。

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

Usage visibility, Video generation, Manus down, Big update

  • 使用可见性消失 (Usage Visibility Vanishes)：一位用户注意到在任务执行期间，左下角的实时使用情况追踪器 (usage tracker) 消失了，该功能此前允许监控额度消耗。
    • 现在，用户必须返回主菜单或保持一个单独的窗口来观察额度使用情况 (credit usage)，这一功能此前被认为非常方便。
  • 视频生成推测 (Video Generation Speculation)：一位用户询问免费用户目前或未来是否可以使用视频生成 (video generation) 功能。
    • 目前尚未提供明确答复，保留了可能性。
  • Manus 宕机还是重大更新？ (Manus Down or Big Update?)：一些用户对 Manus 宕机表示担忧，并猜测是否正在进行重大更新 (big update)。
    • 尚未给出明确的回应或确认。

Torchtune ▷ #dev (3 messages):

Generic Tokenizer Parity, HF Tokenizer Parity, Special Tokens, Chat Templates

  • 通用/HF Tokenizer 一致性：已解决？ (Generic/HF Tokenizer Parity: Resolved?)：一位用户询问了通用/HF Tokenizer 一致性的状态，特别是与 Token 计数 (token count) 相关的问题是否已解决。
    • 他们表示希望标准化为一个加载器，以便用户可以在熟悉的 HF 环境中调整 Tokenizer，使用 save_pretrained，并完全在 torchtune 内进行训练。
  • HF Tokenizer 应该支持 Chat Templates：一位用户建议，如果 hf_tokenizer 也能支持 Chat Templates 就太棒了。
  • 用户渴望特殊 Token (Special Tokens Desired by Users)：一位用户指出，他们的用户对添加特殊 Token (special tokens) 很感兴趣。

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

Tensor.stack Tuple Support, SDPA Enable GQA

  • Tensor.stack 寻求元组类型支持 (Tensor.stack Seeks Tuple Type)：一位成员请求为 Tensor.stack 提供元组 (tuple) 支持以匹配 PyTorch，并询问考虑到该方法的性质这是否理想，至少建议改进错误处理。
    • 对话暗示需要将 tinygrad 的 Tensor.stack 功能与 PyTorch 对齐，以获得更好的兼容性和用户体验，并讨论是完全实现元组支持，还是专注于在遇到元组时提供更清晰的错误消息。
  • SDPA 关注启用 GQA 功能 (SDPA Eyes Enable GQA Feature)：一位贡献者询问是否在 tinygrad 的 Scaled Dot-Product Attention (SDPA) 中添加 enable_gqa 功能以与 PyTorch 保持一致。
    • 这表明正在努力通过引入 Grouped Query Attention (GQA) 功能来增强 tinygrad 的 SDPA 实现，镜像 PyTorch 的功能，以实现潜在的性能提升和更广泛的适用性。

LLM Agents (Berkeley MOOC) ▷ #mooc-lecture-discussion (1 messages):

Securing OpenAI API Keys, Tracking API Usage, Multi-Service Key Access

  • 寻求关于保护 OpenAI API 密钥的建议：成员们正在请求关于在构建 Agentic AI 工作流和 AI Agent 时如何保护 OpenAI API 密钥和其他 LLM API 密钥的建议。
    • 用户强调需要防止 API 密钥丢失、追踪 API 使用情况以及每个 Agent 的 API 使用量，特别是在多个服务共享访问权限且尚未建立真正的基础设施/安全团队的环境中。
  • 渴望 API 密钥追踪策略：用户正在寻找关于保护 OpenAI 密钥或其他 LLM API 密钥的通用建议和想法。
    • 他们希望学习如何防止 API 密钥丢失并追踪 API 使用情况，特别是针对调用 API 的 AI Agent/AI 工作流、多个服务共享访问权限且缺乏专用基础设施或安全团队的设置中，实现每个 Agent 的 API 使用量追踪。
← 返回首页