"20분 로딩을 몇 초로"… AWS, LLM 콜드 스타트 잡는 CPU 바이패스 공개

P6e 인스턴스와 Llama 3.1 405B가 마주한 '로딩 병목'

"왜 최신 GPU를 도입했는데도 모델 실행 전까지 한참을 기다려야 할까?" Llama 3.1 405B 같은 거대 모델을 배포할 때 겪는 지루한 로딩 대기 시간이 그 답이다. BF16 정밀도 기준 약 800GB에 달하는 Llama 3.1 405B의 체크포인트 데이터를 기존의 CPU 기반 방식으로 로드하면 보통 10분에서 20분이 소요된다. 이 과정은 기본적으로 단일 스레드로 동작하며, 체크포인트를 CPU 메모리로 스트리밍한 뒤 PCIe 버스를 통해 각 GPU에 순차적으로 복사하는 CPU 바운드 작업이다. 체크포인트를 미리 분할해 두는 방식을 써도 여전히 수 분의 시간이 걸린다. 이 시간 동안 시스템에서 가장 고가의 자원인 GPU는 아무런 연산을 하지 못한 채 유휴 상태로 머물며, 이는 곧바로 콜드 스타트 TTFT(Time to First Token, 첫 토큰 생성 시간)의 치명적인 증가로 이어진다.

AWS는 이러한 초거대 모델의 연산 수요를 처리하기 위해 NVIDIA Blackwell 아키텍처 기반의 EC2 P6e 및 P6 인스턴스 제품군을 출시했다. 플래그십인 P6e UltraServer는 단일 NVLink 도메인에 72개의 Blackwell GPU를 집적한 구조다. 130 TB/s의 비섹션 대역폭과 13.4 TB의 HBM3e(고대역폭 메모리)를 보유했으며, 연산 성능은 FP8 기준 360 페타플롭스, FP4 기준으로는 720 페타플롭스에 달한다. 이러한 UltraServer는 주로 수조 개의 파라미터를 가진 프런티어 모델의 대규모 분산 학습을 위해 사용되며, 단일 노드 내에서 극도로 높은 데이터 전송 효율을 목표로 설계되었다.

하지만 하드웨어의 연산 성능이 비약적으로 상승했음에도 데이터를 메모리에 올리는 물리적 경로는 여전히 병목 구간으로 남아 있다. P6e와 같은 고성능 인스턴스는 시간당 이용 비용이 매우 높게 책정되어 있어, 로딩 중 발생하는 GPU 유휴 시간은 곧바로 기업의 매몰 비용으로 환산된다. 특히 추론 서빙 환경에서 긴 로딩 시간은 서비스 가용성과 응답 속도에 직접적인 악영향을 미치는 요소다. 모델 파라미터가 수천억 개 단위로 확장되면서, 이제는 단순한 TFLOPS(초당 부동소수점 연산 수) 경쟁보다 GPU 메모리로 가중치를 얼마나 빠르게 로드하여 유휴 시간을 제거하느냐가 전체 추론 시스템의 경제성과 효율을 결정하는 핵심 변수가 됐다.

기술이 실제로 작동하는 방식

거대 모델을 GPU에 올릴 때 왜 여전히 로딩 시간이 병목이 될까. 문제는 데이터가 이동하는 물리적 경로에 있다. Amazon FSx for Lustre(고성능 병렬 파일 시스템)와 NVIDIA GPUDirect Storage(GDS)를 결합하면 이 경로가 획기적으로 짧아진다. 기존에는 CPU 메모리를 거쳐 PCIe 버스로 복사하던 단계를 생략하고, 데이터가 FSx for Lustre에서 EFA(Elastic Fabric Adapter, AWS 전용 네트워크 인터페이스)를 거쳐 GPU HBM(고대역폭 메모리)으로 직접 전송된다. CPU와 시스템 메모리를 완전히 우회하여 데이터를 쏘아 올리는 바이패스 구조를 구축해 전송 효율을 극대화한 것이다.

