가장 빠른 LLM 추론 엔진, 시작에 28분 걸린다

2026년 중반 기준 오픈소스 추론 스택은 네 가지 엔진을 중심으로 정리됐지만, 가장 흔한 질문인 “어느 것이 가장 빠른가?”에는 여전히 깔끔한 답이 없습니다. 단일 H100에서는 상위 세 엔진의 서빙 성능 차이가 약 14% 안에 들어오며, 워크로드를 바꾸는 순간 순위도 뒤집힙니다.

2026년 H100에서 가장 빠른 추론 엔진은?

2026년에 단 하나의 가장 빠른 H100 추론 엔진은 없습니다. TensorRT-LLM, SGLang, vLLM은 대체로 약 14% 이내의 차이로 마무리되며, 선두는 워크로드, 동시성, 모델 아키텍처, 모델별 컴파일 단계를 감수할 수 있는지에 따라 바뀝니다. Llama-3.3-70B-Instruct FP8을 50개 동시 요청으로 돌린 제3자 H100 SXM5 80GB 테스트에서 TensorRT-LLM은 약 2,100 output tokens/s, SGLang은 약 1,920, vLLM은 약 1,850을 기록했습니다 . 차이는 실제로 존재하지만 폭은 좁습니다. 벤더의 헤드라인이 암시하는 것보다 훨씬 작습니다.

지연 시간도 같은 이야기를 합니다. 동시 요청 10개 기준 p50 time-to-first-token은 TensorRT-LLM 105 ms, SGLang 112 ms, vLLM 120 ms로, 전체 차이는 15 ms에 불과했습니다 . 메모리 사용량은 사실상 동률입니다. 동시 요청 100개에서 피크 VRAM은 세 엔진 모두 대략 78–79 GB였습니다 . 실무적으로는 엔진 선택이 하드웨어 예산을 바꾸지 않는다는 뜻입니다. 한 엔진의 VRAM에 모델이 들어간다면, 세 엔진 모두에 들어갑니다.

H100 SXM5 80GB, Llama-3.3-70B-Instruct FP8 (source: Spheron benchmark, 2026).

그런데도 “가장 빠른 엔진” 논쟁이 계속되는 이유는 무엇일까요? 이 수치들은 하나의 GPU에서 하나의 워크로드를 측정한 결과이기 때문입니다. RAG나 멀티턴 에이전트처럼 공유 프리픽스 트래픽으로 바꾸면 SGLang의 KV-cache 재사용이 앞서고, 최대 처리량을 노리는 배치 작업으로 바꾸면 TensorRT-LLM의 컴파일된 커널이 앞섭니다. 단, 몇 분짜리 빌드 단계를 감당할 수 있어야 합니다. 2026년에 더 정직한 판단 기준은 단일 벤치마크가 아니라 운영 방식입니다. 순수 H100 처리량만 보면 충분히 비슷하므로, 실제 결정 요인은 서빙 패턴에 맞는 트레이드오프입니다.

이 가이드의 나머지 부분에서는 그 판단 요소를 엔진별로 살펴봅니다. vLLM의 V1 재작성으로 실제로 무엇이 바뀌었는지, SGLang이 측정 가능한 차이로 앞서는 지점은 어디인지, TensorRT-LLM의 약 28분 컴파일이 무엇을 주는지, 로컬 하드웨어에서는 어떻게 동작하는지, 그리고 점점 엔진 이름보다 중요해지고 있는 처리량 레버(FP4, KV 재사용, prefill-decode 분리)를 다룹니다. 기반이 되는 H100 비교는 계속 돌아와 기준점으로 삼을 자료입니다.

vLLM V1이 실제로 바꾸는 것

vLLM V1은 엔진의 CPU 측 스케줄링을 전면 재작성한 버전입니다. 이제 기본값이 되었고 현재는 유일한 선택지입니다. 따라서 2026년에 vLLM을 실행한다면, 명시적으로 선택했든 아니든 V1을 실행하는 것입니다. 알파는 2025년 1월 27일 발표됐고, V1은 2025년 중반 기본값이 되었으며, 이후 레거시 V0 코드 경로는 완전히 제거됐습니다 . 마이그레이션은 선택이 아니라 필수입니다. 최신 릴리스로 올리기 전에 버전을 고정하고 테스트하는 절차를 잡아야 합니다.

