Task-specialized LLM을 위한 비용 효율적인 서빙 전략: AWS Inferentia2와 Hugging Face Optimum을 활용한 자체 개발 LLM 서빙하기

한때 AI 엔지니어와 많은 연산 자원이 있어야 가능했던 다양한 자연어 처리 작업(task)을 대규모 언어모델(LLM)에 프롬프트 명령 한 줄을 입력하는 것만으로 가능해진 시대가 됐습니다. 텍스트 분류 혹은 QA, 요약, 스타일 변환, 기계번역과 같은 전통적인 자연어 처리 작업들에서 뿐만 아니라 코딩, 수학 문제풀이와 같은 추론 능력이 필요한 작업들에서까지 놀라운 성능을 보이고 있습니다.

Claude3 와 GPT4 같은 고성능의 LLM을 API로 출시하면서 수많은 기업과 조직에서는 손쉽게 다양한 작업(task)에 LLM을 활용할 수 있게 됐습니다. 하지만, 고객의 개인정보나 민감한 정보를 활용하는 작업에서는 데이터의 저장(Rest) 및 전송(Transit)에 있어 정보 유출의 위험이 있습니다. 그리고 특정 작업 수행을 위해 반복적인 호출을 해야 하는 경우에는 그 요청 수만큼 선형적으로 비용이 증가하여 요청이 많아지면 비용을 감당하기 어렵습니다. 그 외에도 커스터마이징이 어렵고 API 사용을 위한 별도의 버전 관리가 필요하기 때문에 직접 제어할 수 있는 자체 LLM 개발에 대한 니즈가 증가하고 있습니다.

본 포스팅을 통해 독자들은 아래의 내용과 관련된 인사이트를 얻을 수 있을 것으로 기대됩니다.

• 금융 분야와 같은 데이터 민감성이 높은 환경에서의 특정 작업에 최적화된 LLM을 사용함으로써 반복적인 AI 작업 수행에 따른 비용 절감 방법
• AWS Inferentia2를 이용한 비용 효율적인 추론을 위한 실험 내용 및 결과
• Hugging Face Optimum을 활용해 LLM을 Inferentia2에 최적화하는 방법

금융권 폐쇄망 환경에서의 Task-specialized LLM 개발 필요성

데이터 보안과 규제 준수의 중요성

금융권은 데이터 보안과 개인정보 보호에 대한 엄격한 규제를 받는 분야입니다. 특히, 폐쇄망 환경에서는 인터넷과 격리된 네트워크를 사용하여 외부로부터의 데이터 유출 위험을 최소화합니다. 이러한 환경에서는 클라우드 기반의 API 서비스 접근이 제한되거나 불가능합니다. 시스템 보안 및 정보보호가 중요한 워크로드에서는 금융 기관은 대규모 언어모델(LLM)을 활용한 자연어 처리 기능을 내부적으로 구축하고 운영할 필요가 있습니다.

금융 데이터는 민감한 개인 정보를 포함하고 있어 서비스를 개발하고 운영하려면 국내의 정보보호 관련 법규 등 다양한 법적 요구사항을 준수해야 합니다. 고객의 특성이나 금융 자산 정보와 같은 데이터는 접근 권한이 제한된 폐쇄망 내에서 처리되어야 하며, 이를 활용할 때에도 각별한 주의가 필요합니다. 생성형AI에 입력으로 제공되는 데이터에 대한 보호를 위해 금융 기관들은 내부 데이터 센터나 폐쇄망 환경에 최적화된 LLM 모델을 자체 개발해야 할 필요가 있습니다.

금융 도메인의 특성을 살린 Task-specialized LLM 개발에 대한 요구 증가

금융 서비스의 사용자들은 점점 더 맞춤화된 서비스를 요구하고 있습니다. 투자 조언, 신용 평가, 리스크 관리 등과 같은 금융 특화된 서비스를 효과적으로 제공하기 위해서 도메인 혹은 특정 업무에 특화된 언어 이해 능력을 가진 LLM을 직접 개발하는 사례들이 증가하고 있습니다.

그리고 대출 신청서의 자동 검토, 거래 이상 탐지 보고서 작성과 같은 금융 업무에서는 비교적 크기가 작은 Task-specialized LLM을 통해서도 이를 처리할 수 있습니다. 이러한 모델은 특정 작업에 최적화되어 있어 필요한 연산 리소스와 처리 시간을 줄이면서도 높은 정확도를 제공할 수 있다는 특징이 있습니다.

보안이 뛰어난 클라우드 기반 폐쇄망을 이용한 LLM 서빙 가능

AWS 환경에서는 국내 금융권 규제를 준수하여 안전한 폐쇄망을 구성할 수 있는 기술들을 제공하고 있습니다. 특히 아래와 같은 요소들이 있어 신뢰할 수 있는 클라우드 기반 안전한 폐쇄망 구성이 가능합니다.

• AWS Direct Connect: 고객사 데이터센터와 AWS간에 Private 전용 네트워크를 이용해서 연결
• Amazon VPC / Private Subnet: AWS VPC를 이용해서 AWS Cloud내에서 고객사 전용 네트워크 망을 구성할 수 있습니다. 그리고 Private subnet을 이용해서 인터넷이 차단된 subnet을 구성할 수 있습니다.
• Multi Availability Zone: AWS는 하나의 리전에 복수개의 AZ를 제공하기 때문에 한 지역의 장애가 발생하더라도 서비스가 지속될 수 있는 안전한 서비스 가용성을 제공합니다.
• AWS Neuron 기반의 AWS Inferentia2 EC2: AWS Inferentia2 EC2를 위에서 구성한 Private subnet에 구성할 수 있습니다. 이를 통해서 고객사 데이터센터와 private 통신으로 머신러닝 추론 아키텍처를 구성할 수 있습니다.

이를 도식화하면 아래와 같은 형태의 안전한 클라우드 폐쇄망에서 LLM을 서빙할 수 있는 아키텍처가 됩니다.

그림1. 금융권 클라우드 기반 폐쇄망에서의 LLM 서빙 아키텍처 예시

Task-specialized LLM의 경제적 효율성 및 비용 절감 전략

Claude 3 Opus, GPT-4 수준의 성능을 보여주는 Task-specialized LLM의 가능성

Task-specialized LLM은 뉴스요약, 기계번역과 같이 특정 작업(task)을 수행하기 위해 설계된 모델로 상대적으로 모델의 크기가 작고 복잡도가 낮아 적은 양의 학습 데이터와 연산 자원으로도 개발이 가능한 LLM입니다. 크기는 다소 작지만 특정 작업을 수행할 수 있는 능력을 가진 LLaMA, Mistral과 같은 오픈소스 LLM을 활용한 연구와 개발이 활발하게 이루어지고 있습니다.

그림 2. Task-specialized LLM

최근 다양한 연구 및 오픈소스 커뮤니티의 보고에 따르면, 오픈소스 LLM에 대한 미세조정 학습(fine-tuning)을 통해 Claude 3 Opus, GPT-4와 같은 상용 모델의 수준에 근접하는 혹은 이를 뛰어넘는 성능을 달성할 수 있다고 합니다. Code나 Vision QA와 같은 특화된 작업 영역에서는 GPT-4의 대안으로 오픈소스 모델을 사용하는 것이 흔하지 않은 광경이기도 합니다.

최근 7B의 작은 사이즈의 모델도 적절한 미세조정 학습을 통해 훨씬 크고 강력한 모델들과 비교하여 우수한 성능을 낼 수 있다는 연구가 있습니다. Base 모델을 기준으로는 미세조정 학습 전에 GPT-4와 GPT-3.5가 가장 높은 성능을 보여주었지만, 파인 튜닝을 통해 대부분의 모델 성능이 크게 향상되었다고 합니다. 31개의 작업에서 task-specialized LLM이 GPT-4보다 전반적으로 높은 성능을 보여주었습니다 (0.756 대 0.661).

고성능의 Fine-tuned LLM은 특히 금융 분야와 같이 일관된 모델의 결과가 필요하고 신속한 데이터 처리가 요구되는 환경에서 유용하게 활용될 수 있습니다. 작은 모델로도 큰 모델들과 경쟁할 수 있는 성능을 발휘하도록 한다면 금융 기관들은 큰 투자 없이도 고품질의 AI 솔루션을 비즈니스에 도입할 수 있습니다.

Fine-tuned Task-specialized LLM 활용의 경제적 이점

금융 기관이 Task-specialized LLM을 직접 운용할 경우, 여러 경제적 이점이 있습니다. 우선, fine-tuned 모델을 사용하면 특정 금융 작업에 대한 처리 효율성이 증가합니다. 반복되는 작업을 자동화하고, 오류율을 낮추며, 처리 시간을 단축시킬 수 있습니다. 그리고 모델의 개발과 운영을 위해 초기 비용이 발생하지만 작업 수행을 위해 많은 요청이 필요한 경우에는 Task-specialized LLM을 직접 운영하면 전체적인 비용은 줄어듭니다.

예를 들어, 텍스트 요약과 같은 작업 수행을 위해서 평균 입력으로 5,000토큰, 출력으로 500토큰이 필요하다고 해봅시다. 약 1,000명의 사용자가 이 작업을 1년 250 영업일에 매일 10번 수행한다고 가정하면, 250만 번의 요청을 하게 됩니다. 이를 Claude 3 혹은 GPT-4와 같은 범용(General-purpose) LLM을 사용한다면 각 3.8억원, 2.2억원의 비용이 발생합니다. 만약 Fine-tuned 모델을 Hugging Face의 Inference Endpoints와 같은 서비스를 사용하여 직접 배포한다면, 시간 당 $4의 NVIDIA A100 GPU 인스턴스로 처리 가능하며 약 0.3억원의 비용이 발생하게 됩니다. Fine-tuned 모델이 상용 모델과 비슷한 성능 수준을 담보할 수 있다면 적게는 7배에서 많게는 13배까지 비용이 줄어듭니다. 물론 개발에 소요되는 시간과 비용을 고려한다면 전체 비용은 비슷하거나 더 많을 수도 있습니다. 따라서 사전에 비용효율 분석을 하여 적절한 방법을 선택하는 것이 좋습니다. 그리고 특정 작업 만을 위해 연간 3천 만원에 달하는 운영 비용은 작은 규모의 기업이나 조직에게는 여전히 부담스러운 가격입니다.

그림3은 요청 수에 따른 비용의 변화를 보여줍니다. 범용 LLM은 요청 수가 증가할수록 비용이 선형적으로 증가하는 반면, 특정 작업에 특화된 모델(Task-specialized LLM)은 초기 개발 비용이 들지만 이후 운영 비용이 적게 들어 장기적으로 비용 효율적일 수 있음을 시사합니다.

그림 3. General-purpose LLM vs. Task-specialized LLM

AWS 전용 하드웨어 최적화를 통한 비용 절감

GPU 기반의 워크로드로 인한 높은 비용을 감소시키기 위해 인공지능 모델 추론 전용 하드웨어를 활용할 수 있습니다. AWS Inferentia2와 같은 AI 추론 전용 칩은 고성능 처리가 필요한 대규모 모델에 특히 유리하며, 전력 소비와 비용을 크게 절감할 수 있습니다. 일반적인 사용환경에서는 GPU 대비 더 높은 처리량과 더 낮은 지연 시간을 제공하며, 비용 효율적인 확장성을 가능하게 합니다. 이를 통해 금융 기관은 더 많은 데이터와 복잡한 계산을 처리할 수 있으며, 클라우드 서비스 비용을 절감하면서도 실시간 데이터 처리 요구를 충족할 수 있습니다.

