Space AI Infrastructure: Where the Edge Meets the Orbital Cloud

1

Space AI Infrastructure: Where the Edge Meets the Orbital Cloud

arXiv:2610.16395v1 [cs.DC] 12 Oct 2026

Zhanwei Wang, Jianhao Huang, Min Sheng, Fellow, IEEE, and Kaibin Huang, Fellow, IEEE Abstract—The fusion of artificial intelligence (AI) and space technologies is extending spaceborne intelligence beyond onboard payloads toward a global infrastructure, here termed Space AI infrastructure (SpaceAI-Infra). Its promise rests on two distinctive advantages of space systems: abundant solar energy in orbit and the global reach of satellite constellations. Realizing this promise hinges on a fundamental systems question: How should satellite constellations be designed and orchestrated to deliver data-center-scale AI services competitive with their terrestrial counterparts? This article develops a roadmap-oriented answer. We first chart the evolution of SpaceAI-Infra through three progressive stages: onboard AI, Space Edge AI, and Space Cloud AI. By revisiting the space-constrained fundamentals for endto-end token services, we derive enabling design principles and translate them into an integrated space edge–cloud architecture. The communication-centric space edge comprises free-flying LEO constellations that provide user-proximate computing and form the access and backhaul fabric for cloud AI services. Complementing the edge, the computing-centric space cloud comprises formation-flying satellite constellations organized as space data centers in dawn–dusk sun-synchronous orbits. A case study demonstrates that the proposed architecture can support data-center-scale foundation-model inference for millions of concurrent users worldwide. Index Terms—AI infrastructure, Edge and cloud computing in space, Formation-flying satellite constellations, and Space-based token services.

I. I NTRODUCTION Space AI infrastructure (SpaceAI-Infra) is emerging as an increasingly credible platform for powering energy-intensive large language model (LLM) services. Its key feature lies in converting solar energy harvested in orbit into AI-generated tokens and delivering them to users worldwide. Such infrastructure will not only alleviate the growing pressure on terrestrial power systems but also extend AI services to underserved regions where deploying terrestrial data centers is economically or geographically impractical. Against this backdrop, leading companies in the space and AI sectors, such as SpaceX, Google, and NVIDIA [1], have moved quickly to secure an early foothold in this emerging field. Unlike its terrestrial counterpart, SpaceAI-Infra is following a reverse evolutionary path under aerospace and economic constraints. Terrestrial AI infrastructure has first matured around centralized cloud data centers and is now extending intelligence toward the network edge, closer to where data are generated [2]. In space, by contrast, data centers with Z. Wang, J. Huang, and K. Huang are with the Department of Electrical and Computer Engineering, The University of Hong Kong (HKU), Hong Kong SAR, China (e-mail: zhanwei.wang@hku.hk; Jianhaoh@hku.hk; huangkb@eee.hku.hk). Corresponding author: K. Huang. M. Sheng is with the State Key Laboratory of Integrated Service Networks, Xidian University (XDU), Xi’an, Shaanxi, China (e-mail: msheng@mail.xidian.edu.cn).

