AI 开发者日报

• Google 快速迭代 Flash 系列：Google 在 3.6 Flash 发布仅三周后便推出了 Gemini 3.7 Flash，将其定位为面向编码、Web 开发、知识工作和智能体工作流的新主力模型。发布公告强调其在编码能力和自主性基准上实现了实质性提升，同时推出限时 50% 折扣（持续至年底）：每 100 万输入/输出 token 仅需 $0.75 / $3.75，之后将恢复至 $1.50 / $7.50。公布的性能提升数据包括 DeepSWE 65.3% vs 49.0%、FrontierCode 43.6% vs 34.4%、AutomationBench 30.4% vs 17.0%，以及 Code Arena Elo 1588 vs 1506/1538（视对比上下文而定）（Google、@GoogleDeepMind、@OfficialLoganK、@_philschmid、@koraykv）。
• 生态即刻铺开：3.7 Flash 同步登陆 Gemini API、AI Studio、Android Studio、Antigravity、Gemini Enterprise、Managed Agents、Gemini Spark 等平台，并迅速渗透到外部工具链中，包括 Cline、Devin、VS Code Agents 及其他编码工具栈（GoogleAIStudio、GeminiApp、code、cognition、cline）。
• 独立及半独立基准测试广泛印证了性能跃升：Artificial Analysis 将 Gemini 3.7 Flash（高配） 的智能指数评为 56 分，较 3.6 Flash 提升 4 分，输出速度约 340 token/秒，支持 100 万 token 上下文，同时在智能-时间和智能-成本两条帕累托前沿曲线上均占据有利位置。Arena 排名同样同步更新，将其推升至 WebDev Code Arena 第 8 名、Text Arena 第 9 名，并在 Agent Arena 中大幅上升（Arena、Arena text、Arena agent）。实践者还指出，该模型在工具循环中表现出更好的"纪律性"：更多的探索、更多的测试执行、更少的无效回合（@_philschmid）。

• DeepSeek Harness 成为当日讨论度最高的基础设施发布：DeepSeek 以 MIT 许可证开源了 DeepSeek Harness，目前为开发者预览版（@tianyi）。技术圈最强烈的反响并非聚焦于基准测试分数，而是集中在架构层面：多种 harness "模式"、可组合插件、可视化轨迹、支持 KV-cache 感知的追加式历史语义，以及该项目本身大量借助 agents/Codex 构建的证据（@eliebakouch、后续讨论、@bookwormengr）。一个反复出现的解读是：DeepSeek 将 harness 视为用于递归改进的 OS/运行时基座，而非仅仅是 Claude Code 的克隆（@0xLogicrw、@teortaxesTex）。
• Arcee 的 NAC 拓宽了设计空间：Arcee 以 Apache 2.0 许可证开源了 NAC，将其描述为一个用于长时、异步、无人值守工作的内部 harness——在过去三个月中，它已经支撑了其预训练、后训练和数据管线中相当大比例的代码提交（@latkins、仓库）。团队成员描述了使用 NAC 的各种场景，从照看实验到跨仓库工程再到自动研究型任务，通常通过手机编排，或通过 MCP 从 Codex/Claude 委派（@stochasticchasm、@code_star、@fujikanaeda）。
• 托管式与桌面端 harness 持续向生产工作流收敛：Cursor 宣布了 builds 功能，使云端 agent 启动速度快 3 倍，可故障切换到最后一个良好构建，并提升了长时自主工作的韧性与可调试性（Cursor）。LangChain 近期关于"托管深度 agents"的表述同样将生产级 agent 定义为以文件定义的 harness，具备调度、记忆、Slack 集成和受治理的运行时语义，而非临时拼凑的聊天机器人（@hwchase17、@bromann、@caspar_br）。
• Nous 持续将 Hermes 扩展为可编程的 agent 外壳：Nous 大幅扩展了 Hermes Agent 的插件面，随后加入了实时子 agent 操控/转录功能，以及 Bot 模式——在该模式下，配置文件可变成具名的 bot，拥有各自的聊天、例程、记忆、SOUL.md 和 bot 间消息传递（@Teknium、实时转录控制、bot 模式）。

