Groq, inferencja na własnym układzie LPU

Groq, inferencja na własnym układzie LPU

Groq to dostawca inferencji, który zamiast kart graficznych używa własnego układu scalonego o nazwie LPU, czyli Language Processing Unit. Skutek jest jeden i mierzalny: modele o otwartych wagach odpowiadają szybciej. Dokumentacja podaje około tysiąca tokenów na sekundę dla openai/gpt-oss-20b i około pięciuset dla openai/gpt-oss-120b.

Czym jest Groq, a czym nie jest

Zanim cokolwiek zainstalujesz, trzeba rozbroić dwie pomyłki nazewnicze, które kosztują ludzi realny czas.

Pierwsza to Grok. Grok to rodzina modeli firmy xAI. Groq to inna firma, inny produkt i inny rodzaj działalności: xAI trenuje własne modele, Groq udostępnia cudze modele na własnym sprzęcie. Nazwy różnią się jedną literą, obie pojawiają się w tych samych rozmowach o modelach językowych, więc pomyłka jest częsta i warto ją wyłapać wcześnie, zanim trafi do dokumentacji projektu albo do umowy.

Druga pomyłka mieszka w rejestrze npm. Pakiet groq w wersji 6.10.1, na licencji MIT, opisuje się jako „Tagged template literal for Sanity.io GROQ-queries" i nie ma z Groq nic wspólnego. To język zapytań platformy Sanity. Oficjalna biblioteka klienta nazywa się groq-sdk. W Pythonie jest odwrotnie: tam pip install groq daje właśnie klienta Groq, bo kolizji nie ma. Instalacja npm install groq zamiast groq-sdk kończy się importem, który nigdy nie zadziała, a komunikat błędu nie podpowie dlaczego.

Groq nie jest laboratorium modeli. Nie trenuje tego, co serwuje. openai/gpt-oss-120b i openai/gpt-oss-20b pochodzą z OpenAI, qwen/qwen3.6-27b od Alibaby, whisper-large-v3 również z OpenAI, modele Orpheus od Canopy Labs, a minimaxai/minimax-m2.7 od MiniMax. Groq dokłada do tego sprzęt, warstwę wykonawczą i API.

Jedna rzecz jest własna: systemy groq/compound i groq/compound-mini. To nie modele, tylko złożenia modeli o otwartych wagach z wbudowanymi narzędziami, wyszukiwaniem w sieci i wykonywaniem kodu, wywoływanymi automatycznie w zależności od pytania. Oba mają około 450 tokenów na sekundę, okno kontekstu 131 072 tokenów i limit 8 192 tokenów odpowiedzi, przy czym w tabeli modeli nie mają podanej stawki za milion tokenów.

Prędkość jako parametr projektowy

Prędkość generowania łatwo potraktować jako miłą właściwość, coś w rodzaju krótszego paska postępu. W praktyce przesuwa granicę tego, co da się w ogóle zbudować, i robi to na dwa sposoby.

Pierwszy dotyczy agentów. Zadanie agentowe to pętla: model generuje, wywołuje narzędzie, dostaje wynik, generuje dalej. Czas całości to suma kroków, więc mnoży się razem z ich liczbą. Agent o dziesięciu krokach, w którym każdy krok generuje osiemset tokenów, przy stu tokenach na sekundę spędza na samym generowaniu około osiemdziesięciu sekund. Przy pięciuset schodzi do szesnastu. To ta sama pętla, ale pierwsza wersja nadaje się do zadania w tle, a druga do interakcji, w której człowiek czeka przy ekranie. Rachunek jest ilustracyjny, bo prawdziwe liczby zależą od Twoich promptów, natomiast proporcja nie zależy od niczego.

Drugi dotyczy odpowiedzi na żywo. Transkrypcja w Whisperze rozliczana za godzinę nagrania, klasyfikacja zgłoszenia w ścieżce żądania HTTP zamiast w kolejce, przeredagowanie wyników wyszukiwania, zanim trafią do przeglądarki. Wszędzie tam decyzja brzmi „stać nas na wywołanie modelu wewnątrz żądania czy nie" i odpowiedź zmienia się razem z opóźnieniem.

Co do mechanizmu, dokumentacja Groq jest oszczędna. Opisuje kwantyzację o nazwie TruePoint Numerics, która obniża precyzję tylko tam, gdzie nie wpływa to na dokładność, i odsyła do wpisu na blogu o budowie LPU. Reszta szczegółów architektury jest po stronie dostawcy i nie da się jej niezależnie sprawdzić z zewnątrz.

