Model do kodu, który zostaje u Ciebie (2026)

30,5 mld parametrów w sumie. 3,3 mld aktywnych na token. 256 K natywnego kontekstu (model card Qwen). Około 16 GB VRAM przy kwantyzacji AWQ 4-bit. Apache 2.0. Tyle zmieniło się w ciągu dwunastu miesięcy i tyle wystarczy, żeby piętnastoosobowy polski fintech, warszawski software house czy kancelaria mogli w kwietniu 2026 uruchomić sensownego własnego asystenta kodu na jednym workstation z kartą NVIDIA RTX PRO 5000 Blackwell 48 GB - bez pytania nikogo o zgodę.

Dla kogo ten tekst: dla zespołu pracującego dla banku spółdzielczego, który właśnie przysłał ankietę outsourcingową powołującą się na Rekomendację D. Dla dostawcy piszącego integrację KSeF albo e-Doręczeń dla klienta z sektora publicznego. Dla radcy, który chce zbudować wewnętrzne RAG na aktach, ale nie wypuści ich do amerykańskiej chmury. Każdy z nich odpowiada na to samo pytanie: co faktycznie możemy postawić u siebie, dziś, co jest wystarczająco dobre?

Teza tego tekstu jest wąska: Qwen3-Coder-30B-A3B to pierwszy open-weights model kodujący klasy 2026, w którym 48-gigabajtowy workstation plus licencja Apache 2.0 plus inferencja on-prem dają małemu regulowanemu MŚP wiarygodną wewnętrzną alternatywę dla Cursora czy Copilota. Wszystko poniżej jest dowodem na to twierdzenie - razem z uczciwą listą zastrzeżeń.

W skrócie. Qwen3-Coder-30B-A3B ma 30,5 mld parametrów, z czego 3,3 mld aktywnych na token, 256 K kontekstu i licencję Apache 2.0, a w kwantyzacji AWQ 4-bit potrzebuje około 16 GB VRAM. Mieści się na jednej stacji roboczej z kartą 48 GB i jest wiarygodną wewnętrzną alternatywą dla Cursora czy Copilota w małym regulowanym MŚP, z opisanymi ograniczeniami wobec modeli frontier.

Stan na kwiecień 2026; aktualizacja pomiarów w przygotowaniu.

Dlaczego MoE przestawia arytmetykę sprzętu

Przez ostatnie dwa lata „30-miliardowy model kodujący" oznaczał gęsty transformer 30 B, a gęste 30 B w AWQ 4-bit oznaczało jakieś 18 GB samych wag plus KV cache rosnący z długością kontekstu i rozmiarem batcha. Na karcie 48 GB zostawało Ci może 8–12 K użytecznego kontekstu roboczego, zanim throughput siadał. Wystarczające do demo z autouzupełnianiem. Niewystarczające do agentowych edycji w prawdziwym repo.

Mixture-of-Experts przepisuje tę arytmetykę. Qwen3-Coder-30B-A3B to MoE z 30,5 mld parametrów, 128 ekspertami i 8 routowanymi na token - koszt obliczeniowy per token wyznaczają aktywne 3,3 mld, a nie łączne 30,5 mld (model card na Hugging Face). W trakcie inferencji model zachowuje się - pod względem kompute - jak model 3 B. Wciąż płacisz pełen narzut VRAM, bo 128 ekspertów musi siedzieć w pamięci, ale FLOP-y per token i tempo rośnięcia KV cache są jak w znacznie mniejszym modelu. O to właśnie chodzi w MoE przy lokalnej inferencji: zachować wyuczoną pojemność modelu 30 B, płacąc za token tyle, co za 3 B.

Konkretnie: na pojedynczej karcie klasy Blackwell 48 GB z vLLM, AWQ-Marlin i chunked prefill obserwujemy 45–60 tok/s przy 64 K kontekstu roboczego i batchu 1 - mniej więcej 16 GB na wagi, 14–18 GB na KV cache przy tym kontekście, reszta na aktywacje i narzut CUDA. To nie prognoza. Tak po prostu działa maszyna.

Krótka lista na kwiecień 2026

Trzy open-weights modele kodujące warto dziś trzymać na krótkiej liście. Liczby poniżej pochodzą ze źródeł pierwotnych; tam, gdzie komórka jest ostrożna, to dlatego, że wynik na leaderboardzie jest self-reportem vendora, jeszcze nie odtworzonym niezależnie.

Dwa uczciwe zastrzeżenia do tabeli. Po pierwsze, 69,6% Qwena na SWE-bench Verified to self-report i liczba zbiorcza z rodziny ogłoszenia Qwen3-Coder - niezależna ewaluacja może dać inny wynik. Po drugie, wiersz Qwen 2.5 Coder 32B jest tu jako „to, co wdrożyłbyś sześć miesięcy temu" - wciąż działa, ale na SWE-bench Verified następca MoE zostawia go daleko w tyle, i to przy mniejszym koszcie per token. Skok generacyjny jest realny.

