AI 开发者日报

• 《财富》杂志证实Anthropic存在高于Opus的层级：一篇已被删除的"Claude Mythos"帖子被@M1Astra保存下来，多个后续帖子引用了《财富》杂志的报道，称Anthropic正在推出Capybara，被描述为一个高于Opus的新层级，比Claude Opus 4.6"更大、更智能"。由@scaling01、@Yuchenj_UW和@kimmonismus总结的报道称，Capybara在编码、学术推理和网络安全方面得分显著更高，但由于成本和安全性考虑，其推出受到限制。

• 计算强度是核心主题：几位发帖者推断Anthropic正在大力投入规模扩展，根据之前Dario的评论推测可能是一个约10T参数级别的模型，尽管这仍停留在评论层面，未经官方确认；参见@scaling01和@Yuchenj_UW。另外，由@FirstSquawk转述的《金融时报》报道称，谷歌即将资助Anthropic的数据中心，这强化了前沿竞争越来越受制于电力和资本支出，而不仅仅是算法的观点。

• 基础设施压力在生产环境中显现：这次泄露发生在Anthropic可用性糟糕的一天，@dejavucoder、@iScienceLuvr等用户广泛抱怨529错误/错误率升高。实际启示是，Anthropic似乎在激进的扩展雄心与仍然紧张的服务容量之间寻求平衡。

• GLM-5.1正在加大对闭源编码模型的压力：智谱通过@Zai_org宣布GLM-5.1对所有编码计划用户开放，同时提供了代理使用的文档@Zai_org。社区反应将其视为高端中国开源或半开源编码模型正在缩小差距的又一迹象：@kimmonismus、@XFreeze以及Arena更广泛的排行榜分析@arena都指出，开源与闭源之间的差距比一年前要小得多。

• 本地部署的经济性持续改善：推文中的一个反复出现的主题是，本地模型现在对于许多工作流程来说已经"足够好"。例子包括@TheGeorgePu用本地Qwen 3.5 14B设置替换昂贵的TTS订阅，@LottoLabs报告Qwen 27B与Hermes Agent具有强大的经济性，以及@0xSero将Qwen3.5-35B压缩到足以在24GB VRAM中容纳完整上下文，平均性能下降仅为**1%**左右。

• 量化和缓存工作仍然是关键推动因素：@iotcoi发布了一个TurboQuant vLLM分支，具有融合的Triton KV写入路径和解码注意力，针对Qwen3.5-35B AWQ、1M上下文和4M KV缓存。同时@bnjmn_marie在RTX Pro 6000/B200/H100上对Qwen3.5 27B格式进行了基准测试，INT4成为RTX Pro 6000级硬件上最佳推理选项。

• 但TurboQuant目前正面临争议：本系列中最强烈的研究争议来自@gaoj0017和更长的澄清说明@gaoj0017，指控Google的ICLR 2026 TurboQuant论文在理论和基准测试中歪曲了RaBitQ，包括不公平的CPU与GPU比较。这并不否定TurboQuant的工程价值，但确实对其一些公开的比较声明提出了质疑。

• Hermes Agent 成为开源智能体的焦点：在数据集中最具持续产品动力的当属 Nous Research 的 Hermes Agent。@NousResearch 将 Hugging Face 集成为首要推理提供商，提供 28 个精选模型 以及更多模型的访问权限，而 @ClementDelangue 将其视为迈向具有记忆、持久机器访问和模型选择能力的开源智能体的一步。来自 @fancylancer3991、@PolackJack 和 @alexcovo_eth 的用户报告强调，相比像 OpenClaw 这样重度依赖浏览器自动化的设置，Hermes Agent 具有更低的摩擦和更好的持久性。

• 智能体基础设施在追踪、评估和可调试性方面日趋成熟：Hugging Face 的 @ClementDelangue 呼吁建立 开源智能体追踪数据集，后续讨论指向了 @yueqi_song 提出的 Agent Data Protocol。LangChain 推出了一系列面向生产的材料：智能体评估准备清单 @LangChain、Deep Agents IDE 风格的用户界面指南 @LangChain_JS，以及用于提示词推广/回滚的 LangSmith Prompt Hub Environments @LangChain。方向很明确：技术栈正从"带工具的聊天机器人"转向智能体的软件生命周期原语。

