Samsung SDS

Executive Summary

• 매주 새로운 오픈웨이트(OpenWeight) 모델이 벤치마크를 갱신하지만, 지능·속도·비용이 모두 우수한 단일 정답은 없습니다. 라이선스, 보유 GPU 규모, 다국어 지원, 고객 수요까지 함께 점검해야 실제 서비스로 이어집니다.
• 추론은 요청마다 연산량이 수십 배 차이 나고, 캐시 재사용 여부에 따라 응답 속도가 달라지는 비균질 워크로드입니다. 좋은 모델을 확보하는 것과 수만 명의 동시 요청을 낮은 지연시간·낮은 비용으로 처리하는 것은 완전히 별개의 엔지니어링 문제입니다.
• LLM 서빙 기술은 네 가지 Pain Point에서 자라났습니다. 놀고 있는 GPU, 반복되는 Prefill 연산, 무게가 제각각인 요청, 출렁이는 트래픽입니다.
• Samsung Cloud Platform 운영 환경에서 KV 캐시 오프로드로 캐시 적중률을 90% 이상까지 끌어올려, 같은 하드웨어에서 분당 처리 토큰(TPM)을 1.3~1.8배 늘렸습니다.
• 인퍼런스 경쟁력은 어떤 모델을 올렸는가가 아니라, 동일한 GPU에서 얼마나 안정적으로 처리량을 확보하는가에서 결정됩니다.

지난 아티클 “AI 가속기, 어떻게 선택할 것인가”에서는 AI 인프라의 출발점인 하드웨어, 즉 GPU와 NPU 같은 가속기를 고르는 기준을 살펴봤습니다. 가속기를 골랐다면 다음 질문이 자연스럽게 따라옵니다. 그 위에 어떤 모델을 올리고, 그 모델을 어떻게 서비스할 것인가? 이번 아티클은 이 두 번째 질문, 그 중에서도 모델을 고른 뒤에 시작되는 숙제인 LLM 서빙에 대한 이야기입니다.

쉽지 않은 좋은 모델 고르기

새로운 오픈웨이트 (OpenWeight) 모델이 쏟아지는 시대입니다. GLM, Qwen, gemma, gpt-oss까지, 매주 새로운 모델이 벤치마크 순위를 갱신하며 등장합니다. 그래서 인퍼런스 서비스를 준비하는 조직이 가장 먼저 마주하는 질문은 이것입니다. “어떤 모델을 쓸 것인가?”

이 질문에 답하려면 생각보다 많은 것을 고민해야 합니다. 아래 그림처럼 모델마다 지능(Intelligence), 속도(Speed), 비용(Cost)이 제각각이어서 하나의 정답이 존재하지 않기 때문입니다. 지능이 높은 모델은 비용이 많이 들고, 빠르고 저렴한 모델은 복잡한 작업에서 한계가 있습니다.^[1]

벤치마크 점수는 기본이고, 상업적 활용이 가능한 라이선스인지, 보유한 GPU에 올릴 수 있는 규모인지, 한국어를 포함한 다국어를 얼마나 잘 지원하는지, 실제 고객 수요가 있는지, 여러 기업이 선호하는 모델인지 살펴야 합니다. 오픈웨이트 모델을 출시할 때 기술 적합성 검토 단계에서 모델 규모, 라이선스, 벤치마크, 예상 고객 수요, 선호 모델 여부를 하나하나 점검하는 이유도 여기에 있습니다. 모델 선택은 기술 판단인 동시에 사업 판단이기 때문입니다.

좋은 모델 선택이 끝이 아닌 이유

이 단계까지 통과한 조직에서도 흔히 나타나는 착각이 있습니다. “이제 GPU 서버에 모델을 올리면 서비스가 되겠지.” 실제로는 그 반대입니다. 진짜 문제는 모델을 고른 다음부터 시작됩니다.

