F5 AI 负载均衡在实验室中实现 3.24 倍提升，但仅限于极端压力下

据报道，在一次由 F5 赞助的实验室参观测试中，F5 AI 负载均衡在最严苛的测试场景下完成的工作量达到基于 Envoy 的网关的 3.24 倍。该结果来自运行在 NVIDIA BlueField-3 数据处理单元（DPU）上的 BIG-IP Next for Kubernetes。然而，在负载较轻的场景中，两者差距小得多。这种反差比标题数字本身更重要。

测试使用了每台配备八块 NVIDIA H100 GPU 的 Supermicro 服务器。每块 GPU 都以 FP8 数值精度运行 Qwen3-32B 模型。BIG-IP Next for Kubernetes 通过 DPU 管理流量，而对比网关则运行在主机处理器上。

这并不是对所有 Kubernetes 网关或推理集群作出的全面结论。这是在受控条件下进行的一项特定对比，由 ServeTheHome 在一次赞助参观后报道。不过，它仍揭示了一场愈发重要的较量：基于实时 GPU 状态的流量路由，与在很大程度上脱离加速器状态的路由之间的竞争。

核心问题不再是一个集群是否拥有足够多的 GPU，而是当请求变得冗长、并发且难以调度时，其软件能否让这些昂贵的加速器持续高效运转。

F5 BIG-IP Next for Kubernetes 测试让路由承受压力

报告中的优势出现在集群键值缓存超额占用时，而非较为轻松的基准测试中。

这项实验室测试比较了两条运行同一 Qwen3-32B 模型的服务路径。F5 的控制组件和 Endpoint Picker 组件运行在 BlueField-3 DPU 上。另一方案则是在主机上运行 Envoy AI Gateway，该产品后来更名为 Agent Router。

测试追踪了 60 分钟运行期间的 P90 延迟。NVIDIA 的 AI Perf Tool 在不同并发水平和提示词长度下生成请求。四种流量模式涵盖了无共享前缀请求、多轮对话、混合流量以及大量前缀复用。

基准测试采用 150 个并发请求，每个请求包含 10,000 个输入 token。ServeTheHome 报道称，在该场景下两个网关的表现相对接近。集群使用了可用键值缓存容量的 46%。

键值缓存通常简称为 KV cache，用于存储模型在生成 token 时可复用的注意力数据。它可以提高推理速度，但会消耗大量 GPU 内存。长提示词和大量同时在线用户会将这一内存资源推至不舒适的边界之外。

高压测试将并发数从 150 提升至 200，增幅为 33%。同时，每个请求的输入长度也翻倍至 20,000 个 token。由此产生的工作负载需要相当于集群可用 KV 缓存容量 1.24 倍的资源。

这种超额占用改变了结果。ServeTheHome 报道称，F5 路径实现了 3.24 倍提升，因为它能更有效地分配这一高难度工作负载。其发布的图表还考察了完成请求数、每秒输出 token 数以及首个 token 的响应时间。

因此，3.24 倍这一数字应被视为高压场景下的结果。它并不意味着每个集群在部署 F5 软件后都能处理 3.24 倍的流量。同一篇报道也将该数字称为测试配置中的极端值。

这一限定并不意味着测试没有意义。生产推理系统必须承受流量高峰、长上下文以及不均衡的加速器负载。一个在低利用率下表现相近的网关，接近饱和时可能会变得价值高得多。

重要变化在于架构。负载均衡正更贴近模型服务状态，包括队列深度、GPU 利用率和缓存压力。网关不再只根据网络连接作出决策。

F5 将 BIG-IP Next for Kubernetes，即 BNK，称为 AI 服务平面。它位于客户端与 GPU 基础设施之间，同时整合流量管理、安全、路由和使用控制。该产品可运行在主机处理器或受支持的 BlueField-3 DPU 上。

将其部署在 DPU 上，可把网络和安全任务从服务器主处理器中转移出去。DPU 是一种可编程基础设施处理器，旨在处理网络、存储和安全工作。这使主机资源能够用于模型服务和集群运维。

因此，该测试衡量了两个相互关联的理念。其一是在 GPU 内存压力下的路由质量。其二是将基础设施工作转移到专为在主机之外处理这类任务而设计的硬件上。

为什么 F5 AI 负载均衡会在高需求下改善表现

F5 的机制依赖于识别传统网络指标无法描述的加速器状态。

传统负载均衡器可以通过轮询、连接数或固定优先级分配流量。当后端服务器的容量可预测时，这些方法效果良好。大语言模型推理打破了这一假设。

一个请求可能只是简短的问题。另一个可能包含 20,000 个 token 的文档和对话历史。第三个请求则可能复用已存储在某块 GPU KV 缓存中的前缀。

