Wnioskowanie AI przy ograniczonej mocy na taktycznej krawędzi sieci

Każdy system wnioskowania AI, który opuszcza centrum danych i wkracza w środowisko taktyczne, napotyka tę samą barierę: sprzęt zapewniający najlepszą dokładność modelu pobiera moc, której platforma nie może dostarczyć, i generuje ciepło, którego obudowa nie może odprowadzić. SWaP-C — rozmiar, masa, moc i koszt — nie jest drugorzędnym zagadnieniem inżynieryjnym na taktycznej krawędzi sieci; jest to podstawowe ograniczenie projektowe, z którego wynikają wszystkie pozostałe decyzje. Artykuł obejmuje pełny łańcuch inżynieryjny: od definiowania budżetu SWaP-C, przez dobór sprzętu, strategię kwantyzacji, metodologię profilowania mocy, wybór środowiska uruchomieniowego, zarządzanie cieplne, aż po projektowanie budżetu mocy dla konkretnej misji w wojskowych wdrożeniach AI.

SWaP-C: dlaczego masa i moc ważą więcej niż surowe TOPS na krawędzi sieci

Hierarchia ograniczeń taktycznej krawędzi sieci stawia TOPS na ostatnim miejscu, nie na pierwszym. Zanim projektant systemu zacznie myśleć o liczbie tera-operacji na sekundę, które układ może wykonać, musi odpowiedzieć na trzy wcześniejsze pytania: czy układ mieści się w dostępnej objętości, czy jego masa nie przekroczy limitu ładunku platformy i czy pobór mocy nie przekracza możliwości baterii lub alternatora? Dopiero gdy wszystkie trzy odpowiedzi brzmią "nie", przepustowość staje się istotna.

Rozmiar ogranicza integrację fizyczną. Moduł Jetson AGX Orin ma wymiary 100 mm × 87 mm i wymaga płyty nośnej, która dodaje kolejne 15–20 mm w osi Z. Przenośny zestaw obliczeniowy żołnierza piechoty, sterownik wieżyczki małego kalibru czy komora naprowadzania amunicji krążącej mogą mieć do dyspozycji jedynie objętość 60 × 60 × 25 mm dla dodatkowego układu obliczeniowego. W takim przypadku akcelerator Hailo-8 M.2 o wymiarach 34 mm × 26 mm mieści się tam, gdzie AGX Orin nie.

Masa kumuluje się w całym systemie. Moduł wnioskowania o masie 300 g dodany do wyposażenia żołnierza piechoty dołącza do obciążenia, które może już wynosić 35–45 kg. Programy ergonomii wojskowej przyjmują 30% masy ciała jako maksymalny próg obciążenia długotrwałego; każdy gram sprzętu do wnioskowania AI konkuruje z amunicją, wodą i sprzętem łączności o przydział poniżej tego limitu. Na BSP dodana masa skraca czas lotu, zwiększając moc potrzebną do utrzymania wysokości — tworzy to podwójną karę: większa masa pobiera więcej mocy baterii na napęd, a dla ładunku pozostaje mniej energii.

Moc jest najbardziej bezwzględnym ograniczeniem, ponieważ jej przekroczenie to nie tylko problem wydajności — może zakończyć misję. Alternator pojazdu naziemnego ma stałą moc wyjściową; bateria BSP ma stałą pojemność. Gdy podsystem wnioskowania AI, radio łączności, zestaw czujników i systemy pojazdu łącznie przekraczają dostępną moc, jednostka dystrybucji zasilania odcina odbiorniki według priorytetu. Wnioskowanie AI rzadko jest odbiornikiem o najwyższym priorytecie. System zaprojektowany do ciągłej pracy działa przerywanego lub wcale.

