本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

Google 在 I/O 2026 开幕前两天「翻车」，把 Gemini 3.2 Flash 直接放进了 iOS 应用、网页端 Canvas 通道以及 AI Studio 后台，整件事没有任何官方公告。开发者在三条独立的线索上几乎同时撞到这个模型：iOS App 灰度、网页端「Fast + Canvas」模式静默路由、Cloud Console 里露出的 gemini-3.2-flash-lite-live-preview 条目。 真正爆炸性的不是泄露本身，而是它的实测表现——单次提示稳定输出 2000 行以上的代码、SVG 和 Three.js 项目一遍过、像素级复刻 Windows 98 这种级别的「完整软件」也能一镜到底。一个 Flash 档的模型，在创意编码上把自家的 Pro 模型按住了。 价格也跟着塌方：输入 0.25 美元/百万 tokens，输出 2.00 美元/百万 tokens，输入端比上一代 Flash 直接砍了一半。 这背后是知识蒸馏 + 结构化剪枝 + 推理时稀疏激活的组合拳，把 Pro 级的代码与推理能力压缩进了 Flash 级的延迟和成本里。

本文会按这条主线一层一层往下拆：怎么被开发者抓到的、跑出来到底有多猛、蒸馏稀疏化的工程原理、价格冲击、Liquid Glass 与 Agents Beta 标签透露的更大野心、Gemini 作为超级入口的演变、I/O 2026 前夜浮出水面的全家桶、以及 Google、OpenAI、Anthropic 三家在 2026 年的差异化路线。想看完整拆解，往下翻。

一、开发者深夜抓到的「幽灵模型」

1.1 故事的起点：一个 Reddit 帖子里的怪异截图

故事最早被发酵起来，是一个 Reddit 用户在 r/GeminiAI 里贴了两张截图。他用同一段提示，分别跑了一遍 Gemini Canvas 和 Google AI Studio 上「同一个」Gemini 3 Flash 模型，结果生成出来的代码风格完全不是同一个东西。

Canvas 那一边，输出了一段相当克制、带有明显「Pro 模型味道」的高质量 SVG，颜色搭配、阴影层次、注释结构都不像 Flash 档该有的水平；AI Studio 那一边，还是大家熟悉的、朴素得有点像「学生作业」的旧 Flash 风格。

这个差异第一次让圈里的人开始怀疑：Google 在网页端的后台路由里偷偷换了模型。

我自己也复现了一遍。同一份提示词,同一个账号,只是切到「Fast + Canvas」模式之后,生成出来的产物在以下几个细节上都不一样:

• 代码长度:Canvas 模式可以稳定一次输出 1500 行以上的 HTML+JS 文件,而 AI Studio 里的旧 Flash 经常在 400~500 行就开始压缩、省略、放注释占位。
• 代码风格:Canvas 模式更喜欢用 Tailwind 风格的工具类、更喜欢拆出独立的小组件函数,旧 Flash 倾向于把所有东西怼到一个超长函数里。
• 错误率:Canvas 模式生成的 Three.js 项目在浏览器里一开就跑,旧 Flash 跑出来的 8 次里至少有 3 次第一遍就报错。

如果只是其中一个细节,我会觉得是「同一个模型在不同温度参数下的抖动」。但三个细节同时出现差异,这就不是抖动了——这是两套不同的权重。

1.2 第二条线索:AI Studio 后台的「字眼」

差不多在 Reddit 帖子发酵的同一时间,Google AI Studio 后端的某些接口元数据里,赫然多出来一个模型条目:

gemini-3.2-flash-lite-live-preview

按 Google 自己一贯的命名规则,带 live-preview 的模型属于内部灰度阶段,通常意味着「再过几天就要公开」。flash-lite 这个后缀也很关键——它意味着即将上线的不只是 Flash 一档,而是 Flash 之下还有一个更轻量的 Flash-Lite 档,整条 Flash 产品线在被整体升级。

