Warianty, formaty i kwantyzacja LLM z otwartymi wagami

Viacheslav Dubrov

2025-05-11 · Zaktualizowano 2026-08-16 · 9 min · Inżynieria modeli

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Nazwy takie jak Model-32B-A3B-Instruct-AWQ wyglądają na złożone, ponieważ łączą kilka niezależnych decyzji: rodzinę i rozmiar, architekturę, rolę treningową oraz kwantyzację. Repozytorium może udostępniać takie wagi w postaci shardów Safetensors, podczas gdy konwersja tego samego checkpointu przygotowana przez społeczność może występować jako Q4_K_M.gguf.

Te etykiety nie należą do jednej kategorii: GPTQ i AWQ to metody kwantyzacji, GGUF to kontener i ekosystem runtime, a MoE to architektura. Rozdzielenie tych warstw ułatwia wybór plików do pobrania.

Wybierając między pobraniem Q4_K_M.gguf do lokalnej inferencji a repozytorium Safetensors z AWQ do serwowania na GPU, zacznij od zachowania checkpointu i architektury wymaganych przez zadanie. Następnie potwierdź, że jego reprezentacja numeryczna, układ pakietu i docelowy runtime pasują do dostępnego sprzętu, pamięci oraz ograniczeń serwowania.

TL;DR. Wybierz checkpoint na podstawie jakości na zadaniu, licencji, języka, kontekstu i zachowania interfejsu. Następnie wybierz runtime obsługujący jego architekturę. Dopiero potem wybierz reprezentację wag i kwantyzację pasujące do zmierzonego zużycia pamięci oraz opóźnienia. GPTQ i AWQ to metody kwantyzacji, Safetensors i GGUF to kontenery, a MoE to architektura. Etykieta MoE nie oznacza, że wszystkie wagi zmieszczą się w pamięci odpowiadającej „aktywnym parametrom”.

W sprawie zwięzłego wyboru wdrożeniowego zobacz Formaty kwantyzacji LLM.

Odczytuj artefakt modelu w sześciu warstwach

Pochodzenie treningowe opisuje te warstwy, zamiast dodawać kolejną warstwę artefaktu. Na przykład distilled opisuje sposób transferu zachowania, a nie rolę checkpointu. Checkpoint może być jednocześnie destylowany, dostrojony instrukcyjnie, dostrojony pod kątem rozumowania i mieć architekturę MoE.

Etykieta „open-source” wymaga osobnej weryfikacji. Jeśli model udostępnia wyłącznie wagi do pobrania, nie zakładaj, że jego licencja spełnia definicję open-source ani że pozwala na użycie w Twoim przypadku. Przeczytaj kartę modelu i licencję przed porównywaniem architektury lub benchmarków.

Etykiety roli treningowej opisują zachowanie, a nie gwarancje możliwości

Base

Checkpoint Base jest trenowany głównie pod kątem predykcji kolejnego tokena. Przydaje się do dalszego pretrainingu, kontrolowanych badań lub adaptacji, gdy chcesz samodzielnie zdefiniować zachowanie instrukcyjne. Może uzupełniać prompt zamiast na niego odpowiadać.

Nie zakładaj, że każdy fine-tuning powinien zaczynać się od modelu Base. Checkpoint Instruct może być lepszą inicjalizacją, jeśli jego obecne zachowanie jest zgodne z celem. Potwierdź w ewaluacji, że istniejące zachowanie nie koliduje z nowym celem.

Instruct lub chat

Te checkpointy przechodzą post-training mający poprawić wykonywanie instrukcji i prowadzenie rozmowy. Dokładny proces może obejmować supervised fine-tuning, optymalizację preferencji, reinforcement learning, destylację lub ich kombinację. Nie musi to być supervised fine-tuning, po którym następuje RLHF.

Użyj checkpointu Instruct jako pierwszego baseline’u asystenta. Sprawdź jego szablon rozmowy, obsługiwany format wywołań narzędzi, zachowanie komunikatu systemowego i charakterystykę odmów. Sama etykieta „Instruct” nie gwarantuje niezawodnego JSON ani korzystania z narzędzi.

Reasoning-tuned

Checkpointy ukierunkowane na rozumowanie są optymalizowane na zadaniach lub trajektoriach premiujących wieloetapowe rozwiązywanie problemów. Niektóre ujawniają tekst rozumowania, inne oddzielają go za pomocą parsera w warstwie serwowania, a jeszcze inne prezentują wyłącznie odpowiedź. Dłuższe generowanie nie gwarantuje wiernego rozumowania ani mniejszej liczby halucynacji.

