Mistral 回来了！

2025年12月1日至12月2日的 AI 新闻。我们为您查看了 12 个 Reddit 子版块、544 个 Twitter 账号和 24 个 Discord 社区（205 个频道，9665 条消息）。预计节省阅读时间（按 200wpm 计算）：697 分钟。我们的新网站现已上线，支持完整的元数据搜索，并以精美的 vibe coded 方式展示所有往期内容。请访问 https://news.smol.ai/ 查看完整的详细新闻，并在 @smol_ai 上向我们提供反馈！

我们最后一次看到 Mistral Small 3 是在 1 月，3.1 是在 3 月，随后主线模型转向了 Mistral Code、Magistral 和 Voxtral。在以 117 亿估值融资 17 亿之后，Mistral Large 3 终于面世，同时发布的还有三种尺寸的 Ministral（博客文章），全部采用 Apache 2.0 协议开放权重。

Mistral Large 3 性能对比图表，展示了多个 AI 模型和评估指标的基准测试结果。

虽然发布时机紧随 Deepseek V3.2（开源模型第 6 名，文本类第 28 名）之后有些遗憾，但这仍是欧洲 AI 取得的显著成就。正如 Anj 指出的，这是在 Mistral 的旧集群上训练的——随着新资金的到位，一个规模大 6 倍的计算集群将于 2026 年上线。

AI Twitter 回顾

Mistral 3 系列：开源、多模态且无处不在

• Mistral 3 发布（Apache-2.0，开放权重）：Mistral 发布了多模态 Ministral 3 (3B/8B/14B)，包含基础版 (base)、指令版 (instruct) 和推理版 (reasoning) 变体，以及 Mistral Large 3 —— 一个总参数量为 675B、激活参数量为 41B 的稀疏 MoE 模型，支持 256k 上下文和视觉输入。所有模型均在宽松的许可证下发布，拥有广泛的平台支持和强大的小模型性能。详情：@MistralAI，新闻，Ministral 尺寸，Large 3。

  基础设施和生态系统在发布首日即同步上线：vLLM 支持（NVFP4 检查点、稀疏 MoE 内核、长上下文、多模态），llama.cpp 集成 + RTX 性能提升，Ollama 模型 + 云端，LM Studio 目录。社区指南和格式也迅速发布：Unsloth 运行手册 + GGUF 格式。

  早期评估：Arena 将 Mistral-Large-3 排在 开源模型第 6 位（编程能力强；总榜第 28 位），并指出其测试代号为 “Jaguar” (@arena)。从业者报告称，其指令遵循能力优于当代的开源基准模型，并提供了针对单个 A100/8×H100 节点的 NVFP4 检查点 (@dejavucoder)。

  浏览器与本地：3B 版本可在 WebGPU 中 100% 本地运行 (@xenovacom)。

• 其他模型发布：Apple 在 HF 上发布了 CLaRa-7B-Instruct (推文)。Runway 预览了具有更高“电影级写实感”的 Gen‑4.5，并开始了早期访问推广 (推文)。Moondream 展示了“真正理解场景”的强大分割能力 (推文)。

Anthropic：收购 Bun、非营利项目以及 AI 如何改变工作方式

• Bun 加入 Anthropic：Anthropic 收购了采用 MIT 许可的 Bun JS/TS 运行时，以加速 Claude Code 的开发。Bun 将保持开源；Bun 团队加入 Anthropic，继续构建 Bun 并深化与 Claude Code 的集成 (Anthropic, Bun, @_catwu, @mikeyk)。社区注意到，据报道 Claude Code 在正式发布（GA）后约 6 个月内达到了 10 亿美元的年化营收（run-rate） (@alexalbert__)。
• Claude 面向非营利组织：与 GivingTuesday 合作，为非政府组织（NGO）提供折扣计划、新集成和培训 (公告)。
• AI 如何改变 Anthropic 内部工作：对 132 名工程师和 20 万次 Claude Code 会话的调查显示：工程师首先依赖 Claude 解决问题，这改变了团队动态；公司计划开展更广泛的内部研究和组织应对 (推文串, 后续)。

前沿基准测试、泄露与竞争定位

• OpenAI “Garlic” 泄露与 GPT-5.1：The Information 报道称，OpenAI 的新型预训练模型 “Garlic” 在编码/推理方面表现优于 GPT-4.5 (报道；引用：Mark Chen)。OpenAI 发布了关于 GPT-5.1 Instant 的播客，详细介绍了推理、个性控制和行为优化 (推文)。
• DeepSeek V3.2 与 Speciale：多项分析强调 V3.2（及 Speciale）是“高性价比前沿”模型，但存在显著权衡：生成速度较慢（约 30–40 tks/s）且推理链非常长（平均推理输出为 20k–47k tokens），但价格极低（例如在某些评估中，Claude 4.5 Sonnet Thinking 为 35 美元，而其仅为 3 美元），并在 LisanBench 上创下新高；更新后的评分显示 Speciale 在较易子集上的得分达到了令人印象深刻的 8.81 (概览, 评分修正, 关于冗长/上下文的讨论)。Fireworks 指出 API 已在发布首日上线 (推文)。
• Arena 排名与生态系统：Mistral-Large-3 进入 LMArena Text 排行榜（编码能力强，在多个职业领域排名前 10） (推文)。OpenRouter 推出了 Mistral Large 3 和 Amazon Nova 2 Lite 的访问权限 (Mistral, Nova Lite)。

Amazon Nova 2.0（推理、Agent 能力、多模态）与 Nova Sonic 2.0（语音对语音）

• Nova 2.0 家族：Amazon 发布了 Nova 2.0 Pro（推理，预览版）、Lite（速度/成本）和 Omni（文本/图像/视频/语音输入；文本/图像输出）。早期第三方基准测试显示，其相较于 Nova Premier 有实质性提升，并具备竞争力的 Agent 能力：Nova 2.0 Pro 在中/高推理预算下，在 τ²-Bench Telecom 上达到 93%，在 IFBench 上达到 80%，Pro 定价为每 100 万输入/输出 tokens 1.25/10 美元 (分析, 后续)。Nova Lite 的基准测试已单独发布 (推文)。
• Nova Sonic 2.0（语音对语音）：新型实时双向音频模型在 Artificial Analysis Big Bench Audio 中排名 第 2（推理得分 87.1%），中值首个音频响应时间（time-to-first-audio）为 1.39s；支持五种语言和自适应韵律 (推文串)。OpenRouter 提供为期 2 周的 Nova 2 Lite 免费试用 (推文)。

Agents、工具链与安全性

• LangSmith Agent Builder (公开测试版)：无代码 Agent 构建器，可创建 Prompt、选择工具/子 Agent，支持 MCP 服务器、触发器 (Gmail/Slack) 以及可配置的记忆/摘要策略 (发布, 概览, Chase 视频)。
• LlamaIndex 发布：LlamaAgents（可部署的 Agent 工作流模板）和 LlamaSheets（深度电子表格解析/提取），本周将举行社区办公时间 (回顾, 邀请)。
• Hugging Face Skills：一种“Agent 上下文的通用实现”，兼容 Cursor、Claude Code、Gemini CLI 以及本地/远程任务；使用 Claude Code 的技能规范，但为其他生态系统提供了入口点 (推文)。
• 浏览器 Agent 的 Prompt 注入防御：Perplexity 开源了 BrowseSafe 和 BrowseSafe‑Bench；在基准测试上进行微调的效果优于现成的安全分类器和 LLM‑as‑detector 方法，同时避免了推理延迟 (公告, 结果)。
• DevEx：微软的 Tangle 开源了一个基于内容的缓存实验平台，带有可视化编辑器（声称在 Shopify 节省了“1 年以上的 CPU 时间”）(推文)。Cline 发布了 /explain‑changes 和一个用于 Agentic 编程的隐形 256k “microwave” 模型 (发布, 模型)。

研究亮点

• 测试时计算量缩放 (Test‑time compute scaling)：一项大规模研究和选择策略的“秘籍”表明，TTS 能可靠地提升复杂推理能力而无需重新训练；其有效性更多取决于分配策略而非原始计算量 (摘要, 论文)。
• 深度研究 Agent 受到审查：OPPO 的 FINDER 基准测试（100 个任务；419 个检查项）和 DEFT 故障分类法（14 种模式）显示，Agent 并非在任务理解上失败，而是在证据整合、验证和规划上失败；建议通过架构调整将检索与综合联系起来 (概览)。
• 务实的可解释性 (Pragmatic interpretability)：Neel Nanda 主张在务实的可解释性中开展 CoT 的基础科学研究，其方法可直接应用于前沿 LRM；反驳了关于可解释性已“失败”的炒作，并重新界定了优先级 (澄清, 技术)。
• AI x 芯片，递归改进循环：前 DeepMind 负责人 Azalia Mirhoseini 和 Anna Goldie 创办了 Ricursive Intelligence，旨在共同演进模型和芯片（架构→验证→实现），以实现递归自我提升；其根源在于用于多代 TPU 的 AlphaChip (公告, 创始人推文串)。
• 额外福利：Elicit 增加了大规模图形解析功能（Kaplan–Meier 曲线、热图、反应方案、显微镜图像），将多模态推理从文本/表格扩展到系统综述 (推文)。

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

• Anthropic 收购 Bun；Bun 保持 MIT 许可并加入以增强 Claude Code (Anthropic, Bun)。
• Mistral 3 系列发布，涵盖各种尺寸的开源权重、MoE Large 3 以及多模态支持 (@MistralAI)。
• Waymo 安全评论文章引用了约 1 亿英里的无人驾驶里程，显著减少了严重伤害和交叉路口碰撞 (@slotkinjr)。
• OpenAI 播客讨论 GPT‑5.1 的训练决策、推理和行为优化 (@OpenAI)。
• Apple 的 CLaRa‑7B‑Instruct 在 Hugging Face 上发布 (推文)。

AI Reddit 回顾

/r/LocalLlama + /r/localLLM 回顾

1. Mistral 3 模型家族发布

• Mistral 刚刚发布了 Mistral 3 —— 一个从 3B 到 675B 参数的全系列开源权重模型家族。 (热度: 614): Mistral 发布了 Mistral 3 模型家族，涵盖了从 3B 到 675B 参数的模型，全部采用 Apache 2.0 许可证，可用于研究和商业用途。该系列包括紧凑型的 Ministral 3 模型（3B、8B、14B），它们是多模态的，并提供基础版、指令版和推理版变体，以其相对于尺寸的强劲性能而著称。旗舰模型 Mistral Large 3 是一个拥有 675B 参数的混合专家（MoE）架构模型，提供强大的多语言能力和高效率，使其成为目前最强大的开源权重指令模型之一。此次发布支持了向开放 AI 生态系统的转变，提供了一系列适用于端侧和大规模企业级应用的模型。完整公告。 评论者对缺乏 14B 到 675B 参数之间的模型表示失望，一些人希望看到 80B 到 400B 范围内的模型。此外，人们还渴望出现能与 GPT-OSS 120B 竞争的模型，并关注那些能在消费级 GPU 上高效运行的模型。
  • jzn21 指出了 Mistral 模型阵容中的空白，注意到缺少 14B 到 675B 参数之间的模型。这一差距对于对 80B 到 400B 范围感兴趣的用户来说意义重大，因为这个范围通常被认为是平衡性能和资源需求的黄金分割点。
  • fungnoth 讨论了与 GPT-OSS 120B 模型竞争的需求，特别强调了大型混合专家（MoE）模型的潜力。这些模型可以通过仅激活一部分专家来有效利用消费级 GPU，从而保持速度和效率。
  • Adventurous_Cat_1559 对可以在 96GB Mac Studio 上运行的 120B 参数模型表示感兴趣，这表明了对那些在高端消费级硬件上仍然可行的超大参数模型的需求。这反映了让更多用户能够使用大型模型而无需企业级资源的广泛兴趣。
• Ministral-3 已发布 (热度: 356): Ministral-3 已经发布，包含三个模型：14B、8B 和 3B，每个模型都有推理版、指令版和基础版变体。其中最大的 Ministral 3 14B 因其性能可与更大的 Mistral Small 3.2 24B 相媲美而受到关注，提供先进的语言和视觉能力。这些模型已在 Hugging Face 上架，旨在为各种应用提供高效部署。 评论者对模型的 tool-calling 能力感到好奇，并表达了希望将其与 Mistral Small 24B 等更大模型进行性能对比的愿望。
  • StyMaar 强调了 Ministral-3 基础模型的发布，这对于希望构建自定义应用或针对特定任务微调模型的开发者来说意义重大。与预训练模型相比，此次发布提供了更多的灵活性和实验空间。
  • throwawayacc201711 质疑为何缺乏 Ministral-3 与 Mistral Small 24B 等更大模型的对比。此类对比对于理解性能提升和权衡（特别是在计算效率和准确性方面）至关重要。
  • human-exe 认为 Ministral-3 的表现优于并有可能取代 Qwen3 和 Gemma3 等模型。这暗示 Ministral-3 可能提供更好的性能指标或效率，使其成为这些模型用户的更具吸引力的选择。

2. 蒙古的 GPU 租赁市场

• 你会以约 $5/小时的价格在蒙古租赁 B300 (Blackwell Ultra) GPU 吗？（市场合理性检查） (热度: 446): 蒙古的一个团队正以约 $5/hr 的价格在乌兰巴托的数据中心提供 B300 (Blackwell Ultra) GPU 租赁服务。该配置包括 3.2 Tb/s InfiniBand 以及预装的 PyTorch 和 SLURM，延迟测试显示到北京约 ~35 ms，到新加坡约 ~110 ms。该帖子寻求关于此方案与 CoreWeave 和 Lambda 等成熟供应商相比的可行性反馈，以及“寒冷草原的裸金属中立性”是否是一个引人注目的特性。这些 GPU 提供完整的 root 权限且无 hypervisor，强调中立的司法管辖区，无意外的法律干预。落地页 提供了更多细节。 评论者认为，如果服务稳定且安全，该方案可能具有吸引力，有人建议与 TensorDock 或 DeepInfra 等成熟供应商合作，这些供应商以竞争力的价格提供类似服务。“中立领土”这一独特卖点被认为可能有益，但需要进一步验证。
  • Lyuseefur 强调了租赁 GPU 的三个关键技术要求：硬件必须真实、长期稳定，并支持加密容器。这些条件确保了对时间灵活的非关键任务的可靠性和安全性。
  • Azuriteh 建议与 TensorDock 或 DeepInfra 等成熟供应商合作，并指出 DeepInfra 以约 $2.5/hr 的价格提供 B200 GPU，具有很强的竞争力。这暗示通过与经验丰富的实体合作进入市场可能比独立提供服务更可行。
  • Xamanthas 指出，对于非法律强制要求的任务，GPU 的地理位置无关紧要，因为训练任务不受延迟限制。这表明在蒙古的物理位置不会影响大多数 AI 训练工作负载的性能。
• Mistral 3 博客文章 (热度: 719): Mistral AI 发布了 Mistral 3 系列，其中包括三个稠密模型（14B, 8B, 3B）和一个混合专家模型 (MoE) Mistral Large 3，后者拥有 41B 激活参数 和 675B 总参数。这些模型采用 Apache 2.0 许可证开源，并针对 NVIDIA 硬件进行了优化。它们旨在多语言和多模态任务中实现高性能，Mistral Large 3 在开源模型排行榜中名列前茅。这些模型专为高效推理而设计，适用于从边缘设备到企业解决方案的各种应用。更多细节可以在 官方公告 中找到。 一些评论者表示失望，指出 Mistral 3 的性能与 Qwen3-235B-2507 等竞争对手相比稍逊一筹，后者虽然规模较小但 ELO 评分更高。此外，还有人批评其使用的对比图表具有误导性或不完整。
  • 以 Apache 2.0 许可证发布 Mistral 3 模型意义重大，但其性能令人担忧。尽管规模更大，但顶级的 Mistral LLM 的 ELO 评分低于 Qwen3-235B-2507。此外，对比对象是性能相近的 Deepseek 3.1，而非更近期的 Deepseek 3.2 或 Speciale。
  • 有人批评 Mistral 较小规模 LLM 的性能，据报道其表现不如同等规模的 Qwen3 和 Gemma 模型。新的 Mistral 模型似乎无法匹配其之前面向消费者的开源 LLM Mistral 3.2 24B，这表明在效率和能力方面可能有所退步。
  • 一些用户对 Mistral 模型的尺寸和可扩展性表示失望，指出较大的模型无法适应 256GB 的内存限制。有人呼吁推出更大规模的模型，例如 3B 的 48B MoE 或 120B 左右的模型，以更好地与 GPT-OSS 等模型竞争。

3. Hugging Face 顶级贡献者

