AI 데이터센터, 훈련에서 추론으로의 패러다임 전환

ChatGPT의 전 세계 사용자 수가 2025년 말 10억 명을 바라보는 시대입니다. 생성형 AI가 촉발한 AI가 창출하는 새로운 비즈니스 가치에 대한 공감이 확산하면서 자연스럽게 엔터프라이즈의 관심사는 훈련(Training)에서 추론(Inference)으로 전환되고 있습니다. 이러한 패러다임의 전환은 AI 데이터센터 전략에도 영향을 끼치고 있습니다. 대표적인 것이 플랫폼 운영 전략입니다. 거대한 GPU 자원 풀의 활용률을 극대화하는 데 있어 훈련과 추론 워크로드를 모두 고려해야 하기 때문입니다.

AI 모델 훈련 워크로드는 수 페타바이트(PB)의 데이터를 처리하기 위해 수백, 수천 개의 GPU를 몇 주 또는 몇 달간 독점적으로 사용합니다. 이 워크로드의 유일한 목표는 최대한 빠르게 모델을 훈련하는 데 필요한 처리량(Throughput) 확보입니다.

반면에 AI 모델을 기반으로 실제 서비스를 제공하는 프로덕션 환경의 AI 추론 워크로드는 지향점이 다릅니다. 추론 요청은 대외 서비스의 경우 24시간 365일 동안 중단 없이 발생합니다. 사내 서비스의 경우 업무 시간만 발생합니다. 두 유형 모두 특정 시기나 시점에 요청이 폭주할 수 있습니다. 따라서 일상적인 요청부터 폭주까지 고려해 지연 시간(Latency)를 관리해야 합니다.

이처럼 훈련과 추론은 본질적으로 핵심 관리 지표가 다릅니다. 이를 AI 데이터센터라는 통합 인프라에서 경제적이고 효율적으로 수용하는 것은 매우 중요한 과제라 할 수 있습니다. 이를 잘 풀어 내면 GPU라는 고가의 자원 활용률을 높일 수 있고, 이는 곧 비용 절감으로 이루어지고, 더 나아가 사용자 경험 측면에서도 더 나은 평가를 받을 수 있습니다.

차세대 AI 데이터센터가 직면한 3가지 딜레마

AI 시장에서 추론에 대한 관심이 커지면서 차세대 AI 데이터센터 전략에 이를 어떻게 반영할 지 고민이 깊어지고 있습니다. 어떤 고민들을 하고 있을까요? AI 데이터센터에서 GPU 자원 활용률을 최적화하는 것은 단순한 비용 절감을 넘어, 기업의 AI 기술 혁신 속도와 시장 경쟁력을 결정짓는 핵심 전략 과제입니다. 하지만 모델 훈련을 담당하는 팀의 훈련용 클러스터와 프로덕션 환경에서 사내 및 대외 AI 서비스를 제공하는 팀의 추론용 클러스터를 분리하여 운영하는 기존의 방식은 다음과 같은 딜레마를 안고 있습니다.

구조적 비효율성

전통적인 방식은 훈련용과 추론용 클러스터를 물리적으로 분리하여 구축하고 운영합니다. 이러한 물리적 분리 운영은 자원 사일로 현상을 불러올 수 있습니다. 이 접근 방식은 훈련 클러스터는 모델 훈련 주기에 따라 사용률 변동이 극심하고, 추론 클러스터는 최대 피크 타임을 기준으로 리소스를 할당하므로 대부분의 시간 동안 유휴 상태로 남게 됩니다. KAYTUS의 자료에 따르면 대부분의 기업은 훈련 중 GPU의 38~43%를 사용하며, 추론 중에는 1% 미만을 사용하는 경우도 있다고 합니다. 아마 추론 활용률이 낮다는 사실에 놀라실 것입니다. 예를 들어 간단한 챗봇 서비스를 위해 할당된 고성능 A100 GPU의 VRAM 5%만 사용하고 나머지 95%의 자원이 그대로 방치되고 있다고 가정해 보겠습니다. 이렇게 한쪽 자원이 유휴 상태일 때 다른 쪽에서 이 자원을 활용할 수 없는 구조적 문제가 있으면 원치 않게 자원을 낭비하게 됩니다.

성능 딜레마

처리량과 지연 시간이라는 상충하는 두 요구 사항을 하나의 거대한 GPU 자원 풀처럼 동작하는 AI 데이터센터 환경에서 만족하려면? 성능 딜레마 문제를 마주하게 됩니다. 예를 들어 볼까요. 1,000개의 GPU를 3주간 사용하는 대규모 훈련작업은 처리량에 최적화되어야 합니다. 반면에 1,000명의 사용자를 위해 1/10개의 GPU를 즉시 필요로 하는 추론 작업은 지연 시간에 최적화되어야 합니다. 한쪽을 위해 설계된 시스템은 다른 쪽 워크로드에는 비효율을 보일 수밖에 없습니다. 이는 결국 자원 낭비 또는 서비스 품질 저하로 이어집니다.

