cuda

KernelEvolve: 메타의 랭킹 엔지니어 에이전트가 AI 인프라를 최적화하는 방법 (새 탭에서 열림)

Meta는 하드웨어와 모델 아키텍처의 급격한 다양화로 인해 발생하는 커널 최적화 병목 현상을 해결하기 위해 에이전트 기반 시스템인 'KernelEvolve'를 도입했습니다. KernelEvolve는 숙련된 엔지니어가 수주간 작업해야 했던 커널 튜닝 및 최적화 과정을 단 몇 시간 만의 자동화된 탐색으로 단축하며, NVIDIA GPU부터 자체 칩인 MTIA에 이르기까지 다양한 이기종 하드웨어에서 성능을 극대화합니다. 이를 통해 Meta는 수조 건의 일일 추론 요청을 효율적으로 처리하고 복잡한 ML 모델 혁신 속도를 가속화하고 있습니다. **폭발적인 커널 요구량과 수동 최적화의 한계** * **복잡도의 증가:** 최적화가 필요한 커널의 수는 {하드웨어 종류 및 세대 × 모델 아키텍처 × 연산자 수}의 곱에 비례하여 기하급수적으로 증가하며, 수천 개의 고유 구성을 생성합니다. * **하드웨어 이질성:** NVIDIA 및 AMD GPU, Meta 자체 칩인 MTIA는 각기 다른 메모리 계층, 명령어 집합, 실행 모델을 가집니다. 특정 플랫폼에 최적화된 커널이 다른 플랫폼에서는 성능이 저하되거나 작동하지 않는 문제가 발생합니다. * **모델 아키텍처의 진화:** 초기 임베딩 중심 모델에서 시퀀스 학습 및 어텐션 기반 모델을 거쳐, 최신 생성형 광고 추천 모델(GEM)과 대규모 추론 모델에 이르기까지 연산자의 유형이 끊임없이 변화하고 있습니다. * **확장성 부족:** 전문가에 의존하는 수동 튜닝 방식은 하드웨어와 모델의 빠른 진화 속도를 따라잡지 못해 모델 배포를 늦추는 결정적인 병목 구간이 됩니다. **KernelEvolve: 에이전트 기반 커널 저작 시스템** * **탐색 중심의 최적화:** 단순한 일회성 코드 생성이 아니라, 커널 최적화를 '탐색 문제'로 정의하여 수백 개의 대안 구현을 시도하고 최적의 솔루션을 식별합니다. * **피드백 루프 아키텍처:** LLM이 생성한 커널 후보를 전용 작업 하네스(Job-harness)에서 평가하고, 실행 결과 및 진단 정보를 다시 LLM에 피드백하여 지속적으로 개선하는 구조를 갖췄습니다. * **광범위한 언어 및 하드웨어 지원:** Triton, Cute DSL, FlyDSL과 같은 고수준 DSL은 물론 CUDA, HIP, MTIA C++ 등 저수준 언어까지 생성할 수 있어 공개 및 독점 하드웨어를 모두 지원합니다. **성능 혁신 및 실질적 도입 성과** * **처리량(Throughput) 대폭 향상:** NVIDIA GPU 기반 Andromeda 광고 모델의 추론 처리량을 60% 이상 개선했으며, Meta 자체 MTIA 칩 환경에서도 광고 모델 학습 처리량을 25% 이상 높였습니다. * **개발 주기 단축:** 프로파일링, 최적화, 교차 하드웨어 디버깅 등 수주가 소요되던 전문가의 엔지니어링 작업을 단 몇 시간의 자동 탐색으로 대체했습니다. * **실제 서비스 적용:** KernelEvolve가 최적화한 코드는 현재 Meta의 프로덕션 환경에서 매일 수조 건의 추론 요청을 처리하는 데 사용되고 있습니다. KernelEvolve는 커널 개발을 수동 프로세스에서 자동화된 적응형 시스템으로 전환함으로써 소프트웨어와 하드웨어 간의 결합 방식을 근본적으로 바꾸고 있습니다. 하드웨어 포트폴리오가 다양해질수록 이러한 에이전트 기반 인프라 최적화는 새로운 칩을 통합하는 데 필요한 엔지니어링 노력을 획기적으로 줄여줄 것입니다.

투 타워를 넘어서: 차 (새 탭에서 열림)

