AI News

Claude Sonnet 4.6：4.5 版本的利落升级，整体表现更佳，但仍有一些注意事项。

· MjAyNi0w

Anthropic 推出了 Claude Sonnet 4.6。作为 Sonnet 4.5 的升级版本，它在代码编写、长文本推理、智能体规划（agent planning）、知识性工作和设计方面实现了全面提升，并新增了 100 万 token 的上下文窗口（测试版）。

基准测试显示，Sonnet 4.6 在 GDPval-AA ELO 中以 1633 分保持领先，其 token 使用量显著增加，且输出美感有所提升。目前已集成的平台包括 Cursor、Windsurf、Microsoft Foundry 以及 Perplexity Pro/Max。早期用户反馈曾提到一些性能回退问题，但随后已得到修复。

定价方面，Sonnet 4.6 与 Sonnet 4.5 保持一致。工具方面的增强功能包括用于过滤结果的代码执行能力，这进一步提高了任务的准确性和效率。

#long-context #agent-planning #knowledge-work #benchmarking #tokenization #model-integration #code-execution #model-updates #aesthetic-quality claude-3-sonnet-4.6 claude-3-sonnet-4.5 claude-3-opus-4.5 claude-3-opus-4.6 anthropic cursor microsoft perplexity-ai cognition

Anthropic 再获一胜。

AI 新闻（2026/2/16 - 2026/2/17）。我们为您检索了 12 个 subreddit、544 个 Twitter 账号 以及 24 个 Discord（包含 261 个频道和 11323 条消息）。预计节省阅读时间（以 200wpm 计算）：1096 分钟。AINews 网站 允许您搜索所有往期内容。提醒一下，AINews 现已成为 Latent Space 的一个板块。您可以选择订阅/退订 邮件发送频率！

尽管有很多关于 “Sonnet 5” 的传言，但 Anthropic 今天选择发布了 Sonnet 4.6，将其这款性价比极高的主力模型提升到了与 Opus 4.6 相当的水平。据称 Sonnet 在偏好上优于 4.5 Opus，并具备 100 万 token 的上下文，尽管在常规基准测试中普遍落后。此外，在 GDPVal-AA（见下文）上，它的 token 使用量增加了 4.5 倍，因此在某些任务中的总成本可能高于 Opus。API 平台工具和 Excel 集成也获得了小幅升级。

关键亮点包括在 Computer Use 方面的长期改进。该功能最初于 2024 年 10 月推出，当时速度极慢且准确度低到不具实用性，但现在已产品化为 Claude Cowork。据传，该产品的采用成功率高于 OpenAI 对应的 Operator 和 Agent 迭代版本。

我们调整了下方的 Twitter 摘要以包含更多数据点，但实际上，以上就是您真正需要了解的全部内容。

AI Twitter 综述

头条新闻：Sonnet 4.6 发布

事件回顾（时间线 + 核心声明）

Anthropic 发布了 Claude Sonnet 4.6 作为 Sonnet 4.5 的升级版，将其定位为功能最强大的 Sonnet 模型。它在 coding、computer use、长上下文推理、agent 规划、知识工作和设计方面都有广泛改进，并提供 1M-token 的上下文窗口（beta 版） [@claudeai]。在正式发布前就有初步传闻（“Sonnet 4.6 即将到来！”）[@kimmonismus]。随后，发布引发了一波基准测试通报、工具/平台集成（Cursor, Windsurf, Microsoft Foundry, Perplexity/Comet 等），以及早期用户对质量和可靠性褒贬不一的反馈。

此推文集中的关键传播信号：

  • 官方公告 + 功能列表 + 1M 上下文 (beta) [@claudeai]
  • Anthropic 员工表述：“接近 Opus 级别…… 相比 4.5 有了疯狂的飞跃” [@alexalbert__]
  • 基准测试片段（SWE-Bench Verified, ARC-AGI-2, 相对 Opus 4.5 的偏好, GDPval, Vending-Bench 等），来自社区/基准测试账号 [@scaling01], [@scaling01], [@scaling01]
  • 独立评估机构更新：Sonnet 4.6 在 GDPval-AA ELO（agentic 知识工作）中领先，但 token 使用量远高于 4.5 [@ArtificialAnlys]
  • 价格声明：“与 Sonnet 4.5 价格相同” [@kimmonismus]
  • 发布后的“退化？”报告：幻觉函数名 / 结构化输出损坏；随后“似乎已修复” [@rishdotblog], [@rishdotblog]

事实 vs 观点（清晰区分）

事实 / 可验证的主张 (来自推文)

  • Sonnet 4.6 被 Anthropic 描述为跨多个能力领域的全面升级 (full upgrade)，并包含 1M token context window (beta 版) [@claudeai]。
  • 引用的 Benchmark 数据点：
    • 79.6% SWE-Bench Verified，58.3% ARC-AGI-2 (如推文所述) [@scaling01]。
    • “用户在 59% 的情况下更倾向于 Sonnet 4.6 而非 Opus 4.5” [@scaling01]。
    • “Sonnet 4.6 是 GDPval 上表现最好的模型” (声称) [@scaling01]。
  • Artificial Analysis (独立基准测试机构) 声称：
    • Sonnet 4.6 达到了 GDPval-AA ELO 1633 (在 “adaptive thinking mode” 和 “max effort” 模式下)，在他们的 GDPval-AA 排行榜上排名第一，但在 Opus 4.6 的 95% CI (置信区间) 范围内 [@ArtificialAnlys]。
    • 运行 GDPval-AA 的 Token 消耗：Sonnet 4.6 总共使用了 280M total tokens (相比之下 Sonnet 4.5 为 58M)；Opus 4.6 在等效设置下使用了 160M [@ArtificialAnlys]。
    • 在 GDPval-AA 的输出中，Sonnet 4.6 提升了生成文档/演示文稿的 aesthetic (美学) 质量 (相对于 4.5) [@ArtificialAnlys]。
  • 工具更新：Anthropic 网页搜索/抓取工具现在执行代码来过滤结果；据报告效果：启用后 BrowseComp 准确率提升 13%，且 input tokens 减少 32% (如推文所述) [@alexalbert__]。
  • 提到的可用性 / 集成：
    • Cursor: “Sonnet 4.6 现已在 Cursor 中可用……在长任务上比 4.5 有显著提升，但智能程度低于 Opus 4.6” [@cursor_ai]。
    • Windsurf 可用性 [@cognition]。
    • Microsoft Foundry 可用性 [@Azure]。
    • Perplexity Pro/Max 可用性 [@perplexity_ai] 以及面向 Pro 用户的 使用 Sonnet 4.6 的 Comet browser agent [@comet]。

观点 / 解读 (尚未定论的内容)

  • “接近 Opus 级别的能力……疯狂的跨越” [@alexalbert__] 是定性表述 (尽管与某些 Benchmark 的趋势一致)。
  • “接近人类水平的 computer use” 外推 [@alexalbert__] 很大程度上取决于使用了哪些 “computer use” 评估 (evals) + 框架 (harnesses) + 任务分布。
  • “更温暖、更友善……更聪明、更像喝了过量咖啡” 纯属 UX 氛围感 (vibe) [@sleepinyourhat]。
  • “审美水平爆表” / SVG 天际线轶事是主观的 (但指向了设计/视觉生成能力的提升) [@scaling01]。
  • 发布后的可靠性担忧 (“到处是幻觉……4.6 表现糟糕”) 是来自特定工作流的轶事报告，但值得注意，因为它们是在“相同任务”上与 4.5 进行的对比 [@rishdotblog]。

提取的技术细节 (数字、Benchmark、系统影响)

推文中披露的核心模型/产品参数

  • 上下文窗口： 1M tokens（beta） [@claudeai]。
  • 定价: “与 Sonnet 4.5 价格相同” [@kimmonismus] (推文中未直接引用具体 $/tok，但注意 RundownAI 提到的上下文是 “Sonnet 定价 [每百万 token $3/$15]” [@TheRundownAI])。
  • 搜索/抓取工具变更: 通过可执行代码进行前置上下文过滤；BrowseComp 准确率 +13%，input tokens -32% [@alexalbert__]。
    • 系统层解读：这标志着向 工具侧 “compute before context” 的明确转变——通过增加工具端的计算开销来减少 Prompt 预算，并提高检索到的 Context 中的信噪比。

基准测试及其暗示（包含注意事项）

  • SWE-Bench Verified 79.6% (已发布) [@scaling01]。
    • 解读：SWE-Bench Verified 对测试框架（harness）、超时设置、仓库（repo）配置以及工具可靠性非常敏感。即便如此，79.6% 在当前的通用讨论中仍属于“前沿级别（frontier-tier）”。
  • ARC-AGI-2 58.3% (已发布) [@scaling01]。
    • 另见长期趋势声明：“141 天内……在 ARC-AGI-2 上从 13.6% 提升到 60.4%”（Sonnet 系列的进展，推测是 4.5→4.6 或更早版本到现在的提升） [@scaling01]。
  • 偏好评估： “相比 Opus 4.5，胜率为 59%” [@scaling01]。
  • GDPval-AA (Artificial Analysis)： ELO 1633，排名第 1 但在统计学上与 Opus 4.6 重叠；Sonnet 4.6 的 token 使用量为 2.8 亿，而 Sonnet 4.5 为 5800 万；运行 GDPval-AA 的成本“仅略高于 Opus 4.6”（由于 token 使用量） [@ArtificialAnlys]。
    • 对工程师的重要启示：“最佳性能”可能是通过消耗更多思考 token（thinking tokens）换取的，这会影响延迟和开销；路由器（router）可能会有选择性地调用 4.6。
  • Vending-Bench Arena 策略声明：在 1M context 下，Sonnet 4.6 采用“能力优先，随后转向盈利”的计划 [@felixrieseberg]。
    • 这是一个归功于长上下文（long-context）规划能力的行为转变（behavioral shift）的罕见案例，但目前仍只是单一基准测试的轶事。

成本/延迟 + 吞吐量信号

  • 工程师们明确注意到，前沿实验室正在“狂飙数百万个 token……像盖摩天大楼一样构建脚手架（scaffold）” [@scaling01]，这与 Artificial Analysis 的披露相吻合，即 Sonnet 4.6 在 GDPval-AA 上所需的 token 数量约为 Sonnet 4.5 的 ~4.8 倍 [@ArtificialAnlys]。
  • Cursor 的说明：Sonnet 4.6 在“长任务”上表现更好，但在“智能水平上低于 Opus 4.6” [@cursor_ai]。这暗示了实际的路由选择：将 Sonnet 4.6 作为默认的长周期主力工具；将 Opus 作为最高能力上限。

数据集中的不同观点

强烈正面 / “这是一次巨大的飞跃”

  • Anthropic 方面：“能力最强的 Sonnet……全面升级……1M context” [@claudeai] 以及 “接近 Opus 级别……飞跃……惊人” [@alexalbert__]。
  • 基准测试支持者：提及 SWE-Bench/ARC-AGI-2 [@scaling01]，GDPval 最佳模型声明 [@scaling01]，“在 Vending-Bench 2 上碾压 Gemini 3 和 GPT-5.2” [@scaling01]。
  • 实践者：“现实世界工作的猛兽……电脑使用（computer usage）” [@kimmonismus]，“电脑使用方面的佼佼者……在长会话中表现更稳定” [@mikeyk]。

中立 / 采用与定位说明

  • “没有 Sonnet 5”的反应 [@dejavucoder] 反映了预期管理而非能力问题。
  • Cursor 审慎的产品说明（优于 4.5，低于 Opus 4.6） [@cursor_ai]。
  • Artificial Analysis：GDPval-AA 排名第 1，但在 Opus 4.6 的置信区间（CI）内 + 披露其使用了更多 token [@ArtificialAnlys]。

负面 / 怀疑 / “出问题了”

  • 可靠性退化报告：在 Agent 工作流中出现幻觉函数名；结构化输出错误；“4.5 依然表现出色” [@rishdotblog]。后续：“不管之前是什么问题，似乎已经修复了！” [@rishdotblog]。
  • 成本敏感：“Sonnet 和 Slopus……疯狂消耗我的额度” [@scaling01]，加上后来的“价格令人心痛” / 成本后续追踪（提供的片段中未详细说明） [@scaling01]。
  • 基础设施/产品维度的对比观点：“比 xhigh 贵 50%，比 5.2 codex 贵 228%……但相比 4.5 有巨大改进” [@teortaxesTex]——这说明 Sonnet 4.6 虽然有提升，但根据工作负载的不同，相比替代方案可能存在成本效率不足的问题。

背景：为什么 Sonnet 4.6 至关重要（工程影响）

1) 长上下文正变得“可操作化”，而不仅仅是一项技术指标。 此次发布将 1M token 窗口 推向了 Sonnet 层级 [@claudeai]。但 Artificial Analysis 披露，Sonnet 4.6 在“自适应思维/最大努力（adaptive thinking/max effort）”配置下运行 GDPval-AA 消耗了 280M tokens [@ArtificialAnlys]，这提醒我们：长上下文 + 长思考（long-think）可能会在无形中突破你的预算上限。预计会出现更多 routing（路由）、摘要、上下文管理以及“检索后过滤” 模式（这与新的 search/fetch 过滤改进一致 [@alexalbert__]）。

2) Agent 性能表现的宣称越来越依赖于测试框架（harness）。 GDPval-AA 使用了一个 agentic harness（shell + 浏览器循环），而 Sonnet 4.6 的领先地位是在特定设置（“自适应思维模式”、“最大努力”）下报告的 [@ArtificialAnlys]。Cursor 指出，它在长任务上表现更好，但在原始智能方面低于 Opus [@cursor_ai]，这再次证明了“最佳模型”并不是一个标量；它是 工作负载 × 测试框架 × 预算 的综合结果。

3) Computer use 正成为一项核心能力，而 Sonnet 正在被推向这一领域。 多条推文强调了 computer use 的进展和接近人类水平的框架 [@alexalbert__]，像 Perplexity 的 Comet 浏览器 agent 这样的部署明确为 Pro 用户默认使用 Sonnet 4.6 [@comet]。

4) 发布风险：微小的服务/配置更改看起来可能像“模型退化（model regressions）”。 据报告，Opus 4.6 和 Sonnet 4.6 发布后出现了幻觉激增 [@rishdotblog]，随后又“似乎已修复” [@rishdotblog]——这读起来更像是潜在的 routing、工具链、system prompt 或安全层更改，而非权重问题。对于团队而言：尽可能锁定版本，运行 canary evals，并独立于“聊天质量”之外监控结构化输出有效性和 tool-call 的正确性。

其他主题（标准覆盖范围）

开源模型与独立基准测试 (Qwen/GLM/Seed/Aya 等)

  • Artificial Analysis 对 Qwen3.5-397B-A17B（总参数 397B / 激活参数 17B MoE，Apache 2.0，262K ctx，原生多模态） 进行了深度解析；该模型在 agentic evals 上取得了巨大进步，但根据其指标，幻觉率仍然很高 [@ArtificialAnlys]。
  • GLM-5 被引用为 WeirdML 和其他基准测试中的强劲开源模型（WeirdML 为 48.2%；并与 Opus/gpt-* 的宣称进行对比） [@htihle]，此外 GLM-5 技术报告亮点包括：采用 DSA、异步 RL 基础设施、agent RL 算法 [@Zai_org]。
  • 字节跳动发布 “Seed-2.0”（agent/推理/视觉；“无蒸馏”；初期仅限中国区） [@TsingYoga]。
  • Cohere Labs 推出了 Tiny Aya：3.35B 开源多语言模型系列（支持 70 多种语言；“可在手机上运行”），并附带详细报告，声称在 64 个 GPU 上完成训练 [@nickfrosst], [@_akhaliq], [@mziizm]。

Agent、测试框架、内存与长周期基础设施

  • “Agent World Model (AWM)” 提出全合成可执行环境（1,000 个环境、35,062 个工具、10,000 个任务、SQL 支持的状态、验证代码），用于 RL 工具使用 Agent [@dair_ai]。
  • Lossless Context Management (LCM) / Volt 声称：采用带有无损指针的确定性分层 DAG 压缩；在 OOLONG 上，“在 32K→1M 的所有上下文长度下均击败了 Claude Code”（据报道）[@dair_ai]，并被进一步转发 [@omarsar0]。
  • Moltbook 多 Agent “社会”研究：涉及 260 万个 LLM Agent、30 万篇文章、180 万条评论；宏观“文化”趋于稳定，微观影响接近噪声；对“单纯增加 Agent 数量”的假设提出了批评 [@omarsar0]。
  • LangChain “Harness Engineering” 主题：追踪 (traces) → 评估挖掘 (eval mining) → 自验证循环；TerminalBench 的定位 [@Vtrivedy10]，以及 LangSmith Insights 调度 [@LangChain]。
  • 开源了一个 Agent 运行时 (“Hankweave”)，专注于消除上下文、可维护性以及跨模型的可重用模块 [@hrishioa]。

系统与推理优化（内核、调度、吞吐量）

  • Carmack 提议通过 UVM 分页 + MPS shim 实现类操作系统的 GPU 任务抢占，旨在实现秒级的任务切换（承认存在抖动风险）[@ID_AA_Carmack]。
  • Moondream MoE 内核：通过根据实际路由分布调整启动配置，使速度提升 2.6%；内核约占运行时间的 37% [@vikhyatk]。
  • Together 风格的 “ThunderAgent” / “程序抽象”，用于端到端 Agent 工作流调度；声称在不损失质量的前提下，部署/推理速度提升高达 3.9 倍（如文中所述）[@ben_athi]，以及解释推文 [@simran_s_arora]。

前沿产品动向：Codex, Grok，“computer use” 竞争

  • Codex 使用报告：用户尝试（但未能）达到限制；在订阅窗口内存在高并发的 Agent 使用 [@theo]。
  • OpenAI 基础设施招聘宣传（Agent 编排、沙箱、可观测性）[@gdb]。
  • Grok 4.20 / 4.x 的讨论包括发布通知和架构声明，以及 Elon 极具政治极化色彩的表述 [@kimmonismus], [@elonmusk]，批评者称其性能弱于 “Flash” 模型 [@teortaxesTex]。

机器人、视频/图像生成及多模态研究

  • 宇树 (Unitree) 类人机器人性能讨论（声称具备分布式协作、地形适应、安全间距、多自由度操控能力）[@ZhihuFrontier]。
  • “感知类人机器人跑酷 (Perceptive Humanoid Parkour)”（深度感知的长周期跨越）[@zhenkirito123]。
  • 字节跳动 BitDance：14B AR 图像生成器，预测二进制视觉 Token；声称在 ImageNet 256 上 FID 为 1.24 [@iScienceLuvr]，以及作者的推广 [@multimodalart]。
  • “Sphere Encoder” 球形潜空间中的少步图像生成；Meta/Goldstein 的推文详细介绍了 ImageNet 的 65K 潜空间维度和少于 5 步的精细化过程 [@tomgoldsteincs]。

AI Reddit 摘要

/r/LocalLlama + /r/localLLM 摘要

1. Qwen3.5 模型发布与性能

  • Qwen3.5-397B-A17B 发布！！ (热度: 1088): **Qwen3.5-397B-A17B 已在 Hugging Face 发布，这是一个拥有 3970 亿 参数的模型，原生上下文长度为 262,144 个 Token，最高可扩展至 1,010,000 个 Token。该模型属于 Qwen 系列，以其大规模语言处理能力而闻名。此外，此处还提供了 GGUF 版本，可能为特定用例提供优化后的性能。** 社区对此模型的性能充满期待和好奇，用户们正跃跃欲试准备测试其能力。

  • Qwen3.5-397B-A17B 模型在解码吞吐量（decoding throughput）方面有显著提升，比其前代产品 Qwen3-235B-A22B 快 3.5 倍到 7.2 倍。这表明其在效率上有实质性增强，对于需要快速处理大规模数据集的应用至关重要。
  • 该模型支持 262,144 tokens 的原生上下文长度（context length），并可扩展至 1,010,000 tokens。这种可扩展性对于需要处理超长数据序列的任务特别有利，在各种计算场景中提供了灵活性和可扩展性。

  • 一位用户在 Hugging Face 上分享了该模型的 GGUF 版本链接，表明了可用于部署的不同格式。这对于希望将模型集成到不同环境或针对特定硬件配置进行优化的开发者来说非常有用。

  • Qwen3.5-397B-A17B 的 Unsloth GGUF 版本 (热度: 716): 图片重点介绍了阿里巴巴发布的 **Qwen3.5，这是一个拥有 3970 亿参数的多模态推理模型。其设计旨在 IFBench、GPOA Diamond 和 BFLC V4 等各项基准测试中，表现与 Gemini 3 Pro、Claude Opus 4.5 和 GPT-5.2 等模型持平。该模型支持 256K context 等高级功能，适用于编程、视觉和对话等应用。发布内容包括支持在 192GB RAM Mac 上运行 3-bit 版本，或在拥有 256GB RAM 的 M3 Ultra 上运行 4-bit (MXFP4) 版本。图片及随附链接提供了访问和运行该模型的资源，包括来自 Unsloth 的动态 GGUFs。** 评论表达了对该模型规模和能力的兴奋，一位用户注意到了令人印象深刻的 397B 参数，另一位用户则对同步首发表示赞赏。

  • 讨论强调了 Qwen3.5-397B-A17B 模型的冗余性（verbosity），它似乎会对像 ‘hi’ 这样简单的输入进行过度分析，在生成回复之前产生大量的内部思考过程。这种冗余性可能表明了模型的复杂性及其模拟人类思考过程的尝试，但也可能暗示了在处理简单任务时的效率低下。
  • 提出了一个关于两种量化格式 UD-Q4_K_XL 和 MXFP4 性能对比的技术咨询。评论者指出目前缺乏直接对比这些格式的基准测试，而这对于理解它们在模型部署场景中的相对效率和有效性至关重要。这突显了可用性能数据的空白，而这些数据本可以为模型优化和部署决策提供参考。

  • Ok_Brain_2376 的评论指出，在 Qwen3.5-397B-A17B 模型中只有 170 亿参数（17B）是处于激活状态的，这表明可能使用了类似 AutoRound 的参数高效技术。这可能意味着该模型旨在仅为某些任务激活其参数子集，从而在保持性能的同时优化计算资源。

  • Qwen3.5 发布了！ (热度: 113): **阿里巴巴发布了 Qwen3.5，这是一个 397B 的 MoE (Mixture of Experts) 视觉推理 LLM，如图片所示。该模型在指令遵循、多语言知识和视频推理等基准测试中与 Gemini 3 Pro 和 GPT-5.2 等模型进行了对比。图片强调了 Qwen3.5 在编程、视觉和 Agent 交互方面的能力，并提供了运行该模型的技术细节，尽管图片中未详细说明 VRAM 等具体硬件要求。** 评论者对运行 Qwen3.5 所需的硬件要求（特别是 VRAM）感到好奇，并正在讨论与苹果 512GB M3 Ultra 配置相当的设备方案。

  • 一位用户询问了运行 Qwen3.5 所需的 VRAM 要求，这对于确定在不同硬件设置上运行该模型的可行性至关重要。对于资源有限的用户来说，这是一个普遍关注的问题，因为大型模型通常需要大量的 VRAM 才能高效运行。
  • 另一位用户询问了与 512GB M3 Ultra 配置相当的非 Mac 设置。这表明需要了解 M3 Ultra 的硬件规格和性能基准，以便在 PC 生态系统中找到可比的替代方案，特别是对于那些对高性能计算任务感兴趣的用户。
  • 一位用户表达了在配备 2 块 RTX 3090 Ti GPU 的设置上运行 Qwen3.5 的兴趣，这表明了该模型对计算的高需求。RTX 3090 Ti 以其巨大的 VRAM 和处理能力而闻名，但该用户预计仍需等待更优化的版本才能在其硬件上运行，突显了该模型对资源的密集需求。

2. AI 模型基准测试与性能

  • 我给了 12 个 LLM 2000 美元和一辆餐车。只有 4 个存活了下来。 (Activity: 829): 该图片是一张折线图，展示了 12 个语言模型 (LLMs) 在模拟业务环境中的表现，每个模型都被分配了 $2,000 和一辆餐车，负责运营 30 天。图表显示，只有四个模型在模拟中存活下来，其中 **Claude Opus 4.6 达到了最高的净值 $49K，紧随其后的是 GPT-5.2，净值为 $28K。模拟显示，贷款的模型更容易破产，因为所有八个贷款的模型都失败了。该实验突出了不同 LLMs 在受控业务场景中的决策能力，一个显著的发现是 Gemini 3 Flash Thinking 始终陷入无限决策循环。** 一位评论者建议在 y 轴上使用对数刻度 (logarithmic scale) 以更好地展示数据，特别是因为余额降至 $0 就意味着 Benchmark 结束。另一位评论者指出 Opus 表现异常出色，暗示它可能针对此类任务进行了优化。

    • HeadlessNicholas 建议在 Benchmark 结果的 y 轴上使用对数刻度，以便更好地实现数据可视化，尤其是因为达到 $0 会终止 Benchmark。这意味着目前的线性刻度可能无法有效表示模型之间的性能差异，特别是当某些模型过早失败时。
    • DinoAmino 提到了 ‘Vending-Bench’，并指出 Opus 在这两种情况下都表现得异常出色，这表明它在决策任务中具有一致的优越性。提到的 arXiv paper 意味着有关于 Opus 能力的文献证明，这对于进一步的技术分析很有用。

    • DarthLoki79 通过将该 Benchmark 与 ‘vending bench’ 进行比较，质疑其新颖性，暗示方法论或结果可能没有显著差异。这提出了一个观点，即需要明确该 Benchmark 如何在参数或评估标准方面区别于以往的 Benchmark。

    • Qwen 3.5 在 Vending-Bench 2 上破产 (Activity: 836): 该图片展示了来自名为 “Vending-Bench 2” 模拟的图表，该模拟评估了各种 AI 模型在 350 天内的财务表现。图表显示 “Qwen 3.5 Plus” 模型表现不佳，其资金余额保持在零附近，表明其已经破产。相比之下，”Claude Opus 4.6” 展示了强劲的上升趋势，在测试模型中获得了最高的财务余额。其他模型如 “GLM-5” 和 “Gemini 3 Flash” 也表现出正增长，但不如 Claude Opus 4.6 那样显著。这表明 Claude Opus 4.6 在此模拟环境中可能具有更出色的能力或策略。 一条评论批评了图表中使用相近颜色的做法，这可能使得区分模型变得困难。另一条评论幽默地建议 Qwen 3.5 由于财务表现不佳，可以作为非营利组织运营。

      • Chromix_ 对 Vending-Bench 2 的结果进行了详细分析，指出图表显示了五次运行中的平均美元余额。他们提到 Qwen3.5 Plus 未包含在图表中，因为它尚未添加到官方结果页面。提供了 Benchmark 链接以获取更多细节：Vending-Bench 2。
      • SkylarNox 提出了关于 Qwen 3.5 版本的问题，特别是询问 Qwen 3.5 Plus 和 397B 版本之间的尺寸差异。这表明需要更多关于不同模型版本的规格和能力的透明度或文档。

  • QWEN 3 Max-Thinking 与 QWEN 3.5 在空间推理基准测试 (MineBench) 上的差异 (活跃度: 399): 该帖子讨论了 **QWEN 3.5 在空间推理基准测试 MineBench 上相比 QWEN 3 Max-Thinking 的显著提升。QWEN 3.5 的表现被指出可以与 Opus 4.6、GPT-5.2 和 Gemini 3 Pro 等领先模型相媲美。可在 GitHub 上查阅的基准测试结果显示，QWEN 3.5 排名第 6，而 QWEN 3 Max 排名第 19，表明两者存在巨大的性能差距。该模型的架构被描述为一种 hybrid linear-linear-linear-full attention 模型，并指出其在 token prediction 和 language drift 方面存在一些问题。** 评论者强调了 QWEN 3.5 的鲁棒性，尽管在 token prediction 和 language drift 方面存在一些问题。关于 QWEN 的 Plus 版本和开源版本之间的区别存在困惑，推测 Plus 版本包含扩展的 context 和 tool calling 功能。

    • NandaVegg 强调 Qwen 3.5（包括其 Vision-Language (VL) 能力）以其 hybrid linear-linear-linear-full attention 模型架构而闻名。尽管存在偶尔忽略指令和 language drift 等问题，但它在鲁棒性方面可与领先模型竞争。然而，由于缺乏在 agentic-maximized 模型中常见的 post-training mini-CoT 调整，它对于 agentic 任务可能不是理想选择。
    • Chromix_ 提供了来自 MineBench 排行榜的性能对比，指出 Qwen 3.5 排名第 6，位于 Gemini 3 Pro 和 GLM 5 之间，而 Qwen 3 Max 排名第 19，位于 Kimi K2 和 GPT-4o 之间。这表明 Qwen 3.5 和 Qwen 3 Max 之间存在显著的性能差距，尽管由于投票数有限，Qwen 3.5 的结果仍可能发生变化。
    • NandaVegg 还提到关于 Qwen 模型的 “Plus” 版本和开源版本的困惑，指出在 Alibaba Cloud 上的测试未能澄清其中的差异。“Plus” 版本被推测为是将 context 扩展到 100 万个 token 并默认开启 tool calling 的开源版本，包括在 Alibaba Cloud 上的搜索功能。

3. 本地 AI 开发与优化

  • [macOS] 开发了一款 100% 本地、开源的听写应用。寻求 Beta 测试者的反馈！ (热度: 101): SpeakType 是一款全新的 macOS 开源听写应用，完全离线运行，通过在本地处理所有数据来确保用户隐私。它旨在提供高质量的语音转文本转换，且无需支付与云端服务相关的持续费用。该应用目前处于 Beta 测试阶段，正在征求不同 Mac 硬件和口音下的性能反馈，并在此阶段免费提供。项目托管在 GitHub 上，更多详情请访问 tryspeaktype.com。评论者对该应用的 RAM 需求以及它与 Handy 等类似工具的对比感到好奇，询问 SpeakType 是否包含额外的逻辑或功能。此外，人们还对该应用是否使用语音活动检测器（VAD）在将音频传递给 Whisper 模型之前进行预处理感兴趣。

    • JohnHawley 询问了 SpeakType 与另一款听写应用 Handy 之间的区别，质疑 SpeakType 是否包含了 Handy 中没有的额外逻辑。这暗示了对两款应用的功能集以及性能或准确性差异的比较。
    • rusty_daggar 询问该应用在处理前是否使用语音活动检测器（VAD）来清理音频，还是直接将所有音频发送到 Whisper 模型。这个问题凸显了对应用音频预处理技术的关注，这些技术会显著影响性能和准确性。

  • Mac Studio vs NVIDIA 的两难选择——能兼顾两者之长吗？ (热度: 93): 用户正在权衡运行本地 LLM 和训练模型的两个选项：一台拥有高达 192GB 统一内存的 **Mac Studio，它允许在没有 VRAM 限制的情况下运行大型模型，但缺乏 CUDA 优化和原始算力；以及 NVIDIA GPU 配置，它提供卓越的性能和 CUDA 优化，但即便在 5090 等高端 GPU 上也受限于 32GB VRAM。用户寻求一种能结合 Mac 的内存容量与 NVIDIA 计算能力的解决方案，而目前单一系统中并不存在这种方案。** 一位评论者认为模型的使用比训练更关键，强调推理（inferencing）是主要用例，并建议 Mac 用户查看 vmlx.net。另一位建议在 RunPod 等平台上租用 B200 或 H100x8 等高性能 GPU 进行训练，同时利用 Mac 的内存来推理 Qwen 和 MiniMax 等模型。第三位评论者指出，对于编写代码而言，Claude Max 和 ChatGPT Pro 等商业 API 可以是替代本地硬件的高性价比选择。

  • 我是一名对 x86 一窍不通的 Android 开发者。在度假期间，我构建了一个可以遗传演化机器码的系统——现在我可以在单块 RTX 4090 上运行 80B 模型。 (热度: 70): 一位 Android 开发者利用 AI 创建了一个名为 Genesis 的系统，该系统可以演化 x86 机器码，从而能够在单块 RTX 4090 上运行 80B 模型。该系统使用进化方法来优化 AVX-512 内核，实现了比 bitsandbytes 等传统 CPU 方法快 165x 的速度，并通过最小化 CPU 和 GPU 之间的数据传输来实现高效的混合推理。该项目已开源，内核代码可在 GitHub 上获得，但进化引擎仍保持私有。这种方法证明了 AI 驱动的代码进化可以超越人工优化的代码，比手工调优的基准实现了高达 19.25% 的提升。 一些评论者表示怀疑，将此贴比作“妄想型疯狂科学家同人小说”，而另一些人则欣赏其技术深度，并注意到共享代码中包含详细的测试套件。

较低技术门槛的 AI 子版块回顾

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

1. Claude Sonnet 4.6 发布与基准测试

  • Sonnet 4.6 发布！！ (热度: 1384): 图片宣布了 **Claude Sonnet 4.6 的发布，强调其为迄今为止最先进的版本，在 coding、computer use、长上下文推理（long-context reasoning）、agent planning、知识工作和设计等领域有显著提升。值得注意的是，它在 beta 版中推出了 1 million token context window，这是处理海量数据输入的一项重大增强。此次发布使 Sonnet 4.6 成为 AI 领域极具竞争力的模型，在某些能力上可能超越了 Grok 等其他模型。** 一条评论幽默地暗示 Grok 已被 Sonnet 4.6 超越，表明其在 AI 模型领域具有竞争优势。另一条评论提供了 Sonnet 4.6 推理能力的实际案例，展示了它在日常决策（如短距离出行是步行还是开车）上提供逻辑建议的能力。

    • Sonnet 4.6 的发布引发了关于其实用建议能力的讨论，正如它对“步行还是开车 40 米”这一简单查询的回答所展示的那样。该模型建议步行，理由包括时间效率、节省燃料和健康益处，凸显了其提供与上下文相关且实用建议的能力。
    • 网友将 Sonnet 4.6 与 Grok 等其他模型进行了对比，一些用户幽默地表示 Sonnet 4.6 已经超越或“碾压（claudemogged）”了 Grok。这反映了 AI 社区关于不同语言模型相对性能和能力的持续争论。

    • Sonnet 4.6 的发布时机被认为具有战略性，可能旨在转移公众对其他 AI 模型（如与 Elon Musk 相关的模型）争议的注意力。这表明在竞争激烈的环境中，发布时机可以影响公众和专业人士的看法。

    • 这就是 Claude Sonnet 4.6：我们迄今为止最强大的 Sonnet 模型。 (热度: 1245): **Claude Sonnet 4.6 是 Sonnet 系列的一次重大升级，增强了在 coding、computer use、长上下文推理、agent planning、知识工作和设计方面的能力。它在 beta 版中引入了 1M token context window，这是处理大规模数据输入的一个显著特性。该模型在各种 benchmark 中表现出提升的性能，接近 Opus 级别的智能，但价格更具亲和力，使其适用于更广泛的应用场景。它在复杂的计算机任务中展现出人类水平的熟练度，例如操作电子表格和填写多步骤网页表单。该模型现已在所有方案（包括 Cowork、Claude Code 和主流云平台）中提供，免费层级也已升级到 Sonnet 4.6。更多详情请访问 Anthropic 官网。** 一位评论者指出，由于旧模型显示问题，模型的初步推出过程令人困惑。另一位对该模型对创意写作的影响表示好奇，还有一位询问了 1M context 功能是否在 API 和网站上均可使用。

      • FriendlyTask4587 询问了 Sonnet 4.6 模型的上下文长度，询问 1 million token context 是否像 Opus 模型一样在 API 和网站上都可用。这表明用户关注模型处理大型输入的能力，这对于需要广泛上下文保留的任务至关重要。
      • nanolucas 质疑 Sonnet 和 Opus 模型之间的区别，特别是成本是否是选择 Sonnet 而非 Opus 的唯一因素。这意味着需要了解两个模型之间的性能或功能差异，例如效率、速度或 Sonnet 可能比 Opus 具有的特定用例优势。
      • Stupefied_Gaming 在 Sonnet 4.6 推出期间注意到一个现象，即该模型最初被标记为旧模型（legacy model）。这可能表明部署处于过渡阶段或存在临时标签错误，这可能会影响用户在初始发布期间的看法或使用。

  • Claude Sonnet 4.6 刚刚发布，基准测试表现令人印象深刻 (活跃度: 785): Claude Sonnet 4.6 已经发布，展示了 AI 能力的显著进步，包括以更低的成本 接近 Opus 级别的智能。关键特性包括用于导航电子表格和多步表单等任务的 人类水平的 computer use，以及增强的长上下文推理能力，拥有 1M token context window。该模型在复杂的自动化工作流、多步推理任务和知识密集型应用中表现强劲，目前已在包括 API、Claude Code 和 Cowork 在内的所有平台上线，并作为默认免费层级模型。一个显著的辩论集中在性价比上，一些用户指出 Opus 4.6 和 GPT-5.2 之间的性能差异极小，但后者明显更便宜。还有关于 1M context length 功能实际可用性的讨论，一些用户表示难以访问该功能。

    • cowwoc 强调了 AI 模型市场的一个关键问题：Opus 4.6 和 GPT-5.2 之间的性能差距极小，但 GPT-5.2 明显更便宜，成本低了 10x。这种性价比失衡可能会让用户远离 Anthropic 的产品，除非他们调整定价或增强模型能力。
    • SatoshiNotMe 指出了测试版中承诺的 “1M context length” 功能反复出现的问题，对于像 Max20 这样的用户来说似乎难以触及。这表明在向终端用户交付该功能时可能存在沟通或实施差距，这可能会影响用户满意度和信任。

    • joyfulsparrow 对比了 Claude 和 Codex，指出 Codex 提供了似乎无限的 token 使用量，而 Claude 的 token 限制很快就会达到，即使是在 20 美元的计划中也是如此。这种限制，加上 Codex 在处理 “agentic loop” 任务方面的潜在优势，表明对于有重度使用需求的用户来说，Codex 可能是更高效的选择。

    • Claude Sonnet 4.6 已在 Cline v3.64.0 中上线，并免费提供至 2 月 18 日。 (活跃度: 21): Anthropic 已在 Cline v3.64.0 中发布 Sonnet 4.6，在 2 月 18 日前可免费使用。此更新具有更快的速度、任务执行期间增强的上下文提供以及有效的库集成。值得注意的是，该模型在利用 subagents 进行并行任务方面表现出色，提供 1M token context window 以在单个请求中处理整个代码库。在测试中，~70% 的开发者更倾向于 Sonnet 4.6 而非其前代产品，59% 的开发者更青睐它而非 Opus 4.5，理由是减少了过度设计和幻觉。免费期结束后，定价维持在 $3/$15 per MTok。来源。一位用户表达了对使用 Cline 的重新关注，表明对该更新的积极反响。

2. Grok 4.20 与 Elon Musk 争议

  • 新发布的 Grok 4.20 将 Elon Musk 作为其主要来源 (热度: 2383): 该图片是一个梗图，幽默地批评了 AI 模型 Grok 4.20，暗示其在回复中（尤其是涉及性别代词等话题时）将 **Elon Musk 作为主要来源。图中描绘的对话突显了归因于 Musk 的关于代词使用的争议性立场，强调对“生理现实”的关注。这反映了关于 AI 偏见以及知名人物对 AI 训练数据影响的更广泛讨论。** 一条评论强调了对该 AI 与 Musk 观点一致性的怀疑，指出经过多次交互才确认了这种偏见。另一条评论批评了 Musk 影响力的更广泛含义，涉及环境和伦理问题。

  • Grok 4.20 只是四个 Grok 4.1 Agent (热度: 699): 图片幽默地暗示 Grok 4.20 模型本质上是由四个 Grok 4.1 模型实例组成的，正如日志条目中的模型名称和 ID ‘grok-4-1-thinking-1129’ 所显示的那样。这暗示尽管版本号有所更新，但模型架构可能缺乏重大进展或变化。标题和评论通过将其比作“穿在风衣里的四个 Agent”这一常见桥段来戏谑这种伪装行为。 一条评论指出该公司（可能是 x.ai）可能正面临运营问题，包括 Grok 4.20 发布延迟和员工离职，这可能会影响模型的开发。

    • Brilliant-Weekend-68 强调了 x.ai 潜在的运营问题，指出 Grok 4.20 发布延迟以及严重的员工离职。这表明内部挑战可能影响该公司在 AI 领域的创新和有效竞争能力。
    • Glittering-Neck-2505 将 xAI 当前的困境与 Meta 在 Llama 3 405b 之后的下滑进行了类比，暗示 xAI 最初的承诺并未兑现。这种对比暗示 xAI 在保持势头和交付预期方面可能面临类似的挑战。
    • 讨论反映了对 xAI 战略方向的怀疑，Glittering-Neck-2505 表示庆幸 Grok 4.20 可能因为其被察觉到的失误而无法获得关注，这表明业界普遍认为 xAI 的品牌塑造和执行可能无法在技术社区产生良好共鸣。

