추론 엔진을 고르지 마세요, 하드웨어 전략을 고르세요

서로 다른 크기의 토대(하드웨어)가 그 위를 흐르는 소프트웨어의 모양을 결정한다는 개념을 형상화했습니다.

개요

LLM을 서빙하려고 마음먹으면 가장 먼저 던지는 질문이 보통 “어떤 추론 엔진을 쓸까”입니다. vLLM, SGLang, TensorRT-LLM, llama.cpp 같은 이름들을 늘어놓고 벤치마크 표를 비교하기 시작합니다. 최근 한 엔지니어가 이 질문 자체가 순서가 틀렸다고 지적해 화제가 됐습니다. 핵심 주장은 단순합니다. “추론 엔진을 고르는 게 아니라 하드웨어 전략을 고르는 것이고, 엔진은 그다음에 따라온다”는 것입니다.

ThakiCloud는 쿠버네티스 위에서 GPU 자원을 풀로 묶고 여러 고객의 추론 워크로드를 서빙하는 플랫폼을 운영합니다. 그래서 이 “하드웨어 우선” 프레임은 단순한 트윗 한 줄의 통찰이 아니라, 우리가 매일 GPU 스케줄링과 서빙 스택을 설계하며 내리는 결정의 언어이기도 합니다. 이 글에서는 이 선택법을 정리하고, 왜 우리가 대부분의 경우 기본값으로 vLLM에서 출발해 병목이 측정될 때만 다른 엔진으로 옮기는지를 설명합니다.

핵심 주장: 엔진이 아니라 하드웨어 전략을 고른다

원 저자의 논지는 추론 엔진을 추상적인 성능 순위로 줄 세우지 말라는 것입니다. 엔진은 진공 속에서 빠르거나 느린 것이 아니라, 특정 하드웨어 위에서, 특정 워크로드 모양에 대해 빠르거나 느립니다. 따라서 결정의 출발점은 “가장 빠른 엔진은 무엇인가”가 아니라 “나는 어떤 하드웨어를 가지고 있고, 내 워크로드는 어떤 모양인가”여야 합니다. 하드웨어와 워크로드가 정해지면 적합한 엔진의 후보는 자연스럽게 한두 개로 좁혀집니다.

이 사고방식이 중요한 이유는, 사람들이 흔히 자기 환경과 무관한 벤치마크를 보고 엔진을 고르기 때문입니다. 8장짜리 H100 클러스터에서 측정한 최대 처리량 숫자는, 맥북이나 RTX 한두 장으로 돌리는 사람에게는 거의 의미가 없습니다. 반대로 에지 박스에서 잘 도는 경량 엔진을 대규모 동시 요청 서빙에 그대로 들이밀면 무너집니다. 결국 맞춰야 할 것은 “런타임을 워크로드의 모양과 하드웨어, 그리고 운영 부담을 감내할 수 있는 정도에 맞추는 것”입니다.

하드웨어별 엔진 지도

원 글이 제시한 치트시트는 하드웨어 상황별로 엔진을 매핑합니다. 핵심을 정리하면 다음과 같습니다.

하드웨어 / 상황                         적합한 엔진
------------------------------------------------------------
CPU·맥·에지·이상한 환경, VRAM 부족      → llama.cpp (GGUF, 하이브리드 오프로드)
  + RAM은 넉넉할 때
맥(Apple Silicon) 중심 워크플로         → MLX
RTX 소비자 GPU 1~4장                    → ExLlamaV2 / ExLlamaV3
일반적인 프로덕션 서빙                  → vLLM
복잡한 인프라·롱 컨텍스트·MoE          → SGLang (RadixAttention)
NVIDIA에서 최대 성능이 절실할 때        → TensorRT-LLM (컴파일 엔진)

각 엔진의 성격을 조금 더 풀면 이렇습니다.

