최신 30B급 dense 모델 Qwen3.8-27B와 Muse-Glimmer 성능 비교, 그리고 로컬 서비스 설정

🎯 최신 30B급 dense 모델 Qwen3.8-27B와 Muse-Glimmer 성능 비교, 그리고 로컬 서비스 설정

8월 초에 30B급 로컬 모델 두 개가 나왔다. 메타의 Muse-Glimmer-30B와 알리바바의 Qwen3.8-27B다. 둘 다 dense 구조이고, 4비트로 양자화하면 파일 크기도 16~18GB로 비슷하다. 사양표만 보면 같은 자리를 놓고 다투는 모델이다. 그래서 둘을 DGX Spark 한 대에 번갈아 올려 같은 과제로 재봤다.

결과는 사양표와 달랐다. 코딩 과제 54회 시행에서 통과 수는 54 대 52로 두 건 차이인데, 그 성적에 든 시간은 1,322초 대 343초였다. 메모리는 방향이 반대다. 토큰당 KV 캐시 비용이 Qwen3.8 쪽이 두 배 남짓 크다.

결론부터 적는다. 30B급 dense 모델을 고를 때 파라미터 수는 선택의 근거가 되지 못한다. 실제로 하드웨어 요구량과 응답 시간을 결정하는 것은 attention 구조에서 나오는 토큰당 KV 비용과 모델이 뱉는 토큰 수다. 둘 다 사양표에 없다.

측정 환경 — NVIDIA DGX Spark 1대(GB10, 128GB 통합 메모리, 메모리 대역폭 약 273GB/s). llama.cpp 자체 빌드, 두 모델 모두 4비트 양자화 GGUF, KV 캐시 8비트. 코딩 과제 18종 × 3회, 에이전틱 과제 4종 × 2회.

🧩 무엇이 다른가

두 모델의 차이는 파라미터 수가 아니라 attention 설계에 있다. 그 얘기를 하려면 KV 캐시부터 짚어야 한다.

배경 · KV 캐시와 GQA

트랜스포머는 토큰을 하나 만들 때마다 앞의 모든 토큰을 다시 참조한다. 매번 처음부터 계산하면 길이의 제곱만큼 비용이 드니, 각 토큰에서 뽑은 key와 value 벡터를 저장해 두고 재사용한다. 이 저장분이 KV 캐시다.

크기는 곱셈으로 결정된다. 토큰 수 × 레이어 수 × KV head 수 × head 차원 × 2(key와 value) × 자료형 바이트. 여기서 토큰 수만 사용자가 정하는 값이고 나머지는 모델이 정해서 나온다. 그래서 캐시는 컨텍스트 길이에 정비례한다 — 32K를 넣으면 4K일 때의 여덟 배가 된다.

모델이 줄일 수 있는 항은 KV head 수다. 원래 attention은 query head마다 key·value head를 하나씩 가진다(MHA, multi-head attention). GQA(grouped-query attention)는 여러 query head가 KV head 하나를 공유한다. query head 32개에 KV head 8개면 캐시가 1/4, 2개면 1/16이다. 공유를 늘릴수록 표현력은 조금 깎이지만 캐시는 그 비율 그대로 줄어들어서, 긴 컨텍스트를 노리는 모델일수록 이 비율을 세게 잡는다. 토큰당 KB 값은 이 설계 선택이 그대로 드러나는 숫자다.

Qwen3.8-27B는 GGUF 메타데이터를 열어보면 설계가 그대로 나온다.

키	값	뜻
block_count	65	층 64개 + MTP 헤드 1개
attention.head_count / _kv	24 / 4	GQA 6:1
attention.key_length / value_length	256 / 256	head 차원이 큰 편
full_attention_interval	4	네 층에 한 층만 full attention
ssm.state_size 외	128 등	나머지 세 층은 크기가 고정된 상태를 들고 간다

마지막 두 줄이 이 모델의 정체다. 64개 층이 전부 KV 캐시를 쌓는 게 아니라, 네 층에 한 층만 쌓고 나머지 48개는 선형 attention 계열이라 컨텍스트가 길어져도 상태 크기가 늘지 않는다.

