Tech Dive

Multi LLM 운영 환경을 위한 효율적인 LLM Gateway 적용 사례

 안녕하세요! KT Agentic AI Lab A-Pattern팀의 송동훈, 김경환, 안종훈입니다. 저희 팀에서는 LLM 라우터인 KT Orchestration & Routing Agent (KORA)를 연구, 개발하고 있습니다. 이 글에서는 LLM 라우터에 대한 간략한 소개와 KORA 개발기, KORA에 AI Gateway인 LiteLLM 적용사례, KORA 개발 환경에서 관측한 LiteLLM 성능에 대해서 소개하고자 합니다.

LLM 라우터와 KORA

  라우터(Router)라고 들어보셨나요? 라우터는 일반적으로 ‘데이터 패킷을 서로 다른 컴퓨터 네트워크 상에서 최적의 경로로 전달하는 장치’를 말합니다. 이와 마찬가지로, LLM(Large Language Model) 라우터는 수 많은 모델 중 사용자 쿼리를 처리하기에 적합한 모델을 찾아 전달해주는 역할을 수행합니다. KT에서도 믿:음 K, SOTA K, Llama K를 포함한 다양한 특성의 모델이 개발/출시되면서 사용자 쿼리에 대한 적절한 모델을 선택할 필요성이 대두되었고, LLM 라우터인 ‘KORA’를 개발했습니다.

  KORA는 카테고리(Category)기반 라우팅을 사용해, 사용자 쿼리를 4개의 카테고리 [Task, Domain, Level, Capability]로 구분하고, 해당 카테고리를 잘 처리할 수 있는 모델 및 여러 조건(비용, 정책)을 고려해 가장 적합한 모델을 선택하는 방식입니다.

00.jpg
그림 1. KORA의 카테고리 기반 라우팅 예시

   그림 1은 KORA에서의 사용자 쿼리에 대한 카테고리 분류 및 라우팅 결과를 보여줍니다. KORA는 “신나는 k-pop 5곡 추천해줘” 라는 사용자 쿼리에 대하여 카테고리를 [Task : 추론/계획, Domain : 일상, Level : 쉬움, Capability : 단발응답]으로 분류합니다. 

  다음으로 생성된 카테고리를 기반으로 어떤 모델이 가장 비용 효율적이고 고품질의 응답을 생성할 수 있는지 판단하며, 예시에서는 KT의 믿:음 모델이 가장 효율적이다 판단하여 믿:음 모델로 사용자 쿼리를 보내고 응답을 반환하였습니다.

  이 외에도 KORA는 다음과 같은 특성들을 가지고 있습니다.
  • 사용자 쿼리에 따라 가장 적합한 모델을 예측하고 선택합니다.
  • 유사 수준의 응답 품질을 낼 수 있는 여러 모델이 중 저렴한 모델을 선택합니다.
  • 표준화된 OpenAI 규격을 사용합니다.
  • 라우팅 대상 모델에 맞춰 최적의 정책을 생성하기에, 애플리케이션에서는 어떤 모델이 사용되는지 알 필요가 없습니다.

  이제 더 이상 어떤 모델을 선택해야 하는 지 고민하지 마시고 KORA에게 물어보세요. KORA가 여러분을 대신해 가장 이상적인 모델을 선택해 답변을 제공할 것입니다.

