Lokalny asystent AI: Qwen 2.5, Ollama i Docker

Streszczenie

→ Film: RTX 5080 i Qwen 3 — lokalny asystent AI dla program...
→ Dlaczego RTX 5080 i GDDR7? Przepustowość jako nowa miara ...
→ Qwen 3 Coder — dlaczego 8B, a nie większy?
→ Docker + Ollama — konfiguracja od zera

Lokalny asystent AI dla programistów — Qwen 3, Ollama i Docker bez chmury

Slug: agenci-ai/lokalny-asystent-ai-qwen3-cursor-docker

Piszesz kod. Kursor miga. Wklejasz fragment do ChatGPT albo Copilota i czekasz na sugestię. Brzmi znajomo?

To, co w 2024 roku było wygodą, w 2026 stało się poważnym ryzykiem prawnym. Twój kod — logika biznesowa, schematy baz danych, klucze API w komentarzach — ląduje na serwerach w innym kraju. Naruszasz politykę bezpieczeństwa firmy, a często nawet nie wiesz, czy Twój pracodawca ma podpisaną umowę DPA z dostawcą modelu. Jeśli pracujesz z kodem klientów, problem jest podwójny.

Rozwiązanie istnieje i działa już od kilku miesięcy na biurkach programistów w Europie: lokalny asystent AI. Model działa na Twoim sprzęcie, dane nigdy nie opuszczają Twojej sieci, a wydajność potrafi zaskoczyć. W tym artykule zbudujesz kompletne środowisko oparte na modelu Qwen 3 Coder, Ollama, Dockerze i edytorze Cursor — krok po kroku.

Film: RTX 5080 i Qwen 3 — lokalny asystent AI dla programistów

https://youtube.com/watchlwfxoP1h_8

Poniżej pełny tutorial z konfiguracją każdego komponentu.

Dlaczego RTX 5080 i GDDR7? Przepustowość jako nowa miara wydajności AI

Przez lata mówiliśmy o wydajności GPU w teraflopsach. Dla modeli językowych to zła metryka. Ważniejsza jest przepustowość pamięci — jak szybko karta potrafi przesuwać dane między pamięcią VRAM a rdzeniami obliczeniowymi.

RTX 5080 osiąga przepustowość bliską 1 TB/s dzięki pamięci GDDR7. To nie jest przypadkowa liczba. Modele językowe działają w ten sposób, że podczas generowania każdego tokenu muszą odczytać wszystkie wagi sieci z pamięci. Przy modelu 8B w kwantyzacji FP4 to kilka gigabajtów danych — i ten cykl powtarza się dla każdego słowa w odpowiedzi.

GDDR7 vs GDDR6X:

GDDR6X (RTX 4090): ~1 TB/s teoretyczna, ~600-700 GB/s praktyczna
GDDR7 (RTX 5080): blisko 1 TB/s praktycznej przepustowości

Dla użytkownika końcowego różnica jest odczuwalna: szybsze generowanie odpowiedzi, możliwość obsługi większego kontekstu bez spowolnienia.

RTX 5080 ma 16 GB VRAM, co przy rozsądnym doborze modeli wystarczy na komfortową pracę.

Qwen 3 Coder — dlaczego 8B, a nie większy?

Model Qwen 3 Coder 8B Instruct od Alibaba Cloud to celowy wybór, nie kompromis.

Kwantyzacja FP4 (4-bitowa precyzja zmiennoprzecinkowa) redukuje wagę modelu z oryginalnych ~16 GB (FP16) do około 5 GB. To oznacza, że na karcie z 16 GB VRAM układ sił wygląda następująco:

Składnik	Zajętość VRAM
Qwen 3 Coder 8B (FP4) — główny agent	~5 GB
Pomocniczy model autouzupełniania	~1 GB
Bufor na kontekst projektu	~10 GB

Ten bufor to kluczowa kwestia. Kiedy przekazujesz do agenta całe pliki projektu, fragmenty dokumentacji czy logi błędów — to wszystko trafia do kontekstu. 10 GB wolnej pamięci pozwala obsłużyć naprawdę duże okna kontekstowe bez spowolnienia.

Dlaczego nie 32B czy 70B? Modele 32B w kwantyzacji FP4 zajmują ok. 20 GB — nie zmieścisz go na RTX 5080. Modele 70B wymagają wielokartowych konfiguracji. Qwen 3 Coder 8B FP4 to maksimum, które zmieści się na jednej karcie konsumenckiej z marginesem — i wyniki jakościowe są zaskakująco dobre dla kodu.

Jeśli interesuje Cię temat lokalnego AI i wektorowego przeszukiwania kodu, sprawdź artykuł o lokalnym RAG z RTX 5080, ColQwen i LanceDB.