即使这些请求到达相同的 GPU，也可能产生不同的处理时间。随着模型批处理请求、分配内存并流式生成 token，队列状态也会迅速变化。一个网络端点即使健康，也仍可能不是下一个提示词的理想目的地。

F5 的负载均衡文档描述了一种 Analyzer 组件，用于监测 GPU 和模型服务遥测数据。它会为每个后端推荐新的流量权重。F5 的 Traffic Management Microkernel 随后在数据平面应用这些权重。

文档列出的输入包括推理延迟、队列深度、GPU 内存消耗、热状态和错误率。F5 还支持来自 NVIDIA Inference Microservices、NVIDIA Data Center GPU Manager 及 vLLM 的遥测数据。

这一反馈循环解释了为何差距可能在压力下扩大。静态策略无法直接了解哪块 GPU 正接近内存极限。具备遥测感知能力的控制器可以在某个端点的队列成为集群瓶颈之前，减少向其发送的流量。

F5 还将其路由描述为具备前缀感知和 KV 缓存感知能力。前缀感知会尝试将相关提示词发送到已持有可复用上下文的后端。避免不必要的缓存重建，可以减少计算工作和内存抖动。

负载感知服务于不同目标。它根据可用容量分散请求，而不是假定每个端点都同样准备就绪。当这些假设开始偏离时，最显著的结果就应当出现，而实验室的超额占用工作负载正是制造了这种情况。

该软件并不会让 H100 GPU 本身变得更快。它试图减少可用处理时间的浪费。在评估有关 GPU 性能的主张时，这一区别至关重要。

改进调度可以在不改变模型权重或加速器芯片的情况下提高集群总吞吐量。它还可以减少被异常昂贵的提示词阻塞在队列后的请求数量。不过，其收益取决于工作负载多样性和遥测质量。

由短提示词组成的统一批次提供的路由机会较少。高度多变的数据流则为智能调度发挥作用创造了更多机会。实验室结果遵循了这一模式：在较轻负载条件下，差异更小。

F5 的公开文档称，相比轮询路由可实现 30% 至 40% 的吞吐量提升。另据 F5 表示，经 The Tolly Group 验证的测试显示，token 吞吐量最高可提升 40%。同一公告还宣称，首个 token 的响应时间加快 61%，整体请求延迟降低 34%。

这些数字比 3.24 倍更为克制，因为它们描述的是不同测试。即使由外部测试机构完成测量，它们仍属于厂商发布的性能主张。买家在比较百分比之前，应审查底层配置。

F5 的系统可部署在 LiteLLM、RouteLLM 和 NVIDIA Router 等外部模型路由器之前。它可以先让请求经过模型选择层，再将其导向所选后端的虚拟地址。

这意味着 BNK 未必会取代每一个路由组件。它可以成为围绕这些组件的流量和策略层。这一更广泛的位置使 F5 能够将 GPU 调度与安全、计量和网络执行连接起来。

这一架构之所以重要，是因为推理网关正在成为稀缺资源的控制点。它们可以决定由哪个模型处理请求、哪个用户获得容量，以及何时必须减缓流量。糟糕的决策浪费的不只是网络带宽。

真正的竞争是 GPU 感知路由与不透明后端之间的较量

压力正落在那些将每个可用推理端点都视作可互换服务器的网关身上。

F5 的主要对手并非某一家公司，而是一种较旧的流量管理模式：它能看到连接，却看不到每个加速器的内部状态。实验室测试采用 Envoy AI Gateway 作为代表性对比对象。

与不断演进的云原生生态系统相关的 Agent Router 项目，反映出整个行业正推动专门化 AI 路由。其命名和项目格局仍在不断变化，这使得简单的产品对比更加复杂。

Envoy 本身仍是一项被广泛使用的代理基础设施。F5 测试并不能证明 Envoy 无法支持更智能的推理路由。它比较的是特定实现、部署位置、策略和配置。

F5 的差异化能力结合了多个层面。其 Endpoint Picker 利用实时遥测选择后端。DPU 部署将流量处理置于主机之外。其更广泛的平台则增加了安全、租户隔离和 token 消耗控制。

将这些功能迁移至 BlueField-3，形成了第二条竞争轴线。基于主机的网关会消耗服务器的 CPU 周期和内存带宽。基于 DPU 的网关则使用专用处理器，同时仍在物理位置上接近工作负载。

NVIDIA 的 AI factory guide将 F5 集成列为卸载代理、负载均衡、加密、防火墙和 API 保护的一种选项。该指南还列举了包括 Fortinet 和 Palo Alto Networks 在内的安全厂商集成。

