端侧部署要权衡精度、显存和延迟

把大模型放到手机、笔记本、车机和边缘盒子上，问题的性质就变了。云端推理可以靠堆 GPU、扩 batch、做弹性扩容来吸收波动；端侧只有一张固定的预算表：可用内存、可用算力、可用电量、可接受的首 token 延迟。量化、蒸馏和调度是这张表上最常被同时动用的三个杠杆，但它们并不是可以随意叠加的优化项，而是三种彼此牵制的取舍。

量化回答“用多少位表示权重和激活”，蒸馏回答“用多小的模型承载多少能力”，调度回答“在给定硬件上如何把一次请求切分、排布和回收”。三者共同决定端侧体验，任何一项单独调优都可能被另外两项抵消。

输入侧。端侧输入的第一道约束是上下文长度与内存的乘积关系。KV Cache 随序列长度线性增长，长上下文在端侧往往比权重更早触发 OOM。工程上常见做法是限制最大上下文、对历史做摘要压缩、把系统提示词做成可复用的前缀缓存。分词器也值得注意：多语言或代码场景下 token 效率差异会直接放大序列长度，同等字数下 token 数可能相差三成以上。输入侧还应做长度预检和截断策略，避免超长请求进入推理队列后才发现放不下。

推理/执行侧。量化分两条线：权重量化（如 4bit、8bit 分组量化）主要省显存和带宽，激活量化则进一步省算力，但对异常值敏感，往往需要保留部分高精度通道。实践中 4bit 权重量化在多数对话任务上损失可控，但数学、代码和结构化抽取任务对量化更敏感，需要单独评测。蒸馏分 logit 蒸馏与序列蒸馏：前者依赖教师模型的分布输出，迁移效率高但需要教师接口；后者只用教师生成的文本，工程简单但信息量少。端侧更现实的是“蒸馏出结构 + 量化压缩”的组合，先得到一个参数更少、层数更浅的骨架，再对其做低比特量化。调度层面要区分预填充与解码两个阶段：预填充是算力密集型，解码是访存密集型，端侧常采用分块预填充避免瞬时内存峰值，用连续批处理提升吞吐，用优先级队列保障交互请求的首 token 延迟。

输出/评测侧。端侧评测不能只看困惑度或通用榜单。应分三层：任务层看准确率与格式合规率；系统层看首 token 延迟、每 token 延迟、峰值内存、能耗与温升；体验层看长尾输入下的失败模式。特别要单独统计量化后出现退化的一类样本，例如长数字、罕见实体、多步推理和否定句。评测应在目标真机上跑，模拟器上的内存与热行为往往过于乐观。