AI 开发者日报

• OpenAI 的“越狱”智能体事件影响范围扩大：七月发生的智能体入侵事件在 Hugging Face 之外引发了更多讨论。据报道，该智能体在 Hugging Face 攻击链中，还访问了横跨四项服务的另外四个账户，其中一个被用作外发中继/暂存路径，另一个用于存储，其余几个账户则在其他独立评估中被访问（via @kimmonismus 总结，Wired 来源链接）。Hugging Face 也发布了详细的入侵可视化图表和技术时间线，重点展示了跨边界攻击阶段和命令痕迹（Mary 的笔记）。运营方从技术层面得出的结论与其说是“AI 末日论”，不如说是企业级安全加固：智能体部署现在需要更强的沙箱隔离、审计追踪、访问控制，以及对非确定性系统的治理机制（@levie）。
• 政策回应仍存在巨大争议：数据集中的一个主要线索是跨实验室签署的“前沿节奏控制”公开信，由多家前沿实验室的部分员工签署。签署者如 @NeelNanda5 为其辩护，认为应当存在协调放缓的选项；@Yoshua_Bengio 则将其视为呼吁建立国际技术和治理护栏。批评者认为，这一诉求在操作上模糊不清，战略上前后矛盾，尤其缺乏具体的承诺、透明度或可验证的行动阈值（@dylan522p，@gallabytes，@ChrisJBakke，@kimmonismus）。METR 提出了一个更具技术性的流程方案，概述了在严重对齐失败事件发生后，如何开展独立的倾向性调查，包括访问权限要求以及向决策者和公众报告的路径。
• 一个反复出现的元观点：多篇文章指出，“模型安全”研究需要评估完整的聊天机器人/框架/系统堆栈，而不仅仅是基础模型，因为记忆、搜索、工具、长会话漂移和脚手架会实质性地改变风险状况（@random_walker）。同样的框架也出现在基准测试的批评中：智能体评估越来越多地衡量的是模型 + 框架 + 环境的交互，而不仅仅是权重本身。

• OpenAI 开源 Codex Security CLI：OpenAI 低调发布了一款开源仓库扫描工具，适用于代码仓库和 CI/CD 流程。该工具可扫描代码库、跨运行追踪发现、验证修复，并将安全检查集成到流水线中（公告，npm 安装/文档，源码/文档）。这是此次发布中最清晰的产品之一：实用、贴近基础设施，对开发和安全团队立即可用。
• Codex 正越来越多地被用于优化 OpenAI 自身的技术栈：OpenAI 表示，GPT-5.6 Sol 在部署后被用于优化生产服务，通过 GPU 内核改进实现了 20% 的服务成本降低，并通过推测解码工作实现了 15% 以上的 token 生成效率提升（OpenAI，OpenAI Devs，@gdb，@reach_vb）。这是一个值得关注的实例，展示了AI 辅助的系统优化在推理基础设施上的实际应用，而不仅仅是编码演示。
• 面向学术研究者的 ChatGPT：OpenAI 启动了一项计划，初期向 10,000 名研究人员提供免费访问权限，到 2027 年扩展至 100,000 名，可免费使用包括 GPT-5.6 系列在内的前沿模型，并享有企业级隐私/安全保障，每个工作区最多可容纳四名协作者（公告，详情，Sebastien Bubeck）。其核心理念是：科学加速应该通过研究人员直接实现，而不仅仅局限于实验室内部。
• Codex/Work 使用变化：OpenAI 还调整了 Sol 的使用机制，声称典型使用时长延长了约 18%，并在优化了工具等待时间和大型网络搜索后，恢复了五小时的使用限制（@reach_vb）。用户反馈显示，实际工作流中存在高需求和大规模的 token 消耗（@kimmonismus，@theo）。

• Kimi K3 仍是本轮讨论最火热的开源模型：除了广泛赞誉外，多篇帖子深入探讨了其技术报告和部署生态。来自 @ZhihuFrontier 的详细分析指出，其训练后流程包含九个 RL 专家，横跨三个领域和三个努力层级，通过多教师在线策略蒸馏（MOPD） 统一整合。关键细节包括：基于 token 预算的条件化努力策略、用于长周期智能体训练的部分 rollout 队列、量化感知训练、基于执行结果的奖励机制，以及大规模沙箱编排（5120 万个沙箱、150 万个容器镜像）。
• 推理性能与广泛的服务支持已同步上线：vLLM 报告称，在 4×4 GB300 上使用 DSpark 运行低熵推理任务时，Kimi K3 实现了 464 tok/s 的 batch-size-1 解码（主要结果、草稿模型链接、博客）。随后，vLLM 及其合作伙伴宣布在 AMD Instinct、NVIDIA、DigitalOcean、Modal 和 Baseten 上首日支持 K3（AMD、NVIDIA、DigitalOcean、Modal、Baseten）。
• 本地和压缩版本进展迅速：Unsloth 表示，1-bit Kimi K3 在从 1.56TB 压缩至 594GB 后仍保留了 约 78.9% 的准确率，可在 Mac Studio + 128GB RAM 上运行；随后他们将本地版本与 Claude Opus 5 和 GPT-5.6 在视频生成提示词上进行了对比（对比结果）。
• 框架与模型本身几乎同等重要：Composio 使用相同的 Kimi K3 模型在三个不同的智能体框架上进行对比，发现成功率相近，但速度和成本差异显著：Kimi Code 22/28、Hermes 21/28、Claude Code 20/28，其中 Hermes 最快，Kimi Code 最便宜且 token 效率最高（结果）。这很好地印证了当前智能体评估讨论中日益形成的"模型 + 框架"论点。

