边缘推理:Apple 神经引擎、Qualcomm Hexagon、WebGPU/WebLLM ...

边缘推理:Apple 神经引擎、Qualcomm Hexagon、WebGPU/WebLLM 与 Jetson

本节摘要:边缘推理的核心约束是内存带宽,不是算力。移动 DRAM 在 5090 GB/s;数据中心 HBM3 可达 23 TB/s——3050 倍的鸿沟。Decode 是内存受限的,所以这道鸿沟是决定性的。2026 年的格局分四路。Apple M4/A18 神经引擎(ANE)峰值 38 TOPS,统一内存(无 CPU↔NPU 拷贝);Qualcomm 骁龙 X Elite / 8 Gen 4 Hexagon 达 45 TOPS;WebGPU + WebLLM 在 M3 Max 上跑 Llama 3.1 8B(Q4)约 41 tok/s(约为原生的 7080%),GitHub 17.6k 星、OpenAI 兼容 API、约 70~75% 移动覆盖;NVIDIA Jetson Orin Nano Super(8GB)装得下 Llama 3.2 3B / Phi-3,AGX Orin 经 vLLM 跑 gpt-oss-20b 约 40 tok/s,Jetson T4000(JetPack 7.1)性能是 AGX Orin 的 2 倍。TensorRT Edge-LLM 支持 EAGLE-3、NVFP4、分块 prefill——在 CES 2026 由 Bosch、ThunderSoft、联发科演示。