AI Gateway 솔루션 도입: LiteLLM, 사용자와 KORA를 이어주는 메신저

  앞서 소개드린 KORA의 핵심 기능은 LLM 라우팅 입니다. LLM 라우팅 개발 과정에서 여러 힘든 일 들이 있었지만, 가장 어려웠던 일 하나만 꼽으라면 개발자라면 누구나 공감하실 시간과의 싸움이었습니다. 개발의 처음 시작은 LLM 라우팅이 실현 가능할 지 맛을 보는 단계였습니다. 할당된 시간이 그리 많지는 않았지만 가능성만 확인해보는 단계라 모자란 시간도 아니었습니다. 

  하지만 기능이 어느 정도 구현/검증되고 팀 외부에 공유하고 서비스하는 단계로 발전하면서, 늘어난 요구사항에 비해 추가 할당된 시간이 넉넉하지 않아 어떻게 개발해야 할 지 고민하게 되었습니다. 그렇게 즉각 사용 가능한 외부 솔루션들에 대해 조사하게 되었고, AI Gateway 솔루션과 LiteLLM 도입에 대해 살펴보게 되었습니다.
  
  AI Gateway란, 말 그대로 AI 서비스를 사용하는 과정의 앞에 하나의 관문(Gateway)을 두고, 서비스를 이용하려는 사용자를 식별하고, 해당 사용자가 어떤 모델이나 서비스로 연결될지를 결정하는 라우팅(Routing) 기능을 수행합니다.

AI Gateway 솔루션의 주요 특징
  1. 애플리케이션은 그림 2와 같이 직접 여러 엔드포인트를 구분해 호출할 필요 없이, AI Gateway만 바라보고 요청 및 응답을 받을 수 있습니다.
  2. 팀/사용자별 권한 및 API 키 관리, 요청별 로깅과 성능 모니터링, 캐싱을 사용한 응답 속도 향상 등 운영&관리측 편의 기능을 제공합니다.
  3. Latency, Token 사용량, 모델 가용성을 종합 고려해 최적의 모델을 결정할 수 있습니다.

01.jpg

그림 2. Application은 LLM 모델 활용을 위해 AI Gateway 솔루션의 API 사용


  KORA의 핵심이라 할 수 있는 LLM 라우팅 기능은 개발 초기부터 진행되어 어느 정도 구현되었습니다. 하지만 이 외 인증이나 로깅 등 운영&관리 측면에서는 부족함이 있었고, 개발 공수를 줄이고자 AI Gateway 솔루션을 적극 도입하고자 했습니다. 그렇게 여러 AI Gateway 솔루션을 조사했고, 저희의 요구사항과 가장 부합했던 LiteLLM을 사용하게 되었습니다.

  LiteLLM의 특징은 다음과 같습니다.
  • 키 발급, 사용량 제어, 모니터링과 같은 기본적인 AI Gateway 솔루션의 기능을 충실히 제공합니다.
  • 표준으로 자리잡은 OpenAI API 스펙을 사용하여, 확장성이 좋습니다.
  • MIT 라이선스로 원하는 기능을 직접 수정 및 배포할 수 있습니다.
  • 팀 주요 개발 언어인 Python으로 개발되어 코드 수정에 이점을 가졌습니다.

02.jpg

그림 3. KORA 아키텍처


  최종적으로 LiteLLM은 그림 3의 KORA 아키텍처에서 보는 것 처럼, 사용자, LLM 그리고 KORA 사이를 이어주는 메신저이자 관문 역할을 수행하게 되었습니다. KORA 아키텍처 내에서 LiteLLM의 역할을 설명드리면 다음과 같습니다.

1 . 인가된 사용자 확인
라우팅 컨트롤러로 들어온 사용자 쿼리는, 요청된 사용자 정보(팀, 사용량 제한, 키)가 유효한 지 LiteLLM을 통해 우선 검사합니다. 이 과정에서 유효하지 않은 접근을 차단할 수 있습니다.
2. 가용 모델 및 비용 카테고리 확인
LiteLLM은 인가된 사용자의 사용 가능한 모델 정보(목록, 비용, 카테고리)를 라우팅 컨트롤러로 전달합니다. 따라서 관리자는 LiteLLM을 통해 모델 정보를 쉽고 효율적으로 관리할 수 있습니다.
3. 실제 라우팅 및 응답 전달
LiteLLM은 라우팅 제어부를 대신해 전달 받은 대상 모델과 사용자 쿼리를 OpenAI 규격에 맞추어 LLM 답변을 요청 및 응답 받습니다. 이 과정에서 모델 관리의 운용 측면이나 캐싱을 통한 성능 측면의 이점을 가집니다.
4. 시스템 관리
LiteLLM 시스템의 동작은 로깅 및 모니터링되며, Config설정으로 쉽게 제어가 가능합니다.

  결과적으로 LiteLLM을 도입하면서 개발 시간을 크게 단축할 수 있었으며, 절약된 시간 만큼 KORA 본연의 LLM 라우팅 기능 개선에 집중 할 수 있었습니다.

