RTX 5090에서 구동한 Qwen3.8 27B: DFlash2 적용 여부에 따른 6개 추론 엔진 벤치마크

단일 요청 수치는 코드, 산문, 지문 복사 시나리오의 중앙값을 평균 낸 것입니다. 마지막 열은 별도의 동시 요청 워크로드에서 나온 결과이며, 요청당 처리량이 아닌 **총 처리량(aggregate throughput)**을 나타냅니다.

DFlash2를 사용한 SGLang의 경우, 32GB 메모리에 두 개의 활성 요청 레인만 들어갈 수 있어서 제출된 4개의 요청 중 일부는 대기열에 들어갔습니다. vLLM의 추론(speculative) 설정은 GPU 메모리 사용률을 0.97로 설정해야 했습니다.

NInfer가 추론 디코딩 및 동시 처리량에서 앞섰습니다. llama.cpp는 일반 디코드 속도에서 가장 높은 수치를 기록했습니다. TensorSharp, SGLang, velox는 DFlash2 사용 시 234~235 tok/s로 사실상 동률이었습니다.

TensorSharp의 경우, 가장 고무적인 처리량 결과는 4개 요청을 합쳐 총 445 tok/s를 기록한 것입니다. 이 워크로드에서는 NInfer가 488로 여전히 앞섰습니다.

지연 시간 (Latency) 결과

32K 프롬프트: NInfer는 추론 없이 3.02초 TTFT, DFlash2 사용 시 3.07초를 기록했습니다. TensorSharp는 3.96초 → 4.07초였습니다. llama.cpp는 5.01초 → 8.16초로, 이 구성에서 추론 기능을 켰을 때 초기 지연 시간 비용이 더 크게 발생했습니다.

스크린샷 입력: 추론 없이 1344×768 스크린샷을 입력했을 때, TensorSharp는 125ms TTFT, vLLM은 127ms를 기록했습니다. 사실상 동률입니다. DFlash2 사용 시 TensorSharp는 142ms, NInfer는 163ms를 기록했습니다.

4턴 도구 루프: DFlash2 사용 시 엔드투엔드 시간은 다음과 같습니다.

• TensorSharp: 0.748초

• SGLang: 0.791초

• llama.cpp 및 NInfer: 0.817초

• velox-inferer: 1.42초

• vLLM: 1.45초

이 테스트는 로컬에서 파일 목록 확인, 파일 읽기, 계산기 호출을 수행하는 통제된 루프였습니다. 이 워크로드에 대한 결과값이며, 브라우저 자동화나 더 긴 에이전트 작업은 별도의 테스트가 필요합니다.

방법론 및 한계

각 시나리오는 웜업 후 3회 반복 측정했습니다. 시간은 클라이언트에서 localhost HTTP 스트리밍을 통해 측정했으므로, TTFT에는 요청 처리, 템플릿 적용, 토큰화, 프리필(prefill)이 포함됩니다. 독립적인 요청 간 재사용을 방지하기 위해 고유한 프롬프트 nonce를 사용했고, 멀티턴 및 도구 루프 테스트에서는 의도적으로 접두사를 재사용했습니다.

실행 간 최대 약 4%의 디코드 변동이 관찰되었습니다. 대략 5% 미만의 차이는 결론을 내리기 어렵다고 봅니다.

또한 테스트 도구로 응답을 검증했습니다. velox는 두 모드 모두에서 3회 반복 테스트 중 JSON 스키마 케이스를 모두 실패했습니다. DFlash2를 사용한 NInfer는 JSON 객체 응답 3회 중 1회에서 빈 JSON 키를 생성했습니다. 다른 검사는 통과했지만, 이는 제한적인 기능 검사일 뿐이며 양자화 방식 간의 품질 동일성은 평가하지 않았습니다.

Thinking 모드, 비-greedy 샘플링, 4개 이상의 동시성, 32K를 초과하는 프롬프트는 테스트하지 않았습니다. 정확한 엔진 리비전, 모델 파일, 실행 설정은 보고서에 문서화되어 있습니다.

5090에서 이 엔진들 중 하나를 쓰다가 성능을 눈에 띄게 깎아먹는 설정을 발견하면, 어떤 설정인지, 왜 바꿔야 하는지 좀 알려주라.

TensorSharp source