Inferență AI cu constrângeri de putere la marginea tactică

Orice sistem de inferență AI care părăsește centrul de date și intră într-un mediu tactic se lovește de aceeași barieră: hardware-ul care oferă cea mai bună acuratețe a modelului consumă putere pe care platforma nu o poate furniza și generează căldură pe care carcasa nu o poate evacua. SWaP-C — Dimensiune, Greutate, Putere și Cost — nu este o preocupare inginerească secundară la marginea tactică; este constrângerea de proiectare principală din care derivă toate celelalte decizii. Acest articol acoperă întregul lanț ingineresc, de la definirea bugetului SWaP-C până la selecția hardware, strategia de cuantizare, metodologia de profilare a puterii, selecția mediului de execuție, managementul termic și proiectarea bugetului de putere specific misiunii pentru implementările militare AI.

SWaP-C definit: de ce greutatea și puterea contează mai mult decât TOPS brut la marginea tactică

Ierarhia constrângerilor la marginea tactică plasează TOPS pe ultimul loc, nu pe primul. Înainte ca un inginer de sistem să se poată preocupa de câte tera-operații pe secundă poate executa un cip, trebuie să răspundă la trei întrebări preliminare: cipul încape în volumul disponibil, masa lui depășește limita de sarcină utilă a platformei și consumul său de putere depășește ce poate furniza bateria sau alternatorul platformei? Abia după ce toate trei răspunsuri sunt negative devine relevantă capacitatea de procesare.

Dimensiunea constrânge integrarea fizică. Un modul Jetson AGX Orin măsoară 100 mm × 87 mm și necesită o placă de bază care adaugă încă 15–20 mm pe axa z. Un kit de calcul portabil al unui soldat dezmembrat, un controler de turelă de calibru mic sau compartimentul de ghidare al unei muniții loitering pot oferi doar un volum de 60 × 60 × 25 mm pentru calcul suplimentar. În acest caz, un accelerator Hailo-8 M.2 de 34 mm × 26 mm încape acolo unde AGX Orin nu are loc.

Greutatea se cumulează la nivelul întregului sistem. Un modul de inferență de 300 g adăugat kitului portabil al unui soldat se alătură unei sarcini care poate cântări deja 35–45 kg. Programele de ergonomie militară folosesc 30% din greutatea corporală ca prag maxim de sarcină susținută; fiecare gram de hardware de inferență concurează cu muniția, apa și echipamentele de comunicații pentru alocarea sub acel prag. Pe un UAV, greutatea adăugată reduce timpul de zbor prin creșterea puterii necesare pentru menținerea altitudinii, creând o penalizare dublă: greutatea mai mare consumă mai multă energie a bateriei pentru propulsie și mai puțină energie rămâne pentru sarcina utilă.

Puterea este cea mai inflexibilă constrângere deoarece depășirea ei nu este doar o problemă de performanță — poate pune capăt misiunii. Alternatorul unui vehicul terestru are o ieșire fixă; bateria unui UAV are o capacitate fixă. Când subsistemul de inferență AI, radioul de comunicații, senzori și sistemele vehiculului depășesc colectiv puterea disponibilă, unitatea de distribuție a puterii elimină sarcinile în ordinea priorităților. Inferența AI este rareori sarcina cu cea mai mare prioritate. Sistemul proiectat să funcționeze continuu funcționează intermitent sau deloc.

Costul determină doctrina de consumabilitate, care la rândul ei constrânge selecția hardware. Un kit de dezvoltare Jetson AGX Orin de 3.000 de dolari nu poate fi instalat pe o muniție loitering cu sens unic destinată utilizării consumabile. Constrângerea de cost nu este pur economică — afectează și logistica, deoarece modulele de calcul scumpe necesită lanțuri de aprovizionare securizate, depozitare controlată și proceduri de responsabilizare care încetinesc ciclurile de reaprovizionare pe câmpul de luptă.

