RTX 3090을 사용한 로컬 벤치마크: Qwen3.6 27b 대 Ornith
요약
RTX 3090 환경에서 Qwen3.6 27b, Gemma4 26B, Ornith1.0 35B 모델을 대상으로 로컬 벤치마크를 수행한 결과입니다. inspect-ai를 활용해 일반 지식, 추론, 코딩 성능을 비교 분석했습니다.
핵심 포인트
- Qwen3.6 27b가 대부분의 지식 및 추론 벤치마크에서 우수한 성능을 보임
- Ornith1.0 35B는 코딩 및 에이전트 작업에서 기대보다 낮은 성능 기록
- 로컬 환경에서 다양한 벤치마크를 실행할 때 발생하는 타임아웃 및 기술적 어려움 공유
- Gemma4 26B는 MMLU 등 특정 지표에서 상대적으로 낮은 점수 기록
여러분, 안녕하세요. 저는 각 새로운 모델(또는 파인튜닝된 모델)이 얼마나 좋은지 가늠하는 것이 얼마나 어려운지에 좌절감을 느껴왔습니다. 그리고 우리는 종종 의존하게 되는 일회성 '자전거를 타는 펠리컨 그림 그리기' 같은 테스트에 만족하지 못했습니다. 제 RTX 3090에서 로컬로 실행할 수 있는 새로운 모델이나 모델 변형은, 그것을 만든 사람들 외에는 제대로 된 벤치마크 커버리지를 얻는 경우가 거의 없습니다. 최근 저는 Ornith 35b가 Qwen3.6 27b와 어떻게 비교되는지 보고 싶었습니다.
그래서 inspect-ai의 기능과 그들의 inspect-evals 패키지에 있는 여러 표준 벤치마크를 가지고 이것저것 만져보았습니다. 새로운 모델에 대한 전체 벤치마크 세트를 하룻밤 사이에 실행하고, 아침에 전반적인 비교 결과를 알고 싶습니다. 아직은 그 단계는 아니지만, 지금까지 제가 실행한 Qwen3.6 27b (Q4_K_M), Gemma4 26B A4B QAT (Q4_0), 그리고 Ornith1.0 35B MoE (Q4_K_M)을 비교하는 벤치마크를 공유하고 싶었습니다. 현재는 LM Studio에서 실행하고 있기 때문에, Ornith를 제외한 나머지 모델들은 lmstudio-community가 제공한 모델들로 아래의 벤치마크를 실행했습니다.
요약하자면 (TLDR)
저는 세 모델 모두에 대해 제한된 수의 샘플(100개)과 공격적인 한계를 설정하여 모든 벤치마크를 테스트했습니다. 저는 Ornith가 코딩 작업에서는 Qwen3.6 27b만큼 거의 좋을 것이라 예상했지만, 그렇지 못했습니다. 또한 파인튜닝 모델로서 일반 지식 및 접지(grounding) 측면에서는 더 나쁠 것으로 예상했습니다. 하지만 최종적인 그림은 그리 명확하지 않았습니다. 경우의 절반이 채 안 되는 곳에서는 Qwen 27b보다 좋거나 같았고, 나머지 경우에는 더 나빴습니다. 비록 에이전트적 작업에서 최고라고 주장하지만, 저는 대부분의 에이전트 벤치마크를 성공적으로 실행하는 데 어려움을 겪었습니다.
각 벤치마크별 세부 사항과 몇 가지 참고 사항을 아래에 제공합니다. 그리고 이러한 벤치마크들을 로컬로 실행하려고 시도했던 것이 얼마나 고통스러웠는지에 대한 저의 생각도 함께 공유합니다.
일반 지식 및 추론 (General Knowledge and Reasoning)
- Qwen은 6개 벤치마크 중 4개에서 최고(또는 공동 최고) 점수를 받았습니다.
- Ornith는 6개 벤치마크 중 3개에서 최고(또는 공동 최고) 점수를 받았습니다.
- MMLU 벤치마크의 경우 Gemma가 좋지 않았던 것 같습니다.
많은 경우에 타임아웃(timeout)이 발생했지만, 그 원인은 아직 파악하지 못했습니다. 무한 루프(endlessly looping)에 빠졌을 수도 있고, 제가 태스크(tasks)를 구성한 방식과 관련이 있을 수도 있습니다. 이러한 사례에서 측정된 Gemma의 점수는 감안하여(take with a pinch of salt) 봐주시기 바랍니다.
정적 지식 및 추론 (Static knowledge and reasoning)
success, logs = eval_set(
tasks=[ gsm8k(), ifeval(), arc_easy(), arc_challenge(), mmlu_0_shot(cot=True), mmlu_5_shot(cot=True) ],
log_dir="logs-know",
**default_config,
max_tokens=20000,
)
| Benchmark | Gemma4 26b | Qwen3.6 27b | Ornith1.0 35b |
|---|---|---|---|
| gsm8k | 0.93 | 0.96 | 0.9 |
| ifeval | 0.93 | 0.95 | 0.91 |
| arc_easy | 1.0 | 1.0 | 0.98 |
| arc_challenge | 0.97 | 0.97 | 0.98 |
| mmlu_0_shot | 0.54 | 0.88 | 0.91 |
| mmlu_5_shot | 0.5 | 0.88 | 0.88 |
그라운딩 및 회상 (Grounding and Recall)
이 부분에서는 Ornith가 앞서 나가지만, 건초더미 속 바늘 찾기 (Needle in a haystack, NIAH) 테스트는 최대 컨텍스트(max context)를 100,000으로 제한해야 했습니다. Qwen의 프롬프트 처리 시간(prompt processing times) 때문에 더 높은 컨텍스트에서 공정한 테스트를 수행하는 것이 지나치게 오래 걸렸기 때문입니다. 로컬 테스트를 위해 더 편리한 벤치마크를 찾거나, 단순히 더 많은 시간을 들여 다시 실행해야 합니다.
그라운딩 및 회상 (Grounding and recall)
success, logs = eval_set(
tasks=[ drop(), niah(max_context=100000), ],
log_dir="logs-ground",
**default_config,
max_tokens=40000,
)
| Benchmark | Gemma4 26b | Qwen3.6 27b | Ornith1.0 35b |
|---|---|---|---|
| drop | 0.932 | 0.947 | 0.952 |
| niah | 10.0 | 10.0 | 10.0 |
코드 생성 및 데이터 과학 (Code generation and data science)
이 부분은 제가 Ornith가 빛을 발할 것이라고 예상했던 영역입니다. 4개 태스크 중 2개에서 Qwen과 대등한 성적을 거두었지만, 모든 경우에서 Qwen이 가장 높은 점수를 기록했습니다. 특히 scicode 점수는 실망스러웠습니다. 여기서 Gemma보다 나았던 점 하나는, Gemma로 scicode를 작동시키기 위해서는 대부분의 샘플에서 무한 루프가 발생했기 때문에 매우 강력한 제한을 걸어야 했다는 것입니다. Ornith는 그런 문제가 없었습니다. 무한 루프 동작이 더 적었습니다.
코드 생성 및 데이터 과학 성공, logs = eval_set( tasks=[ ds1000(), class_eval(), scicode(), ifevalcode(samples_per_language=tasks_limit_per_eval // 10), # 10개 언어 ], log_dir="logs-code", **default_config, )
벤치마크 Gemma4 26b Qwen3.6 27b Ornith1.0 35b
DS-1000 0.34 0.66 0.48
class_eval 0.97 0.97 0.97
scicode 4.615 10.769 1.538
ifevalcode 0.03 0.00 0.03
참고 사항
솔직히 말해서, 이 테스트들을 실행하는 것은 약간 악몽 같았습니다. 특히 Gemma는 무한 루프를 도는 경향이 있었습니다. 모델이 영원히 실행되는 것을 막기 위해 매우 강력한 제한을 걸고 벤치마크를 재설정하여 다시 실행해야 했습니다. 또한, 일부 테스트에서는 프롬프트 처리 시간 (prompt processing time)이 특히 좋지 않았습니다. 이러한 설정 중 일부를 변경한다는 것은 다른 모델들과의 공정한 비교를 위해 벤치마크 전체를 처음부터 다시 실행해야 함을 의미했습니다.
저의 목표는 밤새 전체 테스트 세트를 실행하여 아침에 모델의 성능을 파악하는 것이었습니다. 하지만 실제로 Qwen3.6 27b의 경우, 단 100개의 샘플만으로 ifevalcode를 실행하는 데 18시간이 걸렸습니다. 제가 설정한 사항들은 다음과 같습니다.
각 벤치마크당 최대 100개 샘플.
루프를 방지하기 위한 최대 토큰 제한 (Max token limits). 일부 모델은 진정으로 더 큰 추론 블록 (reasoning blocks)이 필요한 것처럼 보였기 때문에, 이는 벤치마크마다 정말로 다르게 설정해야 했습니다.
처음에는 타임아웃 (timeouts)을 설정했지만, 이는 여러 샘플을 동시에 실행하는 동안 상황을 정말 엉망으로 만들었습니다. 하나의 무거운 작업이 모든 리소스를 점유하는 동안, 다른 작업은 시도조차 해보지 못한 채 타임아웃이 발생했습니다.
한 번에 1개의 작업, 최대 1개의 연결, 한 번에 1개의 샌드박스 (docker 인스턴스).
저는 이 설정들을 교체하고 제한 사항을 더 구체적으로 적용해 보려고 합니다. 샘플 셔플링 (sample shuffling, 모델 간 공유 시드 사용)을 추가하고, 일부 까다로운 테스트의 샘플 수를 줄일 예정입니다. inspect-ai의 eval_sets를 사용하면 중단된 테스트나 취소해야 했던 테스트를 이어서 진행할 수 있습니다. 하지만 실제로 벤치마크를 작동시키기 위해 설정을 변경해야 할 때는 전체 세트를 다시 실행해야만 했습니다.
더욱 신뢰할 수 있는 벤치마크 설정(benchmark setup)을 갖추게 되면 추가적인 내용을 게시할 수도 있습니다. 이 내용이 여러분에게 유용하기를 바랍니다.
제출자: /u/Aggressive_Aspect436
[링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기