• OpenAI 与 Cerebras 联合推出 GPT-5.6 Sol "Ultrafast" 模式：OpenAI 预览了由 Cerebras 驱动的 GPT-5.6 Sol 的 Ultrafast 模式，速度高达 750 tokens/秒，比标准模式快 14 倍，初期面向部分精选 API 客户开放。官方点名的应用场景包括低延迟的语音、客服、电商、编程、金融和安全工作流（OpenAI、详情、Cerebras）。这引发了更广泛的讨论：工具延迟而非模型延迟，即将成为智能体（agentic）系统中的瓶颈（@random_walker）。
• 开源推理工作同步跟进：Red Hat AI 发布了 DSpark，一个面向 Kimi-K3 的投机解码器，声称解码速度提升约 4 倍，在数学推理任务上从约 110 tok/s/用户 提升至 ~435 tok/s/用户，负载下吞吐量提升约 3.5 倍，并通过跨草稿层的滑动窗口注意力机制，在 20K 上下文下保持稳定的接受率（@RedHat_AI）。
• 内核工作日趋专业化：Prime Intellect 发布了 Prime Flash MoE，一套针对 MoE 推理优化的 Blackwell CUDA 内核，融合了路由感知的 GEMM、SwiGLU、量化和归约操作，并在 B200 上对 BF16 和 MXFP8 两条路径进行了基准测试（Prime Intellect）。其意义不言而喻：随着各家实验室不断推出更便宜的 MoE 端点，基础设施团队正在其下的服务栈上展开激烈竞争。

• 自定义基准测试基础设施正在成为一个产品品类：Artificial Analysis 推出了 Optima，这是一个用于在内部工作负载上构建和运行自定义基准测试的平台，支持上传数据集、来自 Arize/Braintrust/Langfuse 等工具的智能体追踪记录，或通过自然语言描述生成基准测试。它可以追踪质量、每任务成本、每任务耗时，并支持类似 AA 公开基准测试的成对评判机制（Artificial Analysis）。其核心卖点是：企业知道自己需要自定义评测，但真正能做好这件事的寥寥无几（@grmcameron）。
• Vals 完成 4000 万美元 A 轮融资并扩展基准测试覆盖范围：Vals 宣布完成4000 万美元 A 轮融资，估值达 4 亿美元，同时推出了 Vals Smith（可从任意 GitHub 仓库构建自定义编码基准测试）、新的 RSI 指数（用于衡量 AI 研发能力）以及用于网络安全的 ReverseEngBench（Vals AI，RSI 评论）。其核心论点虽不新鲜但日益重要：模型实验室不应成为唯一给自己系统打分的机构。
• 多篇论文深入探讨了智能体评测的失败模式：值得关注的摘要包括与微软相关的研究，该研究认为技能库可能反而会损害智能体，将 307 次失败归因于加载的技能，其中包括 125 次功能性失败和 182 次效率退化（@omarsar0）；另一篇论文表明，上下文压缩器仅能保留 17% 的持久会话约束，除非辅以专门的提取器（DAIR.AI）；还有一篇论文认为，排行榜的方差主要由智能体与任务的交互主导，而非稳定的"智能体质量"，在多个基准测试中智能体的主效应不足 3%（DAIR.AI）。

• MiniMax 迎来强势开源日：MiniMax-Music3 以开放权重音乐模型的身份正式发布；相关帖子将其描述为 8B LLM + 2.7B DiT 的组合，可将提示词和歌词转化为完整歌曲，并可通过 diffusers/ComfyUI/Hugging Face Spaces 在消费级硬件上运行（MiniMax AI、@multimodalart）。视频方面，MiniMax-H3 在 Video Edit Arena 综合排名及开源模型排名中均位列第一，获得 1390 分，据报领先次优系统 +32 分（Arena、MiniMax）。
• Meta 的本地智能体布局持续扩展：Meta 的 Muse Glimmer 30B 作为 Apache 2.0 许可的开放权重智能体模型持续受到关注，可在本地运行；Unsloth 新增了免费微调笔记本和 GRPO RL 支持，宣称训练速度提升 1.5 倍、显存占用减少 50%，并可在 24GB 显存 的硬件上进行本地训练（Unsloth、Ollama）。
• Sakana Chat 扩展了实用的代码执行体验：Sakana 更新了 Sakana Chat——由 Fugu 和 Namazu 驱动——新增代码执行支持，无需登录且完全免费，可实现日语交互式应用/游戏/工具生成，以及电子表格和商业分析工作流（Sakana AI Labs、用例）。

