칼럼

칼럼 › 같은 카드인데 값이 다르면 엔진을 먼저 의심하라

같은 카드인데 값이 다르면 엔진을 먼저 의심하라

2026.09.17 · 럭스노트 · 약 9분

매장에서 자주 듣는 말이 있다. 같은 카드로 돌리면 속도도 비슷할 거 아니냐는 것이다. 이 말은 같은 하드웨어라면 소프트웨어 환경도 같을 거라고 읽기 때문에 나온다. 하지만 같은 카드, 같은 모델, 같은 양자화라도 엔진이 다르면 속도가 갈리고 그 차이가 생각보다 크다. 표본은 LLM 벤치마크 272건을 엔진별로 나눠 속도를 세어 모은 것이다.

엔진이 다르면 데이터가 메모리에서 연산부로 들어가는 방식이 달라진다. 같은 연산을 수행하더라도 이동 경로가 짧으면 빠르고 길면 느리다. 이 차이는 하드웨어 성능을 그대로 반영하지 못하게 만든다. 카드가 아무리 빨라도 엔진이 데이터를 비효율적으로 처리하면 실제 체감 속도는 떨어진다. 따라서 하드웨어 스펙만 보고 판단하면 안 된다.

속도 차이는 단순한 오차가 아니다. 공개된 실측을 모아 보면 엔진에 따라 같은 작업에 걸리는 시간이 크게 벌어진다. 이 수치는 사용자가 직접 체감할 수 있는 수준이다. 매장에서 상담할 때 이 점을 짚어줘야 한다. 하드웨어 교체보다 소프트웨어 환경 점검이 먼저일 수 있음을 알려주는 것이다. 같은 카드라도 엔진 선택에 따라 결과가 달라진다는 사실을 이해해야 한다.

같은 카드인데 속도가 갈리는 자리가 있다

공개된 실측 자료를 모아 보면 전체 272건 가운데 엔진이 다른 짝은 6건뿐이다. 비율로 환산하면 2%에 불과하다. 이는 같은 하드웨어 환경에서도 소프트웨어 구성에 따라 결과가 갈릴 수 있음을 보여주는 드문 사례다. 특히 Qwen3.6-27B 모델에서 llama.cpp와 llama.cpp(b9079)를 비교했을 때 초당 토큰 수 차이가 19.7로 나타났다. 단순히 버젼 번호의 차이를 넘어, 동일한 엔진 이름 아래에서도 내부 처리 방식의 미세한 변동이 성능에 직접적인 영향을 미친다는 뜻이다.

이 수치는 매장 상담 시 중요한 기준이 된다. 손님이 동일한 그래픽카드와 메모리를 사용해도 체감 속도가 다르면, 하드웨어 불량보다는 소프트웨어 환경의 불일치를 먼저 의심해야 한다. 특히 최신 모델일수록 엔진의 미세한 업데이트나 빌드 차이가 성능에 큰 변수로 작용할 수 있다. 따라서 하드웨어 교체 비용을 들이기 전에, 현재 사용 중인 소프트웨어의 정확한 버전과 설정을 확인하는 과정이 필수적이다. 같은 카드라도 엔진 선택과 그 세부 구성에 따라 결과가 달라진다는 점을 인지하고, 문제 해결의 순서를 소프트웨어 점검부터 시작하도록 안내해야 한다.

차이가 나는 자리는 정해져 있다

자료에 적힌 실측을 모아 보면, 같은 하드웨어 위에서 엔진에 따라 처리 속도가 크게 갈린다. llama.cpp 계열이 137건으로 가장 많았고, ollama와 MLX가 각각 20건과 18건으로 뒤를 이었다. 건수 차이가 크다는 것은 특정 엔진이 더 많이 사용되었거나, 해당 환경에서 더 많은 테스트가 이루어졌음을 의미한다.

속도 수치로 보면 llama.cpp (llama-bench tg128, build 6205)가 평균 196.3 tps로 가장 높았다. 반면 llama.cpp server (--n-cpu-moe 27, MoE offload to CPU RAM) 설정에서는 평균 1.8 tps에 그쳤다. 이 두 값의 차이는 단순한 오차가 아니라, 메모리 접근 방식과 연산 분배 전략의 근본적 차이에서 비롯된다. 동일한 카드라도 어떤 경로로 데이터를 주고받느냐에 따라 초당 처리 토큰 수가 100배 이상 벌어질 수 있다.

이러한 격차는 하드웨어 자체의 성능 한계라기보다, 소프트웨어가 하드웨어를 얼마나 효율적으로 활용하느냐의 문제다. CUDA나 Vulkan 같은 가속기를 직접 호출하는 방식과, CPU 메모리로 오프로드를 하는 방식은 물리적 구조가 다르다. 따라서 속도 저하를 발견했을 때 즉시 부품 교체를 고려하기보다, 현재 실행 중인 엔진의 빌드 버전과 메모리 할당 설정을 먼저 점검하는 것이 합리적이다.