AWS Inferentia2 & Hugging Face Optimum

AWS Inferentia2는 고성능 딥러닝 모델 추론을 위해 설계된 인스턴스로, 최대 2.3 페타플롭스의 연산 능력과 384GB의 고속 메모리를 제공합니다. NeuronLink 인터커넥트를 통해 각 가속기 간의 빠른 통신을 지원하여 대형 모델의 분산 추론 성능이 향상되었고, TF32와 BF16 ,UNIT8 등 다양한 데이터 타입을 지원합니다. 또한, dynamic input shape을 지원하여 최신 Generative AI 모델을 유연하게 배포할 수 있도록 설계되었습니다.

AWS Inferentia2에서의 모델 추론을 위해서는 별도의 컴파일이 필요하며 본 포스팅에서는 Hugging Face의 Optimum을 사용합니다. Optimum은 CPU나 GPU 외의 다른 하드웨어에서 모델을 훈련하고 추론할 때에도 Transformers와의 동일한 사용성을 제공하기 위해 개발된 프레임워크입니다.

Hugging Face Optimum Neuron은 AWS에서 제공하는 전용 칩인 AWS Trainium과 AWS Inferentia를 위해 고안된 프레임워크입니다. PyTorch로 작성된 모델을 Inferentia2에 최적화된 형태로 변환이 가능하고 커스텀 연산자 또한 지원합니다. Optimum Neuron을 사용하면, 모델 빌드 및 배포 과정이 간소화되어 개발자들은 복잡한 설정 없이 단 몇 줄의 코드로 모델을 Inferentia2에 최적화하고 AWS의 CI/CD 도구들과 쉽게 통합할 수 있습니다. 모델 개발부터 배포까지의 전체 과정을 자동화 할 수 있고, Hugging Face Optimum과 AWS Inferentia2의 시너지를 통해 개발자들은 고성능 AI 추론 시스템을 더욱 쉽고 효율적으로 구축할 수 있습니다.

본 포스팅에서는 LLaMA, Mistral과 같은 LLM에 미세조정 학습을 한 task-specialized LLM을 서빙할 때 AWS Inferntia2를 사용해 비용을 줄일 수 있는지 테스트해 보았습니다.

그림 4. Reducing cost with AWS Inferentia2

Task-specialized LLM 추론 성능 실험 및 비교분석

Amazon EC2 g5.xlarge와 Amazon EC2 inf2.xlarge의 추론 성능을 비교하기 위해 사용한 모델은 특정 task를 수행하기 위해 미세조정 학습을 한 7B 크기의 LLM입니다. 해당 task 수행에는 입력 토큰이 평균 3,107개 사용되고 출력 토큰으로 평균 350개에서 400개 정도 생성됩니다. 이 모델을 bfloat16 으로 사용할 경우 필요한 최소 메모리는 약 14GB (2 bytes * 7B parameters)이지만, 입력 시퀀스의 길이가 평균 4천 개이고 KV caching 과정에서의 메모리 추가로 실제로는 이보다 더 많은 메모리를 필요로 합니다. 따라서 이를 만족하는 GPU 인스턴스 중에서 가장 저렴한 g5.xlarge를 비교 대상으로 하였습니다.

Hugging Face Optimum-nueron을 활용한 모델 컴파일 & 저장

AWS Inferentia2에서 모델을 추론하기 위해서는 먼저 모델을 Inferentia2 칩에 최적화된 모델로 컴파일해야 합니다. AWS Neuron SDK를 통해 컴파일하는 방식이 일반적이나, Inferentia2는 Decoder 모델의 경우 transformers-neuronx와 optimum-neuron 등의 다른 프레임워크를 사용해서 좀 더 편리하게 모델을 컴파일할 수 있습니다. 컴파일은 Inferentia2 혹은 Trainium 인스턴스에서 수행해야 합니다.

optimum-neuron 을 활용해 모델을 컴파일하기 위한 코드는 다음과 같습니다.

from optimum.neuron import NeuronModelForCausalLM

# 컴파일을 위한 인자 설정
compiler_args = {"num_cores": 2, "auto_cast_type": 'bf16'}
input_shapes = {"batch_size": 1, "sequence_length": 4096}

# 사전학습한 모델을 불러오고 설정한 값에 따라 컴파일을 수행 요청
model = NeuronModelForCausalLM.from_pretrained(
    model_id="finetuned-model-name-or-path",
    export=True,
    **compiler_args,
    **input_shapes
)
# 컴파일된 모델을 저장
model.save_pretrained("compiled-model-name-or-path")

학습한 모델을 불러올 때 export=True 를 설정함으로 컴파일할 수 있습니다. 내부적으로는 neuronx 컴파일러가 모델을 XLA subgraph로 먼저 변환한 후에 NEFF (Neuron Executable File Format)로 컴파일하게 됩니다. Hugging Face Hub에 등록된 다수의 모델 아키텍처의 컴파일을 지원하고 있습니다.

하나의 Inferentia2 칩에는 두 개의 neuron core가 있고 각 core는 16GB 메모리를 가지고 있습니다. 테스트에 사용하는 모델은 16GB를 넘게 사용하기 때문에 2개의 core 모두 사용해야 합니다. 컴파일을 위한 인자 설정 값으로 2를 전달 하였습니다.

그림 5. Exporting standard models using optimum-neuron

모델을 컴파일할 때에는 엑셀러레이터 메모리와 RAM을 함께 사용하기 때문에 모델의 크기를 고려해서 적절한 AWS Inferentia2 혹은 Trainium 인스턴스에서 컴파일을 진행해야 합니다. 처음 컴파일을 시도하였을 때, 4 vCPU, 16GB의 RAM이 있는 inf2.xlarge 인스턴스에서 진행하였습니다. 이때, RAM 부족으로 인해 서버가 다운되는 현상이 관찰되었고, 32 vCPU, 128GB의 RAM이 있는 inf2.8xlarge로 변경하고 컴파일을 완료할 수 있었습니다.

from transformers import AutoTokenizer

# 컴파일된 모델을 저장한 경로에 토크나이저를 함께 저장
AutoTokenizer.from_pretrained("finetuned-model-name-or-path").save_pretrained("compiled-model-name-or-path")

컴파일한 모델 추론 테스트

컴파일한 모델을 AWS Inferentia2 칩에서 추론을 했을 때 올바르게 결과가 생성되는지를 확인하기 위해서 테스트를 하였습니다. optimum-neuron을 사용하면 컴파일된 모델을 쉽게 불러올 수 있습니다.

# 토크나이저와 컴파일된 모델을 불러오기
tokenizer = AutoTokenizer.from_pretrained(compiled_model_path)
model = NeuronModelForCausalLM.from_pretrained(compiled_model_path)

# 테스트 케이스
text = [{"role": "user", "content": system_prompt + user_prompt}]
inputs = tokenizer.apply_chat_template(text, add_generation_prompt=True, return_tensors='pt')

