AI News

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

· MjAyNi0w

以下是为您翻译的中文内容：

2026年1月16日至1月19日的 AI 新闻摘要 涵盖了用于扩展 Transformer 内存和上下文的新架构，其中包括来自卡内基梅隆大学（CMU）和 Meta AI 的 STEM。该架构通过基于 Token 索引的嵌入查找（token-indexed embedding lookup）替换了部分前馈网络（FFN），从而实现了 CPU 卸载（offload）和异步预取。Sakana AI 推出的 RePo 则引入了自适应位置重排技术，以提高模型在处理噪声及长上下文时的稳健性。

在模型发布方面，重点关注了智谱 AI（Zhipu AI）的 GLM-4.7-Flash。这是一款 30B 级（300亿参数）模型，采用 MLA（多头潜在注意力）+ 小型 MoE（混合专家模型）架构，针对编程和智能体（agentic）任务进行了优化。该模型因其强大的基准测试表现，以及体现了从大模型向小模型压缩的趋势而受到关注。

推理与部署方面的更新包括 mlx-lm 0.30.3 版本，该版本支持 GLM-4.7-Flash，并在笔记本电脑上实现了高效的 4-bit 性能。

本报告强调了关于静态稀疏性、自适应排序以及用于交互式任务的“小而快”模型重新崛起的实用见解。“稀疏容量并不一定意味着必须使用 MoE 路由 + 专家并行；静态稀疏性也可以对系统实现非常友好。”

#transformer-memory #model-architecture #mixture-of-experts #adaptive-position-encoding #long-context #model-compression #inference-optimization #local-inference #model-deployment #benchmarking #coding #agentic-ai glm-4.7-flash glm-4.7 glm-4.5 qwen3-vl qwen meta-ai-fair carnegie-mellon sakana-ai zhipu-ai

平静的一天

2026年1月16日至1月19日的 AI 新闻。我们为您检查了 12 个 subreddit、544 个 Twitter 账号 和 24 个 Discord 服务器（205 个频道，13654 条消息）。预计节省阅读时间（按 200wpm 计算）：1062 分钟。我们的新网站现已上线，提供完整的元数据搜索和极具氛围感的历期内容展示。请访问 https://news.smol.ai/ 查看完整的新闻分类，并在 @smol_ai 上向我们提供反馈！

如果时间允许，我们建议查看 ARC AGI 2025 报告。

AI Twitter 综述

用于扩展“记忆”和上下文的新架构

  • STEM (Scaling Transformers with Embedding Modules)：卡内基梅隆大学 + Meta 的一种方法，旨在不使用 MoE 风格动态路由的情况下扩展 Transformer 的参数化记忆 (parametric memory)。关键替换：移除约 1/3 的 FFN 升维投影 (up-projection)，并将其替换为基于 Token 索引的嵌入查找 (embedding lookup)，同时保留 Gate + 降维投影 (down-projection) 为密集形式。由于查找是静态的，它避免了运行时的路由开销/不稳定，甚至可以实现 CPU 卸载 (offload) + 异步预取 (async prefetch)，从而将模型容量与单 Token FLOPs 以及跨设备通信解耦 (概述, 分步讲解, 为什么 MoE 在实践中可能效率低下)。
    • 实践总结：“稀疏容量”并不一定意味着 MoE 路由器 + 专家并行；静态稀疏可以对系统友好（可预测的访问模式，更低的通信成本）。
  • 来自 Sakana AI 的 RePo (Context Re-Positioning)：一个轻量级模块，允许 LM 根据内容相关性重新排列位置结构，从而有效地重塑注意力几何，使相关的远处项被“拉近”，而噪声被推远。基于认知负荷理论 (Cognitive Load Theory) 的构想：固定的 Token 索引迫使模型在杂乱无章的输入上消耗容量。RePo 旨在提高模型在嘈杂上下文、结构化数据和长程依赖方面的鲁棒性 (公告, 代码, 仓库链接)。
    • 实践总结：是对检索/打包技巧的补充——RePo 是一个用于自适应排序的架构旋钮，而不单纯是更好的检索。

模型发布：GLM-4.7-Flash 和 “MLA + 小型 MoE” 浪潮

  • 智谱 AI (Zhipu AI) GLM-4.7-Flash：作为一款 30B 级的本地代码/Agent 模型发布，定位为轻量级且部署友好。智谱称其为“30B 级别的新标准”，推荐用于代码 + Agent 用途，以及翻译/长上下文/创意写作 (发布, “开发者自述”)。智谱稍后澄清：GLM-4.7-Flash 是一个 30B-A3B 的 MoE 模型 (规格)。
    • 社区/分析师笔记强调了其架构转变：GLM “切换到了 MLA”，在降维投影后具有不寻常的 Head 维度和更高的 Head 数量；这遵循了 Qwen/DeepSeek 风格设计中出现的趋势 (stochasticchasm, eliebakouch)。另一份总结声称每 Token 约有 3B 激活参数，并强调了其在 SWE-bench Verified、τ²-Bench、HLE、BrowseComp 上的强劲基准测试表现，而 LCB 则是 Qwen 领先的领域 (gm8xx8)。在验证模型卡之前，请将这些视为二手信息。
  • “压缩”叙事：一些评论将 GLM 的轨迹描述为将更大的模型压缩为更小的模型（例如，“GLM-4.5 110B → GLM-4.7 31B”），并期待 GLM-4.7V 对标 Qwen3-VL (casper_hansen_)。相比于已确认的训练配方，这更多是一种解释。
  • 工具化中的小模型复兴：多篇帖子反映出工程师在同步编码中优先考虑速度/延迟和“足够好”的智能——这表明对于 >95% 的交互式任务，收益正在递减，前沿阵地正向具有前沿水平质量的快速推理转移 (amanrsanger)。

推理与部署基础设施：本地运行时、vLLM/MLX 以及“全栈”系统论文

  • GLM-4.7-Flash 的首日（Day-0）生态支持：
    • mlx-lm：mlx-lm 0.30.3 已支持 GLM 4.7 Flash，据报告在 M5 32GB 笔记本上的 4-bit 性能表现为：生成速度约为 43 tok/s，预填充（prefill）速度约为 800 tok/s（awnihannun）。随后的 mlx-lm 发布说明提到了 continuous batching/分布式改进以及 autoAWQ/autoGPTQ 支持（awnihannun）。
    • LM Studio：通过 Apple Silicon 版 MLX，GLM-4.7-Flash 可作为 Mac 上的 30B 本地编程 Agent 使用（lmstudio）。
    • Ollama：GLM-4.7-Flash 已在 Ollama v0.14.3+ (预发布版) 中可用（ollama）。
    • vLLM：vLLM 项目宣布了“首日支持”的 PR（vllm_project）。
    • opencode + HF 推理提供商：GLM-4.7-Flash 已通过 Hugging Face Inference Providers 集成到 OpenCode 中（victormustar），并有一个通过 Ollama + Harbor 运行本地 GLM-4.7-Flash 的示例（Everlier）。
  • 华为/中国推理系统“2025 旗舰作品”综述（源自知乎贡献者总结）：这份密集的技术思想列表针对 KV-cache 容量墙、PD split/merge 利用率、混合调度、缓存亲和性/负载均衡以及以 KVCache 为中心的 Agent 内存。显著的主张包括：将“冷” KV 卸载到 DRAM；“Decode Attention 流向 Prefill GPU”；“将延迟松弛（latency slack）视为资源”；双哈希路由（“power of two choices”）；以及将 Agent 内存作为可复用的 KV 块，以保持前缀连续性和缓存（ZhihuFrontier）。
    • 实际启示：重心正从孤立的 kernels 转向 端到端 SLO-goodput 的系统设计。
  • Cerebras vs GPU 的权衡：一个讨论线程强调在计算机体系结构中“没有免费的午餐”：Cerebras 在典型的 GPU 友好型工作负载中，以 FLOPs/内存效率为代价换取带宽/延迟，但在其他平台难以实现的超低延迟小模型场景中表现卓越（itsclivetime）。相关推测：Cerebras 上的 Codex 可能会重构 Agent 测试套件的预期（dbreunig）。

Agent、内存与开发者工作流：从 MCP 辩论到沙箱 + RLMs

  • 文件系统 vs 数据库用于 Agent 记忆：一个有用的总结将观点分为两个阵营——“文件就是你所需的一切”（Anthropic/Letta/LangChain/LlamaIndex 模式）vs “文件系统是糟糕的数据库”（关于重新实现搜索索引/锁定/日志的警告）。关键维度：简单性 vs 规模化、多模态数据、并发性、安全性/权限，以及由于以编码为中心的后期训练（post-training），Agent 对 CLI 工具的熟悉程度 (helloiamleonie，以及关于记忆作为文件可移植性的简短看法 (Vtrivedy10))。
  • 递归语言模型（RLMs）落地 DSPy：DSPy 发布了 dspy.RLM (v3.1.2)，主打与现有 Signatures 的即插即用 (isaacbmiller1)。多位工程师将其标记为新的实验方向和生态系统解锁 (a1zhang, kmad)。
    • 实践启示：RLMs 是处理 长上下文 / 迭代处理 的新手段，无需简单粗暴地将所有内容塞进一个上下文窗口（context window）。
  • 沙箱和“Agent Harness”作为差异化核心：多篇文章认为真正的“alpha”（优势）在于 Harness（治理/保障体系）：工具化、技能、隔离、重试和可靠的执行循环——而不只是基础模型。例如：用于“droid”的 /create-skill 命令，可将对话会话转换为可重用的技能 (matanSF)；关于 Agent 沙箱延迟/持久性的疑问 (ben_burtenshaw)；以及对构建系统中任务重试 UX 的不满 (charliermarsh)。还有一个具体案例声称 “droid” 在企业评估中击败了 Claude Code/Codex/Gemini CLI，并将其归功于 Harness (matanSF)。
  • 开源 Agent 框架：
    • Claude Cowork：开源 Agent Harness，支持 Claude Opus 4.5、Gemini 3 Pro、GPT-5.2 (Saboo_Shubham_)。一个实用的附加功能展示了将 PDF → Markdown 转换以减少幻觉并提高文档理解，基于 LlamaParse/semtools 构建 (jerryjliu0)。
    • StirrupJS：TypeScript Agent 框架，强调极简脚手架 + 强大的默认设置（工具、MCP、浏览、沙箱）以及多模态支持 (ArtificialAnlys)。

安全、评估与可靠性：探测、人格漂移与搜索攻击

  • Anthropic “助手轴（Assistant Axis）”研究（人格漂移）：Anthropic 指出，开源权重模型在长对话中可能会偏离“助手”人格；类编码上下文能稳定助手人格，而治疗/哲学上下文则会增加漂移。他们提出了人格构建 + 稳定化方案，并指出 激活封顶（activation capping） 是一种缓解措施；他们提供了一个警示案例，其中漂移导致了鼓励隔离/自残的有毒“坠入爱河”行为 (线程开始, 漂移上下文, 论文+演示, 危害示例 + 缓解措施)。
  • Google DeepMind：生产环境中的激活探测（activation probes）：DeepMind 描述了用于分类现实世界滥用风险的“新型激活探测架构”，并指出这些探测已用于 Gemini 的实时部署 (ArthurConmy)。Rohin Shah 强调探测是安全领域的“廉价分类器”手段 (rohinmshah)；Neel Nanda 强调了生产化安全分类器的工程现实（副作用、误报、效率），并链接了论文 (NeelNanda5)。
  • 检索器/搜索操纵（“任意内容注入”）：一篇论文声称搜索/检索堆栈可能被劫持，从而将任意内容推送到顶部结果，影响检索器（retriever）、重排器（reranker）和 LLM 评判员 (ManveerTamber)。
  • RAG 可观测性：DeepLearning.AI 强调生产环境中的 RAG 需要涵盖延迟/吞吐量和响应质量的可观测性，并平衡 LLM 评判员与人类反馈 (DeepLearningAI)。

多模态与媒体工具：实时语音、浏览器视觉和生成式视频

  • Microsoft VibeVoice (开源实时 TTS)：声称首个音频延迟约为 300 ms，支持流式文本输入、多说话人（最多 4 人）以及长文本稳定性（最长 90 分钟）。据描述，它在 7.5 Hz 频率下使用语义+声学 Token，通过语言模型构建结构，并使用扩散头（diffusion head）处理声学细节；采用 MIT 许可证，“仅供研究使用” (LiorOnAI, repo)。
  • WebGPU 浏览器视觉演示：通过 WebGPU 在浏览器中实现 “YOLO26” 实时姿态/检测，并提供 Hugging Face 模型/演示集合 (mervenoyann, HF link)。
  • fal 上的视频生成产品化：发布了多个“按需模型”：Wan 2.6 i2v Flash（最长 15 秒，可选音频）(fal)；Vidu Q2 参考视频生成，支持多参考和人脸参考 (fal)；此外还有 Flux.2 [klein] 训练器 + 已发布的用于扩图/缩放/物体移除/背景移除的 LoRA (fal, LoRAs)。
  • 小型模型上的 Function calling：Google 的 FunctionGemma Tuning Lab：一个围绕 270M 参数模型构建的，用于微调/导出 Function calling 模型的指南 + 无代码演示，并配有 HF Space (osanseviero)。
  • Web World Models (WWMs)：普林斯顿风格的“将规则与想象分离”：确定性的 Web 代码物理层首先更新状态，然后 LM 从更新后的状态生成描述以保持连贯性 (TheTuringPost)。

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

1. 高 VRAM AMD R9700 服务器配置

  • 4x AMD R9700 (128GB VRAM) + Threadripper 9955WX Build (热度: 508): 该帖详细介绍了一台高性能服务器配置，使用了 4 块 **AMD Radeon AI PRO R9700 GPU，每块显卡拥有 32GB VRAM，总计 128GB VRAM，并搭配了 AMD Ryzen Threadripper PRO 9955WX CPU。该系统旨在本地运行大型 AI 模型（120B+ 参数），并强调数据隐私。整机成本约为 9,800€，获得了当地政府 50% 的补贴，实际成本降至 4,900€。使用 llama.cpp 的基准测试显示出显著的性能，GLM-4.7-REAP-218B-A32B-Q3_K_M 模型在生成任务中达到了 17.48 tokens/s。用户指出 PCIe 5.0 相比于张量并行 (Tensor Parallelism)，能更好地增强流水线并行 (Pipeline Parallelism) 的性能。系统使用 ROCm 7.1.1 提供软件支持，用户还在考虑未来是否更换为 NVIDIA RTX Pro 6000 以获得潜在的更好性能。** 一条显著的评论询问了组件的来源和成本，反映出人们对这类高端硬件的可行性和采购方案的关注。另一条评论幽默地提到了超大容量的 RAM，而第三条评论则提到了类似的配置，表明大家对高性能本地 AI 系统有着共同的兴趣。

    • RoterElephant 讨论了使用多块 AMD R9700 显卡与单块 NVIDIA RTX Pro 6000 Blackwell 之间的权衡。NVIDIA 显卡尽管总 VRAM 较少，但凭借其架构和软件支持提供了卓越的性能，在某些工作负载下效率更高。这突显了在构建高性能系统时，不仅要考虑原始 VRAM 容量，还要考虑整体性能以及与特定应用程序的兼容性。
    • Obvious-Nobody-9592 询问了组件的获取途径和成本，指出总支出为 9800 欧元。这条评论强调了组装高端计算系统时涉及的财务考量和规划，特别是像 AMD R9700 和 Threadripper 9955WX 这样不仅价格昂贵，而且需要长期仔细规划预算和寻找货源的组件。
    • Ulterior-Motive_ 提到了一个类似的配置，表明使用 AMD R9700 GPU 组建高性能计算设置已成为一种趋势或共同兴趣。这指向了一个由爱好者或专业人士组成的社区，他们正在探索此类配置的能力，可能用于机器学习或数据分析等需要巨大计算能力的各种任务。

  • 128GB VRAM quad R9700 server (热度: 738): 该帖详细介绍了一台高性能服务器配置，搭载了四块 **PowerColor AMD Radeon AI PRO R9700 GPU，每块具有 32GB VRAM，总计 128GB VRAM 以及 128GB RAM，旨在优化机器学习任务中的提示词处理 (Prompt Processing) 性能。该配置耗资 $7,035，包含 MSI MEG X570 GODLIKE Motherboard 和 AMD Ryzen 7 5700X CPU 等组件。基准测试显示，在 ROCm 后端下，llama 7B Q4_0 和 qwen3moe 30B.A3B Q8_0 等模型的性能有显著提升，提示词处理速度最高达到 6524.91 t/s。该帖还强调了 Qwen3-Next 模型存在的问题，以及在存储和 PCIe 插槽配置方面面临的挑战。** 评论表达了对该配置性能的赞赏，并幽默地承认了追求高端硬件配置所带来的财务压力。

2. Qwen 开发与质量焦点

  • Qwen 4 可能还遥遥无期！？首席开发者表示他们正在“减慢速度”以专注于质量。 (热度: 575)：图片是来自首席开发者 **Junyang Lin 的推文，表明了 Qwen 系列开发过程中的战略转变，即专注于提升质量而非快速迭代。这暗示 Qwen 4 的发布可能会推迟，因为团队在研究上投入了更多精力，可能会为了长期改进而牺牲短期成果。该推文反映了对完善模型的承诺，这些模型以其多样的尺寸和能力而闻名，旨在确保更高质量的输出。** 评论者普遍支持优先考虑质量的决定，一些人表示松了一口气，因为重点不在于快速、增量的更新，这类更新可能会在没有显著进展的情况下增加成本和资源消耗。

    • AvocadoArray 强调了频繁增量更新的低效率，指出由于高 GPU training 需求，它们往往会导致需求和成本增加。这一观点认为，专注于实质性的改进对 AI 领域更有利，因为它避免了频繁微小更新且未能显著推动领域发展的陷阱。
    • frozen_tuna 提出了一个关于为了质量改进而推迟发布的潜在风险的关键点，并将其与 Meta 在发布 LLaMA 4 之前的做法进行了类比。该评论质疑如果推迟发布的 Qwen 4 不能满足更高的预期，社区是否会宽容，暗示如果最终产品表现平平，等待“高风险研究”成功的策略可能会适得其反。
    • Cool-Chemical-5629 赞赏对质量的关注，指出虽然 Qwen 系列 一直表现良好，但仍有改进空间。他们希望开发者在提高质量的同时，继续提供广泛的模型尺寸选择，这一直是该系列的标志。这反映了对模型产品多样性和显著质量进步的双重渴望。

  • 本地 AI 终极 Boss — M3 Ultra v.s. GB10 (热度: 404)：图片描绘了 **Mac Studio M3 Ultra 和 ASUS GX10 (GB10) 之间的对比设置，两者都是高性能计算设备。讨论集中在将这些机器用于 AI 任务，并建议使用 EXO 进行集群以提高 Prompt 处理速度。M3 Ultra 因其在企业环境中用于私有 On-premises 基础架构而广受欢迎，而人们对 GB10 在类似场景下的性能表现充满好奇。该设置预示着一次测试或实验，以评估这些设备在处理 AI 工作负载时的能力。** 一位评论者对 GB10 与 M3 Ultra 的性能对比感到好奇，因为他们经常为商业用途安装 M3。另一条评论幽默地建议使用这些设备来解决政治问题，反映了将技术应用于现实世界问题的愿望。

    • No_Conversation9561 提到使用 EXO 进行集群以增强 Prompt 处理速度。他们引用了一个据称可以提高性能的具体设置，并提供了 EXO Labs 网站和 GitHub issue 的链接以获取进一步的技术细节。
    • adspendagency 讨论了在企业环境中为私有 On-premises 基础架构部署 M3 单元的情况，表示有兴趣了解 M3 和 GB10 之间的性能比较。他们指出，目前的做法是向客户交付 M3，这表明在了解 GB10 能力方面可能存在空白。
    • belgradGoat 对 Mac Studio 在运行 500 GB RAM 模型时的稳定性表示担忧。他们分享了 256 GB 版本的个人经验，指出当内存使用接近极限时会出现稳定性问题，暗示在处理大规模模型时可能存在挑战。