• OpenAI 发布最快的旗舰级推理服务：GPT-5.6 Sol Ultrafast，最高可达 750 tok/s，实现 14 倍加速，由 Cerebras 提供算力支持（OpenAI）。
• Google 主力模型大幅升级：Gemini 3.7 Flash 正式上线，在编码和智能体能力上表现强劲，价格仅为 原版 3.6 Flash 的一半（@OfficialLoganK，Google）。
• OpenAI 桌面端记忆与上下文扩展：Computer History 功能让 ChatGPT/Codex 可选择性地将应用和网页活动作为上下文使用，并配备时间线视图和用户控制选项（OpenAI，OpenAIDevs）。
• DeepSeek 智能体运行时正式开源：DeepSeek Harness 以 MIT 许可证开源，引发了关于 harness 作为长期运行和自改进智能体基座的广泛讨论（@tianyi）。
• Hermes Agent 持续深耕多智能体交互体验：Nous 推出 Bot Mode，可将智能体档案转化为具有固定例程和智能体间消息通信的持久化命名机器人（@Teknium）。

• Qwen3.8-2.4T-A95B 正式发布（热度：2345）：Qwen3.8-2.4T-A95B 作为一个超大规模的稀疏/MoE 风格模型被正式发布：从命名来看，总参数量约为 2.4T，而每个 token 实际激活的参数约为 95B。在 bf16 精度下，存储全部权重需要约 4.8–5 TB 的内存/磁盘空间，这意味着尽管激活参数数量小得多，但完整的本地推理对于典型的家庭实验室来说仍然不切实际。热门评论主要聚焦于可部署性：有人开玩笑说这"终于"是一个可以本地运行的模型，而其他人则指出 5 TB bf16 的存储需求甚至超出了极端家庭实验室的配置；一个反复出现的观点是，只有 95B 激活参数的部分看起来才可能本地运行，而非完整模型。

技术讨论集中在模型的部署占用空间上：一位评论者指出，bf16 格式的检查点大约需要 5 TB，即使对于高端家庭实验室来说，本地推理也不切实际。另一位评论者指出了 MoE 风格模型中总参数与激活参数之间的区别，开玩笑说他们只能运行激活的 A95B 部分，这意味着每个 token 的计算量可能接近 95B 激活参数，但存储仍然需要按完整的 2.4T 参数模型来扩展。

Qwen 3.8 在 Hugging Face 上发布（热度：490）：Qwen 3.8 据报道已在 Hugging Face 上发布，评论者特别关注 27B 变体，并注意到还有一个更大的 95B 激活参数 配置。提出的主要技术问题是可部署性：即使采用激进的量化方案（如 Q1），一个 95B 激活参数的模型在消费级硬件上仍然不切实际或极其缓慢，而拥有 RTX 3090 等 GPU 的用户则在期待更小的 27B 版本发布。评论者对 Qwen"承诺"并"兑现"表示肯定，但明显对 95B 激活参数 模型能否在本地使用持怀疑态度，除非是在高度受限、极慢的环境中。

• 用户指出，这次发布似乎包含一个非常大的 95B 激活参数 模型，一位评论者认为，即使采用 REAP 风格剪枝/量化 和极端的 Q1 量化 等激进方法，由于激活参数数量庞大，推理速度仍然会慢得不切实际。
• 多条评论聚焦于 Hugging Face 上预期的 27B Qwen 3.8 变体，用户特别期待在 RTX 3090 等消费级硬件上运行它，这暗示了人们对较小的检查点能否在 24GB 显存级别的 GPU 上适配并表现良好感兴趣。

你打算如何在本地运行 Qwen3.8-2.4T-A95B？（热度：608）：该帖子询问爱好者们是否以及如何能在本地运行 Qwen3.8-2.4T-A95B，并将其与此前的大型本地推理目标（如 Llama-70B、Mistral Large、DeepSeek V2/V3 和 Kimi K3）并列讨论。帖子中没有提供具体的部署方案、硬件拓扑、量化策略或推理栈；热门评论中唯一半技术性的估算表明，本地执行的吞吐量大约为 0.003 tokens/s，低得不切实际。热门评论大多持悲观/调侃态度，暗示实际的本地推理需要极端的资本支出——大约"$10万"级别——或者不可能实现的内存需求，而非现实的消费级配置。

• 评论者对 Qwen3.8-2.4T-A95B 能否在本地实际运行持怀疑态度，暗示一个数万亿参数的 MoE 规模模型的内存/计算需求将远超消费级硬件；有人开玩笑地估算它大约只能以 0.003 tokens/s 的速度运行，强调了在没有数据中心级 GPU 的情况下预期的严重推理瓶颈。
• 一个技术相关的关注点是采用/验证：一位评论者指出 Hugging Face 上的上传下载量不足 1000 次且未进入趋势榜，认为由于尝试加载或基准测试的用户太少，社区可能缺乏对发布产物是否可用或性能如何的实际验证。

