Red Hat OpenShift AI의 LLM 추론 성능 평가

생성형 AI(Artificial Intelligence, 인공지능) 환경은 지난 몇 년간 급속하게 발전했습니다. 생성형 LLM(Large Language Model, 대규모 언어 모델)의 성능이 향상됨에 따라 조직은 점점 더 자체 기능을 활용하여 비즈니스 요구 사항을 충족하는 방법을 모색하고 있습니다. LLM을 실행하려면 까다로운 컴퓨팅 요구 사항을 충족해야 하기 때문에 기반 하드웨어, 특히 GPU를 비용 효율적으로 사용하기 위해서는 LLM을 성능이 뛰어나고 안정적인 플랫폼에 배포해야 합니다.

이 문서에서는 Red Hat OpenShift AI에 포함된 모델 서빙 스택에 배포된 Llama-2 모델의 성능 테스트 방법과 결과를 소개합니다. OpenShift AI는 유연하고 확장 가능한 MLOps 플랫폼으로, AI 지원 애플리케이션을 빌드, 배포, 관리할 수 있는 툴을 제공합니다. 오픈소스 기술을 사용하여 구축한 이 플랫폼은 팀이 실험하고, 모델을 서빙하고, 혁신적인 애플리케이션을 제공할 수 있도록 일관된 운영을 지원하는 신뢰할 수 있는 기능을 제공합니다.

모델 서빙 스택

모델 서빙 소프트웨어 스택은 KServe, OpenShift Serverless, OpenShift Service Mesh를 기반으로 합니다. OpenShift AI에서도 OpenVINO를 지원하고 기타 사용자 정의 런타임을 모듈식으로 사용할 수 있는 기능을 제공하지만, Red Hat은 Llama-2 모델을 실행하기 위해 Caikit 및 TGIS(text-generation-inference-service)도 사용했습니다. NVIDIA GPU Operator는 TGIS 컨테이너에서 GPU를 사용할 수 있도록 GPU를 관리하고 노출합니다.

그림 1: KServe/Caikit/TGIS 스택의 구성 요소와 사용자 워크플로우 간 상호 작용.

KServe는 OpenShift Serverless와 OpenShift Service Mesh를 활용하여 AI 모델 추론에 필요한 다양한 첨단 서비스 기능을 제공합니다. 이러한 구성 요소는 프로덕션 모델 서빙을 위해 네트워킹, 서비스 구성, 자동 스케일링, 상태 점검과 관련된 복잡성을 캡슐화합니다.

Caikit 툴킷을 사용하면 사용자가 개발자 친화적인 API 집합을 통해 모델을 관리할 수 있습니다. Caikit은 다양한 기반 모델을 쿼리하는 데 사용할 수 있는 표준 gRPC(Remote Procedure Call, 원격 프로시저 호출) 및 HTTP 인터페이스를 제공합니다. 요청을 추론 서비스인 TGIS로 전달합니다.

TGIS는 Hugging Face TGIS 툴킷의 초기 분기입니다. 연속 배치, 신속한 배치, 텐서 병렬 처리(모델 샤딩), PyTorch 2 컴파일 지원 등 서비스를 제공하는 LLM 성능을 최적화하는 몇 가지 중요한 기능을 제공합니다.

NVIDIA GPU Operator는 OpenShift에서 NVIDIA GPU를 프로비저닝하고 사용하는 데 필요한 다양한 소프트웨어 구성 요소의 관리를 자동화합니다. 여기에는 드라이버 컨테이너, 장치 플러그인, DCGM(Data Center GPU Manager) 메트릭 내보내기 툴 등이 포함됩니다. DCGM 메트릭 내보내기 툴을 사용하면 OpenShift 모니터링 Prometheus 인스턴스를 사용하여 메모리 사용률, SM(Streaming Multiprocessor) 사용률 등의 GPU 메트릭을 분석할 수 있습니다.

대규모 언어 모델을 위한 성능 테스트 방법론

