Clockwork: Scheduling Compound AI Systems in Space Data Centers

arXiv:2611.00909v1 [cs.DC] 31 Oct 2026

Clockwork: Scheduling Compound AI Systems in Space Data Centers Milos Gravara

Andrija Stanisic

Stefan Nastic

Distributed Systems Group TU Wien m.gravara@dsg.tuwien.ac.at

Distributed Systems Group TU Wien a.stanisic@dsg.tuwien.ac.at

Distributed Systems Group TU Wien s.nastic@dsg.tuwien.ac.at

already host workloads of this shape, including remote sensing pipelines [10], wildfire monitoring workflows [11], and language model inference in space [12], and the workload mix is expected to keep widening [6]. A natural use case for this tier is provisioning constellation compute for an area of interest (AoI) [13], [14]. A tenant names a region, supplies a Compound AI system such as wildfire monitoring, and specifies an end-to-end latency SLO. The platform must decide which orbital planes to activate, where to place each component, and when to change these decisions. These decisions determine whether the workflow meets its SLO and what the service costs over time. However, to make these decisions, the platform must address two challenges. First, constellation hardware can be heterogeneous, so the resources required by different Compound AI components may be located on different satellites and orbital planes [15]. A workflow may therefore need to span multiple satellites or planes, which introduces additional ISL communication and requires provisioning compute resources I. I NTRODUCTION across those locations. The continued expansion of data centers is increasingly Second, a placement that satisfies the latency SLO at one limited by power supply and cooling requirements, motivat- point in time may no longer satisfy it as the constellation ing the exploration of orbital infrastructure for large-scale moves relative to the AoI [11], [12]. Changes in satellite computing [1]. The orbital infrastructure already operates at visibility and propagation latency alter the communication paths scale, with Starlink alone operating more than seven thousand available to the workflow over time. The platform may need satellites and constellations such as Iridium and OneWeb to place components on different satellites and orbital planes providing global connectivity for years [2]. Computation is to restore SLO compliance, incurring additional provisioning following connectivity, as Starcloud has launched H100-class costs. Therefore, the platform must decide not only where the GPUs, SpaceCloud processors fly on commercial missions, and workflow should run, but also when changing that placement SpaceX plans orbital data center satellites sustaining 120kW is worth its cost. of compute each [3], [4]. A decade of research on orbital Existing work on LEO constellations largely decides where edge computing anticipated this trajectory [5], [6]. Space data a workload runs while treating the available satellites as centers thus form an emerging tier of the computing continuum, fixed. Workflow schedulers place multi component pipelines and the question of how to manage their resources follows the on satellites under latency objectives [11], [16]. Methods based hardware into orbit. on time expanded LEO graphs limit migrations of service This shift is primarily driven by the computational demand chains, typically for uniform network functions on individual of modern AI [7]. The AI services heading to orbit rarely satellites [17]–[19]. Region bound orchestration maintains consist of a single model, as the AI landscape is evolving application reachability over a ground zone through predictive from monolithic models toward system-centric approaches that network handovers without accounting for the cost of resources coordinate multiple specialized AI and non-AI components [8]. that remain provisioned or change [13], [14]. On the ground, Known as Compound AI, this approach combines specialized provisioned compute resources remain fixed relative to the models and software components into workflows of components demand they serve. In orbit, the planes used for compute orchestrated to solve complex AI tasks [9]. Satellite platforms and access move relative to the region, so the platform must

Abstract—Space data centers built on LEO constellations create an opportunity to serve Compound AI workflows close to where observations are captured. Serving such a workflow for an area of interest (AoI) requires deciding which orbital planes to provision and where to place each workflow component, while orbital motion continuously changes which satellites can serve the AoI. Provisioning must therefore be planned as a sequence of decisions over time, and these decisions are coupled because changing component placements or activating new planes incurs costs. To address this, we present Clockwork, a framework for scheduling Compound AI workflows on space data centers under end-toend latency SLOs. Clockwork has two components: i) Castor jointly selects active planes and component placements for each constellation snapshot, while ii) Pollux connects Castor’s candidate provisioning states across predicted orbital evolution to construct a low-cost schedule over time. On our experimental two-shell constellation, Castor serves 81% of instances at a 300 ms SLO, while Pollux reduces mean total scheduling cost by 56% on average and by up to 63% compared to heuristic baselines. Index Terms—Compound AI Scheduling, Space Data Centers, Edge-Cloud-Space Continuum, Orbital Computing

change provisioning states over time. This creates a temporal provisioning problem that remains unaddressed by existing approaches, because orbital motion couples which resources are used, where workflow components are placed, and when the provisioning should change. In this paper, we introduce Clockwork1 , a novel framework for provisioning Compound AI systems in space data centers under an end-to-end latency SLO. Clockwork uses predicted orbital geometry to plan provisioning decisions across constellation snapshots. To do so, Clockwork relies on two novel algorithms. Castor constructs candidate provisioning states for individual snapshots, and Pollux connects them across snapshots while accounting for provisioning and reprovisioning cost. The resulting schedule specifies the shell, active planes, and component placements used over time. The main contributions of our work include: • Clockwork: a novel planning framework and system model for scheduling Compound AI systems in space data centers. Clockwork represents a provisioning state through its shell, component placements, and active planes, while allowing ingress and egress to change with orbital motion without reprovisioning. It connects snapshot feasibility under the latency SLO with provisioning and reprovisioning costs over time, providing a common formulation for placement and scheduling decisions. • Castor: a per-snapshot provisioning algorithm that jointly selects component placements and active planes under the latency SLO. Castor searches a layered graph using label dominance and latency and cost bounds, returning a minimum-cost feasible state over candidate satellites and alternatives within a specified cost-rate margin. At various SLOs in the reference simulation, Castor finds minimum-cost feasible states in up to 98% of instances, representing an increase of up to 40% in the fraction of feasible instances compared with the heuristic baselines. • Pollux: a cyclic scheduling algorithm that connects Castor’s candidate states across predicted constellation snapshots. Pollux reevaluates their feasibility over time and uses dynamic programming to account for provisioning and reprovisioning costs when deciding whether to retain or change a state. In the default configuration, Pollux reduces mean total scheduling cost by 63% relative to baselines while preserving the same SLO attainment. II. M OTIVATIONAL U SE C ASE AND BACKGROUND In remote regions, early wildfire detection is difficult because these regions often lack sufficient sensing and connection to the terrestrial communication infrastructure. Low Earth orbit (LEO) satellites can address this coverage gap by repeatedly imaging the affected region [15]. However, transmitting every captured image for processing on the ground is impractical because satellites can collect more imagery than their intermittent ground links can transmit [5]. Instead, AI models can process 1 The name reflects the predictability of orbital motion, which enables the framework to plan provisioning decisions in advance. It is unrelated to the Clockwork inference-serving system of Gujarati et al. [20].