Devstral Small 1.1 to hedge. 24 B dense, Apache 2.0, 128 K kontekstu, 53,6% na SWE-bench Verified - i co ważniejsze od samej liczby, powstał we współpracy Mistral AI z All Hands AI, zespołem stojącym za OpenHands (model card na Hugging Face). Jeśli zależy Ci na agentowym tool-use w frameworku z realnym przebiegiem, Devstral nie jest nagrodą pocieszenia. To inny zakład, z własnym rodowodem.

vLLM, który naprawdę wstaje

Poniżej komenda, którą trzymamy w produkcji na pojedynczym 48-gigabajtowym Blackwellu dla agenta dev w SADP. Komentarze inline.

# /etc/systemd/system/sadp-coder.service (ExecStart)
vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct-AWQ \
  --host 0.0.0.0 --port 8000 \
  --served-model-name qwen3-coder-30b-a3b \
  \
  # AWQ-Marlin to fused kernel; zwykłe awq jest ~30% wolniejsze na Blackwellu.
  --quantization awq_marlin \
  --dtype float16 \
  \
  # 0.90 zostawia zapas na aktywacje + CUDA workspace na karcie 48 GB.
  # 0.93 tylko jeśli OS jest headless i nic więcej nie dzieli GPU.
  --gpu-memory-utilization 0.90 \
  \
  # 64 K kontekstu roboczego to sweet spot: KV cache mieści się przy batchu
  # 1-2, obejmuje sensowny prompt review'u repo i nie zabija throughputu.
  # Model wspiera 262144 natywnie, ale nie masz na to VRAM-u.
  --max-model-len 65536 \
  \
  # Chunked prefill trzyma TTFT przy długich promptach w ryzach i pozwala
  # decode'owi jechać równolegle z prefillem następnego requesta. Domyślnie
  # włączone w nowszym vLLM, tu explicite dla audytowalności.
  --enable-chunked-prefill \
  --max-num-batched-tokens 8192 \
  \
  # Prefix caching to największa pojedyncza wygrana na workloadzie agentowym,
  # gdzie system prompt + mapa repo powtarzają się między turami.
  --enable-prefix-caching \
  \
  # Dwa równoległe requesty to realizm dla trzyosobowego zespołu dzielącego
  # jeden workstation. Podbijaj tylko jeśli zmierzyłeś zapas KV.
  --max-num-seqs 2 \
  \
  # Speculative decoding z draft modelem 0.5 B Qwena daje ~1.4x throughputu
  # decode'a na tym workloadzie. Opcjonalnie; usuń jeśli draft OOM-uje.
  --speculative-model Qwen/Qwen2.5-Coder-0.5B-Instruct \
  --num-speculative-tokens 4

Trzy flagi, które regularnie robią problemy i zasługują na notkę. --gpu-memory-utilization jest największą pułapką: vLLM prealokuje KV cache pod ten budżet przy starcie, więc „wczoraj działało, dziś OOM-uje" zwykle oznacza, że ktoś zmienił --max-model-len i nie przebalansował reszty. --enable-prefix-caching zwraca koszt pamięci w momencie, gdy agenci zaczynają reużywać prefiksu z mapą repo między turami. A --speculative-model ma sens tylko gdy tokenizer draft-modelu zgadza się z targetem; Qwen-na-Qwenie jest OK, między rodzinami - nie.

Gdzie Qwen3-Coder-30B-A3B jest realnie słabszy od frontier

Uczciwa część. Trzy rzeczy, w których 30B-A3B na Twoim workstation nie dorówna Claude Sonnet 4 ani modelowi klasy GPT-5.

Spójność patchy przez wiele plików w skali repo. W bazach kodu powyżej ~50 K LOC, gdzie sensowna edycja dotyka sześciu plików w czterech pakietach i musi trzymać się konwencji architektonicznej, która jest tylko implicit w istniejącym kodzie, zamknięte modele frontier wciąż wygrywają. Były RL-trenowane na znacznie dłuższych trajektoriach agentowych z budżetem kompute, którego nie odtworzysz lokalnie. Lokalne 30B-A3B zrobi trzy pierwsze pliki dobrze i po cichu zgubi wątek w czwartym. Zauważysz to w review PR-ów, nie w benchmarku.

Długi horyzont tool-use. „Odpal failing test, przeczytaj trace, znajdź flaky dependency, zpatchuj, odpal ponownie, potwierdź, zakomituj" to łańcuch 20–40 wywołań. Frontier modele były post-trenowane właśnie na tym rozkładzie, przy skali niedostępnej lokalnie. Open-weights nadrabiają szybko, ale jeszcze tam nie są - i luka jest największa na taskach wymagających recovery po błędzie w środku łańcucha.

