LLM-інференс на військовому граничному обладнанні: запуск мовних моделей у відключених середовищах

Великі мовні моделі, що працюють повністю на локальному граничному вузлі — без інтернету, без хмарного API, без виходу даних за межі платформи — більше не є дослідницькою цікавинкою. Це операційна реальність для оборонних програм, яким потрібна AI-підтримка командування та управління, зведення розвідувальних даних або підтримка автономних рішень у середовищах, де підключення є вразливістю, а не перевагою. Ця стаття охоплює повний стек: чому хмарні LLM тактично провалюються, яке обладнання та моделі обирати, як ефективно квантувати та обслуговувати їх і як захистити сервіс інференсу на засекреченому граничному вузлі.

1. Проблема підключення

Хмарні LLM на кшталт GPT-4o або Claude Sonnet передбачають стабільне широкосмугове підключення з низькою затримкою. У тактичних умовах це припущення порушується щонайменше трьома структурно різними способами. EMCON (контроль випромінювання) забороняє будь-які радіопередачі для уникнення електронного виявлення. Пропускна здатність MANET становить 1–10 Мбіт/с у сукупності з високою затримкою, легко перенасичуючись паралельними викликами LLM API. Заблоковані комунікації — радіоелектронне придушення, маскування рельєфом або навмисна мережева ізоляція — означають, що позиція з пригніченим GPS і зв'язком потребує AI-допомоги саме тоді, коли хмарне підключення найменш доступне. Крім того, маршрутизація конфіденційних оперативних даних через комерційні хмарні API створює ризики OPSEC та класифікаційні ризики, що часто недозволені для засекречених або чутливих робочих навантажень.

2. Рівні обладнання для граничного LLM-інференсу

NVIDIA Jetson Orin NX 16GB є основною рекомендацією: 16 ГБ LPDDR5 зі швидкістю 102 ГБ/с, 1024 ядра CUDA, бекенд CUDA для llama.cpp, 12–18 токенів/с для Llama 3.1 8B Q4_K_M, 15–20 Вт. Промисловий температурний діапазон, захищені несучі плати, оборонний ланцюг постачання. Hailo-10 пропонує 40 TOPS при споживанні менше 5 Вт — виняткові показники для вузлів з обмеженим живленням, хоча зрілість інструментального ланцюга LLM ще розвивається. Intel Arc A770 16GB забезпечує 20–30 токенів/с при 30–35 Вт для транспортних або стаціонарних граничних серверів. CPU-only ARM досягає 3–6 токенів/с на Llama 3.1 8B — повільно, але повністю офлайн і придатно для пакетних або асинхронних завдань.

3. Вибір моделі: Llama, Qwen, Mistral

Llama 3.1 8B (Apache 2.0): ~73% MMLU, контекст 128K, надійне дотримання інструкцій, 12–18 токенів/с на Orin NX. Базова рекомендація. Qwen2.5 7B (Apache 2.0): ~74,2% MMLU, краща багатомовна продуктивність для коаліційного використання — зверніть увагу на китайське походження при проверці джерел для засекречених програм. Mistral 7B v0.3 (Apache 2.0): ~63% MMLU, найменший KV-кеш, найкращий для вузлів лише з CPU, де критична пропускна здатність. Усі три доступні у форматі GGUF на Hugging Face для передачі з повітряним зазором.

4. Конвеєр квантування

GGUF (llama.cpp) є стандартом для граничного розгортання — портативний для CPU, змішаного та GPU інференсу. Q4_K_M: ~4,9 ГБ для 8B-моделей, 1–3% втрати якості порівняно з FP16, стандартний тактичний вибір. Q8_0: ~8,5 ГБ, майже без втрат, переважний за наявності пам'яті. Уникайте Q2/Q3 для структурованого виводу або багатокрокових завдань міркування. AWQ орієнтований на GPU-інференс NVIDIA з кращою якістю INT4 порівняно з наївним квантуванням — використовуйте з vLLM на потужніших граничних серверах. GPTQ є старішим стандартом з широким інструментарієм; AWQ є кращим вибором для нових GPU-розгортань.

5. Середовища виконання інференсу

llama.cpp з HTTP-сервером є правильним стандартом для граничних вузлів з одним користувачем. Ollama обгортає llama.cpp REST API та CLI — вимкніть автозавантаження на вузлах з повітряним зазором, запускайте як виділений непривілейований користувач. vLLM (лише NVIDIA) додає PagedAttention і безперервне пакетування для граничних серверів з кількома користувачами (10+ одночасних користувачів). ExLlamaV2 досягає 30–40 токенів/с на Orin AGX з квантуванням EXL2 — максимальна пропускна здатність одного GPU, але складніший інструментальний ланцюг.

6. Граничний режим TAKpilot

TAKpilot постійно стежить за підключенням і маршрутизує до Claude Sonnet (хмара), коли доступний висхідний канал, автоматично перемикаючись на локальний Llama 8B при EMCON або втраті підключення — затримка перемикання менше 200 мс, без перезапуску, той самий REST-інтерфейс. Граничний режим автоматично скорочує системні підказки, активує обмежений граматикою вивід JSON та обмежує довжину відповіді.

7. Інжиніринг підказок для обмежених моделей

Тримайте системні підказки до 200 токенів. Забезпечуйте структурований вивід за допомогою граматичних обмежень GBNF (llama.cpp) або параметра формату Ollama, плюс валідація JSON на рівні застосунку з 2–3 спробами повтору, що передають помилки назад як підказки для виправлення. Розміщуйте приклади few-shot у повідомленні користувача, а не в системній підказці, для кращої ефективності токенів і відповідності формату в менших моделях.

8. Безпека для граничного розгортання LLM

Чотири обов'язкові засоби контролю: (1) перевірка цілісності SHA-256 файлів моделей при кожному завантаженні; (2) виділений непривілейований користувач ОС з політикою AppArmor/SELinux, що ізолює сервіс інференсу; (3) захищений від підробки журнал аудиту кожного запиту та відповіді; (4) вихідний мережевий трафік вимкнений на вузлах з повітряним зазором через iptables з прив'язкою до UID сервісу. Ці засоби контролю відповідають NIST SP 800-53 і підтримують документацію ATO.