Ryzen CPU

Rasp. Pi

Object Detection 2

3 Classification ISL

1 Ingress 4 Hop

6 Egress

4090 GPU

5

LLM

Jetson Orin

Fig. 1. Wildfire detection use case

observations on the satellites and return compact alerts rather than complete images [21]. Such processing can combine object detection to identify fire or smoke, image classification to examine the detected region, and report generation to produce an alert for responders. A pipeline that coordinates these specialized models is a Compound AI system [9], [11]. Running such a workflow in orbit requires placing its components on compute resources distributed across the LEO constellation. Satellites that share an altitude and inclination form a shell, each shell is divided into orbital planes, and each plane is a ring of satellites on the same orbit [22]. Inter-satellite links (ISLs) connect a satellite to its neighbors in the same plane and in the adjacent planes, so the workflow components are not confined to the satellite that captured the image but can be placed across satellites in different planes of a shell [2], [23]. The available hardware is also far from uniform. Radiation-hardened processors such as the RAD5545 deliver a few GFLOPS, embedded accelerators of the Jetson class fly on commercial missions, and a single H100-class GPU has reached orbit, so a constellation holds many CPU satellites, fewer with small accelerators, and only a handful with large ones, concentrated in a few planes [3], [4], [24]. Unlike a terrestrial cluster, however, the entire substrate moves continuously relative to the Earth’s surface, changing which satellites and planes are positioned to serve a particular region over time [2]. A LEO satellite travels at about 7.6 km/s and completes an orbit in roughly 95 minutes, so it stays above a burning region for only a few minutes before the next satellite, often in another plane, takes its place. A wildfire alert must therefore be executed on a substrate whose usable resources change every few minutes. Figure 1 illustrates how the Compound AI system for wildfire detection can be provisioned at one snapshot of the constellation. In this example, to serve the request, the platform needs an active plane with a satellite above the fire, since that satellite captures the image and is the ingress of the request (1). It places the detector (2) and the classifier (3) on a CPU satellite of the same plane, since neither requires an accelerator. For the report generator it needs an accelerator, and the nearest one is

located in a neighboring plane, so it activates that plane as well and accounts for the cost of changing it. Deployment execution and forwards the classified result over ISLs (4) to generate the and application state management are outside its scope. alert (5). It cannot use the large accelerator, although that one is faster, because its plane is not in view of the AoI and the A. Orbital Substrate and Provisioning Request additional ISL distance exceeds the SLO. Finally, it needs a The provider operates a set of Walker shells K. Each shell satellite in view of the AoI in an active plane to return the k ∈ K contains satellites S organized into orbital planes P . k k alert, the egress of the request (6), which is not necessarily the Each satellite s belongs to plane p(s), has hardware class τ , s ingress satellite. and provides compute capacity κs . Even at one constellation snapshot, determining how to Satellites communicate through ISLs connecting neighbors provision the workflow is nontrivial. Several satellites may within the same plane and in adjacent planes. Walker Star provide ingress and egress, while compatible compute resources shells form a cylindrical topology, while Walker Delta shells can lie in different planes. Activating additional planes exposes also connect the first and last planes and form a toroidal more hardware and can reduce execution or communication topology [23]. Connections remain fixed in the model, while latency, but increases provisioning cost. Component placements propagation latency changes with orbital motion. We assume also interact through hardware compatibility, satellite capacity, fixed transmission rates and omit signal degradation and link payload transfers, and the end to end SLO. The platform failures. We denote the propagation latency of the minimummust therefore jointly select the active planes and component propagation ISL path between satellites s and s′ at time t by placements, since locally attractive choices can make the d (s, s′ ). Shells are not connected by ISLs, so each provisioning t complete workflow too expensive or infeasible. state uses one shell. Activating a plane allows its satellites to Solving this placement problem independently at each host workflow components and serve as ingress or egress. snapshot is still insufficient. As satellites move relative to Satellites in inactive planes may still forward ISL traffic. the AoI, visibility and propagation latency change, so the A service request specifies an area of interest A, a fixed cheapest feasible provisioning state can change within minutes. Compound AI workflow with components C = (c , . . . , c ), 1 m Following each change can repeatedly activate planes or move and a latency SLO δ. Each component c has compute capacity i components and incur reprovisioning cost, while retaining a demand ρ and execution latency ℓ (τ ) on hardware class τ . i i slightly more expensive state can avoid later transitions. Orbital We set ℓ (τ ) = ∞ when an execution profile is unavailable, i motion makes these future changes predictable, but knowing which denotes incompatible hardware. The input size is b , 0 them does not determine which states should be retained and b denotes the output size of component c in bits. i i or replaced. The platform must therefore plan a sequence We represent the AoI by a fixed ground point that also of provisioning states over the predicted horizon, balancing locates the receiving ground station. At time t, a satellite is the cost of each state against the cost of changing it while visible from the AoI when its elevation meets or exceeds the maintaining the SLO whenever service is feasible. configured minimum elevation. We denote the visible satellites of shell k by Vk (A, t). An ingress satellite captures the input III. C LOCKWORK F RAMEWORK over the AoI, and an egress satellite returns the workflow Clockwork plans where a Compound AI workflow is result to the ground station. The two satellites may differ. The provisioned on an orbital compute infrastructure and when propagation latency between the AoI and satellite s is denoted that provisioning changes over time with respect to an AoI. Its by αt (A, s). inputs are a provider description of the constellation, hardware, network, and provisioning costs, together with a service request B. Provisioning State and Feasibility containing the workflow, area of interest, and latency SLO. The A provisioning state specifies a shell, a placement of the provider also supplies execution profiles for each workflow workflow components, and the active orbital planes: component on each supported hardware class. Clockwork produces a provisioning schedule that specifies the shell, active q = (k, π, Y), π : C → Sk , Y ⊆ Pk . (1) planes, and component placements used over time. Clockwork separates this problem into two stages. Castor The mapping π assigns each component to a satellite. Ingress determines feasible provisioning states for individual constel- and egress selections are not part of q and may change without lation snapshots and identifies low cost alternatives. Pollux reprovisioning while suitable visible satellites remain available then connects these states across snapshots and selects when in the active planes. to retain or change them according to provisioning and Let U(q) contain the satellites hosting at least one workflow reprovisioning cost. Ingress and egress satellites may change component. Each active plane p incurs provisioning rate ϕp , while a provisioning state remains fixed, allowing the same and each satellite in U(q) incurs rate χ(τs ) according to its state to remain useful as satellites move relative to the AoI. hardware class. A satellite is charged once even when it hosts Clockwork assumes stateless workflow executions with no multiple components. The provisioning cost rate is mutable application state shared across requests. The provider X X prepares the software and model artifacts required by a C(q) = ϕp + χ(τs ). (2) scheduled provisioning state. Clockwork plans provisioning p∈Y s∈U (q)

