Jak bezpiecznie udostępnić lokalnego Qwena pracownikom

Nie każdy pracownik potrzebuje karty graficznej. Qwen może działać na jednym serwerze, a zespół korzystać z niego przez przeglądarkę na laptopie, tablecie lub telefonie. Model wykonuje obliczenia na serwerze; urządzenie użytkownika wyświetla odpowiedź.

Wspólny dostęp wymaga logowania, uprawnień i kontroli urządzeń. Port modelu zostaje w prywatnej sieci, a aplikacja rozpoznaje użytkownika i pilnuje dostępu do dokumentów. Osobno ustalamy, czy użytkownik może tylko czytać odpowiedzi, czy także uruchamiać narzędzia.

Jeden model, trzy rodzaje klientów

zatwierdzone urządzenie
  |
  +-- telefon / tablet / przeglądarka
  +-- laptop / IDE / klient API
  +-- automatyzacja / tożsamość usługi
  |
brama dostępu
  |
API modelu -> host z GPU

Przeglądarka jest praktycznym klientem telefonu, tabletu i zwykłego komputera. Użytkownik loguje się do firmowego interfejsu, wybiera dozwolone źródła i widzi cytaty albo historię zadania. Interfejs potrzebuje uwierzytelniania, sesji przypisanych do użytkowników, limitów i rejestru operacji.

Klient programistyczny ma szersze uprawnienia. Qwen Code może czytać repozytorium i uruchamiać lokalne narzędzia, dlatego powinien działać na urządzeniu deweloperskim objętym właściwą polityką. Automatyzacja serwerowa otrzymuje własną tożsamość i limity, bez używania klucza człowieka.

Co rzeczywiście sprawdziliśmy

W zapisanym teście Qwen Code działał na MacBooku, a model na domowym komputerze z RTX 3090. Klient czytał lokalną kopię repozytorium i wysyłał do serwera polecenie oraz wyniki potrzebnych narzędzi. Przez HTTP w zaufanej domowej sieci lokalnej, z kluczem API, łączył się z wybraną konfiguracją vLLM na porcie 18020. Usługa obsługiwała jedno żądanie modelu naraz, więc nie obsługiwała wielu żądań równocześnie.

W zapisanych zadaniach programistycznych OpenAI Codex oceniał zmiany według kryteriów Syntalith: poprawności, testów regresji, zgodności, dyscypliny zakresu, weryfikacji i dokumentacji. Nie sprawdzaliśmy jakości pracy na telefonie ani usługi dla wielu równoczesnych użytkowników. Dostęp przez przeglądarkę, prywatną sieć łączącą urządzenia i tożsamości poszczególnych użytkowników to sposoby wdrożenia, które trzeba przetestować na docelowych urządzeniach. Przebieg z MacBooka potwierdza tylko rozdzielenie klienta od GPU. Cała architektura zdalna wymaga osobnego testu.

Droga 1. Interfejs WWW w prywatnej sieci

Telefon i tablet potrzebują aplikacji WWW, która przyjmuje pytanie, sprawdza użytkownika, dołącza dozwolone źródła i dopiero potem wywołuje Qwena przez localhost albo chronioną sieć serwerową.

HTTPS + logowanie firmowe
          |
  interfejs / brama aplikacyjna
          |
  http://127.0.0.1:18020/v1

Przy Tailscale aplikację można udostępnić zatwierdzonym urządzeniom przez Tailscale Serve. Dokumentacja rozróżnia prywatny Serve od publicznego Funnel. W tym układzie korzystamy z prywatnej trasy, a adres API modelu pozostaje poza Funnel.

Przykład dla interfejsu działającego lokalnie na porcie 3000, z wartościami do zastąpienia:

tailscale serve --https=443 http://127.0.0.1:3000
tailscale serve status

HTTPS szyfruje połączenie, lecz nie określa uprawnień aplikacji. Brama nadal musi wiedzieć, kto pyta, do jakich dokumentów ma dostęp, ile zadań może uruchomić i gdzie zapisać ślad audytowy.