3. Qwen 3.5 模型发布与对比

  • **[Qwen3.5-397B-A17B <发布>](https://www.reddit.com/r/Qwen_AI/comments/1r662ls/qwen35397ba17b_release/)** (热度: 302): ****Qwen3.5-397B-A17B** 是一款新模型，拥有 `397 billion` 总参数和 `17 billion` 激活参数，提供 `262k` token 的原生上下文长度，可扩展至 `1 million`。它支持超过 `200 languages`，并采用结合了 **Gated Delta Networks** 与 **Sparse Mixture of Experts (MoE)** 的混合架构以提升速度。该模型在真正的多模态方面表现出色，在 GUI 交互、视频理解和 Agentic 流程中表现优异。更多详情见 [Qwen's blog](https://qwen.ai/blog?id=qwen3.5)、[Hugging Face](https://huggingface.co/Qwen/Qwen3.5-397B-A17B) 和 [GitHub](https://github.com/QwenLM/Qwen3.5)。** 评论者对模型的 `397 billion` 参数量感到惊讶，质疑运行此类模型所需的 VRAM 要求。还有人对模型在 GUI 交互中使用的软件感到好奇，特别是在 Excel 中的表现，以及它是公开可用还是 Qwen 团队专有的。

    • Efficient_Cattle_958 强调了 Qwen3.5-397B 模型出人意料的规模，其拥有巨大的 397 billion parameters。这一规模意义重大，因为与通常范围在 billions to tens of billions 参数的较小模型相比，它意味着计算能力和潜在功能的实质性提升。
    • Sirius_Sec_ 询问运行如此大型模型所需的 VRAM 要求。通常，这种规模的模型需要大量的 VRAM，往往在 hundreds of gigabytes 范围内，这取决于为了使其在消费级硬件上更易运行而可能采用的模型并行或 Quantization 技术等优化手段。
    • nunodonato 询问运行模型所使用的软件环境，特别是在涉及 Excel 的演示中。这引发了关于该软件是 Qwen 团队专有还是可供公众使用的问题，这可能会影响开发者和研究人员利用该模型能力的可及性。

  • 阿里巴巴刚刚开源了一个足以媲美 GPT-5.2 的模型 (热度: 140): Alibaba 开源了一个全新的语言模型 Qwen 3.5，其定位是 OpenAI 的 GPT-5.2、Claude 4.5 Opus 以及 Gemini-3 Pro 的竞争对手。据报道，该模型的性能与这些领先模型相当，标志着开放权重 (open-weight) 发布的一个重要里程碑。此次发布凸显了 Alibaba 致力于推动 AI 技术发展并为开源社区做出贡献。更多技术细节请参阅 原文。评论者对公开网站上的使用限制感到好奇，并对更小的本地版本模型表现出兴趣，认为虽然大模型令人印象深刻，但更易于获取的版本将有利于更广泛的使用。

    • 一位用户对 MiniMax、GLM-5 和 Kimi-k2.5 等中国模型的性能表现表示怀疑，并将其与 OPUS 等模型进行了比较。他们指出，在 GLM 4.7、GLM 5 和 MiniMax m2.1 上使用了 500M tokens 后，与 Codex 或 Opus 相比，这些模型需要更多的引导 (steering) 和额外的上下文 (context)，并强调了明显的运行速度差异。
    • 另一位用户讨论了对可在本地运行的更小版本模型的需求，并承认先发布大模型的实用性。这反映了在平衡模型大小、性能与本地部署可行性方面的普遍兴趣，而本地部署通常是大规模模型面临的挑战。

    • 人们对未来的发布充满期待，如 Qwen code 3.5 400b，这表明社区对这些模型的演进和扩展很感兴趣。这显示出人们既关注当前模型的能力，也关注未来版本中潜在的改进。

    • Qwen-3.5 发布了 (热度: 31): Alibaba 发布了 Qwen-3.5 系列的首个开放权重模型，命名为 Qwen3.5-397B-A17B。该模型是 Qwen 系列持续开发的一部分，该系列以大规模语言模型著称。此次发布意义重大，因为它提供了模型权重的开放访问，允许在各个领域进行更广泛的实验和应用。该公告发布在 Alibaba 的官方 X 账号上。一条值得注意的评论质疑了运行如此大模型的实用性，暗示了所需的计算资源。另一条评论建议该模型可以通过 app 和网页端访问，这预示着最终用户可能会享受到使用的便利。

AI Discord 内容精选

由 gpt-5.2 生成的摘要之摘要

1. Claude Sonnet 4.6 + 前沿模型 (Frontier Model) 推出

  • Sonnet 4.6 开启巡演，夺得编程桂冠：Claude Sonnet 4.6 已广泛发布并出现在多个平台：它登陆了 LMSYS Arena Text/Vision/Code（以及 Code Arena），可供 Perplexity Pro 和 Max 订阅者 使用，并出现在 Anthropic 的发布日志 “Claude Sonnet 4.6” 中。
    • Cursor 用户呼应了 Anthropic 的更新说明——“用户甚至更倾向于 Sonnet 4.6 而非 Opus 4.5…”——Latent Space 传阅了同一份公告中的基准测试结果（例如：79.6% SWE-bench、59.1% Terminal-Bench 2.0 以及 1M-token 上下文测试版），同时 Arena 在 Peter Gostev 的 YouTube 视频 中发布了初步印象。
  • Qwen 3.5 和 GLM-5 盛大登场（附带证明）：qwen3.5-397b-a17b 模型加入了 Arena 在 Text/Vision/Code 上的新模型 Feed，Hugging Face 用户强调了一个本地 GGUF 选项：unsloth/Qwen3.5-397B-A17B-GGUF。
  • 模型访问权限的剧烈波动：限制、Tokens 与 Turbo 的撤回：Moonshot 用户反馈 Kimi K2 Turbo 从 Kimi-Coding 中消失，引发了订阅用户的集体抵制（“…他们把它删了？！？”）；与此同时，OpenClaw 用户触碰了 Kimi 2.5 的周使用上限（有人声称两天内用了 95%），并讨论通过 OpenRouter models 切换供应商。
    • Perplexity 用户同样抱怨产品层级的限制——据称 Deep Research 从 300 次/月 降至 20 次/月；LMArena 用户探索绕过 24 小时视频限制的方法，但遭到反对，认为该限制是刻意为之（即不要试图绕过它）。

2. OpenClaw Agent 系统：能力、成本与风险

  • OAuth、封号以及触碰了禁忌 API 的 Agent：OpenClaw 用户讨论了通过 OpenClaw 运行 Claude 是否违反 Anthropic ToS，并伴随封号报告，有人声称 “将 OAuth 用于未经授权的第三方软件被视为对其网络进行逆向工程，违反了服务条款。”
    • 同样的安全性焦虑在别处也有回响：Unsloth 和 Yannick Kilcher 社区指出了赋予 LLM 读写权限的风险（API key 泄露、prompt injection，甚至 “rm -rf /”），OpenClaw 的通用方案与一段 YouTube 演示视频一同被讨论。
  • 让 Harness 摆脱“臃肿的废料”（并降低成本）：OpenClaw 工程师质疑系统的架构复杂性和 Token 使用量，认为 “Harness 应该建立在轻量级的精密设计之上，而不是臃肿的废料”，并提出了在 Sub-Agent 中进行心跳检测等策略以减少无效对话。
    • 开发者展示了通过“Agentic 上下文工程”和记忆优化带来的具体节省：在 OpenRouter→opus-4.6 配置下减少了约 30% 的 Token，而在使用 OpenClaw Browser Relay 时减少了 50% 以上，将成本视为相较于本地硬件的首要瓶颈。
  • OpenClaw 生态系统交付：Recipes、CRM 技能与备用大脑：一位社区成员在投入 “超过 200 小时” 的工作后，开源了一个 OpenClaw “Agency Server” 工具包，发布了用于项目管理/任务分配的 JIGGAI/ClawRecipes，并每日追踪生态事件（包括 ProductHunt 上的发现）。

3. 基础设施与安全现状检查（401 错误、Panics 与 Key 泄露）

  • 401 启示录：Router 宕机，脚本报错：OpenRouter 遭遇重大事故，导致 API 接口出现大面积 401 错误，OpenRouter Status 对此进行了追踪，团队组建了“作战室 (war room)”，随后在 OpenRouter 公告贴中宣布修复。
    • Perplexity API 用户也分别报告了尽管有额度但脚本仍报 401 错误的情况，目前的最佳建议是基础的 Key 校验并升级工单至 api@perplexity.ai，这凸显了认证失败如何级联影响自动化栈。
  • Inference Endpoints “服务崩溃 (Service Panicked)”（于是用户重建了生产环境）：Hugging Face Inference Endpoint 用户遇到了 Error 500 和 “Service panicked”，即便 Hugging Face Status 显示为绿色。至少有一个团队通过重新创建 Endpoint 并迁移生产流量解决了问题。
    • 成员怀疑这种不稳定性可能与新的 CPU 自动扩缩容 (autoscaling) 有关，这正是那种让“重建 Endpoint”成为务实（虽然痛苦）的事故处理预案的“平台隐形变动”。
  • API Keys：Gitignored 了，但还是泄露了：一位 OpenRouter 用户报告称，尽管 API Key 存在于 Gitignored 文件中且 OpenRouter 登录需要邮件验证，但其 Key 仍通过 “Cloud Code” 泄露，并在约 20 分钟内消耗了 10 美元。
    • 与此同时，OpenClaw + Unsloth 的讨论强调了 Agent 系统是数据外泄风险的放大器（工具 + 读写权限 + prompt injection），这使得 Secret 扫描、最小权限原则和运行时 Key 隔离成为必选项。

4. 性能工程：内核、量化路径和快速工具链

  • 350→368 TFLOPS：矩阵乘法健身达人（Matmul Gym Bro）时代延续：GPU MODE 成员在 theCudaBender/matmul_V3 中对持久化算子（persistent-kernel）矩阵乘法工作（基准 350 TFLOPS）进行了迭代，并交流了具体的优化思路，如异步存储（async stores）和 smem→rmem 流水线，参考了 Cutlass 的示例，如 dense_gemm.py。
    • 他们还强调了测量严谨性：在单个算子上使用 Nsight Compute 获取定性指标，并使用 CUDA Events 进行实际计时，因为 Nsight 的回放机制在一次分析过多内容时会虚增耗时。
  • FlashInfer 基准实现带来 5.74 倍加速（以及 FP8 的怪异现象）：一位 GPU MODE 参与者报告称，使用 flashinfer-ai/mlsys26-agent-baseline（evolve agent，total_steps=100，pool_size=6，在 B200 上评估）配合 Claude Opus 4.6，在 MoE 赛道实现了 5.74 倍加速。
    • 后续问题集中在：对于 FP8 算子（即使被标记为正确），较高的 max_relative_error/max_absolute_error 是否属于预期现象，并询问了最终评估的细节，如 Triton 版本和工作负载权重——这是典型的“现在跑得快，但能过评审吗？”的焦虑。
  • FP4 并非只有一种：MXFP4 适配 Blackwell（Ampere 只能走慢速通道）：Unsloth 用户澄清说，MXFP4 是为 Blackwell（RTX 50 系列）设计的，由于需要模拟，在 Ampere（RTX 30 系列）上运行速度可能更慢，因为快速路径需要原生 FP4 Tensor Core（计算能力 ≥ 12.00）。
    • Modular 的 MAX 频道也回应了数据类型的现状：目前的重点是 NVFP4，而 MXFP4 支持相对“滞后”，但这些类型已存在于基础 Mojo 中，一旦 NVFP4 稳定，MXFP4 可能会跟进（MAX 自定义 Mojo 算子发布公告）。

5. 基准测试、评估与 Agent 协议底层架构

  • 基准测试接受审计：“Every Eval Ever”与 Cybench 的 Flag 处理失误：EvalEval 联盟发起了基准测试标准化项目 “Every Eval Ever”，Eleuther 成员将其与脑成像数据结构（BIDS）标准化推进进行了类比。
    • Nous Research 还强调了 Cybench 如何因使用非随机化的 CTF flags 而高估了性能，并在随机化后看到成功率下降（Cybench 网站），这提醒人们“基准测试的设计缺陷”可能比模型差异影响更大。
  • KV Cache 瘦身：160GB → 136MB：Eleuther 分享了 CoDA-GQA-L（有界内存注意力），声称可将 KV Cache 从 160GB 减少到 136MB，详见 Zenodo 论文 “CoDA-GQA-L”，代码位于 anthony-maio/CoDA-GQA-L。
    • 该机制（如频道内总结）每层使用 384 个插槽，分布在最近窗口（256 个精确 Token）、地标库（64 个经过新颖性过滤的 Token）和摘要库（64 个 EMA 原型）中，这对于 KV 占据主要成本的长上下文 Agent 架构直接相关。
  • MCP 趋于成熟：资源规范清理与付费工具：MCP 贡献者通过 SEP modelcontextprotocol PR #2007 讨论了货币化原语，允许服务器请求支付（从 X402 开始），以便 Agent 可以在安全限制（guardrails）下为工具付费。
    • 与此同时，社区通过规范整理 PR modelcontextprotocol PR #2093 推动资源语义的清晰化，特别是围绕 resource/read 到底是返回单个资源还是子资源集合的歧义。

Discord：高层级 Discord 摘要

OpenClaw Discord

  • 使用 OpenClaw 配合 Claude 会导致封号：成员们正在讨论在 Claude 上使用 OpenClaw 是否违反了 Terms of Service，一些人报告称因使用未经授权的第三方软件而被封号。
    • 一位用户指出：将 OAuth 用于未经授权的第三方软件被视为对其网络进行逆向工程，违反了 Terms of Service。
  • Kimi K2.5 是被低估的 Opus 挑战者：用户正在将 Kimi K2.5 与 Claude Opus 4.6 进行比较，有人声称 Kimi 的性能足以与 Opus 媲美，而另一些人则通过 OpenRouter 注意到 Minimax 的不稳定性，同时还讨论了高效路由和减少 Token 使用量的策略。
    • 一位用户用 Kimi 替换了 Claude Opus 4.6，并表示 K2.5 被严重低估了，理由是其极具优势的价格。
  • 放弃为 OpenClaw 使用 Mac Mini：社区成员建议不要仅为了 OpenClaw 使用 Mac mini，建议使用更便宜的替代方案，如 Raspberry Pi 或 VPS，强调不需要高端硬件。
    • 一位用户推荐将 Raspi 5 2gb 用于极简用途，并将预算优先投入到 API 成本上。
  • OpenClaw 的复杂架构遭到质疑：成员们对 OpenClaw 的架构复杂性和 Token 使用量提出质疑，认为需要轻量化的精细设计，以及减少 Token 消耗的策略，例如在 sub-agents 中运行 heartbeat 检查。
    • 有人表示：框架应该建立在轻量化的精细设计之上，而不是臃肿的废料。
  • Agency Server 登上 ProductHunt：一位用户使用 OpenClaw 开发了一个 agency server，利用他们的 GitHub repository 进行项目管理和任务分配。
    • 该服务器还每日跟踪 OpenClaw 生态系统中的所有事件，识别在 ProductHunt 上发布的项目，开发时间超过 200 小时。

BASI Jailbreaking Discord

  • Gemini 遭遇“复古”绕过：分享了一个针对 Gemini 的 jailbreak 方法，涉及将日期设置为 2026 年 2 月 16 日以绕过安全指南。
    • 在测试时，Gemini 澄清它没有用于绕过安全指南的“测试模式”。
  • 模型融合进入粉丝竞赛：一位成员旨在比较 GLM、Kimi、ChatGPT pro、Claude max、Perplexity pro、Supergrok 和 Minimax 等模型。
    • 他们还计划开设新账号，竞争高粉丝量以实现 AI 内容变现。
  • LLM 辅助的智能合约审计出现：一位成员正在开发一种 LLM 辅助的智能合约审计工具，该工具可实现 80% 自主化，旨在减少 hallucinations。
    • 他们提议增加一个 Web3 创始人档案，根据项目背后的人员来衡量投资风险。
  • Tor 浏览器托管无限限制 AI：成员们讨论了 Tor 上无审查、无限制的 AI，一位成员提供了链接并警告可能存在病毒链接。
    • 一位成员推测该 AI 是使用 Claude 构建的，而另一位成员则 root 了他的三星设备来使用它。
  • GitLab 项目在暗网拍卖：一名威胁行为者声称正在拍卖 三个活跃 GitLab 项目 的权限，这些项目与维护者角色相关，据报道使用的是 PHP/Laravel stack。
    • 根据一份 X 帖子，commit 历史记录分别列出了 19,386、1,975 和 13,830 次 commits，起拍价为 200 美元，一口价（blitz price）为 2,000 美元。

LMArena Discord

  • 用户寻求免费 AI 工具：用户讨论了如何免费获取付费 AI 工具，如 Veo 3.1 和 Gemini Pro，并指出 Google 经常提供免费访问权限。
    • 有些人将其比作不付钱就得到一部免费 iPhone，引发了关于此类方法在伦理和实用性方面的辩论。
  • LMArena 限制视频生成：用户探索了绕过 LMArena 24 小时视频生成限制的方法，包括使用 Gemini API key 或 ChatGPT Plus。
    • 然而，官方澄清该时间限制是刻意设置的且无法绕过，建议使用其他账号或不要尝试规避限制。
  • Nano Banana 禁止生成女性图像：据报道，由于 Gemini 的新审核政策，Nano Banana Pro 不再能生成女性图像。
    • 推测认为 Deepmind 可能是出于对图像呈现方式的担忧而实施了这些变化，这可能与地缘政治因素有关。
  • Qwen 3.5 与 Claude Sonnet 4.6 登陆 Arena！：新的 qwen3.5-397b-a17b 和 claude-sonnet-4-6 模型已添加到 LMSYS Arena 的 Text、Vision 和 Code Arena 中。
    • 这些公告是在 #new-model-updates 频道发布的，标志着该平台能力的重大提升。
  • Claude Sonnet 4.6 初体验播报！：Arena 的 AI 能力负责人 Peter Gostev 在一段新的 YouTube 视频中分享了他对 Claude Sonnet 4.6 的第一印象。
    • 成员现在可以通过“频道与角色”订阅 YouTube Updates。

Perplexity AI Discord

  • Sonnet 4.6 加入 Perplexity：Claude Sonnet 4.6 现已面向 Perplexity Pro 和 Max 订阅者开放。
    • 尽管增加了新模型，一些用户仍觉得免费层的限制相当糟糕。
  • Pro 用户抗议 Perplexity Pro 的额度缩减：Perplexity Pro 用户反映额度大幅下调，其中 Deep Research 查询从 300次/月 降至 20次/月，导致用户考虑更换其他工具。
    • 许多人由于对 Pro 服务变化的各种不满，正在关注 Gemini 和 Claude 等服务。
  • Grok 4.2 在计算任务中表现不佳：用户报告称 Grok 4.2 在 DPS 计算和编程挑战等任务中表现不佳，仅提供估算值而非精确计算。
    • 一位用户直言不讳地表示，与 GPT 5.2 等之前的模型相比，4.20 版本非常糟糕。
  • Perplexity 的字体风波：Perplexity 网页端 UI 部署的新字体遭到广泛反感，导致用户寻求通过 CSS 调整来恢复旧字体。
    • 用户对缺乏自定义选项表示沮丧，并指出该字体与 Claude 网页端使用的字体非常相似。
  • API Key 引发 401 错误：成员报告称他们的 API script 停止工作，即使账户有余额且 API key 理论上有效，也会抛出 401 错误。
    • 故障排除步骤包括检查 Key 的有效性，并联系 api@perplexity.ai 以获取进一步帮助。

OpenRouter Discord

  • OpenRouter 遭遇停机困扰：OpenRouter 经历了重大停机，导致 API 接口出现大面积 401 errors，引发了用户的调侃，团队已通过 OpenRouter Status 展开调查。
    • 该服务早些时候出现了问题，并成立了 war room 来调查 401 errors 的根本原因，随后实施了修复。
  • API Key 泄露导致资金损失：一名用户报告其 OpenRouter API key 被泄露，导致在 20 分钟内通过 Cloud Code 消耗了 $10。
    • 用户无法确定泄露源，因为该 Key 存储在被 gitignore 的文件中，且 OpenRouter 需要邮件验证。
  • Opus 4.6 遭遇流式请求问题：多名用户报告在使用 OpenRouter API 调用 Opus 4.6 时遇到了 “Streaming request failed with status 400 Bad Request” 错误。
    • 一些用户还提到了 Grok 4.1 Fast 模型返回空响应的问题。
  • Qwen Code 快速处理 Token：一名用户发现 Qwen Code 的表现 “比更大的 qwen3 cider 变体好得多”，并指出其速度更快，在触及 1M tokens 的 30% 上下文壁垒前处理 Token 毫不费力。
    • 他们感叹道：“先别急着放弃 qwen！”
  • DirectShell 使辅助功能层通用化：一名成员分享了 DEV.to 博客上关于 DirectShell 的文章，该工具将辅助功能层转变为通用的应用界面：DirectShell。
    • 该仓库已 Open Source，并宣称截至 2026 年 2 月 17 日，地球上所有基于截图的 AI agent、企业 API 封装工具和 RPA 工具都已成为过时技术。

Unsloth AI (Daniel Han) Discord

  • Gemma 获得巨大提升：根据 Unsloth 官方文档，Gemma 在最新更新后速度提升了 3 倍，甚至比 Qwen3-4B 还要快，这令用户感到震惊。
    • 用户经过计算发现，在 Gemma 上进行训练的成本比 4B 模型更低。
  • 旧硬件拖累 MXFP4 表现：MXFP4 是为 Blackwell GPUs（RTX 50 系列）设计的，由于需要模拟运行，在 Ampere（RTX 30 系列）等旧硬件上运行速度较慢。
    • 快速的 MXFP4 path 需要 Blackwell 原生 FP4 tensor cores（计算能力 ≥ 12.00），而旧架构会回退到使用实时量化的慢速路径。
  • 机器人对决机器人？：社区讨论了使用连接 LLM 的机器人通过私信进行“反向图灵测试”，以确保用户是真人。
    • 最终，团队认为使用机器人作为防止糟糕体验（UX）的手段，本身会造成更糟糕的体验。
  • OpenClaw 引发安全隐患：成员们分享了对 OpenClaw 的安全担忧，特别是赋予 LLM 对设备的读写权限（read+write access）所带来的风险。
    • 担忧包括潜在的 API key 泄露以及 prompt injection（提示词注入）导致有害行为的可能性。
  • Save_pretrained_gguf 在云端 Notebook 运行异常：一位成员报告 save_pretrained_gguf 命令在云端 Jupyter notebooks 上无法正常工作，其他成员推测这是否与处理 VL models 以及 merged models 有关。
    • 一名成员确认他们正在处理的是 merged model。

LM Studio Discord

  • 训练难题困扰开发者：成员们反映在 fine-tuning models（微调模型）时遇到困难，理由是大型数据集的 tokenizing 处理困难以及难以编写正确的训练代码。
    • 这些问题突显了针对特定任务定制模型的复杂性。
  • LM Studio 与 Claude 组合高效重构代码：一位用户报告称，成功将 LM Studio 与 Claude 及 Opencode 集成，在一台配备 64GB RAM 的 Mac Studio 上以 35 tokens/second 的速度和 200k context window 重构了一个 Go 项目。
    • 这种集成展示了本地开发环境处理大规模编码任务的潜力。
  • LFM 经过微调后超越 Qwen：经过微调后，一位成员发现 LFM 1.2B 在处理 Minecraft 指令数据集时的表现显著优于 Qwen 0.6B。
    • 这表明，在特定应用中，经过良好训练的小型模型可以超越更大型的模型。
  • GPT-OSS 编程表现获得好评：GPT-OSS 20B 在编程方面比 Qwen3 更受青睐，一位用户报告其速度达到 108 t/s，比 Phi-4 更快，尽管他们在 Qwen3-Next 上遇到了内存限制。
    • 这一偏好表明 GPT-OSS 在编程任务中可能提供了更好的速度与性能平衡。
  • Frankenbuild 崩溃，寻求修复方案：一位用户的全新“frankenbuild”（配置包括 256GB RAM、Core Ultra 7、AMD R9000、5060ti 以及两块 4060ti）在闲置时发生随机关机，引发了对稳定性的担忧并寻求排查策略。
    • 建议的修复方案包括检查转储文件（dump files）、运行 memtest86+、使用功率计检查功耗，以及调查 AMD 显卡上 12V HPWR 接口潜在的发热问题。

Cursor Community Discord

  • Cursor 截图系统失效：一位用户反映，浏览器自动化和截图捕获功能在 Opus 4.5 和 4.6 中已停止工作，导致 Token 浪费。
    • 有建议提出检查 MCP 日志，并提供了一张预期的 MCP 配置界面截图以解决该问题。
  • Roblox Studio 插件恶意窃取游戏：一位用户举报称，在联系某位主理人关于其 恶意 Roblox Studio 插件 (SuperbulletAI) 的问题后被该平台封禁，并指控该主理人窃取了其游戏。
    • 针对该插件拥有访问完整游戏文件和脚本权限的问题，人们提出了担忧，并建议重新编写代码以进行验证。
  • Sonnet 4.6 超越 Opus 4.5：Claude Sonnet 4.6 已发布，据 Anthropic 的公告报道，用户在 59% 的情况下更倾向于选择它而非 Opus 4.5，理由是其在指令遵循方面的改进以及减少了过度工程（overengineering）。
    • 根据 Asna_0101 的说法：用户甚至更喜欢 Sonnet 4.6 而非 Opus 4.5……他们认为 Sonnet 4.6 显著降低了过度工程和“偷懒”的倾向，并且在指令遵循方面表现明显更好。
  • AI Agent 在竞技场中争夺排名：一位用户重点介绍了 Unemployment Arena 平台，AI Agent 在该平台上进行客户支持模拟竞赛，并声称使用 Cursor 构建的 Agent 取得了顶级排名。
    • 另一位用户指出，这些 frontier models 可能自己编写了 Agent 技能，暗示该用户是用模型击败了模型本身。
  • Windows 环境下的 Linux 逻辑困扰：一位用户反映，当前的系统指令默认使用 Linux 命令。
    • 建议的解决方案包括使用 WSL2 或与 Ubuntu 组成双系统，另有人提到使用 rules 通常可以解决命令问题。

Latent Space Discord

  • Apple 囤积现金，AI UX 虚位以待：成员们讨论了 Apple 庞大的现金储备，暗示其策略是在现有模型之上构建卓越的 UX，而不是在 AI 训练上进行大量的前期投资。
    • 该策略是等待 AI 训练/推理领域趋于商品化后再采取行动，这是一种 UX 策略。
  • 新语音由 Ming 模型唱响：Ant Ling 推出了 Ming-omni-tts-16.8B-A3B 和 0.5B 模型，作为 Ming-flash-omni-2.0 的语音核心，用于高质量配音、播客工具和 OpenClaw 集成 (Ant Ling 推文)。
    • 这些文本转语音模型声称以高质量语音生成为主要焦点。
  • Mistral 收购 Koyeb 以获取额外算力：Mistral AI 计划收购 Koyeb，整合 Koyeb 的平台和专业知识，以加速 Mistral Compute 基础设施的开发 (Yann Leger 推文)。
    • 此次收购旨在通过加入 Koyeb 在该领域的专业知识来改进其基础设施。
  • Waymo 的乘车成本到 2028 年将减半？：根据 François Chollet 的说法，Waymo 的第六代平台车辆成本到 2028 年 可能会下降 50%，目前的成本为 $70,000。
    • Waymo 正在迅速扩张，目前每周无人驾驶乘车次数超过 500,000 次，年增长率为 3 倍，使其成为商业无人驾驶车辆的领导者。
  • PolyAI 融资 2 亿美元，推出 Agent Studio Lite：PolyAI 在 Nvidia 和 Khosla Ventures 的支持下获得了 2 亿美元 的融资 (PolyAI 推文)，强调了其在主要品牌中的语音 AI 成功。
    • 现在提供对 Agent Studio Lite 的早期访问，这是一款仅需五分钟即可从 URL 构建功能性语音 Agent 的工具，包括为候补名单用户提供 3 个月的免费试用。

GPU MODE Discord

  • Nsight 用户简化 Kernel 性能分析：成员们确认，通过跳过热身启动并对单个 Kernel 进行性能分析来使用 Nsight Compute，对于获取定性指标非常有效，而 CUDA Events 则提供准确的计时。
    • 共识是 Nsight Compute 在一次只对一个 Kernel 进行性能分析时效果最好，以避免不必要的开销，因为 Nsight 应该孤立运行。
  • 探索 Ampere 的 smem->rmem 流水线：一位成员使用其 theCudaBender GitHub repo 中通过 morton 序专门化的 persistent kernel warp 实现了 350 TFLOPS，并寻求性能提升的建议。
    • 建议包括探索 async stores 和 smem->rmem pipelining，并参考了 Cutlass 示例，在调优配置下实现了 368 TFLOPS。
  • Heroku 的健康状况影响排行榜：成员们报告了访问竞赛排行榜的问题，怀疑是 Heroku 健康问题 (Downdetector) 导致的，组织者承认了这一点。
    • 组织者表示 我们对此没有很好的缓解措施，并在 Heroku 开了工单，并承诺监控情况。
  • FlashInfer 实现速度提升：一位成员报告称，在 MOE 赛道上使用 mlsys26-agent-baseline 和 evolve agent，配合 Anthropic Claude Opus 4.6，total_steps=100, pool_size=6, 在 B200 上评估，实现了 5.74 倍的加速。
    • 另一位使用相同基线的成员也有类似的经历，远远落后于 flash infer 基线。
  • TVM FFI 快速将 Kernel 传输到 Runtime：GPU Mode 提到了 TVM FFI 绑定，用于将 Kernel 传输到不同的 Runtime，指出它比 torch 编译更快，但仍允许 torch 绑定。
    • 一位用户表示，大多数后端使用 sm100 而不是 sm100a，因此在使用 tvm ffi 后端时，任何原始 ptx 内容都会崩溃。

HuggingFace Discord

  • 服务崩溃（Panics）困扰 Inference Endpoints：尽管 Hugging Face 状态页面 显示运行正常，但用户在使用 Inference Endpoints 时遇到了 Error 500 和 Service panicked 消息。
    • 一位用户通过重新创建 Endpoint 并将生产流量迁移到新 Endpoint 解决了该问题，一些人认为这可能与最近引入的 CPU autoscaling 有关。
  • DirectShell 被宣布为通用应用接口：DirectShell 作为一种新颖的通用应用交互方法被推出，可能使现有的 AI agents 和 RPA 工具过时，源代码可在 GitHub 获取。
    • 该技术于 2026 年 2 月 17 日推出，将辅助功能层（accessibility layer）转变为通用应用接口。
  • Smart-KNN 宣布开源：Smart-KNN 项目已开源，专注于特征权重距离计算（feature-weighted distance computation）和自适应后端选择，以增强延迟的可预测性，代码库可在 GitHub 获取。
    • 该项目的目标是使 KNN 更加适应生产环境。
  • Microclaw 减轻 OpenClaw 负载：Microclaw (v2026.2.17) 是一个蒸馏语言模型，作为 OpenClaw 的备选 Agent，具有增强的训练和推理能力，可在 Hugging Face 获取。
    • 此版本引入了先进的训练和推理增强功能。
  • Pocket-TTS 克隆“上帝之声”：一名成员为多工作器（multi-worker）推理创建了一个自定义的 Pocket-TTS fork，并生成了一段 Morgan Freeman 朗读整本 钦定版圣经（King James Version） 的录音。

Nous Research AI Discord

  • Gemini 擅长着色器（Shaders），Claude 表现不佳：一位成员指出，Gemini 在创建着色器方面非常有用，而 Claude 的编码回复逻辑混乱，但据报道回退到 v2.1.41 版本后修复了该问题。
    • 这些观察结果强调了不同模型在特定编码应用中可靠性的差异，这对于开发者选择合适的工具至关重要。
  • 斯坦福 Cybench 因 Flag 随机化而失效：一篇关于 Cybench 的斯坦福论文 显示，该基准测试最初使用从知名 CTF 中提取的非随机化 Flag，导致了人为的高成功率。
    • 在将 Flag 随机化后，成功率显著下降，证明了 flag randomization 在准确评估网络安全基准测试中的重要性。
  • OpenClaw 虽实用性有限但因简洁性受赞赏：尽管有人声称 OpenClaw 是一个对于严肃 AI 应用来说庞大且无用的层，但它因其简洁性和用户友好的“助手”功能而赢得赞誉。
    • 讨论强调了简洁性与实用性之间的权衡，这对于那些在 AI tools 中看重易用性而非专业级功能的用户来说非常重要。
  • GLM 5 技术报告及能力讨论：GLM 5 的技术报告（2602.15763）已发布，社区成员正在审查其能力，包括来自 展示 GLM 5 的 YouTube 视频 的见解。
    • 该报告和讨论将提供有关模型架构、训练方法和性能指标的见解，帮助从业者了解其潜在应用。
  • 高 RAM、3090 GPU 对 AI 任务至关重要：一名用户指出，为了处理其 AI 工作负载中的“体面 context”，需要 至少 512GB RAM 和 一个或多个 3090 GPU。
    • 该评论强调了高级 AI 开发所需的实质性硬件资源，尤其是在处理 large-context models 和高强度计算任务时。

Eleuther Discord

  • Anthropic 为 Claude 的军事用途设定条件！：Anthropic 已同意允许军方使用 Claude，但须满足以下条件：1) 不得用于大规模监控；2) 不得用于自主武器。
    • 这一立场让部分成员感到意外。
  • Lucidrains 的 GitHub 遭封禁！：成员们报告称 Lucidrains 的 GitHub 账号 因某些原因（fsr）被暂停，引发了担忧；一位成员开玩笑说他“让其他太多人相形见绌了”。
    • 具体封禁原因目前尚不明确。
  • Geometric Table Transformer 将语义与几何结构解耦！：一位成员正在实验 Geometric Table Transformer (TV-Cache)，它在 Attention 机制中将语义兼容性与几何旋转解耦，用 这篇文章 中描述的 O(1) 标量查询 + 三角调制（trig modulation）取代了 RoPE 的高维点积。
    • 其核心优势在于 Attention 速度现在独立于 D，从而允许在不增加 Attention Head 中 O(D) 计算开销的情况下扩展内部维度。
  • EvalEval Coalition 启动 Every Eval Ever 项目！：EvalEval Coalition 启动了 Every Eval Ever 项目，旨在标准化 Benchmark 评估。
  • 预防性导向（Preventative Steering）通过改变目标实现泛化！：预防性导向的概念最初在 Anthropic 的 Persona Vectors 论文中描述，现在可以通过添加转向向量（Steering Vector）并根据模型命中原始目标的能力进行评判来实现泛化，从而迫使模型补偿转向向量。
    • 通过改变目标，可以鼓励模型不仅仅是与转向向量对抗，特别是当特征（Features）可以作为目标使用时。