LiteLLM 성능: 돌다리도 두드려보고 건너자.

  KORA에서 사용되는 대부분의 API는 LiteLLM을 거쳐가게 되는 만큼 LiteLLM의 강건함이 중요했습니다. LiteLLM 자체적으로 부하 시험을 수행한 결과가 있으나 저희의 환경과 상이한 부분이 있었고, 자원 사용률과 관련된 자료는 확인이 어려웠습니다. 따라서 저희만의 서비스 목표와 환경에 맞는 부하 시험이 필요했고, 다음과 같이 실험을 진행하게 되었습니다.

  • 선-실험 (pre-Experiment) 진행: LiteLLM이 부하를 버틴다고 하더라도, 다른 모듈에서 부하를 버틸 수 없다면 지연 시간이 적체될 수 있으므로, 타-모듈의 부하 시험을 사전 수행
        - 대상 모델 부하 시험 : Azure OpenAI API 사용 → 자체 부하 없음
        - 라우팅 제어부 부하 시험 : 약 200tps 수용 확인 (* tps: 초당 처리 가능한 token 수)
  • 시험 도구: llmperf [참고 ] - 일정한 Token 수를 유지하고, 캐싱을 우회한 부하 테스트 진행
  • 데이터셋: sonnet-dataset [참고 ] - 셰익스피어의 소네트 모음
  • 부하: 동시성(Concurrency)을 높여가며 시험
        (* 동시성 : [동시 사용자] x [사용자별 초당 요청 수] x [평균 응답 시간])
        - Input token : mean 768
        - Output token : mean 600
         - 중단점 : 질의 완료 수 5,000 건
  • Infra.: Azure Container App., Multi-instance, 1CPU, 2GB RAM

03.jpg

그림 4. 단일 LiteLLM 대상 부하 시험 결과


  그림 4는 KORA 부하 시험 중 LiteLLM에서 발생하는 처리량(Throughput)과 지연 시간(Latency)을 나타낸 그래프입니다. 그림 4 좌측의 그래프로부터 동시 요청 수가 늘어남에 따라 LiteLLM의 처리량이 늘어나는 것을 확인할 수 있고, 그림 4 우측의 그래프로부터 동시 요청 수가 늘어나는 것에 비해 지연 시간은 비슷하게 유지되는 것을 확인할 수 있습니다. 이러한 결과로부터 LiteLLM은 부하가 커지더라도 추가적인 instance로 부터 부하를 나누어 처리하는 방식으로 지연 시간을 일정하게 유지할 수 있음을 확인했습니다.
  
  그렇다면 어느 정도 부하에서 새로운 instance를 만들어야 효율적이라고 할 수 있을까요? 이를 확인하고자 시험 중 자원 모니터링도 수행했고, 결과적으로 동시성이 증가하는 추세와 instance가 신규로 배포되는 시간을 고려했을 때, CPU 사용률 70% 일 때가 가장 자원 효율적이면서 안정적인 운용이 가능하다고 판단하였습니다.

04.jpg

그림 5. 자원 사용률 변화


  그림 5는 부하 시험 중 LiteLLM의 자원 사용률 변화를 나타냅니다. 동시성이 증가함에 따라 CPU 사용률이 올라가고, CPU 사용률이 70%에 달하면 신규 instance가 배포되면서 CPU 사용률과 MEM 사용률이 내려가는 것을 확인할 수 있습니다. 정리하자면 LiteLLM은 처리량이 늘어남에 따라 CPU 부하가 증가하지만, instance를 늘리는 방법으로 처리량을 분산시켜 부하를 안정적으로 낮출 수 있으며, 따라서 목표로 하는 동시성 조건에 따라 적절한 scale up (instance 신규 생성) 조건을 세워 안정적인 서비스가 가능한 것을 확인했습니다.

