先看结果：跑分第一的框架，未必适合你的项目。
在骁龙 X Elite 的 Windows on Arm 笔记本上，ExecuTorch 的首 token 延迟压到 375ms，比 llama.cpp 纯 CPU 方案快 22%。换到天玑 9400 工程机，MNN 的稳态吞吐跑到 26.4 tokens/s，反超 llama.cpp 18%。ExecuTorch 因为 NPU delegate 适配没跟上，掉到第三。
模型没变，都是 Qwen2.5-7B-Instruct 的 INT4 量化版。变的只是芯片平台，三款框架的排序就重新洗牌。端侧推理的麻烦也在这里：同一个 7B，在不同 Arm 设备上，瓶颈可能完全不是一回事。
7B 为什么成了端侧常用尺寸
2024 年，社区还在讨论手机和轻薄本到底能不能顺畅跑 7B。到 2026 年，7B 参数模型已经成了不少手机和 AI PC 的常见选择。
面壁智能的 MiniCPM 系列在 2024 年 2 月发布后，主打轻量和端侧性能，官方也强调它在全球开源社区被反复测试和使用。这个方向能跑起来，不只靠模型变小，也靠 INT4 量化、KV Cache 管理和芯片侧算子优化一起推进。
7B 的位置比较微妙。INT4 量化后，模型占用大约 3.5-4.5GB 内存，12-16GB RAM 的旗舰手机有机会跑得动；放到 32GB RAM 的 Windows on Arm 笔记本上，余量更大。14B 当然也能尝试，但散热、调度和长时间稳态会更麻烦，尤其是 NPU、CPU、GPU 混合调度时，热节流很容易把峰值性能打回去。
Arm 官方在计算平台介绍里也把端侧 AI 和 ML 推理列为重点方向，提到从云端到边缘侧构建、优化和部署 AI。对开发者来说，这句话落到工程里，就是框架能不能吃到 Cortex-A、GPU、NPU 这些硬件资源，而不只是模型文件能不能加载。
这次怎么测
测试设备两台：一台骁龙 X Elite Windows on Arm 笔记本，32GB RAM；一台天玑 9400 工程机，16GB RAM。
模型统一用 Qwen2.5-7B-Instruct INT4 量化版。场景分三类：短文本对话，输入 50 token；中长文档摘要，输入 800 token；多轮对话上下文累积到 3200 token。
对比框架是 llama.cpp、ExecuTorch 和 MNN。三者都能跑端侧 LLM，但路线差异很大：llama.cpp 更偏通用和稳定，ExecuTorch 强在 PyTorch 链路和特定硬件 delegate，MNN 则更依赖 Arm 指令集和移动端算子优化。
llama.cpp：慢一点，但很稳
llama.cpp 的优势不是峰值，而是可预期。
在骁龙平台上，3200 token 上下文时，它的内存波动不超过 150MB。代价也明显：NPU 利用率几乎为零，主要靠 CPU 扛推理。首 token 和吞吐不一定漂亮，但长时间跑聊天机器人、语音助手这类任务，稳定性比短跑成绩更值钱。
这次测试里，ExecuTorch 在超过 2048 token 后出现过 OOM 崩溃，而且是在 32GB RAM 环境下发生。这个现象说明，端侧 LLM 不是“内存够大就安全”，内存碎片、KV Cache 分配策略、上下文增长后的回收机制都会影响可用性。
llama.cpp 还有一个现实优势：GGUF 格式的模型资源多。ModelScope 和 HuggingFace 上，预量化好的 7B 模型更容易找到。做原型、做跨设备适配，少一次量化转换，就少一段排错时间。
ExecuTorch：骁龙上首 token 很快
ExecuTorch 的强项在骁龙 X Elite 上很明显。
它能把 Prompt 处理里的矩阵乘法卸载到高通 Hexagon NPU，Prefill 阶段首 token 延迟做到 375ms，比 llama.cpp 纯 CPU 方案低 22%。如果产品场景是文档摘要、邮件处理、短提示词问答，用户首先感受到的就是“出来得快不快”，这类优化很直接。
不过，解码阶段并没有把优势继续拉大。NPU 频繁唤醒会带来调度开销，平均 token 延迟没有和其他框架拉开同样幅度。
更关键的是，这套 delegate 链路有平台边界。到了天玑 9400，ExecuTorch 只能回退到 CPU 推理，首 token 延迟反而垫底。也就是说，如果你的设备池主要是骁龙，ExecuTorch 值得优先试；如果要覆盖不同 Arm SoC，就要提前评估回退路径。
MNN：天玑 9400 上吃到了 Arm v9 红利
MNN 在天玑 9400 上的表现最突出。
阿里在 2026 年 3 月发布的 MNN 3.0 增加了对 SVE2 的自动检测和算子调优。天玑 9400 没有 Hexagon NPU 这条路，AI 加速更多依赖 Cortex-X5 大核的 SVE2 指令集。MNN 在这个平台上把优势打了出来：短文本对话首 token 198ms，比 llama.cpp 的 264ms 快 25%，比 ExecuTorch 的 301ms 快 34%。
长文本摘要场景里，差距继续拉大。MNN 对 FlashAttention 做了 Arm 汇编级重写，减少 KV Cache 的重复加载，首 token 延迟 378ms，领先第二名 llama.cpp 约 25%。
这类优化很“底层”，但对端侧推理特别重要。云端服务可以靠更多 GPU 和批处理摊平问题，手机和轻薄本不行。功耗、温度、内存、调度延迟都会挤在一起，算子少搬一次数据，体验就可能差一截。
别只盯延迟，量化链路更容易卡人
三款框架的量化格式并不互通。
llama.cpp 主要使用 GGUF；ExecuTorch 更靠近 PyTorch 原生量化链路，比如 GPTQ、AWQ；MNN 有自己的量化工具链。模型从 HuggingFace 下载后，往往还要按目标框架重新跑量化脚本。
这一步经常比想象中更耗时。校准数据集选得不好，精度会掉；转换脚本版本不匹配，部署会报错；同一个 INT4，在不同框架里的算子实现也可能导致延迟和显存表现不同。
内存策略同样影响落地。llama.cpp 的 KV Cache 偏保守，Q4_K_M 在 7B 上峰值能到 6.8GB。MNN 用固定内存池减少动态分配，工作集比 llama.cpp 少 350-500MB。放在 16GB RAM 的手机上，这几百 MB 可能决定后台应用会不会被系统杀掉。
还有个细节和桌面 GPU 经验相反：骁龙 X Elite 上，ExecuTorch 走 OpenCL 比 Vulkan 快约 8%，原因是 Hexagon NPU 驱动对 OpenCL 的优化更成熟。天玑 9400 的 Immortalis-G925 则更适合 Vulkan 路径，MNN 在这条路径上吞吐能跑到 26.4 tokens/s。
三类场景，选法不同
如果做聊天应用、语音助手，优先考虑 llama.cpp。多轮对话会不断拉长上下文，内存稳定性比首 token 快几十毫秒更重要。尤其是上下文累积到 3000 token 以上时，ExecuTorch 的内存碎片问题可能带来不可预测的崩溃。
如果做文档摘要、邮件处理这类单次任务，芯片平台优先级更高。骁龙平台可以试 ExecuTorch，把 Hexagon NPU 的 Prefill 加速用起来；天玑或其他更依赖 Arm CPU/GPU 路线的平台，可以试 MNN 3.0，重点看 SVE2 和 Vulkan 路径表现。
如果要跨设备部署，覆盖中端机、IoT 或汽车座舱芯片，llama.cpp 和 MNN 的安全边际更高。ExecuTorch 的高通 NPU delegate 在非骁龙平台上不可用，Arm Ethos-U 的 delegate 支持还在 Beta 阶段。纯 CPU 路线和 Arm v9 通用优化，在碎片化设备里更容易控风险。
东吴证券在 2026 年 2 月发布的《2026 年端侧AI 产业深度》中，把端侧应用迭代、终端重构和 SoC 价值重估放在一起讨论。落到开发侧，SoC 的价值能不能被看见，先要看模型和框架能不能在真实设备上稳定跑完任务。
这次实测给出的结论很简单：不要拿一个总榜单决定框架。
骁龙 X Elite 上，ExecuTorch 的首 token 有优势；天玑 9400 上，MNN 的吞吐和首 token 更亮眼；llama.cpp 则在长上下文和跨设备上更稳。端侧 7B 的选型，最好把芯片、任务类型、量化格式和内存策略放在同一张表里看。只看平均延迟，很容易选到一个跑分好看、上线难受的方案。
