Gemma 4带给我的关于设备端AI真实未来的启示，以及我为何要向Seyi道歉
这是一篇提交给Gemma 4挑战赛的作品：写一篇关于Gemma 4
几周前，我泼了一瓢冷水在一个实习生对一种可以在手机上完全运行的强大AI模型的兴奋上。那时我是实习生，现在，我是那个实习生。
让我解释一下 - Seyi是尼日利亚贝尔斯大学的一名机电一体化学生，在我的工作场所实习。他有一天早上兴冲冲地来找我谈论Gemma 4，这是谷歌最新的开放权重语言模型，可以在消费级硬件上完全离线运行。他的眼睛很宽，但我的更窄。我的内心独白大概是这样的：为什么我想从云端访问更强大的模型时，还要降级到本地模型？隐私问题对我来说并不重要。使用限制在我的谷歌一号会员计划上不是个真正的问题，而且离线模型，从定义上来说，是固定在时间里的，仅限于它在训练时知道的内容。
我问：“哪里有好处呢？”
我说出了所有这些话。塞伊点点头，泄了气，回到了他的办公桌。宇宙，就像它经常做的那样，安排了在那一周的晚些时候进行反驳。
我没料到的争论
几天后，我正在浏览 马丁·索特尔的博客 (他是一位电信作者，其著作是我最喜爱的之一)，即使内容远超我的理解范围，我偶尔也会去查看。他发起了一个关于本地运行AI的讨论帖：OpenWebUI 和 RAG 等术语被频繁提及，讨论如何通过外部连接使离线模型更加动态。
我脑海中突然闪过一个想法。我一直在考虑在工作中使用AI处理专业任务，但企业环境并不总是与公共云AI兼容。将专有文件上传到公共模型是一个合理的担忧。在个人设备上运行的一个功能强大的模型，无需连接服务器且不留下数据痕迹，开始听起来不再像是降级，而更像是一种完全不同类别的工具。
后来我看到一条领英动态，是关于Google的Android应用AI Edge Gallery，它让你能直接在手机上运行Gemma 4。不用云服务，不用订阅，数据也不会离开设备。
对我来说这就够了。我心动了。
你的口袋里不止一个聊天机器人
在继续之前，让我快速解释一下AI Edge Gallery上的Gemma 4到底是什么，因为它不仅仅是“一个可以在离线状态下工作的更小ChatGPT。”这种表述低估了这里实际能提供的功能。虽然Gemma 4有四种变体，其中两种轻量到可以在手机上运行：E2B, 针对中端设备进行了速度优化，以及E4B，一款专为配备8GB或更多RAM的现代手机设计的更智能的模型。我使用的是12GB RAM的Google Pixel 8 Pro，所以E4B是我的选择。
The Edge Gallery 应用本身将 Gemma 4 的 E2B 和 E4B 模型的功能组织到不同的工作区中。有带思考模式的 AI 聊天，它实时展示模型的逐步推理过程（一个真正有用的窗口，展示了它是如何得出答案的）。有 Ask Image，它允许模型读取和分析来自您的相机或图库的照片，完全离线。有 Audio Scribe 用于转录和翻译。然后还有 Agent Skills，这个功能占用了我的大部分注意力。
代理技能最好用一个类比来解释。开箱即用的Gemma 4就像一个能进行微妙对话的聪明人。技能是在对话开始前交给这个人的东西，比如计算器、专业参考手册或行为指令集。模型在每个会话开始时读取可用技能菜单，确定哪个技能与你的请求相关，并激活它。定义每个技能的核心文件称为SKILL.md——一个纯文本文件，顶部有一个元数据块（包含名称和触发描述），下方是自由形式的指令（纯文本技能）。无需编码。理论上，任何能清晰写作的人都可以构建自定义AI技能。
“理论上”这个词有点勉强。稍后我们再详细讨论.
我的第一个实验：教Gemma模仿我的写作风格
作为一名撰写电信行业内容的通信专业人士，我运营着一个领英简报Signal Over Noise(信号降噪)，我第一反应是测试一下Gemma模仿我写作风格的能力。不是为了取代我的写作，而是看看一个本地模型能否作为个人写作助手，一个足够了解我的风格，在我提供原始材料让它重塑时真正派上用场的助手。
构建这项技能本身的过程非常有趣。我和Claude一起对我的非AI辅助撰写的文章进行了详细的风格分析，创建了十二个触点，涵盖声音、节奏、结构、开头、类比、词汇、标志性动作等。分析揭示了持续存在的特征：对话式-分析式混合风格、以个人视角作为默认开头、带有尼日利亚背景的流行文化类比、创造的复合词，以及自我意识地跳出叙事的旁白。这个画像成为了SKILL.md 文件 - 我个人、可重复使用、可安装的指令集，理论上可以以文档化的风格重写任何源材料，其校准程度取决于遵循程度.
然后我尝试运行它。值得称赞的是，Gemma 4 对其局限性非常坦诚.
从崩溃、循环并中途放弃的手机中得到的三个教训
第一课：指令占用空间比你想象的更重要
我第一次尝试在E2B和E4B变体上激活我的风格技能时，应用程序立即崩溃了。不是“它给出了一个糟糕的输出。”它反复崩溃。
后来我明白了根本原因在于本地模型在严格的、硬件强制的RAM分配下运行。原始指令文件非常冗长：对所有十二个风格触点的每个遵守级别都有详尽的描述。在模型能处理任何一条用户消息之前，系统必须将其中的所有指令加载到工作内存中。巨大的数据量在引擎甚至无法初始化之前就饱和了手机的RAM分配，导致应用程序无法工作。
修复措施是采用激进的压缩，移除描述性矩阵，仅保留核心原则，将文件大小缩减了大约60%，并将系统级指令控制在内存阈值以下。这起作用了，勉强吧。应用停止崩溃了。
但这也是一个明确的信号：云模型习惯无法迁移到移动硬件。
第二课：结构化指令似乎让小模型困惑？
使用更精简的文件，技能加载成功。但当提示它重写一篇关于5G网络架构的长篇技术文章时，模型什么也没写。它反而生成了这些内容：
<|tool_call>call:run_intent{intent:"dabs-style-rewriter", parameters:{"Source Material": "..."
该模型查看了一个格式化编号步骤、标记输入和结构化架构的指令文件，并得出结论说这不是一个写作角色，而是一个API网关。它试图将数据路由到另一个不存在的应用程序。它没有引导一个作家的声音，而是表现得像一个函数路由器。
解决方案是将整个框架从"步骤和输入"转变为"立即成为这个人。"摆脱程序化结构，转向纯粹的系统指令，从第一行就建立角色设定。模型对被告知应该成为谁的反应远比对被告知按顺序做什么的反应要好得多.
第三课：小模型有工作记忆上限…而且这很明显
使用精简的、以角色为先的技能版本，我终于得到了输出。但它听起来不太像是我，而且它突然在句子中间停止了。据我最好的理解，发生的事情是 上下文耗尽。，也就是说，模型的 working memory（如果你想要技术术语，就是 KV 缓存）被指令文件和我作为源材料提供的包含 700 个单词的 5G 文章的组合完全填满了。由于没有剩余的计算开销来管理，它开始卡顿，输出像 "all the* the*" 这样的排版重复内容，然后达到超时限制并完全停止了。
这是本地移动模型和大型云端LLM之间的根本差距。云模型可以同时容纳数百条复杂规则、密集的技术资料和详尽的创意简报，并产出一种平衡所有这些要素的微妙成果。而一部手机上的40亿参数模型则做不到。差得远呢。这种推理差距并非可以通过软件更新来修补的缺陷；它仅仅是物理和硅片带来的后果。
那么小型本地模型实际上有什么用呢？
这就是改变了我想法的关键，我认为这是一个更有趣的问题...
强迫小型本地模型执行复杂的创意角色复制完全是错误的任务。这就像雇佣一个专业制造者来给你写小说。技能并不是缺失；它们只是分配不当。
本地移动设备真正擅长的是结构化数据、确定性规则和零幻觉的实用工作。它们速度快、私密性好，并且始终可用。问题不是“它们能否复制云模型的创造性输出？”问题在于“哪些任务能从本地、轻量级、始终在线的智能层中受益？”
我想到的一个实际答案是来自我自己的生活。我在家里使用太阳能逆变器设备。管理备用电源意味着要关注云层覆盖情况、电网稳定性以及电池负载，有时我不得不从工作中打电话给我的妻子，让她检查情况并采取相应措施。那么，试试在我的手机上使用一个JavaScript支持的代理技能，它或许能优雅地处理这个问题。
这样操作：JavaScript技能（与之前描述的纯文本技能相对）使AI能够在手机的隐藏浏览器环境中实际执行代码。该模型的工作简化为一件事：捕获用户的自然语言输入，例如社区名称。
然后脚本获取该变量，调用实时天气API，获取实时云量数据，在JS中应用相关电学公式，并返回一个通俗易懂的建议。"打开深冷冰箱。太阳能输出充足。"无需创造性推理，也无需产生幻觉的风险。AI是自然语言接口；代码是引擎。
这种分工，以对话输入作为功能层，以代码作为执行层，在我看来，正是移动AI真正发挥作用的地方.
这对整体格局意味着什么
暂停片刻，思考一下这里实际发生的事情。一个足以理解细微指令、进行有意义的对话并触发适当专业行为的模型，所有这一切都不需要将你的任何数据发送到任何服务器，现在可以放入你口袋中的设备里。
这并非一项小规模的进展。
在云AI受限的环境中，最直接的实用影响最为明显：企业网络、受监管的行业和低连接区域。对于属于这些类别中的任何人来说，在功能强大的安卓手机上使用Gemma 4并不是妥协。它是第一个可行的选项。并且，针对非洲的具体情况，由于数据成本仍然不低，云延迟是一个真正的用户体验问题，因此具备在设备上进行推理的案例比从高带宽的西方基准来看要强得多。
但更有趣的含义是它所暗示的发展方向。我遇到的瓶颈（内存饱和、意图循环、上下文耗尽）是真实存在的，但它们也是被充分理解的工程问题。
模型量化正在取得进步。移动硬件也在提升。编写高效、结构化的技能，利用本地模型的优点而不是对抗其限制的技术是可学习的，并且它们正变得越来越有文档记录。到2026年，基于手机的人工智能能做到什么程度，其底线已经高于大多数人所意识到的。在几年之内，问题将不再是它是否足够有能耐，而是现有的、广泛使用的云模型是否提供了足够的额外价值来证明依赖它的合理性。
我并不是说本地模型会取代云人工智能。那会是一种懒惰的看法，而且我在这篇文章中已经用完了我的懒惰看法配额（参见：Seyi，开篇段落）。我想要说的是，设备端人工智能的角色正在从新奇事物转变为基础设施，从“科技博客上的酷炫演示”转变为为需要将私密、快速和可访问的智能集成到他们工作流程中的人提供的真正实用层。
结尾思考：塞伊是对的
这个实验的轨迹（从怀疑者到谨慎的皈依者）几乎完美地与真正颠覆性技术通常出现的方式相吻合。不是以一种明显、立即可用的用例来证明炒作，而是以一种安静的实际实现积累，最终突然意识到“哦，这实际上是个有用的东西。”
我的风格复制技能没有达到预期效果。模型崩溃了，循环了，并且截断了。但在这些测试中失败，它向我展示了它真正的价值所在，并给了我一个具体的思维模型来构建真正能执行的代理技能。太阳能助手在我的清单上。一个用于工作的RAN架构参考工具也在清单上，一个能接受基站设计输入并根据本地规则私下离线返回设备规格的工具。这些都不是华丽的人工智能应用场景。然而，它们确实是真正有用的场景。
设备端AI并非AI的未来。它是AI融入日常生活的未来——安静、本地化、实用，就像一个好工具应该的那样.
塞伊，如果你在读这篇文章：我欠你一个人情。