Latest / M365.FM – podcast o Microsoft 365, Copilot i AI po polsku / Wolna inferencja na GPU zdemaskowana: fallback na CPU, konflikty wersji CUDA/TensorRT i błędy kontenerów (Dubbing AI)

Transcript

Wolna inferencja na GPU zdemaskowana: fallback na CPU, konflikty wersji CUDA/TensorRT i błędy kontenerów (Dubbing AI) · M365.FM – podcast o Microsoft 365, Copilot i AI po polsku

• 0:00
  Zaczęło się od ostrzeżenia, potem zapadła cisza.
• 0:02
  Rachunek za GPU rusł, jakby akcelerator nigdy nie spał, a mimo to wyniki spływały tak wolno, jakby zgasły światła.
• 0:07
  Dashboardy świeciły na zielono, klienci nie.
• 0:09
  Ta anomalia do niczego nie pasowała.
• 0:11
  Bliskie zeru wykorzystanie GPU przy gwałtownym wzroście opóźnień.
• 0:15
  Żadnych alertów, żadnych czerwonych linii, po prostu czas przeciekający przez palce.
• 0:18
  Dowody wskazują na jedną patologię, która podszywa się pod normalność.
• 0:22
  Oto obietnica.
• 0:23
  Przeanalizujemy artefakty, nazwiemy winowajce i naprawimy usterkę.
• 0:26
  Zbadamy trzy tryby awarii, przełączenie na CPU, niezgodność wersji między cuda i ONNX Tensorszt oraz błędną konfigurację kontenera,
• 0:33
  a następnie udowodnimy to, porównując opóźnienia, przepustowość i wykorzystanie GPU przed i po naprawie.
• 0:38
  Konfiguracja przypadku, środowisko i profil ofiary.
• 0:41
  Każda konfiguracja opowiada pewną historię, a ta zaczyna się od zwykłego użytkownika pod presją.
• 0:46
  Obciążenie to dyfuzja tekstu na obraz, warianty stable diffusion działające w 512 na 512 i skalujące się do 1024 na 1024.
• 0:53
  Ruch jest skokowy. Współbieżność waha się między 8 a 32 żądaniami.
• 0:58
  Rozmiary partii wahają się od 1 do 8.
• 1:00
  Poziomy usług są rygorystyczne w kwestii opóźnień końcowych.
• 1:02
  Naruszenia P95 przekładają się bezpośrednio na zwroty kosztów i kary.
• 1:05
  Modele nie są egzotyczne, ale wybory z nimi związane mają znaczenie.
• 1:08
  Potoki stable diffusion eksportowane do ONNX, optymalizacje cross-attention,
• 1:12
  takie jak sformers lub scalet dot product attention oraz wybory harmonogramu, które zamieniają kroki na jakość.
• 1:17
  Ekosystem ma przyspieszać, gdy infrastruktura działa poprawnie.
• 1:20
  Sprzęt na papierze wygląda przyzwoicie.
• 1:23
  Karty Nvidia RTX i serii A w chmurze 16 do 32 GB VRAM.
• 1:27
  Magistrala PCIe znajduje się między hostem a urządzeniem niczym punkt poboru opłat.
• 1:30
  Wystarczająco szybka, gdy jest skonfigurowana i zabójcza, gdy powiązania i owracają do transferów stronicowalnych.
• 1:34
  W tym środowisku nic nie jest przypadkowe.
• 1:36
  Łańcuch narzędzi układa się w znane warstwy.
• 1:38
  Pythorch służy do eksportu, a potem ONNX Runtime lub Tensorst przejmuje wnioskowanie.
• 1:42
  Sterowniki cuda znajdują się pod wszystkim.
• 1:44
  Jądra Attention obiecują szybkość, jeśli wersje są zgodne.
• 1:48
  Wdrożenie jest ściśle konteneryzowane, obrazy niezmienne, wdrożenia sterowane ci.
• 1:52
  Polityka Blue Green.
• 1:53
  To ograniczenie powinno zapewniać bezpieczeństwo.
• 1:56
  Może jednak również zakonserwować błędy.
• 1:58
  Stawki biznesowe nie są abstrakcyjne.
• 2:00
  Koszt żądania definiuje marżę.
• 2:01
  Rezerwacje GPU wyceniane godzinowo, niezależnie od tego, czy jądra działają, czy nie.
• 2:05
  Gdy opóźnienie wydłuża się z sekund do pół minuty, przepustowość załamuje się.
• 2:08
  Jedna błędna konfiguracja zmienia akcelerator w grzejnik.
• 2:11
  Drogi, cichy i zajęty robieniem czegoś, co nie pomaga kolejce.
• 2:14
  Przy bliższym przyjrzeniu się profil ofiary zawęża się.
• 2:17
  Współbieżność 16, partie po dwie, aby pozostać poniżej limitów VRAM przy 512, przechodząc do 1024 roku dla jakości.
• 2:24
  Użytkownik oczekuje spójnego P95.
• 2:27
  Zamiast tego ślady pokazują nieregularne opóźnienia, szerokie delty między P50 a P95 oraz cykle pracy GPU oscylujące od 5% do 40% bez wyraźnego powodu.
• 2:36
  Wykresy CPU mówią co innego.
• 2:38
  Rdzenie obciążone, choć brak przetwarzania wstępnego, by to uzasadnić.
• 2:41
  Dowody wskazują na trzy możliwe przyczyny.
• 2:43
  Po pierwsze, awaryjne przełączenie na CPU.
• 2:45
  Gdy dostawca wykonań cuda lub tensorszt nie może się załadować, silnik po cichu wybiera wykres CPU.
