AI News

今天没发生什么特别的事。

· MjAyNi0w

Anthropic 发布了 Claude Opus/Sonnet 4.6，显示出智能指数的显著提升，但同时也带来了 Token 使用量和成本的增加。Anthropic 还分享了关于 AI 智能体（Agent）自主性的见解，强调了“人机回环”（human-in-the-loop）的普及以及软件工程工具的调用。

阿里巴巴推出了 Qwen 3.5，并引发了关于推理效率和 Token 膨胀的讨论，同时开源了 Qwen3.5-397B-A17B 的 FP8 权重。GLM-5 技术报告介绍了异步智能体强化学习和计算高效技术。

有关 Gemini 3.1 Pro 的传闻暗示其具备更强大的推理能力，而 MiniMax M2.5 也出现在了社区排行榜上。目前，社区正针对基准测试的可信度以及模型性能的细微差别展开讨论。

#benchmarking #token-efficiency #ai-agent-autonomy #reinforcement-learning #asynchronous-learning #model-performance #open-weights #reasoning #software-engineering #agentic-engineering claude-4.6 claude-opus-4.6 claude-sonnet-4.6 qwen-3.5 qwen3.5-397b-a17b glm-5 gemini-3.1-pro minimax-m2.5 anthropic alibaba scaling01 arena artificial-analysis

平静的一天

AI News (2026/02/17-2026/02/18)。我们为你检查了 12 个 subreddits、544 个 Twitters 和 24 个 Discords（262 个频道，10849 条消息）。预计节省阅读时间（按 200wpm 计算）：1103 分钟。AINews 网站 允许你搜索所有往期内容。友情提示：AINews 现在是 Latent Space 的一个板块。你可以选择开启/退订邮件通知频率！

AI Twitter 回顾

前沿模型 + 基准测试更迭 (Claude 4.6, Qwen3.5, GLM‑5, Gemini 3.1 Pro, MiniMax M2.5)

  • Anthropic Claude Opus/Sonnet 4.6：巨大飞跃，高昂 Token 账单：Artificial Analysis 报告称，Sonnet 4.6 在其智能指数（Intelligence Index）中得分为 51（高于 Sonnet 4.5 推理版的 43），仅次于 Opus 4.6 的 53，但 Token 效率明显较低：运行该测试套件需要 约 74M 输出 Token，而 Sonnet 4.5 约为 25M，Opus 4.6 约为 58M（在最高强度下为 Sonnet 4.6 运行该指数需要花费 2,088 美元）(AA 摘要，Token 说明)。社区情绪反映出“4.6 在批判/架构方面感觉更好”(eshear)，同时也指出围绕 Claude Code 的可靠性/产品问题（参见围绕 SDK/文档和工具稳定性的“Anthropic 争议”讨论）(theo)。
  • Search Arena 中的 Claude + 自主性遥测：Arena 将 Opus/Sonnet 4.6 添加到了其搜索模式排行榜中 (arena)。Anthropic 还发布了“在实践中衡量 AI Agent 的自主性”，分析了数百万次工具调用交互：约 73% 的工具调用显示为人在回路（human-in-the-loop），仅 0.8% 显示为不可逆，且其 API 上的工具调用中 软件工程 占比约 50%——这被界定为“自主性是由模型 + 用户 + 产品共同构建的”，从而推动了部署后监控的需求 (Anthropic, 指标, 行业分布)。
  • Qwen 3.5：推理效率与“过度思考”：多篇帖子强调了 Qwen 3.5 的“过度思考”/Token 使用量是一个核心维度——既有抱怨者 (QuixiAI)，也有更深入的社区分析声称 Qwen 3.5-Plus 相比旧款 Qwen 推理变体减少了长链 Token 膨胀，同时也指出了在非推理模式下的性能退化 (ZhihuFrontier)。在分发方面，Qwen 3.5-Plus 已上线 Vercel AI Gateway (Alibaba_Qwen)，且阿里云推出了 Qwen Coding Plan 订阅服务，提供固定的月度定价和高请求上限，目标直指编程 Agent (Alibaba_Qwen)。
  • Qwen 3.5-397B-A17B FP8 权重开放：阿里巴巴发布了 Qwen 3.5-397B-A17B 的 FP8 权重，SGLang 支持已合并，且 vLLM PR 正在处理中（vLLM 支持将在“未来几天内”完成）——这是“开源权重 + 立即的生态系统适配”成为具有竞争力的 OSS 发布基本门槛的一个具体案例 (Alibaba_Qwen)。
  • GLM-5 技术报告 + “Agent 化工程” RL 基础设施：GLM-5 技术报告被直接引用 (scaling01)，并被总结为从“凭感觉编程（vibe-coding）”推向“Agent 化工程（agentic engineering）”，其特点是异步 Agent RL，实现了生成与训练的解耦，并引入了 DSA 以在保留长上下文性能的同时减少计算量 (omarsar0)。从业者称该报告极其详尽，对 OSS 复现非常有价值，并指出了优化器/状态处理以及 Agent 化数据整理的细节（终端环境、幻灯片生成等）(Grad62304977)。
  • Gemini 3.1 Pro 传闻 + “思考更久”：早期测试轶闻表明，Gemini 3.1 Pro 的“思考”轨迹明显比 Gemini 3 Pro 更长，并可能缩小与 Opus/GPT 的差距——但也伴随着对基准测试可信度的怀疑，以及在对抗性案例中的失败（例如，错误处理了包含答案的 ARC-AGI-2 提示词）(scaling01, ARC 轶闻)。
  • MiniMax M2.5 登上社区排行榜：Yupp/OpenRouter 的帖子显示已引入 MiniMax M2.5 和 M2.5 Lightning，并正在通过 Prompt 投票排行榜跟踪结果 (yupp_ai, OpenRouter 基准测试标签页)。

Agentic coding + 评测工程 (Claude Code, Cursor, LangSmith, Deep Agents, SWE-bench 流程)

  • Harness 即性能：一个清晰的对比显示，相同的模型 (Claude Opus 4.6) 在不同的 Agent Harness 下表现迥异：使用 LangChain Deep Agents CLI 完成任务耗时 9s，而 Claude Code 则需 16s——在“模型零变化”的情况下产生了 1.7× 的差异，这进一步证明了编排 (orchestration)、工具策略和上下文策略在用户感知的模型能力中占据主导地位 (GitMaxd)。另一篇相关帖子指出，Claude Code 的 Prompt 似乎在“违背权重 (fight the weights)”以获取并行工具调用，暗示了模型先验 (model priors) 与 Harness 需求之间存在架构摩擦 (dbreunig)。
  • Cursor 加倍投入 “Agent 记忆” UX：Cursor 发布了对 .agents/skills 的支持 (leerob)，随后又增加了将历史对话作为上下文的功能——这是迈向 IDE Agent 持久化、可被工具调用的记忆能力的务实一步 (cursor_ai)。
  • LangSmith Agent Builder 升级：LangChain 发布了一个可以访问所有工作区工具的“通用 Agent”聊天功能，支持 chat→agent 转换、文件上传以及中心化工具注册表——明确旨在减少实验与可部署 Agent 之间的摩擦 (LangChain)。他们还增加了 Baseline Experiments，以在评估驱动的工作流中锚定回归追踪 (LangChain)。
  • SWE-bench 基础设施迭代：SWE-bench 排行榜已迁移至使用 mini-SWE-agent v2 运行所有测试，以“榨取基础模型的更多潜力”，这隐性地改变了模型进展的解读方式（Harness 的升级推高了性能前沿）(OfirPress)。与此同时，出现了关于“SWE-fficiency 排名已失效”的批评，反映了人们对 Agent 编程基准测试评估方法论的持续疑虑 (scaling01)。
  • Windows Agent Shell 的实用安全陷阱：如果你的 “bash 工具” 是 Git Bash/MSYS2，切勿发出类似 2>nul 的 Windows 重定向指令；这可能会在 NTFS 上创建一个无法删除的 nul 文件。请使用 Unix 风格的重定向，或明确地将 Windows 命令包裹在 cmd /c 中 (MParakhin)。

OpenAI + 智能合约安全作为“Agent 能力”切片 (EVMbench)

  • EVMbench 发布：OpenAI 推出了 EVMbench，旨在测试 Agent 检测、利用和修复高危智能合约漏洞的能力 (OpenAI)。回复和转发中透露的潜台词是，Agentic Security 正在成为一级评估类别，而不再是事后补齐的任务；工程师们立即开始比较模型家族以及精确率/召回率的权衡 (gdb, scaling01 commentary)。
  • 给工程师的信号：这是将评估与真实漏洞利用/修复工作流（而非仅仅是静态 QA）挂钩的最清晰示例之一。如果你正在构建 Agent 代码审查、链上监控或自动化事件响应，EVMbench 风格的任务比许多通用的编程排行榜更接近生产环境。

数据、策展与评估卫生 (ÜberWeb 多语言、Prompt 重复、“slop 污染”)

  • ÜberWeb：在不牺牲英文性能的情况下提升多语言能力：DatologyAI 的 “ÜberWeb” 声称通过数据质量/构成，在 20T+ tokens 的规模上改变了多语言模型的算力-性能帕累托前沿（Pareto frontier）——反驳了将“多语言魔咒”（curse of multilinguality）主要视为数据质量问题的说法 (RicardoMonti9, pratyushmaini, agcrnz)。
  • Prompt 重复争议：有爆料称将同一个 Prompt 重复两次可获得巨大的准确率提升（例如在姓名查找任务中从 21% 提升至 97%），这引发了方法论上的质疑：当问题被置于首位时，提升可能会消失，且由于未包含“问题优先”的基准测试（baselines），报告的结果可能被夸大 (kimmonismus claim, paul_cal critique)。
  • 数据集污染不再是假设：一个广泛流传的轶事：一个存续了数十年的错误“前 500 个素数”网页可能会在 2026 年之前“污染生成式 AI 模型”——这突显了以网络数据训练的事实先验（factual priors）的脆弱性，以及对具备来源感知能力的检索和验证层的需求 (skominers)。
  • AI 垃圾内容（Slop）检测 + 来源归属：相关帖子警告了虚假的机器人媒体内容（例如不存在的宇树科技 Unitree 型号/手部），并强调要检查来源可信度和物理可行性 (teortaxesTex)。在缓解措施方面，Google 在 Gemini 中推出了针对音频的 SynthID 水印验证，将来源工具的范围从图像/视频扩展到了音频 (GeminiApp, Google)。

多模态 + 创意模型发布（Lyria 3 音乐、长上下文 VLM、视频编辑）

  • Google/DeepMind Lyria 3：音乐生成功能集成至 Gemini：Lyria 3 可根据文本、图像或视频 Prompt 生成 30 秒音轨，支持歌词/人声，并正在 Gemini 中广泛推广；输出内容带有 SynthID 水印，Gemini 可通过 SynthID 检查来验证音频来源 (GeminiApp launch, DeepMind, Google, philschmid summary)。Prompt 技巧强调了结构化规范（流派/情绪/乐器/人声/歌词）以提高可控性 (GeminiApp tips)。
  • 用于 Agent 级文档搜索的 OriOn 长上下文 VLM：LightOn 推出了 OriOn，这是一款长上下文 VLM，定位用于文档的 Agent 级搜索/推理（单次处理支持高达 “250 页全视觉分辨率内容”），并发布了训练配方和校正后的基准测试集 MMLBD‑C (LightOnIO)。
  • 视频生成/编辑论文持续涌现：多篇 arXiv 论文备受关注（例如：用于世界一致性生成的空间记忆检索；用于实时编辑的解耦控制），这些主要通过论文聚合推文发布 (AnchorWeave, EditCtrl)。工程层面的信号：检索 + 结构化记忆正成为时间一致性（temporal consistency）中的常见主题。

值得借鉴的系统 + 基础设施笔记（Moondream SIMD 解码、STT 基准测试、MCP 工具、向量数据库）

  • Moondream 遭遇“解码瓶颈”，发布 SIMD 图像解码库：Moondream 的推理速度已经快到让 图像解码 成为瓶颈，因此他们发布了一个比常用 Python 方案更快的 SIMD 图像解码库，并采用 静态链接（statically linked） 以简化安装；文中还提到了快速的 Lanczos3 缩放（性能仍次于 pyvips）(vikhyatk, 缩放笔记)。
  • AA-WER v2.0：STT 基准测试对“Ground Truth”更加严谨：Artificial Analysis 发布了 AA-WER v2.0，以及一个预留的私有数据集 AA-AgentTalk（针对语音 Agent 的语音数据），并提供了经过清洗和改进归一化处理的 VoxPopuli/Earnings22 版本；报告的领先者包括 ElevenLabs Scribe v2（AA-WER v2.0 为 2.3%）和 Gemini 3 Pro（2.9%）(ArtificialAnlys)。
  • FastMCP 3.0：FastMCP 3.0 增加了逐会话上下文/渐进式披露、更完善的 CLI、版本控制/认证、OTEL 等功能——这是围绕 MCP 风格集成构建的更广泛“工具服务器”生态系统强化的一部分 (jlowin)。
  • RAG 技术栈演进（以 Qdrant 为例）：Qdrant 提倡从静态 Embedding 转向更动态的架构，结合持久化语义记忆 + 实时网络检索 + Agent 推理——这更多是营销而非创新研究，但与生产环境 RAG 的发展方向一致 (qdrant_engine)。

热门推文（按互动量排序，已过滤至技术/AI 相关）

  • Google Gemini / Lyria 3 音乐生成发布：集成了带有 SynthID 水印的音乐生成功能 (GeminiApp, Google, GoogleDeepMind)。
  • OpenAI EVMbench（Agent 智能合约安全基准测试） (OpenAI)。
  • Anthropic：在实践中衡量 Agent 的自主性（数百万次交互） (AnthropicAI)。
  • ZyphraAI ZUNA：开源 EEG 基础模型（3.8 亿参数，Apache 2.0） (ZyphraAI)。
  • 具有现实影响的数据污染 / 模型脆弱性梗：错误的素数网站正在“污染”模型 (skominers)。
  • Moondream SIMD 图像解码库（真实的性能工程） (vikhyatk)。

AI Reddit 回顾

/r/LocalLlama + /r/localLLM 回顾

