Elastyczność modeli TAKpilot: chmura, izolacja sieciowa i Edge AI dla środowisk taktycznych

Każde środowisko taktyczne jest inne. Niektóre jednostki działają z trwałą łącznością o wysokiej przepustowości do niejawnego enklawy chmurowej; inne wysuwają się naprzód w rejony, gdzie jedyną siecią jest radio mesh w plecaku żołnierza. Kopiloty AI, które działają tylko wtedy, gdy gwiazdy się ułożą — pełna łączność, dostęp do komercyjnej chmury, brak ograniczeń wynikających z klauzuli tajności — nie są użytecznymi narzędziami do operacji wojskowych. TAKpilot, czatowy kopilot AI Corvus Intelligence dla CloudTAK, zbudowano wokół architektury niezależnej od modelu, która daje dowódcom i integratorom systemów rzeczywisty wybór: uruchom Claude Opus 4.7 przez API Anthropic dla szczytowej wydajności analitycznej lub wdróż Llama 3.3 70B na wzmocnionym serwerze GPU z zerową zależnością od internetu. Ten artykuł omawia, jak działa ta architektura, jak wybrać właściwy model dla danego kontekstu misji i jak skonfigurować TAKpilot do wdrożeń brzegowych w izolacji sieciowej krok po kroku.

Dlaczego niezależność od modelu ma znaczenie dla wdrożeń obronnych

Komercyjne produkty AI zazwyczaj zakodowują na sztywno jednego dostawcę. Takie podejście tworzy twardą zależność od łączności internetowej, dostępności komercyjnego API i warunków przetwarzania danych dostawcy — ograniczenia, które często są niekompatybilne ze środowiskami objętymi klauzulą tajności lub operacyjnie wrażliwymi. Architektura TAKpilot rozwiązuje to, abstrahując dostęp do modelu za pojedynczym interfejsem: specyfikacją API zgodną z OpenAI. Każdy model, który mówi tym protokołem — czy hostowany przez Anthropic, AWS, Google, czy przez lokalny serwer inferencyjny działający na tej samej szafie co węzeł CloudTAK — jest poprawnym backendem TAKpilot.

To nie jest teoretyczna elastyczność. TAKpilot jest wdrożony operacyjnie w ukraińskich siłach zbrojnych, gdzie warunki sieciowe, ograniczenia łączności i wymagania dotyczące klauzuli tajności znacznie różnią się w obrębie sił. Element sztabowy z niezawodną łącznością używa Claude Sonnet 4.6 przez API Anthropic. Jednostka wysunięta do przodu, dysponująca jedynie taktyczną łącznością radiową, uruchamia Llama 3.3 8B na lokalnym węźle inferencyjnym. Obie jednostki korzystają z tego samego interfejsu TAKpilot; różni się tylko backend.

Przewodnik po wyborze modelu: dopasowanie możliwości do kontekstu misji

TAKpilot obsługuje trzy poziomy modeli Claude przez API Anthropic oraz pełen zakres otwartych modeli przez interfejs zgodny z OpenAI. Wybór między nimi wiąże się z kompromisami między głębią rozumowania, opóźnieniem, kosztem operacyjnym i wymaganiami dotyczącymi łączności.

Claude Opus 4.7: złożona analiza wieloetapowa

Opus 4.7 to najwydajniejszy model Claude i właściwy wybór do zadań wymagających trwałego rozumowania wieloetapowego: syntezy raportów ISR z wielu źródeł, generowania szczegółowych rozkazów misji z fragmentarycznych instrukcji lub analizy niejednoznacznych danych z sensorów, gdzie fałszywe alarmy niosą poważne konsekwencje operacyjne. Kompromisem jest opóźnienie — Opus 4.7 produkuje tokeny wolniej niż Sonnet czy Haiku, a koszt na token jest wyższy. Do prac analitycznych na poziomie sztabu (S2 i S3), gdzie czas odpowiedzi mierzy się w minutach, a nie sekundach, Opus 4.7 jest właściwym wyborem. Wymaga łączności z API Anthropic lub z AWS Bedrock / Google Vertex z włączonym modelem Opus.

Claude Sonnet 4.6: zrównoważona wydajność do codziennego zarządzania COP