가장 큰 변화는 처리량입니다. vLLM에 따르면 V1은 멀티스텝 스케줄링 없이도 같은 하드웨어에서 V0 대비 최대 1.7배 높은 처리량을 제공합니다 . 숫자보다 중요한 것은 메커니즘입니다. 속도 향상은 새 GPU 커널이 아니라 스케줄러와 오케스트레이션 루프에서 Python/CPU 오버헤드를 줄인 데서 나옵니다. 여기에는 실무적으로 두 가지 의미가 있습니다. 첫째, API 변경이 필요 없습니다. 기존 서빙 코드와 요청 스키마는 그대로 동작합니다. 둘째, 효과는 워크로드가 얼마나 CPU 병목이었는지에 따라 달라지므로, 개선 폭이 균일하지 않습니다.

모델 크기에 따른 차이는 실제로 큽니다. 속도 향상은 워크로드가 얼마나 CPU 병목이었는지에 비례합니다. 작은 모델(8B 이하)은 각 스텝의 CPU 스케줄링 오버헤드가 전체 실행 시간에서 차지하는 비율이 더 높기 때문에, 그 오버헤드를 제거했을 때 이득이 더 큽니다. 반대로 큰 모델(70B 이상)에서는 GPU가 이미 지배적인 비용이므로 CPU 절감 효과는 상대적으로 작습니다. 헤드라인 수치에서 외삽하지 말고, 실제 모델과 트래픽 조합으로 벤치마크를 돌려야 합니다 .

순수 처리량을 넘어, vLLM이 범용 서빙의 기본 추천으로 남는 이유는 V1의 운영상 장점입니다. 콜드 스타트는 약 62초로, 서버급 엔진 중에서는 SGLang의 약 58초 다음으로 빠르며, TensorRT-LLM의 모델별 컴파일 단계인 약 28분보다 압도적으로 짧습니다 . 세 엔진 중 가장 넓은 모델 지원 범위와 가장 완성도 높은 문서까지 더해지면, vLLM은 마찰이 적은 기준선이 됩니다. 컴파일 대기 시간이 없고, 지원 아키텍처가 좁지 않으며, “git clone”에서 실제 엔드포인트까지 가는 간격이 가장 짧습니다.

트레이드오프는 vLLM이 특화 워크로드에서 뒤처진다는 점입니다. 높은 동시성의 순수 처리량에서는 동시 요청 50개 기준 SGLang이 약 1,920 tok/s, vLLM이 약 1,850으로 약 4% 차이가 납니다. 그리고 공유 프리픽스 트래픽과 낮은 단일 요청 TTFT에서는 SGLang의 우위가 더 벌어집니다 . 다음 섹션에서 그 사례를 살펴봅니다.

공유 프리픽스 작업에서 SGLang이 vLLM을 앞서는 경우

요청들이 공통 프리픽스, 즉 시스템 프롬프트, 퓨샷 예시, 검색된 컨텍스트를 공유할 때 SGLang이 유리합니다. 서드파티 H100 SXM5 벤치마크(Spheron, 2026년 1월, Llama-3.3-70B-Instruct FP8)에서 SGLang은 동시 요청 50개 기준 약 1,920 output tok/s를 기록했고, vLLM은 약 1,850으로 일반적인 혼합 트래픽에서 약 4% 차이가 났습니다 . 프리픽스 비중이 큰 워크로드에서는 RadixAttention 덕분에 이 차이가 더 벌어집니다. SGLang의 초기 벤치마크에서는 캐시 적중률이 높을 때 처리량이 최대 5배까지 높게 측정됐습니다 (2024년 1월, A10G GPU, vLLM v0.2.5 — 방향성을 보여주는 신호이며, 현재 H100 기준 격차는 다름). 핵심 메커니즘은 RadixAttention입니다.