전송 효율을 결정하는 구체적인 수치는 파일 시스템 구성에서 나온다. Persistent_2 EFA 파일시스템을 1000 MBps/TiB 설정과 20개의 OST(Object Storage Targets)로 구성하면 약 94 GiB/s의 처리량을 확보한다. 파일 시스템의 전체 용량이 커질수록 OST의 개수가 늘어나고, 이에 따라 병렬 I/O 경로가 확장되면서 처리량은 선형적으로 증가한다. 용량 확장이 곧바로 로딩 속도의 향상으로 이어지는 구조다. 이는 단순한 소프트웨어 최적화가 아니라 스토리지의 물리적 처리 능력을 GPU 메모리에 직접 연결해 데이터 전송의 고속도로를 뚫은 셈이다.

실제 환경에 이를 구현하려면 커널 모듈 설치와 인터페이스 정렬 작업이 필수적이다. AWS가 제공하는 설정 스크립트를 실행하면 인스턴스 타입을 자동으로 감지하고, NUMA(Non-Uniform Memory Access) 인식 CPU 파티셔닝을 통해 EFA 인터페이스를 최적화한다.

bash

setup.sh –optimized-for-gds

이 스크립트는 systemd 서비스를 생성해 재부팅 후에도 설정이 유지되도록 만든다. P5en 인스턴스의 경우 기본적으로 8개의 EFA 인터페이스를 FSx for Lustre에 할당해 스토리지에서 각 GPU HBM으로 이어지는 직접적인 GDS 데이터 경로를 형성한다. 여기에 nvidia-fs.ko 커널 모듈을 빌드하여 로드하고 cufile.json 런타임 설정 파일을 배치해야만 물리적 바이패스가 완성된다.

결국 이 기술의 핵심은 고가의 GPU 자원이 데이터를 기다리며 낭비되는 유휴 시간을 제거하는 데 있다. 인프라 설정 스크립트를 적용하고 스토리지 아키텍처를 GDS 중심으로 변경하는 것만으로 데이터 흐름의 병목 지점을 물리적으로 삭제한다. 이는 모델 로딩 시 발생하는 콜드 스타트 TTFT(Time to First Token, 첫 토큰 생성 시간)를 최적화하기 위한 가장 확실한 인프라적 기준이 된다.

기존 방식과 달라진 지점

엔지니어가 대규모 모델을 배포할 때 가장 먼저 마주하는 병목은 데이터가 이동하는 물리적 경로에 있다. 기존의 CPU 기반 모델 로딩 방식은 체크포인트 파일을 먼저 CPU 메모리로 스트리밍한 뒤, PCIe 버스를 통해 각 GPU에 가중치를 순차적으로 복사하는 구조를 가진다. Llama 3.1 405B처럼 BF16 기준 약 800GB에 달하는 거대 모델을 이 방식으로 로드하면 단일 스레드 기반의 순차 전송 한계로 인해 10분에서 20분이라는 시간이 소요된다. 체크포인트를 미리 쪼개어 두더라도 결국 CPU 메모리를 거쳐야 하는 특성상 수 분의 대기 시간은 피할 수 없다. 결과적으로 연산 성능이 가장 뛰어난 GPU 자원이 아무런 작업을 하지 못한 채 대기하는 유휴 시간이 길어지며, 이는 콜드 스타트 TTFT(첫 토큰 생성 시간)를 늦추는 결정적 원인이 된다.

NVIDIA GPUDirect Storage(GDS)는 이 데이터 흐름의 경로에서 CPU를 완전히 배제한다. Amazon FSx for Lustre(고성능 병렬 파일 시스템) 내에서 텐서 병렬 랭크별로 체크포인트를 미리 분할하는 샤딩(Sharding) 전략을 취하는 것이 핵심이다. 이렇게 분할된 가중치는 CPU와 시스템 메모리를 거치지 않고 8개의 GPU가 동시에 자신의 HBM(고대역폭 메모리)으로 직접 읽어 들이는 방식을 사용한다. 기존 방식이 CPU라는 좁은 통로를 통해 데이터를 순차적으로 밀어 넣었다면, GDS는 스토리지에서 GPU로 이어지는 다수의 직접 경로를 동시에 열어 데이터를 쏟아붓는 구조다. 이는 데이터 전송의 주도권을 CPU에서 스토리지와 GPU 간의 직접 통신으로 옮겨 전송 효율을 극대화한 설계의 변화다.

