로컬 모델의 실제 성능을 테스트하기 위해 사용한 새로운 벤치마크
요약
본 글은 로컬 환경에서 대규모 언어 모델(LLM)의 실제 코딩 및 문제 해결 능력을 테스트하기 위해 설계된 벤치마크 경험을 공유합니다. C# 기반 라디오 스트리밍 플레이어 제작 프롬프트를 통해 Qwen 3.8 27B와 Qwen Next Flash 등 두 모델의 성능과 디버깅 과정을 비교 분석했습니다.
핵심 포인트
- LLM은 복잡한 코딩 작업에서 여전히 여러 번의 반복적인 수정 및 안내가 필요합니다.
- Qwen 3.8 27B는 코드 측면에서 우수했으나, 오디오 동기화 등 세부 구현에 어려움이 있었습니다.
- Qwen Next Flash는 TUI 레이아웃 구성 능력과 테스트 앱 생성 능력이 뛰어났습니다.
- 두 모델 모두 복잡한 시스템 통합(오디오/TUI)에서는 완벽하게 작동하지 않았습니다.
저는 이 벤치마크를 시작했는데, 모델의 능력을 테스트하는 좋은 방법인 것 같습니다. 때로는 아예 '나쁜 시드(bad seed)'가 나와서, 문제가 시작되기도 전에 모델이 해결하려고 하다가 완전히 엉뚱한 방향으로 빠지기도 합니다. 프롬프트는 단순히 다음과 같았습니다. "C#로 인터넷 라디오 스트리밍 플레이어를 만들어 주세요. <라디오 방송국 이름/기타>을 스트리밍해야 합니다. 단일 스트림만 실행하면 됩니다. UI는 TUI(Text User Interface)를 가진 콘솔 앱이어야 합니다. UI 상단에는 라디오 방송국의 제목이 표시되어야 하고, 볼륨 바 인디케이터가 있는 볼륨 제어 기능과 신호에 맞춰 애니메이션되는 동적 오디오 레벨 미터도 포함해야 합니다." 이 프롬프트는 Qwen 모델들을 상당히 어렵게 만들었습니다. 64GB RAM을 갖춘 RTX 3090 시스템에서 Unsloth의 Q4_K_M GGUF를 사용한 Qwen 3.8 27B (8비트 KV Cache, Llama.cpp(llama-cpp-windows-manager)에서 실행, 119K 컨텍스트, MTP 활성화(레벨 2?))로 테스트했을 때 평균 70tok/sec이었습니다. 솔직히 말해서, 27B 모델이 코드 측면에서는 Qwen Next Flash보다 더 나은 작업을 수행했다고 할 수 있습니다. 심지어 몇 번의 대화 만에 올바른 스트리밍 URL을 찾아내고 코드를 짜기 시작했습니다. 하지만 소리가 제대로 재생되게 하려면 여러 번 돌아가야 했고, 오디오 레벨 미터가 정확하게 작동하고 오디오에 빠르게 반응하며 동기화되도록 하는 데는 훨씬 더 많이 수정해야 했습니다. 모델은 재생을 위해 NAudio를 사용하기로 결정했고 TUI를 위해 다른 라이브러리를 사용했습니다. 한동안 소리가 제대로 재생되게 하려고 계속 순환하는 모습을 보였고, 결국 제가 NAudio의 더 간단한 API(URL이 단일 매개변수인)를 사용하여 스트림을 직접 재생하도록 안내하자 상황이 정상화되기 시작했습니다. 하지만 Qwen 3.8 27B는 포기하지 않는다는 점은 분명했고, 무언가가 올바르게 작동하는지 확인하기 위한 테스트 '프로브(probe)' 앱을 만드는 데 매우 능숙했으며 디버깅 기술도 뛰어났습니다.
Qwen 3.8 Next Flash, IQ3_XXS, 8 bit KV Cache를 Strata에서 128K 컨텍스트로 실행하고 평균 120tok/sec의 성능을 보였습니다: 이 프롬프트를 처음 실행했을 때 올바른 스트리밍 URL MP3 링크를 찾는 데 토큰의 절반 이상을 소모했습니다. 그래서 그 세션을 취소하고 링크를 직접 전달해 주었습니다. 이번에는 훨씬 더 잘 작동하기 시작했지만, 단순히 API 호출을 사용하여 MP3 스트림을 재생하는 대신 MP3 패킷을 가져와 스스로 디코딩(어떻게 했는지는 모르지만, 코드상으로는 그렇게 보였고 여전히 NAudio를 사용합니다)하기로 결정했습니다. 이 때문에 자연스럽게 더 많은 실수가 발생하여 소리가 끊기거나 간격 없이 재생되기까지 꽤 여러 차례의 시도가 필요했습니다. 그리고 Qwen 27b와 마찬가지로 오디오 레벨 미터가 올바르게 작동하도록 하려면 몇 번의 반복 작업이 필요했습니다. 한 가지 큰 장점은 처음부터 TUI 레이아웃을 구성하는 능력이 훨씬 좋았다는 것입니다. Qwen Next Flash 역시 NAudio를 사용했지만, 더 복잡한 API 호출을 사용하여 MP3 스트림 데이터를 자체적으로 포워딩(저는 코드를 잠깐만 봤습니다)했습니다. 콘솔 TUI용 라이브러리를 사용하지 않았습니다. 그 부분이 정확히 어떻게 작동하는지는 모르고 깊이 있게 검토하지는 못했지만, TUI가 훌륭하고 레이아웃도 처음부터 좋았다고 말할 수 있습니다. 하지만 오디오 레벨 미터는 여전히 왔다 갔다 하며 수정해야 했습니다. 제 생각에는 아직 소리와 100% 동기화되지는 않았습니다. 다시 한번 Qwen Next Flash는 문제 해결과 작동 여부를 확인하기 위한 작은 테스트 앱을 만드는 데 탁월한 능력을 보여주었습니다. 두 Qwen 모델 모두 새로운 디렉토리에서 처음부터 제대로 작동하는 스트리밍 플레이어와 TUI를 구현하는 데 최소 2시간이 걸렸습니다. 그리고 단일 스테이션만 재생해야 했습니다. 저는 이 '스트림 재생 방법'에 대한 지식이 모델 능력을 테스트하기에 충분히 복잡하다고 생각합니다. 두 Qwen 모델은 사용되는 라이브러리의 소스 코드를 GIT에서 다운로드하려고 시도하는 것까지 나아가기도 했고, 그것이 작동하지 않으면 둘 다 리플렉션(reflection)을 사용하여 해당 라이브러리에서 사용할 올바른 API를 찾는 것을 시도했습니다.
꽤 보기 좋았습니다. 그들은 단순히 계속 작동하고 가능한 한 많이 시도했습니다. GPT 6.1 Sol (높은 추론): (직장에서 이 프롬프트를 사용해 보았습니다) 이것은 WPF UI 앱과 C# 재생 엔진을 제공하는 원샷(one-shot)으로 프롬프트를 처리했으며, 다른 스테이션이나 즐겨찾기 등을 검색할 수 있는 전체 검색 기능까지 포함했습니다. 그리고 상자에서 바로 작동하며 100% 정확합니다. 정말 인상적이었습니다. Sol은 앱을 만드는 데 약 20분이 걸렸고 69센트가 들었습니다. /u/Perfect-Campaign9551 제출 [링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 Reddit AI Engineering의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기