Qwen3.8-27B 실전 벤치마크: 처리량·응답시간·KV 캐시까지

2일 전

8분 분량

Qwen3.8-27B의 Air API 출시와 성능 분석을 소개하는 이미지. 우측에는 Qwen3.8-27B 칩과 성능 그래프가 표현되어 있다.

안녕하세요. AIEEV 개발팀에서 AI 인프라 연구개발을 담당하고 있는 조용래입니다.

Air API에 Qwen3.8-27B-BF16 모델이 새롭게 추가됐습니다. 현재 Air API의 Playground에서 테스트 환경을 제공하고 있어, 별도의 인프라나 서빙 엔진을 준비하지 않고도 지금 바로 실제 업무 데이터와 프롬프트로 성능을 시험해 볼 수 있습니다. 이번 글에서는 Qwen3.8-27B의 주요 특징과 공개 벤치마크를 먼저 살펴봅니다. 이어 단일 GPU 환경에서 측정한 처리량과 응답시간, 메모리 사용 특성을 공유하고, 이러한 결과를 실제 서비스의 모델 선택과 검증에 어떻게 활용할 수 있는지 정리하겠습니다.

Qwen3.8-27B은 어떤 모델인가요?

Qwen3.8-27B는 대화와 문서 이해, 코드 작성부터 여러 단계에 걸친 복잡한 작업까지 폭넓게 수행할 수 있는 멀티모달 AI 모델입니다. Alibaba Group의 Qwen Team이 2026년 8월 14일 공개했으며, Qwen3.5의 구조를 기반으로 코딩과 전문 업무, 연구, 장기 작업 수행 능력을 강화했습니다. 텍스트뿐만 아니라 이미지와 영상을 이해하고, 작업의 복잡도에 따라 추론 깊이를 조절할 수 있는 것도 특징입니다. 공개 이후 Hugging Face에서 3주 만에 약 13.8K개의 좋아요와 525만 회 이상의 다운로드를 기록하며 뜨거운 관심을 받았습니다. Qwen Team은 원본 가중치를 사용하는 BF16 모델과 블록 단위 양자화를 적용한 FP8 체크포인트를 함께 공개하며 FP8 버전이 메모리 사용량을 줄이면서도 주요 벤치마크에서 BF16과 거의 유사한 성능을 유지한다고 설명했습니다. Air API에서는 BF16 모델을 제공하고 있습니다. 두 모델의 차이가 실제 추론 환경에서는 어떻게 나타나는지 확인하기 위해, BF16과 FP8의 성능 및 메모리 사용량을 직접 비교한 양자화 실험 결과는 뒤에서 소개하도록 하겠습니다. [3][4]

저희가 Qwen 모델을 소개하는 게 이번이 처음은 아닙니다. Air API는 Qwen3.5-9B와 Qwen3.6-35B-A3B, Qwen3-TTS를 비롯한 오픈웨이트 모델 여러개를 이미 제공하고 있고, 가장 저렴하게 Qwen을 쓰는 방법은 지난 블로그에 정리해뒀습니다. 여기에 Qwen3.8-27B까지 새롭게 추가하면서 용도와 규모에 따라 선택할 수 있는 범위를 넓혔습니다. 아래 표는 공식 모델 카드의 사양을 정리한 것입니다. 여기 적힌 값은 모델이 지원하는 상한이고, 실제 처리량과 첫 응답시간은 요청 길이와 동시 요청 수, 서빙 설정에 따라 달라집니다.

항목	사양
제공 모델	Qwen3.8-27B-BF16 (이 글에서 다루는 Air API 모델)
매개변수	270억 개
가중치	BF16 (16비트 부동소수점), 표기 크기 51.8 이진 기가바이트
언어 디코더	64층 (게이트 델타넷 48개 + 출력 게이트 전체 어텐션 16개)
문맥 길이	기본 256K, 설정을 통해 최대 1M 확장
지원 입력	텍스트, 이미지, 영상

