上一篇文章最后留下了一个问题：

如果真的把 GPU 放到 OLT 旁边，用户到底怎么才能用上这份算力？

这问题比"能不能放"更值得琢磨。

算力部署过去，只说明那儿有了计算资源。用户要真用上，还得解决几个事：

• AI 请求从哪进来？
• 网络咋知道这是 AI 请求？
• 用户面在哪？
• 业务怎么被引到合适的算力？
• 不同 AI 业务，该用哪儿的算力？

上一篇从地理、网络、服务三个维度看 Edge。这篇往下具体看，落在三个部署要素上：

• 算力放哪？（地理维度）
• 用户面在哪？（网络维度）
• 服务入口在哪？（服务维度）

这三个要素如果能协同一致，Edge 才有意义。否则 GPU 再近，也只是机房里的一堆铁疙瘩。

GPU 有了，用户从哪进门？

假设 OLT 机房真放了一组 GPU（算力资源）。物理距离上，它离用户很近。

但用户不会因为 OLT 旁边多了几台 GPU，就知道这儿有 AI 服务。用户访问的是 AI 服务，不是 GPU。

一份能被用户用的 AI 服务，除了 GPU，还得有模型、推理服务、数据、服务入口。这个入口，可以叫 AI Gateway。

它负责接用户的 AI 请求，再把请求送到合适的 AI 服务和算力节点。

简单说就是：

用户请求 → AI Gateway → 服务选择 → Edge GPU

GPU 是底层算力。AI Gateway 更像用户进 AI 服务的一扇门。没这扇门，GPU 就算在用户隔壁，也只是机房里一组计算设备。

AI Gateway 不一定是台单独设备，也不一定非得部署在 OLT 上。它可以集中，也可以分层。比如部署在核心管全局调度，部署在区域或接入侧管本地服务发现。

问题就变成了：用户的请求，怎么找到这扇门？

从部署三要素来看，AI Gateway 主要解决服务入口的事：

• 用户请求从哪进入AI 服务
• 服务怎么被发现和选
• 请求怎么被引到合适的算力节点

网络怎么知道这是 AI 请求？

这事儿比想的复杂。

现在大量业务跑在 HTTPS 上。网络通常看不到应用层内容，也就不能简单通过读报文判断：“这是个 AI 请求。”

这里要分两种情况。

运营商自己的 AI 服务，相对简单。AI Gateway 本身就是入口，用户访问这入口，请求自然进运营商自己的 AI 服务体系。

第三方 AI 服务就不一样了。运营商通常没第三方服务的 DNS 控制权，也看不见 HTTPS 里面的具体内容。这时候只能用 SNI、IP 地址、流量特征判断是否是AI请求，但最好是能跟服务商合作拿到更明确的业务信息。

所以 AI 业务识别，不只是网络设备加个"AI 识别功能"这么简单。有效正确的识别，往往要应用、DNS、服务入口、网络策略一起配合。

应用知道自己在调什么服务。网络负责把请求引向合适入口。AI Gateway 再根据用户、业务、资源情况选具体服务和算力。

网络其实不需要知道用户给大模型输的每句话。它要解决的是：这个请求该去哪。

但这儿有个容易被忽略的问题。

AI Gateway 解决的是"业务该去哪"，网络还得解决"报文怎么来的"。

AI业务的HTTP/HTTPS 请求最终还是承载在用户的 IP 会话上，在运营商广泛采用 PPPoE 宽带接入方式下，如果要在用户接入侧完成三层业务分流，得先由用户面完成 PPPoE 会话终结，建立相应的三层业务上下文。

这就引出下一个问题： 用户面到底在哪？

GPU 在 OLT 旁边，BNC-UP 还在核心，咋办？

以固网宽带为例。传统 PPPoE 接入下，用户 PPP 会话在 BNG/BRAS 终结。联通 BNC 架构里，由 BNC-UP 承担用户面功能。

典型业务路径：

用户 → ONU/ONT → OLT → 承载网 → BNC-UP → Internet/云

AI Gateway 和 GPU 都部署在 OLT 局所，但 BNC-UP 还在远端本地核心，这就有问题了。

用户的 AI 请求虽然从 OLT 进了网，但还得先到核心的 BNC-UP 完成用户面处理，再被转发回 OLT 附近的 AI Gateway 和 GPU。

也就是说： GPU 已经很近了，用户面却还在远处。流量走的路反而变长了。

一个完整的交互路径成了这样：

