Fastest AI API from US (Central)
· edge + inference latency
As of October 22, 2026, measured from US (Central), the fastest AI inference API by edge latency (time-to-first-byte) is fireworks at 28 ms p50 (n=289).
Which AI API is fastest from US (Central)?
Endpoint response (TTFB) · last 24 hours · milliseconds (ms) · lower is faster.
How to read these metrics
| # | Provider | Typical (p50 TTFB) | Slower (p95) | Uptime | Samples |
|---|---|---|---|---|---|
| 1 | fireworks | 28 ms | 72 ms | 100% | 289 |
| 2 | baseten | 46 ms | 61 ms | 100% | 289 |
| 3 | meta-llama | 54 ms | 114 ms | 100% | 289 |
| 4 | 58 ms | 160 ms | 100% | 289 | |
| 5 | cohere | 61 ms | 127 ms | 100% | 289 |
| 6 | openrouter | 63 ms | 142 ms | 100% | 289 |
| 7 | cerebras | 76 ms | 151 ms | 100% | 289 |
| 8 | typesafe | 76 ms | 97 ms | 100% | 289 |
| 9 | siliconflow | 78 ms | 104 ms | 100% | 289 |
| 10 | novita | 84 ms | 162 ms | 100% | 289 |
| 11 | perplexity | 88 ms | 143 ms | 100% | 289 |
| 12 | targon | 90 ms | 102 ms | 100% | 289 |
| 13 | replicate | 92 ms | 152 ms | 100% | 289 |
| 14 | anthropic | 94 ms | 160 ms | 100% | 289 |
| 15 | reka | 103 ms | 191 ms | 99.7% | 289 |
| 16 | xai | 111 ms | 175 ms | 100% | 289 |
| 17 | groq | 116 ms | 190 ms | 100% | 289 |
| 18 | together | 125 ms | 209 ms | 100% | 289 |
| 19 | hyperbolic | 126 ms | 275 ms | 100% | 289 |
| 20 | openai | 142 ms | 232 ms | 100% | 289 |
| 21 | writer | 156 ms | 215 ms | 100% | 289 |
| 22 | deepinfra | 164 ms | 726 ms | 100% | 289 |
| 23 | inference-net | 164 ms | 435 ms | 100% | 289 |
| 24 | friendli | 166 ms | 246 ms | 100% | 289 |
| 25 | sambanova | 173 ms | 222 ms | 100% | 289 |
| 26 | nebius | 178 ms | 213 ms | 100% | 289 |
| 27 | mistral | 197 ms | 269 ms | 100% | 289 |
| 28 | yi-01ai | 223 ms | 877 ms | 100% | 289 |
| 29 | nscale | 236 ms | 242 ms | 100% | 289 |
| 30 | ai21 | 237 ms | 373 ms | 99.7% | 289 |
| 31 | baichuan | 238 ms | 868 ms | 100% | 289 |
| 32 | glm | 255 ms | 291 ms | 100% | 289 |
| 33 | aleph-alpha | 256 ms | 322 ms | 100% | 289 |
| 34 | kimi | 269 ms | 350 ms | 100% | 289 |
| 35 | ernie | 269 ms | 281 ms | 100% | 289 |
| 36 | deepseek | 318 ms | 384 ms | 100% | 289 |
| 37 | minimax | 338 ms | 362 ms | 100% | 289 |
| 38 | upstage | 353 ms | 373 ms | 100% | 289 |
| 39 | featherless | 374 ms | 2851 ms | 99.7% | 289 |
| 40 | stepfun | 401 ms | 1060 ms | 100% | 289 |
| 41 | qwen | 406 ms | 454 ms | 100% | 289 |
| 42 | iflytek | 412 ms | 1438 ms | 100% | 289 |
| 43 | sensenova | 414 ms | 1086 ms | 99.7% | 289 |
| 44 | doubao | 463 ms | 1122 ms | 100% | 289 |
| 45 | sarvam | 499 ms | 520 ms | 100% | 289 |
| 46 | hunyuan | 1382 ms | 1398 ms | 100% | 289 |
fireworks leads by 18 ms over baseten here. The median provider measured from US (Central) answers in 166 ms, so the spread between the fastest and a typical option is 138 ms on every single request — before the model has produced anything.
Inference latency (time-to-first-token)
Each provider is measured on the model named below — model size affects TTFT far more than the network does, so these numbers are not a like-for-like ranking of providers. Use the edge-latency table above for that. Coverage is limited to providers we hold an API key for.
First model token (TTFT) · last 24 hours · milliseconds (ms) · lower is faster.
How to read these metrics
Models differ between providers; compare each named model over time.
| # | Provider | Model | Typical (p50 TTFT) | Slower (p95) | Samples |
|---|---|---|---|---|---|
| 1 | typesafe | jev-1.13.0 | 522 ms | 697 ms | 72 |
| 2 | groq | openai/gpt-oss-120b | 1345 ms | 1746 ms | 72 |
| 3 | gemini-flash-lite-latest | 1591 ms | 6437 ms | 72 |
Why measure from US (Central) separately?
Latency is a property of a route, not of a company. The same provider can lead in one region and trail in another, so a ranking produced from a single location tells you very little about what your users will experience somewhere else. This page reports only what was measured from US (Central); the other regions are ranked independently and often disagree — see the cross-region summary for how far apart they get.
How should these numbers be read?
p50 is the typical request and p95 is the slow tail: if p95 is far above p50, that provider is inconsistent from here, which usually hurts more than a slightly higher median. Uptime counts a probe as failed only on a genuine service failure — an authentication error means the endpoint answered correctly and counts as up. All figures cover the last 24 hours and are recomputed continuously; the methodology page states the limits of this data plainly.