导读十亿参数级模型已有手机运行记录，部分任务评测也接近更大模型，但文件小、生成快和任务做得对，仍是三项不同的判断。本文用近期公开数据说明量化后的文件与运行占用、具体设备速度及能力差距，再通过一次日程任务，讲清模型、应用与云端怎样分工。
小模型到底多小，要先说清具体型号
如果一个模型可以放进手机，它能读多长的材料？需要多少内存？回答快不快？把它接到日历或文件系统后，能不能可靠完成任务？
“小模型”没有统一的参数上限，端侧也包括手机、PC 和开发板，资源条件相差很大。本文主要看十亿到数十亿参数的生成模型，用更大模型作对照。1B 代表十亿参数；参数量描述权重规模，不能直接换算成智能水平。
以 Liquid AI 在 2026 年 10 月 27 日发布的 LFM3 为例，文本型号 LFM3-1.7B 实际约 17.3 亿参数。能接收图片和视频的 LFM3-VL-2B 则约 19.2 亿，包含语言主干、视觉编码器和连接模块。文本型号的内存与速度，不能直接当作视觉型号的表现。
两个型号的官方上下文上限分别为 256K 和 128K token，包含输入与输出。token 是模型处理文本的单位，并不固定对应一个汉字；上下文上限能否在目标设备跑满，还要看运行预算。
如果选的是 MoE，也就是混合专家模型，每个 token 通常只动用部分专家，还要区分总参数与激活参数。激活少可以减少部分计算，但不意味着其余权重都不用存。看部署规格，先认准型号、总权重和输入类型。
量化后约 1 GB，不等于只需 1 GB 内存
权重量化用更低位宽的数值近似保存权重。先算最简单的一笔账：如果所有参数都按相同位宽紧密保存，仅裸权重的理论大小如下。这里用十进制 GB，不含其他开销。
实际文件会有分组缩放信息、元数据，也可能保留部分高精度张量。以 llama.cpp 常用的 GGUF 部署格式为例，官方仓库里的 LFM3-1.7B，BF16 文件约 3.47 GB，Q4_K_M 量化文件约 1.10 GB。这个数字回答的是下载文件有多大。
运行时还要为历史上下文、推理状态、中间结果和框架分配空间。标准注意力里的 KV Cache 用来复用历史键值；混合架构还可能包含其他状态。输入变长、并发增加，预算也会变化。
独显主要看显存；手机和不少集成平台使用共享或统一内存，还要与系统和应用共用资源。模型分到 CPU 与 GPU 上运行时，两侧占用也要分别看。
所以，文件大小、模型进程占用、整台设备所需内存，是三个不同数字。有一份 1 GB 文件，不能据此承诺一台只有 1 GB 空闲内存的设备就能顺畅运行。
手机生成 43.6 token/s，完整任务要等多久？
Liquid AI 给出了 LFM3-1.7B 的设备测试。共同条件是 llama.cpp、Q4_0 量化、32K 上下文、单请求、生成 100 个 token，并启用 GPU 加速。下表是发布方报告，不是我的实测；量化格式也与前面举例的 Q4_K_M 文件不同。
Apple 平台的数字是包含 Metal 分配的进程占用；AMD 则将同次运行的主机与 GPU 峰值相加，两者峰值可能并不同时出现。这些都不是独显显存要求，也不是设备最低总内存。
手机结果局部裁切，紫色为 LFM3-1.7B；其后依次为 MiniCPM5-2B、Qwen3.5-4B、Qwen3.5-9B、Gemma 4 E4B
来源：Liquid AI，LFM3-1.7B 模型卡 Edge inference
图中 LFM3 使用支持该架构的 llama.cpp 构建，对照模型使用 b11744，比较还包含后端实现的差异。输入处理速度描述模型读入提示的速度；生成速度描述开始输出后逐个产生 token 的速度，不能把 43.6 token/s 直接写成每秒 43.6 个字。
按这个生成速度，输出 100 个 token 的生成阶段约需 2.3 秒，但这还没计入加载模型、处理输入、等待工具及后续调用。如果模型先输出较长的思考过程，最终答案出现得更晚。官方这组图也没有给出首字延迟、重复测量波动和长时间发热后的表现。
因此，买设备或选模型时，需要看目标输入长度下的首字等待、持续生成和整任务耗时。这里证明了指定条件下的运行表现，不能直接承诺另一台手机也有同样体验。
和更大模型比，差距取决于任务
速度快不等于答得对。先看文本型号：发布方的工具调用基准 BFCL V4 中，LFM3-1.7B 得分 71.39，高于其对照的 Qwen3.5-9B 的 62.83；但知识推理基准 GPQA Diamond 是 63.37 对 80.40。这些是 BF16、vLLM 条件下的能力评测，不能自动对应前面的手机量化表现。
视觉任务则用另一个型号 LFM3-VL-2B 来看。下面选取其官方同表评测中的三项，对照 12B 模型和云端模型，分数按原表归一到 0—100。
这是 Liquid AI 的评测，不是独立验证。评测说明列出的本地推理框架为 vLLM 0.27.1，并采用各模型推荐的生成设置；表中 LFM3-VL-2B 开启思考，GPT-5.6 Luna 使用 medium 推理强度。闭源型号的参数量未在这里披露，不能按名称猜它有多少 B。
这组结果最有用的地方，是让任务差异变得具体：文档问答分数接近，多学科推理与云端对照却相差 25.2 分。工具任务的“部分得分”也不是完整流程成功率。不能把某项接近大模型，概括成整体能力已经追平。
这些分数不等于量化模型在你业务上的正确率。要判断量化损失，应让同一模型的高精度版和量化版处理同一批样本；要判断能否上线，则需在目标设备上，用真实中文文档、截图和工具任务检查遗漏、幻觉、字段错误与执行失败。
最近的优化，改变了哪些使用条件？
小模型进步并不只靠降低位宽。LFM3 的文本主干混合了三种模块：门控短卷积处理邻近片段，滑动窗口注意力在局部范围内交互，全局注意力连接更远的信息。训练也增加了工具轨迹、强化学习和多领域蒸馏。相较前代 LFM2.5-2.6B，它的参数少约 35%，前述工具调用基准得分则从 55.89 提高到 71.39。这是架构与训练等多项变化下的结果，不能把收益全部归给某一个模块。
另一条路线是专用模型。10 月 6 日发布的 EmbeddingGemma 2 用于检索：把文字、图片、音频等转为可比较的向量，再找相关内容。它不负责像聊天模型那样生成答案。完整多模态版本约 7.4 亿参数，文本路径可只用约 2.7 亿；向量还可从 768 维截到 128 维，缩小的是向量存储，不是整个模型或应用的内存。
对本地资料助手来说，先找准相关片段，再让生成模型回答，可能比把所有文件直接塞进上下文更合适。这是可选的系统设计，不代表两个模型已经替你装配好，也不保证任何资料上都能正确回答。
能做什么，最后落到一次完整任务
我会优先把小模型用于边界清楚、输出可检查的环节：提取消息里的时间地点、给文件分类、对短材料生成摘要、从本地资料中检索片段，或提出工具调用。具体型号和任务仍要匹配，视觉能力也不能由文本型号继承。
比如消息写着“11 月 18 日下午 3 点，在 A 会议室讨论方案”，用户要求存为日程。希望模型提取出的内容是：时间为 11 月 18 日 15:00，地点为 A 会议室，事项为讨论方案；年份等未写明的信息，还需结合上下文确认。这是教学场景中的目标输出，不是本文实测结果。
模型负责把自然语言整理成字段，应用负责校验日期、管理权限和调用日历，用户确认后再保存。“下周三”需要结合当前日期解析，时间缺失就追问，不能让模型补一个看起来合理的值。工具执行失败，也要如实返回失败。
这时，小模型承担了明确的一段工作；流程是否可靠，还取决于字段校验与工具执行。如果任务需要更强的知识推理、跨多份材料作判断，或本地验证持续失败，再考虑更大模型或云端。涉及数据上云时，也要重新判断数据范围和授权。
端侧小模型已经能用有限资源承担部分任务，但能装下、生成快和完成得对，需要分别验证。端云分工应从设备预算与任务效果推出：本地能可靠完成的留在本地，超出能力或资源边界的再升级。把这几笔账算清，才知道“小”对自己的应用究竟意味着什么。
参考资料 上下滑动
•Liquid AI，Introducing LFM3，2026-10-27： https://www.liquid.ai/blog/lfm3•Liquid AI，LFM3-1.7B 模型卡，规格、能力评测与设备测试条件： https://huggingface.co/LiquidAI/LFM3-1.7B•Liquid AI，LFM3-1.7B 官方 GGUF 文件列表，2026-11-12核对： https://huggingface.co/LiquidAI/LFM3-1.7B-GGUF/tree/main•Liquid AI，LFM3-VL-2B 模型卡，规格、分项成绩与评测说明： https://huggingface.co/LiquidAI/LFM3-VL-2B•Google，EmbeddingGemma 2 官方介绍，2026-10-06： https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2/
文章仅做学术分享，如有侵权请联系删除，非常感谢！