Sonnet 4.6 to domyślnie zalecany model do aktywnych operacji, w których operatorzy wydają konwersacyjne polecenia COP — umieszczanie znaczników, odpytywanie pozycji jednostek, budowanie pakietów danych, subskrypcja kanałów. Zapewnia silne podążanie za instrukcjami i dokładność użycia narzędzi przy niższym opóźnieniu niż Opus, co czyni go wystarczająco responsywnym do użytku interaktywnego bez narzutu kosztów wynikającego z uruchamiania Opus przy każdym umieszczeniu znacznika na mapie. Sonnet 4.6 to model używany we wdrożeniu operacyjnym TAKpilot w ukraińskich siłach jako podstawowa konfiguracja dla elementów połączonych.

Claude Haiku 4.5: priorytet szybkości dla zadań o dużej częstotliwości

Haiku 4.5 jest zoptymalizowany pod kątem opóźnienia i przepustowości. To właściwy wybór do poleceń o dużej częstotliwości i dobrze ustrukturyzowanych — odpytywania bieżących śladów, listowania misji, pobierania danych pozycji dla konkretnych znaków wywoławczych — gdzie zadanie jest na tyle rutynowe, że maksymalna zdolność rozumowania nie jest potrzebna. Haiku odpowiada szybciej niż Sonnet i przy znacznie niższym koszcie na token, co ma znaczenie w środowiskach, gdzie TAKpilot obsługuje dużą liczbę zapytań operatorów w wielu jednoczesnych sesjach. Sprawdza się też jako model zapasowy w okresach presji na limity API.

Modele otwarte dla środowisk w izolacji sieciowej

Gdy łączność chmurowa jest niedostępna lub wymagania klauzuli tajności zabraniają zewnętrznych wywołań API, TAKpilot kieruje inferencję do lokalnie hostowanego modelu przez punkt końcowy zgodny z OpenAI. Trzy modele zostały zwalidowane pod kątem wzorców użycia narzędzi TAKpilot:

• Llama 3.3 70B — model 70B Meta dostrojony do instrukcji zapewnia najlepszą dokładność użycia narzędzi wśród otwartych modeli zwalidowanych z TAKpilot. W kwantyzacji 4-bitowej (Q4_K_M) mieści się na serwerze z dwoma GPU lub pojedynczej A100 i dostarcza 25–40 tokenów na sekundę — wystarczająco do konwersacyjnych interakcji z COP. To zalecany domyślny model dla dobrze wyposażonych wdrożeń brzegowych w izolacji sieciowej.
• Qwen 2.5 72B — Qwen 2.5 firmy Alibaba o 72B parametrach działa porównywalnie do Llama 3.3 70B przy ustrukturyzowanych wywołaniach narzędzi i ma silniejszą wydajność wielojęzyczną, co może być cenne w operacjach koalicyjnych lub jednostkach nieanglojęzycznych. Wymagania sprzętowe są podobne.
• Mistral Large — model Mistral dostrojony do instrukcji jest dostępny jako opcja wdrożenia lokalnego i dobrze radzi sobie z zadaniami klasyfikacji i routingu. To rozsądny wybór, gdy wymagany jest mniejszy ślad pamięciowy, a obciążenie poleceniami jest stosunkowo ustrukturyzowane.
• Llama 3.3 8B — dla środowisk silnie ograniczonych sprzętowo (pojedynczy konsumencki GPU, 8–12 GB VRAM) wariant 8B w kwantyzacji 4-bitowej zapewnia akceptowalną wydajność dla prostych zapytań COP. Złożone wieloetapowe sekwencje narzędzi pogarszają się względem modelu 70B, więc operatorzy powinni oczekiwać konieczności bardziej jednoznacznego formułowania instrukcji.

Backendy chmurowe dla środowisk objętych klauzulą tajności: AWS Bedrock i Google Vertex

Nie wszystkie wdrożenia chmurowe są równoważne z punktu widzenia klauzuli tajności i rezydencji danych. API Anthropic wysyła ruch inferencyjny do infrastruktury Anthropic. Dla środowisk wymagających, by dane pozostawały w obrębie określonej enklawy chmurowej — AWS GovCloud, Azure Government lub dzierżawy Google Workspace for Government — TAKpilot obsługuje kierowanie modeli Claude przez AWS Bedrock i Google Vertex AI, które obsługują hosting modeli w granicach chmury klienta.