# 추론
outputs = model.generate(inputs, max_new_tokens=1024,)
print(tokenizer.batch_decode(outputs[inputs.shape[1]:], skip_special_tokens=True)

AWS Inferentia2가 이전 세대의 칩과는 다르게 dynamic shape을 지원하고 있어 decoder 모델 외에도 T5와 같은 encoder-decoder 모델도 활용할 수 있습니다. 그리고 허깅페이스 transformers에서처럼 generate() 함수를 사용하여 추론을 할 수 있습니다. do_sample, max_length, temperature와 같은 인자들을 모델의 추론 시 설정 값을 전달하여 모델 디코딩 시에 생성 토큰을 제어할 수 있습니다.

g5.xlarge vs. inf2.xlarge 추론성능 비교분석

Hugging Face Text Generation Inference를 통한 모델 서빙 및 테스트

테스트를 진행한 시점인 2024년 5월에는AWS Inferentia2를 서울 리전에서 제공하지 않아 성능 비교를 위해서 버지니아 북부 리전에서 테스트를 수행했습니다. 각 하드웨어 인스턴스에서 모델을 서빙하고 동일한 리전에 위치한 별도의 EC2 인스턴스에서 각 하드웨어 인스턴스의 엔드포인트를 호출하도록 하였습니다. 테스트를 위한 세부방법과 코드는 허깅페이스 테크 리더의 글을 참고하였습니다. 참조한 글에서처럼 특정 시간 구간 동안 동시접속 사용자 5명이 총 100번 연속적으로 호출을 요청하는 시나리오를 가정하였습니다.

AWS Inferentia2 인스턴스와 g5.xlarge 인스턴스를 비교하기 위해, 허깅페이스의 Text Generation Inference를 서빙 프레임워크로 사용하였습니다. Text Generation Inference (TGI)는 LLM을 배포하고 서빙하기 위한 툴킷으로 다양한 LLM 아키텍처를 지원하고 있고 여러 하드웨어 환경에서도 프로덕션 레벨의 서빙을 할 수 있도록 기능들을 지원하고 있습니다. 허깅페이스에서 개발한 툴킷인 만큼 문서화가 잘 되어있고 다른 허깅페이스의 프레임워크와도 호환성이 좋아 AWS Inferentia2 인스턴스에서 모델 서빙을 쉽게 할 수 있습니다.

그림 6. Text Generation Inference (출처: Hugging Face TGI)

LLM 추론 성능 분석을 위한 지표 및 방법

동일한 인스턴스를 사용하더라도 모델 추론 시 배치(batch) 크기에 따라 성능이 달라질 수 있기 때문에 배치 크기에 따른 성능을 비교하였습니다. 그리고 성능 측정을 위한 척도로는 TTFT, TPOT, Latency 그리고 Throughput 값을 사용하였고 각 척도의 상세는 다음과 같습니다:

• Time To First Token (TTFT): 요청을 받은 시점에서 첫 출력 토큰이 생성되기까지 걸리는 시간으로 prefill 단계에서 입력 토큰에 대한 attention을 계산하고 첫 토큰 생성 시점까지의 시간. 샘플링 및 디코딩 과정이 거의 없어 하드웨어 가속기별로 최적화 정도에 따라 성능의 차이가 나타남. (단위: 초)
• Time Per Output Token (TPOT): 첫 출력 토큰이 생성된 시점으로부터 마지막 출력 토큰이 생성되는데까지 걸린 시간. (단위: 초)
• Latency: 요청이 완료되어 응답을 받기까지의 시간으로 TTFT와 TPOT를 합한 전체 시간과 비슷하며 짧을수록 성능이 더 좋음. (단위: 초)
• Throughput: 초당 생성하는 토큰의 수를 의미하며 생성된 토큰의 수를 Latency로 나눈 값으로 높을수록 성능이 더 좋음. (단위: 토큰 수/초)

AWS Neuron 공식 문서에 따르면 작은 배치 사이즈에서 시작해서 점점 크기를 키워가며 모델을 컴파일하고 최고의 throughput이 나오는 지점을 찾으라고 권고하고 있습니다. 최대 시퀀스 길이가 4,096인 테스트 조건 아래에서 inf2.xlarge 인스턴스의 엑셀러레이터 메모리는 32GB로 배치 크기 16까지 그리고 g5.xlarge 인스턴스의 GPU 메모리는 24GB로 배치 크기 4까지 서빙이 가능했습니다. 이는 AWS Inferentia2의 메모리가 8GB가 더 많고, 출력 토큰이 약 350개 정도로 전체 시퀀스 길이에 비해 상대적으로 작은 토큰을 생성하였기 때문에 더 많은 배치 크기를 사용할 수 있었습니다.

인스턴스별 성능 측정 결과 분석

g5.xlarge 인스턴스는 배치 크기 1에서 4까지 테스트하였으며, 배치 크기 8에서는 메모리 초과(OOM) 오류가 발생했습니다. 배치 크기 1에서 4까지 Latency와 Throughput은 안정적으로 유지되었으나, 큰 차이는 보이지 않았습니다. Latency는 배치 크기에 따라 약간 증가했으나, Throughput은 거의 일정하게 유지되었습니다. inf2.xlarge 인스턴스는 배치 크기 1에서 16까지 테스트하였고 배치 크기 4에서의 Latency가 가장 짧았고 모든 지표에서 가장 좋은 성능을 보여주었습니다. inf2.xlarge의 성능이 g5.xlarge와 비교해서는 수치가 낮게 나왔습니다. AWS Inferentia2에서 모델을 배포할 때에는 운영 시나리오에 따라 사전에 적정한 배치 크기와 배포 방법을 찾는 것이 중요할 것으로 보입니다.

배치 크기에 따른 성능 측정 결과는 아래와 같습니다.

g5.xlarge ($1.0/hour)

inf2.xlarge ($0.76/hour)

이 글을 작성하는 시점에서 Text Generation Inference이 AWS Neuron 백엔드에서 지원하는 기능의 범위가 CUDA와 CPU 백엔드와 달라 성능 결과가 다르게 나타난 것으로 보입니다. 예를 들어, 위의 표에서 측정 지표인 TTFT를 보면 inf2.xlarge는 배치 사이즈 4까지 늘려갔을 때 오히려 속도가 빨라지는 패턴을 보이고 배치 사이즈를 다시 늘렸을 때 예상대로 속도가 느려졌습니다. 이는 정적 배치와 KV 캐시를 재구성하는 방식에서 차이가 있어 AWS Inferentia2에서 prefill을 처리하는 시간이 GPU와는 다른 양상을 보인 것으로 해석됩니다. AWS Inferentia2 칩에 대해 더욱 최적화된 다른 방식으로 테스트를 한다면 결과가 다르게 나올 가능성은 있습니다.

실험 결과를 통해 주목할 점은 inf2.xlarge($0.76/hour)가 g5.xlarge($1/hour)에 비해 훨씬 낮은 비용으로 더 높은 배치 크기를 지원하면서도 준수한 성능을 보여준다는 것입니다. 이는 비용 대비 성능 측면에서 유리한 결과를 나타내며, 특히 대규모 배치 처리가 필요한 워크로드에서 경쟁력 있는 선택이 될 수 있습니다.

인스턴스별 비용 효율성 분석

어느 인스턴스 타입이 더 비용 효율적인지 추가적으로 분석을 해보았습니다. 먼저 한 명의 사용자가 매일 5,500 토큰을 사용한다고 가정해봅시다. 이때, 250 영업일 기준으로 한 명의 사용자를 위해 처리해야 하는 연간 토큰의 수는 138만이 됩니다. (138만 토큰 = 요청 당 5,500 토큰 * 1회 요청 * 250 영업일) 그리고 위의 실험결과에 따라 인스턴스 타입별로 연간 처리 가능한 토큰을 계산해보면 g5.xlarge는 4억 6,665만 토큰이고 inf2.xlarge는 3억 7,368만 토큰입니다.

• g5.xlarge: 4억 6,665만 토큰 = 21.6 토큰/초 * 24시간 * 250 영업일
• inf2.xlarge: 3억 7,368만 토큰 = 17.3 토큰/초 * 24시간 * 250 영업일

그 다음으로는 각 인스턴스가 연간 처리 가능한 총 토큰 수에 한 사용자 당 연간 토큰의 수를 나누면 인스턴스 별로 한 명 사용자에 대한 처리 가능한 요청의 수는 g5.xlarge는 338회/일, inf2.xlarge는 270회/일입니다. (338회 = 4억 6,665만 / 138만) 250일을 기준으로 인스턴스 비용은 g5.xlarge는 $6,000이고, inf2.xlarge는 $4,560으로 한 명 사용자 당 예상 연간 비용은 아래 표와 같습니다.

마지막으로 사용자의 서비스 요청 횟수(Number of Requests per day)의 증가에 따라 운영에 필요한 인스턴스 수를 계산하여 요청 수가 증가함에 따라 각 인스턴스별로 운영 비용이 어떻게 변화하는지를 아래 그림과 같이 시각화하였습니다. 사용자의 요청량이 1일 1회에서 약 5,000회까지 증가했을 때 이를 위한 필요 인스턴스 수에 따른 총 연간 비용을 계산한 결과입니다. 예를 들어, g5.xlarge에서 사용자의 요청량이 1,000회로 증가할 경우 먼저 위에서 계산한 인스턴스 당 처리가능한 요청의 수 338회로 요청량을 나누면 총 3개의 인스턴스를 필요로 함을 알 수 있습니다. 그리고 이를 연간 인스턴스 비용과 곱하면 총 연간 운영비용은 $18,000이 됩니다.

• 필요 인스턴스 수 = Ceil(요청량 / 인스턴스 당 처리가능 요청량) + 1
• 총 운영비용 = 연간 인스턴스 비용 * 필요 인스턴스 수

그림 7. Annual Operating Cost vs. Number of Requests

요청량이 증가할수록 inf2.xlarge 인스턴스가 g5.xlarge에 비해 비용효율적인 선택이 될 수 있음을 보여줍니다. g5.xlarge는 사용자가 증가할수록 빠르게 비용이 증가하는 반면 inf2.xlarge는 더 낮은 시간당 비용으로 인해 전반적으로 더 낮은 연간 비용 추세를 보여줍니다. 사용자 요청 횟수가 1,020회인 지점에서 g5.xlarge는 $24,000이고, inf2.xlarge는 $18,240으로 연간 운영비용이 약 24% 절감되는 효과가 있습니다. 각 인스턴스의 연간 운영비용을 막대 그래프로 시각화하면 아래와 같습니다.

그림 8. Annual Operation Cost Comparison inf2.xlarge vs. g5.xlarge

맺음말

본 포스팅에서는 task-specialized LLM을 활용한 비용 절감 방안과 AWS Inferentia2의 성능을 소개하고 분석했습니다. 고성능의 범용 LLM 사용이 비용 증가로 이어질 수 있는 상황에서, task-specialized LLM에 대한 미세조정 학습의 필요성과 함께 AWS Inferentia2와 Hugging Face Optimum을 사용하여 비용 효율적인 추론이 가능한지 알아보았습니다.

실험 결과, AWS Inferentia2는 더 낮은 비용으로 높은 배치 크기를 지원하면서도 비교적 우수한 성능을 보여주었습니다. 이는 대규모 배치 처리가 필요한 작업에서 특히 경쟁력 있는 선택이 될 수 있음을 시사합니다. 물론, 특정 하드웨어 가속기에 최적화된 서빙 방식을 선택하는 것이 성능에 큰 영향을 미칠 수 있으므로, 이를 고려하여 적절한 서빙 방식을 선택하는 것이 중요할 것 같습니다.

Task-specialized LLM의 활용과 AWS Inferentia2의 도입은 비용과 성능 측면에서 큰 이점을 제공하며, 금융권과 같이 폐쇄망 환경에서 AI 서비스를 제공 및 사용하는 기업들의 운영비용 효율성을 높이는 데 기여할 것으로 기대됩니다.