端侧智能爆火之后，为何模型反而不是主角了？

楔子

写这篇文章的起因，是前段儿时间，身边有一位同事经常跟我炫耀他的 iPhone 可以通过 macOS 的"iPhone 镜像"功能，在上班时间用办公电脑摸鱼玩儿手机。

然后我刚好又在 GitHub 上看到了一个有趣的小项目------phone-harness ^[1] 。

这个开源小项目的开发者直接用 macOS 的"iPhone 镜像"来当传输层------系统截图和 Vision OCR 当 Agent 的眼睛，CGEvents 模拟的点击、拖动和键盘输入当手，通过（Mac 上的）Agent 来控制手机，实现了智能化摸鱼。

比如你被同事叫去讨论问题的时候，你电脑上的 Agent 还可以接替你来继续玩儿手机，大幅提升了摸鱼效率。

phone-harness 这个项目的核心代码只有几百行，至于模型本身，目前还只能跑在 Mac 侧。虽然 phone-harness 这项目暂时还没有涉及到苹果这边最先进的端侧模型 Foundation Models，但至少能让大家看到一个趋势： Agent 正在从终端里快速往外走，走到了汽车、机器人、手机、家里的边缘盒子等等有状态的设备里。

欢迎大家关注 OceanBase 社区公众号 "老纪的技术唠嗑局"。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~

大模型 & 小设备

10 美元芯片 & 2890 万参数

7 月下旬，还有一个开源项目 esp32-ai ^[2] 把 2890 万参数的语言模型跑到了 ESP32-S3 上。据项目实验结果 ^[3] ，实测约 9.88 token/s。

ESP32-S3 常见于几十块人民币的开发板，因为它只有 512KB SRAM、8MB PSRAM 和 16MB Flash。

这个开源项目的做法是：把模型拆开------2890 万参数里，大约 2500 万被做成查找表，放在 Flash 中；真正承担主要计算的稠密核心只有约 55.9 万参数。

模型每生成一个 token，只从 Flash 里读取几百字节的相关表项，不用把整套权重搬进 SRAM。

所以，它确实"装下了 2890 万参数"，但不能理解成 ESP32 得到了一个袖珍版通用大模型。这个模型在 TinyStories 上训练之后，能写上几篇儿童故事。

虽然我目前完全脱离了儿童故事的阶段（已经只看漫画了），但这个实验对我来说，依然很有意义。因为它证明了------ 只要重新安排计算、存储和数据移动，语言生成可以下沉到过去完全不在讨论范围内的廉价芯片上。

我个人理解，微控制器也不必非得变成一个缩小版聊天机器人，才算 AI。

例如让 ESP32 替我来写这篇公众号文章，实际没有多大的必要性（因为我用 Codex），但如果它在地下室断网时仍能告诉你"水泵声音不对"，然后让传感器把异常监控转化成一段儿可读描述，或者几句用于修复异常问题的短指令，也许就非常 NB 了。而且这类任务的边界很窄，正好适合一块便宜、低功耗、可以长期开机的芯片。

端侧模型开始学习适应设备

除了 ESP32 这种超小的"专用"模型，各大科技公司也纷纷发布了很多更通用的端侧模型。

例如今年 6 月公布的第三代 Apple Foundation Models ^[4] ，就有一个 200 亿参数的稀疏端侧模型 AFM 3 Core Advanced。完整模型放在 NAND 中，每次根据请求按需选择一部分信息加载进 DRAM，实际激活规模大约在 10 亿到 40 亿参数之间。

Google 最近也发布了 Gemma 3n ^[5] ------一款认真考虑过普通开发者的端侧模型。它面向手机、平板和笔记本，支持文本、图片、音频和视频，也能离线运行。E4B 有约 40 亿活跃参数，里面还嵌着一个约 20 亿活跃参数的 E2B 子模型，设备可以在效果、延迟和内存之间换挡。

这里的 E2B、E4B 说的是有效参数规模，Google 的玩法和苹果有异曲同工之处：把较小的子模型嵌进较大的模型里，资源紧张时用子模型，需要更高质量时再用完整模型。 端侧模型，已经开始像软件一样去适应设备了。

30B 模型的内存账单

除此以外，Meta 也放出了 Muse Glimmer ^[6] ------一个约 296 亿参数、面向 Agent 任务的开放权重多模态模型。官方提供的 4-bit 量化版本中，文本模型约 16.8GB；再加上约 1.4GB 的视觉编码器和约 1.6GB 的 DFlash 推测解码模型，整套大约占 20GB，目标硬件是 24GB 显存的 GPU，也可以跑在高内存的 Apple Silicon 设备上。

Muse Glimmer 的做法是：带一位约 1.6GB 的 DFlash"草稿员"，草稿模型一次提出一小段候选 token，主模型并行验收，猜对的直接留下，猜错的再改。

我们如果把这几件事摆在一起看，会发现"端侧模型"已经不是一个尺寸。ESP32 上住的是极小、极专用的语言能力；手机和平板开始承接数十亿活跃参数的多模态模型；再往上，配有大内存的 Mac 和消费级显卡，已经开始接待 30B 左右的 Agent 模型。