① Provider and request CPU

P2

② Castor

③ Pollux

Cheapest snapshot placement within the SLO

Cheapest schedule over the cycle T

CPU

P3

Snapshot

GPU Ingress

Detector

Classifier

LLM

Castor

P1 P4 Small Accelerator

P1

LLM

P2

SLO 300 ms

CPU Node Small Acc. Node

GPU Node

Plan Candidates

Over SLO

Alternative plan

P3

Detector Classifier

ti+1

ti

Egress

Cheapest plan

P4

In AoI View

In AoI View

Keep

① Pick among Castor's candidate plans

T

Castor

Castor

P1 P2 P3 P4

Castor's Layered Graph - Constrained shortest path

ti+2

Switch

P1 P2 P3 P4

② Keep current plan if possible to avoid reprovisioning

P1 P2 P3 P4

③ Switch to a new plan to attain SLO or lower the costs

Pollux - Dynamic programming cost optimization

Fig. 2. Clockwork overview. (1) The provider offers shells of orbital planes with heterogeneous hardware; a request names an AoI, a Compound AI system workflow, and a latency SLO. (2) Per snapshot, Castor searches a layered graph of candidate satellites for a minimum-cost feasible state and retains near-minimum-cost alternatives. (3) Per cycle, Pollux selects a state sequence from the resulting pool, using future snapshots to minimize necessary reprovisionings and cost.

Let si = π(ci ) denote the satellite hosting component ci , and let s0 and sm+1 denote the ingress and egress satellites. A valid placement requires components to use compatible hardware in active planes and colocated components to fit within satellite capacity. At snapshot t, ingress and egress must also be visible from the AoI and belong to active planes: p(si ) ∈ Y

∀i = 1, . . . , m,

ℓi (τsi ) < ∞ X ρi ≤ κs

∀i = 1, . . . , m,

i:si =s

s0 , sm+1 ∈ Vk (A, t), p(s0 ), p(sm+1 ) ∈ Y.

∀s ∈ Sk ,

(3)

from input capture to result delivery is Lt (q, s0 , sm+1 ) =

m X i=1

ℓi (τsi ) +

m−1 X

Ti,t (si , si+1 )

i=0

+ dt (sm , sm+1 ) +

bm rdown

+ αt (A, sm+1 ).

(4) Let Qt ⊆ Q denote the states for which some visible ingress and egress pair in the active planes satisfies the access constraints in Equation (3) and has Lt (q, s0 , sm+1 ) ≤ δ. The per-snapshot provisioning problem selects a feasible state with minimum provisioning cost rate: qt⋆ ∈ arg min C(q). q∈Qt

(5)

Castor searches this objective over its candidate satellites and returns low-cost feasible states for Pollux.

Let Q contain the provisioning states satisfying component placement, active-plane membership, hardware compatibility, C. Cyclic Provisioning Schedule and capacity constraints, independently of time-dependent Clockwork plans over snapshots 0 = t1 < · · · < tN < T , access feasibility. where T is a common repeat period of the modeled shells. Clockwork assumes uncongested ISLs with transmission We set tN +1 = T and ∆j = tj+1 − tj . When the AoI-relative rate rISL and pipelined forwarding. For i = 0, . . . , m − 1, geometry repeats after T , the resulting provisioning schedule Ti,t (si , si+1 ) denotes the transfer from the ingress or comcan be reused. Otherwise, Clockwork constructs a new schedule ponent i to the next component. It is zero when si = si+1 . from updated orbital predictions. Otherwise, it equals A cyclic provisioning schedule is Γ = (q1 , . . . , qN ), where state qj applies during [tj , tj+1 ). Feasibility is evaluated at bi snapshot times and is not guaranteed throughout the intervals . dt (si , si+1 ) + rISL between them. Whenever Qtj is nonempty, the schedule must select a feasible state. When no feasible state exists, the provider Each component begins execution after receiving its complete may retain a state from Q or release all resources and enter the input. empty state ∅, with C(∅) = 0. Retaining resources through a The final result may traverse ISLs before reaching the egress. service gap can avoid reprovisioning when service becomes The egress streams the result to the ground station as it arrives. possible again. We assume downlink rate rdown ≤ rISL , so the final payload A transition to a nonempty state incurs reprovisioning cost is serialized once at the downlink rate. The end-to-end latency λ when it changes the component placement or activates a

plane that was previously inactive. Deactivating planes is free, including releasing all resources. Let R(q, q ′ ) equal one when the transition from q to q ′ incurs reprovisioning cost and zero otherwise. The transition from the final state qN back to q1 follows the same rule. The cyclic scheduling problem minimizes provisioning and reprovisioning cost over the repeat cycle: Γ⋆ ∈ arg min Γ

s.t.

N X

C(qj )∆j + λ

j=1

N X

R(qj , qj+1 )

j=1

qj ∈ Qtj ,

Qtj ̸= ∅,

qj ∈ Q ∪ {∅},

Qtj = ∅,

qN +1 = q1 . (6) Pollux constructs a cyclic schedule for this objective from the candidate states generated by Castor across snapshots. IV. C ASTOR : P ER -S NAPSHOT P ROVISIONING Castor jointly selects component placements and active planes for a constellation snapshot to solve the restricted provisioning problem in eq. (5). It returns a state pool Qηt containing a minimum-cost feasible state over its candidate satellites and nondominated alternatives within a cost-rate margin η. These alternatives give Pollux choices beyond the minimum-cost state at each snapshot. a) Search representation: Castor represents provisioning choices as a layered graph with an ingress layer, one layer per compound AI workflow component, and an egress layer. Each complete path selects ingress, component placements, and egress within one shell. To restrict the search, Castor includes all visible satellites and all accelerator-equipped satellites. For each of these, it also includes the K nearest CPU satellites in the same shell and the K nearest CPU satellites in the same plane, ranked by the propagation latency dt (s, s′ ) defined in section III-A. A label represents a partial path through the graph: σ = (i, s, cσ , lσ , Yσ , uσ ),

(7)

