Edge Deployment Scheme (EDS)
- EDS is a systems paradigm that defines how computation and services are strategically placed across edge, cloud, and mobile resources under resource constraints.
- It employs diverse mechanisms such as two-timescale frameworks, genetic algorithms, and graph-theoretic approaches to optimize deployment decisions.
- EDS significantly shapes runtime behavior by influencing resource utilization, fault tolerance, and dynamic service adaptation in heterogeneous computing environments.
Edge Deployment Scheme (EDS) denotes a heterogeneous class of mechanisms for deciding how computation, services, models, microservices, or supporting control logic are placed and operated across end devices, edge nodes, and cloud resources under storage, compute, bandwidth, latency, and topology constraints. In the cited literature, EDS is not a single standardized algorithm: some works study joint service deployment and task scheduling in collaborative mobile edge networks, others study edge discovery, multi-backend service publication, microservice placement, DNN partitioning, or deployment validation, yet all address the same systems question of where functionality should reside and how that placement shapes runtime behavior (Li et al., 22 Aug 2025, Zavodovski et al., 2018, Parthasarathy et al., 2023). This suggests that EDS is best understood as a systems paradigm centered on placement, feasibility, and adaptation rather than as a fixed formalism.
1. Scope, terminology, and problem setting
The canonical EDS problem arises because edge resources are intrinsically constrained. In mobile edge computing, each edge server has limited storage, computation, and bandwidth, so no single node can host or execute everything; collaborative edge computing therefore uses workload sharing and task co-processing across multiple nodes (Li et al., 22 Aug 2025). In service-offloading settings, deployment is a prerequisite for execution: a user equipment can only offload a task to an edge node if the required service or microservice is already cached there (Song et al., 2022). In generative AI settings, the same issue appears in another form: edge servers can deploy only a subset of large models, and cold-start behavior includes transmission, I/O preloading, and inference delay rather than inference alone (Liang et al., 2024).
The literature uses the deployment concept across several layers of abstraction. Some works treat deployment as selecting which services should be placed at which edge servers and how subsequent tasks are routed (Li et al., 22 Aug 2025). Some treat it as discovering candidate edge nodes along a network path and then deciding where deployment is possible (Zavodovski et al., 2018). Others treat deployment as exporting a composed service to a chosen runtime backend such as Docker, JavaScript, or MirageOS (Zhao et al., 2018). In clustered inference and microservice systems, deployment instead means mapping model partitions or microservice instances onto physical nodes and links while respecting resource and topology constraints (Parthasarathy et al., 2023, Chen et al., 9 Jan 2025).
| EDS interpretation | Primary decision | Representative works |
|---|---|---|
| Deployment-plus-scheduling | Which services/models to place, then how to route or schedule tasks | (Li et al., 22 Aug 2025, Song et al., 2022, Liang et al., 2024) |
| Discovery/publication substrate | How candidate edge nodes and deployable services become visible and publishable | (Zavodovski et al., 2018, Zhao et al., 2018) |
| Partitioned inference or microservice placement | How model slices or microservice instances map to edge nodes and paths | (Parthasarathy et al., 2023, Chen et al., 9 Jan 2025, Ge et al., 2024) |
| Deployment observability and validation | How deployed edge pipelines are inspected for correctness and performance | (Qiu et al., 2021) |
A recurrent source of confusion is that the acronym itself is not uniform. One security paper uses EDS to denote Economic Denial Security rather than Edge Deployment Scheme (Singh et al., 29 Dec 2025). The deployment literature is therefore more coherent at the level of problem structure than at the level of acronym standardization.
2. Architectural patterns and control timescales
A central architectural pattern is decomposition by timescale. A two-timescale framework splits time into coarse-grained frames and fine-grained slots, uses the large timescale for service deployment, and uses the small timescale for task scheduling (Li et al., 22 Aug 2025). This separation reflects operational asymmetry: changing placement affects storage occupancy and has persistent effects, whereas routing or scheduling must respond to immediate demand. The same logic appears indirectly in round-based systems such as eDisco, where discovery, deployment, and real-time redirection are executed in rounds because server placement does not typically change constantly (Zavodovski et al., 2018).
Another pattern is collaborative decomposition across resource tiers. CoEL defines a closed-loop architecture with four components—Perception, Deployment, Compression, and Updating—and distinguishes intra-device collaboration, such as GPU memory, CPU memory, SSD, and I/O pipelines on one edge server, from inter-device collaboration, where multiple edge servers jointly host an MoE LLM (Li et al., 12 Feb 2025). A related but model-centric design appears in collaborative edge-cloud AIGC hosting, where the cloud maintains the full model library and the edge maintains a dynamically selected subset of models based on resource state and request dynamics (Liang et al., 2024).
Production-oriented EDS designs also separate planning, orchestration, and runtime. In edge-cluster DNN inference, a dispatcher is elected, pairwise bandwidth is measured, a cluster-wide NFS server stores partitions, Kubernetes Deployments instantiate inference pods, and runtime containers load compressed partitions, execute inference, and exchange intermediate outputs through TCP and FIFO-based I/O paths (Parthasarathy et al., 2023). This broadens deployment from placement alone to lifecycle management, fault tolerance, and live reconfiguration.
These architectural patterns imply that EDS is usually not a single monolithic optimizer. It is more often a layered control stack in which discovery, planning, deployment, execution, and updating exchange state over time.
3. Optimization models and constraint structure
The mathematical structure of EDS varies by workload, but several objective families recur. In collaborative edge networks, the dominant objective is expected task-processing delay. One representative formulation minimizes the long-term average delay
subject to storage, feasibility, and probability constraints, including binary deployment variables and continuous scheduling probabilities (Li et al., 22 Aug 2025). Because deployment is discrete and scheduling is continuous, this becomes a two-timescale mixed-integer nonlinear programming problem and is NP-hard.
In multi-application MEC microservice deployment, the objective is weighted response latency across applications with different priorities:
subject to CPU, memory, and minimum-instance constraints (Ge et al., 2024). Here the deployment state determines both computation delay and transmission delay along application DAGs, and resource contention directly perturbs the latency term.
In partitioned DNN inference on edge clusters, the objective is bottleneck communication latency, which determines throughput. In the regime studied there, communication often dominates compute, so the deployment target becomes
that is, minimizing the maximum transfer-time-to-bandwidth ratio across partition boundaries (Parthasarathy et al., 2023). This formulation makes deployment explicitly communication-aware rather than purely compute-aware.
Generative AI deployment introduces a broader resource-delay trade-off. One model-level formulation uses binary deployment variables , enforces storage, GPU memory, and energy constraints, and minimizes a time-averaged combination of switching cost and resource cost, where switching cost includes transmission delay, I/O preloading delay, and inference delay (Liang et al., 2024). This makes cold-start effects first-class citizens of deployment optimization.
Across these formulations, the constraint set typically includes one or more of the following: storage capacity, CPU and memory budgets, bandwidth or link-capacity limits, feasibility constraints that prohibit routing to undeployed services, coverage constraints that require all experts or microservices to be hosted somewhere, and probabilistic or priority constraints governing routing or queueing. The convergence of these constraints across otherwise different application domains is one of the strongest unifying features of EDS.
4. Algorithmic families
The most characteristic EDS algorithms are hybrid. In two-timescale collaborative service deployment, the small-timescale task scheduling subproblem is convex and solved with CVXPY, while the large-timescale deployment problem is handled by a DDQN-based multi-agent deep reinforcement learning scheme; the two are coupled through the TTOSC alternating-optimization loop (Li et al., 22 Aug 2025). This combination cleanly separates fast continuous control from slower combinatorial placement.
Graph-theoretic formulations are also common. SD-AETO models deployment with an approximate deployment graph whose node weights capture microservice counts on MEC servers and whose edge weights capture approximate overlap; it then transforms a quota Steiner tree objective into a k-MST instance to obtain a popularity-aware service deployment, after which task offloading uses a priority queue derived from service popularity and offloading direction (Song et al., 2022). In eDisco, the graph is not an optimization graph but a discovered cloud-to-client path/tree built from traceroute, PTR or WHOIS mapping, and DNS SRV records; deployment is then performed over that discovered substrate (Zavodovski et al., 2018).
Genetic algorithms appear repeatedly in deployment settings with heterogeneous resources. The feature-aware AIGC framework uses a GA-based model-level decision selection method over deployment vectors to avoid exponential brute-force search (Liang et al., 2024). TAIA-MD augments a topology-aware GA with a small number of greedy-generated “super individuals” so that initialization already encodes good topology-sensitive placements, reducing iterations and mitigating local optima (Chen et al., 9 Jan 2025).
Heuristic decomposition is another major pattern. CAMD decomposes multi-application microservice deployment into single-microservice blocks in a Block Coordinate Descent style, optimizes each block with Simulated Annealing using swap-based neighborhoods, and repairs infeasible solutions by migration (Ge et al., 2024). For DNN cluster deployment, candidate cut points are extracted from the model DAG, feasible contiguous subarrays are assembled into a partition graph, and placement over the communication graph is solved with a -path strategy that matches large transfers to high-bandwidth paths (Parthasarathy et al., 2023).
Model-compression-aware EDS adds a different algorithmic layer. HAQ first performs adaptive activation smoothing and Hessian-aware row-wise weight quantization for W8A8 deployment, then combines expert-level CPU-GPU partitioning, runtime latency comparison, and LRU-based GPU expert caching to decide whether an MoE expert should remain on CPU or be transferred to GPU (Zhang et al., 10 Aug 2025).
5. Substrates, runtimes, and representative application domains
EDS is implemented over a wide range of substrates. eDisco uses standard Internet mechanisms—traceroute, DNS PTR, WHOIS, DNS SRV, and HTTP 302 redirection—to discover edge servers and redirect clients without modifying deployed infrastructure (Zavodovski et al., 2018). Zoo provides a typed service abstraction with create_service, compose_service, and publish_service, and publishes composed data-analytics services to Docker containers, JavaScript, or MirageOS, thereby decoupling service composition from deployment backend selection (Zhao et al., 2018).
Stream-processing EDS emphasizes placement by profile and location rather than by explicit host enumeration. R-Pulsar organizes edge and cloud resources into a quadtree-based, location-aware overlay, maps profiles through a Hilbert space-filling curve, uses a memory-mapped queue for data collection, stores data through a DHT and RocksDB, and extends serverless execution to edge nodes through store_function and start_function actions (Renart et al., 2018). This shows that deployment can be reactive and content-driven rather than solely optimizer-driven.
Microservice deployment makes network topology explicit. TAIA-MD uses a three-tier service–microservice–edge-node traffic model to map invocation structure to actual link traffic, estimate communication delay through path-level bandwidth occupancy, and optimize placement under CPU, memory, and bandwidth constraints (Chen et al., 9 Jan 2025). CAMD adds contention awareness, recognizing that co-located microservices from multiple applications compete for finite CPU and memory and therefore alter end-to-end response time (Ge et al., 2024).
Large-model deployment extends EDS beyond classical MEC services. CoEL uses Hello-message-based perception, intra-device and inter-device collaboration, mixed-precision expert quantization, token fusion, pruning, and periodic updating for edge MoE LLMs (Li et al., 12 Feb 2025). HAQ-based deployment focuses on joint 8-bit quantization and CPU-GPU collaborative inference for Mixtral and OPT-series models (Zhang et al., 10 Aug 2025). AIGC deployment adds storage/GPU-memory heterogeneity and I/O preloading delay as primary placement factors (Liang et al., 2024).
Other domains confirm the breadth of the paradigm. In blockchain-enabled Internet of Vehicles, RSUs are treated as edge servers, and deployment means choosing equal spacing distances that maximize vehicle coverage subject to probabilistic connectivity guarantees (Xu et al., 2020). This differs from service caching or model placement, but it still fits the core EDS question of where edge capability should be physically instantiated.
6. Evaluation practice, empirical behavior, and recurring misconceptions
EDS papers are typically evaluated with latency-centric, resource-centric, or coverage-centric metrics rather than with a single universal benchmark. Two-timescale collaborative service deployment reports convergence after about 800, 1000, 1500, and 2000 episodes for cells, respectively, and average execution times of 0.00721 s for small-timescale scheduling and 0.01939 s for large-timescale deployment (Li et al., 22 Aug 2025). Feature-aware AIGC deployment reports that when storage is 120 GB and GPU memory is 12 GB, the proposed method reduces average cost by 56.06% to 76.73% compared with baselines (Liang et al., 2024).
In microservice systems, TAIA-MD reports approximately 30% to 60% communication-delay improvement over existing schemes in simulation, about 50% fewer iterations than its non-adaptive version, and practical robustness under link failure and throttling on a Raspberry Pi and Orange Pi testbed (Chen et al., 9 Jan 2025). CAMD reports latency reductions of 28.60%, 41.89%, and 47.69% over the best baseline as application complexity increases, and reproduces its latency advantage on a Kubernetes cluster running Flappy Bird cloud game, Sock Shop, and GitLab (Ge et al., 2024).
In partitioned DNN inference, the cluster framework reports bottleneck-latency reductions by about 10x over a random baseline and an average approximation ratio of 1.092 to the optimal bottleneck latency, while also showing node, network, and system-I/O fault tolerance (Parthasarathy et al., 2023). HAQ-based MoE deployment reports that GPU memory usage is reduced by about 60%, with low-bit perplexity close to full precision on Wikitext2 and C4, and that its two-stage expert-placement strategy improves stability relative to a pure frequency-based scheme (Zhang et al., 10 Aug 2025).
A further misconception is that deployment ends once binaries are placed. ML-EXray demonstrates that edge deployment quality can collapse because of preprocessing bugs, quantization issues, and suboptimal kernels, and reports that fixing such issues can recover up to 30% accuracy and improve kernel latency by two orders of magnitude while requiring less than 15 lines of code to examine the full pipeline (Qiu et al., 2021). This suggests that observability and validation are operational components of EDS, not merely post hoc debugging conveniences.
Another common simplification is to equate deployment with static caching. The literature repeatedly argues against this view: demand is spatiotemporally non-uniform in collaborative MEC (Li et al., 22 Aug 2025), service popularity varies over time in service-deployment-enabled offloading (Song et al., 2022), model request patterns are location-dependent in AIGC hosting (Liang et al., 2024), and token distributions, expert popularity, topology, and resource status evolve in edge LLM deployment (Li et al., 12 Feb 2025). Dynamic adaptation, rather than one-shot placement, is therefore a defining property of advanced EDS designs.
Taken together, these results establish EDS as a cross-cutting edge-systems construct. Whether the object being deployed is a microservice, an analytics pipeline, a quantized MoE expert, a DNN partition, a DNS-advertised edge node, or an RSU-backed blockchain miner, the essential problem remains the same: deployment decisions reshape the feasible execution region, the communication pattern, and the latency-resource trade-off of the entire edge system.