Prędkość nie naprawia jednak trzech rzeczy i lepiej wiedzieć o nich zawczasu. Nie naprawia jakości modelu, bo szybki model słabszy nie zastąpi wolniejszego mocniejszego w zadaniu, które wymaga rozumowania. Nie naprawia opóźnienia całościowego, bo podawane tokeny na sekundę opisują generowanie, a domyślna warstwa on_demand według dokumentacji dopuszcza sporadyczne oczekiwanie w kolejce w godzinach szczytu. Nie obejmuje też długich promptów: gwarancja opóźnień w planie Enterprise wymaga, żeby niebuforowany kontekst mieścił się poniżej 8 192 tokenów, więc zadania z dużym wejściem wypadają poza nią nawet po podpisaniu umowy.

Katalog modeli i stawki

Tu leży główne ograniczenie i trzeba je zobaczyć w całości, bo katalog jest znacznie węższy, niż sugeruje kategoria „dostawca inferencji".

Produkcyjnych modeli tekstowych są dokładnie dwa i oba to gpt-oss. Do tego dochodzą dwa warianty Whisper, rozliczane za godzinę nagrania, oraz dwa systemy Compound. Wszystko pozostałe siedzi w podglądzie, który dokumentacja opisuje jako przeznaczony wyłącznie do ewaluacji i możliwy do wycofania z krótkim wyprzedzeniem, albo jest oznaczone jako Enterprise z ceną „Contact Sales", tak jak minimaxai/minimax-m2.7 z oknem 196 608 tokenów.

Historia wycofań mówi więcej niż sam katalog. W ciągu sześciu miesięcy platforma zamknęła cztery rundy modeli: meta-llama/llama-4-maverick-17b-128e-instruct 9 marca 2026, moonshotai/kimi-k2-instruct-0905 15 kwietnia, qwen/qwen3-32b razem z meta-llama/llama-4-scout-17b-16e-instruct 17 lipca, a llama-3.1-8b-instant i llama-3.3-70b-versatile 16 sierpnia. W każdej rundzie zalecanym zamiennikiem był gpt-oss. Wycofania obejmują plan darmowy i deweloperski, natomiast klienci Enterprise z umową na zadeklarowany poziom wydatków są z nich wyłączeni, co samo w sobie jest informacją o tym, jak wygląda stabilność bez umowy.

Skutek dla Twojego kodu jest konkretny. Identyfikator modelu trzymaj w konfiguracji, nie w kodzie, i sprawdzaj stronę wycofań przed każdym większym wydaniem. Powiadomienia idą mailem na adres organizacji, więc jeśli konto założył ktoś, kto zmienił zespół, informacja nie dotrze.

Warto dodać rzecz, która pokazuje, jak szybko ten katalog się zmienia. W chwili pisania strony dokumentacji poświęcone trybowi wsadowemu, warstwie Flex i warstwie Performance nadal wymieniają llama-3.3-70b-versatile oraz llama-3.1-8b-instant, choć oba zostały wyłączone 16 sierpnia 2026. Przykłady z dokumentacji potrafią więc zwrócić błąd przy przekopiowaniu bez zmiany identyfikatora.

Wersje, licencje i to, co naprawdę jest otwarte

Biblioteki klienckie są otwarte i sprawdzenie licencji z trzech źródeł nie ujawnia tu żadnej rozbieżności, co po serii projektów, w których ujawnia, jest przyjemną odmianą.

Pakiet groq-sdk w rejestrze npm ma wersję 1.5.0 i pole license ustawione na Apache-2.0. Rozpakowana paczka zawiera plik LICENSE z pełnym tekstem Apache License 2.0 i notą „Copyright 2026 Groq". Repozytorium groq/groq-typescript ma ten sam plik, a interfejs programistyczny GitHuba raportuje dla niego Apache-2.0. Po stronie Pythona jest identycznie: pakiet groq w wersji 1.6.0 na PyPI, licencja Apache 2.0 w metadanych, ten sam plik w archiwum źródłowym i w repozytorium groq/groq-python. Trzy źródła, jedna odpowiedź.

Skala projektów jest niewielka i pasuje do tego, czym one są, czyli generowanymi bibliotekami klienckimi. Repozytorium Pythona ma około 613 gwiazdek, 61 rozgałęzień i trzy otwarte zgłoszenia. TypeScriptowe ma około 264 gwiazdek, 35 rozgałęzień i pięć zgłoszeń. Żadne nie jest zarchiwizowane, oba miały zmiany 20 sierpnia 2026. Klient TypeScriptowy nie ma zależności produkcyjnych. Pythonowy wymaga wersji języka co najmniej 3.10 oraz pakietów anyio, distro, httpx, pydantic, sniffio i typing-extensions.

