活動合約
查詢期望的欄位
| 欄位 | 型別 | 為什麼存在 |
|---|---|---|
| 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(按型號和功能劃分)
- 資料表:具有權杖計數和重試上下文的慢速請求
讓查詢範例發揮作用
相關埋點和指南
繼續分析
在真實事件中執行它
建立資料表,調整欄位並儲存結果
免費開始,傳送結構化事件,並將查詢結果用作圖表、共享儀表板小工具或警示輸入。