최근 Modal 엔지니어가 스탠퍼드에서 트랜스포머 추론의 클라우드 배포를 다룬 발표를 했다. 발표 범위는 애플리케이션 계층, 하드웨어, 디버깅, 관측 가능성까지 포함됐다.1 이 주제가 중요한 이유는 분명하다. 모델을 한 번 실행하는 것과, 지연시간·비용·장애를 통제하며 서비스로 운영하는 것은 다른 문제이기 때문이다.
트랜스포머 추론 배포는 결국 세 가지 질문으로 좁혀진다. 모델이 GPU 메모리에 들어가는가, 요구 지연시간을 만족하는가, 운영 중 문제를 관측하고 디버깅할 수 있는가.
배포의 첫 제약은 GPU 메모리다
트랜스포머 추론 배포에서 가장 먼저 확인할 것은 “이 모델이 한 장의 GPU에 올라가는가”다. 모델이 GPU 메모리에 들어가지 않으면 단순한 코드 수정으로는 해결하기 어렵다. 이때 필요한 선택지가 모델 병렬화다.
DeepSpeed-Inference는 트랜스포머 기반 PyTorch 모델을 효율적으로 서빙하기 위한 기능을 제공하며, 대형 모델을 GPU 메모리에 맞추기 위해 모델 병렬화를 지원한다.2 모델 병렬화는 모델을 여러 GPU에 나눠 올리고, 실행 중 필요한 통신을 관리하는 방식이다. DeepSpeed는 초기화 과정에서 필요한 경우 모델을 자동으로 분할하고 GPU 간 통신을 처리한다.2
중요한 점은 모델 병렬화가 “큰 모델을 억지로 올리기 위한 기술”에만 머물지 않는다는 것이다. DeepSpeed-Inference는 작은 모델의 추론 지연시간을 줄이는 데도 모델 병렬화를 사용할 수 있다고 설명한다.2 따라서 병렬화는 메모리 한계를 넘기 위한 수단이면서, 응답 속도를 조정하는 성능 전략이기도 하다.
런타임과 커널이 지연시간과 비용을 좌우한다
모델이 GPU에 올라간다고 해서 배포가 끝나는 것은 아니다. 같은 모델이라도 어떤 런타임과 커널로 실행하느냐에 따라 지연시간과 비용이 달라진다.
DeepSpeed-Inference는 추론용 커스텀 커널을 사용해 지연시간과 비용을 줄인다.2 또한 MoQ라는 양자화 방식을 통해 모델을 축소하고 운영 환경의 추론 비용을 낮출 수 있다.2 즉 추론 최적화는 단순히 더 큰 GPU를 쓰는 문제가 아니라, 실행 경로 자체를 바꾸는 문제다.
실무에서는 기본 PyTorch 실행이 가장 단순한 출발점이 될 수 있다. 하지만 운영 환경에서는 더 빠른 런타임을 검토해야 할 때가 많다. transformer-deploy 프로젝트는 ONNX Runtime과 Triton 조합이 일반 PyTorch보다 빠를 수 있고, TensorRT와 Triton 조합은 GPU에서 더 높은 성능을 낼 수 있다고 설명한다.3 다만 이런 선택지는 빌드, 호환성, 디버깅 부담도 함께 가져온다.
NVIDIA의 TensorRT-RTX 문서는 선택 기준을 더 구체화한다. 특정 GPU 몇 종을 겨냥하고 최고 처리량이 필요하면 TensorRT가 적합하고, 다양한 RTX PC에 배포해야 하면 TensorRT-RTX가 더 단순한 선택지가 될 수 있다.4 결국 배포 대상이 데이터센터인지, 사용자 PC인지에 따라 최적의 런타임은 달라진다.
DeepSpeed를 쓴다면 초기화 지점이 핵심이다
DeepSpeed-Inference의 장점은 기존 트랜스포머 모델을 추론용으로 전환하는 흐름이 비교적 명확하다는 데 있다. DeepSpeed는 DeepSpeed, Megatron, HuggingFace로 학습된 호환 트랜스포머 모델에 대해 별도의 모델 내보내기 없이 추론 모드를 제공한다.2
추론 초기화에는 init_inference API가 사용된다.2 이때 tensor_parallel의 tp_size로 텐서 병렬 크기를 지정할 수 있고, replace_with_kernel_inject를 True로 설정하면 호환 모델에 고성능 커널을 주입할 수 있다.2
이 지점에서 배포 설계가 코드 수준의 선택으로 내려온다. 몇 개의 GPU로 나눌 것인지, 커널 주입을 사용할 것인지, 양자화를 적용할 것인지에 따라 메모리 사용량·지연시간·비용이 함께 바뀐다.
운영에서는 성능보다 예측 가능성이 중요하다
트랜스포머 추론 배포는 하드웨어 최적화만으로 끝나지 않는다. 실제 서비스에서는 지연시간, GPU 메모리 사용률, 큐 대기시간, 에러율 같은 운영 지표를 지속적으로 봐야 한다. 문제는 모델 내부보다 토큰화, 배치 처리, 네트워크, GPU 스케줄링 같은 주변 시스템에서 드러나는 경우가 많다.
그래서 좋은 배포란 “가장 빠른 모델”을 만드는 일이 아니라 “예측 가능한 모델 서비스”를 만드는 일에 가깝다. 먼저 기본 실행으로 정확성을 확인하고, 그다음 DeepSpeed·ONNX Runtime·TensorRT 같은 선택지를 비교하는 흐름이 안전하다. 마지막 판단 기준은 단일 벤치마크 수치가 아니라 실제 운영 지표여야 한다.
트랜스포머 추론 배포의 핵심은 모델을 실행하는 방법이 아니라, 모델을 안정적으로 서비스하는 방법이다. GPU 메모리, 병렬화, 런타임, 커널, 양자화, 관측 가능성을 함께 설계할 때 비로소 추론 시스템은 실험 코드를 넘어 운영 가능한 서비스가 된다.
1Modal Engineer Presents Stanford Talk On Transformer Inference Deployment
2Getting Started with DeepSpeed for Inferencing Transformer based Models
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.