RadixAttention은 프롬프트 프리픽스 해시를 키로 삼아 KV 캐시 항목을 radix tree에 저장합니다. 같은 2,000토큰짜리 시스템 프롬프트로 시작하는 두 요청은 해당 캐시된 프리픽스를 자동으로 재사용합니다. 애플리케이션 코드 변경도, 수동 캐시 키도 필요 없습니다. 이는 큰 고정 컨텍스트 뒤에 작은 가변 꼬리가 붙는 RAG 파이프라인, 멀티턴 채팅, 에이전트 루프, 구조화 JSON 생성의 구조와 정확히 맞아떨어집니다. 가변 꼬리가 공유 프리픽스에 비해 짧을수록 캐시 적중률이 올라가고 SGLang의 이점은 커집니다.

운영 특성도 이를 뒷받침합니다. SGLang은 약 58초에 콜드 스타트해 vLLM의 62초보다 근소하게 빠르고, 단일 요청 TTFT는 80~120ms 범위로 주요 세 엔진 중 가장 낮습니다. 즉 TensorRT-LLM의 컴파일 비용을 치르지 않고도 time-to-first-token에서 앞서며, 이 트레이드오프는 다음 섹션에서 다룹니다. 같은 서드파티 H100 비교에서 동시 요청 50개 기준 SGLang은 약 1,920 output tokens/s를 기록해 TensorRT-LLM의 약 2,100에는 뒤졌지만 vLLM의 약 1,850은 앞섰습니다. 프리픽스 비중이 큰 트래픽에서는 원시 커널 성능보다 프리픽스 재사용이 승부를 가를 만큼 근접한 차이입니다.

더 최근의 주장은 더 신중하게 봐야 합니다. 2026년 1월 출시된 v0.5.8은 TensorRT-LLM의 DeepSeek Sparse Attention(DSA) 커널을 통합했고, Blackwell에서 3~5배 속도 향상을 보고했습니다. 그보다 앞선 2026년 2월 수치로는 GB300 NVL72에서 H200 대비 DeepSeek-R1 성능이 최대 25배 높다는 주장도 함께 제시됐습니다. 이는 프로젝트가 직접 보고한, 특정 하드웨어에 묶인 수치입니다. MLPerf 규모에서 검증된 것은 아니므로 정면 비교 결과라기보다 방향성으로 보는 편이 맞습니다. 한 실무자의 정리는 이렇습니다.

"순위는 워크로드에 따라 뒤집힙니다. 단일 처리량 승자는 없습니다. SGLang은 공유 프리픽스 트래픽에서, vLLM은 커버리지에서, TensorRT-LLM은 절대 피크 성능에서 앞섭니다." — 벤치마크 분석 (source: Spheron, 2026).

판단 기준은 명확합니다. 트래픽에 큰 공유 프리픽스가 있고 SGLang의 더 좁은 모델 커버리지를 감수할 수 있다면, 캐시 재사용이 충분히 값을 합니다. 프리픽스가 짧고 대부분 고유하다면 vLLM의 폭넓은 지원 특성이 더 유리합니다.

TensorRT-LLM: 처리량 우위와 28분 컴파일 비용

TensorRT-LLM은 주요 H100 엔진 중 가장 높은 절대 처리량을 내지만, 그 우위를 얻기 위해 모델별 컴파일 단계를 먼저 치러야 합니다. 같은 서드파티 H100 SXM5 비교(Llama-3.3-70B-Instruct FP8)에서 TensorRT-LLM은 동시 요청 50개 기준 약 2,100 output tokens/s를 기록해 SGLang의 약 1,920과 vLLM의 약 1,850을 앞섰고, 동시 요청 10개 기준 p50 time-to-first-token도 105ms로 가장 낮았습니다(112ms, 120ms 대비) . 문제는 콜드 스타트입니다. vLLM이 약 62초, SGLang이 약 58초에 부팅되는 반면, TensorRT-LLM은 단일 요청에 응답하기 전 각 모델의 serving engine을 컴파일하는 데 약 28분을 씁니다 .

