NVIDIA는 한국의 주요 오픈 모델인 SK텔레콤의 A.X K2, LG AI연구원의 K-EXAONE 2.0, 업스테이지의 Solar Open 2, Motif Technologies의 Motif-3를 위한 Dynamo 최적화 배포 레시피를 공개합니다. NVIDIA B200 GPU에 최적화된 이 레시피는 개발자가 모델을 더 빠르게 실제 서비스에 적용할 수 있도록 지원합니다.
한국은 자체 개발 파운데이션 모델과 인프라, 애플리케이션에 대한 투자를 통해 소버린 AI를 발전시키고 있습니다. NVIDIA는 한국의 ‘모두의 AI(AI for All)’ 이니셔티브를 통해 주요 한국 모델 개발사와 협력하며 추론을 최적화하고 확장하고 있습니다. 모델을 효율적으로 배포할 수 있게 하는 것은 이러한 투자를 누구나 이용할 수 있는 AI 서비스로 연결하는 데 도움이 됩니다.
모델 규모가 단일 GPU의 용량을 넘어서면, 서빙을 위해 여러 GPU에 연산과 메모리를 분산해야 합니다. 이때 성능을 유지하려면 요청 라우팅과 GPU 간 통신, 추론 실행을 세밀하게 조율해야 합니다.
NVIDIA Dynamo는 여러 GPU와 노드에 걸쳐 데이터센터 규모로 모델을 배포하기 위한 오픈소스 분산 추론 서빙 프레임워크입니다. 요청 라우팅과 데이터 이동을 조율해 애플리케이션의 지연 시간 목표를 충족하면서 GPU 자원을 효율적으로 활용합니다.
새로운 레시피는 Dynamo에 NVFP4 체크포인트와 vLLM, 모델별 최적화를 결합해 배포 과정의 시행착오를 줄입니다. 이 글에서는 각 모델을 어떻게 최적화했는지, 모델 아키텍처의 차이가 최적화 선택에 어떤 영향을 주었는지, 그리고 어떻게 시작할 수 있는지 설명합니다.
새로운 Dynamo 레시피에는 무엇이 포함되어 있나요?
레시피는 연산량과 메모리, 문맥 처리 요구사항이 서로 다른 네 가지 전문가 혼합(Mixture-of-Experts, MoE) 모델을 지원합니다.
| 모델 | 개발사 | 전체 / 활성 파라미터 | 지원 문맥 길이 |
|---|---|---|---|
| A.X K2 | SK Telecom | 688B / 33B | 256K 토큰 |
| K-EXAONE 2.0 | LG AI Research | 750B / 37B | 256K 토큰 |
| Solar Open 2 | Upstage | 250B / 15B | 1M 토큰 |
| Motif-3 | Motif Technologies | 314B / 13.2B | 256K 토큰 |
각 레시피는 체크포인트와 런타임 이미지, 병렬화 전략, 캐시 구성, 실행 설정을 명시합니다. Kubernetes 배포 매니페스트와 모델 다운로드 작업, 스모크 테스트, 벤치마크 절차를 제공하므로 개발자는 구성을 재현하고 실제 애플리케이션 트래픽으로 평가할 수 있습니다.
레시피는 aggregated와 disaggregated 서빙을 다룹니다. aggregated 구성은 프롬프트를 처리하는 prefill과 토큰을 생성하는 decode를 같은 워커에서 실행합니다. disaggregated 구성은 두 단계를 각각 별도 워커에 배치하고 추론 상태를 워커 간에 전달합니다.
이러한 구성은 배포의 출발점이 되며, 워크로드 요구사항이 달라질 때 GPU 자원 배분을 탐색하는 데에도 활용할 수 있습니다.
모델별 최적화 자세히 살펴보기
MoE 모델은 토큰마다 일부 파라미터만 활성화하므로 모든 파라미터를 사용하는 모델보다 연산량을 줄일 수 있습니다. 다만 서빙 과정에서는 여전히 모델 가중치를 적재하고, 문맥을 유지하며, GPU 간에 통신해야 합니다.
어텐션 아키텍처도 영향을 줍니다. 모델에 따라 KV 표현을 압축하거나, 전역 어텐션과 슬라이딩 윈도 어텐션을 결합하거나, 어텐션 KV 캐시와 선형 어텐션 상태를 함께 유지합니다. 이러한 차이는 메모리 용량과 캐시 재사용, 워커 간에 전달해야 하는 상태에 영향을 미칩니다.
이번에는 모델 실행과 요청 서빙을 함께 최적화했습니다. NVFP4 가중치는 모델의 메모리 요구량을 줄이고, FP8 KV 캐시는 생성 중 문맥을 유지하는 데 필요한 메모리를 줄입니다.
NVIDIA Dynamo는 여러 GPU와 노드에 걸친 추론을 조율합니다. 이번 레시피에서 모델 실행은 vLLM이 담당하고, Dynamo는 요청 배치와 분리된 prefill·decode 워커를 조율합니다.
특히 다음 두 가지 기능이 유용합니다.
KV-aware 라우팅은 재사용 가능한 프롬프트 접두부(prefix)와 워커 부하를 함께 고려합니다. 관련 문맥을 이미 보유한 워커에 요청을 보내면 반복되는 prefill 연산을 줄일 수 있습니다.
disaggregated 서빙은 prefill과 decode를 독립적으로 확장할 수 있게 합니다. NVIDIA Inference Xfer Library(NIXL)가 워커 간 KV 캐시를 전달하므로 각 단계에 적합한 구성을 사용할 수 있습니다.
| 모델 | aggregated 구성 | disaggregated 구성 | 주요 최적화 |
| A.X K2 | TP4 워커 2개 (GPU 8대) | TP4 prefill 워커 2개 + TP4 decode 워커 1개 (GPU 12대) | Sparse MLA, KV-aware 라우팅, EAGLE3 |
| K-EXAONE 2.0 | TP4 워커 1개 (GPU 4대) | TP4 prefill 워커 1개 + TP4 decode 워커 1개 (GPU 8대) | MTP, 검증된 MoE 커널 |
| Solar Open 2 | TP2 워커 2개 (GPU 4대) | TP4 prefill 워커 1개 + TP2 decode 워커 2개 (GPU 8대) | Prefix 캐싱, 하이브리드 상태 전송 |
| Motif 3 | Expert parallelism을 적용한 TP2 워커 1개 (GPU 2대) | TP2 prefill 워커 3개 + TP2 decode 워커 1개 (GPU 8대) | 모델 전용 런타임, 자체 speculative decoding |
A.X K2의 병렬화와 EAGLE3
A.X K2는 전체 688B 파라미터 중 토큰당 33B를 활성화하는 MoE 모델입니다. 256개의 routed expert 중 8개를 선택하고 shared expert도 사용합니다. Sparse Gated Attention은 Multi-head Latent Attention(MLA)을 기반으로 긴 문맥 처리에 사용할 KV 후보를 선택하며, 최대 256K 토큰의 문맥을 지원합니다.
레시피는 skt/A.X-K2-NVFP4와 전용 draft 모델인 skt/A.X-K2-EAGLE3를 함께 사용합니다. Routed expert는 NVFP4 W4A4, 어텐션·라우터·shared expert·dense layer는 FP8, 임베딩과 LM head는 BF16을 사용합니다. KV 캐시는 FP8입니다. 이러한 혼합 정밀도 구성으로 대규모 가중치의 메모리 사용량을 줄입니다.
Sparse MLA는 FLASHINFER_MLA_SPARSE를 통해 실행됩니다. aggregated 프로파일은 B200 GPU 8대에 TP4 워커 두 개를 배치하고 KV-aware 라우팅을 사용합니다. EAGLE3는 각 단계에서 후보 토큰 세 개를 제안하며, 처리량 개선 폭은 실제 요청에서 수락되는 길이에 따라 달라집니다.
배포 파일의 실행 설정 연결하기
다음은 aggregated deploy.yaml에서 발췌한 구간입니다. 공통 상위 들여쓰기만 제거했습니다. 생략된 공통 설정을 포함한 전체 배포에는 원본 매니페스트를 사용하세요.
워커 실행 인자는 TP4와 sparse MLA, FP8 KV 캐시를 선택합니다. SPECULATIVE_CONFIG 환경변수는 ConfigMap의 speculative-config 키를 읽어 –speculative-config로 전달합니다. 기본 배포에서는 실제 EAGLE3 수락 동작을 사용하며, synthetic 벤치마크 구성은 별도 키를 사용합니다.
disaggregated 프로파일은 TP4 prefill 워커 두 개와 TP4 decode 워커 한 개를 사용하며, InfiniBand 기반 NIXL/UCX로 KV 캐시를 전송합니다. aggregated 구성은 B200 GPU 8대, disaggregated 구성은 12대를 사용하므로 목표 사용자 생성 속도와 GPU당 처리량을 함께 평가해야 합니다. A.X K2 레시피
실무에서는 메모리 적재 가능 여부와 통신 비용, speculative decoding의 수락률을 함께 평가해야 합니다. GPU 메모리에 모델을 적재하는 것은 출발점입니다. 서빙 구성을 선택하기 전에 실제 요청으로 EAGLE3의 효과를 측정하세요.
K-EXAONE 2.0의 MTP와 MoE 백엔드 선택
K-EXAONE 2.0은 전체 750B급, 토큰당 활성 37B 파라미터를 갖춘 MoE 모델입니다. 전역 어텐션과 슬라이딩 윈도 어텐션을 결합하며 최대 256K 토큰의 문맥을 지원합니다. 레시피는 LGAI-EXAONE/K-EXAONE-2.0-750B-A37B-NVFP4와 FP8 KV 캐시를 사용합니다. 내장 Multi-Token Prediction(MTP)을 draft length 2로 실행해 여러 후보 토큰을 함께 검증합니다.
권장 aggregated 프로파일은 B200 GPU 4대에서 TP4를 사용합니다. 약 530GB의 가중치는 TP2에 적재되지 않으며, 레시피 테스트에서는 TP8의 추가 통신으로 GPU당 효율이 낮아졌습니다. TP4는 모델을 적재하면서 통신 비용을 제어하는 운영점을 제공합니다. Draft length 2의 MTP는 토큰 생성 경로를 추가로 조정합니다.
MoE 백엔드는 FLASHINFER_CUTLASS로 고정합니다. 레시피에는 이 체크포인트에서 자동 선택 기능이 FLASHINFER_TRTLLM을 선택할 경우 장문 생성의 정확성 문제가 발생한다고 명시되어 있습니다. 따라서 백엔드 고정은 실행 구성을 정의하는 동시에 출력 정확성을 유지하기 위한 조치입니다.
배포 파일의 MTP와 커널 설정
aggregated deploy.yaml의 워커 args 블록에는 MTP와 MoE 백엔드, 파서 설정이 함께 들어 있습니다.
–spec-method exaone_moe_mtp와 –spec-tokens 2는 MTP 방식과 draft length를 선택합니다. –kernel-config는 검증된 FLASHINFER_CUTLASS 백엔드를 선택하며, –dyn-* 옵션은 reasoning 및 tool-call 파서 설정을 Dynamo 프런트엔드에 전달합니다.
disaggregated 서빙에서는 prefill과 decode에 각각 별도 TP4 워커를 배치하고 NIXL/UCX로 KV 캐시를 전송합니다. 두 워커의 speculative decoding 설정과 블록 크기는 일치해야 합니다. Reasoning 및 tool-call 파서는 –dyn-* 옵션을 통해 Dynamo 프런트엔드에 전달해야 합니다. 일반 vLLM 파서 옵션만 설정해서는 동일한 응답 처리가 구성되지 않습니다. K-EXAONE 2.0 레시피
이 모델은 prefix 중복률과 실제 KV 재사용률의 차이도 보여 줍니다. 공개 채팅 trace는 약 70%의 prefix 재사용을 목표로 하지만, aggregated 실행의 실측 재사용률은 8.8%였습니다. Working set이 가용 KV 캐시 용량을 초과해 블록이 재사용되기 전에 축출되기 때문입니다. 애플리케이션 트래픽에서도 캐시 적중과 축출을 함께 관찰하면 라우팅 동작을 이해하는 데 도움이 됩니다.
실무에서는 처리량을 튜닝하기 전에 정확성을 확보해야 합니다. 검증된 커널 경로를 유지하면서 병렬화와 MTP를 평가하고, 워크로드의 prefix 중복이 그대로 캐시 적중으로 이어진다고 가정하지 말고 실제 재사용률을 측정하세요.
Solar Open 2의 캐시 재사용과 하이브리드 상태 전송
Solar Open 2는 전체 250B 파라미터 중 토큰당 15B를 활성화하는 하이브리드 MoE 모델입니다. 48개 레이어 중 12개는 GQA 기반 softmax attention, 36개는 KDA linear attention을 사용하며 최대 1M 토큰의 문맥을 지원합니다. 레시피는 nota-ai/Solar-Open2-250B-Nota-NVFP4를 사용합니다. aggregated 프로파일은 B200 GPU 4대에 TP2 워커 두 개를 배치하고, FP8 KV 캐시와 KV-aware 라우팅을 적용해 프롬프트와 대화 이력을 재사용합니다.
disaggregated 프로파일은 TP4 prefill 워커 한 개와 TP2 decode 워커 두 개를 사용합니다. Prefill 워커가 하나이므로 프런트엔드는 round-robin 라우팅을 사용합니다. Prefill과 decode 사이에서 KDA 상태를 전달하려면 VLLM_SSM_CONV_STATE_LAYOUT=DS가 필요합니다. 전송 과정에서 어텐션 KV 캐시와 KDA 상태를 모두 처리해야 하므로 이 설정을 생략하면 워커 초기화가 실패할 수 있습니다.
Solar Open 2는 MoE 실행에 flashinfer_trtllm을 사용하며 autotuning을 활성화합니다. FP8 KV 캐시는 FlashInfer 어텐션 경로와 함께 사용합니다. 이 모델에서 FlashAttention을 강제로 선택하면 초기화가 실패합니다. 하이브리드 KV 페이지에는 KDA 상태도 포함되므로 캐시 용량을 계산할 때 –block-size와 실제 페이지 크기를 구분해야 합니다.
배포 파일의 캐시와 상태 레이아웃
aggregated deploy.yaml의 워커 args 목록에서 TP2와 FP8 KV 캐시, FlashInfer 설정을 확인할 수 있습니다.
–kv-cache-dtype=fp8과 –enable-prefix-caching은 캐시 정밀도와 재사용을 구성합니다. flashinfer_trtllm 백엔드와 autotuning 옵션은 MoE 실행 경로를 정의합니다. 여기서 –dtype=bfloat16은 연산 자료형 설정이며, 체크포인트의 NVFP4 가중치 정밀도와는 다릅니다.
disaggregated deploy.yaml에서는 spec.env에 KDA 상태 레이아웃을 추가로 설정합니다.
– name: VLLM_SSM_CONV_STATE_LAYOUT
value: DS
레시피는 모델 정의와 파서 지원을 포함한 런타임 이미지를 digest로 고정합니다. 이 체크포인트는 speculative decoding을 사용하지 않습니다. 최대 1M 문맥을 사용하려면 충분한 KV 캐시 용량이 필요하며, max_tokens는 추론 과정과 최종 답변을 모두 담을 수 있도록 설정해야 합니다. Solar Open 2 레시피
공개 벤치마크 매니페스트는 실행 전에 서버 측 KV 캐시를 초기화하지 않습니다. 따라서 반복 실행에서는 이전 요청이 남긴 상태의 영향을 받을 수 있습니다. Cold-cache 비교 시에는 워커를 재시작하고, warm-cache와 cold-cache의 TTFT 및 처리량을 구분해 보고하세요.
실무에서는 disaggregated 구성을 평가할 때 어텐션 KV 캐시와 하이브리드 상태를 모두 고려해야 합니다. 호환되는 상태 레이아웃을 유지하고 캐시 조건을 통제해야 성능 차이를 평가 중인 구성의 효과로 해석할 수 있습니다.
Motif 3의 전용 런타임과 자체 speculative decoding
Motif 3는 전체 314B 파라미터 중 토큰당 13.2B를 활성화하는 MoE 모델입니다. 384개의 routed expert 중 8개를 선택하고 shared expert도 사용합니다. Grouped Differential Latent Attention(GDLA)은 grouped differential attention과 Multi-head Latent Attention(MLA)의 압축 KV latent를 결합하며, 최대 256K(262,144) 토큰의 문맥을 지원합니다. Expert-Specific PolyNorm 활성화 함수와 수정된 manifold-constrained hyper-connections(mHC), 단일 레이어 Multi-Token Prediction(MTP) head도 설계에 포함됩니다.
이러한 전용 구성요소 때문에 런타임 호환성을 먼저 고려해야 합니다. Motif의 공개 vLLM 포크는 MoE 레이어용 grouped PolyNorm 활성화 커널 등 Motif 전용 CUDA 커널을 컴파일하므로, 모델 코드를 기본 vLLM 설치에 단순 패치하는 방식으로는 적용할 수 없습니다. 레시피는 Motif가 공개한 vLLM 이미지를 기반으로 구축한 런타임 이미지(nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.5.0-motif-3-dev.2)에서 Dynamo 1.5.0을 실행합니다. 이 이미지에는 Motif 전용 코드가 포함되어 있으므로 vLLM 패키지를 관련 없는 nightly wheel로 교체해서는 안 됩니다.
NVFP4를 사용하면 각 워커가 B200 GPU 2대에서 314B 체크포인트를 서빙할 수 있습니다. aggregated 구성은 expert parallelism을 적용한 TP2 워커 1개를 사용합니다. disaggregated 구성은 TP2 prefill 워커 3개와 TP2 decode 워커 1개로 이루어진 3P1D 구성으로, 총 8대의 B200 GPU가 필요합니다. 두 구성 모두 FP8 KV 캐시와 내장 MTP head를 사용하며 후보 토큰 2개를 생성합니다. disaggregated 레시피에는 KV-aware 라우팅과 NIXL/UCX KV 전송을 적용합니다.
배포 파일의 speculative decoding과 병렬화
다음은 aggregated deploy.yaml에서 발췌한 구간입니다. 공통 상위 들여쓰기만 제거했습니다. 생략된 공통 설정을 포함한 전체 배포에는 원본 매니페스트를 사용하세요.
워커 args 목록의 양자화·병렬화·KV 캐시 옵션
워커 인자는 NVFP4 양자화와 expert parallelism을 적용한 TP2, 전체 262,144토큰 문맥, FP8 KV 캐시를 선택합니다. SPECULATIVE_CONFIG 환경변수는 ConfigMap의 speculative-config 키를 읽어 –speculative-config로 전달합니다. 기본 배포는 실제 MTP 검증을 사용하며, 별도의 speculative-config-synthetic 키는 벤치마크 전용 실험에서 acceptance length를 2.13으로 고정합니다.
워커가 하나인 경우 프런트엔드는 round-robin 라우팅을 사용하며, Motif의 tool-call 및 reasoning 파서도 프런트엔드에서 설정합니다. Motif 3 레시피
실무에서는 서빙 구성을 비교하기 전에 런타임 호환성을 확보해야 합니다. Motif 전용 런타임을 유지한 상태에서 목표 워크로드의 처리량과 지연 시간, 전체 GPU 요구량을 기준으로 speculative decoding과 토폴로지를 평가하세요.
모델별 최적화로 GPU당 처리량 높이기
B200에서 모델별 baseline 대비 GPU당 출력 처리량은 aggregated 구성의 A.X K2에서 약 1.72배, K-EXAONE 2.0에서 약 1.58배, Solar Open 2에서 약 1.43배, disaggregated 구성의 Motif 3에서 약 3.67배로 증가했습니다.
| 모델 | 전체 / 활성 파라미터 | 최적화 측정 구성 | Baseline 출력 tok/s/GPU | 최적화 출력 tok/s/GPU | 처리량 개선 |
|---|---|---|---|---|---|
| A.X K2 | 688B / 33B | aggregated GPU 8대 | 44.3 | 76.5 | 약 1.72배 |
| K-EXAONE 2.0 | 750B / 37B | aggregated GPU 4대 | 55.0 | 87.0 | 약 1.58배 |
| Solar Open 2 | 250B / 15B | aggregated GPU 4대 | 151.6 | 216.9 | 약 1.43배 |
| Motif 3 | 314B / 13.2B | disaggregated (3P1D) GPU 8대 | 86.95 | 319.26 | 약 3.67배 |
Baseline은 같은 모델의 NVFP4 체크포인트를 Dynamo와 vLLM에서 실행하며, 모델 적재에 필요한 최소 TP와 round-robin 라우팅을 사용합니다. 실행에 필요한 호환성 패치는 baseline에도 포함하고, 워커 replica 수는 최적화 레시피에 맞춥니다. 비교 지표는 GPU당 출력 처리량입니다.
Motif 3의 표에 표시한 319.26 output tok/s/GPU는 B200 GPU 8대를 사용하는 3P1D disaggregated 구성의 결과입니다. 최적화된 aggregated 구성의 결과는 293.96 output tok/s/GPU입니다. 각각의 벤치마크 운영점에서 disaggregated의 GPU당 처리량이 약 8.6% 높았으며, 3.67배는 별도 baseline 대비 disaggregated 결과의 개선 배율입니다. 두 비교의 기준은 서로 다릅니다.
개선율은 사용자별 생성 속도 50 tok/s 이상과 p50 TTFT 5초 미만이라는 SLA를 기준으로 측정한 GPU당 출력 처리량을 나타냅니다. 각 모델의 처리량은 해당 지연 시간 목표와 함께 평가하세요.
벤치마크 운영점과 측정 조건
aggregated 측정에서는 다음 운영점을 사용합니다. 사용자 출력 속도는 평균·E2E·p50 등 모델별로 정의가 다르므로 각 레시피의 맥락에 맞게 해석해야 합니다.
A.X K2: B200 GPU 8대, 동시성 16. Synthetic EAGLE3 acceptance length 2.12에서 76.49 tok/s/GPU를 측정했습니다. 평균 사용자 출력 속도는 55.83 tok/s, p50 TTFT는 525ms였습니다.
K-EXAONE 2.0: B200 GPU 4대, 동시성 7. 사용자별 E2E 처리량은 51.4 tok/s, p50 TTFT는 291ms였습니다. 문맥 한도를 초과한 요청 38개는 지표에서 제외했으며, 실측 KV 재사용률은 8.8%였습니다.
Solar Open 2: B200 GPU 4대, 동시성 20. 사용자 출력 속도 p50은 52.02 tok/s, p50 TTFT는 308ms였습니다. 실행 전에 서버 측 KV 캐시를 초기화하지 않았으므로 이전 캐시 상태가 결과에 영향을 줄 수 있습니다.
Motif 3: B200 GPU 2대, 동시성 11. Synthetic MTP acceptance length 2.13에서 293.96 tok/s/GPU를 측정했습니다. 사용자 출력 속도 p50은 66.27 tok/s, p50 TTFT는 388ms였습니다. Trace 요청 35개가 설정된 262,144토큰 문맥 한도를 초과했으며, 실제 MTP 검증을 적용한 결과는 아직 제공되지 않았습니다.
이 레시피는 모두 Mooncake trace 데이터셋을 바탕으로 8K 입력 시퀀스 길이(ISL), KV 캐시 적중률 70%, 1K 출력 시퀀스 길이(OSL)의 워크로드 형태에 맞춰 최적화했습니다.
애플리케이션을 검증할 때는 A.X K2에 실제 EAGLE3 수락 동작을, Motif 3에 실제 MTP 수락 동작을 사용하세요. 캐시 상태와 요청 제외 기준을 통제하고 처리량·TTFT·ITL·요청 성공률을 함께 측정해야 합니다.
서비스 목표에 맞춰 처리 용량 평가하기
GPU당 처리량이 높더라도 사용자의 대기 시간은 길 수 있습니다. TTFT와 ITL의 p50 및 p95·p99 같은 꼬리 지연을 요청 성공률과 함께 평가하세요. 대표적인 요청 길이로 동시성을 변화시키고, 선택한 서비스 수준 목표(SLO)를 충족하며 완료된 요청의 처리율인 goodput을 평가해야 합니다.
대화형 서비스는 첫 응답과 스트리밍 지연을 우선 살피고, 긴 추론 작업은 완료 시간도 포함하세요. 같은 GPU 예산에서 SLO를 만족하는 구성을 비교하고 지속 부하를 검증해야 합니다. Dynamo 벤치마크 가이드에서는 동시성 sweep과 goodput 분석을 설명합니다.
레시피는 재현 가능한 출발점을 제공합니다
각 레시피는 모델별 체크포인트와 런타임 이미지, 병렬화 전략, KV 캐시 정밀도, 라우팅, speculative decoding, 파서, 커널을 하나의 조합으로 고정합니다. 배포와 실행 동작을 재현할 수 있도록 다음 항목도 제공합니다.
NVIDIA Dynamo Operator용 Kubernetes 배포 매니페스트
공유 스토리지에 Hugging Face 체크포인트를 준비하는 작업
aggregated·disaggregated 토폴로지 구성
/v1/chat/completions 엔드포인트를 통한 스모크 테스트
AIPerf 또는 지정된 trace를 사용하는 벤치마크 재현 절차
모델별 알려진 제약과 운영 중 확인할 설정
레시피의 측정값은 지정된 하드웨어와 소프트웨어, trace, 동시성 조건에서 얻은 기준점입니다. 애플리케이션의 입력·출력 길이 분포와 prefix 재사용률, 동시 요청 수, 목표 SLO를 적용해 다시 측정하세요. NVIDIA DynoSim으로 지원되는 엔진 프로파일을 활용해 후보 구성을 좁힌 뒤 실제 클러스터에서 검증할 수 있습니다.
애플리케이션 트래픽에 맞춰 레시피 조정하기
튜닝 전에 공개 레시피를 먼저 재현하세요. 모델과 런타임, 평가 요청을 고정한 뒤 TP와 replica, 캐시와 라우팅, speculative decoding 등 설정 그룹을 한 번에 하나씩 바꿉니다. 기능 검증을 통과한 구성만 비교하고, 각 측정은 동일 조건에서 반복해야 합니다.
모델의 제약은 튜닝 범위를 결정합니다. A.X K2에서는 실제 EAGLE3 수락 동작을 측정하고, K-EXAONE 2.0에서는 검증된 MoE 백엔드와 MTP 설정을 유지해야 합니다. Solar Open 2에서는 FP8 KV 캐시와 KDA 상태 레이아웃의 호환성을 유지하고, Motif 3는 Motif vLLM 런타임 이미지에서 실행해야 합니다. 워크로드별 조정은 Dynamo 성능 튜닝 가이드를 참고하세요.
서빙 토폴로지 선택하기
워크로드의 병목과 서비스 목표를 바탕으로 초기 구성을 선택하세요.
공개된 워크로드와 유사한 조건에서는 K-EXAONE 2.0과 Solar Open 2가 우선 구성으로 제시하는 aggregated 프로파일로 시작하세요. 배포가 더 단순하며, 두 모델의 공개 측정에서는 disaggregated보다 낮은 TTFT를 보였습니다.
Prefill과 decode를 독립적으로 확장해야 한다면 disaggregated 프로파일을 평가하세요. 긴 입력과 긴 출력 요청이 혼재하거나 단계별 부하 변화가 다르면 워커 수와 TP를 각각 다르게 구성하는 것이 도움이 될 수 있습니다. 목표 부하에서 추가 GPU와 KV 전송 오버헤드를 포함해 비교해야 합니다.
시스템 프롬프트와 도구 정의, 대화 이력이 반복된다면 KV-aware 라우팅과 prefix 캐시 적중률을 함께 측정하세요. 재사용과 워커 부하의 균형을 맞추고 모델별·토폴로지별 라우팅 기본값을 확인해야 합니다.
disaggregated 배포에서는 레시피의 RDMA 리소스 이름(rdma/ib 또는 rdma/shared_ib)을 클러스터의 device plugin과 일치시키세요. 장치 할당뿐 아니라 NIXL/UCX 전송이 실제로 InfiniBand를 사용하는지도 확인해야 합니다.
운영 신호로 병목 찾기
Dynamo 지표와 구조화 로그, 분산 trace를 연계하면 요청 처리 경로에서 변화가 발생한 지점을 찾을 수 있습니다. TTFT가 증가하면 대기열과 prefill을, ITL이 증가하면 decode 부하와 KV 캐시 사용률을 확인하세요. 하나의 신호로 원인을 판단하기 전에 같은 부하와 시간 구간을 비교해야 합니다.
라우터가 추정한 prefix 중복률과 엔진의 실제 KV 재사용률을 구분하세요. disaggregated에서는 선택적 NIXL 텔레메트리로 전송을 살펴볼 수 있으며, UCX 로그로 InfiniBand 경로를 확인할 수 있습니다. 제공되는 신호와 설정은 관측성 가이드와 disaggregated 서빙 가이드를 참고하세요.
NVIDIA Dynamo 시작하기
다음 다섯 단계로 레시피를 배포하고 검증할 수 있습니다.
1. 인프라와 접근 권한 준비: 필요한 NVIDIA B200 GPU와 Kubernetes 클러스터, NVIDIA Dynamo Operator를 준비합니다. 체크포인트에 접근할 수 있는 Hugging Face 토큰을 설정합니다. disaggregated 서빙은 InfiniBand/RDMA 장치와 device plugin이 제공하는 리소스 이름을 확인합니다. A.X K2는 GPU 4대를 사용하는 워커마다 호스트 메모리 400GiB가 필요합니다.
2. 공유 스토리지와 모델 캐시 구성: ReadWriteMany 스토리지에 레시피의 체크포인트를 준비합니다. K-EXAONE 2.0은 약 530GB의 체크포인트를 위해 최소 700GB가 필요합니다. Solar Open 2 체크포인트는 약 153GB이며, 모델 캐시 매니페스트는 trace와 아티팩트 공간을 포함해 1,200Gi를 요청합니다. 용량과 storage class를 확인한 뒤 모델 다운로드 작업을 실행합니다.
3. 서빙 토폴로지 배포: 목표 워크로드에 맞는 aggregated 또는 disaggregated 매니페스트를 적용합니다. 고정된 런타임 이미지와 모델별 설정을 사용하고 워커 준비 상태를 확인합니다. K-EXAONE 2.0의 최초 가중치 적재와 autotuning, CUDA Graph capture에는 40~120분이 걸릴 수 있으므로 시작 시간을 따로 계획합니다.
4. 기능과 전송 경로 확인: /v1/chat/completions 스모크 테스트를 실행합니다. Reasoning이나 도구 호출을 사용한다면 파서 출력을 확인합니다. disaggregated 서빙에서는 NIXL/UCX 전송이 실제로 InfiniBand를 사용하는지 검증합니다.
5. 애플리케이션 트래픽으로 성능 검증: AIPerf와 애플리케이션 trace로 동시성을 변화시키며 GPU당 처리량과 TTFT, ITL, 요청 성공률을 측정합니다. 입력·출력 길이 분포와 캐시 상태, acceptance 설정을 기록한 뒤 목표 SLO를 만족하는 운영점을 선택합니다.
오픈웨이트 모델을 실제 서비스로 연결하기
핵심은 아키텍처별 병목에 맞춰 모델 실행과 서빙 시스템을 함께 튜닝하는 것입니다. A.X K2는 TP4와 sparse MLA, EAGLE3를 결합합니다. K-EXAONE 2.0은 TP4와 MTP, 모델별 MoE 커널을 결합합니다. Solar Open 2는 TP2와 KV-aware 라우팅, 하이브리드 상태 전송을 중심으로 구성합니다. Motif 3는 모델 전용 vLLM 런타임에 TP2와 expert parallelism, 자체 speculative MTP를 결합합니다. aggregated 구성은 TP2 워커 1개로 B200 GPU 2대를 사용하고, disaggregated 구성은 TP2 prefill 워커 3개와 TP2 decode 워커 1개로 B200 GPU 8대를 사용합니다. 정밀도와 병렬화, 캐싱, 토큰 생성을 함께 다루는 것이 GPU당 처리량을 높이는 기반입니다.
해당 모델의 공개 레시피로 시작해 구성을 재현하고, 대표적인 애플리케이션 트래픽으로 처리량과 지연 시간 목표에 맞춰 벤치마크하세요. 이 글에서 설명한 아키텍처 제약을 참고해 다음 튜닝 대상을 정하고, 한 번에 하나의 설정 그룹만 바꾸며 기능·성능 검증을 통과한 변경만 유지하세요.
NVIDIA는 Dynamo와 공개 최적화 레시피, 모델 개발사 및 개발자 커뮤니티와의 협력을 통해 오픈웨이트 모델 생태계를 지속적으로 지원할 것입니다. 개발자가 다양한 모델을 효율적으로 배포하고 확장할 수 있는 추론 소프트웨어를 발전시켜 모델의 역량을 실제 서비스의 가치로 연결하고자 합니다.
