Dlaczego pobranie modelu o pojemności 17 GB nie oznacza, że potrzeba 17 GB pamięci do jego uruchomienia

Został ogłoszony nowy model otwarty – w nagłówku twierdzi się, że konkuruje z znacznie większymi systemami, a jedna liczba przyciąga uwagę wszystkich: rozmiar pliku to zaledwie 17 GB. Wydaje się to oznaczać, że solidna pomoc w programowaniu jest dostępna nawet na zwykłym stanowisku pracy, dopóki nie załaduje się prawdziwego kodu lub długiej rozmowy, a proces nie wyczerpie pamięci. Rozmiar pliku, liczba aktywnych parametrów oraz ilość pamięci potrzebna działającemu modelowi to trzy różne wielkości. Ten artykuł wyjaśnia, jak się one wzajemnie powiązane są, aby można było oszacować rzeczywiste koszty uruchomienia modelu przed planowaniem sprzętu na podstawie nagłówka.

Liczba parametrów to słabszy wskaźnik niż kiedyś

Porównując modele językowe, większość ludzi najpierw zwraca uwagę na liczbę parametrów. To rozsądny instynkt: parametry to wyuczone wagi sieci, i wydaje się naturalne, że im więcej ich jest, tym model jest większy, inteligentniejszy i droższy.

Współczesne architektury znacznie osłabiły tę zależność. Jednym z wczesnych punktów zwrotnych były badania DeepMind nad Chinchillą dotyczące treningu optymalnego pod kątem zasobów obliczeniowych. Pokazały one, że model z 70 miliardami parametrów, treningowy na znacznie większej ilości danych, może przewyższyć modele o wiele większe, w tym Gophera z 280 miliardami parametrów, nawet gdy oba wykorzystują porównywalną ilość zasobów do treningu.

Wniosek nie brzmiał, że zwyciężają małe modele. Był on bardziej złożony i przydatny: sposób, w jaki model wykorzystuje swoje parametry, może być równie ważny jak ich liczba. Ta koncepcja stała się kluczowa dla innej architektury, która obecnie dominuje w dyskusjach na temat efektywnych modeli – Mixture of Experts.

Liczba parametrów aktywnych w porównaniu z całkowitą liczbą parametrów

Model typu Mixture of Experts (MoE) składa się z wielu podsieci ekspertów. Zamiast przesyłać każdy token przez całą sieć, mały router wybiera kilku ekspertów dla każdego tokena i tylko ci eksperci wykonywają pracę.

Potrzebną analogią jest firma z 100 pracownikami. Każda pojedyncza prośba klienta może wymagać tylko pięciu z nich, więc można powiedzieć, że pięć osób jest „aktywnych” przy realizacji tej prośby. Firma nadal musi zatrudniać, umieszczać w biurach i płacić wszystkich 100 pracowników, ponieważ następna prośba może wymagać innych pięciu.

Modele MoE zachowują się w ten sam sposób:

• Liczba parametrów aktywnych to w przybliżenie liczba parametrów biorących udział w tworzeniu jednego tokena.
• Całkowita liczba parametrów to łączna ilość parametrów występujących w modelu.

Różnica pomiędzy nimi może być ogromna. Dobrym przykładem jest DeepSeek-V3: ma łącznie około 671 miliardów parametrów, z czego przy każdym tokenie aktywowanych jest około 37 miliardów. Dlatego generowanie tokena jest znacznie tańsze niż w przypadku modelu o dużej liczbie parametrów, wynoszącej 671 miliardów. Nie oznacza to jednak, że DeepSeek-V3 zachowuje się we wszystkich praktycznych aspektach jak model z 37 miliardami parametrów, i właśnie tutaj wiele porównań zawodzi.

Koszt obliczeń i koszt pamięci to odrębne wydatki

Aktywne parametry stanowią dobry wskaźnik obliczeń: pokazują, ile operacji mnożenia i sumowania wymaga każdy token, a więc jak szybko można je generować na danym sprzęcie.

Pamięć to odrębny budżet. Silnik inferencji nie może usunąć ekspertów, którzy nie zostali wybrani dla bieżącego tokena, ponieważ router może wybrać dowolnego z nich dla następnego. Wszyscy oni muszą pozostać dostępni, zazwyczaj w GPU lub pamięci zintegrowanej, gdyż pobieranie wag z dysku dla każdego tokena byłoby zbyt wolne.

Dlatego model może być tani w obliczaniu, a mimo to wymagać dużej ilości pamięci. Kompaktowa zasada to opisuje:

Aktywne parametry wskazują, ile obliczeń potrzebuje każdy token. Całkowita wielkość modelu pokazuje, ile pamięci musi być dostępnych.

Te dwa wskaźniki są powiązane, ale odpowiadają na różne pytania i nie można ich ze sobą zamieniać.

Co faktycznie zawiera pobranie 17 GB

Dlatego opis „modelu AI o pojemności 17 GB” jest mylący. Plik z wagami skwantyzowanymi rzeczywiście może mieć taką wielkość. Skwantyzacja umożliwia przechowywanie każdej wagi przy użyciu mniejszej liczby bitów – na przykład 4 zamiast 16 – co kilkukrotnie zmniejsza rozmiar pliku przy niewielkiej stratie jakości.

Jednak plik na twoim SSD to tylko jeden z elementów potrzebnych do uruchomienia procesu. Oprócz niego wymagana jest pamięć na:

• wagi po ich załadowaniu do pamięci,
• własne nakłady czasowe procesu przetwarzania danych,
• tymczasowe bufory używane podczas obliczeń,
• kontekst przechowywany w buforze KV,
• oraz wszystko to, co już wykorzystuje system operacyjny i inne oprogramowanie.

Zatem plik o pojemności 17 GB nie oznacza, że komputer z 17 GB wolnej pamięci może swobodnie uruchomić ten model, a tym bardziej wtedy, gdy rośnie rozmiar kontekstu.

Pomiary społeczności dotyczące Qwen3.8-27B uświadamiają tę kwestię w praktyce. Wersja skwantyzowana o rozmiarze około 17 GB może wymagać znacznie więcej pamięci po załadowaniu długiego kontekstu, a przy naturalnej długości kontekstu modelu wynoszącej 262 144 tokenów sama pamięć KV staje się bardzo duża. Aby to zrozumieć, trzeba przyjrzeć się temu, w jaki sposób model zapamiętuje rozmowę.

Sama rozmowa zajmuje pamięć

Transformer nie czyta twojego zapytania raz i je odrzuca. Podczas generowania każdego nowego tokena odwołuje się do wszystkich wcześniejszych tokenów w kontekście. Ponowne obliczanie wewnętrznej reprezentacji całego kontekstu dla każdego nowego tokena byłoby niezwykle wolne, dlatego silniki inferencji przechowują zamiast tego wyniki pośrednie.

Tym magazynem jest KV cache, skrót od key/value cache. Dla każdego tokena w kontekście każda warstwa uwagi przechowuje wektor klucza oraz wektor wartości. Dlatego rozmiar tego magazynu rośnie w przybliżeniu liniowo wraz z długością kontekstu: model, który łatwo radzi sobie z krótką rozmową, może stać się znacznie cięższy, gdy poda mu się dziesiątki lub setki tysięcy tokenów, na przykład cały repozytorium.

Zgodnie z kartą modelu Qwen3.8-27B na Hugging Face, model ten obsługuje natywny kontekst składający się z 262 144 tokenów. Wykorzystuje on projekt hybrydowy, w którym tylko niektóre warstwy stosują konwencjonalną uwagę, co właśnie umożliwia praktyczne wykorzystanie tak długiego okna.

Jedna analiza architektury wskazuje, że warstwy, które nadal używają tradycyjnego pamięci cache, potrzebują około 64 KB danych KV-cache w formacie FP16 na każdy token. Pomnożąc to przez 262 144 tokenów, otrzymujemy w przybliżeniu 16,8 GB pamięci KV-cache, jeszcze zanim weźmiemy pod uwagę cokolwiek innego. Oryginalny budżet pamięci dla sesji z pełnym kontekstem wygląda następująco:

• wagi modelu: około 17 GB
• pamięć KV-cache przy pełnym kontekście: około 17 GB
• koszty operacyjne i bufory: dodatkowo

Model nigdy nie zmniejszył się do rozmiaru 17 GB. Pobrano 17 GB skwantyzowanych wag, ale rzeczywisty obciążenie może wynosić około dwukrotnie tyle lub więcej. Można tu również zrozumieć, dlaczego długość kontekstu jest kluczowym elementem do dostosowania, gdy pamięć jest ograniczona: zmniejszenie jej o połowę przybliżenie zmniejsza również rozmiar pamięci podręcznej, a wiele systemów może dodatkowo skwantyzować samą pamięć KV w celu jej dalszego zmniejszenia, choć z pewnymi stratami w dokładności. Podane przez społeczność wartości są jedynie szacunkami; należy je porównać z danymi o zużyciu pamięci podawanymi przez własny system.