Docker + Ollama — konfiguracja od zera

Używamy Dockera, żeby środowisko było odtwarzalne, izolowane i łatwe do przeniesienia. Ollama obsługuje pobieranie modeli, ich przechowywanie i wystawianie API kompatybilnego z OpenAI.

Struktura plików

ai-dev/
├── Dockerfile
├── entrypoint.sh
└── Modelfile

Dockerfile

Dockerfile
1
2
3
4
5
6
7
8
FROM ollama/ollama:latest

COPY entrypoint.sh /entrypoint.sh
COPY Modelfile /Modelfile

RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh

Ten plik robi całą robotę startową: uruchamia serwer Ollama w tle, pobiera modele i konfiguruje środowisko.

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash

# Uruchom serwer Ollama w tle
ollama serve &
OLLAMA_PID=$!

# Poczekaj aż serwer będzie gotowy
sleep 5

# Ustaw czas utrzymywania modeli w pamięci (24h)
export OLLAMA_KEEP_ALIVE=24h

# Pobierz bazowy model i stwórz niestandardowe modele
ollama pull qwen2.5-coder:7b-instruct

# Stwórz myAgent z własnym Modelfile
ollama create myAgent -f /Modelfile

# Pobierz mały model do autouzupełniania
ollama pull qwen2.5-coder:1.5b-instruct
ollama create myCopilot -f /Modelfile

echo "Silnik gotowy, architektura Blackwell aktywna"

# Przekaż kontrolę do procesu Ollama
wait $OLLAMA_PID

OLLAMA_KEEP_ALIVE=24h to ważna optymalizacja. Domyślnie Ollama zwalnia model z VRAM po 5 minutach bezczynności. Ładowanie wag za każdym razem od nowa zajmuje kilkanaście sekund. Przy ciągłej pracy programistycznej chcesz mieć model zawsze gotowy.

Modelfile

Modelfile definiuje zachowanie modelu — parametry generowania i system prompt:

Dockerfile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
FROM qwen2.5-coder:7b-instruct

# Parametry generowania
PARAMETER temperature 0.1
PARAMETER top_p 0.9
PARAMETER repeat_penalty 1.1
PARAMETER num_ctx 8192

# System prompt — zachowanie agenta
SYSTEM """
Jesteś precyzyjnym asystentem programistycznym. Zawsze:
- Generujesz kompletny, gotowy do uruchomienia kod
- Wyjaśniasz kluczowe decyzje projektowe
- Stosujesz walidację danych wejściowych
- Piszesz czytelne nazwy zmiennych i funkcji
- Sygnalizujesz potencjalne problemy bezpieczeństwa

Odpowiadaj po polsku lub angielsku — w zależności od języka pytania.
"""

temperature 0.1 to celowo niska wartość — chcesz deterministycznego kodu, nie kreatywnych wariacji. num_ctx 8192 to 8 tysięcy tokenów kontekstu, co odpowiada kilku plikom kodu jednocześnie.

Uruchomienie i weryfikacja

Budowanie obrazu

Bash
1
docker build -t programista20 .

Pierwsze budowanie trwa dłużej — Docker pobiera bazowy obraz Ollama i wykonuje entrypoint podczas budowania (pobieranie modeli). Przy kolejnych uruchomieniach modele są już w wolumenie.

Uruchomienie kontenera

Bash
1
2
3
4
5
6
docker run -d \
  --gpus all \
  -p 11434:11434 \
  -v ollama_data:/root/.ollama \
  --name ai-dev \
  programista20

Flagi:

--gpus all — przekazanie wszystkich kart GPU do kontenera (wymaga nvidia-container-toolkit)
-p 11434:11434 — standardowy port Ollama
-v ollama_data:/root/.ollama — wolumin dla modeli (żeby nie pobierać ich przy każdym restarcie)

Weryfikacja

Sprawdź logi kontenera:

Bash
1
docker logs -f ai-dev

Po zakończeniu inicjalizacji zobaczysz:

Silnik gotowy, architektura Blackwell aktywna

Zweryfikuj dostępne modele przez API:

Bash
1
curl localhost:11434/v1/models

Odpowiedź powinna zawierać oba modele:

JSON
1
2
3
4
5
6
7
8
9
10
11
12
{
  "data": [
    {
      "id": "myAgent",
      "object": "model"
    },
    {
      "id": "myCopilot",
      "object": "model"
    }
  ]
}

Jeśli widzisz oba modele — środowisko działa. Możesz też szybko przetestować odpowiedź agenta:

Bash
1
2
3
4
5
6
curl localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "myAgent",
    "messages": [{"role": "user", "content": "Napisz funkcję walidacji emaila w Pythonie"}]
  }'

