AI模型 on KnightLi的博客

Claude Opus 4.8 发布：Anthropic 继续强化编程与代理任务

Fri, 29 May 2026 15:22:47 +0800

Anthropic 在 2026 年 5 月 28 日发布 Claude Opus 4.8。这是 Opus 系列的新版本，官方定位很明确：不是一次换代式命名，而是在 Opus 4.7 基础上继续增强编程、代理任务、推理和专业知识工作能力。

这次更新对普通聊天用户当然有意义，但更值得关注的是 Claude Code 和长任务 agent 场景。Anthropic 把 Opus 4.8 描述成更可靠的协作者：在复杂任务里更能判断何时提问、何时推进、何时保守处理。

这次更新的重点

Claude Opus 4.8 已经上线，价格保持不变。官方同时强调了几项配套变化：

Opus 4.8 在代码、代理能力、推理和知识工作评测上相比前代继续提升。
claude.ai 用户可以控制 Claude 在任务上投入的 effort。
Claude Code 新增 dynamic workflows，用来处理更大规模的问题。
Opus 4.8 的 fast mode 可以以约 2.5 倍速度工作，并且比此前模型的 fast mode 便宜三倍。

这些变化放在一起看，Anthropic 不是只在模型分数上做小幅升级，而是在围绕“长时间执行复杂任务”改产品形态。模型更强只是其中一部分，任务控制、工作流拆解和成本结构同样重要。

为什么 Claude Code 用户更应该关注

Claude Code 这类编程 agent 最怕的不是单个函数不会写，而是在真实仓库里迷路。它需要读文件、理解依赖、跑测试、看错误、修改方案，再把修改控制在合理范围内。

Opus 4.8 的卖点正好贴近这些问题：

更适合 agentic tasks，也就是需要模型持续计划、调用工具、观察结果并调整策略的任务。
更强调 judgement，能在不确定时停下来确认，而不是一路自信地写错。
dynamic workflows 让 Claude Code 更适合处理大规模、多步骤的问题。

如果这些能力在真实项目里稳定，Claude Code 的使用方式会更接近“把一个明确目标交给它推进”，而不是只让它补一段代码。

effort 控制意味着什么

Anthropic 这次给 claude.ai 加入 effort 控制，含义很直接：用户可以调节模型在任务上花多少力气。

这对日常使用很实用。简单问题不需要深推理，复杂任务则值得让模型多想一会儿。过去很多用户只能靠提示词表达“认真一点”或“快速回答”，现在这种控制开始进入产品层。

对开发者来说，这也是一个信号：未来 agent 产品不会只暴露“选哪个模型”，还会暴露更多执行策略，比如速度、成本、推理深度、工具调用积极程度和风险偏好。

fast mode 的成本变化很关键

官方提到，Opus 4.8 的 fast mode 可以达到约 2.5 倍速度，同时成本比此前模型的 fast mode 低很多。

这件事容易被模型能力新闻盖过去，但它对实际工作流很重要。很多 agent 任务不是只跑一次，而是会反复执行：

生成初稿
跑测试
修复失败
再跑测试
根据 review 继续改

如果 fast mode 足够便宜，团队就更愿意把它放进高频流程里，而不是只在关键任务上偶尔使用顶级模型。速度和成本一旦下降，agent 才更容易从“演示效果”进入“日常工具”。

和 Opus 4.7 的关系

Opus 4.8 更像是一次面向可用性的增强版。它继承 Opus 4.7 的定位，但把重点继续推向编程、代理任务和专业工作。

从 Anthropic 的表述看，Opus 4.8 不只是回答更好，而是更会协作。它在任务中应该更清楚什么时候需要信息、什么时候方案不稳、什么时候应该先建立信心再做大改动。

这类能力很难只靠单一 benchmark 判断。真正的验证要看它在大型仓库、复杂业务规则、长上下文任务和多轮修复里的表现。

对 AI 编程竞争的影响

2026 年的模型竞争已经明显从“聊天能力”转向“能不能做事”。OpenAI、Anthropic、Google、xAI 都在把模型和工具链绑得更紧：模型负责推理，工具负责执行，产品层负责把任务保持在可控范围内。

Claude Opus 4.8 的发布延续了这个趋势。它的重点不是炫耀一个单点能力，而是强化三个环节：

模型本身更适合代码和代理任务。
Claude Code 能拆更大的工作流。
产品层开始提供 effort 和 fast mode 这类执行控制。

这对开发者的实际意义是，选择模型时不能只看“哪个最聪明”。还要看它是否适合所在工具、能否稳定调用工具、长任务成本是否可接受、失败时是否容易被纠正。

我的判断

Claude Opus 4.8 是一次偏务实的更新。它没有把叙事放在一个夸张的新参数上，而是继续补 agent 工作流最需要的东西：判断力、稳定性、速度、成本和任务控制。

如果你已经在使用 Claude Code，这次更新值得尽快试。尤其适合拿真实仓库里的长任务做对比，比如跨模块重构、测试修复、文档同步、复杂 bug 定位。

如果你只是普通聊天用户，Opus 4.8 的变化可能不会像新一代模型发布那样立刻震撼。但从产品方向看，它说明 Anthropic 仍在把 Claude 往“可靠执行复杂工作”的方向推。

原文链接：Introducing Claude Opus 4.8

GPT-5.6 爆料：150 万 token 上下文窗口意味着什么

Wed, 27 May 2026 13:55:06 +0800

2026 年 5 月 26 日，有爆料称多名开发者在 OpenAI Codex 后端日志中发现了尚未官宣的 GPT-5.6 相关痕迹，其中一个内部代号为 iris-alpha，传闻支持 150 万 token 上下文窗口，并可能在 2026 年 6 月发布。

这类信息目前仍属于爆料，不等于 OpenAI 官方发布。更稳妥的看法是：它展示了下一代大模型可能继续沿着“更长上下文、更强代码能力、更好前端生成”几个方向推进。

爆料里提到哪些模型代号

报道提到，开发者在相关日志中看到的不只 iris-alpha，还包括 ember-alpha 和 beacon-alpha 等版本。

这些名字现阶段更像内部测试代号。它们是否都属于 GPT-5.6 系列、最终会不会对应公开 API 模型、发布时间是否会改变，都还没有官方确认。

所以不要急着把这些代号当成最终产品名。真正值得关注的是它们暴露出来的能力方向。

150 万 token 上下文为什么重要

报道里最醒目的数字是 150 万 token 上下文窗口。

爆料中给出的对比是：

当前 GPT-5.5 API 为 105 万 token
Codex OAuth 渠道约为 40 万 token
GPT-5.6 传闻提升到 150 万 token

上下文窗口决定模型单次能接收和利用多少信息。它包括用户输入、历史对话、系统提示、文件内容、日志、代码 diff、测试输出等。

如果这个数字属实，GPT-5.6 对几类任务会更有意义：

阅读大型代码仓库
分析长篇合同或技术文档
连续跟踪复杂项目
保留更长的 agent 工作历史
在一次任务里处理更多文件和更多测试反馈

但上下文窗口变大，不代表模型一定“更聪明”。它只是让模型能看到更多材料。模型是否能从长上下文里准确检索、归纳、保持目标一致，还要看训练、推理策略和工具调用能力。

真实世界测试的信号

报道还提到，有开发者在辅助工具 OpenCode 中做了较极端的真实世界测试：当输入达到约 90 万 token 时，模型仍能流畅响应，甚至处理超过 105 万 token 的请求。

如果这个反馈准确，它说明 OpenAI 可能不仅在扩展理论窗口，也在处理长输入下的响应稳定性。

