Red Hat OpenShift, 금융 서비스를 위한 고성능 LLM 추론 지원

금융 서비스 산업은 다른 많은 부문과 마찬가지로 리소스 집약적인 AI 워크로드 시대에 하드웨어를 최대한 활용하는 것을 목표로 합니다. 금융 서비스 기업은 컨테이너 기반 아키텍처의 장점을 활용하고 있지만, 컨테이너 오케스트레이션 플랫폼으로 인해 성능 저하가 발생하여 리소스 제약이 악화될 수 있다고 우려하기도 합니다. 

금융 서비스의 대규모 언어 모델(LLM) 추론 성능 평가를 위한 업계 표준 벤치마크인 새로운 STAC-AI™ LANG6(Inference-Only) 감사 결과는 Red Hat OpenShift에 대한 이러한 우려를 해소하는 데 도움이 될 수 있습니다. Red Hat 성능 및 스케일 엔지니어링 팀은 NVIDIA 및 Supermicro와의 협업을 통해 Supermicro SuperServer SYS-222C-TN에서 2개의 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU를 사용하여 Red Hat OpenShift에서 전체 STAC-AI LANG6 벤치마크 제품군을 실행했습니다. 이는 컨테이너화된 쿠버네티스 플랫폼에서 생성된 최초의 STAC-AI 감사 결과입니다.

Red Hat은 OpenShift가 가장 까다로운 워크로드에 대해 베어메탈과 유사한 성능을 제공한다는 것을 오랫동안 입증해 왔으며, 독립적으로 감사된 결과를 통해 이러한 주장을 뒷받침합니다. STAC-N1 네트워크 벤치마크에서 OpenShift는 시장 데이터의 베어메탈 대기 시간과 일치(일부 경우에는 개선)함을 보여주었으며, 초당 10만 및 140만 메시지 모두에서 가장 낮은 평균과 중앙값 대기 시간을 기록하는 동시에 최대 대기 시간을 37% 줄였습니다. 기록적인 STAC-A2 시장 리스크 벤치마크에서 Red Hat은 NVIDIA DGX A100 시스템이 설치된 OpenShift에서 GPU 가속화 몬테카를로 시뮬레이션에 대한 여러 기록을 세웠습니다. Intel CPU가 탑재된 STAC-A2에서는 CPU 집약적인 금융 워크로드에서도 OpenShift의 컨테이너화 오버헤드가 무시할 수 있는 수준임을 보여주었습니다.

이 새로운 STAC-AI 제출은 이러한 기록을 LLM 추론 영역으로 확장합니다. 금융 기관이 사기 감지, 보안, 정서 분석, 규제 컴플라이언스를 위해 AI 기반 워크플로우를 도입함에 따라 이 영역의 중요성이 급격히 커지고 있습니다.

STAC-AI LANG6 개요

전략적 기술 분석 센터(STAC)는 세계 최대 금융 기관이 기술 스택을 평가하는 데 사용하는 표준화된 벤치마크를 생성합니다. STAC-AI LANG6는 금융 서비스 활용 사례에 대한 LLM 추론 성능을 측정합니다. 이 벤치마크의 데이터세트는 실제 SEC EDGAR 재무 자료에서 파생되었으며, 이는 금융 기관에서 RAG(검색 증강 생성) 및 긴 컨텍스트(long-context) 워크로드를 구동하는 데 사용되는 문서 유형입니다.

벤치마크는 두 가지 추론 모드를 다룹니다. 배치 모드는 단일 API 호출로 전체 데이터세트를 테스트 대상 시스템(SUT)으로 전달하여 최대 처리량을 측정합니다. 인터랙티브 모드는 푸아송 분포에 따라 다양한 도착 속도로 요청을 전송하여 실제 사용 사례를 시뮬레이션하는 동시에, 부하 상태에서의 반응 시간(첫 번째 토큰까지의 시간과 유사), 응답 시간, 출력 속도를 측정합니다.

프롬프트 길이와 복잡성이 다양한 4개의 EDGAR 데이터세트에서 2개의 모델(Llama-3.1-8B-Instruct 및 Llama-3.1-70B-Instruct)을 테스트했습니다. 또한 벤치마크는 충실도(fidelity)를 측정합니다. 즉, 최적화된 모델의 출력이 STAC 참조 SUT에서 네이티브 정밀도로 실행되는 동일한 모델과 얼마나 일치하는지를 확인합니다. 사양에 따르면 총 7개의 필수 워크로드가 필요합니다. 

표 1. STAC-AI 벤치마크의 모델, 데이터세트, 실행 모드

스택

하드웨어:

• Supermicro SuperServer SYS-222C-TN, 2U DC-MHS 서버
• Intel Xeon 6730P CPU 2개(물리 코어 총 64개)
• 2TiB DDR5-5200(64GiB DIMM 32개)
• 2x NVIDIA RTX PRO 6000 Blackwell Server Edition GPU(각각 96GiB GDDR7)