这么看的话，之前看似吹牛的"30B Agent 塞进消费级设备"这句话正在快速成为现实。（不过"消费级设备"暂时只包含 RTX 3080、4090 一类的显卡，或者内存足够大的 Mac。这个定义，对于大家的"消费能力"还是比较乐观的......）

最后多提一句：本地 Agent 不只需要给主模型留位置，视觉编码器、草稿模型、上下文、KV Cache（特别是这个，没那么容易压缩，可能会持续增长），全都要吃同一份内存预算。所以，能把 30B 模型放进 24GB 的显卡里，其实就已经很极限了。

一道面试题

端侧模型在生成 token 时，会把之前 token 的 Key 和 Value 留在 KV Cache 里。后面每生成一步，都可以直接使用这些结果，不必从头重算。它是推理加速的功臣，也是长任务里的显存消费者，因为 KV Cache 会随着上下文一路增长。

NVIDIA 的论文 kv-cache-compression-and-its-infra-problems ^[7] 给过一个例子：4-bit 的 Qwen3-32B 跑在 24GB GPU 上，大约生成到 2.4 万个 token 时，就可能因为显存不足停下来。

既然注意力很稀疏，那么只保留重要 token，删掉其余 90%，为什么 VRAM 会几乎不降？（前几天摸鱼时，刚好也看到 Akshay Pachaar 在 X 上 ^[8] ，把这个问题出成了一道面试题来考大家）

其实问题和模型无关，是内存管理器导致的。vLLM 一类推理系统使用 Paged Attention ^[9] ，把 KV Cache 放进固定大小的物理块。一个物理块通常容纳大约 16 个 token，只有整块都空了，分配器才会把显存收回来。

现在假设 16000 个 token 分布在约 1000 个物理块里。压缩算法删掉其中 14400 个，只留下 1600 个重要 token。数字上已经清掉九成，可如果这 1600 个幸存者恰好散落在原来的 1000 个块里，几乎每个块都还坐着一个钉子户。

很多论文里常见的"节省 90% KV Cache"，有时算的是逻辑上删掉了多少条目，或者是在一块预先分配的连续 Tensor 上做测量。但生产推理引擎面对的却是物理块、并发请求和已经运行起来的内存分配器。

上下文 & 长期记忆

前面这道"面试题"其实挺有意思，因为它提醒我们： token 数量下降，不代表物理内存能下降。 换个角度看这个问题，一定程度上也可以反映出： 上下文能被压缩，不代表 Agent 能获得更多记忆（或者说长期记忆）。

KV Cache 本质是一次推理的工作缓存。任务结束、进程重启或者模型切换，它就理应被释放。如果强行通过上下文压缩，来给 KV Cache 安排长期记忆的职责，本身也不太人道。

一个能长期工作的 Agent，至少要把眼前的推理缓存、尚未完成的任务状态，以及跨任务复用的长期记忆分开。 三者偶尔会互相传递信息，但不能混为一谈。

不出门的抽屉

Agent 的记忆，应该是近水楼台。

记忆层为什么要靠近 Agent?

在端侧模型越来越亲民之后，Agent 的记忆层就有了一个很自然的位置：离 Agent 的行动现场近一点的位置。

对于 phone-harness，就是运行模型和控制逻辑的 Mac。对于汽车或机器人，它可能是座舱 SoC、边缘 Linux 主机，或者设备旁边的应用计算盒子。

这时最合适的记忆存储形式，应该就是： 轻量化，甚至支持嵌入式形态的多模态数据库 。

嵌入式的价值不只是少网络请求的开销。数据库和 Agent 在同一台机器上，还可以大幅简化部署和运维的开销。

OceanBase 在对外宣传时，很喜欢说"一体化"这三个字，嵌入式在一定程度上，也可以理解为一体化。一体化具体是什么，一两句话说不清，那就直接偷懒不说了。不过一体化的好处，用 OceanBase AI 湖库研发负责人竹翁老师最朴素的说法，就是：精简技术栈，高效好运维。

存储/召回 & seekdb

Agent 的记忆层需要支持多模态的原因是：Agent 找记忆时很少只靠一种搜索。它一般会先按 user_id 、应用版本和时间范围筛选，再用全文搜索找"无糖"，最后用向量相似度召回"不要太甜"这一类语义接近的表达。

结构化条件、关键词和向量检索放在同一条查询链路里，比从三个系统各拿一份结果，再通过额外的程序进行归并要更快更省。

这个超级轻量，支持嵌入式形态的多模态数据库，就是我们团队正在持续开发的一个项目------seekdb ^[10] 瞄准的方向。

seekdb 同时支持服务器模式和嵌入式模式，只需要 1C + 0.5G 的资源（马上发布的版本会把 0.5G 继续降为 0.2G），支持 pip install 一键安装、秒级启动。
嵌入式模式可以作为 Python / JS / TS 的动态库，直接运行在应用程序内部，不需要独立数据库进程，无需单独维护数据库服务。
同时塞进去了向量检索、全文搜索、JSON、GIS------一个引擎全包，完全兼容 MySQL 语法，学习成本极低。