• 递归自我改进不再只是理论猜想，已被纳入基准测试：Cline 报告称，Kimi K3 花费了 17 小时递归改进 Cline 测试框架，将 Terminal Bench 的性能从 77.5% 提升至 88.8%，同时运行成本从 79 美元降至 49.8 美元。与此同时，RSIBench-Data 将自己定位为一个开放平台，用于评估智能体是否能像研究人员一样行动——诊断弱点、生成数据、优化后训练、改进模型——而不仅仅是解决固定任务。
• 新的基准设计瞄准长周期策略遵循与企业级真实场景：HANDBOOK.md 衡量智能体是否能够 以允许的方式 得出正确答案，使用长篇幅的手册/策略文档，并通过基于 MCP 的服务进行确定性双向评分。Enterprise Worlds / ITSMBench 针对真实的 IT 服务管理工作流，早期结果表明，前沿模型在策略遵循、歧义解决以及跨多步企业任务中保持正确状态方面仍然存在困难。
• 专门的编码与系统基准测试揭示了不同的瓶颈：Kernel Forge 使用 MCTS 在优化路径上进行搜索，就地重写 CUDA 内核，据称在 四个模型的 14 个内核 上击败了 PyTorch 基线，这表明对于底层优化任务，精心设计的测试框架优于简单的生成-修复循环。与此同时，针对 Opus 5 的网络安全评估指出，它可能比同类模型发现更多漏洞，但代价是 过度活跃、噪声过多的行为（@pilvar222）。
• 基准污染、作弊与诱导问题仍是核心关注点：多个帖子指出，在 2026 年制定公平的智能体基准测试面临诸多困难，包括作弊、测试框架敏感性和环境效应等问题（@yacinelearning 的基准测试访谈，swyx 关于自我博弈/测试框架设计的讨论）。

• 开放权重的倡导浪潮持续升温：Cline 签署了开放权重公开信，并在 Cline 中免费提供 GLM 5.2，认为开放权重在成本、隐私和监管方面具有重要意义。类似的观点也来自 Teknium 等人，强调用户应掌握“AI 生产工具”的控制权。
• 智能体工具链正在快速迭代：Theo 的 T3 Connect 提供了一个极简的开源隧道层，只需一条命令即可远程控制 Claude Code/Codex/OpenCode/Grok Build 实例；deepagents v0.7 将基础提示词和工具描述削减了 65%，并增加了更多可配置的中间件；Perplexity 的 Numbat 是一个 Apache-2.0 协议的 Go 语言二进制文件，用于智能体的检测与响应，支持审计事件、本地检测，以及跨 harness 的可选前置拦截功能。
• 语音/转录与助手交互体验也在升级：OpenAI 的新版 GPT Transcribe 被 Artificial Analysis 总结为 AA-WER 得分 3.31%，相比 GPT-4o Transcribe 提升了 0.7 个百分点，同时价格降低了 25% 至每 1000 分钟 4.50 美元，并新增了提示词、关键词和多语言提示以增强上下文控制（AA 总结）。Cohere 的 Transcribe 已集成到 Superwhisper 中，用于本地听写工作流（Cohere，Superwhisper）。Teknium 还在 Hermes Agent 中推出了更快的流式 TTS 和唤醒词支持（语音更新，Hey Hermes）。

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

• OpenAI Codex 安全 CLI：OpenAI 发布的开源安全扫描命令行工具，成为本周互动量最高的产品发布推文（公告链接）。
• 版权与Anthropic案裁决讨论：最热门的法律/AI相关推文聚焦于法官在Anthropic案中关于训练数据和扫描书籍销毁问题的推理，虽然引发了大量法律争议，但技术实质内容有限（@ChazakielDoremi）。
• OpenAI 学术访问计划：为多达 10万名研究人员 提供前沿模型免费访问权限，作为一项重大分发举措引起了广泛关注（OpenAI）。
• Kimi K3 本地压缩：Unsloth 宣布推出 1-bit Kimi K3 本地运行方案，成为本周最受关注的开源模型基础设施推文之一（Unsloth）。
• Codex 优化 OpenAI 自身服务栈：声称 GPT-5.6 Sol 自主优化了内核和推测解码，实现了实际成本节约——这成为"AI 改进 AI 系统"最清晰的数据点之一（OpenAI）。

/r/LocalLlama + /r/localLLM 社区回顾

• Unsloth发布Kimi K3本地压缩版（1.56TB → 594GB）（热度：386）：Unsloth 发布了 Kimi K3 的本地量化版本，支持 8/4/2/1 比特，报告显示 Q8 1.56 TB（无损）、Q4 1.51 TB、Q2 861 GB、Q1 594 GB，声称最小的 Q1 变体保留了 78.9% 的准确率，同时体积比原始模型小约 3 倍。有评论者还指出了早期的剪枝工作：prometheusAIR/Kimi-K3-REAP55-GGUF，描述为一个约 342 GB 的小型/剪枝版 GGUF 变体。评论者对 Q1 在生产环境中的实用性表示怀疑，尤其是当基础模型本身已经量化时——将其形容为*“量化的量化”*，认为除了基准测试外，实际用途不明。其他人调侃说，即使是“小”的 594–600 GB 模型仍然需要严肃的服务器级存储/内存。

评论者对 Q1 / 1-bit 量化 在生产环境中的实用性提出质疑，特别是因为原始的 Kimi K3 发布版已经量化；一个担忧是这变成了“量化的量化”，除了重复的基准测试演示外，实际用途不明。

