最近手机端小模型的讨论热度明显上升一方面模型厂商不断推出 1B、3B 级别的小参数模型另一方面社区评测机构也在尝试统一“端侧模型”的衡量标准。Artificial Analysis 与 Liquid AI 都在手机端小模型评测上投入了注意力这背后其实是一个很实际的问题小模型跑在手机上的体验到底怎么量化只看跑分表格容易踩坑只看官方宣传又不够客观。今天这篇教程我会从评测维度、离线环境准备、真机部署、性能采集、质量对比到结果解读完整梳理一套可以复用的手机端小模型评测流程。1. 手机端小模型评测为什么值得关注1.1 从 Artificial Analysis 与 Liquid AI 说起Artificial Analysis 是社区里常见的模型评测平台它把“模型质量”和“推理性能”放在一起做横向对比最终形成一个综合指数方便开发者快速判断某个模型是否值得接入。Liquid AI 则是研究非传统 Transformer 架构的代表团队之一其公开的 LFM 系列模型主打低推理成本、适合边缘设备部署尤其强调在手机这类算力受限设备上的可行性。两者同时聚焦手机端小模型说明行业正在经历一次“从云端大模型到端侧小模型”的注意力迁移。过去我们选模型只看参数量和榜单分数现在还要看这个模型能不能塞进手机内存、能不能在用户的中端手机上保持可用速度、断网环境下是否依然稳定。评测的意义不是给模型排名而是给工程选型提供可复现的决策依据。1.2 什么是手机端小模型手机端小模型没有绝对严格的定义但业界通常把参数量在 0.5B 到 7B 之间、可以在移动设备 CPU/GPU/NPU 上运行的大语言模型称为“端侧小模型”。常见例子包括 Llama 3.2 1B/3B、Qwen2.5 0.5B/1.5B/3B、Phi 系列以及 Liquid AI 的 LFM 小型号等。这类模型有两个显著特点。第一模型体积需要控制。以 1.5B 参数为例FP16 权重约 3GB量化到 INT4 后可以压到 1GB 左右手机端才有实际可用性。第二推理资源受限。手机没有数据中心那种并行 GPU内存带宽、功耗、散热都有限所以推理引擎的算子优化、量化策略、内存复用方式直接决定用户体验。1.3 为什么需要正规的评测方法没有评测方法的 LLM 选型基本等于“谁宣传猛就选谁”。但手机端模型更特殊同一款模型在同一台手机上用不同推理框架、不同量化位宽、不同上下文长度表现可能差距很大。甚至同一部手机冷机跑和连续跑 20 分钟后的速度也完全不同。这时就需要一套标准评测流程限定硬件环境、固定推理参数、记录多条性能指标、多次采样看稳定性。只有这样才能回答三个核心问题模型跑不跑得动、跑得快不快、答得准不准。2. 手机端小模型评测到底在测什么2.1 质量类指标从 MMLU 到中文问答质量指标回答“模型聪不聪明”。传统评测集包括MMLU覆盖 STEM、人文、社科等 57 个学科的多选题考察模型是否具备广泛知识。GPQA偏难的研究级问答主要用于区分小模型的推理上限。ARC-C / HellaSwag考察常识推理和文本续写能力对理解能力比较敏感。HumanEval代码生成能力评测。GSM8K数学应用题适合观察小模型的数值推理能力。中文场景还需要补充中文问答集判断模型在中文语料上的文字组织、成语理解、中文数学题等场景的表现。需要提醒的是质量评测通常不需要在手机上完整跑一遍因为质量取决于模型权重和推理参数和“跑在 GPU 还是手机 CPU”关系不大。工程上常见的做法是在 PC 上用 lm-eval-harness 等工具离线评测同一权重再在手机上做性能采样两者组合起来得到完整画像。2.2 性能类指标TTFT、生成速度与内存性能指标回答“模型跑得快不快”也是手机端评测最关注的部分。TTFTTime To First Token用户发出请求到收到第一个 token 的耗时直接影响对话的“跟手”程度。生成速度tokens/s每秒生成 token 数。这个数字越高长篇回答的等待时间越短。峰值内存运行期间的 RSS 峰值。手机内存有限如果模型加 KV Cache 后超过系统可用阈值会被系统直接杀死。功耗与温度长时间推理会触发手机降频属于端侧特有的稳定性问题。2.3 易混淆概念模型体积、量化位宽、显存/内存这里容易踩坑。模型文件体积不等于运行内存占用。GGUF 格式的 Q4_K_M 模型文件可能只有 1GB但推理时需要额外申请 KV Cache、临时激活和运行时缓冲区实际峰值内存可能是文件体积的 1.2 到 1.5 倍。量化位宽Q4、Q6、Q8指的是权重存储精度它会同时影响文件大小、推理速度和回答质量。显存是 GPU 专用显存手机端要区分“系统内存”和“GPU 专用内存”大多数端侧推理框架默认跑 CPU吃的是系统内存。3. 评测环境准备3.1 硬件与系统本文示例不限定具体机型以常见 Android 手机为例要求系统为 Android 10 以上、支持 arm64-v8a 架构。iOS 可以采用 Core ML 或 ExecuTorch 路线但流程类似本文不展开。强烈建议准备两台机器一台 PC用于模型转换和离线质量评测一台 Android 手机用于真机性能采样。PC 需要安装 Python 3.10、Git、CMake并准备 Android NDK 环境。手机需要开启开发者选项和 USB 调试。3.2 推理框架选择当前手机端主流的推理框架有以下几种。llama.cpp支持 GGUF 格式C 编写社区活跃适合在 Termux 里直接编译或用 Android NDK 交叉编译。MLC-LLM基于 TVM 生态支持 CPU/GPU/NPU 多后端部署方式偏 SDK 集成。ExecuTorchPyTorch 官方向移动端延伸的方案适合已有 PyTorch 生态的团队。MNN阿里开源国内资料较多对 Android 兼容性不错。Core ML / Core ML ConvertiOS 原生方案。对于评测场景llama.cpp 最容易上手没有复杂的图形界面命令行参数清晰还自带 llama-bench 这样的性能采样工具。本文后续操作以 llama.cpp 为主线。3.3 模型准备与量化工具链评测使用的模型建议选择开源、授权允许再分发的模型并且记录模型来源与版本不要直接使用未经授权的权重文件。下载模型后需要经历以下转换链路原始权重safetensors - convert_hf_to_gguf.py 转换为 GGUF F16 - llama-quantize 量化为 Q4_K_M / Q6_K 等格式 - 拷贝到手机进行真机评测这样做的原因是手机端直接推理 HF 原版 safetensors 对内存和算子支持都不友好GGUF 是 llama.cpp 生态的标准格式支持多种量化方案而且单文件便于拷贝和版本管理。4. 完整实战在手机端部署并跑一轮评测4.1 在 PC 上转换并量化 GGUF 模型我以 Qwen2.5-1.5B-Instruct 为例因为该模型体积适中量化后单文件约 1GB 左右适合在手机上体验。请先确保模型权重已经下载到本地目录。克隆并编译 llama.cppgit clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease .. cmake --build . --config Release -j编译完成后在build/bin目录下会生成llama-cli、llama-bench、llama-quantize等工具。不同版本对二进制命名可能略有差异请以实际编译结果为准。接下来把原始 HF 权重转换为 GGUFpython3 ../convert_hf_to_gguf.py /path/to/qwen2.5-1.5b-instruct \ --outfile qwen2.5-1.5b-instruct-f16.gguf \ --outtype f16注意convert 脚本在较新版本中一般位于仓库根目录也可能位于convert_hf_to_gguf.py如果路径不对可以先在仓库根目录执行ls | grep convert确认。然后量化为 Q4_K_M./bin/llama-quantize \ qwen2.5-1.5b-instruct-f16.gguf \ qwen2.5-1.5b-instruct-q4_k_m.gguf \ Q4_K_M量化后会得到一个体积小很多的单一 GGUF 文件之后把它推到手机存储中adb push qwen2.5-1.5b-instruct-q4_k_m.gguf /sdcard/Download/这里的adb来自 Android SDK Platform Tools。如果 adb 未安装需要先在 PC 上安装对应工具包。4.2 在 Android 手机编译 llama.cpp在手机上编译 llama.cpp 有两种常见方式。第一种是直接在 Termux 中编译适合临时验证。Termux 安装后执行pkg update pkg install git cmake make python clang git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease .. make -j4第二种是使用 Android NDK 交叉编译适合要集成进 App 的场景。NDK 路径需要根据你的实际安装位置调整mkdir build-android cd build-android cmake -DCMAKE_TOOLCHAIN_FILE$ANDROID_NDK/build/cmake/android.toolchain.cmake \ -DANDROID_ABIarm64-v8a \ -DANDROID_PLATFORMandroid-24 \ -DCMAKE_BUILD_TYPERelease \ .. cmake --build . --config Release -j交叉编译得到的二进制可以在 Android 设备上直接运行。NDK 版本建议使用 r25 及以上过旧的 NDK 可能无法适配新版 llama.cpp。4.3 用 llama-bench 测量生成速度llama.cpp 自带的 llama-bench 是专门做性能采样的工具。先进入编译输出目录然后运行./bin/llama-bench \ -m /sdcard/Download/qwen2.5-1.5b-instruct-q4_k_m.gguf \ -n 128 \ -t 4-m指定模型路径-n是生成 token 数-t是线程数。也可以添加-p 128设置 prompt 长度观察长上下文下的表现。在 Termux 环境下线程数不建议直接拉满因为手机要保留系统 UI 和其他后台进程的运行余量一般中端机用 4 线程、旗舰机用 6 到 8 线程记录时写明线程数。llama-bench 会输出平均生成速度tokens/s和内存占用例如| model | size | mem | t/s | | ------------------------------ | ---- | ----- | ---- | | qwen2.5-1.5b-instruct q4_k_m | 1.1G | 1.4G | 12.5 |这个结果只能代表当前帧率真实项目还需要多次运行取中位数不能只跑一次就下结论。4.4 收集问答结果并计算质量指标性能跑完后还需要验证输出内容质量。以最简方式为例我们可以准备一组带标准答案的测试题用 llama-cli 把每道题的输出保存下来再写脚本对比答案。先生成一批预测结果这里用命令行方式逐条调用./bin/llama-cli \ -m /sdcard/Download/qwen2.5-1.5b-instruct-q4_k_m.gguf \ -p 中国的首都是哪里请直接回答城市名。 \ -n 32 \ --temp 0 \ --no-display-prompt每次运行的输出可以用 shell 重定向保存到文件。不过对于几十道题的评测更推荐写一个简单的 Python 脚本批量请求本地接口。如果你在 PC 端用 llama.cpp 服务模式启动也可以直接通过 HTTP 接口获取预测结果再和答案文件进行比对。下面是一个简单的答案对比脚本示例用于统计准确率import json import re def normalize(text: str) - str: # 去掉多余空格、标点统一小写降低对比误差 text re.sub(r[。、\s], , text) return text.lower().strip() def evaluate_accuracy(pred_file: str, answer_file: str) - dict: predictions json.load(open(pred_file, r, encodingutf-8)) answers json.load(open(answer_file, r, encodingutf-8)) correct 0 total len(predictions) for item in predictions: qid item[id] pred normalize(item[prediction]) target normalize(answers.get(qid, )) # 完全匹配或预测包含标准答案都算对具体规则按任务调整 if pred target or (target and target in pred): correct 1 return { total: total, correct: correct, accuracy: round(correct / total, 4) if total else 0.0, } if __name__ __main__: result evaluate_accuracy(preds.json, answers.json) print(json.dumps(result, ensure_asciiFalse, indent2))这个脚本的核心思想是把“预测结果”和“标准答案”统一格式后对比。实际评测时要根据任务自己设计匹配规则比如多选题只看选项字母代码题需要执行单元测试不能一概而论。5. 结果怎么读不要盲目追求 tokens/s5.1 速度与质量的平衡手机端小模型评测中最常见的误判是只看 tokens/s生成速度很快但回答质量一塌糊涂。反过来质量很高但速度只有每秒 3 个 token用户在真机上也很难接受。合理的做法是把质量指标和速度指标放在同一张表里用综合视角判断。例如一款 1.5B 模型 Q4 量化后在某台中端机上生成速度 15 tokens/sMMLU 得分 55 分另一款同规模模型 Q8 量化后生成速度只有 8 tokens/sMMLU 得分 58 分。如果应用场景是短对话后者体验更好如果应用场景是长文档总结前者的等待时间更值得关注。评测结论要服务于具体场景。5.2 量化位宽的影响量化位宽对速度、内存、质量的影响是三个方向的。Q8_0几乎无损模型文件较大适合对质量和内存都不敏感的场景。Q6_K质量损失很小体积适中适合旗舰机。Q4_K_M体积小、速度快中端机首选但复杂推理任务会肉眼可见地劣化。Q3_K / Q2_K文件极小数学、代码能力下降严重一般不建议用于生产。所以评测时不能只测最优量化还应该在同一台机器上跑 Q8_0 和 Q4_K_M 两组对比差异。这个差异决定了你的产品最低能接受哪个量化档位。5.3 与公开评测平台的对比注意事项Artificial Analysis 这类平台上的模型评分通常是在标准化的云服务器 GPU 环境上跑出来的和手机端的 CPU/GPU 环境完全不同。你可以参考平台上的“模型质量分”来判断模型相对强弱但不能直接拿平台 tokens/s 和本地手机跑出的数字对比。正确用法是用平台数据判断模型路线用本地评测数据决定具体设备上的部署配置。只有你本地复现的标准评测集和平台一致时质量分才有横向对比价值。6. 常见问题与排查思路6.1 常见报错速查表问题现象常见原因解决思路手机 Termux 编译 cmake 失败缺少依赖或内存不足安装 git、cmake、make、clang必要时使用 swap模型加载后直接崩溃系统内存不足换更小模型、降低上下文长度、改用 Q4_K_M生成速度很慢线程数设置过低或跑在非优化后端适当提升-t确认是否走了 GPU 后端量化后回答明显变差量化位宽过低回退到 Q6_K 或 Q8_0重新评估adb push 权限失败手机未开启 USB 调试或存储权限检查开发者选项、授权 MTP 存储6.2 SDK 与工具链版本不匹配问题手机端开发踩坑最多的一类问题就是工具链版本和手机实际环境不一致。不止是大型模型推理普通移动应用也经常遇到编译产物与设备 SDK 不匹配的情况。典型表现是应用在开发机上编译正常但安装到真机后启动报错或功能异常。例如使用跨端工具链编译时如果 IDE 编译器版本是 5.x而手机端 SDK 版本是 4.x 或明显偏低就会出现“本应用使用某个编译器版本编译而手机端 SDK 版本是另一个版本不匹配”这类提示。这种问题在端侧推理 SDK 集成时也同样存在用新版 NDK 编译的 so 文件放到旧系统手机上可能因为 GLIBCXX、OpenCL 或特定系统 API 缺失而加载失败。排查思路如下。记录 IDE、NDK、CMake、推理框架的完整版本号。在 targetSdkVersion 和 minSdkVersion 之间留有合理的兼容区间。真机联调优先选择系统版本接近用户大盘的设备。不要把开发机“能编译”等同于真机“能运行”。6.3 手机发热降频对评测的影响手机和 PC 的最大区别是散热能力有限。连续跑 10 分钟大模型推理后SoC 表面温度升高系统会主动降频此时 tokens/s 可能下降 20% 到 40%。如果评测只跑一次短测试得到的是理想峰值速度不代表用户真实体感。建议评测至少跑 3 轮每轮之间间隔 1 分钟记录第一轮和最后一轮的数据。如果产品需要长时间对话更应该用 30 分钟连续推理的压力测试来验证稳定性。7. 手机端小模型评测的最佳实践7.1 固定评测变量手机端评测结果受变量影响很大因此任何一次评测都必须明确记录手机型号、系统版本、SoC 型号。推理框架名称与版本。模型名称、模型版本或 commit id、量化格式。prompt 长度、生成长度、上下文长度。线程数、是否启用 GPU、是否开启 Flash Attention。温度、top_p 等采样参数。推荐在评测开始前写一份 checklist逐项确认。没有这些信息的评测数据基本不具备复用价值。7.2 建立基线并定期回归模型更新速度很快推理框架也在不断优化。建议每个月或每个季度跑一轮固定基线把模型换成最新版本对比同一台测试机上的数据变化。这样做的好处是当线上体验波动时你可以快速判断是模型权重变了、推理框架变了还是用户设备系统更新导致的性能回归。版本管理中还要记录模型文件的 hash 值防止文件意外损坏或误替换。7.3 隐私、安全与合规端侧推理天然具备隐私优势因为用户输入不需要上传到云端。但这不是“完全无风险”。如果模型能读取本地通讯录、短信等敏感数据那么模型输出同样可能泄露隐私。因此只在沙箱目录中读取用户数据不给模型全局文件系统权限。对模型输出做关键词过滤或指令边界校验避免生成违法、有害内容。在接入第三方模型权重前确认其开源协议是否允许商用和再分发。评测数据如果包含真实用户信息必须先脱敏。8. 总结与下一步学习方向手机端小模型评测不是单纯跑一个 benchmark而是一套融合模型选型、量化方案、推理框架、真机调优和结果判断的工程方法。本文从评测指标设计讲起完整演示了用 llama.cpp 在 PC 上转换量化模型、在 Android 真机上编译运行、用 llama-bench 采集性能、再配合答案对比脚本完成质量评估的流程也整理了版本不匹配、发热降频、量化质量下降等高频问题。如果你想继续深入可以优先研究三块内容。第一是量化原理理解 GGUF、GPTQ、AWQ 的差异这能帮你在质量与速度之间找到更细的平衡点。第二是推理框架的算子加速尤其是手机 NPU 和 GPU 后端接入方式这直接决定生成速度的上限。第三是自定义评测集把业务里的高频问答沉淀成自动化用例形成团队内部的“小模型质检流水线”。手机端小模型评测的核心永远不是跑一个漂亮的分数而是让模型在真实设备上提供稳定、可接受的体验这也是每次评测前最该想清楚的问题。