这一背景表明，市场不会简化为 F5 与 Envoy 的对抗。基础设施供应商正在争夺将安全和流量智能置入 DPU 层的能力。开源项目也正在增加模型感知路由功能。

实际决策关乎所有权。一些运营者希望采用具备集成支持和策略的商业服务平面。另一些则偏好其平台团队能够检查、修改和运维的可组合开源组件。

商业集成可以减少连接遥测、路由、网络和安全所需的工作量。但它也可能加深对特定厂商控制平面和受支持硬件矩阵的依赖。这一权衡在大规模基础设施中尤为重要。

开放组件可以带来灵活性和可移植性，但也要求工程团队自行整合可观测性、策略执行、路由逻辑和生命周期管理。这类工作的成本很少会在简单的吞吐量图表中体现出来。

当 GPU 集群服务于大量工作负载不均衡的租户时，F5 的定位最具优势。共享基础设施提高了对隔离、速率限制、用量核算和可预测服务水平的需求，也让低效的请求调度变得更加昂贵。

对于小型或低负载集群，F5 的优势则不那么明显。如果端点很少接近容量上限，静态或更简单的路由方式依然可能足够。新增基础设施必须证明其运营负担是合理的。

F5 表示，其路由和 DPU 卸载无需修改模型。这降低了一项采用门槛，因为团队可以保留现有的模型服务器。不过，部署仍涉及新的基础设施组件、遥测管道、策略和故障模式。

该公司的文档称，AI 负载均衡默认处于禁用状态。运营人员必须配置该功能及其数据路径。使用内置分析器时，还需要 Prometheus 和兼容的遥测系统。

当前文档中，只有 NVIDIA GPU 指标具备内置插件支持。使用其他加速器的组织可能需要自定义逻辑。即使在 NVIDIA 环境中，模型服务器、网络布局和编排实践也可能存在差异。

硬件要求同样十分具体。F5 的 DPU requirements 列出了受支持的 BlueField-3 硬件、最低内存要求、双网络接口以及所需的软件组件。

这些要求还指出，DPU 必须专用于 BNK。文档警告称，其他 DPU 软件可能造成性能问题或 Kubernetes 不稳定。在该文档所述配置中，BNK 每个机箱仅支持一个 DPU。

这些限制使采购决策不再只是比较网关基准测试。团队必须决定如何分配 DPU、管理固件、集成网络以及恢复故障组件，并将这些工作与节省的主机容量进行比较。

3.24 倍性能声明无法证明什么

这项实验室结果是一个有用的压力信号，但并非对普遍生产优势的独立证明。

ServeTheHome 明确披露，F5 赞助了此次加州实验室访问。这种透明度有助于读者理解该报告，但并不能消除独立复现的必要性。

硬件、模型、精度、提示词长度和请求模式都经过严格定义。每个变量都可能改变路由行为。不同的模型或推理引擎可能以不同方式处理缓存压力。

最强结果来自并发数为 200、上下文长度为 20,000 token 的条件。该工作负载所需的 KV 缓存是可用容量的 1.24 倍，刻意让集群超出舒适的资源边界。

这类过载对于暴露调度器行为很有价值，但也可能放大产品在最佳情况下的差异化优势。买方需要看到正常利用率、峰值利用率和持续过载条件下的结果。

这项比较还将路由位置与路由智能结合在一起。F5 运行在 DPU 上，而替代方案运行在主机上。因此，测试无法分离每种设计选择各自带来的性能贡献。

更具解释力的评估应比较多种配置。F5 可在主机和 DPU 上采用同一策略运行；竞争网关则可同时采用静态路由和遥测感知路由。随后，集群便可分别展现卸载和调度所带来的贡献。

公开文章提供了许多图表，但未提供复现所需的全部原始日志或配置细节。文章提到，人工智能协助将日志转换为可视化展示。这种呈现选择更凸显了发布机器可读结果的重要性。

F5 在 2026 年 3 月发布的 performance announcement 提供了另一项证据。该公告报告了来自独立测试的较低增益，并称验证工作由 The Tolly Group 完成。

多项测试若呈现相同方向的结果，会增强该机制的可信度，但并不意味着这些百分比可以互换。不同的基线、工作负载和成功指标，可能产生截然不同的标题式提升幅度。

完成请求数、token 吞吐量和延迟分别回答不同的问题。一个系统可以生成更多总 token，却让部分用户获得更慢的首 token 响应；它也可以降低平均延迟，同时尾部延迟仍不稳定。

实验室测试在吞吐量之外，还考察了平均和 P99 首 token 时间。生产环境买方还应研究失败请求、重试率、响应质量以及跨租户公平性。这些指标可以揭示更高吞吐量是否来自不理想的优先级安排。

