Let me put this out there straight – 6G is not going to be a GPU only show, at least not entirely. There's a pattern I keep noticing across these operator conversations, and it's fairly consistent. The real question isn't which chip wins. It's how do you handle real-time, low-latency applications that also need proper traffic management, right there at the edge.
This is not just a paper exercise for Rakuten Symphony as we have been actively working on incorporating AI RAN to our products. On the non-real-time side, we've integrated third-party rApps on our RIC platform as part of Rakuten Mobile, and that alone has shown 25% energy savings. Separately, on the real-time side, for AI RAN running on edge compute, we tackled two specific problems. Detecting the uplink signal efficiently took voice quality from poor to very good. And using an AI RAN scheme for adaptive modulation and coding brought error rates down from 20% to 10%. This matters because that's what cuts the throughput fluctuation a user actually feels.
Here's the part I think gets missed in the CPU-versus-GPU debate. We did all of that real-time work on CPUs, with inference running at 60 to 80 microseconds. Yes, GPUs do have the parallel processing capabilities for AI workloads, no argument there, and they're genuinely essential for training. But for a lot of mature 5G deployments, running inference on GPU just isn't cost-effective yet. So our strategy has been straightforward: GPUs for training, CPUs for inference, at least through 5G and 5G Advanced.
Take something like ISAC, the sensing application industry is widely talking about.. Oor XR real-time gaming. In these cases, even a slight lag basically kills the experience. These aren't far-off use cases we'retheorizing about. Operators are already planning around them, and honestly, there's good scope for these to sit right alongside the RAN compute node.
So where does that leave the platform question for 6G? I've said this before: it's not CPU versus GPU. It's both, working together, in a hybrid setup. DU and RAN edge stay CPU-first – deterministic and predictable. It’s the kind of hard real-time performance that radio processing simply cannot do without. GPU-augmented edge clusters get added on top wherever needed, without disturbing that core.
There's a reason this holds up so well going into 6G. Rakuten Symphony took an early stand on architecture – separating software from hardware, allowing third-party RUs through the O-RAN Alliance's Option 7.2x split, and running baseband software on COTS hardware. That philosophy is becoming 6G reality.
It also means the CPU-versus-GPU debate almost doesn't matter to us either way. Whichever wins, the hardware stays COTS, so our strategy remains the reinforced.
Let’s zoom out a bit. I think 6G networks are going to be autonomous and far more software-driven. AI and 6G are essentially evolving together. That's AI-native RAN intelligence built right into the baseband software and the air interface, with every node carrying some AI scope.
On the orchestration side, service-based management architecture should make launching new services much easier and more scalable. And intent-based automation is where things get interesting. Instead of manually tuning a few hundred parameters to hit a quality-of-service target for a network slice, you state the intent and the network configures itself.
Rakuten Symphony developed an Autonomous Energy Efficiency solution for Rakuten Mobile Rakuten Mobile's Autonomous Energy Efficiency solution developed in collaboration with Rakuten Symphony has been successfully validated at Level 4 Autonomy by TM Forum. We're already at level four automation for some of our energy optimizations at Rakuten Symphony. In 6G, we expect that to move to level five. That, for me, is the shape of 6G: hybrid by design, autonomous by ambition, and grounded in results we're already seeing work at scale today.
