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 z zatwierdzonych telefonów, tabletów i komputerów. Urządzenie użytkownika potrzebuje jedynie przeglądarki albo zgodnej aplikacji. Dostęp powinien przechodzić przez warstwę logowania i uprawnień przed serwerem modelu.

Każde urządzenie musi być dopuszczone przez firmę. Port modelu nie powinien być publicznie dostępny w internecie.

Firma powinna więc zdecydować osobno, które telefony, tablety i komputery mogą wejść do prywatnej sieci, z jakich źródeł korzystać oraz jakie działania wykonywać bez dodatkowego zatwierdzenia człowieka.

Jeden model, trzy rodzaje klienta

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 najlepszą drogą dla telefonu, tabletu i zwykłego komputera. Użytkownik nie instaluje narzędzia programistycznego; loguje się do firmowego interfejsu, wybiera dozwolone źródła i widzi cytaty lub historię zadania. Taki interfejs musi mieć uwierzytelnienie, sesje per użytkownik, limity i rejestrowanie operacji.

Klient programistyczny ma szerszy dostęp. Qwen Code może czytać repozytorium i uruchamiać lokalne narzędzia, dlatego powinien działać tylko na urządzeniu deweloperskim objętym właściwą polityką. Automatyzacja serwerowa dostaje osobną tożsamość i własne limity; nie powinna używać klucza człowieka.

Co naprawdę sprawdziliśmy

W zachowanej ewaluacji Qwen Code działał na MacBooku, a model na domowym PC z RTX 3090. Klient czytał lokalną kopię repozytorium i wysyłał do serwera polecenie oraz potrzebne wyniki narzędzi. Łączył się po HTTP w zaufanej domowej sieci lokalnej, z kluczem API, do wybranego profilu vLLM na porcie 18020. Usługa miała jeden slot inferencji.

Nie testowaliśmy jakości pracy na telefonie ani wielu równoczesnych użytkowników. Dostęp przez przeglądarkę, prywatną sieć nakładkową i tożsamości per użytkownik jest wzorcem wdrożeniowym, który trzeba sprawdzić na docelowych urządzeniach. Wynik MacBooka potwierdza rozdzielenie klienta od GPU; nie jest testem całej architektury zdalnej.

Droga 1. Interfejs WWW w prywatnej sieci

Na telefonie i tablecie nie potrzebujesz surowego API. Potrzebujesz małej aplikacji WWW, która przyjmuje pytanie, sprawdza użytkownika, dokłada właściwe źródła i dopiero wtedy wywołuje Qwena po localhost lub chronionej sieci serwerowej.

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 używamy prywatnej trasy; bezpośredni adres API modelu nie trafia do 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

Samo HTTPS nie rozwiązuje uprawnień aplikacji. Brama nadal musi wiedzieć, kto pyta, do jakich dokumentów ma dostęp, ile zadań może uruchomić i gdzie trafi log.

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

Jeżeli użytkownik ma Qwen Code, aplikację desktopową albo zatwierdzony klient mobilny, urządzenie może wejść do prywatnej sieci nakładkowej. Tailscale publikuje klientów między innymi dla Windows, macOS, Linux, iOS, Androida i ChromeOS.

Dostęp powinien wskazywać konkretną grupę, usługę i port. Aktualne Tailscale Grants pozwalają opisać źródło, cel i dozwolone możliwości oraz działają w modelu domyślnej odmowy. Firma powinna dołożyć zatwierdzanie urządzeń, wymagania stanu urządzenia, wycofanie utraconego telefonu i okresowy przegląd reguł.

Na stałej sieci biurowej podobny efekt daje prywatny adres, zapora sieciowa i reguła tylko dla wybranej podsieci. Sieć gościnna pozostaje poza zakresem. Nie wystarczy, że adres zaczyna się od 192.168.

Droga 3. Tunel SSH dla jednego inżyniera

SSH jest dobrym rozwiązaniem zapasowym dla laptopa z terminalem. Słabo nadaje się do codziennej obsługi telefonu, tabletu lub większej grupy. 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. Weryfikacja klucza hosta i ograniczone konto SSH są częścią konfiguracji. Klucz API pozostaje drugą warstwą, a zerwany tunel musi przerwać zadanie bez ryzykownego automatycznego ponowienia. Port należy zastąpić, jeśli wybrany serwer wystawia inny.

Sekret i dane zostają nazwane

Klucza nie wpisujemy do repozytorium, pliku synchronizowanego z prywatną chmurą ani kodu aplikacji mobilnej. Dla jednej osoby może wystarczyć plik użytkownika z prawami 0600. Firma potrzebuje magazynu sekretów, rotacji i tożsamości przypisanej do użytkownika lub usługi.

Plik otwarty na laptopie może pozostać na tym laptopie, lecz jego treść potrzebna Qwenowi przechodzi do stacji GPU. Załącznik wysłany z telefonu również trafia do bramy, modułu odczytującego pliki, dzienników lub pamięci podręcznej zgodnie z projektem aplikacji. Lokalny model usuwa jednego zewnętrznego dostawcę z przepływu; nie usuwa samego przepływu danych.

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 komunikat są czytelne.
  6. Zerwane połączenie: klient nie powtarza akcji ze skutkiem ubocznym.
  7. Restart stacji GPU: interfejs pokazuje awarię, a test syntetyczny potwierdza powrót usługi.

Test wykonujemy na co najmniej jednym telefonie, jednym komputerze poza biurem i urządzeniu, które celowo nie spełnia polityki. Dopiero wtedy „działa z każdego urządzenia” staje się sprawdzonym zakresem zamiast hasła.

Gdzie kończy się samodzielna konfiguracja

Jedna osoba może uruchomić prywatny tunel i klienta. Firma potrzebuje jeszcze interfejsu, logowania, ról, limitów, obserwowalności, procedury utraconego urządzenia i właściciela usługi. Na jednej karcie dochodzi kolejka, ponieważ zmierzony domowy profil miał jeden aktywny slot.

Syntalith projektuje ten 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 sprawdzić, które urządzenia i dane naprawdę powinny dostać 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