OCUDU CUDA on DGX Spark: 5G PHY Tests Show Up to 91× Speedups and an AI-RAN Path

By AiCybr Editorial · Published August 9, 2026

A new OCUDU research preprint shows what happens when a large part of an open 5G radio stack stops bouncing data between CPU and accelerator memory and instead keeps the physical-layer pipeline resident on a GPU.

The result is not a claim that a DGX Spark can make an entire cellular network 91 times faster. The measurements are kernel- and path-specific, and the authors describe them as preliminary. But several of the gains are large enough to make the architecture interesting: on an NVIDIA DGX Spark, the CUDA backend reports up to 10.3× faster PUSCH processing, 19.7× faster split-8 lower-PHY receive processing, 28.8× faster PRACH detection, and 91.4× faster O-RAN BFP12 decompression than the tested production CPU paths.

More importantly, the same GPU-resident pipeline is designed to leave room for learned channel estimation, neural receivers and other AI-RAN workloads beside standards-compliant 5G processing.

The primary source is the August 5 preprint, “GPU-Resident CUDA Acceleration for OCUDU 5G PHY and O-RAN Fronthaul: Architecture and Preliminary Performance”, by Matthew Pennybacker, Wan Liu, Andriy Kharchenko and Timothy O’Shea. The work is associated with DeepSig’s contribution to the open OCUDU ecosystem. It has not been presented here as peer-reviewed evidence.

Results at a glance

Workload / path	Reported GPU speedup vs tested CPU path	What it does
PUSCH	up to 10.3×	Processes the 5G uplink shared channel from user equipment to the base station
PDSCH	up to 2.7×	Processes the downlink shared channel from the base station to users
Split-8 lower-PHY RX	up to 19.7×	Handles lower-PHY receive transforms in the tested split-8 path
O-RAN BFP12 decompression	up to 91.4×	Decompresses block-floating-point IQ data on the fronthaul path
PRACH detector	up to 28.8×	Detects random-access preambles used when devices initially access the network
PUSCH 10% BLER threshold	CPU/GPU agreement within 0.064 dB	Accuracy check showing close agreement in the tested link sweeps

These figures should not be compared as though they were five measurements of the same workload. They cover different kernels, data paths and batching conditions. The 91.4× figure, for example, is a decompression result—not end-to-end 5G throughput, radio capacity or user data rate.

The key design choice: keep the radio pipeline on the GPU

GPU acceleration in a radio stack is useful only if the system does not spend too much time copying intermediate data back and forth.

The OCUDU CUDA backend described in the paper uses CUDA-visible resource grids, device-side soft-bit buffers, CUDA stream events, pinned staging memory and managed-memory policies so intermediate radio data can stay on the accelerator when the platform and radio split allow it.

That matters because a 5G physical layer is a chain rather than one large matrix multiplication. Receive processing can include transforms, channel estimation, equalization, demodulation, decoding and control operations, all under tight timing constraints. Accelerating one kernel but repeatedly returning data to the CPU can erase much of the benefit.

The authors therefore emphasize residency as much as raw CUDA implementation. The backend plugs into existing OCUDU interfaces for resource grids, PRACH buffers and channel processors rather than requiring the rest of the stack to be rewritten around one accelerator.

DeepSig’s July 28 OCUDU AI-RAN update says the CUDA-accelerated L1 implementation is available through the project’s hardware-acceleration working group. The broader OCUDU project is a permissively licensed open-source 5G CU/DU stack intended for commercial deployment and research.

Why DGX Spark is an interesting test platform

The measurements were taken on NVIDIA’s compact DGX Spark system, which combines an Arm host with the GB10 integrated CPU/GPU platform.

That makes the test notable for a reason beyond NVIDIA branding: this is not a conventional multi-socket base-station server with a large discrete accelerator installation. It is a relatively compact shared-memory-style development platform being used to exercise real radio-processing paths.

NVIDIA separately lists DGX Spark GB10 + ConnectX-7 as a supported combination for its Aerial CUDA-Accelerated RAN software. That does not make NVIDIA Aerial and the OCUDU CUDA backend the same software stack, but it shows that DGX Spark is already being positioned as a practical development target for accelerated RAN work rather than only local LLM experimentation.

A separate February preprint, “Six Times to Spare: LDPC Acceleration on DGX Spark for AI-Native Open RAN”, previously measured roughly 6× average GPU/CPU throughput improvement for an NR-like LDPC decoding workload using NVIDIA Sionna. That experiment was narrower and used high-level TensorFlow/Sionna components; the newer OCUDU work moves closer to an integrated open-RAN physical-layer backend.

What exactly is being accelerated

