Czas czytania: około 8 minut
Build vs buy przy on-prem AI to w rzeczywistości wybór z trzech opcji, nie z dwóch: zbudować własny stos on-prem (własny sprzęt i własny zespół), kupić gotową, prywatną platformę wdrażaną u was, albo wynająć chmurę czy gotowe API. Na czystym koszcie przy umiarkowanym wolumenie najtańsze jest zwykle API rozliczane per token. On-prem, czy budowany, czy kupiony, zaczyna wygrywać ceną dopiero przy wysokim, stałym obłożeniu. A o rachunku nie decydują karty GPU, tylko dwie pozycje, które najczęściej wypadają z kalkulacji: ludzie i compliance. Dlatego uczciwa decyzja rozkłada się na dwa pytania: czy dane wymagają on-prem, i jeśli tak, to budować czy kupić, żeby nie płacić kosztem własnego zespołu za coś, co można dostać jako produkt.
Zacznijmy od błędu, który wywraca większość tych kalkulacji. Zestawia się cenę karty GPU po stronie on-prem z pozornym zerem po stronie chmury, bo chmura na starcie nie ma widocznego wydatku. Wychodzi, że chmura jest tańsza, dopóki nie zsumuje się osiemnastu miesięcy faktur i nie doliczy tego, czego w cenniku nie widać. Build vs buy nie jest pytaniem o sprzęt, jest pytaniem o pełny koszt posiadania w trzyletnim horyzoncie.
Trzy opcje, nie dwie
„Build vs buy” brzmi jak wybór binarny, ale przy AI kryją się w nim trzy różne modele, każdy z innym rachunkiem.
- Build, czyli DIY on-prem. Kupujecie własny sprzęt, stawiacie model otwartowagowy sami i utrzymujecie cały stos: aktualizacje, bezpieczeństwo, integracje. Pełna kontrola, ale też pełna odpowiedzialność operacyjna, realnie od jednego do dwóch inżynierów.
- Buy, czyli gotowa prywatna platforma. Dostajecie produkt wdrażany on-prem albo w dedykowanej, odizolowanej instancji, ale to dostawca utrzymuje stos, wersje i wsparcie. Ta sama kontrola nad danymi co przy build, bez budowania zespołu platformowego od zera.
- Rent, czyli chmura lub gotowe API. Nic nie stawiacie, płacicie za zużycie. Najniższy próg wejścia, ale dane opuszczają wasz perymetr, a koszt regulacyjny i per token rośnie wraz z wolumenem.
Mieszanie tych trzech to najczęstsza przyczyna kalkulacji, które nie bronią się przed zarządem. Zanim policzycie cokolwiek, ustalcie, która z tych dróg jest waszą realną alternatywą, bo porównywanie CAPEX własnego sprzętu ze stawką per token to mierzenie dwóch różnych rzeczy: kapitału kontra zużycia.
Pięć kategorii kosztu, które muszą wejść do TCO
Uczciwe TCO obejmuje pięć kategorii po każdej stronie, w tym samym trzyletnim horyzoncie. Compute, czyli sam koszt liczenia, jest najłatwiejszy do policzenia i najmniej różnicujący. Prawdziwa różnica siedzi gdzie indziej.
- Compute. Karta GPU albo stawka za token pomnożona przez czas. Najmniejsza pozycja różnicująca, choć to na niej skupia się większość kalkulatorów.
- Infrastruktura i energia. Zasilanie, chłodzenie, sieć, kolokacja. Przy on-prem realne, przy chmurze schowane w cenie.
- Ludzie. Stawianie i utrzymanie modelu, bezpieczeństwo, aktualizacje. Tu kryje się największa różnica między build a buy.
- Compliance. Przy chmurze coroczne due diligence dostawcy, mapowanie transferów, klauzule DPA, re-ewaluacja przy każdej zmianie podprocesora. Realna praca bez wygodnej stawki jednostkowej.
- Koszty projektowe i wyjścia. Integracja z ERP i MES, szkolenia, iteracje pierwszego półrocza, a także koszt ewentualnego wyjścia od dostawcy.
Skala tej pomyłki bywa spora. W trzyletnim rozbiciu kosztów on-prem, które przytacza analiza Spheron, koszt ludzi potrafi przewyższyć koszt sprzętu, a energia i utrzymanie to kolejne kilkadziesiąt tysięcy, których w „cenie karty” nie widać. Reguła kciuka: do prostej sumy compute dolóżcie od 20 do 40 procent na pozycje, które nie mają wygodnej stawki jednostkowej.
Kiedy on-prem naprawdę wygrywa na koszcie
Wynik przewraca jedna zmienna: wykorzystanie. On-prem to koszt w dużej mierze stały, więc im wyższe i bardziej stałe obłożenie, tym niższy koszt jednej odpowiedzi. Chmura jest odwrotnie: płacicie za to, co zużyjecie, więc przy niskim albo zmiennym ruchu jest tańsza.
Dwa wiarygodne źródła z 2026 pokazują, jak bardzo próg zależy od założeń. Analiza Lenovo Press dla konfiguracji wielokartowych stawia tezę, że dla wysokiego, stałego obłożenia własny sprzęt zwraca się w kilka miesięcy wobec chmury on-demand, i że „era chmury do wszystkiego” dla ciągłego inferencing się skończyła. Z drugiej strony analiza Spheron zwraca uwagę, że przy konkurencyjnych stawkach chmury GPU próg opłacalności on-prem praktycznie znika, a większość zespołów produkcyjnych pracuje przy 40 do 65 procent wykorzystania z powodu zmienności ruchu, co on-prem trudno uzasadnić samym kosztem. Praktyczna linia, która wychodzi z obu: gdzieś w okolicy 70 do 80 procent stałego wykorzystania, i tylko wobec drogiej chmury on-demand, a nie wobec każdej oferty.
Wniosek nie jest ani „zawsze on-prem”, ani „zawsze chmura”. Przy umiarkowanym wolumenie on-prem uzasadnia się kontrolą danych i compliance, a nie ceną, i trzeba to robić z otwartymi oczami, ze świadomością, ile ta kontrola kosztuje. Który workload naprawdę wymaga on-prem, a który spokojnie zostanie w chmurze, rozkładamy w tekście o tym, że tylko część procesów wymaga podejścia suwerennego.
Tabela decyzyjna: build, buy czy rent
Najprościej ustalić kierunek, zestawiając realną sytuację z modelem, który do niej pasuje, i powodem, który za tym stoi.
| Wasza sytuacja | Model | Dlaczego |
|---|---|---|
| Dane mogą być publiczne, wolumen umiarkowany, pilotaż | Rent (chmura / API) | Najniższy próg wejścia, izolacja nic tu nie dodaje |
| Dane wrażliwe, ale bez zespołu ML i platformowego | Buy (gotowa platforma) | Kontrola danych bez kosztu budowania i utrzymania stosu |
| Wysoki, stały wolumen i własny zespół inżynierski | Build (DIY on-prem) | Najniższy koszt krańcowy, gdy sprzęt jest realnie obłożony |
| Podmiot objęty NIS2, audyt pyta o granicę danych | Buy albo Build | Granica danych broni się jednym zdaniem, wybór zależy od zespołu |
| Ruch zmienny, obłożenie poniżej połowy doby | Rent, ewentualnie Buy | Własny sprzęt płaci za godziny, w których nikt nie pyta |
Wzorzec jest czytelny: o wybór między chmurą a on-prem gra wrażliwość danych i wolumen, a o wybór między build a buy gra to, czy chcecie i możecie utrzymywać własny stos ML.
Trzy drogi, dwa pytania: czy dane wymagają on-prem, i jeśli tak, budować czy kupić.
Build vs buy: co realnie różni te dwie drogi
Gdy dane przesądzą, że zostajecie przy on-prem, zostaje właściwe pytanie build vs buy. Obie drogi dają tę samą kontrolę nad danymi, różnią się tym, kto ponosi koszt jej utrzymania.
Build oddaje wam pełną kontrolę nad każdym elementem stosu, ale przenosi na was cały ciężar operacyjny: stawianie modelu, aktualizacje, łatanie bezpieczeństwa, sizing sprzętu, integracje. To realnie od jednego do dwóch etatów inżynierskich i najdłuższy czas do pierwszego efektu. Ma sens, gdy AI jest dla was rdzeniem, a nie narzędziem, i gdy macie zespół, który i tak chcecie mieć.
Buy zostawia wam kontrolę nad danymi, a zdejmuje utrzymanie stosu. Dostawca odpowiada za wersje, bezpieczeństwo i sizing, wy dostajecie działające narzędzie szybciej i bez budowania kompetencji od zera. To najczęściej właściwa droga dla producenta, dla którego AI jest ważnym narzędziem, ale nie przedmiotem działalności. Ważne, żeby „buy” nie stało się nową formą uzależnienia, dlatego kryteria takie jak prawa do modelu i realny plan wyjścia trzeba sprawdzić z góry, co rozkładamy w tekście o single-tenant kontra shared cloud.
Innymi słowy: build kupuje maksymalną elastyczność kosztem własnego zespołu, buy kupuje czas i przewidywalność kosztem części elastyczności. Pełny obraz tego, kiedy on-prem w ogóle ma sens, rozkładamy w przewodniku on-prem AI w produkcji: kiedy ma sens, a kiedy nie, a kiedy prywatna AI wygrywa z publiczną, w tekście o prywatnej AI w produkcji.
Jak policzyć własne TCO krok po kroku
Kolejność, która zamienia orientacyjny rachunek w decyzję, którą obronicie przed zarządem.
- Ustalcie realny wolumen i tryb. Ile zapytań miesięcznie i czy model musi być dostępny całą dobę, czy tylko w godzinach pracy zakładu. To ta liczba przesądza, po której stronie progu jesteście.
- Wybierzcie punkt odniesienia w chmurze. Jeśli i tak stawialibyście model sami, porównujcie z wynajmem GPU. Jeśli wystarczyłoby gotowe API, porównujcie per token. To dwie różne kalkulacje.
- Policzcie pięć kategorii, nie samo compute. Dodajcie ludzi, infrastrukturę, compliance i koszty projektowe, w tym samym trzyletnim horyzoncie po obu stronach.
- Rozdzielcie decyzję kosztową od decyzji o ryzyku. Jeśli wolumen jest umiarkowany, on-prem wybieracie za kontrolę danych, nie za cenę, i musicie wiedzieć, ile ta kontrola kosztuje.
- Dopiero na końcu build vs buy. Gdy już wiecie, że potrzebujecie on-prem, pytajcie, czy chcecie i możecie utrzymywać stos sami, czy taniej i szybciej kupić go jako produkt.
Żeby podstawić własne liczby, a nie orientacyjne rzędy wielkości, zacznijcie od naszego kalkulatora wartości. A jeśli chcecie najpierw sprawdzić, które z waszych procesów w ogóle wymagają on-prem, mini-audyt gotowości zajmuje 10 minut i nie wymaga zostawiania danych.
Najczęstsze pytania
Co jest tańsze: on-prem czy chmura dla AI?
Przy umiarkowanym wolumenie na czystym koszcie zwykle wygrywa gotowe API rozliczane per token. On-prem zaczyna bić chmurę ceną dopiero przy wysokim, stałym wykorzystaniu. Poniżej tego progu on-prem uzasadnia się kontrolą danych i compliance, nie ceną.
Od jakiego wykorzystania on-prem AI się opłaca?
Zależy od tego, z jaką chmurą porównujecie. Analizy z 2026 wskazują próg gdzieś w okolicy 70 do 80 procent stałego wykorzystania wobec drogiej chmury on-demand, ale przy konkurencyjnych stawkach GPU próg ten potrafi znikać. Większość zespołów pracuje przy 40 do 65 procent, co on-prem trudno uzasadnić samym kosztem.
Build czy buy przy on-prem AI?
Build daje maksymalną elastyczność, ale kosztem jednego do dwóch etatów inżynierskich i najdłuższego czasu wdrożenia. Buy zostawia kontrolę nad danymi i zdejmuje utrzymanie stosu, więc jest zwykle właściwy dla firmy, dla której AI jest narzędziem, a nie przedmiotem działalności.
Co najczęściej znika z rachunku TCO?
Po stronie on-prem: ludzie, energia i koszty projektowe pierwszego półrocza. Po stronie chmury: koszt regulacyjny dostawcy, egress, storage oraz godziny GPU opłacane, gdy nikt nie pyta. Do prostej sumy compute dolóżcie od 20 do 40 procent.
Czy niższy koszt chmury oznacza, że on-prem nie ma sensu?
Nie. Oznacza, że on-prem trzeba uzasadniać kontrolą danych i zgodnością, nie ceną, dopóki wolumen jest umiarkowany. Przy wysokim, stałym obłożeniu rachunek kosztowy i argument regulacyjny wskazują w tę samą stronę.
Fryderyk, CortexMine. Piszemy o prywatnej AI dla producentów objętych NIS2, na podstawie własnych wdrożeń i testów.
Wolicie to omówić? Umówcie 30-minutową rozmowę z założycielem, bez pitchu, po prostu o waszym przypadku.