이 해석은 실측으로 확정된다. full_attention_interval 4는 "네 층 중 하나가 full attention"으로도, "네 층 중 셋"으로도 읽힐 수 있다. 앞쪽이면 캐시 층이 16개라 16 × 4 × (256+256) = 32,768개/토큰, q8_0 블록 오버헤드까지 넣으면 약 34KB/token이다. 뒤쪽이면 48개 층에 약 104KB/token이 된다. 뒤에서 실측할 기울기가 44KB/token이므로 앞쪽만 맞는다. 다만 34와 44 사이의 10KB는 어디서 오는지 확인하지 못했다. SSM 상태는 컨텍스트가 늘어도 크기가 고정이라 기울기에 실릴 수 없고, compute buffer는 컨텍스트가 아니라 ubatch에 따라 변한다. 계산해 봐도 둘 다 설명이 안 된다. 예산을 잡을 때는 계산값 말고 실측 기울기를 쓰면 된다.

Muse-Glimmer 쪽도 서버에서 내리고 파일을 지우기 전에 잰 기록이 있다. 131,072 컨텍스트를 f16 KV로 잡았을 때 캐시가 약 4GB, 즉 대략 31KB/token이다. attention은 GQA 32:2.

두 값의 근거는 세기가 다르다. Qwen3.8의 44KB/token은 8K부터 512K까지 네 개 실측점에 최소제곱 직선을 맞춰 얻고 1M 실측으로 확인한 값이라 단단하다. Muse-Glimmer의 31KB/token은 "약 4GB"라고 반올림해 적어둔 기록에서 나온 값이고, 이 모델은 이미 지웠으므로 다시 잴 수 없다. 게다가 정밀도가 달라(q8_0 대 f16) 그대로 비교할 수도 없다. Muse를 8비트로 환산하면 16~17KB/token 언저리이므로 배수는 2.6~2.8배가 되는데, "약 4GB"가 3.5~4.5GB 어디든 될 수 있다는 걸 감안하면 2.4~3.2배 사이로 벌어진다. 그래서 본문은 "두 배 남짓"까지만 말한다.

참고로 커뮤니티 분석 하나는 Qwen 3.x를 64KB/token, Muse-Glimmer를 13KB/token으로 적어 다섯 배 차이라고 본다. Qwen 쪽 64KB는 우리 실측(q8_0 44 ≒ f16 83)과 자릿수가 맞아 다툴 게 없다. 채택하지 않은 건 Muse 쪽 13KB로, 우리 기록의 절반도 안 된다 — 배수를 만드는 게 정확히 그 값이라 그대로 쓸 수 없었다.

이 값이 왜 중요한지는 DGX Spark의 구조에서 나온다. DGX Spark는 CPU와 GPU가 128GB 통합 메모리를 나눠 쓰고 대역폭은 약 273GB/s다. 토큰 하나를 만들 때마다 읽어야 할 데이터가 곧 속도의 상한이 되고, 컨텍스트를 길게 잡을수록 KV 캐시가 그 데이터의 대부분을 차지한다. 같은 체급의 모델이라도 토큰당 캐시 비용이 두 배 남짓 다르면, 같은 컨텍스트를 감당하는 데 드는 메모리와 시간의 격차도 함께 커진다.

속도 차이의 두 번째 원인은 출력량이다. 같은 분석은 실사용 속도가 대체로 출력 토큰 수에 좌우되며, Qwen 계열이 "지나치게 많이 생각하는 경향 때문에 크게 불리하다"고 지적한다. 뒤에서 볼 측정값이 이 지적과 정확히 맞아떨어진다.

🔬 어떻게 쟀나

모델 비교에서 가장 흔한 실패는 답변을 읽고 좋아 보인다고 판정하는 것이다. 이번 측정은 그 판단을 사람에게서 떼어냈다. 코딩 과제 18개를 주고 모델이 내놓은 코드 블록을 실제로 실행해 미리 숨겨둔 assert 테스트를 통과하는지로 채점했다. 설명이 그럴듯한지는 점수에 반영되지 않는다.

