Przejdź do treści
Wróć do bloga
qwen3.8Artykuł

Jak bezpiecznie udostępnić lokalnego Qwena pracownikom

Model działa na jednym serwerze z GPU, a zatwierdzone telefony i komputery łączą się przez prywatną aplikację. Porównujemy sieć lokalną, Tailscale i SSH.

Autor

Syntalith

Opublikowano Zaktualizowano 4 min czytania

Model 27B może działać na jednym serwerze z GPU, a pracownicy mogą korzystać z niego na zatwierdzonych telefonach, tabletach i komputerach. Na urządzeniu użytkownika wystarczy przeglądarka albo zgodny klient. Przed serwerem modelu powinny znaleźć się logowanie, uprawnienia i kontrolowana ścieżka sieciowa.

Firma powinna zatwierdzać konkretne urządzenia i osoby. Port modelu pozostaje w prywatnej sieci, a dostęp przechodzi przez warstwę, która rozpoznaje użytkownika i jego uprawnienia.

Warto osobno ustalić, które urządzenia mogą wejść do prywatnej sieci, z jakich źródeł mogą korzystać użytkownicy oraz które działania wymagają dodatkowej zgody człowieka.

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

Jedna osoba może uruchomić prywatny tunel i klienta. Firma potrzebuje też interfejsu, logowania, ról, limitów, obserwowalności, procedury dla utraconego urządzenia, właściciela usługi oraz reguł określających działania wymagające zgody człowieka. Jedna karta GPU wprowadza kolejkę, ponieważ w domowym pomiarze można było obsłużyć jedno żądanie naraz.

Syntalith projektuje przepływ od urządzenia użytkownika do modelu: interfejs WWW, prywatną sieć, bramę API, polityki danych, pomiar obciążenia, monitoring i instrukcję dla administratora. Audyt procesu AI zaczyna się od 4990 zł netto. Umów bezpłatny skan procesu, jeśli chcesz ustalić, które urządzenia i dane powinny otrzymać dostęp.

Bezpłatny skan procesów

Zacznij od bezpłatnego skanu procesów.

  • 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
  • Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
  • Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.

W 30 minut wybieramy proces do oceny, a w ciągu 2 dni roboczych dostajesz rekomendację, także gdy lepsza będzie prostsza droga.

0 zł

30 minut · pisemne podsumowanie w 2 dni robocze