KI-Inferenz unter Leistungsbeschränkungen am taktischen Edge

Jedes KI-Inferenzsystem, das ein Rechenzentrum verlässt und in eine taktische Umgebung eintritt, stößt auf dieselbe Barriere: Die Hardware, die die beste Modellgenauigkeit liefert, verbraucht mehr Strom, als die Plattform bereitstellen kann, und erzeugt mehr Wärme, als das Gehäuse abführen kann. SWaP-C — Size, Weight, Power und Cost (Größe, Gewicht, Leistung und Kosten) — ist am taktischen Edge keine nachrangige Ingenieursfrage, sondern die primäre Konstruktionsbeschränkung, aus der alle anderen Entscheidungen abgeleitet werden. Dieser Artikel behandelt die gesamte Ingenieurskette von der SWaP-C-Budgetdefinition über die Hardware-Auswahl, die Quantisierungsstrategie, die Leistungsprofilierungsmethodik, die Laufzeitauswahl, das Wärmemanagement bis hin zur missionsspezifischen Leistungsbudgetgestaltung für militärische KI-Einsätze.

SWaP-C definiert: warum Gewicht und Leistung am Edge mehr zählen als rohe TOPS

Die taktische Edge-Beschränkungshierarchie stellt TOPS an letzte, nicht an erste Stelle. Bevor ein Systemkonstrukteur überhaupt berücksichtigen kann, wie viele Tera-Operationen pro Sekunde ein Chip ausführen kann, müssen drei vorgelagerte Fragen beantwortet werden: Passt der Chip in das verfügbare Volumen, überschreitet seine Masse die Nutzlastgrenze der Plattform, und übersteigt seine Leistungsaufnahme das, was der Akku oder die Lichtmaschine der Plattform liefern kann? Erst wenn alle drei Antworten nein lauten, wird der Durchsatz relevant.

Die Größe schränkt die physische Integration ein. Ein Jetson AGX Orin-Modul misst 100 mm × 87 mm und benötigt eine Trägerplatine, die in der Z-Achse weitere 15–20 mm hinzufügt. Das abgestiegene Rechenkit eines Soldaten, ein kleinkalibriger Turmcontroller oder der Führungsbuggy einer kreisenden Munition bieten möglicherweise nur ein Volumen von 60 × 60 × 25 mm für zusätzliche Rechenleistung. In diesem Fall passt ein 34 mm × 26 mm großer Hailo-8 M.2-Beschleuniger dort, wo der AGX Orin nicht passt.

Das Gewicht summiert sich über ein System hinweg. Ein 300 g schweres Inferenzmodul, das zum abgestiegenen Kit eines Soldaten hinzugefügt wird, gesellt sich zu einer Last, die möglicherweise bereits 35–45 kg wiegt. Militärische Ergonomieprogramme verwenden 30 % des Körpergewichts als maximale Dauerbelastungsgrenze; jedes Gramm Inferenzhardware konkurriert mit Munition, Wasser und Kommunikationsausrüstung um die Zuteilung unterhalb dieser Grenze. Bei einem UAV reduziert zusätzliches Gewicht die Flugzeit, da mehr Strom benötigt wird, um die Höhe zu halten, was eine doppelte Strafe schafft: Mehr Gewicht verbraucht mehr Akkustrom für den Antrieb, und weniger Akkustrom bleibt für die Nutzlast übrig.

Leistung ist die unnachgiebigste Beschränkung, weil ihr Überschreiten nicht nur ein Leistungsproblem ist — es kann die Mission beenden. Die Lichtmaschine eines Bodenfahrzeugs hat eine feste Ausgangsleistung; der Akku eines UAV hat eine feste Kapazität. Wenn das KI-Inferenz-Subsystem, das Kommunikationsfunkgerät, die Sensorausstattung und die Fahrzeugsysteme zusammen die verfügbare Leistung überschreiten, wirft die Leistungsverteilungseinheit Lasten nach Prioritätsreihenfolge ab. KI-Inferenz ist selten die Lastpriorität mit dem höchsten Rang. Das System, das für einen Dauerbetrieb ausgelegt wurde, läuft intermittierend oder gar nicht.