외부 비교 지표도 살펴보겠습니다. 아래 그림은 OpenRouter에서 Qwen3.8-27B를 지능, 코딩, 에이전트형 작업의 세 범주에 대해 Nemotron 3.5 Lightning, Gemma 4 31B와 비교한 결과입니다. 여기서 점수는 정확도 백분율이 아니라 OpenRouter 비교 화면의 외부 업무 역량 종합 점수를 의미합니다. Qwen3.8-27B는 지능 52점, 코딩 68점, 에이전트형 작업 51점으로 세 범주 모두 비교 모델보다 높습니다. 특히 코딩과 에이전트형 작업의 강점이 두드러지는데요, 실제 답변 정확도는 별도 검증이 필요하겠지만 복잡한 업무 수행이 중요한 서비스에는 우선 검토해 볼 수 있는 근거가 될 수 있습니다.

모델별 외부 종합 지표를 비교하는 가로 막대 그래프. Qwen3.8-27B, Gemma 4 31B, Nemotron 3.5 세 모델의 지능, 코딩, 에이전트형 작업 성능을 0~100점 범위에서 평가 — 그림 1. 사내 발표자료에 수록된 OpenRouter 비교 화면의 범주별 점수. [5]

Qwen3.8-27B는 48개 게이트 델타넷과 16개 출력 게이트 전체 어텐션 레이어를 결합합니다. 모든 64개 레이어에는 Dense FFN이 포함되며, FP8 체크포인트도 BF16과 같은 구조를 쓰고 가중치 정밀도만 다릅니다. 아래 표와 그림에는 Qwen3.8-27B의 구조와 성능을 비교하기 위한 모델을 함께 정리했습니다. 이때 ‘표기 크기’는 모델의 파라미터 규모를 나타낸 것으로, 실제 실행에 필요한 전체 메모리와는 차이가 있습니다. 또한 입력 유형은 모델 자체의 지원 사양이며, 현재 Air API에서 제공하는 입력 범위와는 구분해서 봐야 합니다.

표에서 ‘서빙 베이스라인’으로 표시한 모델은 뒤에서 진행할 단일 GPU 실험에서 처리량의 상대적인 위치를 확인하기 위한 비교 기준으로만 활용했습니다. [3] [4] [7] [8]

모델	매개변수	가중치 형식·표기 크기	레이어·블록 구성	최대 문맥 길이	멀티모달 입력
Qwen3.8-27B-BF16	270억	16비트 부동소수점(BF16), 51.8 이진 기가바이트	64층: 48개 게이트 델타넷 + 16개 출력 게이트 전체 어텐션	256K 1M 확장	지원
Qwen3.8-27B-FP8	270억	8비트 부동소수점(FP8), 28.7 이진 기가바이트	BF16 버전과 동일	256K 1M 확장	지원
Nemotron 3.5 Lightning	300억 활성 30억	16비트 부동소수점(BF16), 61.3 이진 기가바이트	52블록: 23개 맘바2 + 23개 전문가 혼합 + 6개 전체 어텐션	1M	미지원
Gemma 4 31B (서빙 베이스라인)	310억	NVIDIA 4비트 부동소수점(NVFP4), 30.4 이진 기가바이트	60층: 50개 슬라이딩 윈도우 어텐션 + 10개 전체 어텐션	256K	지원

세 가지 LLM 모델(Nemotron 3.5 Lightning, Qwen3.8-27B, Gemma 4 31B)의 아키텍처 계층 구조를 시각화한 다이어그램. 각 레이어의 컴포넌트(M2, MoE, FA, GDN, SWA 등)를 색상으로 구분하여 표시 — 그림 2. Qwen3.8-27B의 언어 디코더 레이어 배치와 비교 모델의 구조를 함께 정리했습니다. 하단 범례는 각 색상의 블록 유형을 설명합니다. Qwen BF16과 FP8은 같은 구조를 사용하고 가중치 정밀도만 다르며, 그림의 L은 레이어 번호를 뜻합니다.

Qwen3.8-27B 실측 결과

이제 저희가 직접 측정한 결과로 넘어가겠습니다. 이번 테스트를 통해, 실제 서빙 시 처리량과 응답시간, 메모리 특성이 어떻게 달라지는지 확인해보았습니다. 아래 표는 벤치마크에 적용한 실험 조건으로, 각 실험에서는 비교 대상 외의 설정을 최대한 동일하게 유지했습니다.

