Pojemność i kontrola, które prywatny stos AI zapewnia w działaniu

Argumentację etapu decyzyjnego za przejściem na rozwiązania prywatne i lokalne, prowadzoną w języku kontroli nad danymi i ryzyka, opisuje artykuł co zyskują organizacje, gdy AI działa wewnątrz ich sieci. Ten tekst schodzi poziom niżej. Stos jest wymiarowany, sprzęt wdrożony, a zespół operacyjny przejął stery. W działaniu to, co organizacja zyskała, sprowadza się do dwóch właściwości: pojemności i kontroli. Pojemność to to, co system potrafi zrealizować dla biznesu, w granicach fizycznego zasobu obliczeniowego, którym organizacja włada. Kontrola to odpowiedź na pytanie, kto decyduje, co system zrobi dalej. Obie można badać w regularnym rytmie. Żadna nie zależy od kalendarza dostawcy.

Pojemność mówi, co system może zrobić dla firmy. Kontrola mówi, kto decyduje, co zrobi dalej.

Pojemność to własne zasoby obliczeniowe, a nie przydział

Usługa AI rozliczana licznikowo przyznaje pojemność w formie przydziału. Limity, ograniczenia liczby zapytań, dostępność regionalna i warunki, które mogą się zmienić przy odnowieniu, wyznaczają sufit - a dostawca może ten sufit przesunąć bez pytania klienta o zdanie. Własny stos także ma sufit, ale jest on fizyczny, został zmierzony przed zakupem i to organizacja ustala względem niego punkt pracy.

Metodykę wyznaczania tego sufitu opisuje wymiarowanie konfiguracji GPU on-premise na podstawie rzeczywistego obciążenia: odtwarza się rzeczywiste obciążenie, mierzy budżety latencji, przepustowości i pamięci, a z przebiegu odczytuje granicę dolną i górną. Ważne jest tu to, w co te dwie liczby przekształcają się w działaniu. Granica dolna to najmniejsza konfiguracja, która spełnia docelowy poziom usług. Granica górna to punkt, powyżej którego dodatkowy sprzęt nie daje już nic. Między nimi organizacja posiada zakres pojemności, którego żaden dostawca nie zacieśni przy odnowieniu umowy.

Ten zakres utrzymuje się w cyklach pracy definiujących obciążenie przedsiębiorstw. Obciążenia regulowane to nie jest stały ruch internetowy. Pikują wokół zamknięcia kwartału, terminów sprawozdań i szczytów w godzinach pracy, a te piki są z góry znane, bo podążają za kalendarzem biznesowym. Pojemność wymiarowana do zmierzonego szczytu obsługuje cały cykl. Pozorny zapas w dołku to nie marnotrawstwo. To rezerwa na szczyt, który organizacja potrafi już nazwać i datować.

Standardowy kontrargument to elastyczność: wynajmowana pojemność rośnie na żądanie, własna nie. Elastyczność bywa wyceniana pod obciążenia, których nikt nie potrafi przewidzieć. Korporacyjne obciążenie AI wynika z liczby pracowników, wolumenu procesów i kalendarza biznesowego, a wszystkie trzy czynniki da się prognozować wewnątrz organizacji. Gdy obciążenie naprawdę przerośnie ten zakres, rozbudowa sprowadza się do ponownego wymiarowania znaną metodą, na tym samym środowisku odtwarzającym obciążenie, podczas gdy dotychczasowy sprzęt nadal obsługuje produkcję.

Ekonomia krańcowa wskazuje wtedy właściwy kierunek. W usłudze licznikowej wzrost użycia podnosi wydatki, bo każde zapytanie niesie cenę narzuconą przez dostawcę. Na własnym sprzęcie dodatkowa inferencja zbliża się do kosztu energii i obsługi, więc rosnąca adopcja poprawia zwrot z kapitału, który organizacja już zaangażowała. Presja wykorzystania też się odwraca. Środowisko licznikowe po cichu zniechęca do wysycania wynajmowanych mocy. Własny stos nagradza dążenie do zmierzonego sufitu, bo zapas powyżej sufitu został przed zakupem uznany za zbędny i nigdy nie został kupiony.

