SGLang은 지난 2년 사이 추론 배포 현장에서 피하기 어려운 오픈소스 프레임워크가 됐습니다. 같은 GPU에서도 멀티턴 대화, 에이전트, 구조화 출력 같은 부하에서는 순수한 배포보다 확실히 빠른 경우가 드물지 않습니다. 다만 이것은 채팅 제품이 아니라 GPU와 튜닝, 상시 관리가 필요한 추론 엔진입니다. 셀프 호스팅 가치가 있는지는 먼저 요청의 모양을, 다음으로 운영을 감당할 수 있는지를 봐야 합니다.
공식 저장소 정보
- 플랫폼: GitHub
- 조직: sgl-project
- 프로젝트: sglang
- 배경: LMSYS 팀이 시작했고 UC 버클리 등 기관 연구자들과 함께 발전 중
- 라이선스: Apache 2.0, 상업적 사용에 우호적
- 위치: 대형 언어 모델과 멀티모달 모델을 위한 고성능 서빙 프레임워크, OpenAI 스타일 호환 인터페이스 제공
왜 떴는가: 남들이 다시 계산하는 곳에서 빠르다
대부분의 추론 프레임워크는 각 요청을 새 문제로 보고 처음부터 계산합니다. SGLang의 핵심인 RadixAttention은 이미 계산한 프롬프트 접두사의 KV 캐시를 기수 트리에 저장해, 새 요청의 접두사가 같으면 같은 시스템 프롬프트든, 같은 문서의 앞부분이든, 대화에서 이미 오간 내용이든 다시 계산하지 않고 재사용합니다. 공식 논문은 에이전트 제어, JSON 디코딩 같은 작업에서 최대 수 배 규모의 처리량을 보고했지만, 실제 차이는 재사용 가능한 접두사가 트래픽에 얼마나 있느냐에 달려 있습니다.
두 번째 강점은 구조화 생성입니다. JSON 스키마, 정규식, 문법 제약을 따라 출력시킬 때 압축 유한 상태 기계로 디코딩을 가속해 출력이 벗어나는 일도 줄입니다. 필드를 대량으로 뽑거나 도구 호출 체인을 돌리는 제품이라면 맨 채팅 인터페이스보다 훨씬 실용적입니다. 연속 배칭, 텐서 병렬, FP8과 INT4 같은 양자화 지원까지 갖춰 단발 기술이 아닌 운영급 추론 스택 전체를 지향합니다.
맞는 사람, 맞지 않는 사람
요청량이 이미 붙었고 접두사 중복이 많은 팀에 맞습니다. 멀티턴 상담과 대화, 긴 시스템 프롬프트를 가진 에이전트, 같은 문서 묶음을 반복 조립하는 RAG 같은 장면에서는 셀프 호스팅 한 세트로 토큰 단가가 실제로 내려갑니다. 클라우드 종량제 인터페이스를 쓰면서 호출량이 아직 작다면 무리해서 끼어들지 마세요. 인터페이스 요금이 상시 켜진 GPU보다 훨씬 쌉니다. 자기 컴퓨터에 채팅 창 하나 띄우고 싶은 개인 사용자에게도 맞지 않습니다. 최종 사용자용 화면이 없으며, 그건 Open WebUI나 LibreChat 같은 프로젝트의 자리입니다.
배포 비용과 실제 함정
첫 번째 청구서는 GPU입니다. 서버 인스턴스 하나는 모델 하나만 맡으므로 모델이 둘이면 프로세스 둘과 VRAM 두 몫이 필요하고, 70B급을 돌리려면 다중 GPU와 텐서 병렬 튜닝을 피할 수 없습니다. 두 번째는 릴리스 속도입니다. 새 모델과 새 양자화 형식 반영이 빠르고 업그레이드 이득도 크지만, 인터페이스와 매개변수도 움직입니다. 운영 환경에서는 버전을 고정하고 회귀 테스트 후 올리세요. 최신 자동 추종은 금물입니다. 세 번째 함정은 이득 오판입니다. 요청끼리 공통 접두사가 거의 없다면, 예컨대 독립적인 짧은 질문뿐이라면 RadixAttention의 우위는 많이 줄어듭니다. 논문 숫자가 아니라 실제 트래픽으로 측정하고 결정하세요. 네 번째는 운영 자체로, 로그, 속도 제한, GPU 장애 전환, 가중치 관리까지 전부 직접 떠안아야 하며 클라우드 인터페이스의 편함은 없습니다.
결론은 분명합니다. 트래픽이 크고 접두사 재사용이 많고 팀에 GPU를 다룰 사람이 있다면 셀프 호스팅할 가치가 있고, 일찍 옮길수록 절약도 커집니다. 트래픽이 작거나 부하가 잡다하면 당분간 호스팅 인터페이스를 계속 쓰고, 청구서가 정말 아파질 때 이 글을 다시 봐도 늦지 않습니다.