对 AI 编程来说，这点比“窗口数字”本身更重要。开发任务里的上下文往往不是干净的长文本，而是代码、日志、错误栈、依赖文件、配置文件和用户指令混在一起。模型不仅要装得下，还要找得准。

前端界面生成能力也被提到

这次爆料还提到了 GPT-5.6 的前端生成能力。

据报道，爆料截图中模型在几乎没有详细提示词的情况下，生成了一个名为 Lumen Notes 的极简记事应用界面。报道强调的表现包括：

栅格布局更成熟
配色更克制
字体层级更清晰
导航结构更完整

如果这类能力稳定，AI 编程模型的价值会继续从“能写代码”转向“能生成更接近可用产品的界面”。这也是 Codex、Claude Code、Cursor、Gemini CLI 等工具最近都在推进的方向：不只是补函数，而是从需求到界面、测试、修复形成闭环。

还提到了哪些竞争模型

同一批爆料还提到，Anthropic 的 Claude Sonnet 4.8、Google 的 Gemini 3.5 Pro，以及 xAI 的 Grok 5，都可能瞄准 2026 年 6 月发布。

这部分同样要按传闻看待。即便多个模型确实都在 6 月前后更新，最终能力也要等官方文档、API 实测和真实开发任务验证。

不过大方向很清楚：模型厂商的竞争已经不只是聊天能力，而是更长上下文、更强工具调用、更稳的代码编辑、更好的 UI 生成，以及更适合 agent 长任务的可靠性。

我的判断

如果 GPT-5.6 的 150 万 token 上下文窗口最终成真，它对 Codex 这类编程 agent 的意义会比普通聊天更大。

因为 agent 编程天然会消耗大量上下文：读仓库、跑测试、看日志、比较 diff、保留用户偏好、连续修复问题。上下文越长，agent 越有机会在一次任务里保留完整线索。

但我更关心三个实际问题：

长上下文下的定位能力是否稳定。
大量日志和代码混合输入时，模型是否会被噪音带偏。
API、Codex、ChatGPT、OAuth 等不同入口是否会给出一致的上下文上限。

所以这条爆料可以关注，但不适合过早下结论。等 OpenAI 官方发布模型卡、API 文档和真实价格之后，再判断 GPT-5.6 是否真的适合大型代码仓库和长任务 agent 工作流，会更稳。

Gemini 3.5 Flash 的定位及优势：为什么它更适合高频、多模态和低延迟场景

Sun, 24 May 2026 08:43:24 +0800

Gemini 3.5 Flash 的关键词不是“最强”，而是“高频、快速、便宜、好接入”。它更像是 Gemini 系列里的主力工作模型：不一定负责最难的推理题，但适合承接大量真实业务请求，例如问答、摘要、客服、内容处理、多模态理解、轻量代码辅助和自动化工作流。

理解 Flash 的关键，是不要把它当成 Pro 类旗舰模型的替代品，而要把它当成一个面向吞吐量和响应速度优化的模型层。对开发者和企业来说，很多 AI 应用真正的成本不在单次最强能力，而在每天成千上万次请求的延迟、稳定性、价格和上下文处理能力。

Flash 的产品定位

Gemini 系列通常会把模型拆成不同层级：旗舰模型负责更复杂的推理、规划和高难度任务；Flash 模型则强调速度、成本和规模化调用。

Gemini 3.5 Flash 的定位可以概括为：

比 Pro 更适合高频调用。
比轻量小模型更适合复杂输入。
面向低延迟和高吞吐。
适合多模态输入和长上下文处理。
更适合作为应用里的默认模型，而不是只在少数困难任务中调用。

这类模型最适合做“每天都要跑很多次”的任务。它的价值不只是单次回答质量，而是能否在成本可控的前提下稳定处理大量文本、图片、音频、视频或结构化信息。

为什么 Flash 很重要

AI 产品落地时，经常会遇到一个现实问题：最强模型很好，但不是每个请求都值得用最强模型。

例如：

用户问一个普通客服问题。
系统要总结一段会议记录。
后台要分类一批工单。
App 要解释一张图片。
自动化流程要从邮件里抽取字段。
Agent 要先读一批文档，再决定下一步。

这些任务需要模型可靠、便宜、快，但不一定需要旗舰模型的全部推理能力。Flash 的意义就在这里：它把“够强”和“够快”放在同一个位置上。

如果一个 AI 应用要面向大量用户，默认模型往往不能只看峰值能力，而要看平均请求成本、响应速度、并发能力和失败率。Flash 就是这种应用层模型。

主要优势一：低延迟和高吞吐

Flash 最直观的优势是速度。

对聊天产品、搜索增强、客服机器人、实时写作辅助和 Agent 工作流来说，延迟会直接影响体验。用户不一定知道模型参数或 benchmark，但能感觉到“是不是等得烦”。

低延迟带来的价值包括：

对话更像实时交互。
多轮工具调用更不容易拖慢。
Agent 可以更频繁地做中间判断。
后台批处理能更快跑完。
产品可以把 AI 能力放进更多细小流程里。

尤其是 Agent 类应用，模型不是只回答一次，而是要反复判断、调用工具、读上下文、生成下一步动作。单次延迟降低后，整条链路的体验会明显改善。

主要优势二：成本更适合规模化

Flash 的另一个核心价值是成本。

企业和开发者真正上线 AI 应用时，通常会关心三个问题：

每次调用多少钱。
每天总调用量是多少。
峰值并发时成本和延迟是否可控。

如果一个任务每天跑几十万次，哪怕单次差价很小，长期成本也会被放大。Flash 这类模型的定位，就是让更多请求不必直接打到最贵、最重的模型上。

常见做法是分层调用：

普通请求默认走 Flash。
难题、复杂规划、长链路推理再升级到 Pro。
简单分类、固定格式抽取也可以进一步下沉到更轻量模型。

这样可以让 AI 系统既保留上限，又控制日常成本。

主要优势三：多模态输入更适合真实应用

Gemini 系列一直强调多模态能力。Flash 的优势在于，它不是只服务文本请求，也适合处理图片、音频、视频和文档等输入。

这对真实产品很重要。很多业务数据并不是纯文本：

用户上传截图咨询问题。
客服要理解一张故障照片。
教育产品要看题目图片。
内容平台要处理视频片段。
办公场景要读取 PDF、表格和演示文稿。
电商场景要分析商品图和用户描述。

如果多模态能力只能依赖昂贵的旗舰模型，很多高频场景就很难铺开。Flash 的意义在于，把多模态理解下放到更适合规模化调用的模型层。

主要优势四：长上下文让它适合读材料

长上下文是 Gemini 系列的重要能力之一。对 Flash 来说，长上下文的价值不是“把所有东西塞进去就完事”，而是让它能承担更多信息整理型任务。

例如：

总结长文档。
阅读产品手册。
分析会议纪要。
整理多页 PDF。
对比多份合同或方案。
给 Agent 提供较大的任务背景。

长上下文和低成本结合起来，适合做“先读大量材料，再给出可操作结果”的工作流。它不一定每次都要做极难推理，但能把更多上下文纳入同一次处理，这对办公、客服、知识库、研发辅助都很有用。

主要优势五：适合作为默认模型

很多 AI 产品需要一个“默认模型”。这个模型不一定是最贵最强，但要满足几个条件：

大多数问题回答质量稳定。
响应足够快。
成本可控。
多模态输入能处理。
长上下文能力够用。
容易接入 API 和现有产品链路。

Gemini 3.5 Flash 的优势正是在这里。它适合做默认入口：先承接大多数请求，如果遇到复杂任务，再路由到更强模型。

这种模式会越来越常见。未来很多 AI 系统不是“只选一个模型”，而是“Flash 做主力，Pro 做升级，轻量模型做边缘任务”。

