Gemma 4와 Qwen 3.8, 긴 기록 검색은 둘 다 맞히고 주문 계산은 둘 다 틀렸다

크기는 비슷하고 긴 입력을 다루는 구조는 다르다

구글 모델 카드에 따르면 Gemma 4 31B는 약 307억 파라미터의 밀집 모델이다. 로컬 어텐션과 글로벌 어텐션을 섞는 구조이며 공식 문서는 최대 256K 컨텍스트를 제시한다.

Qwen 3.8 27B도 밀집 모델이다. 64개 층에서 Gated DeltaNet 세 층과 Gated Attention 한 층을 묶어 반복하는 하이브리드 구조를 쓴다. 공식 모델 카드는 262,144토큰의 네이티브 컨텍스트와 thinking 모드의 켜고 끄기를 명시한다. Gated DeltaNet은 선형 어텐션 계열이라 긴 입력을 처리하는 경로가 Gemma와 다르다. 파일 크기가 비슷해도 긴 문서를 읽는 속도와 실패하는 방식은 달라질 수 있다는 뜻이다.

양자화는 두 모델 모두 Q4_K_M으로 맞췄다. 구글이 직접 배포하는 Gemma 4 31B의 QAT GGUF는 Q4_0이어서 같은 형식으로 비교하려면 공개 변환본을 써야 했다. Gemma는 Unsloth가, Qwen은 ggml-org가 원 제작사의 체크포인트를 변환한 파일이다. 이번 결과에는 이 변환 품질까지 들어 있으므로 원본 BF16 모델끼리의 품질 순위로 읽을 수 없다.

자료: Gemma 4 개요 문서 · ai.google.dev · Gemma 4 31B 모델 카드 · huggingface.co · Google 공식 Gemma 4 31B QAT Q4_0 GGUF · huggingface.co · Qwen 3.8 27B 모델 카드 · huggingface.co · Unsloth의 Gemma 4 31B GGUF 변환본 · huggingface.co · ggml-org의 Qwen 3.8 27B GGUF 변환본 · huggingface.co

읽는 속도와 쓰는 속도는 따로 움직였다

순수 처리 속도는 llama.cpp에 들어 있는 llama-bench로 쟀다. 입력 512·4,096·16,384토큰을 처리하는 속도와 128토큰을 생성하는 속도를 모델마다 5회씩 측정해 평균과 표준편차를 남겼다.

입력 처리에서는 Qwen이 줄곧 앞섰다. 512토큰에서 11.2%이던 차이가 4,096토큰에서 18.9%, 16,384토큰에서 32.0%로 벌어졌다. Gemma는 입력이 길어질수록 초당 759토큰에서 631토큰으로 내려갔고 Qwen은 833~875토큰 사이에 머물렀다.

생성 속도는 거의 붙어 있었다. 128토큰 생성에서 Gemma는 초당 11.080토큰, Qwen은 11.370토큰이었다. 다섯 번 사이의 표준편차가 0.005토큰에 못 미치니 2.6%의 차이 자체는 흔들림보다 크다. 그래도 짧은 답을 주고받는 채팅이라면 체감 차이는 작을 수 있다.

업무형 과제 12건의 응답 시간 중앙값은 Gemma 16.224초, Qwen 12.876초였다. 입력이 가장 긴 검색 과제에서는 43.525초와 29.496초로 Qwen이 32.2% 짧았다. 토크나이저가 달라 같은 글을 넣어도 Gemma 쪽 입력 토큰이 5~6% 많았다. 실제 대기시간에는 초당 처리량 차이에 이 토큰 수 차이가 겹친다.

Qwen의 선형 어텐션 계열 구조가 긴 입력에 유리했을 가능성과 맞는 결과다. 다만 장비 한 대와 실행기 커밋 하나로 구조가 원인이라고 단정할 수는 없다. 수만 토큰의 코드나 문서를 반복해서 넣는 용도라면 생성 속도표보다 입력 길이별 처리 속도를 봐야 한다.

자료: llama.cpp 저장소 · github.com

합성 과제 12건에서 맞힌 것과 틀린 것

정확도는 개인 문서 대신 스크립트가 만든 합성 데이터로 쟀다. 정답이 데이터와 함께 생성되므로 채점도 자동으로 할 수 있다. 과제는 세 종류, 종류마다 4건씩이다.