이 컴파일은 우연한 부작용이 아니라 속도의 원천입니다. TensorRT-LLM은 고정된 모델, 정밀도, 배치 프로파일을 미리 최적화된 엔진으로 구워 넣습니다. 그래서 통제된 테스트에서는 vLLM이나 TGI 대비 2~4배 향상을 언급하기도 합니다. 동시에 가중치 변경, 양자화 교체, LoRA 변형이 생길 때마다 다시 컴파일해야 하는 이유이기도 합니다 . 안정적인 프로덕션 모델이라면 배포 시점에 28분을 한 번 지불하고 몇 주간의 트래픽에 나눠 부담하면 됩니다. 모델 카탈로그를 계속 교체하는 팀이라면 이 컴파일 비용이 매번 다시 발생합니다.

표준화된 수치는 벤더 최적화 TensorRT 스택이 얼마나 멀리 확장되는지 보여줍니다. MLPerf Inference Datacenter v5.1에서 NVIDIA GB300 NVL72(TensorRT 10.13 + CUDA 13.0)는 DeepSeek-R1 기준 Offline 420,659 tokens/s, Server 209,328 tokens/s를 보고했고, GB200 NVL72(TensorRT 10.11 + CUDA 12.9)는 Llama 3.1 405B 기준 Offline 14,774.3, Server 11,614.3을 보고했습니다 . 이는 순수 엔진 비교가 아니라 전체 랙 규모의 벤더 제출 결과이므로, 엔진 간 정면 순위가 아니라 상한선으로 읽어야 합니다.

더 현실적인 규모에서 용량을 계획할 때는 8-GPU 제출 결과가 유용한 기준점입니다. Oracle의 8x B200 TensorRT 제출은 Llama 3.1 405B에서 Offline 1,615.85 tokens/s, Server 1,243.67 tokens/s를 기록했고, 훨씬 작은 Llama 3.1 8B에서는 Offline 145,789 / Server 128,649를 보고했습니다 . 405B 수치는 구체적인 엔터프라이즈 기준선을 제공합니다. 단일 8x B200 박스가 프런티어급 모델을 서빙할 때, 추가 노드로 샤딩하기 전 MLPerf의 지연 시간 제약 Server 시나리오에서 초당 수천 토큰 초반대에 놓인다는 뜻입니다.

판단 기준은 컴파일 비용에서 바로 나옵니다. TensorRT-LLM은 고정 모델 프로덕션 배포에 가장 잘 맞습니다. 단일 모델을 몇 주 동안 안정적으로 유지하고, 피크 처리량과 낮은 TTFT가 곧바로 서빙 비용을 줄이며, 일회성 엔진 빌드 시간이 전체 배포 기간에 비하면 거의 문제가 되지 않는 경우입니다. 반대로 모델을 반복 실험하거나 체크포인트 A/B 테스트를 하거나 동적인 카탈로그를 서빙하는 팀에는 잘 맞지 않습니다. 반복되는 약 28분 컴파일과 경직된 엔진 프로파일이 운영 부담이 되기 때문입니다. 모델 집합이 작고 고정돼 있다면 TensorRT-LLM의 절대 성능 우위를 그대로 가져갈 수 있습니다. 모델이 자주 바뀐다면 부팅 시간이 짧은 엔진들이 더 실용적입니다.

로컬 추론: llama.cpp, Ollama, Apple Silicon, RTX 5090

단일 워크스테이션에서는 엔진 자체보다 그 주변 설정이 더 중요합니다. 메모리 상주 여부와 동시성 플래그가 처리량을 좌우합니다. Qwen 34B를 실행할 때 llama.cpp 위에서 동작하는 Ollama는 약 100 tokens/s에 도달하고, llama.cpp의 자체 llama-server는 단일 요청에서 약 124 tokens/s를 기록합니다. 여기에 --parallel과 동시성 128을 설정하면 약 231 tokens/s까지 올라가며, 여러 병렬 인스턴스를 실행하면 약 826 tokens/s 근처까지 도달합니다 (video: Alex Ziskind). 핵심은 같은 가중치라도 배치 방식에 따라 처리량이 8배까지 벌어진다는 점입니다.