适合哪些场景

Gemini 3.5 Flash 更适合这些场景：

客服问答和知识库检索后的回答生成。
长文档摘要、报告整理、会议纪要。
图片、截图、PDF、视频片段的多模态理解。
App 内实时 AI 助手。
内容审核、分类、标签生成。
邮件、工单、表单的信息抽取。
Agent 工作流中的中间判断和上下文压缩。
代码解释、轻量修复建议、文档生成。
教育产品里的题目解析和学习辅助。

这些场景共同特点是：请求量大、用户等待时间敏感、输入类型复杂，但不一定每次都需要旗舰级深度推理。

不适合只用 Flash 的场景

Flash 不是万能模型。它更适合高频和低延迟，不代表所有问题都应该只用它。

以下场景仍然更适合使用更强的 Pro 类模型，或至少采用分层路由：

复杂数学和严谨证明。
长链路规划和多步骤策略推理。
高风险法律、医疗、金融判断。
大型代码库的深度重构方案。
需要极高可靠性的复杂 Agent 任务。
对幻觉容忍度极低的专业报告。

更稳妥的策略是：Flash 先处理、判断和整理；当任务复杂度升高时，再升级到更强模型。

和 Pro 类模型的关系

Flash 和 Pro 的关系，不应该理解成“谁取代谁”，而应该理解成“分工不同”。

Flash 更像日常主力：

快。
成本友好。
适合高并发。
适合多模态和长上下文应用。
适合放在产品默认链路里。

Pro 更像高难任务模型：

更适合复杂推理。
更适合困难规划。
更适合高价值请求。
更适合少量但重要的深度分析。

好的 AI 产品通常会把两者组合起来，而不是二选一。

开发者应该怎么用

如果要在产品里接入 Gemini 3.5 Flash，可以考虑这几种用法：

第一，把它作为默认模型。大部分普通请求先走 Flash，既保证速度，也控制成本。

第二，设计模型路由。当 Flash 判断任务复杂、风险高、需要深度推理时，再把请求升级到 Pro。

第三，用它做上下文压缩。Agent 在执行任务前，可以先让 Flash 总结文档、抽取关键事实、生成结构化上下文。

第四，把多模态输入纳入常规流程。图片、截图、PDF、音频、视频不要只作为边缘功能，而可以成为产品默认输入的一部分。

第五，用评测来决定边界。不要只看官方 benchmark，要拿自己的客服问题、文档、代码、图片和业务流程做测试，判断哪些任务 Flash 足够，哪些必须升级。

小结

Gemini 3.5 Flash 的核心定位，是一个面向高频真实应用的多模态主力模型。它的优势不在于取代 Pro 类旗舰模型，而在于把速度、成本、长上下文和多模态能力放到一个更适合规模化调用的位置上。

对开发者来说，Flash 最值得关注的不是单个 benchmark，而是产品架构变化：默认模型可以更快、更便宜、更能读复杂输入；复杂任务再升级给更强模型。这样既能保证体验，也能控制成本。

如果说 Pro 是处理难题的重型工具，那么 Flash 更像每天都在生产线上运转的主力工具。真正做 AI 产品时，后者往往更接近用户每天实际感受到的体验。

参考资料：

Google 官方博客：https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5/
Google DeepMind Gemini Flash：https://deepmind.google/en/models/gemini/flash/
用户提供的知乎讨论链接：https://www.zhihu.com/question/2040529179641385344/answer/2040531897613285214

Gemini 3.5 正式发布：Flash 先行，Google 把重点放在 Agent 和长任务执行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式发布 Gemini 3.5 系列。第一款开放使用的是 Gemini 3.5 Flash，定位不是单纯的聊天模型，而是面向 Agent、代码生成和长时间复杂任务执行的模型。

从这次公告看，Google 对 Gemini 3.5 的叙事很明确：模型不只要回答问题，还要能规划、执行、检查，并在多步任务中持续推进工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已经面向多类用户开放：

普通用户可以通过 Gemini 应用和 Google 搜索中的 AI 模式体验。
开发者可以通过 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企业用户可以通过 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同时提到，Gemini 3.5 Pro 仍在开发中，已经在 Google 内部使用，计划在下个月推出。

这说明 3.5 系列会继续保留 Flash 与 Pro 的分层：Flash 更强调速度、成本和可规模化执行，Pro 则更可能面向更复杂、更高能力需求的场景。

重点是 Agent 和代码任务

Google 把 Gemini 3.5 Flash 称为目前最强的 Agent 与代码编写模型之一。公告中提到，它在多项代码和 Agent 基准测试中超过 Gemini 3.1 Pro 的部分成绩，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

这些指标本身不是普通用户最需要关心的内容。更重要的是，Google 正在把模型能力往“可执行工作流”上集中：不仅能写代码，还能处理旧项目迁移、复杂应用开发、财务报表整理、数据分析和持续测试。

在 Antigravity 开发架构中，Gemini 3.5 Flash 可以通过多个协作子代理处理大型任务。Google 展示的例子包括解析 AlphaZero 论文并实现可玩的游戏、把旧版代码转换为 Next.js、并行生成城市景观和 UI 方案。

这类能力的方向很清楚：AI 编程工具正在从“生成一段代码”走向“组织多个 Agent 完成一个项目”。

多模态 UI 与图形能力增强

Gemini 3.5 Flash 继承了 Gemini 3 的多模态基础。Google 强调它可以生成更丰富的网页 UI、交互动画和图形内容。

公告中给出的应用场景包括：

为研究论文生成交互式动画。
根据文字描述生成交互式硬件模型。
为学校募款活动生成完整品牌概念。
在短时间内为结账流程生成多种 UX 方案。

这部分对开发者和产品团队很有意义。模型不再只是输出文字说明，而是能参与前端原型、交互设计和可视化内容生成。

企业场景：把耗时流程自动化

Google 在公告中列举了多个合作伙伴案例。Shopify 使用子代理分析复杂数据并预测商家增长；Macquarie Bank 测试用 3.5 Flash 阅读超过 100 页的复杂文件，加速开户流程；Salesforce 将其整合到 Agentforce；Ramp 用它改进复杂发票 OCR；Xero 用 AI 代理处理行政流程；Databricks 用自动化工作流监控数据异常并给出修复建议。

这些案例共同指向一个趋势：企业采用大模型时，关注点正在从单次问答转向流程自动化。模型是否便宜、快、能长时间稳定执行，会比单次回答是否惊艳更重要。

Gemini Spark：个人 AI 代理

Google 还公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驱动的个人 AI 代理，目标是在用户引导下长期运行并主动执行任务。

Gemini Spark 已经开始面向受信任测试人员推出，Google 计划在下周向美国 Google AI Ultra 订阅用户开放 Beta 测试。

这部分值得关注。Google 搜索、Gemini 应用、Android、Workspace 和浏览器生态本来就覆盖大量个人数字生活场景。如果个人 Agent 能与这些入口结合，影响可能比单独的聊天机器人更大。

安全机制继续前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 开发，并强化了信息安全和 CBRN 相关防护。公告还提到使用可解释性工具，在模型给出回答前帮助检查和理解推理过程。

这说明前沿模型的发布已经不只是能力竞赛。越是强调 Agent、自动执行和长任务，安全控制、误拒率、有害输出防护和可解释性就越重要。

怎么看 Gemini 3.5

Gemini 3.5 Flash 的意义不只是“又一个新模型发布”。它更像是 Google 对下一阶段 AI 产品形态的集中押注：模型要能调用工具、拆分任务、协作执行、生成 UI，并进入个人和企业工作流。