where i and s identify its current layer and satellite, cσ and lσ are its accumulated cost rate and latency, Yσ contains its active planes, and uσ records its per-satellite capacity usage. Algorithm 1 searches the graph by advancing these labels through successive layers. b) Building a plan: Castor starts from each visible ingress and charges the activation of its plane (line 1). It then places successive compound AI workflow components on satellites with compatible hardware and sufficient remaining capacity, following the constraints in eq. (3) (line 6). Each placement adds the corresponding transfer and execution latency and charges newly used satellites and planes according to eqs. (2) and (4). Selecting a visible egress completes the path. c) Pruning: Castor estimates the minimum additional latency and cost needed to complete each partial path. The resulting lower bounds L(σ) and C(σ) include the accumulated latency and cost rate. Castor discards a path when these bounds

Algorithm 1 Castor per-snapshot provisioning Input: Snapshot time t, request R, margin η Output: State pool Qη t 1: L0 ← I NITIALIZE I NGRESS(t) 2: C ← I NITIAL C OST B OUND(t) 3: for i = 1, . . . , m + 1 do 4: Li ← ∅ 5: for all σ ∈ Li−1 and feasible successors v do 6: σ ′ ← E XTEND(σ, v, t) 7: if L(σ ′ ) ≤ δ and C(σ ′ ) ≤ C + η then 8: PARETO I NSERT(Li , σ ′ ) 9: end if 10: end for 11: end for 12: F ← Lm+1 13: if F = ∅ then 14: return ∅ 15: end if 16: C ⋆ ← minσ∈F cσ 17: F η ← {σ ∈ F | cσ ≤ C ⋆ + η} 18: return M ATERIALIZE A NDV ERIFY(F η , t)

rule out satisfying the SLO or remaining within the permitted cost margin (line 7). Castor also compares labels at the same satellite and layer using dominance [25]. One label dominates another when it has no greater cost rate or latency, no greater per-satellite capacity usage, and an active-plane set containing the other’s, with at least one strict relation. Castor discards the dominated label. d) Output: Castor retains complete paths within η of the minimum cost rate found (line 17). It reconstructs their provisioning states and checks their costs and feasibility using the plan evaluator before returning Qηt (line 18). An empty pool means that no feasible state was found within the candidate satellites. V. P OLLUX : C YCLIC S CHEDULE C ONSTRUCTION Pollux uses Castor to generate candidate provisioning states and connects them across constellation snapshots into a cyclic provisioning schedule Γ. Selecting the minimum-cost state at each snapshot can require frequent reprovisioning. Pollux instead accounts for both provisioning and reprovisioning costs in eq. (6), allowing it to retain a more expensive state when doing so reduces total scheduling cost. a) Candidate pool: Pollux calls Castor at each snapshot and combines its returned state pools into P (line 1). For each state, it also includes a state with the same component placement and only the active planes hosting components, allowing unused access planes to be released (line 2). Pollux evaluates every candidate at every snapshot using the visible ingress and egress pairs in its active planes. The resulting table F records the lowest-latency pair and whether it satisfies the SLO according to eq. (4) (line 3). Thus, a state can remain feasible across snapshots even when its ingress and egress satellites change. b) Permitted states: At each snapshot, Pollux selects a feasible candidate whenever one exists. Otherwise, it may retain provisioned resources or release them by selecting the empty state. The permitted set at snapshot time tj is ( P ∩ Qtj , P ∩ Qtj ̸= ∅, Pj = (8) P ∪ {∅}, otherwise.

Algorithm 2 Pollux cyclic schedule construction Input: Snapshot times t1 , . . . , tN , request R, margin η, reprovisioning cost λ Output: Cyclic S provisioning schedule Γ 1: P ← N j=1 C ASTOR (tj , R, η) 2: P ← A DD R ELEASE S TATES(P) 3: F ← E VALUATE S TATES(P, (t1 , . . . , tN ), R) 4: Construct P1 , . . . , PN from F using eq. (8) 5: k ← arg minj |Pj |; rotate (t, P, ∆) so that k becomes 1 6: z ⋆ ← ∞ 7: for all q1 ∈ P1 do 8: D1 (q1 ) ← C(q1 )∆1 ; D1 (q) ← ∞ for q ̸= q1 9: for j = 2, . . . , N do 10: g ← arg minq′ ∈Pj−1 Dj−1 (q ′ ) 11: for all q ∈ Pj do 12: f ← arg minq′ ∈Pj−1 , R(q′ ,q)=0 Dj−1 (q ′ ) 13: Dj (q) ← C(q)∆j + min{Dj−1 (f ), Dj−1 (g) + λ}; parentj (q) ← f or g accordingly 14: end for 15: end for 16: qN ← arg minq∈PN DN (q) + λR(q, q1 ); z ← DN (qN ) + λR(qN , q1 ) 17: if z < z ⋆ then z ⋆ ← z; Γ⋆ ← BACKTRACK(parent, qN , q1 ) 18: end for 19: return U NDO ROTATION(Γ⋆ , k)

attainment, and how these results vary across deployment conditions. Castor and Pollux execute as part of the prototype over orbital traces that provide satellite positions, visibility, and ISL propagation latency at each snapshot. We measure component execution latencies on representative hardware and use them as execution profiles. At each snapshot, we compute the end-to-end latency of each provisioning state using Equation (4) and determine whether it satisfies the latency SLO. TABLE I D EFAULT EXPERIMENTAL CONFIGURATION . S HELL DIMENSIONS GIVE PLANES × SATELLITES PER PLANE . Parameter

Default value

Orbital substrate Star shell Delta shell Repeat cycle Network Cost rates

12 × 16, 561 km, 87◦ ; 168 CPU, 20 small, 4 large acc. 12 × 16, 888 km, 53◦ ; 179 CPU, 12 small, 1 large acc. One sidereal day (86 164 s): 15 Star, 14 Delta revolutions +Grid ISLs 100 Gbps, downlink 1 Gbps, min. elevation 25◦ CPU / small / large 1 / 4 / 10, active plane 5 units per hour

Request and planning 48◦ N 16◦ E, latency SLO 300 ms Pollux constructs these sets from F (line 4). Holding resources Reference request Castor K = 2 nearest CPU per shell and per plane, margin η = 5 through a service gap can avoid reprovisioning when service units per hour becomes possible again. An empty feasible candidate set does Pollux Reprovisioning cost λ = 5 units Snapshots Equally spaced; Castor: 8 snapshots × 10 seeded hardware not establish infeasibility over the full state space Q. assignments; Pollux: 1-min grid, 1,440 × 3 c) Constructing the schedule: Pollux uses dynamic programming to select a state sequence from the permitted sets 1) Provider Infrastructure: Table I summarizes the default (algorithm 2). Because the schedule is cyclic, it can be cut at configuration. We construct synthetic Walker Star and Delta any snapshot without changing its cost. Pollux cuts the cycle shells [22] and generate orbital traces using circular two body at the snapshot with the fewest permitted states, rotates the motion with Earth rotation. We omit drag and J2 perturbations, sequence so that this snapshot is first, and considers each state an orbital simplification also adopted by Stardust [26]. The in the resulting P1 as the initial state (lines 5–8). selected altitudes produce a common day repeat cycle [27]. For each state, Pollux compares the cheapest predecessor We represent the CPU, small and large accelerator classes usrequiring no reprovisioning with the cheapest predecessor ing execution profiles measured on an AMD Ryzen 9 7950X, an overall plus reprovisioning cost λ, and selects the cheaper NVIDIA Jetson Orin Nano Super, and an NVIDIA RTX 4090, option after adding the provisioning cost for the current interval respectively. These commercial off the shelf platforms represent (lines 10–13). If no predecessor permits a free transition, that the hardware classes in our model. Their use is motivated by the option has infinite cost. At the final snapshot, Pollux accounts adoption and proposed deployment of commercial computing for the transition back to the initial state and retains the hardware in orbit [3]–[5]. minimum-cost cyclic sequence across all initial states (line 17). Accelerators are concentrated in selected planes, so serving d) Output: Pollux reconstructs the selected cyclic sethe AoI can require combining access and compute resources quence by following the recorded predecessors (line 17). across planes. In Star, 3 planes each carry 4 small accelerators, Consecutive intervals assigned the same provisioning state while 2 planes each carry 4 small and 2 large accelerators. form one schedule segment. The table F supplies ingress and In Delta, 3 planes each carry 3 small accelerators, while one egress selections at each snapshot, which may change within a plane carries 3 small and one large accelerator. CPUs occupy segment. The returned sequence minimizes the cyclic objective all remaining positions. Each seeded hardware assignment in eq. (6) over Pollux’s candidate pool. randomly permutes plane configurations within each shell and VI. E VALUATION hardware locations within each plane, preserving each shell’s hardware counts and plane configurations. We use normalized A. Experimental Setup provisioning cost rates because commercial prices for orbital We implement Clockwork in Python and evaluate it through compute resources are unavailable. trace-driven simulation2 . We evaluate whether Castor improves 2) Workload and Execution Profiles: We evaluate a comSLO feasibility and reduces provisioning cost relative to pound AI workflow that detects a potential wildfire, classifies single-plane and heuristic baselines, whether Pollux reduces the detected region, and generates a short report. Table II scheduling cost and reprovisioning while preserving SLO lists its models, capacity demands, output sizes, and execution profiles. The input is an 8 MB image, and each satellite has 2 The codebase and wiki with complete system model and additional experiments are available at https://github.com/polaris-slo-cloud/Clockwork-LEO normalized capacity one.