Koszt determinuje doktrynę zużycia, która z kolei ogranicza dobór sprzętu. Zestawu deweloperskiego Jetson AGX Orin za 3 000 USD nie można instalować na jednorazowej amunicji krążącej przeznaczonej do jednorazowego użytku. Ograniczenie kosztów nie jest czysto ekonomiczne — wpływa również na logistykę, ponieważ drogie moduły obliczeniowe wymagają bezpiecznych łańcuchów dostaw, kontrolowanego przechowywania i procedur ewidencji, które spowalniają cykle uzupełniania zapasów na polu walki.

Właściwą miarą jakości sprzętu AI na taktycznej krawędzi sieci jest zatem użyteczna przepustowość wnioskowania na wat na centymetr sześcienny na dolar — wielowymiarowa efektywność, której żadna pojedyncza liczba TOPS nie oddaje. Szczegółowe porównanie czołowych platform pod kątem tej złożonej metryki opisuje nasz artykuł na temat doboru sprzętu edge AI dla obronności.

Krajobraz akceleratorów AI: Jetson, Hailo, Coral, Qualcomm — porównanie szczytowego TOPS, trwałej przepustowości i obwiedni mocy

Cztery rodziny układów scalonych obejmują praktyczny zakres wdrożeń na taktycznej krawędzi sieci. Zrozumienie pozycji każdej z nich na krzywej TOPS/W i kompromisów architektonicznych, jakie reprezentuje, jest warunkiem wstępnym każdej decyzji o wyborze platformy.

Mocną stroną rodziny Jetson jest ekosystem oprogramowania: pełny Linux, CUDA, TensorRT oraz bogaty zbiór narzędzi open-source do wnioskowania. Mocną stroną Hailo-8 jest surowa efektywność energetyczna na poziomie akceleratora — jego architektura przepływu danych rozkłada graf sieci neuronowej na klastry procesorów i wykonuje go potokowo, minimalizując dostęp do pamięci DRAM, który jest dominującym kosztem energetycznym przy wnioskowania na konwencjonalnym GPU. Coral Edge TPU to najprostsza ścieżka integracji dla zespołów korzystających z TFLite, lecz jego pułap 4 TOPS i rygorystyczne wymagania kompilacji grafów ograniczają go do mniejszych modeli. Układ SoC Qualcomm QCS8550 łączy CPU, GPU i Hexagon NPU na jednym krzemie, osiągając doskonały stosunek TOPS/W w obudowie wywodzącej się ze smartfonów, coraz częściej trafiając do ręcznych urządzeń wojskowych. Szczegółowe porównanie tych platform zawiera nasz artykuł o porównaniu sprzętu edge AI.

Trwała przepustowość znacząco odbiega od szczytowego TOPS w rzeczywistych warunkach pracy. Liczby szczytowego TOPS są mierzone przy 100% wykorzystaniu ścieżki danych i idealnych wzorcach dostępu do pamięci. Rzeczywiste obciążenia wnioskowania na architekturach YOLOv8 lub RT-DETR często osiągają zaledwie 50–70% szczytowego TOPS, ponieważ mieszanina operatorów modelu — warstwy konwolucyjne, normalizacja wsadowa, funkcje aktywacji i wieloskalowe przetwarzanie wyjścia głowicy detekcyjnej — nie zajmuje wszystkich jednostek wykonawczych jednocześnie. Przed zatwierdzeniem platformy w projekcie należy wykonać testy porównawcze z użyciem rzeczywistego modelu.

Strategie kwantyzacji: INT8, INT4, FP16 — kompromisy dokładności i mocy, PTQ a QAT, kwantyzacja per-kanał a per-tensor

Kwantyzacja to pojedyncza, najbardziej efektywna technika programowa zmniejszająca moc wnioskowania na taktycznej krawędzi sieci. Obniżenie precyzji numerycznej z FP32 do INT8 redukuje ślad pamięciowy modelu czterokrotnie i proporcjonalnie zmniejsza zapotrzebowanie na przepustowość DRAM — a ponieważ dostęp do DRAM jest często dominującym poborem mocy przy wnioskowania, przekłada się to bezpośrednio na niższe zużycie energii, niezależnie od oszczędności obliczeniowych.

