한 유저가 RTX 5090 단일 카드에서 Qwen3.8-27B를 구동하는 추론 엔진 세 종류, 즉 llama.cpp, vLLM, NInfer의 품질과 속도를 실제 프로덕션 워크로드 기반으로 비교한 결과를 공개했다. 글쓴이는 HVAC 업계용 콘텐츠 인텔리전스 파이프라인에서 긴 컨텍스트 검색과 구조화 추출이 많은 로컬 추론 서버로 Qwen3.8-27B를 운영 중이며, 기존에는 llama.cpp(Q5_K_M GGUF, q5_1 KV, 262K 컨텍스트, MTP)를 썼지만 parallel=1로 동시 서빙이 불가능해 NVFP4 대체재로 vLLM과 NInfer를 시험했다고 밝혔다. 단순한 체감이 아닌 제대로 된 품질 평가를 함께 진행한 점이 이번 비교의 특징이다.

테스트 환경은 eGPU 도크(OCuLink Gen4 x4)에 장착된 RTX 5090 32GB, Ryzen 7 7840HS, 32GB DDR5, Ubuntu 26.04, 오픈 커널 드라이버 nvidia 610.43.02이며, 글쓴이는 eGPU가 모델 로딩에만 영향을 준다고 설명했다. 엔진별 설정을 보면 llama.cpp는 Q5_K_M GGUF 양자화에 q8_0 KV 캐시, 196K 컨텍스트, MTP(게이트 실패), parallel=1, VRAM 31.6GB를 쓰고, vLLM은 NVFP4에 FP8 KV 캐시, 262K 컨텍스트, MTP 없음, 연속 배칭, VRAM 29.6GB를 쓴다. NInfer는 NVFP4에 FP8 KV 캐시, 240K 컨텍스트, 수용률 76%의 MTP3, x2 레인, VRAM 30.5GB다.

평가는 글쓴이의 실제 프로덕션 워크로드에서 뽑은 6개 티어, 티어당 50개 항목으로 구성한 자체 하네스로 진행됐다. 티어는 산업 관련성 이진 분류, 64K에서 240K 컨텍스트의 업계 팟캐스트·영상 전사본에 심은 팩트 검색, 120K 토큰 이상의 다중 전사본 QA(답변 불가 통제 항목 포함), thinking 모드를 켠 수치·논리 추론(greedy pass@1), json_mode 기반 구조화 추출(NInfer는 json_mode 미지원으로 제외), 녹화된 에이전트 에피소드 재생(진단용, 세 엔진 모두 실패)이다. 모든 엔진에 동일 프롬프트, 동일 시드(42), 동일 골드 라벨을 적용했고 cache_prompt는 쓰지 않았으며, 사전 등록된 비열등성 마진과 paired cluster-bootstrap 신뢰구간으로 통계 비교를 했다. 평가 도중 Codex/GPT-5, DeepSeek V4 Pro, Grok 4.5, Kimi K3 네 모델 패널이 방법론을 감사해 10가지 문제, 그중 모델이 옳고 글쓴이의 라벨이 틀렸던 골드 항목 4건을 포함해 발견했고, 모두 수정한 뒤 재측정했다.

품질 결과에서 관련성 분류는 llama.cpp 86.0%, vLLM 84.0%, NInfer 86.0%, 전사본 QA는 82.0%, 78.0%, 88.0%, 추론은 100%, 100%, 98.0%를 기록했다. 팩트 검색은 세 엔진 모두 수용 가능한 항목에서 100%를 유지했으나 llama.cpp는 196K 컨텍스트 제한 때문에 192K 항목을 담지 못해 29건, vLLM과 NInfer는 41건을 풀었다. 구조화 추출 F1은 llama.cpp 0.300, vLLM 0.350이었고 NInfer는 제외됐으며, 도구 재생은 세 엔진 모두 0%로 전부 오류였다. 통계 비교에서 팩트 검색 델타는 -0.29(NInfer 우위, p=0.0006)였지만 이는 전적으로 컨텍스트 용량 차이에서 온 것이고, 전사본 QA 델타 -0.03(p=0.69), 추론 델타 +0.02(p=0.72), 관련성 McNemar p=1.0, 도구 재생 델타 0.0으로 차이가 없었다. 결국 품질은 세 엔진 간 통계적으로 구분 불가능하다는 것이 핵심 결론이다.

속도 측정(서버 측 타이밍 기준)에서 NInfer는 디코딩 1K에서 114 tok/s 대비 158 tok/s(1.4배), 32K에서 109 대비 213 tok/s(2.0배), 128K에서 72 대비 202 tok/s(2.8배)를 기록했다. 프리필은 1K에서 1545 대비 7265 tok/s(4.7배), 32K에서 2155 대비 6892 tok/s(3.2배), 128K에서 1528 대비 3904 tok/s(2.6배)였고, TTFT는 1K 670ms 대비 138ms(4.9배), 32K 15.2초 대비 4.8초(3.2배), 128K 85.9초 대비 33.6초(2.6배)다. vLLM은 perf probe가 서버 측 타이밍이 아닌 월클록 타이밍을 사용해 수치 비교가 불가능해 표에서 제외됐으며, 커뮤니티 보고와 작업별 측정을 종합하면 vLLM의 단문맥 디코딩은 약 70 tok/s로 NInfer의 순수 스텝 레이트(약 66 tok/s)와 사실상 같다. 글쓴이는 NInfer의 속도 우위가 전부 MTP3 추측 디코딩 덕분이며, 수용률 76%의 MTP3가 158~213 tok/s를 만들어낸다고 분석했다. 또 디코딩 가속은 컨텍스트가 길어질수록 커져 1K에서 1.4배, 128K에서 2.8배에 달하고, NInfer는 Anthropic Messages 형식의 정확한 토큰 수를 알려주는 /v1/messages/count_tokens 엔드포인트가 장점인 반면 response_format json_object가 400을 반환하는 등 json_mode를 지원하지 않는 점이 한계로 지적됐다.