금요일의 대형 릴리스는 알리바바 Qwen 연구실이 만든 Apache 2.0 라이선스의 270억 파라미터 비전 지원 LLM인 Qwen 3.8 27B였다. 꽤 기대해 온 모델이다. 27B는 적당히 사양 좋은 노트북에서 돌리기에 최적의 크기이고, 이전 모델인 Qwen 3.6 27B도 인상적이었기 때문이다.

Qwen이 직접 공개한 이 모델의 벤치마크 결과는 눈길을 끈다. Qwen 3.6 27B는 물론, 올해 5월까지만 해도 모든 크기를 통틀어 Qwen 최강 모델 중 하나였던 비공개 가중치 모델 Qwen 3.7-Plus보다도 성능이 향상됐다고 한다. 독립적인 벤치마크에서 이 모델을 어떻게 평가할지 궁금하다.

나는 두 대의 머신에서 이 모델을 돌려봤다. 128GB M5 Max MacBook Pro와 NVIDIA DGX Spark다. 두 머신 모두 LM Studio와 17GB짜리 Q4_K_M 양자화 빌드를 사용했다. Spark에서는 llama-server를 직접 실행해 보기도 했다.

기본값인 extra high는 엄청난 오버씽킹을 초래한다

Qwen 문서는 이 모델이 추론 강도(reasoning effort) 기본값으로 xhigh를 사용한다고 설명하고, 내가 써본 LM Studio GGUF 역시 그 기본값을 그대로 유지한다:

Qwen 3.8은 추론 깊이를 조절하고 비용을 제어할 수 있는 reasoning_effort를 공식 지원합니다:

• xhigh (기본값): 철저한 분석이 필요한 복잡한 작업용
• medium: 정확도와 속도의 균형
• low: 속도와 비용 최적화를 위한 효율적 추론

이 기본값은 정말 웃기다. 특히 소비자용 하드웨어에서는 모델을 실행하는 좋은 방법이 절대 아니다. 나는 그 결과가 무척 재미있었다.

LM Studio의 기본 컨텍스트 제한인 8,192토큰 때문에 금방 문제가 생겼다. Qwen은 가장 평범한 문제에 대해서도 생각하느라 토큰을 전부 써버렸기 때문이다. 모델을 최대 컨텍스트 길이인 262,144로 로드하니 문제가 사라졌다.

늘린 컨텍스트 길이로 처음 시도해 얻은 자전거를 타는 펠리컨 SVG는 다음과 같다. 생성에 21분이 걸렸고, 3,223토큰의 출력을 만들기 위해 22,276개의 추론 토큰을 사용했다. 추론 과정은 여기에서 볼 수 있다.

이건 내가 로컬 머신에서 동작하는 모델로 생성해 본 펠리컨 SVG 중 단연 최고다. 게다가 이 Qwen은 꽤 작고, 디스크에서도 17GB짜리 파일 하나에 불과하다. 마음에 드는 점이 많다:

1. 자전거 프레임 형태가 올바르다
2. 자전거 양쪽에 다리가 하나씩 있다 — 그건 매우 드문 일이다
3. 펠리컨 주머니가 명확하고 잘 표현됐다
4. 날개가 뻗어 핸들바에 닿는다!
5. 움직임 선이 앞이 아니라 뒤에 있다
6. 취향 좋은 배경 — 멋진 태양, 구름, 언덕, 꽃과 풀이 있다.

21분을 기다릴 가치는 있었을까? 전혀 아니다.

추론을 끄고 같은 프롬프트를 실행한 결과는 다음과 같다 — 전체 기록은 여기. 이번에는 3,715토큰을 생성했고 137초, 즉 2분 남짓 걸렸다.

완벽을 기하기 위해 OpenRouter를 이용해 훨씬 더 큰 Qwen 3.8 2.4T-A95B(지난주 출시)에 같은 프롬프트를 넣어봤고, 이런 근사한 애니메이션 SVG를 얻었다:

xhigh 설정의 Qwen이 과하게 생각하는 경향이 있다고 말했는데, 실제로 얼마나 심할까?

