Hot AI in Cold Space: Thermal-Crosstalk-Aware Scheduling for Sustainable Orbital AI Clusters

We model ODCs as high-density satellite clusters and consider two distinct architectural paradigms. Let $\mathcal{N}=\{1,\dots,N\}$ be the set of satellite nodes. Each node $i$ is characterized by its thermal capacitance $C_{i}$, dynamic power limits ($P_{idle}$ and peak $P_{max}$), and maximum processing speed $S_{max}$. Heat dissipation properties differ fundamentally depending on the architecture:

Monolithic Structures: The monolithic ODC features a rigid, large-scale (e.g., MW-to-GW scale) macro-structure shaped like a massive unified container, similar to conceptual tether-based orbital space stations (Starcloud-4) (Feilden et al., 2024). Power generation and heat dissipation for the entire ODC are managed globally by the primary structure via externally mounted large-area heat radiators and solar arrays. Standalone compute units are housed within this structure and managed by a centralized liquid cooling system.

As shown in the left part of Figure 1, multiple coolant pipes are routed through the data center, pumping coolant through the compute units before returning it to the heat exchanger. Along the pathway of each coolant loop, upstream nodes receive cold coolant, while downstream nodes receive pre-heated coolant, thereby creating an inherent thermal imbalance across the compute units.

Proximity Swarms: The proximity swarm ODC architecture consists of multiple independent satellite computing nodes flying in a tight formation, similar to Google’s Project Suncatcher concept (y Arcas et al., 2025). These nodes form a dense constellation with inter-node distances typically ranging from hundreds of meters to a few kilometers, communicating via high-bandwidth FSO links, as shown in the right part of Figure 1.

Each satellite in the swarm is equipped with its own solar panels and heat radiators. Although each node utilizes independent passive radiative cooling, the nodes within the constellation are physically close enough to thermally influence one another. Due to view factor occlusion caused by neighboring nodes, their radiators experience varying effective radiating areas. Furthermore, warmer nodes may radiate waste heat directly toward their neighbors, establishing a dynamic thermal imbalance across the distributed swarm.

Let $P_{in}$ and $T_{instant}$ denote the instantaneous chip power and temperature. We link computational load to heat generation non-linearly: $P_{in}=P_{idle}+(P_{max}-P_{idle})(S_{instant}/S_{max})^{\gamma}$. The transient thermal state is dictated by the net heat flow $P_{in}-P_{out}$, where heat dissipation $P_{out}$ is architecturally dependent:

Thermal-Fluid Crosstalk (Monolithic): Downstream nodes are cooled by fluid pre-heated by upstream components ($T_{fluid}^{(i)}=T_{fluid}^{(i-1)}+\eta P_{out}^{(i-1)}$). Consequently, the downstream convective heat dissipation rate ($P_{out}^{(i)}\propto T_{instant}^{(i)}-T_{fluid}^{(i)}$) degrades, creating downstream heat traps.

Thermal-Radiative Crosstalk (Swarms): Dense formations rely on deep-space radiation governed by the Stefan-Boltzmann law ($P_{out}\propto T_{instant}^{4}-T_{amb}^{4}$). Mutual geometric shadowing severely restricts this, which we model via an Effective View Factor $\rho_{i}\in(0,1]$. Peripheral nodes retain larger effective radiating areas (higher $\rho_{i}$), while core nodes suffer severe occlusion (significantly lower $\rho_{i}$), triggering immediate heat traps.

To avoid hardware damage, nodes enforce a soft temperature threshold ($T_{soft}$) and a hard threshold ($T_{hard}$). When $T_{instant}$ exceeds $T_{soft}$, the processing speed $S_{instant}$ scales down linearly from $S_{max}$, capping at a minimum safe speed $S_{min}$ once $T_{hard}$ is reached.

Furthermore, we model thermal-induced hardware degradation using the standard Arrhenius equation, where the Mean Time To Failure (MTTF) is exponentially dependent on temperature: $MTTF\propto\exp(E_{a}/k_{B}T)$. Here, $E_{a}$ is the activation energy (e.g., 0.685 eV) and $k_{B}$ is the Boltzmann constant. Because of this exponential relationship, even minor reductions in peak operating temperatures yield disproportionately large extensions in hardware lifespan.

To accelerate training when memory is sufficient, we apply Data Parallelism. Assuming every computing node holds a full replica of the model, the training data batch is split across different nodes. Each node processes a certain volume of data, determined by the configured micro-batch size.

For distributed LLM training via Data Parallelism, the global batch (size $B_{global}$) is partitioned such that each node processes a micro-batch of $b_{i}$ tokens. The computation time is directly proportional to $b_{i}$ and inversely proportional to the thermally throttled speed $S_{i}(T)$.

