Qwen 3.8 모델 3개에 최근 AtCoder 문제 풀이 요청 및 사고 노력(thinking effort) 비교
요약
본 글은 Qwen 3.8을 포함한 여러 LLM 후보 모델들을 대상으로 AtCoder 문제를 활용하여 자체 미니 벤치마크를 구축하고 성능을 비교 분석했습니다. 특히 '사고 노력(thinking effort)'이 모델의 문제 해결 능력에 미치는 영향을 중점적으로 테스트했습니다. 분석 결과, 사고 노력이 모델 성능 향상에 큰 의미를 주지 못했으며, 오히려 '사고 노력 없음' 설정에서 신뢰성 있는 성능 저하가 관찰되었습니다. 따라서 속도와 정확성 중 어떤 것이 더 중요한지에 따라 적합한 모델을 선택해야 함을 시사합니다.
핵심 포인트
- 사고 노력이 문제 해결 능력 향상에 큰 영향을 주지 않음.
- ‘사고 노력 없음’ 설정에서 성능 저하가 가장 두드러짐 (DNF, ERR 증가).
- Flash는 빠르나 부정확할 수 있어 속도 우선 시 고려 가능.
- 27B 모델은 모든 난이도 구간에서 비교적 평탄한 성능을 보임.
저는 일상적으로 사용할 모델을 결정하는 중이었는데, 어떤 것을 선택해야 할지 명확하지 않았습니다. 저는 5060ti 16GB를 가지고 있어서 다음 후보들을 골랐고, 이 모델들은 제 하드웨어에서 합리적인 속도로 작동하는 것 같습니다: Strata Flash Next IQ3_S GSQ-RCO (Swift 1.5), Strata 27B IQS_3 GSQ-RCO (Strata), 그리고 llama.cpp를 사용한 Strata 27B IQS_3 GSQ-RCO입니다. 또한 사고 노력(thinking effort)이 모델 성능에 어떻게 영향을 미치는지 이해하고 싶어서, 사용 가능한 모든 4가지 사고 노력(없음, 낮음, 중간, 매우 높음)을 스윕(sweep)의 일부로 포함했습니다.
저는 AtCoder 문제를 테스트 데이터로 사용하여 자체적인 미니 벤치마크를 구축했고, LiveCodeBench를 테스트 하네스(test harness)의 기반으로 삼았습니다. 모델들이 학습 과정에서 본 문제가 아니도록 지난 30일간의 문제만 테스트 세트로 골랐습니다. 그 결과 다양한 난이도의 14개 문제를 테스트 세트에 포함하게 되었습니다. 모든 테스트는 사고 예산(thinking budget)을 32k 토큰으로 제한하여 실행되었습니다.
하드웨어: AMD 7945HX CPU, DDR5 5200 RAM 64GB 및 5060ti 16GB. 소프트웨어: OS - Arch Linux. llama.cpp: build 11149, 140k context, Strata - 0.1.38 (128k context).
모든 테스트를 실행하는 데 거의 11시간이 걸렸습니다. CAP+DNF burn은 해결되지 않은 문제에 소요된 시간입니다.
https://preview.redd.it/rf85frufznuh1.png?width=893&format=png&auto=webp&s=7c03164f7b605e9973a6aaae7f22229dbdf15764
여기에 요약 표가 있습니다: https://preview.redd.it/wojizpqeunuh1.png?width=845&format=png&auto=webp&s=e732e20d69d2abd6cfe47159b4cff3ef92a3f082
범례: problem - AtCoder의 문제 ID, pts - 난이도 점수 (AtCoder가 각 문제에 부여), low, med, xhi, non - 노력 수준, CAP - 모델이 32K 사고 제한에 도달함, DNF - 코드가 생성되지 않음, ERR - 코드는 생성되었으나 예상 결과와 일치하지 않음. 나머지 셀은 예상 결과가 반환된 경우의 초 단위 모델 실행 시간을 나타냅니다.
결과 해석: 이 벤치마크에서 사고 노력이 큰 의미를 가지지는 않습니다. 세 모델 모두 낮은 점수 대비 ±2 문제 범위 내에서 최고점을 기록하며, 어떤 모델도 low → med → xhi로 단조롭게 성능이 향상되지 않았습니다.
Flash는 med(11)에서, Swift는 xhi(10)에서 최고점을 기록했지만, med에서 3개의 ERR이 발생했습니다. 27b는 모든 구간에서 10으로 평탄합니다. '사고 노력(thinking effort)'을 사용하지 않는 설정만이 신뢰성 있게 성능 저하를 일으키는데, 이는 특정 방식으로 나타납니다: none에서는 DNF가만 나타나며 (총 4개, 모두 Flash/Swift), ERR이 급증합니다 (27b는 0→2, Flash는 0→2, Swift는 0→4). 사고 채널 없이 모델들은 코드 경계(code fence)를 건너뛰거나 잘못된 코드를 작성합니다. 노력을 높이는 것은 주로 CAP-out을 구매할 뿐, 해결책 자체를 제공하지는 않습니다. Flash는 4→3→5 CAPs로 변화하고, Swift는 3→3→4, 27b는 3→4→4로 변화하는 동안 시간이 낮은 수준에서 xhi까지 33–57% 증가합니다. 추가적인 사고 토큰은 모델이 어차피 실패할 문제에 사용됩니다. 최종 평가는 다음과 같습니다: Swift는 빠르지만 부정확하며, 속도가 정확성보다 더 중요하다면 사용할 수 있습니다. 27B는 신뢰성이 높지만 매우 느립니다. Flash가 더 많은 문제를 해결했고 더 빨랐기 때문에, 저는 27B를 사용할 이유를 찾지 못했습니다. Flash IQ3_S는 속도와 정확성 면에서 훌륭한 절충안인 것 같습니다. 게다가, 27B보다 중간 노력(medium effort) 수준에서 한 문제가 더 많다는 것을 발견했습니다. 또한 일상적인 사용 중 Q3 quant Flash가 27B보다 더 똑똑해 보이며 때로는 27B가 놓친 통찰력을 보고한다는 것도 알아차렸습니다. 사고 노력 측면에서는, 계속해서 medium을 사용하고 medium이 막히면 xhigh로 전환할 생각입니다. 간단한 작업의 경우 '사고' 기능을 꺼보는 것도 시도해 볼 수 있습니다. 이 테스트의 한계점은 충분하지 않은 데이터 포인트가 있었고 모델 행동에 어느 정도 무작위성이 있기 때문에, 제시된 수치들은 참고만 해야 한다는 것을 이해합니다. 저는 이러한 테스트를 계속하고 훨씬 더 높은 사고 예산(thinking budget)을 가진 더 복잡한 문제로 좁혀서 어떤 일이 일어나는지 지켜볼 것입니다. 여러분의 의견을 알려주시고 자신만의 관찰 내용을 공유해 주시기 바랍니다. submitted by /u/ColorsOfCosmos [link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 Reddit AI Engineering의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기