Qwen 3.8 27B, 17GB에 담긴 실력보다 더 큰 문제는 ‘과한 생각’

17GB 파일 하나가 로컬 컴퓨터에서 코드를 쓰고, 도구를 호출하고, 이미지 속 객체의 경계 상자까지 정확히 찾는다. Qwen 3.8 27B가 흥미로운 이유는 대형 서버용 모델의 기능 묶음을 27B dense 모델에 담았기 때문이다. 동시에 실제 사용자는 benchmark 점수보다 더 현실적인 질문과 마주친다. 이 모델을 도대체 얼마나 오래 생각하게 둬야 할까.

Simon Willison은 128GB M5 Max MacBook Pro와 NVIDIA DGX Spark에서 LM Studio의 17GB Q4_K_M 양자화 빌드를 시험했다. Qwen 문서가 설명하는 기본 reasoning effort는 xhigh다. 복잡한 작업에는 도움이 될 수 있지만, 단순한 요청에서도 추론이 길어진다. 기본 8,192 token context는 금세 소진됐고, 최대 262,144로 늘린 뒤에야 실험을 계속할 수 있었다.

가장 선명한 사례는 자전거를 타는 펠리컨 SVG다. xhigh 설정에서는 22,276개의 reasoning token을 거쳐 3,223 token의 결과를 만드는 데 21분이 걸렸다. 그림의 자전거 구조와 펠리컨 자세는 로컬 모델 결과 중 특히 좋았지만, 같은 요청에서 reasoning을 끄면 2분 17초 만에 3,715 token을 출력했다. ‘원 하나를 SVG로 그려 달라’는 요청조차 몇 분 동안 확장해 화려한 애니메이션을 만든 사례는 과한 추론이 품질과 지연 사이의 조절 문제임을 보여준다.

추론을 줄이면 항상 나아질까

답은 단순하지 않다. 사진 속 펠리컨 두 마리의 경계 상자를 0~1000 좌표로 반환하는 비전 작업에서는 결과가 잘 맞았다. JSON 좌표를 이미지 위에 표시하는 작은 HTML 도구도 한 번의 지시로 만들었다. 반면 reasoning을 완전히 끈 버전은 경계 상자의 위치를 틀렸다. 긴 추론이 낭비인 순간도 있지만, 코딩 agent처럼 여러 파일을 읽고 도구를 이어 쓰는 작업에서는 정확도를 지탱하기도 한다.

커뮤니티 논점도 여기서 갈렸다. 한쪽은 소비자 하드웨어에서 이 정도 모델을 구동한다는 사실 자체를 가장 큰 변화로 봤다. 다른 쪽은 dense 모델의 느린 token 생성과 반복적인 자기 검토가 실사용 비용을 키운다고 지적했다. reasoning effort를 요청마다 낮추거나, 계획과 실행을 나눠 지시하거나, llama.cpp의 template과 MTP를 조정하는 구체적인 운용법도 공유됐다.

속도 개선 여지는 있다. Willison의 DGX Spark 비교에서는 Multi-Token Prediction을 켠 llama.cpp 설정이 LM Studio 기본 GGUF보다 약 72% 빨랐다. 그래도 일반적인 생성 속도는 초당 15~30 token 수준이었다. 결론은 ‘reasoning을 켜거나 끈다’가 아니라 작업에 맞춰 깊이를 조절하는 쪽이다. 짧은 변환과 단순 그림에는 낮은 effort를, 도구 호출과 장기 코딩에는 더 많은 여유를 주는 운용이 현실적이다.

Qwen 3.8 27B는 Apache 2.0 라이선스, 긴 context, vision, tool calling, code generation을 한 파일에 묶었다. 로컬 LLM의 기준선이 올라간 것은 분명하다. 이제 모델 선택만큼 중요한 것은 추론 예산을 다루는 인터페이스다. 원문 실험과 수치는 Simon Willison의 분석에서, 실제 운용 경험을 둘러싼 논의는 Hacker News 스레드에서 확인할 수 있다.