Figura de merit corectă pentru hardware-ul AI la marginea tactică este, prin urmare, debitul util de inferență pe watt pe centimetru cub pe dolar — o eficiență multidimensională pe care niciun număr TOPS singular nu o surprinde. Pentru o comparație detaliată a modului în care platformele de top se clasează pe această metrică compusă, articolul nostru despre selecția hardware edge AI pentru apărare parcurge sistematic spațiul de compromisuri.

Peisajul hardware acceleratorilor AI: Jetson, Hailo, Coral, Qualcomm — comparație TOPS de vârf vs debit susținut vs anvelopa de putere

Patru familii de silicon acoperă gama practică a implementărilor la marginea tactică. Înțelegerea poziției fiecăreia pe curba TOPS/W și a compromisurilor arhitecturale pe care le reprezintă este o condiție prealabilă oricărei decizii de selecție a platformei.

Punctul forte al familiei Jetson este ecosistemul software: Linux complet, CUDA, TensorRT și un corp mare de instrumente de inferență open-source. Punctul forte al Hailo-8 este eficiența energetică brută la nivelul acceleratorului — arhitectura sa de flux de date împarte graficul rețelei neuronale pe clustere de procesoare și îl execută într-o manieră pipelined care minimizează accesul la DRAM, principalul cost de putere în inferența convențională pe GPU. Coral Edge TPU oferă cea mai simplă cale de integrare pentru echipele care folosesc deja TFLite, dar plafonul de 4 TOPS și cerințele stricte de compilare a graficului îl limitează la modele mai mici. SoC-ul QCS8550 de la Qualcomm combină CPU, GPU și un Hexagon NPU pe un singur die, oferind TOPS/W excelent într-un pachet derivat din smartphone care apare tot mai des în dispozitivele militare portabile. O evaluare aprofundată alăturată a acestor platforme apare în articolul nostru de comparație hardware edge AI.

Debitul susținut diverge semnificativ de TOPS de vârf în condiții reale de operare. Cifrele TOPS de vârf sunt măsurate la 100% utilizare a căii de date cu modele de acces la memorie idealizate. Sarcinile de lucru reale de inferență pe arhitecturi YOLOv8 sau RT-DETR susțin adesea 50–70% din TOPS de vârf deoarece mixul de operatori al modelului — straturi convoluționale, normalizare batch, funcții de activare și procesarea ieșirii multi-scară a capului de detecție — nu menține toate unitățile de execuție ocupate simultan. Testați orice platformă candidată cu modelul dvs. actual înainte de a vă angaja față de ea într-un design de platformă.

Strategii de cuantizare: INT8, INT4, FP16 — compromisuri între acuratețe și putere, PTQ vs QAT, per-canal vs per-tensor

Cuantizarea este singura tehnică software cu cel mai mare impact pentru reducerea puterii de inferență la marginea tactică. Reducerea preciziei numerice de la FP32 la INT8 micșorează amprenta de memorie a modelului de 4 ori și reduce proporțional cererea de lățime de bandă DRAM — și deoarece accesul la DRAM este adesea consumul dominant de putere în sarcinile de inferență, aceasta se traduce direct în consum mai mic de putere independent de economiile de calcul.

FP16 (virgulă mobilă pe 16 biți) este opțiunea cea mai puțin agresivă. Înjumătățește amprenta de memorie față de FP32 și este suportat nativ de toți acceleratorii AI moderni, inclusiv tensorele GPU Jetson. Pierderea de acuratețe este neglijabilă — de obicei mai puțin de 0,2 mAP pe benchmark-uri standard de detecție — deoarece domeniul dinamic redus al FP16 rareori trunchiază valori de pondere semnificative într-un model bine antrenat. FP16 este implicit corect pentru prima implementare a unui model nou când toleranța la riscul de acuratețe este scăzută și economia de putere din INT8 nu este necesară pentru a satisface bugetul SWaP-C.