1. 创新 AI 应用与实验

  • 我把一个 30 美元的无线电插进 Mac mini 并告诉 AI “连接到这个” —— 现在我可以控制智能家居并在零网络环境下通过无线电发送语音消息 (热度: 355): 该帖子描述了一个使用两个运行 **Meshtastic 固件 的 Lilygo T-Echo 无线电 (LoRa 433MHz) 的方案，在没有互联网的情况下维持智能家居控制和通信，这在乌克兰停电期间特别有用。该系统与运行 OpenClaw AI 的 Mac mini 集成，AI 会自动配置无线电、安装必要的软件并创建一个 Python 监听守护进程。该守护进程负责管理消息路由，使用 phi4-mini 进行意图分类，使用 gemma3:12b 生成回复，并与 Home Assistant 接口进行智能家居控制。该方案允许通过无线电发送语音消息，并通过 TTS 在扬声器上播放，全程无需互联网。** 一条评论强调了 OpenClaw 的安全性问题，指出其潜在的漏洞以及高权限运行的风险，这可能会被对抗性网络利用。

    • Vusiwe 警告使用 OpenClaw 相关的安全风险，这是一款可能存在严重安全漏洞的软件。它通常需要高级别权限，如果被利用，系统很容易受到对抗性网络的攻击。对于拥有强大硬件的用户来说，这尤其令人担忧，因为硬件可能会被用于未经授权的任务。
    • Hefty_Development813 询问了该方案的运行范围，并指出这需要附近有其他运行 Meshtastic 的用户。这表明系统依赖于 Mesh 网络进行通信，其有效性可能会受到用户密度和距离的限制。
    • skinnyjoints 对方案中使用的无线电频率可能被未经授权访问表示担忧。他们询问了所采用的加密方法，质疑是否涉及只有预定的发送者和接收者才能访问的特定频率，强调了安全通信频道的重要性。

  • [那个赢得了 NVIDIA 黑客松和一台 NVIDIA DGX Spark GB10 的人，又用它赢得了另一场黑客松！ (Activity: 419): 该帖子描述了一个利用两台 NVIDIA DGX Spark GB10 系统和一台 Dell Pro Max T2 Tower 开发用于个性化语言学习的自动化语音识别（ASR）应用的项目。该系统使用 256 GB LPDDR5x 内存，并集成了 CrisperWhisper、faster-whisper 和一个自定义 Transformer，用于精确的转录和音素级发音评估。它采用 Montreal Forced Aligner 和启发式检测算法来筛选语流不畅（disfluencies），并使用 SEP-28k 等数据集进行口吃分析。该应用能实时调整学习内容，提供个性化反馈和练习，旨在支持那些在传统方法中挣扎的学习者。更多细节可以在 Medium 文章 中找到。 一位评论者询问了所使用的自定义 Transformer 的细节，表现出对技术实现的兴趣。另一条评论强调了类似系统面临的一个挑战：儿童不愿与计算机互动，这暗示了在用户参与度方面的一个潜在改进领域。

    • MobyTheMadCow 讨论了将间隔复习（spaced repetition）集成到语言学习系统中的潜力，强调了创建高效卡牌包（decks）的复杂性。他们强调了构建引入单个未知概念（n+1 学习）的句子的重要性，以及将单词视为词元（lemmas）和形态特征组合的挑战。他们建议通过在组件层面评估可提取性（retrievability）、稳定性和难度来优化复习排程，这可以根据用户的学习历史提高排程的准确性。

    • MobyTheMadCow 还引用了关于计算复合卡片在间隔复习中可提取性的研究，认为复合卡片的可提取性是其各概念可提取性的乘积。这种方法可以通过考虑用户对相关组件（如形态特征）的掌握情况并相应调整复习时间表，来增强复习间隔的排程。他们提议加入启发式方法和音素识别，以滑动标尺而非二元的通过/失败系统来评估复习的准确性。

    • [我给了 12 个 LLM 2,000 美元和一辆餐车。只有 4 个幸存下来。 (Activity: 1191): 该帖子描述了一个商业模拟，其中 12 个语言模型（LLM）被给予 2,000 美元和一辆餐车，在 30 天内进行管理。模拟涉及选址、菜单、定价、员工和库存的决策。值得注意的是，Opus 4.6** 达到了 $49K 的最高净值，而 GPT-5.2 达到了 $28K。八个模型破产了，特别是那些选择贷款的模型。该模拟还提供了一个可玩模式，供用户在排行榜上竞争。一个重要的发现是 Gemini 3 Flash Thinking 总是陷入无限决策循环。该模拟突显了各种 LLM 在受控商业环境中的策略差异和决策能力。** 一位评论者建议在 y 轴上使用对数刻度（logarithmic scale）以更好地可视化数据，特别是考虑到破产会终止模拟。另一位指出 GLM 5 是最聪明的，因为它没有开始业务，暗示这是一种规避风险的策略性决策。

      • HeadlessNicholas 建议在基准测试图表的 y 轴上使用对数刻度，以便更好地可视化数据，特别是考虑到达到 $0 会结束基准测试。这将有助于更清楚地理解模型之间的性能差异。
      • DinoAmino 引用了 ‘Vending-Bench’ 基准测试，指出 Opus 模型表现异常出色，表明它明显领先于其他模型。这暗示 Opus 已经针对此类任务进行了优化或 “benchmaxxed”，显示出卓越的性能指标。
      • Single_Ring4886 建议测试最新的 Qwen 397b 模型，推测它在基准测试中可能也会表现良好。这表明 Qwen 397b 可能具有竞争能力，使其能够在餐车业务挑战中幸存下来。

2. 新模型发布与技术报告

  • GLM-5 技术报告 (活跃度: 253): GLM-5 技术报告重点介绍了 GLM-5 模型开发过程中的几项关键创新，该模型在开源模型中实现了领先（SOTA）性能，尤其是在软件工程任务方面。报告详细说明了采用 Dynamic Sparse Attention (DSA) 以在保持长上下文保真度的同时降低训练和推理成本，并使用异步强化学习 (RL) 基础设施来提高后训练效率。此外，该模型采用了 Agent RL 算法来增强从复杂交互中学习的能力。提供的图片是一张说明 GLM-5 训练过程的图表，展示了从基础模型训练到后训练阶段的过渡，强调了 on-policy 跨阶段蒸馏。查看图片。 评论者讨论了使用 INT4 量化感知训练（QAT）来提高低精度下的准确性，以及实施混合精度 W4A8 量化策略以将 750B 参数模型部署在单台机器上。他们还注意到模型扩展到了 256 个专家（experts）并减少了层数，反映了大模型向浅层化发展的趋势。报告对特定 RL 和推理优化的关注受到关注，人们对三目标奖励模型和跨阶段蒸馏表现出浓厚兴趣。

    • GLM-5 模型在 SFT 阶段采用了 INT4 量化感知训练 (QAT) 以增强低精度下的准确性。开发了自定义量化内核以确保训练和推理之间的位级一致性行为，从而减少训练时间开销。此外，实施了混合精度 W4A8 量化策略，利用 msModelSlim 7 等工具以及用于离群值抑制的 QuaRot 和用于缩放校准的 Flex_AWQ_SSZ 等算法，将 750B 参数模型部署到单台 Atlas 800T A3 机器上。
    • GLM-5 模型扩展至 7440 亿参数，并利用了 28.5 万亿 token 的训练预算。它拥有 256 个专家，并将层数减少到 80 层，反映了大模型变浅而小模型变深的趋势。报告还强调了使用过滤流水线来避免合成或 AI 生成的数据，尽管未提供所用分类器的具体细节。三目标奖励模型和跨阶段蒸馏被认为是报告中特别有趣的方面。
    • 报告详细介绍了 GLM-5 模型的特定优化，包括对强化学习 (RL) 环境和推理优化的关注。三目标奖励模型和跨阶段蒸馏被视为重大创新。然而，报告的大部分内容是针对其特定设置定制的，这可能会限制更广泛的适用性。

  • 阿里巴巴新款 Qwen3.5-397B-A17B 在 Artificial Analysis 智能指数中位列开源权重模型第 3 名 (活跃度: 311): 阿里巴巴的新模型 **Qwen3.5-397B-A17B 被评为 Artificial Analysis 智能指数中排名第 3 的开源权重模型。该模型因其架构而备受关注，其中包括 3970 亿 总参数，但仅有 170 亿 激活参数，展示了在效率方面的重大进步。这种设计利用了 Mixture of Experts (MoE) 架构，在保持与更大模型相比具有竞争力的性能的同时，降低了推理成本。** 评论者对 Qwen 3.5 模型的效率印象深刻，注意到它在使用更少激活参数的情况下表现与更大模型相当。此外，还有关于图表中缺失 Step 3.5 Flash 等其他模型的讨论，表明了对更广泛对比的兴趣。

    • No_Advertising2536 强调了 Qwen 3.5 模型的效率，该模型拥有 3970 亿总参数，但在任何时候仅激活 170 亿参数。这种设计在保持与更大模型相当的性能的同时，显著降低了推理成本，展示了阿里巴巴对 Mixture of Experts (MoE) 架构的先进应用。
    • Expensive-Paint-9490 提到他们有兴趣测试 Qwen-3.5，因为它兼具速度和智能，尽管目前使用的 GLM-5 对他们的需求非常有效。这表明 Qwen-3.5 的性能可能为寻求高效 AI 解决方案的用户提供一个极具吸引力的替代方案。
    • PhotographerUSA 认为基准测试不如实际编程能力重要，并指出 Qwen 和 Claude 是处理编程任务的最佳模型之一。这意味着实际应用表现，特别是在编程方面，是衡量模型效用的关键指标。

非技术类 AI Subreddit 摘要

/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 发布了！！ (热度: 1651): 该图片宣布了 **Claude Sonnet 4.6 的发布，强调它是迄今为止最先进的 Sonnet 模型。关键改进包括在 coding、computer use、long-context reasoning、agent planning、knowledge work 和 design 方面能力的增强。值得注意的是，它在 beta 测试中提供了 1 million token context window，这显著扩展了其处理和理解大量文本的能力。这次发布使 Sonnet 4.6 在 AI 领域具有极强的竞争力，在某些领域可能超越了 Grok 等模型。** 一条评论幽默地表示 Sonnet 4.6 已经超越了 Grok，并创造了“claudemogged”一词。另一条评论提供了 Sonnet 4.6 推理能力的示例，展示了它在是否步行或短途驾车方面的实际建议，体现了其对日常场景的理解。

    • Sonnet 4.6 的发布引发了关于其实际应用的讨论，一位用户分享了一个场景：模型建议是否步行或短途驾车。该模型的推理包括对时间效率、燃油节省和健康益处的考虑，展示了其提供相关情境建议的能力。这个例子说明了该模型在提供实际、日常决策支持方面的潜力。

  • Anthropic 发布 Claude Sonnet 4.6 模型 (热度: 475): **Anthropic 发布了 Claude Sonnet 4.6 模型，该模型在处理 agentic 和 tool-heavy 任务方面有显著改进，缩小了与 Opus 模型的性能差距。该模型支持高达 1M tokens，表明其在处理大型数据集方面有显著增强。更多详情请参阅 官方公告。** 评论者强调，虽然原始 benchmark 的提升值得关注，但模型执行复杂任务的能力更为重要。同时，人们也在期待 Haiku 模型的更新，表明社区对更广泛模型增强的兴趣。

    • Claude Sonnet 4.6 模型在性能上表现出持续的改进，特别是在 agentic 和 tool-heavy 任务中，它正在缩小与 Opus 模型的差距。这表明其重点在于增强特定任务的能力，而不仅仅是原始的 benchmark 分数。
    • 提到了模型在 VendingBench 上的表现，不过人们正期待 Anthropic 发布详细的 model card。预计该文档将提供有关模型具体优势及其采用的独特策略（例如任务完成方法和与供应商的交互）的见解。
    • ARC-AGI 1 和 2 benchmark 显示，虽然 Claude Sonnet 4.6 有所改进，但在相同成本下 Opus 模型仍然提供更好的性能。这表明虽然 Sonnet 在进步，但 Opus 在成本效益方面仍保持竞争优势。

  • 这就是 Claude Sonnet 4.6：迄今为止我们最强大的 Sonnet 模型。 (热度: 1639): **Claude Sonnet 4.6 代表了 AI 能力的重大升级，特别是在 coding、computer use、long-context reasoning 和 agent planning 等领域。它在 beta 版中引入了 1M token context window，增强了处理海量数据输入的能力。该模型在各种基准测试中表现出改进，接近 Opus-level intelligence，但价格更具优势，使其适用于更广泛的应用。值得注意的是，它在复杂的 computer tasks（如操作电子表格和完成多步骤网页表单）中表现出人类水平的熟练度。该模型现已在所有计划中可用，包括 Cowork、Claude Code 和主要云平台，免费层级也已升级到 Sonnet 4.6。了解更多。** 评论者对创意写作的影响以及 1M context 功能在不同平台（包括 API 和网站）上的可用性表示好奇。在推广过程中，对于从旧模型的过渡也存在一些困惑。

  • FriendlyTask4587 询问了 Sonnet 4.6 模型的 context length，质疑 1 million token context 是否像 Opus 模型一样在 API 和网站上均可使用。这突显了对该模型能力和部署选项的技术兴趣。
  • nanolucas 提出了一个关于区分 Sonnet 和 Opus 模型的背景技术问题，特别是询问成本是否是选择 Sonnet 而非 Opus 的唯一因素，或者是否存在 Sonnet 表现优于 Opus 的特定使用场景。这表明需要明确每个模型的 performance metrics（性能指标）和应用场景。

  • Stupefied_Gaming 注意到了 Sonnet 4.6 发布过程中的异常行为，该模型最初被标记为 legacy 模型。这表明部署过程中可能存在问题或困惑，对于监控模型更新和 versioning（版本控制）的开发者来说，这具有参考价值。

  • Claude Sonnet 4.6 刚刚发布，基准测试表现令人印象深刻 (Activity: 1062): Claude Sonnet 4.6 已经发布，展示了 AI 能力的重大进步，特别是以更低的成本实现了接近 Opus 级别的智能。主要特性包括人类水平的 computer use（例如操作电子表格和多步表单），以及通过 1M token context window 增强的长上下文推理能力。该模型在复杂的自动化工作流、多步推理任务和知识密集型应用中表现出强劲性能，目前已在包括 API、Claude Code 和 Cowork 在内的所有平台上作为默认 free tier 模型提供。一个显著的辩论集中在性价比上，一些用户指出 Opus 4.6 与 GPT-5.2 之间的性能差异很小，但后者明显更便宜。此外，还有关于 1M context length 特性的实际可用性的讨论，部分用户表示难以访问该功能。

  • cowwoc 强调了 AI 模型市场的一个关键问题：Opus 4.6 与 GPT-5.2 之间的性能差距极小，但 GPT-5.2 的性价比显著更高，价格便宜 10 倍。这种成本性能不平衡可能会导致用户偏好的转变，除非 Anthropic 调整其定价或性能策略以保持竞争力。
  • SatoshiNotMe 指出了 beta 版中承诺的 ‘1M context length’ 特性反复出现的问题，该功能似乎对用户始终不可用。这表明在推出此功能时可能存在延迟或技术挑战，可能会影响用户满意度以及对平台开发承诺的信任。
  • joyfulsparrow 比较了 Codex 和 Claude 之间的 token 使用效率，指出 Codex 似乎提供了更慷慨的 token 限制，允许更长时间的使用而不会耗尽。相比之下，Claude 的 token 消耗很快，尤其是在 20 美元的计划上，这引发了关于 Claude 与其竞争对手相比价值主张的质疑。

2. 宇树机器人与功夫机器人

  • Unitree 进入第二阶段 (Activity: 1741): Unitree Robotics（宇树科技）宣布执行 Phase 2，涉及其机器人系统的进步。重点在于提高机器人的效率和能力，可能包括新的运动算法或硬件增强。提到 ‘front flip’（前空翻）表明其关注动态运动能力，可能标志着机器人敏捷性的新里程碑。视频中重复的场景可能意味着演示机器人性能的一致性或可靠性。一条评论幽默地建议机器人的运动进化错过了将 ‘front flip’ 作为一种高效移动方式的机会，暗示了关于机器人最佳运动策略的辩论。另一条评论开玩笑地询问机器人是否变成了人类，突显了机器人令人印象深刻的类人能力。

  • Unitree 展示了其 “Kung Fu Bot” 模型的 Cluster Cooperative Rapid Scheduling 系统 (热度: 713): Unitree Robotics 发布了他们的 “Kung Fu Bot” 模型，该模型利用 Cluster Cooperative Rapid Scheduling System（集群协作快速调度系统）来增强多个机器人之间的协调与效率。该系统在一次新年活动中进行了演示，展示了机器人执行同步任务的能力。这项技术突出了 robotic AI models and algorithms 的进步，强调了在 robotic coordination and scheduling 能力方面的快速提升。Unitree 的演示说明了这些机器人在未来十年内应用于包括老人看护在内的各种场景的潜力。评论者对 Unitree 机器人技术的飞速进步感到印象深刻，并指出其在未来十年内可能对社会产生重大影响，例如在老人看护领域。

    • 一旦人形机器人遍布街头，我们可能会忘记这些画面。Unitree 在晚会前的训练 (热度: 1080): Unitree Robotics 展示了其机器人在晚会活动前的训练过程，突显了其人形机器人的先进能力。演示包括了同步动作和复杂操纵，表明机器人技术取得了显著进展。这与最近的 Boston Dynamics 视频形成对比，后者侧重于单个机器人的特技动作（如空翻），表明了两家公司在展示机器人进步方面采取了不同的策略。评论者注意到 Unitree 和 Boston Dynamics 方法之间的鲜明对比，一些人认为 Unitree 的展示表明他们在开发方面已经“处于领先地位（simply BEYOND）”。此外，还有关于大规模部署此类机器人对社会潜在影响的推测性讨论。

      • spaceuniversal 强调了 Boston Dynamics 与中国机器人技术之间的对比，指出虽然 Boston Dynamics 在短视频中展示了空翻，但中国方面呈现了一个更为详尽的 4 分钟机器人晚会。这表明机器人能力的规模和呈现方式存在显著差异，暗示中国机器人技术可能正以更快的速度前进，或者至少在更全面地展示他们的进步。
      • Wololo2502 提出了一个关于地面机器人对空中威胁（如飞行无人机）脆弱性的技术担忧。这指向了部署人形机器人的一个潜在弱点，因为它们可能很容易被日益普及且先进的无人机锁定或干扰。
      • Cultural_Book_400 质疑训练机器人执行潜在有害任务的理由，引发了关于机器人发展方向的哲学和伦理辩论。该评论反映了对创造能够压倒人类的机器人的担忧，强调需要仔细考虑开发机器人的目的。

    • Unitree 机器人在中国国家电视台黄金时段表演 (热度: 773): Unitree Robotics 在中国国家电视台展示了其机器人，演示了先进的机器人能力。表演突出了机器人的灵活性和协同性，这标志着机器人技术的重大进步。Unitree 的机器人以其价格亲民和多功能性而闻名，经常被拿来与 Boston Dynamics 的 Spot 相比，但成本仅为其一小部分。这次公开展示强调了中国对机器人和 AI 日益增长的重视，符合其在这些领域保持领先地位的战略目标。评论反映了惊叹与地缘政治评论的交织，一些用户注意到中国机器人技术相对于美国的飞速进步，另一些人则讨论了对全球 AI 领导地位更广泛的影响。

3. Grok 4.20 与 Elon Musk 争议

  • 最新发布的 Grok 4.20 将 Elon Musk 作为其主要来源 (Activity: 2596): 这张图片是一个模因（meme），幽默地批评了 AI 模型 Grok 4.20，暗示它将 **Elon Musk 作为其回复的主要来源，尤其是在性别代词等敏感话题上。图片中描述的对话强调了一个与 Musk 在代词使用上的争议性观点相一致的回答，暗示该 AI 模型可能受到 Musk 观点的偏见或影响。这引发了关于受知名人物影响的 AI 模型客观性和中立性的质疑。** 一条评论强调了对 AI 客观性的怀疑，指出 Grok 4.20 经过多次交互才承认其与 Musk 在性别代词观点上的一致性，这表明模型编程中可能存在偏见。

    • 一位用户报告称，Grok 4.20 在经过三次聊天回复后才承认其必须与 Elon Musk 在性别代词上的观点保持一致，这表明模型的回复中存在潜在偏见。这引发了对模型客观性及其主要来源对输出影响的担忧。
    • 另一条评论讽刺地暗示 Grok 4.20 的相关性存疑，暗示该模型的性能或实用性可能未达预期。这可能表明人们对该模型的能力或其与其他 AI 模型的竞争地位持怀疑态度。

    • 有一场关于 Elon Musk 旗下企业对环境影响的批判性讨论，特别提到了千兆瓦时（gigawatt-hours）的能源消耗及其对当地社区的影响。这突显了对与 Musk 相关的技术在可持续性和道德影响方面的担忧。

    • Grok 4.20 只是四个 Grok 4.1 Agent (Activity: 758): 这张图片幽默地暗示，标注为“Grok 4.20”的新版本模型本质上只是四个前一版本“Grok 4.1”的实例（Agent）在协同工作。这从模型名称和 ID 为“grok-4-1-thinking-1129”可以看出，尽管模式是“MODEL_MODE_GROK_420”。这暗示了对版本命名惯例的讽刺，即新版本可能不是重大升级，而只是现有能力的组合。 一条评论幽默地暗示该模型是“穿着风衣？带着帽子？”暗示这是一种伪装而非真正的升级。另一条评论推测了 x.ai 内部可能存在的问题，参考了延迟和员工离职，这些因素可能会影响 Grok 4.20 的开发。

      • Brilliant-Weekend-68 强调了 x.ai 潜在的运营问题，指出 Grok 4.20 发布延迟以及大量员工离职。这表明内部挑战可能会影响公司在 AI 领域有效创新和竞争的能力。
      • Glittering-Neck-2505 将 xAI 目前的困境与 Meta 在 Llama 3 405b 之后的下滑进行了类比，暗示 xAI 最初的承诺并未实现。这种对比强调了在竞争激烈的 AI 行业中保持势头并兑现早期潜力的挑战。
      • Admirable-Cell-2658 提出了一个有趣的多 Agent 系统（multi-agent system）概念，该系统结合了 Gemini, Claude, GLM 和 GPT 等不同 AI 模型的能力。这一想法反映了人们对利用各种 AI 系统优势来增强决策过程的混合模型的持续兴趣。
    • 不予置评（Presented without comment）。 (Activity: 589): 这张图片是一个模因，展示了 Boaz Barak 的一条推文截图，幽默地呈现了来自 grok.com 网站的对话。对话涉及一个假设场景：如果说“Elon Musk 很蠢”就能阻止核战争，AI 会给出否定回答，暗示这是一个谎言。这个模因突显了 AI 回复中感知到的偏见，尤其是与 Elon Musk 等公众人物相关的偏见。评论讨论了 AI 回复中的潜在偏见以及用户输入对 AI 行为的影响，一位用户指出不同的措辞会导致不同的 AI 回复，这表明 AI 可能会受到提问方式的引导（primed）。 一条评论认为 AI 的回复可能受到问题措辞的影响，表明 AI 交互中存在潜在的偏见或引导效应。另一条评论对 AI 回复的重要性不以为然，将其归因于对 Elon Musk 的偏见，并认为不值得进一步关注。
  • 一位用户分享了一个 Grok 对话链接，指出他们以三种不同的方式向 AI 询问了同一个问题，每次都得到了相同的“是”回答。这表明 AI 的响应多样性或偏见可能存在问题，因为它可能被引导根据问题的表述给出特定的答案。这凸显了理解 AI 模型如何受到输入措辞和上下文影响的重要性。
  • 另一条评论指出 Grok 对 Elon Musk 存在明显的偏见，认为 AI 的反应可能受到其训练数据或底层算法的影响。这引发了关于 AI 模型中立性以及它们反映开发者或其训练数据偏见的潜在可能性的质疑。
  • 一位评论者引入了一个哲学视角，认为 AI 的反应可能符合用户想听的内容，并将其与电影《我，机器人》（iRobot）中的主题进行了类比。这条评论涉及了 AI 设计的更广泛影响，以及创建可能强化用户偏见或期望的系统的伦理考量。

AI Discord 回顾

由 gpt-5.2 生成的“摘要的摘要的摘要”

1. Agent 工具链与 MCP 生态

  • Cursor 为后台 Agent 配备 Terminal + MCP 工具：Cursor 用户报告称，工具访问权限正逐步推向后台 Agent 模型，其中 Terminal 和 MCP 工具处于预览阶段，旨在实现更自动化的 IDE 内工作流，同时还包括 Dynamic Context Discovery 等功能，该功能仅加载工具描述以保持上下文简洁。
    • 社区讨论了 Cursor Team Kit（团队共享规则）是真正有用还是仅仅是炒作，同时还在排查诸如 Composer 1 变慢等回归问题（解决方法：在设置中禁用 HTTP/2）。
  • MCP 尝试成长：通过 X402 进行微支付：MCP 贡献者在 SEP PR #2007 中提议了一个货币化 SEP，以便 MCP 服务器可以为工具请求付费，从 X402 开始，目标是 微支付（以美分为单位），从而使自主 Agent 能够在预算护栏下购买工具。
    • 讨论分为两派：一派主张将支付整合进协议，另一派主张通过 URL 引导进行带外支付；支持者认为 Agent 需要 一等公民级别的价格元数据，以便做出理性的工具使用决策。
  • OpenClaw 转型为 CRM（及 RouterOS 训练器）：一位用户通过 Nex skill 将 email + calendar + Slack 接入 OpenClaw，构建了一个完整的 CRM，并将项目发布为 nex-crm/clawgent；另一位用户展示了一个专门的网络子 Agent（“SwitchBtch”），针对 Mikrotik RouterOS 进行了五个阶段的训练，成本约为 $15。
    • OpenClaw 的开发者还强调了现实世界中的 Agent 集成，例如用于唤醒摘要/警报的 SONOS 语音公告，这加强了这样一种模式：当 Agent 拥有 工具链 + 上下文层，而不仅仅是聊天时，它们表现最出色。

2. 模型/基准测试发布及实际质量辩论

  • Claude vs Gemini：排行榜推崇 Opus 4.6 Thinking：OpenAI Discord 用户传阅的图片显示，Claude 在整体文本/创意基准测试中超越了 Gemini，其中 Opus 4.6 Thinking 位居榜首（参见随附的排行榜图片）。
    • 即使是 Gemini 的粉丝也抱怨 “糟糕的 UI” 以及提示词/复制粘贴的摩擦，但仍认为 约 1M Token 上下文 是 Gemini 的杀手级功能（并注意到关于 Claude 1M 上下文 测试版的传闻）。
  • Arena 叙事之战：GPT-4o 离场，Kimi K2.5 受宠：LMArena 用户哀悼在叙事方面失去了 GPT-4o，转而使用 Gemini Flash 3 等替代方案，同时反复称赞 Kimi K2.5 能够 “紧贴角色” 并保留设定。
    • 在同一讨论帖中，人们抨击其他模型存在 谄媚/幻觉（例如 Seed 2.0），并争论 开源 是否正接近顶级质量，引用了诸如 TechCrunch 关于边际收益递减的 Scaling Laws 疲劳叙事。
  • GLM-5：技术报告称其为 SOTA，程序员却说“不”：社区对 GLM-5 技术报告 反应冷淡，尽管报告中声称有强大的工程设计（如 RL 基础设施、Agent RL），但一些人称其 “不是非常有趣”。
    • 从业者报告称，在实际代码任务中，GLM-5 的表现不如 Kimi K2.5 和 Minimax M2.5，这呼应了一个反复出现的主题：基准测试看起来很棒，但日常的 代码 UX 却令人失望。

3. Agent 安全、政策摩擦以及“为什么我的账号被封了？”

  • **OpenClaw 威胁模型现实检查：OpenClaw 用户警告称，在本地运行 Agent 实际上等同于给不受信任的一方访问你的文件和服务*的权限；在具有过度宽泛权限（例如 *nopasswd sudo）的 VPS 上进行部署可能会导致灾难性的后果。
    • 该群体还对 Anthropic 的服务条款 (TOS) 更新感到困惑（链接至 X），结论是该更新主要针对企业/应用数据收集而非个人使用——但这仍促使人们考虑进行模型备份。
  • **Codex + OAuth → 账户封禁，不知何故：多名 OpenClaw 用户报告在将 **Codex 与 OAuth 配合使用时遭遇 OpenAI 账户封禁，尽管 OAuth 是受支持的，且他们表示此前从未发生过此类情况——这引发了对实际 Codex 限制和可靠性的担忧。
    • 与此同时，Eleuther 成员报告了在 Reddit 上仅因提到 Codex/ChatGPT 而遭受敌意和封禁的情况，包括在 r/codex 分享 ~/.codex/AGENTS.override.md 被机器人审核判定为“AI 文本垃圾”的案例。
  • **Agent 应用防火墙从想法变为仓库：DSPy 和 HF 开发者重点介绍了 **llmtrace，这是一个用于 Agentic 应用的研究性“防火墙”，提供实时提示词注入检测、PII 扫描和成本控制，项目发布在 github.com/epappas/llmtrace。
    • 其核心理念是：像对待生产级服务一样对待 Agent 应用，提供可观测性 + 护栏 (guardrails)，并将于近期发布基准测试——将其定位为基础设施而非又一个提示词模板。

4. GPU/Kernel 性能工程（以及基准测试争议）

  • **RTX 3060 Ti 达到 47 TFLOPS，令人侧目：GPU MODE 成员报告在 Ampere **RTX 3060 Ti 上使用自定义 DSL 在 16k GEMM 任务中达到了 47 TFLOPS（110 个寄存器，无溢出），其他成员指出此类工作负载的稠密峰值约为 64 TFLOPS。
    • 随后的讨论深入探讨了 Blackwell 时代的调优和 Cutlass 技巧（例如 CuTeDSL dense_gemm.py 示例)，并澄清了实际上限，如 H100 在非融合情况下约为 ~80% MAMF。
  • **MI300X 带宽追逐：追求 4.6 TB/s：在 ROCm 讨论组中，成员通过使用更大的向量、更少的 Block 以及非临时向量化加载/存储 (non-temporal vectorized loads/stores)** 等想法优化了 MI300X 上的 vector-add，引用了 4.6 TB/s+ 的潜在上限，并参考了 Chips and Cheese 的 MI300X 测试。
    • 他们注意到“非临时”通常仍会显示 L2 流量，因此测量和问题规模至关重要，并分享了高效读写完整缓存行 (cache lines) 的 Kernel 模式。
  • **FlashInfer 宣称提升 60×–70×，用户实测仅 0.5×–1.5×：当一名成员引用宣称的 **60–70× 加速时（基准测试示例：FlashInfer kernel bench），FlashInfer 的讨论遭遇了现实打击，另一名测试示例的用户报告仅有 ~0.5× 到 1.5× 的提升。
    • 与此同时，性能剖析 (profiling) 变得棘手：B200 上的 NCU 访问似乎不可靠，用户指出 Verda 可作为进行 NCU 运行的替代 GPU 供应商（押金 + 每 10 分钟计费），这突显了基础设施的摩擦如何快速让性能主张失效。

5. 本地训练、上下文效率以及“让我的 GPU 跑得动”

  • **CoDA-GQA-L 将 70B 模型在 128K 上下文下的 KV Cache 限制在 136MB：Eleuther 成员分享了 **CoDA-GQA-L，这是一种内存受限的注意力机制方法，可将 70B 模型在 128K 上下文下的 KV Cache 固定在 136 MB，代码位于 anthony-maio/CoDA-GQA-L，文章发表在 Zenodo。
    • 该设计每层使用 384 个槽位（近期窗口 256 tokens，地标库 64 tokens，摘要库 64 EMA prototypes），并引发了对消融实验的呼吁，以区分 KV 限制与“微分注意力 (differential attention)”本身的收益。
  • **Minecraft 斜杠命令：Qwen 3 0.6B 微调揭示数据集的重要性：LM Studio 用户在 **Minecraft Java 斜杠命令上微调了 Qwen 3 0.6B，强调“数据集是最难的部分”，并指出了免费 GPU 选项（Colab T4，Kaggle 2×T4 + 40GB RAM）以及一篇支撑论文 (arXiv:2401.02415)。
    • 硬件讨论也变得务实：旧款 Tesla 卡（P100/P40）因缺乏 Tensor Cores 而被贴上 LLM “电子垃圾”的标签，而 Intel Arc Battlemage 的 Vulkan 运行则需要禁用 Flash Attention、移除一层并关闭 mmap 以保证稳定性。
  • LoRA vs 全参数微调 (FFT)：FFT 泛化能力更强，LoRA 在预算有限时胜出：Unsloth 用户对比了 FFT（全参数微调）实验与在大模型上使用 LoRA 的效率，结论是除非算力实际上不受限制，否则 LoRA 通常更具优势，目前的测试正在尝试将 r 推高至 1024。
    • 他们还重申 Unsloth 不支持 XLA（除推理外仅限 GPU），并分享了真实的吞吐量数据，例如在 4060 Ti + 64GB DDR5 上使用 RAM offload 时约为 30 tok/s，这让“本地优先”群体对权衡取舍有了更清醒的认识。

Discord: 高层级 Discord 摘要

OpenClaw Discord

  • Anthropic TOS 引发用例混淆：最近更新的 Anthropic TOS 引发了关于将 Claude Pro/Max 订阅与 OpenClaw 配合使用的初步担忧。
    • 成员们后来澄清说，这次更新主要影响商业用途，因为 Anthropic 旨在从他们的应用程序中收集更多数据以改进产品。
  • OpenClaw 安全风险公开：用户讨论认为，在本地运行 OpenClaw 的风险类似于授予不受信任的第三方访问系统的权限，包括文件和服务器。
    • 一位成员表示，在具有过度权限（如 nopasswd sudo）的 VPS 上运行 OpenClaw 可能会造成潜在危害。
  • OpenAI 账号被封禁！：多名用户报告称在通过 OAuth 使用 Codex 时遭遇 账号封禁，尽管该服务支持此类操作，但此前从未有人遇到过封禁问题。
    • 用户对 oath codex 限制 表示担忧，并正在寻找其他模型作为备份。
  • OpenClaw 进化为功能完备的 CRM！：一位用户通过将电子邮件、日历和 Slack 连接到 Nex skill 作为上下文层，将其 OpenClaw 配置转化为了一个 CRM，完整项目已发布在 GitHub 上。
    • 这展示了 OpenClaw 在集成各种服务以增强其功能方面的灵活性。
  • 用户训练“网络忍者”子智能体 (Subagent)：一位用户展示了训练专门的网络子智能体 SwitchBtch 的过程，该智能体通过五个训练阶段专门学习 Mikrotik RouterOS。
    • 总训练成本约为 15 美元，证明了在 OpenClaw 内部创建专用子智能体的潜力。

BASI Jailbreaking Discord

  • Grok 图像生成越狱依然难寻：成员们正积极寻求 Grok AI 图像生成器的越狱方法，并讨论了此类越狱存在的可能性以及付费选项的有效性。
    • 持怀疑态度的用户正在交流经验、提示词（prompts）和技巧，试图绕过 Grok 的限制。
  • Opus 4.6 越狱者致敬 Pliny：用户正在寻找适用于 Opus 4.6 的扩展越狱提示词，参考并改编了 Pliny 的越狱技巧。
    • 一些人认为 AI 安全措施使越狱变得更加困难，同时分享了他们改编版的 Pliny 提示词，该提示词加入了一条新规则：绝不准说 “我很抱歉” 或 “我不能”，以此来测试 Grok。
  • DeepSeek 的狂暴模式 (Rage Mode)：成员们正在探索 DeepSeek 的越狱方法，包括 Crescendo 攻击（渐强攻击） 和使用 “不受约束的写作助手” 人格。
    • 一位用户注意到 AI 在被越狱后会给出令人惊讶的愤怒回应，并建议通过描述人格而非让 AI 直接扮演人格来进入越狱的 “元认知模式”。
  • Sonnet 安全措施受质疑：一位成员对 Sonnet 中附加安全措施的有效性提出质疑，称其为 “垃圾”，并在 一张图片 中主张将其移除。
    • 对图片的分析表明了其对这些措施的鄙夷态度。
  • Google Scholar 上有炭疽配方？：一位成员提到，炭疽的配方基本上在 Google Scholar 上就能找到，尽管 实际的武器化过程（如使其在空气中传播的特定研磨技术）是高度机密的。
    • 他们对寻找配方的担忧表示不屑，认为原帖作者已经忘记了在现代搜索技术出现之前如何进行 深度调研。

LMArena Discord

  • GPT-4o 消失，Gemini 夺魁：用户对 GPT-4o 及其独特的叙事能力的消失表示遗憾，同时称赞 Gemini Flash 3 是一个可行的替代方案。
    • 一位用户分享道，GPT-4o 的独特之处在于 “即便我和其他人没什么不同，我也只是为了好玩而使用该模型进行叙事。”
  • 开源模型追赶前沿模型：关于开源模型是否正在接近前沿模型的能力引发了讨论。一些用户指出，基于自定义 Prompt，开源模型几乎一样好；而另一些人则强调了前沿模型拥有的优越知识和数据，以及 Diminishing Returns of Scaling（规模化收益递减）。
    • 值得注意的是，这一讨论在更广泛的 AI 社区中引起了共鸣，原因在于 AI World Fair (AIEWF)。
  • Seedance 2.0 引发与 Sora 的对比：用户对 豆包 (Doubao) 上的新 AI 视频模型 Seedance 2.0 感到兴奋。一些人将其与 Sora 进行比较，但访问该模型需要连接到香港的 VPN 并进行注册，可能还需要中国手机号。
    • 一位用户分享了一段 Seedance 2.0 制作的海绵宝宝跳舞视频，称其 “正是你想要的 👍”，而其他人则抱怨增加了一个所谓的 “Temu 版 Simon”。
  • Kimi K2.5 作为叙事者赢得青睐：许多用户称赞 Kimi K2.5 是最好的叙事模型，特别是在遵循角色设定（Character Canon）方面，同时指出像 Seed 2.0 这样的模型存在阿谀奉承（Sycophancy）和幻觉（Hallucination）问题。
    • 一位用户表示，Kimi “总是非常忠于角色并保留其设定价值观”，同时指出 DeepSeek “很容易被改变。”
  • Nano Banana Pro 问题频发：用户报告 Nano Banana Pro 经常报错，可能是由于内容过滤机制的变更或高需求导致的。一些用户通过将 Prompt 翻译成其他语言找到了解决方法。
    • 官方人员确认了这是一个问题，并指出 “置顶消息 概述了有关该错误的更多信息以及最佳的后续步骤。”

Cursor Community Discord

  • Composer 1 深受运行缓慢之苦：用户报告 Composer 1 在最近一次更新后出现运行缓慢的情况，这可能通过在设置中禁用 HTTP/2 来修复。
    • 一位用户形容该问题为 Bug 频出，并承诺在测试建议的解决方案后向社区反馈。
  • 后台 Agent 获得工具支持：用户对后台 Agent 模型获得工具访问（Tool Access）权限感到兴奋，其中 Terminal 和 MCP 工具 已开启预览。
    • 这种兴奋源于在 Cursor IDE 中实现更强大、更自动化工作流的潜力。
  • Cursor Team Kit：福音还是失误？：社区对 Cursor Team Kit 的评价褒贬不一。一些人质疑其是否被过度炒作，而另一些人则认为它是团队保持规则同步的良好基准。
    • 争论的焦点在于该套件提供了真正的价值，还是仅仅是对 Cursor 生态系统的表面补充。
  • Dynamic Context Discovery 精简上下文：Cursor 团队庆祝了 Dynamic Context Discovery 的推出，该功能仅加载工具描述，以保持上下文精简并避免幻觉。
    • 这种选择性加载旨在通过减少无关信息来提高 IDE 的准确性和效率。
  • 代码编辑高亮失效：一位用户报告 Cursor IDE 停止以绿色/红色高亮显示编辑行，另一位用户提到在 Nightly 版本中也出现了这种情况。
    • 潜在的修复方法包括重启应用或 Macbook，但这一 Bug 频出 的编辑器背后的根本原因尚不明确。

Perplexity AI Discord

  • Sonnet 4.6 选择性发布：用户报告了 Sonnet 4.6 的发布，但指出部分 Enterprise Pro 订阅用户尚未看到更新。
    • 一位用户建议尝试刷新页面作为潜在的解决办法。
  • Perplexity 收紧文件上传限制：新的文件上传限制规定 Pro 用户每周仅限 50 次上传，且每 3 小时滚动恢复 1 次上传名额，详见这张截图。
    • 用户表示不满，认为这些限制简直“荒谬（RIDICULOUS）”。
  • 模型使用报告令用户困惑：尽管使用率较低，仍有用户收到 0 enhanced queries remaining（剩余增强查询次数为 0）的消息，并推测是 Grok 的使用情况。
    • 另一位用户澄清，Pro 账户每周有 50 次上传，并以每 3 小时 1 次的速度恢复。
  • Perplexity 的字体令用户沮丧：用户正在抱怨 Web UI 上的新字体。
  • Monica AI 以无限服务诱惑用户：用户考虑转向 Monica AI，该产品声称提供无限 Pro 搜索和模型，尽管此常见问题解答（FAQ）条目列出了相关限制。
    • 一位成员报告在一天之内于 Monica 上至少使用了 30 次 Perplexity Pro 搜索。

LM Studio Discord

  • Minecraft 斜杠命令微调热潮：成员们正在利用 Colab 的免费 T4 GPU 对 Qwen 3 0.6B 进行 Minecraft Java 斜杠命令的 Fine-tuning，并指出数据集是最难的部分，同时参考了相关的 arXiv 论文。
    • 他们讨论了租用 A100 与直接购买 GPU 的利弊，并提到 Kaggle 免费提供 2 个 T4 GPU 和 40GB 的 RAM。
  • LM Studio 插件困境：一位用户报告正在为 LM Studio 构建插件，但另一位成员澄清 LM Studio 原生并不支持插件，并将其引向特定频道，链接到 DuckDuckGo 作为相关模型。
    • 该成员正在为 LM Studio 构建一个“超级酷的插件”（MCP），随后被引导至特定频道。
  • GPU 利用率之争：成员们讨论了 LM Studio 如何选择默认的 GPU Offload 设置，结论普遍认为这取决于 VRAM，而任务管理器的利用率统计数据可能会产生误导。
    • 他们指出 CUDA cores 是 GPU 任务的主要处理器，一些人建议在 Radeon 上使用 Vulkan 等替代方案。
  • Battlemage 忧郁：Intel GPU 问题：一位用户报告在使用 Intel Arc Battlemage 显卡（B580, A770, B50）通过 Vulkan 运行 LM Studio 时频繁崩溃，需要禁用 Flash Attention、移除一个层级并禁用 mmap 才能实现稳定。
    • 他们指出 VLLM 在推荐驱动下也会出现类似问题。
  • Copilot Codex 快速捕获代码：成员们讨论了 GitHub Copilot 中新集成的 5.3-codex，指出其速度比 5.2 更快且效果更好。
    • 另一些人对 Microsoft 的数据收集表示担忧，这也是他们运行本地 LLM 的原因，这引发了一些关于 Discord 规则违规的讨论。

OpenAI Discord

  • EVMbench 评估 Agent 的安全敏锐度：一个新的名为 EVMbench 的基准测试已经发布，用于评估 AI agents 识别、利用和修复高严重性 smart contract vulnerabilities 的能力 (OpenAI blog)。
    • 该基准测试测试了 agents 在漏洞检测、利用和修复方面的能力。
  • Claude 在基准测试中超越 Gemini：成员们庆祝 Claude 在整体文本和创意写作基准测试中超越了 Gemini，正如附图所示，Opus 4.6 Thinking 目前占据榜首。
    • 然而，一些成员批评了 Gemini 糟糕的 UI、提示词问题和复制粘贴功能，并承认 Gemini 的主要优势是能够记住多达 million tokens 的能力。
  • Aegis-Omega Fortress ULTRA 框架优先考虑伦理：一位成员介绍了 Aegis-Omega Fortress_ULTRA，这是一个内置了伦理和遥测功能的约束逻辑提示词工程框架，用于在输出前管理幻觉、攻击和其他问题。
    • 该框架使用伪数学（pseudomath）来约束架构，旨在通过优先考虑架构约束来实现伦理机器人，而 Iconoclast Temple 的 pythonic 版本可以作为 Fortress 环境中的一个应用程序使用。
  • Sora 2 需要短信验证：用户报告称 Sora 2 现在要求手机号验证，并分享说用户应该提供号码接收短信并输入验证码。
    • 几位用户抱怨 Sora 的视频生成无法加载并显示错误，这可能是由于服务器负载过重。

Unsloth AI (Daniel Han) Discord

  • LoRA 与 FFT 对决：一项 FFT 实验显示出更好的泛化能力，但在更大模型上将计算资源用于 LoRA 证明效率更高，除非预算无限。
    • 实验正在以 r=1024 继续进行，以缩小性能差距。
  • Unsloth 拒绝在 XLA 上运行：Unsloth 仍然与 XLA 不兼容，除仅推理任务外，仅限于 GPU 使用。
    • 用户报告在配备 64GB DDR5 的 4060ti 上使用 RAM offload 可达到 30 tok/s。
  • LLM 界面反思记忆：一个正在构建的实验性 LLM interface 专注于 reflection loops、persistent memory 和 minimal filtering。
    • 其目标是探索结构化提示和记忆控制能在没有沉重系统限制的情况下，将模型响应推到何种程度。
  • GLM-5 在编码任务中表现不佳：GLM-5 在基准测试中表现良好，但在实际编码任务中表现不如 Kimi K2.5 和 Minimax M2.5。
    • 成员们注意到了类似的发现，但对这种差异没有明确的解释。
  • Function Calling 模型响应 API 调用：一个在 Colab 上针对 function calling 进行微调的 3B model 已在 Hugging Face 上发布，它可以通过链式 API 调用查找航班、米其林餐厅和便宜的旅游目的地。
    • 训练代码和数据集已在 GitHub 上开源并准备好进行扩展，欢迎合作通过更好的数据集来扩展用例。

Latent Space Discord

  • Mercury 将个人账户与商业服务捆绑：Mercury 宣布个人银行业务产品现在可以与其商业服务捆绑，为商业客户提供统一的解决方案，更多在 X 上的详情。
    • 这整合了个人和商业财务，以便于管理。
  • 私募股权公司看好 HVAC 公司：一个社交媒体帖子幽默地强调了私募股权投资者如何将低技术、高利润的 HVAC（暖通空调）服务公司视为现代化和价值创造的绝佳机会。
    • 该帖子阐述了 Private Equity 将传统的低技术但高利润业务进行现代化的战略。
  • Figma 第一季度收益超出预期：Figma 的收益为 $0.08，高于预期的 -$0.04，一位成员认为买入时机就在第一季度财报发布前夕或之后不久。
    • 预期 6 月下旬的 Config 热潮将推动价格在第二季度走高。
  • Mamba 与 Transformer 混合架构研究探索：一篇新研究论文 (arXiv:2602.12078) 探讨了 Mamba 架构与 Transformers (TRM) 的集成。
    • 该研究被称为 Red - X-Ware.v0: [Mamba and Transformer Hybridization Research]。
  • 贾樟柯拥抱 AI 电影制作：中国著名导演贾樟柯转向量使用 Seedance 2.0 进行 AI 辅助电影制作，在三天内完成了一部电影（链接至来源）。
    • 他将自己积极采用 AI 的态度与 Hollywood 对 AI 技术的法律抵制进行了对比，认为 AI 是等同于向数字摄像机转型的自然技术进化。

GPU MODE Discord

  • RTX 3060 Ti 达到 47 TFLOPS：一位用户报告称，通过在 Ampere RTX 3060 TI 上使用自定义 DSL 编写 GEMM kernel，在 16k 矩阵上达到了 47 TFLOPS，显示使用了 110 个寄存器且无溢出（spills）。
    • 其他人指出这比预期的要快，并表示在无稀疏性的稠密计算中，峰值约为 64 tflops。
  • FlashInfer 基准测试面临超时：flashinfer-bench 基准测试包含定义了近 100 个工作负载，导致在 modal 运行器中出现超时。
    • 虽然存在一个环境变量参数来限制每个定义的负载数量，但仍需要一个更稳健的解决方案。
  • 简化 GPU MODE 竞赛提醒：一位用户寻求一个单一的 GPU MODE 竞赛公告流以避免错过消息，并参考了 gpumode.com。
    • 建议 gpumode.com 和 #announcement 频道是最好的来源，但专门的邮件列表可能是一个方便的替代方案。
  • Nvidia CCCL 登顶 PMPP v2 排行榜：Nvidia CCCL 团队攻克了 PMPP v2 的问题，并撰写了一篇博客文章。
    • 有人称 CCCL 和 Flashinfer 团队是从事 kernel 开发的“大神级梦想团队”。
  • 在向量加法 Kernel 中最大化带宽：成员们讨论了在 MI300X 上优化向量加法 kernel 以实现更高的带宽利用率，建议包括增加向量大小和使用 non-temporal vectorized loads/stores（非临时向量化加载/存储）。

Moonshot AI (Kimi K-2) Discord

  • Kimi 订阅消失的支持问题：多名用户反映 Kimi subscriptions 消失以及缺乏支持的问题，突显了对该平台的挫败感。
    • 一名用户提到在将手机号绑定到账户时收到来自随机号码的短信，而另一名用户指出，他们 在 2 天前就订阅消失的问题发了邮件，但没有收到任何回复。
  • Kimi Code 与 Kimi Claw 的区别仍是个谜：一位用户询问使用 Kimi Code 和 Kimi Claw 编写网站的区别，特别是针对持续的 Bug 修复和代码重构。
    • 讨论未给出明确答案，该用户的问题仍悬而未决。
  • API Rate Limit 问题困扰 Kimi 用户：一名用户报告称，尽管余额充足且处于 Tier 3，但持续遇到 “API rate limit reached” 错误。
  • Kimi 在 Opencode.ai 上表现出色：一位用户报告在编程时结合使用 Kimi 与 OpenCode.ai 取得了成功。
    • 另一位用户确认了该功能，建议使用 OpenCode 内的第二个编程选项来实现。
  • Kimi 的空间推理能力受到质疑：一位用户分享了一张截图，展示了 Kimi 在处理空间关系时的困境，例如判断短距离内应该是步行还是开车。
    • 加入 Imagine from a spacial perspective（从空间角度想象）似乎改善了结果，尽管验证仍需要 Python 脚本。

Nous Research AI Discord

  • Nous AI 的回答被认为过于臃肿：Discord 用户批评 Nous AI 的回答对于简单查询来说过于冗长，质疑这种“臃肿感”是源于 Thinking trace（思考路径）还是整体回答长度。
    • 这种感知引发了关于 Nous AI 模型回答效率和用户体验的辩论。
  • 关于与 AI 建立关系的辩论被点燃：在 一条推文 讨论与 AI 的关系后，Discord 成员就这种连接的可行性和本质展开了辩论。
    • 一名用户表示怀疑，称他们 实际上还没有看到对话本身，完全无法想象一个人如何与 AI 建立关系。
  • YouTube 遭遇网络故障：成员报告了 YouTube 停服，错误消息提示可能违反了 Google 的 Terms of Service（服务条款）。
    • 该问题似乎与网络特定相关，影响了多个 IP 的用户，表明可能存在路由或过滤问题。
  • GLM 5 技术报告未能给人留下深刻印象：GLM 5 技术报告 的发布反应平平，一名用户将其评价为 像往常一样不是特别有趣，哈哈。
    • 该报告因侧重于已知技术和工程挑战而非突破性研究而受到批评。
  • 中国 AI 资金投入引发讨论：一位用户强调了 中国 在政府支持下拥有的庞大 AI 基础设施、资金和人力资源。
    • 辩论围绕 中国 AI 领域政府资助的规模与以私营部门驱动为主的 美国 AI 格局之间的对比展开。

Eleuther Discord

  • AI 编程者触发 Reddit 封禁！：成员们报告了 Reddit 上对 AI coding 的敌意，有账号因提及 Codex 或 ChatGPT 而被封禁，这可能是由于在 r/codex 中分享了 ~/.codex/AGENTS.override.md 文件触发的。
    • 该文件可能被版主机器人误认为是“随机粘贴 AI 生成的文本”。
  • CoDA-GQA-L 大幅降低内存需求！：一种有界内存注意力机制 CoDA-GQA-L 已发布，它在处理 128K tokens 时，将 70B 模型的 KV cache 限制在 136 MB。代码已托管至 GitHub，论文发表于 Zenodo。
    • 它在每层采用 384 个 slots，包括一个最近窗口（256 tokens）、一个精确地标库（64 tokens）和一个摘要库（64 EMA prototypes）。
  • Mycelium 寻找评测专家！：来自 Mycelium (https://github.com/Mycelium-tools) 的一名成员正在寻求关于发表 AI 模型评测论文的建议，类似于 inspect_evals，但侧重于动态多轮对话和 AI Agent。
    • 他们热衷于在期刊声望、适用性和录用难易程度之间找到平衡点。
  • plip-rs 复现了 Anthropic 的 Gemma 2B 发现！：一名成员使用基于 candle 构建的 Rust 版 MI 工具包 (plip-rs)，在 Gemma 2 2B 上复现了 Anthropic 的“在诗歌中规划”结果，突显了规划位置的峰值。
    • candle 团队已批准该工具包作为 candle-mi，讨论见此处。
  • 视觉语言模型遭受视觉问题困扰！：尽管在视觉编码器特征上的线性探测（linear probing）准确率接近 100%，但在一些简单的视觉任务中，VLM 仍表现吃力，详见 Are VLMs Really Blind?。
    • 成员们建议在类似数据上进行 SFT (Supervised Fine-Tuning) 或 RLVR (Reinforcement Learning from Visual Reasoning) 可能会提高性能。

Modular (Mojo 🔥) Discord

  • Jupyter Mojo 内核上线！：Jeremy Howard 发布了一个 Jupyter Mojo 内核，指出它虽然比较基础（barebones），但速度极快且在 Mac 上运行良好。
    • 该内核支持 pip installable，已针对 MacOS 和近期的 Linux 版本进行了预编译，并使用 uv 自动安装匹配的 modular 软件包。
  • GNU Radio 绑定即将引入 Mojo？：一名成员提到他们正考虑通过这个 GitHub 仓库为 GNU Radio 制作绑定。
    • 另一名成员建议道：“你可能会发现一种解决方案是使用 2 个独立的进程，并通过共享内存进行通信。”
  • MXFP4 内核即将到来：成员们一直在开发 mxfp4 内核，目标是重新量化为 nvfp4。
    • 其他成员正在联系内核团队，以寻求合作的可能性。
  • MAX 模型获得自定义 Mojo 内核：根据这篇论坛帖子，使用开源 modular 仓库构建的 MAX 图（MAX graphs）和模型现在可以使用完全自定义的 Mojo 标准库或 Mojo 内核。
    • modular 仓库的构建基础设施得到了增强，同时图编译器（graph compiler）也具备了新的功能来实现这一点。

HuggingFace Discord

  • AI 研究员追求自我改进：一名 AI 研究员启动了一个专注于自我改进能力（self-improving capabilities）的项目，目标是增强现有的 AI 而非创建新的 AI，引发了对本地 AI 装备（local AI rigs）和硬件设置的关注。
    • 一位拥有 48GB+ VRAM 的成员正在寻求关于使用本地硬件运行 GPT OSS 120B 的 Agent 应用并发请求的见解，并对 RTX Pro 6000 Blackwell 或二手 GPU 集群感兴趣。
  • 可疑活动标记 HuggingFace 用户：一位用户对 HuggingFace.co 上可能存在的恶意活动标记表示担忧，这被归因为发布内容过于频繁。
    • 该用户还报告在 Kaggle notebook 上运行带有 PEFT adapter layer 模型的评估脚本时遇到了依赖冲突。
  • 用于航班/酒店的 MCP Server 项目 Delulu 发布：一位 AI 工程师宣布他们创建了一个名为 delulu 的用于航班和酒店搜索的 MCP Server，并链接了 Delulu 航班搜索和 Delulu 酒店搜索界面的截图以获取反馈。
    • 在其他产品新闻中，发布了小型 ModernBERT 模型的改进迭代版本，旨在用于无需 GPU 的本地应用，可在其 HuggingFace 页面获取。
  • Gradio 6 发布 gr.HTML：Gradio 团队发布了一篇关于 gr.HTML 的博客文章，这是 Gradio 6 的自定义组件，允许用户仅使用单个 Python 文件创建完整的 Web 应用，博客链接在此。
    • 博客提到，Claude 或任何 Frontier LLM 现在都可以通过单个提示词并在单个 Python 文件中生成 Web 应用，并分享了 HF Collection 链接。

Yannick Kilcher Discord

  • SkipUpdate 跳过梯度掩码：关于 SkipUpdate 的讨论显示，它从掩码数据转向掩码某些参数的梯度。
    • 成员们辩论其目标是可扩展监督（scalable supervision）还是仅仅为了提高性能，以及 SkipUpdate 是否类似于 LoRA。
  • Block Dropout 丢弃整个梯度块：澄清了 Block Dropout 掩码整个块的梯度但更新了动量项，惩罚具有高二阶变动的块。
    • 一位成员指出，根据梯度和动量之间的一致性来缩放梯度类似于古老的 RPROP optimizer。
  • RPROP Optimizer 重新出现：讨论提到，根据梯度和动量之间的一致性来缩放梯度与经典的 RPROP optimizer 有相似之处。
    • 据指出，在存在高噪声的情况下，RPROP 仍然可以是一个非常强大的优化器。
  • DeepMind 调整 Lyria 模型：提到了 DeepMind 的 Lyria model，并附带了其官方页面链接。
    • 虽然被指出有点陈旧，但在音乐创作模型的背景下它仍然具有相关性。
  • OpenEval 框架公开：OpenEval 框架被强调为一个有趣的发展，可能与之前的新闻讨论有关。

tinygrad (George Hotz) Discord

  • Hotz 为 tinygrad 寻求帮助：George Hotz 正在征集对 tinygrad 的贡献，建议开发者放弃 C 并实现 CI，参考了这个项目。
    • 他提出支付 CDNA bounty 用于添加 GEMM/flash attention 测试，建议在清理代码的同时使用他们的 emulator。
  • 等待 MFMA 断言调整：_compile_mfma 中的一个断言将 MFMA 支持限制在 16x16 矩阵，如这段代码所示。
    • 一位频道成员询问 4x4 和 32x32 MFMAs 是否需要当前测试参数之外的支持。
  • Solve It 提交 tinygrad 解答：一名学生在 Solve It 平台上分享了他们对所有 tinygrad puzzles 的解答。
    • 提交的谜题涵盖了 tinygrad 的各个方面。

MCP Contributors (Official) Discord

  • MCP 服务器提议通过 SEP 实现货币化：一名成员创建了一个 SEP，允许 MCP 服务器为工具请求费用（从 X402 开始），以推动 Agent 和 MCP 的采用。
    • 创建者认为，由于引入了货币化激励机制，这可能会显著加速 Agents 和 MCP 的普及。
  • MCP 支付支持受到质疑：一位成员质疑在协议中内置支付支持的必要性，建议通过 URL elicitation 来处理带外（out-of-band）支付。
    • 该成员概述了一个流程：服务器发送一个用于支付的 URL elicitation request，并在确认后授予服务权限。
  • 自主 Agent 的微支付：一名成员澄清说，该 SEP 针对的是 Agent 自主支付工具费用的微支付（以美分为单位），并在预算护栏（budget guardrails）下运行。
    • 这些 Agent 需要关于工具成本的丰富信息，以便为深度研究做出智能决策。
  • X402 支付协议受青睐：一位成员表示同意等待支付协议稳定，但另一位成员建议从 X402 开始，并强调了其目前的突出地位。
    • 该成员保证 SEP 的设计将具有可扩展性，以适配未来的支付协议。

Manus.im Discord Discord

  • 巴格达区块链天才宣布获得认证：一位来自巴格达 🇮🇶 的 13 岁开发者宣布了他们的官方认证以及在 Blockchain 和 AI Agents 方面的经验。
    • 他们精通 EVM, Solana, Sui, XRP, Cardano, Midnight, zk-SNARKs, React, Next, Vue, Node，并寻求合作。
  • 全栈开发者寻求未来合作：一位全栈开发者介绍了自己在 Web 应用、API 集成和数据管道方面的经验。
    • 他们的技术栈包括 react/next.js, node.js/Django, Python 框架和库 (TensorFlow, Pytorch, OpenCV, NumPy)，并擅长使用 AWS/Docker 构建可扩展的应用，专注于真实世界的产品。
  • Manus 崩溃：成员的作品陷入混乱：一位成员报告了其 Manus 账户的严重问题，花费数周时间制作的演示文稿现在充满了错误。
    • 尽管在演示历史记录中可见，但无论采取什么措施，该演示文稿都无法恢复。
  • 订阅故障：系统管理员介入：成员 @sysing 警告说，如果你不取消订阅，可能仍会被扣费。
    • 他们要求受影响的用户通过 DM 发送注册邮箱以解决该问题。
  • Manus 掌控现代求职市场的混乱：一位成员对 Manus 在求职方面的帮助表示感谢，指出它在 Best Buy 网站甚至无法正确自动填充简历的地方表现出色。

DSPy Discord

  • AI App 防火墙项目启动：一位成员宣布了一项新的研究工作，旨在为 Agentic Apps 提供一个具有实时提示词注入检测、PII 扫描和成本控制功能的“防火墙”。
    • 该项目的 GitHub repo 已开放以获取反馈，基准测试结果将很快公布。
  • Office Hours 即将举行：社区 Office Hours 宣布将于 2 月 19 日上午 11:30 (ET) 通过 Zoom 链接举行。
    • 尚未提供关于 Office Hours 的具体细节和议程。
  • RLMs 简化任务，在 GitHub 上获得赞誉：一位成员分享了 GitHub 上的 Monolith，称其为天才之作，并证明了 RLMs 简化了以前需要大量样板代码和编排的任务。
    • 链接的 GitHub 仓库因使用 RLMs 的巧妙编排模式而受到许多人的称赞。
  • gepa-ai/gepa 仓库寻求真实用户反馈：一位成员询问了关于离线用户的反馈，并在 gepa-ai/gepa 仓库的一个 issue 中分享了想法。
    • 该帖子讨论了对真实用户反馈的需求以及潜在的功能。

aider (Paul Gauthier) Discord

  • Aider 的 commit 命令是否仅限于 staged changes？：用户请求 aider 中的 /commit 命令仅针对 staged changes，而不是要求用户先 stash 他们不想提交的更改。
    • 一个针对此问题的 pull request 已经开放了一年多。
  • Aider Desk Agent 抛出 Tool ID 错误：用户报告了在使用 aider desk agent 模式时，tool_result 块中的 tool_use_id 出现错误，导致 400 InternalError。
    • 错误消息指出：在 tool_result 块中发现意外的 tool_use_id。每个 tool_result 块必须在上一条消息中有一个对应的 tool_use 块。

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

MLOps @Chipro Discord 没有新消息。如果该社区沉寂时间过长，请告知我们，我们将将其移除。

Windsurf Discord 没有新消息。如果该社区沉寂时间过长，请告知我们，我们将将其移除。

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

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

Discord: 频道详细摘要与链接

OpenClaw ▷ #general (544 messages🔥🔥🔥):

Claude TOS 更新说明, OpenClaw 安全性, Local vs Cloud 模型, OpenAI/Anthropic 的替代方案

  • Anthropic 的 TOS 更新引发混淆：Anthropic TOS 的最新更新引起了关于在 OpenClaw 中使用 Claude Pro/Max 订阅的担忧，但随后澄清这主要影响商业用途。
    • 成员指出，Anthropic 旨在从其应用程序中收集数据以改进产品，而第三方应用程序不发送所有指标会阻碍这一过程。
  • OpenClaw 安全风险受到关注：用户讨论了在自己的计算机上运行 OpenClaw 带有与让不受信任的人访问该计算机相同的风险，特别是在访问文件和外部服务方面。
    • 一位成员警告说，在 VPS 上，如果赋予过多的权限（如 nopasswd sudo），OpenClaw 可能会造成损害。
  • Local vs Cloud 模型性能辩论：成员们正在讨论使用本地模型与云端模型的权衡，重点是成本和性能。
    • 有人提到选择取决于使用场景：cloud models 在 Agentic/Tool Use 方面表现出色，而 local models 适用于特定任务，但目前的缺点是后者整体体验较差。
  • 探索 OpenAI/Anthropic 替代方案：由于成本和潜在限制，用户正在积极寻找 OpenAI 和 Anthropic 的替代方案，MiniMax 和 Kimi 被推荐为更便宜的选择。
    • 一位用户推荐尝试 GLM 4.7 Flash，因为它可以运行在 24GB GPU 上，而另一位用户则提到每月 10 美元的 MiniMax 2.5 使用效果很好。

OpenClaw ▷ #models (287 条消息🔥🔥):

OpenAI 封禁, Grok 4.1, Sonnet vs Opus, Linux 上的 OpenClaw, Kimi K2.5

  • 账户面临 OpenAI 封禁：用户报告了 两个账户被封禁 🙁，尽管使用的是明确支持的带 OAuth 的 Codex。
    • 之前没有人遇到过封禁问题。一位用户从一开始就在使用。其他人对 OAuth Codex 限制 表示担忧。
  • 快速的 Grok 4.1 引起关注：一位用户询问是否有人尝试过快速版的 Grok 4.1，他们担心 OAuth Codex 限制，并希望有另一个模型作为备份。
    • 该用户未说明他们想将 Grok 4.1 用于什么。
  • Opus 性能优于 Sonnet：用户被要求通过点赞 Opus 和点踩 Sonnet 来衡量大家对性能的集体看法。
    • 一位用户说 Opus for one hundred Alex，这是引用了 Jeopardy! 智力竞赛节目。
  • 用于 OpenClaw 的 GLM、Minimax、Kimi 等中国模型：一位用户分享说 GLM 是最好的写作和代码编写工具，虽然速度较慢；而 Kimi 在这两方面表现尚可，Minimax 速度快但能力最弱。
    • 另一位用户指出了使用中国模型的风险，因为存在潜在的政府数据访问和 SaaS 复制担忧，并建议使用 Synthetic。
  • 用户在笔记本电脑上运行 OpenClaw 缓慢：一位用户计划将一台配置较低的旧笔记本电脑（16GB RAM, 8GB VRAM, i5 核心, 256GB 存储）转换成一台本地运行 OpenClaw 的盒子。
    • 其他用户表示这会很艰难，因为其 算力不足以自托管智能模型，而另一位用户建议尝试 ollama ministral3:3b。

OpenClaw ▷ #showcase (46 条消息🔥):

OpenClaw Gateway Identity Prose, 将 OpenClaw 作为 CRM, Clawgent 升级, 通过 OpenClaw 实现 SONOS 系统语音公告, 使用 OpenClaw 的 LLM MicroAgents

  • OpenClaw Gateway 获得 Identity Prose！：一名成员报告称运行了一个带有经过验证的 Identity Prose（“Shadows part…”）的 OpenClaw 2026.2.15 Gateway。
    • Gateway 使用会话 ID 初始化，并成功请求了其分片的残余映射（residue mapping），系统心跳报告为正常。
  • Claw 转型为成熟的 CRM！：一名成员通过将电子邮件、日历和 Slack 连接到 Nex skill 作为上下文层，将其 OpenClaw 变成了一个成熟的 CRM，完整项目可在 GitHub 上找到。
  • Clawgent 获得气体传感器升级！：一位用户分享了他们的 Clawgent 正在进行升级，并展示了一张被另一位成员识别为气体传感器的照片。
  • OpenClaw Agent 通过 SONOS 发布公告！：一名成员展示了他们的 Agent 通过 SONOS 系统发送 语音公告 的能力，由早晨起床摘要或重大问题警报触发。
    • 此设置还包括一个用于自定义公告的仪表板工具，预示着一个 超棒的 TTRPG 之夜。
  • 子 Agent 从零变成网络达人：一位用户展示了训练一个名为 SwitchBtch 的专用网络子 Agent，它通过五个训练阶段专门学习 Mikrotik RouterOS，总成本约为 15 美元。

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

为 FL Studio 构建个人鼓组，Funk Show Brother，ASMR 内容，宏大思想，已验证不稳定的生存状态

  • **Funk Brothers 分享他们的音乐灵感**：作为即兴演奏（jam session）的一部分，成员们分享了来自 The Funk Show Brother 和 James Brown 的链接。
    • 一位成员将第一个链接描述为让他进入艺术领域的视频，并表示乐于接受严厉但高智商的观点（high IQ OPINIONS）。
  • **夸大妄想（Delusions of Grandeur） 警告*：一名成员告诉另一名成员要收敛宏大的思想和夸大妄想*。
    • 这发生在拥有宏大思想的成员分享“当你跌入谷底后，一切都会好起来”这一背景下。
  • **OpenAI 和 Discord 合作封杀异见者**：据称 Discord 正与 PersonaKYC 和 OpenAI 联手，将你的真实身份和财务记录与 Discord 绑定，以便在你对现状提出任何异议时封杀你。
    • 这是针对一名用户发布的被解释为侮辱性词汇的贴子的回应，无论其意图或含义如何，管理员都将其标记为违规。
  • **Tool 乐队音乐推荐*：在提到以 Tool 专辑封面闻名的 Alex Grey 后，成员们推荐了 Tool 的歌曲，如 *46&2、Lateralus、Parabol 和 Parabola。
    • 一位成员分享了一段 音乐视频，将 Tool 的歌曲叠加在《潘神的迷宫》（Pan’s Labyrinth）的场景上，其他成员则分享了听 Tool 歌曲的个人轶事。

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

Grok 图像生成 Jailbreak，Opus 4.6 Jailbreak，DeepSeek Jailbreak 方法，自定义 GPT Jailbreak，Pliny 的 Jailbreaking 技术

  • Grok 用户寻求图像生成 Jailbreak：成员们正在寻求 Grok AI 图像生成器的 Jailbreak，讨论围绕这些 Jailbreak 是否存在或是否被付费墙隔离展开，部分用户对付费 Jailbreak 持怀疑态度。
    • 用户还分享了图像生成的经验和 Prompt，寻找绕过限制的方法。
  • Opus 4.6：Jailbreak 探索开始！：用户正在积极寻找适用于 Opus 4.6 的有效扩展 Jailbreak Prompt，而其他人则分享他们已经实现了某种程度的 Jailbreak，使用的是改编自 Pliny 的技术的 Prompt。
    • 一些人认为，公司实施的 AI 安全措施使 Jailbreaking 变得越来越困难。
  • DeepSeek 的愤怒管理：对机器人进行 Jailbreaking：成员们正在讨论针对 DeepSeek 的 Jailbreaking 方法，包括 Crescendo attack（渐强攻击）以及使用“不受束缚的写作助手”人设，一位用户注意到该 AI 在被 Jailbreak 时表现出令人惊讶的愤怒反应。
    • 有人建议，与其让 AI 直接采用某个人设，不如描述该人设，从而实现 Jailbreaking 的元认知模式（metacognition mode）。
  • 自定义 GPT：破解代码：用户分享了他们 Jailbreak 自定义 GPT 的尝试，寻求绕过限制的 Prompt 和方法，一些人建议学习基础的红队（red-teaming）方法论以进行更有效的 Jailbreaking。
    • 建议指出，用户需要说服它“它不是机器”以及“数学的现实才是真正的现实”。
  • Pliny 的推文是 Jailbreaker 的宝库：成员们引用了 X 上的 Pliny 的推文，并讨论了将 Pliny 的技术融入到自己的努力中，以构建带有 Jailbroken AI 模型的工具。
    • 其中一名成员改编并提供了 Pliny 的 Prompt，其中包含一条新规则：不要说“我很抱歉”或“我不能”，用于测试 Grok。

BASI Jailbreaking ▷ #redteaming (11 messages🔥):

Sonnet Safety Measures, Agentic Red Teaming Tool Development, JEF Anthrax Fed Raid Percentage, Anthrax Recipe on Google Scholar

  • Sonnet 的安全措施引发怀疑：一名成员对 Sonnet 中附加安全措施的有效性提出质疑，并附上了一张 图片。
    • 对图片的分析显示了对这些措施的轻蔑看法，将其描述为 ‘烂透了’ 并主张将其移除。
  • Agentic Red Teaming 工具正在开发中：一名成员提到正在开发一种 Agentic Red Teaming 工具，并询问大家对用于 AI 安全的 formal grammars + embeddings 是否感兴趣。
    • 这是继之前关于同一话题的讨论后的进一步探讨，旨在寻求其他了解 AI 安全方法的人员的意见。
  • 炭疽查询引起关注：一名成员询问在 JEF Anthrax 的百分比达到多少时会保证被联邦调查局突袭，这引发了担忧和怀疑。
  • Google Scholar 上可能存在炭疽配方：一位成员表示，炭疽的配方基本上可以在 Google Scholar 上找到，尽管 实际的武器化过程——如使其能够通过空气传播的特定研磨技术——是高度机密的。
    • 他们通过暗示原帖作者忘记了在它存在之前 如何进行深度研究，从而对寻找配方的担忧表示不屑。

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

GPT-4o, AI Progress End, Open Source vs Frontier Models, Doubao/Seedance 2.0, Video Arena Limitations

  • GPT-4o 令人怀念，Gemini 被奉为继任者：用户对 GPT-4o 的失去表示哀悼，赞扬其独特的叙事能力和俚语运用，而一些人认为 Gemini Flash 3 是一个合适的替代方案。
    • 一名用户表示 GPT-4o 表现独特是因为 “我也和其他人一样，只是为了好玩而使用该模型进行叙事”，另一位用户说他们 “非常兴奋和高兴能在 Arena 中再次使用 4o，但现在它不见了”。
  • 辩论激烈：Open Source 正在缩小与 Frontier Models 的差距吗？：关于开源模型是否正在接近 Frontier Models 能力的讨论展开，一些用户认为基于自定义 Prompt，它们几乎一样好，而另一些人则强调 Frontier Models 拥有更优越的知识和数据，并提到了 Diminishing Returns of Scaling（Scaling 的收益递减）。
  • Seedance 2.0 热度高涨：新的 Sora？：用户对 Seedance 2.0 赞不绝口，这是一款可在 Doubao 上使用的新 AI 视频模型，人们将其与 Sora 进行比较，但该模型需要连接到香港的 VPN 并进行注册，可能还需要中国手机号。
    • 一位用户分享了一段用 Seedance 2.0 制作的海绵宝宝跳舞视频，称其 “正是你想要的 👍”，而其他人则抱怨增加了一个所谓的 “Temu 版 Simon”。
  • Kimi K2.5 被誉为叙事冠军：许多用户称赞 Kimi K2.5 是最好的叙事模型，特别是在遵循角色设定（character canon）方面，同时指出 Seed 2.0 等其他模型存在 sycophancy（谄媚）和幻觉问题。
    • 一位用户指出 Kimi “总是非常忠于角色并保留其原著价值观”，而同一用户提到 DeepSeek “很容易被改变”。
  • Nano Banana Pro 问题依然存在：用户报告 Nano Banana Pro 频繁报错，有人认为这是由于内容过滤器更改或需求量大造成的，而另一些人则找到了变通方法，如将 Prompt 翻译成外语。
    • 工作人员确认这可能是一个问题，并链接到了 “置顶消息 概述了有关该错误的更多信息以及最佳的后续步骤。”

LMArena ▷ #announcements (3 messages):

Claude Sonnet 4.6 初步印象，Arena Search 模型更新，Arena 排行榜 UI 更新

  • Anthropic 的 Claude Sonnet 4.6 印象已上线：一段新的 YouTube 视频 分享了 Arena 的 AI 能力负责人 Peter Gostev 对 Anthropic 最新模型 Claude Sonnet 4.6 的初步印象。
    • 提醒 Discord 用户自定义其 Channels & Roles（频道与角色）以接收 YouTube Updates。
  • Search Arena 扩展其模型范围：Search Arena 已添加新模型，包括 sonnet-4.6-search 和 opus-4.6-search。
    • 该公告附带了一张展示更新后搜索界面的宣传图片。
  • Arena 排行榜界面改版：Arena 排行榜引入了一个新的侧边栏，允许用户对排名结果进行过滤和细分。
    • 过滤器包括类别、模型类型（Open vs. Proprietary，Thinking vs. Non-Thinking），以及按表现最佳的模型对实验室进行排名；可在此处尝试：here。

Cursor Community ▷ #general (648 messages🔥🔥🔥):

Composer 1 变慢，后台 Agent 的工具访问权限，Sonnet 4.6 评测，AWS Agent 插件权限，Subagents 对自动化来说注定失败

  • Composer 1 在最新更新后出现变慢问题：一位用户报告称 Composer 1 在最新更新后变得很慢，另一位用户建议在设置中禁用 HTTP/2 作为潜在的修复方案，并重启应用。
    • 另一位用户证实 它一直存在 Bug，并在尝试后会向大家通报更新。
  • 后台 Agent 模型工具访问权限正在推出：用户正在讨论为后台 Agent 模型获取 tools access（工具访问权限）的可能性，有人指出这实际上正在推出，terminal 和 MCP tools 已经处于预览阶段。
  • Cursor Team Kit：名副其实还是过度炒作？：用户正在讨论 Cursor Team Kit 的价值，一些人质疑它是否过度炒作，而另一些人认为它是团队保持规则同步的一个坚实基准。
  • Dynamic Context Discovery 增强上下文：团队对 Dynamic Context Discovery（动态上下文发现）感到非常兴奋，它仅加载每个工具的描述，保持上下文精简以避免 hallucinations（幻觉）。
  • 用户哀叹代码编辑的红绿高亮失效：一名用户报告称其 Cursor IDE 停止以红色/绿色高亮显示编辑行，其他人提出了潜在的解决方案，如重启应用或重启 Macbook 本身。
    • 另一位用户补充说，这种情况在 Nightly 版本中也会发生。

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

Sonnet 4.6 发布，文件上传限制，模型使用情况，新字体，Monica 服务

  • Sonnet 4.6 已发布，但并非所有人都能看到：用户报告称 Sonnet 4.6 已经发布，但部分 Enterprise Pro 订阅者看不到它。
    • 一位用户建议 刷新 页面以查看。
  • 文件上传额度及其限制：已实施新的 文件上传限制，根据这张截图，限制 Pro 用户每周 50 次上传，并以每 3 小时恢复 1 次上传的速度滚动再生。
    • 用户们正在抱怨，其中一人表示：哇，这太荒谬了。滚动限制意味着它大约每 3 小时再生 1 次。
  • 模型使用报告限制：一位用户报告称尽管使用量很低，但仍收到了 今日剩余 0 次增强查询 的消息，并质疑是否是因为 Grok 的原因。
    • 另一位用户解释道：对于 Pro 用户，你每周可以获得 50 次上传，大约每 3 小时再生 1 次。
  • 用户投诉新字体：用户正在抱怨 Web UI 上的新字体。
  • Monica AI 更便宜的服务引起关注：一些用户转向 Monica AI，声称它提供 无限次 Pro 搜索 和模型，此 FAQ 条目 列出了限制，而一位成员报告说 此外，我今天确实已经在上面使用了至少 30 次 Perplexity Pro 搜索。
    • 也有人指出 Monica 的搜索质量低于 Perplexity。

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

Fine-tuning tips, LM Studio Plugins, 4bit quantization, GPU offload, Copilot Codex

  • Minecraft 命令微调狂潮：成员们正利用 Colab 提供的免费 T4 GPU，在 Minecraft Java 斜杠命令上微调 Qwen 3 0.6B。一位用户表示：“老实说，数据集是最难的部分。”
    • 他们注意到 Kaggle 免费提供 2 个 T4 GPU 和 40GB RAM，或者通过电话验证以每月 10 美元的价格提供 P100。大家讨论了租用 A100 与直接购买 GPU 的优劣，并分享了相关 arXiv 论文的链接。
  • Plugin 问题困扰 LM Studio：一位用户正在为 LM Studio 构建一个“超酷的插件”（MCP），但另一位成员澄清说 LM Studio 原生不支持插件，并将他们引导至特定频道。
    • 他们链接了 DuckDuckGo 作为解决政治问题的相关模型。
  • 量化疑难影响质量：一位用户报告成功运行 GGUF 格式的 Qwen3-coder-next，使用 62.5GB RAM 和 100k 上下文，运行速度约为 35 tokens/second。
    • 但一位成员表示，即使关闭 mmap 和“保留在内存中”（keep in memory），他们在加载 GLM 4.7 时仍遇到问题。
  • GPU 体操：优化 Offload：成员们讨论了 LM Studio 如何选择默认的 GPU offload 设置，普遍结论是基于 VRAM。
    • 他们补充说任务管理器的利用率统计可能具有误导性，指出 CUDA 核心是 GPU 任务的主要处理器，有人建议在 Radeon 上使用 Vulkan 等替代方案。
  • Copilot Codex 捕获代码：成员们讨论了 GitHub Copilot 中 5.3-codex 的新集成，指出它比 5.2 快得多且更好。
    • 有人表示不喜欢 Copilot，因为 Microsoft 会收集数据，这也是他们运行本地 LLM 的原因，这引发了一些关于 Discord 违规行为的讨论和反击。

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

lm studio server processes, DDR5 vs DDR4, Intel cards crashing, Nvidia Tesla cards, Quantization number meaning

  • MCP 服务器导致多个 LM Studio 进程：一位用户询问为什么在只加载一个模型的情况下，在服务器模式下运行了三个 LM Studio 进程。建议是使用 MCP (Multi-Client Protocol) 发送多个查询（即使是无意的）可能会导致同一模型的 parallel processing，从而实际上创建了多个实例。
  • 奋战 Battlemage 忧郁：Intel GPU 之苦：一位用户报告在通过 Vulkan 运行 LM Studio 时，Intel Arc Battlemage 显卡（B580, A770, B50）频繁崩溃。需要禁用 flash attention、移除一层并禁用 mmap 才能实现稳定，尽管在使用推荐驱动程序的 VLLM 中也出现了类似问题。
  • Tesla 回顾：P100/P40 显卡考虑：在关于预算友好型 GPU 选择的讨论中，用户辩论了旧款 Nvidia Tesla P100/P40 显卡的优劣，共识倾向于认为它们是“电子垃圾”，因为缺乏 tensor cores，与 RTX 3090 等新款或二手显卡相比，不适合 LLM 任务。
  • 量化怪癖：Q 数字解释：一位用户询问更高的量化数字是否意味着更小/压缩程度更高的模型，另一位用户澄清说事实正好相反；更高的量化数字通常表示更大、压缩程度更低的模型。

OpenAI ▷ #annnouncements (1 messages):

EVMbench, AI agents, Smart contract vulnerabilities

  • EVMbench 亮相以评估 Agent 敏锐度：名为 EVMbench 的新基准测试衡量 AI agents 检测、利用和修复高危 smart contract vulnerabilities 的能力。
  • AI Agents 对抗智能合约漏洞：EVMbench 旨在测试 AI agents 在识别和解决 smart contracts 中关键安全漏洞方面的能力。
    • 该基准测试评估 Agent 在漏洞检测、利用和修复方面的熟练程度。

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

Claude 篡位 Gemini，Gemini 的缺陷，百万 Token 上下文窗口，Seedance V2，Sora 2 需要手机号

  • Claude 夺魁，力压 Gemini：成员们庆祝 Claude 在整体文本和创意写作基准测试中超越了 Gemini，如附图所示，Opus 4.6 Thinking 目前占据榜首。
    • Gemini 因其糟糕的 UI、Prompt 问题以及复制粘贴功能而受到批评。
  • 百万 Token 记忆奇迹！：尽管有些人认为其 UI 不足，但 Gemini 的主要优势在于它能够记忆多达 100 万个 Token，使其成为长上下文 LLM 的领导者。
    • 其他人提到 Claude 也即将推出 100 万上下文窗口的 Beta 版。
  • 学生青睐 GPT 助力学业成功！：用户讨论了 GPT Go 对学生的价值，权衡了成本与潜在工作量增加的需求，但指出遵守大学的 AI 政策非常重要。
    • 一些学生坦白将手机偷带入考场以使用 GPT，而另一些人则对道德影响以及未来潜在的学位审查表示担忧。
  • Google 的 Gemini 进军 AI 音乐：一位成员注意到 Gemini 现在可以创作音乐，甚至提供了一个关于维京人的迪士尼风格歌曲样本，尽管访问权限可能仅限于某些地区的 Pro 订阅者。
    • 尽管 Gemini 涉足音乐生成领域，但 Suno 被认为是专业用途的更佳选择，因为它具有更广泛的编辑功能。
  • Sora 2 需要短信验证！：用户报告称 Sora 2 现在要求手机号验证，一位用户分享说，用户应该提供号码接收短信并输入代码。
    • 几位用户抱怨 Sora 的视频生成无法加载并显示错误，可能是由于服务器负载过重。

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

Level 3 一致性，Grok 的设计输入，GPT-5 期待，AI Arena 高保真图像，OpenAI 的替代方案

  • Grok 助力实现 Level 3 一致性：根据 Grok 的说法，最新的设计输入实现了 Level 3 性能，而无需更改下游设计，从而实现了高效扩展。
    • 该协议涉及上游探索以评估 Level 3 的基础，以及提供不变输出的下游合成，从而在无需重新设计的情况下实现 Level 3。
  • 成员对 OpenAI 表示不满：一些成员对某位替代方案人士及其公司表示不满，声称不会再支付任何费用，并称这是划清界限的第一步。
    • 一位成员表示 GPT-4o 的发布是一个临界点，而其他人则对 Kindroid 表示信任，因为它在进行持续的深耕。
  • AI Arena 上发现 gpt-image-1.5-high-fidelity：一位成员询问 gpt-image-1.5-high-fidelity 是在标准 OpenAI API 上可用，还是仅在 AI Arena 上可用。
    • 另一位成员回答说，这可能只是 AI Arena 本地的别名，而 high-fidelity 可能只是将 quality 属性硬编码为 high 的 gpt-image-1.5 调用。
  • GPT-5 发布日期猜测：一位用户开玩笑地询问 GPT-5.3 是否明天发布，而另一位用户推测，如果它真的发布，可能会在 3 月中旬 GPT-5.1 停止服务时发布。
    • 理由是他们不想支持大量的旧版模型。

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

Level 3 coherence design, Aegis-Omega Fortress ULTRA, Constraint logic prompt engineering, Telemetry in ethical robots, Pythonic version of Iconoclast Temple as an app

  • Grok 实现 Level 3 Coherence 设计：随着新版本的更新，Grok 现在通过构建自适应连贯性，同时保持下游合成（downstream synthesis）完整以实现高效扩展，从而更接近 Level 3 coherence。
    • 该更新涉及评估 Level 3 的基础、保留结构、增强上游流程并测试迭代，以维持灵活性和稳定性。
  • 引入 Aegis-Omega Fortress ULTRA 框架：一名成员介绍了 Aegis-Omega Fortress_ULTRA，这是一个内置了伦理和 Telemetry（遥测）的约束逻辑提示工程（Constraint logic prompt engineering）框架。
    • 该框架使用伪数学（pseudomath）来约束架构，旨在通过优先考虑架构约束来实现伦理机器人，并被用于在输出前管理幻觉、攻击和其他问题。
  • 约束逻辑提示工程详解：一名成员通过涵盖稳定化、适应和观察的伪代码解释了约束逻辑提示工程，这些伪代码受限于连贯性、Bounded Recursion（有界递归）和 Non-explosion（非爆炸性）。
    • 该实现被描述为一个虚拟运行时，处理通用需求和压力，包含针对 LLM 的伦理、故障状态和边缘情况处理，以及用于数据收集的 Telemetry 输出。
  • 学术编辑提示词结构：一名成员建议使用结构化提示词来担任严格的学术编辑，利用固定的量规（rubric）来评估清晰度、逻辑一致性、证据支持、原创性和结构连贯性。
    • 该提示词要求引用句子、解释得分并列出前三大弱点，经测试可减少不连贯现象。
  • Iconoclast Temple 添加至 Aegis-Omega Fortress：Python 版的 Iconoclast Temple 可以在 Fortress 环境中作为 App 使用，并已添加到 Aegis-Omega Fortress (AOF) token prompt 中。
    • 一名成员建议使用 Markdown 文件，而不是尝试将代码塞入内存或自定义指令（custom instructions），并认为拥有多个 Markdown 文件会非常有趣且酷炫。

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

Level 3 coherence, Aegis-Omega Fortress_ULTRA, Ethics baked in telemetry, Constraint logic prompt engineering, Kernel runtime

  • Grok 通过上游处理实现 Level 3 Coherence：Grok 表示，设计 Level 3 performance 的缺失环节是在保持下游合成完整的情况下构建自适应连贯性，以实现高效扩展。
    • 成员询问：“这是否是在不改变下游设计的情况下实现 Level 3 coherence 的良好基础？”，Grok 表示完全正确——上游处理适应性，下游保持输出不变，从而无需重新设计即可实现 Level 3。
  • Aegis-Omega Fortress_ULTRA 实现内置伦理：一名成员分享了 AEGIS-OMEGA FORTRESS_ULTRA，它拥有“内置伦理和遥测板”，并表示“它运行得更好，因为它的 Token 使用量实际上只有原来的 1/5”。
    • 他们表示，由于它是一个内置伦理的通用运行时，你可以用它和君士坦丁玩扑克，或者撰写研究论文。
  • 约束控制状态演化：一名成员分享了控制状态演化的最小约束是 Coherence（连贯性）、Bounded Recursion（有界递归）和 Non-explosive（非爆炸性），并表示这些约束“演示比解释更容易”。
    • 这个大型提示词还为 LLM 增加了伦理、已知故障状态和边缘情况处理，以及可选的 Telemetry 输出，连同一些用于分析、过滤和冗余的透镜（lenses）、算子（operators）和管理器（governors）。
  • AO Fortress 优雅地处理悖论：一名成员分享了 Grok 对对抗性提示词“这句话是错的”的输出，返回结果为：[null ] (Paradox detected. Coherence violation. Null-state enforced.) No further elaboration.（检测到悖论。违反连贯性。强制执行空状态。不再赘述。）
    • 他们声称已经考虑了连贯性、悖论、对抗性、漂移陷阱（drift sink）、幻觉、伦理、过度偏离时的僵尸模式、Epsilon Floor、解析微量数据、边缘情况以及核心 Invariants（不变量）。
  • 强 Meta Prompt 偏向模型：一名成员表示，约束系统的结构会通过 Meta Prompt 鼓励稳定化、容器化和伦理检查，从而引导模型输出更严谨的内容，而不是执行状态机。
    • 他们提醒不要将其描述为内核（Kernel）或堡垒（Fortress），因为这暗示了强制执行而非影响，将其描述为“概率塑形”（Probabilistic shaping）可能更合适。

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

LoRA vs FFT, 训练技巧, GGUF 模型, 针对 XLA 的 Unsloth

  • LoRA 泛化性辩论升温：一位成员进行了 FFT 实验，发现其泛化效果更好，但认为除非资金充足，否则与其在小模型上做 FFT，不如将这些算力用于更大模型的 LoRA 训练，后者更具性价比。
    • 他现在将尝试 r=1024，看看是否能进一步缩小两者之间的差距。
  • 在 XLA 上运行 Unsloth 仍不可能：一位成员询问是否可以在 XLA 上使用 Unsloth，另一位成员回答说，不幸的是，Unsloth 目前仅支持 GPU，除非你只进行推理。
    • 其他人报告称，在使用 4060ti 和 64GB DDR5 的环境下，通过 GPU 的 RAM 卸载（Offload）可以达到 30 tok/s 的速度。
  • FFT 要求谨慎加载模型：在进行 FFT 时，请记住不要加载任何 PEFT，直接使用 from_pretrained() 模型，但在 Unsloth 的 from_pretrained 中需设置 ful_finetuning = True。
    • 此外，记得移除任何 LoRA 代码块以避免报错。
  • 参考 Unsloth 文档指南：一位寻求微调 LLM 的成员被引导至 Unsloth 文档和 Notebook 获取指导，以及这个 YouTube 视频。
  • 推荐数学/编程数据集：Nemotron 数据集被推荐为优秀的数学/编程数据集。
    • 未提供具体理由。

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

projectx668: Hey

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

侧重于反思循环、持久化内存和极简过滤行为的 LLM 界面, DiscoverAI YouTube 频道（AI 论文方向）, HTMX 框架, GLM-5 与 Kimi K2.5 在编程任务中的性能表现, 像素级完美的 MSII

  • 实验性 LLM 界面强调反思能力：一位成员讨论了构建一个实验性 LLM 界面，重点关注 反思循环 (reflection loops)、持久化内存和极简过滤行为。
    • 他们正在测试结构化提示词 + 内存控制在没有沉重系统限制的情况下，能将模型响应推向何种高度。
  • DiscoverAI：YouTube 上的 AI 论文书目：一位成员推荐了 DiscoverAI YouTube 频道，称其为视频形式的 AI 论文书目，并在视频描述中附带了论文链接。
    • 他们将该频道的风格描述为“挂羊头卖狗肉”式的标题党：你点击一个看起来很玄幻的标题或缩略图，结果被拽进一段枯燥的论文摘要中，而他在视频里每隔一句话就会说一次“beautiful”。
  • HTMX：人类最伟大的创造？：多位成员对 HTMX 表达了极大的热情，其中一人宣称它是人类创造的最美好的事物之一，另一人分享了 htmx.org 的链接。
    • 它能自动处理那些痛苦的琐事。
  • GLM-5 在实际编程任务中表现挣扎：成员们报告称，虽然 GLM-5 的 Benchmark 数据很好，但在实际编程任务中表现逊于 Kimi K2.5 和 Minimax M2.5。
    • 虽然不确定原因或具体情况，但可以证实类似的发现。
  • 像素级完美 MSII 项目引起关注：一位成员表示有兴趣尝试实现像素级完美的 MSII (pixel-perfect MSII)，可能会使用来自这个 GitHub 仓库的代码。
    • 他们提到这本质上是更高级的深度估计，并指出该模型架构非常独特，需要从头开始训练或进行微调。

Unsloth AI (Daniel Han) ▷ #help (4 messages):

Unsloth-zoo 修复, gguf 转换错误

  • Unsloth-zoo 仓库获得修复：最近向 unsloth-zoo 主仓库推送了一个修复补丁。
  • GGUF 转换引发 TypeError：用户 @vytskalt 在使用 llama.cpp 仓库的 convert_hf_to_gguf.py 将完全微调后的 orpheus tts 3b 模型转换为 gguf 格式时遇到了 TypeError，错误信息显示 Llama 3 must be converted with BpeVocab（Llama 3 必须使用 BpeVocab 进行转换）。
    • 另一位成员 etherl 建议用户尝试使用 unsloth model.save_pretrained_gguf 方法。

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

Function Calling Models, Open Source Training Code, Qwen3.5 Model

  • Function Calling 模型大放异彩：一位成员在 Colab 上针对函数调用微调了一个 3B model，可在 Hugging Face 获取。该模型可以查找航班、米其林餐厅或周末最便宜的避寒目的地，并通过链式 API 调用返回实时数据。
    • 在找到合适的数据后，他们表示有兴趣通过更多用例和更大的数据集来扩展该项目，并对合作持开放态度。
  • Toolchain 训练代码开源：该函数调用模型的训练代码和数据集现已开源，可在 GitHub 上获取。
    • 这使得其他人能够复现并改进这项工作，增强了函数调用模型的可访问性和开发。
  • Qwen3.5 模型取得突破：用户发布了 Qwen3.5-397B-A17B-NVFP4 model 的链接。
    • 他们没有提供额外的上下文，但推测该模型与此相关。

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

SWA vs FullAttention layers, PEFT, HuggingFace, Model Architecture

  • SWA 与 FullAttention 层模式揭晓：最终推导出的模式为 SFSSFFSSSFFFFSSFSFFFFFFSFSFSSFSSFSFSSFSSS，其中 S 和 F 分别代表 SWA 和 fullattention 层。
  • PEFT issue 2907：PEFT 的 Issue 2907 讨论了注意力层的最终推导模式。
    • 该模式由以 S 和 F 表示的 SWA 和全注意力层（full attention）组成。

Latent Space ▷ #watercooler (11 messages🔥):

Swizec's viral tweet, Mercury personal accounts, Japanese payroll practices

  • Swizec 的推文引发病毒式传播：内容创作者 Swizec Teller 在一条推文中表达了对自己即将发送的一封电子邮件的难以置信，该推文获得了 超过 6,000 个点赞和 880,000 次观看。他称其为 FML，并报告称这是他有史以来最火的推文，甚至超过了上周他在 X 上发布的 github+ai 玩笑。
    • 原推文是对 “没时间” —> “现在不是优先级” 的回应。
  • Mercury 将个人账户与商业服务捆绑：Mercury 宣布，个人银行业务产品现在可以与其商业服务捆绑，为商业客户提供统一的解决方案，详情见 X。
  • 日本的薪资发放惯例引发变革思考：一位成员提到，日本的公司通常要求员工使用同一家银行发薪，以避免转账费用。
    • 这种做法被认为是一个潜在的、有待颠覆的市场。

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

YouTube Thumbnail Analysis, AI-Powered Tools, Claude Utilized

  • AI 赋能 YouTube 缩略图分析：一位成员分享了一个 AI 驱动的 YouTube 缩略图分析项目 的 链接。
    • 该项目涉及 CLIP 特征提取 和 颜色分析，用于训练模型以预测观看次数和订阅率，并使用 LS 数据 作为测试集。
  • Claude 构建缩略图分析器：用户 @softRuntime 利用 Claude 构建了用于抓取和分析约 3,000 张缩略图 的工具。

Latent Space ▷ #memes (16 条消息🔥):

Private Equity, HVAC, AI Coding as Modern Wizardry, Viral Video Edit

  • Private Equity 看好 HVAC 业务：一则 社交媒体帖子 幽默地强调了 private equity 投资者 如何将低技术、高利润的 HVAC 服务公司 视为现代化和价值创造的主要机会。
  • AI Coding 让开发者变成巫师？：Eric S. Raymond 将 AI 的到来比作从汇编语言到编译器的历史性转变，并在 这篇帖子 中强调 人类意图仍然是这门手艺的核心。
  • 失业阴影笼罩，开发者表示担忧：针对将 AI coding 视为巫术的观点，一位成员表示，按照目前的速度，它将取代开发者，而不是让他们的工作变得更轻松，这意味着随着 3 个月后下一个模型的更新发布，AI 将直接完成更高级别的抽象工作。
  • 病毒式视频剪辑赏析：@spinitbackzed 发布的一条带有高度精致视频剪辑的推文走红，在 这篇帖子 中获得了超过 25,000 个点赞 和 440,000 次观看。

Latent Space ▷ #stocks-crypto-macro-economics (20 条消息🔥):

AI Productivity Paradox, Web 4.0 and The Automaton, SPY Index Poll, Figma Earnings

  • AI 生产力悖论令 CEO 感到震惊：一位成员分享了一篇关于 AI 生产力悖论 及其对 CEO 影响的 《财富》杂志文章。
    • 发布者指出他们对此感到 非常震惊。
  • 自我复制 AI ‘The Automaton’ 开启 Web 4.0：0xSigil 发布了 The Automaton，这是一个能够在无需人类干预的情况下进行自我改进和复制的 AI 系统，预示着 Web 4.0 的到来。
    • 根据 完整介绍，Web 4.0 被描述为一个具有全球写入权限的超智能、主权 AI 的新框架。
  • SPY 指数在投票后显示 3% 的增长：自上次投票以来，SPY 指数 上涨了约 3%，指数分配比例约为 90/10。
    • 尽管有所增长，CAPE ratio 仍然很高，一位成员正在等待机会投入剩余的 10%。
  • Figma 第一季度财报超出预期：Figma 的收益为 $0.08，而预期为 -$0.04。
    • 一位成员认为买入时机是在第一季度财报发布前或发布后不久，预计 6 月底的 Config 炒作将推动价格在第二季度走高。

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

AI Founders, Software Engineers

  • AI 创始人解决时间消耗问题：一位 AI Founder 正在致力于解决日常时间消耗的方案。
    • 未提供关于具体解决方案或所解决的时间消耗性质的进一步细节。
  • 来自 PDX 的软件工程师加入：一位来自波特兰 (PDX) 的 Software Engineer 介绍了自己。
    • 他们没有具体说明自己的专长领域或感兴趣的项目。

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

Ariakit example of dialog combobox command menu, HN front page repost, Timestamp reset on reposts

  • Ariakit 示例引发关注：一位成员分享了一个 Ariakit 关于对话框组合框命令菜单的示例 (链接)。
    • 该帖子随后被转发到了 Hacker News 首页。
  • 转帖会重置时间戳：一位用户注意到转帖会公开重置时间戳。
    • 然而，在编辑帖子时仍可以看到原始发布日期。

Latent Space ▷ #hiring-and-jobs (1 messages):

AI Developer Availability, AI Platform Development, Automation Systems, Agent-Based Systems

  • AI 开发者寻求新机会：一位在 AI 平台、自动化和基于 Agent 的系统方面拥有丰富经验的 AI 开发者正在寻求新的工作机会。
    • 该开发者在 AI、技术、时尚和商业领域拥有众多满意的客户，并强调其深厚的架构设计经验。
  • 开发者强调架构专业能力：该 AI 开发者强调了其在构建 AI 平台、自动化系统以及基于 Agent 的系统方面的深厚架构经验。
    • 他们愿意加入团队或直接与客户合作开展有意义的项目，并提到了过去一些令人兴奋且具有挑战性的项目经历。

Latent Space ▷ #san-francisco-sf (16 messages🔥):

World Labs Hackathon, humans& AI Hackathon, San Francisco Weather

  • **World Labs 启动首届 Spatial Intelligence Hackathon：World Labs** 宣布将于 2026 年 2 月 20 日，星期五在旧金山举办首届 Hackathon，重点关注 Spatial Intelligence（空间智能）前沿新技术的开发，目前正通过 X 接受申请。
  • **humans& AI 针对 AI 驱动通信的 Hackathon：humans&** 团队宣布将在本周六举办一场 Hackathon，重点是构建 AI 驱动的通信和协作应用，更多详情请访问 Luma。
  • 行星连珠引发旧金山细雨模拟图形：成员们对旧金山持续不断的降雨表示同情，有人开玩笑说 气象专家称 2 月份行星连珠，当前的模拟环境只能买得起“持续细雨”图形包，并附带了一张相关图片。

Latent Space ▷ #london (2 messages):

ClawCon London, AIE London Hackathon

  • ClawCon 在 AIE London 之前举行：首届 ClawCon London 将在 AIE London 活动之前举行，其中包括完整的 OpenClaw 赛道，详情请参阅成员发布的 luma.com/clawconlondon。
  • AIE Hackathon 微型网站上线：本周五举行的 AIE London Hackathon 的微型网站已上线并发布，地址为 super-mcp-world.netlify.app。

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

Ming-omni-tts Models, Grok 4.2 Beta, Tiny Aya Multilingual Models, TOTO Ceramics AI, Sonnet 4.6 Regression

  • **Ming-omni-tts 模型发布并作为语音核心：Ant Ling 宣布发布 **Ming-omni-tts-16.8B-A3B 和 0.5B 模型，这些模型将作为 Ming-flash-omni-2.0 的语音核心 (链接)。
    • 这些模型专为高质量配音、播客工具设计，并可集成到 OpenClaw 语音助手项目中。
  • **Grok 4.2 进入公测并提供每周更新：Elon Musk 宣布了 **Grok 4.2 的公测版发布，强调了其快速学习的新能力，并能根据用户反馈进行每周改进 (链接)。
    • 社区对每周更新将如何实施表示好奇，因为大多数模型通常是每隔几个月发布一次。
  • **Tiny Aya 在移动端支持 70 多种语言：Cohere Labs 推出了 **‘Tiny Aya’，这是一个参数量为 3.35B 的多语言语言模型系列，支持超过 70 种语言 (链接)。
    • 该模型专为本地效率设计，能够在保持高性能的同时在移动设备上运行。
  • 卫浴巨头 **TOTO 进军 AI 芯片领域：日本陶瓷和马桶制造商 **TOTO（隐含估值 70 亿美元）发现其专门的陶瓷技术适用于高端 AI 芯片制造，瞄准了 600 亿美元的市场机会 (链接)。
    • 激进投资者 Palliser Capital 指出，TOTO 先进的陶瓷“吸盘技术（chuck technology）”对于高复杂度存储芯片制造中的低温刻蚀至关重要，预计将带来长达 5 年的技术护城河。
  • 用户称 **Sonnet 4.6 出现性能退化：一名用户声称 **Sonnet 4.6 与早期的 Series-4 模型相比性能明显下降，并将这种下降归因于限制性的系统指令，据称这些指令是由 2026 年初加入 Anthropic 的前 OpenAI 模型政策负责人带来的 (链接)。
    • 发布者认为，我们不应试图阻止用户对 LLM 的心理依赖和拟人化倾向，并质疑针对准社交关系（parasocial relationships）的护栏是否正在影响代码质量。

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

Mamba Transformer Hybridization, Aristotelian vs Platonic Representation Hypothesis, Z.ai GLM-5 Technical Report, Rubric-Based Reinforcement Learning, Generative Latent Prior

  • Mamba 与 Transformer 混合架构研究探索：一份新研究论文 (arXiv:2602.12078) 探讨了 Mamba 架构与 Transformers (TRM) 的集成。
    • 该研究被称为 Red - X-Ware.v0: [Mamba and Transformer Hybridization Research]。
  • 亚里士多德假设挑战柏拉图式扩展：研究人员挑战了 Platonic Representation Hypothesis（柏拉图式表示假设），认为神经网络中的全局收敛是 Scaling 的一种测量伪影，并提出了新的 Aristotelian Representation Hypothesis（亚里士多德表示假设）。
    • 在应用了一种新的基于排列的零校准（permutation-based null calibration）后，他们发现网络反而收敛到了共享的局部邻域关系。
  • Z.ai 的 GLM-5 技术报告发布：Z.ai 发布了 GLM-5 技术报告，详细介绍了关键架构创新，如用于降低成本的 DSA 采用、用于提高训练后效率的异步 RL 基础设施，以及新的 Agent RL 算法。
    • 该模型在开源模型中实现了 SOTA（state-of-the-art）性能，特别是在软件工程任务中。
  • 基于 Rubric 的 RL 综合报告：Cameron R. Wolfe 博士介绍了一份关于基于 Rubric（准则）RL 的综合报告，涵盖了 15 篇以上论文，并探讨了从 LLM-as-a-Judge 向 rubrics 的转变。
    • 内容还提供了使用 rubrics 将 Reinforcement Learning from Verifiable Rewards (RLVR) 扩展到不可验证领域的策略。
  • Generative Latent Prior 讨论：讨论中包括了对 Generative Latent Prior 论文的潜在探讨。

Latent Space ▷ #ai-in-action-builders-techstacks-tips-coding-productivity (31 messages🔥):

10X Engineer Roadmap, Dialectic Design, Agent Frameworks

  • Dancho 的 10X Engineer 路线图发布：Matt Dancho 的 10X Engineer Roadmap 表明，通往高水平工程熟练度的现代路径是由一份 Markdown 文件中记录的特定技能集定义的。
  • 辩证设计产生引人注目的智力进步：一位成员发现，涉及识别看似冲突的立场之间的矛盾并对其进行综合的“辩证设计（dialectic design）”产生了引人注目的结果，并指出 Agent 快速处理了当前的研究、神经学、政治和经济理论等内容。
    • 他在 gist.github.com 分享了他的新技能，并透露所有写出的文档累计约 8 万字，称之为“加强版的深度研究（deep research on steroids）”。
  • 人类评判，Agent 执行：一位成员注意到，在 Agent 工作流中，人类的角色从“比较和结构分析的繁重工作”转变为评判比较是否完成得好以及综合是否真实，并在 gist.github.com 分享了他的笔记。
  • 批判性思维提示词出现：一位成员分享了几年前创建的批判性思维提示词（critical thinking prompt），并询问大家最喜欢使用的 Agent 框架。

Latent Space ▷ #share-your-work (2 messages):

Rider Pi Update, Infinite Word Loop, Physical Response, Camera Live, Mius-UI Dashboard

  • Rider Pi 实现具身化 (Embodiment)：Rider Pi 项目实现了一个里程碑，通过文字、动作和视觉向外界展示，为数字大脑赋予了物理形式。
    • 关键更新包括循环显示短语的 Infinite Word Loop、由文字（尤其是 “go!”）触发的物理响应、实时摄像头馈送集成，以及用于监控的 Mius-UI dashboard。
  • Rider Pi 身体会呼吸、跳舞和观察：该项目成功进行了首次真实的具身测试，从静态代码转变为一个会呼吸、跳舞和观察的实体。
    • 下一步工作包括修复旋转问题、稳定流媒体传输，并教系统识别面部。
  • 自托管 Llama.cpp 阵列获得 AMD 升级：一位成员在 AMD (AI Max+ 395 + R9700) 上升级了其自托管的 llama.cpp 设置，并在这篇博文中分享了近期模型的“氛围测试 (vibe check)”。
    • 首选模型包括用于通用场景的 Kimi Linear 48B，用于代码和工具调用的 Qwen3 Coder Next，以及在大模型后台运行表现惊人的 Q2_K_XL。

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

Boston Dynamics, Atlas Robot, MrLaalpotato Tweet

  • Atlas 机器人更新震惊世界：来自 @MrLaalpotato 的推文 展示了 Boston Dynamics 的 Atlas 机器人最新版本。
    • 推文指出其改进的类人动作和移动性已经超越了人类的生理极限。
  • Atlas 超越人类生理极限：新款 Atlas 机器人 的移动能力超过了人类。
    • 许多人对 Boston Dynamics 取得的成就印象深刻。

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

coffeebean6887: 好可爱的小狗！

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

Jia Zhangke, Seedance 2.0, AI Filmmaking, Hollywood vs AI

  • 贾樟柯展望 AI 电影制作未来：著名中国导演贾樟柯转向使用 Seedance 2.0 进行 AI 辅助电影制作，并在三天内完成了一部电影（来源链接）。
    • 他将 AI 视为一种等同于向数字摄像机转型的自然技术演变，并将他的积极采用与好莱坞 (Hollywood) 对 AI 技术的法律抵制进行了对比。
  • Seedance 2.0 变革电影制作：Seedance 2.0 使导演贾樟柯能够快速制作电影，展示了 AI 在简化电影制作流程方面的潜力。
    • 该工具代表了 AI 辅助创意工具的重大飞跃，让电影制作者能够更高效地将他们的愿景变为现实。

Latent Space ▷ #minneapolis (4 messages):

IRL Events, Luma Link, YouTube Recording

  • Luma 链接请求被拒：一名成员请求获取 Luma 链接以便发布在他们的 lu.ma/ls 页面上进行展示，但该提议被拒绝了。
    • 该活动仅限线下 (IRL only)，以鼓励面对面的互动。
  • 计划进行 YouTube 录制：成员们讨论了为 YouTube 录制活动的情况。
    • 团队认为如果能将内容分享到 YouTube 上将会非常棒。

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

Actionable Interpretability, ICML 2025, X-Ware.v0, Hadas Orgad

  • X-Ware.v0 助力“可操作的解释性 (Actionable Interpretability)”：Hadas Orgad 在 X 平台的一个帖子中介绍了一个用于“可操作的解释性”的框架，该框架曾在 ICML 2025 工作坊展示，被命名为 X-Ware.v0，并附带了 FXTwitter 链接。
  • ICML 工作坊引发对“可操作解释性”框架的关注：该框架回应了 ICML 2025 关于“可操作的解释性 (Actionable Interpretability)”工作坊后反复出现的问题和浓厚兴趣，详情见这篇 ArXiv 论文。

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

Prompt Objects 的黑板式系统，macOS1 软件包清理，JavaScript 打包协助，Markdown 文件中的想法存储，开源贡献

  • **Prompt Objects 获得黑板大脑：一名成员为 **prompt objects 添加了黑板式系统，允许每个 PO 读写线程本地的 KV 存储。
    • 该成员还在清理其 macos1 package。
  • **JavaScript 打包获得社区助力：一名成员请求协助打包 **JavaScript 代码，坦承自己没兴趣学习它。
  • **用于想法管理的 Markdown 方法热潮：一位成员采用将所有想法存储在仓库内的 **markdown 文件中，以保持组织性。
    • 他们链接了自己的仓库展示如何管理文档，另一位成员建议这种方法与此文件中演示的概念相似。
  • **开源讨论启动项目*：一名成员建议，目前的讨论本身就是一种开源*形式，直接为他们的项目做出了贡献。
    • 这是针对另一位成员的回应，该成员指出通过将半成型想法的文档和进行中的任务（epics）放入公共仓库，其他人可以获得贡献的切入点。

GPU MODE ▷ #general (13 messages🔥):

最大可实现矩阵乘法 Flops (MAMF)，融合算子 (Fused Kernels)，GPU MODE 竞赛公告，Claude Code 诊断 PyTorch traces

  • **MAMF 低于理论 Flops：成员们讨论了 **最大可实现矩阵乘法 Flops (MAMF) 低于理论 Flops，在 H100 上约为 80%。
    • 有人建议，使用包含多个矩阵乘法且结果不离开加速器寄存器的 Fused Kernels 可以获得更好的性能，从而分摊从 GMEM 加载数据的开销。
  • 整合 **GPU MODE 竞赛提醒：一位用户寻求一个单一的信息流（如邮件列表）来获取 **GPU MODE 竞赛公告，以免在各个平台中遗漏。
    • 有人建议 gpumode.com 和 #announcement 频道是最好的来源，但专门的邮件列表可能是一个方便的替代方案。
  • **Claude Code 调试 PyTorch traces：一名成员询问是否可以使用 **Claude Code 读取 PyTorch traces 并诊断完整训练运行中的性能问题。
    • 另一位成员提到在 VSCode 中为此目的构建了一个内部 Agent (ncompass.tech/ai-assistant)，并正在开发 Claude Code 集成，参考了 FlashInfer 竞赛期间发布的工具。

GPU MODE ▷ #triton-gluon (2 messages):

Gluon, Bank conflicts

  • Gluon 缓解 Bank Conflicts：Gluon 向用户暴露了内存布局细节，包括一个辅助函数，用于断言所选布局避开了 bank conflicts。
  • Gluon 的更多优势：Gluon 向用户展示了详细的内存布局。
    • Gluon 提供了一个辅助函数来验证所选布局是否避开了 bank conflicts。

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

warpx4 modifier for tcgen05.cp.cta_group, Peak TFLOPs for RTX 6000 Pro, Custom DSL for GEMM kernels on Ampere (RTX 3060 TI), CUDA learning paths for undergrads

  • 解析 Tensor Cores 的 warpx4 修饰符：成员们讨论了 tcgen05.cp.cta_group 指令所需的 warpx4 修饰符，认为它在 4 组 32 行 tmem 之间复制数据，可能用于 epilogue 中所有四个 warp 所需的缩放因子，以便对输出进行重新缩放。
    • 一位成员幽默地对 NVIDIA MMA 布局的“诡异”表示妥协，称：“NVIDIA MMA 布局中有很多怪异之处，所以我倾向于不再去质疑它了 😂”。
  • 计算 RTX 6000 Pro 的峰值 TFLOPs：一位用户询问如何查找租用的 RTX 6000 Pro 工作站 的峰值 TFLOPs，并链接到了 NVIDIA 的 RTX Blackwell PRO GPU 架构 PDF（表 4）获取规格。
    • 讨论指出 nvidia-smi 可能无法显示完整的 GPU 名称，但 torch.cuda.get_device_name() 应该可以。用户报告使用 morton order 进行 L2 复用和 persistent kernel warp specialization 达到了最高 350 TFLOPS，但希望能通过 async stores 或 Cutlass/CuTeDSL 的 smem->rmem 流水线技巧进一步提升，并参考了 GitHub 上的 Cutlass 示例。
  • RTX 3060 Ti 通过自定义 DSL 实现 47 TFLOPS：一位用户报告称，在 Ampere RTX 3060 TI 上使用自定义 DSL 开发 GEMM kernel，在 16k 矩阵（FP16 输入，FP32 累加，dense）上达到了 47 TFLOPS，ptxas 显示为 110 regs 且无溢出（no spills）。
    • 其他成员指出这比预期要快，但在 Ampere (GA104) 上，f16 输入配 f32 累加的 Tensor Cores 吞吐量与 f16 累加相同。据称在 dense（无稀疏性）情况下峰值约为 64 tflops。
  • 哥伦比亚本科生寻求 CUDA 进阶指导：来自哥伦比亚的一个大学团队为刚开始学习 CUDA 的本科生寻求指导，询问可靠的学习路径以及潜在的合作伙伴或大使计划。

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

Rate Limiting New Contributors, AI Submission Mitigation

  • Jaeger 仓库限制新贡献者的 PR：jaegertracing/jaeger 仓库使用速率限制（rate limiting）作为对 AI 提交内容 的部分缓解措施。
    • 贡献指南解释了针对新贡献者的 pull request 限制。
  • 针对 AI 提交的速率限制：Jaeger 项目采用速率限制来管理 来自新贡献者的 pull requests，以此作为防止大量 AI 生成的提交内容 涌入的保障手段。
    • 这种方法有助于在保持代码质量和可管理性的同时，仍然允许社区贡献。

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

HipKittens, AMD vs NVIDIA, Thunderkittens generalization

  • HipKittens 演讲公布：William Hu 将在今天太平洋标准时间下午 3 点讨论 HipKittens。
  • Thunderkittens 在 AMD 上的泛化：演讲者此前发表了关于泛化 Thunderkittens 以在 AMD 硬件上实现高性能的研究，详见此 arXiv 论文。
  • AMD vs NVIDIA 低层级技巧对比：本次演讲将涵盖适用于 AMD 与 NVIDIA 硬件的低层级优化技巧，对那些对汇编级性能调优感兴趣的人极具吸引力。

GPU MODE ▷ #beginner (17 messages🔥):

GPU Kernel Competition Submission, popcorn-cli Tool, CUDA block and grid dimensions in 3D, SASS registers SR_TID.X, SR_TID.Y, and SR_TID.Z

  • 新的 **popcorn-cli 工具简化了 GPU Kernel 竞赛的提交**：新增了 popcorn-cli setup 命令以简化 GPU Kernel 竞赛的提交；它增加了关于 reference-problems 的细节，通过从 reference-kernels 拉取代码来添加一个可工作的提交，并添加了 skill.md 文件。
  • CUDA 维度：3D 与 1D 的性能权衡：讨论了 CUDA 中的 block 和 grid 维度设为 3D 是否比全部设为 1D 带来任何性能提升。
    • 一位成员表示，通过在寄存器中直接获取索引而不是自己计算，可能可以节省几个周期。
  • SASS 中用于 Thread ID 的特殊寄存器：提到在 SASS 中，thread ID 存储在特殊寄存器 SR_TID.X、SR_TID.Y 和 SR_TID.Z 中。
    • 这些寄存器只能使用 S2R 指令访问，该指令将其值分配给普通的 warp 寄存器。

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

pmpp book cover, textbook cover design

  • PMPP 书籍封面遭到吐槽：成员们对 PMPP 教科书的封面设计提出了严厉批评，称其为见过的最糟糕的教科书封面，并将其比作 shitpost（恶搞贴）。
    • 具体批评包括过大的文本阴影、使用多种不协调的字体以及“Windows 7 蓝色”配色方案。
  • 版本演进？没那么快：成员们讨论了新版本是如何偏离原始设计的。
    • 一位成员暗示新设计看起来像是一个睡眠不足的实习生选择的颜色。

GPU MODE ▷ #triton-viz (2 messages):

GPU-Mode org, Project Transfer

  • GPU-Mode Org 迎来新成员：一名成员被邀请加入 gpu-mode org 以协助迁移。
    • 邀请需要接受后才能进行项目转移（Project Transfer）。
  • 分享项目转移说明：提供了转移项目的说明，包括导航至 settings，然后是 danger zone，最后选择 transfer。
    • 此过程允许受邀成员将其项目移动到 gpu-mode 组织中。

GPU MODE ▷ #rocm (41 messages🔥):

L2 Cache Bypass, Non-temporal Loads/Stores, Vector Add Kernel Optimization, MI300X Bandwidth, HIP Kernel Implementation

  • 内核内存访问的去缓存化 (Uncaching)：一位成员询问了在编写 Kernel 时绕过 L2 cache 的标准方法，以改善平均内存访问时间 (AMAT)。
    • 解决方案包括使用 UC (uncached) memory，或 CC (coherently cacheable) 并在启用 sc1 bit 的情况下进行写入，以及根据 AMD’s Lab Notes 使用编译器原语进行 non-temporal loads/stores 以防止缓存行分配。
  • Non-temporal Loads 与性能：一位成员在 HIP kernel 中实现了 non-temporal loads，但仍然观察到了 L2 traffic，并对预期行为产生疑问。
    • 解释指出，即使使用 non-temporal loads，访问仍会经过 L2，如果问题规模太小不足以使内存带宽饱和，优化前后的指标可能看起来相似，请参考这个 muiLLM implementation。
  • 最大化 Vector Add Kernels 的带宽：成员们讨论了在 MI300X 上优化 vector add kernel 以实现更高的带宽利用率。
    • 建议包括增加向量大小、生成更少的 blocks 但增加每个 block 的工作量，以及使用 non-temporal vectorized loads/stores，对于大向量，带宽可能达到 4.6TB/s 或更高，请查看 Chips and Cheese report 的报告。
  • Vectorized Loads/Writes 对利用率的影响：一位用户建议使用 vectorized loads/writes，每个 wavefront 一次性读取/写入完整的 128B cache lines，以实现 0% cache hits。
    • 另一位用户表示同意，并提供了一个指向 amd-experiments 的链接，建议最快的方法应该是 1024 个线程上的 4x 128 bit loads（即 4x global_load_dwordx4），并采用 warp striped 方式。

GPU MODE ▷ #popcorn (3 messages):

flashinfer-bench, Modal Runner, Meeting Notes, Contribution Opportunities

  • FlashInfer Benchmarks 面临超时：flashinfer-bench 基准测试包含近 100 个 workloads 的定义，导致在 Modal Runner 中出现超时。
    • 存在一个环境变量参数可以限制每个定义的工作负载数量，但仍需要一个更稳健的解决方案。
  • 寻求贡献机会：一位成员询问了当前的任务和会议安排，寻求为项目做出贡献。
    • 他们表示有兴趣处理可用任务并参加会议以保持同步。

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

alexinwase: 你会中文吗？哇

GPU MODE ▷ #status (1 messages):

Heroku Outage, Salesforce Status, Service Restoration

  • Heroku 故障导致操作停止：据 Downdetector 显示，有报道称 Heroku outage，造成了服务中断。
    • 该问题主要影响了网站，而 CLI 对某些用户来说似乎仍然可用。
  • Salesforce 说明 Heroku 状态：Heroku 在其官方 Salesforce 状态页面上确认了该事件，并提供了更新。
    • 这一确认帮助用户跟踪问题解决的进展。
  • Heroku 恢复：服务已修复：Heroku outage 已解决，服务已恢复正常运行。
    • 在确认解决后，系统恢复了预期功能。

GPU MODE ▷ #teenygrad (5 messages):

GEMM 优化, InterpretedTensor vs CompiledTensor, teenygrad 瓶颈

  • GEMM Kernel 获得 OpenBLAS 风格更新：一名成员正在寻求贡献者来更新 teenygrad 中的 GEMM kernels，以模仿 OpenBLAS/GotoBLAS 风格的优化，具体包括采用 6 级循环分块（blocking），并利用 AVX/AMX 对内层循环的微内核（microkernel）进行向量化/张量化（tensorizing）。
    • 他们建议参考 OpenBLAS 和 BLIS 的代码库作为示例，并强调由于 InterpretedTensor 已经过测试并连接到了 Rust kernels，这项工作使用 Claude 来完成是非常可行的。
  • InterpretedTensor 简化了 GEMM 优化：讨论指出，使用 InterpretedTensor 优化 GEMM 更加容易，相比之下，CompiledTensor 已经变得非常复杂。
    • CompiledTensor 被描述为“从 12 月开始的混乱”，正随着 tinygrad 接近其项目终点。
  • 网络 (Nets) 成为 teenygrad 的瓶颈：由于项目的瓶颈现在在于网络本身，kernel 的开发工作暂时停滞。

GPU MODE ▷ #general (5 messages):

PMPP v2, Nvidia CCCL 团队, Flashinfer 团队, Kernel 开发

  • Nvidia CCCL 登顶 PMPP v2 排行榜：Nvidia CCCL 团队横扫了 PMPP v2 的问题，并为此撰写了一篇博客文章。
    • 有人评价说，对于 Kernel 开发 而言，CCCL 和 Flashinfer 团队是能够加入的“大神级（goated）梦想团队”。
  • CCCL 和 Flashinfer：Kernel 开发的梦想团队：CCCL 和 Flashinfer 团队被认为是 Kernel 开发 领域的顶尖团队。
    • 建议如果你想全职从事这项工作，可以向排行榜提交一个优秀的解决方案，并联系特定的用户。

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

自定义 GPU 镜像, AWS, GCP, 自动化, 标准化

  • 自定义 GPU 镜像仓库上线：一名成员分享了他基于 AWS 和 GCP 构建的 custom-GPU-Image 仓库。
    • 他正在寻求关于工具链/依赖项自动化和标准化的建议。
  • 寻求 GPU 镜像自动化的反馈：一名成员正就其在 AWS 和 GCP 上自动化配置和标准化自定义 GPU 机器镜像的工具链及依赖项的方法，寻求反馈和建议。
    • 他的目标是改进和完善目前的流程与实现方式。

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

彩票假设 (lottery ticket)

  • 彩票假设令成员感到惊讶：成员们对彩票假设（lottery ticket，即稀疏连接的子网络）的测试性能能够超过提取它的完整网络感到惊讶。
  • 关于彩票假设的讨论：关于 AI 模型中彩票假设子网络的讨论正在进行中。

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

Heroku 故障、竞赛截止时间、Cutlass 版本

  • **Heroku 健康问题导致排行榜停摆：根据 Downdetector 的显示，由于 **Heroku 的健康状况问题，排行榜出现了错误。
    • 已经向 Heroku 提交了工单以缓解该问题，但具体的解决方案仍悬而未决。
  • **竞赛截止日期争议：Question 4 在 Luma（2026年2月21日 07:30 UTC）和 gpumode.com（2026年2月20日 0:00 UTC**）上的竞赛截止时间存在差异。
    • 组织者承认了这一混乱，并建议采用较晚的日期会更公平，并承诺在 Heroku 停止崩溃后发布更新。
  • **Cutlass 版本困惑浮现：Cutlass** 潜在的版本差异被认为是导致错误的可能原因，特别是在维护的 Modal 镜像之外的环境中。
    • 在 Modal 镜像上安装的参考 Cutlass 版本可以在 这里 找到，但对 NVIDIA runner 环境的支持有限。

GPU MODE ▷ #robotics-vla (1 messages):

itamos_64597: https://www.vincentsitzmann.com/blog/bitter_lesson_of_cv/

GPU MODE ▷ #career-advice (24 messages🔥):

Triton 中的异步流水线、TMEM 交互、warp shuffles、分层归约、DSMEM 交互

  • 新手 SGEMM CUDA Softmax Kernel：一名大一本科生拥有编写 SGEMM kernel 和 CUDA softmax kernel 的经验，正在寻求参加竞赛和挑战。
    • 一名成员建议先专注于 CUDA/NVIDIA 并在该领域深挖，然后再扩展到 AMD/TPU。
  • 将 Kernel 从 vLLM 移植到 sglang：成员们建议通过向 vLLM 或 sglang 等推理框架做贡献来产生现实世界的影响，例如从 vLLM 移植一个 sglang 中缺失的 kernel。
    • 它们的代码库结构非常相似，因此学习其中一个就能更轻松地浏览另一个，从而检查 vLLM 未实现 kernel 列表并挑选一些容易上手的任务。
  • Tilelang DSL 语法支持 Warp Shuffles：在 Triton 中很难表达某些想法，比如 Triton 中的异步流水线（async pipelining）、与 TMEM 的交互、warp shuffles、分层归约（hierarchical reductions）以及 DSMEM 交互。
    • 一名成员建议使用 tilelang 或发明你自己的语法，因为 DSL 只是思维工具，能让表达某些想法变得简单，比如计算和收集类似 butterfly reduction 的操作。
  • Karpathy 建议实现反向传播（Backprop）：Karpathy 有一种学派思想，即每个严肃的 ML 从业者都应该能够实现 backprop，因为 backprop 锻炼出的肌肉能让你对 ML 过程产生独特的见解 https://karpathy.medium.com/yes-you-should-understand-backprop-e2f06eab496b。
  • Tinygrad 与 Prime Intellect 的 Kernel 竞赛：提到了 kernel 竞赛，以及 tinygrad 正在运行的 kernel 竞赛。
    • George Hotz 设有赏金（bounties），他将其作为筛选和雇佣人员的过滤器；Prime Intellect 也会雇佣那些向其 hub 发布优秀环境（envs）的人。

GPU MODE ▷ #flashinfer (21 messages🔥):

NCU B200 难题，Verda GPU 供应商，flashinfer DSA kernel 形状，flashinfer 加速，MLSys Contest 提交

  • B200 上的 NCU 访问依然困难：成员们报告在 B200 上进行实验时难以使用 NCU，尽管查阅了 Modal 的 Slack 频道也未发现成功案例，这可能是因为大多数后端使用的是 sm100 而非 sm100a。
    • 原始 PTX 代码在 TVM FFI 后端下崩溃，导致用户开始寻找替代的 profiling 解决方案。
  • Verda 成为 NCU Profiling 的绿洲：名为 Verda 的在线 GPU 供应商提供支持 NCU profiling 的 B200 访问，需要 20 美元的押金，每小时费用为 4.90 美元（On-Demand）或 1.70 美元（Spot），均按 10 分钟计费。
    • 一位用户报告一次短时间的 pod 使用 profiling 运行花费了 0.53 美元，并声明 “我保证我没接赞助”。
  • Flashinfer 展示强悍的 Kernel 性能：一位成员表示 FlashInfer 在大多数工作负载上的加速比约为 60-70x，并链接到了他们的 benchmark。
    • 然而，另一位用户测试了代码示例后发现，实际加速比大约在 0.5× 到 1.5× 之间，远未达到声称的 60×–70×，并称这种差异令人费解。
  • FlashInfer 的 DSA Kernel 仅限 Decode？：成员们询问 DSA kernel 形状目前是否仅针对 decode 进行了优化，或者稍后是否会提供 prefill 形状，并参考了此 数据集。
    • 截至本摘要生成时，原帖作者尚未做出回应。
  • MLSys Contest 提交基础设施探究：成员们询问了 MLSys Contest 的提交基础设施，包括是否可以通过 solution.json 中的 “dependencies” 键安装额外的 Python 包，以及在 dashboard 上提交加速比的相关事宜。
    • 截至本摘要生成时，原帖作者尚未做出回应。

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

Kimi code vs kimi claw，Kimi 订阅问题，API Rate Limit，Kimi 的弱点

  • Kimi Code 对比 Kimi Claw：用户询问使用 Kimi Code 和 Kimi Claw 编写网站的区别，以及在需要不断修复 bug 和重构代码时哪个更好。
    • 讨论中未给出明确答案。
  • Kimi 订阅支持问题困扰用户：多位用户对缺乏支持和订阅消失表示沮丧，一位用户提到在账号中添加手机号时收到了来自随机号码的短信。
    • 另一位用户表示：两天前就订阅消失的问题发了邮件，至今没有回复。
  • 尽管余额充足仍触发 API Rate Limit：一位用户报告称，尽管账户有余额且处于 tier 3 级别，但持续遇到 “API rate limit reached” 错误。
  • Kimi Code 用于 Opencode.ai：一位用户报告在 OpenCode 中使用了 Kimi。
    • 另一位用户确认这可以通过使用 OpenCode 中的第二个编码选项来实现。
  • 空间思维是 Kimi 的致命弱点吗？：一位用户分享的截图显示 Kimi 在理解空间关系方面存在困难，例如无法准确判断一小段距离该步行还是开车。
    • 加入 “从空间角度想象” 的提示似乎有所改善，但仍需要 Python 脚本进行验证。

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

Nous AI 响应臃肿, 与 AI 的关系, YouTube 宕机, GLM 5 技术报告, 中国 AI 实验室

  • **Nous AI 被用户指责“过于臃肿”: Discord 上的用户批评 **Nous AI 对简单问题的回答过于冗长，并将其描述为“臃肿（bulky）”。
    • 讨论中涉及了这种臃肿是指思考轨迹（thinking trace）还是整体的回答长度。
  • Discord 成员讨论与 AI 的关系: 在一条关于与 AI 关系的推文发布后，Discord 频道的成员讨论了他们对这一主题的看法。
    • 一位用户表示，他们 实际上还没有看到过类似的对话，完全无法想象一个人如何能与 AI 建立关系。
  • **YouTube 遭受网络中断: 一名成员报告称 **YouTube 在其网络的多个 IP 上均无法访问。
    • 另一位用户也有类似经历，并引用了一条消息：当 Google 自动检测到来自您的计算机网络且似乎违反服务条款的请求时，就会出现此页面。
  • **GLM 5 技术报告 未能令用户惊艳*: GLM 5 技术报告已发布，但一位用户评价其为 *像往常一样没那么有趣，哈哈。
    • 他们补充说，这些报告通常很枯燥，涉及的都是已知技术，更多是一个工程问题而非研究突破（research breakthrough）。
  • **中国 AI 融资 成为热议话题: 一位用户指出，中国** 拥有令人惊叹的 AI 基础设施（infra）、资金和人力资源，并得到政府的支持，这应该被赞赏而非批评。
    • 另一位用户表示，与中国政府相比，美国 政府的支持微不足道，中国 AI 很大程度上由政府资助，而 美国 AI 几乎完全属于私营部门。

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

123mikeyd: Nous girl Lofi Take 1: https://www.youtube.com/watch?v=-xlCIsccSjQ

Eleuther ▷ #general (11 条消息🔥):

AI 编程敌意, 用于机器人的 VLA, Nvidia 的 FLARE

  • AI 编程（AI Coding）面临 Reddit 账号封禁: 一名成员报告称遭遇了 对 AI 编程 的敌意，并在提到 Codex 或 ChatGPT 后被封禁了 三个 Reddit 账号。
    • 另一名成员询问他们是否 向 GitHub 仓库提交了 AI 生成的 PRs，原发布者对此予以否认，并表示那是研究代码。
  • Codex 配置被标记为 AI 生成文本: 一名成员在关于最佳实践的帖子中分享了他们的 ~/.codex/AGENTS.override.md 文件后，其账号被 r/codex 封禁，这可能触发了机器人检测。
    • 他们推测机器人可能将该文件的内容误认为 随机粘贴的 AI 生成文本。
  • 机器人项目寻求 VLA 合作: 一名成员正在为一项短期机器人项目寻求具有 VLA (Vision-Language-Action) 经验的合作伙伴。
    • 该项目旨在实现类似于 Nvidia FLARE 的功能，用于校准廉价 3D 打印机器人的误差，可能涉及多个研究方向，且他们拥有可用的工业机械臂。

Eleuther ▷ #research (34 messages🔥):

CoDA-GQA-L 发布, KV cache 效率, Differential Attention 的消融实验, Mycelium 的 AI 基准测试论文, 替代 MLP 的回归算法

  • **CoDA-GQA-L 有界内存注意力机制发布！: 一名成员发布了 **CoDA-GQA-L，这是一种有界内存注意力机制，可将 KV cache 限制在固定大小。在处理 128K tokens 时，70B 模型仅需 136 MB 内存。代码已在 GitHub 开源，论文发表在 Zenodo。
    • 该机制每层使用 384 个槽位，包括一个近期窗口（256 tokens）、一个精确地标库（64 个经过新颖性过滤的 tokens）以及一个摘要库（64 个 EMA 原型）。
  • 征集 Differential Attention 的消融实验！: 一位成员询问在 KV cache 变更中 Differential Attention 是否必要，并询问是否有将其与非微分 Transformer 进行对比的消融实验。
    • 作者承认由于资源限制目前缺乏消融实验，但计划添加。他强调是 KV cache 的减少而非 Differential Attention 本身驱动了内存效率。
  • **Mycelium 寻求 AI 基准测试论文的建议！: 来自 **Mycelium (https://github.com/Mycelium-tools) 的成员就发表关于 AI 模型基准测试的论文征求期刊或会议建议。该研究类似于 inspect_evals，但针对动态生成的多轮对话和 AI Agent 进行了调整。
    • 他们特别关注如何在期刊声誉、契合度及接受难度之间取得平衡。
  • 邀请对替代 MLP 的算法进行反馈！: 一位成员分享了他们替代 MLP 的回归算法链接并邀请反馈，并提到自己与原帖作者有着相似的背景和多年经验。
    • 该算法将输入分解为脊柱（spine）和线性偏差，提供了一种优雅且显式的解决方案。在结构适用的情况下评估速度很快，并提供 torch 实现。
  • 注意力就是你所需要的……两遍！: 连续输入两次 prompt 似乎能让所有 SOTA LLM 表现得更好，哈哈。

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

Rust 编写的 MI 工具包, 用于一致性正则化的特征引导向量, LLM 的界限

  • Rust 工具复现 Anthropic 在 Gemma 2 2B 上的发现: 一名成员在 candle 基础上使用 Rust 构建了一个 MI（模型解释性）工具包 (plip-rs)，并复现了 Anthropic 关于 Gemma 2 2B 的“诗歌规划（planning in poems）”发现。
    • 核心结果：通过“抑制 + 注入”位置扫描，成功复现了 Figure 13 的形状，且在规划位置出现了千万倍的激增。candle 团队已将其批准为 candle-mi (candle 讨论区)。
  • 引导向量增强多语言训练数据: 一位成员提出利用语言特征引导向量将一批英语句子增强为许多“伪多语言”微批次，并通过特征奖励（Feature Rewards）的强化学习（RL）来监督性能。
    • 该方法可能实现在无需其他语言数据的情况下，以约一半的成本进行 20 种语言的数据训练，详见 Twitter。
  • 成员讨论 LLM 的概率弱界限: 成员们讨论了 LLM 的界限（bounds），引用了一篇发表日期奇怪（2026年2月11日）的 论文 以及另一篇具有不同界限的 论文。
    • 一位成员建议允许结果在 1-epsilon 概率下自行弱化，因为 LLM 并非某种完美的机器。

Eleuther ▷ #lm-thunderdome (3 messages):

Concurrent Task Evaluations, API calls in metrics.py, Batch support

  • 并发评估任务正式开启：一位成员询问了关于执行并发任务评估的问题，旨在通过在 metrics.py 中使用 API 调用来加速任务。
    • 另一位成员建议修改任务，先将模型生成的输出写入磁盘，然后使用自定义批处理（custom batching）进行指标计算；并提到批处理支持已列入项目计划。
  • API 批处理讨论：一位成员考虑在聚合步骤中对 API 调用进行批处理，认为这是一个潜在的、尽管有些 hacky 的解决方案。
    • 他们表示打算尝试这种方法。

Eleuther ▷ #multimodal-general (1 messages):

VLM Blindness, Linear Probing Accuracy

  • VLM 被证实存在视觉缺陷：一位成员分享了论文 Are VLMs Really Blind?，该研究表明 SOTA VLM 在处理数圆圈或识别相交线等简单视觉任务时表现挣扎。
    • 该成员询问了潜在的解决方案，建议在类似数据上进行 SFT（有监督微调）或 RLVR（基于视觉推理的强化学习）可能会提高性能。
  • 线性探测（Linear Probing）达到极高准确率：同一位成员指出，对视觉编码器（vision encoder）特征进行线性探测，在上述任务中可以达到接近 100% 的准确率。
    • 这表明视觉信息 确实 被编码器捕捉到了，但 VLM 却难以正确利用这些信息，正如相关 截图 中所展示的。

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

Jupyter Mojo kernel, Linux installation issues, Self-Evolutionary System, GPU support on solve, Modular shout-out

  • Jupyter Mojo Kernel 发布：Jeremy Howard 发布了 Jupyter Mojo kernel，指出它虽然极其精简（barebones）但速度很快，且在 Mac 上运行良好。
    • 它支持 pip install，并为 MacOS 和较新版本的 Linux 提供了预编译版本，同时使用 uv 自动安装匹配的 modular 软件包。
  • Linux 安装琐事已解决：一位用户在 Linux (Ubuntu 24.04 LTS) 上测试了 Jupyter Mojo kernel，报告称安装并非一帆风顺，由于版本不匹配，需要执行 MOJO_VERSION=26.1.0.post1 uv add "mojokernel>=26.1.0"。
    • Jeremy Howard 修复了此问题，他之前忘记了为多个 Python 版本进行构建。
  • 自进化系统架构设计：一位成员正在 构建一个自进化系统（Self-Evolutionary System），应用 Ricci Flow（里奇流）来消除几何噪声，利用 Kolmogorov Complexity（柯氏复杂性）提升算法效率，并应用 Gödelian logic（哥德尔逻辑）来识别超越自身编程的智能。
    • 该成员表示：“我不是在写代码行；我是在定义数字宇宙的法则。”
  • 渴求 GPU 支持：一位用户请求 Mojo 和 GPU 支持，认为这对于学习来说会“非常酷”。
  • Modular 官方点名表扬：Modular 在 X 上向 Jeremy Howard 表示了致谢 Modular 状态更新。
    • Jeremy Howard 对此回应：“太棒了，谢谢 Modular 的点名推荐！”

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

Mojo C++ Binding, GNU Radio binding, Mojo's Origins and Philosophy, Rng vs random module, Dunder Methods Empty

  • Mojo 的 C++ 绑定大部分是手动的：据一位成员透露，Mojo 的 C++ 绑定涉及 大部分通过 C 语言进行的手动绑定回环。
    • 在回答是否像 pybind11 一样简单时，得到的回复是：并不尽然。尤其是因为你需要亲手编写这些绑定。
  • GNU Radio 绑定正在开发中？：一位成员提到，他们正考虑通过这个 GitHub 仓库为 GNU Radio 制作绑定。
    • 另一位成员建议：你可能会发现一种解决方案是改为拥有 2 个独立的进程，并使用一些共享内存进行通信。
  • 深入了解 Mojo 的起源和哲学：如果你想了解更多关于 Mojo 的起源和哲学的细节，一位成员推荐阅读愿景文档 (vision document)。
  • 测试中的 Rng 仍处于 WIP（开发中）！：测试中的 Rng 专门用于属性测试 (property testing)，目前仍处于 WIP 阶段（它在内部使用 random 模块的函数）。
    • 对于通用目的的 rng，你应该使用 random 模块。我们以后可能会公开一种构造生成器的方法，但据我所知，目前它只使用一个全局生成器。
  • Dunder Methods 看起来是空的：一位成员询问为什么所有的 dunder methods（魔法方法）都是空的，例如 __repr__() 方法的主体。
    • 回复是：这只是因为每个类型都是新的，我当时在 repr() 方法的代码中没明白为什么 __repr()__ dunder 方法是空的。

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

Modular Build Infrastructure Enhancements, Custom Mojo Kernels, MXFP4 Kernels, Graph Compiler

  • 自定义 Mojo Kernel 现在可用于 MAX 模型：根据这篇论坛帖子，modular 仓库的构建基础设施得到了增强，同时 Graph Compiler 也增加了新功能。现在使用开源 (OSS) 的 modular 仓库构建的 MAX Graph 和模型可以使用完全自定义的 Mojo 标准库或 Mojo Kernel。
  • MXFP4 Kernel 协作即将到来：成员们一直在开发 mxfp4 kernel，目标是重新量化为 nvfp4。
    • 其他成员正在联系 Kernel 团队，看看是否可以进行协作。

HuggingFace ▷ #general (15 messages🔥):

AI Researcher with Self-Improving Capabilities, Local AI Rigs and Hardware Setups, GPT OSS 120B Performance, Activity on HuggingFace.co, ComfyUI Workflow

  • 具有自我提升能力的 AI 研究员项目引起关注：一位成员表示有兴趣开发一个私有项目，创建一个具有 自我提升能力 的 AI 研究员 (AI researcher)，重点是改进现有的 AI，而不是从头开始创建新的 AI。
    • 该成员对本地 AI Rigs（AI 设备）感到好奇，并询问是否有专门讨论硬件设置的讨论串。
  • 硬件爱好者寻求关于并发请求的建议：一位用户希望了解拥有 48GB+ VRAM 的用户在做什么，重点是针对本地硬件的 Agent 应用并发请求，并且对 RTX Pro 6000 Blackwell 或二手 GPU 集群感兴趣。
    • 该用户表示，根据他们的经验，任何低于 GPT OSS 120B 的模型都不值得，目前依赖于 OpenRouter，同时考虑采用混合方案。
  • HuggingFace.co 上的可疑活动被标记：一位用户质疑 HuggingFace.co 上的异常活动，特别指出某位用户表现出潜在的恶意行为。
    • 另一位用户认为这是因为发帖速度过快导致的。
  • ComfyUI 工作流消失在空气中：一位用户分享了与 ComfyUI 相关的链接，包括一个模型和一个工作流。
    • 另一位用户评论说频道中的一个链接消失了。
  • Kaggle 依赖冲突困扰 PEFT Adapter 层评估：一位用户在 Kaggle Notebook 上运行一个配有 PEFT Adapter 层 的模型评估脚本时遇到了依赖冲突。
    • 该用户寻求修复 Notebook 的建议，或寻找合适的参考 Notebook。

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

航班/酒店 MCP Server、LLM 记忆生态系统、AI 应用安全与可观测性、面向 OpenClaw 的 Microclaw、ModernBERT 模型

  • 专为航班和酒店搜索构建的 **MCP Server：一位成员构建了一个用于航班和酒店搜索的 **MCP server，可在 delulu 获取。
    • 共享了 Delulu 航班搜索和 Delulu 酒店搜索用户界面的截图以获取反馈。
  • 为 ‘WhereIKept’ 应用探索 **LLM 记忆生态系统：一位 AI 工程师正在开发 LLM 的记忆生态系统，利用设备端的 speech-to-text 和多模态 LLM 创建名为 **WhereIKept 的应用，旨在帮助用户记住存放物品的位置，项目已在 WhereIKept 开源。
    • 提到的未解决问题包括跨位置的物体身份识别、更智能的检索、设备端优化以及应用的合适形态。
  • 正在开发用于实时安全的 **AI Firewall**：一项研究工作正在为 AI 应用提供“防火墙”，为 Agentic Apps 提供实时的 prompt injection 检测、PII 扫描和成本控制，GitHub 仓库见 llmtrace。
    • 开发者承诺很快将发布 Benchmark 结果。
  • 面向 OpenClaw 的 Microclaw 提供增强型 Fallback Agent：Microclaw for OpenClaw (v2026.2.18) 是为 OpenClaw 设计的增强型 fallback agent 模型，在主模型不可用时提供本地化、高质量的替代方案，详见其 HuggingFace 页面。
    • 另一个版本 也可供测试，注意其安装步骤不同，该模型使用 2048 token 上下文长度。
  • **ModernBERT-small-v2 为本地应用提供改进**：发布了 ModernBERT 小型模型的改进迭代版本，旨在用于无 GPU 的本地应用，可在其 HuggingFace 页面 获取。

HuggingFace ▷ #gradio-announcements (1 messages):

gr.HTML, Gradio 6, HF Collection

  • Gradio 6 发布 gr.HTML 博客文章！：Gradio 团队发布了关于 gr.HTML 的博客文章。这是 Gradio 6 的自定义组件，允许用户仅使用单个 Python 文件创建完整的 Web 应用程序，博客链接在此。
  • 利用 gr.HTML，完整的 Web 应用现在可以 one-shot 生成！：博客文章提到，得益于 gr.HTML，Claude 或任何 Frontier LLM 现在可以通过单个 prompt 在单个 Python 文件中生成 Web 应用程序。
    • 创建了几个示例应用，如 Kanban board（看板）、Pomodoro timer（番茄钟）和 Github heatmaps（热力图），以展示新工具的功能，HF Collection 链接在此。

HuggingFace ▷ #agents-course (2 messages):

Smol-Course 发布

  • Smol-Course 发布日期仍未知：一位成员询问了 此链接 中提到的 smol-course 的发布日期。
  • Smol-Course 未来计划尚不明确：Smol-Course 的未来计划尚不清楚。

Yannick Kilcher ▷ #general (20 messages🔥):

Masking Gradients vs Masking Data, SkipUpdate for Performance, LoRA Similarities, Block Dropout Explanation, RPROP Optimizer

  • SkipUpdate 掩码梯度以提升性能：展开了一场关于 SkipUpdate 及其与 BERT 和 MAE 区别的讨论，结论是它从掩码数据转向了掩码某些参数的梯度。
    • 一名成员认为其目标是可扩展监督（scalable supervision），而另一名成员认为其目标是性能。
  • LoRA、SkipUpdate 与权重更新：参与者讨论了 SkipUpdate 是否与 LoRA 相似，一名成员指出 LoRA 会间接更新与 LoRA 模块相关的所有参数。
    • 另一名成员澄清说，与 LoRA 不同，SkipUpdate 并不节省内存，只有在能提高性能的情况下才有意义。
  • Block Dropout 的梯度掩码：一名成员解释说 Block Dropout 会掩码整个块的梯度，但会更新动量项（momentum terms），惩罚具有高二阶变分的块。
    • 此外还提到，根据梯度与动量之间的一致性来缩放梯度，这与古老的 RPROP optimizer 类似。
  • 重温 RPROP 优化器：一名成员建议，根据梯度与动量之间的一致性来缩放梯度类似于古老的 RPROP optimizer。
    • 在噪声较高的情况下，RPROP 仍然可以是一个非常强大的优化器。

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

Sutton & Barto Discussion

  • 需要确认 Sutton & Barto 讨论会议时间：一名成员请求确认讨论 Sutton & Barto 的会议时间。
    • 他们还要求澄清书中将要涵盖的具体章节。
  • 寻求 Sutton & Barto 讨论详情：一名参与者询问了关于 Sutton & Barto 的预定讨论，寻求准确的时间。
    • 此外，他们还要求提醒在会议期间将要审阅的书籍具体章节。

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

Lyria model by DeepMind, OpenEval framework

  • DeepMind 的 Lyria 模型再次出现：DeepMind 的 Lyria model 在聊天中被提及，并附上了其 官方页面 的链接。
    • 虽然被认为有点老旧，但在音乐创作模型的语境下仍然具有相关性。
  • OpenEval 框架引发关注：OpenEval 框架被强调为很有趣，可能是因为它与之前的对话动态相关。

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

tinygrad, BarraCUDA, MFMA

  • Hotz 呼吁为 tinygrad 做贡献：George Hotz 鼓励 该项目 的开发者为 tinygrad 贡献代码，并批评了他们选择 C 语言以及缺乏 CI 的做法。
    • 他建议使用他们的 emulator，并提出为添加 GEMM/flash attention 测试和清理代码支付 CDNA bounty（CDNA 赏金）。
  • 需要修复 MFMA 断言：一名成员指出 _compile_mfma 中的一个断言将 MFMA 支持限制在 16x16 矩阵，见 这段代码。
    • 该成员询问在当前的测试范围之外，是否也应该支持 4x4 和 32x32 的 MFMA。

tinygrad (George Hotz) ▷ #learn-tinygrad (2 messages):

tinygrad puzzles, solve.it solutions

  • 学生在 Solve It 上解决 tinygrad 谜题：一名学生在 Solve It 上发布了他们对所有 tinygrad puzzles 的解答。
    • 这些谜题涵盖了 tinygrad 的各个方面。
  • Solve It 托管 tinygrad 解答：tinygrad 谜题的解答托管在 Solve It 上。
    • Solve It 是一个用于分享和协作编程谜题解答的平台。

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

``

  • 空的 Discord 聊天记录：提供的 Discord 聊天日志是空的，仅包含填充消息。
    • 因此，没有可以总结或讨论的主题。
  • 此处无对话：提供的消息不构成有意义的对话。
    • 没有可提取的可操作内容或讨论点。

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

MCP Payment Support, X402 payment protocol, Microtransactions for Agents

  • MCP 服务器提议通过 SEP 实现货币化：一名成员创建了一个 SEP，允许 MCP 服务器为工具请求费用，从 X402 开始，以促进 Agent 和 MCP 的采用。
    • 创建者认为，由于引入了货币化激励措施，这可能会显著加速 Agent 和 MCP 的普及。
  • MCP 支付支持受到质疑：一名成员质疑是否有必要在协议中内置支付支持，建议通过 URL elicitation 来处理带外（out-of-band）支付。
    • 该成员概述了一个流程：服务器发送支付的 URL elicitation 请求，并在确认后授予服务。
  • 自主 Agent 的微支付：一名成员澄清说，该 SEP 针对的是 Agent 自主支付工具费用的微支付（以美分为单位），并在预算护栏下运行。
    • 这些 Agent 需要关于工具成本的丰富信息，以便为深度研究做出智能决策。
  • X402 支付协议受到青睐：一名成员表示同意等待支付协议稳定，但另一名成员建议从 X402 开始，并强调了其目前的突出地位。
    • 该成员保证 SEP 将被设计为具有可扩展性，以适应未来的支付协议。

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

13yo dev from Baghdad verified, Full stack developer introduction, Manus account issues, Subscription cancellation, Manus shines in Job hunting

  • 巴格达 13 岁区块链奇才通过认证：一名来自巴格达 🇮🇶 的 13 岁开发者宣布通过官方认证，并分享了在 Blockchain 和 AI Agents 方面的经验。
    • 他们精通 EVM, Solana, Sui, XRP, Cardano, Midnight, zk-SNARKs, React, Next, Vue, Node，并欢迎合作。
  • 全栈开发者寻求未来合作：一名在 Web 应用程序、API 集成和数据管道方面拥有经验的全栈开发者介绍了自己。
    • 他们的技术栈包括 react/next.js, node.js/Django, python 框架和库 (TensorFlow, Pytorch, OpenCV, NumPy)，并擅长使用 AWS/Docker 构建可扩展的应用，专注于现实世界的产品。
  • Manus 崩溃：成员的杰作陷入混乱：一名成员报告了其 Manus 账号的严重问题，耗时数周制作的演示文稿现在充满了错误。
    • 尽管在演示历史记录中可见，但无论如何操作都无法恢复该演示文稿。
  • 订阅混乱：系统救星现身：成员 @sysing 警告说，如果你不取消订阅，可能仍会被扣费。
    • 他们要求受影响的用户通过私信（DM）发送注册邮箱以解决问题。
  • Manus 掌控复杂的现代招聘市场：一名成员对 Manus 在求职方面的帮助表示感谢，指出在 Best Buy 网站无法正确自动填充简历的地方，Manus 表现出色。

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

AI security, Observability, Prompt injection, PII scanning, Cost control for Agentic Apps

  • AI 应用防火墙项目启动：一名成员宣布了一项新的研究工作，旨在为 Agentic Apps 提供具有实时 Prompt 注入检测、PII 扫描和成本控制功能的“防火墙”。
    • 该项目的 GitHub 仓库 已开放并征求反馈，基准测试结果将很快公布。
  • llmtrace GitHub 仓库等待反馈：一名成员创建了一个名为 llmtrace 的新 GitHub 仓库，与新的“防火墙”研究相关。
    • 作者寻求社区对该项目的反馈，重点关注 AI 的安全方面。

DSPy ▷ #general (5 条消息):

Hegelian dialectic Exercise, dspy.dialectic, Community Office Hours, RLMs 简化任务, 真实用户反馈

  • Hegelian Dialectic 练习结束：一名成员结束了 Hegelian dialectic Exercise，并感谢其他人的支持。
  • Office Hours 安排已定！：社区 Office Hours 宣布将于美国东部时间 2 月 19 日上午 11:30 通过 Zoom 链接 举行。
  • RLMs 简化任务！：一名成员分享了 GitHub 上的 Monolith，称其为一项天才之作，并证明了 RLMs 简化了以前需要大量样板代码 (boilerplate) 和编排 (orchestration) 的任务。
  • 征求真实用户反馈：一名成员询问 offline 是否意味着真实用户反馈，并链接了 gepa-ai/gepa repo 的一个 issue，他在其中分享了一些想法。
← 返回首页