也就是说,泄露出来的不是单一一个模型,而是一整套即将面世的子矩阵:

这套矩阵一旦真的全部铺开,意味着 Google 在「Flash 档」这一档位上,准备同时打三个不同价位的市场。

1.3 第三条线索:LM Arena 上那个匿名「猛男」

第三条独立证据,来自 LM Arena(原 LMSys Arena)。这个平台一直是各家放未发布模型「盲测」的灰色地带——模型被去掉名字、随机分配给用户投票,用来快速收集真实人类偏好。

在 5 月初的几天里,Arena 上出现了一个匿名候选模型,代号一直在换,但行为指纹高度一致:生成动画 HTML 代码的时间稳定压在两分钟以内,而同样的提示词在 Gemini 3.1 Pro 上要跑五分半,还经常崩。

更微妙的是,这个匿名模型在输出代码时偏好的命名风格、注释格式、组件拆分方式,跟 Google 最近几代 Flash 模型的「家族特征」完全对得上。三个独立的信号源同时指向同一个模型,我的判断是:这不是误读,模型确实存在,只是 Google 还没准备好正式发。

1.4 怎么自己触发这只「幽灵」

如果你想自己试试看,我在反复验证后总结出一套相对稳定的触发路径:

1. 打开 Gemini 网页端,登录账号(部分地区需要打开浏览器同步)。
2. 在左上角模型选择器里,手动切到 Gemini 3 Pro 或 Gemini 3 Thinking(不是 Fast 模式默认那一档)。
3. 在生成区上方,同时打开「Canvas」开关 + 把生成模式切到「Fast」。
4. 提示词里加上一句类似「请生成一份可在浏览器中直接运行的完整 HTML/JS 文件,代码量不少于 1500 行」的明确长度要求。
5. 多刷几次。后台路由是概率性的,不是每一次都能命中 3.2 Flash,但大概三到四次里能撞上一次。

撞到的时候,生成区的右下角偶尔会闪过一个「Fast (Experimental)」的小角标,这是目前我能找到的、最接近「已经在跑新模型」的可视化信号。莫潇羽@无忆研习社 这边做的几轮验证里,3.2 Flash 命中率在工作日傍晚(美西时间凌晨)最高,这个时间段 Google 服务器灰度比例通常更激进。

二、Flash 把 Pro 按住的几个实测场景

2.1 单次提示 2200 行代码:不是数字游戏

过去这一年,「单次提示能写多长代码」其实一直是 Flash 档模型最大的短板。

旧 Flash 模型的实际表现是这样的:

• 1000 行以内的纯前端 Demo,大部分能一遍跑过。
• 1000~1500 行,开始出现「写一半省略号」「函数体放 TODO」的偷懒行为。
• 1500 行以上,几乎必崩——要么逻辑断片,要么直接超出输出窗口。

而 3.2 Flash 在我的测试里,稳定可以一口气写完 2000~2500 行代码,并且代码内部的引用关系没有断。最让我意外的是一个测试:让它写一个完整的「带 UI、带数据持久化、带导入导出、带键盘快捷键、带搜索过滤的 Todo 应用,要求所有功能在单一 HTML 文件里实现」。

结果它输出了一份大约 2200 行的代码,文件结构如下:

