AI 서빙: vLLM과 SGLang을 고르는 기준

모델이 GPU에서 실행된다고 서비스 준비가 끝난 것은 아닙니다. 혼자 쓸 때는 빨랐던 챗봇도 사용자가 늘면 첫 답이 늦고 문장이 끊길 수 있습니다. 요청을 어떻게 묶고, GPU 메모리를 어떻게 나누며, 긴 질문과 짧은 질문을 어떤 순서로 처리하느냐가 달라지기 때문입니다.

AI 서빙은 학습을 마친 모델을 여러 사용자가 안정적으로 쓸 수 있게 운영하는 일입니다. LLM에서는 vLLM과 SGLang 같은 서빙 엔진이 요청을 정리하고 GPU를 효율적으로 쓰는 핵심 작업을 맡습니다.

vLLM과 SGLang은 현재 지원하는 기능이 상당 부분 겹칩니다. 이름만 보고 우열을 정하기보다 목표 모델의 지원 여부와 실제 요청의 입력·출력 길이, 동시 요청 수를 기준으로 비교해야 합니다. 이 글에서는 두 엔진의 차이와 선택 순서를 정리합니다.

AI 서빙 엔진은 무엇을 하나?

사용자가 프롬프트를 보내면 API 서버가 요청을 받아 서빙 엔진에 넘깁니다. 서빙 엔진은 대기 중인 요청을 묶어 처리 순서를 정하고, 이미 계산한 문맥은 KV 캐시에 보관합니다. GPU에서 생성된 토큰은 서빙 엔진을 거쳐 사용자에게 전달됩니다.

그림 1. LLM 서빙 엔진이 요청을 처리하는 순서.

일반적인 API 요청은 응답을 한 번 만든 뒤 끝나지만, LLM은 입력을 읽는 prefill과 다음 토큰을 하나씩 만드는 decode를 차례로 거칩니다. 요청마다 입력과 출력 길이도 다릅니다. 먼저 끝난 요청을 배치에서 빼고 새 요청을 넣는 연속 배치가 필요한 이유입니다.

KV 캐시도 중요합니다. 모델은 이미 읽은 토큰을 매번 다시 계산하지 않도록 중간 결과를 GPU 메모리에 저장합니다. 대화가 길어지거나 동시 요청이 늘면 이 캐시가 빠르게 커집니다. 서빙 엔진은 제한된 메모리를 요청별로 나누고, 반복되는 문맥을 재사용합니다.

LLM 서빙 성능은 초당 토큰 수만으로 판단하기 어렵습니다.

vLLM과 SGLang은 무엇이 다른가?

vLLM은 PagedAttention으로 널리 알려졌습니다. KV 캐시를 작은 블록으로 나누고 요청이 실제로 쓰는 만큼 배정합니다. 연속된 큰 메모리 공간을 미리 잡지 않아 낭비와 단편화를 줄입니다.

지금의 vLLM은 PagedAttention만 제공하는 엔진이 아닙니다. Automatic Prefix Caching으로 여러 요청이 공유하는 프리픽스의 KV 캐시를 재사용하고, 구조화 출력도 지원합니다. 지원하는 모델과 하드웨어가 넓고 문서와 운영 사례가 많다는 점이 실용적인 장점입니다.

SGLang은 여러 요청이 공유하는 프리픽스의 KV 캐시를 RadixAttention으로 재사용합니다. 같은 시스템 프롬프트나 RAG 문서가 반복되면 radix tree에서 공통 부분을 찾아 prefill 계산을 줄입니다. 다만 vLLM도 같은 목적의 캐시를 지원하므로 반복 프리픽스가 있다는 이유만으로 SGLang이 더 빠르다고 단정할 수는 없습니다.

SGLang도 연속 배치와 블록 기반 KV 캐시, 구조화 출력을 지원하는 범용 서빙 엔진입니다. 최근에는 에이전트 워크로드와 대형 MoE 모델을 위한 실행 방법과 최적화가 빠르게 추가되고 있습니다.

그림 2. vLLM과 SGLang의 설계 출발점. 현재는 두 엔진의 기능이 상당 부분 겹칩니다.

vLLM과 SGLang 중 무엇을 선택할까?

다음 세 가지 질문으로 후보를 줄일 수 있습니다.

1. 모델이 정해졌습니까? 먼저 모델 카드와 엔진의 지원 목록을 확인합니다. 별도 fork나 개발용 Docker 이미지에 의존하면 설치는 가능해도 이후 업데이트와 장애 대응이 어려워집니다.

2. 프롬프트 앞부분이 얼마나 반복됩니까? 두 엔진 모두 프리픽스 캐시를 지원합니다. 공통 시스템 프롬프트나 RAG 문서가 길다면 두 엔진에서 캐시 적중률과 TTFT를 비교해야 합니다. 출력이 길어 decode가 대부분을 차지하면 프리픽스 캐시의 효과는 작을 수 있습니다.