对开发者来说，值得关注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的实际体验。对企业来说，重点是它能否在真实流程中稳定减少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 还没有正式开放。等 Pro 发布后，Flash 与 Pro 在能力、价格、速度和上下文处理上的差异，才会决定它们各自更适合哪些生产场景。

参考来源：

Google Blog：Gemini 3.5 正式登场

DeepSeek-V4 KV Cache 机制解析：为什么 1M 上下文更省显存

Mon, 18 May 2026 18:38:26 +0800

长上下文模型真正贵的地方，往往不是“能不能塞进 100 万 Token”，而是推理时 KV Cache 要占多少显存。

在 Transformer 解码过程中，每生成一个新 Token，模型都要保留历史 Token 对应的 Key 和 Value。上下文越长，KV Cache 越大；KV Cache 越大，显存、内存带宽、首字延迟和吞吐都会被拖慢。

DeepSeek-V4 的特别之处，是它没有只在注意力头数量上省缓存，而是把压缩进一步推进到序列长度维度。按照 Hugging Face 对 DeepSeek-V4 技术报告的解读，在 1M Token 场景下，DeepSeek-V4-Pro 的 KV Cache 约为 DeepSeek-V3.2 的 10%；如果和常见的 bf16 GQA 架构相比，约为其 2% 左右。

这就是 DeepSeek-V4 缓存机制最值得看的地方：它不是简单把 KV 存得更小，而是减少需要长期保存和检索的 KV 条目数量。

先看几代 KV Cache 优化路线

KV Cache 优化大致可以分成几条路线。

第一类是传统 MHA，也就是 Multi-Head Attention。每个 Query 头通常都有对应的 Key/Value 头。它结构直接，但长上下文下缓存随序列长度线性增长，显存压力最大。

第二类是 GQA，也就是 Grouped Query Attention。多个 Query 头共享较少的 Key/Value 头。LLaMA、Mistral、Qwen 等很多现代模型都采用类似思路。它能显著减少 KV 头数量，是当前主流长上下文模型的常见节省手段。

第三类是 MLA，也就是 Multi-head Latent Attention。DeepSeek-V2、DeepSeek-V3 使用这一路线，把 Key/Value 压缩成低秩潜在表示，从注意力头维度进一步降低缓存占用。

第四类就是 DeepSeek-V4 引入的混合压缩注意力。它把重点放到序列长度维度：不是只减少每个 Token 要存多少 KV，而是把多个历史 Token 压缩成更少的 KV 条目，再用稀疏或稠密方式检索。

可以粗略理解为：

MHA：每个头都认真记。
GQA：多个 Query 头共享一部分记忆。
MLA：把每个 Token 的 KV 表示压成潜在向量。
DeepSeek-V4：把很多历史 Token 聚合成更少的压缩记忆块。

DeepSeek-V4 的关键变化：从头维度压缩到序列维度压缩

GQA 和 MLA 主要是在“每个 Token 存多少 KV”上做优化。这个方向很有效，但当上下文长度来到 1M Token 时，问题会变得更极端：即使每个 Token 的缓存已经很小，Token 数量本身仍然太多。

DeepSeek-V4 选择把旧上下文压缩成块。也就是说，模型不一定要为每个很久以前的 Token 都保留完整 KV，而是让多个 Token 形成压缩条目。

这有点像读一本很长的书：刚读过的几页你会记得细节，前面几章则更多以摘要、主题和关键线索的形式保存。DeepSeek-V4 的注意力机制也有类似分工：近处保留细节，远处用压缩表示。

CSA：4 倍压缩加稀疏检索

CSA 全称是 Compressed Sparse Attention，可以理解为较细粒度的长程压缩机制。

在 CSA 中，模型会把序列中的若干相邻 Token 压缩成更少的 KV 条目。Hugging Face Transformers 文档里给出的默认压缩率是 m=4，也就是大致每 4 个 Token 形成一个压缩条目。

但它不是简单平均。CSA 使用带学习能力的压缩池，并结合重叠窗口，让模型在压缩时保留更有用的信息。压缩之后，查询并不会对所有历史压缩块都做完整注意力，而是先通过 Lightning Indexer 打分，挑出最相关的 top-k 压缩块，再进入核心注意力计算。

这个结构有两层收益：

历史 KV 条目数量先变少。
每次查询只看最相关的一部分压缩块。

所以 CSA 适合处理远距离但仍需要细节检索的上下文，比如代码库、长文档、工具调用历史里的关键信息。

HCA：128 倍压缩加稠密注意力

HCA 全称是 Heavily Compressed Attention，压缩更激进。

Transformers 文档里给出的默认压缩率是 m'=128。也就是说，HCA 会把更长的一段上下文压成一个压缩条目。压缩后的序列已经很短，因此它不需要像 CSA 那样再做稀疏 top-k 检索，而是让 Query 对所有压缩条目做稠密注意力。

HCA 的作用更像全局摘要。它不追求保留每个细节，而是用极低成本覆盖很长的历史范围，让模型对全局背景、长程主题和远处信息保持感知。

如果把 CSA 比作“可检索的压缩笔记”，HCA 更像“全局目录和摘要”。

滑动窗口：最近上下文仍保留细节

DeepSeek-V4 并不是把所有上下文都压缩掉。

在 CSA 和 HCA 之外，它还保留了滑动窗口分支，用来处理最近的一段未压缩上下文。Transformers 文档里提到，DeepSeek-V4 的 attention block 会把长程压缩分支与滑动窗口 K/V 拼接在一起。

这个设计很重要。生成下一个 Token 时，最近几十到几百个 Token 往往最关键：变量名、函数签名、正在写的句子、刚返回的工具结果、最近用户要求。它们如果被过度压缩，输出质量会明显下降。

所以 DeepSeek-V4 的思路不是“全部压缩”，而是：

近处：保留未压缩细节。
中远处：用 CSA 做可检索压缩。
更远处：用 HCA 做重度全局压缩。

混合层栈：不同层做不同注意力

DeepSeek-V4 不是在所有层里使用同一种注意力。

Hugging Face 的 DeepSeek-V4 文章提到，V4-Pro 的 61 层结构中，前两层使用 HCA，之后的层在 CSA 和 HCA 之间交替，末尾的 MTP block 使用滑动窗口。Transformers 文档也说明，V4-Pro 默认是 2 层 HCA bootstrap 加交替 CSA/HCA。

这说明 DeepSeek-V4 把注意力机制当成分层系统来设计。不同层承担不同信息流角色：有的层更偏全局压缩，有的层更偏稀疏检索，有的部分保留局部窗口。

相比所有层统一使用一种注意力，这种混合结构更复杂，但也更适合 1M Token 这种极长上下文。

FP8 和 FP4 进一步降低缓存成本

DeepSeek-V4 的缓存节省不只来自压缩率。

Hugging Face 的文章提到，V4 的大部分 KV 条目使用 FP8 存储，RoPE 相关维度保留 BF16，而 CSA 里的 Lightning Indexer 使用 FP4。压缩比例、低精度存储、稀疏检索叠加在一起，才形成了非常低的 KV Cache 占用。

这也提醒我们：不要只看“上下文长度 1M”这个宣传数字。真正决定可部署性的，是长上下文下的显存占用、带宽压力、推理延迟和工程实现。

和其他模型的差异

与传统 MHA 相比，DeepSeek-V4 不再为长历史里每个 Token 保留完整注意力记忆，缓存压力下降非常明显。

与 GQA 相比，DeepSeek-V4 不只是减少 KV head 数量，还减少长历史的 KV 条目数量。GQA 仍然要随序列长度线性积累缓存，而 V4 会把远处上下文压成块。