TABLE II C OMPOUND AI WORKFLOW AND EXECUTION PROFILES Output Execution latency (ms) Component Model Detector Classifier LLM

YOLOv8m ResNet-50 Qwen2.5-0.5B

Capacity (MB) CPU Small share accel. 0.50 0.25 0.75

2.80 0.04 0.01

90.1 18.7 n/a

96.6 24.6 900

Large accel. 9.0 2.1 117

SLO loosens. At 500 ms, H YPER D RIVE and Castor serve every instance, while BSP serves only 40%. Thus, HyperDrive’s sequential placement becomes sufficient for feasibility, but a single plane often remains insufficient. BSP reaches 90% at 1500 ms, when the small accelerator can execute the LLM within the latency SLO. Castor

BSP

HyperDrive

LF

1.0

fraction served

feasible rate

We report median execution latency at batch size one. Detector and classifier measurements include preprocessing, 0.5 inference, and postprocessing. The language model receives a prompt of 85 tokens and generates up to 32 tokens. The small 0.0 accelerator LLM latency is derived from measured decoding 0.2 0.3 0.5 1 1.5 2 throughput after an execution that terminated after 25 tokens. SLO (s) The CPU configuration does not support the LLM. (a) Feasible rate vs SLO 3) Baselines: We compare Castor with three provisioning 1.00 1.00 baselines. B EST S INGLE P LANE (BSP) finds the least cost valid state confined to one plane, isolating the benefit of multi 0.75 0.75 plane composition. H YPER D RIVE [11] adapts the placement 0.50 0.50 policy of H YPER D RIVE to our snapshot model, using Castor’s candidate set and execution-aware per-edge latency budgets. It 0.25 0.25 places components sequentially, ranking candidates by network 0.00 0.00 latency, isolating the benefit of Castor’s joint placement search 10 20 30 10 20 30 against an external baseline. L ATENCY F IRST (LF) searches cost (units) cost (units) the same candidates as Castor but minimizes latency, isolating (b) Cost, SLO 0.3 s (c) Cost, SLO 1.5 s the benefit of cost aware selection. We compare Pollux with three scheduling baselines. P ER Fig. 3. Effect of the latency SLO on snapshot provisioning. (a) Feasibility S NAPSHOT M INIMUM (PSM) selects the least cost valid state vs various SLOs. (b) and (c) Fraction of instances served at or below each independently at each snapshot, measuring the cost of ignoring provisioning cost at the 300 ms and 1500 ms SLO. future transitions. R EACTIVE retains the current state until it Figure 3 (b)–(c) show the fraction of instances served by violates the SLO, representing adaptation without lookahead. ROLLING H ORIZON (RH) optimizes over the next H minutes plans at or below each provisioning cost. At 300 ms, Castor and applies its first decision, measuring how much lookahead serves 75% of the instances within 21 units, compared with 65% is needed to approach cycle wide planning. All methods use for H YPER D RIVE, 25% for BSP, and 16% for LF. LF requires 40 units to reach Castor’s maximum feasibility of 81%. This the same Castor candidate states and cost model. occurs because only the large accelerators can execute the LLM B. Per-Snapshot Provisioning under Latency SLOs under the tight SLO, which often requires Castor to combine We first evaluate whether Castor’s joint search increases SLO resources across planes. At 1500 ms, Castor, H YPER D RIVE, feasibility and reduces provisioning cost. We vary the latency and LF serve every instance, but Castor reaches this value SLO from 200 to 2000 ms using the default fleet and reference by 16 unit cost while LF requires 40. Thus, Castor’s joint AoI. For each SLO, we evaluate eight evenly spaced planning composition improves feasibility under the tight SLO, while epochs for each of ten seeded hardware assignments, giving 80 cost-aware selection avoids unnecessary accelerator cost on instances. We compare Castor with the BSP, H YPER D RIVE loose SLOs. and LF. Figure 3 (a) shows how the latency SLO affects the fraction C. Cycle-Wide Scheduling of instances that each method can serve. Below 200,ms, all We evaluate whether planning across snapshots reduces total methods fail to find a valid state. At 200 ms, Castor serves 18% scheduling cost while preserving SLO attainment. Using the of the instances, compared with 8% for H YPER D RIVE and default configuration, we compare Pollux with the scheduling 1% for BSP. At the default 300 ms SLO, Castor serves 81%, baselines over one repeat cycle across three seeded hardware compared with 65% for H YPER D RIVE and 28% for BSP. The assignments. All methods use the same candidate pool for each gap over BSP shows that meeting a tight SLO often requires assignment and reprovisioning cost λ = 5, equal to the plane resources from multiple planes. The gap over H YPER D RIVE activation cost. We also examine cumulative cost during the shows that selecting these resources jointly finds valid states first two hours of one assignment to illustrate how scheduling that sequential placement misses. The advantage narrows as the decisions affect cost over time.

