Wnioskowanie LLM na wojskowym sprzęcie brzegowym: uruchamianie modeli językowych w środowiskach bez połączenia

Duże modele językowe działające w całości na lokalnym węźle brzegowym — bez internetu, bez API chmurowego, bez danych opuszczających platformę — nie są już ciekawostką badawczą. To operacyjna rzeczywistość dla programów obronnych, które potrzebują wspomaganego przez AI dowodzenia i kontroli, podsumowań wywiadowczych lub autonomicznego wsparcia decyzyjnego w środowiskach, gdzie łączność jest słabością, a nie atutem. Artykuł omawia pełny stos: dlaczego chmurowe LLM zawodzą taktycznie, jaki sprzęt i modele wybrać, jak efektywnie kwantyzować i obsługiwać je oraz jak zabezpieczyć usługę wnioskowania na tajnym węźle brzegowym.

1. Problem z łącznością

Chmurowe LLM, takie jak GPT-4o lub Claude Sonnet, zakładają stabilne, szerokopasmowe połączenie o małych opóźnieniach. W środowiskach taktycznych założenie to zawodzi na co najmniej trzy strukturalnie różne sposoby. EMCON (Kontrola Emisji) zabrania wszelkich transmisji radiowych, aby uniknąć wykrycia elektronicznego. Przepustowość MANET wynosi 1–10 Mbps łącznie z dużymi opóźnieniami, łatwo nasycanymi przez jednoczesne wywołania API LLM. Zablokowana łączność — zagłuszanie, maskowanie terenowe lub celowa izolacja sieci — oznacza, że pozycja z zablokowanym GPS i łącznością potrzebuje pomocy AI dokładnie wtedy, gdy dostęp do chmury jest najmniej możliwy. Ponadto kierowanie wrażliwych danych operacyjnych przez komercyjne API chmurowe tworzy zagrożenia OPSEC i klasyfikacyjne, często niedopuszczalne dla tajnych lub wrażliwych obciążeń roboczych.

2. Poziomy sprzętu do wnioskowania brzegowego LLM

NVIDIA Jetson Orin NX 16GB to podstawowa rekomendacja: 16 GB LPDDR5 z 102 GB/s, 1024 rdzenie CUDA, backend CUDA llama.cpp, 12–18 tok/s na Llama 3.1 8B Q4_K_M, 15–20 W. Przemysłowy zakres temperatur, wzmocnione płyty nośne, łańcuch dostaw obronny. Hailo-10 oferuje 40 TOPS przy poniżej 5 W — wyjątkowy dla węzłów ograniczonych energetycznie, choć dojrzałość łańcucha narzędzi LLM wciąż się rozwija. Intel Arc A770 16GB dostarcza 20–30 tok/s przy 30–35 W dla brzegowych serwerów w pojazdach lub schronach. CPU-only ARM osiąga 3–6 tok/s na Llama 3.1 8B — wolno, ale w pełni offline i używalne dla zadań wsadowych lub asynchronicznych.

3. Dobór modelu: Llama, Qwen, Mistral

Llama 3.1 8B (Apache 2.0): ~73% MMLU, kontekst 128K, niezawodne wykonywanie instrukcji, 12–18 tok/s na Orin NX. Podstawowa rekomendacja. Qwen2.5 7B (Apache 2.0): ~74,2% MMLU, lepsza wydajność wielojęzyczna do użytku koalicyjnego — należy uwzględnić chińskie pochodzenie przy przeglądach pozyskiwania dla tajnych programów. Mistral 7B v0.3 (Apache 2.0): ~63% MMLU, najmniejszy cache KV, najlepszy dla węzłów tylko z CPU, gdzie przepustowość jest krytyczna. Wszystkie trzy są dostępne jako GGUF na Hugging Face do transferu z air-gap.

4. Potok kwantyzacji

GGUF (llama.cpp) to standard dla brzegu — przenośny między CPU, mieszanym i GPU wnioskowania. Q4_K_M: ~4,9 GB dla modeli 8B, 1–3% straty jakości względem FP16, standardowy wybór taktyczny. Q8_0: ~8,5 GB, niemal bez strat, preferowany gdy pozwala pamięć. Unikaj Q2/Q3 dla strukturyzowanych wyjść lub wieloetapowych zadań rozumowania. AWQ celuje w wnioskowanie GPU NVIDIA z lepszą jakością INT4 niż naiwna kwantyzacja — używaj z vLLM na wydajniejszych brzegowych serwerach. GPTQ to starszy standard z szerokim oprzyrządowaniem; AWQ jest preferowany dla nowych wdrożeń GPU.

5. Środowiska uruchomieniowe wnioskowania

llama.cpp z serwerem HTTP to właściwy standard dla brzegowych węzłów jednego użytkownika. Ollama opakowuje llama.cpp REST API i CLI — wyłącz automatyczne pobieranie na węzłach z air-gap, uruchamiaj jako dedykowany użytkownik o niskich uprawnieniach. vLLM (tylko NVIDIA) dodaje PagedAttention i ciągłe przetwarzanie wsadowe dla brzegowych serwerów wielu użytkowników (10+ jednoczesnych). ExLlamaV2 osiąga 30–40 tok/s na Orin AGX z kwantyzacją EXL2 — maksymalna przepustowość jednego GPU, ale bardziej złożony łańcuch narzędzi.

6. Tryb brzegowy TAKpilot

TAKpilot stale monitoruje łączność i kieruje do Claude Sonnet (chmura) gdy dostępne jest łącze uplink, automatycznie przełączając na lokalny Llama 8B przy EMCON lub utracie łączności — opóźnienie przełączenia poniżej 200 ms, bez restartu, ten sam interfejs REST. Tryb brzegowy automatycznie skraca monity systemowe, aktywuje wyjście JSON ograniczone gramatyką i ogranicza długość odpowiedzi.

7. Inżynieria podpowiedzi dla modeli z ograniczeniami

Utrzymuj monity systemowe poniżej 200 tokenów. Wymuszaj strukturyzowane wyjście za pomocą ograniczeń gramatycznych GBNF (llama.cpp) lub parametru formatu Ollama, plus walidacja JSON na poziomie aplikacji z 2–3 próbami ponowienia przekazującymi błędy jako monity korekcyjne. Umieszczaj przykłady few-shot w turze użytkownika, nie w monicie systemowym, dla lepszej efektywności tokenów i zgodności formatu w mniejszych modelach.

8. Bezpieczeństwo wdrożenia brzegowego LLM

Cztery wymagane kontrole: (1) weryfikacja integralności SHA-256 plików modeli przy każdym ładowaniu; (2) dedykowany użytkownik OS o niskich uprawnieniach z polityką AppArmor/SELinux izolującą usługę wnioskowania; (3) odporna na manipulacje rejestracja audytowa każdego żądania i odpowiedzi; (4) wychodzący ruch sieciowy wyłączony na węzłach z air-gap przez iptables ograniczone do UID usługi. Kontrole te mapują się na NIST SP 800-53 i wspierają dokumentację ATO.