首 token 与整体时延：在一把聚合站 key 上量每个后端的响应速度

为什么要分开看两个时延

调用一个模型时，用户感知到的"卡"通常不是总耗时，而是第一次看到字之前的那段空白。所以一次请求至少有两个值得记录的指标：

• 首 token 时间（TTFT）：从发出请求到收到第一个输出 token 的时间。它主要受排队、模型预填充、网络往返影响。
• 整段耗时：从发出请求到流结束。它取决于输出长度和每秒生成的 token 数。

只记总耗时，你会把"输出长所以慢"和"首字就慢"混在一起，路由决策就没法做。

在聚合站上做这件事的特殊性

用一个 API key 调多个模型时，测量有一个天然好处：客户端代码、网络位置、鉴权路径基本一致，差异主要来自后端本身。但也正因为共用入口，你要注意几点：

1. 按模型维度打标签，不要把所有请求混成一个平均值。不同后端的 TTFT 分布量级差别很大。
2. 区分流式与非流式。TTFT 只在流式下有意义；非流式请求只有整段耗时。
3. 记录输入/输出 token 数。输出长度直接决定整段耗时，不归一化的对比会误导。
4. 关注路由与失败重试。聚合层可能在你不知情时换后端或重试，异常值要单独看，不要直接进平均值。

怎么量：最小可行的做法

不需要复杂的压测平台，客户端埋点就够：

• 用流式接口发请求，在收到第一个内容增量时打一个时间戳，流结束时再打一个。
• 每个请求落一条记录：模型名、时间戳、输入 token、输出 token、是否成功、是否重试。
• 固定一组有代表性的提示词跑。混着跑不同任务类型，TTFT 会因输入长度差异而失真。
• 在一段时间内累积样本，看分位数而不是均值。P50 看常态，P90/P95 看抖动。

跑的时候把并发控制在接近你真实业务的水平。空载测出来的 TTFT 在生产里基本复现不了。

怎么读数据

拿到表之后，按用途筛选：

• 首 token 时间的 P50 决定交互体验的下限。
• 首 token 时间的 P90 和整段耗时的 P90 决定你偶尔会"卡一下"的程度。
• 输出速度（输出 token 数 ÷ 生成阶段耗时） 反映后端吞吐，适合判断长回答场景。

注意不同后端的模型能力不同，时延数据只回答"快不快"，不回答"够不够好"。路由时要先满足质量门槛，再在合格者里比时延和成本。

把结果变成路由策略

有了按后端分开的时延画像，就可以按场景分派：

• 交互式场景（聊天、补全、实时助手）：优先选 TTFT 低且 P90 稳定的后端。这类场景对总耗时没那么敏感，首字延迟才影响主观感受。
• 批处理场景（离线摘要、批量打标、数据清洗）：优先选成本低、吞吐高的后端，把 TTFT 完全排除在决策之外。几秒的首字延迟在批处理里没有人感知。
• 长输出场景：看输出速度而不是 TTFT，否则容易选错。
• 兜底与降级：为每个场景准备一个次优后端，主后端时延劣化或报错时切过去。

这套策略可以先用静态配置实现：交互场景绑定 A 后端，批处理绑定 B 后端。数据积累够了再做动态选择，按实时分位数路由。

成本维度要一起算

聚合站的计费方式是官方价乘以系数扣费，贡献 key 则按另一套系数返 USDC。做路由时把每条路径的实际单价和它的时延画像放在一张表里对比，而不是只看时延或只看单价。

一个常见的结论是：把便宜的慢后端留给批处理，把贵的快后端留给交互，整体成本和体验往往同时改善。但这需要你自己的数据来确认，不同后端在你所在网络和时段的表现会有差异。

定期复测

后端容量、路由、模型版本都在变，时延画像会过期。建议：

• 保持埋点常开，滚动看最近一段时间的分位数。
• 每类场景固定一小批探针请求持续跑，作为长期对照。
• 当某个后端的分位数明显漂移时，先看是不是自己的流量模式变了，再决定要不要调路由。

时延测量本身不复杂，难的是坚持按后端、按场景分开记录。做到这一点，路由决策就从拍脑袋变成了查表。