PSM RH5

planning cycle. These experiments test the generality of Castor’s provisioning results and identify the orbital conditions under which a Pollux schedule must be recomputed.

RH15 RH60

2000 1000

62

0

Castor

374

244

Pollux Reactive

PSM

129

91

63

RH5

RH15

RH60

SLO feasibility (%)

Scheduling cost

Pollux Reactive

Relative provisioning cost

Cumulative cost

(a) Total scheduling cost 200 100 0

0

30

60

90

Time from cycle start (min)

120

(b) Scheduling cost over time Fig. 4. (a) Mean total cost across three seeded hardware configurations, split into provisioning (solid) and reprovisioning (hatched) cost. (b) Cumulative cost during the first two hours for one seeded hardware configuration. Gray bands mark periods with no SLO feasible candidate plan.

Figure 4 (a) shows that Pollux reduces total scheduling cost by 49% relative to R EACTIVE and 63% relative to PSM, while preserving the same SLO attainment. Its mean unit cost is 837, compared with 1,630 and 2,269, respectively. Pollux makes 62 reprovisionings, compared with 244 and 374, offsetting its higher provisioning cost. All methods meet the SLO at approximately 84% of snapshots, with no feasible candidate at the remaining snapshots. Using the same dynamic program with RH60 also approaches Pollux’s cost, indicating that this amount of lookahead captures most of the scheduling benefit in the evaluated configurations. Pollux achieves these savings with one schedule computed for the repeat cycle, showing the benefit of jointly planning provisioning decisions and their changes over time. Figure 4 (b) shows how the cost difference develops over time. Provisioning costs accumulate between changes, while charged reprovisionings produce jumps. R EACTIVE and PSM repeatedly release resources during short service gaps and incur reprovisioning costs when service resumes. Pollux retains resources through these gaps, making four charged reprovisionings in the displayed interval, compared with 26 and 32, respectively. Longer rolling horizons also reduce cumulative cost, with RH60 tracking Pollux closely. The trace illustrates that holding resources during a short service gap costs less than releasing and reprovisioning them. D. Sensitivity to Deployment Conditions We next test whether the preceding results depend on the reference deployment. We vary the availability and distribution of accelerator hardware, the AoI latitude and available orbital shells, and whether the shell geometry repeats over the

BSP

HyperDrive

LF

100 75 50 25 0

(a) SLO feasibility 2.0 1.5 1.0 0.5 0.0

86 × Orin 29 × 4090 24 planes

32 × Orin 6 × 4090 20 planes

32 × Orin 5 × 4090 9 planes

10 × Orin 2 × 4090 5 planes

accelerator satellites and planes holding them (b) Provisioning cost Fig. 5. Effect of accelerator availability on placement.

a) Hardware availability: To test whether Castor’s advantage depends on the reference hardware distribution, we compare it with the provisioning baselines under four hardware configurations that vary how many accelerator satellites the constellation holds and how many planes hold them. The first spreads 86 Orin and 29 RTX 4090 satellites over all 24 planes. The second spreads 32 Orin and 6 RTX 4090 satellites over 20 planes. The reference configuration concentrates 32 Orin and 5 RTX 4090 satellites in 9 planes, and the fourth concentrates 10 Orin and 2 RTX 4090 satellites in 5 planes. CPUs occupy all remaining satellites, and all other parameters remain unchanged. Figure 5 (a) shows that Castor’s advantage increases as accelerators become scarcer and more concentrated. All methods serve at least 93% of instances in the accelerator-rich fleet. With the fleet-wide control, Castor serves 96% of instances, compared with 78% for H YPER D RIVE and 56% for BSP. These rates fall to 81%, 65%, and 28%, respectively, in the reference fleet, and to 71%, 38%, and 6% in the scarce fleet. Figure 5 (b) compares provisioning cost at epochs served by both Castor and each baseline. LF matches Castor’s feasibility but costs between 1.2 and 2.0 times as much. Castor is never more expensive than a baseline at any jointly served epoch. These results show that plane composition and joint search become increasingly important as accelerator access becomes more limited. b) Orbital repeatability: Repeat-track shells allow Pollux to compute one cyclic provisioning schedule and reuse it on subsequent days. We test whether schedule reuse depends on this property by moving the shells to non-repeat altitudes of 550/800 km and 600/1000 km (Table III). On the reference shells, replaying the first-day schedule attains 84.3% SLO compliance on the second day, equal to the maximum achievable for that day’s geometry. On the non-repeat shells, replay attains only 51.4% and 47.1% because the visibility

TABLE III E FFECT OF ORBITAL REPEATABILITY ON THE P OLLUX SCHEDULE . B RACKETS GIVE THE MIN AND MAX REPLAY RESULT ACROSS SEEDS . Day-two SLO attainment (%) Reprov. Shell altitudes (km) Repeat, 561/888 Non-repeat, 550/800 Non-repeat, 600/1000

Ceiling

TABLE IV R ELATED WORK BY GROUP. ✓ ALL SYSTEMS IN THE GROUP, (✓) SOME , – NONE . C OLUMNS : MODEL SELECTION ; HARDWARE HETEROGENEITY; PLACEMENT FEASIBILITY WITH ORBITAL MOTION ; PLACEMENTS PLANNED AHEAD OVER SNAPSHOTS ; PROVISIONING COST IN THE OBJECTIVE .

Replay Replan

84.3 84.3 83.7 51.4 [49–53] 85.8 47.1 [42–50]

84.3 83.7 85.8

62 61 59