Wybierz taki model, jeśli poprawia trudne wycinki ewaluacji po uwzględnieniu liczby tokenów wyjściowych, opóźnienia i weryfikacji. Rutynowa ekstrakcja lub klasyfikacja może stać się wolniejsza bez poprawy jakości.

Distilled

Destylacja przenosi zachowanie z nauczyciela lub danych wygenerowanych przez nauczyciela do innego modelu. Uczeń może być mniejszy, tego samego rozmiaru albo mieć inną strukturę. Nie istnieje stabilna reguła „70–80% jakości przy połowie rozmiaru”: zachowana jakość zależy od nauczyciela, danych, celu, możliwości ucznia i ewaluacji.

Traktuj Distill jako informację o pochodzeniu treningowym, a następnie benchmarkuj ten model jak każdy inny checkpoint.

Która etykieta powinna wpływać na poszczególne etapy wyboru? Ta mapa oddziela rolę treningową, pochodzenie treningowe i architekturę. Nie szereguje typów modeli według jakości.

Dokumentacja szablonów rozmowy w Transformers wyjaśnia, dlaczego dokładny format wiadomości modelu dostrojonego instrukcyjnie ma znaczenie. W oryginalnej publikacji o destylacji wiedzy Hinton, Vinyals i Dean przenoszą zachowanie do modelu ucznia, nie deklarując stałego współczynnika jakości. Publikacja Switch Transformer przedstawia jeden ze sposobów rzadkiego routingu do ekspertów. Konkretna rodzina MoE może kierować tokeny inaczej, dlatego nadrzędnym źródłem pozostaje jej karta modelu.

Etykiety architektury opisują wykonanie

Modele Dense

Większość parametrów uczestniczy w przebiegu forward dla każdego tokena. Liczba parametrów jest przybliżonym wskaźnikiem rozmiaru przechowywanych wag. Pamięć runtime obejmuje również KV cache, aktywacje lub workspace, narzut alokatora, a czasem także zduplikowany lub shardowany stan.

Mixture of Experts

Warstwa MoE kieruje każdy token do podzbioru eksperckich sieci feed-forward. Nazwy takie jak A3B często oznaczają w przybliżeniu trzy miliardy parametrów aktywnych dla każdego tokena, ale konwencje nazewnicze zależą od rodziny. Sprawdź w karcie modelu łączną liczbę parametrów, liczbę parametrów aktywnych, liczbę ekspertów i sposób routingu.

Liczba aktywnych parametrów opisuje obliczenia kierowane, a nie rozmieszczenie wag. Na przykład parallelizm ekspertów w vLLM sharduje warstwy ekspertów między rangami expert-parallel i wyznacza przydział ekspertów dla każdej rangi na podstawie łącznej liczby ekspertów. Inne runtime mogą rozmieszczać lub offloadować wagi inaczej. Model z 30B parametrów łącznie i 3B aktywnych nie mieści się więc automatycznie tak jak gęsty model 3B.

Obsługa runtime również zależy od architektury. Przed pobraniem potwierdź implementację modelu, obsługę expert-parallel lub tensor-parallel, kernele kwantyzacji oraz maksymalny kontekst.

Kontenery i kwantyzacja to różne warstwy

Safetensors

Safetensors to bezpieczny format serializacji tensorów, często używany w repozytoriach Hugging Face. Model może składać się z wielu shardów .safetensors oraz plików konfiguracji, tokenizera i generowania. Tensors mogą być zapisane w BF16/FP16 albo wstępnie skwantyzowane metodą taką jak GPTQ lub AWQ.

Samo rozszerzenie nie informuje o precyzji ani kompatybilności z runtime. Sprawdź config.json, konfigurację kwantyzacji, kartę modelu, dtype tensorów i dokumentację runtime.

GGUF

GGUF pakuje tensory i metadane dla ekosystemu ggml/llama.cpp. llama.cpp ładuje GGUF i obsługuje backendy obejmujące Metal, CUDA, HIP, Vulkan oraz ścieżki CPU. Architektura modelu i jakość konwersji nadal decydują o kompatybilności.

