看到“2B”这两个字先别往歪处想在 AI 圈子里它指的是 2 Billion也就是 20 亿参数。20 亿参数的小模型能干啥我之前也怀疑直到真把一个 1.5B 级别的模型量化到 INT4 塞进手机做出了一个离线版“查账助手”随口说一句“昨天中午和同事吃饭花了 86”它自动归类记账想查“上个月交通花了多少”直接打字问几秒钟返回具体数字。全程不联网账单流水也没离开手机。这个项目特别适合三类人看一是在做端侧 AI 应用的开发者二是想给个人财务数据留点隐私的记账党三是想了解“小模型 工具调用”落地套路的产品经理。下面我把整个踩坑过程掰开揉碎讲一遍。1. 为什么非要把模型塞进手机而不是继续用云上大模型1.1 云上大模型做查账的三个硬伤先说结论用云端大模型做“查账”不是不行但体验和隐私都很难受。第一个是延迟。查账这个动作天然需要“秒回”尤其是语音记账场景你说完“打车 23 块”之后如果 APP 要转圈两三秒才响应基本就废了。云端大模型一次请求包含网络上行、排队、推理、下行再怎么优化也得一秒钟上下对于高频、碎片化的记账场景非常劝退。第二个是隐私。银行流水、消费习惯、每天几点在哪买了什么这都属于极度敏感的财务数据。把这些数据包在 HTTP 请求里送到云端哪怕对方承诺“不留存”心理上也过不去。个人用户可能还能忍但如果你想把这套能力做成小商户的收银辅助工具店主们一听“数据要上传”基本就直接拒绝了。第三个是成本。虽然现在 API 价格一直在降但长期记账产生的 token 量并不小。每天记 5 笔账、每周做一次汇总分析一个月下来怎么也要几百万 token个人用户不会愿意为记账这类低频工具持续付费。把模型压到 20 亿参数并运行在手机本地以上三个问题全部消失延迟取决于手机芯片一般 1 秒内能出结果数据完全不出设备推理不花钱只在开发阶段有成本。1.2 20 亿参数为什么够用很多人有个误区觉得参数越大越聪明20 亿参数连小学生的水平都不如。但这里要区分“通用智能”和“窄任务能力”。查账本质上是三件事的组合信息抽取、分类、格式化成结构化数据再加上一个简单的多轮对话路由。这类任务根本不需要“写诗”级别的语言能力更不需要渊博的世界知识。它需要的是模型能听懂一句大白话抓出金额、类别、日期、备注然后输出一段非常规范的 JSON。现在的 1.5B~2.4B 中文小模型在这类窄任务上的表现其实非常能打。我在测试集上跑过用 Qwen2.5-1.5B-Instruct 做账单实体抽取和分类准确率能到 95% 以上。真正让它写一篇 800 字的消费分析报告它写出来的东西确实比较空但这不是查账的核心需求。另外小模型还有个隐性优势它在手机上跑得快、发热低、内存占用小。一个 1.5B 模型 INT4 量化后体积只有 1GB 左右运行时的峰值内存约 2GB现在的手机完全可以承受。1.3 关键设计查账不是让模型“算”而是让模型“接线”这里我要强调一个容易被新手搞错的核心思路不要让大模型自己做算术也不要让大模型自己查数据库。你如果直接问模型“这个月交通费一共多少”它很可能会给你编一个数字——因为它在训练时见过太多“估算”场景习惯性开始“编”。正确做法是把模型当成一个“意图解析器 参数提取器”真正查数和算数交给 SQLite 和代码来完成。用户问“这个月交通花了多少”模型要做的是识别出两件事意图是“查金额汇总”参数是“分类交通、时间本月”。然后由程序拼接 SQL去数据库里查出结果再把结果包装成一句话返回给用户。这个架构下的模型不需要会算术只需要“听得懂人话、抽得出参数”。20 亿参数的小模型正好在这个点上性价比最高。2. 模型选型和压缩从候选名单到装机实测2.1 我试过的几款候选模型在小模型这个圈子里候选者其实不少。我前后测了四款分别说下感受。模型参数量中文能力工具调用端侧推理我的结论Qwen2.5-1.5B-Instruct1.5B很好好很快首选MiniCPM-2.4B2.4B很好中等较快备选体积略大Llama-3.2-1B1B较弱中等很快中文不太行Phi-3-mini3.8B一般弱慢太胖放弃Qwen2.5-1.5B 胜出的原因主要有三点中文训练数据充足财务术语和口语化表达都认识指令遵循能力在小模型里属于第一梯队给它一条复杂的系统提示词能老老实实执行配合 GGUF 量化后体积和速度都很理想。MiniCPM-2.4B 其实是更强的模型中文能力和复杂对话能力都更好但 2.4B 的 INT4 体积接近 1.4GB运行内存峰值也更高一些在中低端机型上压力大。如果你的目标设备是 3000 元以上的手机选它体验会更好如果要做下沉覆盖Qwen2.5-1.5B 更稳。2.2 量化不是无脑 INT4混合量化更靠谱模型选完之后接下来最重要的就是压缩。20 亿参数的 FP16 模型体积大约 3.2GB直接塞进手机会占掉大量存储而且 FP16 在内存带宽有限的手机上推理速度会很慢。我用 llama.cpp 的量化工具将模型转成 GGUF 格式主要对比了 q4_k_m 和 q4_0 两种量化方案。q4_k_m 是“混合量化”embedding 层和 attention 的输出层保留较高精度矩阵乘部分用 4-bitq4_0 则是全局 4-bit更小但精度损失更大。实测 20 条测试数据里q4_0 有三条出现分类错误q4_k_m 只错一条。所以最终我选了体积稍大一点点的 q4_k_m——它比 q4_0 只大几十 MB准确率却明显提升。注意量化不是越小越好。对于端侧任务4-bit 是甜点位3-bit 或 2-bit 会导致幻觉率大幅上升尤其是 JSON 输出这种对格式要求极高的场景经常输出一半就断了。不要为了省一两百 MB 牺牲稳定性。剪枝方面我试过结构化剪枝把 FFN 层的一些神经元裁掉压缩比不高但微调成本很高。对于 20 亿参数这种小模型直接拿来量化再用 LoRA 做指令微调是投入产出比最高的方案。2.3 手机端的内存与算力估算很多人担心手机跑不动我给出一个估算模型大家心里有个数。20 亿参数 INT4 量化后权重文件约 1.08GB。推理时的 KV Cache 也很关键假设上下文长度设为 2048KV Cache 大约占用 200~400MB。再加上中间激活值、临时缓冲区整体峰值内存约 1.8~2.2GB。也就是说8GB 内存的手机完全能跑运行期间还有富余即使是 6GB 内存的机器只要系统优化得当也能跑起来但后台 App 可能面临被杀的风险。算力方面关键指标是“每秒能生成多少个 token”。正常的中文句子大约每个字对应 1~2 个 token。在高通骁龙 8 Gen 2 上1.5B 模型 q4_k_m 约能跑到 35 tok/s中端的骁龙 7 系列也能跑到 12~18 tok/s。记一笔账只需要生成 30~50 个 token所以即便中端机1 秒内出结果也没问题。3. 手机端查账功能的四层架构拆解3.1 第一层语音/文本输入入口查账功能的第一入口肯定是语音毕竟记账的主要场景是“随手记”。我在 Android 端用的是 sherpa-onnx 的离线语音识别方案它很小中文识别准确率在安静环境下足够用。为什么不用手机自带的语音识别因为自带 SDK 很多也需要联网或者会触发系统权限弹窗直接集成一个本地模型更可控。sherpa-onnx 提供了预编译的 AAR 包集成进 Android Studio 很顺畅识别速度也快。如果你是做 iOS 端原型验证也可以直接调用系统的 Speech 框架在离线模式下效果还不错。但 Android 端的碎片化太严重统一用 sherpa-onnx 是相对省心的选择。语音识别出来的文本统一走文本入口进入第二层。所以如果你的 MVP 版本不想接语音直接做一个“输入框”也完全验证得了核心逻辑。语音只是锦上添花模型处理和工具调用才是核心。3.2 第二层模型做意图识别与结构化抽取这层是整个系统的大脑也是最需要花心思调优的地方。我定义了一个非常精简的 JSON Schema模型输出会严格按照这个格式{ intent: add|query|delete|summary, category: 餐饮|交通|居住|购物|医疗|娱乐|教育|人情|其他, amount: 12.5, note: 午饭, date: 2026-06-02 }这个 Schema 的好处是足够简单。小模型对复杂 JSON 的生成能力有限你如果给它一个嵌套三层、字段十好几个的 Schema它很容易崩。字段越少输出越稳。提示词里我会放几个 few-shot 示例这是提高准确率的胜负手用户说昨天下午打车去机场花了80 输出{intent:add,category:交通,amount:80,note:打车去机场,date:2026-06-01}多放几个类似示例模型基本就能学会模式。实测下来5 个示例以内效果提升最明显超过 5 个边际收益递减反而增加 token 消耗。3.3 第三层工具调用与数据库查询当模型识别出 intent 是 query 时系统进入“查询模式”。这里我用的是 function calling 的思路但实现上没有依赖复杂的 function calling 协议而是让模型输出一个更简单的结构化查询参数{ intent: query, summary_type: sum|count|avg, category: 交通, date_range: this_month, group_by: category }拿到这个 JSON 后程序端做两件事一是把这几个参数拼成 SQL去本地 SQLite 里执行聚合查询二是把查询结果转换成自然语言回复。例如 SQLSELECT SUM(amount) FROM bills WHERE category 交通 AND date BETWEEN 2026-06-01 AND 2026-06-30;重要经验让模型输出“查询参数”而不是直接让它输出 SQL。直接让模型拼 SQL 的话很容易出现注入风险和小模型拼错语法的问题。让模型只输出几个枚举值程序端拼 SQL既安全又可靠。这样做的另一个好处是通用性。就算以后要从 SQLite 换成别的关系型数据库模型侧完全不用动只改程序端的 SQL 模板就行。3.4 第四层本地数据安全与隐私设计既然主打“私人查账”数据安全就得做到位不然就是摆设。账单数据我用的是 SQLite 存储但整库用 SQLCipher 加密。密钥存在 Android Keystore 里和系统账户绑定应用被卸载之后密钥丢失数据也成为一堆密文。另外模型文件本身也要防篡改。APK 内打包的 GGUF 文件在首次启动时计算 SHA-256 哈希如果和内置的哈希值不一致就拒绝加载。这一步是为了防止有人替换模型文件植入恶意行为虽然对于个人项目有点过度设计但如果是做产品这一步不能省。还有一点是权限控制不要在全局开悬浮窗、无障碍之类的高危权限。语音唤起只需要前台 Activity 级别的录音权限后台自动记账用 WorkManager 定期处理即可尽量避免常驻服务。4. 推理引擎选型与端侧调优实录4.1 用 llama.cpp 还是 MLC-LLM 还是 ExecuTorch端侧推理引擎的选择直接影响开发效率和运行效果我三套都试过。第一套是 llama.cpp 的 Android 封装llama.android。GGUF 格式通用、文档齐全、社区活跃CPU/GPU 都能跑对内存的控制也很细。对于 20 亿参数以下的小模型这是最省心的选择。我的最终版本就是基于它做的。第二套是 MLC-LLM。它的强项在算子优化和跨平台统一TVM 后端会把模型编译成各种硬件平台的高效算子。但缺点是编译链路长改个模型参数要重新走一遍编译开发效率偏低。第三套是 ExecuTorchPyTorch 官方的边缘推理方案。如果你模型是从 PyTorch 生态训练出来的它可以一站式导出和部署。但小模型场景下性能优化不如 llama.cpp 激进而且 Debug 工具链还不够完善。结论20 亿参数级别的纯文本小模型无脑用 llama.cpp 就行。MLC-LLM 适合模型更大、算子更复杂的场景ExecuTorch 适合项目深度绑定 PyTorch 生态的团队。4.2 实测性能数据这是我在骁龙 8 Gen 212GB 内存和一款中端机骁龙 7 Gen 1, 8GB 内存上的实测数据模型是 Qwen2.5-1.5B-Instruct量化格式 q4_k_m上下文长度 2048性能指标骁龙 8 Gen 2骁龙 7 Gen 1首 token 延迟约 220ms约 420ms生成速度35~40 tok/s13~16 tok/s峰值内存1.8GB1.9GB单次记账耗时0.6~0.8s1.2~1.8s连续查询 30 次机身温度39℃42℃这个数据说明一个问题即使是中端机只要模型是 1.5B 级别体验也完全可以接受。首 token 延迟主要来自 prompt 解析我通过固定最大 token 数和使用 LLM 的 batch 接口来优化可以把首 token 延迟再压低 20% 左右。4.3 推理参数调优使用 llama.cpp 时有几个参数值得特别调Temperature生成 JSON 时一定要低我直接设到 0.1。低于 0.3 时 JSON 格式基本稳定。如果设成默认的 0.8模型经常会给出“好的我会帮你记账”这种混在 JSON 里的废话解析器会直接崩溃。Top-p建议设 0.9 或 0.95别太低。配合低 temperature能让输出既稳定又不至于太过机械。Repeat penalty设为 1.1 左右。小模型很容易重复输出同一个字段名尤其是 JSON 的 key比如输出完{intent: add之后又开始重复intent。1.1 的惩罚度能压制这种重复又不影响正常内容。Max tokens隐隐需要给一个上限。记账场景每次生成的 JSON 大概 80 到 120 个 token查询场景更短。我把上限设为 256防止模型上下文跑飞。Context length2048 就够用了。太长的话KV Cache 内存占用会急剧上升而且小模型的远距离依赖能力有限长上下文并不会带来多少收益。5. 常见问题与排查技巧实录5.1 模型输出总是带“废话”JSON 解析失败这是我遇到的最多的问题。模型在输出 JSON 前会先来一句“好的我来帮您记录”后面再接大括号。解析器按字符串定位{的位置后截取能用但如果废话里带了{或}就会截错。最终的解决方案是双保险解码时开启一个 JSON 修复器如果标准JSON.parse失败就尝试用正则提取 JSON 片段或者用一个容错解析器如 JsonRepair做修复。另外在提示词里明确要求“只输出 JSON不要输出任何解释文字”配合低 temperature物理上把出废话的概率压到最低。5.2 模型不知道“今天”是几号小模型的训练数据有截止日期而且它根本不能读取系统时钟。你如果问“这个月交通花了多少”它无法知道“这个月”是哪个月。我踩了这个坑之后在 system prompt 里动态注入当前日期现在是 2026 年 6 月 2 日。用户提到的“今天”“昨天”“本月”等词请基于当前日期解析为具体日期。这句话写进提示词之后日期解析准确率马上提升到 98% 以上。这是端侧模型和云端 API 最大的差异之一云端模型有时能拿到一些上下文信息但端侧模型完全隔离所有环境信息都要显式注入。5.3 上下文过长后开始胡言乱语用户连续对话 10 轮之后模型的注意力开始分散回答质量明显下降有的还会突然开始重复之前的输出。这是小模型的通病不是代码 bug。我的处理方式是对话上下文只保留最近 6 轮超过 6 轮后就把更早的对话摘要成一小段文字插到系统提示词里。摘要由模型自己完成相当于加了滑动窗口。具体实现起来很简单每 6 轮之后的第一次请求程序自动调用一次“请总结我们刚才的对话不超过 50 字”的自问自答把摘要替换掉最早的消息。这样处理后长会话的稳定性好了很多内存占用也稳住了。5.4 手机发热严重掉电快直接用 CPU 跑推理连续 30 分钟机身温度能到 45℃ 以上耗电肉眼可见地往下掉。解决思路有三个层面。第一把推理线程数从默认值降到 4。Android 的 big.LITTLE 架构里我们优先让它在小核上跑大核留给 UI 线程。llama.cpp 支持设置线程数和 CPU affinity实测把线程数从 8 降到 4生成速度只慢了 15%温度却能降 5℃。第二单次任务执行完立即释放模型实例不要常驻内存。每次记账查询大约耗时 1 秒冷启动加载模型大约需要 300ms这个代价完全可以接受换来的是平时内存占用只有几十 MB发热问题大幅缓解。第三高频使用场景下用 WorkManager 做异步执行不在主线程跑推理。UI 卡顿和 ANR 问题也就随之消失了。5.5 小模型在查询场景的“幻觉数字”这个问题在测试早期特别明显用户问“上周买咖啡花了多少”模型如果识别不出 category 是餐饮或者把日期范围理解错就会去数据库查一个错误聚合结果。更麻烦的是模型有时会在“没查到”的时候编一个数字出来这就是典型的幻觉。我的策略是双保险一是程序端禁止模型直接输出金额数字。查询结果必须来自 SQL 聚合的真实结果模型只负责生成自然语言包装比如“你上周在餐饮上的总支出是 186 元”其中的“186”由程序拼进去模型不参与生成数字。二是增加异常兜底。如果查出的结果是 0 或空程序端直接返回“没有找到对应的记录”不需要让模型来组织语言以免模型发挥想象。6. 从手机到更多端侧设备的扩展思路这个方案做完之后我最大的感受是它不仅适用于手机查账。模型压缩到 1GB 以内、推理对硬件要求不高这意味着很多嵌入式设备都能跑。比如小商户场景一台几百元的 Android POS 机上也能集成这个模型店主用语音记账、语音查流水不用装复杂的 SaaS 系统数据都在本机离线也能用。再比如车载场景在车机上接一个本地模型停车后说一句“今天加油花了 400”它就自动记到账本里。另外如果你的数据存在手机上还可以结合系统短信权限自动解析银行卡消费短信。权限合规的前提下模型把“您尾号 8899 的卡于 6 月 2 日消费 58 元”自动结构化并写入账本真正实现“零录入”。不过这个涉及敏感权限上线前需要谨慎评估隐私合规问题。我自己在实际操作中还有一个体会这件事最难的不是模型而是把模型接口设计得足够“窄”。很多人一上来就想让模型什么都干结果小模型撑不住。把需求拆成几个非常明确的工具调用让模型做它最擅长的“意图识别 参数抽取”其余交给传统代码体验会好很多。最后再分享一个小技巧无论你选哪个模型存一份每天用固定测试集跑回归的数据脚本。模型换了、提示词改了、量化参数调了拿同一套数据跑一遍准确率变化一目了然。这个小习惯帮我省了无数次“怎么越改越差了”的排查时间。