LiteLLM 적용 후기: 장점과 한계

  LiteLLM은 로깅 및 모니터링 기능이 아주 잘 되어 있어 팀, API 키, 사용자 정의 태그별로 사용량을 조회할 수 있습니다. config 파일을 통해 여러 옵션을 지정할 수 있어 운영 환경에 맞게 손쉽게 설정을 바꿀 수 있는 점이 인상적이었습니다. 또한 Python SDK가 잘 되어 있고 팀에서도 Python으로 KORA를 개발하여 기존 Handler를 상속받아 쉽게 Custom Handler를 정의할 수 있었습니다. 이를 활용해 LiteLLM이 공식적으로 지원하지 않는 자체 구축 LLM 또는 API 엔드포인트를 추가로 연결 할 수 있어 KT에서 개발한 믿:음 K, SOTA K, Llama K 모델을 쉽게 연동 할 수 있었습니다.

  다만, 다음과 같은 아쉬운 점도 다수 있었습니다.
기능제한
  • 오픈소스임에도 불구하고 기본적으로 제공되어야 할 것 같은 기능이 Enterprise버전에 포함
  • (예시) 팀 생성, 키 재발급 같은 핵심 API, 모델 관리 기능 등
모델관리의 미흡
  • config 파일을 통해 모델을 쉽게 등록할 수 있으나 수정이 불가
  • 모델 정보를 삭제 하더라도 팀에 등록된 모델 목록에 잔존
문서화 부족
  • Customizing 관련 문서가 상세하지 않아 직접 구현에 어려움
버그
  • Custom Handler를 붙여 streaming 요청을 보낼 경우 마지막 chunk_id 값이 달라지는 이슈
  • 버전에 따라, Docker Image 빌드 시 웹페이지가 정상적으로 렌더링되지 않는 이슈

결론

  저희는 다양한 LLM 환경에서 최적의 모델을 자동으로 선택하는 KORA 시스템에 오픈소스 AI Gateway 솔루션인 LiteLLM을 도입하여 다양한 LLM API를 통합해 관리의 효율성을 크게 높일 수 있었습니다. LiteLLM은 Python 기반의 Custom Handler를 통해 내부 특화 모델까지 손쉽게 연동할 수 있다는 큰 장점이 있었습니다. 그리고 팀별 키 관리, 예산 추적, 모델 관리와 같은 실무에 유용한 기능과 OpenAI API 호환성 덕분에 기존 애플리케이션에 부담 없이 적용할 수 있었습니다.
  
  다만 운영 과정에서는 AI Gateway 솔루션 도입으로 인한 자원 사용량 증가와 LiteLLM의 장기 운영 시 메모리 누수 가능성을 확인했으며, 일부 중요한 핵심 기능은 엔터프라이즈 버전에서만 제공된다는 제약도 있었습니다. 이러한 점들로 미루어 보았을 때 성능 및 서비스 안정성이 중요한 환경에서는 LiteLLM보다는, 다른 고성능 AI Gateway 솔루션을 고려하는 것이 더 합리적일 수 있겠다는 생각이 들었습니다.

  KORA가 현재는 LiteLLM을 포함한 SaaS 형태로만 서비스되고 있으나, 추후에는 구축형으로 단일 컨테이너에서 실행할 수 있는 라이트한 버전으로 누구나 사용할 수 있도록 배포할 예정입니다.

송동훈, 김경환, 안종훈

송동훈: KT에서 Model Orchestrator 기술을 연구하고 있습니다. 관련 기술 공유는 언제든 환영합니다.

김경환: A-Pattern팀 김경환입니다. LLM Router인 KORA를 개발하고 있습니다.

안종훈: KT에서 Model Orchestrator 기술을 연구하고 있습니다. 사람들에게 LLM을 활용한 서비스 개발 및 연구를 진행하고 있습니다.

Multi LLM 운영 환경을 위한 효율적인 LLM Gateway 적용 사례 - kode