LLM 추론은 전통적인 웹 서비스와 근본적으로 다릅니다. 요청마다 연산량이 수십 배씩 차이 나고, 같은 프롬프트라도 캐시 재사용 여부에 따라 응답 속도가 달라집니다. 수백 GB의 GPU 메모리는 순식간에 KV 캐시로 가득 차고, 트래픽은 시간대에 따라 큰 폭으로 변동하는 특성을 보입니다. 학습이 끝나 좋은 모델을 확보했더라도, 그 모델로 수만 명의 동시 요청을 낮은 지연시간과 낮은 비용으로 처리하는 것은 별개의 엔지니어링 문제입니다.

하루 수천억에서 수백 조 토큰, 숫자가 말해주는 현실

이 문제가 얼마나 현실적인지는 실무 데이터가 보여줍니다. 인퍼런스 서비스 제공자가 운영하는 LLM은 하루 수천억 토큰 규모의 요청을 처리하는 것이 일상이 되었습니다. 구글은 2026년 5월 Google I/O에서 자사 서비스 전반의 월간 처리량이 3,200조 토큰을 넘어섰다고 밝혔는데, 단순 환산하면 하루 100조 토큰이 넘는 규모입니다.^[2] 코딩 에이전트와 AI 애플리케이션 확산으로 사용량은 감소하지 않고 증가 추세입니다. 트래픽 패턴도 뚜렷합니다. 업무 시간대인 오전 늦은 시간과 퇴근 무렵에 수억 토큰이 몰리는 피크가 매일 반복됩니다.

하루 수천억에서 수백조에 이르는 토큰을 변동성이 높은 트래픽 속에서 제한된 GPU로 처리해야 하는 것이 LLM 서빙 생태계가 마주한 현실입니다. 이 현실 속 어려움(Pain Point)을 해결하기 위해 지금, 이 순간에도 서빙 효율화 기술들이 새롭게 등장하고 있으며, 현장에서는 적용 시도와 시행착오가 반복되고 있습니다. 본 아티클에서는 그 가운데 주류로 자리 잡아가고 있는 주요 기술들을 소개합니다. 공통 목표는 제한된 GPU 자원에서 낭비를 줄이고, 단위 비용당 처리량을 높이는 것입니다.

이런 관점에서 LLM 서빙 인프라를, 토큰을 생산하는 공장, 즉 토큰 팩토리(Token Factory)로 볼 수 있습니다. 같은 설비에서 더 많은 토큰을 더 낮은 원가로 생산하기 위한 고민이 토큰 경제학 (Tokenomics)이고, 이어서 살펴볼 네 가지 기술 영역도 이 관점에서 정리할 수 있습니다.

Pain Point ① GPU는 비싼데, 놀고 있다

인퍼런스 서비스의 원가에서 가장 큰 비중을 차지하는 것은 단연 GPU입니다. 최신 GPU는 한 장에 수천만 원을 호가하고, 그마저도 구하기 어려운 공급난이 이어지고 있습니다. 그런데 역설적으로, 이 비싼 자원이 실제로 일하는 시간은 생각보다 짧습니다.

이유는 세 가지입니다. 첫째, 정적 할당입니다. 전통적인 방식은 모델마다 GPU와 메모리를 고정으로 배정합니다. 모델 A에 배정된 메모리가 남아돌아도 모델 B는 그 공간을 쓸 수 없습니다. 모델 수가 늘어날수록 곳곳에 자투리 메모리가 방치되는 파편화가 심해집니다. 둘째, 피크 기준 프로비저닝입니다. 서비스 품질을 지키려면 가장 바쁜 시간대에 맞춰 인프라를 준비해야 하는데, 그 결과 피크가 아닌 대부분의 시간에는 자원이 남습니다. 셋째, 시간대 편중입니다. 업무 시간에 몰리는 트래픽 특성상 야간과 휴일의 GPU는 사실상 대기 상태입니다.

요약하면, 가장 비싼 자원을 가장 바쁜 순간에 맞춰 사두고 나머지 시간에는 놀리는 구조입니다. 서빙 생태계는 이 낭비를 걷어내기 위해 세 방향의 기술을 발전시켜 왔습니다.