Jak hybrydowa uwaga sprawia, że długie konteksty są dostępne

Tutaj architektura staje się interesująca. W tradycyjnym transformatorze każda warstwa uwagi przechowuje własne wpisy KV, więc rozmiar pamięci podręcznej rośnie wraz z liczbą warstw oraz liczbą tokenów.

Zgodnie z opublikowanymi analizami jego projektu, Qwen3.8-27B stosuje podejście hybrydowe. Z 64 warstw tylko niewielka ich liczba wykorzystuje pełną uwagę, podczas gdy większość używa uwagi liniowej. Warstwy z uwagą liniową podsumowują przeszłość w stan o stałej wielkości zamiast przechowywać klucze i wartości dla każdego tokena, dzięki czemu nie powiększają rosnącej pamięci cache. Tylko warstwy z pełną uwagą ponoszą koszt za każdy token, dlatego wartość za token jest tak niska.

Takie sztuczki sprawiają, że bardzo długie okna kontekstowe stają się wykonalne. Bez nich pamięć potrzebna do przechowywania 250 000 tokenów szybko stałaby się niepraktyczna poza sprzętem centrów danych.

Dlatego za każdym razem, gdy model reklamuje ogromne okno kontekstowe, zadaj dodatkowe pytanie: co robi architektura, aby ten kontekst był dostępny? Sama długość kontekstu nic ci nie mówi.

Zwycięstwo w jednym teście nie oznacza zwycięstwa ogólnego

Tytuły artykułów mają jeszcze jeden nawyk: model „przewyższa Claude’a” lub „przewyższa GPT” w jednym teście, a wyciągany wniosek brzmi, że jest lepszy ogólnie. Testy te mierzą konkretne zadania w określonych warunkach, a pojedyncza ocena niewiele mówi o czymkolwiek innym.

Qwen3.8-27B dobrze to ilustruje. Jego opublikowane wyniki pokazują wysokie wyniki w zakresie programowania:

• Terminal-Bench 2.1, który testuje pracę w terminalu: 73,0
• SWE-bench Pro, który testuje naprawianie rzeczywistych problemów w repozytoriach: 61,7
• GPQA Diamond, zbiór pytań naukowych na poziomie studiów podyplomowych: 89,2

W porównaniu z wynikami Opus 4.6 Max w ramach tej samej tabeli modeli opinie są podzielone. Na Terminal-Bench 2.1 Qwen plasuje się za wynikiem 78,2 osiągniętym przez Opus 4.6 Max. Na SWE-bench Pro jego wynik 61,7 jest lepszy od 53,4 uzyskanego przez Opus. Na GPQA Diamond jego wynik 89,2 jest gorszy od 91,3.

Który model jest lepszy? To zależy od zadania. Praca terminalowa z użyciem agentów, naprawa błędów na poziomie repozytoriów oraz zadania naukowe na poziomie studiów magisterskich wymagają różnych umiejętności, podobnie jak zadania agentów o długim horyzoncie czasowym. Każdy test jest dowodem na jedną konkretną umiejętność, a nie uniwersalnym rankingiem inteligencji.

Metodologia również ma znaczenie. Narzędzia oceny, strategia formułowania pytań, dostępne narzędzia, metoda oceniania oraz konfiguracja modelu mogą wpływać na wyniki, a dostawcy nie zawsze testują konkurencyjne modele w identycznych warunkach. Stwierdzenie typu „Model X jest lepszy od Modelu Y” pomija ważną informację. Dokładniejsza wersja brzmi mniej więcej tak:

W tych warunkach Model X uzyskał wyższy wynik niż Model Y w tej ocenie.

To jest mniej ekscytujące, ale o wiele bardziej przydatne.

Wysiłek analityczny to ukryty czynnik mnożący koszty

Nawet po zrozumieniu parametrów i pamięci, jeszcze jedna zmienna może potajemnie wpłynąć na koszt uruchomienia modelu: to, jak długo analizuje on sytuację przed udzieleniem odpowiedzi.

Modele skupione na rozumowaniu coraz częściej oferują ustawienie do tego celu. Qwen3.8 obsługuje parametr reasoning_effort z poziomami low, medium i xhigh, przy czym domyślnym jest xhigh; w jego dokumentacji te poziomy są wyraźnie opisane jako elementy kontrolujące głębię i koszt rozumowania.

Kompromis jest prosty. Większe nakłady na rozumowanie mogą pomóc przy trudnych problemach, ale każdy krok rozumowania generuje tokeny: to oznacza większe obciążenie obliczeniowe, wydłużony czas reakcji oraz, w przypadku długich łańcuchów rozumowania, większy zużycie pamięci KV. Dlatego dwie osoby używające tego samego modelu mogą mieć zupełnie różne koszty wyłącznie ze względu na tę jedną ustawienie.