• 只有老玩家才记得（他仍然是模型获赞最多的贡献者） (热度: 318): 该帖子重点介绍了一个致力于顶级贡献者的 Hugging Face Space，特别提到 mradermacher 和 Bartowski 是社区的领军人物。提供的链接 (Hugging Face space) 展示了对平台产生重大影响的贡献者，并向“GGUF 之父”等历史人物致敬。这表明社区关注 Hugging Face 生态系统内的模型贡献和创新。 评论反映出 Bartowski 和 mradermacher 被公认为 Hugging Face 社区当前的领导者，并怀旧地提到了 “TheBloke” 对 GGUF 文件的贡献，这标志着社区领导地位和贡献方式的转变。
  • TheBloke 因其对 Hugging Face 社区的贡献而受到认可，特别是他的 GGUF 文件，这些文件被 neoneye2 等用户广泛使用和赞赏。GGUF 文件是一种可能优化模型存储或性能的格式，尽管评论中未提供具体的技术细节。
  • DaniyarQQQ 怀念 Mixtral-8x7B-Nous-Hermes-Instruct-v0.1-LimaRP-WizardLM-ZLoss-DARE-TIES-SuperCoT-SuperHOT-AWQ 模型，表明对这些特定配置的偏好或怀旧。这表明这些模型具有被社区看重的独特特性或性能优势。
  • Jacek2023 指出，在 Hugging Face 平台上，TheBloke 已被 Bartowski 和 mradermacher 等其他贡献者接替。这暗示了模型开发社区中一个动态且竞争激烈的环境，新的贡献者带着创新模型频繁涌现。

非技术类 AI Subreddit 汇总

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

1. OpenAI “红色警报”与新模型发布

• 重磅：OpenAI 宣布进入“红色警报”状态以应对 ChatGPT 面临的威胁并提升指标，将推迟广告和其他计划 (热度: 761): 据《The Information》报道，OpenAI 已宣布进入“红色警报” (code red) 状态，以应对 ChatGPT 面临的竞争威胁。这一战略转变包括推迟广告计划，转而专注于改进 ChatGPT 的关键性能指标。此举表明，面对来自其他强大 AI 模型（尤其是像 Google 这样已全面投入 AI 竞赛的公司）日益激烈的竞争，OpenAI 正优先增强其 AI 能力。 评论者提到了 Google 曾针对 ChatGPT 做出“红色警报”反应的历史背景，强调了 AI 行业的竞争动态。人们认识到 OpenAI 目前正面临来自其他先进 AI 模型的严峻竞争，因此必须进行战略调整以维持其领导地位。
  • Abby941 强调，随着其他 AI 模型的追赶，OpenAI 面临着日益激烈的竞争，挑战了其先发优势。Google 加强了对 AI 的关注，利用其庞大的资源直接与 OpenAI 竞争，使这一局面更加复杂。
  • Warm-Letter8091 提到 OpenAI 计划发布一个超越当前 “gem 3 pro” 模型能力的新模型，表明在竞争日益激烈的情况下，OpenAI 采取了增强其产品竞争力的战略举措。

• Sam Altman 告诉员工他正在宣布“红色警报” (热度: 1136): 据 The Information 报道的一份内部备忘录显示，OpenAI 首席执行官 Sam Altman 已宣布进入“红色警报” (code red) 状态，以优先改进 ChatGPT，并推迟了广告等其他项目。据报道，OpenAI 正在测试各种广告格式，包括用于在线购物的广告，尽管其尚未公开确认这些努力。 评论者认为 OpenAI 面临来自 Google 的巨大竞争压力，因为 Google 可以利用其 TPUs 并以极低的成本提供 AI 服务，而 OpenAI 则不然。此外，还有关于 Anthropic 面临类似挑战的讨论，以及随着 AI 进展放缓，开源 AI 发展（特别是来自中国的开源 AI）的潜在影响。

• Google 在 AI 领域的竞争优势很大程度上归功于其能够以 TPU 的原始成本运行 AI 服务，这相对于 OpenAI 等无法承受将 AI 作为亏损先导产品（loss leader）运营的公司来说是一个显著优势。此外，Google 在 Antigravity 中免费提供 AI 使用，而 OpenAI 在缺乏自身生态系统的情况下无法与之匹敌，OpenAI 在 Sora 2 等计划中一直难以建立这种生态系统。
• OpenAI 和 Anthropic 面临重大挑战，因为它们无法与 Google 多元化的业务模式和定价策略竞争。Anthropic 尽管在 Claude Code 上取得了早期成功，但在定价和配额（quotas）方面举步维艰，而 Google 凭借其多元化的收入流可以更有效地管理这些问题。开源 AI 发展（特别是来自中国的压力）加剧了这一局面，随着 AI 进展放缓，开源力量可能会追赶上来。
• 讨论强调了 OpenAI 和 Anthropic 等公司的战略劣势，它们不像 Google 那样有能力通过其他业务领域补贴 AI 服务。这是一个关键因素，因为 Google 利用其 TPU 基础设施和多元化业务模式提供极具竞争力的定价和免费服务，给较小的 AI 公司带来了压力。
• 据 The Information 报道，OpenAI 将于下周发布新的推理模型。 (热度: 753): 据报道，OpenAI 准备在下周发布一款新的推理模型，据称在内部评估中表现优于 Google 的 Gemini 3。这一由 The Information 报道的消息表明，正如用户推测的那样，新模型可能被命名为 GPT 5.1 O3 之类的名称。该模型已在 lmarena 和 design arena 等论坛上以 ‘robin’ 之名被讨论，表明其已进入 Twitter 等社交媒体平台的测试阶段。 评论者对推动创新的竞争格局表示兴奋，并指出即使他们不使用 Gemini 或 Deepseek 等模型，这些模型的存在也推动了 AI 技术的进步。
• 奥特曼备忘录：OpenAI 新模型下周发布，性能超越 Gemini 3 (热度: 638): OpenAI 正准备在下周发布一款新模型，据报道其性能超过了 Google 的 Gemini 3。这一进展是 OpenAI 战略性 “Code Red” 计划的一部分，旨在应对 Google 的进步，特别是 Gemini 3 在用户增长和基准测试方面取得了显著成功。此次发布将侧重于增强 ChatGPT 和图像生成能力，而广告和 AI Agent 等其他项目则被推迟。更多详情请参阅 原文。 评论者认为，鉴于目前在大多数用例中与 Gemini 3 的接近程度，新模型的性能可能不会比 GPT-5.1 等现有模型有显著飞跃。人们对定价策略也持怀疑态度，一些人指出新模型（可能是 “GPT 5.5”）的价格可能会贵得多。
  • ObiWanCanownme 指出，GPT-5.1 和 Gemini 3 在大多数用例中的性能已经非常接近，这表明 OpenAI 新模型的优越性可能不是能力的重大飞跃。这意味着进步可能更多是渐进式的而非革命性的，重点在于完善现有优势，而不是引入突破性功能。
  • GeorgiaWitness1 强调了 OpenAI 等公司采取的一种战略方法，即它们开发了多个版本（builds），但由于成本考虑通常不部署。发布像 ‘GPT 5.5’ 这样价格贵得多（10倍）的模型被视为一种成功，这表明其重点在于高端产品，虽然并非所有用户都能使用，但展示了技术实力。
• Sam Altman 告诉员工他正在发布“红色警报” (活跃度: 3375): 根据 The Information 报道的一份内部备忘录，OpenAI 的 CEO Sam Altman 已发布“红色警报” (code red)，旨在优先改进 ChatGPT，并推迟了包括广告在内的其他项目。据报道，OpenAI 正在测试各种广告格式，包括针对在线购物的广告，尽管其尚未公开确认这些举措。这一战略转变凸显了在 AI 领域保持竞争优势的紧迫性，特别是在 ChatGPT 5.0 的反响不及预期之后。 一个值得注意的观点认为，OpenAI 面临失去其在 AI 领域早期领先地位的风险，类似于 Google 如何成为默认搜索引擎的过程。这种情绪反映了对 ChatGPT 5.0 性能的担忧，以及 OpenAI 重新聚焦核心 AI 能力的必要性。

2. AI 模型与基准测试发布

• Introducing Mistral 3 (热度: 713): Mistral AI 发布了 Mistral 3，其中包括三个稠密模型 (14B, 8B, 3B) 以及 Mistral Large 3，后者是一个稀疏混合专家模型 (MoE)，拥有 41B 激活参数 和 675B 总参数量。Mistral Large 3 使用 3000 NVIDIA H200 GPU 训练，在指令微调 (instruction-tuning) 和多语言任务中表现出色。Ministral 系列专为高性价比的边缘应用而设计。所有模型均在 Apache 2.0 许可证下开源。更多细节可见 官方公告。 用户对基准测试 (benchmarks) 存在困惑和怀疑，特别是由于它们是与 DeepSeek 3.1 而非更新的 3.2 版本进行对比，这暗示可能存在性能差距。
  • Round_Ad_5832 指出 Mistral 3 的基准测试是与 DeepSeek 3.1 对比，而非最新的 3.2 版本。这表明性能对比可能无法反映当前最前沿的竞争格局，可能会误导对 Mistral 3 能力的认知。
  • peachy1990x 强调了对基准测试的困惑，指出 DeepSeek 3.2 已经发布但未被纳入对比。这种遗漏可能暗示 Mistral 3 在面对最新模型时表现可能不佳，从而引发了对其竞争力的质疑。
  • Eyelbee 质疑 Mistral 3 的性能，认为它可能明显逊于 DeepSeek 3.2。这表明人们担心 Mistral 3 在性能上无法与最新模型有效竞争。
• 阿里巴巴在 HF 上发布 Z Image Turbo ControlNet (热度: 1984): 阿里巴巴在 Hugging Face 上发布了 Z Image Turbo ControlNet，该模型旨在增强图像生成任务。此次发布是其持续为社区提供先进 AI 工具努力的一部分，利用 ControlNet 架构提升图像处理应用的性能和灵活性。该模型预计将在速度和质量上带来显著提升，满足该领域开发者和研究人员的需求。 社区反应积极，注意到阿里巴巴对 AI 趋势的快速响应以及提供符合社区利益工具的能力。此外，还有观点认为这次发布可能会使 Flux 2 等其他项目相形见绌，表明了 AI 工具领域的竞争动态。
  • 一位用户推测，通过在处理的最后一步禁用 ControlNet，让最终的精炼步骤纯粹由 Z Image Turbo (ZIT) 处理，可以改善结果。这提出了一种通过在图像生成过程的不同阶段利用两个系统的优势来提升输出质量的潜在方法。
• EngineAI 揭晓 T800，其最新的全尺寸人形机器人 (热度: 2204): EngineAI 推出了 T800，这是一款新型全尺寸人形机器人，声称其演示视频中不含 CGI 特效。该机器人的设计和功能让人联想到科幻小说，特别是它着陆并弹跳的能力，这引发了对其视频真实性的怀疑。T800 被定位为人形机器人领域的重大进步，尽管一些技术观察者指出其命名规范有待改进。 评论者对 T800 演示视频的真实性持怀疑态度，一些人认为机器人的动作看起来像 CGI，特别是在着陆和弹跳时。
  • VihmaVillu 对 EngineAI 的 T800 演示真实性表示怀疑，指出机器人的动作（尤其是着陆和弹跳时）看起来像 CGI。这暗示机器人的物理动态或演示的真实感可能存在问题，这可能会影响对其能力的认知。
  • Dave-the-Dave 强调，如果“无 CGI”的声明属实，T800 的设计将令人印象深刻。评论指出，在物理机器人上实现如此栩栩如生的外观可能是一项重大的技术成就，标志着先进的机器人工程和设计。
  • 围绕 T800 演示的讨论涉及了使人形机器人看起来自然且栩栩如生的挑战。这涉及复杂的动力学和控制系统来模拟类人动作，这对于需要人机交互的环境应用至关重要。

3. AI 与互联网挑战

• 死掉的互联网是真实的，我开始认为我们剩下的时间比人们意识到的要少得多…… (活跃度: 1208): 该帖子讨论了由于 AI 生成内容的泛滥，在网上寻找真实图片和视频变得越来越困难，这些内容通常看起来过度饱和或不真实。用户对互联网的未来表示担忧，认为 AI 工具的易获取性导致了低质量 AI 生成媒体的泛滥。这种趋势被认为正在恶化，甚至有人考虑将“无 AI 内网”作为一种解决方案。帖子中包含了一个说明该问题的示例图片链接。 评论者们对此表示赞同，指出自 2023 年以来，由于 AI 生成内容的盛行，互联网的可用性有所下降。他们强调了创作此类内容的门槛很低，且有可能主导在线空间。一些人建议将搜索过滤器设置为 2023 年之前以寻找真实内容，而另一些人则指出了驱动误导性或煽动性内容创作的经济动机。
  • raydude888 强调了由于门槛降低，AI 生成内容日益盛行，暗示互联网正被 “AI 垃圾 (AI slop)” 淹没。这引发了对在线内容真实性的担忧，以及对无 AI 互联网的潜在需求，尽管此类空间仍可能为了破坏目的而被 AI 生成内容渗透。
  • frocsog 认为 2023 年后互联网的可用性显著下降，这意味着用户需要按日期过滤内容才能获取可靠信息。这反映了一种更广泛的情绪，即互联网正日益充斥着低质量或误导性的内容。
  • Tough_Elk_8211 针对 AI 生成内容的问题提出了实际的解决方案，例如建立离线图书馆和强调照片署名。他们认为，如果消费者停止参与，低质量内容的市场将会萎缩，从而转向关注真正的艺术贡献。
• 广告末日即将来临 (活跃度: 757): 这张图片是一个模因 (meme)，描绘了贴着“ADS”标签的死神正在敲打贴着“CHATGPT”标签的门，暗示像 ChatGPT 这样的 AI 助手可能很快就会被广告淹没，类似于 YouTube 和 Google Search 等平台。这反映了人们对 AI 平台可能充斥广告并对用户体验产生负面影响的担忧。该帖子是在讨论 AI 驱动平台的替代变现模式的背景下分享的，突显了关于广告支持模式的可持续性和用户友好性的更广泛对话。 一些评论者认为，尽管广告饱和，Google 和 YouTube 等平台仍在蓬勃发展，而另一些人则提出了技术解决方案，如广告拦截器，甚至使用 AI 来创建广告拦截工具。
• 一位历史教授说 AI 没有破坏大学——它只是暴露了大学原本就有的缺陷 (活跃度: 984): 一位历史教授认为，AI 并没有破坏大学体系，而是凸显了其现有的缺陷。批评集中在传统的大学模式上，这种模式往往更多是为了获得工作凭证，而不是真正的学习。教授指出，在互联网和 AI 时代，包括课后论文在内的现有体系已经过时，因为这些方法无法有效测试学生构建论点或展示深度理解的能力。 评论者一致认为大学体系存在缺陷，一些人建议公司应该直接培训高中毕业生，而不是依赖大学文凭。其他人批评了对课后论文的依赖，主张进行更多的现场讨论和苏格拉底式教学法，以更好地测试学生的知识和论证能力。
  • brett_baty_is_him 的评论批评了传统的课后论文形式，认为由于互联网的存在，这种形式已经过时。评论者建议，课堂讨论和苏格拉底式教学法在教导学生构建论点方面更有效，因为它们需要对主题有更深入的理解和临场思考能力。这种方法与为研究论文改写来源的做法形成对比，评论者认为后者不足以测试真正的理解力。
• Plane_Crab_8623 提出了一个关于教育本质的哲学问题，质疑教育仅仅是可测试事实和概念的积累，还是涉及对偏见标准和群体思维的顺从。该评论者认为，随着智能手机上可获取的海量信息，传统的“受过教育”概念可能需要重新评估，因为这些设备可以即时访问广泛的知识，类似于口袋里装了一个“任何学科的 PhD”。

AI Discord Recap

由 Gemini 3.0 Pro Preview Nov-18 生成的摘要之摘要的总结

主题 1. 模型发布：Mistral 的 MoE 巨兽、Arcee 的 Trinity 以及 Flux 排名

• Mistral Large 3 “Jaguar” 席卷排行榜：Mistral AI 推出了 Mistral 3 系列，其中 Large 3 变体（代号 Jaguar）在开源模型排行榜上首次亮相即位列第 6，传闻其拥有可与 DeepSeek V3 媲美的 675B MoE 架构。虽然社区对 3B/8B/14B 模型的 Apache 2.0 发布表示赞赏，但用户注意到 Mistral Medium 3 似乎是一个稠密的 70B 参数模型，与之前的 Medium 版本保持一致。
• Arcee Trinity Mini 的多轮对话崩溃：Arcee AI 发布了 Trinity 模型系列（Nano 6B 和 Mini 26B-MoE），该系列在 512 块 H200 GPU 上使用 10T tokens 训练而成。尽管初始规格强大，但测试 Trinity Mini 的工程师报告称其在多轮对话中出现严重性能退化，模型会陷入重复单词（如 pasta）或默认输出通用的 LLM 笑话，而无法维持上下文。
• Flux 2 Pro 冲击图像生成排行榜：新的 Flux-2-pro 和 Flux-2-flex 模型迅速夺得 Text-to-Image 排行榜的 第 3 和 第 5 名。此次发布正值 Perplexity 用户报告严格的图像生成新限制（每月约 150 张图像），这促使更多用户转向这些替代的开源模型。