FP16 (16-bitowy zmiennoprzecinkowy) to opcja najmniej agresywna. Zmniejsza ślad pamięciowy o połowę względem FP32 i jest natywnie obsługiwana przez wszystkie nowoczesne akceleratory AI, w tym rdzenie tensor Jetson GPU. Utrata dokładności jest znikoma — zazwyczaj poniżej 0,2 mAP na standardowych testach porównawczych detekcji — ponieważ zredukowany zakres dynamiczny FP16 rzadko obcina istotne wartości wag w dobrze wytrenowanym modelu. FP16 jest właściwym ustawieniem domyślnym przy pierwszym wdrożeniu nowego modelu, gdy tolerancja na ryzyko dokładności jest niska, a oszczędność mocy z INT8 nie jest wymagana do spełnienia budżetu SWaP-C.

INT8 jest produkcyjnym standardem dla wojskowych wdrożeń na krawędzi sieci o ograniczonej mocy. Sprzęt z jednostkami wykonawczymi INT8 — Jetson Orin, Hailo-8, Coral Edge TPU — zapewnia 2–4-krotną poprawę przepustowości względem FP32 przy tej samej pojemności modelu, z typową utratą dokładności rzędu 0,5–2 mAP. Wpływ na dokładność zależy silnie od jakości kalibracji. Kwantyzacja po treningu (PTQ) kalibruje współczynniki skalowania INT8, uruchamiając model FP32 na zbiorze kalibracyjnym i rejestrując rozkład aktywacji w każdej warstwie. Wybór zbioru kalibracyjnego jest krytyczny: należy kalibrować na obrazach z czujnika wdrożenia i na odpowiedniej wysokości, a nie na ogólnodostępnym publicznym zbiorze lotniczym — w przeciwnym razie rozkłady aktywacji będą niedopasowane, a utrata dokładności będzie wyższa niż sugerują liczby z testów porównawczych.

Kwantyzacja z uwzględnieniem treningu (QAT) wstawia symulowany szum kwantyzacji do grafu treningowego, aby optymalizator dostosował wagi tak, by były odporne na zaokrąglenia INT8. QAT konsekwentnie przewyższa PTQ o 1–3 mAP, z największymi zyskami na małych modelach, gdzie wariancja wag per-kanał jest wyższa. Koszt to przebieg dostrajania 10–50 epok — zazwyczaj 6–24 godziny na GPU treningowym — i dostęp do oryginalnego zbioru treningowego. W programach, gdzie dokładność ma twardy próg związany z wymaganiem prawdopodobieństwa wykrycia, QAT jest właściwym podejściem. Przy szybkim prototypowaniu lub w sytuacjach po przekazaniu, gdy zbiór treningowy jest niedostępny, kalibrowana PTQ ze współczynnikami skalowania per-kanał jest praktyczną alternatywą.

Kwantyzacja per-kanał a per-tensor to wybór kalibracyjny, który znacząco wpływa na dokładność w modelach konwolucyjnych. Kwantyzacja per-tensor przypisuje jeden współczynnik skalowania do całego tensora wag warstwy; per-kanał przypisuje niezależny współczynnik skalowania każdemu kanałowi wyjściowemu. Różnica ma znaczenie, ponieważ filtry konwolucyjne w dojrzałych modelach detekcji mają zasadniczo różne normy L2 w poszczególnych kanałach. Wymuszenie jednego współczynnika skalowania dla wszystkich kanałów powoduje duże błędy zaokrąglenia w filtrach o wysokiej normie. Kwantyzacja per-kanał zachowuje dokładność kosztem nieco większej tabeli kalibracyjnej. Narzędzia TensorRT i PyTorch obsługują kwantyzację wag per-kanał; nie ma inżynierskiego powodu, by w 2026 roku wybierać kwantyzację per-tensor dla wag.

