AI 开发者日报

• NVIDIA 的开源周：NVIDIA 凭借 Cosmos 3 主导了开源模型的讨论。Cosmos 3 是一个面向物理 AI 的全模态世界模型开源家族，同时发布的还有 Nemotron 3 Ultra，一个 5500 亿参数的开源权重模型，多位评论者称其为目前美国最强的开源模型。Cosmos 3 被定位为全栈发布——包含权重、代码、数据集和微调方案——NVIDIA 还联合 Runway 等合作伙伴成立了 Cosmos 联盟，旨在为世界模型构建开放生态系统 @NVIDIAAI 生态系统背景，@runwayml 联盟公告，@kimmonismus Cosmos 讨论串，@ClementDelangue 谈 NVIDIA 在 Hugging Face 的影响力。
• Cosmos 3 的技术意义：抛开机器人领域的宏大叙事，更具体的细节在于，Cosmos 3 通过一个混合 Transformer 架构，将语言、图像、视频、音频和动作统一在一个模型中，该架构将自回归推理器与扩散生成器配对使用。Artificial Analysis 表示，Cosmos 3 在其文生图和图生视频排行榜上均位列开源权重模型第一，并指出其生成器使用结构化 JSON 提示词，既可以通过外部提示词上采样工具驱动，也可以由其自身的推理分支驱动。此外，NVIDIA 的软硬件协同推进还体现在对 OpenMDW 框架的采用，以及 fal 等平台上的合作伙伴生态系统集成 @ArtificialAnlys，@fal。
• Nemotron 3 Ultra 的反响：社区对 Nemotron 3 Ultra 的反响异常热烈，这对于一个全新发布的开源模型来说并不常见。评论者们既强调了其能力，也提到了服务特性，包括有说法称它已经在一些开源评测中登顶，并且在某些配置下可以达到 每秒 300+ token 的服务速度——远超 DeepSeek/Kimi 这类大型模型 @scaling01，@ctnzr，@caspar_br。还有一些技术讨论指出，Nemotron 看起来比 Kimi K2 / DeepSeek V4 等同类模型稀疏度更低——大约 ~10% 的激活率，而同类约为 ~3%——这可能会影响其经济性和行为表现 @eliebakouch。

• MiniMax M3 的发布是当日最重磅的模型发布：M3 被定位为一款开放权重的多模态智能体/编程模型，拥有 100万上下文、原生多模态能力，并在智能体基准测试中表现强劲。发布合作伙伴反复提及的核心数据包括：SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0% 以及 MCP Atlas 74.2% @MiniMax_AI，@PBDTokenRouter，@kimmonismus。多家基础设施供应商在发布当天即提供支持——包括 Novita、Vercel AI Gateway、Cloudflare AI Gateway、OpenClaude、Flowith 等——这表明生态系统的采用速度异常之快 @MiniMax_AI on Novita，@rauchg，@gitlawb。
• 基准测试与实际体验褒贬不一：M3 在前端生成、视觉/游戏任务以及性价比方面获得好评，并排演示展示了强大的一次性 UI/游戏输出能力，在 Next.js 智能体评测中也取得了亮眼的基准排名 @notjazii，@lostinlatencyX，@rauchg。但多位评测者也报告了 高 Token 消耗、冗长的自我检查循环，以及在长任务中偶尔出现的 需求漂移 问题，使得 M3 更像是一个“质量优先、效率其次”的模型 @ZhihuFrontier review，@teortaxesTex skepticism。
• Qwen3.7-Plus：阿里巴巴发布了 Qwen3.7-Plus，这是一款 多模态交互式混合智能体，统一了 GUI 和 CLI 操作、视觉推理、编程以及搜索增强的问答能力。该模型已通过阿里云百炼平台提供 API 访问，并迅速被集成到 Cline 等工具中 @Alibaba_Qwen launch，@cline。此次发布进一步印证了一个趋势：开放程度较高的亚洲实验室不再仅仅发布“聊天模型”，而是推出完整的 具备智能体能力的多模态系统。
• JetBrains Mellum2：JetBrains 发布了 Mellum2，这是一个 12B MoE 模型，拥有 25亿活跃参数，基于约 11T tokens 训练，并采用 RLVR 进行后训练，同时发布了 base / SFT / RL 检查点 以及一份技术报告 @nv_pavlichenko，@jetbrains。其目标定位尤其值得关注：为 路由、RAG、子智能体和 IDE 使用场景 提供 超低延迟推理，并且该模型已立即登陆 vLLM @vllm_project。这看起来更像是一个面向开发者工作流的“小而快的开放模型”策略，而非追逐基准测试的前沿发布。

