枢影Kernel

Focus On Android

0%

端侧大模型实测：Gemma 3n 在 Android 上的性能、内存与功耗调优

发表于 分类于
基于 Google 官方 LiteRT-LM 基准与公开第一手实测，拆解 Gemma 3n 在 Android 端侧的性能数据（prefill/decode/TTFT）、MatFormer 与 PLE 内存优化、CPU/GPU/NPU 加速路径的收益与坑，以及功耗与发热控制，给出可复现的调优清单。

上一篇 AI Edge Gallery 架构解析解决了”怎么跑起来”的问题：三层技术栈、模型管理、Function Calling、MCP 集成，每层都有完整源码可复刻。但”能跑起来”和”跑得好”之间还隔着三个工程问题——推理速度够不够用户容忍、内存占用会不会挤压业务进程、连续推理半小时发热降频之后还剩多少可用。这三个问题在 demo 阶段往往被回避，一旦进产品就是阻塞项。

本文聚焦”跑得好”这一半：以 Gemma 3n 为对象，把 Google 官方 LiteRT-LM 基准、Hugging Face 模型卡、GitHub 第一手 field report 和学术界的能效实测汇编成一份带完整环境标签的调优指南。需要说明的是，本文数据来自官方基准与公开的一手实测（设备、量化格式、上下文长度均逐一标注），本文自己的贡献是把散落各处的数据收拢、交叉验证，并提炼出可落地的调优清单——这符合端侧测试报告的第一原则：不带环境标签的性能数字没有意义。

Key Takeaways

  • Gemma 3n E2B 在 Samsung S24 Ultra 上 GPU prefill 816 tok/s（CPU 的 7.4 倍），但 decode GPU 与 CPU 持平（16 tok/s）——decode 是内存带宽瓶颈，"换加速器"主要提速长 prompt，几乎不提速生成。
  • NPU 是能效最优解：ASPLOS 2025 实测 NPU prefill 能耗比 CPU 低 35–59 倍；S24 Ultra 持续推理实测 146.4 mJ/token 约合满电池 42.6 万 token。Gemma3-1B 在 S25 Ultra NPU 上 prefill 5,836 tok/s、decode 85 tok/s，常驻内存为三种路径最低（较 CPU/GPU 路径低约四成，跨设备口径）。
  • GPU 路径有精度坑：Mali-G715 上 fp16 累加缺陷会让 3k token 上下文中的数字静默损坏，短 prompt 冒烟测试测不出来；q4_block128 变体在 GPU 上还会静默输出零 token。
  • MatFormer + PLE 让 E2B 用 1.91B 有效参数跑出 5B 总参模型的质量，但换来的是 2,965 MB 的模型文件——"有效参数 2B"约束的是加速器内存，不是磁盘。
  • Gemma 4 已发布并在官方基准中取代 3n 成为 featured model（S26 Ultra GPU decode 52 tok/s、TTFT 0.3 s），但 3n 仍是学习端侧调优方法的最佳教材。

先把指标说清楚：prefill、decode 和 TTFT 不是一回事

LLM 推理分两个阶段，两者的瓶颈完全不同，混着谈”快慢”是端侧选型最常见的错误。

Prefill（预填充）处理用户输入的整个 prompt，逐 token 并行计算，是 compute-bound（算力瓶颈）——矩阵乘法占主导，算力越强的加速器收益越大。Decode（解码）逐 token 自回归生成，每生成一个 token 都要读一遍全部权重和 KV Cache，是 memory-bound（带宽瓶颈）——瓶颈在内存带宽而非算力。这解释了官方数据里最反直觉的一组数字：Gemma 3n E2B 在 S24 Ultra 上，GPU 把 prefill 从 111 tok/s 拉到 816 tok/s（7.4 倍），但 decode 纹丝不动地停在 16 tok/s。加速器再快，也快不过内存搬运权重的那条总线。

