Replicate, modele uczenia maszynowego przez API

Replicate, modele uczenia maszynowego przez API

Replicate wystawia modele uczenia maszynowego jako zwykłe wywołania HTTP. Nie konfigurujesz sterowników CUDA i nie rezerwujesz kart graficznych: wysyłasz JSON, odbierasz obraz, tekst albo plik audio. Rachunek liczony jest jednak na dwa zupełnie różne sposoby i to jest najważniejsza rzecz do zrozumienia przed pierwszym wdrożeniem.

Co dokładnie kupujesz

Usługa sprzedaje trzy rzeczy naraz i mylenie ich ze sobą jest najczęstszym źródłem niespodzianek na fakturze.

Pierwsza to katalog modeli publicznych. Ktoś inny spakował model, opublikował go pod adresem w formacie właściciel/nazwa, a Ty uruchamiasz go jednym wywołaniem. Nie masz wpływu na sprzęt ani na kolejkę, bo dzielisz pulę maszyn z innymi klientami. Druga to modele prywatne. Pakujesz własny kod w obraz kontenera narzędziem Cog, wypychasz go na Replicate i dostajesz identyczny interfejs, ale na sprzęcie przypisanym tylko do Ciebie. Trzecia to deployments, czyli nakładka na jedno i drugie, dająca stały adres, wybór sprzętu oraz sterowanie skalowaniem przez pola min_instances i max_instances.

Interfejs programistyczny jest wspólny. Tworzysz predykcję przez POST /predictions, opcjonalnie podajesz adres webhooka, a wynik odbierasz przez odpytywanie, przez webhook albo strumieniem. Limity zapytań wynoszą 600 na minutę dla tworzenia predykcji i 3000 na minutę dla pozostałych punktów końcowych. Konta, którym przyznano kredyt bez podpiętej metody płatności, mają limit jednego zapytania na sekundę i maksymalnie sześciu na minutę, co w praktyce wyklucza jakiekolwiek testy obciążeniowe na darmowym koncie. Po przekroczeniu limitu dostajesz kod 429 z ciałem w rodzaju {"detail":"Request was throttled. Your rate limit resets in ~30s."}.

Biblioteka dla Pythona wygląda tak:

import replicate

output = replicate.run(
    "black-forest-labs/flux-schnell",
    input={"prompt": "mapa portu w stylu rysunku technicznego"},
    wait=30,
    use_file_output=True,
)

Parametr wait przyjmuje wartość logiczną albo liczbę sekund od 1 do 60. Przy True żądanie jest trzymane otwarte przez maksymalnie 60 sekund, a potem klient przechodzi na odpytywanie. Pozostałe parametry uznawane przez replicate.run i przez replicate.predictions.create to webhook, webhook_completed, webhook_events_filter, stream oraz file_encoding_strategy. Metoda predictions.create wymaga podania dokładnie jednego z argumentów model, version albo deployment, w przeciwnym razie zgłasza ValueError.

Dwa sposoby rozliczania, które dają inny rachunek

To jest sedno artykułu. Część modeli publicznych rozlicza się za czas pracy sprzętu, a część za jednostkę wyjścia: obraz, sekundę wideo, tysiąc tokenów. Przy tym samym zadaniu obie metody dają rachunki różniące się o rząd wielkości, a wybór między nimi nie należy do Ciebie, tylko wynika z tego, jak dany model został opublikowany.

Oto stawki za jednostkę wyjścia z cennika dostawcy na dzień 22 sierpnia 2026 roku:

Kolumna z przelicznikiem nie jest ozdobnikiem. Cennik podaje ceny w niejednorodnych jednostkach na jednej stronie: flux-schnell za tysiąc obrazów, flux-dev za pojedynczy obraz, a przy modelach językowych wejście liczone jest za milion tokenów, podczas gdy wyjście za tysiąc. Karta modelu claude-3.7-sonnet pokazuje obok siebie 0,015 USD i 3,00 USD, przez co wyjście wygląda na dwustukrotnie tańsze od wejścia. Po sprowadzeniu do wspólnej jednostki jest odwrotnie: 15 USD za milion tokenów wyjścia wobec 3 USD za milion tokenów wejścia, czyli wyjście kosztuje pięć razy więcej. Ta sama pułapka dotyczy deepseek-r1: 10 USD za milion wyjścia wobec 3,75 USD za milion wejścia.