Crucially, a global training step strictly requires gradient synchronization (e.g., All-Reduce). This means the total step latency is dictated entirely by the single slowest node in the cluster: $t_{step}=\max_{i}(t_{comp}(i)+t_{comm})$. This mathematical ”max” operation establishes the severe consequence of the Proximity-Thermal Paradox: a single node suffering from intense thermal crosstalk will experience degraded $S_{i}(T)$, thereby stalling the entire ODC cluster and causing a global collapse in MFU.

TLB is designed as a generalized, closed-loop orchestration framework, fundamentally decoupling the load-balancing mechanism from any specific scheduling policy. It continuously operates through a three-phase control loop: 1) Thermal Telemetry: Aggregating real-time physical metrics, such as instantaneous silicon temperatures, local fluid pre-heating levels, and dynamic view factor occlusions; 2) Capability Profiling: Translating raw thermal data into an abstract capability score ($w_{i}$) that quantifies each node’s real-time thermal margin; and 3) Asymmetric Workload Slicing: Dynamically adjusting the distribution of the AI workload (e.g., micro-batch sizes in Data Parallelism) to match the profiled capabilities.

This abstraction allows ODC operators to plug in arbitrarily complex decision engines, ranging from convex optimization solvers to Deep Reinforcement Learning (DRL) agents, without altering the underlying distributed AI communication backends.

For this position paper, rather than deploying a computationally expensive global optimization solver, we implement a lightweight, greedy heuristic to demonstrate the viability of the TLB paradigm.

Standard Data Parallel frameworks enforce a uniform batch distribution, allocating $B_{global}/|\mathcal{N}|$ tokens to each node. This severely penalizes the entire cluster when nodes with degraded cooling drop their processing speed $S_{i}(T)$. TLB breaks this uniformity by calculating the thermal capability score $w_{i}$. The workload $b_{i}$ assigned to node $i$ is strictly proportional to its score:

where every node receives at least one baseline unit of work to maintain gradient synchronization participation, and any fractional rounding remainders are allocated to the highest-scoring nodes.

We define an aggressiveness multiplier $\alpha$ and compute the capability scores based on the architectural paradigm:

Monolithic Flow-Path Priority: We prioritize upstream nodes that receive the coldest fluid. Let $L_{pipe}$ be the total number of nodes on a cooling pipe, and $idx_{i}$ be the zero-based index of node $i$ along that pipe. The capability score is:

Swarm Radiative Priority: We prioritize nodes on the periphery of the cluster with an unobstructed view of deep space. By directly utilizing the Effective View Factor ($\rho_{i}$) introduced in our thermal model, which inherently accounts for geometric shadowing, the capability score is:

By proactively shifting the heaviest computational burdens to nodes with high $w_{i}$, TLB inherently limits the heat generation of central or downstream nodes, preventing them from hitting $T_{soft}$ and triggering the straggler effect.

To transition TLB from a theoretical model to a deployable system, it must bridge the gap between hardware telemetry and the AI application layer. At the hardware level, TLB leverages standard space-grade baseboard management controllers (BMCs) to poll instantaneous silicon temperatures and coolant states. At the application layer, TLB interfaces with distributed AI frameworks (e.g., PyTorch DistributedDataParallel (DDP) or Megatron-LM). Instead of relying on a static DataLoader that evenly shards the dataset, TLB implements a Thermal-Aware Data Sampler. When the profiling engine updates the capability scores $w_{i}$, the sampler dynamically adjusts the micro-batch size $b_{i}$ for the upcoming training steps.

A key practical challenge in dynamic workload slicing is memory pre-allocation. Terrestrial LLM training heavily relies on static computational graphs (e.g., XLA compilation) to maximize hardware utilization. Dynamically changing batch sizes mid-flight can trigger expensive graph recompilations. To mitigate this, TLB assumes the use of emerging dynamic-shape compilers (e.g., PyTorch 2.0 torch.compile) or pre-compiled computational graph buckets corresponding to a discrete set of allowable batch sizes. This ensures that thermal-induced workload shifts do not introduce prohibitive software overhead.

Triggering Policies and Overhead Mitigation. Executing the TLB control loop at every training step would introduce unacceptable synchronization delays. Therefore, TLB employs a hybrid policy: workload redistribution occurs at coarse-grained intervals (e.g., epoch boundaries) to handle slow-moving thermal dynamics like orbital eclipses. Conversely, an event-driven safety net triggers immediate asynchronous task evacuation if hardware telemetry detects a node rapidly approaching $T_{soft}$, guaranteeing thermal safety while bounding orchestration overhead.

