Benchmarki Nvidia Vera CPU pokazują przewagę w Pythonie nad Intelem i AMD

Procesor Vera firmy Nvidia prowadzi w kilku testach Pythona na tle serwerowych układów Intela i AMD, nadając mierzalne podstawy argumentacji firmy dotyczącej infrastruktury AI. Opublikowane 30 października benchmarki Nvidia Vera CPU porównują samodzielny procesor z Granite Rapids-AP Intela i EPYC Turin firmy AMD. Wskazują na istotne atuty, nie rozstrzygając jednak, która platforma najefektywniej obsługuje kompletne agenty AI.

To rozróżnienie ma znaczenie, ponieważ agentowe AI — oprogramowanie korzystające z narzędzi i wykonujące zadania w wielu krokach — zależy od czegoś więcej niż generowanie przez model. System może szybko tworzyć instrukcje, a mimo to odpowiadać wolno, czekając na wykonanie kodu, wyszukiwanie informacji lub walidację. Vera jest przeznaczona do obsługi tego otaczającego procesu, co stawia Nvidię w bezpośredniej konkurencji z uznanymi procesorami serwerowymi.

Kluczowa rywalizacja dotyczy Very i dotychczasowego podejścia Intela oraz AMD do obsługi tych obciążeń. Nabywcy muszą wiedzieć, czy zalety CPU utrzymują się w ich rzeczywistym oprogramowaniu, przy ich wymaganiach dotyczących współbieżności i wdrożenia. Dostępne dane przemawiają za poważnym rozważeniem Very, pozostawiając jednak szerokie twierdzenia o lepszej wydajności agentów do dalszych testów.

Benchmarki Nvidia Vera CPU wskazują przewagę zależną od obciążenia

Najmocniejszy wynik Very potwierdza konkurencyjność procesora serwerowego, a nie jego uniwersalne zwycięstwo w całej infrastrukturze AI. Niezależne benchmarki CPU Tom’s Hardware obejmują Pythona, testy pamięci i szersze obciążenia serwerowe. Ten zakres ma znaczenie, ponieważ procesor promowany pod kątem agentów nadal musi obsługiwać zwykłe zadania aplikacyjne.

Najbardziej klarowny dostępny wynik Pythona pochodzi z PyBench, benchmarku mierzącego czas wykonania podstawowych operacji Pythona. Publikacja podaje, że Vera ukończyła test o 4% przed AMD EPYC 9755. To konkretna przewaga w konkretnym teście, a nie miara tego, o ile szybciej działa cały asystent programistyczny.

Inne wyniki wzmacniają potrzebę analizowania poszczególnych wykresów. Vera ustępuje grupie porównawczej w teście CacheBench łączącym odczyt, modyfikację i zapis. Intel prowadzi w przedstawionym porównaniu przetwarzania promptów wyłącznie przez CPU, które mierzy przetwarzanie danych wejściowych przed generowaniem tekstu. Różne testy premiują różne elementy procesora i stosu oprogramowania.

Wyniki te czynią porównanie bardziej użytecznym niż prosta narracja o zwycięstwie. Zespół odpowiedzialny za zakupy może powiązać zaobserwowaną mocną stronę z obciążeniem, które rzeczywiście uruchamia. Może też wskazać obszary, w których pozornie odpowiedni procesor wymaga dodatkowej oceny przed przeniesieniem usług produkcyjnych.

Na szczególną uwagę zasługuje różnica między testami samodzielnego CPU a zintegrowanym systemem AI. Porównanie samodzielnych serwerów bada pracę wykonywaną przez procesor i otaczającą go platformę. Nie mierzy automatycznie interakcji z GPU, akceleratorem powszechnie używanym do uruchamiania dużych modeli AI.

Wdrożenie wspierane przez GPU może dzielić pracę inaczej niż test wyłącznie CPU. Operacja dominująca w samodzielnym benchmarku może mieć niewielki udział w czasie odpowiedzi wdrożonej usługi. Z kolei umiarkowane usprawnienie CPU może mieć znaczenie, gdy aplikacja wielokrotnie czeka na tę operację.

Użyteczna interpretacja ma zatem charakter warunkowy. Vera stanowi wiarygodną alternatywę tam, gdzie mierzone obciążenia przypominają aplikację nabywcy. Te same wyniki nie dowodzą, że każda baza danych, usługa inferencyjna lub aplikacja korporacyjna powinna przejść na Nvidię.

