AT&T

Welcome to AT&T’s home on Hugging Face for open telecom AI models, datasets, and training and inference recipes.

Open Telco (OTel) AI is an open ecosystem of telecom datasets, benchmarks, models, and reproducible training and inference recipes. OTel’s mission is to give telecom operators the freedom to choose their models, software, hardware, and infrastructure. With contributions from across the industry, OTel has built a shared, open-source AI foundation that enables operators to build, adapt, and deploy AI on their own terms.

OTel has expanded beyond open telecom datasets and specialized embedding, reranking, language, decision, classification, and safety models to include a reproducible training and inference ecosystem. It supports multiple software stacks across hardware from AMD, NVIDIA, AWS, Apple, Tenstorrent, and Intel. OTel includes more than 35 models, with tens of millions of downloads worldwide.

Explore GitHub · Models · Datasets · Research Paper

Explore OTel

Decision Models: Structured Answers, Not Generated Prose

OTel 2.0 Decision 26B A4B 4bit is a 26B total parameter, approximately 4B active parameter mixture of experts model, distributed with 4 bit W4A16 weights. It is built from Gemma 4 26B A4B IT for classification, Yes/No questions, and ordered levels supplied at request time.

Decisions are read from answer label probabilities, supporting confidence thresholds and routing over messages, call transcripts, tickets, and documents. Shared prefix execution lets multiple questions reuse the same input text. This is a typed decision engine, not an open ended chat, retrieval, or reranking model.

The model card reports 86.58% to 87.45% on the 231 task public JevBench suite on AMD MI350P, and 87.45% on AMD Ryzen AI MAX+ PRO 395. These are small benchmark results, not guaranteed production accuracy; label probabilities require calibration checks on the target workload. Training data and adaptation details remain forthcoming in the model card.

Language Models: Deeper Telecom Specialization

OTel 2.0 31B IT is a 31 billion parameter telecom instruction model post trained by AT&T from Gemma 4 31B IT. It extends OTel’s original emphasis on answering from retrieved evidence into a broader telecom domain adaptation program.

The training mixture includes direct telecom question answering, context grounded generation, abstention examples, general instruction following, and general tool calling examples. These describe training coverage, not a guarantee of performance on every task. Telecom specific MCP and tool calling data are not part of the current mixture.

In a retrieval augmented generation pipeline, OTel 2.0 is the answer generation stage. Use the dedicated OTel embedding and reranking models for retrieval and evidence ranking.

Explore the OSFT checkpoint and QLoRA variant. QLoRA offers a lower memory adaptation method; it does not by itself imply a 4 bit inference checkpoint. The technical configuration above describes the OSFT model, not both variants.

The OTel 1.0 LLM collection provides additional instruction and reasoning checkpoints. The paper evaluates 17 core language models from 270M to 32B parameters. Its strongest reported core LLM result is 87.8% ± 0.5 percentage points context grounded correctness for OTel LLM 27B IT; this is not an OTel 2.0 benchmark.

OTel 1.0: Retrieve, Rerank, Answer, Abstain

OTel 1.0 provides complementary model families for building an evidence grounded telecom AI pipeline. Its data curation reduced approximately 1.1 million candidate examples to 326,767 retained examples, organized into instruction tuning, embedding, reranking, and safety datasets.

Embedding Models

The OTel embedding collection turns telecom questions and passages into vectors for semantic search. The paper covers 10 embedding models from 22M to 8B parameters, allowing teams to balance retrieval quality, latency, and memory.

OTel Embedding 300M reaches 90.4% ± 0.6 percentage points NDCG@10, while OTel Embedding 8B reaches 93.1% ± 0.4 percentage points, compared with 83.9% for its base model.

Reranking Models

The OTel reranker collection scores query and passage pairs to prioritize the strongest evidence after initial retrieval. The paper evaluates 0.6B, 4B, and 8B cross encoder models.

OTel Reranker 0.6B reaches 0.938 ± 0.007 MRR@10. The 8B model reaches 0.947 ± 0.005, compared with 0.417 for its base model, providing a separate relevance ranking stage before generation.

Classification Models

OTel LLM 8.3B Classification adapts EssentialAI/rnj-1 with full parameter training and a classification head for eight 5G network root cause classes. Unlike the Decision model’s request defined labels, this checkpoint targets a fixed classification task.