이러한 접근은 최근의 소프트웨어 레벨 최적화 시도와는 궤를 달리한다. vLLM 0.19 버전부터 기본으로 적용된 vLLM V1 엔진은 GPU 간 병렬 가중치 로딩을 도입해 이전 버전보다 로딩 시간을 상당히 단축했다. 하지만 vLLM의 개선 사항은 데이터를 처리하는 논리적 순서를 최적화한 것이며, 실제 데이터 패킷은 여전히 CPU 메모리와 PCIe 버스를 통과해야 하는 물리적 제약에 묶여 있다. 반면 GDS는 이러한 논리적 최적화를 넘어 데이터가 흐르는 물리적 통로 자체에서 CPU와 PCIe 구간을 완전히 제거한다. 인프라 설정 스크립트와 스토리지 아키텍처의 변경만으로 하드웨어 수준의 병목을 해결함으로써, 소프트웨어 최적화만으로는 도달할 수 없는 전송 속도를 확보한 것이다.

분 단위 대기 시간을 초 단위로 줄인 실무적 영향

수백 기가바이트에 달하는 모델 가중치를 GPU 메모리에 올리는 동안 발생하는 수 분의 공백을 어떻게 처리해야 하는가. Llama 3.1 405B 같은 거대 모델을 배포할 때 겪는 로딩 시간은 이제 분 단위에서 초 단위로 단축된다. 시간당 비용이 매우 높은 GPU 자원이 아무런 연산을 하지 않고 유휴 상태로 머무는 시간은 운영 관점에서 곧바로 매몰 비용으로 이어진다. 기존의 CPU 기반 로딩 방식이 가졌던 순차적 처리의 한계를 극복하고 로딩 시간을 초 단위로 줄이는 것은 단순한 개발 편의를 넘어 전체 인프라의 가동률과 경제성을 결정짓는 실무적 변수가 된다.

P5en 인스턴스는 141GB HBM3e를 탑재한 NVIDIA H200 GPU 8개를 제공하며, NVSwitch를 통해 3.6 TB/s의 비섹션 대역폭을 지원해 대규모 모델의 효율적인 서빙 환경을 구축한다. Llama 3.1 405B 모델은 FP8 정밀도 기준 약 400GB의 용량을 차지하므로 단일 GPU의 HBM 용량을 초과한다. 따라서 모델을 여러 GPU에 나누어 배치하는 텐서 병렬화(Tensor Parallelism)가 필수적으로 요구된다. 텐서 병렬화 기반의 샤딩 로딩 구조를 적용하면 8개의 GPU가 동시에 자신의 몫에 해당하는 가중치를 읽어 들여 메모리 적재 시간을 획기적으로 줄이며 GPU 가동률을 극대화한다.

이러한 최적화 패턴은 Llama 3.1뿐만 아니라 텐서 병렬 샤딩을 지원하는 모든 모델 아키텍처에 동일하게 적용할 수 있다. Mixtral이나 DeepSeek 같은 모델 역시 동일한 인프라 구조를 통해 로딩 병목을 해결하고 서빙 속도를 높이는 것이 가능하다. 여기에 최근 도입된 TurboQuant KV 캐시(Key-Value Cache)를 함께 적용하면 모델이 한 번에 처리할 수 있는 텍스트 양인 컨텍스트 윈도우 크기를 대폭 확장할 수 있다. 이는 긴 문서를 분석하거나 복잡한 대화를 유지해야 하는 실제 서비스 환경에서 응답성을 즉각적으로 개선하고 사용자 경험을 높이는 핵심 요소가 된다.