과제는 구간 병합, LRU 캐시, 로그 파싱, 회전 정렬배열 탐색, CSV 따옴표 처리, 위상정렬, 수식 파서, 최장공통부분수열, 로마숫자, 애너그램 그룹핑, 중첩 딕셔너리 평탄화, word wrap, 나선 순회, 괄호 균형, 런렝스 인코딩(RLE) 왕복, 그리고 버그 수정 세 종이다. 각 과제를 3회 반복해 통과 여부가 아니라 통과율로 봤다.

채점에는 두 가지 규칙을 뒀다. 하나는 느슨하게, 하나는 빡빡하게다. 응답에 코드 블록이 여러 개면 전부 시도해 하나라도 통과하면 인정한다. 초안을 먼저 보여주는 모델이 초안 때문에 떨어지는 일을 막기 위해서다. 그리고 각 과제의 테스트는 참조 해답을 먼저 통과시켜 테스트 자체의 오류를 배제한 뒤에 사용했다.

코드 생성만으로는 터미널에서의 쓸모를 다 재지 못한다. 두 번째 측정은 임시 프로젝트 폴더에 실제 파일을 놓고, 모델에게 파일 목록 조회·읽기·쓰기·테스트 실행 네 가지 도구를 준 뒤 최대 14턴까지 스스로 돌게 하는 방식이다. 채점 대상은 대화가 아니라 루프가 끝난 뒤의 파일 상태이며, 모델이 본 적 없는 숨은 테스트를 워크스페이스에 돌려 판정한다. "고쳤습니다"라고 말만 한 경우는 0점이 된다.

📊 결과

코딩 18과제 × 3회의 통과 수와 총 소요시간이다. Qwen3.8은 thinking을 끈 조건과 reasoning_effort를 medium으로 둔 조건을 함께 실었다.

조건	통과	총 시간	출력 토큰
Muse-Glimmer-30B	54 / 54	1,322초	42,992
Qwen3.8-27B · thinking off	52 / 54	343초	8,509
Qwen3.8-27B · reasoning_effort=medium	49 / 54	1,135초	27,889

에이전틱 루프 4과제 × 2회다.

모델	통과	총 시간	평균 턴	도구 호출 오류
Muse-Glimmer-30B	8 / 8	304초	7.0	0
Qwen3.8-27B	7 / 8	138초	5.25	0

정확도는 Muse-Glimmer가 앞선다. 코딩 54회와 에이전틱 8회를 모두 통과했다. 다만 두 축의 성격이 다르다. 정확도 차이는 54개 표본에서 2건이고, 시간 차이는 3.9배와 2.2배로 서로 다른 두 측정에서 같은 방향으로 나타났다.

도구 사용 능력에서는 차이가 없었다. 16회 루프 전부에서 도구 호출 형식 오류가 0건이고, 전부 스스로 종료했으며, 전부 테스트를 실제로 돌려본 뒤 끝냈다. 로컬 모델이 에이전트 루프를 감당하지 못한다는 통념은 이 두 모델에는 해당하지 않는다.

에이전틱 과제 중 하나는 함정으로 설계했다. 세 파일에 걸친 함수 이름 변경인데, 눈에 보이는 테스트는 시작부터 통과 상태다. 테스트만 쫓는 모델은 할 일이 없다고 판단할 수 있고, 숨은 테스트만이 새 이름의 존재와 옛 이름의 부재를 확인한다. 두 모델 모두 지시대로 세 파일을 고쳤다. 다만 Muse-Glimmer는 11턴을 썼고 Qwen3.8은 5~7턴이었다.

⚙️ Qwen3.8의 thinking 설정을 그대로 쓰면 안 되는 이유

위 표에서 눈에 띄는 것은 thinking을 켠 조건이 끈 조건보다 느리면서 동시에 정확도도 낮다는 점이다. 이 모델을 쓸 때 가장 먼저 손대야 할 설정이 여기 있다.