TTFT（Time To First Token）近似等于 prefill 时间加调度开销，决定用户按下发送后看到第一个字的等待感。Decode tok/s 决定后续文字”打字机”的观感——Qualcomm 的工程博客提醒过，人类阅读速度约 4–7 tok/s，语音场景更低，所以 decode 并不是越快越好，能效（每 token 耗电）在多数场景比峰值速度更重要。

本文所有数据遵循同一套口径：prefill/decode 单位为 tok/s，内存为进程 RSS，均标注设备与量化格式。

官方基准：Gemma 3n 在旗舰机上的完整成绩单

Google 在 LiteRT-LM 官方文档（2026-09-04 更新）给出的基准表，是目前最完整的 Gemma 3n Android 数据，模型均为 .litertlm 格式（Gemma-3n-E2B 模型卡、Gemma-3n-E4B 模型卡）：

模型 文件大小 设备 Backend Prefill (tk/s) Decode (tk/s)
Gemma-3n-E2B 2,965 MB Samsung S24 Ultra CPU 111 16
Gemma-3n-E2B 2,965 MB Samsung S24 Ultra GPU 816 16
Gemma-3n-E4B 4,235 MB Samsung S24 Ultra CPU 74 9
Gemma-3n-E4B 4,235 MB Samsung S24 Ultra GPU 548 9
Gemma-3n-E2B 2,965 MB MacBook Pro M3 CPU 233 28

把这张表画出来，”prefill 有 GPU 巨大红利、decode 两者持平”的结构一目了然：

Gemma 3n 在 S24 Ultra 上的 CPU/GPU 性能对比 数据来源 Google LiteRT-LM 官方基准（2026-09-04 更新）：E2B prefill CPU 111、GPU 816 tok/s；E2B decode CPU 16、GPU 16 tok/s；E4B prefill CPU 74、GPU 548 tok/s；E4B decode CPU 9、GPU 9 tok/s。GPU 对 prefill 提升约 7.4 倍，对 decode 无提升。 0 200 400 600 800 111 816 16 16 74 548 E2B · Prefill E2B · Decode E4B · Prefill CPU GPU Prefill 提升约 7.4× Decode 两种 backend 持平（E4B 均为 9，柱体过小省略） 单位：tok/s · 设备：Samsung S24 Ultra · 模型：.litertlm 格式
Gemma 3n 在 S24 Ultra 上的 CPU/GPU 对比。数据来源：Google LiteRT-LM 官方基准表（2026-09-04 更新）；E4B decode 为 9 tok/s，柱体过小省略，精确值见表格

三个可以直接读出的结论：

  1. E2B 是旗舰机型的甜点档。S24 Ultra CPU 路径 16 tok/s 的 decode 已接近”阅读舒适”的下限（Qualcomm 引用的 4–7 tok/s 是静读速度，交互式对话观感上 10+ tok/s 才不显得卡顿）；配合 GPU 的 816 tok/s prefill，2,000 token 的长 prompt 首字约 2.5 秒（2,000 ÷ 816 ≈ 2.45 秒，加调度开销）。
  2. E4B 的 decode 跌到 9 tok/s，交互观感明显劣化。除非业务需要 E4B 的质量增益（E4B 在 LMArena 超过 1300 分，是首个 10B 以下达到该水平的模型，Google 开发者博客，2025-06），否则优先 E2B。
  3. prefill 与 decode 的差距决定了优化的抓手：如果你的产品是”长 prompt、短回答”（文档摘要、翻译、RAG），GPU 加速收益巨大；如果是”短 prompt、长回答”（闲聊、写作流），换加速器没用，要动模型量化与内存布局（下文展开）。

硬件加速路径：CPU、GPU、NPU 各自的收益与坑

GPU：prefill 红利明确，但有两个已知的坑

MediaPipe LLM Inference API（读 .task 格式）与 LiteRT-LM（读 .litertlm 格式）都支持 GPU backend。MediaPipe 侧的配置在官方 sample 中核心就是 preferredBackend 一行：

