Qwen3.8 27B 모델, 내 맥에서 진짜 쓸 수 있을까
Qwen3.8-27B가 dense인데도 MoE급 성능이 나온다는 이야기를 봤습니다. 리더보드를 열어보니 같은 27B급 모델들이 평균 0.51-0.53 사이에 몰려 있고, 이 모델도 그 안에 들어 있더라고요. 27B dense면 제가 쓰는 맥에서도 돌아가는 크기죠. 그래서 자연스럽게 이런 생각이 들었습니다. 이거 실제 업무에 붙일 수 있는 물건인가.
문제는 조건입니다. 제 맥은 M4 Pro 48GB인데, 27B를 BF16으로 올리면 54GB라 애초에 안 들어갑니다. 게다가 통합메모리인 부분을 고려하면 4bit로 양자화한 15GB짜리를 써야 합니다. 그러면 리더보드에 올라온 수치는 원본 정밀도 기준이니까, 내 환경에서 실제로 얼마나 나오는지는 따로 재봐야 하는 것들이 생깁니다. 결국에는 양자화 모델의 벤치마크를 어떻게 돌려야 하는가라는 질문으로 시작한 셈입니다.
lm-eval harness로 시작했는데
가장 익숙한 조합부터 갔습니다. lm-evaluation-harness[1]에 LM Studio를 붙이는 겁니다. LM Studio가 OpenAI 호환 API를 열어주니까 local-chat-completions 모델 타입으로 연결하면 될 거라고 생각했습니다.
gsm8k 세 문제는 잘 돌아가더라고요. 문제당 19초쯤 걸렸고 두 문제 맞혔습니다. 여기까지는 되게 순조로웠습니다.
그런데 MMLU를 돌리려니까 안 됩니다. 이유를 이해하려면 logprobs가 뭔지부터 짚어야 해요.
언어 모델은 다음 토큰을 고를 때 후보마다 확률을 매깁니다. logprob은 그 확률에 로그를 씌운 값이에요. 이 모델이 이 문장을 얼마나 자연스럽다고 보는가를 숫자로 꺼내온 것들이라고 보면 됩니다. 확률 0.67이면 logprob은 -0.4쯤 되고, 확률 0.0003이면 -8.1쯤 됩니다. 0에 가까울수록 모델이 그 문장을 그럴듯하게 본다는 뜻이에요.
객관식 벤치라고 하는 것들은 이 값을 씁니다. 프랑스의 수도를 묻는 문제가 있으면 모델한테 답을 쓰라고 하지 않아요. 프롬프트 뒤에 리옹, 파리, 마르세유, 니스를 각각 붙여서 문장 네 개를 만들고, 모델에 통과시켜서 붙인 부분의 logprob을 더합니다. 제일 높은 게 모델의 답입니다. 생성을 안 하니까 빠르고, 모델이 딴소리를 해도 채점이 안 흔들리고, 리더보드 수치 대부분이 이렇게 나온 값이라 비교도 됩니다.
여기서 핵심은 붙인 부분의 logprob이라는 거예요. 모델이 스스로 고른 토큰이 아니라, 내가 써서 넘긴 토큰의 확률이 필요합니다. lm-eval 소스를 보면 실제로 그렇게 계산해요. 프롬프트 길이를 ctxlen이라고 두고, 응답에서 그 뒤쪽 토큰들의 logprob만 잘라서 더합니다.
logprobs = sum(choice["logprobs"]["token_logprobs"][ctxlen:-1])그러려면 API가 내가 보낸 텍스트를 그대로 되돌려주면서 토큰마다 logprob을 붙여줘야 하는데, 이게 completions 엔드포인트의 echo 옵션입니다. 그리고 LM Studio는 이걸 안 줍니다.
처음엔 제가 잘못 보낸 줄 알았습니다. 아니죠, chat completions는 logprobs를 주긴 줍니다. 근데 그건 모델이 방금 생성한 토큰의 확률이에요. 내가 써서 넘긴 문자열의 확률이 아니에요. completions 엔드포인트에 echo를 켜서 요청해야 하는데 LM Studio는 echo도 logprobs도 구현이 안 돼 있더라고요. 마침 LM Studio가 Open Responses API[2]라는 걸 새로 내놨길래 그것도 확인했는데, 여기도 생성 토큰의 logprobs만 줍니다. 네이티브 API까지 네 군데를 다 찔러봤는데 전부 같았습니다.
lm-eval 소스를 열어보니 아예 명시가 돼 있었습니다.
Loglikelihood (and therefore multiple_choice-type tasks) is not supported for chat completions as OpenAI does not provide prompt logprobs.
결국에는 HTTP API를 통해서는 객관식 벤치를 돌릴 수 없다는 게 결론이었습니다.
mlx_lm evaluate로 넘어가기
모델을 직접 로드하면 되는 거였습니다. mlx_lm에 lm-eval이 통합돼 있어서[3] 명령 하나로 같은 태스크를 돌릴 수 있더라고요. 이 모델은 GGUF가 아니라 MLX 포맷이라 llama.cpp로 우회하는 것도 안 됐는데, 오히려 그래서 mlx_lm이 정답이었습니다.
python3 -m mlx_lm evaluate \
--model /path/to/Qwen3.8-27B-MLX-4bit \
--tasks kmmlu haerae \
--no-apply-chat-template --batch-size 1여기서 함정 같은 것들을 두 개 밟았습니다.
chat template을 켜면 점수가 무너져요. MMLU abstract_algebra 20문제로 대조해봤는데 끄면 0.70, 켜면 0.20이 나왔어요. 4지선다에서 무작위가 0.25니까 켜면 찍는 것보다 못한 겁니다. 객관식은 선택지의 확률을 비교하는 건데 chat template이 프롬프트 구조를 바꿔놓으니까 그 비교가 어긋나는 겁니다.
batch-size는 1이 제일 빠릅니다. 8이나 32로 올리면 오히려 느려져요. MLX 패딩 오버헤드 때문인데, 50문제 기준으로 1일 때 55초, 32일 때 66초였습니다. 정확도는 셋 다 같았고요.
한국어 벤치 중에 lm-eval에 없는 것들이 있었습니다. KMMLU-Pro[4], Ko-MuSR[5] 같은 거요. 이건 YAML 하나 써서 lm-eval의 tasks 디렉토리에 넣으면 됩니다. mlx_lm evaluate에 include_path 옵션은 없는데 내부에서 simple_evaluate를 호출하니까 그냥 인식이 되더라고요. 데이터셋 스키마를 보면서 잔손이 좀 갔습니다. KMMLU-Pro는 5지선다 2,702문항에 4지선다 120문항이 섞여 있어서 선택지 레이블을 문항마다 잘라줘야 했고, 정답 필드가 숫자가 아니라 문자열이라 형변환을 안 하면 TypeError가 납니다. 결국에는 도구를 바꾸는 게 아니라 모델을 로드하는 경로를 바꾸는 문제였습니다.
결과
한국어 벤치 다섯 개를 돌렸습니다. 서브태스크당 50문제로 잘랐으니 정식 수치는 아니고 경향을 보는 용도입니다.
| 벤치 | 값 | 무작위 기준 |
|---|---|---|
| HAE-RAE | 0.756 | 0.25 |
| CLIcK | 0.717 | 0.25 |
| KMMLU | 0.575 | 0.25 |
| Ko-MuSR | 0.540 | 0.25-0.50 |
| KMMLU-Pro | 0.420 | 0.20 |
| ko_commongen_v2 | 0.300 | 0.25 |
업무 적용 관점에서 보면 이렇습니다. 한국 문화나 상식을 묻는 것들은 되게 잘해요. CLIcK 문화 파트가 0.77이고 전통 항목은 0.92까지 나와요. KMMLU에서도 computer_science가 0.92, economics가 0.86입니다. 그런데 한국어 문법 판단은 0.34로 좀 약합니다. 문화는 아는데 언어 자체는 흔들리는 겁니다.
| 영역 | 항목 | 값 |
|---|---|---|
| 강함 | CLIcK 전통 | 0.92 |
| 강함 | KMMLU computer_science | 0.92 |
| 강함 | KMMLU economics | 0.86 |
| 강함 | CLIcK 문화 파트 전체 | 0.77 |
| 약함 | CLIcK 문법 | 0.34 |
| 약함 | KMMLU 전문 법률 | 0.18 |
같은 법률인데 정반대인 게 재미있었습니다. CLIcK의 생활 법률 상식은 0.88인데 KMMLU의 전문 법률은 0.18이에요. 4지선다에서 0.18이면 찍는 것보다 낮습니다. 단순히 모르는 게 아니라 체계적으로 틀린 답을 고르고 있다는 뜻입니다. 한국 법체계가 국가별 특수성이 강한 영역이라 다른 나라 법 지식을 끌어다 쓰는 것 같더라고요. 역사도 비슷한데, HAE-RAE 역사는 0.78이고 CLIcK 역사는 0.46입니다. 같은 영역인데 벤치마다 0.32가 벌어지니까, 벤치 하나 보고 이 모델 역사 잘한다고 말하면 안 되는 거였습니다.
| 영역 | 벤치 A | 벤치 B | 차이 |
|---|---|---|---|
| 법률 | CLIcK 생활 법률 0.88 | KMMLU 전문 법률 0.18 | 0.70 |
| 역사 | HAE-RAE 역사 0.78 | CLIcK 역사 0.46 | 0.32 |
ko_commongen_v2에서는 평가 설계의 함정을 하나 봤습니다. 개념 몇 개를 주고 자연스러운 문장을 고르라는 건데, 선택지가 A나 B 같은 레이블이 아니라 문장 자체예요. 문장 네 개의 로그확률을 그대로 비교하면 짧은 문장이 유리해지거든요. 그래서 acc는 0.20으로 찍는 것보다 낮게 나오고, 길이로 정규화한 acc_norm이 0.30입니다. 지표 하나만 봤으면 모델이 문장을 아예 못 고른다고 결론 냈을 겁니다.
재는 도중에 멈춘 이야기
말이 좀 돌아갔는데, 사실 이 결과가 나오기까지 하루가 더 걸렸습니다. 처음 한 번은 limit 없이 전부 돌리려고 했거든요. KMMLU-Pro 2,822문항을 걸어놓고 보니 진행률 표시에 문제당 140초, 예상 완료 110시간이라고 찍혀 있었습니다. 앞서 돌린 KMMLU가 문제당 1.4초였는데 갑자기 100배가 느려진 겁니다.
한참을 원인을 찾았습니다. 프롬프트가 긴가 싶어서 재보니 평균 346자로 짧았고, 디스크가 느린가 싶어서 재보니 15.9GB/s로 정상이었어요. 그러다 문항 단위 로그를 뜯어보니까 61번까지는 3초씩 가다가 62번에서 17분을 멈추고, 그 다음부터 다시 2초로 돌아오더라고요. 지속적으로 느린 게 아니라 간헐적으로 한 번씩 멈추는 거였습니다. tqdm이 직전 구간 속도로 남은 시간을 계산하니까 스톨 직후에 110시간이라는 숫자가 튀어나온 거고요.
그러면 왜 멈추냐가 다음 질문이었는데, 여기서 제가 잘못 짚었습니다. 벤치를 태스크마다 새 프로세스로 돌리고 있었으니까 모델을 올리고 안 내려서 메모리가 쌓이는 건가 싶었어요. 확인해보니 아니었습니다. 남은 프로세스는 없었고, 실행 중인 걸 죽이니까 여유 메모리가 0.1GB에서 16GB로 바로 돌아왔어요. 진짜 원인은 다른 앱들이었습니다. 가상머신 하나가 6.2GB, 크롬 헬퍼들이 합쳐서 4.5GB, node가 1GB. 이것들이 15GB를 이미 먹고 있는 상태에서 모델 15.5GB를 얹으니까 macOS가 페이지를 회수하는 순간마다 모델이 스왑으로 밀려나는 거였습니다.
그런데 이때 vm_stat을 보면 free가 0.3GB인데 memory_pressure는 여유 90%라고 해요. 48GB 맥에서 메모리가 안 남는다는 게 이해가 안 됐는데, macOS가 free를 최소로 유지하고 나머지를 캐시로 쓰기 때문에 free 수치 자체는 정상인 거였습니다. 진짜 압박은 swapusage랑 같이 봐야 보이더라고요.
해결은 두 줄이었습니다. 모델 가중치를 wired memory에 고정해버리면 회수 대상에서 빠집니다.
import mlx.core as mx
GB = 1024 * 1024 * 1024
mx.set_wired_limit(20 * GB)
mx.set_cache_limit(2 * GB)이걸 걸기 전엔 생성 평가에서 문항 하나에 1,233초가 걸렸는데 걸고 나니 16-76초로 돌아왔습니다. 결국에는 메모리가 쌓인 게 아니라 메모리를 지켜주지 않은 게 문제였던 겁니다.
그런데 리더보드랑 다르네
여기서 이상한 걸 발견했어요. 공식 리더보드에 같은 모델이 올라와 있는데 KMMLU-Pro가 0.549예요. 저는 0.42가 나왔거든요. 0.13 차이입니다.
자연스럽게 4bit 탓인가 싶었죠. 그런데 다른 벤치를 같이 놓고 보니까 그게 아니더라고요.
| 벤치 | 리더보드 | 내 측정 | 차이 |
|---|---|---|---|
| Ko-MuSR | 0.55 | 0.54 | -0.01 |
| CLIcK | 0.763 | 0.717 | -0.046 |
| KMMLU-Pro | 0.549 | 0.420 | -0.129 |
양자화가 성능을 깎았다면 모든 벤치가 고르게 내려가야 합니다. 근데 Ko-MuSR은 거의 일치하고 KMMLU-Pro만 크게 벌어져요. 추론이 필요한 벤치일수록 차이가 커지는 패턴이었습니다.
표본 크기도 봤습니다. 50문제에서 0.42였는데 100문제로 늘리니까 0.47로 올라가더라고요. 일부는 표본 때문이 맞는데 0.13을 다 설명하진 못해요.
그래서 논문을 열어봤습니다. KMMLU-Pro 논문[4]에 평가 프로토콜이 나와 있었어요.
By default, we apply a zero-shot Chain-of-Thought (CoT) prompt written in Korean. ... We use greedy decoding for non-reasoning models, while for reasoning models, we adopt the temperature of 0.6 and top-p of 0.95.
공식 평가는 CoT 생성 방식이었습니다. 모델이 실제로 풀이를 쓰고 답을 뽑는 겁니다.
저는 loglikelihood로 쟀으니까 애초에 같은 시험이 아니었던 겁니다. 이 모델은 reasoning 모델이라 thinking을 켜고 재는 게 공식인데, 저는 chat template을 꺼서 thinking 자체가 불가능한 상태로 잰 거고요. 심지어 논문은 reasoning 모델이 한국어 프롬프트에서 더 못하는 경우가 있어서 한국어랑 영어 둘 다 돌리고 높은 쪽을 보고했다고 합니다. 결국에는 같은 벤치 이름 아래 전혀 다른 시험이 두 개 있었던 겁니다.
CoT로 다시 재봤더니
그럼 CoT로 재면 0.549에 가까워지겠네 싶었죠. 그래서 해봤는데 반대로 나왔습니다.
먼저 lm-eval의 생성 경로로 돌렸는데 이게 또 멈췄습니다. 프로세스가 36GB까지 부풀면서 50분 동안 CPU를 3분밖에 안 쓰더라고요. 문항마다 KV 캐시가 쌓이는데 해제를 안 하는 것 같았습니다. 그래서 lm-eval을 거치지 않고 문항마다 generate 하고 캐시를 비우는 루프를 직접 짰어요.
thinking을 끄고 CoT 프롬프트만 줬을 때 30문제에서 0.30이 나왔습니다. loglikelihood보다 낮아요. 예측이 D랑 E로 쏠리는 편향도 보였고요. 정답 분포는 균등한데 모델은 D를 열 번, E를 일곱 번 골랐습니다. thinking이 없는 CoT는 그냥 생성이라서, 풀이를 쓰다가 엉뚱한 데로 흘러갈 여지가 확률 비교보다 큰 것 같더라고요.
그래서 thinking을 켰습니다. 그랬더니 안 끝나요. 3,072토큰을 다 쓰고도 think 태그가 안 닫혀요. 6,144토큰으로 올렸더니 문제 하나에 7분을 쓰고 20,000자를 뱉었는데도 결론에 안 도달합니다. 민법의 법원(法源)을 묻는 5지선다 문제였는데, 생성 끝부분을 보면 이렇습니다.
I recall a Korean bar exam question: "관습법에 관한 설명으로 옳지 않은 것은?" One option: "법원은 관...
Art 726: - Art 727: - Art 728: - Art 729: - Art 730: - Art 731: - Art 732: - Art 733:
mandatory? Let's recall hierarchy: "제정법이 있는 경우, 관습법은 적용할 수 없다. 다만, 제정법이 관습에 위임하는 경우, 또는 제정
한국어 문제인데 영어로 생각하고, 기억나는 판례를 더듬다가, 어느 순간 민법 조문 번호를 726조부터 하염없이 나열합니다. 발산하는 겁니다. 재미있는 건 같은 문제를 thinking 끄고 물어보면 83초 만에 정답 D를 맞힙니다. 풀이도 멀쩡해요. 제정법이 관습법보다 상위라는 걸 짚고 D가 그 순서를 뒤집었다고 정확히 지적합니다. 생각을 안 하면 맞히고 생각을 하면 못 끝내는 상황인 거죠.
의미 있는 표본을 재려면 서너 시간이 필요한데 그마저 답이 나온다는 보장이 없어서 여기서 멈췄습니다.
여기서 하나 더 해봤습니다. Qwen3 계열에는 thinking budget이라는 게 있어요. 예산만큼만 생각하게 두고, 그 안에 안 끝나면 전환 문구를 끼워 강제로 사고를 닫고 답을 받는 방식입니다. 답이 안 나오는 상황 자체를 없앨 수 있는 겁니다.
budget 1024로 30문항을 돌리니 전부 답이 나왔습니다. 30문항 전부 예산에 걸렸는데도요. 그런데 점수는 0.27로 thinking off보다도 낮았어요. 1,024토큰이면 사고의 앞부분만 있는 상태라, 거기서 답을 내게 하면 찍는 거랑 크게 다르지 않은 겁니다. 2048로 올리니 0.40이 나왔습니다. loglikelihood랑 거의 같은 수준까지 올라온 거예요. 문항당 3분씩 걸렸고, 이번에도 30문항 전부 예산에 걸렸습니다.
그래서 4096까지 올려봤습니다. 문항당 6분씩 세 시간이 걸렸는데 0.43이 나왔어요. 2048에서 0.13 올랐던 게 4096에서는 0.03 오른 겁니다. 문항별로 대조하면 2048과 4096이 아홉 문항을 같이 맞히고 각각 세 개, 네 개만 따로 맞혀서 사실상 같은 결과였습니다. 30문항 중 29문항이 여전히 예산에 걸렸는데도요.
| 조건 | acc | 증가분 | 예산에 걸린 문항 | 문항당 | 생성 길이 |
|---|---|---|---|---|---|
| thinking off | 0.30 | 해당 없음 | 30초 | 661자 | |
| budget 1024 | 0.27 | -0.03 | 30/30 | 90초 | 3,405자 |
| budget 2048 | 0.40 | +0.13 | 30/30 | 190초 | 6,295자 |
| budget 4096 | 0.43 | +0.03 | 29/30 | 347초 | 12,784자 |
문항별로 어느 조건이 맞혔는지 겹쳐 보면 이렇습니다.
| 비교 | 둘 다 정답 | 앞만 정답 | 뒤만 정답 | 둘 다 오답 |
|---|---|---|---|---|
| off vs 1024 | 4 | 5 | 4 | 17 |
| off vs 2048 | 5 | 4 | 7 | 14 |
| 2048 vs 4096 | 9 | 3 | 4 | 14 |
결국에는 곡선이 2048 근처에서 꺾인 건데, 이 4bit 모델은 예산을 더 줘도 0.42-0.43이 상한으로 보입니다. 리더보드의 0.549까지 남은 0.12는 예산으로는 안 메워지고, 양자화 자체나 프롬프트 언어 같은 다른 요인의 몫인 셈입니다. 30문항 표본이라 오차가 0.09쯤 되니 숫자 하나하나는 확정적이지 않지만, off 0.30에서 1024 0.27, 2048 0.40, 4096 0.43으로 방향은 일관됐습니다.
정리하면 이렇습니다. 리더보드와의 차이는 양자화가 정확도를 직접 깎아서가 아니었습니다. 평가 방식이 달랐고, 그 방식의 핵심인 thinking이 4bit 모델에서는 안정적으로 수렴하지 않았습니다. 예산을 걸어 억지로 끝내면 점수가 올라오긴 하는데 2048 근처에서 꺾여서, 예산만으로는 리더보드 수치에 닿지 않습니다. 양자화가 정확도가 아니라 추론 경로의 안정성을 건드렸을 가능성이 있는 겁니다. 확증하려면 원본 정밀도 모델로 같은 실험을 해야 하는데 이 맥에서는 불가능합니다. 가설로만 남겨둡니다.
참고로 논문을 보면 공식 평가는 A100 16장으로 4일이 걸렸다고 합니다. 단일 맥에서 재현할 규모가 애초에 아니었던 겁니다.
그래서 업무에 쓸 수 있나
처음 질문으로 돌아오면 이렇습니다.
문서 분류나 한국 문화 맥락을 읽는 지식형 작업 같은 것들은 4bit로도 쓸 만합니다. 벤치 수치가 그렇게 말하고 있고, 문항을 직접 보면서도 그런 느낌이었어요.
추론이 필요한 것들은 좀 다릅니다. 이 모델의 성능은 thinking에서 나오는데, 4bit에서 thinking이 느리고 불안정합니다. 업무에 붙이려면 thinking을 켜야 하고, thinking budget으로 답이 안 나오는 건 막을 수 있지만 점수가 2048 근처에서 꺾이니 문제 하나에 3분을 쓰고 0.40을 얻는 게 현실적인 선입니다. 이건 원본 정밀도로 검증해야 하는데 로컬에서는 방법이 없어요.
시간 얘기에는 단서를 하나 달아야 합니다. 여기 나온 문항당 3분, 6분은 M4 Pro에서 mlx_lm으로 요청을 하나씩 순서대로 처리한 시간이에요. 실제 서비스는 vLLM 같은 서빙 엔진이 continuous batching으로 요청 수십 개를 한 번에 돌리고, LMCache 같은 것들이 KV cache를 저장해뒀다가 같은 프롬프트 앞부분을 다시 계산하지 않게 해줍니다. 그러니 처리량 기준으로는 이 글의 숫자보다 훨씬 빠르고, 벤치 자체도 문항을 배치로 던졌으면 세 시간이 아니라 몇십 분에 끝났을 겁니다.
다만 요청 하나가 끝나는 시간은 다른 문제예요. thinking이 4,000토큰을 뽑는 동안 사용자는 기다려야 하고, 그 속도는 서빙 엔진이 아니라 하드웨어가 정합니다. 이 맥은 초당 9.6토큰인데 A100이면 그 몇 배가 나오니까, 같은 4,096 예산이라도 서버에서는 6분이 아니라 2분 안쪽이 되는 겁니다. 결국에는 느리다는 건 이 환경의 이야기이고 인프라를 갖추면 달라지지만, 0.43이라는 상한은 인프라를 바꿔도 그대로입니다.
여기서 하나 짚을 게 있습니다. loglikelihood 0.42랑 thinking 4096의 0.43이 같다는 건, 이 모델이 4,096토큰을 생각해도 확률만 읽은 것과 같은 답을 낸다는 뜻이에요. 사고가 더해주는 게 없는 겁니다. 그러니 선택지가 정해진 작업, 그러니까 문서를 카테고리 몇 개 중 하나로 분류한다거나 의도를 골라내는 것들이라면 thinking을 켤 이유가 없습니다. logprobs 비교가 같은 정확도를 180배 빠르게 줍니다.
다만 두 가지는 조심해야 합니다. KMMLU-Pro가 아는 걸 꺼내는 문제라서 사고가 소용없었을 가능성이 크고, 다단계 추론이 필요한 Ko-MuSR에서는 loglikelihood가 2지선다에서 0.52로 찍는 수준이었으니 거기서는 뒤집힐 수 있습니다. 그리고 원본 정밀도는 thinking으로 0.549까지 가니까, 4bit에서 사고의 이득이 사라진 거라면 양자화가 그 몫을 깎았다는 얘기가 됩니다.
모델을 벤치하는 방법 자체는 이렇게 정리가 됩니다. 모델을 직접 로드하는 경로를 잡고, 객관식이면 chat template을 끄고, 생성 평가면 wired memory를 고정하고, 리더보드와 비교하려면 그쪽 프로토콜을 먼저 읽어야 합니다. 그리고 reasoning 모델이면 thinking을 켠 상태의 수치와 끈 상태의 수치가 완전히 다른 물건이라는 걸 알고 봐야 합니다.
가장 크게 배운 건 이겁니다. 벤치 수치는 그 프로토콜에서의 수치일 뿐이다. 같은 벤치 이름이어도 loglikelihood인지 생성인지, thinking을 켰는지, 프롬프트가 한국어인지 영어인지에 따라 숫자가 다 달라집니다. 리더보드 수치를 보고 이 모델 좋다고 판단하는 건 그 프로토콜과 그 하드웨어에서 좋다는 뜻이고, 내 환경에서는 내가 재봐야 압니다.
결국에는 벤치 수치를 믿을 게 아니라 벤치를 돌리는 법을 알아야 했던 거죠.
삽질에서 건진 것
장시간 벤치 산출물은 처음부터 영구 경로에 쓰세요. 임시 디렉토리에 두고 돌리다가 세션이 재시작되면서 결과랑 리포트가 한 번 통째로 날아갔습니다. ㅜ
주석
[1] EleutherAI, lm-evaluation-harness. https://github.com/EleutherAI/lm-evaluation-harness
[2] LM Studio, Open Responses API 발표. https://lmstudio.ai/blog/openresponses
[3] mlx_lm 0.31.3의 evaluate 서브커맨드. python3 -m mlx_lm evaluate --help 참조
[4] Hong et al., From KMMLU-Redux to Pro: A Professional Korean Benchmark Suite for LLM Evaluation. arXiv:2507.08924. 데이터셋은 LGAI-EXAONE/KMMLU-Pro (HF, gated)
[5] thunder-research-group/SNU_Ko-MuSR (HF, gated). 원본 MuSR의 한국어판