메타가 유휴 GPU를 광고 추천에 재활용하는 방법 RMA·SBM 탄력성 설계

추론 플릿의 역설: 전체는 부족한데, 구석구석은 논다

AI 추론 플릿을 운영해 본 분이라면 공감할 거예요. 전체 캐파시티는 빠듯한데, 특정 리전·특정 가속기·특정 시간대에는 유휴 자원이 남아도는 상황 말이죠. 메타도 같은 문제를 겪었고, 이걸 그냥 놀리지 않고 광고 추천 품질을 끌어올리는 데 재활용하는 시스템을 만들었습니다.

유휴 캐파시티가 생기는 대표적 원인은 네 가지예요.

• 피크 프로비저닝 vs 트래픽 변동: 피크 기준으로 캐파시티를 잡기 때문에 비피크 시간엔 논다.
• 모델 개발과 캐파시티 공급의 시차: 하드웨어는 공급망 일정대로 오는데, 모델은 따로 개발되니까 소비 시점이 안 맞는다.
• 리전별 자원 비율 불일치: GPU는 있는데 CPU가 부족해서, 혹은 그 반대라서 생기는 병목.
• 가속기 종류 불일치: 벤더·세대·아키텍처가 달라 워크로드가 이식되지 않아 방치되는 하드웨어.

이 글의 핵심은 "이 파편화된 유휴 자원을 어떻게 안전하게 끌어다 쓰는가"입니다. 관련해서 AI 에이전트의 일관성 함정을 다룬 Pass^k 가이드도 함께 보시면, 왜 "가끔 잘 되는" 시스템이 위험한지 감이 오실 거예요.

두 개의 탄력성 레버: RMA와 SBM

메타가 선택한 워크로드는 두 가지 구조적 특성을 만족해야 합니다. 높은 탄력성(옵셔널 작업을 빠르게 늘리고 줄일 수 있음), 스케일에서의 품질 유지, 그리고 낮은 교차 서비스 의존성이죠. 이 조건을 만족하는 레버가 두 개 있습니다.

RMA (Rank More Ads)

랭킹 단계에서 평가하는 후보 광고 수를 늘리는 레버입니다. 후보가 많아지면 사용자에게 맞는 광고를 찾을 확률이 올라가죠. 다만 후보가 늘면 CPU를 많이 쓰는 업스트림(리트리벌, 피처 처리)과 가속기 추론을 둘 다 소비합니다.

# RMA 개념 의사코드: 유휴 캐파시티에 따라 후보 수를 조절
class RMAController:
    def __init__(self, base_candidates: int, max_candidates: int):
        self.base = base_candidates
        self.max = max_candidates
        self.target = base_candidates

    def update(self, p99_latency_ms: float, sla_ms: float, available_ratio: float):
        # 지연이 SLA보다 여유 있으면 후보를 늘리고, 아니면 줄인다
        if p99_latency_ms < sla_ms * 0.9 and available_ratio > 0.3:
            self.target = min(self.max, int(self.target * 1.1))
        elif p99_latency_ms > sla_ms * 0.95:
            self.target = max(self.base, int(self.target * 0.9))
        return self.target

SBM (Serve Better Models)

더 강력한 모델로 라우팅되는 요청 비율을 조절하는 레버입니다. 랭킹에 들어가는 광고 수는 그대로 두기 때문에 업스트림 CPU 부담은 거의 늘지 않고, 가속기 잉여분만 소비할 수 있습니다. RMA가 못 쓰는 자원을 SBM이 쓰는 구조인 거죠.

# SBM 라우터 개념: 요청 가치 세그먼트별로 강한 모델 커버리지를 조절
class SBMRouter:
    def __init__(self, target_coverage: float):
        self.target_coverage = target_coverage

    def route(self, request, segment_value: float, current_coverage: float) -> str:
        # 목표 커버리지보다 현재 커버리지가 낮으면 가치 높은 요청부터 강한 모델로
        if current_coverage < self.target_coverage and segment_value > 0.7:
            return "powerful_model"
        return "baseline_model"

두 레버를 같이 쓰는 이유는 소비하는 자원 조합이 다르기 때문입니다. RMA는 CPU+가속기, SBM은 가속기 위주. 그래서 유휴 자원의 구성에 따라 유연하게 배분 비중을 조정합니다.

안전하게 쓰는 법: 격리, 피드백 루프, 로드 셰딩

유휴 캐파시티의 가장 큰 리스크는 예고 없이 회수될 수 있다는 점입니다. 메타의 설계 원칙은 명확해요. "유휴 캐파시티를 잃으면 옵셔널 작업이 줄어들 뿐, 베이스라인 서빙 캐파시티를 절대 압박해서는 안 된다."

