GB10 Qwen3.8‑27B 3주, 3.4배 느려도 남긴 이유
GB10 한 대에 Qwen3.8-27B를 사내 챗봇의 선택 모델로 3주째 운영하고 있습니다. 공개 지능 지표는 같은 기계의 기본 모델 Gemma-4-26B의 두 배(52 대 26)인데, 한국어 산문은 14~15 tok/s로 그 기본 모델(51.5)보다 3.4배 느렸습니다. 속도를 올리려 한 시도는 MTP 깊이 하나만 빼고 전부 실패했습니다.
한 줄 결론
속도 목표는 실패했습니다. 기본 모델이 여전히 3.4배 빠른데도 계속 선택 모델로 두는 것은, 분석이나 설계 검토처럼 느려도 좋은 질문에서 두 배 지능이 값어치를 하기 때문입니다.
정정 (2026년 10월 3일): 원래 vLLM 배포처 문서가 MTP 깊이로 2를 권한다고 썼으나, 문서의 기본값은 3이고 2는 처음 운영에 쓴 값이어서 고쳤습니다. 측정값 가운데 k=2를 "가장 나빴다"고 한 표현도 k=5가 더 느려 "3이 가장 빨랐다"로 바로잡았습니다.
사내 챗봇의 기본 모델은 Gemma 4 26B인데, 8월 중순에 나온 Qwen3.8-27B는 공개 지능 지표가 그 정확히 두 배였습니다(52 대 26). 같은 27B급이고 GB10 한 대에 들어가니 질문은 하나였습니다 — 30 tok/s를 유지하면서 더 똑똑한 모델이 있는가. 한국어에서는 없었습니다. 가능한 조합을 전부 열어본 뒤 최고치가 13.5 tok/s였고, 조합을 견주려고 고정해 둔 같은 에서 Gemma는 44.3이 나오니 3.3배 차이입니다.
그래서 교체하지 않고 두 번째 선택지로 붙여 3주째 운영 중입니다. GB10 한 대로 사내 챗봇을 운영하신다면 이 모델을 기본으로 올리는 것은 권하지 않고, 분석이나 설계 검토처럼 느려도 좋은 질문용으로 두시는 편이 낫습니다. 아래 수치는 전부 그 기계 한 대에서 직접 확인한 것이고, 성공보다 실패가 훨씬 많습니다. 비교 기준으로 계속 나오는 기본 모델 Gemma-4-26B는 같은 기계에서 넉 달 동안 운영한 기록으로 따로 리뷰했습니다.
k=3 MTP에 KV 8 GiB, 작은 몫으로 붙였다
모델은 서드파티 4비트 판 unsloth/Qwen3.8-27B-NVFP4입니다(공식 배포는 과 뿐). 엔진은 0.27.1 스톡 arm64이고, 드래프트는 체크포인트에 들어 있는 head를 k=3으로 씁니다.
--max-model-len 65536--max-num-seqs 4--max-num-batched-tokens 8192--gpu-memory-utilization 0.40--kv-cache-memory-bytes 8589934592(8 GiB)--reasoning-parser qwen3--enable-auto-tool-choice --tool-call-parser qwen3_coder--default-chat-template-kwargs '{"reasoning_effort":"medium"}'--override-generation-config '{"top_p":0.8}'--speculative-config '{"method":"mtp","num_speculative_tokens":3}'
기본 모델보다 몫이 작은데 일부러 그렇게 줬습니다. 같은 기계에서 GPU를 나눠 쓰고 선택 모델이라 동시 사용자가 1~2명이기 때문인데, 이 결정이 뒤에 계속 등장합니다.
한국어 산문은 14~15 tok/s, 기본 모델보다 3.4배 느리다
한국어 산문 답변 한 건(약 1,200)이 78~87초, 14~15 tok/s입니다. 같은 기계의 기본 모델은 같은 한국어 산문에서 51.5라 3.4배 차이입니다. 첫 글자까지는 0.36초, 순수 는 256토큰 고정에서 22.0이고 1,024토큰 고정에서 17.0, 동시 4건이면 합계 57.1이 나옵니다. 수용률(acceptance rate) 60.1%에 수용 길이(acceptance length) 2.80.
측정 길이에 따라 값이 크게 달라진다는 점은 강조하고 싶습니다. 256토큰에서 22.0인데 실제 답변에서는 14대까지 내려가는 것은 컨텍스트가 쌓이면서 이 커지기 때문이고, 공개 벤치가 흔히 쓰는 128 in / 128 out은 이 구간을 보여주지 않습니다.
이긴 것은 MTP 깊이 하나뿐이었다
배포처 문서는 한 번에 던질 수의 기본값을 3으로 두는데, 처음에는 2로 운영했습니다. 다 측정했더니 한국어 산문에서 k=2가 12.61, k=3이 13.45, k=5가 11.78로 3이 가장 빨랐습니다.
직관과 반대라 재미있는 대목이 여기 있습니다. k=2는 수용률이 가장 높은데(산문 53.7%, k=3은 43.2%) 정작 속도는 느립니다. 두 개를 던져 잘 맞혀도 한 스텝에 최대 3토큰만 확정하는 반면, k=3은 덜 맞히는 대신 스텝당 기대 확정 토큰이 2.30으로 더 크기 때문입니다. 속도를 정하는 것은 수용률이 아니라 길이였습니다.
코드와 수학은 k=5가 낫고 산문은 k=3이라, 내용이 섞이는 실사용에서는 k=3으로 뒀습니다. 영어로 측정한 외부 결과에서는 k=5가 k=3보다 빨랐으니, 최적 깊이가 언어에 따라 뒤집히는 셈입니다.
도구 호출·사고 모드·메시지 위치가 조용히 실패했다
3주에서 실무에 제일 쓸모 있는 소득이 여기입니다. 전부 예외 없이 조용히 실패하는 종류라, 벤치로는 안 걸리고 사용자 보고로 발견됐을 것들입니다.
도구 호출부터. --enable-auto-tool-choice와 --tool-call-parser를 빼면 tools를 실은 요청이 전부 400입니다. tool_choice: "none"으로 우회하면 더 나쁜데, 모델이 호출 구문을 본문 텍스트로 출력하고 tool_calls는 빈 배열이라 부르는 쪽이 실패를 알아채기 어렵습니다. 화면 채팅은 도구를 안 쓰지만 사내 다른 앱이 같은 엔드포인트를 쓰고 있어서, 붙인 지 이틀 뒤 그쪽 400으로 알았습니다.
두 번째는 사고 모드입니다. 이 체크포인트는 기본값이 최고라 서버 기본을 중간으로 낮췄는데, 진짜 문제는 따로 있었습니다. 대화 제목 생성(40)이나 의도 분류(100토큰)처럼 예산이 작은 호출은 사고가 그 예산을 다 쓰고 본문이 빈 채로 끝나서, 제목 생성이 6회 중 6회, 의도 분류가 5회 중 4회 실패했습니다. 정상 응답으로 끝나니 부르는 쪽은 조용히 폴백으로 빠지고, 증상은 제목이 요약 대신 첫 문장으로 나오는 것뿐입니다. 짧은 호출에는 사고를 끄도록 명시해 막았습니다.
세 번째는 위치. 이 모델은 맨 앞이 아닌 system 메시지를 400으로 거부하는데(System message must be at the beginning.) 기본 모델은 받아줍니다. 대화 중간에 지침을 끼워 넣는 코드가 있어서 모델을 바꾼 사용자만 실패했고, 보내기 직전에 인접 user 메시지 안으로 접어 넣어 정리했습니다.
샘플링 프리셋도 섞여 있었습니다. 한국어 답변에 중국어·일본어 낱말이 끼어든다는 보고(사실陈述입니다 같은 식)를 쫓다 보니 비사고 온도에 사고 쪽 top_p를 물려 쓰고 있었는데, 프리셋을 맞춰 놓긴 했지만 이걸 고쳐서 나아졌다는 실측은 아직 못 냈습니다.
가장 아까운 실패는 DFlash2였다
블록 확산 방식의 새 드래프터 DFlash2가 나왔습니다. 한 번의 forward로 블록 전체를 뽑고 위치마다 후보를 남긴 뒤 경로 하나를 고르는 방식인데, GB10 2대를 묶은 구성에서 대비 +43%라는 실측이 공개돼 있었습니다. 이 방식은 (quantization)된 출력 head를 하드 거부해서, 그 층만 되돌린 판을 직접 만들어 붙였습니다.
결과는 −22%. 체감 e2e가 15.3에서 11.9 tok/s로 내려갔고 수용률은 60.1%에서 29.1%로 반토막이 났습니다. 수용 길이는 3.03으로 더 긴데 그걸 얻으려고 2.2배를 던져서, 1,806개 중 525개만 붙었습니다.
원인은 k=5가 k=3보다 나빴던 것과 같습니다. 이 방식을 소개한 벤치들을 다시 봤더니 전부 코딩 작업이었는데, 코드는 다음 이 문법으로 거의 정해져서 일곱 개를 던지면 일곱 개가 붙습니다. 한 커뮤니티 실측의 작업별 분해가 그대로 보여줍니다 — 코드 32~40, 수학 41~44, 자유 산문(영·불·독) 17~22. 그 목록에 한국어는 없습니다. 예측이 어려운 텍스트일수록 깊게 던질수록 버려지는 연산이 커지는데, K는 줄일 수도 없습니다. 엔진이 블록 크기를 1 + K로 잡고 드래프트가 블록 8로 훈련됐기 때문입니다.
KV를 3배로 늘렸더니 이웃 모델이 3할 느려졌다
마지막 시도는 KV를 8에서 24 GiB로, 슬롯을 4에서 16으로 올리는 것이었고 이쪽은 의도대로 됐습니다. 단독 속도는 14.2 tok/s로 소수점까지 같았고 동시 8건 합계 104.4, 16건 158.4까지 받았습니다. 할당은 속도를 정하지 않고 자리만 정합니다.
그런데 놀고 있던 기본 모델이 같이 느려졌습니다. −34%, 동시 처리 −31%. GB10은 통합 메모리라 프리필의 큰 임시 버퍼가 호스트 여유와 같은 풀에서 나오는데, 호스트 가용이 30에서 14 GiB로 줄자 그쪽만 눌렸습니다. 2회 재현되고 되돌리니 복구됐습니다. 가끔 쓰는 모델이 8명을 동시에 받는 대신 모두가 쓰는 모델이 3할 느려지는 거래라, 되돌렸습니다.
prefix caching·CUDA graph·대안 엔진은 전부 되돌렸다
은 켜면 당연히 이득일 줄 알았는데 queries 4,103에 hits 0. 하이브리드 모델이라 엔진이 특정 캐시 모드를 강제하는데 그 모드에 미수정 버그가 있고, 다른 모드는 엔진이 기동을 거부합니다. 이득이 0인데 블록 때문에 KV만 5% 줄어서 되돌렸습니다.
CUDA graph를 완전 모드로 세우는 것 자체는 성공했습니다. 완전 모드를 세우려면 어텐션 백엔드를 바꿔야 하는데 그 대가가 더 커서, 가 21.0에서 14.3으로 32% 느려졌습니다. DFlash2 구성에서 완전 모드가 저절로 잡혔을 때도 느렸으니 등급이 우리 병목은 아니었다는 뜻입니다. 선형 어텐션 플래그 두 개는 로그에 requested=auto로 찍혀 있었는데, 다른 종류의 믹서용이라 에러 없이 무시된 것이었습니다. 대안 엔진은 34~38 tok/s라는 보고가 많았지만 한국어 산문에서 7.97이 나왔고, 엔진 최신 버전은 짧은 디코드만 미세하게 나아서 되돌렸습니다. 다만 새 버전부터 이 계열의 prefix caching이 기본 켜짐으로 뒤집히기 때문에, 끈 상태를 플래그로 명시해 뒀습니다.
사고도 한 번 있었습니다. 재기동 전에 페이지 캐시를 비우면서 컨테이너를 띄운 채로 비웠더니, 내렸을 때 62GiB가 잡히는 자리에서 20GiB만 잡혔습니다. 여유가 모자란 채로 재생성이 실행됐고, 새 컨테이너가 메모리 게이트에 걸려 10시간 내려가 있었습니다. 선택 모델이라 기본 채팅은 살아 있었던 게 다행이었습니다. 컨테이너를 먼저 내리고 그다음 캐시를 비운다고 순서를 문서에 적어뒀습니다.
속도는 못 올렸습니다. 13.5에서 시작해 지금 14~15이고, 이긴 것은 깊이 하나뿐인데 그건 첫 주에 끝났습니다. 나머지는 전부 무효이거나 손해. 그러면 3주가 헛됐을까요?
그렇게 보지 않는 이유가 셋입니다. 첫째로 왜 남의 수치와 다른지를 알게 됐는데, 작업 종류와 측정 길이 두 가지라 이제 공개 벤치에서 그 둘만 확인하면 우리에게 해당하는지 바로 압니다. 같은 엔진·같은 방식으로 남이 측정한 값이 20.89이고 256 고정에서 우리 값이 22.0이라, 조건은 달라도 자릿수가 같다는 것으로 우리 설정이 크게 잘못되진 않았다는 확인은 됐습니다. 둘째로 깨질 수 있는 자리를 사용자보다 먼저 밟았습니다. 셋째로 통합 메모리에서는 이웃의 임시 버퍼 자리까지 계산해야 하고 (speculative decoding)의 이득은 텍스트의 예측 가능성에 정확히 비례한다는 것을 배웠는데, 모델이나 엔진을 바꿔도 안 변하는 성질이라 앞으로의 판단 기준이 됩니다.
속도로 이기려는 시도는 당분간 접습니다. 다시 열 조건은 셋 중 하나. 한국어로 검증된 드래프터가 나오거나, 이 계열의 prefix caching 버그가 고쳐지거나, 기계를 한 대 더 놓거나.
그래도 이 모델은 계속 선택지로 둡니다. 느려도 좋은 질문 — 분석, 설계 검토, 코드 — 에서는 지능 차이가 값어치를 하기 때문입니다.
3.2 / 5.0
좋았던 점
- 공개 지능 지표가 기본 모델의 두 배(52 대 26)라 분석·설계 검토·코드 질문에서 값어치를 합니다
- MTP 깊이를 처음 쓰던 2에서 3으로 올리자 한국어 산문이 12.61에서 13.45 tok/s로 올랐습니다
- 본문 첫 글자까지 0.36초라 응답이 시작되는 감각은 빠릅니다
- KV 8 GiB에 슬롯 4라는 작은 몫으로도 선택 모델 트래픽을 감당해 기본 모델과 한 대에 공존합니다
아쉬운 점
- 한국어 산문이 14~15 tok/s로 같은 기계의 기본 모델보다 3.4배 느리고 답 하나에 출력 토큰도 더 씁니다
- 이 계열은 하이브리드 어텐션이라 4천여 건을 측정하는 동안 prefix caching 히트가 0이었고, vLLM 쪽 미해결 버그라 설정으로 피할 수 없습니다
- 별도 드래프터를 붙인 DFlash2는 GB10 2대를 묶은 외부 실측에서는 MTP 대비 +43%인데 우리 1대·한국어 산문에서는 22% 손해였습니다
- 사고 모드가 기본으로 켜져 있어 짧은 내부 호출의 토큰 예산을 먹고 빈 응답을 내는데 예외가 안 납니다
테스트: 자체 호스팅(요금제 없음) · 3주, 계속 운영 중 · 2026년 8월 15일 시작 · 여러 가지를 시도해 이긴 것은 MTP 깊이 하나뿐이고 그것도 첫 주에 끝났습니다.