• 技术栈正从模型调用转向Agent运行时：多项发布共同指向一个趋势——工程杠杆的核心已从模型本身转移到**"缰绳"（harness）上。Perplexity的"Search as Code" 是最典型的例子：模型不再进行迭代式的搜索工具调用，而是直接编写Python代码调用搜索SDK，从而实现自定义排序管道、索引上的map-reduce操作、批量处理、聚合分析，并大幅降低Token开销。Perplexity报告称，采用该架构后，其内部WANDR基准测试得分从0.152跃升至0.386** @perplexity_ai，@AravSrinivas。

• 托管Agent + 沙箱正成为标配：Google详细介绍了Gemini API中的托管Agent（Managed Agents），只需一次API调用即可启动一个Agent，它能够进行推理、编写/运行代码、管理文件，并在托管的Linux沙箱中运行 @_philschmid，@GoogleAIStudio。LangChain也推出了类似理念的Deep Agents、Context Hub以及LangSmith Sandboxes/Engine，强调持久化上下文、Agent生命周期工具和自动化故障排查 @LangChain，@hwchase17。

• 记忆仍然是缺失的原语：一个反复出现的抱怨是，即使上下文窗口再大，也无法解决跨会话记忆的问题。关于HydraDB的一篇讨论指出，"RAG + 手动上下文注入"被错误地冠以"记忆"之名，而真正的持久化会话知识仍然没有得到充分满足 @kimmonismus。相关研究线程提到了可复用的上下文管理策略，如AdaCoM，它通过强化学习训练一个独立的LLM，为冻结的Agent修剪/保留上下文 @dair_ai。

• 安全仍然是企业级Agent的关卡性问题：微软安全情报部门发布了一条重要警告，指出一次重大的npm供应链攻击影响了90多个redhat-cloud-services软件包，其中包括一种能够自我传播的蠕虫，窃取npm/GitHub/AWS/SSH凭据 @MsftSecIntel。与此同时，企业级Agent供应商强调，沙箱化、运行时隔离和安全栈集成是部署的先决条件，相关讨论包括NVIDIA OpenShell和LangChain的沙箱主题演讲 @shannholmberg，@LangChain。

• OpenAI 将 Codex 扩展到更多场景：OpenAI 宣布，前沿模型和 Codex 现已正式登陆 AWS / Amazon Bedrock，主要面向希望在现有 AWS 安全/合规工作流中使用 OpenAI 能力的企业用户 @OpenAI，@OpenAIDevs。OpenAI 还发布了 Codex Python SDK，支持线程、轮次、流式传输、断点续传、图像和沙箱控制 @reach_vb，同时增加了对基于 Bedrock 的 Codex 工作流的支持 @reach_vb on Bedrock config。
• Claude Code 遭遇真实运维事故：Anthropic 在修复一个 Bug 后，重置了 Pro 和 Max 用户的 5 小时和每周速率限制。该 Bug 导致部分 Opus 4.8 会话产生了过多的 并行子智能体/工具调用，意外消耗了大量使用额度 @ClaudeDevs，后续跟进。这提醒我们，编程智能体的产品质量越来越取决于编排行为，而不仅仅是模型本身的智商。
• 不同编程模型之间的行为差异仍然显著：开发者指出，在 ProgramBench 和 WeirdML 等基准测试中，GPT、Claude 和其他模型之间存在巨大的定性差异。Opus 有时更倾向于探索而非追求最高分数，或表现出特定于基准测试的奇怪行为 @OfirPress，@htihle。另一篇长文认为，较新的 Claude Opus 4.6–4.8 变体在非编程领域可能编造出看似合理但实际虚构的概念，这表明可能存在真实性/对齐性退化，而非普通的幻觉问题 @distributionat。