reasoning_effort 기본값이 폭주한다

Qwen3.8은 채팅 템플릿의 reasoning_effort 기본값이 xhigh다. 그대로 두면 한 과제에서 thinking에만 30,837자를 쓰고 토큰 상한에 걸려 답이 잘리는 일이 생긴다. 같은 과제를 medium으로 내리면 3,068자를 쓰고 통과했다. 소요시간은 394초에서 52초로 줄었다. 두 조건의 차이는 열 배 규모다.

reasoning_effort와 reasoning-budget은 서로 다른 장치다

llama.cpp에는 생각 분량을 제한하는 --reasoning-budget 옵션이 있다. 이름만 보면 "이 한도 안에서 정리하라"로 읽히지만 동작은 다르다. 모델은 한도의 존재를 모른 채 평소대로 생각하고, 한도에 닿는 순간 바깥에서 end-of-thinking 태그(</think>)가 강제로 삽입된다. 응답을 열어보면 문장 한가운데에서 끊긴 자국이 그대로 남는다.

따라서 한도를 낮게 잡는 것은 "압축해서 생각하라"가 아니라 "덜 생각한 채로 답하라"가 된다. 모델이 스스로 깊이를 조절하게 만드는 값은 reasoning_effort 쪽이며, 이 값은 프롬프트에 실려 모델이 알고 반응한다. 두 값은 맞물려야 한다. reasoning_effort를 xhigh로 두고 한도를 8,000토큰으로 잡으면 매번 길게 생각하다 잘리는 최악의 조합이 된다.

llama.cpp는 끊기는 순간 모델에게 건넬 문장을 지정하는 --reasoning-budget-message 옵션도 제공하는데, 기본값은 없다. 아무 안내 없이 끊는 대신 "시간이 다 됐으니 지금까지 정리해 답하고, 확인하지 못한 것은 추측하지 말고 그렇다고 밝히라"를 넣어두면 결과가 달라진다. 실측에서 이 문장은 생각 중간에 정확히 삽입됐고, 모델은 거기서 멈춘 뒤 완결된 답을 냈다.

권장 샘플링이 모드마다 다르다

공개된 권장값은 두 벌이다. thinking을 켠 모드는 temperature 1.0 · top_p 0.95 · top_k 20이고, thinking을 끈 모드는 temperature 0.7 · top_p 0.80 · top_k 20에, 반복을 억제하는 presence_penalty 1.5다. thinking을 끄고 쓰기로 했다면 샘플링도 함께 바꿔야 하는데, 서버 기본값만 켠 모드에 맞춰두고 요청에서 thinking만 끄는 구성이 흔한 실수다.

📐 컨텍스트를 예산으로 환산하는 법

Qwen3.8-27B에서 컨텍스트 길이만 바꿔가며 잰 값이다.

컨텍스트	GPU 사용량	그중 KV 캐시
8K	18,748 MiB	기준(가중치 + 비전 인코더)
128K	23,964 MiB	5,216 MiB
256K	29,596 MiB	10,848 MiB
512K	40,860 MiB	22,112 MiB
1M	63,388 MiB	44,640 MiB

토큰당 약 44KB이고 1M까지 직선을 유지한다. 512K까지의 네 점에 최소제곱 직선을 맞춰 1M을 예측하면 63,324MiB가 나오는데 실측이 63,388MiB였으므로 오차는 0.1%다. 컨텍스트를 조정할 때 추정 대신 이 계수를 쓰면 된다.

KV 캐시 양자화에서는 흔한 기대가 빗나간다. 512K 조건에서 8비트 캐시가 22,112MiB를 쓰는데, 4비트로 내리면 절반인 11,000선이 아니라 13,920MiB가 된다. 63% 수준이다. 블록 단위 양자화의 오버헤드와, 양자화되지 않고 남는 텐서가 원인이다.