Rachunek za tokeny na tle faktury za sprzęt

Argument ekonomiczny z poprzedniego akapitu można uziemić w liczbach. Zakres ilustrują dwie konfiguracje startowe. Pierwsza to klaster dwóch lub trzech maszyn NVIDIA DGX Spark - sprzęt stojący przy biurku, który scala pamięć w pulę łączami klastrowymi NVIDIA. Druga to pojedynczy serwer z trzema kartami NVIDIA RTX Pro 6000, konfiguracja, którą mała firma montuje w szafie raz, a potem dopiero się w nią rozwija. Poniższe tabele podają, ile każda konfiguracja kosztuje i ile wytwarza w miesiącu. Następnie zestawiają ten miesięczny wolumen z cenami katalogowymi API chmurowych i pokazują, kiedy sprzęt zwraca się z unikniętych wydatków. Ostatnia tabela utrzymuje roczny budżet chmurowy organizacji jako stały i pyta, co te pieniądze kupują w tokenach albo w sprzęcie.

Ile kosztuje sprzęt i co dostarcza

Konfiguracja	Szacunkowa inwestycja	Szybkość generowania	Okno kontekstowe
2x NVIDIA DGX Spark	13 000 USD	ok. 170 tok/s	ok. 800 tys. tokenów
3x NVIDIA DGX Spark	19 500 USD	ok. 220 tok/s	ok. 1 mln tokenów
Serwer z 3x RTX Pro 6000	52 000 USD	ok. 470 tok/s	ok. 1 mln tokenów

Podane szybkości i okna kontekstu to szacunki dla ciągłego, równoległego użytku zespołowego. Dla porównania: taryfy rozliczane tokenowo w czołowych API chmurowych przyjmują około miliona tokenów kontekstu. Miejsce subskrypcyjne w chmurze zapewnia w codziennym użyciu okno klasy 200 tys., więc okna z tabeli są cztery do pięciu razy szersze.

Ile te same tokeny kosztują w API chmurowych

Dostawca	Poziom	Model	Wejście (USD/1M)	Wyjście (USD/1M)
Anthropic	Flagowy	Claude Fable 5.1	10 USD	50 USD
Anthropic	Wyższy średni	Claude Opus 5.5	4 USD	20 USD
Anthropic	Średni	Claude Sonnet 5	2 USD	10 USD
Anthropic	Mały	Claude Haiku 4.5	1 USD	5 USD
OpenAI	Flagowy	gpt-6-astra	10 USD	50 USD
OpenAI	Wyższy średni	gpt-5.6-sol (promocja, gwarancja do 2026-11-21)	4 USD	20 USD
OpenAI	Średni	gpt-6-sol	2 USD	10 USD

Przy typowej proporcji pięciu tokenów wejściowych na jeden wyjściowy powyższe ceny katalogowe średnio dają około 20 USD za milion tokenów wyjściowych na poziomie średnim, około 40 USD na poziomie wyższym średnim i około 100 USD na poziomie flagowym. Obaj dostawcy zmniejszają o połowę ceny katalogowe w API Batch dla prac tolerujących opóźnienia.

Tokeny można kupić na trzy sposoby: miejsca subskrypcyjne, rozliczane tokenowo API wycenione powyżej oraz własny sprzęt. Stan na wrzesień 2026 r.: miejsce kosztuje 20-25 USD miesięcznie, a w planach premium około 100 USD. W codziennym użyciu miejsce daje okno klasy 200 tys. z kranem, który resetuje się co 5 godzin i co tydzień zostaje zakręcony. Własny sprzęt nie ma kranu. Jego okna sięgają od 800 tys. do 1 mln, a jedynym sufitem jest przepustowość.

