Table of Contents

Lokalna AI jest praktyczną opcją dla ograniczonych zadań z jasnymi kontrolami. Zastąpienie pracy przekazywanej ChatGPT lub Claude wymaga zgodności trzech elementów: możliwości modelu, użytecznej pamięci oraz agenta wyposażonego w narzędzia do sprawdzania i weryfikowania wyników.

Model mieszczący się w twojej stacji roboczej nadal potrzebuje odpowiednich narzędzi i wystarczającej szybkości dla kolejnych prób. Ten artykuł oddziela wyniki testów, szacunki pamięci i dowody wykonania zadań, aby oceniać je osobno.

Najważniejsze wnioski

  • Możliwości: wyniki referencyjne opisują konkretne ustawienia testu, a nie twoją lokalną wersję po kwantyzacji.
  • Pamięć: razem zaplanuj miejsce na wagi, cache kontekstu i narzut środowiska uruchomieniowego.
  • Szybkość: odtworzenie rozmowy agenta mierzy wydajność obsługi, a nie poprawność.
  • Weryfikacja: agent potrzebuje kontroli dopasowanych do oczekiwanego wyniku.
  • Wybór: przed zakupem sprzętu porównaj powtarzalne zadania, czas napraw i całkowity koszt.

Odczytuj wyniki w kontekście

Artificial Analysis Intelligence Index łączy kilka ocen w jeden wynik referencyjny. Ranking modeli i lokalne wyniki sprzętowe pokazują poniższe wybrane wpisy sprawdzone 6 października 2026 roku.

Model i ustawienie Wynik indeksu Wdrożenie w tym porównaniu
Qwen3.8 27B, xhigh 34 Wagi do pobrania
GLM-5.3, max 45 Wagi do pobrania
GPT-6 Astra, max 53 Usługa hostowana
Claude Opus 5.5, max z fallbackiem 58 Usługa hostowana

Punkty indeksu nie są procentem inteligencji ani skuteczności zadania. Różnica 13 punktów między GLM i Claude nie oznacza 13% różnicy w wynikach programowania. Ustawienie rozumowania także ma znaczenie przy porównywaniu tego samego modelu.

Opublikowana metodologia oceny opisuje konfigurację testu. Niektóre oceny obejmują narzędzia i infrastrukturę agentów. Traktuj wynik jako rezultat w tych warunkach. Nie przenoś go bezpośrednio na skompresowaną kopię lokalną uruchamianą przez inną aplikację.

ChatGPT i Claude są produktami, a tabela porównuje wybrane modele bazowe. Dodatkowe różnice wprowadza subskrypcja, wybrany model, dostępne narzędzia i kontekst zadania. Zacznij od zadania, które powtarzasz, a następnie przetestuj cały zestaw.

Zaplanuj całą pamięć żądania

Dopasowanie pamięci zaczyna się od trzech przydziałów. Wagi modelu przechowują wyuczone parametry. Cache klucz-wartość, czyli KV cache, zachowuje dane uwagi używane podczas wnioskowania. Bufory środowiska i inne programy zużywają pozostałe miejsce.

Required memory = resident weights + context cache + runtime allowance
Available memory = physical capacity - operating system and application reserve

Kwantyzacja zmniejsza precyzję przechowywania wag modelu. Niższa precyzja zmniejsza wymagania pamięciowe, a jakość zależy od modelu i wybranej wersji kwantyzowanej. Precyzja cache jest osobnym ustawieniem. Plik wag Q4 nie oznacza czterobitowego cache.

W przybliżonym przykładzie dotyczącym samych wag 27 miliardów parametrów przy 16 bitach wymaga około 50,3 GiB. Osiem bitów daje około 25,1 GiB, a cztery bity około 12,6 GiB. Opublikowane rozmiary plików uwzględniają także metadane, pakowanie i mieszaną precyzję, dlatego do planowania wdrożenia używaj konkretnych plików.

Karta modelu Qwen3.8-27B i karta modelu GLM-5.3 opisują różne architektury. Model mixture-of-experts aktywuje dla każdego tokena tylko część parametrów, ale pozostałe wagi nadal wymagają przechowywania. Offloading zmienia rozmieszczenie i opóźnienie, lecz nie usuwa wag.

Zacznij od opublikowanych plików