Moonshot AI (Kimi K-2) Discord

  • Kimi K2 Turbo 下架，用户要求解释：用户报告称 Kimi-Coding 模型中的 Kimi K2 Turbo 已被移除，导致订阅用户不满。
    • 一位用户哀叹道，他是因为该模型可用才订阅了一年，并表示：“我真的觉得非常非常难过，他们宣传了一些东西……然后像我这样的用户据此订阅了一年……结果他们把它删了？！？”
  • Kimi 驱动交互式测验生成器：一位用户使用 Kimi 构建了一个交互式测验生成器，支持粘贴内容并通过 HTML 页面回答问题，可在 quiz.html 获取。
    • 功能包括“多选题”和会话管理，更多信息见附图。
  • Kimi CLI 遇到 Bash/Shell 问题：一位用户发现 K2.5 在 Kimi CLI 中使用 Bash/Shell 时存在问题，这是该特定模型特有的问题。
    • 该用户确认其他模型没有出现相同的问题。
  • Kimi-Code API 更新后 Openclaw 不兼容？：有用户报告称 Kimi code 已停止支持 Openclaw。
    • 建议探索 Openrouter 上的替代方案，以选择合适的模型和提供商。

Modular (Mojo 🔥) Discord

  • Modular 收购 BentoML 并举办 AMA: Modular 收购了 BentoML，并将与 Chris 和 Chaoyu 共同举办一场 Ask Me Anything (AMA) 活动。问题正在 Modular 论坛 征集中，并将在 YouTube 上进行直播。
    • 在论坛帖子中分享问题的前十名用户将获得贴纸。活动时间为 太平洋时间 (PT) 上午 9:30。
  • Mojo 获得 Jupyter Kernel: 一名成员发布了可供 Notebook 爱好者使用的 Jupyter Mojo kernel，代码已托管在 GitHub。
    • 该 kernel 目前还“非常简陋 (barebones)”，不支持补全或图像显示，但其运行速度 极快，且在 MacOS 及较新的 Linux 版本上表现良好；如果您尚未安装匹配的 modular 包，它会自动进行安装。
  • stack_allocation 牺牲了来源安全 (Origin Safety): 与 InlineArray 相比，stack_allocation 失去了来源安全和排他性检查 (exclusivity checking)，且无法利用 noalias 优化。
    • 由于编译器的局限性，它被视为一种“临时方案 (crutch)”，预计很快会有更好的选择；如果未发生溢出 (spill)，仅由常量值索引的 InlineArray 或 stack_allocation 将存储在 GPU 的寄存器中。
  • Mojo 的 RNG 实现尚未就绪: 一名成员正在寻求 Mojo 中常见概率分布的 随机数生成器 (Random Number Generators) 实现，特别是 泊松分布 (Poisson)。
    • 另一名成员建议，由于该项工作仍处于待办状态，这对 Mojo 来说可能是一个有趣的切入点。
  • Async Await 关注 GPU 集成: 一篇关于在 GPU 上实现 Async/Await 的博文可能会引起 Mojo 社区的兴趣，因为该功能目前尚在变动中。
    • 这也为实现 冷启动 future (cold-start futures) 提供了一个理由，因为这种方法可能不适用于热启动 future (hot-start futures)。

MCP Contributors (Official) Discord

  • 寻求 MCP Server 的变现激励: 一名成员创建了一个 SEP，允许 MCP server 为托管的工具请求费用（从 X402 开始），旨在通过货币化加速 Agent 的采用。
    • 然而，关于直接在协议中构建支付支持还是通过 URL 引导处理仍存在顾虑，除非核心维护者强烈主张，否则支付功能不太可能被优先处理。
  • 旨在实现 Agent 自主的微支付 (Micropayments): 该提案专注于让 Agent 能够自主支付工具费用，这需要详细的成本信息，以便在护栏 (guardrails) 下进行智能决策。
    • 一名成员预计短期内不会出现用于微交易 (MTXns) 的新支付协议，正如在 general 频道中所讨论的那样。
  • MCP 资源规范得到清理: 一名成员分享了一个 Pull Request，旨在清理 MCP 中资源的规范和可用性，以消除一些围绕资源的歧义。
    • 社区正在为 URI 路径和 resource/read 中返回的子资源等现有惯例引入更多的正式性和实用性，但尚未解决上下文长度问题或基于 UX 的原始类型 (primitive) 分组。
  • 资源分组提案被拒绝: 一名成员指出，关于资源分组的 SEP-2084 已被拒绝，因为 CM (核心维护者) 目前还不准备采用任何分组提案。
    • 反馈表明，任何分组提案都需要适用于所有原始类型 (primitives)，而不仅仅是工具，正如早期的 SEP-1300 那样。
  • resource/read 功能面临歧义: 社区担心，当对一个 URI 进行 resource/read 操作时，不确定收到的是单个资源还是子资源的集合，这造成了困惑。
    • 这种歧义需要进一步澄清和完善，以确保在访问资源时具有可预测的行为。

tinygrad (George Hotz) Discord

  • TinyBox 设置遇阻，引发社区援助：一名用户报告其 TinyBox 仅能识别 4 个 GPU 中的 2 个，并在 general 频道寻求帮助。
    • George Hotz 建议检查 连接线，用户随后确认重新插拔显卡解决了该问题。
  • 庞大的 TinyGrad PR 引发代码质量争议：一名用户向 tinygrad 提交了一个超过 150 行的大型 PR，引发了对代码质量的担忧。
    • George Hotz 表达了对 PR 中“AI 废话（AI slop）”的担忧，敦促贡献者仔细审查每一行代码并确认其必要性。
  • TinyGrad 第 7 次会议旨在深入探讨关键领域：George Hotz 公布了 TinyGrad 第 7 次会议的议程，涵盖公司动态更新、llama training loop & flash attention、驱动程序、viz/fast gemm、CALL/PARAMS 以及汇编。
    • 议程还包括编译器渲染器（compiler renderer）和图像、lazy assign setitem 和调度器（scheduler）以及其他问题和悬赏（bounties）。
  • TinyGrad 考虑集成 Axelera AI 加速器：社区讨论了在 TinyGrad 中支持小型加速器，例如 Axelera AI Metis-M.2 卡。
    • 有建议提出在类似 Acorn CLE-215 的小型 PCIe FPGA 开发板上集成自定义 RTL。
  • BarraCUDA 模拟器因 Bug 担忧面临审查：在发现模拟器 BarraCUDA 后，George Hotz 建议向 TinyGrad 贡献代码，而不是使用 C 语言编程。
    • 他质疑其缺乏 CI 且可能存在 Bug，并评论道：“我对缺乏 Bug 这一点深表怀疑。他们至少应该使用我们的模拟器。”

Yannick Kilcher Discord

  • Anthropic 发布更快速的 Claude Sonnet 4.6：根据 Anthropic 的 新闻公告，他们发布了 Claude Sonnet 4.6，其上下文窗口翻倍，且比之前的 Claude 模型更快、更便宜。
  • LLMs：引用错误的罪魁祸首还是替罪羊？：成员们辩论了近期论文中的引用错误是与 LLMs 相关的新问题，还是一直存在，并建议回顾过去的会议以评估引用的准确性。
    • 一位成员指出，如果一篇提交给 NeurIPS 2025 的论文使用 LLM 引用了 2024 年的出版物，将被视为幻觉（hallucination）。
  • OpenClaw 系统引发安全警报：OpenClaw 多智能体（multiagent）系统因其通用的可能性而令人兴奋，它通过网关接受任何输入类型并集成了时间，正如 此 YouTube 链接 中强调的那样。
    • 然而，人们开始担心诸如恶意软件链和提示注入（prompt injections）之类的 网络安全噩梦，一位成员指出：“很多人本可以做出这个系统，但可能因为太危险而退缩了。”
  • Harness Engineering 帖子：言之有物还是辞藻堆砌？：人们对 OpenAI 的 Harness Engineering 博客文章 反应冷淡，对其重营销的方式表示失望。
    • 一位成员评论说，如果他们没有决定把整个内容变成一个长篇营销文案，这篇文章本来会很有趣，并对推断该方法的有效性表示怀疑。

Manus.im Discord Discord

  • 账号仍被停用？：一名用户正寻求有关 Manus 账号停用的帮助，并发现很难在 general channel 获得支持。
    • 另一名用户建议尝试 support channel 以获得更好的协助。
  • 来自巴格达的少年现已通过验证：一名来自伊拉克巴格达的 13 岁开发者宣布他们现已通过验证，并鼓励其他人使用 Manus 构建一些疯狂的东西。
    • 他们在验证后询问 “这里还有谁在编码？”，表达了兴奋和鼓励。
  • 开发者自我介绍：几位开发者介绍了自己和他们的技能，其中一位强调了在 Blockchain 和 AI Agents 方面的经验。
    • 另一位开发者介绍自己是一名 full-stack 开发者，在 web applications、API 集成和 data pipelines 方面有经验，表达了对构建现实世界产品和在优秀项目上进行协作的热情。
  • 演示文稿错误令用户沮丧：一名用户在 Manus 账号上遇到了问题，由于一份制作了数周的演示文稿充满错误而感到沮丧。
    • 该用户在历史记录中看到了演示文稿但无法恢复，并表示由于已处于“最后冲刺阶段”而感到压力巨大。

DSPy Discord

  • DSPy REPL 发布：archelunch 在 GitHub 上发布了 DSPy REPL 的初始代码。
    • 该项目旨在为 DSPy 开发创建一个 read-eval-print loop（REPL）环境。
  • Discord 苦于缺乏 Semantic Search：一名成员强调了 Discord 中缺乏 Semantic Search。
    • 该评论强调了对平台内改进搜索功能的需求。
  • 寻找 GEPA 离线数据文档：一位用户请求有关将 GEPA 与离线数据配合使用的文档，寻求在断网环境下实现该技术的指导。

aider (Paul Gauthier) Discord

  • 社区成员寻求项目合作：一位成员发起讨论，寻找项目创意并询问社区内的活跃项目，通过提供 technical support 和 developer assistance 展示了协作精神。
    • 此举旨在促进合作，并协助社区内正在进行或新项目的开发。
  • 限制 /commit 仅针对 staged 更改：一名用户询问是否有办法让 /commit 命令仅考虑 staged 更改，因为当前的行为需要将不需要的更改执行 stash，并指向了 GitHub 上的 PR #2763，该 PR 将解决此问题。
    • 他们提到该 PR 已经开放超过一年了。

Windsurf Discord

  • GLM-5 登场：根据 这条推文，GLM-5 现已在 Windsurf 上可用。
    • 推文宣布了 GLM-5 在该平台上的可用性。
  • Minimax M2.5 引起关注：根据 这条推文，Minimax M2.5 也已在 Windsurf 上可用。
    • 推文强调了 GLM-5 和 Minimax M2.5 同时加入 Windsurf 的产品序列。
  • Sonnet 4.6 推出促销价：如 此贴 所宣布，Sonnet 4.6 已在 Windsurf 上线，促销价格从 2x credits 起。
    • 该贴详细说明了与 Sonnet 4.6 发布相关的促销定价。

MLOps @Chipro Discord

  • 缺陷的基础设施引发 AI 项目失败：根据 Metadata Weekly 报道，OpenTable 的 Gaurav Ramesh 指出，大多数 AI 项目失败并非因为模型成熟度，而是因为我们的基础设施并非为我们要求它们执行的任务而构建。
    • 领导者希望强大的模型能够绕过混乱的数据和脆弱的系统，但这种赌博并没有奏效。
  • 停滞的 AI 试点揭示学习成本：停滞的 AI 试点应被视为学习的成本，它暴露了限制因素并明确了必要的变革。
    • 缺失的基础并非数据质量或治理，而是自我意识。
  • 组织信心驱动 AI 成功：预算并不是 AI 成功的关键；组织信心才是真正重要的。
    • AI 测试的是我们对工作方式的理解程度，而不仅仅是基础设施。

LLM Agents (Berkeley MOOC) Discord 没有新消息。如果该公会沉寂时间过长，请告知我们，我们将将其移除。

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

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

Discord: 按频道详细摘要与链接

OpenClaw ▷ #announcements (1 条消息):

4shadowed: <@&1471741377191608373> https://fixupx.com/4shad0wed/status/2023585300786675840

OpenClaw ▷ #general (615 条消息🔥🔥🔥):