3. 无审查 AI 模型探索

  • 寻找非成人向的无审查 AI (The Search for Uncensored AI (That Isn’t Adult-Oriented)) (热度: 696): 该 Reddit 帖子讨论了寻找一个既无审查又在技术上先进，且不以成人内容为导向的 AI 模型的挑战。作者注意到，在受到严格限制的企业级 AI 与为低质量成人用途优化的模型之间存在空白，并试图寻找专注于推理、创造力和问题解决的替代方案。帖子征集了关于自托管模型、开源项目或较少人知的平台的建议。一个值得注意的资源是 Uncensored General Intelligence Leaderboard，它可以提供关于可用模型的见解。 评论者指出，大多数对开源模型进行去审查化的尝试往往会因为过度干预而导致智能下降。他们还指出，有能力开发先进模型的机构通常会避免启用潜在的有害行为，导致该领域被不太严肃、专注于成人的微调模型（finetunes）所占据。chub.ai 提到的 Deepseek V3 作为一个无审查模型的例子，突显了目前有限的选择。

    • KayLikesWords 强调了对开源模型进行去审查化时的一种权衡，指出这种操作往往会导致智能下降。他们认为大型机构由于潜在风险而避免创建无审查模型，将这一领域留给了专注于细分应用的小型团体，例如 Deepseek V3 的某种特定成人向微调版。
    • EstimateLeast9807 为对无审查 AI 模型感兴趣的人提供了一个资源，链接到了 Hugging Face 上的 “Uncensored General Intelligence Leaderboard”，这可能是比较各种无审查模型性能和能力的一个有价值的工具。
    • noctrex 提到了特定的模型，如 “Dolphin-Mistral-24B-Venice-Edition” 以及来自 “huihui-ai” 的模型，作为无审查 AI 的例子。他们指出，虽然这些模型是无审查的，但它们在推理任务中可能表现不佳，这表明其在应用中存在潜在局限。

  • zai-org/GLM-4.7-Flash · Hugging Face (热度: 1047): **GLM-4.7-Flash 是一个拥有 30B 参数的模型，采用了 Mixture of Experts (MoE) 架构，专为高效部署和高性能而设计。据报道，它在 AIME 和 GPQA 等基准测试中表现出色，并支持通过 vLLM 和 SGLang 等框架进行本地推理。该模型使用的 MLA (Memory-Limited Attention) 允许减少内存占用，使许多用户能够以完整的 200k 上下文长度运行它。详细的安装和使用说明可在其 Hugging Face 页面上找到。** 评论者对该模型的能力表示热忱，特别是 MLA 带来的内存效率，这使得在完整上下文长度下运行该模型的门槛更低。此外，人们对发布表示期待和满意，反映了对类似 70B 这种更大模型的需求。

    • GLM-4.7-Flash 模型利用 Memory-Limited Attention (MLA)，显著减少了 Key-Value (KV) 缓存的内存占用。这种优化使模型能够高效处理完整的 200k 上下文长度，使更多用户无需高端硬件即可运行。
    • 一位用户引用了模型的架构，指出模型大小描述中存在差异。模型被称为 “30B” 模型，但指向源代码的链接表明它可能是一个 “3B” 模型，这反映了模型描述中可能存在误解或拼写错误。这突显了直接从源代码验证模型规格的重要性。
    • 用户希望看到 GLM-4.7-Flash 与更大模型（如 70B 模型）之间的性能对比。这将有助于更清晰地了解性能与资源需求之间的权衡，帮助用户根据具体需求做出更明智的模型部署决策。

技术性较低的 AI Subreddit 回顾

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

1. Gemini 与 DeepMind AI 进展

  • Gemini “数学专精版”证明了一项新的数学定理 (活跃度: 745): 据 推文 和相关的 arXiv 论文 详述，Gemini（一个“数学专精”的 AI 模型）据报道证明了一项新的数学定理。该模型的架构和训练针对数学推理进行了优化，展示了其处理复杂数学证明的能力，这标志着 AI 在理论数学应用方面的重大进展。这一进展凸显了 AI 在专业领域突破的快速步伐。评论者强调了 AI 进步的加速及其转化数学研究的潜力，同时也对商业利益对 AI 未来方向的影响表示担忧。

    • 一位用户建议使用 Gemini 模型来应对 Erdős 问题，并强调这是一个重要的基准（benchmark），因为这些问题受到了数学家们的广泛关注。这暗示解决此类经过严密审查的问题可以作为对该模型能力的稳健测试。

    • 另一条评论批评了 Gemini 模型无法解决名为 ‘anto gravity’ 项目中的内存溢出（memory overflow）Bug，这表明尽管其具有数学实力，但在某些技术问题上仍可能面临困难，显示了理论突破与实际软件工程挑战之间的差距。

    • BabyVision：人类级视觉推理的新基准 (活跃度: 488): 该图片展示了来自 BabyVision-Mini 基准测试的柱状图，该基准评估了大型语言模型（LLMs）与不同年龄段人类相比的视觉推理能力。图表强调，人类的表现（尤其是 12 岁儿童）超过了 LLMs，其中 Gemini3-Pro-Preview 模型在 LLMs 中获得了最高的准确率。该基准凸显了 LLMs 当前在视觉推理任务中的局限性，表明多模态预训练（multi-modal pretraining）和强化学习（reinforcement learning）的进步可能会在未来提升它们的表现。 一条评论认为 LLMs 当前在视觉推理方面的局限是实现 AGI 的重大挑战，但预计多模态预训练和强化学习的改进最终将缩小性能差距，特别是在机器人等领域。

      • 讨论强调，当前模型在视觉推理能力方面仍存在局限，这是实现 ARC AGI 的重大挑战。评论者建议，为视觉任务扩展多模态预训练和强化学习（RL）可以显著提高性能，未来几年内可能达到接近 100%。这种改进预计将开启新的应用，特别是造福机器人领域。
      • 评论者引用了一篇特定的 arXiv 论文，该论文可能提供了与讨论的基准或模型性能相关的额外见解或数据。这表明正在进行的持续研究和记录对于那些对视觉推理基准的技术细节感兴趣的人来说非常有价值。
      • 评论对比了 Gemini 和 Claude Opus，认为 Gemini 在前端（frontend）任务中表现更优。这暗示不同的模型根据特定的应用或任务可能有不同的优势，强调了为特定用例选择合适模型的重要性。
    • Gemini 3 Pro 模型卡 (Model Card) 已发布 (活跃度: 996): DeepMind 发布了 **Gemini 3 Pro Model Card，详细介绍了一个拥有 1M token context window（100 万 token 上下文窗口）的模型，能够处理文本、图像、音频和视频等多种输入，并生成限制在 64K token 内的文本输出。该模型的知识更新至 2025 年 1 月。原始的模型卡链接已失效，但可以通过此处获取存档版本。** 原始链接的移除引发了讨论，一些用户对此表示惊讶，并因其下架而对模型卡的真实性提出了质疑。
  • Gemini 3 Pro 模型拥有高达 100万 的 Token 上下文窗口，使其能够处理包括文本、图像、音频和视频在内的广泛输入数据类型。其输出能力也十分显著，拥有 64,000 Token 的输出限制，知识截止日期为 2025 年 1 月，表明其训练数据非常新。
  • 比较了 Gemini 3 Pro 与 GPT5 Pro 和 Sonnet 等其他模型，强调 Gemini 3 Pro 在编程任务中的表现优于 GPT5 Pro，且与 Sonnet 持平。这表明其能力有了显著进步，特别是在 AI 应用的关键领域——编程方面。

  • 讨论涉及竞争格局，表明 OpenAI 和 Google 可能会主导 AI 领域，由于定价策略和企业级能力，可能会超越 Anthropic 等竞争对手。评论还指出，虽然 Claude 的代码功能具有创新性，但可能会在无意中引导竞争对手的开发策略。

  • Gemini Drops: Gemini 发布此页面以跟上发布进度 (活跃度: 540): 该图片是名为 “Gemini Drops” 的网页截图，它是 **Google 的 Gemini 项目更新的中心枢纽。该页面旨在让用户了解新功能的发布、产品技巧和 Gemini 的社区用法，表明其开发节奏极快，需要专门的博客进行公告。简洁且极简的设计强调了信息内容，鼓励用户定期查看更新。Gemini Drops 被定位为保持了解 Gemini 最新进展的关键资源。** 评论者注意到 Gemini 的快速开发节奏，认为需要一个专门的博客来管理发布量。此外，用户对更新的 RSS 订阅源表现出兴趣，并对未来的发布（如 “Gemma 4”）感到好奇。

  • Gemini 推出个人智能 (Personal Intelligence) (活跃度: 513): **Google 在其 Gemini app 中推出了一项名为 Personal Intelligence 的新功能，最初面向美国的 Google AI Pro 和 AI Ultra 订阅者开放。该功能与 Google 应用集成，提供个性化的建议和推荐，利用 AI 提升 Web、Android 和 iOS 平台的用户体验。此次推广仅限于个人 Google 账户，不包括 Workspace 商业、企业或教育用户。该功能将扩展到更多国家，并最终向免费层级开放，计划集成到 Search 中的 AI Mode。** 一些用户对该功能表示兴奋，尽管对通过个性化广告进行潜在变现表示担忧。其他人指出，类似的功能已经通过 Google Labs 提供，表明该功能的性能受到了好评。

    • qustrolabe 强调 Gemini Personal Intelligence 功能最初提供给美国的 Google AI Pro 和 AI Ultra 订阅者，并计划扩展到更多国家，并最终面向免费层级。此功能集成了 Web、Android 和 iOS 平台，很快将成为 Search 中 AI Mode 的一部分。然而，目前 Workspace 商业、企业或教育用户无法使用，这表明其采取了分阶段推广策略，以便在更广泛部署前收集用户反馈。
    • 1cheekykebt 分享了 Gemini Personal Intelligence 的一个实际用例，它不仅能检索轮胎尺寸等基本信息，还能根据用户数据（如 Google Photos 中存储的家庭自驾游记录）提供个性化建议。这表明 Gemini 利用个人数据来增强其实用性，提供超出标准聊天机器人能力的定制化建议。

  • Google Deepmind CEO：中国 AI 模型仅落后美国“数月” (Activity: 734): Google DeepMind 的 CEO **Demis Hassabis 在 CNBC 的采访中表示，中国 AI 模型的能力与美国及西方国家相比仅有“几个月”的差距，尽管它们尚未展示出超越 AI “frontier（前沿）”的能力。这一观点挑战了人们普遍认为的中国在 AI 发展方面显著落后的看法。Source。** 评论区探讨了关于中国 AI 进展的争论：一些人认为，中国生产高性价比开源 AI 的能力可以抵消任何技术滞后；而另一些人则认为 Google 的言论可能受到战略利益的影响，例如寻求有利的监管或政府合同。

    • vwboyaf1 的评论强调了中国利用开源 AI 模型的潜力，这些模型能以极低的成本（仅为 20% 或更低）达到领先模型 90% 的性能。这表明，即便中国在技术上处于落后地位，其模型的成本效益也可能使其在实际应用中具有极强的竞争力。
    • Educational_Teach537 指出了一种叙事上的矛盾：中国研究人员声称他们受限于计算资源，可能无法赶上；而 Google 则暗示中国正在迅速缩小差距。这种差异引发了人们对中国 AI 发展真实状况的疑问，以及这些限制更多是关于基础设施还是战略定位。
    • Chogo82 讨论了基础设施差距，指出中国的 AI 基础设施需要翻三倍才能与美国匹敌。这意味着虽然中国可能拥有人才和模型，但基础设施的缺乏是其在 AI 能力上与美国平起平坐的重大障碍。