• 面向智能体的基准测试开始反映真实工作负载：Artificial Analysis 通过 @ArtificialAnlys 推出了 AA-AgentPerf，专注于 真实的编码智能体轨迹、超过 10 万序列长度，以及以 每加速器/每千瓦/每美元/每机架的并发用户数 表示的吞吐量。这比合成令牌基准测试更具部署相关性，对于比较用于智能体密集型服务的加速器系统的团队来说应该很有用。

• OpenAI的Codex生态系统正朝着工作空间原生自动化方向发展：OpenAI开发者通过@OpenAIDevs展示了Codex插件和使用案例库，而Box则推出了一个用于自动化Box内容工作流的Codex插件@Box。来自@theo、@nickbaumann_和@reach_vb的用户反馈表明，重心正从提示词/响应模式转向持久化工作空间、问题系统、终端、PR流程和插件。

• 获胜的用户体验模式日益成为"软件舰队管理"：@VibeMarketer_很好地捕捉了这一新兴模式：类似看板的卡片、隔离的工作树、智能体拥有的任务以及基于差异的审查。相关工具包括@ctatedev推出的新型智能体浏览器仪表板，用于实时浏览器会话调试，以及来自@JTLonsdale和@cognition等Cognition/Devin相关评论中对多智能体软件工程系统的广泛热情。

• Composer 2和长周期编码评估正在提高标准：虽然CursorBench的讨论在这里大多是间接的，但@cwolferesearch指出了该基准测试的优势：真实的编码会话、未充分指定的提示词、更广泛的质量维度以及每个任务平均修改181行代码。这比静态的玩具任务设计更健康的基准测试，并与更广泛的长周期智能体评估趋势保持一致。

• Meta发布了实用的SAM 3.1加速版本：@AIatMeta发布了SAM 3.1，这是SAM 3的直接更新版本，引入了对象多路复用功能，允许在单次前向传播中处理多达16个对象。Meta表示，对于中等对象工作负载，这大约将视频处理吞吐量从单个H100上的16 FPS提升至32 FPS，这对于可访问的视频分割流程具有重要意义。

• 世界模型和机器人技术均有显著的开源发布：@LiorOnAI强调了LeCun的LeWorldModel论文/代码库，这是一个小型开源世界模型，旨在通过SIGReg使表示崩溃在数学上不可能发生，声称实现了48倍更快的规划速度和约200倍更少的token使用。在机器人数据方面，@UnitreeRobotics开源了UnifoLM-WBT-Dataset，这是一个真实世界的人形机器人全身遥操作数据集，计划进行滚动更新。

• 语音/开放音频仍然是健康度最高的开源类别之一：Cohere新推出的2B Apache-2.0 Transcribe模型获得了@victormustar的高度评价，以及@vanstriendaniel的吞吐量测量报告，显示在A100上12分钟内转录了33小时的音频。Mistral的Voxtral TTS论文被@qtnx_标记，而浏览器/本地演示则出现在@sophiamyang和@nickfrosst的分享中。

• 开源机器人技术栈也变得更加可复现：AI2发布了MolmoBot，这是一个完全在模拟环境中训练的开源机器人操作套件，通过@allen_ai提供了代码、训练数据、生成流程和评估方法。这补充了Unitree的数据集，并标志着在顶级实验室之外实现可复现机器人研究方面的持续进展。

• Anthropic/Capybara 泄露事件：@Yuchenj_UW 关于 Capybara 的推文成为技术类内容中互动量最高的项目，总结了 Opus 之上的新层级及其报告的基准测试提升。

• Paul Conyngham 的 AI 辅助狗癌症治疗：@sama 分享了一个使用 ChatGPT 及相关工具帮助设计mRNA 疫苗方案治疗狗癌症的故事，这成为关于 AI 赋能个性化医疗的重要讨论点。

• TurboQuant 批评：@gaoj0017 关于论文方法论的争议获得了异常高的互动量，很可能是因为它挑战了一篇被大力推广的系统论文。

• GLM-5.1 发布：@Zai_org 宣布 GLM-5.1 广泛可用获得了强烈反响，强化了人们对开源编码模型的持续兴趣。

• 智能体开放基础设施：@OpenAIDevs 关于 Codex 插件和 @NousResearch 关于 Hugging Face 集成到 Hermes Agent 的内容是最清晰的产品/基础设施发布，对广大开发者具有相关性。

/r/LocalLlama + /r/localLLM 回顾

