端侧小模型：把智能塞进手机
参数少一个数量级，能力却要保住七成——端侧模型做的是「能力密度」的生意，而不是跑分的生意。
一、为什么非要在本地跑
把模型放云端最简单，但有几件事云做不到：没有网络时要能用、延迟要压到几十毫秒、照片和聊天记录不离开设备、每次调用不花钱。手机助手、车机语音、输入法、相机、翻译耳机、机器人，这些场景最终都会落到端侧。
难点也很实在：手机内存通常只有 8～16 GB，还要跟系统抢；持续推理会让设备发烫、掉电；用户对卡顿的容忍度以百毫秒计。所以端侧模型的技术路线和大模型完全不同——量化为 4bit 甚至更低、做成小尺寸 MoE 只激活一部分参数、用投机解码加速，都是常规操作。
二、面壁智能 MiniCPM：把「小」做到极致
面壁智能（OpenBMB）是国内最专注端侧的团队之一，从早年的 2.4B 小模型一路做到现在的 MiniCPM5，官方定位就是「端侧 SOTA、小而强」。它有几条很清晰的产品线：
| 系列 | 能力 | 典型场景 |
|---|---|---|
| MiniCPM5 | 端侧通用语言模型 | 手机助手、离线问答、边缘设备 |
| MiniCPM-V | 端侧多模态（图像/视频理解） | 拍照问答、无障碍、文档理解；OCR 能力是传统强项 |
| MiniCPM-o 4.5 | 端侧全模态（看、听、说） | 离线语音助手、实时对话 |
面壁的开源项目里还有一整套配套工具：iOS / Android / 鸿蒙的离线多模态 App 示例、量化与推理脚本、评测工具。对做硬件的团队来说，这些「能跑起来的 Demo」往往比论文更有用。
它的技术路线值得一提：不做参数最大，而是在数据质量与训练配方上下功夫，让小模型在有限容量里学到更「密集」的知识——所谓「模型能力密度」的说法就是从这里流行起来的。
三、小米 MiMo：从硬件出发做模型
小米的 MiMo 系列是「硬件厂商做模型」的典型样本：模型不一定追求榜单第一，但要和手机、汽车、IoT 设备的算力与场景严丝合缝。目前已公开的方向包括：
- MiMo 系列语言模型：早期以 7B 级推理模型开源，强调在有限参数下把推理能力做扎实；后续通过云平台提供
mimo-v2.5-pro这类 1M 上下文的服务型号。 - MiMo-Audio：音频语言模型，探索「少样本」的语音理解与生成。
- MiMo-Code / 智能体工具：面向开发与自动化场景的编码智能体。
把它和面壁放在一起看很有意思：一家从算法出发往硬件走，一家从硬件出发往算法走，最终都在同一个战场——让模型真正在设备上跑起来。
四、同赛道的其他选手
端侧这条赛道上还有不少选择：Qwen 的 0.6B 到 8B 小尺寸（生态最好、工具最全）、GLM 系列的轻量版本、各家手机厂商的自研助手模型，以及大量基于开源权重自行量化的小模型。实际选型时，建议按「目标设备的可用内存 → 量化位宽 → 首 token 延迟」的顺序倒推，而不是先挑模型。
五、端侧选型的四个硬指标
| 指标 | 怎么判断 |
|---|---|
| 内存占用 | 4bit 量化后模型体积大约等于参数量 × 0.5～0.7 GB，再留 1～2 GB 给 KV 缓存与运行时 |
| 首 token 延迟 | 端侧用户可感知的门槛大约是 300～500 ms，超过就会觉得「卡」 |
| 功耗与发热 | 连续对话 10 分钟机身温度上升多少，比跑分更能反映真实体验 |
| 能力边界 | 小模型不适合做长链推理与知识问答，更适合做意图识别、摘要、抽取、格式转换 |
本页整理于 2026-09，依据 OpenBMB（MiniCPM、MiniCPM-V、MiniCPM-o）与 XiaomiMiMo 开源组织的公开仓库说明，以及云平台上架的 MiMo 服务型号条目。