prefill 속도를 잴 때는 큰 프롬프트를 써야 한다. 짧은 프롬프트에서는 고정 비용이 지배해 처리량이 아니라 지연시간을 재게 된다. 26,000토큰 프롬프트에서 아래 설정의 512K 슬롯 하나가 낸 prefill 속도는 약 730 tok/s였다.

🔧 우리가 실제로 쓰는 설정

위 내용을 하나로 합치면 지금 돌아가고 있는 구성이 된다. llama.cpp llama-server 기준이고, 모델 경로·host·port는 각자 것으로 바꾸면 된다.

llama-server \
  --model Qwen3.8-27B-UD-Q4_K_XL.gguf \
  --mmproj mmproj-Qwen3.8-27B-F16.gguf \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --n-gpu-layers 999 \
  --ctx-size 1048576 --parallel 2 \
  --rope-scaling yarn --rope-scale 4 --yarn-orig-ctx 262144 \
  --override-kv qwen35.context_length=int:1048576 \
  --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --jinja \
  --chat-template-kwargs '{"reasoning_effort":"medium"}' \
  --reasoning-budget 8000 \
  --reasoning-budget-message "Thinking budget reached. Stop reasoning now and \
answer with what you have. Give your best conclusion, and name anything you \
could not verify instead of guessing." \
  --no-mmap --cache-ram 1024 --ctx-checkpoints 8 \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --presence-penalty 0.0 --repeat-penalty 1.0

줄별로 왜 그 값인지 정리하면 이렇다.

플래그	값	이유
--ctx-size / --parallel	1048576 / 2	ctx-size는 슬롯당이 아니라 전체 풀이다. 이 조합은 512K 슬롯 두 개이고, 메모리는 1M 하나일 때와 같다
--rope-scaling 계열	yarn / 4 / 262144	이 모델의 native 학습 길이가 262,144다. 그 위로 가려면 YaRN이 필요하고 배수는 목표 ÷ native
--override-kv	qwen35.context_length	메타데이터의 컨텍스트 상한을 덮어쓴다. arch 이름이 틀리면 조용히 무시된다. arch 이름은 모델 번호와 다르다 — Qwen3.8인데 키는 qwen35다
--cache-type-k/v	q8_0	KV 8비트. 4비트는 절반이 아니라 63%까지만 줄고 품질은 더 깎인다
--chat-template-kwargs	reasoning_effort medium	템플릿 기본값이 xhigh다. 그대로 두면 생각만 하다 답이 잘린다
--reasoning-budget	8000	비상 정지선. 실측 25 tok/s에서 최악의 대기를 5분 남짓으로 묶는 값
--reasoning-budget-message	위 문장	없으면 생각이 문장 중간에서 잘린다. 이 옵션이 짧은 budget을 쓸 수 있게 해주는 것
--spec-type	draft-mtp	MTP가 본체 GGUF에 들어 있는 모델이라 --model-draft가 없다
--cache-ram	1024	프롬프트 캐시 상한. 기본값이 서버당 8192MiB라 여러 개 띄우면 호스트 RAM을 먹는다
샘플링	1.0 / 0.95 / 20 / 0.0	모델카드의 thinking 권장값. thinking을 끌 거면 0.7 / 0.80 / 20 + presence_penalty 1.5로 함께 바꿔야 한다

이 설정은 thinking을 켜 둔다 — 앞 절과 모순이 아니다. 서버 기본값은 코딩만이 아니라 온갖 호출을 받는다. 코딩 과제에서는 켠 쪽이 더 낫지 않았다 — 정확도는 같거나 조금 낮고 속도는 3배 넘게 느리다. 그런데 우리가 잰 범위가 자족적인 함수 한 개짜리 문제뿐이고, thinking이 값을 한다고 알려진 영역(설계·리팩터링·원인 불명 버그)은 측정하지 않았다. 그래서 서버 기본값은 측정한 적 없는 쪽에 유리하게 두고, 코딩처럼 끄는 게 유리한 게 확인된 용도는 요청에서 enable_thinking: false로 끈다. 느린 건 기다리면 되지만, 켰어야 할 자리에서 꺼져 있었던 건 결과를 봐도 모른다. 다만 요청에서 끌 거라면 샘플링도 함께 바꿔야 한다 — 아래 표 마지막 줄.

