분산형 AI 추론: 통신 서비스 제공업체 리더가 알아야 할 사항

모든 통신 서비스 제공업체는 현재 AI를 운영에 도입하고 있습니다. 활용 사례로는 외부 엔터프라이즈 고객 등을 위한 고객 관리 봇, 네트워크 운영 코파일럿, 관리형 AIaaS(AI-as-a-Service) 등이 있습니다. 

어려운 점은 활용 사례와 비즈니스 사례 간의 상관관계입니다. 여기서 핵심 요소는 그래픽 처리 장치(GPU), 텐서 처리 장치(TPU) 또는 신경망 처리 장치(NPU)와 같은 AI 가속기 비용입니다. 추론당 비용에 따라 이러한 AI 가속기가 수익성을 개선할지 아니면 악화시킬지가 결정됩니다. 비용을 절감하려면 적절한 AI 모델을 선택하는 것뿐만 아니라, 분산된 지리적 규모에서 해당 모델을 배포하고 서비스하는 방식도 중요합니다.

최근 아티클에서 Red Hat 전문가들은 추론 배포 문제를 모델 크기뿐만 아니라 트래픽과 규모에 따라 달라지는 아키텍처 관점에서 다루었습니다. 이 블로그 포스트에서는 해당 연구 결과를 요약하여 소개합니다.

추론당 비용이 손익에 미치는 영향

각 AI 요청은 동일한 하드웨어 내에서 두 가지의 개별 작업을 수행합니다. 

• 첫째, 청구 내역, 장애 접수 건, 네트워크 로그 등 처리해야 할 프롬프트 또는 입력값을 읽어옵니다. 
• 그런 다음 해당 입력값에 대한 응답을 한 번에 토큰 1개씩 생성합니다.

읽기 단계는 사용자가 첫 단어가 나올 때까지 기다리는 시간을 결정하며, 쓰기 단계는 대화가 자연스럽게 이어지는지 또는 자주 끊기는지를 결정합니다. 두 단계는 서로 다른 리소스 프로필과 최적화 방식이 필요하며, AI 가속기 리소스를 공유할 경우 서로 자원을 점유하기 위해 경쟁하게 됩니다.

이러한 상충 관계는 AI 활용 사례와 워크로드 유형에 따라 손익에 각기 다른 영향을 미칩니다. 예를 들어 고객 관리 챗봇의 경우, 봇 응답이 지연되어 상담원에게 세션이 넘어가면 상담당 관리 비용이 상승합니다. 엔터프라이즈 AI 서비스는 지연 시간 약정을 준수하지 못할 경우 서비스 수준 계약(SLA) 위반에 따른 페널티가 발생할 수 있습니다. 또한 쿼리당 비용이 계약에 책정된 가격을 초과하면 B2B AI 제품의 수익성이 악화됩니다. 

대부분의 배포 실수는 트레이드오프(trade-off) 판단 착오에서 비롯되며, 제품의 가치와 무관한 지표를 최적화할 때 발생합니다. AI가 수익을 창출하는 구체적인 방식을 살펴보면 각 워크로드 유형에 적합한 배포 모델을 파악할 수 있습니다.

고객 관리

고객 관리는 가장 대표적인 사례입니다. 고객 관리 트래픽은 매 통화마다 동일한 요금제 및 정책 머리말(preamble)을 재사용하는 수천 건의 짧고 동시 다발적인 채팅 세션으로 구성됩니다. Red Hat 전문가들은 Red Hat의 vLLM 벤치마크를 통해 다음 사항을 확인했습니다.

• 읽기 및 쓰기 풀을 분리하고 적절한 규모로 조정하면 이러한 트래픽 패턴에서 비용을 25~40% 절감할 수 있습니다.
• 오픈소스 llm-d 프로젝트에서 구현한 스케줄링 방식인 캐시 인식 라우팅은 프롬프트 재사용률이 높은 경우 GPU당 2~3배 더 많은 토큰을 처리하고 토큰당 비용을 3~5배 낮췄습니다.

실제 운영 시스템에서 이 정도의 개선 효과를 보기는 어렵겠지만, 측정된 모든 워크로드에서 개선 방향성은 일관되게 나타났습니다. 월간 수천만 건의 고객 관리 상호 작용이 발생하는 환경에서는 추론 비용을 단 몇 퍼센트만 줄여도 추가적인 가속기 자본 지출(CapEx) 없이 다음 제품 주기에 필요한 예산을 확보할 수 있습니다.

