SGLANG 썸네일형 리스트형 SGLang vs vLLM, 어떤 추론 엔진을 써야 하나 LLM을 직접 서빙하려고 vLLM을 붙였다가 응답 속도가 생각보다 안 나온다는 분들, SGLang 얘기 한 번쯤 들어보셨을 텐데요. 두 엔진 다 실사용 벤치마크를 찾을 수 있는 만큼 다 찾아봤고, 수치가 벤치마크 조건마다 꽤 갈리길래 어떤 조건에서 어떤 결과가 나오는지, 그리고 실제로 프로덕션에서 어떤 회사들이 어떻게 쓰고 있는지까지 같이 정리했어요. 핵심 비교부터 표로 보여드릴게요.한눈에 보는 비교표항목vLLMSGLang핵심 기술페이지드어텐션 (KV 캐시 블록 분할)래딕스어텐션 (프리픽스 캐시 재사용)8B급 모델 처리량 (PremAI 측정)초당 12,500토큰초당 16,200토큰 (+29%)70B급 모델 처리량 격차기준+3~5% (격차 축소)단일 턴(캐시 미스) 처리량초당 60토큰 (우위)초당 52.7.. 더보기 vLLM vs SGLang: 프로덕션 LLM 서빙 프레임워크 완전 비교 DeepSeek V4가 MIT 라이선스로 공개되면서 자체 서버에 LLM을 올리려는 팀이 급증했습니다. 그 순간 반드시 마주치는 질문이 하나 있습니다. vLLM이냐 SGLang이냐. 둘 다 오픈소스에 OpenAI 호환 API를 제공하는데, 무엇을 골라야 하는지 기준이 없으면 잘못된 선택을 하고 나중에 마이그레이션하게 됩니다. 직접 숫자를 뜯어보고 정리했습니다.핵심 요약두 프레임워크를 한 줄로 정리하면, vLLM은 프로덕션 기본값이고 SGLang은 멀티턴·에이전트 워크로드에서 더 빠른 대안입니다.vLLM은 PagedAttention으로 GPU 메모리를 가상 메모리처럼 관리합니다. 기존 방식이 KV 캐시에 연속 메모리 블록을 할당해서 60~80%를 낭비했다면, vLLM은 16토큰 단위 페이지로 쪼개서 단편화를.. 더보기 vLLM vs SGLang — 프로덕션 LLM 서빙 프레임워크 어떻게 골라야 하나 모델을 골랐으면 다음 결정이 서빙 엔진입니다. vLLM과 SGLang은 둘 다 OpenAI 호환 엔드포인트를 제공하고, 둘 다 PagedAttention 계열 메모리 관리를 씁니다. 그런데 특정 워크로드에서는 성능 차이가 6배까지 납니다. 어떤 걸 써야 하는지는 모델 크기가 아니라 워크로드 형태가 결정합니다.핵심 차이 — PagedAttention vs RadixAttention두 엔진의 근본적 차이는 KV 캐시를 어떻게 다루느냐입니다.vLLM의 PagedAttention은 KV 캐시 메모리를 고정 크기 블록으로 관리하고 요청이 끝나면 해제합니다. SGLang의 RadixAttention은 KV 캐시를 LRU 래딕스 트리에 유지하고 새 요청이 이전 요청과 프리픽스를 공유하면 재사용합니다. PagedAtt.. 더보기 SGLang Attention Backend 완전 비교 — Triton, FlashInfer, FA3, TRTLLM SGLang으로 서버 띄울 때 이 파라미터를 보게 돼요.python -m sglang.launch_server \ --model-path Qwen/Qwen3.5-9B-Instruct \ --attention-backend ??? # 뭘 써야 하지?옵션이 여러 개예요.tritonflashinferfa3 (flashattention3)trtllm_mhatrtllm_mlafa4 (최신)각각이 뭔지, 언제 써야 하는지 정리할게요.백엔드가 뭔가Attention 계산을 어떤 커널(저수준 GPU 코드)로 처리할지 결정하는 거예요.SGLang 서버 ↓Attention Backend 선택 ↓┌──────────────────────────────────────┐│ Triton │ FlashInfer.. 더보기 vLLM, SGLang이 빠른 이유 — Continuous Batching 원리와 실전 LLM 서빙 서버를 직접 구축하면 처음에 이런 상황이 생겨요.# 단순하게 구현한 LLM 서버@app.post("/generate")async def generate(request): output = model.generate(request.prompt) return output요청 하나하나를 순서대로 처리해요. GPU 사용률 확인해보면 이래요.nvidia-smi:GPU 사용률: 15~30%GPU 자원의 70~85%를 낭비하고 있어요. Continuous Batching이 이걸 해결해요.LLM 추론의 두 단계이해하려면 LLM이 어떻게 토큰을 생성하는지 알아야 해요.Prefill 단계 (입력 처리):"안녕하세요, 오늘 날씨는" → 한번에 병렬 처리→ 계산 집약적 (compute-bound)→ 첫 .. 더보기 KV Cache 완전 정리 — PagedAttention vs RadixAttention, SGLang이 빠른 이유 LLM이 토큰을 생성할 때마다 이전 토큰들의 중간 연산 결과를 저장해 두는 게 KV 캐시예요. 없으면 매 토큰마다 처음부터 다시 계산해야 해요.근데 이 KV 캐시를 어떻게 관리하느냐에 따라 성능이 완전히 달라져요. vLLM과 SGLang은 서로 다른 방식으로 이 문제를 풀어요.KV 캐시가 뭔가트랜스포머의 어텐션 레이어는 매 스텝마다 이전 토큰들의 Key/Value 벡터를 참조해요.1번째 토큰 생성: [토큰1] KV 계산2번째 토큰 생성: [토큰1, 토큰2] — 토큰1 KV 재계산하면 낭비!KV 캐시:1번째 토큰 생성: [토큰1] KV 계산 → 저장2번째 토큰 생성: 저장된 토큰1 KV 재사용 + 토큰2 KV만 계산→ 계산량 대폭 감소문제는 KV 캐시가 메모리를 많이 먹는다는 거예요.Llama-3.1-8B.. 더보기 LLM 양자화 완전 정리 — FP8, AWQ, GPTQ, GGUF 차이와 선택법 70B 파라미터 모델을 FP16으로 그냥 올리면 GPU 메모리가 140GB 필요해요. H100 두 개가 있어야 겨우 올라가요.양자화(Quantization)는 이 문제를 해결해요.FP16 (기본): 70B 모델 = 140GB VRAM → H100 2개 필요INT8: 70B 모델 = 70GB VRAM → H100 1개로 가능INT4 (4비트): 70B 모델 = 35GB VRAM → A100 1개로 가능근데 양자화 방식이 너무 많아요. FP8, AWQ, GPTQ, GGUF, BitsAndBytes, MXFP4... 뭐가 뭔지 헷갈려요.이번 글에서 각 방식이 어떻게 다르고 언제 써야 하는지 완전 정리해 드릴게요.양자화란 무엇인가LLM의 가중치는 수천억 개의 숫자예요. 기본적.. 더보기 SGLang PD 분리 배포 완전 가이드 — Prefill/Decode 분리로 처리량 5배 올리기 LLM 추론에는 두 단계가 있어요.Prefill은 입력 프롬프트 전체를 한 번에 처리하는 단계로, 연산 집약적이고 보통 수백에서 수천 토큰을 한 번에 처리하면서 KV 캐시를 생성해요.Decode는 그렇게 만들어진 KV 캐시를 매 스텝마다 읽으면서 토큰을 하나씩 생성하는 단계인데, 연산보다는 메모리에 부담이 크고 요청당 수십에서 수백 번 반복돼요.전통적인 통합 엔진에서는 이 두 단계가 같은 GPU에서 실행돼요. 그래서 두 가지 심각한 문제가 생겨요. 문제 1: Prefill 방해(Prefill Interruption)기존 통합 엔진에서는 디코딩이 한창 진행 중일 때 새 요청이 들어오면, 디코딩을 멈추고 프리필을 처리한 다음 다시 디코딩을 재개하는 식으로 동작해요. 이게 반복되면 토큰 생성이 계속 끊기면서 .. 더보기 이전 1 2 다음