Tu kończy się część otwarta i zaczyna nieporozumienie, które w rozmowach o Groq wraca najczęściej. Licencja Apache na kliencie nie mówi nic o usłudze. Sam układ LPU, warstwa wykonawcza i cała platforma są zamknięte, a jedyną drogą do tej prędkości jest konto u Groq. Nie ma wariantu do uruchomienia u siebie.

Osobno stoją licencje samych wag, które należą do autorów modeli, nie do Groq. openai/gpt-oss-120b i openai/gpt-oss-20b są na Hugging Face oznaczone jako Apache 2.0, podobnie qwen/qwen3.6-27b. Modele Meta, obecne na platformie do sierpnia 2026, mają własną licencję społecznościową, która nie jest licencją otwartego oprogramowania w rozumieniu Open Source Initiative i nakłada warunki na sposób użycia. Otwarte wagi i otwarte oprogramowanie to dwie różne rzeczy, a licencję sprawdza się na karcie modelu, nie u dostawcy inferencji. Więcej o tym rozróżnieniu jest w tekstach o modelach Meta Llama i o Hugging Face.

Ryzyko przywiązania do dostawcy jest tu asymetryczne i to raczej dobra wiadomość. Kształt API jest zgodny z OpenAI, więc odejście to zmiana adresu bazowego i klucza. Trudniejsze jest to, że identyfikatory modeli są specyficzne dla Groq, a wynik działania aplikacji zależy od prędkości, której gdzie indziej możesz nie dostać. Przenosisz kod bez tarcia, przenosisz charakterystykę czasową znacznie gorzej.

Pierwsze wywołanie i zgodność z OpenAI

Instalacja i pierwsze wywołanie zajmują dwie minuty. Klucz generuje się w konsoli i trafia do zmiennej środowiskowej.

pip install groq
export GROQ_API_KEY=gsk_...

# w projekcie w Node uważaj na nazwę pakietu
npm install groq-sdk

Klient własny Groq wygląda tak, jak każdy klient tego kształtu. Parametr service_tier jest tu ważniejszy niż zwykle i wracam do niego w sekcji o limitach.

import os
from groq import Groq

client = Groq(api_key=os.environ["GROQ_API_KEY"])

odpowiedz = client.chat.completions.create(
    model="openai/gpt-oss-120b",
    service_tier="auto",
    max_completion_tokens=4096,
    messages=[
        {"role": "system", "content": "Odpowiadasz zwiezle, po polsku."},
        {"role": "user", "content": "Sklasyfikuj zgloszenie i podaj priorytet."},
    ],
)

print(odpowiedz.choices[0].message.content)
print(odpowiedz.usage.prompt_tokens, odpowiedz.usage.completion_tokens)

Istniejący kod napisany pod OpenAI przenosi się przez podmianę adresu bazowego. Nie trzeba wymieniać biblioteki.

import os
import openai

client = openai.OpenAI(
    base_url="https://api.groq.com/openai/v1",
    api_key=os.environ["GROQ_API_KEY"],
)

strumien = client.chat.completions.create(
    model="openai/gpt-oss-20b",
    messages=[{"role": "user", "content": "Wypisz piec ryzyk tej migracji."}],
    stream=True,
)

for fragment in strumien:
    if fragment.choices[0].delta.content:
        print(fragment.choices[0].delta.content, end="")

Zgodność jest wysoka, ale nie pełna, i dokumentacja wymienia braki wprost. Pola logprobs, logit_bias, top_logprobs oraz messages[].name zwracają błąd 400. Parametr N, jeśli go podasz, musi być równy jeden. Wartość temperature ustawiona na zero jest zamieniana na 1e-8. W transkrypcji i tłumaczeniu dźwięku nie działają formaty wyjścia vtt i srt. Obsługiwany jest natomiast interfejs Responses API, więc kod napisany pod nowszy kształt też ma dokąd trafić.

Wywoływanie narzędzi działa standardowo i to na nim najlepiej widać zysk z prędkości, bo każda tura pętli to osobne generowanie.

import Groq from 'groq-sdk'

const groq = new Groq({ apiKey: process.env.GROQ_API_KEY })