네트워크 운영

네트워크 운영은 이와 정반대의 양상을 보입니다. 사용자는 적지만 처리해야 할 문서의 양이 매우 방대합니다. 인시던트 분석 시 동일한 런북, 토폴로지 기록, 벤더 매뉴얼을 반복해서 참조하므로, 이미 처리된 내용을 캐싱하는 것이 비용 절감의 핵심입니다. 이를 통해 진단 시간을 단축하고 숙련된 엔지니어에게 지원을 요청하는 에스컬레이션 빈도를 줄일 수 있습니다.

기업 대상 관리형 AI

기업 고객을 대상으로 하는 AI 서비스는 다수의 테넌트, 계층화된 SLA, 급격한 수요 변화라는 세 번째 특성을 가집니다. 이러한 시나리오에서 수익성을 보호할 수 있는 두 가지 메커니즘은 다음과 같습니다.

• 모델 캐스케이딩(Model cascading)은 일반적인 쿼리는 소형 모델에서 처리하고 복잡한 쿼리만 상위 모델로 전달하는 방식으로, 단순 쿼리 비중이 높은 클러스터의 비용을 40~60% 절감합니다.
• 서비스 수준 목표(SLO)와 연계된 승인 제어는 SLA 위반이 예상되는 요청을 대기열에 넣어 실패하게 두는 대신 사전에 거부함으로써, 과부하 상황에서도 서비스의 신뢰성을 유지합니다.

표 1에서 알 수 있듯이, 이러한 세 가지 활용 사례는 고객이 단일 공유 AI 가속기 풀에 의존하게 만드는 대신 골드, 실버, 브론즈 등급의 가격 책정 모델로 활용될 수 있습니다. 또한 두 가지 제약 조건을 추가로 고려하면 서비스 제공업체의 비즈니스 모델을 완성하고 특정 고객에 최적화된 AI 서비스를 제공할 수 있습니다. 

클라우드 버스팅 역량을 갖춘 소버린 AI

데이터 주권 규정에 따라 가입자 데이터는 해당 국가 내에 보관되어야 합니다. 이러한 요구 사항을 충족하는 최적의 패턴은 규제를 준수하는 온프레미스 환경을 기본으로 하되, 트래픽이 몰릴 때만 활성화되는 클라우드 버스팅을 활용하는 것입니다. Red Hat OpenShift AI와 같은 단일 제어 평면을 통해 두 환경을 동기화하면, 구성 관리의 인적 오류에만 의존하지 않고도 컴플라이언스를 유지할 수 있습니다.

엣지 컴퓨팅

동시 세션이 약 100개 이하인 네트워크 엣지 환경에서는 복잡한 풀링 없이 가속기당 하나의 모델을 배치하는 것이 가장 효율적입니다.  복잡한 쿼리는 백홀을 통해 상위 시스템으로 전달하여, 전송 비용이 데이터 양이 아닌 작업의 복잡도에 비례하도록 관리해야 합니다.

표 1. 워크로드 유형별 비즈니스 성과 창출 방안

각 활용 사례를 검토할 때 서비스 제공업체가 고려해야 할 질문은 다음과 같습니다.

• 고객 관리: 현재 완전히 자동화된 고객 상담 비용은 얼마이며, 어떤 요인이 비용에 가장 큰 영향을 주고 있나요? 실제 트래픽에서 측정된 상담 완료 건당 비용과, 특정 요소를 적용하기 전후의 수치를 제시하는 것이 바람직합니다.
• 네트워크 운영: 엔지니어가 인시던트 기록에서 유용한 답변을 얻기까지 대기 시간은 어느 정도이며, 동일한 문서가 반복해서 처리되고 있지는 않나요? 런북 및 사이트 기록이 재처리되지 않고 캐시에서 제공되는 비율과, 첫 번째 답변이 나오기까지의 시간 추이를 제시하는 것이 좋습니다.
• B2B 서비스: 최대 부하 시 가장 먼저 위반되는 엔터프라이즈 SLA는 무엇이며, 해결책이 하드웨어 증설인가요 아니면 라우팅 개선인가요? 부하 테스트를 통해 취약한 서비스 등급을 파악하고, 추가 구매 요청에 앞서 라우팅이나 승인 제어 개선을 시도했는지 확인해야 합니다.
• 데이터 주권 및 피크 대응: 데이터 상주 규정을 준수하기 위해 피크 시간 외에 유휴 상태로 방치되는 용량은 어느 정도인가요? 평상시의 기본 사용량과 대기 시 비용이 발생하지 않는 버스트 설계 방안을 보고해야 합니다.
• 엣지 및 현장: 중앙 클러스터로 전송되는 현장 쿼리의 비율은 어느 정도이며, 그에 따른 전송 비용은 얼마인가요? 사이트별 로컬 처리율을 확인하고, 현장 모델이 처리할 수 없는 쿼리에 대해서만 에스컬레이션이 이루어지도록 해야 합니다.