与 DeepSeek-V3 的 MLA 相比，V4 的重点从“每个 Token 的表示更紧凑”进一步扩展到“历史 Token 数量也被压缩”。MLA 已经大幅降低单 Token KV 占用，但面对百万级上下文时，序列长度本身仍是压力来源。

与普通稀疏注意力相比，DeepSeek-V4 的 CSA 是先压缩再稀疏检索，索引器面对的是更短的压缩序列；HCA 则通过 128 倍压缩让全量稠密注意力也变得便宜。

对 Agent 和长任务有什么意义

Agent 工作流特别吃长上下文：它会读文件、调用工具、接收工具返回、生成计划、修正计划、继续调用工具。上下文越长，KV Cache 越容易成为瓶颈。

DeepSeek-V4 这种缓存机制的潜在价值在于：

更容易承载长代码库、长文档、多轮工具调用历史。
首字延迟和吞吐更不容易被 KV Cache 拖垮。
同等硬件上可以跑更长上下文或更多并发请求。
对百万 Token 场景，部署成本更接近实际可用，而不是只停留在论文指标。

不过也要注意，压缩注意力不是免费午餐。把历史 Token 压缩成块，必然涉及信息取舍。模型需要在“省显存”和“保留可检索细节”之间做平衡。真正效果还要看任务类型：代码定位、法律文档、长篇问答、Agent 工具链，对细节召回的要求并不一样。

不要把 2% 理解成所有成本都降到 2%

“KV Cache 约为 GQA 的 2%”很容易被误读。

它主要指 KV Cache 显存规模，不等于总推理成本只剩 2%，也不等于所有场景速度都会提升 50 倍。推理还包括模型权重读取、MoE 路由、前馈网络、注意力计算、调度开销、通信开销等。

Hugging Face 的文章里也把两个数字分开讲：在 1M Token 场景，DeepSeek-V4-Pro 相对 DeepSeek-V3.2 的单 Token 推理 FLOPs 是 27%，KV Cache 是 10%。这说明缓存和计算是两个不同维度。

所以更稳妥的说法是：DeepSeek-V4 让超长上下文的 KV Cache 压力显著降低，从而改善百万 Token 场景的部署可行性；但具体吞吐和延迟仍取决于实现、硬件、批处理、量化和推理框架。

小结

DeepSeek-V4 的缓存机制和其他大模型最大的不同，是它把 KV Cache 优化从注意力头维度推进到了序列维度。

GQA 是少存一些 KV 头，MLA 是把每个 Token 的 KV 表示压得更紧，DeepSeek-V4 则进一步把远处 Token 聚合成压缩块，并通过 CSA、HCA、滑动窗口和低精度存储组合起来，让百万 Token 上下文不再被 KV Cache 轻易卡死。

这不是单一技巧，而是一整套长上下文推理架构：近处保细节，远处做压缩，需要细节时稀疏检索，需要全局时重度摘要。

对开发者和 Agent 应用来说，它的意义很直接：长上下文不只是“能输入更多”，还要“跑得起、跑得稳、成本能接受”。DeepSeek-V4 真正改变的，正是这一点。

参考资料

Gemini 3.5 Pro 曝光：代号 Cappuccino，谷歌想在编程和 Agent 上追回节奏

Sun, 17 May 2026 11:47:27 +0800

Google 还没有正式发布 Gemini 3.5 Pro。

目前能看到的信息，主要来自开发者社区截图、匿名跑分、爆料人消息和媒体转述。36Kr / 新智元在 2026 年 5 月 15 日整理称，新一代 Gemini 检查点内部代号可能是 Cappuccino，相关模型已经在社区和评测平台中提前曝光。

这类信息还不能等同于官方发布，但它透露出一个清晰方向：Google 正在试图同时补上两块短板，一块是编程和推理能力，另一块是全天候 AI Agent。

先说结论

这次爆料可以拆成三层来看：

Gemini 3.5 Pro 尚未正式发布，Cappuccino 更像是内部检查点或候选版本代号。
曝光信息显示，新 Gemini 在代码生成、SVG / 交互式 Web 生成、多模态输出上有明显提升。
Google 同步测试的 Gemini Spark，可能比模型本身更关键，因为它指向 24 小时运行的个人 AI Agent。

换句话说，这不是一条简单的“模型跑分新闻”。它更像是 Google 在 I/O 前释放出的产品路线信号：模型要追赶 GPT-5.5，Agent 要抢占用户工作流入口。

Cappuccino 是什么

36Kr 文章提到，网友 Lentils 放出的消息显示，代号 Cappuccino 的 Gemini 3.5 Pro 检查点已经开始产出。此前社区还在讨论 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果这个命名最终属实，说明 Google 可能希望把下一代 Gemini 包装成一次更大的版本跃迁，而不是普通小版本更新。

需要注意的是，Cappuccino 现在仍应被视为爆料中的内部代号。它不等于 Google 已经公开上线的正式模型，也不代表最终发布名一定就是 Gemini 3.5 Pro。

编程能力为什么是焦点

这次爆料里最受关注的点，是新 Gemini 的编程能力。

36Kr 引述的社区截图和跑分信息显示，新模型在以下任务上表现更强：

生成 SVG 与视觉组件。
生成交互式 Web 应用。
处理动画、3D、可调参数面板等复杂前端输出。
逻辑推理和代码生成能力有所提升。

文章还提到，Abacus.AI CEO Bindu Reddy 转述的说法是，3.2 Flash 在编码和推理上接近 GPT-5.5 的水平，同时成本更低。另有媒体信源则认为，新款 Gemini 的整体性能大致追平 GPT-5.5，但未必能带来质变。

这也是为什么要谨慎看待“追平 GPT-5.5”这句话。它更像是不同爆料源和匿名评测中的相对判断，而不是 Google 官方给出的基准测试结论。

为什么 Google 急着补编程

AI 编程已经从开发者工具变成了大模型竞争的核心战场。

OpenAI 有 Codex，Anthropic 有 Claude Code。它们不只服务工程师，也在把产品经理、设计师、运营人员带进“自然语言生成可运行产品”的工作流里。

相比之下，Google 虽然有 Gemini 和 Antigravity，但在开发者心智里一直没有形成同等强度的默认入口。36Kr 文章也提到，Antigravity 在外部市场还没有真正突围，定价、额度提醒和体验稳定性都曾引发社区讨论。

所以新 Gemini 如果要证明自己，编程会是最直接的战场。它不一定只比拼“会不会写代码”，还要比拼能不能稳定产出完整界面、理解复杂需求、调用工具、修复错误并融入真实开发流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料里，Gemini Spark BETA 也被扒出。

根据 TestingCatalog 等信息源的说法，Spark 的定位接近“全天候 AI Agent”：它可以处理收件箱、执行在线任务、管理多步骤工作流，并连接 Google 应用、技能模块、聊天记录、定时任务、登录网站、位置信息等上下文。

这意味着 Spark 不是一个普通聊天入口，而是一个可能长期在线、持续读取上下文并替用户执行任务的系统。

它的吸引力很明显：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起来，Spark 会天然拥有 OpenAI 和 Anthropic 很难复制的分发优势。

但风险也同样明显。36Kr 文章提到，Spark 相关说明中出现了“可能在未经询问的情况下分享信息或完成购买”的表述。哪怕系统设计上会在敏感操作前征求许可，这类 Agent 仍然会带来隐私、授权边界和误操作风险。

这对普通用户意味着什么

如果你只是普通 Gemini 用户，这次爆料真正值得关注的不是模型名，而是三个变化：

第一，Google 可能会继续强化“生成完整结果”的能力。以前用户经常吐槽 Gemini 在视觉生成、SVG、前端页面上容易偷懒，如果新模型能一次给出多个完整方案，体验会明显改善。

