Batas Laju API Groq dan Cara Kerja Batas 429 Kami

Layanan mana yang menjadi milik batasnya

Nama-nama ini mudah tertukar. Groq adalah perusahaan yang menjalankan model pada perangkat kerasnya sendiri. Grok adalah keluarga model dari xAI. Situs ini bukan keduanya: ini adalah API kompatibel OpenAI untuk satu model bobot terbuka (ID model uncensored), dijalankan oleh penyedia independen. Jadi, untuk batas laju API Groq itu sendiri, seperti permintaan atau token per menit pada paket tertentu, buka konsol atau dokumentasi Groq dan baca angka untuk akun Anda. Angka tersebut berubah, dan saya tidak akan menebak-nebak.

Yang berikut ini berlaku tepat untuk API kami, dan kebiasaan ini berlaku untuk penyedia mana pun: hormati header batas, coba lagi hanya pada error yang tepat, dan batasi konkurensi Anda sendiri sebelum server melakukannya untuk Anda. Jika Anda datang ke sini untuk pengaturan Grok NSFW, panduan integrasi kami mencakup error terkait lainnya.

Batas secara ringkas

Dua di antaranya adalah batas laju dalam arti ketat, permintaan per menit dan konkurensi. Dua lainnya adalah batas ukuran pada satu permintaan, dan mereka independen dari batas laju. Permintaan dengan prompt 90.000 token dihitung sebagai satu permintaan terhadap 300 per menit, sama seperti prompt satu baris, meskipun akan memakan waktu lebih lama dan memegang slotnya lebih lama.

Kredit uji coba senilai $0,50 diklaim dengan satu klik di halaman kunci API setelah pendaftaran, dan menggunakan batas uji coba. Batas kunci penuh berlaku setelah Anda mengisi saldo.

Tiga jenis 429

Semua error batas tiba sebagai HTTP 429, tetapi mereka berarti hal yang berbeda dan memerlukan reaksi yang berbeda.

• rate_limited: Anda mengirim lebih banyak dari kuota permintaan per menit Anda. Pelankan lajunya; jendelanya adalah satu menit, sehingga menjeda permintaan secara merata membantu lebih daripada jeda panjang.
• concurrency: terlalu banyak permintaan yang sedang berjalan sekaligus. Tunggu hingga yang sebelumnya selesai. Ini umum terjadi dengan streaming, di mana setiap permintaan berlangsung selama seluruh generasi.
• Beban berlebih sementara: juga 429, dengan header Retry-After: 5. Ini bukan kesalahan Anda dan tidak terkait dengan batas kunci Anda. Tunggu 5 detik yang dinyatakan dan coba lagi.

Permintaan yang gagal tidak dikenakan biaya, sehingga loop retry hanya memerlukan biaya satu permintaan yang akhirnya berhasil. Respons juga membawa X-RateLimit-Limit-Requests dan X-RateLimit-Limit-Concurrency sehingga klien Anda dapat membaca batas atasnya sendiri daripada menuliskannya langsung di kode (hardcode), plus X-Balance-USD untuk kredit yang tersisa dan X-Request-Id, yang harus Anda log dan kutip jika menghubungi dukungan.

Matematika throughput: mengapa 300 per menit sulit dicapai

Kedua batas berinteraksi. Dengan 8 slot konkuren, yang paling banyak dapat Anda selesaikan per menit adalah 8 x 60 dibagi dengan durasi rata-rata permintaan dalam detik. Untuk benar-benar mencapai 300 permintaan per menit, Anda memerlukan permintaan yang selesai dalam 8 x 60 / 300 = 1,6 detik rata-rata. Permintaan yang lebih lambat dibatasi oleh konkurensi terlebih dahulu.

Ini adalah batas aritmatika untuk waktu permintaan hipotetis, bukan pengukuran layanan kami; ukur permintaan Anda sendiri. Pelajaran utamanya adalah generasi kreatif panjang selama 20 detik pada kunci penuh mencapai batas atas 24 permintaan per menit, jauh di bawah 300 yang diizinkan. Jika Anda membutuhkan throughput lebih tinggi, perpendek balasan dengan max_tokens atau minta teks lebih sedikit per panggilan daripada berharap batas permintaan yang lebih tinggi.

Klien yang menangani ketiga kasus

Klien Python ini membatasi konkurensinya sendiri dengan semaphore, membaca Retry-After saat ada, dan mundur dengan jitter kecil jika tidak ada. Ini menggunakan paket openai resmi.

Copyimport random
import threading
import time
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI, RateLimitError

client = OpenAI(
    base_url="https://api.groknsfw.top/v1",
    api_key="YOUR_KEY",
    max_retries=0,            # we handle retries ourselves
)

slots = threading.BoundedSemaphore(8)   # use 2 on the trial key

def ask(prompt, tries=6):
    for attempt in range(tries):
        with slots:
            try:
                r = client.chat.completions.create(
                    model="uncensored",
                    messages=[{"role": "user", "content": prompt}],
                    max_tokens=400,
                )
                return r.choices[0].message.content
            except RateLimitError as e:
                wait = e.response.headers.get("retry-after")
                body = e.response.text
        # sleep outside the slot so others can proceed
        delay = float(wait) if wait else min(2 ** attempt, 30)
        if "rate_limited" in body:
            delay = max(delay, 5)
        time.sleep(delay + random.random())
    raise RuntimeError("still rate limited after retries")

with ThreadPoolExecutor(max_workers=8) as pool:
    results = list(pool.map(ask, ["Write one line about the sea."] * 20))
