AI 서빙이란? vLLM과 SGLang을 고르는 기준
모델이 GPU에서 실행된다고 서비스 준비가 끝난 것은 아닙니다. 혼자 쓸 때는 빨랐던 챗봇도 사용자가 늘면 첫 답이 늦고 문장이 끊길 수 있습니다. 요청을 어떻게 묶고, GPU 메모리를 어떻게 나누며, 긴 질문과 짧은 질문을 어떤 순서로 처리하느냐가 달라지기 때문입니다.
AI 서빙은 학습을 마친 모델을 여러 사용자가 안정적으로 쓸 수 있게 운영하는 일입니다. LLM에서는 vLLM과 SGLang 같은 서빙 엔진이 요청을 정리하고 GPU를 효율적으로 쓰는 핵심 작업을 맡습니다.
모델과 트래픽 조건이 아직 열려 있다면 vLLM으로 기준선을 만들기 좋습니다. 긴 시스템 프롬프트가 반복되거나 에이전트 워크플로와 특정 대형 MoE 모델의 최적화가 중요하다면 SGLang을 고려해야 합니다. 다만 엔진 이름만으로 성능을 결정할 수는 없습니다. 모델과 GPU, 입력 길이, 동시 요청 수가 바뀌면 결과도 달라집니다.
AI 서빙 엔진은 무엇을 하나?
사용자가 프롬프트를 보내면 API 서버가 요청을 확인하고 서빙 엔진에 넘깁니다. 서빙 엔진은 대기 중인 요청을 묶고 처리 순서를 정합니다. 이미 계산한 문맥은 KV 캐시에 보관하며, GPU가 만든 토큰을 다시 사용자에게 전달합니다.
그림 1. LLM 서빙 엔진이 요청을 처리하는 순서.
일반적인 웹 요청은 한 번 처리하면 끝납니다. LLM은 입력을 읽는 prefill과 다음 토큰을 하나씩 만드는 decode를 거칩니다. 요청마다 입력과 출력 길이도 다릅니다. 먼저 끝난 요청을 배치에서 빼고 새 요청을 넣는 연속 배치가 필요한 이유입니다.
KV 캐시도 중요합니다. 모델은 이미 읽은 토큰을 매번 다시 계산하지 않도록 중간 결과를 GPU 메모리에 저장합니다. 대화가 길어지거나 동시 요청이 늘면 이 캐시가 빠르게 커집니다. 서빙 엔진은 제한된 메모리를 요청별로 나누고, 반복되는 문맥을 재사용합니다.
성능은 초당 토큰 하나로 설명하기 어렵습니다.
| 지표 | 무엇을 뜻하나 | 사용자가 느끼는 차이 |
|---|---|---|
| 첫 토큰 지연시간(TTFT) | 요청부터 첫 토큰까지 걸린 시간 | 답변을 기다리는 시간 |
| 토큰 간 지연시간(ITL) | 출력 토큰 사이의 시간 | 답변이 끊기지 않는 정도 |
| 전체 처리량 | 일정 시간에 처리한 요청 또는 토큰 | GPU 한 대가 감당하는 부하 |
| 유효 처리량(goodput) | 지연시간과 오류율 목표를 만족한 처리량 | 실제 서비스에 쓸 수 있는 처리량 |
vLLM과 SGLang은 무엇이 다른가?
vLLM은 PagedAttention으로 널리 알려졌습니다. KV 캐시를 작은 블록으로 나누고 요청이 실제로 쓰는 만큼 배정합니다. 연속된 큰 메모리 공간을 미리 잡지 않아 낭비와 단편화를 줄입니다.
지금의 vLLM은 PagedAttention만 제공하는 엔진이 아닙니다. 프리픽스 캐시와 구조화 출력도 지원합니다. 지원 모델과 하드웨어가 넓고 문서와 운영 사례가 많다는 점이 가장 실용적인 장점입니다.
SGLang은 RadixAttention에서 출발했습니다. 여러 요청이 공유하는 프리픽스와 KV 캐시를 radix tree에 저장합니다. 같은 시스템 프롬프트, few-shot 예시, RAG 문서가 반복되는 서비스라면 앞부분을 다시 계산하지 않고 재사용할 수 있습니다.
SGLang도 현재는 범용 서빙 엔진입니다. 연속 배치와 블록 기반 KV 캐시, 구조화 출력을 지원합니다. 특히 대형 MoE 모델, 프리픽스 재사용과 복잡한 에이전트 워크로드에 맞춘 기능이 빠르게 추가됩니다.
그림 2. vLLM과 SGLang의 설계 출발점. 현재는 두 엔진의 기능이 상당 부분 겹칩니다.
| 판단 기준 | vLLM | SGLang |
|---|---|---|
| 설계의 출발점 | PagedAttention으로 KV 캐시 메모리 효율 개선 | RadixAttention으로 반복 프리픽스 재사용 |
| 처음 검토하기 좋은 상황 | 모델과 하드웨어가 아직 열려 있고 호환성이 중요할 때 | 목표 모델과 반복되는 요청 구조가 분명할 때 |
| 강점이 잘 드러나는 워크로드 | 여러 공개 모델을 바꿔 가며 검토하는 환경, 일반 채팅과 배치 | 긴 공통 프리픽스, 에이전트, 대형 MoE |
| 운영에서 볼 점 | 모델·양자화·GPU 조합별 지원 차이 | 모델별 권장 설정과 빠른 버전 변화 |
vLLM과 SGLang 중 무엇을 선택할까?
다음 세 가지 질문으로 후보를 줄일 수 있습니다.
- 모델이 정해졌습니까? 먼저 모델 카드와 엔진의 지원 목록을 확인합니다. 별도 fork나 전용 Docker 이미지가 필요하면 설치보다 업데이트와 장애 대응 비용이 커집니다.
- 프롬프트 앞부분이 얼마나 반복됩니까? 공통 시스템 프롬프트와 RAG 문서가 길고 자주 재사용된다면 SGLang을 우선 비교할 이유가 생깁니다. 반복이 적으면 프리픽스 캐시만으로 큰 차이가 나지 않을 수 있습니다.
- 운영팀이 감당할 설정 범위는 어디까지입니까? 여러 모델을 빠르게 검토하려면 넓은 호환성과 문서가 중요합니다. 한 모델을 오래 운영하며 세밀하게 튜닝한다면 더 많은 설정을 검증할 가치가 있습니다.
최신 오픈웨이트 모델은 어디까지 지원하나?
모델 가중치가 공개됐다고 최신 안정판에서 바로 실행되는 것은 아닙니다. 아래 표는 2026년 7월 28일 기준 vLLM v0.26.0과 SGLang v0.5.16, 공식 모델 카드를 대조한 결과입니다.
✓는 공식 배포판이나 모델 카드에서 실행 방법을 확인한 경우, △는 모델 개발사가 제공한 별도 fork나 Docker 이미지가 필요한 경우, —는 공식 실행 방법을 확인하지 못한 경우입니다.
최근 공개된 주요 모델
| 모델(AAII) | 공개일 | 구조·파라미터 | vLLM | SGLang |
|---|---|---|---|---|
| Kimi K3 (57) | 2026-07-27 가중치 공개 | MoE · 2.8T / 104B active | ✓ | ✓ |
| Inkling (41) | 2026-07-15 | MoE · 975B / 41B active | ✓ | ✓ |
| Hy3 (41*) | 2026-07-06 | MoE · 295B / 21B active | ✓ | ✓ |
| GLM-5.2 (51) | 2026-06-16 | MoE · 753B / 40B active | ✓ | ✓ |
| Kimi K2.7 Code (42) | 2026-06-12 | MoE · 1T / 32B active | ✓ | ✓ |
| MiniMax-M3 (44) | 2026-06-01 | MoE · 428B / 23B active | ✓ | ✓ |
| Qwen3.6-35B-A3B (32) | 2026-04-16 | MoE · 36B / 3B active | ✓ | ✓ |
국내 주요 모델
| 모델(AAII) | 공개일 | 구조·파라미터 | vLLM | SGLang |
|---|---|---|---|---|
| Solar Open 2 250B (미평가) | 2026-07-22 | MoE · 250B / 15B active | △ | — |
| Motif-3 Beta (44) | 2026-07-21 | MoE · 314B / 13B active | △ | — |
| EXAONE 4.5 33B (23*) | 2026-04-09 | Dense · 34.4B | ✓ | △ |
| Kanana 2 30B-A3B Thinking (미평가) | 2026-01-15 | MoE · 30B / 3B active | ✓ | ✓ |
| A.X K1 (미평가) | 2025-12-29 | MoE · 519B / 33B active | ✓ | △ |
| HyperCLOVA X SEED Think 32B (17*) | 2025-12-26 | Dense · 33.3B | ✓ | — |
| VAETKI (미평가) | 2025-12-16 | MoE · 112.2B / 10.1B active | — | — |
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를 안내합니다. 운영 전에는 공식 명령이 엔진의 안정판을 대상으로 하는지 확인해야 합니다.
무엇이 더 빠른지는 어떻게 확인할까?
모델 체크포인트와 GPU, 정밀도, 입력·출력 분포, 동시 요청 수를 모두 밝힌 최신 비교 자료는 생각보다 드뭅니다. 엔진 개발팀의 벤치마크는 각 기능의 효과를 확인하는 데 유용하지만, 조건이 다른 숫자를 한 줄에 놓고 순위를 매길 수는 없습니다. GPU 종류조차 밝히지 않은 커뮤니티 결과는 후보를 고르는 근거로 쓰기 어렵습니다.
비교 결과에는 적어도 다음 조건이 들어가야 합니다.
- 모델 체크포인트, 정밀도와 양자화 방식
- GPU와 드라이버, 엔진 버전과 실행 이미지
- 실제 서비스의 입력·출력 길이 분포
- 초당 요청 수와 동시 요청 수
- 공통 프리픽스의 길이와 캐시 적중률
- P95·P99 TTFT, ITL, 오류율과 유효 처리량
최대 처리량이 높아도 요청이 몰릴 때 첫 토큰이 늦거나 오류가 늘면 서비스에는 쓰기 어렵습니다. 마지막에는 서비스 목표를 만족한 출력 토큰을 기준으로 비용을 계산해야 합니다.
유효 토큰당 비용 = 전체 GPU 시간 비용 ÷ 지연시간과 품질 목표를 만족한 요청의 출력 토큰 수
정리
모델과 트래픽이 정해지지 않았다면 vLLM으로 기준선을 만들기 좋습니다. 반복 프리픽스와 에이전트 워크플로, 특정 대형 MoE 모델의 최적화가 중요하다면 SGLang을 고려합니다. 그다음에는 실제 요청 분포로 두 엔진의 지연시간과 유효 처리량을 측정해 결정합니다.
매니코어소프트는 모델과 트래픽에 맞는 GPU 서버, 서빙 엔진, 배포와 운영 환경을 함께 구축합니다. AI 인프라 도입이나 LLM 서빙 환경을 검토하고 있다면 AI 인프라 구축 문의에서 상의할 수 있습니다.