Droga 2. Prywatna sieć dla aplikacji i klientów

Urządzenie z Qwen Code, aplikacją desktopową albo zatwierdzonym klientem mobilnym może dołączyć do prywatnej sieci łączącej urządzenia przez internet. Tailscale udostępnia klientów między innymi dla Windows, macOS, Linux, iOS, Androida i ChromeOS.

Reguła dostępu powinna wskazywać konkretną grupę, usługę i port. Tailscale Grants opisują źródło, cel i dozwolone możliwości w modelu domyślnej odmowy. Firma powinna dodać zatwierdzanie urządzeń, wymagania dotyczące ich stanu, procedurę odebrania dostępu po utracie telefonu i okresowy przegląd reguł.

W stałej sieci biurowej podobną granicę tworzą prywatny adres, zapora i reguła dla wybranej podsieci. Sieć gościnna powinna pozostać poza zakresem. Sam prefiks 192.168 nie potwierdza zaufania.

Droga 3. Tunel SSH dla jednego inżyniera

SSH jest dobrym rozwiązaniem zapasowym dla laptopa z terminalem. Codzienna obsługa telefonu, tabletu lub większej grupy wymaga wygodniejszej warstwy. Przekierowanie portu może wyglądać tak:

ssh -N \
  -L 18020:127.0.0.1:18020 \
  gpu-user@gpu-host.example

Klient używa wtedy http://127.0.0.1:18020/v1. Konfiguracja obejmuje weryfikację klucza hosta i ograniczone konto SSH. Klucz API tworzy drugą granicę, a zerwany tunel powinien przerwać zadanie bez ryzykownego automatycznego powtórzenia. Przy innym profilu serwera trzeba podmienić port.

Sekret i przepływ danych muszą być jawne

Klucz nie powinien trafiać do repozytorium, pliku synchronizowanego z prywatną chmurą ani kodu aplikacji mobilnej. Jednej osobie może wystarczyć plik użytkownika z prawami 0600. Firma potrzebuje magazynu sekretów, rotacji oraz tożsamości przypisanej użytkownikowi lub usłudze.

Plik otwarty na laptopie może pozostać na tym laptopie, lecz treść potrzebna Qwenowi przechodzi do stacji GPU. Załącznik wysłany z telefonu może trafić do bramy, modułu odczytującego pliki, dzienników lub pamięci podręcznej, zależnie od projektu aplikacji. Lokalny model eliminuje udział jednego zewnętrznego dostawcy, lecz dane nadal przechodzą przez system.

Siedem testów przed oddaniem użytkownikom

1. Nowe urządzenie: bez zatwierdzenia nie widzi interfejsu ani portu.
2. Utracony telefon: odebranie urządzenia kończy aktywne sesje i blokuje kolejne.
3. Zła rola: użytkownik nie pobiera źródła spoza swojego zakresu.
4. Brak klucza: API odmawia odpowiedzi.
5. Drugi użytkownik: kolejka, limit lub odmowa są czytelne.
6. Zerwane połączenie: klient nie powtarza akcji wywołującej skutek uboczny.
7. Restart stacji GPU: interfejs pokazuje awarię, a test syntetyczny potwierdza powrót usługi.

Testy wykonaj na co najmniej jednym telefonie, jednym komputerze poza biurem i urządzeniu, które celowo nie spełnia polityki. Dopiero taki zakres pozwala powiedzieć, z jakich urządzeń usługa rzeczywiście działa.

Gdzie kończy się samodzielna konfiguracja

Syntalith wdraża prywatne modele dostępne dla zespołu: od serwera i sieci po interfejs, logowanie, limity oraz monitoring. Sprawdzamy obciążenie przy kilku użytkownikach i przygotowujemy instrukcję odebrania dostępu, np. po utracie telefonu.

Pomagamy też osobom prywatnym połączyć własny komputer z modelem i drugim urządzeniem. Opisz sprzęt i sposób użycia, a dobierzemy zakres konfiguracji.