GGUF jest kontenerem. Może zawierać tensory o wysokiej precyzji lub tensory skwantyzowane. Modele multimodalne mogą dodatkowo wymagać osobnego pliku projectora lub enkodera. Stwierdzenie „jeden plik GGUF zawiera wszystko” nie jest uniwersalną regułą.

GPTQ i AWQ

GPTQ i AWQ to metody kwantyzacji wag po treningu, a nie rozszerzenia plików. Ich artefakty zwykle używają Safetensors wraz z konfiguracją specyficzną dla danej metody. Silniki serwujące potrzebują kerneli zgodnych z metodą, szerokością bitową, rozmiarem grupy, architekturą modelu i sprzętem.

Żadna z tych metod nie gwarantuje uniwersalnie najlepszej jakości. Znaczenie mają dane kalibracyjne, implementacja, ścieżka kerneli i zadanie. Obsługa runtime się zmienia, dlatego zweryfikuj dokładny artefakt względem przypiętej wersji. Przy tej decyzji sprawdź oficjalne strony Transformers quantization i vLLM quantization.

Sam sprzęt nie pozwala wybrać kontenera. Najpierw wybierz runtime obsługujący architekturę i interfejs serwowania. Następnie użyj układu artefaktu i ścieżki kwantyzacji udokumentowanych przez ten runtime.

Na przykład projekt llama.cpp wymaga GGUF i dokumentuje kilka backendów sprzętowych. Specyfikacja GGUF definiuje kontener na tensory i metadane. Transformers ładuje natomiast metody kwantyzacji za pomocą konfiguracji zależnej od backendu, zgodnie z opisem w swoim workflow kwantyzacji. Żadne z tych źródeł nie gwarantuje, że pasujące rozszerzenie obsługuje każdą architekturę ani że działa dobrze na każdym urządzeniu.

Matematyka kwantyzacji to dolna granica, a nie planowanie pojemności

Dla $P$ parametrów wag przy $b$ bitach surowy rozmiar przechowywanych wag wynosi w przybliżeniu:

Model 13B z nominalnie czterobitowymi wagami zaczyna więc od około 6,5 GB. Nie oznacza to, że uruchomi się w 6,5 GB. Skale, punkty zerowe, tensory o wyższej precyzji, embeddings, metadane, bufory runtime, KV cache i fragmentacja zwiększają zużycie pamięci.

Kontekst i współbieżność mogą zdominować różnicę między „ładuje się” a „można serwować”. Zmierz szczytowe zużycie pamięci przy rzeczywistej maksymalnej długości sekwencji, polityce batchowania, dtype cache i sposobie równoległości.

Kwantyzacja może zmniejszyć zużycie pamięci i czasem poprawić szybkość, ale kernele niskobitowe mogą być także wolniejsze na nieobsługiwanym sprzęcie. Porównuj jakość na zadaniu i przepustowość end-to-end, a nie tylko rozmiar pliku. Zobacz przewodnik po kwantyzacji llama.cpp, aby poznać receptury specyficzne dla runtime.

Uważnie odczytuj nazwy kwantyzacji GGUF

W llama.cpp element Q4_K_M oznacza recepturę kwantyzacji na poziomie pliku, a nie jeden typ tensora stosowany wszędzie. llama-quantizeopcje udostępniają Q4_K_M jako wybieralny typ i opisują --pure jako wyłączenie mieszanek K-quant. Implementacja kwantyzatora używa Q4_K jako domyślnego typu dla tej receptury i stosuje inne typy do niektórych kategorii tensorów. Traktuj sufiks jako nazwę receptury llama.cpp, a nie przenośną specyfikację szerokości bitowej.

Aktualna llama.cpp dokumentacja kwantyzacji pokazuje również, że receptury mogą różnić się zależnie od architektury i kategorii tensorów. Macierz ważności może wskazywać, które wagi powinny zachować wyższą precyzję.

Unikaj uniwersalnych twierdzeń, że Q4_K_M jest nieodróżnialne od BF16 albo że większy model Q3 zawsze pokona mniejszy model Q8. Użyj niewielkiej drabiny dla dokładnego checkpointu:

1. artefakt o wysokiej precyzji lub zaufany artefakt referencyjny
2. jeden kandydat blisko limitu pamięci
3. jeden mniejszy kandydat z większym zapasem

Uruchom te same prompty, testy ustrukturyzowanych danych wyjściowych, przypadki z długim kontekstem i test opóźnienia na wszystkich trzech.

Workflow wyboru odporny na nowe formaty

1. Zdefiniuj kontrakt zadania

