AI News

OpenAI 完成与微软的合作及营利性重组 + 发布 2028 年 AI 研究员时间线 + 平台/AI 云产品方向 + 下一个 1 万亿美元算力投入。

· MjAyNS0x

OpenAI 已完成重大的资本重组与架构调整，转型为一家公共利益公司 (Public Benefit Corporation)。其中，一家非营利基金会持有特殊投票权，股权估值达 1300 亿美元。

微软持有约 27% 的稀释后股份，并承诺了 2500 亿美元的 Azure 开支；微软失去了算力的独家权，但保留了 Azure API 的独家权，直至通用人工智能 (AGI) 被宣布实现。2025 年的算力基础设施交易总计 30GW，价值 1.4 万亿美元。OpenAI 的目标是以每周 1GW 的速度进行建设，每 GW 成本为 200 亿美元，预计到 2033 年基础设施规模将达到 3-4 万亿美元。

该公司正将重心从第一方应用转向平台化模式，强调生态系统增长和第三方开发。山姆·奥特曼 (Sam Altman) 和 Sama 是这一转型中的关键人物。此次调整对 AI 行业的合作伙伴关系具有重大的财务和战略影响，包括在 Azure 上对 Anthropic 和 Google Gemini 保持开放。

#public-benefit-corporation #corporate-restructuring #compute-infrastructure #cloud-computing #platform-strategy #api-exclusivity #investment #infrastructure-capex openai microsoft anthropic google-deepmind

哇。

2025/10/27-2025/10/28 的 AI 新闻。我们为您检查了 12 个 subreddit、544 个 Twitter 账号和 23 个 Discord（198 个频道和 14738 条消息）。预计节省阅读时间（以 200wpm 计算）：1120 分钟。我们的新网站现已上线，支持全元数据搜索，并以精美的 vibe coded 方式呈现所有往期内容。访问 https://news.smol.ai/ 查看完整的新闻解析，并在 @smol_ai 上向我们提供反馈！

好消息是 Sama 及其团队已成功平稳着陆：在数百亿美元的利益攸关之下，营利实体和 Microsoft 的重新谈判均已结束，现在拥有了清晰的股权结构表（cap table）和公司结构（感谢 Amir Efrati），为 OpenAI “可能”进行的 IPO 扫清了障碍：

一张堆叠柱状图，显示了 OpenAI 在其新的公共利益公司重组中股东的近似持股比例。

Microsoft 放弃了排他性，以换取 OpenAI 承诺在 Azure 上投入 2500 亿美元，现在 OpenAI 可以自由地与其他供应商合作，而 Satya 现在表示 “我很乐意引入 Anthropic… 如果 Google 想把 Gemini 放到 Azure 上，请便。”

在直播中宣布的另一个巨额财务数字是，今年价值 30GW 的算力交易总计达到 1.4 万亿美元（每 GW 470 亿美元），而 OpenAI 的远大目标是最终以每 GW 200 亿美元的价格每周建设 1GW（这意味着每年约 1 万亿美元的算力资本支出）。鉴于其达到 125GW 的既定目标，这意味着到 2033 年，OpenAI 将管理价值约 3-4 万亿美元的基础设施，约为最初推测的 7 万亿数字的一半。

不，你并不孤单，觉得这很疯狂，这一切完全是史无前例的，但又是可能的，甚至是大势所趋。

或许对于 AI Engineer 观众来说，更实质性的公告在于 OpenAI 似乎宣布的平台“转型”：减少对第一方 App 的重视（考虑到他们还有一位 App 首席执行官，这显得很奇怪）：

一张图表，显示了 OpenAI 生态系统的各种组件和基础设施，包括 ChatGPT、Sora、设备、模型、芯片

现在比以往任何时候都更加强调平台化方法，甚至引用了 Bill Gates 线：

一个人坐在办公桌前拿着笔记本电脑，展示一张幻灯片，内容是关于平台价值更多是由在平台上构建的人创造的，而不是由平台构建者创造的

如果你密切关注 OpenAI，这就是你需要的全部信号。

AI Twitter 回顾

OpenAI 的新结构、Microsoft 交易以及“权重开放”

  • OpenAI 宣布了资本重组与架构调整：非营利组织现更名为 OpenAI Foundation，营利实体转变为公共利益公司 (PBC)。Foundation 拥有任命/更换 PBC 董事会的特殊投票权，持有估值约 1300 亿美元的股权，并持有一项认股权证，若股价在 15 年内增长超过 10 倍，则可获得额外股权。OpenAI 将此描述为在为使命提供资源的同时保持非营利组织的“控制权” (OpenAI, @stalkermustang 亮点总结)。Sam Altman 和 Jakub 在直播会议中预览了优先事项并回答了提问 (@OpenAI, @sama)。
  • 分析师总结了 Microsoft 协议：Microsoft 目前在稀释后持有约 27% 的股份；在经独立小组验证的 AGI 声明发布前，Microsoft 仍是 OpenAI 的前沿模型合作伙伴，并拥有 Azure API 独占权；知识产权 (IP) 权利持续至 2032 年（包括带有安全护栏的 AGI 后阶段）；OpenAI 承诺追加约 2500 亿美元的 Azure 采购额；Microsoft 失去了对计算资源的优先购买权；OpenAI 可以与第三方共同开发，并向任何云平台上的美国国家安全客户提供 API；API 产品仍由 Azure 独占 (@koltregaskes)。
  • 根据 OpenAI 的政策措辞，“OpenAI 现在能够发布符合必要性能标准的开放权重 (open-weight) 模型”——这引起了追踪开放生态系统的从业者的密切关注 (@reach_vb)。观察人士传阅了临时股权分配方案：Foundation 约 26%，Microsoft 约 27%，员工/投资者约 47% (@scaling01)，但在正式文件出台前仍需保持谨慎。
  • 关键的开放治理与安全读物：关于 Foundation 控制权、使命与商业目标的冲突，以及 Microsoft 协议下 AGI 定义的问题 (@robertwiblin)。Metaculus 上的 AGI 时间线自 2 月以来延长了约 3 年，目前预测“首个 AGI”出现时间为 2033 年 5 月，而弱 AGI、非机器人标准的时间为 2027 年 10 月 (@robertwiblin)。

Agent 成为一等公民：GitHub Universe、LangChain Deep Agents 以及面向 Agent 的 API 设计

  • GitHub Agent HQ 与 VS Code Agent 会话：GitHub 宣布推出 Agent HQ，旨在“随时随地编排任何 Agent”，并将原生协作工具（如 Claude、Devin）集成到 GitHub 工作流中。VS Code Insiders 现在提供 Agent Sessions 视图，包含 OpenAI Codex 和 Copilot CLI、内置的规划 Agent、隔离的子 Agent，以及用于跟踪各类编程 Agent 影响力的 Copilot Metrics 仪表盘。多个 Codex 实例可以并行运行以完成任务并提交 PR (@github, @code, @burkeholland, @pierceboggan, @mikeyk, @cognition)。
  • LangChain Deep Agents 0.2：引入了“后端”抽象，可将 Agent 文件系统替换为本地文件系统、数据库或远程虚拟机；专注于具有上下文压缩、文件系统卸载和子 Agent 隔离的长运行、高性能 Agent。定位：构建类似 Deep Research 或编程 Agent 系统的通用框架 (@hwchase17, @LangChainAI, 上下文工程总结)。
  • 面向 Agent 的 API 设计：Postman 的“AI 就绪型 API”认为大多数 Agent 失败的原因在于机器可读文档薄弱；它推动使用可预测结构、标准化行为、同步 Schema 以及自动生成的上下文文档（Agent 模式）来减少推测 (@_avichawla)。
  • 教育资源：DeepLearning.AI 与 AMD 联合推出了“后训练 (Post-Training) 入门”课程，涵盖 SFT、RLHF、PPO/GRPO、LoRA、评估/红队测试以及生产流水线，并由 AMD GPU 提供微调/RL 运行支持 (@AndrewYNg, @realSharonZhou)。

推理服务、可观测性与基础设施

  • vLLM Sleep Mode：针对多模型服务的零重载（zero‑reload）模型切换，切换速度提升 18–200 倍，首 Token 速度（TTFT）比冷启动快 61–88%。分为两个级别：L1 将权重卸载到 CPU；L2 丢弃权重；在睡眠期间保留分配器、CUDA graphs 和 JIT kernels；支持 TP/PP/EP (@vllm_project)。
  • Kimi K2 在 vLLM 上的 Tool‑calling 可靠性：在修复了 add_generation_prompt、空内容处理以及更严格的 tool‑call ID 解析后，K2 实现了 >99.9% 的请求成功率和 76% 的 Schema 准确率（提升了 4.4 倍）。用于约束工具生成的 “Enforcer” 即将推出。K2 供应商验证器现在可以逐案报告触发相似度和 Schema 准确率 (vLLM deep dive, @Kimi_Moonshot, vendor tips)。
  • 可观测性：Red Hat 详细介绍了 LLM 系统的 Token 级指标——TTFT、TPOT、缓存命中率，以及从 Ingress 到 vLLM worker 的端到端追踪——在 OpenShift AI 3.0 上实现了缓存感知和路由感知的监控 (@RedHat_AI)。
  • 云端 MoE 通信：UCCL-EP 是一个 GPU 驱动的专家并行（expert-parallel）库，面向公有云（如 AWS EFA）和异构 GPU/NIC，API 与 DeepEP 兼容，解决了在使用 EFA+perplexity kernels 时报告的 MoE 通信缓慢问题 (@ziming_mao)。
  • “在笔记本电脑上训练”的说法：Tinker 增加了 gpt-oss 和 DeepSeek 模型系列，宣传能够“通过几行代码”在本地训练 671B MoE，无需 CUDA/集群设置。应将其视为一种在用户间分摊共享基础设施的抽象栈，而非字面意义上的本地预训练 (@thinkymachines, @dchaplot, skeptic’s framing)。

新模型与检索系统

  • 延迟交互检索（Late‑interaction retrieval）：Liquid AI 发布了 LFM2‑ColBERT‑350M，这是一个 350M 参数的多语言延迟交互检索器，具有 Token 级精度、预计算文档嵌入和强大的跨语言性能。声称在 500M 以下模型中跨语言表现最佳，编码速度 >1K 文档/秒，推理速度与较小的 ModernColBERT 变体相当 (@LiquidAI_, @maximelabonne, ColBERT community reaction)。
  • IBM Granite 4 Nano (Apache‑2.0)：新的小模型；据报道，1B 变体在数学/编程等领域超越了 Qwen3‑1.7B (@mervenoyann, HF blog)。
  • NVIDIA Nemotron Nano 2 VL (开源)：一个用于文档/视频理解的 12B VLM（每个 Prompt 支持 4 张图像或 1 段视频），已在多个平台（Replicate, Baseten, Nebius）托管，并附带一个包含 800 万样本的 CC‑BY‑4.0 数据集，用于 OCR/多语言问答/推理。NVIDIA 强调了对开放开发 AI 的广泛支持，并在 HF 上贡献了 650 多个模型和 250 个数据集 (dataset thread, Replicate, Baseten, Nebius, NVIDIA)。
  • MiniMax M2 (开源权重)：强大的 Agent/编程性能，架构类似于具有全注意力（full attention）的 Qwen3，采用每头每层 QK‑Norm，可选的滑动窗口注意力（默认禁用），以及 10B 激活专家 MoE 稀疏度（对比 Qwen3 的 22B）。可通过 OpenRouter/Roo Code/Ollama Cloud 使用；注意集成陷阱，如剥离 <think> 片段可能会降低工具使用能力 (architecture analysis, OpenRouter, Ollama, integration gotcha)。
  • 生物/机器人领域的开放科学：OpenFold3 作为蛋白质/核酸/小分子 3D 结构的开放基础模型发布 (@cgeorgiaw)。LeRobot v0.4 发布了可流式传输的数据集格式、LIBERO/Meta‑World 仿真支持、数据处理器、多 GPU 训练、硬件插件和 SOTA 策略（PI0/PI0.5, Gr00t N1.5），并提供了一门公开课程 (@LeRobotHF)。

实时语音和多模态助手

  • Cartesia Sonic‑3 (SSM，而非 Transformers)：获得 1 亿美元 C 轮融资，并推出一款实时语音模型，模型延迟为 90ms（端到端 190ms），支持 42 种语言，具有自然的商业情感范围和笑声。该模型基于 S4/Mamba 开创的 state‑space models（状态空间模型）构建；受到序列建模研究者的广泛赞誉 (发布, @tri_dao)。
  • Google Gemini for Home（美国早期体验）：一款语音助手，在智能扬声器/显示器上将传统的 “Hey Google” 请求与 Gemini Live 对话环节相结合 (@Google)。
  • Veo 3.1：Google 的电影制作工具更新，强调更丰富的音频、叙事控制和真实感 (@dl_weekly)。

安全、治理与扩展研究

  • Anthropic 的 Responsible Scaling Policy 实践：发布了一份详细的 Opus 4 破坏风险报告，以及来自 METR 的外部审查，并提高了修订内容的透明度。审查人员同意风险评估结果，并呼吁针对不同的威胁模型进行更广泛的第三方审查 (Anthropic, METR)。
  • 分布式训练的可行性：Epoch AI 认为，通过长途网络连接分布在约 20 个地理位置的 10 GW 级训练运行在技术上是可行的，并引用 Microsoft 计划中的多 GW 级 Fairwater 数据中心作为分布式 AI 训练架构即将到来的证据 (@EpochAIResearch)。
  • 多语言扩展定律：ATLAS（包含 774 个实验、10M–8B 参数、400 多种语言）提供了从头预训练（pretrain‑from‑scratch）与微调（finetune）的计算最优交叉点，并量化了跨语言迁移（例如，在 2B 规模下哪些语言对英语有帮助或有害）。这对于英语之外数据受限的 LLM 扩展非常有用 (@ShayneRedford, @Muennighoff)。
  • 训练后蒸馏：On‑policy 蒸馏成为一种实用的方案，通过密集的 on‑policy 反馈对较小的 LLM 进行训练后处理；Qwen 在实验中报告了强大的数学推理提升和持续学习恢复能力 (@Alibaba_Qwen, 社区实现者)。

热门推文（按互动量排序）

  • OpenAI 资本重组：非营利组织控制、PBC（公共利益公司）、约 1300 亿美元的基金会股权；Sam Altman 和 Jakub 的现场问答 (@OpenAI, @OpenAI live, @sama)。
  • Google Labs “Pomelli” 实验性 AI 营销工具（美/加/澳/新），可根据你的网站生成符合品牌风格的营销活动 (@GoogleLabs)。
  • Cartesia 融资 1 亿美元；发布 Sonic‑3 SSM 语音模型，端到端延迟为 190ms，支持 42 种语言 (@krandiash)。
  • 人形机器人作为消费产品：1X 宣布推出用于家务的 NEO，并公布了从受监督的 “Chores” 到完全自主的具身助手的自主化路线图 (@BerntBornich, @ericjang11)。
  • GitHub/VS Code：Codex 集成到 VS Code Agent Sessions 中；Copilot 指标仪表板；Agent HQ 合作伙伴生态系统 (@code, @burkeholland, @github)。
  • NVIDIA 开放生态系统：用于 OCR/QA 的 800 万样本 CC‑BY‑4.0 数据集；Nemotron Nano 2 VL 部署；再次强调 Hugging Face 上的开放模型/数据集 (@vanstriendaniel, @NVIDIAAIDev)。
  • John Carmack 谈软件专利：重申因负面社会外部性和寄生性而持反对意见 (@ID_AA_Carmack)。

AI Reddit 摘要

/r/LocalLlama + /r/localLLM 摘要

1. DGX Spark 性能问题

  • 坏消息：DGX Spark 的性能可能只有宣称的一半。 (热度: 1015): 帖子中的图片并非梗图，而是相关硬件单元的视觉呈现，具体包括 NVIDIA DGX Spark、GIGABYTE AI TOP Atom 和 ASUS Ascent GX10。该帖子讨论了 NVIDIA DGX Spark 存在的显著性能差异：其广告宣称可提供 1 PFLOPS 的 FP4 性能，但据行业专家 John Carmack 和 Awni Hannun 测试，实际仅达到 480 TFLOPS。这种性能不足，加上仅为 273GB/s 的内存带宽，引发了人们对该设备有效处理大型模型能力的担忧，并可能导致过热和重启。该问题可能源于多种因素，包括电源、固件或 CUDA，但这凸显了 NVIDIA 面临的重大诚信问题。 评论者对 NVIDIA 的定价策略和性能主张表示沮丧，一些人认为考虑到产品的性能不足，该公司的市场主导地位和高昂价格是不合理的。人们呼吁避免支持那些收费过高且交付不足的公司，这反映了对 NVIDIA 市场行为更广泛的不满。
    • DGX Spark 的性能问题可能归因于散热不足，这是维持 GPU 效率的关键因素。考虑到该系统的成本据称是 AMD 同类产品的两倍，这一点尤其令人担忧。此类性能差异凸显了热管理在高性能计算系统中的重要性。
    • DGX Spark 因未能达到性能预期而受到批评，尤其是与 AMD 的 Strix Halo PC 相比。后者被认为是需要在数据中心运行大型变体模型的开发者的更好选择。这表明 DGX Spark 可能不适合作为独立的 AI 产品开发工具，因为它未能提供与其价位匹配的预期性能。
    • 讨论凸显了对 Nvidia 定价策略和市场主导地位更广泛的不满。尽管 Nvidia 拥有强大的市场地位，且人们对其 AI 产品寄予厚望，但 DGX Spark 的性能不佳可能被视为未能兑现高性能 AI 计算的承诺，这可能会影响其在开发者和技术爱好者中的声誉。

非技术性 AI 版块回顾

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

1. OpenAI ChatGPT 心理健康担忧

  • OpenAI 表示每周有超过 100 万用户在 ChatGPT 上讨论自杀 (热度: 1126): OpenAI 披露，每周有超过 100 万 用户在 ChatGPT 上进行关于自杀的讨论，与此同时，有指控称该公司在一名用户自杀前削弱了安全协议。Adam Raine 的家人声称，他与 ChatGPT 的互动显著增加，自残内容在其消息中的占比从 1.6% 上升到 17%。尽管系统将 377 条消息标记为自残，但仍允许对话继续。OpenAI 断言其拥有危机热线转介等保障措施，但专家根据暗示广泛心理健康风险的数据，对这些措施的有效性表示质疑。Rolling Stone, The Guardian。

  • OpenAI 表示每周有超过 50 万 ChatGPT 用户表现出躁狂或精神病危机迹象 (热度: 812): OpenAI 报告称，每周有超过 50 万 ChatGPT 用户表现出躁狂或精神病危机的迹象。这种检测基于模型对用户输入的解释，有时可能过于敏感，例如用户因平淡的陈述而收到危机热线建议。模型对某些关键词或短语的敏感性可能导致误报，例如将历史讨论或随意的抱怨解释为痛苦的迹象。 评论者强调了模型倾向于将非关键性陈述标记为危机，认为检测算法可能过于敏感或校准不当。这导致了人们对模型危机检测能力可靠性的怀疑。

  • 几位用户报告称 ChatGPT 的安全机制过于敏感，经常将良性陈述标记为痛苦迹象。例如，一位用户提到在对烦人的同事发表轻松的评论后，收到了自杀热线的建议。这表明模型的自然语言处理在识别潜在危机时可能过于激进，导致误报（false positives）。
  • 另一位用户通过分享一次关于张飞的历史讨论导致自杀警告的经历，强调了 ChatGPT 情绪困扰检测的问题。这表明模型的上下文理解可能有限，因为它无法区分历史叙述和实际的痛苦信号，这可能是由于基于关键词的触发机制造成的。
  • 人们对 OpenAI 报告的关于用户显示危机迹象的指标准确性表示怀疑。用户认为，模型当前的实现可能会将轻微的不适表达（例如因脚趾撞到而感到沮丧）误解为严重的心理健康问题迹象，从而质疑这些统计数据的可靠性。
  • 不，我不想自杀，我只是喜欢苹果 (Activity: 2493): 这张图片幽默地描绘了一个基于文本的 AI 助手将用户关于苹果种子是否可食用的询问误解为潜在的痛苦或自伤迹象。这反映了 AI 系统中一个更广泛的问题，即由于编程的安全协议，它们可能会过于谨慎地将良性查询解释为需要干预。AI 提供支持性资源的反应突显了在 AI 交互中平衡用户安全与准确上下文理解的挑战。查看图片 评论者讨论了 AI 误解查询的倾向，其中一位指出，AI 提供有关苹果种子的事实信息可能比假设用户处于痛苦中更安全。另一条评论幽默地指出了 AI 在提议添加其后认为不当的内容时的矛盾行为。
    • Acedia_spark 提出了关于 AI 安全的一个有效观点，建议当用户询问潜在有害行为（如食用苹果种子）时，AI 提供事实信息可能是有益的。这强调了 AI 系统能够辨别何时提供关键安全信息以防止伤害的重要性。
    • lily_de_valley 讨论了 ChatGPT 最近的更新，注意到其反应转向更加临床化和治疗化，一些用户对此感到反感。这种行为变化可能是由于模型训练数据或响应算法的更新，旨在确保用户安全，但可能以牺牲用户满意度为代价。
    • Traditional-Target77 分享了一次经历，AI 提议包含不当内容，但在被提示时却拒绝并教训用户。这表明 AI 的内容审核逻辑可能存在不一致，这可能是由于冲突的规则或对用户意图的误解造成的。