第二，编程能力会继续下放到更轻量的模型。爆料里反复提到 Flash 版本在编码、推理和交互式生成上的提升，这意味着未来不一定只有 Pro 模型才能处理复杂任务。

第三，Agent 会变得更主动。Spark 如果发布，Gemini 可能不再只是回答问题，而是开始长期接管邮件、网页、购买、日程和跨应用任务。

这对效率是好消息，对权限管理则是新挑战。

这对开发者意味着什么

开发者更应该关注两个问题。

第一个问题是工具生态。36Kr 文章提到，社区从模型选择器里看到了 MCP Tool Testing 这类未公开入口。如果 Gemini 原生支持 MCP 或第三方工具测试，那么它会更容易接入开发者自己的工具链。

第二个问题是成本和稳定性。即便新 Gemini 在某些基准上追平 GPT-5.5，开发者最终还是会看三件事：实际代码质量、上下文稳定性、价格和额度是否可预期。

过去一年，AI 编程工具竞争已经证明，模型能力只是门票。真正让开发者留下来的，是能不能在日常项目里持续可靠地改代码、跑测试、读上下文、处理边界条件。

现在应该如何看待这条消息

这条消息适合用“强信号、弱确认”来理解。

强信号在于：多个社区线索都指向 Google 正在准备更强的新 Gemini，以及更主动的 Gemini Spark Agent。

弱确认在于：Gemini 3.5 Pro 还没有官方发布，Cappuccino 仍是爆料代号，所谓“追平 GPT-5.5”的说法也需要等 Google 官方基准、第三方评测和真实用户测试来验证。

所以现在最稳妥的判断是：

不要把它当成已发布产品。
可以把它当成 Google 下一阶段 Gemini 路线的提前预告。
重点关注 I/O 或后续官方活动中是否会确认模型命名、API 可用性、价格、上下文窗口、工具调用和 Agent 权限边界。

总结

Gemini 3.5 Pro / Cappuccino 的曝光说明，Google 可能正在为下一代 Gemini 做一次更强势的版本推进。它要补的不是单一能力，而是整个 AI 工作流：模型要更会写代码、生成界面和处理复杂推理，Spark 则要把 Gemini 推向全天候 Agent。

但在官方发布前，所有跑分和截图都只能作为线索。真正决定 Gemini 3.5 Pro 能否翻身的，不是代号是否好听，而是它能否在真实开发、真实办公和真实多步骤任务里稳定胜出。

参考链接：

Claude Opus 4.7、Sonnet 4.6、Haiku 4.5 有什么区别？Claude 模型选择指南

Fri, 08 May 2026 08:19:03 +0800

Anthropic 的核心大模型主要通过 Claude 系列迭代。到 2026 年 5 月，Claude 的主流产品线已经进入 4.x 阶段，整体仍然延续三档定位：Opus 负责最高能力，Sonnet 负责性能与成本平衡，Haiku 负责速度和性价比。

如果只想快速选型，可以先记住一句话：

最复杂、最重的推理和 agentic coding：优先看 Claude Opus 4.7。
大多数开发、写作、分析和企业 API 场景：从 Claude Sonnet 4.6 开始最稳。
高并发、低延迟、成本敏感任务：考虑 Claude Haiku 4.5。

当前主流模型

根据 Anthropic 官方模型文档，当前 Claude 主流模型可以这样理解。

模型	定位	适合场景
`Claude Opus 4.7`	当前最强的通用可用模型，面向复杂推理和 agentic coding	大型代码库重构、多步骤任务、复杂策略分析、要求更高一致性的工作
`Claude Sonnet 4.6`	速度、能力和成本的平衡点，支持 100 万 token 上下文窗口	代码生成、长文档分析、企业知识工作、Agent 开发、日常高质量生产任务
`Claude Haiku 4.5`	速度最快、成本更低的小模型，但仍有接近前沿模型的能力	实时对话、客服、批量分类、简单代码协作、高并发 API 调用

这里需要注意两个命名细节。

第一，官方名称是 Claude Haiku 4.5，不是 Claude 4.5 Haiku。第二，Claude Mythos Preview 不是普通用户或开发者的主流可用模型，它是 Project Glasswing 相关的受控研究预览，主要面向防御性网络安全工作流，不应和常规 Claude 模型混在一起选型。

Opus：处理最难的问题

Opus 是 Anthropic 给最强模型使用的档位。Claude Opus 4.7 的重点不是便宜，也不是最快，而是更适合处理复杂、多步骤、需要反复校验的任务。

它更适合这些情况：

跨很多文件的大型代码修改。
复杂系统重构和架构推理。
长链路 Agent 任务。
需要更强视觉理解、文档理解和多轮规划的工作。
对错误成本比较敏感的企业分析任务。

如果一个任务失败一次的代价很高，或者你希望模型在开始动手前花更多时间理解上下文，Opus 通常更值得尝试。

Sonnet：多数人的默认起点

Claude Sonnet 4.6 是更适合作为默认入口的模型。它的定位不是“低配 Opus”，而是把足够强的推理、编程、视觉理解、长上下文和 agent planning 放在更可控的成本与速度里。

对开发者来说，Sonnet 4.6 的价值主要在三点：

能处理很长的上下文，适合放入代码库、合同、报告或多篇资料。
在 Claude Code、API 和企业场景中更容易作为常用模型。
成本低于 Opus，更适合高频使用。

如果你不知道该从哪个 Claude 模型开始，通常可以从 Claude Sonnet 4.6 开始。只有在任务明显需要更强能力时，再切到 Opus。

Haiku：快和便宜更重要时

Claude Haiku 4.5 是小模型档位，但不能简单理解成“弱模型”。Anthropic 对它的定位是快速、低成本，同时保留接近前沿模型的能力。

它适合这些场景：

实时聊天和客服机器人。
大量短文本分类。
低延迟 API 调用。
简单代码修改和快速原型。
多 Agent 工作流中的子任务执行。

如果任务本身很清楚、上下文不复杂、需要吞吐量，Haiku 往往比盲目使用更大的模型更合理。

Claude 的工具能力

Claude 系列不只是聊天模型。Anthropic 现在把模型能力放进了多种产品和开发工具里。

Claude Code 是面向开发者的命令行编程工具，可以读取代码库、编辑文件、运行命令和测试，适合持续推进工程任务。它的体验很依赖模型本身的代码理解、上下文管理和工具调用稳定性。

Computer Use 是让模型通过截图、鼠标和键盘操作桌面环境的能力。它仍然需要谨慎使用，官方文档也强调要放在隔离环境中运行，避免误操作或安全风险。

Artifacts 更偏向 Claude 应用侧体验，可以把代码、页面原型、图表或文档结果放在界面中预览和迭代。它不是一个单独模型，而是 Claude 产品形态的一部分。

至于“Managed Agents”或“自我进化 Agent”这类说法，写文章时要谨慎。Anthropic 确实在强化 Agent SDK、Claude Code、长上下文、工具调用和企业工作流，但不要把它描述成已经具备不受控自我进化能力。

访问方式

普通用户可以通过 Claude.ai 网页端或移动端使用 Claude，不同套餐会影响可用模型、额度和功能。

开发者通常有几种接入方式：

Anthropic Console 和 Claude API。
Amazon Bedrock。
Google Cloud Vertex AI。
Microsoft Foundry。

具体可用模型、上下文窗口、价格和地区支持会变化，开发前最好以 Anthropic 官方模型文档和对应云平台页面为准。

怎么选

实际使用时，不需要一开始就追求最强模型。更好的方式是按任务成本分层。