INT8 este standardul de producție pentru implementările militare edge cu constrângeri de putere. Hardware-ul cu unități de execuție INT8 — Jetson Orin, Hailo-8, Coral Edge TPU — oferă o îmbunătățire a debitului de 2–4 ori față de FP32 la capacitate echivalentă a modelului, cu pierdere tipică de acuratețe de 0,5–2 mAP. Impactul asupra acurateței depinde puternic de calitatea calibrării. Cuantizarea post-antrenament (PTQ) calibrează factorii de scală INT8 rulând modelul FP32 pe un set de date de calibrare și înregistrând distribuția activărilor la fiecare strat. Alegerea setului de date de calibrare este critică: calibrați pe imagini de la senzorul de implementare și altitudinea de implementare, nu pe un set generic de date aeriene publice, altfel distribuțiile activărilor vor fi nepotrivite și pierderea de acuratețe va fi mai mare decât sugerează numerele de benchmark.

Antrenamentul conștient de cuantizare (QAT) inserează zgomot de cuantizare simulat în graful de antrenament astfel încât optimizatorul ajustează ponderile pentru a fi robuste la rotunjirea INT8. QAT depășește constant PTQ cu 1–3 mAP, cu cele mai mari câștiguri pe modelele mici unde varianța ponderilor per canal este mai mare. Costul este o rulare de fine-tuning de 10–50 de epoci — de obicei 6–24 de ore pe un GPU de antrenament — și accesul la setul de date de antrenament original. Pentru programele unde acuratețea are un prag greu legat de o cerință de probabilitate de detecție, QAT este abordarea corectă. Pentru prototipare rapidă sau situații post-transfer unde setul de date de antrenament nu este disponibil, PTQ calibrat cu factori de scală per canal este alternativa practică.

Cuantizarea per canal vs per tensor este o alegere de calibrare care afectează semnificativ acuratețea pe modelele convoluționale. Cuantizarea per tensor atribuie un singur factor de scală întregului tensor de ponderi al unui strat; cuantizarea per canal atribuie un factor de scală independent fiecărui canal de ieșire. Diferența contează deoarece filtrele convoluționale din modelele de detecție mature au norme L2 substanțial diferite între canale — rețeaua a învățat să concentreze informația în unele filtre și să o suprime în altele. Impunerea unui singur factor de scală pe toate canalele creează erori mari de rotunjire în filtrele cu normă ridicată. Cuantizarea per canal păstrează acuratețea cu costul unui tabel de calibrare marginal mai mare. Toate instrumentele de cuantizare TensorRT și PyTorch din producție suportă cuantizarea ponderilor per canal; nu există niciun motiv ingineresc pentru a alege per tensor pentru cuantizarea ponderilor în 2026.

Cuantizarea INT4 împachetează două valori pe byte și obține până la 8x compresie față de FP32, dar pierderea de acuratețe de 3–8 mAP pe benchmark-urile de detecție o face inadecvată pentru majoritatea aplicațiilor tactice fără QAT. Cazul său de utilizare principal este inferența modelelor de limbaj foarte mari unde lățimea de bandă DRAM, nu calculul, este constrângerea obligatorie. Pentru aplicațiile de detecție ISR și a țintelor pentru apărare care rulează modele din clasa YOLOv8, INT8 este punctul de operare practic.

# Calibrare TensorRT INT8 — fragment reprezentativ
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+ imagini din domeniul de implementare
        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

# Construiești motorul INT8
config.set_flag(trt.BuilderFlag.INT8)
config.int8_calibrator = Int8Calibrator(calib_images, 'calib.cache')
# Cuantizarea per canal este implicită în TRT 9+

Metodologia de profilare a puterii — instrumentare de măsurare, putere dinamică vs statică, limitare termică în medii MILSPEC