comparable capabilities face substantially greater technical and economic barriers to deployment. At a representative mass-topower ratio of 40 kg/kW, competing economically with terrestrial infrastructure would limit the spacecraft-build budget to only $250–$1000/kg, whereas the latest published rocket launch price is roughly an order of magnitude higher [3]. This substantial disparity makes an immediate leap to data-centerscale orbital computing impractical; we therefore envision SpaceAI-Infra evolving toward this long-term goal through the following three progressive stages, also illustrated in Fig. 1. 1) Onboard AI: The first stage is onboard AI, in which mission-specific AI capabilities are embedded in individual satellites for local inference. This stage addresses the downlink bottleneck arising from the mismatch between rapidly growing sensing-data volumes and the limited capacity of space–ground links. For example, a single high-resolution Earth observation satellite can generate 1–2 TB of imagery per day, whereas its RF downlink operates at only 220 Mbit/s during brief ground passes [1]. Even assuming uninterrupted transmission and neglecting protocol overhead, downlinking the entire volume would require approximately 10–20 hours per day, far exceeding the contact time available during typical ground passes. By processing sensor data at the source, onboard AI can discard low-quality observations and extract actionable information before downlink. This reduces communication overhead and response latency. Consequently, onboard AI can enhance mission autonomy through a single-satellite upgrade without requiring constellation-scale coordination. Such single-spacecraft deployments can be supported by expendable launchers. 2) Space Edge AI: The second stage extends AI service provisioning from onboard tasks to users worldwide, including those on land, aboard aircraft and vessels. It embeds computing payloads (e.g., AI functions) into communicationcentric satellite constellations in low Earth orbit (LEO), with user-proximate connectivity, giving rise to Space Edge AI. Its advantages are twofold. First, computing payloads can reuse the spacecraft bus, communication links, and operational infrastructure established for communication missions [3]. Second, the proximity and global coverage of LEO constellations make Space Edge AI well suited to ubiquitous and latency-sensitive computing services, such as real-time translation, interactive gaming, and autonomous navigation. Partially reusable launchers support this stage by reducing the cost of repeated launches for constellation deployment and replenishment [4]. 3) Space Cloud AI: The third stage is Space Cloud AI, which targets general-purpose AI services through space data centers (SpaceDCs). It is envisioned to support frontier foundation models, multimodal workloads, and agentic services

2

Space AI Capacity

Space Cloud AI Space Edge AI Onboard AI • Mission-specific • Spacecraft use • Expendable launchers

Sensing data

Analysis

• Lightweight • Latency-sensitive • Ubiquitous coverage • Partially reusable launchers

• Frontier Models • Long context • Massive Concurrency • Fully reusable heavy-lift launchers

Space data center

Navigation input

Guidance Agent

Coding

Multimodal

Automation

Comm. Tasks Intelligent machines

Stage I

Stage II

Urban users

Stage III

Timeline

Figure 1. Roadmap of Space AI Infrastructure.

for millions of concurrent users worldwide. Current initiatives illustrate this vision at different levels of maturity. For example, SpaceX has proposed an AI satellite capable of supplying 120 kW to its computing payload, comparable to the power demand of an NVIDIA GPU rack. Google’s Project Suncatcher aims to build a scalable distributed SpaceDC comprising TPU-equipped satellites flying in formation in a dawn–dusk sun-synchronous orbit (SSO). By networking multiple such satellites through high-speed optical links, Space Cloud AI could pool computing resources in orbit and ultimately provide data-center-scale AI services to terrestrial users. Fully reusable heavy-lift launchers are envisioned to enable economical deployment of the computing, power, and thermal infrastructure required at this scale [5]. This article is a humble attempt to conceptualize the roadmap and enabling architecture for SpaceAI-Infra. The rest of the article is organized as follows. Sec. II examines the orbital fundamentals underlying roadmap stages and formulates the corresponding design principles. Building on these principles, Sec. III presents an integrated space edge–cloud architecture for end-to-end (E2E) token services. Sec. IV evaluates the resulting architecture through a case study. Finally, Sec. V concludes the article and outlines future research directions. II. F UNDAMENTALS AND D ESIGN P RINCIPLES FOR S PACE AI I NFRASTRUCTURE In this section, we examine the physical fundamentals underlying SpaceAI-Infra, spanning individual-satellite orbital characteristics and multi-satellite cooperation, and derive the corresponding design principles. A. Solar Harvesting and Token Delivery Space-based token services face two fundamental bottlenecks: energy-intensive token generation and latency-sensitive