Rozmiar pobierania daje konkretniejszy punkt wyjścia niż liczba parametrów. Opublikowane przez Unsloth wersje Qwen i GLM pokazują, jak wybór kwantyzacji zmienia wymagania magazynowania.

Wersja kwantyzowana Opublikowany rozmiar, dziesiętne GB Przybliżone GiB
Qwen3.8 27B Q4_0 16.1 15.0
Qwen3.8 27B Q8_0 29.0 27.0
GLM-5.3 UD-Q4_K_XL 467 434.9
GLM-5.3 UD-IQ2_M 239 222.6

Źródła plików: Qwen Q4_0 , Qwen Q8_0 , fragmenty GLM UD-Q4_K_XL oraz fragmenty GLM UD-IQ2_M . Wartości to zaokrąglone zestawienia sprawdzone 6 października 2026 roku. Konwersja GiB dzieli bajty dziesiętne przez 2³⁰.

Są to rozmiary plików wag, a nie całkowite pomiary pamięci rezydentnej. Sposób ładowania, cache, bufory tymczasowe i dodatkowe składniki modelu wpływają na działający proces. Nie porównuj pliku 29 GB bezpośrednio z przydziałem 30 GiB bez konwersji jednostek.

Kontekst zmienia dopasowanie

Cache uwagi Qwen daje przykład obliczeniowy. Jego opublikowana konfiguracja określa 64 warstwy, pełną uwagę w co czwartej warstwie, cztery głowy klucz-wartość i wymiar głowy 256.

Full-attention KV bytes per token:
16 layers × 4 KV heads × 256 dimensions × 2 (K and V) × 2 bytes
= 65,536 bytes

8,192 tokens  = 0.5 GiB
32,768 tokens = 2.0 GiB

Ten obliczony składnik cache zakłada 16-bitowe klucze i wartości dla jednej sekwencji. Nie obejmuje stanu uwagi liniowej, buforów środowiska, narzutu alokatora ani opcjonalnych składników wizji lub dekodowania spekulatywnego. Te alokacje także wymagają rezerwy.

W przykładowym budżecie planistycznym dodaj 3–5 GiB na pozostałe alokacje do zaokrąglonych rozmiarów wag. To założenie zastąp pomiarami z wybranego środowiska uruchomieniowego.

Wersja i kontekst Obliczony zakres planowania
Qwen Q4_0, 8K 18.5–20.5 GiB
Qwen Q8_0, 8K 30.5–32.5 GiB
Qwen Q8_0, 32K 32.0–34.0 GiB

Użyteczny przydział 30 GiB zostawia dużo miejsca dla przykładu Q4, a scenariusze Q8 przekraczają ten limit według założeń. Mniejsza zmierzona rezerwa zmienia granicę. Dlatego udany krótki prompt nie dowodzi wystarczającej pojemności dla długiej sesji programistycznej.

Równoległe żądania dodają kolejny wymiar. Ollama opisuje wzrost pamięci kontekstu przy równoległych żądaniach oraz osobne ustawienia precyzji cache. Cache Q8 zużywa około połowy pamięci cache F16, a Q4 około jednej czwartej. Oba ustawienia mają zależne od modelu kompromisy jakościowe. Zobacz FAQ środowiska Ollama .

Dopasuj sprzęt do przydziału

RTX 5090 oferuje 32 GB dedykowanej pamięci graficznej. DGX Spark ze 128 GB używa pamięci współdzielonej. Artificial Analysis dokumentuje obie konfiguracje w wynikach sprzętowych. Większa pojemność pozwala na większe przydziały, lecz sama pojemność nie określa szybkości obsługi.

Scenariusz sprzętowy Praktyczne znaczenie
RTX 5090, 32 GB Qwen Q4 zostawia więcej miejsca na kontekst niż Q8
DGX Spark, 128 GB Miejsce na obie wersje Qwen, lecz nadal potrzebny jest narzut środowiska
Mac Studio, 256 GB Większe zestawy wag są kandydatami, zależnie od środowiska i limitów przydziału

GLM UD-Q4_K_XL przekracza wszystkie trzy pojemności przed dodaniem cache. Zestaw wag IQ2 o rozmiarze około 222,6 GiB przekracza także system 128 GB. Na Macu 256 GB wykonalność zależy od pamięci dostępnej dla GPU i pozostałego narzutu. Specyfikacje Apple określają opcje sprzętowe, a nie gwarantowany przydział dla wnioskowania.

Hipotetyczny użyteczny budżet 240 GiB zostawia około 17,4 GiB po załadowaniu wag IQ2. Budżet 192 GiB nie mieści samych wag. Żaden z tych budżetów nie określa domyślnych ustawień systemu, obsługi skompresowanego cache, użytecznej przepustowości ani akceptowalnej jakości IQ2. Przed zakupem sprzętu dla tego obciążenia wymagaj sprawdzonej konfiguracji środowiska.

Szybkość to osobny wynik

Lokalny test wnioskowania Artificial Analysis odtwarza zarejestrowane obciążenie obejmujące 168 tur modelu. Wyniki laptopów i stacji roboczych podają poniższe czasy dla testowanych konfiguracji Qwen3.8 27B.

System Czas odtworzenia obsługi
DGX Spark, 128 GB 24.2 minuty
RTX 5090 4.9 minuty
Mac Studio, 256 GB Brak wyniku w tym porównaniu

Wynik RTX wymaga około jednej piątej czasu Sparka. Konfiguracja obsługi ma znaczenie, dlatego nie jest to uniwersalny stosunek sprzętowy. Testowane wersje obsługi różnią się także od przykładów planowania GGUF powyżej.

Czas odtworzenia pomija wykonanie narzędzi i wymusza zarejestrowane długości odpowiedzi. Nie ocenia, czy wygenerowane odpowiedzi rozwiązują pierwotne zadanie. Pomiar MacBooka nie określa także wydajności Mac Studio.

Przekazuj agentowi informacje zwrotne

System wykonywania agenta dostarcza narzędzia, kontekst, pętlę działań i weryfikację. Model zapisuje lub wybiera działania wewnątrz tego systemu. Przy eksporcie CSV przydatne możliwości obejmują odczyt plików projektu, zmianę kodu, uruchamianie testów i odbieranie wynikających z nich błędów.

Rozważ przykładowe zadanie eksportu, a nie zmierzony eksperyment. Agent tworzy funkcję pobierania, ale używa nieprawidłowego formatu daty. Przegląd wizualny pomija problem. Test otwiera wyeksportowany plik i porównuje daty z wymaganym formatem. Agent otrzymuje błąd, zmienia formatter i ponownie uruchamia kontrolę.

Brakujący składnik Prawdopodobna porażka
Odpowiedni kontekst Zmiana niepowiązanego pliku
Narzędzia wykonawcze Opisanie poprawki bez jej zastosowania
Krok weryfikacji Zatrzymanie się po wiarygodnie wyglądającym kodzie
Informacja o błędzie Powtarzanie nieudanego podejścia

Raport LangChain opisuje zmianę z 52,8% do 66,5% w Terminal Bench 2.0 przy stałym GPT-5.2-Codex. Raport o inżynierii agentów opisuje wskazówki weryfikacji, kontekst środowiska, wykrywanie powtarzanych edycji i zmiany budżetu rozumowania.

To dowód zgłoszony przez dostawcę, a nie dowód, że mały model lokalny dorównuje modelowi czołowemu. Wspiera węższy wniosek: sam wybór modelu nie wyjaśnia wyników agentów. LangChain zgłasza także gorsze wyniki przy stałym maksymalnym rozumowaniu z powodu limitów czasu.

Dopasuj kontrole do pracy

Zakończona kontrola ustanawia tylko zakres objęty kontrolą. Test CSV sprawdzający nazwy kolumn nie obejmuje formatowania dat, cudzysłowów, Unicode ani kontroli dostępu. Zdefiniuj oczekiwany wynik przed wyborem sposobu weryfikacji.

Zadanie Przydatny dowód wykonania
Zmiana kodu Odpowiednie testy oraz sprawdzenie wynikowego zachowania
Odpowiedź badawcza Źródła wspierające poszczególne twierdzenia
Rezerwacja lub zwrot Prawidłowy zapisany stan oraz zgodność z odpowiednią polityką
Eksport dokumentu Sparsowany wynik zgodny z wymaganymi polami i formatami

Badanie τ-bench ocenia agentów współpracujących z narzędziami, użytkownikami i regułami domenowymi. Artykuł badawczy porównuje końcowy stan bazy danych z oczekiwanym wynikiem. Pokazuje to, dlaczego płynny tekst potwierdzenia nie wystarcza do kontroli transakcji.

Lokalnie nie znaczy offline