Estimările de putere raportate de software din API-urile furnizorilor sunt utile pentru monitorizarea tendințelor, dar insuficiente pentru validarea bugetului de putere la nivel de sistem. Singura sursă fiabilă de adevăr este măsurarea curentului inline pe șinele de alimentare hardware care alimentează acceleratorul AI. Decalajul dintre puterea raportată de software și cea măsurată poate ajunge la 15–25% pe platformele Jetson în timpul inferenței susținute, deoarece firmware-ul de management termic ajustează frecvențele de ceas în moduri care nu sunt întotdeauna reflectate în citirile instantanee ale API-ului.

Abordarea standard de instrumentare pentru platformele AI embedded folosește amplificatoare de detecție curent INA3221 sau INA226 plasate în serie cu linia de alimentare a fiecărui șin de putere, citind prin I2C la 100–200 Hz. Pe Jetson Orin, NVIDIA expune senzorii INA3221 de pe placă prin sysfs:

# Citire șine de putere Jetson Orin prin sysfs (eșantion la fiecare 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)  # microwați
    echo "$ts,$rail,$pwr"
  done
  sleep 0.1
done >> /var/log/power_trace.csv

Puterea statică (inactivă) este consumul de bază cu modelul încărcat în memoria acceleratorului și pipeline-ul de inferență rulând, dar fără cadre procesate. Pentru Jetson Orin Nano în modul de 7 W, puterea inactivă este de aproximativ 1,5–2,0 W. Aceasta este limita inferioară sub care sistemul nu coboară niciodată cât timp serviciul de inferență este activ. Într-un model de ciclu de lucru, puterea inactivă înmulțită cu timpul de inactivitate stabilește costul energetic minim al menținerii capacității de inferență disponibilă.

Puterea dinamică (inferență activă) este consumul incremental față de inactivitate în timpul procesării active a cadrelor. Diferența dintre puterea inactivă și cea activă reprezintă costul energetic al fiecărui ciclu de inferență. Pentru un Jetson Orin Nano care rulează YOLOv8s INT8 la 15 fps, puterea dinamică peste inactivitate este de aproximativ 4–6 W, pentru un total de 5,5–8 W în timpul exploziilor de inferență.

Limitarea termică este cel mai periculos scenariu de profilare a puterii de omis dintr-un program de testare MILSPEC. Toți acceleratorii AI moderni au firmware care reduce frecvențele de ceas când temperatura die-ului se apropie de maximul joncțiunii evaluat. Pe platformele Jetson, aceasta este guvernată de framework-ul de management termic și începe limitarea la 5–10°C sub limita de joncțiune. Într-un mediu MILSPEC unde carcasa poate ajunge la +70°C ambient, un cip evaluat la 85°C temperatură de joncțiune are doar un buget termic de 15°C de la ambient la joncțiune. Dacă rezistența termică de la die la ambient depășește 15°C/W și cipul disipă 10 W, temperatura de joncțiune nu se poate stabiliza sub limita de joncțiune — limitarea începe imediat și persistă indefinit. Consecința practică este că debitul de inferență specificat la temperatura camerei nu este debitul disponibil pe un vehicul fierbinte într-un mediu deșertic. Profilarea puterii trebuie efectuată la temperatura ambientală maximă așteptată cu hardware-ul instalat în carcasa sa de producție.

Selecția sistemului de operare și a mediului de execuție pentru eficiență energetică — bare-metal vs RTOS vs Linux, TensorRT vs ONNX Runtime vs TFLite

Alegerea mediului de operare afectează direct puterea în stare de repaus. O distribuție Linux completă cu un mediu desktop, servicii de fundal și un stack de logare consumă semnificativ mai multă putere în stare de repaus decât un Linux minimal cu doar serviciul de inferență și dependențele sale. Implementările bare-metal sau RTOS pot reduce și mai mult puterea în stare de repaus prin eliminarea complet a planificatorului OS și subsistemelor kernel, dar sacrifică compatibilitatea toolchain care face practică implementarea și actualizarea modelelor într-un program operațional.

