Artificial Analysis 联合 Liquid AI 发布的手机端小模型评测最近在端侧 AI 开发者圈子里讨论度不低。它要回答的问题很具体在手机这种内存、功耗、算力都被严格约束的设备上哪些小模型既能跑得动又能在真实任务上维持可用质量。对做移动端 AI 应用、离线助手、端侧 Agent 或边缘推理的开发者来说这类评测比云端大模型榜单更有参考价值因为测试环境更接近真实部署场景。不过要真的用好这份评测不能只盯着排名和最高分。你需要先理解它测了什么、用什么指标测、结果能不能在自己设备上复现以及哪些分数在选型时可以直接用哪些必须打折扣。这篇文章就按这条思路展开。1. 手机端小模型评测到底在测什么1.1 为什么“手机端小模型”需要一套独立评测先看背景。端侧推理的核心诉求是数据不出设备、断网可用、响应更快。手机能装下的模型规模由内存和算力共同决定内存不仅要装模型权重还要装激活值、KV Cache 以及系统里其他进程所以实际可用的模型体积通常只有几个 GB。这也是为什么评测会聚焦在 0.5B 到 8B 参数的小模型并且几乎必须使用 INT4 或 INT8 量化。云端模型评测通常把速度和内存当作次要指标因为服务器可以堆显卡、扩容、热迁移。手机端完全相反。模型一装进手机推理速度直接决定用户能不能接受内存占用决定进程会不会被系统杀死。所以手机端评测必须同时回答三个问题模型质量够不够跑得快不快内存吃得住吃不消。这就是它从云端评测里独立出来的根本原因。1.2 评测源头里的两个角色这份评测之所以受关注是因为它把“模型设计方”和“第三方测评方”放在了一起。Artificial Analysis 是第三方模型评测平台长期按统一口径收集模型质量、推理速度和部署成本数据再对外发布横向对比结果。它的价值在于口径一致尽量用相同设备、相同提示词、相同量化条件去比较不同模型减少“各测各的”造成的误差。Liquid AI 在产品路线上强调液态神经网络和 LFM 系列模型核心思路是用更小的参数规模获得接近大模型的推理能力。这类模型天然适合手机端和边缘设备所以联合评测的落地场景非常清楚。两家合作可以把“模型设计方的能力声明”和“第三方独立测试结果”放在同一份报告里。对开发者来说重点不是无条件相信某一方而是看到同一批模型在同一个设备、同一套提示词、同一个量化条件下的可比数据。1.3 评测维度质量、速度、内存、成本手机端模型评测至少包含四个维度缺少任何一个都会造成误判。评测维度具体内容实际关注点质量通用知识、指令遵循、代码生成、工具调用是否满足真实业务需求速度输出 token/s、首 token 延迟TTFT对话是否流畅、响应是否及时内存模型文件体积、运行期峰值内存进程是否会被系统回收成本下载体积、量化格式、硬件要求分发、更新、兼容成本这里要特别注意 Agent 评测。近两年的小模型评测里工具调用类任务占比越来越高。手机端的小模型不仅要会生成文本还要能理解用户意图、选择工具、按 JSON 格式输出工具调用参数、在多轮对话里保持状态。语音助手、快捷指令、自动化操作都属于这类场景。所以看评测报告时不要只盯语言知识分数还要确认它是否包含工具调用类任务。知识分数高不代表 Agent 能力好这是选型时最容易踩的坑。2. 评测指标拆解这些数字为什么要对照着看2.1 四个核心性能指标评测报告里最常出现的数字是 tokens/s但单看它很容易误判。手机端至少需要同时关注四个指标。指标含义使用感受测量建议输出速度每秒生成 token 数连续对话是否卡顿固定 prompt 和生成长度后测量TTFT提交后到首个 token 的延迟打开页面是否立即出字控制网络和存储干扰峰值内存推理期间最大内存占用会不会被杀进程、卡顿用 adb 或系统监测工具统计模型体积量化后文件大小下载安装成本、磁盘占用统计 GGUF 等实际文件大小这几个指标之间存在冲突。输出速度快不代表首字快TTFT 更影响“点开即用”的感知。内存峰值和上下文长度强相关上下文开得越大KV Cache 占用越高。量化越狠速度和内存越好看但质量可能明显下降。因此评测报告里任何单个数字都不能独立解读必须和量化方式、上下文长度、设备型号放在一起看。2.2 质量分必须匹配你的业务任务质量分数也有分类。MMLU 类评测测的是知识记忆IFEval 类评测测的是指令遵循HumanEval 类评测测的是代码生成Agent 类评测测的是工具调用和状态维持。手机应用里最常见的场景是“短指令、结构化输出”所以应该优先看指令遵循分数和 Agent 分数知识类分数作为参考而不是决定因素。还要注意提示词模板和采样参数会明显影响评测结果。同一个模型温度设为 0 和设为 0.8在结构化输出任务上的表现差别很大chat template 用错甚至会出现乱写、重复、输出格式不合格。第三方评测通常会固定这些条件但固定条件对你的业务未必公平。使用榜单前最好确认评测用的 prompt 模板和你的实际调用方式是否接近。2.3 量化方式是榜单可比的必要条件手机端无法直接加载 FP16 权重的 7B 模型因为权重就要约 14GB远超普通手机的内存预算。INT4 量化后同样一个模型可以压到 4GB 左右才具备落地可能。量化方式直接决定评测结果所以评测必须注明量化级别否则数字之间没有可比性。以 7B 参数模型为例常见量化的体积大致如下实际数值因模型词表和层结构不同会略有差异。量化格式7B 模型约占用质量损失手机端适用性FP16约 14 GB无不适合内存放不下Q8_0约 7.6 GB很小仅适合大内存平板Q5_K_M约 4.8 GB较低中高端手机Q4_K_M约 4.2 GB可接受主流手机首选Q4_0约 3.8 GB明显低内存手机的备选同一个模型Q4_0 和 Q5_K_M 在多数任务上差别不大但在代码、工具调用这类对输出格式敏感的任务上退化可能很明显。榜单如果不标注量化级别先不要急着用。3. 本地复现评测在 Android 设备上跑一次推理基准3.1 环境准备与前置条件榜单只能作为参考真正决定选型的是“这台模型在你的手机上表现如何”。复现评测不复杂但需要准备几样东西。一部 Android 手机建议 8GB 以上内存支持 64 位应用。Termux 环境或者 llama.cpp 的 Android 构建包。一份 GGUF 格式的量化模型文件。稳定的网络和充足电量测试期间不要插着快充跑重负载。最省事的方式是直接使用 llama.cpp 官方 Android 示例 App想获得更大自由度可以在 Termux 里自己编译这样能精确控制线程数、上下文长度和卸载到 GPU 的层数。3.2 在 Termux 中编译 llama.cpp打开 Termux依次执行以下命令安装工具链并编译。pkg update -y pkg install -y git cmake ninja build-essential python3 git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build -j4编译取决于手机 CPU 性能通常需要几分钟。如果不想等可以直接用预编译的 Android 版本。编译完成后重点确认build/bin/llama-bench和build/bin/llama-cli两个文件存在它们分别用于性能基准测试和对话验证。下载模型时注意选择与设备内存匹配的量化版本。# 示例下载地址实际使用时替换成目标模型的 GGUF 下载路径 wget -O model-q4_K_M.gguf \ https://huggingface.co/example/models/resolve/main/model-q4_K_M.gguf3.3 运行性能基准并记录输出进入 llama.cpp 构建目录运行内置基准工具。./build/bin/llama-bench \ -m model-q4_K_M.gguf \ -p 128 \ -n 128 \ -t 4参数含义-m指定模型文件-p 128表示用 128 个 token 的提示词做 prefill-n 128表示生成 128 个 token-t 4表示使用 4 个线程。输出会类似下面这样具体数字因设备和模型而异。model size params backend threads test t/s gguf model 4.2 GiB 3.1 B C 4 pp128 14.5 gguf model 4.2 GiB 3.1 B C 4 tg128 11.2pp128是提示词处理阶段的吞吐tg128是文本生成阶段的吞吐。手机端场景里tg128更接近用户实际感知的生成速度。建议固定条件下重复运行三次取中位数用于对比而不是只跑一次。3.4 用 adb 观察真实内存占用性能分数之外内存是另一个必须验证的指标。通过 adb 连接设备后可以查看推理进程的内存情况。adb shell dumpsys meminfo com.example.llamapp重点关注TOTAL PSS和Native Heap两项。如果进程在生成过程中直接消失通常就是内存超限被系统回收。桌面环境复现时可以通过以下命令观察最大常驻内存。/usr/bin/time -v ./build/bin/llama-bench \ -m model-q4_K_M.gguf \ -p 128 \ -n 128 \ -t 4查看Maximum resident set size字段。注意这个值包含了权重、KV Cache 和激活值是判断“设备是否跑得动”的直接依据。3.5 复现评测的检查点复现第三方评测时至少要核对这几项模型文件的哈希是否一致量化级别是否一致上下文长度是否一致线程数和温度设置是否一致。任何一项不同跑出的数字都不具备可比性。同时记录设备的电池温度和 CPU 频率因为手机一旦触发温控降频吞吐会明显下降造成“同一台手机上午快下午慢”的假象。4. 影响评测结果的关键参数4.1 上下文长度和 KV Cache 的取舍上下文长度直接影响内存和速度。KV Cache 的大小约等于模型层数、注意力头数、头维度、序列长度和每项字节数的乘积再乘以必要的系数。手机端每增加 1K 上下文KV Cache 就会增加几十到几百 MB具体取决于模型结构。上下文长度开得大长对话能力增强但内存上涨开得小内存省了对话却被强行截断。参数含义调大影响调小影响-c / --ctx-size上下文长度长对话、长文档更强内存和延迟上升内存下降但对话可能被截断-t / --threads推理线程数多核利用率高吞吐上升耗电增加更省电但生成变慢-ngl卸载到 GPU 的层数加速明显内存和功耗增加回落到 CPU速度下降调优时不要只看峰值吞吐。先确认业务里最长对话需要多少 token再反推上下文长度。盲目把上下文开到 32K在手机端通常不是一个合理选择。4.2 采样参数和提示词模板的影响同样的模型生成参数不同质量和稳定性差别很大。温度过高会让 Agent 的 JSON 输出不稳定温度过低又可能让回答变得机械。第三方评测通常会固定采样参数但你自己复现时也要固定否则很难定位是模型问题还是参数问题。./build/bin/llama-cli \ -m model-q4_K_M.gguf \ -p 请用 JSON 返回一个三天的健身计划 \ -n 256 \ -t 4 \ --temp 0.2 \ -c 4096这段命令把温度固定为 0.2上下文设置为 4096适合验证结构化输出任务。要注意使用模型原生的 chat templatellama.cpp 在某些版本里需要显式指定--chat-template模板错了会出现乱写、重复或前后内容不一致。4.3 设备差异CPU、GPU、NPU 与散热同一份评测榜单换一台手机结果可能完全不同。不同手机的 CPU 多核性能差异很大散热设计也不一样。散热差的手机会在连续推理几分钟后触发温度墙吞吐断崖式下降。部分模型可以接入 NPU 或 GPU但部署复杂度会显著提高而且 NPU 对算子支持不完整时反而可能比 CPU 更慢。所以不要把榜单里的设备参数当成“所有手机的典型表现”。榜单的价值是横向排序不是替你完成最后一公里验证。5. 评测数据解读中的常见坑与排查路径5.1 复现分数总是低于榜单这是复现评测时最常见的现象。按下面顺序排查。问题现象常见原因检查方式处理建议分数低 20% 以上量化、上下文、线程数不一致对比命令参数和文件哈希统一配置后重测速度忽高忽低温控降频或后台应用抢占查看 CPU 频率和电池温度冷却后静置重测进程被系统回收峰值内存超出设备预算用 adb dumpsys 查看内存换更低的量化级别或缩短上下文检查 CPU 频率时可以在部分设备上读取系统节点adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq不同设备的路径可能不同但思路一致先确认 CPU 是否处于降频状态再判断性能波动的原因。手机端评测必须记录温度和频率否则数据不可信。5.2 分数高但真实体验差评测分数只能反映评测集覆盖的任务。MMLU 考的是知识记忆如果你的业务是快速提取短信验证码并输出 JSON知识分数再高也没有直接帮助。评测环境通常固定了 prompt真实场景里用户输入五花八门模型的表现会有明显波动。建议自建一套“业务基线”准备 10 到 50 条真实业务输入固定 prompt 模板逐条记录成功率和典型错误。用这条基线去对比候选模型比任何公开榜单都更接近最终体验。5.3 榜单排名不等于选型结论榜单排名基于特定配置比如特定手机、特定量化、特定上下文。但选型还要看集成成本、系统兼容性、模型加载时间、热更新方案和维护成本。一个排名靠前的模型如果要用很复杂的算子库才能在目标手机上运行实施风险会显著上升。正确做法是把榜单当筛选器先通过公开评测缩小候选范围到两到三个模型再在自己的目标设备上跑业务基线最后结合集成复杂度做决定。榜单负责缩小范围实测定最终结论。6. 从评测到选型移动端模型落地清单6.1 选型的判断顺序不要一上来就比速度。推荐的判断顺序是质量是否满足核心业务尤其是结构化输出和工具调用能力。量化后内存是否可接受确认峰值内存低于设备可用内存。速度是否流畅TG 吞吐是否达到业务要求。功耗是否可控长时间运行是否会触发降频。集成与维护成本包括框架选型、模型热更新和异常回退。6.2 可复用的模型复测清单每次评测新模型时按下面清单执行可以保证结果可复现、可对比。记录设备型号、系统版本、可用内存。固定模型文件与量化级别记录文件 SHA-256。固定上下文长度、线程数、采样参数和 chat template。清理后台应用固定屏幕亮度充满电量。每次连续运行至少三次取中位数。同步记录电池温度、CPU 频率、峰值内存。用业务内的真实样例做 10 到 50 条定性对比。保存设备环境与完整命令参数方便两周后再次复现。6.3 学习环境与生产环境的差异学习阶段不需要先买旗舰手机。一台普通 PC 加 llama.cpp 就能理解量化、KV Cache、解码速度这些核心概念跑通后再迁移到 Android 环境。开发阶段可以根据团队技术栈选择框架。llama.cpp 社区活跃、部署资料多MLC-LLM 在多种硬件后端上统一性强ExecuTorch 适合计划深度嵌入自家 APP 的场景。不同框架对算子和模型结构的支持程度不同选型前要先验证目标模型能否在该框架下完整运行。生产环境还要额外考虑模型加载策略和冷启动时间、端云降级方案、模型热更新与灰度、推理日志和性能监控、异常时的回退逻辑。手机端模型评测解决的是“模型选哪个”的问题而产品能否稳定运行还要靠这些工程能力兜底。回到 Artificial Analysis 与 Liquid AI 的这次评测合作。它最有价值的不是某几个具体分数而是把“手机端小模型可用性”拆成了可对比的数据维度。对开发者来说正确用法是拿榜单缩小候选范围再用自己业务的真实问题在目标设备上完成验证最后用自己测出来的数字做决定。模型在更新评测在变化设备也在换代但“在真实约束下验证真实效果”这个原则不会变。