The new CUDA backend covers several portions of the 5G physical layer and fronthaul rather than one isolated decoder.

PUSCH and PDSCH

PUSCH and PDSCH carry most ordinary user data on the uplink and downlink. Their processing involves multiple stages, including modulation-related operations, channel estimation/equalization and coding paths.

The reported maximums—10.3× for PUSCH and 2.7× for PDSCH—also show why a single “GPU speedup” number would be misleading. Different directions and processing chains expose different bottlenecks.

PRACH

PRACH handles random access, including the preambles devices use when establishing initial access to a cell. The paper reports up to a 28.8× speedup for its tested PRACH detector path.

Split-8 lower PHY

In split-8 designs, more of the low-level radio-processing work remains on the centralized compute side than in common O-RAN 7.2x deployments. The paper reports up to 19.7× receive-side lower-PHY speedup with slot-shaped batching and scattered mapped zero-copy in the tested configuration.

That qualification matters: batching and memory mapping are part of the result, not incidental implementation details.

O-RAN fronthaul compression

Modern disaggregated RAN systems move IQ data between distributed compute and radio components. Compression reduces the bandwidth required on that fronthaul.

The paper accelerates O-RAN IQ compression/decompression and reports the largest headline number—91.4×—for BFP12 decompression. This is useful evidence that data movement and representation operations can become significant accelerator targets, but it should not be interpreted as a 91× improvement to cell capacity.

The AI-RAN connection is more than running an LLM next to the base station

AI-RAN is often described loosely as sharing GPU infrastructure between cellular processing and AI applications. The more technically interesting possibility is to put learned models inside the radio-processing loop.

The GPU-resident architecture gives those models direct access to data that is already on the accelerator. The paper identifies use cases including:

machine-learned channel estimation;
neural receivers;
learned signal-processing components; and
AI-native air-interface research.

DeepSig says its own OmniPHY neural receiver, OmniSIG spectrum-intelligence software and Axon learned air-interface work are being adapted to the same OCUDU dApp interfaces. Those are vendor statements about the surrounding ecosystem, not performance results from this preprint.

The distinction is important. An operator does not gain an AI-native radio simply by installing a GPU. The software stack needs stable interfaces, predictable timing and a way for AI components to consume radio data without repeatedly crossing CPU/GPU boundaries.

What the benchmark does not prove

The paper is useful because it reports concrete measurements, but its limits are just as important as the speedups.

It does not establish:

a 91× increase in end-to-end network throughput;
a 91× increase in spectrum efficiency;
production-scale multi-cell performance;
carrier-grade latency under every radio configuration;
an apples-to-apples comparison against dedicated baseband ASICs or FPGAs;
total-system power savings for a commercial deployment;
that every 5G workload benefits equally from GPU acceleration; or
that the preliminary results will reproduce unchanged on different CPUs, GPUs, NICs, radio units or O-RAN splits.

The CPU baselines were pinned to high-capacity cores, and individual tests use workload-specific batching and memory strategies. The correct reading is therefore that the authors found large acceleration opportunities in specific production code paths on the tested platform, not that they established a universal GPU multiplier for RAN workloads.

The close PUSCH BLER result is also worth noting. The authors report the CPU and GPU implementations’ 10% block-error-rate thresholds agreeing within 0.064 dB in the tested sweeps. That is an accuracy-consistency check, not proof of field performance across all channels and deployment conditions.

Why this matters for open 5G and 6G research

OCUDU grew from the open srsRAN CU/DU work into a broader Linux Foundation ecosystem intended to provide a vendor-neutral open RAN implementation. DeepSig describes its CUDA L1 contribution as one layer in that platform rather than a private extension accessible only to its own AI models.

That changes who can experiment with accelerated radio processing.

A research group can now study several layers together:

an open CU/DU implementation;
GPU-accelerated physical-layer kernels;
O-RAN fronthaul processing;
AI models operating close to the radio data path; and
future learned receiver or air-interface designs.

There are already alternative directions. A July preprint on AI-RAN using an Ascend 310B1 NPU demonstrated an end-to-end OFDM transceiver on an inference-oriented accelerator, illustrating that the underlying idea is not necessarily GPU-exclusive.

The broader engineering question is therefore becoming less “Can accelerators run radio workloads?” and more “Which radio functions belong on which accelerator, and how much data movement can the system eliminate while still meeting real-time requirements?”

The OCUDU work does not settle that question. It provides a concrete open implementation and an unusually detailed set of preliminary measurements on hardware small enough to be practical for serious lab work. For AI-RAN and early 6G experimentation, that may be more useful than another high-level architecture diagram.