第 11 章 边缘与移动端推理
第 11 章 边缘与移动端推理
如果说第 10 章是"在 CPU 上跑 LLM"，这一章就是"在手机和笔记本上跑模型"。边缘端的世界规则完全不同：内存以 GB 计甚至 MB 计、没有 NVIDIA GPU、有电池和散热的硬约束。原书仓库 ch11/ 目录用三台参考设备 × 三种负载的系统实验，把边缘推理讲透了。
11.1 实验设计：三设备 × 三负载
ch11/README.md 把实验框架交代得很清楚：
三台参考设备：
- MacBook Air M3（Apple Silicon 笔记本）
- iPhone 16（手机）
- Pixel 10 Pro（Android 手机，Tensor G5 芯片）
三种负载（覆盖视觉 / 音频 / 语言三类任务）：
- EfficientNet-Lite0（视觉分类）
- Whisper-tiny encoder（音频）
- Llama-3.2-1B-Instruct（LLM）
四层执行环境（README 里的表格）：
| 层 | 运行环境 | 干什么 |
|---|---|---|
| Mac | M3 Mac，macOS 15+ | TFLite host bench、Core ML + MLX + MPS、prepost、画图 |
| Linux 容器 | Docker / Colab GPU | Llama → MediaPipe .task → LiteRT-LM .litertlm；Whisper → .tflite |
| Android 手机 | Pixel 10 Pro | TFLite + LiteRT-LM 实测，通过 AWS Device Farm 跑真机 |
| iPhone（手动） | iPhone 16 + Xcode | 用 Xcode 生成 .mlperfreport 性能报告 |
关键设计：所有测量结果都写进同一个 results.json，所有画图脚本只从 results.json 读数据、绝不在画图时重新测量（ch11_1_aggregate.py 是唯一的数据消费者）。这让整章的图表严格可复现——你在章节里看到的每个数字都能追溯到一次真实测量。
11.2 Android 侧：TFLite 与 LiteRT-LM
ch11_2_tflite.py 覆盖了 Android 上跑模型的两种方式：TFLite（经典）和 LiteRT-LM（新秀，前身叫 MediaPipe LLM Inference，专门在端侧跑 LLM）。
# 来自 ch11/ch11_2_tflite.py（核心模式）
def mode_convert(args): # 把 EfficientNet-Lite0 转成 TFLite
def mode_inspect(args): # 检查 TFLite 模型的算子、输入输出
def mode_verify_accuracy(args):# 验证量化前后精度
def mode_bench_host(args): # 在 Mac 上先跑一轮 host 基准几个关键工程点：
- 转换在哪做：EfficientNet-Lite0 的 TFLite 转换在 Mac 上就能做；但 Llama 的 LiteRT-LM 打包和 Whisper 的 TFLite 转换必须在 Linux 容器里做——因为相关依赖（TF nightly 等）在 macOS arm64 上装不干净。这是真实的工具链限制，不是随便分的。
- LiteRT-LM 流水线：Llama-3.2-1B 先量化，再转成 MediaPipe 的
.task，最后打包成 LiteRT-LM 的.litertlm格式。这个格式是端侧 LLM 推理（完全本地、离线、隐私安全）的载体。 - 真机验证：
ch11_4_android.py的mode_ingest会把手机（通过 AWS Device Farm 上的 Pixel 10 Pro）跑出来的基准数据收回来，统一进results.json。AWS Device Farm 让你不用真机也能跑真机基准。
11.3 Apple 侧：Core ML、MLX、MPS
ch11_3_apple.py 是 Apple 生态的大满贯，三种推理后端：
# 来自 ch11/ch11_3_apple.py（核心模式）
def mode_convert_coreml_vision(args): # EfficientNet-Lite0 → Core ML (.mlpackage)
def mode_convert_coreml_whisper(args): # Whisper → Core ML
def mode_convert_coreml_llm(args): # Llama-3.2-1B → Core ML
def mode_convert_mlx_llm(args): # Llama → MLX（Apple 的机器学习框架）三种后端的分工：
- Core ML：Apple 的官方推理引擎，能调度到 ANE（Apple Neural Engine，神经引擎）、GPU、CPU 三个计算单元，还能用
MLComputePlan查看每个算子实际落在哪个单元（_compute_plan_coverage会解析它）。 - MLX：Apple 的开源机器学习框架，更接近 PyTorch 的编程模型，对 LLM 友好，在 Apple Silicon 上跑 LLM 的社区事实标准。
- MPS：Metal Performance Shaders，直接调 GPU 的低层 API。
iPhone 上怎么测性能（ch11_3_iphone_steps.md）：用 Xcode 的 Core ML Performance 测试生成 .mlperfreport 报告，再把报告喂回 ch11_3_apple.py 的 ingest 逻辑，进 results.json。这是"端侧性能报告"的标准工作流。
这一节还演示了**算子放置（op placement）**的概念：同一个 Core ML 模型，哪些算子跑 ANE、哪些跑 GPU、哪些掉回 CPU，决定了真实性能。ANE 快但支持的算子集有限，算子落不下去就会掉回 CPU——所以"模型能转成功"不等于"模型跑得快"，必须检查放置情况。
11.4 前后处理：被低估的延迟大头
ch11_5_prepost.py 测量的是前处理（pre-processing）和后处理（post-processing）的开销——这是整个边缘推理里最容易翻车的地方，因为大家都只看"推理时间"。
# 来自 ch11/ch11_5_prepost.py（核心模式）
def mode_bench_vision_prepost(args): # 视觉：解码 → resize → normalize → 推理 → argmax
def mode_bench_audio_prepost(args): # 音频：解码 → 重采样 → 分帧 → 推理 → ...
def mode_bench_llm_prepost(args): # LLM：tokenize → 推理 → detokenize
def mode_bench_end_to_end(args): # 端到端：全部环节一起测核心发现（第 12 章会再次验证并放大）：
推理本身在边缘端可以很快，前后处理才是延迟大户。 例如 EfficientNet-Lite0 在 M3 上推理只要几毫秒，但图片解码 + resize + normalize 可能就要几十毫秒——端到端延迟的预算被前后处理吃掉。音频更夸张：Whisper 的音频解码、重采样、分帧的开销可能远超编码器推理本身。
mode_bench_end_to_end 把整个管线串起来测，得到真实的端到端 p95 延迟。这一节的工程结论：优化边缘推理，先测前后处理——很多时候不用碰模型，把图像解码换成硬件加速、把 resize 用对库、把 tokenize 缓存起来，延迟就下来了。
11.5 聚合视角：跨设备、跨负载的设计空间
ch11_1_aggregate.py 把三个脚本的所有测量结果聚合成跨设备、跨后端、跨负载的设计空间图：
# 来自 ch11/ch11_1_aggregate.py（核心）
def mode_summary(args): # 汇总所有结果
def mode_design_space(args): # 画设计空间图：x=延迟, y=能耗, 点=设备×后端×负载你会在图上看到：同一个 EfficientNet-Lite0，在 iPhone 上 Core ML 跑和 Pixel 上 TFLite 跑、在 M3 上 MLX 跑，延迟和能耗的分布完全不同。"最好的方案"没有普适答案——它取决于你的设备、负载、以及你更在乎延迟还是能耗。
_draw_null_power_strip 甚至画了"空载能耗基线"——连什么都不跑时设备的底噪功耗，用来把模型的真实增量能耗从底噪里剥出来。这种严谨的测量方法值得所有做性能优化的工程师学习。
11.6 本章小结
- 三设备三负载：MacBook Air M3 / iPhone 16 / Pixel 10 Pro × EfficientNet-Lite0 / Whisper-tiny / Llama-3.2-1B。
- Android：TFLite 经典方案 + LiteRT-LM 端侧 LLM 新秀，转换依赖在 Linux 容器里解决，真机用 AWS Device Farm。
- Apple：Core ML（ANE/GPU/CPU + MLComputePlan 检查放置）、MLX（LLM 友好）、MPS；iPhone 用 Xcode 出性能报告。
- 前后处理是隐藏瓶颈：推理可能只有几毫秒，解码/resize/tokenize 才是延迟大户，先测它们。
- 测量方法论：所有数字进
results.json，画图只读数据，空载能耗要单独测。
下一章是全书收官——把第 7 章的 4bit 权重、第 11 章的端侧管线、第 9 章的部署栈、可观测性全部组合起来，交付一个生产级的 4bit LLM 服务器和一个端侧视觉管线。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。