摘要

  • F5 的正式措辞是 Telenor AI Factory “has selected” BIG-IP Next for Kubernetes；公告把多租户隔离、入口/出口/API 流量策略、可视性和遥测列为当前能力，把 token 感知治理、熔断和更高级的推理感知流量优化明确列为后续计划。因此，这是一项产品选择和服务边界设计决定，不是完整生产部署已经完成的证明。
  • DPU 的经济意义首先不是“更快”，而是把策略执行点放到共享 AI 流量必经的数据路径，并让租户身份、网络路径和遥测更容易对应。F5 的产品文档已经提供这种技术基础，但 Telenor 没有公开合同金额、产品价格、利用率、性能提升、CPU/GPU 节约、当前客户总数、收入、实际计费结果或投资回报数据；目前能够证明的是控制边界，而不是经济回报。

证据边界：已经运营的 AI Factory，与尚未完成的部署证明

先把两件容易混在一起的事分开。Telenor AI Factory 本身不是一个刚刚宣布、尚未启动的项目。 Telenor 在 2024 年 11 月宣布正式推出 AI Factory；其当前官方页面称，首个 GPU 集群已经向客户提供主权和安全的云服务，基础设施包括 NVIDIA H100 GPU、bare metal GPU 接入以及 Kubernetes 接口。2025 年 6 月，Telenor 又称该设施正在扩大容量，并已经承载内部和外部实际应用。因此，说 Telenor 正在运营 AI Factory，有连续的第一方材料支持。

但 2026 年 10 月 21 日的 F5 公告所证明的事情更窄。F5 的原文是 Telenor AI Factory 选择了 BIG-IP Next for Kubernetes 作为其 NVIDIA-powered sovereign AI infrastructure 的智能 AI service plane。公告没有使用“全面生产部署完成”“商业验收完成”或类似措辞；同时，F5 在同一公告的前瞻性声明中专门把计划中的能力、可用性和预期收益列为可能受技术和商业因素影响的事项。因而，最稳妥的状态描述是：Telenor 已作出服务层技术选择，公告确认了目标架构和功能边界，但没有公开证据证明完整生产部署已经结束。

功能状态也必须按公告自己的时态来读。F5 把安全多租户和网络隔离、基于策略的入口与出口流量控制、API interactions、运营遥测，以及实时可观测性和遥测列为 BIG-IP Next for Kubernetes on NVIDIA BlueField DPU 为 Telenor AI Factory 提供的能力。随后两个条目则明确加上“planned”：token-aware governance 与 circuit breaking，以及 inference-aware traffic optimization。后者被描述为随着商业 AI 服务扩展而进一步加入服务层的能力。

这里还有第二层状态差异：“Telenor 计划以后使用”不等于“F5 产品今天完全没有这项能力”。 F5 当前 BIG-IP Next for Kubernetes 2.4 文档已经把 AI traffic handling、intelligent load balancing 和 token governance 写入产品能力，并提供 token counting、按用户或模型限额、并发会话限制以及使用数据输出等配置文档；2.4.0 的 release notes 也把新的 AI inference routing 能力列为已发布功能。

这正是本案最重要的核验点。产品文档可以证明 BNK 普遍具备或可配置某些 token 与 AI 流量功能；Telenor 公告却仍把 token-aware governance、熔断和更高级的推理感知优化描述成其自己的后续计划。两者并不矛盾：产品可用性、客户选择和客户实际启用是三个不同状态。尤其不能因为 F5 文档已经说明 token usage 可以输出给外部 metering 或 billing 工具，就倒推出 Telenor 已经完成 entitlement、reporting 或 billing 系统。Telenor 公告对此的措辞只是：计划中的能力拟用于支持这些工作流。

截至这些官方材料，尚没有公开数据可以回答若干关键经济问题：Telenor 采用 F5 的合同金额和许可价格没有披露；F5 层是否已承载全部或多少比例的 AI Factory 生产流量没有披露；当前租户或客户总数、负载构成、GPU 利用率、主机 CPU 变化、吞吐和时延结果没有披露；网络、安全与可观测性各自的实际单位成本没有披露；也没有公开 chargeback、token 计费、收入贡献、成本节约或商业验收结果。Telenor 的材料证明 AI Factory 已在运营和扩展，F5 的材料证明了选择和能力设计，但这些材料没有给出一套可据此计算投资回报的经营数据。

机制变化：DPU把执行边界固定在共享服务路径

这项选择真正改变的是策略在哪里执行，以及谁能在什么范围内改变策略。

F5 的 BNK 文档把 Host 与 DPU 两种模式区分得很清楚：在 DPU 模式下，Traffic Management Microkernel（TMM）运行于 NVIDIA BlueField-3 DPU，而不是作为依赖主机 CPU 的数据面；Kubernetes 控制器则持续监视资源和配置变化，再把服务与策略配置下发到 TMM。也就是说，DPU 承担的是流量数据路径上的执行，Kubernetes CRD 和控制器仍承担声明、编排和生命周期管理。把两者笼统称作“控制面迁到 DPU”并不准确；更准确的说法是，策略执行点被推到 DPU，而策略定义和编排仍由 Kubernetes-native 控制机制掌握。

这一区别直接决定市场含义。F5 的公告称，在 BlueField-3 上运行其 traffic-management data plane，可以让部分网络和安全功能与 host workload 隔离，并强化基础设施和租户之间的 enforcement boundary。这里可以确认的是架构隔离和执行位置；不能从这句话推导出 Telenor 实际节约了多少 CPU、获得多少吞吐提升，或者因此减少了多少 GPU 成本。公告所写的 host CPU capacity 和减少数据路径瓶颈是预期架构收益，不是 Telenor 已公开验证的经营指标。

