Spór „lokalnie czy chmura” rzadko ma jedną odpowiedź, bo to nie jest wybór technologii, tylko profil kosztu. Chmura to koszt zmienny (OPEX) rosnący z ruchem. Self-hosting to koszt głównie stały (CAPEX + utrzymanie) prawie niezależny od ruchu. Która struktura jest tańsza, zależy od tego, ile naprawdę używasz.
Dwa profile kosztu#
| Lokalnie (self-hosted) | API w chmurze | |
|---|---|---|
| Koszt wejścia | Wysoki (sprzęt, wdrożenie) | Bliski zera (klucz API) |
| Koszt jednostkowy | Niski, przewidywalny | Zmienny, rośnie z ruchem |
| Skalowanie kosztu | Płaskie do limitu sprzętu | Liniowe z wolumenem |
| Prywatność danych | Dane zostają u Ciebie | Dane wychodzą do dostawcy |
| Najlepsze przy | Stałym, dużym wolumenie | Małym, nieregularnym ruchu |
Jak policzyć punkt przecięcia#
Policz miesięczny koszt chmury (liczba zadań × koszt jednego wywołania) i porównaj go z miesięczną amortyzacją własnej infrastruktury (sprzęt rozłożony w czasie + prąd + utrzymanie). Wolumen, przy którym te dwie liczby się zrównują, to Twój punkt przecięcia. Poniżej zostań w chmurze; powyżej self-hosting zaczyna oszczędzać.
Policzmy to na przykładzie (ceny orientacyjne, weryfikuj w aktualnym cenniku — stawki API i sprzętu zmieniają się szybko). Załóżmy typowe zadanie: ~1 tys. tokenów wejścia + ~0,5 tys. tokenów wyjścia. Przy modelu średniej klasy (rząd wielkości ok. 0,30 USD za 1 mln tokenów wejścia i ok. 1,20 USD za 1 mln wyjścia) jedno wywołanie kosztuje ok. 0,0009 USD. Po stronie self-hostingu weź box z GPU rozłożony na 36 miesięcy plus prąd i utrzymanie — realnie mieści się to w widełkach ok. 600–1200 USD miesięcznie, zależnie od klasy karty i tego, czy sprzęt jest dzielony z innymi zadaniami.
| Wolumen / mies. | Koszt chmury (orientacyjnie) | Koszt self-host (widełki) |
|---|---|---|
| 0,5 mln wywołań | ~450 USD | ~600–1200 USD |
| 2 mln wywołań | ~1800 USD | ~600–1200 USD |
| 5 mln wywołań | ~4500 USD | ~600–1200 USD |
W tym scenariuszu linie przecinają się gdzieś między 0,5 a 2 mln wywołań miesięcznie — powyżej tego progu stały koszt sprzętu zaczyna się zwracać. To tylko ilustracja jednego profilu: dłuższe prompty, RAG i droższe modele przesuwają próg w dół (chmura drożeje szybciej), a tańsze zadania w górę. Policz własny próg w kalkulatorze kosztu inferencji — a gdy Twój wolumen go przekroczy, kolejnym krokiem jest migracja z API na własny model, która kwantyfikuje ten sam punkt przecięcia w praktyce.
Dlaczego hybryda zwykle wygrywa#
Rzadko wszystko jest „małe” albo „duże”. Stałe, wysokowolumenowe zadania (klasyfikacja, embeddingi, wyszukiwanie semantyczne na BGE-M3) tanio obsłużysz lokalnie. Rzadkie, ciężkie wnioskowanie wygodnie kupisz w chmurze. Router kieruje każde zadanie tam, gdzie jest najtaniej i najbezpieczniej — i to on, dobierając model do zadania, jest największą dźwignią kosztową, niezależnie od wyboru lokalne/chmura.
Koszt to nie tylko faktura#
W rachunku uwzględnij też ryzyko lock-inu (zmiana cennika dostawcy), koszt utrzymania (cały TCO: monitoring, aktualizacje, dyżury) i koszt zgodności (dane osobowe wychodzące do chmury to dodatkowe obowiązki — patrz self-hosted LLM a RODO). Przewidywalność bywa warta więcej niż kilka procent na fakturze.
FAQ#
Kiedy własny model jest tańszy od API?#
Gdy masz stały, duży wolumen. Wysoki koszt wejścia rozkłada się wtedy na wiele zadań i koszt jednostkowy spada poniżej ceny chmury. Przy małym lub nieregularnym ruchu API pozostaje tańsze.
Czy muszę wybrać jedno albo drugie?#
Nie. Najczęściej optymalna jest hybryda: lokalnie obsługujesz tanie, wysokowolumenowe zadania, a chmurę rezerwujesz dla rzadkiego, ciężkiego wnioskowania. Router spina to w jeden przepływ.
Co najmocniej obniża rachunek za LLM?#
Dobór modelu do zadania. Kierowanie prostych przepływów na mały, tani model i rezerwowanie dużego tylko tam, gdzie trzeba, zwykle daje większą oszczędność niż sam wybór lokalne vs chmura. Zaraz za tym jest optymalizacja kosztu tokenów — krótsze prompty, cache i kontrola długości kontekstu.