Ollama, vLLM i self-hosted LLM — jak uruchomić lokalny model AI w firmie

Własny hosting modelu językowego opłaca się, gdy miesięczny koszt API przekracza ~$400–600 lub gdy dane nie mogą opuścić Twojej infrastruktury (GDPR, tajemnica handlowa, dane medyczne). Poniżej tej skali: API OpenAI lub Anthropic jest tańsze po uwzględnieniu kosztów DevOps i GPU. Powyżej — RTX 4090 (koszt ~$1 600) zwraca się w 3–5 miesięcy przy obciążeniu 1M+ tokenów dziennie. Do rozruchu na laptopie i testów: Ollama. Do produkcji z wymaganą skalą i niskim latency: vLLM. Do testowania modeli bez terminala: LM Studio.

Praktyczny przewodnik po samodzielnym hostingu modeli językowych: kiedy własny model opłaca się bardziej niż API OpenAI, jak skonfigurować Ollama na laptopie i vLLM na GPU serwerze, jakie GPU wybrać, jak podłączyć aplikacje przez OpenAI-compatible API i jak wdrożyć monitoring prywatnego LLM w produkcji.

Twój chatbot AI obsługuje zapytania klientów i przetwarza dokumenty wewnętrzne — a każde wywołanie wysyła fragmenty tych danych na serwery OpenAI. Prawnik pyta, czy to zgodne z GDPR. Finanse patrzą na fakturę: $3 200 miesięcznie za API. CTO zastanawia się, czy nie czas na własną infrastrukturę.

To pytanie zadaje coraz więcej firm — i odpowiedź brzmi: zależy, ale coraz częściej "tak". Ekosystem self-hosted LLM (Ollama, vLLM, LM Studio, Hugging Face TGI) dojrzał na tyle, że wdrożenie zajmuje godziny, nie tygodnie. Ten artykuł pokazuje kiedy, jak i na czym.

Kiedy self-hosted LLM się opłaca?

Cztery scenariusze, w których własna infrastruktura jest lepsza niż API:

• Compliance i prywatność — branże regulowane (medycyna, prawo, finanse, obronność) nie mogą wysyłać danych do zewnętrznych dostawców; HIPAA, GDPR art. 28, tajemnica bankowa wprost to uniemożliwiają lub wymagają DPA, którego OpenAI nie podpisuje z każdym klientem
• Wysoka skala tokenów — przy 5M+ tokenów dziennie ($22,50/dzień na GPT-4o-mini) własny A100 40 GB zwraca się w 2–3 miesiące; przy 20M tokenów dziennie oszczędność to $50 000 rocznie
• Niskie latency jako wymóg — aplikacje real-time (voice AI, interaktywne UI) potrzebują <200 ms; lokalne vLLM z GPU na tej samej maszynie co aplikacja daje 30–80 ms
• Fine-tuned model — po treningu QLoRA (artykuł #38) masz plik adaptera GGUF lub LoRA weights; żeby z niego korzystać, potrzebujesz lokalnego serwera inferencji — Ollama lub vLLM

Trzy scenariusze, w których API jest lepsze:

• Startup na etapie budowania produktu — prototyp w 30 minut bez DevOps
• Mała skala (< $200/msc API) — koszt GPU i inżyniera przewyższa oszczędności
• Potrzebujesz modeli GPT-4o / Claude — te nie są dostępne self-hosted (zamknięte wagi)

Ollama — lokalny LLM w 5 minut

Ollama to najprostszy sposób na uruchomienie otwartego modelu na własnym komputerze. Instalacja, pobranie modelu i pierwsze wywołanie to dosłownie trzy komendy.

# macOS / Linux — instalacja jedną komendącurl -fsSL https://ollama.ai/install.sh | sh# Pobierz i uruchom model (auto-download z HuggingFace)ollama run llama3.2:3b           # 3B — działa na każdym laptopieollama run llama3.1:8b           # 8B — potrzebujesz 8 GB VRAM lub 16 GB RAMollama run mistral:7b-instruct   # 7B Mistral — świetny do instrukcjiollama run phi3:14b              # 14B Phi-3 — najlepszy stosunek jakość/VRAM# Serwer HTTP na porcie 11434 (startuje automatycznie)# REST API kompatybilne z OpenAI:curl http://localhost:11434/v1/chat/completions \  -H "Content-Type: application/json" \  -d '{"model":"llama3.1:8b","messages":[{"role":"user","content":"Czesc!"}]}'

Podłączenie do istniejącej aplikacji korzystającej z OpenAI SDK:

from openai import OpenAI# Zmień tylko base_url — reszta kodu identyczna jak z OpenAIclient = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")response = client.chat.completions.create(    model="llama3.1:8b",    messages=[{"role": "user", "content": "Streść ten kontrakt w 3 zdaniach."}],    temperature=0.2,)print(response.choices[0].message.content)

Konfiguracja Ollama jako serwis systemd (Linux/serwer):

[Unit]Description=Ollama LLM serverAfter=network.target[Service]ExecStart=/usr/local/bin/ollama serveRestart=alwaysUser=ollamaEnvironment=OLLAMA_HOST=0.0.0.0:11434Environment=OLLAMA_MODELS=/opt/models[Install]WantedBy=multi-user.target

Kiedy Ollama wystarczy, a kiedy nie:

• Ollama sprawdza się do: lokalnego developmentu, testowania modeli przed wyborem, małych wdrożeń (1–5 concurrent users), integracji z n8n/LangChain podczas budowania pipeline'u
• Ollama nie nadaje się do: produkcji z wieloma równoległymi zapytaniami (obsługuje jedno wywołanie na raz), wysokich wymagań throughput, wdrożenia z GPU i pełnym wykorzystaniem kart

vLLM — LLM gotowy na produkcję

vLLM to silnik inferencji zoptymalizowany dla GPU. Jego główna innowacja — PagedAttention — zarządza pamięcią KV-cache jak stronicowanie w OS, co pozwala obsłużyć 2–4× więcej równoległych zapytań przy tym samym GPU niż naiwna implementacja.

# Instalacja (wymaga CUDA 12.x, Python 3.10+)pip install vllm# Uruchomienie serwera (OpenAI-compatible API na porcie 8000)python -m vllm.entrypoints.openai.api_server \  --model meta-llama/Llama-3.1-8B-Instruct \  --gpu-memory-utilization 0.90 \  --max-model-len 8192 \  --dtype bfloat16 \  --port 8000# Model fine-tuned z LoRA adaptera:python -m vllm.entrypoints.openai.api_server \  --model meta-llama/Llama-3.1-8B-Instruct \  --enable-lora \  --lora-modules firmowy-model=/opt/lora/checkpoint-500 \  --port 8000

Podłączenie aplikacji do vLLM — identyczny kod jak z OpenAI:

from openai import OpenAIimport asyncioclient = OpenAI(base_url="http://localhost:8000/v1", api_key="vllm")# Batch processing — vLLM obsługuje wiele rownoległych zapytańasync def process_documents(docs: list[str]) -> list[str]:    import httpx    async with httpx.AsyncClient() as http:        tasks = [            http.post("http://localhost:8000/v1/chat/completions", json={                "model": "meta-llama/Llama-3.1-8B-Instruct",                "messages": [{"role": "user", "content": f"Stresc: {doc}"}],                "max_tokens": 200,            })            for doc in docs        ]        results = await asyncio.gather(*tasks)    return [r.json()["choices"][0]["message"]["content"] for r in results]

Konfiguracja dla różnych GPU:

• Jedna karta A100 80 GB: "--gpu-memory-utilization 0.90 --tensor-parallel-size 1"
• Dwie karty A100 40 GB (model 70B): "--tensor-parallel-size 2"
• Cztery karty RTX 4090 24 GB (model 34B): "--tensor-parallel-size 4"

Jakie GPU wybrać i ile kosztuje?

Praktyczna reguła: potrzebujesz ~2× VRAM ile zajmuje model w wybranej precyzji.

Czym jest kwantyzacja (Q4, Q8, GGUF)?

Kwantyzacja to kompresja wag modelu z pełnej precyzji (16-bit, oznaczanej bf16) do mniejszej liczby bitów — najczęściej 8 (Q8) lub 4 (Q4). To kluczowa technika, dzięki której duże modele mieszczą się na konsumenckich GPU:

• bf16 (pełna precyzja) — model 8B zajmuje ~16 GB VRAM; najlepsza jakość, wymaga drogiego GPU
• Q8 (8-bit) — ~8 GB dla modelu 8B; utrata jakości praktycznie niemierzalna; bezpieczny standard
• Q4 (4-bit) — ~5 GB dla modelu 8B; utrata jakości 1–3% na benchmarkach; najczęstszy wybór do self-hosted, bo pozwala zmieścić 2× większy model na tym samym GPU — a większy model Q4 prawie zawsze bije mniejszy bf16
• GGUF — format pliku skwantyzowanych modeli używany przez llama.cpp i Ollama; modele w GGUF pobierzesz gotowe z Hugging Face (szukaj suffixu "-GGUF")

Praktyczna zasada: zaczynaj od Q4. Jeśli zauważysz problemy z jakością na swoim zadaniu — przejdź na Q8 lub bf16 i porównaj na golden datasecie.

Cloud vs własny GPU: Dla zmiennego obciążenia (godziny pracy biurowej) — cloud on-demand (RunPod, Lambda Labs, Vast.ai) jest tańszy: płacisz tylko za czas działania. Dla stałego obciążenia 24/7 — własny serwer lub dedykowana maszyna zwraca się w 3–6 miesięcy. Kalkulator: miesięczny koszt cloud = koszt_na_godzinę × 720 h; jeśli > $800 — własny serwer zaczyna wygrywać.

Modele: które wybrać do self-hosted?

Rekomendacja startowa: zacznij od Llama 3.1 8B Instruct (Ollama: "ollama pull llama3.1:8b") — działa na RTX 4090 lub A10G, radzi sobie z polskim, ma świetny stosunek jakości do kosztu. Dla wymagań 70B+ — Qwen2.5 72B lub Llama 3.1 70B na A100 80 GB.

Jak podłączyć self-hosted LLM do istniejących narzędzi?

Zarówno Ollama, jak i vLLM eksponują OpenAI-compatible REST API — co oznacza, że każde narzędzie obsługujące OpenAI działa od razu, bez modyfikacji:

• LangChain — ChatOpenAI(base_url="http://localhost:11434/v1", model="llama3.1:8b") — zmiana jednej linii
• LlamaIndex — OpenAI(api_base="http://localhost:8000/v1") — analogicznie
• n8n — w węźle OpenAI zmień "Base URL" na lokalny adres serwera (Ollama lub vLLM)
• Open WebUI — GUI dla Ollama, działa jak ChatGPT w przeglądarce, dostępny po zainstalowaniu na localhost:3000
• Continue.dev — plugin VS Code z lokalnym LLM zamiast Copilot; w config.json ustaw model i apiBase

Monitoring i bezpieczeństwo self-hosted LLM

Self-hosted LLM to nie tylko GPU i model — potrzebujesz obserwacji i kontroli dostępu.

Obserwabilność:

• Langfuse self-hosted (Docker Compose) — traces, tokeny, latency, koszty obliczeniowe, analogicznie jak przy zewnętrznym API
• Prometheus + Grafana — metryki GPU (temperatura, VRAM usage, throughput) przez nvidia-smi lub DCGM exporter
• Własny JSON log z request_id, model, prompt_tokens, completion_tokens, latency_ms, user_id do każdego wywołania

Kontrola dostępu:

• vLLM obsługuje API key auth przez parametr "--api-key SECRET" — wymuś to od razu
• Reverse proxy (nginx lub Caddy) z SSL + rate limiting przed vLLM; nigdy nie wystawiaj portu vLLM bezpośrednio na internet
• Loguj każde wywołanie z IP i user_id do audytu — przy compliance GDPR to wymóg

server {    listen 443 ssl;    server_name llm.twojafirma.pl;    ssl_certificate /etc/letsencrypt/live/llm.twojafirma.pl/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/llm.twojafirma.pl/privkey.pem;    location /v1/ {        proxy_pass http://127.0.0.1:8000;        proxy_set_header X-Real-IP $remote_addr;        limit_req zone=llm_limit burst=20 nodelay;    }}limit_req_zone $binary_remote_addr zone=llm_limit:10m rate=30r/m;

Checklist wdrożenia self-hosted LLM

1. 1.Policz TCO: API cost miesięcznie vs koszt GPU + koszt DevOps; jeśli API < $400/msc — nie wdrażaj własnego modelu
2. 2.Określ wymagania compliance — czy dane naprawdę nie mogą opuścić infrastruktury, czy wystarczy DPA z dostawcą API?
3. 3.Zacznij od Ollama lokalnie — zweryfikuj, że wybrany model daje wystarczającą jakość PRZED zakupem GPU
4. 4.Wybierz GPU według zasady: VRAM ≥ 2× rozmiar modelu (Q4); dla produkcji z 5+ concurrent users — A10G lub A100
5. 5.Dla produkcji: vLLM zamiast Ollama — obsługa wielu równoległych zapytań i PagedAttention
6. 6.Wystaw API przez nginx z SSL, API key auth i rate limiting; nigdy bezpośrednio na internet
7. 7.Wdróż monitoring GPU (Prometheus + Grafana) i traces LLM (Langfuse self-hosted)
8. 8.Zrób test regresji na golden dataset po każdej zmianie modelu
9. 9.Zaplanuj rollback — trzymaj poprzednią wersję modelu, przełączenie powinno zająć < 5 minut
10. 10.Przejrzyj politykę GDPR — nawet self-hosted wymaga RCP dla danych osobowych przetwarzanych przez LLM

---

Pomagam firmom ocenić, wybrać i wdrożyć self-hosted LLM — od analizy TCO i doboru GPU przez konfigurację vLLM i Ollama po monitoring, bezpieczeństwo i integrację z istniejącymi systemami. Napisz do mnie — zaczynam od bezpłatnej 30-minutowej analizy Twojego stacku AI i kalkulacji progu opłacalności.