운영 복잡성

AI 클러스터의 규모가 수천, 수만 개의 노드로 확장되면 운영의 복잡성은 단순한 관리의 어려움을 넘어서게 됩니다. 실제로 대규모 클러스터에서 개별 노드 장애는 예외적인 일이 아닙니다. 언제든 일어날 수 있습니다. KAYTUS의 자료에 따르면 Llama 같은 거대 언어 모델 훈련 중 발생하는 시스템 장애의 거의 절반이 GPU 및 메모리 문제에서 비롯된다고 합니다. 노드 장애는 언제든 일어날 수 있는 일이란 것이죠. 이러한 장애 발생 시 관리자가 일일이 개입해야 한다면 훈련 작업이 중단되고 개발 로드맵이 몇 주씩 지연될 수 있습니다.

위와 같은 세 가지 문제들은 개별적으로 바라보고 해결책을 찾을 수 있는 것이 아닙니다. 인프라 설계 단계부터 워크로드의 실행, 운영에 이르기까지 전 과정을 아우르는 시각으로 접근해 문제의 본질을 바라봐야 합니다. 그렇다면 이러한 시각은 어떻게 확보할 수 있을까요? MotusAI에서 힌트를 찾을 수 있습니다.

통합 AI DevOps 플랫폼, MotusAI

MotusAI는 앞서 살펴본 도전 과제들을 해결할 수 있습니다. 거대하고 복잡한 AI 데이터센터에서 MotusAI가 어떤 역할을 하는지 알아보겠습니다.

MotusAI의 핵심 역할은 물리적으로 분산되어 있는 서버, 스토리지, 네트워크 자원을 논리적인 단일 리소스 풀(Pool)로 통합하는 것입니다. 이 논리적 풀을 통해 모델 훈련에 할당한 GPU 중 유휴 자원을 트래픽이 폭증하는 프로덕션 서비스에 즉각적이고 자동화된 방식으로 할당해 자원 사일로와 유휴 용량 문제를 해결할 수 있습니다.

다음에 주목할 MotusAI의 역할은 AI DevOps 플랫폼입니다. 기존 DevOps가 주로 코드를 관리했다면 AI DevOps는 코드뿐만 아니라 데이터 파이프라인과 모델이라는 복잡한 자산을 함께 관리해야 합니다. 이는 데이터 준비부터 모델 버전 관리, 하이퍼파라미터 튜닝, 재현성 보장, 그리고 이 모든 것을 전문화된 하드웨어 위에서 수행하는 전 과정을 포함합니다.

자원 통합과 AI DevOps를 어떻게 단일 플랫폼으로 접근할 수 있을까요? 그 방법은 MotusAI의 아키텍처에서 찾을 수 있습니다. MotusAI는 특정 하드웨어에 종속되지 않는 개방형 표준 기술 기반의 유연한 통합 관리 계층으로, 다음과 같은 4개의 계층으로 구성됩니다.

• 인프라 계층: NVIDIA, AMD 등 다양한 이기종 GPU, CPU, NLU와 같은 컴퓨팅 자원과 InfiniBand, RoCEv2 등 고속 네트워크, 그리고 분산/오브젝트/클라우드 스토리지 같은 물리적 기반을 포함합니다.

• 오케스트레이션 계층: Kubernetes(K8S)와 Docker를 기반으로 하는 플랫폼의 핵심 두뇌입니다. 이 계층은 컨테이너 오케스트레이션과 MotusAI의 지능형 스케줄러를 통해 모든 하드웨어 자원을 추상화하고 논리적 풀로 관리합니다.

• 운영 계층: 인프라 자원 풀에 배포한 컨테이너 기반 워크로드 관리, 모니터링, 보안 등을 기능을 제공합니다.

• 도구 계층: 개발자와 운영자가 실제로 상호작용하는 인터페이스입니다. 여기에는 MLOps 도구, 모델 훈련 및 추론 배포, 자산 관리 기능과 더불어 모니터링, 리포팅, 사용자 및 할당량(Quota) 관리 기능이 포함됩니다.

이상으로 AI 관련 민간과 공공 부문의 수요 변화와 관련해 AI DevOps 플랫폼이 필요한 이유 그리고 MotusAI가 어떤 역할을 할 수 있는 지 살펴보았습니다. 더 자세한 내용이 궁금하시면 대원씨티에스로 문의 바랍니다.