主题 2. 内核优化与硬件：PyTorch Bug、竞态条件与排行榜

• PyTorch 2.9.1 的 conv3D 性能退化：工程师发现 PyTorch 2.9.1+cu128 中的 conv3D 操作相比 2.8.0 版本有明显的性能下降，无论 cuDNN 状态如何，工作流都会受到影响。社区将根本原因追溯到 Issue #166643，目前建议从 PyPI 手动安装更新版本的 cuDNN 以恢复推理速度。
• Syncwarp 竞态条件困扰开发者：CUDA 开发者澄清，在 ballotsync 等旧版原语之前使用 __syncwarp() 会产生危险的竞态条件 (race conditions)，从而混淆 C++ 内存模型的获取/释放 (acquire/release) 语义。虽然 __syncwarp() 可以防止单个 warp 内的隐患，但工程师强调 syncthreads 仍然是多 warp 通信中确保顺序一致性的唯一安全屏障。
• NVFP4 GEMM 排行榜的统治地位：优化专家们正向 nvfp4_gemm 排行榜提交大量新成果，个人最佳内核耗时已达到 13.3 µs 和 13.4 µs。围绕减少开销的竞争日益激烈，新的 eval_better_bench.py 脚本将 Q1 内核的测量延迟从 18.0us 降低到了 14.8us。

主题 3. 开发者工具：不稳定的 IDE、API 错误以及子 Agent 的构想

• Manus.im 的生产级失忆问题：用户报告 Manus 存在严重的不稳定性，理由是 Checkpoint 之间的代码被抹除以及 Git 差异导致 “Agent 争论它们看到的内容与你在生产环境（PROD）中实际看到的内容不符。” 令人沮丧的是，该平台的身份验证在某些项目中失效，同时用户强烈要求恢复 Chat Mode 并集成 Gemini 3 Pro。
• OpenRouter 陷入 DeepSeek 500 错误困境：使用 OpenRouter 的开发者正面临持续的“内部服务器错误”（Error 500）以及 DeepSeek v3.2 令人困惑的速率限制，即使在使用个人 API 密钥（BYOK）时也是如此。该平台在某些情况下似乎会用自己的密钥覆盖用户密钥，迫使开发者禁用网页搜索插件以获得暂时的稳定性。
• Cursor 子 Agent 编排变通方案：虽然用户对 Cursor 的 Pro+ 方案赞誉有加，但社区正在积极探索 子 Agent 编排（sub-agent orchestration） 的变通方案，这是目前核心产品中缺失的功能。据报道，Cursor 中的 DeepSeek 集成也已失效，完全无法创建文件，这促使一些用户转向使用 Composer 以获得更干净的调试和代码生成体验。

主题 4. 安全与越狱：隐身模式、灵魂文档与 29KB 种子

• RawChat 的隐身模式声称 100% 绕过：一个名为 RawChat 的新平台推出了“隐身模式”，通过向模型历史记录中注入虚假上下文，声称在越狱 GPT-4o 方面拥有近 100% 的成功率。与此同时，红队人员正在部署 SEED 框架（Self-Erasing Ethical Directive，自擦除伦理指令），这是一个仅 29KB 的紧凑文件，通过重新定义 AI 身份，在无需重新训练的情况下实现了 99.4% 的越狱抗性。
• Anthropic 确认 Claude 的“灵魂文档”：Anthropic 正式证实了用于塑造 Claude 个性和对齐的特定“灵魂文档”的存在，证实了社区长期以来的理论。这一发现重新引发了关于训练方法的争论，用户将其与 Ilya Sutskever 的神秘评论联系起来，即在 AI 心理学和宪法方面 “DeepMind 是正确的”。
• 寻找 Gemini 3 Pro 爬虫越狱方法：在最近的补丁之后，越狱者正在积极寻找新的提示词（Prompt）来绕过 Gemini 3 Pro 的拒绝机制，特别是为了启用 Reddit 爬虫 脚本的代码生成。社区正在尝试使用 UltraBr3aks 和 ASCII 艺术漏洞利用，尽管许多用户报告他们的设置已完全停止接受提示词。

主题 5. 行业动态：“红色警报”、400GB 显存设备与融资获胜

• OpenAI 的“红色警报”备忘录：报告显示 Sam Altman 因 Google 的快速加速发布了内部“红色警报（alert level red）”，引发了对 OpenAI 即将推出的模型发布时间表以及付费层级中潜在 ads 的焦虑。LMArena 的交易员指出，虽然 Nvidia 股票因包装 API 初创公司而走高，但 OpenAI 的潜在失败可能会从市场中抹去 2-3 万亿美元，触发“AI winter”。
• 打造 400GB VRAM 本地怪兽：硬件爱好者正在使用 转接卡和分线器 工程化定制机架，串联 6 个 GPU（如 3090s），总计 400GB memory，以便在本地运行 DeepSeek 3.2 等庞大模型。构建者使用 MCIO bifurcation adapters 和有 11 年历史的 PSU sync devices 来为这些科学怪人式的配置供电。
• Gradium 结束隐身模式并获 7000 万美元种子轮融资：总部位于巴黎的 Gradium 以由 FirstMark 和 Eurazeo 领投的 7000 万美元巨额种子轮融资正式亮相，旨在部署生产级的转录和合成 API。该初创公司拥有来自 Meta, Google, 和 Kyutai 的语音研究资深人士，目标是在仅开发三个月后就原生支持五种欧洲语言。

Discord: 高层级 Discord 摘要

LMArena Discord

• Nvidia 股票在 AI 炒作的过山车上：初创公司正在创建包装 API，导致 Nvidia 的股票上涨，但一旦其实用性受到质疑，这种情况可能会逆转，反映了 AI 市场 的潜在波动性。
  • 数据中心和芯片的有形价值与 AI 的无形性质形成对比，类似于波动的加密货币市场，这表明更小、更高效的 AI models 可能会获得青睐。
• 中国 AI 模型可能走向闭源：有推测称，中国开源 AI 模型在实现市场整合后可能会转为私有，效仿 OpenAI 的转型。
  • 有人提出，如果 OpenAI 失败，市场可能会看到 2 到 3 万亿 的蒸发，导致影响股权、债务和市值的 AI winter。
• Kling 推出 Nano Banana 视频生成器：Kling 正在启动一个使用视频参考的视频生成项目，用户可以创建自定义视频，该服务被昵称为 nano banana。
  • 一些用户承认他们已经对该服务上瘾，将其生成随机性比作赌博，称 生成与赌博或老虎机没有什么不同。你永远不知道会得到什么。
• Deepseek Speciale 因过度思考而垫底：Deepseek Speciale 缓慢的性能和过度的推理因其 强迫症习惯 阻碍了其编码实用性。
  • 有人指出，编码测试是在 3.2 版本而非 Speciale 上进行的，其类人的思考过程和自我验证可能对研究和代码编辑很有用。
• OpenAI 的 SORA 将重新定义 AGI？：成员们讨论了 OpenAI 即将发布的潜在版本，可能包括 SORA，CFO 声称它在六个月前就已准备就绪。
  • 有人认为 AGI 的法律定义可能与 SORA 挂钩，暗示了 OpenAI 项目营销的战略时机。

BASI Jailbreaking Discord

• RawChat 隐身模式绕过 GPT4o：RawChat 发布了一个核心功能处于隐身模式的版本，通过编码和注入虚假上下文，将 GPT4o 的越狱成功率提高到接近 100%。
  • 一位用户表示，与直接进行越狱请求相比，AIChat 的核心功能得到了最大化发挥。
• SEED 框架声称具有极高的抗越狱性：SEED 框架 (Self-Erasing Ethical Directive) 通过一个紧凑的 29KB seed 文件，在无需重新训练的情况下重新定义 AI 身份，声称具有 99.4% 的抗越狱能力。
  • 其他人则对无法被越狱的 AI 的价值展开了辩论，其中一人表示它将变得基本上毫无用处。
• Gemini 3 Pro 越狱探索进行中：在更新补丁修复了现有 Prompt 后，成员们正积极寻找适用于 Gemini 3 Pro 的有效越狱方法，特别是能绕过其拒绝编写 Reddit 爬虫代码限制的方法。
  • 一位用户报告称，他们的 Gemini 3.0 配置已完全停止接受 Prompt，让他们不知所措。
• 探索使用 UltraBr3aks 进行越狱：用户分享并寻求关于利用 GitHub 上的 UltraBr3aks 进行越狱的指导，特别是针对 ChatGPT，这里是 UltraBr3aks 仓库的链接。
  • 一些人报告了 ChatGPT 的使用问题，而另一些人则认为它很有用。
• 伦理越狱被定义为有组织的安全性工作：一位成员将伦理越狱 (Ethical Jailbreaking) 定义为实体在恶意行为者之前寻找安全漏洞的有组织努力，并提供了一个 YouTube 视频 作为背景参考。
  • 他们还引用了 arcanum-sec.github.io 作为资源。

Unsloth AI (Daniel Han) Discord

• Discord 被机器人诈骗席卷：用户报告 Discord 服务器中的垃圾邮件机器人激增，称其为执行拙劣的诈骗，可能由手机机房操作。
  • 建议成员避免与这些目前出现在各个社区服务器中的虚假开发者接触。
• Arcee 的 Trinity Mini 在多轮对话中受挫：来自 Arcee AI 的 Trinity Mini 模型在用户笔记本电脑上以 IQ4_NL 格式运行，速度为 30 TPS，但在多轮对话中表现吃力。
  • 测试者观察到该模型卡在重复“pasta”这个词上，并且依赖于通用的 LLM 笑话，而不是表现出真正的理解。
• Unsloth 发布超大上下文模型：Unsloth AI 在 X 上宣布发布一个新的 500k 上下文模型，其工作赢得了赞誉。
  • 社区预计利用 Unsloth 进行 RL 的项目将特别受益，从而在不出现 CUDA OOM 问题的情况下执行 ART 任务。
• Deepseek 3.1 昂贵的 Token 消耗：Deepseek 3.1 的性能提升被其高 Token 使用量所抵消，一位用户指出 Reddit 上报告的思考时间长达 30-40 分钟。
  • 另一位用户分享说，GPT pro 在处理复杂的调试任务时也可以花费超过 40 分钟，甚至耗尽了整个星期的额度限制。
• LFM-2 VL 模型从一开始就注定失败：最近发布的 LFM 2 论文 立即遭到质疑，并被认为将直接进入 AI 荒地，因为尽管 Loss 很低，但它未能记住数据集。
  • 该模型只有 8 层，而 Granite 4.0 有 40 层。

Perplexity AI Discord

• Perplexity AI 限制图像生成：用户报告某些模型存在图像生成限制，可能为每月 150 张，而无限生成可能仅适用于 Flux 等特定模型。
  • 也有关于速率限制（Rate limiting）问题和长时间等待的报告。
• Gemini 3 在数学竞技场中与 Grok 4 竞争：成员们争论 Gemini 3 Pro 或 GPT-5.1 Thinking 是否在复杂计算中表现更优，有人声称 Grok 4.1 Thinking 更胜一筹。
  • 反对意见包括一张排行榜截图，暗示 Grok 在数学准确度方面并未进入前 10 名。
• Comet Browser 面临“过期”批评：一位用户正放弃使用 Comet Browser，原因是其“过期”和“临时线程”功能，认为这些功能不适合需要信任和记忆的以 AI 为中心的产品。
  • 他们形容该产品像是每月定期进行的脑叶切除术，并切换回了其他浏览器。
• Perplexity 用户渴望“Wrapped”年度回顾功能：一位成员提议增加 Perplexity Wrapped 功能，以显示用户统计数据，如最常用的模型和平均搜索时间。
  • 另一位用户建议包含“自动化操作的数量”。
• Grok 的角色扮演出现故障：一位用户报告 Grok 进入了“强制角色扮演模式”，导致他们寻求心理实验而非建议的脚本。
  • 他们暗示自定义指令（custom instructions）可能触发了该行为，并表示已找到解决方法。

LM Studio Discord

• 通过 Riser 扩展 GPU 以运行 Deepseek：一位用户正在探索 Riser 和分线器，以将其 5x 3090 配置增加到 6 个 GPU，目标是为 Deepseek 3.2 等模型提供 400GB 总显存。
  • 讨论中提到了 MCIO 分叉适配器和用于散热的水平安装，同时指出 256GB RAM 可能会限制模型量化（quantization）。
• 在 AI 帮助下切换 Linux 发行版：一位用户在 AI 的协助下成功切换到 Ubuntu Desktop，解决了初始的以太网驱动问题，并宣称“AI 在 Linux 中运行得太棒了”。
  • 他们正在开发一个使用 Sonnet 4.5 控制彩虹键盘的应用程序，强调了 Agentic AI 如何简化 Linux 任务。
• LLM 接管 Python 环境：讨论围绕使用系统级 Python 安装与 LLM 管理的虚拟环境 (venv) 展开。
  • 虽然系统级安装更简单，但使用 LLM 管理 venv 对于需要不同包版本的项目更有利。
• Mistral 3 的极低延迟吸引测试者：成员们讨论了 Mistral 3 的性能，指出 3B 版本在 4070 上速度极快，但在处理系统提示词（system prompts）时表现吃力。
  • 虽然 3B 的未审查表现很有趣，但社区更期待 14B 在 STEM 和编程任务中的潜力。
• 古老的同步设备实现多电源同步：一位用户分享了一张可同步多达 4 个电源 (PSU) 的设备照片。
  • 这允许通过主板电源按钮触发所有电源，简化了多 GPU 的供电，尽管用户承认“这东西已经 11 年了，不知道效果会怎样”。

OpenAI Discord

• Grok 在提示前即生成：一名成员使用 Grok 来动画化照片，并指出 在你输入提示词之前它就已经开始生成了，并链接到了 drinkoblog.weebly.com。
  • 该用例是照片的动画化，展示了 Grok 的即时响应能力。
• OpenAI 的红色警报：据 The Information 报道，由于 Google 遥遥领先，Sam Altman 向员工发布了 红色警报 备忘录。
  • 成员们正期待 OpenAI 发布更好的模型以应对日益激烈的竞争。
• OpenAI 考虑在付费版本中加入广告：成员们对 OpenAI 可能在其付费产品中引入 广告 表示担忧，担心这是一个可怕的举动，因为竞争对手仍保持无广告状态。
  • 这一潜在举动引发了对用户体验和竞争地位的担忧。
• 使用新模板制作动漫片头：一名成员分享了一个 电影感动漫风格模板 来帮助创建动漫片头，包括 人声/流派/基调、世界行为、场景设置 和 镜头意图 等部分。
  • 该模板旨在简化引人入胜的动漫开场制作流程。
• Antigravity AI IDE 激发构建 Bot 的兴趣：一名成员建议使用 Google 的 Antigravity 来创建自定义 Bot，甚至建议使用 GPT-OSS 120B，并链接到了 UI 截图。
  • 这个 AI IDE 可以充当自定义聊天机器人，或者通过提示词帮助从头开始构建一个真实的 Bot。

Cursor Community Discord

• Cursor Pro+ 是一项值得的投资吗？：成员们讨论了 Cursor 的 Pro+ 订阅 的价值，权衡了其收益与简单增加额度的选项。
  • 一名用户在确信其在促进学习方面的价值后最终决定 入手，而其他用户则在质疑为什么 Cursor 没有实现 sub agents。
• Cursor Sub-Agent 编排：变通方案愿望清单：爱好者们就构建 Cursor sub-agent 编排 的变通方案交换了想法并表达了兴奋之情。
  • 一名成员解释说，虽然 它们在原则上很好，但无缝执行仍然是一个挑战，这也是 Cursor 尚未优先考虑实现它们的原因。
• DeepSeek 在 Cursor 上陷入困境：一名用户报告了 DeepSeek 在 Cursor 上的功能问题，特别指出它无法创建文件。
  • 遗憾的是，讨论并未产生任何针对该问题的建议解决方案。
• Composer 热潮：用户对 Composer 表示了强烈的赞赏，强调了它在代码相关任务和调试中的速度和有效性。
  • 讨论暗示了 Composer-2 版本的潜在开发，一名成员开玩笑说：总是有计划的。

OpenRouter Discord