AWS Bedrock udostępnia Claude Opus 4.7, Sonnet 4.6 i Haiku 4.5 przez standardowy SDK AWS. Z perspektywy TAKpilot zmiana konfiguracji to podmiana bazowego adresu URL API i metody uwierzytelniania: zastąp klucz API Anthropic poświadczeniami AWS IAM (przez zmienne środowiskowe lub rolę instancji) i ustaw TAKPILOT_PROVIDER=bedrock z odpowiednim regionem AWS. Dostępne są te same modele Claude; ruch inferencyjny pozostaje w granicach sieci AWS i podlega umowom o przetwarzaniu danych klienta z AWS, a nie komercyjnym warunkom Anthropic.

Google Vertex AI oferuje ten sam dostęp do modeli Claude przez model garden Google. Konfiguracja przebiega według tego samego wzorca: ustaw TAKPILOT_PROVIDER=vertex z identyfikatorem projektu GCP i poświadczeniami konta serwisowego. Dla organizacji działających już w ramach ofert chmurowych Google klasy obronnej utrzymuje to cały ruch inferencyjny w obrębie istniejącego obwodu bezpieczeństwa.

Obsługa punktu końcowego zgodnego z OpenAI

Ścieżka TAKpilot w izolacji sieciowej używa tej samej specyfikacji API OpenAI Chat Completions, która stała się de facto standardem dla lokalnych serwerów inferencyjnych modeli. Oznacza to, że TAKpilot jest kompatybilny z każdym środowiskiem inferencyjnym implementującym ten interfejs — Ollama, vLLM, serwer llama.cpp, LM Studio, Hugging Face TGI oraz każdym niestandardowym kontenerem opakowującym model warstwą REST zgodną z OpenAI.

Konfiguracja jest celowo minimalna. Dwie zmienne środowiskowe wystarczą, aby przekierować TAKpilot z API Anthropic na dowolny lokalny punkt końcowy:

# Skieruj TAKpilot na lokalny serwer inferencyjny Ollama
TAKPILOT_API_BASE=http://192.168.1.50:11434/v1
TAKPILOT_MODEL=llama3.3:70b-instruct-q4_K_M
TAKPILOT_API_KEY=ollama

# Lub na serwer vLLM uruchamiający Qwen 2.5
TAKPILOT_API_BASE=http://10.0.1.20:8000/v1
TAKPILOT_MODEL=Qwen/Qwen2.5-72B-Instruct
TAKPILOT_API_KEY=vllm-token

Gdy ustawiono TAKPILOT_API_BASE, TAKpilot pod żadnym pozorem nie próbuje łączyć się z API Anthropic. Nie ma awaryjnego przełączenia na modele chmurowe, jeśli lokalny punkt końcowy jest nieosiągalny — TAKpilot zwróci operatorowi błąd, zamiast po cichu kierować ruch do niezamierzonego punktu końcowego. To celowe zachowanie bezpieczeństwa dla środowisk objętych klauzulą tajności.

Izolacja danych w piaskownicy przypisanej do sesji

Niezależnie od używanego backendu modelu TAKpilot egzekwuje ten sam model izolacji sesji. Każde połączenie operatora tworzy kontekst sesji w pamięci, który przechowuje historię rozmowy, oczekujące wywołania narzędzi i wszelkie dane COP pobrane z CloudTAK podczas sesji. Kontekst ten nigdy nie jest zapisywany na dysku, nigdy nie jest współdzielony z innymi sesjami i nigdy nie jest wysyłany do żadnego punktu końcowego innego niż skonfigurowany backend modelu.

Gdy operator się rozłącza — przez zamknięcie panelu czatu CloudTAK lub po konfigurowalnym limicie czasu sesji — kontekst sesji jest usuwany z pamięci. Nie ma trwałości sesji między połączeniami. Operator, który łączy się ponownie, rozpoczyna świeży kontekst bez wiedzy o poleceniach i pobranych danych z poprzedniej sesji.

