大模型往端侧走已经不是概念了：手机助手离线问答、PC 本地文档总结、代码补全，这些场景都在把推理搬到用户手边的 NPU 上。但把云端跑得好好的模型塞进端侧，处处是坑。这篇聊聊工程上的关键点。

## 端侧 NPU 的算力特点

端侧 NPU 和云端 GPU 的设计哲学不同：

- **算力有限但能效优先**：手机 SoC 的 NPU 算力通常在几十 TOPS 量级（以各厂商公开的标称值为准），远小于数据中心 GPU，但每瓦性能是强项。
- **内存是紧箍咒**：端侧没有 HBM，统一内存架构下 NPU 和 CPU/GPU 共享内存带宽，大模型推理最容易卡在"把权重喂给计算单元"的速度上，而不是计算单元本身。
- **算子支持有边界**：NPU 对主流算子支持较好，碰到模型里的" exotic 算子"就可能回退到 CPU 跑，性能断崖式下跌。选模型架构时就要考虑目标 NPU 的算子覆盖。

## 优化三板斧

**模型量化**：把 FP16/BF16 权重量化到 INT8 甚至 INT4，是端侧部署的第一步。权重量化主要省内存占用和带宽，激活量化还要考虑精度损失。实践中常用"权重量化 + 激活 FP16"的混合策略，再配合校准数据集把精度损失控制在可接受范围。

**算子适配**：模型里不被 NPU 原生支持的算子，要么替换为等价的原生算子组合，要么接受 CPU 回退。上线前一定要在真机上跑一遍算子覆盖率检查，模拟器上"能跑"不等于真机上"跑得快"。

**内存带宽优化**：decode 阶段是典型的访存密集型，KV Cache 的管理直接决定长文本生成的速度。PagedAttention 这类技术把 KV Cache 做成按需分页，能显著降低内存碎片和峰值占用，在端侧同样适用。

## 与云端协同的取舍

不是所有推理都适合端侧。一个实用的划分原则：

- **放端侧**：对延迟敏感、隐私敏感、弱网可用的场景，如输入法联想、本地文档问答、实时字幕。
- **放云端**：需要大参数模型、复杂推理、联网检索的场景，如深度研究、代码大工程生成。
- **混合**：端侧做意图识别和简单回答，搞不定再上云，兼顾体验和成本。

混合架构下，端云切换的策略本身就是产品体验的一部分：切换时的延迟、回答风格的一致性，都需要精心设计。

## 工程 checklist

1. 先定目标：在什么设备、多少内存预算、多大延迟内跑什么规模的模型。
2. 真机实测一切：算子覆盖、首 token 延迟、 sustained 生成速度、发热降频后的表现。
3. 发热是隐形杀手：跑分 10 秒和连续对话 10 分钟完全是两回事，测试要覆盖温控降频。
4. 模型更新机制：端侧模型也要能 OTA，量化版本和云端版本保持对应。

端侧大模型拼的不是参数规模，而是"在有限预算里把体验做顺"的工程能力。