해법 1: 한 장의 GPU를 여러 모델이 나눠 쓰는 GPU 분할처리

첫 번째 방향은 GPU 한 장을 더 잘게, 더 유연하게 쓰는 것입니다. 핵심은 KV 캐시 메모리의 동적 관리입니다. 기존의 정적 할당 구조에서는 모델 별로 정해진 KV 캐시 공간이 있어 남는 공간을 다른 모델이 쓸 수 없었습니다. 최근에는 이 공간을 블록 단위로 잘라 필요한 모델에 동적으로 빌려주는 구조가 등장했습니다. 여러 모델이 하나의 메모리 풀을 공유하면서, 같은 GPU에서 더 많은 모델을 더 큰 캐시로 운영할 수 있게 됩니다.^[3]

또 하나의 축은 Warm Start입니다. 모든 모델이 항상 바쁜 것은 아니므로, 요청이 많은 인기 모델은 GPU에 상주시켜 즉시 응답하고, 요청이 뜸한 모델은 Sleep 상태로 전환해 GPU 메모리를 반환합니다. Sleep 모델에 요청이 들어오면 빠르게 Active 상태로 복원하고, GPU가 부족해지면 우선순위가 낮은 모델부터 자동으로 비활성화됩니다.

해법 2: 서빙이 한가할 때 학습을 돌리는 Mixed Workload

두 번째 방향은 시간의 빈틈을 다른 종류의 일로 채우는 것입니다. 서빙 트래픽이 줄어드는 야간과 휴일에 같은 GPU를 학습(Training) 작업으로 자동 전환하는 Mixed Workload 기술이 대표적입니다. 서빙 요청량이 줄면 학습 작업을 수행하고, 요청량이 다시 늘면 학습을 종료해 서빙 응답시간을 안정적으로 유지합니다.

응답 지연에 민감한 서빙과, 오래 걸리지만 중단해도 다시 이어갈 수 있는 학습의 상반된 특성을 조합해 GPU 활용률을 극대화하는 접근입니다.

해법 3: 유휴 시간대와 외부 수요의 연결

세 번째 방향은 남는 자원을 아예 새로운 수요와 연결하는 것입니다. LLM 추론 수요는 전 세계에 퍼져 있고, 하나의 통일된 API로 수백 개 모델을 라우팅해 주는 통합 LLM 게이트웨이 플랫폼이 성장하면서, 지역과 사업자를 넘나드는 토큰 거래 시장이 형성되고 있습니다. 인퍼런스 서비스 제공자는 야간 유휴 GPU를 이런 분산 서빙 플랫폼에 공급해 추가 수익을 만들 수 있습니다.

특히 타임존의 이점이 큽니다. 아시아의 야간은 북미와 유럽의 낮, 즉 글로벌 요청이 가장 몰리는 피크 시간대와 겹칩니다. 국내 트래픽이 적은 시간대에 해외 요청을 처리하면 GPU 가동 시간을 24시간에 가깝게 유지할 수 있습니다.

GPU 분할처리, Mixed Workload, 유휴 자원의 외부 공급은 모두 GPU 활용률을 높이기 위한 기술입니다. 토큰 단가 경쟁이 치열해질수록 GPU 활용률은 인퍼런스 서비스의 원가 경쟁력을 좌우하는 핵심 지표, 즉 토큰 경제학의 첫 번째 지표가 되고 있습니다. 다만 활용률을 높여도 GPU가 같은 계산을 반복하고 있다면 자원은 여전히 낭비됩니다. 다음 장에서는 이 중복 연산 문제를 다룹니다.

Pain Point ② 반복되는 Prefill 연산

LLM이 답변을 생성하는 과정은 크게 두 단계로 나뉩니다. 먼저 입력된 프롬프트 전체를 읽고 이해하는 Prefill 단계, 그 다음 토큰을 하나씩 생성하는 Decode 단계입니다. 이 중 Prefill은 입력이 길수록 연산량이 가파르게 늘어나는, GPU 입장에서 가장 비싼 작업입니다.