• DeepSeek：我们今天发布 DeepSeek-V4-Pro！（热度：643）：DeepSeek 通过 X 宣布推出 DeepSeek-V4-Pro，评论者注意到同时发布了新的 API 定价表，并在 Hugging Face 上公开了模型权重：deepseek-ai/DeepSeek-V4-Pro-0813。主要的技术后续是，该模型似乎既可用于托管 API 调用，也支持本地/自托管推理，但 API 成本结构的变化足以影响工作负载的经济性。评论者对定价变化持负面态度：有人认为涨价消除了 DeepSeek 此前的优势，因为该模型本来就*"token 消耗大且速度稍慢"*，只是因为价格低廉才可接受，这使得本地部署更具吸引力。

DeepSeek-V4-Pro 的权重据报道已在 Hugging Face 上发布，地址为 deepseek-ai/DeepSeek-V4-Pro-0813，讨论焦点从 API 定价转向了第三方推理提供商是否能在有需求的情况下经济地托管该模型。

• 多位评论者关注 API 经济性：有人指出 DeepSeek 此前虽然*"token 消耗大且速度稍慢"*但可以接受，因为它便宜，而新定价消除了这一优势，可能将用户推回本地推理或转向其他提供商。
• 一位早期用户对 DeepSeek 声称与 Kimi 3 持平的说法提出质疑，认为 DeepSeek-V4-Pro 在知识深度以及长时间、免干预的扩展上下文项目工作能力方面无法与 Kimi 匹敌。

deepseek-ai/DeepSeek-V4-Pro-0813 · Hugging Face（热度：594）：DeepSeek 短暂在 Hugging Face 上发布了 deepseek-ai/DeepSeek-V4-Pro-0813，评论者指出对于一个 1.7T 参数的模型而言，其报告的基准测试成绩异常强劲，相比之下 Kimi 的模型为 2.8T 参数；有人特别指出 DeepSWE 从 V4-Pro Preview 的 12.8 跃升至 62.7，据报道超过了 GLM-5.2 和 Opus-4.8。该仓库一度返回 404/私有状态，显然是由于打包/配置问题：config.json 据称声明了 43 个隐藏层（类似"flash"变体），而下载的权重分片包含 61 层，这表明该版本可能被撤回修正后重新发布。评论者对速度和基准提升印象深刻，但也有人敦促谨慎，因为最初的 Hugging Face 产物似乎内部不一致，可能需要修复。

• 一位评论者指出，DeepSeek-V4-Pro-0813 作为一个 1.7T 参数的模型，相比 Kimi 的 2.8T 模型表现异常强劲，并引用了相对于 V4-Pro Preview 的大幅基准提升：DeepSWE 12.8 → 62.7，据报道超越了 GLM-5.2 和 Opus-4.8。
• 多位用户观察到 Hugging Face 模型短暂返回 404，一种技术解释是 DeepSeek 可能因 config.json 问题而撤回：配置据称列出了 43 个隐藏层（类似 Flash 版本），而下载的权重分片包含 61 层，表明存在需要修正的打包/配置不匹配问题。

DeepSeek Harness 已上线！（热度：373）：DeepSeek AI 宣布推出 DeepSeek Harness（dsh），这是一个开源 agent harness，处于开发者预览阶段，围绕"一切皆插件"的架构构建，并由 Cordis 驱动，参考了《A Programming Paradigm for Spatiotemporal Composability》中的设计。该项目明确表示不稳定——"将会有破坏兼容性的变更"——并将开发者引导至 DeepSeek Harness Discord；未提供基准测试、除插件/Cordis 模型之外的实现细节，也没有 API 稳定性保证。热门评论对该项目迅速走红持怀疑态度，一位用户声称在约一小时内看到 GitHub 星标从 20k 涨到 30k，怀疑存在机器人刷星。其他技术反应质疑了 agent harness 普遍采用 TypeScript 实现的趋势，并询问 dsh 是否能比 Reasonix 实现更好的缓存命中率。