The model card reports approximately 99% accuracy on the TeleLogs test set, an auxiliary experiment outside the paper’s 30 core baselines. TeleLogs contains synthetic 5G drive test scenarios; this result does not establish accuracy on live operator incidents or unseen fault categories.

Safety and Abstention Models

OTel LLM 8.3B Safety is a full parameter adaptation of EssentialAI/rnj-1-instruct on OTel Safety data. It is trained to abstain when retrieved context is missing, irrelevant, or insufficient, rather than invent an unsupported answer.

This is an abstention focused generation model, not a universal safety filter or a guarantee of secure network operation. Evaluate both correct abstention on insufficient evidence and answer quality when evidence is sufficient. The auxiliary safety model is outside the paper’s 30 core baselines.

How to Read the Results

The OTel paper reports 30 core baselines: 10 embedding models, 3 rerankers, and 17 language models. Retrieval, reranking, and generation results above use held out OTel evaluation partitions, with standard errors from 1,000 bootstrap resamples. LLM correctness averages judgments from GPT-4o mini and Claude Sonnet 3.5 on answers generated from supplied context.

These metrics measure different tasks and should not be compared as one accuracy score. They do not measure unrestricted telecom factual recall or prove safe live network operation. Decision and TeleLogs results use separate benchmarks and protocols; comprehensive public OTel 2.0 LLM evaluation remains forthcoming.

Built for Hardware and Software Choice

The repository provides isolated recipes for language modeling, embeddings, reranking, and classification, with methods including SFT, continued pretraining, DPO, GRPO, PPO, OSFT, LoRA, QLoRA, and DoRA.

Training options include DeepSpeed, FSDP2, PEFT, Unsloth, Axolotl, LLaMA Factory, verl, OpenRLHF, NeMo, TorchTitan, and ScalarLM. Inference options include vLLM, SGLang, Transformers, llama.cpp, Ollama, Lemonade, TEI, TensorRT LLM, MLX, and the Tenstorrent serving path. Framework and workload coverage vary.

Portability does not mean every recipe supports every device. Consult each recipe for installation commands, dependencies, verification evidence, and known limitations. The general recipe library is distinct from the exact OTel 2.0 training implementation and reproducible configuration, identified in project release notes as a separate forthcoming release.

Telecom Applications and Use Cases

OTel models, datasets, and recipes are building blocks for the applications below. Combine embedding and reranking models for evidence retrieval, LLMs for explanations and generation, Decision models for request defined labels, Classification models for their trained categories, and Safety models for insufficient context abstention.

These are application patterns, not claims that every released checkpoint has been trained or validated for each workflow. Code, telemetry, signalling, security, multilingual, and agentic applications require task specific data, integrations, and evaluation. Access to additional standards also depends on source availability and usage rights.

Standards and Protocol Knowledge

• Telecom standards Q&A: Build assistants over 3GPP, ETSI, ITU, IETF, ATIS, IEEE 802, and BBF specifications to explain procedures, interfaces, parameters, and normative rules using retrieved evidence.
• Specification and contribution summarisation: Summarise specification sections, change requests, contributions, and patents as source extracts or detailed explanations.
• Grounded RAG assistants: Retrieve and rank relevant documents, generate answers grounded in the evidence, ignore irrelevant passages, and abstain when the retrieved text does not contain the answer.
• OSS/BSS architecture guidance: Explain TM Forum ODA, eTOM, and SID, and help map operator processes and data to those frameworks using authoritative documentation.

Network Software and Automation

• 5G RAN and core code assistants: Develop code navigation and explanation workflows for OpenAirInterface, srsRAN, Open5GS, and free5GC, including NGAP, F1AP, and E2AP ASN.1 definitions.
• Network automation: Draft or review Terraform, Ansible, Helm/Nephio, and ONAP/ODL YANG configurations, with schema checks, testing, and engineering approval before deployment.
• O-RAN RIC development: Support near real time RIC xApp development and E2 interface work on FlexRIC using relevant code and specifications.

Network Operations and Troubleshooting