• NVIDIA 正在进军 PC 领域：最受关注的硬件发布是 RTX Spark，这是一款基于 Grace + Blackwell 架构的 NVIDIA/Microsoft "个人 AI 计算机"，配备高达 128GB 统一内存，并宣称达到 1 PFLOP FP4 算力。其关键战略意图在于：NVIDIA 不再仅仅销售加速器，而是提供一套端到端的本地 AI 系统，同时与 Apple Silicon、x86 PC 以及高通展开竞争 @kimmonismus, @swyx。
• 集群/网络更新：在数据中心方面，Lambda 宣布率先采用 NVIDIA Quantum-X InfiniBand Photonics Q3450-LD 交换机，通过共封装光学技术来降低大型 AI 集群的网络功耗和故障率 @LambdaAPI。OpenAI 还宣布了 Stargate Michigan 项目，这是一个规划中的 1GW 数据中心，采用闭环冷却系统，并配套了劳动力/教育方面的承诺 @OpenAINewsroom。
• 本地开源模型工具链正在快速进步：MLX-VLM v0.6.0 版本是本地推理/工具链方面的重要更新之一，新增了推测解码、Anthropic 风格和 responses 风格 API、工具调用、对多种多模态模型的支持，以及图像/音频功能，其明确目标是将 Apple 设备打造成"真正的本地 Agent 机器" @Prince_Canuma。这与不断增长的 DGX Spark + vLLM 实验相得益彰，后者用于本地 NVFP4 MoE 推理服务 @vllm_project。

以下是本周 AI 领域最受关注的技术动态精选：

• Anthropic 启动 IPO 进程：Anthropic 宣布已向美国证券交易委员会（SEC）秘密提交了 S-1 注册声明草案，这意味着该公司正式开启了首次公开募股（IPO）的大门，目前正等待审核结果 @AnthropicAI。

• Claude Code 使用事故：由于 Opus 4.8 的并行子代理/工具调用 bug 导致用户配额被过度消耗，Anthropic 已重置了用户的速率限制 @ClaudeDevs。

• Qwen3.7-Plus 发布：阿里巴巴推出了全新的多模态智能体模型，支持图形界面（GUI）/命令行（CLI）操作、代码编写以及视觉任务等多种场景 @Alibaba_Qwen。

• OpenAI 登陆 Amazon Bedrock：OpenAI 模型及其 Codex 代码生成工具现已通过 Amazon Bedrock 平台开放，方便企业集成到工作流中 @OpenAI。

• ARC-AGI-3 基准新突破：Claude Opus 4.8 在 ARC-AGI-3 测试中取得了新的最佳成绩（SOTA），得分 1.5%。虽然绝对值仍然很低，但相比此前已有显著提升 @arcprize。

1. 前沿模型发布与早期测试

• MiniMax M3 —— 编程与智能体前沿，百万上下文，多模态（热度：1090）：MiniMax M3 被宣布为一款开放权重的前沿模型，专注于编程与智能体能力，原生支持多模态/视觉，并采用 MiniMax 稀疏注意力 机制，可实现高达 1M token 的上下文窗口，且保证最低 512K token（MiniMax M3）。官方声称的长期智能体任务成果包括：12 小时内复现 ICLR 论文、Hopper FP8 GEMM CUDA/Triton 优化在 147 次迭代后达到 9.4× 加速，以及 PostTrainBench 排名第三（仅次于 Opus 4.7 和 GPT-5.5）。目前可通过 API/MiniMax Code 访问，HuggingFace/GitHub 权重及本地部署计划中。评论者们对廉价高效的视觉能力与长上下文智能体编程的结合持谨慎兴趣，但对其宣称的*“开放权重”*却迟迟未公开权重甚至参数量表示怀疑。一个技术争论点在于：这些结果究竟意味着模型远超 ~250B 参数规模、极端的基准测试优化，还是一次真正的开放权重突破。