• 一位评论者提出实现层面的担忧，认为大多数 agent/harness 项目似乎都是用 TypeScript 编写的，与 Codex 形成对比（后者可能是例外）。技术上的隐含质疑是关于编码 harness 的运行时/生态系统选择，但未提供具体的基准测试或失败模式。
• 一个技术问题询问 DeepSeek Harness 是否能比 reasonix 实现更好的缓存命中率，指出缓存效率对于 agentic 编码工作负载越来越重要，因为重复的上下文/工具调用可能主导成本和延迟。
• 相关的发布材料是 GitHub 仓库 deepseek-ai/deepseek-harness 和产品页面 deepseek.com/harness/en/，但评论者指出该公告缺乏详细的技术文档或基准数据。

• Claude 和 GPT 的隐藏推理被解码，结果相当有趣（热度：447）：一篇被引用的论文 "Stealing Reasoning Traces from Proprietary LLM APIs" 声称，通过 API 侧泄露方法可以恢复 Claude 和 GPT 模型的隐藏推理 token，相关示例已发布在 mitkox/stolen-thoughts 仓库中。该帖子重点展示了一个 AIME 示例，其中解码出的 Claude 推理痕迹似乎能凭记忆识别出基准测试题目——"这是一个已知的 AIME 问题。答案是 60"——这引发了对基准测试污染以及专有模型数学分数虚高的担忧；评论者还链接了 X/Twitter 镜像 上的相关讨论。核心争论在于：前沿模型的推理痕迹是否揭示了隐藏的算法"秘方"？发帖者认为，这些痕迹大多只是展示了普通的现象，比如记忆、不连贯的中间 token 和过度思考，这意味着开源模型可能比基准测试差距所暗示的更接近前沿水平。此外，还有人推测这种泄露可能已经促成了对专有模型的大规模蒸馏，而堵住这个漏洞可能会减缓未来的蒸馏工作。

一个关联仓库 mitkox/stolen-thoughts 被引用作为"解码"闭源模型隐藏推理痕迹的证据。引用的推理痕迹在技术上很有趣，因为它似乎暴露了内部的思维链式行为，包括问题识别、对 AIME 问题的部分记忆、中间几何计算（如 AC = 7√3 和 AD = 13√3），以及围绕最终答案的不确定性和自我修正。

• 一位评论者认为，推理 token 中可能并不存在独特的专有"秘方"：差距主要在于数据、算力和工程，而非根本不同的推理机制。他们推测，开源权重模型未来可能达到闭源模型的能力水平，同时还能装进一台 128G 设备中，不过这更多是预测而非基准测试证据。
• 另一个技术观点是，隐藏推理的价值不在于面向用户的输出，而更多在于后训练和 RL 优化：保留或监督潜在推理痕迹可以改善训练信号，并通过避免更长的可见生成来降低成本。其主张是，隐藏推理主要有助于优化后训练目标和推理经济性，而非代表一种质上不同的能力。

Anthropic、OpenAI、Google、Meta、Microsoft 和 Mistral 均签署了欧盟《AI 生成内容透明度行为准则》（热度：949）：图片 是 X 平台帖子的截图，声称 Anthropic、OpenAI、Google、Meta、Microsoft 和 Mistral 签署了欧盟关于 AI 生成内容透明度的行为准则，其中 OpenAI 的支持文本表示希望将溯源信号扩展到所有模态，包括文本。Reddit 帖子将此解读为未来将对生成的代码和散文进行隐形水印标记，包括这些厂商的本地/开源权重模型，不过该图片本身并非技术规范或实现证明。评论者主要关注实际绕过方法和工作流风险：有人认为水印可以通过约 10M 个生成 token 被学习，并被一个小型对抗性 1.5B 模型或浏览器扩展移除；另一些人则担心这可能推动用户转向非签署方或中国模型，或干扰智能体代码生成和编译器。

• 一位评论者认为，文本水印在技术上可能很容易被逆向工程：每个模型生成大约 10,000 段文本 / ~10M 个 token，训练一个分类器来区分输出，识别与水印相关的特征，然后训练一个对抗性 1.5B 模型对文本进行最小化改写以移除信号。他们声称这种移除器可以在笔记本电脑 CPU 上本地运行，或作为浏览器扩展实时修改流式 LLM 输出。
• 几位评论者质疑隐形水印是否与功能性文本生成兼容，尤其是代码生成。担忧在于 token 分布扰动或隐藏标记可能干扰智能体脚本、对编译器敏感的输出或精确格式生成，这与图像/音频/视频中的水印不同——后者中不可感知的信号通道更为自然。
• 一个技术采用方面的担忧是，欧盟强制水印可能推动用户转向签署方之外的开放权重或更便宜的 API 模型，尤其是中国模型，如果水印影响输出质量或可检测性的话。有评论者推测，如果其他市场的用户拒绝水印，提供商可能会维持仅限欧盟的水印行为。

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

