Qwen3.8-27B, 16GB 맥북에선 안 돌아간다

현지 시각 8월 14일(한국시간 15일) 알리바바 통이랩이 공개한 Qwen3.8-27B를 두고 “27B짜리 로컬 모델이 클로드 오퍼스를 이겼다”는 이야기가 돈다. 모델카드를 직접 세어보니 과장이 아니었다. 오퍼스 4.6 Max와 직접 비교가 가능한 항목 20개 중 16개에서 Qwen이 앞선다.

그런데 이 글의 결론은 다르다. 당신이 16GB 맥북을 쓰고 있다면, 이 모델은 당신 기기에서 돌아가지 않는다. 성능이 부족해서가 아니다. 파일 크기가 문제인데, 여기에는 함정이 하나 있다. 4비트로 압축한 파일은 16.1GB이고 기기 메모리는 16GB다. 언뜻 “1억 바이트 차이니까 아슬아슬하게 안 되는구나” 싶지만, 실제로는 바이트로 따지면 파일이 메모리보다 작다. 그런데도 안 된다. 이유는 뒤에서 자세히 설명한다.

그래서 직접 확인했다. 맥북에어 M5(16GB)에서 27B는 올라가지 않았고, 대신 실제로 돌아가는 9B 모델의 생성 속도를 측정했다. 워밍업 후 평균 26.45 토큰/초. 사람이 소리 내어 읽는 속도의 6배 이상이다. 이 글은 그 측정 기록이자, “로컬 LLM이 좋아졌다”는 기사와 “내 노트북에서 돌아간다”가 전혀 다른 문제라는 이야기다.

Photo by Mikey Harris on Unsplash

Qwen3.8-27B는 실제로 무엇인가

먼저 모델 자체를 정확히 보자. 아래는 허깅페이스 공식 모델카드 기준이며, 2차 블로그가 아니라 원문에 적힌 값이다.

항목	내용
공개	2026년 8월 14일(현지) / 15일 0시(KST), 알리바바 통이랩
파라미터	27B 덴스(dense) — 실측 27.78B, 히든 5,120 / 64레이어
구조	하이브리드 어텐션 — Gated DeltaNet + Gated Attention 교차 배치
컨텍스트	네이티브 262,144 토큰, YaRN 확장 시 최대 100만
멀티모달	네이티브 비전-언어 — 이미지·영상 직접 처리
라이선스	Apache 2.0

핵심은 세 가지다. 첫째, 덴스 모델이다. 요즘 대형 모델이 대부분 MoE(전문가 혼합) 구조로 가는 것과 반대로, 27B 전부를 매번 활성화한다. 이 성질은 뒤에 나올 메모리 이야기에서 결정적인 역할을 한다. 둘째, 네이티브 멀티모달이다. 이미지 인식을 별도 모델로 붙인 게 아니라 처음부터 비전-언어 모델로 학습됐다. 셋째, Apache 2.0이다. 상업적 이용에 제약이 없다. 실무자에게는 벤치마크 점수보다 이 조항이 더 중요할 수 있다.

벤치마크를 보자. 흔히 인용되는 승리 항목만이 아니라 지는 항목까지 함께 싣는다.

벤치마크	Qwen3.8-27B	Opus 4.6 Max	결과
SWE-bench Pro	61.7	53.4	Qwen 승
OSWorld-Verified	84.3	72.7	Qwen 승
Terminal Bench 2.1	73.0	78.2	Qwen 패
NL2Repo-Bench	42.3	47.6	Qwen 패
GPQA Diamond	89.2	91.3	Qwen 패
HLE	30.8	40.0	Qwen 패

출처: Qwen/Qwen3.8-27B 모델카드, Hugging Face

읽는 법이 중요하다. 이 숫자는 전부 Qwen이 자기 모델을 자기가 측정한 값이다. 그 점을 감안하고 직접 집계했다. 모델카드에서 오퍼스 4.6 Max와 나란히 점수가 실린 항목은 20개이고, Qwen이 16개에서 앞서고 4개에서 진다. 지는 항목은 위 표의 네 가지인데, 특히 HLE는 30.8 대 40.0으로 격차가 작지 않다. 어려운 추론 과제로 갈수록 격차가 벌어지는 패턴이다.