Dla wdrożeń w izolacji sieciowej gwarancja piaskownicy jest absolutna: kontekst sesji nigdy nie przekracza granicy sieci, ponieważ backend modelu znajduje się w tym samym segmencie sieci. Operatorzy obsługujący dane COP objęte klauzulą tajności powinni używać trybu izolacji sieciowej z modelem lokalnym — piaskownica przypisana do sesji zapewnia, że dane niejawne są przetwarzane wyłącznie przez lokalny węzeł inferencyjny i usuwane po zakończeniu sesji.

Jak wdrożyć TAKpilot z Llama 3.3 na taktycznym sprzęcie w izolacji sieciowej

Poniższa procedura zakłada instancję Node.js TAKpilot już wdrożoną i połączoną z serwerem CloudTAK. Aby zapoznać się z początkowym wdrożeniem CloudTAK, zob. przewodnik wdrożenia serwera CloudTAK. Serwer inferencyjny musi znajdować się w tej samej taktycznej sieci LAN co CloudTAK i TAKpilot.

Krok 1: Udostępnij serwer inferencyjny GPU w taktycznej sieci LAN

Zainstaluj Ollama na serwerze z systemem Linux (zalecany Ubuntu 22.04 LTS) z co najmniej jednym GPU NVIDIA. Zweryfikuj rozpoznanie GPU:

curl -fsSL https://ollama.com/install.sh | sh
nvidia-smi   # powinno wylistować GPU
ollama --version

Przypisz serwerowi statyczny adres IP w taktycznej sieci LAN (np. 192.168.1.50). Upewnij się, że port 11434 jest osiągalny z hosta TAKpilot. Domyślnie Ollama wiąże się tylko z 127.0.0.1 — aby akceptować połączenia z LAN, ustaw OLLAMA_HOST=0.0.0.0 w środowisku usługi Ollama.

Krok 2: Pobierz model Llama 3.3

# Model 70B — wymaga ~40 GB VRAM (dwa GPU lub A100)
ollama pull llama3.3:70b-instruct-q4_K_M

# Model 8B — mieści się na pojedynczym GPU 8 GB
ollama pull llama3.3:8b-instruct-q4_K_M

Polecenie pull pobiera wagi modelu przez internet. Dla całkowicie izolowanych sieciowo środowisk, gdzie nawet to początkowe pobranie jest zabronione, przenieś plik modelu ręcznie: pobierz plik GGUF na maszynie połączonej z siecią, skopiuj go na serwer przez nośnik wymienny i zaimportuj poleceniem ollama create. Dokumentacja Ollama opisuje procedurę importu offline.

Krok 3: Zweryfikuj punkt końcowy zgodny z OpenAI

# Z hosta TAKpilot
curl http://192.168.1.50:11434/v1/models
# Oczekiwane: {"object":"list","data":[{"id":"llama3.3:70b-instruct-q4_K_M",...}]}

Jeśli żądanie przekroczy limit czasu, sprawdź, czy Ollama jest powiązana z 0.0.0.0 i czy żadna zapora hosta nie blokuje portu 11434.

Krok 4: Skonfiguruj zmienne środowiskowe TAKpilot

# Środowisko .env lub usługi systemd
TAKPILOT_API_BASE=http://192.168.1.50:11434/v1
TAKPILOT_MODEL=llama3.3:70b-instruct-q4_K_M
TAKPILOT_API_KEY=ollama

# Nieustawione lub puste — TAKpilot nie przełączy się awaryjnie na Anthropic
# ANTHROPIC_API_KEY=

Krok 5: Uruchom TAKpilot i potwierdź routing modelu

Uruchom proces Node.js TAKpilot i sprawdź log startowy pod kątem linii backendu modelu. Następnie wyślij polecenie testowe przez interfejs czatu CloudTAK i potwierdź, że odpowiedź jest zwracana. Monitoruj wykorzystanie GPU serwera inferencyjnego za pomocą nvidia-smi dmon, aby zweryfikować, że inferencja działa lokalnie.

Krok 6: Przetestuj użycie narzędzi poleceniem COP

