3.5 Benchmark własnego warsztatu

Jedno popołudnie pomiarów daje trzy rzeczy, z których będziesz korzystać przez całe życie projektu: realne tempo publikowania, koszt na opublikowany post, którego da się obronić, oraz umiejętność odróżnienia regresji od preferencji.

Bez punktu odniesienia każde spowolnienie jest albo niewidoczne, albo alarmujące — i nie wiesz, które. Dziesięć minut na test, cztery testy, zapisane w jednej tabeli.

Protokół, który liczy się bardziej niż same testy

Każdy test poniżej jest bezwartościowy, jeśli warunki się rozjadą. Ustal je na sztywno:

• Ten sam prompt, ten sam seed, te same ustawienia w każdym przebiegu, który zamierzasz porównywać.
• Ta sama rozdzielczość i ta sama liczba steps.
• Zapisuj szczytowe zużycie VRAM, nie średnie. To szczyty wywalają przebieg po czterdziestu minutach.
• Zapisuj środowisko — wersję sterownika, wersję PyTorch, plik modelu i precyzję.
• Uruchom każdy test dwa razy i zachowaj drugą liczbę. Pierwszy przebieg modelu spędza czas na wczytywaniu wag do pamięci; pierwsza liczba to pomiar twojego dysku.

Zasada czytania tabeli: zmiana w jednym polu przy wszystkich pozostałych ustalonych to informacja. Wszystko inne to szum.

Test 1: obraz bazowy

Jeden obraz 1024 px, 20 steps, jedna generacja, świeży proces.

Zapisz czas zegarowy w sekundach i szczytowe zużycie VRAM. To liczba, względem której mierzy się wszystko inne, i przekłada się wprost na przepustowość: jeśli render trwa 40 sekund, a potrzebujesz 20 opublikowanych obrazów miesięcznie przy średnio pięciu próbach na obraz, mówimy o około godzinie czystego renderu — plus czas człowieka, a to składnik większy.

Uruchom go jeszcze raz na modelu destylowanym przy 6 steps. Różnica pokaże ci, co daje ci tier szkicowy.

Test 2: test dryfu, jedyny test, który zmienia decyzję

To najcenniejszy pomiar w tym rozdziale i prawie nikt go nie wykonuje.

Weź jedno odniesienie tożsamości — twarz swojej persony, w jakości, w której zamierzasz publikować. Uruchom na nim tę samą instrukcję edycji na każdym modelu-kandydacie z wybranej rodziny:

same person, red jacket, studio light, facing camera, neutral expression

Minimum trzy modele. Ten sam obraz referencyjny, ta sama instrukcja, ta sama rozdzielczość wyjściowa.

Teraz oceń utrzymanie tożsamości. Użyj prostej skali i bądź uczciwy w środku:

Model, który wypada najwyżej, jest twoim modelem produkcyjnym do wszystkiego, co dotyczy twarzy, niezależnie od tego, co mówią ogólne rankingi. Ten test kosztuje dwadzieścia minut i zapobiega miesiącom walki z tożsamością, którą utrzymałby inny checkpoint.

Uruchom go ponownie za każdym razem, gdy zmieniasz model bazowy, wersję adaptera albo artefakt tożsamości. Dryf nie ogłasza się sam; narasta w całym kalendarzu treści.

Test 3: przepustowość wideo

Render 6-sekundowy image-to-video z jednego nieruchomego obrazu.

Punkt odniesienia: karta klasy 4090 z 24 GB VRAM i około 90 GB pamięci RAM systemu wykonuje to w od jednej do dwóch minut. [UNVERIFIED] Traktuj to jako punkt odniesienia do pobicia albo do zaakceptowania, a nie jako gwarancję — twoja liczba zależy od rozdzielczości, złożoności ruchu i modelu.

Poza czasem zapisz dwie rzeczy:

• Szczyt VRAM. Modele wideo skaczą mocniej niż modele obrazu, a szczyt, który mieści się przy jednej rozdzielczości, nie zmieści się przy następnej w górę.
• Wskaźnik nieudanych prób. Jeśli trzy z pięciu renderów wracają nieużywalne, twój efektywny czas na użyteczny klip to trzykrotność czasu zegarowego, a ta liczba należy do wzoru kosztowego z rozdziału 0.4.

