오늘날의 LLM 서빙은 튜닝하기가 까다롭습니다. 배포마다 모델 백엔드, 텐서 병렬(TP) 형태, 프리필/디코드 분할, 워커 수, 스케줄러 설정, 라우팅 정책, KV 캐시 동작, 오토스케일링 임계값, 토폴로지 등 서로 영향을 주고받는 선택지가 켜켜이 쌓여 있기 때문입니다. 이러한 선택은 여러 계층에 걸쳐 상호작용하며, 한 곳을 개선하면 병목이 다른 곳으로 옮겨가기도 합니다. 규모가 큰 모델에서는 현실적인 실험 하나를 돌리는 데에도 다수의 GPU나 노드가 필요해, 그 아이디어가 검증할 가치가 있는지조차 확인하기 어렵습니다.
바로 이 지점에서 DynoSim, 즉 Dynamo 트윈이 출발합니다.
DynoSim은 NVIDIA Dynamo 서빙 스택을 워크로드 기반으로 시뮬레이션하는 이산 사건 시뮬레이션 도구입니다. 실측한 엔진 포워드 패스 타이밍, Mocker 스케줄러 코어, Router와 Planner 동작, KV 캐시 효과, 워크로드 트레이스를 하나의 가상 타임라인 위에서 결합합니다. 목표는 순수한 해석적 추정도, 비트 단위로 정확한 하드웨어 에뮬레이터도 아닙니다. 포워드 패스라는 원자 수준에서 충실하게 서빙을 시뮬레이션하되, 그 범위를 전체 추론 스택까지 확장하는 것이 목표이며, 우리에게 그 스택은 곧 Dynamo입니다(많은 다른 사용자에게도 마찬가지입니다).
DynoSim은 충실할 뿐 아니라, 전체 스택을 Rust로 구현한 덕분에 매우 빠르게 동작합니다. Apple M4 MacBook Air에서 단일 스레드 Rust 오프라인 리플레이는 23,608개 요청 규모의 Mooncake 트레이스를 라운드 로빈 워커 8개와 512토큰 트레이스·엔진 블록 구성으로 단 2.41초 만에 시뮬레이션했습니다. 시뮬레이션한 서빙 구간은 60.1분으로, 실제 시간보다 약 1,500배 빠른 셈입니다.
DynoSim을 사용한 스윕(sweep)은 기존 하드웨어에서 워크로드에 대한 파레토 최적 전선을 매핑할 수 있으며, 자율 연구 방식의 워크플로우는 더 나은 라우터 비용 함수, 플래너 휴리스틱 또는 캐시 정책과 같은 구성 요소의 알고리즘 변경을 제안할 수 있습니다.
아키텍처: Dynamo를 이벤트로 구성하기
핵심 설계 원칙은 구성(composition)입니다. DynoSim은 하나의 거대한 단일 모델이 아니라, 동일한 시뮬레이션 타임라인 위에서 동작하는 서빙 컴포넌트의 집합입니다. 리플레이 하니스가 워크로드 도착을 구동하고, 단일 엔진 시뮬레이션이 워커 단위의 스케줄링과 포워드 패스 타이밍을 모델링하며, 다중 엔진 시뮬레이션은 워커 사이에서만 발생하는 시스템 동작, 즉 라우팅과 분산 캐싱, Planner 결정을 더합니다.
가상 클록 위의 리플레이
이산 사건 시뮬레이션(DES)은 DynoSim에 가상 클록과 이벤트 큐를 제공합니다. 각 컴포넌트는 실제 시간을 기다리지 않습니다. 대신 요청 도착, 스케줄러 단계, 포워드 패스, KV 전송, 워커 기동, Planner 동작 같은 작업을 모델링된 지속 시간과 함께 미래 이벤트로 예약합니다. 런타임은 다음 타임스탬프로 건너뛰어 시스템 상태를 갱신하고, 영향을 받는 컴포넌트가 추가 작업을 예약하도록 합니다.
트윈을 통과하는 요청의 여정
- Dynamo AIPerf 같은 부하 생성기가 트레이스 또는 합성 워크로드에서 요청을 내보냅니다.
- Router가 요청을 어디로 보낼지, 아니면 대기시킬지 결정합니다.
- 선택된 엔진 스케줄러가 요청을 프리필 또는 디코드 패스로 배칭합니다.
- AI Configurator(AIC)가 뒷받침하는 하드웨어 기반 타이밍이 해당 패스의 지속 시간을 추정합니다.
- KV 핸드오프, 캐시, 오프로드 관련 이벤트가 같은 가상 타임라인에 예약될 수 있습니다.
- 디코드가 사용자에게 보이는 출력 토큰을 생성합니다.
- 트레이스 컬렉터가 요청 수준과 시스템 수준 지표를 기록합니다.
여기서 중요한 점은 모든 컴포넌트의 결정이 미래 이벤트를 바꾼다는 사실입니다. Router의 결정은 워커 큐에 영향을 주고, Planner의 스케일링 결정은 용량 확보를 지연시키며, KV 이동 결정은 디코드 시작 시점을 바꿀 수 있습니다.
리플레이 하니스: 트윈 구동하기
리플레이 하니스는 워크로드 생성을 시뮬레이션 컴포넌트에 연결한 뒤 다시 지표로 되돌립니다. 고정 트레이스의 경우 도착 이벤트를 트레이스에서 곧바로 예약할 수 있습니다. 멀티턴이나 에이전틱 트래픽처럼 피드백 기반 워크로드의 경우, 하니스가 후속 요청을 발행하기 전에 완료를 기다릴 수 있습니다. 트레이스 컬렉터는 시뮬레이션 타임라인에서 처리량, TTFT, TPOT, 종단 간 지연, 프리픽스 캐시 재사용률을 비롯한 요청 수준·시스템 수준 지표를 기록합니다.
단일 엔진 시뮬레이션: 스케줄러 충실도가 관건이다
단일 엔진은 단순한 초당 토큰 수 추정값에 그치지 않습니다. 스케줄러는 어떤 요청이 각 패스에 들어갈지, 프리필과 디코드 작업을 어떻게 배칭할지, KV 압력이 진행 상황을 어떻게 바꿀지 결정합니다. DynoSim은 이를 백엔드별로 구분해 다룹니다. vLLM 경로는 공유 토큰 예산과 선점·재계산을 갖춘 대기/실행 스케줄러를 모델링하고, SGLang 경로는 라딕스 캐시 인식 수용, 청크 프리필 예산, 프리픽스를 보존하는 디코드 철회를 모델링합니다.
AIConfigurator(AIC)는 엔진 측 타이밍으로서 이 그림에 들어맞습니다. 모델, 백엔드, 시스템, 텐서 병렬 형태, 패스 형태가 주어지면, 프리필이나 디코드 작업에 걸리는 시간을 추정합니다. 스케줄러 시뮬레이션이 각 패스의 구성 내용을 결정하면, AIC가 그 패스의 지속 시간을 추정합니다. AIC는 패스 속도를 알려주고, Mocker/리플레이 스케줄러는 그 패스를 둘러싼 서빙 동작을 모델링합니다.
아래 그림은 이 스케줄러 계층이 왜 중요한지를 보여줍니다. AIC는 엔진 측 성능, 특히 처리량과 토큰 시간 측면에서 실제 실리콘에 매우 높은 충실도를 제공합니다. 그러나 TTFT는 높은 동시성 환경에서 요청이 어떻게 대기하고, 배칭되고, 청크로 나뉘고, 프리필에 진입하는지에 민감하게 반응합니다.
다중 엔진 시뮬레이션: 워커에서 시스템으로
Dynamo의 힘은 활성 시스템 피드백을 바탕으로 온라인 결정을 내리는 컴포넌트에서 나옵니다. Router는 현재 캐시 상태와 디코드 부하를 알아야 합니다. Planner는 트래픽, 워커 상태, SLA 신호를 필요로 합니다. KVBM은 전송 압력, 계층 용량, 향후 캐시 가용성을 파악해야 합니다. 다중 엔진 시뮬레이션은 이러한 피드백 루프를 동일한 타임스탬프 정렬 이벤트 큐로 모델링합니다. 각 컴포넌트는 현재 시뮬레이션 상태를 관찰하고, 향후 결정이나 완료 이벤트를 다시 그 큐에 예약합니다.
아래의 구체적인 Router와 KVBM 결과에서는, 별도 언급이 없는 한 동일한 기준 리플레이 설정을 사용합니다. 23,608개 요청 규모의 Mooncake FAST25 toolagent 트레이스 전체, NVIDIA HGX B200에서 구동하는 MiniMax-M2.5 FP8, AIC가 제공하는 vLLM 0.14.0 타이밍, TP=4, 오프라인 리플레이가 그 구성입니다. Router 실험은 집계형 워커 8개로 구성하고, KVBM 실험은 워커 1개에 G2 호스트 메모리 계층을 토글합니다.
아래 그림은 라운드 로빈 라우팅과 KV Router를 비교합니다. G2 오프로드는 비활성화했으므로, 차이는 라우팅과 캐시 배치에서 비롯됩니다.
KVBM은 로컬 HBM, 호스트 메모리, SSD, 분산 또는 원격 캐시에 이르는 서빙 메모리 계층 전반에서 KV 블록을 관리합니다. 로컬 하위 계층 캐시 동작은 흔히 타이밍과 자원 압력으로 모델링할 수 있습니다. G1(GPU 메모리), G2(호스트 메모리), 전송 대역폭, 계층 용량, 그리고 최종적으로 G3(디스크)가 그 대상입니다. 시뮬레이션이 한층 흥미로워지는 지점은 분산 캐시입니다. 오프로드, 온보드, 원격 읽기, 배치 결정은 라우팅과 스케줄링, 큐잉, 향후 캐시 상태에 영향을 주므로, 나머지 서빙 하니스와 같은 타임라인 위에 이벤트로 등록해야 합니다.
아래 KVBM 예시는 G2 호스트 메모리 계층을 활성화하고 32,768블록으로 설정했을 때 Mocker가 무엇을 예측하는지 보여줍니다.
앞으로 리플레이는 실제 분산 캐시 대상을 향해 NIXL(NVIDIA Inference tranXfer Library) 읽기·쓰기를 구동할 수도 있습니다. 이러한 측정값은 전송 비용, 배치 동작, 경합을 보정한 뒤 분산 캐시 모델로 다시 반영됩니다.
DynoSim을 활용한 최적화와 탐색
DynoSim이 구성된 컴포넌트를 통해 워크로드를 실행할 수 있게 되면, 리플레이는 최적화와 탐색 양쪽에서 점수 함수 역할을 합니다. 레이아웃이나 정책을 제안하고, 워크로드를 실행하며, 지표를 수집해 목표나 가설과 비교하는 방식입니다.
리플레이를 통한 체계적 최적화
현재 최적화기는 다소 거칠지만 실용적인 블록 좌표 하강법을 배포 노브 전반에 적용합니다. TP 형태를 고르고, 그 TP 형태에 맞는 워커 분할을 고른 뒤, Router 설정을 고릅니다. 현재 탐색 공간이 아직 작고 국소적으로 충분히 매끄러워, 거친 좌표 탐색만으로도 유용한 후보를 찾을 수 있기에 이 방식이 통합니다. 탐색 공간이 커지면, 동일한 리플레이 점수 루프를 Hyperopt 계열의 베이지안 탐색, 유전 알고리즘, Vizier 같은 더 풍부한 블랙박스 최적화기에 연결할 수 있습니다.
더 흥미로운 점은 리플레이 루프가 정형화된 노브에만 국한되지 않는다는 것입니다. Karpathy의 오토리서치 방식처럼, 에이전틱 하니스가 사소하지 않은 코드 변경을 제안하고 Dynamo를 다시 빌드한 뒤 같은 트레이스를 재실행해, 목표를 개선하는 변경만 남길 수 있습니다. 이렇게 하면 리플레이는 작은 파라미터 그리드로 표현하기 까다로운 Router 비용 함수, Planner 휴리스틱, 캐시 정책을 다루는 제한된 연구 루프로 거듭납니다.
현재 최적화기를 넘어선 탐색 사례
같은 시뮬레이션 루프는 구성 탐색뿐 아니라 연구에도 활용할 수 있습니다. 어떤 실험은 노출된 파라미터를 조정하고, 또 어떤 실험은 알고리즘 자체를 바꿉니다.
여기서는 심층 탐색 사례를 Planner에 집중해 살펴봅니다. 오토스케일링은 두 가지 이유에서 DynoSim에 잘 맞습니다. 첫째, 흥미로운 동작이 거시적입니다. 수 분간의 트래픽, 지연된 워커 기동, 용량 변동, 스케일 결정과 큐·라우팅 사이의 피드백에서 비롯되는데, 작은 단위 테스트로는 이를 충실히 재현할 수 없습니다. 둘째, 이를 다른 방식으로, 즉 완전한 Kubernetes 환경에서 평가하면 정책 변경 한 건당 GPU 시간과 엔지니어 시간 모두에서 비용이 큽니다. DynoSim을 활용하면 완전한 환경을 구축하기 전에 이러한 효과를 적극적으로 휩쓸어 볼 수 있습니다. 정적 구성과 동적 구성을 비교하고, Planner 파라미터를 조정하며, 더 빠른 기동이나 예측적 스케일링, 미리 예열한 용량에 엔지니어링을 투입할 가치가 있는지 판단하기에 앞서 워커 기동 시간이 얼마나 중요한지 정량화하는 식입니다.
아래 세 가지 실험은 앞서 소개한 Mooncake FAST25 toolagent 트레이스를 재사용하되, 시뮬레이션 엔진 프로파일을 H200-SXM에서 TP=2로 구동하는 Qwen3-32B로 전환합니다.
실험 1, 구성 트레이드오프: 정적 배포와 Planner를 사용하는 동적 배포를 집계형 엔진으로 비교합니다. 정적 레플리카 수(Planner 없이 엔진 레플리카 수만 달리한 고정 배포)를 휩쓸어 보고, 그 위에 SLA를 TTFT=1500ms, ITL=50ms로 설정한 Planner 실행 하나를 겹쳐 봅니다.
Planner를 사용하는 동적 배포는 훨씬 더 나은 비용-지연 지점에 도달합니다. p90 TTFT와 ITL이 어떤 정적 배포보다 훨씬 낮으면서도, 동시에 더 적은 GPU 시간을 사용합니다.
실험 2, 스케일링 간격: 엔진 기동을 즉시로 설정한 채 스케일링 간격을 1초에서 300초까지 휩쓸어, 트래픽 변화에 빠르게 반응하는 것과 지나치게 자주 스케일링하는 것 사이의 트레이드오프를 살펴봅니다.
p90 TTFT는 1~10초 간격에서 거의 그대로 유지되지만, 스케일링 이벤트는 1,529회에서 233회로 급격히 줄어듭니다. 약 30초를 넘어서면 Planner가 버스트에 너무 느리게 반응합니다. GPU 시간은 전체 구간에서 대체로 일정하므로, 매우 짧은 간격이 GPU 시간을 크게 더 소모하지는 않지만 불필요한 스케일링 변동을 유발합니다. 가장 적절한 범위는 5~10초 안팎입니다.
실험 3, 콜드 스타트 시간: 실제 클러스터에서는 새 엔진 파드가 트래픽을 처리하기까지 수 초에서 수 분이 걸리므로, 용량을 추가하는 데 시간이 듭니다. 시뮬레이션에서는 이 지연을 모델링하고 Planner가 이를 얼마나 잘 다루는지 측정합니다.
TP=2의 Qwen3-32B에서 Planner는 기동 지연이 약 180초에 이를 때까지 SLA를 충족합니다. 200초 부근에서 성능이 급격히 떨어지고, 300초에 이르면 시스템이 트래픽 버스트에 발목이 잡혀 p90 TTFT가 242초까지 치솟습니다. 따라서 최상의 성능을 위해서는 콜드 스타트 시간을 200초 미만으로 최적화하는 편이 바람직합니다.
이 세 가지 실험은 설계 공간을 저렴하게 탐색하는 방법을 잘 보여줍니다.
이너 루프로서의 시뮬레이션
목표는 실제 클러스터 검증을 대체하는 것이 아니라, 그 검증을 한층 집중적으로 만드는 데 있습니다.
시뮬레이션은 설계 탐색의 이너 루프가 되고, 실제 클러스터는 검증을 위한 아우터 루프로 남습니다. 두 루프 사이에서 Dynamo는 스케줄러 동작, 라우팅 정책, Planner 제어, KV·캐시 이동, 워크로드 형태, 실측 엔진 타이밍을 하나의 시스템으로서 검증할 수 있습니다.
앞으로는 프로덕션에서도 이 루프를 닫을 계획입니다. DynoSim 위에 구축한 스마트 스위핑 알고리즘은 최근 기록한 프로덕션 트래픽을 대상으로 주기적으로 실행되어, 현재 워크로드 분포 아래에서 구성 공간을 탐색하고, 확연히 더 나은 배포를 찾으면 재구성을 권고하거나 직접 적용합니다. 트래픽 형태는 시간과 날짜에 따라 표류하므로(서로 다른 프롬프트 조합, ISL/OSL 분포, 버스트 패턴 등), 지난주에 적절했던 TP 형태와 프리필/디코드 분할, Router 정책, Planner 설정이 오늘은 더 이상 최적이 아닐 수 있습니다. DynoSim 기반의 지속적 스위핑은 일회성 출시 결정에 의존하는 대신, 라이브 배포가 현재의 최적값을 계속 추적하도록 돕습니다.
