Self-Hosted Large Language Model (LLM) z Ollama za serwerem proxy z autoryzacją

Przesyłanie poufnych dokumentów firmowych, danych klientów czy kodu źródłowego do publicznych interfejsów API dużych modeli językowych (LLM), takich jak OpenAI, Anthropic czy Google Gemini, wiąże się z poważnym ryzykiem utraty suwerenności danych oraz naruszeniami przepisów RODO. Hostowanie otwartych modeli AI – takich jak Llama 3.1, Mistral czy CodeLlama – na własnej infrastrukturze serwerowej gwarantuje całkowitą izolację informacji. Ponieważ popularny serwer inferencyjny Ollama domyślnie wystawia swoje API REST na porcie 11434 bez natywnego uwierzytelniania, jego bezpieczne wdrożenie w sieci przedsiębiorstwa wymaga zastosowania dodatkowej warstwy architektonicznej: serwera proxy odwrotnego Nginx wymuszającego rygorystyczne uwierzytelnianie tokenem oraz szyfrowanie TLS.

1. Architektura rozwiązania: Bezpieczny potok inferencji brzegowej

Profesjonalne lokalne wdrożenie modelu LLM oddziela wykonywanie obliczeń od bezpośredniej ekspozycji sieciowej poprzez warstwowe połączenie trzech odizolowanych usług w środowisku kontenerowym:

• Backend inferencyjny Ollama: Wykonuje obliczenia modeli o otwartych wagach przy użyciu akceleracji GPU NVIDIA (za pośrednictwem NVIDIA Container Toolkit) lub kwantyzacji CPU, komunikując się wyłącznie przez wewnętrzne interfejsy sieci kontenerowej.
• Serwer proxy uwierzytelniający i szyfrujący Nginx: Działa jako jedyny punkt wejścia, przechodząc przez który każde zapytanie HTTP podlega terminacji SSL/TLS oraz weryfikacji tokena Bearer lub poświadczeń HTTP Basic Auth przed przekazaniem do serwera Ollama.
• Kompatybilny z OpenAI interfejs lub skrypty: Wewnętrzne interfejsy internetowe (np. Open WebUI) lub zautomatyzowane skrypty Python komunikują się z zabezpieczonym punktem końcowym przy użyciu standardowej składni SDK OpenAI, bez pomijania warstwy ochronnej.

2. Wdrożenie kontenerów i akceleracji GPU krok po kroku

W celu uruchomienia serwera Ollama wraz z dedykowanym proxy odwrotnym Nginx należy wdrożyć poniższy produkcyjny plik docker-compose.yml skonfigurowany pod kątem dostępu do procesorów graficznych (GPU Passthrough) oraz izolacji sieciowej:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: enterprise_ollama
    restart: always
    environment:
      - OLLAMA_HOST=0.0.0.0
      - OLLAMA_ORIGINS=*
    volumes:
      - ./ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    networks:
      - llm_internal

  auth_proxy:
    image: nginx:alpine
    container_name: ollama_auth_proxy
    restart: always
    ports:
      - "8443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
      - ./htpasswd:/etc/nginx/.htpasswd:ro
    depends_on:
      - ollama
    networks:
      - llm_internal

networks:
  llm_internal:
    driver: bridge

3. Konfiguracja proxy uwierzytelniającego Nginx krok po kroku

Aby ograniczyć dostęp do API wyłącznie do autoryzowanych systemów firmowych, Nginx jest konfigurowany z wymogiem HTTP Basic Auth lub weryfikacji tokenów. Poniższy skrypt nginx.conf egzekwuje uwierzytelnianie i wydłuża limity czasowe dla długotrwałego strumieniowania odpowiedzi modeli LLM:

events {
    worker_connections 1024;
}

http {
    upstream ollama_backend {
        server ollama:11434;
    }

    server {
        listen 443 ssl;
        server_name llm.internal.domain;

        ssl_certificate /etc/nginx/certs/server.crt;
        ssl_certificate_key /etc/nginx/certs/server.key;
        ssl_protocols TLSv1.2 TLSv1.3;

        # Wymuszenie HTTP Basic Auth (Generowanie przez: htpasswd -c ./htpasswd api_user)
        auth_basic "Enterprise LLM Secure Gateway";
        auth_basic_user_file /etc/nginx/.htpasswd;

        # Obowiązkowe wydłużenie timeoutów dla strumieniowania długich odpowiedzi
        proxy_read_timeout 600s;
        proxy_connect_timeout 600s;
        proxy_send_timeout 600s;

        location / {
            proxy_pass http://ollama_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            
            # Obsługa strumieniowania Server-Sent Events (SSE)
            proxy_buffering off;
            proxy_cache off;
        }
    }
}

4. Weryfikacja działania skryptów i interfejsu Web UI krok po kroku

Po uruchomieniu proxy serwer inferencyjny da się bezpiecznie odpytywać za pomocą skryptów lub połączyć z interfejsami czatu:

1. Pobieranie modeli: Początkowe pobranie modelu odbywa się wewnątrz kontenera przy użyciu wiersza poleceń:
   docker exec -it enterprise_ollama ollama run llama3.1
2. Weryfikacja przez API w Pythonie/cURL: Wysłanie uwierzytelnionego zapytania HTTPS REST do proxy z podaniem poświadczeń Basic Auth:
   curl -k -u "api_user:SecretPassword123" https://localhost:8443/api/generate -d '{"model": "llama3.1", "prompt": "Podsumuj politykę prywatności firmy.", "stream": false}'
3. Połączenie z Open WebUI: Wdrożenie kontenera open-webui w tej samej sieci przy odpowiednim skonfigurowaniu zmiennej środowiskowej punktu końcowego:
   OLLAMA_BASE_URL=https://api_user:SecretPassword123@auth_proxy:443

5. Podsumowanie i wartość architektoniczna

Co da się osiągnąć dzięki temu poradnikowi: Wdrożenie własnego, akcelerowanego procesorami GPU serwera dużych modeli językowych (LLM) z wykorzystaniem platformy Ollama, zabezpieczonego przez serwer proxy Nginx z uwierzytelnianiem i szyfrowaniem SSL/TLS.

Wynikająca z tego wartość: Wewnętrzne zespoły, systemy programistyczne oraz interfejsy pracowników zyskują dostęp do prywatnego, wysoce wydajnego odpowiednika „ChatGPT” bez ryzyka wycieku danych do zewnętrznych komercyjnych interfejsów API. Zachowana zostaje pełna suwerenność informacji oraz zgodność z przepisami RODO, a obowiązkowe nagłówki uwierzytelniające uniemożliwiają nieuprawniony dostęp do firmowych zasobów obliczeniowych.