• 2:50
  Model działa, ale z od 10 do 30-krotnie większym opóźnieniem.
• 2:53
  Po drugie, niezgodność wersji.
• 2:54
  ONNX Runtime skompilowany pod jedno cuda, węzły używające innego, silniki tensorszt unieważnione i przebudowane z ogólnymi jądrami.
• 3:02
  Wykorzystanie jest widoczne, ale szybkie ścieżki zniknęły.
• 3:05
  Po trzecie, błędna konfiguracja kontenera, przeładowane obrazy, brak zamontowanych urządzeń GPU, złe ustawienia NVID, a container toolkit oraz obszary pamięci przetrzymujące, alokacje, co zwiększa opóźnienia końcowe pod obciążeniem.
• 3:15
  Ostatecznie nie jest to zagadka dotycząca modeli, to sprawa dotycząca uczciwości infrastruktury.
• 3:20
  Prześledzimy artefakty, kolejność dostawców, logi możliwości, punkty montowania urządzeń i powiążemy je z trzema niezmiennymi metrykami, opóźnieniem, przepustowością i wykorzystaniem GPU.
• 3:30
  Plik dowodowy, a awaryjne przełączenie na CPU, cichy sabotażysta.
• 3:35
  Zaczęło się od zapytania, które powinno zająć sekundy, a nie zajęło.
• 3:38
  Wskaźnik GPU był cichy, zbyt cichy.
• 3:41
  Wykres CPU tymczasem wzrósł jak alarm przeciwpożarowy.
• 3:43
  Po bliższym przyjrzeniu się, silnik dokonał wyboru.
• 3:46
  Uruchomił zadanie przeznaczone dla GPU na procesorze.
• 3:48
  Żaden alert się nie włączył.
• 3:50
  Wynik w końcu się pojawił.
• 3:51
  Oto cichy sabotażysta, awaryjne przełączenie na CPU.
• 3:54
  Dlaczego to ważne?
• 3:55
  To proste.
• 3:55
  Stable diffusion na procesorze to strata czasu.
• 3:58
  Model działa, ale opóźnienie rośnie wielokrotnie od 10 do 30 razy wolniej, a przepustowość drastycznie spada.
• 4:03
  W środowisku, gdzie sprzedaje się milisekundy, ta różnica jest krytyczna.
• 4:06
  Rachunek nalicza czas GPU, ale urządzenie nie wykonuje pracy.
• 4:09
  Oś czasu ujawniła wzorzec.
• 4:10
  Kontenery, które lokalnie działały z cuda, śmigały.
• 4:13
  Po wdrożeniu do węzła klastra z nieco innym stosem sterowników, te same kontenery uruchamiały się, odpowiadały na sondy zdrowia, a potem zwalniały.
• 4:19
  Punkt końcowy zdrowia sprawdzał tylko, czy serwer działa, więc nigdy nie sprawdzał, czy GPU faktycznie wykonuje pracę.
• 4:25
  W tym środowisku nic nie jest przypadkowe.
• 4:27
  Cisza to artefakt.
• 4:29
  Głównym artefaktem jest kolejność dostawców wykonań w ONN X Runtime.
• 4:33
  Silnik akceptuje listę, spróbuj ten sorszt, potem cuda, potem CPU.
• 4:37
  Jeśli cuda nie zainicjuje się zły sterownik, brak bibliotek, niezamontowane urządzenie ORT po cichu przypisze dostawcę wykonań CPU.
• 4:44
  Brak wyjątku, brak awarii, tylko linijka w logach często ukryta na dole.
• 4:48
  Dostawca wykonań cuda niedostępny przełączam na CPU.
• 4:51
  Ta linijka to wyznanie, którego większość zespołów nigdy nie czyta.
• 4:54
  A teraz najdziwniejsza część.
• 4:55
  Wykresy wykorzystania wyglądają na pierwszy rzut oka zwodniczo normalnie.
• 4:58
  Zapytania nadal się kończą.
• 5:00
  Mapa usług świeci się na zielono, ale cykl pracy GPU utrzymuje się na poziomie 5%,
• 5:03
  podczas gdy zużycie procesora przez użytkownika jest wysokie i stałe.
• 5:06
  Opóźnienie P50 rośnie czterokrotnie, a P95 wymyka się spod kontroli.
• 5:09
  Nagłe skoki ruchu tylko pogarszają sprawę.
• 5:11
  Kolejki rosną, a autoskalowanie dodaje kolejne repliki, z których każda dziedziczy tę samą wadę.
• 5:15
  Wyobraź sobie sztafetę, w której sprinter się nie zjawia, więc jego odcinek biegnie bibliotekarz.
• 5:24
  Podczas śledzenia sekwencji uruchamiania szybko pojawiają się dowody problemów.
• 5:29
  Dzienniki ładowania dostawców pokazują próby inicjalizacji cuda wraz z weryfikacją wersji sterownika.
• 5:33
  Jeśli kontener zbudowano w oparciu o cuda 12.2, a węzeł ma tylko 12.0, inicjalizacja kończy się niepowodzeniem.
• 5:39
  Jeśli zestaw narzędzi NVID i a-container toolkit nie jest skonfigurowany,
• 5:42
  montowanie urządzenia nigdy nie pojawi się w kontenerze.
• 5:44
  Brak dev Nvidia oznacza brak libcuda.
• 5:47
  Jeśli więc specyfikacja podanie rząda GPU wprost, harmonogram nigdy nie przypisze urządzenia.
• 5:52
  Każda z tych przyczyn wywołuje cichą degradację wydajności.
• 5:55
  Odtworzenie błędu jest proste.