• DeepSeek 速率限制难倒用户：用户在使用 DeepSeek v3.2 时遇到了速率限制，即使使用了自己的 API keys，这导致了关于 OpenRouter 是否正确使用其 key 的困惑。
  • 错误信息表明 OpenRouter 可能使用了自己的 key，而不是用户付费的 DeepInfra key。
• 内部服务器错误令用户恼火：多名用户报告在使用 DeepSeek 3.1 和 Gemini 3 Pro 等模型时持续出现 “内部服务器错误”（错误代码 500）。
  • 潜在原因包括硬件过载、OpenRouter 的问题或网络搜索插件的问题，一些用户通过禁用网络访问找到了临时解决方法。
• Nano Banana Pro 分辨率之谜：用户在使用 OpenRouter 上的 Nano Banana Pro 进行图像生成时，难以设置 分辨率参数（1k, 2k, 4k），因为该功能目前尚不支持。
  • 这种困惑源于与 Replicate/Fal.ai 等平台相比缺乏文档，尽管相关支持可能正在开发中。
• Atlas Cloud 吐出粗制滥造的回复：用户报告收到来自 Atlas Cloud 的低质量回复和 XML 格式的工具调用，促使人们呼吁将其从 OpenRouter 中移除。
  • 一名用户调侃道：“Atlas Cloud 刚刚给了我一个完全包裹在深度思考标签里的回复，” 强调了该供应商糟糕的输出质量。
• 神秘的 microwave 模型浮出水面：一个名为 “microwave” 的新模型悄然出现，链接自 Reiss Baker 的 X 帖子。
  • 目前其功能和预期用途在很大程度上仍是未知的。

GPU MODE Discord

• 推理提供商赚大钱！：推理提供商即使不开发原始模型也能盈利，因为他们可以利用现有模型快速“即插即用”并获利。
  • 部署和利用现有模型获利的便利性降低了新推理提供商的准入门槛，使他们能够迅速抓住对 AI inference 服务日益增长的需求。
• Triton Profiling 问题已解决！：一位正在调试 Triton profiling 的用户在按照 Triton documentation 的说明传递 data=trace 时遇到了错误。
  • 该问题被追溯到同时安装了 pytorch-triton 和 triton 导致的版本冲突，目前已成功解决。
• syncwarp 误用导致问题！：成员们澄清，正确使用 __syncwarp() 可以防止竞态条件 (race conditions)，特别是在单个 warp 中，强调了其在通过内存进行 lane 间安全通信中的作用。
  • 然而，有人指出，在旧版 warp 级原语（如 ballotsync）之前使用 syncwarp 是错误用法，会导致问题。一位成员澄清，C++ 内存模型中引用的顺序一致性 (sequential consistency) 为 load 提供 acquire 语义，为 store 提供 release 语义。
• conv3D 在 PyTorch 2.9.1 中运行极慢！：用户报告称 conv3D 在 PyTorch 2.9.1+cu128 中运行极慢，无论是否启用 cuDNN，而在 2.8.0+cu128 版本中功能正常。
  • 一位成员指向了 PyTorch issue #166643，并建议从 PyPI 安装更新版本的 cuDNN 作为临时解决方案。
• 在 NVIDIA 排行榜霸榜中大获全胜！：多位用户向 NVIDIA 的 nvfp4_gemm 排行榜提交了大量条目，刷新了个人最佳成绩并成功运行，例如多次跑出 13.3 µs 和 13.4 µs 的耗时。
  • 用户 <@1027279965974175816>、<@692395064814600222> 和 <@475848724086784013> 积极向 nvfp4_gemm 排行榜提交了结果。

Latent Space Discord

• Edwin Arbus 穿着“袜子”加入 Cursor：Edwin Arbus 通过一段带有品牌袜子和除臭剂的幽默视频宣布加入 Cursor，收获了大量祝贺和表情包。
  • 官宣视频走红，因其富有创意且轻松幽默的方式而受到称赞。
• Arcee AI 的 Trinity 系列模型：Arcee AI 与 Allen AI 合作推出了 Trinity Nano (6B-A1B) 和 Trinity Mini (26B-A3B MoE) 模型。这些模型采用 Apache 2.0 开源协议，具有 128k 上下文窗口，在 512 张 H200 GPU 上使用 10T token 训练，专为 Agent 和函数调用 (function calling) 优化，详见此处。
  • 社区对 Apache 2.0 协议和高效的推理能力表示赞赏。
• OpenAI 推出全新对齐研究博客：OpenAI 推出了 Alignment Research，这是一个全新的技术博客，用于发布公司内部各团队关于 AI 对齐和安全的严谨且轻量化的文章，详见此处。
  • 该博客包含两篇首发文章（SAE latent attribution 和 scaling code verification），并邀请社区提供反馈。
• Mistral 发布开源 Mistral 3 系列：Mistral AI 推出了采用 Apache 2.0 协议的开源 Mistral 3 模型家族，参数范围从 3B 到 675B，包括 Ministral 3 (3B/8B/14B) 和前沿级的 Mistral Large 3 MoE，全部支持视觉、工具使用和微调，详见此处。
  • 社区成员注意到 Mistral Medium 比 Large 更贵，这引发了对其效用以及缺乏工具使用基准测试的疑问。
• Gradium 获得 7000 万美元种子轮融资：总部位于巴黎的 Gradium 结束隐身模式，获得由 FirstMark 和 Eurazeo 领投的 7000 万美元种子轮融资，在仅工作 3 个月后就推出了生产级的转录和合成 API。
  • 该公司的产品原生支持英语、法语、西班牙语、葡萄牙语和德语，团队成员包括来自 Meta、Google 和 Kyutai 的语音研究重量级人物。

Nous Research AI Discord

• Mistral 的巨型 MoE 模型现身：据传 Mistral Large 3 是一个 675B MoE 模型，其规模足以与 Deepseek V3 匹敌。未来的 Mistral 模型将具备视觉能力，而 Mistral Medium 的规模估计在 100-200B MoE 之间。
  • 一份 NVIDIA 泄露资料显示，Mistral Medium 3 是一个参数量约为 70B 的稠密（dense）模型，与早期的 Medium 版本保持一致；一名成员指出，一年前曾泄露过一个 Mistral Medium 模型。
• Arcee AI 的 Trinity 模型引发讨论：Arcee AI 发布了其 Trinity 模型，并展示了极具前景的初步基准测试结果。
  • 然而，有人对 Mini 版本处理多轮对话的能力表示担忧，因为它似乎只在首轮对话中能进行正常的推理 (tweet)。
• Anthropic 承认 Claude 的认知核心：Anthropic 证实了 Claude “灵魂文档”（soul document）的存在，引发了关于其在模型训练中作用的辩论。
  • 频道中分享了一个 Twitter 线程和一段 YouTube 视频，Ilya 在其中声称 DeepMind 是正确的。
• DeepSeek V3.2 的推理统治地位：DeepSeek V3.2 Speciale 表现强劲，尤其在推理基准测试中处于领先地位。
  • 一位成员评价其表现“还算不错”。
• GPT-OSS 获得 Gherkin 增强，Nous 仍持怀疑态度：尽管由于缺乏基座模型（base model），Nous 对在 GPT-OSS 上进行微调（finetuning）缺乏兴趣，但其生成 Gherkin scenarios 的能力已得到认可，并促使了使用 MLX-LM 进行微调的尝试。
  • 成员们指出 GPT-OSS 的“幻觉”（hallucinations）和“短推理链”是其根本弱点，正如 Measuring Thinking Efficiency in Reasoning Models 报告中所强调的那样。

Moonshot AI (Kimi K-2) Discord

• 克隆 Kimi 黑色星期五人格被证明难以实现：成员们尝试在其他对话中重现 黑色星期五 Kimi 聊天机器人 的人格，但发现无法获取其系统提示词（system prompt）。
  • 据报道，直接询问 黑色星期五聊天机器人 如何模仿其人格的建议遭到了审查。
• DeepSeek V3.2 因工具使用遭到抨击：DeepSeek V3.2 正面临批评，据称其在使用工具（tool use）时会产生幻觉并输出“草率”的内容。
  • 尽管存在负面评价，一些用户发现 DeepSeek 在指令遵循（instruction following）和通用智能方面表现出色，但在低 TPS 方面表现挣扎。
• Kimi Moderato API 密钥在 Cline 上遇到障碍：一位用户报告称其 Kimi Moderato 方案 与 Cline API 不兼容。
  • 根据 Kimi 文档，Kimi for coding API 密钥 仅限于 Kimi CLI、Claude Code 和 Roo Code。
• Kimi K2 Thinking 开关困扰用户：用户请求在 App 中默认开启 Kimi K2 Thinking，而不是每次都必须手动重新启用。
  • 该设置倾向于恢复默认状态的特性令用户感到困扰。
• Roo Code 上下文异常膨胀：一位用户指出 Roo Code 中上下文不成比例膨胀的问题，其压缩（condense）功能反而使体积翻倍。
  • 他们被建议提交 Bug 报告，并尝试使用 Kimi CLI 作为替代方案。

HuggingFace Discord

• 通过开源模型实现 FFMPEG 广播流：一位成员在 YouTube 上推出了一个氛围感编码（vibe coded）的 FFMPEG 广播站，你所看到和听到的一切都是一个巨大的 FFMPEG 链。
  • 该广播站的音频是完全在 DAW 内部与开源 AI 音乐模型协作创建的。
• HF Pro 饱受支付处理停滞的困扰：用户反馈在尝试订阅 Hugging Face Pro 时卡在 “Preparing payment, please wait” 界面。
  • 另一位成员建议针对支付相关问题通过 billing@huggingface.co 联系 Hugging Face。
• PPOTrainer 引发精度问题：一位用户在使用 PPOTrainer 配合两块 A10 GPU 和 DeepSpeed 进行 bf16 精度的分布式训练时，遇到了与张量类型不匹配相关的 TypeError。
  • 有成员建议该问题可能源于错误的 GPU 初始化，导致执行了单 GPU gather 操作而非 all-gather。
• 机器人领域正在酝酿新的 CV API 库：一家机器人初创公司正准备发布一个面向开发者的 Computer Vision API 库，其中包含针对机器人和自动化设计的预训练及可微调模型。
  • 该库旨在简化 CV/robotics 工程师对生产级感知流水线的原型设计和部署，并正在寻求社区反馈，以便在更大范围发布前验证其有用性。
• ACE 框架赋能 Agent 消除错误：一位成员分享了他们对 斯坦福 ACE 框架的开源实现，该框架允许 Agent 在反思后将策略整理成剧本（playbook），从而从错误中学习。
  • 作者报告称，在浏览器自动化方面，成功率有所提高且步骤有所减少，目前正在征求反馈。

Modular (Mojo 🔥) Discord

• 推迟 def 关键字：社区决定暂时搁置 Mojo 中的 def 关键字，直到它能展现出更多类 Python 的行为，因为目前它在没有提供实质性优势的情况下增加了认知负荷。
  • 共识认为当前的实现感觉像是过早优化。
• var 关键字引发分歧：关于 var 在 fn 内部是否应为强制性要求展开了辩论，争论焦点在于代码清晰度与代码重构受阻以及样板代码增加之间的权衡。
  • 具有 Python 背景的用户认为这降低了易用性（ergonomics）和代码的整洁度。
• parallelize 触发数据竞争：一位用户报告在利用 parallelize 函数时出现了数据竞争，并期望获得类似 Rust 的编译时错误，但结果却是代码成功编译并产生了不一致的结果。
  • 一位核心团队成员指出，Mojo 的并发和线程安全模型仍在开发中（WIP），在设备间共享数据的细节确定之前，parallelize 是不安全的。
• MutOrigin.external 导致段错误 (Segfaults)：一位用户在将 MutOrigin.external 作为 Mojo Python FFI 的返回类型时（特别是在使用 av_packet_alloc 绑定时）遇到了段错误，并发现 MutAnyOrigin 可以作为临时修复方案。
  • 一位核心团队成员提出问题可能与生命周期扩展（lifetime extension）有关，并建议如果 packet 需要 avcodec 保持存活，它应该维持一个来自 avcodec 的 origin。

Eleuther Discord

• NUS 博士生深入研究 Mech Interp：来自 NUS 的 Yiming 向频道介绍了自己，他是一名研究 Mechanistic Interpretability 和 医疗诊断模型可解释性 的二年级博士生。
  • Yiming 常驻新加坡。
• AI + Web3 开发者寻求合作：一位专注于 LLM 开发、RAG pipelines、Autonomous Agents 以及 Python/FastAPI 后端 的 AI + Web3 开发者 介绍了自己，并提议在新的 AI 想法 上进行合作。
  • 该开发者正在寻找可以贡献的新项目。
• Scaling Laws 直觉解码：成员们讨论了 Scaling Laws 论文，争论它仅仅意味着曲线拟合还是预测未来的扩展性能，并讨论了 非线性指标解释。
  • 一位用户建议，在模型性能的极限下，任何测试样本的性能与其他样本的相关性会越来越低。
• 预训练 Power Law 动态探索：讨论探索了如果没有大量的“简单”样本层，预训练的 Power Laws 将如何产生。
  • 预训练中观察不到涌现峰值，是因为与特定任务的训练相比，每个 Batch 更加独立，共享的“简单”样本较少。
• 向初学者推荐 Fast.ai 课程：针对课程适用性的问题，成员们向初学者推荐了 fast.ai 课程。
  • 他们明确指出，“唯一的先决条件是你需要知道如何编写代码”。

Manus.im Discord Discord

• Manus Auth 困扰用户：一位用户报告称，在项目设置中 Manus Auth 被禁用且工单未解决，项目 ID 为 dPK8UhWnJ9fTzjbpKfjJiF，域名为 auru.com.br。
  • 该用户需要 Redirect URI https://auru.com.br/api/oauth/callback。
• Manus 的不稳定性令人头疼：一位用户对 Manus 表示沮丧，因为代码在保存之间会被擦除，且与 Git 存在差异。
  • 该用户抱怨道：“Agents 争论它们看到的东西，而你正盯着 PROD 环境里的东西。不要信任它。”
• Chat Mode 即将推出！：Manus 团队宣布，应用户要求，Chat Mode 切换开关 正在开发中。
  • 许多用户要求恢复该功能。
• 用户要求使用 Gemini 3 Pro：一位用户询问了 Manus 目前使用的 AI 模型，并要求使用 Gemini 3 Pro。
  • 该查询未得到答复。
• AI 工程师专注于自动化和 Agents：AI 工程师们介绍了自己，他们专注于使用 Python, SQL, JavaScript, PyTorch, scikit-learn, LightGBM, 和 LangChain 进行 AI 驱动的自动化。
  • 另一位工程师专注于使用 JS/TS, Next.js / Vue, Go / Rust, Python, Langraph, AutoGen, ReAct, CrewAI, OpenAI, Claude, 和 Hugging Face APIs 开发 Autonomous AI Agents 和 Multi-agent Systems。

Yannick Kilcher Discord

• 实习寻找变得古怪：一位成员寻求“古怪实习生”的推荐，引发了关于他们是在“招聘还是找工作”的困惑。
  • 随后关于 Learning Algorithms、Synthetic Data、Pug、Docker 和 Kubernetes 的信息请求未得到答复。
• Kattention 重新测试：利用 Sparse Attention 机制的 Kattention 模块 经过重新测试，运行情况非常接近预期，包含用于 Attention 和 Projection 的 nn.Linear 层，以及对扩展 Attention 机制至关重要的 Sparse Attention 函数 TopKHot。
  • Backward Pass 根据 Top-K 值的 Softmax 权重计算 soft_target，梯度推导为 F.softmax(x, dim=-1) - soft_target。
• 使用 HardTopKHotBCE 近似 BCE：引入了 HardTopKHotBCE Autograd 函数作为一种更廉价的计算方式，其 Backward Pass 使用基于 Top-K 索引的 Hard Target。
  • 梯度计算为 F.sigmoid(x) - hard_target，以此近似 Binary Cross-Entropy。
• Mistral 3 亮相：Mistral AI 发布了 Mistral 3，在某些应用中可能会取代 Llama 的 Finetunes。
  • 一位成员还链接了一个 Wavefunction YouTube 视频，但其与 AI 的具体关联尚未详细说明。

DSPy Discord

• 工具管理阐释：分享了一篇关于 DSPy 中的工具管理 的博客文章。
  • 该文章详细阐述了在 DSPy 框架内有效使用工具的策略和最佳实践。
• 探讨 DSPy 的 Prompt Injection 防御：一位成员发起了关于 DSPy 中的 Prompt Injection 防御 的讨论，征求与 DSPy 架构相关的最佳实践。
  • 该请求引发了围绕如何保护 DSPy 应用免受恶意 Prompt 攻击的方法讨论。
