Ericsson Makes Its Case for Edge Inference

Ericsson published a blog on 7 October, written by Benedek Kovacs, Wolfgang John and Mischa Dohler, arguing that where AI inference runs is becoming a strategic decision for enterprises and that communications service providers are well placed to answer it. Ericsson draws on an F5 report for the shift toward enterprises running some inference themselves. The blog states that service providers operate about 100,000 distributed network data centres, which could support over 100 GW of new AI compute over time. It names 3 advantages for the telco edge: access to live network context such as radio conditions and device location, stable low latency for physical AI, and confidential computing that keeps data private from the operator and from co-located workloads. It adds that a Swedish regulatory sandbox assessed the confidential computing approach as compliant with current data protection rules, subject to user-controlled attestation and key management.

The 100 GW figure divided by 100,000 sites implies an average of about 1 MW per site, which is my arithmetic and not Ericsson's. The blog gives it as an eventual ceiling with no timeline and no split between sites that have the power, cooling and fibre today and those that would need a rebuild. Those 3 constraints are why I placed AI Grid deployment at central offices and mobile switching offices rather than at the cell site in Operators Lean In On AI Grid Location. A count of 100,000 sites says little about how many of them can host accelerated compute.

Ericsson's own performance chart points the same way. At 30 tokens per second it shows roughly 7.0 billion parameters running on a device and roughly 30.8 billion at an edge site, which is the range of small and mid-size models, not frontier models. The workload Ericsson builds the latency case on is physical AI: robotics models of 10 billion to 100 billion parameters, control loops of 10 Hz to 20 Hz and responses under 100 ms. Those are real requirements, and they define a narrower market than general enterprise inference.

The operator role Ericsson describes

The more notable statement is about 6G. Ericsson expects specialised AI providers to deliver most early edge AI services on top of telco infrastructure, with the service provider's value in orchestration, network API exposure and end-to-end assurance. That is a vendor describing the operator as the infrastructure and assurance layer, not the seller of the AI service, and it is a shift from the position I covered in Ericsson Says the Telco Edge Was Too Early. Operators that accept that role should price edge sites on power and connectivity economics at the central office and metro layer, and should treat network context as a paid input that third-party AI providers consume through APIs.

AT&T and GSMA warn Telco AI Models Drift

Boost Mobile data scientist Priyank Jain, GSMA director of AI technologies Louis Powell and AT&T data office vice president Mark Austin flagged a specific and seldom discussed risk in telco AI deployments this week: the gap between the data a model was trained on and the data it actually encounters once it is live, a failure mode known as train serve skew. Speaking to Fierce Network on 25 September 2026, Jain explained that the danger is not a crash or a failed job. Nothing alerts an operator that anything is wrong. Jain said the model "just gets quietly worse."

Two Different Ways Models Drift

The article identifies 2 separate causes. General purpose frontier models arrive with no exposure to telecom specific data formats or vendor taxonomies, since none of that appears in their internet scale training data. Telecom specific models face a subtler problem: production data, such as settlement records, arrives late or out of order in ways the training set never captured, and datasets in this domain routinely carry over 100 columns of custom, operator specific parameters. Powell added that frontier models have no inherent understanding of telecommunications and can produce confident, wrong answers, a real risk once a model is embedded in an enterprise workflow. Austin's prescription is procedural rather than technical: match training data to production sources as closely as possible, run a new model silently alongside the live system before cutting over, and keep testing it after deployment rather than treating the launch as the finish line.

Why This Matters Before Autonomy

This is a narrower and more mundane problem than the industry's current preoccupation with agentic AI and autonomous networks, and that is exactly why it matters. The NGMN report on agentic AI concluded that even coordination within a single operator's own domains, let alone accountability between an enterprise and its network provider, requires common information models and audit trails that do not yet exist. Train serve skew shows the problem starts a level below that. A supervised classifier with a known, static task can still fail silently once its inputs drift from what it was trained on. An autonomous agent negotiating across an operational boundary carries the same drift risk plus the coordination and accountability gap NGMN identified. Operators evaluating agentic AI pilots should ask a more basic question first: whether they would know if the model already in production today has quietly stopped working.

Quiet drifts like this example are worse than explicit failures. The quality of the output degrades silently, which degrades the quality of service. Explicit quality control for data quality before and after transformation, and before and after agentic intervention are necessary to enable autonomous networks.