Groq API Hız Limiti ve 429 Sınırlarımızın Çalışma Şekli

Limitlerin hangi hizmete ait olduğu

İsimler kolayca karıştırılır. Groq, modelleri kendi donanımında barındıran bir şirkettir. Grok ise xAI'dan gelen model ailesidir. Bu site bunların hiçbiri değildir: bağımsız bir sağlayıcı tarafından işletilen tek bir açık ağırlıklı model (model ID uncensored) için OpenAI uyumlu bir API'dir. Bu nedenle, groq API hız limiti ile ilgili olarak (örneğin belirli bir planda dakika başına istek veya token sayısı), Groq'un konsolunu veya dokümantasyonunu açın ve hesabınız için sayıları okuyun. Sayılar değişir, ben tahmin etmem.

Aşağıdakiler API'miz için doğrudur ve alışkanlıklar herhangi bir sağlayıcıya aktarılır: limit başlıklarına saygı gösterin, yalnızca doğru hatalarda yeniden deneyin ve sunucu sizin için yapmadan önce kendi eşzamanlılığınızı sınırlandırın. Bir Grok NSFW kurulumu için buraya geldiyseniz, entegrasyon kılavuzumuz çevresindeki hataları da kapsar.

Limitlere genel bakış

Bunların ikisi sıkı anlamda hız limitleridir, dakika başına istekler ve eşzamanlılık. Diğer ikisi tek bir istekte boyut limitleridir ve hız limitlerinden bağımsızdırlar. 90.000 token'lık bir prompt içeren bir istek, dakikada 300'e karşı bir istek olarak sayılır, tek satırlık bir prompt ile aynıdır, ancak daha uzun sürer ve slotunu daha uzun süre tutar.

$0.50 deneme kredisi, kayıttan sonra API anahtarı sayfasında tek tıkla alınır ve deneme limitlerini kullanır. Tam anahtar limitleri, bakiye yükledikten sonra geçerli olur.

Üç 429 türü

Tüm limit hataları HTTP 429 olarak gelir, ancak farklı anlamlara sahiptirler ve farklı tepkiler gerektirirler.

• rate_limited: dakikadaki istek izninizden daha fazlasını gönderdiniz. Hızınızı azaltın; pencere bir dakikalık olduğundan, istekleri eşit aralıklarla dağıtmak uzun bir beklemeden daha etkilidir.
• concurrency: aynı anda çok fazla istek işlenmekteydi. Daha önce birinin bitmesini bekleyin. Bu, her istek tüm üretim süresince devam ettiği için akış ile yaygındır.
• Geçici aşırı yüklenme: bu da bir 429'dur ve Retry-After: 5 başlığı taşır. Bu sizin hatanız değildir ve anahtarınızın limitleriyle ilişkili değildir. Belirtilen 5 saniyeyi bekleyin ve yeniden deneyin.

Başarısız istekler ücretlendirilmez, bu nedenle bir yeniden deneme döngüsü yalnızca nihai olarak başarılı olan isteğin maliyetine sahiptir. Yanıtlar ayrıca X-RateLimit-Limit-Requests ve X-RateLimit-Limit-Concurrency taşır, böylece istemciniz kendi tavanlarını okuyabilir ve bunları sabit kodlamak zorunda kalmaz; ayrıca kalan kredi için X-Balance-USD ve destek ile iletişime geçerseniz loglamanız ve belirtmeniz gereken X-Request-Id de gelir.

Verimlilik matematiği: dakikada 300'e ulaşmanın zor olmasının nedeni

İki limit etkileşim halindedir. 8 eşzamanlı slot ile, dakika başına tamamlayabileceğiniz maksimum istek sayısı, 8 x 60 değerinin bir isteğin saniye cinsinden ortalama süresine bölünmesiyle bulunur. Dakikada 300 isteye gerçekten ulaşmak için, ortalama olarak 8 x 60 / 300 = 1,6 saniye içinde tamamlanan isteklere ihtiyacınız vardır. Daha yavaş istekler önce eşzamanlılıkla sınırlanır.

Bunlar varsayılan bir istek süresi için aritmetik tavanlardır, hizmetimizin ölçümleri değildir; kendi isteklerinizi zamanlayın. Çıkarım şudur ki, tam bir anahtarla 20 saniyelik uzun bir yaratıcı üretim, dakikada 24 istekle sınırlıdır, izin verilen 300'ün çok altındadır. Daha fazla aktarım hızına ihtiyacınız varsa, max_tokens ile yanıtları kısaltın veya her çağrıda daha az metin isteyin; daha yüksek bir istek limiti ummayın.

Üç durumu da yöneten bir istemci

Bu Python istemcisi, kendi eşzamanlılığını bir semaforla sınırlar, mevcut olduğunda Retry-After okur ve aksi takdirde küçük bir jitter ile geri çekilme (backoff) uygular. Resmi openai paketini kullanır.

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))

Node'daki aynı fikir, en fazla 8 bekleyen promise'e izin veren küçük bir kuyruktur ve aşağıdaki curl kontrolü, anahtarınızın tavanlarını onaylayabilmeniz için limit başlıklarını yazdırır:

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

Akış, uzun istemler ve bağlam

