Fastest AI API from Asia (Tokyo)
· edge + inference latency
As of October 22, 2026, measured from Asia (Tokyo), the fastest AI inference API by edge latency (time-to-first-byte) is fireworks at 17 ms p50 (n=289).
Which AI API is fastest from Asia (Tokyo)?
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 | 17 ms | 57 ms | 100% | 289 |
| 2 | sambanova | 26 ms | 79 ms | 100% | 289 |
| 3 | upstage | 60 ms | 76 ms | 100% | 289 |
| 4 | openrouter | 62 ms | 126 ms | 100% | 289 |
| 5 | 66 ms | 120 ms | 100% | 289 | |
| 6 | glm | 91 ms | 153 ms | 100% | 289 |
| 7 | meta-llama | 115 ms | 282 ms | 100% | 289 |
| 8 | kimi | 128 ms | 210 ms | 100% | 289 |
| 9 | ernie | 136 ms | 166 ms | 100% | 289 |
| 10 | baichuan | 141 ms | 538 ms | 99.3% | 289 |
| 11 | typesafe | 146 ms | 162 ms | 100% | 289 |
| 12 | novita | 152 ms | 214 ms | 100% | 289 |
| 13 | qwen | 158 ms | 219 ms | 100% | 289 |
| 14 | groq | 166 ms | 243 ms | 100% | 289 |
| 15 | baseten | 167 ms | 195 ms | 100% | 289 |
| 16 | xai | 172 ms | 264 ms | 100% | 289 |
| 17 | cohere | 181 ms | 223 ms | 100% | 289 |
| 18 | deepseek | 182 ms | 252 ms | 100% | 289 |
| 19 | together | 184 ms | 381 ms | 100% | 289 |
| 20 | yi-01ai | 192 ms | 1105 ms | 88.2% | 289 |
| 21 | replicate | 193 ms | 476 ms | 100% | 289 |
| 22 | cerebras | 205 ms | 283 ms | 100% | 289 |
| 23 | inference-net | 206 ms | 459 ms | 100% | 289 |
| 24 | openai | 212 ms | 303 ms | 100% | 289 |
| 25 | perplexity | 219 ms | 288 ms | 100% | 289 |
| 26 | minimax | 222 ms | 256 ms | 100% | 289 |
| 27 | iflytek | 232 ms | 902 ms | 99.7% | 289 |
| 28 | anthropic | 243 ms | 330 ms | 100% | 289 |
| 29 | sarvam | 252 ms | 264 ms | 100% | 289 |
| 30 | reka | 274 ms | 632 ms | 100% | 289 |
| 31 | writer | 275 ms | 378 ms | 100% | 289 |
| 32 | friendli | 278 ms | 479 ms | 100% | 289 |
| 33 | targon | 317 ms | 334 ms | 100% | 289 |
| 34 | mistral | 321 ms | 388 ms | 100% | 289 |
| 35 | ai21 | 342 ms | 471 ms | 100% | 289 |
| 36 | stepfun | 344 ms | 960 ms | 100% | 289 |
| 37 | siliconflow | 373 ms | 399 ms | 100% | 289 |
| 38 | sensenova | 442 ms | 1137 ms | 100% | 289 |
| 39 | deepinfra | 452 ms | 1060 ms | 100% | 289 |
| 40 | nebius | 479 ms | 526 ms | 100% | 289 |
| 41 | hyperbolic | 482 ms | 570 ms | 100% | 289 |
| 42 | doubao | 492 ms | 1223 ms | 99.7% | 289 |
| 43 | featherless | 496 ms | 1493 ms | 100% | 289 |
| 44 | nscale | 544 ms | 548 ms | 100% | 289 |
| 45 | aleph-alpha | 552 ms | 619 ms | 100% | 289 |
| 46 | hunyuan | 1116 ms | 1125 ms | 100% | 289 |
fireworks leads by 9 ms over sambanova here. The median provider measured from Asia (Tokyo) answers in 212 ms, so the spread between the fastest and a typical option is 195 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 | 850 ms | 1050 ms | 72 |
| 2 | groq | openai/gpt-oss-120b | 1455 ms | 1772 ms | 72 |
| 3 | gemini-flash-lite-latest | 1761 ms | 8059 ms | 72 |
Why measure from Asia (Tokyo) 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 Asia (Tokyo); 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.