Utinzo

LLM Latency Calculator

Estimate expected LLM response latency — time-to-first-token and total response time — for planning real-time AI applications.

Did this tool work for you?

How to use this calculator

Total Time = TTFT + (Output Tokens / Tokens per Second)
  1. 1

    Select the LLM you are planning to use.

  2. 2

    Enter the expected input token count (your prompt length) and output token count (desired response length).

  3. 3

    Select the expected server load — low for off-peak hours, high for peak traffic.

  4. 4

    Review TTFT and total response time to determine if the model fits your latency budget.

Frequently asked questions

What formula does the latency calculator use?

Total time = TTFT + output tokens ÷ tokens per second. TTFT and tokens per second start from a per-model baseline at medium load, then the load level rescales them: TTFT × 0.7, 1.0 or 1.8 for low, medium or high, and tokens per second ÷ the same multiplier. Both are rounded to whole numbers before the total is computed.

Where do the baseline latency numbers come from?

From two lookup tables in the code, commented as approximate figures at medium load. They are static and are not measurements or benchmarks, so real latency can differ by region, provider load, prompt length and model version. Measure the endpoint you plan to use.

Does the number of input tokens change the result?

No. The input tokens field is accepted but is not used in the calculation, so a 100,000-token prompt returns the same result as a 500-token one. In reality, longer prompts generally take longer before the first token appears, so results for large prompts are optimistic.

How is the real-time verdict decided?

From total response time only: under 3 seconds is Yes, suitable for real-time chat; under 8 seconds is Marginal, consider streaming; otherwise No, use async or background processing. TTFT alone is not part of the label.

What does time to first token mean?

It is the delay between sending the request and the first generated token arriving. In a streamed interface it is roughly how long the user waits before anything appears; the rest of the response then appears at the tokens-per-second rate.

Does streaming change the total time?

Not in this tool: total time is the same formula either way. Streaming changes what users experience, because they can read from the first token onward instead of waiting for the full response.

What do the low, medium and high load options do?

They are fixed multipliers of 0.7, 1.0 and 1.8 applied to the baselines. They are not derived from any provider data, so use them to see sensitivity rather than to predict peak behaviour.

What is left out of the estimate?

Network round trips, queueing beyond the three load levels, tool calls, retries, rate-limit delays and any hidden reasoning tokens generated before the visible answer.

About llm latency calculator

LLM latency calculator: time to first token and total response time

The two-part formula

Total time = time to first token (TTFT) + output tokens ÷ tokens per second. Both values come from lookup tables in the code, one pair of numbers per model at medium load, and the load setting rescales them: TTFT is multiplied by 0.7 at low load, 1.0 at medium and 1.8 at high, while tokens per second is divided by the same multiplier. Results are rounded to whole milliseconds and whole tokens per second before generation time is calculated, so the on-screen figures reproduce exactly from each other. Output is clamped to at least one token.

Baselines stored in the code

These are static, approximate figures built into this tool, not measurements. Real latency depends on region, prompt length, provider load, streaming settings and model version, so benchmark the endpoint you plan to call. Model names appear as listed in the dropdown, without release dates.

Medium-load baselines used by the calculator
Model entryTTFT (ms)Tokens per second
GPT-4o40060
GPT-4o-mini200120
Claude Sonnet60070
Claude Haiku200150
Gemini 1.5 Pro40080
Gemini 1.5 Flash150200
Llama 3 70B30040
Llama 3 8B100120

Worked examples

Latency runs. The columns show Run, TTFT, Tokens/s, Total time and Verdict, one line per case.

Latency runs
RunTTFTTokens/sTotal timeVerdict
GPT-4o, medium load, 300 output tokens (defaults)400 ms605.40 sMarginal
GPT-4o, low load, 600 output tokens280 ms867.26 sMarginal
GPT-4o, medium load, 600 output tokens400 ms6010.40 sNo
GPT-4o, high load, 600 output tokens720 ms3318.90 sNo
Gemini 1.5 Flash, low load, 150 output tokens105 ms2860.63 sYes
Llama 3 70B, high load, 800 output tokens540 ms2236.90 sNo

How the verdict works

The real-time label looks only at total time: under 3 seconds is Yes, under 8 seconds is Marginal, anything longer is No. Streaming is not part of it, so a response that streams can feel faster than the label suggests, because users start reading after the TTFT instead of after the total. If your product shows tokens as they arrive, use the TTFT line for responsiveness and the total line for how long the connection stays open. The GPT-4o runs at 600 output tokens show that output length dominates: 280 ms of TTFT matters little against nearly seven seconds of generation.

What the model leaves out

The input-token field is accepted but does not enter the formula, so a very long prompt returns the same answer as a short one. Real processing time before the first token grows with prompt length, so treat results for long prompts as optimistic. Network round trips, queueing beyond the three load levels, tool calls, retries and any reasoning tokens generated before the visible answer are also outside the calculation. Use the output to compare shapes and sensitivities, then confirm with a timed test against the actual endpoint.

LLM Latency Calculator – Utinzo

Learn more from an authoritative source:

OpenAI Platform Docs
Related tools

Results are estimates for informational purposes only and do not constitute professional financial, medical, legal, or technical advice. Read full disclaimer →