print(len(results))

Ide yang sama di Node adalah antrean kecil yang mengizinkan paling banyak 8 promise yang tertunda, dan pemeriksaan curl di bawah ini mencetak header batas sehingga Anda dapat mengkonfirmasi batas atas kunci Anda:

Copycurl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
  -H "Authorization: Bearer YOUR_KEY" | grep -i "x-"

Streaming, prompt panjang dan konteks

Permintaan streaming dengan stream: true memegang slot konkurensinya hingga peristiwa terakhir tiba. Itu berarti pembaca yang lambat dihitung terhadap Anda: jika kode Anda jeda saat menangani setiap bagian, slot tetap sibuk. Konsumsi stream segera.

Prompt panjang berinteraksi dengan batas dalam dua cara. Pertama, mereka membutuhkan lebih banyak waktu untuk diproses, sehingga menurunkan throughput Anda dengan rumus di atas. Kedua, mereka harus muat di jendela 100.000 token bersama dengan balasan, jadi jaga margin. Memangkas putaran obrolan lama membantu kedua masalah, dan pemangkasan yang sama mengurangi tagihan Anda: pada $0,15 per 1M token input, riwayat 20.000 token berharga $0,003 setiap kali Anda mengirimkannya kembali.

Detail format permintaan ada di panduan memulai cepat, dan tarif ada di halaman harga.

Menunjukkan batas kepada pengguna Anda sendiri

Batas laju juga merupakan keputusan produk. Jika aplikasi Anda berada di antara pengguna akhir dan API, 429 mentah seharusnya tidak pernah mencapai mereka. Putuskan sebelumnya apa yang akan mereka lihat.

• Untuk aplikasi chat, tampilkan status "menulis" singkat dan antri pesan. Jeda beberapa detik tidak terlihat oleh sebagian besar pengguna jika ada sesuatu yang terjadi di layar.
• Untuk alat batch, tampilkan kemajuan sebagai hitungan item yang selesai dan biarkan pekerjaan berjalan di latar belakang. Retry bersifat internal dan seharusnya tidak muncul sebagai error.
• Untuk deployment bersama, berikan setiap pengguna kuota kecil di kode Anda sendiri sehingga satu pengguna berat tidak dapat mengambil semua 8 slot dari pengguna lain.

Log tiga hal untuk setiap kegagalan: X-Request-Id, kode error, dan berapa banyak permintaan yang sedang berjalan di aplikasi Anda pada saat itu. Dengan itu, Anda dapat membedakan klien yang berperilaku buruk dari beban nyata dalam beberapa menit. Jika masalah tampaknya berasal dari sisi server, ID permintaan adalah apa yang dukungan akan minta terlebih dahulu.

Akhirnya, uji jalur kegagalan secara sengaja. Jalankan klien Anda dengan semaphore yang sengaja rendah dan kemudian dengan yang tinggi, lalu perhatikan apa yang ditunjukkan oleh log. Loop retry yang belum pernah terjadi adalah loop retry yang tidak dapat Anda percayai. Kunci uji coba adalah tempat yang nyaman untuk ini, karena dengan hanya 2 permintaan paralel, mudah untuk memicu error concurrency dengan skrip pendek dan melihat bagaimana kode Anda bereaksi, dengan biaya beberapa persepuluh sen per permintaan.

Kesalahan umum

Beberapa pola menyebabkan sebagian besar masalah 429 yang dilaporkan orang.

1. Melakukan retry segera. Loop yang mengirim ulang setiap kegagalan mengubah satu momen melebihi batas menjadi badai. Tunggu, tambahkan jitter, dan batasi jumlah percobaan.
2. Melakukan percobaan ulang untuk semuanya. Hanya kesalahan 429 dan kesalahan server sementara yang layak untuk percobaan ulang. Permintaan yang salah format atau kunci yang salah akan gagal dengan cara yang sama setiap saat.
3. Melupakan streaming dalam penghitungan. Sepuluh jendela obrolan terbuka pada kunci penuh dapat menjadi sepuluh streaming, dan itu dua slot lebih banyak dari 8 slot.
4. Tidak mengatur batas waktu. Koneksi yang macet menjaga slot tetap sibuk. Berikan setiap permintaan batas waktu yang wajar di klien HTTP Anda.
5. Merancang berdasarkan rata-rata. Lalu lintas datang dalam gelombang. Rencanakan untuk menit tersibuk Anda, bukan rata-rata harian Anda.

Merencanakan kapasitas sebelum Anda meluncurkan

Kerjakan secara terbalik dari puncak Anda. Jika Anda mengharapkan 30 pengguna mengobrol secara bersamaan dan setiap balasan streaming selama sekitar 15 detik, Anda membutuhkan 30 slot pada saat mereka semua mengirim, dan kunci penuh memiliki 8. Antrikan sisanya di aplikasi Anda sendiri, tampilkan waktu tunggu singkat, dan proses mereka saat slot tersedia. Dengan 8 slot dan balasan 15 detik, Anda dapat menyelesaikan 8 x 60 / 15 = 32 balasan per menit.

Untuk pekerjaan batch, jalankan kumpulan pekerja tetap yang sama dengan batas konkurensi Anda dan biarkan logika percobaan ulang menangani kelebihan beban sesekali. Daripada mengatasi batas, buat antrian: ini memberikan perilaku yang dapat diprediksi dan memungkinkan Anda menampilkan waktu tunggu nyata kepada pengguna Anda.

Panduan lainnya

• API Grok Tanpa Sensor: Panduan Integrasi LLM NSFW