문제: 대기열은 긴데 활성 요청은 너무 적음
요청 대기열이 바쁘다고 GPU가 가용 처리 능력을 충분히 활용해 유용한 작업을 하는 것은 아닙니다. vLLM 0.25.1의 Qwen3-30B-A3B에서 ProsGrow는 초기 서빙 구성이 짧은 프롬프트 배치에서 동시에 실행할 수 있는 작업량을 제한한다는 사실을 발견했습니다. 대기 중인 작업이 충분한데도 출력 17,961토큰/초에 머물렀습니다.
프로파일링과 스케줄링 동작 조정으로 이 속도를 출력 41,651토큰/초로 높였습니다. 132% 향상, 즉 2.32배입니다. GPU, 런타임, 체크포인트, 정밀도, 요청 수, 프롬프트/출력 사양은 고정했습니다. 이는 ProsGrow 초기 구성에 대한 실측 개선이며, 최적으로 튜닝한 vLLM 기준 구성과의 비교는 아닙니다.
기준 구성 → ProsGrow 튜닝 후
이 통제된 비교에서 요청 지연 시간 중앙값도 15.91초에서 11.70초로 개선됐습니다. 이는 해당 워크로드에서 회수 가능한 처리 능력을 보여주며, 다른 추론 엔진이나 충분히 최적화된 배포 환경보다 전반적으로 우월하다는 의미는 아닙니다.
스케줄러가 중요했던 이유
ProsGrow는 들어온 부하와 엔진이 실제로 실행을 허용한 작업을 구분한 뒤, 같은 워크로드에서 완료된 처리량과 요청 지연 시간을 비교했습니다. 증거는 스케줄링 병목을 가리켰습니다. 초기 구성은 긴 대기열을 충분한 동시 실행으로 전환하지 못했습니다. 이 결과로 커널 수준의 속도 향상을 따로 입증할 수는 없습니다.
엔지니어링 과제는 이 서빙 스택에서 제한 요인을 찾고, 통제된 조건에서 영향을 평가하며, 유용한 운영 지점을 검증하는 것이었습니다. 모델이 GPU 하나에 들어가므로 독립 복제본을 사용하면 단일 GPU에서 확보한 추가 처리 능력이 전체 노드로 이어지는지 실용적으로 확인할 수 있었습니다.
절충점: 동시 실행 수를 늘리면 결국 대기만 증가
별도의 포화 부하 구성은 두 번의 독립 실행에서 출력 45,941 및 46,701토큰/초를 기록했고, 지연 시간 중앙값은 약 20초였습니다. 같은 탐색에서 해당 운영 지점 이상으로 부하를 늘리자 처리량은 0.91%만 증가한 반면 지연 시간 중앙값은 20.04초에서 29.85초로 늘었습니다. 추가 대기는 더 이상 의미 있는 처리 능력을 제공하지 않았습니다.
메모리도 선택을 제한했습니다. 서빙 오버헤드 때문에 키/값 캐시에 쓸 수 있는 공간이 줄었습니다. 짧은 프롬프트는 선정 구성에 충분한 여유를 남겼습니다. 더 긴 컨텍스트나 대화형 지연 시간 목표는 별도로 평가해야 합니다.
튜닝한 GPU 1개에서 GPU 8개 배치 서비스로
독립 복제본 8개로 진행한 두 번의 동기화 실행은 출력 362,812 및 361,679토큰/초를 달성했습니다. 처리 능력 추정에는 더 낮은 결과를 사용합니다. 각 실행은 요청 32,768개와 출력 토큰 8,388,608개를 모두 완료했고, 실패나 길이 부족 응답은 없었습니다.
더 낮은 결과의 실행은 첫 클라이언트 시작부터 마지막 완료까지 공통 실제 시간 구간 23.19초를 사용했습니다. 이 공유 구간에 모든 작업을 포함하면, 각각 따로 측정한 복제본 속도를 합산해 노드 결과를 부풀리는 일을 피할 수 있습니다.
로컬 132% 향상과 공개 비교 8.17%의 관계
위의 132% 향상은 대기열에 있는 짧은 요청의 스케줄링 조정 효과를 측정합니다. 역량 보고서의 8.17% 비교는 다른 질문에 답합니다. 지정된 더 긴 요청 사양에서 로컬 실행은 보관된 공개 참조 결과와 비교해 어떤 성능을 내는가입니다.
| 비교 | 기준 → 로컬 결과 | 입증하는 내용 |
|---|---|---|
| 로컬 스케줄러 튜닝 | 17,961 → 41,651 출력 토큰/초/GPU · +132% | 동일한 vLLM 0.25.1, 입력 63–66 / 출력 256토큰, 대기 요청 2,048개 |
| 보관된 NVIDIA 참조 결과 | 9,938 → 10,750.04 출력 토큰/초/GPU · +8.17% | 동일한 RTX PRO 6000 SKU 및 입력 1,000 / 출력 1,000 사양, 호스트와 TensorRT-LLM 버전은 다름 |
| 별도로 측정한 전체 노드 처리 능력 | 출력 85,409토큰/초/노드 | 1,000 / 1,000 사양의 동시 TP1 복제본 8개, 동기화 확장 효율 99.31% |
공개 사양 실행은 대기열에 넣은 합성 요청과 TensorRT-LLM 1.3.0rc24를 사용했고, 보관된 NVIDIA 참조는 1.1을 사용했습니다. 긴 대기열에서 평균 요청 지연 시간은 173.04초였습니다. 9,938은 2026년 8월 17일 기록한 NVIDIA 참조 페이지의 수치이며, 이후 출처 검토에서는 해당 행이 더 이상 표시되지 않았습니다. 날짜가 명시된 비교로 이를 보관하고 있으며, 워크로드는 공개 성능 측정 방법으로 정의합니다.
+8.17%는 단일 GPU의 독립 실행 결과입니다. 이 값이나 노드의 85,409 대 361,679토큰/초 차이 모두 순수 소프트웨어 개선만 분리해 보여주지는 않습니다. 후자는 런타임과 요청 길이가 달라집니다. 이 속도는 배치 처리 능력을 설명하며, 대화형 서비스에는 별도의 지연 시간 목표가 필요합니다.
고객에게 달라지는 점
프라이빗 생성 대기열과 합성 데이터 작업은 기존에 설치된 자원으로 작업을 더 빨리 끝내는 이점을 얻을 수 있습니다. ProsGrow는 GPU 추가를 권하기 전에 서빙에서 회수 가능한 처리 능력을 측정할 수 있습니다.
선정한 처리량 구성은 긴 대기열을 필요로 하며, 약 20초의 지연 시간 중앙값을 수용합니다. 배포 적합성 검증에는 고객 모델, 요청 길이 분포, 품질 검사, 트래픽 트레이스를 사용해야 합니다. 대화형 어시스턴트에는 별도의 지연 시간 목표가 필요합니다.
측정 방법과 한계
- 하드웨어 및 소프트웨어: 테스트는 2026년 8월 18일 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU 8개 노드에서 진행했습니다. 통제된 탐색에는 GPU 1개를 사용했습니다. 런타임은
vllm/vllm-openai:v0.25.1이며 ModelOpt NVFP4 가중치와 FP8 키/값 캐시를 사용했습니다. - 모델 및 요청: 고정한 NVIDIA Qwen3-30B-A3B-FP4 체크포인트의 리비전은
2538ded2a4edb247b4d2b4a8ba24e44bd4c017c3입니다. 기술 가이드 프롬프트를 반복하면서 요청 식별자를 바꿨고, API가 보고한 입력은 63–66토큰이었습니다. 온도는 0, 사고 모드는 비활성화했으며 모든 응답이 256토큰 한도에 도달했습니다. - 측정: 처리량은 완료된 출력 토큰 수를 클라이언트가 관측한 경과 시간으로 나눈 값으로, 프롬프트 처리와 로컬 HTTP 오버헤드를 포함합니다. 132% 비교는 구성별 한 번의 측정을 사용합니다. 선정된 포화 구성에는 독립 반복 실행 2회와 동기화 노드 반복 실행 2회가 있으며, 후자는 각각 약 23초에 불과합니다.
- 품질 및 운영: 고정 출력 길이는 생성 작업량을 검증하며 작업 품질을 검증하지는 않습니다. 이는 이전 Qwen3 체크포인트의 로컬 포화 측정으로, 장시간 프로덕션 안정성 테스트나 고객 SLA, 품질 동등성 검사가 아닙니다. 대표 프롬프트, p95/p99 지연 시간, 네트워크 오버헤드, 실패, 도메인 품질은 여전히 프로덕션 수용 조건입니다.
과거 vLLM 0.23 비교도 원본 프롬프트 요청이 보관되지 않아 제목의 증가율에서 제외했습니다. 동일 버전의 로컬 비교가 통제된 기준을 제공합니다.
프라이빗 Qwen3 배포와 vLLM 배치 추론
프라이빗 Qwen3 배포를 계획하는 팀은 이 벤치마크로 배치 추론 처리 능력, GPU 활용률, 허용 가능한 대기 시간을 검토할 수 있습니다. 초당 출력 토큰 수는 완료된 생성 처리량을 측정하고, 요청 지연 시간은 작업의 대기와 실행에 걸리는 시간을 보여줍니다. vLLM 배포 규모는 고객의 요청 구성과 제공 목표에 맞춰 정해야 합니다.
추론 대기열의 병목 찾기
ProsGrow는 고객 모델과 요청 구성을 벤치마크하고 서빙 병목을 식별하며, 프라이빗 배포 규모를 정하기 전에 처리량과 지연 시간의 절충점을 검증할 수 있습니다.
ProsGrow AI와 상담하기