用户 → OLT → 核心 BNC-UP → OLT 附近 AI Gateway / GPU → 核心 BNC-UP → 用户

这就是典型的流量折返（Trombone），也可以叫"迂回路由"“折返路由"或"流量绕行”。

GPU 本来是为了靠近用户而下沉的。如果用户面留在核心，业务流量却要先上核心、再回接入侧，GPU 位置带来的低时延优势，就可能被网络路径上的折返抵消。

从部署三要素来看：

• 地理上，GPU 已在 OLT 附近，离用户很近
• 网络上，用户面（BNC-UP）仍在远端核心，流量路径没真下沉
• 服务上，AI Gateway 和 AI 服务逻辑虽在 OLT 侧，但得等流量从核心绕回来才能发挥作用

三要素没协同，地理上的"近"，很难变成真正的 Edge 体验。

所以我越来越觉得： 算力离用户近，不等于 AI 服务离用户近。用户面的位置同样重要。

如果用户面不能和算力、服务入口在路径上对齐，“算力下沉"很容易变成"资源下去了，业务路径没下去”。

BNC-UP 到底该在哪？

现在 BNC-UP 主要集中部署在本地核心。对传统互联网业务，这有合理性——大量的流量是访问IDC的，IDC一般位于本地的核心位置或本地外的互联网其他位置，总体来说是个南北汇聚性业务，用户面在核心，距离业务近，建设运维也方便。

但后期大概会有越来越多 AI 服务向边缘靠近，新问题出来了：用户面是不是也该有更灵活的部署方式？是否像之前的IP城域网将BNG部署在汇聚节点就可以了？

但别简单理解成"以前在核心，现在退回汇聚"。这不是回到过去的问题。

不同业务，对位置要求不一样。

普通互联网业务、一般大模型问答，对极低时延不敏感。用户面集中在本地核心，没大问题。

区域性 AI 业务，比如区域视频分析、智慧城市，算力可能在区域节点。这时候用户面也可以考虑更靠近区域侧。

再往下，工业视觉、实时云渲染、车路协同这类对时延敏感的业务，算力可能就在接入局所或附近。那用户面也得考虑能不能再靠近。

还有一类是企业自己的 AI。企业可能希望数据和模型留在园区或内部。这时候用户面、AI Gateway、算力的位置，可能围绕企业自身业务位置来设计。

与其说 BNC-UP 要"下沉"，不如说： BNC-UP 的位置不该永远只有一个答案。面向不同业务，它可能需要更灵活的分布式部署能力。

这也是 AI 时代网络架构变化里，我觉得值得继续研究的点。从工程三要素来看，这是在调整网络维度（用户面位置）来协同地理维度（算力位置）和服务维度（业务类型）的差异。

用户面下沉了，也不等于 AI 服务就近了

假设 BNC-UP 真下沉到 OLT 附近。Edge AI 就自然成立了？还是不一定。

比如用户面下沉了，但 AI Gateway 和 GPU 还在核心：

用户 → OLT → Edge BNC-UP → 核心 AI Gateway → 核心 GPU

用户面近了，AI 服务本身没下沉。

反过来，算力下沉了，用户面还在核心：

用户 → OLT → 核心 BNC-UP → OLT 附近 GPU → 核心 BNC-UP → 用户

又是前面说的流量折返。

真正值得关注的不是"哪个设备一定要下沉"，而是： 业务路径上的几个关键环节，能不能形成合理的配合。

回到 PPPoE。为什么不能让 OLT 看到 AI 流量后，直接扔给旁边的 GPU？因为传统 PPPoE 架构下，OLT 主要管接入和二层转发。PPPoE 会话终结、用户地址分配、用户业务处理，都在用户面完成。OLT 本身没有完整的用户三层业务上下文。

所以如果想在接入侧真完成三层业务分流，分流位置得具备相应的用户面功能。这正是分布式 BNG 解决的问题之一：控制面可以集中，用户面根据业务需要向边缘部署。它不是绕过用户面，而是把用户面放到更合适的位置。

从三要素来看，这在强调：

• 地理层：算力可部署在 OLT 附近或区域节点
• 网络层：用户面需能根据业务类型，在核心、区域或接入侧灵活终结
• 服务层：AI Gateway 和服务编排要能和用户面、算力形成一致的业务路径

再往下，还得考虑两个问题：服务怎么选、流量怎么过。AI Gateway 不只是找台 GPU，还得找到合适的服务和算力。用户面得能把相应业务真正送到那个服务和算力节点。

