端侧 LLM 产品化

学习目标

本章关键词

承上：回顾与定位

前十四天已从神经网络基础走到 LLM 结构、运行时、量化、框架和跨尺度性能。本章把全部知识压回一个真实产品：谁有执行权、每个字节和每焦耳花在哪里、失败时如何保持安全、版本如何发布与回滚。

本章讲解

从验收指标反推系统边界

先写产品必须满足的事件、端到端时延、离线时长、误报漏报、安全状态、功耗和成本，再决定模型放在 MCU、Edge Host 或云。若断网后仍须毫秒级停机，判断与执行就不能依赖主机 LLM；若任务需要大上下文，可把解释放主机，但设备保留阈值规则。每项需求都映射到一个责任组件和可测信号，避免架构图只有箭头没有承诺。

把 Host 消息定义为提案而非指令

消息应使用有版本的结构化 schema，包含 device_id、request_id、sequence、deadline、action、typed params 和认证信息。ESP32 收到后验证来源、版本、去重、时效、动作白名单、参数范围与当前状态，全部通过才转成内部事件。自然语言永远不直接驱动 GPIO。对重复帧、乱序、重放、半包和未知字段做协议测试，并让拒绝原因可审计。

正常路径与降级路径必须共享状态机

为在线、主机慢、链路断、模型失败、传感器异常和执行器故障定义显式状态与转换；不要在异常回调里临时拼补动作。超时后取消主机请求并丢弃迟到回复，设备切回本地阈值或安全保持模式；重连需重新握手和同步序号。通过断网、重启、包丢失、Host 满载与 watchdog 复位做故障注入，确认每条路径都能回到已知状态。

端侧芯片是异构内存系统，不是一串 TOPS

CPU 负责控制流、tokenizer、采样与不被 delegate 支持的算子；GPU 适合规则的大规模并行，但命令提交、shader 编译、buffer 转换和共享资源争用会进入延迟；DSP/NPU 在受支持的 dtype、shape 与图模式上能以较低能耗运行，却可能要求静态维度、特定量化或厂商编译器。统一内存减少显式 PCIe 复制，不等于数据免费移动：缓存一致性、页面迁移、带宽争用和布局转换仍消耗时间与能量。宣称的 TOPS 通常是特定低精度算术峰值，既不包括 tokenizer、KV 管理和 sampling，也不说明模型有多少算子 fallback 到 CPU。应从 runtime trace 查每个子图落在哪个 backend、边界复制多少字节、首次编译多长、并发 UI/相机是否抢资源，再解释端到端 TTFT 与 ITL。

模型文件只是交付契约的一部分

GGUF 把张量、量化类型和推理元数据打包，适合 llama.cpp 的低依赖多后端生态；ExecuTorch 把 PyTorch 模型 AOT 导出为 .pte，并通过 partitioner/delegate 把子图交给目标后端；MLC LLM 从模型表示经编译器生成平台代码与参数；LiteRT-LM 在 LiteRT 之上组合 tokenizer、解码器与跨平台 API；MNN-LLM 把移动 runtime、多 backend 与应用集成连接起来。格式名不能保证语义相同：tokenizer 文件、chat template、RoPE 参数、special token、量化尺度、KV dtype 和采样默认值都属于模型包契约。发布时要记录原 checkpoint、转换工具 commit、命令、hash、license、支持的 context 与验证 prompt；加载前验证 schema 和兼容矩阵，避免 runtime 静默采用错误默认值。模型可加载只证明字节能解析，不证明输出、速度或权限符合产品要求。

把 lowering、分区与 fallback 当作可观测编译过程

端侧部署通常先捕获或导出计算图，再规范化算子、融合 pattern、插入量化/反量化，最后由 partitioner 将支持的子图交给 CPU、GPU、NPU delegate。边界两侧可能需要 layout、dtype 或内存域转换；一个孤立的不支持算子会把图切碎，导致多次同步与复制，甚至让“启用 NPU”比纯 CPU 更慢。正确做法是保存编译报告：哪些节点被委派、哪些 fallback、每个子图的输入契约、workspace 和首次编译缓存。对动态序列长度，可使用 shape bucket、chunked prefill 或专用 decode 图，但要验证边界值。若 delegate 失败，fallback 必须是受测路径而非“理论上能跑”；它需要容量上限、超时、日志和可恢复的模型版本。编译器日志、runtime trace 和系统功耗采样必须用同一 request id 对齐。

以质量、体验、能量、温度和可恢复性共同验收

端侧 benchmark 必须固定 checkpoint、量化、prompt 集、backend、线程、功耗模式、环境温度和软件版本。分别报告加载冷启动与缓存暖启动、Prefill tokens/s 与 TTFT、Decode tokens/s 与 ITL、峰值 RSS、J/token 或平均功率、设备温度与持续运行后的频率变化；生成速度还要与任务质量、格式遵循和拒答策略一起看。观测数据带模型 hash、delegate 分区摘要与 trace id，便于在设备群中比较版本。发布采用签名模型包、兼容矩阵、灰度比例、健康门槛与回滚；离线、delegate 初始化失败、温度过高、内存不足和云回退超时都要演练。最终交付不是某台凉爽样机的一次最高 tokens/s，而是目标设备分布在真实热状态、网络和前台负载下仍满足体验与安全边界的证据。

代码或命令示例

proposal = edge_llm(request)
validated = policy_and_schema_check(proposal)
if validated:
    mcu_execute(validated)
else:
    enter_safe_degraded_state()
record(version_set, latency, energy, thermal, failures)

动手实验

工程陷阱

延伸阅读

• llama.cpp server（官方/原始资料）
• llama.cpp / GGUF 官方仓库（官方/原始资料）
• ExecuTorch LLM 官方部署文档（官方/原始资料）

启下：下一章如何使用本章能力

15 天路线已经完成。下一次项目从目标设备和真实工作负载开始：先写安全与验收边界，再选择模型与 runtime，并让每次优化都留下可复现证据。