token delivery. The former converts harvested solar energy into tokens through onboard computing, whereas the latter delivers them to requesting users. Both processes are closely coupled with the orbital configurations of token-serving satellites, which are presented as follows. 1) Harvesting-latency Tradeoff: The energy harvesting efficiency is determined by the sunlit ratio during the lifetime and governed by the Sun–Earth–satellite geometry. One of the key parameters is orbital altitude, defined as the satellite’s height above a specified Earth reference surface. For otherwise comparable orbits, increasing altitude generally reduces the fraction of each orbit spent in eclipse, thereby increasing the annual sunlit fraction, as shown in Fig. 2(a). This energy gain comes at the cost of longer space–ground propagation. For an overhead satellite, moving from a 600-km LEO to the 35,786km GEO increases the round-trip propagation delay from approximately 4 to 240 ms. Orbital altitude therefore governs a fundamental harvesting–latency tradeoff. Low-latency E2E token services require a computing orbit that combines abundant sunlight with short propagation paths. We next identify such a token-service-friendly orbit. 2) Sun Synchronous Orbit: Another factor affecting sunlight availability is the solar beta angle, defined as the angle between the Sun vector and the orbital plane. Owing to Earth’s oblateness, the orbital plane undergoes nodal precession about Earth’s rotational axis. By jointly selecting the orbital altitude and inclination, the precession rate of the orbital plane can be matched to the apparent annual motion of the Sun, approximately 360◦ per year, thereby maintaining an approximately fixed local solar time at the ascending node [6]. Such an orbit is termed an SSO. As illustrated in Fig. 2(b), the Earth–Sun direction rotates throughout the year, while the orbital plane precesses at approximately the same angular rate. Among SSO designs, dawn–dusk SSO is particularly attractive for space computing, as it mitigates the harvesting–

3

(99.1%,125 ms) GEO (82%,22 ms)

MEO

(63%,4 ms)

(97%,3.5 ms)

LEO

Dawn-dusk SSO

(a) Solar availability and one-way propagation-latency tradeoff. Non-SSO Dawn-dusk SSO Jun. 21 Earth

Synchronous

Sep. 23

Sun

Mar. 21

Dec. 22

(b) Sun-synchronous orbit geometry. Figure 2. Orbital characteristics relevant to space AI infrastructure. LEO spans altitudes from 200 to 2,000 km, MEO from 2,000 to 35,786 km, and GEO is located at an altitude of 35,786 km.

latency dilemma. Its orbital plane remains close to the day– night terminator, providing large solar beta angles and nearcontinuous sunlight [3]. Moreover, this configuration can be engineered in LEO at typical altitudes of 700–1,200 km. The resulting minimum ground–satellite round-trip propagation delay is approximately 4.7–8.0 ms, which is of the same order of magnitude as the single-digit-millisecond network latency reported for the AWS Los Angeles Local Zone [7]. This observation leads to the following orbital design principle. Principle 1: SpaceDCs should operate in dawn–dusk SSO to combine near-continuous solar exposure with LEO-class propagation latency. B. Satellite Constellations for Space AI Infrastructure Space-based token services at scale require capabilities far beyond what an individual satellite can support, necessitating multi-satellite cooperation. The spatiotemporal organization of cooperating satellites is characterized by their constellation, defined by their relative positions and motion over time. The formation type governs the inter-satellite communication and cooperative computing that underpin token services. We next distinguish two representative formation types suited to Space Edge AI and SpaceDCs, respectively. 1) LEO-based Free-flying Constellations: A free-flying constellation comprises spatially distributed satellites that independently follow prescribed orbits without maintaining a