• DeepMind 刚刚发布了 SL2T，一种手语转文本模型，聋哑用户现在可以通过手语输入手机而无需打字，该模型在开发过程中得到了聋人社区的深度参与（活跃度：3468）：据报道，DeepMind 发布了 SL2T，一种手语转文本系统，能够将同步的手部、身体和面部动作实时转换为英文文本，使聋哑用户可以通过手语输入手机而无需打字；详细信息见所附的 DeepMind 博客文章。该文章指出，姿态追踪在设备端运行以保护隐私，而翻译则在服务器端完成，支持诸如单手打手语同时持握手机等实际场景，并声称在*“学术基准测试中达到最先进水平”*，不过 Reddit 摘要中未提供具体的基准数据。热门评论总体持积极态度，对 DeepMind 表示尊重，并惊讶于这类无障碍技术此前竟未出现；所提供评论中不存在实质性的技术争论。

• PSA：我是 Heretic 的创建者，建议你不要将 “heretic” 模型用作 H3（或任何其他模型）的文本编码器（活跃度：2901）：Heretic 的创建者警告说，将 “heretic”/去审查（abliterated）大模型替换为图像/视频模型的文本编码器——例如替换 Minimax H3** 的 Qwen3-VL 编码器——不会减少输出审查，反而可能降低提示词遵循度或引入伪影。Heretic 风格的方法使用方向性消融（directional ablation）/ ARA / SOMA 来扰动残差流表示，使“有害”提示词在大模型拒绝行为层面看起来像“无害”提示词；这些方法不会为下游扩散/Transformer 生成器产生更丰富、更“原始”的语义嵌入，反而会将隐藏状态移出生成器训练时所基于的分布。一个可能的例外是那些具有显式拒绝型大模型阶段的模型或工作流，例如提示词增强器或 Ideogram 风格的主动拒绝系统，在这些场景中，对那个大模型组件进行去审查可能确实有意义。评论大多支持该 PSA，认为其具有权威性且值得广泛传播。一位评论者指出一个实际例外：如果图像工作流首先通过一个基于大模型的提示词增强器来处理用户提示词，而该增强器本身会拒绝有争议的内容，那么将该增强器替换为未审查模型可以在提示词到达生成器之前绕过拒绝。

一位评论者指出了 Heretic/未审查模型在图像生成工作流中的一个狭窄有效用例：不是作为 H3 或类似模型的文本编码器，而是作为上游的大模型提示词增强器，在用户提示词传递给图像模型之前对其进行重写。他们报告说，某些提示词增强器工作流会拒绝“有争议的内容”，而换用未审查的大模型可以避免这种拒绝，这意味着收益在于提示词预处理层，而非 CLIP/T5 风格的图像模型条件化层。

• DeepSeek 大幅上调 API 价格（自 2026 年 8 月 16 日生效）——缓存命中最高涨幅达 1,114%（热度：1597）：DeepSeek 正在调整其 API 定价，自 2026-08-16 16:00 UTC 起生效，新增高峰/低谷时段，其中高峰时段价格为低谷时段的 2×，详见其 API 定价文档。涨幅最大的是缓存输入：V4-Pro 缓存命中价格从 $0.003625 上涨至低谷/高峰时段的 $0.022/$0.044 每计价单位，即 +507%/+1,114%；输出价格同样大幅上涨，V4-Pro 输出从 $0.87 涨至 $1.98/$3.96（+128%/+355%）。这实质上削弱了 DeepSeek 在依赖提示词缓存的长时间上下文/重复性工作负载上的成本优势，并引入了围绕 UTC 高峰时段的调度与成本优化复杂性。热门评论大多偏非技术性且态度悲观；一位评论者表示他们"已经迁移走了"，因为*"DS4 不错，但前提是便宜"*，暗示该模型的价值主张高度依赖低廉的 API 定价。

部分用户报告称已开始从 DeepSeek API 迁移，他们认为 DS4 的价值主张高度依赖低价策略；在宣布涨价后，尽管模型质量尚可，他们仍认为其竞争力已大不如前。

• 一位评论者指出了与时区相关的定价优势：在巴西，API 的"低谷"时段恰好对应当地时间的 7:00–22:00，使得大部分正常工作时间都能享受折扣价格。