Die Kosten bestimmen die Verbrauchsfähigkeit, was wiederum die Hardware-Auswahl einschränkt. Ein Jetson AGX Orin-Entwicklungskit für 3.000 US-Dollar kann nicht in einer Einwegmunition installiert werden, die für den Verbrauch bestimmt ist. Die Kostenbeschränkung ist nicht rein wirtschaftlicher Natur — sie beeinflusst auch die Logistik, da teure Rechenmodule sichere Lieferketten, kontrollierte Lagerung und Rechenschaftsverfahren erfordern, die die Nachschubzyklen auf dem Gefechtsfeld verlangsamen.

Die richtige Kenngröße für taktische Edge-KI-Hardware ist daher nutzbarer Inferenzdurchsatz pro Watt pro Kubikzentimeter pro Dollar — eine mehrdimensionale Effizienz, die keine einzelne TOPS-Zahl erfassen kann. Für einen detaillierten Vergleich, wie die führenden Plattformen bei dieser zusammengesetzten Kennzahl abschneiden, arbeitet unser Artikel zur Edge-KI-Hardware-Auswahl für die Verteidigung den Kompromissraum systematisch durch.

KI-Beschleuniger-Hardware-Landschaft: Jetson, Hailo, Coral, Qualcomm — Peak-TOPS vs. Dauerdurchsatz vs. Leistungsbereich im Vergleich

Vier Halbleiterfamilien decken den praktischen Bereich taktischer Edge-Einsätze ab. Ein Verständnis davon, wo jede auf der TOPS/W-Kurve liegt und welche architektonischen Kompromisse jede darstellt, ist Voraussetzung für jede Plattformauswahlentscheidung.

Die Stärke der Jetson-Familie liegt in ihrem Software-Ökosystem: vollständiges Linux, CUDA, TensorRT und ein großes Angebot an Open-Source-Inferenz-Tooling. Die Stärke des Hailo-8 liegt in der rohen Energieeffizienz auf Beschleunigerebene — seine Datenflusarchitektur kachelt den neuronalen Netzwerkgraphen über Prozessorcluster und führt ihn in einer Pipeline-Weise aus, die den DRAM-Zugriff minimiert, was die dominante Leistungskosten bei herkömmlicher GPU-Inferenz darstellt. Der Coral Edge TPU ist der einfachste Integrationsweg für Teams, die bereits TFLite verwenden, aber seine 4-TOPS-Obergrenze und die strengen Graph-Kompilierungsanforderungen begrenzen ihn auf kleinere Modelle. Qualcomms QCS8550-SoC kombiniert CPU, GPU und einen Hexagon-NPU auf einem einzigen Die und liefert hervorragende TOPS/W in einem smartphone-abgeleiteten Gehäuse, das zunehmend in handgehaltenen Militärgeräten zu finden ist. Eine gründliche Gegenüberstellung dieser Plattformen findet sich in unserem Artikel zum Vergleich von Edge-KI-Hardware.

Der Dauerdurchsatz weicht unter realen Betriebsbedingungen erheblich von den Peak-TOPS ab. Peak-TOPS-Werte werden bei 100 % Datenpfadauslastung mit idealen Speicherzugriffsmustern gemessen. Reale Inferenz-Workloads auf YOLOv8- oder RT-DETR-Architekturen erzielen oft nur 50–70 % der Peak-TOPS, weil der Operator-Mix des Modells — Faltungsschichten, Batch-Normalisierung, Aktivierungsfunktionen und die Mehrskalen-Ausgabeverarbeitung des Detektionskopfes — nicht alle Ausführungseinheiten gleichzeitig auslastet. Benchmarken Sie jeden Kandidaten mit Ihrem tatsächlichen Modell, bevor Sie ihn in einem Plattformdesign festlegen.

Quantisierungsstrategien: INT8, INT4, FP16 — Genauigkeit vs. Leistungs-Kompromisse, PTQ vs. QAT, pro Kanal vs. pro Tensor