To również wyjaśnia, dlaczego szerokość benchmarków jest ważniejsza od prostoty nagłówka. Testowanie niepowiązanych zadań serwerowych pomaga ujawnić słabości, które wąsko dobrana demonstracja mogłaby pominąć. Nabywcy potrzebują tych granic, ponieważ serwery produkcyjne rzadko wykonują wyłącznie operację pokazywaną w prezentacji produktu.

Bezpośrednia zmiana polega na tym, że samodzielna wydajność Very zyskała kolejny publiczny punkt odniesienia. Następne pytanie dotyczy tego, jak blisko mierzone operacje odpowiadają pracy wykonywanej przez usługi agentowe.

Wydajność Pythona zwiększa presję na krótką listę CPU

Mocne wyniki Pythona dają Verze praktyczną możliwość wejścia do ocen, które wcześniej koncentrowały się na Intelu i AMD. Python, język programowania szeroko stosowany w oprogramowaniu AI, stanowi istotny punkt wyjścia. Jego wyniki benchmarków nadal wymagają interpretacji, zanim staną się dowodem zakupowym.

Rozważmy hipotetycznego agenta programistycznego, który edytuje plik, uruchamia skrypt walidacyjny i analizuje wynik przed kontynuowaniem. Model nie może ukończyć tej sekwencji wyłącznie dzięki szybszemu generowaniu tekstu. Krok walidacji musi się zakończyć, zanim następna decyzja będzie mogła wykorzystać jego wynik.

W takiej aplikacji szybsze wykonanie odpowiedniego skryptu może skrócić zależność w przepływie pracy. Istotne jest określenie „odpowiedniego skryptu”. Benchmark obejmujący wbudowane operacje języka nie odtwarza każdego pakietu, rozszerzenia ani podprocesu wywoływanego przez aplikację produkcyjną.

Aplikacje Pythona wykonują pracę w różnych miejscach. Niektóre spędzają znaczną część czasu na wykonywaniu przepływu sterowania na poziomie języka. Inne wywołują skompilowane biblioteki, kontaktują się ze zdalnymi usługami lub czekają na pamięć masową. Sam język aplikacji nie wskazuje, który zasób sprzętowy determinuje jej czas odpowiedzi.

Ogranicza to znaczenie przewagi wydajności Pythona, nie czyniąc jej nieistotną. Daje powód do testowania reprezentatywnych śladów aplikacji, czyli zarejestrowanych sekwencji rzeczywistych operacji. Nie pozwala pominąć takich testów.

Nvidia wyraźnie łączy Verę z wykonywaniem narzędzi i orkiestracją, czyli koordynowaniem pracy w aplikacji. Jej projekt dla obciążeń agentowych podkreśla utrzymującą się wydajność na rdzeń oraz dostęp do pamięci. Takie ujęcie wyjaśnia zainteresowanie firmy obciążeniami skryptowymi, lecz nie stanowi niezależnej walidacji każdej deklarowanej korzyści systemowej.

Presja na Intela i AMD jest w konsekwencji konkretna. Ich platformy muszą konkurować w operacjach CPU opóźniających użyteczny postęp aplikacji. Serwer o większej łącznej pojemności nie musi automatycznie szybciej kończyć pojedynczej zależnej operacji.

Równie ważne jest przeciwne stwierdzenie. Szybsza pojedyncza operacja nie dowodzi większej całkowitej pojemności usługi. Gdy wielu użytkowników pojawia się jednocześnie, planowanie, zużycie pamięci i konkurujące zadania mogą zmienić wynik. Nabywcy potrzebują zarówno responsywności, jak i wystarczającej pojemności do obsługi spodziewanego ruchu.

Dla programistów przesuwa to uwagę w stronę ustalenia, gdzie upływa czas między odpowiedziami modelu. Dla nabywców korporacyjnych dodaje kolejny procesor do krótkiej listy ocen. Dla użytkowników aplikacji każda korzyść zależy od tego, czy dostawca wdroży sprzęt poprawiający kroki, na które rzeczywiście czekają.

Wyniki Pythona wywierają więc presję konkurencyjną poprzez wiarygodne powiązanie z aplikacjami. Nie dowodzą, że sam język programowania definiuje cały rynek infrastruktury agentów.