문제는 실제 서비스에 들어오는 요청의 상당 부분이 서로 겹친다는 점입니다. 모든 요청에 똑같이 붙는 시스템 프롬프트, 여러 사용자가 함께 조회하는 사내 문서, 대화가 이어질 때마다 다시 전송되는 이전 대화 이력까지. 내용이 같다면 계산 결과도 같습니다. 그런데 아무 장치가 없다면 GPU는 이 동일한 앞부분(Prefix)을 요청이 올 때마다 처음부터 다시 계산합니다. 책을 읽다가 페이지를 넘길 때마다 1페이지부터 다시 읽는 것과 같습니다.

이 중복을 없애는 장치가 KV 캐시입니다. 한 번 계산한 중간 결과(Key/Value)를 저장해 두었다가, 같은 Prefix를 가진 요청이 오면 계산을 생략하고 저장된 값을 바로 꺼내 쓰는 것입니다.

KV 캐시가 있는데 왜 여전히 문제일까요? 저장 공간 때문입니다. KV 캐시는 기본적으로 GPU VRAM에 저장되는데, VRAM은 모델 가중치가 이미 대부분을 차지하고 있는 가장 비싸고 좁은 공간입니다. 캐시가 차오르면 가장 오래 안 쓰인 것부터 지우는 LRU 방식으로 자리를 비워야 하고, 지워진 캐시에 해당하는 요청이 다시 들어오면 결국 Prefill을 처음부터 다시 계산해야 합니다. 캐시가 있어도 오래 유지되지 못하는 구조입니다.

해법: 캐시에 계층을 만드는 KV 캐시 오프로드

서빙 생태계가 찾은 답은 메모리 계층화입니다. 컴퓨터 구조에서 익숙한 캐시 계층 개념을 KV 캐시에 적용해, 좁고 빠른 GPU VRAM(L1) 아래에 CPU RAM(L2)과 로컬 NVMe SSD(L3)를 두고, 필요하면 여러 노드가 캐시를 공유하는 원격 스토리지(L4)까지 확장하는 구조입니다.

이 구조의 특징은 복제가 미리 일어난다는 점입니다. GPU에서 블록 단위(예: 64토큰)로 KV 블록 계산이 끝나면 그 사본을 비동기로 CPU RAM에 복사하고, CPU 저장이 완료된 블록은 다시 디스크에도 이어서 복제합니다(cascade). 복사는 GPU 연산과 병렬로 이뤄지므로 서비스 응답에는 영향이 없습니다. 이렇게 미리 사본을 만들어 두면, VRAM이 가득 차 LRU로 캐시가 지워져도 같은 내용이 하위 계층에 살아 있습니다.

재사용은 반대 방향으로 일어납니다. 같은 Prefix를 가진 요청이 오면 GPU에서 먼저 찾고, 없으면 CPU, 그 다음 디스크 순으로 조회합니다. 디스크에서 발견되면 CPU를 거쳐 GPU로 승격(Promotion)시켜 Prefill 계산을 통째로 생략합니다. 다시 계산하는 것보다 복사해 오는 쪽이 압도적으로 빠르고 쌉니다. 블록 단위로 관리하기 때문에 Prefix가 부분적으로만 일치하는 요청도 겹치는 만큼 재사용할 수 있습니다.

물론 하위 계층의 저장 공간 역시 한정되어 있어 주기적인 정리가 필요합니다. 디스크 사용률이 임계치(예: 85%)에 도달하면, 최근에 접근된 블록은 남겨두고 오래 쓰이지 않은 캐시부터 자동 삭제해 목표 수준(예: 50%)까지 공간을 회수합니다. CPU 계층은 LRU로, 디스크 계층은 접근 시각 기반으로, 계층마다 성격에 맞는 퇴출 정책을 두는 것입니다.