Quantisierung ist die wirkungsvollste Softwaretechnik zur Reduzierung der Inferenzleistung am taktischen Edge. Die Reduzierung der numerischen Präzision von FP32 auf INT8 verringert den Speicherbedarf des Modells um den Faktor 4 und senkt die DRAM-Bandbreitennutzung proportional — und da der DRAM-Zugriff oft die dominante Leistungsaufnahme bei Inferenz-Workloads ist, führt dies direkt zu einem geringeren Stromverbrauch, unabhängig von den Rechenersparnissen.

FP16 (16-Bit-Gleitkomma) ist die am wenigsten aggressive Option. Es halbiert den Speicherbedarf gegenüber FP32 und wird von allen modernen KI-Beschleunigern nativ unterstützt, einschließlich der Jetson-GPU-Tensorkerne. Der Genauigkeitsverlust ist vernachlässigbar — typischerweise weniger als 0,2 mAP auf Standard-Detektions-Benchmarks —, da der reduzierte Dynamikbereich von FP16 selten bedeutende Gewichtswerte in einem gut trainierten Modell beschneidet. FP16 ist der richtige Standard für die erste Bereitstellung eines neuen Modells, wenn die Risikobereitschaft für Genauigkeitsverluste gering ist und die Leistungsersparnis durch INT8 nicht erforderlich ist, um das SWaP-C-Budget einzuhalten.

INT8 ist der Produktionsstandard für strombeschränkte militärische Edge-Einsätze. Hardware mit INT8-Ausführungseinheiten — Jetson Orin, Hailo-8, Coral Edge TPU — liefert eine 2–4-fache Durchsatzverbesserung gegenüber FP32 bei gleichwertiger Modellkapazität, mit einem typischen Genauigkeitsverlust von 0,5–2 mAP. Die Auswirkungen auf die Genauigkeit hängen stark von der Kalibrierungsqualität ab. Post-Training-Quantisierung (PTQ) kalibriert INT8-Skalenfaktoren, indem das FP32-Modell auf einem Kalibrierungsdatensatz ausgeführt und die Verteilung der Aktivierungen an jeder Schicht aufgezeichnet wird. Die Wahl des Kalibrierungsdatensatzes ist entscheidend: Kalibrieren Sie mit Bildern vom Einsatzsensor und der Einsatzhöhe, nicht mit einem generischen öffentlichen Luftbild-Datensatz, sonst sind die Aktivierungsverteilungen nicht abgestimmt und der Genauigkeitsverlust wird höher sein, als die Benchmark-Zahlen vermuten lassen.

Quantisierungsbewusstes Training (QAT) fügt simuliertes Quantisierungsrauschen in den Trainingsgraphen ein, damit der Optimierer die Gewichte so anpasst, dass sie robust gegenüber INT8-Rundung sind. QAT übertrifft PTQ konstant um 1–3 mAP, mit den größten Gewinnen bei kleinen Modellen, bei denen die Gewichtsvarianz pro Kanal höher ist. Der Aufwand ist ein Feinabstimmungslauf von 10–50 Epochen — typischerweise 6–24 Stunden auf einer Trainings-GPU — und der Zugriff auf den originalen Trainingsdatensatz. Für Programme, bei denen die Genauigkeit eine harte Untergrenze hat, die an eine Detektionswahrscheinlichkeitsanforderung gebunden ist, ist QAT der richtige Ansatz. Für schnelles Prototyping oder Situationen nach der Übergabe, bei denen der Trainingsdatensatz nicht verfügbar ist, ist kalibriertes PTQ mit Skalenfaktoren pro Kanal die praktische Alternative.

Pro Kanal vs. pro Tensor Quantisierung ist eine Kalibrierungswahl, die die Genauigkeit bei Faltungsmodellen erheblich beeinflusst. Pro-Tensor-Quantisierung weist dem gesamten Gewichtstensor einer Schicht einen einzigen Skalenfaktor zu; pro Kanal weist jedem Ausgangskanal einen unabhängigen Skalenfaktor zu. Der Unterschied ist bedeutsam, weil Faltungsfilter in reifen Detektionsmodellen wesentlich unterschiedliche L2-Normen über Kanäle hinweg haben — das Netz hat gelernt, Informationen in einigen Filtern zu konzentrieren und in anderen zu unterdrücken. Das Erzwingen eines einzigen Skalenfaktors über alle Kanäle hinweg erzeugt große Rundungsfehler in den hochnormierten Filtern. Pro-Kanal-Quantisierung bewahrt die Genauigkeit auf Kosten einer marginal größeren Kalibrierungstabelle. Alle produktiven TensorRT- und PyTorch-Quantisierungs-Tools unterstützen Pro-Kanal-Gewichtsquantisierung; es gibt keinen ingenieurtechnischen Grund, im Jahr 2026 Pro-Tensor für die Gewichtsquantisierung zu wählen.

