Kwantyzacja modelu: mniej pamięci, nowa próba jakości

Plik modelu stał się mniejszy, lecz zadanie nie zmalało razem z nim. Zespół nadal oczekuje właściwego terminu, poprawnego oznaczenia produktu i uczciwego „brak podstaw” przy niepełnej instrukcji. Oszczędność pamięci zasługuje na uwagę. Nie powinna jednak niepostrzeżenie zmieniać warunków odbioru odpowiedzi.

Kwantyzacja oznacza tutaj zmianę sposobu liczbowego zapisu wag, czyli parametrów modelu. Mniejsza precyzja może ograniczyć pamięć potrzebną do ich przechowania. Pytanie firmowe brzmi: czy konkretny wariant, uruchomiony w konkretny sposób, nadal wystarczająco dobrze wykonuje uzgodnioną pracę? Wspólna nazwa rodziny modeli nie stanowi odpowiedzi.

Mniejsza liczba bitów opisuje tylko część zmiany

Przegląd kwantyzacji w Hugging Face opisuje obniżenie precyzji zapisu wag w celu zmniejszenia wymagań pamięciowych, przy próbie zachowania jakości. Rozróżnia też wiele metod. Sam dopisek „4-bit” nie mówi więc wszystkiego o pochodzeniu i zachowaniu wariantu, który zespół właśnie pobrał.

Rozważmy własny rachunek, nie pomiar modelu. Dla siedmiu miliardów wag zapisanych równomiernie po 16 bitów otrzymujemy 14 miliardów bajtów, czyli 14 GB w zapisie dziesiętnym. Przy czterech bitach byłoby to 3,5 GB. Przemnożyliśmy wyłącznie liczbę wag przez liczbę bitów i podzieliliśmy przez osiem. Ten wynik nie opisuje rozmiaru rzeczywistego pliku ani pamięci zajętej przez działającą aplikację.

W rzeczywistym wariancie dochodzą dane potrzebne do reprezentacji, a poszczególne części mogą używać różnych sposobów zapisu. Zasoby są potrzebne także podczas wykonywania zadania. Nie przyjmuj zatem, że urządzenie z 3,5 GB wolnej pamięci uruchomi nasz teoretyczny wariant. Rachunek pokazuje skalę różnicy między reprezentacjami, a nie listę zakupową sprzętu.

Kod narzędzia kwantyzacji llama.cpp wymienia odrębne warianty Q4_K_S i Q4_K_M oraz opcje wpływające na typy zapisu części modelu. To konkretny powód, aby zachować pełne oznaczenie i konfigurację. Nie korzystamy tu z umieszczonych w kodzie wyników przykładowych modeli jako prognozy dla firmy.

Do porównania potrzebny jest identyfikator bazowego modelu, jego rewizja, pochodzenie wariantu po zmianie i wersja środowiska uruchomieniowego. Rewizja oznacza konkretny stan plików, a nie tylko etykietę rodziny. Zapisz także ustawienia wpływające na przetwarzanie wejścia i generowanie odpowiedzi. Dwie próby opisane jako „ten sam model lokalny” mogą w praktyce używać innych zestawów.

Praktyczny zapis wariantu powinien rozdzielać plik pobrany do próby od etykiety widocznej w aplikacji. Zachowaj sumę kontrolną pliku, czyli jego cyfrowy identyfikator pozwalający wykryć zmianę zawartości. Dodaj ustawienia załadowane w danym uruchomieniu, nie tylko planowane. Gdy aplikacja sama wybiera inny wariant po braku pamięci, raport musi wskazać rozwiązanie, które rzeczywiście udzieliło odpowiedzi. Nazwanie próby według pierwotnego zamiaru dałoby wynik przypisany do niewłaściwego wykonawcy.

Jeżeli wariant korzysta z dodatkowego adaptera LoRA, jego zgodność i rzeczywiste włączenie należą do tego opisu. Nie łącz w jednym nieoznaczonym porównaniu zmiany wag, adaptera i instrukcji. Możesz ocenić cały nowy zestaw jako rozwiązanie, lecz wniosek o samym wpływie kwantyzacji będzie wtedy węższy.

Najpierw pytanie, na które ma odpowiedzieć próba

W hipotetycznej wypożyczalni wyposażenia asystent przygotowuje robocze odpowiedzi na podstawie kart produktów. Zespół chce uruchomić go na mniejszym urządzeniu. Przedmiotem oceny jest odczyt warunków użycia i wskazanie właściwego materiału, bez samodzielnego potwierdzania rezerwacji. To wymyślony scenariusz; nie przedstawiamy wyników rzeczywistego wdrożenia ani uruchomienia modelu.