intervals shift between days. Recomputing from the predicted second-day geometry restores SLO compliance to the respective maxima of 83.7% and 85.8%, with 61 and 59 reprovisionings compared with 62 on the reference shells. This shows that the loss under replay is caused by changing orbital geometry rather than a limitation of Pollux. Repeat-track shells therefore permit schedule reuse, whereas other shells require Pollux to recompute the schedule as their geometry changes.

Model HW Orbital Plans Prov. selection classes motion ahead cost Compound AI serving [9], [28]–[31] LEO placement [13], [14], [16], [33] Time-expanded chains [17]–[19] HyperDrive [11] Clockwork

✓ – – – –

(✓) (✓) – ✓ ✓

– ✓ ✓ (✓) ✓

– (✓) ✓ – ✓

✓ (✓) ✓ – ✓

variants on heterogeneous hardware per stage to maximize predicted accuracy under SLOs [30]; Compass switches between precomputed configurations as load changes [9]; and Murakkab maps agentic workflows to models and hardware and reconfigures them at runtime [31]. Clockwork inherits their view of a workflow as a chain of components with perVII. D ISCUSSION hardware execution profiles, and their principle that placement Clockwork deliberately targets stateless compound AI work- is decided by an SLO and a cost. flows, whose explicit components, payloads, and per-hardware These systems assume that every node is reachable for the execution profiles make placement and communication costs whole deployment, so a placement, once chosen, stays feasible tractable to model. Stateful applications would additionally until the load changes, and only the load triggers adaptation. require state migration and consistency during reprovisioning, On a constellation, however, the nodes leave the view of the while less structured applications may be harder to characterize AoI within minutes, so feasibility changes with geometry, and with sufficiently accurate execution profiles. Clockwork exploits the placement decision recurs over time with a cost for every predictable orbital motion but assumes that resource and change. These systems therefore cannot be applied directly to network availability follow the planned constellation state. a constellation, and Clockwork builds the temporal dimension Satellite or link failures, temporary communication loss, and they lack on top of the per-component configuration they solve. power or thermal constraints could therefore invalidate planned provisioning decisions. Our evaluation further assumes uncongested communication, static execution profiles, normalized B. Workload Placement on LEO Constellations provisioning costs, and a fixed reprovisioning cost. These Satellite computing systems place tasks, microservices, abstractions support controlled comparison of provisioning and pipelines on satellites and across the edge-cloud-space strategies but do not predict operational deployment costs continuum, and handle orbital motion through handovers and or transition times. Finally, Clockwork evaluates feasibility migration [13], [14], [16], [32], [33]. Service-chain placement on a one-minute planning grid because provisioning changes over time-expanded LEO graphs plans across successive are driven by visibility intervals lasting several minutes. This snapshots and limits migrations of network functions [17]–[19], provides multiple decision points within each interval and is building on the predictability of orbital motion that contact-plan sufficient for the provisioning and scheduling comparisons routing established for networking [23]. Clockwork inherits made here, though it does not establish continuous SLO this predictability and the handover of access satellites within a satisfaction between snapshots. fixed placement. HyperDrive [11] is closest to our per-snapshot VIII. R ELATED W ORK problem: it schedules serverless functions across edge, cloud, Prior work relevant to Clockwork spans two areas: (1) and satellite nodes under latency objectives, ranking candidates serving compound AI workflows on fixed infrastructure and by network proximity. Its placement policy operates on a single topology snapshot and does not model provisioning cost or (2) placing workloads on LEO constellations. reprovisioning over time. A. Serving Compound AI Workflows These systems decide where a workload runs on satellites the Deploying a compound AI workflow means choosing, for request can already use, and where they plan over time, they each of its components, a model variant and the hardware do so for uniform functions on individual satellites. Clockwork it runs on, under latency, cost, and accuracy objectives [8]. decides which planes to activate for an AoI and where to place Serving systems make this choice on fixed infrastructure. IPA components with different hardware classes, and weighs the and Loki select variants and scale hardware so that a pipeline provisioning cost of holding a state against the reprovisioning meets its latency SLO at low cost [28], [29]; Atlas places cost of changing it over the cycle.

IX. C ONCLUSION Serving compound AI workflows from LEO constellations requires jointly deciding which planes to activate, where to place workflow components, and when these decisions should change as orbital geometry evolves. We presented Clockwork, which uses predicted orbital geometry to plan these provisioning decisions over time. Castor searches each snapshot for low cost feasible provisioning states, while Pollux connects these states across snapshots and accounts for both provisioning and reprovisioning cost. In our evaluation, Castor serves 81% of instances at a 300 ms SLO, while Pollux reduces mean total scheduling cost by up to 63% with equal snapshot SLO attainment. These results show that provisioning on a constellation is a decision in time as well as in space, and that predictable orbital motion enables these decisions to be planned in advance. Future work includes multi tenant scheduling for shared orbital resources, support for stateful workflows that require state migration or synchronization during reprovisioning and incorporation of satellite and link failures, resource contention, and changing power or thermal availability to improve robustness in operational space data centers. ACKNOWLEDGMENT This work was partly funded by the European Union under the Horizon Europe programme through the SNS JU (Grant Agreement No. 101192912, NexaSphere). Views expressed are those of the authors and do not necessarily reflect those of the EU or the SNS JU. R EFERENCES [1] International Energy Agency, “Key questions on energy and AI,” International Energy Agency, Tech. Rep., 2026. [Online]. Available: https://www.iea.org/reports/key-questions-on-energy-and-ai [2] M. Ali, U. Upadhyay, S. McCormick, J. Hill, and B. Zhang, “Starlink constellation: Deployment, configuration, and dynamics,” arXiv preprint arXiv:2603.25835, 2026. [3] Starcloud, “Starcloud-1,” Company website, 2026, accessed 2026-08-24. [Online]. Available: https://www.starcloud.com/starcloud-1 [4] Unibap AB, “SpaceCloud iX10-102 data sheet,” Product datasheet, 2025, accessed 2026-08-24. [Online]. Available: https://unibap.com/ wp-content/uploads/2025/03/datasheet-ix10-102.pdf [5] B. Denby and B. Lucia, “Orbital edge computing: Nanosatellite constellations as a new class of computer system,” in Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems. ACM, 2020, pp. 939–954. [Online]. Available: https://doi.org/10.1145/3373376.3378473 [6] S. Chen, Y. Wu, B. Mao, F. Tang, and N. Kato, “Space computing power networks: A survey,” IEEE Communications Surveys & Tutorials, vol. 28, pp. 6628–6664, 2026. [7] International Energy Agency, “Energy and AI,” International Energy Agency, Tech. Rep., 2025. [Online]. Available: https://www.iea.org/ reports/energy-and-ai [8] M. Gravara, A. Stanisic, and S. Nastic, “Design Methodology and Performance Trade-offs Management for Distributed and Compound AI Systems,” in 2026 IEEE 19th International Conference on Cloud Computing (CLOUD). IEEE, 2026, pp. 376–387. [9] M. Gravara et al., “Compass: Optimizing compound AI workflows for dynamic adaptation,” in 2026 IEEE 26th International Symposium on Cluster, Cloud and Internet Computing (CCGrid), 2026, pp. 84–93. [10] Q. Jiang et al., “Efficient on-orbit remote sensing imagery processing via satellite edge computing resource scheduling optimization,” IEEE Transactions on Geoscience and Remote Sensing, vol. 63, pp. 1–19, 2025.