Co sprzęt wytwarza w ciągu miesiąca

Poniższa tabela podaje miesięczną produkcję każdej konfiguracji przy pracy w godzinach biurowych oraz to, ile ten wolumen kosztowałby w API chmurowych według trzech kotwic średnioważonych.

Konfiguracja	Tokeny wyjściowe miesięcznie	Poziom średni	Poziom wyższy średni	Poziom flagowy
2x NVIDIA DGX Spark	około 135 milionów	około 2 700 USD	około 5 400 USD	około 13 500 USD
3x NVIDIA DGX Spark	około 175 milionów	około 3 500 USD	około 7 000 USD	około 17 400 USD
Serwer z 3x RTX Pro 6000	około 370 milionów	około 7 400 USD	około 14 900 USD	około 37 200 USD

Praca w godzinach biurowych oznacza tu dziesięć godzin dziennie w dni robocze, czyli około 22 dni w miesiącu. Przy pracy całodobowej ten sam sprzęt generuje mniej więcej trzy razy więcej: około 440 milionów, 570 milionów i 1,2 miliarda tokenów wyjściowych miesięcznie.

Kiedy sprzęt się zwraca

Liczba miesięcy, po których każda konfiguracja spłaca inwestycję z unikniętych wydatków na tokeny, przy pracy w godzinach biurowych:

Konfiguracja	Poziom średni	Poziom wyższy średni	Poziom flagowy
2x NVIDIA DGX Spark	4,8	2,4	1,0
3x NVIDIA DGX Spark	5,6	2,8	1,1
Serwer z 3x RTX Pro 6000	7,0	3,5	1,4

Nawet przy cenach poziomu średniego każda konfiguracja zwraca się w siedem miesięcy lub szybciej. Przy cenach flagowych para Spark zwraca się w około miesiąc, a serwer w około sześć tygodni. Energia elektryczna jest wliczona w zwrot i przesuwa każdą wartość o mniej niż jedną dziesiątą miesiąca. Praca całodobowa skraca każdy zwrot mniej więcej trzykrotnie: do 0,3-1,5 miesiąca dla pary Spark, 0,3-1,7 dla klastera z trzech jednostek i 0,4-2,2 dla serwera.

Co kupuje ten sam roczny budżet przy 15, 50 i 100 użytkownikach

Przyjmij roczny budżet chmurowy organizacji jako stały i zapytaj, co te pieniądze kupują w każdym wariancie: tokeny z API albo sprzęt, który potrafi je wygenerować. Poniższa tabela przeprowadza to porównanie dla 15, 50 i 100 użytkowników.

Przyjmuje się, że każdy użytkownik generuje 25 000 tokenów wyjściowych w dni robocze przy pracy w godzinach biurowych - to pełne obciążenie asystenta agentowego. Każdą wielkość przypisano do konfiguracji, która pokrywa zapotrzebowanie z trwałym zapasem: para Spark przy 15 użytkownikach, klaster Spark z trzech jednostek przy 50, serwer RTX Pro przy 100. Przypisania celowo zostawiają zapas, przy średnim wykorzystaniu od 6% do 16%. Porównanie liczy to, co sprzęt potrafi wygenerować, a nie to, czego wymaga obciążenie.

Kolumna pierwszego roku porównuje roczną pojemność tokenową sprzętu przy pracy w godzinach biurowych z tokenami, które za ten sam budżet kupuje się w API. Ta wielokrotność pozostaje niezmienna przy każdej kotwicy cenowej, bo budżet z definicji jest ceną żądanych tokenów. Kolumna trzyletnia porównuje tokeny na dolara po obu stronach: ile sprzęt generuje na dolara ceny zakupu plus energii oraz ile API zwraca na dolara wydatku.

