F5 AI 로드 밸런싱, 랩 환경에서 3.24배 기록…단 극한 부하에서만
F5 AI 로드 밸런싱은 F5가 후원한 랩 방문 테스트에서 가장 까다로운 조건하에 Envoy 기반 게이트웨이보다 완료 작업량이 3.24배 더 많았던 것으로 전해진다. 이 결과는 NVIDIA BlueField-3 데이터 처리 장치(DPU)에서 실행되는 BIG-IP Next for Kubernetes를 통해 나왔다. 다만 부하가 가벼운 워크로드에서는 차이가 훨씬 작았다. 이 대비가 헤드라인 수치보다 더 중요하다.
테스트에는 각각 NVIDIA H100 GPU 8개를 장착한 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은 서로 다른 동시성 수준과 프롬프트 길이로 요청을 생성했다. 공유 접두사가 없는 요청, 다중 턴 대화, 혼합 트래픽, 높은 접두사 재사용을 포함한 네 가지 트래픽 패턴이 적용됐다.
기준선은 요청당 입력 토큰 10,000개와 동시 요청 150개를 결합했다. ServeTheHome은 이 경우 두 게이트웨이의 성능이 비교적 비슷했다고 보도했다. 클러스터는 사용 가능한 키-값 캐시 용량의 46%를 사용했다.
일반적으로 KV 캐시로 줄여 부르는 키-값 캐시는 모델이 토큰 생성 중 재사용할 수 있는 어텐션 데이터를 저장한다. 이는 추론 속도를 높이지만 상당한 GPU 메모리를 소비한다. 긴 프롬프트와 많은 동시 사용자는 이 메모리 자원을 편안한 한계 이상으로 밀어 올릴 수 있다.
고부하 테스트에서는 동시성이 150개에서 200개로 33% 증가했다. 각 요청의 입력 길이도 20,000토큰으로 두 배가 됐다. 그 결과 워크로드는 클러스터에서 사용할 수 있는 KV 캐시 용량의 1.24배를 요구했다.
이 과다 할당은 결과를 바꿨다. ServeTheHome은 F5 경로가 까다로운 워크로드를 더 효과적으로 분산했기 때문에 3.24배의 향상을 보였다고 전했다. 공개된 차트는 완료 요청 수, 초당 출력 토큰 수, 첫 토큰까지 걸린 시간도 분석했다.
따라서 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토큰이 포함될 수 있다. 세 번째 요청은 한 GPU의 KV 캐시에 이미 저장된 접두사를 재사용할 수 있다.
이러한 요청은 동일한 GPU에 도달하더라도 서로 다른 처리 시간을 만들 수 있다. 모델이 요청을 배치하고, 메모리를 할당하며, 생성된 토큰을 스트리밍하면서 대기열도 빠르게 바뀐다. 네트워크 엔드포인트가 정상이라도 다음 프롬프트를 보내기에는 좋지 않은 대상일 수 있다.
F5의 로드 밸런싱 문서는 GPU 및 모델 서빙 텔레메트리를 관찰하는 Analyzer 구성 요소를 설명한다. 이 구성 요소는 각 백엔드에 대한 새 트래픽 가중치를 권장한다. 이어 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이 검증한 테스트에서 토큰 처리량이 최대 40% 높게 나왔다고 밝혔다. 같은 발표에서는 첫 토큰까지 걸리는 시간이 61% 빨라졌고 전체 요청 지연 시간은 34% 낮아졌다고 주장했다.
이 수치는 서로 다른 테스트를 설명하기 때문에 3.24배보다 더 절제된 수치다. 외부 테스트 기관이 측정을 수행했더라도, 이는 여전히 벤더가 공개한 성능 주장이다. 구매자는 백분율을 비교하기 전에 기본 구성 사항을 살펴봐야 한다.
F5의 시스템은 LiteLLM, RouteLLM, NVIDIA Router 같은 외부 모델 라우터 앞에 배치될 수 있다. 요청을 선택된 백엔드의 가상 주소로 전달하기 전에 모델 선택 계층을 거치게 할 수 있다.
이는 BNK가 반드시 모든 라우팅 구성 요소를 대체하는 것은 아니라는 의미다. BNK는 이들을 둘러싼 트래픽 및 정책 계층이 될 수 있다. 이러한 더 넓은 위치 덕분에 F5는 GPU 배치를 보안, 계량, 네트워크 강제 적용과 연결할 수 있다.
추론 게이트웨이가 희소 자원의 제어 지점이 되고 있기 때문에 이 아키텍처는 중요하다. 어떤 모델이 요청을 처리할지, 어떤 사용자가 용량을 받을지, 언제 트래픽을 늦춰야 할지를 결정할 수 있다. 잘못된 결정은 네트워크 대역폭 이상의 것을 낭비한다.
실제 경쟁은 GPU 인식 라우팅과 불투명한 백엔드 간의 대결이다
모든 사용 가능한 추론 엔드포인트를 교체 가능한 서버로 취급하는 게이트웨이가 압박을 받는다.
F5의 주된 경쟁 상대는 한 회사가 아니다. 이는 연결은 보지만 각 가속기의 내부 상태는 보지 못하는 오래된 트래픽 관리 모델이다. 랩 테스트는 Envoy AI Gateway를 대표 비교 대상으로 사용했다.
진화하는 클라우드 네이티브 생태계와 관련된 Agent Router 프로젝트는 특화된 AI 라우팅을 향한 더 광범위한 움직임을 반영한다. 명칭과 프로젝트 지형은 계속 변화하고 있어 단순한 제품 비교를 어렵게 만든다.
Envoy 자체는 여전히 널리 사용되는 프록시 기반이다. F5 테스트가 Envoy가 더 스마트한 추론 라우팅을 지원할 수 없음을 입증하는 것은 아니다. 이는 특정 구현, 배치 위치, 정책, 구성을 비교한 것이다.
F5의 차별화는 여러 계층을 결합한다. Endpoint Picker는 백엔드 선택에 실시간 텔레메트리를 사용한다. DPU 배포는 호스트 외부에 트래픽 처리를 배치한다. 더 광범위한 플랫폼은 보안, 테넌트 격리, 토큰 소비를 위한 제어 기능을 추가한다.
이러한 기능을 BlueField-3로 옮기면 두 번째 경쟁 축이 생긴다. 호스트 기반 게이트웨이는 서버의 CPU 사이클과 메모리 대역폭을 소비한다. DPU 기반 게이트웨이는 워크로드와 물리적으로 가까운 위치를 유지하면서 전용 프로세서를 사용한다.
NVIDIA의 AI 팩토리 가이드는 프록시, 로드 밸런싱, 암호화, 방화벽, API 보호를 오프로드하기 위한 한 가지 선택지로 F5 통합을 나열한다. 같은 가이드는 Fortinet과 Palo Alto Networks를 포함한 보안 벤더의 통합도 언급한다.
이 맥락은 시장이 F5 대 Envoy 구도로 축소되지 않을 이유를 보여준다. 인프라 공급업체들은 보안과 트래픽 인텔리전스를 DPU 계층 안에 배치하기 위해 경쟁하고 있다. 오픈소스 프로젝트도 모델 인식 라우팅 기능을 추가하고 있다.
실질적인 결정은 소유권에 관한 것이다. 일부 운영자는 통합 지원과 정책을 갖춘 상용 서비스 플레인을 원한다. 다른 운영자는 플랫폼 팀이 검사, 수정, 운영할 수 있는 조합형 오픈소스 구성 요소를 선호한다.
상용 통합은 텔레메트리, 라우팅, 네트워킹, 보안을 연결하는 데 필요한 작업을 줄일 수 있다. 동시에 특정 벤더의 제어 플레인과 지원 하드웨어 매트릭스에 대한 의존도를 높일 수도 있다. 이 절충은 대규모 플릿 전반에서 중요해진다.
개방형 구성 요소는 유연성과 이식성을 제공할 수 있습니다. 하지만 엔지니어링 팀은 관측성, 정책 집행, 라우팅 로직, 수명 주기 관리를 조립해야 합니다. 이러한 작업의 비용은 단순한 처리량 차트에 좀처럼 나타나지 않습니다.
F5의 입지는 GPU 플릿이 불균일한 워크로드를 가진 다수의 테넌트를 지원하는 환경에서 가장 강합니다. 공유 인프라는 격리, 속도 제한, 사용량 계량, 예측 가능한 서비스 수준의 필요성을 키웁니다. 또한 비효율적인 요청 배치의 비용도 더 커집니다.
소규모 또는 부하가 낮은 클러스터에서는 그 입지가 덜 분명합니다. 엔드포인트가 한계에 거의 도달하지 않는다면 정적이거나 더 단순한 라우팅도 충분할 수 있습니다. 추가 인프라는 그 운영 부담을 정당화해야 합니다.
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토큰 조건에서 나왔습니다. 이 워크로드는 가용 KV 캐시의 1.24배를 요구했습니다. 의도적으로 클러스터를 여유 있는 리소스 경계 밖으로 밀어냈습니다.
이러한 과부하는 스케줄러 동작을 드러내는 데 유용합니다. 동시에 제품의 최적 조건에서의 차별화도 확대할 수 있습니다. 구매자는 정상 활용률, 피크 활용률, 지속적인 과부하 전반에 걸친 결과가 필요합니다.
비교는 라우팅 위치와 라우팅 인텔리전스도 함께 묶었습니다. F5는 DPU에서 실행된 반면 대안은 호스트에서 실행되었습니다. 따라서 이 테스트는 각 설계 선택이 기여한 성능을 분리하지 못합니다.
더 유용한 평가는 여러 구성을 비교할 것입니다. F5는 동일한 정책으로 호스트와 DPU에서 실행될 수 있습니다. 경쟁 게이트웨이는 정적 라우팅과 텔레메트리 인식 라우팅 모두로 실행될 수 있습니다. 그러면 클러스터는 오프로딩과 스케줄링의 기여도를 별도로 보여줄 수 있습니다.
공개 기사에는 많은 차트가 제공되지만 재현에 필요한 모든 원시 로그나 구성 세부 정보가 담기지는 않았습니다. 로그를 시각적 표시로 변환하는 데 인공지능이 도움을 주었다고 언급합니다. 이러한 표현 방식은 기계 판독 가능한 결과 공개의 중요성을 높입니다.
F5의 2026년 3월 performance announcement는 또 다른 근거를 제공합니다. 별도 테스트에서 더 낮은 향상 폭을 보고하며, 검증은 The Tolly Group이 수행했다고 설명합니다.
여러 테스트가 같은 방향의 결과를 보이면 메커니즘의 개연성은 강화됩니다. 그렇다고 그 비율을 서로 교환해 사용할 수 있는 것은 아닙니다. 서로 다른 기준선, 워크로드, 성공 지표는 매우 다른 수준의 개선 수치를 만들 수 있습니다.
완료된 요청, 토큰 처리량, 지연 시간은 각각 다른 질문에 답합니다. 시스템은 일부 사용자의 초기 응답을 더 느리게 하면서도 총 토큰을 더 많이 생성할 수 있습니다. 평균 지연 시간은 낮추면서도 꼬리 지연 시간을 불안정하게 남길 수 있습니다.
실험실은 처리량과 함께 첫 토큰까지 걸리는 평균 및 P99 시간을 검토했습니다. 프로덕션 구매자는 실패한 요청, 재시도율, 응답 품질, 테넌트 간 공정성도 살펴봐야 합니다. 이러한 지표는 더 높은 처리량이 바람직하지 않은 우선순위 부여를 통해 얻어진 것인지 보여줍니다.
모델 서빙 최적화는 출력 일관성에도 영향을 줄 수 있습니다. 프롬프트를 더 작은 모델로 라우팅하면 리소스 사용량은 줄지만 품질은 바뀔 수 있습니다. F5는 더 큰 모델과 더 작은 모델 간 정책 기반 라우팅을 설명하지만, 이 기능은 이번 비교의 핵심은 아니었습니다.
보안 기능은 또 다른 측정 문제를 만듭니다. 암호화, 방화벽 규칙, 토큰 제어, 검사를 처리하는 게이트웨이는 최소한의 라우터보다 더 많은 작업을 수행합니다. 공정한 비교는 활성화된 기능을 맞추거나 그 운영 가치를 설명해야 합니다.
DPU 오프로딩은 호스트 리소스를 보존할 수 있지만, 해당 DPU는 공짜 용량이 아닙니다. 전력을 소비하고 관리가 필요하며 서버 아키텍처의 일부를 차지합니다. 관련 경제 지표는 전체 인프라 비용 대비 전체 클러스터 출력입니다.
“GPU 사이클을 확보한다”는 공급업체의 주장도 신중한 표현이 필요합니다. 네트워크 서비스는 흔히 GPU 자체에서 실행되기보다 호스트 CPU 리소스를 직접 두고 경쟁합니다. 더 나은 라우팅은 GPU 활용률을 높일 수 있지만, DPU가 새로운 가속기 코어를 만들어내는 것은 아닙니다.
3.24배 결과는 하나의 극단적 시나리오에서 병목 관리 우위를 보여주는 근거로 볼 때 가장 신뢰할 만합니다. 이를 용량 계획의 일률적인 배수로 사용해서는 안 됩니다. ServeTheHome조차 이를 관찰된 이점의 상단에 가까운 결과로 설명했습니다.
보고서는 더 절제된 예시도 제시했습니다. 1.25배 향상은 4GPU 기준선에서 5GPU의 출력을 얻는 것과 유사합니다. 이 비유는 경제적 중요성을 전달하지만, 프로덕션 환경의 향상 폭은 각 클러스터에 따라 달라집니다.
팀은 자체 프롬프트 길이 분포, 동시성 곡선, 캐시 재사용, 모델 구성, 서비스 목표를 재현해야 합니다. 그다음 장기간에 걸쳐 일관된 구성을 비교해야 합니다. 짧은 시연으로는 모든 운영 장애를 포착할 수 없습니다.
신뢰할 수 있는 파일럿에는 텔레메트리 장애와 오래된 메트릭도 포함되어야 합니다. 라우팅 컨트롤러가 GPU 상태를 볼 수 없게 되면 운영자는 문제를 얼마나 빨리 감지하는지 알아야 합니다. 예측 가능한 폴백 정책도 필요합니다.
테스트는 DPU 장애, 컨트롤 플레인 중단, 네트워크 파티셔닝을 다뤄야 합니다. 활성 요청이 살아남는지, 새 트래픽이 안전하게 이동하는지를 보여줘야 합니다. 완벽하게 작동하는 상태에서의 성능은 프로덕션 준비성의 일부일 뿐입니다.
실험실의 이점이 실제 환경으로 이어지는지 보여줄 세 가지 신호
다음 시험대는 F5가 설득력 있는 과부하 결과를 일반적인 프로덕션 워크로드 전반에서 반복 가능한 향상으로 전환할 수 있는지입니다.
첫 번째 신호는 독립적인 워크로드 재현입니다. 구매자는 여러 모델, 서빙 프레임워크, 프롬프트 분포에서 원시 데이터와 완전한 구성을 공개하는 테스트가 필요합니다. 결과는 DPU 오프로딩과 텔레메트리 기반 스케줄링을 분리해야 합니다.
중간 수준 부하에서 일관된 개선이 나타난다면 F5의 주장은 더 강해질 것입니다. 의도적인 캐시 초과 할당에서만 이점이 나타난다면 적용 가능한 사용 사례는 좁아질 것입니다. 어느 결과든 용량 계획에 유용한 정보를 제공합니다.
두 번째 신호는 더 폭넓은 배포 근거입니다. F5와 NVIDIA는 기업 및 GPU 서비스 제공업체를 대상 사용자로 설명하지만, 이름이 공개된 프로덕션 사례는 운영 모델을 더 명확히 해줄 것입니다. 유용한 사례는 클러스터 규모, 트래픽 변동, 관찰된 장애 모드를 설명해야 합니다.
프로덕션 근거는 완전한 보안 제어를 활성화한 뒤에도 팀이 약속된 용량 향상을 유지하는지 보여줘야 합니다. 토큰 거버넌스, 암호화, 테넌트 격리, 감사는 모두 추가 작업을 만듭니다. 이들의 결합 효과가 축소된 벤치마크보다 더 중요합니다.
세 번째 신호는 오픈 게이트웨이 및 추론 라우팅 프로젝트의 대응입니다. 이러한 프로젝트가 비슷한 GPU 텔레메트리, 접두사 인식, 캐시 인식 배치를 추가한다면 F5의 라우팅 우위는 표준 기능이 될 수 있습니다.
그 결과 경쟁은 운영 통합, DPU 지원, 보안 정책, 공급업체 서비스 쪽으로 이동할 것입니다. 또한 더 많은 배포 모델을 통해 AI 인식 트래픽 관리를 이용할 수 있게 되어 사용자에게도 이점이 됩니다.
F5는 이미 이 계층들을 결합하고 있기 때문에 의미 있는 입지를 유지합니다. 자사의 platform overview는 BNK를 애플리케이션 제공, 보안, 정책 전반을 아우르는 통합 Kubernetes 트래픽 관리로 설명합니다. DPU 옵션은 이 모델을 AI 인프라로 확장합니다.
그렇더라도 플랫폼의 폭넓음이 입증 책임을 없애지는 않습니다. 클러스터 운영자는 인그레스와 서비스 플레인을 재설계하기 전에 워크로드별 측정을 요구해야 합니다. 피크 초당 토큰뿐 아니라 완료된 요청당 비용을 측정해야 합니다.
개발자에게 이 변화는 모델 코드만으로 추론 성능이 결정되지 않는다는 점을 상기시킵니다. 요청 배치, 캐시 지역성, 큐 관리, 인프라 격리는 동일한 GPU가 완료하는 작업량을 실질적으로 바꿀 수 있습니다.
기업 구매자에게 이 이야기는 확장에 앞선 활용률에 관한 것입니다. 전력, 랙 용량, 납기 일정이 성장을 제한할 때 더 많은 가속기를 구매하는 것보다 더 똑똑한 제어 계층이 실용적일 수 있습니다.
F5 AI 로드 밸런싱 결과는 클러스터가 가장 어려운 순간에 가장 강력한 주장을 펼칩니다. 피크 압력은 용량 구매와 사용자 경험을 좌우하는 경우가 많기 때문에 이는 가치가 있습니다. 동시에 신중한 검증이 가장 중요한 지점이기도 합니다.
3.24배 수치를 도입하기 전에 그 수치를 만든 조건을 재현하십시오. 자체 모델과 정책을 사용해 일반 트래픽, 지속적인 피크, 장애 복구를 비교하십시오. 그다음 결정적인 질문을 던지십시오. 더 똑똑한 라우팅이 제거하는 운영 위험보다 더 큰 운영 위험을 추가하지 않으면서 다음 하드웨어 구매 시점을 늦출 수 있는가?