Pentru platformele Jetson, calea recomandată este Linux minimal (Ubuntu Server sau BSP derivat din Yocto) configurat pentru boot specific targetului. Dezactivați serviciile systemd care nu sunt necesare pentru operarea inferenței: eliminați managerul de afișaj, daemonul NetworkManager dacă platforma folosește o configurație de rețea fixă, orice agenți de telemetrie cloud și Bluetooth dacă hardware-ul îl suportă. Serviciul nvpmodel trebuie păstrat și setat la modul de putere minim care satisface cerința de latență a inferenței la rata de cadre a misiunii. Un Jetson Orin Nano curățat corespunzător care rulează doar serviciul de inferență, un daemon SSH și un proces de logare minimal are o putere în stare de repaus de aproximativ 1,2–1,8 W față de 2,5–3,5 W pentru imaginea implicită de dezvoltator.

Selecția mediului de execuție determină modul în care graficul modelului cuantizat este compilat în instrucțiuni hardware la momentul încărcării sau în avans. TensorRT este mediul de execuție cu cea mai înaltă performanță pentru hardware-ul NVIDIA Jetson. Fuzionează kernelurile operatorilor adiacenți, selectează cea mai rapidă variantă de algoritm pentru fiecare strat dat precizia și dimensiunea batch-ului țintă și exploatează pe deplin capacitățile tensor core ale GPU-ului Jetson. Un model YOLOv8s compilat într-un fișier motor TensorRT INT8 rulează la 30–45 fps la 7–9 W pe Jetson Orin Nano; același model într-o sesiune ONNX Runtime generică fără backend TensorRT rulează la 12–18 fps la 10–14 W. Diferența de putere nu este accidentală — fuziunea kernelurilor TensorRT reduce numărul de accesări DRAM pe inferență, iar accesul DRAM este costul dominant de putere.

ONNX Runtime cu TensorRT Execution Provider este opțiunea recomandată pentru programele care trebuie să targeteze atât hardware-ul Jetson cât și acceleratoare non-NVIDIA din aceeași bază de cod. API-ul ONNX Runtime abstractizează backend-ul hardware, iar TensorRT EP gestionează compilarea și execuția pe Jetson în timp ce un EP diferit (DirectML, CUDA generic, CPU) gestionează execuția pe alte platforme. Beneficiul de portabilitate vine cu un cost marginal de performanță față de utilizarea directă a TensorRT, de obicei o reducere de 5–10% a debitului.

TFLite cu delegatul Edge TPU este mediul de execuție corect pentru platformele Coral. Compilează graficul modelului în SRAM-ul on-chip al Edge TPU la momentul încărcării; orice operații care nu pot fi mapate pe Edge TPU se execută pe CPU-ul gazdă. Fracțiunea din model care revine la CPU este principalul factor de latență și eficiență energetică — un model cu 10% revenire la CPU poate consuma de 2–3x mai multă putere decât un model complet on-chip deoarece CPU-ul gazdă consumă semnificativ mai multă putere per operație decât hardware-ul dedicat al Edge TPU. Folosiți jurnalul de compilare al edgetpu_compiler pentru a identifica operațiile care nu sunt mapate la hardware și modificați arhitectura modelului pentru a le înlocui cu echivalente compatibile Edge TPU înainte de implementarea în producție.

Managementul termic în carcase MILSPEC — disipatori de căldură, răcire prin conducție, interval operațional de la -40°C la +85°C

Carcasele MILSPEC pentru electronica tactică specifică de obicei un interval de temperatură operațională de la -40°C la +85°C conform MIL-STD-810 metoda 501/502. Limita inferioară și superioară creează provocări de inginerie termică opuse. La -40°C, dispozitivele silicon s-ar putea să nu pornească fiabil fără precondiționare; la +85°C ambient, rejecția pasivă a căldurii este marginală pentru orice accelerator AI care disipă mai mult de 3–4 W.

