Zimny start domowego modelu AI zależy od układu pamięci masowej, ponieważ środowisko uruchomieniowe musi zlokalizować, odczytać, zdekodować, zmapować i przesłać każdą wymaganą wagę przed rozpoczęciem wnioskowania.
Dwie kopie tego samego modelu mogą uruchamiać się z różną szybkością, gdy jedna jest już buforowana na lokalnym dysku NVMe i przechowywana w formacie przystosowanym do szybkiego ładowania, a druga znajduje się na udziale sieciowym, pofragmentowanym systemie plików, w skompresowanym archiwum lub w katalogu z nieoptymalnie rozmieszczonymi fragmentami. Ścieżka zimnego startu obejmuje również pliki tokenizera, konfigurację, inicjalizację środowiska uruchomieniowego, przydzielanie zasobów akceleratora oraz pierwsze wykonanie. Poniższe sekcje oddzielają surową przepustowość pamięci masowej od układu checkpointu, aby można było przypisać opóźnienia uruchamiania do właściwego etapu.
Zimny start to łańcuch etapów związanych z pamięcią masową i środowiskiem uruchomieniowym
Model nie jest gotowy w chwili, gdy proces po prostu otworzy pierwszy plik. Środowisko uruchomieniowe musi odczytać metadane checkpointu, utworzyć strukturę modelu, odczytać bajty wag, zdeserializować lub zmapować tensory, przydzielić pamięć docelową, przesłać dane oraz zainicjalizować kernele lub grafy wykonawcze.
Badania nad wnioskowaniem bezserwerowym wskazują ładowanie podczas zimnego startu jako istotną część opóźnienia poprzedzającego gotowość usługi LLM. Najwolniejszy etap zmienia się zależnie od rozmiaru modelu, formatu, warstwy pamięci masowej, pamięci hosta i ścieżki akceleratora.
Szybki dysk SSD może skrócić czas odczytu, ale nie zmienić czasu deserializacji, kopiowania przez CPU, przesyłania do GPU ani rozgrzewania kerneli. Mierz czas na każdej granicy zamiast traktować całe opóźnienie jako jeden test dysku.
Lokalność decyduje o tym, czy wagi trafią z pamięci podręcznej, sieci LAN czy dysku
Wagi przechowywane na lokalnym dysku NVMe można odczytać bez opóźnienia sieciowego i kolejki na innym serwerze. Model znajdujący się na SMB, NFS, w magazynie obiektowym lub na wolnym zewnętrznym dysku wymaga dodatkowego transportu i obsługi zdalnej pamięci podręcznej, zanim rozpocznie się lokalne ładowanie.
Najnowsze badania nad modelami buforowanymi na węzłach pokazują, że przechowywanie dużych artefaktów lokalnie może znacznie uniezależnić uruchamianie kolejnych replik od wielokrotnego dostarczania ich ze zdalnego źródła. Na domowym serwerze ta sama zasada odróżnia pierwsze pobranie od kolejnego lokalnego uruchomienia.
Lokalne nie zawsze oznacza ciepłe. Ponowne uruchomienie, usunięcie danych z pamięci podręcznej, ponowne zamontowanie systemu plików lub równoległy intensywny odczyt mogą sprawić, że kolejne uruchomienie ponownie pobierze większość stron modelu z fizycznej pamięci masowej.
Artykuł ZimaSpace o usuwaniu modeli z pamięci omawia powiązaną granicę pamięci: gdy model przestaje być rezydentny, kolejne żądanie musi odtworzyć szybki stan wykonania.
Format checkpointu steruje deserializacją i kopiowaniem danych
Checkpoint może być jednym spójnym plikiem zoptymalizowanym pod kątem ładowania, kilkoma fragmentami tensorów z indeksem, skompresowanym archiwum lub serializacją właściwą dla danego frameworka, która odtwarza obiekty Pythona i metadane tensorów.
ServerlessLLM wykorzystuje sekwencyjne odczyty checkpointów, aby zmniejszyć narzut zimnego startu. Układ obsługujący duże bezpośrednie odczyty i przewidywalne rozmieszczenie tensorów poświęca mniej czasu na drobne operacje na metadanych oraz pośrednie odtwarzanie.
Fragmentowanie może zmniejszyć szczytowe zużycie pamięci RAM hosta, ponieważ fragmenty są obsługiwane pojedynczo, jednak zbyt wiele małych plików zwiększa liczbę wyszukiwań w katalogach, otwarć, operacji pozycjonowania i przetwarzania indeksu. Optymalny rozmiar fragmentu zależy od współbieżności modułu ładującego i używanego systemu plików.
Kompresja pozwala oszczędzić miejsce kosztem pracy procesora podczas uruchamiania. Może pomóc, gdy pamięć masowa jest bardzo wolna, ale zaszkodzić, gdy szybki dysk SSD czeka na dekompresję i kopiowanie danych w pamięci.
Mapowanie pamięci zmienia moment wczytywania stron do RAM-u
Moduł ładujący działający w trybie eager może przydzielić duży bufor w pamięci hosta i odczytać większość lub całość checkpointu przed dalszym kopiowaniem tensorów. Moduł ładujący korzystający z mapowania pamięci tworzy mapowania wirtualne i pozwala systemowi operacyjnemu wczytywać strony pliku do RAM-u dopiero w chwili ich użycia.
Badania i nowoczesne systemy ładowania wykorzystują ładowanie z mapowaniem pamięci, aby uniknąć duplikowania całego artefaktu w pamięci anonimowej. Może to zmniejszyć szczytowe zużycie RAM-u i umożliwić kolejnym procesom ponowne wykorzystanie stron dzięki pamięci podręcznej systemu plików.
Mapowanie pamięci nie eliminuje opóźnienia pamięci masowej. Przenosi odczyty na moment wystąpienia błędu strony, dlatego pierwsze wnioskowanie nadal może się zatrzymać, jeśli wymagane strony nie zostały jeszcze wczytane lub pobrane z wyprzedzeniem.
Sekwencyjne pobieranie z wyprzedzeniem może pomóc modelowi, który odczytuje większość wag po kolei, natomiast losowy dostęp do ekspertów lub komponentów multimodalnych może sprawić, że wzorzec błędów stron będzie mniej przewidywalny.
Ładowanie równoległe pomaga tylko wtedy, gdy ścieżka pamięci masowej ma zapas przepustowości
Wiele wątków modułu ładującego lub strumieni kopiowania do GPU może nakładać na siebie odczyt, dekodowanie i przesyłanie. Mogą jednak również zamienić jeden uporządkowany odczyt w kilka konkurujących strumieni, które przeciążą słaby dysk SSD, mostek USB, udział sieciowy lub ścieżkę metadanych systemu plików.
Wyniki inżynieryjne firmy NVIDIA dotyczące współbieżnego strumieniowania wag pokazują, że konstrukcja modułu ładującego i wybór pamięci masowej wspólnie decydują o poprawie. Równoległość jest użyteczna, gdy źródło i miejsce docelowe mogą ją obsłużyć bez wydłużania kolejek.
Domowy serwer może również jednocześnie obsługiwać multimedia, zapisywać kopie zapasowe, skanować pliki lub uruchamiać bazy danych na tej samej puli. Te zadania zmieniają opóźnienie zimnego startu, mimo że katalog modelu pozostaje niezmieniony.
Ciepła pamięć podręczna i ponowne wykorzystanie wag mogą decydować o czasie kolejnych uruchomień
Pierwsze uruchomienie po starcie systemu może odczytać z pamięci masowej każdy bajt modelu, podczas gdy drugie skorzysta z pamięci podręcznej stron systemu plików, zachowanej pamięci GPU lub środowiska uruchomieniowego, które przechowuje wagi w stanie gotowym do ponownego użycia.
Tangram przyspiesza uruchamianie dzięki ponownemu wykorzystaniu wag w pamięci GPU. Szerszy wniosek dla domowego serwera jest taki, że określenie „zimny start” musi wskazywać, które pamięci podręczne i procesy zostały wyczyszczone przed testem.
Nie porównuj modelu uruchomionego od razu po innym ciepłym uruchomieniu z innym modelem uruchomionym po ponownym rozruchu. Oddzielnie zdefiniuj stan zimny, stan z ciepłą pamięcią podręczną systemu plików, stan z ciepłym środowiskiem uruchomieniowym oraz stan z rozgrzanym akceleratorem.
Przetestuj układ w powtarzalnym teście zimnego stanu
Zapisz rozmiar modelu, liczbę plików, rozmiary fragmentów, system plików, opcje montowania, urządzenie pamięci masowej, ścieżkę sieciową, tryb modułu ładującego, pamięć RAM hosta, pamięć akceleratora oraz konkurencyjne operacje wejścia-wyjścia. Następnie zmierz czas wykrywania metadanych, odczytu przez hosta, deserializacji, przesyłania do urządzenia, inicjalizacji środowiska uruchomieniowego i wygenerowania pierwszego tokenu.
Badania FlowLoader dotyczą lokalnego buforowania modeli, ponieważ umiejscowienie checkpointu i nakładanie etapów potoku mogą skrócić uruchamianie z sekund lub minut. Dokładna poprawa zależy od tego, czy rzeczywistym wąskim gardłem jest pamięć masowa, kopiowanie czy inicjalizacja.
Powtórz test po wyczyszczeniu pamięci podręcznej systemu plików, po standardowym ciepłym uruchomieniu oraz podczas reprezentatywnego ruchu na serwerze NAS. Uzyskana różnica pokaże, czy pomoże zmiana układu, szybsza lokalna warstwa pamięci masowej, mniejsza liczba fragmentów, mapowanie pamięci lub zasada utrzymywania modelu w gotowości.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Co powoduje, że agent AI do planowania powtarza już wykonane kroki?
Śledź powtarzające się kroki planera, analizując trwałość stanu, dowody ukończenia, analizę wyników narzędzi, zachowanie kontekstu, ponowne próby, przeplanowywanie i warunki zatrzymania.

Co powoduje błędy uprawnień występujące wyłącznie w podprocesach agentów AI?
Porównaj tożsamość procesu nadrzędnego i podrzędnego, widok systemu plików, środowisko, uprawnienia, zasady bezpieczeństwa oraz ścieżkę pliku wykonywalnego, aby zdiagnozować odmowę występującą wyłącznie w podprocesie.

Co powoduje przeciążenie procesora, gdy sprzętowe transkodowanie i sztuczna inteligencja wideo działają jednocześnie?
Śledź wysycenie procesora w zakresie odciążania kodeków, konwersji pikseli, kopiowania klatek, wstępnego przetwarzania AI, dźwięku, napisów, pamięci masowej i planowania procesów.

