详解在手机/平板上跑LLM的 tiered 架构思路,推荐1B-4B参数量化模型(Llama 3.2、Qwen 2.5、Phi-3、Gemma),分析GQA对KV cache的优化。
将大语言模型直接部署到手机和平板设备上,背后的驱动来自三个硬性需求:延迟、隐私和离线可用性。然而,移动硬件的物理特性设定了一个天花板。旗舰级 SoC 上的 NPU 和 DSP 虽然性能强大,但热设计功耗(TDP)和电池容量使得长上下文推理或多轮推理变成快速耗电。实际的前进路径既不是纯边缘计算,也不是纯云端,而是采用分层架构:小型的量化模型在本地处理敏感的、高频的任务,而可预测的云 API 处理其余一切。
要控制功耗,模型必须能够在设备 DRAM 中运行而不需要频繁换页,工作集必须足够小以避免持续高频内存时钟。对于大多数当前的移动硬件,这意味着目标模型在 1B 到 4B 参数之间,量化到 INT4 或 INT8。
强候选模型包括 Llama 3.2 1B 和 3B、Qwen 2.5 0.5B 到 3B、Phi-3 Mini 3.8B,以及 Gemma 2B 和 4B。这些架构使用分组查询注意力(GQA)或多查询注意力(MQA),这会缩小 KV 缓存并降低内存带宽——而内存带宽是移动 SoC 上能耗最大的贡献者之一。
使用运行时原生支持的量化格式。通过 llama.cpp 使用 GGUF 是快速原型验证最常见的路径。对于生产级 Android 应用,带有 INT8 QDQ 图的 ONNX Runtime 和高通 QNN 委托让你可以在 Hexagon NPU 上执行。在 iOS 上,Core ML Tools 将模型转换后使用 Neural Engine。
from llama_cpp import Llama
llm = Llama(
model_path="./qwen2.5-1.5b-q4_k_m.gguf",
n_ctx=2048,
n_threads=4,
verbose=False
)
output = llm.create_chat_completion(
messages=[{"role": "user", "content": "Summarize this paragraph."}]
)
运行时的选择决定了你是让 CPU 耗费电力,还是在 NPU 或 GPU 上高效执行。
llama.cpp:移动 LLM 推理的事实标准。它在 iOS 上支持 Apple Metal,在 Android 上支持 ARM NEON/dotprod。Adreno 和 Mali GPU 可用 Vulkan GPU 卸载。这是使用 GGUF 模型最简单的路径。
MediaPipe LLM Inference API:Google 的跨平台解决方案,捆绑模型权重并处理内存映射。如果你希望在 Android 和 iOS 上使用相同代码,且不需要自定义量化,这个方案很有用。
ONNX Runtime Mobile:当你需要硬件加速器委托支持时最佳。高通神经网络(QNN)委托在 Hexagon NPU 上运行,Core ML 委托则面向 Apple Neural Engine。这是大型子 4B 模型实现最低持续功耗的路径。