SGLang은 vLLM보다 빠를까 Ollama 다음 단계에서 봐야 할 로컬 LLM 서빙 엔진 선택 기준

로컬 LLM을 혼자 테스트할 때는 Ollama가 가장 쉽지만, 여러 사용자가 동시에 쓰는 서비스가 되면 서빙 엔진의 병목이 바로 비용과 응답속도로 드러난다. 이번 글은 괴발자 소개 자료의 SGLang 내용을 출발점으로 삼아 SGLang, vLLM, Ollama의 역할을 실무 기준으로 나눠 본다.

▶

왜 갑자기 SGLang을 봐야 하나

소개 자료의 핵심 주장은 단순하다. 기존에 Ollama보다 빠른 선택지로 vLLM을 소개했는데, 이제는 vLLM보다 높은 처리량과 낮은 지연시간을 보인다는 SGLang도 함께 봐야 한다는 것이다. 공식 논문 초록은 SGLang이 여러 대형 언어모델·멀티모달 모델 작업에서 기존 추론 시스템보다 최대 6.4배 높은 처리량을 보였다고 설명한다.

다만 이 숫자는 곧바로 “내 컴퓨터에서도 6.4배 빠르다”는 뜻이 아니다. 모델 크기, GPU 종류, 동시 요청 수, 입력 길이, 출력 길이, 캐시 재사용률, 양자화 방식에 따라 결과가 바뀐다. 그래서 이 글의 관점은 “누가 더 빠르냐”보다 “어떤 상황에서 무엇을 고를 것인가”에 둔다.

SGLang의 핵심은 RadixAttention이다

대형 언어모델은 답변을 만들 때 이전 토큰의 계산 결과를 계속 참조한다. 이때 재계산을 줄이기 위해 쓰는 임시 기억 공간이 KV cache다. 문제는 여러 요청에서 비슷한 앞부분, 예를 들어 같은 시스템 프롬프트, 같은 문서 묶음, 같은 대화 이력, 같은 검색 결과가 반복될 때다. 매번 처음부터 계산하면 GPU는 같은 일을 계속 반복한다.

SGLang의 RadixAttention은 이 반복 구간을 기수 트리 방식으로 관리해, 이전 요청에서 만들어진 KV cache를 다음 요청에서 더 잘 재사용하려는 접근이다. 해당 설명의 비유처럼, 한 번 처리한 업무 경험을 매번 지워버리는 직원이 아니라, 비슷한 업무가 들어오면 이전 기억을 꺼내 쓰는 직원에 가깝다.

Ollama, vLLM, SGLang은 같은 문제를 풀지만 역할이 다르다

따라서 SGLang을 Ollama의 대체재로만 보면 판단이 흐려진다. Ollama는 로컬 모델 실행 경험을 낮은 문턱으로 만든 도구다. 반면 vLLM과 SGLang은 모델을 서비스처럼 제공하는 엔진에 더 가깝다. 사내 여러 사람이 같은 모델을 API로 쓰거나, 웹 서비스 뒤에서 모델이 계속 요청을 받아야 할 때 비교 대상이 된다.

설치와 첫 실행은 어렵지 않지만, 운영은 별도 문제다

SGLang 공식 문서는 Python 3.10 이상 환경에서 pip 또는 uv로 설치하는 흐름을 안내한다. NVIDIA GPU 일반 환경은 다음과 같은 식으로 시작할 수 있다.

pip install --upgrade pip
pip install uv
uv pip install sglang

python3 -m sglang.launch_server \
  --model-path qwen/qwen2.5-0.5b-instruct \
  --host 0.0.0.0 \
  --port 30000

서버가 뜨면 OpenAI 호환 엔드포인트로 요청할 수 있다. 기존 OpenAI SDK 기반 코드가 있다면 base_url만 로컬 주소로 바꿔 테스트할 수 있다는 점이 장점이다.

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen/qwen2.5-0.5b-instruct",
    "messages": [{"role":"user","content":"한국어로 세 문장 요약해줘."}]
  }'

성능 비교는 “내 workload”로 해야 한다

소개 자료에서는 같은 프롬프트를 기준으로 Ollama, vLLM, SGLang의 성능을 비교한다. 이런 비교는 입문자가 감을 잡기에는 좋다. 그러나 실제 서비스에서는 단일 프롬프트 한 번보다 아래 조건이 더 중요하다.

SGLang은 자체 bench_serving 도구로 처리량, 첫 토큰까지 걸리는 시간, 토큰 간 지연, 요청별 전체 지연을 측정할 수 있다. vLLM도 벤치마크 도구와 운영 사례가 풍부하다. 결국 선택은 “유튜브에서 빠르다고 했다”가 아니라 같은 모델, 같은 GPU, 같은 요청 패턴으로 직접 재본 결과로 내려야 한다.

누가 SGLang을 먼저 검토하면 좋을까

로컬 LLM 서버 도입 체크리스트

• 첫째, 모델 크기와 메모리부터 계산한다. 7B급은 실험이 쉽지만, 32B·70B급으로 갈수록 GPU 메모리와 양자화 전략이 핵심이 된다.
• 둘째, 요청 패턴을 기록한다. 평균 입력 길이, 출력 길이, 동시 사용자 수, 반복되는 프롬프트 비율을 먼저 숫자로 잡는다.
• 셋째, Ollama에서 시작하되 API 서버 전환 시점을 정한다. 개인 실험이 팀 도구가 되는 순간 vLLM·SGLang 비교가 필요하다.
• 넷째, 외부 공개 전 보안을 분리한다. 인증, 방화벽, 프록시, 로그에 남는 개인정보, 모델 라이선스를 확인한다.
• 다섯째, 속도보다 안정성을 같이 본다. 하루 1시간 빠른 서버보다 일주일 내내 죽지 않는 서버가 실무에서는 더 중요하다.

마지막 판단

SGLang은 이름부터 낯설지만, 문제의식은 명확하다. LLM 서비스에서 반복되는 계산을 줄이고, 긴 컨텍스트와 구조화 출력을 더 효율적으로 처리하겠다는 것이다. 소개 자료의 표현처럼 vLLM보다 빠른 결과가 나오는 경우가 있을 수 있고, 공식 문서와 논문도 고성능 서빙 프레임워크라는 방향을 분명히 보여준다.

다만 개인 사용자에게 가장 좋은 첫 선택은 여전히 Ollama일 수 있다. 설치, 모델 다운로드, 간단한 채팅까지의 속도가 빠르기 때문이다. 반대로 사내 API 서버, RAG, 에이전트, 멀티턴 챗봇을 운영한다면 이제는 vLLM만 볼 것이 아니라 SGLang도 비교 목록에 넣을 시점이다. 좋은 결론은 “SGLang이 무조건 정답”이 아니라 “내 요청 패턴에서 SGLang이 값을 하는지 재보자”다.