메모리보다 세 배 큰 모델을 32GB 맥에서 돌릴 수 있을까: Qwen3.8-Flash-Next를 M2 Max에서

메모리보다 세 배 큰 모델을 32GB 맥에서 돌릴 수 있을까: Qwen3.8-Flash-Next를 M2 Max에서

Qwen3.8-Flash-Next는 4비트 가중치만 약 105GB(98GiB)인 전문가 혼합(MoE) 모델입니다. 32GB 맥에는 다 들어가지 않으니, "내 맥에서 돌릴 수 있나"에 대한 보통의 답은 "아니요"입니다.

slotstream은 그 답을 바꾸려고 나온 맥 앱입니다. 모델에서 늘 쓰는 작은 부분은 메모리에 두고, 층마다 512개씩 있는 전문가는 SSD에 남겨 둡니다. 그리고 토큰마다 필요한 전문가만 읽어 오고, 자주 쓰는 것은 메모리 캐시에 둡니다. 모든 토큰이 다 쓰지는 않는 부분이라면, 빠른 내장 SSD가 메모리 노릇을 대신할 수 있다는 계산입니다.

저자는 속도를 꼼꼼하게 쟀습니다. 48GB M5 Pro에서 초당 20.91-23.69토큰이고, 다른 맥에서 온 커뮤니티 보고도 표로 정리해 두었습니다. 품질 쪽으로는 사실, 산수, 정렬, 지시 따르기, 번역, 코드를 묻는 15문항짜리 손상 점검을 두었고 15/15를 통과합니다. 저자도 이것은 큰 손상만 잡는 점검이지 원본 모델과의 비교가 아니라고 밝혀 두었습니다. GSM8K나 HumanEval 같은 공개 벤치마크 점수는 프로젝트 문서에 없습니다.

저희 앞 글은 같은 모델의 다른 파일(A100에서 돌린 2비트 GGUF)로 점수를 쟀고, SSD는 재지 않았다고 적었습니다. 그래서 두 질문을 평범한 맥 한 대에 같이 던졌습니다. 2023년형 맥북 프로 14인치, M2 Max, 메모리 32GB, 내장 SSD 1TB입니다. 얼마나 빠른지, 답은 얼마나 맞는지, 같은 질문에 같은 답이 나오는지입니다.

어떻게 쟀나

• 소프트웨어: 설치한 그대로의 slotstream 0.2.28과 qwen3.8-flash-next:4bit 모델(MLX 4비트 파일)입니다. macOS 15.7.3, 전원 연결, 다른 앱 종료, 잠자기 끔 상태로 쟀습니다. 측정 계획과 판정 규칙은 첫 측정 전에 정해 두었습니다.
• 메모리 계획: 다른 앱을 닫고 slotstream doctor를 돌리면 프로세스 예산 20.9GB를 고릅니다. 속도와 점수는 이 자동 계획(A)으로 쟀고, 서버는 층당 512개 중 약 75개(10GB) 캐시로 시작했습니다. 비교용으로 예산을 10GB로 고정한 계획(B)도 돌렸고, 이 서버는 층당 약 22개(3GB)로 시작했습니다. 두 계획은 캐시 크기만 다르지 않습니다. A에서 B로 가면서 slotstream은 전문가를 미리 읽어 두는 lookahead를 껐고, draft head의 전문가를 메모리에서 SSD로 옮겼고, 프롬프트를 1,024토큰이 아니라 256토큰씩 읽었고, 프롬프트 재사용 상한도 낮췄습니다. 다음 토큰을 미리 짐작하는 추측 디코딩은 두 계획 모두 켜져 있었습니다.
• 속도: 짧은 프롬프트 3개를 세 번씩 보내 256토큰을 생성했습니다. 디코드 속도는 서버가 직접 센 값(eval_count / eval_duration)입니다. 저자의 정의대로 세 번째 같은 요청을 "warm"으로 봤습니다. 긴 프롬프트는 slotstream에 들어 있는 context-check로 8,192토큰을 읽혔습니다. 저자의 하드웨어 표에서 "Long prompt" 열을 만든 도구입니다.
• 점수: Strata 글에서 쓴 하네스 그대로입니다. 질문, 프롬프트, 채점이 모두 같습니다. GSM8K 300문항(시드 0)과 HumanEval 164문항 전부이고, 생각 끔, 출력 최대 1,024토큰, 요청은 한 번에 하나씩 보냈습니다. slotstream에 맞춰 바꾼 것은 두 가지입니다. slotstream은 모르는 요청 필드를 거절해서, 생각 끔은 slotstream 방식인 think: false로 보냈습니다. 그리고 기본 샘플링이 temperature 0.7, presence penalty 1.5라서, 매번 같은 답이 나오도록 greedy 설정(temperature 0, top_k 1, presence penalty 0)을 명시했습니다.
• 반복 일치: GSM8K 앞 30문항을 계획 A에서 세 번 물었고, 프롬프트 재사용을 끈 계획 A(이때 서버는 층당 약 85개로 시작)와 계획 B에서 한 번씩 더 물었습니다.