const tools = [
  {
    type: 'function' as const,
    function: {
      name: 'get_order_status',
      description: 'Wywolaj, gdy uzytkownik pyta o status zamowienia po numerze.',
      parameters: {
        type: 'object',
        properties: { orderId: { type: 'string' } },
        required: ['orderId']
      }
    }
  }
]

const completion = await groq.chat.completions.create({
  model: 'openai/gpt-oss-120b',
  service_tier: 'auto',
  tools,
  messages: [{ role: 'user', content: 'Co z zamowieniem 88213?' }]
})

const call = completion.choices[0].message.tool_calls?.[0]
console.log(call?.function.name, call?.function.arguments)

Limity, plany i rachunek za tokeny

Limity są mierzone w kilku jednostkach naraz i obowiązują na poziomie organizacji, nie pojedynczego klucza. Skróty to RPM i RPD dla żądań na minutę i na dobę, TPM i TPD dla tokenów, ASH i ASD dla sekund dźwięku, a w części organizacji dochodzą osobne ITPM i OTPM, czyli oddzielne limity tokenów wejścia i wyjścia na minutę. Pierwszy próg, który przekroczysz, decyduje, więc pięćdziesiąt krótkich żądań potrafi wyczerpać limit szybciej niż jedno długie.

Przy konkretnych liczbach dokumentacja mówi dwie różne rzeczy i uczciwiej jest podać obie. Tabela na stronie limitów, opisana w tekście jako podstawowe limity planu deweloperskiego, dla openai/gpt-oss-120b podaje 30 żądań na minutę, tysiąc na dobę, 8 tysięcy tokenów na minutę i 200 tysięcy na dobę. Tabela na stronie modeli, w kolumnie zatytułowanej wprost „RATE LIMITS (DEVELOPER PLAN)", dla tego samego modelu podaje 250 tysięcy tokenów na minutę i tysiąc żądań na minutę. Różnica jest ponad trzydziestokrotna i nie da się jej pogodzić z zewnątrz. Wiążące są wartości widoczne na stronie limitów Twojej organizacji w konsoli, a przy planowaniu wydajności traktuj niższy zestaw jako założenie ostrożne.

Plany układają się w trzy poziomy. Darmowy daje dostęp do API i do niższych limitów. Deweloperski, płatny, podnosi limity i odblokowuje dwie rzeczy niedostępne wcześniej: tryb wsadowy oraz warstwę Flex. Enterprise otwiera warstwę Performance i limity ustalane indywidualnie.

Warstwę wybiera się parametrem service_tier. Domyślna to on_demand, z prędkością LPU i sporadycznym oczekiwaniem w kolejce w szczycie. Warstwa flex jest dostępna tylko dla klientów płacących, daje dziesięciokrotnie wyższe limity przy tej samej stawce i płaci się za to inaczej: gdy zabraknie pojemności, żądanie kończy się szybko statusem 498 i błędem capacity_exceeded, więc obsługa ponawiania z losowym opóźnieniem jest tu obowiązkowa, a nie opcjonalna. Warstwa auto wybiera najlepszą dostępną w danej chwili.

Gwarancje przepustowości istnieją, ale wyłącznie w warstwie Performance i wyłącznie w planie Enterprise. Dokumentacja podaje SLA na dostępność 99,9 procent oraz gwarancję opóźnień na poziomie 99 procent, z zastrzeżeniem, że szczegóły określa umowa. Rozliczenie nie jest tam za token: kupuje się przydzieloną pojemność wejścia i wyjścia i płaci za nią, a ceny nie ma na stronie, tylko za kontaktem z działem sprzedaży. Do tego dochodzi wspomniany warunek kontekstu poniżej 8 192 tokenów bez buforowania. Na planie darmowym i deweloperskim żadnej gwarancji opóźnień nie ma.

Rachunek obniżają dwa mechanizmy i oba działają bez zmian w kodzie albo prawie bez zmian.

Buforowanie promptu włącza się samo, nie kosztuje nic dodatkowo i daje pięćdziesiąt procent zniżki na zbuforowane tokeny wejścia. Dla openai/gpt-oss-120b oznacza to 0,075 USD zamiast 0,15 USD za milion. Dopasowanie działa na prefiksie, więc statyczna część promptu, czyli instrukcja systemowa, definicje narzędzi i przykłady, musi stać na początku, a zmienna, czyli pytanie użytkownika, znaczniki czasu i identyfikatory sesji, na końcu. Bufor wygasa po dwóch godzinach bez użycia, obejmuje na razie tylko openai/gpt-oss-20b, openai/gpt-oss-120b i openai/gpt-oss-safeguard-20b, a trafienie nie jest gwarantowane. Zbuforowane tokeny nie liczą się do limitów, choć odejmowane są dopiero po przetworzeniu, więc przy wielu żądaniach równoległych limit nadal da się przekroczyć.

