feat(logs): distinguish generation rate from end-to-end throughput

Environment

• OmniRoute 3.8.52, image digest sha256:90f903d7e9245973dc23f7f0a3afc0c63502c9bd25961097843361689df6474b
• Dashboard -> Logs, green speed column (second-to-last data column, left of the duration column)

Summary

The per-request speed column on the Logs page appears to be computed as tokens_out / (duration - ttft_ms). When an upstream buffers its response (first token arrives late, the rest streams in a burst), duration - ttft_ms collapses towards zero and the column displays physically impossible throughputs. Observed on DeepSeek v4.1 Flash: 12,709 and 5,146 "TPS", while the true end-to-end throughput of the same requests is 85-230 TPS.

On the pre-3.8.52 build (digest sha256:90358c971b44e9f135edac557352658ddbdb5b6d11fc5e42f732688e5dbac981) the same column read systematically low on identical traffic, so this looks like an unannounced semantics change between releases.

Verified against call_logs - 14/14 recent rows match the formula exactly

All rows: model cb/deepseek-v4.1-flash via a custom openai-compatible-chat-* connection, status 200. The remaining 9 rows of the window match the same identity to +/-1 (rounding).

Repro SQL

SELECT timestamp, tokens_out, duration, ttft_ms,
       ROUND(tokens_out * 1000.0 / duration, 1)                   AS tps_end_to_end,
       ROUND(tokens_out * 1000.0 / MAX(duration - ttft_ms, 1), 1) AS tps_column_formula
FROM call_logs
WHERE model LIKE '%deepseek-v4.1-flash%' AND status = 200
ORDER BY timestamp DESC LIMIT 14;

Why this misleads

• duration - ttft is only the post-first-token window. For buffered / non-incremental upstreams it shrinks to tens of milliseconds, so the quotient measures a burst rate, not throughput.
• Rows with ttft ~= 0 display correct-looking values, which masks the defect in casual inspection.
• The column has no unit tooltip and no sanity clamp; values above ~2-3k TPS are beyond any current frontier model, yet they are shown unmarked.

Expected behaviour

Either

1. show end-to-end throughput tokens_out / duration and label the column accordingly, or
2. keep the generation-phase rate but clamp / fall back, e.g. when duration - ttft_ms < 500 or shown > 5 x (tokens_out / duration), fall back to the end-to-end value; and persist the displayed value in call_logs (e.g. tps_display) so the metric is auditable.

Note

Whichever semantics is intended, please document the change in the changelog: operators comparing dashboards across 3.8.51 -> 3.8.52 currently see the same traffic reported ~10-90x faster.