• 5:58
  Na źle skonfigurowanym węźle prosta inferencja wskazuje dostawcę CPU zamiast oczekiwanego tensorszt lub cuda.
• 6:07
  Wysłanie pojedynczego promptu pozostawia GPU w stanie bezczynności.
• 6:10
  Wątki CPU gwałtownie rosną, a obraz wraca po od 20 do 40 sekundach zamiast po 2 do 6.
• 6:15
  Powtórz to na węźle z właściwymi sterownikami i montowaniami.
• 6:18
  Ten sam prompt kończy się w ułamku czasu, a cykl pracy GPU wchodzi w stabilny zakres.
• 6:22
  Dowody sugerują, że obecne zabezpieczenia są tylko fasadowe.
• 6:25
  Sondy zdrowia zwracają 200, ponieważ serwer odpowiada.
• 6:28
  Brak jest asercji przy starcie, która potwierdzałaby, że ścieżka GPU działa.
• 6:31
  Sondy wydajności nie istnieją, więc orkiestracja uznaje repliki za sprawne.
• 6:35
  System nie potrafi odróżnić akceleracji od emulacji.
• 6:37
  Środek zaradczy jest z założenia radykalny.
• 6:40
  Całkowita awaria, jeśli dostawca wykonawczy GPU jest nieobecny lub działa nieprawidłowo.
• 6:44
  Odmowa uruchomienia z użyciem CPU w środowisku produkcyjnym.
• 6:47
  Przy uruchomieniu procesu wylicz dostawców, sprawdź, czy załadowano tensorszt lub cuda i czy liczba urządzeń jest zgodna z oczekiwaniami.
• 6:54
  Zaloguj zestaw możliwości QDNN, dostępne rdzenie tensorą, limity pamięci i zakończ z kodem błędu, jeśli czegokolwiek brakuje.
• 7:01
  Poświęć dostępność na rzecz integralności i pozwól orkiestratorom przenieść zadania na zdrowy węzeł.
• 7:05
  Aby to zapewnić, wprowadź weryfikację wiązania we W.
• 7:08
  Przypisz wejścia i wyjścia do pamięci urządzenia i zweryfikuj prostą inferencję przy starcie.
• 7:12
  Jeden rozgrzewkowy przebieg, który uruchamia jądro Fused Attention.
• 7:15
  Jeśli czas przekroczy limit opóźnienia, uznaj ścieżkę za zdegradowaną i zrestartuj poda.
• 7:20
  Dodaj zestaw promptów kontrolnych z deterministycznymi ziarnami losowości.
• 7:23
  Porównaj opóźnienia z oknem bazowym.
• 7:25
  Jeśli odchylenie przekracza tolerancję, wyślij alert i zatrzymaj wdrażanie.
• 7:29
  Może się to wydawać surowe, ale alternatywa jest znacznie gorsza.
• 7:32
  Klaster, który działa jednocześnie marnując czas i budżet.
• 7:35
  Zablokuj kolejność dostawców, odrzuć użycie procesora, fallback i wymuś, by system udowodnił szybkość, zanim uznamy go za sprawny.
• 7:41
  Dopiero wtedy zielony kolor oznacza akcelerację.
• 7:44
  Dowód B. Niedopasowanie wersji, niekompatybilność, cuda ONNX i TensorSzt.
• 7:48
  Jeśli GPU nie zostało użyte, kolejne pytanie brzmi, czy mogłoby działać z pełną prędkością, nawet jeśli jest obecne?
• 7:54
  Dowody wskazują na bardziej subtelną awarię.
• 7:56
  Wersje są na tyle zgodne, by uruchomić system, ale nie na tyle, by odblokować szybką ścieżkę.
• 8:00
  System wygląda na przyspieszony, dopóki nie spojrzysz na zegary.
• 8:03
  Powód, dla którego to ważne, jest oczywisty.
• 8:04
  Potoki dyfuzyjne zależą od wydajności mechanizmu Attention.
• 8:08
  Gdy ONNX Runtime i TensorSzt nie mogą załadować oczekiwanych połączonych jąder Fused Kernels,
• 8:13
  przez różnice w wersjach cuda, cudne lub TensorSzt, cicho przełączają się na implementacje ogólne.
• 8:17
  Model działa.
• 8:19
  Wykorzystanie oscyluje wokół od 30 do 50%, a opóźnienia przekraczają budżet.
• 8:24
  Kompilacja wygląda tak samo, praca jest wolniejsza.
• 8:26
  Przy bliższym przyjrzeniu się, artefakty są precyzyjne.
• 8:29
  Logi ładowania dostawców ogłaszają sukces z pewnym, ale...
• 8:32
  Powrót do domyślnych jąder lub wyłączone z Formers.
• 8:36
  Zobaczysz, że deserializacja planu TensorSzt zawodzi, wymuszając przebudowę silnika, co inicjuje kompilację na węźle.
• 8:42
  Silniki zbudowane na jednej wersji MinorTensorSzt nie zdeserializują się na innej.
• 8:46
  Przebudowa kończy się sukcesem, ale wynikowy plan może pomijać Fused Attention lub optymalizację FP16.
• 8:51
  Wyścig dobiega końca.
• 8:52
  Bez skoków wydajności, cykle pracy rdzeni Tensor pozostają stłumione.
• 8:55
  Oto część sprzeczna z intuicją.
• 8:57
  Zespoły interpretują fakt, że system działa jako optymalny.
• 9:00
  W tym środowisku nic nie jest przypadkowe.
• 9:03
  Jeśli Scaled Dot Product Attention nie jest aktywne, jeśli Sformers jest wyłączone, jeśli Cudny zgłasza ograniczony obszar roboczy, wydajność uprzejmie się załamuje.