로그 집계에는 작업 ID, 상태, 지연시간, 위험 표시가 한 줄씩 적힌 80·180·320·520줄 로그를 넣었다. 요구한 답은 상태 네 가지의 건수와 위험 표시가 붙은 ID 목록, 최대 지연 ID와 그 값이다. 희소 값 검색은 120~620줄의 잡음 기록 가운데 처음과 4분의 1, 절반, 4분의 3, 끝 근처에 숨긴 키 다섯 개의 값을 순서대로 돌려받는 과제다. 주문 계산은 품목 네 줄의 단가와 수량으로 소계를 낸 뒤 8~11% 할인을 소수점 버림하고 배송비 규칙을 적용해 총액을 구하게 했다.

모든 과제에서 설명이나 Markdown 없이 JSON 객체 하나만 내라고 지시했다. 채점표에는 JSON 파싱 성공, 키 순서, 부연 없음, 값 완전 일치를 따로 기록했다.

값까지 완전히 맞은 답은 Gemma 4건, Qwen 6건이었다. 검색은 두 모델이 4건 모두 맞혔다. 로그 집계는 Gemma 0건이었고 Qwen은 80줄과 180줄 두 건만 맞혔다. 주문 계산은 둘 다 0건이었다.

형식은 Qwen이 12건 모두 지켰다. Gemma는 검색과 계산 8건에서 JSON만 냈지만 로그 집계 4건에는 Markdown 코드 블록 기호를 붙였다. 응답을 그대로 JSON으로 파싱하는 자동화라면 이것만으로 실패한다. 거꾸로 JSON이 잘 파싱됐다고 값이 맞은 것도 아니었다. 주문 계산 8건은 전부 형식을 지킨 오답이었다.

위험 ID는 찾았고 상태별 건수는 틀렸다

틀린 로그 집계 6건의 원답을 열어 보면 오류가 한곳에 몰려 있다. 위험 표시 ID 목록과 최대 지연 ID, 최대 지연값은 6건 모두 정답과 같았다. 어긋난 것은 상태별 건수뿐이었다.

Gemma는 80줄 로그에서 상태마다 20건인 것을 15건으로 셌다. 320줄에서는 80건을 63건으로, 520줄에서는 130건을 103~104건으로 답했다. 네 번 모두 정답의 75~80% 수준이었다. Qwen은 80줄과 180줄을 정확히 셌고 320줄에서 80건을 75건으로, 520줄에서 130건을 127~128건으로 답했다. 틀린 답은 두 모델 모두 실제보다 적게 센 쪽이었다.

컨텍스트 한도에 걸린 것도 아니다. 가장 긴 520줄 로그도 1만1천 토큰 안팎이라 설정한 32,768토큰 창의 3분의 1 정도였다.

눈에 띄는 드문 항목을 찾아 옮기는 일과 반복되는 모든 행을 빠짐없이 세는 일은 사람이 보기에 같은 문서 읽기다. 두 모델에게는 다른 과제였던 셈이다. 공식 자료의 256K와 262K는 그만큼의 입력을 받을 수 있다는 수치다. 그 안의 모든 행을 정확히 집계한다는 보증으로 읽을 근거는 이번 결과에 없다.

네 줄짜리 주문서에서 틀린 곳은 소계였다

주문 계산은 입력이 150토큰 안팎으로 짧다. 첫 주문의 정답 소계는 2,546인데 Gemma는 2,534, Qwen은 2,540이라고 답했다. 세 번째 주문에서는 정답 4,150을 두 모델이 각각 3,454와 3,450으로 냈다.

오답 8건의 할인액과 총액은 모델이 스스로 낸 소계를 기준으로 계산하면 모두 규칙대로 맞는다. 할인율 적용과 소수점 버림, 배송비 판단은 해냈다는 뜻이다. 틀린 곳은 단가와 수량을 곱해 더하는 단계였다. 틀린 숫자가 형식이 맞는 JSON 안에 자연스럽게 들어 있으니 눈으로 훑어서 잡아내기는 어렵다.

JSON 강제는 형식만 고쳤고 thinking은 시간과 예산을 요구했다

기본 비교가 끝난 뒤 실패 원인을 가르려고 두 가지 옵션을 따로 시험했다. 이 결과는 12건 점수에 더하지 않았다.

Gemma에는 응답을 JSON 객체로 강제하는 response_format 옵션을 걸고 80줄 집계와 첫 주문 계산을 다시 냈다. 코드 블록 기호가 사라져 파싱은 성공했다. 값은 여전히 틀렸다. 80줄 집계는 이번에도 상태마다 15건이었고 첫 주문 소계는 2,544였다. 문법 제약이 고친 것은 형식이었다.