Vera kontra EPYC Turin to więcej niż liczba rdzeni

Porównanie podważa założenie, że większa liczba rdzeni sama w sobie wskazuje lepszy procesor dla usługi agentowej. Rdzeń CPU jest jednostką wykonawczą wewnątrz procesora. Większa liczba rdzeni wspiera dodatkową pracę równoległą, ale pojedyncze zadania nie zawsze można skutecznie między nimi podzielić.

Vera ma 88 niestandardowych rdzeni Nvidia Olympus. Nvidia podaje, że każdy z nich obsługuje dwa wątki sprzętowe, czyli konteksty wykonawcze zarządzane przez procesor. Specyfikacje te opisują dostępne zasoby wykonawcze; nie oznaczają, że każda aplikacja uzyska równoważne skalowanie.

Specyfikacje procesorów EPYC firmy AMD wymieniają 128 rdzeni dla EPYC 9755 i 192 dla EPYC 9965. Produkty te reprezentują różne pozycje w tej samej rodzinie serwerowej. Traktowanie ich jako wymiennych „procesorów AMD” zaciera istotne porównanie.

Vera kontra EPYC Turin wymaga zatem wyraźnego pytania o obciążenie. Czy nabywca chce szybciej ukończyć pojedynczy skrypt, obsłużyć więcej niezależnych żądań czy skonsolidować usługi? Każdy cel może premiować inną równowagę między szybkością wykonania, pojemnością równoległą i dostępem do pamięci.

Intel należy do tej samej dyskusji. Jego platforma Xeon to kolejna ugruntowana droga do uruchamiania usług aplikacyjnych i pracy AI po stronie CPU. Porównanie benchmarków powinno bezpośrednio testować tę drogę, zamiast zakładać, że każda operacja związana z AI sprzyja Nvidii.

Przepustowość pamięci, czyli tempo przesyłania danych między pamięcią a procesorem, dodaje kolejny wymiar. Nvidia deklaruje do 1,2 TB/s dla pamięci LPDDR5X Very, technologii pamięci o niskim poborze energii. To opublikowana możliwość, a nie gwarancja, że aplikacja osiągnie taki transfer.

Aplikacja korzysta z przepustowości, gdy przenoszenie danych ogranicza jej postęp. Korzysta z niej mniej, gdy wykonanie zależy od zdalnej odpowiedzi lub sekwencji obliczeń. Duża deklarowana przepustowość nie może sama wskazać tych warunków.

To sprawia, że równowaga platformy jest ważniejsza niż pojedyncza specyfikacja. Zapewnienie jednostkom wykonawczym szybszego dostępu do danych może pomóc tylko wtedy, gdy tych danych potrzebują. Dodanie pojemności równoległej pomaga tylko wtedy, gdy aplikacja potrafi produktywnie z niej korzystać.

Vera kontra EPYC Turin najlepiej rozumieć więc jako porównanie dopasowania do obciążenia. Nabywcy powinni opierać się pokusie normalizowania każdego wyniku wyłącznie według rdzeni, gniazd lub wątków. Każdy mianownik odpowiada na inne pytanie i może ukrywać koszty w innych częściach systemu.

Liczba gniazd, czyli liczba zainstalowanych procesorów w serwerze, także zmienia granicę porównania. Przewaga na gniazdo i przewaga całego serwera to różne ustalenia. Żadnego z nich nie należy po cichu zastępować drugim podczas oceny wymagań wdrożeniowych.

Konkurencyjny wniosek jest prosty: Intel i AMD potrzebują odpowiedzi zależnych od obciążeń, a Nvidia musi wykazać korzyści wykraczające poza korzystne specyfikacje. Żaden z dostawców nie uzyskuje decyzji produkcyjnej wyłącznie dzięki liczbie rdzeni.

Szybsze kroki CPU nie przekładają się automatycznie na szybsze agenty

Mechanizm łączący szybkość CPU z wydajnością agentów jest wiarygodny, lecz jego wpływ zależy od rzeczywistego wąskiego gardła aplikacji. Wąskie gardło to zasób lub operacja ograniczająca postęp. Usprawnienie innej części systemu pozostawia to ograniczenie w dużej mierze bez zmian.

