手机端小模型评测正在成为一条和云端榜单截然不同的赛道。过去两年我翻过大量模型评测报告MMLU、GPQA、HumanEval、长上下文、多模态……这些指标对云端部署当然有参考价值可一旦把模型放进手机问题立刻就变了模型再聪明如果装不上、跑不动、用起来烫手一切榜单分数都是空谈。Artificial Analysis 联合 Liquid AI 发布手机端小模型评测正好指向了这个断层。它想回答的不是“哪个模型理论上更强”而是“在手机这种资源受限的环境里哪个模型能真正被用起来”。这个动作背后有一个值得所有开发者认真琢磨的判断手机端小模型评测的价值不在排名本身而在它把“手机端能不能用、好不好用”这件事从一句宣传口号变成了一组可以检查、可以对比、可以验证的工程指标。这篇文章我会从评测逻辑差异、可信度判断、指标读法、落地路径四个层面展开最后给出一套从榜单到真机能复用的选型框架。1. 手机端小模型评测为什么不能沿用云端榜单的逻辑1.1 云端评测回答的是“能不能”端侧评测回答的是“跑不跑得动”云端大模型的评测核心任务是比较能力上限。测试环境基本固定GPU 资源充足内存和显存不是首要瓶颈评测机构可以放心地把模型做大、把上下文拉长然后观察它在数学、代码、推理、知识问答上的表现。手机端完全不同。一部主流中端手机的可用内存可能只有 4GB 到 8GB还要留给系统、后台应用和当前前台进程。一个 7B 模型量化后可能仍然占用两三个 GB加载后内存所剩无几即使能运行首字延迟超过两秒用户点完按钮就开始怀疑应用是不是卡死了。这种情况下继续用云端那套能力分数做判断基本等于只看菜谱不看厨房。所以端侧评测的第一个变化是把“模型能不能答对”扩展成“模型在设备上能不能稳定、及时、不烫手地回答”。这不是把同一套指标换组设备跑一遍而是从评价维度到评价方法都要重建。1.2 小模型不是大模型的“缩小版”评测维度要跟着换很多开发者对小模型有一个误解觉得它只是大模型的压缩版本能力弱一点但定位相同。实际上手机端小模型的优化目标从来不是单纯逼近大模型的能力而是“在有限资源里保留最多的可用能力”。为了塞进手机模型会被量化、剪枝、蒸馏这些操作会改变模型在不同任务上的表现分布。因此评测小模型时能力指标只是其中一个维度。真正影响决策的还包括模型文件大小、峰值内存、每 token 生成速度、首 token 延迟、连续运行后的功耗和温度、芯片平台兼容性、推理框架支持度。这些指标在云端评测里很少被当成核心排名依据但在端侧评测里每一项都可能决定一个模型的生死。1.3 为什么是现在出现这类评测手机端 AI 应用正在快速增多。语音助手、实时翻译、会议记录、OCR 识别、相册分类、输入法智能联想还有正在兴起的端侧 agent都需要模型跑在本地。端侧推理带来的隐私保护、离线可用、低延迟体验是云端 API 替代不了的。也正因为应用多了厂商和开发者都面临选型问题。过去只能靠自家测试或者看模型厂商自己发布的数据这里面既有工程条件差异也有明显的利益立场。现在评测机构与模型公司联合发布评测说明行业已经意识到端侧模型的选择不能靠单方自述需要相对中立、可复现的标准。2. 端侧评测和云端评测差异到底在哪里2.1 评测维度从能力清单变成运行体检如果只从能力分数看端侧小模型和云端大模型好像只是分数的差距但落到评测维度两者几乎不是同一个物种。我用一张表把常见差异列出来评测维度云端大模型评测手机端小模型评测核心问题模型能力上限有多高在设备上能不能稳定运行参数量级从数十亿到数千亿不等多在亿级到数十亿级模型体积通常是 GB 到百 GB 级量化后通常在几百 MB 到几 GB内存占用资源相对宽裕不作为首要瓶颈峰值内存是决定适配机型的关键推理延迟关注吞吐但对单字延迟容忍度高首字延迟和生成速度直接影响体验功耗与温度很少作为普通用户级排名指标持续运行的发热和耗电是硬指标硬件兼容性相对统一的 GPU 环境芯片、系统、推理框架差异巨大评测任务学术能力集、长文本、复杂推理日常短任务、离线场景、低资源前提这张表不是某一份具体评测的细则更像是一份通用导读。你去看任何手机端评测如果它只报告能力分数不报告运行环境那么结论就缺乏落地参考价值。真实端侧评测里还有一类指标容易被忽略冷启动加载时间。模型首次加载要读文件、建内存、初始化推理引擎这个过程可能持续数秒。如果应用每次启动都要重新加载用户会非常不耐烦。评测如果不区分冷启动和热推理很多问题会被掩盖。2.2 任务设计要贴近真实场景而不是学术测试题云端评测常用的 MMLU、BBH、HumanEval 这类基准对学术研究很有价值但在手机上用户不会让模型做一套完整的多选题。真实场景是短文本摘要、信息抽取、几轮连续对话、离线状态下听懂含糊的语音指令、拍一张照片后快速提取文字。一份靠谱的手机端小模型评测通常会同时覆盖三条线通用能力抽样用一批难度适中、格式稳定的任务验证基本能力性能测试记录不同输入长度、不同并发任务下的延迟、内存和功耗场景模拟把任务设计成贴近应用实际调用的样子比如限制输出长度、限制上下文轮次、要求离线完成。所以你看评测时不能只看它跑了几道题还要看它的任务输入是不是真的贴近用户操作。一个模型在短任务上很强在长上下文中表现崩掉这在手机端很常见。2.3 统一评测环境是端侧评测最难做到又最该较真的地方手机端评测最大的坑是环境很难统一。芯片不同、系统版本不同、内存管理策略不同、推理引擎对算子的优化程度不同都会导致结果天差地别。同一个模型在一部旗舰机上可能运行流畅到中端机上可能加载就要十几秒。所以一份可信的手机端评测至少要做三件事明确标注测试设备和系统版本明确量化方式、上下文长度、推理框架和关键参数提供可复现路径让开发者可以按同样的条件验证。如果评测报告里没有这些信息只给一个综合排名那它的参考价值和厂商宣传稿差别不大。这不是说评测机构一定有问题而是作为使用者你要先确认边界再读结论。3. 评测机构加模型公司联合发布为什么值得多看几眼3.1 单方自说自话的公信力瓶颈如果模型厂商只发布自家跑分你一定会怀疑它只挑好听的说。这是正常的信任防御机制不是针对哪一家。反过来如果第三方机构评测又缺少模型公司的工程支持它可能拿到一个没有经过合适量化的模型或者用错误的上下文长度、不兼容的推理引擎跑了结果最后得出的结论并不代表这个模型在真实部署中的水平。联合发布的价值在于第三方机构负责设计评测方法和保持方法论独立模型公司提供模型访问、运行配置和工程支持。两者共同发布结果一方面减少了信息不对称另一方面也把评测从“理论抽测”往前推进了一步更接近模型真正被部署时的状态。3.2 联合评测的好处不等于无条件信任关联合作会不会影响客观性肯定会带来这样的疑问。所以你在看这类评测时要重点检查几个点评测方法是否公开是否给出完整的测试环境配置是否存在只挑优势场景展示的倾向是否包含失败案例、局限场景模型公司是否有权限干预最终排行。如果这些信息是透明的那么联合发布的参考价值是大于单方宣传的。如果这些信息缺失即使来源听起来很权威也要保持保留。3.3 对开发者的现实意义从“看排名”变成“看条件”我见过不少团队看到一份榜单就直接选第一名接入结果在自家目标机型上表现很差。原因很简单榜单的第一名可能是在高位设备、特定量化、特定任务下拿到的而你的真实用户群更多是中低端机型任务类型也不一样。正确的姿势是把榜单当漏斗不把它当答案。先用榜单筛出三五个值得测试的候选模型然后带入自己的场景做真机验证。这一步省不了评测只能帮你把“要从几十个模型里挑”变成“要从三五个模型里挑”。4. 看手机端小模型评测最该盯住这四类数据4.1 体积与内存占用决定“能不能装机”在手机端体积不是小事。当前主流应用安装包已经有几十 MB 甚至上百 MB模型文件动辄几百 MB会影响下载转化率也会占用用户的存储空间。比文件体积更重要的是峰值内存占用。模型加载后的常驻内存加上推理时的临时内存如果超过了系统可用内存的合理比例应用就会面临被系统杀后台、卡顿甚至闪退的风险。所以我建议你做一张配置表把候选模型的文件大小、量化位宽、加载后内存、推理峰值内存分别列出来再对照你的最低支持机型去判断。这一步越早做越好不要等到功能开发完才发现机型覆盖不了。4.2 延迟和吞吐决定“体验顺不顺”手机端用户对延迟的忍耐度很低。点击之后如果超过一秒都没反应用户就会觉得应用卡。所以评测里的首 token 延迟和生成速度直接影响产品体验。这里有一个常被忽略的细节输入较长时提示词处理时间会比生成过程更长。比如用户粘贴一大段文章要求摘要模型要先把整篇文章的 token 处理完才开始输出摘要。如果评测只报告生成阶段的速度不报告提示词处理时间你会在真实场景里发现明显偏慢。看评测时要区分短输入和长输入。一个在短任务上很快的模型不一定能扛住长文档处理反之亦然。4.3 功耗和散热决定“能不能长期用”手机端模型评测如果只看速度和准确率会漏掉一个最容易毁掉体验的变量发热。连续跑几轮对话后手机温度上升系统可能会主动降频推理速度会肉眼可见地下降。如果模型持续调用大算力单元电量和温度都会走高用户很快会感受到“用了一会儿就发烫、掉电快”。好的端侧评测会把连续压力测试的结果放出来比如连续运行后温度上升了几度、电池消耗多少、速度下降多少。这些数据比单轮跑分更接近真实使用。如果你的应用需要长时间保持前台运行这个维度甚至比准确率更重要。4.4 能力指标决定“换得值不值”最后才是能力分数。看能力分数时不要只看综合分要看任务分。不同小模型的能力分布差异很大有的强在指令跟随有的强在中文理解有的强在代码生成有的是通用但平庸。先列出你的核心任务类型再去看对应任务上的表现。两个综合分相同的模型在你需要的任务上可能差出一大截。你在选型时真正关心的应该是“这个模型在我这个场景里够不够用”而不是“它在所有任务上是不是平均分最高”。5. 评测之外把端侧小模型落进真实项目还差几步5.1 先跑通单条样例再谈批量使用把模型接入手机端的第一个目标不是调到最优而是跑通一条完整链路。我建议按这个顺序来选定一个目标测试设备最好是你的用户群体中占比最高的机型把模型转换成你的推理引擎支持的格式从最简单的输入开始确认加载、推理、输出都能正常完成记录基线数据加载时间、首 token 延迟、峰值内存、温度变化再验证两条真实业务样例看看输出质量是否可用。跑通之后再逐步增加上下文长度、测试多轮对话、接入更复杂的业务逻辑。不要一上来就塞进完整业务流程否则出了问题很难定位到底是谁的锅。5.2 真机覆盖要分档不要只看旗舰机同一个模型在不同档位手机上的表现差距很大。实际落地时至少要在三个档位测试低端机确认基本可用主要看加载时间、内存、发热是否在可接受范围中端机承担主要体验优化覆盖大多数用户旗舰机看模型的性能上限也用来判断未来功能扩展空间。只测旗舰机的项目往往上线后才会发现低端机的崩溃率远高于预期。这属于非常典型的踩坑点。5.3 模型格式、量化方式和推理引擎要提前对齐手机端模型通常需要经过量化才能塞进内存。常见的量化位宽有 FP16、INT8、INT4不同位宽对模型体积、内存、推理速度、能力损失的影响都不一样。这里有一个很现实的坑某些推理引擎对算子和量化方式的支持是有限制的。一个模型在 Python 端测试时表现很好转成端侧格式后部分层可能不支持导致运行报错或者精度下降。所以选型时不要只看模型算法本身还要确认你的目标推理引擎能不能完整支持它。另外手机端还有一个非常常见的问题打包工具链版本和手机端 SDK 版本不匹配导致模型推理库加载失败。这类问题看起来像是模型加载 bug实际是 so 库和宿主环境不匹配排查时经常绕远路。遇到加载失败先检查工具链和 SDK 的版本对应关系再去看模型文件和代码逻辑。5.4 上下文长度与会话管理内存暴涨的常见源头手机端内存有限上下文长度不是越大越好。当上下文超过模型配置上限或设备内存承受范围时推理内存会快速上涨最终导致闪退。常见解决思路有三类滑动窗口只保留最近几轮对话历史摘要把早期轮次浓缩成一段摘要释放 token 空间限制轮次达到上限后提示用户开启新会话。评测里给出的内存数据通常是在某个固定上下文长度下测出来的。你在自己的应用里改长上下文后内存可能完全不一样需要重新压测。5.5 回退策略端侧解决不了的要有兜底方案手机端小模型的能力再强也有它的边界。比如复杂的数学推理、罕见领域的知识问答、超长文档的深刻理解端侧模型很可能做不好。一个务实的做法是设计二级策略优先用端侧模型当它给出低置信度结果或检测到任务超出能力范围时再回退到云端大模型接口。这个策略既保留端侧模型的隐私和速度优势又避免因能力不足导致用户体验崩坏。从评测角度看没有任何一份榜单能告诉你“回退阈值应该设在哪里”。这个值要靠你自己用一批真实测试样本去校准评测只能帮你确定哪些能力需要回退。5.6 典型问题的排查链路如果你的应用已经接入了端侧模型出现加载慢、卡顿、内存暴涨、发热严重或输出异常我建议按照下面的顺序排查不要一开始就怀疑模型能力先看输入输入文本是不是太长上下文累计轮次是不是超过了限制特殊格式或超长文本会导致提示词处理时间暴涨。再看模型文件量化位宽是不是合适模型是否被正确转换算子是否被推理引擎完整支持有没有版本不匹配导致的加载异常。然后看设备资源剩余可用内存还有多少后台进程占用是否严重系统温度是不是已达到降频阈值充电状态下发热会更容易放大。再看推理引擎参数上下文长度设置、batch size、线程数、是否启用了硬件加速单元。不同参数配置对性能和内存影响非常大。最后排查应用层逻辑是否每次调用都重复加载模型是否在 UI 线程同步执行了推理是不是有路径写错、资源没释放。这个链路是通用思路具体参数要结合你的设备、模型和应用场景调整。但它能帮你避免把时间浪费在错误方向上。6. 评测是照妖镜但不是地图最近手机端小模型评测越来越多这是一个积极的信号。它说明这个方向已经从“技术尝鲜”进入“工程选型”阶段行业开始需要可比较、可验证、可复现的标准。对普通开发者来说榜单的价值不在记住谁排前面而在于它帮你把候选范围缩小然后让你带着自己的真实任务去做验证。我建议每个准备使用手机端小模型的团队都建立一套自己的三步选型框架第一步看场景。你的核心用户任务是什么对延迟、离线、隐私、成本的要求是什么端侧模型是不是真的必要这一步直接决定后面要不要继续。第二步看硬件。你的最低支持机型是哪一档内存预算是多少网络环境如何把评测数据和设备参数放在一起算出模型能不能覆盖你的目标用户。第三步做压测。从榜单里挑两到三个候选放进真实应用用真实任务跑记录性能、内存、温度、稳定性和输出质量。只有这一步的结果才是你最终做决策的依据。评测的本质是把复杂问题简化成可比较的指标。它帮你降低试错成本但它永远不会替你决策。真正决定手机端小模型成败的不是榜单上那个第一名的名字而是你在自己的设备上反复跑通、长期稳定运行的那个模型。AI 模型在手机上跑起来已经不是一个能不能的问题而是怎么选、怎么调、怎么用好的问题。这套能力靠看榜单是学不来的只能靠上手。 
长河君 · 2026/8/28 20:09:29 · 阅读 1.2k 手机端小模型评测：从云端榜单到真机可用的选型指南
手机端小模型评测正在成为一条和云端榜单截然不同的赛道。过去两年我翻过大量模型评测报告MMLU、GPQA、HumanEval、长上下文、多模态……这些指标对云端部署当然有参考价值可一旦把模型放进手机问题立刻就变了模型再聪明如果装不上、跑不动、用起来烫手一切榜单分数都是空谈。Artificial Analysis 联合 Liquid AI 发布手机端小模型评测正好指向了这个断层。它想回答的不是“哪个模型理论上更强”而是“在手机这种资源受限的环境里哪个模型能真正被用起来”。这个动作背后有一个值得所有开发者认真琢磨的判断手机端小模型评测的价值不在排名本身而在它把“手机端能不能用、好不好用”这件事从一句宣传口号变成了一组可以检查、可以对比、可以验证的工程指标。这篇文章我会从评测逻辑差异、可信度判断、指标读法、落地路径四个层面展开最后给出一套从榜单到真机能复用的选型框架。1. 手机端小模型评测为什么不能沿用云端榜单的逻辑1.1 云端评测回答的是“能不能”端侧评测回答的是“跑不跑得动”云端大模型的评测核心任务是比较能力上限。测试环境基本固定GPU 资源充足内存和显存不是首要瓶颈评测机构可以放心地把模型做大、把上下文拉长然后观察它在数学、代码、推理、知识问答上的表现。手机端完全不同。一部主流中端手机的可用内存可能只有 4GB 到 8GB还要留给系统、后台应用和当前前台进程。一个 7B 模型量化后可能仍然占用两三个 GB加载后内存所剩无几即使能运行首字延迟超过两秒用户点完按钮就开始怀疑应用是不是卡死了。这种情况下继续用云端那套能力分数做判断基本等于只看菜谱不看厨房。所以端侧评测的第一个变化是把“模型能不能答对”扩展成“模型在设备上能不能稳定、及时、不烫手地回答”。这不是把同一套指标换组设备跑一遍而是从评价维度到评价方法都要重建。1.2 小模型不是大模型的“缩小版”评测维度要跟着换很多开发者对小模型有一个误解觉得它只是大模型的压缩版本能力弱一点但定位相同。实际上手机端小模型的优化目标从来不是单纯逼近大模型的能力而是“在有限资源里保留最多的可用能力”。为了塞进手机模型会被量化、剪枝、蒸馏这些操作会改变模型在不同任务上的表现分布。因此评测小模型时能力指标只是其中一个维度。真正影响决策的还包括模型文件大小、峰值内存、每 token 生成速度、首 token 延迟、连续运行后的功耗和温度、芯片平台兼容性、推理框架支持度。这些指标在云端评测里很少被当成核心排名依据但在端侧评测里每一项都可能决定一个模型的生死。1.3 为什么是现在出现这类评测手机端 AI 应用正在快速增多。语音助手、实时翻译、会议记录、OCR 识别、相册分类、输入法智能联想还有正在兴起的端侧 agent都需要模型跑在本地。端侧推理带来的隐私保护、离线可用、低延迟体验是云端 API 替代不了的。也正因为应用多了厂商和开发者都面临选型问题。过去只能靠自家测试或者看模型厂商自己发布的数据这里面既有工程条件差异也有明显的利益立场。现在评测机构与模型公司联合发布评测说明行业已经意识到端侧模型的选择不能靠单方自述需要相对中立、可复现的标准。2. 端侧评测和云端评测差异到底在哪里2.1 评测维度从能力清单变成运行体检如果只从能力分数看端侧小模型和云端大模型好像只是分数的差距但落到评测维度两者几乎不是同一个物种。我用一张表把常见差异列出来评测维度云端大模型评测手机端小模型评测核心问题模型能力上限有多高在设备上能不能稳定运行参数量级从数十亿到数千亿不等多在亿级到数十亿级模型体积通常是 GB 到百 GB 级量化后通常在几百 MB 到几 GB内存占用资源相对宽裕不作为首要瓶颈峰值内存是决定适配机型的关键推理延迟关注吞吐但对单字延迟容忍度高首字延迟和生成速度直接影响体验功耗与温度很少作为普通用户级排名指标持续运行的发热和耗电是硬指标硬件兼容性相对统一的 GPU 环境芯片、系统、推理框架差异巨大评测任务学术能力集、长文本、复杂推理日常短任务、离线场景、低资源前提这张表不是某一份具体评测的细则更像是一份通用导读。你去看任何手机端评测如果它只报告能力分数不报告运行环境那么结论就缺乏落地参考价值。真实端侧评测里还有一类指标容易被忽略冷启动加载时间。模型首次加载要读文件、建内存、初始化推理引擎这个过程可能持续数秒。如果应用每次启动都要重新加载用户会非常不耐烦。评测如果不区分冷启动和热推理很多问题会被掩盖。2.2 任务设计要贴近真实场景而不是学术测试题云端评测常用的 MMLU、BBH、HumanEval 这类基准对学术研究很有价值但在手机上用户不会让模型做一套完整的多选题。真实场景是短文本摘要、信息抽取、几轮连续对话、离线状态下听懂含糊的语音指令、拍一张照片后快速提取文字。一份靠谱的手机端小模型评测通常会同时覆盖三条线通用能力抽样用一批难度适中、格式稳定的任务验证基本能力性能测试记录不同输入长度、不同并发任务下的延迟、内存和功耗场景模拟把任务设计成贴近应用实际调用的样子比如限制输出长度、限制上下文轮次、要求离线完成。所以你看评测时不能只看它跑了几道题还要看它的任务输入是不是真的贴近用户操作。一个模型在短任务上很强在长上下文中表现崩掉这在手机端很常见。2.3 统一评测环境是端侧评测最难做到又最该较真的地方手机端评测最大的坑是环境很难统一。芯片不同、系统版本不同、内存管理策略不同、推理引擎对算子的优化程度不同都会导致结果天差地别。同一个模型在一部旗舰机上可能运行流畅到中端机上可能加载就要十几秒。所以一份可信的手机端评测至少要做三件事明确标注测试设备和系统版本明确量化方式、上下文长度、推理框架和关键参数提供可复现路径让开发者可以按同样的条件验证。如果评测报告里没有这些信息只给一个综合排名那它的参考价值和厂商宣传稿差别不大。这不是说评测机构一定有问题而是作为使用者你要先确认边界再读结论。3. 评测机构加模型公司联合发布为什么值得多看几眼3.1 单方自说自话的公信力瓶颈如果模型厂商只发布自家跑分你一定会怀疑它只挑好听的说。这是正常的信任防御机制不是针对哪一家。反过来如果第三方机构评测又缺少模型公司的工程支持它可能拿到一个没有经过合适量化的模型或者用错误的上下文长度、不兼容的推理引擎跑了结果最后得出的结论并不代表这个模型在真实部署中的水平。联合发布的价值在于第三方机构负责设计评测方法和保持方法论独立模型公司提供模型访问、运行配置和工程支持。两者共同发布结果一方面减少了信息不对称另一方面也把评测从“理论抽测”往前推进了一步更接近模型真正被部署时的状态。3.2 联合评测的好处不等于无条件信任关联合作会不会影响客观性肯定会带来这样的疑问。所以你在看这类评测时要重点检查几个点评测方法是否公开是否给出完整的测试环境配置是否存在只挑优势场景展示的倾向是否包含失败案例、局限场景模型公司是否有权限干预最终排行。如果这些信息是透明的那么联合发布的参考价值是大于单方宣传的。如果这些信息缺失即使来源听起来很权威也要保持保留。3.3 对开发者的现实意义从“看排名”变成“看条件”我见过不少团队看到一份榜单就直接选第一名接入结果在自家目标机型上表现很差。原因很简单榜单的第一名可能是在高位设备、特定量化、特定任务下拿到的而你的真实用户群更多是中低端机型任务类型也不一样。正确的姿势是把榜单当漏斗不把它当答案。先用榜单筛出三五个值得测试的候选模型然后带入自己的场景做真机验证。这一步省不了评测只能帮你把“要从几十个模型里挑”变成“要从三五个模型里挑”。4. 看手机端小模型评测最该盯住这四类数据4.1 体积与内存占用决定“能不能装机”在手机端体积不是小事。当前主流应用安装包已经有几十 MB 甚至上百 MB模型文件动辄几百 MB会影响下载转化率也会占用用户的存储空间。比文件体积更重要的是峰值内存占用。模型加载后的常驻内存加上推理时的临时内存如果超过了系统可用内存的合理比例应用就会面临被系统杀后台、卡顿甚至闪退的风险。所以我建议你做一张配置表把候选模型的文件大小、量化位宽、加载后内存、推理峰值内存分别列出来再对照你的最低支持机型去判断。这一步越早做越好不要等到功能开发完才发现机型覆盖不了。4.2 延迟和吞吐决定“体验顺不顺”手机端用户对延迟的忍耐度很低。点击之后如果超过一秒都没反应用户就会觉得应用卡。所以评测里的首 token 延迟和生成速度直接影响产品体验。这里有一个常被忽略的细节输入较长时提示词处理时间会比生成过程更长。比如用户粘贴一大段文章要求摘要模型要先把整篇文章的 token 处理完才开始输出摘要。如果评测只报告生成阶段的速度不报告提示词处理时间你会在真实场景里发现明显偏慢。看评测时要区分短输入和长输入。一个在短任务上很快的模型不一定能扛住长文档处理反之亦然。4.3 功耗和散热决定“能不能长期用”手机端模型评测如果只看速度和准确率会漏掉一个最容易毁掉体验的变量发热。连续跑几轮对话后手机温度上升系统可能会主动降频推理速度会肉眼可见地下降。如果模型持续调用大算力单元电量和温度都会走高用户很快会感受到“用了一会儿就发烫、掉电快”。好的端侧评测会把连续压力测试的结果放出来比如连续运行后温度上升了几度、电池消耗多少、速度下降多少。这些数据比单轮跑分更接近真实使用。如果你的应用需要长时间保持前台运行这个维度甚至比准确率更重要。4.4 能力指标决定“换得值不值”最后才是能力分数。看能力分数时不要只看综合分要看任务分。不同小模型的能力分布差异很大有的强在指令跟随有的强在中文理解有的强在代码生成有的是通用但平庸。先列出你的核心任务类型再去看对应任务上的表现。两个综合分相同的模型在你需要的任务上可能差出一大截。你在选型时真正关心的应该是“这个模型在我这个场景里够不够用”而不是“它在所有任务上是不是平均分最高”。5. 评测之外把端侧小模型落进真实项目还差几步5.1 先跑通单条样例再谈批量使用把模型接入手机端的第一个目标不是调到最优而是跑通一条完整链路。我建议按这个顺序来选定一个目标测试设备最好是你的用户群体中占比最高的机型把模型转换成你的推理引擎支持的格式从最简单的输入开始确认加载、推理、输出都能正常完成记录基线数据加载时间、首 token 延迟、峰值内存、温度变化再验证两条真实业务样例看看输出质量是否可用。跑通之后再逐步增加上下文长度、测试多轮对话、接入更复杂的业务逻辑。不要一上来就塞进完整业务流程否则出了问题很难定位到底是谁的锅。5.2 真机覆盖要分档不要只看旗舰机同一个模型在不同档位手机上的表现差距很大。实际落地时至少要在三个档位测试低端机确认基本可用主要看加载时间、内存、发热是否在可接受范围中端机承担主要体验优化覆盖大多数用户旗舰机看模型的性能上限也用来判断未来功能扩展空间。只测旗舰机的项目往往上线后才会发现低端机的崩溃率远高于预期。这属于非常典型的踩坑点。5.3 模型格式、量化方式和推理引擎要提前对齐手机端模型通常需要经过量化才能塞进内存。常见的量化位宽有 FP16、INT8、INT4不同位宽对模型体积、内存、推理速度、能力损失的影响都不一样。这里有一个很现实的坑某些推理引擎对算子和量化方式的支持是有限制的。一个模型在 Python 端测试时表现很好转成端侧格式后部分层可能不支持导致运行报错或者精度下降。所以选型时不要只看模型算法本身还要确认你的目标推理引擎能不能完整支持它。另外手机端还有一个非常常见的问题打包工具链版本和手机端 SDK 版本不匹配导致模型推理库加载失败。这类问题看起来像是模型加载 bug实际是 so 库和宿主环境不匹配排查时经常绕远路。遇到加载失败先检查工具链和 SDK 的版本对应关系再去看模型文件和代码逻辑。5.4 上下文长度与会话管理内存暴涨的常见源头手机端内存有限上下文长度不是越大越好。当上下文超过模型配置上限或设备内存承受范围时推理内存会快速上涨最终导致闪退。常见解决思路有三类滑动窗口只保留最近几轮对话历史摘要把早期轮次浓缩成一段摘要释放 token 空间限制轮次达到上限后提示用户开启新会话。评测里给出的内存数据通常是在某个固定上下文长度下测出来的。你在自己的应用里改长上下文后内存可能完全不一样需要重新压测。5.5 回退策略端侧解决不了的要有兜底方案手机端小模型的能力再强也有它的边界。比如复杂的数学推理、罕见领域的知识问答、超长文档的深刻理解端侧模型很可能做不好。一个务实的做法是设计二级策略优先用端侧模型当它给出低置信度结果或检测到任务超出能力范围时再回退到云端大模型接口。这个策略既保留端侧模型的隐私和速度优势又避免因能力不足导致用户体验崩坏。从评测角度看没有任何一份榜单能告诉你“回退阈值应该设在哪里”。这个值要靠你自己用一批真实测试样本去校准评测只能帮你确定哪些能力需要回退。5.6 典型问题的排查链路如果你的应用已经接入了端侧模型出现加载慢、卡顿、内存暴涨、发热严重或输出异常我建议按照下面的顺序排查不要一开始就怀疑模型能力先看输入输入文本是不是太长上下文累计轮次是不是超过了限制特殊格式或超长文本会导致提示词处理时间暴涨。再看模型文件量化位宽是不是合适模型是否被正确转换算子是否被推理引擎完整支持有没有版本不匹配导致的加载异常。然后看设备资源剩余可用内存还有多少后台进程占用是否严重系统温度是不是已达到降频阈值充电状态下发热会更容易放大。再看推理引擎参数上下文长度设置、batch size、线程数、是否启用了硬件加速单元。不同参数配置对性能和内存影响非常大。最后排查应用层逻辑是否每次调用都重复加载模型是否在 UI 线程同步执行了推理是不是有路径写错、资源没释放。这个链路是通用思路具体参数要结合你的设备、模型和应用场景调整。但它能帮你避免把时间浪费在错误方向上。6. 评测是照妖镜但不是地图最近手机端小模型评测越来越多这是一个积极的信号。它说明这个方向已经从“技术尝鲜”进入“工程选型”阶段行业开始需要可比较、可验证、可复现的标准。对普通开发者来说榜单的价值不在记住谁排前面而在于它帮你把候选范围缩小然后让你带着自己的真实任务去做验证。我建议每个准备使用手机端小模型的团队都建立一套自己的三步选型框架第一步看场景。你的核心用户任务是什么对延迟、离线、隐私、成本的要求是什么端侧模型是不是真的必要这一步直接决定后面要不要继续。第二步看硬件。你的最低支持机型是哪一档内存预算是多少网络环境如何把评测数据和设备参数放在一起算出模型能不能覆盖你的目标用户。第三步做压测。从榜单里挑两到三个候选放进真实应用用真实任务跑记录性能、内存、温度、稳定性和输出质量。只有这一步的结果才是你最终做决策的依据。评测的本质是把复杂问题简化成可比较的指标。它帮你降低试错成本但它永远不会替你决策。真正决定手机端小模型成败的不是榜单上那个第一名的名字而是你在自己的设备上反复跑通、长期稳定运行的那个模型。AI 模型在手机上跑起来已经不是一个能不能的问题而是怎么选、怎么调、怎么用好的问题。这套能力靠看榜单是学不来的只能靠上手。