Source-linked AI summary
Workload-Aware Monitoring for AI-RAN
Babak Azkaei, Georgios Exarchakos, Kishor Chandra Joshi
TL;DR
Aggregate telemetry can report operating conditions without showing whether timing changes reflect workloads, processors, or measurement boundaries. The paper links radio-work descriptors to processing paths, timing, and context before comparing like with like. In 16 over-the-air experiments, hybrid dispatch has lower all-TB callback durations than direct GPU dispatch, with the separation located in small TBs.
Problem
Aggregate telemetry can obscure whether timing changes reflect workload mix, processor choice, or timing boundaries, despite shared CPU and GPU use in AI-RAN.
Source: §1 · p. 1Method
The framework links each work item’s workload, dispatch path, timing, and context, then associates records before aggregating like workloads.
Source: §2 · p. 1Results
Takeaways & Limitations
In this OTA PDSCH case, the observations motivate complementary CPU/GPU use; broader online dispatch adapting to load and co-located AI work is presented as a possibility.
Source: §5 · p. 2The logs do not identify whether processing delay, buffering, or link adaptation caused the different TB-size proportions.
Source: §4 · p. 2
Abstract
from arXiv · showhide
AI-RAN platforms are expected to share CPU and GPU resources between radio workloads and AI services. Aggregate telemetry reports operating conditions, but timing changes may reflect different workloads, processors, or measurement boundaries. We propose workload-aware monitoring that associates radio-work descriptors with processing paths, timing boundaries, and operating context before comparing like with like. In 16 over-the-air downlink experiments, hybrid dispatch (CPU for transport blocks (TBs) below 4,096 bytes and GPU otherwise) has 29.66% and 22.93% lower mean host-callback durations than direct GPU dispatch, without and with a synthetic GPU co-runner, respectively. Grouping locates the separation in small TBs, while large-TB callback-duration ranges overlap. These observations identify a candidate for complementary CPU/GPU use.
1 Introduction
Aggregate telemetry can obscure whether timing changes reflect workload mix, processor choice, or timing boundaries. The paper proposes a RAN-level monitoring layer that links each work item to what was processed, where it ran, what was timed, and operating conditions.
1 Introduction
- About 1,400 downlink TBs per second from one testbed phone make per-task records voluminous, while aggregates alone cannot explain timing changes.The motivating comparison found hybrid processing of small blocks lowered mean host-callback durations by about a quarter, but the average alone could not distinguish faster GPU processing, workload changes, or work moving to the CPU.Source: §1 · p. 1
- AI-RAN designs share CPU and GPU resources between radio processing and AI services, making processor-aware interpretation of radio timing relevant.The introduction cites software radio processing on CPUs and GPUs [1] [6] and shared GPUs with AI services.Source: §1 · p. 1
- A RAN-level monitoring layer is missing for linking each work item’s workload, execution path, timing boundary, and operating conditions.The authors illustrate the approach with over-the-air PDSCH processing.Source: §1 · p. 1
2 Workload-Aware Monitoring
The framework treats a work item as its unit of analysis and links workload, dispatch, timing, and context views. It associates records before aggregation and compares like workloads within each context.
2 Workload-Aware Monitoring
- Each work item, such as a PDSCH encoding request, is represented through linked workload, dispatch, timing, and context views.Native logs already pair TB descriptors with callback duration; optional Janus codelet or CUPTI records can add actual processor and GPU-output readiness information.Source: §2 · p. 1
- Associate records through shared work identifiers or jointly logged fields, then aggregate timing by workload class, processor, and context.The framework cautions against linking records by nearby timestamps alone and recommends per-context workload shares and timing, such as TB-size- and processor-labeled duration histograms.Source: §2 · p. 1
- Online monitoring updates bounded summaries as records arrive, whereas offline analysis applies the same associations to stored logs.Only workload-relevant KPIs receive chosen groupings; the case conditions callback duration on TB class and policy using online collection and offline analysis.Source: §2 · p. 1
3 Illustrative PDSCH Case
The illustrative case compares direct GPU dispatch with hybrid dispatch on an over-the-air PDSCH testbed. It records host-callback timing and analyzes retained callbacks from selected successful runs.
3 Illustrative PDSCH Case
- Hybrid dispatch sends TBs below 4,096 bytes to the CPU and larger TBs to the GPU; direct dispatch sends every TB to the GPU.The testbed uses an NVIDIA DGX Spark with an Arm CPU and GB10 GPU, an OCUDU base station, and a 20-MHz single-antenna link serving one phone; an optional co-runner emulates GPU sharing.Source: §3 · p. 2
- The measured host-callback duration spans processor entry to callback entry, rounded to 0.1 μs, and excludes pre-entry queueing and logger submission.Policy and TB size imply the execution path rather than tracing it, and GPU callbacks can precede output readiness.Source: §3 · p. 2
- The analysis retains 223,979 single-codeword callbacks from 16 selected successes, with four successes per setting.Later producer-log timestamps select [5,15) s after each traffic-control request, not exact callback-entry times.Source: §3 · p. 2
4 Results
Hybrid dispatch has lower all-TB callback durations than direct GPU dispatch in the reported run-mean comparison, with the separation located in small TBs. The run workloads vary in large-TB share, and the logs do not identify what caused those proportions to differ.
4 Results
- Using equal-weight averages of run means, hybrid’s all-TB callback durations were 29.66%/22.93% lower without/with the co-runner, respectively, locating an observed callback-time advantage.Source: §4 · p. 2
- 36.09% and 30.29% lower small-TB mean callback durations were observed under hybrid dispatch without and with the co-runner, respectively.Hybrid selects the CPU for small TBs while retaining CUDA for larger blocks.Source: §4 · p. 2
- Large-TB callback-duration ranges overlap, but this does not establish equal GPU performance, and direct-policy large-TB ranges use only three runs.Workload composition also varies: the large-TB share differs across runs, and results within one size category do not make workloads identical.Source: §4 · p. 2
- Receiver reports show near 30 Mbps and zero reported UDP loss over approximately 20-second intervals, while enabled logger/export counters report zero loss.These are reported scope measurements for the OTA case.Source: §4 · p. 2
5 Conclusion
In the OTA PDSCH case, workload-aware analysis locates lower small-TB host-callback durations under hybrid dispatch, where the configured path uses the CPU. The observations motivate complementary CPU/GPU use, while further timing, cutoff, and stage coverage remain next steps.
5 Conclusion
- Hybrid dispatch has lower small-TB host-callback durations in the OTA PDSCH case, where the configured path uses the CPU.The observations motivate complementary CPU/GPU use.Source: §5 · p. 2
- Next steps include online implementation, device-side completion timing, a cutoff sweep, and evaluation of additional stages such as PUSCH decoding.Source: §5 · p. 2
- Workload-aware monitoring could drive online CPU/GPU dispatch that adapts to load and co-located AI work.Source: §5 · p. 2