fixed relative geometry. Such constellations are well suited to communication-centric missions and offer three advantages for space-based token services: • Ubiquitous coverage: Distributing satellites across multiple orbital planes, as in Walker, rosette, and polar constellations, enables persistent connectivity over wide geographical areas. By optimizing orbital-plane placement and satellite phasing, LEO-based free-flying formation allows minimizing the number of satellites required to achieve a target coverage level, motivating their adoption in commercial systems such as Iridium NEXT, OneWeb, and Starlink. • Low-latency computing access: As discussed in Sec. II-A, deployment in LEO shortens space–ground propagation paths, allowing terrestrial users to access onboard computing with low latency. For example, a satellite at the approximately 550-km altitude of a Starlink shell incurs a minimum ground–satellite round-trip propagation delay of around 4 ms. • Token relay for SpaceDCs: LEO constellations can serve as an access and relay layer between terrestrial users and the higher-altitude dawn–dusk SSO data centers identified above. Their wide-area coverage and intersatellite connectivity allow user requests to be forwarded to SpaceDCs and the generated tokens to be returned. These properties align with the vision of Space Edge AI, leading to the following design principle. Principle 2: LEO-based free-flying constellations are well suited to Space Edge AI and should form the network backbone of SpaceAI-Infra. However, this coverage-oriented geometry is less suitable for tightly coupled cooperative computing. As illustrated in Fig. 3(a), satellites in a free-flying constellation are typically uniformly distributed along an orbital plane to maximize coverage. Consider a ring topology between them with each satellite maintaining two intra-plane inter-satellite links [8]. At an orbital altitude of 800 km, adjacent satellites are separated by approximately 4,900 km. When onboard memory constraints require an LLM to be partitioned across multiple satellites, each decoded token must traverse at least one intersatellite link as hidden states pass between model partitions. This transfer alone adds at least 16.4 ms to the per-token latency, thereby limiting token-generation throughput. 2) Formation-flying Constellations: Unlike its free-flying counterpart, a formation-flying constellation maintains multiple satellites in a prescribed relative geometry. Their relative motion is coordinated through orbital control. Formation flying offers two principal advantages: • Proximity-enabled computing: The compact geometry substantially shortens inter-satellite distances and hence reduces propagation latency for cooperative computing. Figure 3(b) illustrates a representative design based on Google’s Project Suncatcher [5]. The formation comprises a chief satellite near the center of a 2 × 1-km region and multiple deputy satellites following controlled

4

4900 km (16.4 ms) 800 km

Earth Core

Non-blockage link ≤ 2 km (i.e., ≤ 6.7 us)

(a) Free-flying constellation with ring topology

2 km × 1 km

(b) Formation-flying constellation with ring topology

Figure 3. An illustrative comparison of free-flying and formation-flying satellite constellations, each with a ring topology.

elliptical trajectories relative to the chief. A maximum inter-satellite separation of 2 km incurs only approximately 6.7 µs of propagation delay, comparable to that of terrestrial data-center interconnects. • Modular scalability and resilience: Reconfigurable ISLs allow satellites to be added to, removed from, or isolated within the computing cluster. This flexibility supports incremental capacity expansion and technology refresh by deploying advanced satellites and retiring obsolete ones. When satellites become unavailable because of debris impacts or space-weather disturbances, workloads can be rerouted among the remaining nodes, while only the affected satellites need to be replaced. Formation flying thus improves service continuity and reduces recovery costs compared with a monolithic orbital platform [1]. As envisioned for the third stage in Sec. I, Space Cloud AI must support frontier-scale models, complex AI workloads, and massive user concurrency. Their aggregate computing and memory demands typically exceed the capacity of a single satellite. Agentic AI services, for example, invoke numerous tools and specialized models, while multi-agent orchestration requires coordinated execution and intermediate data exchange across multiple agents [9]. Mapping such workloads onto SpaceAI-Infra therefore requires multiple satellites interconnected through high-bandwidth, low-latency links. Formationflying constellations are well suited to these requirements, leading to the following design principle. Principle 3: Formation-flying constellations should form the computing backbone of SpaceDCs, enabling tightly integrated distributed AI services in SpaceAI-Infra. C. Why the Space Edge Must Meet the Orbital Cloud The preceding principles reveal a fundamental complementarity between Space Edge AI and Space Cloud AI. LEObased free-flying constellations provide ubiquitous access and low-latency token delivery, but their communication-centric power budgets constrain onboard computing scale, particularly during orbital eclipses. Formation-flying SpaceDCs can instead pool computing and memory resources under nearcontinuous sunlight, yet their compact, compute-centric ge-