대규모 언어 모델의 성능을 평가할 때는 일반적으로 대기 시간과 처리량을 측정합니다. 그러나 LLM에 대한 요청의 엔드 투 엔드 대기 시간은 몇 가지 요인에 따라 크게 다를 수 있습니다. 가장 중요한 측면은 출력의 길이로, 이는 LLM이 한 번에 하나의 토큰으로 텍스트를 생성하는 방식 때문입니다. 따라서 주로 토큰당 대기 시간 또는 TPOT(Time Per Output Token, 출력 토큰당 시간) 관련 대기 시간을 측정합니다.

토큰은 단어 또는 하위 단어 문자열을 나타내는 텍스트 단위입니다. 대규모 언어 모델에서 텍스트를 처리할 때는 먼저 텍스트를 토큰으로 변환합니다. 텍스트를 토큰에 매핑하는 데 사용되는 정확한 체계는 모델마다 다릅니다. 토큰에는 숫자 표현이 할당되며 이러한 토큰은 모델에 제공된 후 모델에서 출력되는 벡터로 정렬됩니다.

총 요청 대기 시간에 영향을 미치는 또 다른 요인은 모델에서 새 토큰을 처음으로 생성하기 전에 입력 프롬프트 토큰을 처리하는 데 걸리는 시간인 '사전 채우기' 시간입니다. 총 요청 대기 시간에 세 번째로 중요한 요인은 대기 시간입니다. GPU 메모리와 같은 하드웨어 사양 미달로 인해 추론 서비스에서 들어오는 부하를 처리할 만큼 충분히 빠른 속도록 요청을 처리할 수 없는 경우 일부 요청은 처리되기 전에 대기열에서 기다려야 합니다. 이러한 요인으로 인해 TTFT(Time To First Token, 처음 토큰까지의 시간)는 LLM 성능을 측정하는 일반적인 메트릭으로 사용됩니다. TTFT는 특히 토큰이 생성될 때 스트리밍되고 표시되는 챗봇과 같은 활용 사례와 관련이 있습니다.

대기 시간과 마찬가지로 처리량은 초당 요청을 사용하여 측정하는 경우 요청에서 생성되는 토큰 수에 따라 크게 달라집니다. 따라서 모델을 쿼리하는 모든 사용자에 대해 초당 생성된 총 토큰의 전체 처리량을 측정합니다.

llm-load-test를 사용한 부하 테스트

Red Hat은 OpenShift AI 모델 서빙 스택에서 실행되는 모델에 부하 테스트를 수행하기 위해 llm-load-test라는 오픈소스 툴을 개발했습니다. 이 툴은 Python으로 작성되었으며 내부적으로 ghz라는 gRPC 부하 테스트 툴을 활용합니다. Red Hat은 테스트 출력의 각 요청에 대한 작업자 스레드 ID와 응답을 저장하는 기능을 추가하기 위해 ghz를 분기했습니다.

llm-load-test를 사용하면 ghz에서 제공하는 기능 외에도 각 인스턴스에서 임의의 순서로 여러 ghz 프로세스와 입력 데이터세트를 병렬로 실행할 수 있습니다. 이 기능을 사용하면 많은 사용자가 다양한 프롬프트를 사용하여 모델을 동시에 쿼리하는 상황을 시뮬레이션할 수 있습니다. 또한 llm-load-test는 실험 후 결과를 S3 버킷에 직접 업로드하여 실행에 대한 메타데이터로 출력 오브젝트에 태그를 지정할 수도 있습니다.

입력 데이터세트

JSON 파일을 사용하여 부하 테스트를 위한 llm-load-test에 입력 프롬프트를 구성할 수 있습니다. 이 블로그 포스트에서 공유한 결과를 생성하기 위해 실행한 실험에는 다양한 입력/출력 길이가 있는 OpenOrca 데이터세트에서 32개의 입력 데이터세트를 선택했습니다. 테스트 데이터에서 가장 긴 입력은 1688개 토큰이었고 가장 긴 출력은 377개 토큰이었습니다. 그림 2에서는 테스트 데이터세트의 입력/출력 길이 분포를 보여줍니다.

