Skip to main content

Measuring latency

Every successful API response includes a standard Server-Timing header with server-side latency measurements.

Server-Timing: processing;dur=31.669
MetricWhat it measures
processingServer-side time from receiving the request until response headers are available, including request handling and model startup.

Subtract processing from the time to response headers to estimate client and network overhead. Treat the result as an approximation because the measurements are taken at different points in the request lifecycle.

Reading it

curl -sS -D - -o /dev/null \
https://inference.cloud.celeris.ai/celeris-1/v1/chat/completions \
-H "Authorization: Bearer $CELERIS_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"celeris-1","messages":[{"role":"user","content":"ok"}],"max_tokens":4}' \
| grep -i '^server-timing'

Getting the numbers down

  • Deploy close to the region. Typical short requests complete in roughly 50–150 ms within the region. Network distance adds to end-to-end latency. See Models § Regions.
  • Reuse connections. Use an HTTP client with connection pooling and keep-alive enabled. OpenAI SDK clients do this by default.
  • Cap max_tokens. Completion length is the main thing you control that moves inference time.
  • Monitor 429 responses in your application. The usage page does not include throttled requests. See Rate limits.