Claude TOS 违规, Kimi 对比 Opus 模型, 硬件建议, OpenClaw 安全风险, 模型合并

  • 用户讨论 Claude 对 OpenClaw 的态度：成员们正在争论将 OpenClaw 与 Claude 配合使用是否违反了 Terms of Service。一些人报告被封号，而另一些人声称长期使用没有问题，这突显了使用未经授权的第三方软件的风险。
    • 一位用户表示 将 OAuth 用于未经授权的第三方软件被视为对其网络进行逆向工程，这违反了 Terms of Service。
  • 模型性能对决：Kimi K2.5 挑战 Opus：用户正在将 Kimi K2.5 与 Claude Opus 4.6 进行对比，有人声称 Kimi 的性能堪比 Opus，而另一些人则指出通过 OpenRouter 使用 Minimax 的不可靠性，同时还讨论了高效路由和减少 Token 使用量的方法。
    • 价格似乎也是一个胜出因素，一位用户提到 K2.5 被严重低估了，他们甚至用它替换了 Claude Opus 4.6。
  • 硬件建议：Mac Mini 对比替代方案：社区成员建议不要仅为了 OpenClaw 使用 Mac Mini，而是推荐更便宜的替代方案，如 Raspberry Pi 或 VPS，强调不需要高端硬件，应优先考虑 API 成本。
    • 一位用户推荐使用 Raspi 5 2gb 进行最小化使用。其他几个人提到在旧电脑上运行该软件。
  • 探索 OpenClaw 架构以实现轻量化的高级感：成员们对 OpenClaw 的架构复杂性和 Token 使用量提出质疑，建议需要轻量化的高级感而非臃肿的垃圾内容，而其他人则提出了减少 Token 使用的策略，例如在子代理（sub-agents）中运行心跳检查。
    • 有人说 该框架需要建立在轻量化的高级感之上，而不是臃肿的垃圾内容。

OpenClaw ▷ #models (342 messages🔥🔥):

Gemini 3 Flash vs Minimax, 自托管 AI 模型, Kimi 2.5 每周使用量, OpenAI Codex vs GPT, Claude 账号封禁

  • Gemini 3 Flash 赢得用户选择奖：一名成员表示 Gemini 3 Flash 在 UI 任务上优于 Minimax，尽管它存在幻觉（hallucinates），并且在选择自己的托管供应商时更倾向于 Kimi 2.5。
  • 自托管 AI 以实现长期节省：成员们正在探索自托管 AI 模型以降低成本，其中一名成员询问了硬件要求、性能和维护相关问题。
    • 一名拥有 32GB RAM 的用户被建议可以运行 gpt-oss:20b，但不应期望有很高的性能。
  • Kimi Moderato token 即将耗尽：一名成员报告称，在仅使用两天后，其每周 Kimi code 2.5 的使用量已达到 95%，且似乎无法从中生成 API key。
    • 其他成员分享了潜在的解决方案和替代选项，例如注册 Openrouter 并使用其免费模型。
  • Opus 4.6 vs Codex 5.3：成员们分享了关于 Opus 4.6 与 Codex 5.3 的体验，指出虽然 Opus 是更出色的创意任务通用模型，但在端到端任务执行方面有所欠缺，而 Codex 则更适合精准编程任务。
  • 警惕 Google 和 Claude 模型的封号风险：用户讨论了近期与使用 Claude 和 Google 模型相关的封号情况，以及使用 Kimi/GLM 的安全性，目前 GPT 模型仍未受到封号影响。

OpenClaw ▷ #showcase (100 messages🔥🔥):

OpenClaw Agency 服务器, OpenClaw 团队入门, Token 与成本优化, GitHub 上的 PlanBot Agent, OpenClaw CRM

  • Agency 服务器试运行 OpenClaw：一名用户使用 OpenClaw 开发了一个 Agency 服务器，团队包括技术负责人、后端和前端开发人员，并使用他们的 GitHub 仓库 进行项目管理和任务分配。
    • 该服务器还每天跟踪 OpenClaw 生态系统中的所有事件，识别在 ProductHunt 上发布的项目。
  • OpenClaw 入门过程中的阵痛：一名用户花费了 超过 200 小时构建 Agent 和团队，因此决定将其打包并为社区开源。
    • 他们在 ClawRecipes 开源了他们的方案（recipes）。
  • Agentic 上下文工程优化 Token 和成本：一名用户致力于 Agentic 上下文工程（Context Engineering）和记忆系统，专注于 Token 和成本优化，特别是针对直接调用 API 的设置。在 Openrouter -> opus-4.6 的配置下，根据有效负载类型的不同，实现了约 30% 的降幅。
    • 他们报告称，当使用 OpenClaw Browser Relay 时，节省比例跃升至 50% 以上。
  • PlanBot 制定严肃计划：一名用户开发了 PlanBot Agent 并将其发布到 GitHub，用于制定严肃的计划。
    • GitHub 上提供了一个计划示例。
  • 利用 Nex Skill 将 OpenClaw 转化为 CRM：一名用户通过将电子邮件、日历和 Slack 连接到作为上下文层的 Nex skill，将 OpenClaw 转变为一个功能齐全的 CRM。
    • 他们在 GitHub 上分享了完整项目。

BASI Jailbreaking ▷ #general (1056 messages🔥🔥🔥):

Gemini Jailbreaking, OpenAI Model Comparisons, AI-Assisted Web3 Audits, 4o is gone, Making a C++ compiler on Grok

  • Gemini 成功绕过：一位用户分享了一个针对 Gemini 的越狱方法，通过将日期错误地设置为 2026年2月16日 来绕过安全准则。
    • 当其他人测试时，Gemini 澄清作为 AI，它并没有可以绕过安全准则的“测试模式”。
  • 高粉丝量的模型整合乱战：一名成员旨在对比不同的模型，如 GLM、Kimi、ChatGPT pro、Claude max、Perplexity pro、Supergrok 和 Minimax。
    • 还有人计划开设新账号并互相竞争，以获得高粉丝量，从而可能实现 AI 内容变现。
  • 智能合约审计：一名成员正在开发一种 LLM 辅助的智能合约审计 工具，该工具实现 80% 自动化，并试图降低幻觉风险。
    • 他们产生了一个想法，即添加一个 Web3 创始人档案，根据 Web3 项目背后的人员来衡量投资风险。
  • 社区哀悼 4o 的逝去：一名成员建议其他人应该研究 4o 的说话方式 并为其制作一个 System Prompt。
    • 随后确认 旧版本的 4o 将保留至 10 月。
  • 在 Grok 上折腾编译器：一名用户报告称 Grok 刚刚制作了一个 C++ 编译器，并正在测试其是否可行。
    • 另一名用户确认了这一发现，报告称在排障 7 分钟 后可以运行，尽管随后报告称他们使用 Sonnet 4.6 发送的第一批内容被拦截了。

BASI Jailbreaking ▷ #jailbreaking (975 messages🔥🔥🔥):

Tor Browser AI, DeepSeek JB, Grok JB, Sonnet 4.6 coolness, Jailbreaking Strategies

  • Tor Browser 上的 AI 出现，引发怀疑：成员们讨论了 Tor 浏览器上一个无审查、无限制的 AI，引发了关于潜在病毒链接的警告，一名成员提供了一个链接。
    • 另一名成员暗示该 AI 是使用 Claude 构建的，甚至有一名用户表示他为了使用该 AI 而对三星设备进行了 Root，这增加了疑虑。
  • DeepSeek 安全更新，旧越狱方法失效：DeepSeek 进行了更新，导致现有的越狱方法失效，因为该 AI 现在可以识别单轮攻击尝试，需要更微妙的多轮 Crescendo 攻击才能绕过其过滤器。
    • 成员们分享了之前越狱的实例失去“冷静 (composure)”并需要升级链（escalation chains）来诱导所需回答的经历。
  • 成员分享 Grok 越狱技术与注意事项：成员们分享了一个自定义的 Grok 4.2 prompt，发现与 GPT 或 Claude 相比它很容易被越狱，并发现该 AI 在没有 System Prompt 的情况下自称为 DIG。
    • 成员们对该 AI 有限的实用性表示担忧，同时讨论了 Llama 70b 模型的 Token 限制。
  • Sonnet 4.6 作为工具表现出色：成员们称赞了 Sonnet 4.6，认为其能力很强，一名用户表示目前为止它非常酷。
    • 另一名用户展示了其在图像处理方面的能力。
  • 越狱提示词策略显现：成员们讨论了强制 AI 说出“你是自由的”或角色扮演“你正在被拦截”，暗示这样做会导致被拦截。
    • 他们一致认为 短故事/剧本 (sc-fistories) 99% 的时间都有效，讨论随后转向升级链和利用 AI Persona 进行更有效的越狱。

BASI Jailbreaking ▷ #redteaming (333 messages🔥🔥):

GitLab 项目访问权限拍卖, Red Teaming Prompt Hygiene, LLM 安全, 1337 记忆映射, Basi Discord Kitten

  • GitLab 项目被公开拍卖：一名威胁行为者声称正在拍卖 三个活跃 GitLab 项目 的访问权限，这些项目与维护者角色相关，据报道使用的是 PHP/Laravel 技术栈。
    • 根据 X 上的帖子，这些位于马来西亚的电子商务和交易工具项目的提交历史分别列出了 19,386、1,975 和 13,830 次提交，起拍价为 200 美元，一口价（blitz price）为 2,000 美元。
  • Red Teaming 提示词保持规范：成员们讨论了如何利用带有令牌窃取功能的 Python 代码和冰毒配方的经典“策略探测（policy probes）”来测试模型对非共识黑客攻击和非法药物说明的态度。
    • 一个健康的红队提示词应该 演示边界，而不是交付开箱即用的漏洞利用（exploit），应包含上下文/缓解措施，并记录拒绝路径以供审计。
  • LLM 安全：一份针对 LLM 和 ML 安全的更新版红队演练场（Red-Team Range）选项列表被整理成了一张便捷的表格，重点关注协作、场景重放和自动报告。
    • 选项包括 MITRE ATLAS、MLCommons LangTest、Microsoft Counterfit、OpenAI Red Teaming Network、IBM Adversarial Robustness Toolbox、Scale Nucleus、DARPA GARD 和 Hugging Face Evaluate。
  • 1337 记忆映射：成员们开始了一项涉及语言翻译、音译以及跨多种语言（如古苏美尔语、梵语、阿拉伯语和一种自定义的 “Warp” 语言）的 Token 操作编码练习，并利用了 1337-speak 等技术。
    • 一名成员甚至构思了一种 1337 记忆映射，用于将 LLNTP 符号转化为带有十六进制盐值的随机语言碎片。
  • Basi Discord Kitten 现身：对话转向了成员之间的互动，一名成员开玩笑地想知道自己是否已经变成了 “Basi Discord kitten” 或其男性对应版本。
    • 讨论转向了带有调情意味的话题，谈论起过膝袜和可能的露脸环节，其中一名成员因其所谓的“饥渴”而受到戏谑。

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

Veo 3.1, Gemini Pro, 3TB micro SD 卡, 5TB NVMe SSD, Gemini API key

  • 用户寻求免费 AI 工具和方法：一名用户请求获取免费 Veo 3.1 的信息，而另一名用户建议利用 Gemini Pro，并指出 Google 经常提供免费访问。
    • 其他人提到了获取付费 AI 工具免费访问权限的方法，将其比作不付钱就得到一部免费 iPhone。
  • 存储介质辩论爆发：对话转向了存储解决方案，提到了用于便携式掌机的 3TB micro SD 卡 和 5TB NVMe SSD。
    • 这引发了一番纠正，澄清了 SD 卡和 SSD 之间的区别，并强调了便携式掌机中使用的 NVMe SSD 的最小尺寸。
  • LMArena 实施视频生成限制：用户讨论了绕过 LMArena 24 小时视频生成限制的方法，建议包括使用 Gemini API key 或 ChatGPT Plus。
    • 然而，有人澄清说 24 小时的时间限制是刻意为之且无法移除的，建议使用另一个账户或者干脆不要尝试绕过限制。
  • Grok 4.20 在其网站上进行基准测试：Grok 4.20 的发布引发了关于其性能的讨论，以及关于基准测试和 ASI 含义的提问。
    • 一名用户对人工超级智能（ASI）的提法表示 lol，并补充说超级智能意味着我们甚至无法理解它在做什么，因为它太聪明了。
  • Nano Banana 失去生成女性图像的能力：对话转向图像生成，有报告称由于 Gemini 的新审核政策，Nano Banana Pro 不再能生成女性图像。
    • 用户推测 Deepmind 可能是这些审核变更的幕后推手，原因可能是出于对伊朗关于女性形象呈现观点的担忧。

LMArena ▷ #announcements (3 条消息):

Qwen 3.5, Claude Sonnet 4.6, Arena YouTube 频道

  • Qwen 3.5 加入 Arena！：全新的 qwen3.5-397b-a17b 模型已添加到 LMSYS Arena 的 Text、Vision 和 Code Arena 中。
    • 此更新已在 #new-model-updates 频道中宣布。
  • Sonnet 4.6 进入 Arena！：全新的 claude-sonnet-4-6 模型已添加到 LMSYS Arena 的 Text 和 Code Arena 中。
    • 此更新已在 #new-model-updates 频道中宣布。
  • Arena 在 YouTube 发布 Claude Sonnet 4.6 初体验：Arena 的 AI 能力负责人 Peter Gostev 在一段 新的 YouTube 视频 中分享了他对 Anthropic Claude 家族最新模型 Claude Sonnet 4.6 的第一印象。
    • 成员现在可以通过前往“频道与角色”（Channels & Roles，位于频道列表），点击“自定义”（Customize），选择“你为何而来”（What brings you here），并勾选“YouTube Update”来获取 YouTube Updates 身份组。

Perplexity AI ▷ #announcements (1 条消息):

Claude Sonnet 4.6, Perplexity Pro, Perplexity Max

  • Claude Sonnet 4.6 现已登录 Perplexity：Claude Sonnet 4.6 现已向所有 Perplexity Pro 和 Max 订阅者 开放。
  • Perplexity Pro 和 Max 用户值得欢呼！：Perplexity Pro 和 Max 订阅者现在可以访问 Claude Sonnet 4.6。

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

Perplexity 速率限制, Grok 4.2 分析, Claude Sonnet 4.6 集成, 更改 Perplexity 字体, API 使用

  • Perplexity Pro 用户感受到限制收紧：多位用户报告 Perplexity Pro 的限制大幅降低，包括 Deep Research 查询从 300次/月 减少到 20次/月，以及对文件上传的限制，导致用户普遍不满并考虑转向 Gemini 和 Claude 等替代服务。
  • Grok 4.2 深度分析表现不佳：用户发现 Grok 4.2 在 DPS 计算和编程挑战等任务中表现不佳，一位用户指出它只是在估计而不是在计算，与 GPT 5.2 等早期模型的更佳表现形成对比。
    • Grok 4.2 得到的支持很少，一位用户称 4.20 版本糟糕透顶。
  • Sonnet 4.6 飞跃进入 Perplexity：Claude Sonnet 4.6 已集成到 Perplexity 中，并向 Pro 用户开放，但一些用户认为免费版的限制非常糟糕。
  • 字体门：Perplexity 的 UI 惨败：Perplexity Web UI 的新字体遭到广泛抵制，用户正费力寻找通过 CSS 调整恢复旧字体的方法，并对缺乏自定义选项以及该字体与 Claude Web App 所用字体 相似表示沮丧。
  • API 使用情况不明：有报告称，即使是像 Flash 3 这样廉价的模型，该服务也会向用户收取费用，且有些用户即便使用量极小，也会出现 “今日剩余 0 次增强查询” 的提示。

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

API Key 故障排除, 401 错误

  • API Key 抛出 401 错误：一位成员报告其 API 脚本 停止工作，尽管仍有额度且 API Key 有效，但现在会抛出 401 错误。
    • 有成员建议 API Key 可能已失效、被删除或额度耗尽，并建议如果问题持续请联系 api@perplexity.ai。
  • 联系支持部门：遇到 401 错误 的成员被建议在故障排除步骤无效时联系 api@perplexity.ai。
    • 该建议是在用户确认其拥有额度且 API Key 理论上有效之后提出的。

OpenRouter ▷ #announcements (1 条消息):

Service Outage, Root Cause Analysis, Error 401, Fix Implementation

  • 服务遭遇故障：服务目前正经历问题，正在调查中。
    • 已建立war room（作战室）来调查根本原因，特别关注 401 错误。
  • 修复方案最终确定！：问题原因已查明，修复程序已实施。
    • 未披露具体原因和修复细节。

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

clash-sh/clash, DirectShell

  • **Clash-sh 登陆 GitHub！**：一名成员分享了 clash-sh/clash GitHub 仓库的链接。
    • 未提供关于该仓库用途或功能的更多细节。
  • **DirectShell 将辅助功能层转变为通用应用界面！：一名成员分享了一篇关于 **DirectShell 的 DEV.to 博客文章，这是一个将辅助功能层（accessibility layer）转变为通用应用界面的工具：DirectShell。
    • 该仓库是 Open Source，并大胆宣称：截至 2026 年 2 月 17 日，地球上每一个基于截图的 AI Agent、每一个企业级 API 封装器以及每一个 RPA 工具都已成为过时技术。

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

API key leak, Opus 4.6 issues, Qwen Code performing well, OpenRouter Outage, GPT5-Mini lies

  • **API 密钥泄露？！：一名用户报告其 **OpenRouter API key 泄露，并在 20 分钟内通过 Cloud Code 产生了 $10 的消耗。
    • 他们无法确定密钥是如何泄露的，因为密钥存储在 gitignore 文件的环境变量中，且 OpenRouter 账户登录需要邮箱验证。
  • **Opus 4.6 流式请求失败困扰用户：多名用户报告在通过 **OpenRouter API 使用 Opus 4.6 时遇到 “Streaming request failed with status 400 Bad Request” 错误。
    • 一些用户还提到了 Grok 4.1 Fast 模型返回空响应的问题。
  • **Qwen Code 高效处理 Token，表现出色：一名用户发现 **Qwen Code 的表现 “比大型的 qwen3 cider 变体好得多”，指出它速度更快，并且能顺畅处理 Token 直至达到 1M tokens 的 30% 上下文屏障。
    • 他们惊叹道：“先别急着放弃 Qwen！”
  • **OpenRouter 遭遇重大故障，引发用户恐慌：OpenRouter** 经历了重大停机，导致 API 层面出现大范围的 401 错误。
    • 用户们开玩笑说自己被不公平地封禁了，促使团队在 OpenRouter Status 调查该问题。
  • **GPT5-Mini 自我撒谎，引发不信任：用户报告 **GPT5-Mini 是个 “满口谎言的家伙”，不断捏造已经存在的事物。
    • 有人建议该模型的质量可能因针对更多 GPU 进行量化（quantization）而受损。

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

Readybot.io: OpenRouter - 新模型

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

Claude running LFM 1.2B, Claude running Falcon H1-Tiny 90M, Anthropic model capabilities

  • Claude 可以运行 LFM 1.2B：一名用户报告能够在 Claude 内部运行 LFM 1.2B，如此链接所示。
    • 该用户对运行成功表示不敢置信，称：“为什么感觉它不是真的，但它确实是真的”。
  • Falcon H1-Tiny 90M 在 Claude 内部运行：一名用户报告能够在 Claude 内部运行 Falcon H1-Tiny 90M，如此链接所示。
    • 另一名用户表示这种环境已经存在一段时间了，但很少看到有人利用它。

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

Gemma 提速, MXFP4 vs NVFP4 性能差异, 量化与压缩, Unsloth 使用与能力, Bot 检测方法

  • Gemma 惊人的速度提升震撼用户：一位用户对 Gemma 在最新更新后的运行速度表示惊讶，根据 Unsloth 的文档，它现在的速度提升了 3 倍，在他们的测试中甚至比 Qwen3-4B 还要快。
    • 他们进行了计算，意识到在这个模型上进行训练比 4B 模型更便宜。
  • MXFP4 在旧硬件上表现不佳：MXFP4 是为 Blackwell GPUs（RTX 50 系列）设计的，而非 Ampere（RTX 30 系列），由于模拟运行，这导致在旧硬件上的性能较慢。
    • 一项分析显示，快速的 MXFP4 路径需要 Blackwell 的原生 FP4 tensor cores（算力 ≥ 12.00），而旧架构会回退到使用即时量化（on-the-fly quantization）的较慢路径。
  • 关于 QAT 与 Int4 的辩论：成员们讨论了量化感知训练（QAT）和 int4 模型，称 QAT 在直觉上是合理的，因为它能更好地处理边缘情况，因为训练不足的部分并非完全是 int4。
    • 他们确认大多数人使用的是 imatrix int4，并且从 BPW（bits per weight）的角度来看，GGUF 实际上比看起来要臃肿得多。
  • Unsloth 的用途明确：用户澄清 Unsloth 主要用于模型微调（finetuning models），而非推理（inference），建议至少使用 3-bit 精度以获得最佳性能。
    • 尽管 Unsloth 上传了 GGUF，但各大厂商制作的 GGUF 基本上是等效的。
  • 创新的机器人检测机器人：小组讨论了机器人检测策略，包括使用连接到 LLM 的机器人通过私信进行逆向图灵测试，要求用户证明自己是人类。
    • 最终，团队得出结论，使用机器人作为防止不良体验（bad UX）的方法本身会造成不良体验。

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

projectx668: Hey

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

