Tim Strnad | Search arXiv

arXiv2026

Where Should Agents Live? Energy-Memory Characterization of Agentic AI for the Edge-Cloud Continuum

As telecommunication networks evolve toward autonomous 5G-Advanced and 6G operations, agentic artificial intelligence (AI) workflows, where large language models (LLMs) execute multi-step reasoning, invoke diagnostic tools, retrieve domain knowledge, and coordinate across agent teams, are increasingly embedded across the edge-cloud continuum. While the biological brain accomplishes complex cognition on an exceptionally modest metabolic power budget of approximately 20W contemporary LLMs are profoundly energy- and memory-intensive, making sustainable lifecycle orchestration a critical operational priority. However, existing AI lifecycle metrics evaluate only isolated, single-model inferences or overlook multi-agent execution graphs entirely. Consequently, network operators lack foundational models to determine whether distributed agent communication incurs meaningful energy costs and where across edge-cloud tiers agent teams should physically reside. To address this gap, we introduce agentic-eCAL, generalizing the Energy Cost of AI Lifecycle (eCAL) metric to directed multi-agent workflows by coupling a closed-form two-rate single-call energy model (compute-bound prefill and memory-bound decode) with 7-layer OSI data transport. Grounded in hundreds of GPU benchmark configurations on NVIDIA A100 and H100, 16 open-weight models and 8 orchestration topologies, we validate components of the metric and study workflow placement implications. Our findings demonstrate that inter-agent text transport incurs 0.25% of workflow energy across 5G RAN, metro, and optical links. Therefore in edge-cloud agent placement the dominant energy cost of distribution is often not the transmission of inter-agent text itself, but the additional inference and context processing induced by that communication.

cs.AI↗

arXiv2026

A Configuration-First Framework for Reproducible, Low-Code Machine Learning: a Localization Use Case

As machine learning underpins more critical applications, the value of a reported result depends on whether it can be compared and repeated. In practice, this remains difficult: research groups often assemble their own tools for configuration, execution, versioning, and evaluation, while also repeating the domain-specific work such as dataset preparation and baseline implementation. We present a configuration-first design for application-specific ML experimentation frameworks that addresses these sources of repeated effort. An experiment is declared in human-readable configuration files; a workflow orchestrator executes each stage as an isolated process that communicates only through explicit inputs and outputs; and code, data, configurations, environment specifications, and generated artifacts are versioned together, so that a recorded run can be inspected and repeated. We instantiate the design as LOCALIZE for radio-localization research, which supplies preconfigured datasets, processing stages, model-development procedures, and experiment templates while leaving the underlying pipeline open to modification. A qualitative comparison against five experimentation platforms, together with controlled quantitative studies against matched Jupyter notebook and Kedro implementations, shows that for the localization workflows studied, changes covered by LOCALIZE's supplied components require fewer codebase edits, while total wall-clock time and peak memory usage remain comparable. In a controlled scaling experiment at 1x, 5x, and 10x the base dataset volume, total CPU and wall time grew sublinearly over the tested sizes.

cs.SE↗