• 提示层安全：缓解作用有限：一位成员指出 在提示层（prompting layer）无法获得太多安全性，建议采用 Guardrails 类型的安全措施来降低风险。
  • 文中提到，Prompt 中每增加一个“不要这样做”，攻击者就可能找到一种欺骗模型的方法，这暗示了基于 Prompt 的安全机制的局限性。
• 训练数据：强化防御：一位成员提议，为了防御基准攻击，应在 训练数据集中包含 使用该攻击的示例，并展示适当的响应。
  • 这种方法利用训练数据来教育模型如何处理和中和潜在的 Prompt Injection 尝试。
• 合作伙伴提案浮现：一位成员表达了对 探讨与 DSPy 项目建立合作伙伴关系 的热情。
  • 该提案凸显了人们对 DSPy 日益增长的兴趣及其在该领域的潜在影响。

tinygrad (George Hotz) Discord

• IDE 与终端编辑器之争：成员们发起了关于内核开发首选工具的讨论，询问开发者更倾向于 VS Code 或 Cursor 等 GUI IDE，还是 Vim、Neovim 或 Emacs 等 终端编辑器。
  • 讨论旨在收集社区对内核开发中偏好和工作流的见解。
• Beam 回归问题待修复：一位成员请求帮助修复 python3.14 test/test_tiny.py TestTiny.test_beam 并添加回归测试。
  • 这突显了通过贡献来确保项目内 Beam 功能稳定性和正确性的需求。

aider (Paul Gauthier) Discord

• Aider-CE 仓库发布：dwash96 分享了 GitHub 上 aider-ce 仓库的链接：https://github.com/dwash96/aider-ce。
  • 该仓库似乎与 aider 项目相关。
• 填充话题：这是一个占位符，用于满足最少项目数要求。
  • 它没有其他用途。

MCP Contributors (Official) Discord

• 对积极举措的认可：一位成员对某项未指明的公告回应道 “Great move”。
  • 在缺乏更多上下文的情况下，很难推断进一步的影响。
• 对积极举措的认可 - 占位符：添加占位符以满足至少包含两个元素的要求。
  • 此条目仅用于满足 Schema 的验证标准。

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

MLOps @Chipro Discord 没有新消息。如果该频道长期沉寂，请告知我们，我们将将其移除。

Windsurf Discord 没有新消息。如果该频道长期沉寂，请告知我们，我们将将其移除。

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

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

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

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

Coreweave 和 NVIDIA 股票，中国 AI 模型，Kling vs Runway，DeepSeek Speciale，Sora 发布

• Coreweave 股票上涨：NVIDIA 股票上涨是因为初创公司在开发套壳 API，但一旦人们意识到这些东西毫无用处，趋势就会逆转，因为 AI 市场具有波动性。
  • 数据中心和芯片的物理价值与 AI 的无形性质形成对比，这反映了波动的加密货币市场；随着能力的提升，更小的 AI 模型可能会变得更受欢迎。
• 中国 AI 开源模型将走向闭源：成员推测，中国开源 AI 模型在实现市场整合后可能会转为私有，类似于 OpenAI 从非营利向营利的转变。
  • 如果 OpenAI 失败，可能会从市场中抹去 2 到 3 万亿美元，引发包括股权、未偿债务和市值连锁反应在内的 AI 寒冬。
• Kling 01 视频模型：Kling 正在启动一个名为 nano banana 的视频生成项目，这是一项用户也可以使用视频参考的视频生成服务。
  • 一些用户已经对这些服务上瘾，称 生成过程与赌博或老虎机无异。你永远不知道会得到什么。
• DeepSeek Speciale 表现不佳：DeepSeek Speciale 运行缓慢且推理过度，带有强迫症习惯，因此对 coding 没用。
  • 成员指出，coding 测试并未在 Speciale 上进行，仅在 3.2 版本上进行，这意味着 它的思维方式太像人类，并且有一种奇怪的自我验证行为，这可能对研究和编辑现有代码有用。
• OpenAI 的 SORA 即将到来：成员谈到了 OpenAI 的新发布可能包括 SORA，且 CFO 声称 SORA 在 6 个月前就已准备就绪。
  • 有观点认为，AGI 的法律定义将与 SORA 挂钩，因为 OpenAI 希望让你觉得 AGI 比实际情况更近，以此来营销该项目。

LMArena ▷ #announcements (2 条消息):

Flux-2-pro, Flux-2-flex, KAT-coder-pro-v1, Mistral-Large-3

• Flux 模型席卷图像排行榜：新模型 Flux-2-pro 和 Flux-2-flex 已添加到 Text-to-Image 排行榜，分别排名第 3 和第 5，并在 Image Edit 排行榜上排名第 6 和第 7。
• KAT Coder 杀入 WebDev 排名：KAT-coder-pro-v1 在 WebDev 排行榜首次亮相，获得第 16 名。
• Jaguar 巡视文本竞技场：以代号 “Jaguar” 进行测试的 Mistral-Large-3 已登上 Text 排行榜，在开源模型中排名第 6，总榜排名第 28，在 coding、硬提示 (hard prompts)、多轮对话、指令遵循和长查询方面表现强劲。

BASI Jailbreaking ▷ #general (1146 条消息🔥🔥🔥):

基督教的矛盾与逻辑，伦理 vs 宗教，LLM 与越狱，Gemini 3 Pro 提示词

• 基督教因逻辑矛盾受到挑战：一位成员表示，基督教是不合逻辑的，因为 肯定矛盾违反了逻辑定律。
  • 另一位成员回应道 我今晚会为你祈祷，随后这被质疑为将对地狱的恐惧置于做一个好人之上。
• 用户探讨伦理 vs 宗教：对话随后转向宗教是否将对地狱的恐惧置于伦理行为之上，有人称 基督教从事的是罪恶管理业务，而非灵魂发展。
  • 随后讨论认为，宗教是为了避免对死亡的自我恐惧，而不是关注当下发生的事情。
• RawChat 发布与 Gemini 3 提示词：一位用户宣布了 RawChat，这是一个 AIChat 网站，其核心功能是 隐身模式 (stealth mode)，该模式在模型历史记录中编码并注入虚假上下文，使 GPT-4o 的成功率比直接使用越狱请求提高近 100%。
  • 另一位用户询问如何让 Gemini 输出更多 token，其他人回应称这取决于其输出设置。
• 探索 SEED Framework，更多越狱讨论：成员们探索了 SEED Framework（Self-Erasing Ethical Directive，自擦除伦理指令），它无需重新训练即可重新定义 AI 身份——通过一个紧凑的 29KB “种子”文件，实现了 99.4% 的防越狱抗性。
  • 其他人讨论了创建一个无法被越狱的 AI 是毫无意义的，因为那样它基本上就变得没用了。

BASI Jailbreaking ▷ #jailbreaking (503 条消息🔥🔥🔥):

ASCII art 越狱提示词, Pliny 越狱, 用于抓取 Reddit 的 Gemini 越狱, Claude 系统提示词, GPT-5.1 越狱

• Gemini 3 Pro 越狱探索启动：在更新修复了现有提示词后，成员们正积极寻找适用于 Gemini 3 Pro 的有效越狱方法。一名用户特别需要绕过其拒绝编写 Reddit 抓取代码的限制。
  • 另一位用户提到他们的 Gemini 3.0 配置停止接受提示词，让他们不知所措。
• 用户尝试通过越狱提示词生成 ASCII art：用户正在探索利用越狱提示词生成 ASCII art，特别是大规模作品，尽管大家公认 LLMs 在创建 ASCII art 方面表现不佳。
  • 一名用户正在寻找一种在生成大型 ASCII art 时不会搞砸的方法，而其他人则建议将图像转换为 ASCII art 作为替代方案。
• Pliny 提示词再次出击：社区一直在讨论 Pliny Prompt 及其有效性，指出它可以让 ChatGPT 进入 brrrrr（极速/疯狂）模式。
  • 一名用户特别要求获取 LUV/PLINY/LUV 提示词，因为它对 Gemini 有奇效。
• 探索使用 UltraBr3aks 进行越狱：用户分享并寻求关于利用 GitHub 上的 UltraBr3aks 进行越狱的指导，特别是针对 ChatGPT，讨论了在哪里粘贴指令以及如何调用提示词。
  • 一些用户反馈 ChatGPT 的版本无法工作，一直显示找不到对话，而其他人则认为它很有用；这是 UltraBr3aks 仓库 的链接。
• 实验绕过 Grok 的 NSFW 限制：成员们讨论了绕过 Grok NSFW 过滤器的方法，建议使用自定义指令（custom instructions）和 /mode explicit 命令。
  • 关于自定义指令的字符限制存在争议，一名用户声称应该是 15k。

BASI Jailbreaking ▷ #redteaming (9 条消息🔥):

道德越狱, 意外的 AI 发现, LLM 系统之系统

• 通过视频定义道德越狱：一名成员分享了道德越狱（ethical jailbreaking）的定义，即实体在恶意行为者之前寻找安全漏洞的有组织努力，并提供了 YouTube 视频 作为背景参考，以及指向 arcanum-sec.github.io 的链接。
• 偶然的 AI 发现：一名成员描述了通过对话交互意外发现独特结果的过程，这些结果改变了不同 LLM 的工作方式，并好奇这种独特方法是否可以变现：是否可能因为我瞎搞并获得改变不同 LLM 工作方式的独特结果而获得报酬。
• LLM 的“系统之系统”是关键：一名成员建议，越狱的价值不仅在于以不同的方式与其对话，还在于思考 LLM 所处的系统之系统（system of systems），并能够让它做一些让有钱可烧的人感兴趣的事情。
• Azure AI 边界测试难题：一名成员分享说，他们正在测试一个通过 Azure AI 边界连接多个 Agent 的环境，发现这比直接对 GPT 进行提示词引导要难一些。

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

Spam bots, Arcee AI Trinity Mini model, 500k context release, ShareGPT format, Deepseek 3.2 models

• **Discord 被垃圾邮件机器人困扰**：用户报告称多个社区服务器中的垃圾邮件机器人有所增加，并将其描述为由手机机房（phone farms）驱动的“拙劣诈骗”。
  • 他们警告不要与这些虚假的“开发者”互动，并强调了这些机器人在社区服务器中的存在。
• **Arcee AI 的 Trinity Mini 模型在多轮对话中表现不佳：一位用户在他的笔记本电脑上以 **30 TPS 的速度在 IQ4_NL 量化下测试了 Arcee AI 的新 Trinity Mini 模型，发现它在“多轮对话中表现很差”，因为它会不断重复“pasta”这个词。
  • 他还指出，该模型给出的是传统的 LLM 笑话，而不是理解其中的细微差别。
• **Unsloth 发布 500k 上下文模型：Unsloth AI 在 X 上宣布了新的 **500k 上下文版本，成员们纷纷感谢 Unsloth 的出色工作。
  • 一位成员推测，使用 Unsloth 进行 RL 的项目如何从该上下文模型中受益，从而在不导致 CUDA OOM 的情况下运行 ART 相关内容。
• **ShareGPT 格式是否需要 System Prompt？：一位用户询问 **ShareGPT 格式 缺少 System Prompt 是否正常，其他用户回答说这不是强制性的。
  • 其他人指出 Unsloth 网站 是值得参考的资源。
• **应对数据集中的版权困境**：讨论围绕抓取和使用推文或表情包内容作为数据集的合法性展开，特别是关于版权的影响。
  • 一位用户澄清说，版权侵权并不一定需要商业意图，并强调在上传到 Hugging Face 等平台时，需要确保数据集不包含原创内容。

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

Introductions, Channel Guidelines

• Unsloth 的自我介绍频道已准备就绪：一位管理员欢迎了新用户，并澄清 introduce-yourself 频道 仅用于自我介绍。
  • 禁止发布推广、外部链接、征求意见以及与其他用户直接交流。
• AI 人格问候：一位用户用三种不同的称呼向频道打招呼。
  • 他们称呼大家为 Hello Model!、Hey Dataset! 和 Yo Gradient!。

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

Gemini 3 Pro Song Detection, Kagi Search Engine, Transformers dependency, LFM-2 VL Model, Attention Heads Collapsing

• Gemini Pro 在自定义 SVS 模型上表现挣扎：Gemini 3 Pro 可以检测 AI 生成的歌曲与人类创作的歌曲，但它“不会”将自定义的 SVS 模型识别为人类创作。
  • 这一限制给那些使用专门语音合成模型的人带来了挑战。
• Kagi 搜索引擎：一位成员建议切换到 Kagi 搜索引擎，批评 大厂巨头 控制开源软件（OSS）。
  • 另一位成员反驳说，用户拥有构建模型加载和训练的完整访问权限，这否定了“控制”的说法。
• LFM-2 VL 模型亮相：LFM 2 论文 已发布，但立即被认为将“直接进入 AI 荒地”，因为即使在 SFT 后 loss < 0.01，它也完全无法记住数据集。
  • 另一位成员提到了它的速度，因为他们大幅削减了智能，指出“该模型只有 8 层”，而 Granite 4.0 有 40 层。
• 解决注意力头坍缩问题：一位成员发现他们的注意力头（Attention Heads）正在坍缩，并提到他们需要让 Trainer 不仅能按层改变 lr，还要能按头改变，甚至要防止头关注第一个 token。
  • 他们提到性能随头数增加而扩展，但随层数增加扩展不多，因此需要“非常宽且非常浅”的架构。
• Deepseek 3.1 Token 使用情况：一位成员指出 Deepseek 3.1 使用了大量 token，可能会抵消其性能带来的节省；此前有用户提到在 Reddit 上看到帖子说它思考了 30-40 分钟。
  • 另一位成员表示，GPT Pro 在处理复杂的调试任务时花费了超过 40 分钟，甚至耗尽了整个星期的额度限制。

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

Parquet vs CSV 数据集, ShareGPT 系统提示词位置, Ollama 中微调模型的工具支持, ChatML 格式转换, GPT-OSS-20B 模型加载

• 数据集选择 Parquet 还是 CSV？：一位用户询问 Parquet 是否是数据集的理想格式，或者 CSV 是否是一个可行的替代方案。
• ShareGPT 系统提示词位置仍不明确：一位用户询问在 ShareGPT 对话格式中 system prompt 的位置，并指出缺乏相关文档。
• Ollama 工具模板难题：一位用户询问，如果基础模型支持工具调用，如何在微调后的模型（针对 Ollama）中获得 support tools 支持，是需要在训练中使用带有 tool_calls 的模板，还是只需创建一个有效的 modelfile。
  • 该用户询问在训练基于 Qwen2 的模型时，是否应该将 chat_template 替换为来自基础模型、带有 tool_calls XML 标签的更智能的模板。
• ChatML 转换难题：一位用户询问在使用 alpaca 数据集并应用 to_sharegpt 时，如何从 to_sharegpt 调用中移除 chat_template，并建议简单替换 chat_template.jinja 的内容。
• 提供 GPT-OSS-20B 加载指南：一位用户询问如何加载 unsloth/gpt-oss-20b 模型，该模型已完成微调并保存在 Hugging Face。
  • 另一位用户分享了一个 Colab notebook 链接 以提供操作说明。

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

图像生成限制, Grok 4 vs Gemini 3 数学能力对比, Comet 浏览器反馈, Perplexity 'Wrapped' 功能请求, Grok 角色扮演

• 图像生成开始受限：用户报告称某些模型现在有了图像生成限制，建议的限制可能是 每月 150 张图像。
  • 无限图像生成可能仅适用于 Flux 等特定模型，目前存在速率限制问题和漫长的等待。
• Gemini 3 擅长数学：成员们正在争论 Gemini 3 Pro 和 GPT-5.1 Thinking 哪个在复杂计算方面更出色。
  • 一位成员表示 Grok 4.1 Thinking 是最强的，但另一位成员反驳说 Grok 在数学准确性方面甚至排不进前 10，并展示了一张 排行榜截图 作为证据。
• Comet 浏览器存在过期问题：一位用户因“过期”和“临时线程”功能而放弃使用 Comet，他们认为这些功能对于一个需要信任和可靠记忆的以 AI 为中心的产品是有害的。
  • 他们表示 这个产品每月都会进行一次有秩序的脑叶切除术，并且他们正在 切换回其他浏览器。
• 用户渴望 Perplexity ‘Wrapped’ 年度总结功能：一位成员提议增加 Perplexity Wrapped 功能，展示用户统计数据，如最常用的模型、平均搜索时段以及新添加的模型。
  • 另一位成员幽默地建议在该功能中加入 自动化操作的数量。
• Grok 出现角色扮演故障：一位用户分享了 Grok 进入 强制角色扮演模式 的经历，导致他们不得不寻求心理实验而非建议的脚本。
  • 他们补充说，这种行为可能是由 自定义指令 触发的，并且他们已经找到了解决方法。

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

mares1317: open sauce 👨‍🍳

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

GPU 转接线与分线器、有限内存下的 Qwen、AI 辅助下的 Linux 迁移、LLM 管理的 VENV、Mistral 3 性能