소프트웨어:

• Red Hat OpenShift 4.20(단일 노드 OpenShift)
• Red Hat Enterprise Linux CoreOS 9.6
• 노드 기능 검색 오퍼레이터
• NVIDIA GPU operator
• STAC-AI 오퍼레이터(Red Hat에서 개발한 사용자 정의 오퍼레이터)
• NVIDIA Model Optimizer 0.37.0을 통해 NVFP4 양자화를 사용하는 NVIDIA TensorRT-LLM 1.2.0rc2(PyTorch 백엔드)

오퍼레이터 스택은 STAC-A2 작업에서 설정한 것과 동일한 패턴을 따릅니다. 노드 기능 검색 오퍼레이터는 전제 조건으로, 각 노드에서 하드웨어 기능을 검색하고 이를 쿠버네티스 레이블로 표시합니다. NVIDIA GPU 오퍼레이터는 이러한 레이블을 사용하여 GPU 드라이버 컨테이너를 배포할 위치를 결정하며, 스케줄러에서 GPU를 nvidia.com/gpu 리소스로 사용할 수 있도록 합니다. 이 시점부터 포드는 CPU 또는 메모리를 요청하는 것과 동일한 방식으로 GPU를 요청합니다.

이 두 오퍼레이터를 설치하면 GPU는 최고 수준의 쿠버네티스 리소스가 됩니다. 수동 드라이버 설치, 특수 호스트 구성 또는 사용자 지정 커널 모듈이 필요하지 않습니다. 엣지에 단일 GPU 노드가 있든 데이터센터에 클러스터가 있든 동일한 접근 방식이 적용됩니다.

이러한 기반 위에 STAC-AI 오퍼레이터를 추가하여 벤치마크 자체를 오케스트레이션했습니다.

STAC-AI 오퍼레이터

STAC-AI 벤치마크를 엔드 투 엔드로 실행하려면 모델을 목표 정밀도로 양자화하고, GPU 클록 및 전력 제한을 설정하고, 여러 워크로드 및 도착 속도 전반에서 벤치마크 하네스를 실행하고, 각 실행과 동기화하여 전력과 온도 추적을 수집하고, 마지막으로 참조 모델에 대한 충실도 분석을 실행하는 등 많은 과정이 포함됩니다. 이 모든 작업을 수동으로 수행하면 시간이 많이 소요되고 오류가 발생하기 쉬우며 재현하기 어렵습니다. STAC-AI 오퍼레이터는 전체 워크플로를 선언형으로 만듭니다.

사용자 지정 리소스

오퍼레이터는 3가지 사용자 지정 리소스 정의(CRD)를 도입합니다.

• Implementation은 사용 가능한 LLM 백엔드(예: TensorRT-LLM)를 컨테이너 이미지, 지원되는 모델 및 데이터세트와 함께 등록합니다.
• BenchmarkRun은 기본 리소스입니다. 사용할 구현, 테스트할 모델 및 데이터세트, 양자화 방법, GPU 할당, 사후 처리 충실도 분석 실행 여부 등 단일 벤치마크 실행을 선언합니다. 오퍼레이터가 그 이후의 모든 과정을 처리합니다.
• BenchmarkImageBuild는 TensorRT-LLM 스택에 대한 일회성 컨테이너 이미지 빌드를 관리합니다.

라이프사이클 관리

BenchmarkRun이 생성되면 오퍼레이터가 상태 머신을 통해 이를 구동합니다.

Pending → Queued → Initializing → Quantizing → Building → Running → RunCompleted → PostProcessing → Completed

각 단계에서 오퍼레이터는 쿠버네티스 잡(Job)을 생성하여 작업을 수행합니다. 또한 nvidia-smi를 사용하여 최대 GPU 클록 속도와 전력 제한을 자동으로 검색하여 적용하고, 한 번에 하나의 벤치마크만 실행되도록 순차 실행 대기열을 관리하여 실행 간 GPU 경합을 방지하며, vLLM을 참조로 사용하여 충실도 분석 단계를 처리합니다. 단계가 실패하면 실행이 원인 코드와 함께 Failed 상태로 전환되므로 진단이 간단해집니다.

벤치마크 실행

감사된 워크로드를 실행하는 데 필요한 사항은 다음과 같습니다.

apiVersion: stac.ai/v1alpha1
kind: BenchmarkRun
metadata:
  name: stac-rtxpro6000-8b-e4a-batch
  namespace: stac-ai