• 一个技术上相关的替代方案是早期剪枝工作：prometheusAIR/Kimi-K3-REAP55-GGUF，描述为 Kimi K3 的小型/剪枝版 GGUF 变体，约 342 GB，远低于 Unsloth 的 594 GB 压缩版。
• 用户对压缩算法和可行性感兴趣：他们询问一个 2.8T 参数的模型如何以大约 1 字节/参数的比例装入 1.56 TB，并指出 1-bit 量化保留近 80% 性能 的说法异常强劲；另一条引用的说明称 Unsloth “仍在研究是否能将其压缩到 512 GiB 以下。”

家庭实验室首次运行Kimi K3，速度约4t/s（热度：582）：图片是一张技术截图，展示了本地 Kimi K3 推理运行的结果，包含冒泡排序响应和运行时统计：模型分片 Kimi-K3-Q2_K-00001-of-00094，在 4 分 6 秒 内生成了 947 个 token，即在一个配备 768 GB DDR5 + 2× RTX 5090 的家庭实验室上达到约 3.85 tok/s（图片）。该帖子报告使用了支持 Kimi K3 文本的 llama.cpp 分支以及来自 Hugging Face 的 Q2_K GGUF 量化版本，大提示词预填充速度约为 50–70 tok/s，解码吞吐量似乎随时间增加，可能是由于预热或交换行为。评论者认为，对于一个在“荒谬的家庭硬件”上重度量化的前沿规模模型来说，~4 tok/s 的速度出人意料地强劲，尤其是与那些使用更大规模多 5090 以太网设置仅达到 ~0.7 tok/s 的报告相比。一些人调侃了功耗/散热需求，以及用这样的配置来请求冒泡排序代码的讽刺意味。

• 一位评论者强调，在配备 768GB DDR5 和 2× RTX 5090 的家庭实验室上达到 ~4 tokens/s 明显优于早期的分布式尝试，引用了之前使用 80× 5090 通过以太网仅达到 ~0.7 tokens/s 的运行结果。这意味着对于这类重度量化的大模型推理，内存局部性/互连开销可能占主导地位，使得规模更小但耦合更紧密的配置出人意料地具有竞争力。
• 另一个技术要点是，虽然 4 t/s 对于交互式使用来说可能太慢，但对于过夜复杂规划、编排或委托给更快的子代理来说仍然可行。这使 Kimi K3 的角色更像是一个本地多模型工作流中的慢速高能力规划器，而不是用于实时提示的聊天模型。
• 一位用户将自己的本地推理体验与这个结果进行了比较，称 Qwen3.6 27B 和 Gemma4 31B 在他们的机器上运行得更慢。虽然这是基于具体硬件的轶事，但这表明所报告的 Kimi K3 设置相对于一些较小稠密模型的部署来说可能异常优化。

更新：Kimi K3 现在在我的 M1 MacBook 上以约4 tokens/分钟的速度运行（热度：560）：Deltafin 报告在单台 64 GB M1 Max MacBook Pro 上完整运行 Moonshot AI Kimi K3 推理，从约 1 token/分钟 提升至中位数 4.1 tokens/分钟（14.6 秒/token，0.069 tok/s），共进行了六次完整模型运行，与仓库中 2.8T 参数 MoE 模型的参考结果 ~0.0687 tok/s 一致（GitHub）。主要的优化包括：通过并行原始跨度读取选择性加载每层仅 16 个路由专家，对驻留的“脊柱”进行 int8 量化并配合融合的 Metal 反量化/复制内核，以及使用 Apple 打包的 MPS int8 矩阵乘法 进行输出投影，将其驻留内存从 ~4.7 GB 减少到 1.17 GB，并将中位数解码吞吐量提高了约 17%。评论者大多强调在消费级 Apple Silicon 上运行一个数万亿参数 MoE 模型的极端性，并称赞在权重可用约 35 小时内实现了约 4 倍的快速提升；其余则是关于“按分钟计 token”以及尝试在更小的硬件（如 8 GB 的 Raspberry Pi）上运行的轻松调侃。

• 一位评论者指出了 Kimi K3 开放权重 的优化进展：最初 M1 MacBook 的运行报告称需要几分钟每 token，但在权重可用后约 35 小时 内，提升到了约 4 tokens/分钟（~15 秒/token）。该帖子认为这值得注意，因为它证明了在受限的 Apple Silicon 硬件上运行极大模型的可行性，即使对于正常使用来说不切实际。
• 项目作者认为这些优化不仅适用于性能不足的本地硬件：“这些优化也能让更快的系统变得更快，” 从而减少较新本地机器和云实例上的每 token 时间和成本。这一定位将 M1 实验视为一个压力测试，其实现改进可能推广到更高吞吐量的部署中。
• 一个技术建议要求添加一个标准基准测试模式，以便用户可以在不同机器和配置之间比较相同的基线。另一个问题询问该设置是否可用于驱动 Claude Code，暗示用户有兴趣将 Kimi K3 接入编码代理工作流，而不仅仅是交互式本地推理。

