手机端小模型评测最近突然成了端侧 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 验证机制和切换路径等评测指标更新、新模型发布后可以快速重新评估。手机端小模型的竞争才刚刚进入实战阶段谁能持续用真实环境数据做决策谁的产品体验就更可能稳住。