속도

자동 계획에서는 짧은 답이 초당 9.5토큰쯤으로 나옵니다. doctor가 추정한 값과 비슷합니다. 10GB 계획은 디코드가 절반 속도였고, 8K 프롬프트를 읽는 데는 3분의 1쯤 더 걸렸습니다. 이 차이는 계획 B에서 함께 바뀐 것들(캐시 크기, lookahead, draft head 전문가의 위치, 프롬프트를 읽는 단위)이 모여 만든 결과이고, 캐시 크기 하나의 탓으로 볼 수는 없습니다.

참고로 slotstream 하드웨어 표의 커뮤니티 보고에는 32GB M5 Air가 초당 6.22토큰, 36GB M4 Max가 8.41토큰으로 적혀 있습니다. 버전과 메모리 계획이 달라서 몇 배인지는 계산하지 않습니다.

짧은 답 속도와 긴 작업의 체감은 다릅니다. GSM8K 300문항은 프롬프트 읽기까지 포함해 요청 하나에 중앙값 37.5초, 전체로 3.6시간이 걸렸습니다. 출력 토큰으로 따지면 초당 6.9토큰입니다. HumanEval은 1.8시간이었습니다.

답의 품질

참고로 Strata 글에서는 같은 모델의 다른 파일인 ISTA-DASLab의 2비트 IQ2_XS GGUF를 A100에서 쟀습니다. GSM8K는 279(llama.cpp)와 280(Strata), HumanEval은 둘 다 157이었습니다. 파일, 엔진, 하드웨어가 모두 달라서 우열은 매기지 않습니다. 두 파일의 점수는 문항 1-2개 차이였지만, 엔진과 장비까지 달라 이것을 2비트와 4비트의 비교로 볼 수는 없습니다. 원본 bf16 모델의 이 하네스 점수도 모르기 때문에, 이 숫자로 4비트 파일이 얼마나 잃는지는 말할 수 없습니다. 참고로 결정 모델에서는 비트를 깎을 때 정확도보다 confidence가 먼저 움직였습니다(2비트 모델은 맞히는 법은 기억하고 확신하는 법은 잊는다). 이 글은 확률을 재지 않았습니다.

반복 일치

모든 출력이 바이트 하나까지 같았습니다. 캐시가 네 배쯤 차이 나고 lookahead, 프롬프트 읽는 단위, draft head 전문가의 위치까지 달랐던 두 계획 사이에서도 그랬습니다. slotstream 문서는 전문가 캐시가 출력이 아니라 속도만 바꾼다고 설명하고, 자체 테스트로도 확인합니다. 실제 과제에서도 그대로였습니다.

전문가를 옮겨 다니며 계산하는 엔진에서 이런 일치가 저절로 따라오지는 않습니다. 저희 Strata 글에서는 GPU를 12GiB로 묶고 기본 설정으로 돌리자, 세 번 반복해 모두 같은 답이 나온 문항이 30개 중 12개뿐이었습니다. Strata 문서도 이 동작을 설명하고, 속도를 조금 내주고 일치시키는 스위치를 제공합니다.

치르는 값

• 다운로드와 디스크: 압축해서 88.3GB이고, 저희 회선에서 19분 걸렸습니다. 디스크에는 98GiB(약 105GB)를 차지합니다. 그만큼의 여유가 빠른 내장 SSD에 있어야 합니다. 저자 표에는 같은 64GB M4 Max가 10Gb/s 외장 드라이브에서 초당 15.93토큰에서 2.98토큰으로 떨어진 보고가 있습니다. 저희는 외장 드라이브가 없어 재지 못했습니다.
• SSD 수명: SSD에서 전문가를 꺼내 오는 것은 읽기이지 쓰기가 아닙니다. slotstream이 대화 상태를 디스크에 쓰는 것은 --prefix-cache-dir를 줘서 띄울 때뿐이고, 저희는 이 옵션을 쓰지 않았습니다. 다만 실제로 쓰인 바이트를 재지는 않았으니, 측정이 아니라 설계상 그렇다는 뜻으로 읽어 주세요.
• 시간과 발열: 긴 작업은 몇 시간씩 걸리고, 그동안 맥은 그 일만 합니다. 3.6시간 걸린 GSM8K 동안 노트북이 느려지지는 않았습니다. 앞 50개 요청은 중앙값 초당 6.73토큰, 뒤 50개는 6.83토큰이었습니다.
• 끊긴 요청 하나: HumanEval 32번 문제에서 1,024토큰을 끝까지 쓰던 답이 106초째에 insufficient_memory로 멈췄고, 클라이언트는 HTTP 503을 받았습니다. 그 뒤 slotstream은 캐시를 층당 약 75개에서 60개로 줄였다가, 몇 분 뒤 다시 늘렸습니다. 같은 요청을 다시 보내자 125초 만에 정상으로 끝났습니다. slotstream 명령어 문서에는 자동 크기 캐시가 "요청과 요청 사이에" 크기를 바꾼다고 적혀 있고, 저희 로그에서도 캐시는 이 요청이 끝난 직후에 줄었습니다. 그래서 긴 답을 쓰는 도중에 메모리가 부족해지면 그 답이 끊깁니다. 긴 작업을 스크립트로 돌린다면 503에 재시도를 넣어 두세요. 그 순간 무엇이 메모리를 가져갔는지는 저희도 모릅니다.

