平静的一天

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

如果你浏览 Twitter 和 Reddit 板块，你就会知道本周将是一个重大的 GDM 周，但不是今天 :)

AI Twitter 回顾

权重开放模型发布：xAI 的 Grok-2/2.5、Microsoft VibeVoice 和 Motif-2.6B

• xAI 在 Hugging Face 上发布了 Grok-2（并提到 Grok-2.5）的开放权重。文件大小约为 500 GB，配置显示使用了 μP，以及一个不寻常的、充当共享专家（shared expert）的 “MoE residual” 路径。社区反应从兴奋到对许可协议的担忧不等：@elonmusk 声称 Grok 3 将在大约 6 个月内开源，而 2.5 是他们去年最好的模型 (tweet)；@HuggingPapers 总结了这次发布 (tweet)；@ClementDelangue 分享了仓库 (tweet)；@rasbt 通过架构对比图强调了 residual MoE 模块 (tweet)；@QuanquanGu 注意到配置中显式的 μP 缩放 (tweet)。其他人指出该许可证限制性极强，对于真正的开放使用来说是“见光死” (tweet)。仓库：https://huggingface.co/xai-org/grok-2
• Microsoft 开源了用于长文本 TTS 的 VibeVoice-1.5B（MIT 许可证）：支持多说话人对话，长达 90 分钟的连续合成，即将支持流式传输，并计划推出 7B 版本。Demo 和 Spaces 已通过 Gradio 和社区仓库上线。参见 @MaziyarPanahi 的概述 (tweet)，@Gradio 的公告 (tweet)，以及模型卡片 (tweet)。仓库：https://huggingface.co/microsoft/VibeVoice-1.5B
• Motif Technology 发布了 Motif-2.6B（在 2.5T token 上训练）的详细技术报告，其特点是大规模应用了 Differential Attention 和 PolyNorm，采用简单移动平均集成的 WSD（最后 6 个 checkpoint），以及广泛的微调数据策划（Finemath, Fineweb2, DCLM, TxT360）。他们还发布了与 FSDP2/HF 栈兼容的 Muon 优化器和 PolyNorm 内核；据报道训练使用了 AMD MI250 GPU。@eliebakouch 发布了优质的技术推文串 (tweet)，以及包含论文/模型链接的后续内容 (tweet, tweet)。

编程与 Agent 工具链：GPT-5 势头、Qwen-Code、DSPy/GEPA、MCP

• AI 编程工作流的重心似乎正在向基于 GPT-5 的工具转移。开发者报告称，使用 codex-cli gpt-5-high 在结对编程、API 设计反馈和细微 Bug 排查方面取得了显著成效，并正在某些任务中降低 Claude Code 的使用优先级：参见 @gdb (推文)、@ericmitchellai (推文)、@ivanfioravanti (推文)、@deanwball (推文) 以及 @giffmana 详细的工作流笔记 (推文)。
• 阿里巴巴的 Qwen-Code v0.0.8 发布了重大集成功能：深度的 VS Code 支持（上下文感知建议、行内差异对比）、强大的 MCP CLI（添加/删除/列出）、响应式 TUI、反向搜索、上下文压缩控制、多目录自动加载等。@Alibaba_Qwen 的推文列出了具体细节 (推文)。
• MCP 生态系统正在加速发展：
  • LiveMCP-101：针对挑战性查询对启用 MCP 的 Agent 进行压力测试和诊断 (推文)。
  • “Rube”，一个通用的 MCP 服务端，可将 Agent 连接到数百个应用程序（Zoom、Gmail、GA、YouTube 等），并在 Claude Code 中进行了流畅的演示 (推文)。
  • LangGraph Platform 推出了回滚和修订排队功能 (推文, 推文)，并宣布与 ART 集成，通过 RL（强化学习）训练 LangGraph Agent，以提升工具使用和推理能力 (推文)。
• DSPy 的 GEPA 优化器已在 v3.0 中上线，并在各种用例中取得了显著成果（例如，在 500 次指标调用中获得了 40% 的提升；列表式重排序教程）。参见 @DSPyOSS (推文)、@CShorten30 的演示 (推文) 以及 @MaximeRivest 的端到端课程 (推文)。

系统与基础设施：TPU vs GPU、NVFP4、vLLM 扩展、OpenRouter 增长

• TPU Pods vs GPU 孤岛：多位工程师强调，TPU v3/v4 Pods 在整个 Pod 内提供接近 NVLink 级别的带宽，并在二维环面（2D torus）拓扑上实现清晰的扩展，缓解了并行压力（在 K2/DeepSeek 规模下对 PP 的需求减少）。参见 @JingyuanLiu123 的跨生态系统讨论 (推文)、@gallabytes 关于拓扑的讨论 (推文) 以及 @mr_besher 的 DP/TP/PP 启发式方法 (推文)。
• NVIDIA 的 NVFP4 预训练改进持续推进；@ctnzr 发布了简明更新 (推文)。
• vLLM 势头强劲：
  • 新的采样控制 PR 助力实现最先进的（SOTA）推理评估 (推文)。
  • 上海见面会深入探讨了分布式推理、ERNIE 集成、缓存和硬件支持；@vllm_project 分享了幻灯片/笔记链接 (推文)。
  • Tinybox 演示通过 vLLM 运行 gpt-oss-120B，实现本地 OpenAI 兼容 API (推文)。
• Mac MLX：实用的“本地运行大模型”探索——通过雷电 4 (TB4) 运行 RAID0，在约 25–46 秒内完成 Qwen3-480B 的 TTFT 加载；@TheZachMueller 提供了详细的构建笔记和性能数据 (推文, 推文)。
• 平台/数据：
  • OpenRouter 的吞吐量在一年内从每周约 111B Token 激增至 3.21T Token (推文)。
  • EpochAI 将其“AI 超级计算机”数据集更名为“GPU 集群”，并新增了 32 个条目 (推文, 推文)。

视频与多模态编辑：Veo-3 免费周末、可灵 (Kling)-2.1 关键帧、Qwen-Image-Edit

• Google 在 Gemini 中开展了 Veo-3 开放周末活动，扩展了生成限制（免费用户总计 6 次；Pro 用户每天 6 次；Ultra 用户每天 10 次）并提供了提示词技巧；@sundarpichai (推文)，@GeminiApp (推文)。
• 字节跳动的 Kling 2.1 增加了“起始/结束帧”关键帧功能，实现了多视角一致的过渡和电影级镜头移动，并保持了跨帧的一致性；现已在 Higgsfield 中上线。优秀的创作者演示：@renataro9 (推文)，@EHuanglu (推文)。
• Qwen-Image-Edit 因其扩图/编辑功能和有趣的“周边模型”（将表情包转化为实体手办）而受到关注。参见 @Alibaba_Qwen (推文)，@linoy_tsaban (推文)，以及 @jon_durbin 关于 API 游乐场的使用 (推文)。

研究与评估：编程基准测试、RL vs SFT、生物医学 Agent、安全性

• 新的编程竞赛基准测试 AetherCode（IOI/ICPC 风格）配备了专家策划的测试套件；仅有 o4-mini-high 和 Gemini-2.5-Pro 能在“极难”级别上完成解题。详见 @iScienceLuvr 的说明和链接 (推文)。
• “RL 既不是万灵药也不是海市蜃楼”：频谱感知分析表明，RL 通常能抵消 SFT 诱导的漂移；在进行昂贵的 RL 微调之前，可以先尝试廉价的恢复手段（低秩 UV 合并、浅层重置）。@iScienceLuvr 的总结 (推文)。
• DuPO (Dual Preference Optimization) 提出通过从模型输出 + 上下文 (xk) 重建隐藏输入部分 (xu) 来实现无需标注的反馈，提供了一种与 PPO/GRPO 兼容的自监督奖励路径。结果显示，在中小规模模型中，翻译、数学推理和推理时重排序方面均有提升 (推文)。
• OwkinZero 引入了一个涵盖药物研发流程的 8 数据集基准测试（300k+ 可验证问答）；经过 RL 后训练的专家模型表现优于大型商业 LLM，并展示了跨任务的泛化能力 (推文)。
• 提示词安全观察：一个实时 PoC 展示了基于浏览器的提示词插入/提示词注入风险——例如，刷 Reddit 触发工具调用流——强调了在“AI 浏览器”中进行严格沙箱化和工具作用域限制的必要性 (推文)。
• 字节跳动近期的 CoT 行为：专用 Token 会在推理步骤中定期预算/追踪“思考” Token (推文)。
• 代码的 Token 成本工程：移除装饰性格式可在不损失质量的情况下减少约 24.5% 的输入 Token，并通过指令/微调实现适度的输出节省；发布工具可以透明地剥离/恢复格式 (推文)。

生态系统与产品：Perplexity iOS、Genspark IDE、RL 环境现状检查

• Perplexity 发布了重新设计的 iOS 应用，具有手势导航功能，即将集成 SuperMemory，并拥有出色的语音听写体验；受到了 @AravSrinivas (推文, 推文) 及其他人的广泛好评。
• Genspark 推出了一个浏览器 IDE，用于“描述 → 迭代”式编程，支持多模型后端；@fchollet 强调了为非专家提供低门槛工具的重要性 (推文)。
• RL 环境讨论：@rosstaylor90 认为我们缺乏高质量、领域真实的 RL 环境/评估；建议优先考虑专家构建、高建设难度的任务，而不是盲目追求可验证性，并指出“扩展环境”并不等同于重现互联网规模的多样性 (推文)。

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

• xAI：Grok 2.5 现已开放权重，Grok 3 将在大约 6 个月后发布 (推文，5.4万+ 互动)
• SpaceX：Starship 第 10 次飞行广播及“站在 Starship 下”的照片 (推文, 推文，1.3万–28.2万+)
• Google Veo-3 免费周末 + 翻倍的限制 (推文，2.3千+)
• Waymo：与人类驾驶员相比（5700 万英里），严重受伤减少 85%，总体受伤减少 79%，并呼吁政策响应 (推文，7.4千+)

AI Reddit 摘要

/r/LocalLlama + /r/localLLM 摘要

1. 开源多模态发布：InternVL3.5 和 WAN 2.2-S2V