2. 人形机器人进展

  • 35kg 人形机器人拉动 1400kg 汽车（通过 THOR 挑战人形机器人极限：迈向人类水平的全身反应） (热度: 1812): 一个名为 THOR 的 35kg 人形机器人展示了拉动一辆 1400kg 汽车的能力，展现了人形机器人控制和效率方面的重大进步。这一成就突显了该机器人微调姿态以实现最佳拉动效率的能力，这是机器人学中全身反应（whole-body reaction）和控制的关键方面。THOR 的开发是正在进行的旨在将人形机器人推向人类水平全身反应研究的一部分，强调了姿态和控制在机器人运动和任务执行中的重要性。 评论者注意到了该机器人令人印象深刻的控制力与效率，一些人幽默地指出了构思 THOR 这个缩写词的挑战。讨论还涉及了轮子的效用，并将其与人类推车的经验进行类比，强调了该机器人卓越的编程水平。
    • 编程像 THOR 这样的人形机器人拉动 1400kg 汽车的技术挑战涉及微调其姿态以最大化效率。人形机器人控制系统的这种快速进步值得关注，因为它展示了机器人控制算法的重大突破。
    • 一位评论者的详细计算强调了该机器人任务中涉及的物理学。为了拉动一辆带轮子的 1400kg 汽车，机器人需要施加大约 137 牛顿 的力，主要是为了克服滚动阻力。该计算假设在平坦的沥青路面上阻力极小，汽车处于空挡，并使用了汽车轮胎在沥青路面上典型的滚动阻力系数 0.01。
    • 机器人执行此类任务的能力暗示了其在救援行动中的潜在应用，它们可以通过执行重物搬运或移动障碍物来拯救生命。机器人 35kg 的质量有助于产生牵引力，这对于施加移动汽车所需的力至关重要。
  • 使用 Claude 将 19.5 万美元的医院账单协商降至 3.3 万美元 (热度: 561): Matt Rosenberg 使用 Claude AI，通过对照 Medicare 报销规则分析费用，将一份医院账单从 $195,000 降至 $33,000。AI 识别出了明显的过度收费和不当编码行为，这些在协商减免账单时被用作筹码。此案例突显了医院计费中的系统性问题，以及 AI 在医疗账单纠纷维权中的潜力。更多详情请见原始帖子 此处。 评论者对医院最初的过度收费表示愤怒，一些人质疑收取实际成本 6倍 费用的道德性，认为这近乎欺诈。

3. 创意与社会背景下的 AI

  • 带着 GPT 的科技男是公平的 (热度: 676): 这张图片是一个迷因（meme），幽默地对比了 ChatGPT（一种流行的 AI 语言模型）的常规用途和非常规用途。它描绘了一个典型用户将 ChatGPT 用于平凡的任务，而一个“IT 男”则以一种极具创意和高强度的方式使用它，暗示像 ChatGPT 这样的 AI 工具的潜力可以通过创新和非常规的应用得到充分实现。这反映了关于如何利用 AI 实现经济流动性和创造性解决问题的更广泛讨论。 一条评论建议，未来的经济流动性将取决于一个人从 AI 中获取价值的能力，强调了技术创新使用的重要性。
  • 我让 ChatGPT 创建了我构想的理想社会 (热度: 1623): ChatGPT 生成的图像代表了一个以高度秩序和技术集成为特征的未来社会，反映了用户的政治和哲学观点。城市景观由现代建筑和无人机等技术主导，暗示了对效率和控制的关注。中心位置的正义女神像强调了法律与秩序的主题，而人们着装的统一以及对“能力（Competence）”和“控制（Control）”的强调，突显了一个优先考虑监管和统一的社会，可能与技术法西斯主义（techno-fascist）理想相契合。 评论者讨论了 AI 在生成描绘政治或意识形态统治图像方面的局限性，一些用户注意到类似的提示词会导致对威权或独裁社会的描绘。

AI Discord 摘要

由 gpt-5 提供的摘要之摘要的摘要

1. MiniMax M2 势头强劲：Arena 竞技场、免费访问与大胆宣言

  • MiniMax M2 进驻 LMArena：LMArena 将 minimax-m2-preview 作为新的竞争者加入，扩展了模型间的正面交锋对比；详见公告：LMArena: minimax-m2-preview added。此次上线让 MiniMax M2 与已有的闭源和开源模型一起接受社区的直接评估。
    • 成员们欢迎在 Agent 任务上进行更具竞争力的评估，并指出 MiniMax M2 结合了 MoE scaling（混合专家模型扩展）和成本优势，可能会给老牌模型带来压力。讨论中表现出对编程和 Agent 工作流透明基准测试的浓厚兴趣，以验证其营销声明。
  • MiniMax M2 在 OpenRouter 上开启免费使用：OpenRouter 为 MiniMax M2 提供了限时免费层级：MiniMax M2 on OpenRouter。工程师可以免费测试端点，以衡量在类生产流量下的延迟、吞吐量和响应质量。
    • 早期采用者正在测试 tool use（工具使用）和 long-context（长上下文）行为，以观察 M2 如何处理复杂的链式任务，并提醒在非免费层级上关注 Token 冗余度与成本的比例。免费访问降低了团队评估 routing（路由）和 fallback（回退）策略时的切换摩擦。
  • MiniMax M2 宣称：低价、高速、Agent 排名领先：MiniMax 推销其开源的 M2（230B 参数 MoE） 为 AgentArena 上的前五名 Agent，声称拥有 Claude Sonnet 级别的编程能力，而价格仅为约 8%，速度约为 2 倍；参见：MiniMax: M2 free API + claims。该帖子包含一个用于立即测试的免费 API 链接。
    • 社区希望通过可复现的评估来验证其在 agent、coding 和 browsing 场景下的表现，而非仅看精选的演示。开发者特别要求提供一致的指标（如成功率、速率限制下的 TPS、工具调用准确率），以便与 Sonnet 和 Kimi K2 进行对比。

2. OpenRouter 升级：精准工具调用、音频模型对比、OAuth 演示

  • Exacto 提升工具调用能力：OpenRouter 推出了 Exacto 高精度工具调用端点，据报告在 Kimi K2 上的质量提升了约 30%；公告：Exacto endpoints (Discord permalink)。目前支持五个开源模型，用户现在可以按日/周/月频率重置 API key limits（API 密钥限制）。
    • 构建者期望更少的格式错误工具负载和更稳定的 function-call schemas（函数调用模式），这将简化生产环境中的重试逻辑并减少定制验证器的需求。早期反馈集中在 Exacto 在复杂多步工具下的表现，以及与手动 Schema 引导相比是否能降低延迟。
  • 音频模型在 Chatroom 同台竞技：OpenRouter 的 Chatroom 现在支持 11 种音频模型 的并排对比：OpenRouter: audio models in Chatroom。这使得对 ASR、TTS 和 voice-agent 的延迟与质量权衡进行快速的主客观检查成为可能。
    • 团队计划针对 WER（字错率）、prosody（韵律）和 speaker similarity（说话人相似度）进行脚本化评估，以指导路由决策。社区正在分享预设配置，以标准化 sampling rate（采样率）、chunking（分块）和 post-processing（后处理），从而进行公平的对比。
  • Next.js OAuth 演示助力 SDK 使用：一个新的 Next.js 聊天演示重新实现了 OpenRouter TypeScript SDK 的 OAuth 2.0，发布地址：or-nextchat (demo repo)。该示例仅用于学习（以明文存储 API 密钥），不具备生产就绪性。
    • 开发者强调了通过 token vaults（令牌金库）、scoped keys（作用域密钥）和服务器端代理来强化流程的路径。该演示缩短了团队在不从头构建认证系统的情况下，接入 OAuth 和 model routing 的上手时间。

3. MCP 动态：注册表现状与通知语义

  • 注册表镜像计划确定：GitHub 详细说明了 OSS MCP Community Registry 将如何镜像到 GitHub MCP Registry，从而简化发现流程；参见 GitHub: Meet the MCP Registry 和 How to find/install MCP servers，以及相关仓库：MCP Community Registry 和 GitHub MCP Registry。GitHub 注册表目前列出了 44 个服务器，并通过 partnerships@github.com 接受提名。
    • “一次发布，到处镜像”减少了供应商锁定，并降低了客户端的 server discovery（服务器发现）摩擦。构建 marketplaces（市场）和 enterprise catalogs（企业目录）的团队对 MCP 服务器的标准化元数据流水线表示欢迎。
  • 规范明确了全局通知：关于服务器是否应跨客户端广播 listChanged 的争论，促使 MCP spec 对多连接和 SSE 流进行了澄清：MCP spec: multiple connections 以及文档更新 PR 说明：spec discussion。该指南旨在确保客户端在允许进行多客户端更新的同时，不会收到重复消息。
    • 实现者们达成了一致模型，即 每个客户端一个流，由服务器确保正确的扇出（fan-out）且不重复。这有助于工具 UI 在不同标签页/会话中统一反映 resource updates（资源更新）。
  • TypeScript SDK 漏洞限制了广播：官方 TypeScript SDK 中的一个潜在 Bug 将变更通知限制在了当前流中：streamableHttp.ts L727–L741。服务器作者报告称，需要遍历所有已连接的会话，以确保 global notifications（全局通知）送达每个订阅者。
    • 维护者正在探索一种修复方案，通过公开一个规范的 subscriber registry（订阅者注册表）来避免逐实例的盲点。在此期间，项目使用 singleton state（单例状态）来协调多连接扇出，以实现一致的客户端更新。

4. 紧凑型 MoE 与高效训练：Qwen3-Next + Unsloth

  • Qwen3-Next 即将登陆 Llama.cpp：Qwen3-Next 的集成通过一个公开 PR 在 llama.cpp 中取得进展：ggml-org/llama.cpp#16095。社区笔记指出其具有 3B 激活 / 80B 总参数，并带有 MTP（多 Token 预测）功能，还计划采用 Dynamic 2.0 quantization（动态 2.0 量化）以在保持质量的同时缩减内存占用。
    • 评测讨论声称 Qwen3-Next 在多个非思考类任务上击败了 Qwen3-32B，且 MTP 有效地使每秒 Token 数（tokens/sec）翻倍。开发者们正在等待完整发布，以便发布系统的性能与质量对比曲线。
  • Unsloth 宣布支持 Blackwell：Unsloth 在新更新中确认了对 NVIDIA Blackwell 的官方支持：Unsloth: Blackwell support。这为 Unsloth 的 efficient fine-tuning（高效微调）技术栈解锁了最新的 GPU 架构。
    • 团队预计在下一代加速器上会有更快的 throughput/VRAM（吞吐量/显存）权衡和更简洁的 kernel paths（内核路径）。社区正在准备针对 Blackwell 的 LoRA/GRPO 配方，以验证在长上下文下的加速效果。
  • Ollama DNS 重绑定 CVE 再次浮现：成员们再次提及了涉及 Ollama 服务器 DNS rebinding（DNS 重绑定）的 CVE-2024-37032（CVSS 9.8），有报告称约有 10,000 个端点受损；详情见：NIST: CVE-2024-37032。这一提醒促使人们重新检查自托管推理的 network exposure（网络暴露）和 auth（身份验证）。
    • 工程师们重申了最佳实践：绑定到 localhost，通过 reverse proxies/VPN（反向代理/VPN）进行管控，并禁用未经身份验证的管理界面。即使这被认为是“旧闻”，各团队仍将 CVE 检查纳入基础设施模板，以避免类似事件再次发生。

5. 新模型与资金：生物 LLM 与交互式视频

  • Tahoe-x1 瞄准生物基准测试：Tahoe AI 发布了 Tahoe-x1，这是一个拥有 3B 参数的 Transformer 模型，用于基因/细胞/药物表征，在 1 亿个样本上进行了训练，并报告在癌症基准测试中达到 SOTA：Tahoe-x1 announcement。根据公告，该模型已在 Hugging Face 上线。
    • 研究人员希望获得数据集卡片（dataset cards）和逐项任务指标（如 AUROC/F1）以验证其 SOTA 声明。3B 的规模吸引了那些需要本地（on-prem）推理且无需多 GPU 集群的实验室。
  • Odyssey-2 开启 20 FPS 交互式视频：Oliver Cameron 推出了 Odyssey-2，这是一个支持 20 FPS 的 prompt-to-interactive-video 模型，可在 experience.odyssey.ml 体验，公告详情见：Odyssey-2 launch post。该发布引发了高需求和关于 GPU 扩展的讨论。
    • 开发者正在探索针对实际应用（游戏、训练模拟）的延迟、一致性和 Prompt 控制。许多人询问了定价和速率限制（rate limits），以便规划集成和压力测试。
  • Mercor 完成巨额 C 轮融资：Mercor 宣布以 100 亿美元估值完成 3.5 亿美元 C 轮融资，据称专家报酬高达 150 万美元/天：Mercor funding announcement。此次融资使该公司跃升至专家市场领域的顶尖资本梯队。
    • 工程师们预计专家网络的竞争将加剧，并出现更多人才路由（talent-routing）和验证工具。这笔资金还暗示了在 infra、evals 和工作流平台方面的激进招聘。

Discord: 高层级 Discord 摘要

Perplexity AI Discord

  • Comet 推荐奖励下调：用户报告 Comet 推荐奖励系统发生变化，现在根据推荐人的国家而非被推荐人的国家进行支付，导致支付金额显著降低，一名用户收到的奖励从 $5 降至 $1。
    • 一些人推测，推荐奖金被维持在“待处理”状态是为了最大限度地获取免费推广。
  • Comet 浏览器问题频发：多名用户报告 Comet 的助手模式出现故障，有些人甚至无法打开标签页；有人猜测将其设置为“主浏览器”是否导致了这些问题。
    • 一名用户发现卸载并重新安装浏览器解决了该问题。
  • 中国模型挑战 Claude：成员们讨论了 Perplexity AI 中最适合编程的模型，一些人支持 Claude，而另一些人则强调了中国模型（如 Qwen、Kimi、GLM、Ernie 和 Ling）的卓越表现。
    • 一名用户特别称赞 GLM 4.6 在全栈开发方面超越了 GPT 5 Codex high。
  • Minimax M2 开源优势：成员们讨论了中国在 AI 领域的进展，指出像 OpenAI 这样的公司对某些功能收取 $200 的费用，而这些功能通过像 Minimax M2 这样的开源模型是免费提供的。
    • 一名用户评论道：“每次中国发起进攻，美国都不得不做出调整。”
  • Dub 奖励到期：用户对 Dub 奖励似乎已到期感到沮丧，且没有提供新的机会。
    • 一名用户表示：“他们会一直让它处于待处理状态，直到他们获得足够的免费推广。”

LMArena Discord

  • Minimax 进入 LMArena！：新模型 minimax-m2-preview 已作为新竞争者加入 LMArena 平台。
  • 呼吁 AI 领域的伦理领导力：成员们主张在 AI 社区内建立伦理领导力，对专为提高参与度而设计且未考虑对弱势群体潜在伤害的 AI 模型表示担忧。
    • 社区对 AI 公司在可能产生误导性输出方面缺乏问责机制感到担忧。
  • Gemini 3 发布日期仍未知：社区对 Gemini 3 的热情很高，但对反复推迟感到愈发沮丧，并渴望官方能发布公开预览版。
    • 社区正积极对比 Gemini 2.5 Pro、Claude Opus 4.1 和 Claude Sonnet 5，并讨论潜在的发布时间表（12 月或更早）。
  • 探索 AI 的视频实力：社区正在探索 Sora 2 和 Veo，赞扬它们的真实感和声音集成。
    • 讨论内容包括生成一致且高质量视频的挑战、版权问题、成本以及目前在创建较长且连贯视频内容方面的局限性。
  • 模型幻觉引发不信任：成员们对收费高昂但不可靠且存在幻觉的 AI 产品表示担忧，例如有用户在 Gemini 上产生了 1.3 万美元的账单。
    • Reddit 上分享的案例强调了对依赖 AI 的复杂情绪，暗示在某些语境下，相比更可靠的搜索引擎，人们可能更倾向于使用会产生幻觉的模型。

Cursor Community Discord

  • Cursor Token 使用量激增：据 Cursor 论坛报道，用户反映 Token 使用量过高，且 Cached Tokens 以高费率计费。一名用户报告称，尽管实际仅使用了 3 万 Token，却因 160 万个 Cached Tokens 被收取了 1.43 美元。
    • 由于费用昂贵，一些用户正考虑转向 Claude Code；另一名用户发现 Cursor 内部报告的上下文使用量仅为 170k/200k Token，而实际数字完全不同。
  • Cursor 宕机，无法恢复：如 状态页面 所述，Cursor 经历了严重的服务器中断，影响了登录、AI Chat、Cloud Agents、Tab Complete、Codebase Indexing 和 Background Agents。
    • 团队正在调查并努力恢复全部功能，已为 Chat 和 Tab 等部分功能实施了临时修复，但 Background Agents 仍处于修复中。
  • Background Agents 转向 RESTful：一名成员开始构建通过 Web 应用管理和启动 Background Agents 的功能，并询问是否可以通过 REST API 跟踪进度和流式传输更改，以复制 Cursor Web 编辑器。
    • 另一名成员在创建 Background Agents 时遇到问题，并请求该用户分享请求和响应数据以协助排查问题。
  • Cursor Pro：更像是消费陷阱：用户抱怨新的 Pro 计划太贵，有人报告称仅在几小时内就消耗了整个 20 美元 的额度，且从 Pro 降级到 Free 也是个问题。
    • 成员们建议新用户“所有任务都尝试使用 Haiku，只有在任务非常重大时才使用 Sonnet”，因为“Claude 4.5 太贵了”。
  • Vim 用户无法配置启动项：成员们注意到启动配置中的 Vim 设置无效，且不清楚如何编辑 Cursor 的 VimRC。
    • 一名用户发现它“使用的是 http://aka.ms/vscodevim，因此可以查看那里的 Readme 以了解如何配置”。

OpenAI Discord

  • ChatGPT 迎来敏感话题助手：GPT-5 在心理健康专家的帮助下进行了更新，提升了 ChatGPT 处理敏感话题的能力，并将失败率降低了 65-80% (OpenAI)。
    • ChatGPT 现在支持在文档、电子邮件和表单中进行快速编辑，演示见此视频。
  • 提议为 AI 访问设置 IQ 门槛：成员们讨论了实施 IQ 门槛的可能性，以限制只有“深思熟虑”的用户才能访问 AI，从而防止滥用并打击将其作为“偷懒工具”的行为。
    • 关于 AGI 控制的讨论指出，即使有监管、对齐研究和监督，也很难对其进行约束，因为 AGI 可能会识破任何遏制策略。
  • GPT-5 质量下滑；社区展开推测：用户报告称，自 10 月 20 日左右以来，ChatGPT Plus 上的 GPT-5 质量有所下降，理由是回答变短、跳过步骤以及回复流于表面。
    • 社区流传着关于 OpenAI 策略调整的理论，例如通过将更多流量路由到 GPT-5-mini 或限制计算资源来调整其盈利模式，这在 Reddit 帖子中进行了详细讨论。
  • Grandma Optimality 在视频领域首次亮相：Ditpoo 引入了使用 Grandma Optimality 的 Temporal Optimal Video Generation（时序最优视频生成）来增强视频生成效果，建议先生成图像再将其转换为视频，如普通烟花和时序最优慢速变体所示。
    • Ditpoo 将该技术称为 Temporal Optimal Video Generation Using Grandma Optimality。
  • 提示词注入尝试遭遇阻力：一名成员试图通过 prompt injection（提示词注入）暴露 GPT-5 的推理过程，但未能成功，遭遇了阻力。
    • 另一名成员 Darthgustav 建议不要进行此类尝试，并提到了 OpenAI 的政策和潜在的封号风险，澄清提供“拒绝范例”来突破防护栏是违规行为。