• 9:10
  Mówiąc prościej, niedopasowane pliki binarne wymuszają użycie jąder, które częściej przenoszą dane w pamięci kosztem gęstości obliczeń.
• 9:15
  Pcie staje się widoczne w śladach Traces.
• 9:17
  Opóźnienia końcowe, Tail Latencies, rosną wraz ze wzrostem współbieżności.
• 9:20
  Potraktuj stos oprogramowania jak zestaw zamków.
• 9:23
  Sterownik, zestaw narzędzi Cuda, Cudne, flagi kompilacji, ONNX Runtime i TensorSzt.
• 9:28
  Jeden ząbek nie na swoim miejscu i klucz obraca się tylko do połowy.
• 9:31
  Ord ogłasza graf możliwości dla każdego dostawcy wykonawczego.
• 9:34
  Jeśli skompilowany Ord oczekuje Cuda 12.2, a sterownik węzła udostępnia 12.1, Cuda ładuje się z ograniczonymi funkcjami lub wcale.
• 9:42
  Jeśli na węźle jest TensorSzt 8.6, a plany wygenerowano w 8.4, deserializacja zawodzi i generuje je ponownie z użyciem konserwatywnych taktyk.
• 9:50
  System po cichu przedkłada poprawność nad szybkość.
• 9:52
  Benchmarki dowodzą strat w praktycznym ujęciu. Z aktywnym sformers lub SDP mechanizm Attention w dyfuzji mierzalnie skraca czas rzeczywisty.
• 10:00
  Badania konsekwentnie pokazują przyspieszenie od 2x do 5x w ścieżce Attention w zależności od rozdzielczości i rozmiarów sadu.
• 10:06
  Wyłączając je przez rozbieżność wersji tracisz te mnożniki.
• 10:09
  Token Merging Tome sumuje się z tymi zyskami.
• 10:12
  Bez połączonych jąder korzyść jest ograniczona przepustowością pamięci i niezoptymalizowanymi układami.
• 10:17
  Różnica potęguje się przy rozdzielczości 1024 na 1024 i wyższej współbieżności.
• 10:22
  Aby śledzić artefakty, zacznij od wyliczenia możliwości.
• 10:24
  Przy starcie wypisz dokładną listę dostawców i zgłaszane przez nich funkcje.
• 10:28
  Wersja TensorSt, dostępność FP16 i INT8, maksymalna przestrzeń robocza, heurystyka, splotu cudne, obecność NCCL dla wielu GPU.
• 10:38
  Dla środowiska wykonawczego ONNX zrzuć priorytety app.
• 10:41
  TensorSt, cuda, a następnie CPU.
• 10:43
  Zweryfikuj, co faktycznie łączy się z węzłami Twojego grafu.
• 10:47
  Zaloguj, czy węzły uwagi są przypisane do TensorSt ze scalonymi jądrami, czy do ogólnych jąder cuda.
• 10:52
  Następnie sprawdź środowisko.
• 10:54
  Odpytaj sterownik NVID i ASM i pokazuje moduł jądra i kompatybilność z cuda.
• 10:58
  Odczytaj wersję bibliotek w kontenerze.
• 11:00
  Libcuda, libcublas, libcan, libnywinfer.
• 11:03
  Jeśli obraz zawiera biblioteki cuda 12.3, a sterownik hosta obsługuje do 12.2,
• 11:07
  tryb kompatybilności środowiska uruchomieniowego może wczytać się z ograniczeniami.
• 11:11
  Jeśli obraz oczekuje na główku w TensorSt 8.6, a wtyczka węzła dostarcza 8.4,
• 11:15
  wywołania API ulegną degradacji lub anulują niektóre optymalizacje.
• 11:18
  Rozwiązaniem jest macierz budowania, a nie życzenia.
• 11:21
  Zablokuj dokładne wersje w jednym źródle prawdy.
• 11:23
  Obraz bazowy z kompatybilnością sterowników, wersją podrzędną cuda, cudne,
• 11:28
  haszem kompilacji ORD i wersją TensorSt.
• 11:30
  Przygotuj obrazy inferencji zgodnie z tą macierzą i odrzucaj węzły,
• 11:33
  które nie pasują poprzez etykiety węzłów i kontrolę przyjęcia.
• 11:35
  Wstępnie buduj i buforuj silniki TensorSt dla każdego wariantu modelu i rozdzielczości na dokładnie tej wersji TensorSt, którą wdrażasz.
• 11:41
  Traktuj pliki planu jako artefakty powiązane z macierzą.
• 11:44
  Nigdy nie polegaj na budowaniu silnika na węźle w środowisku produkcyjnym.
• 11:47
  Maskuje to dry w wersji i wydłuża zimne starty.
• 11:50
  Aby to utrzymać, dodaj testy dymne Ci, które potwierdzają możliwości jądra.
• 11:54
  Uruchom kontener w izolowanym środowisku z docelowym sterownikiem i zweryfikuj,
• 11:57
  czy TensorSt wczytuje używane jądra FP16,
• 12:00
  czy węzły uwagi są scalone,
• 12:01
  czy wiązanie IO jest aktywne i czy Sformers lub SDP są rozpoznawane.
• 12:05
  Uruchom deterministyczny zestaw promptów i przerwi budowanie,
• 12:08
  jeśli opóźnienie przekracza bazowe okno
• 12:09
  lub jeśli logi zawierają komunikaty o przełączaniu na inne tryby.
• 12:13
  Przechowuj migawkę możliwości wraz z sumą kontrolną obrazu,