Test 4: mini-trening

Przebieg treningu LoRA na dziesięciu obrazach, w najmniejszej sensownej konfiguracji. Celem nie jest dobra LoRA. Celem jest dowód, że pipeline działa od początku do końca, zanim zainwestujesz w wyselekcjonowany dataset i siedem godzin.

Zapisz: czy przebieg się zakończył, ile trwał, jakie było szczytowe zużycie VRAM i jak wyglądał wynik. Przebieg, który się kończy i daje słabą LoRA, jest sukcesem. Przebieg, który rzuca błędem przy step zero, to znacznie lepsze odkrycie teraz niż po wyselekcjonowaniu trzydziestu obrazów.

Jeśli planujesz trening hostowany, wykonaj ten test tam. Chodzi o poznanie kształtu przebiegu, a kształt jest wszędzie taki sam.

Tabela wyników

Wypełnij ją raz, opatrz datą i zachowaj. To jest punkt zerowy.

Jedno zastrzeżenie do ocen dryfu: są twoje, nie uniwersalne. Model, który u ciebie dostaje 4, u kogoś innego może dostać 2, bo utrzymanie tożsamości zależy od jakości odniesienia, promptu i wersji adaptera tak samo jak od checkpointu. To argument za wykonaniem testu zamiast czytania porównania — i za powtarzaniem go, gdy którakolwiek z tych trzech rzeczy się zmieni.

Zamiana liczb na pieniądze

Dwa wyprowadzenia, oba trafiają do rozdziału 0.4:

Czas na opublikowany materiał = (czas renderu × średnia liczba prób) + (czas człowieka). Składnik ludzki jest prawie zawsze większy i to jego ludzie pomijają w rachunku kosztów.

Koszt pieniężny na opublikowany materiał = (czas renderu × godzinowy koszt maszyny) + (czas człowieka × twoja stawka godzinowa) + ewentualne opłaty za API. Przy renderze lokalnym koszt maszyny to prąd i amortyzacja; przy wynajętej karcie to stawka godzinowa; przy API to opłata za wywołanie.

Powtórz cały zestaw, gdy zdarzy się którakolwiek z tych rzeczy: nowy sprzęt, duża aktualizacja sterownika albo frameworku, nowy model bazowy albo zmiana hosta. Poza tym raz na kwartał wystarczy, żeby wychwycić powolny dryf od zmian w środowisku.

Gdzie to się psuje

Benchmark raz i nigdy więcej. Wartość tabeli tkwi w porównaniu, a to wymaga drugiego pomiaru.

Inny prompt w każdym przebiegu. Zmierzyłeś własną niespójność.

Zapis średniego VRAM zamiast szczytu. To szczyt zawodzi.

Brak zapisu wersji środowiska. Wyniku bez jego konfiguracji nie da się odtworzyć ani wyjaśnić.

Pominięcie testu dryfu. To jedyny test, który zmienia model, na którym produkujesz.

Traktowanie liczb odniesienia z tego rozdziału jako swoich. To tylko kontrola zdrowego rozsądku. Twoja liczba to ta, która trafia do wzoru kosztowego.

Benchmark przy rozdzielczości, w której nie publikujesz. Mierz workflow, który uruchamiasz.

Bramka

1. Czy masz opatrzoną datą tabelę wyników ze wszystkimi czterema testami?
2. Który model wygrał test dryfu i czy to ten, na którym produkujesz?
3. Ile wynosi twój czas na opublikowany materiał, razem z próbami?
4. Ile wynosi twój koszt pieniężny na opublikowany materiał?
5. Gdzie konfiguracja środowiska jest zapisana obok liczb?

Z czym wychodzisz

Ustalony protokół, cztery testy, ocena dryfu tożsamości, która decyduje o twoim modelu produkcyjnym, tabela punktu zerowego do porównania za sześć miesięcy oraz dwa wyprowadzenia, które zamieniają czasy renderu na jedyne dwie liczby, jakie się liczą: czas na opublikowany materiał i koszt pieniężny na opublikowany materiał.