Vertex AI nie ma jednej ceny. Rachunek to suma kilku usług rozliczanych według użycia, a najbardziej zaskakuje pozycja predykcyjnych endpointów: wdrożony model jest rozliczany tak długo, jak długo jest wdrożony, niezależnie od tego, czy trafia do niego choć jedno zapytanie. Ten arkusz zamienia to w szacunek do wypełnienia, czynnik po czynniku, żebyś mógł oszacować budżet Vertex AI zanim się zdecydujesz. To ta sama struktura, której używamy wewnętrznie, gdy wyceniamy budżet albo szukamy, dlaczego rachunek urósł.
Uwaga o nazwie: podczas Google Cloud Next w kwietniu 2026 Google zmienił nazwę Vertex AI na Gemini Enterprise Agent Platform. Strona cennika nadal jest pod adresem Vertex AI, a mechanika rozliczeń jest bez zmian, więc wszystko poniżej dotyczy obu nazw.
Pełny arkusz jest poniżej, za darmo do czytania i użycia.
Zostaw e-mail, jeśli chcesz też od czasu do czasu dostać praktyczną notkę o kosztach chmury i narzędziach AI. Bez rozmowy sprzedażowej, w każdej chwili można się wypisać, a arkusz i tak zostaje otwarty.
Jak używać tego arkusza
Przejdź przez pięć czynników poniżej po kolei. Dla każdego wpisz własne liczby w polach „Twoje dane”. Celowo nie podajemy tu aktualnych stawek jednostkowych: Google je zmienia i różnią się między regionami, więc arkusz ujmuje kształt każdego kosztu i Twoje użycie. Po aktualne liczby sięgnij do oficjalnej strony cennika Vertex AI. Pobierz stawkę dla swojego regionu, pomnóż przez swoje dane i masz uzasadniony szacunek.
Najważniejszy nawyk: szacuj części stałe oddzielnie od części zależnych od użycia. Części stałe są rozliczane niezależnie od tego, czy ktokolwiek z nich korzysta, i przy niskim ruchu zwykle dominują.
1. Predykcyjne endpointy (koszt, który nalicza się, gdy śpisz)
Gdy wdrożysz własny wytrenowany model na endpoint predykcji online, płacisz za każdą godzinę, w której model jest wdrożony, nawet jeśli obsłuży zero zapytań. Rozliczenie jest per node-hour, skalowane typem maszyny i mnożone przez liczbę węzłów (replik). Autoskalowanie rzadko schodzi do zera dla standardowego endpointu online, bo minimalna liczba replik trzyma gotową pojemność dla niskich opóźnień.
Model myślowy to nie „płać za predykcję”. To „wynajmij maszynę, która akurat serwuje predykcje”, a najem trwa, dopóki go nie zakończysz.
Twoje dane:
- Liczba endpointów online (uwzględnij każdy zapomniany testowy): __
- Repliki na endpoint: __
- Typ maszyny na endpoint (i ewentualne GPU): __
- Godziny wdrożenia w miesiącu (730 = zawsze włączone przez cały miesiąc): __
- Przybliżona suma miesięczna (repliki x godziny x stawka node-hour, zsumowane po endpointach): __
To zwykle największa pozycja przy niskim ruchu. Wypisz każdy endpoint, zwłaszcza ten, który ktoś z zespołu uruchomił do testu integracji i nikt go nie zdjął.
2. Własne trenowanie (płacisz, gdy zadanie trwa)
Trenowanie jest rozliczane za obliczenia zużyte w trakcie zadania: maszynogodziny VM plus stawka godzinowa za podłączone GPU lub TPU, przez czas rzeczywisty trwania zadania. Gdy zadanie się kończy, opłata ustaje. To ta intuicyjna pozycja, ale stawki akceleratorów są wysokie, więc długie trenowanie na GPU lub TPU to często największy jednorazowy koszt na platformie.
Twoje dane:
- Zadania trenowania w miesiącu: __
- Średnia liczba godzin na zadanie: __
- Sprzęt na zadanie (CPU / GPU / TPU i rozmiar maszyny): __
- Przybliżona suma miesięczna (zadania x godziny x stawka sprzętu): __
3. Model Garden i modele generatywne (zależy który model)
Model Garden to nie jedna cena, bo to nie jeden rodzaj modelu:
- Własne modele generatywne Google (rodzina Gemini) rozliczają się za milion tokenów wejściowych i wyjściowych. Stawki różnią się między modelami i zmieniają w czasie.
- Modele partnerów zewnętrznych rozliczają się po stawce dostawcy, przekazanej dalej.
- Modele open-weight wdrożone samodzielnie zachowują się jak endpoint predykcji: płacisz per node-hour za sprzęt, na którym działają, a nie za token. To ta sama pułapka co w czynniku 1, więc licz samodzielnie wdrożony model open pod endpointami, nie tutaj.
Twoje dane:
- Rodzina modeli lub używane modele: __
- Tokeny wejściowe w miesiącu: __
- Tokeny wyjściowe w miesiącu: __
- Jakieś samodzielnie wdrożone modele open-weight? Jeśli tak, dodaj ich node-hours do czynnika 1: __
- Przybliżona suma miesięczna (wolumen tokenów x stawka za token): __
Koszt tokenów rośnie liniowo z ruchem. Jest mały przy niskim wolumenie i dominujący przy wysokim, czyli odwrotnie niż zawsze włączony endpoint.
4. Predykcja wsadowa (taniej dla dużych partii)
Gdy nie potrzebujesz odpowiedzi w czasie rzeczywistym, predykcja wsadowa uruchamia zadanie na zbiorze danych i rozlicza per node-hour przez czas trwania zadania, a potem się zatrzymuje. Dla dużego scoringu offline jest zwykle dużo tańsza niż utrzymywanie aktywnego endpointu online, właśnie dlatego, że nic nie zostaje wdrożone po zakończeniu.
Twoje dane:
- Zadania wsadowe w miesiącu: __
- Node-hours na zadanie: __
- Przybliżona suma miesięczna (zadania x node-hours x stawka): __
Jeśli któryś z endpointów z czynnika 1 istnieje tylko po to, by cyklicznie scorować dane, zastanów się, czy zadanie wsadowe nie zrobiłoby tego samego taniej.
5. Usługi wspierające (różnica między szacunkiem a fakturą)
Feature Store, Vertex AI Pipelines, przechowywanie modeli i artefaktów oraz ruch wychodzący (egress) są rozliczane osobno. Żadna z tych pozycji nie jest duża sama w sobie przy małej skali, ale razem tworzą różnicę między szacunkiem a fakturą. Egress szczególnie zaskakuje zespoły przenoszące wyniki predykcji lub dane treningowe między regionami albo poza Google Cloud.
Twoje dane:
- Użycie Feature Store: __
- Uruchomienia Pipelines w miesiącu: __
- Przechowywanie (artefakty, zbiory danych): __
- Egress międzyregionalny lub poza GCP: __
- Przybliżona suma miesięczna: __
Wychwyć miejsca gdzie przepłacasz
Zanim zaufasz sumie, przejdź tę listę. Każda pozycja to koszt, który łatwo zostawić włączony bez żadnego efektu:
- Zapomniany testowy endpoint wciąż naliczający node-hours (czynnik 1).
- Samodzielnie wdrożony model open-weight zostawiony po zakończeniu eksperymentu.
- Egress międzyregionalny, którego nie zaplanowałeś (czynnik 5).
- Stały, przewidywalny workload bez zastosowanego committed-use discount: dla stabilnego użycia rabaty za zobowiązanie w Google Cloud często ruszają efektywną stawkę bardziej niż jakakolwiek cena jednostkowa.
- Zawsze włączony endpoint online robiący pracę, którą cykliczne zadanie wsadowe wykonałoby taniej (czynnik 4).
Twój szacunek miesięczny
Zsumuj pięć podsum. Potem podziel sumę na dwa kosze:
- Stałe (rozliczane niezależnie od użycia): zawsze włączone endpointy, samodzielnie wdrożone modele open, bazowe przechowywanie.
- Zależne od użycia (skalują się z ruchem): tokeny, zadania trenowania, zadania wsadowe, egress.
Ten podział to właściwy wniosek. Przy niskim ruchu kosz stały dominuje, więc koszt na zapytanie jest wysoki; podwój ruch, a kosz stały zostaje płaski, podczas gdy kosz użycia rośnie, więc koszt na zapytanie spada. Dlatego „ile kosztuje Vertex AI” nie ma jednej odpowiedzi i dlatego szacunek jest tylko tak dobry, jak Twoje założenie o ruchu.
Jeśli chcesz, żeby ktoś jeszcze rzucił okiem na szacunek, albo widzisz już rosnący achunek Vertex AI, którego nie umiesz wyjaśnić, nasz zespół pomoże zamodelować realny koszt przed wdrożeniem i znaleźć przepłacanie po nim. Zacznij od naszego konsultingu Google Cloud, a jeśli pytanie dotyczy kontroli kosztów na całej platformie, od naszej pracy FinOps.