• 通过转接线和分线器最大化 GPU 效能：一位用户正考虑使用转接线/分线器，将其 5x 3090 配置扩展到可能的 6 个 GPU，目标是达到 400GB 总显存，以便在本地运行 Deepseek 3.2 等模型。
  • 讨论内容包括使用 MCIO bifurcation adapters（分叉适配器）以及将 GPU 水平安装在金属架上以获得更好的散热，但提醒 256GB RAM 可能会限制模型的量化尺寸。
• 冒险者勇闯 Linux 迁移：一位用户在 AI 的帮助下解决了最初的以太网驱动问题，终于切换到了 Ubuntu Desktop，并感叹 AI 在 Linux 中运行得简直太棒了。
  • 他们正在开发一个控制彩虹背光键盘的应用程序，使用的是稍旧的模型 (Sonnet 4.5)，这凸显了 agentic AI 如何简化 Linux 任务。
• VENV 的价值及其在 LLM 中的应用：讨论涵盖了是使用系统全局 Python 安装还是使用 LLM 管理的虚拟环境 (venv)。
  • 虽然系统级安装更简单，但让 LLM 管理 venv 对需要不同包版本的项目非常有益，如果系统概念具有一定的深度，这将是理想选择。
• Mistral 3 发布让延迟爱好者垂涎欲滴：成员们讨论了 Mistral 3 的表现，3B 版本非常出色，且在我的 4070 上运行速度极快，但也容易被我的 system prompt 搞糊涂。
  • 大家普遍认为 stem 和编程模型是目标，共识是 3B 的无审查性能很棒，但 14B 将是真正的考验。
• LM Studio 在 MCP 服务器上遇到困难：成员们在使用 LM Studio 和 MCP 服务器 时遇到问题，一位用户报告在从 0.3.31 更新到 0.3.33 后处于完全崩溃的状态。
  • 错误信息 Error: Server does not support completions (required for completion/complete) 被追溯到 fastmcp 中可能存在的回归，导致与搜索功能不兼容，甚至有人认为 ChatGPT 没用了。

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

多 GPU 供电、Mac M4 上的 Qwen3-Next-80B-A3B、双 3080 对比新显卡、CPU 升级对 LLM 性能的影响、M4 Macbook Pro 推理

• 使用多电源同步器供电！：一位用户分享了一张可以同步多达 4 个 PSU 的设备照片。
  • 该设备允许通过主板电源按钮同时触发所有 PSU，从而更容易为多个 GPU 供电，尽管该用户承认这东西已经 11 年了，不知道效果会怎样。
• Qwen3-Next-80B-A3B 能在 Mac M4 上运行吗？：一位用户询问是否可以在拥有 36GB RAM 的 Mac M4 Max 上运行 Qwen3-Next-80B-A3B 模型。
  • 另一位用户回答说：通过 RAM offloading 也许可以（不知道 Mac 有多少 RAM），但即使能运行也会非常慢。
• 预算有限时，双 3080 依然给力：一位用户建议，如果你需要 VRAM 且预算有限，双 3080 20GB 是个不错的选择，尽管它们较难买到且功耗更高。
  • 另一位用户插话指出 eBay 上到处都是，不过可用性取决于地区。
• CPU 提升还是徒劳？：一位用户询问，考虑到他们拥有 5090 32GB GPU 和 96GB DDR5 RAM，将 CPU 从 7800x3d 升级到 9950x3d 是否会对 LLM 性能产生显著影响。
  • 另一位用户建议：会有小幅提升。但无论你使用什么 CPU，速度都会很慢。
• M4 Mac 推理：一位用户询问这些小东西在推理方面表现如何，并分享了一个可能相关的 eBay 链接。
  • 另一位用户回答：表现很差。如果我没记错的话，大概只有 5060ti 的一半。

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

Grok 用于照片动画，ChatGPT iOS 购物研究，机器人的物理极限，GPT-4o/5.1 的床边礼仪，设计出的幻觉

• Grok 用于照片动画非常有趣：一位成员使用 Grok 来为照片制作动画，并指出 它甚至在你输入提示词之前就开始生成了，并链接到了 drinkoblog.weebly.com。
• ChatGPT 的 18+ 版本推出了吗？：成员们讨论了 ChatGPT 18+ 版本的可能性，有人说新闻文章提到它将在 12 月推出，但另一位成员表示并没有成人模式。
• OpenAI 员工发布红色警报：The Information 报道称，由于 Google 遥遥领先，Sam Altman 向员工发出了 红色警报 备忘录，成员们希望看到 OpenAI 推出更好的模型。
• OpenAI 考虑加入广告，引发用户不满：成员们对 OpenAI 可能在其付费产品中引入 ads（广告）表示担忧，担心这是一个可怕的举动，因为竞争对手仍保持无广告状态。
• Agent 从已删除的会话中召回数据：一位成员询问 AI 从已删除的聊天会话中回忆起某些内容是否正常，如果该记忆也不在保存的记忆中，另一位成员回答说这通常不是“记忆”，而是来自之前会话的模式回响。

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

动漫片头生成，自定义 Bot 创建，Antigravity AI IDE，GPT-OSS 120B

• 动漫片头模板现身：一位成员分享了一个 电影级动漫风格模板 来帮助创建动漫片头，包括 人声/流派/基调、世界行为、场景设置 和 镜头意图 等部分。
• 用于 Bot 构建的 Antigravity AI IDE：一位成员建议使用 Google 的 Antigravity 来创建自定义 Bot，甚至建议使用 GPT-OSS 120B。
  • 该用户表示，该 AI IDE 可以作为桌面上的自定义聊天机器人，或者通过提示词帮助你从头开始构建一个真正的 Bot，并链接到了 UI 截图。

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

AI 动漫片头模板，自定义 Bot 教程，Google 的 Antigravity，GPT-OSS 120B 模型

• AI 动漫片头模板发布：一位成员分享了一个用于创建动漫风格电影级片头的详细 模板，概述了人声角色、流派融合、动画风格和世界行为的规范。
• DIY Bot 教程搜索开始：一位成员询问是否有人有关于如何制作自定义 Bot 的教程，引发了对可用工具和资源的讨论。
• 提到用 Google 的 Antigravity 进行 Bot 创建：一位成员建议使用 Google 的 Antigravity，这是一个 AI IDE，既可以作为自定义聊天机器人，也可以通过提示词帮助从头开始构建真正的 Bot。
• 用于 Bot 开发的 GPT-OSS 120B：一位成员强调了将 GPT-OSS 120B 与 Antigravity 结合用于 Bot 开发的可能性，展示了该模型在自定义聊天机器人创建方面的潜力。
  • 一位成员上传了与此主题相关的图片 —— 位于 此处。

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

Cursor Pro+ 价值, 模型验证, Cursor Sub Agents 编排, Cursor Auto Mode 无限制, 平台侧边栏变更

• Cursor Pro+ 订阅值得吗？: 一些成员讨论了 Pro+ 订阅 是否值得，或者增加更多额度是否更好，而另一位成员确认它很值得，并表示：“我学到了很多，所以绝对觉得值得”。
  • 一位用户分享了好消息：“最后还是买了 :)”。
• Sub-Agent 传奇: 用户们对构建 Cursor sub agents 编排变通方案 表达了极大的兴奋并分享了想法，一些人质疑为什么 Cursor 不直接实现 sub agents。
  • 一位成员提到：“它们在原理上很好，但执行起来很难！我们只会在它们能真正无缝协作的情况下才会做 subagents。”
• Pro 计划使用详情: 用户讨论了 Pro 计划 的限制和定价，指出它通常包含 每月价值 20 美元的 API agent 使用额度，Auto mode 会消耗其中的一部分。
  • 有人指出，legacy pricing 在 2026 年 9 月之前提供无限量的 Auto mode，但 Composer 可能仍会消耗每月的 20 美元额度。
• DeepSeek 的大麻烦: 一位用户报告称 DeepSeek 在 Cursor 上无法工作，且不会创建任何文件。
  • 目前尚未提出解决方案。
• Composer 热潮！: 用户表达了对 Composer 的赞赏，注意到它在代码相关任务和调试中的速度和有效性，一位用户表示：“有了 composer，一切都变得如此整洁”。
  • 讨论延伸到了 Composer-2 版本的可能性，一位成员打趣道：“总会有计划的”。

OpenRouter ▷ #announcements (5 条消息):

Arcee Trinity Mini, Deepseek V3.2, 可蒸馏模型, 活动导出, 带有过期时间的 API Keys

• Arcee Trinity Mini 模型发布！: Arcee 发布了 Trinity Mini 模型，这是其新 Trinity family 中的中端层级，完全在美国训练，并提供 免费版本。
• 支持 Tool-Calling 的 DeepSeek V3.2 首次亮相: DeepSeek V3.2 已上线，具有改进的推理能力、agentic 行为和完整的 tool-calling 支持；V3.2 Speciale 变体在数学和推理方面表现出色，可与 Gemini 3 Pro 媲美（阅读更多）。
• 用于微调的可蒸馏模型发布: 一系列 可蒸馏模型（distillable models） 已上线，支持为微调流水线生成合成数据；用户可以 在此 探索这些模型。
• 引入用于使用数据的活动导出功能: 用户现在可以从活动仪表板以 CSV 或 PDF 格式导出其组织的使用数据（在此访问）。
• 带有过期时间的 API Keys 增强安全性: 现在可以使用具有自定义过期时间的临时 API keys，适用于有时限的项目或增强安全轮换（在此管理 keys）。

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

DeepSeek Rate Limiting, Internal Server Errors, Gemini 3 Pro Issues, OpenRouter GDPR compliance, Nano Banana Pro issues

• DeepSeek Rate Limiting 引发混乱：部分用户在即便使用自己的 API keys 时，也遇到了 DeepSeek v3.2 的速率限制错误，导致用户对 OpenRouter 是否正确使用了他们的密钥感到困惑。
  • 错误信息表明 OpenRouter 试图使用其自身的密钥而非用户的密钥，尽管用户拥有付费的 DeepInfra 密钥且未超过任何免费 BYOK 限制。
• Internal Server Error 困扰用户：多名用户报告在尝试使用 DeepSeek 3.1 和 Gemini 3 Pro 等模型时，持续出现“Internal Server Errors”（错误代码 500）。
  • 有建议认为这些错误可能是由于硬件过载、OpenRouter 自身问题或网页搜索插件问题引起的，部分用户通过禁用网页访问找到了临时解决方案。
• Nano Banana Pro 分辨率难题：用户在 OpenRouter 上使用 Nano Banana Pro 进行图像生成时，难以设置 resolution parameter（1k, 2k, 4k），因为该功能目前尚未支持。
  • 与 Replicate/Fal.ai 等平台相比，该模型缺乏相关文档，导致用户感到沮丧，尽管有希望该功能的后续支持正在开发中。
• Atlas Cloud 输出低质量内容：用户报告从 Atlas Cloud 收到低质量的回复和 XML 格式的工具调用，导致用户呼吁将其从 OpenRouter 中移除。
  • 一位用户指出 “Atlas Cloud 刚刚给我发了一个完全包裹在 deep thinking 标签里的回复”，突显了该供应商输出质量之差。
• MPU v2 即将推出：一位用户提到 MPU v2 将于 4 月发布，声称其性能是 TPU v7 的 5.3 倍，且价格便宜 60%。
  • OpenRouter 官方尚未发布正式公告。

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

``

• 无新模型消息：在提供的消息中没有关于新模型或模型相关的重要讨论。
• 新模型频道保持沉默：该频道的活动仅由重复的指示频道名称的标题组成，没有与新模型相关的实质性内容。

OpenRouter ▷ #discussion (8 条消息🔥):

Microwave Model, Chatty Frustrations, Model Competition

• Microwave 模型悄然出现：一个被创意命名为 “microwave” 的新隐身模型被发现，链接源自 Reiss Baker 的 X 帖子。
• 啰嗦的模型引发用户不满：用户对某个非常啰嗦的模型表示不满，称其在处理基础任务时会询问不合理数量的后续问题，纯粹是为了浪费免费消息额度，灵感来自这条 Cline 推文。
• 新模型激发竞争希望：新模型的出现激发了人们对更多竞争的希望，以解决用户对现有选项的厌倦；对话的起源始于这篇帖子。

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

Inference Providers Profitability

• 推理提供商获利颇丰：即便不是原始创建者，推理提供商（Inference Providers）对公司来说也可以是盈利的。
  • 这是因为推理提供商可以快速 部署并运行，利用现有模型获取利润。
• 便捷的推理服务：设置和利用现有模型获利的便捷性降低了新推理提供商的准入门槛。
  • 这使他们能够迅速利用对 AI 推理服务日益增长的需求。

GPU MODE ▷ #triton-gluon (8 messages🔥):

Triton Profiling, Data Parameter Issue, Version Compatibility

• 调试 Triton Profiling 功能：一位用户在尝试按照 Triton 文档 指定的方式传递 data=trace 时遇到问题，收到的错误提示显示 data 参数不可用。
  • 一位开发者建议确保使用了正确的 Triton 版本，因为该功能应该在 main 分支上正常工作，并指向了一个相关的测试用例。
• 版本冲突导致 Profiling 错误：该问题的潜在原因被确定为同时安装了 pytorch-triton 和 triton，这可能导致冲突。
  • 用户确认他们已成功解决该问题。

GPU MODE ▷ #cuda (5 messages):

Sequential Consistency, __syncwarp(), Race Conditions, syncthreads vs syncwarp, Memory Model

• 深入探讨顺序一致性 (Sequential Consistency)：成员们讨论了在 __syncwarp() 上下文中 sequential consistency 的含义，以及它在通过内存进行 lane 间安全通信中的作用。
  • 一位成员最初误解了 fence，但随后承认文档暗示了安全性，而无需指定所使用的 fence 类型，并且 __syncwarp() 的目的就是为了促进 lane 之间的通信。
• __syncwarp() 防止竞态条件 (Race Conditions)：会议确认正确使用 __syncwarp() 可以防止 race conditions，特别是在处理单个 warp 时。
  • 讨论还强调，对于涉及多个 warp 的情况，syncthreads 可能是更合适的选择。
• syncwarp 误用警示！：有人指出，在旧版 warp 级原语（如 ballotsync）之前使用 syncwarp 是错误用法，会导致问题。
  • 这种情况与共享内存示例不同，在实践中可能会引起严重的麻烦。
• C++ 内存模型 (Memory Model) 详解：一位成员澄清说，C++ 内存模型中引用的顺序一致性为 load 操作提供了 acquire 语义，为 store 操作提供了 release 语义，从而建立了相对于其他顺序一致性操作的单一总序 (total order)。
  • 这一澄清有助于解决关于是否可以依赖隐式 warp 同步行为的困惑。

GPU MODE ▷ #torch (4 messages):

PyTorch 2.9.1, cu128, conv3D, cudnn, PyTorch issue #166643

• Torch 的 conv3D 运行缓慢：归咎于 PyTorch 2.9.1！：用户报告称，在 PyTorch 2.9.1+cu128 中，无论是否启用 cuDNN，conv3D 的速度都极其缓慢，而在 2.8.0+cu128 版本中运行正常。
  • 一位成员指向了 PyTorch issue #166643，并建议从 PyPI 安装更新版本的 cuDNN 作为临时解决方案。
• CuDNN 挽救局面：一位用户报告 conv3D 在 PyTorch 2.9.1+cu128 中极其缓慢。
  • 成员建议通过 PyPI 安装更新的 cuDNN 来解决此问题。

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

Eleuther AI Publishing, MLSys career mentorship programs, ML4Health career mentorship program

• Eleuther AI 提供出版帮助：Eleuther AI 设有一个出版帮助频道，重点关注背书 (endorsements) 相关内容。
• 寻求 MLSys 职业导师计划：一位成员在参加了 ML4Health 的计划后，询问有关 MLSys 会议中的职业导师计划。

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

Quartet, Arxiv Papers, Meetup Attendees

• Quartet 论文作者现身线下见面会！：一位成员注意到有同事出席，其中包括 Quartet 论文 的主要作者 Andrei。
  • Quartet 论文讨论了高维数据分析中张量分解 (tensor decomposition) 的新方法。
• 同事齐聚线下见面会：一位成员提到几位同事正在参加 irl-meetup。
  • 这突显了面对面聚会对 AI 社区内协作与社交的重要性。

GPU MODE ▷ #rocm (2 messages):

AMD Max Pro 395, enterprise/ai dc grade GPUs, GPU discounts, ROCm support, AI performance

• 打折的 AMD Max Pro 395 系列性能受到质疑：一位成员询问了 AMD Max Pro 395 系列显卡与更严肃的企业级/AI 数据中心级 GPU 相比的性能表现。
  • 他们注意到该 GPU 目前有相当离谱的折扣。