ometry does not provide ubiquitous user coverage. Neither infrastructure alone can satisfy the combined coverage and computing requirements of Stage III. Realizing this stage therefore requires an edge–cloud-integrated SpaceAI-Infra that couples the coverage-oriented space edge with the computingoriented orbital cloud, as developed in the next section. III. S PACE E DGE - CLOUD A RCHITECTURE In this section, building on the preceding design principles, we present an edge–cloud-integrated architecture for SpaceAIInfra. A. Architecture Overview As shown in Fig. 4(a), SpaceAI-Infra comprises two subnetworks with complementary roles. 1) Space Data Center Subnetwork: The SpaceDC subnetwork comprises multiple SpaceDCs deployed in dawn– dusk SSOs, each implemented as a formation-flying satellite constellation. Benefiting from near-continuous solar exposure, each satellite is envisioned as a high-capacity computing node comparable to a GPU rack equipped with multiple accelerators. Interconnected through high-speed ISLs, these satellites collectively provide data-center-scale computing capacity. Within each SpaceDC, satellites are functionally classified as gateway satellites and general-purpose computing satellites. The former serve as both external interfaces and internal orchestrators. They maintain optical links with the space edge subnetwork to receive AI requests and return generated tokens. Internally, they schedule cooperative workloads, allocate resources, and balance loads across computing satellites. The latter host computing accelerators and execute the assigned model components and inference tasks. 2) Space Edge Subnetwork: The space edge subnetwork provides user-facing connectivity and proximity-based computing. It comprises free-flying LEO constellations whose satellites are equipped with large phased-array antennas and ISLs, with selected satellites additionally carrying AI computing payloads. For communication, the phased-array antennas receive user requests and deliver generated tokens, while the ISLs connect the LEO constellation to gateway satellites in dawn–dusk SSO. Multi-hop routing and satellite handovers

5

Space Data Center

Dawn-Dusk SSO

LEO

Load Balancing Tokens

3

SpaceDC Cloud Computing

Edge-SDC ISLs

Eclipse Sunlit

Ground Data Center

2

Solar-aware Computing

Edge Computing

LEO ISLs

Energy & Thermal Manag. Control Flow

Inter-satellite Link

Routing Control Service Handover

Edge computing

Topology & ISL Manag.

Communication Layer 4

1

1 Request Collection

Prompts

Tokens

2

Provider Selection

3 Token Generation

User Layer

(a) Constellation Architecture

4

Token Delivery

(b) Protocol of Space-based Token Service

Figure 4. Architecture of Space AI Infrastructure.

thereby sustain request and token exchange between terrestrial users and the SpaceDC subnetwork. For computing, AIenabled LEO satellites serve nearby users directly. Their proximity to the ground shortens E2E propagation paths, making edge execution suitable for latency-sensitive workloads whose computing and memory demands can be accommodated by a single satellite. B. Protocol of Space-based Token Service As shown in Fig. 4(b), E2E token services in the proposed architecture operate across two logical planes. The token plane carries service data during token generation and delivery, including user prompts, intermediate inference states, and generated tokens. The control plane orchestrates these processes through request and token routing, resource allocation, and workload balancing. Together, the two planes realize each token service through four logical stages. 1) Token Request Collection: An access satellite in the space edge subnetwork receives a user prompt and its associated QoS requirements, including the requested AI model, output modality, and token throughput. The prompt enters the token plane, while the service metadata are forwarded to the local control function. The control plane also records the request identifier and the user’s serving access satellite for subsequent routing and mobility management. 2) QoS-aware Edge–cloud Provider Selection: The control plane maps the QoS requirements to computing, memory, and communication demands, together with the corresponding latency constraints. For an MoE-based token service, for example, a higher output-quality target may require activating more experts, thereby increasing the computing workload and inter-satellite traffic during token generation. Based on the available resource and network states, the control plane selects an eligible token provider: either a nearby AI-enabled edge satellite or a SpaceDC. It then reserves the required resources, establishes the forwarding path, and directs the token plane to deliver the prompt to the selected provider. 3) Token Generation: At the selected provider, token generation then proceeds in two phases. The prefill phase processes the input-token sequence and constructs the KV cache,