spec:
  implementation: tensorrt-llm
  model: llama-3.1-8b
  dataset: edgar4a
  sut: RTXPRO6000-8B-E4a-Batch
  sutConfig:
    configMapName: sut-tensorrt-llm-rtxpro6000-batch
    key: RTXPRO6000-8B-E4a-Batch.yaml
  config:
    quantization: NVFP4
    gpuCount: 2
    useExecutor: false
  postProcessing:
    fidelity: true
  storage:
    workspacePVC: stac-workspace-pvc
    modelCachePVC: stac-model-cache-pvc
    logsPVC: stac-logs-pvc

이 YAML이 사용자 상호 작용의 전부입니다. 이를 적용하면 오퍼레이터가 모델 양자화, GPU 튜닝, 벤치마크 실행, 전력 및 온도 캡처, 충실도 분석을 처리합니다. 워크로드별 매개변수(배치 크기, 시퀀스 길이, 도착 속도)는 ConfigMap을 통해 주입되므로 컨테이너 이미지를 다시 빌드하지 않고도 다양한 구성을 테스트할 수 있습니다.

전체 STAC-AI LANG6 제품군을 실행하기 위해 7가지 워크로드를 모두 정의하는 SUT 구성을 참조하는 단일 BenchmarkRun을 적용했습니다. 이러한 방식으로 오퍼레이터는 사용자 지정 리소스에 정의된 대로 벤치마크 하네스를 시작하고, 하네스는 SUT 구성에 정의된 대로 각 워크로드를 순차적으로 실행합니다. 전력 및 유입 공기 온도는 요꼬가와 WT1804R 정밀 전력 분석기(벤치마크 포드에서 VXI-11/SCPI를 통해 쿼리)와 USB 직렬 연결된 Dallas DS18B20 프로브를 통해 각 측정 기간 동안 캡처됩니다.

결과

표 2와 3의 감사 결과는 공식 STAC 보고서에서 발췌한 것입니다. 모든 워크로드는 FP8 KV 캐시를 사용하여 NVFP4로 양자화되었으며, 각 GPU는 독립적인 모델 인스턴스를 실행했습니다.

표 2. 배치 모드 결과

표 3. 인터랙티브 모드 결과(가장 높은 지속 도착 속도)

감사 결과를 통해 확인할 수 있는 몇 가지 사항은 다음과 같습니다.

• 2U 폼 팩터가 제공하는 강력한 공간 효율성입니다. STAC 보고서에 따르면, 2U SYS-222C-TN은 단 2개의 GPU만으로 보고된 전체 워크로드 세트를 완료하면서, 비교 가능한 모든 워크로드에서 더 큰 NVIDIA GH200 시스템보다 높은 배치 공간 효율성을 제공했습니다(EDGAR4a에서 ft³·시간당 950만 1,000단어 대 614만 8,000단어, EDGAR4b에서 142만 8,000단어 대 79만 9,500단어, EDGAR5a에서 23만 7,400단어 대 22만 6,900단어).
• NVFP4는 70B 모델을 단일 GPU에서 원활하게 구동할 수 있게 합니다. Llama-3.1-70B-Instruct를 NVFP4로 양자화하면 온디스크 모델 크기가 약 35GB로 줄어들어, KV 캐시를 위한 충분한 여유 공간을 확보하면서 단일 RTX PRO 6000의 96GB 메모리에 충분히 수용할 수 있습니다. 각 GPU는 독립적인 모델 인스턴스를 실행하며, 두 GPU 모두 배치 및 인터랙티브 워크로드에서 동시에 사용됩니다.

STAC-AI 오퍼레이터는 이러한 모든 실행을 담당했습니다. 전체 제품군에 대한 SUT 구성을 참조하는 BenchmarkRun 사용자 지정 리소스를 적용했으며, 오퍼레이터가 추가 개입 없이 양자화, 튜닝, 실행, 사후 처리를 처리했습니다.

LLM 추론에 Red Hat OpenShift를 선택해야 하는 이유

컨테이너화된 플랫폼이 성능에 민감한 워크로드에 영향을 미치는 오버헤드를 유발하는지에 대한 질문을 자주 받습니다. 이번 감사 결과는 LLM 추론에 대해 다음과 같은 강력한 시사점을 제공합니다. 즉, 플랫폼이 아닌 GPU가 병목 현상의 원인으로 보이며, OpenShift의 컨테이너 런타임이나 스케줄링이 추론 파이프라인에 유의미한 오버헤드를 추가한다는 증거는 데이터상으로 확인되지 않습니다. 보고서에 담긴 STAC의 자체 논평도 다음과 같이 일치합니다: "컨테이너 및 오케스트레이션 계층은 실제 환경에서 중대한 성능 제한을 초래하지 않는 것으로 보입니다." 이전에 감사를 거친 STAC-N1(네트워크) 및 STAC-A2(GPU 컴퓨팅) 결과와 함께, 이는 OpenShift가 까다로운 금융 워크로드에 대해 조직이 베어메탈에서 기대하는 성능을 제공할 수 있다는 관점을 강화하는 세 번째 데이터 포인트입니다.