구분	설정 및 측정 방식
하드웨어	NVIDIA RTX PRO 6000 96GB 1장
실험 대상	Air API 제공 모델: Qwen3.8-27B-BF16 양자화 비교: Qwen3.8-27B-FP8 서빙 베이스라인: Gemma 4-31B-IT-NVFP4
서빙 엔진	vLLM 0.27.1
가중치와 캐시	Qwen BF16: 16비트 가중치·캐시 Qwen FP8: 8비트 가중치·16비트 캐시 베이스라인: NVFP4 가중치·8비트 캐시
어텐션 실행 방식	Qwen 두 체크포인트는 같은 실행 경로를 사용하고 베이스라인은 다른 경로를 사용함
공통 조건	그래픽 메모리 사용 상한 90%, 합성 랜덤 요청, 난수 초기값 42, 요청을 한꺼번에 투입
문맥 길이 변화	최대 문맥 길이 2K~128K, max-num-batched-token 8K, 동시 32건, 총 64건
max-num-batched-token 변화	최대 문맥 길이 32K, max-num-batched-token 1K~32K, 동시 요청 16, 총 32개 요청
요청 구성	입력과 출력 토큰 비율 8:2, 실제 요청 길이는 설정한 최대 길이의 10~100% 범위

표의 max-num-batched-tokens는 vLLM이 한 번의 스케줄링에서 처리할 수 있는 최대 토큰 수를 의미합니다. 값을 높이면 더 많은 토큰을 한 번에 처리할 수 있지만, 메모리 사용량과 요청 지연시간도 함께 달라질 수 있습니다. 결과를 살펴보기 전에 몇 가지 참고할 점이 있습니다.

최대 문맥 길이를 늘린 실험에서는 실제 요청 길이도 함께 길어졌습니다.
'전체 토큰 처리량'은 실험 도구가 표기한 지표이며 생성 토큰만의 속도를 의미하지 않습니다.
여러 요청을 동시에 처리한 합성 부하 테스트이므로, 일반적인 채팅 환경의 응답시간이나 Air API의 성능 보장치와는 차이가 있을 수 있습니다.
Gemma 4는 Qwen 계열 모델과 가중치 및 캐시 정밀도, 어텐션 실행 경로가 다릅니다. 따라서 완전히 통제된 일대일 비교로 해석하지 않습니다.

실험 결과

핵심 결과 세 가지를 정리하면 다음과 같습니다.

문맥 길이를 늘릴수록 Qwen BF16과 베이스라인의 격차는 줄어들어 128K에서는 Qwen이 앞섭니다.
max-num-batched-token은 4K에서 32K까지 바꿔도 처리량이 초당 3,475~3,505토큰으로 거의 흔들리지 않는데, 이 구간에서는 Gemma 4보다 17~19% 낮습니다.
메모리는 문맥이 길어질수록 요청당 키-값 캐시가 커져서 동시에 받을 수 있는 요청 수가 빠르게 줄어듭니다.

실험 1. 최대 문맥 길이 2K에서 128K까지

먼저 문맥 길이를 바꿔가며 실험한 결과입니다. 최대 문맥 길이(max_model_len)를 2K에서 128K까지 바꾸면서 요청 처리량, 전체 토큰 처리량, 첫 토큰 응답시간, 토큰 간 시간과 종단간 지연을 측정했습니다. 이 실험은 최대 문맥 길이에 맞춰 실제 요청 길이 분포도 함께 길어지도록 구성했기 때문에, 응답시간 증가는 설정값과 요청 길이가 함께 반영된 결과입니다.

최대 문맥 길이별 단일 GPU 성능을 비교하는 2개의 꺾은선 그래프. 요청 처리량(요청/초)과 전체 토큰 처리량(토큰/초) 지표를 2K~128K 범위에서 세 모델 비교 — 그림 3. 최대 문맥 길이별 요청 처리량과 전체 토큰 처리량. 전체 토큰 처리량은 입력과 출력 토큰을 합친 값입니다.