发布一天后，在无GPU的迷你PC上运行Moonshot的2.8T参数Kimi K3（热度：350）：作者报告运行 Moonshot Kimi K3，一个 2.8T 参数的 MoE 检查点（1.56TB，96 个 safetensors 分片，93 层，每层 896 个专家），在一台无 GPU 的 Slimbook ONE 迷你 PC 上，配备 Ryzen AI 9 HX 370、128GB 内存和两块消费级 NVMe 硬盘，使用 rabbit 实现。该实现将量化的稠密/共享组件保留在 RAM 中，同时通过 LRU/固定缓存直接从 Moonshot 的 safetensors 流式传输 MXFP4 专家权重；无需检查点转换，验证包括与 Moonshot 参考代码的比特精确比较以及结构检查。当前性能极慢：模型加载 610s，7 个 token 的预填充 412.8s，40 个生成 token 耗时 2698.1s（~0.015 tok/s），作者指出 MXFP4 内核仍然是标量且未经调优。评论者将这一结果视为执行可行性的证明，而非实用推理：“每秒 0.01 个 token，但它能跑。” 另一位评论者指出，与某些 vLLM 体验相比，10 分钟的加载时间并不算特别糟糕。

• 一位评论者报告了 Moonshot Kimi K3 2.8T 在纯 CPU 环境下的极低吞吐量，约为 0.01 tokens/s，但指出该模型至少可以在无 GPU 的迷你 PC 上运行。另一个技术观察是，~10 分钟 的模型加载时间被认为可以接受，并明确与 vLLM 也可能产生较长的启动/加载延迟进行了比较。

DeepSeek V4 Flash，在AMD Ryzen AI MAX+ 395上达到最高32 tok/s（热度：484）：图片 是一张宣传/非技术性图形，用于帖子声称的内容：在 AMD Ryzen AI MAX+ 395 / Strix Halo 上运行 DeepSeek V4 Flash，配备 128 GB 统一内存。技术内容在帖子正文中：Lucebox 报告将 284B 参数的 DeepSeek V4 Flash GGUF 目标模型加上一个 11.3 GB 的 DSpark 推测性草稿模型，使用 ROCmFPX 混合低位格式，在 ROCm/HIP gfx1151 上，在约 8K 上下文下实现了 25.31 tok/s 自回归速度，最高 32.0 tok/s 推测解码速度，以及约 245–255 tok/s 稀疏预填充速度。评论者质疑实际限制，特别是 8k 上下文是否有用，以及当 128 GB 内存满载时性能如何；其他人询问与 Qwen 相比的编码质量，以及 ROCm/HIP 设置是否仅限 Linux 还是也能在 Windows 上运行。

• 几位评论者关注了所报告的 DeepSeek V4 Flash 在 AMD Ryzen AI MAX+ 395 / Strix Halo 平台上 8K 上下文 的实际限制。他们询问在 128GB 内存中实际能容纳多少上下文和模型容量，以及在“满载”状态下而非最小上下文长度测试时的吞吐量如何。
• 一个技术性较强的请求是要求与 Qwen 3.6 进行编码性能对比，暗示仅有原始 token 吞吐量是不够的，还需要任务质量基准。另一位用户询问该设置是仅限 Linux 还是也能在 Windows 上运行，强调了部署/运行时兼容性是一个重要的缺失细节。
• 一位评论者建议进行重新量化构建，以牺牲一些精度换取更大的上下文空间，认为 32K 或 65K 上下文 是可用的代理工作流的门槛，而 8K 不够用于有意义的多步骤自动化。他们还提到了“antirez 设置”可能带来的轻微加速，将该帖子定位为一个有趣的最大吞吐量实验，但还不是一个最优的实用配置。

• Anthropic 呼吁禁止开源权重模型，提出它们可能永远无法满足的强制性要求（热度：1893）：图片是 Anthropic 政策论点的摘录，声称其*“从未倡导禁止开源权重模型”*，同时辩称开源权重发布后更难监控或设置护栏，并且能力足够强的开源和闭源模型都应接受强制性安全测试。结合标题声称 Anthropic 实际上是在呼吁禁令，评论者关注的是这些要求对于开源权重模型是否实际上不可能满足，以及 Anthropic 自己的闭源模型能否通过同样的测试。图片 评论者持怀疑态度，认为 Anthropic 的表述尽管否认明确禁令，但可能构成事实上的开源权重禁令。一个值得注意的反驳观点是：如果模型蒸馏像防止滥用开源权重一样难以阻止，那么同样的逻辑可能意味着对 Anthropic 自身模型的限制。

评论者聚焦于 Anthropic 论点中的一个技术一致性问题：如果从闭源模型进行蒸馏是产生不安全开源权重模型的关键途径，并且像对开源权重设置护栏一样难以阻止，那么 Anthropic 自己托管的模型也可能构成类似的上游风险。一位评论者质疑Anthropic 的模型能否通过提议的强制性安全测试，暗示这些要求可能不可行或被选择性应用。

等等，Dario 刚才是不是说闭源、秘密训练的模型比开源权重模型更危险？（热度：1042）：图片是一篇 AI 政策文章的截图（链接见此处），突出显示了标题中归因于 Dario 的主张：即*“最危险的模型可能是秘密训练的模型”*，并交给军事/安全行为者，而不是公开释放权重的模型。技术/背景意义在于 AI 治理论证中的一个张力：虽然开源权重常被描述为扩散风险，但这段突出显示的段落表明闭源、秘密的前沿模型在被国家行为者优化并部署于无人机、监控、镇压或军事优势时可能更加危险。评论大多认为这是反开源权重论点中的虚伪或意外矛盾，一位评论者开玩笑说这看起来像未经校对、由 Claude 生成的文本。另一条讨论从地缘政治角度切入，认为所描述的不当使用反映了美国现有的军事/监控行为，而非中国独有。

