谷歌版两门「小钢炮」开源！2.7亿参数干翻SOTA
谷歌这波像开了「大小号双修」：前脚用 Gemini 把大模型战场搅翻，后脚甩出两位端侧「师兄弟」：一个走复古硬核架构回归，一个专职教 AI「别光会聊，赶紧去干活」。手机里的智能体中枢，要开始卷起来了。
谷歌是真的底蕴深厚啊～
刚刚在 「大模型」 领域用 Gemini 3 Pro➕Flash 重挫了 OpenAI 锐气后，马不停蹄继续在端侧 「小模型」 发力！
昨天夜里，一口气又放出新的两个技术博客，全是和端侧相关的。
一个是 T5Gemma 2，一个专门的底层架构创新，首个多模态长上下文码器-解码器模型开源，最小是 270M–270M。
另一个是 FunctionGemma， 专为函数调用优化的 270M （ 2.7 亿参数 ） 模型，可在手机、浏览器及其他设备上运行。
T5Gemma 2 和 FunctionGemma 都来自 Gemma 3 家族，相对于 Gemini 这种「大模型」，Gemma 就是「小模型」。
这两个虽然都是小模型，但是他们的关系有点类似 同门师兄弟，但专攻方向不同 。
T5Gemma 2 专注于 架构效率与多模态 （Encoder-Decoder 架构回归）。
而 FunctionGemma 专注于 智能体与工具使用 （Function Calling 能力）。
T5Gemma 2 和现在流行的 LLM 的架构不同，可以理解为 AI 技术领域「另一条路」。
论文地址： https://arxiv.org/ pdf/2512.14856
谷歌开源了 T5Gemma 2： 270M–270M、1B–1B 以及 4B–4B 三种规模的预训练模型。
开源地址： https://huggingface.co/ collections / google/t5gemma-2
FunctionGemma 则是技能变体， 它是对模型「技能」的专项训练。
有点类似把一个大模型里所有知识类的能力都剥离掉，只保留针对性的函数调用功能。
开源地址： https://blog.google/technology/developers/functiongemma/
T5Gemma 系列深层技术解析
先看下 T5Gemma 2 这种「新结构」的优势：
强大的多模态性能 ：在多个基准测试中超越谷歌自己的 Gemma 3。
全面提升的通用能力 ：在代码、推理和多语言等任务上，T5Gemma 2 整体上优于对应规模的 Gemma 3 模型。
卓越的长上下文能力： 相较于 Gemma 3 和第一代 T5Gemma，在生成质量上取得了显著提升。
与 T5Gemma 类似，T5Gemma 2 在预训练阶段的性能 或超过 Gemma 3 对应体量模型 ，而在 后训练阶段则取得了显著更优的表现 。
左右滑动查看 
想要理解为什么谷歌要搞 T5Gemma，就需要看看目前大模型技术路线演变的 核心脉络 。
T5Gemma 算得上是大模型领域的「古典主义复兴」。
在当今 GPT、Llama 等 Decoder-only（仅解码器）架构占主导的时代 ，T5Gemma 2 是对经典 Transformer 架构中 Encoder-Decoder（编码器-解码器）路线的回归与现代化改造。
我们现在熟知的 GPT、Gemini、DeepSeek 都是 Decoder-only（仅解码器）架构。
GPT 系列 （ OpenAI ） ： 从 GPT-1 到现在的 GPT-4o，全是 Decoder-only。
DeepSeek： 无论是 DeepSeek-V2 还是最新的 V3，核心都是 Decoder-only（结合了 MoE 混合专家技术）。
Llama （ Meta ） ： 它是目前开源界 Decoder-only 的标杆。
Gemini （ 谷歌 ） ：主线模型（Pro / Flash）主要是 Decoder-only。
目前叫得上名字的、用来「聊天」的超级模型，几乎 清一色全是 Decoder-only 。
为什么说 T5Gemma 2 是「回归」？
这就要说到 Transformer 的分家史。
要理解「回归」，得先看它们当初是怎么「分家」的。
2017 年谷歌发布《Attention Is All You Need》论文提出 Transformer 时， 祖师爷原本是 Encoder-Decoder（编码器-解码器）全套架构 。
但后来，家族分成了三个流派：
流派 A：Encoder-only（只用编码器）
代表人物： BERT 。
特长： 只能「读」，不能「写」。它极其擅长做选择题、分类、情感分析，但你让它写作文，它憋不出来。
流派 B：Decoder-only（只用解码器）
代表人物：GPT 。
特长： 只能「猜下一个字」。虽然它看上文不如 Encoder 那么全面（只能看左边，不能看右边），但它天生会说话，而且人们发现 只要把这玩意儿做得足够大，它居然产生了智能（涌现） 。
也就是「意外的」开启了我们这个 AI 时代（笑。
流派 C：Encoder-Decoder（全套保留）
代表人物：T5 （ 谷歌 ） ，BART 。
特长： 既能读又能写。也就是现在的 T5Gemma 2 所在的流派。
T5 的全称是 Text-to-Text Transfer Transformer，连着 5 个 T，所以叫 T5。
那为什么 Decoder-only（GPT 流派）后来一统天下了？
训练简单粗暴： 只需要把网上的海量文字扔进去，让它不停预测下一个字就行（自监督学习）。
上限极高： 也就是 Scaling Law（缩放定律）。人们发现 Decoder-only 模型越做越大，智商提升得最明显，而且工程上更容易堆算力。
Encoder-Decoder 被冷落： 因为它结构复杂（有两套参数），训练起来比 Decoder-only 稍微麻烦点，且在做超大模型（千亿参数）时，性价比似乎不如纯 Decoder 那么极致。
所以也只有财大气粗的谷歌能有精力回归这个经典模型，继续投入搞研发。
谷歌在全世界都疯狂卷 Decoder-only 的时候，突然杀了个回马枪。
既然 Decoder-only 这么强，为什么要改回 Encoder-Decoder？
因为谷歌发现了 Decoder-only 的几个死穴，而这些死穴正好是 Encoder-Decoder 的强项：
「幻觉」问题（瞎编）：
Decoder-only （ GPT ）
是边写边想，有时候写嗨了就收不住，容易一本正经胡说八道。
Encoder-Decoder （ T5 ）
是「先读懂（Encoder）-再动笔（Decoder）」 。
Encoder 会强迫模型先把你的输入彻底消化一遍，生成一个完整的「中心思想向量」，然后再让 Decoder 翻译出来。
这种机制 天生更严谨，幻觉更少。
在多模态方面的天然优势：
你要让模型看图，Encoder（编码器）是最好的「眼睛」。
T5Gemma 2 可以直接把图像信号喂给 Encoder，这比强行塞给 Decoder-only 处理要顺畅得多。
端侧效率（手机上跑）：
在手机这种算力有限的地方，如果你只是做翻译、摘要、指令执行，Encoder-Decoder 往往能用 更少的参数（更小的显存） 达到和巨大 Decoder-only 模型一样的效果。
T5Gemma 2 的出现，不是要推翻 GPT，而是 在特定领域（比如手机端、翻译、工具调用、严谨推理）复兴了 Encoder-Decoder 架构 。
谷歌并未从零开始训练 T5Gemma，而是采用了一种被称为「模型适配」（Model Adaptation）的高效技术。
该技术的核心在于利用已经过数万亿标记训练的 Gemma 2 或 Gemma 3 解码器模型作为种子，将其权重映射到新的编码器-解码器结构中。
这种做法极大地降低了计算成本，同时让模型能够继承原有的语言理解能力。
FunctionGemma：智能体的专用大脑
如果 T5Gemma 是从底层架构的创新，那么 FunctionGemma 就是从功能实现上的创新。
FunctionGemma 是为了解决大模型落地中最痛的点 ——「不仅要能聊，还要能干活」而设计的。
FunctionCalling （ 函数调用 ） ：普通模型在被要求「定个闹钟」或「查天气」时，往往只能瞎编。FunctionGemma 经过专门的微调，能够精准地输出结构化的数据（如 JSON），去调用外部的 API 或工具。
Agent （ 智能体 ） 优化 ：它是为 AIAgent 设计的，擅长多步骤推理和执行任务。
极致轻量化 ：这意味它可以直接跑在手机、甚至更低功耗的边缘设备上，作为系统的「控制中枢」。
适用场景 ：手机语音助手、家庭自动化控制、端侧 AI Agent、API 调度中心。
FunctionGemma 并非仅仅是 Gemma 家族的一个「缩小版」，而是一个专门设计的「神经路由器」，旨在解决云端大模型在延迟、隐私和成本上的固有缺陷。
从对话到行动的范式跃迁
在过去的一年中，大语言模型（LLM）的发展主要集中在提升模型的对话能力、知识广度以及多模态理解力上。
然而，随着应用场景的深入，开发者社区最迫切的需求已从「能聊天的 AI」转向「能干活的 AI」。
这种从「对话式接口」向「主动体」的转变，要求模型不仅要理解自然语言，还要能精准地操作软件接口、执行多步工作流并与物理世界交互。
FunctionGemma 的推出正是为了响应这一需求。
作为 Gemma 3 家族中最小的成员，它抛弃了通用知识的广度，换取了对函数调用（Function Calling）这一特定任务的极致优化。
这种「特种兵」式的模型设计思路，代表了 AI 工程化的一个新方向：即通过模型的小型化和专业化，将智能下沉至网络的边缘 —— 用户的手机、IoT 设备乃至浏览器中。
FunctionGemma 之所以能在极小的参数规模下实现高性能的函数调用，依赖于其独特的架构设计和训练策略。
它不是通过简单的压缩得到的，而是基于 Gemma 3 架构进行了针对性的「压缩」，专注于句法结构的精确性和逻辑判断的确定性。
FunctionGemma 拥有 2.7 亿（270M）参数。
在当今动辄数千亿参数的模型时代， 这一数字显得微不足道 ，连「大模型」零头都不到，但其设计哲学却极具颠覆性。
通常模型的推理能力随着参数量的增加而涌现（Scaling Laws）。
然而，FunctionGemma 打破了这一常规，证明了在特定领域（Domain-Specific），小模型可以通过高质量数据的微调达到甚至超越大模型的表现。
虽然官方未披露具体的蒸馏细节， 但 270M 的规模暗示了大量的通用世界知识被剔除。
模型不再需要知道「法国的首都是哪里」或「莎士比亚的生平」，它只需要知道如何解析 JSON、如何匹配函数签名以及如何处理参数类型。
发力移动端
「在手机上能运行吗？」这是用户最关心的问题。
答案不仅是肯定的，而且 FunctionGemma 正是为此而生。
在移动设备上，随机存取存储器（RAM）是最宝贵的资源。
Android 系统的低内存查杀机制会毫不留情地关闭占用内存过大的后台进程。
FunctionGemma 270M 在 FP16 精度下的权重大小约为 540 MB 。
对于拥有 8GB 或 12GB 内存、甚至 24GB 的现代 Android 旗舰机，这仅占总内存的 5%-7%，完全可以在后台常驻。
Int8/Int4（量化） ：为了进一步降低功耗和内存占用，端侧部署通常使用量化技术。
Int8 量化 ：模型大小降至约 270 MB 。
Int4 量化 ：模型大小降至约 135 MB 。
这意味着它可以在入门级设备甚至嵌入式设备上流畅运行。
谷歌为何要发布这样一个「小」模型？
这背后隐藏着其对未来 AI 计算架构的深刻思考，以及在移动操作系统控制权争夺战中的防御性布局。
这是 FunctionGemma 最核心的战略价值。
在当前的 AI 应用中，将所有请求都发送到云端大模型既昂贵又缓慢。
移动互联网的下一个阶段
移动互联网的下一个阶段是 意图驱动 （Intent-Driven） 的。
意图驱动 （Intent-Driven），用户不再通过点击图标打开 App，而是直接表达意图。
现状 ：Siri 和谷歌 Assistant，以及类似手机助手长期以来受限于硬编码的指令集，只能通过特定接口调用 App 的有限功能。
FunctionGemma 通过让模型直接学习 App 的 API 定义，FunctionGemma 试图让 AI 成为通用的 UI。
开发者只需要暴露工具（Tools），FunctionGemma 就能理解并操作这些工具。
谷歌的野心是 通过开源 FunctionGemma，谷歌实际上是在制定一套 AI 与 App 交互的标准协议 。
如果所有 Android 开发者都按照 FunctionGemma 的格式定义工具，那么谷歌的 Android 系统将成为世界上最强大的智能体平台，进一步加深其护城河。
为了验证 FunctionGemma 的能力，谷歌提供了两个典型的参考实现，展示了其在游戏和系统控制领域的潜力。
场景描述 ：用户用自然语言发出指令，模型将其转换为 Android 系统意图。
技术细节 ：
多参数提取 ：用户说「给 John 发邮件说我迟到了」，模型提取 recipient="John"，body=" 我迟到了 "，action="send_email"。
歧义处理 ：如果用户只说「发邮件」，模型可能会调用 ask_clarification 函数，反问用户「发给谁？」。这种多轮对话能力是硬编码助手无法比拟的。
性能对比 ：经微调的 FunctionGemma 在此任务上的准确率达到 85%，远超未微调的基座模型（58%）。这证明了在端侧垂直领域，小模型完全可以替代大模型。