---
title: 'CoEdgeSys: Cooperative Edge Systems'
url: https://www.emergentmind.com/topics/coedgesys
type: topic
---

# CoEdgeSys: Cooperative Edge Systems

Searching arXiv for papers explicitly using or contextualizing “CoEdgeSys” and closely related cooperative edge systems.
CoEdgeSys denotes a family of collaborative edge systems in which multiple heterogeneous edge nodes coordinate computation, data access, and communication under explicit service constraints such as latency, energy, carbon, privacy, or reliability. In current arXiv usage, the term has both a narrow and a broad sense. In the narrow sense, it is the name of the Jetson-based prototype used to validate LLM-enhanced task offloading in collaborative edge computing [2605.05727]. In the broader sense, it functions as a systems lens for architectures that decompose edge intelligence into coordinated local execution and global or hierarchical control, including retrieval-augmented LLM serving, carbon-aware placement, multimodal semantic processing, GNN co-inference, and cognitive orchestration across robot fleets and edge-cloud infrastructures [2511.05915; 2502.14076; 2510.19670; 2512.11856; 2511.08354; 2603.07621].

## 1. Terminology, scope, and historical lineage

The literature does not present a single canonical software stack called CoEdgeSys. Instead, the term is attached to a recurrent problem class: cooperative edge systems that must exploit distributed data and heterogeneous resources without collapsing into cloud-only offloading or single-node optimization. CoEdge-RAG states that it is “best understood as a concrete instantiation of a ‘CoEdgeSys’ for LLMs with RAG,” whereas LeDRL uses CoEdgeSys as the deployed prototype system on which its scheduler is realized and tested [2511.05915; 2605.05727].

This usage sits within a broader lineage of cooperative edge research. “CoEdge: Cooperative DNN Inference with Adaptive Workload Partitioning over Heterogeneous Edge Devices” formulates cooperative inference as adaptive workload partitioning that minimizes dynamic energy under latency constraints, but it does not define a separate artifact called CoEdgeSys [2012.03257]. “Coalescent Computing” pushes the idea further toward a proximity-driven fabric in which user devices dynamically “coalesce” nearby disaggregated edge resources, exposing them as elastic extensions of the device rather than as a distant offload target [2104.07122]. A plausible implication is that CoEdgeSys can be read as the systems realization of this collaborative-edge trajectory: from cooperative task partitioning, to orchestrated multi-node edge clusters, to explicitly co-designed edge fabrics.

A second conceptual lineage comes from formal co-design. “A Mathematical Theory of Co-Design” is not an edge paper, but it provides a rigorous vocabulary for coupled subsystem design problems, Pareto antichains, and feedback loops solved by least fixed points [1512.08055]. This suggests a useful formal interpretation of CoEdgeSys as a co-design problem whose subsystems include schedulers, models, networks, sensors, and energy sources.

## 2. Canonical architecture

Across the recent literature, CoEdgeSys architectures exhibit a recurring decomposition into local execution planes and coordinating control planes. In CoEdge-RAG, the architecture is a global coordinator plus multiple heterogeneous edge nodes, each with its own private corpus, vector database, and model pool. The coordinator performs query encoding, PPO-based online query identification, and inter-node scheduling, while each node performs local Faiss retrieval, prompt construction, and intra-node scheduling over models and GPUs. Privacy is enforced by keeping raw documents local; only scores, embeddings, and metrics are shared [2511.05915].

CarbonEdge instantiates the same pattern for carbon-aware placement. Built on Sinfonia, it separates a Telemetry Service, Carbon Intensity Service, Profiling Service, Placement Service, and Edge Orchestrator. Placement is centralized at the control plane, but execution remains at mesoscale edge data centers and PoPs, with hard latency constraints and explicit server power-state management [2502.14076].

CODECO expresses the pattern in Kubernetes terms. Its architecture comprises ACM, MDM, NetMA, PDLC, and SWM, extending rather than replacing Kubernetes. ACM is the entry point for application requirements via the CODECO Application Model; NetMA contributes network probing and secure L2 overlays through L2S-M; PDLC computes node weights and stability estimates; SWM performs placement and migration; MDM turns data freshness and age of information into orchestration inputs [2511.08354; 2603.07621].

CoSense-LLM applies the same decomposition to continuous multimodal sensing. Its four-part stack—SenseFusion, Edge-RAG, PromptRouter, and Secure Execution—makes the edge node a semantic front-end rather than a mere relay. Sensor windows are transformed into compact semantic codes locally; retrieval is performed against site-specific corpora; routing decides among edge-only generation, edge-plus-retrieval, or compact cloud escalation; and raw waveforms never leave the device [2510.19670].

GCoDE and CoRaiS extend the architectural pattern to inference and scheduling. GCoDE treats communication as an explicit graph operation inside a device-edge co-inference engine, enabling operation-level pipeline parallelism between device and edge [2512.11856]. CoRaiS inserts a territorial scheduler above a service-oriented control region, with each edge exporting compact state summaries rather than raw hardware telemetry [2403.09671].

## 3. Scheduling, optimization, and learning mechanisms

