Summary

  • Telenor AI Factory has selected F5 BIG-IP Next for Kubernetes for its NVIDIA-powered sovereign AI infrastructure, with traffic policy, tenant isolation, ingress and egress controls, visibility and telemetry in the described scope. The announcement does not establish that production deployment is complete.
  • The architecture could improve the traceability of activity across shared AI infrastructure and therefore provide inputs for allocating some costs or usage to customers. But token-aware governance, circuit breaking and inference-aware optimisation remain planned for Telenor, while entitlement, reporting and billing are intended workflows rather than demonstrated commercial results.

A shared AI factory has a simple commercial problem before it has a sophisticated networking one. Several customers can use the same underlying infrastructure, but to operate that capacity as distinct customer services, the provider needs a way to tell whose traffic is moving through the system, which rules apply to it and what activity can be traced back to each tenant. That does not by itself produce a customer bill. It does, however, create the operational record from which customer-specific governance — and potentially some forms of usage or cost attribution — can be built.

F5’s documentation describes per-tenant policy, logging and egress identity, while its per-application egress model gives upstream systems an auditable way to attribute traffic to applications.

That is the commercial significance of Telenor AI Factory’s 21 October 2026 selection of F5 BIG-IP Next for Kubernetes as an AI service plane for its NVIDIA-powered sovereign AI infrastructure. F5 describes the service plane as a control point in the AI traffic path: policy can be applied to ingress and egress traffic and API interactions; tenants can be isolated; and operational telemetry can provide visibility for operations, audit and compliance reporting. The announcement is explicit about the selection, but it does not say that a full production rollout has been completed across Telenor AI Factory.

The DPU element matters because it changes where some of that control can sit. F5’s product documentation says that, in the DPU deployment model, its traffic-management microkernel runs on BlueField-3 DPU hardware rather than as a software pod on the host CPU. The documented architecture supports hardware-accelerated packet processing and enforcement, along with multi-tenant segmentation, telemetry and policy-based ingress and egress controls. For AI inference clusters, F5 says traffic processing can be offloaded to the DPU.

F5’s Telenor announcement goes further in describing the architectural intention: selected networking and security functions can be accelerated and isolated from host workloads, which F5 says preserves host CPU capacity for AI applications, strengthens the enforcement boundary between infrastructure and tenants and can reduce data-path bottlenecks. Those are vendor descriptions of how the architecture is intended to work. The sources provide no Telenor-specific benchmark showing host CPU capacity saved, GPU capacity released, latency reduced, throughput improved or infrastructure cost avoided after the selection.

That distinction is central to the investment case. A DPU-based enforcement point can be economically interesting without yet being economically proven. If policy, tenant identity and telemetry are attached consistently to traffic, an operator has a better technical basis for assigning activity to a particular tenant or application. F5’s documentation explicitly describes per-tenant enforcement, logging and egress identity and calls its application-level traffic attribution auditable. From that, it is reasonable to infer that such records could become one input into allocating some shared service costs.

But the documentation does not define Telenor’s accounting method, prices, customer entitlements or billing rules, so traffic attribution should not be confused with cost attribution already operating in production.

Nor should the F5 selection be mistaken for the launch of Telenor’s AI business. Telenor was already offering customer services from its first GPU cluster. Its AI Factory page says that cluster provides sovereign cloud services using H100 GPUs, bare-metal GPU capacity and a Kubernetes interface. In June 2025, Telenor said the AI Factory was being expanded after already supporting real-world applications including translation, public-sector digitalisation, language-model hosting and industrial automation.

The separation becomes even clearer in Telenor’s second-quarter 2026 report, published before the October F5 selection. Telenor said the AI Factory was serving enterprise and public-sector customers and that commercial use cases included multilingual AI translation, public-sector digitalisation and industrial AI applications hosted in Norway. In other words, the service-plane selection is an infrastructure-governance development inside an existing service operation, not evidence that customer services began with F5.

The same report also establishes that AI Factory investment was already material enough to appear in Telenor’s capital-expenditure discussion. Telenor said the increase in group capital expenditure excluding leases in the second quarter was driven by NOK 150 million of GPU investment in AI Factory. Separately, its Infrastructure business reported NOK 265 million of quarterly capital expenditure, mainly driven by AI Factory investments.

Those figures should not be stretched into unit economics. Telenor’s Infrastructure business contains its tower operations as well as the AI Factory and an interest in a data-centre company. The report provides Infrastructure-level financial figures but does not give a standalone AI Factory revenue, EBITDA, free-cash-flow or return figure. The disclosed GPU investment therefore proves capital deployment into the AI Factory; it does not show what revenue that capital generated, what utilisation it achieved or whether the F5 architecture changes the return on that investment.

The most important line to draw is between the functions described around the selection today and the capabilities Telenor says it plans to use later. In the current described scope, F5 identifies secure multi-tenancy and network isolation, policy-based traffic control across ingress, egress and API interactions, plus observability and telemetry. Telenor can use the selected service-plane architecture to apply policy, visibility, tenant isolation and traffic control in the AI service path.

Token-aware governance is different. The announcement labels token-aware governance and circuit breaking as planned. More advanced inference-aware traffic optimisation is also planned. The release says these future capabilities are intended to improve control over AI consumption and support entitlement, reporting and billing workflows as commercial services scale. That wording matters: it identifies a route toward metered commercial control, not evidence that token-based entitlements or customer bills are being generated through the platform today.

There is a subtle point because F5’s general BIG-IP Next for Kubernetes documentation lists AI traffic handling, including token governance, among the product’s core capabilities. That does not override the Telenor-specific announcement. A function can exist in a product while still being planned rather than deployed in a particular customer environment. For Telenor, the company-specific evidence is the relevant boundary: token-aware governance, circuit breaking and advanced inference-aware optimisation are future plans.

For the market, this leaves a narrower but more defensible thesis than a headline about AI efficiency. Shared GPU infrastructure creates costs at the physical layer, while commercial services need controls and records at the customer layer. A policy-and-telemetry boundary that can identify tenants and applications may help connect those two layers. If Telenor eventually combines auditable tenant identity with token-aware consumption data and its own commercial rules, it could obtain a richer basis for entitlement and cost allocation.

The October announcement provides evidence for that architectural direction, but not for the completed economic chain from telemetry to invoice to margin.

That missing chain is precisely what prevents stronger claims about economics. The official evidence set discloses no F5 contract value for Telenor, no customer pricing linked to the new service plane, no production traffic volumes passing through it and no workload mix. It provides no measured change in CPU or GPU use, no quantified infrastructure saving, no billing-accuracy result, no customer-acceptance metric and no revenue or return-on-investment result attributable to the selection. F5 itself identifies statements about planned capabilities, availability and expected benefits for Telenor AI Factory as forward-looking.

So the investable question is not whether DPU offload sounds efficient. It is whether Telenor can turn a technical boundary around AI traffic into a reliable commercial boundary around consumption. The first half of that proposition — policy, tenant separation, traffic control and telemetry — is described in the selected architecture. The second half — durable metering rules, operational billing, measurable savings and improved returns — remains to be demonstrated publicly.

Sources: