Wstęp - dlaczego w ogóle o tym mówimy
Kiedy mówimy dziś „AI”, niemal automatycznie myślimy o wielkich modelach językowych (LLM) i o kartach GPU za dziesiątki tysięcy dolarów. Tymczasem ogromna część realnej, produkcyjnej pracy modeli uczenia maszynowego to znacznie skromniejsze, ale niezwykle praktyczne zadania: klasyfikacja, detekcja, kontrola jakości, wykrywanie anomalii. I tu rządzą zupełnie inne prawa ekonomiczne.
W ramach projektu badawczego prowadzonego przez Netwise S.A. dla klienta z branży transportowej zbudowaliśmy podstawy systemu do wykrywania anomalii na obrazach. Model dotrenowaliśmy na zbiorach specyficznych dla obszaru działania klienta. Docelowym środowiskiem była chmura Microsoft Azure, a środowisko lokalne służyło do developmentu i jako benchmark.
Ten artykuł nie jest o trenowaniu modeli ani o fine-tuningu – tych tematów świadomie nie poruszamy. Jest o czymś, co bardzo często umyka na etapie planowania: o samej inferencji – czyli o uruchamianiu gotowego modelu na produkcji. To właśnie inferencja, powtarzana tysiące czy miliony razy, generuje realny, comiesięczny koszt. I to tutaj zapadają decyzje, które potrafią zaważyć na opłacalności całego projektu.
Jedna uwaga o tym, jak czytać dalsze liczby. Samą inferencję – konkretny zbiór danych, parametry uruchomienia, szczegóły konfiguracji modelu – traktujemy tu jako black box. Ujawniamy to, co istotne dla wniosków: model, porównywane konfiguracje sprzętowe, framework i kontekst projektu. Nie wchodzimy natomiast w głębokie szczegóły techniczne, bo dla tej historii nie mają one znaczenia – a wartości, które pokazujemy, pochodzą z realnego projektu badawczego, nie z syntetycznego testu „na pokaz”. Chodzi o zależności i proporcje między płaszczyznami, a nie o pojedyncze milisekundy w oderwaniu od kontekstu.
Pokażemy cztery płaszczyzny, które warto wziąć pod uwagę, planując inferencję – a wnioski mają bezpośrednie przełożenie również na projekty z modelami generatywnymi, w tym LLM.
Czym jest PatchCore i biblioteka Anomalib
Do testów wybraliśmy model PatchCore, jeden z najpopularniejszych algorytmów wykrywania anomalii wizualnych, dostępny w bibliotece Anomalib.
Anomalib to otwarta biblioteka deep learning rozwijana w ramach ekosystemu Intel/OpenVINO, zbierająca najnowsze algorytmy detekcji anomalii i umożliwiająca ich benchmarking na publicznych i prywatnych zbiorach danych (Anomalib, dokumentacja). Co istotne dla naszego tematu, Anomalib natywnie wspiera eksport modelu do kilku formatów uruchomieniowych – m.in. PyTorch, ONNX oraz OpenVINO (Anomalib – Get Started). To pozwala uruchomić ten sam wytrenowany model na różnych „silnikach” inferencji – z czego skorzystamy w ostatniej części artykułu.
PatchCore działa w uproszczeniu tak:
- z obrazów „normalnych” (bez wad) sieć pretrenowana na ImageNet wyciąga cechy fragmentów obrazu (patchy),
- cechy te trafiają do tzw. memory bank (banku pamięci), redukowanego metodą coreset subsampling do reprezentatywnego podzbioru (Bonview Press, PatchCore),
- podczas inferencji dla każdego fragmentu nowego obrazu liczona jest odległość do najbliższego sąsiada w banku pamięci (nearest-neighbour search); im większa odległość, tym bardziej „anomalny” jest dany fragment (PatchCore – Anomaly Scoring).
Dla tego artykułu kluczowe są dwie rzeczy. Po pierwsze, PatchCore uczy się wyłącznie na przykładach poprawnych – nie potrzebuje katalogu wszystkich możliwych wad, co jest ogromną zaletą w realnych wdrożeniach. Po drugie, inferencja PatchCore to w dużej mierze wyszukiwanie najbliższego sąsiada i ekstrakcja cech – operacje, które, jak się przekonamy, wcale nie wymagają GPU, żeby działać sensownie.
Chmura kontra środowisko lokalne – i o czym naprawdę mówimy
Zanim przejdziemy do liczb, ustalmy ramy porównania, bo łatwo tu o nieporozumienie.
Po jednej stronie mamy chmurę publiczną (Microsoft Azure) – maszyny rozliczane za godzinę pracy, dostępne od ręki, skalowalne w górę i w dół. Po drugiej stronie mamy środowisko lokalne (on-premises) – ale celowo nie w wersji „własna serwerownia z kartami GPU za setki tysięcy dolarów”. Takie porównanie byłoby nieuczciwe i oderwane od realiów większości firm.
Zamiast tego po stronie lokalnej stawiamy trzy maszyny, na które stać praktycznie każdą organizację albo nawet pojedynczego dewelopera:
- przeciętny laptop biznesowy (HP ProBook),
- MacBook Air (typowy sprzęt deweloperski),
- wydajną stację roboczą klasy „AI PC” z nowoczesnym CPU, szybką pamięcią, dyskami NVMe i kartą GPU klasy desktopowej – ale nie serwerowej.
To ważne rozróżnienie: zarówno użyte usługi Azure, jak i lokalne maszyny to wydatki w zasięgu firmy dowolnej wielkości. Nie porównujemy chmury z hiperkosztowną infrastrukturą HPC, tylko z realistycznymi opcjami, przed którymi staje klient.
Porównywane konfiguracje
Wszystkie testy wykonaliśmy na tym samym modelu PatchCore i na tych samych danych wejściowych, mierząc średni czas pojedynczej inferencji w milisekundach. Przypominamy: szczegóły techniczne samej inferencji traktujemy jako black box – dla porównania liczy się to, że dla każdej konfiguracji warunki były identyczne, a jedyną zmienną był najpierw sprzęt, a potem framework.
Środowisko chmurowe - Microsoft Azure (region Sweden Central)
| Maszyna (SKU) | Typ | Procesor / akcelerator | vCPU | Cena pay-as-you-go (USD/h) |
|---|---|---|---|---|
| Standard_NC24ads_A100_v4 | GPU (+ CPU) | NVIDIA A100 PCIe 80 GB / AMD EPYC 7V13 (Milan) | 24 | 4.0461 |
| Standard_D4ads_v6 | CPU | AMD EPYC 9004 (Genoa) | 4 | 0.2068 |
| Standard_D4ds_v6 | CPU | Intel Xeon Platinum 8573C (Emerald Rapids) | 4 | 0.2245 |
| Standard_D4pds_v6 | CPU | Azure Cobalt 100 (Arm64) | 4 | 0.1661 |
Trzy właściwe maszyny CPU dobrano tak, by miały tę samą liczbę rdzeni/wątków (4 vCPU), ale różne procesory – dwa x86-64 (AMD, Intel) i jeden Arm64 (Azure Cobalt). To pozwala porównać samą architekturę i wydajność CPU „przy innych warunkach równych”.
Ważne zastrzeżenie: maszyna Standard_NC24ads_A100_v4 to opcja czysto GPU – w Azure nie ma wariantu z kartą A100 i jedynie 4 vCPU. Towarzyszy jej serwerowy procesor EPYC 7V13 (Milan) z minimum 24 vCPU, czyli sześciokrotnie więcej rdzeni niż maszyny CPU z tej tabeli. Dlatego jej wyniku na samym CPU nie zestawiamy wprost z maszynami 4 vCPU – pomiar CPU na tej maszynie robimy „przy okazji”, żeby pokazać, co potrafi potężny (i bardzo kosztowny) procesor serwerowy. Punktem odniesienia dla tej maszyny pozostaje jej GPU.
Środowisko lokalne (on-premises / deweloperskie)
| Maszyna | Typ | Procesor / akcelerator |
|---|---|---|
| "AI PC" workstation | GPU (+ CPU) | Intel Core Ultra 5 245K / Intel Arc Pro B50 16 GB |
| HP ProBook 440 G9 | CPU | Intel Core i5-1235U |
| MacBook Air (A2681) | CPU | Apple M2 |
Środowisko software (do którego wrócimy w sekcji 8): Ubuntu Linux 24.04 (poza MacBookiem, gdzie macOS), Python 3.12, framework PyTorch – a w drugiej rundzie OpenVINO 2026.
Płaszczyzna pierwsza – sam procesor potrafi zrobić różnicę
Zacznijmy od najprostszego pytania: jak bardzo różni się czas inferencji na maszynach CPU o identycznej liczbie rdzeni (4 vCPU), ale z różnymi procesorami? Porównujemy tu wyłącznie trzy maszyny z tej samej półki, żeby zmienną był sam procesor, a nie liczba rdzeni. Poniżej średnie czasy inferencji na frameworku PyTorch (mniej = lepiej):
| Maszyna CPU (4 vCPU) | Śr. czas inferencji - PyTorch (ms) |
|---|---|
| Azure - Intel Xeon 8573C (Emerald Rapids) | 313.0 |
| Azure - Azure Cobalt 100 (Arm64) | 344.7 |
| Azure - AMD EPYC 9004 (Genoa) | 484.8 |
To, że różne procesory dają różne czasy, jest oczywiste. Ciekawa jest skala tej różnicy: przy tej samej liczbie rdzeni najszybszy procesor (Intel Xeon Emerald Rapids) jest ok. 1,55x szybszy od najwolniejszego (AMD EPYC Genoa). Innymi słowy: dwie maszyny „4 rdzenie” w tej samej cenie potrafią różnić się wydajnością o połowę.
Dla kontekstu warto pokazać, co potrafi procesor z zupełnie innej półki. Maszyna GPU Standard_NC24ads_A100_v4 ma serwerowy EPYC 7V13 (Milan) z 24 vCPU – i na samym CPU (mierzonym „przy okazji”, bo to maszyna GPU) osiąga 180,5 ms, czyli ok. 1,7× szybciej niż najlepsza maszyna 4 vCPU. Nie jest to porównanie „równy z równym” – ten procesor ma sześciokrotnie więcej rdzeni i należy do znacznie droższej maszyny. Pokazuje jednak, że serwerowa moc CPU robi różnicę, do której ceny wrócimy za chwilę.
To pierwszy sygnał, że liczba rdzeni nie mówi całej prawdy – a wybór konkretnego SKU ma realne konsekwencje. Co prowadzi nas wprost do pytania o pieniądze.
Płaszczyzna druga – liczy się koszt utrzymania maszyny, nie cena za inferencję
Sama prędkość niewiele mówi, dopóki nie zestawimy jej z ceną. I tu trzeba od razu obalić wygodny mit: w praktyce, w scenariuszach tego typu, nie płacimy ani za inferencję, ani za 1000 inferencji. W takim scenariuszu, nawet „w chmurze”, płacimy za czas, w którym maszyna jest włączona – a w większości dzisiejszych scenariuszy oznacza to utrzymanie co najmniej jednej maszyny każdego potrzebnego typu w trybie ciągłym, 24/7, przez cały miesiąc.
| Maszyna Azure | Cena (USD/h) | Koszt / miesiąc (730 h) |
|---|---|---|
| Standard_D4pds_v6 (Cobalt, Arm, 4 vCPU) | 0.1661 | ~$121 |
| Standard_D4ads_v6 (EPYC Genoa, 4 vCPU) | 0.2068 | ~$151 |
| Standard_D4ds_v6 (Xeon Emerald Rapids, 4 vCPU) | 0.2245 | ~$164 |
| Standard_NC24ads_A100_v4 (GPU, 24 vCPU) | 4.0461 | ~$2,954 |
Proporcje są bezlitosne. Utrzymanie maszyny GPU przez miesiąc kosztuje ok. 24× więcej niż najtańszej maszyny CPU (~2 954 USD vs ~121 USD) – różnica rzędu 2 800 USD miesięcznie na jedną maszynę. Co więcej, można utrzymać wszystkie trzy różne maszyny CPU jednocześnie (łącznie ~436 USD/mc) i nadal jest to blisko 7× taniej niż jedna maszyna GPU. To jest realny rachunek, który trafia na fakturę – niezależnie od tego, ile inferencji faktycznie wykonaliśmy.
A gdyby jednak rozliczać per 1000 inferencji? (scenariusz SaaS)
Dla porządku pokażmy też miarę, którą często przyjmuje się intuicyjnie – koszt 1000 inferencji (czas inferencji × cena godzinowa, znormalizowane do 1000 próbek, PyTorch):| Maszyna Azure | Śr. czas (ms) | Koszt 1000 inferencji (USD) |
|---|---|---|
| Standard_D4pds_v6 (Cobalt, Arm, 4 vCPU) | 344.7 | 0.0159 |
| Standard_D4ads_v6 (EPYC Genoa, 4 vCPU) | 484.8 | 0.0279 |
| Standard_D4ds_v6 (Xeon Emerald Rapids, 4 vCPU) | 313.0 | 0.0195 |
| Standard_NC24ads_A100_v4 - CPU only (EPYC Milan, 24 vCPU) | 180.5 | 0.2029 |
Ta miara ma sens tylko w jednym świecie: gdybyśmy kupowali inferencję jako gotową usługę SaaS rozliczaną per 1000 inferencji. Wtedy nie płacimy za włączoną maszynę, tylko za faktyczne użycie – i jeśli założymy, że po stronie dostawcy SaaS ryzyko braków GPU jest mniejsze (bo to on zarządza pulą sprzętu i współdzieli ją między wielu klientów), dla klienta końcowego byłoby to rozwiązanie niemal idealne: płacisz tylko za to, czego używasz, bez ryzyka utrzymywania drogiej, bezczynnej maszyny.
Jest jednak haczyk. Model per-1000-inferencji niemal zawsze oznacza współdzielenie zasobów sprzętowych z innymi klientami. To z kolei podnosi poziom zaufania, jakim trzeba obdarzyć vendora – wobec danych (często wrażliwych obrazów produkcyjnych), izolacji workloadów i gwarancji dostępności. Dla jednych klientów to akceptowalny kompromis, dla innych (np. ze względów regulacyjnych czy poufności) – nie. To realna oś decyzji, którą warto świadomie rozegrać.
Wracając do naszego scenariusza – utrzymania własnych maszyn w chmurze – to jest moment, w którym GPU pojawia się w zestawieniu jako opcja. Przyjrzyjmy mu się uczciwie.
Płaszczyzna trzecia – dokładamy GPU i maszyny lokalne
Teraz dorzucamy do porównania GPU oraz maszyny lokalne. Najpierw GPU w chmurze. Karta NVIDIA A100 na frameworku PyTorch wykonuje inferencję w ok. 11,6 ms (po pominięciu pierwszej, „rozgrzewkowej” próbki, która wyniosła 278,5 ms – to typowy efekt cold-startu / kompilacji kerneli na GPU). To imponujące: ok. 15-40× szybciej niż maszyny CPU. Ale przełóżmy to na miarę, która faktycznie trafia na fakturę – koszt utrzymania maszyny przez miesiąc:| Opcja (chmura, 24/7) | Śr. czas (ms) | Koszt / miesiąc (730 h) |
|---|---|---|
| A100 GPU (PyTorch, "warm") | 11.6 | ~$2,954 |
| D4pds - Cobalt CPU (PyTorch) | 344.7 | ~$121 |
Tu pada pierwsze ważne stwierdzenie artykułu: GPU jest ~30× szybsze per inferencja, ale jego utrzymanie kosztuje ~24× więcej miesięcznie. Prędkość GPU jest realna – tyle że w scenariuszu „maszyna włączona na okrągło” płacimy za nią niezależnie od tego, ile inferencji rzeczywiście przez nią przepuściliśmy. Jeśli model nie jest obciążony non-stop w 100%, ta prędkość w dużej części marnuje się, a rachunek biegnie dalej.
GPU wygrywa wtedy, gdy potrzebujemy niskiej latencji w czasie rzeczywistym albo bardzo wysokiej, stałej przepustowości, która faktycznie wysyca kartę. Ale dla wielu scenariuszy wsadowych (batch) – a takich jest w przemyśle mnóstwo – CPU jest w pełni wystarczające i znacząco tańsze w utrzymaniu.
Do różnicy w cenie dochodzi dostępność. Na czerwiec 2026 rynek GPU w chmurze jest mocno napięty: analizy branżowe opisują pojemność on-demand kart Nvidii jako praktycznie wyprzedaną — „cała pojemność wchodząca do sierpnia–września 2026 jest już zarezerwowana” (SemiAnalysis za ICLE), a uzyskanie kart często wymaga formalnej rezerwacji i kilkutygodniowego oczekiwania na limity nawet u hyperscalerów (Spheron – Azure H100 2026). To kolejny, mocny argument za CPU: maszyn CPU — zwłaszcza przy strategii korzystania z wielu rodzin, a często wystarczy nawet jedna — prawdopodobnie nigdy nie zabraknie, a ryzyko niedoboru jest nieporównanie niższe niż przy GPU. W praktyce oznacza to, że maszynę CPU da się utrzymać w ciągłej gotowości bez obawy, że po zwolnieniu nie odzyskamy zasobu — czego o GPU dziś powiedzieć nie można.
Teraz maszyny lokalne (framework PyTorch, czas inferencji w ms):
| Maszyna lokalna | Procesor | Śr. czas - PyTorch (ms) |
|---|---|---|
| Stacja „AI PC" (CPU) | Intel Core Ultra 5 245K | 164.2 |
| MacBook Air | Apple M2 | 170.5 |
| HP ProBook 440 G9 | Intel Core i5-1235U | 571.2 |
Wynik jest pouczający: lokalna stacja robocza (164,2 ms) na CPU bije każdą chmurową maszynę CPU 4 vCPU – i to bez użycia GPU. Co więcej, wyprzedza nawet serwerowy EPYC Milan z 24 vCPU (180,5 ms) z maszyny A100. Nawet zwykły MacBook Air (170,5 ms) wypada lepiej niż wszystkie maszyny 4 vCPU w Azure. Z drugiej strony przeciętny laptop biznesowy (i5-1235U, 571,2 ms) jest najwolniejszy w całym teście – co pokazuje, że „lokalnie” to bardzo pojemne pojęcie.
Wniosek pośredni: nowoczesny, dobrze dobrany CPU – także w laptopie czy stacji roboczej – to poważna baza dla inferencji. GPU nie jest koniecznością. Ale to wciąż nie koniec historii, bo dotąd zmienialiśmy tylko sprzęt. A co, jeśli przy tym samym sprzęcie zmienimy software?
Płaszczyzna czwarta – software bywa ważniejszy niż kolejny rdzeń
Do tej pory wszystkie testy działały na Ubuntu 24.04 (poza macOS na MacBooku), Python 3.12 i frameworku PyTorch. Czym jest PyTorch? To najpopularniejszy dziś framework deep learning, ceniony za elastyczność i ogromny ekosystem. Świetnie sprawdza się zarówno w treningu, jak i w inferencji, działa na CPU i GPU.
Jest naturalnym, „domyślnym” wyborem – i właśnie dlatego rzadko ktoś pyta, czy istnieje coś lepszego do samej inferencji na CPU.
Otóż istnieje. Wprowadzamy zmienną: ten sam model, te same maszyny, ten sam system – ale framework inferencji zmieniamy z PyTorch na Intel OpenVINO 2026.
Czym jest OpenVINO? To otwarty toolkit Intela do optymalizacji i uruchamiania inferencji, zaprojektowany tak, by wycisnąć maksimum z procesorów Intel (CPU oraz GPU Intel Arc), ale działający też na innych architekturach. OpenVINO optymalizuje graf obliczeniowy modelu, dobiera kwantyzację i tryby wykonania pod konkretny sprzęt (OpenVINO – Optimize Inference).
| Maszyna CPU | PyTorch (ms) | OpenVINO (ms) | Przyspieszenie | Redukcja czasu |
|---|---|---|---|---|
| Azure - EPYC Genoa (4 vCPU) | 484.8 | 333.0 | 1.46× | −31% |
| Azure - Cobalt Arm (4 vCPU) | 344.7 | 249.2 | 1.38× | −28% |
| Azure - Xeon Emerald Rapids (4 vCPU) | 313.0 | 245.6 | 1.27× | −22% |
| Azure - EPYC Milan (24 vCPU, GPU machine) | 180.5 | 131.3 | 1.38× | -27% |
| Local - Core Ultra 5 245K | 164.2 | 126.4 | 1.30x | -23% |
| Local - i5-1235U | 571.2 | 451.0 | 1.27x | -21% |
| Local - Apple M2 | 170.5 | 159.5 | 1.07x | -6% |
Sama zmiana frameworka dała 20-31% skrócenia czasu inferencji na większości maszyn CPU – bez dokładania ani jednego rdzenia, ani złotówki na sprzęt. Co ciekawe, najmniejszy zysk widać na Apple M2 (−6%) – co jest spodziewane, bo OpenVINO jest optymalizowany pod sprzęt Intela, a nie Apple Silicon.
A teraz domknięcie ekonomiczne. Pamiętajmy o tym, co ustaliliśmy w sekcji o płaszczyźnie drugiej: w realnym scenariuszu płacimy za włączoną maszynę, a nie za inferencję. Co więc daje przejście na OpenVINO przy stałym, miesięcznym koszcie utrzymania maszyny? Daje więcej przerobionych obrazów za tę samą stawkę. Skoro koszt miesięczny maszyny CPU się nie zmienia (~121-164 USD/mc, zależnie od SKU), a inferencja jest o 20-31% szybsza, to ta sama maszyna – za te same pieniądze – przepuści w miesiącu o 20-31% więcej obrazów. To czysty zysk przepustowości wynikający z warstwy software, bez dokładania sprzętu i bez podnoszenia rachunku.
Uwaga – GPU nie zawsze wygrywa z CPU.
Ciekawy niuans tej samej rundy testów: w stacji „AI PC” karta Intel Arc Pro B50 pod OpenVINO osiąga 255,9 ms – czyli wolniej niż CPU tej samej maszyny (Intel Core Ultra 5 245K: 126,4 ms). Innymi słowy, dla tego typu modelu konsumencki/profesjonalny GPU Intel nie zawsze daje przewagę nad dobrze dobranym CPU. To kolejny dowód, że „dołożenie akceleratora” nie jest automatyczną odpowiedzią – liczy się dopasowanie sprzętu, frameworka i charakterystyki modelu.
| Maszyna Azure (vCPU) | Koszt 1000 inf. - PyTorch (USD) | Koszt 1000 inf. - OpenVINO (USD) |
|---|---|---|
| D4pds - Cobalt (Arm, 4 vCPU) | 0.0159 | 0.0115 |
| D4ds - Xeon Emerald Rapids (4 vCPU) | 0.0195 | 0.0153 |
| D4ads - EPYC Genoa (4 vCPU) | 0.0279 | 0.0191 |
| A100 - GPU (24 vCPU, reference) | 0.0131 | - |
I tu pada puenta całego artykułu – i jest ona spójna w obu miarach. W ujęciu per 1000 inferencji (hipotetyczny scenariusz SaaS) najtańsza maszyna CPU z OpenVINO kosztuje 0,0115 USD – czyli mniej niż karta A100 (0,0131 USD), która jest ~30× szybsza per inferencja. A w ujęciu miesięcznego utrzymania maszyny (scenariusz realny) ta sama maszyna CPU to ~121 USD/mc wobec ~2 954 USD/mc za GPU. Obie miary wskazują w tę samą stronę: software – a nie kolejny rdzeń czy GPU – okazał się dźwignią, która przesunęła punkt opłacalności.
Punkt przecięcia wszystkich płaszczyzn
- Procesor ma znaczenie - dwie maszyny „4 rdzenie" w tej samej półce cenowej potrafią różnić się wydajnością ok. 1,55× (Intel Xeon vs AMD EPYC Genoa). Sam wybór SKU - bez zmiany ceny - robi różnicę.
- Liczy się koszt utrzymania maszyny, a nie cena za inferencję - w realnym scenariuszu płacimy za maszynę włączoną 24/7, a nie za pojedyncze inferencje: ~121 USD/mc za CPU wobec ~2 954 USD/mc za GPU (~24× drożej). Rozliczanie per 1000 inferencji - idealne dla klienta - ma sens wyłącznie w modelu SaaS, ten zaś oznacza współdzielenie zasobów i wymaga wyższego zaufania do vendora.
- GPU nie jest koniecznością - a w 2026 bywa też trudno dostępne - A100 jest ~30× szybsze per inferencja, ale przy zadaniach wsadowych dobrze dobrany CPU wygrywa rachunek ekonomiczny; do tego GPU jest dziś towarem deficytowym (rezerwacja z wyprzedzeniem, ryzyko niedoboru), podczas gdy o CPU - znacznie łatwiej. Nowoczesny CPU (także lokalny) to solidna baza inferencji.
- Software bywa ważniejszy niż hardware - sama zmiana frameworka z PyTorch na OpenVINO dała 20-31% skrócenia czasu inferencji: przy stałym koszcie utrzymania maszyny to 20-31% więcej przerobionych obrazów za te same pieniądze - i przesunięcie najtańszej maszyny CPU poniżej kosztu GPU w obu miarach.
Wszystkie te płaszczyzny przecinają się w jednym punkcie – i jest to punkt biznesowy, nie tylko techniczny. Wydajność inferencji to nie wyłącznie kwestia „dołóżmy rdzeni” albo „kupmy GPU”. To suma decyzji o procesorze, modelu rozliczeń, lokalizacji obliczeń i – co najczęściej pomijane – o warstwie software.
Jeśli z tego artykułu warto zapamiętać jedną myśl, to tę: najszybszym sposobem na to, by rachunek za GPU przestał boleć, nie jest mniejsze GPU. To odpowiedni framework.
Dodawanie kolejnych rdzeni czy kart GPU to najprostsza strategia – ale rzadko najtańsza czy najlepsza. W naszym projekcie większą wartość dała umiejętność rozpoznania problemu, przetestowania kilku konfiguracji i dopasowania rozwiązania do sytuacji – takiego, które osiąga lepsze wyniki na tańszej infrastrukturze, bo to warstwa programowa, a nie sprzęt, została lepiej zaprojektowana.
Hardware nie jest całą historią. Software zresztą też nie. Dobry partner projektowy jest właśnie po to, żeby połączyć jedno z drugim – dobierając sprzęt, framework i model rozliczeń tak, by wnioskowanie kosztowało jak najmniej, a jednocześnie dawało najlepszy możliwy wynik.
Ale to nie koniec obrazu: kiedy odpowiedni sprzęt i framework są już wybrane, pojawia się pytanie, jak opakować to wszystko w system, który faktycznie działa w produkcji.
Poza pojedynczą maszyną wirtualną - wdrożenie produkcyjne w Azure
Gdy projekt wychodzi poza pojedynczy benchmark, pojawiają się pytania, na które „jedna włączona maszyna” już nie odpowiada: jak skalować inferencję pod zmienne obciążenie? jak przetworzyć duże, wsadowe paczki obrazów w nocy? jak wersjonować model, wdrażać nową wersję bez przestoju, monitorować jakość i koszty? Tu wchodzą usługi orkiestracji, a wybór konkretnej zależy od całości scenariusza, który mamy zrealizować:
Azure Machine Learning (Azure ML) – naturalny wybór dla większości scenariuszy ML. Pozwala opakować wytrenowany model w zarządzane endpointy: online endpoints do inferencji w czasie rzeczywistym (stabilny URI, uwierzytelnianie, terminacja TLS, autoskalowanie) oraz batch endpoints do przetwarzania dużych wolumenów danych „od czasu do czasu”. To właśnie ten podział – online vs batch – najczęściej decyduje o tym, czy w ogóle potrzebujemy GPU, czy wystarczy dobrze dobrany CPU (do czego wracaliśmy w poprzednich rozdziałach).
Azure Batch – usługa do zadań obliczeniowych o charakterze wsadowym. Sprawdza się tam, gdzie inferencja to nie ciągły strumień zapytań, lecz okresowe, duże „przeloty” przez zbiory danych – i gdzie zależy nam na pełnej kontroli nad pulą maszyn i harmonogramem.
Microsoft Foundry – platforma Microsoft do budowy aplikacji i agentów AI (do niedawna znana jako Azure AI Foundry), w której zunifikowano inferencję, ewaluacje, monitoring oraz Foundry Agent Service. Po Foundry sięgamy zwłaszcza wtedy, gdy detekcja anomalii ma być elementem szerszego rozwiązania AI – np. współpracować z modelami generatywnymi, agentami czy warstwą oceny jakości.
Innymi słowy: VM to cegła, a nie cały budynek. To, czy postawimy na Azure ML, Azure Batch, czy Foundry, wynika z kształtu całego scenariusza – charakteru ruchu (online vs wsadowy), wymagań co do latencji, skali, integracji z resztą systemu i modelu kosztowego.
AI/ML Landing Zone - czyli „JAK" wdrażać, a nie tylko „NA CZYM"
Wcielenie tych usług do produkcji zwykle nie kończy się na ich włączeniu. Oznacza budowę dedykowanej strefy AI/ML w ramach Azure Landing Zone – czyli określonego zestawu zasad, wytycznych i predefiniowanych konfiguracji, które mówią zespołom jak wdrażać: jak segmentować sieci, jak zarządzać tożsamością i dostępem, jak szyfrować i izolować dane, jak monitorować koszty i bezpieczeństwo, jak utrzymać zgodność (compliance).
Warto rozwiać częste nieporozumienie: zgodnie z aktualnymi wytycznymi Microsoft Cloud Adoption Framework nie buduje się zwykle osobnej, oddzielnej „AI Landing Zone” obok istniejącej – workloady AI wdraża się do aplikacyjnych landing zones na fundamencie standardowej platformowej Azure Landing Zone, tak samo jak każdy inny workload.
W praktyce zasoby AI (Azure ML, Foundry, magazyny danych) trafiają do subskrypcji typu Application Landing Zone, zgodnie z zasadą „demokratyzacji subskrypcji” (Cloud Adoption Framework – AI updates and Landing Zone design). Daje to gotowy, „dobrze zaprojektowany” fundament (well-architected) z wbudowanym bezpieczeństwem, zgodnością i efektywnością operacyjną. Co istotne, taki fundament można wdrażać jako kod, co czyni go powtarzalnym i audytowalnym.
PoC kontra produkcja - co naprawdę składa się na wdrożenie
Pełne wdrożenie produkcyjne to jednak złożenie w całość kilku warstw:
- Przygotowanie danych – pozyskanie, oczyszczenie, oznaczenie i wersjonowanie zbiorów (w przypadku PatchCore: reprezentatywnych obrazów „normalnych”).
- Przygotowanie i trening/dotrenowanie modelu – w ramach powtarzalnego, śledzonego procesu (eksperymenty, metryki, rejestr modeli). (Przypomnienie: trening i fine-tuning to świadomie temat poza zakresem tego artykułu – wymieniamy je tu tylko jako składową pełnego cyklu.)
- Wdrożenie kilku środowisk (MLOps) – typowo dev / test / produkcja, z automatyzacją wdrożeń, monitoringiem jakości modelu i kosztów oraz mechanizmem bezpiecznej wymiany wersji.
- Złożenie całości zgodnie z wytycznymi AI Landing Zone – tak, by sieci, tożsamość, dane i zgodność spełniały reguły organizacji, a wszystko dało się odtworzyć i audytować.
Dlaczego to ma znaczenie dla wniosków z tego artykułu
Ta perspektywa wzmacnia, a nie podważa, wcześniejsze konkluzje. Skoro produkcyjny system inferencji i tak osadzamy w warstwie orkiestracji i ładu (governance), to wybór, czy pod spodem pracuje drogie GPU, czy tańszy CPU, staje się świadomą decyzją architektoniczną – a nie domyślnym odruchem. Azure ML czy Azure Batch równie dobrze zorkiestrują pulę maszyn CPU, jak i GPU; różnica trafia wprost na fakturę i w dostępność zasobów. A to znaczy, że największą wartość wnosi nie sam sprzęt, lecz ktoś, kto potrafi dobrać właściwą usługę orkiestracji, zaprojektować strefę zgodnie z dobrymi praktykami i poskładać to w działający, opłacalny system – czyli dokładnie ta rola, do której wracamy w zakończeniu.
Jeśli planujesz własny pipeline wnioskowania i zastanawiasz się, czy Twój przypadek użycia rzeczywiście wymaga GPU, czy raczej lepszego frameworku – albo jak przejść od benchmarku do systemu gotowego na produkcję – skontaktuj się z nami. To dokładnie te pytania, na które wolimy odpowiadać liczbami, a nie sloganami.