• 在MacAir上本地运行Google TurboQuant的Qwen模型 (活动量：433)：这篇帖子讨论了一项实验，将Google的TurboQuant压缩方法应用于llama.cpp，使得在标准MacBook Air（M4，16 GB）上运行Qwen 3.5-9B模型成为可能，并支持20000 tokens的上下文长度。这在以往在此类硬件上是不可行的，突显了TurboQuant在不依赖云API的情况下实现大模型本地执行的潜力。实验表明，即使是MacBook Air或Mac Mini这样的入门级设备也能处理大上下文，尽管存在一些速度限制。开源应用atomic.chat被提及为本地运行这些模型的资源。一位评论者指出，在基础版MacBook Air上无需交换就能处理20K上下文的壮举，表明许多先前依赖云API的应用现在可以在本地运行。另一位评论者询问TurboQuant如何集成到llama.cpp中，显示出对更广泛可访问性的兴趣。

Tatrions强调了在基础版16GB RAM的MacBook Air上无需交换就能运行20K上下文模型的惊人能力，这要归功于TurboQuant。这表明许多先前依赖云API的应用现在可以在本地执行，不过人们好奇在这种压缩级别下，与相同模型的标准Q4相比，质量下降了多少。

• M5_Maxxx对TurboQuant实现进行了详细审计，揭示它只是Jan.ai的轻微修改版本。主要变化包括重命名、UI调整和自定义的llama.cpp后端分支，但没有新的推理引擎或模型架构支持。96次提交大多涉及CI/构建流水线更改，表明除了原始Jan.ai功能外创新有限。
• AppealThink1733询问TurboQuant如何集成到llama.cpp中，表明对这项技术是否已得到这个流行开源项目支持的关注，这可能促进更广泛的采用和实验。

跳过90%的KV反量化工作 → 在32K上下文下解码速度提升22.8%（llama.cpp，TurboQuant） (活动量：744)：这篇帖子讨论了llama.cpp中TurboQuant实现用于KV缓存压缩的优化，通过跳过对注意力权重可忽略的位置进行反量化，显著提高了解码性能。这种方法利用了注意力稀疏性，在M5 Max上32K上下文长度下实现了+22.8%的解码速度提升，且不影响困惑度（PPL）。该方法涉及内核中约三行代码的简单修改，避免了复杂的优化如SIMD技巧或融合内核。结果在不同硬件上保持一致，包括M2 Pro，与标准q8_0 KV缓存相比，性能从~0.45x提升到~0.73x。实现和基准测试可在GitHub上找到，并有详细的技术文档。**评论者赞扬了该解决方案的简洁性和有效性，注意到创新性地利用注意力稀疏性跳过不必要的计算。人们好奇这种方法在更长上下文（如64K+）下的扩展性，并希望将此优化集成到主线的llama.cpp中。

• Specialist_Sun_7819强调了llama.cpp中TurboQuant的一项新颖优化，即跳过对输出影响不显著的token的90%键值反量化工作，在32K上下文长度下实现+22.8%的解码速度提升。这种方法利用了长上下文中可预测的注意力稀疏性，通过最小的代码更改（特别是内核中的三行代码）实现了显著的计算节省。评论者好奇这种方法在更长上下文（如64K）下的可扩展性，以及稀疏率是否会继续增加或趋于平稳。
• sean_hash将TurboQuant中的优化与Flash Attention中使用的技术进行了类比，指出缓存反量化输出而不是在每个解码步骤重新计算是类似的策略。这种方法有效地减少了冗余计算，通过重用先前计算的值来提升性能，这是高性能计算中常见的优化手段，旨在最小化不必要的处理开销。
• Pentium95表示有兴趣将此优化集成到主线的llama.cpp中，表明社区希望更广泛地采用这种技术。这暗示社区看到了这些性能改进的价值，并渴望看到它们在广泛使用的代码库中实现，从而可能带来更高效的模型和跨各种应用的更快推理时间。

Llama.cpp中TurboQuant的基准测试 (活动量：463)：这篇帖子讨论了TurboQuant的实现，这是Google的一种压缩技术，在llama.cpp框架中，特别是在使用Metal的Apple Silicon上。作者注意到性能显著下降，TPS比f16低50%，表明其设置可能存在潜在问题。他们还尝试在CUDA机器上运行内核，但遇到了输出质量差的问题，暗示方法存在错误。该技术被认为有利于在VRAM有限的消费级硬件上运行本地模型，可能允许在本地执行更复杂的任务。帖子引用了相关项目如MLX和VLLM的持续开发工作。评论者建议检查KLD来评估该方法的有效性，并表示希望看到像pp2048这样的性能指标，因为pp64的指示性不强。另一位评论者建议尝试RotorQuant进行比较。