A central characteristic of CoEdgeSys is that coordination is not ad hoc; it is posed as an explicit optimization or control problem. CoEdge-RAG is a three-level example. Its global query router learns query-to-node affinities with policy-only PPO; its inter-node scheduler caps node assignments using an empirical capacity model
$$
C_n(L^t) = k_n L^t + b_n;
$$
and its intra-node optimizer allocates query proportions, memory fractions, and deployment states to maximize expected quality under latency constraints and model load/reload overheads [2511.05915].

CarbonEdge uses an ILP whose objective is operational emissions:
$$
f =
\sum_i \sum_j x_{ij} \cdot E_{ij} \cdot \bar{I}_j
+
\sum_j (y_j - y_j^{curr}) \cdot B_j \cdot \bar{I}_j,
$$
subject to resource capacity, latency, placement uniqueness, and power-state consistency. It later adds a carbon–energy trade-off objective
$$
\alpha \cdot p + (1-\alpha)\cdot f
$$
to expose the non-equivalence of carbon minimization and energy minimization [2502.14076].

LeDRL, whose real deployment is named CoEdgeSys, formulates collaborative offloading as a Dec-POMDP. Each node observes local queueing, failure, and link features, constructs a structured prompt, queries a lightweight LLM, and fuses the LLM suggestion with a PPO-style actor through a self-attention alignment module. The deployed actor network has three fully connected layers and total size below 100 KB, which is critical for Jetson-class devices [2605.05727].

CoRaiS begins from an ILP-style objective—minimize the worst edge completion time—and then replaces exact optimization with an attention-based policy network that encodes edge states, request states, and their compatibility. The result is a lightweight real-time scheduler that retains near-optimal quality while reducing decision latency from seconds to hundredths of a second on medium instances [2403.09671].

GCoDE shifts the focus from pure scheduling to joint architecture–mapping search. Its objective is
$$
\arg \max_{\alpha \in \mathbb A}
\left[ acc_{val}(\mathcal W^*, \alpha) - \lambda \mathcal P_{sys}(\alpha, \mathcal D, \mathcal E, \mathcal S) \right]
$$
under explicit latency and on-device energy constraints, where communication is treated as an explicit operation in the search space. This fuses model architecture and placement into one design variable rather than two sequential decisions [2512.11856].

## 4. Objective space: latency, quality, energy, carbon, privacy

A common misconception is that CoEdgeSys is primarily about latency. The literature shows a broader multi-objective regime. CoEdge-RAG optimizes a latency–quality trade-off: routing affects retrieval quality, while intra-node scheduling determines whether larger or smaller models are feasible under slot-level latency budgets. Its reward combines ROUGE-L and BERTScore, and the scheduler adapts model sizes as latency headroom changes [2511.05915].

CoEdge, the earlier cooperative DNN system, makes dynamic energy the primary objective and treats latency as a hard deadline. It minimizes computation plus communication energy while partitioning CNN inference across heterogeneous devices [2012.03257]. GCoDE similarly couples accuracy, latency, and on-device energy for GNNs, but exposes that this coupling must be reasoned about at operation granularity because KNN, Aggregate, and Combine exhibit different latency and power behavior on Jetson TX2, Raspberry Pi, Intel CPU, and GPU platforms [2512.11856].

CarbonEdge adds a different dimension: grid carbon intensity. Its results show that carbon-aware and energy-aware optimization are not interchangeable. In heterogeneous clusters, Intensity-aware and CarbonEdge can consume up to 12× and 5.5× more energy than Energy-aware, respectively, in some scenarios, even while sharply reducing emissions. The multi-objective variant shows that, at $\alpha=0.1$ in low utilization, the system retains 97.5% of carbon savings while reducing energy by 67% relative to pure carbon minimization [2502.14076]. This directly rebuts the assumption that a “green” CoEdgeSys is automatically energy-minimal.

Privacy is equally first-class in several systems. In CoEdge-RAG, no raw documents are shared; only scores, embeddings, and metrics circulate among nodes [2511.05915]. In CoSense-LLM, the boundary is even stricter: raw RF, audio, IMU, and other waveforms never leave the edge node, and only discrete codes plus redacted metadata are eligible for cloud escalation. PromptRouter uses a cost model
$$
\mathcal{C} =
\alpha\cdot \widehat{\text{lat}}
+
\beta\cdot \widehat{\text{energy}}
+
\gamma\cdot \widehat{\text{tokens}}
+
\delta\cdot \widehat{\text{risk}}
$$
together with calibrated uncertainty to choose between edge-only generation, edge-plus-retrieval, selective abstention, and controlled escalation [2510.19670].

## 5. Representative systems and empirical evidence

The diversity of CoEdgeSys instantiations is easiest to see comparatively.