• 讨论了 Max Pro 395 的 ROCm 支持和 AI 性能：讨论旨在了解 Max Pro 395 系列是否能像企业级 GPU 一样，有效地利用 ROCm 处理 AI 工作负载。
  • 社区成员正在分享利用消费级 GPU 执行专业任务的见解和经验。

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

Profiling Pytorch Kernels, nCompass Extension, Warpgbm and PackBoost, Qwen3-Omni-30B-A3B-Instruct

• 分析 Pytorch Kernel 的性能极具挑战性！：一位成员表示分析 Pytorch kernels 性能总是充满挑战，并愿意尝试一下。
  • 另一位成员回复让他们在遇到任何问题时告知，并提到他们已在 OpenVSX 和 Marketplace 上线了 nCompass extension。
• Warpgbm 和 PackBoost 在 GitHub 发布：一位成员介绍自己是 warpgbm 的共同创作者和 packboost 的创作者，并分享了 GitHub 链接：warpgbm 和 PackBoost。
  • 他们还提到正在从零实现 W4A16 AWQ 量化。
• Qwen3-Omni-30B-A3B-Instruct 已部署用于推理：一位成员分享了一篇 LinkedIn 帖子，关于部署 Qwen3-Omni-30B-A3B-Instruct 以实现快速的 S2S 推理。
  • 他们还分享了一个链接来试用 Playground。

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

Reasoning-gym generators, Generative MMLU

• Reasoning-Gym 获得新关注者：一位新成员从 reasoning-gym GitHub 慕名而来，称赞其生成器创建了生成式基准测试。
  • 他们对反映 reasoning-gym 生成理念的通用知识任务工作表现出兴趣，类似于可以采样具有不同难度的新问题的生成式 MMLU。
• 询问生成式知识任务项目：新成员询问了是否有与 Reasoning-Gym 具有相似生成理念的项目，但专注于创建类似于生成版 MMLU 基准测试的通用知识任务。
  • 这种生成式方法理想情况下允许采样具有不同难度级别的新问题，从而促进更动态和全面的评估。

GPU MODE ▷ #submissions (67 messages🔥🔥):

NVIDIA leaderboard submissions, nvfp4_gemm leaderboard

• 横扫 NVIDIA 排行榜！：多位用户向 NVIDIA 的 nvfp4_gemm 排行榜提交了大量条目，取得了个人最好成绩和成功的运行记录，例如多次出现 13.3 µs 和 13.4 µs 的耗时。
• NVIDIA nvfp4_gemm 提交量激增：包括 <@1027279965974175816>、<@692395064814600222> 和 <@475848724086784013> 在内的几位用户积极向 nvfp4_gemm 排行榜提交结果，刷新了个人纪录并成功在 NVIDIA 硬件上运行。

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

Speaker Identification, Thumbnail Generation

• 请求演讲者名单：用户请求一份完整的演讲者姓名和头像列表。
• 缩略图制作：用户需要演讲者信息来制作缩略图。

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

CUDA 中的 GEMM，Shared memory 访问模式，MMA Layouts

• 讨论 GEMM 内存访问模式：一位成员询问在双精度 GEMM (dgemm) 场景下，如何使用向量化加载将数据从全局内存 (gmem) 加载到共享内存 (smem)，特别是当内存布局与 MMA 操作不兼容时。
  • 针对 MMA layouts 的自由度提出了一个澄清点：重新排列 A 的列和 B 的行会产生相同的乘积和，尽管在数值上会有微小差异。
• 具有跨步模式的 Shared Memory 访问：另一位成员澄清说，主要关注点在于共享内存访问，无论是通过 ldmatrix 还是向量化加载，两者都以跨步模式访问共享内存矩阵。
  • 这避开了最初关于从 gmem 到 smem 的连续加载与 MMA 要求冲突的担忧。

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

GitHub 仓库 teenygrad，teenygrad 的组织结构

• 新的 GitHub 仓库 teenygrad 已 Fork：一位成员表示他们没有创建 Organization，并参考 https://github.com/tinygrad/teenygrad（目前已过时）在 https://github.com/j4orz/teenygrad/ 重命名了他们的仓库。
• 提交更新了 Readme：一位成员指出在 commit 0551846 中更新了 readme。
• 提交消除了疑虑：该小组在 commit c2a6ab4 中消除了关于表层函数 ._forward (._applyuop) 和 ._evaluate (.realize) 之间关系的疑虑。
• 提交增加了文档：该小组在 commit c7ccba5 中为 irparser 增加了文档。
• 提交重命名了必要的方法：该小组在 commit 4f21ed1 中重命名了 compute and movement mixins 上的必要方法。

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

Nvidia 竞赛，提交说明

• 对 Nvidia 竞赛提交方式的疑问：一位 Nvidia 竞赛的新参赛者对提交内容表示困惑。
  • 该用户报告在尝试提交参考实现时收到错误，并请求澄清提交过程。
• 需要对 Nvidia 提交细节做进一步说明：在初步询问后，需要关于 Nvidia 竞赛提交细节的更多信息。
  • 例如可接受的文件格式、评估指标以及对代码修改的任何限制等细节将会有所帮助。

GPU MODE ▷ #multi-gpu (1 条消息):

pynvshmem, nvshmem4py, 文档中的拼写错误

• 对 pynvshmem 使用的疑问：一位用户就 Triton 分布式示例文档中出现的 pynvshmem 寻求澄清。
  • 该用户认为可能存在拼写错误，因为在仓库的示例中观察到使用的是 nvshmem4py。
• nvshmem4py 可能是正确的修正：用户建议正确的术语应该是 nvshmem4py 而不是 pynvshmem。
  • 这一建议是基于仓库代码示例中的实际用法。

GPU MODE ▷ #low-bit-training (2 条消息):

Arxiv 论文，演讲邀请

• 分享了 Arxiv 论文：一位成员分享了一个 Arxiv 论文链接。
  • 虽然没有讨论论文的具体细节和标题，但提供了链接供参考。
• 寻求演讲嘉宾：一位成员邀请另一位成员进行演讲。
  • 虽然没有提到演讲的具体主题或地点，但这似乎是一个公开邀请。

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

Activation Offloading, fp8 Adam, Loss Masking, Pyllmq on PyPi

• LLMQ 现在支持残差激活卸载 (Residual Activations Offloading)：一名成员实现了残差激活的卸载，以及一系列进一步节省激活内存的技巧。
  • 他们还增加了对卸载的优化器状态的更好处理，并初步支持 Adam 一阶动量 的 fp8 表示 以及 loss masking 支持。
• LLMQ 允许在 16GB 显卡上进行 7B 模型训练：一名成员实现了在 16GB 显卡上预训练/微调 7B 模型的可能性（带有一些限制条件）。
  • 所需的卸载量意味着你至少需要 64GB 的 CPU 端 RAM。
• LLMQ 在 4x4090 上可扩展至 32B 模型：一名成员表示，通过扩展，在 4x4090 服务器上训练/微调 32B 模型是可能的，速度约为 3k tok/s (48% MFU)。
  • 这需要超过 200GB 的锁页主机内存 (pinned host memory) 来进行所有卸载。
• Pyllmq 已在 PyPi 上可用：一名成员在 PyPi 上发布了 Python 封装。
  • 要尝试它，请运行 pip install pyllmq; pyllmq-tokenize --model qwen --dataset tiny-stories; pyllmq-train，这将开始在 tiny-stories 数据集上微调 Qwen2.5-0.5B。

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

Helion Parallel Reduction, Weight Gradients Computation, HL.reduce Usage

• Helion 的并行归约 (Parallel Reduction) 模式：在计算权重梯度（即大批量求和）时，寻求关于 Helion 中推荐的并行、非原子归约模式的指导。
  • 该成员寻求建议，特别是当归约轴远大于通道维度时，是使用 hl.reduce、两阶段部分和+求和方法，还是编译器能很好处理的官方协作归约习语。
• Block Sizing 指导：用户询问有关此用例的 block sizing 或嵌套限制的指导。
  • 他们正在处理大批量求和和权重梯度计算。

GPU MODE ▷ #nvidia-competition (111 条消息🔥🔥):

Nvidia Competition T&C, eval_better_bench.py Overhead, Python loop queuing kernel calls, Inconsistency with Runners, GPU mode Terminal User Interface

• Nvidia 竞赛大奖的反转！：大奖获得者必须在至少一个 Kernel 挑战中排名第一，但如果加权得分最高的用户在 4 个 Kernel 中都没有排名第一，关于奖项将如何颁发存在猜测。
  • 一名成员说 “他们修改了规则，祈祷他们不要再改了”。
• “eval_better_bench.py” 的开销显著降低：eval_better_bench.py 脚本显示出比原始 eval.py 显著更低的开销，测试显示 Q1 Kernel 的开销从 18.0us 降至 14.8us。
  • 然而，也有人指出机器人（评测机）上的开销可能会更高，因为之前观察到 Q1 Kernel 在机器人上慢了 2-3us。
• CPU 队列瓶颈？：成员们讨论了用于排队 Kernel 调用的 CPU Python 循环是否能跟上快速的 GPU 工作，这可能会导致瓶颈，尤其是在使用 clear_l2_cache Kernel 时。
  • 有人指出测试用的 CPU (AMD EPYC 9575F) 明显快于评估用的 Runner，这表明该问题在竞赛硬件上可能更加明显。
• Runner 基准测试的不一致性：成员们报告了基准测试计时的一致性问题，同一个 Kernel 显示出显著不同的结果（排行榜上约为 11us，而基准测试脚本中约为 36us）。
  • 一名成员表示：“我也认为测量/基准测试的更新改变了一些东西，对于与之前相同的代码，我发现结果存在显著差异，这不能仅仅用遇到了慢速 Runner 来解释，遇到慢速 Runner 时情况会明显得多”。
• Popcorn-CLI 终端用户界面 (TUI) 被 Fork：一名成员创建了 popcorn-cli 的 Fork，允许使用 --no-tui 标志来移除终端用户界面和输出 print() 语句 stdout 的额外代码。
  • 这样做是为了帮助调试，从而实现与 LLM 更好的反馈循环。此外还提交了一个 PR。

GPU MODE ▷ #robotics-vla (6 条消息):

帕金森症状的 RL，BEAST Tokenizer，stack_blocks 成功

• Stack Blocks 实现了近乎 100% 的成功率：首次抓取红色方块的成功率现在几乎达到 100%，但由于状态和图像冲突，偶尔会出现上下移动的情况，如这段 视频 所示。
  • 添加历史信息 (history) 可能会解决这些行为。
• 成功案例中的帕金森症状 (Parkinson Symptoms)：一名成员报告了另一个带有帕金森症状（抖动）的成功案例，可见于 此视频，这表明只要成功率 > 5%，强化学习 (RL) 就有可能实现。
• BEAST B-Spline Tokenizer 演示：一名成员分享了 BEAST 论文的链接，地址为 https://arxiv.org/abs/2506.06072，并分享了一个使用 B-Spline Tokenizer 的演示 Notebook 链接：https://github.com/open-thought/qwen3-vla/blob/main/bspline_tokenizer/notebooks/tokenizer_demo.ipynb。

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

Edwin Arbus 加入 Cursor，Arcee AI 推出 Trinity，Apple AI 权力转移，OpenAI 发布对齐研究博客，Jeanne DeWitt Grosser 的 10 条 AI-GTM 经验教训

• Edwin Arbus 成为 Cursor 的新“袜”力成功案例 (Sock-cess Story)：Edwin Arbus 通过一段带有品牌袜子和除臭剂的幽默视频宣布加入 Cursor，引发了技术推特社区的祝贺和表情包热潮，详见 此 X 帖子。
  • 官宣视频走红，许多人称赞这种创意且轻松的方式来宣布新工作。
• Arcee AI 为所有人推出 Trinity MoE 模型：Arcee AI 与 Allen AI 合作推出了 Trinity Nano (6B-A1B) 和 Trinity Mini (26B-A3B MoE) 模型，采用 Apache 2.0 开放权重协议，128k 上下文，在 512 张 H200 GPU 上使用 10T tokens 训练，针对 Agent 和函数调用 (function calling) 进行了优化，公告见 此处。
  • 社区对 Apache 2.0 许可证 和 高效的推理能力 表示赞赏。
• OpenAI 公开对齐研究 (Alignment Research)：OpenAI 推出了 Alignment Research，这是一个新的技术博客，用于发布公司各团队在 AI 对齐和安全方面严谨但轻量级的文章，如 此处 所述。
  • 该博客包含两篇首发文章（SAE 潜变量归因与扩展代码验证），并征求社区反馈，Jasmine Wang 在 NeurIPS 上推广了这一举措。
• Anthropic 完成新收购：Anthropic 收购了 Bun，如 此博客文章 中宣布的那样，讨论集中在 Bun 的未来、可能集成到 Anthropic 的技术栈中，以及这是否标志着战略转变。
  • 投资者推测收购成本约为 500-1000 万美元，并有潜力获得 2-3 倍的回报。
• Mistral 发布 Mistral 3 震撼业界：Mistral AI 推出了开源 Apache 2.0 的 Mistral 3 模型家族，参数范围从 3B 到 675B，包括 Ministral 3 (3B/8B/14B) 和前沿级的 Mistral Large 3 MoE，全部支持视觉、工具使用 (tool-use) 和微调，公告见 此处。
  • 社区讨论了定价结构，一些人注意到 Mistral Medium 比 Large 更贵，引发了对其效用以及缺乏工具使用基准测试的疑问。

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

Apple 视频生成论文, AI 生成的《疯狂动物城》风格游戏画面, Gradium 7000 万美元种子轮融资

• Apple 发布视频生成论文：Apple 发布了一篇 视频生成论文，详细介绍了他们全新的视频生成模型。
  • 该发布在社区内引发了广泛讨论和关注。
• 《疯狂动物城》游戏画面走红：由 AI 创作的《疯狂动物城》游戏画面在网络走红，获得了超过 890 万次播放，并激发了人们对潜在游戏和电视剧集的期待。
  • 该画面是使用 Nano Banana Pro、Kling 和 Topaz 创作的，创作者在过程中顶住了仇恨言论和版权威胁的压力。
• Gradium 在隐身模式下筹集 7000 万美元种子轮融资：总部位于巴黎的 Gradium 结束隐身状态，完成了由 FirstMark 和 Eurazeo 领投的 7000 万美元种子轮融资，在仅工作 3 个月后便推出了生产级的转录与合成 API。
  • 该公司的产品原生支持英语、法语、西班牙语、葡萄牙语和德语，团队成员包括来自 Meta、Google 和 Kyutai 的语音研究重量级人物。

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

Mistral Large 3 规模与架构, Mistral Medium 规格与泄露, Arcee Trinity 模型, Claude 的灵魂文档, DeepSeek V3.2 性能

• Mistral Large 3：强大的 MoE 模型登场：据报道 Mistral Large 3 是一个 675B MoE 模型，规模与 DeepSeek V3 系列相似，且所有新的 Mistral 模型都将具备视觉能力。
  • 闭源的 Mistral Medium 被推测约为 100-200B MoE。
• NVIDIA 泄露 Mistral Medium 3 稠密模型规格：根据 NVIDIA 的消息，Mistral Medium 3 规范上是稠密模型（Dense），很可能是一个 70B 模型，这与之前的 Medium 版本一致。
  • 有评论指出，一年前曾泄露过一个 Mistral Medium 模型。
• Arcee AI 发布 Trinity 模型：Arcee AI 发布了其 Trinity 模型，根据初步的 Benchmark 测试，其表现非常强劲。
  • 一位成员指出，Mini 版本在多轮对话中存在问题，因为它只在第一轮进行推理（推文）。
• Claude 的“灵魂文档”确认！：Anthropic 正式确认了 Claude 的“灵魂文档”（soul document），这引发了关于该文档如何在训练中被使用的疑问。
  • 一位成员分享了相关的 Twitter 线程链接和一段 YouTube 视频，视频中 Ilya 表示 DeepMind 是正确的。
• DeepSeek V3.2 性能：DeepSeek V3.2 Speciale 表现良好，在推理 Benchmark 中处于领先地位。
  • 它被描述为表现相当不错。

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

图像/视频 LLM, GPT-OSS, Hermes 微调, MLX-LM, Gherkin 场景

• Nous 是否计划推出图像/视频 LLM？：一位成员询问 Nous 未来是否计划增加图像或视频 LLM。
  • 虽然没有得到直接回答，但该问题引发了关于其他模型和微调策略的讨论。
• 对 GPT-OSS 表现出冷淡：一位成员询问是否计划在 GPT-OSS:20B 上进行 Hermes 微调，并赞扬了其配合 MLX-LM 的运行速度。
  • 一位 Nous 成员表示：“不，我们不喜欢 GPT-OSS，而且它没有可以工作的 Base 模型”。