Integracja z Cursorem — rozszerzenie Continue

Tu pojawia się pierwsza nieoczywista pułapka: wbudowane ustawienia Cursora nie obsługują połączeń z localhost.

Cursor blokuje połączenia do lokalnych endpointów z poziomu swoich wbudowanych ustawień modeli. To celowe ograniczenie — Cursor zakłada, że używasz zewnętrznych API. Próba dodania http://localhost:11434 w standardowych ustawieniach po prostu nie zadziała.

Rozwiązanie: rozszerzenie Continue.

Instalacja Continue

W Cursorze otwórz panel rozszerzeń (Ctrl+Shift+X)
Wyszukaj "Continue"
Zainstaluj rozszerzenie od Continue Dev
Poczekaj na pełną instalację i zrestartuj Cursor

Konfiguracja

Continue przechowuje konfigurację w pliku ~/.continue/config.json. Otwórz go i dodaj oba modele:

JSON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
{
  "models": [
    {
      "title": "myAgent (lokalny Qwen 3)",
      "provider": "ollama",
      "model": "myAgent",
      "apiBase": "http://localhost:11434"
    },
    {
      "title": "myCopilot (autouzupełnianie)",
      "provider": "ollama",
      "model": "myCopilot",
      "apiBase": "http://localhost:11434"
    }
  ],
  "tabAutocompleteModel": {
    "title": "myCopilot",
    "provider": "ollama",
    "model": "myCopilot",
    "apiBase": "http://localhost:11434"
  },
  "allowAnonymousTelemetry": false
}

allowAnonymousTelemetry: false — warto wyłączyć, skoro zależy nam na prywatności.

Po zapisaniu pliku i restarcie Cursora w panelu Continue pojawią się oba modele. Możesz przełączać między nimi zależnie od zadania: myCopilot do szybkiego autouzupełniania linii kodu, myAgent do planowania i generowania większych fragmentów.

Wyniki w praktyce

Po uruchomieniu środowiska widać kilka charakterystycznych wzorców:

Pierwsze pytanie jest wolniejsze. Model musi załadować wagi do VRAM (kilka sekund nawet przy szybkiej karcie). Kolejne pytania są znacznie szybsze — dzięki keep_alive=24h model zostaje w pamięci między zapytaniami.

myCopilot reaguje natychmiast. Model 1.5B jest na tyle mały, że autouzupełnianie działa bez odczuwalnego opóźnienia — porównywalnie do GitHub Copilota w chmurze.

Przykładowe zadania, które model wykonuje dobrze:

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Pytanie: "Napisz funkcję walidacji emaila przez regex"

import re

def validate_email(email: str) -> bool:
    """
    Waliduje adres email zgodnie z RFC 5322.

    Args:
        email: String do walidacji

    Returns:
        True jeśli email jest poprawny, False w przeciwnym razie
    """
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    return bool(re.match(pattern, email))

# Przykłady użycia
print(validate_email("user@example.com"))   # True
print(validate_email("invalid-email"))       # False
print(validate_email("test@domain.co.uk"))  # True

Model dodaje docstring, typowanie, przykłady użycia — bez dodatkowego zachęcania. To efekt systemu promptu z Modelfile.

Co agent potrafi z rozszerzeniem Continue:

Tworzyć nowe pliki w projekcie
Edytować wskazane fragmenty kodu
Planować implementację funkcjonalności (podejście "najpierw architektura")
Proponować refactoring z wyjaśnieniem decyzji
Debugować błędy na podstawie stack trace

Dla porównania: lokalne środowisko kosztuje energię elektryczną (RTX 5080 pobiera ok. 320W pod obciążeniem) i jednorazowy koszt sprzętu. Nie ma abonamentu, nie ma limitu zapytań, nie ma ryzyka wycieku kodu.

Jeśli chcesz pójść krok dalej i zbudować agentów automatyzujących całe procesy deweloperskie, sprawdź artykuł o MCP, n8n i Claude Code w automatyzacji.

Dalej w tym klastrze

Lokalny RAG z RTX 5080, ColQwen i LanceDB — gdy potrzebujesz przeszukiwać setki dokumentów lokalnie
MCP, n8n i Claude Code — automatyzacja agentami AI — integracja lokalnych modeli z workflow automatyzacji

Chcesz zbudować podobne środowisko dla swojego zespołu developerskiego lub wdrożyć lokalny AI w infrastrukturze firmowej? Umów spotkanie z Kacprem — omówimy architekturę i koszty.

Tagi

#automatyzacja#RAG#AI lokalne#compliance#Ollama#Qwen

Lokalny asystent AI dla programistów — Qwen 2.5, Ollama i Docker