stream: true ile bir akış isteği, son olay gelene kadar eşzamanlılık slotunu tutar. Bu, yavaş bir okuyucunun sizin aleyhinize sayıldığı anlamına gelir: kodunuz her parçayı işlerken duraklatırsa, slot meşgul kalır. Akışı hızla tüketin.

Uzun istemler limitlerle iki şekilde etkileşime girer. Birincisi, işlemek için daha fazla zaman alırlar, bu da yukarıdaki formüle göre verimliliğinizi düşürür. İkincisi, yanıtla birlikte 100.000 token'lık pencereye sığmalıdır, bu yüzden bir marj bırakın. Eski sohbet turlarını kısaltmak her iki soruna da yardımcı olur ve aynı kısaltma faturanızı da düşürür: 1M girdi token başına $0.15 ile, 20.000 token'lık bir geçmiş, her gönderdiğinizde $0.003 maliyetine sahiptir.

İstek formatının ayrıntıları hızlı başlangıç sayfasında yer alır ve fiyatlar fiyatlandırma sayfasında bulunur.

Limitleri kendi kullanıcılarınıza gösterme

Bir hız limiti aynı zamanda bir ürün kararıdır. Uygulamanız son kullanıcılar ile API arasında duruyorsa, ham bir 429 onlara asla ulaşmamalıdır. Onlara ne gösterileceğini önceden belirleyin.

• Sohbet uygulamaları için, kısa bir "yazıyor" durumu gösterin ve mesajı kuyruğa alın. Ekran üzerinde bir şeyler oluyorsa, birkaç saniyelik bir bekleme çoğu kullanıcı için görünmez.
• Toplu araçlar için, tamamlanan öğelerin sayısı olarak ilerleme gösterin ve işi arka planda çalışmaya bırakın. Yeniden denemeler dahili olmalı ve hata olarak görünmemelidir.
• Paylaşılan dağıtımlar için, tek bir ağır kullanıcının diğerlerinden tüm 8 slotu alamaması için kendi kodunuzda her kullanıcıya küçük bir kullanıcı başı kota tanımlayın.

Her hata için üç şeyi günlüğe kaydedin: X-Request-Id, hata kodu ve uygulamanızın o anda aynı anda işlenen isteklerinin sayısı. Bunlarla, kötü davranan bir istemciyi gerçek yükten birkaç dakika içinde ayırt edebilirsiniz. Bir sorun sunucu tarafında gibi görünüyorsa, istek ID'si destek'nin ilk soracağı şeydir.

Son olarak, hata yolunu kasıtlı olarak test edin. İstemcinizi kasıtlı olarak düşük bir semafor ve ardından yüksek bir semafor ile çalıştırın ve günlüklerin ne gösterdiğine bakın. Daha önce tetiklenmemiş bir yeniden deneme döngüsü, güvenebileceğiniz bir döngü değildir. Deneme anahtarı bunun için uygun bir yerdir, çünkü yalnızca 2 eşzamanlı istekle, kısa bir betikle concurrency hatasını almanız ve kodunuzun nasıl tepki verdiğini görmeniz, istek başına kuruşun birkaç onda biri kadar tutar.

Yaygın hatalar

İnsanların bildirdiği 429 sorunlarının çoğuna neden olan birkaç kalıp vardır.

1. Anında yeniden deneme. Her başarısızlıkta yeniden gönderen bir döngü, bir limit aşımı anını bir fırtınaya dönüştürür. Bekleyin, jitter ekleyin ve deneme sayısını sınırlandırın.
2. Her şeyi yeniden deneme. Yalnızca 429 ve geçici sunucu hataları bir yeniden denemeye layıktır. Bozuk bir istek veya yanlış bir anahtar her zaman aynı şekilde başarısız olur.
3. Akışları sayımdan unutmak. Tam anahtar üzerinde açık on sohbet penceresi on akış olabilir ve bu, 8 slottan iki fazla demektir.
4. Zaman aşımı ayarlamamak. Asılı kalan bir bağlantı bir slotu meşgul tutar. HTTP istemcinizde her istek için makul bir zaman aşımı verin.
5. Ortalama için boyutlandırma. Trafik patlamalar halinde gelir. Günlük ortalamanıza değil, en yoğun dakikanıza göre plan yapın.

Lansmandan önce kapasite planlaması

Zirvenizden geriye doğru çalışın. Aynı anda 30 kullanıcının sohbet edeceğini ve her yanıtın yaklaşık 15 saniye akışacağını öngörürseniz, hepsi aynı anda gönderdiğinde 30 slota ihtiyacınız vardır ve tam anahtarın 8'i vardır. Geri kalanını kendi uygulamanızda kuyruğa alın, kısa bir bekleme gösterin ve slotlar boşaldıkça işleyin. 8 slot ve 15 saniyelik yanıtlarla dakikada 8 x 60 / 15 = 32 yanıt tamamlayabilirsiniz.

Toplu işler için, eşzamanlılık limitinize eşit sabit bir worker havuzu çalıştırın ve nadir aşırı yüklenmeleri yeniden deneme mantığına bırakın. Limitlerin etrafından dolaşmak yerine kuyruk oluşturun: bu, öngörülebilir davranış sağlar ve kullanıcılarınıza gerçek bekleme sürelerini göstermenize olanak tanır.

Daha fazla kılavuz

• Sansürsüz Grok API: NSFW LLM Entegrasyon Kılavuzu