VRAM 상주는 넘으면 바로 떨어지는 절벽입니다. 32GB RTX 5090은 가중치가 GPU 안에 완전히 머무는 동안 35B 양자화 MoE를 100~140 tokens/s로 실행할 수 있지만, 시스템 RAM으로 조금이라도 밀려나는 순간 처리량이 무너집니다 (video: Zen van Riel). 여기에는 완만한 성능 저하가 없습니다. 메모리 예산 안에 있거나 절벽 밖에 있는 둘 중 하나이므로, 더 빠른 커널을 좇는 것보다 여유 공간을 남기는 양자화를 고르는 일이 더 중요합니다.

Apple의 통합 메모리는 계산 방식을 바꿉니다. 전체 메모리 풀이 GPU에서 주소 지정 가능하기 때문입니다. M4 Pro는 48GB 전체를 모델에 노출하고, 512GB Mac Studio는 Llama 70B 서버 네 개를 동시에 호스팅할 수 있습니다 (video: Alex Ziskind). 엔진 측면에서는 vllm-mlx가 M4 Max에서 최대 525 tokens/s를 보고했습니다. 이는 llama.cpp보다 21~87% 높고, 동시 요청 16개에서는 총합 기준 4.3배 우위이며, 콘텐츠 기반 프리픽스 캐싱을 통한 반복 이미지 처리에서는 최대 28배 빠릅니다 . 여러 에이전트를 서빙하는 Mac 개발자에게 결정 요인은 단일 스트림 속도가 아니라 이 동시성 배수입니다.

Claude Code에 로컬 서버를 연결하는 사람이라면 한 가지 설정 함정을 표시해 둘 만합니다. LM Studio는 이제 Anthropic 호환 /v1/messages 엔드포인트를 제공하지만, 기본 4,000토큰 컨텍스트는 Claude Code의 약 80,000토큰 시스템 프롬프트에서 조용히 멈춥니다. 요청이 오류를 내지 않고 그대로 정지합니다 (video: Zen van Riel). 로컬 서버로 ANTHROPIC_BASE_URL을 지정하기 전에 context_length를 명시적으로 설정하세요. 권장 하한은 약 80,000입니다.

소비자용 환경에서의 실전 결론은 이렇습니다. API 표면과 동시성 지원을 기준으로 엔진을 고른 다음, 튜닝 노력은 양자화, 메모리 상주, --parallel 스윕에 쓰세요. 머신마다 308개의 인스턴스 및 동시성 조합을 훑는 "Llama Throughput Lab" 같은 도구가 존재하는 이유도 여기에 있습니다. 최적 설정은 하드웨어별로 달라지며, 사양표만 보고 맞힐 수 없습니다.

2026년 처리량을 끌어올리는 핵심: FP4, KV 재사용, 프리필-디코드 분리

2026년의 가장 큰 처리량 향상은 더 이상 엔진 교체에서 나오지 않습니다. 주요 스택이라면 대부분 활용할 수 있는 네 가지 지렛대, 즉 FP4/NVFP4 양자화, FP8 KV 캐시, 프리필-디코드(PD) 분리, 프리픽스/KV 재사용에서 나옵니다. FP4는 Blackwell 하드웨어에서 가장 큰 단일 배수 효과를 냅니다. vLLM의 GB300 보고서(vLLM 0.14.1 + CUDA 13.0)에 따르면, NVFP4와 TP2로 실행한 DeepSeek-V3.2는 프리필 전용 테스트에서 7,360 tokens/GPU/s를 기록했고, 두 대의 GB300에서 NVFP4+EP2로 실행한 DeepSeek-R1은 프리필 22,476 tokens/s, ISL=2k/OSL=1k 혼합 시나리오 3,072 tokens/s에 도달했습니다 . 같은 글은 이 구성에서 Blackwell Ultra/B300이 H200 대비 프리필 약 8배, 혼합 컨텍스트 10~20배 향상을 보였다고 보고합니다.

여기서 얻을 교훈은 정밀도 형식과 병렬화 배치가 이제 엔진 이름보다 수치를 더 크게 움직인다는 점입니다. 그래서 가장 먼저 튜닝할 것은 양자화와 메모리 상주이며, 마지막에 손댈 항목이 아닙니다.

