直接回答
Baseline Profile 与 Macrobenchmark 面向应用代码路径和用户可感知旅程；它们不会直接证明模型制品兼容，也不自动证明推理更快。Android 官方建议使用 Macrobenchmark 测试应用启动和 UI 操作等较大流程，并通过 Baseline Profile 生成识别适合预编译的代码路径。对于本地 AI 应用，目标旅程可能是进入功能页、显示模型状态或展示结果。runtime 自身的加载与推理边界必须在测试记录中分别标明。 先用用户语言写出完整流程。例如，“打开笔记功能、查看 runtime 是否就绪、提交一个固定本地任务并显示合格结果”包含应用启动、界面导航、模型就绪、推理和结果呈现。先确定 profile 测试要观察其中哪一段。如果只想验证导航，就用不触发推理的夹具或状态，并明确记录这一点。如果包含模型加载，应把它记录为单独阶段，而不是将整段用户旅程归功于 profile。 保持构建变体的说明准确。Android Macrobenchmark 指南要求目标尽量接近 release，并区分 benchmark 测试模块和被测应用。记录应用变体、profile 状态、编译模式、runtime 构建、模型制品身份、设备和测试修订。不能将可调试开发构建与优化 release 版直接对比后称为纯 profile 效果。也不能仅因生成任务成功就假设 profile 已安装；应确认 release 包含情况和 benchmark 运行条件。 每轮前要把起始状态控制一致。旅程需从确定界面和声明好的模型状态开始。如果任务不属于测量范围，预置条件必须在每轮相同，并从计时段之外排除。如果推理属于测量场景，固定输入并定义哪个输出事件表示完成。还要确认一个变体不会意外包含网络下载、文件校验、冷引擎初始化或模型预热，而另一个变体没有。这些路径可以测试，但回答的问题不同。 除了结果数值，还要查看 trace 和结果文件。Macrobenchmark 可以输出结构化结果及追踪；按测试修订与构建身份保存。确认耗时属于启动、组合、导航、主线程阻塞、模型初始化还是推理。profile 可能改变被纳入的代码执行方式，但不能修复缺库、无效模型、不支持操作或隐私问题。结论用语应限制在实际测量层级。 按文档化 harness 比较启用 profile 与对照条件。不能用模拟器结果证明实体手机表现，也不能把单次结果推广到所有设备。如果项目无法正确配置 benchmark module 或近似 release 的变体，就应报告限制，而非改用手动秒表。本文提供可靠测试设计，不声称 Cove 已发布 Baseline Profile 或取得某个速度提升。 性能评估期间也要保留用户可见正确性。不能为了让旅程看似更顺畅而提前显示“就绪”、重复提交请求或隐藏失败。对同一条流程保留功能断言，避免更好的 trace 掩盖丢失的结果或不可用操作。保存 profile 修订、旅程定义、观察到的状态和 trace 引用；benchmark 报告不放提示词和媒体正文。 Profile 生成场景本身也应固定。若定义的是首次启动路径，应明确安装条件和 profile 编译状态；若测试二次导航，应说明是同一进程还是冷启动。Android benchmark 工具支持控制编译模式和启动状态，团队应在方案中写明。否则“启动改善”可能把缓存、安装或系统编译差异混在一起。 将模型任务状态划分清楚：未安装、已安装待校验、引擎初始化中、任务运行和输出已展示。Benchmark 要知道从哪个状态开始，并把其余转换保留在 trace。测试还应确认错误或取消能结束任务且不会阻止后续导航。不要仅在成功样例中生成 profile；关键失败旅程也应覆盖，但不应把故障回退称作性能收益。 最终报告应写明 profile 是否被纳入、对应哪种编译模式、运行的旅程是什么、模型任务是否位于计时区间以及有哪些设备信息。若没有可比数据，就只报告流程和测试结果，不输出百分比提升。一个可复核的窄结论比把应用层优化误写成模型能力更可信。
为模型辅助笔记流程评估 Baseline Profile
benchmark 启动应用、进入笔记页、等待模型就绪、提交固定输入并显示结果。团队必须知道指标反映 UI 代码还是推理。
决策
把旅程拆成命名阶段，指定 profile 的目标阶段，并保留近似 release 构建及 trace 证据。
预期结果
审阅者能解释 UI/profile 指标，而不会把模型加载或推理时间归错层。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- BENCHMARK-01：结论需绑定可复现的工作负载、软件和测量边界。
- COVE-LIFECYCLE-01：模型就绪与任务阶段要显式区分；界面流程测试不自动证明 runtime 成功。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 写明目标旅程和测量层级. 描述从启动到导航和结果显示的步骤，并指出目标是外壳绘制、模型就绪、推理还是其中一段。
- 使用正确的 benchmark 和变体. 将 Macrobenchmark 目标配置为接近 release，注明测试模块、profile 状态和编译模式。不要把 debug/release 差异误当成 profile 单变量效果。
- 为每轮重置一致状态. 让屏幕和制品状态一致。若不测模型初始化或推理，就把它稳定放在测量区间外；若要测，需命名边界。
- 同时检查 trace 与功能结果. 查看启动、组合、导航、主线程任务、模型就绪和推理区间，并断言输出与错误状态仍正确。
- 报告具体范围而非速度大话. 结果绑定应用变体、profile 修订、设备、系统、旅程、runtime 和制品；列出缺少的 trace 或设置限制，不推断普遍增益。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 测量旅程声明是否包含应用启动、模型就绪、推理和结果呈现。
- 记录 profile 测试与目标应用的构建身份、近似 release 配置和编译模式。
- Trace 将 UI 与 native 初始化/推理分开；功能输出断言持续有效。
- 公开结论仅限实际设备、构建、旅程、profile 和测量环境。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| Macrobenchmark UI 旅程 | 测应用启动、导航和渲染边界 | 适合用户流程，不单独衡量模型质量。 |
| 模型 runtime 专项测试 | 用命名事件记录制品加载和推理 | 回答 runtime 问题，不应称为 Baseline Profile 结果。 |
| 手动秒表 | 只作探索检查并说明限制 | 难以隔离阶段且重复性弱，不能替代有追踪的基准配置。 |
需要避免的失败模式
- 把应用首屏或导航耗时当成本地模型推理耗时。
- 用可调试开发构建与 release 构建比较，却将差异都归因于 Baseline Profile。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
Baseline Profile 会让模型推理更快吗？
不能这样假设。它针对纳入的应用代码路径；runtime 推理仍需独立的制品、backend、工作负载和测量证据，且要绑定设备、系统及构建变体来源。
能把 debug 版和 profile release 版直接比较吗？
不能将差异仅归因 profile，因为构建类型和优化也不同。应按 benchmark 指南记录可比的近似 release 条件、设备、编译模式和测量设置，并保留 trace 便于复核。
模型初始化要计入启动耗时吗？
只有研究问题明确包含时才计入，并单独记录事件；不能将 UI 启动、引擎加载和任务输出混在一个时长，结果也只适用于该任务。