INT4-Quantisierung packt zwei Werte pro Byte und erreicht bis zu 8-fache Komprimierung gegenüber FP32, aber der Genauigkeitsverlust von 3–8 mAP auf Detektions-Benchmarks macht es für die meisten taktischen Anwendungen ohne QAT ungeeignet. Sein hauptsächlicher Anwendungsfall ist die Inferenz sehr großer Sprachmodelle, bei denen die DRAM-Bandbreite, nicht die Rechenleistung, die bindende Einschränkung ist. Für Verteidigungs-ISR und Zieldetektionsanwendungen, die YOLOv8-Klassen-Modelle ausführen, ist INT8 der praktische Betriebspunkt.

# TensorRT INT8 calibration — representative snippet
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+ deployment-domain images
        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

# Build INT8 engine
config.set_flag(trt.BuilderFlag.INT8)
config.int8_calibrator = Int8Calibrator(calib_images, 'calib.cache')
# Per-channel quantization is default in TRT 9+

Methodik der Leistungsprofilierung — Messinstrumentierung, dynamische vs. statische Leistung, thermisches Drosseln in MILSPEC-Umgebungen

Softwaregestützte Leistungsschätzungen aus Hersteller-APIs sind für die Trendüberwachung nützlich, aber für die Leistungsbudgetvalidierung auf Systemebene unzureichend. Die einzige zuverlässige Wahrheitsquelle ist die direkte Strommessung an den Hardware-Leistungsschienen, die den KI-Beschleuniger versorgen. Die Abweichung zwischen softwaregemeldeter und gemessener Leistung kann auf Jetson-Plattformen während Dauerinferenz 15–25 % erreichen, weil die Firmware für das Wärmemanagement Taktfrequenzen auf eine Weise anpasst, die nicht immer in den Momentanwerten der API widergespiegelt wird.

Der Standardinstrumentierungsansatz für eingebettete KI-Plattformen verwendet INA3221- oder INA226-Stromerfassungsverstärker in Reihe mit der Versorgungsleitung jeder Leistungsschiene, die über I2C mit 100–200 Hz ausgelesen werden. Auf dem Jetson Orin stellt NVIDIA die eingebauten INA3221-Sensoren über sysfs bereit:

# Read Jetson Orin power rails via sysfs (sample every 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)  # microwatts
    echo "$ts,$rail,$pwr"
  done
  sleep 0.1
done >> /var/log/power_trace.csv

Statische (Leerlauf-)Leistung ist die Grundlastaufnahme mit dem in den Beschleunigerspeicher geladenen Modell und der laufenden Inferenz-Pipeline, aber ohne verarbeitete Frames. Für den Jetson Orin Nano im 7-W-Modus beträgt die Leerlaufleistung etwa 1,5–2,0 W. Dies ist die Untergrenze, unter die das System niemals fällt, solange der Inferenzdienst aktiv ist. In einem Arbeitszyklus-Modell legt die Leerlaufleistung multipliziert mit der Leerlaufzeit die Mindestenergikosten für die Aufrechterhaltung der Inferenzbereitschaft fest.

Dynamische (aktive Inferenz-)Leistung ist die zusätzliche Leistungsaufnahme über den Leerlauf hinaus während der aktiven Frame-Verarbeitung. Die Differenz zwischen Leerlauf- und Aktivleistung stellt die Energiekosten jedes Inferenzzyklus dar. Für einen Jetson Orin Nano, der YOLOv8s INT8 mit 15 fps ausführt, beträgt die dynamische Leistung über dem Leerlauf etwa 4–6 W, für eine Gesamtleistung von 5,5–8 W während Inferenz-Bursts.

