CoEdgeSys: Cooperative Edge Systems
- CoEdgeSys is a family of collaborative edge systems where heterogeneous nodes coordinate to optimize computation, data access, and communication under multiple constraints.
- Its architectures decompose operations into local execution and coordinated control, enabling advanced techniques such as LLM-enhanced offloading and carbon-aware placement.
- The systems employ optimization, ILP, and learning-based control methods to manage trade-offs in latency, energy, privacy, and carbon emissions while ensuring robust performance.
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 (Guo et al., 7 May 2026). 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 (Hong et al., 8 Nov 2025, Wu et al., 19 Feb 2025, Akgul et al., 22 Oct 2025, Zhou et al., 5 Dec 2025, Zhu et al., 11 Nov 2025, Koukis et al., 8 Mar 2026).
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 (Hong et al., 8 Nov 2025, Guo et al., 7 May 2026).
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 (Zeng et al., 2020). “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 (Hale, 2021). 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 (Censi, 2015). 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 (Hong et al., 8 Nov 2025).
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 (Wu et al., 19 Feb 2025).
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 (Zhu et al., 11 Nov 2025, Koukis et al., 8 Mar 2026).
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 (Akgul et al., 22 Oct 2025).
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 (Zhou et al., 5 Dec 2025). CoRaiS inserts a territorial scheduler above a service-oriented control region, with each edge exporting compact state summaries rather than raw hardware telemetry (Hu et al., 2024).
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
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 (Hong et al., 8 Nov 2025).
CarbonEdge uses an ILP whose objective is operational emissions:
subject to resource capacity, latency, placement uniqueness, and power-state consistency. It later adds a carbon–energy trade-off objective
to expose the non-equivalence of carbon minimization and energy minimization (Wu et al., 19 Feb 2025).
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 (Guo et al., 7 May 2026).
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 (Hu et al., 2024).
GCoDE shifts the focus from pure scheduling to joint architecture–mapping search. Its objective is
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 (Zhou et al., 5 Dec 2025).
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 (Hong et al., 8 Nov 2025).
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 (Zeng et al., 2020). 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 (Zhou et al., 5 Dec 2025).
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 in low utilization, the system retains 97.5% of carbon savings while reducing energy by 67% relative to pure carbon minimization (Wu et al., 19 Feb 2025). 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 (Hong et al., 8 Nov 2025). 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
together with calibrated uncertainty to choose between edge-only generation, edge-plus-retrieval, selective abstention, and controlled escalation (Akgul et al., 22 Oct 2025).
5. Representative systems and empirical evidence
The diversity of CoEdgeSys instantiations is easiest to see comparatively.
| System | CoEdgeSys role | Representative result |
|---|---|---|
| CoEdge-RAG (Hong et al., 8 Nov 2025) | Hierarchical collaborative RAG serving | 4.23% to 91.39% gains over baselines |
| CarbonEdge (Wu et al., 19 Feb 2025) | Carbon-aware mesoscale placement | up to 78.7% regional reduction |
| LeDRL / CoEdgeSys (Guo et al., 7 May 2026) | 10-node Jetson offloading prototype | up to 60% success rate |
| GCoDE (Zhou et al., 5 Dec 2025) | GNN device-edge co-inference | up to 44.9× speedup |
| CoSense-LLM (Akgul et al., 22 Oct 2025) | Edge-first semantic cooperation | sub-second p95 on edge-dominant paths |
| CoRaiS (Hu et al., 2024) | 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 (Hong et al., 8 Nov 2025). 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 (Wu et al., 19 Feb 2025).
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 (Guo et al., 7 May 2026).
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 (Zhou et al., 5 Dec 2025).
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 (Zhu et al., 11 Nov 2025). 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 (Koukis et al., 8 Mar 2026).
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 (Hu et al., 2024).
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 (Wu et al., 19 Feb 2025, Hong et al., 8 Nov 2025, Koukis et al., 8 Mar 2026, Hu et al., 2024, Guo et al., 7 May 2026). 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 (Hale, 2021).
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
and feedback-coupled compositions can be solved via least fixed points on antichains (Censi, 2015). 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 (Hong et al., 8 Nov 2025). CarbonEdge highlights the need for migration of long-running applications, better network models, and multi-tenant fairness or carbon-budget mechanisms (Wu et al., 19 Feb 2025). GCoDE identifies the absence of multi-device collaboration, multi-hop hierarchies, and dynamic graphs in current device-edge GNN co-inference (Zhou et al., 5 Dec 2025). CODECO’s current validation remains limited in fleet scale and real wireless dynamics (Zhu et al., 11 Nov 2025). 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 (Hale, 2021).
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.