실무자가 주목해야 할 판단 기준은 인프라 설정 스크립트와 스토리지 아키텍처의 변경만으로 GPU의 유휴 시간을 완전히 제거할 수 있는가에 있다. CPU와 PCIe 버스를 거치지 않는 직접 경로를 구축함으로써 콜드 스타트 상황에서 발생하는 TTFT(Time to First Token, 첫 토큰 생성 시간)를 최적화하는 기준을 확보하게 된다. 고성능 인스턴스의 하드웨어 성능을 온전히 활용하기 위해 데이터 흐름의 물리적 병목을 제거하고, 모델 로딩이라는 지루한 대기 시간을 실제 서비스 가동 시간으로 전환하는 것이 이번 최적화가 가져오는 실질적인 영향이다. 결국 하드웨어의 물리적 한계를 소프트웨어와 네트워크 설정으로 우회해 추론 준비 시간을 최소화하는 최적화 경로를 찾는 것이 중요하다.

H200·B200 도입 기업의 GPU 비용 효율화 전략

P5en이나 P6 같은 고성능 인스턴스는 시간당 사용 비용이 매우 높게 책정되어 있다. 모델 가중치가 HBM(고대역폭 메모리)으로 완전히 로드되기 전까지 GPU는 어떤 연산도 수행하지 못한 채 대기 상태로 머문다. 이 유휴 시간은 단순한 대기가 아니라 그대로 매몰 비용이 된다. 전체 인프라 스택에서 가장 비싼 자원인 GPU를 점유하고 있으면서 실제 추론 서비스에는 투입하지 못하는 시간이 길어질수록, 기업이 지불하는 시간당 비용 대비 산출되는 토큰의 효율은 급격히 떨어진다.

대규모 모델을 서빙하는 한국 AI 기업들은 특히 모델 업데이트나 오토스케일링 상황에서 이 콜드 스타트 지연 문제를 직접적으로 겪는다. 트래픽 급증으로 인해 인스턴스를 자동으로 확장할 때, 새로운 노드가 프로비저닝되어 시스템상 '준비 완료' 상태가 되어도 실제 모델 로딩이 끝날 때까지는 첫 토큰 생성 시간(TTFT)이 비정상적으로 길어진다. 수천억 개의 파라미터를 가진 거대 모델일수록 로딩 시간이 수 분에서 수십 분까지 늘어나며, 이는 사용자 경험 저하와 동시에 불필요한 비용 지출이라는 이중고로 이어진다.

이러한 비용 낭비를 막기 위해 AWS는 aws-samples 저장소를 통해 인프라 프로비저닝과 GDS(GPUDirect Storage) 설정을 자동화하는 CloudFormation 템플릿을 제공한다. 이는 단순한 라이브러리 최적화를 넘어, 스토리지 아키텍처와 네트워크 인터페이스 설정을 근본적으로 변경하여 데이터 전송 경로를 재설계하는 작업이다. 제공되는 템플릿과 설정 스크립트를 적용하면 복잡한 GDS 환경 설정을 자동화하고 CPU를 완전히 우회하여 데이터를 전송하는 경로를 빠르게 구축할 수 있다.

결국 H200이나 B200 같은 초고가 가속기를 도입한 기업이 비용 효율을 극대화하는 판단 기준은 GPU의 순수 연산 성능보다 데이터 로딩 경로의 최적화 여부에 있다. 인프라 설정 스크립트와 스토리지 구조 변경만으로 GPU 유휴 시간을 제거함으로써 콜드 스타트 TTFT를 최적화하는 것이 실질적인 비용 절감의 핵심이다.

Llama 3.1 405B 같은 거대 모델을 배포할 때 겪는 지루한 로딩 시간은 더 이상 감수해야 할 상수가 아니다. Amazon FSx for Lustre와 NVIDIA GPUDirect Storage를 통해 CPU를 완전히 우회하고 모델 가중치를 HBM으로 직접 로드하는 경로가 증명됐기 때문이다. 특히 Persistent_2 EFA 파일시스템 기반의 94 GiB/s 처리량과 텐서 병렬화 샤딩 구조는 데이터 전송의 물리적 병목을 제거하는 구체적인 해법이 된다.

이제 관건은 인프라 설정 스크립트와 스토리지 아키텍처 변경만으로 GPU 유휴 시간을 없애 콜드 스타트 TTFT를 최적화하는 기준을 갖추는 일이다. LLM 인프라의 실질적 경쟁력은 단순한 연산 성능이 아니라 데이터가 GPU 메모리에 도달하는 경로의 효율성에서 결정된다.