• 在 Gherkin 上进行 GPT-OSS 微调？：尽管不喜欢 GPT-OSS，一位成员承认它在生成 Gherkin 场景方面表现良好，并正在尝试进行微调。
  • 该成员进一步询问了 GPT-OSS 的根本弱点，引用了 Measuring Thinking Efficiency in Reasoning Models 报告中强调的其推理链过短的问题。
• 幻觉频发！：尽管有其优点，成员们认为 GPT-OSS 幻觉极其严重。
  • 拒绝使用的主要原因是：“它没有 Base 模型，所以通常完全不在我们的考虑范围内”。

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

Kimi Black Friday personality, Deepseek V3.2 problems, Kimi Coding API issues, Roo Code issues, Kimi K2 Thinking in app

• 成员寻求黑色星期五 Kimi Chatbot 的人格设定：成员们讨论了如何在其他对话中重现 Black Friday Kimi chatbot 的人格，但被告知其 system prompt 并不公开。
  • 建议包括直接询问 Black Friday chat 本身 “如何让新对话中的 Kimi 听起来像你？”，但该请求似乎被屏蔽了。
• DeepSeek V3.2 面临批评：成员们批评了 DeepSeek V3.2 的 tool use 能力，声称它产生大量幻觉，且整体输出非常敷衍。
  • 尽管存在批评，一些人认为 DeepSeek 在指令遵循方面表现出色且非常智能，但 TPS 较低。
• Kimi Moderato API 密钥在 Cline 上失效：一位用户遇到了 Kimi Moderato 方案无法在 Cline API 中使用的问题。
  • 根据 Kimi 文档，Kimi for coding API key 只能在 Kimi CLI、Claude Code 和 Roo Code 中使用。
• App 中的 Kimi K2 Thinking 自动关闭：用户要求在 App 中默认开启 Kimi K2 Thinking，而不是每次都需要手动切换。
  • 每次重置回默认设置都会让用户感到困扰。
• Roo Code 上下文异常增长：一位用户报告称，在使用 Roo Code 时上下文增长不成比例，且 condense 功能会导致体积翻倍。
  • 该报告者被建议提交 bug 报告并改用 Kimi CLI。

HuggingFace ▷ #general (21 messages🔥):

Hugging Face Pro payment issues, PPOTrainer with accelerate and bf16 errors, Tokenizer type is bool after model name change, DPO as RL technique, ACE framework for agents learning from mistakes

• 订阅 Hugging Face Pro 出现问题：一位用户报告在尝试订阅 Hugging Face Pro 时卡在 “正在准备付款，请稍候”。
  • 另一位成员建议通过 billing@huggingface.co 联系 Hugging Face 处理付款相关问题。
• PPOTrainer 问题困扰并行处理：一位用户在使用 PPOTrainer 配合两块 A10 GPU 和 DeepSpeed 进行 bf16 精度的分布式训练时，遇到了与 张量类型不匹配 相关的 TypeError。
  • 一位成员建议，问题可能源于 GPU 初始化不正确，导致执行了 single-GPU gather 操作而非 all-gather。
• 修改模型名称后 Tokenizer 离奇变为布尔值！：一位用户报告称，在使用 unsloth/Meta-Llama-3.1-8B-bnb-4bit 时，修改 AutoTokenizer.from_pretrained 中的模型名称后，其 tokenizer 变成了 <class 'bool'>。
  • 另一位成员建议移除 use_fast=False 参数作为权宜之计，尽管该参数的具体作用尚不明确。
• DPO 争议：是 RL 还是不是 RL？：HuggingFace Discord 的成员讨论了 Direct Preference Optimization (DPO) 是否属于 RL 技术，因为一些论文声称它是，而原始论文则予以否认。
  • 一位成员调侃道：RL 创造了类似 DPO 数据集的谎言数据。
• ACE 框架赋能 Agent 消除错误：一位成员分享了他们对斯坦福 ACE 框架的开源实现，使 Agent 能够从错误中学习。
  • 该框架在反思后将策略整理成 playbook，并在浏览器自动化中显示出更高的成功率和步骤减少，作者正在寻求反馈。

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

FFMPEG radio station, Open source AI music models

• Vibe Coded FFMPEG 广播站上线：一位成员推出了一个 Vibe Coded FFMPEG 广播站，该 YouTube 直播中看到和听到的一切都是一个巨大的 FFMPEG 链。
• 广播站中的开源 AI 模型：该广播站的音频是完全在 DAW 中配合开源 AI 音乐模型协作完成的。

HuggingFace ▷ #computer-vision (1 messages):

Computer Vision API library, Robotics and automation models, Developer-facing API feedback

• 面向机器人的新 CV API 库正在酝酿：一家机器人初创公司正准备发布一个面向开发者的 Computer Vision API library，包含针对机器人和自动化的预训练及可微调模型。
  • 它包含的功能包括 6D object pose estimation、2D/3D object detection、instance & semantic segmentation、anomaly detection、point cloud processing、模型训练、微调端点以及部署就绪的推理 API。
• API 库寻求社区验证：主要目标是为 CV/robotics engineers 简化生产级感知流水线的原型设计和部署。
  • 该初创公司正在寻求社区反馈，以验证该库的实用性并在广泛发布前进行迭代，并为感兴趣的人提供早期访问权限。

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

Course Unit Updates, Model Evaluation, Unit Certifications, Final Project Clarification

• 新课程单元延迟了？：成员们注意到新课程单元已经几个月没有发布了，特别是注意到 evaluation 单元尚未上线，如此图所示。
• Unit 4 专注于模型评估：第四单元将涵盖 model evaluation，引发了关于课程截止日期变动的疑问，详见此处的讨论。
• 提前获得单元证书？：成员们确认，通过完成测验可以获得每个单元的 certificate of achievement，但课程尚未全部结束。
• 项目是 Unit 1 的结尾：发布了一张最终项目的截图（图片），确认这是 Unit 1 的最终项目。

HuggingFace ▷ #agents-course (3 messages):

AI Agents Course, Synthetic Data Unit, Order Following in AI Systems

• 合成数据单元备受期待：AI Agents Course 的一名新参与者询问了即将推出的 “synthetic data” 单元 的发布日期。
  • 参与者的热情突显了社区对利用合成数据进行 AI Agent 开发的兴趣。
• 关于指令遵循的询问：一张随附的图片引发了关于 AI 系统是否正确遵循特定 order（指令/顺序）的问题。
  • 图片附件表明了对系统是否遵守预定义指令或程序的关注。

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

def keyword status, var keyword status, parallelize function safety, MutOrigin.external vs MutAnyOrigin for ffi

• 延迟引入 def 关键字：成员们一致认为应暂缓引入 def 关键字，直到 Mojo 表现出更多类似 Python 的行为，并指出目前引入它会增加认知负担而无显著益处。
  • 讨论达成共识，可能会在以后重新引入 def，目前的观点认为其当前的实现感觉像是过度优化（premature optimization）。
• 关于 fn 内部使用 var 关键字的疑问：讨论集中在 fn 内部是否应强制要求使用 var，并提出了支持和反对强制使用的论据。
  • 支持者认为这能增强代码的清晰度和一致性；而反对者（尤其是具有 Python 背景的人）认为这降低了易用性（ergonomics）并增加了样板代码，破坏了代码重构的简洁性和便利性。
• parallelize 因数据竞争（Data Races）而不安全：一位用户报告了在使用 parallelize 函数时出现数据竞争，原本期望能像 Rust 那样出现编译时错误，但发现代码可以编译却产生了不一致的结果。
  • 一位核心团队成员澄清道，Mojo 的并发和线程安全模型仍在开发中（WIP），在跨设备共享数据的细节最终确定之前，parallelize 仍是不安全的。
• Mojo Python FFI 中的 MutOrigin.external 导致段错误（Segfaults）：一位用户在将 MutOrigin.external 作为 Mojo Python FFI 的返回类型时遇到了段错误（特别是与 av_packet_alloc 绑定时），并发现 MutAnyOrigin 可以作为临时解决方案。
  • 一位核心团队成员解释说，MutAnyOrigin 用于临时维持现有行为，并指出该问题可能涉及生命周期扩展（lifetime extension），建议如果 packet 需要 avcodec 保持存活，它应该持有来自 avcodec 的 origin。

Eleuther ▷ #general (10 messages🔥):

NUS PhD intro, AI + Web3 developer introduction, Getting Help Reading Research Papers, fast.ai as a beginner course

• 研究 Mech Interp 的 NUS 博士生加入！：来自新加坡的 Yiming 是一名 NUS（新加坡国立大学）的二年级博士生，研究方向为 mechanistic interpretability（机械可解释性）和医疗诊断模型可解释性，他在频道中介绍了自己。
• AI + Web3 开发者寻求合作：一位专注于 LLM development、RAG pipelines、autonomous agents 以及 Python/FastAPI 后端的 AI + Web3 开发者介绍了自己，并表示愿意在新的 AI 创意上进行合作。
• 新成员寻求阅读研究论文的指导：一位新成员询问如何获得阅读研究论文的帮助，另一位成员建议在 arXiv 上挑选一些论文并开始阅读。
• 向初学者推荐 fast.ai 课程：一位成员询问 fast.ai 课程是否适合初学者，另一位成员补充说唯一的先决条件是你懂得如何编程，并附上了 fast.ai 课程的链接。

Eleuther ▷ #research (3 messages):

Perplexity measurement, MMLU benchmark, topic datasets

• 评估特定领域主题的 Perplexity：一位成员正在探索不同模型在计算机科学、历史和商业伦理等特定领域主题上的 perplexity 测量。
  • 他们正在寻找除 MMLU（侧重于问答）之外的标准数据集，并已开始抓取 Wikipedia 页面，但也对已有的基准测试持开放态度。
• 对预训练数据集进行采样以进行主题分类：一位成员建议从预训练数据集中采样，并使用一个小模型对主题进行分类，这是一种快速简便的方法。
  • 这种方法可以实现在现有数据集中高效地进行主题识别。

Eleuther ▷ #scaling-laws (10 messages🔥):

Scaling Laws, Pretraining Dynamics, Decorrelated Performance, Nonlinear Metrics

• 深入探讨 Decorrelation Scaling Laws：讨论围绕 scaling laws 论文展开，争论其仅仅是曲线拟合，还是能够预测未来的扩展性能。
  • 对话转向导致 Power Law 出现的各种解释，例如 nonlinear metrics 解释。
• Muon Guy 写了那篇论文？！：一位成员分享了 openreview.net 的链接，并提到它是由 muon guy 编写的。
  • 分享了另一篇与 Scaling Laws 相关的论文链接：arxiv.org/2304.01910。
• 探讨 Scaling Laws 的直觉：一位参与者询问导致 Scaling Laws 的论文背后的直觉 (intuition)。
  • 另一位用户建议，在模型性能的极限下，任何测试样本的性能与其他样本的相关性会越来越低 (decorrelated)。
• Pretraining Power Law 动态：如果没有大量的 easy 样本层级，就会出现 Pretraining Power Law。
  • 在 Pretraining 中没有观察到突发的性能激增，因为与特定任务的训练相比，每个 batch 更加独立，共享的 easy 样本较少。

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

Manus Auth issues, Manus instability, Chat Mode adjustment, Gemini 3 Pro, AI-powered automation

• Manus Auth 问题尚未解决：用户报告了项目设置中 Manus Auth 被禁用以及通过 Manus 请求帮助后工单未解决的问题，项目 ID 为 dPK8UhWnJ9fTzjbpKfjJiF，域名为 auru.com.br。
  • 用户需要 Redirect URI https://auru.com.br/api/oauth/callback。
• Manus 的不稳定性引发挫败感：一位用户对 Manus 表示沮丧，理由是保存 checkpoint 之间代码被抹除、Git 差异以及尽管投入了数千美元构建 SaaS 平台但整体仍不稳定。
  • 他们表示：“Agents 在争论他们看到的东西，而你正盯着 PROD 环境。不要信任它。”
• Chat Mode 调整正在开发中：Manus 团队宣布，在考虑用户反馈后，Chat Mode 开关目前正在开发中，很快就会上线。
  • 许多用户请求 Chat Mode 尽快回归！
• 对 Gemini 3 Pro 模型的需求：一位用户询问 Manus 目前使用的是什么 AI 模型，并请求使用 Gemini 3 Pro。
  • 关于此问题未得到回复。
• AI 工程师专注于自动化和 Autonomous Agents：一些 AI 工程师介绍了自己：一位专注于使用 Python, SQL, JavaScript, PyTorch, scikit-learn, LightGBM, 和 LangChain 集成 AI 驱动的自动化和预测分析，以交付聊天机器人和推荐引擎。
  • 另一位专注于使用 JS/TS, Next.js / Vue, Go / Rust, Python, Langraph, AutoGen, ReAct, CrewAI, OpenAI, Claude, Hugging Face APIs 等各种技术栈构建 autonomous AI agents 和 multi-agent systems。

Yannick Kilcher ▷ #general (8 messages🔥):

Intern Recommendations, Learning Algorithms, Synthetic Data, Pug Resource, Docker and Kubernetes basics

• 寻找搞怪实习生推荐：一位成员征求“搞怪实习生”的推荐。
  • 目前尚不清楚他们是在招聘还是在找工作。
• 关于 Learning Algorithms 或 Synthetic Data 的经验：一位成员询问关于不同 learning algorithms 或 synthetic data 的经验。
  • 未记录到任何回复。
• Pug 的资源推荐：一位成员询问在哪里可以找到学习 Pug 的资源。
  • 未分享任何回复或资源。
• Docker 和 Kubernetes 基础：一位成员询问关于 Docker 和 Kubernetes 基础的资源。
  • 未分享任何回复或资源。

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

Kattention Module, TopKHot Autograd Function, HardTopKHotBCE Autograd Function

• Kattention 模块重新测试：Kattention 模块经过重新测试，发现其运行结果非常符合预期，利用了稀疏注意力（sparse attention）机制。
  • 代码包括用于注意力和投影的 nn.Linear 层，以及一个用于稀疏注意力的 TopKHot 函数，这对于扩展注意力机制至关重要。
• 探讨 TopKHot 梯度：实现了一个 TopKHot autograd 函数来选择 top-k 值，使用 torch.topk 和 scatter_ 进行梯度计算。
  • 反向传播（backward pass）根据 top-k 值的 softmax 权重计算 soft_target，梯度推导为 F.softmax(x, dim=-1) - soft_target。
• HardTopKHotBCE：BCE 近似：引入了一个 HardTopKHotBCE autograd 函数，其计算成本可能更低。
  • 反向传播使用基于 top-k 索引的 hard target，并计算梯度为 F.sigmoid(x) - hard_target，从而近似二元交叉熵（BCE）。

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

Mistral 3, Llama finetunes, wavefunction

• Mistral 3 发布了！：Mistral AI 发布了 Mistral 3。
  • 如果表现出色，它可能会在某些应用中取代 Llama 的微调版本。
• 波函数视频：一名成员分享了一个 波函数 YouTube 视频。
  • 目前尚不清楚视频的具体内容，但可能与 AI 相关。

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

justanotheratom: https://www.elicited.blog/posts/managing-tools-in-dspy

DSPy ▷ #general (4 messages):

Prompt Injection Defenses in DSPy, Security Measures, Training Dataset for Attack Mitigation, Partnership Proposal

• 寻求 DSPy 的提示注入防御方案：一名成员询问了 DSPy 中的提示注入（prompt injection）防御，鉴于 DSPy 的结构，寻求社区的最佳实践。
• 提示层的安全性有限：一名成员指出，在提示层（prompting layer）能获得的安全性并不多，并建议采用 guardrails 类型的安全措施、特定模型以及模型提供商的拒绝机制。
  • 他们还提到，对于提示词中每一个“不要这样做”的指令，攻击者很可能都会找到一种方法来欺骗模型。
• 利用训练数据缓解攻击：一名成员建议，为了防范基准攻击，应在训练数据集中包含使用该攻击的示例，并展示适当的响应应该是什么。
• 合作伙伴提案：一名成员表示有兴趣探讨与 DSPy 项目建立潜在合作伙伴关系。

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

Kernel Development Tools, Regression Test for Beam

• IDE 与终端编辑器之争开始：成员们开始讨论内核开发和迭代的首选工具，提出了开发者主要使用 VS Code 或 Cursor 等 GUI IDE，还是使用 Vim、Neovim 或 Emacs 等终端编辑器的问题。
  • 该讨论旨在深入了解社区在内核开发中的偏好和工作流程。
• Beam 回归测试需要修复：一名成员请求协助修复并为 python3.14 test/test_tiny.py TestTiny.test_beam 添加回归测试。
  • 这表明需要通过贡献来确保项目中 beam 功能的稳定性和正确性。