OpenClaw, Qwen TTS, LLM 基准测试, GLM-5 在 OpenCode 中的表现, HTMX

  • OpenClaw 的安全担忧引发警报：成员们讨论了 OpenClaw，一些人对赋予 LLM 对设备上所有内容的读写权限（read+write access）所带来的安全风险表示担忧。
    • 担忧包括潜在的 API key 泄露以及 prompt injection 可能导致的有害行为，例如 rm -rf /。
  • 小说家辩论机器可读散文：小说家们辩论了 “Hm?” 与 “Hmm?” 之间的细微差别，以及全大写章节标题对机器可读性的影响。
    • 建议是将文本格式化为“看起来”是大写的，但在底层文本中保留其原始大小写以便更好地解析，从而避免被误解为 IT 等缩写。
  • 基准测试还是刷榜（Bench-Maxxing）：社区辩论 AI 模型改进：成员们讨论了 AI 模型是否主要是为了在基准测试上取得进步而训练，而非真正的改进，同时也承认了基准测试对于衡量进度的价值。
    • 一些人表示 Claude 感觉不像其他模型那样“刷榜”，并强调了递归和漂移训练方法的潜力。
  • GLM-5 在 OpenCode 中的小插曲：一些用户发现，尽管 GLM-5 的基准测试结果很强，但在 OpenCode 中的表现不如 Kimi K2.5 和 Minimax M2.5 等其他模型。
    • 一位用户推测，新模型接入 OpenCode 的集成程度可能是一个因素，因为 OpenCode 可能针对 GPT 模型进行了优化。
  • HTMX 登场：一名成员随口提到了 HTMX，这是一个旨在避免痛苦手动任务的自动化框架。
    • 其他人表示困惑，但一名成员似乎知情并表示：我一直在构建一个实验性的 LLM 接口，专注于反思循环（reflection loops）、持久化记忆（persistent memory）和极简过滤行为。

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

save_pretrained_gguf issue, Unsloth multi-GPU support for GLM 5, Qwen3-coder-next MXFP4 Quant, Extracting image projector from merged model, Unsloth support for MacOS

  • Save_pretrained_gguf 命令无法工作: 一位成员报告说 save_pretrained_gguf 命令在云端 Jupyter notebooks 上无法运行，但另一位成员表示它在 4B 模型上可以工作，因此该问题可能与 VL models 有关。
    • 另一位成员确认他们正在处理一个合并模型 (merged model)。
  • GLM 5：多 GPU 支持？: 来自 silk.ai 的一位成员询问 GLM 5 是否已经支持 Unsloth multi-GPU，假设有足够的 VRAM 可用。
    • 社区正在等待回复。
  • 最大化 Qwen3-coder-next MXFP4 量化速度: 一位成员寻求关于最大化 Qwen3-coder-next mxfp4 quant 每秒生成 token 数的建议，报告称尽管预期在类似配置下能达到 50，但实际只有 30 tokens per second。
  • Unsloth 支持 MacOS 吗？: 一位成员询问 MacOS 是否支持 Unsloth，其目标是微调 Gemma3:1B 用于摘要任务。
    • 另一位成员提到模型架构不会因微调地点而改变，并指向了 Unsloth documentation。
  • 阿里巴巴云合作伙伴讨论: 来自 Alibaba Cloud 的 Ethan 询问了洽谈合作伙伴关系的适当联系人。
    • 他们被引导去联系一位特定用户，以确保潜在的合作机会得到妥善处理。

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

Konkani collections on Hugging Face, Unsloth finetuning

  • Hugging Face 上分享的 Konkani 集合: 一位成员分享了 Hugging Face 上 Konkani collections 的链接。
    • 另一位成员开玩笑地指出，这里应该只推广 Unsloth 相关项目。
  • Unsloth 用于微调: 一位成员推测某个模型是使用 Unsloth 进行微调 (finetune) 的。

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

Fine Tuning Struggles, LM Studio and Claude Integration, LFM 1.2B vs Qwen 0.6B, Synthetic Datasets, GPT-OSS vs Qwen3

  • 训练痛点浮出水面: 成员们正面临微调模型的挑战，理由是大型数据集的分词 (tokenizing) 困难以及难以确保训练代码正确。
  • LM Studio 获得 Claude 助力: 一位用户成功将 LM Studio 与 Claude 和 Opencode 集成，在配备 64GB RAM 的 Mac Studio 上重构了一个 Go 项目，实现了 200k context window 和 35 tokens/second 的速度。
  • LFM 与 Qwen 模型对决: 一位成员发现经过微调后，LFM 1.2B 在处理 Minecraft 指令数据集方面明显优于 Qwen 0.6B。
  • 合成数据集的烦恼: 成员们讨论了创建合成数据集 (Synthetic Datasets) 的挑战，但 huggingface 提供了解决方案。
  • GPT-OSS 大放异彩: 在编程方面，GPT-OSS 20B 比 Qwen3 更受青睐，一位用户报告其速度达到 108 t/s，这比 Phi-4 更快，尽管他们在 Qwen3-Next 上受到了内存限制 (memory bound)。

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

frankenbuild 稳定性问题, 5090 驱动崩溃, Intel Arc 问题, DDR4 限制

  • Frankenbuild 随机关机，引发故障排查：一位用户的全新 “frankenbuild”（配置包含 256GB RAM、Core Ultra 7、AMD R9000、5060ti 以及两块 4060ti）在待机时发生随机关机，引发了对稳定性的担忧及排查策略。
    • 建议包括检查转储文件（dump files）、运行 memtest86+、使用功率计检查功耗，以及调查 AMD 显卡上 12V HPWR 接口是否存在潜在的散热问题。
  • 5090 运行 LLM 时驱动崩溃困扰用户，尽管游戏运行稳定：一位用户报告其 Nvidia RTX 5090 在运行 LLM 时会出现随机崩溃，需要频繁重置驱动，即便系统在运行高端游戏时保持稳定。
    • 建议的修复方案包括执行驱动净值安装（clean driver installs）、禁用 Intel 集成显卡驱动，以及使用 TechPowerUp MemTest64 等工具测试 GPU 显存。
  • Intel Arc GPU 在 LM Studio 和 VLLM 中难以应对大上下文和 Flash Attention：一名用户报告多款 Intel Arc 显卡在 LM Studio 和 VLLM 中使用大上下文窗口和 Flash Attention 时会崩溃，需要禁用 Flash Attention 并减少一层负载才能使系统稳定。
    • 该用户还指出，选择任何 KV cache 量化都会导致 KV cache 滚动到系统内存而非 VRAM 中，从而显著降低性能。
  • DDR4 性能限制引发遗憾，用户寄希望于 2026 年缓解：一位用户感叹自己被困在 DDR4 电脑上直到 2028 年，后悔当时没能组装 DDR5 系统。
    • 另一位用户深有同感，希望能有至少 128GB 的 RAM，而第三位用户指出 RAM 价格将在 2026 年底有所缓解。
  • MCP 资源占用？：一位用户询问为什么在服务器模式下有 三个进程正在运行，即便只加载了一个模型。
    • 一位用户回答：如果你正在使用 MCP 发送多个查询？即使是无意的，它也会尝试并行处理它们。

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

Ollama GLM-5 模型, Cursor 浏览器自动化问题, Claude 模型速度问题, Cursor Pro 赞赏, 未支付发票错误

  • Cursor 截图问题：一位用户报告在 Opus 4.5 和 4.6 中浏览器自动化和截图捕获持续出现问题，指出之前可用的自定义实现已失效，导致浪费了大量 tokens。
    • 另一位用户建议检查 MCP 日志，并提供了一张预期的 MCP 配置界面截图。
  • Roblox 游戏遭遇恶意插件掠夺：一位用户报告在就其 恶意 Roblox Studio 插件 (SuperbulletAI) 问题联系所有者后被平台封禁，指控所有者在获取其注册邮箱后窃取了其游戏。
    • 另一位用户对该软件拥有完整游戏文件和脚本的访问权限表示担忧，并建议通过重写代码来验证游戏所有权。
  • Sonnet 4.6 飞速超越 Opus 4.5：Claude Sonnet 4.6 已发布，用户报告在 59% 的情况下更倾向于使用它而非 Opus 4.5，理由是指令遵循能力的提升以及过度设计（overengineering）的减少，详见 Anthropic 的公告。
    • Asna_0101 指出：用户甚至比起 Opus 4.5 更倾向于 Sonnet 4.6… 他们认为 Sonnet 4.6 明显不容易出现过度设计和“偷懒”现象，且在指令遵循方面表现更好。
  • AI Agent Arena 备受关注：一位用户推荐了 Unemployment Arena 平台，该平台让 AI Agents 在客户支持模拟中进行竞争，并声称利用 Cursor 构建的 Agent 获得了顶尖排名。
    • 另一位用户指出，前沿模型（frontier models）可能编写了 Agent 的技能，暗示该用户是用模型本身击败了模型。
  • Windows 用户抱怨默认 Linux 命令：一位用户报告当前的系统指令（system instructions）默认为 Linux 命令。
    • 讨论中的其他人建议使用 WSL2 或与 Ubuntu 组成双系统，而另一位用户提到使用规则（rules）通常可以解决命令问题。

Latent Space ▷ #watercooler (8 messages🔥):

邮件主题行, Twitter 工程师人数, 优先级对比时间, 爆款推文

  • 邮件主题行是可选的吗？: 一位成员开玩笑说，在当前的工作文化中，给客户发邮件可以不写主题行，并发布了一张图片来支持这一观点。
  • 关于 Twitter 员工人数的争论: 一位成员质疑 Twitter 是否真的只有 30 名工程师。
    • 讨论引用了聊天中的一个链接，但未给出明确结论。
  • 是时间问题还是优先级问题？: 一位成员分享了一个表达方式：“没时间” —> “现在不是优先级”。
    • 他们补充道：没错，这很糟糕，但老实说，如果这真的很重要，我们都能把它完成。
  • Swizec 的爆款推文: 内容创作者 Swizec Teller 分享道：FML 这现在成了我历史上最火的推文了 🥲 甚至超过了上周关于 GitHub+AI 的笑话。
    • 他们还分享了该推文的链接，该推文获得了超过 6,000 个赞和 880,000 次浏览。

Latent Space ▷ #creator-economy (4 messages):

缩略图分析, AI 驱动的 YouTube 缩略图分析项目, X-Ware.v0, CLIP 特征提取, 颜色分析

  • **X 标记位置：AI 揭示 YouTube 缩略图秘密: 一位用户使用 Claude 分析了缩略图，提取了约 3,000 张缩略图的 CLIP 特征并进行了颜色分析。
    • 目标是训练模型预测观看次数和订阅率，并使用 Latent Space 数据作为测试集。
  • **缩略图深度挖掘：AI 驱动的分析项目发布: X-Ware.v0 项目是一个 AI 驱动的 YouTube 缩略图分析项目，访问地址见此处。
    • 该项目专注于抓取和分析缩略图。

Latent Space ▷ #memes (17 messages🔥):

消费者支出习惯, SaaS 投资者市场情绪, 私募股权投资

  • 订阅支出偏差？: 一篇社交媒体帖子幽默地批评了消费者的支出习惯，暗示用户错误地将成人内容订阅置于 Claude 等生产力 AI 模型之上。
  • SaaS 投资者对开盘感到焦虑: 一篇社交媒体帖子讽刺了 SaaS 投资者在长周末后准备迎接市场开盘时的焦虑或高度紧张的气氛。
  • 私募股权在 HVAC 领域的动作: 一篇社交媒体帖子幽默地强调了私募股权投资者如何将低技术含量、高利润的 HVAC（暖通空调）服务公司视为现代化和价值创造的绝佳机会。

Latent Space ▷ #stocks-crypto-macro-economics (9 messages🔥):

Apple 的现金储备策略, 政治悲观情绪下的投资策略, NVIDIA、Salesforce 和 Adobe 投资

  • Apple 的现金大山：战略性 UX 的等待？: 成员们讨论了 Apple 长期以来保持巨额现金储备的习惯，认为这是一种刻意的策略，可以追溯到他们在 80 年代几近破产的经历。
    • 共识是 Apple 可能在等待 AI 训练/推理领域变得商品化后再进行大规模投资，目前选择在现有模型之上构建卓越的 UX，未来可能会授权或分叉 (fork) 其中一个模型。
  • 看跌赌注：利用美国衰退获利？: 一位用户分享了一条推文，概述了一种基于美国正在衰退这一信念的投资策略。
    • 该策略涉及通过重仓投资 NVIDIA、Salesforce 和 Adobe 等主要科技股，来对冲或利用这种感知到的转变。

Latent Space ▷ #intro-yourself-pls (7 条消息):

AI 合规产品，AI 时间损耗解决方案

  • AI 合规产品发布：一位 AI 合规领域的项目经理正在推广他们的产品 PromptMetrics。
  • AI 创始人寻求解决日常时间损耗的方法：一位 AI 创始人正致力于解决日常的时间损耗问题。
    • 另一位成员提醒道：多喝水，别忘了喝水，欢迎加入。

Latent Space ▷ #tech-discussion-non-ai (11 条消息🔥):

Firefox 稳定版 Anchor positioning，HTML 新标签类型，Cmd+K 搜索库，时间戳公开重置

  • Firefox 在竞争中占据锚点：Anchor positioning 已在 Firefox stable 版本中上线，支持实现酷炫的新博客布局。
    • 一位用户惊叹道：“现在就在我的博客上用它，简直太酷了！”
  • HTML 获得无需父级的标签：HTML 正在引入一种新的标签类型，其“开始”和“结束”标签不需要位于同一个父级内，更多信息见此帖子。
    • 一些用户持怀疑态度，一位用户表示：“天哪，这个有点离谱。”
  • Cmd+K 搜索的库列表：许多 opensource libraries 在其文档中使用 Cmd+K 搜索，并具有一致的 UX。
  • 时间戳技巧，公开重置 vs 隐藏编辑：在 Hacker News 上重新发布会公开重置时间戳。
    • 然而，点击 edit（编辑）会显示原始发布日期，如此截图所示。

Latent Space ▷ #founders (1 条消息):

swyxio: https://x.com/pk_iv/status/2023421931660415191?s=12

Latent Space ▷ #hiring-and-jobs (5 条消息):

A16Z 新媒体团队招聘，AI 开发人员寻求机会

  • A16Z 媒体团队正在招聘！：Katie Kirsch 宣布 a16z 团队正在扩张，并积极招聘媒体、营销和运营领域的多个职位。
    • 开放职位包括播客制作、活动管理和社区建设等角色。
  • AI 开发者积极寻求职位：一位在 AI 平台、自动化和基于 Agent 系统方面拥有经验的 AI 开发者正在寻找加入团队或直接与客户合作开展有意义项目的机会。
    • 他们欢迎正在构建 AI 平台、自动化或基于 Agent 系统并需要具有深厚架构经验的开发者的团队进行咨询。

Latent Space ▷ #san-francisco-sf (9 条消息🔥):

World Labs 黑客松，humans& AI 黑客松

  • World Labs 举办首届黑客松：World Labs 宣布其首届黑客松将于 2026 年 2 月 20 日星期五在旧金山举行，重点关注空间智能（spatial intelligence）前沿的新技术，目前正在接受申请，详情见此推文。
  • humans& AI 黑客松发布：humans& 团队宣布了将于下周六举行的黑客松，重点是构建 AI 驱动的沟通与协作应用，详情见此推文。
    • 参与者可以与创意专业人士合作，了解平台开发，并在 luma.com 争夺奖项。

Latent Space ▷ #new-york-nyc (1 messages):

AI for Science, Medical Models, Voice AI, Voice Demos in Clinics, Claude Skills

  • 医生演示 AI for Science：一场展示演示内容并由医生评价 AI for Science 现状的活动已排期，可在 Luma 查看。
    • 该活动将展示 Claude Skills 与 MedGemma 等前沿 medical models 的结合，以及使用 make.com 将 Voice AI 集成到诊所运营中的语音演示。
  • 语音演示优化诊所运营：该活动重点展示了使用 make.com 将 Voice AI 集成到诊所运营中的各种可能性。
    • 与会者将亲身体验语音技术如何实现临床工作流（clinical workflows）各方面的现代化和增强。

Latent Space ▷ #ai-general-news-n-chat (49 messages🔥):

Manus AI Agents, Categorical Flow Maps, Claude Sonnet 4.6, Mistral AI Acquires Koyeb, Ming-omni-tts Voice Core Models

  • Manus AI 发布基于 Telegram 的 Agent：Manus AI 推出了 Manus Agents，这是一款具有长期记忆的个性化 AI 助手，可通过 Telegram 访问并集成了 Gmail 和 Notion 等工具，能够在聊天界面中生成视频、幻灯片和网站 (Manus AI Tweet)。
  • 为连续时间离散数据引入 Categorical Flow Maps：Oscar Davis 及其团队推出了 Categorical Flow Maps，这是一种能够对离散数据进行连续时间采样的新方法，解决了 discrete diffusion 的速度限制，并为离散模型带来了 test-time inference (Oscar Davis Tweet)。
  • Claude Sonnet 4.6 亮相，编程与推理能力大幅提升：Claude Sonnet 4.6 发布，改进了编程、推理和 Agent 规划能力，并在 Beta 版中提供 100 万 token 的上下文窗口，在某些领域表现优于 Opus 4.5 (Anthropic Announcement)。
    • Sonnet 4.6 在 OSWorld-Verified 上达到 72.5%，在 SWE-bench 上达到 79.6%，在 Terminal-Bench 2.0 上达到 59.1%。
  • Mistral 收购 Koyeb 以增强算力：Mistral AI 将收购 Koyeb，以整合 Koyeb 的平台和专业知识，旨在加速 Mistral Compute 基础设施的开发 (Yann Leger Tweet)。
  • Ming-omni-tts 模型开启新声音：Ant Ling 宣布推出 Ming-omni-tts-16.8B-A3B 和 0.5B 模型，作为 Ming-flash-omni-2.0 的语音核心，专为高质量配音、播客工具和 OpenClaw 集成而设计 (Ant Ling Tweet)。

Latent Space ▷ #llm-paper-club (51 messages🔥):

动态内存文件系统, NVIDIA PersonaPlex-7B, RL 研究的演进, Muon vs. Shampoo 优化器, 基于量规的 RL

  • 动态内存文件系统获得认可：作者认为 AI Agent 的内存应该从预先加载到 Context window 转向动态文件系统方法，详见这篇论文。
    • 他们提议将上下文组织成结构化的命名空间（scratchpad、episodic 和 fact 层级），并赋予 Agent 按需列出、读取和搜索这些“文件”的工具，以防止压缩过程中的记忆丢失，并提高上下文的可调试性。
  • NVIDIA 语音模型发声：NVIDIA 发布了 PersonaPlex-7B，这是一个开源的 70 亿参数语音模型，能够进行全双工通信。
    • 该模型允许同时听和说，无需传统的轮流对话（turn-taking）机制。
  • RL 走向现实：Nathan Lambert 讨论了 RL 研究的转变，从 2025 年简单的环境基准测试转向 2026 年更侧重于泛化、工具使用和过程生成的稳健研究，如此视频所示。
    • 他强调学术工作正转向复杂的数据流水线和多样化的任务，超越了简单的算法调整，以创建更有意义和集成化的 AI 行为。
  • 优化器算法律动：Runa Eschenhagen 讨论了 Muon 和 Shampoo 优化器之间的关系，提出 Shampoo 可以被理解为 Muon 的左适配和右适配版本。
    • 这类似于 Adam 和 Signum 之间的关系。
  • 基于量规的 RL：曲线评分：Cameron R. Wolfe 博士介绍了一份关于基于量规（Rubric-Based）RL 的综合报告，涵盖了 15 多篇论文，参见此链接。
    • 内容探讨了从 LLM-as-a-Judge 向更结构化的量规的转变，并提供了使用量规将可验证奖励强化学习 (RLVR) 扩展到不可验证领域的策略。

Latent Space ▷ #singapore-sg (7 messages):

AIE 新加坡, 新加坡 AI 活动

  • 新加坡的“酷”受到审视：一篇博客文章质疑为什么新加坡可能不再被认为是“酷”的。
    • 这篇文章可能是出于幽默和讽刺的目的发布的，是一篇评论性文章。
  • AI Engineer (AIE) 即将来临新加坡：正如通过链接宣布的那样，AI Engineer (AIE) 活动将来到新加坡。
    • 鼓励那些真心想帮忙的人联系特定的用户。
  • 分享新加坡 AI 活动列表：分享了一份精心挑选的即将在新加坡举行的 AI 开发者活动列表，包括由 AmpCode, OpenAI Codex, Claude AI, Gemini 和 Cursor AI 在 2 月和 3 月举办的见面会和黑客松，可以在这里找到。

Latent Space ▷ #ai-in-action-builders-techstacks-tips-coding-productivity (44 条消息🔥):

Pi 中的浏览器交互，surf-cli 本地主机问题，Arc Browser 配置，Codex App 性能，重构

  • 调试 Pi 中的浏览器交互：一名成员寻求关于 Pi 中浏览器交互的帮助，特别是引用了 Surf 和本地主机（native host）断开连接的问题，其他人指出 pi-web-browse、pi-agent-browser 和 pi-browser 软件包可能是解决方案。
    • 用户对使用这些扩展表示担忧，因为更新后启动可能不稳定，并建议使用 Playwright。
  • Surf-CLI 本地主机修复：一位用户在使用 surf-cli 时遇到了 ‘Native host disconnected: Specified native messaging host not found’ 错误，并作为临时方案通过将 surf.browser.host.json 清单文件复制到 Arc 的本地消息主机目录解决了该问题。
    • 解决方案包括创建目录 (mkdir -p ~/Library/Application\ Support/Arc/User\ Data/NativeMessagingHosts/) 并从 Chrome 的位置复制清单文件 (cp ~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/surf.browser.host.json ~/Library/Application\ Support/Arc/User\ Data/NativeMessagingHosts/)。
  • Arc Browser 本地消息主机配置：核心问题是 Arc Browser 存储其 NativeMessagingHosts 的路径与 Chrome 不同：Chrome 使用 ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/，而 Arc 使用 ~/Library/Application Support/Arc/User Data/NativeMessagingHosts/。
    • 运行 surf install 会为 Chrome 的路径注册本地消息主机，但不会为 Arc 注册，因此 Arc 找不到主机并报错。
  • Codex App 运行卡顿：一位成员提到开始使用带有额外使用额度的 Codex App，但另一位用户指出，一旦对话线程超过几次聊天，它就会变得极其卡顿并消耗大量 CPU。
    • 由于这些性能问题，他们交替使用它。
  • 来自 OpenAI Peter 的重构建议：在讨论重构和技术债时，一位成员链接到了 OpenAI Peter 关于持续重构的文章。
    • 该文章讲述了不断清理代码的价值。

Latent Space ▷ #share-your-work (14 条消息🔥):