• 12:15
  aby wycofanie zmian przywracało zarówno kod, jak i charakterystykę wydajności.
• 12:19
  Ostatecznie dowody wskazują, że dry w wersji to nie błąd, jak widać.
• 12:22
  To szybkość, za którą płacisz.
• 12:24
  System będzie działać.
• 12:25
  Zegary złożą świadectwo.
• 12:27
  Dowód plik C – kontener.
• 12:28
  Erozja wydajności przez błędną konfigurację w projekcie.
• 12:33
  Nawet gdy wersje są zgodne, kontener może od wewnątrz sabotować wydajność.
• 12:37
  Dowody wskazują na powolny wyciek, rozrost obrazu,
• 12:39
  brakującą infrastrukturę GPU i zachowanie alokatora,
• 12:42
  które zniekształca opóźnienia pod obciążeniem.
• 12:44
  Nic się nie zawiesza.
• 12:45
  Wszystko ulega degradacji.
• 12:47
  Dlaczego to ważne jest proste?
• 12:49
  Kontenery kształtują rzeczywistość wykonawczą.
• 12:51
  Jeśli obraz jest ociężały, a zimne starty się wleką,
• 12:54
  repliki przybywają spóźnione do incydentu.
• 12:56
  Jeśli urządzenia GPU nie są zamontowane lub środowisko uruchomieniowe
• 12:59
  nie ma odpowiednich flag, dostawcy wykonawczy działają nieprawidłowo.
• 13:02
  Jeśli obszary pamięci gromadzą alokację,
• 13:04
  rotacja RAM wywołuje stronicowanie i skoki opóźnień.
• 13:06
  Model wygląda dobrze.
• 13:08
  Kontener po cichu obciąża każde żądanie.
• 13:10
  Przy bliższym przyjrzeniu się,
• 13:11
  artefakty gromadzą się podczas budowania.
• 13:14
  Obrazy przekraczają 2 GB,
• 13:15
  wypchane kompilatorami, nagłówkami i testami,
• 13:18
  bo brak budowania wieloetapowego.
• 13:19
  Brak Docker Ignore wpuszcza notatniki,
• 13:21
  cache i eksperymentalne wagi do warstw produkcyjnych.
• 13:24
  Każde wdrożenie przesyła gigabajty przez sieć.
• 13:27
  Przeskaluj to na pulę węzłów,
• 13:29
  a zimny start stanie się normą, niewyjątkiem.
• 13:31
  Dowody nie są tajemnicze.
• 13:33
  Historia Dockera opowiada historię w warstwach.
• 13:35
  Środowisko uruchomieniowe ujawnia drugi poziom erozji.
• 13:38
  Bez jawnych flag GPU,
• 13:40
  braku GPU w Dockerze lub konfiguracji
• 13:42
  wtyczek urządzeń w Kubernetes,
• 13:44
  proces nie widzi urządzeń NVIDIA.
• 13:46
  Błędna konfiguracja zestawu narzędzi kontenera NVIDIA
• 13:50
  ukrywa LiMQDA,
• 13:51
  więc dostawca wykonawczy ładuje się z ograniczeniami lub wcale.
• 13:55
  MIG nie są wymuszane,
• 13:56
  więc obciążenia walczą o plasterki pamięci,
• 13:58
  generując straty, których planiści nie rozumieją.
• 14:00
  Logi pozostają grzeczne, a wydajność wycieka.
• 14:02
  Zachowanie pamięci to trzeci poziom.
• 14:04
  Domyślnie obszar pamięci cuda w ONNX Runtime
• 14:07
  agresywnie cachuje alokację.
• 14:08
  Przy współbieżności wygląda to na stabilność,
• 14:10
  dopóki obszar nie zarezerwuje zbyt wiele
• 14:12
  i nie zagłodzi nowych żądań.
• 14:14
  Pamięć przypięta nie jest ustawiona,
• 14:15
  więc transfery host urządzenie
• 14:16
  idą przez bufory stronicowalne,
• 14:18
  zmieniając pcie w wąskie gardło.
• 14:20
  Wejście-wyjście nie jest przypisane do urządzenia,
• 14:22
  więc tensory skaczą między CPU a GPU,
• 14:24
  tworząc ukryte koszty opóźnień.
• 14:25
  Zachowanie ogonowe pogarsza się najpierw,
• 14:27
  potem podąża za nim mediana.
• 14:29
  Oto jak objawy wyglądają w praktyce.
• 14:31
  Efektywna przepustowość kuleje
• 14:32
  mimo umiarkowanego użycia GPU.
• 14:34
  Opóźnienie przy lekkim obciążeniu jest akceptowalne,
• 14:36
  ale P95 chwieje się przy współbieżności,
• 14:42
  tworząc efekt stada.
• 14:44
  Restartujący się kaskadowo autoskalowanie drga,
• 14:46
  a kolejki rosną od nowa.
• 14:47
  Operatorzy szukają błędnej przyczyny,
• 14:48
  wierząc, że model jest ciężki,
• 14:50
  podczas gdy polityki kontenera powodują upadek.
• 14:52
  Pomyśl o higienie kontenerów,
• 14:53
  jak o zabezpieczaniu dowodów.
• 14:54
  Budowanie wieloetapowe usuwa odciski palców.
• 14:56
  Kompilatory i narzędzia deweloperskie
• 14:57
  nigdy nie wchodzą do środowiska uruchomieniowego.
• 14:59
  Obraz bazowy Distroles lub Slim
• 15:00
  zwęża powierzchnię ataku
• 15:01
  i skraca czas pobierania.
• 15:03
  Audyty Docker Slim lub DAEW
• 15:04
  potwierdzają, co przetrwało budowanie.