그림 2: 테스트 데이터세트의 토큰 길이.

실제 시나리오에서 TGIS의 연속 배치 및 신속한 배치 기능을 테스트하려면 입력 및 출력 크기를 혼합하여 사용해야 합니다. 최근 모델에서는 4k 이상의 매우 큰 컨텍스트 길이를 지원하기 시작했으며, 이는 RAG(retrieval-augmented generation)와 같은 활용 사례에서 특히 중요합니다. 따라서 향후 더 큰 입력 길이를 포함하도록 부하 테스트 데이터세트의 크기를 늘릴 계획입니다.

OpenShift AI on AWS에서 llama-2의 성능 결과

다음 성능 측정값은 AWS에 설치된 셀프 매니지드 IPI(installer-provisioned infrastructure) OpenShift 클러스터를 사용하여 수집되었습니다. Kserve, Caikit, TGIS를 사용하여 모델을 서빙할 수 있도록 OpenShift AI Operator를 설치하고 ServingRuntime 및 InferenceService 오브젝트를 생성했습니다.

아래 표 1에는 모델과 AWS 인스턴스 유형의 네 가지 조합을 테스트한 결과가 요약되어 있습니다.

표 1: 테스트 구성 요약.

각 구성에서 llm-load-test를 다양한 수의 동시 스레드(아래 그림의 동시성 매개 변수)와 함께 사용하여 4분 동안 여러 번의 부하 테스트를 실행했습니다. 각 테스트에서 각각의 동시 스레드는 이전 요청에서 응답을 받는 즉시 한 번에 하나의 요청을 계속 전송합니다.

아래의 그림 3은 특정 실험에서 테스트 기간 동안 각 요청의 총 대기 시간을 시각적으로 표현한 것입니다. 각 점의 색상은 토큰 길이를 나타내므로 토큰 길이가 전체 요청 출력과 얼마나 밀접한 상관관계가 있는지 시각화할 수 있습니다.

그림 3: 부하 테스트 기간 동안 모든 요청의 총 대기 시간.

각 요청의 총 대기 시간은 TGIS 로그를 구문 분석하여 얻고, 처리량은 부하 테스트 중 생성된 총 토큰을 테스트 기간(240초)으로 나누어 계산했습니다.

그림 4에서는 다양한 부하 테스트 동시성 설정을 사용하여 g5.2xlarge 인스턴스에서 llama-2-7b를 부하 테스트할 때 측정된 대기 시간과 처리량을 보여줍니다. 이 경우 부하 테스트 동시성을 최대 20개의 스레드 동시성으로 늘리면 처리량이 증가하는 것을 확인할 수 있습니다. g5.2xlarge 인스턴스의 GPU 메모리 제약으로 인해 TGIS는 한 번에 20개 이상의 요청을(요청의 입력/출력 길이에 따라 다름) 배치에 맞출 수 없습니다.

그림 4: g5.2xlarge의 Llama-2-7b에 대한 대기 시간 및 처리량 요약.

그림 5 그래프에서는 g5.12xlarge 인스턴스에서 llama-2-13B를 부하 테스트할 때 측정된 대기 시간과 처리량을 보여줍니다. 이 경우 토큰당 최소 대기 시간은 g5.2xlarge의 7B 모델보다 짧게 시작하고, 모델이 더 크고 인스턴스에 동일한 유형의 GPU가 있음에도 불구하고 처리량이 동시 요청 30개 이상으로 확장됩니다. 이는 텐서 병렬 처리를 사용하여 GPU 4개에 모델을 배포함으로써 얻는 상당한 성능 이점 때문입니다.

그림 5: g5.12xlarge의 Llama-2-13b에 대한 대기 시간 및 처리량 요약.