Kwantyzacja INT4 pakuje dwie wartości na bajt i osiąga do 8-krotnej kompresji względem FP32, jednak utrata dokładności rzędu 3–8 mAP na testach detekcji sprawia, że jest nieodpowiednia dla większości zastosowań taktycznych bez QAT. Jej podstawowym przypadkiem użycia jest wnioskowanie bardzo dużych modeli językowych, gdzie przepustowość DRAM, a nie obliczenia, jest wiążącym ograniczeniem. Dla aplikacji ISR obrony i detekcji celów uruchamiających modele klasy YOLOv8 INT8 jest praktycznym punktem operacyjnym.

# Kalibracja TensorRT INT8 — przykładowy fragment
import tensorrt as trt

class Int8Calibrator(trt.IInt8EntropyCalibrator2):
    def __init__(self, calibration_images, cache_file):
        super().__init__()
        self.cache_file = cache_file
        self.dataset = calibration_images   # 500+ obrazów z domeny wdrożenia
        self.index = 0

    def get_batch(self, names):
        if self.index >= len(self.dataset):
            return None
        batch = preprocess(self.dataset[self.index])
        self.index += 1
        return [cuda.memcpy_htod_async(d_input, batch, stream)]

    def get_calibration_cache(self):
        if os.path.exists(self.cache_file):
            with open(self.cache_file, 'rb') as f:
                return f.read()
        return None

# Buduj silnik INT8
config.set_flag(trt.BuilderFlag.INT8)
config.int8_calibrator = Int8Calibrator(calib_images, 'calib.cache')
# Kwantyzacja per-kanał jest domyślna w TRT 9+

Metodologia profilowania mocy — oprzyrządowanie pomiarowe, moc dynamiczna a statyczna, dławienie termiczne w środowiskach MILSPEC

Programowe szacunki mocy z interfejsów API dostawców są przydatne do monitorowania trendów, ale niewystarczające do walidacji budżetu mocy na poziomie systemu. Jedynym wiarygodnym źródłem prawdy jest pomiar prądu inline na sprzętowych szynach zasilających akcelerator AI. Rozbieżność między mocą zgłaszaną przez oprogramowanie a mocą zmierzoną może sięgać 15–25% na platformach Jetson podczas trwałego wnioskowania, ponieważ oprogramowanie sprzętowe zarządzające ciepłem reguluje częstotliwości taktowania w sposób, który nie zawsze odzwierciedla się w chwilowych odczytach API.

Standardowe podejście do oprzyrządowania wbudowanych platform AI stosuje wzmacniacze prądowe INA3221 lub INA226 umieszczone szeregowo z linią zasilającą każdej szyny mocy, odczytywane przez I2C z częstotliwością 100–200 Hz. Na platformie Jetson Orin NVIDIA udostępnia wbudowane czujniki INA3221 poprzez sysfs:

# Odczyt szyn zasilania Jetson Orin przez sysfs (próbkowanie co 100 ms)
RAILS=(
  "/sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon1"  # VDD_GPU_SOC
  "/sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon2"  # VDD_CPU_CV
  "/sys/bus/i2c/drivers/ina3221/1-0041/hwmon/hwmon3"  # VIN_SYS_5V0
)
while true; do
  ts=$(date +%s%N)
  for rail in "${RAILS[@]}"; do
    pwr=$(cat "$rail/power1_input" 2>/dev/null)  # mikrowaty
    echo "$ts,$rail,$pwr"
  done
  sleep 0.1
done >> /var/log/power_trace.csv

Moc statyczna (czuwanie) to bazowy pobór przy załadowanym modelu w pamięci akceleratora i działającym potoku wnioskowania, ale bez przetwarzanych ramek. Dla Jetson Orin Nano w trybie 7 W moc w trybie czuwania wynosi około 1,5–2,0 W. Jest to podłoga, poniżej której system nigdy nie schodzi podczas aktywnej usługi wnioskowania. W modelu cyklu pracy moc w trybie czuwania pomnożona przez czas czuwania wyznacza minimalny koszt energetyczny utrzymania gotowości systemu wnioskowania.