• Velocita84指出基准测试中缺少Kullback-Leibler散度（KLD），这对于评估TurboQuant的有效性至关重要。KLD衡量一个概率分布与第二个预期概率分布的差异程度，缺少它可能意味着无法深入了解模型在TurboQuant压缩下的性能。
• CornerLimits认为使用pp64的基准测试对评估性能信息量不大，建议改用pp2048。pp指标指的是困惑度，这是语言模型中常见的衡量标准，表示概率分布预测样本的能力。更高的pp值可以提供更全面的模型性能视图。
• DinoAmino讨论了TurboQuant中数据压缩与准确性之间的权衡，指出虽然它允许更高的数据压缩且接近无损精度，但不会提高准确性。他们强调大多数大模型在较长上下文长度下都会经历准确性下降，这意味着TurboQuant的主要好处是能够在没有额外准确性损失的情况下使用更长的上下文。

RotorQuant：通过Clifford转子实现比TurboQuant快10-19倍的替代方案（参数减少44倍） (活动量：652)：RotorQuant引入了一种新颖的向量量化方法，利用Clifford代数，相比TurboQuant实现了10-19倍的速度提升，且参数减少了44倍。该方法用Clifford转子替换了d×d随机正交矩阵，将计算复杂度从16,384次FMA减少到约100次FMA（对于d=128）。这导致余弦相似度为0.990，而TurboQuant为0.991，表明性能几乎相同。该实现利用了融合CUDA内核和Metal着色器，在RTX PRO 4000和Apple M4上显著优于cuBLAS矩阵乘法。权衡涉及在随机单位向量上更高的合成MSE，但通过QJL校正，真实模型的注意力保真度得以保持。GitHub 论文 一个关键争论集中在RotorQuant和TurboQuant之间的理论差异上。虽然TurboQuant的全局随机旋转将能量分散到所有维度，但RotorQuant的3D块混合无法复制这一点，导致最大坐标幅度更高，低比特量化中的MSE更差。然而，RotorQuant在KV缓存分布中的实际性能得到认可，表明对于真实模型来说，这是一个有价值的速度/质量权衡。

• Juan_Valadez强调了RotorQuant相比TurboQuant的一个关键理论限制，指出TurboQuant的全局随机旋转（Haar）有效地将能量分散到所有维度，优化了标量量化。相比之下，RotorQuant在3D块内的混合限制了其实现相同能量分布的能力，这可能对低比特量化产生负面影响，特别是在像one-hot这样的最坏情况向量中。然而，RotorQuant在向量对抗性较低的KV缓存分布中可能仍然具有实际用途。
• Dany0将TurboQuant与图形编程中使用的技术进行了类比，特别引用了应用于模型权重的类似方法QuiP。尽管由于论文简短及其呈现方式而最初持怀疑态度，但Dany0承认RotorQuant的潜力，将其使用Clifford转子比作应用四元数而非欧拉角，通过将乘法减少到零来简化计算。
• sean_hash评论了Clifford代数在量化中的意外应用，指出这是几何代数向图形学以外领域交叉渗透的一个例子。这突显了传统上与其它领域相关的数学概念的创新使用，表明这些技术具有更广泛的适用性。

• GLM 5.1已发布（活跃度：1127）：图片宣布了Z.ai发布的GLM-5.1，重点突出了其在编码任务上相比之前版本的改进性能。图片中的图表显示，GLM-5.1在编码评估中获得了45.3分，超过了GLM-5的35.4分，但仍落后于Claude Opus 4.6的47.9分。这表明GLM-5.1的能力有了显著提升，很可能是由于其底层架构或训练数据的改进。评论者猜测GLM-5.1可能会发布开源权重，显示出对更广泛可访问性的期待。同时还有关于DS v4发布延迟的讨论，暗示在特定硬件（如Ascends）上进行训练可能面临挑战。

power97992推测DeepSpeed v4的发布可能存在延迟，认为这可能与在Ascend硬件上进行训练相关的问题有关。这突显了为不同硬件架构优化机器学习框架所面临的挑战，这些挑战可能会影响发布时间表。

