Google DeepMind 面向 AI 智能体的三款新模型

如果要浓缩成一句话，那就是： 用 Gemini 3.5 Flash-Lite 做廉价的第一道路由，用 Gemini 3.6 Flash 承担主要的智能体工作，需要在自己的系统上运行时选 Gemma 4。

以下是简要版本。文章从对 AI 智能体最重要的几个维度比较了三款模型：延迟、成本、工具调用、多模态输入、规划能力和部署控制。一款为高并发分诊而生，一款适合日常执行，还有一款面向自托管和私有工作负载。

最让我印象深刻的几点：

• Gemini 3.5 Flash-Lite 是用于分类、抽取和路由的低成本流量分发器，延迟低于 200 ms
• Gemini 3.6 Flash 居中，是工具调用、文档处理和工作流步骤的主力，延迟约 ~500 ms
• Gemma 4 把取舍转向开放权重、Apache 2.0 许可、本地部署和私有数据处理
• Gemma 4 的参数规模从 2.3B 到 31B，上下文最高 256K
• 26B A4B MoE 版本在推理时激活 25.2B 参数中的 3.8B
• 分层架构可以让简单任务留在小模型上、把困难情况交给大模型，从而降低开支

如果你想快速决策：
路由选 Flash-Lite，执行选 Flash，自托管控制选 Gemma 4。

Google 的 3.6 Flash 证明 AI 智能体即将变得廉价

快速对比

换句话说，这不是要挑出一个"最好"的模型，而是借助统一 LLM API 让每款模型各司其职，使你的智能体架构保持快速、成本可控，并在需要的地方掌握控制权。

1. Gemini 3.6 Flash

智能体工作负载适配

三款模型中，Gemini 3.6 Flash 是吞吐量优先的选项。把它用于需要低延迟、稳定成本和快速周转的高并发智能体。

延迟与吞吐量

这使它非常适合工单分诊、文档检索或大规模任务路由这类请求密集的流程。在这些场景中，当模型还需要以稳定可靠的方式执行操作时，速度才最关键。

工具调用与定制化

你可以把它与函数调用、检索、策略检查和人工审批环节搭配使用，让自动化保持在受控范围内。举例来说，它很适合这样一个智能体：读取请求、拉取源文档、调用工具，并把边界情况转给人工。

接下来，Gemini 3.5 Flash-Lite 把取舍转向更轻量、更低成本的智能体任务。

2. Gemini 3.5 Flash-Lite

智能体工作负载适配

Gemini 3.5 Flash-Lite 是高并发分类、抽取和路由的默认低成本模型。可以把它看作智能体架构中的轻量控制层：它承接大部分流量，更大的模型只在棘手情况下出手。

延迟与吞吐量

低于 200 ms 的延迟让它非常适合扇出式工作流、批处理和快速路由。当智能体系统把一个大任务拆成许多小任务时，Flash-Lite 可以快速清掉这些子任务，再把结果传回去汇总。

成本与部署模型

低成本使它成为大批量简单任务队列的默认第一道模型。如果部署控制和开放权重比这套配置更重要，Gemma 4 会改变这个取舍。

工具调用与定制化

Flash-Lite 支持结构化输出，以及面向路由和抽取的轻量任务微调。一个常见模式很简单：让 Flash-Lite 做第一道分类器或抽取器，只把边界情况发给更强的模型。这样，更大的智能体就能把重型模型留给规划、多模态推理和疑难异常。

3. Gemma 4

智能体工作负载适配

Gemma 4 是控制优先的选择，适合需要本地运行、处理敏感数据且易于调优的智能体架构。它的 Apache 2.0 许可允许团队在本地系统上微调和部署，契合有严格数据治理规则的受监管或离线场景。它还能在数据离开本地系统之前于入口处对 PII 脱敏，这对医疗和金融团队很实用 ^[1]。

这很重要，因为本地控制不只关乎隐私，还关乎你能对模型做多少调优、它在哪里运行、能承载什么样的工作负载。对 Gemma 4 来说，这归结为模型规模、上下文窗口和运行时成本。

延迟与吞吐量

Gemma 4 覆盖从 2.3B 移动端模型到 31B 服务器模型的范围。这让团队可以让模型匹配任务，而不是强迫一个模型包办一切。小模型可以处理边缘任务，大模型可以承担规划或长上下文推理。

26B A4B MoE 变体在这里很突出。推理时它只激活 25.2B 参数中的 3.8B，有助于保持运行时效率。在上下文长度上，较小的模型支持 128K token，而 12B、26B A4B 和 31B 模型支持 256K token。这非常适合长文档和长智能体轨迹 ^[1]。

成本与部署模型

在自己的硬件上运行 Gemma 4 省去了按 token 计费的 API 费用，但账单不会消失，而是转移到服务器、扩容和可用性上。所以你不再付钱给提供商，而是为模型背后的整套基础设施买单。