Wyobraźmy sobie agenta badawczego, który pobiera dokumenty, wyodrębnia fragmenty i prosi model o ich porównanie. Jeśli przetwarzanie dokumentów dominuje w opóźnieniu, szybsze wykonanie CPU zasługuje na uwagę. Jeśli dominuje zdalna usługa wyszukiwania, wymiana lokalnego procesora rozwiązuje mniejszą część problemu.

Ta sama logika dotyczy agentów programistycznych. Kompilacja, czyli przekształcanie kodu źródłowego w wykonywalne oprogramowanie, może zajmować istotne miejsce w sekwencji walidacji. Aplikacja może jednak zamiast tego spędzać większość czasu, czekając na wynik modelu, testy zewnętrzne lub dostęp do repozytorium.

Analiza przepustowości AI firmy Nvidia argumentuje, że opóźnienia po stronie CPU mogą wpływać na otaczającą usługę GPU. Jest to architektoniczne wyjaśnienie firmy, a nie niezależny pomiar każdego wdrożenia. Jego znaczenie zależy od sposobu planowania pracy przez usługę i zachowywania stanu aplikacji.

Ten argument poszerza zakres tego, co kupujący powinni mierzyć. Szybsze ukończenie wywołania narzędzia ma bezpośrednie znaczenie dla użytkownika, który na nie czeka. Każda dalsza korzyść dla wykorzystania akceleratorów wymaga dowodów z zintegrowanego systemu.

Wykorzystanie, czyli udział dostępnej mocy wykonującej użyteczną pracę, również może wprowadzać w błąd, gdy rozpatruje się je osobno. Obciążony procesor może wykonywać ponowne próby, nadmiarową pracę lub zadania, które nie dotrzymują terminów. Wysoka aktywność nie musi oznaczać wysokiej użytecznej wydajności.

Mocniejszą miarą jest ukończona praca przy jasno określonym wymaganiu dotyczącym usługi. W przypadku produktu do programowania może to oznaczać zweryfikowane zmiany zwrócone w akceptowalnym czasie odpowiedzi. W przypadku produktu badawczego mogą to być ukończone odpowiedzi z wymaganymi dowodami.

Te przykłady są celami ewaluacji, a nie raportowanymi wynikami Vera. Pokazują, dlaczego pomiary komponentów i pomiary aplikacji powinny występować razem. Pierwsze wskazują prawdopodobne mocne strony; drugie określają, czy te mocne strony poprawiają produkt.

Podobne rozróżnienie dotyczy średniej wydajności i opóźnień ogonowych, czyli czasu odpowiedzi odczuwanego przez najwolniejszą część żądań. Średnia może się poprawić, podczas gdy trudne żądania pozostają wolne. Współdzielone systemy produkcyjne wymagają uwagi poświęconej obu tym aspektom.

Aplikacje oparte na wiedzy wprowadzają kolejną granicę między wydajnością sprzętu a jakością informacji. Lepsze łączenie wiedzy i szybsze przetwarzanie dotyczą różnych części procesu tworzenia odpowiedzi. Szybsze wykonanie nie sprawia, że niekompletny zbiór źródeł staje się pełniejszy.

Testy porównawcze procesora Nvidia Vera uzasadniają zbadanie, gdzie wykonanie CPU ogranicza postęp agentów. Pozostawiają jednak właścicielom aplikacji obowiązek wykazania tego związku we własnych usługach. To wymóg inżynieryjny, a nie podważanie zmierzonych zysków.

Wybór kompilatora, pobór mocy platformy i wdrożenie nadal mają decydujące znaczenie

Porównanie procesorów staje się argumentem zakupowym dopiero wtedy, gdy analiza uwzględnia konfigurację oprogramowania, energię systemu i wymagania operacyjne. Czynniki te mogą zmienić wartość zaobserwowanej przewagi w benchmarkach. Zasługują na taką samą kontrolę jak architektura procesora.

Kompilator, czyli oprogramowanie przekształcające kod źródłowy w wykonywalne instrukcje, może istotnie wpływać na wynik testu. Różne ustawienia optymalizacji mogą zmieniać skuteczność wykorzystania dostępnego sprzętu przez aplikację. Powstałe porównanie obejmuje wybory programowe obok możliwości procesora.

