소형 모델은 다양한 엔터프라이즈 사용 사례에 걸쳐 빠르게 더 많은 기능을 갖추고 적용 가능해지고 있습니다. 동시에 각각의 새로운 GPU 세대는 훨씬 더 많은 컴퓨팅 및 메모리 대역폭을 제공합니다. 그 결과 동시성이 높은 워크로드에서도 소형 LLM은 GPU 컴퓨팅 및 메모리 대역폭의 상당 부분을 유휴 상태로 두는 경우가 많습니다.
코드 완성, 검색, 문법 교정 또는 특화된 모델과 같은 사용 사례를 통해 저희 엔터프라이즈 고객은 Databricks에서 이러한 소규모 언어 모델을 다수 서빙하고 있으며, 저희는 끊임없이 GPU를 한계까지 사용하고 있습니다. NVIDIA의 다중 프로세스 서비스(MPS)는 유망한 도구처럼 보였습니다. 이는 여러 추론 프로세스가 단일 GPU 컨텍스트를 공유하여 메모리 및 compute 운영이 중첩되도록 함으로써 동일한 하드웨어에서 훨씬 더 많은 작업을 효과적으로 처리할 수 있게 합니다.
저희는 프로덕션 환경에서 MPS가 GPU당 더 높은 처리량을 제공하는지 엄격하게 테스트하기 시작했습니다. 그 결과 MPS가 다음과 같은 경우에 의미 있는 처리량 향상을 제공한다 는 것을 발견했습니다.
- 짧거나 중간 길이의 컨텍스트(<2k 토큰)를 사용하는 초소형 언어 모델(≤3B parameter)
- 프리필 전용 워크로드의 매우 작은 언어 모델(<3B)
- CPU 오버헤드가 상당한 엔진
저희의 절제 연구에 기반한 핵심 설명은 두 가지입니다. GPU 수준에서 MPS는 개별 엔진이 컴퓨팅 또는 메모리 대역폭을 충분히 활용하지 못할 때, 특히 소형 모델의 어텐션 지배적 단계에서 의미 있는 커널 중첩을 가능하게 합니다. 또한 유용한 부수 효과로, 멀티모달 워크로드에서 총 배치을 엔진 간에 샤딩하여 엔진별 CPU 부하를 줄임으로써 스케줄러 오버헤드나 이미지 처리 오버헤드 같은 CPU 병목 현상을 완화할 수 있습니다.
MPS란 무엇인가요?
NVIDIA의 다중 프로세스 서비스(MPS)는 여러 프로세스가 CUDA 커널을 하드웨어에 멀티플렉싱하여 단일 GPU를 더 효율적으로 공유할 수 있게 해주는 기능입니다. NVIDIA의 공식 문서에서는 다음과 같이 설명합니다.
다중 프로세스 서비스(MPS)는 CUDA 애플리케이션 프로그래밍 인터페이스(API)의 대안적인 바이너리 호환 구현입니다. MPS 런타임 아키텍처는 협력적인 다중 프로세스 CUDA 애플리케이션을 투명하게 활성화하도록 설계되었습니다.
간단히 말해, MPS는 드라이버 내에서 바이너리 호환 CUDA 구현을 제공하여 여러 프로세스(추론 엔진 등)가 GPU를 더 효율적으로 공유할 수 있도록 합니다. 프로세스가 액세스를 직렬화하는 대신(그리고 차례 사이에 GPU를 유휴 상태로 두는 대신), 리소스가 사용 가능할 때 MPS 서버에 의해 커널과 메모리 운영이 다중화되고 중첩됩니다.
스케일링 환경: MPS는 언제 도움이 될까요?
주어진 하드웨어 설정에서 효과적인 활용도는 모 델 크기, 아키텍처, 컨텍스트 길이에 따라 크게 달라집니다. 최신 대규모 언어 모델은 유사한 아키텍처로 수렴하는 경향이 있으므로, Qwen2.5 모델 제품군을 대표적인 예로 사용하여 모델 크기와 컨텍스트 길이가 미치는 영향을 탐구합니다.
아래 Experiment에서는 완벽하게 균형 잡힌 동종 워크로드를 사용하여 (MPS가 활성화된) 동일한 NVIDIA H100 GPU에서 실행되는 두 개의 동일한 추론 엔진을 단일 인스턴스 기준선과 비교했습니다.
스케일링 연구의 주요 관찰 결과:
- MPS는 컨텍스트가 짧은 소형 모델에서 50% 이상의 처리량 향상을 제공합니다
- 동일한 모델 크기의 경우 컨텍스트 길이가 증가함에 따라 이득은 로그 선형적으로 감소합니다.
- 모델 크기가 커짐에 따라 이득이 급격히 줄어들며, 이는 짧은 컨텍스트에서도 마찬가지입니다.
- 7B 모델 또는 2k 컨텍스트의 경우 이점은 10% 미만으로 떨어지며 결국 속도 저하를 유발합니다.
프리필 중심 워크로드에 대한 스케일링 연구의 주요 관찰 사항
- 소형 모델(<3B): MPS는 지속적으로 100% 이상의 throughput 향상을 제공합니다.
- 중간 크기 모델(~3B): 컨텍스트 길이가 증가함에 따라 이점이 감소하며 결국 성능 저하로 이어집니다.
- 대형 모델(>3B): MPS는 이러한 모델 크기에서 성능 이점을 제공하지 않습니다.
위의 스케일링 결과는 MPS의 이점이 효과적인 중첩을 용이하게 하는, 즉 GPU 활용도가 낮은 설정, 소형 모델 및 짧은 컨텍스트에서 가장 두드러지게 나타남을 보여줍니다.
이점 분석: MPS의 이점은 실제로 어디에서 오는가?
정확한 원인을 파악하기 위해 최신 트랜스포머의 두 가지 핵심 구성 요소인 MLP(다층 퍼셉트론) 계층과 어텐션 메커니즘을 따라 문제를 분석했습니다. 각 구성 요소를 분리하고(CPU 오버헤드와 같은 다른 교란 요인을 제거함으로써) 이득을 더 정확하게 귀속시킬 수 있었습니다.
필요한 GPU 리소스 | |||
| N = 컨텍스트 길이 | 프리필(compute) | 디코딩(메모리 대역폭) | 디코딩(compute) |
| MLP | O(N) | O(1) | O(1) |
| Attn | O(N^2) | O(N) | O(N) |
트랜스포머는 서로 다른 스케일링 동작을 보이는 Attention 및 MLP 레이어로 구성됩니다.
- MLP: 가중치를 한 번 로드하고 각 토큰을 독립적으로 처리 -> 토큰당 일정한 메모리 대역폭 및 컴퓨팅.
- Attention: KV 캐시를 로드하고 이전 모든 토큰과 내적을 계산 → 토큰당 선형 메모리 대역폭 및 컴퓨팅.
이를 염두에 두고 목표 제거 실험을 진행했습니다.
MLP 전용 모델(Attention 제거)
소규모 모델의 경우 배치당 토큰 수가 많아도 MLP 계층이 compute를 포화시키지 못할 수 있습니다. 모델에서 어텐션 블록을 제거하여 MLP의 영향을 분리했습니다.
위 그림에서 볼 수 있듯이 이점은 미미하며 빠르게 사라집니다. 모델 크기나 컨텍스트 길이가 증가함에 따라 단일 엔진은 이미 compute를 포화시킵니다(더 큰 MLP에서는 토큰당 더 많은 FLOPs, 더 긴 시퀀스에서는 더 많은 토큰). 엔진이 컴퓨팅 바운드 상태가 되면 두 개의 포화된 엔진을 실행해도 거의 이점이 없습니다 — 1 + 1 <= 1.
어텐션 전용 모델(MLP 제거)
MLP의 이득이 제한적인 것을 확인한 후, Qwen2.5-3B를 사용하여 어텐션 전용 설정을 유사하게 측정했습니다.
결과는 놀라웠습니다.
- 어텐션 전용 워크로드는 프리필과 디코드 모두에서 전체 모델보다 훨씬 더 큰 MPS 이득을 보입니다.
- 디코드의 경우, 이점은 컨텍스트 길이에 따라 선형적으로 감소하는데, 이는 디코드 단계에서 어텐션에 대한 리소스 요구 사항이 컨텍스트 길이에 따라 증가한다는 우리의 예상과 일치합니다.
- 프리필의 경우, 이득이 디코드보다 더 빠르게 감소했습니다.
MPS 이점은 순전히 어텐션 이점에서 비롯되는 것일까요, 아니면 Attention MLP 중첩 효과가 있는 것일까요? 이를 연구하기 위해, 실제 경과 시간(wall time)에 대한 기여도를 가중치로 하여 Attention 전용과 MLP 전용의 가중 평균으로 전체 모델 예상 이득(Full Model Expected Gain)을 계산했습니다. 이 전체 모델 예상 이득은 기본적으로 Attn-Attn 및 MLP-MLP 중첩에서만 발생하는 이득이며, Attn-MLP 중첩은 고려하지 않습니다.
디코드 워크로드의 경우, 전체 모델의 예상 이득이 실제 이득보다 약간 더 높아, 어텐션-MLP 중첩의 영향이 제한적임을 나타냅니다. 또한 프리필 워크로드의 경우 실제 전체 모델 이득(Full Model Gain)은 seq 128에서 기대되는 이득보다 훨씬 낮습니다. 이에 대한 가설적인 설명은 다른 엔진이 포화된 MLP를 수행하는 데 상당한 시간을 소비하기 때문에 불포화 Attention 커널이 중첩될 기회가 적기 때문일 수 있습니다. 따라서 MPS 이득의 대부분은 attention이 포화되지 않은 상태에서 2개의 엔진을 사용함으로써 발생합니다.
추가 이점: CPU 오버헤드로 손실된 GPU 시간 복구
위의 제거 실험은 GPU 바운드 워크로드에 초점을 맞췄지만, 가장 심각한 형태의 비활용은 다중 모드 모델의 스케줄러, 토큰화 또는 이미지 전처리 등과 같이 GPU가 CPU 작업을 기다리며 유휴 상태일 때 발생합니다.
단일 엔진 설정에서 이러한 CPU 지연은 GPU 사이클을 직접적으로 낭비합니다. MPS를 사용하면 첫 번째 엔진이 CPU에서 차단될 때마다 두 번째 엔진이 GPU를 인계받아 유휴 시간을 생산적인 compute로 전환할 수 있습니다.
이 효과를 분리하기 위해 이전의 GPU 수준 이득이 사라진 체제인 Gemma-4B(어텐션과 MLP가 이미 충분히 포화되어 커널 중첩 이점이 최소화되는 크기 및 컨텍스트 길이)를 의도적으로 선택했습니다.
8초의 지연 시간에서 기준 단일 엔진(파란색)은 스케줄러 CPU 오버헤드로 인해 제한되며, 이는 vLLM에서 비동기 스케줄링을 활성화하거나(녹색 선, 처리량 +33%) 비동기 스케줄링 없이 MPS로 두 개의 엔진을 실행하여(노란색 선, 처리량 +35%) 해결할 수 있습니다. 거의 동일한 이러한 이득은 CPU 제약 시나리오에서 MPS가 비동기 스케줄링이 제거하는 유휴 GPU 시간과 거의 동일한 시간을 회수할 수 있음을 확인시켜 줍니다. 순정 vLLM v1.0은 스케줄러 계층에 여전히 CPU 오버헤드가 있고 비동기 스케줄링과 같은 최적화를 완전히 사용할 수 없기 때문에 MPS가 유용할 수 있습니다.
총알, 하지만 은탄환은 아닙니다
저희 실험에 따르면, MPS는 몇몇 작동 영역에서 소형 모델 추론에 상당한 이득을 가져올 수 있습니다.
- CPU 오버헤드가 상당한 엔진
- 짧거나 중간 길이의 컨텍스트(<2k 토큰)를 사용하는 초소형 언어 모델(≤3B parameter)
- 프리필 중심 워크로드의 매우 작은 언어 모델(<3B)
이러한 최적 지점(예: 7B+ 모델, 8k 이상의 긴 컨텍스트 또는 이미 컴퓨팅 바운드인 워크로드)을 벗어나면 MPS가 GPU 수준의 이점을 쉽게 포착할 수 없습니다.
반면에 MPS는 운영상의 복잡성도 야기했습니다.
- 추가적인 구성 요소: 엔진 간에 트래픽을 분할하기 위한 MPS 데몬, 클라이언트 환경 설정 및 라우터/로드 밸런서
- 디버깅 복잡성 증가: 엔진 간 격리 없음 → 한 엔진의 메모리 누수 또는 OOM(메모리 부족)이 GPU를 공유하는 다른 모든 엔진을 손상시키거나 중단시킬 수 있음
- 모니터링 부담: 이제 데몬 상태, 클라이언트 연결 상태, 엔진 간 로드 밸런스 등을 주시해야 합니다.
- 취약한 장애 모드: 모든 엔진이 단일 CUDA 컨텍스트와 MPS 데몬을 공유하기 때문에, 단일 클라이언트의 오작동이 전체 GPU를 손상시키거나 리소스를 고갈시켜 함께 배치된 모든 엔진에 즉시 영향을 미칠 수 있습니다.
요컨대, MPS는 날카롭고 전문화된 도구입니다. 위에서 설명한 좁은 범위에서는 매우 효과적이지만 범용적인 이점이 되는 경우는 드뭅니다. 저희는 GPU 공유의 한계를 뛰어넘고 실제 성능 절벽이 어디에 있는지 알아내는 것을 정말 즐겼습니다. 전체 추론 스택에 걸쳐 아직 활용되지 않은 엄청난 양의 성능과 비용 효율성이 있습니다. 분산 서빙 시스템이나 프로덕션 환경에서 LLM을 10배 더 저렴하게 실행하는 데 관심이 있다면, 저희는 채용 중입니다!
저자: Xiaotong Jiang
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)