1) 물리적/논리적 격리

• SBM은 물리적 격리: 베이스라인 모델과 강한 모델이 별도 라우팅 타깃을 사용합니다. 유휴 캐파시티가 줄면 강한 모델로 가는 요청 비율만 낮추면 되고, 그 요청은 이미 프로비저닝된 베이스라인 모델로 흘러갑니다.
• RMA는 논리적 격리: 모델 레플리카가 베이스라인과 추가 작업을 섞어 받되, 전역 예산으로 총 증분 작업량을 제한합니다. 격리는 물리적 분리가 아니라 "예산 상한"으로 달성하는 거죠.

2) 워크로드별 피드백 루프

• RMA: 중앙 PID 컨트롤러가 테일 레이턴시를 보고 랭킹에 보낼 광고 수 목표를 계산하고, 클라이언트가 이를 적용합니다.
• SBM: 중앙 컨트롤러가 강한 모델 커버리지 목표를 설정하고, 클라이언트 라우터가 세그먼트별 explore-and-exploit으로 실제 증분 효과를 측정해 배분을 갱신합니다. 절대적 요청 가치와 증분 효과가 항상 일치하지 않기 때문에 이 과정이 필수입니다.

3) 다층 로드 셰딩

중앙 컨트롤러는 분 단위로 동작하는데, 선점(preemption)은 밀리초 단위로 일어납니다. 그래서 두 단계의 즉각 대응이 있습니다.

• 서버 측 셰딩: 유휴 풀이 줄면 서버가 즉시 저가치 옵셔널 작업을 제거합니다.
• 클라이언트 측 셰딩: 클라이언트가 서버 상태를 직접 관찰해 과부하 징후가 보이면 스스로 옵셔널 작업을 줄입니다.

두 셰딩 모두 가치 신호를 기준으로 제거 대상을 고르기 때문에 전환 구간의 품질 손실이 최소화됩니다.

주의사항과 한계

• 워크로드 적합성: 이 패턴은 "옵셔널 작업을 늘려도 품질이 계속 오르는" 워크로드에만 통합니다. 옵셔널 작업이 선형으로 품질을 올리지 않는 시스템엔 과투자입니다.
• 컨트롤 루프 지연: 중앙 제어가 분 단위라 급격한 회수에는 로컬 셰딩이 필수입니다. 셰딩 정책이 없으면 베이스라인 SLA가 깨질 수 있어요.
• 측정 복잡도: SBM의 explore-and-exploit은 지속적인 실험 트래픽을 요구합니다. 실험 인프라가 없는 조직은 이 부분이 병목이 됩니다.

실무 적용을 위한 정리

메타의 사례에서 가져갈 핵심은 세 가지입니다.

1. **유휴 자원은 "버리는 비용"이 아니라 "옵셔널 작업의 연료"**입니다. 단, 옵셔널 작업의 품질 곡선이 우상향인 워크로드를 골라야 합니다.
2. 격리 전략을 먼저 정하세요. 물리적 분리가 가능한 워크로드(SBM형)와 예산 상한으로 격리해야 하는 워크로드(RMA형)를 구분하는 것이 설계의 출발점입니다.
3. 중앙 제어와 로컬 셰딩을 반드시 이중화하세요. 선점은 컨트롤러보다 빠릅니다.

국내 환경에서는 특히 멀티 클라우드/온프레미스 혼합 인프라에서 이 패턴이 유효합니다. 리전별 GPU 세대가 섞여 있는 경우, SBM처럼 "가속기만 추가로 쓰는" 레버가 RMA보다 안전하게 시작할 수 있는 선택지예요. 다만 국내 SI 프로젝트에서는 실험 인프라(explore-and-exploit용 트래픽 분할)가 부족한 경우가 많으니, SBM 도입 전에 A/B 인프라부터 점검하시길 권합니다.

다음 단계로는 precomputation elasticity(요청 시점 이전에 미리 계산해두는 방식)를 살펴보세요. 실시간 트래픽 위치·타이밍 제약에서 상대적으로 자유롭기 때문에, 배치성 워크로드가 많은 조직에 더 현실적인 첫걸음이 될 수 있습니다.

근거자료: Meta Engineering - Turning opportunistic AI inference capacity into better ads recommendations

함께 보면 좋은 글

• 메타가 AV1을 RTC에 도입한 이유와 3년간의 삽질기
• AI 에이전트가 어제는 되던 일이 오늘 안 되는 이유, Pass^k로 보는 일관성 함정