Thermisches Drosseln ist das gefährlichste Leistungsprofilierungsszenario, das in einem MILSPEC-Testprogramm weggelassen werden kann. Alle modernen KI-Beschleuniger verfügen über Firmware, die Taktfrequenzen reduziert, wenn die Die-Temperatur sich dem bewerteten Junction-Maximum nähert. Auf Jetson-Plattformen wird dies vom Wärmemanagementsystem gesteuert und beginnt 5–10°C unter dem Junction-Limit zu drosseln. In einer MILSPEC-Umgebung, in der das Gehäuse +70°C Umgebungstemperatur erreichen kann, hat ein auf 85°C Junction-Temperatur bewerteter Chip nur ein Wärmebudget von 15°C von der Umgebung bis zur Junction. Wenn der Wärmewiderstand von Die zu Umgebung 15°C/W übersteigt und der Chip 10 W abgibt, kann die Junction-Temperatur nicht unterhalb des Junction-Limits stabilisiert werden — Drosseln beginnt sofort und hält dauerhaft an. Die praktische Konsequenz ist, dass der bei Raumtemperatur spezifizierte Inferenzdurchsatz nicht der Durchsatz ist, der auf einem heißen Fahrzeug in einer Wüstenumgebung verfügbar ist. Leistungsprofilierung muss bei der maximal erwarteten Umgebungstemperatur mit in seinem Produktionsgehäuse installierter Hardware durchgeführt werden.

Betriebssystem- und Laufzeitauswahl für Energieeffizienz — Bare-Metal vs. RTOS vs. Linux, TensorRT vs. ONNX Runtime vs. TFLite

Die Wahl der Betriebsumgebung beeinflusst direkt die Leerlaufleistung. Eine vollständige Linux-Distribution mit einer Desktop-Umgebung, Hintergrunddiensten und einem Logging-Stack zieht im Leerlauf deutlich mehr Strom als ein minimales Linux, das nur den Inferenzdienst und seine Abhängigkeiten ausführt. Bare-Metal- oder RTOS-Einsätze können die Leerlaufleistung noch weiter reduzieren, indem sie den OS-Scheduler und die Kernel-Subsysteme vollständig eliminieren, opfern aber die Toolchain-Kompatibilität, die das Bereitstellen und Aktualisieren von Modellen in einem operativen Programm praktisch macht.

Für Jetson-Plattformen ist der empfohlene Weg ein minimales Linux (Ubuntu Server oder Yocto-abgeleitetes BSP), das für zielspezifisches Booten konfiguriert ist. Deaktivieren Sie systemd-Dienste, die für den Inferenzbetrieb nicht benötigt werden: Entfernen Sie den Display-Manager, den NetworkManager-Daemon, wenn die Plattform eine feste Netzwerkkonfiguration verwendet, alle Cloud-Telemetrie-Agenten und Bluetooth, wenn die Hardware dies unterstützt. Der nvpmodel-Dienst sollte beibehalten und auf den niedrigsten Leistungsmodus eingestellt werden, der die Inferenzlatenzanforderung bei der Missions-Framerate erfüllt. Ein ordnungsgemäß abgespeckter Jetson Orin Nano, der nur den Inferenzdienst, einen SSH-Daemon und einen minimalen Logging-Prozess ausführt, hat eine Leerlaufleistung von etwa 1,2–1,8 W gegenüber 2,5–3,5 W für das Standard-Entwicklerimage.

Die Laufzeitauswahl bestimmt, wie der quantisierte Modellgraph beim Laden oder vorher zu Hardware-Anweisungen kompiliert wird. TensorRT ist die leistungsstärkste Laufzeit für NVIDIA-Jetson-Hardware. Es fusioniert benachbarte Operatorkerne, wählt die schnellste Algorithmusvariante für jede Schicht bei gegebener Zielpräzision und Batchgröße und nutzt die Tensorkern-Fähigkeiten der Jetson-GPU vollständig. Ein YOLOv8s-Modell, das zu einer TensorRT-INT8-Engine-Datei kompiliert wurde, läuft mit 30–45 fps bei 7–9 W auf dem Jetson Orin Nano; dasselbe Modell in einer generischen ONNX-Runtime-Sitzung ohne TensorRT-Backend läuft mit 12–18 fps bei 10–14 W. Der Leistungsunterschied ist kein Zufall — TensorRTs Kernel-Fusion reduziert die Anzahl der DRAM-Zugriffsrunden pro Inferenz, und DRAM-Zugriff ist die dominante Leistungsaufnahme.

