手机端跑大模型性能实测：MELTing Point基准测试深度解析

当大模型走向手机：一份罕见的真实基准测试

随着端侧AI浪潮兴起，越来越多人开始追问同一个现实问题：手机和边缘设备，究竟能不能流畅运行大语言模型（LLM）？近日，一篇名为《MELTing Point: Mobile Evaluation of Language Transformers》的论文在社区引发热议。一位深耕边缘设备LLM基准测试的Reddit用户分享了他的深度阅读笔记，将其评价为近期关于移动端性能基准测试最出色的论文之一。

这篇论文的价值体现在两个维度：一是高度还原真实用户使用场景的测试设计；二是提出了 prefill-decode 分离（disaggregation） 方案。要理解这一方案的意义，需要先深入了解 LLM 推理的底层机制。

Prefill（预填充）阶段本质上是一次大规模矩阵乘法（GEMM），负责一次性处理所有输入 token，属于计算密集型任务，可高度并行、对 GPU 算力要求极高——输入序列越长、并行度越高，GPU 的 Tensor Core 利用率越充分，这也是为什么云端 GPU 集群特别适合承担该阶段。Decode（解码）阶段则逐个生成输出 token，每次只生成一个 token，计算量极小，瓶颈完全在于将模型权重从显存读入计算单元的内存带宽——以 Mistral-7B 的 Q4 量化版本为例，每生成一个 token 就需要读取约 3.5GB 权重数据，这对移动端有限的内存带宽（通常为 50-80 GB/s）构成严峻挑战，相比之下云端 A100 的内存带宽高达 2 TB/s。将两者分离部署，可让高算力设备专注 Prefill、低功耗移动端承担 Decode，是云边协同推理的重要架构方向。这与业内大多数只在裸机上跑 token 吞吐量的评测有着本质区别。

测试设备矩阵：从老旧机型到旗舰全覆盖

论文的实验设置极具工程化思维，测试设备横跨多个性能层级：

手机端：iPhone SE、iPhone 14 Pro、三星 Galaxy S23、Pixel 6a
NVIDIA 边缘设备：Jetson Nano、AGX Orin

测试模型从超轻量到中量级全面覆盖：TinyLlama、Llama-2、Gemma、Zephyr-3B、Mistral-7B，推理后端则采用 MLC-LLM 和 llama.cpp 两套主流框架。

这两套框架代表了端侧推理的两种截然不同的设计哲学。MLC-LLM 由陈天奇团队开发，基于 Apache TVM 机器学习编译器栈，能够针对目标硬件的指令集、缓存层级和并行架构进行自动调优（AutoTuning），生成接近手写汇编质量的本地代码。这种 AOT（Ahead-of-Time）编译方式与手机 GPU 的 Metal/Vulkan 驱动深度集成，能绕过运行时解释开销，理论上可充分挖掘硬件潜力，但编译链路较为复杂。llama.cpp 则通过 GGUF 量化格式和高度优化的 CPU 内核（利用 ARM NEON、AVX2 等 SIMD 指令集），在无 GPU 的环境下依然保持可用性能，跨平台兼容性极强，社区活跃、上手门槛低，但在 Apple Silicon 或高通 Adreno GPU 的专项优化深度上略逊于前者。这也解释了为何两套框架在相同设备上的表现存在显著差异。

值得强调的是，这些模型并非"裸跑"，而是集成进真实聊天应用中运行——Android/iOS 上的 MLChat，以及支持 iOS Metal 加速的 LLMFarm。这种做法让测试结果更接近用户在手机上的真实体验。

以树莓派为核心的自动化测控平台

整个测试平台以一台 Raspberry Pi 4 作为中央控制器，统一负责任务调度、数据采集与设备交互，下辖两个测试分区：

PhoneLab：管理所有 Android 与 iOS 手机
JetsonLab：管理 NVIDIA 边缘设备

这套测控架构的设计选择颇具工程智慧。Android 端通过 ADB（Android Debug Bridge）提供丰富的系统级访问权限（如直接读取 /proc/stat 获取 CPU 利用率），iOS 端则采用树莓派连接键鼠的自定义 HID 装置——HID（Human Interface Device）是 USB 标准子类，树莓派通过 USB OTG 模式将自身模拟为 HID 设备，可向 iOS 设备注入精确定时的触控和键盘事件，从而绕过苹果对第三方自动化框架的限制，模拟人类真实的打字与滚动操作。

热量测量方面，研究者通过热成像相机捕捉手机表面温度，通过 SysFS 读取 NVIDIA 设备数据——不过这里也有一个局限：无法获取 CPU/GPU 各组件的精细温度数据。此外，团队通过继电器和 YAKUSH 控制器实现设备的统一断电上电，让 USB 仅承担数据传输而非充电功能，但该方案在 iPhone 上遭遇了兼容性问题。

核心亮点：像真实用户一样操作手机

真正让这篇论文脱颖而出的，是对"真实用户体验"的极致还原。研究者从 oasst1 数据集中筛选出 50 条 prompt（每条 6-10 词起步，中位数约 36 词），并重复测试三轮。

整个用户交互流程——打开聊天 App、输入对话、等待 LLM 回复——全部纳入监控范围。值得注意的是，HID 事件注入的时序精度受 USB 总线调度影响，可能引入 1-10ms 量级的抖动，在高频采样的性能监控中需要后处理滤波，这也是后文提及的"HID 模拟可能引入噪声"问题的技术根源。

