Lokalny asystent AI do kodu działa jak chmurowe asystenty programisty – podpowiada kod, odpowiada na pytania o repozytorium, pomaga w refaktoryzacji – ale kod źródłowy nie opuszcza Twojej infrastruktury. Wyjaśniamy, które otwarte modele się do tego nadają, jak połączyć je z IDE i ile sprzętu potrzeba dla zespołu 10, 50 i 200 programistów.
Asystenci AI do programowania stali się codziennym narzędziem w wielu zespołach. Problem w tym, że każda podpowiedź kodu i każde pytanie o funkcję oznaczają wysłanie fragmentu kodu do zewnętrznego dostawcy. Dla software house’u pracującego na kodzie klientów, firmy finansowej albo producenta z własnym know-how to często nie do przyjęcia. Lokalny asystent AI do kodu na własnym GPU rozwiązuje ten problem, ale wymaga przemyślenia modelu, architektury i sprzętu. Opisujemy wszystkie trzy elementy.
Dlaczego kod źródłowy nie powinien wychodzić poza firmę
Kod to często najcenniejszy zasób firmy technologicznej. Powodów, żeby go nie wysyłać na zewnątrz, jest kilka:
- Własność intelektualna. Algorytmy, logika biznesowa i architektura systemu to przewaga konkurencyjna. Nawet jeśli dostawca deklaruje, że nie trenuje na Twoich danych, kod fizycznie trafia na jego serwery.
- Umowy z klientami i NDA. Software house’y często pracują na kodzie, do którego prawa ma klient. Umowa może wprost zabraniać przekazywania go podmiotom trzecim – a dostawca chmurowego asystenta jest takim podmiotem.
- Regulacje. W sektorze finansowym (DORA), u podmiotów objętych NIS2 i w administracji publicznej korzystanie z zewnętrznych usług przetwarzających kod i dane wymaga oceny ryzyka dostawcy, umów i dokumentacji. Własna infrastruktura w Polsce znacząco to upraszcza.
- Sekrety w kodzie. Mimo dobrych praktyk w repozytoriach zdarzają się klucze API, hasła w plikach konfiguracyjnych czy dane testowe z produkcji. Asystent wysyła kontekst automatycznie, często bez świadomej decyzji programisty.
- Kontrola nad retencją. Przy usłudze zewnętrznej o czasie przechowywania zapytań i logów decyduje dostawca i jego regulamin, który może się zmienić.
Szerzej o ryzykach wysyłania danych do publicznych modeli piszemy w artykule Wdrożenie lokalnych modeli LLM w firmie: jak uniknąć wycieku danych.
Otwarte modele do programowania (stan na listopad 2026)
Rynek otwartych modeli zmienia się co miesiąc, więc poniższa lista to stan na listopad 2026. Nie podajemy wyników benchmarków: jakość na Twoim kodzie, w Twoich językach i frameworkach trzeba sprawdzić w pilotażu. Kolumna z pamięcią to przybliżony rozmiar samych wag, bez KV cache i narzutu.
| Model | Parametry | Licencja | Wagi (ok.) | Rola w zespole |
|---|---|---|---|---|
| Devstral Small 2 (24B) | 24B, model do kodu | Apache 2.0 | 24 GB w FP8, 12 GB w 4-bit | dobry punkt startu; mieści się na jednym GPU z zapasem na wielu użytkowników |
| Devstral 2 (123B) | ok. 125B, model do kodu | własna licencja Mistral – sprawdź warunki komercyjne | 125 GB w FP8, 63 GB w 4-bit | większy model do kodu na serwer z kilkoma GPU |
| Kimi K2.7-Code | ok. 1,03T, model do kodu | zmodyfikowana MIT – przeczytaj dodatkowe warunki | ok. 1 TB w FP8, ok. 515 GB w 4-bit | największy z listy; wymaga serwera klasy HGX |
| Qwen3.8-27B | 27,8B, multimodalny | Apache 2.0 | 28 GB w FP8, 14 GB w 4-bit | uniwersalny model ogólny; rozumie też obraz, np. zrzuty ekranu |
| Qwen3.8-Flash-Next | 180B | Qwen Community License (własna) | 180 GB w FP8, 90 GB w 4-bit | większy model ogólny z rodziny Qwen |
| gpt-oss-120b / gpt-oss-20b | 117B / 21B | Apache 2.0 | ok. 59 GB / 11 GB w 4-bit | modele ogólne OpenAI z licencją bez ograniczeń komercyjnych; 20b dla mniejszego sprzętu |
Dwie praktyczne uwagi. Po pierwsze, licencja: Apache 2.0 pozwala na użytek komercyjny bez dodatkowych warunków, licencje własne trzeba przeczytać przed wdrożeniem. Po drugie, nie musisz wybierać jednego modelu. Typowa konfiguracja to większy model do czatu i trybu agenta oraz mniejszy, szybki model do autouzupełniania. Jak policzyć pamięć z uwzględnieniem kontekstu, pokazujemy w artykule Ile VRAM potrzebuje model LLM.
Lokalny asystent AI do kodu: architektura
Rozwiązanie składa się z trzech warstw, z których każdą da się wymienić niezależnie:
- Serwer inferencji z API zgodnym z OpenAI. W produkcji zwykle vLLM lub SGLang, które obsługują wielu użytkowników naraz. Różnice między serwerami opisujemy w artykule Ollama, vLLM, SGLang czy NVIDIA NIM.
- Bramka API. Uwierzytelnianie przez SSO lub osobne klucze dla programistów, limity, kierowanie zapytań do właściwego modelu i logi metadanych bez treści kodu.
- Rozszerzenia IDE obsługujące własny endpoint zgodny z API OpenAI. Przykładem otwartego narzędzia jest Continue (VS Code i JetBrains), w którym wskazuje się adres własnego serwera, oraz Cline dla VS Code. Programista pracuje w swoim edytorze, a zapytania trafiają do Twojej serwerowni.
Opcjonalnie dochodzi indeks repozytorium: model embeddingów uruchomiony na tym samym serwerze i baza wektorowa, dzięki którym asystent znajduje właściwe fragmenty kodu w dużym projekcie.
Czat, agent i autouzupełnianie to różne obciążenia
- Autouzupełnianie wysyła krótkie zapytania bardzo często, przy każdej pauzie w pisaniu. Liczy się czas odpowiedzi: podpowiedź, która przychodzi za późno, jest bezużyteczna. Potrzebny jest mały, szybki model, który obsługuje tryb FIM (fill-in-the-middle) – sprawdź to w karcie modelu.
- Czat to pytania o kod, wyjaśnienia, generowanie testów. Średnia długość kontekstu, akceptowalne kilka sekund oczekiwania.
- Tryb agenta to wieloetapowe zadania: model czyta wiele plików, proponuje zmiany, uruchamia polecenia. Konteksty są długie, a KV cache rośnie najbardziej. Tu przydaje się największy model, na jaki pozwala sprzęt.
Bezpieczeństwo w praktyce
Serwer dostępny tylko z sieci firmowej lub przez VPN, logowanie metadanych zamiast treści zapytań, wykluczenie plików z sekretami z kontekstu wysyłanego przez rozszerzenie i regularne aktualizacje serwera inferencji. To te same zasady, które stosujemy przy każdym produkcyjnym wdrożeniu LLM.
Ile sprzętu potrzeba dla zespołu 10, 50 i 200 programistów
Najczęstszy błąd przy wymiarowaniu to liczenie „GPU na programistę”. O sprzęcie decyduje liczba równoczesnych zapytań i długość ich kontekstu, a nie liczba osób w zespole. Programista nie odpytuje modelu cały czas. Za to jeden agent pracujący na dużym repozytorium potrafi zająć więcej pamięci KV cache niż kilka osób korzystających z czatu. Dlatego poniższa tabela to punkt wyjścia, który weryfikujemy pomiarem w pilotażu.
| Zespół | Charakter ruchu | Proponowany sprzęt | Przykładowa konfiguracja modeli |
|---|---|---|---|
| 10 programistów | kilka równoczesnych zapytań, krótkie szczyty | DGX Spark, VPS z GPU lub gotowy pakiet GPU (np. A40 48 GB), ewentualnie serwer z 1× RTX PRO 6000 | Devstral Small 2 lub gpt-oss-20b w kwantyzacji; na DGX Spark także gpt-oss-120b lub Devstral 2 w 4-bit, kosztem szybkości generowania |
| 50 programistów | dziesiątki zapytań w szczycie, stały ruch z autouzupełniania | serwer z 2–4 GPU RTX PRO 6000 (96 GB każdy) | Devstral 2 lub gpt-oss-120b do czatu i agentów, mały model do autouzupełniania na osobnym GPU |
| 200 programistów | ciągły ruch, wiele długich kontekstów agentów jednocześnie | serwer z 8 GPU RTX PRO 6000 albo HGX B200; dla największych modeli HGX B200 lub B300 | kilka replik modelu średniej wielkości albo Kimi K2.7-Code (ok. 1 TB wag w FP8) na HGX B200 z niewielkim zapasem na KV cache lub na HGX B300 z większym |
Kilka uwag do tabeli. DGX Spark ma 128 GB pamięci zunifikowanej, więc zmieści nawet duże modele, ale jego przepustowość pamięci (273 GB/s) jest znacznie niższa niż w GPU z pamięcią HBM. Sprawdzi się w małym zespole i na etapie pilotażu, nie przy dziesiątkach równoczesnych użytkowników – więcej w artykule NVIDIA DGX Spark jako usługa. Na start możesz też skorzystać z gotowych pakietów GPU, na których uruchomimy dowolny otwarty model, nie tylko DeepSeek. Przy 200 osobach zwykle lepiej mieć kilka replik modelu średniej wielkości niż jedną instancję największego – awaria lub aktualizacja jednej repliki nie zatrzymuje wtedy całego zespołu. Pełną drabinę sprzętu od prototypu do produkcji opisujemy w artykule DGX Spark, RTX PRO 6000 czy HGX B200.
Jak wdrożyć asystenta: od pilotażu do całego zespołu
- Pilotaż na 5–10 osobach. Mniejszy sprzęt, dwa lub trzy modele do porównania, zadania z prawdziwych projektów.
- Pomiar. Bramka API zbiera dane o liczbie równoczesnych zapytań, długości kontekstu, czasie odpowiedzi i wykorzystaniu poszczególnych trybów. To podstawa doboru docelowego sprzętu.
- Ocena jakości. Programiści oceniają odpowiedzi na swoim kodzie. Ta opinia jest więcej warta niż ogólne rankingi.
- Wybór modelu i sprzętu. Na podstawie pomiarów, a nie przeczucia.
- Wdrożenie dla wszystkich. Konfiguracja rozszerzeń IDE, instrukcja dla zespołu, zasady korzystania (np. czego nie wklejać), monitoring.
Ograniczenia, o których warto wiedzieć
Uczciwie: najlepsze komercyjne modele chmurowe w najtrudniejszych zadaniach mogą nadal być mocniejsze od otwartych modeli, które zmieścisz na swoim sprzęcie. Jak duża jest ta różnica w Twoich projektach, warto sprawdzić na własnych przypadkach. Własny asystent to też infrastruktura do utrzymania: aktualizacje modeli i serwera inferencji, monitoring, reagowanie na awarie. Jeśli nie chcesz angażować w to swojego zespołu, utrzymanie możemy przejąć w całości. W zamian dostajesz kontrolę nad kodem, przewidywalny koszt niezależny od liczby tokenów i możliwość dostosowania modelu do własnych standardów.
FAQ: najczęściej zadawane pytania
Czy można uruchomić asystenta AI do kodu lokalnie?
Tak. Otwarty model do kodu uruchamia się na serwerze inferencji z API zgodnym z OpenAI, a programiści łączą się z nim przez rozszerzenia IDE obsługujące własny endpoint, np. Continue. Kod nie opuszcza Twojej infrastruktury.
Jaki model open source jest najlepszy do programowania?
Na listopad 2026 warto przetestować m.in. Devstral Small 2 i Devstral 2, Kimi K2.7-Code, modele Qwen oraz gpt-oss. Najlepszy będzie ten, który dobrze radzi sobie z Twoim kodem i mieści się w Twoim sprzęcie – rozstrzyga to pilotaż.
Ile GPU potrzeba na lokalnego asystenta dla zespołu programistów?
Dla około 10 osób wystarczy DGX Spark lub jedno GPU, dla 50 osób serwer z 2–4 GPU RTX PRO 6000, dla 200 osób serwer z 8 GPU lub HGX B200. Decyduje liczba równoczesnych zapytań i długość kontekstu, więc warto ją zmierzyć w pilotażu.
Czy lokalny asystent AI do kodu działa w VS Code i JetBrains?
Tak, przez rozszerzenia, które pozwalają wskazać własny endpoint zgodny z API OpenAI. Continue działa w obu środowiskach, Cline w VS Code.
Czy lokalny model może podpowiadać kod w trakcie pisania?
Tak, ale do autouzupełniania potrzebny jest mały, szybki model obsługujący tryb FIM i krótki czas odpowiedzi. Zwykle uruchamia się go obok większego modelu do czatu i trybu agenta.
Chcesz dać zespołowi asystenta AI bez wysyłania kodu na zewnątrz? Dobierzemy model i sprzęt, uruchomimy pilotaż i przejmiemy utrzymanie. Zobacz ofertę serwerów GPU albo napisz do nas.