매일 아침, 어제의 AI를 한 통으로 정리해 보내드립니다메일로 받아보기

METAL LAB

큐원3.8 27B, 뛰어나지만 기본값이 '과잉 사고'

사이먼 윌리슨 리뷰, 원 하나 그리는데도 xhigh 추론으로 수 분 낭비

자전거를 타는 펠리컨 캐릭터가 해변 도로를 달리는 일러스트

이미지: Hacker News (200↑)

요약

  • 알리바바 큐원랩의 270억 파라미터 모델 Qwen3.8 27B가 기본 추론 강도를 xhigh로 설정해 간단한 요청에도 과도하게 사고한다는 리뷰가 나왔다
  • 펠리컨 자전거 SVG 테스트에서 추론을 켠 경우 21분과 22,276개 추론 토큰이 들었지만 끈 경우 137초 만에 끝났다
  • 128GB 맥북 프로와 엔비디아 DGX Spark에서 실행한 테스트에서 코딩 에이전트 연동과 이미지 바운딩 박스 작업은 준수한 결과를 보였다
원문 영상
모델명
Qwen3.8 27B (알리바바 큐원랩, Apache 2.0 라이선스)
전작
Qwen3.6 27B
기본 추론 강도
xhigh (큐원 공식 문서 명시)
펠리컨 SVG 소요 시간(추론 켬)
21분, 추론 토큰 22,276개, 출력 토큰 3,223개
펠리컨 SVG 소요 시간(추론 끔)
137초, 출력 토큰 3,715개
테스트 하드웨어
128GB M5 Max 맥북 프로, 엔비디아 DGX Spark
실행 환경
LM Studio, 17GB Q4_K_M 양자화 빌드, llama-server

21분짜리 펠리컨 한 마리

사이먼 윌리슨이 로컬 LLM을 테스트할 때 늘 쓰는 질문이 있다. "자전거를 타는 펠리컨을 SVG로 그려달라"는 것이다. 큐원3.8 27B에게 이 질문을 던졌더니 답이 나오기까지 21분이 걸렸다. 모델은 22,276개의 추론 토큰을 소모한 뒤에야 겨우 3,223개 토큰짜리 SVG를 내놨다. 결과물 자체는 로컬에서 돌아가는 모델 중 가장 정교한 펠리컨 SVG라고 할 만큼 훌륭했지만, 그 완성도를 위해 지불한 시간이 문제였다.

큐원3.8 27B는 어떤 모델인가

Qwen3.8 27B는 알리바바 큐원(Qwen) 연구소가 아파치 2.0 라이선스로 공개한 270억 파라미터 규모의 비전 지원 언어 모델이다. 27B — 게이밍용 노트북 한 대에서도 무리 없이 돌릴 수 있는 크기 — 급 모델 가운데 전작인 Qwen3.6 27B가 좋은 평가를 받았던 터라 후속작에 관심이 쏠렸다. 알리바바가 공개한 자체 벤치마크에서는 전작은 물론, 한때 큐원 라인업 최상위였던 폐쇄형 모델 Qwen3.7-Plus까지 앞서는 점수가 나왔다고 알려졌다. 다만 이 수치는 알리바바가 직접 발표한 것이라 독립 기관의 검증은 아직 확인되지 않았다.

문제는 '생각을 너무 많이 하는' 기본값

윌리슨은 128GB 메모리를 탑재한 M5 Max 맥북 프로와 엔비디아 DGX Spark 두 기기에서 LM Studio를 돌려 이 모델을 테스트했다. 실제로 실행한 빌드는 디스크 용량 17GB짜리 Q4_K_M 양자화 버전이었고, DGX Spark에서는 llama-server를 직접 띄워보기도 했다.

문제의 원인은 모델 설정에 있었다. 큐원 공식 문서는 이 모델의 reasoning_effort 추론 강도 기본값을 "xhigh"로 안내하고 있고, LM Studio가 배포한 GGUF 빌드도 이 값을 그대로 물려받았다. 여기에 LM Studio의 기본 컨텍스트 길이 제한인 8,192 토큰이 겹치면서, 모델은 "원을 그려달라"는 아주 단순한 요청에도 사고를 위해 남은 토큰을 전부 소진해버렸다. 윌리슨은 컨텍스트를 모델이 지원하는 최대치인 262,144 토큰으로 늘리고서야 이 문제를 피할 수 있었다.