Dokumentacja rozliczeń podaje przykład na modelu meta/meta-llama-3.1-405b-instruct: 8 tokenów wejścia kosztuje 0,0000760 USD, 43 tokeny wyjścia kosztują 0,0004085 USD, razem 51 tokenów za 0,0004845 USD. Arytmetyka się zgadza i w obie strony wychodzi 0,0000095 USD za token, czyli 9,50 USD za milion niezależnie od kierunku. To akurat rzadki przypadek, w którym wejście i wyjście mają tę samą cenę.

Cennik sprzętu i arytmetyka godzinowa

Drugi tryb rozliczenia jest prostszy do policzenia, bo mnożysz sekundy przez stawkę. Poniżej stawki z cennika, sprawdzone pod kątem zgodności ceny sekundowej z godzinową:

Każda para przeliczona przez 3600 sekund zgadza się co do grosza, więc dostawca nie stosuje tu żadnej ukrytej korekty. Dwie rzeczy w tej tabeli wymagają komentarza. Po pierwsze, gpu-h200 kosztuje dokładnie tyle samo co gpu-h100, mimo większej pamięci karty, ale jest dostępny wyłącznie w ramach umowy z zadeklarowanym poziomem wydatków. To samo dotyczy wszystkich wariantów wielokartowych powyżej dwóch układów. Po drugie, cennik nie podaje specyfikacji pamięci dla sprzętu z sekcji dodatkowej, więc nie warto zgadywać.

Policzmy teraz oba tryby na jednym zadaniu. Przyjmuję założenie, którego cennik nie potwierdza, bo zależy od konkretnego modelu: pojedyncze wygenerowanie obrazu zajmuje trzy sekundy na karcie H100. Przy tym założeniu tysiąc obrazów to 3000 sekund czasu aktywnego, czyli 4,58 USD. Ten sam tysiąc obrazów przez publiczny flux-schnell kosztuje 3,00 USD, a przez flux-1.1-pro już 40,00 USD.

Rachunek wygląda inaczej, gdy w grę wchodzi czas bezczynności. Instancja gpu-h100 utrzymywana przez całą dobę to 86400 sekund razy 0,001525 USD, czyli 131,76 USD dziennie. Jeśli obsługuje sto żądań dziennie po trzy sekundy, czas aktywny wynosi 300 sekund, czyli 0,46 USD, a resztę płacisz za maszynę czekającą na ruch. Te same sto obrazów przez publiczny flux-1.1-pro kosztuje 4,00 USD. Punkt zrównania dla mojego założenia o trzech sekundach wypada w okolicach 3294 obrazów dziennie, bo tyle jednostek po 0,04 USD daje 131,76 USD. Powyżej tego progu własna instancja zaczyna się opłacać, poniżej przepłacasz za bezczynność.

Zimny start, bezczynność i utrzymanie w gotowości

Cykl życia instancji dokumentacja dzieli na cztery stany: offline, setting up, active i idle. Setup obejmuje pobranie wag modelu i może trwać kilka sekund. Idle to okres kilku minut po ostatnim żądaniu, w którym instancja nie jest wygaszana, żeby uniknąć ponownej konfiguracji.

Kto płaci za który stan, zależy od rodzaju modelu i to jest reguła, którą trzeba zapamiętać dosłownie. Przy modelach publicznych płacisz wyłącznie za czas aktywny, a setup i bezczynność są darmowe. Cena bywa za to zapłacona inaczej: dzielisz kolejkę z innymi klientami, więc zdarzają się zimne starty i ograniczenia skalowania zależne od tego, jak innym akurat idzie ruch. Przy modelach prywatnych i przy deploymentach płacisz za cały czas, w którym instancja jest online, czyli za setup, za bezczynność i za pracę.