PD 분리는 올해 연구 단계에서 프로덕션 단계로 넘어왔습니다. 하나의 GPU 풀이 계산 집약적인 프리필과 지연 시간에 민감한 디코드 단계를 모두 처리하는 대신, 분리는 두 단계를 나누어 각각 독립적으로 확장하게 합니다. vLLM의 2026년 4월 AMD MORI-IO 글은 8-GPU MI300X 한 대에서 단일 노드 PD 분리를 보여줍니다. Qwen3-235B-A22B-FP8을 2,000토큰 프롬프트와 1,000토큰 출력, 8 req/s로 실행했을 때, 같은 위치에서 함께 서빙하는 방식보다 SLO를 만족하는 goodput이 2.5배 높았습니다 . 실제 트래픽을 라우팅하기 시작하면 중요한 지표는 원시 토큰 수가 아니라 지연 시간 SLO 안에서 처리된 요청 수, 즉 goodput입니다.

벤더의 헤드라인을 믿기 전에 계속 염두에 둘 연구 결과가 두 가지 있습니다. SPEED-Bench는 합성 입력이 실제 환경의 speculative decoding 처리량을 과대평가한다고 경고합니다. 따라서 벤치마크에서 보이는 accept rate는 프로덕션 프롬프트 분포에서는 그대로 유지되기 어렵습니다. 별도로 Blink 논문은 vLLM, SGLang, TensorRT-LLM 모두에서 호스트 CPU가 여전히 병목이라고 주장합니다. 요청 오케스트레이션을 CPU에서 GPU/SmartNIC으로 옮기면 P99 TTFT가 최대 8.47배 낮아지고, P99 TPOT가 3.40배 낮아지며, 토큰당 에너지가 48.6% 줄어든다고 주장합니다(논문 수치이며, 감사된 제출 자료는 아닙니다). 둘 다 오케스트레이션 오버헤드와 입력 현실성이 논문에 적힌 배수 효과를 지워버릴 수 있다는 reminder로 읽어야 합니다.

모델 아키텍처가 엔진 동작을 아예 뒤집을 수도 있습니다. vLLM의 GB300 데이터에서는 2k 토큰 프리필에서 DeepSeek-R1이 DeepSeek-V3.2를 앞섰습니다. V3.2의 sparse-attention indexer 경로 때문에 단일 DSA 레이어 단계가 MLA보다 커널 시간이 2.7배 길어졌기 때문입니다 . 희소성이 보상을 주는 훨씬 긴 컨텍스트에서는 V3.2가 여전히 이길 수 있지만, 짧은 프리필에서는 서빙 스택이 아니라 아키텍처가 순위를 결정합니다.

"이 설정에서 Blackwell Ultra/B300은 H200 대비 프리필 최대 8배, 혼합 컨텍스트 처리량 10~20배를 보였지만, V3.2와 R1의 비교는 컨텍스트 길이에 따라 뒤집힙니다. 모델의 attention 경로가 결과를 지배합니다," — vLLM 엔지니어링 팀, GB300 DeepSeek 보고서 (source: vLLM, 2026-02).

실전 순서는 이렇습니다. 모델과 정밀도를 지원하는 엔진을 고르고, 하드웨어가 허용하는 곳에서는 NVFP4 또는 FP8을 켜고, 반복 컨텍스트에는 KV/프리픽스 재사용을 활성화한 뒤, 하나의 공동 배치 풀이 더 이상 TTFT SLO를 지키지 못할 때 PD 분리를 검토하세요. 그런 다음 자신의 트래픽으로 검증해야 합니다. 합성 벤치마크의 승리는 깔끔하게 이전되지 않습니다.

워크로드별 엔진 선택 기준

대표 처리량 숫자만 보고 고르지 말고, 주된 워크로드를 기준으로 선택하세요. 요청들이 같은 prefix 를 공유하는 경우(RAG, 멀티턴 채팅, 구조화된 JSON, 에이전트 루프)에는 SGLang 이 유리합니다. RadixAttention 의 KV-cache 재사용 덕분에 prefix 비중이 큰 트래픽에서 처리량이 눈에 띄게 높아지며, 일반적인 H100 혼합 트래픽 테스트에서는 약 4% 앞서고 prefix 중심 요청 패턴에서는 격차가 더 커집니다 . 대부분의 팀에는 vLLM V1 이 안전한 기본 선택입니다. 고정 모델 프로덕션에서는 TensorRT-LLM 이 가장 높은 절대 성능을 냅니다. 로컬 개발은 llama.cpp, Ollama, 또는 vllm-mlx 가 맞습니다.