효과는 뚜렷합니다. 실제 Samsung Cloud Platform 운영 환경 측정에서 오프로드로 캐시 적중률(Hit Rate)을 90% 이상까지 끌어올리고, 같은 하드웨어에서 분당 처리 토큰(TPM)을 1.3배에서 1.8배까지 늘린 결과를 확인했습니다. 오픈소스 진영에서도 KV 캐시 계층화로 지연시간과 처리량이 크게 개선된다는 보고가 이어지고 있습니다.^[8]

이 기술은 사용자의 비용 구조에도 그대로 반영되고 있습니다. 주요 인퍼런스 서비스들은 캐시에 적중한 입력 토큰(Cached Input)에 대해 일반 입력 토큰의 2분의 1에서 3분의 1 수준, 혹은 그 이하의 요금을 매깁니다.^[7]

제공자로서는 계산을 생략한 만큼 원가가 줄었으니, 가격을 낮출 수 있고, 사용자로서는 시스템 프롬프트와 대화 이력을 재사용하도록 애플리케이션을 설계할수록 요금이 내려갑니다.

다만 KV 캐시의 효과는 저장 방식만으로 결정되지 않습니다. 동일한 Prefix를 가진 요청을 캐시가 존재하는 인스턴스로 보내는 라우팅이 함께 뒷받침되어야 합니다. 다음 장에서는 이 라우팅 문제를 다룹니다.

Pain Point ③ 요청 불균형과 라우팅의 한계

여러 대의 서버에 요청을 나눠주는 로드밸런싱은 오래된 기술입니다. 가장 널리 쓰이는 방식은 라운드로빈, 즉 들어오는 순서대로 서버를 돌아가며 배정하는 것입니다. 이 방식은 하나의 전제 위에 서 있습니다. 모든 요청의 무게가 비슷하다는 전제입니다. 웹 페이지 조회처럼 균질한 요청이라면 이 전제가 통합니다.

그런데 LLM 추론에서는 이 전제가 무너집니다. 한 줄짜리 질문과 수만 토큰짜리 문서 분석 요청은 연산량이 수십 배 차이 나고, 같은 요청이라도 해당 인스턴스에 KV 캐시가 살아 있는지에 따라 처리 시간이 크게 달라집니다. 인스턴스마다 지금 쌓여 있는 대기열의 길이도 제각각입니다. 이런 상황에서 순서대로만 나누면, 어떤 GPU 앞에는 무거운 요청이 몰려 대기 큐가 길어지는데 옆의 GPU는 놀고 있는 불균형이 생깁니다. 전체 처리량은 떨어지고, 운 나쁜 요청의 응답 시간은 한없이 늘어집니다.

해법: 엔드포인트를 고르는 EPP (추론 스케줄링)

서빙 생태계가 내놓은 답은 라우터를 똑똑하게 만드는 것입니다. 최근의 LLM 오케스트레이션 프레임워크들은 쿠버네티스의 Gateway API Inference Extension 위에서 추론 스케줄링(Inference Scheduling)이라는 접근을 표준화하고 있습니다.

잠깐 짚고 가면, Gateway API Inference Extension은 쿠버네티스에서 생성형 AI 모델을 직접 서빙할 때의 라우팅을 최적화하고 표준화하기 위한 쿠버네티스 공식 프로젝트입니다. 기존 게이트웨이(Envoy Gateway, kgateway 등)를 추론에 특화된 Inference Gateway로 확장해 주며, 기존의 Gateway와 HTTPRoute 리소스 옆에 모델 서버들의 집합을 나타내는 InferencePool이라는 리소스를 새로 정의합니다. 요청 경로(Path)가 아니라 모델 이름 기반으로 라우팅하는 모델 인지 라우팅, 모델 별 서빙 우선순위 지정, 트래픽 분할을 통한 점진적 모델 롤 아웃 같은 기능을 표준 패턴으로 제공합니다.^[4]

구조의 핵심은 EPP(Endpoint Picker)입니다. 게이트웨이는 요청을 받으면 어느 vLLM 인스턴스로 보낼지 직접 정하지 않고, EPP라는 별도의 판단자에게 묻습니다. EPP는 각 인스턴스에서 대기열 깊이, KV 캐시 사용률 같은 실시간 메트릭을 수집하고 있다가, 요청마다 세 단계 파이프라인으로 최적의 엔드포인트를 골라 줍니다.