Wyjątkiem są tak zwane fast booting fine-tunes. To dostrojone modele uruchamiane na wspólnej puli sprzętu z modelem bazowym, rozliczane wyłącznie za czas aktywny niezależnie od tego, czy są publiczne czy prywatne. Dokumentacja podaje, że takie wersje są oznaczone na liście wersji modelu, ale nie definiuje warunków, po spełnieniu których model kwalifikuje się do tego trybu. To znaczy, że nie da się tego zaplanować z góry.

Utrzymanie modelu w gotowości robi się przez deployment z ustawionym min_instances. Struktura jest krótka:

{
  "name": "my-app-image-generator",
  "model": "some-org/some-model",
  "version": "da77bc59ee60423279fd632efb4795ab731d9e3ca9705ef3341091fb989b7eaf",
  "hardware": "gpu-t4",
  "min_instances": 1,
  "max_instances": 5
}

Wartość min_instances domyślnie wynosi zero, więc bez tego ustawienia model schodzi do zera i przy kolejnym żądaniu przechodzi pełny setup. Ustawienie jedynki eliminuje zimny start, ale przełącza Cię na rozliczenie dobowe opisane wyżej. Pole max_instances jest jedynym mechanizmem ograniczania maksymalnego wydatku, jaki dostawca udostępnia w konfiguracji wdrożenia.

Dokumentacja rozliczeń zawiera w tym miejscu sprzeczność, którą łatwo przeoczyć. Sekcja o nieudanych uruchomieniach zaczyna się od zdania, że dla wszystkich modeli nieudany przebieg nie jest naliczany, a dwa zdania dalej stwierdza, że dla modeli prywatnych i deploymentów nieudane oraz anulowane przebiegi są naliczane za czas aktywności instancji. Drugie zdanie unieważnia pierwsze. Przy modelach oficjalnych anulowanie też może być płatne. Jeśli budujesz kosztorys, licz według wariantu droższego.

Cog, czyli własny model w kontenerze

Cog to narzędzie do pakowania modelu w obraz kontenera z serwerem HTTP. Repozytorium replicate/cog ma plik LICENSE z pełnym tekstem licencji Apache 2.0, a wydanie 0.22.0 ukazało się 14 sierpnia 2026 roku, czyli osiem dni przed datą tego tekstu. Poprzednie wydanie 0.21.0 pochodzi z 16 czerwca 2026 roku, więc przerwa wyniosła 59 dni. Narzędzie jest rozwijane, w przeciwieństwie do bibliotek klienckich opisanych w następnej sekcji.

Odpowiedź na pytanie, czy wgranie modelu tutaj to ulica jednokierunkowa, brzmi: nie. Obraz zbudowany przez Cog jest zwykłym obrazem Dockera z serwerem nasłuchującym na porcie 5000, który wystawia POST /predictions, PUT /predictions/<prediction_id> oraz GET / zwracające adresy pozostałych punktów końcowych. Nagłówek Prefer: respond-async przełącza tryb na asynchroniczny, a Accept: text/event-stream na strumieniowanie zdarzeń. Pole image w cog.yaml domyślnie wskazuje na r8.im, czyli rejestr Replicate, ale dokumentacja wprost mówi, że może to być dowolny rejestr Dockera. Możesz więc zbudować obraz Cogiem i uruchomić go na własnym klastrze.

Plik konfiguracyjny ma trzy klucze najwyższego poziomu: build, image i run.

build:
  gpu: true
  python_version: "3.13"
  python_requirements: requirements.txt
  system_packages:
    - "ffmpeg"
    - "git"
image: "r8.im/twoja-nazwa/twoj-model"
run: "run.py:Runner"

Klucz build przyjmuje między innymi cuda, gpu, python_version, python_packages, python_requirements, sdk_version, system_packages oraz własne run z poleceniami powłoki. Pola python_packages i python_requirements wykluczają się wzajemnie. Warto zwrócić uwagę na zmianę nazewnictwa: wcześniejsze projekty używały klucza predict wskazującego na klasę Predictor, a dokumentacja wydania 0.22.0 oznacza go jako przestarzały i zaleca run wskazujące na klasę Runner. Stare nazwy nadal działają, ale Cog wypisuje ostrzeżenie przy wczytywaniu modelu.