투자 경로

AI 활용 사례가 정립되면, 이를 효율적이고 경제적인 방식으로 구축하는 단계가 필요합니다. 최종 목표보다 그 과정의 순서가 더 중요합니다. 각 단계는 정해진 일정이 아니라 측정된 지표에 따라 진행되며, 다음 단계로 넘어가기 전에 이전 단계의 비용 효율성이 입증되어야 합니다.

1. 단일 노드로 시작: 일주일 동안 실제 고객 관리 또는 네트워크 트래픽 환경에서 단일 서빙 인스턴스를 운영해 보세요. 이때 확보한 기준 데이터가 향후 모든 의사 결정의 척도가 됩니다. 가상의 테스트 트래픽은 실제와 다를 수 있으므로 주의해야 합니다.
2. 지능형 라우팅 추가: 단순히 복제본을 두 개로 늘려도 처리량은 기존의 1.8배에 못 미치는 경우가 많습니다. 이러한 차이는 이미 다른 서버가 보유한 컨텍스트를 새로운 서버가 다시 읽어야 하는 비효율성 때문에 발생합니다. 이는 용량 부족이 아니라 라우팅 과정의 낭비이므로, 하드웨어를 추가하기 전에 이 문제를 먼저 해결해야 합니다.
3. 읽기 및 쓰기 풀 분리: 한 단계의 부하가 다른 단계에 심각한 영향을 주어, 운영 복잡성이 증가하더라도 풀 분리가 더 이득이라고 판단될 때만 이 작업을 수행하십시오.
4. 멀티테넌트 그리드 도입: 여러 제품과 B2B 고객이 플랫폼을 공유하게 되면, 계층화된 SLA를 보장하기 위한 메커니즘의 복잡성을 감수할 가치가 생깁니다. 그 미만의 규모에서는 오히려 불필요한 노력이 될 수 있습니다.

각 단계마다 기준 데이터는 갱신됩니다. AI 추론 전략은 단 한 번의 아키텍처 결정으로 끝나는 것이 아니라, 측정된 데이터를 기반으로 끊임없이 판단해 나가는 과정입니다. 서비스 제공업체는 이미 무선 주파수 대역 관리에서 이러한 방식을 적용하고 있습니다. 즉, ROI(투자수익률)가 확실한 제품에 용량을 할당하고, 지속적으로 모니터링하며, 유휴 자원을 회수하는 방식입니다. AI 가속기 관리에도 동일한 원칙이 적용되어야 합니다.

결론

분산형 AI 추론은 서비스 제공업체의 AI 제품이 수익성을 유지할 수 있을지를 결정짓는 핵심 요소입니다. 이 블로그 포스트에서 제안하는 방식은 무리한 예산 투입을 요구하지 않습니다. 모든 메커니즘은 다음 단계로 넘어가기 전 실제 트래픽 환경에서 그 효과가 입증되는 단계적 절차를 따르며, 표 1은 우선적으로 검토해야 할 사항을 보여줍니다.

고객 관리, 네트워크 또는 B2B 포트폴리오에 이러한 방식을 적용할 준비가 되셨다면, 트래픽 데이터를 지참하여 Red Hat 어카운트 팀에 문의해 주세요. vLLM, llm-d, Red Hat OpenShift AI를 활용한 이러한 패턴은 이미 여러 서비스 제공업체에 적용되고 있으며, 일반적인 청사진보다는 고객의 실제 요구 사항에서 시작할 때 가장 신속한 해결책을 찾을 수 있습니다.