Rzadsze języki spoza mixu treningowego. Jeśli Twoja baza kodu to 80% Elixira, 80% OCamla albo migracja Cobola do Javy, benchmarki na Pythonie/TypeScripcie/Javie/Go nie przewidują Twojego doświadczenia. To prawda dla każdego modelu, ale asymetria mixu treningowego boli open-weights mocniej - bo nie zapłacisz OpenAI za poszerzenie mixu pod siebie.

Żadne z tego nie jest fatalne. Wszystkie są realne.

Dlaczego on-prem 30 B i tak wygrywa u małego regulowanego klienta

Przy tej uczciwej liście pytanie pisze się samo: czemu nie wziąć po prostu Claude'a albo GPT-5 przez API enterprise z DPA? Cztery powody - i dla polskiego małego MŚP pierwsze dwa pojawiają się w rozmowie wcześniej niż warstwa unijna (więcej w Sovereign AI - dlaczego teraz).

KNF Rekomendacja D. Jeśli piszesz kod dla kogokolwiek pod nadzorem KNF - banku, ubezpieczyciela, SKOK-u, banku spółdzielczego, fintechu płatniczego - ankieta outsourcingowa klienta pyta, gdzie się kręci AI, czyje są wagi i co się dzieje przy wyjściu z umowy. „Nasz dostawca korzysta z OpenAI na unijnym DPA" to odpowiedź, która generuje kolejne pytania. „Model jedzie na naszym sprzęcie, w naszym LAN-ie, wagi są pinowane hashem przy deployu, logi trzymane w naszej schemie" - to odpowiedź, która kończy wymianę. To drugie zdanie jest dostępne tylko wtedy, gdy wagi siedzą na Twoim GPU.

UODO / RODO, art. 28. Każdy fragment kodu, który cytuje produkcyjny log, schemę z danymi osobowymi, stack trace z adresem e-mail - wysłany do chmurowego LLM - tworzy relację powierzenia z art. 28, którą musisz papierować. Inferencja on-prem zwija powierzchnię compliance do jednego administratora i zera procesorów. Dla dwudziestoosobowej firmy koszt nie-negocjowania kolejnej umowy powierzenia z amerykańskim dostawcą LLM liczy się tygodniami pracy kancelarii.

Art. 28 DORA + art. 12 AI Act. Nad regulatorem krajowym siedzi warstwa unijna. Podmioty w zakresie DORA muszą udokumentować kontraktowe prawa wyjścia, transparentność podwykonawców i rejestr ryzyka ICT obejmujący inferencję stron trzecich; systemy AI wysokiego ryzyka w rozumieniu AI Act muszą logować kto/co/kiedy/w czyim imieniu każdej inferencji w sposób, który przetrwa ocenę zgodności. Chmurowy endpoint daje Ci dashboard użycia; własny vLLM za własnym gatewayem daje Ci surową parę request/response i deterministyczny hash szablonu promptu. Zgadnij, o które z tych dwojga pyta audytor.

Wymiana, którą faktycznie robisz. Oddajesz część zdolności modeli frontier w zamian za zero egress, przewidywalny koszt, audytowalną inferencję i powierzchnię łańcucha dostaw kończącą się na Twojej szafie. Dla software house'u piszącego integrację KSeF lub e-Doręczeń, dla fintechu kodującego autoryzację płatności, dla kancelarii pracującej pod tajemnicą adwokacką - ta wymiana jest błędem zaokrąglenia po stronie strat i otwieraczem drzwi w każdej rozmowie zakupowej. Klient - albo klient Twojego klienta - już pyta, niezależnie od tego, czy procurement to spisał.

Zmiana 2026 polega na tym, że luka zdolności zmalała na tyle, by tę wymianę zrobić. Gdy luka była duża, nie mogłeś jej zrobić z czystym sumieniem. Teraz możesz - i Twój audytor Ci podziękuje.

Hedge Devstral Small

Ostatnia rzecz. Nie wdrażaj stacka jednego dostawcy, nawet jeśli dostawca daje Apache 2.0. Ryzyko licencji wag jest realne - to nie ryzyko procesowe, to ryzyko typu „Qwen3 wstrzymał aktualizacje na osiem tygodni, a mamy otwarty incydent u klienta". Devstral Small 1.1 jest hedgem wartym wymienienia: 24 B dense, Apache 2.0, 128 K kontekstu, rodowód tool-callingu z OpenHands - i na tyle inny w mixie treningowym, że jego failure mode nie koreluje z Qwenowym. Trzymaj go ciepłego na drugiej maszynie albo w drugim kontenerze na tej samej. Stack inferencji regulowanego MŚP z dokładnie jednym dostawcą wag nie jest stackiem suwerennym. To jest single point of failure z permissive licencją.

Taki stack prowadzę dla SADP. Dane nie opuszczają budynku; model też nie. Jeśli to jest ten 2026, pod który się przygotowujesz - czy piszesz kod dla klienta pod KNF, integrację pod KSeF, czy po prostu chcesz, żeby naciśnięcia klawiszy Twoich deweloperów przestały trafiać do amerykańskiej chmury - pogadajmy.