ONNX Runtime mit TensorRT Execution Provider ist die empfohlene Option für Programme, die sowohl auf Jetson-Hardware als auch auf Nicht-NVIDIA-Beschleunigern aus derselben Codebasis abzielen müssen. Die ONNX Runtime API abstrahiert das Hardware-Backend, und der TensorRT EP übernimmt die Kompilierung und Ausführung auf Jetson, während ein anderer EP (DirectML, generisches CUDA, CPU) die Ausführung auf anderen Plattformen übernimmt. Der Portabilitätsvorteil kommt mit einem marginalen Leistungsverlust gegenüber der direkten Verwendung von TensorRT, typischerweise 5–10 % Durchsatzreduzierung.

TFLite mit dem Edge TPU-Delegate ist die richtige Laufzeit für Coral-Plattformen. Es kompiliert den Modellgraphen beim Laden in den On-Chip-SRAM des Edge TPU; alle Operationen, die nicht auf den Edge TPU abgebildet werden können, werden auf der Host-CPU ausgeführt. Der Anteil des Modells, der auf die CPU zurückfällt, ist der Haupttreiber sowohl für Latenz als auch für Energieeffizienz — ein Modell mit 10 % CPU-Fallback kann 2–3-mal so viel Leistung verbrauchen wie ein vollständig On-Chip-Modell, weil die Host-CPU deutlich mehr Leistung pro Operation verbraucht als die dedizierte Hardware des Edge TPU. Verwenden Sie das Kompilierungsprotokoll des edgetpu_compiler, um Operationen zu identifizieren, die nicht auf Hardware abgebildet sind, und modifizieren Sie die Modellarchitektur, um sie durch Edge TPU-kompatible Äquivalente zu ersetzen, bevor Sie in die Produktion einsetzen.

Wärmemanagement in MILSPEC-Gehäusen — Wärmeverteiler, Leitungskühlung, Betriebsbereich -40°C bis +85°C

MILSPEC-Gehäuse für taktische Elektronik spezifizieren typischerweise einen Betriebstemperaturbereich von -40°C bis +85°C gemäß MIL-STD-810-Methode 501/502. Die untere und obere Grenze schaffen entgegengesetzte thermische Ingenieursprobleme. Bei -40°C starten Siliziumbausteine möglicherweise nicht zuverlässig ohne Vorkonditionierung; bei +85°C Umgebungstemperatur ist die passive Wärmeabfuhr für jeden KI-Beschleuniger, der mehr als 3–4 W abgibt, grenzwertig.

Leitungskühlung ist der dominante Wärmeabfuhrmechanismus in versiegelten MILSPEC-Gehäusen, bei denen der konvektive Luftstrom durch die IP-Schutzklasse ausgeschlossen ist. Der Wärmepfad verläuft vom Die des KI-Beschleunigers durch das Gehäuse, durch ein thermisches Schnittstellenmaterial (TIM), durch eine Wärmeverteilerplatte, durch die Gehäusewand und schließlich zur Außenumgebung über natürliche Konvektion und Strahlung. Jede Materialgrenzfläche fügt Wärmewiderstand hinzu, und die Summe aller Widerstände bestimmt den Temperaturanstieg von der Die-Junction zur Umgebungsluft.

Wärmewiderstandsbudget — Hailo-8 in versiegeltem Al-Gehäuse
==========================================================
Junction → Gehäuse (Hailo-8-Paket):       2,0 °C/W
Gehäuse → TIM (Phasenwechselpad, 1 mm):   0,5 °C/W
TIM → Wärmeverteiler (Al 6061, 3 mm):     0,3 °C/W
Wärmeverteiler → Gehäusewand:             1,0 °C/W
Gehäusewand → Umgebung (150 cm² Al):      4,5 °C/W
                                          ─────────
