这次我们来看一个评测事件不是单个模型。Artificial Analysis 联合 Liquid AI 发布了针对手机端小模型的评测。这个事值得关注的地方在于它把大模型对比从“GPU 集群上的基准跑分”拉到了“手机能不能流畅跑、跑多久会发热、内存够不够、延迟可不可接受”的真实端侧维度。文章会拆解手机端小模型评测的维度、端侧评测的复现思路、性能观察方法以及做这类评测时最常见的坑。适合对端侧 AI、小模型部署和模型评测感兴趣的开发者和算法工程师。先说结论端侧小模型评测和服务器端评测完全是两套思路。服务器端更关心吞吐和综合能力分手机端更关心单次请求延迟、峰值内存、能效和持续稳定性。Artificial Analysis 和 Liquid AI 这次把评测焦点放到手机端意味着小模型的战场开始从“能不能在云端跑出高分”转向“能不能在用户手里长期跑得动”。1. 核心能力速览先把这次评测相关的能力和边界整理成一张表。需要说明的是截至本文写作时公开材料并没有给出完整的评测集、设备列表和具体分数所以下表只标注已经确认的方向和仍需实测验证的部分。能力项说明参与方Artificial Analysis第三方模型评测平台、Liquid AI模型研发团队评测对象手机端可运行的小尺寸语言模型包括 Liquid AI 自身的小模型和同量级开源小模型核心评测维度文本生成质量、推理延迟、内存占用、能效、设备适配性、长上下文稳定性关联能力扩展agent 类任务评测信号如工具调用、多轮任务成功率可参考 swe-bench 这类任务设计端侧关注重点首 token 延迟、解码吞吐、峰值内存、发热降频、多轮对话稳定性硬件要求以 Android 手机为主具体芯片平台和内存规格需以官方评测说明为准启动方式评测本身是离线跑测模型部署通常使用 llama.cpp、MLC LLM、ONNX Runtime Mobile 等端侧推理框架接口 API端侧模型可本地起 HTTP 服务但这不是评测必需品批量任务评测通常需要批量跑测试样本适合脚本化执行适合场景端侧模型选型、量化方案对比、芯片平台对比、本地部署前预研不确定项具体测试集、设备清单、量化规格、官方榜单分数需等完整评测报告从这张表能看出这次评测的本质是给“手机端小模型”建立一个可比较的标尺。以前大家在服务器端用 MMLU、HumanEval、GSM8K 这些基准对比模型但这些基准并不能回答一个关键问题同一块手机芯片上这个模型到底能不能在 2 秒内给出回答会不会占用超过 4GB 内存连续跑会不会过热。2. 这次事件为什么值得关注Artificial Analysis 是第三方模型评测平台长期在做大模型能力对比、价格和速度分析它的榜单经常被作为模型选择的参考。Liquid AI 则以 LFMLiquid Foundation Models系列进入大模型赛道主打非 Transformer 架构或混合架构强调更低的推理内存占用和更长的上下文处理能力。这两家联合做手机端小模型评测释放了几个信号。第一端侧 AI 的评测不再满足于“能不能跑”而是进入“跑得有多好”的阶段。手机端小模型的价值不在单轮得分而在持续可用性。用户不会关心模型在云端跑 MMLU 拿了多少分只会关心手机上的语音助手响应快不快、离线翻译准不准、连续对话会不会卡顿。第二小模型的评测维度正在从单一能力分转向多维工程指标。文本质量、延迟、内存、能效、设备适配性必须放在一起看。一个模型在服务器端跑分很高但量化到 INT4 后质量大幅下降或者 INT4 版本在某些芯片上算子不支持这个模型就不适合作为端侧方案。第三Liquid AI 这类新架构模型需要新的评测传播方式。新架构的优势如果在云端大集群上体现不明显那在内存受限的手机端反而更容易拉开差距。联合第三方评测平台来做这件事比自说自话更有说服力。对于开发者来说这件事的实际价值在于以后做端侧模型选型时可以多一个参考榜单。但也要注意榜单只能作为初筛最终选型仍然要放在自己的目标设备和真实业务场景里跑一轮验证。3. 手机端小模型评测到底测什么手机端小模型评测不能简单照搬服务器端基准它需要围绕端侧真实使用场景设计。从公开信息和评测常识来看至少包含以下维度。3.1 文本质量与小模型能力基线能力分依然是基础。需要验证模型在指令跟随、知识问答、数学推理、代码生成、摘要、改写等常见任务上的表现。对于手机端场景不会测极限难度的任务而是更关注日常高频任务写一条短信、总结一段会议记录、解释一个概念、生成一段可运行的代码片段。这类能力评测需要固定采样参数。温度、top_p、repetition_penalty 等参数不同同一模型的生成质量会有明显差异。正规评测会固定一组参数多次采样取均值减少随机性。3.2 首 token 延迟与解码吞吐这是端侧模型最核心的体验指标。首 token 延迟TTFTTime To First Token决定了用户等待第一句话出现的时间。手机端模型通常追求 TTFT 在几百毫秒到 2 秒以内。解码吞吐tokens/s决定了后续生成流畅度。如果模型只有 3 tokens/s用户等一整段回答会非常痛苦如果能到 20 tokens/s 以上体验就比较接近可用状态。实测时需要注意不同量化规格和推理框架对吞吐影响极大。INT4 量化通常能显著提升速度但也会带来质量损失评测需要同时记录速度和质量两组指标。3.3 内存占用与能效内存是手机端模型的硬约束。一个 7B 模型即使量化到 INT4权重也需要约 4GB 左右再加上激活值、KV Cache 和系统开销对大多数手机来说压力很大。所以手机端小模型评测通常选择 1B 到 4B 范围或者更小。能效指标可以用每生成一定量 token 的耗电量来评估也可以观察连续推理时的温升曲线。手机不同于服务器没有主动散热芯片一旦过热就会降频导致推理速度断崖式下降。这也是为什么“首轮跑得快”不代表“连续十轮还快”。3.4 长上下文与多轮稳定性手机端 AI 助手通常是多轮对话模型需要在上下文不断增长的情况下保持稳定。评测要覆盖长上下文输入的延迟变化生成的遗忘或重复问题KV Cache 内存随对话轮次的增长连续对话导致的显存/内存压力。对于 agent 类任务这一维度尤其重要。agent 需要多轮工具调用每一步都要保留历史信息。评测时要模拟工具调用轨迹而不是只测单轮问答。3.5 设备适配性与算子兼容性手机端推理框架依赖特定算子实现。同一个模型在不同芯片上可能表现完全不同高通骁龙、联发科天玑、苹果 A 系列、以及各类国产芯片对 INT4 量化和自定义算子的支持程度都不一样。评测如果覆盖多台手机就能看出模型和框架的适配边界。4. 评测方法论从服务器基准到端侧跑分端侧小模型评测不能直接把服务器评测脚本搬过来需要重新设计评测流程。4.1 服务器评测与端侧评测的差异服务器评测通常有稳定的 GPU 环境、充足的内存和主动散热评测重点是模型推理质量和大并发吞吐。端侧评测则是资源受限环境CPU/GPU 共享功耗、内存带宽有限、无主动散热、存储读写速度受限。这导致端侧评测要额外关注冷启动时间模型从加载到可推理需要多久。峰值内存加载瞬间和推理过程中的内存波动。热降频时间点连续推理多久后会降频降频后性能下降多少。功耗曲线不同生成阶段的功耗变化。4.2 评测流程设计一次完整的端侧小模型评测可以这样设计确定目标设备、操作系统版本、可用内存、芯片型号。选择待测模型和量化规格。准备评测数据集覆盖通用能力、代码、数学、摘要、多轮对话、agent 工具调用等场景。将模型转换为端侧推理框架支持的格式。编写评测脚本逐条执行测试样本记录延迟、吞吐、内存、功耗、输出内容。对输出结果做质量评分。多轮运行取平均值排除偶然波动。汇总生成对比报告。这里可以借鉴传统在线评测系统的思路。一本通在线评测系统这类 OJ 工具通过限定输入输出、设置超时和内存限制来判定程序是否正确。端侧模型评测没有标准答案但同样需要设置超时和内存上限避免一个坏 case 拖垮整轮评测。Lemon 这类评测工具的思路也值得参考按测试点计分、超时判定、内存限制、批量跑测、输出汇总报告。模型评测可以在相同思想下扩展将单个测试样本视为一个测试点模型输出视为待判定的结果。4.3 评测集质量是前提评测集质量直接决定评测结果可信度。高质量数据集质量评测规范通常包含数据来源可追溯测试集与训练集无交叉题目覆盖均衡不偏向某个模型答案标准明确可重复判定污染检测防止测试样本出现在训练语料中。如果测试集和训练集混在一起评测结果基本没有参考价值。评测前至少要做一次相似度去重。4.4 agent 任务评测的新维度agent 评测比单纯问答复杂得多。它不仅要评估模型生成文本的能力还要评估模型是否能在多轮工具调用中正确决策。参考 swe-bench 这类真实软件工程任务评测agent 评测需要设计任务环境给模型一个真实问题例如“修复某个仓库的 bug”。可用工具定义模型可以调用的工具如文件读取、代码搜索、命令执行。多轮轨迹记录每一步工具调用和模型决策。最终结果以任务是否完成为标准而不是以文本相似度为标准。手机端小模型做 agent 任务难点在于上下文控制和延迟。工具调用会快速消耗上下文长度手机端内存也会随之增长。评测时要设定上下文上限观察模型在上限附近的决策质量。5. 复现思路自己跑一轮端侧小模型评测如果你看完评测报告想在自己手机上复现可以参考下面的流程。注意这不是某个具体项目的完整安装教程而是一套通用端侧评测方法。5.1 准备端侧推理框架常见选择包括 llama.cpp、MLC LLM、ONNX Runtime Mobile、ExecuTorch、MediaPipe LLM Inference 等。每个框架对芯片和算子的支持不同建议根据目标设备选择。这里给出通用量化加载和推理的逻辑实际调用需要替换为你选择的框架 API。5.2 准备模型与量化版本从模型仓库下载小模型权重然后用框架提供的量化工具转换成 INT4 或 INT8 版本。保留原始权重方便对比量化前后的质量差异。5.3 准备评测数据准备一个 JSONL 格式的测试集每条包含一个唯一 ID 和测试 prompt。可以从公开评测集中抽取子集也可以根据业务场景自建。{id: 1, prompt: 用一句话解释什么是端侧推理} {id: 2, prompt: 写一段 Python 代码计算斐波那契数列} {id: 3, prompt: 把下面这段文本压缩成三个关键词人工智能正在改变手机应用的使用方式。}5.4 编写评测脚本以下脚本是框架示例核心逻辑是逐条推理并记录指标。# 端侧小模型评测脚本框架示例需按实际推理框架替换 import time import json from typing import List, Dict def load_model(model_path: str): # TODO: 替换为实际推理框架加载逻辑 # 例如 llama.cpp、MLC LLM、ONNX Runtime Mobile 等 return {model_path: model_path} def generate(model, prompt: str, max_tokens: int 128): # 返回生成文本、首 token 延迟、总耗时、生成 token 数 start time.time() first_token_latency None generated_tokens 0 # 此处为伪代码实际应调用框架的流式生成接口 # first_token_latency 0.3 # generated_tokens 128 total_time time.time() - start return { text: 生成的文本, first_token_latency: first_token_latency, total_time: total_time, generated_tokens: generated_tokens, } def run_eval(model, dataset: List[Dict]) - List[Dict]: results [] for item in dataset: prompt item[prompt] r generate(model, prompt) results.append({ case_id: item[id], input_tokens: len(prompt), output_text: r[text], first_token_latency: r[first_token_latency], tokens_per_second: r[generated_tokens] / r[total_time] if r[total_time] else 0, }) return results if __name__ __main__: dataset json.load(open(./data/dev_set.jsonl, encodingutf-8)) model load_model(./models/example_q4.gguf) results run_eval(model, dataset) print(json.dumps(results, ensure_asciiFalse, indent2))运行方式python eval.py5.5 批量对比多个模型如果你有多个模型需要对比可以写一个 shell 脚本循环执行。#!/bin/bash # 批量评测脚本示例循环执行 eval.py参数包括模型路径和输出文件 MODELS( ./models/model_a_q4.gguf ./models/model_b_q4.gguf ./models/model_b_q8.gguf ) OUTPUT_DIR./eval_results mkdir -p $OUTPUT_DIR for model in ${MODELS[]}; do name$(basename $model .gguf) echo Running eval: $name python eval.py \ --model $model \ --dataset ./data/dev_set.jsonl \ --output $OUTPUT_DIR/${name}.json \ --max-tokens 128 if [ $? -ne 0 ]; then echo ERROR: $name failed | tee -a $OUTPUT_DIR/error.log else echo OK: $name fi done5.6 评测参数建议固定采样参数非常重要。建议使用低温度多次采样取平均结果。{ model: ./models/example_q4.gguf, dataset: ./data/dev_set.jsonl, max_tokens: 128, temperature: 0.2, top_p: 0.9, repetition_penalty: 1.1, metrics: [first_token_latency, tokens_per_second, memory_peak_mb], output: ./eval_results/example_result.json }6. 如何读评测报告核心指标与常见误读评测报告出来之后最忌讳直接看排行榜总分。要拆开看细节。延迟要区分首 token 延迟和解码吞吐。首 token 延迟低的模型未必整体生成速度快。有的模型擅长快速输出第一个字但后续生成速度很慢长文本场景会很吃亏。内存要区分模型权重大小和实际峰值内存。权重文件 2GB不代表推理过程只要 2GB。激活值、KV Cache、临时缓冲都会增加内存占用。评测报告里的内存数字需要看是空闲内存还是峰值内存。能效不能只看功耗单点。要看连续运行一段时间后的温升和降频情况。手机没有主动散热热降频是端侧推理经常踩的坑。一个模型首轮推理很快连续跑五分钟可能因为发热降到一半速度。能力分要看测试集构成。如果测试集偏向代码就不适合用来评估日常问答助手如果偏向数学对通用对话场景的参考价值也有限。需要关注评测集是否做了能力分层。量化前后对比非常关键。同一模型 INT8 和 INT4 的能力差异比不同模型之间的差异可能更大。评测报告要说明每个分数对应的量化规格。否则你看到的高分 INT8 版本可能在手机上根本装不下。另外要警惕评测集污染。一些模型训练时可能已经见过评测集题目导致分数虚高。第三方评测平台的价值在于尽量控制污染但完全杜绝很难。自己复现评测时最好从没有公开传播过的新测试样本中抽一部分做验证集。7. 手机端部署与性能优化观察如果你不满足于跑评测想把小模型真正部署到手机端有几个通用优化方向。7.1 量化级别选择INT4 在速度和内存上有优势但质量损失明显。INT8 更接近原始模型但内存占用更高。建议的做法是先跑原始权重记录质量基线再跑 INT8观察质量下降比例最后跑 INT4看是否在可接受范围内。中小尺寸模型在 INT4 下质量下降通常可控但也要结合具体任务判断。7.2 推理框架与算子选择不同的推理框架在小模型端侧推理上的实现效率差异很大。芯片平台决定了框架能调用哪些加速算子建议优先选择目标芯片有优化支持的框架。框架没有对应算子的模型结构在 CPU 上可能会退化为慢速通用实现。7.3 显存/内存观察方法在评测脚本中增加内存监控记录推理前后的峰值。常见做法是在子进程中运行推理主进程定时采样内存信息。也可在模拟器中反复跑同一推理任务用系统自带的资源监视器观察内存曲线。7.4 版本一致性检查如果你不是直接用命令行部署而是把模型集成到自研 App 或 SDK 中要特别注意编译环境与目标设备 SDK 版本的一致性。例如前端/容器层用较新版本的编译器打包而目标设备上的 SDK 版本较低就可能导致模型加载接口不可用或推理结果异常。现象往往是模拟器上正常真机上崩溃或同一套代码在这台手机上正常另一台手机上报错。排查时要先确认编译环境版本和手机端 SDK 版本是否匹配。7.5 端口与进程资源部分端侧推理框架支持以本地 HTTP 服务方式运行。如果你打算把模型封装成服务给上层应用调用要注意本地端口占用和进程残留问题。# 本地起一个简单的推理服务框架示例具体命令以实际框架为准 python server.py --host 127.0.0.1 --port 8080 --model ./models/example_q4.gguf调用测试可以使用 curlcurl -X POST http://127.0.0.1:8080/generate \ -H Content-Type: application/json \ -d {prompt: 用一句话解释什么是端侧推理, max_tokens: 128}服务化部署后批量任务就可以通过 HTTP 请求驱动方便接入上层业务。7.6 性能观察清单实测时建议记录以下数据模型完整加载耗时冷启动首次推理耗时连续运行 5 分钟、10 分钟后的推理速度推理过程中的峰值内存设备外壳温度变化降频后速度恢复时间。这些数据能真实反映“手机端能不能持续用”这个核心问题。8. 常见问题与排查方法端侧小模型评测过程中会遇到很多环境问题下面是高频排查清单。问题现象可能原因排查方式解决方案模型加载失败模型文件损坏或格式不受支持检查模型文件完整性确认框架支持的量化格式重新下载模型转换格式量化后输出质量明显下降量化级别过低或校准数据不匹配对比原始权重和量化版本的输出使用 INT8 替代 INT4重新做校准推理速度远低于预期算子未走加速实现或设备热降频检查框架日志观察 CPU/GPU 占用和温度更换框架或算子实现降低持续负载首 token 延迟高模型体积大、上下文填充耗时拆解耗时确认是否卡在 prompt 处理阶段减小 prompt 长度使用更激进的量化内存占用过高KV Cache 过大或激活值峰值高分阶段记录内存变化缩短上下文长度批量跑测时降低并发多轮对话越来越慢KV Cache 持续增长观察内存增长曲线限制上下文窗口或使用 KV Cache 量化同一模型不同手机表现差异大芯片算子支持不同、内存带宽不同分别记录每台设备的日志按设备集团队做针对性优化接口调用失败端口被占用或服务未启动检查端口和进程日志更换端口重启服务批量任务卡住单条测试样本超时或返回异常设置单条超时和重试机制增加超时上限跳过异常样本集成到 App 后运行时崩溃编译环境与手机端 SDK 版本不匹配检查编译工具版本、SDK 版本、架构兼容性统一编译环境和目标设备 SDK 版本这些排查项同样适用于端侧模型服务化和批量评测的工程化场景。9. 评测合规与隐私边界端侧模型评测涉及模型、数据、设备和部署方式有一些合规和隐私边界需要明确。自建评测集时不要使用未授权抓取的文本、人脸照片、声音样本或包含个人隐私的数据。评测过程如果使用真实用户对话数据必须提前脱敏并确认数据来源合法。涉及 agent 任务评测时如果评测环境包含真实工具、代码仓库或在线服务要注意不要对线上系统产生不可控影响。建议使用隔离的测试环境避免评测脚本误操作真实业务资源。涉及人脸、声音、肖像等敏感内容的评测必须获得明确授权。人脸生成、声音克隆、数字人相关能力在合规要求上非常严格评测样本和部署方案都需要谨慎。模型发布或商用前要做一轮完整效果复核。评测分数只能说明模型在特定测试集上的表现不能替代真实业务场景的验收。建议在正式发布前用你的真实数据再跑一轮小样本验证。10. 总结与下一步Artificial Analysis 联合 Liquid AI 发布的手机端小模型评测把行业关注点从服务器端跑分拉到了端侧可用性。手机端小模型评测的关键不止于能力分更在于延迟、内存、能效、热降频、多轮稳定性和设备适配性。如果你要做端侧模型选型最先应该验证的是目标设备上的实际推理速度、峰值内存和连续运行稳定性。建议先跑一个小数据集固定采样参数记录首 token 延迟、解码吞吐和内存曲线再结合能力分做综合判断。最容易踩的坑有三个只看榜单分不看量化规格、不看延迟细分指标、忽略设备热降频问题。评测数据集质量也容易被忽略测试集一旦被污染所有对比都失去意义。下一步可以扩展的方向很多把 agent 评测纳入端侧模型对比建立自己的端侧 benchmark 基线跟踪不同芯片平台的算子支持差异以及把评测脚本沉淀成自动化批量任务。端侧小模型评测会越来越像传统软件测试一样成为模型发布前的标准环节。这篇内容建议收藏备用后面做端侧模型选型时可以对照着搭一套自己的评测流程。 手机端小模型评测：核心维度、复现思路与性能优化实践
这次我们来看一个评测事件不是单个模型。Artificial Analysis 联合 Liquid AI 发布了针对手机端小模型的评测。这个事值得关注的地方在于它把大模型对比从“GPU 集群上的基准跑分”拉到了“手机能不能流畅跑、跑多久会发热、内存够不够、延迟可不可接受”的真实端侧维度。文章会拆解手机端小模型评测的维度、端侧评测的复现思路、性能观察方法以及做这类评测时最常见的坑。适合对端侧 AI、小模型部署和模型评测感兴趣的开发者和算法工程师。先说结论端侧小模型评测和服务器端评测完全是两套思路。服务器端更关心吞吐和综合能力分手机端更关心单次请求延迟、峰值内存、能效和持续稳定性。Artificial Analysis 和 Liquid AI 这次把评测焦点放到手机端意味着小模型的战场开始从“能不能在云端跑出高分”转向“能不能在用户手里长期跑得动”。1. 核心能力速览先把这次评测相关的能力和边界整理成一张表。需要说明的是截至本文写作时公开材料并没有给出完整的评测集、设备列表和具体分数所以下表只标注已经确认的方向和仍需实测验证的部分。能力项说明参与方Artificial Analysis第三方模型评测平台、Liquid AI模型研发团队评测对象手机端可运行的小尺寸语言模型包括 Liquid AI 自身的小模型和同量级开源小模型核心评测维度文本生成质量、推理延迟、内存占用、能效、设备适配性、长上下文稳定性关联能力扩展agent 类任务评测信号如工具调用、多轮任务成功率可参考 swe-bench 这类任务设计端侧关注重点首 token 延迟、解码吞吐、峰值内存、发热降频、多轮对话稳定性硬件要求以 Android 手机为主具体芯片平台和内存规格需以官方评测说明为准启动方式评测本身是离线跑测模型部署通常使用 llama.cpp、MLC LLM、ONNX Runtime Mobile 等端侧推理框架接口 API端侧模型可本地起 HTTP 服务但这不是评测必需品批量任务评测通常需要批量跑测试样本适合脚本化执行适合场景端侧模型选型、量化方案对比、芯片平台对比、本地部署前预研不确定项具体测试集、设备清单、量化规格、官方榜单分数需等完整评测报告从这张表能看出这次评测的本质是给“手机端小模型”建立一个可比较的标尺。以前大家在服务器端用 MMLU、HumanEval、GSM8K 这些基准对比模型但这些基准并不能回答一个关键问题同一块手机芯片上这个模型到底能不能在 2 秒内给出回答会不会占用超过 4GB 内存连续跑会不会过热。2. 这次事件为什么值得关注Artificial Analysis 是第三方模型评测平台长期在做大模型能力对比、价格和速度分析它的榜单经常被作为模型选择的参考。Liquid AI 则以 LFMLiquid Foundation Models系列进入大模型赛道主打非 Transformer 架构或混合架构强调更低的推理内存占用和更长的上下文处理能力。这两家联合做手机端小模型评测释放了几个信号。第一端侧 AI 的评测不再满足于“能不能跑”而是进入“跑得有多好”的阶段。手机端小模型的价值不在单轮得分而在持续可用性。用户不会关心模型在云端跑 MMLU 拿了多少分只会关心手机上的语音助手响应快不快、离线翻译准不准、连续对话会不会卡顿。第二小模型的评测维度正在从单一能力分转向多维工程指标。文本质量、延迟、内存、能效、设备适配性必须放在一起看。一个模型在服务器端跑分很高但量化到 INT4 后质量大幅下降或者 INT4 版本在某些芯片上算子不支持这个模型就不适合作为端侧方案。第三Liquid AI 这类新架构模型需要新的评测传播方式。新架构的优势如果在云端大集群上体现不明显那在内存受限的手机端反而更容易拉开差距。联合第三方评测平台来做这件事比自说自话更有说服力。对于开发者来说这件事的实际价值在于以后做端侧模型选型时可以多一个参考榜单。但也要注意榜单只能作为初筛最终选型仍然要放在自己的目标设备和真实业务场景里跑一轮验证。3. 手机端小模型评测到底测什么手机端小模型评测不能简单照搬服务器端基准它需要围绕端侧真实使用场景设计。从公开信息和评测常识来看至少包含以下维度。3.1 文本质量与小模型能力基线能力分依然是基础。需要验证模型在指令跟随、知识问答、数学推理、代码生成、摘要、改写等常见任务上的表现。对于手机端场景不会测极限难度的任务而是更关注日常高频任务写一条短信、总结一段会议记录、解释一个概念、生成一段可运行的代码片段。这类能力评测需要固定采样参数。温度、top_p、repetition_penalty 等参数不同同一模型的生成质量会有明显差异。正规评测会固定一组参数多次采样取均值减少随机性。3.2 首 token 延迟与解码吞吐这是端侧模型最核心的体验指标。首 token 延迟TTFTTime To First Token决定了用户等待第一句话出现的时间。手机端模型通常追求 TTFT 在几百毫秒到 2 秒以内。解码吞吐tokens/s决定了后续生成流畅度。如果模型只有 3 tokens/s用户等一整段回答会非常痛苦如果能到 20 tokens/s 以上体验就比较接近可用状态。实测时需要注意不同量化规格和推理框架对吞吐影响极大。INT4 量化通常能显著提升速度但也会带来质量损失评测需要同时记录速度和质量两组指标。3.3 内存占用与能效内存是手机端模型的硬约束。一个 7B 模型即使量化到 INT4权重也需要约 4GB 左右再加上激活值、KV Cache 和系统开销对大多数手机来说压力很大。所以手机端小模型评测通常选择 1B 到 4B 范围或者更小。能效指标可以用每生成一定量 token 的耗电量来评估也可以观察连续推理时的温升曲线。手机不同于服务器没有主动散热芯片一旦过热就会降频导致推理速度断崖式下降。这也是为什么“首轮跑得快”不代表“连续十轮还快”。3.4 长上下文与多轮稳定性手机端 AI 助手通常是多轮对话模型需要在上下文不断增长的情况下保持稳定。评测要覆盖长上下文输入的延迟变化生成的遗忘或重复问题KV Cache 内存随对话轮次的增长连续对话导致的显存/内存压力。对于 agent 类任务这一维度尤其重要。agent 需要多轮工具调用每一步都要保留历史信息。评测时要模拟工具调用轨迹而不是只测单轮问答。3.5 设备适配性与算子兼容性手机端推理框架依赖特定算子实现。同一个模型在不同芯片上可能表现完全不同高通骁龙、联发科天玑、苹果 A 系列、以及各类国产芯片对 INT4 量化和自定义算子的支持程度都不一样。评测如果覆盖多台手机就能看出模型和框架的适配边界。4. 评测方法论从服务器基准到端侧跑分端侧小模型评测不能直接把服务器评测脚本搬过来需要重新设计评测流程。4.1 服务器评测与端侧评测的差异服务器评测通常有稳定的 GPU 环境、充足的内存和主动散热评测重点是模型推理质量和大并发吞吐。端侧评测则是资源受限环境CPU/GPU 共享功耗、内存带宽有限、无主动散热、存储读写速度受限。这导致端侧评测要额外关注冷启动时间模型从加载到可推理需要多久。峰值内存加载瞬间和推理过程中的内存波动。热降频时间点连续推理多久后会降频降频后性能下降多少。功耗曲线不同生成阶段的功耗变化。4.2 评测流程设计一次完整的端侧小模型评测可以这样设计确定目标设备、操作系统版本、可用内存、芯片型号。选择待测模型和量化规格。准备评测数据集覆盖通用能力、代码、数学、摘要、多轮对话、agent 工具调用等场景。将模型转换为端侧推理框架支持的格式。编写评测脚本逐条执行测试样本记录延迟、吞吐、内存、功耗、输出内容。对输出结果做质量评分。多轮运行取平均值排除偶然波动。汇总生成对比报告。这里可以借鉴传统在线评测系统的思路。一本通在线评测系统这类 OJ 工具通过限定输入输出、设置超时和内存限制来判定程序是否正确。端侧模型评测没有标准答案但同样需要设置超时和内存上限避免一个坏 case 拖垮整轮评测。Lemon 这类评测工具的思路也值得参考按测试点计分、超时判定、内存限制、批量跑测、输出汇总报告。模型评测可以在相同思想下扩展将单个测试样本视为一个测试点模型输出视为待判定的结果。4.3 评测集质量是前提评测集质量直接决定评测结果可信度。高质量数据集质量评测规范通常包含数据来源可追溯测试集与训练集无交叉题目覆盖均衡不偏向某个模型答案标准明确可重复判定污染检测防止测试样本出现在训练语料中。如果测试集和训练集混在一起评测结果基本没有参考价值。评测前至少要做一次相似度去重。4.4 agent 任务评测的新维度agent 评测比单纯问答复杂得多。它不仅要评估模型生成文本的能力还要评估模型是否能在多轮工具调用中正确决策。参考 swe-bench 这类真实软件工程任务评测agent 评测需要设计任务环境给模型一个真实问题例如“修复某个仓库的 bug”。可用工具定义模型可以调用的工具如文件读取、代码搜索、命令执行。多轮轨迹记录每一步工具调用和模型决策。最终结果以任务是否完成为标准而不是以文本相似度为标准。手机端小模型做 agent 任务难点在于上下文控制和延迟。工具调用会快速消耗上下文长度手机端内存也会随之增长。评测时要设定上下文上限观察模型在上限附近的决策质量。5. 复现思路自己跑一轮端侧小模型评测如果你看完评测报告想在自己手机上复现可以参考下面的流程。注意这不是某个具体项目的完整安装教程而是一套通用端侧评测方法。5.1 准备端侧推理框架常见选择包括 llama.cpp、MLC LLM、ONNX Runtime Mobile、ExecuTorch、MediaPipe LLM Inference 等。每个框架对芯片和算子的支持不同建议根据目标设备选择。这里给出通用量化加载和推理的逻辑实际调用需要替换为你选择的框架 API。5.2 准备模型与量化版本从模型仓库下载小模型权重然后用框架提供的量化工具转换成 INT4 或 INT8 版本。保留原始权重方便对比量化前后的质量差异。5.3 准备评测数据准备一个 JSONL 格式的测试集每条包含一个唯一 ID 和测试 prompt。可以从公开评测集中抽取子集也可以根据业务场景自建。{id: 1, prompt: 用一句话解释什么是端侧推理} {id: 2, prompt: 写一段 Python 代码计算斐波那契数列} {id: 3, prompt: 把下面这段文本压缩成三个关键词人工智能正在改变手机应用的使用方式。}5.4 编写评测脚本以下脚本是框架示例核心逻辑是逐条推理并记录指标。# 端侧小模型评测脚本框架示例需按实际推理框架替换 import time import json from typing import List, Dict def load_model(model_path: str): # TODO: 替换为实际推理框架加载逻辑 # 例如 llama.cpp、MLC LLM、ONNX Runtime Mobile 等 return {model_path: model_path} def generate(model, prompt: str, max_tokens: int 128): # 返回生成文本、首 token 延迟、总耗时、生成 token 数 start time.time() first_token_latency None generated_tokens 0 # 此处为伪代码实际应调用框架的流式生成接口 # first_token_latency 0.3 # generated_tokens 128 total_time time.time() - start return { text: 生成的文本, first_token_latency: first_token_latency, total_time: total_time, generated_tokens: generated_tokens, } def run_eval(model, dataset: List[Dict]) - List[Dict]: results [] for item in dataset: prompt item[prompt] r generate(model, prompt) results.append({ case_id: item[id], input_tokens: len(prompt), output_text: r[text], first_token_latency: r[first_token_latency], tokens_per_second: r[generated_tokens] / r[total_time] if r[total_time] else 0, }) return results if __name__ __main__: dataset json.load(open(./data/dev_set.jsonl, encodingutf-8)) model load_model(./models/example_q4.gguf) results run_eval(model, dataset) print(json.dumps(results, ensure_asciiFalse, indent2))运行方式python eval.py5.5 批量对比多个模型如果你有多个模型需要对比可以写一个 shell 脚本循环执行。#!/bin/bash # 批量评测脚本示例循环执行 eval.py参数包括模型路径和输出文件 MODELS( ./models/model_a_q4.gguf ./models/model_b_q4.gguf ./models/model_b_q8.gguf ) OUTPUT_DIR./eval_results mkdir -p $OUTPUT_DIR for model in ${MODELS[]}; do name$(basename $model .gguf) echo Running eval: $name python eval.py \ --model $model \ --dataset ./data/dev_set.jsonl \ --output $OUTPUT_DIR/${name}.json \ --max-tokens 128 if [ $? -ne 0 ]; then echo ERROR: $name failed | tee -a $OUTPUT_DIR/error.log else echo OK: $name fi done5.6 评测参数建议固定采样参数非常重要。建议使用低温度多次采样取平均结果。{ model: ./models/example_q4.gguf, dataset: ./data/dev_set.jsonl, max_tokens: 128, temperature: 0.2, top_p: 0.9, repetition_penalty: 1.1, metrics: [first_token_latency, tokens_per_second, memory_peak_mb], output: ./eval_results/example_result.json }6. 如何读评测报告核心指标与常见误读评测报告出来之后最忌讳直接看排行榜总分。要拆开看细节。延迟要区分首 token 延迟和解码吞吐。首 token 延迟低的模型未必整体生成速度快。有的模型擅长快速输出第一个字但后续生成速度很慢长文本场景会很吃亏。内存要区分模型权重大小和实际峰值内存。权重文件 2GB不代表推理过程只要 2GB。激活值、KV Cache、临时缓冲都会增加内存占用。评测报告里的内存数字需要看是空闲内存还是峰值内存。能效不能只看功耗单点。要看连续运行一段时间后的温升和降频情况。手机没有主动散热热降频是端侧推理经常踩的坑。一个模型首轮推理很快连续跑五分钟可能因为发热降到一半速度。能力分要看测试集构成。如果测试集偏向代码就不适合用来评估日常问答助手如果偏向数学对通用对话场景的参考价值也有限。需要关注评测集是否做了能力分层。量化前后对比非常关键。同一模型 INT8 和 INT4 的能力差异比不同模型之间的差异可能更大。评测报告要说明每个分数对应的量化规格。否则你看到的高分 INT8 版本可能在手机上根本装不下。另外要警惕评测集污染。一些模型训练时可能已经见过评测集题目导致分数虚高。第三方评测平台的价值在于尽量控制污染但完全杜绝很难。自己复现评测时最好从没有公开传播过的新测试样本中抽一部分做验证集。7. 手机端部署与性能优化观察如果你不满足于跑评测想把小模型真正部署到手机端有几个通用优化方向。7.1 量化级别选择INT4 在速度和内存上有优势但质量损失明显。INT8 更接近原始模型但内存占用更高。建议的做法是先跑原始权重记录质量基线再跑 INT8观察质量下降比例最后跑 INT4看是否在可接受范围内。中小尺寸模型在 INT4 下质量下降通常可控但也要结合具体任务判断。7.2 推理框架与算子选择不同的推理框架在小模型端侧推理上的实现效率差异很大。芯片平台决定了框架能调用哪些加速算子建议优先选择目标芯片有优化支持的框架。框架没有对应算子的模型结构在 CPU 上可能会退化为慢速通用实现。7.3 显存/内存观察方法在评测脚本中增加内存监控记录推理前后的峰值。常见做法是在子进程中运行推理主进程定时采样内存信息。也可在模拟器中反复跑同一推理任务用系统自带的资源监视器观察内存曲线。7.4 版本一致性检查如果你不是直接用命令行部署而是把模型集成到自研 App 或 SDK 中要特别注意编译环境与目标设备 SDK 版本的一致性。例如前端/容器层用较新版本的编译器打包而目标设备上的 SDK 版本较低就可能导致模型加载接口不可用或推理结果异常。现象往往是模拟器上正常真机上崩溃或同一套代码在这台手机上正常另一台手机上报错。排查时要先确认编译环境版本和手机端 SDK 版本是否匹配。7.5 端口与进程资源部分端侧推理框架支持以本地 HTTP 服务方式运行。如果你打算把模型封装成服务给上层应用调用要注意本地端口占用和进程残留问题。# 本地起一个简单的推理服务框架示例具体命令以实际框架为准 python server.py --host 127.0.0.1 --port 8080 --model ./models/example_q4.gguf调用测试可以使用 curlcurl -X POST http://127.0.0.1:8080/generate \ -H Content-Type: application/json \ -d {prompt: 用一句话解释什么是端侧推理, max_tokens: 128}服务化部署后批量任务就可以通过 HTTP 请求驱动方便接入上层业务。7.6 性能观察清单实测时建议记录以下数据模型完整加载耗时冷启动首次推理耗时连续运行 5 分钟、10 分钟后的推理速度推理过程中的峰值内存设备外壳温度变化降频后速度恢复时间。这些数据能真实反映“手机端能不能持续用”这个核心问题。8. 常见问题与排查方法端侧小模型评测过程中会遇到很多环境问题下面是高频排查清单。问题现象可能原因排查方式解决方案模型加载失败模型文件损坏或格式不受支持检查模型文件完整性确认框架支持的量化格式重新下载模型转换格式量化后输出质量明显下降量化级别过低或校准数据不匹配对比原始权重和量化版本的输出使用 INT8 替代 INT4重新做校准推理速度远低于预期算子未走加速实现或设备热降频检查框架日志观察 CPU/GPU 占用和温度更换框架或算子实现降低持续负载首 token 延迟高模型体积大、上下文填充耗时拆解耗时确认是否卡在 prompt 处理阶段减小 prompt 长度使用更激进的量化内存占用过高KV Cache 过大或激活值峰值高分阶段记录内存变化缩短上下文长度批量跑测时降低并发多轮对话越来越慢KV Cache 持续增长观察内存增长曲线限制上下文窗口或使用 KV Cache 量化同一模型不同手机表现差异大芯片算子支持不同、内存带宽不同分别记录每台设备的日志按设备集团队做针对性优化接口调用失败端口被占用或服务未启动检查端口和进程日志更换端口重启服务批量任务卡住单条测试样本超时或返回异常设置单条超时和重试机制增加超时上限跳过异常样本集成到 App 后运行时崩溃编译环境与手机端 SDK 版本不匹配检查编译工具版本、SDK 版本、架构兼容性统一编译环境和目标设备 SDK 版本这些排查项同样适用于端侧模型服务化和批量评测的工程化场景。9. 评测合规与隐私边界端侧模型评测涉及模型、数据、设备和部署方式有一些合规和隐私边界需要明确。自建评测集时不要使用未授权抓取的文本、人脸照片、声音样本或包含个人隐私的数据。评测过程如果使用真实用户对话数据必须提前脱敏并确认数据来源合法。涉及 agent 任务评测时如果评测环境包含真实工具、代码仓库或在线服务要注意不要对线上系统产生不可控影响。建议使用隔离的测试环境避免评测脚本误操作真实业务资源。涉及人脸、声音、肖像等敏感内容的评测必须获得明确授权。人脸生成、声音克隆、数字人相关能力在合规要求上非常严格评测样本和部署方案都需要谨慎。模型发布或商用前要做一轮完整效果复核。评测分数只能说明模型在特定测试集上的表现不能替代真实业务场景的验收。建议在正式发布前用你的真实数据再跑一轮小样本验证。10. 总结与下一步Artificial Analysis 联合 Liquid AI 发布的手机端小模型评测把行业关注点从服务器端跑分拉到了端侧可用性。手机端小模型评测的关键不止于能力分更在于延迟、内存、能效、热降频、多轮稳定性和设备适配性。如果你要做端侧模型选型最先应该验证的是目标设备上的实际推理速度、峰值内存和连续运行稳定性。建议先跑一个小数据集固定采样参数记录首 token 延迟、解码吞吐和内存曲线再结合能力分做综合判断。最容易踩的坑有三个只看榜单分不看量化规格、不看延迟细分指标、忽略设备热降频问题。评测数据集质量也容易被忽略测试集一旦被污染所有对比都失去意义。下一步可以扩展的方向很多把 agent 评测纳入端侧模型对比建立自己的端侧 benchmark 基线跟踪不同芯片平台的算子支持差异以及把评测脚本沉淀成自动化批量任务。端侧小模型评测会越来越像传统软件测试一样成为模型发布前的标准环节。这篇内容建议收藏备用后面做端侧模型选型时可以对照着搭一套自己的评测流程。