훨씬 더 간단한 프롬프트로, 다시 기본값인 extra high 설정으로 시도해 봤다:

draw an svg of a circle

Qwen의 추론 과정은 이렇게 시작됐다:

사용자가 원 모양의 SVG 그림을 요청하고 있다. 간단한 요청이지만, 정성스럽게 만든 작품으로 만들고 싶다. 단순히 <circle>를 넘어서는 무언가를 만들어 보자. 개성 있는 단일 자체 완결형 SVG 파일 — 아마도 미묘한 애니메이션, 여러 겹의 링, 독특한 팔레트를 갖춘 기하학적 “원 연구” 같은 것.

범위를 정확히 유지하자. 사용자가 요청한 것은 원의 SVG다. 그러니 핵심은 원이다. 하지만 정성을 더할 수 있다. 동심원 가이드(컴퍼스로 그린 기하학 도면처럼), 눈금 표시, 메인 원에 부드러운 그라데이션 채우기, 절제된 주변 움직임(천천히 회전하는 점선 링, 맥동하는 빛). prefers-reduced-motion을 존중해야 할까? 그건 CSS 쪽이 더 맞다. SVG SMIL이나 SVG 내부 CSS로 처리하면 된다.

팔레트 옵션: 따뜻한 종이 위의 짙은 청록색 잉크? 아니면 미색 바탕에 네이비 제도선이 들어간 강렬한 주홍색 원 — 바우하우스/컴퍼스 드로잉 느낌. “기하학 연구” 룩으로 가보자. 차가운 슬레이트 배경, 아니면 밝은 종이 흰색? 크림-테라코타 조합만 아니면 종이 흰색도 괜찮다. [...]

몇 분 뒤 모델은 이런 정말 아름다운 원 애니메이션을 만들어냈는데, 내가 요청한 것과는 전혀 다른 것이었다!

강력히 권한다. 그 기본값은 무시하라. Qwen 3.8 27B는 처음에는 low나 아예 추론 없는 수준으로 실행하라. 훌륭한 모델이지만, 그 기본 설정은 시작하기에 정말 좋지 않다.

바운딩 박스를 아주 잘한다

비전 모델을 테스트하는 재미있는 방법 중 하나는 사진 속 물체 주변에 바운딩 박스를 얼마나 잘 반환하는지 보는 것이다. 이전 Qwen 모델들이 이 작업을 잘 해내는 것을 본 적이 있어, 펠리컨 주변에 바운딩 박스를 그리는 테스트를 해보기로 했다.

예전에 0-1000 스케일로 요청하면 좋은 결과가 나온 걸 본 적이 있다. 이렇게 시도해 봤다:

llm -a https://static.inaturalist.org/photos/714731804/large.jpg \
  -m lmstudio/qwen/qwen3.8-27b \
  'Return JSON bounding boxes for the pelicans in this photo, 0-1000 scale for each dimension'

추론 과정은 여기에 있으며, 결과는 다음과 같았다:

[
  {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
  {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

정말 완벽하게 들어맞는다. 사진 위에 렌더링된 박스는 다음과 같다:

바운딩 박스 레이블링 도구를 만들기

바운딩 박스를 시각화한 이미지는 Qwen 3.8 27B가 내 노트북에서 오프라인으로 만들어 준 새로운 커스텀 도구로 만든 것이다.

추론 강도를 낮추는 걸 깜빡해서 결과물이 엄청나게 과하게 설계됐지만, 이런 전체 인터페이스를 이 단일 프롬프트 하나로 만들어내는 데는 성공했다:

[
   {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
   {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

Build an HTML page which has an input box for accepting the URL to an image and a textarea for accepting the above style of JSON.

It appends the image to the page, measures its width and height, then treats the coords in the bbox_2d as scaled from 0-1000 and scales them against the actual width and height, then it renders labelled boxes over the image.

이 스크린샷은 내가 요청하지도 않은 기능 중 하나를 보여준다. 테스트할 사진이 없을 때를 위한 데모 장면이다:

다음은 사고 과정 중 관련 부분으로, 내가 프롬프트의 예시 JSON에 “pelicans”라는 레이블을 썼다는 이유만으로 모델이 스스로 펠리컨을 그리기로 결정한 대목이다:

알려진 이미지를 쓰는 “샘플 불러오기”도 넣을까? 외부 이미지에 의존할 수는 없지만… 이미지 URL 입력은 사용자가 제공하니까 “샘플로 시도” 버튼을 추가할 수 있겠다 [...] 흠, 캔버스에 간단한 장면을 그린 뒤 data URL로 내보내 이미지에 로드하면 되겠다 — 자체 완결형이고 데모도 가능하다! [...] 하지만 사용자가 준 좌표는 실제 펠리컨 이미지용이다. 생성된 플레이스홀더라도 스케일링을 시연할 수 있다. 1000x1000 플레이스홀더를 생성하자. 그라데이션 물 + 주어진 bboxes 위치에 배치된 두 개의 뭉툭한 “펠리컨” 실루엣(같은 스케일 사용 — 귀엽다. 실루엣이 정확히 0-1000 위치에 있어 박스가 정렬된 걸 보여준다). 재미있고 자체 완결적인 데모가 된다. 단순하게 유지하자. 하늘 그라데이션, 태양, 물, 펠리컨 비슷한 형태 두 개(타원형 몸통, 원형 머리, 부리). bbox 중심에 배치.

(전 세계 모델들이 내가 만든 어리석은 벤치마크에 거의 2년 동안 노출된 탓에, 기회가 될 때마다 펠리컨을 그리려는 편향을 갖게 된 건 아닌지 조금 걱정된다.)

그렇게 과한 생각이 다 필요할까? 어느 정도는 필요할지도 모른다. 추론을 끈 채로 시도해 이런 버전(전체 기록은 여기)을 얻었는데, 거의 동작은 하지만 박스 위치가 틀렸다:

즉, 추론 없이는 한 번에 동작하는 도구를 만들지 못했다. 후속 프롬프트 몇 번이면 충분히 만들 수 있었겠지만, 이 사례는 추론이 차이를 만들 수 있음을 잘 보여준다.

코딩 에이전트도 구동할 수 있다

로컬 모델에 대한 가장 큰 의문 중 하나는 코딩 에이전트 루프를 성공적으로 구동할 만큼의 성능이 있는가 하는 점이다. 코딩 에이전트는 긴 컨텍스트, 강력한 코드 생성 지원, 안정적인 도구 호출을 필요로 한다. 서류상으로 Qwen 3.8 27B는 이 세 가지를 모두 갖추고 있는데, 과연 해낼 수 있을까?

Pi로 한 초기 실험 결과는 매우 유망했다. Pi를 선택한 이유는 대부분의 다른 옵션보다 시스템 프롬프트가 짧아 더 작은 모델을 시험하기에 더 적합했기 때문이다.

Spark에서 LM Studio로 실행 중인 Qwen 3.8 27B를 Pi가 사용하도록(tailscale serve로 공유) ~/.pi/agent/models.json에 다음을 추가해 설정했다:

{
  "providers": {
    "spark": {
      "baseUrl": "https://spark-18b3.tail68a31.ts.net/v1",
      "api": "openai-responses",
      "apiKey": "dummy",
      "models": [
        {
          "id": "qwen3.8-27b",
          "reasoning": true
        }
      ]
    }
  }
}

그런 다음 ~/dev/datasette 폴더에서 pi --provider spark --model qwen3.8-27b를 실행하고 이렇게 프롬프트했다:

how does auth work?

여러 파일에 접근하는 일련의 추론과 도구 호출 끝에 모델은 이 답변을 내놓았는데, 매우 충실했다.

문제는 딱 하나, 그 대화 기록을 공유하고 싶다는 것이었다. 그래서 Pi와 Qwen 3.8 27B에 ~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette--에 있는 JSONL 대화 기록 파일을 가리키고 이렇게 프롬프트했다:

Write Python code to convert this jsonl to markdown

그러자 모델은 내가 필요로 하던 pi_jsonl_to_md.py를 만들고 테스트까지 마쳤다. 해당 세션의 대화 기록은 모델이 만든 그 도구를 이용해 게시한 것이다.

속도를 향한 탐구

지금까지는 모든 것이 매우 유망해 보인다. 하이엔드 소비자용 하드웨어에서 동작하는 17GB 모델이 코드를 작성하고, 도구를 구동하며, 이미지에 주석을 달고, LLM에게 기대하는 실제 업무 대부분을 해낼 수 있다.

한 가지 매우 큰 단점이 있다. 느리게 느껴진다는 것이다. 특히 과하게 생각하기 시작하면 그렇고, 그렇지 않더라도 그다지 날렵하지는 않다.

LM Studio에서는 초당 15~30토큰 정도가 나온다. 나쁘지 않은 수치지만, 훨씬 더 빠르게 결과를 반환할 수 있는 호스팅 API 모델에서 나를 끌어오기엔 충분히 느리다. Artificial Analysis는 토큰 속도를 추적하는데, OpenAI 5.6 Sol은 초당 74토큰, 5.6 Luna는 무려 초당 184토큰을 기록한다.

다행인 점은 모델이 처음 출시된 지 이틀 만에 커뮤니티에서 속도를 높일 방법을 활발히 모색하고 있다는 것이다.

가장 유망한 최적화 중 하나는 모델 자체에 내장되어 있다. Qwen은 Multi-Token Prediction을 지원하는데, 이는 더 저렴한 메커니즘이 몇 토큰 앞을 미리 예측하고 메인 모델이 그 예측이 맞았는지 빠르게 검증하는 아키텍처 트릭이다. 이는 추론 성능에 꽤 극적인 영향을 줄 수 있다.

llama.cpp 제작자 Georgi Gerganov의 이 트윗을 보고 Spark에서 MTP를 이용해 다음과 같이 모델을 실행해 봤다:

llama serve \
 -hf  ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
 -hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 \
 --spec-default \
 --spec-type draft-mtp \
 --reasoning-preserve

그리고 실제로 상당한 성능 향상을 얻었다. Codex에서 GPT-5.6이 Spark에서 비교 벤치마크를 실행하도록 했는데, --spec-type draft-mtp 서버가 LM Studio 기본 GGUF보다 약 72% 더 높은 성능을 보였다.

앞으로 몇 주 동안 이 모델을 더 빠르게 서빙하기 위한 혁신이 훨씬 더 많이 나올 것으로 기대한다. MLX 커뮤니티에서도 뭔가 묘안을 준비 중일 것이다.

몇 가지 관찰

17GB짜리 파일 하나로 내 집 머신에서 이 모든 걸 할 수 있다는 사실 자체가 기적이다. 다시 한 번, 올해 로컬 모델이 얼마나 발전했는지에 놀라고 감탄한다. 1년 전만 해도 이 정도면 가장 비싸고 우수한 프로프라이어터리 모델들과 경쟁할 수준이었을 텐데, 이제는 사양 좋은 노트북에서도 돌릴 수 있다.

이 모델이 데일리 드라이버가 되지 못하는 유일한 이유는 성능이다. M5 Mac과 DGX Spark 모두에서 꽤 느리게 느껴진다. 이게 바로 이런 밀집(dense, 비중 전문가 혼합이 아닌) 모델의 단점이다. 좋은 성능을 내려면 엄청난 메모리 대역폭이 필요한데, 내가 쓸 수 있는 두 머신 모두 그 부분에서는 최고 수준이 아니다.

Qwen 3.8 27B에서 가장 중요한 점은 그것이 보여주는 바다. 우리는 긴 컨텍스트, 효과적인 도구 호출, 강력한 비전 능력, 유능한 코드 생성을 갖춘 오픈 가중치 범용 모델을 가질 수 있으며, 그 모든 것을 단 17GB 파일 하나에 담을 수 있다.

이 크기의 모델들은 계속해서 인상적인 속도로 발전하고 있다. 유능한 모델을 실행하기 위해 데이터센터급 하드웨어에 50만 달러를 쓸 필요가 없다.