Fastest AI API from South America (Santiago)
· edge + inference latency
As of November 08, 2026, measured from South America (Santiago), the fastest AI inference API by edge latency (time-to-first-byte) is openrouter at 57 ms p50 (n=21).
Which AI API is fastest from South America (Santiago)?
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 | openrouter | 57 ms | 83 ms | 100% | 21 |
| 2 | meta-llama | 165 ms | 379 ms | 100% | 21 |
| 3 | typesafe | 174 ms | 179 ms | 100% | 21 |
| 4 | baseten | 176 ms | 198 ms | 100% | 21 |
| 5 | cerebras | 181 ms | 237 ms | 100% | 21 |
| 6 | xai | 187 ms | 220 ms | 100% | 21 |
| 7 | anthropic | 192 ms | 218 ms | 100% | 21 |
| 8 | groq | 196 ms | 300 ms | 100% | 21 |
| 9 | cohere | 202 ms | 226 ms | 100% | 21 |
| 10 | openai | 212 ms | 252 ms | 100% | 21 |
| 11 | inference-net | 213 ms | 265 ms | 100% | 21 |
| 12 | novita | 219 ms | 332 ms | 100% | 21 |
| 13 | perplexity | 234 ms | 481 ms | 100% | 21 |
| 14 | together | 238 ms | 619 ms | 100% | 21 |
| 15 | fireworks | 260 ms | 276 ms | 100% | 21 |
| 16 | reka | 264 ms | 571 ms | 100% | 21 |
| 17 | writer | 266 ms | 329 ms | 100% | 21 |
| 18 | siliconflow | 280 ms | 287 ms | 100% | 21 |
| 19 | friendli | 294 ms | 389 ms | 100% | 21 |
| 20 | mistral | 300 ms | 341 ms | 100% | 21 |
| 21 | kimi | 343 ms | 384 ms | 100% | 21 |
| 22 | sambanova | 379 ms | 384 ms | 100% | 21 |
| 23 | baichuan | 393 ms | 1385 ms | 100% | 21 |
| 24 | ai21 | 395 ms | 506 ms | 100% | 21 |
| 25 | ernie | 412 ms | 418 ms | 100% | 21 |
| 26 | nebius | 440 ms | 475 ms | 100% | 21 |
| 27 | nscale | 441 ms | 443 ms | 100% | 21 |
| 28 | deepseek | 455 ms | 525 ms | 100% | 21 |
| 29 | aleph-alpha | 464 ms | 475 ms | 100% | 21 |
| 30 | minimax | 496 ms | 512 ms | 100% | 21 |
| 31 | deepinfra | 527 ms | 564 ms | 100% | 21 |
| 32 | glm | 533 ms | 545 ms | 100% | 21 |
| 33 | replicate | 556 ms | 708 ms | 100% | 21 |
| 34 | upstage | 593 ms | 685 ms | 100% | 21 |
| 35 | sarvam | 673 ms | 689 ms | 100% | 21 |
| 36 | stepfun | 704 ms | 1758 ms | 100% | 21 |
| 37 | sensenova | 729 ms | 1660 ms | 100% | 21 |
| 38 | qwencloud | 732 ms | 750 ms | 100% | 15 |
| 39 | qwen | 735 ms | 773 ms | 100% | 21 |
| 40 | iflytek | 741 ms | 1711 ms | 100% | 21 |
| 41 | featherless | 742 ms | 834 ms | 100% | 21 |
| 42 | hyperbolic | 752 ms | 783 ms | 100% | 21 |
| 43 | doubao | 763 ms | 1725 ms | 100% | 21 |
| 44 | tencent-tokenhub | 793 ms | 806 ms | 100% | 21 |
| 45 | 970 ms | 1071 ms | 100% | 21 |
openrouter leads by 108 ms over meta-llama here. The median provider measured from South America (Santiago) answers in 393 ms, so the spread between the fastest and a typical option is 336 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 | 306 ms | 454 ms | 5 |
| 2 | groq | openai/gpt-oss-120b | 717 ms | 823 ms | 5 |
| 3 | gemini-flash-lite-latest | 1891 ms | 2003 ms | 5 |
Why measure from South America (Santiago) 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 South America (Santiago); 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.