IT /AI

vLLM과 SGLang 차이: 서빙 엔진 vs 제어 언어

· 3분 읽기
#AI #LLM #vLLM #SGLang #서빙 #추론

vLLM이랑 SGLang, 왜 자꾸 헷갈렸나

회사에서 LLM 서빙 구조를 검토하게 됐는데, 처음에 vLLM이랑 SGLang을 같은 후보군에 넣고 비교표를 만들려고 했다. 기능 항목을 나열하는데 뭔가 자꾸 안 맞았다. vLLM 쪽은 배칭이나 KV 캐시 이야기가 나오고, SGLang 쪽은 분기 로직이나 상태 관리 이야기가 나오니까 같은 축으로 비교가 안 되는 거다.

한참 삽질하다가 결국 깨달은 건 단순했다. 이 둘은 경쟁 관계가 아니라 아예 다른 층에서 동작하는 도구였다.

결론부터 쓰면

  • vLLM: 모델 추론 요청을 빠르게 처리하는 서빙 엔진. GPU 효율, 배칭, 지연 시간 같은 걸 다룬다.
  • SGLang: 여러 번의 LLM 호출을 하나의 흐름으로 엮는 프로그래밍 레이어. 분기, 반복, 상태 저장 같은 걸 다룬다.

이걸 먼저 잡고 나니까 비교표를 만들겠다는 생각 자체가 좀 잘못됐다는 게 보였다.

왜 같은 것처럼 보이냐면

둘 다 “LLM 성능을 개선한다”는 맥락에서 같이 언급되기 때문이다. 블로그 글이나 발표 자료에서도 나란히 등장하는 경우가 많아서, 처음 접하면 당연히 같은 범주라고 생각하게 된다.

근데 실제로 각각이 신경 쓰는 질문은 다르다.

  • vLLM: “이 추론 요청 하나를 어떻게 하면 더 빠르고 효율적으로 처리하지?”
  • SGLang: “이 추론 호출 여러 개를 어떤 순서로, 어떤 조건으로 연결하지?”

내가 비교표에서 느꼈던 어색함이 정확히 여기서 온 거였다. 한쪽은 인프라 레벨이고 다른 한쪽은 애플리케이션 로직 레벨이니까.

vLLM 쪽을 보게 되는 상황

실제로 vLLM을 찾아보게 된 건 동시 요청이 늘어나면서 GPU 사용률이 문제가 됐을 때였다. 이런 고민이 있으면 vLLM 쪽이다.

  • 동시 요청이 많아서 GPU를 더 효율적으로 써야 할 때
  • 같은 모델을 여러 사용자가 동시에 호출할 때
  • 응답 지연 시간을 줄여야 할 때
  • KV 캐시 관리나 배칭이 병목일 때

vLLM의 핵심은 PagedAttention 같은 기법으로 KV 캐시를 메모리 효율적으로 관리하고, 동적 배칭으로 처리량을 올리는 것이다. OpenAI 호환 API도 지원해서 기존 호출 코드를 크게 바꾸지 않아도 된다.

처음에 “추론 엔진”이라는 표현을 봤을 때 뭔 소린가 싶었는데, 써보고 나니까 정말 딱 그 표현이 맞다. 앱 로직을 짜는 게 아니라, 정해진 요청을 빠르게 처리하는 기반을 까는 거다.

SGLang 쪽을 보게 되는 상황

SGLang은 단순히 모델 한 번 호출해서 끝나는 게 아니라, 여러 단계를 거쳐야 하는 구조를 만들 때 의미가 있다.

  • 먼저 분류하고, 그 결과에 따라 다른 프롬프트를 보내야 할 때
  • 중간 결과를 저장했다가 다음 단계에서 다시 써야 할 때
  • 조건 분기, 반복, 도구 호출을 섞어야 할 때

그러니까 SGLang은 “모델 하나”보다 “LLM을 포함한 프로그램”을 짜는 도구에 가깝다. 에이전트 같은 구조를 만들 때 자연스럽게 검토 대상이 된다.

레이어로 그려보면 바로 보인다

내가 이해가 확 된 순간은 이걸 층위로 그려봤을 때였다.

Application / Workflow
        ↑
     SGLang
        ↑
     LLM API
        ↑
      vLLM
        ↑
      GPU

SGLang은 위에서 흐름을 만들고, vLLM은 아래에서 추론 성능을 받쳐준다. 그러니까 둘이 충돌할 이유가 없다.

실무에서는 같이 쓰는 경우

이 구조가 납득이 간 건 실제로 같이 쓰는 예시를 봤을 때다.

  • SGLang에서 단계별 프롬프트와 상태를 관리
  • 실제 모델 호출은 vLLM 서버가 처리
  • 결과를 다시 SGLang 흐름으로 넘겨서 다음 단계를 결정

이 경우 두 도구는 같은 자리를 두고 경쟁하는 게 아니라, 오케스트레이션과 서빙을 나눠 맡는 조합이다.

내 나름의 판단 기준

이걸 정리하고 나서 나한테 남은 기준은 꽤 단순하다.

모델 호출 속도랑 GPU 효율이 급한 문제면 vLLM을 먼저 본다. 호출 흐름이 복잡하고 분기나 상태 관리가 필요하면 SGLang을 먼저 본다. 서비스 규모가 있으면서 흐름도 복잡하면 둘 다 쓴다.

처음에 이 둘을 같은 표에 넣고 비교하려던 게 지금 돌아보면 좀 웃기다. 도구 이름만 보고 판단하지 말고, 그 도구가 해결하려는 병목이 뭔지를 먼저 봤어야 했다. 그래야 비교가 안 꼬인다.