TelecomGPT-R1 and RF-GPT are helping AI interpret telecom engineering knowledge and wireless signals and subsequently assisting radio frequency engineers to quickly understand RF signals. Khalifa University’s high-performance computing (HPC) facilities support the development workflow, reducing demanding RF-GPT tasks from days to hours and making repeated experiments more practical.
A network engineer investigating a weak radio frequency connection may need to read technical standards, inspect network records and examine the radio signals in detail. Our research at Khalifa University can assist a radio frequency engineer understand the causes of abnormal RF signals without having to resort to numerous resources through two complementary projects: TelecomGPT-R1 specializes in telecommunications reasoning, while RF-GPT interprets radio-frequency signals through a language-based interface.
Telecommunications has its standards, procedures and engineering constraints. A fluent answer from a general-purpose large language model can still misinterpret this specialized information. TelecomGPT-R1 builds on our TelecomGPT research by training an AI model to reason across protocol specifications, technical knowledge, engineering calculations and network fault data.
The AI model learns from curated examples and is then refined using reinforcement learning with answers checked against task-specific rules. The aim is to connect an engineering question to the relevant evidence and work through the reasoning needed to answer it. Potential uses include interpreting standards and helping engineers investigate radio network problems. The GSMA Open Telco Leaderboard snapshot in our July 2026 presentation placed TelecomGPT-R1 first among the models shown.
RF-GPT extends the research to radio signals. A radio receiver records a waveform, which we convert into a spectrogram: an image showing how signal energy changes across time and frequency. This lets us adapt the visual capabilities of a multimodal language model to wireless data.
Users can ask which wireless technology is present, whether transmissions overlap or how many users are active. The research also examines the extraction of specific 5G signal characteristics. The interaction gives engineers a way to ask questions about a signal using ordinary language, alongside the plots and measurements they already use.
Our demonstration connects the model to radio equipment and a software interface for inspecting captured signals. It shows how RF-GPT can be used beyond simulated RF signals. The published study evaluates the approach across several tasks, including wireless technology recognition, signal overlap analysis and user counting, using a controlled synthetic benchmark.
Teaching this capability requires examples that connect signal patterns to correct technical descriptions. We use wireless simulators to generate signals and record their underlying configurations. These records specify what each example contains, allowing us to pair a spectrogram with a description grounded in the simulation settings.
A large language model then turns those descriptions into varied questions and answers for training. The workflow presented at the HPC forum produced around 600,000 instruction pairs. It supports different questions about the same scene, including signal counting, technology recognition and overlap analysis, while reducing the need to write every example manually.
This workflow creates several distinct computing demands. Signal simulation benefits from parallel processing on central processing units (CPUs). Generating conversations requires substantial language-model inference, and fine-tuning RF-GPT uses multiple graphics processing units (GPUs). HPC therefore contributes throughout development, including the preparation of the data on which the final model depends.
The RF-GPT workflow comparison shows the practical benefit of the HPC cluster. Signal generation time fell from 24 hours on 1 CPU to 2 hours using 96 CPUs. Conversation synthesis time fell from 12 hours on two NVIDIA A6000 GPUs to 20 minutes on one node containing eight NVIDIA H200 GPUs.
For the model-training comparison, the workstation with two A6000 GPUs took more than 72 hours, whereas two nodes with eight H200 GPUs each completed training in 2 hours. These measurements reflect the reported RF-GPT workflow and hardware allocations. The gains combine the effects of parallel software and access to larger shared computing resources.
The shorter turnaround changes which experiments are practical. A researcher can test a revised training dataset, inspect the results and plan another run without each iteration occupying several days. For our work, this matters because data quality, training choices and evaluation all need repeated attention. Faster computation makes it easier to investigate those choices systematically.
The gains depend on matching each task to appropriate resources. Our workflow uses parallel signal generation, efficient language-model inference and distributed training. Requesting the CPUs, GPUs, memory and run time that a job needs help researchers use the HPC cluster effectively and keeps shared capacity available for other projects.
TelecomGPT-R1 and RF-GPT point towards engineering tools that can explain telecom evidence and make wireless observations easier to query. The RF-GPT results show why access to HPC matters for developing such tools at KU: it supports the scale of data preparation and model training, while giving researchers a workable cycle for testing and improving their ideas.
