대규모 언어 모델(LLM) 서비스 및 배포를 위한 최고의 클라우드 GPU

대여한 GPU에서 LLM 서빙이 실제로 요구하는 것

대형 언어 모델(LLM) 서빙은 모델 훈련과 근본적으로 다른 작업입니다. 훈련은 처리량에 제한을 받고 지연 시간에 관대하지만, 서빙은 지연 시간에 민감하며 메모리 제한이 있고 버스트성 트래픽이 발생합니다. API 뒤에 LLM을 배포하기 위해 GPU를 대여할 때 병목 현상은 거의 원시 FLOPS가 아닙니다. 모델과 그 KV 캐시를 VRAM에 얼마나 많이 보유할 수 있는지, 그 메모리가 얼마나 빠르게 스트리밍되는지, 그리고 토큰당 초당 사용자별 요청을 배치할 수 있는 동시 요청 수가 얼마나 되는지가 중요합니다.

KV 캐시는 대부분의 사람들이 과소평가하는 부분입니다. 모든 활성 요청은 해당 컨텍스트에 대한 어텐션 키와 값을 저장하며, 이 메모리 사용량은 시퀀스 길이와 동시 사용자 수에 따라 증가합니다. 유휴 상태에서 여유 있게 맞는 모델도 긴 프롬프트가 포함된 실제 트래픽이 들어오면 즉시 메모리가 부족해질 수 있습니다. 이 때문에 서빙 배포는 종종 모델 가중치만으로 예상되는 것보다 더 많은 VRAM 여유 공간이 필요합니다.

GPU 크기 조정 방법

실질적인 첫 번째 질문은 모델이 한 대의 GPU에 맞는지 아니면 여러 대로 분할해야 하는지입니다. 위 비교를 모델과 대조하여 다음 요소들을 고려하십시오:

• VRAM 용량은 어떤 모델이 맞는지를 결정합니다. FP8 또는 INT8로 양자화된 7B~13B 모델은 중급 가속기 한 대에서 서빙할 수 있지만, BF16의 70B 모델은 일반적으로 고메모리 카드나 다중 GPU 노드가 필요합니다. 매우 대형 프런티어급 모델은 사실상 여러 대의 최고급 GPU를 연결해야 합니다.
• 메모리 대역폭은 토큰 생성 속도를 결정합니다. 자동회귀 디코딩은 생성되는 모든 토큰마다 전체 가중치를 읽기 때문에, 데이터센터 카드에 탑재된 HBM급 메모리가 동일한 모델 크기의 GDDR 기반 소비자 카드보다 훨씬 빠르게 토큰을 생성합니다. 대화형 채팅에서는 대역폭이 계산 성능보다 더 중요할 때가 많습니다.
• 지원되는 정밀도는 모델을 얼마나 공격적으로 축소할 수 있는지를 결정합니다. FP8 및 INT8 텐서 지원이 있는 카드는 서빙 스택과 모델의 양자화 방식이 호환되는 경우, 더 적은 VRAM으로 더 큰 모델을 더 높은 처리량으로 서빙할 수 있습니다.
• 인터커넥트는 모델이 여러 GPU에 걸쳐 있을 때 중요합니다. 텐서 병렬 서빙은 각 레이어마다 GPU 간 활성화를 교환하므로, 노드 내 NVLink급 연결이 PCIe 전용 구성보다 지연 시간을 크게 줄여줍니다. 단일 GPU 배포에서는 인터커넥트가 중요하지 않습니다.

단일 GPU 대 다중 GPU 서빙

모델과 최대 KV 캐시가 한 대의 GPU에 맞는다면 그곳에 유지하십시오. 단일 GPU 서빙은 장치 간 통신 오버헤드를 완전히 피하고 운영이 더 간단합니다. 모델이 실제로 맞지 않을 때만 텐서 병렬화나 다중 노드 서빙으로 전환하십시오. GPU를 추가할수록 동기화 비용이 증가하고 자동 확장이 복잡해집니다. 여러 GPU가 필요할 경우, 위 목록에서 고메모리 카드와 빠른 노드 내 인터커넥트를 결합한 인스턴스를 선호하십시오. 느슨하게 연결된 카드를 조합하는 것보다 낫습니다.

훈련이 아닌 서빙에 중요한 제공자 기능

실리콘을 넘어, 제공자의 운영 모델이 배포 가능성을 결정합니다. 위 비교를 훈련 작업이 아닌 서빙 작업에 맞게 살펴볼 때는 우선순위를 다르게 두십시오:

• 콜드 스타트 및 설정 시간이 주요 관심사가 됩니다. 트래픽 급증 사이에 0으로 확장되는 서빙 엔드포인트는 확장 시마다 콜드 스타트 비용을 지불하므로, 빠른 프로비저닝과 이미지 캐싱이 꼬리 지연 시간에 직접적인 영향을 줍니다.
• 청구 단위는 버스트성 트래픽의 경제성에 영향을 줍니다. 초 단위 또는 분 단위 청구는 인스턴스를 자동 확장하는 엔드포인트에 적합하지만, 시간 단위의 거친 청구는 이 패턴에 불리합니다.
• 온디맨드 신뢰성 대 스팟은 일반적으로 올바른 선택입니다. 인터럽트 가능하거나 스팟 인스턴스는 훈련 및 배치 작업에 적합하지만, 사용자 대상 실시간 엔드포인트에서는 요청 중간에 인스턴스가 회수되면 라이브 트래픽이 중단될 위험이 있습니다. 스팟은 비대화형 배치 추론에는 여전히 적합합니다.
• 영구 저장소 및 빠른 모델 로딩은 재시작 시 고통을 줄여줍니다. 매번 콜드 오브젝트 저장소에서 재로드하는 수 기가바이트 가중치는 수 분의 다운타임을 추가하지만, 캐시되거나 연결된 볼륨은 이를 단축합니다.
• 네트워킹 및 아웃바운드 트래픽은 대규모에서 비용에 영향을 미칩니다. 고처리량 추론은 많은 데이터를 전송할 수 있으므로, 고트래픽 배포 전에 아웃바운드 조건을 확인하십시오.

배치 대 실시간, 그리고 비용 위치

어떤 모드를 최적화할지 조기에 결정하십시오. 실시간 대화형 서빙은 첫 토큰까지의 시간과 사용자별 토큰 속도를 중시하며, 이는 고대역폭 메모리와 적당한 배치 크기를 선호합니다. 배치 또는 오프라인 추론은 총 처리량을 중시하며, 더 저렴하거나 인터럽트 가능한 하드웨어에 큰 배치를 쌓아 요청당 지연 시간을 희생하는 대신 토큰당 비용을 크게 절감합니다. 많은 팀이 두 가지를 모두 운영합니다: 라이브 사용자용 반응형 온디맨드 계층과 대량 생성을 위한 스팟 기반 배치 계층.

대여 비용 측면에서 서빙은 전체 스펙트럼에 걸쳐 있습니다. 중급 카드에서 양자화된 작은 모델은 저렴하고 널리 이용 가능하지만, 다중 GPU 고메모리 노드에서의 프런티어 모델은 희소하고 더 비싸며 수요 급증 시 용량이 제한될 수 있습니다. 요금은 지속적으로 변동하고 지역 및 약정에 따라 다르므로, 위 실시간 비교를 고정된 수치보다 진실의 원천으로 간주하고 VRAM, 대역폭 등급, 인터커넥트, 청구 모델을 함께 비교하십시오.

자주 묻는 질문

LLM 서빙에 필요한 VRAM은 얼마입니까?

선택한 정밀도의 모델 가중치 예산과 컨텍스트 길이 및 동시 사용자 수에 따라 증가하는 KV 캐시에 충분한 여유 공간을 포함하십시오. 대략적인 가이드로, 양자화된 소형 및 중형 모델은 단일 중급 카드에서 서빙할 수 있으며, 고정밀 대형 모델은 고메모리 카드 또는 여러 GPU가 필요합니다. 항상 유휴 상태가 아닌 최대 동시성을 기준으로 크기를 조정하십시오.

스팟 또는 인터럽트 가능한 GPU가 LLM 서빙에 적합합니까?

사용자 대상 실시간 엔드포인트에는 일반적으로 적합하지 않습니다. 회수 시 라이브 요청이 중단되고 콜드 재시작이 강제되기 때문입니다. 스팟 인스턴스는 중단이 처리량 지연만 초래하는 오프라인 또는 배치 추론에 적합합니다. 많은 팀이 라이브 트래픽에는 온디맨드 용량을 유지하고 대량 작업에는 스팟을 사용합니다.

서빙에서 메모리 대역폭이 계산 성능보다 중요한 이유는 무엇입니까?

토큰별 디코딩은 생성되는 모든 토큰마다 메모리에서 모델 가중치를 읽기 때문에, 생성 속도는 GPU가 메모리를 스트리밍하는 속도에 의해 제한됩니다. 이 때문에 HBM이 장착된 데이터센터 카드는 동일 모델을 보유한 소비자 카드보다 토큰을 더 빠르게 생성하며, 대역폭이 위 비교에서 중요한 열인 이유입니다.

한 대의 GPU에서 서빙해야 합니까, 아니면 여러 대로 분할해야 합니까?

모델과 최대 KV 캐시가 맞는 한 단일 GPU를 사용하십시오. 이는 장치 간 통신을 피하고 확장을 단순화합니다. 모델이 정말 맞지 않을 때만 다중 GPU 텐서 병렬화로 전환하고, 그럴 경우 고메모리 카드와 빠른 노드 내 인터커넥트를 결합한 인스턴스를 선택하십시오.