Moc dynamiczna (aktywne wnioskowanie) to przyrostowy pobór ponad poziom czuwania podczas aktywnego przetwarzania ramek. Różnica między mocą w trybie czuwania a mocą aktywną reprezentuje koszt energetyczny każdego cyklu wnioskowania. Dla Jetson Orin Nano uruchamiającego YOLOv8s INT8 z szybkością 15 kl./s moc dynamiczna powyżej czuwania wynosi około 4–6 W, co daje łącznie 5,5–8 W podczas serii wnioskowania.

Dławienie termiczne jest najbardziej niebezpiecznym scenariuszem profilowania mocy do pominięcia w programie testów MILSPEC. Wszystkie nowoczesne akceleratory AI mają oprogramowanie sprzętowe, które redukuje częstotliwości taktowania, gdy temperatura złącza zbliża się do znamionowego maksimum. Na platformach Jetson zarządza tym środowisko zarządzania ciepłem i dławienie zaczyna się 5–10°C poniżej limitu złącza. W środowisku MILSPEC, gdzie obudowa może osiągnąć +70°C otoczenia, układ o temperaturze złącza 85°C ma jedynie 15°C budżetu termicznego od otoczenia do złącza. Jeśli rezystancja cieplna od złącza do otoczenia przekracza 15°C/W, a układ rozprасza 10 W, temperatura złącza nie może ustabilizować się poniżej limitu — dławienie zaczyna się natychmiast i utrzymuje bezterminowo. Profilowanie mocy musi być przeprowadzane w maksymalnej oczekiwanej temperaturze otoczenia z zainstalowanym sprzętem w produkcyjnej obudowie.

Dobór systemu operacyjnego i środowiska uruchomieniowego dla efektywności energetycznej — bare-metal a RTOS a Linux, TensorRT a ONNX Runtime a TFLite

Wybór środowiska operacyjnego bezpośrednio wpływa na moc w trybie czuwania. Pełna dystrybucja Linux ze środowiskiem graficznym, usługami działającymi w tle i stosem rejestrowania pobiera znacznie więcej mocy w trybie czuwania niż minimalny Linux z jedynie usługą wnioskowania i jej zależnościami. Wdrożenia bare-metal lub RTOS mogą jeszcze bardziej obniżyć moc w trybie czuwania, eliminując planistę OS i podsystemy jądra, lecz rezygnują z kompatybilności łańcucha narzędzi, która sprawia, że wdrażanie i aktualizacja modeli jest praktyczna w programie operacyjnym.

Dla platform Jetson zalecaną ścieżką jest minimalny Linux (Ubuntu Server lub BSP pochodny od Yocto) skonfigurowany do rozruchu właściwego dla celu. Należy wyłączyć usługi systemd niewymagane do operacji wnioskowania: usunąć menedżera wyświetlania, demon NetworkManager (jeśli platforma używa stałej konfiguracji sieciowej), wszelkich agentów telemetrii chmury i Bluetooth, jeśli sprzęt go obsługuje. Usługa nvpmodel powinna być zachowana i ustawiona na najniższy tryb mocy spełniający wymaganie opóźnienia wnioskowania przy szybkości ramek misji. Właściwie odchudzony Jetson Orin Nano uruchamiający jedynie usługę wnioskowania, daemon SSH i minimalny proces rejestrowania ma moc w trybie czuwania około 1,2–1,8 W, wobec 2,5–3,5 W dla domyślnego obrazu deweloperskiego.