최대 문맥 길이별 단일 GPU 성능을 나타내는 2개의 꺾은선 그래프. 평균 첫 토큰 응답시간(초)과 p99 첫 토큰 응답시간(초)을 2K~128K 범위에서 비교 — 그림 5. 최대 문맥 길이별 평균 토큰 간 시간과 평균 종단간 지연. 두 지표 모두 낮을수록 좋습니다.

Qwen BF16의 처리량 정점은 32K에서 초당 3,856토큰이고, Qwen FP8은 64K에서 초당 4,707토큰으로 가장 높습니다. Qwen FP8은 64K와 128K에서 세 체크포인트 중 가장 높은 처리량을 보입니다. Air API 제공 모델과 같은 Qwen BF16 체크포인트만 보면 서빙 베이스라인 대비 전체 토큰 처리량이 8K~32K에서 24.2~27.3% 낮고, 64K에서는 격차가 13⁠.⁠5⁠%로 줄어듭니다. 128K에서는 Qwen BF16이 오히려 7.3% 높습니다. 중간 문맥에서는 베이스라인이 앞서지만, 문맥이 길어질수록 차이가 줄고 가장 긴 실험 구간에서는 Qwen BF16이 앞섭니다. 128K에서 Qwen FP8은 BF16보다 처리량이 21.8% 높고, 평균 첫 토큰 응답시간은 약 25% 짧습니다. 평균 종단간 지연도 485초로 BF16의 554초보다 짧습니다. 반면 평균 토큰 간 시간은 Qwen BF16이 218밀리초로 FP8의 326밀리초보다 짧습니다. 첫 응답과 생성 진행 속도를 따로 봐야 하는 이유입니다.

실험 2. max-num-batched-token 1K에서 32K까지

다음 실험에서는 최대 문맥 길이를 32K, 동시 요청을 16개로 고정하고 max-num-batched-token을 1K~32K로 바꿨습니다. Gemma 4는 1K와 2K 설정에서 테스트가 실행되지 않았습니다. 해당 결과는 성능 측정값이 0이라는 의미가 아니라 이미지 토큰 전처리에 필요한 최소 조건을 충족하지 못해 체크포인트 로딩 단계에서 실행이 중단된 것입니다.

최대 문맥 길이별 단일 GPU 성능 비교. 평균 토큰 간 시간(밀리초)과 평균 중단간 지연(초)을 2K~128K 범위에서 세 모델 비교 — 그림 6. max-num-batched-token별 요청 처리량과 전체 토큰 처리량. Gemma 4의 1K·2K는 실행 불가 조건입니다.

max-num-batched-token별 성능 비교. 1K~32K 배치 토큰 범위에서 요청 처리량(요청/초)과 전체 토큰 처리량(토큰/초)을 세 모델로 비교한 꺾은선 그래프 — 그림 7. max-num-batched-token별 평균 및 p99 첫 토큰 응답시간.

max-num-batched-token별 성능을 나타내는 2개의 꺾은선 그래프. 평균 첫 토큰 응답시간(초)과 p99 첫 토큰 응답시간(초)을 1K~32K 배치 토큰 범위에서 비교 — 그림 8. max-num-batched-token별 평균 토큰 간 시간과 평균 종단간 지연.

Qwen BF16은 4K~32K에서 초당 3,475~3,505토큰으로 처리량 변화가 1% 이내입니다. Qwen FP8은 4K와 8K에서 BF16보다 각각 20.0%, 20.3% 높은 처리량을 보이지만, 16K와 32K에서는 각각 17.0%, 22.8% 낮습니다. 이번 환경에서 FP8을 사용할 때는 4K~8K부터 검토할 근거가 됩니다.

Qwen BF16은 4K~32K에서 서빙 베이스라인 처리량의 80.9~83.4% 수준을 유지합니다. 조건별 격차는 약 17~19%이지만, 두 체크포인트의 캐시 정밀도와 어텐션 실행 경로가 달라 이를 모델 구조만의 효과로 해석할 수는 없습니다. 따라서 베이스라인은 상대적 위치를 확인하는 참고값으로 봐야 합니다.

