최근 몇 주간 OpenAI의 gpt-oss와 Moonshot AI의 Kimi K2를 비롯한 새로운 오픈소스 모델들이 등장하면서 거대 언어 모델(LLM) 혁신이 가속되고 있습니다. 최근 공개된 Dynamo 0.4는 이러한 모델들을 대규모로, 그리고 저비용으로 배포할 수 있도록 지원하는 새로운 기능을 제공합니다. 이번 버전은 성능, 가시성, 서비스 수준 목표(SLO)에 기반한 오토스케일링에 중점을 두고 있습니다.
Dynamo 0.4의 주요 기능은 다음과 같습니다.
- NVIDIA Blackwell에서 분리형(disaggregation) 구조를 통한 4배 빠른 성능
- GB200 NVL72와 Hopper에서의 대규모 전문가 병렬 배포 가이드
- 분리형 환경 설정을 단순화하는 새로운 prefill-decode(PD) 설정 도구
- Kubernetes와 통합된 SLO 기반 PD 오토스케일링
- 실시간 성능 모니터링을 위한 내장 가시성 메트릭
- 인플라이트 요청 재라우팅과 조기 장애 감지를 통한 향상된 복원력
이번 글에서는 이러한 업데이트들을 자세히 살펴봅니다.
Dynamo 0.4가 분리형 구조를 통해 4배 더 빠른 추론 성능을 제공하는 방법
Dynamo 0.4는 NVIDIA Blackwell 환경에서 분리형 서빙 성능을 한층 강화했습니다. NVIDIA B200에서 Dynamo와 TensorRT-LLM을 활용해 OpenAI gpt-oss-120b 모델을 실행한 결과, 매우 긴 입력 시퀀스 길이에서도 사용자당 초당 토큰 수(tokens/second/user)가 최대 4배 더 빠른 상호작용 성능을 달성했습니다. 에이전틱 워크플로우, 코드 생성, 요약과 같은 활용 사례에서 특히 유용하게 활용될 수 있으며, 처리량 저하 없이 구현되었습니다.
또한 NVIDIA GB200 NVL72와 TensorRT-LLM, Dynamo를 사용해 DeepSeek-R1 671B 모델을 실행했을 때, GPU당 초당 토큰 수(tokens/second/GPU)가 2.5배 더 높은 처리량을 기록했습니다. 이 결과는 GPU당 초당 토큰 수가 2.5배 향상되었음에도 불구하고, 추론 비용이 추가로 발생하지 않았음을 보여줍니다.
이러한 성능 향상은 Dynamo의 분리형 서빙 덕분에 가능했습니다. 분리형 서빙은 모델 추론의 prefill 단계와 decode 단계를 별도의 GPU에서 분리하여 실행합니다. 단계를 분리함으로써 Dynamo는 각 단계의 요구 사항에 따라 GPU 자원과 모델 병렬화를 유연하게 할당할 수 있으며, 이를 통해 전체적인 효율성을 크게 높일 수 있습니다.
NVIDIA는 커뮤니티가 이러한 결과를 재현하고, 분리형 서빙 아키텍처의 비용 효율성을 최대한 활용할 수 있도록 지원하는 스크립트를 공개합니다. GitHub 링크는 아래에서 확인하실 수 있습니다.
- Dynamo와 TensorRT-LLM을 사용해 B200(8xGPU)에서 OpenAI gpt-oss-120b 배포
- Dynamo와 TensorRT-LLM을 사용해 GB200 NVL72(64xGPU)에서 DeepSeek-R1 671B 배포
또한 연구자, 엔지니어, 기관이 분리형 서빙을 통한 MoE 모델 서빙의 이점을 탐구할 수 있도록, DeepSeek-R1을 SGLang과 함께 설정하거나 Llama4 Maverick을 TensorRT-LLM과 함께 멀티 노드 환경에서 실행하는 방법을 단계별로 안내하는 포괄적인 배포 가이드도 제공합니다. GitHub 링크는 아래에서 확인하실 수 있습니다.
- Dynamo와 SGLang을 사용해 GB200 NVL72(56xGPU)에서 DeepSeek-R1 배포
- Dynamo와 SGLang을 사용해 H100(104xGPU)에서 DeepSeek-R1 배포
- Dynamo와 TRT-LLM을 사용해 GB200 NVL72(16xGPU)에서 Llama4 Maverick 배포
분리형 서빙 클러스터 설정에서 시행착오를 줄이는 방법
추론 팀들이 분리형 서빙을 도입할 때 가장 자주 직면하는 과제는 예상되는 처리량 향상을 정확히 가늠하기 어렵고, 각 배포 환경에 최적화된 구성을 찾기 힘들다는 점입니다. 구체적으로는 목표 SLO를 달성하기 위해 prefill과 decode 단계별 GPU 배정 수를 어떻게 정할지, 그리고 어떤 모델 병렬화 방식을 선택할지에서 어려움을 겪는 경우가 많습니다.
이 문제를 해결하기 위해 Dynamo 0.4에는 AIConfigurator라는 새로운 도구가 포함되었습니다. 이 도구는 주어진 모델과 GPU 예산을 기반으로, 목표 SLO를 충족할 수 있도록 최적의 prefill-decode 분리형 구성과 모델 병렬화 전략을 추천하도록 설계되었습니다.
AIConfigurator는 어텐션, FFN, 통신, 메모리 등 모델의 다양한 레이어별 성능 데이터를 미리 수집해두고 이를 적극적으로 활용합니다. 여기에 정적 배칭(static batching), 인플라이트 배칭(inflight batching), 분리형 서빙(disaggregated serving) 같은 여러 스케줄링 기법까지 함께 모델링하게 됩니다. 이 과정을 통해 주어진 SLO와 GPU 예산을 만족하면서도 GPU당 처리량을 극대화할 수 있는 최적의 prefill–decode 구성을 찾아내고 이렇게 도출된 결과는 Dynamo에 곧바로 적용할 수 있는 백엔드 설정으로 자동 변환됩니다.
AIConfigurator는 CLI와 웹 인터페이스 모두에서 제공되며, 초기 릴리스에서는 NVIDIA Hopper에서 TensorRT-LLM을 지원합니다. 향후 릴리스에서는 추가 추론 프레임워크와 NVIDIA 하드웨어도 지원될 예정입니다.
PU 과소 혹은 과다 할당 없이 추론 SLO를 일관되게 충족하는 방법
지난 5월 공개된 0.2 릴리스에서는 NVIDIA는 생성형 AI 추론과 prefill-decode 분리를 위해 특별히 설계된 GPU 오토스케일링 엔진인 Planner의 첫 번째 버전을 선보였습니다. Planner는 prefill 큐와 decode 메모리 사용량을 모니터링하여 추론 워커를 지능적으로 증감시킴으로써 GPU 활용도를 극대화하고 추론 비용을 최소화했습니다.
0.4 릴리스에서는 Planner를 한 단계 더 발전시켰습니다. 이제 SLO 기반 오토스케일링을 도입하여, 비용 최적화뿐 아니라 Time to First Token(TTFT), Inter-Token Latency(ITL)와 같은 엄격한 성능 목표를 안정적으로 충족할 수 있도록 했습니다.
기존의 반응형 스케일링 시스템과 달리, 새로운 SLO 기반 Planner는 선제적인 접근 방식을 취합니다.
- 배포 전 프로파일링을 통해 다양한 모델 병렬화 및 배칭 구성에서의 동작을 분석합니다.
- 사용자가 정의한 SLO에 맞춰 가장 비용 효율적인 엔진 구성을 제안합니다.
- ARIMA, Prophet과 같은 고급 시계열 모델을 활용해 향후 트래픽 패턴을 예측합니다.
- 예측된 수요에 따라 SLA 목표를 충족하는 데 필요한 최소한의 PD 워커 수를 계산합니다.
- 트래픽 패턴을 지속적으로 평가하고, 목표 SLA를 유지하기 위해 PD 워커를 동적으로 재조정합니다.
Planner의 차별화된 점은 입력 및 출력 시퀀스 길이 변화가 성능에 미치는 영향을 예측하고, 병목 현상이 발생하기 전에 자원을 선제적으로 확장할 수 있다는 것입니다.
SLO 기반 Planner를 통해 추론 팀은 다음과 같은 이점을 얻을 수 있습니다.
- 사용자 경험과 인프라 지출을 효과적으로 관리
- 자원의 과소 혹은 과다 할당 없이 SLA 성능 유지
- 수동 조정 없이 GPU 활용도 최적화
아래 데모 영상을 통해 Planner가 실제로 어떻게 작동하는지 확인해 보세요.
Planner는 Kubernetes와 기본적으로 통합되어 있어, 컨테이너 기반 인프라를 표준으로 사용하는 조직들이 Dynamo를 손쉽게 배포하고 Planner를 활용해 AI 워크로드를 확장할 수 있습니다. 이번 릴리스에는 vLLM에 대한 Planner 지원이 포함되어 있으며, 향후 업데이트에서는 추가 추론 프레임워크에 대한 지원도 제공될 예정입니다.
실시간 추론 가시성 메트릭 추적 방법
대규모 분산 추론 환경에서 가시성은 매우 중요합니다. 이를 통해 엔지니어링 팀은 시스템 상태를 모니터링하고, 성능 병목 현상을 진단하며, 지연 시간과 처리량·GPU 활용도를 실시간으로 최적화하여 엄격한 SLO를 충족할 수 있습니다.
이번 릴리스에서는 이벤트 플레인, 컨트롤 플레인, 데이터 플레인 전반에 걸쳐 Dynamo 워커와 컴포넌트가 주요 가시성 메트릭을 출력합니다. 주요 메트릭에는 다음이 포함됩니다.
- 초당 평균 요청 수와 요청 처리 시간
- 평균 최초 토큰 생성 시간(TTFT)과 토큰 간 지연 시간(ITL)
- 평균 입력 및 출력 시퀀스 길이
- GPU 활용도와 전력 사용량
이 메트릭은 오픈소스 Prometheus 툴킷을 통해 수집되며, 별도의 개발 작업 없이도 Grafana와 같은 오픈소스 모니터링·가시성 도구에서 손쉽게 활용할 수 있습니다.
또한 새롭게 제공되는 API를 통해 엔지니어링 팀과 솔루션 아키텍트는 자신들의 서빙 환경에 맞는 맞춤형 메트릭을 정의하고 출력할 수 있어, 유연성과 확장성이 한층 강화되었습니다.
Dynamo 0.4의 이러한 가시성 기반은 향후 릴리스에서 PD 분리형 서빙을 포함한 보다 세분화되고 활용 사례별로 특화된 메트릭을 도입하기 위한 토대를 마련합니다.
Dynamo 0.4의 복원력 강화와 조기 장애 감지
최전선 추론 MoE 모델을 대규모로 배포하려면 수백 개의 GPU에 걸친 멀티 노드 환경이 필요합니다. 이러한 환경에서는 소프트웨어나 하드웨어 구성 요소 중 어느 하나라도 잠깐이라도 장애가 발생하면 전체 시스템 운영이 중단되고, 그 결과 지연이나 사용자 요청 실패가 발생하여 비즈니스 운영을 방해하고 고객 경험에 부정적인 영향을 줄 수 있습니다.
Dynamo 0.4에는 인플라이트 요청 재라우팅(inflight request re-routing)을 비롯한 내결함성과 복원력 기능이 새롭게 추가되었습니다. 이전 버전에서는 요청이 오프라인 GPU로 전달되면 실패 처리되어 추론 스택 상위 계층이나 최종 사용자에게 반환되었습니다. 이때 토크나이제이션이나 임베딩 같은 전처리 단계가 반복 실행되면서 연산 자원이 낭비되고 지연 시간도 늘어났습니다. 이번 업데이트에서는 요청을 인플라이트 상태에서 재라우팅해 중간 계산 결과를 그대로 보존한 채 온라인 GPU로 직접 전달합니다. 이를 통해 불필요한 중복 작업을 없애고 응답 효율을 크게 높였습니다.
이번 업데이트에서는 장애를 더 신속하게 감지할 수 있는 기능이 도입되었습니다. 이전 버전에서는 Dynamo 컨트롤 플레인의 핵심 구성 요소인 etcd가 오프라인 워커를 감지하고 그 상태를 시스템 전반에 브로드캐스트하는 역할을 담당했습니다. 그러나 이 과정에서 몇 초간 지연이 발생해, 그 시간 동안에도 요청이 여전히 오프라인 워커로 전달될 수 있었습니다. 이번 릴리스에서는 Dynamo 스마트 라우터 내부에 조기 장애 감지 기능이 추가되어 etcd를 우회하고 중요한 상태 신호에 즉시 반응할 수 있습니다. 이를 통해 장애 감지부터 복구까지의 시간을 단축하고 실패 요청 발생을 크게 줄일 수 있습니다.
추론의 기본 이해: LLM에 질문했을 때 추론에서는 무슨 일이 일어날까요?
NVIDIA Dynamo의 분리형 서빙 개념을 다시 짚어보려면, 먼저 LLM에 질문했을 때 어떤 일이 일어나는지 살펴보는 것이 도움이 됩니다. 이는 추론(inference)이라 불리며, prefill부터 decode와 토큰 예측에 이르기까지의 전 과정을 포함합니다.
아래 영상에서는 이 과정이 구체적으로 어떻게 이루어지는지, 어떤 방식으로 발전하고 있는지, 그리고 NVIDIA Dynamo가 각 단계를 어떻게 가속화하는지를 설명합니다. 또한 분리형 서빙이 이러한 단계를 여러 GPU에 분산시켜 더 빠르고 효율적인 AI 응답을 가능하게 하는 방법도 확인하실 수 있습니다.
커뮤니티에 참여하기
Dynamo는 앞으로도 개발자 커뮤니티와 함께 발전을 이어갈 예정입니다. 지금까지 진행된 Office Hours 영상을 확인하고, 다가오는 Office Hours에 참여하여 팀으로부터 직접 답변을 받아보세요.
또한 Discord 커뮤니티에 참여해 다른 개발자들과 교류하고, 피드백을 공유하며, 실시간으로 지원을 받아보실 수 있습니다. 앞으로의 로드맵에 기대가 되신다면 오픈소스 리포지토리를 방문해 보세요. 여러분의 기여와 제안, 그리고 새로운 아이디어를 환영합니다.