Wybór środowiska uruchomieniowego determinuje, jak skwantyzowany graf modelu jest kompilowany do instrukcji sprzętowych w czasie ładowania lub z wyprzedzeniem. TensorRT to najwydajniejsze środowisko uruchomieniowe dla sprzętu NVIDIA Jetson. Scala sąsiednie jądra operatorów, wybiera najszybszy wariant algorytmu dla każdej warstwy przy danej precyzji i rozmiarze wsadu oraz w pełni wykorzystuje możliwości rdzeni tensor GPU Jetson. Model YOLOv8s skompilowany do pliku silnika TensorRT INT8 działa z szybkością 30–45 kl./s przy 7–9 W na Jetson Orin Nano; ten sam model w ogólnej sesji ONNX Runtime bez backendu TensorRT działa z szybkością 12–18 kl./s przy 10–14 W. Różnica w mocy nie jest przypadkowa — fuzja jąder TensorRT zmniejsza liczbę rund dostępu do DRAM na jedno wnioskowanie, a dostęp do DRAM jest dominującym kosztem mocy.

ONNX Runtime z TensorRT Execution Provider jest zalecaną opcją dla programów, które muszą obsługiwać zarówno sprzęt Jetson, jak i akceleratory inne niż NVIDIA z tej samej bazy kodu. API ONNX Runtime abstrahuje backend sprzętowy, a TensorRT EP obsługuje kompilację i wykonanie na Jetsonie, podczas gdy inny EP (DirectML, ogólny CUDA, CPU) obsługuje wykonanie na innych platformach. Korzyść z przenośności wiąże się z marginalnym kosztem wydajności względem bezpośredniego użycia TensorRT, zazwyczaj 5–10% redukcją przepustowości.

TFLite z delegatem Edge TPU jest właściwym środowiskiem uruchomieniowym dla platform Coral. Kompiluje graf modelu do wbudowanej pamięci SRAM Edge TPU w czasie ładowania; operacje, których nie można odwzorować na Edge TPU, wykonują się na procesorze hosta. Odsetek modelu, który wraca do CPU, jest głównym czynnikiem zarówno opóźnienia, jak i efektywności energetycznej — model z 10% awarią CPU może pobierać 2–3 razy więcej mocy niż model w pełni wykonywany na chipie, ponieważ procesor hosta pobiera znacznie więcej mocy na operację niż dedykowany sprzęt Edge TPU. Należy użyć dziennika kompilacji edgetpu_compiler, aby zidentyfikować operacje nieodwzorowane na sprzęcie i zmodyfikować architekturę modelu, by zastąpić je odpowiednikami zgodnymi z Edge TPU, przed wdrożeniem produkcyjnym.

Zarządzanie cieplne w obudowach MILSPEC — rozpraszacze ciepła, chłodzenie przewodzące, zakres operacyjny od -40°C do +85°C

Obudowy MILSPEC dla elektroniki taktycznej zazwyczaj określają operacyjny zakres temperatur od -40°C do +85°C zgodnie z metodą 501/502 normy MIL-STD-810. Dolna i górna granica stwarzają przeciwne wyzwania inżynierii cieplnej. W -40°C urządzenia krzemowe mogą nie uruchomić się niezawodnie bez wstępnego kondycjonowania; w +85°C otoczenia pasywne odprowadzanie ciepła jest marginalne dla każdego akceleratora AI rozpraszającego więcej niż 3–4 W.

Chłodzenie przewodzące jest dominującym mechanizmem odprowadzania ciepła w szczelnych obudowach MILSPEC, gdzie konwekcyjny przepływ powietrza jest wykluczony przez klasę ochrony IP. Ścieżka cieplna prowadzi od złącza akceleratora AI przez obudowę pakietu, przez materiał interfejsu termicznego (TIM), przez płytę rozpraszającą ciepło, przez ścianę obudowy i wreszcie do środowiska zewnętrznego poprzez naturalną konwekcję i promieniowanie. Każdy interfejs materiałowy dodaje rezystancję cieplną, a suma wszystkich rezystancji determinuje wzrost temperatury od złącza do otaczającego powietrza.