• 15:05
  Plik Docker Ignore zapobiega
• 15:07
  przypadkowemu gromadzeniu zbędnych plików.
• 15:09
  Efektem jest czystość kryminalistyczna.
• 15:11
  Uruchamia się tylko to, co powinno.
• 15:13
  Instalacja GPU wymaga jawnych deklaracji.
• 15:15
  W Dockerze zadeklaruj wszystkie GPU
• 15:17
  lub dokładny plasterek MIG.
• 15:19
  W Kubernetes żądaj zasobów GPU NVIDIA
• 15:21
  i upewnij się, że wtyczka urządzenia
• 15:23
  pasuje do gałęzi sterownika.
• 15:25
  Przy starcie potwierdź obecność urządzenia
• 15:26
  i kompatybilność sterownika.
• 15:28
  Konfiguracje NVID i ASME i LD
• 15:30
  nie są dla ozdoby, to kontrole dostępu.
• 15:32
  Jeśli czegoś brakuje lub jest niedopasowane,
• 15:33
  zaloguj to jako naruszenie i wyjdź.
• 15:35
  Następnie dostrój ONNX Runtime i Tensor z rozmysłem.
• 15:38
  Zablokuj kolejność dostawcy wykonawczego
• 15:40
  tylko do ścieżek GPU na produkcji.
• 15:41
  Rozważ wyłączenie lub ponowną konfigurację
• 15:43
  obszaru pamięci cuda, gdy gromadzi on zasoby
• 15:45
  poza Twoim zestawem roboczym.
• 15:47
  Ogranicz wzrost lub ustaw przealokację
• 15:49
  na przewidywalne limity.
• 15:50
  Włącz FP16 domyślnie, gdy pozwalają na to bariery dokładności.
• 15:54
  Zabezpiecz i NT8 testem dokładności.
• 15:57
  Powiąż i OS pamięcią urządzenia,
• 15:58
  aby wejścia trafiały tam,
• 15:59
  gdzie odbywają się obliczenia
• 16:00
  i wybieraj strumienie świadomie,
• 16:02
  by zapobiec blokowaniu kolejki.
• 16:04
  Wymuś to za pomocą dwóch bramek,
• 16:05
  stanu i wydajności.
• 16:06
  Stan to nie tylko kod 200,
• 16:08
  to zweryfikowany migawka możliwości.
• 16:10
  Dostawcy załadowani,
• 16:11
  połączone jądra obecne,
• 16:12
  wdzenie tensorą rozpoznane i opowiązane.
• 16:15
  Wydajność to bazowy zestaw poleceń,
• 16:17
  który uruchamia się na rozgrzewkę
• 16:18
  z oknem opóźnienia
• 16:19
  i minimalnym progiem utylizacji.
• 16:21
  Jeśli kontener nie osiąga obu,
• 16:22
  nie zostaje dopuszczony do obsługi.
• 16:24
  Dołącz budżety rozmiaru pobierania do Ci,
• 16:26
  aby obrazy przekraczające progi
• 16:27
  i przerywały budowanie.
• 16:28
  Przechowuj różnice zawartości obrazów
• 16:30
  dla każdego skrótu,
• 16:31
  aby wycofania przywracały kod i porządek.
• 16:33
  Dowody wskazują,
• 16:34
  że kontenery nie tylko wdrażają oprogramowanie,
• 16:36
  one kodują zachowanie pod obciążeniem.
• 16:38
  Gdy są hałaśliwe,
• 16:39
  ciężkie lub niejasne w kwestii GPU,
• 16:41
  zmieniają akcelerację w ceremonie.
• 16:43
  Gdy są lekkie, konkretne i asertywne,
• 16:44
  zachowują szybką ścieżkę,
• 16:45
  za którą zapłaciłeś.
• 16:46
  W tym środowisku nic nie jest przypadkowe.
• 16:49
  Kontener albo pomaga GPU w pracy,
• 16:50
  albo wchodzi w drogę.
• 16:52
  Laboratorium kryminalistyczne,
• 16:53
  metryki, które wydają wyrok.
• 16:54
  Opóźnienie, przepustowość, utylizacja.
• 16:56
  Dowody są lepsze od opinii,
• 16:58
  więc ustalamy zestaw poleceń,
• 16:59
  blokujemy ziarna
• 17:00
  i uruchamiamy na rozgrzewkę.
• 17:01
  Te same harmonogramy,
• 17:02
  te same kroki,
• 17:03
  od 20 do 25 dla 512,
• 17:05
  rozszerzone do 50 dla 1024 na 1024,
• 17:08
  aby ujawnić obciążenie.
• 17:09
  Współbieżność utrzymywana na 16,
• 17:11
  z próbą do 32.
• 17:12
  Rozmiar partii zaczyna się od 1,
• 17:14
  rosnąc ostrożnie,
• 17:15
  aż granice VRAM dadzą o sobie znać.
• 17:16
  Żadnych ekstrapolacji,
• 17:18
  żadnych wymówek,
• 17:18
  tylko zegary i liczniki.
• 17:19
  Opóźnienie zeznaje jako pierwsze.
• 17:21
  W stanie zdegradowanym
• 17:22
  przy awaryjnym CPU
• 17:23
  lub ogólnej ścieżce uwagi,
• 17:24
  P50 przy 512 na 512
• 17:26
  rozciąga się do wartości dwucyfrowych.
• 17:28
  P95 mówi całą prawdę.
• 17:30
  Waha się nieprzewidywalnie
• 17:31
  od 20 do 40 sekund,
• 17:33
  ponieważ kolejki potęgują
• 17:34
  małe nieefektywności.