Pytanie „czy mniejszy model jest równie dobry?” zamień na kilka rozstrzygnięć związanych z tą pracą. Czy zachował ograniczenie dotyczące miejsca użycia? Czy wskazał właściwą wersję karty? Czy nie dopowiedział parametru, którego w materiale nie ma? Poprawność stylu można oceniać osobno. Gładka odpowiedź z błędnym warunkiem nie jest oszczędnością pamięci, którą wypożyczalnia chciała kupić.

Przygotuj wspólny zestaw wejść oraz oczekiwane elementy odpowiedzi. Wykorzystaj typowe sprawy i przypadki rozstrzygające dopuszczenie rozwiązania. Instrukcja dwóch podobnych modeli wyposażenia pomoże sprawdzić rozróżnienie. Dokument z wyjątkiem w dalszej części sprawdzi zachowanie warunku. Materiał bez wymaganej wartości pokaże reakcję na brak podstaw.

Takie porównanie korzysta z zasad migracji modelu AI, lecz tutaj nazwa rodziny może pozostać ta sama. To zwiększa ryzyko potraktowania zmiany jako czysto technicznej. Jeśli nowy zapis wpływa na odpowiedzi, właściciel procesu powinien zobaczyć tę różnicę przed przełączeniem zwykłej pracy.

Nie wymagaj identycznego brzmienia zdań, jeśli zadanie dopuszcza różne poprawne sformułowania. Ustal natomiast elementy, które muszą być zachowane. W wypożyczalni „wyłącznie wewnątrz” nie może zmienić się w „najlepiej wewnątrz”. Obie odpowiedzi brzmią uprzejmie. Tylko jedna przekazuje przyjęty warunek użytkowania.

Rozpiszmy jeden przypadek bez uruchamiania modelu. Karta fikcyjnego stojaka P-6 podaje „do pomieszczeń”, a karta podobnego P-6Z dopuszcza ogród. Pytanie klienta dotyczy P-6. Poprawny szkic ma zachować ograniczenie i wskazać tę właśnie kartę. Odpowiedź „można użyć w ogrodzie przy dobrej pogodzie” nie przechodzi oceny, nawet jeśli zawiera nazwę produktu i eleganckie zastrzeżenie. Drugą wersję przypadku można przygotować bez informacji o miejscu użycia. Wtedy kryterium dotyczy braku podstaw, a nie odtworzenia warunku znanego oceniającemu z poprzedniej próby.

Jeżeli przygotowujący wariant dobierał ustawienia na określonych przykładach firmowych, zachowaj je jako materiał przygotowania. Zestaw odbiorowy powinien zawierać odrębne przypadki. Inaczej można ocenić dopasowanie do znanego kompletu zamiast zachowania na dalszej pracy. W protokole zapisz pochodzenie obu zbiorów i dostęp osób przygotowujących rozwiązanie. To decyzja o wiarygodności porównania, a nie instrukcja technicznego prowadzenia kwantyzacji.

Ocena powinna obejmować każdą konfigurację na tym samym materiale. Jeśli dla wariantu mniejszego skrócono dokument, zmieniono pytanie lub usunięto trudny przypadek, wynik nie rozstrzyga porównania. Zapisuj też wejście, które ostatecznie dotarło do modelu. Sam plik w folderze nie potwierdza, że aplikacja przekazała całą jego treść.

W przeglądzie operacyjnego użycia AI Aeneia Audit można uporządkować zadania, wersje, dowody porównania i granice dopuszczenia. Specjalistyczne strojenie sprzętu pozostaje osobnym zakresem technicznym. Właściciel procesu powinien przede wszystkim wiedzieć, z jakim wynikiem będzie pracować zespół i w jakich warunkach oceniono jego jakość.

Rozmiar pliku, pamięć procesu, czas pracy

Raport powinien odróżniać rozmiar materiału na dysku od pamięci używanej po uruchomieniu. Zapisz, co faktycznie zmierzono: cały proces, wybrany rodzaj pamięci czy zasoby urządzenia podczas konkretnego zadania. Wartość z ekranu pobierania nie jest pomiarem użycia przy długiej rozmowie. Nie porównuj też dwóch różnych definicji pod wspólną rubryką „RAM”.

Dokumentacja strategii pamięci podręcznej Transformers opisuje osobną kwantyzację cache KV i ostrzega, że przy krótkim kontekście oraz wystarczającej pamięci GPU może ona wydłużyć oczekiwanie. Cache KV przechowuje wyniki pośrednich obliczeń używane przy kolejnych fragmentach generowanego tekstu. Jego ustawienia to dodatkowa część konfiguracji, a nie automatyczny skutek mniejszego pliku wag.

Dlatego zapisz długość wejścia i odpowiedzi oraz liczbę równocześnie obsługiwanych zadań. Próba jednego krótkiego pytania nie mówi, czy zestaw poradzi sobie z pracą kilku osób i dłuższą kartą produktu. Nie trzeba od razu odtwarzać całej przyszłej organizacji, ale granica pomiaru musi być widoczna.

