端侧模型生成一句简短回复的时候，整体功耗天然拆成 Prefill（提示词处理）和 Decode（逐 Token 生成）两个阶段，两段功耗特征完全不一样，Prefill 属于计算密集型、瞬时功耗高但持续时间短，Decode 是带宽瓶颈、平均功耗更低但会持续循环直到输出结束，统计一句话回复总功耗时，要分开采集两段的功率曲线、时长再分别算能耗，而不是只拿一个平均功耗乘总时间，很多手机、嵌入式 NPU 的功耗管控、温控策略也是基于这两段分开调度，甚至可以分配到不同硬件单元跑，降低峰值发热，避免一句话推理直接触发降频。一句话回复的 Token 数量不多，很容易误以为功耗是均匀的，实际上 Prefill 一次性把用户输入全部并行算完、产出 KV 缓存，Decode 拿着这个缓存逐个吐出回复文字，两段算力模型、访存模式不同，功耗、能效差异很大，分开统计才能拿到真实的功耗指标，方便做端侧唤醒、对话、离线交互的功耗预算。
一、两段基础定义与功耗特点清单
- Prefill 段（第一段：输入提示词编码）
- 任务：一次性并行处理用户输入的所有 Prompt Token
- 计算特征：矩阵乘矩阵，计算密集
- 功耗特点：瞬时峰值功率高，持续时间短
- 产出：KV 缓存，给 Decode 复用
- Decode 段（第二段：生成回复 Token）
- 任务：自回归循环，一次只生成 1 个输出 Token，循环到结束
- 计算特征：矩阵乘向量，访存密集，反复读取权重和 KV 缓存
- 功耗特点：单 Token 功耗偏低，但随输出长度累加总能耗占大头
- 结束条件：输出结束符 EOS 或者达到预设 Token 上限
二、一句话回复功耗拆分测算步骤
- 打点标记分界点：推理框架埋时间戳，输入全部处理完成、KV 缓存就绪的时刻就是 Prefill 和 Decode 的分割点。
- 分段采集功率：使用 NPU/SoC 功耗采样工具，分别记录 Prefill 窗口、Decode 窗口的功率时序。
- 分段计算能耗：能耗 = 平均功率 × 该阶段持续时长，总能耗 = Prefill 能耗 + Decode 能耗。
- 指标输出：分别输出峰值功耗、平均功耗、每段时长、每段能耗占比。
- 硬件调度优化：Prefill 可交给算力单元短时爆发，Decode 做带宽节流、降频控温。
三、两段关键指标对比表
| 阶段 | 瓶颈类型 | 功耗特征 | 能耗占比（短句回复） | 硬件调度思路 |
|---|---|---|---|---|
| Prefill | 算力 / 计算瓶颈 | 尖峰高功率、短时间 | 偏低，一般 20%~40% | 短时拉高 NPU 频率，做完立刻降频 |
| Decode | 内存带宽瓶颈 | 平稳中等功率、持续循环 | 偏高，一般 60%~80% | 限制访存、固定低档位频率，防止持续发热 |
四、常见工程落地方式
- 同硬件串行跑：同一个 NPU 先跑完 Prefill，再切到 Decode 循环，框架内部自动切阶段打点统计功耗，最通用。
- 异构分流拆分：Prefill 丢给算力引擎（ANE、NPU），Decode 在另一个单元，错开峰值功耗，苹果 MLX、部分骁龙 NPU 支持该模式。
- 功耗预算隔离：给两段设置独立功耗墙，Prefill 允许短脉冲超功耗阈值，Decode 严格限制持续功耗，适配电池设备。
【相关 FAQ】
问题 1：端侧模型一句话回复功耗按 Prefill、Decode 两段拆分方案，一句话很短还有必要拆分两段统计功耗吗？
回答 1：端侧模型一句话回复功耗按 Prefill、Decode 两段拆分方案，就算只生成一句话也建议拆分，因为 Prefill 峰值功耗很高，虽然时间短，但会影响瞬间发热、电压压降，Decode 持续耗电决定电池续航，合并平均会掩盖峰值风险。
问题 2：端侧模型一句话回复功耗按 Prefill、Decode 两段拆分方案，两段之间的 KV 缓存会不会带来额外功耗？
回答 2：端侧模型一句话回复功耗按 Prefill、Decode 两段拆分方案，KV 缓存读写属于 Decode 阶段的访存开销，统计时归入 Decode 功耗；Prefill 阶段只包含生成 KV 缓存的计算功耗，缓存本身占用内存，会增加 Decode 阶段带宽功耗。
问题 3：端侧模型一句话回复功耗按 Prefill、Decode 两段拆分方案，能不能只优化其中一段降低一句话回复功耗？
回答 3：端侧模型一句话回复功耗按 Prefill、Decode 两段拆分方案，两段优化方向不一样，Prefill 优先优化并行算子、压缩输入长度压峰值，Decode 优先优化 KV 缓存复用、量化、带宽调度降低持续能耗，短句场景 Decode 通常是优化重点。
【参考资料】
[2026-07-09]（Seeing is Free, Speaking is Not: Uncovering the True Energy Bottleneck in Edge VLM Inference）arXiv
[2026-03-26]（LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs）arXiv
[2026-08-27]（ANE Batch Prefill for On-Device Parallel LLM Inference）atomgradient
[2025-12-12]（PD-Swap: Prefill–Decode Logic Swapping for End-to-End LLM Inference）arXiv
【免责声明】
本文关于端侧模型一句话回复功耗按 Prefill、Decode 两段拆分方案的数据、占比区间来自公开学术论文的测试场景，不同芯片、模型量化版本、上下文长度、推理框架的结果会有明显差异；本文不代表芯片选型、低功耗方案定型依据，正式功耗测试请在目标硬件上使用原厂功耗采集工具实测。