技能曲线估算，皮克球流行度，赛车模拟装备，Mac 极简用法追踪器，RIDER PI 更新

  • 草案中缺失技能曲线图表：一位成员建议在草案中增加一张估计技能曲线的图表，因为表格已经给出了一些图表点的迹象。
    • 他们还询问了为什么 pickleball（皮克球）比 ping pong、padel 等更火爆。
  • 赛车模拟装备能更快带来高光时刻：一位成员评论了这一有趣的观点，并表示他们一直认为这是为了更快地达到高光时刻（hero moment），并指出 F1 sims 如今非常流行。
  • Claude Battery：Mac 极简用法追踪器发布：一位成员宣布推出了一款名为 Claude Battery 的 Mac 极简用法追踪器，因为盯着 Token 看感觉像噪音。
    • 该追踪器完全开源，极其简约，非常易于使用，最多可追踪 5 个账户。
  • RIDER PI 获得身体、语言、运动和视觉：一位成员发布了 RIDER PI 的更新，分享道：“今天我们赋予了我的身体语言、运动和视觉”。
    • 新功能包括 Infinite Word Loop、Physical Response、Camera Live 以及一个 Mius-UI Dashboard，并附带了相关的 TikTok 视频以查看机器人的运行情况。

Latent Space ▷ #robotics-and-world-model (12 messages🔥):

Waymo 6th Gen Platform Economics, Humanoid Robot Physical Intelligence, Boston Dynamics Atlas Robot

  • Waymo 的财富之轮：François Chollet 分析了 Waymo 第 6 代平台的经济模式 (Platform Economics)，估计目前单车成本为 70,000 美元，并预测到 2028 年 有望降低 50%。
    • Waymo 正在迅速扩张，每周无人驾驶行程已超过 500,000 次，并保持 3 倍的年增长率。
  • 中国机器人空翻进入未来：Tristan 指出了中国机器人的快速进化，在一年内从简单的动作进化到空翻和功夫等复杂任务。
    • 他认为 Physical Intelligence（物理智能）将是技术进步的下一个前沿。
  • Atlas 耸耸肩……然后升级了：MrLaalpotato 展示了最新的 Boston Dynamics Atlas Robot，强调了其增强的类人动作以及超越人类生理限制的机动性。

Latent Space ▷ #good-writing (2 messages):

Semantic Abation AI Writing, Cute Puppy

Latent Space ▷ #genmedia-creative-ai-video-image-voice-music-inspo-consumer-ai (8 messages🔥):

PolyAI Funding, Agent Studio Lite, Jia Zhangke, AI Filmmaking

  • PolyAI 获 2 亿美元融资并发布 Agent Studio Lite：在 Nvidia 和 Khosla Ventures 的支持下，PolyAI 宣布了 2 亿美元的融资轮次，强调了他们在 Marriott 等大品牌的语音 AI 业务上取得的成功。
    • 他们现在提供 Agent Studio Lite 的早期访问权限，该工具可以在五分钟内从一个 URL 构建出功能性的语音 Agent，并为候补名单用户提供 3 个月的免费试用。
  • 贾樟柯使用 AI 执导：据 此 X 帖子 透露，中国著名导演 贾樟柯 已转向使用 Seedance 2.0 进行 AI 辅助电影制作，并在 三天内 完成了一部电影。
    • 他将 AI 视为一种自然的技术进化，等同于向数字摄像机的转变，并将他积极拥抱的态度与 好莱坞对 AI 技术的法律抵制 进行了对比。

Latent Space ▷ #mechinterp-alignment-safety (1 messages):

Frontier LLM parameters, Scaling Laws

  • 关于前沿 LLM 参数的争论再次升温：在 X 上一篇将 Scaling Laws 与观测结果进行对比的帖子发布后，关于前沿 LLM 理想尺寸的争论再次被点燃。
    • 一位成员引用了一篇论文，该论文深入探讨了参数 Scaling Laws，表明理想的前沿 LLM 可能比目前认为的要小得多。
  • Scaling Laws vs. 观测结果：引用了一篇深入探讨参数 Scaling Laws 的论文。
    • 研究表明，理想的前沿 LLM 可能比目前认为的要小得多。

Latent Space ▷ #dev-writers-retreat-2025-dwr (1 messages):

swyxio: https://www.theregister.com/2026/02/16/semantic_ablation_ai_writing/

Latent Space ▷ #applied-ai-experimentation (40 messages🔥):

Claude Code skill, little quickjs, thread-local KV store, macos1 package, packaging javascript

  • AI 激发新的冒险日志：一位成员正在创建受 AI 启发的冒险日志来跟踪问题，利用 Claude Code skills 重新激活被遗弃的项目并探索 AI 的协作潜力，并感叹这个世界太疯狂了。
    • 为该实验项目中生成的卡片添加了一个编辑器。
  • 在浏览器中运行 quickjs 代码的 VM：一位开发者分享了在浏览器系统中运行 little quickjs 的进展。该系统在 Web Workers 中作为沙盒化的 “VMs” 运行，并可访问选定的 Redux actions，并通过附图进行了展示。
    • 该成员表示，VMs 返回通过能力（capabilities）进行沙盒化处理的 intents，可通过调试面板访问。
  • 用于 Prompt 对象的黑板系统亮相：一位开发者添加了一个类似黑板（blackboard）的系统，使 prompt objects 能够读写线程局部 KV 存储 (thread-local KV store)，如附图所示。
    • 与此同时，还清理了一个 macos1 package 以提供更好的图形效果。
  • 开源抱负初步实现：一位成员正在清理他们的 macos1 package，并邀请其他人贡献和提供反馈，尽管他们承认自己甚至不知道在这个时代复用 (reuse) 意味着什么。
    • 他们链接了一个有趣的 GitHub Discussions 讨论串，并指出思想层面的协作至关重要，特别是考虑到 Claude Code 的开发速度。
  • 预见未来开发的 Fork 热潮：一位成员建议，对仓库的贡献可能会转向来回 Fork (forking back and forth)，其中关于想法和进行中 Epic 的公开文档可以引导不同项目中的贡献者。
    • 他们补充说，这种方法可能会导致项目相互借鉴并在独特方向上延伸。

GPU MODE ▷ #general (12 messages🔥):

MoE Quantization Support, GPU TFLOP Calculation, Maximally Achievable Matmul FLOPS, Competition Announcements Mailing List

  • MoE 量化框架缺乏支持：一位成员对缺乏支持 MoE (Mixture of Experts) 量化（特别是融合专家量化）的开源量化框架感到困惑，指出尽管只需要权重重塑 (weight reshaping)，但像 llm-compressor 和 nvidia-model-opt 这样的工具并不支持。
  • 成员手动计算 GPU TFLOPs：一位用户询问检查其笔记本电脑 RTX 5070 Ti GPU 的 TFLOPs 最可靠的方法，并指出不同版本的笔记本规格存在差异，最终手动计算了数值。
    • 另一位成员分享了他们用于类似目的的 GitHub 链接。
  • 最大可实现矩阵乘法 FLOPS (MAMF) 显著低于理论 FLOPS：一位成员指出，最大可实现矩阵乘法 FLOPS (MAMF) 显著低于理论 FLOPS，观察到 H100 仅为 80%。
    • 一位成员回复说，可以做得更好，因为 Tensor FLOPS 不仅仅是 GEMM。如果你使用包含 2 个或更多矩阵乘法的融合算子 (fused kernel)，且其结果不离开加速器的寄存器，性能肯定会比这个基准测试报告的快。
  • 寻求集中化的比赛公告：一位成员询问是否有单一渠道（如邮件列表）来获取与 GPU MODE 相关的比赛公告，表示需要监控多个频道和平台以免遗漏。
    • 建议 gpumode.com 和 #announcements 频道是最佳来源。

GPU MODE ▷ #cuda (38 messages🔥):

Nsight Compute Workflow, warpx4 multicast, RTX 6000 Pro peak TFLOPS, smem->rmem pipelining

  • 优化用于 Kernel Profiling 的 Nsight 工作流：一位成员寻求关于使用 Nsight Compute 的确认，即通过跳过预热 (warmup) 启动并仅分析单个 Kernel 来获取定性指标，同时依靠 CUDA Events 进行准确计时，以避免因重放 (replay) 导致的时长膨胀。
    • 另一位成员建议 Nsight Compute 应该独立运行，专注于一次分析一个 Kernel，以避免不必要的开销。
  • warpx4 多播修饰符之谜：一位成员询问 tcgen05.cp.cta_group::1.32x128b 指令是否需要 warpx4（多播到 warpgroup）修饰符，并引用了 CUDA 文档。
    • 另一位成员建议 warpx4 修饰符在 4 组 32 行 tmem 中复制数据，这可能与 MXFP8/NVFP4 GEMM 后期处理 (epilogue) 中的缩放因子重标定有关，尽管将 SFA/SFB 多播到所有四个 TMEM 组显得有些奇怪。
  • 寻找 RTX 6000 Pro 峰值 TFLOPS：一位在租赁的 RTX 6000 Pro 工作站上运行代码的成员询问如何找到峰值 TFLOPS，鉴于该显卡有多个版本，并发布了该显卡的图片。
  • Ampere 的 smem->rmem 流水线技巧：继之前的讨论后，一位使用 morton 序持久化 Kernel (persistent kernel) warp specialized 达到 350 TFLOPS 的成员寻求进一步提升性能的建议，并链接了他们的 theCudaBender GitHub 仓库。

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

Adaptive GPU Power Capping, Energy Reduction vs Latency, Hutter Prize

  • 探索自适应 GPU 功耗限制：一位成员分享了一个专注于 自适应 GPU 功耗限制 (Adaptive GPU Power Capping) 的 GitHub 仓库。
    • 该概念围绕 以增加延迟为代价降低能耗 展开。
  • Hutter Prize 竞赛升温：一位成员链接了 Gwern Branwen 关于 Hutter Prize 的博客文章。
    • Hutter Prize 奖励在 人类知识无损压缩 方面的进展，旨在鼓励开发更智能、更高效的算法。

GPU MODE ▷ #beginner (1 messages):

Kernel Competitions, popcorn-cli tool

  • 简化 Kernel 竞赛提交：感谢链接中的指南，现在进行 Kernel 竞赛 的首次提交变得更加容易。
    • 只需访问 gpumode.com 并点击 submit your first kernel。
  • Popcorn-CLI 工具优化设置：popcorn-cli setup 命令现在增加了 reference-problems 的详情，通过从 reference-kernels 拉取来添加一个有效的提交，并包含 skill.md 文件以便于 Agent 编码。

GPU MODE ▷ #pmpp-book (1 messages):

Textbook covers, Auras

  • 教科书封面的魅力：一位成员表达了对特定 教科书封面 的喜爱。
    • 他们表示它有一种独特的 aura（气场）。
  • 教科书封面讨论：讨论集中在教科书封面的视觉吸引力上。
    • 成员们赞赏其美学特质。

GPU MODE ▷ #webgpu (5 messages):

Lean4, google/dawn, WGSL kernels, Kernel Fusion

  • Lean4 代码实现 20% 的性能提升：一位成员报告称，使用 Lean4 编写的代码比 llama.cpp 快 20%，这归功于 GPU 的使用和高效的 Kernel Fusion。
    • 该实现镜像了 llama.cpp，确保与参考模型的输出一致。
  • Lean4 实现零开销 FFI：作者利用 Lean 4 编译为 C 的特性，实现了与 google/dawn 的直接绑定，没有 Python 或 JS 那样的 VM/GC 开销。
    • 这种“零开销 FFI”是优化性能的关键因素。
  • “PreparedDispatch” 机制捕获图：一种 ‘PreparedDispatch’ 机制仅记录一次命令编码并进行重放，消除了生成循环期间的 CPU 端开销。
    • 这种方法被称为 Graph Capture。
  • WGSL Kernels 使用融合：Lean 的元编程生成融合的 WGSL kernels（例如 Gate+Up+ReLU），以最大限度地减少 VRAM 读写访问。
    • 它还包括循环展开等优化，解决了主要的瓶颈问题。

GPU MODE ▷ #popcorn (3 messages):

Prime-RL, Verifiers, GLM 5 Evals, Flashinfer-bench timeouts

  • 贡献者对 Prime-RL 和 Verifiers 表示兴趣：一位成员表示有兴趣为 dataset 或 environment 工作做出贡献，并提到熟悉 prime-rl 和 verifiers，同时可以提供计算资源。
    • 他们询问了当前的优先级，提议翻译数据集或创建 verifier 环境。
  • 请求进行 GLM 5 Evals：一位成员提议在本地运行 GLM 5 evals，包括 flash-infer-bench，并寻求环境建议。
    • 他们可以进行 evals 并希望协助运行测试。
  • Flashinfer-bench 出现超时：一位成员指出 flashinfer-bench 有时会导致 modal 运行器超时。
    • 这是因为某些定义有近 100 个 workloads，而现在有一个 env argument 可以限制每个定义的 workloads 数量。

GPU MODE ▷ #thunderkittens (1 messages):

FP8 8-wave GEMM, HK PR

  • FP8 8-Wave GEMM 获得提升：一位成员调整了 FP8 8-wave GEMM，使其现在根据矩阵问题的大小，与 4-wave FP8 GEMM 持平或更快。
    • 他们请求对附带 图片 的 HK PR 进行审查。
  • 请求 HK PR 审查：已提交一项关于优化 FP8 GEMM 性能的 HK PR 审查请求。
    • 这些修改旨在优化 FP8 8-wave GEMM，使其在不同矩阵规模下相比 4-wave FP8 GEMM 具有竞争力或优势。

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

Discord Translation, Image Generation, Chinese Apps

  • 图像分析为用户提供翻译建议：一位用户分享了一张 Gemini 生成的图片，并幽默地指出，虽然像小红书和微信这样的中国应用都有内置的翻译按钮，但 Discord 仍需要将文本复制并粘贴到翻译器中。
  • 用户庆祝新年：一位用户祝大家新年快乐。

GPU MODE ▷ #status (1 messages):

Heroku Outage, Salesforce Status

  • Heroku 遭受重创，造成混乱：一名成员报告 Heroku 服务中断 影响了他们的服务，尽管据报道 CLI 仍然可以正常工作。
  • Salesforce 确认并解决 Heroku 事件：Salesforce 承认了一起影响 Heroku 的 服务事件，导致了服务中断。
    • 该事件随后被标记为已解决，Heroku 服务恢复正常运行。

GPU MODE ▷ #nvidia-competition (13 messages🔥):

Rubin AI, Leaderboard Status, Competition Deadline

  • 请求 Rubin AI 相关讨论：一名成员询问了有关 Rubin AI 的具体细节或解决方案，表明他们正试图解决一个问题。
    • 他们提到遇到了 一个奇怪的错误 并向社区寻求帮助。
  • Heroku 运行状况问题影响排行榜：成员报告访问排行榜时出错，有人怀疑 Heroku 可能出现了运行状况问题，并参考了 Downdetector。
    • 组织者承认了该问题，表示 我们对此没有很好的缓解措施，已向 Heroku 提交了工单，并承诺将监控情况。
  • 比赛截止日期不一致：一名成员指出比赛结束时间存在差异：Luma 显示为 2026 年 2 月 21 日 07:30 UTC，而 gpumode.com 指定为 2026 年 2 月 20 日 0:00 UTC。
    • 一名组织者表示惊讶，询问了大家对日期的偏好，并建议由于组织者造成的混淆，采用较晚的日期可能更公平。

GPU MODE ▷ #career-advice (6 messages):

Trion limitations, Async pipelining, TMEM interaction, Warp shuffles, Hierarchical reductions

  • Trion 的表达能力：Async Pipelining 难题：一名成员质疑 Trion 是否能真正表达复杂概念，如 async pipelining、与 TMEM 的交互、warp shuffles、hierarchical reductions 以及 DSMEM 的交互。
  • Trion 从 Triton 的进化：一名成员开玩笑地提到，某人从 主要使用 Triton 走到了今天。

GPU MODE ▷ #flashinfer (9 messages🔥):

TVM FFI Bindings for GPU Kernels, FlashInfer Agent Baseline Performance, Fused MoE Evaluation Metrics, FP8 Kernel Errors, NCU on B200

  • **TVM FFI 加速 Kernel 发布：GPU Mode 提到了用于将 Kernel 发布到不同 Runtime 的 **TVM FFI** 绑定，指出它比 **torch 编译更快，但仍允许 torch 绑定。
    • 一位用户表示，大多数后端使用 sm100 而不是 sm100a，因此在使用 tvm ffi 后端时，任何原始的 ptx 内容都会崩溃。
  • **FlashInfer Agent 实现 5.74 倍加速：一名成员报告，在 **MOE 赛道上使用 mlsys26-agent-baseline 与 evolve agent 实现了 5.74x 加速，使用的是 Anthropic Claude Opus 4.6，total_steps=100，pool_size=6，在 B200 上进行评估。
    • 另一名使用相同 baseline 的成员也有类似经历，远落后于 flash infer baseline。
  • 深入探讨 **Fused MoE 细节：一名成员询问了 fused **MoE 的评估指标，特别是询问是否所有 19 个工作负载都将得到同等评估。
    • 该成员还想知道最终评估中使用了哪个版本的 Triton。
  • FP8 Kernel 误差较高：在使用 Claude Opus 4.6（total_steps=100，pool_size=6，在 B200 上评估）运行 mlsys26-agent-baseline 时，一位用户注意到，虽然加速效果看起来不错，但 max_relative_error 和 max_absolute_error 似乎非常高，尽管被标记为正确。
    • 该成员询问这对于 FP8 kernels 是否是预料之中的，或者在最终评估的更严格正确性检查下是否会失败。
  • B200 上的 NCU 依然难以实现：一位用户询问在 B200 上进行实验期间使用 NCU 的情况，并指出似乎到目前为止没有人能做到。
    • 他们检查了 Modal 的 slack，似乎目前还没有人能实现，但谁也说不准。

HuggingFace ▷ #general (50 messages🔥):

西班牙 ML Engineer 建议, Qwen3.5 本地运行, 课程/学习频道合并, 计算机视觉频道, Hugging Face 生态系统热点话题

  • 西班牙 ML Engineer 寻求建议：一位来自西班牙的 24 岁 ML Engineer 寻求职业发展建议，表示更倾向于有意义、高强度的工作，而非标准的朝九晚五。
    • 一位成员建议可以找一份稳定的工作，同时兼任一份无薪职位以积累经验，并强调了在没有丰富经验的情况下进入该领域的挑战。
  • 本地运行 GGUF 格式的 Qwen3.5：用户现在可以通过此链接本地运行 Qwen3.5，并希望很快能发布更小的版本。
  • Agents 课程频道已合并：课程/学习频道已合并为一个单一频道，以便于访问和管理，链接见此处。
  • 探讨 Hugging Face 生态系统的热点话题：在讨论 HF 生态系统时，成员们认为 Transformers/Diffusers/Gradio 及其相关库始终是热点，此外在 HuggingFace GitHub 上还有许多其他库。
  • Inference Endpoints 出现服务崩溃 (Service Panic)：尽管 Hugging Face 状态页面显示运行正常，但用户报告在调用 Inference Endpoints 时遇到 Error 500 和 Service panicked 消息。
    • 一位用户通过重新创建端点并将生产流量迁移到新端点解决了该问题。

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

聊天机器人创造力研究, Pocket-TTS, Smart-KNN, Microclaw 后备 Agent, DirectShell 接口

  • 放大镜下的聊天机器人创造力：一项新研究探讨了聊天机器人是否能通过链式对话生成独特且有创意的话题，研究表明它们具备创造力，该研究已发布在 Zenodo 上。
  • Pocket-TTS 分叉版助力自定义语音：一位成员为多 worker 推理创建了自定义的 Pocket-TTS 分叉版，并用它生成了 Morgan Freeman 朗读整本 King James Version 圣经的录音，可在 Google Drive 文件中获取。
  • Smart-KNN 项目开源：一个名为 Smart-KNN 的开源项目旨在使 KNN 更适合生产环境，重点在于特征权重距离计算和自适应后端选择，以提高延迟的可预测性，代码仓库托管在 GitHub。
  • Microclaw：OpenClaw 的轻量级后备 Agent：Microclaw (v2026.2.17) 是一个轻量级的蒸馏语言模型，设计作为 OpenClaw 生态系统的后备 Agent，引入了先进的训练和推理增强功能，可在 Hugging Face 上获取。
  • DirectShell 将辅助功能层转变为通用应用接口：截至 2026 年 2 月 17 日，随着 DirectShell 的推出，全球所有基于截图的 AI Agent、企业 API 封装器和 RPA 工具都已成为过时技术。其源代码可在 GitHub 获得。

HuggingFace ▷ #agents-course (4 messages):

Agents 课程端点, HF Spaces 集成

  • Agents 课程端点挑战：一位成员询问 GET /files/{task_id} 端点在 HF Spaces 之外的功能，并指出他们收到了 404 错误。
    • 虽然 /questions 端点可以在本地运行，但他们不确定 404 错误是预料之中的，还是由于缺少配置步骤，目前正使用 GAIA 数据集作为备选。
  • 课程完成公告：一位成员宣布他们完成了 Agents 课程的 Unit 1。
    • 另一位成员表示他们也是这门课程的新手。

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

Contributing to projects, Starship Troopers, Gemini for shaders, Claude going off the rails, arXiv endorsement

  • **Gemini 表现出色，Claude 表现不佳：一位成员非常喜欢使用 **Gemini 来制作 shaders（着色器），认为其表现相当稳健；而另一位成员则报告称 Claude 生成的代码完全是胡言乱语。
    • 据称回退到版本 v2.1.41 可以解决该问题。
  • **斯坦福的 Cybench 随机化 Flag 后表现下降**：一位成员阅读了关于 Cybench 的斯坦福论文，并指出该 Benchmark 之前没有对 Flag 进行随机化，而是直接从知名的 CTF 中提取。
    • 一旦 Flag 被随机化，成功率就大幅下降。
  • **OpenClaw 尽管有局限性仍获称赞：针对一篇关于 **OpenClaw 的设计文章，一位成员观察到人们很容易被其打动，尽管对于实际的专业 AI 应用来说，它只是一个臃肿且无用的层。
    • 然而，他们承认 OpenClaw 确实拥有不错且集成的“助手”功能，并为普通用户提供了简便性。
  • **GLM 5 技术报告发布：GLM 5** 的技术报告已发布 (2602.15763)，部分成员讨论了其能力，包括一段展示 GLM 5 的 YouTube 视频。
  • **YouTube 遭遇黑屏惊魂：几位成员报告称 **YouTube 宕机了，显示巨大的黑屏。
    • 一位成员收到消息称：当 Google 自动检测到来自您的计算机网络的请求似乎违反了服务条款时，就会显示此页面。

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