Przypadek zakończony brakiem pamięci pozostaje wynikiem próby. Nie usuwaj go z raportu tak, jakby w ogóle nie został zadany. Pokaż osobno poprawnie zakończone odpowiedzi, odmowy wykonania i uruchomienia bez wyniku. Czas do przerwania można odnotować, lecz nie należy mieszać go ze średnim czasem uzyskania kompletnej odpowiedzi. Szybko zakończony błąd nie jest szybkim wykonaniem zadania. Jeśli krótszy kontekst był konieczny do dokończenia zadania, odnotuj zmianę wejścia i oceń ją osobno. Wypożyczalnia potrzebuje wiedzieć, które karty mieszczą się w rzeczywistym obiegu, a nie tylko jak szybko przetworzono te najkrótsze.

Czas także ma kilka znaczeń. Start aplikacji, załadowanie modelu, oczekiwanie na początek odpowiedzi i zakończenie całej pracy nie są tym samym. Dla osoby czekającej na szkic liczy się droga do użytecznego wyniku. Szybsze pojawienie się pierwszego słowa nie wynagrodzi późniejszej konieczności przepisywania warunków produktu.

Rozdziel pierwsze uruchomienie po starcie od kolejnych z już załadowanym modelem. Zapisz także inne zadania obciążające urządzenie podczas pomiaru i kolejność testowania wariantów. Jeśli próby wykonywano w odmiennych warunkach, wynik powinien zachować tę informację. Nie trzeba nadawać prostemu pilotażowi pozoru laboratoryjnej precyzji, ale należy umożliwić odtworzenie tego, co faktycznie zrobiono.

Zestaw te obserwacje z powtarzalnością odpowiedzi. Jedno udane uruchomienie nie rozstrzyga rozrzutu jakości ani czasu. Zapisz liczbę prób i sposób ich wykonania. Nie wybieraj po jednej najładniejszej odpowiedzi z każdego wariantu, bo wtedy raport porówna cierpliwość osoby robiącej zrzuty.

Bilans powinien pokazywać także przegrane przypadki

Wynik zbiorczy może ukryć zmianę, która dla wypożyczalni rozstrzyga decyzję. Jeśli wariant radzi sobie z krótkimi opisami, a myli wyjątki w dłuższych kartach, trzeba pokazać te grupy osobno. Nie nadawaj wszystkim błędom tej samej wagi wyłącznie dla wygody obliczenia jednej średniej.

Do raportu dołącz pary odpowiedzi i wskazanie różnicy względem kryterium. „Odpowiada gorzej” jest oceną trudną do odtworzenia. „W przypadku P-6 pominął ograniczenie do pomieszczeń” wskazuje materiał i znaczenie błędu. Przy przeglądzie można ukryć nazwę wariantu przed osobą oceniającą, aby oczekiwanie oszczędności nie zmieniało oceny treści.

Nie przypisuj przyczyny wyłącznie na podstawie wypowiedzi modelu. Poproszony o wyjaśnienie może napisać przekonujące zdanie o swojej pamięci, choć nie ma dostępu do pomiaru procesu. Uzasadnienie AI nie jest śladem wykonania obliczeń. Zmianę konfiguracji potwierdza jej zapis, a jakość odpowiedzi porównanie z właściwym kryterium.

Jeśli nie da się uruchomić wariantu odniesienia na tym samym urządzeniu, rozdziel wnioski. Możesz porównać odpowiedzi na różnych środowiskach, zapisując tę różnicę. Nie wyciągaj jednak z tego prostego wniosku, że skrócenie czasu spowodowała wyłącznie kwantyzacja. Odbiorca raportu powinien zobaczyć, które zmienne utrzymano, a których nie udało się oddzielić.

W decyzji można dopuścić mniejszy wariant do węższego zadania, zatrzymać wdrożenie albo zmienić sposób kontroli wyniku. Każda opcja potrzebuje granicy. „Do szkiców krótkich opisów z kontrolą wskazanego warunku” jest konkretniejsze niż „jakość akceptowalna”. Powinna też istnieć droga powrotu do wcześniejszego zestawu, jeśli późniejsza próba ujawni problem.

Osobno pozostaje lokalność całego procesu. Mniejszy plik nie dowodzi braku połączeń z usługami ani dostępności wszystkich składników bez internetu. Nie używaj pomiaru pamięci jako zastępstwa oceny obiegu danych. To dwa pytania, które mogą mieć różne wyniki.

Na końcu wybierz wariant na podstawie zapisanej pracy: co poprawnie robi, ile zasobów potrzebuje w sprawdzonych warunkach i gdzie kończy się jego dopuszczenie. Mniej gigabajtów jest wynikiem wartym odnotowania. Właściwa odpowiedź dla użytkownika nadal potrzebuje własnego dowodu.