whereas the decoding phase generates output tokens autoregressively. For a SpaceDC-based service, the gateway satellite orchestrates distributed inference across multiple computing satellites using tensor, pipeline, or other forms of model parallelism. A related example is SpaceMoE, which reduces token-generation latency in LEO networks through topologyaware placement of MoE layers and experts [10]. Intermediate activations and synchronization traffic are confined within the SpaceDC whenever possible, limiting traffic over longer edge– cloud links. For a lightweight edge service that fits within a single satellite, the selected edge satellite performs centralized inference using the allocated resources. 4) Token Delivery: Token delivery is pipelined with autoregressive decoding to reduce both time to first token and inter-token latency. Each newly generated token is detokenized and immediately forwarded through the token plane along the established delivery route. To preserve service continuity, the distributed control plane tracks the association between each active request and its serving access satellite. When user mobility or satellite motion triggers a handover, the control plane updates the delivery route and installs new forwarding entries without restarting token generation. Upon receiving the detokenized output, the serving access satellite streams it to the user over the space–ground downlink. IV. C ASE S TUDY: A C OMPARISON BETWEEN E DGE AND S PACE DC- BASED T OKEN S ERVICES A. Experimental Setup For the space edge subnetwork, we consider a 640-satellite polar LEO constellation deployed at an altitude of 500 km, comprising 32 orbital planes with 20 satellites per plane. Each satellite maintains at most four ISLs with adjacent satellites, forming a mesh topology with a linkless counterrotating seam between the first and last orbital planes. Every active ground user associates with its nearest visible satellite, which serves as the access satellite for its token service. Each access satellite provides a total downlink capacity of 10 Gbps, shared equally among its associated active users. The SpaceDC subnetwork comprises 20 dawn–dusk SSO clusters at an

6

Cumulative probability

1

tion and transmission delays from the computing satellite to the ground user. The latter is the arithmetic mean of per-user throughputs, each defined as the reciprocal of the E2E token latency, which is the sum of token generation and delivery latencies.

0.8 0.6 0.4

Space edge with 1% computing Space edge with 10% computing SpaceDC Computing

0.2 0

0

10

20

30

40

Token Delivery Latency (ms)

50

60

Average Token Throughput (Token/s per user)

(a) CDF of token delivery latency with different fractions of edge computing satellites.

SpaceDC only Space edge only 50% SpaceDC + 50% Edge

140 120 100 80 60 40 20 0

0

1

2

3

4

# Ground users (million)

(b) Average throughput under a user-demand sweep. Short Answer Interactive Chat

Agentic AI

Probability density

0.07

SpaceDC only Space edge only

0.06 0.05 0.04 0.03 0.02 0.01 0.00

0

20

40

60

80

100

Average Token Throughput (Token/s per user)

(c) Throughput density at 10 million users. Figure 5. Token-service performance under uniformly distributed demand across Earth’s surface.

altitude of 600 km, each containing 16 computing satellites. Each SpaceDC establishes at most four gateway links with visible LEO satellites. The network evolves over one-minute time slots; within each slot, its topology is modeled as a static graph, and tokens are routed along the shortest paths. For computing, we consider a 70-billion-parameter dense model with a workload of 140 billion floating-point operations (FLOPs) per generated token. Each SpaceDC computing satellite is assigned a computing throughput equivalent to one NVIDIA GB300 NVL72 rack-scale system, assuming a 100% sunlit fraction. The long-term effective computing throughput of each edge satellite is obtained by scaling this baseline according to its annual sunlit fraction. When a computing satellite concurrently serves multiple users, the latency of one decoding iteration is approximated as the aggregate workload required to generate one token for each served user divided by the satellite’s effective computing throughput. We evaluate SpaceAI-Infra using token delivery latency and average token throughput. The former is the sum of propaga-