max-num-batched-token	Qwen BF16	Qwen FP8	Gemma 4
1K	3,204 / 25.0초	3,911 / 20.0초	N/A(실행 불가)
2K	3,284 / 24.9초	4,057 / 15.4초	N/A(실행 불가)
4K	3,502 / 14.9초	4,202 / 12.6초	4,331 / 10.9초
8K	3,477 / 15.6초	4,182 / 13.9초	4,253 / 12.6초
16K	3,475 / 17.3초	2,883 / 23.8초	4,221 / 11.9초
32K	3,505 / 18.9초	2,705 / 31.7초	4,205 / 12.3초

[ 표. max-num-batched-tokens 설정별 '전체 토큰 처리량' / '평균 첫 토큰 응답시간' ]

실험 3. 키-값 캐시 여유

Qwen3.8-27B-BF16의 메모리 측정에서는 가용 키-값 캐시, 키-값 캐시에 담을 수 있는 토큰 수, 최대 길이 요청의 이론상 동시 수용량과 요청당 캐시를 함께 계산했습니다. 동시 수용량은 캐시 토큰 수를 설정한 최대 문맥 길이로 나눈 산술값이며, 실제 서비스 동시 요청 수나 성능 보장치가 아닙니다.

측정 결과, 가용 키-값 캐시는 31.25~31.37GiB로 거의 일정했습니다. 반면 요청당 필요한 캐시 용량은 문맥 길이가 2K일 때 0.43GiB에서 128K일 때 8.33GiB, 256K일 때 16.33GiB까지 증가했습니다. 이론상 동시 수용량은 72.78개에서 1⁠.⁠9⁠2⁠개로 97.4% 줄어들었습니다. 즉, 긴 문맥을 지원하는 것과 여러 개의 긴 요청을 동시에 처리하는 것은 별개의 운영 과제입니다.

max-num-batched-token별 성능을 나타내는 2개의 꺾은선 그래프. 평균 토큰 간 시간(밀리초)과 평균 중단간 지연(초)을 1K~32K 배치 토큰 범위에서 비교 — 그림 9. Qwen3.8-27B-BF16의 메모리 요약. 왼쪽은 최대 문맥 길이에 따른 총 키-값 캐시 토큰 수와 최대 길이 요청의 이론상 동시 수용량, 오른쪽은 가용 키-값 캐시 메모리입니다.

최대 문맥 길이 (max_model_len)	가용 키-값 캐시 (GiB)	키-값 캐시 토큰 수	이론상 동시 수용량	요청당 키-값 캐시 (GiB)
2K	31.35	149,048	72.78	0.43
4K	31.35	223,573	54.58	0.57
8K	31.35	315,632	38.53	0.81
16K	31.37	397,463	24.26	1.29
32K	31.35	447,146	13.65	2.30
64K	31.37	476,956	7.28	4.31
128K	31.25	491,896	3.75	8.33
256K	31.35	503,531	1.92	16.33

[표 4. 최대 문맥 길이 기준. Qwen3.8-27B-BF16에서 max-num-batched-token은 8K, 최대 동시 시퀀스는 256으로 고정했습니다. 256K는 메모리 수용량만 확인했으며 성능 실험 범위에는 포함하지 않았습니다. ]

max-num-batched-token	가용 키-값 캐시 (GiB)	키-값 캐시 토큰 수	이론상 동시 수용량	요청당 키-값 캐시 (GiB)
1K	31.43	447,829	13.67	2.299
2K	31.39	447,146	13.65	2.300
4K	31.37	447,146	13.65	2.298
8K	31.35	447,146	13.65	2.297
16K	30.13	429,397	13.10	2.300
32K	27.10	386,389	11.79	2.299

[ 표 5. max-num-batched-token 기준. Qwen3.8-27B-BF16에서 최대 문맥 길이는 32K, 최대 동시 시퀀스는 256으로 고정했습니다. ]

이번 실험에서 사용 가능한 KV 캐시 용량은 max-num-batched-tokens가 1K~8K일 때 약 31.4GiB로 거의 일정했습니다. 반면 8K에서 32K로 높이자 가용 캐시는 31.35GiB에서 27.10GiB로 13.6% 감소했고, 이론상 동시 수용량도 13.65개에서 11.79개로 줄었습니다. 최대 문맥 길이를 32K로 고정했기 때문에 요청당 필요한 캐시 용량은 약 2.30GiB로 일정하게 유지됐습니다. 따라서 max-num-batched-token는 처리량만 보고 높이기보다, KV 캐시 여유와 동시 처리 가능 요청 수까지 함께 고려해 설정해야 합니다.