Gesamt R_th (j→a):                        8,3 °C/W

Bei P_diss = 5 W, ΔT = 8,3 × 5 = 41,5 °C
Bei T_Umgebung = 71°C (MIL): T_Junction = 71 + 41,5 = 112,5 °C
Hailo-8 max. bewertete Junction: 125 °C → Marge 12,5 °C ✓

Die Auswahl des Wärmeverteiler-Materials ist erheblich bedeutsam. Aluminium 6061 hat eine Wärmeleitfähigkeit von etwa 167 W/m·K und ist die standardmäßige Luft- und Raumfahrt-Strukturlegierung. Kupfer (385 W/m·K) bietet eine 2,3-fach bessere Wärmeleitfähigkeit und wird dort eingesetzt, wo der Wärmeverteiler eine größere Fläche zwischen dem Chipgehäuse und der Gehäusewand überbrücken muss. Pyrolytische Graphitfolien (700–1500 W/m·K in der Ebene) werden in den anspruchsvollsten Anwendungen eingesetzt, bei denen Aluminium das Wärmebudget nicht erfüllen kann, aber sie sind spröde und erfordern Schutz vor Vibrations- und Stoßlasten — ein erhebliches Problem in gepanzerten Fahrzeugen oder luftabgeworfenen Anwendungen. Für die meisten taktischen KI-Gehäuse, die mit Hailo-8- oder Coral-Klasse-Beschleunigern betrieben werden, ist eine 3–5 mm starke Aluminiumplatte zwischen dem Modul und der Gehäusewand ausreichend, wenn das Gehäuse mindestens 100–150 cm² Außenfläche für natürliche Konvektion hat.

Kaltstart bei -40°C erfordert, dass die Platine mit Heizungen vorgewärmt wird, bevor eine Rechenlast angelegt wird. COTS-Jetson-Module sind für -25°C (Industrievariante) für Lagerung und Betrieb bewertet; einige Militärvarianten erweitern auf -40°C. Unterhalb der bewerteten Untergrenze laden interne Kondensatoren möglicherweise nicht korrekt und Flash-Speicher initialisiert möglicherweise nicht. Ein thermostatgesteuerter Widerstandsheizer, der 3–5 W aus dem Plattformakku zieht — automatisch aktivierend, wenn die Gehäusetemperatur unter -20°C fällt — ist eine einfachere und zuverlässigere Lösung als das Warten auf Halbleiterlieferanten, die den Betrieb bei -40°C spezifizieren. Der Heizer sollte zwischen der Gehäusewand und der Rechenplatine platziert werden, um sicherzustellen, dass die Platinentemperatur die minimale bewertete Betriebstemperatur erreicht, bevor die Hauptspannung angelegt wird.

Thermische Tests müssen mit dem Produktionsgehäuse und der Produktionsmontage-Konfiguration durchgeführt werden. Benchtop-Tests mit einer offenen Trägerplatine in einer Thermokammer zeigen niedrigere Junction-Temperaturen als die Produktionskonfiguration, weil die Zwangskonvektion des Kammerlüfters hilft, die Platine auf eine Weise zu kühlen, die das versiegelte Gehäuse nicht replizieren kann. Testen Sie immer in der schlimmsten Konfiguration — versiegeltes Gehäuse, maximaler Inferenz-Arbeitszyklus, maximale Umgebungstemperatur — und dokumentieren Sie die Steady-State-Junction-Temperatur bei dieser Bedingung als Teil des Systemqualifizierungsberichts.

Missionsspezifische Leistungsbudgetgestaltung — Arbeitszyklus-Modellierung, Inferenzfrequenz vs. Akkulaufzeit, Leistungsmodi verknüpft mit Bedrohungszustand