模型服务优化也可能影响输出一致性。将提示词路由至更小的模型可以降低资源使用，但可能改变质量。F5 描述了在更大和更小模型之间进行基于策略路由的功能，尽管这并不是本次比较的核心。

安全功能带来了另一项测量难题。处理加密、防火墙规则、token 控制和检查的网关，比最精简的路由器承担更多工作。公平比较必须对齐已启用的功能，或说明其运营价值。

DPU 卸载可以保留主机资源，但这些 DPU 并非免费的容量。它们消耗电力、需要管理，并占用服务器架构的一部分。相关的经济指标应是总集群输出相对于总基础设施成本。

供应商关于“释放 GPU 周期”的说法也需要谨慎表述。网络服务通常直接竞争的是主机 CPU 资源，而不是在 GPU 本身上执行。更好的路由可以提高 GPU 利用率，但 DPU 不会创造新的加速器核心。

3.24 倍结果最可信的解读，是它证明了某一极端场景下的瓶颈管理优势。它不应被当作容量规划中的通用乘数。ServeTheHome 也将其描述为接近所观察到收益的上限。

报告给出了一个更温和的例子：1.25 倍的提升类似于在四块 GPU 的基础上获得五块 GPU 的输出。这个类比传达了经济层面的利害关系，但生产环境中的收益将取决于每个集群自身情况。

团队应复现自身的提示词长度分布、并发曲线、缓存复用、模型组合和服务目标，然后在长期运行中比较一致的配置。短暂演示无法捕捉所有运营故障。

可靠的试点测试应包含遥测中断和指标陈旧的情况。如果路由控制器失去对 GPU 状况的视图，运营人员需要知道系统能多快检测到问题，也需要可预测的回退策略。

测试还应涵盖 DPU 故障、控制平面中断和网络分区，并展示活跃请求是否能够存活、新流量是否能安全迁移。完美运行状态下的性能只是生产就绪程度的一部分。

三个信号将表明实验室优势能否延续到实际环境

接下来的考验是，F5 能否将令人信服的过载测试结果，转化为在日常生产工作负载中可重复获得的收益。

第一个信号是独立的工作负载复现。买方需要覆盖多种模型、服务框架和提示词分布的测试，并公开原始数据和完整配置。结果应将 DPU 卸载与遥测驱动调度区分开来。

在中等负载下持续改善将强化 F5 的论点。若收益仅在刻意超额占用缓存时出现，可服务的使用场景就会缩小。无论结果如何，二者都能提供有价值的容量规划信息。

第二个信号是更广泛的部署证据。F5 和 NVIDIA 将企业及 GPU 服务提供商描述为目标用户，但具名的生产案例将使其运营模式更加清晰。有价值的案例应说明集群规模、流量变化和观察到的故障模式。

生产证据还应展示，团队在启用完整安全控制后是否仍能维持承诺的容量收益。token 治理、加密、租户隔离和审计都会增加工作量。它们的综合影响比精简基准测试更重要。

第三个信号来自开放网关和推理路由项目的反应。如果这些项目加入可比的 GPU 遥测、前缀感知和缓存感知调度能力，F5 的路由优势可能会成为标准功能。

这一结果将使竞争转向运营集成、DPU 支持、安全策略和供应商服务。它也将让用户受益，因为 AI 感知流量管理可通过更多部署模式获得。

F5 仍保有重要定位，因为它已经整合了这些层级。其 platform overview 将 BNK 定位为统一的 Kubernetes 流量管理平台，覆盖应用交付、安全和策略。DPU 选项则将这一模式延伸至 AI 基础设施。

不过，平台广度并不能消除举证负担。集群运营者在重新设计入口和服务平面之前，应要求获得针对其工作负载的测量数据。他们应衡量每个完成请求的成本，而不仅仅是每秒峰值 token 数。

对开发者而言，这一进展提醒人们：模型代码已不再单独决定推理性能。请求调度、缓存局部性、队列管理和基础设施隔离，都能显著改变相同 GPU 可完成的工作量。

对企业买方而言，这个故事首先关乎在扩容前提升利用率。当电力、机架容量或交付周期限制增长时，更智能的控制层可能比采购额外加速器更实际。

F5 AI 负载均衡结果在集群最艰难的时刻提出了最有力的论证。这很有价值，因为峰值压力往往决定容量采购和用户体验；同时，这也正是最需要仔细验证的地方。

在采用 3.24 倍这一数字之前，请复现产生它的条件。使用你自己的模型和策略，比较日常流量、持续峰值和故障恢复。然后提出决定性的问题：更智能的路由是否能推迟下一次硬件采购，同时增加的运营风险是否少于它所消除的风险？