Răcirea prin conducție este mecanismul dominant de rejecție a căldurii în carcasele MILSPEC sigilate unde circulația aerului convectiv este exclusă de ratingul de protecție IP. Calea termică rulează de la die-ul acceleratorului AI prin pachet, prin un material de interfață termică (TIM), prin o placă de dispersie a căldurii, prin peretele carcasei și în final în mediul extern prin convecție naturală și radiație. Fiecare interfață de material adaugă rezistență termică, iar suma tuturor rezistențelor determină creșterea de temperatură de la joncțiunea die-ului la aerul ambient.

Buget de rezistență termică — Hailo-8 în carcasă Al sigilată
==========================================================
Joncțiune → carcasă (pachet Hailo-8):      2,0 °C/W
Carcasă → TIM (pad cu schimbare de fază, 1 mm):    0,5 °C/W
TIM → dispersor de căldură (Al 6061, 3 mm):     0,3 °C/W
Dispersor de căldură → perete carcasă:          1,0 °C/W
Perete carcasă → ambient (150 cm² Al):  4,5 °C/W
                                        ─────────
R_th total (j→a):                       8,3 °C/W

La P_diss = 5 W, ΔT = 8,3 × 5 = 41,5 °C
La T_ambient = 71°C (MIL):  T_joncțiune = 71 + 41,5 = 112,5 °C
Joncțiune max evaluată Hailo-8: 125 °C → marjă 12,5 °C ✓

Selecția materialului dispersorului de căldură contează semnificativ. Aluminiul 6061 are o conductivitate termică de aproximativ 167 W/m·K și este aliajul structural aerospațial standard. Cuprul (385 W/m·K) oferă o conductanță termică de 2,3x mai bună și este utilizat când dispersorul de căldură trebuie să acopere o arie mai mare între pachetul cipului și peretele carcasei. Foile de grafit pirolitic (700–1500 W/m·K în plan) sunt utilizate în aplicațiile cele mai solicitante unde aluminiul nu poate satisface bugetul termic, dar sunt fragile și necesită protecție față de sarcini de vibrații și șocuri — o preocupare semnificativă în aplicațiile pe vehicule blindate sau lansate din aer. Pentru majoritatea carcaselor AI tactice care operează cu acceleratoare din clasa Hailo-8 sau Coral, o placă de aluminiu de 3–5 mm între modul și peretele carcasei este suficientă dacă carcasa are cel puțin 100–150 cm² de suprafață exterioară pentru convecție naturală.

Pornirea la rece la -40°C necesită ca placa să fie alimentată cu încălzitoare înainte de aplicarea sarcinii de calcul. Modulele Jetson COTS sunt evaluate la -25°C (varianta industrială) pentru depozitare și operare; unele variante militare se extind la -40°C. Sub limita inferioară evaluată, condensatoarele interne s-ar putea să nu se încarce corect și stocarea flash s-ar putea să nu se inițializeze. Un încălzitor rezistiv controlat de termostat care consumă 3–5 W din bateria platformei — activând automat când temperatura carcasei scade sub -20°C — este o soluție mai simplă și mai fiabilă decât așteptarea ca furnizorii de semiconductori să specifice operarea la -40°C. Încălzitorul trebuie plasat între peretele carcasei și placa de calcul pentru a se asigura că temperatura plăcii atinge temperatura minimă de operare evaluată înainte ca alimentarea principală să fie aplicată.

Testarea termică trebuie efectuată cu carcasa de producție și configurația de montare de producție. Testarea pe bancul de lucru cu o placă de bază deschisă într-o cameră termică va arăta temperaturi de joncțiune mai mici decât configurația de producție deoarece convecția forțată de la ventilatorul camerei ajută la răcirea plăcii în moduri pe care carcasa sigilată nu le poate replica. Testați întotdeauna în configurația cea mai defavorabilă — carcasă sigilată, ciclu de lucru maxim de inferență, temperatură ambientală maximă — și documentați temperatura de joncțiune în stare staționară la acea condiție ca parte a înregistrării de calificare a sistemului.

