제10장 — LLM 엔진 계층

LLM Primer VI: AI 시스템 확장하기를 챕터별로 걷는 워크스루의 열 번째 글입니다. 엔진과 플랫폼 사이의 경계에 이름을 붙이고, 2026년 그 계층을 지배하는 다섯 엔진을 걷는 장입니다.

이 장이 존재하는 이유

제1장부터 제9장까지는 한 번의 포워드 패스가 건드리는 기계 — 자기회귀 루프, KV 캐시, GPU 기판, 그것을 줄이는 양자화, 유휴 시간을 감추는 배칭, 순차 의존을 깨는 투기적 디코딩 — 를 걸었습니다. 그 어느 것도 pip install로 넣고 잊어버릴 라이브러리로 나오지 않습니다. 누군가는 그것을 하나의 단일 노드 런타임으로 엮어, 모델을 감싸고, KV 캐시를 소유하고, 요청을 연속 배치로 스케줄하고, 추론 API를 노출합니다. 그 런타임이 엔진입니다. 제10장은 엔진 계층의 일에 이름을 붙이고, 그것을 플랫폼 계층(제11장)과 구분하며, 같은 일에 서로 다른 기제적 절충을 하는 다섯 엔진 — vLLM, TensorRT-LLM, SGLang, TGI, Ollama — 을 걷습니다.

10.1 vLLM은 파이썬 네이티브의 기본값

vLLM은 대부분의 프로덕션 팀이 먼저 손을 뻗어야 할 엔진입니다. 초보자가 어떻게 생각해야 하는지 모를 축들에 대해 올바른 기본 결정을 내리고, 그것을 파이썬으로 합니다. PagedAttention이 단편화를 60~80퍼센트에서 한 자릿수로 무너뜨려 같은 GPU에서 달성 가능한 배치 크기를 대략 두 배로 만듭니다. 연속 배칭이 그 위에 자연스럽게 얹히고, 청크드 프리필이 같은 이터레이션에서 프리필과 디코드 작업을 섞어 두 국면 사이의 경계가 죽은 시간이 되지 않게 합니다. 카피 온 라이트 프리픽스 공유는 블록 테이블 설계에서 공짜로 나옵니다. 인터페이스는 진짜로 몇 줄의 오프라인 배치나 OpenAI 호환 HTTP이고, 모든 새 모델 아키텍처가 거기에 빠르게 안착합니다. 커뮤니티가 넓기 때문입니다. 운영자가 다른 것을 고를 특별한 이유가 없을 때 표준화하기에 좋은 엔진입니다.

10.2 TensorRT-LLM은 빌드 파이프라인으로 처리량을 산다

TensorRT-LLM의 제안은 좁습니다. 함대가 오로지 NVIDIA이고, 달러당 처리량의 매 퍼센트 포인트가 중요하며, 팀이 하드웨어 세대마다 모델별 엔진 파일을 컴파일하는 엔지니어링 세금을 낼 것이라면, TRT-LLM은 같은 하드웨어에서 vLLM 대비 15~35퍼센트 더 많은 처리량을 뽑아냅니다. 기제는 커널 수준입니다 — 트랜스포머 그래프를 NVIDIA 특화 IR로 내리고, 인접 커널을 융합하고(layernorm + matmul + activation을 한 번의 시작에), 사전 튜닝된 라이브러리에서 셰이프별 최적 커널을 고르고, 직렬화된 엔진을 만들고, Triton Inference Server 아래에서 돌립니다. 융합이 중요한 이유는 커널 시작 오버헤드가 각 5~10μs이고 소박한 70B 포워드 패스가 토큰당 수천 개를 디스패치하기 때문입니다. 세금은 빌드 파이프라인 그 자체입니다 — 대부분의 팀이 그 운영 비용을 과소평가하는 모델별, GPU별, 배치 영역별 컴파일 단계. SGLang은 다른 특화입니다 — RadixAttention은 엔진이 본 적 있는 모든 프롬프트 프리픽스에 대한 KV 캐시를 라덱스 트리에 저장해, k토큰 프리픽스를 공유하는 두 요청이 배치 사이와 시간을 넘어 정확히 그 k토큰에 대한 KV를 공유합니다. 긴 공유 시스템 프롬프트와 짧은 변형 서픽스를 가진 에이전트 워크로드에서 SGLang은 vLLM 대비 2~6배 처리량을 냅니다. 그 구조화 출력 DSL은 로짓 수준에서 JSON 스키마를 강제해 출력이 유효함을 보장합니다.

10.3 결정 트리는 헤드라인 처리량이 아니라 워크로드 모양을 통해 흐른다

다섯 엔진은 작은 결정 트리에 부채꼴로 펼쳐집니다. 개발자 노트북이나 혼합 가속기 엣지 → Ollama. 프로덕션 GPU 함대, 오로지 NVIDIA, 높은 QPS, 처리량 ROI가 빌드 파이프라인을 정당화 → TensorRT-LLM. 혼합 하드웨어나 잦은 모델 스왑, 프리픽스 중심의 구조적 패턴(에이전트, 도구 호출, 긴 공유 프롬프트)이 지배하는 워크로드 → SGLang. 혼합 하드웨어, 일반 챗 워크로드, 깊은 Hugging Face 통합 → TGI. 그 밖의 모든 것 → vLLM. 결정은 영구적이지 않습니다. 엔진들은 API 경계에서 상호 교체 가능합니다 — 모두 OpenAI 스타일 HTTP를 씁니다 — 그래서 플랫폼 계층의 라우터가 클라이언트 코드를 바꾸지 않고 모델별, 워크로드별, 리전별로 트래픽을 옮길 수 있습니다. 많은 프로덕션 스택은 둘이나 셋의 엔진을 나란히 돌립니다. 헤드라인 벤치마크를 조심하십시오 — 「Llama-2-7B에서 배치 1일 때 초당 토큰」은 어떤 프로덕션 워크로드도 묻지 않는 질문에 답합니다. 여러분의 모델, 여러분의 프롬프트 분포, 여러분의 동시성 프로파일로 벤치마크하십시오. 반나절이 몇 달을 아낍니다.

제10장이 준비하는 것

이 장에서 설명된 모든 엔진은 같은 경계에서 멈춥니다. 커널, KV 블록, 연속 배칭에 대해서는 알지만 리플리카, 테넌트, 체인, 인증에 대해서는 모릅니다. 제11장은 그 관심사를 다루는 플랫폼 계층 — Ray Serve, KServe, BentoML, Triton Inference Server — 을 걷고, 선택이 기능보다는 운영 모델이 팀의 기존 인프라와 역량과 얼마나 맞는지에 훨씬 더 관한 것임을 보여 줍니다.

다음 → 제11장: 플랫폼과 오케스트레이션 계층. Ray Serve, KServe, BentoML, Triton — 엔진 위에 앉아 운영 문화의 적합성으로 골라지는 네 플랫폼.