• llama.cpp: 거의 어디서나 돕니다. VRAM이 빠듯하고 시스템 RAM이 넉넉할 때, GGUF 양자화와 하이브리드 오프로드로 버티는 데 강합니다. 개인 실험, 에지, 노트북에 적합합니다.
• MLX: 애플 실리콘에 최적화된 선택지로, 맥 중심 워크플로에서 자연스럽습니다.
• ExLlamaV2/V3: RTX 한두 장에서 네 장 정도의 소비자 GPU 환경에서 양자화 모델을 효율적으로 돌리는 데 특화돼 있습니다.
• vLLM: 하드웨어와 모델 커버리지가 가장 넓고 성능이 예측 가능합니다. 일반적인 프로덕션 서빙의 기본 후보입니다.
• SGLang: RadixAttention과 다중 호출 스케줄링으로 높은 동시성, 롱 컨텍스트, MoE 워크로드에서 강점을 보입니다. 대신 인프라가 더 복잡합니다.
• TensorRT-LLM: NVIDIA 하드웨어에서 컴파일된 엔진 경로로 가장 높은 원시 처리량을 냅니다. 대신 운영 복잡도가 상당합니다.

여러 비교 분석들도 대체로 같은 결론에 수렴합니다. 중·고볼륨 프로덕션에서는 처리량과 개발자 경험의 균형으로 vLLM이나 SGLang이 무난하고, 초고볼륨이나 지연에 극도로 민감한 경우에 한해 TensorRT-LLM의 컴파일 경로에 투자하는 식입니다. 대부분의 팀에게 권장되는 출발점은 vLLM이며, 프로파일링으로 병목이 확인됐을 때 비로소 다른 엔진으로 이전하라는 것입니다.

왜 이 순서가 맞는가

“엔진 먼저”가 위험한 이유는 조기 최적화이기 때문입니다. 아직 실측 병목이 무엇인지 모르는 상태에서 가장 빠르다고 알려진 엔진을 고르면, 운영 복잡도라는 비용을 먼저 치르고 그 대가로 얻을 이득은 불확실합니다. TensorRT-LLM의 컴파일 경로는 분명 빠르지만, 엔진 빌드와 버전 관리, 모델 변환 파이프라인이라는 지속적인 운영 부담을 동반합니다. 워크로드가 그 복잡도를 정당화하지 못하면 이는 순손실입니다.

“하드웨어와 워크로드 먼저”는 반대로 측정 가능한 사실에서 출발합니다. 가진 GPU의 종류와 장수, 모델 크기, 컨텍스트 길이, 동시 요청 패턴은 모두 관측 가능한 값입니다. 이 값들이 정해지면 후보 엔진은 좁혀지고, 그중 측정된 병목에 맞는 가장 단순한 엔진을 고르는 것이 합리적입니다. 단순함은 그 자체로 운영 가치입니다. 장애가 적고, 업그레이드가 쉽고, 사람을 적게 묶습니다.

ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점

이 프레임은 ThakiCloud의 서빙 운영 철학과 거의 그대로 겹칩니다. 우리는 쿠버네티스 위에서 GPU를 풀로 묶고 Kueue로 큐잉·스케줄링을 관리하며 멀티테넌트로 추론 워크로드를 서빙합니다. 이 환경에서 “하드웨어 전략 먼저”는 다음과 같이 구체화됩니다.