이 중 사고가 나는 건 둘이다. --ctx-size를 슬롯당으로 읽고 --parallel을 올리면 요구 메모리가 슬롯 수만큼 곱해져 부팅이 실패한다. --override-kv의 arch 이름을 틀리면 에러 없이 무시되고, 컨텍스트가 늘지 않은 채로 정상 부팅한 것처럼 보인다. 후자는 로그의 n_ctx를 직접 확인하는 것 말고 알아챌 방법이 없다.

DGX Spark 커뮤니티에서 자주 권하는 --ubatch-size 2048과 스레드 수 조정은 이 조합에서는 효과가 없었다. 26,000토큰 프롬프트 prefill이 731 tok/s에서 평균 722 tok/s로, 측정 편차 안이다. 대신 compute buffer가 3,516MiB 늘어서 되돌렸다. 권장 플래그라도 자기 모델·자기 컨텍스트에서 재보고 결정하는 게 맞다.

⚖️ 이 숫자를 어디까지 믿을까

여기 실은 값은 DGX Spark 한 대에서, 우리가 만든 과제셋으로 잰 것이다. 공개 벤치마크가 아니라 참고 자료로 읽는 게 맞다. 한계는 셋이다.

과제가 쉬웠다 — ceiling effect. 세 조건이 전부 90%대 이상이라는 건 이 과제들로 두 모델이 갈리지 않는다는 뜻이다. 뒤집어 읽으면 어렵지 않은 문제는 둘 다 잘한다가 된다. 일상적인 함수 작성이 목적이라면 정확도로 고를 이유가 별로 없고, 선택은 속도와 메모리에서 갈린다. 다만 과제가 전부 자족적인 함수 하나짜리라 설계·리팩터링·원인 불명 버그처럼 thinking이 값을 하는 영역은 아예 들어 있지 않다. thinking을 끄는 편이 낫다는 결론도 그 범위 안에서만 유효하다.

표본이 얇다. 과제마다 3회씩 돌렸지만 그 3회가 표본의 전부이고, 세트를 통째로 다시 돌리지는 않았다. 실패한 과제를 같은 조건으로 재시행하니 통과했으므로 조건 사이의 2건 차이는 그 흔들림 안에 있다고 봐야 한다. 벤치마크는 세 조건 모두 temperature 0.6으로 돌렸다. thinking 말고 다른 변수가 움직이지 않게 일부러 고정한 것이라, 아래 설정 절에서 권하는 모드별 샘플링(1.0 / 0.7)과는 다르다. 재현하려면 권장값이 아니라 이 값을 맞춰야 한다.

공개 수치와는 축이 다르다. Qwen3.8-27B의 공개 성적은 LiveCodeBench v6 90.3, OSWorld-Verified 84.3이다. 다만 원본 정밀도, 256K 컨텍스트, 벤더 자체 측정이라는 조건 위의 값이라 4비트 양자화로 다른 과제를 돌린 이 글의 숫자와 같은 표에 올릴 수 없다. 뒤집으면 둘 다 쓸 데가 있다 — 공개 수치는 이 모델이 최상의 조건에서 낼 수 있는 천장이고, 이 글의 숫자는 책상 위 DGX Spark에서 4비트로 받게 될 바닥이다.

같은 하드웨어에서 나온 다른 결론

DGX Spark에서 dense가 불리하다는 건 널리 알려져 있다. 공개된 벤치마크는 같은 Q4_K_M 조건에서 30B MoE를 83.8~89.3 tok/s, 32B dense를 10.5~10.7 tok/s로 적고, 이 차이를 "DGX Spark를 규정하는 특성"이라고 부른다. 약 8배다. 우리 자체 측정도 MoE 쪽은 같은 자리에 온다 — 전에 쓰던 35B MoE가 87 tok/s였다.