Lokalne wnioskowanie określa miejsce działania modelu. Otaczająca aplikacja nadal określa, gdzie trafiają dokumenty, zapytania wyszukiwania, ślady i wyniki narzędzi. Lokalny model kodujący połączony ze zdalnym wyszukiwaniem lub usługami chmurowymi pozostaje systemem sieciowym.

Ollama stwierdza, że nie otrzymuje promptów ani odpowiedzi przy lokalnym wykonaniu, oraz opisuje wyłączanie funkcji chmurowych. To stwierdzenie zależne od środowiska, a nie gwarancja prywatności dla każdego połączonego agenta. Zweryfikuj punkt końcowy modelu i każdą integrację w dokumentacji środowiska .

Ścieżka danych Co sprawdzić
Punkt końcowy wnioskowania Proces lokalny, serwer zdalny lub automatyczny fallback
Wyszukiwanie i pobieranie Zewnętrznie wysyłane zapytania i fragmenty dokumentów
Połączenia narzędzi Pliki i rekordy udostępniane każdej usłudze
Logi i ślady Miejsce przechowywania, zachowana treść i dostęp

Hybrydowy przepływ pracy potrzebuje jawnej reguły przekazania. Na przykład utrzymaj ekstrakcję prywatnych dokumentów lokalnie, a następnie wyślij do hostowanej analizy tylko zatwierdzone wyniki zbiorcze. Sprawdź dokładnie wysyłany materiał. Podsumowanie nadal zawiera wrażliwe informacje, jeśli zachowuje nazwiska, dane klientów lub poufne ustalenia.

Przetestuj przed zakupem

Wybierz powtarzalne zadanie z jasnym warunkiem zakończenia. Porównaj lokalną konfigurację z używanym produktem hostowanym, razem z jego narzędziami. Przekaż obu stronom te same dane wejściowe i kryteria akceptacji, a następnie powtórz zadanie na kilku reprezentatywnych przykładach.

  1. Zapisz konfigurację: dokładny plik modelu, kwantyzację, wersję backendu, limit kontekstu i ustawienie rozumowania.
  2. Zdefiniuj sukces: oczekiwany artefakt, wymagane zachowanie i zabronione skutki uboczne.
  3. Zmierz wykonanie: czas, zaliczone kontrole, nieudane próby i ręczne naprawy.
  4. Uwzględnij koszt posiadania: sprzęt, prąd, opłaty API, utrzymanie i twój czas.
  5. Sklasyfikuj błędy: błędy rozumowania, limity pamięci, opóźnienie, brak kontekstu lub brak weryfikacji.

Lokalne wnioskowanie pasuje do pracy, której oceniona jakość i opóźnienie spełniają wymagania. Model hostowany nadal jest użyteczny, gdy dodatkowe możliwości zmniejszają liczbę błędów lub nakład przeglądu. Hybrydowy przepływ przydziela różne zadania obu stronom po określeniu danych, które mogą opuścić komputer.

Oblicz koszt zaakceptowanego wyniku

Czas naprawy przez człowieka często zmienia ekonomikę. Szybka lokalna odpowiedź wymagająca dziesięciu minut korekty zużywa więcej czasu pracy niż wolniejsza odpowiedź przechodząca przegląd. Licz zaakceptowane wyniki razem z kosztem wnioskowania.

Cost per accepted task =
(hardware allocation + electricity + service fees + maintenance + review time)
÷ accepted tasks

Przykładowy koszt przeglądu: przy założeniu 30 USD za godzinę osiem minut korekty kosztuje 4 USD na zadanie. Sto takich zadań zużywa 400 USD czasu przeglądu. To przykłady arytmetyczne, a nie zmierzone wskaźniki porażek lokalnego modelu.

Porównuj równoważne wyniki. Uwzględnij odrzucone próby w czasie i koszcie. Dla własnego sprzętu rozłóż cenę zakupu na realistyczny okres użytkowania i liczbę zadań. Dla usługi hostowanej uwzględnij subskrypcję lub koszt API oraz wymagany przegląd.

Szczegóły sprzętu znajdziesz w przewodniku po lokalnych modelach, GPU i kontekście . Informacje o pojemności i cenie znajdziesz w porównaniu pamięci DGX Spark . Na podstawie wyników zadań wybierz najmniejszą konfigurację spełniającą wymagania jakości, szybkości i danych.

Film referencyjny

Źródła