Sam kod modelu wygląda tak:

from cog import BaseRunner, Path, Input
import torch

class Runner(BaseRunner):
    def setup(self):
        self.model = torch.load("weights.pth")

    def run(
        self,
        image: Path = Input(description="Image to enlarge"),
        scale: float = Input(description="Factor to scale image by", default=1.5),
    ) -> Path:
        return self.model(image)

Metoda setup jest opcjonalna i służy do wczytania wag, run jest wymagana. Od wersji 0.14.0 obie mogą być asynchroniczne, a od 0.21.0 dostępny jest dekorator @cog.concurrent(max=N) ustawiający maksymalną liczbę równoległych przebiegów. Przekroczenie limitu zwraca kod 409. Wartość max musi być literałem całkowitym, bo jest wypalana w obrazie na etapie budowania, a zmienna środowiskowa COG_MAX_CONCURRENCY pozwala ją nadpisać w czasie działania. Typy wejścia i wyjścia obejmują cog.Path, cog.Secret oraz własne klasy oparte na BaseModel. Instalacja na macOS sprowadza się do brew install replicate/tap/cog.

Jedna rzecz z zależności jest ciekawa. Pakiet cog w wersji 0.22.0 wymaga pakietu coglet w wersji co najmniej 0.22.0 i poniżej 1.0, a coglet opisuje siebie jako wysokowydajny serwer predykcji dla modeli Cog napisany w Rust. Właściwa pętla wykonawcza przeniosła się więc do osobnego komponentu.

Licencje i stan bibliotek klienckich

Licencję sprawdziłem z trzech źródeł osobno, bo tu znalazła się najciekawsza usterka w całym zestawie.

Plik LICENSE w repozytoriach replicate/cog, replicate/replicate-python i replicate/replicate-javascript zawiera pełny tekst Apache 2.0 i tu żadnych niespodzianek nie ma. Pakiet npm replicate deklaruje w rejestrze pole license o wartości Apache-2.0, a opublikowana paczka wersji 1.4.0 zawiera plik package/LICENSE oraz szesnaście plików JavaScript zajmujących około 192 kilobajtów, czyli jest tam realny kod, a nie atrapa. Zależności czasu wykonania brak, a pole engines wymaga Node w wersji co najmniej 18.

Rozjazd jest po stronie PyPI. Pole license w metadanych pakietu replicate nie zawiera identyfikatora licencji, tylko cały tekst Apache 2.0: 12921 znaków rozciągniętych w pliku METADATA od szóstej do dwieście ósmej linii, po czym dopiero zaczyna się nagłówek Project-URL. Pole license_expression jest puste, a wśród klasyfikatorów nie ma ani jednego zaczynającego się od License ::. Dokładnie ten sam błąd ma pakiet cog w wersji 0.22.0. Skutek jest praktyczny: automatyczny skaner licencji, który oczekuje krótkiego identyfikatora SPDX, dostanie w tym polu dwieście linii prozy prawniczej i albo zgłosi licencję jako nierozpoznaną, albo wpisze do raportu pierwszą linię tekstu. Sam plik licencyjny jest w porządku, leży pod replicate-1.0.7.dist-info/licenses/LICENSE, a w paczce siedzi dwadzieścia jeden modułów Pythona o łącznej objętości około 130 kilobajtów. Co ciekawe, pakiet coglet deklaruje Apache-2.0 poprawnie, więc jest to niedopatrzenie w konfiguracji dwóch projektów, a nie świadoma decyzja.

