手机端能跑的模型越来越大，但“哪个模型在我手机上表现最好”这个问题，反而越来越难回答。你翻厂商宣传，每家的榜单都把自己排第一；你翻开源评测，同一个模型在不同框架、不同量化格式下成绩能差出一大截；你准备在真机上一一验证，光是把模型包和推理框架组合起来就够折腾好几天。手机端小模型评测，早就不是“跑分”的问题，而是“怎么让跑分可信、可复现、可落到业务决策”的工程问题。
最近，Artificial Analysis 联合 Liquid AI 发布手机端小模型评测，我认为这条信息值得开发者关注的真正原因，不是它又给出一份“手机端模型排行榜”，而是它把端侧模型评价这件事往“可复现、可对比、可解释”的方向推了一步。本文会从端侧评测为什么难、哪些指标真正影响部署效果、如何自己搭建一套本地评测流程，以及上线前如何做回归验证这几个角度展开。读完你会明白：手机端小模型的评测，不是简单地跑一遍公共 benchmark，而是一套需要结合模型、推理框架、真机资源和业务场景反复校准的工程方法。
1. 为什么手机端小模型评测成了“硬需求”
过去两年，大模型评测的主流注意力都在云端模型上，大家比的是 MMLU、GPQA、HumanEval 这类智力榜单。但随着端侧 AI 成为新方向，手机端小模型的处境其实非常尴尬：论智力，它比不过云端大模型；论部署，它又不像云端那样有统一的 GPU 环境和 API 网关。你可以在服务端方便地横向对比 7B、14B、70B 模型，但在手机端，1B 模型配上不同量化方案，就是完全不同的产品体验。
更麻烦的是，手机端小模型的评测维度比云端模型多得多。云端模型只需要关注“回答对不对”和“每秒输出多少个 token”，而在手机上，你还需要关心：
- 模型量化后是否还能保持稳定的中文理解能力；
- 首 token 延迟是否控制在用户可感知的 300ms 以内；
- 峰值内存会不会把低端机直接压到后台被杀；
- 长时间推理时发热和降频到底有多严重；
- 每万次请求的端侧推理功耗是否影响手机续航。
这些指标用传统的云端评测脚本一个都测不出来，必须放到真实的端侧推理环境里看。所以，“手机端小模型评测”天然就是一个系统工程，而不是简单地把 HellaSwag 或 CMMLU 跑一遍、算个准确率。
另一个被低估的问题是选择成本。现在开源社区里适合端侧的模型数量已经不少，从 0.5B、1.5B 到 3B、4B，加上各种量化格式和推理框架，组合数量轻松超过几十种。如果没有一套统一的评测方法，团队很容易陷入“每个人都认为自己的方案最好，但谁也没法说服谁”的僵局。这也是 Artificial Analysis 这类第三方评测平台与模型厂商合作做端侧评测时，最值得关注的信号：端侧模型开始进入“用同一把尺子量不同方案”的阶段。
2. 从 Artificial Analysis 与 Liquid AI 的合作看端侧评测的范式变化
在展开具体指标之前，先聊聊这次合作背后反映出的趋势变化。Artificial Analysis 是独立的大模型评测与分析平台，核心方式是设置统一提示词、统一评估流程，把不同厂商、不同规模模型的“智力”“速度”“成本”放到同一张图表里做横向对比。它解决的是“各说各话”的问题，让模型能力从宣传文案变成可比较的量化数据。
Liquid AI 则是一家更强调架构效率的 AI 公司。从公开信息看，它旗下的 LFM 系列模型主打低内存占用、高效推理和可控的部署成本，方向恰恰就是端侧和边缘场景。这次 Artificial Analysis 选择与 Liquid AI 联合做手机端小模型评测，说明端侧模型评测不再是“模型厂商自己放出的成绩单”，而是第三方评测机构入场，把一个更中立的评价体系带到移动端。
这个变化的深层原因，是端侧模型的商业模式正在变化。过去手机厂商说“AI 能力”，更多是 PPT 上的展示；现在应用开发者真的要把模型塞进 App，真实的性能、功耗、内存数据变成采购决策依据。没有第三方评测，开发者既没办法在模型 A 和模型 B 之间做选择，也没办法向采购方解释“为什么这个模型比那个贵但值得用”。
所以我认为，这次评测的真正价值在于把“手机端小模型”从技术展示品变成了“可以被产品化度量的标准组件”。它对开发者的影响是：以后评估一个手机端模型，不能只看官方说的智能跑分，还要看它在一套公开、可复现的评测流程下，能否达到你业务要求的延迟、内存和功耗指标。
3. 手机端小模型评测的核心指标有哪些
要搭建一套端侧评测体系，第一步不是找评测集，而是明确这一轮评测要回答什么问题。我把手机端小模型常用指标分成四类，实际项目里通常要组合使用。
| 指标类别 | 典型指标 | 关注原因 | 常用工具/方式 |
|---|---|---|---|
| 智力能力 | MMLU / MMLU-Pro 子集、CMMLU、CEval | 衡量模型知识面和推理能力的底线，不能低于业务可接受水平 | lm-evaluation-harness、自建 prompt 评测脚本 |
| 代码能力 | HumanEval、MBPP 子集 | 端侧模型作为编码助手或工具调用底座时需要 | 自建或公开评测框架 |
| 指令遵循 | IFEval、自建指令集 | 判断模型能否按要求输出格式，影响产品交互稳定性 | 自建指令集 + 规则校验 |
| 速度体验 | 首 token 延迟 TTFT、解码速度 tokens/s、预填充速度 tokens/s | 直接影响用户等待体感 | llama-bench、MLC-LLM benchmark、真机打点 |
| 资源占用 | 峰值内存、模型文件大小、CPU 占用率、发热、功耗 | 决定模型能否稳定运行在低端机上，是否影响续航 | Android Profiler、Instruments、系统级打点 |
这里特别说一下“智力指标”在端侧的局限。MMLU 这类 benchmark 对云端大模型有区分度，但对端侧小模型的区分度正在下降。很多 1B 级模型在 MMLU 上做到 50 多分，看起来只差几个点，但实际业务场景里可能一个能稳定输出 JSON，另一个经常格式崩塌。因此，端侧评测一定要在通用指标之外，加入真实业务样例。
此外，tokenizer 效率也很值得注意。同样是 500 字的中文回答，有的模型需要 700 个 token，有的只需要 400 个 token。在端侧推理场景中，token 数量直接决定首 token 延迟和总生成时长。所以评测报告里如果只看 tokens/s，不看“生成相同内容所需的 token 数”，很可能做出错误判断。
4. 端侧推理框架与评测环境怎么选
评测结果和推理框架强相关。同一个模型在同一台手机上，用不同框架跑出来的速度和内存占用可能相差很大。原因很简单：端侧芯片的异构计算单元复杂，CPU、GPU、NPU 分别适合不同算子，推理框架对算子的调度策略直接决定性能。
目前项目里常见的端侧推理框架主要有这几类：
| 框架 | 主要平台 | 特点 | 适用场景 |
|---|---|---|---|
| llama.cpp | Android / iOS / Linux / Windows | CPU 优化成熟，量化支持好，易于集成 | 快速验证、CPU 推理、统一基准测试 |
| MLC-LLM | Android / iOS / WebGPU | 基于 TVM 编译，支持 GPU 加速和多种硬件后端 | 追求端侧 GPU 性能释放 |
| ExecuTorch | Android / iOS | PyTorch 官方端侧运行时，与 PyTorch 生态衔接好 | 已有 PyTorch 模型，需要完整 PyTorch 工具链 |
| ONNX Runtime Mobile | Android / iOS | ONNX 生态，跨框架转换方便 | 已有 ONNX 模型或异构方案 |
| Core ML | iOS | Apple 官方方案，NPU/GPU/CPU 调度能力强 | 只做 iOS 端时的优先考虑 |
| Qualcomm QNN | Android（骁龙） | 可调用骁龙 NPU | 深度适配旗舰安卓机 |
我的建议是：评测阶段优先用 llama.cpp，因为它的llama-bench工具简单直接，能快速得到可对比的速度数据；正式产品阶段再根据目标用户机型决定是否上 MLC-LLM 或 QNN。要特别注意，评测框架版本必须固定。llama.cpp 不同 commit 的性能差异很大，今天用 A 版本跑出 30 tokens/s，下周换 B 版本可能变成 25 tokens/s，但这不代表模型变差了。
评测环境还需要遵循“先 PC 粗筛，再真机验证”的原则。PC 评测速度快，适合从十几个模型里筛出前三名；真机评测则负责回答“这个模型在用户主力机型上到底卡不卡、烫不烫、费不费电”。真机测试不要只用模拟器，CPU 调度、内存限制、温控策略都是真机才有。
5. 评测数据准备与任务设计
评测数据是整套体系的灵魂。直接下载公共数据集跑一遍固然省事，但很容易遇到两个坑：一是公共 benchmark 样本可能出现在模型的训练数据里，准确率虚高；二是公共数据集的语言和格式不一定符合你的真实业务。
比较稳妥的做法是采用“公共数据集 + 业务回归集”的双层结构。公共数据集用于横向对比和外部参考，业务回归集用于验证“这个模型到底能不能完成我们产品的关键任务”。
业务回归集的样本不需要太多，但必须覆盖核心链路。比如你做的是客服助手，就应该准备 200 到 500 条真实脱敏对话，标准答案由产品负责人审核后冻结；如果你做的是写作辅助，就要覆盖不同体裁、不同字数的输入。重点是样本要来自真实使用场景，而不是临时编造。
在设计 prompt 时，还要注意“评测 prompt 和线上 prompt 不一致”的问题。比如线上你用了加了 system prompt 的模型服务，评测时也必须在同样的 system prompt 下测试，否则测出来的能力不能代表线上行为。评测脚本里最好把 prompt 模板抽出来，作为配置文件管理，避免模型、模板、评测数据三者版本错位。
下面是一个简单但完整的评测数据格式示例，推荐用 JSON 保存：
[ { "id": "case-001", "task_type": "choice", "question": "手机端小模型评测中，首 token 延迟主要影响以下哪个体验？", "choices": [ "模型下载速度", "用户等待第一个字出现的时间", "手机的屏幕亮度", "应用安装包大小" ], "answer": "B", "source": "business-regression-v1" } ]这份 JSON 的特点是：既包含评测集本身，也包含答案和来源，方便后续追溯。业务回归集一旦建立，建议作为团队资产固定下来，任何模型升级、框架更换、量化位宽调整，都需要重新跑一遍。
6. 完整示例：在本地跑通一个小模型评测流程
下面以一个通用的端侧小模型评测流程为例，演示从环境准备、基础推理、准确率计算到速度测试的完整过程。这个流程适合在 PC 上先跑通，代码也可以继续复用到真机验证中。
6.1 环境准备
建议使用 Python 3.9 以上版本，创建独立虚拟环境：
python -m venv .eval_env source .eval_env/bin/activate pip install transformers torch accelerate也可以把依赖写进requirements.txt：
transformers>=4.40.0 torch>=2.1.0 accelerate>=0.30.0这里不限定具体版本，以实际安装时的稳定版本为准。评测脚本的核心目的是跑通“输入提示词、得到输出、解析结果”这一链路，后续再进行速度和内存测试。
6.2 基础推理示例
以当前常见的端侧小模型为例，先写一个最基础的单条推理脚本：
# 文件：basic_inference.py from transformers import AutoModelForCausalLM, AutoTokenizer model_id = "Qwen/Qwen2.5-0.5B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_id, torch_dtype="auto", device_map="auto", trust_remote_code=True, ) messages = [{"role": "user", "content": "用一句话解释什么是端侧AI推理。"}] prompt = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True, ) inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=128, do_sample=False, ) response = tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True) print(response)运行验证方法：
python basic_inference.py如果正常，会输出一句中文解释。这里有两个关键点：一是apply_chat_template会按模型官方模板拼接对话，避免不同模型模板不一致的问题；二是do_sample=False保证评测结果是确定性输出，方便复现。评测阶段不建议开启随机采样，否则同一道题跑两次结果不一样，难以定位是模型问题还是评测脚本问题。
6.3 评测脚本核心逻辑
下面是更接近真实评测的脚本，包含 prompt 构造、答案解析和准确率计算。仍然以单选题为例：
# 文件：eval_choice.py import json from transformers import AutoModelForCausalLM, AutoTokenizer def build_choice_prompt(question, choices): lines = [f"题目：{question}"] labels = ["A", "B", "C", "D"] for i, choice in enumerate(choices): lines.append(f"{labels[i]}. {choice}") lines.append("请直接输出正确选项的字母，例如 A。") return "\n".join(lines) def parse_answer(raw_text): text = raw_text.strip().upper() for ch in text: if ch in "ABCD": return ch return None def evaluate_subset(model, tokenizer, examples, max_new_tokens=16): correct = 0 for ex in examples: prompt = build_choice_prompt(ex["question"], ex["choices"]) messages = [{"role": "user", "content": prompt}] formatted = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True, ) inputs = tokenizer(formatted, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=max_new_tokens, do_sample=False, ) decoded = tokenizer.decode( outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True, ) if parse_answer(decoded) == ex["answer"]: correct += 1 return correct / len(examples) if examples else 0.0 if __name__ == "__main__": model_id = "Qwen/Qwen2.5-0.5B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_id, torch_dtype="auto", device_map="auto", trust_remote_code=True, ) with open("eval_set.json", "r", encoding="utf-8") as f: data = json.load(f) acc = evaluate_subset(model, tokenizer, data) print(f"准确率: {acc:.2%}")这个脚本把“评测”抽象成了三个环节：根据数据构造 prompt、把模型输出解析成结构化结果、与标准答案比较。你只需要把eval_set.json替换成自己的业务回归集，就能得到一个最简但完整的评估闭环。
6.4 用 llama.cpp 基准工具测速度
上面的脚本验证了“模型会不会”，接下来要测“跑得多快”。速度评测建议使用 llama.cpp 自带的llama-bench：
./llama-bench -m ./models/qwen2.5-0.5b-instruct-q4_k_m.gguf -p 128 -n 64 -t 4参数含义分别是：
-m：模型文件路径，建议统一使用 Q4_K_M 这类内存占用适中的量化版本；-p：预填充 token 数，模拟用户输入长度；-n：生成 token 数，模拟模型回答长度；-t：线程数，可按真机 CPU 核心数调整。
预期输出会类似：
model size params backend ngl threads test t/s qwen2.5-0.5b-instruct-q4_k_m 422 MB 0.62B CPU - 4 pp128 ... qwen2.5-0.5b-instruct-q4_k_m 422 MB 0.62B CPU - 4 tg64 ...pp128和tg64分别表示预填充和生成两个阶段。生成阶段的 t/s 值，就是通常大家说的“每秒吐多少个 token”。把这个命令固定下来，作为团队的基准测试基线，以后每次换模型、换框架版本都跑一遍，数据就可比、可回归。
7. 如何解读评测结果，避免被跑分误导
评测流程跑通之后，真正难的是解读结果。
首先，要区分“能力基准”和“用户体验”。一个模型公共 benchmark 准确率领先，但中文回答总是啰嗦、尾缀乱码，很可能在业务上反而不如分数稍低但输出格式稳定的模型。端侧小模型尤其如此，它的能力上限比云端大模型低，用户对“稳定性”的敏感度远高于“偶尔惊艳”。
其次，量化格式会显著影响评测结论。同一个模型，Q4_K_M 和 Q8_0 的准确率可能只差 1 到 2 个百分点，但速度可能差 20% 以上。评测报告如果不说清楚量化格式，结论基本无法复用。我的建议是，所有评测记录里都要带上这五个字段：模型版本、量化格式、推理框架版本、热身状态、设备型号。
第三，要注意 benchmark 污染。很多模型在预训练阶段已经把 MMLU、CMMLU 的题目见过一遍，这对大模型时代的评测司空见惯，但端侧模型领域更严重，因为小模型要突出“高性能”，很容易在公开数据集上花心思。判断方法也很简单：把评测集顺序打乱，或者按时间留出近期业务数据，再观察分数是否出现明显下跌。
第四，不要只盯着 tokens/s。不同 tokenizer 的 token 密度差异巨大，同样回答 200 字中文，A 模型消费 500 token，B 模型消费 350 token。此时 B 模型即使单 token 速度略慢，实际用户体验也可能更好。更合理的对比方式是“生成相同目标文本所需的总时间”，而不是简单比较 tokens/s。
最后，建议把所有评测结果沉淀成一份可检索的基线文档。哪种模型、哪种量化、在什么任务上跑出多少分，全部记录在案。这样以后面对新模型时，只需要跑同一个评测集，就能快速判断：新模型是提升了，还是只是换了个壳。
8. 常见问题与排查思路
手机端小模型评测过程中，常遇到的问题集中在依赖、同步和结果稳定性三方面。下面整理了一个排查表，可以直接对照操作。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型加载报错 | transformers 版本过旧或依赖冲突 | 查看完整堆栈，执行pip list检查版本 | 升级到当前稳定版，重新安装依赖 |
| 评测脚本输出乱码 | 模板拼接错误或 tokenizer 未按 chat 模板处理 | 打印模型输入 prompt，人工检查 | 使用apply_chat_template统一处理 |
| 准确率与官方结果不一致 | prompt 模板、评测集子集、解码参数不同 | 对比官方评测脚本参数 | 固定 prompt、固定do_sample=False，记录参数 |
| 同一模型两次速度测试差异大 | 手机温度、后台进程、框架版本变化 | 保证真机重启后统一场景再测 | 固定预热轮数和测试环境，多轮取中位数 |
| 同一模型在不同手机上表现悬殊 | 芯片平台、内存带宽、框架后端不同 | 分别记录 CPU/GPU/NPU 调度情况 | 按目标用户机型做分档评测，而不是只看平均值 |
| 模型端侧推理内存溢出 | 量化位宽过大或 context 长度过长 | 用 Android Profiler / Instruments 观察峰值内存 | 降低量化位宽、减小max_new_tokens，或换更小模型 |
排查时最重要的原则是“先固定变量”。测准确率时，prompt、解码参数、评测集都要保持不变；测速度时，框架版本、线程数、输入长度都要保持一致。如果变量没有固定，任何结论都是不可复现的，也就失去了评测的意义。
9. 最佳实践与工程建议
最后，把我在实际项目中积累的几条手机端小模型评测经验分享出来，这些建议比跑分本身更重要。
第一，把所有评测配置代码化。模型版本、量化格式、prompt 模板、评测集版本，都应该作为配置文件维护，而不是散落在脚本里。哪怕是一个人维护的项目，三个月后回看，也需要能知道“当时这个分数是用哪套配置跑出来的”。
第二，建立多档位机型回归矩阵。不要只在主力测试机上评测。建议按用户设备分布选三个档位：旗舰机、中端机、低端机。每个档位跑同一套业务回归集，记录速度、内存、温度三个硬指标。如果低端机上首 token 延迟超过 1 秒，这个方案就不具备上线条件。
第三，把评测嵌入发布流程。模型升级、推理框架升级、量化方案调整，都要触发一次全量回归。最好写一个简单的 CI 脚本，把业务回归集放到固定目录，跑完自动输出报告。发布一个端侧 AI 版本之前，必须保证评测报告和版本号一一对应。
第四，不盲目追求新模型。端侧模型的更新速度快，但每次都换新模型对产品稳定性伤害很大。新模型要接入，至少要同时满足三个条件：业务回归集准确率不低于现网模型、解码速度不慢于现网模型、内存占用不超过现网模型。三个条件都满足，再谈上线。
第五，注意安全和隐私边界。端侧评测使用的业务回归集，原则上只用脱敏数据。如果评测过程需要真实用户请求，必须先获得明确授权，并限定在最小范围内。这也是合规建设的基本要求。
下一步，你可以先从自己的业务回归集做起，用文中的脚本跑通第一版评测链路；然后再接入 llama-bench 做速度基线，逐步搭建起属于团队的端侧模型评测体系。等评测体系稳定后，再结合第三方平台给出的横向对比数据，做最终选型。这样，下次面对“到底选哪个模型”的问题时，你手里有的就是一套可量化的证据链，而不是一家之言。