如果是日常写作、代码生成、长文档分析、知识整理和大多数 Agent 原型，先用 Claude Sonnet 4.6。它通常是性价比和通用能力的最佳起点。

如果任务需要更强的复杂推理、跨文件工程修改、长链路规划或更高可靠性，再切到 Claude Opus 4.7。

如果任务简单、数量大、对延迟敏感，例如分类、摘要、客服、批量处理，就把 Claude Haiku 4.5 放进候选。

Claude 的模型线不是单纯的“新版本替代旧版本”，而是一套按任务难度、速度和成本分层的工具箱。选对模型，比盲目使用最贵模型更重要。

参考链接

Anthropic Models Overview：https://platform.claude.com/docs/en/about-claude/models/overview
Introducing Claude Opus 4.7：https://www.anthropic.com/news/claude-opus-4-7
Introducing Claude Sonnet 4.6：https://www.anthropic.com/news/claude-sonnet-4-6
Introducing Claude Haiku 4.5：https://www.anthropic.com/news/claude-haiku-4-5
Anthropic Computer Use Tool：https://docs.anthropic.com/en/docs/build-with-claude/computer-use

GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking 和 GPT-5.5 Pro 有什么区别

Thu, 07 May 2026 21:59:33 +0800

OpenAI 现在把 GPT-5.5 拆成了几个更明确的使用层级：Instant、Thinking 和 Pro。

很多人看到 GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking、GPT-5.5 Pro 会混在一起。简单说：GPT-5.5 是这一代模型能力的总称，Instant 是日常快速模型，Thinking 是深度推理模式，Pro 是更高强度的研究级模式。

快速对比

名称	本质	适合场景	速度/成本	可用性
GPT-5.5	GPT-5.5 主模型/家族名；在 ChatGPT 里通常对应 GPT-5.5 Thinking 的能力定位	复杂工作、代码、研究、分析、工具调用	比 Instant 更重，但能力更强	Plus、Pro、Business、Enterprise
GPT-5.5 Instant	快速默认模型，替代 GPT-5.3 Instant	日常问答、写作、总结、轻量代码、快速查询	最快、最省额度	面向所有 ChatGPT 用户逐步推出
GPT-5.5 Thinking	深度推理模式	难题、长上下文分析、复杂代码、研究、文档密集任务	较慢，但推理更稳	付费用户可手动选择
GPT-5.5 Pro	更高强度的研究级模式	高风险/高精度任务：法律、商业、教育、数据科学、科研分析	最慢、最重，追求质量	Pro、Business、Enterprise、Edu

如果只想记一个选择规则：

日常快速任务：用 GPT-5.5 Instant。
复杂推理和代码分析：用 GPT-5.5 Thinking。
特别难、特别重要、需要更全面严谨：用 GPT-5.5 Pro。

GPT-5.5 是什么

单独说 GPT-5.5 时，通常是在说 GPT-5.5 这一代主模型能力，而不是某一个固定按钮。

OpenAI 对 GPT-5.5 的定位是“面向真实工作的更强模型”。它重点提升的是：

agentic coding；
复杂代码调试；
研究和资料综合；
文档、表格、演示文稿生成；
计算机使用和跨工具工作；
长任务中的持续推理和自我检查。

在 ChatGPT 里，用户看到的不是一个笼统的 GPT-5.5 按钮，而是更具体的 Instant、Thinking、Pro。所以如果有人说“我在用 GPT-5.5”，最好再问一句：是 Instant、Thinking，还是 Pro？

GPT-5.5 Instant：默认、快速、日常使用

GPT-5.5 Instant 是新的快速默认模型。OpenAI 官方说明里，它开始替代 GPT-5.3 Instant，成为 ChatGPT 的默认模型，并在 API 中作为 chat-latest 提供。

它适合这些任务：

日常聊天；
快速问答；
普通写作；
总结文章；
改写邮件；
轻量代码解释；
简单表格和清单；
不需要长时间推理的任务。

Instant 的核心优势是速度和默认可用性。你不需要每次都手动选择推理模式，也不需要为普通问题付出更高延迟。

它还有一个变化：OpenAI 强调 GPT-5.5 Instant 的回答更清晰、更简洁，并且个性化能力更强。对普通用户来说，这意味着它更适合“每天一直开着用”。

需要注意的是，Instant 不是“最强模式”。遇到复杂数学、长代码、架构设计、多文件分析、严肃研究时，它可能会自动切换到 Thinking，也可能需要你手动选择 Thinking。

GPT-5.5 Thinking：复杂任务的主力

GPT-5.5 Thinking 是更适合复杂任务的推理模式。

它适合这些场景：

代码调试；
架构设计；
多步骤推理；
长文档分析；
学术资料整理；
商业方案推演；
数据分析解释；
需要比较、权衡、验证的任务。

Thinking 的特点是会花更多时间推理。OpenAI Help Center 提到，当 GPT-5.5 Thinking 或 GPT-5.5 Pro 开始推理时，可能会先显示一个简短 preamble，说明它打算怎么做。用户也可以在模型还在 thinking 时追加指令，提前调整方向。

在 ChatGPT 里，手动选择 Thinking 时，还可以调整 thinking time。官方说明中，Plus 和 Business 用户可以使用 Standard 和 Extended；Pro 用户还会有 Light 和 Heavy 等更多选项。

我的理解是：Thinking 是“认真干活”的默认选择。只要任务涉及多步骤、长上下文或高准确性要求，就比 Instant 更合适。

GPT-5.5 Pro：研究级、更重、更严谨

GPT-5.5 Pro 是面向更难问题和更高精度工作的模式。

它适合这些场景：

法律材料分析；
商业研究；
教育和课程设计；
数据科学；
科研资料综合；
高风险决策前的深度审阅；
多文档、多约束、多轮验证任务。

OpenAI 在 GPT-5.5 发布说明中提到，早期测试者认为 GPT-5.5 Pro 相比 GPT-5.4 Pro，在完整性、结构性、准确性、相关性和实用性上都有明显提升，尤其在商业、法律、教育和数据科学领域表现更强。

Pro 的缺点也很明显：它更慢、更重，不适合每个小问题都用。它更像“专家审阅/研究伙伴”，而不是日常聊天入口。

另外，Pro 在工具支持上有特殊限制。OpenAI Help Center 写明，Apps、Memory、Canvas 和图像生成不适用于 Pro。如果你的任务需要这些 ChatGPT 功能，可能要用 Instant 或 Thinking。

工具支持有什么不同

根据 OpenAI Help Center，GPT-5.5 Instant 和 GPT-5.5 Thinking 支持 ChatGPT 的常用工具，包括：

Web search；
Data analysis；
Image analysis；
File analysis；
Canvas；
Image generation；
Memory；
Custom Instructions。

GPT-5.5 Pro 更偏研究级推理，但不是所有 ChatGPT 工具都可用。尤其要注意：

Apps 不可用；
Memory 不可用；
Canvas 不可用；
图像生成不可用。

所以选择模型时，不只看“哪个更聪明”，还要看你要用哪些工具。

上下文窗口有什么区别

官方 Help Center 给出的 ChatGPT 上下文窗口说明大致是：

模式	上下文窗口
GPT-5.5 Instant	Free：16K；Plus/Business：32K；Pro/Enterprise：128K
GPT-5.5 Thinking	付费档手动选择时通常为 256K；Pro 档可到 400K

这意味着：

普通聊天和短文档，Instant 足够；
多文件、多轮研究、长代码库分析，Thinking 更合适；
特别长、特别复杂的高精度任务，Pro 用户可以利用更大的上下文和更重推理。

怎么选

日常问答

用 GPT-5.5 Instant。

