추론 엔진을 먼저 고르는 것이 아닙니다. 하드웨어 전략, 워크로드 형태, 서빙 모델을 먼저 선택해야 합니다. 엔진은 그 다음입니다.
LLM 추론 엔진에 대해 생각하는 가장 유용한 방식입니다.
시리즈 참고: 이 글은 셀프 호스팅 LLM / 로컬 AI 시리즈의 3부입니다.
위 두 글에서는 하드웨어 용량과 대역폭 계산을 설명했습니다.
이 글에서는 그 하드웨어를 사용 가능한 추론으로 바꿔주는 소프트웨어 계층을 설명합니다.
엔진
이 도구들은 서로 다른 목적을 제공하며 서로 다른 계층에 위치합니다.
- 로컬 이식성
- 컨슈머 CUDA
- Apple 통합 메모리 워크플로우
- 양자화된 추론
- 프로덕션 서빙
- 분산 오케스트레이션
- 벤더 최적화 데이터센터 실행
유용한 개념 모델:
추론 엔진은 "모델"이 아닙니다. 추론 엔진은 트래픽 컨트롤러, 메모리 관리자, 커널 디스패처, 스케줄러, 캐시 회계사, 병렬성 설계자, API 표면, 그리고 때로는 배포 프레임워크입니다.
최고의 엔진은 사용자의 메모리 계층 구조, 인터커넥트, 양자화 형식, 지연 시간 및 처리량 목표, 모델 아키텍처, 운영 성숙도에 가장 잘 맞는 엔진입니다.
한 페이지 의사 결정 가이드
- 랩탑 / 엣지 / 특수 하드웨어 → llama.cpp
- Mac 우선 워크플로우 → MLX / MLX-LM
- 단일 RTX 로컬 추론 → ExLlamaV2
- 2-4+ NVIDIA / CUDA GPU → ExLlamaV3
- 일반 프로덕션 서빙 → vLLM
- 긴 컨텍스트 / MoE / 라우팅 → SGLang
- NVIDIA 최대 성능 → TensorRT-LLM
- 클러스터 오케스트레이션 → NVIDIA Dynamo
나머지 가이드에서는 그 이유를 설명합니다.
추론 엔진의 실제 역할
추론 엔진은 가중치를 로드하고, 입력을 토큰화하고, 순방향 패스를 실행하고, 토큰을 샘플링하고, KV 캐시를 유지 관리하고, 결과를 스트리밍합니다. 진지한 엔진은 배치 처리, 스케줄링, 프리픽스 캐싱, 양자화, 병렬 실행, API 서빙, 메트릭, 분산 실행도 처리합니다.
워크로드에는 두 가지 단계가 있습니다.
프리필(Prefill)은 프롬프트를 읽고 초기 KV 캐시를 구축합니다. 계산 집약적입니다.
디코드(Decode)는 한 번에 하나의 토큰을 생성하며, 가중치와 KV 캐시를 반복적으로 읽습니다. 메모리 대역폭에 의해 제한됩니다. 디코드 속도는 최대 계산 능력보다 메모리 대역폭에 더 밀접하게 추적됩니다.
이 구분은 거의 모든 것을 설명합니다.
- 짧은 프롬프트, 긴 답변: 디코드가 지배적 → 메모리 대역폭과 배치 처리가 중요
- 긴 프롬프트, 짧은 답변: 프리필이 지배적 → 어텐션 커널과 청크 프리필이 중요
- 많은 사용자: 스케줄러 품질이 중요 → 연속 배치 처리, 캐시 페이징, 공정성
- 긴 컨텍스트: KV 캐시가 지배적 → 페이지드 어텐션, KV 양자화, 오프로드
- MoE: 전문가 라우팅이 지배적 → 전문가 병렬화, 인터커넥트, 그룹 GEMM
- 멀티 노드: 인터커넥트가 지배적 → NVLink, RDMA, 파이프라인 병렬화, 분리
PagedAttention은 KV 캐시 단편화를 해결했습니다. FlashAttention은 IO 인식 타일링을 사용하여 HBM(고대역폭 메모리) 트래픽을 줄였습니다. 추측성 디코딩은 저렴한 토큰을 초안으로 작성하고 병렬로 검증합니다. 반복되는 주제는 추론 성능은 메모리 이동과 스케줄링의 결합이라는 것입니다.
실제 병목 현상
- 메모리 대역폭, VRAM 크기만이 아닙니다. VRAM은 적합성을 결정합니다. 대역폭은 디코드 속도를 결정합니다. Apple의 M3 Ultra는 최대 819 GB/s의 통합 메모리 대역폭을 제공합니다. NVIDIA의 H100 SXM은 3.35 TB/s의 GPU 메모리 대역폭을 제공합니다. 통합 메모리를 사용하면 컨슈머 VRAM에 맞지 않는 모델을 탑재할 수 있습니다. HBM을 사용하면 모델이 맞을 때 더 빠르게 서빙할 수 있습니다. 적합성은 속도가 아닙니다. 용량은 대역폭이 아닙니다.
- KV 캐시 증가. KV 캐시는 배치 크기와 컨텍스트 길이에 따라 증가합니다. 긴 컨텍스트 워크로드는 가중치가 맞더라도 메모리가 부족할 수 있습니다. PagedAttention은 KV 캐시를 블록으로 분할하여 사용률을 높이고 더 큰 배치를 지원합니다.
- 인터커넥트. 모델이 GPU 경계(멀티 GPU)를 넘어서는 순간 통신 비용이 발생합니다. 텐서 병렬화는 빈번한 all-reduce 집합 통신이 필요합니다. 파이프라인 병렬화는 단계 경계에서 통신합니다. 전문가 병렬화는 MoE를 위한 all-to-all 트래픽이 필요합니다. vLLM 문서에는 NVLink 없이 파이프라인 병렬화가 텐서 병렬화보다 성능이 나을 수 있다고 명시되어 있습니다.
- 스케줄러 품질. 좋은 스케줄러는 어떤 요청이 배치에 들어갈지, 프리필과 디코드가 가속기를 어떻게 공유할지, 긴 프롬프트가 짧은 디코드를 차단하는지, 기아 상태를 방지하는 방법을 결정합니다. 배치 처리를 지원하는 것과 프로덕션 준비가 된 스케줄러처럼 동작하는 것은 다릅니다.
- 런타임 오버헤드. CUDA 그래프, 커널 퓨전, 샘플링 오버헤드, 토크나이저 오버헤드, HTTP 오버헤드, LoRA 스위칭, 구조화된 디코딩 모두 중요합니다. 대규모 환경에서는 성가신 2% 오버헤드가 결합되어 주의가 필요합니다.
엔진 제품군
네 가지 주요 제품군이 있습니다.
이식 가능한 로컬 런타임: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, Ollama 스타일 도구. "여기서 실행되게 만드는 것"에 중점을 둡니다.
Apple / 통합 메모리 런타임: MLX 및 MLX-LM. "큰 공유 메모리와 Apple 스택을 잘 활용하는 것"에 중점을 둡니다.
컨슈머 CUDA 양자화 엔진: ExLlamaV2 및 ExLlamaV3. "내 3090/4090/5090 박스를 저비트 가중치로 최대한 활용하는 것"에 중점을 둡니다.
프로덕션 서빙 엔진: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. 동시 사용자, KV 캐시, 배치 처리, 병렬화, 관찰 가능성, 토큰당 비용에 중점을 둡니다.
그리고 Dynamo와 같은 오케스트레이션 계층이 엔진 위에 위치하여 플릿을 조정하고, 분리된 프리필/디코드, 라우팅, 오토스케일링을 관리합니다.
llama.cpp: 이식성의 제왕
llama.cpp는 하드웨어가 특이하거나, 제약이 있거나, 오프라인이거나, CPU 중심이거나, 엣지 지향적이거나, 깔끔한 NVIDIA 데이터센터 노드가 아닌 경우에 선택하는 답입니다.
ARM NEON, Accelerate, Metal을 통한 Apple Silicon, AVX/AVX2/AVX512/AMX를 통한 x86, RISC-V, 저비트 양자화, CUDA, HIP를 통한 AMD, MUSA, Vulkan, SYCL, CPU+GPU 하이브리드 오프로드를 지원합니다. 이것이 llama.cpp가 "그냥 실행되게 만드는" 차선을 차지하는 이유입니다.
HTTP 서버는 "장난감 로컬 러너" 이상의 기능을 제공합니다. llama-server는 OpenAI 호환 라우트, Anthropic Messages API 호환성, 재순위화, 연속 배치 처리, 멀티모달 지원, JSON 스키마 제약 조건, 함수 호출, 추측성 디코딩, 웹 UI를 제공합니다.
중요한 제한 사항: llama.cpp는 진지한 멀티 노드 프로덕션 서빙용이 아닙니다. RPC 백엔드는 개념 증명 수준이며, 취약하고, 안전하지 않다고 명시적으로 문서화되어 있습니다.
결론: 이식성, 오프라인 작동, GGUF 또는 하이브리드 오프로드가 플릿 규모 서빙보다 더 중요할 때 llama.cpp를 사용하세요.
멀티 GPU 설정에서는 사용하지 마세요.
MLX 및 MLX-LM: Apple Silicon의 무기
MLX는 Apple Silicon용 Apple의 배열 프레임워크이고, MLX-LM은 그 위에 구축된 LLM 패키지입니다. Mac 우선 ML 스택입니다.
핵심 하드웨어 사실은 통합 메모리입니다. Apple Silicon은 CPU와 GPU가 동일한 메모리 풀에 직접 액세스할 수 있게 합니다. MLX 배열은 통합 메모리에 상주하며, 배열을 별도의 메모리 공간 간에 이동하는 대신 작업을 실행할 때 장치를 선택합니다.
이것은 로컬 추론의 트레이드오프를 변화시킵니다. 개별 GPU 시스템에서는 "VRAM에 맞는가?"가 문제입니다. 대용량 통합 메모리를 갖춘 M 시리즈 Mac에서는 "메모리에 맞는가, 그리고 메모리 시스템이 GPU를 충분히 빠르게 공급할 수 있는가?"가 문제가 됩니다. 대규모 양자화 모델은 동일한 모델이 24 GB 컨슈머 GPU에서는 불가능한 시스템에 탑재될 수 있습니다.
하지만 속도는 더 느립니다.
MLX-LM은 Hugging Face Hub 통합, 양자화, LoRA 및 전체 미세 조정, 분산 추론, 대규모 MLX Community 모델 생태계를 추가합니다. MLX는 더 이상 Mac 전용이 아닙니다. Linux용 CUDA 및 CPU 전용 패키지를 제공합니다. 분산 통신은 MPI, Ring over TCP, Thunderbolt를 통한 RDMA용 JACCL, CUDA용 NCCL을 지원합니다.
MLX-LM 서버 자체는 기본적인 보안 검사만 구현하기 때문에 프로덕션에 권장되지 않는다고 경고합니다.
결론: Mac 우선 ML 및 LLM 워크플로우에는 MLX를 사용하세요. 높은 동시성을 가진 공개 서빙의 경우 실제 서빙 스택으로 시작하세요.
ExLlamaV2 및 V3: 컨슈머 CUDA, 튜닝되고 빠름
ExLlamaV2는 컨슈머 NVIDIA GPU가 자체 성능 이상을 발휘하도록 원하는 사람들을 위한 로컬 CUDA 양자화 엔진입니다. 페이지드 어텐션, 동적 배치 처리, 프롬프트 캐싱, KV 캐시 중복 제거, 배치 생성, 스트리밍, 추측성 디코딩을 지원합니다. 기억해야 할 단어는 로컬입니다. 최신 CUDA GPU, 특히 컨슈머 카드에서 양자화된 모델을 빠르게 만듭니다.
최적: 단일 RTX 3090/4090/5090 박스, 로컬 코딩 어시스턴트, 로컬 채팅, EXL2 양자화 모델, 프로슈머 워크스테이션 사용.
ExLlamaV3는 철학을 멀티 GPU 및 MoE 로컬 추론으로 확장합니다. QTIP 기반 EXL3 양자화 형식, 컨슈머 하드웨어를 위한 유연한 텐서 병렬 및 전문가 병렬 추론, TabbyAPI를 통한 OpenAI 호환 서버, 지속적인 동적 배치 처리, 멀티모달 지원을 추가합니다.
V3는 2-4+개의 컨슈머 NVIDIA GPU를 보유하거나 로컬 MoE를 원할 때 매력적입니다. 주의사항: 일부 모델은 ExLlamaV3에서 텐서 또는 전문가 병렬 처리를 지원하지 않습니다.
결론: ExLlamaV2는 매니아를 위한 로컬 CUDA 엔진입니다. ExLlamaV3는 멀티 GPU(2-4) 로컬 설정을 위한 최첨단입니다. 더 나은 기능을 위해 더 거친 부분이 있을 수 있습니다.
vLLM: 기본 오픈소스 프로덕션 서버
vLLM은 진지한 오픈소스 LLM 서빙을 위해 대부분의 팀이 가장 먼저 평가해야 하는 엔진입니다.
PagedAttention 기반 KV 메모리 관리, 연속 배치 처리, 청크 프리필, 프리픽스 캐싱, CUDA/HIP 그래프, 광범위한 양자화(FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), 최적화된 어텐션 및 GEMM/MoE 커널, 추측성 디코딩, torch.compile, 분리된 프리필/디코드/인코드를 제공합니다.
또한 유연합니다. 텐서/파이프라인/데이터/전문가/컨텍스트 병렬화, 스트리밍, 구조화된 출력, 도구 호출, OpenAI 호환 및 Anthropic Messages API, gRPC, 멀티 LoRA, NVIDIA, AMD, x86/ARM/PowerPC CPU 지원, TPU, Gaudi, Ascend, Apple Silicon 등을 위한 플러그인을 지원합니다.
vLLM 문서는 멀티 노드 배포가 일반적으로 Ray를 사용하며, NVLink 없이 파이프라인 병렬화가 텐서 병렬화를 능가할 수 있다고 언급합니다. 함정은 vLLM이 시스템 사고의 필요성을 제거한다고 가정하는 것입니다. 여전히 배치 처리, 컨텍스트 길이, GPU 메모리 활용률, 병렬화 레이아웃, 라우팅을 조정해야 합니다. vLLM은 매우 훌륭한 엔진을 제공하지만, 여전히 좋은 시스템 설계가 필요합니다.
결론: 누군가 "프로덕션에서 오픈 모델을 서빙해야 합니다"라고 말한다면, vLLM이 기본 시작점입니다.
SGLang: vLLM의 시스템 중심 사촌
SGLang은 서빙 워크로드가 까다로울 때 사용하는 엔진입니다: 구조화된 출력, 긴 컨텍스트, MoE, 분리, 라우팅.
RadixAttention 프리픽스 캐싱, 프리필-디코드 분리, 추측성 디코딩, 연속 배치 처리, 페이지드 어텐션, 텐서/파이프라인/전문가/데이터 병렬화, 구조화된 출력, 청크 프리필, 멀티 LoRA 배치 처리를 제공합니다. NVIDIA, AMD, Intel Xeon, Google TPU, Ascend NPU 등을 지원합니다.
SGLang의 차별점은 서빙 아키텍처입니다. 프리필-디코드 분리는 계산 집약적인 프리필을 메모리 집약적인 디코드와 분리하여 전문화된 인스턴스로 만들고, 그 사이에 KV 캐시를 전송합니다. 이렇게 하면 긴 프리필 배치가 디코드를 중단하고 토큰 지연 시간을 급증시키는 것을 방지합니다.
결론: SGLang은 병목 현상이 "모델을 실행할 수 있는가?"에서 "적대적인 트래픽 아래에서 지연 시간, 메모리, 비용을 태우지 않고 실행할 수 있는가?"로 전환된 팀을 위한 것입니다.
TensorRT-LLM: 최대 NVIDIA 성능
TensorRT-LLM은 NVIDIA 최대 성능 스택입니다. 최적화되어 있고, 전문화되어 있으며, 강력하고, 이식 가능한 척하지 않습니다.
최첨단 최적화로 TensorRT 엔진을 구축하기 위한 Python API와 Python 및 C++ 런타임을 제공합니다. 어텐션, GEMM, MoE를 위한 맞춤형 커널, 프리필-디코드 분리, 광범위한 전문가 병렬화, 추측성 디코딩, NVIDIA Dynamo 및 Triton Inference Server와 통합된 고급 Python API를 포함합니다.
B200 GPU는 최적화된 커널로 FP4 가중치를 로드할 수 있습니다. H100 이상은 FP8 양자화를 지원하여 16비트 대비 최소한의 정확도 손실로 성능을 두 배로 높이고 메모리 소비를 절반으로 줄일 수 있습니다.
장점: H100/H200/B200/GB200/GB300급 플릿, NVIDIA 전용 데이터센터, FP8/FP4 배포, 멀티 노드 서빙, 대규모 MoE. 단점: AMD, Apple 또는 Intel 이식성; 빠르게 변화하는 실험적 모델; 소규모 로컬 설정; "모든 곳에서 작동하는" 것이 필요한 팀.
결론: NVIDIA에 전념하고 절대적인 성능에 관심이 있다면 TensorRT-LLM은 비교 평가에 포함되어야 합니다. 이식성을 성능과 맞바꿉니다. 튜닝된 전문화이지만 기능은 적습니다.
나머지 분야
TGI는 Hugging Face의 프로덕션 서버로, 추적, 메트릭, 텐서 병렬화, 연속 배치 처리를 제공합니다. HF 통합과 단순성이 중요할 때 사용하세요.
MLC LLM은 컴파일러 우선 범용 배포 엔진으로, REST, Python, JavaScript, iOS, Android 전반에 걸쳐 OpenAI 호환 API를 제공합니다. "모든 곳에 LLM을 배포"하는 데 가장 적합하며, 특히 브라우저, 모바일 및 네이티브 앱에 적합합니다.
ONNX Runtime GenAI는 ONNX Runtime을 통해 전체 생성 루프를 구현하며 Foundry Local, Windows ML, VS Code AI Toolkit을 지원합니다. CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU, AMD GPU를 지원합니다. 앱 배포 및 ONNX 워크플로우에 가장 적합합니다.
OpenVINO GenAI는 Intel 최적화 스토리로, Xeon CPU, Arc GPU, Core Ultra, NPU를 지원합니다. 연속 배치 처리 및 페이지드 어텐션을 갖춘 OpenAI 호환 서빙을 제공합니다. Intel 하드웨어에 가장 적합합니다.
LMDeploy는 성능을 위한 TurboMind와 접근성을 위한 PyTorch를 갖춘 CUDA 중심 툴킷입니다. vLLM/SGLang/TensorRT-LLM의 대안을 원하는 CUDA 사용자에게 가장 흥미롭습니다.
NVIDIA Dynamo는 vLLM, SGLang, TensorRT-LLM과 같은 엔진 위에 있는 분산 오케스트레이션 계층으로, 분리, 지능형 라우팅, 다중 계층 KV 캐싱을 지원합니다. 단일 엔진 서빙으로는 더 이상 충분하지 않을 때 사용하세요.
참고: Ollama를 사용하지 마세요.
하드웨어 전략 레시피
CPU 전용 서버: 먼저 llama.cpp. Intel Xeon용 OpenVINO. 앱/ONNX 배포용 ONNX Runtime GenAI.
MacBook / Mac Studio: Mac 네이티브 워크플로우용 MLX / MLX-LM. GGUF 이식성용 llama.cpp.
단일 RTX 3090 / 4090 / 5090: EXL2 로컬 추론용 ExLlamaV2. GGUF 또는 이식성용 llama.cpp. 여러 사용자 서빙 시 vLLM.
듀얼 또는 쿼드 컨슈머 RTX 박스: 멀티 GPU 양자화 추론 또는 MoE용 ExLlamaV3. 서빙 동작이 중요하다면 vLLM. 라우팅 또는 긴 컨텍스트 패턴 테스트 시 SGLang.
8×H100 / H200 노드: vLLM 또는 SGLang으로 시작. NVIDIA 전용이고 성능이 튜닝을 정당화한다면 TensorRT-LLM 벤치마크. 멀티 노드 오케스트레이션이 필요해지면 Dynamo 사용.
B200 / GB200 / GB300급 인프라: TensorRT-LLM, SGLang, vLLM 벤치마크. 플릿 수준 오케스트레이션, KV 인식 라우팅, 오토스케일링을 위해 Dynamo 추가.
AMD MI300 / MI325 / MI350 / MI355: ROCm에서 vLLM 또는 SGLang으로 시작. NVIDIA 벤치마크가 깔끔하게 이전된다고 가정하지 마세요.
Intel Xeon / Core Ultra / Arc: OpenVINO GenAI 또는 OpenVINO Model Server. 앱 임베딩이 중요하다면 ONNX Runtime GenAI.
브라우저, 모바일, 앱 네이티브: MLC LLM / WebLLM 또는 ONNX Runtime GenAI.
벤치마킹: 측정할 것
잘못된 벤치마크: "180 tok/s 나왔어요."
좋은 벤치마크에는 다음이 포함됩니다.
- 모델: 정확한 모델, 아키텍처, 매개변수 수, 활성 MoE 매개변수.
- 가중치: 데이터 타입, 양자화 형식, 그룹 크기, 캘리브레이션.
- 엔진: 버전, 커밋, 백엔드, 플래그.
- 하드웨어: GPU SKU, 메모리 용량, 대역폭, 인터커넥트, CPU, RAM.
- 워크로드: 입력/출력 길이 분포, 동시성, 스트리밍, 공유 프리픽스, 구조화된 출력.
- 메트릭: TTFT, TPOT, 종단 간 지연 시간, p50/p95/p99, 초당 토큰 수, 초당 요청 수, GPU 메모리 사용량, KV 캐시 적중률, 프리필 처리량, 디코드 처리량, 100만 토큰당 비용.
벤치마킹 규칙:
- 단일 사용자 초당 토큰 수만으로 엔진을 절대 비교하지 마세요.
- 실제 프롬프트와 출력 분포를 테스트하세요.
- 현실적인 동시성으로 테스트하세요.
- 프리필과 디코드를 분리하세요.
- 평균뿐만 아니라 p95 및 p99를 추적하세요.
- 목표 컨텍스트 길이에서 메모리 여유를 측정하세요.
- 앱에 반복되는 프리픽스가 있으면 캐시 재사용을 테스트하세요.
- 구조화된 출력은 별도로 벤치마킹하세요. 문법은 오버헤드를 추가합니다.
- LoRA 및 멀티 LoRA는 별도로 벤치마킹하세요.
- 드라이버, CUDA, ROCm, 모델 또는 엔진 업그레이드 후에 다시 테스트하세요.
일반적인 실수
VRAM 용량만으로 선택하기. VRAM은 적합성을 결정합니다. 대역폭과 스케줄러가 속도를 결정합니다. 대용량 통합 메모리 시스템은 거대한 모델을 탑재할 수 있지만, H100은 모델이 맞을 때 훨씬 더 높은 HBM 대역폭으로 인해 더 빠르게 디코드합니다.
약한 인터커넥트에서 텐서 병렬화 사용하기. NVLink 또는 NVSwitch가 없으면 파이프라인 병렬화를 테스트하세요. vLLM 문서는 L40S 유사 설정에서 이를 지적합니다.
KV 캐시 무시하기. 긴 컨텍스트와 동시성은 KV 캐시를 제한 요소로 만들 수 있습니다. PagedAttention, 프리픽스 캐싱, KV 양자화, 분리는 대규모 환경에서 선택 사항이 아닙니다.
로컬 엔진을 프로덕션 서버로 취급하기. llama.cpp 서버는 유능합니다. MLX-LM 서버는 편리합니다. Ollama는 사용하기 pleasant 하지만 사용해서는 안 됩니다.
그러나 프로덕션은 보안, 관찰 가능성, 역압력, 라우팅, 오토스케일링, SLA 동작을 의미합니다. MLX-LM 자체는 서버가 프로덕션에 권장되지 않는다고 경고합니다.
모든 양자화 형식이 이식 가능하다고 가정하기. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, MLX 형식, ONNX는 상호 교환 가능하지 않습니다. 올바른 형식은 엔진에 최적화된 커널이 있는 형식입니다.
모델 아키텍처 무시하기. 밀집 모델, MoE, 하이브리드 어텐션, 멀티모달 모델, 긴 컨텍스트 변형은 엔진의 다른 부분에 부하를 줍니다. 광범위한 지원이 모든 최적화가 동등하게 작동한다는 것을 의미하지는 않습니다.
워크로드 형태 없이 벤치마크 차트 신뢰하기. 1K 입력 / 128 출력에서 Llama 3.1 8B에 대한 차트는 80K 컨텍스트에서 Qwen 3.6 27B / Gemma 4 26B-A4B를 실행하는 코딩 에이전트 또는 500명의 동시 사용자가 있는 RAG 서비스에 대해 거의 말해주지 않습니다.
독단적인 최종 지도
로컬 AI 사용자: 편의성을 위해 LM Studio 또는 Harbor. 제어를 위해 llama.cpp. Mac에서는 MLX. CUDA 로컬 성능을 위해 ExLlamaV2/V3.
로컬 에이전트 구축: 모두 작동해야 하지만, 대부분의 사람들이 사용하는 것을 고려하면 llama.cpp가 이식성에 적합. 사용자가 Apple Silicon을 사용한다면 MLX. 로컬에서 프로덕션 서빙을 시뮬레이션한다면 vLLM.
내부 팀 서빙: vLLM으로 시작. 구조화된 출력, 긴 컨텍스트, 멀티 LoRA, MoE 또는 라우팅이 중요하다면 SGLang 사용.
고객을 대규모로 서빙: vLLM, SGLang, TensorRT-LLM 벤치마크. 라우팅과 분리가 중요하다면 SGLang과 Dynamo가 주목할 가치가 있음.
NVIDIA 데이터센터: 최대 성능을 위해 TensorRT-LLM. 유연성을 위해 vLLM. 복잡한 서빙을 위해 SGLang. 플릿 오케스트레이션을 위해 Dynamo.
Apple Silicon: 네이티브 개발을 위해 MLX. GGUF를 위해 llama.cpp. 통합 메모리는 HBM이 아닌 대역폭 트레이드오프가 있는 용량 슈퍼파워입니다.
엣지, 앱, 브라우저 또는 Windows 네이티브: 스택에 따라 llama.cpp, MLC LLM, ONNX Runtime GenAI 또는 OpenVINO.
최종 원칙
추론 엔진에는 결과가 따릅니다.
다음 질문에 답한 후 엔진을 선택하세요.
- 실제로 어떤 하드웨어를 가지고 있습니까?
- 모델이 빠른 메모리에 맞습니까, 아니면 시스템/통합 메모리에만 맞습니까?
- 디코드 또는 프리필이 병목입니까?
- 어떤 컨텍스트 길이와 동시성이 중요합니까?
- 프롬프트가 프리픽스 캐싱에 충분히 공유됩니까?
- 모델이 밀집형, MoE, 멀티모달 또는 하이브리드입니까?
- 로컬 편의성, 프로덕션 서빙 또는 플릿 오케스트레이션이 필요합니까?
- 대상 엔진에 최적화된 커널이 있는 양자화 형식은 무엇입니까?
- 인터커넥트는 PCIe, NVLink, NVSwitch, Ethernet, RDMA 또는 Thunderbolt입니까?
- 지연 시간, 처리량, 비용, 개인정보 보호, 이식성 또는 개발자 속도를 최적화하고 있습니까?
엔진은 답을 따릅니다.
다음에 또 만나요.
-Ahmad