Użytkownicy	Roczny koszt chmury: średni / wyższy średni / flagowy	Koszt sprzętu / tokeny rocznie	Pojemność za te same pieniądze, rok 1	Tokeny na dolara w 3 lata: średni / flagowy
15	1 980 / 3 960 / 9 900 USD	13 000 USD - około 1,62 mld tokenów rocznie	16,3 x	7,3 x / 36,6 x
50	6 600 / 13 200 / 33 000 USD	19 500 USD - około 2,09 mld tokenów rocznie	6,3 x	6,3 x / 31,6 x
100	13 200 / 26 400 / 66 000 USD	52 250 USD (szacunek) - około 4,47 mld tokenów rocznie	6,8 x	5,0 x / 25,2 x

Wiersz 50 użytkowników niesie najprostszy wynik. Przy kotwicy średniej trzy lata wydatków chmurowych to 19 800 USD, a klaster Spark z trzech jednostek kosztuje w tym samym okresie 19 856 USD, cena zakupu plus energia. To ta sama kwota z dokładnością do 0,3%, a klaster potrafi wygenerować 6,3 raza więcej tokenów.

Kotwica średnia pokazuje też uczciwie luki pierwszego roku. Budżet 15 użytkowników (1 980 USD) i budżet 50 użytkowników (6 600 USD) nie pokrywają w pierwszym roku żadnej z trzech konfiguracji. Zakup przypisanego sprzętu od ręki wymaga dodatkowych 11 020 USD przy 15 użytkownikach i dodatkowych 12 900 USD przy 50. Przy 100 użytkownikach budżet poziomu średniego (13 200 USD) pokrywa tylko najmniejszą konfigurację. Serwer przypisany do tego wiersza wymaga dodatkowych 39 050 USD.

Przy kotwicy flagowej budżety 50 i 100 użytkowników kupują sprzęt od ręki już w pierwszym roku, zostawiając nie wydane 13 500 USD i 13 750 USD. Flagowemu budżetowi 15 użytkowników do pary Spark brakuje w pierwszym roku 3 100 USD. Kotwica wyższa średnia ląduje pomiędzy tymi kolumnami: 14,6 x, 12,6 x i 10,1 x w trzech latach. Trzyletnie wielokrotności nie zależą od założenia dotyczącego liczby tokenów na użytkownika. Zostają przy dowolnym profilu obciążenia, lżejszym lub cięższym.

Zastrzeżenia, które towarzyszą tym liczbom

Wszystkie ceny to publikowane wartości stron trzecich w USD, zarejestrowane w chwili pisania. Ceny katalogowe chmur i promocje się zmieniają, a ceny sprzętu różnią się zależnie od sprzedawcy i regionu. Szybkości, pojemności i okresy zwrotu to szacunkowe wartości zagregowane do celów planowania, a nie oferta ani wycena dostarczanych systemów. Przelicz ten rachunek na rzeczywistym obciążeniu, zanim zaangażujesz kapitał w którąkolwiek ze stron.

Kontrola to cztery warstwy, którymi można zarządzać

W materiałach dostawców słowo „kontrola” bywa używane luźniej, niż na to zasługuje. W działaniu sprowadza się do czterech warstw, którymi organizacja albo zarządza, albo nie.

Dane

Ład danych zaczyna się od lokalizacji. Inferencja działa wewnątrz sieci, więc pytanie, które systemy przetworzyły zapytanie, ma jedną odpowiedź i jest ona lokalna. Nie ma telemetrii po stronie dostawcy na temat treści zapytań, bo nie ma strony dostawcy. Retencja podlega własnym harmonogramom organizacji. Ścieżka audytu powstaje w miejscu pracy, pod mechanizmami kontroli dostępu, które organizacja już stosuje - i to właśnie utrzymuje księgi finansowe raportowalne i rekonstruowalne na żądanie. Dla platform technologicznych dane najemców i własność intelektualna kodu źródłowego podlegają tej samej separacji, którą platforma już gwarantuje w każdej umowie z klientem.

Modele