它速度快，足够聪明，适合随手问、快速写、快速改。

写文章、总结、改邮件

优先用 GPT-5.5 Instant。

如果文章很长、需要结构重写、需要多轮校对，再切到 GPT-5.5 Thinking。

写代码和调试

简单代码解释用 Instant。

多文件调试、架构设计、复杂报错分析，用 Thinking。如果是非常棘手的长期工程问题，可以考虑 Pro。

研究和资料分析

普通资料整理用 Thinking。

如果是法律、商业、科研、数据科学这类高精度任务，用 Pro 更合适。

需要图像生成、Canvas、Memory

优先用 Instant 或 Thinking。

不要默认选 Pro，因为 Pro 不支持部分 ChatGPT 工具。

简短结论

GPT-5.5 Instant 是日常默认模型，快、清晰、省额度，适合多数普通任务。

GPT-5.5 Thinking 是复杂任务主力，适合代码、研究、长文档、分析和多步骤推理。

GPT-5.5 Pro 是高精度研究模式，适合更难、更重要、更需要严谨性的任务，但工具支持和速度都更受限制。

GPT-5.5 本身更像这一代模型的总称。真正选择时，要看你在 ChatGPT 里选的是 Instant、Thinking 还是 Pro。

GPT-5.5 Instant 发布：ChatGPT 默认模型变得更准、更短、更懂你

Thu, 07 May 2026 14:28:40 +0800

OpenAI 在 2026 年 5 月 5 日发布 GPT-5.5 Instant，并开始把它作为 ChatGPT 面向所有用户的默认模型。

这次更新的关键词不是“更大”或“更炫”，而是更贴近日常使用：回答更准确、更简洁，语气更自然，也更会利用用户已经分享过的上下文。对 ChatGPT 来说，默认模型的变化尤其重要，因为它影响的是最多用户每天实际打开就会用到的体验。

默认模型为什么重要

Instant 是 ChatGPT 的日常主力模型。很多用户不会手动切换模型，也不会研究不同模型之间的差异。他们感受到的 ChatGPT，就是默认模型的质量。

所以 GPT-5.5 Instant 的意义不只是新增一个模型名，而是把基础体验整体往前推了一步。OpenAI 在公告中提到，这次更新让日常互动更有用、更顺手：不同主题下的回答更紧凑，聊天语气更自然，也能在合适的时候更好地使用已有上下文。

这种改进看起来不如一次大型多模态发布显眼，但对几亿级用户来说，默认模型少犯错、少啰嗦、少问多余问题，本身就是很大的产品变化。

更少幻觉，更可靠的回答

OpenAI 把准确性放在了第一位。

官方表示，在内部评测中，面对医学、法律、金融等高风险提示词，GPT-5.5 Instant 相比 GPT-5.3 Instant 产生的幻觉声明减少了 52.5%。在用户曾经标记过事实错误、难度更高的对话中，不准确声明减少了 37.3%。

这两个数字值得注意。它们说明 OpenAI 不只是追求模型“会说”，而是继续压低错误事实的发生率。尤其是在医疗、法律、金融这类领域，模型不能只给出流畅答案，还要更谨慎、更少编造。

当然，这不等于用户可以把 ChatGPT 当成专业意见的替代品。更准确的模型仍然需要在高风险场景里保留核查、引用来源和人工判断。但从产品体验看，默认模型的事实可靠性提升，会减少很多日常使用中的误导。

日常任务能力增强

GPT-5.5 Instant 不只是在事实性上改进，也提升了多种日常任务能力。

OpenAI 提到，它在分析照片和图片上传、回答 STEM 问题，以及判断何时使用网页搜索方面都有提升。这里的重点是“判断何时搜索”。很多用户并不关心模型内部是否调用工具，只关心答案是否新、是否准、是否能解释清楚。

如果模型能更好判断哪些问题需要联网，哪些问题可以直接回答，用户就不必反复提醒“你去查一下”。这会让 ChatGPT 更像一个主动可靠的助手，而不是只会等待明确指令的聊天框。

公告中的数学示例也体现了这个方向。GPT-5.5 Instant 在一开始认可错误解法后，能继续检查并发现代数错误，再回到正确方程求解。真正重要的不是它从不出错，而是它更有机会在推理链条中发现问题并修正。

回答更短，但不是变少

OpenAI 还强调，GPT-5.5 Instant 的回答更紧、更直接，同时保留必要内容和 ChatGPT 的友好语气。

这点对默认模型很关键。很多用户对 AI 回答的疲劳感，不来自信息不够，而来自结构太重、铺垫太多、格式太满。一个简单问题被拆成五个小标题、十几条注意事项，反而会让人觉得不自然。

GPT-5.5 Instant 的目标，是减少无谓的冗长和过度格式化，少问不必要的追问，也避免让回答显得杂乱的装饰性内容。对日常办公、写作建议、生活咨询和快速解释来说，这类改进往往比单项基准分更影响体感。

更短不等于更浅。好的默认模型应该能判断用户需要的是一句可执行建议、一段解释，还是完整方案。GPT-5.5 Instant 的方向，就是把这种分寸感做得更稳。

个性化能力继续增强

这次更新的另一条主线，是个性化。

OpenAI 表示，Instant 现在更擅长使用过去聊天、文件以及已连接 Gmail 中的上下文，让回答更贴合用户。它会判断什么时候额外个性化能改善答案，并更快搜索过去对话中的相关内容，减少用户反复交代背景。

这对长期使用 ChatGPT 的人很有价值。比如做计划、写文章、选工具、整理项目、延续一段工作流时，用户往往已经在过去对话里提供过偏好、约束和上下文。如果模型能自然接上，就会减少很多重复说明。

但个性化也必须配合透明度和控制。否则用户会不知道模型为什么突然提到某个偏好，也不知道哪些记忆正在影响回答。

Memory sources：让个性化更可见

OpenAI 同时推出 memory sources，覆盖所有 ChatGPT 模型。

它的作用是让用户看到哪些上下文被用于个性化回答，例如保存的记忆或过去聊天。如果某些内容过期、不准确或不想再被使用，用户可以删除或更正。

OpenAI 还说明，如果用户分享一段聊天，memory sources 不会展示给其他人。用户仍然可以删除不希望被引用的聊天，在设置中修改保存记忆，或使用不会使用和更新记忆的临时聊天。

这一步很重要。AI 助手越个性化，就越需要解释“我是根据什么在回答你”。Memory sources 不一定展示所有影响因素，但至少让个性化从黑箱里走出来一部分。

可用性安排

GPT-5.5 Instant 从公告当天开始向所有 ChatGPT 用户推出，并替代 GPT-5.3 Instant 成为默认模型。在 API 中，对应 chat-latest。

对付费用户来说，GPT-5.3 Instant 还会保留三个月，可通过模型配置设置访问，之后会被退役。

增强个性化功能会先在网页端向 Plus 和 Pro 用户推出，移动端随后上线，并计划在接下来几周扩展到 Free、Go、Business 和 Enterprise。Memory sources 会在网页端向 ChatGPT 消费者计划推出，移动端也会随后跟进。不同地区可用的个性化来源可能会不同。

简短判断

GPT-5.5 Instant 是一次面向默认体验的升级。

它不只是模型能力变强，而是在回答准确性、表达密度、语气、上下文使用和个性化透明度上一起调整。对普通用户来说，最直接的变化应该是：少一点废话，少一点事实错误，更容易接上你的背景。

对 OpenAI 来说，这也是默认助手形态的继续演进。ChatGPT 不再只是“每次从零开始回答问题”的工具，而是在逐步变成能记住偏好、理解上下文、知道何时搜索，并且让用户管理这些记忆来源的长期助手。