对应原课程:Phase 17 · Lesson 12 · 12-edge-inference(原英文 phases/17-infrastructure-and-production/12-edge-inference/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 解释为什么移动 LLM 推理是内存带宽受限的,算力是次要的。
2. 列出四个边缘目标(Apple ANE、Qualcomm Hexagon、WebGPU/WebLLM、NVIDIA Jetson),并把每个对应到用例。
3. 说出 2026 年 WebGPU 覆盖缺口(Firefox Android 在追赶)与 Safari iOS 26 的落地。
4. 按目标选量化格式(ANE 用 Core ML INT4 + FP16,Hexagon 用 QNN INT8/INT4,浏览器用 WebGPU Q4,Jetson Thor 用 NVFP4)。

一、问题与直觉

某客户想要一个端上聊天机器人:语音优先、隐私默认、可离线。在 MacBook Pro M3 Max 上,Llama 3.1 8B Q4 跑约 55 tok/s——没问题。在 iPhone 16 Pro 上,同模型跑 3 tok/s——不行。在中端骁龙 8 Gen 3 安卓上,7 tok/s。浏览器经 WebGPU 在 Chrome Android v121+ 上,依设备 4~8 tok/s。

吞吐差异不是移植问题。它是带宽鸿沟 × 量化格式 × NPU 能否从用户态访问的乘积。2026 年的边缘推理是四个不同问题,有四个不同解。

二、核心概念

带宽才是真天花板

Decode 每 token 都要读全部权重。一个 7B Q4 模型是 3.5 GB。50 GB/s 读 3.5 GB 要 70 ms——理论上限约 14 tok/s。90 GB/s(高端移动 DRAM)上限约 25 tok/s。在这数字之下,多少算力都帮不上忙。

数据中心 HBM3 在 3 TB/s 下,同样 3.5 GB 只要 1.2 ms——上限 830 tok/s。同模型、同权重,不同内存子系统。

Apple 神经引擎(M4 / A18)

• 最高 38 TOPS。统一内存(CPU 与 ANE 共享同一池)——无拷贝开销。
• 经 Core ML + 编译后的 .mlmodel 访问,或经 Metal Performance Shaders(MPS)走 PyTorch。
• llama.cpp 的 Metal 后端用 MPS,不直接用 ANE;原生 ANE 需要 Core ML 转换。
• 2026 年 iOS 应用的最佳实操路径:Core ML,INT4 权重 + FP16 激活。

Qualcomm Hexagon(骁龙 X Elite / 8 Gen 4)

• 最高 45 TOPS。SoC 内与 CPU、GPU 集成,但内存域独立。
• QNN(Qualcomm Neural Network)SDK 与 AI Hub 提供从 PyTorch/ONNX 的转换。
• 聊天模板、Llama 3.2、Phi-3 都作为 AI Hub 一等构件发布。

Intel / AMD NPU(Lunar Lake、Ryzen AI 300)

• 40~50 TOPS。软件落后 Apple/Qualcomm;OpenVINO 在改善但仍小众。
• 最适合 Windows ARM 副驾驶应用;AMD/Intel 桌面上做本地优先。

WebGPU + WebLLM

• 经 WebGPU 计算着色器在浏览器跑模型;无需安装。
• Llama 3.1 8B Q4 在 M3 Max 上约 41 tok/s——经同一后端约为原生的 70~80%。
• WebLLM GitHub 17.6k 星;OpenAI 兼容 JS API;Apache 2.0。
• 2026 覆盖:Chrome Android v121+、Safari iOS 26 GA、Firefox Android 仍在追赶。整体约 70~75% 移动覆盖。

NVIDIA Jetson 家族

• Orin Nano Super(8GB):装得下 Llama 3.2 3B、Phi-3,tok/s 不错。
• AGX Orin:经 vLLM 跑 gpt-oss-20b 约 40 tok/s。
• Thor / T4000(JetPack 7.1):性能是 AGX Orin 的 2 倍,支持 EAGLE-3 与 NVFP4。
• TensorRT Edge-LLM(2026)支持 EAGLE-3 投机解码、NVFP4 权重、分块 prefill——数据中心优化移植到边缘。

按目标选量化

边缘上的长上下文陷阱

Llama 3.1 的 128K 上下文是数据中心特性。8 GB RAM 的手机上,4 GB 模型 + 32K token 的 2 GB KV 缓存 + 系统开销 = OOM。边缘部署把上下文压到 4K~8K,除非接受激进的 KV 量化(Q4 KV)。

语音是杀手级应用

语音 Agent 延迟敏感(首 token < 500 ms)。本地推理彻底消除网络延迟。配合语音转文字(Whisper Turbo 变体可在边缘跑),边缘推理就成了生产级语音回路。

你该记住的数字

• Apple M4 / A18 ANE:38 TOPS。
• Qualcomm Hexagon SD X Elite:45 TOPS。
• WebLLM M3 Max:Llama 3.1 8B Q4 约 41 tok/s。
• AGX Orin:gpt-oss-20b 经 vLLM 约 40 tok/s。
• 数据中心-边缘带宽鸿沟:30~50 倍。
• WebGPU 移动覆盖:约 70~75%(Firefox Android 落后)。

三、从零实现:带宽受限的 decode 天花板计算

原课程 code/main.py 跨边缘目标,从带宽受限算式算理论 decode 天花板,对比实测基准,标出哪是带宽瓶颈而非算力。下面给最小可读骨架。

def decode_ceiling(weight_gb, bandwidth_gbs):
    """带宽受限下的理论 decode tok/s 上限。

    参数:
      weight_gb:      需逐 token 读取的权重 GB(量化后)
      bandwidth_gbs:  内存带宽 GB/s
    返回: tok/s 上限
    """
    ms_per_token = (weight_gb / bandwidth_gbs) * 1000
    return round(1000 / ms_per_token, 1) if ms_per_token else float("inf")


# 案例:Llama 3.1 8B Q4 ≈ 3.5 GB,跨设备带宽
for label, bw in [("iPhone(50 GB/s)", 50), ("高端安卓(90 GB/s)", 90),
                  ("M3 Max(400 GB/s)", 400), ("HBM3(3000 GB/s)", 3000)]:
    print(f"{label}: 8B Q4 天花板 {decode_ceiling(3.5, bw)} tok/s")
# 这解释了为什么 iPhone 16 Pro 上 8B 只有 3 tok/s——带宽天花板 ~14,加上 NPU 访问开销
​

💡 在边缘上,「换更快的 NPU」往往不涨 tok/s——因为带宽才是天花板。提升量化档位(把 3.5 GB 压到 2 GB)比加算力更直接。

四、框架对比:四个边缘目标横向对照

心法:iOS → Core ML ANE;安卓/Windows ARM → QNN Hexagon;浏览器 → WebLLM;机器人/车载 → Jetson + TRT Edge-LLM。统一推理栈要靠 OpenAI 兼容 API 在应用层抹平差异。

五、可复用产物

本节产出 outputs/skill-edge-target-picker.md(原课程目录)。给定平台(iOS/安卓/浏览器/Jetson)、模型、延迟与内存预算,它选出量化格式与转换流水线:

1. 目标-格式映射:四平台各自的推荐格式与转换工具。
2. 内存预算:权重 + KV + 激活在目标设备 RAM 内的占用,判断是否 OOM。
3. 带宽天花板:目标设备带宽下的理论 tok/s,对比实测判断运行时效率。
4. 降级策略:低端设备回落到更小模型或服务器端同 API。

六、练习

1. 跑通计算器:运行 code/main.py。对骁龙 8 Gen 3(约 77 GB/s)上的 7B Q4,算 decode 天花板。对比实测 6~8 tok/s——运行时高效吗?

2. WebGPU 降级:Android 上 WebGPU 需要 Chrome v121+。为旧浏览器设计一个降级——服务器端经同一 OpenAI 兼容 API。

3. iOS 内存:你的 iOS 应用要 4K 上下文流式。哪个模型/格式组合能让你在 iPhone 16 上保持在 4 GB 活跃内存内?

4. 统一栈:AGX Orin 跑 gpt-oss-20b 在 40 tok/s,Nano 只装 3B。如果你的产品同时瞄准两者,如何统一推理栈?

5. 论证 WebLLM:论证「2026 年 WebLLM 是否生产就绪」。引用覆盖率、性能与 Firefox Android 缺口。

本节要点回顾

1. 边缘约束是带宽不是算力:移动 DRAM 5090 GB/s vs HBM3 23 TB/s,30~50 倍鸿沟,decode 内存受限故决定性。
2. 四个目标四套解:Apple ANE(38 TOPS,统一内存)、Hexagon(45 TOPS,QNN)、WebGPU/WebLLM(浏览器,70~80% 原生)、Jetson(Thor 2× AGX)。
3. WebGPU 覆盖约 70~75%:Chrome Android v121+、Safari iOS 26 GA,Firefox Android 仍追赶。
4. 量化按目标选:ANE 用 Core ML INT4+FP16,Hexagon 用 QNN INT8/INT4,WebGPU 用 MLC Q4,Jetson 用 GGUF/NVFP4。
5. 长上下文在边缘是陷阱:8 GB 手机装不下 128K 上下文,边缘压到 4K~8K 或激进 KV 量化。
6. 语音是杀手级:首 token <500 ms,本地推理消除网络延迟,配 Whisper Turbo 成生产语音回路。
7. TRT Edge-LLM 把数据中心优化搬上边缘:EAGLE-3、NVFP4、分块 prefill 在 Jetson Thor 上可用。
8. 统一栈靠 OpenAI 兼容 API:应用层抹平四平台差异,低端设备回落到服务器端同 API。

下一节,我们转向「看得见」的问题——LLM 可观测性:看如何用 Langfuse / Arize / Helicone 这类栈,把提示、响应、延迟、成本、质量一次性收进可查询的存储。