Qwen에는 thinking 모드를 켜고 기본 모드에서 틀린 5건을 출력 512토큰 한도 안에서 다시 풀게 했다. 320줄 집계 1건과 주문 계산 4건이다. 주문 2번과 3번은 정답이 됐다. 대신 39.786초와 38.197초가 걸렸다. 기본 모드에서 같은 주문에 4초 남짓 걸렸으니 9~10배를 기다린 셈이다.

주문 1번과 4번은 추론 과정에서 소계와 할인액, 총액을 모두 맞게 계산했다. 최종 JSON을 쓰는 도중에 512토큰 한도에 닿아 1번은 답이 중간에 끊겼고 4번은 최종 답이 비었다. 320줄 집계는 53.645초 동안 로그를 한 줄씩 옮겨 적다가 한도를 다 쓰고 답을 내지 못했다.

thinking을 켜는 순간 바뀌는 것은 정답률만이 아니다. 대기시간과 출력 토큰 사용량, 최종 답에 남겨야 할 예산이 같이 움직인다. 예산을 짧게 잡으면 정답을 계산하고도 전달하지 못한다. 512토큰보다 큰 예산은 이번에 시험하지 않았다. 예산을 늘렸을 때 정답률이 얼마나 오를지는 이 결과로 알 수 없다.

모델에 맡길 일과 코드에 맡길 일

이 결과를 자동화 설계로 옮기면 역할이 나뉜다. 모델은 사용자의 질문을 구조화한다. 어떤 상태를 세야 하는지, 어떤 기간과 필터가 필요한지 해석하고 긴 문서에서 근거 후보를 찾아 설명한다.

건수와 금액은 모델에게 세게 하지 않는다. 로그는 Python이나 SQL로 파싱하고 금액은 정수 연산이나 스프레드시트 수식으로 계산한다. 모델이 낸 답은 JSON 스키마로 키와 타입을 고정한 다음 합계가 부분값의 합과 같은지, 할인 뒤 총액이 식과 맞는지 같은 불변식으로 다시 검사한다. 형식이 맞아도 값 검증을 통과하지 못한 응답은 사용자에게 넘기지 않는다.

thinking 모드나 더 큰 모델은 검증에 실패한 요청을 재시도할 때만 쓴다. 이때 추론 토큰과 최종 JSON 토큰을 따로 어림해 출력 예산을 잡고 타임아웃도 기본 요청과 분리한다.

모델 하나를 고른다면 이번 조건에서는 Qwen 3.8 27B가 긴 문서 검색과 자동화의 출발점으로 유리했다. 16K 입력 처리가 32% 빨랐고 기본 모드의 12개 응답이 모두 JSON 형식을 지켰으며 작은 로그 두 건을 더 맞혔다. 짧은 채팅이 중심이라면 생성 속도가 초당 11토큰대로 같아 차이가 작다. 말투와 한국어 품질, 라이선스, 도구 생태계는 이번에 비교하지 않았다. 정확한 계산이 필요한 리포트 자동화라면 두 모델 중 어느 쪽도 단독으로 맡길 수 없었다.

이번에 어떻게 측정했나

측정은 2026년 9월 4일 밤(한국시간) NVIDIA GB10 장비 한 대에서 했다. 운영체제가 보고한 통합 메모리는 121GiB, GPU의 compute capability는 12.1이다. 실행기는 그날 최신이던 llama.cpp 커밋 64a155d242cb427766055ea9caea6f34df1ca94b를 CUDA로 따로 빌드했다. 두 모델은 같은 설정으로 한 번에 하나씩 띄웠다.

공통 설정은 Q4_K_M, GPU 레이어 전부 적재, Flash Attention, K·V 캐시 q8_0, 컨텍스트 32,768, 배치 4,096과 마이크로배치 2,048, 스레드 8, 병렬 슬롯 1이다. 기본 비교에서는 thinking과 MTP(멀티 토큰 예측)를 껐다. 과제 요청은 temperature 0, top_p 1, 고정 시드, 최대 출력 512토큰으로 보냈다. 속도는 조건마다 5회 반복했고 정확도 과제 12건은 각 1회만 실행했다. 모델 파일의 SHA-256과 원시 응답, 서버 로그를 모두 보존했다.

같은 장비에는 다른 Qwen 3.6 서버가 떠 있었다. 측정 중에는 유휴 상태였다고 전제했을 뿐 완전히 격리한 벤치마크는 아니다. 그러니 절대 속도보다는 같은 시간대에 잰 두 모델의 상대 차이와 실패 모양을 중심으로 읽기를 권한다. 멀티모달 입력과 MTP, 에이전트 도구 실행은 이번 범위 밖이다.

자료: llama.cpp 저장소 · github.com