活动合约
查询期望的字段
| 字段 | 类型 | 为什么存在 |
|---|---|---|
| timestamp_utc | Timestamp | 模型请求完成时间。 |
| model | Utf8 | 提供者模型标识符。 |
| feature | Utf8 | 提出要求的产品功能。 |
| status | Utf8 | 最终请求结果。 |
| time_to_first_token_ms | Float64 | 距离第一个流式令牌的毫秒数。 |
| latency_ms | Float64 | 总请求持续时间(以毫秒为单位)。 |
DataFusion SQL
复制查询
sql
SELECT
feature,
model,
COUNT(*) AS requests,
approx_percentile_cont(time_to_first_token_ms, 0.50) AS p50_ttft_ms,
approx_percentile_cont(time_to_first_token_ms, 0.95) AS p95_ttft_ms,
approx_percentile_cont(latency_ms, 0.95) AS p95_total_latency_ms
FROM llm_requests
WHERE timestamp_utc >= now() - INTERVAL '7 days'
AND status = 'success'
AND time_to_first_token_ms IS NOT NULL
GROUP BY feature, model
HAVING COUNT(*) >= 30
ORDER BY p95_ttft_ms DESC;此只读查询是针对空类型表计划和执行的 阿帕奇 DataFusion 45.2.0。确定性样本输出是综合的并单独审查;根据您自己的数据验证字段类型、阈值和业务定义。 阅读测试方法。
查询结果
p95 第一个令牌的时间
报告生成的启动暂停时间最长,总完成时间最慢。
report_generation
4,620 ms
comparison 1,280 ms
draft_reply
920 ms
comparison 310 ms
search_summary
1,380 ms
comparison 480 ms
| feature | model | requests | p50_ttft_ms | p95_ttft_ms | p95_total_latency_ms |
|---|---|---|---|---|---|
| report_generation | large-reasoning | 842 | 1,280 | 4,620 | 18,400 |
| draft_reply | small-fast | 6,810 | 310 | 920 | 3,840 |
| search_summary | balanced | 2,420 | 480 | 1,380 | 6,210 |
综合示例输出。在将其用于操作决策之前,针对您自己的事件架构和阈值运行查询。
SQL 是如何工作的
- 1成功的流请求按产品决策和模型进行分组。
- 2p50 描述了典型的停顿,而 p95 则暴露了用户抱怨的尾部。
- 3总 p95 延迟仍然存在于 TTFT 旁边,因此优化不会改善启动,同时会使完成情况变得更糟。
需要决定的边缘情况
- 非流请求没有有意义的第一个令牌测量。
- 提供商报告的时间和客户观察到的时间可能有所不同;记录测量边界。
- 比较功能内的模型,因为提示大小和请求的输出长度都会影响这两个指标。
推荐仪表板
- 分组条:p50_ttft_ms 和 p95_ttft_ms
- 趋势:p95 TTFT(按型号和功能划分)
- 表:具有令牌计数和重试上下文的慢速请求
让查询示例发挥作用
相关埋点和指南
继续分析
在真实事件中运行它
创建表,调整字段并保存结果
免费开始,发送结构化事件,并将查询结果用作图表、共享仪表板小部件或警报输入。