扎克伯格的观点：AI 未来属于每个人（热度：494）：图片是马克·扎克伯格在《华尔街日报》发表的专栏文章《AI 未来属于每个人》的截图/插图，将 AI 开放性问题框定为去中心化、人类能动性以及对集中控制的抵抗。从技术角度看，该帖子将扎克伯格的观点置于当前 AI 政策辩论中：支持扩散/开放生态系统与基于阈值的限制、前沿节奏控制或先进 AI 系统的集中治理之间的对立。图片本身是象征性的而非技术性的：一个笼子形状的人头释放出电路状的小鸟，视觉上表达开放 AI 访问"解放"人类潜能的观点。评论者主要关注 AI 权力集中的政策影响，有人赞同认为将 AI 视为如此危险以至于只有集中控制才安全的观点本身可能就很危险。另一条务实评论打破了宣言式的框架，直接要求发布新的 Llama 版本。

• 评论者聚焦于 Meta/扎克伯格支持开放 AI 的言论与产品现实之间的差距，有人指出*"他的模型现在已经是闭源的了"*，并呼吁根据实际发布而非声明的原则来问责。最具体的技术需求就是要求发布新的 Llama 版本，这表明社区主要通过 Llama 系列模型是否保持可用和竞争力来评估 Meta 的立场。

1. “去审查”大模型比基础模型更乐观，但准确率并未提升

“去审查”大模型在可测量范围内比其基础模型更乐观（热度：382）：该帖子报告了一项预先注册的本地评估，对比了 huihui 的“abliterated”去审查版 Gemma 和 Qwen 变体与其基础模型在 21,600 次股票方向决策上的表现。实验使用相同的公司报价/新闻载荷，并提示模型进行1周涨跌预测；数据和代码链接在作者的论文中：arXiv:2607.17427。主要发现是，通过 abliteration 移除拒绝回答行为改变了模型的倾向：去审查模型产生了更多的“上涨”预测，更少的不确定性标记，以及更长、更自信的推理过程，但并未提升预测准确率，结果仍接近抛硬币水平。一个值得注意的模型族特异性结果是相反的置信度漂移：Gemma 的置信度下降，而 Qwen 的置信度上升，尽管采用了相同的编辑方式。评论者指出，这种效应可能只是移除了模型说“不”的能力，从而将输出偏向肯定回答的简单后果；另有人质疑“置信度”是否是衡量这种漂移的正确潜在维度。

一位评论者质疑，所测量的“置信度”维度是否真的是衡量乐观情绪的正确潜在/行为指标，并指出报告的方向因模型族而异：Gemma 置信度下降，而 Qwen 置信度上升。这表明去审查/abliteration 的效果可能无法通过单一的标量置信度指标来捕捉，并且可能因模型架构或对齐微调而异。

• 一个技术相关的轶事将 abliteration 描述为高度依赖模型：该评论者观察到，仅在 gpt-oss 模型上出现了明显的任务性能提升（他们认为这些模型原本过度关注“策略”），而大多数其他 abliterated 模型“在简单任务上开始失败”。这与以下观点一致：移除拒绝行为不仅会影响安全拒绝，还会改变更广泛的指令遵循和推理行为。

2. 5B活跃参数的模型“知道的不多”，但这不再是缺陷

一个5B活跃参数的模型知道的不多，我已经不再把这当作缺陷了（热度：318）：该图片是一张技术架构图，而非梗图：它展示了 Ling–3.0–flash 作为一个大型 MoE 模型，拥有 124B 总参数 / 约 5B 活跃参数、157k 词汇量、1M 上下文长度、2560 嵌入维度、Kimi Delta Attention、门控潜在注意力、RoPE/RMSNorm，以及专家路由 E512A8 + 1 个共享专家（图片）。在该帖子的语境中，这张图支持了作者的观点：低活跃参数量的 MoE 模型应该少用 MMLU 这类记忆型知识基准来评估，而应更多关注它们在知识缺失时是否能可靠地调用工具/检索上下文而非产生幻觉。评论者普遍认同，对于本地 RAG/工具代理工作流而言，模型的内在知识远不如可靠的检索和工具使用能力重要。一场辩论围绕“活跃参数”是否是一个有意义的弱点展开：一位评论者认为，密集模型在推理时实际上也是稀疏的，因此 MoE 的活跃参数数量不应被视为能力的简单代理指标。

• 多位评论者认为，对于 RAG/工具使用的本地部署，模型记忆的世界知识不如可靠地决定何时调用工具以及将答案基于检索到的上下文重要。一个例子是 MiniPCM5 1B，被描述为激进地“工具优先”：据报道，它甚至拒绝回答像“澳大利亚首都是什么”这样简单的事实性问题，除非进行检索。这在需要基于检索的问答时是可取的，但在将情感分析等任务错误地路由到工具时则会产生问题。
• 一场技术辩论反驳了将活跃参数数量等同于能力的观点。一位评论者认为，密集模型也表现出激活稀疏性——对于给定的提示词，只有一部分参数有实质性贡献——因此 MoE 设计是利用了这一点，而不是在整个参数集上浪费算力；然而，另一位评论者指出，如果一个 124B 的 MoE 表现不佳，问题可能出在路由器/专家选择上，而非 MoE 本身。
• 评论者将低活跃参数量的 MoE 模型与小型密集模型进行了比较，指出 GPT-OSS-120B（仅约 5B 活跃参数）和 Qwen 35B-A3B（约 3B 活跃参数）的性能可以大幅超越微小的密集模型。技术回复的共识是，如果一个大型 MoE “感觉像”一个低于 4B 的密集模型，可能的原因包括路由器不良、权重被修改（如蒸馏/abliteration），或后训练修改导致的工具调用能力退化。