B. Performance Comparison Fig. 5 evaluates the token-serving performance of SpaceAIInfra under uniformly distributed demand across the Earth’s surface. Specifically, Fig. 5(a) plots the cumulative distribution function (CDF) of token delivery latency at 1 million concurrent users for different fractions of LEO satellites equipped with edge AI computing, compared with “SpaceDC Computing.” At an edge-computing fraction of 10%, edge-based service achieves lower token delivery latency than its SpaceDCbased counterpart. This gain stems from shorter delivery paths between the edge computing satellites and terrestrial users. Reducing the fraction from 10% to 1%, however, substantially increases latency, as sparser edge computing satellites require longer routes to deliver tokens to users. Fig. 5(b) plots the average token throughput against the number of users for the three user-assignment strategies. The throughput decreases with user concurrency as users contend for shared computing and communication resources. At low concurrency, the edge-only case, in which all requests are served by edge satellites, outperforms its SpaceDC-only counterpart. Its throughput, however, degrades more rapidly and eventually falls below that of SpaceDC-based service. This crossover reflects the limited computing capacity and intermittent solar availability of edge satellites, whose widely separated geometry also prevents efficient resource pooling. By contrast, SpaceDCs sustain relatively stable throughput by pooling formation-flying computing nodes under nearcontinuous solar exposure. The equal-split case exceeds both single-tier cases at intermediate concurrency, but falls below SpaceDC-only service at the highest concurrency. Fig. 5(c) plots the probability density function (PDF) of user token throughput under 5 million concurrent users. The SpaceDC-only case provides most users with sufficient throughput for interactive chat, with a smaller fraction supporting agentic AI services. Edge-only operation is largely limited to short-answer services, with approximately 32% of users attaining the throughput required for interactive chat. These results highlight the essential role of SpaceDCs in supporting Space Cloud AI under massive user concurrency. Fig. 6 maps the geographical distribution of yearly-average E2E token latency for services from space edge (left) and SpaceDCs (right), using a shared color scale, when demand from 2 million concurrent users follows the Gridded Population of the World population-count data [11]. Under space edge service, densely populated regions, particularly East and South Asia, experience E2E token latencies exceeding 100 ms per token. Concentrated demand in these regions saturates the limited computing capacity of the overflying edge AI satellites. By pooling substantially greater computing capacity, SpaceDCs alleviate these regional bottlenecks.

7

20

40

60

E2E token latency per user (ms) 80

(a) Token services from space edge subnetwork

100

120

140

160

(b) Token services from SpaceDC subnetwork

Figure 6. Yearly-average E2E token latency per user under population-weighted token demand with the polar LEO access constellation.

V. C ONCLUDING R EMARKS

R EFERENCES

We have proposed an edge–cloud-integrated architecture for SpaceAI-Infra. Its key feature lies in the confluence of communication-centric and computing-centric satellite constellations for token services in space. In particular, LEObased free-flying constellations exploit their spatial distribution over the Earth to provide ubiquitous user access and global token delivery, while their long inter-satellite distances limit the tightly coupled computing required for data-center-scale token generation. This limitation is addressed by formationflying satellites operating in proximity along dawn–dusk sunsynchronous orbits, forming promising SpaceDCs for Space Cloud AI. Integrated with the space edge, these SpaceDCs are capable of delivering generated tokens to users anywhere on Earth. The proposed architecture raises several research directions. • Computing-efficient Topology of SpaceDCs: One emerging direction is the largely unexplored network topology of formation-flying satellite constellations. Its design requires a fusion of orbital dynamics and computing-efficient interconnect structures. For example, terrestrial butterfly or hierarchical interconnects among GPU racks may not readily satisfy satellite visibility and hardware constraints. This calls for new SpaceDC topologies and associated ISL control tailored to parallel computing. Such ISL control should support data-centerscale token exchange while remaining robust to radiationinduced link and node failures. • Space Edge-cloud Cooperative Token Generation: The cooperation is enabled by distributing foundation models across edge satellites and SpaceDCs for cooperative inference. Its implementation faces unique challenges different from terrestrial edge–cloud systems, such as asymmetric solar availability, limited ISL ports, and timevarying edge–cloud visibility. Addressing these requires rethinking the LLM inference workflow and exploiting inference-level degrees of freedom, such as model placement and token routing. Moreover, as cloud computing scales, the communication bottleneck may shift from space–ground access to edge–cloud ISLs. This shift calls for revisiting LEO constellation coverage: the space edge must cover not only terrestrial users, but also dawn–dusk SSO data centers.