Zdefiniuj język, modalność, długość kontekstu, interfejs narzędzi lub schematu, ograniczenia bezpieczeństwa, wymagania licencyjne i wycinki ewaluacji. Porównuj checkpointy w reprezentacji wystarczająco dokładnej, aby kwantyzacja nie decydowała o pierwszej rundzie.

2. Wybierz checkpoint

Wybierz najmniejszy checkpoint, który spełnia niepodlegające negocjacji wymagania jakościowe i behawioralne. Zapisz dokładne repozytorium i rewizję, tokenizer, szablon rozmowy oraz wymagany parser rozumowania.

3. Wybierz runtime

Sprawdź obsługę architektury, backend sprzętowy, równoległość, kernele kwantyzacji, ustrukturyzowane dane wyjściowe, adaptery i interfejs operacyjny. W przypadku lokalnej inferencji GGUF llama.cpp jest referencyjnym runtime. W przypadku serwowania na GPU porównaj aktualne vLLM, TGI, Transformers lub wyspecjalizowane silniki z rzeczywistym artefaktem.

4. Ustal budżet pamięci na podstawie pomiarów

Uwzględnij wagi, KV cache, workspace runtime, oczekiwaną współbieżność oraz zapas dla systemu operacyjnego lub procesów współdzielących sprzęt. To, że plik mieści się w RAM lub VRAM, jest konieczne, ale niewystarczające.

5. Wybierz i zweryfikuj reprezentację

Preferuj artefakty dostarczone przez autora, z udokumentowaną kalibracją i pochodzeniem. Jeśli używasz konwersji społecznościowej, zapisz rewizję źródła, rewizję konwertera, recepturę kwantyzacji, dane kalibracyjne lub dane ważności oraz hashe.

6. Benchmarkuj jednostkę wydania

Zmierz jakość na zadaniu, poprawność schematu i wywołań narzędzi, czas do pierwszego tokena, przepustowość generowania, szczytowe zużycie pamięci oraz błędy przy docelowym kontekście i współbieżności. Powtórz pomiary po każdej zmianie checkpointu, runtime, kernela lub ustawienia kwantyzacji.

Przykładowa nazwa

Załóżmy, że repozytorium nosi nazwę:

Acme-32B-A3B-Instruct-AWQ

Odczytaj ją jako zestaw pytań:

• Acme: jaka rodzina, licencja i rewizja?
• 32B: łączna liczba wag czy inna konwencja autora?
• A3B: jak ta rodzina definiuje aktywne parametry?
• Instruct: jaka receptura post-training i jaki szablon rozmowy?
• AWQ: jaka szerokość bitowa, rozmiar grupy, kalibracja i obsługiwane kernele?
• pliki repozytorium: shardy Safetensors, konfiguracje, tokenizer i kod niestandardowy?
• docelowy runtime: czy przypięta wersja obsługuje dokładnie tę architekturę i kwantyzację?

Nazwa jest indeksem do dokumentacji, a nie kompletną specyfikacją wdrożenia.

Podsumowanie

Wybór modelu staje się mniej zagmatwany, gdy etykiety przestają być traktowane jako należące do jednej kategorii. Rola treningowa mówi, jakie zachowanie optymalizowano. Architektura mówi, jak zorganizowano obliczenia. Kwantyzacja mówi, jak przybliżono niektóre tensory, kontenery — jak przechowywane są artefakty, a runtime — co działa wydajnie na danym sprzęcie.

Wybieraj w tej kolejności, zachowuj dokładne informacje o pochodzeniu i pozwól, aby jedna ewaluacja zadania porównywała artefakty wydania. Znany sufiks nie jest dowodem, że model zmieści się w pamięci, będzie działał szybko ani zachowa potrzebne zachowanie.

Referencje

• Szablony rozmowy w Transformers — formatowanie wiadomości dla bazowych i dostrojonych instrukcyjnie causal language models.
• Distilling the Knowledge in a Neural Network — oryginalna publikacja Hintona, Vinyalsa i Deana o destylacji.
• Switch Transformers — architektura rzadkiego routingu do ekspertów autorstwa Fedusa, Zopha i Shazeera.
• Specyfikacja GGUF oraz przewodnik po kwantyzacji llama.cpp
• Koncepcje kwantyzacji w Hugging Face Transformers
• Publikacja GPTQ
• Publikacja AWQ
• Dokumentacja kwantyzacji vLLM