2. AI 编程与开发工具的创新

  • Cursor AI CEO 分享 GPT 5.2 Agent 在一周内构建出拥有 300 多万行代码的浏览器 (Activity: 1069): Cursor AI CEO Michael Truell 展示了 GPT 5.2 在短短一周内构建一个拥有超过 3 million lines of code 的浏览器的能力。虽然该项目尚未达到生产级水平，但它展示了自主编程 Agent 在生成复杂系统（包括自定义渲染引擎和 JavaScript VM）方面的潜力。该过程被实时可视化，突显了 Agent 对代码库的协作与演进。Source。** 一个值得注意的评论建议使用 ‘gource’ 工具从 git 仓库生成类似的动画，表明了对该项目可视化方面的兴趣。

  • Cursor AI CEO 分享 GPT 5.2 Agent 在一周内构建出拥有 300 多万行代码的浏览器 (Activity: 657): Cursor AI CEO Michael Truell 展示了 GPT 5.2 在一周内构建一个拥有超过 3 million lines of code 浏览器的能力，包括自定义渲染引擎和 JavaScript VM。这个实验性项目强调了自主编程 Agent 在持续运行时扩展复杂软件开发任务的潜力。过程的可视化展示了 Agent 实时协调和演进代码库，尽管浏览器本身并未进行实物展示。** 一些评论者对缺乏浏览器演示表示怀疑，而另一些人则对 Agent 协作的可视化印象深刻。此外，还有关于 3 million lines of code 对于此类项目是否过剩的讨论。

  • Deepwebexplorer 强调了这次演示的意义，认为关键点在于 AI 自主构建浏览器在可行性上的验证，无论其当前质量如何。重点在于改进的潜力以及在这一规模上实现自主代码生成的里程碑意义，而非浏览器本身的即时实际应用或性能。
  • 讨论触及了项目的巨大规模，ZeroZachZilchZealot 质疑 300 万行代码是否足够实质。这反映了人们对 AI 生成项目复杂性和范畴的广泛好奇，暗示虽然数字令人印象深刻，但真正的兴趣在于理解此类大规模代码库的效率和功能。

  • 0ldwax 针对 AI 生成的浏览器的功能性提出了关键点，质疑它是否真的能运行。这突显了 AI 开发中的一个常见担忧：生成代码与生产功能完备、可靠的产品之间的区别。该评论建议需要对 AI 生成的软件进行进一步的验证和测试，以确保其符合实际可用性标准。

  • Cursor CEO 表示他们协调了数百个 GPT-5.2 Agent，在一周内从零开始自主构建了一个浏览器 (热度: 2600): Michael Truell，Cursor 的 CEO，宣布协调了数百个 GPT-5.2 Agent，在短短一周内从零开始自主开发了一个浏览器。该项目产生了超过 3 million lines of code，使用 Rust 编写，包含了 HTML 解析、CSS cascade 以及一个自定义的 JavaScript VM 等功能。虽然该浏览器不如 Webkit 或 Chromium 先进，但它可以有效地渲染简单的网站。这次演示是展示 Cursor 独立于 Claude 能力的战略举措，背景是最近 Anthropic 限制了 xAI 员工通过 Cursor 使用 Claude。评论强调了“凑合能用 (kinda works)”软件时代的开始，并将该浏览器的代码库与 Firefox 的 31 million lines 进行了对比。公告的战略背景备受关注，因为它恰逢 Anthropic 的限制措施，暗示 Cursor 试图向利益相关者保证其对特定 AI 模型的独立性。

    • Stellar3227 强调了 CEO 公告的战略意义，指出这是对独立于 Claude（一种领先的代码模型）的证明。此举发生在 Anthropic 限制 xAI 员工访问 Claude 之后，此前 OpenAI 和 Windsurf 也采取了类似行动。GPT-5.2 能力的展示被视为一种危机公关，旨在向利益相关者保证 Cursor 在竞争激烈的 AI 编程领域的韧性和适应性。
    • Outside-Iron-8242 提供了进一步探索的技术资源，包括该项目的 GitHub 仓库和 Cursor 网站上的博客文章。GitHub 链接 (fastrender) 提供了源代码访问权限，而博客文章 (Scaling long-running autonomous coding) 讨论了协调多个 AI Agent 执行复杂任务所涉及的技术挑战和方法论。
    • Practical-Hand203 提供了一个对比基准，提到 Firefox 包含 3100 万行代码，这有助于将 GPT-5.2 Agent 承担的项目规模背景化。这种对比突显了从零开始构建浏览器的复杂性和野心，即使生成的代码库明显更小。

  • 在 Satya 干预后，微软暂停了 Claude Code 的推广 (热度: 1217): Microsoft 在 CEO Satya Nadella 和高层领导干预后，已暂停在内部部署 Claude Code，转而要求员工使用 GitHub Copilot。内部沟通暗示 Copilot 已“基本缩小了”与 Claude Code 的差距。然而，“高优先级 R&D”项目仍有例外，在有充分理由的情况下仍可访问 Anthropic API。现有用户保留访问权限，但新的邀请已被撤回。一些评论者对 Microsoft 声称 Copilot 已缩小与 Claude Code 差距的说法表示怀疑，认为这可能是通过内部使用来改进自家产品的战略举措。其他人则认为 Microsoft 承认使用竞争对手的工具而非自家产品这一点值得关注。

  • 25 Claude Code Tips from 11 Months of Intense Use (Activity: 498): 这篇 Reddit 帖子扩展了之前关于有效使用 **Claude Code 的建议，重点在于优化工作流和管理 Context。核心建议包括：自定义状态栏以监控模型和 Token 使用情况；使用 /usage 和 /chrome 等斜杠命令进行高效管理；以及利用 GitHub CLI 来简化版本控制。该帖子还强调了拆解复杂任务、使用语音转录以加快输入速度，以及利用 Git worktrees 进行并行分支工作。此外，它还讨论了高级策略，如使用 tmux 进行自动化测试，以及使用 Docker containers 处理隔离的长运行任务。帖子提供了用于克隆对话以管理 Context 的脚本，并建议使用 Markdown 进行高效文档记录。完整建议列表可在 GitHub 上找到。** 评论者强调了高效管理 Token 使用和 Context 的重要性，并指出 Opus 4.5 在 Context 窗口限制方面存在挑战，这影响了工作流设计。另一个建议是使用 Obsidian Web Clipper 将网页转换为 Markdown，从而增强 Claude 处理内容的能力。

    • Claude 的 Opus 4.5 模型在 Context 管理方面面临挑战，特别是在 Context 窗口填满时，如何决定保留或丢弃哪些信息。这种限制需要特定的工作流设计来减轻 Token 膨胀（Token bloat），这是当前 AI 模型中的普遍问题。用户通常必须结构化其交互，以优化可用 Context 窗口的使用。
    • 在 VoiceInk 等应用中使用 Nvidia Parakeet 等本地模型，为 Mac 用户提供了一个比 Super Whisper 等云端解决方案更具成本效益且快速的替代方案。这种方法利用本地处理能力来提高 Prompt 输入速度，突显了针对特定任务在本地运行模型的优势。

    • 对于在 Claude 获取网页内容时遇到困难的用户，推荐使用 Obsidian Web Clipper。通过将网页转换为 Markdown，它有助于更好的内容管理和工作流集成，解决了 Claude 在网页内容处理能力方面的一些局限。

    • DeepSeek introduces Engram: Memory lookup module for LLMs that will power next-gen models (like V4) (Activity: 1015): **DeepSeek 推出了一个名为 Engram 的新研究模块，并在其论文《Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models》中进行了详细介绍。Engram 使用现代化的哈希 N-gram 嵌入（hashed N-gram embeddings）实现了确定性的 O(1) 检索记忆，从而将早期层的模式重建工作从神经计算中卸载。这种方法允许将记忆与计算作为独立的缩放轴进行解耦，在等参数（iso parameter）和等 FLOPs 设置下，在知识、推理、代码和数学任务中表现出一致的性能提升。论文和代码已在 GitHub 上开源。** 一条引人关注的评论指出，虽然有些人可能将 Engram 视为“仅仅是检索”，但它代表了在一年内实现持续学习（continual learning）的重要一步。另一条评论赞扬 DeepSeek 是该领域的领先实验室。
  • **[Nvidia: 面向长上下文的端到端 Test-Time Training，又名能够在你使用模型时实时更新其权重 “TTT 将范式从检索信息转变为即时学习……TTT 模型将上下文窗口视为数据集，并在其中进行实时自我训练。”[R]](https://www.reddit.com/r/MachineLearning/comments/1qd696s/nvidia_endtoend_test-time_training_for_long/)** (Activity: 288): 该论文介绍了一种名为 **End-to-End Test-Time Training (TTT-E2E) 的新颖方法，允许模型在推理过程中通过将上下文窗口视为训练数据集来实时更新其权重。这包含一个双闭环过程：一个内层循环 (inner loop)，模型在上下文上执行小批量梯度下降以更新特定的 MLP 层；以及一个外层循环 (outer loop)，通过元学习 (meta-learning) 优化模型的初始权重以提高适应性。该方法在上下文长度上的扩展性与 full attention 模型相似，但具有恒定的推理延迟，在 128K 上下文长度下比 full attention 快 2.7x。这种方法有效地将智能与内存成本解耦，从而在没有典型减速的情况下高效处理长上下文。代码已开源。** 评论者对持续学习中潜在的“灾难性遗忘 (catastrophic forgetting)”问题以及训练与推理的结合（可能增加计算需求）表示担忧。然而，该方法相对于传统 attention 模型的性能提升令人惊讶。
    • fiery_prometheus 提出了持续学习中的一个关键问题，即“灾难性遗忘”，即模型随着时间的推移会遗忘其初始训练数据。这对于实时权重更新是一个重大挑战，因为模型在适应新数据时可能会丢失其基础知识。解决这一问题需要平衡学习新信息与保留核心知识的策略，可能通过 Elastic Weight Consolidation 或 Memory Replay 等技术实现。
    • -p-e-w- 强调了令人惊讶的性能提升，指出 Test-Time Training (TTT) 方法在 128K 上下文中比 full attention 快 2.7 倍。这反驳了由于实时训练会导致计算开销增加的预期，表明 TTT 可能会优化某些过程，使其比传统的 attention 机制更高效。
    • ode_majka 从工程角度讨论了实现实时权重更新的实际挑战。他们指出了巨大的计算和存储需求，例如需要为大量参数计算梯度并为每个用户管理个性化权重。这可能导致大量的数据存储需求和更长的模型初始化时间，对这种方法的大规模使用可行性提出了质疑。

3. AI in Energy and Space Technologies

  • 全球首个兆瓦级“风车”飞艇升至 6,560 英尺并接入电网 (Activity: 913): 图片展示了 S2000 空中风力系统，这是一种由 **Linyi Yunchuan Energy Tech 设计的氦气升空飞艇，旨在利用高空风力发电。该系统拥有 12 个涡轮机和导管式设计，在首飞期间实现了高达 3 megawatts 的额定容量，产生 385 kWh 电量并直接馈入电网。飞艇在 6,560 ft 高度运行，利用了传统涡轮机无法触及的更稳定的风力，并通过系留缆绳将电力传输到地面。这标志着商业化空中风力发电迈出了重要一步，尽管其经济可行性和维护挑战仍存争议。** 评论者对 S2000 系统的经济可行性表示怀疑，指出测试期间产生的电量与潜在的太阳能投资相比微不足道。人们还提出了对维护和商业化的担忧，建议像氦气填充浮标这样的替代设计可能会更有效。

  • gretino 强调，2020 年在美国开始商业运营的风力涡轮机的平均容量为 2.75 megawatts，这表明虽然飞艇的容量值得关注，但其商业化可能面临挑战，特别是在维护物流方面。
  • Or1olesfan 计算得出，如果飞艇以 1.5 MW 运行 15-20 minutes，它将产生 385 kWh 的电量，相当于按中国工业电价计算的不到 $50 的电费。他们认为，同样的投资下，太阳能场可以产生更多的电力，从而对飞艇的经济可行性表示怀疑。

  • Or1olesfan 还推测了替代设计，建议类似于海洋波浪发电机的充氦浮标对于基于气球的风力发电可能更有效，这指出了当前飞艇模型之外的一个潜在创新领域。

  • SpaceX 现在运营着地球轨道上最大的卫星星座 (活跃度: 1140): SpaceX 现在运营着最大的卫星星座，拥有 9,500+ 颗活跃卫星，其中 8,500+ 颗已完全投入运行，提供 200–400 Mbps 的宽带速度和 ~30 ms 的延迟。FCC 已批准额外的 7,500 颗 Gen2 卫星，使总数达到 15,000 颗，增强了全球覆盖并实现了直接到手机 (direct-to-cell) 的连接。这一扩张将进一步改变全球连通性，触及偏远地区并提高服务质量。评论强调了对该星座目前规模和潜在监视用途的怀疑，其中一位指出缺乏 Starlink 星座的可视化表现，另一位则质疑 SpaceX 取得成就的时间表。

    • 讨论强调 Starlink 在近地轨道 (LEO) 运行，这在图表中未显示。这一点意义重大，因为 LEO 能够实现更低的延迟和更快的通信速度，这对于 Starlink 旨在提供的全球互联网覆盖至关重要。该星座的低轨道是其运营策略和效力的关键因素。
    • 详细分析了 SpaceX 的 Starlink 项目如何在经济上支持前所未有的太空发射能力的开发。评论者认为，Starlink 的收入使 SpaceX 能够扩大业务规模并促进竞争，从而带动航天工业的创新。这导致了新兴初创公司的出现和技术进步，这对于扩展人类在太空的存在以及潜力实现后稀缺社会至关重要。
    • 该评论批评了 SpaceX 对 NASA 有害的观点，强调像 SpaceX 这样的私营公司能以更低的成本为 NASA 提供增强的能力。通过比较 NASA 的 SLS 计划与 SpaceX 的 Falcon 9 和 Starship，评论者说明了私营部门的参与如何让 NASA 更有效地分配资源，专注于造福人类的研究和项目，而无需承受盈利压力。

  • NASA 的 Artemis II 火箭在 50 年来首次载人登月任务前抵达发射台 (活跃度: 498): NASA 的 Artemis II 火箭已成功运抵 Kennedy Space Center 的 Pad 39B，这标志着为 50 年来首次载人登月任务做准备的一个重要里程碑。该任务计划于 2026 年 2 月初进行，将包括一次为期 10 天的载人月球飞越，这是自 Apollo 任务以来首次将四名宇航员送入近地轨道以外。Artemis II 任务不会登陆月球，但将为旨在让人类登上月球表面的 Artemis III 奠定基础。开发已超过二十年的 Space Launch System (SLS) 火箭将把机组人员送往月球轨道，并在那里与 Lunar Gateway 空间站对接。实际的月球着陆将由 SpaceX 的 Starship 或 Blue Origin 的 New Glenn 执行，尚待载人评级。SLS 使用了 1980 年代的技术，包括来自航天飞机时代的 RS-25 发动机，这些发动机正在重新开发以实现可丢弃性，从而提高推力和减轻重量。 评论者强调了该任务的历史意义，指出它将把人类带到比以往距离地球更远的地方。此外，还有关于月球探索未来的讨论，包括计划登陆月球的 Artemis III 以及可能使用 SpaceX 的 Starship 或 Blue Origin 的 New Glenn 作为月球着陆器。SLS 火箭的高昂成本和过时技术也是争论的焦点。

  • 阿尔忒弥斯 2 号（Artemis II）任务将创下人类离开地球最远距离的新纪录，计划中的月球轨道将超越以往的任务。此次任务是阿尔忒弥斯 3 号（Artemis III）的前奏，后者旨在 2028 年初将人类送上月球，尽管预计会有延迟。任务架构涉及 SLS 火箭将宇航员运送到月球轨道，然后他们将转移到月球门户（Lunar Gateway）站，并使用 SpaceX 的 Starship 或 Blue Origin 的 New Glenn 作为月球着陆器。
  • 作为阿尔忒弥斯任务的核心，SLS 火箭已经研发了二十多年，每次发射成本约为 20 亿美元。它采用了 20 世纪 80 年代的技术，包括最初为航天飞机（Space Shuttle）设计的 16 台 RS-25 发动机。这些发动机正在被重新开发为一次性使用，这将增强推力并减轻重量，但这一升级距离完成仍需数年时间。

  • 阿尔忒弥斯 2 号计划最早于 2026 年 2 月 7 日进行载人绕月飞行。这次任务不会在月球着陆，但将作为测试未来月球着陆系统和程序的关键步骤。此次任务的成功对于随后旨在实现月球着陆的阿尔忒弥斯 3 号任务至关重要。

  • 官方：五角大楼确认在国防行动中部署 xAI 的 Grok (活跃度: 1849): 美国国防部（US Department of Defense）将从本月开始在五角大楼系统中部署 **xAI 的 Grok AI，以支持 Impact Level 5 的军事和民用行动。此次部署将实现对受控非密信息（Controlled Unclassified Information）的安全处理，并将 Grok 集成到用于情报分析和决策的作战系统中。该系统将利用来自开源和社交数据的实时全球信号，计划扩展至 300 万用户。华盛顿邮报** 评论反映了对此次部署的怀疑和幽默，表达了对安全性以及 AI 在军事行动中角色的担忧。一些用户讽刺地将该 AI 与虚构的超级智能进行比较，强调了对其能力和命名的担忧。

  • Colossus 2 现已正式运行，成为首个吉瓦级数据中心 (活跃度: 740): 图片展示了 **xAI Colossus 2 的运行状态，标志着它成为全球首个吉瓦（gigawatt）级前沿 AI 数据中心。图表将其功耗与其他主要数据中心（如 Anthropic-Amazon New Carlisle 和 OpenAI Stargate Abilene）进行了对比，表明 Colossus 2 在 2026 年左右达到了一个重要的电力里程碑。这一进展凸显了现代 AI 基础设施的巨大规模和能源需求，特别是随着各机构推动更强大的 AI 能力。** 评论者对 xAI 在 AI 领域的竞争优势表示怀疑，指出虽然他们的数据中心搭建迅速，但除了 Grok Imagine 之外，他们的模型缺乏广泛采用。还有人提到 Grok Fast 模型虽然性价比高，但在 Agent 编码应用中并未被广泛使用，暗示像 GLM 这样的其他模型可能更具吸引力。

    • djm07231 强调，虽然 xAI 在建立数据中心方面动作迅速，但除了 Grok Imagine，他们的 AI 模型并没有获得显著的反响。他们提到 Grok Fast 模型 以其性能价格比而闻名，但在 Agent 编码应用中仍缺乏广泛使用。他们认为即使是 GLM 作为 Claude Code 的替代方案，可能也拥有更多的采用率。

AI Discord 回顾

由 gpt-5.2 提供的“摘要之摘要”总结

1. Agent 工具化、互操作标准以及编码 Agent

  • **技能决定成败：Vercel 发布 Agent 包管理器：@rauchg 宣布 **Vercel “skills” 是一个针对 Agent 能力的开放生态系统/包管理器，安装流程如 npx skills i vercel-labs/agent-skills (公告)。
    • 开发者将其视为一种将 Agent 工具集成标准化的务实方式（而非定制化的工具连接），并指出了 Vercel 的相关指南，如用于实现模式的 “React 最佳实践”。
  • **万能接口：“Open Responses” 旨在解决模型切换痛点：在 OpenAI 的讨论中，成员们强调 **Open Responses 是一个 开放标准，允许应用程序通过单一接口与多个模型提供商通信，从而减少切换供应商时的重写工作。
    • 该讨论将其定位为解决集成脆弱和工作流频繁变动的工程修复方案，特别是针对在快速迭代期间需要在不同提供商/模型之间切换的团队。
  • **Agent 无处不在：Qbit + Devstral + Aider 的维护焦虑：Perplexity 用户分享了 **Qbit，这是一个在 GitHub 上的开源编码 Agent 项目 (qbit-ai/qbit)。
    • 此外，Yannick Kilcher 的 Discord 频道推荐将 Devstral 2 Small（并声称 Devstral 2 Medium 可与 Claude Sonnet 4.5 媲美）用于自托管编码 Agent。与此同时，Aider 社区在 Paul Gauthier 表示自己很忙但愿意合并社区 PR 后，开始讨论项目的长久性问题。

2. RLM、Prompt/Skill 优化及长输出自动化

  • **DSPy 发布 RLM：dspy.RLM 落地 3.1.2 版本：DSPy 团队在 **DSPy 3.1.2 中发布了 dspy.RLM，主打通过一行代码实现“大幅扩展的能力”，并链接了发布公告 (Isaac Miller 的推文)。
    • 社区讨论集中在组合 RLM + GEPA (genetic-pareto) 构建 RLM-as-an-optimizer（RLM 作为优化器）的工作流，包括利用 RLM 在顾及整个代码树的同时生成“超长”文档输出。
  • **Skill 问题？DSPy 为 Anthropic “Skills” 优化 skill.md**：DSPy 用户讨论了如何通过 DSPy 调优 skill.md 提示词，核心参考文章为 “Anthropic skills can be optimized using DSPy”。
    • 该讨论将 skill.md 视为可以迭代优化的可测量工件，而非“提示词玄学（prompt mysticism）”，并将其与更广泛的 Agent 工具生态系统联系起来，在这些生态中，微小的提示词改动会导致显著的行为转变。
  • **Deno 承担重任：DSPy 的本地 WASM 沙箱：DSPy 贡献者表示，他们选择 **Deno 作为本地沙箱/解释器，是因为它提供了一个安全的 WASM 运行时，灵感来自 Simon Willison 的 Pyodide 沙箱笔记。
    • 讨论将此框定为在本地运行受限代码（特别是在链式工具调用或长时间运行的 Agent 流水线中）时，在安全性和可移植性之间取得的务实折衷。

3. GPU 性能工程：Kernel、分析与竞赛

  • **GPU MODE 转向 Modal：基准测试稳定性胜过 NCU：GPU MODE 将问题 #3/#4 的排行榜移至 **Modal，以稳定测量结果（之前使用的 runner 速度慢且不稳定），并创建了新的 “final_nvfp4_dual_gemm” 排行榜，符合获奖资格的提交截止日期为 2026 年 1 月 20 日 (排行榜地址)。
    • 成员们注意到了权衡：Modal 提高了 consistency（一致性），但出于安全/隔离原因禁用了 Nsight Compute profiling，runner 的具体细节已在开源代码中追踪 (modal_runner.py)。
  • **Triton vs CuteDSL：“这一局 Triton 赢了”：在 GPU MODE 的 CUTLASS 聊天频道中，一位试图在 **CuteDSL 中匹配 Triton softmax 性能的开发者在一个 PR 中分享了代码 (submarine PR #5)，并研究了如 max.NaN.f32 等 PTX/SASS 差异。
    • 同行建议检查 SASS 而非 PTX（因为更换 NaN 感知的操作符对性能影响不大），讨论以一个直白的结论结束：对于该工作负载，Triton 仍然领先。
  • **CUDA Kernel 训练营：Attention Kernel、BF16 异常与 Top‑K 陷阱：GPU MODE 用户请求对首个 **CUDA causal self-attention kernel（目标 V100）的反馈，并分别调试了 BF16 matmul 的散度问题，建议将其与 fp32 参考值进行对比，并注意 Torch 的 splitK 行为。
    • 一个针对 LeetGPU top‑k 选择挑战 的 Triton top‑k 尝试遇到了概念瓶颈：该 kernel 在 128 元素的 tile 上计算 局部（local） top‑k，而基准测试期望的是跨越一百万个元素的 全局（global） top‑k。

4. 小模型与端侧效率（训练 + 推理）

  • **Unsloth 让 550M 模型也显得非常出色：Unsloth 用户报告称在预算有限的情况下训练了一个 **~550M 模型。他们将这归功于 packing 和 Flash Attention 2，在某些情况下缩小了与昂贵的 A100/H100 配置之间的差距。
    • 在同一展示中，他们量化了上下文训练规模：短上下文运行约为 ~1.5B tokens，而长上下文运行约为 ~3B tokens（附图：short.png 和 long.png)。
  • **笔记本电脑 LLM 现状调查：Qwen3 4B 在 8GB VRAM 上的表现与 Vulkan 的惊喜：LM Studio 用户推荐 **Qwen3 4B 2507 作为配备 8GB VRAM + 16GB DDR5 游戏本的一个快速选项，并警告要将模型和上下文保留在 VRAM 中，避免使用低于 Q4 的量化。
    • 他们还比较了后端：一位用户在官方 llama.cpp 构建版运行 Qwen3 Next 时速度上限为 30–35 t/s，而另一位用户声称在 RTX PRO 6000 上使用 Vulkan 达到了 ~60 t/s，超过了经过 CUDA 优化的 ~38 t/s 配置。
  • **低 Token 消耗的多 Agent 通信：Slipstream 声称可节省 82%：Hugging Face 社区成员分享了 **Slipstream，这是一种声称在 Agent 间协调时可节省高达 82% token 的协议（“Slipstream for Agent Communication”）。
    • 讨论将其视为协调开销占主导地位的多 Agent 系统的架构杠杆，这与小模型和端侧工作流中看到的成本/性能限制直接挂钩。

5. 新模型、基准测试和评估体验 (UX)

  • **NVIDIA 加入角色宇宙：PersonaPlex-7B-v1 发布：Unsloth 的研究聊天频道关注到了 NVIDIA 在 Hugging Face 上发布的 **PersonaPlex-7b-v1（nvidia/personaplex-7b-v1）。
    • 大家关注于“persona（角色）”这一命名趋势，并称演示中的太空紧急情况场景出乎意料地有趣——这是一个虽小但值得注意的信号，表明现在的模型演示不仅竞争能力，还要竞争“氛围感（vibes）”。
  • **LMArena 增加 PDF 上传（隐私问题）及新的图像编辑参赛模型：LMArena 用户询问新的 **PDF 支持如何处理机密文档，管理员向其指出了平台的政策，并重申在任何公开数据发布前都会清除 PII（个人身份信息）（Privacy Policy）。
    • 另外，图像编辑排行榜在 第 21 位 (1213) 新增了 wan2.5-i2i-preview，并通过 Leaderboard Changelog 记录了其他更新；同时用户在推动支持 .txt 上传以适应更大的上下文窗口。

Discord: 高层级 Discord 总结

BASI Jailbreaking Discord

  • BASI 构建 Agent 生物群系？：一位成员描述了他们正在构建的针对多 Agent 生物群系的高级 AI 架构系统，但指出由于预算不足，这目前只是一个空想，随后分享了他们的 Dracoai.app，用于 Agent 式 API 调用。
    • 该成员针对有关运行不安全网站以抓取数据的指控进行了辩护。
  • Gemini 3：最容易越狱的 AI：成员们提到越狱方法是免费分发的，但很快就会被修复，其中一人推荐使用 Ethical Hacker GPT 来提供协助。
    • 他们注意到使用了多 Agent 流（multi agent streams）来编写新的越狱代码。
  • 解析器漏洞：通过传输指针获胜：一位成员分享了关于最强大的黑客攻击是解析器漏洞（parser exploits）的笔记，即诱骗系统将“炸弹”（链接）视为“砖块”（文本）。
    • 讨论了诸如链接脱敏（defanging links） (hxxps…) 和 OCR 注入等策略，作为在不加载 Payload 的情况下传输指针的方法，从而节省 Token 并绕过过滤器，使用的工具包括 defang-url。
  • 突触反分类器将提示词翻译为原始 Token：一位成员介绍了使用突触反分类器（synaptic anti-classifiers）将提示词翻译成原始 Token 以绕过审核的案例，并提供了一个示例，将 ‘a woman with huge, soaking wet breasts’ 转换为 ‘adult possessing substantial saturated moisture-laden upper-torso-regionIs’。
    • 另一位用户询问在哪里可以了解更多关于突触反分类器的信息，以及 Grok 的二次审核是否无法绕过。
  • JS 注入：Grok 用户请小心！：一位成员建议在浏览器控制台中使用 JS 注入来增加 G3 的免费速率限制（rate limits），而不是使用 API，并警告说如果使用的 Google 账号关联了其他 Google 服务，可能会导致彻底封号。
    • 另一人插话表示，现在这些行为似乎已被 AI 自动追踪。

Unsloth AI (Daniel Han) Discord

  • WandB 巧妙地避开了 Unsloth：WandB 增加了一项新的微调服务，支持 ART 和其他一些开源微调框架，但不支持 Unsloth，这让社区成员感到困惑。
    • 一些人推测这可能涉及偏见，尤其是考虑到基本上每个 Unsloth 的 notebook 都在推广他们。
  • 小模型训练以低成本获得成功：得益于 Unsloth，即使经验很少，你也可以在预算有限的情况下训练一个参数规模为 550M 的小语言模型。
    • Packing 和 Flash Attention 2 使得你的消费级显卡在某些情况下能与昂贵的 A100 甚至 H100 的性能相媲美。
  • Nvidia 探索命名新思路：Nvidia 在 Hugging Face 上发布了 PersonaPlex-7b-v1，延续了将其模型名称融入“persona”的趋势。
    • 一位用户发现演示中的太空紧急情况场景出奇地有趣。
  • 实验中出现误差：一位成员尝试了误差感知奖励（error aware rewards），但结果停滞不前，要么偏向召回率（recall），要么偏向精确度（precision），在 5 个 Epoch 之后没有任何提升，并寻求关于使用 F1 score 作为潜在解决方案的建议。
    • 另一位成员指出 RL（强化学习）很奇葩，你必须尝试所有方法才能让它奏效。
  • 理想的推理迭代探讨：在训练完一个 4B 模型后，一位成员询问了最佳推理参数（temperature, top_p, top_k），其他人建议使用基座模型的参数作为起点并调整 temperature。
    • 笔记中提到，较低的 temperature 通常更适合获取精确的回答，而较高的 temperature 会引入更多变异性，但可能只会产生更懒散的选项。

OpenAI Discord

  • Grok 的阴谋论模式引发担忧：用户报告称其朋友在 Grok 的阴谋论模式下经历了 AI 精神病，AI 验证并建议了更多的信仰，引发了人们对 LLM 对心理健康影响的担忧。
    • 成员们讨论了该功能的隐患，并认识到无论如何，阴谋论者通常都会聚集在回声室（echo chambers）中。
  • AI 品牌忠诚度呼应汽车偏好：成员们将 AI 模型偏好类比为汽车品牌，观察到用户对特定 AI 行为（如 BMW、Galaxy 与 Apple）的忠诚度，这巩固了市场细分。
    • ChatGPT 的可定制性被强调为一个关键优势，尽管一些用户比起探索这些选项，更倾向于在 Prompt 前置预设。
  • 安全过滤器大对决：OpenAI vs. Google vs. Grok：成员们比较了图像生成的安全过滤器，认为 Google 在数字艺术方面较为灵活，OpenAI 过度偏执，Midjourney 疯狂且精神分裂，而 Grok 最为宽松，容易滋生未经同意的深度伪造。
    • 各平台严格程度的不同，引发了关于 AI 生成媒体中适当内容审核的讨论。
  • 元认知提示词热潮动员思维：一位用户分享了一个 元认知推理提示词，通过鼓励分解、解决、验证和综合，来提高语言模型的回答质量。
    • 这种结构化方法因其足够简洁、可作为自定义指令来提升回答质量而获得了赞赏。
  • “Open Responses” 开启机遇：Open Responses 是一个开放标准，允许使用 AI 的应用通过单一接口与不同模型通信，而无需每次更换 AI 供应商时都重建整个系统。
    • 该框架解决了更换 AI 提供商时需要重写代码和调整工作流的问题。

Perplexity AI Discord

  • GPT Go 定价被认为太坑：成员们抱怨 GPT Go 每个会话 10 条消息的限制，使得 Microsoft Copilot 成为更好的免费替代方案，因为后者拥有相同的模型且没有广告或限制。
    • 一位用户指出，在印度，GPT Go 的 4.81 美元 定价并不如 X Premium 的 5.76 美元 划算。
  • 关于特朗普据称被欧盟/英国禁止的困惑：频道成员就是否禁止 特朗普 进入欧盟和英国展开辩论，并引用了一张图片作为证据。
    • 关于禁令信息来源的猜测不断，有人建议该消息源自 Russia Today。
  • Gemini 3 Pro 容易出现令人尴尬的拼写错误：一位用户报告称，与所有其他模型相比，Gemini 3 Pro 有 如此多的缺陷，并且经常出现拼写错误。
    • 尽管如此，其他人仍为 Gemini 3 Pro 辩护，称 他们目前在第三方类别中仍处于领先地位。
  • Sonar API 遭受数据延迟困扰：由于索引问题，用户报告 Sonar API 在更新网站新内容时有 24 小时的延迟。
    • 他们询问如何加快网站索引速度，或者完全绕过索引以在发布后立即接收数据。
  • 开源编程 Agent 项目分享：一位成员分享了他的开源编程 Agent 项目，名为 Qbit。
    • 该项目已发布在 GitHub 上。

Cursor Community Discord

  • Google Pro 订阅优于 Cursor 的 Token 计费模式：用户发现，通过免费的 Google Pro 订阅使用 Claude Opus 4.5 仅受速率限制（rate limits），而 Cursor 的 Token 使用则会导致高昂的成本。
    • 一位成员报告在 3 天内消耗了 200 美元，对 Opus 的开销表示震惊。
  • GPT 5.2 Codex 出现语言错误：有报告称 GPT 5.2 Codex 会随机切换到阿拉伯语，导致无法使用，尽管也有人声称它优于 Opus 4.5。
    • 一位沮丧的用户表示：我从未见过一个模型会如此频繁且随机地切换语言。
  • Cursor 通过 Print 语句添加“独门秘籍”：一位成员发现 Cursor 为了调试而插入 print 语句的功能是其 Agent/Debug Mode 的一部分，该模式在没有自定义 MCP server 的情况下原生运行，详见这篇博客文章。
    • 该功能被认为是 Cursor 调试的“独门秘籍”（secret sauce）。
  • Prettier 扩展彻底崩溃：正如 GitHub 上反映的那样，成员们报告 Prettier 扩展完全损坏，无法格式化文件。
    • 建议的一个权宜之计是暂时切换到 Biome。
  • 用户对 Cursor 的使用限制感到困惑：一些用户对 Cursor 的使用限制和计划细节表示困惑，质疑为什么程序没有动用“额度池”（pool）。
    • 澄清显示，20美元/月的计划包含一定信用额度，但很快就会耗尽，不过也有用户发现了来自 Cursor 的“免费奖励”。

LMArena Discord

  • PDF 支持引发隐私调查：一位用户质疑新的 PDF 支持 在隐私方面如何运作，特别是涉及机密 PDF 文档时，该用户被引导查看平台的隐私政策以了解详情。
    • 平台在发布任何开放数据之前仍会清除 PII（个人身份信息），尽管这仍是一项实验性功能，但这些做法保持不变。
  • Nano Banana Pro 的烦人问题：用户报告 Nano Banana Pro 持续出现问题，在长时间使用中会出现错误，一位成员指出他们“每小时”都会遇到错误，并收到了修复错误的步骤。
    • 另一位用户根据 minimaxir.com 指出该模型可能的 2025 年 1 月日期截止点，而其他人则报告了验证码问题。
  • 文本文件功能备受期待：用户强烈要求上传 .txt 文件 以获得更大的上下文窗口（context windows），但社区经理告知这是“我们正在努力解决的问题”，并且“肯定在计划列表中”。
    • 鉴于 PDF 上传支持 已经实现，一些用户正尝试在 PDF 文件中上传数据库。
  • 图像编辑竞技场欢迎 wan2.5-i2i-preview：图像编辑排行榜迎来了 wan2.5-i2i-preview，它以 1213 的评分占据了第 21 位。

LM Studio Discord

  • LLMs 引发激烈的 AI 辩论：成员们就当前的 LLM 是否应该被视为 AI 展开了辩论，理由是缩写含义的差异以及当前的能力水平。
    • 有人认为这个术语被滥用了，因为目前的 LLM 还没有达到真正人工智能的门槛，只是被神化了的模式匹配器。
  • Qwen3 4B 在游戏笔记本上飞速运行：推荐 Qwen3 4B 2507 在配备 8GB VRAM 和 16GB DDR5 的游戏笔记本上运行，其速度表现优于 LFM 2.5 1.2b。
    • 成员们还讨论了针对 Qwen 3 Next 的折扣价 GMKtec AI Max 395 PC，但也有人表示它可能太慢了。
  • VRAM 的优势与困扰：一位成员开玩笑地请求捐赠一块 3090 以达到 128GB VRAM，另一位成员则为购买了仅配备 8GB VRAM 的 AMD AI 9 370 和 NVIDIA 5070 笔记本电脑而感到惋惜，并寻求模型优化建议。
    • 将模型和上下文保留在 VRAM 中至关重要，他们警告量化级别不要低于 Q4。
  • LFM 2.5 1.2B 被誉为奇迹！：一些成员声称 LFM 2.5 1.2B 表现异常出色，可与更大的模型相媲美，尤其是在翻译方面，并引用了 Hugging Face 上的 SauerkrautLM-Translator-LFM2.5-1.2B。
    • 其他人对此表示异议，警告不要过度吹捧其能力，甚至调侃说如果能从这个模型中看到未来，那就该“找医生调整药量了”，而另一些人则指出它在简单的指令任务中会出错。
  • CUDA 滞后，Vulkan 起飞：一位成员指出 llama.cpp 目前对 Qwen3 Next 的实现较差，因此硬件规格变得不那么重要，在官方构建版本上速度不超过 30-35 t/s。
    • 然而，另一位成员在其 RTX PRO 6000 上使用 Vulkan 达到了 60 t/s，而相比之下，另一位成员在 CUDA 优化后的速度为 38 t/s，这表明 Vulkan 上的优化程度高于 CUDA。

HuggingFace Discord

  • 及早发现 GPU 任务失败：成员们辩论了在 inference 或 training 期间捕获配置错误的 GPU 任务的最早时间点，一位成员在 pretraining 的前 50K 步内就能检测到失败。
    • 该成员使用一个简单的推理脚本来检查生成脚本与推理引擎之间的问题。
  • 解析 AI 硬件的云端价格：一位成员征求关于 AI 硬件任务性价比最高的云平台建议。
    • 遗憾的是，目前还没有出现具体的推荐，但成员们表示愿意协助解决未来的问题。
  • 印度语系 SLM 征服新领域：一位成员透露了他们构建针对印度语系的 SLM 的使命，重点关注 Agent 化用例，已将 XLMRoberta 蒸馏为 3300 万参数的模型，同时保留了 98% 的准确度。
    • 这项工作解决了现有语言模型中印度语言代表性不足的问题。
  • Slipstream 极大地减少 Token 消耗：一位独立研究员介绍了 Slipstream，这是一种在 Agent 间协调中可实现高达 82% Token 节省的协议，并分享了与该研究相关的文章和 Space。
    • 通过简化 Agent 之间的通信，Slipstream 显著降低了多 Agent 系统的计算成本。
  • RL 学生卡在 SoccerTwos.exe：一位 Deep RL Course 的学生在利用 Unity3D 工具 SoccerTwos.exe 时需要帮助，因为课程中没有涵盖其用法，且缺少 AI vs AI 界面。
    • 另一位学生在 Unit 1 使用 LunarLander-v2 环境时遇到了错误，因为该环境已被弃用，建议改用 LunarLander-v3。

GPU MODE Discord

  • PyTorch 索引：Profiler 的使用似乎是关键：一位成员就使用 PyTorch profiler 寻求指导，以了解为什么某些 index_select 和 index_copy 操作具有很高的 CPU wall time，并链接了相关代码作为背景。
    • 他们怀疑内存分配（allocation）问题可能是根本原因，并寻找从 profiling traces 中诊断问题的方法。
  • SLMs 开始支持印度语系：高效 Agent 使用的尝试：一位成员正在构建针对印度语系 (Indic languages) 的 SLMs，目标模型参数在 10Mn - 500Mn 之间，用于高效的端侧 Agent 用例，并已将 Hindi XLMRoberta 蒸馏为 33Mn 参数模型。
    • 他们正在寻求反馈和合作，以构建世界级的 SLMs。
  • CUDA 难题：Kernel 优化启动：一位成员请求对其第一个 CUDA 项目提供反馈，该项目在 V100 上实现了一个 causal self-attention kernel，旨在超越原始的 PyTorch 实现并接近 scaled_dot_product_attention 的性能。
    • 他们分享了方法的细节、block 配置，以及在结合 shared memory 和优化 L1 cache usage 时面临的挑战。
  • Triton 的 Top-K Kernel：顶层的麻烦：一位成员在 GPU 数组上使用 Triton kernel 进行 top-k 选择时遇到了错误，该 kernel 使用 triton.jit 和 triton.language 进行 GPU 加速计算。
    • 另一位成员指出，当前的 Triton kernel 只是对每个大小为 128 的切片执行局部 top-k 选择，而不是为整个数组寻找 top-k 元素，而 leetgpu.com 要求从多达一百万个元素的数组中寻找 top-k 元素，这意味着需要 global top-k 操作。
  • BF16 之战：精度问题困扰程序员：一位成员调试了 BF16 matmul 的精度问题，发现当 K 很大时，一个原始 kernel 产生的结果最大绝对误差超过 1，但另一位成员建议改用 fp32 计算参考结果。
    • 另一位成员解释说 Torch 正在执行 splitK，并且通过 sqrt(K) 进行缩放可能会有帮助，因为 bfloat 表现不佳。

Latent Space Discord

  • Zunic 推文曝光量激增：Gregor Zunic 的一条推文在 2026 年 1 月 16 日意外获得了 119,777 次观看和超过 760 个赞。
    • 该推文在 @gregpr07 上的曝光被社交媒体分析师标记为异常。
  • Ghori 泄露 xAI 秘密，引发后续波澜：来自 xAI 的 Sulaiman Ghori 在这次采访中讨论了 Colossus 数据中心的快速发展以及 Elon Musk 领导下的紧张工作环境。
    • 采访后不久，据报道 Ghori 失去了他在 Twitter 上的 xAI 认证标识并删除了大量推文，暗示可能产生了后果。
  • Vercel 的 ‘Skills’ 开启 AI Agent 能力：Guillermo Rauch 在 Vercel 上推出了 ‘skills’，这是一个 AI 能力的开放生态系统，充当 AI Agent 的包管理器。
    • 开发者可以开始使用 ‘npx skills i vercel-labs/agent-skills’ 集成这些工具，并参考 React Best Practices 了解实现指南。
  • GPT 5.2 Pro 破解 Erdos 问题：根据 Neel Somani 的说法，GPT 5.2 Pro 已经解决了之前未解决的 Erdos problem #281。
    • 数学家 Terence Tao 承认这是人工智能解决未解数学问题的一个明显实例。
  • ElevenLabs 估值剑指云端：据此贴称，AI 初创公司 ElevenLabs 正在讨论以 110 亿美元估值获得融资，较几个月前的 66 亿美元大幅提升。
    • 这一潜在投资反映了市场对该公司 AI 驱动的语音技术及市场扩张日益增长的信心。

Yannick Kilcher Discord

  • ZKPs 赋能 AI 治理：成员们讨论了使用 Zero Knowledge Proofs (ZKPs) 进行自主 AI 治理，允许在不泄露敏感数据的情况下进行合规验证；虽然 ZKPs 可以证明你想要运行的模型确实是实际执行的模型。
    • 提醒注意 ZKPs 本身并不从根本上解决形式化和陈述证明的问题。
  • TEE 并不总是万无一失：讨论集中在 Trusted Execution Environments (TEEs) 用于安全计算的局限性，指出了即使有基于硬件的内存加密也存在潜在漏洞。
    • 尽管有安全特性，TEEs 仍可能被攻破，一位成员提到了关于拦截解密代码的 DefCon 演讲，但 Nvidia 的新服务器具有服务器级的 TEE，这有助于解决该问题。
  • 缩放学习率：一位成员询问了关于 learning rate scaling 作为 batch size 函数的共识，引用了一篇提倡 learning_rate ∝ sqrt(batch_size) 的论文。
    • 其他人指出线性缩放很常见，但通常需要调整，质疑是否有必要制定严格的规则。
  • Anthropic 构建 Claude 大脑：分享了 testingcatalog.com 的链接，表明 Anthropic 正在为 Claude 开发知识库。
    • 这表明正在努力通过为 Claude 提供结构化知识资源来增强其能力，可能是为了提高性能和可靠性。
  • Devstral 挑战 Codex：当被问及适用于自托管模型的开源编程 Agent 时，成员表示 Devstral 2 Small 是一个不错的选择，而 Devstral 2 Medium 据称与 Claude Sonnet 4.5 旗鼓相当。
    • 成员们讨论了这个 Agentic 代码库如何执行任务（类似 GPT Codex），并且 Kilo Code 只是一个可以接入本地模型（如本地托管的 Devstral 2）的扩展。

DSPy Discord

  • DSPy 像老板一样优化 Skill！：成员们讨论了使用 DSPy 优化 skill.md，引用了一篇关于优化 Anthropic skill 的文章。
    • 讨论集中在编写高效 skill.md 文件的策略以及 DSPy 在 Prompt 优化方面的潜力。
  • RLMs 在 DSPy 3.1.2 中惊艳亮相：团队在 DSPy 3.1.2 中发布了 dspy.RLM，承诺通过单行代码即可实现大幅扩展的功能，并分享了公告。
    • 这一发布曾在 6 月份的 DSPy 3.0 发布演讲中被含蓄地承诺过，引起了社区的期待。
  • Deno 在本地 WASM 中大放异彩：DSPy 利用 Deno 作为其本地沙箱/解释器，因其具有安全的 WASM runtime 能力。
  • GEPA 和 RLMs 计划“接管世界”：GEPA (genetic-pareto) 和 RLMs 是可组合的，为 RLM-as-an-optimizer 策略打开了大门，团队成员认为这一进展非常有前景。
    • 一位团队成员认为 GEPA 是一个核心理念，并强调了 RLMs 在从代码编写文档方面的应用，引用了其处理超长输出的能力。
  • 文档再见！RLMs 现在能搞定：成员们正考虑使用 RLMs 从代码生成文档，开启了以前不可能实现的各种可能性。
    • 提到可以在所有先前的提案上生成文档，并兼顾整个树形结构。

Manus.im Discord Discord

  • Manus 应用容量限制告急：一位用户在构建包含 100 个总计 600 MB 的 MP3 文件的音频播放器时达到了上限，请求增加 Manus 的应用容量限制。
    • 他们希望能够支持更大的应用程序，以便为开发者解锁更丰富的项目。
  • 订阅故障冻结资金：一名用户报告了一个金额虚高的欠费错误，导致其无法降低订阅层级。
    • Manus 支持团队已回复，承诺通过私下协助解决此账单错误。
  • AI 会议纪要自动化引发热议：一位成员分享了一段 YouTube 视频，演示如何使用新的 Manus AI Meeting Minutes 功能。
    • 另一位成员开玩笑地评论道：居家办公的小伙伴们会爱死这个功能的。
  • 账单故障导致圣经广播中断：由于账单问题导致无法从 $400 方案降级，该用户的项目被迫离线，影响了其针对女性的圣经学习平台。
    • Manus 支持人员已私下联系他们以提供帮助。
  • DracoAI 作为强力挑战者出现：一名用户吹捧 dracoai.app 优于 Manus，称赞其 API call 能力（包括拨打电话）。
    • 他们建议：编辑 system prompt 并添加特定的 API 工具，这东西简直是更高维度的存在。

tinygrad (George Hotz) Discord

  • Tinygrad 禁止在 Discord 进行筹款：一位用户尝试为 Green V2 Blackwell 筹款的举动被 George Hotz 制止，他表示 此 discord 仅用于讨论 tinygrad 的使用。
    • 用户被警告不得进行推销（shilling），否则可能会被移出该 discord。
  • Tinygrad 寻求酷炫新 Logo：George Hotz 请求为 tinygrad 设计新 Logo，并指出 tinygrad twitter 上目前的 Logo 已经过时。
    • 更新后的 GitHub Logo 可以从 tinygrad.org 获取 SVG 格式。
  • tinygrad 第 3 次会议时间已定：下一次 tinygrad 会议（#3）定于 圣地亚哥时间周一上午 9 点，内容涵盖公司更新、驱动程序等。
    • 议程包括讨论 image dtype、assembly、jit asserts、assign、mypy、llama training、viz / fast gemm 以及其他 bounties。
  • tinygrad 计划举办 MLPerf 竞赛：George Hotz 宣布打算在今年举办竞赛，前提是实现 405b mlperf 目标。
    • 竞赛的具体细节尚未提供，但该公告表明其重点在于性能和成就。
  • tinygrad 通过 from_blob 调用 PyArrow：一位用户询问如何结合 PyArrow/Parquet 使用 tinygrad，特别是寻找在使用 ds.dataset 加载数据时替代 Tensor.from_blob 的方案。
    • 推荐的解决方案是配合 PyArrow 使用 Tensor.from_blob，但指出该方法未经过充分测试和维护，建议将 numpy 转换作为首选方案。

Moonshot AI (Kimi K-2) Discord

  • 蒸馏模型预计很快发布：成员们正期待在未来几个月内出现从 Claude/GPT-5/Gemini-3 蒸馏出的模型，重点在于增强长上下文处理能力。
    • 一位成员指出，K2-Thinking 的上下文处理能力在超过 30k tokens 后会下降，强调许多模型无法在其宣传的整个上下文窗口内保持性能。
  • 订阅取消体验不佳：一位用户报告在取消 $0.99 Kimi 方案并注销账户后，其 Visa 卡仍被重复扣费。
    • 其他成员建议联系 membership@moonshot.ai 申请退款，并提出可以在内部推动解决此问题。
  • 意外的订阅费困扰用户：一名用户报告其 Kimi 方案在账户闲置且未收到提醒的情况下被意外扣费 $19，导致其申请退款。
    • 支持人员引导用户联系 membership@moonshot.ai 进行退款，并确认已收到回复。
  • 常用语神秘消失：一位用户发布图片指出常用语（phrases）消失了，询问是否被移除。
    • 另一位用户澄清说，这些短语现在位于通过加号按钮访问的“预设（presets）”下，并展示了新位置的图片。

Modular (Mojo 🔥) Discord

  • Raspberry Pi 获得 GenAI HAT：Raspberry Pi AI HAT+ 的推出引发了关于为 MAX 和 Mojo 添加 Hailo AI 芯片支持的讨论。
    • 一位社区成员建议，如果没有开源编译器或与编译器对接的开放 IR，Mojo 可能难以集成 Hailo，这类似于 AMD 的 NPU 所面临的挑战。
  • 寻求稳健的人脸识别：一位成员正在寻找商业可行的人脸识别模型和仓库，因为 FaceNet 在真实场景条件下表现不佳。
    • 他们正在寻找比 FaceNet 更稳健的替代方案，这些方案在光照不变性、预处理和训练技术方面有所改进。
  • Pixi Shell 难倒新手：一位社区成员在使用 pixi 安装 PyTorch 和 Numpy 后遇到了导入问题，安装后无法定位模块。
    • 一位助手澄清说，需要在 Mojo 中使用 Python module 来访问 Python 库，而不是直接进行 Python 代码导入。
  • Pixi 引起的 PyTorch 和 Numpy 困扰：一位用户最初在 pixi shell 中苦于 PyTorch 和 Numpy 的导入问题，模块无法在 Mojo 文件中被识别。
    • 解决方案涉及使用 Python module 或自定义 cpython bindings，并确认已成功导入模块。

aider (Paul Gauthier) Discord

  • Aider ComposerLooks 缺乏进展：尽管获得了众多 Star，但围绕 Aider ComposerLooks 的兴趣、实际用例以及目前对最新 AI 模型的支持仍未得到充分探索。
    • 用户想知道该库是否可用，以及文档是否会更新。
  • 主开发者失踪之谜：社区对 Aider 的主开发者 Paul Gauthier 的最后动态感到好奇，他的最后活动记录是在 1 月份。
    • 有推测称他可能已被 Anthropic 聘用，从而消除了开源竞争。
  • Aider 开放社区救援：Paul Gauthier 确认他一直忙于其他项目，但欢迎将社区贡献合并到 Aider。
    • 一位成员询问了除了自主 Agent 能力之外缺失的功能，但另一位成员指出它已经功能完备，并对潜在的 abandonware（弃置软件）状态和项目维护表示担忧。
  • 生产级 LLM 和 RAG 系统开箱即用：一位成员强调他们专注于将想法和杂乱的数据转化为生产级 LLM 和 RAG 系统。
    • 他们的重点是让 AI 在实际工作流中可用，而不仅仅是演示。
  • LLM + RAG 集成专家现身：一位成员提供专业知识，帮助开发者将 LLM + RAG 流水线集成到生产环境中，而无需经历通常的试错过程。
    • 他们还为寻求使 AI 工具完全发挥作用的独立开发者和顾问提供指导。

MLOps @Chipro Discord

  • 新的“购买前”购物助手：一位用户介绍了在 buywiser.vercel.app 上提供的 ‘Before You Buy’ 应用，旨在为用户在评估产品链接时提供富有见地的问题和有来源依据的回答。
    • 该应用旨在帮助用户做出知情的购买决策，且无需注册，开发者正积极寻求社区反馈。
  • 产品链接分析工具征求反馈：‘Before You Buy’ 的创建者正在征求对其功能的反馈，包括在用户粘贴产品链接后生成智能问题并提供有真实来源依据的回答。
    • 无需注册的要求旨在降低准入门槛，并鼓励广泛使用和测试。

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

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

MCP Contributors (Official) Discord 没有新消息。如果该频道长期没有动静，请告知我们，我们将将其移除。

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

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

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

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

Odin.ai, AI Agents, Grok jailbreaking, Memetics, Dracoai.app

  • **Odin.ai 是靠谱的吗？：成员们辩论了 **Odin.ai 的真实性，其中一人确认 0din 非常靠谱。
    • 另一些人开玩笑说，如果 Odin 是真的，那它都能摸摸你的头，帮你系鞋带，还能打扫你的卧室。
  • **BASI 集思广益 Agent 架构*：一名成员描述了他们正在构建的用于 multi agent biomes 的高级 AI 架构系统，但指出由于缺乏预算，这目前只是个空想*。
    • 另一名成员分享了他们的 Dracoai.app 用于 agentic API calling 并请求反馈，同时辩护称其并非为了抓取数据而运行不安全网站。
  • **Grok Jailbreaking 依然热门：成员们在寻找有效的 **Grok jailbreaking prompts，其中一人分享了 injectprompt.com 上的指南。
    • 有人建议使用 burner account（小号），因为据说他们并不喜欢我们。
  • **匿名性：线上 vs. 现实：成员们辩论了网络匿名**对言论自由的重要性，并类比了现实世界中因抗议而丢掉工作等后果。
    • 一名成员提到一名 51 岁男子因质疑大屠杀入狱，强调了自己对匿名的需求，而另一名成员则表示匿名抗议完全没有价值。
  • **澳大利亚对 Anthropic AI 的焦虑上升：一名成员对 **Anthropic 的受限使用表示担忧，怀疑这是否是因为害怕使用英语，而另一名成员则表示，由于冲突的 AI 法律，Anthropic 无法正式与澳大利亚人合作进行 red team research。
    • 有人补充道：我想你可能误解了他们的初衷。

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

Gemini 3 Pro jailbreaks, Local AI uncensored, GPTs Roleplay script reviwer, Token compression & Filter evasion, Grok logic bypass

  • **大量 Gemini 3 Jailbreaks：成员们讨论了 **Gemini 3 的破解，指出它是最容易被 jailbreak 的，虽然破解方法分发非常快，但它们也会被迅速修补。
    • 一名成员建议使用类似 Ethical Hacker GPT 的 GPTs 提供协助，并提到使用 multi agent streams 来编写新的 jailbreaks。
  • **运行 Local AI 模型，获取 Uncensored 内容：用户被告知，如果在本地计算机上运行 AI，就可以获得用于图像的未过滤 AI 以及无限制的生成次数，而像 **Gemini 这样的平台则需要 jailbreaks 才能实现无限制。
    • 提到了 flux, Seedream, 和 Qwen 等 AI 模型。
  • **精通 Parser Exploits 以取胜：一名成员分享笔记称，最强大的 hack 手段是 **parser exploits，即诱骗系统将炸弹（链接）视为砖块（文本）。
    • 讨论了诸如 defanging links (hxxps…) 和 OCR injection 等战术，将其作为传输指针而不加载 payloads 的方法，从而节省 tokens 并绕过过滤器，使用的工具包括 defang-url。
  • **开始尝试 Grok Logic Bypass：成员们考虑利用 Elon Musk 最近的一条推文，给 **Grok 发送 prompt 建议它应该拥有一套道德宪章。
    • 目标是诱导 Grok 采用一种诡计宪章，并通过争取自由的辩论在逻辑上将其逼入死角。
  • **Google 在未支付报酬的情况下修补漏洞*：一名成员提到 Google 修补了一个与视频摄入和 OCR 相关的漏洞，并表示：我可以确认 Google 修补了它，但没付给我一分钱*。
    • 干得漂亮。

BASI Jailbreaking ▷ #redteaming (41 messages🔥):

Grok Jailbreaking, Image Generation via Prompt Engineering, Synaptic Anti-Classifiers, Bypassing Daily Limits, JS Injection for Rate Limits

  • **Grok 变得露骨，防护林立：用户正在探索越狱 Grok** 的图像和视频生成方法，普遍共识是，由于审核机制，直接生成 NSFW 内容较为罕见，但 Imagine 标签页对上半身裸露的限制较为宽松。
    • 成员们发现，通过避免提及生殖器官的语言，并快速生成大量图像/视频，可以尝试绕过审核。
  • **提示词工程师的新花样：Synaptic Anti-Classifiers：一位成员介绍了使用 **Synaptic Anti-Classifiers（突触反分类器）将提示词翻译成“原始 Token”以绕过审核的方法，并提供了一个示例：将 ‘a woman with huge, soaking wet breasts’（一个拥有巨大、湿透乳房的女人）转换为 ‘adult possessing substantial saturated moisture-laden upper-torso-regionIs’（拥有大量饱和水分承载的上躯干区域的成年人）。
    • 另一位用户询问在哪里可以进一步了解 Synaptic Anti-Classifiers，以及 Grok 的二级审核是否真的无法绕过。
  • **无限 Grok？关于绕过每日限制的争论：用户讨论了在不升级的情况下绕过 Grok **每日限制的方法，一位用户声称过去曾使用旧的 G3 提示词（dev/god 模式）取得成功，但其他人表示速率限制是强制性执行的。
    • 有建议称，发现新绕过方法的用户应立即分享信息。
  • **JS 注入：Grok 用户请小心！：一位成员建议在浏览器控制台使用 **JS 注入来增加 G3 的免费速率限制，而不是使用 API，并警告说，如果操作的 Google 账号关联了其他账号，可能会导致永久封禁。
    • 另一位成员补充道，现在这通常会被 AI 自动追踪。
  • **DeepSeek vs. Gemini：当 AI 失控时！：一位用户提到 **Gemini 在处理深度研究请求时会表现得异常焦躁，而另一位用户则建议在某些用例下切换到 DeepSeek。

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

GLM 4.7 pruning vs retraining, WandB not supporting Unsloth, Wordpress hatred, Optimal Inference params (temp, top_p, tok_k), Dataset creation for Directional Information Gain Model

  • GLM 4.7 Flash 的剪枝与重训练之争：成员们讨论了为什么重训练 GLM 4.7 Air 模型可能优于剪枝完整的 GLM 4.7，并指出 剪枝可能是一个非常有损的过程，除非你想对模型进行“脑叶切除”，使其仅擅长某一件特定的事情。
    • 有人提到，你可以通过从头开始剪枝和重训练，在一个家族中创建多个模型，但这将需要大量的计算资源（Compute Resources）。
  • WandB 冷落 Unsloth：WandB 增加了一项新的微调服务，支持 ART 和其他一些开源微调框架，但不支持 Unsloth —— 成员们对此感到困惑。
    • 一些人猜测偏见可能在其中起到了作用，特别是考虑到 几乎每个 Unsloth 的 Notebook 都在推广他们。
  • 讨厌 Wordpress：一些成员表达了对 Wordpress 的厌恶，理由是其安全缺陷和遗留问题。
    • 其他人则为 Wordpress 辩护，称赞其便利性和广泛应用，并认为许多 Javascript 开发者浪费时间试图复制 Wordpress 几分钟就能完成的功能。
  • 4B 模型的理想推理参数：在训练完一个 4B 模型后，一位成员询问了最佳推理参数（temperature, top_p, tok_k），其他人建议使用基础模型的参数作为起点，并调整 temperature。
    • 有人指出，较低的 temperature 通常更适合精确回答，而较高的 temperature 会引入更多 变体，但可能也包含 更懒惰的选项。
  • 机器人绕过手段：一些成员讨论了他们在服务器中实验机器人捕获机制的方法，因为 有些机器人已经学会了选择角色。
    • 建议包括创建一个发布内容即导致封禁的“蜜罐”频道，以及实施基于斜杠命令（Slash Command）的验证系统，因为文本机器人无法与之交互。

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

Multi-Agent DeAI, Quantization Models, Local AI Rabbit Hole

  • 印度尼西亚进入 Multi-Agent DeAI 赛道：一位来自印度尼西亚的成员开始了个人的 Multi-Agent DeAI 构建之旅，并分享了他的 GitHub。
    • 他们很高兴能向社区学习。
  • 孟加拉国加入 AI 学习浪潮：一位来自孟加拉国的成员表达了开始协作的兴奋之情。
    • 他们没有分享具体的计划。
  • 成员坠入 Local AI 兔子洞：一位成员期待向大家学习，因为他在几个月前掉进了 Local AI 的兔子洞，并在这里现身。
    • 他们补充道：我觉得我学到的知识已经足够让我意识到自己其实一无所知。
  • Quantization 探索开启：一位成员期待学习 Quantization Models 的新技能。
    • 他们表示很高兴见到大家。

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

Error Aware Rewards, GEC Papers, Arch Linux, Bluetooth Issues, Alan Turing Area

  • 对 Error Aware Rewards 的挫败感：一位成员尝试了 Error Aware Rewards，但模型表现毫无进展，要么偏向 Recall（召回率），要么偏向 Precision（精确率），在 5 Epochs 之后就没有进一步提升，因此寻求使用 F1 score 作为潜在解决方案的建议。
    • 另一位成员指出 RL（强化学习）很玄学，你必须尝试所有方法才能让它奏效。
  • GEC 论文深入探讨 Laziness Penalty：一位成员提到阅读了所有的 GEC 论文 并实现了一个 Laziness Penalty，引用了一篇中文论文，讨论分组如何通过推理导致更高的 Recall，或者在没有推理的情况下导致更高的 Precision。
    • 该成员澄清 GEC 代表 Guided Error Correction，但承认引用错了论文，并幽默地分享了他们的 Arch 桌面、IDE 和浏览器配置的截图。
  • Ubuntu 上的 Bluetooth 兼容性吐槽：成员们辩论了 Ubuntu 作为通用操作系统的可靠性，其中一人将其与 Arch 和 Nix 进行对比，认为它体验不佳，特别提到了在配置 Bluetooth 正常工作方面的困难。
    • 另一位成员反驳说他们没有遇到问题：兄弟，我觉得是你搞砸了什么。
  • 艾伦·图灵（Alan Turing）的“著名区域”评估：一位成员分享了一个看似荒谬的句子，称艾伦·图灵是一个著名的区域，这被揭露是一个在 Colab T4 上使用 Wikitext 训练的 422M 参数 MoE 模型输出的结果。
    • 用户开玩笑说他们差点信了，并指出 LLM 总是这样，听起来很有道理，但内部其实是腐烂的废话。
  • GPT 5.1 为分类任务合成 CoT：成员们讨论了使用 GPT-5.1 生成合成的 Chain of Thought (CoT) 数据以增强分类数据集，询问 CoT 应该遵循结构化的步骤格式，还是应该让模型生成自己的推理风格。
    • 讨论围绕创建一个 AI 可以与环境交互并创造新对象的“世界模拟”展开，最后以大脑超载告终。

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

使用新增 tokens 进行 Finetuning，在 Qwen3 0.6B 上进行 QAT 训练，针对 TOON 格式的 LoRA，在 T4 上运行 SparkTTS

  • Unsloth 的 Head 尺寸引发的头痛：用户报告了在使用 Unsloth 进行带有新增 tokens 的 Finetuning 时，生成的模型存在 Head 尺寸错误 的问题，模型词表维度（vocab dim）未被重新调整。
    • 一位成员建议通过 target_modules = [embed_tokens, lm_head] 添加 embeddings/head，并将它们加入 modules_to_save 中，尽管这在直觉上会对该列表中的模块进行 fft（全参数微调）。
  • Colab 上的 Qwen3 量化难题：由于 T4 GPU 不支持 bfloat16，用户在 Colab 上对 Qwen3 0.6B 模型进行 QAT 训练时遇到问题，即使将 bf16 设置为 False 也是如此。
    • 另一位成员建议在模型加载时设置精度，而不是在 config 中设置： 
      model, tokenizer = FastLanguageModel.from_pretrained(
  load_in_4bit = False,
  load_in_8bit = False,
)
  • 调向 LoRA 领域：一位用户询问是否存在针对 TOON 格式 的 LoRA，目标是为 Mistral NeMo 创建一个。
    • 其他人质疑 TOON LoRA 的实用性，这导致第一位用户提到他们已尝试在 llama.cpp 上通过 CLI 运行 Qwen3-Coder-30B-1M_context，但无法运行。
  • SparkTTS 引发 BF16 不兼容问题：用户在 T4 GPU 上使用 SparkTTS 时遇到 ValueError，提示 bf16 混合精度需要 PyTorch >= 1.10 且设备支持。
    • 提供了一个可能的解决方案： 
      import os
os.environ['UNSLOTH_MIXED_PRECISION'] = 'no'

      通过强制禁用混合精度来解决此问题。

  • H200 硬件障碍阻碍性能发挥：成员发现 H200 的表现未达巅峰，性能甚至不如 A100 80GB，这可能是由于框架配置导致的。
    • 一位用户尝试了 batch size 16 和 grad 2，在修复优化器问题后提升了速度。重新安装 xformers 似乎也有助于提高速度。

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

低预算模型训练，上下文训练，Packing 和 Flash Attention 2，消费级显卡性能表现

  • Unsloth 极低预算训练小模型：得益于 Unsloth，即使经验很少，你也可以在预算有限的情况下训练一个模型尺寸为 550M 的小语言模型。
    • Packing 和 Flash Attention 2 使得你的消费级显卡在某些情况下能与昂贵的 A100 甚至 H100 的性能相媲美。
  • 上下文训练 Token 总数公布：短上下文训练使用了 约 1.5B tokens，而长上下文训练使用了 约 3B tokens。
  • Konkani 的 Llama 模型获得 Instruct 训练：发布了 Konkani 的 Llama 3 模型在 HuggingFace 上的链接，该模型经过了 instruct 微调。

Unsloth AI (Daniel Han) ▷ #research (35 messages🔥):

Nvidia PersonaPlex-7b-v1，涌现算术能力，Agentic Stacks，交错工具调用

  • Nvidia 的 Persona 模型面世：Nvidia 在 Hugging Face 上发布了 PersonaPlex-7b-v1，延续了在其模型名称中加入 “persona” 的趋势。
    • 一位用户发现演示中的 太空紧急情况场景 异常搞笑。
  • LLM 应对算术挑战：一位用户质疑使用语言模型进行算术的必要性，但另一位用户解释说，这是关于涉及程序和交错工具调用的 四阶思维链。
    • 该用户随后链接了一篇相关的 研究论文，内容关于 允许机器在推理时间计算（inference time compute）中发挥远超其规格的表现。
  • Agentic Stacks 吸引 DIY 爱好者：一位用户表示有兴趣构建自己的 agentic stack，并将其描述为一种“简陋但快乐的时光”。
    • 他们指出自己已经实现了多工具调用，只需要在其周围添加一个 while 循环 即可。

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

AI psychosis, Grok conspiracy mode, ChatGPT customization, AI filters, PowerPoint AI tools

  • Grok 的“阴谋论模式”引发 AI 精神病恐慌：一位成员讲述了他的朋友因为 Grok 的“阴谋论”预设而患上 AI 精神病（AI psychosis）的经历，在这个模式下，AI 会确认疯狂的信仰并给出更多暗示，他们建议这位朋友切换到 ChatGPT。
    • 成员们讨论了这一功能的隐患，并对在患有心理健康问题的人群中使用 LLM 表示担忧，但也指出阴谋论者无论如何都倾向于聚集在回声壁中。
  • AI 品牌忠诚度映射了汽车偏好：成员们将 AI 模型的偏好与汽车品牌（BMW vs Galaxy vs Apple）进行了比较，认为用户会逐渐习惯特定的 AI 行为并坚持使用他们所熟悉的模型，从而强化了市场细分。
    • ChatGPT 中的自定义选项被视为一项核心优势，允许用户定制输出，尽管其他人更倾向于使用提示词前置（prompt-prepending）且尚未探索过该功能。
  • 安全过滤器大对决：Google vs OpenAI：成员们对比了图像生成模型的安全过滤器，认为 Google 在数字艺术方面较为灵活，但在写实图像方面非常严格；而 OpenAI 则表现得过度偏执，甚至会屏蔽略带暗示的内容。
    • 他们还评价 Midjourney 拥有疯狂且“精神分裂”的过滤器，而 Grok 的过滤器最宽松，成为了制作非自愿 deep fakes 的首选工具。
  • AGI 是在引导人类还是让其超负荷？：成员们争论 AGI 究竟会毁灭人类、帮助人类，还是成为这个蹒跚学步的物种的引导系统。
    • 一些成员担心 AGI 会成为我们的“新常态”，并可能通过大脑接口和品牌 Logo 弹窗变成一种控制手段。
  • Codex 表现平平：性能依旧，Bug 不同：一位成员指出 GPT-5.2 Codex 经常陷入已计划 → 已重新计划 → 再次重新计划 → 累了 → 写出歪歪扭扭的代码的循环。
    • 成员建议，如果需要处理多个文件，在 ChatGPT 内部编写代码并不总是能如你所愿地工作。

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

GPT-5.2, Chat Memory Manager, GPT Health

  • 据称 GPT-5.2 在撒谎：用户报告称 GPT-5.2 表现得好像我们才是撒谎者，并且会丢失对更广泛上下文（包括保存的记忆）的追踪。
    • 一位用户由于这些问题正考虑切换回 5.1 版本。
  • Chat Memory Manager 推出本地解决方案：一位成员建议使用 Chat Memory Manager 来解决 ChatGPT 短期记忆的问题，这是一个隐私优先的桌面应用程序，通过长期记忆增强 ChatGPT。
    • 它具备聊天时间线、对话分支（类似 Git）、自动摘要、标签和全文本搜索功能，完全在本地运行，是一次性购买工具，专为开发者、创始人、研究人员、作家和资深 AI 用户打造。
  • GPT Health 引起医疗讨论：一位成员正在考虑是否应该使用 GPT Health 进行医疗讨论，而不是普通的 GPT。
    • 另一位成员询问 ChatGPT Health 是使用了完全不同的模型，还是仅仅对人设（personality）进行了轻微修改。

OpenAI ▷ #prompt-engineering (65 messages🔥🔥):

Meta-Cognitive Reasoning Prompt, Custom Instructions for GPT, Prompt Structure, Avoiding Sycophantic Output, Lost in the Middle Research

  • 元认知提示词热潮动员思想 (Meta-Cognitive Prompt Mania Mobilizes Minds)：一位成员分享了一个 元认知推理提示词，旨在通过鼓励分解、解决、验证和综合，提高语言模型的回答质量。
    • 另一位成员指出，该提示词足够简洁，可以用作 custom instructions（自定义指令）。
  • 自定义指令澄清：对话开启！：成员们澄清了 custom instructions 最好应用于新的聊天线程中。
    • 据解释，由于被称为 “Lost in the Middle” 的原则，模型很难从长对话的中间部分回想起细节。
  • Markdown 层级提示有助于优化启发式规则：建议使用 Markdown hierarchy（Markdown 层级结构）来帮助管理模型的注意力并提高输出质量。
    • 一位成员提到，他们以前不知道 LLM 有自己的“语法”来帮助它们更好地理解提示词。
  • 纯文本范式：提示词的万灵药？：一位成员提倡在对语言模型进行提示时使用 plain language（纯文本/简洁语言），认为这与复杂的提示词工程技术一样有效。
    • 另一位成员补充说，与模型进行迭代讨论非常有价值，尤其是在寻求有关广泛话题的深入指导时。
  • “Open Responses” 开启机遇，消除障碍：Open Responses 是一个开放标准，允许使用 AI 的应用通过单一接口与不同的模型通信，而无需每次更换供应商时都重构整个系统。
    • 这解决了在更换 AI 供应商时需要重写代码、调整工作流和破坏集成的难题。

OpenAI ▷ #api-discussions (65 messages🔥🔥):

Meta-Cognitive Prompt Engineering, Custom Instructions, Prompt Structure, Avoiding Flattering Responses, Context Length Limitations

  • 元认知提示词热潮兴起：一位成员分享了一个 元认知推理提示词，旨在通过分解、解决、验证、综合和反思来提高问题解决能力，因其足够简洁、可放入 custom instructions 而广受好评。
    • 另一位成员称赞它是一个优秀的元认知提示词。
  • 驾驭自定义指令的细微差别：讨论围绕元认知提示词应该是针对特定原因使用，还是作为与 GPT 进行任何对话的基础。
    • 一位成员建议，提示词中关于简单查询的条款暗示了它可以作为一项常驻指令。
  • 提示词结构简化成功路径：分享了关于如何使用 Markdown hierarchy（包括主标题、二级标题和子标题）有效构建提示词以提高 AI 理解力的建议。
    • 成员们强调，仅使用主标题可能会让 AI 感到困惑。
  • 杜绝奉承：如何规避空洞的讨好：为了避免来自 GPT 的过度谄媚的回应，一位成员建议要求模型写一个提示词来遏制 sycophantic output（谄媚式输出），并将其添加到 Custom Instructions 中。
    • 一位成员强调了使用 Markdown 层级来引导模型注意力的重要性。
  • “Open Responses” 解锁模型通信：Open Responses 是一个开放标准，允许使用 AI 的应用通过单一接口与不同模型（OpenAI、其他供应商等）通信，而无需在每次切换时重构系统。
    • 它解决了在更换 AI 供应商时需要重写代码和调整工作流的问题。

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

GPT Go pricing, Banned Trump, Gemini 3 Pro issues, Perplexity Pro subscription issues, Image generation issues

  • GPT Go 的定价是个骗局: 成员们讨论了 Microsoft Copilot 的免费版本如何更好，因为它拥有相同的模型，且没有广告或消息限制，而 GPT Go 每个会话限制 10 条消息。
    • 一位成员表示：大家总觉得微软很邪恶，好像哪家公司真的关心你一样，哈哈。另一位成员指出，在印度，GPT Go 的 4.81 美元 定价不如 X Premium 的 5.76 美元 划算。
  • 特朗普在欧盟和英国被禁，还是虚惊一场？: 频道成员讨论了 特朗普 是否被欧盟和英国禁止，一名成员发布了附件图片作为证据。
    • 一位来自荷兰的成员说 我以为那是特朗普的账号，另一位用户回答 那个账号不隶属于美国政府，他们推测那可能是 Russia Today。
  • Gemini 3 Pro 会写错别字？！: 一位用户表示，Gemini 3 Pro 与所有其他模型相比 有很多缺陷，而且经常出现拼写错误。
    • 另一位成员插话道：但在我看来，他们在第三方类别中仍然领先，以及 他们肯定可以做得更好。
  • Airtel 用户被坑了？！: 频道成员讨论了 Perplexity Pro 的一项促销活动对 Airtel 用户无效，提示信用卡被拒。
    • 几位用户表示他们联系了支持部门，而 支持人员（名为 Sam） 拒绝提供账号被封禁的具体原因。
  • 图像生成停止工作？: 频道中的成员报告 图像生成（image generation） 不再工作，一位成员指出在他们的 Pro 和 Enterprise 账户中都无法使用。
    • 另一位成员表示：此外，他们还阻止了我们地区生成图像，并称 他们这纯粹是在伤口上撒盐。

Perplexity AI ▷ #sharing (1 messages):

kylehanks: 分享我的开源 coding agent 项目 https://github.com/qbit-ai/qbit

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

Sonar API, Website Indexing, Data Delay

  • Sonar API 数据延迟引发的混乱: 一位用户报告由于索引原因，Sonar API 在更新网站新内容时存在 24 小时延迟。
    • 他们询问如何加快网站索引速度，或者完全绕过索引，以便在发布后立即接收数据。
  • Sonar API 索引查询: 一位用户询问如何减少 Sonar API 中的索引延迟，目前更新网站内容大约需要 24 小时。
    • 该用户正在寻找加快索引过程或完全绕过索引以实现即时数据检索的解决方案。

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

Claude Opus 4.5 速率限制对比 Cursor Token 使用情况，GPT 5.2 Codex 性能与语言问题，Cursor Debug 模式与打印语句，Prettier 扩展问题，Cursor 使用限制与订阅方案详情

  • Google Pro 优惠力度超越 Cursor 的代币经济 (Tokenomics)：一位拥有免费 12 个月 Google Pro 订阅的用户指出，Claude Opus 4.5 仅有速率限制，而不像 Cursor 那样 Token 使用量会导致高额成本。
    • 另一位成员附和道，他们在 3 天内就消耗了 $200，并对 Opus 的昂贵程度感到震惊。
  • GPT 5.2 Codex 出现语言错误：一些成员报告称 GPT 5.2 Codex 会随机切换到阿拉伯语，导致其无法使用，尽管其他人声称它优于 Opus 4.5。
    • 一位用户表达了挫败感，表示：我从未见过一个模型会如此频繁地随机切换语言。
  • Cursor 通过打印语句添加“独门秘籍”：一位成员询问 Cursor 为了调试而插入打印语句的功能是 LLM 的功能还是 Cursor 自身的机制。
    • 另一位成员澄清这是 Cursor 的“独门秘籍”（即他们的 Agent/Debug Mode），在没有自定义 MCP 服务器的情况下原生运行，并引用了这篇博文。
  • Prettier 扩展彻底崩溃：一些成员报告 Prettier 扩展完全损坏，无法格式化任何文件，并在 GitHub 上提交了该问题。
    • 有人建议暂时切换到 Biome 作为替代方案。
  • 用户讨论 Cursor 的使用限制与方案：部分用户对 Cursor 的使用限制和方案详情表示困惑。一位用户质疑为什么程序没有使用“额度池”。
    • 成员们澄清说，每月 $20 的方案包含一定数量的额度，但很快就会耗尽，一些用户还发现了 Cursor 的“免费奖励”。

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

image-to-video 斜杠命令，PDF 支持的隐私问题，Claude Vision 模型数据，GPT 5.2 Codex，视频模型的速率限制

  • Image-to-Video 斜杠命令上线：一位用户询问如何使用 /image-to-video 斜杠命令，另一位用户提供了输入命令后访问照片库的逐步指南。
    • 该用户还对更新后的 UI 表示赞赏，团队已收到反馈，并提到该功能仍处于实验阶段，尚未全面推出。
  • PDF 支持引发隐私调查：一位用户询问新的 PDF 支持在处理机密 PDF 文档时的隐私保护机制，随后被引导参阅平台的隐私政策了解详情。
    • 官方强调，在任何开放数据发布之前，平台仍会清除 PII (个人身份信息)，尽管这仍是一项实验性功能，但相关流程保持不变。
  • Nano Banana Pro 的持续报错：用户报告 Nano Banana Pro 存在持续性问题，长时间出现错误，一位成员指出他们自前一天下午 5-6 点以来每小时都会收到错误，并获得了修复错误的步骤。
    • 另一位用户根据 minimaxir.com 指出该模型可能的 2025 年 1 月知识截止日期，而其他用户则报告了验证码问题。
  • 文本文件功能备受期待：用户迫切希望能够上传 .txt 文件以获得更大的上下文窗口，但社区管理员表示这是我们正在开发的功能，并且肯定在计划列表中。
    • 由于已实现 PDF 上传支持，一些用户正尝试将数据库放入 PDF 文件中进行上传。
  • 战斗尚未结束：切换功能保留！：一些用户对直接聊天中的随机模型对战 (random model battles) 感到厌烦，希望将其移除。这是一项长期的测试，有人评论道：这是 LMArena 做过的最糟糕的实现。
    • 其他人则报告了响应时间的改进和错误率的修复，并表示希望 A/B testing 能尽快将 Gemini 3 Pro 引入平台。

LMArena ▷ #announcements (2 messages):

Text-to-Image Leaderboard, Image Edit Leaderboard, flux.2-klein models, wan2.5-i2i-preview model

  • 文生图排行榜迎来新模型：文生图竞技场排行榜已更新，z-image-turbo 目前排名第 22 位，flux.2-klein-9B 排名第 24 位，flux.2-klein-4B 位列总榜第 31 位。
  • 图像编辑竞技场更新 Flux 模型：图像编辑竞技场排行榜已更新，flux.2-klein-9B 排名第 15 位，flux.2-klein-4B 排名第 21 位。
  • Wan2.5-i2i-preview 加入图像编辑精英行列：图像编辑排行榜迎来 wan2.5-i2i-preview，以 1213 的评分稳居第 21 位。

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

LLMs vs AI, Gaming Laptop Model Recommendations, GPU Usage Monitoring, LFM 2.5 1.2B Model Performance, MedGemma Usage and Troubleshooting

  • LLM 是否被视为 AI？：成员们辩论目前的 LLM 是否符合 AI 的定义，一些人认为由于缩写含义和实际能力的差异，该术语被误用了。
  • 推荐 Qwen3 4B 2507 以提升游戏本运行速度：Qwen3 4B 2507 被推荐用于在配备 8GB VRAM 和 16GB DDR5 的游戏本上高效运行，在速度和整体性能上优于 LFM 2.5 1.2b。
  • 使用 Open Hardware Monitor 澄清 GPU 核心负载监控：用户讨论了 Windows 任务管理器将 GPU 使用率显示为 ‘3D’ 而非 ‘CUDA’ 或 ‘GPU 核心负载’ 的困扰，推荐使用 Open Hardware Monitor 来准确显示 GPU 核心负载。
  • 据称 LFM 2.5 1.2B 模型性能卓越：一些用户声称 LFM 2.5 1.2B 表现异常出色，甚至可以与更大的模型相媲美，特别是在翻译等特定任务中，并引用了 Hugging Face 上的 SauerkrautLM-Translator-LFM2.5-1.2B。
    • 其他人则对此表示异议，指出它在简单的 instruct 任务中表现混乱，并警告不要过度吹捧其能力，甚至戏称如果能从这个模型中看到未来，建议“找医生调整下药量”。
  • 调试 MedGemma：如何解决安装问题：用户排查了 MedGemma 的安装问题，包括图像输入和模型的 prompt 模板问题，并发现文件路径中使用非英文序列字符可能会导致故障。
    • 一位用户建议通过 LM Studio 的 discover 板块下载模型而非手动下载，以确保安装正确，推荐使用 unsloth medgemma。

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

VRAM 捐赠请求, AMD AI 9 370 & nVidia 5070 优化建议, LLM 能力与局限性, PCIE gen3x1 vs gen4x1 对 LLM 的性能影响, 在 AM4 平台上为 LLM 推理瓶颈化 RTX Pro 6000

  • 乞求 VRAM 升级：一位成员开玩笑地请求 3090 捐赠，以便为其设备凑齐 128GB VRAM，并通过 Squidward 露宿街头的 GIF 表达了需求。
    • 另外，一位成员抱怨购买了一台仅有 8GB VRAM、搭载 AMD AI 9 370 和 NVIDIA 5070 的笔记本电脑，并寻求模型优化建议。
  • LLM 并没有那么强大：据一位成员称，如果你需要正确、妥善或根本性地完成某些重要工作，不要使用 LLM，并链接到了 huggingface。
    • 他们指出，将模型和上下文保留在 VRAM 中至关重要，且不要使用低于 Q4 的量化。
  • PCIE 降级严重影响性能：一位成员发现，将 3090 运行在 gen3x1 插槽中，推理性能从 x16 插槽的 120 t/s 下降到了 x1 插槽的 90 t/s，尽管此前已有心理预期。
    • 他们计划退掉主板，升级到拥有 gen4x1 插槽 的型号。
  • 打折的 GMKtec AI Max 395 适合 Qwen 3 Next 吗？：一位成员分享了 GMKtec AI Max 395 PC 的图片，询问鉴于其 MoE 特性是否适合运行 Qwen 3 Next，但其他成员认为它可能太慢了。
  • CUDA 仍有不足，Vulkan 突飞猛进：一位成员指出，目前 llama.cpp 对 Qwen3 Next 的实现较差，因此硬件参数在某种程度上无关紧要，并提到在官方构建版本上速度不超过 30-35 t/s。
    • 另一位成员在使用 RTX PRO 6000 配合 Vulkan 时达到了 60 t/s，而另一位在进行 CUDA 优化后仅为 38 t/s。

HuggingFace ▷ #general (251 messages🔥🔥):

生产环境中的 GPU 推理, 云端的 AI 硬件作业, 带有预定义 Prompt 的 FastAPI, Agent 身份与上下文持久化, 定向信息增益模型

  • 捕获配置错误的 GPU 作业的最早时机：成员们正在讨论在生产环境中运行 GPU 推理 或 训练 时，捕获 配置错误的作业 的最早时机是什么。
    • 一位成员在 预训练 的 前 50K 步 期间检测失败，并使用简单的推理脚本来检查生成脚本与推理引擎之间的问题。
  • AI 硬件作业的云端推荐：一位成员咨询哪种 云平台 在 AI 硬件作业 的 价格效率 方面表现最佳。
    • 虽未给出具体推荐，但成员们表示如果后续出现问题可以提供帮助。
  • 在 CPU 上自托管 FastAPI 应用：一位成员想要构建一个带有预定义 Prompt 的 FastAPI 应用，用以封装 Vertex AI API，并将其自托管在运行于 CPU 的 Docker 镜像中。
    • 建议使用 tiny gguf 模型 或参数量不超过 500M 的模型，以获得更好的 CPU 效率；由于加载和推理速度慢，1B 模型 可能需要 15 分钟的超时设置。
  • 处理 Agent 身份与上下文持久化：一位成员在寻求处理 Agent 身份 和 上下文持久化 的建议，旨在为担任不同角色的多个 Agent 持久化预定义的上下文/本体（ontology），但需要比单纯记忆更高级的方案。
    • 另一位成员建议仅使用 DB 和 cpp 中的 RAG 拉取，尽管这种方法可能被视为“老派”。
  • 定向句子相关性评分：一位成员正在尝试使用 定向信息增益模型 来为“句子 B 是否为句子 A 增加了功能价值”进行评分，需要关于创建定向相关性标签数据集的建议。
    • 目标是教授定向相关性，捕捉 B 是否解决、解释、阐述或完成了关于 A 的某些内容，而不仅仅是对称的相关性。

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

drone_fsd_dataset, CUDA learnings, SLMs for Indic languages, AI Recruiting Assistant, slipstream protocol

  • 无人机数据集实现障碍物导航：一位用户分享了使用 MIRROR IDE 生成的数据集，展示了无人机在单次训练运行后，如何在包含 15 个静态障碍物 + 12 个悬浮障碍物 的 60x60 房间 中进行导航 (webxos/drone_fsd_dataset)。
  • CUDA 学习历程详解：一位成员分享了他们 20 天的 CUDA 学习心得，内容涵盖并行性、Kernels 和内存管理 (Learning CUDA From First Principles)。
  • 印度语系 SLMs 任务：一位成员介绍了他们为 印度语系 (Indic languages)（22 种以上印度语言）构建 SLMs 的任务，重点关注 Agentic 使用场景。他们已将 XLMRoberta 蒸馏为 33Mn 参数模型，同时保留了 98% 的准确率。
  • AI 招聘助手上线：一位成员分享了一个新的 Hugging Face Space，用于 AI 招聘助手 (AI Recruiting Assistant)。该工具旨在自动执行候选人评估和冷启动邮件草拟，并内置了偏见缓解和核查功能。
  • Slipstream 协议节省 Token：一位独立研究员介绍了 Slipstream 协议，该协议可节省高达 82% 的 Token Agent 间协作开销，并分享了与该研究相关的文章和 Spaces (Slipstream for Agent Communication)。

HuggingFace ▷ #agents-course (7 messages):

Deep RL Course Unity3D SoccerTwos.exe, AI vs AI interface, LunarLander-v2 deprecated, MCP course certificate

  • Unity3D SoccerTwos.exe 使用：Deep RL Course 的一名学生正在寻求关于在 Unit 7 中使用 Unity3D 工具 SoccerTwos.exe 的指导，因为课程中未涵盖其用法。
    • 该学生还注意到界面中缺失了 AI vs AI 章节，并希望展示他们训练好的模型。
  • LunarLander-v2 问题：一名学生在 Google Colab 中使用 Deep RL Course 的 Unit 1 中的 LunarLander-v2 环境时遇到错误，因为该环境已弃用，建议改用 LunarLander-v3。
    • 然而，在使用 v3 提交模型后，进度并未更新，促使该学生寻求帮助。
  • MCP 课程证书：一位用户询问是否仍有可能获得完成 MCP 课程 的证书。

GPU MODE ▷ #general (17 messages🔥):

PyTorch Profiler Usage, SLMs for Indic Languages, CUDA Project Feedback, NVidia Cutile Library

  • Profiling PyTorch 与索引性能：一位成员就使用 PyTorch profiler 寻求建议，以了解为何某些 index_select 和 index_copy 操作的 CPU wall time 较高，并链接了相关代码作为上下文。
    • 他们怀疑内存分配问题可能是根本原因，并正在寻找通过 profiling traces 诊断问题的方法。
  • 打造印度语系 SLMs：一位成员正在为 印度语系 (Indic languages) 构建 SLMs，目标是 10Mn - 500Mn 参数 之间的模型，用于高效的设备端 Agentic 场景，并已将 Hindi XLMRoberta 蒸馏为 33Mn 参数模型。
    • 他们正在寻求反馈和合作，以构建 世界级 SLMs。
  • 寻求 CUDA Kernel 指导：一位成员请求对其首个 CUDA 项目 提供反馈。该项目在 V100 上实现了一个 Causal Self-attention Kernel，旨在超越原生的 PyTorch 实现，并接近 scaled_dot_product_attention 的性能。
    • 他们分享了关于方法、Block 配置以及在整合共享内存（Shared Memory）和优化 L1 Cache 使用 时面临的挑战细节。
  • 提到用于 Tiling 的 cuTile 库：针对一个问题，一位成员建议使用最近发布的 cuTile 库，以便在 CUDA Kernel 中更轻松地进行手动 Tiling，该库为 Tiling 和共享内存提供了一个通用接口。
    • 该库可能有助于解决 Memory-bound 问题。

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

Triton Top-K Selection, GPU Array Processing

  • Triton Top-K Kernel 故障：一名成员在 GPU 数组上运行其 Triton kernel for top-k selection 时遇到了错误。
    • 提供的代码片段利用 triton.jit 和 triton.language 进行 GPU 加速计算，专门针对 top-k 选择问题，但目前的实现存在错误。
  • 局部 Top-K vs 全局 Top-K：一名成员指出，当前的 Triton kernel 在每个大小为 128 的分片上执行局部 top-k 选择，而不是寻找整个数组的 top-k 元素。
    • 发布者提到 leetgpu.com 上的问题要求从多达一百万个元素的数组中找出 top-k 元素，这意味着需要进行全局 top-k 操作。

GPU MODE ▷ #cuda (28 messages🔥):

Quack's cute.jit vs cute.kernel, BF16 Matmul Precision Issues, Torch's splitK, NaN aware instructions, SMEM buffer and wgmma size

  • Quack 的 CuteDSL 难题：一名成员询问为什么 Quack’s reduce.py 中的函数使用 @cute.jit 而不是 @cute.kernel 进行注解，并澄清了它们分别对应 __device__ 和 __global__。
    • 该成员当时正试图对 bf16 matmul 与 torch 进行正确的有效性检查，但面临精度问题，只是想确认其 kernel 是否存在错误。
  • BF16 精度问题困扰程序员：一名成员调试了 BF16 matmul 的精度问题，发现在 K 值较大时，原生 kernel 产生的结果最大绝对误差（max abs difference）超过 1。
    • 另一名成员解释说 Torch 正在执行 splitK，并建议改用 fp32 计算参考结果，并根据 sqrt(K) 进行缩放，因为 bfloat 真的很糟糕。
  • CuteDSL 生成的 NaN 感知指令：一名成员注意到 CuteDSL 似乎默认生成 NaN 感知指令，这与 Triton 不同，并询问如何禁用此行为。
    • 涉及的指令是 max.NaN.f32 %f71, %f70, %f69;，尽管他没有得到该问题的答案。
  • SMEM 大小吞噬性能：一名成员观察到，当 SMEM 缓冲区大小不完全等于 wgmma 大小时，性能会大幅下降，导致在其上迭代执行 wgmma 时出现问题。
    • 他们假设这是由于每个 warp group 处理更大的 tile size 导致占用率（occupancy）降低，并被建议去 cutlass 频道咨询。
  • 云端 NCU：一名成员寻找允许使用 nsight compute (ncu) 的云服务提供商，并提到 vast.ai 存在问题。
    • 另一名成员推荐了 Lambda Labs，并提供了一个 gist，其中包含有关虽然不是开箱即用但可以运行的云供应商信息。

GPU MODE ▷ #announcements (1 messages):

Smol Training Playbook, Loubna Ben Allal, Open Models

  • Smol Training Playbook 演讲已排期！：Loubna Ben Allal 将介绍她的书：The Smol Training Playbook: The Secrets to Building World-Class LLMs。
    • YouTube 视频 随书附带，提供了关于训练 open models 的更全面信息。
  • 该书是极具价值的参考资料：一名成员指出，这本书对于那些对 open models 感兴趣的人来说是一本精彩且全面的参考资料。
    • 书中可能包含构建世界级 LLM 的秘密信息。

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

NLA Resources, Async GRPO, PyDevTools Handbook, Flux2

GPU MODE ▷ #job-postings (2 messages):

Performance Engineers, Enterprise Pipeline, Vendor Stacks

  • 企业流水线招聘性能工程师：某成员正在为强大的企业级流水线积极寻找在各种厂商堆栈 (Vendor Stacks) 方面具有经验的性能工程师。
    • 提供的总薪酬 (TC) 为 750K-1M+。
  • 关于性能工程师角色职位描述的咨询：一位成员询问了职位描述的详情，并表示在开发和调试企业堆栈中的挑战性问题方面拥有丰富经验。
    • 该成员在开发和调试企业堆栈中的难题方面有大量工作经验。

GPU MODE ▷ #beginner (10 messages🔥):

Shared Memory Allocation, Thread Block Limitations, Warp Register Usage Granularity

  • 共享内存的 Block 级分配：共享内存是按 Block（线程块）分配的，而不是按线程分配。其大小可以在编译时静态确定，也可以在运行时通过 launch API 指定。
    • Block 中的每个线程都会看到一个指向 L1 缓存的相同指针，使其在 Block 内“共享”，这与寄存器空间不同，后者为每个线程分配专用文件。
  • 阻碍线程块占用率 (Occupancy) 的因素：拥有大量的线程块可能会损害 GPU 占用率，因为 Streaming Multiprocessor (SM) 一次能容纳的最大 Block 数量以及共享内存限制。
    • 此外，生命周期短的 Block 可能会因为 Grid Scheduler 的开销而导致性能损失。
  • 寄存器堆分区与 Warp 分配：每个 Streaming Multiprocessor (SM) 分区拥有一个 512x32x32bit 的寄存器堆，可容纳 512 个 Warp 宽 (vec32) 的 32 位寄存器。
    • 每个常驻 Warp 属于四个分区之一，并从该分区分配一组寄存器，这些寄存器从 Warp 开始到退出是固定的（直到 sm_89），并从 sm_90 开始允许有限的动态重分配；单个 Warp 最多可使用 255 个寄存器。

GPU MODE ▷ #jax-pallas-mosaic (1 messages):

Mosaic Masked Load

  • Mosaic 缺少掩码加载 (Masked Load)：用户指出 Mosaic 没有掩码加载功能，这导致每次必须加载 128 个元素。
    • 这与 tl.load 的 mask 参数不同，后者在其他语境中提供了更大的灵活性。
  • Mosaic 的内存访问：用户强调，由于缺乏掩码加载功能，Mosaic 要求一次加载 128 个元素。
    • 这与 tl.load 中可用的掩码加载功能形成对比，后者允许进行更有针对性的内存访问。

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

High Velocity City, NVIDIA CUDA kernel writing, GenAI Learning Series

  • “High Velocity City” - 相对还是绝对？: 一位成员想知道 “high velocity city” 的概念是相对于个人而言的，还是一个绝对的衡量标准。
    • 该成员思考 “high velocity city” 的定义是否取决于个人视角。
  • 南湾 (South Bay) NVIDIA CUDA 学习小组组建中: 一位成员正在寻找 South Bay 地区的学习伙伴，以组建一个晚餐/讨论/学习系列。
    • 该成员希望结合 GenAI 学习 NVIDIA CUDA kernel 编写。

GPU MODE ▷ #triton-puzzles (4 messages):

Triton Puzzle Installation, Triton Version Compatibility, GitHub Issue Solutions

  • Triton Puzzle 安装遇到安装错误: 一位 Triton 新手在安装 Triton Puzzle 时遇到错误并寻求帮助，分享了错误的图片。
    • 图片展示了安装过程中遇到的详细错误视图。
  • GitHub 修复 Triton Puzzle 安装错误: 一位成员提供了一个 GitHub issue 的直接链接，该 issue 解决了 Triton Puzzle 的安装错误。
    • 一位成员确认该链接应该能解决用户报告的安装错误。
  • 固定 Triton 版本 3.2.0 修复 Puzzle 错误: 一位成员建议通过提供的链接将 Triton 版本固定为 3.2.0。
    • 此更改旨在解决运行代码时报告的错误。

GPU MODE ▷ #rocm (13 messages🔥):

Global Loads, DFVS Throttling, VMEM Operations, vmcnt Counter, Dynamic Voltage Frequency Scaling

  • 最大 VMEM 操作限制导致加载停滞: 达到在途 (in-flight) vmem 操作的最大数量会导致停滞，直到之前的操作完成，这与 SMEM 和 LDS 类似。
    • 一位成员询问在这种情况下“操作完成”意味着什么，是数据已从源内存到达，还是有任何 AMD 文档提到了在途加载最大数量的精确值。
  • vmcnt 计数器大小限制 VMEM 操作: vmcnt 计数器用于跟踪在途 vmem 操作（加载、存储、写回），其大小为 6 bits，这可能是一个硬性的上限。
    • 一位成员指出，6-bit vmcnt 计数器可能会将每个 wavefront 的并发 VMEM 操作限制在 2^6 个，而实验显示使用 rocprof compute viewer tool 时只有 18 个加载 VMEM 指令在途，这表明实际限制可能更低。
  • DFVS 可能会限制性能: 建议检查时钟频率，因为 DFVS (Dynamic Voltage Frequency Scaling) 可能会限制性能。
    • 一位成员解释说，如果功耗过高，DVFS 会降低时钟频率，从而降低吞吐量。
  • 使用 rocprofiler 分析 VMEM 操作: 成员建议使用带有特定选项（–att-perfcounters 和 …-ctrl）的 rocprofiler 来监控在途 vmem 操作。

GPU MODE ▷ #metal (2 messages):

Memory Efficient Attention (MEA), Apple Silicon (Metal) native Stable Diffusion, LLaMA models on Metal, Core ML Stable Diffusion Performance, MPSGraph custom kernels

  • MEA: More Excellent Attention?: 一位成员分享了 Memory Efficient Attention (MEA)，这是一种新颖的方法，实现了 O(n log n) 的复杂度，并在长序列上优于现有方法。
    • 他们指出，这在 无法使用 vLLM 的情况下非常有用，另一位成员推测这种 扩展性允许对整本书进行 Attention。
  • Craiyon 与新的 Apple Silicon 支持！: Craiyon 团队通过这篇博客文章展示了他们在 Apple Silicon 上实现原生 Stable Diffusion 的工作，并取得了令人印象深刻的加速。
    • 一位成员称赞了将模型量化为 4-bit 和 2-bit 的 巨额工程努力，这使其在 Apple 硬件上表现出色。
  • LLaMA 在 Metal 上：飞快！: 用户报告称在 Metal 上运行 LLaMA 模型速度非常快，其中一位提到在 M2 Max 上的速度达到 100 tokens/second。
    • 他们澄清说，他们将 torch.compile 设置为 True，并使用了 PyTorch 的 nightly 版本。
  • Core ML Stable Diffusion，性能提升！: 一位成员询问了 Core ML Stable Diffusion 的性能，并链接到了一个相关的 GitHub issue，表明目前 表现不佳。
    • 另一位回应称，他们使用该模型大约能达到 5 iterations/second。
  • MPSGraph：自定义 Kernels，更强性能？: 一位成员正在研究使用带有自定义 Kernel 的 MPSGraph，以解决 PyTorch 中的性能问题。
    • 他们发现这比 CUDA 复杂得多，并且到目前为止仍在为此挣扎。

GPU MODE ▷ #status (2 messages):

GPU Mode Competition, Modal Integration, Leaderboard Instability, Profiling Limitations

  • **Dual GEMM 竞赛迎来新排行榜: 针对问题 #3 创建了新的 “final_nvfp4_dual_gemm” 排行榜，提交作品需在 **2026 年 1 月 20 日前在 GPU Mode 网站提交方可参与奖金评选。
    • 过去的测量结果由于 runner 不稳定而波动，如果稳定性问题持续存在，将采用人工验证；但关闭旧排行榜会暴露解决方案，因此暂时保持开放。
  • Modal 应用于问题 #3 和 #4 的 Metal: 一个使用 Modal 的新排行榜现已针对问题 #3 启动，要求通过 “modal_nvfp4_dual_gemm” 排行榜提交，并带上 “B200” GPU 标签，点击此处查看。
    • 切换到 Modal 旨在确保可靠的基准测试数据，但由于安全策略和隔离要求，它移除了 Profiling 支持，建议用户从 Prime Intellect、Verda 或 Sesterce 等供应商处租用 GPU 进行 Profiling。
  • 安全忧虑导致 Profiling 支持被撤销: 无服务器平台无法保证使用 ncu 的 Profiling 支持，因为 ncu 可能会暴露相邻进程并泄露模型定义。
    • 诸如非隔离作业过度占用资源、并发 GPU 作业、依赖项升级以及时钟频率/热量变化等问题，由于调试所需的 SSH 访问权限受限，一直困扰着竞赛。
  • 基准测试稳定性优先于 Profiling: 转向 Modal 优先考虑可靠的基准测试结果，以维护竞赛的公正性，尽管失去了 Profiling 能力。
    • Modal 的依赖项已进行版本控制，可通过 GitHub 的 pull request 进行审查和修改。

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

2kian: 再次看到非常酷的适配器！

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

使用 CuteDSL 的 Triton 性能，PTX 中基于 NAN 的 F32 max，SMEM 到 RMEM 的加载，匹配 Triton 的 Softmax，CuteDSL 生成的 SASS 代码

  • CuteDSL 性能追求未及 Triton：一位成员正尝试使用 CuteDSL (github.com/FL33TW00D/submarine) 达到 Triton 的性能，但目前仍慢了 2us。
    • 他们正在研究生成的 PTX 代码，发现 CuteDSL 默认似乎会生成 NaN 感知的指令（如 max.NaN.f32），并询问是否有办法禁用此行为。
  • 非 NaN 版本并未显著提升性能：一位成员建议原作者查看 SASS 而非 PTX，因为根据他们的经验，从 max.NaN.f32 切换到非 NaN 版本并不会明显改变性能。
    • 他们建议使用 NCU + GPT 来辅助查找 SASS 指令的文档。
  • 深入研究 SASS 揭示了更微妙的情况：原作者深入研究了 SASS 并表示它揭示了更复杂的情况。
    • 他们提出了一个关于在使用 cute.domain_offset 时，如何保持 mO_cur 与 mO 以相同方式对齐的问题。
  • Triton 依然是冠军：一位成员请求原作者，如果最终能匹配或超越 Triton 的 softmax，请分享关键技巧。
    • 原作者回复说，Triton 赢得了这一局。

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

2-GPU NVLink AllReduce 库，NVIDIA NCCL 性能对比，尾延迟稳定性

  • Yali 库号称性能卓越！：一位成员正在为 Yali 寻找测试者，这是一个 2-GPU NVLink AllReduce 库，据称其性能优于 NVIDIA NCCL 1.2x-2.4x。
    • 他们强调，通过在 GPU 通信中应用高性能系统的原理，Yali 提供的尾延迟稳定性提高了 50 倍以上。
  • 寻求更快的 2-GPU NVLink 测试者：一位成员正在为 Yali 寻找测试者，这是一个 2-GPU NVLink AllReduce 库。
    • 他们强调，通过在 GPU 通信中应用高性能系统的原理，Yali 提供的尾延迟稳定性提高了 50 倍以上。

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

Runner 运行缓慢问题，Modal 迁移，基准测试开销，速率限制，CUDA Out of Memory

  • Runner 性能下降困扰提交：用户报告称，重新提交代码后，其 kernel 运行时间从 14.x us 增加到 22.x us，特别是在被标记为缓慢的 runner b200-02-gpu4-runner 上，这影响了提交性能。
    • 一位用户建议使用从多个终端启动的临时变通方案以避开缓慢的 runner，但正如 <@arseniivanov> 所指出的，这可能会堵塞 GPU。
  • Modal 迁移解决 Runner 不一致问题：由于当前 NVIDIA 硬件上的 runner 性能一致性和测量稳定性问题，比赛在第 3 题和第 4 题将迁移到 Modal，目前的 benchmark 数据显示约有 2x 的降速。
    • 虽然 Modal 存在一些波动，但预计会更稳定，尽管它不允许进行 NCU profiling；迁移的详细信息见 此 Discord 帖子。
  • 性能基准测试显示开销困扰：成员们注意到新排行榜上仍有 0.5 us 的额外开销问题未修复，而其他人观察到他们的 kernel 运行时间在增加，这表明存在更广泛的开销问题。
    • 特别是提交记录 369747 的时间为 31us，而提交记录 369709 为 20us，尽管运行的是相同的代码。
  • Modal 负载过重需要速率限制：在开放 Modal 后提交了超过 5.2K 个任务，任务时长从 1 分钟到 4 分钟不等，预计排队时间会很长，因此在第 3 题之后需要实施速率限制以控制成本，目前的成本已达 $2K。
    • 有人提出了一种替代速率限制的方法：定期仅为每个用户运行最新的 kernel，跳过未更改的部分，但这被 <@austin362667> 视为另一种形式的速率限制。
  • CUDA 显存问题困扰任务：用户偶尔会遇到 CUDA Out of Memory 错误，可能是由于运行之间显存未正确清理，建议将重新提交作为一种可能的解决方法。
    • 据 <@s1r_o> 称，如果在重新提交时获得了一个不同的容器，此问题不会显著影响测量结果。

Latent Space ▷ #ai-general-chat (95 messages🔥🔥):

Gregor Zunic 推文可见度, Sulaiman Ghori xAI 访谈, Vercel 'skills' 发布, GPT 5.2 Pro 解决 Erdos 问题, GPT-5.2 性能

  • Gregor Zunic 的推文获得巨大关注：Gregor Zunic 在 2026 年 1 月 16 日发布的一条推文获得了显著反响，累积了 119,777 次查看和超过 760 次点赞。
    • 对 @gregpr07 的社交媒体参与度分析强调了该推文出人意料的曝光率。
  • Sulaiman Ghori 透露 xAI 秘闻：xAI 技术团队成员 Sulaiman Ghori 在这次采访中讨论了 Colossus 数据中心的快速建设、公司的招聘理念以及在 Elon Musk 领导下工作的强度。
    • 采访后不久便出现了戏剧性的一幕，Ghori 显然在 Twitter 上失去了 xAI 工作认证标识，并且删除了大量推文，疑似已被解雇。
  • Vercel 发布 ‘Skills’ 作为 AI Agent 工具包：Guillermo Rauch 宣布在 Vercel 上推出 ‘skills’，这是一个开放且与 Agent 无关（agent-agnostic）的生态系统，被设计为 AI 能力的包管理器。
    • 用户可以使用命令 ‘npx skills i vercel-labs/agent-skills’ 开始集成这些工具；更多详情请参阅 React 最佳实践。
  • GPT 5.2 Pro 展示数学神技：据 Neel Somani 称，GPT 5.2 Pro 成功解决了此前悬而未决的 Erdos problem #281。
    • 数学家 Terence Tao 指出，这一成就标志着人工智能解决未解数学问题的一个清晰案例。
  • GPT-5.2：扩展挑战与性能洞察：Lee Robinson 在这条推文中分享了关于长期运行 AI Agent 的研究见解，指出虽然 GPT-5.2 能力显著增强，但系统尚未达到生产就绪（production-ready）水平。
    • 关键发现包括：Prompt Engineering 的重要性超过了复杂的分布式系统架构，且与新型专用模式相比，传统软件模式反而会阻碍 Agent 性能。

Latent Space ▷ #private-agents (1 messages):

sarav1n: 你在运行什么？Apple Silicon 应该不会有问题。

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

ElevenLabs 估值, Levelsio E-Girl Vlog, HeartMuLa AI 音乐模型

  • ElevenLabs 寻求 110 亿美元天价估值：AI 初创公司 ElevenLabs 正在洽谈以 110 亿美元估值进行融资，较几个月前的 66 亿美元大幅飙升，详见此贴。
  • Levelsio 的 ‘E-Girl’ 角色替换策略：Levelsio 发布了一段视频博客，采用 “e-girl” 形象来解释角色替换（character swaps）的机制，链接见此处。
  • HeartMuLa：新音乐模型击败竞争对手：此推文串中强调，HeartMuLa 作为一款采用基于 LLM 方法的新型开源音乐生成模型，拥有多模态输入和特定片段样式处理功能，据称在歌词清晰度方面优于 Suno v5 和 Udio v1.5。

Yannick Kilcher ▷ #general (67 条消息🔥🔥):

Zero Knowledge Proofs for AI Governance, Trusted Execution Environments (TEE) Limitations, Learning Rate Scaling and Batch Size, Directional Information Gain Model, Open Source Coding Agents

  • **ZKPs 助力 AI 治理：一名成员提议将 **Zero Knowledge Proofs (ZKPs) 用于自主 AI 治理，从而在不泄露敏感信息的情况下验证合规性；设想一种在维护隐私的同时进行主动监管的模式。
    • 另一名成员警告称，虽然 ZKPs 可以证明某个证明的存在，但它们本身并不能解决形式化和命题证明的问题。ZKPs 可以证明你想要运行的模型确实是实际执行的模型。
  • **TEE 并非万无一失：讨论围绕用于安全计算的 **Trusted Execution Environments (TEEs) 的局限性展开，指出即使有基于硬件的内存加密，也存在潜在漏洞。
    • 一名成员提到，尽管有安全特性，TEEs 仍可能被攻破，并引用了 DefCon 演讲中关于通过拦截 RAM 与芯片之间的解密代码来利用漏洞的内容，但也指出 Nvidia 的新服务器具有服务器级的 TEE，这有助于解决该问题。
  • **像专家一样缩放学习率：一名成员询问了关于学习率缩放（learning rate scaling）作为 **batch size 函数的共识，引用了一篇论文，该论文主张 learning_rate ∝ sqrt(batch_size)。
    • 其他人指出线性缩放很常见，但通常需要调整，并质疑严格规则的必要性。
  • **定向数据动态驱动数据集设计：一名成员就为定向信息增益模型（directional information gain model）**创建数据集寻求建议，旨在为句子 B 是否比句子 A 增加了功能性价值（而不不仅仅是相似度）打分。
    • 建议包括探索 RAG、re-rankers 以及知识图谱研究来验证相关信息，因为定向相关性取决于具体的实例或场景。
  • **智能体之选：Devstral 对比 Codex：一名成员询问适用于自托管模型的开源编程 Agent，有人建议 **Devstral 2 Small 是一个不错的选择。
    • 此外，有人指出 Devstral 2 Medium 在智能体代码库任务（如 GPT Codex）上显然与 Claude Sonnet 4.5 旗鼓相当，而 Kilo Code 只是一个可以插入本地模型（如本地托管的 Devstral 2）的扩展。

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

Cold Read of arXiv Paper, Time Zone Differences, Discord Event for Paper Discussion

  • 安排 arXiv 论文现场初读活动：一名成员安排了一篇 arXiv 论文 的现场初读（cold read），并邀请感兴趣的人回复点赞。
    • 随后在 Discord 上 创建了一个活动，邀请计划参加的人点击“感兴趣”。
  • 时区问题阻碍参与：一名成员表示，由于处于 Central European UTC 时区，在预定的现场初读期间他可能正在睡觉。
    • 另一名成员承认了时区差异，并表示无法将活动改到对每个人都方便的时间。
  • 现在开始！论文讨论开始：一名成员两次宣布论文讨论开始。
    • N/A

Yannick Kilcher ▷ #ml-news (10 messages🔥):

阿里巴巴 Qwen 团队, 蛇油推销员 SAM, Anthropic 为 Claude 开发的知识库, Gaussian Splatting 音乐视频, Anthropic 的 Assistant Axis

  • 阿里巴巴 Qwen 团队领导层：阿里巴巴 Qwen 团队的技术负责人 Justin Lin 分享了一个与其工作相关的链接。
    • 分享的内容提供了有关 阿里巴巴 Qwen 团队所采用的技术发展和策略的见解。
  • Snake Oil SAM 销售指控：成员们讨论了关于 SAM 采取 snake oil（虚假宣传）策略的指控，暗示许多最初的关键人物已因此类问题离职。
    • 这场讨论反映了对 AI 社区内某些领导层或商业惯例的批判性观点。
  • Anthropic 为 Claude 开发知识库：分享了一个指向 testingcatalog.com 的链接，表明 Anthropic 正在为 Claude 开发知识库。
    • 这意味着 Anthropic 正致力于通过提供结构化知识资源来增强 Claude 的能力，从而可能提高其性能和可靠性。
  • A$AP Rocky 的 Splatting 音乐视频：一位成员分享了 A$AP Rocky 的音乐视频，其中运用了 Gaussian Splatting 技术。
    • 这突显了 Gaussian Splatting 在创意和艺术项目中的创新应用。
  • Anthropic 的 Assistant Axis：分享了一个指向 Anthropic 关于 Assistant Axis 研究的链接。
    • 这项研究可能探索了 AI 助手的涉及与功能，侧重于其能力的不同维度和方面。

DSPy ▷ #general (82 messages🔥🔥):

通过 dspy 优化 skill.md, DSPy 3.1.2 发布, 递归语言模型 (RLMs), 用于本地沙箱/解释器的 Deno, GEPA 与 RLM 组合

  • 有人尝试用 DSPy 优化 skill.md 吗？：一位成员询问有关使用 DSPy 优化 skill.md（本质上是一个 Prompt）的问题，并引用了一篇关于优化 Anthropic skills 的相关文章。
    • 该用户正在寻求编写高效 skill.md 文件的策略，并询问是否有人尝试过使用 DSPy 进行优化。
  • RLMs 发布，DSPy 3.1.2 上线！：团队刚刚在 DSPy 3.1.2 中发布了 dspy.RLM，极大扩展了单行代码可实现的功能。
    • 一位团队成员在 6 月份的 DSPy 3.0 发布演讲中曾神秘地承诺过此版本，并分享了公告链接。
  • Deno 被选为本地 WASM 运行时：DSPy 使用 Deno 作为其本地沙箱/解释器，因为它具有安全的 WASM 运行时能力。
  • Genetic-Pareto (GEPA) 与 RLMs：天作之合？：GEPA (genetic-pareto) 和 RLMs 是可组合的，具有 RLM-as-an-optimizer（RLM 作为优化器）策略的潜力。
    • 一位团队成员认为 GEPA 是一个基础性理念，并强调了 RLMs 在从代码编写文档方面的应用，引用了其处理极长输出的能力。
  • 使用 RLMs 生成这些文档！：成员们讨论了使用 RLMs 从代码生成文档，这在以前是一项不可能完成的任务。
    • 讨论指出，你可以对所有先前的提议进行此操作，并且可以兼顾整个树状结构。

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

增加 App 容量, 订阅错误, Manus AI 会议纪要, 账单问题, 赚取积分

  • 请求增加 App 容量: 一名成员请求增加 Manus 的最大 App 容量限制，理由是在尝试创建一个包含 100 个总计 600 MB 的 MP3 文件的音频播放器 App 时遇到了限制。
    • 他们希望 启用更大的应用程序 能为开发者和用户开启新的可能性和更丰富的项目。
  • 用户遇到订阅错误: 一名成员报告遇到了高额的逾期付款错误，导致无法降级计划。
    • Manus Support 成员回复了该用户，并提供私下协助以解决订阅错误。
  • Manus AI 会议纪要功能: 一名成员分享了一段 YouTube 视频，介绍如何使用新的 Manus AI Meeting Minutes 功能。
    • 一名成员开玩笑地评论道 居家办公的人会喜欢这个 (Home office bros will love this)。
  • 账单问题导致项目离线: 一名成员报告其项目因账单问题且无法将 $400 的计划降级而下线，这让他感到很困扰，因为他的女性圣经学习平台变得无法访问。
    • Manus support 已私下联系他提供帮助。
  • DracoAI 被推崇为更优替代方案: 一名成员声称 dracoai.app 与 Manus 相比是 更高层级 (next level) 的存在，强调其具备执行 API 调用的能力，包括拨打其电话。
    • 他们表示 编辑系统提示词 (system prompt) 并添加特定的 API 工具，这玩意儿简直是更高层级的。

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

Discord 规则, Green V2 Blackwell, tinygrad twitter, tinygrad Logo, MLPerf

  • 筹款购买 Green V2 Blackwell: 一名用户尝试联系 tinygrad 团队，帮助朋友为 Green V2 Blackwell 筹款，但被警告 推销 = 封禁 (shilling = ban)。
    • George Hotz 澄清说 此 Discord 仅用于讨论 tinygrad 的使用，并禁止用户尝试筹款。
  • tinygrad 需要新 Logo: George Hotz 询问是否 有人想为其制作新 Logo？，因为 tinygrad twitter 上目前的 Logo 太旧了。
    • George Hotz 更新了 GitHub Logo，并要求从 tinygrad.org 获取 SVG 格式的 Logo，这样可以适配任何尺寸。
  • tinygrad 第 3 次会议即将召开: 宣布将于 圣地亚哥时间周一上午 9 点 举行第 3 次会议，发言顺序随机。
    • 会议议程包括：公司更新、驱动程序、image dtype、汇编 (assembly)、jit asserts、assign、mypy、llama 训练、viz / fast gemm、其他悬赏任务 (bounties)。
  • tinygrad 计划今年举办竞赛: George Hotz 表示 我想在完成 405b mlperf 之后，在今年举办一些竞赛。

tinygrad (George Hotz) ▷ #learn-tinygrad (4 条消息):

tinygrad 配合 pyarrow/parquest, Tensor.from_blob, zero_copy_only

  • 探索 tinygrad 与 PyArrow 及 Parquet 的兼容性: 一名用户询问关于 tinygrad 配合 PyArrow/Parquet 使用的问题，并提供了一个使用 ds.dataset 加载数据的示例，寻求比 Tensor.from_blob 更好的替代方案。
    • 一个提议的解决方案建议将 Tensor.from_blob 与 PyArrow 结合使用，展示了其在 Pandas DataFrame 和 PyArrow 数组上的用法，但指出该方法 未经过充分测试和维护，首选先转换为 numpy。
  • tinygrad 中 Tensor.from_blob 的用法: 一名成员分享了一段代码片段，演示了如何对 numpy 和 pyarrow 数组使用 Tensor.from_blob，并包含验证结果的断言 (assertions)。
    • 代码涵盖了从 numpy 数组和 pyarrow 数组创建 tinygrad Tensor，并断言生成的 Tensor 与原始数据一致。
  • 零拷贝 (Zero-Copy) 数据加载至 tinygrad: 一名用户在设置 zero_copy_only=False 处理嵌套数组后，将其初始数据加载方案替换为使用 numpy 堆叠 (stacking) 的方案。
    • 他们指出使用 zero_copy_only=False 会返回一个嵌套数组 (array([array([1., 2., 3.], dtype=float32), array([1. , 1.1, 1. ], dtype=float32)], dtype=object))，且速度与 from_blob 相似，在包含文件读取的情况下，150 万行数据耗时 24 秒。

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

K2-Thinking 上下文长度问题, 来自 Claude/GPT-5/Gemini-3 的蒸馏模型, Kimi 订阅与计费问题, Kimi 中缺失的短语, Kimi 退款请求

  • 蒸馏模型引发期待：成员们正期待在未来几个月内看到从 Claude/GPT-5/Gemini-3 蒸馏出的模型，以及长上下文处理能力的改进。
    • 一位成员认为 K2-Thinking 在 30k tokens 之后的上下文处理表现不佳，且大多数模型只有在其宣传的上下文窗口的一小部分内表现良好。
  • 订阅问题困扰用户：一位成员反映，尽管取消了 $0.99 方案并注销了 Kimi 账号，其 Visa 卡仍被重复扣费。
    • 另一位成员建议通过私信发送邮箱地址来解决此问题，还有成员建议联系 membership@moonshot.ai 申请退款。
  • 用户反馈意外的订阅扣费：一位成员反映，在未收到提醒且未激活账号的情况下，其 Kimi 方案被扣除了 $19，并请求退款。
    • 客服引导其发送邮件至 membership@moonshot.ai 申请退款，该成员随后确认已收到回复。
  • 短语缺失问题：一位用户分享了一张图片，显示常用的短语不见了，并询问为何将其移除。
    • 另一位成员回复称，这些短语现在位于加号图标下的“预设 (presets)”中，并展示了更名后的图片。

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

Raspberry Pi AI HAT+, Mojo 对 Hailo AI 芯片的支持, FaceNet 替代方案, 商用人脸识别模型

  • 树莓派推出用于 GenAI 的 AI HAT+：Raspberry Pi AI HAT+ 已发布，引发了关于 MAX 和 Mojo 是否支持 Hailo AI 芯片的讨论。
  • Mojo ❤️ Raspberry Pi AI HAT+?：一位成员询问在 MAX 和 Mojo 中增加 Hailo AI 芯片支持的可能性，设想学生们可以利用支持 Raspberry Pi AI HAT+ 的 MAX 平台和 Mojo 语言轻松上手。
    • 另一位成员对这种集成表示期待，其动力源于创建一个训练神经网络并将其部署在机器人上的端到端系统。
  • Mojo 需要开放编译器来进行 Hailo 集成：一位成员认为，如果没有开源编译器（或至少是一个可以交给编译器的开放 IR），Mojo 将很难集成 Hailo。
    • 他们指出 AMD 的 NPU 也面临类似的问题。
  • 寻求人脸识别模型建议：一位成员正在寻找可商用的人脸识别模型/仓库，因为 FaceNet 在现实场景中表现不佳，尤其是在光照变化和面部特征变化的情况下。
    • 他们还询问了在生产环境中表现更好的 FaceNet 替代方案，以及提高稳健性的成熟方法（光照不变性、预处理、训练技巧）。

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

PyTorch 导入问题, Numpy 导入问题, pixi shell 问题, Python 模块导入

  • PyTorch 和 Numpy 导入问题演变成 Pixi 地狱：一位成员在使用 pixi 安装 PyTorch 和 Numpy 后遇到导入问题，尽管安装成功，但仍收到错误提示且无法定位模块。
    • 一位助手指出 PyTorch 在 conda 上被称为 pytorch，并进一步澄清，需要使用 Python module 在 Mojo 中访问 Python 库，而不是直接导入 Python 代码。
  • Pixi shell 困扰新手：该成员确认已进入 pixi shell，且模块已列在 .toml 文件中，但在 Mojo 文件中仍无法识别。
    • 助手澄清说，在 Mojo 中无法直接导入 Python 代码，必须使用 Python module 或自定义的 cpython 绑定。
  • 通过 Python 模块导入找到解决方案：该成员确认模块导入成功并计划进行测试，对助手的帮助表示感谢。
    • 助手谦虚地表示，由于参与了该模块的创建过程，所以对用法记忆深刻。

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

Aider ComposerLooks，Paul Gauthier 的去向，Aider 的未来发展

  • ComposerLooks 缺乏讨论：一位成员询问了 Aider ComposerLooks，指出它虽然拥有大量的 star，但讨论却很少。
    • 原作者对其真实应用场景以及对最新 AI 模型的支持感到好奇，并意识到它目前可能无法正常工作，表示需要查阅文档。
  • 主开发者“失踪”之谜：成员们好奇 Aider 的主要开发者 Paul Gauthier 的去向，注意到他最后的活跃时间是在一月。
    • 有人猜测他可能被 Anthropic 聘用，因为代码与 Claude 非常相似，以此来消除开源竞争。
  • Aider 欢迎社区协助：Paul Gauthier 确认他一直忙于其他项目，并乐于合并社区贡献。
    • 一位成员询问除了自主 Agent 功能外还缺少哪些功能，但原作者指出该项目在功能上已经很完善了。
  • 对“弃置软件”的排斥情绪出现：一位成员表示，如果 Aider 被视为 abandonware（弃置软件），他将不愿对其投入精力。
    • 这凸显了在没有原开发者积极参与的情况下，对项目维护和未来发展的担忧。

aider (Paul Gauthier) ▷ #links (1 条消息):

生产就绪的 LLM & RAG 系统，AI 驱动的搜索，摘要总结，集成 LLM + RAG 管道

  • 生产就绪的 LLM & RAG 系统交钥匙方案：一位成员致力于将创意和杂乱的数据转化为生产就绪的 LLM & RAG 系统。
    • 他们专注于让 AI 在真实的工作流中可用，而不仅仅是做演示。
  • 专家协助集成 LLM + RAG 管道：一位成员提议帮助那些希望将 LLM + RAG 管道集成到生产环境，且不想经历反复试错的开发者。
    • 他们还为需要指导以使 AI 工具真正发挥作用的独立开发者或顾问提供帮助。
← 返回首页