一旦共享 AI 流量经过这个边界，原本容易混在“AI 集群总体开销”中的几类控制活动就获得了更明确的归属键。网络侧，BNK 支持按 namespace 的 egress identity、SNAT、独立 GatewaySettings、VRF 与入口/出口路径；安全侧，策略能够绑定 Gateway 或 EgressGateway，并与租户网络边界对应；可观测性侧，则可以让不同 namespace 独立选择采集什么指标、采集频率和输出方式。F5 2.4 的网络模型甚至明确把 infrastructure provider、cluster operator/tenant network administrator 和 application developer/tenant administrator 分成不同角色。

因此，DPU 边界实际上形成了两层控制。上层是 Telenor 这样的基础设施运营方可以控制的共享网络、地址、路由域、许可边界和全局策略；下层是租户或应用团队在获得权限后能够操作的 Gateway、route、egress 和监控配置。F5 的 telemetry 设计同样采用这种嵌套关系：集群管理员可规定哪些 namespace 和指标允许被访问，租户则能在这些边界内选择采集项目和频率。控制权没有简单地“交给 F5”或“交给租户”，而是被编码到 Kubernetes 资源和权限层次中。

这比单纯增加一个负载均衡器更重要。对于共享 AI 基础设施，真正难以商业化的部分往往不是“有没有流量”，而是能否回答：这是谁的流量、经过了什么控制、产生了什么可观测性负担、谁有权改变策略。BNK 的 namespace、独立 egress identity、租户化统计和策略对象使这些问题更容易获得一致的技术标识。它们构成成本归属的前提，但还不是成本会计本身。

市场含义：可归属不等于已收费，更不等于已回报

从 Market 角度看，最有价值的变化，是 Telenor 有机会把过去作为公共基础设施开销处理的网络、安全和可观测性资源，拆成更接近租户或服务的成本池。

网络成本最容易建立第一层映射。BNK 可以给不同租户配置独立的入口和出口路径、SNAT 身份、VRF 或 GatewaySettings，同时其 telemetry 能记录虚拟服务的连接和流量统计。这使运营方有可能把特定数据路径的资源消耗对应到 namespace 或租户，而不是只看到整个集群的网络总成本。这里的关键词是“有可能”：官方材料没有公布 Telenor 已采用怎样的内部成本分摊公式，也没有给出网络流量单位价格。

安全成本也可以获得类似的结构化归属。策略对象能够与 Gateway、EgressGateway、租户网络和路由边界绑定，因此从配置层面可以回答某个租户是否需要特定防火墙、访问控制或其他 enforcement。可是“这个租户启用了一个策略对象”与“这个策略应分摊多少许可证、DPU、运维和支持成本”仍是两回事。F5 文档描述了功能和许可机制，但没有公开 Telenor 的采购价格或内部成本模型，因此安全能力目前是可标识，不是已定价。

可观测性成本反而可能是最容易被精细拆分的一项。F5 的 tenant-aware statistics 允许每个 namespace 选择指标、采集频率和聚合方式，管理员还能限制可访问范围和输出量；文档明确指出，租户可以只导出所需指标，从而减少无关数据和资源消耗。于是，一个高频采集、大量输出的租户与低频、少量指标的租户，不再必然被视为相同的监控负担。

但是，能把成本看清楚，并不意味着没有增加成本层。 BNK 本身需要控制器、TMM、生命周期管理、遥测组件以及许可；这些组件必须被部署、升级、监控和支持。F5 的安装文档显示，telemetry subsystem 会带来统计收集、OpenTelemetry Collector 和 observer 等组件，产品同时存在明确的集群许可流程。这说明 AI service plane 在经营上不可能被简单视作“零成本的标签层”。

它是否最终成为一个新的净成本层，取决于替代关系，而不是产品清单。如果 Telenor 用这一边界统一承担原先分散在不同位置的流量控制、隔离和遥测，并利用租户标识减少重复工具和不可分摊的公共成本，那么新增 service plane 可能更多是一种成本重组；如果原有网络、安全和监控路径继续完整保留，DPU 层只是在其上再叠一套策略、许可和运维体系，那么它就是新增成本池。现有公开资料没有告诉市场 Telenor 属于哪一种情况，因此不能把“架构整合能力”写成“成本已经下降”。

token-aware governance 使这条边界的商业意义更进一步，也正因为如此，Telenor 把它放在未来计划里值得重视。F5 的通用产品文档目前已经支持识别用户、统计输入和输出 token、按用户或模型设置使用上限，并把使用数据输出给外部 metering 和 billing 工具。技术上，这会让 service plane 从“知道是谁的网络流量”继续向“知道谁消费了多少 AI 请求资源”演进。

但 Telenor 公告没有说这套流程已经上线。它只是说计划中的 token-aware governance 和 circuit breaking 将帮助管理 AI consumption 和 usage policies，并支持 entitlement、reporting 和 billing workflows。换句话说，权利控制、报告和计费在此处是未来能力要服务的业务流程，而不是 2026 年 10 月 21 日已经验收的独立产品功能。更高级的 inference-aware traffic optimization 同样是后续计划。

这也解释了为何当前最合理的市场判断不是“F5 为 Telenor 创造了多少节约”，而是：Telenor 已经选择在哪里建立可执行、可观察、可逐步计量的服务边界。 这一步减少了未来做成本归属时的数据歧义，但经济回报仍需要另一组证据——实际部署覆盖率、被替代的旧成本、许可与运维增量、租户级使用数据，以及最终是否形成可持续的内部 chargeback 或外部计费。上述指标目前均未由 Telenor 或 F5 在本次材料中公开。