그림 6에서는 g5.48xlarge 인스턴스에서 llama-2-70b를 부하 테스트할 때 측정된 대기 시간과 처리량을 보여줍니다. 이 경우 토큰당 대기 시간이 이전 구성보다 전반적으로 더 깁니다. llama-2-70B와 같은 모델에는 중요한 하드웨어 요구 사항이 있습니다. 8xA10G GPU에는 192GB VRAM이 결합되어 있는데, 대부분 16비트 정밀도의 70B 매개 변수를 메모리에 로드하는 데에만 필요합니다(70B*16비트 = ~140GB). 성능 요구 사항에 따라 p4d.24xlarge 인스턴스와 같이 추가 컴퓨팅이 필요할 수 있습니다.

그림 6: g5.48xlarge의 Llama-2-70b에 대한 대기 시간 및 처리량 요약.

그림 7에서는 p4d.24xlarge 인스턴스에서 llama-2-70b를 부하 테스트할 때 측정된 대기 시간과 처리량을 보여줍니다. 이 인스턴스에서는 g5.48xlarge 인스턴스에 비해 동일한 수의 사용자에 대해 훨씬 더 짧은 대기 시간을 유지할 수 있습니다. 동시성=30까지 부하 테스트 동시성이 증가함에 따라 처리량이 계속 확장됩니다.

그림 7: p4d.24xlarge의 Llama-2-70b에 대한 대기 시간 및 처리량 요약.

비용 계산

측정된 처리량과 인스턴스 유형 비용을 사용하여 토큰 100만 개를 생성하는 데 드는 비용을 추정할 수 있습니다. 아래 표에는 10의 부하 동시성으로 수집한 결과에 대해 측정된 처리량을 사용하여 이러한 추정치가 요약되어 있습니다.

표 2: 각 구성에 대한 결과 요약(토큰 백만 개당 계산된 비용 포함).

향후 작업

이러한 결과는 Red Hat의 PSAP(Performance and Scale for AI Platform) 팀에서 진행 중인 테스트에 대한 작은 스냅샷에 해당합니다. Red Hat은 OpenShift AI의 기타 측면에 대한 성능 테스트와 함께 모델 서빙 스택의 성능과 확장성 분석을 적극적으로 진행하고 있습니다. 다른 모델을 테스트하고, 트래픽을 기반으로 모델 복제본을 자동 스케일링하는 등 향후 더 많은 결과를 공유하고자 합니다.

Red Hat은 llm-load-test를 계속 개발할 예정이며, 다음과 같은 몇 가지 기능이 곧 추가될 예정입니다.

• 스트리밍 요청에 대한 time-to-first-token(첫 번째 토큰까지의 시간) 및 time-per-output-token(출력 토큰당 시간)을 측정하는 기능
• HTTP 및 gRPC 인터페이스를 포함하여 다양한 API의 기반이 되는 쿼리 모델에 대한 장착형/모듈식 인터페이스
• 준비 단계 & 모델이 오류 없이 로드되어 응답하는지 검증하는 기능
• 더 복잡한 부하 패턴(예: 임의의 푸아송 도착 속도)

결론

OpenShift AI에서 수행한 Llama-2 모델의 성능 테스트를 통해 LLM을 다양한 구성으로 실행하는 데 필요한 대기 시간과 처리량, 비용 간의 절충안을 확인할 수 있습니다. 예를 들어 7B 모델의 경우 g5.2xlarge 인스턴스가 가장 경제적이었지만, g5.12xlarge로 업그레이드하면 텐서 병렬 처리로 인해 대기 시간과 처리량이 상당히 개선되므로 일부 활용 사례에서는 이 인스턴스가 유용할 수 있습니다. 대규모 모델을 실행하면 출력 품질이 향상되지만 더 많은 GPU 메모리가 필요하므로 비용이 늘어납니다.

OpenShift AI는 조직이 생성형 대규모 언어 모델 배포의 복잡성을 다룰 수 있도록 성능과 적응성을 갖춘 모델 서빙 솔루션을 제공합니다. 모델 품질, 대기 시간, 처리량, 비용 중 우선순위가 어디에 있든 유연한 플랫폼이 다양한 요구 사항을 수용합니다. 귀사의 활용 사례에서 이러한 장점을 누릴 수 있는지 확인하려면 선택한 모델을 OpenShift AI에 배포해 보세요.