Ein System, das für Spitzen-Inferenzleistung während einer gesamten Mission ausgelegt ist, läuft entweder vor Missionsabschluss aus dem Akku oder trägt einen größeren Akku, der Gewicht und Kosten erhöht. Keines der Ergebnisse ist optimal. Der richtige Designansatz verknüpft die Inferenzfrequenz mit dem Betriebszustand, indem der KI-Beschleuniger nur dann mit hohem Arbeitszyklus betrieben wird, wenn die taktische Situation es erfordert, und der Arbeitszyklus reduziert wird — oder ein Leerlauf-Niedrigenergiemodus betreten wird — in Phasen, in denen volle Inferenz nicht notwendig ist.

Die Arbeitszyklus-Modellierung beginnt mit einem Missionsprofil: einer zeitgeordneten Sequenz von Betriebsphasen mit geschätzten Dauern und zugehörigen Bedrohungszuständen. Eine Bodenfahrzeugmission könnte eine Transitphase haben (60 Minuten, geringe Bedrohung, Bewegung entlang einer bekannten sicheren Route), eine Annäherungsphase (20 Minuten, erhöhte Bedrohung, Eintreten in unbekanntes Gebiet) und eine Aufklärungsphase (40 Minuten, hohe Bedrohung, stationäre Beobachtung). Jede Phase hat eine andere Inferenzanforderung: 2 fps während des Transits, 10 fps während der Annäherung, 15 fps während der Aufklärung. Die Leistungsaufnahme in jeder Phase ist die Summe aus Leerlaufleistung plus (aktive Inferenzleistung × Inferenz-Arbeitszyklus-Anteil).

Die Tabelle verdeutlicht, dass die Arbeitszyklus-Steuerung den KI-Inferenz-Energieverbrauch um 42 % gegenüber dem Dauerbetrieb mit maximaler Framerate reduziert — von 20 Wh auf 11,5 Wh für eine 160-Minuten-Mission auf einer Hailo-8-Klasse-Plattform. Bei einem System mit einer 40-Wh-KI-Subsystem-Akkuzuteilung verlängert der gesteuerte Ansatz die Akkuausdauer von 120 Minuten auf 210 Minuten, was der Unterschied zwischen einer Plattform sein kann, die die Mission abschließt, und einer, die in der letzten Phase die KI-Fähigkeit verliert.

Leistungsmodusübergänge sollten vom Betriebszustandsautomaten der Plattform gesteuert werden, nicht durch manuelle Besatzungseingaben, weil die kognitive Belastung der Besatzung in Hochbedrohungsumgebungen das manuelle Management unzuverlässig macht. Zustandsautomat-Eingaben umfassen Fahrzeuggeschwindigkeit (über 15 km/h deutet auf Transitmodus hin), Waffensystemstatus (scharf deutet auf erhöhte Bedrohung hin), GPS-Geofencing gegen bekannte Bedrohungsgebiete und explizite Befehlshaber-Override-Befehle. Der KI-Inferenz-Manager empfängt Zustandsübergänge als Ereignisse und passt die Framerate der Inferenzschleife entsprechend an, entweder durch Änderung des Schlafintervalls zwischen Frame-Erfassungen oder durch Konfiguration der Betriebsfrequenz des Beschleunigers über die Leistungsmodus-API. Der vollständige Designansatz für den Einsatz dieser Systeme unter Feldbedingungen wird in unserem Artikel über Onboard-KI-Inferenz für UAVs behandelt, der dieselben Arbeitszyklus-Prinzipien im luftgestützten Kontext anwendet.

Reservemarge muss in jedes Leistungsbudget eingebaut werden. Eine 20%ige Reserve ist ein Minimum — taktische Missionen werden routinemäßig über ihre geplante Dauer hinaus verlängert, die Umgebungstemperaturen in Sommer-Wüstenumgebungen überschreiten die Planungsannahmen, und Software-Updates können die Modellgröße oder Inferenzfrequenz zwischen Planung und Ausführung erhöhen. Ein Leistungsbudget, das bei der Planung zu 100 % zugeteilt ist, wird im Feld überzogen sein. Dimensionieren Sie den Akku oder die Leistungszuteilung auf 120 % des durch den Arbeitszyklus modellierten Energiebedarfs, und dokumentieren Sie die Reserverichtlinie in der Systemdesignspezifikation.