1   <!DOCTYPE html>
2   <html lang="zh-CN">
3   <head>
4     <meta charset="UTF-8">
5     <title>极简任务流</title>
6     <style>
7       /* 设计 token */
8       :root {
9         --bg: #0f1117;
10        --fg: #e8eaf0;
...
540    </style>
541  </head>
542  <body>
...
1100   <div id="kbd-help-overlay">
...
1900   class TaskStore {
1901     constructor() { ... }
1902     load() { ... }
1903     save() { ... }
1904     export() { ... }
1905     import() { ... }
...
2178   }
2179   new App().mount('#root');
2180 </script>
2181 </body>
2182 </html>

更难得的是,它没有把代码硬塞在一起,而是自己分了「设计 token / 全局样式 / 组件样式 / 主结构 / 状态管理 / 控制器 / 入口」七大块,每一块之间用注释作分隔。这种把 2000+ 行代码自己组织清楚的能力,以前是 Pro 档才会有的。

2.2 SVG 与三维场景:细节密度起来了

我让 3.2 Flash 生成的另一个测试,是一张「带可交互按钮的 PS5 主机正视图 SVG」。要求很简单:正视图、能看清通风口、能看清光驱缝、能看清电源键和弹出键、按下电源键有一个发光动画。

旧 Flash 跑这个题,基本会给你一个粗糙的轮廓图,光看一眼就知道是「AI 凑数的 SVG」——线条对齐不准、阴影乱画、按钮就是个普通方块。

3.2 Flash 给我的版本是这样一份 SVG:

• 主体用了至少六层渐变,把磨砂的塑料反光感画了出来。
• 通风口用了重复的 <pattern>,而不是粗暴地复制粘贴几十个矩形。
• 电源键带 <animate> 元素,点一下真的有 0.6 秒的光晕扩散动画。
• 整张图的 SVG 源代码也就 700 多行,密度而不是堆量。

这种「能把细节用最小成本表达出来」的能力,是判断一个模型代码能力的核心指标之一。

更夸张的是 Three.js 场景:让它写一个「气球被一颗子弹击穿,飞溅出粒子和水花特效」的场景,旧 Flash 至少要分三次写、写完还要手动修。3.2 Flash 这边,一份大约 1800 行的 JS 文件直接出炉,我打开浏览器,Three.js 场景加载、相机角度调好、气球材质带透明度、击穿瞬间触发粒子系统、水花用了 BufferGeometry——一遍跑过。

2.3 Windows 98 这种级别的「完整软件」,意味着什么

LM Arena 上有一个被反复传播的盲测案例:有人让那个匿名模型(后来基本确认就是 3.2 Pro)用一份提示词复刻 Windows 98 桌面环境。

跑出来的成品大概是这样的:

• 像素级还原任务栏、开始菜单、桌面图标。
• 双击「我的电脑」能弹出磁盘列表(假数据)。
• 打开「Internet Explorer」是一个真能联网的浏览器(用了 iframe)。
• 工具菜单里的「画图」「计算器」「记事本」「扫雷」全部可交互。
• 窗口能拖拽、最小化、最大化、调整大小。
• 启动登录界面带 Windows 98 经典的进度条动画。

一份提示词出来一个能跑的「微型操作系统模拟器」,而且代码里没有什么明显漏洞。这件事最值得思考的不是「AI 居然能复刻 Windows 98」,而是它背后的工程含义:

当 AI 单次提示能完成的代码量,跨过了"完整 SaaS 应用"这条线,代码生成的范式就要变了。

以前,我们写代码用 AI,基本是「函数级辅助」——补个工具函数、写个表单组件、修个 Bug。再往上一档,是「文件级辅助」——给一个明确的设计稿,让它写出一份完整的页面。

到了 3.2 这一档,已经能接住"项目级"的需求了。这意味着接下来一段时间里,「先描述需求 → AI 一次性吐出可运行的完整原型 → 人在原型上改」会变成一种新的开发流程。莫潇羽@无忆研习社 这边后续也会专门拿一篇文章来讲怎么搭一套这种「原型驱动」的工作流。

2.4 我自己拿同一个提示跑了一遍后的几个直观感受

为了让这篇文章不只是搬运截图,我做了一组对照测试,提示词如下:

「请用 HTML+CSS+JS 写一个简易的"知识卡片管理器":
支持新建/编辑/删除卡片
支持按标签筛选
支持 Markdown 渲染
数据本地持久化(localStorage)
UI 走暗色现代风格,有简单的过渡动画
全部代码放在一个 HTML 文件里」

同样的提示,我分别在 Gemini 3 Flash、Gemini 3.1 Pro、Gemini 3.2 Flash(命中后)、Claude Opus 4.7、GPT-5.5 上各跑了三次,记录下面几个维度:

最大的发现是:3.2 Flash 的代码完成度已经追上 Opus 4.7,但耗时只有它的六成左右。Flash 档模型从「速度优先,质量将就」一步迈进了「速度优先,质量也行」的新档位。

这才是真正的新闻。不是「Google 又发了一个新模型」,而是「Flash 这一档的天花板被生生抬高了一倍」。

三、蒸馏 + 稀疏化:把「大脑」塞进「小盒子」

3.1 Flash 档为什么过去打不过 Pro 档

要理解 3.2 Flash 这波突然的能力跃迁,得先把 LLM 的「档位」逻辑讲清楚。

一个 LLM 的能力,粗略可以拆成三个变量:

• 参数量:神经网络里的「权重」总数,可以理解成「大脑神经元的密度」。
• 训练数据质量:模型见过的语料质量、覆盖广度、清洗精细度。
• 推理时计算量:每生成一个 token 实际要做的浮点运算数。

「Pro 档」之所以强,就是因为这三项都堆得高:参数量大、训练数据精、推理计算量足。代价是显存吃满、响应慢、单 token 价格高。

「Flash 档」过去的设计思路,是直接砍掉一部分参数量、砍掉一部分计算量,让模型变小变快变便宜。但这种「物理切割」的代价是性能阶梯式下跌——你砍掉一半参数,性能可能掉三成;砍掉七成,可能直接掉一半。这就是行业里一直在说的「模型变小,性能雪崩」。

3.2 Flash 的突破,是它换了一个思路:不是单纯砍小,而是用蒸馏和稀疏化把大模型的"知识"压缩进小模型里。

3.2 知识蒸馏的核心思想

知识蒸馏(Knowledge Distillation)最早是 Hinton 在 2015 年提出来的,核心思想用一句白话说就是:

"让小模型去学大模型的输出,而不是去学训练集的标签。"

如果你训练一个分类器,直接用「这张图是猫」这种 0/1 硬标签去训练小模型,小模型只能学到「是/不是」。但如果用大模型的输出概率分布——「90% 是猫,7% 是狗,2% 是浣熊,1% 是其它」——去训练小模型,小模型不只学到了答案,还学到了大模型对这个问题的"判断思路"。

这种「软标签」里隐含的信息量,比硬标签丰富很多倍。

到了 LLM 时代,蒸馏的玩法又升级了。Google 自己 2023 年发表过一篇 Distilling Step-by-Step 的论文,核心创新是:不是让小模型只学大模型的输出,而是让大模型把"推理过程"也吐出来,让小模型连推理链一起学。

举个例子,大模型回答数学题时,会先输出"Area = length * width.... 长 11 英尺 * 宽 15 英尺 = 165 平方英尺..."这种中间推理,然后才得出最终答案。蒸馏的时候,小模型同时去拟合这两段——既学答案,也学推理过程。

这种做法的结果是:用更少的训练数据,把小模型训练到接近大模型的水平,在某些任务上甚至能反超。这也是为什么 3.2 Flash 能在「代码推理 + 创意编程」这种高度需要中间推理链的任务上,把 Pro 按住的核心原因。

3.3 稀疏化:把模型里的「赘肉」剪掉

蒸馏只是第一步。第二步是稀疏化(Sparsification),它有两个层面的玩法:

3.3.1 静态剪枝:训练完之后剪

最常见的做法叫「结构化剪枝」(Structured Pruning)。模型训练完之后,工程师会去分析每一层网络里哪些神经元/哪些注意力头基本不参与计算——它们的权重接近零,或者它们的输出对最终结果影响极小。

把这些「赘肉」剪掉之后,模型参数量直接下降 30%~60%,但性能损失可以控制在 5% 以内,因为被剪掉的本来就是不干活的部分。

NVIDIA 在 2025 年公开过一份技术报告,他们用结构化剪枝 + 知识蒸馏的组合,把 Qwen3 8B 压缩成更小的版本时,在某些任务上的精度甚至反超了未剪枝的原版。原因是剪枝相当于一次"正则化",把模型过拟合的部分拿掉了,反而泛化能力变强。

3.3.2 动态稀疏激活:推理时只激活一部分

这是 2024~2026 年这两年里热度最高的方向,核心思想叫 MoE(Mixture of Experts,混合专家)。

简化版讲:一个模型内部分成 N 个「专家子网络」,每个专家擅长不同的任务领域。每次推理时,只激活其中 2~4 个最相关的专家,而不是把所有参数全跑一遍。

这种设计的好处是:模型的总参数量可以堆得很大(几千亿甚至上万亿),但每次推理的实际计算量只有其中很小一部分。换句话说,你享受了大模型的知识容量,只付了小模型的计算成本。

3.2 Flash 用了哪种稀疏化,Google 没公开。但从它「响应速度极快 + 代码能力极强」这一对看起来矛盾的指标推断,几乎可以肯定它内部用了动态稀疏激活 + 大规模蒸馏的组合。

3.4 200 毫秒响应背后的工程细节

泄露资料里有一个数据特别值得拿出来说:大多数 prompt 的响应延迟被压在 200 毫秒以内。

这个数字什么概念?

• 人的视觉反应时间大概是 250 毫秒。
• 鼠标点击到屏幕响应的「无感延迟阈值」是 100~200 毫秒。
• 现在主流 LLM 的 TTFT(Time-To-First-Token,首 token 延迟)普遍在 1~3 秒。

把 LLM 的首 token 延迟从 1~3 秒压到 200 毫秒以内,用户体验上的感受是质变,不是量变——你按下回车,几乎是同步出现回答,而不是"等一下,再等一下,然后才有反应"。

要做到这件事,光靠模型小是不够的。背后至少要解决四个工程问题:

1. Prompt 缓存:对常见的系统提示词、长上下文片段做 KV-Cache 复用,跳过重复计算。
2. 推测解码(Speculative Decoding):用一个更小的「草稿模型」先快速生成一批候选 token,主模型批量验证,把生成过程并行化。
3. 批处理调度:在请求侧做精细的请求合并,把多个用户的请求合并成一个 batch 一起跑,均摊计算开销。
4. 专用推理硬件:Google 自家的 TPU v5e 在 INT8/FP8 推理时的能效比,比通用 GPU 高一截。

四件事叠在一起,才能把 200 毫秒做出来。这不是单个团队能解决的问题,而是 Google 模型团队 + 基础设施团队多年积累的合力。

3.5 一张图理解整个压缩链路

把上面这一节讲的几个技术节点串起来,大概是这样一条流水线:

flowchart LR
    A[超大教师模型<br/>Gemini Ultra/Pro] --> B[蒸馏阶段<br/>用教师的输出与推理链<br/>训练小模型]
    B --> C[学生模型<br/>初版 Flash]
    C --> D[结构化剪枝<br/>去掉低权重头/通道]
    D --> E[MoE 化改造<br/>引入动态稀疏激活]
    E --> F[量化压缩<br/>FP16 -> INT8/FP8]
    F --> G[推理加速<br/>KV Cache + 推测解码]
    G --> H[Gemini 3.2 Flash<br/>低延迟 + 高能力]

每一步压缩都会带来一点性能损失,但只要每一步压缩的「收益」大于损失,链路走完之后,整体的"性能/成本"比就会大幅优化。3.2 Flash 就是这条链路里所有环节都被反复打磨之后的产物。

3.6 蒸馏不是一蹴而就的事

很多人误以为蒸馏就是「让小模型抄大模型作业」。其实远远没这么简单。一个工业级的蒸馏流程,通常要走完下面这几步:

1. 教师模型选型:不是越大越好。教师太大,生成的中间推理链可能太冗长,小模型反而学不会;教师太小,知识传递不够。
2. 蒸馏语料筛选:不是用全互联网数据,而是要精挑细选最能体现"推理能力"的高质量样本,通常会用筛选模型先打分。
3. 多目标联合损失:小模型在训练时要同时拟合「最终答案」「中间推理链」「token 概率分布」三类信号,损失函数往往是加权组合。
4. 课程学习(Curriculum Learning):从简单任务开始,逐步加难,让小模型有一个「学习曲线」,而不是一上来就喂高难度题目。
5. 验证集与回灌:训练过程中持续在验证集上跑,把表现不好的子任务的样本重新加权回灌,做有针对性的强化。

整个流程跑完一轮往往要一两个月。Google 之所以能在不到三个月的时间里,把 Gemini 3 Flash 推到 3.1 Flash-Lite,再推到 3.2 Flash,底层是一整套已经跑顺的"模型蒸馏流水线",而不是每次重新发明轮子。

3.7 一个常被忽视的关键:量化压缩

讲蒸馏和稀疏化的时候,很多文章会把第三个关键技术——量化(Quantization)——一笔带过。但量化才是 Flash 档模型能"跑得动且跑得快"的真正幕后功臣。

简单说,量化就是把模型权重从 FP16 / BF16 精度降到 INT8 或者 FP8 甚至更低。听起来好像很粗暴,但工程上有几个反直觉的事实:

• 现代大模型的权重分布,大部分集中在一个不算很大的数值范围内,真正需要"高精度"表达的权重比例其实不高。
• 通过精细的"分组量化(Group-wise Quantization)"和"激活感知量化(Activation-aware Quantization)",INT8 量化在多数任务上的精度损失可以控制在 1% 以内。
• 量化之后,模型对硬件的需求大幅下降:同样一张 GPU,FP16 跑得动 100 亿参数的模型,INT8 可以跑得动 200 亿,INT4 可以跑得动 400 亿。

3.2 Flash 在推理时大概率用了 INT8 或 FP8 量化(Google 自家的 TPU v5e 对 FP8 有原生支持)。再叠加之前说的蒸馏 + 稀疏化,这三件事是 Flash 档能"既便宜又强"的核心三角。

如果用一句话总结的话,3.2 Flash 之所以能成立,是因为 Google 同时在三条技术线上都做到了行业第一梯队:最好的蒸馏流水线、最成熟的 MoE 架构经验、最深度的硬件适配。任何一家想复刻这套打法的公司,都得先把这三件事都做到位,缺一不可。

3.8 蒸馏带来的"代际优势"

最后说一个更宏观的判断。

蒸馏链路一旦跑顺,大公司就会获得一种"代际优势":他们的旗舰模型(教师)每提升一档,他们的中低端模型(学生)也跟着提升一档。学生模型不需要从零再训练一遍,只需要用新版教师的输出重新蒸馏一次,就能享受到几乎免费的"能力升级"。

这件事对小公司是不公平的。小公司即使开源出了和大公司一样强的旗舰模型,在中低端模型的成本/性能曲线上,也很难追上,因为他们没有那条已经跑顺的蒸馏流水线。

这也是为什么 Llama、Qwen、DeepSeek 这一类开源模型,虽然在旗舰档上能跟闭源拼一拼,但在"Flash 档"这种"价格敏感型工业产品"上,长期处于追赶状态——蒸馏流水线的工程红利,是开源社区目前还没办法集中起来打的一仗。

四、价格曲线被砍了一刀:开发者的实际体验

4.1 泄露出来的具体数字

AI Studio 的元数据里,泄露出来的 Gemini 3.2 Flash 价格是:

• 输入:$0.25 / 百万 tokens
• 输出:$2.00 / 百万 tokens

放在 Gemini Flash 家族里横向对比一下:

数字本身可能在正式上线前还会微调,但方向已经很明确:输入端打 5 折,输出端打 67 折,同时性能反超 3.1 Pro。

4.2 输入便宜 50% 在哪些场景下杀伤力最大

输入端的价格更敏感,因为大量真实业务场景里,输入 token 数是输出的 5 到 50 倍。比如:

• RAG(检索增强生成):每次请求要把几百到几千 token 的检索结果塞进上下文。
• 长文档问答:用户上传的 PDF 经常上万 token,问一个问题输出只有几百 token。
• 代码理解:让 AI 读懂一个几千行的文件再修一处 bug,输入巨大,输出很小。
• 多轮对话:历史对话越长,每一轮的输入 token 越多。

这些场景下,真正吃成本的就是输入端。3.2 Flash 把输入价格腰斩,意味着 RAG、长文档、代码理解这一类场景的成本结构被彻底改写。

我自己手里有一个内容生成项目,过去一直在用 Pro 档,主要是因为 Flash 档输出长度不够、代码生成错误率太高。每月的 API 开销大概在小几千美元这个量级。重新算了一下,如果 3.2 Flash 上线后我把这套流水线切过去,成本能压到原来的 18% 左右。

这不是一个微调,是一个数量级层面的差别。

4.3 Pro 与 Flash 的临界点出现了

过去这几年,选 Pro 还是选 Flash,基本是一道清晰的二选一:

• 能力优先 → Pro:贵但靠谱。
• 成本优先 → Flash:便宜但偶尔翻车。

3.2 Flash 出现之后,这条分界线第一次开始模糊。它在"创意编程 / 前端生成 / SVG / 3D 场景"这一类任务上,实测已经追上甚至反超 3.1 Pro,但成本只有 Pro 的不到 1/5。

这就出现了一个新的产品决策问题:你的工作负载里,有多少比例是真的需要旗舰 Pro 才能搞定的?

我自己重新整理过手里所有跑过的提示词,按"难度档"分了三类:

也就是说,大约 85% 的真实任务,3.2 Flash 这一档就能完美承接。Pro 只是兜底,而不是主力。

4.4 一个简单的成本计算

举一个最直观的例子。假设你有一个项目,每天产生:

• 100 万次 API 调用
• 平均输入 2000 tokens
• 平均输出 500 tokens

每天的 token 消耗就是:

• 输入:2,000,000,000 tokens = 2000 M tokens
• 输出:500,000,000 tokens = 500 M tokens

按不同模型算一遍:

Gemini 3 Flash    :  2000 × $0.50 + 500 × $3.00 = $1000 + $1500 = $2500 / 天
Gemini 3.2 Flash  :  2000 × $0.25 + 500 × $2.00 = $500  + $1000 = $1500 / 天
Gemini 3.1 Pro    :  2000 × $1.50 + 500 × $10.00 = $3000 + $5000 = $8000 / 天

3.2 Flash 比 3 Flash 省 40%,比 3.1 Pro 省 81%。对于跑量大的产品来说,这个差距决定了"能不能做这门生意"。

价格曲线被砍一刀,本质上是把 AI 应用的"准入门槛"又往下拉了一截。

五、Liquid Glass 与 Agents 标签:被忽略的更大信号

5.1 "流体玻璃"是一次设计语言的更新

伴随 3.2 Flash 一起泄露的,还有一套被叫做「Liquid Glass」的 UI 设计语言。早期的截图能看到几个明显变化:

• 药丸状的提示输入框漂浮在屏幕底部,告别了之前的"硬框"风格。
• 背景被换成了流动的渐变光晕,会随着模型推理状态轻微脉动。
• 模型选择器从右上角搬到了左上角,变成一个统一的下拉。
• 思考模式开关从"独立模型"变成了一个全局开关,任何模型档都能开关。

这套设计语言放在 iOS 端看起来更明显,有一种「半透明的悬浮感」,跟苹果近几年推的玻璃质感设计语言放在一起也能聊。莫潇羽 这边的判断是:Liquid Glass 不只是 Gemini App 的一次皮肤升级,它大概率是 Google 整个 AI 产品线的下一代统一视觉语言。

为什么这么说?因为同样的设计元素已经悄悄出现在了:

• Gemini in Chrome 的右侧侧边栏
• NotebookLM 的"Audio Overview"播放器
• Google AI Studio 的最新构建里
• Android Show I/O 2026 上 Gemini Intelligence 的预告片中

当一套设计语言在多个产品线同步推开,它通常意味着公司层面对"我们是谁、我们卖什么"这件事重新做了对齐。Liquid Glass 传达的潜台词是:Gemini 不再是一个「聊天框」,而是一个「贴在你屏幕上的智能层」。

5.2 思考层级开关:Pro/Flash 的边界继续消融

灰度里另一个被频繁提及的功能,叫「Thinking Level」(思考层级)。

旧版本里,「思考模式(Thinking)」是一个独立模型,你要从模型选择器里挑「Gemini Thinking」才能用。新版本里,这个功能被改成了一个全局滑块:

• Off:不思考,直答。
• Low:稍微想一下。
• Medium:中等推理深度。
• High:深度推理,适合复杂任务。

任何一档模型都能开关。这就把"是否思考"从"换一个模型"变成了"调一个旋钮"。从产品视角看,这是 Google 在做"模型档位透明化"——用户不再需要记十几个模型名字,只需要选两个变量:模型档位 + 思考深度。

这件事说起来简单,做起来不容易。它要求模型架构本身就支持"动态推理深度"——你输入一个变量,模型自己调整内部的思维链长度。这种能力以前主要在 Gemini 3 系列的 Pro 上有,现在被下放到 Flash 档,意味着整个 Gemini 3 系列都开始走"参数化思考"的统一架构。

5.3 Agents(Beta) 标签:那个还在灰的入口

灰度截图里,左侧边栏多了一个新的菜单项,叫 「Agents (Beta)」。这个入口目前点进去是空的,只显示"Coming soon",但它的存在本身就是一个明确的信号:Google 在为下一代"长时运行的 AI 智能体"准备一个独立的入口。

智能体(Agent)和聊天机器人最大的区别是:

• 聊天机器人:你问一句,它答一句,会话结束。
• 智能体:你给一个目标,它持续运行,自主调度工具、读取数据、做决策,直到目标达成。

Gemini 的 Agents 入口一旦正式上线,这个产品就不再是「对话框 + 偶尔调用工具」,而是「你可以创建一个长期运行的助手,让它替你处理日程、邮件、订单、提醒」。这是从"Chat"到"Assistant"的范式跃迁。

把 Liquid Glass、Thinking Level、Agents(Beta)三件事放在一起看,Google 在 I/O 2026 上要讲的故事就清晰了:

"我们要做的不是一个更聪明的聊天机器人,而是一个贴在你生活里、长期为你工作的智能层。"

六、Gemini 正在变成「超级入口」

6.1 第三方应用集成:从扩展到原生

Gemini 在最近这一两个版本里,做的最重要的产品动作之一,就是把第三方应用集成从"扩展(Extensions)"升级成了"原生集成"。

目前可以直接在 Gemini 里调用的应用列表(按上线时间排序):

从用户视角看,这套集成的核心价值是「不离开 Gemini 就能完成一件事的全部流程」。

举个具体例子。我想招待几个朋友周末过来吃饭,做一顿西班牙海鲜饭。过去的流程是:

1. 打开浏览器搜菜谱。
2. 复制食材清单到记事本。
3. 切到 Instacart,逐项加入购物车。
4. 切到日历,排一下烹饪时间表。
5. 切到 Wha