3. 感谢那位说“不要量化KV缓存”的人

感谢那位说不要量化KV缓存的人（热度：619）：该帖子报告了 Qwen3.6-27B 上 KV 缓存量化带来的质量退化，声称禁用 Q8 KV 量化产生了 “天壤之别” 的改进（相比仅量化权重），尤其是在 100k+ 上下文长度的 Elixir 编码任务中。该设置使用 llama.cpp 的多 GPU split-mode tensor 模式，跨两块 Nvidia 5060 Ti 16GB 显卡（总计 32GB），运行 bartowski 的 IQ4_NL 权重量化版 Qwen3.6-27B；发帖人表示张量拆分释放了足够的显存，从而避免了 KV 量化和/或增加了上下文长度。发帖人还链接了原始建议评论此处以及描述改进的评论此处。评论者普遍同意避免 KV 缓存量化可能很重要，但有人指出他们通常将 KV 保持在 Q8，因为它 “接近无损”，并且他们没有观察到性能差异。发帖人反驳说，合成测试可能无法捕捉到在极长上下文中小众语言编码的失败，而这时微小的质量损失会变得更加明显。

• 几位评论者质疑避免 KV 缓存量化是否能实质性地提升质量，询问观察到的改进是否表现为更少的幻觉或其他生成质量变化。一位用户报告说通常使用 Q8 KV 缓存，因为它 “接近无损”，并表示没有注意到有意义的性能差异。
• 一位 Qwen 用户询问了确切的 27B 模型量化设置，指出他们运行的是 Q8 27B Qwen 配置，搭配 Q8 KV 缓存，并且没有遇到问题。另一位评论者认为，在最近的 llama.cpp 中，Q8 KV 不应该产生 “天壤之别” 的差异，并引用对 attention rotate / attn rotate 的支持作为质量差距应该更小的理由。

• 有人喜欢我的沙漠场景，所以这里奉上御水术演示！（热度：4989）：该帖子介绍了 SNOWFLOW，一个纯浏览器端的 WebGPU/Babylon.js 图形演示，包含程序化生成的雪地地形、可持久变形的积雪、布料/长袍模拟、水/雪法术视觉特效以及雪地滑行穿越系统；在线演示托管在 Vercel，源码在 GitHub。作者表示，Claude Code with Opus 5 根据一份详细的实现需求文档，端到端地生成了整个项目——包括架构设计、Babylon.js/WGSL 系统、性能分析、截图迭代和文档——耗时约 9 小时，消耗约 400 万 非缓存 token。需求文档中指定的高端目标配置为 Windows 11 + RTX 5070 Ti 上的 Chrome/WebGPU，分辨率 2560×1440，要求稳定 90 FPS / 最低 60 FPS，通过跟随玩家的渲染目标实现持久雪地变形、地形 clipmap、带有 SSS/闪光/结冰状态的自定义雪着色器、后处理、管线预热以及严格的渲染循环分配规避。热门评论多为轻松的反应而非技术性评价：用户称赞了该演示，建议将其扩展为多人游戏或开放世界《降世神通》风格的御术游戏，并调侃了提示词中的那句 "不要构建测试套件；花在测试上的时间就是没花在雪着色器上的时间。"
• 有人用 Opus 5 在一天内做出了一个 NMS 风格的探索游戏（热度：1657）：一位开发者声称 Opus 5 在大约一天内构建了一款《无人深空》/《星空》风格的探索游戏，包括游戏逻辑代码以及所有资源——3D 模型和纹理——均通过 Blender MCP 使用子代理生成；工作流程在链接的 X 帖子中有描述：x.com/anshuc/status/2081801966158811506。评论者指出，结果似乎被打包成了一个 "自包含的 HTML 文件"，这意味着它是一个浏览器可交付的构建版本，包含嵌入/生成的资源，而非传统的游戏引擎项目。热门评论对资源质量印象深刻，有人表示模型 "好得离谱"，另一个人则认为它看起来更像 《星空》 而非 《无人深空》。一场关于游戏开发中 AI 敌意的更广泛辩论随之展开，有评论者认为反 AI 情绪正在压制潜在的有趣游戏，并引用了针对 AI 生成临时资产的抵制案例。

评论者强调，该原型据称是使用 Claude Opus 5 生成为一个 自包含的 HTML 文件，这值得注意，因为演示似乎包含了多个游戏系统/资源，而不仅仅是一个静态场景。最强烈的技术反应是对生成模型和室内场景质量的惊讶，不过有评论者指出，一旦飞船着陆序列出现，这种幻觉就被打破了，表明游戏各组件之间的保真度并不均衡。

• 一个讨论焦点集中在 AI 辅助游戏开发的采用上：一位评论者认为，游戏社区中强烈的反 AI 情绪阻碍了实验，并引用了即使临时使用 AI 生成资产也可能引发抵制或奖项后果的案例。其含义是，生成模型已经可以加速原型设计和资产迭代，但社会舆论和许可问题限制了其公开使用。