• Signalling trace analysis: Build workflows to interpret 5G/LTE signalling and network function logs, including registration, PDU sessions, S1AP, and NAS, with references to the applicable 3GPP procedures.
• Core network root cause analysis: Investigate outage hypotheses from logs and signalling, such as AMF/SMF/UPF restarts, NRF/UDM stops, or N2/N3 impairments, and present supporting evidence for engineer review.
• RAN and RF health checks: Combine telemetry and validated analytical tools to assess RSRP/SINR, MCS, transmit power, latency, and SLA compliance.
• NOC ticket triage: Integrate OSS alarms, KPIs, configuration, and inventory to distinguish likely faults from false positives and assemble an evidence trail. English and French ticket workflows require separate language specific evaluation; current OTel quality claims cover English only.
• Security triage: Explore detection workflows for fake base stations in LTE signalling and RADIUS brute force or credential failures, using security specific training data and independently validated detectors.

Agentic Operations and Tool Calling

These workflows require an external orchestration layer with verified tool interfaces, scoped permissions, audit logging, and approval gates. General tool calling training does not establish telecom tool competence or authorise network changes.

• Closed loop incident handling: Correlate TMF642 alarms with router state, then propose or execute approved TMF621 trouble ticket updates within an evaluated workflow.
• Customer care diagnostics: Use authorised CAMARA APIs to check subscriber roaming, reachability, and network type when investigating connectivity problems, subject to consent and privacy controls.
• Router and 5G core operations: Integrate read only router health checks through CLI, SNMP, telemetry, and topology tools, and authorised queries to NWDAF analytics and UDR subscriber data.
• Policy following operations agents: Orchestrate tools in parallel, sequentially, or across multiple turns while enforcing change control and safety rules outside the model.

Under Development

The following application directions remain under development and are not presented as validated capabilities of the released checkpoints.

• Digital troubleshooting for broadband: Automated diagnosis of connectivity and service issues on subscriber smartphones, with guided resolution steps for customers.
• Network root cause analysis reasoning: Explain network performance degradation from KPIs and recommend parameter changes with an explicit rationale for engineering review, aiming to shorten diagnosis and resolution time.
• 5G mobility failure analysis: Investigate interactions among device mobility, packet core, and RAN behaviour where individual messages comply with 3GPP but a missing optimisation or procedural ordering creates a chain of waits and a dropped call, such as during a 4G to 5G handover.
  • Reconstruct device, gNodeB, SMF, and AMF actions and wait states, and identify candidate causes such as an Initial Context Setup sent without the PDU sessions indicated by the device.
  • Link the analysis to observed failure signatures, such as the EBAT SUPERCODE value “Radio Network Layer: TXnRELOCOverall expiry”.
• Cybersecurity attack classification: Classify device originated signalling and packet traffic for malicious or attack activity, starting with the UDM to AMF interface.

Research and Community

AT&T develops and trains the OTel models within a broader industry collaboration. GSMA convenes the Open Telco AI initiative and contributes standards data; Pleias contributes to the open corpus; Red Hat supports synthetic data generation and OSFT; Microsoft supplies managed compute; AMD supplies accelerators and ROCm; Dell Technologies supplies training infrastructure; and MLCommons and research collaborators contribute evaluation and domain expertise.

Explore the project through Google Cloud’s account of OTel and Gemma, Microsoft’s trillion token workflow overview, and Dell Technologies’ OTel 2.0 infrastructure story.

Research and Documentation · Selected Blog and Media Coverage

Capabilities and Responsible Use

OTel supports development of telecom standards assistants, document search, engineering knowledge tools, and context grounded question answering. Evaluate direct Q&A and RAG separately on your target domain; comprehensive public OTel 2.0 capability evaluation remains forthcoming.

OTel 2.0 telecom post training and published quality claims cover English text. Image input is inherited from the base architecture, not telecom tuned or comprehensively evaluated; audio and video are unsupported. Standards knowledge does not establish expertise in live telemetry, vendor commands, or private operational workflows.

OTel 2.0 has not been validated for autonomous network control, live procedure execution, or security operations. High impact applications require verified tools, scoped permissions, source validation, audit logging, and appropriate human review. Pin checkpoint revisions for reproducible evaluation and deployment.

Build with Us

Explore the models, adapt a recipe, evaluate on your own telecom tasks, or contribute through GitHub.

Review each model and dataset card for licensing, intended use, and limitations. Verify generated content against authoritative sources before operational use.

Get Started · Questions and Contributions