Obecny przegląd ilustruje tę wrażliwość. Tom’s Hardware informuje o 10% poprawie po ponownym przetestowaniu obciążenia Intel z binariami zoptymalizowanymi pod oneAPI. W tym porównaniu Vera pozostała o 8,6% z przodu przy użyciu GCC, innego kompilatora. Wynik pokazuje zarówno utrzymującą się przewagę, jak i istotny wpływ oprogramowania.

Nie oznacza to, że każdy wynik wymaga użycia tego samego kompilatora, aby porównanie było uczciwe. Porównania międzyplatformowe często wymagają różnych narzędzi, aby odzwierciedlać praktyczne warunki wdrożenia. Wymagane jest ujawnienie tych wyborów i powiązanie ich z tym, co klienci mogą faktycznie uruchomić.

Ogólny build może odpowiadać na pytanie o przenośność. Dostrojony build może odpowiadać na pytanie o optymalizację platformy. Żaden z nich nie powinien być przedstawiany jako odpowiedź na każde pytanie programowe kupującego.

Historyczne warunki testów również wymagają ostrożności. Wczesne testy Vera przeprowadzone przez Phoronix korzystały ze sprzętu przedprodukcyjnego i ograniczonego dostępu do obciążeń. Recenzent opisał również ograniczenia w monitorowaniu poboru mocy i częstotliwości. Warunki te dotyczą tamtej wcześniejszej sesji i nie powinny automatycznie charakteryzować odrębnej recenzji z października.

To rozróżnienie ma znaczenie, ponieważ wstępna demonstracja i późniejsza ocena serwera mają różną wagę dowodową. Kupujący powinni pytać, co zostało zmierzone w konkretnym porównaniu, które czytają. Zastrzeżenia powinny wynikać z dowodów, zamiast stawać się trwałymi etykietami przypisywanymi produktowi.

Ocena energetyczna wymaga podobnej precyzji. Moc projektowa układu cieplnego, specyfikacja używana do planowania chłodzenia i zasilania, nie jest równa zmierzonemu zużyciu energii na ukończone zadanie. Same specyfikacje procesora nie mogą rozstrzygnąć kwestii wydajności całego systemu.

Porównanie wdrożeniowe powinno uwzględniać zasoby platformy wymagane do dostarczenia równoważnej pracy. Pamięć, sieć, magazyn danych i chłodzenie mogą wpływać na wynik. Znaczenie może mieć także czas, który system spędza na oczekiwaniu przy jednoczesnym poborze energii.

Gotowość operacyjna stwarza kolejne możliwe ograniczenie. Vera korzysta z Arm, architektury instrukcji procesora odmiennej od architektury x86 używanej przez porównywane układy Intel i AMD. Kupujący muszą ustalić, czy ich wymagane oprogramowanie i ustalenia dotyczące wsparcia działają akceptowalnie na docelowej platformie.

Nie jest to twierdzenie, że migracja z konieczności się nie powiedzie. To powód, aby przed podjęciem zobowiązania przetestować zależności, pakietowane aplikacje, monitoring i odzyskiwanie po incydentach. Zyski wydajności mają ograniczoną wartość, jeśli obsługa usługi powoduje niedopuszczalne zakłócenia.

Sceptyczny wniosek jest zatem węższy niż zarówno entuzjazm, jak i odrzucenie. Vera ma wiarygodne mocne strony, podczas gdy pełny przypadek wdrożeniowy pozostaje zależny od obciążenia. Nvidia, Intel i AMD powinny podlegać temu samemu wymogowi ujawniania konfiguracji i wykazywania użytecznych wyników produkcyjnych.

Trzy sygnały określą, co te wyniki będą dalej oznaczać

Kolejne dowody powinny połączyć powtarzalne zyski CPU z ukończoną pracą aplikacji i niezawodnym wdrożeniem. W ciągu najbliższych kilku miesięcy na szczególną uwagę zasługują trzy sygnały. Ich wartość polega na rozstrzyganiu niepewności, których obecne wykresy nie mogą wyjaśnić.

Pierwszym sygnałem jest szersze odtwarzanie wyników na systemach produkcyjnych. Niezależni recenzenci i klienci powinni publikować konfiguracje, wersje oprogramowania, wybory dotyczące dostrajania i kompletne wyniki. Powtarzalne mocne strony w porównywalnych systemach zwiększyłyby pewność, że przewagi Vera utrzymują się poza konkretnym środowiskiem testowym.