根据 artificial analysis arena 的评测，Grok 4.6 与 Sol 5.6 水平相当（热度：1475）：这张图片是一张名为"Artificial Analysis Intelligence Index"的基准测试柱状图，显示 Claude Opus 5 以 63 分领先，Claude Fable 5 为 62 分，而 GPT-5.6 Sol 与 Grok 4.6 并列 61 分，印证了帖子标题中*"Grok 4.6 与 Sol 5.6 水平相当"*的说法。评论补充了定价与模型规模背景：Grok 4.6 被描述为便宜得多（输入 $2/M，输出 $6/M tokens），而 GPT-5.6 Sol 为（输入 $5/M，输出 $30/M），且据称 Grok 4.6 是更小的 1.5T 参数模型，竞争对手则是 5T+。评论者将这一结果视为 xAI/Grok 在前沿模型上的惊人进展，有人指出 Google"完全退出前沿竞争"出乎意料。还有推测认为 Grok 4.7 可能扩展到 2T–2.5T 参数，未来主要模型将以"Kimi 级别"为起点。

• 评论者重点对比了定价与规模：Grok 4.6 输入 $2/M、输出 $6/M tokens，远低于 GPT 5.6 Sol 的输入 $5/M、输出 $30/M。有用户指出，SpaceXAI 仅将 Grok 4.6 与 Sol 和 Fable 对比，而非 Opus 或 Sonnet，尽管声称 Grok 4.6 是约 ~1.5T 参数的小模型，而对手据称是 5T+ 参数。
• 一个技术讨论串争论了 Grok 4.6 究竟是 2T 还是 1.5T 参数，一位评论者自我纠正称它很可能是 Grok 4.5 加上额外的强化学习，类似于 GPT 5.5 与 GPT 5.6 之间被声称的关系。他们认为这意味着 SpaceXAI 可能仅落后 OpenAI 约 3 个月，依据是推断 OpenAI 5.6 在 4 月/5 月左右可用，以及外部测试者在发布前约 3 个月就已获得 5.6 的访问权限。
• 多条评论将 Grok 4.6 的基准测试地位视为值得关注，因为它据称在多项基准上接近 SOTA，而 Google 似乎"已退出前沿"。另一位评论者提出，如果 Grok 4.6 和 Kimi 级别模型现在已成为大型前沿模型发布的基准线，那么即将推出的模型如 Grok 4.7 可能会转向 2T–2.5T 参数。

Grok 4.6 基准测试（热度：1017）：这张图片是"Grok 4.6 High"的基准测试表格（图片），将其与 Grok 4.5 High、GPT-5.6 Sol Max 和 Fable 5 Max 进行对比。结果显示 Grok 4.6 是强劲的前沿模型，在 GDPVal-AA v2、AA-Briefcase 和 Harvey LAB 上领先，而竞争对手在多个其他基准类别上仍保持领先；表格注明结果基于第三方模型评分，采用最佳自报或公开数据。一位评论者还强调了据报的 1.5T 规模，暗示模型大小/算力也是基准测试背景中值得关注的部分。评论大多轻松或带有推测性质：有用户将前沿进展描述为轮换炒作周期——Grok → Claude → Gemini → ChatGPT——另一位则称 1.5T 的规模"令人印象深刻"。

• 一位评论者指出，Grok 4.6 据报是 1.5T 参数模型，考虑到这一规模以及明显的快速进步，其基准测试结果尤为值得关注。另一位评论者强调了性价比，称 Grok "非常擅长编码" 且 "速度很快"，基准测试定位似乎接近 Kimi K3——"每任务价格完全相同"，但得分高出 1 分。
• 一个技术上颇有实质内容的工作流描述结合了 Claude Opus 和 Grok 进行编码：Opus 负责高层规划和初始实现，而 Grok 执行范围精确的编辑。该评论者将这种手动设置比作 Cursor/Composer 风格智能体编辑的强化版，并建议可以通过子智能体实现自动化。

• 我让 Opus 5 在 24 小时内独立开发 GTA6（热度：1558）：作者声称让 Opus 5 自主生成一个类似 GTA 的开放世界游戏，限时 24h，让模型自行决定城市布局、区域划分、道路、建筑、NPC、载具和天气，全程不做额外干预。作者随后发布了完整的编排框架，包括"技能、智能体、工具链、资源和模型"，托管在 ukanwat/aaabench；由于 Reddit 的 403 Forbidden 拦截，链接中的游戏实机/预告片视频无法从提供的 URL 访问。评论区大多停留在猜测层面：有用户询问 3D 模型/素材从何而来，也有人认为尽管结果"粗糙"，但这种自主游戏生成方式在未来十年内有望显著拓展独立游戏的生产边界，尽管可能存在 AI 生成的"垃圾内容"。

