분산 추론: 50개 데이터 센터를 하나의 서비스로

F5 ADSP | 2026년 10월 20일

Praful Bhaidasna제품 부문 부사장 - F5 BIG-IP Next for Kubernetes | F5

통신사 아키텍트에게 AI 클러스터를 그려 달라고 하면 랙, GPU, 패브릭, 스토리지 등 모든 것을 그려냅니다. 하지만 요청이 그 클러스터에 어떻게 도달하는지 그려 달라고 하면 펜이 멈춥니다. 트래픽은 그저 도착할 뿐입니다. 문 앞에 나타나면 그때부터는 클러스터가 처리합니다.

그 사각지대는 곧 막대한 비용을 초래할 수 있습니다. 분산 추론 환경에서 이러한 공백은 한 시설의 GPU는 유휴 상태인 반면 다른 시설의 대기열은 과부하되는 상황으로 이어질 수 있습니다. 전국에 50개 시설을 보유한 서비스 제공업체는 시설이 두 곳뿐인 하이퍼스케일러가 돈으로 살 수 없는 자산을 갖고 있습니다. 바로 사용자와의 근접성, 전력 공급원의 다양성, 데이터 주권을 보장하는 인프라 거점, 그리고 이미 지중에 구축된 광섬유망입니다.

이는 단일 사이트가 아닌 여러 사이트로 구성된 네트워크에서 모델을 제공하는 분산 추론의 가장 강력한 근거입니다. 하지만 요청이 들어올 때마다 50개 사이트 중 어디에서 응답할지를 결정하는 체계가 있어야만 50개 사이트가 하나의 추론 서비스로 통합될 수 있습니다. 현재는 그런 체계가 없습니다. F5는 NVIDIA, AMD 및 기타 AI 인프라 제공업체와 협력해 이 공백을 메우고 있으며, 이를 통해 서비스 제공업체가 실제로 배포하는 가속기와 추론 스택의 텔레메트리를 기반으로 의사 결정이 이루어지도록 하고 있습니다.

트래픽은 저절로 유입되지 않는다

실제로는 다음과 같은 일이 일어납니다. DNS 조회를 통해 사이트가 선택됩니다. 글로벌 서버 로드 밸런서는 근접성, 상태, 용량을 종합적으로 고려해 주소를 반환합니다. 사이트 내부에서는 프록시가 연결을 종료하고 요청 주체를 확인한 뒤 정책을 적용하며, 로드 밸런서가 서버를 선택합니다. 이러한 일련의 과정을 애플리케이션 인식 라우팅이라고 합니다. 지난 20년간 모든 웹 및 모바일 서비스는 드러나지 않게 이 기술을 기반으로 운영되어 왔으며, 그 기반의 상당 부분을 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가 ID, 액세스 및 트래픽 정책을 적용하고 Endpoint Picker가 워커를 선택합니다.

이 마지막 단계에서 라우팅은 단순히 GPU로 향하는 경로를 넘어 추론 성능의 일부가 됩니다. 엔진이 프롬프트를 처리하면 프리필 단계에서 GPU의 KV 캐시가 채워집니다. 다음 요청이 동일한 접두사를 공유하고 해당 데이터를 여전히 보유한 워커로 전달되면 기존 연산 결과를 재사용할 수 있습니다. 다른 워커로 전달되면 GPU가 이를 다시 계산해야 합니다. 부하가 적을 때는 아무도 그 차이를 알아차리지 못합니다. 하지만 프로덕션 환경에서 동시 요청이 늘어나 작업 세트가 캐시 용량을 초과하면, 요청을 어느 워커에 배치하느냐에 따라 기존 연산을 재사용할지 다시 수행할지가 결정됩니다.

BIG-IP Next for Kubernetes 2.4에서 Endpoint Picker는 워커를 선택하기 전에 캐시 접두사, 큐 깊이, 실행 중인 요청, KV 캐시 사용률, 예상 첫 토큰 생성 시간(TTFT)을 종합적으로 고려합니다. 또한 프리필/디코드 분리와 다음과 같은 개방형 추론 기술을 지원합니다. llm-d 및 Kubernetes Gateway API Inference Extension가 이에 해당합니다. 중요한 점은 세 계층이 컨텍스트를 공유한다는 것입니다. 용량을 기준으로 선택된 사이트가 포화 상태인 클러스터로 요청을 넘기지 않으며, 모델을 기준으로 선택된 클러스터가 컨텍스트를 처음부터 다시 구축해야 하는 워커로 요청을 보내지 않습니다.

GPU가 아는 것을 아는 네트워크

이 모든 것을 구현하기 위해 AI 인프라 외에 별도의 새로운 플랫폼이 필요한 것은 아닙니다. 글로벌 트래픽 조정 계층은 이미 존재합니다. 클러스터 수준의 인텔리전스도 이미 구축되어 있으며, 현재 F5 고객의 프로덕션 환경에서 운영되고 있습니다. 이제 진행 중인 작업은 클러스터 텔레메트리와 요청 의도를 하나의 DNS 결정에 반영하도록 이들을 연결하는 것입니다.

이제 다시 펜을 든 아키텍트의 이야기로 돌아가 보겠습니다. AI 추론에서는 데이터 센터 50곳이 2곳보다 분명 유리하지만, 이는 데이터 센터를 연결하는 네트워크가 GPU의 상태를 파악할 수 있을 때만 가능합니다. 그래야 50개 사이트가 서로 고립된 50개의 컴퓨팅 자원에 머무르지 않고, SLA를 준수하고 국경을 넘지 않으며 이미 비용을 지불한 모든 GPU를 활용하는 하나의 추론 서비스처럼 작동할 수 있습니다.

이 글은 예고편이라고 생각해 주세요. 어떻게 구축했는지, 어떤 도구를 사용했는지, 무엇을 측정했는지 자세히 다룬 본편이 곧 공개됩니다.

F5가 최신 AI 인프라 전반에서 조직의 분산 추론, AI 트래픽 관리 및 GPU 활용률 개선을 어떻게 지원하는지 자세히 알아보세요.