手机端小模型评测，最近突然成了端侧 AI 开发者圈子里讨论度不低的话题。Artificial Analysis 联合 Liquid AI 发布的这一次手机端小模型评测，核心价值在于把过去只在大算力服务器上完成的模型能力验证，真正搬到了手机这个受限环境里来做。也就是说，它解决的不是“模型理论能力有多强”，而是“模型落在手机上跑起来，到底还能剩下多少可用性”。
这件事适合谁看？我觉得三类人最该关注：一类是正在做手机端离线推理或端侧 AI 应用的开发者，第二类是准备接入小模型做智能体或本地知识库的产品负责人，第三类是自己在 Win 掌机、平板、旧手机上折腾本地模型的技术爱好者。最值得先看的点不是排行榜上的名次，而是评测维度本身——因为评测维度决定了这份榜单对你有没有参考价值。
下面我会从评测背景、评测指标、自己复现一轮评测的流程、落地时容易误判的地方、以及最终选型经验五个方面展开。这篇适合保存下来，等真拿到评测报告或者准备做端侧小模型选型时再对着看。
1. 为什么“手机端小模型评测”值得单独拿出来看
先说一个很多人容易混淆的地方：手机端小模型评测，重点往往不在“能不能跑”，而在“跑起来的体验差异有多大”。
现代手机的性能已经足够带动几亿到几十亿参数的小模型，哪怕是几年前的旗舰芯片，经过量化压缩之后跑一个小模型也不是什么新鲜事。所以“能跑”这件事，已经不能作为选型依据。真正拉开差距的是同样一部手机、同一个任务，不同模型在延迟、峰值内存、生成速度和稳定性上的表现差异。
1.1 从服务器端榜单到设备端实测，评估逻辑完全变了
传统的大模型评测榜单，几乎都是跑在高端 GPU 上。这类评测看的是模型的推理质量、数学能力、代码能力、幻觉率，评价的是模型“聪明不聪明”。这对云端 API 选型很有效，但对端侧部署的参考价值其实很有限。
原因很简单：同一个模型在 A100 上跑 1000 token，可能只要几百毫秒；换到手机上，同样的模型即使量化过，也可能要被换入换出内存、被算力上限卡住，甚至因为发热导致降频。所以服务器端评测看的是能力上限，手机端评测看的是能力在受限条件下的保留率。
Artificial Analysis 和 Liquid AI 这次联合做的评测，最大的变化就是把评估环境从服务器切换到手机端。这也意味着评测指标必须跟着调整。因为手机端不可能只测理论吞吐量，还得关注实际推理时的内存峰值、电池消耗、连续请求的可靠性，甚至不同芯片平台上的行为差异。
1.2 为什么这一轮评测的关注度比以往高
手机端小模型并不是新概念，市面上早就有很多能跑在手机上的模型，比如各种 1.5B、3B、7B 量级的轻量模型。但以前的问题是：缺乏一个统一的、可信的、针对真实手机环境的评测标准。
各家模型发布时，展示的都是自己在服务器上的跑分。到了手机端，实际体验往往和宣传相差很大。有的模型看起来参数量很小，但实际加载后内存占用惊人；有的模型在 Linux 服务器上推理很流畅，但换成手机端 SDK 后算子不支持，被迫回退到低效的 CPU 实现。
Liquid AI 本身的模型技术路线也比较特殊，不是简单地跟跑传统 Transformer 架构，而是更强调模型结构和推理效率的匹配。所以当这种偏底层的模型开发商，和专注于评测分析的人工智能分析平台合作，重视的并不是“谁分数更高”，而是“到底哪些模型能承受住真实手机环境的考验”。
注意：如果你在手机端只跑纯 API 调用，这份评测对你的参考价值不大。它更偏向端侧推理、本地部署以及离线智能体场景。
2. 手机端评测到底在测什么
要看懂手机端小模型评测，必须先搞清楚评测维度。这里有一个通用判断标准：如果一份评测只给出“准确率”和“排名”，没有交代测试设备、推理框架、量化精度、输入输出长度、温度参数、重复次数，那它的参考价值就要打一个问号。
2.1 常规三件套：延迟、吞吐、内存峰值
手机端评测最常见的三个核心指标是延迟、吞吐和内存峰值。
延迟指的是从输入一段提示词到模型开始输出第一个 token 的时间，也可以理解为“首 token 时间”。这个指标直接影响聊天或问答场景的体验。用户敲完问题，如果等了两秒模型才开始动弹，产品就得被用户骂。
吞吐量一般看 token 每秒，也就是模型每秒能生成多少个 token。这个指标决定了长文本生成、内容总结或文档处理场景的效率。如果吞吐只有个位数，那生成一篇 500 字的总结可能要等上一分钟，这种速度很难进入实际产品。
内存峰值则是端侧小模型最敏感的指标。因为手机不是服务器，没有动辄几十 GB 的显存，系统内存也是共享的。模型加载进来之后如果吃掉 4GB 内存，那后台任务和系统进程都会被挤掉。更关键的是，内存峰值往往不是固定值，它会随输入序列长度、批处理大小和模型上下文窗口变化。
比如同一个 7B 模型，用 4bit 量化后静态文件可能不到 4GB，但推理时如果上下文窗口拉长到 4096，激活值带来的临时内存可能比别人多占用不少。只看模型文件大小就做判断，在手机端很容易踩坑。
2.2 容易被忽略的第四项：环境依赖与 SDK 匹配度
除了上面三个指标，还有一项在服务器端很少出现、但在手机端非常常见的评测维度——环境依赖匹配度。
手机端推理不纯粹是模型问题，还牵扯到推理框架、系统版本、芯片平台、SDK 版本等一系列环境因素。评测时需要确认的事情包括：
- 模型是通过什么格式加载的，ONNX、MLX、GGUF，还是特定厂商的私有格式
- 当前 SDK 版本是否支持模型里用到的算子和量化方式
- 同一模型在不同手机品牌上的表现是否一致
- 推理框架是否启用了 GPU 加速，还是默默回退到 CPU 模式
这些在评测报告里必须交代清楚。否则就会出现“在 Android 上表现很好，换到 iOS 上性能折半”或“在开发机上没问题，打包到生产 App 后 SDK 版本不匹配导致彻底跑不起来”的情况。
这也是为什么真实手机端评测比服务器评测更难做。服务器上环境相对统一，操作系统、驱动、GPU 配置相对可控；手机端有不同芯片、不同系统版本、不同厂商定制化逻辑，同一模型跑在不同手机上的结果差异可能非常大。
3. 如果要从零跑一轮自己的手机端小模型评测
看别人的评测报告只能解决参考问题，真正做端侧模型选型时，还是需要自己跑一轮小范围对比。但我不建议一上来就模仿机构去做完整评测，成本太高，而且很多测试环境不是普通开发者能复现的。更合理的做法是做一个“最小可行评测”，只测自己关心的场景。
3.1 最小评测流程怎么搭
建议拆成四步：固定设备、固定输入、固定参数、记录输出。
第一步是固定设备。这轮测试用的是什么手机或者平板，芯片型号、内存大小、系统版本都要记录下来。如果你要的是真实产品体验，最好用目标用户的常见机型，而不是手头性能最好的那台旗舰机。原因很直接：旗舰机跑起来流畅不代表中端机能扛得住，如果你的目标用户一半是两三年前的手机，评测基准就按那类机型来。
第二步是固定输入。不要每次随便找一句话去问模型。准备一组固定的测试输入，比如 10 个问题、2 篇 500 字左右的文档、1 段长上下文任务。每个输入要能反映你真实产品里的核心使用场景。如果产品是问答，就拿真实用户经常问的问题来测；如果是文档总结，就直接用真实文档片段。固定输入才能保证不同模型之间的对比公平。
第三步是固定参数。采样温度、top p、最大生成 token 数、上下文长度、量化精度，这些参数要统一。如果换一个模型就调一次参数，那测出来的差异不一定是模型本身的差异，而是参数设置带来的差异。温度太高可能采样过头，输出飘了；最大生成 token 数设得太短会影响长文本任务表现。最容易做对比的方式是：除了推理框架和模型文件不同，其他参数全部保持一致。
第四步是记录输出。不只是记录模型回答内容，还要记录首 token 时间、总耗时、内存峰值、输出 token 数，以及是否有报错或卡死。最好有日志记录，方便后续排查。
3.2 判断结果的几个标准
评测结果不是简单看谁分数高就选谁，要结合自己的实际场景来判断。
如果你的核心场景是实时对话，优先看重首 token 延迟。如果首 token 时间差出一倍，哪怕最后的回答质量差不多，实际体验差距也会非常明显。
如果你的核心场景是长文档总结，优先看吞吐量和内存峰值。长文档处理意味着输入长度和输出长度都不小，内存占用会明显上升。只测短句问答看不出真实表现。
如果你要做的是离线智能体或工具调用，那还要额外测模型对 JSON 输出、多轮对话、指令遵循的稳定性。这里推荐参考 agent 评测和 swe-bench 评测的玩法，任务要足够具体，要考察模型能否从复杂上下文中提取关键信息并完成多步操作。测的时候不要只看能不能跑通，还要看它连续跑 30 次后有没有状态错乱、JSON 解析失败或者上下文被污染。
4. 把评测结果落到真实业务中，最容易误判的几个点
评测报告和数据摆在那里，真正落地时还是容易出现误判。下面这几个问题是我在实际环境中见过比较多的，也正好是手机端小模型评测最容易迷惑人的地方。
4.1 排名第一不代表在你的 App 里体验最好
榜单上有排名，但这个排名通常是在固定条件下产生的。固定条件包括特定处理器、特定内存、特定推理框架、特定批次请求模式。而你的 App 运行环境可能完全不同。
举个最常见的例子：评测里可能用的是最新款旗舰芯片，支持更多 GPU 算子，模型可以直接跑在 NPU 上。但你的目标用户还在用两三年前的机型，芯片不支持某些高级算子，推理框架被迫回退到 CPU 模式，速度立刻掉一半不止。
所以正确做法不是“选榜单第一”，而是“选在你目标机型上表现最好、且与你的推理框架匹配度最高的模型”。如果你的用户群里中端机占大头，直接拿中端机跑，不要拿旗舰机的结果替代。
4.2 “支持某功能”不等于所有格式都稳定
小模型常常被宣传为支持长上下文、支持工具调用、支持多轮对话、支持 JSON 输出。但支持本身是一个很粗的概念。端侧模型的最大上下文可能确实达到了 8192，但如果输入稍微长一点，推理速度变成不可用状态；或者上下文能接受，但模型在长上下文段乱接，前文信息严重丢失。这种情况在手机上比服务器上更容易触发。
我的建议是拿到评测结果后，不要只信“支持”这两个字，而是按照实际业务的最长输入、最长输出、最复杂指令来分别测试。测试时尤其要关注以下类型的数据：
- 中英文混合的长文本
- 带表格、编号、JSON 等结构化格式
- 有歧义、需要多轮澄清的指令
- 异常输入，比如空内容、超长文本、重复内容、乱码
很多评测只测“正常输入”，但实际产品里用户输入五花八门。模型能不能在异常输入下保持稳定，比它在完美输入下能得多少分更重要。
4.3 环境依赖冲突是经常被忽略的坑
手机端小模型评测跑得像模像样，拿到自己项目里半天跑不起来，这类问题我见过太多次。排查顺序通常是这样的：
先看报错信息出现在加载阶段还是推理阶段。加载阶段重点检查模型文件路径、文件权限、模型文件格式是否完整。
再看 SDK 版本匹配。有些项目用打包工具开发，编译环境和手机端 SDK 版本不一致，很容易出现模型加载失败或算子不兼容。手机上安装提示不匹配，或者模型初始化报错。这种问题不是模型本身不行，而是环境版本对不上。
接着看内存占用。如果你的模型加载后内存直接顶满，再好的模型也没有可用性。可以考虑降低量化精度、缩短上下文长度、或者换一个更小的模型。
最后看系统资源。是否有 GPU 加速被禁用的可能。有些机型默认不允许第三方应用使用 GPU 加速，或者驱动存在兼容性问题，导致推理始终走 CPU 模式。
提醒：拿到评测报告后，先搞清楚它的测试环境和你目标环境之间的差异。差异越大，结果可迁移性越低。
5. 手机端小模型选型的一些实际经验
评测看多了以后，我自己的选型逻辑从“看参数多高”慢慢变成了“看综合成本”。所谓综合成本，不只是模型文件大小，还包括内存占用、推理耗时、开发适配难度、长期维护成本。
5.1 先看任务类型，再看评测指标
不同任务对评测指标的敏感性完全不同。我建议把任务分三类来看。
第一类是对话和问答类。这类任务最看重首 token 延迟和回复质量。模型太小回复容易空洞，但模型太大内存容易吃紧。一般考虑 1B 到 4B 之间的模型，配合适当的量化。
第二类是结构化信息提取和文本改写类。这类任务对指令遵循能力要求较高，模型要能严格按照 JSON 格式输出。评测时除了看延迟，还要看 JSON 解析成功率和输出格式稳定性。很多模型在服务器上 JSON 输出没问题，但端侧量化后格式稳定性会下降。
第三类是智能体类。智能体任务涉及多轮工具调用、状态管理、上下文约束。这类任务对小模型的挑战最大，不能只看标准评测指标，还要做 agent 评测和任务成功率测试。有些小模型在单轮问答里表现得不错，但进入多轮工具调用后会出现忘记指令、输出错误格式、越权动作等问题。这时候要参考 swe-bench 或类似评测跑法，设计多步任务链条来测试。
5.2 模型性价比和量化精度要一起看
手机端模型选型时，量化精度是一个绕不开的话题。同样的模型，4bit 量化比 8bit 量化占内存更少、速度可能更快，但质量会有一定损失。这个损失在不同任务上的反馈不一样。简单问答里可能感觉不出来，但在长文本理解、代码生成、指令遵循任务上，量化损失会被放大。
我的建议是不要只看 4bit 量化后的模型文件大小，还要对比同模型在 8bit 和 4bit 下的实际输出质量。选一个你产品场景可接受的最低量化精度，而不是追求极致压缩。如果目标产品对质量和稳定性要求非常高，内存允许的情况下宁可选择更高精度。
另外，小模型跑在手机上的速度波动也要关注。手机 CPU 频率会受发热和电池状态影响，跑同一段推理任务，冷机状态和连续跑 20 分钟后差异可能很大。评测报告里如果没提到温度控制机制和连续任务表现，它就只能作为理想参考，不能直接当真实用户体验来用。
6. 小模型评测标准的未来走向
这次 Artificial Analysis 和 Liquid AI 的合作，其实是把手机端小模型评测往前推了一步。但这件事还远没有成熟，评测标准本身也在快速变化。
6.1 从单纯能力评测走向任务场景评测
以前业界更重视模型的静态能力，也就是它在固定数据集上的准确率。现在越来越多人意识到：对小模型来说，任务场景匹配度比绝对能力更重要。
同样一个模型，可能在代码生成任务上表现一般，但在移动端智能体控制、本地语音输入处理、设备端异常检测这些具体场景上表现很好。这就推动评测从“通用能力榜单”走向“任务场景评测”。每一类任务都应该有专门的测试集和评估指标。
对开发者来说，这意味着以后看评测报告时，要更关注“这个评测是不是覆盖了我的真实业务场景”。如果评测只测了通用问答，那它对你做智能体决策参考价值有限。
6.2 模型在变，评测方法也要跟着变
手机端小模型的生态还在进化。Qwen3.5 这种通用小模型在持续更新，Liquid AI 这类偏工程效率的模型也在进入手机端。模型结构、训练数据、推理框架、手机芯片能力都在快速变化。
所以评测不是一锤子买卖，而是需要持续跟进的工程任务。我建议团队内部至少每个季度做一次端侧模型选型复审，重新测一次当前能拿到的模型，对比新的推理框架和新的 SDK 版本，确认现在上线的模型还是不是最优解。这段时间模型市场和手机生态变化太快，半年前的选择很可能已经过了最佳时效。
另外，手机端评测有一个服务器端不太常见的现象：模型版本更新频繁，但很多更新只是换了个量化精度或者微调了部分层，模型文件名称看起来差不多，实际行为差异可能不小。评测报告里一定要记录模型的具体版本哈希或构建时间，否则隔两个月再回头看，你对比的可能已经不是一个东西了。
7. 给想入局手机端小模型者的最终建议
写到最后，我把这一轮对手机端小模型评测的判断和实际经验再浓缩一下。
第一，评测报告的参考价值取决于环境匹配度。不要直接照搬任何榜单结论，一定要把测试设备、推理框架、量化精度、输入输出长度这四个维度对应到自己的目标环境。
第二，先跑通最小场景，再逐步扩展。不要一上来就在所有场景、所有型号上做完整评测。我建议先用一个场景、一台目标机型、一条真实输入，跑通完整链路，确认评测流程、日志记录、输出统计都正确，再扩展成多个模型和多种任务。
第三，稳定性比峰值性能更重要。手机端评测中常常出现单次测试很好，连续多次测试后表现不稳定的情况。小模型部署到真实产品里，遇到的是成千上万次调用，单次表现好没意义。
第四，关注上下文长度和量化精度的组合。这两个参数在手机上比服务器端更敏感，直接影响内存占用和推理速度。评测时要特意测试它们在边界状态下的表现，而不是只测默认状态。
如果你正在做手机端模型落地，建议把这篇文章和官方评测报告放在一起看。看报告时先回答一个基本问题：评测里的测试环境，离你的真实产品环境还有多远。答案越清晰，报告对你越有用。
我个人更建议把评测当成一个动态过程，不要盯着某一次的榜单就做长期决定。选型时留好 A/B 验证机制和切换路径，等评测指标更新、新模型发布后可以快速重新评估。手机端小模型的竞争才刚刚进入实战阶段，谁能持续用真实环境数据做决策，谁的产品体验就更可能稳住。
