모든 GPU에서 판매 가능한 토큰을 더 많이 확보하세요
AI 네이티브 추론 기업의 수익은 GPU 시간당 처리하는 토큰 수에 달려 있으며, 요청 라우팅이 각 GPU의 토큰 생산량을 결정합니다
모든 요청이 수익률을 결정합니다
추론 서비스를 제공하는 기업은 고정 비용으로 GPU 용량을 구매하고, 점점 낮아지는 가격으로 토큰을 판매합니다. 그 차이가 수익 마진이며, 마진의 상당 부분은 요청 처리 경로에서 결정됩니다. 어떤 GPU가 요청을 처리하는지, 해당 GPU의 캐시에 데이터가 미리 적재되어 있는지, 요청이 대기열에서 기다리는지에 따라 달라집니다. 라운드 로빈 방식은 모든 요청을 동일하게 취급합니다. F5는 F5 Application Delivery and Security Platform에서 실시간 서빙 신호를 기반으로 각 요청을 라우팅합니다.
동일한 GPU로 더 많은 토큰 생성
The Tolly Group이 검증한 테스트에서 DPU 모드의 토큰 처리량이 최대 40% 증가했습니다.
더 빠른 첫 토큰 생성
The Tolly Group이 검증한 테스트에서 첫 토큰 생성까지 걸리는 시간이 최대 61% 단축되었습니다.
현재 사용 중인 서빙 스택을 그대로 유지하세요
NVIDIA Dynamo와 NVIDIA NIM의 신호를 기반으로 라우팅하며, 기존 스택의 어떤 구성 요소도 교체하지 않습니다.
모든 고객을 관리하고 보호하세요
고객별 토큰 사용량을 추적하고 제한하며, 모델을 제공하는 API를 보호하세요.
F5는 AI 추론 기업의 수익성 유지를 지원합니다
추론 인식 라우팅
첫 토큰 생성까지 걸리는 시간
고객별 토큰 거버넌스
모델 API 및 에이전트 보안
리소스
보고서
자주 묻는 질문
추론 인식 라우팅은 대기열 길이, KV 캐시 사용률, GPU 부하 등 서빙 계층의 실시간 신호를 활용하여 각 AI 요청을 처리하기에 가장 적합한 모델 서버로 보냅니다. 일반적인 로드 밸런싱은 요청을 균등하게 분산하지만, 추론 요청은 처리 비용의 편차가 크므로 요청을 고르게 분산해도 실제 작업 부하는 불균형해집니다. Kubernetes Gateway API Inference Extension은 이러한 방식을 표준화합니다.
첫 토큰 생성까지 걸리는 시간을 줄이려면 먼저 대기열을 최적화해야 합니다. GPU가 바쁜 상황에서 생성 시간이 긴 요청 뒤에서 대기하는 요청은 모델 속도와 관계없이 첫 토큰을 늦게 반환하기 때문입니다. 대기열이 짧고 캐시가 준비된 엔드포인트로 요청을 라우팅하고, 프롬프트 접두사는 이미 해당 접두사가 저장된 서버에서 처리하도록 하며, 매우 긴 요청은 짧은 대화형 요청과 분리하세요. 배치 처리 설정 조정이나 양자화 같은 모델 측 기법을 적용하면 시간을 더욱 줄일 수 있습니다.
토큰당 비용은 대략 GPU의 시간당 비용을 해당 시간 동안 생성된 유효 토큰 수로 나눈 값입니다. 하드웨어를 구매하거나 임대하면 비용은 대부분 고정되므로, 핵심은 처리량입니다. 이는 GPU 활용률, 캐시 적중률, 배치 처리 효율, GPU 간 요청 분산의 균등성에 달려 있습니다. 토큰 가격이 하락하는 상황에서는 GPU 시간당 토큰 생성량이 조금만 늘어도 수익성에 직접적인 영향을 미칩니다.
아니요, 추론 인식 라우팅은 NVIDIA Dynamo나 vLLM을 대체하지 않습니다. 서빙 프레임워크는 배칭, 캐싱, 스케줄링 등 모델이 GPU에서 실행되는 방식을 결정합니다. 추론 인식 라우팅은 요청을 어떤 서버로 보낼지, 어떤 정책을 적용할지 결정합니다. BIG-IP Next for Kubernetes는 이러한 시스템이 제공하는 신호를 기반으로 라우팅하므로 기존 서빙 스택은 그대로 유지됩니다.
공개된 결과는 DPU 모드의 NVIDIA BlueField-3 DPU에서 측정한 것으로, 호스트 배포 환경에 그대로 적용되지 않습니다. BIG-IP Next for Kubernetes는 표준 호스트 CPU에서 동일한 라우팅 로직으로 실행되며, 컴퓨팅 자원을 임대해 사용하는 대부분의 추론 서비스 기업은 이러한 환경에서 시작하게 됩니다. 호스트 배포 규모는 해당 환경에서 직접 수행한 테스트 결과를 기준으로 산정하세요.