论文还探索了一个前沿架构方案：在 NVIDIA 设备上完成 prefill，再通过 WiFi 6 将 decode 任务下发至手机执行。这正是 prefill-decode 分离思想的工程落地实践。WiFi 6 理论带宽高达 9.6 Gbps，以 Mistral-7B 为例，处理 512 个 token 后产生的 KV Cache 约为 256MB（fp16 精度），理论传输仅需约 200ms，但实际信道效率、协议开销和多设备竞争会使延迟显著上升。此外，KV Cache 在 NVIDIA Orin 与 Apple Metal 之间的数据布局格式差异还需要额外转换开销——这也是该方案目前仍停留在研究阶段、距离产品化还有相当距离的原因之一。在保证体验的前提下，该架构使手机仅承担内存带宽友好的逐 token 生成工作，大幅降低了移动端的算力压力。

QES 质量体验评分：超越单一吞吐量指标

论文提出的 QES（Quality Experience Score） 是另一大创新点，从三个维度综合评估端侧体验：

响应性（Responsiveness）：推理过程中手机是否出现卡顿或无响应
稳定性（Stability）：连续对话场景下的性能一致性（通过连续三轮共 150 次对话压力测试）
温度（Temperature）：结果颇为惊人——手机表面最高温度达到 47.1 摄氏度，已接近烫手临界值

实测数据：GPU优势、能耗规律与诡异的性能尖峰

测试结果既有意料之中，也有不少意外发现：

GPU 推理明显优于 CPU，iPhone 在 GPU 推理上表现领先，尤其搭配 LLMFarm 后端时效果突出——归因于其对 Metal GPU 加速的高效调用，MLC-LLM 在这方面略逊一筹。而在 CPU decode 场景下，Android 设备反而比 iPhone 稍快。

量化精度测试覆盖 Q3 和 Q4，理解两者差异有助于解读测试结论。模型量化将神经网络权重从高精度浮点数压缩为低比特整数：Q4（4-bit 整数量化）通常采用分组量化（Group Quantization）策略，每 32 或 64 个权重共享一组缩放因子，能在保持较低精度损失的前提下实现约 4 倍压缩；Q3 则面临更严峻的信息熵压缩问题——将浮点权重压缩至仅 8 个离散级别时，对注意力层中的极值权重会产生较大失真。GPTQ、AWQ 等先进量化算法虽能通过 Hessian 矩阵引导的权重补偿缓解 Q3 的精度损失，但其计算开销本身也会部分抵消推理加速效益。测试结果显示 Q4 在吞吐量与能效两项指标上均更优——它处于精度损失与计算效率的帕累托最优边界附近，而 Q3 在移动端有限算力下反而可能因频繁的精度补偿操作拖慢整体性能。

在稳定性压力测试（3×50 次对话）中出现了一个值得关注的现象：第 20 和第 32 次迭代时，吞吐量与 prefill 速度都出现了性能尖峰（AGX Orin 同样如此）。论文将其归因于 DVFS（动态电压频率调节）——这是现代移动处理器的核心节能机制。以高通骁龙 8 Gen2 为例，CPU 大核频率范围为 1.0-3.2 GHz，GPU 频率范围约为 587-680 MHz，调频间隔可低至毫秒级。当持续高负载触发热保护阈值（通常为芯片结温 75-80°C）时，系统会主动降频（Thermal Throttling）造成吞吐量骤降；而当任务暂时减轻后系统频率回升，则会产生短暂的性能峰值。该读者则补充判断——prefill 的跳变更可能源于 KV Cache 重建阶段：KV Cache 通过缓存历史 token 的注意力键值对来避免重复计算，随着对话历史累积其体积持续增长，当 Cache 被清空后重建时会触发密集的内存读写操作，在内存带宽有限的移动端芯片上尤为明显，是端侧推理性能抖动的重要根源。

其他值得关注的细节：

iPhone 加载所有测试模型均在 5 秒内完成，Pixel 表现相近；S23 相对较慢，加载 7B 模型需 14 秒，加载 3B 甚至超过 30 秒（疑似以 fp32 精度加载）
加载 Zephyr-3B 时手机出现无响应——若非 HID 模拟人类触控操作，这一问题极可能被遗漏
高延迟模型消耗更多电量（mAh）
ALU 利用率偏低，大量时间花费在内存读写上——这是端侧推理的典型性能瓶颈，也印证了 LLM Decode 阶段本质上是内存带宽受限（memory-bound）而非算力受限（compute-bound）的工作负载特征

值得商榷的局限与不足

这位读者也客观指出了论文存在的几处问题：

配置网格搜索导致横向对比困难：对上下文长度、生成长度、batch size 做 grid search，使各设备结果难以直接比较
HID 模拟操作可能引入噪声：完整模拟人类交互虽真实，但 HID 事件注入的 USB 总线调度抖动可能给监控系统带来额外干扰，或许以后台任务替代会更简洁
线程数未统一调整：仅在 iPhone 的 LLMFarm 上启用多线程，可能导致其 tok/sec 数据偏高，影响横向公平性
QES 测试中未让设备充分散热：作者对此给予正面评价，认为更贴近极限压力场景
缺乏精细的频率与热力曲线：若提供 CPU/GPU 频率变化数据，DVFS 引发的性能尖峰将得到更有力的解释

结语：端侧LLM评测的方法论参考

总体而言，MELTing Point 是一篇难得的、以真实用户视角出发的手机端 LLM 基准测试研究。它在多轮对话设计、QES 综合评分、贴近真实的设备测试三个维度上均有扎实建树。对于任何希望认真评估边缘设备 LLM 部署能力的团队而言，这套方法论都是极具参考价值的起点。

随着更多轻量化模型和高效推理后端持续涌现，如何在推理性能、能耗控制、发热管理与用户体验之间找到最优平衡点，将成为端侧 AI 规模化落地绕不开的核心命题。MELTing Point，正是朝这个方向迈出的重要一步。