Batas Rate Limit
Apa yang dibatasi rate limit, apa yang tidak, dan cara melakukan retry dengan aman.
zrouter sengaja membiarkan jalur inferensi tanpa throttle sekaligus menerapkan batas yang jelas dan terdokumentasi pada permukaan administratif yang berisiko lebih tinggi. Halaman ini menjelaskan setiap batas dan cara menangani respons limit dengan benar.
Rate limit inferensi#
Jika Anda melihat 429 pada endpoint inferensi, itu bukan rate limit per klien dari zrouter. Itu adalah passthrough dari respons technical_limit milik upstream, yang diteruskan kepada Anda apa adanya. Detail lengkapnya ada di bagian Penanganan Error.
Rate limit reseller#
Program reseller menerapkan rate limit pada endpoint administratifnya. Melebihi batas akan mengembalikan 429 rate_limited:
| Operasi | Batas |
|---|---|
| Login (sign-in / sign-up) | 5 request per menit per email + IP |
| Pembuatan top-up | 10 request per menit |
| Mint | 30 request per menit |
Batas ini melindungi akuntansi kuota prabayar pada program reseller. Untuk kontrak API reseller, lihat Ringkasan Program Reseller.
Timeout#
Request inferensi non-streaming memiliki timeout sisi server 120 detik, yang diterapkan pada round trip ke upstream. Nilai pastinya dapat dikonfigurasi per deployment, tetapi tetap untuk suatu environment — gateway tidak akan membiarkan satu upstream yang macet menahan koneksi tanpa batas.
Request streaming tidak terkena batas ini: begitu stream dimulai, gateway meneruskan event selama proses generasi (dengan keepalive untuk mencegah pemutusan karena idle).
Praktik terbaik retry#
Kegagalan transien pasti terjadi — gangguan upstream, blip jaringan, timeout. Lakukan retry, tetapi dengan hati-hati:
| Praktik | Alasan |
|---|---|
Gunakan exponential backoff dengan jitter pada 429, 5xx, dan timeout | Memberi jarak dan mengacak retry mencegah kontensi thundering-herd pada error upstream yang transien. |
| Retry hanya request yang idempoten | Chat completion non-streaming aman untuk di-retry. Begitu stream sudah dimulai, jangan di-retry — generasinya sudah berjalan dan retry bisa menagih pemakaian dua kali. |
| Atur timeout klien sedikit di bawah 120 detik | Membiarkan klien menyerah tepat sebelum timeout server berarti Anda melihat error yang bersih, bukan pemutusan tak terduga. |
| Gunakan kembali koneksi dan aktifkan keep-alive | Koneksi yang dipakai ulang menghindari overhead membangun TLS di setiap request dan mengurangi tail latency. |
| Batasi retry pada 2–3 percobaan | Lebih banyak percobaan jarang membantu menghadapi outage yang persisten dan dapat memperbesar beban saat terjadi. |