결국 문제는 카드가 아니라, 그 카드를 다루는 엔진의 선택과 구성에 있다.

엔진별 벤치마크 건수 분포
엔진별 벤치마크 건수 분포

엔진이 속도를 가르는 까닭

공개된 실측 자료를 보면 272건의 처리 속도 기록에서 최소 1.8에서 최대 286.9까지 벌어져 있고, 평균은 66.0으로 집계된다. 이 폭넓은 차이는 동일한 하드웨어 환경에서도 소프트웨어 계층의 구현 방식에 따라 성능이 극단적으로 달라진다는 점을 보여준다. 특히 48종의 엔진 중 llama.cpp가 이 전체 범위를 커버하며, 특정 빌드나 설정에 따라 속도가 100배 이상 벌어질 수 있음을 시사한다.

이러한 편차는 메모리 접근 패턴과 병렬화 전략의 차이에서 기인한다. 같은 그래픽카드라도 데이터가 GPU 메모리로 이동하는 경로와 연산이 수행되는 순서가 엔진마다 다르다. 최적화 수준이 낮은 엔진은 빈번한 메모리 복사나 동기화 지연을 유발해 처리량이 급감한다. 반대로 효율적인 스케줄링을 갖춘 엔진은 하드웨어 자원을 밀도 있게 채워 높은 처리량을 유지한다. 따라서 특정 엔진이 항상 우월하다고 단정할 수 없으며, 실제 워크로드와 하드웨어 조합에 따라 결과가 역전될 수 있다.

숫자는 문맥 안에서 의미를 가진다. 평균 66.0이라는 값만으로는 개별 시스템의 상태를 판단하기 어렵다. 최소 1.8과 최대 286.9 사이의 분포를 살펴야 현재 시스템이 어디에 위치하는지 알 수 있다. 만약 자신의 시스템이 하위 범위에 머물러 있다면, 하드웨어 교체보다 엔진의 빌드 버전이나 메모리 할당 파라미터를 점검하는 것이 우선이다. 같은 카드를 사용하더라도 소프트웨어 구성에 따라 체감 성능이 크게 달라지므로, 문제 해결 시 하드웨어보다 소프트웨어 계층의 변수를 먼저 검토해야 한다.

tps 평균이 가장 높은 엔진 vs 가장 낮은 엔진
tps 평균이 가장 높은 엔진 vs 가장 낮은 엔진

이 셈을 그대로 믿으면 안 되는 자리

벤치마크 272건은 모두 공개 자료에서 모은 값이며, 우리가 직접 측정하지 않았다. 따라서 특정 엔진의 성능 수치는 해당 벤치마크가 밝힌 내용을 그대로 옮긴 것이다. 같은 엔진이라도 모델 구조나 양자화 방식이 다르면 처리 속도가 달라질 수 있으므로, 단순 비교보다는 구성 요소를 함께 확인해야 한다.

엔진 목록에는 llama.cpp, vLLM, Ollama 등 48종이 포함되어 있다. 이 중 일부는 하드웨어 가속을 지원하지 않거나, CPU 메모리로 오프로드하는 설정을 사용한다. 이러한 기술적 선택은 성능에 직접적인 영향을 미치지만, 모든 환경에서 동일한 결과를 보장하지는 않는다.

회사 규정상 특정 엔진 사용이 요구되는 경우가 있다. 이는 기술적 효율성보다는 내부 정책이나 보안 기준에 따른 결정이다. 따라서 성능 최적화만으로는 해결되지 않는 문제도 존재하며, 규정 준수 여부가 우선시되는 자리는 별도로 구분해야 한다.

그래서 무엇을 물어야 하나

손님이 먼저 확인해야 할 것은 모델 이름과 양자화 방식이다. 이 두 가지가 같아야 비교가 성립하며, 여기서 어긋나면 속도 차이는 당연한 결과다. 다음으로 그 모델이 어떤 엔진으로 실행되는지 파악해야 한다. 공개된 실측 자료를 모아 보면 llama.cpp 엔진이 초당 토큰 수에서 평균 196.3으로 가장 높게 기록되었다. 같은 조건에서 엔진이 다른 짝이 6개 존재하며, 이 차이가 속도를 가르는 결정적 요인이다.

엔진마다 내부 구조와 최적화 방식이 다르기 때문에 같은 하드웨어와 모델이라도 처리 속도가 갈린다. 따라서 성능 문제를 진단할 때는 하드웨어 사양보다 소프트웨어 환경의 정합성을 먼저 점검해야 한다. 모델과 양자화가 일치하는지, 그리고 어떤 엔진으로 구동되는지를 명확히 하지 않으면 속도 차이를 설명할 수 없다. 결국 같은 카드라도 엔진이 다르면 속도가 갈린다는 사실을 인지하는 것이 문제 해결의 출발점이다.

게시판에서 이 글의 댓글 보기 →

다른 칼럼