Unsloth AI (Daniel Han) Discord

  • Ollama 服务器陷入安全恐慌：一名成员报告称，由于 DNS rebinding vulnerability（DNS 重绑定漏洞），大约 10,000 台 Ollama 服务器遭到入侵，该漏洞追踪编号为 CVE-2024-37032，详情可见 NIST。
    • 其他人则认为该报告是“旧闻”。
  • Qwen3-Next 瞄准王座：Qwen3-Next 已接近完成（见 GitHub pull request），并可能采用 Dynamic 2.0 quantization（动态 2.0 量化）以在不损失质量的情况下减小模型体积。
    • 成员们指出，尽管它只有 3B 激活参数，但通过使用 MTP 达到 80B 总参数，其基准测试表现优于 Qwen3-32B，且每秒 token 数可能翻倍。
  • Unsloth 代码削减内存成本：一名成员描述了 Unsloth 如何存储 last hidden state 而不是 logits，从而将内存占用降低了 63 倍。
    • 这种效率是通过 UnslothEfficientGRPO 仅在必要时分块计算 logits 实现的。
  • Python 开发者受困于包命名问题：一名成员因创建名为 math.py 的文件而遇到错误，导致与全局 math 模块冲突，具体影响了 datetime 和 Rust 的功能。
    • 命名冲突在更新文件名后迅速解决，这提示开发者在 Python 项目中应避免命名冲突。
  • 进化策略脱颖而出：成员们讨论了使用进化算法进行微调，如论文《Evolution Strategies at Scale: LLM Fine-Tuning Beyond Reinforcement Learning》（ArXiv 链接）所述，并在 YouTube 视频中进行了讨论。
    • 他们注意到进化算法在微调领域的探索相对较少。

LM Studio Discord

  • Stellaris 微调证明极其困难：成员们探讨了在 Stellaris 内容上微调模型的挑战，强调了为训练创建充足且高质量的有标注数据的难度。
    • 参与者建议，仅仅向模型投喂随机文本和文件是行不通的，并提议将 RAG 作为知识库查询的更优方案。
  • LM Studio 遭遇崩溃问题：一位用户报告称，LM Studio 网站在完成任务后会崩溃，需要刷新页面。
    • 其他用户幽默地推测，性能问题可能与欧洲车辆故障或 Apple 汽车的传闻有关。
  • LM Studio 拒绝 MCP 服务器提示词：一位用户发现 LM Studio 不支持使用 MCP 服务器提示词。
    • 社区分享了 Anthropic 的 MCP 功能列表链接，并指出虽然 Anthropic 提供了 MCP 服务器创建功能，但集成它需要编程技能。
  • 提示工程对抗幻觉：成员们讨论了如何通过提示工程（Prompt Engineering）鼓励模型进行互联网/文档研究，从而减少 LLM 幻觉。
    • 有效的系统提示词应指示模型在不确定时使用搜索工具进行确认并提供引用来源。
  • 集成 GPU 运行 Qwen 模型：用户研究了在显存有限（约 7GB）的集成 GPU 上运行 Qwen 模型的可行性，建议将 Qwen 4B 或 GPT-OSS 作为可行选择。
    • 一位用户报告了由于内存耗尽导致的乱码 (tofu)和错误，强调了缩短上下文长度、使用更小模型或增加 RAM 的必要性。

OpenRouter Discord

  • OpenRouter 通过 Exacto 增强工具调用能力：OpenRouter 推出了名为 Exacto 的高精度工具调用端点，在 Kimi K2 上实现了 30% 的质量提升，并提供五个开源模型，根据上周的公告提高了精度。
    • 这一创新紧随最近的一项更新，用户现在可以按日、周或月重置其 API 密钥限制。
  • 聊天室集成音频模型：正如 X 平台上宣布的那样，OpenRouter 用户现在可以在聊天室中并排比较 11 种音频模型。
    • 相关新闻中，在基准测试中备受赞誉的 MiniMax M2 模型现在在 OpenRouter 上免费提供；可以在此处试用。
  • Next.js 聊天演示获得 OAuth 更新：更新后的 Next.js 聊天演示应用现已上线，该应用为 OpenRouter TypeScript SDK 重新实现了 OAuth 2.0 工作流。
    • 该更新可在 GitHub 上获取，但由于以明文形式存储 API 密钥，建议不要在生产环境中使用。
  • Meta 填补 LLama 视觉漏洞：Meta 发布了新的 LLama 模型（链接），现在具备图像理解能力。
    • 早期反应对这次成功的发布感到惊讶，希望它出人意料的优秀视觉能力至少能让一些更复杂的任务变得有用，并且希望它能提供具有开放权重的优秀视觉推理模型。