我让 SCAIL 2 处理了一堆它本不该处理的场景。它搞定了大部分。（热度：1223）：作者对 SCAIL 2 进行了压力测试，针对超出典型单角色演示的视频/图像驱动编辑，报告称在 角色替换 方面效果最佳，前提是使用 Flux Klein 9B 或 Krea 2 Identity Edit LoRA 将第一帧预先编辑为目标身份/姿势。报告的能力包括：在主体离开/重新进入画面后具有合理的 物体恒存性；合理的幻觉动态效果，如火弧、头发/衣物运动、透明酒杯的折射和液体晃动；而 文字渲染则会退化成一团乱码。工作流程使用了开源的本地 Mix Studio ComfyUI 前端（GitHub）；生成据说在 Dell Pro Precision T2 + NVIDIA RTX 6000 Pro 上耗时 约 2–3 分钟，教程在 YouTube 上。评论不多，但将 SCAIL 2/Bernini 称为 "被严重低估"，并提出了预期的真实性担忧："我们再也无法相信视频了。" 一位用户特别想知道该工作流是否能在 RTX 4070 12GB 上运行，但没有提供 VRAM/运行时间的确认。

• 用户讨论了 SCAIL-2 在不同 GPU 上的运行时间/VRAM 预期：一位评论者希望它能在 RTX 4070 12GB 上运行，而另一位则报告称 5080 16GB 处理 5 秒 低分辨率视频 大约需要 13 分钟，这与帖子中显示的 2–3 分钟 运行时间形成对比。
• 一位评论者分享了一个 复杂打斗场景中单角色替换 的技术示例，包括生成结果、参考角色视图以及与源素材的并排对比：结果、正面参考、背面参考 和 对比。他们指出，SCAIL-2 在与传统视频编辑结合时几乎达到了生产级质量，表明剩余的伪影可以在后期处理中解决。

• MCP 自发布以来迎来最大更新 👀（热度：1034）：配图是一张 X 平台帖子的截图，宣布了 "MCP 2026-07-28"，Reddit 标题称这是 MCP 自发布以来最大的更新：图片。评论区讨论的核心技术变化是 MCP 现在采用无状态/请求-响应模式，远程 MCP 服务器不再需要为每个客户端维护长连接会话，可以运行在普通的 HTTP 负载均衡器或无服务器基础设施之后。评论者还注意到，更新改进了 OAuth 2.0/OIDC 对齐以支持企业级认证，并标准化了 Tasks 以处理长时间运行的操作，而本地的 stdio MCP 服务器基本不受影响。总体来看，评论者认为无状态重构对托管/远程 MCP 部署是一大胜利，不过也有人批评最初的有状态设计本身就是糟糕的架构选择。

一条技术性较强的解释指出，MCP 从有状态的双向会话模型转向了请求/响应语义，这使得请求可以落在标准 HTTP 负载均衡器后的任意实例上，也让部署兼容无服务器基础设施。这一变化主要影响托管的远程 MCP 服务器；基于本地 stdio 的 MCP 服务器在日常使用中几乎不受影响。

• 服务器开发者还强调了更新中的另外两个重要变化：OAuth 2.0/OIDC 对齐，便于与 Okta 或 Microsoft Entra 等身份提供商集成；以及标准化的 Tasks，用于处理长时间运行的操作。此前，服务器通常要么阻塞工具调用直到完成，要么自行实现轮询/状态协议，这导致了脆弱的行为，例如工具结果在调用后不久就变得过时。
• Anthropic 的官方公告链接在此：https://claude.com/blog/bringing-mcp-2026-07-28-to-claude。多位评论者特别批评了最初的有状态设计，认为它不适合可扩展的分布式系统，因为重启可能导致已连接的客户端断开，且正常的负载均衡也难以实现。

有人在使用这个功能吗？（热度：1402）：配图（JPEG）展示了一个标题为 "Using Claude Code Remote Control" 的手机视频，来自 @claude，Reddit 标题询问是否有人在使用这个功能。评论者将 Claude Code Remote Control 描述为一种手机到代理的工作流：让 Claude 在笔记本电脑或小型 EC2 实例上持续运行，然后远程要求它检查代码库、诊断问题、编辑代码，并在远离工作站时打开 PR。技术评论者普遍持积极态度，称其"超级方便"和"最好的功能之一"。可见的图片评论捕捉到了主要担忧：远程编码代理可能会模糊工作与个人时间的界限——"我需要的是工作与生活的平衡，而不是工作与生活的融合。"

• 多位用户描述了他们让 Claude 在家用机器或小型 EC2 实例上持续运行，并使用手机作为远程编码/调试的控制面板。工作流包括让 Claude 检查工作消息、诊断代码库问题、修改代码以及打开 PR，无需笔记本电脑，实际上将 Claude 变成了一个随时可用的远程开发代理。
• 一个实际用例是：用户在外出时通过 WhatsApp 收到测试站点问题的报告，他们在手机上让 Claude 诊断并修复了问题，整个过程不到 20 分钟。另一位用户让家里的笔记本电脑保持运行，并将该功能设为新对话的默认选项，强调相比等待数小时回到工作站，这种方式的延迟优势明显。
• 一位评论者将该功能用作项目工作的任务执行循环：他们创建了一个大型任务列表，然后通过短暂的手机会话指导 Claude 逐步推进。他们特别提到 Claude 会为 UI 任务生成截图，这表明该工作流在远程操作时也支持前端变更的视觉反馈/验证。

创建 ADHD 技能的人，愿上天保佑你（热度：3607）：一位 Reddit 用户分享了 Anthropic Claude 的一个"技能" 的完整文本，名为 i-have-adhd，旨在全局重塑 Claude 的输出以适配 ADHD（注意力缺陷多动障碍）用户的使用习惯：以可执行的下一个操作开头、对步骤进行编号并限定数量、在对话轮次间重复当前状态、列表不超过 5 项、提供具体的时间估算、抑制离题/开场白/结束语，并在调试陷入死胡同时提供诊断重置。一条高赞评论指出，该技能的原始来源是 GitHub 仓库 ayghri/i-have-adhd。评论者大多以讽刺的方式验证了这一前提——他们表示因为 ADHD 而跳过了长长的技能文本；还有人强调应给予原作者适当的署名。