Proiectarea bugetului de putere specific misiunii — modelarea ciclului de lucru, frecvența inferenței vs durata de viață a bateriei, moduri de putere legate de starea de amenințare

Un sistem proiectat pentru performanță de inferență de vârf pe durata întregii misiuni va rămâne fie fără baterie înainte de finalizarea misiunii, fie va transporta o baterie mai mare care adaugă greutate și cost. Niciun rezultat nu este optim. Abordarea corectă de proiectare leagă frecvența inferenței de starea operațională, rulând acceleratorul AI la un ciclu de lucru ridicat doar când situația tactică o justifică și reducând ciclul de lucru — sau intrând într-o stare de repaus cu consum redus — în fazele în care inferența completă nu este necesară.

Modelarea ciclului de lucru începe cu un profil de misiune: o secvență ordonată în timp de faze operaționale cu durate estimate și stări de amenințare asociate. O misiune a unui vehicul terestru ar putea avea o fază de tranzit (60 de minute, amenințare scăzută, deplasare pe un traseu cunoscut ca sigur), o fază de apropiere (20 de minute, amenințare ridicată, intrare pe teritoriu necunoscut) și o fază de supraveghere (40 de minute, amenințare mare, observare staționară). Fiecare fază are o cerință diferită de inferență: 2 fps în tranzit, 10 fps în apropiere, 15 fps în supraveghere. Consumul de putere în fiecare fază este suma puterii inactive plus (puterea activă de inferență × fracțiunea ciclului de lucru al inferenței).

Tabelul ilustrează că gestionarea ciclului de lucru reduce consumul de energie al inferenței AI cu 42% față de rularea la rata maximă de cadre continuu — de la 20 Wh la 11,5 Wh pentru o misiune de 160 de minute pe o platformă din clasa Hailo-8. Pe un sistem cu o alocare de baterie pentru subsistemul AI de 40 Wh, abordarea gestionată extinde autonomia bateriei de la 120 de minute la 210 de minute, ceea ce poate face diferența între o platformă care finalizează misiunea și una care pierde capacitatea AI în faza finală.

Tranzițiile modului de putere ar trebui să fie conduse de mașina de stare operațională a platformei mai degrabă decât de introducerea manuală a echipajului, deoarece sarcina cognitivă a echipajului în medii cu amenințare mare face gestionarea manuală nesigură. Intrările mașinii de stare includ viteza vehiculului (peste 15 km/h sugerează modul de tranzit), starea sistemului de armament (armat sugerează amenințare ridicată), geofencing GPS față de zone de amenințare cunoscute și comenzi de suprascriere explicite ale comandantului. Managerul de inferență AI primește tranziții de stare ca evenimente și ajustează rata de cadre a buclei de inferență în consecință, fie prin modificarea intervalului de repaus dintre capturi de cadre, fie prin configurarea frecvenței de operare a acceleratorului prin API-ul modului de putere. Abordarea completă de proiectare pentru implementarea acestor sisteme în condiții de teren este acoperită în articolul nostru despre inferența AI la bord pentru UAV, care aplică aceleași principii ale ciclului de lucru în contextul aerian.

Marja de rezervă trebuie inclusă în fiecare buget de putere. O rezervă de 20% este minimul — misiunile tactice se extind în mod curent dincolo de durata lor planificată, temperaturile ambientale în mediile deșertice de vară depășesc ipotezele de planificare, iar actualizările software pot crește dimensiunea modelului sau frecvența inferenței între planificare și execuție. Un buget de putere alocat 100% la momentul planificării va fi depășit pe teren. Dimensionați bateria sau alocarea de putere să acopere 120% din cerința de energie modelată prin ciclu de lucru și documentați politica de rezervă în specificația de proiectare a sistemului.