Wyślij ustrukturyzowane polecenie COP: „Wymień wszystkie aktywne jednostki w Kompanii Alfa." TAKpilot powinien wywołać narzędzie list_units CloudTAK i zwrócić sformatowaną odpowiedź. Jeśli model zwróci zwykłą odpowiedź tekstową bez wywołania żadnych narzędzi, oznacza to, że zdolność modelu do podążania za instrukcjami jest niewystarczająca dla schematów wywołań narzędzi TAKpilot — przełącz na wariant 70B lub na Qwen 2.5 72B.

Krok 7: Zweryfikuj, że żaden ruch nie opuszcza granicy sieci

# Na hoście TAKpilot — przechwyć ruch nieprzeznaczony do LAN
tcpdump -i eth0 -n 'not net 192.168.1.0/24 and not net 10.0.0.0/8'

Wyślij kilka poleceń TAKpilot i potwierdź, że w wyniku tcpdump nie pojawiają się żadne pakiety. Cały ruch inferencyjny modelu powinien pozostać w taktycznej sieci LAN. Jeśli zaobserwowano pakiety do zewnętrznych adresów IP, zaudytuj konfigurację środowiska TAKpilot — upewnij się, że TAKPILOT_API_BASE jest poprawnie ustawione, a ANTHROPIC_API_KEY jest nieobecne w środowisku.

Kompromisy wydajnościowe dla typowych zadań COP

Praktyczne różnice wydajności między modelami chmurowymi a brzegowymi szybko stają się widoczne w całym zakresie zadań, które obsługuje TAKpilot. Poniższe charakterystyki opierają się na zaobserwowanym zachowaniu we wdrożeniach TAKpilot, a nie na opublikowanych benchmarkach.

Umieszczanie znaczników i zapytania o jednostki to najczęstsze interakcje z COP. Zarówno Claude Haiku 4.5, jak i Llama 3.3 8B obsługują je dokładnie i przy niskim opóźnieniu. Zadanie jest dobrze ustrukturyzowane — operator mówi, gdzie umieścić znacznik, TAKpilot wywołuje API CloudTAK — i wymaga minimalnego rozumowania. Każdy z modeli jest odpowiedni. Dla wariantu 8B jednoznaczne formaty współrzędnych (stopnie dziesiętne lub MGRS) poprawiają dokładność; model może mieć trudności z niejednoznacznymi odniesieniami do lokalizacji.

Wieloetapowe zarządzanie misją — tworzenie misji, przypisywanie grup, dołączanie pakietu danych i potwierdzanie wyniku — wymaga, by model utrzymywał kontekst przez wiele wywołań narzędzi. Claude Sonnet 4.6 obsługuje to niezawodnie. Llama 3.3 70B obsługuje to z akceptowalną dokładnością. Llama 3.3 8B ma trudności z sekwencjami dłuższymi niż trzy wywołania narzędzi i nie powinna być używana do złożonych przepływów zarządzania misją.

Wywiad z dokumentów i obrazów — przetwarzanie plików PDF, obrazów i raportów wywiadowczych przesłanych do sesji TAKpilot — znacząco zyskuje na większych modelach. Claude Opus 4.7 i Sonnet 4.6 zapewniają najbardziej spójną syntezę dokumentów wielostronicowych. Zadania oparte na wizji (analiza załączników PNG/JPG) wymagają modelu z możliwościami wizyjnymi; Llama 3.3 obsługuje tylko tekst. Do zadań wizyjnych w środowiskach w izolacji sieciowej wymagany byłby LLaVA lub wariant Qwen-VL.

Często zadawane pytania

+Jakie modele AI TAKpilot obsługuje od razu po instalacji?

TAKpilot jest dostarczany z obsługą pełnej rodziny modeli Claude — Opus 4.7, Sonnet 4.6 i Haiku 4.5 — poprzez API Anthropic albo AWS Bedrock i Google Vertex AI. Obsługuje również dowolny model dostępny przez punkt końcowy zgodny z OpenAI, co obejmuje Llama 3.3, Qwen 2.5, Mistral Large oraz każdy inny otwarty model serwowany przez Ollama, vLLM, llama.cpp lub niestandardowy kontener inferencyjny. Aktywny model wybiera się za pomocą zmiennych środowiskowych TAKPILOT_MODEL i TAKPILOT_API_BASE — bez konieczności zmian w kodzie.

+Czy TAKpilot może działać bez połączenia z internetem?

