端侧 LLM 推理横评
展开自 challenges.md 第 10 项：端侧 LLM 推理的内存墙与 KV-Cache 管理 MNN-LLM 相关见 精读: mnn ncnn 无 LLM 支持见 精读: ncnn
调研元信息
| 项 | 值 |
|---|---|
| 日期 | 2026-06-22 |
| 环境 | macOS / Apple Silicon |
| 实测状态 | 未实测，以公开文档和源码为准 |
| 流水线段 | Deploy/Run（LLM 推理专项） |
一句话定位
端侧 LLM 推理是 2024-2026 年最热的移动 AI 方向，与传统 CV 推理有根本差异（有状态 vs 无状态），本文横评 4 个主要方案。
日常类比
CV 推理像「一次性翻译一句话」——输入图片、输出结果、完事。LLM 推理像「持续对话」——需要记住上下文（KV-Cache），每说一句话都要翻阅之前的对话记录，手机内存就是你的记忆容量上限。
CV 推理 vs LLM 推理：根本差异
| 维度 | CV 推理（检测/分类） | LLM 推理（文本生成） |
|---|---|---|
| 状态 | 无状态（每帧独立） | 有状态（KV-Cache 累积） |
| 内存模式 | 峰值固定，可预测 | 随生成长度线性增长 |
| 计算模式 | 单次前向 | Prefill + 逐 token Decode |
| 瓶颈 | 计算（FLOPS） | 内存带宽（memory-bound） |
| 延迟敏感 | 帧率（30fps 目标） | 首 token 延迟 + 每 token 延迟 |
| 模型大小 | 5-50MB（典型 YOLO） | 1-7GB（典型 7B 模型 INT4） |
端侧 LLM 方案横评
| 方案 | 维护方 | 语言 | 支持模型 | 量化 | 平台 |
|---|---|---|---|---|---|
| MNN-LLM | 阿里巴巴 | C++ | Qwen/LLaMA/GLM 等 | INT4/INT8 | iOS/Android/Mac |
| llama.cpp | 社区 (ggerganov) | C/C++ | LLaMA 系列为主 | GGUF 多种量化 | 全平台 |
| MediaPipe LLM | C++ | Gemma/Gemini Nano | INT4/INT8 | Android/iOS/Web | |
| MLX | Apple | Python/C++ | 全系列（Apple 专属） | INT4/INT8 | 仅 Apple Silicon |
MNN-LLM [已有]
MNN 六个框架中唯一内建 LLM 推理能力：
- 集成在 MNN 框架中，共享 Geometry Compiler 优化
- 支持 KV-Cache 管理 + 流式输出
- 分词器（Tokenizer）内建
- 与 CV 推理共用一个运行时（无需额外依赖）
- 劣势：社区不如 llama.cpp 活跃，模型支持列表更新较慢
llama.cpp
端侧 LLM 推理的社区标杆：
- GGUF 格式：灵活的混合量化（每层可不同量化位数）
- Metal 优化（Apple）、Vulkan 优化（Android/Windows）
- 活跃社区：新模型支持通常最快
- 劣势：独立运行时，不能与 CV 推理共享引擎；安装体积较大
MediaPipe LLM
Google 官方方案：
- 集成在 MediaPipe 生态中
- Gemini Nano 的唯一官方端侧方案
- 与 Android 系统级集成（AICore API）
- 劣势：模型选择受限，主要服务 Google 生态
MLX
Apple 专属：
- 利用 Apple Silicon 统一内存架构（CPU/GPU 零拷贝）
- Python 接口友好，研究用途为主
- 劣势：仅 Apple 设备，非移动端（Mac 为主）
端侧 LLM 核心挑战 [已有]
展开 challenges.md 第 10 项：
内存墙
7B 模型 FP16 需约 14GB 内存，INT4 量化后约 3.5GB。典型手机可用内存 4-6GB（需预留系统和 App），因此：
- 7B INT4 是当前手机可运行的实际上限
- 3B 及以下模型更适合端侧
- KV-Cache 随序列长度线性增长，2K 上下文约需额外 200-500MB
KV-Cache 管理策略
| 策略 | 思路 | trade-off |
|---|---|---|
| 固定长度窗口 | 只保留最近 N 个 token 的 KV | 简单但丢失远距离上下文 |
| PagedAttention（端侧简化版） | 分页管理，按需分配/释放 | 内存效率高但实现复杂 |
| 量化 KV-Cache | 对 KV 做 INT8 压缩 | 降内存但影响注意力精度 |
| 稀疏 Attention | 只关注关键 token | 降计算但需判断「关键性」 |
Prefill vs Decode 双阶段
| 阶段 | 计算特征 | 瓶颈 | 优化方向 |
|---|---|---|---|
| Prefill（首次处理全部输入） | 计算密集 | FLOPS | 批量矩阵乘、GPU 加速 |
| Decode（逐 token 生成） | 内存带宽密集 | 带宽 | KV-Cache 读取优化 |
与 ncnn 的关系
ncnn 目前不支持 LLM 推理 [已有]，原因：
- 无状态设计：ncnn 的 Lazy Eval + Light Mode（中间 blob 即释放）与 LLM 的「持续保留 KV-Cache」设计冲突
- 无内建 Tokenizer/Sampler
- 社区有实验性尝试（见 issue #6576 paged attention request）但未合入主线
如果犀牛鸟想在 ncnn 做 LLM 方向，这是高风险高回报的前沿贡献——但短期内 MNN-LLM 或 llama.cpp 是更务实的选择。
证据等级
| 标签 | 来源 |
|---|---|
| [已有] | challenges.md #10, deep-dive-mnn.md (MNN-LLM 段落) |
| [文档] | llama.cpp README, MNN-LLM docs, MediaPipe LLM docs |
| [Issue] | ncnn #6576 (paged attention request) |
| [源码] | MNN source/llm/, llama.cpp (public repo) |