같은 이유로 항목 선택도 조심해야 한다. 예컨대 MathVision에서 Qwen3.8-27B는 94.6이라는 높은 점수를 내지만, 이건 코드 인터프리터를 붙인(With CI) 조건이다. 코드 인터프리터 없이 재면 90.0이고, 비교 대상인 Qwen3.7-Plus는 90.3으로 오히려 근소하게 앞선다. 벤더 자료에서 숫자를 가져올 때 조건이 같은지 확인하지 않으면 이런 함정에 빠진다.

그래도 SWE-bench Pro에서 27B 모델이 61.7을 낸다는 건 의미가 작지 않다. 1년 전이라면 클라우드 프런티어 모델의 영역이었다.

파일은 메모리보다 작다. 그런데도 안 올라간다

여기서 이 글의 본론이 시작된다.

애플 실리콘용으로 가장 널리 쓰이는 MLX 4비트 양자화 버전 mlx-community/Qwen3.8-27B-4bit의 파일 크기는 16.1GB다. 그리고 기기 메모리는 16GB다. 여기서 많은 사람이 “16.1 > 16이니까 안 되는구나”라고 결론 내리는데, 이건 틀렸다.

허깅페이스가 표기하는 16.1GB는 10진 기가바이트(10⁹ 바이트)다. 반면 애플이 “16GB”라고 파는 메모리는 기가바이트가 아니라 기비바이트(GiB, 2³⁰ 바이트)다. 같은 자로 재면 이렇다.

• 모델 파일: 16.1 × 10⁹ 바이트 = 14.97 GiB
• 기기 메모리: 16 GiB = 17.18 × 10⁹ 바이트

파일이 메모리보다 1 GiB 남짓 작다. 그런데도 안 올라간다. 진짜 이유는 세 가지다.

첫째, macOS가 GPU에 내주는 메모리에 상한이 있다. 애플 실리콘의 통합 메모리는 CPU와 GPU가 같은 물리 메모리를 나눠 쓰는데, macOS는 GPU가 점유(wired)할 수 있는 양을 물리 메모리의 약 75%로 기본 제한한다. 16GB 기기라면 약 12 GiB다. 14.97 GiB 모델은 이 선을 넘는다. iogpu.wired_limit_mb 같은 시스템 파라미터를 직접 손대지 않는 한 애초에 할당 자체가 되지 않는다.

둘째, OS와 앱이 이미 메모리를 쓰고 있다. 측정 시점에 이 맥북의 시스템 여유 메모리는 64%였다(memory_pressure 명령 기준). 16 GiB의 64%면 약 10.2 GiB다. 브라우저와 편집기를 띄워둔 평범한 작업 상태에서 실제로 모델에 내줄 수 있는 건 그 정도다.

셋째, 모델 파일이 전부가 아니다. 추론 중에는 KV 캐시와 활성화 메모리가 모델 위에 추가로 얹힌다. 컨텍스트를 길게 쓸수록 이 몫이 커진다. 파일 크기는 필요 메모리의 하한이지 총량이 아니다.

잠깐, 4비트 양자화가 무슨 뜻인가

이 글을 이해하는 데 필요한 개념 하나만 짚고 가자. 모델의 파라미터는 원래 하나당 16비트(2바이트) 실수로 저장된다. Qwen3.8-27B의 실제 파라미터는 27.78B이므로, 원본은 약 56GB다. 개인 기기에서는 불가능한 숫자다.

양자화(quantization)는 이 숫자의 정밀도를 낮춰 파일을 줄이는 기법이다. 16비트를 4비트로 줄이면 이론상 4분의 1이 되고, 27.78B × 0.5바이트 = 약 13.9GB로 내려온다. 실제 파일이 16.1GB인 이유는 이 모델이 비전-언어 모델이라 비전 인코더와 임베딩 층이 BF16 정밀도로 남기 때문이다.

핵심은 양자화가 공짜가 아니라는 것이다. 정밀도를 깎는 만큼 답변 품질이 떨어진다. 업계에서 4비트를 사실상의 실용 하한으로 취급하는 이유가 여기 있고, 특히 2비트 이하로 내려가면 문장이 어색해지거나 논리가 끊기는 현상이 눈에 띄기 시작한다.