这样看，Edge 不是把某个设备搬到用户身边就完了，而是要让用户面、服务入口、算力之间形成一条合理的业务路径。

Edge 不是某台设备的位置，而是一条由服务入口、用户面、算力共同构成的业务路径。

只有这条路径在地理、网络、服务三个要素都"对得上"，用户才能真感受到"算力就在身边"。

算力不一定跟着用户走，服务应该按需下沉

一路追求"离用户越近越好"，容易得出简单结论：给每个 OLT 都放 GPU。

不现实。GPU 不只是买台服务器的事。还有电力、散热、空间、运维，更重要的是算力利用率。一个 OLT 覆盖的用户很多，不意味着这些用户会持续产生足够多的 AI 请求。

我更倾向这样理解： 算力适度集中，服务按需下沉，流量精细引导。

核心的云池仍承担大量通用 AI 服务。汇聚节点的Edge 承担一些对时延和数据位置敏感的业务。更靠近接入侧的算力，服务于少数真正需要本地处理的场景。

重点不是让每个 OLT 都拥有一份算力，而是：用户请求到来后，网络能找到距离、能力、负载都合适的算力。这可能比"每个 OLT 放多少 GPU"更重要。

这就是地理、网络、服务三个要素协同后的结果。

从 OLT 到 Cloud CO：接入局所会发生什么变化？

再回头看 OLT，觉得它的角色会变得有些不同。

OLT 仍是接入设备。计算可以放在附近的通用服务器上。用户面根据业务需要部署。AI Gateway 负责服务入口和业务引导。再往上，还有统一的服务、算力及资源管理。

真正变的可能不是 OLT 本身，而是： OLT 所在的这个局所，未来能不能承载更多东西？

类似思路早有人探索过。CORD 就是代表项目之一。它提出把传统 Central Office（端局） 重新改造成能承载数据中心能力的环境，通过虚拟化承载包括 vOLT 在内的网络功能。后来 ONF 又发展出 SEBA 等方案。具体技术路线变了，但有个思路今天仍值得回头看：

传统端局不一定永远只是放网络设备的地方。

如果未来一个接入局所同时具备网络接入、用户面、一定计算能力、服务编排能力，它就可能在地理、网络、服务维度上都具备 Edge 特征。如果未来一个接入局所同时具备这些，它就可能逐渐成为连接用户、网络、算力的近端基础设施。

至于 GPU 是放在 OLT 旁边，还是同机房服务器机柜，甚至附近的小型 Edge DC，反而只是具体实现方式。

回到最初的问题

现在再看最开始的问题：把 GPU 放到 OLT 旁边，用户就能用上算力了吗？

答案显然没这么简单。

用户首先需要一个服务入口。网络需要知道请求该去哪。用户面需要能把业务送到合适的地方。AI Gateway 还得找到合适的服务和算力。最后，算力才真正完成 AI 处理。

上一篇从地理、网络、服务三个维度讨论 Edge，这篇思考到现在，可以得到个比较简单的认识：

Edge 不是某台设备的位置，而是一条业务路径。

这条路径能不能真正靠近用户，取决于服务入口、用户面、算力之间能不能配合起来。

也正因为如此，我现在越来越觉得：“OLT + GPU"只是个设备部署问题。真正值得研究的，是运营商这些遍布用户身边的接入局所，未来能不能逐步成为连接用户、网络、算力和 AI 服务的近端基础设施。

过去，接入网络主要解决：用户怎么接入网络。

以后可能还要继续解决：

• 用户的 AI 请求怎么找到合适的服务
• 服务怎么找到合适的算力
• 算力怎么真正通过网络被用户使用

这样再回头看"OLT 能不能成为算力边缘节点”，答案似乎变了点。

也许真正值得讨论的，不是"要不要给 OLT 旁边放块 GPU？“而是： 当算力进入网络以后，原来的接入网络，会不会逐渐变成连接用户、服务和算力的一部分？

换句话说，接入网络是不是也能在地理、网络、服务维度上，一起向 Edge 演进？

这个问题，可能比 OLT 本身是不是个"算力节点”，更值得继续往下想。

至此，《OLT 能不能成为算力边缘节点》系列文章告一段落，片面之见，欢迎讨论指正。随着 AI 应用的逐渐普及深入，AI所带来的业务和流量的变化对本地网络的发展会产生什么样的影响，也是值得下一步研究。