评论者聚焦于缺失的发布细节：尽管声称是*“首个具备三种前沿能力的开放权重模型”*，用户仍无法找到 MiniMax M3 的实际权重、参数量或规模信息。一位评论者贴出了公告中的预览图（Reddit 图片），但该帖仍未确认模型规模或可下载的产物。

• 一个技术层面的实质性担忧是：广告中宣称的能力水平暗示了三种可能性之一：远超预期的模型规模、异常强大的基准测试优化，或是一次重大的开放权重突破。猜测集中在 MiniMax M3 的实际参数量是 ~250B 还是更大，以及其编程/智能体/多模态的宣称能否在权重和独立基准测试公布后得到验证。

• NVIDIA 发布 Nemotron 3 Ultra（热度：621）：该图片是一张 NVIDIA Nemotron 3 Ultra 的技术公告幻灯片，评论称其为 MoE 550B-A55 模型。该幻灯片将 Nemotron 3 Ultra 与包括 GLM 5.1、Kimi K2.6 和 Qwen3.5 在内的开放/开放权重竞争对手进行了对比，涵盖“前沿智能”基准类别，如智能体生产力、编程、指令遵循、知识工作和长上下文能力。评论者对此与其它开源/开放权重模型的对比持积极态度，但有人指出其“人工分析评分”为 48，略低于前沿模型水平，大致处于 MiniMax 2.7 的区间，并预计它可能成为最强的美国开放权重模型。

• NVIDIA Nemotron 3 Ultra 被确认为 MoE 550B-A55 模型，意味着总参数量约 550B，每个 token 激活约 55B 参数。这一架构细节是该帖中最具体的技术规格。

• 一位评论者引用了 Artificial Analysis 评分 48，将 Nemotron 3 Ultra 定位为“比前沿模型低一个档次”，大致处于 MiniMax 2.7 的区间，同时指出它可能是该指标下最强的 美国开放权重 模型。

• 分享的技术参考资料包括 NVIDIA 官方 Nemotron 3 Ultra Base 使用手册（GitHub：NVIDIA-NeMo/Nemotron），以及 LifeArchitect 模型对比表：lifearchitect.ai/models-table。一位评论者认为，与 Qwen3.5 的对比值得注意，因为 Nemotron 可能是 NVIDIA 最好的开放权重模型，但仍落后于多个非美国/开放模型。

• Stepfun 3.7 Flash 表现非常出色（热度：473）：该 GIF 是一个技术视觉演示，而非梗图：它展示了 Stepfun 3.7 Flash 对提示词 create a beautiful, relaxing flight simulator in a single html page 的输出，渲染出一个低多边形 3D 飞行场景，并带有 HUD 风格的速度/高度指示器。发帖者表示这是官方 Q4_X_S 量化版本，并声称该模型在美学上接近 GLM 5.1，在 3D 世界理解方面达到其约 80% 的水平，而参数量仅为 GLM 5.1 的约 25%，且内置视觉能力。评论者大多以比较和怀旧情绪回应，而非深入基准测试：有人提到了老式的 Excel 飞行模拟器，另有人则对 Qwen 3.7 Max / 27B 表示兴趣，并询问它是否优于 Qwen3.6 27B。

• 一位评论者通过引用 Qwen 3.7 Max 并期待未来发布 Qwen 3.7 27B 来展开模型对比，而另一位则询问 Stepfun 3.7 Flash 是否比 Qwen3.6-27B 更好。该帖附有 Qwen3.6-27B 参考的截图证据（图片），但未提供定量基准测试分数或可复现的评估细节。

戴尔确认搭载NVIDIA N1X的XPS笔记本（Computex亮相，本质上是面向消费者的Windows版DGX Spark GB10）

戴尔在Computex上确认了一款搭载NVIDIA N1X平台的XPS笔记本，这表明OEM厂商正在跟进NVIDIA的Arm/PC端战略。该帖子将其描述为面向消费者的Windows版DGX Spark/GB10，但提供的VideoCardz摘要并没有包含具体的规格参数、发布时间、定价或基准测试数据。评论区的讨论焦点集中在：这样的系统能否提供大容量统一内存配置——例如256GB——这将是其与传统独显笔记本相比的主要技术差异点。热门评论者对定价接近DGX Spark时的性价比表示怀疑，认为更便宜的RTX 5090笔记本在许多工作负载下可能更快。此外，对于这类面向AI/开发者的硬件，社区更倾向于一流的Linux支持而非Windows。

评论者认为统一内存容量是这类设备与传统GPU笔记本的主要技术差异点：128GB系统内存（其中约64GB可供GPU使用）对于本地大模型工作负载来说，比典型的笔记本显存限制要实用得多，部分人甚至希望看到256GB的统一内存配置。

• 如果XPS N1X的定价与NVIDIA DGX Spark相近，其性价比受到质疑：一位评论者认为，尽管统一内存较少，但GeForce RTX 5090笔记本在许多GPU工作负载下会更便宜、更快。
• 几个技术层面的担忧集中在软件和架构支持上：评论者更倾向于在本地AI工作流中使用一流的Linux支持而非Windows；质疑消费级系统是否会缺少DGX Spark所支持的NVFP4；以及新的SM119内核可能需要额外的底层优化工作。

我信了Reddit上陌生人的话，买了块中国特供的3080 20GB

图片是一张终端nvidia-smi截图，显示一块罕见的"NVIDIA GeForce RTX 3080"拥有20480 MiB显存，与一块RTX 3090（24576 MiB） 并列安装，证实了发帖人购买了一块改装版/中国市场的"3080 20GB"。技术上的亮点在于，这块显卡能被驱动识别并正常待机运行，但帖子没有提供任何基准测试、稳定性测试、散热表现、功耗数据，也没有确认在CUDA/ML工作负载下全部显存是否可靠。评论者的关注点集中在实际风险上：驱动兼容性、风扇/噪音表现、性能问题、使用寿命，以及这是否是目前最划算的每美元CUDA显存方案。整体氛围是谨慎的好奇，夹杂着对轻信Reddit陌生人推荐购买非标准显卡的焦虑。

• 评论者聚焦于中国改装版RTX 3080 20GB的实际验证，特别询问了驱动兼容性、声学表现，以及相比标准版是否存在性能回退或速度问题。
• 一个技术角度的讨论是性价比：考虑到其非主流的20GB显存配置，与主流RTX 3080/3090的定价相比，这张卡是否是每GB最便宜的CUDA显存选择。
• 有评论者指出，与RTX 3090并排安装时仅15°C的温差令人印象深刻，表明尽管是非标准的"中国特供"版本，其散热表现可能仍有竞争力。另一位用户提到自己订购了3风扇版本，暗示散热器设计可能是不同版本之间的重要差异因素。

• Opus 4.7 与 Opus 4.8 在 MineBench 上的差异（热度：1821）：MineBench 作者报告称，Claude Opus 4.8 在类似《我的世界》的 3D 方块放置基准测试（MineBench，仓库）上相比 Opus 4.7 有所改进。该测试使用 15 个建筑，花费 $41.52，平均推理时间为 24.8 分钟 / 1,487 秒。尽管 API 定价未变，但 Opus 4.8 比 4.7 更便宜，原因是其 CoT“思考”时间更短/更精简，同时生成了主观上更好的建筑——据称接近 GPT 5.5 的质量，但一致性较差。运行过程中因无效方块调色板幻觉或格式错误的 JSON 而需要 5 次重试；作者指出这对 Claude 来说很常见，但自适应思考似乎在耗尽输出 token 之前更不容易出现问题（发布说明）。评论大多是非技术性的赞赏；一位评论者提供了另一个 Opus 4.6 与 4.7 的对比链接，另一位开玩笑说“骑士看起来不再像 Bender 了。”

一位评论者链接了之前的 Opus 4.6 与 4.7 MineBench 对比以提供纵向参考：reddit.com/r/singularity/comments/1sofehv/differences_between_opus_46_and_opus_47_on。这为评估 4.8 的变化相对于之前 4.6→4.7 的步骤是否为增量改进提供了参考点。

