Latency is an interesting thing, its always part of the SDR pipeline since you have filter delays and processing delays. Most digital streams are uni-directional so you get the bits out, just shifted by 'x' nS. Since the 'x' is deterministic you can plan for it.
This design pattern is a common of nearly all SDR frameworks (Gnuradio, Redhawk, Pothos, Etc.) The "interconnect" between processing elements is typically shared memory, and that is why it lends itself to GPU work as well.
That said, since my head is most comfortable thinking in C, I tend to write stuff in C rather than Python :-).
https://www.ericsson.com/en/blog/2020/4/hardware-acceleratio...
I don't know if this involves baseband processing or just protocols and tighter coupling of applications to the network to reduce overall latency.
This effort is certainly driving a reduction in jitter which is currently an issue with many realtime GPU applications.
I'm no expert on SDR, but it seems to me that SDRs are the high bandwidth and parallel workloads where GPUs excel in. (GPUs can perform fourier transforms very efficiently)
The only possible qualm would be the latency of a GPU. But I don't imagine that SDR workloads are very latency sensitive? Or am I mistaken there?
GPU kernels are just software, but the parallel nature of GPUs means that it's better if most of the GPU is sharing the same code (very small L1 code cache per thread). So it's far more flexible than a FPGA but somewhat less flexible than a CPU (where different cores and threads can be executing very different code with large and unique L1 caches)