To model the multi-scale thermal dynamics of ODCs, we developed a time-stepped thermal-compute co-simulator that evaluates distributed LLM training workloads executing via Data Parallelism.

For the Monolithic architecture, 64 nodes are distributed across 8 liquid cooling pipes (8 nodes daisy-chained per pipe). Downstream nodes process coolant that has been pre-heated by upstream nodes. For the Proximity Swarm architecture, 36 independent satellites fly in a dense $6\times 6$ planar grid formation. We implement a radiative view factor model where nodes dynamically cast thermal shadows on each other; edge nodes retain larger effective radiating areas (higher $\rho_{i}$), while the core nodes suffer severe radiative occlusion (significantly lower $\rho_{i}$).

We compare two scheduling paradigms: 1) Baseline (Uniform): Shards the global micro-batch evenly across all nodes, mimicking standard PyTorch DDP behavior; 2) TLB (Greedy): Implements the proportional allocation heuristic. We track instantaneous hardware temperatures, dynamic processing speeds (throttling), and global step synchronization latency.

The spatial thermal distribution reveals the fundamental flaw of homogeneous scheduling in ODCs. Figure 2 shows the average node chip temperatures in the Monolithic and Proximity Swarm architectures. Under the Baseline policy, the Proximity-Thermal Paradox manifests rapidly. In the Monolithic configuration, heat progressively accumulates along the cooling loops, pushing the downstream nodes (Row 7) into thermal saturation (up to 354.4 K / 81.3^∘C). In the Swarm configuration, the core nodes become severe heat traps reaching 357.2 K (84.1^∘C) due to high radiative view factor occlusion, while the periphery satellites remain significantly cooler (344.5 K / 71.4^∘C).

TLB dynamically maps the thermal topology and deliberately shifts the heaviest computational burdens to the upstream Monolithic nodes and the periphery Swarm nodes. This asymmetric workload slicing neutralizes the cooling variance. For the Monolithic setup, the maximum temperature drops to 353.3 K (80.2^∘C). For the Swarm, the extreme thermal gradient is flattened, with core temperatures reducing to 353.9 K (80.8^∘C) and edge temperatures rising to 351.9 K (78.8^∘C), effectively eliminating spatial heat traps.

The resolution of spatial heat traps translates directly into measurable improvements in computational efficiency and hardware sustainability.

Latency Variance and MFU: In the Baseline scenario, nodes trapped in the thermal core exceed temperature thresholds and trigger hardware throttling. Due to the synchronization requirement of LLM training, the entire cluster must wait for the slowest overheated nodes. Figure 3 demonstrates this straggler effect: the Baseline Monolithic architecture exhibits severe step-like latency variance, capping the MFU at 75.1%. TLB compresses this tail latency spread, improving the Monolithic MFU to 82.7%. In the Proximity Swarm, while the Baseline MFU is already high at 90.0%, TLB perfectly equalizes the computation time across all 36 nodes (indicated by the flat TLB latency distribution), raising the MFU to 90.2% and completely eliminating synchronization wait times.

Extending Lifespan to Amortize Embodied Carbon: Using an apparent activation energy ($E_{a}$) of 0.685 eV, we calculate the cumulative thermal degradation to determine the relative hardware lifespan extension provided by TLB. Our analysis demonstrates that the TLB policy extends the MTTF of the most thermally constrained nodes, yielding a 6.15% lifespan increase for the core node in the Proximity Swarm and a 1.71% increase for the downstream outlet node in the Monolithic cluster, compared to the Baseline.

Under uniform loading, central nodes experience severe thermal fatigue due to relentless temperature oscillation and sustained peak temperatures (e.g., 357.2 K / 84.1^∘C). By smoothing out the thermal gradients and capping peak temperatures at safe operational limits, TLB prevents these nodes from entering cyclical throttling regimes. Flattening the temperature curve directly extends the physical durability of the hardware. In orbital computing, where the operational carbon footprint is zero, extending hardware lifespan is the primary mathematical pathway to amortizing the massive embodied carbon of rocket launches.

Limitations and Evaluation Scope. While the absolute throughput improvements (e.g., 7.6% MFU gain in the Monolithic cluster, 0.2% in the Swarm) may appear modest, this evaluation intentionally employs a rudimentary static heuristic. By ignoring secondary bottlenecks like multi-hop optical routing latency and transient fluid lag, this heuristic serves merely as a lower-bound baseline. Rather than presenting a theoretically optimal scheduler, our primary objective is to empirically validate the existence of the Proximity-Thermal Paradox and the solvability of spaceborne heat traps. Ultimately, extending hardware lifespans by mitigating thermal cycling, even alongside marginal MFU gains, is the fundamental prerequisite for amortizing the immense embodied carbon of space launches.