1
2
3
4
5
6
val options = LlmInference.LlmInferenceOptions.builder()
    .setModelPath("/data/local/tmp/gemma-3n-E2B-it-int4.task")
    .setPreferredBackend("gpu")   // "cpu" 或 "gpu"
    .setMaxTokens(2048)
    .build()
val llm = LlmInference.createFromOptions(context, options)

但 GPU 路径有两个社区已经踩实、官方文档尚未醒目标注的坑。其一来自 Pixel 9 Pro（Mali-G715）上一位开发者的系统性 field report（google-ai-edge/LiteRT-LM #2202，2026-10）：GPU backend 在约 3k token 上下文时出现数字静默损坏——短 prompt 下日期、价格、电话号码逐位正确，同一 prompt 前面拼上 3k token 的无关内容后，输出变成 am2.0.2226 um13:3 Uhr … Telefon +4 1 553388 这样的残缺串。该问题在 MediaPipe 与 LiteRT-LM 两条 GPU 路径均能复现，指向共享 GPU kernel 的 fp16 累加精度缺陷；CPU backend 在约 40 次长生成测试中零复现。更隐蔽的是 q4_block128 量化的 .task 变体在 GPU 上会静默输出零 token（CPU 正常）——没有报错，只有一个空转的推理循环。

这两条经验对测试策略有直接指导意义：GPU 路径的验收必须用接近真实业务长度的长 prompt 跑数字抽取类任务（回显日期、金额、编号），只跑 50 token 短句冒烟测试会把问题放过去——“验收用例如何按有效性分层”这个问题，此前讨论 AI 单元测试金字塔时出现过同款教训。

其二，选择 GPU 初始化要做降级兜底。GPU delegate 在不同 GPU 驱动上的兼容性差异远大于 CPU 路径，直接指定 preferredBackend("gpu") 而不捕获初始化异常，会在部分机型上直接 crash。

NPU：速度与能效的双冠王，代价是兼容性矩阵

NPU 数据来自 Gemma3-1B 模型卡：CPU/GPU 行在 Samsung S24 Ultra 上测得（dynamic_int4 QAT，上下文 2,048），NPU 行在 Samsung S25 Ultra 上测得（a16w4 QAT，128 token prefill chunk / 1,024 tokens）——NPU 数字来自更新一年的机型，跨设备对比只作量级参考：

Backend 设备 Prefill (tk/s) Decode (tk/s) 常驻内存 (RSS) 模型文件
CPU（int4 QAT） S24 Ultra 379 55 1,009 MB 529 MB
GPU（int4 QAT） S24 Ultra 2,531 49 1,205 MB 529 MB
NPU（a16w4 QAT） S25 Ultra 5,836 85 626 MB 689 MB

同一模型上，NPU 的 prefill 比 GPU 快 2.3 倍、比 CPU 快 15 倍，decode 也首次显著拉开（85 vs 49 tok/s），626 MB 的常驻内存是三种路径中最低的（较 S24 Ultra 上的 CPU/GPU 路径低约 38%–48%，注意跨设备口径）。这不是孤例：学术界在 Redmi K60 Pro 上的系统实测（llm.npu，ASPLOS 2025）显示，1,024 token prompt 下 NPU prefill 超过 1,000 tok/s，能耗比 CPU 低 35–59 倍、比 MLC-GPU 低同样量级、比 TFLite-GPU 低 1.9–4.3 倍。Hexagon NPU 以 500–750 MHz 的低频运行是能效优势的直接原因——CPU 满频全核跑 prefill 时功耗最高，NPU 反而最低。

需要说明文件大小口径：上表的 529/689 MB 是模型卡中 int4/a16w4 量化文件的标注大小；下文横评表中的 1,005 MB 是 LiteRT-LM 官方 .litertlm 适配版，两者不是同一文件，不构成矛盾。