Takie odtwarzanie powinno zachowywać zarówno niekorzystne, jak i korzystne wyniki. Pojedyncza słabość może ujawnić granicę obciążenia istotną dla kupującego. Kompletny zestaw wyników jest bardziej użyteczny niż kolejny nagłówek zbudowany z wybranych zwycięstw.

Odtwarzanie wyników musi również odróżniać spójność od identycznych liczb. Różne systemy mogą osiągać różne wyniki bezwzględne, zachowując jednocześnie istotny wzorzec względny. Ważne pytanie brzmi, czy wyjaśnienie wytrzymuje analizę w tych konfiguracjach.

Drugim sygnałem jest porównanie aplikacji, które utrzymuje stałość zadania i wymaganej jakości wyniku. Szybsze uruchomienie znaczy niewiele, jeśli pomija walidację lub zwraca słabszy rezultat. Ukończona praca wymaga definicji, zanim platformy będzie można uczciwie porównać.

W przypadku agenta programistycznego takie porównanie powinno zachować model, zestaw zadań, narzędzia i kryteria akceptacji. W przypadku agenta badawczego powinno zachować wymagania dotyczące dowodów i proces ewaluacji. Są to proponowane warunki pomiaru, a nie twierdzenia o już ukończonych testach.

Wykazane skrócenie czasu realizacji ukończonych zadań wzmocniłoby związek między wynikami komponentów Vera a jej pozycjonowaniem dla agentów. Niewielka zmiana mimo szybszych operacji CPU sugerowałaby, że w tej aplikacji dominuje inny etap. Każdy z tych wyników byłby użyteczny.

Trzecim sygnałem są dowody wdrożeniowe od dostawców i partnerów systemowych. Szczegóły premiery Vera od Nvidia wskazują konfiguracje jednogniazdowe i dwugniazdowe wraz z planowaną dostępnością u partnerów. Zapowiedziane wsparcie potwierdza intencję; dostępne systemy i trwałe wyniki operacyjne stanowią dowód innego rodzaju.

Relacje klientów powinny wskazywać, co zostało przeniesione, co się poprawiło i co wymagało dostosowania. Przydatne ujawnienia omawiałyby zachowanie aplikacji, zgodność oprogramowania oraz pracę operacyjną potrzebną do utrzymania usługi. Ogłoszenie o wdrożeniu procesora bez tych szczegółów pozostawia kluczowe pytania zakupowe bez odpowiedzi.

Porównania konkurencyjne muszą również nadążać za dostępnymi alternatywami. Wynik wobec wskazanej generacji pozostaje dowodem dotyczącym tej generacji. Kupujący powinni aktualizować krótką listę, gdy zmieniają się ich opcje zakupowe, zachowując starsze wyniki jako historyczne punkty odniesienia.

Łącznie te sygnały przesunęłyby dyskusję od obietnicy architektonicznej w stronę oceny wdrożenia. Dają też Intel i AMD jasną ścieżkę odpowiedzi: wykazać równoważną użyteczną pracę w porównywalnych warunkach operacyjnych. Nvidia podlega temu samemu standardowi.

Obecne dowody już zmieniają sposób oceny. Vera zasługuje na rozważenie jako samodzielna platforma CPU, szczególnie tam, gdzie jej zmierzone mocne strony odpowiadają charakterystyce aplikacji. Testy porównawcze procesora Nvidia Vera nie ustanawiają bezwarunkowego zastępstwa dla istniejących serwerów.

Przed kolejną decyzją infrastrukturalną zidentyfikuj pracę CPU, która faktycznie opóźnia Twoją aplikację. Oddziel lokalne wykonanie od generowania przez model, usług zdalnych i oczekiwania na magazyn danych. Następnie porównaj kompletne zadania na dostępnych platformach, zachowując spójność jakości wyników i wymagań operacyjnych. Zachowaj konfiguracje i niekorzystne wyniki obok sukcesów. Użyteczne pytanie brzmi, czy Vera szybciej kończy Twoją pracę, efektywniej wykorzystuje zasoby i pasuje do Twojego środowiska operacyjnego. Poproś dostawców o dowody na tej granicy. Przewaga w Pythonie zasługuje na bliższą ocenę; decyzja produkcyjna powinna wynikać z zachowania usługi, od której zależą Twoi użytkownicy.