블로그로 돌아가기
#연속 배칭
2개의 포스트
기술모델 서빙LLM 서빙
2026.10.03모델 서빙 설계 가이드 2026 — 요청 하나의 여정으로 배우는 구조와 노하우
2026년 10월의 모델 서빙에서 엔진은 사실상 정해졌습니다(vLLM, SGLang). 설계의 승부는 엔진 바깥에서 납니다. 이 글은 요청 하나가 들어와 답이 나가기까지의 여정을 식당 운영에 빗대어 따라가며, 지금 통하는 설계와 그 근거를 정리합니다. 응답 시간을 대기·읽기·쓰기로 나눠 재는 법, 최대 처리량이 아니라 굿풋으로 용량을 세는 법, 엔진의 기본값(동시 처리 1,024개, 대기열 무제한)을 그대로 쓰면 안 되는 이유, 같은 대화를 같은 서버로 보내는 것만으로 처리량이 두 배가 되는 라우팅, 받을 수 없는 요청을 거절하는 입장 제어, GPU 사용률이 아닌 확장 신호, 수십 GB 모델의 콜드 스타트를 줄이는 방법, 세대별 양자화 선택, 그리고 규모별 구성까지. vLLM 0.30과 llm-d 0.10의 문서, 그리고 Together·Modal·Baseten·토스·네이버 등이 올해 공개한 운영 사례의 수치를 근거로 삼았습니다. 직접 움직여 보는 위젯 6개가 들어 있습니다.
코어닷투데이57분
기술vLLMNVIDIA Triton
2026.07.29넷플릭스는 왜 LLM을 직접 서빙하는가 (2부): vLLM과 Triton, 서빙 엔진을 해부하다
1부에서 '왜'를 봤다면 2부는 '어떻게'다. 넷플릭스 서빙 스택의 심장인 vLLM과 Triton을 뜯어본다. KV 캐시가 왜 메모리를 잡아먹는지, PagedAttention이 어떻게 그걸 운영체제의 페이징으로 해결했는지, 연속 배칭이 왜 처리량을 몇 배로 끌어올리는지 — 생소한 용어를 하나씩 그림으로 풀고, 넷플릭스가 TensorRT-LLM에서 vLLM으로 갈아탄 진짜 이유까지 따라간다.
코어닷투데이33분