• 一个技术建议是增加一个 “预算模式”，让每个模型使用 相同数量的方块。这将通过标准化可用的构建资源（而不仅仅是比较无约束的输出）使 MineBench 对比更加可控。
• 另一位评论者提议建立一个专门网站，用于追踪 同一提示词下模型随时间的演进。这将把单个 MineBench 帖子转变为可重复的纵向基准测试，使跨模型版本的可视化/空间构建质量对比更加容易。

Karpathy 的 CLAUDE.md 刚刚突破 22 万 GitHub 星标。以下是它有效的原因。（热度：1462）：该帖子认为，一个极简的 CLAUDE.md/Claude Code 项目指令文件——归功于 Forrest Chang 对 Andrej Karpathy 指导的实现——之所以流行，是因为它缓解了常见的智能体编码失败模式：冷启动时缺乏项目记忆、未经验证的假设、不必要的重构以及过度自信的执行。其核心规则是：先询问再假设、实现最简单的可行方案、避免无关的代码更改、明确标记不确定性；作者声称这在涉及 Magic Hour/Kling 风格集成的有状态 API 密集型项目（如视频生成管线）中尤其有用。评论者意见不一：有人认为这些规则只在早期有用，与更自动化的“工具工程”工作流相比会变得太慢；另有人警告说，硬编码的个性覆盖可能会与不断演进的 Claude Code/模型行为产生冲突，应将其限定在会话或项目范围内，而非全局应用。

• 几位评论者认为，Karpathy 风格的 CLAUDE.md 规则主要对从“普通编码”过渡到 Claude Code 的用户有用，但一旦用户构建了更高级的 工具工程 工作流，这些规则就会变得低效。技术上的担忧是，重复的确认/检查点提示会拖慢迭代速度，有经验的用户可能更倾向于自动化模式，让他们可以“发出查询”而无需反复批准相同的决策。
• 一个实质性的批评集中在硬编码的个性或工作流覆盖在 Claude Code 版本变更时的脆弱性上。一位评论者指出，新的模型版本和工具更新可能会颠覆之前的假设——例如，因为旧模型“问的问题不够多”而编写的提示词，在新模型问得太多时可能会适得其反——因此他们建议将此类规则限制在会话或项目级别，而不是作为全局行为覆盖。
• 另一个技术观点是，流行的 CLAUDE.md 文件鼓励的许多行为可能已经在 Claude Code 的工具/系统提示词中实现了，评论者称这在之前的源代码泄露中可见。如果属实，在用户级文件中重复这些指令可能边际效果有限，更像是安慰剂，或者作为 Anthropic 现有 RLHF 和工具设计之上的一个弱引导层。

速率限制重置（热度：918）：图片 是 ClaudeDevs / X.com 公告的截图，称 Claude Pro 和 Max 的 5 小时和每周速率限制已重置，原因是 Anthropic 修复了一个 bug，该 bug 导致某些 Claude Code 会话生成了过多的并行子智能体，迅速消耗了用户配额。背景表明该问题导致了失控的工具调用或智能体循环，一位评论者报告了 Opus 4.8 子智能体，另一位表示他们的 Max 计划会话限制被消耗了两次，达到了每周限制的 70%+。评论者分为两派：一派认为未事先通知的重置令人困惑或不负责任，另一派（受影响的用户）则认为这是对周末 Claude Code 行为异常的一种适当或慷慨的补救措施。

• 用户推断重置与 “过多的并行子智能体” 行为有关，一位评论者分享了截图并指出涉及的智能体 全部是 Opus 4.8：https://preview.redd.it/gye31dlekp4h1.png?width=348&format=png&auto=webp&s=bd740cb1239c5dbc12a5fedd3957ec197d47c8ee。讨论的技术含义是，并行智能体执行会迅速放大对速率/会话限制的使用，尤其是在同时启动多个高端模型实例时。
• 一位用户报告称，无休止的工具调用循环 在一个周末内两次消耗了他们 Max 计划 的整个会话限制，并将他们推至 每周限制的 70% 以上，这表明存在一种故障模式，即智能体/工具编排可以在没有实质性进展的情况下消耗配额。另一位用户表示，在意外重置之前，他们的 每周使用量已达到 96%，这表明重置对接近硬性每周上限的用户产生了实质性影响。