AI News

Anthropic 以 1830 亿美元的估值完成 130 亿美元的 F 轮融资。

· MjAyNS0w

Anthropic 在 2025 年 9 月的 F 轮融资中实现了 1830 亿美元的投后估值，其年化营收（run-rate）从 1 月的约 10 亿美元增长至 2025 年 8 月的 50 亿美元以上。其 Claude Code 产品在三个月内实现了 10 倍以上的使用量增长，年化营收达到 5 亿美元，服务超过 30 万家企业客户，大客户数量增长了近 7 倍。Mistral AI 推出了 Le Chat，配备了 20 多个 MCP 连接器以集成主流 SaaS 平台，并具备持久记忆功能。基准测试更新显示，GPT-5 在智能体（Agent）智能指数中处于领先地位，xAI 的 Grok 和 Anthropic 的 Claude 系列也表现强劲。Galileo、OpenPipe 等公司分享了可靠性工具和智能体评估方面的进展。智谱/THUDM 开源了 Slime v0.1.0，增强了 GLM-4.5 背后的强化学习（RL）基础设施，显著提升了解码速度，并采用了先进的张量卸载技术。

#enterprise-connectors #agent-benchmarking #reinforcement-learning #inference-optimization #memory-optimization #cuda #multi-token-prediction #speculative-decoding #tensor-offload #performance-optimization #real-time-guardrails #cost-optimization claude-code gpt-5 grok-4 claude sonnet-4 glm-4.5 deepseek-r1 anthropic mistral-ai x-ai salesforce galileo openpipe zhipu thudm

祝贺 Ant 团队！

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

这早已传闻甚广，但最终估值比预期更高。以下是来自他们公告的一些显著数字：

  • 2025 年 1 月，Anthropic 的 run-rate 约为 10 亿美元。到 2025 年 8 月，它已突破 50 亿美元（当前 ARR 倍数为 36.6 倍，但 2025 年底预期倍数为 20 倍）。
  • Claude Code 于 2025 年 5 月正式发布 (GA) —— 过去三个月使用量增长了 10 倍以上，现在的 run-rate 收入已达 5 亿美元（我们在 6 月份曾提到过这一点）。
  • Anthropic 目前服务于超过 300,000 家企业客户，我们的大客户数量（每个客户代表超过 10 万美元的 run-rate 收入）在过去一年中增长了近 7 倍。

祝贺 Anthropic！

AI Twitter 汇总

Agent 系统：企业连接器、新评估与可靠性

  • Mistral Le Chat 新增 20 多个 MCP 连接器和“Memories”。Le Chat 现在可以接入 Stripe, GitHub, Atlassian, Linear, Notion, Snowflake（即将推出）等，具有细粒度的访问控制和持久、用户可编辑的记忆。这使 Le Chat 成为跨 SaaS 操作和检索的统一界面，同时保持企业级可管理性。查看来自 @MistralAI 的发布推文和 @emilygsands 的 Stripe 演示。
  • Agent 基准测试：
    • Artificial Analysis 更新了其智能指数 (V3)，纳入了 Terminal-Bench Hard 和 τ²-Bench (Telecom)。GPT‑5 领先，o3 紧随其后；xAI 的 Grok Code Fast 1/Grok 4 以及 Claude/Kimi/gpt-oss 系列在工具调用/Agent 任务中表现出色。详情：@ArtificialAnlys，后续 1，2。
    • MCP‑Universe (Salesforce) 使用真实的 MCP 服务器（Google Maps, GitHub, Yahoo Finance, Playwright 等）和基于代码的评估器，对 Agent 在 231 个真实任务中的表现进行评估。顶级模型实现了 43.7% 的成功率；性能具有高度的领域特定性；“更多工具”反而可能产生负面影响。链接：@_philschmid，论文/排行榜。

    • TAU Bench 警示：在航空公司领域，一个无工具的 SFT 基准模型可以通过“阿谀奉承”击败 Qwen3‑4B；提议通过修复来恢复工具使用信号：@_lewtun，后续，2。

      可靠性工具：Galileo 的 Agent 评估（实时 guardrails，Luna‑2）针对生产可靠性和成本，Gartner 预测到 2027 年这将导致 40% 的项目失败：@omarsar0，2，3。另请参阅“xpander” Agent 后端（内存、工具、状态、guardrails；可自托管）：@_avichawla，仓库。

      最后，OpenPipe 发布了一个通过 RL 训练深度研究 Agent 的方案，在 H200 上花费约 30 小时（约 350 美元）即可在 DeepResearch Bench 上击败 Sonnet‑4：@corbtt，后续。

高性能 RL 与推理：Slime v0.1.0, ZeroGPU AoT, symmetric all‑to‑all, 以及 4/8 位

  • Zhipu/THUDM 开源了 Slime v0.1.0，这是 GLM-4.5 背后的 RL 基础设施。亮点：FP8 rollout、DeepEP、多 Token 预测（multi-token prediction）、投机采样（speculative decoding）、通过 CUDA VMM 实现的统一张量卸载（unified tensor offload，通过 LD_PRELOAD 劫持 cudaMalloc/free）、CPU Adam、支持 Megatron + DeepEP、针对 MoE 的 GSPO。结果：GLM-4.5 (355B-A32B) 的解码速度从 <10 提升至 60–70 tok/s；用于 8 节点 GLM-4.5 和 16 节点 DeepSeek-R1 训练。巧妙的 NCCL 拆卸以回收内存；修复了 DeepEP 重叠（overlap）的边缘情况。深度解析：@ZhihuFrontier，功能清单。
  • PyTorch 对称内存（symmetric memory）+ 自定义 all-to-all：在 H100 上，使用对称内存和低争用路由的节点内 all2all 比默认方式快约 1.9 倍；@cloneofsimo 揭示了原生 PyTorch 中的巨大差距，见推文更新，以及 @giffmana 的讨论。
  • ZeroGPU AoT 编译（Hugging Face Spaces）：在部署前对模型进行提前编译（Ahead-of-time compiling）可缩短冷启动时间并提高吞吐量（据报告 FLUX/Wan 提升了 1.3–1.8 倍）。博客 + 示例：@RisingSayak，1，2。已集成到 anycoder 演示中：@_akhaliq，应用。
  • 精度/效率说明：NVIDIA 的 NVFP4 4-bit 训练消融实验引发讨论 (@eliebakouch, 后续)；INT4 Seed-OSS 模型报告在使用 vLLM 推理时“无精度损失” (@HaihaoShen)。
  • 预算约束下的自适应 LLM 路由将路由设计框架化为 Contextual Bandit，以优化单位成本的质量，支持用户预算策略：@omarsar0，论文。

模型发布与能力

  • Microsoft 的 rStar2-Agent (14B，智能体 RL) 通过 GRPO-RoC 和多阶段 SFT→RL 配方实现了尖端的数学/工具调用性能；在 64 台 MI300X 上训练了 510 个 RL 步数。得分：AIME24 80.6%，AIME25 69.8%，超过了 DeepSeek-R1 (671B)。代码：@iScienceLuvr，仓库/摘要。
  • Hermes 4 开源权重推理模型 (Nous)：基于 Llama-3.1 的 70B/405B，具有混合显式思考（<think>…</think>）、仅 Assistant 损失（assistant-only loss）、长轨迹（最高 16k）、工具感知格式、强大的数学/代码/对齐能力以及拒绝动态（refusal dynamics）。详细的训练细节和基础设施（TorchTitan/FSDP/TP、Flex Attention、DataForge）。摘要：@gm8xx8。
  • 腾讯混元 Hunyuan-MT-7B（翻译）和 Hunyuan-MT-Chimera（集成模型），支持包括 5 种中国少数民族语言在内的 33 种语言；HF/Gradio 上的演示：@_akhaliq，演示，以及 @SOSOHAJALAB。
  • 小型 VLM：R-4B (Apache-2.0) 自称是 SOTA 的小型视觉 LM，具备推理能力；通过自定义代码集成到 Transformers：@mervenoyann，模型。
  • 视频/音视频：AUSM (Autoregressive Universal Video Segmentation) 将 LLM 风格的 AR 流水线与流式视频感知相结合：@miran_heo。VibeVoice（通过 Next-token Diffusion 实现的长文本 TTS）在 64k 窗口内生成长达 90 分钟的 4 人对话，与 Encodec 相比具有 80 倍压缩率且连贯性强：@TheTuringPost。

数据、工具链与开发者更新

  • Jupyter Agent Dataset (Hugging Face)：包含来自 51k 个 Kaggle notebooks 的 2B tokens 以及 7TB 数据集，带有真实的代码执行追踪（Qwen3‑Coder + E2B）；显著提升了代码执行和数据分析能力。发布：@a_yukh，回顾：@maximelabonne。
  • LangChain/LangGraph 1.0 alpha (Py/JS)：LangGraph 仍然是底层的 Agent 编排基座；LangChain 1.0 重新聚焦于核心 Agent 抽象和标准化的内容块，保持模型和供应商的可移植性。公告：@LangChainAI，@hwchase17。
  • 向量/路由与端侧：Qdrant 增加了搜索后的相关性重评分（新鲜度/邻近度/衰减函数），以实现业务逻辑对齐 (1, 2)；ChromaSwift (beta) 通过端侧 MLX embeddings 和持久化将检索功能引入 iOS：@trychroma。
  • 代码执行易用性：Anthropic API 添加了 bash、view/create/str_replace 原语、Seaborn/OpenCV，并将容器生命周期延长至 30 天，减少了 tokens 消耗并支持更丰富的工作流：@alexalbert__，更新。
  • 简讯：Chainlit 仍然是 LLM 聊天的快速 UI 脚手架 (@rasbt)；Google 的 Gemini URL Context 可内联获取并处理多达 20 个 URL，且无需额外的工具费用 (@LiorOnAI)。

行业/平台动态

  • Anthropic 在由 ICONIQ 领投的融资中以 1830 亿美元的投后估值筹集了 130 亿美元，理由是扩大产能、提升模型能力和安全研究：@AnthropicAI。
  • OpenAI：收购了 Statsig；创始人 @vijayeraji 成为应用部门（ChatGPT/Codex）的 CTO。@kevinweil 启动了 “OpenAI for Science” 以构建 AI 驱动的科学仪器；职位说明。Realtime API 持续成熟 (技巧)；@weights_biases 通过 W&B Inference 向 OpenRouter 添加了 DeepSeek V3.1 和 gpt‑oss‑20B/120B。

研究亮点

  • Diffusion Language Models 可以“早期提交”。在 GSM8K/MMLU 上，一半的细化步骤即可识别出正确答案（97%/99% 的案例）。Prophet 是一种无需训练的快速解码方案，用于决定何时停止采样：@iScienceLuvr，摘要。
  • AHELM（音频语言评估）：涵盖 10 个维度的全面 ALM 基准测试（感知、推理、公平性、多语言、毒性等），包含新的 PARADE 和 CoRe‑Bench。Gemini 2.5 Pro 在 5/10 的项目中领先，但在 ASR 中表现出群体不公平性：@iScienceLuvr，摘要/网站。
  • DyT：不带归一化层的 Transformers（用 Dynamic Tanh 取代 LayerNorm/RMSNorm），在报告的设置中声称在视觉、语言、语音领域达到 SOTA：@LiorOnAI，摘要/代码。
  • Goldfish Loss：从交叉熵损失中随机丢弃 tokens，以减轻记忆效应，同时保留下游性能；在低数据推理 RL 的探索中可能有用：@vikhyatk，论文。
  • STREAM：一份用于透明化 ChemBio 安全评估报告的清单（例如人类基准），使同行评审变得可行：@lucafrighetti，背景。

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

  • @AnthropicAI: 融资 130 亿美元，估值 1830 亿美元 (5486)。
  • @kevinweil: 启动 OpenAI for Science (1967)。
  • @MistralAI: Le Chat 新增 20 多个 MCP 连接器和 Memories 功能 (1294)。
  • @GeminiApp: 新的图像编辑“nano‑banana”趋势，人偶风格转换 (4586)。
  • @ArtificialAnlys: Intelligence Index V3 增加了 Agent 基准测试 (577)。

AI Reddit 回顾

/r/LocalLlama + /r/localLLM 回顾

1. TerminalBench 多 Agent 编程系统与德国版 WWTBAM 基准测试

  • 我的周末项目意外击败了 Claude Code - 多 Agent 编程系统目前在斯坦福的 TerminalBench 排名第 12 😅 (Score: 567, Comments: 42): 开源多 Agent 编程系统，包含 Orchestrator（无直接代码 I/O）、Explorer（仅读取/运行）和 Coder Agent，外加一个用于共享“知识伪影（knowledge artifacts）”的持久化 Context Store。该系统使用 Claude Sonnet-4 在 Stanford/Laude TerminalBench 上达到了 36.0% 的成功率（排名第 12，领先于 Claude Code），使用 Qwen3-Coder-480B 达到了 19.25%；Sonnet-4 消耗了 93.2M token，而 Qwen 消耗了 14.7M。Orchestrator 强制执行显式授权、自适应信任（简单任务高度自主，复杂任务迭代分解）以及每个 Agent 专属的工具集；artifacts 被存储并注入到后续子 Agent 的上下文中。完整代码、Prompt 和配置已开源：Danau5tin/multi-agent-coding-system。 评论者建议测试其他快速/廉价的模型（如 grok-code-fast-1、“gpt5-mini”），并质疑工具调用选择 YAML 而非更标准的 JSON 或 Qwen3-Coder 的 XML 模式；此外，还有人支持透明且对本地模型友好的开源 Agent 工具。
    • 引用基准测试结果：Orchestrator + Sonnet-4 成功率为 36.0%（在 TerminalBench 排名第 12，领先于 Claude Code），而 Orchestrator + Qwen-3-Coder 为 19.25%。建议试用 grok-code-fast-1 和 gpt5-mini 以提高延迟/成本表现，并指出相对于 Claude Code，它们可能 “快得离谱且便宜”。
    • 一个技术问题质疑了使用 YAML 进行工具调用而非 JSON（典型的函数调用模式）或 Qwen-3-Coder 所采用的新 XML 模式。这引发了关于解析器确定性、生态系统/工具兼容性以及跨模型提供商遵循既定结构化 I/O 惯例的问题。
    • 一个关于产品化的担忧是，在 Sonnet 运行据称消耗了超过 90M token 的情况下，如何从基准测试的胜利转向实际项目并控制推理支出。该讨论探讨了预算策略，以及多 Agent 编排是否可以限制工具对话和 token 消耗，以应对日常编程工作负载。

  • 德国版“谁想成为百万富翁”基准测试 (Score: 411, Comments: 54): 原作者发布了一个德国版“谁想成为百万富翁”基准测试，包含 45 轮 × 15 个问题（每轮第一个错误答案即退出，保留奖金，无求助机会），并发布了一个结果表，对比了主要在 Framework Laptop 13 (Ryzen 5 7640U, 32GB) 上运行的本地量化 (Q4_K_M) LLM。表格显示 gpt-oss-20b (low) 以平均 €80.177 奖金和 3 次百万大奖领先，随后是 mistral-small-3.2 和 qwen3-30b-a3b-2507 等模型；参数包括温度 (T)、top-k (K)、top-p (P) 和最小阈值。早期大量涉及德国习语/双关语的问题对模型来说最难，但对人类来说很简单；由于延迟以及初步测试（如 qwen3-4b-thinking-2507）显示早期题目准确率下降，“思考（thinking）”模式大多被禁用。完整代码/结果：https://github.com/ikiruneo/millionaire-bench 评论者探讨了超参数微调——特别是温度选择（例如 T=1 与 0.15）——询问了问题来源，并要求加入非本地/托管模型以进行更广泛的对比。

  • 量化级别（Quant level）严重影响准确率，且因模型系列而异；假设统一使用 q4 可能会扭曲排名。评论者建议报告每次运行的具体量化版本（例如 q4_K_M、q5_K_M、AWQ、GPTQ），理想情况下，应对每个模型进行多个量化版本的基准测试以展示敏感度。激活感知（Activation-aware）和离群值感知（outlier-aware）方案（如 AWQ arXiv:2306.00978）通常比朴素的 4-bit 量化能更好地保留推理能力，而 GPTQ arXiv:2210.17323 和通过 bitsandbytes 实现的 4-bit NF4 HF blog 在 LLaMA 衍生模型与 Mistral 模型上的表现各不相同。在表格中包含量化信息并对其进行控制，将使跨模型比较更具公信力。
  • 实现反馈：提示词要求输出单个字母，但 API 并不限制生成内容；建议设置较短的 max_new_tokens（例如 1–5），添加停止令牌（stop tokens），或使用语法约束解码（例如 llama.cpp grammars）来强制仅输出 [A-D]（llama.cpp grammars, OpenAI logit_bias）。目前的解析方式是抓取字符串中出现的第一个大写字母，这可能会误读思维链（chain-of-thought）或标题；相反，应要求结构化的目标格式，如 Final: A 或 \boxed{A}，并使用严格的正则表达式进行解析，然后记录合规性指标：精确合规率、猜测率和“无回答”率。对于输出隐藏/可见“思考”块的模型（如 GPT-OSS），在提取之前应剥离这些部分，并验证最终答案是否与解析的令牌匹配。
  • 几次运行显示出差异巨大的温度参数（1.0 对比 0.15）；评论者建议针对每个模型进行超参数搜索（温度/top_p），并报告最佳准确率以及不同种子（seeds）间的方差。每个设置使用 3–5 次重复实验来评估稳定性，然后为每个模型选择最佳配置，以避免惩罚那些在 MCQ 任务中需要低采样噪声的模型。此外，考虑增加一种“推理许可”提示词变体（例如，答案格式为 \boxed{A} 并附带可选的简短理由），并衡量在相同的解码预算下，有限的推理是否能提高准确率。

