Kwantyzacja i szybkie wnioskowanie na własnym sprzęcie

Pierwszą reakcją wielu inżynierów, gdy spojrzą na wymagania sprzętowe dla najnowocześniejszego dużego modelu językowego, jest szok cenowy. Model z 70 miliardami parametrów w natywnym formacie FP32 wymagałby około 280 GB pamięci GPU — więcej niż większość organizacji ma w jednym serwerze i znacznie więcej niż chcą przeznaczać tylko na odpowiadanie na zapytania pracowników. Kwantyzacja to technika, która sprawia, że te liczby są łatwe do opanowania, i jej zrozumienie jest niezbędne dla każdego projektującego stos AI on-premise.

Co kwantyzacja faktycznie robi

Sieć neuronowa to ostatecznie bardzo duży zbiór liczb — wag wyuczonych podczas trenowania. Domyślnie wagi te są przechowywane jako 32-bitowe liczby zmiennoprzecinkowe (FP32), każda zajmująca 4 bajty pamięci. Kwantyzacja zastępuje wysokoprecyzyjne liczby reprezentacjami o niższej precyzji: 16-bitowe liczby zmiennoprzecinkowe (FP16 lub BF16), 8-bitowe liczby całkowite (INT8) lub nawet 4-bitowe liczby całkowite (INT4). Zajętość pamięci proporcjonalnie się zmniejsza, a na sprzęcie z natywną obsługą arytmetyki niższej precyzji wnioskowanie jest również szybsze.

• FP16 / BF16 — liczby zmiennoprzecinkowe o połowicznej precyzji. Praktycznie bezstratne dla większości zadań; domyślny wybór do wdrożeń produkcyjnych, gdzie dokładność jest krytyczna. Oszczędności pamięci: 2x w porównaniu z FP32.
• INT8 — 8-bitowe liczby całkowite, zazwyczaj produkowane metodami kwantyzacji post-treningowej (PTQ) takimi jak GPTQ lub llm.int8(). Umiarkowana degradacja jakości przy złożonym rozumowaniu; znacząca dla większości praktycznych zadań. Oszczędności pamięci: 4x w porównaniu z FP32.
• INT4 — 4-bitowe liczby całkowite, granica agresywnej kwantyzacji. Narzędzia takie jak GGUF Q4_K_M i AWQ dostarczają zaskakująco dobrą jakość dla swojego rozmiaru. Oszczędności pamięci: 8x w porównaniu z FP32, z akceptowalną degradacją dla obciążeń czatu i streszczania.

Kompromis jakości a rozmiaru

Kwantyzacja nie jest darmowa. Każdy bit, który usuwasz, to informacja odrzucona, i w pewnym momencie objawia się to jako zdegradowane wyniki — halucynacje, błędy rozumowania lub utrata niuansów. Praktyczne odkrycie z wdrożeń Privonis jest takie, że kompromis jest zaskakująco korzystny dla większości zadań korporacyjnych. Model 70B skwantowany do INT4 zazwyczaj przewyższa model 13B przy FP16, nawet jeśli oba mieszczą się w podobnej pamięci GPU. W razie wątpliwości używaj największego modelu, który mieści się przy najwyższej precyzji, którą obsługuje Twój sprzęt.

Wybór właściwej kwantyzacji to mniej kwestia liczby bitów, a bardziej dopasowanie pojemności modelu do zadania: dobrze wybrany INT4 70B bije niedbały FP16 13B za każdym razem.

Serwery wnioskowania: skąd pochodzi przepustowość

Uruchomienie skwantowanego modelu to tylko połowa historii. Efektywne serwowanie go pod jednoczesnym obciążeniem wymaga serwera wnioskowania, który rozumie strukturę uwagi transformatora. Dominującą opcją open-source jest dziś vLLM, który wprowadził PagedAttention — technikę zarządzania pamięcią zapożyczoną z wirtualnej pamięci systemu operacyjnego, pozwalającą serwerowi przeplatać wiele żądań jednocześnie bez marnowania pamięci GPU na wstępnie przydzielone bloki cache KV. Praktyczny efekt to 10–30x poprawa przepustowości w porównaniu z naiwną pętlą jednorazowych żądań.

Inne godne uwagi opcje to llama.cpp (przyjazny CPU, doskonały dla mniejszych modeli na sprzęcie towarowym), Ollama (przyjazne dla programistów opakowanie wokół llama.cpp), TGI od Hugging Face (silne wsparcie dla formatów modeli Hugging Face) i TensorRT-LLM od NVIDIA (najwyższa przepustowość na sprzęcie NVIDIA, kosztem bardziej złożonego potoku kompilacji). Privonis ocenia i benchmarkuje wszystkie z nich dla każdej konfiguracji klienta.

Batchowanie i przepustowość

GPU osiągają szczytową wydajność przetwarzając wiele operacji jednocześnie — do tego zostały zaprojektowane. Ciągłe batchowanie (zwane również dynamicznym batchowaniem lub planowaniem na poziomie iteracji) pozwala serwerowi wnioskowania grupować tokeny z wielu jednoczesnych żądań w jedno wywołanie jądra GPU, dramatycznie poprawiając wykorzystanie. Bez batchowania pojedyncze zapytanie użytkownika może używać 5% pojemności GPU; z ciągłym batchowaniem możesz osiągnąć wykorzystanie 70–80% przy rzeczywistych wzorcach ruchu. Dla przedsiębiorstwa z dziesiątkami jednoczesnych użytkowników różnica między serwerem świadomym batchowania a naiwnym może oznaczać różnicę między potrzebą jednego serwera GPU lub czterech.

Wybór właściwej kwantyzacji dla Twojego GPU

Drzewo decyzyjne jest prostsze niż wygląda. Zacznij od budżetu pamięci GPU, odejmij margines dla systemu operacyjnego i serwera wnioskowania (zazwyczaj 4–8 GB), a następnie znajdź największy model, który mieści się przy najwyższym poziomie precyzji. Kilka praktycznych punktów odniesienia:

• 24 GB VRAM (np. RTX 4090, A5000) — komfortowo uruchamia model 13B przy FP16 lub model 34B przy INT4.
• 48 GB VRAM (np. RTX 6000 Ada, A6000) — uruchamia model 34B przy FP16 lub model 70B przy INT4.
• 2 × 80 GB (np. para A100 przez NVLink) — uruchamia model 70B przy FP16 lub model 140B przy INT4 z tensor parallelism.
• Tylko CPU (bez GPU) — llama.cpp z modelem Q4_K_M 7B lub 13B jest opłacalne dla narzędzi deweloperskich o niskiej współbieżności; oczekuj 5–15 tokenów/s.

Składanie wszystkiego razem z Privonis

Wybór formatu kwantyzacji i serwera wnioskowania to praca inżynierska, wymagająca profilowania na konkretnym sprzęcie z konkretnym obciążeniem. Privonis obsługuje to benchmarkowanie jako część każdego wdrożenia: przeprowadzamy testy przepustowości, mierzymy jakość wyników na reprezentatywnej próbce rzeczywistych promptów i dostarczamy konfigurację maksymalizującą wydajność w ramach budżetu sprzętowego. Wynikiem jest produkcyjny stos wnioskowania, który Twój zespół może obsługiwać bez specjalisty ML dostępnego pod telefonem. Jeśli jesteś gotowy zbadać, co pasuje do Twojego środowiska, nasz zespół chętnie przeprowadzi z Tobą obliczenia.