把能耗折算成”一块电池能写多少字”更直观：S24 Ultra 上 Gemma 类模型持续推理实测为 146.4 mJ/token（arXiv:2603.23640，熄屏、BatteryManager 口径，未限定单一 backend、作者标注为参考值，作量级参照）。按一块 4,500 mAh × 3.85 V ≈ 62,370 J 的典型旗舰电池估算，这一能效水平约合满电池 42.6 万个 decode token，即每 1% 电量约 4,260 tokens。对需要长时间语音助手/离线 Agent 的产品，这个数字直接决定产品形态是否成立。

那为什么 LiteRT-LM 官方基准表里 Gemma 3n 没有 NPU 数据？兼容性。NPU backend 依赖厂商 NPU SDK（高通 QNN、联发科 NeuroPilot），量化格式、算子覆盖、驱动版本任何一个不匹配都会失败。#2202 field report 还记录了一个更迷惑的现象：engine_create(backend=npu) 初始化失败后约 190 秒，执行静默 fallback 到 GPU（日志先出现 backend=npu create，随后是 backend=gpu create）——你以为在测 NPU，实际在测 GPU。工程结论：NPU 路径必须显式校验运行时 backend，并在不支持机型上干净地降级，而不是依赖隐式 fallback。

Gemma3-1B 三种 backend 的 decode 速度 decode 速度：NPU 85 tok/s（S25 Ultra）、CPU 55 tok/s（S24 Ultra）、GPU 49 tok/s（S24 Ultra）。NPU 同时具备最快 decode 与最低常驻内存（626 MB，见正文表）。 Decode 速度（tok/s） 55 · CPU（S24 Ultra, int4 QAT） 49 · GPU（S24 Ultra, int4 QAT） 85 · NPU（S25 Ultra, a16w4 QAT） 来源：Gemma3-1B 模型卡（CPU/GPU 为 S24 Ultra，NPU 为 S25 Ultra）· 能效对比见正文（arXiv 实测数据）
Gemma3-1B 三种 backend 的 decode 速度对比：NPU 领先且常驻内存最低，代价是机型兼容性矩阵与显式校验成本。速度与内存的 CPU/GPU/NPU 行分别来自 S24 Ultra 与 S25 Ultra（图内已标注），跨设备对比只作量级参考

一个反直觉的补充：GPU 不总是比 CPU 快

Commencis 团队在 Gemma 3n 多模态原型中的实测（Medium 工程博客，2025）值得注意：**冷启动场景下 CPU 推理反而比 GPU 稳定快约 20%**。GPU delegate 初始化涉及 shader 编译与内存布局，首 token 延迟被放大。他们的对策是把模型初始化提前到 Application.onCreate 常驻内存——这比纠结 backend 更有效。如果你的应用是”用户点开就要答”的形态，初始化时机与预热比 backend 选型对 TTFT 的影响更大。

内存调优：MatFormer 与 PLE 的真实含义

Gemma 3n 最核心的端侧创新是让”总参数 5B”的模型以”有效参数 1.91B”运行（Gemma 3n 官方文档），靠的是两件事：

MatFormer（Matryoshka Transformer）：E4B 模型内部嵌套着完整联合训练的 E2B 子模型（E4B 为 35 层、16,384 FFN 维度；E2B 为 30 层、8,192 维度）。推理时只激活子模型，外层参数不参与计算。嵌套结构还允许在 2B–4B 之间拼装任意中间尺寸。

Per-Layer Embeddings（PLE）：每层 transformers 的 embedding 参数不在推理时驻留加速器内存，而是常驻 CPU 内存按需流式供给。结果是加速器（GPU/NPU）侧只加载约 2B/4B 的核心权重，低速大内存充当”外存”。