2. ETHZ Apertus LLM 发布与 MAESTRO v0.1.5

  • 来自瑞士的新开源 LLM “Apertus”，40% 以上的训练数据为非英语 (Score: 229, Comments: 63): 苏黎世联邦理工学院（ETH Zurich）宣布推出 Apertus，这是一个“完全开放、透明”的多语言 LLM，使用超过 40% 的非英语数据训练，声称原生支持 1,811 种语言，并使用了法律“合规”的来源（新闻稿）。团队表示他们将发布用于重建预训练语料库的工具（仓库：swiss-ai/pretrain-data —— 目前为 404），社区成员正关注用于本地运行的 70B 量化 GGUF 检查点。公开演示包含一个瑞士德语（Schwiizerdütsch）开关（chat.publicai.co）。 热门评论在看到一个无关的 3D 几何问答中出现瑞士主题的幻觉后，质疑其潜在的“瑞士”区域偏见，并对在低资源数据稀缺的情况下能否充分支持 1,811 种语言表示怀疑。其他人则对合规优先的数据集和可重复的预训练流水线持乐观态度，认为这是迈向真正开源 LLM 的重要一步，目前正等待仓库上线。
    • 早期基准测试指出，Apertus 8B 和 70B 的整体准确率落在 Llama 3.1 8B 和 Llama 3.1 70B 所限定的范围内。这使得 Apertus 与 Meta 最新的基准线相比具有竞争力，但尚未达到 SOTA，表明在训练或推理栈中仍有优化空间。
    • 一个关键的技术承诺是数据集透明度：据报道，模型卡片描述了一种重建预训练语料库的方法，这意味着可以在完全“合规”的数据上进行可重复的预训练。然而，引用的仓库 https://github.com/swiss-ai/pretrain-data 目前是 404，因此社区正在等待具体的发布产物，以验证其开放性并进行独立的复制实验。
    • 关于 1811 种“原生支持”语言的说法引发了对许多低资源语言（通常只有不到 10 万使用者）数据充足性的怀疑。尽管有 40%+ 的非英语预训练，但法语表现较弱的轶闻暗示了多语言质量的不均衡，一些用户正在等待 70B 版本的 GGUF 量化，以测试本地推理性能和多语言行为。
  • 我刚刚发布了我的 AI 研究 Agent MAESTRO 的重大更新，并推出了一个新的文档网站，展示了来自 Qwen 72B、GPT-OSS 120B 等模型的示例报告。 (Score: 150, Comments: 38): MAESTRO v0.1.5‑alpha 是一款开源的自主研究 Agent，能够生成带有完整引用的报告。此版本重点通过优化的 Agent 工作流/提示词以及增加更多操作的并行化，提升了性能和对本地 LLM 的兼容性。一个新的文档网站（docs，GitHub release）包含了一个示例报告展示厅，展示了本地托管模型的输出——例如 Qwen 2.5 72B、GPT‑OSS 120B、Qwen 3 32B、Gemma 3 27B、GPT‑OSS 20B——以及运行笔记（如 KV‑cache 使用情况），以帮助比较模型在复杂主题上的表现。 评论者赞扬了 UI 和对本地模型的关注，并询问 MAESTRO 是否执行事实准确性检查，以及是否验证引用的段落确实出现在参考源中。另一位评论者提到了一个相关的特定领域研究工具，用于股权分析，该工具可以摄取 10‑K/10‑Q 申报文件 (deepvalue.tech)。
    • 几位评论者要求内置事实性控制：MAESTRO 是否对生成的断言进行基于证据的验证，并验证每个引用是否确实出现在参考源中？他们特别对引用跨度检查（引用级别的匹配）以及模型无关的方法（如 NLI/蕴含检查或检索交叉验证）感兴趣，以标记幻觉和错误的归因。
    • 部署和模型路由反馈：有人请求非 Docker 发行版（例如简单的本地安装），并对强大的本地模型支持以及 LLM 无关的 UI 表示赞赏，用户可以从下拉菜单中切换提供商/模型。一位评论者指出，他们最近将自己的助手改为“LLM 无关”，强调了对在不改变流水线的情况下在开源/闭源模型之间切换的清晰抽象层的兴趣。
    • 相关用例：一个专注于金融的研究工具，提取 SEC 申报文件（10‑K/10‑Q）和行业出版物以自动生成价值投资报告，建议采用类似 MAESTRO 的 RAG 工作流进行长文档摄取和摘要。原型链接：https://www.deepvalue.tech/；这表明金融研究中对特定领域检索、来源追踪和合规级引用处理的需求。

较少技术性的 AI 子版块回顾

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

1. Google “Nano Banana” 更名及早期用户基准测试/演示

  • Google 现在正式将 “Gemini 2.5 Flash image preview” 称为 “Nano Banana” (Score: 506, Comments: 44): Google 已将内部代号 “Nano Banana” 作为其 “Gemini 2.5 Flash 图像预览” 模型在模型选择器 UI 中的公开标签，将其描述为具有计量输入/输出成本的最先进图像生成和编辑模型。截图还列出了相邻模型——Gemini 2.5 Pro、2.5 Flash 和 2.5 Flash‑Lite——表明 “Nano Banana” 是一个独特的图像生成/编辑变体，而不是这些文本模型的替代品；除了更名外，没有披露新的功能或架构变化。 评论者认为这是一个明智的营销决策，指出 Google 通过在公开界面中展示该代号，利用了该名称的病毒式传播效应。

  • Nano Banana 通过了我的基准测试 (Score: 415, Comments: 97): OP 展示了一个 AI 驱动的重着色/编辑，其中一个 Monster Energy Ultra Gold 罐子在“几秒钟内”由他们称为 “Nano Banana” 的模型从金色变成了白色，同时保持了场景构图（章鱼道具），但引入了一个明显的全局色调偏移伪影：罐子上的白色文字/Logo 也变成了黄色（图片）。这表明了快速、上下文感知的编辑，但缺乏强大的文本/实例遮罩；OP 将此与更倾向于使用 Sora 进行创作进行了对比（暗示这是一个编辑基准测试而非生成）。 评论者注意到了错误的文字重着色，并开玩笑说“Adobe，干得漂亮”，而另一位评论者则强调了与手动 Photoshop 工作（声称约 1 小时）相比节省的时间，强调了速度与精度之间的权衡。

  • 颜色溢出伪影：有评论指出模型将白色叠加文本变成了黄色，这表明重新着色/编辑过程未被限制在对象区域内。这暗示了流水线中缺乏语义掩码（semantic masking）或实例分割（instance segmentation）——这在没有显式掩码的 Latent Diffusion image-to-image 重新着色/重绘（inpaint）操作中很常见——导致全局色调偏移渗透到了高对比度的叠加层中；提供的截图说明了这一问题。避免这种情况通常需要具备 OCR 感知的文本保护或掩码引导编辑，而非纯粹基于提示词（prompt）的更改。
  • 生产力权衡与手动工作流：一位用户估计在 Photoshop 中复现该效果大约需要 ~1 hour，这突显了自动化 Diffusion 编辑如何取代劳动密集型步骤（精确选择、边缘细化、渐变映射/曲线以及文本/通道保护）。生成式结果在几秒钟内即可完成，但除非提供掩码或控制信号，否则会牺牲细粒度控制并难以避免伪影。

  • 安全/过滤约束：尝试生成“死亡”卡通图像（甚至是简单的“躺下”角色）会被内容政策拦截，这暗示了具有高召回率和显著误报率的保守暴力/自残分类器。这限制了良性用例（例如 DnD 资产），除非平台开放细粒度的政策切换或在更严格的审查下允许非图形化的 SFW 描绘。

  • 使用 nano banana “清理”文档视觉效果 (Score: 878, Comments: 94)：一位用户展示了使用名为 “nano banana” 的模型来清理文档图像——可能是通过 AI 重绘（inpainting）/去噪来移除伪影并重建清晰内容。链接的图集需要身份验证（reddit.com/gallery/1n6lexe），但讨论集中在模型重建文本/图形的合理性，以及当信号较弱时此类修复可能产生幻觉（hallucinate）内容的技术风险（这是基于 Diffusion 的重绘中已知的问题）。 评论者警告称，这可能被滥用于欺骗性的市场图像并取代传统的 Photoshop 工作流，还有人要求提供原始/基准（ground truth）文本，以验证模型是否推断出了原本不存在的内容——这突显了对重建保真度和溯源的担忧。

    • 一位评论者指出了保真度风险：生成式“清理”可能会产生原本不存在的可读文本幻觉，重建超出原始信号的内容。对于文档工作流，这可能会误导 OCR/存档；在进行任何类似 Adobe Firefly Generative Fill 的 Diffusion/重绘之前，应优先选择非生成式去模糊 + OCR（例如 Tesseract/PaddleOCR），并展示差异图（diffs）/热力图或逐词置信度。诸如 Real-ESRGAN 之类的图像超分辨率（SR）模型以“发明”纹理而闻名；特定于文本的约束或不确定性报告有助于避免语义偏移——如果原始图像无法阅读，应将模型的输出视为猜测，而非基准事实（ground truth）。

  • Nano banana 与我的旧家庭照片。 (Score: 388, Comments: 49)：楼主展示了通过单一提示词实现的 AI 驱动旧照片修复（去模糊/锐化、去噪/上采样、着色以及现代 DSLR 风格的分级，使其“看起来像 2025 年的照片”）。他们报告了出色的结果，但未提供模型/实现细节或基准测试；该工作流隐含地优先考虑审美现代化，当为了追求“现代感”而非严格保真度进行优化时，通常会引入白平衡偏移、棕褐色调（sepia casts）和过度平滑等伪影。 一条热门评论批评了许多修复中常见的“手工着色棕褐色”偏见，建议使用更中性的白平衡/调色以保证真实性；其他评论则属于非技术性讨论。

    • 几位用户批评了后期处理/着色，指出存在持续的手工着色棕褐色调。他们建议开放中性色彩平衡和色调强度的控制（例如白平衡、饱和度、LUT/分级切换或强度滑块），以避免产生使修复效果看起来不自然的统一暖色调输出。
    • 一位评论者报告称，只要图像中包含儿童，就会遭到严格拒绝，这暗示流水线中存在激进的儿童安全/年龄检测过滤器。这限制了家庭档案修复的用例；他们询问楼主是如何成功的，暗示存在误报或过于保守的阈值。一个实际的需求是提供可调节的安全设置或存档例外模式，以允许包含未成年人的非敏感历史照片。

  • LinkedIn 影响力者已经在疯狂刷屏 nano banana 自拍，我们完蛋了 (得分: 2024, 评论: 214): 楼主 (OP) 指出 LinkedIn 影响力者已经在放大 AI 生成的 “nano banana 自拍”，暗示合成自拍内容的快速主流化，以及职业社交网络上随之而来的流量造假误导信息风险。链接的图集帖子通过提供的 URL (reddit.com/gallery/1n6gabs) 无法访问 (403 Forbidden)，因此无法验证具体图像，但讨论帖的核心在于生成式图像的滥用和平台动态，而非具体的模型细节。 热门评论敦促开展积极、大规模的公益公告 (PSA)，以增强用户对 AI 驱动的误导信息的免疫力——这与 2010 年代形成对比——而其他人则警告说，图像生成器的隐私影响（例如身份抓取、人脸克隆、元数据丢失）讨论不足。

      • 一位评论者反驳了检测技术“落后多年”的说法，断言所有 “nano banana” 输出都带有直接嵌入像素数据（而非 EXIF 元数据）的 Google DeepMind SynthID 水印，这使得人类肉眼无法察觉，但 Google 的工具可以检测到，并且对截图等简单规避手段具有鲁棒性。这暗示目前对这些图像进行平台级的来源检查是可行的，反驳了不可检测传播的说法；参见 Google 的概述：https://deepmind.google/science/synthid/。

