手机端跑大模型，最容易被一个指标带偏：TOPS。它能描述芯片在特定精度下的峰值吞吐，却回答不了用户真正会遇到的问题：首轮回复要等多久，多轮对话会不会越来越慢，打开相机后是否抢内存，机身升温后还能维持什么水平。
先别急着谈40%
目前不宜把“7B至14B模型能效提升约40%”作为结论。现有可引用素材没有给出测试设备、模型版本、量化格式、上下文长度和功耗测量方法，也无法支持“2026年7月，AI专属CPU/GPU混合架构全面落地”的说法。在本稿现有素材中，同样找不到Arm官方对这组结论的确认。
缺少测试条件，40%就无法复核。它也不能直接证明手机已经可以持续运行复杂的本地智能体，更不能推导出实时多模态任务已经普遍可用。
公开信息能够确认的，是Arm正把移动AI作为一套完整计算平台推进。Arm官方的移动端AI页面同时列出CPU、CSS（计算子系统）和IP产品组合，并强调在Arm平台上构建、优化和部署从云端到边缘侧的AI工作负载。
Arm还提到，AI模型演进很快，软件发展开始领先硬件，需要计算栈各层继续调整。对开发者来说，这比单个跑分更有参考价值。模型能否落地，要看编译器、运行时、内存和调度能不能接上硬件。
手机上的第一道坎，往往是内存
如果团队把7B至14B模型作为目标，权重只占内存的一部分。激活值、KV Cache和临时张量还要与操作系统、相机及其他应用共享空间。对话越长，KV Cache占用越高；内存一旦频繁搬运，延迟和功耗都会受到影响。
因此，访存局部性值得单独检查。具体要看权重是否反复从DRAM读取，临时张量能否及时复用，KV Cache有没有持续扩张或出现碎片。峰值算力再高，也无法抵消低效的数据搬运。
拿LLaMA-3或Qwen-2.5做实验时，模型在PC上完成量化和转换，只能证明转换链路成立。到了手机，还要重新检查内存峰值、后端支持和持续运行状态。把云端模型压缩后直接装进手机，通常只能得到一个演示版本。
模型能输出，还要看算子落在哪里
常见部署流程会经过ONNX或TFLite，再调用NNAPI、CoreML等接口。这只是开始。开发者需要查看执行轨迹，确认Attention、矩阵乘等主要算子究竟运行在哪个后端，有没有回退到CPU。
算子回退很容易被忽略。模型仍然可以输出内容，CPU和GPU利用率看起来也不低，但首轮响应和连续生成速度已经受到影响。比起只看总利用率，逐算子延迟和后端分布更能说明问题。
INT4、FP8、AWQ和GPTQ也不能只看格式名称。它们是否有效，取决于目标设备的运行时支持，以及能否顺利落到NEON、Mali GPU或其他可用后端。量化完成后还要用真实任务样本复测。模型能够正常出字，并不代表语义质量没有下降。
动态批处理别照搬云端
云端使用动态批处理，通常是为了提高多请求吞吐。手机多数时候面对单用户交互，优先级更接近首轮响应、内存峰值和功耗。没有真实并发时，动态批处理反而可能增加等待和内存占用。
KV Cache管理也要结合运行时能力。PagedAttention或类似方案可以纳入测试，但前提是推理引擎确实支持，并且设备上存在需要解决的缓存碎片问题。仅仅打开一个配置项，不会自动带来收益。
线程调度同样没有固定答案。计算密集型算子该放在Prime Core还是Little Core，需要根据具体设备测试。Big.LITTLE架构下，最高瞬时性能、最低功耗和最长稳定运行时间，往往对应不同的调度方案。
发布前，别只跑一次Demo
一套可复核的手机端测试，至少应覆盖这些环节：
- 固定模型版本、量化格式、输入长度、上下文长度和设备电源状态，避免每轮测试条件不同。
- 分别记录模型加载时间、首个Token延迟、稳定生成速度和内存峰值。
- 查看运行时执行轨迹，列出回退到CPU的算子，而不是只看CPU或GPU总利用率。
- 连续进行多轮和长上下文推理，观察KV Cache、温度、频率及延迟变化。
- 在前台、后台、充电和非充电状态下重复测试，确认系统调度是否改变结果。
- 用实际业务样本检查量化后的输出质量，避免模型出现看似流畅、语义却已经偏移的情况。
这些测试不需要先设定一个通用的发热或降速阈值。不同手机的散热、系统策略和运行时版本差异很大，结论应绑定具体设备，而不是直接从芯片规格表推导。
3100亿颗芯片，意味着更大的适配范围
在2025年COMPUTEX前夕的演讲中，Arm高级副总裁兼终端事业部总经理Chris Bergey表示，基于Arm架构的芯片累计出货量已经超过3100亿颗。这一数据由深圳湾报道。
Arm在其20项技术预测中，也把计算从集中式云架构走向设备、终端和系统中的分布式智能列为明确方向。福布斯中国则提到，随着模型瘦身和轻量化，小模型正进入更多边缘设备，面对的是数以百亿计的边缘物联网设备。
如此大的设备范围，也带来了更复杂的适配问题。同一个模型可能运行在手机、平板、PC或物联网终端上，硬件能力、操作系统和运行时并不一致。开发团队需要准备设备分层和降级方案，而不是只在一台旗舰机上跑通后就宣布完成部署。
端侧部署逻辑确实要改，依据却不该是一个未经复核的40%数字。更可靠的顺序是：先确定使用场景，再选择模型和量化方式，随后核对算子与后端，最后用真机长时间测试内存、温度和功耗。做到这些，本地模型才有机会从演示变成稳定功能。