这个设计的收益在数字上很清晰，但有一个容易误读的点：PLE 约束的是加速器内存，不是磁盘，也不是进程 RSS。E2B 的 .litertlm 文件仍是 2,965 MB——PLE 省的是”必须放进 GPU/NPU 有限显存池”的部分，模型文件本体、KV Cache、运行时 buffer 都还在进程账单里。2GB RAM 的设备跑 E2B 是官方给的最低配置，但那是理论下限；工程上要给系统、业务进程、KV Cache 留余量，实践建议 6–8 GB RAM 起步。

量化格式是另一层内存杠杆，但选择时要把”文件更小”和”GPU 兼容”放在一起权衡：

量化 典型文件大小 备注
dynamic_int4 QAT（.litertlm / .task） Gemma3-1B 529 MB 量化感知训练，官方默认推荐，CPU/GPU 均正常
q4_block128（.task） 更小 GPU 上静默零输出（#2202），仅 CPU 可用
a16w4 QAT Gemma3-1B 689 MB NPU 路径专用（S25 Ultra 实测 85 tok/s decode）

功耗与发热：多数场景该优化的是”每 token 焦耳”而不是”tok/s”

Decode 是带宽瓶颈这一性质，决定了功耗优化的杠杆点与性能优化不同。学术界的能效研究给出了三个可复现的结论：

其一，NPU 低频运行是能效基础。llm.npu 的实测显示 NPU 在 500–750 MHz 下功耗最低而 prefill 反而最快（前文 35–59 倍能耗数据）；S24 Ultra 上 Gemma 类模型的持续推理实测为 146.4 mJ/token（arXiv:2603.23640，BatteryManager 测量、熄屏条件，作者标注为参考值）。

其二，decode 场景可以主动降频。EnerInfer 研究（Qwen2-1.5B 4-bit）显示：NPU 与内存 governor 默认跑满频率追求峰值 tok/s，而把频率降下来可减少 44% 功耗、同时保持 10 tok/s 以上——语音助手场景人类语速远低于此（讲 <3 词/s、听 <5.3 词/s），峰值吞吐纯属浪费。按场景限频而不是默认满频，能效可再提 38%–62%。

其三，热降频是端侧特有的性能悬崖。持续推理 30 分钟量级后，SoC 降频会显著压缩吞吐并放大波动——arXiv:2603.23640 的 S24 Ultra 持续负载实测记录了同趋势：GPU 频率从 1,000 MHz 降至平均 804 MHz，吞吐方差随之扩大（其 20 轮迭代累计耗电 7%）。发布前的压测必须覆盖”满电+室温”之外的持续热态，这正是把”每 token 毫焦”纳入观测的理由。

工程上可执行的功耗清单：

  • 语音助手、离线翻译等”输出速率有人类上限”的场景，给 decode 设目标 tok/s（10–15 即可），用限频换能效；
  • prefill 是高功耗脉冲，长 prompt 应分块（NPU 路径的 128 token prefill chunk 就是这个思路），避免单次大块触发过热；
  • 推理密集期用 BatteryManager 记录电压×电流做回归基线，把”每 token 毫焦”纳入 CI 观测指标。

Gemma 3n 还是 Qwen？同框架下的横向对比

“模型质量”不在本文范围，但同一推理框架下的速度对比数据是现成的，对选型有直接参考价值。仍取 LiteRT-LM 官方基准（均为 .litertlm 格式、官方适配的量化）：