[1] N. Bleier and R. Kumar, “Space datacenters,” Computer, vol. 59, no. 6, pp. 126–131, Jun. 2026. [2] G. Zhu, D. Liu, Y. Du, C. You, J. Zhang, and K. Huang, “Toward an intelligent edge: Wireless communication meets machine learning,” IEEE Commun. Mag., vol. 58, no. 1, pp. 19–25, Jan. 2020. [3] S. G. Turyshev, “Orbital data centers: Spacecraft constraints and economic viability,” 2026, arXiv:2604.27197. [4] NASA, “Launch services program rockets,” Last updated: Sep. 15, 2026. Accessed: Oct. 2, 2026. [Online]. Available: https: //www.nasa.gov/launch-services-program-rockets/ [5] B. Agüera y Arcas et al., “Toward a future space-based, highly scalable AI infrastructure system design,” Joule, Oct. 1, 2026, early access, Art. no. 102678, doi: 10.1016/j.joule.2026.102678. [6] O. Montenbruck and E. Gill, Satellite Orbits: Models, Methods and Applications. Berlin, Germany: Springer, 2000. [7] S. Roberts, “Announcing a second Local Zone in Los Angeles,” AWS News Blog, Aug. 27, 2020, Accessed: Oct. 6, 2026. [Online]. Available: https://aws.amazon.com/blogs/aws/announcing-asecond-local-zone-in-los-angeles/ [8] H. Wang et al., “Space computing constellation: System architecture, implementations, and challenges,” IEEE Internet Things J., vol. 13, no. 6, pp. 11 472–11 492, 2026. [9] G. I. Chaudhry et al., “Murakkab: Resource-efficient agentic workflow orchestration in cloud platforms,” in Proc. 20th USENIX Symp. Oper. Syst. Des. Implementation (OSDI), Jul. 2026, pp. 567–587. [10] Z. Wang, H. Yang, M. Sheng, K. B. Letaief, and K. Huang, “SpaceMoE: Realizing distributed mixture-of-experts inference over space networks,” 2026, arXiv:2605.00515. [11] CIESIN, Columbia University, “Gridded Population of the World, version 4 (GPWv4): Population count, revision 11,” NASA SEDAC, Palisades, NY, USA, 2018, doi: 10.7927/H4JW8BX5.

B IOGRAPHIES Zhanwei Wang is a research assistant professor with the Department of Electrical and Computer Engineering, The University of Hong Kong, Hong Kong. His research interests include wireless communications, edge intelligence, and space AI. Jianhao Huang is a postdoctoral fellow with the Department of Electrical and Computer Engineering, The University of Hong Kong, Hong Kong. His research interests include compressed sensing, semantic communications, and deep learning. Min Sheng [Fellow, IEEE] is a full professor and the director of the State Key Laboratory of Integrated Service Networks, Xidian University, Xi’an, China. Her research interests include mobile ad hoc networks, 5G mobile communication systems, and satellite communication networks. Kaibin Huang [Fellow, IEEE] is a professor with the Department of Electrical and Computer Engineering, The University of Hong Kong, Hong Kong. His research interests include mobile edge computing, edge AI, and 6G systems.

Related documents

• Space AI Infrastructure: Where the Edge Meets the Orbital Cloud#1327985
• What is AI?#134395
• AI-Driven Scientific Computing Workflows: A Systems Review of Orchestration, Execution, Reproducibility and Provenance#1035130
• AI-Driven Scientific Computing Workflows: A Systems Review of Orchestration, Execution, Reproducibility and Provenance#1006825
• Scalable AI and data processing strategies for hybrid cloud environments#706745