[11] T. Pusztai, C. Marcelino, and S. Nastic, “HyperDrive: Scheduling serverless functions in the edge-cloud-space 3D continuum,” in 2024 IEEE/ACM Symposium on Edge Computing (SEC), 2024, pp. 265–278. [12] Z. Wang et al., “SpaceMoE: Realizing distributed mixture-of-experts inference over space networks,” arXiv:2605.00515, 2026. [13] V. Bhosale, A. Gavrilovska, and K. Bhardwaj, “Krios: Scheduling abstractions and mechanisms for enabling a LEO compute cloud,” in Proceedings of the 2024 ACM Symposium on Cloud Computing (SoCC). ACM, 2024. [14] G. Zheng et al., “SDN-based service function chaining in integrated terrestrial and LEO satellite-based space internet,” IEEE Journal on Selected Areas in Communications, vol. 43, pp. 537–550, 2025. [15] A. Stanisic, M. Gravara, J. L. Herrera, and S. Nastic, “Constella: A novel framework for cost-efficient distributed AI inference in LEO space data centers,” in Euro-Par 2026: Parallel Processing: 32nd European Conference on Parallel and Distributed Processing, Pisa, Italy, August 24–28, 2026, Proceedings, Part II, 2026, pp. 347–362. [16] Z. Li et al., “OrbitChain: Orchestrating in-orbit real-time analytics of Earth observation data,” arXiv preprint arXiv:2508.13374, 2025. [17] M. Mahyoub, W. Jaafar, S. Muhaidat, and H. Yanikomeroglu, “Scalable security and migration-aware SFC provisioning in LEO satellite networks,” arXiv:2607.00471, 2026. [18] Y. Liu, R. Zhang, J. Liu, N. Sun, and X. Zhang, “VMR-STAG based online SFC orchestration in space-terrestrial integrated networks,” IEEE Transactions on Mobile Computing, vol. 25, pp. 3936–3952, 2026. [19] T. Liu, X. Li, C. Zhao, X. Yan, Y. Zhang, and S. Huang, “Switchingresistant and load-balanced SFC deployment in LEO satellite networks,” in 2025 International Conference on Aerospace Information Perception and Intelligent Processing (AIPIP), 2025, pp. 230–234. [20] A. Gujarati et al., “Serving DNNs like clockwork: Performance predictability from the bottom up,” in 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, 2020, pp. 443–462. [21] M. Moussa, A. Williams, S. Roffe, and D. Morton, “PyroFocus: A deep learning approach to real-time wildfire detection in multispectral remote sensing imagery,” in 2025 IEEE/CVF International Conference on Computer Vision Workshops (ICCVW), 2025, pp. 2855–2864. [22] J. G. Walker, “Some circular orbit patterns providing continuous whole Earth coverage,” Royal Aircraft Establishment, Tech. Rep. 70211, 1970. [23] L. Wood, G. Pavlou, and B. Evans, “Effects on TCP of routing strategies in satellite constellations,” IEEE Communications Magazine, vol. 39, no. 3, pp. 172–181, Mar. 2001. [24] BAE Systems, “RAD5545 SpaceVPX single-board computer,” Technical presentation, JHU APL Flight Software Workshop, 2016. [Online]. Available: https://flightsoftware.jhuapl.edu/files/2016/Day-2/ Day-2-13-Saridakis.pdf [25] S. Irnich and G. Desaulniers, “Shortest Path Problems with Resource Constraints,” in Column Generation, ser. Springer Books. Springer, 2005, pp. 33–65. [26] T. Pusztai et al., “Stardust: A scalable and extensible simulator for the 3D continuum,” in 2025 IEEE International Conference on Edge Computing and Communications (EDGE), 2025, pp. 44–53. [27] X. Luo et al., “A novel technique to compute the revisit time of satellites and its application in remote sensing satellite optimization design,” International Journal of Aerospace Engineering, pp. 1–9, 2017. [28] S. Ghafouri et al., “Inference pipeline adaptation to achieve high accuracy and cost-efficiency,” Journal of Systems Research, vol. 4, no. 1, 2024. [29] S. Ahmad et al., “Loki: A system for serving ML inference pipelines with hardware and accuracy scaling,” in Proceedings of the 33rd International Symposium on High-Performance Parallel and Distributed Computing (HPDC). ACM, 2024, pp. 267–280. [30] M. Gravara, A. Stanisic, and S. Nastic, “Atlas: Optimizing Deployment of Compound AI Workflows on Heterogeneous Clusters,” in 2026 IEEE/ACM Symposium on Edge Computing (SEC). IEEE, 2026. [31] G. I. Chaudhry et al., “Murakkab: Resource-efficient agentic workflow orchestration in cloud platforms,” in 20th USENIX Symposium on Operating Systems Design and Implementation (OSDI 26). USENIX Association, 2026. [32] Y. Huang, X. Zhang, and Z. Xu, “SatEdge: Platform of edge cloud at satellite and scheduling mechanism for microservice modules,” IEEE Access, vol. 11, pp. 126 283–126 294, 2023. [33] N. Lin et al., “Dependency-aware task offloading for satellite mobileedge computing: A deep reinforcement learning scheme,” IEEE Internet of Things Journal, vol. 12, pp. 43 440–43 455, 2025.

Related documents

• Clockwork: Scheduling Compound AI Systems in Space Data Centers#1536724
• Plenty of Room in the Middle: Revealing Opportunities on a GPU Cluster via Fine-Grained Monitoring#1473582
• Plenty of Room in the Middle: Revealing Opportunities on a GPU Cluster via Fine-Grained Monitoring#1467653
• Job Class Thermal Intent Aware Liquid Cooling Allocation for AI Data Centers#1105344
• Safety-Aware AoI Scheduling for LEO Satellite-Assisted Autonomous Driving#120461