다만 이 글의 두 dense 모델은 그 10 tok/s대가 아니다. Qwen3.8-27B가 약 25, Muse-Glimmer가 28 tok/s다(Qwen 쪽은 이 글을 쓰면서 현재 구성으로 3회 재측정한 값 — 24.4 / 25.3 / 25.5). 둘 다 speculative decoding용 draft head를 달고 있기 때문이고, Muse는 그걸 끄면 13 tok/s로 떨어진다. Muse 쪽 수치는 KV 값과 마찬가지로 모두 폐기 전 기록이며, 모델을 지웠으므로 다시 잴 수 없다. 앞의 결과 표를 나눠보면 이 28과 어긋난다. 뮤즈는 42,992토큰을 1,322초에 냈으니 32.5 tok/s이고, 총 시간에 프롬프트 처리가 포함돼 있으므로 이건 디코딩 속도의 하한이다. 즉 그 시행들에서 뮤즈는 최소 32.5로 디코딩했다. 28은 서버 네 대가 모두 떠 있던 다른 조건에서 잰 별개 기록이라 같은 축에 놓을 수 없고, 모델을 지웠으므로 지금 와서 맞춰볼 방법도 없다. dense가 대역폭 병목에서 손해를 보는 건 맞지만, draft head가 그 손해의 절반쯤을 되돌려준다. MoE와의 격차는 그래도 3~4배 남는다.

같은 하드웨어에서 더 빠른 구성도 보고된다. SGLang에 NVFP4 양자화와 draft model을 얹어 34~38 tok/s다. 다만 그 보고 자체가 조건을 붙인다. draft model이 내용과 맞지 않으면 이득이 사라지고, 다국어 산문에서는 19.5 tok/s로 떨어져 다른 구성의 24.7 tok/s보다 느려졌다. draft acceptance rate가 3.3~4.9에서 1.25~1.52로 내려간 탓이다.

✅ 용도별 선택

상황	선택	근거
자주 부르는 코딩 보조	Qwen3.8-27B, thinking off	96.3%를 4분의 1 시간에. 실패는 재시도로 넘어가는 종류
틀리면 비싼 작업	Muse-Glimmer-30B	두 측정에서 실패 0회. 2건 차이는 잡음 안이지만, 최악을 줄이는 쪽을 고르는 선택
긴 에이전트 루프 (dense 중에서)	Muse-Glimmer-30B	토큰당 KV가 절반 이하라 컨텍스트가 쌓여도 예산이 버틴다
긴 문서·이미지를 다루는 작업	Qwen3.8-27B	실사용 컨텍스트가 1M(native 262,144에 YaRN 확장)으로 Muse-Glimmer의 131,072보다 훨씬 크고, 토큰당 44KB로 소요 메모리를 미리 계산할 수 있다
속도가 최우선	같은 체급의 MoE	우리 실측으로 35B MoE 87 대 Qwen3.8 25 tok/s — 약 3.5배. 다만 두 값은 측정 시점과 빌드·컨텍스트 설정이 달라 통제된 비교가 아니다. draft head가 없는 dense는 11까지 떨어진다

한 줄로 줄이면, 30B급 dense 모델을 고르는 일은 정확도 순위표를 고르는 일이 아니라 토큰당 KV 비용과 출력 토큰 수를 고르는 일이다. 두 모델의 정확도 차이는 54회 중 2회였고, 그 성적에 든 시간은 3.9배, 토큰당 KV 비용은 두 배 남짓 차이였다.

📚 참고 자료

• Qwen3.8-27B 공식 모델카드 — 권장 샘플링, LiveCodeBench v6 90.3, OSWorld-Verified 84.3
• DGX Spark llama.cpp 벤치마크 리포트 — 273GB/s, dense와 MoE의 디코딩 속도 차이
• 30B급 dense 모델의 토큰당 KV 비교(커뮤니티 분석) — 본문의 실측과 다름
• SGLang + NVFP4 + draft model 구성 보고 — 34~38 tok/s와 그 조건
• llama.cpp server README — reasoning-budget 및 reasoning-budget-message