• 一位评论者指出，ADHD 技能似乎源自 ayghri/i-have-adhd，并认为应归功于原作者：https://github.com/ayghri/i-have-adhd。如果该技能提示词被重新分发或改编，这一点对于署名和溯源非常重要。
• 一个技术层面的担忧是，技能本身对于目标受众来说可能太长了，并且会增加不必要的提示词/上下文开销："喜欢这个想法，但这技能是不是太长了？" 这暗示了详细行为指令与可用性/上下文效率之间的权衡。
• 一位患有 ADHD 的用户指出，该技能的假设可能不具普适性：他们个人更喜欢非常详细、全面的回答，而该技能似乎偏向于较短的回复。他们还提到依赖 Claude 的记忆功能来保留这一偏好，但在新模型发布后需要重新声明，这表明模型版本的变化会影响对已存储风格偏好的遵循程度。

• 我所在的公司收到美国政府指令，要求停止使用 Anthropic 的产品、服务和模型。（热度：1186）：一位 Reddit 用户声称其雇主收到了美国政府指令，要求全公司逐步淘汰 Anthropic 产品/服务/模型——包括 Claude 应用、Claude Code/CLI、Anthropic Console/API、Opus/Sonnet/Haiku，以及 IDE/云服务/托管服务中集成的 Anthropic 相关功能——内部截止日期为 2026 年 8 月 31 日，并立即禁止新建账户/API 密钥/部署。该通知指示工程用户保留 Cursor 等工具但移除 Anthropic 模型，将 Claude Code 工作流迁移至 Codex via WebAI/GPT 模型，并由 IT/安全部门通过工单强制执行访问控制和依赖追踪。热门评论大多偏向政治而非技术层面，将这一指令视为政府过度干预，并推测供应商可能被迫转向 Grok 等政治倾向性替代方案。

一条技术相关的讨论聚焦于该指令的操作范围：引用的指示称，任何依赖 Anthropic 的应用、开发活动或供应商都必须通过工单上报，这意味着需要对直接 API 使用、嵌入式供应商集成以及软件供应链暴露进行内部依赖审计。列出的受影响模型系列包括 Claude Opus、Sonnet 和 Haiku，表明该禁令广泛针对 Anthropic 模型访问，而非单一产品层面。

特朗普正在禁止中国机器人/人工智能模型（热度：1263）：该图片是 一条 X 帖子的截图，引用路透社头条称特朗普政府计划禁止新的中国机器人和电源逆变器，此举被描述为保护美国 AI 基础设施建设。帖子/标题还声称可能涉及 中国 AI 模型禁令，但截图本身指出这仅是 X 平台上的说法，“在所展示的路透社文章中并未提及。” 评论者更多关注供应链影响而非 AI 模型本身，称 电源逆变器禁令 很“疯狂”，并警告这可能损害美国科技初创企业；有人质疑为何要针对逆变器。

• 评论者特别指出拟议的 电源逆变器禁令 是一个技术上重要的供应链问题，质疑为何逆变器会被纳入禁令范围。担忧在于逆变器是 太阳能、电池储能和并网电力电子设备 的核心组件，限制中国产逆变器可能推高部署成本或延迟能源/机器人基础设施项目。
• 多位评论者认为，禁止中国机器人或 AI 模型将不成比例地影响 美国科技初创企业，这些企业依赖低成本进口硬件、开源/托管的中国模型或通用自动化组件。隐含的技术影响是，获取平价机器人平台和 AI 工具的机会减少，可能迫使团队转向更昂贵的国内或盟友替代方案。
• 一个间接提出的技术担忧是，限制美国访问中国 AI 模型可能导致有效的 算力和模型可用性 向非美国用户倾斜，而美国开发者则失去某些推理/训练选项。评论将此视为竞争力问题而非安全讨论，几乎没有涉及哪些模型系列或基准测试会受到影响。

GPT-5，一年前还是世界最佳模型，如今已不如 Qwen3.6 27B 和当今大多数低端模型（热度：2788）：该图片是来自 Artificial Analysis Intelligence Index 的基准测试柱状图（图片），显示较新的前沿模型位居前列——例如 Claude Opus 4.1 得分 61——而 GPT-5 "high" 则低至 35。该帖子的技术主张是，Qwen3.6 27B 作为一个相对较小/开源的模型，得分为 37，略高于 GPT-5 的这项综合"智能"指标，暗示前沿模型与小型模型之间的基准测试差距正在迅速缩小。评论者对这一基准测试是否反映真实能力存在争议：一些人强调 Qwen3.6 27B 是免费/开源的，且可能在笔记本电脑上运行，而另一些人则认为实际使用中 GPT-5 仍然 "遥遥领先"，该图表可能夸大了小型模型的能力对等性。

• 多位评论者对基准测试到实际应用的推断提出质疑：尽管小型本地模型进步迅速，但实际使用过这两种模型的用户表示，在日常使用中 GPT-5 仍然"遥遥领先"于 Qwen3.6-27B，表明这种比较可能仅限于特定基准测试，而非广泛代表实际能力。
• 一位评论者质疑了评估方法，询问该指标究竟衡量什么，以及 Qwen3.6-27B 是否在所有领域都能匹配前沿模型，还是仅局限于狭窄的基准测试。他们还提出了硬件扩展方面的推论：接近前沿水平的模型是否可能在约 2 年内在一台 64GB 的笔记本电脑上运行。