SOTAAZ 강좌

이 강좌만 $79 · 24강 · 앞 3강 무료무료로 보기 →

메모리에 다 들어가는 9B와 비교하면

32GB 맥 사용자의 실제 선택지는 "이 모델이냐 아니냐"가 아니라 "이 모델이냐, 메모리에 다 들어가는 모델이냐"입니다. 그래서 같은 맥에서 Qwen3.5-9B Q4_K_M(5.7GB)을 llama.cpp(0.6.0, Metal)로 띄우고 같은 하네스로 쟀습니다. 비교 규칙은 측정 전에 정했습니다. 같은 문항끼리 짝지은 McNemar 정확 검정에서 p<0.05면 정답률이 다르다고 쓰고, 아니면 이 문항 수로는 구분되지 않는다고 씁니다. 엔진이 다르므로 아래 속도는 "각자 실제로 돌리는 방식" 그대로의 비교입니다.

GSM8K는 이 문항 수로 구분되지 않았습니다. Flash-Next만 맞힌 문항이 14개, 9B만 맞힌 문항이 7개였습니다(p = 0.19). HumanEval은 같은 문항에서 정답률이 달랐습니다. Flash-Next만 맞힌 문제가 20개, 9B만 맞힌 문제가 2개였습니다(p = 0.0001). 9B 쪽도 출력 상한에서 잘린 답이 GSM8K 5개, HumanEval 5개였습니다.

그래서, 32GB 맥에서 돌아가나

기다릴 수 있는 답이라면 돌아갑니다. 이 M2 Max에서 짧은 답은 초당 9.5토큰쯤으로 나오고, 같은 질문에는 같은 답이 나옵니다. 메모리에 다 들어가는 9B와 비교하면 값과 얻는 것이 분명합니다. 디스크를 18배쯤 더 쓰고, 같은 작업에 다섯 배쯤 더 오래 기다립니다. 그 대가로 산수 문제(GSM8K)에서는 차이를 확인하지 못했고, 코드 문제(HumanEval)에서는 164개 중 18개를 더 풀었습니다. 에이전트 작업은 재지 않았지만, 긴 작업 전체로 초당 6.9토큰이라 긴 답을 여러 번 이어 받는 일은 몇 시간이 걸립니다.

한계

• 맥 한 대(M2 Max, 32GB, 내장 SSD), 릴리스 하나(0.2.28), 모델 파일 하나입니다. 비교 상대도 9B 하나이고, 32GB 맥에 들어가는 더 큰 모델(예를 들어 27B)은 재지 않았습니다. 저자의 표가 보여 주듯 다른 맥, 다른 릴리스, 다른 드라이브에서는 속도가 크게 다를 수 있습니다.
• 생각 끔, 답 1,024토큰까지입니다. 긴 추론이나 에이전트 작업은 재지 않았습니다.
• 300문항과 164문항으로는 큰 품질 차이만 보입니다.
• 계획 B는 같은 맥에서 예산만 줄인 것이지 16GB 맥이 아닙니다.
• 반복 일치는 30문항으로 확인했습니다.
• 두 실행은 중간에 끊겼다가 같은 서버에서 이어 갔습니다. HumanEval은 32번에서 요청이 끊긴 뒤 이어 갔고, 계획 B 실행은 저희 클라이언트가 자체 시간 제한으로 22번째에서 멈춘 뒤 23번째부터 이어 갔습니다. 시각과 지점은 원본 메모에 있습니다.

계획서, 맥에서 쓴 클라이언트 스크립트, 맥에서 나온 원본 파일 전부(요청 기록, 서버 로그, doctor 출력, 다운로드 기록)는 아래 재현 패키지에 들어 있습니다.