Ład modeli oznacza, że to organizacja decyduje, która wersja modelu obsługuje produkcję. Usługi hostowane wycofują modele według własnych harmonogramów i mogą zmieniać zachowanie modelu za stabilną nazwą endpointu, co zamienia przypięcie wersji w usługową nadzieję. Na własnym stosie wersja obsługująca produkcję jest przypięta jawnie. Ulepszenia wchodzą według kalendarza organizacji, po tym jak następca został oceniony na jej własnych danych wzorcowych, a nie na publicznym benchmarku. Sprzęt nie musi się przy tej zmianie ruszać: lepsze modele przychodzą jako oprogramowanie i działają na tych samych maszynach. Modele o otwartych wachach z licencjami przyjaznymi komercyjnie utrzymują szeroki wachlarz opcji, a postawa licencyjna pozostaje po stronie organizacji.

Na własnym stosie wersja obsługująca produkcję jest przypięta jawnie. Ulepszenia wchodzą według kalendarza organizacji.

Konfiguracja

Ład konfiguracji obejmuje wszystko, co kształtuje zachowanie w czasie wykonania: parametry próbkowania, reguły routingu, bariery bezpieczeństwa, źródła wyszukiwania, prompty. Na prywatnym stosie są to artefakty wersjonowane pod kontrolą zmian organizacji. Każdy wynik da się wyśledzić do dokładnej konfiguracji, która go wygenerowała, i tę samą konfigurację można odtworzyć. Na hostowanym endpointcie część konfiguracji należy do dostawcy, a powtarzalność wyników zależy od jego polityki wersjonowania, nie od klienta.

Zmiana

Ład zmiany to warstwa, która decyduje, kiedy porusza się którakolwiek z powyższych warstw. Na prywatnym stosie wydania przechodzą przez własne bramki akceptacji organizacji i dyżury - te same, które przechodzi już każdy inny system produkcyjny. Żaden dostawca nie może wycofać endpointu spod działającego przepływu pracy. Prace migracyjne odbywają się dlatego, że organizacja je zaplanowała, a nie dlatego, że przyszedł komunikat o wycofaniu.

Dwie właściwości wzajemnie się wzmacniają

Kontrola czyni pojemność czytelną. Ponieważ wersje i konfiguracja są przypięte, pomiary przepustowości i latencji znaczą to samo kwartał po kwartale, a telemetria, która to dowodzi, należy do organizacji, a nie do konsoli dostawcy. Dyscyplinę pomiarową opisują wskaźniki, które pozwalają obronić inwestycję w AI po wdrożeniu: dokładność, czas cyklu, uniknięte koszty i adopcja, odczytywane względem linii bazowej przyjętej przed budową.

Pojemność czyni kontrolę przystępną cenowo. Ocena nowego modelu, zmienionej bariery bezpieczeństwa czy rozszerzonego przepływu pracy odbywa się na tym samym własnym sprzęcie, na rzeczywistym obciążeniu, bez licznika naliczającego eksperyment. Decyzje ładu korporacyjnego opierają się więc na zmierzonych dowodach, które organizacja wytworzyła sama.

Test dla każdej kandydującej architektury

Dla ewaluatora technicznego ten podział kondensuje się do dwóch sprawdzeń. Po pierwsze, zapytaj, kto ustala sufit: czy maksymalna przepustowość jest zmierzoną właściwością sprzętu, którym organizacja włada, czy przydziałem, który dostawca może przeskalować. Po drugie, zapytaj, kto podpisuje zmianę: czy decyzje o modelach, konfiguracji i wydaniach przechodzą przez bramki organizacji, czy dostawcy. Na prywatnym stosie obie odpowiedzi lądują po stronie organizacji. Pojemność i kontrola przestają wtedy być argumentami zakupowymi. Stają się właściwościami operacyjnymi, badanymi przy każdym przeglądzie, na dowodach, które wytwarza sam stos.

Zapytaj, kto ustala sufit i kto decyduje o zmianach w AI, które prowadzą Twoją firmę w przyszłość.