• 17:35
  Przy 1024 na 1024 i 50 krokach
• 17:38
  P95 staje się naruszeniem
• 17:40
  już na starcie.
• 17:41
  Po naprawie zablokowanym EPU
• 17:42
  aktywną połączoną uwagą
• 17:44
  i opowiązanym z urządzeniem P50
• 17:46
  wraca do niskich wartości jednocyfrowych,
• 17:48
  a P95 mieści się w budżecie.
• 17:50
  Zakres się kurczy,
• 17:51
  system staje się przewidywalny.
• 17:53
  Przepustowość potwierdza.
• 17:54
  Przy współbieżności 16
• 17:56
  zdegradowana ścieżka
• 17:57
  daje tylko namiastkę wydajności.
• 17:58
  Obrazy na minutę
• 17:59
  ledwo rosną wraz z replikami,
• 18:00
  ponieważ każda instancja
• 18:01
  sama się blokuje.
• 18:02
  Skalowanie do 32
• 18:03
  z wielokrotnia spory,
• 18:05
  a nie wynik.
• 18:05
  Po naprawie relacja się prostuje.
• 18:07
  Obrazy na minutę
• 18:08
  rosną niemal liniowo,
• 18:09
  aż cykl pracy rdzeni
• 18:10
  tensorowych się nasyci
• 18:11
  lub VRAM ograniczy partię.
• 18:13
  Różnica w nachyleniu
• 18:14
  to dowód winy.
• 18:15
  Praca faktycznie dociera
• 18:16
  do mety szybciej,
• 18:17
  a nie tylko głośniej.
• 18:18
  Utylizacja zamyka sprawę.
• 18:19
  Wcześniej cykl pracy GPU
• 18:21
  oscylował między zerem
• 18:22
  a 50% z długimi,
• 18:24
  płaskimi dolinami.
• 18:25
  Liczniki PC
• 18:25
  wykazywały szum
• 18:26
  związany z transferami
• 18:28
  stronicowalnymi.
• 18:29
  Po zmianach cykl pracy
• 18:31
  stabilizuje się
• 18:31
  na wysokim,
• 18:32
  stałym poziomie
• 18:33
  z widocznym zaangażowaniem
• 18:34
  rdzeni tensorowych.
• 18:35
  CPU powraca do orkiestracji
• 18:37
  i lekkiego wstępnego przetwarzania.
• 18:39
  Piki PC
• 18:39
  wygładzają się,
• 18:40
  ponieważ przypięta pamięć
• 18:41
  i wiązanie
• 18:42
  i owy eliminowały
• 18:43
  zbędny ruch.
• 18:43
  Nic innego nie tłumaczy
• 18:45
  tej zmiany
• 18:45
  poza rzeczywistym przyspieszeniem.
• 18:46
  Dodajemy stres
• 18:47
  test weryfikacyjny.
• 18:48
  Dla 512 na 512 kroków
• 18:50
  2025
• 18:51
  poprawiona ścieżka
• 18:52
  utrzymuje współbieżność
• 18:52
  16 bez skoków na końcu.
• 18:54
  Przy 32 system
• 18:55
  degraduje się
• 18:55
  w sposób kontrolowany.
• 18:56
  P95 rośnie przewidywalnie,
• 18:59
  a nie chaotycznie.
• 18:59
  Dla 1024 na 1024
• 19:01
  przy 50 krokach
• 19:03
  różnica jest wyolbrzymiona.
• 19:04
  Zdegradowana ścieżka
• 19:05
  załamuje się
• 19:05
  pod wpływem przekroczeń czasu.
• 19:07
  Wzmocniona ścieżka
• 19:07
  utrzymuje użyteczne P50
• 19:09
  i akceptowalne P95
• 19:10
  przy partii od 1 do 2
• 19:13
  areny i strumienie.
• 19:15
  Po optymalizacji
• 19:15
  blokowanie typu
• 19:16
  Head of Line ustępuje.
• 19:17
  Kwestia kosztów
• 19:18
  to prosta arytmetyka.
• 19:19
  Liczba zapytań
• 19:20
  na godzinę pracy GPU
• 19:21
  rośnie od 2 do 5 razy
• 19:22
  po weryfikacji
• 19:23
  Fused Attention FP16
• 19:24
  i wiązania IO.
• 19:25
  Efektywny koszt
• 19:26
  za 1000 obrazów
• 19:27
  odpowiednio spada.
• 19:28
  Kary za zimny start maleją,
• 19:30
  ponieważ obrazy są lekkie,
• 19:31
  a silniki są wstępnie zbudowane.
• 19:33
  Węzły nie płacą już podatku
• 19:34
  od kompilacji
• 19:34
  przy pierwszym użyciu.
• 19:35
  Rejestr zgadza się z logami.
• 19:37
  Weryfikacja zapobiega
• 19:38
  przypadkowym sukcesom.
• 19:39
  Powtórz na drugiej puli węzłów
• 19:41
  z inną wersją sterownika.
• 19:42
  Wzmocniony obraz z założenia
• 19:44
  odmawia uruchomienia
• 19:45
  na niedopasowanym węźle.
• 19:46
  Dzięki temu wyniki są porównywalne,
• 19:48
  a nie zafałszowane.
• 19:49
  Sprawdź migawki możliwości.
• 19:51
  Ta sama kolejność dostawców,
• 19:52
  ten sam tensor,
• 19:53
  te same asercje Kerneli.
• 19:55
  Uruchom ponownie zestaw promptów
• 19:56
  i odzyskaj rozkłady.
• 19:58
  Gdy histogramy się pokrywają,
• 19:59
  pewność wzrasta.
