Air Combat Mission Replanning #1: Overcoming CPython Latency & VRAM OOM
· 13 min read

💡 Executive Summary (TL;DR)
- The Target: Designing an end-to-end mission-critical software architecture for in-flight dynamic mission replanning (F-16 and F-15E air combat operations), generating and verifying tactical delta packages within 5.0 seconds over tactical data links (Link 16).
- Real Engineering Pitfalls Encountered:
- The 31.4s CPython Search Latency Wall: Pure Python A* graph search over a
100 km × 100 kmDigital Elevation Model (10^7nodes) consumed up to 31.42 seconds (48.0s in ridge lines) due to dynamic object boxing, heap fragmentation, and runtime ray-casting, failing quality standardQ_3(<= 5.0 s).- 8GB VRAM Dual-LLM CUDA OOM Trap: Loading two generative 7B/8B language models simultaneously demanded
11.44 GBVRAM (weights + KV-cache + CUDA overhead), immediately triggeringtorch.cuda.OutOfMemoryErroron single-GPU developer workstations.- Ground-Truth Circularity in Fuel Metrics: Stating a "
\pm 1\%calculation accuracy" without access to classified military aerodynamic polar tables created an untestable circular definition.- Clean Production Fixes:
- Pre-baked Viewshed Maps & 2D Manifold A*: Pre-computed radar lines-of-sight into a contiguous 2D float NumPy matrix during scenario loading, combining 2D horizontal A* exploration with analytical altitude clamping to slash search latency to 0.259 seconds (1/20th of the 5.0s budget).
- KV-Cache Elimination & 4D Cost-Weight Vectorization: Discarded generative autoregressive text generation in favor of a
0.28 GBencoder (DeBERTa-v3-small) and an MLP predicting a 4D cost vectorw ∈ [0, 1]^4, reducing required VRAM to 0.80 GB (90% headroom on 8GB GPU) with zero coordinate hallucination.- RK4 Numerical Ground Truth: Formulated an independent Runge-Kutta 4th Order numerical integration engine calibrated via publicly released Breguet range equations (
c_0 = 0.131227 hr^{-1), achieving a maximum relative error of3.31 × 10^{-5to mathematically verifyQ_2.