원 그리기 테스트가 이 현상을 가장 잘 보여준다. xhigh 기본값이 켜진 상태에서 모델의 추론 과정은 "The user is asking for an SVG drawing of a circle"(사용자는 원의 SVG를 요청하고 있다)로 시작해, 동심원과 컴퍼스 눈금, 은은한 애니메이션까지 스스로 덧붙이며 수 분을 흘려보냈다. 결과물은 아름다웠지만 애초에 요청한 '원 하나'는 아니었다.

추론 켬/끔 비교

구분추론 켬(xhigh 기본값)추론 끔
소요 시간21분137초(약 2분 17초)
추론 토큰22,276개해당 없음
출력 토큰3,223개3,715개

추론을 끈 버전은 원하는 그림을 정확히 원샷으로 만들지는 못했지만, 2분 안에 답을 내놨다. 반대로 바운딩 박스 테스트 — 사진 속 물체 위치를 좌표로 짚어내는 비전 과제 — 에서는 추론을 켰을 때 펠리컨 사진 위 박스 위치가 정확히 맞아떨어졌고, 꺼두면 박스 위치가 어긋나는 결과가 나왔다. 즉 추론이 무의미한 낭비만은 아니라는 뜻이다.

코딩 에이전트로도 써봤다

윌리슨은 시스템 프롬프트가 짧아 작은 모델에 유리한 에이전트 도구 'Pi'를 큐원3.8 27B와 연결했다. DGX Spark에서 LM Studio로 모델을 띄운 뒤 tailscale serve로 공유하고, ~/.pi/agent/models.json 설정 파일에 이를 등록해 실제 개발 폴더에서 작업을 시켰다. 모델은 여러 파일을 오가며 추론과 도구 호출을 반복한 끝에 쓸 만한 답을 내놨고, 이어서 대화 로그 파일(JSONL)을 마크다운으로 변환하는 파이썬 스크립트까지 직접 작성해 실행에 성공했다. 17GB짜리 로컬 모델이 코드 작성, 도구 호출, 이미지 주석 작업까지 실제 업무에 필요한 기능을 대부분 소화한 셈이다.

에디터의 시선

이 리뷰가 흥미로운 이유는 성능 자랑이 아니라 '기본값의 함정'을 정확히 짚었다는 데 있다. 알리바바는 추론 강도를 조절할 수 있는 reasoning_effort 옵션을 공식으로 지원한다고 문서에 명시해뒀다. 그런데 정작 배포된 GGUF 빌드의 기본값이 가장 무거운 xhigh였고, 이를 내려받아 쓰는 일반 사용자 대부분은 이 사실을 모른 채 원 하나 그리는 데 수 분을 태우게 된다. 오픈소스 모델의 발목을 잡는 건 모델 자체의 실력이 아니라 배포 단계의 기본 설정인 경우가 의외로 많다.

27B급 로컬 모델을 실무에 붙여 본 경험에 비춰보면 결론은 늘 비슷하다 — 추론형 모델을 그대로 켜두면 간단한 작업에서 체감 속도가 떨어지고, 복잡한 비전·코딩 작업에서는 오히려 추론이 정답률을 끌어올린다. 즉 작업 종류에 따라 추론 강도를 그때그때 낮추거나 끄는 습관이 필수다. 지난 8월 초 공개된 이후 큐원3.8 계열이 허깅페이스 트렌딩과 로컬 추론 순위 상단을 차지해온 흐름도 이런 유연성과 무관하지 않다.

실무 관점에서 보면 이 모델은 개인 노트북이나 소형 워크스테이션에서 코드 작성, 이미지 주석, 간단한 에이전트 작업을 돌리려는 팀에 시도해볼 가치가 있다. 다만 배포 전 컨텍스트 길이와 reasoning_effort 기본값을 반드시 확인하고 필요에 맞게 낮추는 작업이 선행돼야 한다. 이 조정 없이 그대로 서비스에 붙이면 응답 시간 지연으로 이어질 수 있다.

앞으로 몇 주 안에 LM Studio나 Ollama 같은 배포 도구들이 이런 지적을 반영해 기본 reasoning_effort 값을 낮추거나 사용자에게 명시적으로 안내하는 방향으로 업데이트를 낼 가능성이 크다. 동시에 독립 벤치마크 기관들이 큐원3.8 27B의 자체 발표 점수를 검증하는 결과도 곧 나올 것으로 예상된다.