To ma szczególne znaczenie dla agentów kodujących, które zajmują się zadaniami o zupełnie różnym stopniu trudności. Porównajmy prośbę o przemianowanie zmiennej z prośbą o zbadanie nieznanej bazy danych, znalezienie błędu architektonicznego, zmianę sześciu plików, uruchomienie testów, zdiagnozowanie awarii oraz stworzenie poprawki. Pierwsza nie wymaga nawet w przybliżeniu takiego budżetu rozumowania jak druga. Wykonywanie maksymalnego poziomu rozumowania przy każdej prośbie to jak wciąganie doświadczonego inżyniera na spotkanie dotyczące etykiety na przycisku: to działa, ale jest to niewłaściwe wykorzystanie zasobów.

Istnieje pewna zastrzeżenie, na które wskazuje sama dokumentacja Qwen. Zmniejszenie nakładu pracy może przyspieszyć każdy pojedynczy krok, ale powodować więcej prób ponownych lub niepowodzeń w zadaniami wieloetapowych, co może zniwelować oszczędności. Praktycznym podejściem jest mierzenie całkowitego kosztu zadania, a nie opóźnienia na każdym kroku, oraz kierowanie prostymi i trudnymi zadaniami do różnych ustawień, jeśli to umożliwiają narzędzia. Żadne jedno ustawienie nie nadaje się do wszystkiego.

Dlaczego efektywny obliczanie aktywne wciąż ma duże znaczenie

Pomimo tych zastrzeżeń łatwo byłoby uznać, że historia zdolnych małych modeli lokalnych to tylko hiperbola. Tak nie jest. Postępy są rzeczywiste: modele z umiarkowanym budżetem obliczeniowym mogą teraz obsługiwać poważne zadania z zakresu inżynierii oprogramowania, które jeszcze kilka lat temu byłyby bardzo trudne do uruchomienia lokalnie.

Jedyną konieczną korektą jest to, że wydajne obliczanie nie oznacza automatycznie małego zużycia pamięci.

Różnica ta ma jeszcze większe znaczenie w skali centrów danych. Dostawca obsługujący tysiące użytkowników ładowa wagę tylko raz i udostępnia ją we wszystkich żądaniach. Natomiast cache typu KV należy do każdej pojedynczej rozmowy. Zmniejszenie ilości pamięci potrzebnej do każdej aktywnej rozmowy umożliwia obsługę większej liczby użytkowników jednocześnie na tym samym sprzęcie, co bezpośrednio obniża koszty obsługi modelu.

Patrząc w ten sposób, szczegóły architektoniczne, które wydają się skomplikowanymi technikami badawczymi, takie jak hybrydowa uwaga czy kompresja cache typu KV, stają się istotnymi czynnikami ekonomicznymi. Model nie musi być mały we wszystkich aspektach – musi być wydajny tam, gdzie infrastruktura jest najsilniej obciążona.

Kiedy model o pojemności 17 GB naprawdę stanowi świetną ofertę

Istnieje również bardzo pozytywny aspekt. Wiele rzeczywistych zadań wymaga krótkiego kontekstu:

• jeden plik,
• jedno konkretne zadanie programistyczne,
• mali projekt,
• zwykła rozmowa.

W takich przypadkach dobrze skwantyzowany model z tej kategorii może być naprawdę imponujący. Nie potrzeba dużego serwera chmurowego, aby go wypróbować. Można uruchomić wydajny model na sprzęcie konsumenckim, przechowywać dane na własnym komputerze i unikać opłat za każdy token w ramach API przy każdym eksperymencie. Aby zobaczyć praktyczny przykład takiego procesu, sprawdź tworzenie lokalnego klonu Angry Birds przy użyciu Qwen3.8-27B i Pi.

To rozszerza krąg osób, które mogą eksperymentować z zaawansowaną sztuczną inteligencją, co jest prawdopodobnie ważniejsze niż to, czy jeden wynik testowy jest o trzy punkty wyższy od drugiego.

Cztery pytania do zadań zamiast „ile parametrów?”

Następnym razem, gdy nagłówek podkreśla małą liczbę parametrów lub niewielki rozmiar pliku do pobrania, przemyśl te cztery pytania.

Ile parametrów jest aktywnych?

Pozwala to określić obliczenia na token i tym samym przybliżoną szybkość generowania modelu na twoim sprzęcie.