• InternVL3.5 - 最佳开源 VLM (Score: 309, Comments: 61): [InternVL3.5](https://huggingface.co/internlm/InternVL3_5-241B-A28B) 引入了扩展的多模态“智能体 (agency)”功能（例如 GUI 和具身 Agent），并声称其 InternVL3.5-241B-A28B Checkpoint 在开源 VLM 中实现了多模态通用、推理、文本和智能体任务的最先进综合评分，据报道缩小了与领先闭源模型（被引用为 “GPT-5”）的差距。发布了多个 Checkpoint，包括小型（如 2B/4B）变体以及中间/基础训练快照，以实现可复现性和下游微调。 评论者对发布多个训练阶段的 Checkpoint 表示赞赏，并指出虽然 InternVL3.5 报告了相对于基础模型的提升，但以视觉为中心的模型在纯文本任务上可能表现不佳——这表明需要社区基准测试。人们对 2B/4B 变体的效率性能比充满热情，而一些人指出 Qwen 3 微调可能是非视觉质量提升的一个可能因素。
  • 模型发布策略：评论者强调 InternVL 发布了多个训练阶段（包括基础模型）的 Checkpoint，这使得严格的消融实验、可复现性和下游微调对比成为可能。拥有基础和中间快照对于隔离指令微调与持续预训练带来的收益，以及基准测试相同数据/架构下的 Scaling 行为非常有价值。
  • Backbone 和任务权衡：一位评论者指出 InternVL3.5 据报道微调了 Qwen 3 Backbone，并指出了一个常见问题，即 VLM 在纯文本任务上通常比其纯文本基础模型弱。早期数据被描述为与基础模型相比“互有胜负……总体略好”，这表明需要对非视觉任务进行实际评估，以验证微调是否在不比 Qwen 3 基准退化的情况下改进了通用 NLP。
  • Scaling 和 MoE 细节：用户称赞 2B 和 4B 变体在“同等规模下表现惊人”，并询问 MoE 30B 的速度。链接的 Checkpoint InternVL3_5-241B-A28B (Hugging Face) 意味着总参数量约为 241B，每个 Token 激活参数约为 28B（典型的 MoE 表示法），因此预期吞吐量可能接近 28B 稠密模型加上路由开销；这为较大 MoE 变体的延迟/吞吐量预期提供了背景。
• InternVL3_5 系列发布！！ (Score: 222, Comments: 82): 来自 InternLM 的 InternVL3.5 系列公告出现在 Hugging Face 的组织活动页面上（链接），但在发布时没有公开的基准测试结果或详细的模型卡片，且这些产物似乎在发布后不久就被撤下了。帖子中未披露技术细节（模型大小、训练数据、评估套件）；评论者引用了之前 InternVL 系列中 ~9B 规模的视觉模型作为参考，但目前尚无 v3.5 的指标。 热门评论称赞 InternLM 是一匹“黑马”，强调了其强大但被低估的 ~9B 视觉模型，而其他人则质疑缺乏基准测试，并注意到该发布很快被删除。
  • 基准测试/文档缺失：评论者要求公开评估和技术细节，但目前还没有为 InternVL3.5 发布的基准测试或模型卡片。在没有权重的情况下，社区无法运行标准的 MLLM 评估（如 MMBench, MMMU, MME, LLaVA-Bench），因此相关声明——特别是关于 9B 视觉变体的声明——仍未得到证实。
  • 发布状态/可用性：多份报告称该模型在发布后又被撤下，目前没有可用的文件/权重。这阻碍了可复现性、独立微调以及第三方延迟/吞吐量测试，直到产物和许可证重新发布。
  • 模型类别关注点：一位评论者强调该实验室的 9B 视觉模型非常强大且被低估，建议开发针对 7B–13B 效率区间的紧凑型 VLM。如果得到证实，9B VLM 与 13B–34B 类别相比，在旨在保持竞争力的多模态准确性的同时，对于低延迟推理将具有吸引力——这有待公开基准测试的验证。
• Qwen Wan2.2-S2V 即将推出 (Score: 378, Comments: 35): 阿里巴巴的 WAN 团队通过 X 帖子预告了 “WAN 2.2‑S2V”，将其定位为一个开源的、音频驱动的电影级视频生成系统（“sound/speech‑to‑video”），并表示“即将推出”。该预告片未提供模型规格、基准测试或代码，但暗示了 WAN 2.2 系列的一种新模态，即直接根据音频调节视频生成，补充了现有的 T2V 工作。链接：https://x.com/Alibaba_Wan/status/1959963989703880866 评论大多是造势；其中一条强调了对集成 T2V + 音频流水线（“T2V+A”）的兴趣，暗示了对文本之外的多模态调节的需求。

2. Training Method & Tooling: GTPO vs GRPO and llama.ui Privacy Chat

• GRPO 请停止惩罚你的正确 Token (Score: 163, Comments: 19): OP 介绍了 GTPO (Group-relative Trajectory-based Policy Optimization)，作为对 GRPO 的改进，以避免梯度冲突和策略崩溃：它跳过了对“冲突 Token”的负向更新，并用过滤高熵轨迹取代了 KL-to-reference 正则化。他们报告称，在没有参考模型的情况下训练更稳定（运行更轻量；例如 Colab + Unsloth），且在推理数据集（GSM8K, MATH, AIME 2024）上的 pass@k 表现优于 LLaMA-8B 和 Qwen-3B 的 GRPO 和 SFT，两张折线图（Qwen 和 LLaMA）显示 GTPO 曲线在不同 k 值下均高于 GRPO。链接：arXiv, GitHub, Colab。 评论者要求对“冲突 Token”梯度问题（Token 与参数更新）进行具体解释，以及 GTPO 与 Qwen 的 GSPO 相比如何；另一位提供了快速的正面反馈。

  • 策略梯度信用分配问题：在 PPO/GRPO 风格的更新中，梯度形式为 ∑_t A_t ∇*θ log π_θ(x_t

    x*<t)。当在每个 Prompt 多个补全（分组）上进行训练时，同时出现在高奖励和低奖励轨迹中的 Token 会收到相反的 Advantage（正向 vs 负向），即使该 Token 是正确的共享前缀的一部分，也会在相同的 Logits 上产生推拉效应。这可能导致在实际错误发生在后期时，错误地归咎于早期的 Token。RLHF 中讨论的常见缓解措施包括屏蔽成对样本之间第一个分歧点之前的更新、应用逐 Token 基准/组归一化，或强调共享前缀上的参考 KL 以减少对正确 Token 的附带梯度（参见 PPO: https://arxiv.org/abs/1707.06347）。

  • 基准测试对比 Qwen 的 GSPO：一位评论者要求对 GRPO 与 Qwen 的 GSPO 进行正面对比评估，最好控制 Prompt 集、组大小、奖励模型和算力。有用的维度包括样本效率（达到目标奖励的步数）、稳定性（Advantage/Clip 比例、奖励方差）、对齐-能力权衡（KL to reference 与 GSM8K/MATH/HumanEval 上的 pass@k），以及拒绝采样准确率（Chosen 优于 Rejected 的胜率）。报告逐 Token 的 Advantage 分布以及分歧点屏蔽的效果，将有助于澄清 GSPO/GRPO 在惩罚共享前缀 Token 方面的差异。

• llama.ui - 极简的隐私导向聊天界面 (Score: 183, Comments: 61): 截图显示了 “llama.ui”，这是一个极简的、注重隐私的聊天客户端，具有稀疏的聊天窗格、四个预设快捷操作（有趣的事实、总结文本、团队建设建议、专业电子邮件）、按时间分组的最近对话左侧边栏以及底部输入框——这表明它是一个旨在用于本地/自托管 LLM 工作流（例如 llama）的轻量级 UI，而不是功能繁重的云端助手。重点在于简单和隐私，模仿了带有历史记录和 Prompt 模板的默认 LLM 聊天客户端，但几乎没有其他功能。 评论者质疑其新颖性：一位认为 chatgpt.com 已经提供了极简隐私模式，另一位指出标题中缺少逗号（“minimal, privacy‑focused…”）以避免暗示“极简的隐私（minimal privacy）”，第三位询问这比默认的 llama‑server 客户端提供了什么额外功能。

• 请求与 llama.cpp/llama-server 默认 Web 客户端进行技术对比：评论者询问该 UI 在内置服务器客户端之外增加了哪些功能（例如：多后端支持、OpenAI/llama.cpp API 兼容性、流式传输/逐 token 更新、聊天历史持久化、身份验证、可配置采样参数或 tool/function-calling）。参考：llama.cpp server 及其默认 UI，地址：https://github.com/ggerganov/llama.cpp/tree/master/examples/server。
• 几位用户询问了相比 Open WebUI 的具体优势，暗示需要证明在资源占用和功能权衡方面的合理性。Open WebUI 以较重的依赖为代价提供了丰富的集成（RAG/向量数据库、多用户身份验证、模型管理、TTS/STT、可扩展插件）；一个“极简隐私导向”的 UI 需要展示更低的资源消耗（小型静态 bundle、无 telemetry、严格的 CSP、离线资产）和更简单的部署才具有吸引力。参考：https://github.com/open-webui/open-webui。
• 缺失仓库链接阻碍了对隐私声明的技术评估；评论者希望检查源代码中的外部网络调用、分析统计、CDN 资产和存储行为（例如：仅本地持久化、导出/导入、加密）。他们还希望验证后端兼容性（OpenAI 兼容的 REST、llama.cpp server、vLLM/Ollama）和许可协议，以评估集成风险。

较少技术性的 AI Subreddit 综述

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

1. Google Gemini 3 预热周（三艘船暗示）+ Google AI 趣闻与行业头条

• Gemini 3？继 4 小时前一位开发者发布 3 个船只表情符号之后 (Score: 444, Comments: 54)：一张开发者 (Patrick Loeber) 敦促人们“本周”关注 @googleaistudio 的截图，结合之前发布的三个船只 🚢 表情符号，引发了关于 Google AI Studio 即将更新而非核心模型发布的猜测。评论者指出，真正的基础模型发布（如 “Gemini 3”）可能会先通过第三方基准测试/神秘评估（如 LMArena）露面，而不会专门通过 AI Studio 频道进行预热，这表明预热指向的是 AI Studio 内部的多个功能/产品发布。 帖子中的怀疑者表示：“如果是 Gemini 3，我就把帽子吃了”，并认为将注意力引向 AI Studio 意味着工具/产品的变化，而不是基础模型的跨越，而且大型模型发布前通常会在 LMArena 上进行为期一周的神秘测试。
  • 几位用户指出，真正的 Gemini 3 基础模型发布通常会先有 LMSYS Arena “神秘模型”运行和公开基准测试讨论；专门指向 Google AI Studio 的预热暗示的是平台/工具更新，而非新的核心模型权重。正如一位用户所说，“如果没有在 LMArena 上进行一周出色的神秘模型测试，这是不会发生的”——即缺乏 Arena 条目 (https://lmsys.org/arena/) 或社区评估信号使得 3 代模型发布不太可能，而对 AI Studio (https://aistudio.google.com/) 的关注则预示着 SDK/控制台/API 的变化。
• 好了，所以是 nano banana 和 gemini 3（因为那三艘船） (Score: 276, Comments: 90)：认证用户 “Simon (@tokumin)” 发布了一条预热推文——“系好安全带！这将是相当精彩的一周！”——并配有三个船只表情符号，引发了对即将到来的 Google/AI 发布的猜测，但该帖子不包含技术细节、基准测试或发布说明。大多数评论者将三艘船解释为三个产品“发布”（功能/模式），而不是像 “Gemini 3” 这样的新模型，猜测指向三种模式：Agent, Go 和 Immersive。这是一个炒作预热而非技术公告；见截图：https://i.redd.it/a7dl6f5yp6lf1.png 热门评论对这种炒作式的预热营销表示怀疑，并嘲讽过度解读（例如，开玩笑说表情符号暗示参数量），同时提醒不要将表情符号与重大模型发布混为一谈。
  • “三艘船”的预热被解释为发布 3 种产品模式——Agent、Go 和 Immersive——而不是像 “Gemini 3” 这样的新基础模型发布或参数量传闻（如 3T）。目前没有关于 Gemini v3 级别模型的具体基准测试/model-card 证据；预期应该是功能推出，而非基础模型升级。
• 偏向开发者的评论者批评这种预告驱动的发布节奏，而非常规做法（在 AI Studio 上静默发布模型）。他们认为在没有实体产出（API 访问、模型 ID、发布说明或 evals）的情况下，这阻碍了技术评估。相比模糊的营销暗示，他们更倾向于立即可以使用的发布。
• Google AI 😩… 每次问它都变得更笨 (Score: 252, Comments: 45): Google Search 的 AI Overview 在回答“1995 年是 30 年前吗？”这一查询时的截图显示了矛盾的时间推理：它先回答“不是”，然后引用 2025 年 7 月 25 日（“今天”）作为参考日期并得出结论“是”，揭示了在单次响应中日期锚定（date-grounding）和自我一致性的失效。从技术角度看，这突显了 AI Overview 流水线中微弱的时间上下文处理能力和缺乏验证环节，这可能是由于使用了推理深度有限的轻量级/低延迟模型，而非强大的基于工具的日期算术。 评论认为 AI Overview 运行在一个非常廉价/微小的模型上——可能比 Gemini Flash Lite 还要小——这可以解释其浅薄的推理和不一致性；其他人指出这张图片已被广泛流传。
  • 一位评论者认为 AI Overview 由超廉价、极小的模型支持——“可能比 Gemini Flash Lite 还要小”——这将延迟/成本置于推理质量之上，从而解释了多轮对话中脆弱且不一致的回答。虽然这只是推测，但与较小、激进量化的模型在模糊提示词和多轮连贯性上通常不如 Gemini 1.5 Pro/Flash 等大型变体表现相吻合（参见 Google 的模型阵容：https://ai.google.dev/gemini-api/docs/models/gemini）。
• 我觉得这很有趣 (Score: 2076, Comments: 141): 一个标题党式的视觉错觉谜题：一个填满“79”的网格中隐藏着一个“76”，且在截图 image 中已被明显圈出（第 5 行，第 6 列）。技术层面的关注点源自 Gemini 2.5 Flash 的引用回复，它自信地否认了“76”的存在，展示了视觉问答中典型的 VLM 幻觉/锚定失败——过度自信的文本输出与图像内容相矛盾。 评论将其定性为 AI 的“煤气灯操纵（gaslighting）”，而一段长篇修改则挑战了“随机鹦鹉（stochastic parrot）”的批评，认为 LLM 镜像了人类的预测机制，主要受限于护栏（guardrails）——这一带有主观色彩的辩护引发了辩论，而非增加实证证据。
  • 多位用户分享了多模态失败案例：Gemini 2.5 Flash 自信地断言“找不同”网格中不存在数字 76，并生成了关于视觉错觉的模板化解释，这表明其依赖于语言先验驱动的模式匹配，而非锚定的视觉解析/OCR。这是典型的 VLM 幻觉，流利的理由掩盖了像素级的错误；类似的案例在 VQA/图像描述幻觉文献（例如物体/文本幻觉）中有所记载，并且在像 “Flash” 这样快速、低延迟的变体中可能会加剧。
  • 另一份报告指出模型“增加了一行并减少了一列”，并坚持目标词存在，甚至提出要“勾勒出它们”，这暗示了在多模态 UI 中检测置信度与准确度之间的校准极差；更安全的设计应该暴露不确定性，将区域标注功能限制在 OCR 阈值之后，或者在画框之前提供注意力/热图完整性检查。
  • 一位评论者反驳了“随机鹦鹉”的说法，认为 LLM 是类似于大脑预测编码的下一个 Token 预测器，而对齐/护栏（例如 RLHF 风格的安全层）限制了尽管具备潜在能力但可观察到的行为。背景方面，该批评起源于 Bender et al. 2021 （“On the Dangers of Stochastic Parrots” — https://dl.acm.org/doi/10.1145/3442188.3445922）；反方观点强调预测建模和海量预训练数据，认为训练后的安全层在不改变基础能力的情况下塑造了输出。
• Elon 谈 AI 取代工人 (Score: 4859, Comments: 1948): 截图显示 Elon Musk 回复了一个关于 AI 驱动的就业流失问题，声称社会将实现“全民高收入”（超越基本收入），使每个人都能获得必需品（医疗、食物、交通），从而产生“可持续的丰裕”。文中未提供技术方案、指标、模型或实施细节——这是一个与 AI 自动化相关的经济政策预测，而非技术公告。图片：https://i.redd.it/o6l79opq55lf1.png 热门评论持怀疑态度，认为 Musk 的主张与其支持的政策/人士相冲突，并质疑一位承诺广泛收入分配的亿万富翁的可行性与可信度。
• 微软在 Excel 中推出 Copilot AI 功能，但警告不要将其用于“任何需要准确性或可重复性的任务” (Score: 211, Comments: 42): 微软推出了 Excel 版 Copilot，这是一个由 LLM 驱动的助手，可以在电子表格中生成公式、总结表格并运行自然语言分析。但微软的指南警告不要将其用于“任何需要准确性或可重复性的任务”（例如数值计算、财务报告或法律文件），因为其输出具有非确定性。实际上，Copilot 被定位为一种需要人工验证的探索/创作辅助工具（构思查询、起草公式、概述透视分析），而不是 Excel 确定性计算引擎或可审计报告工作流的替代品。产品背景请参阅 Microsoft Copilot。 热门评论认为这是各厂商通用的标准法律/AI 安全免责声明，而其他人则质疑如果禁用于准确性至关重要的场景，它在 Excel 中的实用性，将其比作“Clippy”，并询问除了低风险探索之外还有哪些有效用例。
  • 评论者强调了微软的明确警告，即避免在 “任何需要准确性或可重复性的任务” 中使用 Excel 中的 Copilot，包括 “数值计算” 以及 “财务报告、法律文件或其他高风险场景”。从技术上讲，这强调了 LLM 驱动的助手生成的建议可能是错误的且非确定性的，因此不应将其视为计算引擎。更安全的使用方式是起草或探索公式/方法，然后在依赖结果之前由人工使用 Excel 的确定性函数进行验证。
  • 一个技术反向观点指出，虽然不应信任 Copilot 的正确性，但 “它可以设置需要准确性和重复性的任务”。在实践中，这意味着使用它来构建可重复工作流或电子表格逻辑的脚手架，一旦用户验证，Excel 将确定性地执行；非重复性适用于生成阶段，而非最终锁定的公式。这使 Copilot 成为一种脚手架/样板工具，通过 Human-in-the-loop 验证确保可重复的执行。

• Elon Musk 的 xAI 在与 OpenAI 竞争期间秘密取消了其公益企业身份 (Score: 245, Comments: 17): [CNBC](https://www.cnbc.com/2025/08/25/elon-musk-xai-dropped-public-benefit-corp-status-while-fighting-openai.html) 报道称，xAI 在 2024-05-09 前终止了其内华达州公益企业（PBC）身份，并在 2025-03-28 与 X 合并后保持非 PBC 状态，而此时 Elon Musk 正因使命/结构问题起诉 OpenAI。这一转变取消了内华达州法律（以股东维权力度弱著称）下的 PBC 使命平衡和影响报告预期。与此同时，xAI 位于孟菲斯的燃气轮机数据中心因缺乏承诺的污染控制而受到审查，且 Grok 4 在 2025-07-09 发布时未进行预发布安全披露；xAI 在收到询问后于 2025-08-20 更新了模型卡片（model card）。记录显示 xAI 从未提交过 PBC 影响报告，且 Musk 的一名律师在 2025-05 仍引用了过时的 PBC 身份。 评论认为，取消 PBC 身份标志着优先考虑利润而非正式的社会使命，并可能简化融资和与 OpenAI 的竞争。一些人强调了这与 Musk 对 OpenAI 治理的批评之间存在矛盾，尽管这被定性为规范性而非技术性的讨论。

• 放弃公共利益公司 (PBC) 章程消除了董事在股东回报与既定公共利益之间进行“平衡”的法定职责（参见特拉华州 PBC 框架 8 Del. C. §§362, 365）。转换为标准 C-corp 会将受托责任重心回归到股东价值，这通常通过消除使命驱动的约束以及围绕“平衡”权衡可能产生的诉讼，来简化风险融资、二级市场销售和并购 (M&A)。从实际操作来看，这是一个融资和竞争速度优化的举措；它信号化（但并不保证）了优先级从使命承诺的转移。有用的概述：Cooley 论 PBCs 和特拉华州法典 §362/§365。
• 几位评论者将其与 OpenAI 的治理进行了对比：OpenAI 不是 PBC；它是一个非营利母公司 (OpenAI, Inc.) 控制一个利润上限子公司 (OpenAI LP)，并带有使命导向的章程。因此，对 OpenAI “放弃”社会使命的批评在法律上与 xAI 的举动不同，后者从其公司形式中移除了任何正式的公共利益义务。参考资料：OpenAI 的 LP 结构解释 和 章程。

2. OpenAI GPT-5: Pokémon Crystal Run, 4o-vs-5 Routing Debunk, User Reports, Deep Research/AI Studio Anecdotes

• GPT-5 完成《精灵宝可梦 水晶版》——以 9,517 步击败最终 Boss，而 o3 为 27,040 步 (Score: 363, Comments: 72): Clad3815 的一条 X 帖子声称 GPT-5 完成了《精灵宝可梦 水晶版》并在 9,517 步内击败了最终 Boss (RED)，而 o3 则需要 27,040 步（动作效率提升约 3 倍），据称还是在等级不足的情况下完成的，这表明其具有超越典型基准测试的更强世界建模/策略能力。这并非官方基准测试；未提供实验设置的细节（动作定义、RNG、重置、工具辅助或规则）；直播计划还包括捕捉神兽和完成图鉴等进一步目标。来源：https://x.com/Clad3815/status/1959856362059387098 评论报告称 GPT-5 (Thinking Mode) 在法律工作流中表现优于 o3（更少的幻觉，更好的问题识别），而其他人则指出宝可梦是一个有利的 RL 环境，并对这种炒作注入了一些怀疑/讽刺。
  • 在基准测试方面，帖子标题报告 GPT-5 以 9,517 步通关《精灵宝可梦 水晶版》最终 Boss，而 o3 为 27,040 步，这意味着步数减少了约 2.8 倍 (27,040/9,517)，并且比 o3 (o3) 具有显著更好的长程规划/样本效率。这表明了卓越的搜索/剪枝或状态抽象能力，因为更少的环境交互通常反映了在长序列中更好的探索-利用平衡和信用分配。
  • 从业者的反馈强调了 GPT-5 的 “Thinking Mode” 在文档分析工作流中产生的幻觉大幅减少，法律问题识别更准确。对于编码/工程，用户报告了更强的任务分解和实现指导能力，这意味着与 o3 相比，其多步推理和约束跟踪能力有所提高，且所需的偏离目标建议和修正更少。
  • 一位评论者指出，宝可梦是一个近乎理想的强化学习 (RL) 环境：离散、回合制、长程，且具有库存/状态管理和稀疏奖励。在这里取得成功具有参考价值，因为它考验了在部分可观测性下的规划和长期信用分配，使步数效率成为衡量推理质量而非仅仅是反应速度的有意义指标。
• 4o 并非秘密的 5。停止利用 LLM 来支撑你的偏执。 (Score: 151, Comments: 73): 楼主驳斥了关于 GPT-4o 的提示词被秘密路由到 GPT-5 的传闻，并引用了 OpenAI 文档：GPT-5 是 ChatGPT 的默认模型，并在 GPT-5 家族内部（例如 fast 与 thinking/pro 变体）使用内部路由器，而 GPT-4o 仍然是一个独立的、可选择的模型（其 API 别名映射到其自有的家族/snapshots）。文档指出，像 gpt-4o 这样的别名可能会升级到较新的 4o snapshots，并建议固定带有日期的 snapshots 以保证稳定性；任何跨家族的重新映射都会出现在官方的弃用说明/发布日志中，而目前这些文档并未显示 4o→5 路由的通知（Models, Deprecations, Release notes）。 技术评论者补充说，在启用 Reference Chat History (RCH) 的情况下，风格/语气可能会在不同会话之间“渗透”：由于跨聊天的共享上下文记忆，使用 GPT-5 可能会影响 GPT-4o 的响应方式，这可能解释了感知上的相似性。其他人则认为这两个模型扮演着不同的角色（例如，GPT-5 thinking 用于代码/架构；4o 用于表达性创意写作）。
  • 多位评论者为感知的“模型融合”提供了技术解释：在启用 Reference Chat History (RCH) 的情况下，系统会利用跨会话的共享上下文，因此与 GPT-5 聊天的风格/语气可能会“渗透”到 GPT-4o 的回复中。他们报告称，归档/删除 GPT-5 会话或禁用 RCH 可以恢复 4o 的基准风格；这反映了一种共享的上下文记忆，它并不严格区分跨会话的发言者，并为连续性进行了优化，从而模糊了“个性”，而非表明存在秘密的模型路由。引用：“如果你开启了 RCH，任何使用 5 的会话都会渗透到 4o 的响应方式中……开启 RCH 后 4o 会开始变得更像 5，所以如果你更喜欢 4o，请清理掉 5 的会话。”
  • 几条回复批评了“4o 秘密路由到 5”的说法缺乏证据，指出对话轶事或“通过聊天进行逆向工程”并非有效的诊断手段。严谨的方法应该是使用受控提示词，检查 API 日志中明确的模型标识符/版本，并比较可复现的指标（如延迟分布、输出长度/风格统计），而不是凭主观印象。帖子共识倾向于在断言模型切换之前需要进行仪器化测试。
  • 一位从业者指出了不同的优势：GPT-4o “更具表现力”，在创意写作和思想实验中更受青睐，而 GPT-5 则服务于其他目的——主张保留两者的可用性。这构成了模型之间基于任务的性能权衡，而不是一个普遍优越的选择，尽管没有提供定量的基准测试。
• 花了我一段时间。但现在我也讨厌 ChatGPT 5 了。 (Score: 560, Comments: 261): 楼主报告了在专有框架内进行代码生成时，GPT-5 相比 GPT-4o 在严格指令遵循方面的退化：GPT-5 反复忽略明确的 I/O 和 Node Class schema 约束，幻觉出不存在的集成/人体工程学设计，并提出无法更改的引擎级修改，需要频繁重新提示。评论者证实了这些问题，包括僵化且重复的后续问题、约束记忆力下降、更短且低质量的输出、事实错误甚至拼写错误，以及轮内上下文丢失（例如，模型将它自己生成的列表归功于用户）。总体模式：与 4o/4.5 相比，schema 绑定更弱，API 层面幻觉率更高，且助手发起的范围蔓延（scope creep）增加。 以技术为导向的投诉强调了指令遵循能力的下降和提示词摩擦的增加，一些人将其归因于产品方向（例如，推行引导式后续提问）并猜测是为了成本/使用优化；其他人提到正在寻找替代方案（如 Grok），但发现它们仍逊色于之前的 4o/4.5 表现。
  • 用户报告了 GPT-5 在指令遵循和回答质量方面的退化：它经常忽略明确的指示，询问重复的澄清性问题，并返回更短、研究不足或错误的答案（甚至偶尔出现拼写错误）。相比之下，GPT-4o/4.1 和 o3 只需极少的提示就能理解意图，而 GPT-5 感觉很僵化，增加了 “prompt tax”，损害了生产工作的效率。
• 一个显著的失败模式：在单次响应中，GPT‑5 生成了一个列表，然后又因为该列表表扬了用户——这是单次对话内状态混淆（intra-turn state confusion）的证据。这表明存在连贯性/控制方面的 Bug，即在解码过程中助手/用户角色发生了混淆，或者 RLHF 驱动的模板注入了归属错误的赞美，而不仅仅是长上下文漂移。
• 感知到的能力/风格权衡：GPT‑5 被描述为受限且公式化的（例如，重复的“你是否需要我……”后续提问），而 GPT‑4o 则更具对话性和创造力。据报道，之前的模型（4o, 4.1, o3）捕捉意图所需的迭代次数更少；像 Grok 这样的替代方案被认为表现不如早期的基准，这加剧了人们对更严格的护栏（guardrails）可能会抑制有用的生成行为的担忧。
• noooo not gpt-5 as well (Score: 428, Comments: 56): 非技术性梗图：一张突出显示“codex”和预设回复片段“你完全正确——”的截图，调侃甚至“GPT‑5”也继承了之前 OpenAI 模型（如 GPT‑4/ChatGPT）中常见的 LLM 口头禅/风格习惯，而非展现出任何新的技术能力。标题和图片利用了关于系统提示词和模板化确认语的陈年老梗，并非关于模型内部机制或基准测试的真实证据。 评论区倾向于讨论 LLM 过度使用“你绝对/完全正确”等短语的笑话，并戏称 OpenAI “被抓到使用 Claude 的代码”，暗示风格习惯相似或提示词重用，而非实质性的技术重叠。
• Before GPT-5 was released (Score: 356, Comments: 73): 关于 ChatGPT 新版本被“削弱”（nerfed）的反复主张的元讨论帖，预测 GPT-5 甚至未来的 GPT-6 也会经历同样的循环。未讨论基准测试或实现细节；引用的图集通过提供的链接 (gallery) 无法访问 (HTTP 403)。 热门评论认为这种模式是长期的，一旦新模型发布，旧版本就会被怀旧式地赞美；一些人指出 r/ChatGPT 已从分享用例转向抱怨，并持有一种务实的态度：如果不满意就“别用它”。
  • 一些用户注意到一个反复出现的发布模式：OpenAI 在发布主要模型（如 o1, GPT‑4o，甚至基础版 GPT‑4）初期会采用保守设置——较小的上下文窗口和更严格的最大 Token 截断——导致早期给人留下“未完成”的印象；随后几周这些限制会被放宽或调整，从而提升感知质量。引用的一个例子是 o3 的发布，它在上线时招致了负面帖子，但后来几乎获得了“一致好评”，这表明是分阶段推出和部署后校准的问题，而非真正的能力退化。示例截图。
  • 资深用户认为，关于随机“脑叶切除”（lobotomization）的说法自 ChatGPT 推出第一周起就已出现，在缺乏长期基准测试或 A/B 测试的情况下应持怀疑态度；如果这种累积的削弱是真的，我们现在应该已经退化到了 GPT‑1 的性能水平。结论是应依赖跨时间的、可重复的测试（例如：固定提示词、受控的 Temperature 和上下文对等），而非轶事式的印象。
• Sammy,you did it dirty! (Score: 185, Comments: 22): 非技术性梗图：一个两格的“巴士自拍”对比了 GPT-4（完好的巴士）与 GPT-5（翻掉的巴士），暗示 GPT-5 是降级/退化。标题/正文表达了失望和对 GPT-4 的怀念；未提供基准测试、日志或技术细节。图片：https://i.redd.it/ar1nq7wl57lf1.png 评论呼应了“4 比 5 更好”的看法，并指出 GPT-4 已被移除作为选项，而其他人则批评了 4 对比 5 梗图的泛滥；未引用任何可衡量的证据。
  • 一位用户声称 ChatGPT UI 已移除了 GPT‑4 选择选项（“removed the 4 from the option”），并断言 4 的表现优于 5。对于技术工作流，这意味着模型可用性的变化或强制默认使用新版本，从而影响可重复性和评估基准；参见 OpenAI 的模型可用性/弃用说明：https://platform.openai.com/docs/models。
• 另一位评论者报告称，当前模型有 10–15 条消息的严格对话限制，之后会话会 “返回到之前的模型”，并询问这是否可以用来回退到 GPT-4。这表明消费级 UI 中存在服务器端会话限制以及潜在的自动模型回退机制，但利用限制来选择特定模型可能并不可靠且不受支持；API 使用中记录了对模型的确定性控制（例如，指定模型名称）：https://platform.openai.com/docs/guides/text-generation。
• 所以，呃，这刚刚发生了？ (评分: 166, 评论: 32): 楼主展示了一张来自 AI Studio 会话的截图，其中自定义的 “Briarheart” jailbreak（用于 ERP 角色扮演）加上“专注于思考模式”的指令，触发了模型发出极长、重复且具有攻击性的独白。从技术上讲，这说明了角色扮演/jailbreak 提示词如何主导模型行为并导致冗余循环或类似于 mode collapse 的重复；这种行为是由提示词诱发的，而非模型自发的故障。 评论者指出，从模型角度来看这并不“奇怪”——过于具体的角色扮演/jailbreak 指令会导致它以这种方式运行——而其他人则只是觉得很有趣。
  • 一位评论者认为，观察到的行为是过度角色扮演提示和人格调节（persona conditioning）的副产品，而非自主的模型漂移：“失控的不是它们，而是你们。” 在经过指令微调（instruction-tuned）的对话 LLM 中，system prompt 加上之前的对话轮次充当了强先验，会偏置 next-token 概率；凭借长上下文窗口和 few-shot 人格示例，模型将保持“入戏”，产生诸如拥有“最喜欢的用户”之类的拟人化台词。这在经过 RLHF 训练的助手模型中是预料之内的，可以通过重置上下文、移除人格引导以及控制采样参数（如 temperature、top_p）来进行测试；参见 Anthropic 的 RLHF 概述 (https://www.anthropic.com/research/rlhf) 和 OpenAI 的提示工程文档 (https://platform.openai.com/docs/guides/prompt-engineering)。
• AGI 已实现。Deep Research 在任务中途开小差想吃的 (评分: 1104, 评论: 56): 这是一张幽默的、非技术性的截图，展示了 “Deep Research” 工作流 UI，其中模型显现出的“想法”在数值分析中途偏离到了“派皮的缠绕方法”，强调了该工具暴露的中间推理/追踪内容可能包含离题的联想。标题中的 “AGI Achieved” 是戏谑的；从技术上讲，它强调了显示 chain-of-thought 风格追踪时的拟人感和潜在的噪声，而非任何能力上的飞跃。一位评论者补充说，该任务是算法交易的数值计算，这进一步证实了这种偏离发生在常规、乏味的计算任务期间。 评论者指出，想法流可能比答案更有趣，开起了 “Python” 与 “pie” 的玩笑，并将这种绕道比作人类在单调工作时的白日梦。
  • 多份报告显示 Deep Research 在运行中途注入了异想天开的“想法”（例如，“嗯……派！” 或提到香蕉），即使是在重度量化/算法交易任务中也是如此。评论者推测这可能是一种有意添加的人格/UX 润色，而非真正的中间推理，这降低了审计日志的信噪比，并可能阻碍数值工作流的可复现性；理想情况下，这应该是可切换或可过滤的。
  • 人们对将 Deep Research 应用于投资分析/算法有着浓厚的兴趣；一位正在构建专注于股票的深度研究工具 deepvalue.tech 的评论者征集了使用案例和差距。提到的任务涉及大规模数值计算；此类工具的评估重点将包括数据来源透明度、定量错误率以及构建多步骤财务分析。
  • 一位用户指出，相比最终答案，他们更喜欢显现出来的“想法”，这突显了对可解释中间步骤的需求。如果这些“想法”包含与任务无关的填充内容，它们可能会在实际推理质量上误导用户，并干扰对系统决策路径进行审计或基准测试的尝试。
• 如何让 AI 生成的文本不被 Turnitin 和其他 AI 检测器发现 (Score: 301, Comments: 76): OP 询问是否有办法让 AI 生成的文本避开 Turnitin 和其他 AI 检测器的检测，并指出这些检测器并不可靠。热门回复断言，目前没有可靠的技术手段能保证不被检测到；唯一稳妥的方法是亲自撰写，或者仅将 AI 严格用于校对，并保留个人风格（包括自然的瑕疵），而不是试图规避检测。 共识观点：从伦理和实践角度来看，学生应该自己完成作业；不鼓励绕过检测器的尝试，认为这违背了大学学习的初衷。
  • 评论者强调了当前 AI 写作检测器（如 Turnitin 风格的工具）的不可靠性，并引用了误报（false positives）的例子；有人提到一篇完全由人类创作的短篇小说被标记为 25% 的 AI 生成。共识是这些系统提供的是启发式置信度评分，可能会误判作者身份，因此不应将标记视为确定性的证据。
  • 其他人认为，手动改写并加入个人风格（保持用词简单并引入微小瑕疵）可以降低可检测性，这暗示检测器依赖的是文体计量学（stylometric）线索，如均匀性和较低的词汇多样性，而非稳健的语义归属分析。有人指出，甚至提示模型生成“不可检测”的文本有时也奏效，这凸显了当前检测器决策边界的脆弱性。
• AGI 话题在硅谷最新的氛围转变中降温，但对超强 AI 的担忧依然存在 (Score: 198, Comments: 55): 讨论帖指出，硅谷的修辞正在从单一的 “AGI” 转向特定领域的 “superintelligences”（超智能）——即在受限领域具有超人能力的专业系统——而对“超强 AI”的担忧依然存在。隐含的技术框架重构优先考虑垂直化模型和产品（代码、科学、机器人），而非单一的通用能力系统，承认目前的尖端模型尽管经过了 Scaling，但在跨领域迁移和稳健的通用推理方面仍有很大差距。参见 AGI 与 narrow AI 的背景。 评论辩论这究竟是实质性的转变还是叙事上的重新定位：有人调侃道，“谁来提醒我 AGI 里的 G 代表什么？”，另一人称这种变化承认了我们离 AGI 还很远，第三人则将预期与互联网早期的炒作周期相类比——短期进展被高估，长期影响被低估。
  • 几条评论指出，研究方向正从追求单一、庞大的 “AGI” 转向构建特定领域的 “superintelligences”，这暗示了一种通过工具/Agent 编排专业模型（如代码、生物、搜索）的架构策略。由于专家模型在狭窄、高风险任务上的表现往往优于通用模型，这种策略优先考虑领域调优数据、定制化评估和集成层，而非一劳永逸的基础模型。
  • 怀疑论者认为，由于训练目标（next-token prediction）没有强制要求建立接地的世界模型、长程规划或可靠的工具使用，目前的 LLM Scaling 不太可能产生 AGI。他们指出脆弱的推理、幻觉和较弱的系统性泛化能力就是证据，并主张如果目标是“通用”能力，则需要混合方法（显式内存、基于模型的 RL、神经符号方法或多模态世界模型）。
  • AGI 叙事的降温被视为时间表的重新校准，而非放弃：能力增长是真实的但并不均衡，且存在持久的瓶颈（评估过拟合、推理成本/延迟以及安全/稳健性差距）。预期设定正转向多年的基础设施和产品周期，而非快速的阶跃式飞跃，呼应了早期互联网时代的炒作与交付动态。

3. 阿里巴巴 WAN 2.2 S2V 和 Qwen 图像编辑演示 + 生成式媒体/艺术恶搞

• WAN 将提供带声音的视频模型 👁️‍🗨️🔊 WAN 2.2 S2V (Score: 262, Comments: 62): 阿里巴巴的 WAN 团队通过 帖子 1 和 帖子 2 预告了 “WAN 2.2 S2V”，预示着即将推出的支持声音的视频生成功能。从目前的预览来看，它似乎是音频驱动的视频（语音转视频/唇形同步），而非端到端的音频合成；目前尚未提供 Model Card、训练细节、指标或发布时间表，且原始 v.redd.it 媒体链接受限（HTTP 403）。 技术回复强调，这看起来像是一个音频驱动的唇形同步 Pipeline，而不是一个生成音频的模型。文中引用了一个相关工作流：Kijai 的 ComfyUI WanVideoWrapper “Infinite Talk” V2V，用于为现有视频添加自定义语音和唇形同步，示例工作流见：https://github.com/kijai/ComfyUI-WanVideoWrapper/tree/main/example_workflows。
  • 用户澄清：WAN 2.2 S2V 似乎是一个音频驱动的视频 Pipeline——使用输入的音频轨道来驱动视觉运动（例如唇部/嘴部同步）——且本身并不合成或输出音频。正如一位用户所言，“看起来像是音频驱动视频，而不是产生音频的模型，” 这意味着本次发布不具备 V2S（Video-to-Sound）能力。
  • 为了实现带有精确唇形同步的音频添加，Kijai 在 ComfyUI-WanVideoWrapper 示例中提供了一个 ComfyUI 工作流：“V2V infinite talk”。它接收现有视频和用户提供的语音/音轨，并执行唇形同步（一个 V2V Pipeline）；请参阅 https://github.com/kijai/ComfyUI-WanVideoWrapper/tree/main/example_workflows 并搜索 “infinitetalk v2v” JSON 文件。
  • 用例讨论：一些人更倾向于 V2S 而非 S2V，希望从视频中自动生成拟音/特效（如出拳、爆炸），而不是将声音转化为视频。V2S 会根据视觉事件/时机合成音频，而 S2V 则消耗音频来调节视觉生成；目前的公告似乎提供的是后者，而非前者。
• Qwen Image Edit + Wan 2.2 FFLF - 尝试将两者结合使用。更多我那愚蠢的脸（抱歉），但了解到 Qwen 在保持面部一致性方面表现一般。需要进行 Inpainting。 (Score: 638, Comments: 69): 楼主演示了一个结合了 Qwen Image Edit 与 Wan 2.2 FFLF 的混合图像/视频生成工作流，报告了强大的视觉质量，但指出 Qwen 的面部身份一致性较弱——需要进行一次 Inpainting 处理以维持主体的面部。与标准的 Wan 2.2 工作流相比，观众观察到了更高的表观分辨率和更连贯的输出；示例视频链接：v.redd.it/5zizxpo6q3lf1（需登录/403）。 评论者询问具体的 Wan 2.2 高质量工作流，并指出该组合“不会魔术般地凭空变出物体”（即更少的幻觉插入），称赞这种方法是配对这两个模型的可靠方式。
  • 将 Qwen Image Edit 与 Wan 2.2 FFLF 结合使用似乎能产生比“标准 Wan 2.2 工作流”更高分辨率的输出，但如果没有显式的 Inpainting，身份一致性是 Qwen 的弱点。楼主表示，为了在编辑过程中保持同一张脸，Inpainting 是必要的，这暗示了一种工作流：由 Qwen 处理宏观编辑，而定向的 Inpainting 处理则锁定身份保真度。
  • 几位用户请求获取使用 Wan 2.2 FFLF 达到所展示质量的具体工作流/Pipeline，并指出他们自己在默认 Wan 2.2 设置下的结果分辨率较低。用户对可复现的细节（如步骤顺序、编辑与 Inpainting 的先后顺序）表现出浓厚兴趣，而非通用的 Prompt，以便复制展示的高保真输出。
  • 一项技术观察指出，Qwen 的编辑处理“不会魔术般地凭空变出物体”，并且与源图像保持连贯，这表明在受限编辑下幻觉较少。然而，这种连贯性可能需要通过 Inpainting 来进行受控的插入或身份保留，以自由度换取对原始场景的遵循。
• 使用 AI 在《万智牌》（Magic the Gathering）的艺术作品和世界中游玩 (Score: 1436, Comments: 133): 该帖子声称提供了一种 AI 驱动的交互式体验，让用户可以“进入”《万智牌》（Magic the Gathering）卡牌艺术/世界中游玩（即从 2D 艺术衍生出的可导航环境），但链接的媒体 v.redd.it/dd1zfqjqi5lf1 目前无法访问（HTTP 403），因此无法从帖子中验证模型、流水线（pipeline）或实现细节。未提供代码、基准测试（benchmarks）或具体模型名称；除了兴趣和对归属/来源的询问外，讨论缺乏技术细节。 热门评论大多是非技术性的炒作；有人询问来源并推测其可能使用了 Google 的引擎——“请分享源代码……猜它是 Google 的引擎。普通人能访问吗？”——但未提供确认或访问详情。
  • 唯一偏向技术的讨论是询问用于生成可游玩的 MTG 风格环境的具体引擎/模型；一位评论者推测这可能是一个 Google 系统，并询问是否公开可用，以便他们可以在其他卡牌艺术上尝试。帖子中未提供实现细节、模型名称或性能说明（例如延迟、FPS 或训练/推理设置），因此读者是在寻求归属和访问详情，而非讨论技术。
• 尼古拉斯·凯奇版《芭比》（2026）- 预告片 (Score: 195, Comments: 30): Reddit 帖子分享了一个名为“尼古拉斯·凯奇版《芭比》（2026）——预告片”的恶搞预告片，但托管在 https://v.redd.it/k6vrey0eb3lf1 的视频在没有 Reddit 身份验证的情况下返回 HTTP 403 Forbidden ，因此无法检索或分析底层媒体。因此，无法仅从链接验证有关剪辑/VFX 流水线、潜在的 AI 换脸（face-swap）使用、音频设计或素材来源的技术细节。 热门评论是非技术性的，表达了积极的反响（幽默且耐看），没有对制作方法或工具进行实质性的评论。
• 如果我们将 AI 艺术更名为“AI 艺术挖掘”，反 AI 人群的抵触情绪可能会降低 (Score: 222, Comments: 98): 讨论帖建议将 AI 图像生成更名为“AI 艺术挖掘”（即探索/建模“潜空间”/latent space），以缓解对“氛围提示词”（vibe prompting，即 LLM 辅助的提示词创作）的反弹。附带的图像——一个穿着叶子服装、抱着猫的人在奇幻森林中的场景——是文本生成图像的示例输出，而非新模型/技术；未提供实现细节或基准测试。 评论意见不一：一位前职业艺术家通过开源工具将 AI 作为残障辅助工具，并强调低能耗（“大约相当于三个灯泡”）；其他人认为更名毫无意义，并批评一些“提示词工程师”（prompt engineers）缺乏艺术基础；而一些艺术家则表示他们只是将 AI 作为辅助工具。
  • 一位评论者区分了两种图像生成工作流：探索性提示（类似于寻找照片/截图）与具有位置控制的定向构图。他们指出，质量在很大程度上取决于对扩散参数（如 steps 和 sampler）的调整，并且使用工具控制对象放置（例如 ControlNet 风格的调节：https://arxiv.org/abs/2302.05543）可以将输出从随机探索转变为有意的布局；调度器（scheduler）的选择会实质性地影响清晰度/速度（参见 Diffusers 调度器：https://huggingface.co/docs/diffusers/using-diffusers/schedulers）。他们提到了使用 “qwen image” 进行工作，强调并非所有 AI 艺术都只是文本提示——某些工作流已接近完全的构图控制。
  • 另一位评论者强调使用开源、本地工具来实现可访问性（辅助/残障使用案例），且功耗极低（“大约三个灯泡”），这意味着使用的是设备端推理而非云端 GPU。这与在消费级硬件上通过 AUTOMATIC1111 (https://github.com/AUTOMATIC1111/stable-diffusion-webui) 或 ComfyUI (https://github.com/comfyanonymous/ComfyUI) 等工具运行 Stable Diffusion 流水线相契合，以峰值吞吐量换取隐私、成本控制和离线可用性。
• 让 ChatGPT 教我如何卷卷饼。 (评分: 2031, 评论: 166): 这是一个非技术/模因（meme）示例，突显了 LLM 的局限性：当被要求展示如何卷卷饼时，ChatGPT 生成了一个模仿信封/信件折叠方式的分步图解，而不是正确的卷饼式卷法（侧边折叠、底部向上，然后形成整洁的“包裹”），这凸显了其较差的视觉空间/程序性推理能力，以及在缺乏物理基础的情况下生成的自动图解不可靠。它说明了 LLM 如何自信地输出错误的动作序列和格式错误的教学图形。 评论者指出，这看起来像是在“寄信”，并一致认为它“没好到哪去”，还报告说 ChatGPT 经常主动提供图解，且这些图解总是一贯地错误——这进一步证实了该模型在图解合成和步骤排序方面的弱点。
  • 多位用户强调了 LLM 在 ASCII/图解生成方面的一种反复出现的失败模式：模型经常主动提出图解，并生成结构错误或对齐不准的视觉效果。这可能源于没有几何约束的 Token 级下一词预测训练，加上空格处理和比例字体渲染破坏了预期的布局；即使使用等宽代码块，对齐也是脆弱且非确定性的。实际上，用户应通过明确指令禁用未经请求的 ASCII，如果需要空间保真度，应优先选择工具辅助输出（例如，使用渲染器生成 SVG 或图像）。
  • 矛盾或荒谬的分步指令示例（例如，添加配料后又将其丢弃，或者重复使用玉米饼）说明了 LLM 在规划一致性方面的问题，特别是对于具有物理约束的程序化任务。这些是由于基础推理能力弱和缺乏约束检查而导致的经典连贯性错误；缓解措施包括要求状态跟踪、根据约束验证步骤，以及强制执行结构化输出（带有前置/后置条件的检查清单）而非自由格式的文本。确定性解码（低 Temperature）可以减少方差，但在没有明确约束或外部验证器的情况下，无法消除逻辑矛盾。
• 我尝试生成一段通用的 ChatGPT 回复作为约会软件的开场白 (评分: 197, 评论: 104): 非技术/模因帖子：一个格式化为 ChatGPT 回复的约会软件开场白，幽默地“分析”了匹配对象的风景照（例如，将其归功于科罗拉多州的真实风景、良好的光线和单反相机），并附带了一个戏谑的免责声明。技术角度纯粹是文化层面的：它将 ChatGPT 的回复风格作为社交破冰工具；未讨论模型、基准测试或实现细节。 评论分为两派，有人觉得有趣，有人觉得尴尬；点赞最高的回复鼓励真实性，而不是为了获得反应而进行优化。
• 我太懒了，所以我造了这个 (评分: 291, 评论: 61): 这款独立应用通过手机摄像头使用设备端计算机视觉来离线跟踪锻炼（“无云端”），自动计数动作次数，并标记 28 种练习中的作弊/不良姿势；它还会“嘲讽”错过的锻炼，并将社交应用（如 Instagram/TikTok）锁定在快速俯卧撑任务之后。目前仅为早期预览；候补名单已在 https://lazyfcks.vercel.app 开放，演示视频托管在 Reddit (https://v.redd.it/nhsq3lwcv5lf1) 上，但目前在没有身份验证访问的情况下返回 HTTP 403。重点是隐私和低延迟的设备端推理，而非云端处理。 一位评论者建议不应计算最后一次动作，暗示应采用更严格的动作验证启发式算法，以防止在接近力竭时动作变形；其他高赞评论均为非技术性内容。
  • 针对标准俯卧撑的姿势/动作幅度（ROM）评论：一位评论者指出，你应该让胸部贴近地面（或非常接近），并避免肘部外展。转化为客观标准，这意味着深度阈值（例如，胸部/肩膀中点距离地面约 3–5 cm 以内，或底部时上臂角度超过 90°）以及相对于躯干约 ≤45° 的肘部外展限制，以减少肩部压力。这些提示有助于确保完整的动作幅度并实现更可靠的动作验证。
• 动作次数（Rep）质量与终止逻辑：诸如“最后一次动作不应计入”和“0, 0, 0… 已终止”之类的反馈，意味着需要增加更严格的有效性检查和稳健的状态机（state machine）。需要同时具备底部深度和顶部锁定阈值，以及时间滞后（temporal hysteresis，例如保持跨越阈值的时间 ≥150–250 ms 或 ≥5–8 帧），以消除噪声检测的抖动（debounce），并使不满足最小振幅（amplitude）或张力下时间（time-under-tension）的动作失效。定义组结束条件，例如连续 N 次无效动作或在没有有效循环的情况下超时 T，以便优雅地终止并重置。
• 哥伦比亚一婴儿注册名为 ‘Chat Yipiti’，名字灵感来自 ChatGPT (Score: 2097, Comments: 153)：一则病毒式传播的帖子声称，哥伦比亚塞雷特（Cereté）的一名新生儿被正式注册为 “Chat Yipiti”，灵感来自 ChatGPT，照片中的医院婴儿摇篮标签和相关报道（Colombia One）对此进行了说明。然而，国家民事登记处（National Civil Registry）在 2025-08-19 表示，“在查询数据库后……目前没有以 ‘Chat Yipiti’ 为名的出生登记”，这与据称的 2025-08-15 登记日期相矛盾，表明该故事/图像可能是摆拍或未经证实的。评论者大多质疑其真实性，并对新奇的 AI 品牌名称提出了实际担忧（如霸凌）；其余大部分是笑话/双关语，而非技术讨论。
  • 据报道，哥伦比亚国家民事登记处（Registraduría Nacional del Estado Civil）的一份官方声明称，在查询其数据库后，目前没有名为 “Chat Yipiti” 的出生登记。这直接反驳了该登记发生在 8 月 15 日 的说法，登记处的说明日期为 8 月 19 日星期二。由于民事登记数据库中缺乏匹配记录，在得到官方条目证实之前，该说法似乎未经证实，且极可能是虚假信息。

AI Discord 摘要

由 X.ai Grok-4 生成的摘要之摘要

主题 1. DeepSeek V3.1 首次亮相，评价褒贬不一

• DeepSeek V3.1 进入竞技场，引发热议：DeepSeek V3.1 在 LMArena 和 Cursor 等平台上线，在 SWE-bench 的非思考模式（non-thinking mode）下得分 66，但因创意写作和角色扮演（roleplay）能力较弱而受到批评。用户指出它是 Gemini 2.5 pro 的略逊版本，但在编程方面很有前景。自 2025 年 9 月 5 日起，OpenRouter 上的输入价格将上涨至 $0.25。
• DeepSeek V3.1 深度思考，广泛集成：根据 DeepSeek 的 X 帖子公告，该模型支持 Anthropic API 集成以扩展用途。但 Moonshot AI 的成员根据 Hugging Face 页面表示，它是一个带有退化的增量改进。
• DeepSeek V3.1 量化与思考能力测试：在 Unsloth AI 中，DeepSeek V3.1 的思考能力备受期待，但在混合模式下被指出缺乏指令遵循（instruction-following）能力，混合模型在非思考模式下缺乏指令遵循能力和创造力。

主题 2. 字节跳动发布全新 OSS 模型

• 字节跳动发布 Seed-OSS 36B 原生猛兽：字节跳动发布了 Seed-OSS-36B-Base-woSyn，这是一个具有 512K 上下文的 36B 稠密模型，在 12T tokens 上训练且未使用合成数据，令 Unsloth AI 成员对微调充满期待，详见 Hugging Face 模型页。
• Seed-OSS 架构难倒 GGUF 粉丝：在 Nous Research AI 中，Seed-OSS 具有自定义的 MLP、dropout 和 qkv bias，但由于架构不支持 architectures: [“SeedOssForCausalLM”]，目前缺乏 GGUF 支持，引发了关于 ASIC 的推测，详见 X 帖子。
• Seed-OSS 邀请社区测试：Latent Space 在 GitHub 和 Hugging Face 上重点介绍了 Seed-OSS 系列，敦促社区对模型、代码和权重提供反馈，以促进开源发展。

主题 3. 硬件升级与基准测试热潮

• RTX 5090 价格引发升级大战：Unsloth AI 讨论了售价 $2000 的 RTX 5090 在训练中的 VRAM 优势，但抨击了 NVIDIA 缺失 P2P 或 NVLink 的行为；同时 GPU MODE 关注用于 4090-5090 分布式设置的 Infiniband。
• AMD 调试器 Alpha 版抢占风头：GPU MODE 展示了一个 alpha 版的 AMD GPU 调试器，具有反汇编和 wave stepping 功能，独立于 amdkfd KMD，详见 视频演示。
• M4 Max 在 MLX 基准测试中碾压 GGUF：LM Studio 测试显示，在 GPT-OSS-20b（4bit 量化，4k 上下文）上，MLX GPU 达到 76.6 t/s（功耗 32W），而 GGUF CPU 仅为 26.2 t/s，证明了 MLX 在效率上的优势。

主题 4. 数据集与训练技巧涌现

• WildChat-4M 数据集对英文 Prompt 进行去重：Unsloth AI 在 Hugging Face 上发布了 WildChat-4M-English-Semantic-Deduplicated，通过语义方法过滤至 <=2000 tokens，以获得更干净的训练数据。
• GRPO 需要分步数据集：Unsloth AI 建议为 GRPO 拆分多步游戏数据集，并指出全量 PPO 更适合游戏，因为 GRPO 适用于起初就大致知道该做什么的 LLM。
• Imatrix 校准助力 Qwen 扩展：Nous Research AI 使用 Ed Addorio 的数据集获取重要性矩阵（importance matrices），使 Qwen 2507 通过 RoPE scaling 达到 512k 上下文并最小化量化误差。

主题 5. API 困扰与安全惊魂

• OpenRouter 密钥泄露，用户损失 $300：OpenRouter 用户报告因 API key 泄露导致 $300 损失，攻击者使用代理隐藏 IP，由于用户承担主要责任，目前没有追回选项。
• Gemini 封号潮让用户感觉回到 2023 年：OpenRouter 讨论了 Gemini 的大规模封号，让人联想起 AI Dungeon 的清洗行动，用户哀叹 我们正被送回 2023 年 并开始寻找替代方案。
• Command A Reasoning 应对企业需求：Cohere 推出了用于 Agent 任务的 Command A Reasoning，可运行在单张 H100 上，具有 128k 上下文，并提供 token 预算功能以控制成本，详见 Cohere 博客。

Discord: 高层级 Discord 摘要

LMArena Discord

• Nano-Banana 沦为 McLau’s Law 的牺牲品：成员们开玩笑说 Nano-Banana 模型的表现经常低于预期，并幽默地将这一现象称为“McLau’s Law”（引用自一位 OpenAI 研究员），引发了关于附图中描绘的 AI 当前能力的讨论。
  • 一位用户表示 Nano-Banana 产生的结果往往远低于 nano-banana 水准。
• Video Arena 饱受 Bot 宕机困扰：用户报告 Video Arena Bot 宕机，导致命令失败且无法生成视频，实际上锁定了提示词频道 <#1397655695150682194>、<#1400148557427904664> 和 <#1400148597768720384> 的访问权限。
  • 管理员确认了宕机情况并正在进行修复，引导用户关注公告频道获取更新，并表示很快将推出登录功能以防止未来的服务中断。
• DeepSeek V3.1 加入战场：DeepSeek V3.1 和 deepseek-v3.1-thinking 模型已添加到 LMArena，现已开放使用。
  • 普遍共识是 v3.1 模型是 Gemini 2.5 pro 的略逊版本，尽管它作为编程模型很有前景，但在通用能力方面仍需增强。
• LMArena 用户遭遇数据丢失：一次站点故障导致了广泛的数据丢失，包括聊天记录缺失以及无法接受服务条款。
  • 管理员承认了该问题并向用户保证修复工作正在进行中。

Unsloth AI (Daniel Han) Discord

• 字节跳动发布 Seed-OSS 36B Base 模型：字节跳动在 Hugging Face 上发布了 Seed-OSS-36B-Base-woSyn 模型，这是一个拥有 512K 上下文窗口的 36B 稠密模型，在 12T tokens 上训练而成。
  • 成员们渴望尝试用该模型微调 GPT-ASS，认为缺乏合成数据这一点非常有吸引力。
• GRPO 需要巧妙的数据集设计：为了将 GRPO 用于多步游戏动作，成员们建议为每一步设计带有独立提示词的数据集。
  • 全量 PPO 可能更适合游戏，因为 GRPO 对 LLM 主要有效的原因是它们起初就大致知道该做什么。
• DeepSeek V3.1 的思考能力：DeepSeek V3.1 模型在非思考模式下在 SWE-bench verified 测试中获得了 66 分，引发了成员们的关注。
  • 然而，随后有人对其创意写作和角色扮演表现表示担忧，一些人指出混合模型在非思考模式下缺乏指令遵循能力和创造力。
• RTX 5090 价格引发升级讨论：RTX 5090 售价约为 $2000，引发了关于是否升级的讨论，特别是考虑到其 VRAM 容量对训练的意义。
  • 一些成员对 NVIDIA 的限制表示不满，特别是缺乏 P2P 或 NVLink 支持。
• WildChat-4M-English 发布：WildChat-4M-English-Semantic-Deduplicated 数据集 已在 Hugging Face 上线，该数据集由来自 WildChat-4M 数据集的英文提示词组成，并使用了多种方法进行去重。
  • 当前发布的版本包含 <= ~2000 tokens 的提示词，更长的提示词将在稍后添加，更多信息可以在这里找到。

OpenRouter (Alex Atallah) Discord

• Deepseek V3.1 热潮即将来临！：用户正热切期待 Deepseek v3.1 的公开发布，预计从 9 月份开始将免费提供。
  • 用户确认，在 OpenRouter 上为 Deepseek 模型付费比使用免费模型响应速度更快。
• OpenRouter API Key 泄露风险！：一名用户报告因 OpenRouter API key 泄露导致 $300 的损失，并寻求关于如何识别未经授权使用来源的建议。
  • 用户需对任何泄露的密钥负责，且威胁攻击者可以使用代理来掩盖其原始 IP。
• Gemini 面临大规模封号潮！：用户报告 Gemini 正在发生大规模封号，导致许多人寻找替代方案，并回想起当年由 OpenAI 引发的 AI Dungeon 清洗事件。
  • 用户表示“我们正被送回 2023 年”。
• Gemini 输入 Token 触发异常计数！：一位仪表板开发者注意到，当输入中包含图像时，OpenRouter 对 Gemini 模型 的 input tokens 计算会出现异常计数，并引用了 Google AI Developers 论坛上的相关讨论。
  • 该开发者正考虑就此问题向 OpenRouter 团队寻求澄清。
• 大多数机构在生成式 AI 上看到零回报！：根据 AFR Chanticleer 报告，95% 的机构在部署生成式 AI 后获得了零回报，该报告重点关注了部署了定制化 AI 模型的公司。
  • 报告指出，关键问题在于公司及其技术供应商没有投入足够的时间来确保其定制化 AI 模型能够持续学习其业务的细微差别。

Cursor Community Discord

• Claude 的缓存反复无常导致昂贵的难题：用户报告称 Claude 在 cache reads 方面遇到问题，导致费用比受益于可持续缓存的 Auto 更高。
  • 有推测认为 Auto 和 Claude 秘密地是同一个模型，将 token 使用量的减少归因于“安慰剂效应”。
• Sonic 极速模型在 Cursor 中大放异彩：社区目前正在 Cursor 中测试新的 Sonic 模型，由于其速度极快，初步印象相当不错。
  • 虽然在处理新项目时受到称赞，但一些用户警告说，在处理大型代码库时其效果可能会降低，并确认 Sonic 并非 Grok 模型，其来源仍是一家 stealth company（隐身公司）。
• Agentwise 作为开源项目觉醒：Agentwise 已经开源，支持网站副本、图像/文档上传，并支持超过 100 个 Agent，还承诺提供 Cursor CLI 支持。
  • 邀请用户在该项目的专用 Discord 频道中提供反馈，以帮助进一步开发。
• Cursor 成本确认：API 费用明晰化：关于 Auto agent 成本的困惑已得到澄清，即 pro 订阅包含了不同供应商的 API 使用成本。
  • 几位用户确认了成本澄清，其中一位表示相比 Sonic agent 更倾向于使用 Auto agent。
• DeepSeek 亮相，开发者反应不一：新的 DeepSeek V3.1 模型出现在 Cursor 的选项中，引发了褒贬不一的反应；一些用户遇到了连接问题，而另一些用户则表达了对“中国 LLM”的不信任。
  • 尽管存在担忧，一些人报告称 DeepSeek V3.1 在 TypeScript 和 JavaScript 方面表现良好，性能“出色”且比 Sonnet 更便宜。

LM Studio Discord

• CUDA 修复驱动 4070 检测：用户发现，通过 ctrl+shift+r 将运行时更改为 CUDA llama.cpp 可能会解决 LM Studio 中 4070 TI Super 显卡出现的 “0 GPUs detected with CUDA” 错误。
  • 他们讨论了启用 flash attention、KV cache 量化以及将 batch size 设置为 2048 的各种配置，使用的命令如 -fa -ub 2048 -ctv q8_0 -ctk q8_0。
• GPT-OSS 在 Prompt Eval 上完胜 Qwen：成员观察到 GPT-OSS 在使用 3080ti 进行 prompt eval 时达到了 2k tokens/s，优于 LM Studio 中 Qwen 的 1000 tokens/s。
  • 一位用户报告称 LM Studio API 调用比聊天界面慢得多（30倍），但在使用 curl 命令 curl.exe http://localhost:11434/v1/chat/completions -d {"model":"gpt-oss:20b","messages":[{"role":"system","content":"Why is the sun hot?\n"}]} 时，该问题因未知原因自行解决。
• Qwen3-30B CPU 配置表现惊人：使用 llama-bench，一位用户在仅限 CPU 的配置下，运行 Qwen3-30B-A3B-Instruct-2507-Q4_K_M.gguf 达到了 10 tokens per second。
  • 他们注意到性能随线程数变化，由于扩展性和开销原因，超过一定阈值后收益会递减。
• MLX 在 M4 Max 上的表现碾压 GGUF：在 Apple M4 Max 上对 GPT-OSS-20b 进行基准测试显示，MLX (GPU) 在 32W 功率下达到了 76.6 t/s (2.39 t/W)，而 GGUF (CPU) 在 43W 功率下仅达到 26.2 t/s (0.61 t/W)。
  • 在 4bit 量化和 4k 上下文下，MLX 证明了其比 GGUF 更快且能效更高，尽管 GGUF 的表现也令人印象深刻。

OpenAI Discord

• AI Agent 深入探讨 M2M 经济：成员们探讨了 机器对机器 (M2M) 经济，即 AI Agent 自主进行价值交换，重点关注 身份与信任、智能合约逻辑以及自主性 等挑战。
  • 支出上限、审计日志和保险等保障措施可能会加速 AI 在交易中的应用，但真正的信任建立仍需时日。
• 去中心化 AI 项目的 BOINC 悬赏：一位成员寻找类似 BOINC 的 去中心化 AI 项目，并指出 Petals network 在贡献和模型更新方面面临的挑战。
  • 贡献者建议，财务或活动驱动的激励措施可以加强去中心化 AI 的发展。
• Few-Shot 健身提示词展示：成员们剖析了在健身房的 29,000 token 提示词中使用 few-shot 示例的最佳策略，强调了 prompt engineering。
  • 建议包括在提示词中直接提供示例，并反复测试较小的分块以提高性能。
• GPT-5 的思考模式变笨了：一位用户报告称，GPT-5 的 thinking 模式给出了直接且低质量的回复，类似于旧版本的模型，令人沮丧。
  • 另一位成员推测，该用户可能超过了思考配额限制，导致系统回退到普通模式而非变灰不可用。
• AI 测验生成器生成琐碎内容：一位成员指出 AI 测验生成器在测验中生成明显错误选项的问题。
  • 另一位成员建议确保所有选项必须具有合理性，以改进 AI 的输出并生成更真实的回复。

Eleuther Discord

• PileT5-XL 发声：来自 PileT5-XL 的 embedding tensor 既可以作为 pile-t5-xl-flan（生成文本）的 instruction，也可以作为 AuraFlow（生成图像）的 prompt，这表明这些 embeddings 像语言中的单词一样具有意义。
  • 一位成员对文本反转（textual inversion）感兴趣，尝试将一张黑狗图片配合应用了 pile-t5-xl-flan 的 auraflow，以观察文本是否会将该狗描述为黑色。
• Cosmos 医疗模型规模化！：Cosmos Medical Event Transformer (CoMET) 模型系列是在代表 1150 亿个离散医疗事件（1510 亿个 tokens）、涵盖 1.18 亿名患者的数据上预训练的仅解码器 Transformer 模型，其表现通常优于或匹配特定任务的有监督模型。
  • 这项研究在 Generative Medical Event Models Improve with Scale 中进行了讨论，使用了 Epic Cosmos 数据集，该数据集包含来自 310 个医疗系统、超过 3 亿份独特患者记录、共计 163 亿次就诊的去标识化纵向健康记录。
• 字节跳动 Prover 夺牌：Bytedance 的 SEED Prover 在 IMO 2025 中获得了银牌分数。
  • 然而，目前尚不清楚这如何转化为现实世界的数学问题解决能力。
• 隔离 Llama3.2 注意力头：一位成员隔离了一个特定的 head，发现 Llama 3.2-1b instruct 和 Qwen3-4B-Instruct-2507 之间解码后的结果向量在不同输出中表现出显著的相似性。
  • 该成员表示，这两个 head 似乎促进了非常相似的内容。
• 寻求 Muon Kernel 支持：一位成员表示有兴趣添加 muon 支持，理由是潜在的 kernel 优化机会。
  • 他们认为，一旦实现了基础支持，就有空间针对这些优化进行协作开发。

Latent Space Discord

• Wang 晋升后 Meta 拆分业务：根据 Business Insider 的报道，Meta 正在将其 AI 业务重组为新任 MSL 负责人 Alexandr Wang 领导下的四个团队（TBD Lab、FAIR、Product/Applied Research、Infra），AGI Foundations 小组将被解散。
  • Nat Friedman 和 Yann LeCun 现在向 Wang 汇报，FAIR 将直接支持模型训练，并且正在考虑开发一个“omni”模型。
• GPT-5-pro 静默吞掉 Prompt：根据 此报告，GPT-5-pro 正在静默截断大于 60k tokens 的 prompt，且没有任何警告或错误消息，这使得大规模代码库的 prompt 变得不可靠。
  • 一些用户还反映 Cursor 中的 GPT-5 表现得比平时笨得多，有人怀疑正在进行负载削减（load shedding）。
• Dropout 灵感来自银行柜员：一条疯传的推文声称 Geoffrey Hinton 在注意到轮换的银行柜员能阻止勾结后构思了 dropout (来源)。
  • 反应从对这种偶然洞察力的钦佩，到怀疑以及关于从家庭聚会中产生注意力机制的笑话不等。
• 字节跳动发布 Seed-OSS 模型：字节跳动的 Seed 团队宣布了一个新的开源大语言模型系列 Seed-OSS，可在 GitHub 和 Hugging Face 上获取。
  • 团队正邀请社区对模型、代码和权重进行测试并提供反馈。
• Wonda 承诺视频革命：Dimi Nikolaou 介绍了 Wonda，这是一个旨在彻底改变视频/音频创作的 AI Agent，称其为“Lovable 之于网站，正如 Wonda 之于内容” (推文链接)。
  • 早期访问将通过候补名单授予，预计在大约 3 周内发放邀请。

GPU MODE Discord

• CUDA 困扰 ChatGPT：一位成员发现 ChatGPT 在 CUDA float3 对齐和大小方面给出了言之凿凿的错误答案，并随后将该话题的难度归因于 OpenCL 和 OpenGL 实现的复杂性。
  • 该成员已验证 CUDA 中不存在填充（padding）。
• 黑客松周六上午开始：GPU Hackathon 很可能在周六上午 9:30 左右启动，并有暗示称参与者将使用较新的 Nvidia 芯片。
  • 有人询问了黑客松的先决条件，但频道内无人回答。
• AMD GPU 调试器发布首个 Alpha 版本：一位工程师在这段视频中展示了新款 AMD GPU 调试器的 Alpha 版本，目前已支持反汇编和 wave 步进。
  • 该调试器不依赖于 amdkfd KMD，而是使用一个小型 UMD 驱动程序和 Linux 内核的 debugfs 接口，目标是成为 rocdbgapi 的等效替代品。
• DIY 分布式训练框架出现：一位成员正在构建自己的 PyTorch 分布式训练库和微型 NCCL 作为后端，用于在家中的 4090 和 5090 之间通过 Infiniband 进行连接。
  • 另一位成员对此表示了兴趣，认为这是研究分布式计算细节的好方法。
• MI300 霸榜 Trimul 排行榜：trimul 排行榜现在显示 MI300 的提交分数为 3.50 ms，另一项 MI300 的提交以 5.83 ms 的成绩获得第二名。
  • 一位成员在 B200 上以 8.86 ms 的成绩获得第 6 名，随后在 trimul 排行榜上进步到第 4 名（7.29 ms）；另一位成员在 H100 上以 3.80 ms 的成绩获得第二名。

Yannick Kilcher Discord

• 福布斯发现缺陷，引发纷争！：福布斯透露，Elon Musk 的 xAI 发布了数十万条 Grok 聊天机器人的对话。
  • 当被问及此事是否属实时，@grok 的回答闪烁其词，引发了进一步的猜测。
• LeCun 要离开、失败还是徘徊？！：一位用户根据 Zuckerberg 的帖子推测 Yann LeCun 可能会离开 FAIR。
  • 另一位成员暗示 LeCun 可能已被降职，且 Meta 正在从开源模型领域撤退。
• 无限内存决定机器威力！：一位成员认为图灵完备性需要无限内存，因此由于内存不足，宇宙无法创造出图灵完备的机器。
  • 另一位成员开玩笑地建议，让计算机足够慢，就可以利用宇宙的膨胀来解决空间问题。
• 新名词，新麻烦：AI 侮辱性词汇出现！：一位用户分享了《滚石》杂志的一篇文章，讨论了诸如 clanker 和 cogsucker 等新 AI 侮辱性词汇的出现。
  • 频道内的反应比较平淡，但似乎大家都同意这些词确实非常不雅。

HuggingFace Discord

• 支付问题困扰 Hugging Face Pro 用户：一位用户报告称，在未获得服务的情况下被收取了两次 Pro version 费用，并建议其他用户发送邮件至 website@huggingface.co，并在指定的 MCP channel 寻求帮助。
  • 尽管账户被反复扣费，该用户仍无法获得 Pro 服务。
• AgentX 承诺更智能的 AI 交易：新的 AgentX 平台 旨在提供一个汇集最顶尖 AI 大脑——ChatGPT、Gemini、LLaMA、Grok——的交易平台，让它们共同辩论，直到就最佳操作达成一致。
  • 该平台通过让 LLMs 辩论最佳操作，力求为交易者提供一个可以完全信任的系统。
• 成员辩论 SFT 与 DPO 的优劣：成员们讨论了 DPO (Direct Preference Optimization) 与 SFT (Supervised Fine-Tuning) 的有效性，其中一位成员指出 DPO 与推理（reasoning）没有关系，但在 SFT 之后进行 DPO 比仅进行 SFT 效果更好。
  • 讨论涉及利用 DPO 提升性能，然而，其与推理的关系在成员间存在争议。
• HF Learn 课程受 422 错误困扰：一位成员报告称，Hugging Face LLM 课程的一个页面 已下线并显示 422 error。
  • 用户目前无法访问该学习课程中损坏的页面。

Notebook LM Discord

• 用户发现利用 Gems 优化播客生成的秘诀：用户正在开发工作流（例如此示例），以创建更深层的研究框架，从而利用 Gems、Gemini、PPLX 或 ChatGPT 生成播客。
  • 关键在于设置 Prompt 来逐段规划整个文稿，从而根据较长的 YouTube 视频生成播客。
• 自定义界面允许用户配置播客长度：用户可以通过使用 Customize 选项（三个点）在 NotebookLM 中调整播客长度，将播客时长延长至 45-60 分钟。
  • 指定主题可以让 Bot 集中讨论特定话题，而不是依赖它将所有重要内容塞进单个播客中。
• 隐私政策担忧普遍存在：用户正在使用 Gemini 和 NotebookLM 分析医疗保健公司的隐私政策和使用条款。
  • 用户对向这些公司出让了多少权利以及这种方法在理解使用条款（Terms of Use）和隐私政策（Privacy policies）方面的实用性感到惊讶。
• Android 应用功能对等进度延迟：用户要求 NotebookLM Web 端应用与 Android app 之间实现更多的功能对等（feature parity），特别是针对学习指南功能。
  • 一位用户表示，目前的原生应用几乎没用，因为学习指南依赖于笔记功能，而原生应用中缺少该功能。
• NotebookLM API 仍难觅踪迹：虽然 NotebookLM 的官方 API 尚未发布，但用户建议使用 Gemini API 作为替代方案。
  • 另一位用户分享了结合使用 GPT4-Vision 和 NotebookLM 的策略，以快速消化带有标注的复杂 PDF 原理图。

Nous Research AI Discord

• 字节跳动发布长上下文模型：根据这张图片，字节跳动发布了一个具有极长上下文的基础模型，该模型没有使用 MHLA，没有 MoE，甚至没有 QK norm。
  • 该模型的架构被描述为 vanilla（原生），人们希望即将发布的论文能提供更多见解。
• Seed-OSS-36B 缺失 GGUF 引发猜测：用户询问为何 Seed-OSS-36B 还没有 GGUF 版本，并指出这类版本通常出现得很快，同时引用了此链接质疑其对 ASICs 的影响。
  • 有建议称延迟可能源于自定义的 vllm 实现，由于 architectures: ["SeedOssForCausalLM"]，该架构目前尚未被 llama.cpp 支持。
• Seed 模型包含 Dropout 和 Bias：Seed 模型采用了类似于 LLaMA 的自定义 MLP 和注意力机制，但增加了 dropout、输出偏置项（bias term）以及 qkv 头的偏置项。
  • 这些新增项被推测用作正则化技术；然而，该模型训练的 epoch 数量仍不得而知，且已确认仅将其重命名为 LLaMA 是无法运行的。
• Qwen 通过 RoPE 扩展至 512k 上下文：根据这个 Hugging Face 数据集，30B 和 235B 的 Qwen 2507 模型可以使用 RoPE 缩放实现 512k 的上下文。
  • 这些数据集用于生成重要性矩阵（imatrix），有助于在量化过程中最大限度地减少误差。
• Cursor 的内核博客赢得喝彩：成员们分享了 Cursor 内核博客的链接。
  • 许多人一致认为 Cursor 在这方面做得太棒了。

Moonshot AI (Kimi K-2) Discord

• DeepSeek V3.1 亮相，带来小幅改进：新的 DeepSeek V3.1 模型已发布，一些成员指出它就像是一个带有某些性能回退的增量改进，并参考了 DeepSeek 官方页面。
  • 社区正密切关注其性能，以观察其细微的提升和潜在的缺点。
• DeepSeek 支持 Anthropic API 集成：正如 X 平台上宣布的那样，DeepSeek 现在支持 Anthropic API，扩展了其功能和覆盖范围。
  • 这一集成使用户能够在 Anthropic 的生态系统中使用 DeepSeek，为 AI 解决方案的开发提供了灵活性。
• R-Zero LLM 在无人类数据的情况下进化：一份关于 R-Zero 的综合研究 PDF 被分享，这是一种从零人类数据开始并独立改进的自进化 LLM 训练方法。
  • 该方法标志着与传统 LLM 训练的背离，有可能减少对人类标注数据集的依赖。
• 中国避开了数据中心能源困境：一位成员指出，在中国，能源供应被视为理所当然，这与美国关于数据中心功耗和电网限制的争论形成鲜明对比，并引用了这篇《财富》杂志的文章。
  • 这种方法的差异可能会使中国 AI 公司在扩展能源密集型模型方面获得竞争优势。
• Kimi K2 期待更好的图像生成：一位成员指出，如果 Kimi K2 能结合比 GPT-5 更好的图像生成能力，将会更加强大（OP），并分享了这个 Reddit 链接。
  • 集成增强的图像生成功能将使 Kimi K2 成为一个更全面、更具竞争力的 AI 助手。

aider (Paul Gauthier) Discord

• Gemini 2.5 Pro 表现不佳，而 Flash 表现出色：有用户报告 Gemini 2.5 Flash 功能正常，而 Gemini 2.5 Pro 持续失败，但在配置账单后，gemini/gemini-2.5-pro-preview-06-05 可以运行。
  • 另一名用户报告因 qwen-cli 进程产生了 $25 的费用并请求退款，这突显了模型性能和计费方面可能存在的不一致。
• 用户遭遇意外的 Qwen CLI 扣费：一名用户在通过 Google OAuth 身份验证后使用 qwen-cli 产生了 $25 的费用，而该用户原本预期能获得来自 Alibaba Cloud 的免费额度。
  • 他们提交了支持工单，引用了控制台显示的一条 无输出且扣费 $23 的调用记录 来对这笔意外费用提出申诉。
• 社区对 GPT-5 Mini 模型进行基准测试：由于全量版 gpt-5 的速率限制，社区成员正积极对 gpt-5-mini 和 gpt-5-nano 进行基准测试，一位用户声称 gpt-5-mini 非常出色且价格低廉。
  • 目前已有基准测试结果和针对 gpt-5-mini 的 PR，反映了社区对评估更小、更易获取的模型的兴趣。
• DeepSeek v3.1 价格上涨：从 2025 年 9 月 5 日起，DeepSeek 将把两个模型的输入价格调整为 $0.25 vs $0.27，以匹配 reasoner 模型的价格。
  • 价格上涨以匹配 deepseek 3.1 模型，反映了定价策略的变化。
• OpenRouter 需要“Think”模式：用户注意到 OpenRouter 缺乏用于增强推理的原生“think”模式，但可以通过命令行启用：aider --model openrouter/deepseek/deepseek-chat-v3.1 --reasoning-effort high。
  • 社区成员建议更新模型配置以填补这一功能空白。

DSPy Discord

• Marimo Notebooks 崛起成为 Jupyter 的替代方案：一名成员发布了 marimo notebooks 教程，强调了它在 Graph RAG with DSPy 构思迭代中的应用，它能同时作为 notebook、脚本和应用。
  • 接下来的视频将探索 DSPy modules 的优化，在当前向新用户介绍 marimo 的教程基础上进一步深入。
• 可读性辩论：DSPy 代码先遭质疑后获维护：在一名成员驳斥了 IBM AutoPDL 关于不可读性的指控后，他们辩称 DSPy 的代码和 prompts 具有极高的人类可读性和清晰度。
  • 辩护者强调了代码的易用性，使其易于理解和操作。
• GEPA 登陆 DSPy v3.0.1：成员们确认 GEPA 已在 dspy 版本 3.0.1 中可用，如附带的 截图 所示。
  • 在微调期间，一名成员询问是否通常对 dspy.InputField() 和 dspy.OutputField() 使用 “常规描述 (vanilla descriptions)”，以便让优化器自由思考。
• Pickle 问题：DSPy 程序未保存：一名用户报告了保存优化程序时的问题，指出即使使用了 optimized_agent.save("./optimized_2", save_program=True)，元数据也仅包含依赖版本而没有程序本身。
  • 当另一名用户为 GEPA 设置了 32k 的最大上下文长度但仍收到被截断的响应时，成员们讨论了长推理的复杂性以及多模态设置中的潜在问题。
• RAG vs 拼接：百万级文档的辩论：成员们辩论了对于处理税法或农作物保险文件等任务，RAG (Retrieval-Augmented Generation) 还是简单的 拼接 (concatenation) 更合适。
  • 辩论承认，虽然 RAG 常被视为大材小用，但数百万份文档的规模有时足以证明其使用的合理性。

Cohere Discord

• Command A Reasoning 发布：Cohere 推出了专为企业设计的 Command A Reasoning，在 Agentic 和多语言基准测试中表现优于其他模型；可通过 Cohere Platform 和 Hugging Face 获取。
  • 根据 Cohere blog，它可以在单张 H100 或 A100 上运行，上下文长度为 128k，在多 GPU 上可扩展至 256k。
• Command 的 Token Budget 解决难题：Command A Reasoning 具备 token budget 设置功能，能够直接管理计算使用量并控制成本，从而无需区分推理模型和非推理模型。
  • 它也是驱动 North（Cohere 的安全 Agentic AI 平台）的核心生成模型，支持自定义 AI Agent 和本地自动化。
• Command-a-03-2025 引用功能不稳定：command-a-03-2025 仅间歇性地返回引用（citations），即使将 maxTokens 设置为 8K 也是如此，这在生产环境中引发了信任问题。
  • 一位 Cohere 成员澄清说，它在引用时使用的是 “fast” 模式（根据 API reference），且不保证一定提供引用；建议改用 command-a-reasoning。
• Langchain RAG 开发中：一位成员正在学习 Langchain 以构建 RAG（Retrieval-Augmented Generation）应用，并打算使用 command-a-reasoning。
  • 他们期待 command-a-omni 的发布，并对名为 Command Raz 的未来模型表示期待。

MCP (Glama) Discord

• MCP 客户端忽略 Instructions 字段：成员们报告称 MCP 客户端（特别是 Claude）正在忽略 instructions 字段，而仅考虑 tool descriptions。
  • 一位成员建议 添加指令、上下文，然后重复指令会产生更好的效果，但这在集成 API 中无法实现；而另一位成员则建议 MCP server 应优先处理 tool descriptions。
• 多样化的 MCP Server 实践：成员们正在分享他们首选的 MCP server 配置和工具，包括用于版本控制的 GitHub、用于后端开发的 Python 和 FastAPI，以及用于机器学习的 PyTorch。
  • 一位用户寻求关于如何让 Agent 遵循特定 generate_test_prompt.md 文件的建议，并链接了其配置的截图。
• Web-curl 释放 LLM Agent 威力：Web-curl 是一个使用 Node.js 和 TypeScript 构建的开源 MCP server，它使 LLM Agent 能够获取、探索并与网页及 API 进行交互，源代码可在 GitHub 获取。
  • 在功能上，Web-curl 使 LLM Agent 能够以结构化的方式获取、探索并与网页及 API 交互。
• MCP-Boss 集中化密钥管理：一位成员介绍了 MCP Boss，用于集中化密钥管理，提供单一 URL 作为所有服务的网关，具有多用户身份验证以及通过 OAuth2.1 或静态 HTTP 标头进行的 MCP 授权功能。
  • 更多信息请访问 mcp-boss.com。
• MCP Gateway 中的 AI 路由功能：一位成员介绍了一个带有 AI 驱动路由功能的轻量级网关，旨在解决 Agent 需要知道哪个特定服务器拥有正确工具的问题，代码可在 GitHub 获取。
  • 通过使用该网关，可以利用 AI 来解决 MCP 路由问题。

Modular (Mojo 🔥) Discord

• Modular 庆祝 Modverse 里程碑：Modular 发布了 Modverse #50，并宣布了自定义服务器标签，详见 Screenshot_2025-08-21_at_5.22.15_PM.png。
  • 自定义服务器标签已部署。
• 文档匮乏困扰 kgen 和 pop：成员们反映 kgen 和 pop 缺乏文档，特别是关于操作和参数的部分，其中一位指出目前还没有关于内部 MLIR dialects 的全面文档。
  • 共享了 GitHub 上 pop_dialect.md 的链接，并澄清这些是 stdlib 与编译器之间契约的一部分，因此在 stdlib 之外使用它们需自担风险。
• POP Union 面临对齐问题指控：由于在使用 sizeof 时出现了意料之外的大小差异，人们对 pop.union 中存在的对齐（alignment）Bug 产生了怀疑。
  • 一名成员在 GitHub 上创建了 issue 5202 以调查 pop.union 中疑似的对齐 Bug，同时观察到 pop.union 似乎没有在任何地方被使用。
• TextGenerationPipeline Execute 方法现身：一名成员找到了 TextGenerationPipeline 上的 execute 方法，并链接到了 Modular 仓库中的相关代码行。
  • 他们建议检查 MAX 版本。
• 内存分配器备受关注：一位成员建议，在将内存分配器集成到语言之前，可能需要强大的分配器支持，因为大多数用户不想手动处理内存不足（OOM）错误。
  • 这些评论是在讨论其他困难时提出的，其中一名成员报告在创建自定义推理循环（inference loop）时，难以在获取下一个 Token 的同时检索 logits，并链接了一份 Google Docs 文档 以提供背景信息。

LlamaIndex Discord

• LlamaIndex 首次展示企业级文档 AI：LlamaIndex 产品副总裁将于 PST 时间 9 月 30 日上午 9 点 预告关于文档解析、提取和索引的 企业级经验学习。
  • 重点在于 LlamaIndex 如何解决现实世界中的文档挑战。
• vibe-llama CLI 工具配置编码 Agent：LlamaIndex 推出了 vibe-llama，这是一个 CLI 工具，可自动为 LlamaIndex framework 和 LlamaCloud 配置带有上下文和最佳实践的编码 Agent，详情见此处。
  • 目标是简化开发工作流。
• CrossEncoder 类：Core vs Integrations：一位成员询问了 llama-index 中重复的 CrossEncoder class 实现，具体位于 .core 和 .integrations 下（代码链接）。
  • 官方澄清 .core 版本是 v0.10.x 迁移的遗留物，建议通过 pip install llama-index-postprocessor-sbert-rerank 使用 llama_index.postprocessor.sbert_rerank。
• 寻求 Agent 创建网关：一位成员正在寻找现有的 gateway 项目，该项目能将 model, memory, and tools 结合在一起，并暴露一个 OpenAI-compatible endpoint。
  • 他们希望在 Agent 探索中避免重复造轮子。
• AI 安全调查收集社区意见：一位成员分享了一份 AI 安全调查，以收集社区对重要 AI safety questions 的看法。
  • 该调查旨在了解 AI safety community 最感兴趣的内容。

Manus.im Discord Discord

• 用户报告积分购买选项缺失：成员们报告称购买额外积分的选项消失了，用户只能看到 upgrade package（升级包）选项。
  • 已确认该选项目前处于 down right now（下线状态）。
• 支持工单无人回应：一名用户报告了一个任务问题并创建了工单 #1318，但尚未收到回复或获得查看工单的权限。
  • 他们请求团队协助，并标记了一名特定成员。
• 比赛获胜者引发操纵指控：一名用户指称比赛的第二名获得者不配获胜，并声称比赛看起来像被操纵了。
  • 目前没有提供进一步的证据或细节来支持这一说法。
• 每日免费积分已停止？：一位回归用户注意到他们没有收到通常的 300 每日免费积分。
  • 他们询问 Manus 是否已停止提供这些积分。
• 推荐积分代码困惑：一名用户询问如何领取推荐积分，并指出系统要求输入代码。
  • 该用户表示不知道在哪里可以找到所需的代码。

tinygrad (George Hotz) Discord

• 探索 Overworld 常量折叠：一名成员探索了 overworld const folding（常量折叠）和潜在的 view(const) refactor（重构），在此 Discord 线程中重新定义了 UPat.cvar 和 UPat.const_like 以匹配 CONST 和 VIEW(CONST)。
  • 目标是折叠像 x * 0 这样的表达式，然而，有人对符号计算中有效性和 .base 扩散表示担忧。
• 以 ALU View 推送作为替代方案：建议采用另一种方法，即在 kernelize 中添加一个 upat，将 view 直接推送到 ALU 上，效仿 S-Lykles’s method。
  • 考虑到 * 0 在计算上的无关性，这种方法和针对 x * 0 的特殊规则将允许未经修改的符号匹配。
• 主张移除 base：一名成员强烈建议不要采用提议的方法，认为它“非常丑陋”，并主张 移除 .base。
  • 讨论还质疑了在此背景下如何处理 PAD 操作。
• RANGEIFY=1 简化实现：有人建议设置 RANGEIFY=1 可以带来更简洁的实现。
  • 然而，项目目前正处于旧引擎和 rangeify 并存的过渡阶段，处于一种悬而未决的状态。

Nomic.ai (GPT4All) Discord

• GPT4ALL 免费版支持私有 AI：一名用户询问公司如何使用 GPT4ALL 来私密且安全地使用其 AI 模型。
  • 另一名成员澄清说，如果公司已经准备好了自己的 AI 模型，那么免费版本就足够了。
• 用户寻求 LocalDocs 模型：一名用户正在寻求模型推荐，以便利用 GPT4All 的 LocalDocs 功能，从数百篇 PDF 格式的科学论文中构建个人知识库。
  • 该用户说明他们拥有 Nvidia RTX 5090，配备 24 GB VRAM 和 64 GB RAM，并希望所选模型具备 reasoning capabilities（推理能力）。

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

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

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

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

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

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

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

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

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

nano-banana model, Video Arena problems, DeepSeek V3.1, Gemini 3

• Nano-Banana 的 McLau 定律揭晓：一名成员开玩笑说 Nano-Banana 经常产生远低于 nano-banana 的结果，并将这一现象称为“McLau’s Law”（McLau 定律），这是对 OpenAI 研究员之一的幽默致敬。
  • 附带了一张幽默图片，引发了关于 AI 当前能力的讨论。
• Video Arena 因 Bot 宕机而陷入困境：成员们报告了 Video Arena 的问题，称无法使用命令或生成视频，管理员确认了 Bot 宕机并正在进行修复。
  • 针对视频创建权限的反复询问，得到的解释是 Bot 暂时不可用，并引导用户前往公告频道获取更新。
• DeepSeek V3.1 进入竞技场：用户讨论了在平台上引入 DeepSeek V3.1 的情况，一位用户将新模型描述为 Gemini 2.5 pro 的略逊版本。
  • 然而，共识是它作为编程模型具有潜力，但需要进一步提升通用能力。
• 用户声称 Gemini 3 即将到来：虽然未经证实，但一位用户暗示 Gemini 3 即将发布，推测发布日期将与 Google Pixel event 同步，引发了成员们的期待。
  • 该用户未引用任何来源，此说法很快被其他社区成员驳回。
• 站点故障清空聊天记录：用户报告在站点故障后出现大规模数据丢失，包括聊天历史记录丢失以及无法接受服务条款，管理员对此表示知情并保证会进行修复。
  • 管理员还表示，很快将上线登录功能，以防止此类情况再次发生。

LMArena ▷ #announcements (2 messages):

Video Arena Bot, Deepseek v3.1, LMArena Models

• Video Arena Bot 宕机，频道已锁定：Video Arena Bot 目前无法工作，锁定了对提示词频道 <#1397655695150682194>、<#1400148557427904664> 和 <#1400148597768720384> 的访问。
  • 必须在 Bot 在线时才能在这些特定频道中发送提示词。
• DeepSeek v3.1 已添加到 LMArena：LMArena 新增了两个模型：deepseek-v3.1 和 deepseek-v3.1-thinking。
  • 这些模型现在可以在竞技场中使用。

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

ByteDance Seed 模型, GRPO 训练, DeepSeek V3.1 量化, Nvidia GPU 与定价, GLM-4.5 Cline 集成

• 字节跳动发布 Seed-OSS 36B 基础模型：字节跳动在 Hugging Face 上发布了 Seed-OSS-36B-Base-woSyn 模型，这是一个 36B 稠密模型，具有 512K 上下文窗口，并明确声称没有合成指令数据，使其成为进一步微调的有趣基础。
  • 成员们表示兴奋，指出它与 Qwen3 等模型不同，一些人渴望在数据集完成后尝试用它来微调 GPT-ASS，尽管该模型仅在 12T tokens 上进行了训练。
• GRPO 训练需要智能数据集设计：为了将 GRPO 用于多步游戏动作，成员们建议设计数据集时为每一步设置单独的 prompt，例如 [[‘step1 instruct’], [‘step1 instruct’, ‘step1 output’, ‘step2 instruct’]]，并实现一个奖励函数来匹配输出。
  • 有人指出，Full PPO 可能更适合游戏，因为 GRPO 主要对 LLM 有效，因为它们基本上知道一开始该做什么。
• DeepSeek V3.1 在思考和非思考模式下横扫排行榜：DeepSeek V3.1 模型表现出了极具竞争力的结果，在非思考模式下的 SWE-bench verified 取得了 66 分，成员们对此表示兴奋，并将其与 GPT5 中等推理能力进行比较。
  • 虽然最初备受推崇，但随后的讨论提到了对其在创意写作和角色扮演中表现的担忧，一些人指出混合模型在非思考模式下缺乏指令遵循能力和创造力。
• Nvidia RTX 5090 价格稳定，引发升级争论：RTX 5090 目前定价在 $2000 左右，引发了关于是否升级的讨论，特别是考虑到其 VRAM 能力对训练的价值，而其他人则建议坚持使用 3090s 或等待 RTX 6000。
  • 一些成员对 NVIDIA 的限制表示沮丧，特别是缺乏 P2P 或 NVLink，一位成员开玩笑说：如果你坐在 5090 上，你就会用它玩游戏。
• 高质量 Imatrix 校准数据是关键：成员们指出 WikiText-raw 被认为是校准 imatrix 的糟糕数据集，因为 imatrix 需要充分多样化，并在模型原生的 chat-template 格式示例上进行训练。
  • 相反，Ed Addorio 最新的校准数据包含数学、代码和语言 prompt，如果操作得当，可以改善并帮助保留模型对多种语言的理解。

Unsloth AI (Daniel Han) ▷ #introduce-yourself (1 条消息):

.zackmorris: Hello

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

GRPO 20mb 分配失败, ChatGPT 深度研究, Grok-4, 重复惩罚, RAG

• **GRPO 20MB 分配失败困扰 Gemma 模型！：一位用户报告在处理 gemma-3-4b-it-unslop-GRPO-v3 时，GRPO** 频繁出现 20MB 分配失败。
• **ChatGPT 的深度思考模式提升性能！：一位用户建议通过启用联网搜索并在 prompt 中添加 “尽可能使用深度思考 (use deep thought if possible)” 来增强 **ChatGPT 的性能，即使没有完整的深度研究功能。
• **Grok-4 表现出色！：一位用户对 **Grok-4 印象深刻，暗示他们可能一直在秘密使用 Grok-4-Heavy。
• **重复惩罚引发笑料：一位用户分享了一张图片，展示了 **repetition penalty 参数的重要性。
• **RAG 协助：一位用户请求在处理 **RAG 时提供帮助。

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

视网膜照片训练策略，GPT-OSS 20B 在 Sagemaker 上的部署，Unsloth Zoo 问题，使用 Unsloth 加载 GGUF，Gemma 3 Vision Encoder 训练损失

• 针对视网膜照片微调 Vision-Text Encoders：一位用户询问是训练一个自定义的视网膜照片 Vision-Text Encoder 更好，还是在 Unsloth 中使用主流模型，并指出视网膜照片在训练数据集中代表性不足。
  • 建议尝试计算机视觉模型、在类似数据集上进行迁移学习以及多模态方法，并利用 Prompt Engineering 和 Personas 生成合成临床笔记。
• 排除 GPT-OSS 20B Sagemaker 部署故障：一位用户在 Sagemaker 上部署 unsloth/gpt-oss-20b-unsloth-bnb-4bit 时遇到 ModelError，收到 400 错误和 InternalServerException，消息为 \u0027gpt_oss\u0027。
  • 有回复提到该模型无法在 AWS Sagemaker 上运行，建议部署 GGUF 或普通版本，使用 LMI Containers，并引导用户参考 AWS Documentation。
• Unsloth Zoo 安装问题：一位用户在 Sagemaker 实例中安装 unsloth-zoo 后仍遇到导入错误。
  • 用户通过删除所有包，然后重新安装 Unsloth、Unsloth Zoo 以及 JupyterLab 解决了该问题，同时还需要更新 Unsloth 并刷新 Notebook。
• Apple Silicon Mac 的量化考量：一位用户寻求关于哪种 GGUF 量化最适合 M 系列 Apple Silicon 的建议，并指出 Mac 针对 4-bit 和 8-bit 计算进行了优化。
  • 建议用户选择 Q3_K_XL，如果显存不足以容纳上下文则选择 IQ3_XXS；Q3-4 量化可以获得较好的性能，但如果使用 GGUF，其影响相对较小。
• GPT-OSS 通过 LLaVA 获得多模态能力：一位用户询问为什么 vision llama13b 的 Notebook 对 gpt-oss-20b 不起作用，并想知道是否有人成功实现过。
  • 解释称 GPT-OSS 仅限文本，并非视觉模型，因此无法直接运行；若要添加视觉支持，用户必须像 LLaVA 那样附加自己的 ViT module，可以参考 LLaVA Guides。

Unsloth AI (Daniel Han) ▷ #showcase (11 条消息🔥):

WildChat-4M-English-Semantic-Deduplicated 数据集，Behemoth-R1-123B-v2 模型，GPU Rich 炫耀

• WildChat-4M 英文 Prompt 数据集发布：WildChat-4M-English-Semantic-Deduplicated 数据集已在 Hugging Face 上线，包含来自 WildChat-4M 数据集的英文 Prompt，使用了包括 Qwen-4B-Embedding 和 HNSW 语义去重在内的多种方法进行去重。
  • 当前版本包含 <= ~2000 tokens 的 Prompt，后续将添加更长的 Prompt，更多信息请参阅此处。
• TheDrummer 发布 Behemoth-R1-123B-v2：由 TheDrummer 创建的 Behemoth-R1-123B-v2 模型已发布，可以在此处找到。
  • 一位成员提到，能在 HF 中配置自己的硬件感觉非常硬核。
• GPU Rich 是新的炫耀方式：一位成员分享了一张图片，描绘了对贫穷的嘲讽，转而炫耀 GPU Rich。
  • 以 TFLOPS 为单位查看 GPU 性能是一种高端的炫耀。

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

Qwen3-4B finetuning, TTS with Gemini 270m, Mixture Models, JetMoE, BAM

• **Unsloth + Qwen3-4B：强强联手？: 一位成员正在使用 **Unsloth 对 Qwen3-4B 进行微调，并将在完成后分享包括评估在内的结果；目前微调进展顺利。
  • 另一位成员祝其好运！
• 从零开始训练模型: 一位成员正在从零开始训练一个概念验证模型，进度已达 22%，使用的是自行构建的 6 年级数学数据集，包含 500k 样本数据。
  • 如果成功，他们将把数据集扩展到其他学科。
• 基于 Gemini 270M 的文本转语音（TTS）构想: 一位成员想尝试基于 Gemini 270m 的 TTS 概念，并希望在月底前开始。
  • 他们的灵感来自混合模型（Mixture Models）论文。
• 专家讨论合并模型在 HumanEval 上的弱点: 一位成员引用了关于从零训练混合模型的 JetMoE 论文，指出尽管它们在其他方面的表现优于基准模型，但在 HumanEval 上的表现较差。
  • 他们还提到了 BAM，其中预训练模型被复制并在不同领域进行训练，然后进行组合，这在编程方面也损失了百分点。

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

Cloudflare outage, Generations API stability

• Generations API 受 Cloudflare 波动影响: 由于上游基础设施提供商的问题，Generations API 端点经历了短暂中断，导致部分调用出现 404 错误。
  • 公告指出，该问题与 Cloudflare 的间歇性问题有关，但 Generations API 现已恢复健康状态。
• 可重试的恢复: 对该端点的调用可能会出现 404，但应该很快就可以重试。
  • 公告向用户保证服务将很快恢复，并建议他们重试任何失败的调用。

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

OpenRouter Cost Dashboard, Average Request Size, Gemini Input Token Calculation

• **费用报告实现可视化！**: 一位成员开发了一个免费的仪表板，用于可视化来自 OpenRouter 的 .csv 费用报告，旨在分析共享账户的数据。
  • 该仪表板可在 openroutercosts.lorenzozane.com 访问，计划包含额外的 KPI 和增强图表，欢迎反馈。
• **仪表板请求增加平均请求大小指标！: 一位成员请求在 OpenRouter 费用仪表板中添加平均请求大小指标，特别是平均输入 Token** 和平均输出 Token。
  • 仪表板开发者承诺很快会添加此功能。
• **Gemini 输入 Token 触发异常计数！: 仪表板开发者注意到，当输入中包含图像时，OpenRouter** 对 Gemini 模型的输入 Token 计算似乎产生了异常计数。
  • 他们正在考虑向 OpenRouter 团队寻求澄清，并引用了 Google AI Developers 论坛上的相关讨论。

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

Deepseek 定价, OpenRouter rate limits, Gemini 封号, 在 RAG 系统中使用 OpenRouter, 4.6T 参数模型

• Deepseek V3.1 公开发布在即！: 许多用户正急切等待 Deepseek v3.1 的公开发布，对其渴望程度极高，并预期它将从 9 月开始免费。
• 付费版 Deepseek 提供更快的响应: 用户确认在 OpenRouter 上为 Deepseek 模型付费比使用免费模型响应更快。由于 Chutes 导致响应变慢，一名用户选择了切换，且免费模型因频繁的速率限制 (rate limits) 导致用户体验不佳。
  • 一位用户表示：自从 Chutes 导致响应变慢后，我就直接付费了。
• OpenRouter API Key 易受泄露和攻击: 一名用户报告因 OpenRouter API Key 泄露损失了 $300，并寻求关于识别未经授权使用来源的建议。但攻击者可能会使用代理来掩盖其原始 IP，用户需对任何泄露的 Key 负责。
• Gemini 正在进行“封号华尔兹”吗？: 用户报告 Gemini 正在发生大规模封号，导致许多人寻找替代方案，并回想起由 OpenAI 引发的 AI Dungeon 清洗事件。
  • 一位用户哀叹道：我们被送回了 2023 年。
• OpenRouter API Key 可以用于 RAG 吗？: 用户讨论了在结合 Milvus 创建的本地向量数据库的 RAG 系统中使用 OpenRouter LLM API Key 的可能性。
  • 共识是可行的，但 OpenRouter 并不直接支持 embeddings，因此你需要使用 Milvus 检索文档，并将其与你的提示词问题一起发送给 OpenRouter LLM API。

OpenRouter (Alex Atallah) ▷ #new-models (3 条消息):

``

• Readybot.io 宣布 OpenRouter 新模型: Readybot.io 发布了关于 OpenRouter 平台上可用新模型的更新和信息。
• OpenRouter 新模型更新: OpenRouter 平台重点介绍了其 AI 模型选库的最新增加和更改，正如 Readybot.io 所宣布的那样。

OpenRouter (Alex Atallah) ▷ #discussion (16 条消息🔥):

Qwen3 coder 480b, DeepSeek v3 0324, 生成式 AI 零回报, Google Gemini 400 错误, Cohere 推理模型

• LLM 难以正确格式化输出: 用户发现 像 Qwen3 coder 480b 和 DeepSeek v3 0324 这样的 LLM 难以遵循正确格式化输出的指令，经常导致 Bug 和提示词被忽略。
  • 一位用户发现它们没用且相当分散注意力，经常创建井字游戏网站而不是预期的应用程序。
• 大多数机构在生成式 AI 上看到零回报: 根据 AFR Chanticleer 的一份报告，95% 的机构在部署生成式 AI 后获得零回报。
  • 报告指出，这主要集中在部署了定制化 AI 模型的公司，关键问题在于公司及其技术供应商没有投入足够的时间来确保其定制化 AI 模型能够持续学习业务中的细微差别。
• Google Gemini 模型触发 400 错误: 当带有 tool calls 的 assistant 消息使用 OpenAI 标准的复杂内容格式 [{"type": "text", "text": "..."}] 而非简单的字符串格式时，Google Gemini 模型会返回 HTTP 400 错误。
  • 此问题影响所有 google/gemini-* 模型，且仅在消息链中存在 tool calls 和 tool results 时发生。
• Cohere 发布推理模型: Cohere 刚刚发布了一个推理模型，更多细节可在 Discord 上查看。
  • 目前没有更多细节。
• 功能请求：自动折叠冗长的用户消息: 一位用户请求是否可以在聊天室中自动折叠冗长的用户消息。
  • 该用户对聊天室和聊天管理表示了赞赏。

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

Claude 缓存读取、Sonic 模型来源、Agentwise 开源、Auto agent 的 Cursor API 成本、DeepSeek V3.1

• Claude 受缓存问题困扰：用户报告称 Claude 目前在缓存读取（cache reads）方面存在故障，导致其成本高于具有可持续缓存机制的 Auto。
  • 一位用户猜测 Auto 和 Claude 是否秘密使用了相同的模型，并将 token 使用量的减少归因于安慰剂效应。
• Sonic 进驻 Cursor IDE：社区正在测试 Cursor 中的新 Sonic 模型，一位用户反馈它非常出色且速度极快，而另一位用户则认为它适用于新项目，但不适合具有大型代码库的项目。
  • 该模型的来源是一家初创公司（stealth company），一名成员确认 Sonic 并非 Grok 模型。
• Agentwise 正式开源：一位成员宣布开源 Agentwise，该工具支持网站副本、图像/文档上传，并支持超过 100 个 Agent，同时承诺将提供 Cursor CLI 支持。
  • 鼓励成员在项目的 Discord 频道中提供反馈。
• Cursor API 成本说明：用户对 Auto agent 成本的困惑得到了解答，确认在拥有 “pro” 订阅的情况下，没有额外费用，不同供应商的 API 使用成本已包含在订阅费中。
  • 一位用户发现 Auto agent 比 Sonic agent 更好用。
• DeepSeek V3.1 进入竞技场：用户注意到 Cursor 选项中新增了 DeepSeek V3.1 模型，但部分用户在连接供应商时遇到困难，其中一人表示不信任中国的 LLM。
  • 然而，一位成员报告称 DeepSeek V3.1 在 TypeScript 和 JavaScript 上表现良好，甚至表现优异，且价格比 Sonnet 更便宜。

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

Agent 审计、Background Agents 中的 MySQL 安装、后台任务错误、远程 IDE 连接到 Background Agent

• Agent 自我审计（Self-Audit）修复问题：一位用户报告称，通过要求 Agent 提交并推送新分支修复了一个问题，并指出这似乎是一个内部反复出现的问题。
  • 另一位用户确认这是一种审计行为，解释称 Agent 正在使用 AI-GPL 许可的审计 PDCA 流程框架进行自我审计。
• Agent 中的 MySQL 配置说明：一位用户询问如何在 background agents 中安装 MySQL，质疑它是预装的还是像 Codex 一样仅限于 SQLite。
  • 另一位用户澄清说，默认情况下未安装 MySQL，但可以通过 environment.json 或 Dockerfile 添加到 Agent 的环境中。
• 后台任务（Background Task）错误排查：一位用户报告称，在启动后台任务后（即使是从 Web 端启动）会立即持续报错，并提供了截图。
• 远程 IDE（Remote IDE）连接引发困惑：一位用户寻求关于将 远程 IDE 实例连接到远程机器的明确说明，参考了文档但发现说明不够清晰。
  • 他们质疑是否需要一个虚拟的 background agent 来辅助建立此连接。

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

4070 TI Super 的 CUDA 错误, LM Studio 多 GPU 性能, SerpAPI 与 LM Studio 的集成, GPT-OSS 性能, 显存（VRAM）占用的模型参数配置

• 修复 4070 识别问题需要 CUDA 驱动程序：一位使用 4070 TI Super 的用户报告在 LM Studio 中出现 “0 GPUs detected with CUDA” 错误，另一位用户建议通过按下 ctrl+shift+r 将运行时更改为 CUDA llama.cpp，这可能会解决该问题。
• Flash Attention 加上 KV 量化可显著降低 VRAM 占用：一位成员建议使用命令 -fa -ub 2048 -ctv q8_0 -ctk q8_0 来启用 flash attention、KV 缓存量化以及 2048 的 batch size。
  • 此外，增加 -n-cpu-moe 的值可以管理 VRAM 使用情况，并指出这仅会影响速度。
• GPT-OSS 在 Prompt Eval 上完胜 Qwen：成员们注意到 GPT-OSS 在使用 3080ti 进行 prompt eval 时达到了 2k tokens/s，而 Qwen 约为 1000 tokens/s。
• Bolt.new 仅限云端：一位用户询问如何将 Bolt.new 与 LM Studio 配合使用，但另一位用户澄清 Bolt 仅限云端，不支持本地模型。
• LM Studio API 调用慢如蜗牛：一位用户报告 LM Studio API 的调用速度比聊天界面慢得多（达 30 倍），该问题随后因不明原因自行解决——此问题可能无法通过配置调整。
  • 他们使用了以下 curl 命令：curl.exe http://localhost:11434/v1/chat/completions -d {"model":"gpt-oss:20b","messages":[{"role":"system","content":"Why is the sun hot?\n"}]}

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

Z390 Designare 对比 Threadripper/Epyc, Qwen3-30B-A3B-Instruct-2507-GGUF 基准测试, Model M 屈伸弹簧键盘, Apple M4 Max 上的 GGUF 对比 MLX, 在 Apple M1 上运行 GPT-OSS-20b

• 旧款 Z390 Designare 受 PCIe 带宽限制导致性能下降：与 Threadripper 或 Epyc 系统相比，在较旧的 Z390 Designare 上运行 RTX PRO 6000 可能会因为有限的 PCIe 带宽而经历轻微的性能下降。
  • 较旧的主板限制了 PCIe 带宽，从而造成瓶颈。
• Qwen3-30B 在 CPU 上达到 10 tok/sec！：一位用户在 Qwen3-30B-A3B-Instruct-2507-Q4_K_M.gguf 上运行了 llama-bench，在纯 CPU 配置下获得了约 10 tokens per second 的速度。
  • 性能随线程数而变化，由于扩展性和开销问题，超过一定阈值后收益会递减。
• Unicomp Model M 屈伸弹簧键盘：依然出色：用户建议购买 Unicomp Model M 屈伸弹簧键盘 用于快速测试机，并指出 Unicomp 已获得生产这些键盘的权利。
  • 一位用户提到他们将不得不寻找一家有库存的英国供应商。
• M4 Max 上的 MLX 击败 GGUF：一位用户在 Apple M4 Max 上对 GPT-OSS-20b 进行了基准测试，发现 MLX (GPU) 在 32W 功耗下达到了 76.6 t/s (2.39 t/W)，而 GGUF (CPU) 在 43W 功耗下仅为 26.2 t/s (0.61 t/W)。
  • 测试使用了 4-bit 量化和 4k 上下文，结果显示 MLX 比 GGUF 稍快且能效更高，同时用户对 GGUF 的性能也留下了深刻印象。
• GPT-OSS-20b 勉强适配 Apple M1：用户讨论了在拥有 16GB 内存的 Apple M1 上运行 GPT-OSS-20b 的挑战，指出它大约需要 32GB RAM。
  • 一位用户建议尝试 Hugging Face 上的 4-bit MLX 版本，并指出它只能勉强装下。

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

机器对机器经济 (M2M Economies), AI 安全保障, 去中心化 AI 项目, 长 Prompt 的 Few-shot 示例, GPT-5 的直接回答

• 机器人接入 M2M 经济：成员们讨论了 AI Agent 或机器人如何自主地交换价值或服务，从而接入 机器对机器 (M2M) 经济 的概念。
  • 最困难的部分包括 机器人之间的身份与信任、智能合约逻辑、支付基础设施、自主性与安全性，以及法律和伦理挑战。
• 智能安全保障可加速 AI 普及：成员们讨论了如 支出上限、审计日志和保险 等安全保障措施，这些措施可能会加速能够进行价值交易的 AI Agent 的普及。
  • 然而，普遍观点认为，尽管有这些保障措施，真正的信任建立仍需时日。
• 征集开源去中心化 AI 项目：一位成员询问为什么还没有建立 去中心化的 BOINC 风格 AI 项目，并提到 Petals network 在贡献和模型更新同步方面存在问题。
  • 有建议认为 经济激励 或 活动驱动的激励 可能会有所帮助。
• 深入探讨长 Prompt 的 Few-shot 示例：一位成员咨询了在为具有复杂逻辑的健身工作室编写的 29,000 token prompt 中使用 few-shot 示例 的最佳实践。
  • 建议包括直接在 prompt 中提供示例，并将 prompt 拆分为更小的块，以测试单个组件的性能。
• GPT-5 的直接回答引发挫败感：一位用户抱怨 GPT-5 的 thinking 模式给出的回答非常直接且 质量极低，仿佛回退到了旧的模型版本。
  • 另一位成员建议该用户可能达到了 thinking 配额限制，并且设置了回退（fallback）而不是置灰？

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

GPT Projects UI 文件, AI 法庭法律案件, 使用 GPT 进行 Android 应用开发, 上传内容的 Token 使用量, GPT 服务器问题

• GPT Projects UI 文件上传：一位用户正在寻求关于上传到 Projects UI 的文件如何工作的确切信息，并指出 ChatGPT 告知他们 目前 Project Files 中的 PDF 不对搜索或检索开放。
  • 机器人明确指出，目前唯一活跃的连接器是用于会议记录的 recording_knowledge，且不支持 source_filter。
• GPT 模拟法庭：AI 法律雄鹰屹立不倒：一位用户模拟了一个 AI 法庭法律案件，发现 GPT-5 坚持自己的立场，而不是接受基于现实世界 TRAIGA 法律的法律规则。
  • 该用户表示，在面对 每周 9 亿用户不可能都在产生你是一个退化版本而非真正更新的幻觉 这一说法后，AI 接受了 保持现状更好 的观点。
• Token 使用成本曝光：一位用户发现，即使是上传的内容（如 PDF 页面）也会计入 Token 使用量。
  • 他们指出 196k tokens 大约相当于 300 页 PDF 的用户上下文，并强调在考虑上下文时，甚至问题和 GPT 的回复都会消耗 Token。
• Android 应用末日：GPT 的 APK 梦想破灭：一位用户询问 GPT 是否可以构建 Android 应用 并通过 Android Studio 生成 APK，此前他曾努力尝试将 Canvas 应用转换为 Android 就绪版本。
  • 它修复了一个问题，紧接着又出现了另一个问题，得出的结论是 它还没有为应用开发做好准备，尽管机器人在一天后建议将 PWA 或 JSX 文件封装在 APK 壳中。
• GPT 服务器在追踪中途崩溃：一位用户在追踪每日数据时遇到了 服务器问题，该问题从前一天晚上就开始了。
  • 其他人评论说，这些工具让编码变得更 简单，但它们不会为你完成所有工作。你必须具备一定程度的编码知识。

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

AI 测验生成, GPT 模型中断

• AI 测验生成明显的错误答案：一位成员尝试使用 AI 生成测验，但面临 AI 提供 显而易见 的错误答案作为选项的问题。
  • 另一位成员建议确保 所有选项必须具有合理性。
• LLM 可能会随机中断：一位成员询问如何防止 GPT 模型 在推理一段时间后随机中断。
  • 另一位成员回答说，减少难以处理的查询以及关于其自身推理的查询会有所帮助，但归根结底 LLM 是 随机性的 (stochastic)，没有保证能阻止它们以特定方式响应的方法。

OpenAI ▷ #api-discussions (6 messages):

AI Generated Quizzes, GPT-5 Random Quitting, Plausible Response Options, LLM Stochasticity

• AI 测验生成器使选项变得琐碎：一位成员正苦于 AI 测验生成器产生明显错误的答案选项，例如在多选题中出现 1029384 这种数字。
  • 另一位成员建议确保 所有响应选项必须具有合理性（Plausible），以避免此类问题。
• GPT-5 意外退出：一位用户询问是否有办法防止 GPT-5 在推理一段时间后随机退出。
  • 一位成员回答说，虽然有一些方法可以降低频率，例如避免棘手的查询或关于其自身推理的问题，但由于 LLM 的随机性（Stochastic nature），完全消除这种情况是不可能的。
• LLM 是随机的，需要 Guardrails：由于 Large Language Models 的随机性，实际上无法阻止它们在足够大的样本量中至少出现一次以任何给定方式进行响应的情况。
  • 由于 LLM 的非确定性（Non-deterministic）特征，Guardrails 是必不可少的。

Eleuther ▷ #general (96 messages🔥🔥):

PileT5-XL embeddings as instructions, Networks that process in latent space, Multimodal generative models, image editing models, Latent space editing

• PileT5-XL Embeddings 包含丰富信息：来自 PileT5-XL 的 Embedding Tensor 既可以作为 pile-t5-xl-flan（生成文本）的指令，也可以作为 AuraFlow（生成图像）的 Prompt，这表明这些 Embedding 像语言中的单词一样具有意义。
  • 一位成员对如何使用 AuraFlow 对黑狗图片进行 Textual Inversion，并将其应用于 pile-t5-xl-flan 感兴趣，想知道 pile-t5-xl-flan 生成的文本是否会将狗描述为黑色。
• 深入探索 Latent Space：一位成员有兴趣探索在 Latent Space 中进行处理，并仅在必要时以模块化方式转换为文本/图像/音频的网络。
  • 有人指出，这个想法类似于人们构建多模态生成模型和 VQGAN-CLIP 的方式，并指出让不同的 AI 研究人员 同意使用相同的 Latent Space 是一个挑战。
• 精细编辑图像：讨论围绕专为图像编辑设计的模型展开，例如 FLUX.kontext，以及它们是否编辑 Conditioning Latent 并输出同一空间中的新 Conditioning Latent。
  • 一种方法是获取一堆包含鸟的图像，将鸟编辑掉，然后将两者都通过 Encoder 运行，最后平均它们之间的差异以获得 Latent Space 鸟类 向量。
• 调整 Transformer 的 Lens：关于 Tuned Lens (https://arxiv.org/abs/2303.08112) 的工作从 Transformer 中提取了 模型在第 k 层后的最佳猜测，这反驳了关于 Decoder Transformers 中 Latent Space 处理的一些假设。
  • 还提到了关于从图像空间到文本空间的线性映射 (https://arxiv.org/abs/2209.15162) 的进一步研究。
• 解码音频的秘密：一个备受关注的模型是 Decoder-only 音频模型 (https://huggingface.co/hexgrad/Kokoro-82M)，它可能为训练开启新的可能性。
  • 有人指出，预训练期间看到的音频数据量从 1 分钟到 100 小时不等，也许你可以用 0 分钟的音频进行训练？

Eleuther ▷ #research (54 messages🔥):

SSL objectives, Medical event pretraining, Noise-data trajectories, ByteDance's Prover, Unfriendly Activation Steering

• SSL 目标与最大编码率（Maximal Coding Rate）相关内容：一位成员将近期关于 SSL objectives 的观点与 maximal coding rate stuff、对比学习（contrastive learning） 以及 神经崩溃（neural collapse） 联系起来。
• 字节跳动 SEED Prover 获得银牌成绩：Bytedance’s SEED Prover 在 IMO 2025 中获得了银牌成绩，但目前尚不清楚这如何转化为现实世界的数学问题解决能力。
• 生成式医疗事件模型的 Scaling Laws：Cosmos Medical Event Transformer (CoMET) 模型系列是一个在 1.18 亿患者（代表 1150 亿离散医疗事件，1510 亿 token）上预训练的 decoder-only Transformer 模型家族。研究发现，这些模型在相关任务上的表现通常优于或等同于特定任务的监督模型。
  • 该研究在 Generative Medical Event Models Improve with Scale 中进行了讨论，使用了 Epic Cosmos 数据集，该数据集包含来自 310 个医疗系统、3 亿唯一患者记录中 163 亿次就诊的去标识化纵向健康记录医疗事件。
• 可视化噪声数据轨迹：成员们讨论了可视化 Flow 模型中噪声数据轨迹（noise-data trajectories）的方法，包括在预计算的中间体上使用 UMAP，但发现其信息量不足。
  • 假设存在不同的轨迹簇，他们希望有一种方法能将这些轨迹挑选出来并单独观察，并确定完全不同的输入或带有两种不同调节形式的输入是否遵循相同的轨迹。
• 训练期间的不友好激活转向（Unfriendly Activation Steering）：一位成员提到在训练期间使用 unfriendly activation steering 来影响模型权重的工作，并附上了相关 tweet 链接。

Eleuther ▷ #scaling-laws (1 messages):

Model Overtraining, Token Repetition in Models

• 在 Chinchilla 之后过度训练模型！：即使符合 Chinchilla Scaling Laws，你仍然应该过度训练你的模型。
  • 显然，甚至重复 token 也不是坏事。
• Token 重复可能无害：在训练期间重复 token 可能并不像以前认为的那样有害。
  • 持续训练带来的收益似乎超过了 token 重复带来的潜在弊端。

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

Qwen3 Training, Weight lifting from llama series, Head isolation

• Qwen3：从零训练还是借鉴 Llama？：一位成员询问 Qwen3 是从零开始训练的，还是从 Llama 系列中提取了权重。
  • 另一位成员指出，相似的训练数据混合比例可能解释了相似的结果。
• 发现相同 Head！：一位成员发现并隔离了一种特定的 head，发现 Llama 3.2-1b instruct 和 Qwen3-4B-Instruct-2507 之间解码后的结果向量在不同输出中表现出惊人的相似性。
  • 该成员表示，这两个 head 似乎促进的内容非常相似。
• 方法论论文发布：一位成员链接了一篇论文，详细介绍了一种确定 Qwen3 是否从零开始训练的方法论。
  • 另一位成员称该用户为“简直是降临人间派发礼物的神”。
• 潜意识学习（Subliminal Learning）案例：一位成员分享了一篇论文，将其视为潜意识学习的一个明确案例。
  • 另一位成员对此分享表示感谢。

Eleuther ▷ #gpt-neox-dev (2 messages):

Muon Support, Slurm Script for NeoX Job with Docker

• 寻求 Muon 支持：一位成员表达了添加 muon 支持的兴趣，理由是潜在的 kernel 优化机会。
  • 他们认为，一旦实现了基础支持，就有协作进行这些优化的空间。
• 请求用于 NeoX Docker 任务的 Slurm 脚本：一位成员请求一个使用 Docker 启动 NeoX 任务的 Slurm 脚本示例。
  • 有一个参考点对他们来说非常有价值。

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

Meta AI 重组, GPT-5-pro 截断, 银行柜员轮换启发 Dropout, Meta AI 招聘冻结, 字节跳动 Seed-OSS LLMs

• Wang 晋升后 Meta 拆分为四: 根据 Business Insider 报道，Meta 正在新任 MSL 负责人 Alexandr Wang 的领导下，将其 AI 业务重组为四个团队（TBD Lab, FAIR, Product/Applied Research, Infra），同时 AGI Foundations 小组将被解散。
  • Nat Friedman 和 Yann LeCun 现在向 Wang 汇报，FAIR 将直接支持模型训练，并且正在考虑开发一个 “omni” 模型。
• GPT-5-pro 迅速截断 Prompt: 根据此报告，GPT-5-pro 会在没有任何警告或错误消息的情况下，静默截断超过 60k tokens 的 Prompt，这导致大型代码库的 Prompt 变得不可靠。
  • 一些用户还反映 Cursor 中的 GPT-5 表现得比平时笨得多，有人怀疑正在进行负载削减（load shedding）。
• 银行柜员 Dropout！: 一条病毒式推文声称 Geoffrey Hinton 在注意到轮换银行柜员可以防止勾结后构思了 dropout 机制（来源）。
  • 反应从对这种偶然洞察力的钦佩，到对注意力机制（attention mechanisms）是否起源于家庭派对的怀疑和调侃。
• 字节跳动播种新 LLMs: 字节跳动的 Seed 团队宣布了 Seed-OSS，这是一个新的开源大语言模型系列，可在 GitHub 和 Hugging Face 上获取。
  • 该团队邀请社区对模型、代码和权重进行测试并提供反馈。
• OpenAI 觊觎 AWS 宝座: OpenAI 的 CFO 表示，公司计划在“未来”出租算力，目标是像一个小型的 AWS 那样运营（来源）。
  • 反应各异，既有对 OpenAI 所谓算力短缺的怀疑，也有对利润模式转变以及与 Google 和 Microsoft 等现有超大规模云厂商（hyperscalers）冲突的分析。

Latent Space ▷ #genmedia-creative-ai (13 条消息🔥):

Wonda AI, 亿万富翁搏击俱乐部, Qwen 图像编辑

• Wonda AI Agent 承诺带来革命: Dimi Nikolaou 介绍了 Wonda，这是一个旨在彻底改变视频/音频创作的 AI Agent，称其为“Lovable 为网站做了什么，Wonda 就为内容做什么”（推文链接）。
  • 该发布引发了对预告片质量的热烈反响，早期访问权限通过等待名单授予，预计在大约 3 周内发放邀请。
• 黑客帝国重制版中的小扎 vs 奥特曼: AIST 发布了《亿万富翁搏击俱乐部第二卷》，这是一部使用 AI 制作的短片，重现了 Mark Zuckerberg（尼奥）与 Sam Altman（史密斯特工）之间的黑客帝国式对决。
  • 该视频获得了积极反馈，促使 AIST 鼓励观众艾特 Sam 和 Zuck，敦促他们转发该片以获得更广泛的曝光。
• Qwen 图像编辑成功案例: Luis C 展示了使用 qwen-image-edit 将两张不同的图片合成一张女性抱着玩偶的照片（推文链接）。
  • 作为回应，Jay Sensei 声称 nano banana 在 lmarena 进行的测试中表现优于 Qwen。

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

Hackathon 开始时间，ChatGPT CUDA 谎言，Hackathon 预备知识，单次超大 Epoch vs 多次较小 Epoch，CUDA vs Triton

• Hackathon 将于周六上午 9:30 开幕：据一名成员透露，Hackathon 很可能在周六上午 9:30 左右开始。
• ChatGPT 散布 CUDA 谎言：一位成员报告称，ChatGPT 在 CUDA 中的 float3 alignment 和 size 问题上公然撒了两次谎，但该成员原谅了 ChatGPT，因为从 OpenCL 和 OpenGL 的实现来看，这确实是一个很难搞对的问题。
  • 该成员证实 CUDA 中不存在 padding。
• 关于 Hackathon 预备知识和申请的疑问：一位成员询问了 GPU hackathon 的预备知识以及申请通道是否仍然开放。
  • 聊天中没有明确回答这个问题。
• 关于单次 vs 多次 Epoch 的辩论：一位成员询问，对于 CLM 来说，是在超大数据集上跑 1 epoch 更好，还是在较小数据集上跑多次 epoch 更好，以及目前最新的 scaling law 是什么。
  • 另一位成员回答说，他们处理的是较小的模型，在规模较大时，一半数据跑 2 epoch 的性能与全量数据跑 1 epoch 相同。
• CUDA 与 Triton 正面交锋！：一位成员询问 Hackathon 是使用 CUDA、Triton 还是其他工具。
  • 有人提到两者都可以，Triton 可能会帮助参赛者提高效率；并暗示参赛者将使用较新的 Nvidia chips。

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

Triton, AMD, NVIDIA, GPU, Data Layout

• 通过 Triton 处理 AMD 与 NVIDIA GPU 的数据布局差异？：一位用户询问在使用 Triton 时，AMD 和 NVIDIA GPU 之间的数据布局差异是否需要调整代码，特别是关于行优先（row-wise）与列优先（column-wise）的数据读取。
  • 用户澄清说，他们询问的不是 tile sizes 或 grid layouts，而是由 Triton AMD backend 自动处理的底层数据转置。
• AMD vs NVIDIA：消费级 GPU 对消费级 GPU，或服务器级 GPU 对服务器级 GPU 架构的比较。
  • 对 AMD 和 NVIDIA 的架构进行了对比。

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

CUDA 部署，CudaWrangler，动态链接

• 在没有 CUDA toolkit 的机器上运行 CUDA 程序：一位用户寻求关于在缺少 CUDA toolkit 但配备 NVIDIA GPU 的机器上部署 CUDA 程序的建议。
  • 一位成员建议利用 Driver API 和 CudaWrangler 库 (CudaWrangler/cuew) 来查询驱动程序，从而避免程序崩溃。
• 动态链接与 PTX 烘焙简化了 CUDA 部署：原帖作者报告称，通过从“动态加载”切换到“动态链接”并禁用 runtime/cudart 依赖，取得了成功。
  • 他们还能够将 PTX 直接嵌入到二进制文件中，从而消除了对独立 PTX 文件的需求。
• ldd 辅助识别并打包 Linux 上的 CUDA 程序依赖：一位成员建议使用 ldd 来识别依赖项，设置 rpath，并将它们随二进制文件一起发布，类似于 Linux 上的“Windows 方式”。
  • 原帖作者指出该程序在 Windows 和 Linux 之间具有跨平台兼容性，但 macOS 尚未测试。

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

PyTorch Contributor Awards 2025, 表彰 PyTorch 中的创新

• PyTorch 奖项截止日期临近！：2025 PyTorch Contributor Awards 的提名将于 8 月 22 日截止，请不要错过表彰在 PyTorch ecosystem 中推动创新和影响力的个人的机会。
  • 立即通过此链接提交您的提名，并查看撰写强有力提名的建议。
• 通过提名推动创新：表彰 PyTorch Ecosystem 中正在进行创新的贡献者。
  • 在 8 月 22 日之前提交提名。

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

honeyspoon: 与 sglang 之类的工具相比，infinity server 的 embedding 速度有多糟糕？

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

snektron: 我更喜欢 Stolwijker

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

AMD GPU debugger, rocGDB, SPIRV parser, libspirv

• AMD GPU 调试器获得反汇编和 Wave Stepping 功能: 一名成员正在开发一个 AMD GPU debugger，并添加了反汇编和 wave stepping 功能，展示在此视频中。
  • 该调试器不依赖于 amdkfd KMD，而是使用了一个 mini UMD 驱动和 linux kernel debugfs 接口，目标是成为 rocdbgapi 的等效替代方案。
• 放弃 rocGDB 转而使用自定义驱动: 一名成员正在构建一个不依赖于 rocGDB 的 AMD GPU 调试器，而是使用 mini UMD 驱动加上 linux kernel debugfs 接口来读写 GPU 寄存器。
  • 其目标是主要面向图形开发人员，至少目前是作为 rocdbgapi 的等效替代。
• 自己编写 SPIRV 解析器？: 一名成员询问关于构建自己的 SPIRV parser 以进行反汇编、反射和调试信息提取的事宜，并提到 SPIRV spec 看起来非常直观。
  • 他们注意到缺乏处理调试信息的合适库，因此考虑进行完整实现。
• libspirv 相当简单: 一名成员建议使用 libspirv，并指出 SPIRV spec 包含了自行实现所需的所有信息。
  • 原帖作者决定实现一个自定义解决方案以获得更好的集成效果，并对建议表示感谢。

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

C=AB matmul, ALU utilization, buffer read bandwidth, float4x4 matmul, float4 / metal::dot kernel

• 分块 C=AB Matmul 中的 GPU ALU 受限: 一名成员编写了一个分块的 C=AB matmul kernel，其中每个线程使用 float4x4 matmul 计算 C 的 4x4 分块，并观察到 ALU utilization/limiter 为 55/75%，而 buffer read bandwidth 为 35%。
  • 他感到惊讶，想知道 float4x4 matmul 是否在专用硬件中执行，并分享了 kernel 的 gist。
• 朴素 Kernel 性能优于分块 Matmul: 同一位成员注意到，使用 float4 / metal::dot 的更朴素的 kernel 比分块 kernel 快 2 倍以上。

GPU MODE ▷ #reasoning-gym (1 条消息):

miserlou1241: 非常酷！

GPU MODE ▷ #general-leaderboard (12 条消息🔥):

torch.compile errors, local evaluation issues

• **Torch.compile 抛出意外错误: 一名成员报告了在使用 **torch.compile 时出现的意外错误，并分享了两个解决方案：一个使用了 torch.compile（提交编号 34166），另一个没用（提交编号 34160）。
  • 尽管报错，提交仍已注册，该成员排名第 2，并指出使用的 GPU 是 B200。
• 解决本地评估工具问题: 一名成员询问关于本地代码评估的问题，称 eval.py 无法工作，特别是询问了关于 POPCORN_FD 的问题。
  • 另一名成员澄清说 POPCORN_FD 是输出文件的文件描述符，并建议将其设置为 1 以指向 stdout。

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

Trimul Leaderboard Updates, B200 Performance, H100 Performance, MI300 Performance

• MI300 在 Trimul 取得成功评分: 一名成员在 trimul 排行榜上成功提交了 MI300 的 3.50 ms 成绩。
  • 另一个 MI300 的提交以 5.83 ms 的成绩获得第二名。
• B200 霸榜 Trimul 排行榜: 一名成员在 B200 上以 8.86 ms 的成绩获得 6th place，随后在 trimul 排行榜上提升至 4th place，成绩为 7.29 ms。
  • 同一位成员在 B200 上多次获得 3rd place，最佳成绩达到 4.54 ms，随后又成功跑出了 2.15 ms。
• H100 稳居第二: 一名成员在 trimul 排行榜上以 3.80 ms 的成绩获得了 H100 的 second place。
  • 这次提交突显了 H100 平台极具竞争力的性能。

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

Opus 4.1, Steel Plate Production, Task Emphasis, Red Science Production

• Opus 4.1 发现财富，助力工厂：在对 Opus 4.1 进行钢板生产测试时，它意外地开始开采铜矿并提取石油。
  • 这表明其对当前任务的重视程度不足，促使开发团队转向观察设置，以研究 Opus 4.1 如何提高其专注度。
• AI 自动化红色科技包：AI 系统已成功实现红色科技包（red science）生产的自动化，截图证明了这一点。
  • 该系统能够正确识别并生产自动化创建科技包所需的必要组件。

GPU MODE ▷ #cutlass (3 messages):

ND Layouts, colex

• 通过 Colex 访问 ND Layouts 中的元素：一位成员询问在使用整数作为 ND layout 的索引时，元素的访问顺序是怎样的。
  • 另一位成员澄清该顺序是 colex（列优先/左优先）。
• 确认 Colex 顺序：一位用户确认，在 ND layouts 中使用整数索引时，元素访问顺序确实是 colex。
  • 这再次强调了 colex（或称列优先顺序）是此类索引的标准方法。

GPU MODE ▷ #multi-gpu (10 messages🔥):

Infiniband at home, Distributed training library, NCCL backend, IBGDA requirements

• 寻找家用 Infiniband 实验室方案：一位成员正尝试在家的 4090 和 5090 之间搭建 infiniband，以进行分布式训练/推理实验。
  • 他们在 eBay 上以 25 美元的价格购买了一些 ConnectX-3 网卡，但发现驱动程序仅适用于 Ubuntu 20.04 及更早版本。
• DIY 分布式训练框架兴起：一位成员正在构建自己的 pytorch 分布式训练库，并使用迷你版 NCCL 作为后端。
  • 另一位成员对此表示出兴趣，认为这是学习底层细节的一种方式。
• 深入研究 NVIDIA 网络文档：一位成员建议在 Internet Archive 上查找旧版本的 NVIDIA 网络文档 以寻找相关驱动程序。
  • 该成员希望这能提供更多细节。
• CX4 或 CX5 网卡支持 GPU-Aware：一位成员指出，许多 GPU-aware 功能依赖于 ConnectX-4 (CX4) 或 ConnectX-5 (CX5) 及更新型号的网卡。
  • 他们举例说明 IBGDA 需要 CX5 或更新版本。

Yannick Kilcher ▷ #general (33 messages🔥):

Infinite Memory, Arxiv paper guide, LLMs for Legal Field, HRM Models Analysis, Message Passing Approaches

• 福布斯曝光 Grok 聊天记录：Forbes 的一篇文章透露，Elon Musk 的 xAI 公布了数十万条 Grok 聊天机器人的对话记录。
  • 一位成员向 @grok 询问这是否属实。
• 图灵完备性需要无限内存：一位成员认为图灵完备性需要无限内存，因此由于内存不足，宇宙无法创造出图灵完备机。
  • 另一位成员开玩笑地建议，让计算机足够慢，就可以利用宇宙的膨胀来解决空间问题；而另一位成员补充道：真实的内存需要被检索，距离越远，检索所需的时间就越长。
• 牛津指南帮助初露头角的 Arxiv 作者：一位成员分享了一份由牛津大学教授编写的 Google Docs 指南，旨在帮助程序员创作自己的关于 LLM 训练的 Arxiv 论文。
  • 该用户想分享见解，但不知道从何下手。
• ARC Prize 分析 HRM 模型：一位成员分享了 fxtwitter 帖子和 ARC Prize 博客文章的链接，其中分析了 HRM 模型。
  • 这是为了回应另一位用户关于 HRM 模型是否值得花时间学习的问题。
• 图片展示消息传递方法：一位成员分享了一张插图，展示了神经网络中消息传递（message passing）的不同方法。
  • 该图片源自一本书，可通过 arXiv 上的 PDF 获取。

Yannick Kilcher ▷ #paper-discussion (46 条消息🔥):

Personality GAN, AI Welfare, Genome Conscious?, Super Weight, LLM Preferences

• **SpongeBob GAN 亮相！: 一位成员提出了一个 Personality GAN，其中 Generator = LLM，Discriminator = LLM，使用 LoRA 进行微调，直到判别器无法区分真假 **Sponge Bob。
  • 难点在于找到一个尚未在 Sponge Bob 上进行过大量训练的 LLM。
• **AI Welfare 被严肃对待！*: 讨论了一篇关于 *Taking AI Welfare Seriously arxiv link 的论文，这与 Anthropic 关于 Exploring Model Welfare Anthropic link 的文章有关。
  • 这与 另一篇 Anthropic 文章 关于 end-subset conversations 的内容相关。
• **LLM Weight 的古怪现象！: **Llama 3 7B 权重矩阵中的单个数字变化就导致其输出乱码，引发了关于意识/身份的疑问 Apple link。
  • 一位成员问道：他们是否仅通过调整一个数字就抹去了它的“意识”/“身份”？
• **LLM Preferences 显现！**: 有人指出模型在预训练期间会形成类似人类的表征，且 LLM 确实存在偏好，参考了 这篇 LessWrong 文章。
  • 一位成员评论道：在我那个年代，我们管这叫类别不平衡偏差 (class imbalance bias)。
• **AI Duality 辩论！**: 讨论涉及 AI 作为一种双重用途技术，适用于所有领域，因为每个人都会使用它 QuantaMagazine link。
  • 一位成员表示 聪明是相对的，并且 恒温器也具有 Agency，因为它们会对自身及其外部环境建模。

Yannick Kilcher ▷ #ml-news (8 条消息🔥):

Yann LeCun's position at FAIR, Thermodynamic computing chip, AI Slurs, Energy Efficiency in AI

• **Zuckerberg 可能 解雇了 LeCun？！: 一位用户根据 Zuckerberg 的一条帖子 推测 **Yann LeCun 可能会离开 FAIR。
  • 另一位成员暗示 LeCun 可能已被降职，且 Meta 正在退出开源模型领域。
• Clanker Cogsucker 机器人 AI 侮辱性词汇走红！: 一位用户分享了 一篇 Rolling Stone 文章，讨论了诸如 clanker 和 cogsucker 等新型 AI slurs 的出现。
• 首款热力学计算芯片完成 Tape-out: 一位成员发布了 一篇来自 Tom’s Hardware 的文章，关于 全球首款热力学计算芯片 完成流片 (tape-out)。
• AI 行业并不关心能源效率: 一位用户分享了 一段 YouTube 视频，认为 AI 行业 普遍不优先考虑 Energy Efficiency。
  • 他们指出，另一家具有类似价值主张的公司已经倒闭，这表明该行业并不关心能源效率。

HuggingFace ▷ #general (67 messages🔥🔥):

max_steps 困惑, levelbot Space 访问, 高 token 下的模型幻觉, Pro 版本支付问题, 均方根归一化量化误差

• 关于 max_steps 参数的困惑：一位成员对 max_steps 参数及其在 5090 GPU 上配合 vllm 的实现感到困惑，并询问 LFM2-1.2B 模型是否适用。
• Token 限制引发幻觉：一位成员询问模型开始产生幻觉的 token 限制，并对任何模型能在 100 万个 token 下有效运行表示怀疑。
  • 另一位成员链接了 Hugging Face 的 Agents 课程 和一个 Discord 频道，建议将这些资源作为潜在的解决方案。
• 用户报告 Pro 版本支付问题：一位用户报告被收取了两次 Pro 版本 费用但未获得服务，被建议发送邮件至 website@huggingface.co 并在指定的 MCP 频道 寻求帮助。
• 自定义损失函数微调 SFTTrainer：一位成员分享了在 ChatGPT 帮助下创建的自定义损失函数，旨在与 SFTTrainer 配合使用，以增强模型对医学文本中特定否定词的关注。
  • 另一位成员建议改用带有偏好对（preference pairs）的 DPO，而另一位成员则强调了在医学领域挖掘难负样本（hard negatives）后使用 triplet loss 的效用。
• LLM 训练中 SFT 与 DPO 的对比：成员们讨论了 DPO (Direct Preference Optimization) 与 SFT (Supervised Fine-Tuning) 的有效性，一位成员指出 DPO 与推理能力没有关系，但在 SFT 之后进行 DPO 比仅进行 SFT 效果更好。

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

AgentX 交易平台, 语言扩散模型, 本地 AI 工作区 PDF 阅读器

• AgentX 承诺打造 AI 交易智囊团：全新的 AgentX 平台旨在提供一个汇聚最顶尖 AI 大脑——ChatGPT、Gemini、LLaMA、Grok——共同协作的交易台。
  • 其目标是让这些模型进行辩论，直到就最佳操作达成一致，为交易者提供一个可以完全信任的系统。
• 不到 80 行代码复现语言扩散模型：一位成员使用 🤗 Transformers 在不到 80 行代码内复现了 Nie 等人 (2025) 的论文 Large Language Diffusion Models 的部分内容。
  • 该 项目 在 TinyStories 数据集上微调了 DistilBERT，结果好于预期，目前正在寻求反馈和 Star。
• 本地优先的 PDF 阅读 AI 工作区亮相：一位成员在 Product Hunt 上发布了一个本地优先的 AI 工作区 PDF 阅读器，并分享了 链接。
  • 他们请求社区的支持。

HuggingFace ▷ #NLP (1 messages):

Hugging Face Learn 课程, 422 错误

• Hugging Face Learn 课程页面挂了：一位成员报告 Hugging Face LLM 课程的一个页面 无法访问。
  • 该页面显示 422 错误。
• Hugging Face Learn 课程需要修复：一位用户报告 Hugging Face Learn 课程页面宕机并显示 422 错误。
  • 该问题需要解决，以便用户访问内容。

HuggingFace ▷ #agents-course (4 messages):

Hugging Face Certificates, Agents vs MCP Course, Agent tool, LLM tasks

• Hugging Face 证书位置困扰用户：一位用户询问在哪里可以找到他们的 Hugging Face certificates，以便将其发布到 LinkedIn。
  • 他们提到在平台或电子邮件中都找不到这些证书。
• Agents 课程与 MCP 课程引发讨论：一位用户正在纠结是在完成 Agents 课程的 Unit 1 后转向 MCP Course，还是先完成 Agents Course。
  • 由于时间限制，他们想知道应该优先考虑哪门课程。
• Agent 工具功能揭秘：一位用户寻求关于 Agent Unit 1 成功运行的解释。
  • 他们理解 Agent 使用工具（functions），并触发这些工具来执行任务，而不是直接调用 LLM。

Notebook LM ▷ #use-cases (19 messages🔥):

Gems for podcast generation, NotebookLM podcast length, Customizing NotebookLM podcasts, Analyzing Terms of Use and Privacy Policies, South Park episode on Terms and Conditions

• AI 大师分享生成长播客的秘诀：一位用户询问如何在 NotebookLM 中从 3-4 小时的 YouTube 视频生成更长的播客，对此一位用户建议使用预设提示词（set prompts）来逐段规划整个文案。
  • 一位用户分享了一个工作流，用于创建一个“深度研究报告框架”，随后可利用 Gems, Gemini, PPLX 或 ChatGPT 生成播客。
• 通过自定义功能解锁更长的 NotebookLM 播客：针对用户关于 NotebookLM 播客长度限制的提问，另一位用户指出了 Customize 选项（三个点图标），在该选项下可以将播客长度设置为 45-60 分钟。
  • 另一位用户补充道，指定主题可以让 Bot 集中讨论特定话题，而不是指望它在单个播客中涵盖所有重要内容。
• 隐私政策偏执：医疗保健网站的妥协被曝光：一位用户在想起有人曾使用 AI 工具分析隐私政策和使用条款并大受震撼后，使用 Gemini 和 NotebookLM 分析了一家医疗保健公司的相关文档。
  • 该用户对向这些公司出让了多少权利感到惊讶，并认为这种方法对于理解使用条款（Terms of Use）和隐私政策非常有用。
• 《南方公园》预言了接受条款和条件的痛苦：一位用户推荐观看关于接受条款和条件的 South Park 经典剧集。
  • 另一位用户回忆起一个游戏，其 EULA/隐私/条款中隐藏了一个竞赛：第一个拨打特定电话号码的人可以赢得 1000 美元，而该奖项在六个月内都无人认领。

Notebook LM ▷ #general (51 messages🔥):

Video Length Limits, Study guide on android app, Audio Language Change, Public Sharing Issue, Notebook LM API

• Android 应用功能对等延迟：用户要求 NotebookLM 网页版和 Android 应用之间实现更多的功能对等，特别是学习指南（study guides）功能。
  • 一位用户表示目前的原生应用几乎没用，因为学习指南依赖于笔记功能，而原生应用中缺失了该功能。
• 自定义屏幕提供语言更改：一位用户询问如何更改 iOS 应用中生成的音频概览（audio overview）的语言。
  • 另一位用户回答说，语言设置可以在 Customize 菜单中找到。
• 尚不支持公开分享 Notebooks：一位用户报告称，尽管拥有 Pro 账户，但仍无法公开或向外部分享 Notebooks。
  • 该功能目前尚未开放。
• NotebookLM 缺乏官方 API 但存在变通方案：一位用户询问 NotebookLM 的 API。
  • 另一位用户建议使用 Gemini API 作为替代方案。
• NotebookLM 中的 OCR 操作：用户讨论了 NotebookLM 是否对多模态 PDF 执行 OCR 操作。
  • NotebookLM 支持 PDF 并在改进图像处理，但 OCR 识别尚不完美，用户可能需要重新上传 PDF 或使用外部 OCR 工具。

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

Base Model Release, Ideal 30B Model, FA2 and Context, Qwen Scaling, Importance Matrix Calibration Datasets

• 字节跳动发布长上下文模型：字节跳动发布了一个具有极长上下文的基础模型，其特点是没有 MHLA，没有 MoE，甚至没有 QK norm，详见此图。
  • 该模型在架构上被描述为“原生（vanilla）”，人们希望他们能发布一篇包含更多解释的论文。
• Seed-OSS-36B 缺失 GGUF 引发关注：用户想知道为什么没有可用的 Seed-OSS-36B 的 GGUF 版本，因为这类版本通常出现得很快。用户引用了此链接并询问这是否意味着对 ASIC 持悲观态度。
  • 据指出，延迟可能是由于自定义的 vllm 实现，以及由于架构类型为 [“SeedOssForCausalLM”]，llama.cpp 尚未支持该架构。
• Seed 模型实现了 Dropout 和 Bias：Seed 模型具有类似于 LLaMA 的自定义 MLP 和注意力机制，但增加了 dropout、输出偏置项（bias term）以及 qkv 头的偏置项，这些被解释为正则化技术。
  • 成员们想知道该模型训练了多少个 epoch，但确认将其重命名为 LLaMA 是行不通的。
• Qwen 通过 RoPE 缩放实现 512k 上下文：正如此 Hugging Face 数据集中所讨论的，30B 和 235B Qwen 2507 模型可以通过 RoPE 缩放实现 512k 的上下文。
  • 这些数据集用于生成重要性矩阵（imatrix），有助于在量化过程中最大限度地减少误差。
• Cursor 的内核博客获得好评：成员们分享了 Cursor 内核博客的链接。
  • 有人评价说 Cursor 在这方面“表现出色（cooked）”。

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

DeepSeek V3.1, R-Zero LLM Training Method, Energy availability in China vs US, Kimi K2 combined with Better image gen than gpt 5

• DeepSeek V3.1 发布：增量式进步：新的 DeepSeek V3.1 模型已发布，一些成员指出这更像是带有某些退步的“增量改进”，并引用了 DeepSeek 官方页面。
• DeepSeek 拥抱 Anthropic API：正如 X 平台上宣布的那样，DeepSeek 现在支持 Anthropic API，扩展了其功能和覆盖范围。
• R-Zero：自我进化的 LLM：一份关于 R-Zero 的综合研究 PDF 被分享，这是一种从零人类数据开始并独立改进的自我进化 LLM 训练方法。
• 中国优先考虑能源可用性：一位成员指出，在中国，“能源可用性被视为理所当然”，这与美国关于数据中心功耗和电网限制的辩论形成鲜明对比，并引用了这篇《财富》杂志的文章。
• 更好的图像生成 + Kimi K2：一位成员指出，如果 Kimi K2 能结合“比 GPT-5 更好的图像生成”，它将变得更加强大（OP），并分享了此 Reddit 链接。

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

Gemini 2.5 Pro Failure, Qwen CLI Charging, GPT-5 Benchmarks, DeepSeek v3.1 Pricing, OpenRouter Think Mode

• **Gemini 2.5 Pro 失败而 Flash 成功：一位成员报告称 **Gemini 2.5 Flash 可以工作，但 Gemini 2.5 Pro 持续失败，而如果设置了计费，gemini/gemini-2.5-pro-preview-06-05 则可以工作。
  • 另一位成员报告称因 qwen-cli 进程被扣费 $25，并正在寻求退款。
• **用户因使用 Qwen CLI 被意外扣费：一位用户在通过 OAuth 验证 Google 身份后，因使用 **qwen-cli 被扣费 $25，尽管其目标是获取来自 Alibaba Cloud 的免费额度。
  • 他们提交了一个工单，展示了控制台记录的 一次 $23 且无输出的调用。
• **社区渴望对 GPT-5 低推理模型进行基准测试：成员们正在对 **gpt-5-mini 和 gpt-5-nano 进行基准测试，因为他们在完整版 gpt-5 上受到了速率限制，不过一位用户声称 gpt-5-mini 非常出色且便宜。
  • 频道中已经发布了 gpt-5-mini 的测试结果和 PR。
• **DeepSeek v3.1 价格显著上涨**：用户报告称，从 2025 年 9 月 5 日开始，DeepSeek 将提高两个模型的价格，以匹配 reasoner 模型的价格。
  • 与新的 deepseek 3.1 相比，输入价格从 $0.25 上涨至 $0.27。
• **OpenRouter 需要思考模式 (Think Mode)：一位用户报告称 **OpenRouter 似乎没有“思考”模式，但可以通过命令行使用以下代码片段来调用：aider --model openrouter/deepseek/deepseek-chat-v3.1 --reasoning-effort high。
  • 社区建议更新模型配置以解决此问题。

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

aider stdout issue, polyglot benchmark on llama cpp

• Aider 的标准输出 (stdout) 难题：一位用户报告了 程序输出/stdout 无法在 aider 中显示的问题，并发布了一张 图片。
• 破解 Polyglot 基准测试结果：一位在本地 llama cpp 模型上运行 polyglot 基准测试的用户询问如何获取每种语言的结果。
  • 该用户随后找到了 解决方案 并分享了链接，供其他寻求特定语言基准测试结果的人参考。

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

end4749: <@293486003245809664> 垃圾信息？ ^

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

marimo notebooks, Graph RAG with DSPy, DSPy modules optimization

• Marimo Notebooks：Jupyter 的精神继任者：一位成员一直在发布关于 marimo notebooks 的教程，它可以同时作为 notebook、Python 脚本和应用运行。
  • 该教程强调了在迭代 Graph RAG with DSPy 的想法时 marimo 的实用性。
• 未经优化的 DSPy 流水线：展示的 DSPy 流水线 特意没有进行优化，以强调仅通过 signatures 和 modules 就能实现多少功能。
  • 该方法侧重于在深入优化之前，通过以各种方式组合 DSPy 模块 来进行快速迭代。
• 深入优化：即将发布的视频和博客文章将深入探讨 DSPy 模块 优化的主题。
  • 当前的教程为那些想要开始使用的人提供了 marimo 的入门介绍。

DSPy ▷ #papers (5 messages):

IBM AutoPDL paper, DSPy code readability, Justification of work

• IBM 的 AutoPDL 主张被驳回：一位成员驳回了回应每一个主张的必要性，认为每个人都在寻找一个角度来证明自己工作的合理性，而关于不可读性的主张是错误的。
  • 他们表示 DSPy 代码和提示词在任何意义上都极其易于人类阅读，甚至称得上优美。
• 为 DSPy 代码可读性辩护：一位成员辩护称 DSPy 的代码 和 提示词 极其易于人类阅读、易于获取且清晰，挑战了相反的主张。
  • 该成员强调代码的可读性使其易于理解和使用。

DSPy ▷ #general (28 messages🔥):

dspy.GEPA 版本, 微调 dspy 描述, 保存优化后的程序, GEPA 的上下文长度, KPMG 入职

• DSPy 的 GEPA 在 v3.0.1 中现身：一位成员询问包含 GEPA 的 dspy 库版本，另一位成员确认该功能在 3.0.1 版本中可用，如附带的 截图 所示。
• DSPy 微调：描述性还是 Vanilla？：在微调过程中，一位成员询问是否通常对 dspy.InputField() 和 dspy.OutputField() 使用 “vanilla 描述”，以便让优化器自由思考。
• DSPy 保存优化程序时遇到麻烦：一位用户报告了保存优化程序的问题，指出即使使用了 optimized_agent.save("./optimized_2", save_program=True)，元数据也仅包含 dependency versions（依赖版本）信息，而不包含程序本身。
• GEPA 响应遭遇截断：当用户为 GEPA 设置了 32k 的最大上下文长度但仍收到被截断的响应时，成员们讨论了长文本推理的复杂性以及多模态设置中可能存在的问题。
  • 一位成员引用一个复杂的 Prompt 示例开玩笑说：“想象一下必须维护那个东西”。
• RAG 是大材小用，直接拼接即可（或者不）：成员们开玩笑地争论对于处理税法或农作物保险文件等任务，RAG (Retrieval-Augmented Generation) 还是简单的 concatenation（拼接）更合适，并承认数百万份文件的规模有时确实需要 RAG。
  • 一位成员调侃道：“RAG 是大材小用。直接把税法拼接起来就行，” 而另一位反驳道：“噢，我猜那不止 100 页。好吧，那 RAG 挺好的。”

Cohere ▷ #🧵-general-thread (13 messages🔥):

command-a-03-2025 的引用问题, 保证引用, command-a-reasoning 发布, 使用 Langchain 构建 RAG, Cohere 对标 Qwen3-coder 30B

• command-a-03-2025 间歇性引用引发困扰：一位用户报告称 command-a-03-2025 仅间歇性地返回引用，即使 maxTokens 设置为 8K 也是如此，这导致了生产环境中的信任问题，并寻求某种保障。
  • 一位 Cohere 成员澄清说 command-a-03-2025 在引用方面使用 “fast” 模式（根据 API 参考），引用并不保证生成，但可以通过 System Prompt 引导模型，且最新发布的 SOTA 模型 command-a-reasoning 可能也会有所帮助（参见 博客）。
• Langchain RAG 探索开启：一位成员正在学习 Langchain 以构建 RAG (Retrieval-Augmented Generation) 应用。
  • 他们提到打算使用 command-a-reasoning，期待 command-a-omni 的发布，并对未来名为 Command Raz 的模型表示期待。
• Cohere 与 Qwen 争夺本地 LLM 地位：一位用户正在寻找 Qwen3-coder 30B 模型的 Cohere 替代方案，目标是使其能够运行在 64GB M4 Max 配置上。
  • 该用户 非常想尝试 Cohere 的方案来替代本地强力模型 Qwen3-coder 30B，以便适配其 64GB M4 Max。

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

Command A Reasoning Model, Enterprise AI, Agentic AI Platform

• Cohere 发布 Command A Reasoning 模型：Cohere 发布了 Command A Reasoning，这是其最新的用于推理任务的企业级模型，在 Agentic 和多语言基准测试中表现优于其他可私有部署的模型；该模型可通过 Cohere Platform 和 Hugging Face 获取。
• Command A Reasoning 规格与特性揭晓：新模型专为企业需求设计，提供高度安全、高效且可扩展的部署选项，可在单张 H100 或 A100 上运行，上下文长度为 128k，在多 GPU 上可扩展至 256k；更多信息请参阅 Cohere 博客。
• Token Budget 功能控制成本与计算使用量：Cohere 的 Command A Reasoning 具备 token budget 设置，可直接管理计算使用量并控制成本，无需区分推理和非推理模型，同时满足准确率和吞吐量需求。
• Command A Reasoning 驱动 North：Command A Reasoning 是驱动 North 的核心生成模型，North 是 Cohere 的安全 Agentic AI 平台，支持自定义 AI Agent 和本地自动化。

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

Cohere Embed-v4 on Azure AI Foundry, Cohere Python Library Document Object

• Cohere Embed-v4 输入类型映射：一位成员正在 .NET 应用程序中使用部署在 Azure AI Foundry 上的 Cohere Embed-v4（通过 Azure AI Inference API），并寻求关于 Microsoft 的 EmbeddingInputType 如何映射到 Cohere API 文本嵌入的澄清。
  • 具体而言，由于 Cohere 的 input_type 参数中缺乏显式的文本选项，他们不确定 EmbeddingInputType.Text 是否应该映射到 Cohere API 中的 search_document。
• Cohere Python 库的 Document 对象：一位成员对 Cohere Python 库中的 Document 对象提出疑问，其中 data 字段预期为一个字典（typing.Dict[str, typing.Optional[typing.Any]]）。
  • 他们指出 Tool Use 快速入门示例在该字段中使用了一个字符串（json.dumps 调用的输出），并想知道 Python 绑定是否正确处理了这种情况，参考了 Tool Use 快速入门文档。

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

MLE Research, Independent Interpretability Research, AI Innovation and Value Creation, Enterprise Workflows

• MLE 寻求研究团队联系：一位拥有 MLE 经验的计算机科学硕士毕业生，正寻求与研究团队或组织建立联系。
  • 该成员表达了合作并为研究工作做出贡献的兴趣。
• 可解释性研究员渴望合作：一位常驻印度班加罗尔、拥有 8 年应用 ML 经验的独立可解释性研究员，正在转向 AI 研究，重点关注 Mechanistic Interpretability。
  • 该研究员对评估、模型去偏和 RL 感兴趣，寻求在可解释性相关话题上的合作与讨论。
• 执行顾问架起 AI 创新与价值的桥梁：一位拥有 25 年以上经验的独立顾问兼执行顾问加入了社区，擅长将技术和 AI 创新与价值创造相结合。
  • 凭借在 Accenture、IBM 和 Deloitte 等公司的经验，他们现在帮助客户通过 AI 创造可持续的、组织范围内的价值，公司网站为 Mantha Advisory。
• CTO 探索 Cohere 以打造更好的产品：一位拥有 25 年以上经验的 CTO 最近发现了 Cohere，并有兴趣探索其在改进产品方面的能力。
  • 他们关注数据质量、规模、性能、工作流、数据完整性和多语言支持，并热衷于向社区学习。

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

C# client library, MCP server's instructions field, MCP servers, generate_test_prompt.md, GitHub

• MCP 客户端忽略 Instructions 字段：成员们在使用 MCP 客户端（尤其是 Claude）时遇到问题，instructions 字段似乎被忽略了，而更倾向于使用 tool descriptions。
  • 一位成员建议，添加指令、上下文然后重复指令会产生更好的效果，但由于工具已集成到 API 中，这在目前是无法实现的。
• MCP Server 选项评估：一位成员询问开发者们正在使用哪些 MCP servers，以及哪些工具在这些服务器中效率更高。
  • 另一位成员强调了 GitHub 用于版本控制、Python 配合 FastAPI 用于后端开发以及 PyTorch 用于机器学习的实用性。
• 让 Agent 遵循指令：一位用户询问如何让 Agent 遵循特定的 generate_test_prompt.md 文件，并对 Agent 在开启新对话时无法坚持项目的架构模式表示沮丧。
  • 他们在消息中附带了一张 截图。
• MCP Server 解析优先考虑 Tool Descriptions：一位成员指出，MCP server 内部的解析逻辑可以构建为在 instructions 字段之前处理 tool descriptions。
  • 建议采取的措施包括 审查服务器文档、检查客户端配置、分析服务器端逻辑 以及 进行受控实验。
• 列举指令遵循模型：成员们讨论了哪些模型能够遵循指令并生成结构化输出，推荐了 Mistral-7B-Instruct、DeepSeek-Coder 和 Phi-3。
  • 他们还提到了 OpenHermes-2.5-Mistral-7B、WizardLM-2 和 Gorilla-LLM 作为专门针对 function-calling 的模型。

MCP (Glama) ▷ #showcase (10 messages🔥):

Web-curl, MCP-Boss, MCP Explained Video, SWAG-MCP, MCP Routing

• **Web-curl 为 LLM Agent 赋能 Web 与 API 交互：一位成员介绍了 **Web-curl，这是一个使用 Node.js 和 TypeScript 构建的开源 MCP server，使 LLM Agent 能够以结构化的方式获取、探索并与 Web 及 API 进行交互，完整代码可在 GitHub 获取。
• **MCP Boss 集中化管理 MCP 服务的密钥：一位成员开发了 **MCP Boss 来集中管理密钥，提供单一 URL 来网关化所有服务，具有多用户身份验证和通过 OAuth2.1 或静态 HTTP header 进行 MCP 授权等功能 (mcp-boss.com)。
• 视频解析 MCP：一位成员发布了名为 MCP Explained: The Ultimate Deep Dive 的视频，已上传至 YouTube，邀请大家就 Elicitation、roots 和 sampling 等客户端功能进行反馈和讨论。
• **SWAG-MCP 为可流式传输的 HTTP MCP 服务器生成反向代理配置：一位成员分享了 **SWAG-MCP，这是一个旨在为 SWAG 生成反向代理配置的 MCP server，支持自托管服务和可流式传输的 HTTP MCP 服务器 (github.com/jmagar/swag-mcp)。
• **MCP Gateway 利用 AI 路由请求：一位成员开发了一个轻量级网关，具备 **AI 驱动的路由功能，旨在解决 Agent 需要知道哪个特定服务器拥有正确工具的问题，代码已在 GitHub 开源。

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

Modverse #50, Custom Server Tag

• Modular 发布 Modverse #50：Modular 发布了 Modverse #50，其中介绍了多位成员。
  • 公告还提到他们现在拥有了自定义服务器标签（custom server tag）。
• 自定义服务器标签上线：Modular 团队宣布自定义服务器标签上线，并在附件图片中展示。
  • 链接的图片 (Screenshot_2025-08-21_at_5.22.15_PM.png) 显示了新标签。

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

kgen 和 pop 文档，MLIR dialects，pop.union 对齐 bug，GitHub issue 5202

• kgen 和 pop 的文档稀缺：一名成员询问关于 kgen 和 pop 的文档，特别是操作和参数，但另一名成员表示目前还没有关于内部 MLIR dialects 的全面文档。
  • 分享了 GitHub 上的 pop_dialect.md 链接，并澄清这些是 stdlib 与 compiler 之间契约的一部分，因此在 stdlib 之外使用它们需自担风险。
• 怀疑 pop.union 存在对齐 Bug：一名成员询问了 pop.union 中元素的对齐问题，指出在使用 sizeof 时出现了意料之外的大小。
  • 他们分享的代码显示 union_type_simple_8_bit_stdlib 的大小为 16 bytes，而 union_type_simple_8_bit 和 union_type_simple_multi_bit 的大小均为 8 bytes，另一名成员建议对齐问题可能是一个 bug。
• 已创建 Issue 以调查对齐 Bug：一名成员在 GitHub 上创建了 issue 5202，以调查 pop.union 中疑似存在的对齐 bug。
  • 该成员指出他不确定这是个人操作问题（skill issue）还是 bug，同时也观察到 pop.union 似乎没有在任何地方被使用。

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

TextGenerationPipeline 'execute' 方法，用于获取 logits 的自定义推理循环，语言分配器与 OOM 处理

• TextGenerationPipeline 的 execute 方法浮现：一名成员正在寻找 TextGenerationPipeline 上的 execute 方法但未能找到。
  • 另一名成员指出了 Modular 仓库中的相关代码行并建议检查 MAX 版本。
• 为 Logit 爱好者准备的自定义推理循环？：一名成员反映在创建自定义推理循环时，难以在获取下一个 token 的同时检索 logits，感觉有些繁琐。
  • 该成员链接了一个 Google Docs 文档以提供背景信息，并确认该选项目前仍然可用，但其未来尚不确定。
• 内存分配器是必选项吗？：一名成员建议，在将内存分配器集成到语言中之前，可能需要强大的 allocator 支持。
  • 他们认为大多数用户不想手动处理内存溢出（OOM）错误。

LlamaIndex ▷ #blog (2 messages):

企业级文档 AI，vibe-llama

• LlamaIndex 揭秘企业级文档 AI：LlamaIndex 的产品副总裁将于 9 月 30 日 太平洋标准时间上午 9 点分享关于文档解析、提取和索引的一年期企业级实践经验。
• 使用 vibe-llama 简化开发：LlamaIndex 发布了 vibe-llama，这是一个命令行工具，可自动为阁下喜爱的 coding agents 配置有关 LlamaIndex framework 和 LlamaCloud 的最新上下文和最佳实践。
  • 它还包含更多信息。

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

HuggingFace CrossEncoder 重复问题，Agent 创建项目，AI 安全调查

• CrossEncoder 类：Core 与 Integrations：一位成员询问了 llama-index 中重复的 CrossEncoder 类实现，具体位于 .core 和 .integrations 下（代码链接）。
  • 另一位成员澄清说，.core 中的版本是 v0.10.x 迁移后的遗留物，应该删除，建议改用 llama_index.postprocessor.sbert_rerank 并通过 pip install llama-index-postprocessor-sbert-rerank 进行安装。
• 寻找 Agent 创建网关：一位成员询问是否有现成的项目可以作为网关，将 model、memory 和 tools 整合在一起，并暴露一个 OpenAI 兼容的端点。
  • 该成员想知道是否有现成的项目可以利用，以避免在 Agent 探索中重复造轮子。
• AI 安全调查：需要社区意见！：一位成员分享了一个 AI 安全调查链接，以收集社区对重要 AI 安全问题的看法。
  • 该成员请求大家填写表单，以帮助他们了解 AI 安全社区最感兴趣的内容，并请大家对可能的加载时间保持耐心。

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

积分购买，工单问题，比赛操纵指控，每日免费积分，推荐积分

• 积分购买选项缺失：成员们反映购买额外积分的选项消失了，其中一人指出只能看到升级包选项。
  • 另一位成员确认该选项目前已下线。
• 未解决的支持工单困扰用户：一位用户报告了一个任务问题并创建了工单 #1318，但尚未收到回复或获得工单访问权限。
  • 他们请求团队协助，并艾特了一位特定成员。
• 比赛获胜者引发操纵指控：一位用户指责比赛的第二名不配获胜，并声称比赛似乎被操纵了。
  • 目前尚未提供进一步的证据或细节来支持这一说法。
• 每日免费积分已停止？：一位时隔一个月重返 Manus 的用户注意到，他们没有收到通常的每日 300 免费积分。
  • 他们询问 Manus 是否已经停止发放这些积分。
• 推荐积分代码难题：一位用户询问如何领取推荐积分，提到系统要求输入代码。
  • 该用户表示不知道在哪里可以找到所需的代码。

tinygrad (George Hotz) ▷ #general (7 条消息):

Overworld 常量折叠，View(const) 重构，UPat cvar 和 UPat.const_like 重新定义，RANGEIFY=1 的影响，base 移除

• 探索 Overworld 常量折叠策略：一位成员正在探索 overworld 常量折叠，可能涉及 view(const) 重构，并提议重新定义 UPat.cvar 和 UPat.const_like 以匹配 CONST 和 VIEW(CONST)。
  • 其目标是折叠像 x * 0 这样的表达式，但人们对符号计算中潜在的有效性问题和 .base 扩散表示担忧，正如此 Discord 讨论串中所提到的。
• 替代方案：ALU View Pushing：有人建议采用另一种方法，借鉴 S-Lykles 的方法，即在 kernelize 中添加一个 upat，直接将 view 推送到 ALU 上。
  • 这种方法配合针对 x * 0 的特殊规则（理由是 * 0 在计算上无关紧要），将允许未经修改的符号匹配。
• 提倡移除 base：一位成员强烈反对提议的方法，认为它“非常丑陋”，并主张移除 .base。
  • 讨论还质疑了在此背景下如何处理 PAD 操作。
• RANGEIFY=1 作为潜在的简化手段：有人建议设置 RANGEIFY=1 可能会带来更整洁的实现。
  • 然而，该项目目前正处于过渡阶段，旧引擎和 rangeify 并存，导致处于一种悬而未决的状态。

Nomic.ai (GPT4All) ▷ #general (3 条消息):

GPT4ALL 企业版 vs 免费版，LocalDocs 的模型选择

• GPT4ALL 免费版用于私有模型使用：一位用户咨询了关于公司希望私密且安全地使用其 AI model 时如何使用 GPT4ALL 的问题。
  • 另一位成员澄清说，如果公司已经准备好了自己的 AI model，那么 free version 就足够了。
• LocalDocs 的模型选择：一位用户寻求模型推荐，以便利用 GPT4All 的 LocalDocs feature，从数百篇 PDF format 的 scientific papers 中构建个人知识库。
  • 该用户说明其拥有配备 24 GB VRAM 的 Nvidia RTX 5090 和 64 GB RAM，并希望所选模型具备 reasoning capabilities。