Budżet rezystancji cieplnej — Hailo-8 w szczelnej obudowie aluminiowej
=======================================================================
Złącze → obudowa pakietu (Hailo-8):     2,0 °C/W
Obudowa → TIM (podkładka fazowa, 1 mm): 0,5 °C/W
TIM → rozpraszacz (Al 6061, 3 mm):      0,3 °C/W
Rozpraszacz → ściana obudowy:           1,0 °C/W
Ściana obudowy → otoczenie (150 cm²):   4,5 °C/W
                                        ─────────
Całkowita R_th (złącze→otoczenie):      8,3 °C/W

Przy P_diss = 5 W, ΔT = 8,3 × 5 = 41,5 °C
Przy T_otoczenia = 71°C (MIL): T_złącza = 71 + 41,5 = 112,5 °C
Maks. złącze Hailo-8: 125 °C → margines 12,5 °C ✓

Dobór materiału rozpraszacza ciepła ma istotne znaczenie. Aluminium 6061 ma przewodność cieplną około 167 W/m·K i jest standardowym stopem konstrukcyjnym w lotnictwie. Miedź (385 W/m·K) zapewnia 2,3 razy lepszą przewodność cieplną i jest stosowana tam, gdzie rozpraszacz musi pokonać większy obszar między obudową układu a ścianą obudowy. Pyrolowe arkusze grafitowe (700–1500 W/m·K w płaszczyźnie) stosuje się w najbardziej wymagających zastosowaniach, gdzie aluminium nie spełnia budżetu cieplnego, lecz są kruche i wymagają ochrony przed drganiami i obciążeniami udarowymi — istotna kwestia w zastosowaniach pojazdów opancerzonych lub zrzucanych z powietrza. Dla większości taktycznych obudów AI pracujących z akceleratorami klasy Hailo-8 lub Coral, aluminiowa płyta o grubości 3–5 mm między modułem a ścianą obudowy jest wystarczająca, jeśli obudowa ma co najmniej 100–150 cm² zewnętrznej powierzchni do naturalnej konwekcji.

Zimny rozruch w -40°C wymaga, aby płyta była zasilana grzejnikami przed przyłożeniem obciążenia obliczeniowego. Moduły Jetson COTS są znamionowane do -25°C (wariant przemysłowy) dla przechowywania i pracy; niektóre warianty wojskowe rozszerzają zakres do -40°C. Poniżej dolnej granicy znamionowej kondensatory wewnętrzne mogą nie ładować się prawidłowo, a pamięć flash może się nie inicjalizować. Sterowany termostatem grzejnik rezystancyjny pobierający 3–5 W z baterii platformy — włączający się automatycznie, gdy temperatura obudowy spada poniżej -20°C — jest prostszym i bardziej niezawodnym rozwiązaniem niż oczekiwanie, aż dostawcy układów określą pracę w -40°C. Grzejnik powinien być umieszczony między ścianą obudowy a płytą obliczeniową, aby zapewnić, że temperatura płyty osiągnie minimalną znamionową temperaturę pracy przed przyłożeniem głównego zasilania.

Testy cieplne muszą być przeprowadzane z produkcyjną obudową i produkcyjną konfiguracją montażu. Testy na stole z otwartą płytą nośną w komorze cieplnej wykażą niższe temperatury złącza niż konfiguracja produkcyjna, ponieważ wymuszona konwekcja wentylatora komory pomaga chłodzić płytę w sposób, którego szczelna obudowa nie może replikować. Zawsze należy testować w konfiguracji najgorszego przypadku — szczelna obudowa, maksymalny cykl pracy wnioskowania, maksymalna temperatura otoczenia — i dokumentować stacjonarną temperaturę złącza w tych warunkach jako część rekordu kwalifikacji systemu.

Projektowanie budżetu mocy dla konkretnej misji — modelowanie cyklu pracy, częstotliwość wnioskowania a czas pracy baterii, tryby mocy powiązane ze stanem zagrożenia