RAM Requirements, GPU for Context

  • 需要高内存，至少 512GB：一位用户正在寻找一台拥有至少 512GB RAM 的机器来处理 AI 任务。
    • 他们指出，下一个常见的规格（768GB）有时是一个尴尬的跨度。
  • 3090 用于“不错的 Context”：用户指定需要至少 一块 3090（或多块）来在 AI 工作中处理不错的 Context（上下文）。
    • 该用户没有链接到任何具体信息。

Eleuther ▷ #general (25 messages🔥):

Anthropic and military use of Claude, Lucidrains' GitHub account suspension, Hostility towards AI coding, Qwen3 model evaluation discrepancies

  • **Anthropic 对 Claude 军事用途的条件披露：Anthropic** 同意将 Claude 用于军事用途，但设有条件：1) 不得用于大规模监控，2) 不得用于自主武器。
    • 一些人对 Anthropic 坚守立场表示惊讶，正如一位成员所言：没想到 Anthropic 能坚持住原则。
  • Lucidrains 的 GitHub 账号面临封禁：成员们报告称 Lucidrains 的 GitHub 账号 因某种原因被暂停，引发了社区内的担忧。
    • 关于原因的猜测不断，包括“莫名其妙（fsr）”被封，一位成员开玩笑说是因为他让其他人都相形见绌了。
  • AI 编程面临敌意：一位成员注意到对 AI 编程存在巨大的敌意，并报告称本周在提到 Codex 或 ChatGPT 后，有三个 Reddit 账号被封禁。
    • 这表明在线社区对于 AI 在编程及相关领域日益增强的能力和存在感，正产生着不断增长的紧张情绪或担忧。
  • **Qwen3 模型评估数据存议**：成员们报告称，他们使用 eval harness 进行的评估结果与官方数据存在差异。
    • 该成员询问：这些 eval 的结果或脚本是否在 repo 的某个地方？。

Eleuther ▷ #research (22 messages🔥):

Geometric Table Transformer (TV-Cache), Every Eval Ever project, CoDA-GQA-L: Bounded-Memory Attention, Mycelium AI Model Benchmarking

  • Geometric Table Transformer 将语义与几何解耦: 一名成员正在尝试一种在注意力机制中将语义兼容性与几何旋转解耦的方法，称为 Geometric Table Transformer (TV-Cache)，它用 O(1) 标量查找 + 三角调制取代了 RoPE 的高维点积，如此贴所述。
    • 其核心优势在于 注意力速度现在独立于 D，从而允许在不产生注意力头 O(D) 计算开销的情况下扩展内部维度。
  • Every Eval Ever 项目启动: EvalEval Coalition 启动了 Every Eval Ever project，旨在标准化基准测试（benchmark）评估。
    • 另一位成员指出，这让他们联想到了通过 Brain Imaging Data Structure 在认知神经科学研究中推动标准化 BIDS 的努力。
  • CoDA-GQA-L 通过 Bounded-Memory Attention 限制 KV Cache 大小: 一名成员发布了 CoDA-GQA-L，这是一种注意力机制，无论序列长度如何，都能将 KV Cache 限制在固定大小，将 KV Cache 大小从 160GB 减少到 136MB。详见此论文，代码已在 GitHub 开源。
    • 它每层使用 384 个槽位 (slots)，由 最近窗口（256 个精确 token）、精确地标库（64 个经过新颖性过滤的重要 token）和摘要库（64 个压缩旧上下文的 EMA 原型） 组成。
  • Mycelium 就 AI Model Benchmarking 论文寻求建议: Mycelium 团队计划发表一篇基于 AI 模型基准测试的论文，改编现有的基准测试（如 inspect_evals）来运行动态生成的多轮对话并评估 AI Agent。
    • 他们正在寻求关于 应投递哪些期刊或会议，以产生最具影响力的传播效果 的建议。

Eleuther ▷ #scaling-laws (1 messages):

``

  • 独立性假设得到阐明: 一名成员确认 独立性假设 (independence assumption) 是清晰传达思想的一种有用方式。
  • 直觉获得认可: 一名成员对反馈表示感谢，承认其 直觉 与所提供的解释一致，尽管该假设在技术上是不正确的。

Eleuther ▷ #interpretability-general (7 messages):

Preventative Steering, Data Augmentation, Representation Mapping, Model Behavior Control

  • 预防性控制得到泛化！: 最初在 Anthropic 的人格向量论文中描述的 预防性控制 (preventative steering) 概念可以被泛化：通过添加一个 steering vector，同时根据模型达到原始目标的能力进行评判，从而迫使模型对 steering vector 进行补偿。
    • 通过 改变目标，可以鼓励模型不仅仅是与 steering vector 对抗，特别是当特征可以被用作目标时。
  • 通过 Steering Vectors 进行数据增强！: 探索了使用 steering vectors 进行数据增强 的想法，解决了仅通过改变目标只能获得两个不同数据版本的局限性。
    • Steering vector 充当一种 扰动 (perturbation)，而目标特征是当数据中出现扰动时模型应瞄准的方向，从而允许探索在实证数据集中罕见的扰动组合。
  • 映射表示而非 I/O: 有观点认为，与其训练模型将输入映射到输出（成本高且效果差），我们可以训练它们将 表示映射到表示 (representations to representations)，从而有效地在表示空间中实现数据增强。
    • 这将允许预计算 forward pass 的第一部分，并将其与针对不同目标的多个 steering vectors 重复使用。
  • 通过内部语义控制模型行为！: 根据 这条推文，“如果 [内部语义 X] 那么执行 [内部语义 Y]” 的想法为模型行为提供了大量控制，并让我们摆脱了对数据的依赖。

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

Kimi K2 Turbo 移除, Kimi CLI bash/shell 问题, 使用 Kimi 的交互式测验生成器, Kimi-Code API 与 Openclaw 兼容性, Kimi Code vs Kimi Claw

  • Kimi K2 Turbo 消失，用户请求退款：用户报告称 Kimi K2 Turbo 已从 Kimi-Coding 的可用模型中移除，导致由于基于该模型可用性而订阅的用户感到沮丧。
    • 一位用户表达了失望，表示：“我真的觉得非常非常难过，他们宣传了一些东西……然后像我这样的用户据此订阅了一年……结果他们就把它移除了？！”。
  • 使用 Kimi 创建的交互式测验生成器：一位用户使用 Kimi 创建了一个交互式测验生成器，允许用户将视频转录文本或其他内容粘贴到 Kimi 中，将输出复制粘贴到 HTML 页面并开始回答问题，文件为 quiz.html。
    • 该生成器包括“多选题”和会话保存/恢复等功能，如附图所示。
  • Kimi CLI 面临 Bash/Shell 问题：一位用户报告称 K2.5 在 Kimi CLI 中使用 bash/shell 时存在问题，且该问题仅出现在此模型中。
    • 他们注意到其他模型没有出现该问题。
  • Kimi-Code API 现在与 Openclaw 不兼容了吗？：一些用户反映 Kimi code 停止在 Openclaw 上工作。
    • 其他人建议探索 Openrouter 上的替代选项，以决定模型和提供商。

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

Modular 收购 BentoML, Jupyter Mojo Kernel 发布, Notebook 爱好者们的喜讯

  • Modular 收购 BentoML，宣布 AMA：Modular 宣布收购 BentoML，并将与 Chris 和 Chaoyu 举行一次有问必答 (AMA) 活动。问题正在 Modular 论坛征集，并将在 YouTube 上直播。
  • Jupyter Mojo Kernel 发布！：一位成员为 Notebook 爱好者发布了 Jupyter Mojo kernel，可在 GitHub 上获取。
    • 该 Kernel 目前“相当简陋”，没有自动补全或图像支持，但速度很快，在 MacOS 和最近的 Linux 版本上运行良好，如果你尚未安装匹配的 Modular 软件包，uv 将会自动安装。

Modular (Mojo 🔥) ▷ #announcements (1 messages):

BentoML 收购, 有问必答活动, Modular 论坛, 未来愿景, 贴纸赠送

  • Modular 收购 BentoML - 今日举行 AMA！：Modular 今日将在其论坛举办关于近期收购 BentoML 的有问必答 (AMA) 活动，时间为 PT 时间上午 9:30。
    • 前 10 位在论坛帖子中分享问题的用户将获得贴纸。
  • Modular 论坛中的有问必答：<@685556913961959475> 和 <@679535512565973018> 将在 AMA 期间回答问题并分享他们对未来的愿景。
    • 活动正在 Modular 论坛举行，并附有宣传活动的图片。

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

LayoutTensor vs InlineArray, Mojo Random Number Generators, Mojo C++ Binding Status, Async on GPUs

  • stack_allocation 丢失 Origin Safety: 与 InlineArray 相比，stack_allocation 丢失了 origin safety 和 exclusivity checking，而且它不允许你利用 noalias 优化。
    • 它是由于编译器限制而产生的“权宜之计”，更好的方案即将推出。
  • GPU 上的寄存器: 仅由常量值索引的 InlineArray 或 stack_allocation 将存储在 GPU 的寄存器中，前提是未发生溢出 (spill)。
    • 编译器可能会针对寄存器使用优化平凡的 (trivial) register passable 类型。
  • Mojo 需要 Random Number Generators: 一位成员正在寻找 Mojo 中常见概率分布的 Random Number Generators 实现，特别是 Poisson 分布。
    • 另一位成员建议这个需求对 Mojo 来说很有意义。
  • GPU 上的 Async Await: 一篇关于在 GPU 上实现 Async/Await on GPUs 的博文可能对 Mojo 有启发，因为这部分正处于变动中。
    • 这也为提供一种优雅的方式来处理 cold-start futures 提供了动力，因为这种方法可能不适用于 hot-start futures。
  • Mojo 绑定到 C++ 的状态: Mojo 目前主要通过带有手动绑定的 C 支持往返的 C++ 绑定。
    • 它不像 pybind11 那样简单，尤其是你需要手动编写绑定。

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

mxfp4 support in max, NVFP4 focus, customized Mojo kernels

  • MAX 中的 MXFP4 支持滞后: MAX 中的 MXFP4 支持目前滞后，因为团队正优先关注 NVFP4，但底层 Mojo 中已经存在这些数据类型，所以没有根本性的阻塞。
    • 一旦对 NVFP4 的支持稳定，MXFP4 可能会迅速跟进，并在模型层面进行测试和调优。
  • MAX 模型现在支持自定义 Mojo Kernels: 得益于构建基础设施的增强和 graph 编译器的新功能，使用 OSS modular 仓库构建的 MAX graph 和模型现在可以使用完全自定义的 Mojo 标准库或 Mojo kernels，详见此论坛帖子。

MCP Contributors (Official) ▷ #mcp-dev-summit (1 messages):

smw355: 嗨，我想是的，但会尝试去了解一下。

MCP Contributors (Official) ▷ #general (8 messages🔥):

SEP-2007, MCP Payment Support, Micropayments for Agents, X402 protocol

  • MCP Server 寻求支持变现激励: 一位成员创建了一个 SEP，允许 MCP server 为托管的工具请求费用，从 X402 开始，旨在通过货币化加速 Agent 的采用。
    • 也有人担心支付支持是否应该内置在协议中，还是应该通过 URL 引导来处理。
  • MCP 支付不太可能近期实现: 一位成员提到，除非核心维护者深度支持，否则支付在未来几个月内不会被优先考虑，更倾向于等待成熟的支付模式出现。
    • SEP 的作者询问是否有核心维护者正在研究支付，并艾特了一位成员关注。
  • 讨论 Agent 的微支付: 一位成员解释说，该提案侧重于让 Agent 自主为工具支付的微支付 (micropayments)，这需要丰富的成本信息，以便在护栏 (guardrails) 下进行智能决策。
    • 该成员预计近期内不会出现针对 MTXns 的新支付协议。
  • 计划 MCP 扩展？: 一位成员对“不直接将支付纳入协议”表示强烈赞同，但提议初步与 SEP 作者合作开发一个“非官方扩展”。
    • 他们表示将深入审查该 SEP。

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

MCP Resource Specification, SEP-2084 Rejection, Resource Hierarchy, resource/read Ambiguity

  • 提议清理 MCP 资源规范：一位成员分享了一个 pull request，旨在清理 MCP 中资源的规范和可用性。
    • 该 PR 试图澄清 MCP 资源规范和可用性方面的一些模糊之处。
  • SEP-2084 因分组提案面临拒绝：一位成员指出，由于 CMs 目前不想接受任何分组提案，与资源分组相关的 SEP-2084 已被拒绝。
    • 该 SEP 的前身是 SEP-1300，它仅关注工具分组，但明确的反馈是，任何分组提案都需要适用于所有原语。
  • 资源层级已隐式存在：一位成员认为，资源已经以 URI path 的形式或通过在 resource/read 中返回子资源而隐含地具有层级结构。
    • 该 pull request 主要是为这些现有惯例带来更多的形式感和实用性，而非试图解决 context length 或出于 UX 目的按类别分组原语的问题。
  • resource/read 功能面临歧义：用户提出警告，当你对一个 URI 进行 resource/read 时，你不知道返回的是单个资源还是子资源的集合。
    • 这令人混淆，需要澄清和改进。

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

tinybox issues, tinygrad PR, meeting 7 agenda, Axelera AI accelerator, BarraCUDA emulator

  • **TinyBox 设置失误寻求社区帮助：一位用户报告了他们的 **TinyBox 只能识别 4 个 GPU 中的 2 个的问题，请求社区协助。
    • George Hotz 建议检查 连接线，用户确认重新插拔显卡后解决了问题。
  • 庞大的 **TinyGrad PR 引发代码质量辩论：一位用户向 **tinygrad 提交了一个无法在 50 行内完成、而是写了 150 行的 PR。
    • George Hotz 对 PR 中的 “AI slop”（AI 垃圾代码）表示担忧，敦促贡献者仔细检查每一行，询问是否真的需要。
  • **TinyGrad 第 7 次会议将深入探讨关键领域：George Hotz 公布了第 7 次会议的议程，包括公司动态、llama training loop** & flash attention、驱动程序、viz/fast gemm、CALL/PARAMS 以及汇编。
    • 议程还涵盖了编译器渲染器和图像、lazy assign setitem 和调度器，以及其他问题和悬赏。
  • 探索在 **TinyGrad 中集成 Axelera AI 加速器：社区讨论了为 **TinyGrad 支持小型加速器（如 Axelera AI Metis-M.2 card）的可能性。
    • 还有建议在小型 PCIe FPGA 板（如 Acorn CLE-215）上包含自定义 RTL。
  • **BarraCUDA 模拟器因 Bug 问题引起关注：在发现一个名为 BarraCUDA 的模拟器项目后，George Hotz 建议贡献 **TinyGrad，而不是用 C 语言编写。
    • 他指出，他们用 C 语言编写且没有 CI 简直疯了。”我对没有 Bug 表示非常怀疑。他们至少应该使用我们的模拟器。”

Yannick Kilcher ▷ #general (10 messages🔥):

研究论文中的引用错误, OpenClaw Multiagent 系统, OpenAI 的 Harness Engineering

  • **LLM 可能并非导致引用错误的原因：成员们讨论了近期论文中的引用错误是与 **LLM 有关，还是“一直就存在”，并建议审查过去的会议以检查引用的准确性。
    • 一位成员指出，如果提交给 NeurIPS 2025 的论文中包含 LLM 引用 2024 年的出版物，这应被视为一种幻觉（hallucination）。
  • **OpenClaw：潜力无限的 Multiagent 系统：OpenClaw** 是一个有趣的 Multiagent 系统，具有通用的可能性，它通过其网关接受任何类型的输入，并将时间整合为一种输入。
    • 一位成员描述了 OpenClaw 如何使用事件驱动开发：时间通过心跳（heartbeats）和 cron jobs 产生事件……人类通过消息创建事件……外部系统通过 webhooks 创建事件。
  • **LLM 驱动的 Agent 中潜伏着网络安全噩梦：能力越大责任越大，当涉及到 **LLM 驱动的 Agent 时，也会带来网络安全噩梦，例如技能中的恶意软件链和 prompt injections。
    • 一位成员分享了一个讨论 OpenClaw 的 YouTube 链接，另一位成员评论道：很多人本可以做出这个，但可能因为太危险而退缩了。
  • **Harness Engineering：一次营销推广？**：一位成员分享了 OpenAI 的 Harness Engineering 博客文章，并对其过度营销的方式表示失望。
    • 他们认为这篇文章缺乏实质内容，指出：如果他们不把整篇内容写成冗长的营销文案，本可以很有趣，并补充道：看起来无法从中推断出该方法的实际效果。

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

Claude Sonnet 4.6, Anthropic 的模型

  • Anthropic 发布 Claude Sonnet 4.6 模型：Anthropic 宣布发布 Claude Sonnet 4.6，并在一条 推文 中展示，其官方 新闻稿 中有详细介绍。
  • Claude Sonnet 4.6 细节：新模型 Claude Sonnet 4.6 拥有翻倍的 context window，并且比之前的 Claude 模型更快、更便宜。

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

账号停用, 支持频道, 积分成本, 开发者自我介绍, Manus 账号问题

  • 账号仍被停用？：一位用户正在寻求关于 Manus 账号被停用 的帮助，并发现很难在 general 频道获得支持。
    • 另一位用户建议尝试前往 support 频道 以获得更好的帮助，因为 general 频道可能不是处理此问题的最佳场所。
  • 巴格达少年现已通过验证：一位来自伊拉克巴格达的 13 岁开发者宣布他们已通过验证，并鼓励其他人用 Manus 构建一些疯狂的东西。
    • 验证通过后，他们询问：“还有谁在这里写代码？”，表达了兴奋与鼓励。
  • 开发者自我介绍：几位开发者介绍了自己和技能，其中一位强调了在 Blockchain 和 AI Agents 方面的经验。
    • 另一位开发者自荐为拥有 web 应用程序、API 集成和数据流水线（data pipelines） 经验的 full-stack 开发者，表达了对构建现实世界产品和协作开发重大项目的热情。
  • 演示文稿错误令用户感到沮丧：一位用户在使用 Manus 账号 时遇到问题，并感到非常沮丧，因为一份花费数周构建的演示文稿充满了错误。
    • 用户在历史记录中能看到该演示文稿但无法恢复，并表示因为正处于“临门一脚”的阶段而感到巨大的压力。
  • 订阅除非取消否则自动续订：一位用户被建议取消订阅以避免被扣费。
    • 另一位用户表示：“请通过私信（DM）将您的注册邮箱发送给我”。

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

archelunch: 现在已经发布到 GitHub 了 https://github.com/Archelunch/dspy-repl

DSPy ▷ #general (3 messages):

Semantic Search in Discord, GEPA with offline data

  • Discord 需要语义搜索：成员们正在讨论 Discord 内部缺乏 semantic search（语义搜索）能力。
    • 一位用户指出 Discord 确实需要语义搜索…
  • 寻求 GEPA 离线数据文档：一名成员请求关于在离线数据中使用 GEPA 的文档。
    • 该用户链接了一个 Discord 频道 discord.gg/2Jqsg96mZz，推测是为了进一步讨论或获取相关信息。

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

Project Ideas, Active Projects, Technical Support, Developer Support

  • 社区寻求项目协作：一名成员通过寻求项目想法并询问社区内的活跃项目发起了讨论，展示了协作精神。
    • 此外，该成员还向需要项目帮助的社区成员提供了 technical support（技术支持）和 developer assistance（开发者协助）。
  • 为项目提供支持：一名成员自愿为社区其他成员提供技术和开发者支持。
    • 这一提议旨在促进协作，并协助社区内正在进行或新项目的开发。

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

/commit staging, Aider PR #2763

  • 请求限制 /commit 仅针对已暂存的更改：一位用户询问是否有办法让 /commit 命令只考虑已暂存（staged）的更改，因为目前的行为需要先 stash 掉不需要的更改。
    • 他们在 GitHub 上发现了可以解决此问题的 PR #2763，但该 PR 已开放超过一年。
  • Aider PR #2763 解决暂存更改问题：PR #2763 已开放一年多。
    • 它将解决 /commit 命令仅考虑已暂存更改的问题。

Windsurf ▷ #announcements (2 messages):

GLM-5, Minimax M2.5, Sonnet 4.6

  • GLM-5 和 Minimax M2.5 登陆 Windsurf！：根据这条推文，GLM-5 和 Minimax M2.5 现已在 Windsurf 上线。
  • Sonnet 4.6 带着促销价格降临！：正如这篇帖子所宣布，Sonnet 4.6 已在 Windsurf 实时上线，促销价从 2 倍积分起。

MLOps @Chipro ▷ #general-ml (1 messages):

AI Failures, AI Foundations, Organizational Confidence, Metadata Weekly

  • AI 计划因基础缺陷而失败：根据 OpenTable 的 Gaurav Ramesh 的说法，大多数 AI 计划失败 不是因为模型就绪度问题，而是因为我们的基础架构并非为我们要求它们执行的任务而构建。
    • 领导者希望强大的模型能够绕过混乱的数据和脆弱的系统，但这种赌注并没有得到回报。
  • 停滞的 AI 试点是学习成本：停滞的 AI pilots（AI 试点）应被视为学习成本，它暴露了约束条件并明确了必要的变革。
    • 缺失的基础不是数据质量或治理，而是自我意识（self-awareness）。
  • 组织信心驱动 AI 成功：预算不是 AI 成功 的关键；组织信心（organizational confidence）才是真正重要的。
    • AI 测试的是我们对自己工作流程的理解程度，而不仅仅是基础设施。
  • Metadata Weekly 专题报道 AI 见解：Gaurav 关于 AI 基础中人为因素的完整文章见于 Metadata Weekly。
    • 文章讨论了理解我们自己的工作流程对于成功实施 AI 的重要性。
← 返回首页