直接回答
端侧 AI 电量基准测试应从准确的工作负载和声明测量来源开始，而不是从状态栏抄一个电量百分比下降值。固定模型制品、运行时、后端证据、输入夹具、任务序列、应用构建和执行时长。记录设备型号、系统、电池及充电状态、屏幕条件、网络状态、热环境及其他影响复现的条件。使用同一配置先跑空闲或基线时段，再执行固定 AI 工作负载；所有运行都应保留，包括失败或中断记录。没有原始数据时，只能发布方法，不能发布电池寿命数字、设备排名或“单次充电可用几小时”的承诺。 Android Studio Power Profiler 可以通过 ODPM 等设备仪器显示可测电源轨的功耗，官方文档也说明应将系统轨迹与应用操作关联起来。关键限制是：ODPM 读数属于设备级，而非特定应用级，并且各硬件可用的电源轨不同。文档还限定了特定设备与系统环境的可用条件；不能假设所有 Android 手机都有同一传感器，也不能把缺失的电源轨读成零功耗。电量百分比、剩余电量和瞬时电流，也不是某个应用任务消耗的能量本身。 热状态会改变设备能持续承受的工作负载。Android Thermal API 资料说明，温度状态和热节流可能随时间影响性能，并提供应用观察系统条件的信号。因此，测试协议应把可获得的热状态或 headroom 与任务进度一起加上时间戳记录。不要强行读取设备不支持的传感器，也不要超出文档指导频率轮询。短时测量与重复持续负载应分开：一次成功推理无法证明长期电量影响、热稳定性或性能一致性。 比较前要控制混杂因素：保持任务、等待时间、屏幕亮度和前后台状态一致，固定充电策略，即使模型推理本身在本地运行，也要记录网络设置。不能把不同制品、提示长度、图片尺寸或语音时长当作同一负载比较。如果系统级功耗同时包含其他应用和无线电，就必须如实标注信号范围，不能将完整轨迹都归因于模型推理。条件允许时，应在受控环境重复多轮实验，保留全部试验和波动范围，而不是挑最有利的一条记录。 项目结果政策要求主张记录设备、芯片、系统、制品、运行时、后端、输入、计时、内存、热状态和失败结果。本文提供实验设计，不证明 Cove 当前的电池消耗。有效结论应是一条可复现的轨迹，说明测量了什么、功耗工具无法归因什么、结果如何变化，而不是通用百分比或续航承诺。 电量基准还需要预先界定比较目标。若比较运行时版本，应保持其他条件不变；若比较输入长度，就不能同时更换模型和测试场景。空闲基线有助于说明测试窗口内设备本来就在做什么，但并不能简单地从总读数中减去一个固定值后就得到精确的应用能耗。报告要保留测量工具、读取间隔、异常环境、热事件和失败退出时间。测量能力不足时，最诚实的产出是指出无法归因或无法比较，并设计下一次更受控的实验。 面向产品的解释应避免把一次实验变成用户续航承诺。说明被测配置、任务重复次数、设备级功耗限制和热状态观测范围。若只测到某些系统轨迹，而没有应用能量归因能力，就只描述观测到的轨迹，不换算成“每次任务耗电百分比”。这些边界并不会让实验失去价值：它们帮助团队找到变化发生的时间段，并决定是否需要更适合的仪表和更多复测数据。
团队想比较两个推理改动的电量影响
开发构建中，长时间 AI 会话结束后的电量百分比与之前不同，但设备先前连接过充电器，且后台还有其他应用运行。团队需要比较两个版本，又不能把系统级功耗轨迹误写成应用级能耗。
决策
固定一项工作负载，注明功耗工具与归因限制，统一设备状态，并采集包含热状态和失败上下文的多轮原始轨迹。
预期结果
报告能描述实际测量来源和波动，不会把无线电或后台应用负载归因给模型推理。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- BENCHMARK-01：发布结果需原始设备、制品、运行时、输入、计时、内存、热状态和失败记录。
- THERMAL-01：一次成功推理不能证明持续性能；需重复固定工作负载并记录可用热信号和失败。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 锁定工作负载和构建身份. 记录应用构建、模型制品和量化方式、运行时版本、后端请求/观察、提示或输入夹具、任务序列和测量时段。除非某个变量就是要比较的对象，否则不同版本需保持这些条件一致。
- 稳定设备状态. 记录设备和系统、电池状态、充电或断开条件、屏幕/亮度策略、网络状态、测试环境和运行前等待规则。还要注明可能影响系统功耗的其他前后台任务。
- 选择并命名仪器来源. 选择可用的分析器或仪表，并写清测量的是设备电源轨、充电计数器、电流还是其他量。先确认设备是否暴露该电源轨；设备级轨迹要按设备级标记，不能归算成应用独占耗电。
- 把功耗轨迹与热状态和任务轨迹配对. 记录任务开始、完成、暂停、错误以及可获得热信号的时间戳。重复相同工作负载并保留每轮结果。不能从一次短运行或一个电量百分比差值推断可持续运行或续航。
- 分析波动并披露限制. 比较匹配条件下的运行；适用时加入空闲基线；报告测量来源和所有排除项，并说明工具无法归因的部分。原始值缺失或条件不一致时，发布方法与局限，不填写推测数字。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每个对比运行都有固定的制品/运行时/负载身份，并记录测量时段与测量来源。
- 记录设备条件和热状态；缺失传感器或不支持的电源轨标记不可用，而不是零。
- 报告区分设备级测量与应用级能量归因，不把电量百分比直接等同单任务能耗。
- 保留所有重复轮次和失败，不在缺少原始证据时声称通用续航、耗电比例或设备排名。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 运行前后电量百分比 | 用户可见的粗粒度状态变化 | 容易观察，但受时长、电量计量和其他系统任务影响，不适合作为单任务能耗证据。 |
| Power Profiler/电源轨迹 | 将仪器化系统信号与任务时间关联 | 可提供更丰富的时间上下文；ODPM 仍是设备级读数且轨道支持因设备而异。 |
| 匹配条件的重复实验 | 固定负载、控制条件、热上下文并保留全部记录 | 适合比较有限范围的改动，但仍受测量归因能力和设备样本限制。 |
需要避免的失败模式
- 把状态栏电量百分比变化直接当成一次推理的应用级耗电量。
- 忽略 Power Profiler 读数是设备级信号，或将缺失电源轨解释为零。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
能否把电量百分比下降归因到一次推理任务？
不能只凭百分比判断。电量百分比是粗粒度设备状态，其他应用、无线电、屏幕与充电情况都会影响它。要说明测量来源，并用受控的重复轨迹后再讨论归因。
Android Power Profiler 只测我的应用功耗吗？
不是。ODPM 电源轨是设备级信号，可以和应用操作关联；可用轨道会因设备不同。报告应说明信号及归因限制，不能把完整轨迹都算到推理上。
一次成功推理能证明持续耗电可接受吗？
不能。持续行为需要重复固定工作负载，并记录热状态和失败信息。单次任务无法说明长时间运行、热节流或整体电量影响。