Gemma 4 还提供了几种削减内存占用的方式。量化感知训练（QAT）检查点提供 GGUF、移动端优化的 wNa8o8 和 Compressed Tensors w4a16 格式。这些可以降低内存需求，同时让输出质量接近 bfloat16 ^[1]。

这套配置使该模型非常适合智能体需要本地控制和结构化执行、且团队准备好管理随之而来的基础设施的场景。

工具调用与定制化

Gemma 4 支持原生函数调用和原生 system 角色，让智能体开发者对对话流程和任务执行拥有更直接的控制 ^[1]。它还兼容 transformers、vLLM 和 llama.cpp ^[1]，可以顺利嵌入许多团队已在使用的技术栈。

Unified 12B 变体可以直接接收图像和音频输入。这对需要在文本、图像和音频输入上共用一条微调路径的多模态智能体很有用 ^[1]。

Gemma 4 还内置了"思考"模式。它对更难的任务有帮助，但会增加延迟。直白地说：把它用于规划和复杂推理，而不是快速路由 ^[1]。所以说，Gemma 4 虽然全力押注控制权，但这种控制伴随着基础设施要求和一些速度上的取舍。

取舍、集成选项与优缺点

如果把这几款模型当作一个架构来看，它们相当清晰地分成三种职责：分诊、执行和本地控制。

所以核心决策不只是_哪款模型最好_，而是你想让一个模型包办一切，还是采用分层架构、让每款模型承担它最擅长的部分。

分层架构通常最适合复杂的企业级智能体。Flash-Lite 可以用最低的延迟和成本承接高并发分诊和路由。Gemini 3.6 Flash 可以处理核心工作流执行、工具调用和长上下文工作。Gemma 4 适合需要自托管或私有云部署的受监管或私有工作负载。

这样使用时，相比把每个请求都发给一个更高能力的模型，团队可以实实在在地削减成本。到了这一步，取舍就变成了：部署控制 vs. 运维简单性。

对于文本推理之外的图像或视频生成，APIMart 可以通过一个多模态 API 统一路由任务。

下表总结了主要的集成路径。

在实践中，这些取舍指向一个相当简单的选择：用一个模型从头跑到尾，还是把路由、执行和私有工作负载拆分到不同层。

结论

选对模型归结为三件事：任务复杂度、预算和部署控制。

从这个视角看，Gemini 3.5 Flash-Lite 是轻量路由的首选。它很适合高并发的路由和抽取工作。把它用于分类、抽取和第一道路由。如果任务需要更多协调，就升级到 Gemini 3.6 Flash。

Gemini 3.6 Flash 是生产智能体的默认执行层。它介于 Flash-Lite 的更低成本和 Gemma 4 的控制优先部署之间，对于想要规模化稳定输出的团队来说是可靠的默认选项。如果部署控制最重要，Gemma 4 就成了更好的选择。

Gemma 4 为需要控制权、隐私或离线能力的团队而生。它支持端侧或自托管处理以及本地 PII 脱敏，因此契合受监管环境。它的开放权重也让领域微调更简单。

路由用 Flash-Lite，执行用 Gemini 3.6 Flash，自托管控制用 Gemma 4。

常见问题

什么时候应该采用分层模型架构？

当应用规模增长、你需要在性能、成本和可靠性之间取得平衡时，就该采用分层模型架构。

基本思路是这样的：把简单的高并发任务发给低成本模型，把前沿模型留给复杂的高风险工作。

这种分流可以削减 60% 到 80% 的 API 成本，尤其是当你只在轻量模型未达到置信度阈值后才升级请求时。

这是一笔相当简单的账。你不需要最先进的模型去处理每个日常任务。让轻量模型先上，只在任务真正需要时才请出重型模型。

Gemini 3.6 Flash 和 Gemma 4 之间怎么选？

根据你最看重什么来选择：速度、规模还是控制权。

Gemini 3.6 Flash 是为低延迟、高并发任务打造的高性能多模态模型。这使它非常适合实时应用和成本敏感的工作流。

Gemma 4 更适合想要更多控制权和灵活性的情况，比如本地部署或在自己的基础设施上运行模型。快速、可扩展的生产环境选 Gemini 3.6 Flash；私有、端侧使用或定制微调选 Gemma 4。

哪些智能体任务最适合 Flash-Lite？

Flash-Lite 适合高并发、成本敏感、效率比深度推理更重要的工作。它在基础数据抽取和分类上表现尤其出色。

它作为模型级联的第一层也很好用。在许多配置中，它可以先处理 70% 到 85% 的请求，再把更棘手的查询发给高端模型。这可以削减 60% 到 75% 的成本，同时让标准智能体工作流保持稳定。