Ile parametrów istnieje łącznie?

Pomaga to zrozumieć ogólny rozmiar modelu, co jest głównym czynnikiem determinującym ilość pamięci potrzebnej do przechowywania wag.

Jaki jest rozmiar pamięci cache KV?

Zależy to od architektury oraz długości kontekstu, którą planujesz użyć; staje się kluczowym czynnikiem przy długich kontekstach.

Ile czasu model potrzebuje na rozważenie przed udzieleniem odpowiedzi?

Wpływa to na opóźnienie, zużycie tokenów i koszt, a można to dostosować do poszczególnych zadań.

Wspólnie te cztery odpowiedzi mówią ci o wiele więcej niż kiedykolwiek może to zrobić rozmiar pliku do pobrania.

Modele stały się bardziej wydajne, niekoniecznie mniejsze

Ogólny trend to rzeczywiste poprawy wydajności we całym stacku: lepsze strategie szkolenia i skalowanie danych, lepsze kierowanie zapytaniami do ekspertów, lepsza kwantyzacja, lepsze architektury uwagi oraz możliwość konfiguracji procesu rozumowania w czasie wykonywania zapytania.

Żadne z tych elementów nie sprawia, że wydajne obliczenia są tożsame z małym zużyciem pamięci:

• Model typu MoE może aktywować tylko część swoich parametrów na jeden token, zachowując przy tym bardzo dużą sieć.
• Model kwantyzowany może zajmować niewielką ilość miejsca na dysku, ale wymagać znacznie więcej pamięci podczas wykonywania zapytania.
• Długi okno kontekstowe może sprawić, że sama rozmowa zajmie kilka gigabajtów.
• Wyższy poziom rozumowania może sprawić, że to samo zapytanie będzie wymagać znacznie większych zasobów obliczeniowych.

Zatem lepsze pytanie brzmi nie o to, ile parametrów ma model. Jest bliższe temu:

Ile pamięci i mocy obliczeniowej potrzebuje ten konkretny zadanie, od załadunku modelu po wygenerowanie końcowego tokena?

Główne wnioski

• Rozmiar pliku do pobrania modelu obejmuje tylko jego wagi; cache KV, koszty operacyjne oraz bufory dodają się do tego i mogą podwoić rzeczywiste wymagania przy długim kontekście.
• Aktywne parametry opisują moc obliczeniową na token, natomiast łączna liczba parametrów określa, ile pamięci musi być dostępne.
• Rozmiar cache KV skaluje się wraz z długością kontekstu i w dużej mierze zależy od architektury, dlatego hybrydowe rozwiązania typu attention są ważne przy długich oknach kontekstowych.
• Sukcesy w testach benchmark są specyficzne dla danego zadania i zależne od metodologii; należy je interpretować jako „lepsze w tym konkretnym testowaniu”, a nie jako „lepsze ogólnie”.

Wysiłek potrzebny do rozumowania stanowi rzeczywisty czynnik wpływający na koszty, ale należy mierzyć całkowity koszt zadania, ponieważ mniejszy wysiłek może skutkować próbami ponownymi, które unieważniają oszczędności.

Gdy nagłówek obiecuje mały model, który przewyższa model gigantyczny, przed przyjęciem lub odrzuceniem takiej informacji sprawdź wyniki testów, ustawienia, liczbę parametrów aktywnych i całkowitą liczbę parametrów, metody kwantyzacji, długość kontekstu oraz budżet na rozumowanie.

Literatura pokrewna

• Zrozumienie pamięci AI: kontekst, embeddingi, RAG i wagi modelu wyjaśnione — Ten artykuł szczegółowo opisuje, w jaki sposób systemy AI faktycznie przechowują informacje, omawiając okna kontekstowe, embeddingi, bazy danych wektorowych, RAG oraz parametry modelu.
• Kiedy kwantyzacja przekracza perpleksję i potajemnie niszczy bezpieczeństwo modelu — Kwantyzacja cache KV o niskiej liczbie bitów może usunąć mechanizmy odmowy modelu, podczas gdy perpleksja prawie się nie zmienia; oto dlaczego standardowe metryki tego nie wykrywają i co należy dodać do swojego mechanizmu kontroli.
• Wyjaśnienie długości rekurencyjnej: transformery z pętlami i ukryte rozumowanie — Jak transformery rekurencyjne (z pętlami) rozumują w stanie ukrytym, dlaczego laboratoria je preferują, co pokazuje osiem lat publikacji naukowych oraz jakie to ma znaczenie dla lokalnej sztucznej inteligencji i nadzoru.