直接回答
首 token 延迟只有在明确起止事件之后才有意义。对于用户体验，可以测量应用接受请求到首段模型内容显示的端到端时间；运行时层面则可以从请求提交到推理 API，计时到第一个输出事件。这两个指标回答的问题不同。不能在某次运行中把冷模型加载算进去，另一次又忽略加载。若集成暴露足够时间戳，应分别记录模型就绪、预处理、提示构造、请求提交、运行时首个输出、UI 首次渲染和任务结束。 不要假设标注为 streaming 的 API 每次回调都只发一个 token。LiteRT-LM Kotlin 指南展示了异步对话输出的收集方式，但应用应按准确版本的文档理解事件语义。如果回调提供的是文本块，除非可以观察到 token 级事件，否则应称“首个输出块时间”，不能叫“首 token 延迟”。如果接口只在生成结束后返回完整字符串，这条集成无法测首 token；应标为不可获得，而不是用时间或字符数估算。 间隔测量应使用单调时钟，并从同一时钟来源采集时间戳。Android SystemClock 文档区分 elapsed realtime 和 wall clock；墙上时钟可能因用户或网络校时改变。记录应用构建、制品、运行时、后端请求及可观察执行路径、提示模板、输入夹具、输出预算、设备、系统和冷/热进程状态。请求级 TTFT 可以将初始资产下载与引擎加载排除，但若产品问题关注首次使用就绪体验，应把这些阶段另行计时。 准备固定且非隐私的夹具集，在相同配置下按顺序重复测试。保留全部运行，包括失败、超时、取消和没有输出的情况。定义用户感知时间是否包括队列等待、输入预处理、准入、prefill、流传输、UI 渲染和辅助功能播报。只有在这些阶段的时间戳确实可观察且计算方法已说明时，才可以单独相减。热模型与冷进程属于不同测试组，不应放进同一个平均值。 项目没有完整真实设备基准数据，因此本文提供方法，而非 TTFT 结果、设备排行或速度承诺。如果运行时首个事件只是多个 token 组成的文本块，记录里要说明块语义；如果只能观察到 UI 文本，就称“首个可见输出”，并承认计时包括渲染。有效结果要把计时定义绑定准确制品与事件边界，并保留足以复算的原始时间戳。 图表也应标明“首输出”的对象。它可能是首个非空 token、首个流块、解析后首段文本或 UI 首次绘制，四者不可混用。若第一事件为空控制标记，是否计时到首个用户可见内容需事前约定。计时脚本应自动识别事件，不要由人工看屏幕后按秒表，以免起止主观偏移。不同版本要使用同一界面和日志边界。 报告应同时保留总用户感知时间与可拆分阶段，不要因首段很快就忽略后续生成耗时。若旧版本只有整体回调而新版本支持流事件，两个 TTFT 数字并非同一种测量方法。发生运行时异常或取消时，应保留失败状态，不要从延迟平均数中删掉它们。所有公开结果只对应准确设备和可复现夹具。
模型更新后首段响应感觉变慢
本地助手更新后，团队只有用户点击按钮到屏幕出现文字的一次秒表时间。新版改变了预处理，可能冷启动模型；旧测量则在模型已加载状态下进行。
决策
分别定义请求级、运行时首事件和 UI 首次可见边界；模型加载与预处理另记阶段，比较相同状态。
预期结果
团队能说明准确夹具和配置下哪个区间发生变化，而不宣称通用 token 速率或隐藏冷启动成本。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- BENCHMARK-01：量化结果须有设备、制品、运行时、输入、计时与失败原始记录。
- THERMAL-01：不同运行状态和重复工作负载需分别记录，单次结果不能证明持续表现。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 先定义测量问题和区间. 明确指标是用户动作到可见输出、API 提交到首事件，还是其他命名时间段。写明是否包括队列、预处理、提示构造、模型加载和界面渲染。
- 确认事件粒度. 阅读准确运行时版本的输出契约，注明回调是 token、chunk 还是完整字符串。逐 token 事件不可见时，不得把文本块或最终回答叫首 token。
- 锁定时钟与配置. 统一使用单调时钟，记录应用/制品/运行时、后端请求/证据、提示、夹具、输出预算、设备/系统及冷/热状态。初始模型加载另行测量。
- 执行有序且匹配的多轮测试. 每种声明状态下重复同一非隐私输入。保存全部时间戳及失败、取消、超时或无输出记录；冷、热测试分组保存。
- 报告边界和计算过程. 列出起止定义、原始时间戳、包含阶段、事件粒度、试验次数和排除项。只测 UI 时说明计时含渲染，不推算不可观察的内部阶段。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 指标有明确起始事件、结束事件、时钟来源及包含/排除策略。
- 仅在运行时暴露逐 token 事件时使用首 token 说法；否则叫首块或首个可见输出。
- 冷启动、预处理与请求级输出时间分开，冷/热试验不混合。
- 保留所有运行和失败；速度结论不超出原始时间戳证据。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 首个运行时事件 | API 请求提交到第一个可观察输出事件 | 运行时范围较窄；事件可能是块而不是一个 token。 |
| 首个可见输出 | 用户动作到 UI 首次渲染模型内容 | 以用户为中心，但依定义包括排队、准备、流处理和渲染。 |
| 冷启动就绪加响应 | 首次启动/加载到输出，分阶段报告 | 反映首次使用体验，不应与热模型请求指标混在一起。 |
需要避免的失败模式
- 把按钮点击到页面显示文字的总时间直接当作模型生成时间。
- 没有逐 token 事件时仍把首个 chunk 叫首 token。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
流式回调是否总等于一个 token？
不能这样假设。应查看准确运行时 API 契约。如果回调提供文本块，就报告首块时间，除非逐 token 事件明确可见；固定版本并保留事件样例。
TTFT 是否应包括冷模型加载？
取决于问题，但要分开报告。首次使用总耗时可以包含加载；请求级 TTFT 通常从模型就绪后开始。不同定义不能混入同一个平均值。
秒表测按钮到文字能证明模型速度吗？
不能。它可能合并队列、预处理、提示构造、运行时、流收集和 UI 渲染。比较版本前需定义事件并保留单调时钟时间戳，也需固定冷/热状态。