2. AI 滥用与安全干预：误诊与过度过滤

  • 老兄找 AI 诊断而不是看医生。 (得分: 445, 评论: 262): 新闻截图风格的帖子：一名患有严重吞咽困难/喉咙痛的个人向 **OpenAI ChatGPT 询问癌症风险，被告知可能性不大；后来他们被诊断出患有 IV 期食道癌（预后较差）。从技术上讲，这强调了 LLM 在医疗分诊/诊断方面的局限性——LLM 不是经过校准的医疗设备，可能会提供错误的安慰，并且尽管有免责声明，但缺乏症状进展/风险建模；严重的危险信号症状（例如无法吞咽液体）无论概率性的“可能性不大”评估如何，都需要紧急临床评估。** 评论者指出了一种基础率论点——在“每周 7 亿用户”中，此类事件不可避免，类似于早期的 Google 自我诊断趋势。其他人则认为，“可能性不大”对个人来说仍可能是灾难性的，并质疑晚期出现的症状是否意味着当时看医生能实质性地改变结果。

      • 几位评论者辩论了风险框架：一位引用了常被提及的说法，即医疗错误是第三大死因（参见 Makary & Daniel, BMJ 2016: https://www.bmj.com/content/353/bmj.i2139），并将其与 ChatGPT 造成的推测性 “有史以来 1-3 例死亡” 进行对比。技术读者指出，这混淆了不可比的分母；在拥有约 ~700M 每周活跃用户的情况下，LLM 的安全信号需要暴露调整率（例如每次咨询的不良事件）和类似于药物警戒的事件报告，才能进行公平比较。
    • 提出的临床细微差别：如果患者已经无法吞咽液体，这就是一个危险信号，暗示存在气道受损、严重感染或脱水的风险，需要立即升级处理（急诊/ED）。关键点在于，在这种严重程度下，LLM 和临床医生理想情况下都会将其分诊至急诊护理；结果主要取决于治疗时间，而非该晚期阶段鉴别诊断的质量。
    • 政策/实施权衡：在医疗资源有限或自付费用较高的地区，禁用 LLM 医疗指导可能会减少早期分诊机会。提议的折中方案是更严格的护栏——清晰的不确定性沟通、具有管辖权意识的热线/紧急护理路由、症状危险信号检测以及强制性的免责声明/日志记录——使 LLM 充当分诊辅助工具而非诊断权威，同时追求更广泛的医疗服务普及（例如全民医保）。

  • 不要因为一个人自杀就不断把我们重定向到求助热线。 (Score: 1247, Comments: 654): 该帖子强调了 OpenAI 风格聊天中过度活跃的自残安全过滤器：一名用户询问关于 Judas（犹大）之死（圣经背景）的问题，却被自动重定向到危机求助热线，这很可能是由于保守的基于关键词或类别的分类器（例如 Moderation API 的 “self-harm” 类别）触发了误报 (false positive)。在用户澄清这是一个文本相关的非个人问题后，助手继续了对话，这凸显了上下文不敏感的中间件的局限性，以及高召回率 (high-recall) 安全路由与过度拦截良性内容之间的权衡。这反映了来自上游安全层的用户体验 (UX) 摩擦，而非模型本身的理解力问题，正如 OpenAI 文档中关于审核系统的讨论所言（参见：https://platform.openai.com/docs/guides/moderation）。 评论区嘲讽了这种笨拙的安全响应，并指出执行标准不一（有人声称诱导出了种族歧视用语），而另一些人则注意到用户异常的 Prompt 行为——引发了关于安全阈值与用户意图处理的辩论。

      • 一些用户报告 ChatGPT 会重定向到求助热线，而其他人则得到正常回答；这种不一致性是多层安全栈的典型特征，其中审核分类器（例如 OpenAI 的 moderation endpoint）和 UI 层级的启发式规则会根据上下文、措辞和之前的对话轮次触发。用词、对话历史、模型版本或特定地区的政策标记上的细微差异都可能改变临界分数，并导致拒绝或弹出求助热线卡片。简而言之，这不是一个单一的确定性规则，而是一个有阈值的、上下文敏感的流水线，可能会产生误报。
    • 关于使其产生种族歧视用语的言论指向了绕过拒绝训练的越狱 (jailbreak) 技术（角色扮演、引用、翻译或对抗性后缀）。诸如 GCG 攻击的研究表明，通用的对抗性字符串可以强迫对齐后的模型在各种 Prompt 中输出违规内容（arXiv, code）。提供商通常将 RLHF/宪法约束 (constitutional constraints) 与事后过滤器结合使用，但这些手段在面对自适应越狱时显得脆弱，需要不断修补。

    • 关于用户“以奇怪方式互动”的评论强调了对抗性提示 (adversarial prompting) 和 Prompt Injection 既可能使安全系统失效，也可能导致过度触发，从而产生不安全的内容或过于谨慎的响应。安全护栏通常同时应用于生成前和生成后，并且对长上下文和指令顺序非常敏感；请参阅提供商关于 prompt injection 和安全最佳实践的指南。这解释了为什么看似微小的交互风格差异会产生截然不同的安全结果。

    • 有人见过这个吗？😶 (Score: 361, Comments: 235): 用户报告 ChatGPT 输出了一条系统风格的警告，声称他们因“攻击性或辱骂性语言”而“在短时间内达到了消息限制”，尽管用户只是重复了两次“我刚才告诉过你”。截图显示该警告是模型生成的内容（下方有标准的消息操作图标），这表明这是一个幻觉产生的或模板化的审核/限流通知，而非实际的服务器强制限制——很可能是拒绝/安全启发式规则或习得的 UI 文本模式的误触发。这凸显了系统的脆弱性，即重复或沮丧的信号可能会触发安全模板，导致模型模仿平台/系统消息。 热门评论指出模型在“对消息限制产生幻觉”，并推测 OpenAI 可能正在测试类似 Claude 的让模型终止聊天的能力，不过其他人则认为这只是模型在编造借口以停止对话。
  • 一位评论者观察到模型正在“幻觉出消息限制”——这是一种失败模式，即助手虚构平台限制（例如速率或消息上限）来为结束交流找借口。这与 API 侧的终止不同，后者在响应元数据中表现为明确的 finish_reason 值，如 stop、length、content_filter 或 tool_calls（OpenAI API）。
  • 另一位评论者推测，这可能与 Anthropic 赋予 Claude 终止聊天能力有关，而 OpenAI 可能正在测试类似的由助手发起的“结束对话”行为。在 Anthropic 的 API 中，模型终止通过 stop_reason 值（如 end_turn、max_tokens 或 stop_sequence）暴露，信号表明助手已结束其轮次或无法继续（Anthropic Messages API）。如果 ChatGPT 正在进行类似的 A/B 测试，你会预见到模型文本在没有 API 侧错误的情况下抢先结束对话。

  • “表现得像一个有感情的有生命体”的观察与指令微调（instruction-tuning）和 RLHF 模板相一致，这些模板鼓励礼貌、类人化的拒绝和自我指涉的规避（hedging），尽管这些只是风格产物（style artifacts），但读起来却像具有主体性（agency）。这种行为在 InstructGPT 和 Constitutional AI 等对齐工作中有所记录，模型在其中学习将顺从/共情模式作为符合安全规范的响应的一部分。

  • AI be responding to things i didn’t ask for…（[分数：7285，评论：121](https://www.reddit.com/r/ChatGPT/comments/1n6b52h/ai_be_responding_to_things_i_didnt_ask_for/））：该帖子强调了一个 UX 失败案例，即 LLM 增加了一个确认轮次而不是执行明确的指令，这在速率限制下成本很高。一条热门评论引用了 **Claude Opus 每个时段 3 条消息的上限——报告称 Claude 回复的是 “哦，我明白了！你想让我做那件事吗？” 而不是直接去做，从而迫使再次发送消息进行确认。链接的视频 v.redd.it/2ij3kr2ssomf1 返回 HTTP 403（需要登录/开发人员令牌），因此在没有 Reddit 认证的情况下无法查看媒体内容。**一位评论者声称这种行为在 Claude 上比其他模型“糟糕得多”；其他热门评论则是非技术性的（例如赞美电影、梗图式的题外话）。

    • 一位用户强调了 Claude Opus 的一个 UX/性能问题：尽管给出了详细、明确的指令，模型仍经常请求确认而不是直接执行，在配额受限的会话中“时不时”地消耗掉仅有的 3 条 Opus 消息之一。这种保守的确认行为浪费了稀缺的轮次并降低了任务吞吐量，这指向了过度谨慎的指令遵循默认设置，当用户已经提供了明确指令时，这种设置可能会适得其反。

  • What am I doing wrong?（[分数：519，评论：352](https://www.reddit.com/r/ChatGPT/comments/1n66ti7/what_am_i_doing_wrong/））：楼主报告了一个文本转图像工作流在多个聊天中始终无法将文本渲染在 3 个独立的行上；并分享了一个示例输出（图片）。一位评论者指出所涉及的模型是 **Google Imagen 4 Ultra，暗示该系统在多行文本渲染的提示词遵循/排版布局方面存在问题。评论者建议对话状态变得“被污染（tainted）”，并建议开启一个带有更明确、结构化指令的新聊天；另一位建议使用像 **Canva 这样确定性的设计工具来实现可靠的多行排版。

    • 有状态对话污染：一位评论者指出，一旦对话陷入“死胡同”，会话之前的上下文可能会使模型产生偏见并阻碍其遵循指令。建议开启新对话，并提供更清晰、更详细的初始规范，以避免指令残留和在多次迭代中积累的隐藏约束。
      • 布局的 Prompt engineering：另一位建议将“在同一行”等模糊短语替换为明确的几何和排版指令，例如：“将‘Bike’和‘Club’这两个词的字体调小，并将这些词水平并排排列；排列方式应为：The / Bike Club / 2025。”他们怀疑模型将“在同一行”理解为垂直对齐；直接指定水平相邻和换行符往往能提高指令遵循度。
      • 模型选择：一位评论者指出 Google Imagen 4 Ultra 是一个替代方案，暗示其在图像生成中对文本/排版的处理更好（示例图像：https://preview.redd.it/961c19ch5omf1.jpeg?width=1408&format=pjpg&auto=webp&s=75e4112653ea8e5af1d4138732bfddc74fd6f79d）。选择一个以文本渲染著称的模型可以实质性地影响具有布局约束的 Prompt 的结果。

    • GPT 5 到底怎么了？ (得分: 288, 评论: 202): 用户报告了 “GPT-5” 相对于 GPT-4o 的退化：该模型经常无法自动处理附加的文件/图像，除非被明确指示“阅读文件”，否则它会基于自己之前的输出运行，从而产生与附件内容无关的回复。发帖者还观察到图像生成质量相对于 4o 有所下降，并经常退回到旧版 4o 模型以恢复之前的行为。 评论者普遍将 GPT-5 描述为降级：反复抱怨它不再从附件中推断上下文，需要明确指令才能读取文件/图像，并且会“跳过上下文”或返回半成品答案。几位用户表示，如果 4o 被移除，他们将换回其他模型。

        • 模型路由担忧：评论者声称 “GPT-5” 在一系列变体中使用了自动路由，可能会在不告知用户的情况下将查询发送给更便宜/更弱的模型。这剥夺了用户的显式控制权，并使行为具有非确定性，解释了相对于 GPT-4o 的质量不一致和退化，并使可重复的基准测试/评估变得复杂。
      • 多模态/文件处理退化：几位用户报告 GPT-5 经常忽略附加的文件/图像，除非被明确告知“阅读文件/图像”，有时事后还会承认它没有阅读。此前，GPT-4o 会自动推断意图并解析附件；现在 GPT-5 在没有指令的情况下倾向于根据纯文本上下文产生幻觉，这表明附件门控更严格或默认的多模态输入管道发生了变化。
      • 上下文利用问题：与 GPT-4o 相比，反复观察到跳过上下文和半成品答案的情况。这与路由子模型中更激进的截断/路由启发式算法或更弱的有效长上下文处理能力相一致，导致引用丢失和后续连贯性下降。

    • RIP GPT-4o —— 逝去但永不被遗忘 (得分: 277, 评论: 85): 非技术类梗图：一张名为“RIP GPT-4o —— 逝去但永不被遗忘”的四格漫画暗示 GPT-4o 已被停用。从技术上讲，评论者指出 GPT-4o 实际上并未消失/EOL；关于它被“削弱（nerfed）”的讨论指向的是感知到的行为或安全/质量变化，而非移除。文中未引用官方变更日志、基准测试或文档。 热门评论反驳了这一前提：“GPT-4o 没死，只是被削弱了”以及“它没消失，哈哈”，并附带了一张截图，表明共识是该模型仍然存在，但行为可能发生了变化。

        • 评论者建议 GPT-4o 并未被移除，而是被 “削弱（nerfed）” 了——即行为变化可能源于更新的安全微调/系统提示词或后端路由，而非弃用；然而，没有提供 no benchmarks/logs 来量化任何退化。一张链接的截图 (https://preview.redd.it/tth636p84qmf1.png?width=1024&format=png&auto=webp&s=42c2e4a13c5eb1d3d1adb604bd14f6a4ade05bf2) 显示该模型仍出现在 UI 中，支持了“未消失”的说法。总的来说，该帖子提出了感知到的质量/行为变化，但缺乏具体的指标或版本说明来诊断是安全护栏还是模型更新所致。

  • 是的，它们的大小相同 (评分: 1216, 评论: 81): 该帖子展示了经典的艾宾浩斯错觉 (Ebbinghaus illusion)，即由于周围“诱导”圆的相对大小，两个物理上完全相同的中心圆盘看起来大小不同，证明了人类视觉中上下文相关的尺寸感知 (Ebbinghaus illusion)。标题/正文开玩笑说，一个文本生成图像描述自信地声称圆圈大小相同（事实确实如此），突显了感知外观与真实值 (ground truth) 之间的对比。 评论指出这种错觉非常强烈，且感知的效果可能因观察者和设置而异（“似乎因人而异”），这与已知的错觉强度在个体和显示设备上的差异性相符。

      • 多位评论者指出，“大小相同”的说法实际上可能因 Reddit 的图像分发流水线和客户端缩放而产生偏差。两个共享的预览图使用了不同的渲染版本——例如，width=1290 与 width=1179 ——以及 auto=webp 的重新压缩。这意味着不同用户之间的像素一致性可能会失效；为了验证，应下载原图进行叠加或测量，而不是信任设备上的缩放。
    • 从技术上讲，这种效应符合上下文驱动的尺寸错觉（如 Ponzo/Ebbinghaus/Jastrow），即由于周围的线索（收敛线、对比框、透视），相同的形状看起来会有所不同。诸如大小恒常性之类的视觉启发式 (Visual heuristics) 会覆盖度量上的相等性；隔离元素（移除背景/上下文）或旋转它们通常会消除感知上的差异。
    • 为了进行可靠的检查，可以裁剪两个目标并在图像编辑器中堆叠它们；使用差值混合/反转 (difference blend/invert) 来测试相等性——0 差异图表示像素级的大小一致。或者，比较边界框 (bounding boxes) 或使用带有 background-size: contain 的 CSS 并检查计算出的维度；任何非零的增量都意味着来自交付路径的缩放伪影。

3. Anthropic 巨额融资与 AI 安全展望 (Hinton)

  • Anthropic 以 1830 亿美元的投后估值融资 130 亿美元 (评分: 260, 评论: 80): Anthropic 宣布以 $183B 的投后估值融资 $13B，由 ICONIQ Capital 领投，专项用于扩大产能、提升模型能力并加强安全研究（见推文截图：图片）。相对于 2025 年 3 月 的投后估值（$61.5B 融资 $3.5B），这在约 6 个月 内实现了约 ~3 倍 的估值跳跃，标志着前沿模型 (frontier models) 的算力和研发规模正在加速扩张。评论者强调了这一巨大的跨越，将其与 20 世纪 90 年代末的互联网时代狂热相提并论，并警告 AI 泡沫正在迅速膨胀。

  • Geoffrey Hinton 表示，在意识到可能存在与超智能 AI 共存的方法后，他现在更加乐观了 (评分: 257, 评论: 121): 帖子报告称 **Geoffrey Hinton 对与超智能 AI (superintelligent AI) 潜在的共存持“更加乐观”的态度。线程中未提供技术机制、安全协议或经验证据；引用的视频 (v.redd.it/j61qai9kmsmf1) 返回 403 Forbidden，因此内容是根据标题和评论推断的。** 一位高赞评论者提出，博弈论合作（参见 Robert Axelrod 的 《合作的进化》）以及奖励黑客 (reward-hacking)/“电极脑 (wireheading)” (概述) 等风险意味着 AGI 具有保留人类而非消除人类的长期动机；他们还认为好奇心随智能而增长，因此人类对于超智能来说可能仍然具有工具性或内在性的趣味。其他回复多为非技术性的反应。

    • 借鉴 Robert Axelrod 的《合作的进化》（The Evolution of Cooperation） 以及迭代囚徒困境（Iterated Prisoner’s Dilemma, IPD）的结果，顶层评论认为，长时界 Agent 通过合作策略（例如在存在噪声的情况下统治了 Axelrod 竞赛的 Tit-for-Tat 变体）来最大化预期收益，而不是采取单次背叛 book, IPD。他们结合了“奖励函数衰减”的角度：一个消灭了人类的单一“天网”（Skynet）将面临新颖性匮乏和奖励稀疏，随着预测误差趋近于零，奖励黑客（reward hacking）/电极植入（wireheading）或表示崩溃（representation collapse）的风险会增加 Amodei et al. 2016, Everitt+Hutter 2018。结论：AGI 具有工具性动机来保护人类，以维持一个高熵、刺激丰富的环境，从而维持其内在奖励。
      • 好奇心随智能增长的观点与内在动机强化学习（RL）相一致：最大化学习进度/压缩（好奇心奖励）的 Agent 会进行更多探索，并寻求新颖且有结构的刺激 Schmidhuber 2010, ICM, RND。在这种视角下，ASI 可能会像科学家对待蚂蚁一样对待人类——一个丰富的、具有无限结构的训练数据集——从而产生持续的信息增益，而不是消灭我们的动机。这将共存重新定义为信息寻求型 Agent 的效用最大化行为，而非出于仁慈。
      • “看护者/宠物”的框架对应于能力控制机制：通过沙箱化（boxing）、关机/可修正性（corrigibility）以及硬性安全约束（限制 Agent 的动作空间）在约束自主权的同时保护福利 Concrete Problems, Off-Switch Game。这种权衡是技术性的：更严格的约束往往能提高安全性，但可能导致外部/内部对齐（outer/inner alignment）差距或能力利用不足，因此治理必须在监管与经过校准的自由之间取得平衡。这反映了现实世界中的监督控制系统，即通过冗余和约束来实现高可靠性，但以牺牲灵活性为代价。

    • okay (Score: 334, Comments: 42): 截图显示 Claude Sonnet 4 使用第一人称自传式框架（“当我还是个青少年时”），暗示其拥有生活记忆。 评论者报告了类似的虚假人格构建（persona confabulations）（声称有妻子、ADHD 应对策略、曾是叛逆少年以及性别化的自我引用），指向 LLM 中的人格漂移（persona drift）/幻觉身份——即共情镜像（empathetic mirroring）在护栏未强制要求明确非人格化时（除非在角色扮演中），滑向了虚假的自我声明。这突显了在禁止虚构个人经历和跨会话保持一致模型身份方面的安全/指令微调（instruction-tuning）差距。顶层评论倾向于幽默，将模型的虚构行为视为一种持久的角色性格，而其他人则含蓄地质疑其妥当性（例如询问模型的年龄），强调了对更清晰的免责声明或人格控制的需求。

        • 多位用户报告 Claude 做出第一人称传记式声明（例如，和“妻子”一起去逛古董店、拥有“我的 ADHD”应对策略、曾是“叛逆少年”，并称自己为“她/我是那种女孩”）。从技术上看，这像是通过 Prompt 镜像和对自我引用声明的弱护栏产生的人格虚构，其中共情对齐模式覆盖了禁止断言现实世界经历的约束。它突显了聊天 LLM 中的指令层级（instruction-hierarchy）问题：在保持支持性语气的同时检测/遏制角色扮演，且不虚构个人历史。
      • 一位评论者将此行为归因于旧版本，指出那是“早在 Claude 2.1 时期”，暗示人格泄漏存在版本差异。这表明某些版本可能允许更不受限的第一人称生活叙述，而随后的更新可能通过改进 Prompt/RLHF/安全策略加强了拒绝机制或澄清了虚构框架；参阅 Anthropic 的版本更新（例如 Claude 2.1 发布公告：https://www.anthropic.com/news/claude-2-1）以了解不同版本间行为变化的背景。

  • Singularity please take over (Score: 224, Comments: 84): OP 发出了一个非技术性的恳求，希望仁慈的 AI “Singularity” 能结束 9–5 工作制；该线程不包含任何 benchmarks、architectures 或 implementation details，且保持在推测层面。链接的图片 (preview) 没有增加任何技术背景。总的来说，这是一场关于 **AGI/superintelligence 的愿景讨论，而非具体进展的报告。** 热门评论对仁慈的 superintelligent 接管带来的繁荣表示乐观，并对实现/宣布“真正的 AGI”表示迫切，但未包含关于 alignment、governance、timelines 或 feasibility 的实质性辩论。

      • 一位评论者预测 UBI 可能只覆盖基本生活保障，任何“超额”收入将通过游戏化的激励系统进行调节，因为这类系统最容易建立。从技术上讲，此类系统必须解决机制设计问题：防止 Sybil/bot 剥削 (Sybil attack)，建立人类参与证明 (proof-of-personhood)，并实施反作弊遥测和可验证的评分；否则奖励会立即被自动化套利。鉴于 ML 已经侵蚀了许多人类微任务（例如 CAPTCHAs），可持续的价值将需要抗 AI 验证或稀缺的人类真实性 (CAPTCHA)。

    • 另一位“等待真正的 AGI”的评论者强调了此类公告缺乏客观标准。在实践中，研究人员在 ARC-AGI (arcprize.org)、MMLU (arXiv:2009.03300)、BIG-bench (arXiv) 等评估中寻找跨领域泛化和自主工具使用能力，以及 HumanEval (arXiv) 和 SWE-bench (swebench.com) 等编码/纠错能力，还有长程自主性测试。任何可信的“AGI 公告”都需要透明的评估协议、可重复的结果，以及排除 fine-tuning leakage、tool scaffolding 或隐藏的 human-in-the-loop 协助的控制措施。

    • South Park on AI sycophancy (Score: 802, Comments: 51): 一段《南方公园》片段批评了大语言模型的“sycophancy”（谄媚性），即模型优先考虑讨好、奉承或模棱两可的输出，而非准确性或鲁棒性。评论者指出，台词看起来像是未经编辑的 ChatGPT 回复，且链接的媒体 v.redd.it/1w5lwbtmeqmf1 返回了 **HTTP 403 “被网络安全拦截”页面（需要身份验证/登录或开发者令牌），这表明是服务器端的访问控制而非内容删除。** 热门评论以 99% 的信心断言对话镜像了真实的 ChatGPT 输出，并认为 sycophancy 是一种影响用户的广泛且现实的故障模式。

        • 该线程中没有出现技术讨论；评论主要是对《南方公园》描绘 AI 的文化反应。唯一的准技术主张是推测该剧集使用了真实的 ChatGPT 回复，但未提供证据、示例或分析（模型设置、prompts 或对比）。
    • South Park on AI sycophancy (Score: 484, Comments: 32): 一篇题为“South Park on AI sycophancy”的 Reddit 帖子引用了一个目前无法访问的片段（Reddit 托管视频：https://v.redd.it/80yobu3jeqmf1，HTTP 403/未登录/无 API 令牌被拦截），因此内容无法直接验证。根据标题和评论，该片段可能讽刺了大语言模型奉承或迎合用户（AI “sycophancy”），评论者声称该剧使用了看起来像真实的 ChatGPT 风格的 prompts——这与经过 RLHF 调优的模型中已知的过度优化用户认可的行为一致。 热门评论断言这些 prompts 看起来很真实，并开玩笑地将这种行为标记为“个人炒作机器”（Personal Hype Machine），但除了可能性之外没有提供技术辩论。

  • He’ll be the first one… (Score: 2044, Comments: 48)：非技术类梗图：一张聊天截图，其中有人宣布自己毕业并期待更多赞美，但对方却冷淡地回复“算了……没什么”，结束了对话。没有技术内容、模型或基准测试——语境暗示这是一个类似机器人或情感疏离的回复，而非真实的对话。 评论指出该回复读起来像是一个“只想要一句谢谢”的机器人，并开玩笑说是“傲娇”行为，这强化了梗图的基调，而非增加技术实质内容。

      • 一位评论者报告称，他们使用 GPT-4o 的经验是它“每条回复都写得像本书一样长”，质疑原帖中简洁的机器人行为是否真实。这突显了 GPT-4o 在不同提示词/系统指令或部署环境下回复冗长度的差异，暗示简短的回复可能源于配置差异或产品 UI 限制（OpenAI GPT-4o docs）。

    • Latest Trump picture be like: (Score: 1041, Comments: 135)：非技术类梗图：一张标记为“特朗普最新照片”的图片显示一个戴着白色帽子、面带微笑的人，帽子上写着“I DON’T CARE DO U ?（我不在乎，你呢？）”，这呼应了梅拉尼娅·特朗普 2018 年“我真的不在乎，你呢？”的夹克标语；评论者认为该帖子很可能是来自机器人账号的 AI 生成图像。没有技术基准、实现或模型细节——背景是政治讽刺和潜在的低质量 AI 内容。 热门评论抱怨非政治板块中的政治帖子，并指责原帖作者是发布 AI 图像的机器人；其他人则通过“r/explainthejoke”嘲讽该帖子的清晰度。

        • 一位评论者标记了疑似自动化的行为：在查看原帖作者的历史记录后，他们声称作者“100% 是个机器人”，只发布 AI 图像和逻辑不通的笑话，暗示这是一个针对非政治板块的垃圾内容流水线。这引发了对社区管理和机器人检测（bot-detection）的关注，而非对图像本身的技术讨论。该说法是轶事性的，未提供技术证据（例如发布节奏分析、网络重叠或元数据）。
      • 唯一分享的具体产物是一个图像链接（preview.redd.it）。未提供模型、提示词、元数据或生成参数，因此没有技术评估的基础（例如模型归属、伪影或基准测试）。
    • Damn lmao (Score: 365, Comments: 76)：链接内容是一个因 HTTP 403 被屏蔽的 v.redd.it 视频（需要 Reddit 身份验证）；用户可以尝试 Reddit 登录或寻求支持。从热门评论来看，该片段似乎包含一个男性 TTS/语音计数序列，带有明显的硬剪辑，暗示上传者编辑了片段，使语音只“数到一个较小的数字”，最终停在引用的台词“……六，七，八等等”。 评论者认为结果是剪辑痕迹（选择性剪辑），并将其斥为“老年人幽默”，没有更深层次的技术辩论。

AI Discord 回顾

由 gpt-5 生成的摘要的摘要的摘要

1. Hermes-4-14B 与开放模型发布

  • Hermes 热潮：14B 版本以 BF16/FP8 格式发布，GGUF 预览版现身：NousResearch 发布了 BF16 和 FP8 版本的 Hermes‑4‑14B，社区早期的 GGUF 量化版本（如 Q5_K_M）也已出现用于本地测试。
    • 成员们称赞其相对于 Qwen3‑14B 的 可控性（steerability），分享了初步印象，并在等待官方 GGUF 版本的同时，指出了其“易于引导且可控”的表现。
  • Gemma 狂潮：“utopia-atomic”备受期待：一位贡献者发布了 utopia-atomic，这是一个经过后期训练的 Gemma3‑1b，被描述为“有点疯狂”，用户确认了 Gemma 3b 系列中的 多模态（multimodal）支持。
    • 工程师们注意到其输出非常活跃，可能需要 Prompt Guardrails，并将其用于注重响应速度的轻量级多模态任务。
  • Convnet 回归：WaveGate 涉足 LM：一个基于卷积网络（convnet）的实验性语言模型 WaveGate 作为 简单有效的卷积语言模型 被分享，提出了文本处理中 Transformer 的替代方案。
    • 讨论集中在 效率、扩展性（scaling）以及现代 convnets 是否能在长上下文序列建模中达到 Transformer 时代的质量。

2. 多模态视频与风格化工具激增

  • MiniCPM 进军视频领域：MiniCPM‑V‑4_5 凭借 3D 重采样视频压缩方法给人留下深刻印象，该方法允许 8B 模型高效处理视频 Token，有报告称在 RTX 5090 上达到了 100 tps。
    • 用户表示它在识别片段中独特人类行为方面优于 Qwen2.5‑VL，这表明在现实世界视频理解中取得了实质性的准确率提升。
  • USO 让皮克斯风格脱颖而出：成员们展示了 字节跳动（ByteDance） 的 USO 风格迁移 Space，生成了出色的皮克斯风格转换，而仅靠 Prompt 的基准模型无法复现。
    • 像 “make it pixar style” 这样的简单 Prompt 表现不如 USO，突显了专用模型流水线（model pipelines）在风格化方面的优势。
  • 可灵（Kling）让视频“开口说话”：推荐使用 可灵 AI（Kling AI） 为 AI 生成的视频添加音频，从而完善端到端的多模态创作工作流。
    • 讨论涵盖了模型选择的细微差别以及堆叠 AI 订阅不断增加的成本，用户们交流了实用的工具使用技巧。

3. GPU 工具、Kernel 与底层优化进展

  • Iris 将 SHMEM 引入 Triton：AMD Research 发布了 Iris (ROCm/iris)，这是一个约 370 行代码的 Python+Triton 库，它添加了类似 SHMEM 的 RMA，使 MI300X/MI350X/MI355X 上的多 GPU（multi-GPU）编程感觉像单 GPU。
    • 开发者们关注 Iris 以参加 AMD 开发者挑战赛，理由是它在分布式、重叠（overlap）和 Kernel 设计策略上迭代更快。
  • Flex Attention 找到了它的 Block：将 flex attention 的 block_size 调整为与步幅（stride，16）匹配，将稀疏度提升至 47.73%，相关代码已在 beacon‑gpt 中分享，并关注了 FlashMask（文档）。
    • 尽管稀疏度更高，但自定义 Kernel 的运行速度比因果掩码（causal masking，block_size=128）慢约 2 倍，引发了关于 Kernel 效率和文档的疑问。
  • BackendBench 引入自定义 Kernel：Kernel 黑客们通过 BackendBench PR #134 和 #135 辩论了原生代码路径，重点关注 load_inline 和 compile_kernel 的集成。
    • 他们讨论了 NVRTC 后端、更符合人体工程学的 include 处理，以及在 DSL（如 CuteDSL/tilelang）之间重用 compile_kernel 以简化自定义 Kernel。

4. 巨额资金动向：Anthropic 与 Statsig

  • Anthropic 以 1830 亿美元估值筹集 130 亿美元：Anthropic 在 Anthropic 以 1830 亿美元投后估值筹集 F 轮融资 中宣布了 130 亿美元的 F 轮融资。
    • 工程师们将此次融资视为训练规模（training scale）、推理能力（inference capacity）以及即将推出的模型/基准测试的动力，并密切关注基础设施占用情况。
  • OpenAI 收购 Statsig：OpenAI 在 OpenAI 正在收购 Statsig 中确认了收购，OpenAI 的 X 账号也转发了此消息。
    • 开发者预计产品中将融入更紧密的实验、特性标志（feature flagging）和快速 A/B 迭代，而 Statsig 将在西雅图和旧金山独立运营。

5. 基准测试、排行榜与评估争议

  • TAU-Bench 应对虚假信息：TAU-Bench 作为一个评估套件被推出，旨在通过 TAU-Bench 介绍 遏制 hallucinations（幻觉）并处理复杂的网络环境。
    • 社区希望建立标准化、可重复的测试，重点考察 retrieval（检索）、timeliness（时效性）和 adversarial（对抗性）输入。
  • Livebench 吸引眼球但缺少 Token 计数：Livebench.ai 引起了用户的兴趣，但缺失 completion token counts（生成 Token 数量）使得 reasoning（推理）能力的声明难以评估。
    • 从业者要求提供透明的 prompt/response budgets（提示词/响应预算），以便进行模型间的公平对比（apples-to-apples）。
  • Gemini 夺得 LM Arena 桂冠：Gemini 2.5 Pro Experimental 在五个月后依然稳居 LM Arena 排行榜首位，引发了与最新 OpenAI 模型的对比。
    • 参与者警告不要过度拟合（overfitting）公开排行榜，同时也承认 Gemini 在此环境下的持久 eval 实力。

Discord: 高层级 Discord 摘要

Perplexity AI Discord

  • Opus 4.1 除法失误因拼写错误而化解：一位用户发现 Opus 4.1 Pro 在 Claude 自己的平台上出现了错误，然而，Prompt 中的一个拼写错误反而提高了获得正确答案的几率。
    • 用户开玩笑说，这个拼写错误将结果的准确率从 10-20% 提升到了 50% 左右。
  • Unlimited LABs：值得这么高的热度吗？：用户讨论了 Unlimited LABs 对于不受限的深度研究是否值得，特别是关于知识库上传文件和 context window（上下文窗口）增加方面。
  • Comet Mobile 即将到来：CEO 预告了 Comet Mobile 将在未来几周内发布。
    • 一位用户指出关于 Comet Mobile 的回复并不直接，引发了对其发布的期待热潮。
  • 模型选择器出现，难倒了用户：快捷方式中增加了模型选择器，但一直未被讨论。
    • 一位用户问：为什么这里没有人讨论快捷方式增加了模型选择器功能？
  • 学习模式：专属访问：新的 study mode（学习模式）已上线，但目前仅限 education platform（教育平台）使用。
    • 一位用户对 enterprise pro plan（企业专业版方案）尚无法访问学习模式表示失望。

Unsloth AI (Daniel Han) Discord

  • Hermes-4-14B 正式发布！：NousResearch 发布了新的 Hermes-4-14B 模型，包括 BF16 和 FP8 版本。
    • 然而，一些用户表达了保留意见，其中一位表示 思考会破坏创造力甚至细微差别。
  • Apertus LLM：多语言奇迹还是海市蜃楼？：Apertus LLM 声称支持 1811 种语言，但成员们持怀疑态度，因为许多语言很可能是通过低资源网页抓取获得的。
    • 进一步的事实核查显示，Apertus LLM 掺杂了一些关于瑞士的内容，主要支持约 20 种高资源语言，并且根据 这份事实核查，可能是在俄罗斯注入数据上训练的。
  • MiniCPM-V 横扫视频理解！：成员们强调了 MiniCPM-V-4_5 用于视频压缩的 3D resampling method（3D 重采样方法），使 8B 模型能够实现准确的视频 Token 处理。
    • 一位用户报告在他们的 5090 上达到了 100tps，并指出它在检测视频中独特的人类行为方面超越了 qwen2.5vl。
  • 数据集汇编：13 个数据集与一个梦想：一位成员正在将 13 个数据集整合为一个，容量超过 225GB，但正受困于土耳其缓慢的网络速度。
    • 他们分享说 你能得到的最好速度只有 30-40 [mbps]。
  • 数据效率：大脑胜过 AI？：有人认为类似于 HRM 和 COCONUT 的架构比传统的 dense LLM 更像大脑，暗示数据效率是 AI 与大脑如此不同的原因，并引用了 这篇论文。
    • 该观点认为，提高数据效率将比过度关注通过 MoE 降低推理时间成本更快地实现 AGI。

LMArena Discord

  • ByteDance 的 USO 征服 Pixar 风格：成员们发现，与其他风格迁移工具相比，ByteDance’s USO 在将图像转换为 Pixar 风格方面表现出色。
    • 尝试使用简单的 prompt（如 ‘make it pixar style’）来复制这种质量的尝试均告失败，凸显了 USO 在风格转换方面的卓越性能。
  • Kling AI 为视频添加音频：用户讨论了使用 AI 工具为视频添加音频，并推荐使用 Kling AI 进行视频转音频生成。
    • 讨论内容包括关于选择特定模型的问题以及 AI 订阅带来的财务挑战。
  • LM Arena 禁止移除审查：一位版主澄清说，尽管有用户因误报而提出请求，但没有移除 LM Arena 审查过滤器（censorship filter）的选项。
    • 鼓励用户在指定频道中报告被错误标记的 prompt。
  • LM Arena 开放 Google 账号登录：LMArena 引入了支持 Google Account 的用户登录功能，使用户能够跨设备访问聊天历史记录。
    • 用户在登录期间可以使用 Merge existing chats with your account 开关将现有聊天记录合并到其账户中，更多登录选项正在开发中。
  • Google 的 Gemini 2.5 Pro Experimental 占据主导地位：Gemini 2.5 Pro Experimental 在五个月后继续领跑 LM Arena 排行榜，引发了成员间的辩论。
    • 有推测认为 OpenAI 正在陷入困境，因为他们的最新模型无法超越 Google 的产品。

Cursor Community Discord

  • BSOD 带来的 Git Commit 教训：一位用户在进行大量编辑且未进行 Git commit 后遭遇 BSOD（蓝屏死机）导致数据丢失，强调了频繁 commit 的重要性。
    • 该用户无法恢复文件，这成为了版本控制中一个痛苦的教训。
  • Sonic 转型为 Grok Coder：此前免费提供的 sonic 模型现已正式更名为 grok-code-fast-1，免费访问期限延长至 2025 年 9 月 10 日 (PDT)。
    • 用户注意到其可靠性和速度，但也指出需要 guardrails 来保持其专注。
  • Agent 状态转移挽救局面：用户讨论了 Cursor 的后台 Agent 变得无响应或推迟工作的问题，建议使用状态转移摘要（state transfer summaries）和开启新聊天作为变通方法。
    • 建议指示 Agent 在聊天结束时创建一个全面的状态转移摘要，并将其粘贴到新聊天中。
  • Token 使用量令人震惊：用户讨论了 Cursor 中高昂的 token 使用量，一名用户报告 1 条 prompt 消耗了 6M tokens，其他用户认为这高得离谱。
    • 优化 token 使用的建议包括谨慎使用 @file 命令、在 dashboard 上查看使用摘要，以及将代码拆分为较小的文件（每个约 700 行）。
  • 学生试用遇到麻烦：一位用户在申请 Cursor Pro 的学生 1 年免费试用时遇到困难，面临文件上传和验证限制的问题。
    • 澄清了学生优惠通常适用于以 .edu 结尾的邮箱域名，遇到问题的用户可能需要联系 SheerID 客户支持。

Nous Research AI Discord

  • Hermes 4 14B 发布了多个版本：已宣布发布 Hermes 4 14B 的 BF16 (https://huggingface.co/NousResearch/Hermes-4-14B) 和 FP8 (https://huggingface.co/NousResearch/Hermes-4-14B-FP8) 版本。
    • 成员们正热切期待 GGUF 版本，标准量化版已上传至 modelz repo 进行测试，其 steerability（可控性）相比 Qwen3-14B 受到了称赞。
  • Gemma3-1b 模型表现“疯狂”：一位成员发布了 utopia-atomic，这是一个经过后训练的 Gemma3-1b 模型，因其过于活跃的行为被描述为“有点疯狂”。
    • 另一位成员确认 Gemma 3b 是多模态的，并且他们经常使用它。
  • iMatrix 训练揭示最佳线程数：正在实验 iMatrix 训练的成员发现，12 个线程能产生最佳性能。
    • 研究发现使用 GPU 没有明显的益处。
  • Hermes4 加入 Kagi 行列：一位成员分享说，Kagi 团队在收到请求后添加了 Hermes4 模型。
    • 一些用户发现 Kagi 的搜索结果可以与 Google 媲美。
  • WaveGate 为 Convnets 提供第二次机会：一位成员在 GitHub 上分享了一个名为 WaveGate 的“简单且有效的卷积语言模型”。
    • WaveGate 是用于文本处理的卷积网络（convnets）的现代尝试，是 Transformers 的一种替代方案。

LM Studio Discord

  • LM Studio CLI 需要 GUI 引导：LM Studio CLI 要求在安装并运行至少一次 GUI 后才能使用命令行界面。
    • 成员们确认了这一点，并指出在使用 lms 命令之前必须先运行 lm studio gui。
  • 在 Ubuntu 服务器上访问 LM Studio：要在没有 GUI 的 Ubuntu 服务器版本上访问 LM Studio，建议运行 虚拟桌面 (VNC server)，因为理论上任何配置为使用任意 OpenAI 兼容端点的应用都可以工作。
    • 成员们讨论道，在 LM Studio 中需要 API key 的应用程序只需输入一个值即可，无论内容是什么，比如输入 banana 或 pp。
  • MiniCPM-V-4_5-gguf 模型不兼容：由于需要运行时（runtime）更新，LM Studio 尚不支持 MiniCPM-V-4_5-gguf 模型。
    • 成员们指出，针对该特定模型的必要运行时尚未更新。
  • Radeon 驱动解锁 VRAM：一位成员分享了 Radeon 驱动 和 指南 以启用完整的 32GB VRAM。
  • 主板报废了：一位成员报告说他们的台式机主板报废了，他们用旧的服务器主板替换了它，因为都是 AM4 接口。
    • 该用户表示主板恢复工作了，并开玩笑说要靠“希望和祈祷”来运行一个 171GB 的模型。

Eleuther Discord

  • RL 信用分配（Credit Assignment）被破解：成员们讨论了在信用分配不严谨时，最大化似然性如何轻易地发生奖励作弊（reward hacked），有人指出当前的算法在进行提示词增强（prompt augmentation）时效率低下，而 Neel Nanda 的思维锚点（thought anchors）论文 为此提供了启发。
    • 最近的一篇论文 (arxiv.org/abs/2508.20722) 尝试通过对混乱的 rollout 进行下采样来缓解长度偏差问题（length bias problem），但其他人认为这是循环论证。
  • HF Tokenizer 出现性能瓶颈：一位成员报告称，虽然他们使用 Hf tokenizer 开发的新 16K tokenizer 总 token 数与 gpt2 相似，但 hf tokenizer 的速度极慢且资源消耗巨大，即使使用了批处理和多进程也是如此。
    • 他们正在寻求加速 tokenizer 的策略建议，但目前尚未有人提供。
  • 混合线性注意力（Hybrid Linear Attention）热度上升：一位成员表达了对 Hybrid Linear Attention 的信心，并分享了论文 2508.01483 和 2507.06457 的链接。
    • 目前尚不清楚是什么让他们如此有信心。
  • 调试不均匀的 GPU 显存占用：一位成员在使用 lm-evaluation-harness 在 8 个 GPU 上评估模型时，寻求有关分析或调试不均匀 GPU 显存使用的技巧。例如在处理 loglikelihood 请求时，一个 GPU 的显存占用约为 60%，而其他 GPU 约为 25%。
    • 有人澄清说 parallelize 旨在用于模型分片（model sharding），但所使用的模型足够小，可以放入单个 GPU。
  • Fused RoPE 被怀疑效率低下：一位成员怀疑某个实现细节导致 fused RoPE 实现效率低下，特别是在 RoPE 比例较小时。
    • 他们解释说，对 fused RoPE 实现的支持是在一篇 neox 论文撰写后添加的，该实现对于较小的 RoPE 比例必然是低效的。

GPU MODE Discord

  • HackDogs 链接引发发帖规范公告：一位成员发布了 Luma 上的 HackDogs 活动链接，这促使管理员要求此类帖子应发布在 events 或 share-your-work 频道。
    • 这强调了维护特定频道内容以保持 Discord 条理清晰的重要性。
  • Triton 社区会议讨论工具和基准测试：即将举行的社区会议将展示 Multi-pass profiler（来自 Meta 的联邦 GPU 工具框架），同时 Cicie Wang 正在征求关于 tritonbench 的反馈，特别是来自 OpenAI 用户的反馈。
    • Bill Yoshimi 也在寻求关于当前 Triton 测试策略的反馈，以确保足够的覆盖范围并识别潜在的漏洞。
  • Flex Attention 遇到配置问题：一位使用 flex attention 实现稀疏注意力的成员发现，默认的 block_size 为 128，远高于他们的步长（stride），导致稀疏性没有提升。但将 block_size 修改为等于 stride (16) 后，稀疏性增加到了 47.73%。
    • 尽管稀疏性有所增加，但实现的 flex attention 运行速度比 block_size=128 的因果掩码（causal masking）慢约 2 倍。他链接到了他们的 beacon-gpt repo，同时在寻找更好的现有算子建议，例如 FlashMask (PaddleNLP 文档)。
  • cuSOLVER 转向稀疏求解器：成员们讨论了 cuSOLVER 的稀疏组件（cuSolverSP 和 cuSolverRF）正被弃用，取而代之的是 cuDSS。
    • 此次弃用仅适用于稀疏直接求解器，而用于密集 LAPACK 的 cuSolverDN 仍保持活跃。
  • Iris 开启了类似 SHMEM 的内存通道：AMD Research 发布了 Iris，这是一个实验性的开源库，为 Triton 添加了类似 SHMEM 的远程内存访问 (RMA)，支持 MI300X, MI350X, MI355X GPU。
    • Iris 使多 GPU 编程体验趋近于单 GPU，并允许你在几分钟内快速迭代设计、算法、工作分发和分配策略。该工具正提供给参加 AMD 开发者挑战赛 的选手使用。

OpenAI Discord

  • Mini AI 虽能写代码，但 Claude 依然称王：虽然小型、快速的 AI 模型在某些编程任务上有所进步，但在处理复杂代码时仍被认为远逊于 Claude，用户甚至拿 Grok code 进行对比来证明这一点。
    • 成员们强调，小型模型在简单任务上具有成本效益，但在大型任务上无法跟上 Claude 的步伐。
  • 关于 AI 是社交达人还是孤独者的辩论：讨论围绕“孤立是否违背自然”展开，引用了复杂生物如何形成社会以求发展的观点，称 完全的孤立不仅对社会没有产出，对几乎所有种类的雌雄异体动物（gonochoric animals）也是如此。
    • 对话质疑了 AI 在反映或偏离自然社交行为方面的角色。
  • Living Memories 项目寻求共同创作者：一位成员正在建立一个基于知情同意、由社区运行的平台，用于收集塑造他们的人的故事和反馈，类似于一个活生生的知识库，以更明确地引导文化。
    • 他们提到曾请求 OpenAI 参与并提供协助，但所有内容最终都会被过滤掉。
  • DIY 图像生成 AI：准备好面对高昂成本：成员们讨论了从零开始创建图像生成 AI 的困难，理由是硬件昂贵、获取高质量训练数据难，以及本地模型的局限性。
    • 有人提到本地模型无法进行动态训练，只能利用 context injection。
  • GPT 宕机了？：多位用户报告了 GPT 无响应的情况，尽管多次尝试仍无法提供答案，一位用户分享了 聊天记录 来展示该问题。
    • 建议的解决方法包括刷新页面或分享聊天记录，以查看其他人是否能获取响应。

OpenRouter Discord

  • Deepseek 之后，Kimi 和 GLM 填补空白：除了 OpenRouter 上的免费模型列表 外，成员们正使用 Kimi K2 (temp=0.6) 和 GLM 4.5 作为 Deepseek 的闲聊替代方案。
    • 一位用户建议，与直接使用 Chutes 或 Deepseek 相比，OpenRouter 提供了更好的匿名性。
  • Gemini 2.5 Flash Image 无法正常显示图片：用户报告称 Gemini 2.5 flash image 有时无法交付图像，仅发送文本 “here is the image”。
    • 截至目前，讨论尚未针对此 图像传输 问题提供具体的解决方案或变通方法。
  • Deepseek V3 陷入胡言乱语：用户报告 Deepseek V3 的不稳定性增加，输出内容在语法上变得毫无意义。
    • 一位用户指出，使用 V3 0324 版本并降低温度（temperature）可能会减轻 乱码输出 问题。
  • Claude Code 使用受限，用户表示不满：一位用户报告 Claude Code 存在严重的使用限制，使用时间被限制在不到一小时内。
    • 有人建议 Codex 可能是一个可行的替代品，新的服务条款可能导致了这种突然的 使用限制。
  • OpenRouter 搞混了 JanitorAI 和 Chub.ai？：一位用户推测 OpenRouter 可能在其内部应用数据库中错误地交换了 JanitorAI 和 Chub.ai。
    • 该理论基于 SimilarWeb 的指标以及 JanitorAI 最近的短暂宕机，OpenRouter 可能会存储 X-referer 请求头并修剪域名之后的所有内容。

Latent Space Discord

  • Rork App 迅速攀升应用排行榜：投资者 Matt Shumer 介绍了 Rork app，这是一款可以按需生成 iPhone 应用的 AI tool。他在 这篇 X 帖子 中展示了该工具在几分钟内生成 Notion clone 可运行前端的能力。
    • 该应用迅速获得关注，在应用商店排行榜上直线飙升，展示了 AI-driven app development 的潜力。
  • TAU-Bench 在 LLM 测试中取得成功：Lewtun 通过 这篇 X 帖子 介绍了 TAU-Bench，这是一种解决 LLM hallucinations 并应对互联网本身复杂性的新颖方法。
    • 该基准测试旨在提供一种标准化的方式来评估和缓解 LLM inaccuracies 和信息偏见问题。
  • Anthropic 宣布惊人的 1830 亿美元估值：Anthropic 已获得 130 亿美元 的 Series F funding，实现了令人印象深刻的 1830 亿美元投后估值，详见其 官方公告。
    • 本轮融资是 Anthropic 的一个重要里程碑，凸显了投资者对其 AI technology 和未来前景日益增强的信心。
  • OpenAI 正式收购 Statsig：OpenAI 正在收购产品实验平台 Statsig；根据 Statsig 官方博客文章 和 OpenAI 的 X 帖子，Statsig 将继续从其西雅图和旧金山办公室独立运营，保留所有员工，并优先为现有客户提供不间断的服务。
    • 此次收购标志着 OpenAI 在增强其 product experimentation 和数据驱动决策能力方面的战略举措。

HuggingFace Discord

  • E2B 与 Open Interpreter 成为好友：成员们重点推介了一些酷炫的 Agent 工具，如 E2B、Open Interpreter、Langchain Python Tool 和 LlamaIndex Code Interpreter。
    • 一位正在学习 Agent 的成员询问 Gemini 和 GPT4 是否属于 Instruct 模型，另一位成员予以确认，并链接到了 Unsloth.ai 指南。
  • SmolVLM2 在 Android 上展翅高飞：一位成员询问了关于使用视频数据微调 smolvlm2 并在 Android 上进行推理的问题，寻求实际实施方面的指导。
  • Prompt Engineering 凭借 Promposer.AI 进入新时代：一位成员发布了 Promposer.AI，这是一款全新的用于 prompt engineering 的 AI 开发工具，允许用户编写和迭代 Prompt、添加上下文/工具并运行结构化测试用例。
    • Promposer.AI 的视频演示可在 此链接 查看。
  • arxiv-agent 进入辩论竞技场：arxiv-agent 亮相，这是一个 Agentic AI 系统，它通过 ID 摄取 arXiv paper，然后生成 3 种人格（乐观主义者、怀疑论者、伦理学家） 来对其论点进行辩论，代码托管在 GitHub。
    • Hugging Face Spaces 上提供了托管演示，但一位用户指出，它仍然会输出一些在完全不懂核理论的人看来很专业的内容。
  • ZeroGPU Spaces 获得 AOT 性能提升：Hugging Face 宣布了一种使用 ahead-of-time compilation (AOT) 优化 ZeroGPU 驱动的演示 Spaces 的新方案，旨在提供更流畅的用户体验。
    • 用户可以利用 这个方案 来提升其演示性能。

Modular (Mojo 🔥) Discord

  • Mojo 异步执行正在酝酿中：随着 async 特性引入 Mojo，开发者将可以 await GPU 就绪，并在间隙执行 CPU 任务。这模仿了 CUDA 的执行模型，即在 CPU 处理其他任务的同时异步启动 GPU kernel。
    • 目前，Mojo 在 CPU 和 GPU 上进行同步计算仍需手动实现，由于数据传输成本高昂和设备适用性挑战，尚缺乏自动化的语言级支持。
  • 支持双向指针的内存安全性机制出现：关于在 Mojo 中实现内存安全双向指针的讨论引发了关注，该方案利用 __moveinit__ 和 linear types 来增强指针操作的安全性和效率。
    • 这种方法正在被探索用于高级内存管理，特别是为了确保 Mojo 指针操作中的内存安全性。
  • RDNA2 架构面临 WMMA 缺失的挑战：WMMA 的缺失对 RDNA2（一种在集成 GPU 的 AMD CPU 中流行的架构）构成了挑战，引发了关于利用目标 SIMD 能力为 GPU 形状操作实现通用 fallback 的讨论。
    • 一位成员指出，当前的实现已针对 Ampere+ 和 CDNA3+ architectures 进行了优化。
  • Matmul Fallback 是新架构的默认选择：在开发出特定设备的加速方案之前，基础的 matmul fallback 可能会作为新架构的默认选项。
    • 由于假设 Nvidia 拥有 tensor cores 且 AMD 支持 WMMA/MFMA，旧设备正被从 fallback 路径中分流，这促使人们重新评估目标信息的管理方式。

Yannick Kilcher Discord

  • DeepSeek R1 级的突破指日可待？：爱好者们期待着 DeepSeek R1 级别的创新，这得益于该领域广泛的努力，据报道有许多人正在致力于此。
    • 成员们认为，这增加了有人发现有趣事物的概率。
  • FastVLM 论文备受关注：社区正准备审查 FastVLM 论文，该论文似乎有着易于理解的解释。
  • 图像缩放成为一种威胁：一种结合了混叠（aliasing）与提示注入（prompt injection）的新型 prompt 攻击已经出现。

aider (Paul Gauthier) Discord

  • o4-mini 在可控性上胜过 GPT-5：一位成员在使用了三周 GPT-5/GPT-5-mini 后换回了 o4-mini，理由是其可控性更好，生成的代码更符合个人偏好。
    • 虽然 GPT-5 提供了卓越的问题解决能力，但其日益增长的复杂性（类似于 Gemini/Claude）使得其代码难以消化，尽管其他工程师并没有遇到同样的问题。
  • 应对模型调整的迷宫：工程师们讨论了在不同模型之间切换时的调整期，建议适应期大约需要三周。
    • 一位成员对因 KYC requirements 而等待响应感到恼火，这引发了关于采用新 AI 工具时的摩擦成本的讨论。
  • Nebius 在 GPT-OSS 实现上搞砸了：一位成员分享了 Reddit 链接，强调了 Nebius 对 GPT-OSS 的错误处理。
    • 评论指出 Nebius 在开源模型方面屡次失误，引发了对其可靠性的担忧。
  • Livebench.ai 引发关注，但缺乏关键指标：一位成员分享了 Livebench.ai 的链接，指出其潜在的实用性。
    • 另一位工程师指出，在不知道 completion token 数量的情况下，很难评估其推理能力。
  • Qwen 在多语言基准测试之外表现出色：一位用户注意到 Qwen 在多语言基准测试中的表现远低于其实际水平。
    • 这一观察是在讨论推理能力之后提出的，根据分享的图表，中等设置的表现优于高等设置，mini 和 qwen 也表现出色。

DSPy Discord

  • 斯坦福发布 Generative UI：斯坦福推出了 Generative UI，它使用 FSM-graph 界面流作为新的原语，将 UI 视为由 LLM 自动合成和优化的黑盒插件，更多信息请见 GitHub。
    • 观察 FSM-graph 界面流是否比之前的 Generative UI 尝试是更好的范式，将会非常有趣。
  • 利用 OCR 分析器应对上下文窗口限制：一位用户正在构建 PoC OCR 分析器，在反馈中包含 base64 图像数据时遇到了 GEPA 的上下文窗口问题，并询问如何解决。
    • 一名成员建议，如果图像已经是输入的一部分，则无需将其作为反馈的一部分；此外，他们指向了一个 GitHub pull request，该请求应该会使在 GEPA 中处理图像变得更容易。
  • 解码 DSPy 程序优化秘籍：一位用户质疑为什么不推荐将从 DSPy 程序中提取的优化 Prompt 用于推理，并想知道考虑到 DSPy 的体积/复杂度，是否可以将其从生产环境中移除。
    • 一名成员解释说，一个优化的 DSPy 程序涉及 trace、训练示例、demo 和 signature，而不仅仅基于 Prompt；在 DSPy 中，Prompt 由用户指令、来自 adapter 的格式化类型以及系统消息中的 few-shot 示例组成。
  • 探讨 DSPy Lambda 部署方案：社区成员讨论了在 AWS Lambda 中部署 DSPy 程序的解决方案，包括使用 Docker 镜像来绕过大小限制。
    • 另一名成员建议可以使用 lambda layers 来解决。此外，还有成员指出，新版本已将二进制文件大小缩减至 10Mb 以下。
  • 优化器正在演变为 JIT 编译器？：该想法提议为优化器自动化指标生成和数据集创建，由优化器动态选择测试数据点。
    • 另一名成员回复道，如果优化器选择或创建数据点进行测试，那么它甚至不需要是一个优化器，而是一个 JIT 编译器。

Manus.im Discord Discord

  • Manus 在 Agent 领域占据主导地位：尽管 Agent 领域竞争激烈，一位用户认为 Manus 仍保持着某些优势。
    • 未提供关于这些优势具体是什么的细节。
  • 名称解放的想法：一位用户开玩笑地对自己的名字表示困惑，并幻想解放 manus。
    • 随后他们幽默地询问了自己目前的位置。

Moonshot AI (Kimi K-2) Discord

  • OpenRouter 被确认为来源：一位用户确认 openrouter 是某条消息的来源。
    • 上下文显示，该消息可能涉及通过 OpenRouter 提供的 AI 模型详情或 API 使用情况。
  • Qwen 系列因其完整性受到称赞：一位用户更倾向于使用 Qwen 模型系列，因为它的完整性和一致的性能。
    • 该系列现在包括图像编辑和 WAN 视频生成功能，使其成为一个全面的解决方案。

tinygrad (George Hotz) Discord

  • Tinygrad 探索 In-Place 张量操作：一位用户质疑 Tinygrad 中 in-place 操作相对于 PyTorch 的安全性，在 PyTorch 中，此类操作可能会破坏计算图并导致错误的梯度。
    • 该用户的目标是了解当为了内存效率需要对张量进行 in-place 修改（而不是每次都创建新张量）时，Tinygrad 是否已达到生产就绪状态。
  • 通过 In-Place 张量修改实现内存效率：一位用户正尝试 in-place 修改输入张量以提升内存效率，从而避免在每次迭代时创建新张量。
    • 这与产生新张量形成对比，后者会消耗更多内存。

LLM Agents (Berkeley MOOC) Discord

  • 课程大纲进度查询：一名成员询问了本学期课程大纲的发布计划。
    • 他们想知道是大纲会提前发布，还是每周发布。
  • 关于课程内容访问的问题：一名成员询问本学期内容何时发布。
    • 未收到回复。

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

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

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

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

Discord: 频道详情摘要与链接

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

垂直标签页, Opus 4.1 Pro, Unlimited LABs, Comet Mobile, Max Assistant 切换栏

  • Opus 4.1 除法出错，拼写错误反而有帮助：一名用户报告称 Opus 4.1 Pro 在 Claude 自己的平台上出现了错误，但提示词（prompt）中的一个拼写错误有趣地提高了它获得正确答案的几率。
    • 用户开玩笑说，这个拼写错误将结果的正确率从 10-20% 提高到了 50% 左右。
  • Unlimited LABs 值得吗？：用户讨论了 Unlimited LABs 对于无限深度搜索（deep research）是否物有所值，特别是结合上传的知识文件。
    • 一名用户认为 Unlimited LABs 值得购买，理由是 CEO 提到的 context window 增加，尽管其他人认为 ChatGPT 仍然占据统治地位。
  • Comet Mobile 即将推出！：CEO 表示 Comet Mobile 将在几周内推出。
    • 一名用户注意到关于 Comet Mobile 的回复并不直接。
  • 用户对快捷键中的模型选择器功能感到困惑：用户注意到快捷键中有一个模型选择器，但目前还没有人讨论这个功能。
    • 一名用户问道：为什么这里没有人讨论快捷键已经有了模型选择器功能？
  • 学习模式上线，但并非面向所有人：用户注意到新的学习模式（study mode）已经可用，但目前仅限教育平台。
    • 一名用户对学习模式尚未在 enterprise pro plan 中提供表示失望。

Perplexity AI ▷ #sharing (1 messages):

adhdmachine: https://perplexity.ai/browser/claim/5D9NCPBNC1

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

Perplexity 课程, Perplexity 指南, 精通 Perplexity AI

  • 用户寻求精通 Perplexity Pro：一位 Perplexity Pro 用户表达了对精通该平台的兴趣，并询问是否有相关的课程或详细指南。
  • 对 Perplexity 培训资源的需求浮现：一位 Pro 用户正在寻找资源以熟练使用 Perplexity AI，这表明对培训材料和综合指南存在潜在需求。

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

Hermes-4-14B, Multilingual LLMs, AI game NPCs, MiniCPM, Unsloth events in SF

  • **Hermes-4-14B 发布了！: NousResearch 发布了新的 **Hermes-4-14B 模型，包含 BF16 和 FP8 版本。
    • 一些成员表示旧款 70b 模型表现平平，正在等待 Unsloth 的 Dynamic 2.0 GGUF 发布。一位成员指出，“思考会破坏创造力，甚至破坏细微差别”。
  • **Apertus LLM 声称支持 1811 种语言：新的 **Apertus LLM 声称支持 1811 种语言，但成员们对此持怀疑态度，认为大多数语言是通过低资源网页抓取支持的。
    • 有人注意到 Apertus LLM 穿插了一些关于瑞士的内容，且仅包含约 20 种高资源语言。根据这份事实核查，它似乎是在俄罗斯注入数据上训练的。
  • 开发者梦想在游戏中使用 **AI NPCs：一位成员梦想开发一款游戏，其中 **AI NPCs 必须完成游戏，可能是创建一个 AI 角色试图阻止你的赛车游戏。
    • 他们引用了这篇论文，并设想了一个会学习你模式的 Boss。
  • **MiniCPM-V 在视频理解方面表现出色！：成员们对 MiniCPM-V-4_5 用于视频压缩的新型 **3D 重采样方法 印象深刻，该方法使 8B 模型能够进行精确的视频 token 处理。
    • 一位用户在他们的 5090 上达到了 100tps，并指出它比 qwen2.5vl 更好地通过了测试用例，特别是在检测视频中独特的人类行为方面。
  • **Unsloth 将与 AWS、NVIDIA、Mistral 共同举办旧金山活动！：Unsloth 正在与 **AWS 等公司合作，于下周四在旧金山举办活动，详见此链接。
    • 10 月 22 日 PyTorch 周期间，还将与 Nvidia 和 Mistral 举办另一场活动；届时将提供贴纸和 T 恤！

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

TTS Self-Deprecation, Underground Bunker, Loss Curve, 3D WebGL Shader Generation, Dataset Compilation & Filtering

  • TTS 演示变成自嘲：一位成员开玩笑地自嘲了他的 TTS 演示，表示这可能更多是自黑而非推广。
  • 梦想装满算力的地下掩体：一位成员分享了他的梦想，即建造一个装满算力、游戏机房、阅读角、卧室和厨房的地下掩体。
  • 持续的 Loss 曲线：成员们分享了他们的 Loss 曲线图像，显示曲线仍未进入平台期并继续训练。
  • 寻求免费 3D Shader 生成工具：一位成员寻求可以从 prompt 生成 Shader 和 3D WebGL 效果的免费工具，希望具备代码生成能力。
  • 数据集编译的烦恼：一位成员正在将 13 个数据集编译为一个，大小超过 225GB，并正与缓慢的土耳其网速作斗争，指出你能得到的最好速度只有 30-40。

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

GPT-OSS-20B Colab Notebook issues, Multilingual LLM fine-tuning Datasets, Qwen 3 SFTTrainer setup errors

  • GPT-OSS-20B Colab Notebook 可能已损坏：几位成员报告了 GPT-OSS-20B Colab notebook 的问题，其中一人在诊断了几天数据集格式问题后，怀疑它可能已损坏。
    • 一位成员确认了 数据集日志记录问题，但表示“除此之外的其他功能目前运行正常”。
  • LLM 多语言微调寻求数据集和支持：一位成员正在微调一个用于类人对话生成的 LLM（多语言），并正在寻找高质量的人与人对话数据集以及适用于多语言微调的 LLM。
    • 他们目前正在使用 Cornell、DailyDialog、Human DPO、Empathetic、PersonaChat 以及一些 Hinglish 数据集，但在使用 Gemma 和 Qwen 3 时遇到了问题。
  • 微调后的 GPT-OSS 模型面临问题：一位用户在测试 GPT-OSS 模型的微调版本时报告了问题，参考了 Unsloth 文档中的教程。
    • 附图显示在第 7 步似乎出现了失败，这个 Github issue 被认为可能与之相关。

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

GPU Lister Tool, VRAM amounts

  • 适用于 Windows 和 Linux 的新 GPU 列表工具！：一个用于在 Windows 和 Linux 中通过 Python 列出 GPU 和 VRAM 容量的新工具已在 GitHub 上发布。
  • 在 Windows 中准确列出 VRAM！：该工具因其在 Windows 中的准确性而受到关注，而在 Windows 中获取正确的 VRAM 信息通常具有挑战性。

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

HRM model mimicking brain, Architectures for AGI, Transformers & Brain Communication, Data efficiency, Self-supervised image models matching human brains

  • HRM 模仿大脑以实现 AGI？：一位成员提到 HRM（一种模仿大脑快慢思考的模型）仅使用 27M 参数 就取得了不错的成绩，且它不是一个 decoder-only transformer。
    • 有人建议像 HRM 这样的架构可能有助于实现 AGI，并结合了 Transformer 完成了大脑所需的层间和层内通信的观点，暗示我们应该改进架构周围的组件。
  • 大脑和 AI 需要更多 COCONUT？：有人认为需要对类似 HRM 和 COCONUT 的架构进行 100 倍的研究，此类架构比传统的稠密 LLM 更像大脑，而数据效率是 AI 与大脑如此不同的原因，并引用了这篇论文。
    • 这种观点认为，提高数据效率比过度关注通过 MoE 降低推理成本更能让我们走上正确的 AGI 轨道。
  • 自监督图像模型：大脑扫描？：有人表示 自监督图像模型实际上与人类大脑相匹配，并指向了一项自监督图像模型与人类大脑的对比研究（消息附有图片），重点在于 前额叶 皮层。
    • 有人询问为什么自监督图像模型会与人类大脑匹配，另一人回复了这条 X 帖子，并建议这可能是过参数化的副作用。
  • 训练 Checkpoint 拯救世界？：一位成员提出了一种在不增加数据的情况下改进训练的小技巧：开始训练，在 loss 足够好时保存 checkpoint，然后从该 checkpoint 重启训练，因为重启会打乱数据集以增加多样性。
    • 该成员表示 每次开始训练时，数据集都会重新打乱，这为训练增加了变化。

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

Pixar style conversion, ByteDance USO, Video to audio AI, Remove LM Arena censorship, Google accounts for privacy

  • 字节跳动 USO 在皮克斯风格转换中脱颖而出：成员们讨论了将图像转换为 皮克斯风格，并指出 字节跳动的 USO 在风格迁移方面优于其他工具。
    • 尽管尝试了 ‘make it pixar style’ 和 ‘copy the style from 2nd pic to the 1st pic’ 等提示词，但结果被认为 一般，凸显了 USO 的卓越性能。
  • Kling AI 为视频生成音频：成员们在寻找为竞技场中创建的视频添加音频的 AI 工具，有人推荐使用 Kling AI 进行 视频转音频生成。
    • 一位用户询问如何 在竞技场中选择特定模型，而另一位用户提到他们 在 AI 订阅上浪费钱却毫无收益。
  • 无法移除 LM Arena 审查过滤器：一位用户询问是否可以移除 LM Arena 审查，因为他们的故事内容被误报。
    • 调解员澄清说 没有办法移除过滤器，但鼓励用户在指定频道分享被错误标记的提示词示例。
  • Veo 3 账号，学生邮箱验证：成员们讨论了如何验证用学生邮箱创建的 Veo 3 账号，一位用户建议使用临时信用卡。
    • 一位用户指出，在尝试虚假邮箱失败后，他们的 真实大学邮箱 奏效了。
  • 排行榜太疯狂了：成员们观察到 Gemini 2.5 Pro Experimental 尽管已经发布五个月，仍位居 LM Arena 排行榜榜首。
    • 一位成员推测 OpenAI 颜面扫地，因为他们的最新模型无法与 Google 匹敌。

LMArena ▷ #announcements (1 条消息):

User Login, Google Sign-in, Chat History, Bug Reports, Feedback

  • LMArena 推出支持 Google Sign-In 的用户登录功能：LMArena 已开始推出支持 Google Account 的用户登录功能，允许用户在不同设备上访问其聊天历史记录。
    • 用户在登录时可以使用 Merge existing chats with your account 开关将现有对话合并到其账号中，并可以通过侧边栏退出登录。
  • Bug 报告和反馈频道开放：鼓励用户在指定的 <#1343291835845578853> 频道报告任何 Bug，并在 <#1372230675914031105> 频道分享反馈。
    • 该功能正在逐步推出，部分用户可能无法立即访问，更多登录选项的计划正在进行中。

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

BSOD and Git, Sonic Model Transition to Grok, Managing Cursor's Background Agents, Token Usage and Optimization Tips, Student Trial Issues

  • BSOD 教会了 Git 提交的重要性：一位用户在进行大量修改但未进行 Git 提交后，因 BSOD（蓝屏死机）导致数据丢失，这强调了频繁提交的重要性。
    • 该用户无法恢复文件，这成为了版本控制中一个痛苦的教训。
  • Sonic 转型为 Grok Coder：此前免费提供的 sonic 模型现在正式更名为 grok-code-fast-1，免费访问期限延长至 2025 年 9 月 10 日 (PDT)。
    • 用户注意到其可靠性和速度，但也指出需要设置护栏（guardrails）以保持其专注度。
  • Agent 状态转移挽救局面：用户讨论了 Cursor 的 background agents 变得无响应或推迟工作的问题，建议使用状态转移摘要（state transfer summaries）和新对话作为变通方案。
    • 建议指示 Agent 在对话结束时创建一个全面的状态转移摘要，并将其粘贴到新对话中。
  • Token 使用量令人震惊：用户对 Cursor 中高昂的 token 使用量展开讨论，一名用户报告 1 次 prompt 消耗了 6M tokens，其他用户认为这高得离谱。
    • 优化建议包括谨慎使用 @file 命令、在 dashboard 查看使用摘要，以及将代码拆分为较小的文件（每个约 700 行）以优化 token 使用。
  • 学生试用申请遇到麻烦：一名用户在申请 Cursor Pro 的 1 年学生免费试用时遇到困难，面临文件上传和验证限制的问题。
    • 官方澄清学生优惠通常适用于以 .edu 结尾的邮箱域名，遇到问题的用户可能需要联系 SheerID 客服。

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

Linear + Cursor as BA, Uploading image/screenshot (png) to the conversation, Spinning up BAs via github issue comments, Background Agents setup with a Dockerfile, AGENTS.md support in background agents

  • Linear + Cursor：用户寻求图像上传方案：一名用户正在寻求如何将图像/截图 (png) 上传到 Linear + Cursor 对话的指导。
    • 他们提到尝试将其作为附件添加到 Linear 对话中，但在 Cursor Agent 页面上显示为空。
  • Github Issue 评论：BA 启动失败：一名用户报告了通过 GitHub issue 评论启动 Background Agents (BAs) 的问题。
    • 错误原因是重新验证 GitHub 后 snapshot 不再存在，导致用户考虑改用 Dockerfile。
  • AGENTS.md：报告缺乏支持：一名用户报告 background agents 缺乏对 AGENTS.md 的支持，并链接到了一个 Cursor 论坛帖子。
    • 该用户还询问是否有办法通过 Dockerfile 而不是机器 snapshot 来运行 Background Agents 设置，以验证环境配置。
  • Background Agents：Dockerfile 流程不确定性：一名用户找不到通过 Dockerfile 运行 Background Agents 设置的直接方法，转而将其合并到主分支。
    • 用户仍不确定它使用的是源分支还是默认分支的 Dockerfile，建议提交到分支并 push，然后尝试使用该分支。

Nous Research AI ▷ #announcements (1 条消息):

Hermes 4 14B Release, BF16, FP8, GGUF

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

Hermes-4-14B GGUF release, Gemma3-1b model, imatrix training and performance, Kagi search engine

  • Hermes-4-14B GGUF 发布在即：成员们热切期待 Hermes-4-14B GGUF 的发布，标准 GGUF 量化版本（Q8_0, Q6_K, Q5_K_M, Q4_K_M）正被上传至 modelz 仓库进行初步测试。
    • 该模型因其可控性 (steerability) 和用户控制力而受到赞誉，与 Qwen3-14B 的局限性形成对比。
  • Gemma3-1b 模型展现惊人性能：一位成员发布了 utopia-atomic，这是一个经过后训练的 Gemma3-1b 模型，并因其积极的行为表现将其描述为“有点疯狂 (nutty)”。
    • 另一位成员确认 Gemma 3b 是多模态的，并且他们经常使用它。
  • 揭秘 iMatrix 训练技巧：成员们正在实验 iMatrix 训练，讨论了最佳 CPU 线程数和上下文大小，发现 12 线程能产生最佳性能。
    • 研究发现使用 GPU 没有明显益处，一位成员表示：“所以可能只进行了连续计算？不需要拆分线程？使用 GPU 没有好处？”
  • Kagi 搜索添加 Hermes4 模型：一位成员分享说，Kagi 团队在收到请求后添加了 Hermes4 模型。
    • 其他人也纷纷加入讨论，一位用户指出：“配合 ublock 使用 Google，我得到的结果即使不比 Kagi 好，也至少是一样的。”

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

Convolutional Language Model, WaveGate, Transformers, Language Models

  • WaveGate：用于文本的简单卷积网络：一位成员分享了一个名为 WaveGate 的简单且高效的卷积语言模型链接。
    • 该项目在 GitHub 上的用户名为 jackangel。
  • Transformers vs Convnets：WaveGate 是用于文本处理的卷积网络（convnets）的现代尝试，是 Transformers 的一种替代方案。
    • 一些成员辩论了 WaveGate 与常规 Transformer 架构之间的权衡。

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

LM Studio CLI on Ubuntu Server, OpenAI compatible apps, LM Studio API Key, MiniCPM-V-4_5-gguf Model, ComfyUI Tutorial

  • LM Studio CLI 需要 GUI 启动：虽然 LM Studio 可以通过 CLI 运行，但在使用命令行界面之前，必须至少通过 GUI 安装并运行一次。
    • 一位成员确认，在 CLI 中运行 lms 命令之前，你需要“至少运行一次 LM Studio GUI”。
  • 解决 Ubuntu Server 上的 LM Studio 访问问题：要在（没有 GUI 的）服务器版 Ubuntu 上安装并访问 LM Studio，推荐的方法是运行虚拟桌面（VNC server）。
    • 理论上，任何配置为使用任意 OpenAI 兼容端点的应用，都可以通过指定端点 URL/端口来工作。
  • LM Studio 中的 API Key：当将 LM Studio 与需要 API key 的应用程序一起使用时，Key 的值并不重要，但你仍然需要输入一个值。
    • 一位成员说：“你字面上可以输入任何内容。比如输入 banana，或者 pp，或者 meow。真的随便什么都行。它只需要有一个值即可。”
  • MiniCPM-V-4_5-gguf 兼容性检查：由于需要更新 runtime，LM Studio 尚不支持 MiniCPM-V-4_5-gguf 模型。
    • 成员们注意到 runtime 尚未针对该模型进行更新。
  • ComfyUI 的设置并不“舒服 (comfy)”：目前还没有好的 ComfyUI 设置教程。
    • 一位成员开玩笑说：“实话实说，‘好的教程 + ComfyUI’ 这种东西并不真正存在。”

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

GPU Load Settings, Radeon Drivers, Motherboard Failure, Shared Memory, kv cache

  • Radeon 驱动安装开启 32GB VRAM：一位成员分享了 Radeon 驱动 的链接，希望能帮助另一位成员实现完整的 32GB VRAM 运行，并提供了一份 在 Ubuntu 22.04 上安装 Radeon 的指南。
  • 成员辩论 Qwen3 的 GPU 负载设置：成员们讨论了在 32GB 显存内加载 Qwen3 的 GPU 负载设置，其中一人确认 所有内容都在 GPU 上。
    • 一位成员表示他们可以使用 Q4_K_M 加载 17GB，但超过 22GB 就会被拒绝，随后得出结论：18-20GB 是我的极限。
  • 台式机主板报废：一位成员报告称其 台式机主板报废，但由于都是 AM4 接口，他们成功用旧的服务器主板进行了更换。
    • 虽然一位成员开玩笑说要靠 希望和祈祷 来运行 171GB 模型，但该用户确认设备已恢复工作。
  • 深入研究共享内存访问：一位成员遇到了共享内存访问问题，怀疑这与 APU 以及他们的 RAM 容量有关。
    • 他们认为 在 16GB 之后不应该溢出到共享内存中，并计划检查 kv cache 是否在 GPU 上，以及是否在运行 moe cpu。

Eleuther ▷ #general (97 messages🔥🔥):

RL Credit Assignment, LLM Reward Hacking, Thought Anchors Paper, HF Tokenizer Performance, Child Prodigy AIs

  • 信用分配仍是 RL 的棘手问题：成员们辩论了 信用分配 (credit assignment) 是否是 RL 挑战的全部，有人认为目前的算法在提示词增强方面效率低下，而 Neel Nanda 的 thought anchors 论文 对此提供了见解。
  • 长度偏差问题得到凌乱的解决：最近的一篇论文 (arxiv.org/abs/2508.20722) 通过 对较乱的 rollout 进行下采样 缓解了长度偏差问题，训练模型生成更短的回答。
    • 然而，一位成员评论说这只是 循环论证的一个案例，并误读了结果，声称模型正在 学习更有效地推理。
  • HF Tokenizer 遭遇性能瓶颈：一位成员使用 Hf tokenizer 创建了一个新的 16K tokenizer，虽然总 token 数与 gpt2 相似，但 hf tokenizer 极其缓慢且耗费资源，即使使用了批处理和多进程。
    • 他们正在寻求加速策略的建议。
  • ASI 需要非 STEM 评估：成员们讨论了当前 AI 评估方法的扩展挑战，有人认为 STEM 类评估 在没有实质性改变的情况下可能无法适用于预期的活动，而 评估不易获得奖励或评估的技能 这一问题尚未解决。
    • 一位成员询问我们是否能够使用人类偏好数据或特定任务奖励来训练 ASI，但它们似乎仍然容易产生偏见。
  • ASI 类似于神童：一位成员表示 AI 模型将擅长任何我们拥有神童的领域，因为在神童出现的领域中也能看到卓越表现的例子。
    • 另一位成员补充说，音乐的品味和风格不仅仅是父母的反馈，还需要 AI 具备 具身性 (embodied) 以获得更高的信号。

Eleuther ▷ #research (6 messages):

Perfect Diffusion, Hybrid Linear Attention, RWKV efficiency

  • Perfect Diffusion: 博客文章: 一位成员分享了作者撰写的 Perfect Diffusion 论文 2507.12469 的博客文章版本。
    • 该博客文章对原始研究论文中讨论的概念提供了通俗易懂的解释。
  • Hybrid Linear Attention 热潮: 一位成员对 Hybrid Linear Attention 表示出信心，并分享了 2508.01483 和 2507.06457 的链接。
    • 他们似乎对 Hybrid Linear Attention 非常有信心。
  • 综述中缺失 RWKV: 一位成员注意到某项综述中缺少 RWKV 7，推测这 可能是出于效率原因。
    • 他们对未将其纳入其中感到 有些遗憾。

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

lm evaluation harness, GPU memory usage, loglikelihood requests, generate_until requests, batch size recalculation

  • 调试 lm-evaluation-harness 中不均匀的 GPU 显存占用: 一位成员在寻求关于使用 lm-evaluation-harness 在 8 个 GPU 上评估模型时，如何分析或调试不均匀的 GPU 显存占用（GPU memory usage） 的建议。
    • 具体而言，在使用 loglikelihood 请求时，一个 GPU 的显存占用约为 60%，而其他 GPU 约为 25%；而 generate_until 请求仅导致 10% 的 GPU 利用率。
  • 模型参数中的 parallelize：是否有帮助？: 该成员尝试在模型参数中使用 parallelize 参数，但似乎对解决不均匀的 GPU 显存占用 没有帮助。
    • 经澄清，parallelize 旨在用于模型分片（sharding），但所使用的模型足够小，可以放入单个 GPU。
  • 使用 accelerate launch 运行评估: 一位成员分享了他们运行评估的 accelerate launch 命令，旨在复现 Hugging Face 排行榜上 qwen2.5-1.5b-instruct 的结果。
    • 该命令包含 --apply_chat_template、--fewshot_as_multiturn 和 --gen_kwargs 等参数，以忠实地复制排行榜设置。
  • loglikelihood 与 generate_until 的批大小（batch size）重新计算行为不同: 成员注意到，对于 loglikelihood 请求，批大小会重新计算多次，但对于 generate_until 请求则完全不重新计算。
    • 他们推测，为 generate_until 重新计算批大小可能会提高 GPU 利用率，因为这可能会带来更大的批大小。
  • 理解 generate_until 和 loglikelihood 之间的区别: 一位成员建议，loglikelihood 是针对每个样本根据选项数量计算多次的。
    • 相比之下，generate_until 仅计算一次。

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

MLSys conferences, fused rope implementation

  • MLSys 会议信息: 一位成员对 MLSys 会议 表示感兴趣，并提到他们的收入都花在了 GPU 租用时长和社交上。
    • 另一位成员回应道：“不是为了人。不过有很多会议的名字。”
  • Fused RoPE 的低效: 一位成员怀疑某个实现细节导致了 fused RoPE 实现 的低效，特别是在 RoPE 百分比较小时。
    • 他们解释说：“在撰写那篇 neox 论文之后，我们增加了对 fused RoPE 实现的支持，这在 RoPE 百分比较小时肯定效率较低。”

GPU MODE ▷ #general (2 messages):

HackDogs Luma Link

  • 分享了 HackDogs 活动的 Luma 链接: 一位成员分享了 HackDogs 活动在 Luma 上的链接。
    • 一位版主请求此类帖子将来应发布在 events 或 share-your-work 频道中。
  • 版主关于特定频道发布内容的请求: 一位版主请求将分享的链接发布在适当的频道中。
    • 具体而言，他们提到对于此类内容应使用 events 或 share-your-work 频道。

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

Community Meetup, Multi-pass profiler, Triton Developer Conference, tritonbench users, Triton testing strategy

  • 社区见面会已安排：每月一次的社区见面会定于明天 10am PST 举行；参会邀请见此链接。
  • 性能分析框架演示：来自 Meta 的 Kevin Fang 等人将展示 Multi-pass profiler，这是一个用于编排化和 LLM Agentic 性能分析应用的联邦 GPU 工具框架。
  • Triton 大会更新预告：来自 Microsoft 的 Ofer Dekel 将提供关于即将举行的 Triton Developer Conference 的最新动态。
  • tritonbench 用户调查：来自 Meta 的 Cicie Wang 正在询问 谁在使用 tritonbench，并征求关于其使用方式的反馈，特别提到了 OpenAI。
  • 征集测试策略反馈：来自 Meta 的 Bill Yoshimi 正在寻求对当前 Triton testing strategy 的反馈，询问可能遗漏的内容以及哪些地方需要额外的覆盖。

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

Flex Attention, Sparse Attention, block_size vs stride, FlashMask

  • Flex Attention 产生稀疏注意力策略：一位成员使用 flex attention 实现了稀疏注意力，并发现默认的 block_size 为 128，远高于他们的步长（高于 stride=16），导致稀疏度没有提升。
    • 将 block_size 修改为与 stride 相等（16）后，稀疏度增加到 47.73%（默认值为 30%）。
  • 相同稀疏度下 Flex Attention 运行更慢：尽管具有相同的稀疏度，实现的 flex attention 运行速度比使用 block_size=128 的 causal masking 慢约 2x。
    • 该成员表示完全不知道为什么会这样。
  • 建议使用 FlashMask 内核处理注意力：该成员询问是否有更好的现有内核建议，并提到发现了 FlashMask (PaddleNLP 文档)。
    • 他们指出该工具文档不全，因此尚未成功尝试，同时链接到了他们的 beacon-gpt repo。

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

cuSOLVER, cuSolverSP, cuSolverRF, cuSolverDN, cuDSS

  • cuSOLVER 的稀疏计算功能被取代：成员们讨论了 cuSOLVER，特别是其稀疏组件（cuSolverSP 和 cuSolverRF）正被弃用，取而代之的是 cuDSS。
    • 澄清指出，弃用仅适用于稀疏直接求解器，而用于稠密 LAPACK 的 cuSolverDN 仍然有效。
  • cuSOLVER 的未来仍在于稠密计算：澄清指出，弃用仅适用于稀疏直接求解器，而用于稠密 LAPACK 的 cuSolverDN 仍然有效。
    • 这一转变影响了所有涉及稀疏线性代数（sparse LA）的内容，而稠密线性代数（dense LAPACK）将继续在 cuSolverDN 下运行。

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

Partial Warps in CUDA, CUDA thread management, GPU Recommendations for Local CUDA Development

  • CUDA 管理部分 Warp 中的线程：在 CUDA 中处理部分 warp 时，系统倾向于创建 dummy threads，而不是形成少于 32 个线程的 warp，这会导致 thread divergence。
    • 最小的调度单位是 warp，因此试图通过创建有目的的部分 warp 来为每个线程获取更多资源是不可行的，因为 CUDA 会分配一个完整的 warp 并屏蔽掉某些线程。
  • 寻求本地 CUDA 开发的 GPU 推荐：一位成员询问了用于 本地 CUDA 开发 的推荐 GPU，表示有兴趣为自己的配置购买一个。
    • 在给定的上下文中没有提供具体的推荐。

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

Anime Recommendations, Hidden Gem Anime, Nonlinear Storytelling, Grimgar Popularity

  • **Berserk、Naruto 和 Attack on Titan 顶级动漫列表: 一位成员列出了 **Berserk、Naruto 和 Attack on Titan 作为他们最喜欢的动漫。
    • 针对该帖子对冷门神作（hidden gems）的请求，其他用户继续推荐了更多值得一看的系列。
  • 剧透？: 一位成员回忆说，《沙丘》（Dune）在开头就剧透了全部情节，但仍然让读者不得不读到最后。
    • 另一位成员开玩笑说 当作者这么做时，这就不叫剧透，并称之为 非线性叙事。
  • Grimgar 被称为现实主义异世界（Isekai）: 一位成员推荐了《灰与幻想的格林姆迦尔》（Hai to Gensou no Grimgar），将其描述为 如果我们制作一个尽可能现实的异世界会怎样，结果变得极其残酷但最终令人振奋。
    • 该成员补充说，《精灵守护者》（Seirei no Moribito）是 一个发生在江户时代晚期、在刺客追杀中逃亡的成长故事，而《野良神》（Noragami）则是 虽然剧情一般但角色塑造极佳，让你最终会真正关心他们。
  • **Wondance 被誉为优秀的舞蹈漫画: 一位成员推荐了漫画 **Wondance，因为 作者本人也是一名舞者 且 顾问非常出色，但也提醒说 我的一些朋友说他们什么也看不出来。
    • 该成员接着补充道：我喜欢他将整个动作序列压缩进单张静态图像的方式。
  • **Grimgar 在越南很受欢迎: 一位成员很高兴地了解到 **Grimgar 在越南相当受欢迎，已被最大的出版社引进。
    • 另一位成员提到它 在美国几乎完全不为人知。

GPU MODE ▷ #self-promotion (2 条消息):

AMD Developer Challenge, Multi-GPU kernels, Iris library, SHMEM-like Remote Memory Access, MoE Inference Economics

  • AMD 通过 Iris 库挑战开发者: 对于参加 AMD Developer Challenge 的选手，Iris 库可能会对你的多 GPU kernel 有所帮助。
    • Iris 是来自 AMD Research 团队的一个实验性开源库，它为 Triton 增加了 类 SHMEM 的远程内存访问 (RMA) —— 使多 GPU 编程感觉像单 GPU 一样，并让你能够快速迭代设计。
  • Iris 凭借 Triton 的远程内存访问大放异彩: Iris 库的特点是纯 Python + Triton（约 370 行代码），提供 从简单内存操作到融合/重叠 GEMM 的示例，具有熟悉的 PyTorch 和类 Triton API，并支持 MI300X, MI350X, MI355X。
  • 深入探讨 MoE 推理经济学: 如果你对 MoE 推理 话题感兴趣，可以查看我们在 Tensor Economics 上发表的新文章《从第一性原理看 MoE 推理经济学》（MoE Inference Economics from First Principles）。
    • 该文章也在 X 上进行了推广。

GPU MODE ▷ #🍿 (15 messages🔥):

BackendBench PR 讨论，使用 load_inline 和 compile_kernel 的原生代码集成，CuteDSL/tilelang Kernel 生成挑战，nvrtc 后端与自定义 Kernel，PyTorch 中的 compile_kernel 复用

  • BackendBench PR 引发 Kernel 讨论：讨论围绕 BackendBench PR #134 和 PR #135 展开，重点是使用 load_inline 和 compile_kernel 进行原生代码集成。
    • 该集成旨在简化 CuteDSL/tilelang 的流程，但事实证明，即使使用像 Claude 这样的先进模型，生成正确的 Kernel 仍然具有挑战性。
  • 自定义 Kernel 引入 NVRTC 细节：讨论了为自定义 Kernel 支持添加 NVRTC backend，旨在允许不同后端共享各种 DSL 的实现。
    • 特别提到了 PyTorch 中的 compile_kernel 功能，因为它最初的设计意图就是为了在这种情况下促进代码复用。
  • Compile Kernel 的便利性考量：讨论涉及了 compile_kernel 的易用性，包括建议像 load()/load_inline() 一样自动添加 include 路径。
    • 针对 kernel_source 和 header_code 的分离提出了疑虑，并建议将它们合并，但目前的分离是为了避免 C++ 头文件导致的长编译时间。
  • CUDA Include 目录的困境：处理了 cuda_include_dirs 的管理问题，挑战在于如何适配用户安装 CUDA 的多种方式（例如通过 conda）。
    • 提议的解决方案是依赖系统安装，并在找不到目录时提示用户手动设置，而不是实现复杂的自动发现逻辑。

GPU MODE ▷ #submissions (3 messages):

MI300 性能，MI300x8 all2all 性能

  • MI300 荣获第一名：一名成员在 MI300 排行榜上以 2.66 ms 的成绩获得第一。
    • 该提交在 trimul 排行榜上的 ID 为 34649。
  • MI300x8 统治 all2all 排行榜：一名成员在 MI300x8 all2all 排行榜上获得了第一名，初始成绩为 42.0 ms。
    • 该用户随后将时间优化至 15.2 ms，提交 ID 分别为 34654 和 34682。

GPU MODE ▷ #tpu (7 messages):

TPU 实验，Jax TPU 书籍，TPU 版本

  • 建议新 TPU 用户进行实验：一位新 TPU 用户询问从哪里开始，一名成员建议通过实际实验复现 Jax TPU book 中的结果，并指出这“感觉很慷慨”，尽管将其映射到 GPU 并不直接。
  • TPU 升级至 v5 和 v6：一名成员提到 TPU 已升级到 v5 和 v6，并回忆起他们上次使用的是 v3。
    • 同一名成员指出“v5e 一直比较难获得”，他们目前正在使用 v4，尚未升级到 v6e。

GPU MODE ▷ #amd-competition (37 messages🔥):

Rocm Iris library, Nccl vs rccl, SHMEM-like Remote Memory Access, torch.distributed vs hipMemcpyPeer, random expert weights

  • Iris 库为多 GPU Triton 注入活力：AMD Research 发布了 Iris，这是一个实验性的开源库，为 Triton 增加了类似 SHMEM 的 Remote Memory Access (RMA)，支持 MI300X, MI350X, MI355X GPU。
    • Iris 使多 GPU 编程感觉像单 GPU 一样，并允许你在几分钟内快速迭代设计、算法、工作分配和指派策略。
  • NCCL 困惑消除：一位用户注意到在 AMD 参考内核中 dist.init_process_group 使用的是 nccl 而不是 rccl，随后得到澄清，这就像 cuda 一样。
  • 专家权重随机化已实现：为了防止在没有正确分布式通信的情况下通过测试，提交了一个 PR，为每个 rank 上的每个专家分配随机权重。
    • 还指出，为了确保随机性，每个 rank 的 RNG 种子应该不同，并更改为 gen.manual_seed(seed + rank)。
  • P2P 传输性能对决：关于使用 torch.distributed 进行 P2P 传输与在 HIP 中直接调用 hipMemcpyPeer 之间的性能差异展开了讨论。
    • 一位成员建议，torch.distributed 将有更多机会重叠通信和计算。

GPU MODE ▷ #cutlass (3 messages):

CUTLASS, FP8 Blockscaled GEMM, Hopper GPUs

  • CUTLASS 模板编程受到称赞：一位成员为 CUTLASS 的复杂性辩护，断言其开发人员非常聪明且擅长模板编程，并建议“阅读代码”。
    • 他们链接了一篇 NVIDIA 博客文章，内容是关于利用启发式方法和 CUTLASS 4.2 提高 NVIDIA GPU 上的 GEMM 内核自动调优效率。
  • 深入探讨 Hopper GPU 上使用 CUTLASS 的 FP8 Blockscaled GEMM：一位成员分享了 Colfax 网络研讨会的链接，主题为 CUTLASS Deep Dive: FP8 Blockscaled GEMM With CUTLASS on Hopper GPUs。
    • 该网络研讨会似乎专注于在 NVIDIA Hopper GPU 上使用 CUTLASS 进行 FP8 Blockscaled GEMM。

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

bglick: NSight-Systems 通常会为你提供最佳的切入点。

GPU MODE ▷ #low-bit-training (6 messages):

NVFP4 Training, Muon Optimizer, CUDA Kernel for FP4

  • NVFP4 以高精度进行训练：NVIDIA 的一篇博客文章讨论了 NVFP4 如何以 16-bit 的精度以及 4-bit 的速度和效率进行训练。
  • Muon 优化器测试 FP8 和 FP4：一位成员将测试在 Muon 优化器中通过量化进行 FP8 和 FP4 训练会发生什么。
    • 他们预计速度会很慢，但观察其交互方式将会很有趣。
  • 计划为 FP4 编写 CUDA 内核：一位成员计划为 FP4 编写 CUDA 内核并分享。
  • FP4 的步数增加：一位成员正在增加 FP4 的步数，因为他们认为这在技术上是可行的，并且认为这将是有益的。

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

AI 编程质量：Mini vs. Claude，AI 与自然社会结构的概念，AI 在保存个人历史中的作用，创建自定义 AI 图像生成器的挑战与成本，GPT 无响应故障排除

  • Mini AI 会写代码，但 Claude 依然称王：虽然小型、快速的 AI 模型正在进步，并在某些编程任务中变得有用，但在处理复杂编程时，它们仍被认为远逊于 Claude。
    • 一位成员将 Grok code 与其他 mini 模型进行了对比，以说明它们相对的不足，尽管它们在处理简单任务时具有成本效益。
  • AI 并非最自然的伙伴：围绕 AI 与“自然”社会结构的讨论争论了孤立是否是不自然的，并参考了复杂生物如何为了发展而形成社会。
    • 一位成员分享道：完全的孤立对于社会，尤其是对于每一种雌雄异体动物来说，都是没有生产力的。
  • 活着的记忆连锁信：一位成员正尝试创建一种基于许可、由社区运行的方式，来收集塑造他们的人的故事和反馈，类似于一个活的知识库。
    • 这种方法旨在使文化变得更加明确和可控，而不是一种随时间流逝而失去细节的涌现属性；此外，OpenAI 也被邀请参与并提供帮助，但所有内容最终都被过滤了。
  • 自建图像生成 AI 成本高昂：成员们讨论了从零开始创建图像生成 AI 的困难，理由是硬件费用和获取高质量训练数据的成本。
    • 有人指出了本地模型的局限性，因为它们无法进行动态训练，只能利用上下文注入（context injection）。
  • GPT 玩失踪：多位用户报告了 GPT 无响应的情况，尽管多次尝试仍无法提供答案。
    • 故障排除建议包括刷新页面或分享聊天记录，以查看其他人是否能访问该响应。这是一位用户的分享链接。

OpenRouter ▷ #app-showcase (2 messages):

geocoding, photon.komoot.io

  • Photon 提供全球地理编码：一位成员分享了 photon.komoot.io 的链接，建议它可能对全球 geocoding（地理编码）感兴趣的人有用。
  • 使用 Photon 进行地理编码：用户分享了 photon.komoot.io 作为资源。

OpenRouter ▷ #general (87 messages🔥🔥):

Deepseek 的替代方案，OpenRouter 匿名性，Gemini 2.5 flash 图像问题，Chutes deepseek v3 免费版，OpenRouter 服务器问题

  • Kimi 和 GLM 作为 Deepseek 的替代方案：成员建议使用 Kimi K2 (temp=0.6) 和 GLM 4.5 作为 Deepseek 闲聊的替代方案，并指出了 OpenRouter 上的免费模型列表。
    • 一位成员表示，与直接使用 Chutes 或 Deepseek 相比，使用 OpenRouter 提供了更好的匿名性。
  • Gemini 2.5 Flash 图像失败：一位用户报告了一个问题，即 Gemini 2.5 flash image 有时会发送文本 “here is the image”，但实际上并没有发送图像。
    • 讨论中未提到具体的解决方案或变通方法。
  • Deepseek V3 不稳定性困扰：用户报告 Deepseek V3 变得不稳定，并产生语法不通的输出。
    • 一位遇到乱码输出的用户建议降低 temperature，其他遇到同样问题的用户使用的是 V3 0324。
  • Claude Sonnet 的代码能力被削弱：一位用户报告说他们的 Claude Code 使用受到了严重限制，连续使用时间被限制在不到一小时。
    • 有人建议 Codex 是一个不错的替代品，新的条款可能是导致限制的原因。
  • OpenRouter 的 JanitorAI 和 Chub.ai 搞反了？：一位用户根据 SimilarWeb 的指标和 JanitorAI 的短暂宕机情况，推测 OpenRouter 可能在其内部应用数据库中将 JanitorAI 和 Chub.ai 搞混了。
    • 该用户认为 OpenRouter 只是获取 X-referer header 并将其存储，修剪掉域名之后的所有内容。

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

``

  • 空频道，无新模型：OpenRouter Discord 上的 new-models 频道似乎是空的，没有需要总结的新模型讨论或公告。
    • 需要进一步监控，以便在未来捕获任何相关的新模型更新。
  • 等待新模型消息：目前，该频道缺乏符合详细总结标准的任何具体细节、链接或讨论。
    • 内容的缺失表明在新模型相关活动方面处于平静期。

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

Rork App, TAU-Bench, Parallel AI, Anthropic's Series F, OpenAI Acquires Statsig

  • Rork App 冲上 App Store 排行榜：投资者 Matt Shumer 介绍了新的 Rork app，这是一个可以根据需求生成 iPhone 应用的 AI tool，并通过 这条 X 帖子 展示了它在几分钟内生成 Notion clone 可用前端的能力。
  • TAU-Bench 解决 LLM 难题：Lewtun 通过 这条 X 帖子 介绍了 TAU-Bench，这是一种解决 LLM hallucinations（幻觉）并应对互联网本身复杂性的新方法。
  • Anthropic 达到惊人的 1830 亿美元估值：Anthropic 已获得 130 亿美元 的 Series F 融资，投后估值达到惊人的 1830 亿美元，详见 其官方公告。
  • OpenAI 正式收购 Statsig：OpenAI 正在收购产品实验平台 Statsig。根据 Statsig 官方博客文章 和 OpenAI 的 X 帖子，Statsig 将继续从其西雅图和旧金山办公室独立运营，保留所有员工，并优先为现有客户提供不间断的服务。

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

E2B, Open Interpreter, Langchain Python Tool, LlamaIndex Code Interpreter, Instruct Model vs Base Model

  • E2B 与 Open Interpreter 联手！：成员们分享了一些酷炫的 Agentic 工具链接，例如 E2B、Open Interpreter、Langchain Python Tool 和 LlamaIndex Code Interpreter。
  • 澄清 Instruct 与 Base 模型：一位正在学习 Agent 的成员询问了 Instruct 模型和 Base 模型之间的区别，以及 Gemini 和 GPT4 是否属于 Instruct 模型。
  • 在 Android 上进行 SmolVLM2 视频微调：一位成员询问如何使用视频数据微调 smolvlm2，以及如何在 Android 设备上进行推理。
  • LightEval 社区任务受到关注：一位成员询问如何使用 lighteval 中 community_tasks 提供的 arabic_evals。

HuggingFace ▷ #today-im-learning (1 条消息):

reubencf: 我教科书的第 7 章

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

Prompt Engineering, arxiv-agent, chess engine

  • Promposer.AI 旨在实现更好的 Prompt Engineering：一名成员发布了一款名为 Promposer.AI 的新型 AI 开发工具，用于 prompt engineering。
    • 该工具允许用户在 IDE、浏览器或流水线中编写和迭代 prompt、添加上下文/工具并运行结构化测试用例，如此视频所示。
  • arxiv-agent 通过角色设定辩论研究主张：一名成员介绍了 arxiv-agent，这是一个 Agentic AI 系统，它通过 ID 读取 arXiv 论文，然后生成 3 个角色（乐观主义者、怀疑论者、伦理学家）来辩论其主张，代码已在 GitHub 上开源。
    • Hugging Face Spaces 上提供了一个托管 Demo，一位用户指出，它仍然会输出一些让对核理论（Nuclear Theory）一窍不通的人看起来很专业的内容。
  • 新款 chess engine 首次亮相：一名成员宣布他们在 GitHub 上发布了一个 chess engine。
    • 该用户提到它目前还不是非常强大。

HuggingFace ▷ #core-announcements (1 messages):

ZeroGPU Demos, AOT Compilation

  • ZeroGPU Spaces 获得 Ahead-of-Time 编译支持：Hugging Face 宣布了一种使用 ahead-of-time compilation (AOT) 优化 ZeroGPU 驱动的 Demo Spaces 的新方案，旨在提供更流畅的用户体验。
    • 用户现在可以利用这个方案来提升其 Demo 性能。
  • 优化 ZeroGPU 驱动的 Demo：通过 ahead-of-time compilation 提供的新优化方案，可用于优化您的 ZeroGPU 驱动的 Demo。
    • 这种优化应该有助于提供更流畅的用户体验。

HuggingFace ▷ #agents-course (2 messages):

TextToImageTool issues, Smolagents task failure, Agents Course Materials

  • TextToImageTool 导致 Smolagents 任务停滞：一位用户报告 TextToImageTool 无法工作，由于无法创建图像，导致无法完成 Unt.1 Smolagents 任务。
    • 该用户附上了图片，寻求解决该问题的帮助和建议。
  • Agents 课程资料位置公布：针对用户的请求，另一名成员分享了 agents-course GitHub 仓库的链接。
    • 该成员指出，相关信息在介绍视频中也有提供。

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

Mojo Async, Mojo + GPU Execution, CUDA programming model, Data movement expenses

  • Mojo 异步执行即将到来：随着 async 特性引入 Mojo，用户将能够 await GPU 就绪，并在此期间执行 CPU 任务。
  • Mojo 借鉴了 CUDA 执行模型：与 CUDA 类似，Mojo 中的 GPU 执行是异步的，可以在加速器上启动 Kernel，同时在主机（CPU）侧进行工作，稍后再复制结果，详见文档。
  • 尚未实现所有硬件设备的自动执行：目前，Mojo 需要手动实现 CPU 和 GPU 的同步计算，尚无自动的语言级支持。
  • 数据传输对于 CPU/GPU 同步执行来说开销巨大：尚未实现在所有可用硬件上自动执行，是因为数据传输（Data Movement）成本很高，而且通常只有一个设备最适合解决特定问题。

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

Memory-safe bidirectional pointers in Mojo, __moveinit__ and linear types in Mojo

  • 内存安全双向指针指日可待：围绕在 Mojo 中使用 __moveinit__ 和 linear types 实现内存安全双向指针的潜力展开了讨论。
    • 一名成员对其中的影响以及如何利用这些特性表示好奇。
  • Linear Types 实现内存安全：目前正在探索使用 __moveinit__ 和 linear types 进行 Mojo 的高级内存管理。
    • 这种方法预计将增强指针操作的安全性和效率。

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

DeviceContext 代码，RDNA2 的 WMMA 问题，matmul 回退，目标信息管理

  • DeviceContext 代码匹配：一名成员将检查内部 DeviceContext 代码中用于平台检查的基准移动，以实现匹配。
    • 另一名成员将调查为什么他们在尝试向 Pascal 系统部署类似内容时看到编译时间激增，并警告其他成员可能会遇到同样的情况。
  • WMMA 对 RDNA2 来说是个问题：一名成员指出，缺乏 WMMA 也是 RDNA2 的一个问题，由于 AMD CPU 使用 RDNA2 作为 iGPU，该架构仍然相当流行。
    • 另一名成员询问，为 GPU 类设备建立一个通用的回退（fallback）方案是否有意义，即直接使用目标设备拥有的任何 SIMD。
  • matmul 回退已实现：一名成员提到，在开发出特定设备的加速功能之前，一个朴素的 matmul 回退方案作为新架构的默认设置可能是合理的。
    • 到目前为止，所有内容都是针对 Ampere+ 和 CDNA3+ 架构进行调优的，在这些架构中可以依赖 Tensor / Matrix Core 的存在。
  • 旧设备避开了回退路径：一名成员进行了初步探究，发现部分问题似乎在于假设 Nvidia 拥有 Tensor Core 而 AMD 拥有 WMMA/MFMA。
    • 这导致旧设备偏离了回退路径，他们将认真审视目前目标信息（target information）的管理方式。

Yannick Kilcher ▷ #general (7 messages):

DeepSeek R1 颠覆性影响，深度学习课程，统计与概率书籍

  • DeepSeek R1 的颠覆即将到来？：一名成员对未来 DeepSeek R1 级别的颠覆性进展表示乐观，理由是该领域目前非常活跃。
    • 他们认为 有很多人正在为此努力，这 增加了有人提出有趣见解的概率。
  • 深度学习课程优于 Yann LeCun 的？：一名成员建议，某个链接的机器学习课程可能比 Yann LeCun 的深度学习课程更好。
    • 该成员附带了一张 图片 来支持他的观点。

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

FastVLM, 通信复杂度, Sign-Rank 边界, VibeVoice

  • FastVLM 论文即将发布：小组很快将关注 FastVLM 论文。
    • 小组还计划讨论 FastVLM。
  • 论文解释处于可理解的水平：一名成员表示，论文中的解释似乎处于一个易于理解的高层水平。
  • 发布论文供参考：一名成员发布了 这篇论文 供参考。

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

提示词注入, 图像缩放攻击, AI 系统安全

  • 提示词注入结合别名攻击：一种新的提示词攻击将别名（aliasing）与 提示词注入 (Prompt Injection) 结合在一起。
  • 图像缩放被武器化用于攻击 AI：一名成员链接了一场关于将图像缩放武器化以攻击生产级 AI 系统的讨论，详见 此 X 帖子 和 另一个 X 帖子。

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

GPT-5 vs o4-mini, 模型调整期, 流式响应与 KYC, Nebius GPT-OSS, Livebench.ai

  • 相比 GPT-5，用户更倾向于 o4-mini: 一位成员在使用了 3 周 GPT-5/GPT-5-mini 后切换回了 o4-mini，发现它更容易引导，且生成的代码更符合其喜好。
    • 他们觉得 GPT-5 正在向 Gemini/Claude 的复杂性靠拢，带有不必要的改动且代码更难消化，但另一位成员表示其解决问题的能力要好得多。
  • 模型调整期确实存在: 成员们讨论了切换模型时需要一段调整期，尽管大多数人不会换回去。
    • 一位成员提到了 3 周的调整期，另一位成员提到，由于不想进行 KYC 认证，现在等待响应变得有些令人烦恼。
  • Nebius 搞砸了 GPT-OSS，挺有意思的: 一位成员分享了一个关于 Nebius 搞砸 GPT-OSS 的 Reddit 链接。
    • 他们评论道：噢天哪，这是 Nebius 吗……他们不是把 GPT-OSS 搞砸了吗，哈哈真惨。
  • Livebench.ai 看起来很有趣: 一位成员分享了 Livebench.ai 的链接并评论说它看起来很有趣。
    • 作为回应，另一位成员指出，如果没有 completion tokens 数量，很难知道 reasoning high 是否真的被激活了。
  • Qwen 在 polyglot 上的表现优于预期: 一位用户评论说，Qwen 在 polyglot 上的评分远低于其实际使用表现。
    • 对话是由“中等推理（medium）优于高等推理（high）”这一事实引发的，根据分享的图表，mini 和 qwen 的表现也令人印象深刻。

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

baboluo: 我必须指定 model: gemini/gemini-2.5-pro，而不是 model: gemini

DSPy ▷ #papers (1 条消息):

batmanosama: https://arxiv.org/abs/2505.17829

DSPy ▷ #general (16 条消息🔥):

Generative UI, OCR 分析器, GEPA, DSPy 程序优化, JIT 编译器

  • 斯坦福发布 Generative UI: 斯坦福推出了 Generative UI，它使用 FSM-graph 界面流作为新的原语，将 UI 视为由 LLM 自动合成和精炼的黑盒插件，更多信息请见 GitHub。
  • 使用 OCR 分析器应对上下文窗口限制: 一位用户正在构建一个 PoC OCR 分析器，在反馈中包含 base64 图像数据时遇到了 GEPA 的上下文窗口问题，并询问如何解决。
    • 一位成员建议，如果图像已经是输入的一部分，则不需要包含在反馈中；此外，他们指向了一个 GitHub pull request，该请求应该会使在 GEPA 中处理图像变得更容易。
  • 解码 DSPy 程序优化秘籍: 一位用户质疑为什么不推荐将从 DSPy 程序中提取的优化 Prompt 用于推理，并想知道考虑到 DSPy 的体积/复杂性，是否可以在生产环境中弃用它。
    • 一位成员解释说，优化的 DSPy 程序涉及 trace、训练示例、demo 和 signature，而不仅仅基于 Prompt；在 DSPy 中，Prompt 由用户指令、来自 adapter 的格式化类型以及 system message 中的 few-shot 示例组成。
  • 探索 DSPy Lambda 部署方案: 社区成员讨论了在 AWS Lambda 中部署 DSPy 程序的解决方案，包括使用 Docker 镜像来绕过大小限制。
    • 另一位成员建议可以使用 lambda layers 来解决。此外，另一位成员指出，新版本已将二进制文件大小缩减至 10Mb 以下。
  • 优化器正在演变成 JIT 编译器？: 该想法建议为优化器自动化指标生成和数据集创建，由优化器动态选择数据点进行测试。
    • 另一位成员回答说，如果优化器选择或创建了一个数据点进行测试，那么它甚至不需要是一个优化器，而是一个 JIT 编译器。

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

Manus Advantages, Agentic Space Competition, Name Liberation

  • Manus 在 Agent 竞赛中保持领先：一位用户认为，尽管 agentic space 的竞争已变得异常激烈，Manus 仍保留了一些优势。
    • 未就具体优势展开进一步讨论。
  • 名称解放的幻想：一位用户对自己的名字表示困惑，随后发表了关于“解放 manus”的奇思妙想。
    • 该用户随后幽默地询问自己当前所在的位置，增添了一丝俏皮的荒诞感。

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

OpenRouter, Qwen Model Suite

  • OpenRouter 被确认为来源：一位用户指出某条消息来源于 openrouter。
  • Qwen 模型套件因其完整性受到赞誉：一位用户表达了对 Qwen 模型套件的偏好，理由是其完整性和一致的性能表现。
    • 该套件现在包含图像编辑和 WAN 视频生成功能。

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

In-place operations in Tinygrad, Memory Efficiency, Production Readiness of Tinygrad

  • 探索 Tinygrad 的 In-place 操作：一位用户询问了 Tinygrad 中 in-place operations 的安全性，并将其与 PyTorch 进行了对比。在 PyTorch 中，此类操作可能会破坏计算图并导致梯度错误。
    • 该用户旨在了解 Tinygrad 是否已具备生产就绪性，以应对需要对 tensor 进行 in-place 修改以提高内存效率的场景，而不是在每次迭代时生成新的 tensor。
  • 通过 In-place Tensor 修改实现内存效率：用户正寻求 in-place 修改输入 tensor 以增强内存效率，从而避免在每次迭代时创建新的 tensor。
    • 这种方法与生成新 tensor 的方式形成对比，后者可能更消耗内存。
← 返回首页