먼저 Filter가 조건에 맞지 않는 인스턴스를 걸러냅니다. 다음으로 복수의 Scorer가 남은 인스턴스마다 점수를 매깁니다. 예를 들어 대기 요청이 적은 인스턴스에 높은 점수를 주는 queue-scorer, KV 캐시에 여유가 있는 인스턴스에 높은 점수를 주는 kv-cache-utilization-scorer, 요청의 Prefix 캐시를 가지고 있을 것으로 추정되는 인스턴스에 높은 점수를 주는 prefix-cache-scorer 같은 스코어러를 조합할 수 있습니다. 마지막으로 Picker가 스코어러들의 점수를 가중 결합해 최종 점수가 가장 높은 인스턴스를 선택합니다(max-score-picker).

Samsung Cloud Platform의 Simple AI Inference 서비스는 queue-scorer, kv-cache-utilization-scorer, prefix-cache-scorer를 기준으로 추론 스케줄링을 구현해 운영하고 있으며, 지속적으로 다양한 Scorer 기준을 확장하고 있습니다.

Prefix Cache 기반 라우팅

여기서 앞 장의 KV 캐시 이야기와 라우팅이 만납니다. 캐시를 아무리 잘 쌓아 두어도, 요청이 캐시 없는 인스턴스로 가면 소용이 없기 때문입니다.

prefix-cache-scorer가 흥미로운 점은 기본 방식이 각 인스턴스의 캐시 상태를 직접 들여다보지 않는다는 것입니다. 대신 EPP가 이전에 어떤 요청을 어느 인스턴스로 보냈는지 기록해 두고, “이 인스턴스에 아직 캐시가 남아 있을 것”이라고 추정하는 근사(approximate) 방식을 씁니다. 이 추정만으로도 같은 Prefix를 가진 요청들이 같은 인스턴스로 모이면서 캐시 적중률이 크게 올라갑니다. 나아가 vLLM이 발행하는 KV 블록 생성, 퇴출 이벤트를 구독해 실제 캐시 상태를 추적하는 정밀(precise) 방식으로 발전하고 있습니다.^[6]

Inference-aware Routing의 확장

추론 스케줄링은 부하 분산 외의 역할도 맡습니다. 서비스 등급(SLO)에 따라 우선순위를 조정하고, 요청이 실패하면 같은 경로로 재시도하거나 대체 인스턴스로 자동 전환하며(retry & fallback), 오토스케일링과 연동해 장애나 과부하 상황에서도 서비스 품질을 유지합니다.

여기에 더해, 연산 특성이 다른 Prefill과 Decode 단계를 아예 다른 인스턴스 그룹에서 처리하는 P/D 분리(Prefill/Decode Disaggregation)와, 세대가 다른 GPU와 NPU가 섞인 이기종 환경에서 하드웨어별 특성을 반영해 분배하는 이기종 라우팅도 표준 경로로 자리 잡아가고 있습니다.^[5]

라우팅은 주어진 인스턴스 집합 안에서 최적의 배치를 찾는 기술입니다. 그런데 트래픽 총량 자체가 시간대에 따라 크게 변하는 상황에서는 인스턴스 수를 조절하는 별도의 대응이 필요합니다. 다음 장에서 다룰 탄력성의 문제입니다.

Pain Point ④ 트래픽 변동과 고정된 인프라

LLM 서비스의 트래픽은 하루에도 몇 번씩 출렁입니다. 업무가 몰리는 오전 늦은 시간과 퇴근 무렵에 피크가 오고, 새벽에는 요청이 바닥까지 떨어집니다. 문제는 인프라가 이 곡선을 따라가지 못한다는 데 있습니다.

고정된 수의 인스턴스로 운영하면 선택지는 둘뿐입니다. 피크에 맞추면 나머지 시간에 자원이 남고, 평균에 맞추면 피크 때 대기열이 폭발합니다. 게다가 LLM 추론은 한 번 밀리기 시작하면 회복이 어렵습니다. 대기열에 쌓인 요청들이 KV 캐시를 점유한 채 순서를 기다리고, 그 사이 새 요청은 계속 들어오기 때문입니다. 트래픽의 변동에 맞춰 인프라 역시 유연하게 확장 및 축소될 수 있어야 합니다.

해법 1: 추론 특화 메트릭 기반 GPU 오토스케일링

첫 번째 해법은 오토스케일링입니다. 쿠버네티스 생태계의 KEDA (Kubernetes Event-driven Autoscaling)와 HPA (Horizontal Pod Autoscaler)를 활용해, 부하가 늘면 인스턴스를 자동으로 늘리고 부하가 줄면 다시 회수하는 구조입니다.

여기서 중요한 것은 무엇을 보고 늘리느냐입니다. 전통적인 오토스케일링은 CPU나 GPU 사용률 같은 자원 지표를 기준으로 삼습니다. 그런데 GPU Utilization만으로는 대기열 증가나 KV 캐시 포화처럼 사용자 체감 성능 저하를 선행해서 포착하기 어렵습니다. 따라서 서빙 엔진이 노출하는 대기열 깊이(Queue Depth), KV 캐시 사용률, 대기/실행 요청 수, 지연시간 같은 추론 특화(Inference-aware) 메트릭을 기준으로 오토스케일링을 구현해야 합니다. 서비스 특성에 맞춰 어떤 메트릭이 처리 능력의 한계를 가장 먼저 드러내는지 찾고, 그 신호를 스케일링 판단에 연결하는 것이 핵심입니다.

다만 LLM 오토스케일링에는 고유한 난관이 있습니다. 수십 GB의 모델 가중치를 GPU에 올리는 데 시간이 걸려, 인스턴스를 늘리기로 결정한 시점과 실제로 트래픽을 받는 시점 사이에 공백이 생깁니다. 앞서 소개한 Warm Start처럼 모델을 Sleep 상태로 대기시켰다가 빠르게 깨우는 기술이 이 공백을 줄이는 열쇠가 되고, 나아가 요청이 전혀 없을 때는 인스턴스를 0까지 줄였다가 첫 요청에 다시 깨우는 Scale to Zero로 발전하고 있습니다.

Samsung Cloud Platform의 Simple AI Inference 서비스는 대기열과 KV 캐시 사용률 메트릭을 기준으로 오토스케일링을 구현해 운영하고 있습니다. 대기열이 길어진다는 것은 현재의 처리 능력이 증가하는 수요를 충분히 감당하지 못하고 있다는 의미이고, KV 캐시 사용률이 임계치에 가까워진다는 것은 곧 캐시 퇴출과 성능 저하가 시작된다는 뜻이기 때문입니다.

해법 2: GPU 이상 감지와 작업 이전

탄력성은 트래픽 대응만의 문제가 아닙니다. 수백 장의 GPU를 24시간 돌리다 보면 하드웨어와 소프트웨어 어느 쪽에서든 반드시 이상이 생깁니다. 그리고 LLM 서빙에서 GPU 한 장의 장애는 단순히 처리량이 줄어드는 문제가 아니라, 그 GPU가 들고 있던 세션과 캐시가 사라지는 문제입니다.

그래서 서빙 인프라는 GPU의 하드웨어와 소프트웨어 상태를 지속적으로 모니터링하고 이상 징후를 조기에 감지할 수 있는 체계가 필요합니다. 오류가 발생하면 원인을 분석해 복원을 시도하고, 복원이 불가능한 경우에는 해당 작업을 정상 노드로 자동 이전해 작업 연속성을 유지합니다. 사용자로서는 장애가 있었는지조차 모르게 만드는 것이 목표입니다.

여기까지 자원 효율, 중복 연산, 라우팅, 탄력성이라는 네 가지 Pain Point와 대응 기술을 살펴봤습니다. 마지막 장에서는 이 기술들이 실제 서비스에서 어떻게 조합되는지 살펴봅니다.

