直接回答
基准结果只有连同周围条件一起记录时才可解释。可用的数据结构应把应用构建、系统版本、设备身份、模型制品、runtime 与 backend 配置、工作负载修订、输入夹具、测量边界、输出验收规则及终态绑在一起。缺少其中任一字段，审查者可能无法判断两条数值是否描述同一个任务，backend 是否改变，或者失败样本是否被静默删除。记录结构的目的不是让所有结果自动可比，而是把比较的前提与限制显示出来。 区分稳定身份和一次观测。run identity 可以引用准确的应用/runtime 修订、模型制品摘要或稳定 ID、请求 backend 与实际观察到的 backend（若能取得）、设备和系统构建、协议修订。observation 则保存观察事件和值，而非预设结论：开始与结束事件、样本序列、状态、错误、取消、回退及单位。原始事件记录应不可变；派生摘要需注明来源记录和聚合规则。这样日后若解析器或单位换算被纠正，历史数据仍可重算而不必改写原始事实。 采集前先定义事件名。例如“提交请求”“首个有效输出”和“任务终态”不能与应用启动、制品校验或引擎初始化互换。只记录一个耗时可能隐藏等待到底发生在存储、初始化、首 token 还是后续生成。保存事件标记和简短协议说明。如果同时采集设备热状态或电量状态，记录平台信号来源和采样时刻；不能从结构里的字段推导通用合格阈值。 所有终态都要保留。一次测试可以是成功、失败、取消、超时、回退，也可以因明确记录的仪器故障而作废。数据结构必须说明状态和原因。不能把崩溃平均掉，也不能没有预先规则就删除慢样本，或用重试数据替代最初失败。持续测试需保留按顺序排列的样本，让审阅者能查看变化趋势，不只看到平均值。缺失数据应是 null 或明确的缺失原因，不能伪装成零。 把隐私边界也写入模式。必要时使用夹具 ID 和内容摘要，但不要把用户提示词、照片、音频、文档正文或敏感文件名放进分析记录或公开 benchmark 导出。若独立复现确实需要测试内容，应使用另行治理的合成或已获同意夹具。技术上完整但会泄露用户内容的记录系统仍然不可接受。 像校验应用输入一样校验基准记录。要求已知 schema 版本、明确单位、合法状态值和协议引用。拒收有数值却无事件定义、声称发生回退却无原因、或引用了 release manifest 不存在的 artifact ID 的记录。若为前向兼容保留未知字段，消费者只能在安全忽略时接受，绝不能猜测未知单位。版本迁移必须用旧夹具测试，不能静默修改历史记录语义。 当多个团队共同采集数据，或某条性能说法日后需要审计时，这种方式尤其有用。但记录模式本身不会生成基准数据，也不建立 Cove 设备兼容名单。事实卡明确要求可复现方法和原始证据。模式能帮助保存证据，却不能替代真机测试、仪器校准或判断工作负载是否代表真实用户任务的审核者。发布内容只能覆盖记录支持的范围，并说明数据集没有包含什么。 还应记录测量系统自身的版本。若脚本改变了计时点、采样频率或清理缓存的方法，即使应用制品不变，结果也属于不同协议。把 harness 版本和操作说明绑定到运行记录，而不是只在团队聊天中口头说明。对于追踪数据，可保存受控的位置或摘要，而不是将含敏感内容的 trace 附件公开。保留访问控制和到期策略，使复现所需证据不会变成无限期数据仓库。 比较多个版本时，先筛选完全匹配的记录，再报告差异。若设备、artifact 或任务夹具不同，应明确说明这是不同组，而不是将所有数字并列成公平对比。聚合规则还要说明是否包含失败、是否按样本加权以及如何处理缺测。无法恢复的历史表格不要伪造 schema 字段，应标为来源不足并停止用于宣传结论。明确承认未知，能避免后续团队把推测当成原始事实。
两张“回答耗时”表格的计时起点不同
一名测试者从点击发送开始计时，另一名在模型初始化后开始；两边都没有保留失败或取消尝试。团队需要比较版本改动，却不能假装历史定义一致。
决策
建立事件驱动的记录结构，保留原始观察，而不是事后把含糊时间强行归一。
预期结果
未来结果能说明配置、任务、状态和边界；历史歧义则诚实标为未知。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- BENCHMARK-01：事实卡要求基准结论绑定方法和原始记录；缺少数据时不得补造结果。
- THERMAL-01：热状态属于有来源的平台信号；记录来源和采样时刻，而非创造通用阈值。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 定义一次运行的身份. 绑定 app/runtime 修订、制品身份、请求与观察到的 backend、设备/系统构建、夹具 ID 和协议版本。使用稳定标识，不能只靠人工填写的模型家族名称。
- 规定事件名称和单位. 为每个指标说明准确起止事件、单位、时钟来源及采样方式。启动、制品验证、引擎就绪、首个输出和任务结束要分别记录。
- 表示所有终态和样本. 明确成功、失败、取消、超时、回退和仪器作废状态。保留按序样本及错误，在测试前定义排除条件，而非看过数据后决定。
- 使用保护隐私的夹具引用. 保存夹具标识或经批准的摘要，不写提示词或媒体正文。若需公开复现，使用单独治理的合成或已获许可测试集。
- 校验结构与旧版本迁移. 拒绝未知单位、缺协议版本、未绑定的制品 ID 和缺少必要事件的成功记录。发布迁移前使用旧版夹具测试读取语义。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每条数字观测都注明事件边界、单位、工作负载、应用/runtime 修订和制品身份。
- 失败、取消、回退及持续运行顺序样本不会被摘要静默过滤。
- 模式校验拒绝歧义单位或缺少溯源信息的记录，迁移测试保留历史含义。
- 普通基准记录不保存提示词、媒体载荷、文档正文或敏感文件名。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 单个汇总耗时 | 仅作为引用来源 ID 的派生视图保存 | 简洁，但不足以解释耗时变化发生在哪一阶段。 |
| 事件驱动原始记录 | 保存命名状态转换与有序观测 | 可审计阶段和趋势，但需要更多存储与 schema 管理。 |
| 无结构电子表格 | 只有恢复溯源信息时才迁移 | 历史含糊数值应继续标注未知，不应凭空回填。 |
需要避免的失败模式
- 只保存一个汇总时间，丢失模型加载、首个输出与任务完成等阶段边界。
- 删除失败样本、混用单位或把用户提示与媒体内容写入基准导出。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
模式完整就能保证两次测试可比较吗？
不能保证。模式只能使条件可检查；仍需匹配工作负载、制品、协议、仪器和所回答的问题，并说明设备、版本及采样差异来源和记录。
失败样本应从平均值里删掉吗？
必须保留并标注。若某指标有排除规则，应在测试前定义并保留原始记录，使失败率、重试情况和样本选择都可审计、复核和追踪。
benchmark 记录里应保存真实用户提示词吗？
不应保存。使用经过批准的夹具 ID 和隐私审核引用；普通导出不包含提示词、私人媒体或文档内容，也不暴露敏感文件名及路径。