zb-mrx注意到GLM 5.1的发布流程有所改进，与之前的GLM 5版本形成对比，后者并未在第一天就向所有人开放。这表明开发者可能已经解决了之前的物流或资源相关问题，比如GPU可用性，以确保更顺畅的发布。

jacek2023提到由于硬件限制（特别是72GB VRAM的限制），在本地运行GLM存在局限性。这强调了运行先进模型所需的硬件要求这一持续存在的挑战，对于许多没有高端GPU访问权限的用户来说，这可能是一个障碍。

• 双DGX Spark与Mac Studio M3 Ultra 512GB对比：本地运行Qwen3.5 397B的体验分享 (活动量：819)：这篇帖子对比了Mac Studio M3 Ultra 512GB和双DGX Spark配置在本地运行Qwen3.5 397B模型的性能表现。Mac Studio采用MLX 6位量化技术，生成速度达到30到40 tok/s，内存带宽约为800 GB/s，但存在预填充时间较慢的问题，并且需要自定义异步代理来处理工具调用。相比之下，双DGX Spark配置使用INT4 AutoRound量化，生成速度为27到28 tok/s，得益于CUDA张量核心，预填充和批量嵌入速度更快，但面临配置复杂性、内存带宽限制（每个节点约273 GB/s）和稳定性问题等挑战。作者将两种配置用于不同任务：Mac Studio用于推理，Spark用于RAG和嵌入，通过Tailscale进行通信。每种配置的成本约为10,000美元，与每月2,000美元的API费用相比，盈亏平衡点为10个月。评论中强调了Mac Studio 512GB的独特性，并批评了Nvidia对DGX的支持。还有关于Qwen3.5 397B与Claude性能对比的讨论，指出虽然Qwen3.5不如Claude的Opus先进，但性能接近。

Repoman444指出了Nvidia DGX系统的一个重大问题，认为Nvidia的支持不够理想。这可能会影响依赖及时有效支持来排查问题和优化高性能计算任务的用户，尤其是在运行像Qwen3.5 397B这样的大型模型时。

• sp4_dayz讨论了Qwen3.5 397B与Claude和Opus的性能对比，认为虽然Qwen3.5尚未达到Opus的水平，但已经相当接近。这意味着熟悉Claude的用户可能会觉得Qwen3.5略有不足，但在性能上仍是一个强有力的竞争者。
• Gringe8提出了一个关于比较方法的技术问题，质疑评估是否包含了提示词处理速度。这表明提示词处理速度是评估像Qwen3.5 397B这样的AI模型性能的关键因素，尤其是在比较DGX和Mac Studio M3 Ultra等不同硬件配置时。

如果你现在有约10,000美元预算用于本地大模型硬件，你会实际构建什么？ (活动量：201)：这篇帖子讨论了用约10,000美元预算构建本地硬件配置来运行大模型。用户的目标是运行至少30B参数，理想情况下达到70B参数的模型，用于超越简单聊天的任务，如多步骤工作流和工具调用，重点关注隐私保护和避免API成本。主要的技术争论围绕GPU选择展开：RTX 4090因其性能而被考虑，而二手A6000/A40** GPU则因其VRAM容量而受到关注。用户还考虑了Mac Studio (M3 Ultra)的统一内存优势，但对其在实际应用中与CUDA配置的性能对比存在疑问。帖子寻求关于如何平衡GPU、CPU、RAM和存储投资以实现最佳性能的建议，同时不牺牲速度或可靠性。评论者建议考虑RTX 6000 Blackwell或Mac Studio作为可行选择。一位评论者幽默地建议用这笔预算赚取利息并支付大模型订阅费用，强调了云解决方案的成本效益，尽管用户更倾向于本地配置。

• Blackdragon1400强调了本地大模型硬件至少需要256GB VRAM/统一内存的重要性，认为低于这个配置是不够的。他们推荐使用2x DGX Sparks，可以以约40t/s的速度运行Qwen3.5-122b-Int4-Autoround，突出了其相对于最先进模型的效率。
• MatthiasWM提到了苹果可能在6月的开发者大会上发布M5 Ultra芯片。他们建议在做出本地大模型硬件的重大投资之前等待这次发布，表明新芯片可能会带来显著改进。
• Blackdragon1400还建议优先考虑大容量RAM来处理大模型任务，警告不要仅仅满足于能够"塞进"较小内存配置的量化模型。这强调了需要强大的硬件来有效处理高要求的大模型工作负载。