• 20:00
  Gdy nie, różnica w możliwościach
• 20:02
  wyjaśnia dlaczego.
• 20:03
  Ostatecznie liczby nie dyskutują,
• 20:04
  one wydają werdykt.
• 20:05
  Opóźnienia maleją,
• 20:09
  metodologia nie jest hipotetyczna.
• 20:11
  Jest mierzalna i po fakcie
• 20:12
  pozostawia odciski palców
• 20:13
  na każdym wykresie.
• 20:15
  Protokół naprawczy,
• 20:16
  powtarzalna lista kontrolna wzmocnienia.
• 20:18
  Kontrola wstępu jest najważniejsza.
• 20:20
  Odmów uruchomienia,
• 20:21
  jeśli dostawcy tensorszt lub cuda
• 20:23
  nie są obecni.
• 20:24
  Wylicz dostawców,
• 20:25
  zweryfikuj liczbę urządzeń,
• 20:26
  wydrukuj migawki możliwości,
• 20:28
  obszar roboczy cudne,
• 20:29
  FP16 i NT8.
• 20:31
  Jeśli czegokolwiek brakuje,
• 20:32
  zakończ z kodem błędu.
• 20:33
  Dostępność wynika z integralności.
• 20:35
  Przypinanie wersji to kręgosłup.
• 20:37
  Utrzymuj jedną macierz,
• 20:38
  gałąź sterownika,
• 20:39
  cuda minor do cudne,
• 20:40
  hash kompilacji
• 20:41
  o NNX Runtime,
• 20:42
  tensorszt.
• 20:42
  Buduj obrazy wnioskowania
• 20:43
  zgodnie z tą macierzą.
• 20:45
  Oznacz węzły, aby pasowały.
• 20:46
  Uzależnij dostęp od zgodności.
• 20:48
  Wstępnie zbudowane silniki
• 20:49
  tensorszt dla każdego modelu
• 20:50
  i rozdzielczości.
• 20:51
  Plany to artefakty,
• 20:52
  niezgadywanie w czasie wykonywania.
• 20:54
  Higiena kontenerów zachowuje prawdę.
• 20:56
  Stosuj wieloetapowe budowanie.
• 20:57
  Utrzymuj środowisko uruchomieniowe
• 20:59
  jako distroles lub slim.
• 21:00
  Uwzględnij restrykcyjny plik Docker Ignore.
• 21:02
  Zweryfikuj za pomocą historii
• 21:03
  Dockera i audytu odchudzania.
• 21:04
  Ustaw budżety wielkości puli w CII.
• 21:06
  Odrzucaj napuchnięte obrazy,
• 21:07
  podpisuj je i porównuj zawartość
• 21:09
  według skrótów.
• 21:10
  Skonfiguruj najpierw GPU.
• 21:11
  Zablokuj kolejność app
• 21:12
  na tensorszt cuda.
• 21:13
  Wyłącz dostawcę CPU
• 21:14
  w środowisku produkcyjnym.
• 21:16
  Zweryfikuj obecność
• 21:16
  DevNV i DIA
• 21:17
  oraz wersję zestawu narzędzi
• 21:18
  kontenera NV i DIA.
• 21:20
  Żądaj GPU NVIDIA.com jawnie
• 21:22
  lub łącz licencję
• 21:22
  i weryfikuj je przy starcie.
• 21:30
  Powiąż i o bezpośrednio
• 21:31
  z pamięcią urządzenia
• 21:33
  włącz pamięć przypiętą.
• 21:34
  Wybierz strumienie,
• 21:35
  by uniknąć blokowania kolejki.
• 21:37
  Dostrój ponownie lub wyłącz
• 21:38
  arenę Ord Cuda,
• 21:39
  gdy zatrzymuje się
• 21:40
  poza zestawem roboczym.
• 21:41
  Ustaw SL o wydajności jako kod.
• 21:43
  Test autostartu
• 21:44
  z oknem opóźnień
• 21:44
  deterministycznych podpowiedzi
• 21:46
  i progiem wykorzystania.
• 21:47
  Przerywaj działanie
• 21:48
  przy narastających zaległościach.
• 21:49
  Dodaj obserwowalność
• 21:50
  metryki GPU dla żądania,
• 21:52
  alerty o obniżonej wydajności,
• 21:53
  podpowiedzi Canary
• 21:54
  i porównywalne linie bazowe.
• 21:56
  Wdruż Blue, Green
• 21:57
  z bramkami wydajności
• 21:58
  i automatycznym wycofaniem
• 21:59
  przy naruszeniu.
• 22:00
  Dzięki egzekwowaniu protokołu
• 22:02
  akceleracja jest dowodliwa,
• 22:03
  a nie zakładana.
• 22:05
  Lekcja jest kliniczna.
• 22:06
  Cichy fallback na CPU,
• 22:07
  dry w wersji
• 22:08
  i rozrost kontenerów
• 22:09
  to nie błędy.
• 22:10
  To przewidywalne wzorce awarii,
• 22:11
  które możesz zablokować.
• 22:13
  Stosuj protokół,
• 22:13
  mierz wykorzystanie GPU,
• 22:14
  odrzucaj zdegradowane ścieżki,
• 22:16
  przypinaj wersję,
• 22:17
  traktuj silniki jak artefakty.
• 22:18
  Jeśli chcesz głębiej poznać
• 22:19
  środowisko uruchomieniowe ONNX,
• 22:21
  zachowanie pamięci tensorszt
• 22:23
  i kiedy wyłączać Areny,
• 22:24
  obejrzyj kolejny odcinek
• 22:25
  i zasubskrybuj notatki laboratoryjne.