Quick Answer: 워크로드에 맞춰 엔진을 고르세요. 공유 prefix 트래픽에는 SGLang(RadixAttention KV-cache 재사용, 일반 H100 트래픽에서 약 4% 우위, prefix 중심 워크로드에서는 더 큰 격차), 폭넓은 지원이 필요하면 vLLM V1(TensorRT-LLM 최고점 대비 약 14% 이내), 정적 고정 모델 서빙에는 약 28분 컴파일을 감수하고 TensorRT-LLM, 로컬 하드웨어에는 llama.cpp/Ollama 또는 vllm-mlx 가 맞습니다.

이 구분을 가르는 핵심 운영 요소는 콜드 스타트입니다. vLLM 은 약 62초, SGLang 은 약 58초에 워밍업되지만, TensorRT-LLM 은 모델마다 약 28분의 컴파일 단계를 거칩니다 (source). 고정된 카탈로그라면 감당할 수 있지만, 자주 바뀌는 카탈로그에서는 치명적입니다. vLLM 은 50개 동시 요청에서 선두권과 큰 차이 없이 유지됩니다(출력 기준 약 1,850 tok/s, TensorRT-LLM 은 약 2,100 tok/s) (source). 그러면서도 가장 넓은 모델 지원 범위와 무컴파일 운영을 제공합니다.

로컬 하드웨어에서는 엔진 선택보다 설정이 더 중요합니다. Qwen 34B 에서 llama.cpp 의 llama-server 는 단일 요청 기준 약 124 tok/s, --parallel concurrency=128 에서는 약 231 tok/s 를 기록했고, Ollama 는 약 100 tok/s 였습니다 (source). Apple Silicon 에서는 vllm-mlx 가 M4 Max 에서 최대 525 tok/s 를 보고했습니다. 이는 llama.cpp 대비 21%–87% 높고, 동시 요청 16개 기준 전체 처리량은 4.3배입니다 (source). Mac 에서 동시 요청 확장이 필요하다면 이쪽을 선택하세요(video: Zen van Riel).

핵심 정리(결): 2026년에 모든 상황에서 가장 빠른 단일 엔진은 없습니다. 기본값은 vLLM V1 으로 두고, 트래픽이 prefix 를 공유하기 시작하는 순간 SGLang 으로 전환하세요. TensorRT-LLM 의 컴파일 비용은 모델 구성이 정말로 고정되어 있을 때만 받아들이면 됩니다. 마지막으로 반드시 자신의 요청 조합으로 벤치마크하세요. 여기의 여러 출처 수치는 방향성을 보여주는 것이지, 엄밀한 일대일 비교가 아닙니다.

영상 / 출처

• Alex Ziskind — 로컬 LLM 이 제 성능보다 10배 느린 이유
• Zen van Riel — 따라올 수 없는 로컬 AI 코딩 워크플로우(2026 전체 세팅)
• Zen van Riel — 2026년 로컬 AI 코딩 최종 가이드

자주 묻는 질문

2026년에도 대부분의 팀에 vLLM이 기본 추론 엔진으로 적합한가요?

네, 대부분의 팀에는 그렇습니다. vLLM은 가장 폭넓은 모델 커버리지, 컴파일 단계가 없다는 점, 약 62초의 콜드 스타트 를 갖추고 있으며, V1 엔진에서는 V0의 한계였던 CPU 오버헤드를 제거해 최대 1.7배 높은 처리량을 보고했습니다 . 다만 H100 피크 처리량에서는 TensorRT-LLM보다 약 14% 뒤처지고(동시 요청 50개 기준 출력 약 2,100 tok/s 대 1,850 tok/s), 공유 프리픽스 TTFT에서는 SGLang보다 뒤처집니다 . 전환은 헤드라인 수치가 아니라, 실제 워크로드 벤치마크에서 의미 있는 차이가 확인될 때만 하세요.