模型 文件大小 设备 CPU Prefill/Decode GPU Prefill/Decode
Gemma-3n-E2B 2,965 MB S24 Ultra 111 / 16 816 / 16
Gemma3-1B 1,005 MB S24 Ultra 177 / 33 1,191 / 24
Qwen2.5-1.5B 1,598 MB S25 Ultra 298 / 34 1,668 / 31
Qwen3-0.6B 586 MB Vivo X300 Pro 165 / 9 580 / 21
Qwen2.5-0.5B 521 MB S24 Ultra 251 / 30 —
phi-4-mini (3.8B) 3,906 MB S24 Ultra 67 / 7 314 / 10
同框架下的 GPU decode 速度横评 GPU decode tok/s：Qwen2.5-1.5B 31（S25 Ultra）、Gemma3-1B 24（S24 Ultra）、Qwen3-0.6B 21（Vivo X300 Pro）、Gemma-3n-E2B 16（S24 Ultra）、phi-4-mini 10（S24 Ultra）。Qwen2.5-1.5B 文件体积约为 Gemma 3n E2B 的 54%，decode 达到其 1.9 倍。 Qwen2.5-1.5B 31 Gemma3-1B 24 Qwen3-0.6B 21 Gemma-3n-E2B 16 phi-4-mini (3.8B) 10 Gemma3-1B 用约 1/3 于 E2B 的体积（1,005 vs 2,965 MB）跑出 24 tok/s GPU decode ——且其 GPU decode（24）反而低于 CPU（33），prefill 1,191 tok/s 补回差距 蓝色为 Gemma 系，绿色为 Qwen 系，紫色为 phi 系 · 数据：LiteRT-LM 官方基准表（2026-09-04），设备以图注标明
GPU decode 速度横评（tok/s）。注意各模型的测试设备不同（Qwen2.5-1.5B 为 S25 Ultra、Qwen3-0.6B 为 Vivo X300 Pro，其余为 S24 Ultra），跨设备数字只作量级参考；同为 S24 Ultra 的 Gemma3-1B 与 Gemma-3n-E2B、phi-4-mini 之间可直接对比

三点选型观察：

  1. 纯文本、预算敏感：Qwen2.5-1.5B 是被低估的选项——1,598 MB 的体积（E2B 的 54%）在 S25 Ultra 上跑出 31 tok/s GPU decode、1,668 tok/s prefill，比 E2B 快近一倍；中文语料的 tokenizer 切分效率也是社区公认的加分项（本文未单独实测）。
  2. 多模态（图像/音频输入）：Gemma 3n 是 LiteRT-LM 官方适配列表中唯一内建完整多模态编码器的选项——该列表其余模型（Qwen 系、phi 系、Gemma3-1B）均标注为纯文本 Chat 类型（官方支持列表，2026-09-04 版）。
  3. 超小内存设备：Qwen3-0.6B（586 MB）适合 4–6 GB RAM 的中端机兜底，但注意它的 decode 只有 9–21 tok/s，交互体验下限，更适合后台批处理（摘要、分类）而非对话。

值得强调的是，这张表里所有模型跑在同一个推理栈上——LiteRT-LM 的适配质量抹平了运行时差异，数据差距基本反映模型架构与量化质量本身。这也意味着从 Gemma 换 Qwen（或反向）在工程上只是换模型文件，运行时代码不变。

可复现的调优清单

把前文结论收拢成上线前的检查表：

初始化

  • 模型加载提前到 Application.onCreate，冷启动 TTFT 的收益远大于 backend 微调（Commencis 实测 CPU 冷启动即快 20%）；
  • 启动时探测 backend 可用性：GPU 初始化异常捕获后降级 CPU；NPU 路径校验运行时真实 backend，防止 npu→gpu 静默 fallback 污染测试数据（#2202）。

Backend 选型

  • 长 prompt 短回答（摘要/RAG/翻译）→ GPU 或 NPU，吃 prefill 红利；
  • 短 prompt 长回答（对话/写作）→ 优先 NPU（decode 与能效双优），无 NPU 则接受 CPU/GPU 的 decode 持平现实；
  • 能效敏感（全天候语音、离线 Agent）→ 只考虑 NPU（prefill 能耗比 CPU 低 35–59 倍）。

测试策略

  • GPU 验收必须含 ≥3k token 的长 prompt 数字抽取用例（日期/金额/编号回显），短句冒烟测不出 fp16 累加缺陷；
  • 回归禁用 q4_block128 量化的 .task 上 GPU；
  • 压测覆盖热态（连续 30 分钟）与不同电量状态，记录降频后的 tok/s 衰减。