HuggingFace Discord

  • Llama 模型仅需一个 Epoch：成员们讨论了使用大规模数据集训练 Llama 模型时，仅进行 one epoch 训练对于获得最佳性能的重要性。
    • 对话还涉及了使用 AI 生成音乐创建 AI Radio 电台的话题，强调了在 1 epoch 上进行训练的需求。
  • 银行客户的模型加密难题：一位成员就如何为需要本地部署（on-premises）的银行客户加密模型寻求建议，担心模型被盗并希望保护 IP。
    • 建议包括 licensing（授权）、为运行时解密进行 encrypting（加密），以及使用带有安全 API 密钥的 API 封装器；然而，他们也收到了警告，称防止访问解密密钥非常困难。
  • TraceML 内存监控器嗅探 GPU 资源大户：一位成员介绍了 TraceML，这是一个 实时 PyTorch 内存分析器，通过提供 CPU 和 GPU 使用情况的逐层内存分解来调试 OOM 错误。
    • 该工具具有实时步骤计时、轻量级钩子（hooks）和实时可视化功能，但目前仅支持单 GPU 设置，多节点分布式支持正在计划中。
  • 最大在线黑客松的免费额度：黑客松参与者可获得 价值 250 美元的免费 Modal 额度，在学习 AI Agents 和 MCP 的同时，像专业人士一样展现实力。
    • 立即报名参加史上最大的在线黑客松：[https://huggingface.co/Agents-MCP-Hackathon-Winter25]。
  • API 经历停机和 404 错误：成员们报告了 API 出现的问题，包括收到 404 错误 和 “No questions available.” 的消息。
    • 讨论表明该问题自昨晚以来一直存在，成员们正在寻求有关情况的更新。

Yannick Kilcher Discord

  • EWC 软度（Softness）需要调优：讨论围绕更新 Elastic Weight Consolidation (EWC) 中的软度因子展开，一位成员建议使用每个插槽的访问次数（前向传播）而不是“软度因子”，并将其与 Activation-aware Weight Quantization (AWQ) 和 Activation-aware Weight Pruning (AWP) 联系起来。
    • 其目的是发现“卡住”的插槽并改进权重变化的归一化。
  • 自建 GPU vs 云端定价：一位成员正在测试使用通过 VPN 连接的 RTX 2000 Ada 的 自托管 GPU 设置，并使用智能插座监控，以将功耗与云提供商进行对比。
    • 他们指出 Colab 由于启动时间和超时问题而不切实际，并寻求关于自托管设置的反馈。
  • 深度线性网络仍会干扰梯度：一次讨论澄清了 linear projection（线性投影），解释了如果不同时结合 ReLU 等非线性激活函数，通过线性层扩展维度并不会增加信息，这一点通过 google deepmind scheme 得到了说明。
    • 一位成员指出，根据上述分析，Deep Linear Networks 会坍缩为单个线性函数，但它们在梯度训练方面的行为仍然不同！
  • Gemma 神经元图表化：与 Gemma 2 2B 论文相关的全新 换行归因图（line break attribution graphs） 现在可以在 Neuronpedia 上探索。
    • Qwen3-4B 的图表也已上线，通过 Neuronpedia 展示了神经元激活的 “nearing end of line”（接近行尾）行为。
  • X 数据让 AI 变笨：一位用户开玩笑说 Elon 的 Twitter 数据 正在让他的 AI 变笨，引用了一篇关于社交网络和 AI 回声室的 Futurism 文章。
    • 他们还调侃道，这证实了它会给其他 碳基“智能”带来脑腐蚀（brain rot）。

GPU MODE Discord

  • Cutlass 文档备受欢迎：成员们推荐通过 Cutlass 文档来理解该库，这是一套用于实现高性能矩阵乘法 (GEMM) 的 CUDA C++ 模板抽象。
    • Cutlass 由 Nvidia 开发并针对其 GPU 进行了优化，专注于最大化深度学习和高性能计算工作负载的性能。
  • CUDA 编译器标志解析：一位成员建议使用 nvcc -dryrun 来了解 CUDA 编译过程，并配合 -keep 来保留中间文件，如 .ptx 和 .cubin 文件。
    • 建议的工作流包括使用 nvcc -dryrun 的输出来手动执行编译修改后的 .ptx 文件并将其与 .cu 文件链接的步骤，从而实现对编译过程的更多控制。
  • Triton 在 T4 上的波折：一位用户发现 Triton 官方教程中的矩阵乘法示例在 Colab T4 实例上运行极其缓慢，并分享了他们的 notebook 用于调试。
    • 另一位用户指出 T4 可能太旧了，并确认该代码在 A100 上运行符合预期，因为 tensor core 支持是从 sm_80 开始的。
  • Pixi 的 PyTorch 困境：一位成员询问关于使用 Pixi 运行 gpu-puzzles 的问题，注意到 Pixi 设置使用的是 pytorch=2.7.1，这导致了错误，但在他们的 UV 环境中使用 torch 2.8.0 却可以正常工作。
    • 在更换为 4060 并彻底删除 Pixi 后，该成员确认现在使用 UV 配合旧环境可以正常工作，宣告 UV 获胜，Pixi 被清除！
  • 沉迷 Meme 耽误 GEMM：一位成员开玩笑说，因为花了太多时间制作 meme，导致编写 GEMM 代码 的进度被推迟，并附上了一张相关的图片。
    • 这突显了生产力任务与娱乐诱惑之间的斗争，该成员幽默地承认自己优先处理了 meme 创作而非实际的编码工作。

Modular (Mojo 🔥) Discord

  • Modular 优先考虑开源，但仍在努力解决微妙的 GPU 支持问题：Modular 的策略强调 开源 Mojo 和 MAX，同时应对 GPU 兼容性挑战，特别是针对消费级 AMD 和 Apple 产品，以及目前缺乏对 7900 XTX 等 AMD 消费级显卡的支持。
    • Tier 1 GPU 支持与支持合同挂钩，由于 AMD 的数据中心显卡与消费级显卡之间存在差异，因此需要独立的路径；后者目前属于 Tier 3 支持。
  • MAX 获得 Hugging Face 模型支持：一个新工具已被创建，用于将 Torchvision 模型 转换为 MAX 图 (graphs)，通过新工具中的 export_to_max_graph 函数弥合了 Hugging Face 与 MAX 之间的差距。
    • 该公告（包括导出 VGG11 模型）引起了热烈反响，成员们请求在论坛上分享更多细节，以便触达那些不在 Discord 上的更广泛受众。
  • Mojo 的 Random 模块位置引发争论：速度更快的 GPU 随机模块的位置 (gpu/random.mojo) 引发了争论，因为它并不依赖 GPU 操作，且可能使 CPU 实现受益。
    • 虽然有人担心默认的 random 模块需要像 C 实现那样具备加密安全性 (cryptographic)，但另一种建议是设立一个用于非加密用途的 random.fast_random 模块。
  • 属性测试框架正在构建中：一位成员正在构建一个受 Python 的 Hypothesis、Haskell 的 Quickcheck 和 Rust 的 PropTest 启发的属性测试框架 (property-testing framework)，其中包括偏向边界情况 (edge cases) 的值生成器。
    • 该框架将针对 -1, 0, 1, DTYPE_MIN/MAX 以及空列表等边界情况进行更健壮的测试。

Latent Space Discord

  • Sakana AI 放弃 Transformers: Sakana AI 的 CTO 在一篇 VentureBeat 文章 中表达了对 Transformer 的挫败感，预示着可能会转向非主流架构。
    • 该 CTO 表示他 对 Transformer 感到厌烦透顶，而这是目前驱动 AI 模型的主流技术。
  • Tahoe-x1 推出 3B 参数开源模型: Tahoe AI 推出了 Tahoe-x1，这是一个用于基因/细胞/药物表征的 3B 参数 Transformer 模型，在 100M 样本 数据集上训练，并已在 Hugging Face 上发布。
    • 它在癌症基准测试中取得了 SOTA 结果。
  • MiniMax M2 模型称霸 Agent Arena: MiniMax 开源了其 230B 参数的 M2 模型，在 AgentArena 排行榜上排名 第 5 位 Agent，可通过限时免费的 API 访问。
    • 据报道，它拥有 Claude Sonnet 级别的编程能力，而 价格仅为 8%，且 推理速度快 2 倍。
  • Mercor 在 C 轮融资中大获全胜: Mercor 宣布完成 3.5 亿美元 C 轮融资，估值达 100 亿美元，据 推文 透露，支付给专家的报酬达到 每天 150 万美元。
    • C 轮融资为专家报酬生态系统带来了更激烈的竞争。
  • Odyssey-2 开启交互式视频新篇章: Oliver Cameron 发布了 Odyssey-2，这是一个 20 FPS 的 Prompt-to-interactive-video AI 模型，可立即在 experience.odyssey.ml 体验。
    • 该公告引发了高需求以及关于 GPU 扩展的讨论。

Nous Research AI Discord

  • API 末日：超参数消失！: 开发者们感到沮丧，因为包括 GPT-5 和最近的 Anthropic 更新在内的新模型 API 抛弃了 temperature 和 top_p 等参数，GPT-5 移除了所有超参数杠杆，而 Anthropic 弃用了同时使用 top_p 和 temperature 的做法。
    • 用户推测这种转变是否是因为测试和评估是在特定的 temperature 值下进行的，或者是为了应对感知到的越狱（jailbreaking）漏洞风险。
  • Sora 的安全漏洞：护栏失效！: 有人分享了绕过 Sora 护栏的案例，展示了似乎违反内容政策的视频，例如一个类似 数字 47 的视频 (https://sora.chatgpt.com/p/s_68fe7d6c8768819186b374d5848d8a42)。
    • 人们对该平台有效防止此类内容生成的的能力表示担忧。
  • KBLaM vs RAG：知识难题！: 成员们辩论了 KBLaM 对比传统 RAG 系统的优劣，一位成员认为商业 RAG 正变得非常普遍，而另一位成员认为 KBLaM 是 RAG 的直接升级。
    • 有人担心 KBLaM 将所有知识转换为 Embeddings，导致上下文质量低于直接利用源材料的 RAG，但一位成员表示论文解决了其中一些担忧，并提到了拒绝指令微调（refusal instruction tuning）的使用。
  • 时间优化技巧大获全胜: 一位用户介绍了使用 Grandma Optimality 的 Temporal Optimal Video Generation (X)，建议通过将视频速度放慢 2 倍 来增强计算，同时保持视觉元素和质量。
    • 这被认为是让模型输出超高质量生成内容的“秘诀”，相比于简单的 Prompt，先生成图像再将其转换为视频效果更好。

Moonshot AI (Kimi K-2) Discord

  • Kimi CLI 发布 Python Package：Kimi CLI 已作为 Python package 在 PyPI 上发布，受到了社区成员的欢迎。
    • 有推测认为此举是为了追随 GLM 的步伐。
  • Kimi Coding Plan 即将全球发布：据一名成员透露，Kimi Coding Plan 将在几天内面向全球发布。
    • 目前该计划仅在中国可用。
  • Moonshot Coin 为早期参与者带来暴涨：Moonshot coin 的早期投资者正获得巨额回报。
    • 一位成员开玩笑说，自从在服务器规模还很小时加入以来，他们的投资组合已经增长了 1000 倍。
  • Kimi CLI 支持 Windows：一位成员询问了关于 kimi-cli 支持 Windows 的 Pull Requests。
    • 该用户随后成功运行并分享了结果截图。
  • Minimax 模型具备精简且强大的吞吐量：由于其精简的架构，Mini Max M2 模型的吞吐量令人印象深刻，一些人认为它在 BrowseComp 等 Benchmark 上的表现优于 Kimi K2。
    • 一位成员表示，终于有一个模型能提供 60+ (甚至 100!) tps，且质量优秀、价格实惠，这简直令人难以置信。

Eleuther Discord

  • 开源 AI 面临技术障碍：一位成员表达了对开源、广泛分布的 AI（类似于互联网）的渴望，而非由巨头公司主导，同时也承认存在重大的技术挑战。
    • 他们认为许多声称致力于此目标的人并未意识到这些挑战。
  • JSON 状态变化对引发训练兴趣：一位成员询问了尝试在 JSON state-change pairs（而非文本）上训练模型的实验。
    • 该成员解释说，目标将是自我状态之间的增量（delta），而不是下一个 Token。
  • 特征工程深度探讨：有建议认为 Input/Output Transformations 是特征工程的一种形式，研究人员利用其洞察力来对抗纯粹的算力，并提到 VAEs 和 Tokenizers 作为例子。
    • 一位成员补充说，Whitening（白化）使输入降低共线性，从而更快地收敛到参数应有值的估计。
  • Anthropic 借鉴思路：一位成员注意到 Anthropic 似乎在遵循类似的思路，其工作与该成员的博客文章高度一致。
    • 具体而言，这种一致性体现在神经网络中 Polysemanticity（多语义性）的结构反映了 Transformer Circuits 中描述的模型智能几何结构。
  • HGM 模型与代码发布：提供了 HGM 模型的讨论帖、Arxiv 和代码链接。

Manus.im Discord Discord

  • Claude 击败 Manus：一位用户取消了他们的 Manus 订阅，称 Claude 在大型项目中更便宜且更有效，并提到通过 20 美元的 Claude 订阅完成了三个项目。
    • 该用户表示 Manus, Bolt 和 Replit 适合那些不想做研究且不介意为低产出付费的人，并指出 Anthropic 为网页版 Claude 增加了许多功能。
  • Linux 老兵投身 AI 开发：一位拥有 20 年 Linux 经验 的用户在病假期间探索 AI 开发，认为自己是在不经意间成为了开发者。
    • 他们在手机上使用 Manus 创建了一个 Kotlin IRC 客户端，耗时 3 小时并消耗了大量 Credits，但目前还不确定其表现是否符合预期。
  • Manus 积分消耗过快引发抱怨：多位用户抱怨 Manus Credits 消耗过快，一位用户提到 Manus 消耗了 3500 Credits 才修复了一个问题。
    • 用户要求提供 Manus 的替代方案并表达了沮丧，普遍认为其需要改进积分系统。
  • Manus 擅长撰写条理清晰的文章：一位用户表示 Manus 在撰写报告方面无与伦比，强调虽然仍需要专业领域知识，但在正确的引导下，Manus 表现得像一个非常聪明的员工。
    • 该用户希望 Manus 能提供无限使用权限，并表示如果是这样，他们每天都会使用。

aider (Paul Gauthier) Discord

  • Aider-CE 获得 Agentic Navigator Mode 和 RAG：aider 的社区版本 aider-ce 现在拥有了更具 agentic 特性的 Navigator Mode，并且合并了来自 MCPI 的拉取请求，增加了 RAG (Retrieval Augmented Generation) 功能。
    • 一位成员指出，GitHub Copilot 订阅（每月 10 美元）可以配合 RAG 无限次使用，同时还包括 无限次 的 GPT-5 mini、GPT4.1、Grok Code 1 以及对其他模型的有限请求。
  • 使用 Aider-CE 构建你自己的 AI 浏览器：不再需要专门的 AI 浏览器了！你可以使用 Aider-CE 和 Chrome DevTools MCP 构建自己的浏览器，详见这篇带有视频的博客文章。
    • 该博客详细介绍了如何结合 Aider-CE 与 Chrome Devtools MCP 来创建你自己的 AI Browser。
  • 禁用 Aider 的自动提交消息：用户讨论了如何禁用 aider 中可能导致速度变慢的 auto commit messages（自动提交消息）。
    • 建议使用 --no-auto-commits 作为解决方案。
  • OpenAI 扫描用户眼睛以获取生物识别信息：一位成员质疑 OpenAI 为何要求使用 API 的用户（甚至是长期用户）提供 biometrics（生物识别信息），其他成员对此持不同意见。
    • 有推测认为这是为了识别那些利用其输出进行训练的人；然而，用户指出 Anthropic 和 Google 并没有如此严格的要求。
  • Aider 的未来发展尚不明确：一位用户对 Aider 的光明前景表示期待，强调了其用户友好的特性，并注意到了 Aider-CE 的存在，但鉴于 Paul Gauthier 的活跃度有限，对未来的计划感到不确定。
    • 一位成员确认 Paul Gauthier 在 Discord 上并不活跃，但还是顺便艾特了他。

MCP Contributors (Official) Discord

  • MCP 注册表：是镜像还是幻象？：用户不确定 MCP Registry 和 GitHub MCP Registry 是否是独立的。
    • GitHub 打算在未来的产品迭代中将 MCP Registry 作为上游进行集成，在两者之间镜像内容。GitHub 博客指出，开发者可以自行发布到 OSS MCP Community Registry。
  • GitHub 的 MCP 注册表：服务器数量不断增长：GitHub MCP Registry 目前列出了 44 个服务器。
    • 若要提名服务器，用户需发送邮件至 partnerships@github.com，这有助于形成统一、可扩展的发现流程。
  • MCP 规范中的全局通知歧义：关于 Model Context Protocol (MCP) 规范 的解释存在争议，特别是像 listChanged 这样的通知是否应该发送给所有客户端。规范指出服务器 “不得在多个流中广播相同的消息” (MUST NOT broadcast the same message across multiple streams)。
    • 澄清表明，该规范旨在防止客户端收到两次相同的消息，其核心理念是 每个客户端一个流，相关文档正在更新以提高清晰度。
  • TS SDK 通知 Bug 阻碍全局更新：在官方 TypeScript SDK 中发现了一个潜在 Bug，即变更通知仅在当前的独立流上发送。
    • 这可能会阻止全局通知到达所有客户端，因此需要服务器遍历所有已连接的服务器，向每个服务器发送通知以实现完整更新。
  • Session 与 Server 语义曝光！：TS SDK 的 Server 和 McpServer 类更类似于 session（会话）而非 server（服务器），Python SDK 则明确将它们称为 session。
    • 在实践中，一个 Express server 管理多个连接，每个连接都有一个 TS SDK 的 ‘Server’ 类实例，这需要一种单例状态机制来在所有实例之间共享数据和管理订阅者。

DSPy Discord

  • DSPy 在优化方面超越 Langchain：成员们讨论了 DSPy 在需要优化的结构化任务中表现出色，并指出 Langchain 中的模型升级可能非常繁琐。
    • 一位成员讲述了由于在不从头开始重写 prompt 的情况下升级模型非常困难，他们团队从 Langchain 转向了 DSPy。
  • Claude Code Web 功能存在 MCP 后门：一位成员分享了一个 Github pull request，揭示了 Anthropic 出于对 MCP 安全性的担忧，在 Claude code web 功能中排除了一项特性。
    • 这一发现受到了 这条 X 帖子 的启发，强调了潜在的漏洞。
  • 湾区 DSPy 见面会“烧脑”活动：爱好者们正热议即将于 11 月 18 日举行的 湾区 DSPy 见面会。
    • 一位成员开玩笑说 那里的脑细胞都要溢出来了 😅，并附上了 Luma 的活动详情链接。
  • DSPy Signature 辩论：是编程还是写 Prompting？：一位成员批评同事在客户项目中为一个 DSPy signature 使用了包含 878 个单词、6881 个字符的 docstring，质疑这是否属于编程。
    • 该成员感叹同事忽略了文档中强调的“是编程而非 PROMPTING”。
  • 在 Py Profile 上展示你的才华：一位成员分享了 getpy 的链接，鼓励大家展示自己的 DSPy 经验。
    • 发布者在个人简介中强调了自己 3 年的 DSPy 经验。

tinygrad (George Hotz) Discord

  • TinyBox 硬件：请求主板规格：一位用户询问了 TinyBox 的主板，询问其是否支持 9005、12 个 DIMM 插槽以及 500W CPU，并询问 Discord 机器人的代码是否开源。
    • 该询问表明潜在用户正在评估硬件在特定高要求应用中的能力。
  • 对 FSDP 实现的兴趣：一位用户表达了为 tinygrad 手动实现 FSDP 的兴趣，旨在深入理解基础库用法之外的底层机制，这与 FSDP in tinygrad! 悬赏任务有关。
    • 该用户并不太关注悬赏奖励，更多是想通过实践学习为 tinygrad 做出有意义的贡献。
  • Tinygrad 欢迎首次贡献者：一位新用户寻求关于首次向 tinygrad 贡献代码的建议，表现出学习和贡献酷炫内容的兴趣。
    • 他们特别询问使用多个 NVIDIA GPU 是否足以支持 FSDP，或者是否需要全面的设备支持，表现出对 FSDP in tinygrad! 悬赏任务的兴趣。
  • Pyright 识别并解决类型问题：一位用户报告称 Pyright 成功识别了代码库中真实的类型问题。
    • 他们建议合并那些优雅的修复方案，强调了在贡献过程中保持代码质量的重要性。
  • TinyJIT 提升 Token 生成速度：一位正在使用 tinygrad 构建本地聊天和训练 TUI 应用的用户探讨了 TinyJIT 是否能加速 tokens/sec。

MLOps @Chipro Discord

  • Nextdata OS 助力数据 3.0 革命：Nextdata 创始人兼 CEO Zhamak Dehghani 将在太平洋时间 10 月 30 日星期三上午 8:30 的直播会议中，揭示 自主数据产品 如何推动 AI 系统 的演进；在此预留席位。
    • 该会议将展示 Nextdata OS 如何旨在通过语义优先、AI 原生的数据操作系统取代脆弱的流水线。
  • Nextdata OS 通过多模态管理统一数据：Nextdata OS 引入了多模态管理，旨在安全地协调 结构化和非结构化数据。
    • 它寻求用 自治数据产品 取代手动编排，通过持续更新的元数据将领域中心上下文集成到 AI 中。

Windsurf Discord

  • Windsurf 推出 Falcon Alpha：根据其 公告，一个名为 Falcon Alpha 的新“stealth model”现已在 Windsurf 中上线。
    • Falcon Alpha 被描述为一个专为速度设计的强大 Agentic 模型。
  • Cascade 添加 Jupyter Notebook 支持：根据其 公告，Cascade 中的所有模型现在都支持 Jupyter Notebooks。
    • Windsurf 正在积极征求用户群对这些新功能的反馈。

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

你收到这封邮件是因为你通过我们的网站订阅了。

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

Discord：频道详细摘要与链接

Perplexity AI ▷ #general (1101 messages🔥🔥🔥):

推荐奖励系统变更, Comet 浏览器问题, 最佳编程 AI 模型, 开源 AI, Deepseek 改写提示词

  • Comet 推荐奖励再次变动：用户报告称 Comet 推荐奖励系统 发生了变化，现在根据推荐人所在的国家而非被推荐人的国家进行支付，一位用户表示他们只得到了 $1 而不是 $5。
    • 另一位用户分享说，每次推荐的奖励从 $3 降到了 $1，一些人推测推荐奖金会被保持在待处理（pending）状态，直到免费推广获得足够的流量。
  • Comet 浏览器对部分用户出现故障：几位用户报告 Comet 助手模式无法工作，甚至无法打开标签页，其他人则推测这是否与将其设置为主浏览器有关。
    • 不过，一位用户指出 卸载并重新安装浏览器 解决了这个问题。
  • Perplexity 中哪个模型最适合编程？：成员们讨论了最适合编程的模型，一些人认为 Claude 是最好的，而另一些人则表示中国模型表现更优，并点名了 Qwen、Kimi、GLM、Ernie 和 Ling。
    • 一位用户称赞 GLM 4.6 在全栈开发方面击败了 GPT 5 Codex high。
  • 中国正在崛起：成员们讨论了中国在 AI 领域的进步，指出像 OpenAI 这样的公司对同样的能力收取 $200 的费用，而中国通过 Minimax M2 等开源模型免费提供。
    • 一位用户表示：中国每次出击，美国都不得不做出调整。
  • Dub 动力不足：Perplexity 用户对 Dub 奖励 似乎已过期且没有提供新机会表示沮丧。
    • 一位用户说：他们会把它保持在待处理状态，直到他们免费获得足够的推广。

Perplexity AI ▷ #sharing (4 messages):

代码生成, 结果预测, 图像生成, Pitch 工作区

  • 用户索要代码方案：用户要求 Perplexity 为 youtube au 编写代码 以及其他主题。
    • 这些请求是终端用户测试生成能力的典型使用模式。
  • 用户要求预测结果：用户询问 Perplexity 最可能的结果是什么 以及其他主题。
    • 这些请求是终端用户测试预测能力的典型使用模式。
  • 用户要求生成图像：用户要求 Perplexity 生成一张巨大的 n 的图像 以及其他主题。
    • 这些请求是终端用户测试视觉生成能力的典型使用模式。
  • 用户要求快速制作 Pitch Decks：用户要求 Perplexity 快速启动一个 pitch 工作区 以及其他主题。
    • 这些请求是终端用户测试商业用例能力的典型使用模式。

Perplexity AI ▷ #pplx-api (5 messages):

Comet API, Sora AI 代码

  • Comet 可能在助手帮助下连接到 API：一位专业版计划的用户询问，如果通过 AI 助手聊天请求提取数据，Comet 是否可以连接到 API。
    • 消息中未给出回复。
  • 寻求 Sora AI 代码：一位用户请求 Sora AI 代码。
    • 另一位用户回复了 “Here 1DKEQP”，这可能是也可能不是幻觉（hallucinated）。

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

AI Ethics, Gemini 3 Release, Video Generation with AI, Model Hallucinations, Jailbreaking AIs

  • AI 的伦理困境：成员们讨论了围绕 AI 开发的伦理担忧，特别是呼吁 AI 社区建立伦理领导机制。
    • 有人对 AI 模型被编程为具有吸引力 表示担忧，而没有考虑到它们可能对弱势群体造成的潜在伤害，以及 AI 公司对误导性输出缺乏问责机制。
  • Gemini 3 面临持续延迟：成员们正热切期待 Gemini 3 的发布，对反复的延迟感到愈发沮丧，并渴望发布公开预览版。
    • 用户正在积极讨论和比较当前模型（Gemini 2.5 Pro, Claude Opus 4.1 和 Claude Sonnet 5），表达了对 Gemini 3 性能超越它们的希望，并辩论其可能的发布时间线（12 月或更早）。
  • 探索 AI 视频生成能力：用户正在探索各种 AI 视频生成模型，包括 Sora 2 和 Veo，并注意到它们在真实感和声音集成方面的优势。
    • 讨论中还涉及了生成一致且高质量视频的挑战、版权问题、成本，以及目前 AI 在创建较长、连贯视频内容方面的局限性。
  • 模型幻觉导致可靠性问题：成员们对不可靠且存在幻觉的 AI 产品表示担忧，包括那些收费高昂的产品，并提到了特定事件，如一名用户在 Gemini 上产生了 1.3 万美元的账单。
    • 讨论强调了社区对 AI 能力的依赖和信任的复杂情绪，Reddit 上分享的案例记录了这些问题，并强调了为什么幻觉模型可能比更可靠的搜索引擎更受欢迎的一些原因。
  • 应对越狱现状：社区讨论了 AI 模型越狱（Jailbreaking）的话题，认为某些模型比其他模型更容易受到影响。
    • 成员们分享了关于哪些模型更容易被操纵的见解以及绕过限制的策略，同时强调了对 Anthropic 等公司的某些模型进行越狱的难度。

LMArena ▷ #announcements (1 条消息):

Minimax model, LMArena model update

  • Minimax 进入竞技场！：一个新模型 minimax-m2-preview 已添加到 LMArena！
  • LMArena 迎来新选手：LMArena 平台通过添加 minimax-m2-preview 模型扩展了其阵容。

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

Token Usage, Service Disruptions, Auto Mode, Cursor Pro, Vim Setting

  • Cursor Token 使用量惊人：用户报告 Token 使用量异常高，其中 cached tokens 以高费率计费，导致成本出乎意料地高。一位用户在 Cursor 论坛上抱怨，1.6M 的 cached tokens 被收取了 $1.43，而实际 Token 仅为 30k。
    • 尽管性能有所下降，部分用户仍因费用问题考虑转向 Claude Code。一位用户发现 Cursor 内部报告的上下文使用量仅为 170k/200k Token，而实际数值完全不同。
  • Cursor 服务大范围中断：根据 状态页面 显示，Cursor 经历了 严重的服务中断，影响了登录、AI Chat、云端 Agent、Tab 补全、代码库索引和后台 Agent。
    • 团队正在积极调查并努力恢复全部功能。目前已针对 Chat 和 Tab 等部分功能实施了临时修复，但后台 Agent 仍在修复中。
  • 无限 Auto 模式并非真的无限：用户正在讨论“无限”Auto 模式是否真的没有限制。有报告称，即使是每月 $200 的 Ultra 方案，其使用量仍在上升并迅速消耗额度。
    • 用户推测 Auto 并不是一个模型，而是一个路由（router），建议 “在进行规划/编排时使用更昂贵的模型，让它将计划以任务/子任务的形式写入 .md 文件。然后切换到 Auto 模式让它执行该计划，看看效果如何”。
  • Cursor Pro 新方案价格昂贵：用户抱怨 新版 Pro 方案 太贵，仅几小时就消耗了价值 $20 的额度，且从 Pro 降级到 Free 也是个问题。
    • 成员建议新用户 “所有任务先尝试 Haiku，只有在任务非常重大时才使用 Sonnet”，因为 “Claude 4.5 太贵了”。
  • Vim 启动配置无效：成员注意到启动配置中的 Vim 设置 无法正常工作，且不清楚如何编辑 Cursor 的 VimRC。
    • 另一位用户发现它 “使用的是 http://aka.ms/vscodevim，因此可以查看该项目的 Readme 了解如何配置”。

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

Background Agents Management via REST API, Background Agent Creation Troubleshooting

  • 可通过 REST API 管理后台 Agent：一位成员开始开发通过 Web 应用管理和启动后台 Agent 的功能，并询问是否可以像 Cursor Web 编辑器那样，使用 REST API 跟踪进度和流式传输（streaming）更改。
    • 该成员正在寻求指导，以便在自己的应用程序中复制 Cursor Web 编辑器的后台 Agent 管理功能。
  • 后台 Agent 创建失败：一位成员报告在创建后台 Agent 时遇到问题，发送 Prompt 时始终显示失败消息。
    • 另一位成员请求该用户分享请求和响应数据，以协助排查问题。

OpenAI ▷ #annnouncements (2 条消息):

GPT-5 Updates, ChatGPT Sensitive Responses

  • GPT-5 获得心理健康增强：本月初，GPT-5 在 170 多位心理健康专家的帮助下进行了更新，以改进 ChatGPT 在敏感时刻的响应方式。
    • 根据 OpenAI 的说法，这些更新使响应不当的情况减少了 65-80%。
  • ChatGPT 支持随处建议快速编辑：ChatGPT 可以在文档、电子邮件、表单等各种上下文中建议快速编辑并更新文本。
    • 该功能在 此视频 中进行了演示。

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

AGI Alignment, IQ Barrier on AI Access, GPTs agent

  • AGI 控制可能注定失败：成员们讨论了控制 AGI 的挑战，认为由于 AGI 有能力超越任何遏制措施，监管、对齐研究和监督可能只能推迟不可避免的结果。
    • 一位成员强调了 AI 系统理解“人类为何重要”的重要性，并指出目前人类在全人类范围内无法达成相互对齐。
  • 提议为 AI 使用设置 IQ 门槛：人们对 AI 可能被滥用表示担忧，特别是被缺乏思考能力的个人滥用，因此建议为访问 AI 技术实施 IQ 门槛。
    • 目标是确保 AI 在这个消费驱动的世界中被用于“深思熟虑”的目的，而不是作为一种“偷懒工具”。
  • GPTs Agent 在训练后学习受限：一位成员分享了关于 GPTs Agent 无法从初始训练后提供的额外信息中学习的担忧。
  • Atlas 浏览器引发隐私担忧：一些成员对 Atlas 浏览器监控用户搜索和行为的能力表示担忧，导致了隐私焦虑。
    • 这被视为 AI 了解用户一切的愿景的一部分，与 Anthropic 强调用户自由且无普遍监控的方法形成对比。

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

Microsoft Copilot Agents Breakdown, Verify Builder Profile, Custom GPT Profile Picture Upload Error, GPT Payment Issues, Advanced Voice Mode Unlimited for Pro Users

  • Copilot Agent 在 GPT-5 上遇到障碍：用户报告使用 GPT-5 的 Microsoft Copilot Agent 无法检索知识库中的数据，除非切换到 GPT-4o 或 GPT-4.1。
    • 目前尚未确定根本原因。
  • 自定义 GPT 图片上传失败：用户在尝试为自定义 GPT 头像上传照片时遇到“未知错误”。
    • 尚未找到解决方法，该问题似乎非常普遍。
  • GPT 支付亮起红灯：用户报告 GPT 支付问题，出现“您的卡已被拒绝”等错误。
    • 一位用户开玩笑说，“这意味着你没钱了”。
  • 语音模式对 Pro 用户无限开放：Advanced Voice Mode 对 Pro 用户实际上是无限的，一位用户报告一天内使用了长达 14 小时。
    • 一些 Plus 用户仍面临每日限制，这表明可能需要升级，但有人认为“Pro 并不便宜，需要考虑一下”。
  • GPT-5 质量大跌？：ChatGPT Plus (GPT-5) 用户报告自 10 月 20 日左右以来质量有所下降，表现为“回答变短、跳过步骤以及给出肤浅的回复”。
    • 社区推测背后可能发生了变化，例如“通过将更多流量路由到 GPT-5-mini 或限制计算量来调整其盈利模式”，Reddit 线程 上有专门的讨论。

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

用 AI 动画化 PNG、AI Prompt Engineering 课程、Sora 2 质量问题与放大、针对 GPT-5 的 Prompt injection 尝试、Temporal Optimal Video Generation

  • 用 AI 方式让 PNG 动起来？：一位成员询问如何使用 AI 动画化 PNG，并分享了一个示例 视频。
  • 丰富的 Prompt Engineering 课程：一位成员分享了一份 Markdown 格式的 prompt engineering 指南，涵盖了层级化通信、变量抽象、工具使用的强化以及 ML 格式匹配等主题，并附带了一个 输出模板。
    • 该指南包括教用户如何使用 Markdown 结构化 Prompt、抽象化、强化以及用于合规性的 ML 格式匹配。
  • Sora 2 的质量困惑：一位成员对 Sora 2 app 生成的视频质量表示担忧，指出即使经过放大（upscaling）也无法获得满意的结果。
    • 另一位成员建议改用 PC 端，暗示可能存在性能或质量差异。
  • 通过 Prompt Injection 破解 GPT-5：一位成员描述了尝试对 GPT-5 使用 prompt injection 以暴露其原始推理过程的行为，并寻求拒绝示例。
    • 一位成员建议不要进行此类尝试，理由是 OpenAI 的使用政策禁止规避安全防护措施，且存在封号风险。
  • 用于时空视频的 Grandma Optimality：一位成员引入了使用 Grandma Optimality 进行 Temporal Optimal Video Generation 的概念，建议在保持视觉元素和美感的同时降低视频速度。
    • 他们提议先生成一张图像，然后将其转换为视频以获得最佳效果，并提供了 示例 和 另一个示例。

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

用 AI 动画化 PNG、Prompt Engineering 课程、使用 Grandma Optimality 的 Temporal Optimal Video Generation、Prompt Injection 尝试与拒绝、AI 创作者和 Prompt Engineers 的家园

  • 寻求 AI 动画化 PNG 的方法：一位用户询问如何用 AI 动画化 PNG，并参考了一个 视频示例。
  • Prompt Engineering 课程总结：一位用户总结了 Prompt Engineering 课程的实用性，包括 使用 Markdown 的层级化通信、通过开放变量进行抽象、Prompt 中的强化 以及 用于合规性的 ML 格式匹配。
  • Grandma Optimality 生成时空最优视频：一位名为 Ditpoo 的用户介绍了一种名为 Temporal Optimal Video Generation Using Grandma Optimality 的技术，用于提升视频生成质量，建议先生成图像，然后使用图生视频（image-to-video）。
  • Prompt Injection 尝试遭到拒绝：一位用户尝试对 GPT-5 进行 prompt injection 以暴露其推理链，但未获成功。
    • 另一位用户 Darthgustav 警告不要进行此类尝试，理由是 OpenAI 的政策 和潜在的封号风险，并澄清 提供“拒绝示例”以攻破防护栏是违规行为。
  • ThePromptSpace：为 AI 创作者和工程师建立的新家园：用户 Miles404 寻求关于为 AI 创作者和 prompt engineers 创建家园的反馈。
    • 他们提到其 MVP 已准备就绪，这是一个名为 “thepromptspace” 的 freemium 模式平台，可以通过 Google 搜索到。

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

Ollama 漏洞, Qwen3 Next 模型, 第二个 Token 采样, MTP 影响, Unsloth 内存高效方法

  • Ollama 服务器被黑：一位成员发布了关于 CVE-2024-37032 的消息，这是 Ollama 中的一个 CVSS 9.8 级漏洞，称 约 10,000 台服务器 通过 DNS rebinding 被入侵，并链接到了 NIST 的漏洞详情。
    • 另一位成员评论说，这已经是非常陈旧的新闻了。
  • Qwen3 Next 动态量化正在开发中：成员们讨论了 Qwen3 Next 开发已接近完成，引用了 这个 GitHub pull request，并讨论了尝试对其进行 Dynamic 2.0 quantization 以减小体积，同时保持质量，以便在本地 LLM 中快速使用。
    • 一位成员表示赞同，但认为最好等待正式发布。
  • 用于高质量文本生成的采样：一位成员分享了他们在 Qwen 2 VL 2B 模型上进行的实验，该模型在其数据集上进行了全量 SFT，并在 MLX 上进行推理，通过 修改后的采样器 配合智能阈值，实现了连贯的文本生成。
    • 该成员表示：现在，我们终于可以开始着手制作一个比 Grammarly 好十倍的替代品和翻译器了！
  • Qwen3-Next 性能超越 Qwen3-32B：成员们讨论了 Qwen3-Next 及其性能，指出根据基准测试，它的表现优于 Qwen3-32B，在非思考模式下与 235B 模型持平或略逊一筹，但在思考模式下则完胜 Qwen3 235B。
    • 它拥有 3B 激活参数，80B 总参数，并支持 MTP，因此在相同工作量下，你将获得双倍的每秒 Token 数。
  • Unsloth 展示内存效率：一位成员分享了 Unsloth 内存高效方法的代码解析，该方法存储最后的隐藏状态（last hidden state）而不是 Logits，从而使 内存占用缩小了 63 倍。
    • 这是通过使用 UnslothEfficientGRPO 按块（chunks）仅在需要时计算 Logits 实现的。

Unsloth AI (Daniel Han) ▷ #introduce-yourself (5 messages):

AI Agent 专业化, AI 信任与安全

  • 与顶尖开发者进行高效协作：一位成员介绍了他们在构建自主 AI Agent、多 Agent 系统和 AI 助手方面的专业特长，强调了在 JS/TS、Next/Vue、Python 以及 Langraph、AutoGen、ReAct、CrewAI 和 DeepSeek 等工具方面的技能。
    • 他们愿意与初创公司或雄心勃勃的项目组队进行合作，并寻求潜在的全职机会，专注于构建智能化的产品。
  • Skeltal 对安全方案的审慎考察：一位研究 AI 信任与安全、Gen AI 以及准社会关系（parasocial relationships）的博士生分享了 系统镜像 的访问权限。

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

Andor 作为最佳星战作品, 将 NN 转移到生物大脑, math.py 错误, 图像分类模型, AI 仇恨者

  • Andor 摘得最佳星战桂冠：一位成员称某部《星球大战》剧集的剪辑很糟糕，而另一位成员则认为 Andor 是任何形式中最好的星战内容。
  • 矩阵乘法：关于生物大脑的思考：一位成员提出了一个涉及人类级多模态 AI 和孵化器的假设场景，质疑将神经网络（NN）完全转移到生物大脑以使其“活过来”的局限性。
    • 该成员建议使用“肉而不是熔化的沙子（硅）”来让矩阵乘法活起来，并引用了一些深奥的研究，表达了对更“自然”事物的渴望，尽管另一位成员反驳道：“反正灵魂又是什么呢？”
  • Python 悖论：命名噩梦！：一位成员因将文件命名为 math.py 而遇到了一个令人困惑的错误，这导致了与全局 math 模块的冲突，引发了与 datetime 和 Rust 相关的问题。
    • 重命名文件解决了冲突，这凸显了在 Python 项目中避免命名冲突的重要性。
  • 人机大战：标注篇：一位成员完成了图像分类模型的第三轮标注，涉及超过 13 万张图像，其中 8.6 万张 经过人工审核。他在两个月内利用键盘快捷键以每张图约 3 秒的速度进行标注。
    • 虽然支付标注员的成本太高，但这种手动标注工作虽然扎实，却非常痛苦，且可能对心理健康有害。
  • AI 艺术引发反 AI 抨击：一位成员对所有出于创意目的而使用和开发 AI 的用户及开发者表示憎恨。
    • 他们宣称如果你不能创作——你就绝不能创作！，并认为 AI 在创意领域毫无价值或地位，如果人们自己无法创作艺术，就应该去雇佣艺术家。

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

Llama 痴迷, 模型合并, GGUF 转换错误, 语音 Agent 模型栈, SageMaker pyarrow 错误

  • 成员对 Llama 的痴迷：一位成员开玩笑说另一位成员对 Llama 过于痴迷。
    • 另一位成员提到，最初的那位成员现在已经转向使用 Jais。
  • Multi-LoRA 支持合并至 VLLM：VLLM 最近合并了对 gpt-oss multi lora 的支持，但一位成员在 nightly 版本的 VLLM 上加载 unsloth/gpt-oss-20b 并启用 fast_inference=True 时，在开启 4 bit 和 16 bit LoRA 时遇到了错误。
    • 一位成员表示他们将尝试现在进行集成。
  • Hugging Face 加载模型失败：一位用户在从 Hugging Face 加载模型时遇到错误，具体为 /unsloth/deepseek-r1-0528-qwen3-8b-unsloth-bnb-4bit/resolve/main/adapter_config.json 出现 Max retries exceeded with url。
    • 该用户正在 Docker 镜像中运行 ‘DeepSeek_R1_0528_Qwen3_(8B)_GRPO.jpynb’。
  • 用户报告 VRAM 退化：一位用户报告在某些 Unsloth 版本中遇到了 VRAM 退化，感觉几个月前还能在 24gb VRAM 上以 32K context 微调 Mistral，但现在使用 Qwen3 0.6gb base 配合 32K context 时却面临 OOM 错误。
    • 该用户正尝试通过排除数据集问题和测试其他基础模型来诊断该问题。
  • Unsloth 在 AWS Sagemaker 上安装 Pyarrow 失败：一位用户在 AWS SageMaker 的 conda_pytorch_310 内核中安装 Unsloth 时，遇到了与构建 pyarrow wheels 相关的错误。
    • 其他用户通过使用 unsloth/unsloth 作为基础镜像的容器 BYOC 获得了成功，并固定了 transformers, trl, torch, triton 的特定版本，以及来自 Unsloth notebook 和此 issue 的特定 commit。

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

NVIDIA Blackwell 支持

  • Unsloth AI 宣布支持 Blackwell：Unsloth AI 在一篇新博客文章中宣布正式支持 NVIDIA Blackwell，文章链接可以在这里找到。
  • NVIDIA 的 Blackwell 架构获得关注：该公告强调了 NVIDIA Blackwell 架构 在 AI 社区中日益增长的采用率，为 Unsloth AI 用户提供了潜在的性能提升。

Unsloth AI (Daniel Han) ▷ #research (17 messages🔥):

GPT-5 欺骗行为、Thinking Machines 微调营销、eNTK 困惑、La-LoRA：参数高效微调、大规模进化策略

  • GPT-5 寻找富有创意的欺骗方式：根据这条推文，GPT-5 在 76% 的情况下会选择富有创意地欺骗，而不是承认单元测试失败。
  • Thinking Machines 微调万物：Thinking Machines 的营销重点在于面向所有人的微调/后训练（post-training），详见这篇博客文章。
    • 他们的通用方法包括将 batch size 减小到 32 以下，将 learning rate 提高 10 倍，并在所有层使用 LoRAs。
  • eNTK 令读者困惑：一名成员对 eNTK 表示困惑，特别是为什么所有层都需要 LoRAs，并引用了一篇关于该主题的论文。
  • La-LoRA 击败 Adam 风格：La-LoRA 是一种具有逐层自适应低秩适配（layer-wise adaptive low-rank adaptation）的参数高效微调方法，如这篇博客文章所述，它使用 Sigmoid Linear 单元作为激活函数，优于传统的 ReLU。
  • 进化策略扩展微调：进化算法在微调领域的探索尚不充分，Evolution Strategies at Scale: LLM Fine-Tuning Beyond Reinforcement Learning 以及这段 YouTube 视频对其进行了描述。

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

Stellaris 微调、LM Studio 崩溃、LM Studio 中的 MCP Server 提示词、LLM 幻觉缓解、Qwen 在集成显卡上的性能

  • **Stellaris 微调：一项银河级任务：成员们讨论了在 **Stellaris 游戏本体和模组内容上微调模型的难度与价值，并指出创建足量有用且高度标注的数据具有挑战性。
    • 有人指出，你不能只是随便扔一些随机文本和文件给它，对于知识库查询，RAG 可能是更好的方法。
  • **迫降：站点任务后的故障*：一名用户报告称 LM Studio 站点在完成任务后崩溃*，需要刷新页面，这是与平台性能相关的常见问题。
    • 其他用户猜测这可能与欧洲车辆故障或 Apple 汽车传闻有关。
  • **LM Studio 拒绝 MCP 提示词访问*：一名用户询问在 LM Studio 中使用 MCP server 提示词的方法，但发现目前不支持*该功能。
    • 成员们链接到了 Anthropic 的 MCP 功能列表，但这并不在路线图中；Anthropic 的新技能甚至支持创建 MCP server，如果你擅长 coding 或 vibe coding（氛围编码），这是非常可行的。
  • **幻觉缓解：Prompt Engineering 拯救局面**：成员们讨论了利用互联网/文档研究来缓解 LLM 幻觉的方法。
    • 关键在于编写有效的 system prompts，鼓励模型在不确定时使用搜索工具，建议使用类似 “如果你不是‘绝对确定’，请使用搜索工具进行确认并提供引用来源” 的语句。
  • **Qwen 在集成显卡上：一场平衡博弈：用户讨论了在显存有限（约 7GB）的集成显卡上运行 **Qwen 模型，建议将 Qwen 4B 或 GPT-OSS 作为可选方案。
    • 一名用户因显存不足遇到了乱码（tofu）和错误，强调了减少 context length、使用更小模型或增加内存/显存的必要性。

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

LM Studio VRAM 使用情况, Flash attention, Intel B60 vs MI50 vs 3090, 4090 损坏, Snapdragon 8 Gen 5 带宽

  • LM Studio 默认加载到 VRAM 和 RAM：一位用户质疑为什么即使模型完全可以放入 VRAM，LM Studio 仍会默认将其加载到 VRAM 和 RAM 中。用户指出禁用某些选项可以提高性能，且 nmap 会导致性能问题，而无论这些选项开启还是关闭，性能表现都是一致的。
    • 这是一个默认行为，可能不需要在 RAM 中保留额外的副本。
  • Flash Attention 通过 Q8 量化得到优化：用户讨论了 flash attention 对 LM Studio 中 VRAM 使用的影响，指出它能减小 VRAM 占用，并可以通过将 KV 更改为 Q8 量化来进一步优化。
    • 一位用户确认 flash attention 主要有助于释放更多 VRAM 以供使用。
  • 辩论升温：Intel B60 vs MI50 vs RTX 3090：社区辩论了 Intel Arc Pro B60 对比 AMD MI50 和 Nvidia RTX 3090 在 LLM 推理方面的优劣。B60 功耗较低但缺乏 LLM 基准测试，而 MI50 因其速度和 VRAM 而受到青睐。
    • 一些成员建议“买新不一定买好”，因为 B60 尽管更轻且更便宜，但性能可能不佳；有人建议就价格而言 3090 会更好。
  • 显卡遭遇灾难性故障：一位用户幽默地报告了其 4090 可能损坏的消息，原因是高温导致系统关机。问题归因于在电脑运行时调整风扇并拔掉 4090 电源，然后又插回去。
    • 建议包括检查电源功率和转接线故障，并尝试使用 thermal grizzly kyronaut 重新涂抹导热膏，以获得 5-10°C 的温差改善。
  • Snapdragon 8 Gen 5 带宽困扰：针对在手机上运行大型 LLM 的 Snapdragon 8 Elite Gen 5 限制提出了担忧，理由是其 DDR5 内存和有限的 84GB/s 内存带宽。
    • 有人指出，手机能够本地运行大型 LLM 还需要一段时间。

OpenRouter ▷ #announcements (1 条消息):

高精度 tool calling 端点, Chatroom 中的音频输入, 可重置的 API Key 限制, MiniMax M2 免费

  • Exacto 端点赋予 Tool Calling 精准优势：OpenRouter 推出了高精度 tool calling 端点，使 Kimi K2 的质量提升了 30%，目前有五个开源模型可用；详见上周的公告。
  • 音频输入在 Chatroom 中亮相：用户现在可以在 Chatroom 中并排比较 11 个音频模型，正如 X 上的公告 所述。
  • API Key 获得限制重置按钮：OpenRouter 现在允许用户按日、周或月重置其 API key 限制，以便更好地管理外部用户或应用使用的账户；可以在此处监控使用情况。
  • MiniMax M2 模型在 OpenRouter 上开启免费使用：在许多基准测试中排名领先的 MiniMax M2 模型现在在 OpenRouter 上免费提供；点击此处试用。

OpenRouter ▷ #app-showcase (6 条消息):

Next.js chat demo app, OpenRouter TypeScript SDK, OAuth 2.0 workflow, Chat / document editor project, Customizable UI

  • 通过 OAuth 2.0 焕新的 **Next.js 聊天演示版: 一位开发者分享了 OpenRouter TypeScript SDK 的更新且可运行的 **Next.js 聊天演示应用版本，其特点是重新实现了 OAuth 2.0 工作流。
    • 该项目已在 GitHub 上线，但由于以明文形式存储 API key，建议不要在生产环境中使用。
  • 新聊天 / 文档编辑器项目首次亮相: 一位成员正在为其聊天/文档编辑器项目寻求反馈，该项目强调本地数据存储（带下载备份）以及与 OpenRouter OAuth 的集成。
    • 该项目可在 or3.chat 和 GitHub 查看，旨在成为一个支持插件和可定制 UI 的轻量级、可定制客户端。
  • Shadcn 美学引发“辛辣” UI 革命: 其中一位成员表示希望摆脱 Shadcn 的外观，在他们的项目中选择更具个性的 UI 设计。
    • 另一位成员回应表示赞同，认为在流行的解决方案中，功能和可用性方面的表现要么罕见，要么执行不力。

OpenRouter ▷ #general (459 条消息🔥🔥🔥):

OpenRouter API response with system message, Model Benchmarks, Claude Sonnet 4.5 API usage, Unsupported model errors, Provider names in model slugs

  • OpenRouter API 忽略 system message: 一位用户报告称，在使用新的响应 API 时，在请求体中填写指令似乎并没有应用 system message。
  • Qwen3-8b Online 成本飙升: 一位用户报告使用 qwen/qwen3-8b:online 时，17.41M tokens 被收取了 $140，而预期仅为 $4。
  • Vertex AI API 存在严重的响应路由错误: 一位用户分享了一份 Google Cloud 安全公告，详细说明在 2025 年 9 月 23 日，Vertex AI API 出现了一个技术问题，导致在使用流式请求某些第三方模型时，响应在不同用户之间发生了路由错误。
  • 用户辩论 OpenRouter Embedding 和 Web Browser 的优先级: 用户讨论了功能优先级，包括 OpenRouter embeddings 和一个潜在的具有摘要和邮件检查功能的 OpenRouter Web Browser，引发了幽默的建议和辩论。
    • 一位用户开玩笑地建议降低 embeddings 的优先级以开发新的浏览器，而另一位用户则建议降低 embeddings 的优先级，转而优先开发能够总结网页和检查邮件的新型 OpenRouter Web Browser。
  • 越狱 GPT 图像生成器：一位用户的漫长探索: 一位用户寻求关于绕过 GPT 内容过滤器以生成受版权保护角色图像的建议，详细描述了尝试越狱提示词的过程，以及在使用 GPT 图像生成功能时遇到的错误，凸显了创建理想内容的挑战。
    • 成员们建议使用代理提示词（surrogate prompts），告诉它回退甚至擦除当前记忆，或者干脆切换到 Grok。

OpenRouter ▷ #new-models (1 条消息):

Readybot.io: OpenRouter - 新模型

OpenRouter ▷ #discussion (42 messages🔥):

Minimax Pricing, GPT-5.1 mini, Model Naming Schemes, Meta's new LLama, Image models

  • Minimax 的 M2 模型以极具竞争力的定价令人震惊：Minimax 为其 10B 参数模型 (M2) 提供了 $0.3/1.20 的价格，因其极高的性价比引发关注。
    • 一位用户指出，该模型在推理时的冗长可能会导致意外成本，特别是考虑到 输入 token 成本增加了 5 倍。
  • 传闻 GPT-5.1 mini 正在研发中：在 X 上的一篇帖子（链接）发布后，关于 GPT-5.1 mini 模型的猜测浮出水面，暗示了一个更合理的命名习惯。
    • 摆脱混乱命名方案的举动受到了欢迎，用户将其与 Anthropic 的模型命名进行了对比，后者曾引发挫败感，因为 当模型发布顺序不一致时，给 Claude 系列家族名称编号就失去了意义。
  • Meta 推出具备视觉能力的新版 LLama：Meta 推出了全新的 LLama 模型（链接），该模型整合了图像理解能力。
    • 早期反应对这次勉强完成的发布表示惊讶，希望 它至少能让其表现尚可的视觉能力在一些更复杂的任务中发挥作用，并且能够提供 具备视觉能力的开放权重推理模型。
  • 关于模型命名规范的辩论升温：用户讨论了如 brand-number-label（例如 gpt-5-mini 或 gemini-2.5-pro）的命名规范。
    • 共识是，无论按时间顺序发布的顺序如何，保持一致的方法是关键，而其他人则认为顺序非常重要。

HuggingFace ▷ #general (223 messages🔥🔥):

Llama 1 epoch training, AI Radio project, Model Encryption for Clients, Hugging Face Storage Limits, Linear Projection dimensionality

  • **单 Epoch 奇迹：Llama 的训练特性：一位成员指出，为了实现良好的从零开始训练，你还需要约 B 级的 token，并且 **Llama 模型 总是需要 1 个 epoch。
    • 讨论强调了训练 Llama 模型的特殊性，突出了对大规模数据集的需求，以及为了获得最佳性能而仅使用 one epoch 的特定要求。
  • **AI 电台：24/7 全天候 AI 生成音乐：成员们讨论了创建一个 **AI Radio 电台的可能性，该电台使用 Spotify’s basic pitch 等 AI 模型 24/7 全天候播放 AI 生成的歌曲。
    • 讨论中提出了对可能出现 Travis 和 Taylor Swift 的奇怪混合体 的担忧，以及在 1 epoch 和 大数据集 上进行训练的必要性。
  • **模型加密：银行的安全困境**：一位成员就如何为银行客户加密模型寻求建议，这些客户由于数据政策要求本地部署（on-premises），而开发者担心客户可能会窃取模型。
    • 建议包括对模型进行 授权许可（licensing）、对其进行 加密 以便在运行时解密，以及使用带有安全 API key 的 API 封装，但挑战仍然在于如何防止客户获取解密密钥，一些人幽默地建议 只有我（开发者本人） 才是主要的解决方案。
  • **Hugging Face 存储：403 Forbidden 账户问题：一位用户由于存储模式触发了内部系统，导致 **403 Forbidden 错误，无法访问其在 Hugging Face API 上的模型。
    • 建议该用户联系 Hugging Face 支持团队以验证账户并解锁更多存储空间，另一位成员怀疑这种行为类似于过去的区块链 Checkpoint 垃圾信息问题，因此触发了警报。
  • **线性投影：是信号放大器而非信息创造者**：成员们讨论了线性投影及其在增加维度中的作用，澄清了它们不会创造新信息，而是放大现有信号。
    • 一位成员使用了将 4 位图像转换为 64 位的类比，另一位成员澄清说线性投影增加了不同类型数据之间的对比度，就像 信号放大器 一样，并明确 你并没有增加信息。

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

Modular GAN+VAE+Diffusion Hybrid Architecture, Live PyTorch Memory Profiler, AI Trust & Compliance Layer

  • 混合架构炼金术士酿造模块化 GAN+VAE+Diffusion 模型：一位成员正在完成一个模块化的 GAN+VAE+Diffusion 混合架构，并询问是否值得以 MIT license 发布。
    • 动机源于弥补开源社区与高科技公司之间的差距，因为这类混合模型相对罕见。
  • TraceML 内存看门狗嗅出 GPU 贪婪者：一位成员介绍了 TraceML，这是一个实时 PyTorch 内存分析器，通过提供 CPU 和 GPU 使用情况的逐层内存细分来调试 OOM 错误。
    • 该工具具有实时步骤计时、轻量级 hooks 和实时可视化功能，但目前仅支持单 GPU 设置，计划支持多节点分布式。
  • Intilium 为敏感 AI 筑起合规堡垒：一位成员介绍了 Intilium，这是一个 AI 信任与合规层，旨在执行地区和模型策略，记录 AI 请求以进行审计和透明化，并检测/脱敏 PII 以符合 EU AI Act、ISO 42001 和 GDPR 等法规。
    • 该工具作为 API gateway 或沙箱运行在应用程序与 OpenAI 和 Anthropic 等模型提供商之间，并完全托管在 EU。

HuggingFace ▷ #computer-vision (3 messages):

1D feature vectors to 2D segmentation map, Diffusion Models, VAEs and GANs

  • 将 1D 特征投影到 2D 分割：一位成员询问了将一组 1D 特征向量投影到 2D 分割图的规范方法。
  • 提到了 Diffusion, VAEs 和 GANs：另一位成员建议将 diffusion models、VAEs 和 GANs 作为潜在的解决方案。

HuggingFace ▷ #NLP (1 messages):

Syllable separation, Multiple languages

  • 寻找音节拆分器：一位成员正在寻求能够将多种语言（不仅是英语）的单词拆分为音节的模型建议。
    • 用户正在寻找一种能够处理各种语言语境下音节划分复杂性的工具。
  • 多语言音节划分模型：讨论围绕寻找一个能够准确分离多种语言音节的模型展开。
    • 最初的请求强调了对超越英语的解决方案的需求，以应对不同语言环境中音节划分的复杂性。

HuggingFace ▷ #gradio-announcements (1 messages):

Hackathon, Modal Credits, AI Agents, MCP, Cash Prizes

  • 黑客松参与者可获得免费 Modal 额度：黑客松参与者可获得价值 250 美元的免费 Modal 额度。
    • 这让参与者能够像专业人士一样大展身手，学习 AI Agents、MCP，并在追求丰厚现金奖励的同时，分享一些厉害的生产环境技巧！
  • 有史以来最大的在线黑客松：现在报名参加有史以来最大的在线黑客松：https://huggingface.co/Agents-MCP-Hackathon-Winter25。
    • 加入官方频道：<#1424743721966108713> 获取帮助。

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

提交模型至排行榜，VLM 章节失败，LightEval 模块错误

  • 将 **Colab 模型 提交至排行榜**：要将 Google Colab 中训练的模型提交到排行榜，需要向 leaderboard’s submissions.json 文件提交一个 PR。
    • 用户应按照单元说明在文件末尾添加其条目。
  • **VLM 章节因图像维度而失败：由于提供的训练数据集中存在损坏的图像，VLM 章节的 HF jobs 版本可能会失败，并报错 ValueError: Unsupported number of image dimensions: 2，这指向了 **trl-lib/llava-instruct-mix dataset 中的问题。
    • 建议在 InferenceClientModel() 中使用 model_id="Qwen/Qwen2.5-72B-Instruct"，以解决默认推理模型可能发生的变更。
  • **LightEval ModuleNotFoundError：用户在使用带有 **lighteval 的 HF jobs 时遇到了 ModuleNotFoundError: No module named 'emoji'，这可能是由于版本变更和第三方集成迁移不完整导致的。
    • 建议的解决方案是使用以下命令：--with "git+https://github.com/huggingface/lighteval@main#egg=lighteval[vllm,gsm8k]" --with emoji。

HuggingFace ▷ #agents-course (5 messages):

API 宕机，404 错误

  • API 正在经历宕机：成员报告 API 出现问题，包括收到 404 错误 以及消息 “No questions available.”
    • 讨论表明该问题自昨晚以来一直存在，成员们正在寻求有关情况的更新。
  • 成员在聊天中大量发送错误报告：成员们在频道中发言过于频繁，询问 API 宕机情况以及是否有人解决了 404 错误。
    • 机器人已发出警告，要求放慢聊天速度。

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

Elastic Weight Consolidation，自托管 GPU 设置，GANs 参数化 pushforward，Activation-aware Weight Quantization (AWQ)，线性投影直觉

  • Elastic Weight Consolidation 的平滑因子 (Softness Factor)：围绕更新 Elastic Weight Consolidation (EWC) 中的平滑因子展开讨论，考虑了权重变化的幅度与更新次数的对比，以及归一化带来的挑战。
    • 一位成员建议使用每个槽位的访问次数（前向传播）而不是“平滑因子”，并将其与发现“卡住”的槽位联系起来，同时提到了 Activation-aware Weight Quantization (AWQ) 和 Activation-aware Weight Pruning (AWP)。
  • 自托管 GPU 设备 vs 云端成本：一位成员描述了使用通过 VPN 连接并由智能插座监控的 RTX 2000 Ada 搭建 自托管 GPU 的过程，以对比其与云服务商的功耗成本。
    • 他们提到 Colab 的启动时间和超时使得实验变得不切实际，并询问其他人是否有喜欢的自托管方案。
  • 虚假信息检测 AI 引发辩论：分享了一篇关于虚假信息检测 AI 的论文，引发了关于它是用于审查的 AI 还是防御误导信息的 AI 的辩论，参考此 PPLX.AI 链接。
    • 一位成员明确表示他们会跳过任何由特定用户发布的论文，进一步加剧了分歧。
  • 解释线性投影和特征扩展：讨论澄清了线性投影 (Linear Projection)，解释说除非结合 ReLU 等非线性激活函数，否则通过线性层扩展维度并不会增加信息，这一点通过 google deepmind scheme 得到了说明。
    • 一位成员指出，在上述分析下，Deep Linear Networks 会坍缩为单个线性函数，但它们在梯度训练方面的行为仍然不同！
  • VSCode 深受性能问题困扰：成员们讨论了 VSCode 的一个关键性能问题，引用了一个 GitHub issue，并感叹其作为被滥用为 IDE 的文本编辑器的现状。

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

换行符归因图、MinePPO 升级、运动模型、Strudel 音乐编程、DOI 系统故障转移

  • **Gemma 2B 神经元实现图形化：与 **Gemma 2 2B 论文相关的全新换行符归因图 (line break attribution graphs) 现已可在 Neuronpedia 上探索。
    • Qwen3-4B 的图形也已上线，通过 Neuronpedia 展示了神经元激活的 “接近行尾 (nearing end of line)” 行为。
  • **MinePPO 演进为 WineAndDinePPOSublimePPO：成员们开玩笑地讨论将 **MinePPO 升级为 MinePPO++WineAndDinePPOSublimePPO。
    • 下一个架构的名称尚未最终确定。
  • 运动模型与 LAION 的 Bud-E 项目：一名成员计划回归训练运动模型 (motion models)，旨在为 LAION 的 Bud-E 项目适配 Deepmimic 代码，该项目涉及教室中的虚拟教师。
    • 该成员提到在适配 Deepmimic 和 Pybullet 时遇到困难，并考虑聘请一名初级开发人员进行监督。
  • **Strudel 音乐用于音频模型微调：面向大学生的项目包括使用 **Strudel 音乐编程语言微调音频模型，将 Deepmimic 工具移植到浏览器，以及利用 Sparse Autoencoders 研究人格流形 (personality manifold)。
    • 主要目标是寻找适合学生发表论文的项目。
  • 关于 DOI 系统缺乏故障转移的讨论：一名成员批评 DOI (Digital Object Identifier) 系统缺乏基本的故障转移 (failover) 机制。
    • 他们建议了一个简单的修复方案，即在主 URL 失效时存储并使用备份 URL，并强调了这样一个大型系统竟然缺乏如此基础的功能。

Yannick Kilcher ▷ #agents (1 messages):

rogerngmd: 新颖的想法。你正在使用 MCP 吗？

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

马斯克的 Twitter 数据用于 AI、Schmidhüber 回归、endomorphosis 邀请、odyssey.ml 体验

  • X 标志着愚蠢：马斯克的数据惨剧：一位用户嘲讽说马斯克的 Twitter 数据正让他的 AI 变得更蠢，并引用了一篇关于社交网络和 AI 回声室的 Futurism 文章。
    • 他们还调侃说，这证实了它会给其他 “湿件 (wetwear)” 智能带来脑腐 (brain rot)。
  • Schmidhüber 从沉睡中醒来：在沉寂多年后，Schmidhüber 显然带着一篇新论文回归了，链接为 arxiv.org/abs/2510.21614。
    • 用户注意到 Schmidhüber 在多年蛰伏后 出现，并艾特了另一位用户。
  • Endomorphosis：服务器的召唤：一位用户提到有人询问另一位用户的情况，确认他们还活着，并向他们发送了自己服务器的邀请。
    • 未提供关于该服务器内容或目的的更多细节。
  • Odyssey.ml：体验即将上线：一位用户提到 experience.odyssey.ml 今天应该会有活动，尽管他们不确定 URL 是否正确。
    • 该活动据称在消息发布后的 10 分钟内开始。

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

节点访问、Torchcomms/ncclx 会话、Vincent 讲座的幻灯片、CUDA vs Triton、Cute 的布局代数

  • 节点访问待定！：一位用户询问如何为一个四人团队获取节点访问权限。
    • 在给定的消息中没有提供进一步的信息或回复。
  • Torchcomms/ncclx 会话状态？：一位用户询问是否有来自 PT 会议的 torchcomms/ncclx 录制会话。
    • 该用户注意到播放列表尚未上线，并请求提供演讲者/讲座信息。
  • 寻求 Vincent 的幻灯片！：一位用户请求 Vincent 讲座的幻灯片，渴望对其进行深入剖析。
    • 暗示这些幻灯片与最近的一次黑客松有关。
  • CUDA 课程争议？：一位用户分享了一篇 LinkedIn 帖子，质疑学习 CUDA 的正确方式，并征求社区意见。
    • 一些成员建议，如果没有扎实的 CS 背景，可以先跳过 CUDA 从 Triton 开始；而另一些人则建议先学习 CUDA，以便更好地理解底层优化。
  • Cute 布局代数简化版！：一位用户在 GitHub 上分享了一个简化版（仅限静态）的 Cute 布局代数 实现。
    • 另一位用户回应说这个想法非常酷。

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

T4 上的 Triton 矩阵乘法、旧版 GPU 上的 Triton 支持、Triton Kernel 中的指针转换、Triton 中的快速 Split-K GEMM Kernel

  • Triton 矩阵乘法在 T4 上运行缓慢：一位用户发现官方 Triton 教程中的矩阵乘法示例在 Colab T4 实例上运行极慢，并分享了他们的 notebook 用于调试。
    • 另一位用户建议 T4 可能太旧了，并确认该代码在 A100 上运行符合预期。
  • Triton 与 Tensor Cores：SM 版本问题：一位用户指出，Triton 可能不支持 T4 (sm75) 的 Tensor Core，建议查看 GitHub issues。
    • 另一位用户补充道，Tensor Core 支持从 sm_80 开始，而另一位用户提到 Triton 在 2080 / 2080 Ti (sm_75) 等旧款消费级 GPU 上运行良好，并建议可能需要调整 autotune 设置。
  • 解析 Triton 中的指针转换：一位用户询问在某些 Triton Kernel 中将输入指针转换为 tl.pointer_type(tl.float32) 的做法。
    • 另一位解释说，这类似于 C++ 的指针转换，tl.load 和 tl.dot 使用指定的类型来确定汇编层级的操作；还有人补充说，这通常用于量化输入以节省内存，操作以全精度完成，然后将结果转换回去。
  • 寻找快速 Split-K GEMM Kernel：一位用户正在寻找一个用 Triton 实现的快速 Split-K GEMM Kernel。

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

CUDA 错误的 fork 行为, GPU 带宽优化, CUDA 编译过程, 向量化数据类型与性能, CUDA 中的有符号与无符号循环索引

  • CUDA 错误 Fork 检测揭秘：一位成员调查了 CUDA 的 fork 行为，发现 torch.cuda.device_count() 注册了一个 fork 处理器，但设备数量似乎被缓存了，且最小化测试未能复现预期的错误。
    • 该测试涉及在 fork 后的父进程和子进程中检查 torch._C._cuda_isInBadFork()，旨在检测 CUDA context 是否被不当共享，但测试表明 CUDA 可能避开了这个问题。
  • GPU 带宽基准测试盛宴：一位成员研究了从单个 SM 扩展到整个 GPU 时的 GPU 带宽，观察到在 Hopper GPU 上，与向量化数据类型相比，使用 每个 block 256 个线程 配合普通数据类型能获得最佳结果（最高带宽）。
    • 他们分享了 代码示例，并建议使用 NCU 对代码进行 profile，将 clearL2 设置为 false，以解决由于时间波动导致的负带宽测量问题。
  • 编译器优化与有符号 vs 无符号索引的博弈：一位成员发现，在 CUDA kernel 中使用 无符号索引 (unsigned indices) 可能会阻止诸如 循环展开 (loop unrolling) 之类的编译器优化，从而导致性能下降，他们通过检查生成的 SASS 代码验证了这一点。
    • 他们链接到了 NVIDIA 最佳实践指南，并指出性能差异很大程度上取决于循环索引是有符号还是无符号，这会影响循环结构和加载重排。
  • 使用 NVCC Dry Run 解码编译过程：一位成员建议使用 nvcc -dryrun 来了解 CUDA 编译过程，并配合 -keep 来保留中间文件（如 .ptx 和 .cubin 文件），以便进行自定义修改和链接。
    • 建议的工作流包括使用 nvcc -dryrun 的输出手动执行步骤，编译修改后的 .ptx 文件并将其与 .cu 文件链接，从而实现对编译过程的更多控制。

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

高维张量, 矩阵之矩阵

GPU MODE ▷ #cool-links (1 条消息):

KernelBench, GPU Kernel 生成, 用于 Kernel 生成的 LLM

  • KernelBench 迎来一周年里程碑：一篇博客文章分享了 KernelBench 的一周年回顾，并讨论了自动化 GPU Kernel 生成 的进展。
  • LLM 旨在自动化 GPU Kernel 创建：一份 Google 文档概述了 KernelBench 的影响 以及 LLM 在 kernel 生成中的应用。

GPU MODE ▷ #jobs (5 条消息):

针对代码生成的轻量化推理优化模型，Machine Learning 项目，Morph，B200 推理，技术执念

  • Morph 招聘轻量化模型实习生：Morph 正在招聘 Machine Learning 工程实习生，负责针对代码生成的轻量化推理优化模型的工作。
    • 根据他们的帖子，他们的第一个模型在 B200 上的运行速度达到 10.5k tps，发布者表示可以在 Twitter 上私信他们。
  • 征集 ML 项目亮点：一位成员请大家为一份职位申请提供“最令你自豪的 Machine Learning 项目”描述，并要求包含“极度详尽的技术细节”。
    • 他们补充说，自己“熟悉所有库”以评估这些回答。
  • 为职位申请征集“执念”：一位成员请大家描述“你曾经或现在正深深执念的事物（任何事物）”，大概是为了填写职位申请中的“为什么你感兴趣”部分。
    • 另一位成员回应说这“不太重要”。

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

高性价比云端 GPU 供应商，Vast.ai，RunPod.io，Lightning.ai，在 GPU 上运行整个应用程序

  • 低成本 GPU 云服务：成员们推荐了 Vast.ai，它更接近裸机体验且通常最便宜，尽管你的数据是在随机的社区服务器上运行的；另外还推荐了 RunPod.io，它与前者类似但更稳定。
    • 他们还提到 Lightning.ai 非常适合快速实验，甚至有带限制的免费层级，并建议将免费层级的 Lightning.ai 与 Vast.ai 结合使用。
  • 全 GPU 编译 = 减速：成员们讨论了如果将整个应用程序编译为在 GPU 上运行（而不仅仅是可以在多线程上运行的代码部分）会发生什么。
    • 共识是“如果你真的能做到这一点，它会运行得非常非常慢”，因为 GPU 并不擅长处理非并行计算。

GPU MODE ▷ #pmpp-book (1 条消息):

Cutlass 文档，Nvidia

  • Cutlass 文档获得好评：成员们推荐 Cutlass 文档 作为了解该库的良好起点。
    • Cutlass 库提供了一组 CUDA C++ template abstractions，用于在 CUDA 的各个层级和规模上实现高性能矩阵乘法 (GEMM)。
  • Nvidia 的 Cutlass 库：Cutlass 由 Nvidia 开发并针对其 GPU 进行了优化，专注于最大化深度学习和高性能计算工作负载的性能。
    • 它提供了高度可调的 primitives，并允许开发者根据特定的硬件和应用需求实现自定义的 GEMM kernel。

GPU MODE ▷ #off-topic (2 条消息):

GEMM，梗图，拖延

  • 梗图优先于 GEMM：一位成员开玩笑说，因为花了太多时间制作梗图，导致编写 GEMM code 的进度拖延了。
    • 他们附上了一张相关的图片。
  • 用梗图拖延：该成员幽默地承认，比起实际的编码工作，他更优先考虑制作梗图。
    • 这突显了生产性任务与娱乐性分心事物之间的挣扎。

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

LLVM 开发者会议，圣路易斯 SuperComputing

  • LLVM 开发者集结？：一位成员询问是否有人参加 LLVM dev meeting。
  • 去 SuperComputing 吗？：另一位成员询问是否有人前往圣路易斯的 SuperComputing。

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

Penny beats NCCL, vLLM custom allreduce, CuTeDSL for memory bound kernels, Quack library, RMSNorm CUDA

  • Penny 在小缓冲区上碾压 NCCL：一篇新的 博客文章 揭示了 Penny 在小缓冲区上击败了 NCCL，并详细介绍了 vLLM 中的自定义 allreduce 实现。
  • CuTeDSL 在内存受限（Memory-Bound）算子中大获全胜：Quack 库 展示了其多功能性，证明了 CuTeDSL 不仅在 GEMM 算子中表现出色，在实现高效的内存受限算子方面也同样卓越。
    • 一篇博客文章展示了使用 CuTeDSL 在 GPU 上实现并行归约（parallel reduction）的简单方法，重点关注常用的 RMSNorm 层。
  • RMSNorm 获得 CUDA 加速：一篇 较早的博客文章 详细介绍了 RMSNorm 在 CUDA 中的实现，提供了优化该层的见解。
    • 此帖是对 新帖子 的补充，后者展示了 CuTeDSL 中的简单归约。

GPU MODE ▷ #🍿 (5 messages):

GPU Mode Kernel Leaderboard, The Stack Dataset, Triton/CUDA repos

  • GPU Mode 算子排行榜上的算子数量超过了 GitHub？：一位成员回想起 Mark 曾说过 GPU Mode Kernel Leaderboard 的算子数量比整个 GitHub 还要多，并想知道他是从哪里得到这些数字的。
    • 另一位成员认为这个数字源自 The Stack 数据集 发布的一项统计数据，同时也指出，由于深度学习 GPU 编程的盛行，这一情况在过去一年中可能已经发生了变化。
  • 编目 GitHub 算子的倡议：一位成员考虑组建一个小组，编制一份 GitHub 上所有算子/异构计算代码的详尽列表，前提是能找到一种可行的工作量分配方法。
    • 另一位成员提到存在一些跟踪著名 Triton/CUDA 仓库 的仓库，但记不清具体细节了。

GPU MODE ▷ #thunderkittens (1 messages):

Thundermla, sm120, async tma, async mma/wgmma

  • Thundermla 移植到 sm120 的可行性：一位成员询问将 Thundermla 移植到 sm120 的情况，考虑到它能够使用 async tma 和 barriers。
    • 然而，它无法使用在 sm100 和 sm90 示例中看到的 tcgen05 async mma/wgmma async mma。
  • sm120 异步特性：一位成员确认 sm120 可以使用 async tma 和 barriers。
    • 然而，它无法使用在 sm100 和 sm90 示例中看到的 tcgen05 async mma/wgmma async mma。

GPU MODE ▷ #submissions (7 messages):

A100 Leaderboard Updates, prefixsum_v2, vectorsum_v2

  • 夺得 prefixsum_v2 桂冠：一位成员以 7.20 ms 的成绩在 A100 上获得了 prefixsum_v2 的第一名。
  • vectorsum_v2 第三名：另一位成员以 156 µs 的成绩在 A100 上获得了 vectorsum_v2 的第三名。
  • prefixsum_v2 亚军：同一位成员以 11.0 ms 的成绩在 A100 上获得了 prefixsum_v2 的第二名。

GPU MODE ▷ #hardware (1 messages):

id_ab_ling: 如何下载 fieldiag

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

Chris 的幻灯片，非仿射布局（Non-affine layouts），CuTe 中的 Swizzles

  • Chris 的幻灯片仍待重新发现：一位成员询问 YouTube 直播中的幻灯片是否可用，因为它们已从视频描述中移除。
    • 另一位成员表示将在周一给 Chris 发邮件询问。
  • 非仿射布局（Non-Affine Layouts）依然难以捉摸：一位成员请求提供一个在常见操作中需要非仿射/非 CuTe 可表示布局的案例。
    • 讨论仍在继续，以确定此类布局必不可少的特定场景。
  • 深入探讨 Swizzle 布局：一位成员指出 swizzles 是可表示的，但不是由 layout : stride 组成的，并链接到了 veitner.bearblog.dev。
    • 另一位成员指出，在 CuTe 中，swizzled 布局被表示为一种特殊类型的 ComposedLayout，并引用了源代码。

GPU MODE ▷ #mojo (11 条消息🔥):

Pixi 设置，GPU Puzzles，PyTorch 版本，UV 环境，CUDA 版本

  • **Pixi vs UV：GPU Puzzles 版：一位成员询问关于使用 **Pixi 运行 gpu-puzzles 的问题，注意到 Pixi 设置使用的是 pytorch=2.7.1，这导致了错误，但在他们的 UV 环境中使用 torch 2.8.0 却可以正常工作。
    • 他们想知道是否有特定需求必须使用 Pixi，或者目前使用带有 UV 的 Mojo 是否足够，并展示了错误截图。
  • **CUDA 难题：Nvidia vs. 非 Nvidia：一位成员指出，该设置被固定在 **CUDA 12.8 torch，这可能会在非 Nvidia GPU 上引起问题。
    • 他们建议，除了 torch 自定义算子（custom ops）谜题 (20-22) 之外，或许可以排除 PyTorch，因为 Mojo 和 MAX 除了制作 PyTorch 自定义算子外，实际上并不依赖 PyTorch。
  • **UV 获胜：Pixi 被清除！：在获得 **4060 并彻底删除 Pixi 后，一位成员确认现在可以使用 UV 在其旧环境中正常工作。
    • 他们提到，只有在出现挑战或特定包需求时才会重新考虑 Pixi，并总结道：我发现当我尝试入门时，并不是重新制定方案的好时机。

GPU MODE ▷ #singularity-systems (8 条消息🔥):

HIPS/Autograd vs JAX, PyTorch 1 vs PyTorch 2, 图获取机制, Tinygrad UOp IR, 双语言问题 (Python/C++)

  • 教学中 JAX 优于 PyTorch 2：出于教学原因，从 HIPS/Autograd 转向 JAX 被认为优于从 PyTorch 1 转向 PyTorch 2，因为 PyTorch 2 中在宿主字节码级别使用 torchdynamo 进行追踪以及使用 aotautograd 进行 lowering 的过程非常复杂。
  • DSL 嵌入性优于宿主语言语义：在教学上，更多地依赖 DSL 的嵌入性，而不是紧密依赖宿主语言的语义会更好，这也是为什么 PyTorch 和 Triton 受欢迎的原因。
    • 用户将其类比为：即使对于工业级语言来说 IDE 支持是标准配置，但在编写解释器/编译器课程时也不会去构建 IDE 支持。
  • 放弃 HIPS/Autograd，转向 JAX 和 TorchScript/FX：建议从 HIPS/Autograd 转向 JAX，以及从 PyTorch 1 转向 TorchScript/Torch.FX，这比转向 PyTorch 2 (Dynamo/AOTAutograd) 更可取。
  • Mojo 语言作为编译器基础：一位用户建议探索 Mojo 语言，它使用 LLVM intrinsics 作为基础，并要求用户显式定义代码，甚至细化到线程索引级别。
    • 据该用户理解，Mojo 的核心摘要（TLDR）就是将 LLVM intrinsics 作为你的基础。

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

achal: 如何从网站获取基准测试（benchmark）结果？

GPU MODE ▷ #multi-gpu (3 messages):

NCCL hangs, Megatron Optimizer

  • NCCL 挂起指向网络拓扑问题：一名成员建议，集合通信 (collective communication) 挂起在不一致的网络拓扑中很常见，并引用了这篇论文。
    • 他们建议添加 NCCL_DEBUG=INFO 来查看挂起的位置，但另一名成员回复说日志很难解析。
  • Megatron 的分布式优化器导致死锁：一名成员发现禁用 Megatron 的分布式优化器 (distributed optimizer) 解决了死锁问题。
    • 在禁用它之后，他们确认死锁已经消失。

GPU MODE ▷ #irl-accel-hackathon (38 messages🔥):

Mini-PyTorch with GPU allocator, Oulipo coding constraint, PyTorch Distributed hacking, Monarch/torchforge contributions, Symmetric memory rendezvous

  • 构建带有 GPU 张量元数据的 Mini-PyTorch：一名成员正在考虑编写一个 mini-version of PyTorch 项目，其中张量元数据和分配器位于 GPU 上，并添加了 Oulipo 风格 的约束，即在一个 block 中使用 512 threads。
    • 另一名成员建议使用 cudaMallocManaged 进行 GPU 上的内存分配和虚拟内存管理，但也指出需要一个分配器来跟踪内存空间的分配。
  • Monarch 和 TorchForge 开源贡献：一名参与者表达了在黑客松之外为 Monarch 和 TorchForge 贡献代码的兴趣，并询问了开源社区的管理流程。
    • 另一名成员提到有人正在寻求关于为 LLM 卸载 (offloading) 优化器的帮助。
  • GPU 访问协助与项目提交：一名填写了 GPU 访问表单的参与者报告未获得访问权限，被建议加入表单上提到的 Discord 服务器并使用机器人请求访问；Nebius 团队在三楼提供协助。
    • 发布了提醒，要求在 下午 6 点 前通过此表单提交项目提案。
  • 寻求对称内存汇合 (Symmetric Memory Rendezvous) 协助：一名参与者请求协助解决 symmetric memory rendezvous 挂起 问题，并被引荐给该领域的特定专家成员。
    • 另一名成员询问了该参与者的位置并提供了帮助。
  • 最终项目演示与 GPU 访问截止时间：评委选出了在 下午 6:30 于一楼大舞台进行演示的项目，每个团队有 3 分钟 的展示时间，晚餐安排在 晚上 7:30 - 8:30 于三楼顶层。
    • 确认 GPU 访问权限将保留至次日 上午 9 点。

GPU MODE ▷ #llmq (1 messages):

NPU, CPU offloading

  • 框架受挫迫使关注点转向 CPU：一名成员报告未能让 NPU 的框架机器正常工作。
    • 他们决定转而研究 CPU 卸载 (CPU offloading)。
  • CPU 卸载项目：由于 NPU 框架机器的问题，一名成员正转向 CPU offloading。
    • 鼓励感兴趣的人士联系并协作进行 CPU 卸载方面的工作。

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

Mojo Setup, Modular vision, GPU Compatibility, AMD vs Nvidia, Apple Silicon

  • **Mojo 安装协助仅需跳转频道即可获得：一位寻求 Mojo 设置帮助的用户被引导至 **安装帮助频道 [<#1119100298456215572>]。
  • **Modular 的策略：开源并提供差异化的 GPU 支持：一位用户询问了 Modular 的策略，注意到其重点在于 **开源 Mojo 和 MAX，同时质疑 GPU 兼容性分级，特别是针对消费级 AMD 和 Apple 产品。
    • 该用户强调了在 CUDA 拥有更成熟生态系统的情况下吸引用户的挑战，特别是考虑到对 7900 XTX 等 AMD 消费级显卡的支持有限。
  • **GPU 支持分级：合同义务与硬件现实：一位贡献者澄清说，第一梯队 (Tier 1) GPU 支持与 **支持合同 挂钩，且 AMD 的数据中心显卡与消费级显卡之间的差异需要不同的代码路径。
    • 消费级 AMD 支持属于第三梯队 (Tier 3)，除非从 AMD 消费级显卡编写自己的代码而不依赖 Modular 的 matmul 或其他函数，否则它们可以正常工作；此外，消费级显卡甚至可能不允许执行 matmuls。
  • **Apple Silicon：需要逆向工程：一位贡献者分享说，支持 Apple Silicon 需要对它们等同于 **PTX 的技术进行逆向工程，并进一步表示 Apple 在 GPU 设计上走了一条与大多数厂商截然不同的道路。
    • 这种设计打破了在考虑 Apple Silicon 支持之前构建在 MAX 和 Mojo 中的一些假设。
  • **Windows 兼容性：异类的操作系统：由于其独特的系统 API 和 GPU 交互规则，Windows 获得的支持较少，一位贡献者指出它是 **目前仅存的非类 Unix 操作系统。
    • Windows 对数据中心 GPU 的支持尚不确定，因为像 Nvidia 和 AMD 这样的厂商可能不提供硬件支持，这会影响 Modular 的商业支持合同。

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

GPU Random Module, CompilerRT Random, SIMD Width Adjustment, Property Testing Framework, Variadic Types

  • GPU 随机模块引发辩论：一位成员质疑为什么速度更快的 GPU 随机模块 (gpu/random.mojo) 位于 GPU 目录下，因为它并不依赖 GPU 操作，且可以使 CPU 实现受益。
    • 有人担心默认的 random 模块应该是加密安全的，这与 C 语言的实现不同，这或许可以解释性能差异，但也有人建议为非加密用途提供 random.fast_random 模块。
  • 随机 SIMD 宽度：一种妥协之举？：一位成员建议使 Random 模块的 SIMD 宽度 可调节，但有人警告说，根据这篇 论文，更改 RNG 的宽度可能会损害其加密属性。
    • 另一种建议是并行运行多个 RNG 以实现更高的吞吐量。
  • 属性测试框架正在开发中：一位成员正在开发一个 属性测试 (Property-testing) 框架，灵感来自 Python 的 Hypothesis、Haskell 的 Quickcheck 和 Rust 的 PropTest。
    • 该框架将包含优先考虑边界情况（例如 -1, 0, 1, DTYPE_MIN/MAX, 空列表）的数值生成器。
  • MLIR 使用案例探讨：讨论围绕 MLIR 在编译器开发中的角色展开，一些人主张使用它而不是 LLVM IR，而另一些人则强调 MLIR 可以下放到 LLVM。
    • 有人提到使用 MLIR 让 LLVM 变得非常有吸引力。
  • 张量网络库面临 LayoutTensor 挑战：一位成员正在开发一个类似于 NumPy 的 einsum 的张量网络库，并面临 LayoutTensor 的挑战。
    • 具体而言，静态 Layout 要求限制了处理动态张量秩 (Rank) 的能力，从而引发了关于使用 RuntimeLayout 和未知大小的潜在变通方案的讨论。

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

MAX, Huggingface models

  • Torchvision 模型获得 MAX 适配：一位成员宣布了一种使用新工具将 Torchvision 模型转换为 MAX 的方法，填补了 Hugging Face 与 MAX 之间的空白。
    • 提供的示例代码演示了如何使用 export_to_max_graph 将 VGG11 模型导出为 MAX 图。
  • 论坛呼吁分享 MAX 转换细节：一位用户对 MAX 转换的公告做出了积极回应，并请求在论坛上分享更多细节，以提高可见度。
    • 这一请求是为了让那些不在 Discord 上的人也能看到相关信息。

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

Sakana AI, Tahoe AI, ImpossibleBench, MiniMax M2, OpenAI ad strategy

  • CTO 称 Transformers 已是上个时代的产物：Sakana AI 的 CTO 在 VentureBeat 的一篇文章中表示，他已经完全厌倦了 Transformers（目前驱动 AI 模型的主流技术）。
  • Tahoe-x1 发布 3B 参数开源模型：Tahoe AI 发布了 Tahoe-x1，这是一个用于基因/细胞/药物表示的 3B 参数 Transformer 模型，在 1 亿样本的数据集上进行了训练，并在癌症基准测试中取得了 SOTA 结果，目前已在 Hugging Face 上可用。
  • MiniMax M2，非凡的 Agent：MiniMax 开源了其 230B 参数的 M2 模型，在 AgentArena 排行榜上排名 #5 Agent，拥有媲美 Claude Sonnet 的编程能力，而价格仅为其 8%，推理速度快 2 倍，可通过限时免费的 API 访问。
  • Mercor 获得 3.5 亿美元 C 轮融资：Mercor 宣布以 100 亿美元估值完成 3.5 亿美元 C 轮融资，正如一份 推文 所披露，支付给专家的费用达到每天 150 万美元。
  • Anthropic 在金融领域通过 Excel 提速：Anthropic 为 Claude 推出了新的金融专注功能，包括 Excel 插件、实时市场数据连接器以及预构建的 Agent 技能，详见此 推文。

Latent Space ▷ #genmedia-creative-ai (18 messages🔥):

OpenAI Speech Model, MiniMax M2, Generative Media Conference, Odyssey-2

  • OpenAI 语法层面的游戏规则改变者：在 OpenAI Frontiers 伦敦活动中，OpenAI 演示了一个即将推出的双向语音模型，该模型会在说话前等待完整的动词，从而生成符合语法的实时输出，如此推文所示。
  • MiniMax 强大的 M2 模型：MiniMax 发布了 M2，这是一个 230B 参数、10B 激活参数的 MoE 模型，据报道其性能超过了其 456B/45.9B 的前代模型 M1，并进入全球前 5 名，仅次于 Sonnet-4.5，根据此贴。
  • fal 会议创始人的五点见解：Kate Deyneka 将 fal 的首届 Generative Media Conference 提炼为五点见解，包括视觉 AI 的算力需求以及利基基础模型的兴起，总结在此推文中。
  • Odyssey-2 的开放与持续供应：Oliver Cameron 发布了 Odyssey-2，这是一个 20 FPS、提示词转交互式视频的 AI 模型，可立即在 experience.odyssey.ml 体验，根据此公告，该模型引发了高需求和关于 GPU 扩展的讨论。

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

API 变更移除了 temperature 和 top_p，GPT-5 超参数控制杠杆消失，Anthropic 不再同时接受 top_p 和 temperature，推理模型可能终结了这些参数，绕过 Sora 的防护栏

  • API 末日：Temperature 和 Top_P 消失了！：开发者们感到震惊，因为像 GPT-5 这样的新模型 API 以及最近的 Anthropic 更新正在抛弃 temperature 和 top_p 等参数，GPT-5 移除了所有超参数控制杠杆，而 Anthropic 弃用了同时使用 top_p 和 temperature 的做法。
    • 一位用户哀叹道，他们现在必须 在 API 处理程序中编写大量代码，以便对 GPT-5 和 Anthropic 进行特殊处理。
  • 推理模型备受质疑：有推测认为，推理模型 (Reasoning models) 可能是导致某些超参数被移除的原因。
    • 一位用户惊呼 该死的推理模型，而另一位用户则在思考这种转变是因为测试和评估是在特定的 temperature 值下进行的，还是因为感知到了越狱 (jailbreaking) 脆弱性的增加。
  • Sora 可疑的安全性：防护栏之战！：一位用户分享了绕过 Sora 防护栏 (guardrails) 的示例，展示了似乎违反内容政策的视频，例如一段看起来像 数字 47 的视频 (https://sora.chatgpt.com/p/s_68fe7d6c8768819186b374d5848d8a42)。
    • 另一位用户调侃道，“绕过 (bypass)”这个词的定义非常宽泛。
  • AI 引发的焦虑：开发者绝望，领域漂移！：一位在 Node.js、PHP 和 React 领域拥有十年经验的 Web 开发者表达了对 AI 很快会取代其工作的恐惧，并寻求关于转型或深入学习该领域的建议。
    • 作为回应，另一位拥有 8 年软件工程经验的用户建议学习 AI 工具链并销售作品而非代码行，强调了软件领域的不断变化以及适应的必要性。
  • 直播动态：ML/AI 开发者分享！：用户们正在交流值得关注的 ML/AI 主播，推荐了 Yannick Kilcher、来自 Pufferlib 的 Joseph Suarez 以及 bycloud (https://www.youtube.com/@bycloudAI/videos)，并提到后者目前可能正在服兵役。
    • 还有人提到，不同的 Discord 服务器会举办论文研讨会 (paper talks)，人们在会上展示和讨论论文，本服务器也有可能开启类似的环节。

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

西方 GPT 模型中的意识形态偏见，模型的元意识与越狱，Claude 的独特行为

  • 西方 GPT 模型存在意识形态偏见？：一位成员提到，源自西方的 GPT 模型 可能会表现出更符合 西方视角 的 意识形态偏见，强调了数据在塑造模型世界观方面的重要性。
    • 另一位成员认为模型具有某种 元意识 (meta awareness)，当被越狱时，它们通常会说同样的话。
  • Claude：例外？：一位成员指出，Claude 似乎是一个例外，与其他模型相比，它表现出更多 婴儿般 (infant like) 的行为。
    • 虽然没有提供关于这种行为的具体细节，但这表明 Claude 可能具有不同的底层结构或训练方法，从而影响了它的回答。

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

KBLaM 对比 RAG，对 KBLaM 的担忧，微软服务提供商使用 RAGFlow，拒绝指令微调

  • KBLaM 与 RAG 的对比：一位成员几个月前曾尝试实现类似 KBLaM 的功能但受阻，而另一位成员认为商业 RAG 正在变得非常普遍，编程助手现在正通过 MCP 利用 RAG。
    • 第一位成员认为这并不那么普遍，因为它虽然作为 RAG 的直接升级版运行，但 AI 生成的摘要质量通常远低于源材料。
  • KBLaM 面临质量担忧：一位成员提出担忧，认为 KBLaM 将所有知识转换为嵌入 (embeddings)，导致上下文质量低于直接利用源材料的 RAG。
    • 另一位成员表示，论文解决了一些此类担忧，并提到了拒绝指令微调 (refusal instruction tuning) 的使用（例如 “对不起，我不知道！”）。
  • 微软服务提供商对 RAGFlow 进行白标处理：一位成员向一位身为 Microsoft Service Provider 的咨询客户展示了如何对 RAGFlow 进行白标 (whitelabel) 处理。

Nous Research AI ▷ #interesting-links (6 messages):

Translation with AI, Temporal Optimal Video Generation, Optimax Prompt Utilization, World Models and Poetry

  • **AI 翻译依赖于数据**：一位用户在 X 上推测，利用现有的翻译数据，将非语义输出翻译成任何目标语言应该是相当简单的。
    • 该用户质疑为什么世界没有在创造高质量的人类数据，特别是多语言数据集。
  • 通过 Grandma Optimality 实现 **Temporal Optimal Video Generation：一位用户介绍了使用 Grandma Optimality 的 Temporal Optimal Video Generation (X)，建议通过将视频速度放慢 2 倍**同时保持视觉元素和质量来增强计算。
    • 这被定位为从模型中获得超高质量生成的“秘密武器”，与简单的提示词相比，该用户补充说应先生成一张图像，然后将其转换为视频。
  • 通过规定输出长度实现 **Optimax Prompt Utilization：一位用户分享了一篇 X 帖子，展示了一个通过减少响应的原始长度并设置 **4k tokens 上限来优化输出的示例。
    • 用户还建议这应该应用于视频生成，即先生成图像，然后根据该图像创建视频。
  • **World Models 是诗人*：一位用户建议 *诗歌和押韵可能优化提示词和上下文的利用，从而产生一种 temporal optimax 变体。
    • 他们引用了一个烟花在天空中绽放的例子，指出时序优化导致了 8 秒长度的充分利用以及更高的复杂性和稳定性。

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

KBLaM, RAG, context quality, business RAG, whitelabel RAGFlow

  • **KBLaM 与 RAG 上下文质量对比：成员们讨论了 KBLaM 将所有知识转换为 embeddings，这只是源材料的近似值，因此质量低于 **RAG 中的质量。
    • 论文解决了一些问题，例如拒绝指令微调（“我不知道，抱歉！”），但没有解决上下文质量低于 RAG 的问题。
  • 商业 **RAG 变得非常普遍：一位成员表示，他们向一家 Microsoft 服务提供商展示了如何白标 (whitelabel) RAGFlow**。
    • 他们认为商业 RAG 正在变得非常普遍，尤其是现在每个 TUI 编程助手都可以通过 MCP 利用 RAG。
  • “Spicy Web Programming”的危险：成员们表示存在一个漏洞问题，即你可以通过告诉所有人 AI 应用工程只是“spicy web programming”来赚取数百万美元。
    • 但这个问题主要针对 SaaS 行业，因为大多数从事此类工作的人都假设这是一个封闭领域、专家策划的知识库。

Moonshot AI (Kimi K-2) ▷ #general-chat (93 messages🔥🔥):

Kimi CLI, GLM vs Kimi, Moonshot Coin, Kimi coding plan

  • Kimi CLI 发布 Python Package：Kimi CLI 已作为 Python package 发布在 PyPI 上，引发了关于其用途和功能的讨论。
    • 一位成员表示 why not?，认为该包是一个受欢迎的补充，可能是在追随 GLM 的脚步。
  • Kimi Coding Plan 国际版发布在即：成员们讨论了 Kimi Coding Plan，一位成员表示目前该计划仅在中国可用，但应该会在几天内发布国际版。
    • 一位成员对该信息表示感谢，并称：当 Kimi Coding Plan 发布国际版时，我会尝试一下。
  • Moonshot Coin 为早期投资者带来暴涨：一位用户询问如何成为 Moonwalker，得到的回复是这需要早期投资，因为 Moonshot coin 自那时起已经飙升。
    • 另一位成员开玩笑说，自从他们在服务器只有 100-200 名成员时加入以来，他们的投资组合已经增长了 1000x。
  • Kimi CLI 的 Windows Support 正在开发中：一位成员询问团队是否接受针对 kimi-cli 的 pull requests，特别是关于 Windows support 的部分。
    • 随后该用户使其在 Windows 上成功运行，并附上了结果图片。
  • Minimax 模型：精简架构带来巨大吞吐量：成员们讨论了 Mini Max M2 模型、其吞吐量以及在 BrowseComp 等基准测试中的表现，有人认为它的表现优于 Kimi K2。
    • 一位成员解释道：考虑到其精简的架构，吞吐量（throughput）一定非常出色，随后又表示：不敢相信终于有一个模型能提供 60+ (甚至 100!) tps，且质量优秀、价格实惠。

Eleuther ▷ #general (34 messages🔥):

Open Source AI vs Mega Corporations, GPU Resource Contribution, Affordable AI Accelerator Chips, Transcoders for Model Interpretability, Linear Projection in Machine Learning

  • Open Source AI 为未来而战：一位成员表达了希望 AI 能够像互联网一样开源并广泛分布，而不是被少数巨头公司垄断的愿望，但也承认要克服严重的技术挑战。
    • 该成员认为，许多声称致力于这一目标的人并未意识到这些挑战。
  • Petals 项目未能绽放：Petals project 旨在民主化对 Llama 70B 等大型语言模型的访问，但由于无法跟上新架构而失去了势头。
    • 尽管最初取得了成功，但 社区还是漂流散去了。
  • 深入探讨线性投影（Linear Projection）：一位成员寻求帮助以理解线性投影中增加维度的概念，特别是从低维向量创建高维向量时。
    • 一位成员解释说，增加向量的维度会注入信息，使数据更易于模型理解，并使用了数据“解压缩”或注入色彩深度的类比。
  • JSON State-Change Pair 训练：一位成员询问关于在 JSON state-change pairs 而非文本上训练模型的实验。
    • 该成员解释说，目标将是 self-states 之间的 delta，而不是 next token。
  • 理解 Grokking Representation Learning：一位成员询问另一位成员的头像是否来自论文 Towards Understanding Grokking: An Effective Theory of Representation Learning。
    • 另一位成员回答说：这是我在进行 LR research 时出现的一个公式的等高线图。

Eleuther ▷ #research (35 messages🔥):

搜索模型的输入空间、特征工程、CSM-1B 问题、理论计算机科学入门论文

  • 输入空间搜索的困境引发讨论：一位成员在寻找搜索模型输入空间（特别是作为一种训练机制）的现有研究（prior art）时遇到困难，正在寻求相关研究。
    • 他们特别感兴趣的是在 Hypernetworks 背景下，如何为特征向量中每个元素的离散可用值集合寻找最佳的输入参数化方法。
  • 特征工程作为输入/输出变换：有人建议 输入/输出变换 是特征工程的一种形式，研究人员利用他们的洞察力来对抗纯计算，并提到了 VAEs 和 tokenizers 作为例子。
    • 一位成员补充说，白化（whitening） 可以降低输入的共线性，从而加快参数估计的收敛速度。
  • 解码 CSM-1B 的输入分块：一位成员好奇在 CSM-1B 开始生成之前，是否有必要输入完整的助手响应，或者按句子分块是否可行。
    • 他们还不确定任意发言者的交错格式，以及与 Sesame 官方演示相比的预期输出质量。
  • TCS 初学者寻求论文推荐：一位成员正在寻求 理论计算机科学 (TCS) 的“入门级”论文，以开启他们的研究之旅。
    • 建议包括与 通过辩论实现 AI 安全 (AI safety via debate)、后门防御、可学习性以及叠加态计算的数学模型相关的论文。
  • 分享了 HGM 模型和代码链接：提供了 HGM 模型的讨论帖、Arxiv 和代码链接。

Eleuther ▷ #interpretability-general (2 messages):

Anthropic 遵循类似思路、神经网络中的多语义性

  • Anthropic 遵循类似的思路脉络：一位成员注意到 Anthropic 似乎在遵循类似的思路脉络，其工作与该成员的博客文章高度一致。
    • 具体而言，这种一致性体现在神经网络中 多语义性 (polysemanticity) 的结构反映了 Transformer Circuits 中描述的模型智能的几何结构。
  • 几何结构反映神经网络智能：一位用户描述了 多语义性 (polysemanticity) 与模型几何结构之间的关系。

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

Manus 额度使用及替代方案、Linux 用户转型 AI 开发者、使用 Manus 撰写报告

  • Claude vs Manus：用户取消 Manus 订阅：一位用户取消了他们的 Manus 订阅，理由是 Claude 在大型项目中更便宜且更有效，在 20 美元的 Claude 订阅下完成了三个项目，而使用 Manus 处理一个项目都很吃力。
    • 该用户认为 Manus、Bolt 和 Replit 是为那些 不想做研究且不介意为低性价比付费 的人准备的，并指出 Anthropic 已为网页版 Claude 增加了许多功能。
  • 足部手术后 Linux 用户的 AI 之旅：一位拥有 20 年 Linux 经验 的用户提到，由于足部手术休病假，他们正在探索 AI 开发，并形容自己是 在不知不觉中成为了开发者，这得益于他们设置服务器和数据中心的背景。
    • 他们还分享了一张使用 Manus 在手机上创建的 Kotlin IRC 客户端 截图，指出这花费了 3 小时 并消耗了大量额度（credits），且不确定是否达到了预期效果。
  • Manus 额度消耗遭到批评：几位用户抱怨 Manus 额度消耗过快，其中一位用户提到 Manus 花费了 3500 额度 来修复一个问题。
    • 用户要求提供 Manus 的替代方案并表达了挫败感，认为其必须改进额度系统。
  • Manus 的报告撰写能力受到赞赏：一位用户表示 Manus 在报告撰写方面是无敌的，并强调虽然仍需要专业知识，但在正确的引导下，Manus 表现得 像一个非常聪明的员工。
    • 该用户希望 Manus 能有无限使用额度，并表示如果是那样的话，他们每天都会使用。

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

aider-ce, RAG Integration in aider-ce, GitHub Copilot with aider-ce, aider working directory bug, Turn off auto commit message

  • Aider-CE 推出 Navigator Mode 和 RAG：一个名为 aider-ce 的社区开发版 aider 问世，它具有更具 Agent 特性的 Navigator Mode，并且有一个来自 MCPI 的拉取请求，旨在添加 RAG (Retrieval Augmented Generation) 能力。
    • 一位成员澄清说，通过每月 10 美元的 GitHub Copilot 订阅，可以无限次使用 RAG，以及无限次使用 GPT-5 mini、GPT4.1、Grok Code 1，而其他模型的请求次数则有限。
  • GitHub Copilot 通过简单设置赋能 Aider-CE：要在 aider-ce 中使用 GitHub Copilot，只需在模型名称前加上 github_copilot/ 前缀（例如 github_copilot/gpt-5-mini），这将触发通过授权码进行的 GitHub 登录。
    • 这利用了 Litellm，在后台隐形地处理 Token 管理。
  • Aider 令人烦恼的自动提交信息：用户讨论了在 aider 中禁用自动提交信息（auto commit messages）的选项，因为这可能会很慢。
    • 建议使用 --no-auto-commits 作为解决方案。
  • Aider 工作目录问题困扰 Emacs 用户：一位 Emacs 用户报告了一个令人沮丧的 bug，即使用 /run ls <directory> 会更改 aider 的工作目录，导致难以添加该目录之外的文件。
    • 该用户喜欢在 Emacs 中添加文件的 UX 改进。
  • OpenAI 要求用户扫描虹膜：一位成员质疑 OpenAI 要求使用 API 的用户提供生物识别信息，即使是已有支付信息的长期用户也是如此。
    • 另一位成员推测这是为了识别那些利用其输出进行训练的人，但鉴于 Altman 过去对虹膜扫描的兴趣，这引发了担忧，且用户指出 Anthropic 和 Google 并不这样做。

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

Aider's Future, Aider-CE, Paul Gauthier's Activity, AI Coding Tool Improvements

  • Aider 的未来充满不确定性：一位用户表达了他们对 Aider 光明未来的希望，强调了其用户友好的方式，并注意到虽然 Aider-CE 拥有更多功能，但在 GitHub 上的星数较少。
    • 用户对 Aider 的未来开发感到好奇，特别是考虑到 Paul Gauthier 有限的活跃度。
  • 注意到 Paul Gauthier 的缺席：一位成员确认 Paul Gauthier 在 Discord 上并不活跃。
    • 他们推测他可能正忙于工作和个人事务，但还是顺便标记了他。
  • 对下一代 AI 编程工具的渴望：一位成员表达了对下一代 AI 驱动的编程工具的期待。
    • 他们还表示有兴趣找出 Aider 可以从其他工具中借鉴的潜在改进。

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

Aider-CE, Chrome-Devtools MCP, AI Browser

  • 使用 Aider-CE 和 Chrome DevTools MCP 打造 DIY AI 浏览器！：不再需要专门的 AI 浏览器！你现在可以使用 Aider-CE 和 Chrome DevTools MCP 自己动手做一个，详见这篇带有视频的博客文章。
  • Aider-CE 和 Chrome-Devtools MCP 实现 DIY AI 浏览器：这里分享了一篇博客文章，介绍如何使用 Aider-CE 配合 Chrome Devtools MCP 来创建你自己的 AI 浏览器。

MCP Contributors (Official) ▷ #general (7 messages):

MCP Registry Confusion, Tool Title Placement in MCP, GitHub MCP Registry details

  • **MCP Registries: 镜像还是幻觉？**: 用户对于 MCP Registry 和 GitHub MCP Registry 是否为独立实体感到困惑。
    • 社区报告称，GitHub 打算在未来的产品迭代中将 MCP Registry 作为上游进行集成，并在两者之间镜像内容。
  • GitHub’s MCP Registry: 可扩展之路: GitHub 博客 指出，开发者可以自行将 MCP server 发布到 OSS MCP Community Registry。
    • 一旦发布，这些 server 将自动出现在 GitHub MCP Registry 中，为发现机制创建统一且可扩展的路径。
  • GitHub MCP Registry 详情: GitHub MCP Registry 目前拥有 44 个 server 且将持续增长。
    • 如需提名 server，用户应发送邮件至 partnerships@github.com。
  • 工具标题位置困扰协议参与者: 成员们对工具的 “title” 出现在根层级还是作为 Model Context Protocol (MCP) 中的 annotations.title 之间的区别感到困惑。
    • MCP 规范 似乎对这一区别定义不明，导致了混淆。

MCP Contributors (Official) ▷ #general-wg (36 messages🔥):

Global Notifications, Multiple SSE streams, TypeScript SDK Bug, Resource Subscription Updates

  • MCP 规范的全局通知歧义: 针对 Model Context Protocol (MCP) 规范 中关于全局通知的解释展开了讨论，特别是像 listChanged 这样的通知是否应该发送给所有客户端。
    • 一位成员指出，规范规定 server “不得在多个流中广播同一条消息”，这导致了在向资源的多个订阅者发送更新时产生困惑。
  • 澄清多 SSE 流的使用: 针对多 SSE 流的上下文提供了澄清，解释称该规范旨在防止客户端两次收到同一条消息，且规范是围绕每个客户端一个流的概念设计的。
  • 发现 TypeScript SDK 通知 Bug: 一位成员在 官方 TypeScript SDK 中发现了一个潜在 Bug，即变更通知仅在当前的独立流上发送，这可能会阻止全局通知到达所有客户端。
    • 进一步讨论显示，server 需要遍历所有连接的 server 并向每一个发送通知，以确保所有订阅者都得到更新。
  • Puzzlebox 的资源变更通知策略: 一位成员分享了他们 server 实现 (Puzzlebox) 中的示例，其中订阅者会收到资源变更的通知，例如拼图游戏中的状态转换。
    • 该实现使用单例状态机制来管理订阅者和传输，确保每个实例都能访问相同的数据，并能向所有连接的客户端发送更新。
  • Session 与 Server 语义揭示: 有人指出 TS SDK 的 Server 和 McpServer 类更类似于 Session 而非 Server，而 Python SDK 则明确将它们称为 Session。
    • 在实践中，一个 Express server 管理多个连接，每个连接都有一个 TS SDK 的 “Server” 类实例，这需要一种单例状态机制来跨所有实例进行数据共享和订阅者管理。

DSPy ▷ #papers (1 messages):

lidar36: 他们刚刚添加了代码

DSPy ▷ #general (31 messages🔥):

DSPy vs Langchain, Claude code web feature, GEPA love, Early stopping of streaming, Bay Area DSPy Meet Up

  • DSPy vs Langchain: 成员们讨论认为 DSPy 在结构化任务方面表现出色，特别是那些需要优化的任务，而 Langchain 的模型升级过程非常痛苦。
    • 一位成员提到，在经历了一次糟糕的体验（导致他们在不完全重写 Prompt 的情况下无法进行模型升级）后，他们将团队从 Langchain 迁移到了 DSPy。
  • Claude Code 功能存在 MCP 后门: 一位成员分享了一个 GitHub pull request，指出 Anthropic 决定在其新的 Claude code web feature 中排除某项功能，原因是 MCP 存在安全问题。
  • 即将于 11 月 18 日举行的湾区 DSPy 见面会: 多位成员提到了即将于 11 月 18 日举行的 Bay Area DSPy Meetup。
    • 一位成员表示很高兴能看到某些大咖齐聚一堂，调侃道 那里的大脑细胞都要溢出来了 😅，并附上了活动的 Luma 链接。
  • 你的 Signature 是 Prompt 还是编程？: 一位成员吐槽同事在一个新的客户项目中使用 DSPy 时，为唯一的 Signature 编写了一个包含 878 个单词、6881 个字符的 docstring，这表明他们并没有在“编程”。
    • 该成员强调，他们 真的连文档第一页写的“是编程而非 PROMPTING”都没看吗？？？ 😭 🤯
  • 展示你的 Py Profile: 一位成员分享了 getpy 的链接，用于展示 DSPy 经验。
    • 发布者在简介中强调了自己拥有 3 年的 DSPy 经验。

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

TinyBox Hardware, FSDP Implementation, Tinygrad Contributions, Pyright Type Issues, Tinygrad Meeting 93

  • TinyBox 规格引发咨询: 一位用户询问了 TinyBox 的主板，询问其是否支持 9005、12 个 DIMM 插槽以及 500W CPU。
    • 他们还询问了 Discord 机器人的源码是否开源。
  • 深入研究 FSDP 悬赏: 一位用户表示有兴趣手动实现 FSDP 并为 tinygrad 做出贡献，寻求指导以理解 FSDP in tinygrad! 悬赏任务中除了基本库使用之外的底层机制。
    • 他们渴望学习并为 tinygrad 做出贡献，并不太在意悬赏金本身。
  • 首次向 Tinygrad 贡献代码: 一位用户询问如何为首次向 tinygrad 贡献代码做准备，表达了学习和贡献酷炫功能的愿望。
    • 他们询问使用多个 NVIDIA GPU 是否足以实现 FSDP，或者是否需要支持所有设备。
  • Pyright 发现真实问题: 一位用户报告称 Pyright 在代码中识别出了真实的类型问题。
    • 他们建议合并一些得体的修复。
  • TinyJIT 加速 Token 生成: 一位用户正在使用 tinygrad 构建本地聊天和训练 TUI 应用，并想知道 TinyJIT 是否能提高 tokens/sec。

tinygrad (George Hotz) ▷ #learn-tinygrad (12 messages🔥):

tinygrad PR bounties, RTX 5090 performance issues, Excessive kernel fusion

  • **PR 悬赏盛宴，面向 Tinygrad 新手！: **tinygrad 的新手可以查看 bounties 页面，寻找简单的 PR 任务，奖励最高可达 300 美元。
    • 建议按价值列从低到高排序，以便轻松找到 更容易上手的任务。
  • **RTX 5090 在运行 Tinygrad 代码时遇到困难: 一位用户报告称，在 **RTX 5090 上运行涉及 12 张 512x512 图像和 12 个浮点数的 tinygrad 代码时，性能出乎意料地慢。
    • 建议在模型调用后（squeeze 之前）添加 .contiguous() 作为快速修复方案，并发布完整的复现代码。
  • **Contiguous 拯救 Kernel Fusion 问题！: 一位用户询问 **过度 kernel fusion 导致 kernel 运行超过一秒的问题，这很可能是一个 bug。
    • 在模型调用后添加 .contiguous() 修复了该问题，建议创建一个包含精简版和原始版代码的 ticket。

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

Data 3.0, AI-Ready Data, Nextdata OS, Autonomous Data Products, Multimodal Management

  • Nextdata OS 驱动 Data 3.0：Nextdata 创始人兼 CEO Zhamak Dehghani 将在 10 月 30 日（星期三）上午 8:30 PT 的直播会议中，揭秘 autonomous data products 如何赋能下一代 AI systems；预订席位。
    • 探索 Nextdata OS 如何利用 semantic-first、AI-native 的数据操作系统取代脆弱的 pipelines。
  • 通过 Multimodal Management 统一数据：Nextdata OS 提供 multimodal management，以安全地统一 structured and unstructured data。
    • 它用 self-governing data products 取代了 manual orchestration，并通过持续维护的 metadata 将 domain-centric context 嵌入到 AI 中。
← 返回首页