1. Zdefiniuj punkt odniesienia i oczekiwany wynik
Zacznij od tego, co chcesz powtórzyć: uzyskać te same kategorie, otrzymać zbliżone wartości lub odtworzyć trajektorię uczenia. Zachowaj mały zbiór danych wejściowych przechodzący przez ważne kroki oraz przykład prawidłowego wyniku. Instalacja, która kończy się bez błędu, jeszcze nie odpowiada na to pytanie.
Rozważmy przypadek edukacyjny: Twoja aplikacja generuje embeddingi dla zidentyfikowanej próbki. W środowisku referencyjnym musisz ustalić kształt wyników, ich typ, brak wartości niebędących liczbami skończonymi oraz użyteczne kryterium biznesowe. Jeśli porównujesz wartości, wybierz tolerancję uzasadnioną swoim zastosowaniem. Nie podano tu żadnego uniwersalnego progu liczbowego.
Przypisz rewizję do kodu, danych i wag. Nazwa taka jak „ostatni-model” może się zmienić, a program tego nie pokaże. Powiąż także parametry i przetwarzanie wstępne z referencją. Ten rejestr pozwala ustalić, czy różnica wynika z oprogramowania, danych wejściowych czy warunków wykonania.
Przewiń tabelę, aby zobaczyć wszystkie kolumny.| Element | Do zachowania | Kontrola po odtworzeniu |
|---|---|---|
| Kod i parametry | Rewizja, ewentualne modyfikacje, konfiguracja | Ten sam punkt wejścia i te same opcje. |
| Dane i wagi | Wersja lub odcisk, pochodzenie i prawa dostępu | Ta sama próbka i ta sama oczekiwana zawartość. |
| Python i pakiety | Wersje, procedura i źródła instalacji | Poprawny interpreter i spójne zależności. |
| System i backend | System operacyjny, architektura, sterownik, CUDA lub ROCm | Widoczne urządzenie i udane obliczenie minimalne. |
| Wynik | Format i kryteria akceptacji | Struktura, a następnie jakość lub przewidziana tolerancja. |
2. Oddziel łańcuch systemowy od pakietów Python
Sprawdź razem kartę, system, sterownik, Python i biblioteki. Środowisko wirtualne porządkuje pakiety Python; nie zastępuje jednak sterownika systemowego. Podobnie sama referencja obrazu nie wystarcza do opisania rzeczywistego dostępu do GPU z jego hosta. W przypadku rozszerzenia kompilowanego zapisz niezbędne narzędzia i biblioteki kompilacji.
Wybierz dystrybucję PyTorch na podstawie platformy obliczeniowej swojego projektu. W ROCm PyTorch ponownie używa wywołań torch.cuda i urządzeń o nazwie cuda: nazwa interfejsu nie pozwala zidentyfikować NVIDIA. Zapisz osobno torch.version.cuda i torch.version.hip. Rozszerzenie napisane dla danego łańcucha zasługuje na własną kontrolę.
Zachowaj procedurę, która faktycznie umożliwiła instalację, wraz z pochodzeniem pakietów. Unikaj mieszania świeżego polecenia znalezionego w sieci ze starym plikiem zależności bez zbadania ich zgodności. Przeglądana dokumentacja może się zmieniać; zapisz używane wersje we własnym rejestrze.
3. Napisz odtworzenie zamiast kopiować zainstalowany katalog
Utwórz nowe środowisko z wybranym Pythonem. Następnie użyj jawnie jego interpretera, aby zainstalować i uruchomić projekt. W systemie Linux będzie to na przykład .venv-rebuild/bin/python; w systemie Windows .venv-rebuild\Scripts\python.exe. Nie musisz polegać na wcześniejszej aktywacji. Dokumentacja Python precyzuje, że środowisko wirtualne należy odtworzyć, gdy zmienia lokalizację.
pip freeze dostarcza inwentarz zainstalowanych pakietów, a nie obliczony plik blokady. Zachowaj go jako obserwację. Plik odtworzenia musi także jasno określać indeksy lub pliki niezbędne dla Twojego wariantu PyTorch oraz zgodne wersje. Przeczytaj ścieżki lub adresy URL, które może zawierać inwentarz, zanim go udostępnisz.
Poniższe polecenia ilustrują odtworzenie w systemie Linux do dostosowania; nie stanowią one wykonanej próby Twojego projektu. Plik requirements-rebuild.txt powinien już opisywać Twoje środowisko, w tym właściwy wybór PyTorch. Nie zastępuj go listą rzekomo uniwersalnych wersji.
python -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip --version
.venv-rebuild/bin/python -m pip install -r requirements-rebuild.txt
.venv-rebuild/bin/python -m pip check
.venv-rebuild/bin/python -m pip freeze --all > installed-after.txt4. Sprawdź kontrakt zależności przed obliczeniem
python -m pip check, uruchomiony z właściwym interpreterem, wyszukuje brakujące lub niezgodne zainstalowane zależności na podstawie ich metadanych. Wynik bez konfliktów nie jest walidacją sterownika, natywnych rozszerzeń ani jakości aplikacji. Dlatego pozostaw ten krok jako krótki i przejdź do kontroli obliczeń.
Aby rekonstrukcja była bardziej rygorystyczna, możesz przypiąć wersje i zachować odciski dozwolonych dystrybucji. Ta decyzja wymaga utrzymania pełnej listy odpowiadającej Twojej platformie. Archiwum skompilowanych wheelów może zależeć od systemu operacyjnego i architektury; nie jest gwarancją przenośności między dwiema różnymi maszynami.
W naszym przykładzie z embeddingami porównaj zrekonstruowany inwentarz z referencją, zanim zmodyfikujesz model lub jego parametry. Jeśli różnica jest zamierzona, odnotuj ją i potraktuj nowe uruchomienie jako wariant. W przeciwnym razie popraw rekonstrukcję; zmiana kilku warstw naraz sprawi, że diagnoza będzie mniej precyzyjna.
5. Od minimalnej kontroli do zastosowania
W interpreterze projektu odczytaj Python, PyTorch i backend, a następnie sprawdź urządzenie i małe obliczenie. Zatrzymaj ten krok, jeśli oczekiwany GPU nie jest dostępny; awaryjne uruchomienie na CPU zaciemniłoby porównanie. Diagnostyka Kernodeck dostarcza czytelny raport i rozróżnia kroki faktycznie wykonane.
Gdy ta kontrola się powiedzie, użyj swojego małego przykładowego zbioru aplikacyjnego. W przypadku embeddingów sprawdź liczbę wyników, ich wymiary, ich zgodność z identyfikatorami i wybrane kryterium. Wczytaj ponownie pliki ze katalogu wyjściowego. Udane obliczenie macierzowe nie dowodzi, że wstępne przetwarzanie lub rozszerzenie projektu działa.
Jeśli próba kończy się błędem przy wczytywaniu danych, transferze lub podczas konkretnej operacji, zachowaj krok i pierwszy błąd. Ogólna rekonstrukcja może być poprawna; blokada może dotyczyć loadera danych lub konkretnego operatora. Skieruj wtedy diagnostykę na tę warstwę.
6. Rozróżnij rekonstrukcję od tożsamości numerycznej
Odtworzenie tych samych zależności nie gwarantuje identycznych wyników między sprzętem, platformami czy wersjami PyTorch. Ustawienie ziarna nie obejmuje wszystkich źródeł zmienności. Udokumentuj użyte generatory, transformacje danych oraz istotne ustawienia precyzji lub determinizmu.
Zdefiniuj kryterium porównania, zanim spojrzysz na różnicę: dokładna struktura, tolerancja numeryczna lub stabilność metryki. Niektóre ustawienia deterministyczne mogą odrzucać operacje lub zmieniać koszt obliczeń. Pożądanym wynikiem jest zrozumiały wniosek w ogłoszonych warunkach, a nie obietnica tożsamości na każdej maszynie.
W przypadku wznowienia treningu same wersje nie wystarczą: trzeba także przywrócić stan obliczeń i postęp. Folder wznowienia weryfikuje tę kwestię osobno. Jego ćwiczenie na CPU i jego tolerancja nie stają się automatycznie warunkami Twojego modelu.
7. Zakończ folderem, którego może użyć inne uruchomienie
Folder końcowy łączy procedurę, zaobserwowany inwentarz, konfigurację, odniesienia do danych i wyniki kontroli. Dodaj dokładną sekwencję: zrekonstruuj, zdiagnozuj, uruchom próbkę, odczytaj wynik. Przechowuj dane dostępu osobno i podaj jedynie, jak je dostarczyć.
Powtórz tę sekwencję w czystym folderze, zanim uznasz środowisko za przekazywalne. Kontrola musi się powieść bez pobierania zmiennej ze starego notebooka ani szukania zapomnianego pliku. Jeśli zmiana jest konieczna, popraw procedurę i nadaj referencji nową tożsamość. Otrzymujesz bazę użyteczną na Twój następny okres obliczeń.