3
Dell and AMD supply the hardware behind OTel 2.0’s live deployment
In sum – what we know:
- A CUDA-free stack – Cloud training ran on roughly 430 AMD Instinct MI300X GPUs via Microsoft Foundry, with Dell shipping MI355X servers for on-premises deployment.
- Heavy data curation – Over a trillion tokens were processed and distilled down to about 400 billion telecom-specific tokens for post-training.
- Routing cuts the bill – An “AI Gateway” caches responses and escalates between OTel 2.0 and frontier models, which AT&T says trims inference costs by up to 90%.
AT&T has taken OTel 2.0, the open-source telecom AI model developed under the GSMA-led Open Telco AI initiative, and pushed it into full production deployment — with Dell and AMD supplying the hardware muscle. The model is built on Google’s Gemma 4 31B-IT base and post-trained specifically for telecom workloads. It’s a 31 billion parameter model, which is far lower than what you’d find in a frontier model — but that’s intentional. Keeping it well below frontier scale means it can run on right-sized hardware in an operator’s own data center, not exclusively on hyperscale clusters. Compared to the earlier OTel 1.0, this is a meaningful jump in scale, data curation, and production readiness.
AT&T and its partners processed over a trillion tokens during training and data selection, ultimately distilling that pool down to roughly 400 billion highly relevant telecom tokens for post-training. That corpus includes a 15-billion-token curated dataset and a 10-billion-token “Telco Corpus” from GSMA, drawing on materials from 3GPP, ETSI, CAMARA, ITU, O-RAN, and TM Forum, augmented with synthetic data generated by other open models like Phi-4 to improve structured reasoning and scenario coverage. Because the focus is strictly on standards-based content and technical documentation, the partners argue there’s far less PII exposure than you’d find in a consumer internet corpus.
Hardware partnerships
The most notable thing about OTel 2.0’s infrastructure is what’s missing from it. Training and inference run heavily on AMD Instinct GPUs and AMD’s open ROCm software stack, bypassing NVIDIA and the CUDA-centric stacks that dominate most AI deployments today. Cloud training used roughly 430 AMD Instinct MI300X GPUs deployed through Microsoft Foundry’s managed compute service on Azure, which is a fairly convincing demonstration that trillion-token-scale workloads can run on ROCm without a CUDA dependency.
Dell handles the other half of the equation. The company provides carrier-grade on-premises servers hosting AMD MI355X GPUs for localized data center deployment, and its role here goes beyond simply shipping boxes. Dell’s hardware acts as a replicable blueprint — the reliability, support, and lifecycle management that turn an open-source model release into something an operator can actually run in production.
Of course, there’s a wrinkle in the anti-lock-in narrative. The architecture is designed to reduce dependence on closed AI and a single GPU vendor, but operators adopting it still face potential lock-in of a different flavor — to specific cloud services, or to particular open-source infrastructure stacks. The dependency shifts rather than disappears.
Multi-model routing
OTel 2.0 doesn’t run in isolation. It sits behind what AT&T calls an “AI Gateway,” which caches responses and routes each task between OTel 2.0, other domain models, and frontier models depending on what the job actually requires. The routing is cache-aware and dynamic — if a multi-turn conversation escalates in complexity, the gateway can switch models mid-session, starting cheap and stepping up only when needed. This is running at genuine production scale. The live infrastructure processes around 45 billion tokens per day, and total workloads consume over a trillion tokens monthly across more than 100 generative AI models, with about 40% of those operations running on AMD hardware.
AT&T claims the gateway routing and cached computation reuse cut AI inference costs by up to 90% compared to leaning on primary frontier models for everything. That figure is plausible given the architecture, but it deserves a caveat — replicating those savings requires complex engineering and caching setups, and smaller operators may simply lack the scale to realize the same economics, even if they adopt the model wholesale.
The deployment is deliberately hybrid. Azure handles large-scale training bursts, while Dell’s on-premises servers handle latency-sensitive core network operations where data can’t leave the building. “Day 0” inference is already available for testing through Microsoft Foundry, Featherless AI, and Red Hat, and this is engineered as a “living” model — weekly weight updates are planned as training continues, so the version you test this month won’t be the version running next quarter.
So what does an operator actually do with it? OTel 2.0 summarizes dense standards documents from the likes of 3GPP and ETSI, generates compliant network configurations, and automates troubleshooting queries, knowledge retrieval, and runbook generation for daily operations. For regional operators, the appeal is obvious — telecom-tuned AI without the capital expense of building a custom foundation model from scratch. Equipment vendors and standards bodies get something out of it too, using the model to test interoperability scenarios and produce standardized documentation.
The security question can’t be waved away, though. Dropping open AI models into mission-critical telecom infrastructure introduces new attack surfaces — prompt injection and model poisoning among them — and operators will need extensive auditing before trusting the model anywhere near live networks. To its credit, the project makes that scrutiny possible. Model weights and documentation are publicly available on Hugging Face with instructions for reproducible evaluation, and the whole effort was developed through a multi-stakeholder governance approach spanning AT&T, GSMA, Dell, AMD, Microsoft, Red Hat, MLCommons, and Pleias.