| System | CoEdgeSys role | Representative result |
|---|---|---|
| CoEdge-RAG [2511.05915] | Hierarchical collaborative RAG serving | 4.23% to 91.39% gains over baselines |
| CarbonEdge [2502.14076] | Carbon-aware mesoscale placement | up to 78.7% regional reduction |
| LeDRL / CoEdgeSys [2605.05727] | 10-node Jetson offloading prototype | up to 60% success rate |
| GCoDE [2512.11856] | GNN device-edge co-inference | up to 44.9× speedup |
| CoSense-LLM [2510.19670] | Edge-first semantic cooperation | sub-second p95 on edge-dominant paths |
| CoRaiS [2403.09671] | Real-time multi-edge scheduler | about 0.02 s on medium instances |

The concrete systems differ sharply in workload, but their results are structurally similar. CoEdge-RAG reports 4.23% to 91.39% performance gains over baseline methods across all tasks, with PPO-based query identification approaching Oracle routing, inter-node scheduling mitigating domain skew, and intra-node scheduling adapting model size to slot-level SLOs [2511.05915]. CarbonEdge reports up to 78.7% emissions reduction in a regional edge testbed in Central Europe, together with 49.5% and 67.8% savings in US and Europe CDN-scale experiments, while respecting latency SLOs [2502.14076].

LeDRL’s CoEdgeSys prototype consists of 10 heterogeneous Jetson nodes—4 Jetson Nano and 6 Jetson Xavier NX—connected by wired Gigabit LAN, with YOLOv8 tasks offloaded over gRPC and Qwen3-4B hosted on a central RTX 4090 server. Under random denial-of-service intervals and a 4 s end-to-end deadline, it achieves success rates up to 60% and outperforms the best baseline by 13.5% on the real testbed [2605.05727].

GCoDE reports up to 44.9× speedup and 98.2% energy reduction compared to existing approaches, while keeping accuracy comparable to hand-designed and NAS baselines. Its search completes in 1.5 GPU hours for ModelNet40 and 0.2 GPU hours for MR, which is notable given that architecture and placement are co-optimized rather than searched sequentially [2512.11856].

For orchestration-centric systems, the evidence is different but equally instructive. The AMR case study of CODECO reports reduced CPU consumption and more stable communication patterns than standard Kubernetes, at the cost of modest memory overhead of 10–15% and slightly increased pod lifecycle latency due to secure overlay initialization [2511.08354]. The broader CODECO toolkit evaluation shows that automation can reduce manual effort by roughly 75–90% across cluster deployment, Kubernetes installation, and service deployment, while keeping CPU and energy overhead modest, though memory overhead remains substantial [2603.07621].

CoRaiS demonstrates that a learned scheduler can preserve high decision quality while achieving real-time behavior: around 0.02 s on medium-scale instances, and about 4.6 s even at 2000 edges, 1000 control-region edges, and 15000 requests. Its characteristic-validation experiments show emergent load balancing, workload perception, and heterogeneity recognition rather than simple myopic dispatch [2403.09671].

## 6. Formal interpretation, misconceptions, and open problems

A persistent misconception is that CoEdgeSys is a single deployment pattern. The evidence instead shows multiple coordination regimes: centralized ILP in CarbonEdge, hierarchical scheduling in CoEdge-RAG, decentralized or profile-driven Kubernetes extensions in CODECO, attention-based RL in CoRaiS, and hybrid LLM–DRL control in LeDRL [2502.14076; 2511.05915; 2603.07621; 2403.09671; 2605.05727]. Another misconception is that cooperative edge systems are merely cloud offloading with shorter links. Coalescent Computing explicitly rejects that framing, advocating a model in which nearby resources become ephemeral extensions of the device, governed by latency and mobility rather than by a static local/remote dichotomy [2104.07122].

The co-design literature provides a useful formal lens for these systems. In the language of monotone co-design, a subsystem can be represented as a design problem with implementation
$$
\mathrm{dp} = (F, R, J, \mathsf{exec}, \mathsf{eval}),
$$
and feedback-coupled compositions can be solved via least fixed points on antichains [1512.08055]. This suggests that a rigorous CoEdgeSys formalization would treat latency, quality, coverage, or semantic fidelity as functionality spaces, and energy, carbon, memory, bandwidth, and trust exposure as resource spaces. The implication is not yet a standard practice, but it clarifies why these systems repeatedly surface Pareto fronts rather than single optima.

Open problems are consistent across papers. Network modeling remains simplified in several systems; CoEdge-RAG explicitly notes the value of modeling latency, jitter, and bandwidth more explicitly beyond small-cluster assumptions [2511.05915]. CarbonEdge highlights the need for migration of long-running applications, better network models, and multi-tenant fairness or carbon-budget mechanisms [2502.14076]. GCoDE identifies the absence of multi-device collaboration, multi-hop hierarchies, and dynamic graphs in current device-edge GNN co-inference [2512.11856]. CODECO’s current validation remains limited in fleet scale and real wireless dynamics [2511.08354]. Coalescent Computing raises a more foundational concern: when edge resources are ephemeral and possibly untrusted, security, attestation, and resource naming become first-order systems problems rather than implementation details [2104.07122].

Taken together, these works show that CoEdgeSys is best understood not as a single framework but as a research program: the systematic co-design of edge-side execution, inter-node coordination, learning-based control, and resource-aware objective functions for collaborative computation at the edge.

Source: https://www.emergentmind.com/topics/coedgesys