BF16과 FP8 비교

양자화 효과는 구조가 같은 Qwen3.8-27B-BF16과 Qwen3.8-27B-FP8만 떼어 비교합니다. 두 체크포인트는 270억 매개변수와 64층 레이어 구성, 어텐션 실행 경로가 같습니다. 가중치 정밀도는 BF16 버전이 16비트, FP8 버전이 8비트이며, FP8 버전의 키-값 캐시는 16비트입니다. 여기서 성능은 처리량과 응답시간을 뜻하며, 답변 품질 차이는 이 실험의 측정 대상이 아닙니다.

FP8 체크포인트의 모델 가중치 표기 크기는 BF16의 51.8GiB 대비 28.7GiB로 44.6% 작습니다. 일곱 문맥 길이의 단순 평균 처리량은 BF16의 초당 약 2,935토큰보다 FP8이 약 3,708토큰으로 26.3% 높습니다. 가중치 크기는 거의 절반으로 줄지만 평균 처리량 증가는 약 4분의 1에 그쳐, 크기 감소만큼 극적이지는 않습니다. 문맥 길이별 처리량 증가율도 17.2~53.7%로 차이가 큽니다. 이 크기는 가중치만 뜻하며, 키-값 캐시와 서빙 엔진 메모리를 포함한 전체 그래픽 메모리 사용량은 아닙니다.

FP8 처리량은 64K에서 초당 4,707토큰으로 가장 높습니다. 128K의 평균 첫 토큰 응답시간은 약 350⁠초로 BF16의 약 467초보다 25% 짧습니다. 반면 max-num-batched-token이 16K와 32K인 조건에서는 BF16보다 느립니다.

마무리

세 실험을 겹쳐 보면 설정값이 서로 맞물려 있습니다. max-num-batched-token은 4K에서 첫 토큰 응답시간이 14.9초로 가장 짧고, 그 위로 올려도 처리량은 1% 안에서만 움직이면서 가용 캐시는 31.35GiB에서 27.10GiB로 줄어듭니다. 최대 문맥 길이는 32K를 넘기면 처리량이 포화되는데 요청당 캐시는 계속 커집니다. 긴 문맥을 열어둘지 동시 요청을 많이 받을지, 한쪽을 고르는 문제입니다. Gemma 4와의 격차는 우열을 가리는 값이 아닙니다. 캐시 정밀도와 어텐션 실행 경로가 달라 조건이 통제되지 않았기 때문에, 이 숫자는 Qwen이 그만큼 느리다는 뜻이 아니라 처리량이 대략 어느 자리에 있는지 가늠하는 눈금입니다. 2장에서 본 공개 지표도 품질 쪽 값이라 처리량과 나란히 놓을 수 없습니다. 그래서 검증 순서는 서비스 성격이 정합니다. 답변 품질과 여러 단계에 걸친 작업이 중요하면 Qwen3.8-27B를 실제 업무 데이터로 먼저 돌려보는 편이 빠릅니다. 중간 길이 요청의 처리량과 첫 응답시간이 우선이라면 베이스라인 결과를 같이 봐야 합니다. 모든 조건에서 가장 빠른 모델은 아니지만, 실무에서 쓰는 구간에서 처리량이 흔들리지 않고 긴 문맥에서는 오히려 앞선다는 것이 이번 측정의 결론입니다. 이런 설정을 직접 만지지 않고 모델부터 확인하고 싶다면 Air API에서 바로 호출해볼 수 있습니다.

Air API에서는 별도의 GPU 서버와 서빙 엔진을 준비하지 않고 Qwen3.8을 애플리케이션에 연결할 수 있습니다. OpenAI API와 호환되는 호출 형식을 지원하므로 기존 연동 코드가 있다면 접속 주소와 인증키를 바꾸는 방식으로 시작할 수 있고, Playground에서 프롬프트와 응답을 먼저 확인한 뒤 제품에 적용할 수 있습니다.