内存与功耗

  • “2GB 内存跑 E2B”只对加速器侧成立，进程预算按模型文件 + KV Cache + 运行时全额计算，6–8 GB RAM 起步；
  • 图片输入统一 downscale 到长边 512 px，把多模态 prefill 从分钟级压到秒级（Commencis 实测）；
  • decode 目标 tok/s 按场景封顶（10–15 足够），用 NPU/Mem 限频换 38%–62% 能效。

常见问题

E2B 和 E4B 应该怎么选？

优先 E2B。官方基准中 E4B 的 decode 只有 9 tok/s（E2B 为 16），交互观感明显劣化，且模型文件从 2,965 MB 涨到 4,235 MB；只有在业务确需 E4B 的质量增益（LMArena 超过 1300 分）时才值得付出这个代价。

为什么 GPU 只大幅提速 prefill，几乎不提速 decode？

Prefill 是 compute-bound，GPU 算力直接兑现为吞吐（816 vs 111 tok/s）；decode 是 memory-bound，每生成一个 token 都要把权重和 KV Cache 从内存读一遍，瓶颈在内存带宽而非算力，所以 CPU 与 GPU 都停在 16 tok/s。想提速 decode，路径是换带宽更高的 NPU 或减小模型（如 Gemma3-1B）。

Gemma 3n 有 NPU 官方基准数据吗？

官方 LiteRT-LM 基准表中 Gemma 3n 只给了 CPU/GPU 数据；NPU 路径依赖厂商 NPU SDK（如高通 QNN），量化与算子覆盖决定兼容性。可参考同框架下 Gemma3-1B 的 NPU 实测（S25 Ultra：prefill 5,836 / decode 85 tok/s），并且务必在代码里校验运行时真实 backend，防止静默 fallback 到 GPU 污染数据。

多大内存的手机能跑 Gemma 3n E2B？

官方口径是加速器侧约 1.91B 有效参数、最低 2 GB 内存可运行，但模型文件本身就有 2,965 MB，加上 KV Cache、运行时 buffer 与业务进程，工程上建议 6–8 GB RAM 起步。架构原理（MatFormer 与 PLE）详见 上一篇 AI Edge Gallery 架构解析。

结语：3n 是最好的教材，但下一站已经是 Gemma 4

2026 年 7 月发布的 Gemma 4 技术报告显示，新一代 E2B/E4B 在音频识别（FLEURS 平均 WER 从 3n 的 0.108 降到 0.090）、长上下文（RULER 32k 从 83.0 提升到与 E4B 持平的水平）上全面进步，且官方基准已把 Gemma4-E2B 列为 featured model：S26 Ultra 上 GPU prefill 3,808 tok/s、decode 52 tok/s、TTFT 0.3 秒、峰值内存 676 MB——decode 速度约为 3n E2B 的 3.3 倍。同一代 LiteRT-LM 运行时，3n 的调优方法论全部平移适用。

端侧大模型这条路的工程底牌已经掀开：架构（MatFormer/PLE）解决”装得下”，量化与 backend 解决”跑得动”，限频与分块解决”耗得起”。剩下的功课——把”每 token 毫焦”和”降频后 tok/s”写进监控面板，像对待启动耗时一样对待推理能效——这类可验证的开发流程怎么让 Agent 参与进来，Android Skills 与 CLI 工具链的实践给出了现成模式，也是这个系列下一篇想聊的话题。

（本文数据核验于 2026-10-24：LiteRT-LM 官方基准表 2026-09-04 版、Gemma3-1B 模型卡、LiteRT-LM issue #2202、arXiv:2607.02770 / 2407.05858 / 2603.23640 / 2606.23001、Google 开发者博客与 Commencis 公开实测。全文统计口径：汉字与英文/数字词合计数见署名行，正文含标题与表格、不含 SVG 与元数据。）