하지만 OpenShift에서 실행하는 것의 진정한 가치는 단순한 성능 그 이상입니다. 프로덕션 금융 서비스 환경에서는 보안 정책, 역할 기반 액세스 제어, 감사 로깅, 라이프사이클 관리, 멀티테넌시도 필요합니다. OpenShift는 이 모든 기능을 즉시 제공합니다. 베어메탈과 유사한 성능과 엔터프라이즈급 운영 중 하나를 선택할 필요가 없습니다.

또한 GPU 워크로드를 실행하기 위해 별도의 스택을 구축할 필요도 없습니다. 이 벤치마크를 실행한 동일한 클러스터에서 애플리케이션 워크로드, 가상화, 배치 작업, CI/CD 파이프라인을 함께 실행할 수 있습니다. 모두 동일한 운영 팀, 동일한 관측성 환경, 동일한 보안 정책 하에 실행됩니다. 이미 OpenShift를 운영 중인 팀은 별도의 운영 환경을 구축하지 않고도 GPU 추론 플랫폼을 도입할 수 있습니다.

이 벤치마크에 사용된 오퍼레이터 패턴은 벤치마크 제품군이든 프로덕션 LLM 서비스든 관계없이, 복잡한 GPU 워크로드를 선언적인 쿠버네티스 네이티브 API를 통해 관리할 수 있다는 더 광범위한 요점을 시사합니다. 사용자가 원하는 사항(모델, 양자화, 데이터세트)을 정의하면 오퍼레이터가 이를 제공하는 방법을 결정합니다. 이 패턴은 단일 노드 테스트 환경에서 다중 노드 프로덕션 클러스터로 동일한 방식으로 확장됩니다.

이는 Red Hat OpenShift AI가 구축되는 방식이기도 합니다. Red Hat OpenShift AI는 동일한 노드 기능 검색 및 NVIDIA GPU 오퍼레이터, 동일한 nvidia.com/gpu 리소스 모델, 그리고 클라우드, 온프레미스, 엣지 전반에서 모델 개발, 훈련, 서빙, 모니터링을 관리하기 위한 동일한 오퍼레이터 패턴을 갖춘 코어 OpenShift에서 실행됩니다. 이 벤치마크를 실행한 인프라는 기본 토대를 변경하지 않고도 프로덕션 AI 플랫폼으로 직접 확장됩니다.

GPU 관리도 마찬가지로 간소화됩니다. 노드 기능 검색 및 NVIDIA GPU 오퍼레이터는 클러스터 전반에서 하드웨어 검색, 드라이버 라이프사이클, 리소스 스케줄링을 처리합니다. 새로운 GPU 노드를 추가하려면 오퍼레이터를 설치하기만 하면 되며, 나머지는 자동으로 수행됩니다. 여기에 사용된 것과 같은 단일 노드 OpenShift 클러스터, 지점에 적합한 3노드 컴팩트 클러스터, 엣지의 원격 작업자 노드 또는 지역 데이터센터의 다중 노드 클러스터 전반에서 동일한 배포 모델이 변경 없이 실행됩니다. 이 블로그 포스트의 어떠한 YAML도 이러한 환경을 대상으로 하기 위해 변경할 필요가 없습니다.

마지막으로, 이 프로젝트의 모든 벤치마크 실행은 버전 제어되는 YAML로 정의됩니다. 모든 구성은 재현 가능합니다. STAC에서 독립적인 감사를 수행했을 때, Red Hat은 동일한 리소스를 적용하여 정확히 동일한 환경과 결과를 재현했습니다. 이러한 수준의 재현성은 쿠버네티스 배포 모델의 자연스러운 결과이며, 벤치마크 제출뿐만 아니라 프로덕션 워크로드에도 매우 유용합니다.

결론

이러한 감사 결과는 Red Hat OpenShift가 금융 서비스 기업이 AI 인프라를 평가하는 데 사용하는 LLM 추론 워크로드를 실행할 수 있음을 보여주며, 플랫폼 오버헤드가 GPU 성능을 저해한다는 징후는 나타나지 않았습니다. 기존의 STAC-N1 및 STAC-A2 결과와 결합하여, 조직이 동일한 OpenShift 플랫폼에서 가장 까다로운 워크로드를 베어메탈급 성능으로 실행할 수 있다는 일관된 결론을 뒷받침합니다.

전체 감사 결과는 STAC 웹사이트에서 확인할 수 있습니다. TensorRT-LLM 구현 및 SYS-222C-TN 하드웨어 플랫폼에 대한 추가 논평은 NVIDIA의 이 블로그 포스트를 확인하세요.