Tak. Ścieżka wdrożenia TAKpilot w izolacji sieciowej kieruje całą inferencję modelu do lokalnego serwera inferencyjnego zgodnego z OpenAI, działającego w tej samej taktycznej sieci LAN lub na tym samym hoście fizycznym. Żaden ruch nie opuszcza sieci. Operatorzy udostępniają model taki jak Llama 3.3 70B lub Qwen 2.5 72B na wzmocnionym serwerze GPU, wystawiają go na prywatnym punkcie końcowym (np. http://192.168.1.50:11434/v1) i ustawiają TAKPILOT_API_BASE na ten adres. TAKpilot łączy się z nim identycznie jak z dostawcą chmurowym — jedyną różnicą jest warstwa transportowa.

+Jak TAKpilot zapewnia, że dane operatora nie opuszczają sieci?

TAKpilot egzekwuje piaskownicę przypisaną do sesji dla wszystkich danych operatora. Każda sesja operatora otrzymuje izolowany kontekst, który nigdy nie jest zapisywany na dysku ani współdzielony między sesjami. Gdy operator się rozłącza, kontekst sesji — w tym wszystkie wiadomości, wyniki wywołań narzędzi i odwołania do COP — jest usuwany z pamięci. Dla modeli hostowanych w chmurze (Claude przez API Anthropic) obowiązują korporacyjne polityki danych Anthropic; dla wdrożeń w izolacji sieciowej z modelami lokalnymi dane nigdy nie opuszczają taktycznej sieci LAN, ponieważ punkt końcowy inferencji jest lokalny. Operatorzy obsługujący zadania objęte klauzulą tajności powinni zawsze wdrażać TAKpilot w trybie izolacji sieciowej z lokalnie hostowanym modelem.

+Jakie są wymagania sprzętowe do uruchomienia Llama 3.3 70B na taktycznym serwerze brzegowym?

Llama 3.3 70B w kwantyzacji 4-bitowej (GGUF Q4_K_M) wymaga około 40 GB pamięci VRAM. Pojedyncza karta NVIDIA RTX 4090 (24 GB) jest niewystarczająca przy pełnej precyzji; do pełnej inferencji modelu o 70B parametrach zalecany jest układ z dwoma GPU lub serwerowa karta A100/H100. Dla bardziej ograniczonego sprzętu taktycznego Llama 3.3 8B (Q4_K_M, ~5 GB VRAM) lub Qwen 2.5 7B zapewniają akceptowalną wydajność na pojedynczym konsumenckim GPU. Szybkość inferencji dla 70B na A100 wynosi około 25–40 tokenów na sekundę, co wystarcza do konwersacyjnych interakcji z COP przy akceptowalnym opóźnieniu.

+Czy TAKpilot może przełączać modele w trakcie operacji bez restartu serwera?

Wybór modelu w bieżącym wydaniu TAKpilot ustawiany jest przy starcie za pomocą zmiennych środowiskowych i dotyczy wszystkich sesji. Przełączanie modeli „na gorąco" bez restartu serwera nie jest obsługiwane w konfiguracji bazowej. Ponieważ jednak TAKpilot jest oprogramowaniem open-source na licencji AGPL-3.0, wdrażający, którzy potrzebują wyboru modelu na poziomie sesji, mogą rozszerzyć API konfiguracji. Powszechnym wzorcem dla środowisk wieloklauzulowych jest uruchomienie dwóch instancji TAKpilot na osobnych portach — jednej połączonej z chmurowym punktem końcowym Claude do pracy bez klauzuli tajności, drugiej połączonej z lokalnym punktem końcowym Llama do operacji objętych klauzulą — i kierowanie operatorów do odpowiedniej instancji przez reverse proxy.

Powiązana lektura: Aby zapoznać się z wprowadzeniem do pełnego zestawu możliwości TAKpilot, w tym poleceń COP w języku naturalnym, wywiadu wizyjnego i strumieniowych kart narzędzi, zob. Kopiloty AI dla aplikacji taktycznych i NLP. Aby poznać API CloudTAK, którego TAKpilot używa do wykonywania poleceń operatora, zob. Integracja REST API CloudTAK. Aby postawić bazową infrastrukturę serwera CloudTAK, zob. przewodnik wdrożenia serwera CloudTAK.