SGLang의 RadixAttention은 어떻게 작동하며, 어떤 워크로드에 유리한가요?

RadixAttention은 프롬프트 프리픽스 해시를 키로 삼아 KV-cache 항목을 저장합니다. 그래서 시스템 프롬프트, 퓨샷 예시, 검색 컨텍스트처럼 프리픽스를 공유하는 요청은 코드 변경 없이 자동으로 캐시를 재사용합니다. SGLang의 2024년 벤치마크에서는 캐시 적중률이 높을 때 처리량이 최대 5배 높아진 것으로 측정됐고 (2024년 1월, A10G GPU, vLLM v0.2.5 — 방향성을 보여주는 신호이며, 현재 H100 기준 격차는 다를 수 있음), 2026년 1월 H100 기반 서드파티 벤치마크에서는 일반 혼합 트래픽에서 SGLang이 약 4% 앞서는 것으로 나타났습니다 . RAG, 멀티턴 채팅, 에이전트 루프, 안정적인 템플릿을 쓰는 구조화 JSON 생성에서 가장 큰 이점을 얻습니다. 완전히 고유한 프롬프트는 재사용할 프리픽스가 없기 때문에 이점이 없습니다.

MLPerf Inference 결과는 실제 서빙 성능을 반영하나요?

방향성은 맞지만, 정확한 수치까지 그대로 보기는 어렵습니다. MLPerf의 Offline 시나리오는 이상적인 조건에서 최대 배치 처리량을 측정하고, Server는 지연 시간 제약 아래 포아송 도착 요청 처리량을 측정합니다 . 둘 다 순수한 엔진 비교라기보다 벤더가 최적화한 전체 스택을 사용합니다. 예를 들어 AMD의 87개 MI355X 클러스터는 llama2-70b-99 Offline에서 1,042,110 tokens/s에 도달했습니다 . 실제 배포에는 라우팅, 오토스케일링, 혼합 트래픽이 추가되므로 유효 처리량은 20~40% 낮게 보는 편이 현실적입니다. 또한 MLCommons는 제출 후 변경 로그를 통한 수정도 허용하므로, 공개 수치는 수정될 수 있는 값으로 다뤄야 합니다.

프리필-디코드 분리는 무엇이고, 언제 켜야 하나요?

프리필-디코드(PD) 분리는 프롬프트 처리(프리필, 연산 병목)와 토큰 생성(디코드, 메모리 대역폭 병목)을 한 노드 안의 서로 다른 GPU 할당이나 여러 노드로 나누는 방식입니다. 코로케이션 서빙은 두 단계를 같은 GPU에서 실행해 각 단계의 장점을 충분히 살리지 못합니다. 긴 컨텍스트 프롬프트(2k+ 토큰)를 의미 있는 요청률로 서빙할 때 켜는 것이 좋습니다. vLLM의 2026년 4월 7일 MI300X 실험에서는 Qwen3-235B-A22B-FP8(8 req/s, 2,000토큰 프롬프트, 1,000토큰 출력)을 사용했을 때, 단일 8-GPU 장비의 코로케이션 서빙보다 SLO를 만족하는 goodput이 2.5배 높았다고 보고했습니다 .

Claude Code나 Kilo Code를 로컬 llama.cpp 또는 Ollama 서버에 연결할 수 있나요?

네, ANTHROPIC_BASE_URL 및 ANTHROPIC_API_KEY 환경 변수를 통해 가능합니다. LM Studio는 Anthropic 호환 /v1/messages 엔드포인트를 제공하고, Ollama는 OpenAI 호환 /v1을 제공하므로 Claude Code, Kilo Code, Continue가 로컬 서버를 대상으로 동작할 수 있습니다(video: Zen van Riel). 중요한 함정은 이것입니다. LM Studio의 기본 컨텍스트 윈도우는 4,000토큰이라 Claude Code의 큰 시스템 프롬프트가 조용히 멈춥니다. 테스트하기 전에 모델 설정에서 context_length를 약 80,000으로 설정하세요 .