전통적인 추천 시스템의 표준인 'Two-Tower' 모델은 효율적이지만, 사용자-아이템 간의 복잡한 상호작용 특징(Interaction features)을 반영하지 못하는 구조적 한계가 있습니다. 이를 해결하기 위해 핀터레스트는 범용 신경망 기반의 복잡한 랭킹 모델을 도입하기로 결정하고, 이를 지원하기 위한 GPU 기반의 서빙 스택 재설계를 단행했습니다. 데이터 전송 병목 현상을 해결하고 비즈니스 로직을 모델 내부에 통합함으로써, 초기 4,000ms에 달하던 지연 시간을 실시간 서비스 가능한 수준인 20ms까지 단축하는 데 성공했습니다. ### Two-Tower 모델의 한계와 새로운 도전 * **표현력의 제약:** Two-Tower 구조는 사용자(User)와 아이템(Item)을 각각 독립적인 벡터로 인코딩한 뒤 마지막에 내적(Dot product)만 수행하므로, 네트워크 깊은 곳에서 두 피처가 결합되는 '교차 피처(Cross-features)'나 '타겟 어텐션(Target attention)'을 활용하기 어렵습니다. * **복잡한 모델 도입의 필요성:** 보다 정교한 추천을 위해 피처 간의 직접적인 상호작용을 모델링할 수 있는 일반적인 딥러닝 아키텍처 도입이 필요해졌습니다. * **서빙 인프라의 한계:** 기존 인프라는 단순한 연산(내적 또는 ANN 검색)에 특화되어 있어, 무거운 GPU 추론 단계를 지연 시간 손실 없이 통합하는 것이 핵심 과제였습니다. ### 인벤토리 세분화를 통한 피처 패칭(Feature Fetching) 최적화 * **데이터 전송 병목:** 수만 개의 후보군에 대해 네트워크를 통해 피처를 가져오는 I/O 작업이 모델 추론보다 더 긴 시간을 소모하는 문제가 발생했습니다. * **고가치 인벤토리(Segment 1):** 매출 기여도가 높은 약 100만 개의 문서는 피처를 PyTorch 모델 파일 내의 'Registered Buffer' 형태로 직접 삽입했습니다. 이를 통해 모델 가중치처럼 GPU의 고대역폭 메모리(HBM)에 피처가 상주하게 되어 네트워크 오버헤드를 완전히 제거했습니다. * **롱테일 인벤토리(Segment 2):** 나머지 10억 개 이상의 문서는 고성능 Key-Value 저장소와 인-호스트 캐시를 조합하여 피처를 가져오도록 이원화했습니다. ### 비즈니스 로직의 모델 내부 통합 * **데이터 전송량 최소화:** 기존에는 GPU에서 계산된 수만 개의 점수를 모두 CPU로 보낸 뒤 필터링했으나, 이는 Device-to-Host(D2H) 전송 병목을 야기했습니다. * **로직 내재화:** 유틸리티 계산(pCTR, pCVR, 입찰가 조합 등), 다양성 규칙, Top-K 정렬 등의 비즈니스 로직을 PyTorch 텐서 연산으로 구현하여 모델 내부에 포함시켰습니다. * **병렬 처리 이점:** 복잡한 필터링과 정렬을 GPU의 대규모 병렬 연산으로 처리함으로써 CPU 기반 처리보다 속도를 높였고, 최종 결과값(약 1,000개)만 출력하여 전송 효율을 극대화했습니다. ### GPU 추론 가속화 및 시스템 최적화 * **멀티 스트림 CUDA:** 단일 스트림 방식에서 벗어나 여러 CUDA 스트림을 사용하여 데이터 전송(H2D, D2H)과 연산(Compute)이 서로 겹쳐서 수행(Overlap)되도록 설계했습니다. * **커널 퓨전(Kernel Fusion):** Triton 커널을 사용하여 선형 레이어와 활성화 함수 같은 반복적인 레이어 패턴을 하나로 합침으로써 메모리 대역폭 압박을 완화했습니다. * **수치 형식 최적화:** FP32 대신 BF16(Brain Floating Point 16) 형식을 채택하여 메모리 사용량을 줄이고 연산 속도를 높였습니다. * **워커 정렬:** 호스트 CPU 코어 수에 맞춰 워커 스레드 수를 조정하고 고정(Pinning)하여 컨텍스트 스위칭과 락 경합을 최소화했습니다. 이러한 재설계는 고성능 추천 시스템을 구축할 때 모델 아키텍처뿐만 아니라, 데이터 흐름과 하드웨어 가속기(GPU)의 특성을 고려한 인프라 최적화가 필수적임을 보여줍니다. 특히 대규모 트래픽 환경에서 GPU를 효율적으로 활용하려면 비즈니스 로직을 포함한 전체 서빙 파이프라인을 모델과 밀접하게 통합하는 전략이 유효합니다.