Operating Distributed Inference Systems at Scale — Nishant Gupta & Naman Ahuja, Meta

한 줄 핵심

대규모 inference 운영의 핵심은 모델 자체보다 라우팅·스케줄링·캐싱·리라이팅을 포함한 오케스트레이션과 컨트롤 플레인 설계에 있으며, 이를 제대로 못 하면 비용·지연·장애가 모두 악화된다.

시간별 요약

1. 0:00
   Inference는 Meta가 본 가장 빠르게 성장하는 워크로드 Inference는 더 이상 연구용 산출물이 아니라 하이퍼스케일 인프라의 핵심 워크로드가 되었고, Meta에서 가장 빠른 성장률을 보인다. 이 영상은 분산 inference 시스템을 대규모로 운영하는 방법을 다룬다.
2. 0:54
   가치가 오케스트레이션 계층으로 이동한 2008년의 반복 클라우드 시대에 가치가 VM에서 스케줄러·서비스 메시·오토스케일러로 이동했듯, AI도 동일한 경로를 압축적으로 따라가고 있다. 에이전트형 워크로드는 사용자 수만이 아니라 호출 수와 토큰 수에 따라 규모가 커지므로, 기존 마이크로서비스식 용량 계획이 아니라 탄력성과 워크로드 인지형 스케줄링이 필요하다.
3. 3:13
   마이크로서비스와 inference의 차이 inference 요청은 50 tokens부터 100,000 tokens까지 폭이 넓고 prefill과 decode의 계산 특성도 크게 달라 연속 배치가 필수다. 또한 KV cache 같은 요청별 상태, GPU 중심 자원, 느린 cold start, 중간 실패 시 대량 토큰 손실 같은 특성 때문에 병목은 모델보다 오케스트레이션에 더 자주 생긴다.
4. 6:09
   낡은 계층, 새로운 결합 라우팅, 캐시 히트율, 배치 구성, GPU 활용률, 오토스케일링은 서로 강하게 얽혀 있어 한 계층의 결정이 다른 계층의 성능을 연쇄적으로 바꾼다. 요청은 gateway, router, cache lookup, scheduler, serving runtime을 거치며, 여러 단계가 결합된 전체 경로를 보지 않으면 병목 원인을 잘못 짚기 쉽다.
5. 7:36
   요청은 분산 트랜잭션이다 inference 요청의 각 홉은 재시도·타임아웃·폴백·실패가 모두 가능하므로, 일반 RPC보다 부분 실패 처리와 복구가 훨씬 어렵다. 이미 일부 토큰을 스트리밍한 뒤 GPU 호스트가 프리엠프트되는 상황까지 고려하면, 신뢰성은 엣지가 아니라 전체 워크플로를 보는 control plane의 속성이어야 한다.
6. 8:31
   스케줄러가 봐야 하는 일곱 가지 축 inference 스케줄러는 GPU 타입, HBM 여유분, KV cache 상태, 모델 weight 로드 여부, 테넌트 우선순위, 워크플로 컨텍스트, latency budget을 함께 고려해야 한다. 특히 요청이 워크플로의 몇 단계인지와 이미 투입한 비용이 얼마인지 알아야, 실패 시 전체 낭비를 줄이는 agentic-aware scheduling이 가능하다.
7. 10:19
   작업을 피하고, 공유하고, 옮기고, 미루기 최적화는 캐싱으로 작업을 피하기, batching으로 작업을 공유하기, routing으로 더 싸거나 더 가까운 곳으로 옮기기, admission control과 queueing으로 미루기로 정리할 수 있다. 무엇보다 비용은 token당이 아니라 성공한 task당으로 봐야 하며, 사용자 가치에 맞는 KPI를 기준으로 최적화해야 한다.
8. 12:36
   KV cache가 있는 연쇄 장애 GPU 저하가 지연 증가를 부르고, 그 지연이 재시도를 늘리며, 큐가 쌓여 더 많은 GPU를 포화시키는 전형적 연쇄 장애가 발생할 수 있다. 여기에 KV cache warm-up 제약이 더해지면 단순 재시작이나 재라우팅이 통하지 않으므로, circuit breaker, admission control, load shedding, retry budget 같은 차단 장치가 필요하다.
9. 16:19
   지연 시간, 비용, 처리량의 삼각형 배치 크기, speculative decoding, 더 작은 모델 사용은 각각 throughput, latency, cost에 서로 다른 영향을 주며 세 가지를 동시에 최적화할 수는 없다. 모든 서빙 결정은 이 삼각형 안에서 시스템을 이동시키므로, 목표에 맞는 균형점을 찾는 최적화 문제로 봐야 한다.
10. 17:00
    Inference에는 자체 control plane이 필요하다 routing, batching, caching, scheduling, reliability는 분리된 개별 설정이 아니라 하나의 inference control plane으로 수렴하고 있다. 앞으로의 핵심은 GPU, KV cache, token, latency, cost를 자원처럼 스케줄링하고, 수동 운영보다 자동 제어 루프로 시스템을 적응시키는 것이다.

실무 인사이트

• inference 비용 최적화는 GPU 사용률이 아니라 성공한 task당 비용을 기준으로 다시 정의해야 한다.
• 장애 대응은 개별 서버 복구보다 routing·admission control·retry budget을 묶은 control plane 설계로 접근해야 한다.
• 워크로드가 복잡해질수록 캐싱, 배치, 라우팅, 지연 허용을 하나의 운영 정책으로 통합해야 성능과 안정성을 함께 지킬 수 있다.