이 기술들이 모여 만든 것, 그리고 다음 단계

이러한 서빙 기술이 실제 서비스에 적용된 사례 중 하나가 Samsung Cloud Platform의 Simple AI Inference입니다. Simple AI Inference는 사용자 신청을 기반으로 서버리스 형태로 LLM을 제공하는 Models-as-a-Service로, 앞서 설명한 KV 캐시 오프로드, 추론 스케줄링, 오토스케일링 등의 기술을 실제 운영 환경에 적용해 GPU 자원의 활용 효율과 서비스 안정성을 높이고 있습니다.

사용자는 이러한 인프라 운영의 복잡성을 직접 관리하지 않고, API Key를 발급받아 약정 없이 사용한 토큰만큼 지불하는 온디맨드(Pay-as-you-go) 방식으로 모델을 사용할 수 있습니다. 앞에서 살펴본 기술들은 개별적인 최적화 기법에 머무르지 않고, 실제 인퍼런스 플랫폼을 구성하고 운영하는 기술 요소로 활용되고 있습니다.

서빙 기술의 확장은 계속되고 있습니다. 먼저 서비스의 폭이 넓어집니다. 서버리스와 함께 전용 GPU에서 모델을 서빙하는 Dedicated 인퍼런스, 대량 요청을 모아 처리하는 Batch Inference, 브라우저에서 바로 모델을 시험하는 Chat Playground처럼 사용 형태별 선택지가 늘어납니다. 인프라 측면에서는 여러 모델이 GPU 메모리를 효율적으로 공유하는 기술과 시분할 스케줄링의 적용 범위가 점차 확대되고 있습니다.

하드웨어와 라우팅 기술의 진화도 이어질 전망입니다. GPU를 넘어 NPU 기반의 모델 서빙으로 확장되고, 요청이 없는 구간에는 Scale to Zero를 적용해 유휴 자원에 따른 비용을 최소화하는 방향으로 발전하고 있습니다.

라우팅은 프롬프트의 특성을 분석해 가장 적합한 모델로 요청을 자동 배정하는 방향으로 고도화되고 있습니다. KV 캐시 오프로드는 여러 노드가 캐시를 공유할 수 있는 공유 스토리지 계층(L4)으로 확장되고 있으며, Prefill과 Decode 역시 각각 독립적으로 최적화할 수 있는 분리형 워크로드 구조로 발전하고 있습니다.

마치며

앞으로의 인퍼런스 경쟁은 모델 성능뿐 아니라 동일한 GPU 자원에서 얼마나 안정적으로 처리량을 확보할 수 있는지까지 확대될 것으로 보입니다. 이를 위해 캐시, 스케줄링, 오토스케일링처럼 개별적으로 발전해 온 기술들이 하나의 서빙 플랫폼 안에서 더욱 긴밀하게 결합되고 있습니다.

후속 글에서는 이번 글에서 다룬 기술 가운데 LLM 오케스트레이션과 AI 게이트웨이, 인텔리전트 라우팅, KV Cache 오프로드, Day Zero를 지향하는 모델 파이프라인, AI 콘텐츠 필터링(Guard), 서빙 인프라 운영 등을 실제 구현 관점에서 자세히 다룰 예정입니다.

References

• Artificial Analysis. LLM Leaderboard: Intelligence, Performance & Price Analysis. Artificial Analysis
• Sundar Pichai. (2026.5.). Google I/O 2026: Sundar Pichai's opening keynote. Google
• Kyungmin Bin, et al. (2025). FineServe: Precision-Aware KV Slab and Two-Level Scheduling for Heterogeneous Precision LLM Serving
• Kubernetes SIGs. Gateway API Inference Extension. Kubernetes
• Modular. Prefill-decode disaggregation, LLM Inference Handbook. Modular
• vLLM Team. vLLM Documentation. vLLM
• Samsung SDS. Simple AI Inference, Samsung Cloud Platform 서비스 포탈. Samsung SDS.
• LMCache Team. (2025). LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference. LMCache.

FAQ