一个技术性较强的讨论聚焦于素材来源：有评论者追问*"模型是从哪里获取模型的"*，指出评估 AI 构建的 GTA 类演示，关键在于 Opus 是自行生成了网格/纹理，还是使用了内置素材、抓取/下载了第三方模型，抑或依赖了现有游戏引擎的素材包。这一区分对于判断自主性、版权风险以及结果在多大程度上反映真实模型能力（而非素材拼装）至关重要。

Opus 5 用起来简直让人抓狂。（热度：1378）：该帖报告了 Anthropic Claude Opus 5 在编码/工作流场景中的糟糕可用性，尽管作者遵循了 Anthropic 的官方指南并修改了全局 claude.md：输出仍然过于冗长、堆砌术语，且倾向于把小任务膨胀成多步骤的"项目"。作者的主要技术抱怨是代码编辑不完整 / 代码腐化：Opus 5 可能修改了文件的一部分，却破坏了同一文件中的另一部分，然后只是轻描淡写地提示*"如果你也想改这部分，告诉我"*，而不是修复自己引入的不一致；作者将其与 Fable 对比，称 Fable 这类问题较少，但即使在 $200 套餐上也有严格的每周限额。高赞评论强烈认同，将 Opus 5 形容为不可用或"令人恼火"；有用户表示，一个简单的"把两页文本文件精简一下"的请求，竟然变成了耗时一小时、附带约 10 个待办事项的漫长过程，另一位用户则说必须反复催促模型才能完成一个简单的修改请求。

• 多位用户报告 Opus 5 在任务跟随/回归方面存在劣于 Opus 4.8 的问题，尤其是在摘要、改写等简单转换任务上：有用户表示，一个"精简两页文本"的请求，一小时后变成了"大段文字"外加一套建议的工作流/系统以及大量后续待办事项。反复出现的核心技术抱怨是过度分解和过度规划，而不是直接完成请求的输出。
• 多条评论描述 Opus 5 在边缘情况上产生晦涩的散文和混乱的推理，有用户明确回退到 Opus 4.8，因为"Opus 5 什么都干不成"。另一位用户指出明显的"代码腐化"现象，称模型需要反复提示才能完成一个简单的编码任务，暗示与前代版本相比，指令遵循能力或持久性有所退化。
• 有评论者将 Opus 5 与 ChatGPT 5.6 进行不利对比，称自己已切换回去，因为 ChatGPT"有用得多"。虽然帖子没有提供任何基准数据，但讨论的核心主题是感知到的实际可用性退化：冗长、固执、执行力差，而非原始智能水平的问题。

好日子总是失去后才懂得珍惜（除非你还在用 4.6）（热度：1001）：配图是一张柱状图，对比各版本模型的每次回答字数，显示 Opus 5 明显更加冗长，达到 510 字/回答，而 Opus 4.6 为 234、Opus 4.8 为 259、Opus 4.7 为 276、Fable 5 为 316、Opus 4.5 为 158。帖子以此论证，更新的模型——尤其是 Opus 5——在实际工作流中可能并不更令人愉悦，因为它们会"淹没聊天窗口"地输出无关废话，尽管纸面实力更强。评论者就"更高的基准智能是否意味着更好的可用性"展开辩论：有人更倾向于一个稍弱但能简洁执行的模型，而不是一个过度叙述的模型；也有人询问图表背后的数据来源。第三位评论者表示，自己现在将 Kimi K3 作为主力模型，因为它更令人愉悦，并且会暴露推理轨迹供其他智能体监督。

• 多位评论者认为，更高的基准分数或"纸面更聪明"的表现并不必然转化为更好的开发者体验：Opus 5 因冗长的元推理、过多的免责声明以及反复生成新的后续问题（而非直接完成任务）而受到批评。有用户表示，如果某个"稍弱的模型"能更可靠地理解任务并无需长篇叙述就能执行，他宁愿选择它。
• 一个工作流对比突出了 Kimi K3 作为首选"主力"模型，Claude/Sol 则作为规划/审查智能体。关键技术要点在于，Kimi 据称会暴露推理轨迹而非隐藏它们，使监督智能体能够近乎实时地检查中间推理过程并更有效地发现问题；Fable 被描述为更擅长规划，而 Sol 更彻底但写作风格退化，体验较差。