Tryb wsadowy daje pięćdziesiąt procent zniżki i nie dotyka limitów synchronicznych. Okno przetwarzania ustawia się od doby do siedmiu dni, przy czym dłuższe okno zwiększa szansę, że zadanie zdąży się wykonać, zamiast wygasnąć. Zniżki nie sumują się: wszystkie tokeny w partii rozliczane są po stawce wsadowej niezależnie od tego, czy trafiły w bufor. Tryb wsadowy nie przyjmuje też parametru service_tier.

{"custom_id": "zgloszenie-1", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "openai/gpt-oss-20b", "messages": [{"role": "user", "content": "Sklasyfikuj: klient nie moze sie zalogowac"}]}}
{"custom_id": "zgloszenie-2", "method": "POST", "url": "/v1/chat/completions", "body": {"model": "openai/gpt-oss-20b", "messages": [{"role": "user", "content": "Sklasyfikuj: faktura z bledna kwota"}]}}

Stan limitów widać w nagłówkach każdej odpowiedzi i to najprostszy sposób na wykrycie problemu, zanim zrobi się z niego awaria.

import httpx

odpowiedz = httpx.post(
    "https://api.groq.com/openai/v1/chat/completions",
    headers={"Authorization": f"Bearer {KLUCZ}"},
    json={
        "model": "openai/gpt-oss-120b",
        "service_tier": "flex",
        "messages": [{"role": "user", "content": tresc}],
    },
    timeout=60.0,
)

if odpowiedz.status_code == 429:
    czekaj = float(odpowiedz.headers.get("retry-after", "2"))
elif odpowiedz.status_code == 498:
    czekaj = 1.0

print(odpowiedz.headers.get("x-ratelimit-remaining-requests"))
print(odpowiedz.headers.get("x-ratelimit-remaining-tokens"))
print(odpowiedz.headers.get("x-ratelimit-reset-tokens"))

Nagłówek x-ratelimit-limit-requests zawsze odnosi się do żądań na dobę, a x-ratelimit-limit-tokens zawsze do tokenów na minutę, co jest niekonsekwentne i łatwo je źle odczytać. Nagłówek retry-after pojawia się tylko przy odpowiedzi 429, pozostałe są zawsze.

Groq a alternatywy

Wybór rozstrzyga się na jednym pytaniu: czy opóźnienie jest u Ciebie ograniczeniem produktowym. Jeśli tak, bo budujesz agenta o wielu krokach albo interfejs, w którym człowiek czeka, Groq daje coś, czego samą optymalizacją promptu nie osiągniesz. Jeśli nie, wąski katalog i cztery rundy wycofań w pół roku są ceną, której nie ma powodu płacić.

Rozsądny układ pośredni polega na tym, żeby nie wybierać. Warstwa pośrednicząca w rodzaju LiteLLM albo OpenRoutera pozwala trzymać Groq dla ścieżek wrażliwych na czas, a trudniejsze rozumowanie kierować do Claude czy innego mocniejszego modelu, bez rozsypywania kodu po dwóch bibliotekach. Do pracy lokalnej i danych, które nie mogą wyjść z firmy, zostaje Ollama, gdzie te same wagi gpt-oss uruchomisz u siebie, tyle że dużo wolniej.

Najbliższym konkurentem po stronie modeli o otwartych wagach jest Together AI, który stawia nie na własny sprzęt, lecz na szerokość katalogu i dokłada dostrajanie oraz wynajem klastrów. Przy tym samym modelu stawki bywają identyczne, więc różnicę robi to, czego szukasz: szybkości pojedynczego wywołania czy wyboru spośród setek modeli. Dwie rzeczy trzeba tam wiedzieć: nie ma planu darmowego, bo konto jest przedpłacone od pięciu dolarów, a licencja modelu zostaje po Twojej stronie i część pozycji z katalogu ma progi przychodowe, powyżej których potrzebna jest osobna umowa z autorem wag.

Typowe błędy

Pierwszy to npm install groq. Pakiet o tej nazwie należy do platformy Sanity i jest językiem zapytań, nie klientem API. Właściwa nazwa to groq-sdk.

