TL;DR
작성자는 Qwen 3.8 27B Instruct를 2× RTX 3090과 LM Studio에서 2,483개 항목으로 평가해 GSM8K 96.7%, MATH-500 86.4%, HumanEval 95.5%, MBPP 80.0%를 얻었습니다. 핵심 문제는 reasoning이 토큰 예산을 모두 쓰고 종료되지 않는 소수 항목으로, 정상 종료 시 94~98%대였던 정답률이 정지 항목에서 크게 하락했습니다. HumanEval은 이어쓰기 유사도와 세 번의 반복 실행 결과 때문에 오염과 샘플링 변동을 고려해야 하며, 작성자는 MBPP 점수를 더 신뢰했습니다. 또한 prompt 누락, eval 차단, 들여쓰기 제거, 수식 검증기 오류가 모델이 아닌 하니스의 실패를 만들 수 있어 self-test와 실행 조건 기록이 필요하다고 정리했습니다.
주요 논점
소수의 추론 정지 항목을 별도 분리해야 전체 평균만으로는 보이지 않는 성능 붕괴를 찾을 수 있다는 입장입니다.
벤치마크 점수보다 실행 조건, 반복 횟수, 오염 검사, 하니스 검증을 함께 공개해야 결과를 비교할 수 있다는 입장입니다.
HumanEval의 높은 점수는 데이터 오염과 단일 실행 변동성 때문에 조심해서 해석해야 하지만, 이어쓰기 검사는 암기를 확정하지 못한다는 제한도 함께 남아 있습니다.
합의점 vs 논쟁점
합의점
- Qwen 3.8의 reasoning이 정상 종료되는 항목과 토큰 예산을 소진하는 항목 사이에 큰 성능 격차가 있습니다. 이 차이는 GSM8K, MATH-500, ACT에서 같은 방향으로 반복됐습니다. 따라서 로컬 평가에서는 평균 점수와 함께 정지 여부별 결과를 기록할 필요가 있습니다.
- 평가 하니스의 작은 구현 오류가 모델의 실패처럼 기록될 수 있습니다. helper prompt 누락, 코드 들여쓰기 손상, 과도한 안전 차단, 수식 검증기의 플랫폼 오류가 실제 답안의 실행과 채점을 방해했습니다. self-test와 독립 프로세스 실행이 점수 산출 과정에 필요합니다.
논쟁점
- HumanEval 95.5%를 학습 데이터 오염 때문에 얼마나 할인해야 하는지는 확정되지 않았습니다. 특정 continuation의 높은 유사도와 기준선 대비 +0.307의 차이는 경고 신호지만, prefix-conditioning이 이름과 공통 구조를 재사용하게 만드는 효과도 포함합니다. 작성자는 그래서 HumanEval을 가장 신뢰하기 어려운 수치로 보았지만 오염 비율을 정량적으로 확정하지는 않았습니다.
- thinking을 끈 fallback이 평가를 더 현실적으로 만드는지, 아니면 모델의 추론 실패를 감추는지는 해석의 여지가 있습니다. 이 방식은 reasoning_content만 소진하고 답을 내지 않는 요청을 빈 결과로 남기지 않지만, MATH-500의 정지 항목에서는 정답률이 6.7%에 그쳤습니다. 따라서 fallback 결과를 정상 reasoning 결과와 합치면 실패 원인이 평균 점수에 묻힐 수 있습니다.
실용적 조언
- 로컬 평가에서는 전체 정답률만 저장하지 말고 reasoning이 정상 종료했는지와 fallback이 발생했는지를 항목별로 기록해야 합니다. 이 글의 측정에서는 GSM8K 정지 항목이 전체 실행 시간 245분 중 60분을 차지하면서도 거의 기여하지 않았습니다. 시간 초과와 정답률을 함께 보면 운영상 병목과 품질 저하를 동시에 확인할 수 있습니다.
- HumanEval처럼 한 번의 실행 결과가 크게 흔들리는 벤치마크는 temperature 0.2에서 여러 차례 실행해 평균과 변동폭을 함께 기록해야 합니다. 글에서는 164개 항목을 세 번 실행한 결과가 94.5%, 97.6%, 94.5%로 나타났고 평균은 95.5%였습니다. 모델 간 1점 차이를 비교하려면 이 정도 샘플링 변동을 먼저 고려해야 합니다.
- 코드 평가 하니스에는 데이터셋 prompt와 helper 정의를 항상 포함하고, 모델이 반환한 함수 본문의 선행 공백을 보존해야 합니다. 실행 환경은 임시 디렉터리와 별도 프로세스, timeout을 사용하되 문제 풀이에 필요한 eval까지 일괄 차단하지 않아야 합니다. 수학 채점은 플랫폼별 검증기 동작을 self-test로 확인하고, 필요하면 SymPy 등가성 검사를 별도로 구현해야 합니다.
- LM Studio 로컬 실행에서는 문서에 적힌 설정이 실제로 적용됐는지 확인해야 합니다. 글에서는 `chat_template_kwargs: {"enable_thinking": false}`가 효과가 없었고 `reasoning_effort: "none"`이 작동했으며, `lms load`가 지정한 quant를 선택하지 못해 Python SDK의 `handle.get_info().model_key`로 모델 키를 검증했습니다. 스트리밍 응답을 직접 처리할 때는 `requests`의 기본 인코딩으로 UTF-8이 깨질 수 있어 `r.encoding = "utf-8"`을 지정해야 합니다.
섹션별 상세
용어 해설
- 추론 정지(Reasoning Stall)
- — Reasoning 모델이 답변을 생성하지 못한 채 reasoning_content에서 토큰 예산을 모두 소진하는 현상입니다. 이 글에서는 정지한 항목을 thinking 없이 다시 요청해 빈 답변을 피했지만, 어려운 수학 문제에서는 정답률이 크게 떨어지는 결과가 확인됐습니다.
- 벤치마크 오염(Contamination)
- — 평가 데이터가 모델 학습 자료에 포함되어 실제 추론 능력보다 높은 점수를 내는 문제입니다. 글에서는 일부 항목의 이어쓰기 유사도와 서로 다른 항목의 공통 구조에서 생기는 기준선을 비교해 HumanEval 점수의 신뢰도를 따졌습니다.
- SymPy 등가성 검사(SymPy Equivalence)
- — 수학 답안을 문자열이 아니라 SymPy 식으로 변환한 뒤 두 식이 같은 값을 나타내는지 확인하는 검증 방식입니다. 기존 math_verify의 오류를 피하기 위해 작성자가 직접 정규화기와 23개 자기 테스트를 구현했습니다.
- 샘플링 노이즈(Sampling Noise)
- — 같은 벤치마크라도 생성 온도와 무작위 샘플에 따라 점수가 달라지는 변동입니다. HumanEval을 temperature 0.2에서 세 번 실행하자 94.5%, 97.6%, 94.5%가 나와 단일 실행의 1점 차이를 과대해석하기 어렵게 했습니다.
코드 예제
reasoning_effort: "none"LM Studio에서 Qwen 3.8의 thinking을 끄는 데 사용한 설정입니다.
handle.get_info().model_keyLM Studio Python SDK에서 실제 로드된 모델 키를 확인하는 코드입니다.
r.encoding = "utf-8"스트리밍 SSE 응답의 문자 인코딩을 UTF-8로 지정하는 코드입니다.
언급된 도구
Qwen 3.8 27B Instruct의 GGUF 모델을 로컬 GPU에서 실행하고 평가했습니다.
실제로 로드된 모델 키를 `handle.get_info().model_key`로 검증하는 Python SDK입니다.
수학 답안의 식을 정규화하고 등가성을 판정하는 검증 도구로 사용했습니다.
Windows와 Python 3.14 환경에서 발생한 multiprocessing 및 분수 표기 오류의 원인이 된 수학 채점 도구입니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