3. 운영팀이 어디까지 검증할 수 있습니까? 여러 모델을 빠르게 검토한다면 지원 범위와 문서가 넓은 쪽이 유리합니다. 한 모델을 오래 운영한다면 설정이 복잡하더라도 실제 성능 향상이 있는지 검증할 가치가 있습니다.

최신 오픈웨이트 모델은 어디까지 지원하나?

모델 가중치가 공개됐다고 최신 안정판에서 바로 실행되는 것은 아닙니다. 아래 표는 2026년 7월 30일 기준 vLLM v0.26.0과 SGLang v0.5.16, 공식 모델 카드를 대조한 결과입니다.

✓는 엔진 안정판이나 모델 개발자가 작성한 안내에서 별도 fork 없이 실행하는 방법을 확인한 경우입니다. △는 별도 fork나 개발용 Docker 이미지가 필요한 경우, —는 공식 실행 방법을 확인하지 못한 경우입니다. Hugging Face가 자동으로 보여 주는 일반 실행 예시는 판정 근거에서 제외했습니다.

최근 공개된 주요 모델

국내 주요 모델

AAII는 Artificial Analysis Intelligence Index v4.1의 reasoning mode 점수입니다. *는 독립 평가가 끝나지 않은 추정치입니다. 미평가는 0점이 아니라 2026년 7월 28일까지 해당 모델의 평가 페이지를 확인하지 못했다는 뜻입니다.

지원 여부만큼 어떤 버전으로 실행하는지도 중요합니다. Solar Open 2와 Motif-3 Beta는 별도의 vLLM fork나 Docker 이미지가 필요하고, EXAONE 4.5와 A.X K1도 SGLang에서 별도 fork를 안내합니다. MiniMax-M3는 SGLang 안정판에 코드가 들어갔지만 아직 개발용 이미지를 사용해야 합니다. 운영 전에 실행 명령이 안정판을 대상으로 하는지 확인해야 합니다.

무엇이 더 빠른지는 어떻게 확인할까?

모델 체크포인트와 GPU, 정밀도, 입력·출력 분포, 동시 요청 수를 모두 밝힌 최신 비교 자료는 생각보다 드뭅니다. 엔진 개발팀의 벤치마크는 각 기능의 효과를 확인하는 데 유용하지만, 조건이 다른 숫자를 한 줄에 놓고 순위를 매길 수는 없습니다. GPU 종류조차 밝히지 않은 커뮤니티 결과는 후보를 고르는 근거로 쓰기 어렵습니다.

비교 결과에는 적어도 다음 조건이 들어가야 합니다.

• 모델 체크포인트, 정밀도와 양자화 방식

• GPU와 드라이버, 엔진 버전과 실행 이미지

• 실제 서비스의 입력·출력 길이 분포

• 초당 요청 수와 동시 요청 수

• 공통 프리픽스의 길이와 캐시 적중률

• P95·P99 TTFT, ITL, 오류율과 유효 처리량

최대 처리량이 높아도 요청이 몰릴 때 첫 토큰이 늦거나 오류가 늘면 서비스에는 쓰기 어렵습니다. 마지막에는 서비스 목표를 만족한 출력 토큰을 기준으로 비용을 계산해야 합니다.

유효 토큰당 비용 = 전체 GPU 시간 비용 ÷ 지연시간과 품질 목표를 만족한 요청의 출력 토큰 수

정리

먼저 목표 모델의 공식 지원 경로를 확인합니다. 두 엔진이 모두 지원한다면 실제 입력·출력 길이와 동시 요청 수로 TTFT, ITL과 유효 처리량을 측정합니다. 호환성과 운영 편의가 우선이면 vLLM을 기준선으로 삼고, 목표 모델에 SGLang용 실행 방법이나 최적화가 잘 갖춰져 있다면 SGLang도 함께 비교합니다.

매니코어소프트는 모델과 실제 요청 분포를 바탕으로 GPU 구성과 서빙 엔진을 비교하고, 배포부터 운영까지 하나의 환경으로 구축합니다.

함께 읽을 글

• AI 오케스트레이터란? GPU 클러스터 운영의 2026년 흐름

• AI 토큰이란? 토큰 하나가 데이터센터에서 쓰는 시간·돈·전력

참고 자료

• vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention

• vLLM 공식 문서: 기능

• vLLM 공식 문서: 지원 모델

• SGLang: Efficient Execution of Structured Language Model Programs

• SGLang 공식 문서

• SGLang 공식 문서: 지원 모델

• vLLM v0.26.0 릴리스

• SGLang v0.5.16 릴리스

• Artificial Analysis 모델 리더보드