System zaprojektowany do szczytowej wydajności wnioskowania przez całą misję albo rozładuje baterię przed jej zakończeniem, albo będzie musiał przenosić większą baterię, która dodaje masę i koszty. Żaden z tych wyników nie jest optymalny. Właściwe podejście projektowe łączy częstotliwość wnioskowania ze stanem operacyjnym, uruchamiając akcelerator AI przy wysokim cyklu pracy tylko wtedy, gdy sytuacja taktyczna tego wymaga, i redukując cykl pracy — lub wchodząc w stan niskiego poboru — podczas faz, gdy pełne wnioskowanie jest zbędne.

Modelowanie cyklu pracy zaczyna się od profilu misji: szeregowanej chronologicznie sekwencji faz operacyjnych z szacowanym czasem trwania i powiązanymi stanami zagrożenia. Misja pojazdu naziemnego może obejmować fazę tranzytu (60 minut, niskie zagrożenie, ruch wzdłuż bezpiecznej trasy), fazę podejścia (20 minut, podwyższone zagrożenie, wejście na nieznane terytorium) i fazę obserwacji (40 minut, wysokie zagrożenie, obserwacja stacjonarna). Każda faza ma inne wymaganie dotyczące wnioskowania: 2 kl./s podczas tranzytu, 10 kl./s podczas podejścia, 15 kl./s podczas obserwacji. Pobór mocy w każdej fazie to suma mocy w trybie czuwania plus (moc aktywnego wnioskowania × ułamek cyklu pracy wnioskowania).

Tabela ilustruje, że zarządzanie cyklem pracy redukuje zużycie energii wnioskowania AI o 42% w stosunku do ciągłej pracy z maksymalną szybkością ramek — z 20 Wh do 11,5 Wh dla 160-minutowej misji na platformie klasy Hailo-8. W systemie z przydziałem baterii podsystemu AI wynoszącym 40 Wh, zarządzane podejście wydłuża czas pracy baterii ze 120 minut do 210 minut, co może być różnicą między platformą kończącą misję a taką, która traci zdolność AI w ostatniej fazie.

Przejścia między trybami mocy powinny być sterowane przez maszynę stanów operacyjnych platformy, a nie przez ręczny wkład załogi, ponieważ obciążenie poznawcze załogi w środowiskach wysokiego zagrożenia sprawia, że ręczne zarządzanie jest zawodne. Wejścia maszyny stanów obejmują prędkość pojazdu (powyżej 15 km/h sugeruje tryb tranzytu), status systemu uzbrojenia (uzbrojony sugeruje podwyższone zagrożenie), geofencing GPS względem znanych obszarów zagrożenia i wyraźne polecenia nadrzędne dowódcy. Menedżer wnioskowania AI otrzymuje przejścia stanów jako zdarzenia i odpowiednio dostosowuje szybkość ramek pętli wnioskowania, zmieniając interwał uśpienia między przechwytywaniem ramek lub konfigurując częstotliwość operacyjną akceleratora przez API trybu mocy. Kompletne podejście projektowe do wdrażania tych systemów w warunkach polowych opisuje nasz artykuł o wnioskowania AI na pokładzie BSP, który stosuje te same zasady cyklu pracy w kontekście lotniczym.

Margines rezerwowy musi być wbudowany w każdy budżet mocy. 20% rezerwa to minimum — misje taktyczne rutynowo przedłużają się poza planowany czas, temperatury otoczenia w letnim środowisku pustynnym przekraczają założenia planistyczne, a aktualizacje oprogramowania mogą zwiększyć rozmiar modelu lub częstotliwość wnioskowania między planowaniem a wykonaniem. Budżet mocy, który jest w 100% przydzielony w czasie planowania, będzie przekroczony w terenie. Należy zwymiarować baterię lub przydział mocy tak, aby pokrywał 120% wymagania energetycznego modelowanego cyklem pracy, i udokumentować politykę rezerwy w specyfikacji projektowej systemu.