Drugi to identyfikator modelu wpisany na stałe w kod. Przy czterech rundach wycofań w sześć miesięcy to kwestia czasu, kiedy wywołanie zacznie zwracać błąd. Trzymaj identyfikator w konfiguracji i sprawdzaj stronę wycofań przed wydaniem.

Trzeci to kopiowanie przykładów z dokumentacji bez czytania. Strony trybu wsadowego, warstwy Flex i warstwy Performance nadal wymieniają llama-3.3-70b-versatile oraz llama-3.1-8b-instant, wyłączone 16 sierpnia 2026.

Czwarty to używanie warstwy flex bez obsługi błędu 498. To nie jest zwykłe niepowodzenie sieciowe, tylko udokumentowane zachowanie przy braku pojemności, i bez ponawiania z losowym opóźnieniem zobaczysz je w każdym szczycie.

Piąty to zmienna treść na początku promptu. Znacznik czasu albo identyfikator sesji wstawiony przed instrukcją systemową unieważnia prefiks i buforowanie przestaje działać, bez żadnego komunikatu. Statyczne na początek, zmienne na koniec.

Szósty to planowanie wydajności na podstawie tabeli ze strony modeli. Podaje ona 250 tysięcy tokenów na minutę tam, gdzie strona limitów podaje 8 tysięcy dla tego samego planu. Wiążące są wartości w Twojej konsoli.

Siódmy to zakładanie, że deklarowane tokeny na sekundę są gwarancją. Bez planu Enterprise nie ma żadnego SLA, a i tam gwarancja opóźnień obejmuje wyłącznie prompty poniżej 8 192 tokenów bez buforowania.

Ósmy to liczenie na skumulowanie zniżek. Tokeny wysłane w partii rozliczane są po stawce wsadowej niezależnie od trafień w bufor, więc obie zniżki naraz nie zadziałają.

FAQ

Czy Groq to to samo co Grok od xAI?

Nie. Grok to rodzina modeli firmy xAI. Groq to dostawca inferencji, który nie trenuje modeli, tylko udostępnia cudze modele o otwartych wagach na własnym układzie LPU. Nazwy różnią się jedną literą i to jedyne, co je łączy.

Czy da się przenieść istniejący kod napisany pod OpenAI?

Tak, przez zmianę adresu bazowego na https://api.groq.com/openai/v1 i podmianę klucza. Wyjątki są wymienione w dokumentacji: pola logprobs, logit_bias, top_logprobs i messages[].name zwracają błąd 400, parametr N musi być równy jeden, temperature równa zeru zamieniana jest na 1e-8, a w dźwięku nie działają formaty vtt i srt.

Ile realnie kosztuje wywołanie?

Przy openai/gpt-oss-120b stawka to 0,15 USD za milion tokenów wejścia i 0,60 USD za milion wyjścia, przy openai/gpt-oss-20b odpowiednio 0,075 i 0,30 USD. Zbuforowane wejście kosztuje połowę. Tryb wsadowy zdejmuje połowę z całości, ale nie sumuje się z buforowaniem. Whisper rozliczany jest za godzinę nagrania, od 0,04 USD w wariancie turbo.

Czy Groq gwarantuje przepustowość i opóźnienia?

Tylko w warstwie Performance dostępnej w planie Enterprise, gdzie dokumentacja podaje SLA na dostępność 99,9 procent i gwarancję opóźnień na poziomie 99 procent, rozliczane jako przydzielona pojemność, nie za token. Obowiązuje przy tym warunek niebuforowanego kontekstu poniżej 8 192 tokenów. Na planie darmowym i deweloperskim gwarancji nie ma.

Co się stanie, gdy Groq wycofa model, którego używam?

Dostaniesz mail na adres organizacji i wpis na stronie wycofań z datą wyłączenia oraz zalecanym zamiennikiem. Po tej dacie żądania do starego identyfikatora zwracają błąd. Wycofania dotyczą planu darmowego i deweloperskiego, klienci Enterprise z umową na zadeklarowany poziom wydatków są z nich wyłączeni.

Czy plan darmowy wystarczy do produkcji?

Nie. Nie daje trybu wsadowego ani warstwy Flex, limity są niskie, a gwarancji żadnych. Nadaje się do prototypu i do sprawdzenia, czy prędkość faktycznie zmienia Twój przypadek użycia. Do produkcji potrzebny jest przynajmniej plan deweloperski.

Aktualne modele, stawki i limity opisuje dokumentacja Groq, historię wycofań strona deprecjacji, a kod bibliotek klienckich leży w repozytorium groq-python.