分布式推理：50个数据中心，一项服务

F5 ADSP | 2026年10月20日

Praful Bhaidasna产品副总裁，F5 BIG-IP Next for Kubernetes | F5

让电信架构师画出一个AI集群，他们会画出机架、GPU、网络架构、存储等所有组件。但如果让他们画出请求如何到达该集群，他们就会停笔。流量仿佛会自行到达，出现在集群入口，之后便由集群接手处理。

这一盲区很快就会带来高昂代价。对于分布式推理而言，这一缺口可能导致一个站点的GPU闲置，而另一个站点的队列不堪重负。一家在全国拥有50处设施的服务提供商，具备仅有两处设施的超大规模云服务商无法购买的优势：贴近用户、多样化的电力供应、主权基础设施布局，以及已经铺设的光纤。

这正是采用分布式推理的有力理由：通过站点网络而非单一站点提供模型服务。但要让50个站点形成一项统一的推理服务，就必须针对每个请求确定应由哪个站点响应。目前还没有任何机制能够做到这一点。F5正与NVIDIA、AMD及其他AI基础设施提供商合作弥补这一缺口，使决策能够基于服务提供商实际部署的加速器和推理堆栈所提供的遥测数据。

流量不会凭空到来

实际过程如下：DNS查询会选择一个站点。全局服务器负载均衡器会综合评估距离、运行状况和容量，并返回一个地址。在站点内部，代理会终止连接、检查请求方身份并应用策略，随后由负载均衡器选择服务器。这一流程称为应用感知路由。20年来，它一直在幕后支撑着各种Web和移动服务，而其中很大一部分由F5构建。

这套链路仍然适用于AI，只是它做决策时依据并不合适。全局服务器负载均衡器（GSLB）知道哪个站点距离最近、哪个站点正常运行，却不知道哪个站点已加载模型、该站点的GPU是否已饱和，也无法判断当前请求是不能跨越全国传输的语音交互，还是可以调度到容量成本较低之处的长时间智能体任务。因此，它会选择距离最近且运行正常的站点，但该站点可能正处于高负载状态，而200公里外配置相同的集群却有一半容量闲置。

从应用感知路由迈向AI感知路由

关键转变在于：应用感知路由必须升级为AI应用感知路由。链路不变，DNS不变，代理不变，只需增加两个新输入。

第一个新输入是来自AI基础设施内部的遥测数据。每个集群都知道自己正在提供哪些模型、队列有多深、正在使用多少KV缓存、有多少请求正在处理，以及新请求需要等待多久才能收到首个令牌。F5 BIG-IP Next for Kubernetes已部署在这些集群的前端，能够查看所有这些信息，甚至包括每个请求的令牌数。将这些信息向上传递后，F5 DNS解决方案所掌握的将不再只是一张标示站点位置的地图，而是每个站点当前能力的实时视图。

F5 DNS解决方案将各站点的实时推理遥测数据与请求意图相结合，把请求引导至当前能够满足其SLA的站点。

第二个因素是请求意图。支持LLM感知的路由器可以在请求被分配之前对其进行分类，包括请求需要哪种模型、对延迟有多敏感、大致需要多少工作量，以及租户付费使用的是哪个SLA等级。这样，请求意图就会成为生成DNS应答的输入，而不是等请求落到错误位置后才被识别。

将两者结合起来，服务级别协议（SLA）就不再只是合同中的一段条款，而会转化为路由规则。延迟SLA会将请求路由到已加载所需模型且仍有充足余量的最近站点。成本SLA会将请求路由到当前可用且成本较低的容量。数据主权要求则确保请求始终留在相应国家/地区境内。GSLB仍然执行其一贯能够做出的决策，但现在有了过去无法获得的信息。

三级决策，一个答案

部署位置并非由单一决策决定，而是由三个层层嵌套的决策共同决定。

在全球范围内，F5 DNS解决方案会选择站点或AI工厂，如今不仅依据邻近性、运行状况和数据主权，还会参考实时推理遥测数据和请求意图。
在区域层面，请求会被引导至具备适用模型和可用容量的集群，并在使用任何GPU之前通过租户专属安全边界实施隔离。
在本地，在集群内部，BIG-IP Next for Kubernetes应用身份、访问和流量策略，并由Endpoint Picker选择工作节点。

在最后这一层，路由不再只是通往GPU的路径，而是会影响推理性能。当引擎处理提示词时，预填充阶段会填充GPU的KV缓存。如果下一个请求具有相同的前缀，并被分配到仍保留该前缀的工作节点，就可以复用已有计算结果。如果被分配到其他节点，GPU就需要重新计算。负载较低时，这种差异并不明显。但在生产环境的并发负载下，工作集会超出缓存容量，此时，请求分配将决定计算结果是被复用还是需要重新生成。

在BIG-IP Next for Kubernetes 2.4中，Endpoint Picker会综合考虑缓存前缀、队列深度、正在运行的请求、KV缓存利用率以及预计首个令牌生成时间，然后再选择工作节点。它支持预填充与解码分离，以及以下开放推理技术：llm-d和Kubernetes Gateway API Inference Extension。关键在于，这三个层级共享上下文。根据容量选定的站点不会将请求转交给已满载的集群。根据模型选定的集群也不会将请求发送到需要从头重建上下文的工作节点。