Poważniejszy problem dotyczy tempa wydań po stronie Pythona. Ostatnie stabilne wydanie pakietu replicate to 1.0.7 z 27 maja 2025 roku. Od tamtej pory ukazywały się wyłącznie wersje przedpremierowe: 1.1.0b1 z 9 czerwca 2025, 1.1.0b2 z 12 czerwca 2025, 1.1.0b3 z 26 sierpnia 2025, a równolegle cała linia 2.0.0 od 2.0.0a1 z 10 czerwca 2025 do 2.0.0b4 z 18 grudnia 2025. Od tamtego dnia nie ukazało się nic. Licząc od dzisiejszej daty to piętnaście miesięcy bez stabilnego wydania i osiem miesięcy bez jakiegokolwiek. Biblioteka dla JavaScriptu jest w niewiele lepszej sytuacji: 1.4.0 pochodzi z 17 listopada 2025, a znacznik alpha wskazuje na 2.0.0-alpha.74 z 18 grudnia 2025, czyli z tego samego dnia co ostatnia beta pythonowa.

Usługa działa, replicate.com odpowiada kodem 200, Cog dostaje wydania co kilka tygodni, ale dwa oficjalne SDK stoją. Jeśli budujesz na nich produkcję, przyjmij, że łatanie błędów w kliencie będzie po Twojej stronie, albo pisz bezpośrednio do interfejsu HTTP, który jest udokumentowany i stabilny.

Replicate a Modal, Hugging Face i własny vLLM

Różnica wobec Modala jest zasadnicza i nie sprowadza się do cennika. W Modalu piszesz własny kod w Pythonie i oznaczasz go dekoratorami, a dostawca zajmuje się zestawieniem środowiska. Rozliczenie jest tam wyłącznie za sekundę zasobu, więc nie ma odpowiednika stawki za obraz. W Replicate typowe użycie zaczyna się od cudzego modelu z katalogu, którego w ogóle nie piszesz, a wersję prywatną dodajesz dopiero wtedy, gdy katalog nie wystarcza. Jeśli Twoje zadanie to własna logika obliczeniowa, Modal pasuje lepiej. Jeśli to uruchomienie znanego modelu bez pisania kodu inferencji, Replicate wygrywa czasem wdrożenia.

Hugging Face to przede wszystkim miejsce, z którego bierzesz wagi i kod modelu. Replicate jest natomiast miejscem, w którym model już działa za adresem HTTP. Te dwa produkty często występują razem, bo model publiczny na Replicate zwykle pobiera wagi z Huba w metodzie setup. Jeśli zależy Ci na tym, żeby wagi zostały u Ciebie, samodzielne uruchomienie przez vLLM albo lokalnie przez Ollama daje pełną kontrolę i zerową zależność od cudzego cennika, kosztem tego, że utrzymanie sterowników, kolejki i skalowania spada na Ciebie. Dla porównania samych stawek za modele językowe przez API sprawdź Groq i OpenAI, a jeśli szukasz izolowanego środowiska do uruchamiania kodu generowanego przez model, to zupełnie inna kategoria opisana przy E2B.

Ryzyko przywiązania do dostawcy jest tu umiarkowane, ale nie zerowe. Format Cog i obraz kontenera są przenośne, licencja Apache 2.0 na to pozwala. Nieprzenośne są: konkretne wersje modeli publicznych opublikowane przez osoby trzecie, konfiguracja deploymentów i całe zaplecze skalowania. Odtworzenie tego u siebie jest wykonalne, ale nie jest kwestią jednego popołudnia.

Najbliższym krewnym Replicate w tym zestawieniu jest fal, który też daje katalog gotowych modeli i też miesza dwa sposoby rozliczania, ale skupia się na obrazie, wideo i dźwięku, a nie na modelach językowych. Różnica praktyczna leży gdzie indziej: fal ma osobny tryb kolejki z webhookiem, pomyślany pod zadania trwające minuty, co przy generowaniu wideo jest jedyną rozsądną drogą. Dwie wady po tamtej stronie: nie ma planu darmowego, bo rozliczenie jest przedpłacone, a klient dla JavaScriptu i klient dla Pythona mają dwie różne licencje, MIT i Apache 2.0, co komplikuje zestawienie licencji w projekcie używającym obu.

Typowe błędy

Porównywanie stawek bez sprowadzenia ich do wspólnej jednostki. Cennik miesza tysiące i miliony w obrębie jednej karty modelu, więc dopóki nie przeliczysz obu liczb na tę samą podstawę, porównanie nie ma sensu.

Zakładanie, że model prywatny jest tańszy od publicznego, bo nie ma marży za gotowe wyjście. Przy niskim i nieregularnym ruchu jest odwrotnie, bo płacisz za setup i bezczynność, których przy modelu publicznym nie płacisz wcale.

Ustawianie min_instances na jedynkę odruchowo, żeby pozbyć się zimnego startu. Na karcie H100 to decyzja o wartości 131,76 USD dziennie, niezależnie od tego, czy przyjdzie sto żądań, czy zero.

Poleganie na zdaniu z dokumentacji, że nieudane przebiegi nie są naliczane. Dotyczy to modeli publicznych, a dla prywatnych i deploymentów obowiązuje reguła odwrotna, podana dwa zdania niżej w tym samym akapicie.

Testowanie obciążeniowe na koncie z przyznanym kredytem bez metody płatności. Limit sześciu żądań na minutę sprawi, że zmierzysz limit, a nie model.

Przypinanie zależności do wersji przedpremierowej pakietu replicate. Linia 2.0.0 zatrzymała się na becie w grudniu 2025 i nic nie wskazuje, żeby została dokończona.

Zaufanie automatycznemu skanerowi licencji przy audycie zależności pythonowych. Dla pakietów replicate i cog pole license zawiera cały tekst licencji zamiast identyfikatora, więc raport trzeba poprawić ręcznie.

FAQ

Czy Replicate nadaje się do produkcji?

Usługa działa i jest rozwijana, a interfejs HTTP jest stabilny i udokumentowany. Słabym punktem są oficjalne biblioteki klienckie: pythonowa nie ma stabilnego wydania od maja 2025, a javascriptowa od listopada 2025. Przy zastosowaniu produkcyjnym rozsądniej jest oprzeć się na surowych wywołaniach HTTP albo przygotować się na własne poprawki w kliencie.

Czy da się używać Cog bez Replicate?

Tak. Cog jest na licencji Apache 2.0, buduje zwykły obraz Dockera z serwerem na porcie 5000, a pole image w cog.yaml może wskazywać dowolny rejestr, nie tylko r8.im. Obraz uruchomisz na własnym klastrze i wywołasz przez POST /predictions.

Jak uniknąć płacenia za bezczynność modelu?

Przy modelach publicznych nie płacisz za nią wcale, bo naliczany jest wyłącznie czas aktywny. Przy modelach prywatnych i deploymentach płacisz za każdą sekundę, w której instancja jest online, więc jedyną drogą jest pozostawienie min_instances na zerze i pogodzenie się z zimnym startem albo sprawdzenie, czy Twój dostrojony model kwalifikuje się jako fast booting fine-tune.

Ile kosztuje darmowy plan?

Dostawca nie podaje liczby. Dokumentacja mówi tylko, że wybrane modele można uruchamiać za darmo, ale po pewnym czasie zostaniesz poproszony o skonfigurowanie płatności, i że część funkcji wymaga włączonych rozliczeń. Bez konkretnego limitu nie da się na tym oprzeć żadnego planu.

Czy stawki za H100 i H200 naprawdę są takie same?

Według cennika z 22 sierpnia 2026 roku tak, obie wynoszą 0,001525 USD za sekundę i 5,49 USD za godzinę. Różnica polega na dostępności: H200 jest oferowany wyłącznie w ramach umowy z zadeklarowanym poziomem wydatków, a nie w samoobsłudze.

Czym Replicate różni się od Modala?

Modal jest platformą do uruchamiania własnego kodu w Pythonie z rozliczeniem wyłącznie za sekundę zasobu. Replicate zaczyna od katalogu gotowych modeli i dopuszcza dwa tryby rozliczenia, w tym stawkę za jednostkę wyjścia. Szczegóły po stronie Modala opisaliśmy w osobnym artykule.

Źródła sprawdzone bezpośrednio: cennik Replicate, dokumentacja rozliczeń, repozytorium Cog oraz metadane pakietu replicate na PyPI.