• GPU 풀의 모양이 엔진 후보를 정합니다. 우리가 운영하는 노드 풀의 GPU 종류와 토폴로지가 곧 하드웨어 전략입니다. 데이터센터급 NVIDIA GPU 위에서 다수 테넌트에게 범용 서빙을 제공하는 우리의 기본 상황에서는, 커버리지가 넓고 성능이 예측 가능한 vLLM이 자연스러운 기본값입니다. 그래서 우리는 새 모델을 올릴 때 vLLM에서 출발합니다.
• 워크로드 모양으로 분기합니다. 특정 테넌트의 워크로드가 롱 컨텍스트나 MoE, 높은 동시성으로 치우치면 SGLang의 RadixAttention 같은 특성이 의미를 갖습니다. 반대로 지연에 극도로 민감하고 모델·하드웨어가 고정된 초고볼륨 서비스라면 그때 TensorRT-LLM의 컴파일 경로를 검토합니다. 핵심은 이 분기를 추측이 아니라 측정된 병목에 근거해 내린다는 점입니다.
• 온프레미스·self-hosting에 그대로 적용됩니다. 외부 API에 의존할 수 없는 공공·연구·금융 고객에게는 “어떤 하드웨어를 가졌는가”가 선택의 전부가 됩니다. 가진 GPU 세대와 장수에 맞춰 엔진을 고르고, 비용 대비 처리량을 자기 인프라 안에서 최적화하는 것이 곧 차별화입니다. 하드웨어 우선 사고는 이런 제약 환경에서 특히 강력합니다.

운영자 입장에서 가장 실용적인 결론은 “기본은 vLLM, 이전은 병목이 증명될 때만”이라는 규칙입니다. 멀티테넌트 환경에서 엔진을 테넌트마다 제각각 운영하면 관리 비용이 폭증합니다. 표준 엔진을 하나 정해 두고, 측정된 예외에 한해서만 특화 엔진을 붙이는 편이 장기적으로 훨씬 싸게 먹힙니다.

한계 및 반론

이 프레임이 만능은 아닙니다. 몇 가지 짚어 둘 지점이 있습니다.

• 치트시트는 출발점이지 결론이 아닙니다. 같은 vLLM이라도 버전, 양자화 방식, 배치·KV 캐시 설정에 따라 결과가 크게 달라집니다. “vLLM이면 끝”이 아니라, 정해진 엔진 안에서의 튜닝이 또 다른 큰 변수입니다.
• 하드웨어를 선택할 수 있다는 전제가 늘 성립하지는 않습니다. “하드웨어 전략 먼저”는 하드웨어를 고를 여지가 있을 때 강력합니다. 이미 특정 GPU에 묶여 있는 조직에게는 사실상 엔진 선택만 남습니다. 그래도 워크로드 모양으로 후보를 좁히는 원칙은 여전히 유효합니다.
• 숫자는 직접 측정해야 합니다. 외부 비교 글의 처리량·지연 수치는 측정 환경에 강하게 의존합니다. 자기 모델과 자기 하드웨어, 자기 트래픽 패턴으로 프로파일링하지 않은 숫자는 참고치일 뿐입니다. 이 글에서도 특정 처리량 수치를 단정적으로 인용하지 않은 이유가 여기에 있습니다.
• 엔진 생태계는 빠르게 움직입니다. 오늘의 강점 분포가 다음 분기에 바뀔 수 있습니다. 그래서 “한 번 고르고 끝”이 아니라, 표준 엔진을 두되 주기적으로 재평가하는 운영 루틴이 필요합니다.

정리하면, “추론 엔진을 고르지 말고 하드웨어 전략을 고르라”는 조언은 조기 최적화를 피하고 측정 가능한 사실에서 출발하라는 좋은 규율입니다. ThakiCloud에게 이는 새로운 발상이 아니라 우리가 GPU 풀과 멀티테넌트 서빙을 설계하며 이미 따르고 있는 원칙의 간결한 요약입니다. 기본은 단순하고 넓은 엔진에서 출발하고, 복잡한 특화 엔진은 병목이 스스로를 증명할 때만 도입합니다.

출처

• 원 트윗(@TheAhmadOsman): x.com/TheAhmadOsman/status/2051779046468673986
• 공유 트윗(@hjguyhan 경유): x.com/hjguyhan/status/2069049583276298276
• 보강 비교 분석: vLLM vs SGLang vs TensorRT-LLM vs Ollama (LeetLLM, 2026), Best LLM Inference Engines 2026 (Yotta Labs)