그래서 “16GB에 안 들어가면 2비트로 누르면 되지 않나”는 해법은 권할 만하지 않은데, 애플 실리콘 사용자에게는 더 단순한 사정이 있다. 현재 mlx-community에 올라온 Qwen3.8-27B 양자화본은 4비트와 8비트 두 가지뿐이다. 3비트도 2비트도 없다. 눌러 쓰고 싶어도 선택지가 존재하지 않는다.

또 하나 짚어둘 것은 Qwen3.8 계열에 작은 모델이 없다는 점이다. 현재 공개된 것은 27B와 2.4조 파라미터급 Max(Qwen3.8-2.4T-A95B) 두 가지뿐이다. Qwen3.5 세대에는 0.8B·2B·4B·9B로 이어지는 경량 라인이 있었지만, 3.8 세대에는 아직 없다. 16GB 사용자에게 Qwen3.8은 “작은 걸 쓰면 되지”라는 선택지조차 없는 셈이다.

”디스크로 넘겨 쓰면 되지 않나”

여기서 한 가지 반문이 나온다. 메모리가 모자라면 디스크로 넘겨 쓰면 되지 않나. 컴퓨터는 60년 넘게 정확히 그 방법으로 이 문제를 풀어왔다. 1962년 맨체스터대와 페란티(Ferranti)가 함께 만든 아틀라스(Atlas)가 처음 구현한 가상 메모리가 그것이다. 그전까지 프로그래머는 프로그램을 손으로 조각내 번갈아 올리는 오버레이(overlay) 작업을 직접 해야 했는데, 가상 메모리는 물리 메모리보다 큰 프로그램도 느릴지언정 돌아가게 만들어 그 수고를 없앴다.

그런데 LLM 추론은 이 60년짜리 해법이 통하지 않는 드문 작업이다. 가상 메모리가 성립하는 전제는 지역성(locality) — 프로그램이 매 순간 전체가 아니라 일부만 쓴다는 것이다. 덴스 모델은 정반대다. 토큰 하나를 만들 때마다 27B 파라미터 전부를 읽는다. 지역성이 사실상 0이다. 실제로 모델 파일을 메모리 매핑해 램보다 큰 모델을 억지로 띄우면, 토큰 하나마다 가중치 파일 전체를 디스크에서 다시 읽어 속도가 실용 범위 밖으로 떨어진다. “안 들어가면 디스크로”가 통하지 않기 때문에, 이 벽은 협상이 불가능하다.

그래서 직접 재봤다 — 맥북에어 M5 16GB 실측

27B를 못 돌리니, 실제로 돌아가는 것을 정확히 재기로 했다. 테스트 환경은 이렇다.

항목	사양
기기	MacBook Air M5 (10코어 — 성능 4 / 효율 6)
메모리	16GB 통합 메모리, 대역폭 153GB/s
런타임	LM Studio (OpenAI 호환 서버, 포트 1234)
모델	Qwen3.5-9B MLX 4비트 (디스크 5.6GB)
컨텍스트	8,192 토큰
측정	세 가지 길이의 프롬프트, temperature 0.3

결과는 다음과 같다.

시나리오	출력 토큰	소요 시간	생성 속도
첫 실행(모델 로드 포함)	399	42.80초	9.32 tok/s
짧은 답변	119	4.63초	25.70 tok/s
중간 길이	299	11.13초	26.86 tok/s
긴 생성	699	26.10초	26.78 tok/s
워밍업 후 평균	—	—	26.45 tok/s

두 가지가 눈에 띈다.

첫째, 워밍업 이후 속도가 놀랄 만큼 일정하다. 119토큰이든 699토큰이든 25.7~26.9 tok/s 사이에 머문다. 출력이 길어져도 속도가 무너지지 않는다는 뜻이고, 로컬 모델을 실무에 쓸 때 중요한 성질이다. 초반만 빠르고 뒤로 갈수록 느려지면 긴 문서 작성에 쓸 수 없다.

둘째, 첫 실행의 9.32 tok/s는 모델을 디스크에서 메모리로 올리는 시간이 포함된 값이다. 5.6GB를 읽어 올리는 시간이 여기 다 들어가 있다. 실제 사용 감각은 두 번째 요청부터다. LM Studio 기본 설정에서는 60분간 모델이 메모리에 남아 있으므로, 하루에 몇 번씩 쓰는 패턴이라면 대부분 워밍업 상태로 쓰게 된다.

체감으로 옮기면 이렇다. 사람이 소리 내어 읽는 속도가 대략 분당 150단어, 초당 34토큰 수준이다. **26.45 tok/s는 그 68배다.** 화면에 글자가 차오르는 걸 기다린다는 느낌이 들지 않는다. 다만 눈으로 훑는 묵독은 소리 내어 읽기보다 두 배 가까이 빠르므로, 그 기준이면 배수는 절반으로 줄어든다. 그래도 코드 한 함수, 이메일 한 통, 요약 한 문단 정도는 몇 초 안에 끝난다.

Photo by Jeremy Waterhouse on Pexels

27B를 돌리려면 무엇이 필요한가

그렇다면 Qwen3.8-27B를 실제로 쓰려면 어떤 기기가 필요한가. 메모리 용량이 1차 관문이고, 메모리 대역폭이 2차 관문이다.

메모리	현실적으로 가능한 규모	비고
8GB	4B 이하	4비트 기준 2~3GB. 실용성 제한적
16GB	9B~14B	이 글의 측정 환경. Qwen3.8-27B 불가
24GB	14B~24B	27B 4비트가 흔히 최소 사양으로 인용되지만, 컨텍스트를 길게 쓰면 KV 캐시 때문에 빠듯
32GB 이상	27B 4비트 여유	Qwen3.8-27B의 실질적 최소 사양
외장 GPU (RTX 4090 24GB / 5090 32GB)	27B 4비트	약 15 GiB + KV 캐시. 속도는 맥 대비 유리

여기서 오해하기 쉬운 지점이 있다. 메모리를 늘린다고 속도가 비례해 오르지는 않는다. 용량은 “올라가느냐 마느냐”를 결정하고, 속도를 결정하는 건 메모리 대역폭이다. M5의 통합 메모리 대역폭은 153GB/s로 M4 대비 28% 개선됐지만, 프로·맥스 계열이나 고성능 외장 GPU와 비교하면 여전히 낮은 축이다. 같은 27B 모델을 32GB 맥북에어에 올린다 해도, 파라미터가 3배로 늘어난 만큼 토큰당 읽어야 할 데이터도 3배가 되므로 체감 속도는 9B의 3분의 1, 대략 8~9 tok/s 수준으로 떨어진다고 보는 편이 안전하다. 읽는 속도와 비슷해지는 구간이다.

즉 27B를 노트북에서 쾌적하게 쓰고 싶다면 필요한 건 메모리 32GB만이 아니라 대역폭이 높은 프로·맥스급 칩이다. 이 구분을 놓치면 “32GB로 업그레이드했는데 왜 이렇게 느리냐”는 상황이 생긴다.

27B를 못 쓰면 무엇을 포기하는 것인가

정직하게 따져보자. 9B로 내려앉으면 실제로 무엇을 잃는가.

가장 크게 잃는 것은 멀티모달이다. Qwen3.8-27B의 차별점은 점수보다 이미지·영상을 네이티브로 읽는다는 데 있다. 스캔한 계약서, 손으로 그린 다이어그램, 도면, 차트 이미지를 API 비용 없이 로컬에서 읽는 작업이 여기 걸린다. 이건 텍스트 전용 9B로는 대체가 안 되는 기능이다.

두 번째는 긴 컨텍스트다. 27B는 네이티브 262K 토큰을 지원한다. 이 글의 측정 환경은 8,192 토큰이었다. 코드베이스 전체나 수백 페이지 문서를 한 번에 넣는 작업은 애초에 다른 급이다. 다만 여기엔 함정이 있는데, 컨텍스트를 길게 쓰면 KV 캐시가 메모리를 추가로 잡아먹는다. 모델카드의 컨텍스트 숫자는 “이 길이까지 이해한다”는 뜻이지 “당신 기기에서 이 길이를 쓸 수 있다”는 뜻이 아니다.

반대로 덜 잃는 것도 분명히 말해둘 필요가 있다. 일상적인 요약, 번역, 이메일 초안, 짧은 코드 조각, 문서 질의응답 같은 작업에서 9B급과 27B급의 체감 차이는 벤치마크 점수 차이만큼 크지 않다. 벤치마크는 모델을 변별하기 위해 일부러 어려운 문제를 모아 놓은 것이라, 점수 격차가 일상 업무 격차로 그대로 번역되지 않는다. “27B가 아니면 의미 없다”는 식의 이야기는 대체로 과장이다.

이건 개인용 컴퓨터의 오래된 이야기다

지금 벌어지는 일이 낯설게 느껴진다면, 개인용 컴퓨터의 역사를 돌아보면 익숙한 장면이라는 걸 알 수 있다.

소프트웨어가 먼저 앞서 나가고 메모리가 뒤늦게 따라가는 구도는 PC 산업의 상수였다. 1981년 IBM PC의 640KB 한계가 그랬다. 다만 그 한계는 흔히 알려진 것처럼 “누구도 그만큼 쓸 일이 없다”는 오판에서 나온 게 아니다. CPU였던 인텔 8088의 주소선이 20개뿐이라 주소공간 전체가 1MB였고, IBM은 그중 위쪽 384KB를 화면 메모리·확장카드 ROM·BIOS ROM 몫으로 미리 떼어놨다. 남은 아래쪽 640KB가 프로그램이 쓸 수 있는 전부였다. 수요 예측의 실패가 아니라 주소를 어떻게 나눌지에 대한 배분 결정이었다. (빌 게이츠의 “640K면 누구에게나 충분하다”는 유명한 인용도 본인이 부인했고, 1차 출처가 확인된 적이 없다.)

문제는 배분이 아니라 속도였다. 출시 당시 IBM PC는 램 16KB를 달고 나왔으니 640KB는 한참 먼 얘기였다. 그런데 3년 만인 1984년 그 선이 실제 제약으로 닥쳤고, 인텔이 어보브 보드(Above Board)를 내놓은 것을 시작으로 1985년 EMS, 1988년 XMS까지 우회 규격이 줄줄이 등장했다. 소프트웨어가 요구하는 것과 표준 하드웨어가 제공하는 것 사이의 간극을, 사용자들이 편법으로 메우던 시기다. 벽을 넘을 길이 열린 것은 1985년 발표되고 이듬해 보급된 80386이 32비트 주소공간(최대 4GB)을 연 뒤였다. 다만 DOS가 리얼 모드로 계속 돌았던 탓에, 이 벽이 실무에서 완전히 사라지기까지는 그 뒤로도 여러 해가 더 걸렸다.

지금 로컬 LLM 사용자가 2비트 양자화를 만지작거리는 것도 구조적으로 같은 행동이다. 모델이 요구하는 메모리와 내 기기가 가진 메모리의 간극을, 품질을 깎아 메우려는 시도다. 그때의 오버레이와 EMS 뱅크 스위칭이 오늘의 저비트 양자화다.

그런데 결정적으로 다른 점이 있다. 과거의 사용자에게는 벽을 넘는 비상구가 두 개 있었지만, 지금은 둘 다 막혔다.

첫 번째 비상구는 가상 메모리였다. 못 들어가면 디스크로 넘겨 느리게라도 돌린다. 앞에서 봤듯 덴스 LLM에는 이게 통하지 않는다. 토큰마다 전체 파라미터를 읽으니 지역성이 없다.

두 번째 비상구는 물리적 확장이었다. 1984년 어보브 보드 같은 확장 메모리 카드가 그 역할을 했고, 램이 모자라면 슬롯에 보드를 꽂거나 소켓에 모듈을 더 꽂는 것이 1990년대까지 PC의 기본 상식이었다. 640KB의 벽은 적어도 “돈을 더 쓰면 넘을 수 있는” 벽이었다. 애플 실리콘의 통합 메모리에는 그 선택지가 없다. 메모리가 칩 패키지에 함께 붙어 나오므로 구매 시점에 고른 용량이 그 기기의 수명 내내 상한이다. 1980년대 사용자는 “지금은 부족하지만 나중에 꽂으면 된다”고 말할 수 있었지만, 지금 16GB 맥북을 산 사람에게 남은 선택지는 기기를 통째로 바꾸는 것뿐이다.

So What — 이 소식을 어떻게 읽어야 하나

첫째, 로컬 LLM 뉴스는 ‘성능’이 아니라 ‘메모리’로 읽어야 한다. “27B가 오퍼스를 이겼다”는 문장에는 그 27B를 올릴 기기가 있느냐는 조건이 빠져 있다. 모델 발표 기사를 볼 때 먼저 확인할 숫자는 벤치마크 점수가 아니라 4비트 파일 크기다. 그리고 그 값을 내 기기 메모리와 비교할 때는, 이 글에서 봤듯 기기 메모리의 75%가 실질 상한이라는 점을 계산에 넣어야 한다. 16GB 기기의 실질 한도는 16GB가 아니라 12GB다.

둘째, 이번 릴리스의 진짜 뉴스는 점수가 아니라 라이선스다. Apache 2.0으로 풀린 네이티브 멀티모달 27B는 지금까지 없던 조합이다. 스캔 문서와 도면을 외부로 보내지 않고 사내에서 처리해야 하는 조직에게는 벤치마크 1~2점보다 이 조항이 훨씬 큰 변수다. 다만 그 혜택을 보려면 32GB 이상, 가급적 대역폭 높은 장비가 전제된다.

셋째, 지금 16GB 기기를 쓰고 있다면 기다리는 것이 합리적이다. Qwen3.5 세대에는 0.8B부터 9B까지 경량 라인이 있었고, Qwen3.8도 시간이 지나면 경량 버전이 나올 가능성이 있다. 지금 무리하게 저비트로 눌러 쓰는 것보다 — 애초에 애플 실리콘용으로는 4비트 미만 변환본이 존재하지도 않는다 — 잘 압축된 9B급을 쓰다가 경량 버전이 나오면 갈아타는 편이 낫다. 실측대로 9B는 26 tok/s로 충분히 실무에 쓸 만하다.

넷째, 하드웨어 구매를 고민 중이라면 기준은 32GB다. 로컬 LLM을 진지하게 쓸 계획이라면 통합 메모리 32GB가 사실상의 입장권이고, 여기에 대역폭까지 보려면 프로·맥스 계열을 봐야 한다. 16GB는 9B~14B급까지의 기기다. 나쁘다는 뜻이 아니라, 어디까지 되는 기기인지 알고 사자는 뜻이다. 그리고 통합 메모리에서는 이 판단을 나중에 되돌릴 수 없다.

정리하면 이렇다. Qwen3.8-27B는 좋은 모델이고, 27B 크기에서 이 정도 점수가 나온다는 건 분명한 진전이다. 그러나 모델의 발전 속도와 내 노트북의 메모리는 별개로 움직인다. 640KB의 벽은 돈이나 시간을 더 쓰면 넘을 수 있는 벽이었지만, 통합 메모리의 벽은 그렇지 않다. 로컬 AI에서 진짜 병목은 지능이 아니라 메모리이고, 그 메모리는 구매 시점에 이미 결정돼 있다.

참고 자료

• Qwen/Qwen3.8-27B 공식 모델카드 — 파라미터·구조·컨텍스트·벤치마크 원문
• mlx-community/Qwen3.8-27B-4bit — 애플 실리콘용 4비트 변환본 (16.1GB)
• Apple — MacBook Air 기술 사양 · Macworld — M5 맥북에어 상세 스펙 — 153GB/s 대역폭, M4 대비 28% 개선
• AppleInsider — 애플 실리콘 통합 메모리의 장단점
• The 640K Barrier — Digital Antiquarian · Quote Investigator — “640K” 인용의 출처 문제
• Atlas Computer and the Invention of Virtual Memory (IEEE Milestone)
• 생성 속도 측정: 2026-08-16, MacBook Air M5 / 16GB, LM Studio + Qwen3.5-9B MLX 4비트. 원자료는 본문 표에 그대로 기재