⚡ 한 줄 답변
Qwen3.8-27B는 맥미니 M4 Pro 64GB에서 decode 15 tok/s밖에 안 나와서 느리다. 그런데도 나는 이걸 최종 채택했다. 5~7배 빠른 MoE 모델 두 개를 먼저 테스트했는데, 둘 다 속도가 아니라 정확도에서 탈락했기 때문이다.
Obsidian에 로컬 LLM을 붙여 쓰고 있다. 노트 정리하고, 웹 검색 시키고, 한국어로 깔끔하게 요약하도록 한다.
어느 날부터 “좀 더 똑똑하면 좋겠다”는 생각이 들었다. 그래서, 새로운 모델이 나오길 기다렸는데, Qwen3.8이 나왔다는 소식을 듣고 설치해 보았다. 그런데 속도가 느렸고, 그래서 다시 MoE 모델로 돌아가는 실험을 해보았다.
그 과정에서 두 번 잘못 짚었다. 한 번은 GPU를 의심했고, 한 번은 모델이 멍청해졌다고 생각했다. 둘 다 틀렸다.
이 글은 그 오진 기록이자, 로컬 LLM을 고를 때 뭘 봐야 하는지에 대한 실측 정리다 😅
Qwen3.8-27B는 어떤 모델이고, 왜 느릴까?
Dense 27B 모델이라 느리다. 4비트로 양자화해도 15GB고, 토큰 하나 뽑을 때마다 이 15GB를 통째로 읽는다.
디코딩 속도는 연산이 아니라 메모리 대역폭이 결정한다.
반면 MoE 계열인 A3B 모델은 전문가 256개 중 8개만 활성화한다.
토큰당 실제로 읽는 건 약 3B 파라미터뿐이다. 5~7배 빠른 이유가 여기 있다.
| 기종 | Mac mini (Mac16,11) |
| 칩 | Apple M4 Pro (12코어 CPU / 16코어 GPU) |
| 메모리 | 64GB 통합 메모리 |
| 추론 엔진 | vllm-mlx (OpenAI 호환 /v1/*) |
| 용도 | 한국어 + 웹 검색 요약 + 노트 질의 |
마지막 줄이 이 글에서 제일 중요하다.
내 용도는 코딩이 아니기 때문이다.
코딩 벤치마크가 잘 나오는 모델이 내가 원하는 걸 잘한다는 보장은 없다. 그래서 직접 테스트를 해보았다.
로컬 LLM 3개를 실측하면 속도 차이는 얼마나 날까?
직접 돌려본 값이다. 조건은 동일하게 맞췄다. 8.3k자 시스템 프롬프트 + 툴 스키마 7개.
| 항목 | Qwen3.6-A3B | Qwen3.8-27B | Ornith-1.5-A3B |
|---|---|---|---|
| 구조 | MoE | Dense | MoE |
| 크기(4bit) | 19GB | 15GB | 18GB |
| decode | 72.5 tok/s | 15.0 tok/s | 71.3 tok/s |
| 첫 턴(콜드) | 약 5초 | 32.7초 | 4.9초 |
| 긴 답변 | 약 10초 | 40.8초 | 5.3초 |
| 채택 여부 | 탈락 | 채택 ✅ | 탈락 |
숫자만 보면 결론이 명백해 보인다. MoE 두 개가 압도적이다. 그런데 둘 다 떨어졌다. 이유는 아래에서 하나씩 까보겠다 🔍
벤치마크 숫자가 안 맞으면 뭘 먼저 확인해야 할까?
칩 세대와 양자화 비트부터 확인해야 한다. 커뮤니티 벤치에서 훨씬 높은 숫자를 보면 “내 설정이 잘못됐나” 싶어진다. 나도 그랬다. 그 링크의 URL 파라미터를 열어봤더니 M5 Max에 40코어 GPU였다. 내 건 M4 Pro 16코어다. 세대가 다르고 GPU 코어가 2.5배 차이 난다.
참고로 AWQ 5비트는 4비트보다 더 느리다. 읽을 바이트가 늘어나니까 당연하다.
그다음 오진은 대역폭이었다. 처음 쟀을 때 161.7 GB/s가 나왔다. M4 Pro 사양은 273 GB/s인데 59%다. 하드웨어 고장을 의심했는데, 측정 방법이 부실했던 거였다.
- 버퍼가 작으면 커널 실행 오버헤드가 섞인다 → 최소 1GB 이상으로 잰다
- 읽기+쓰기 패턴은 항상 낮게 나온다 → 디코딩은 가중치를 읽기만 하므로 읽기 전용으로 잰다
제대로 재니 256.6 GB/s가 나왔다. 사양의 94%다. roofline으로 계산하면 상한이 17.1 tok/s인데 실측이 15.0이었다.
이미 하드웨어 한계의 88%였다. 튜닝으로 올릴 여지가 없었다는 뜻이다.
속도 문제의 절반은 왜 설정에서 나왔을까?
프리픽스 캐시가 아예 작동하지 않고 있었다. 3.8이 못 쓸 정도로 느껴졌던 건 decode 15 tok/s 때문이 아니었다.
7,000토큰짜리 프롬프트를 매 턴 다시 계산하고 있었다. 그것만 70초다.
원인은 두 개였다.
① 캐시 상한이 낮았다. 이 모델의 KV는 토큰당 73.2KB다. 상한 400MB면 5,400토큰이 한계인데, 툴 스키마가 붙은 실제 프롬프트는 7,000토큰이 넘는다. 로그에 rejected 7016 tokens가 찍혀 있었다. 1800MB로 올리니 동일 프롬프트 재전송이 70.31초 → 0.33초가 됐다.
② 채팅 템플릿이 prefix 관계를 깨고 있었다. 생성 프롬프트엔 thinking 서두를 붙이면서, 히스토리를 렌더할 땐 생략한다. 그래서 N번째 턴이 N+1번째의 접두가 될 수 없었다. Qwen3.5/3.6/3.8 템플릿엔 이미 preserve_thinking 플래그가 있다. 한 줄 켰더니 턴2가 12.0초, 턴3이 5.3초로 떨어졌다.
💡 교훈 — 프리픽스 캐시가 턴 사이에만 안 걸리면, 캐시나 클라이언트를 파기 전에 템플릿을 두 턴 렌더해서 s2.startswith(s1)을 확인하자. 몇 초면 끝난다.
5배 빠른 Qwen3.6-A3B는 왜 탈락했을까?
대화 이력에 답이 있는데도 도구로 되돌아가기 때문이다. 3.6은 반년 넘게 잘 쓰던 모델이다.
그런데 3.8과 나란히 놓으니 차이가 분명했다.
완료된 사실을 전망으로 뒤튼다
검색 스니펫에 “65세 이상 인구가 20%를 넘어섰다”를 넣고 요약을 시켰다.
- 3.6: “초고령사회에 진입할 것으로 전망되며…” ← 완료를 예측으로 변환
- 3.8: “20%를 넘어섬에 따라 공식적으로 진입했습니다” ← 원문 유지
뉴스 요약 용도에서 이건 치명적이다.
20회 반복 테스트: 65% vs 100%
검색 결과에 드라마 두 편을 넣고 “넷플릭스 오리지널 제목이 뭐야?”를 각 모델 20회씩 물었다. 서버를 우회해 파서 영향을 뺐다.
| 결과 | Qwen3.6-A3B | Qwen3.8-27B |
|---|---|---|
| 제목 정확히 회수 | 13/20 (65%) | 20/20 (100%) |
| 재검색으로 빠져 빈 응답 | 7/20 | 0/20 |
실패 케이스는 토큰은 생성했는데 본문이 비어 있다. 원본 출력을 찍어보니 텍스트 대신 툴 호출을 뱉고 있었다. 더 흥미로운 건 검색어다. 이미 답을 알고 있으면서 그걸 쿼리에 넣어 다시 검색하러 간다. 모르는 게 아니라 자기 대화 이력을 신뢰하지 않는다.
프롬프트로 막으려다 역효과를 봤다
“이미 답이 있으면 도구를 다시 호출하지 마”를 시스템 프롬프트에 넣고 10회씩 돌렸다.
- 지시 없음 → 정답 8/10, 재검색 2/10
- 한국어 지시 → 정답 0/10, 재검색 9/10
- 영어 지시 → 정답 1/10, 재검색 9/10
재검색이 20%에서 90%로 뛰었다. 정확히 반대 결과다. 추정 원인은 도구를 언급하는 것 자체가 도구 사용을 점화한다는 것이다. 한국어와 영어가 같은 방향으로 움직인 걸 보면 언어 문제도 아니다. 이 방향은 접었다 🙅
벤치마크가 더 높은 Ornith-1.5는 왜 탈락했을까?
모델 카드 벤치마크가 영어 코딩·에이전틱 과제였기 때문이다.
Terminal-Bench 67.8, SWE-bench 79, GPQA 89.2로 3.6을 전 항목에서 앞섰고, 속도도 71.3 tok/s로 예상대로였다.
그런데 실사용에서 무너졌다. 같은 스니펫 두 건을 주고 정리를 시켰다.
Ornith-1.5
“죄송하지만, 충분한 정보를 얻을 수 없어 정확한 정리를 드리기 어렵습니다. 검색 결과로 얻은 내용은 매우 제한적입니다…”
Qwen3.8-27B
“1. 초고령사회의 정의 — 65세 이상 비율 20% 이상… 2. 한국의 현황… 3. 정부의 대응 조치…”
Ornith는 스니펫을 읽고 나열까지 하고서 “정리할 수 없다”며 되물었다. 이어진 4턴에서도 같은 회피가 반복됐다.
3.8은 같은 두 건으로 구조화된 답을 만들고, 검색에 없던 7%/14%/20% 기준까지 채웠다.
한국어 출력에 중국어 토큰이 섞이는 것도 몇 번 눈에 띄었다. 다만 이건 실사용 중 우연히 관측한 것이고 횟수를 세지 않았다. 4비트 양자화 탓인지 모델 특성인지는 확인 못 했으니 참고만 하시길.
그래서 로컬 LLM은 뭘 기준으로 골라야 할까?
속도가 아니라 “틀린 답이 나오는 비율”로 골라야 한다. 세 모델을 갈아치우며 얻은 결론은 세 줄로 줄어든다.
- 속도는 닫힌 문제다. 대역폭 사양의 94%, roofline 대비 88%. 토큰당 읽는 바이트를 줄이는 것 말곤 방법이 없고, 그건 곧 모델을 바꾸는 거다.
- 느림의 절반 이상은 설정이었다. 캐시 상한과 템플릿 플래그 두 개로 실사용 턴이 70~190초에서 5~12초가 됐다.
- 아무리 빨라도 답이 틀리면 못 쓴다. 이게 최종 판단 기준이었다.
하나 더. 이 글을 쓰면서 실제로 저지른 실수인데, 표본 3회로 결론 내지 말자.
3회에서 1/3이 나와 “3.6은 33%”라고 적었다가, 20회로 다시 재니 65%였다.
참값이 65%여도 3회에서 1/3이 나올 확률은 약 20%다.
🙏 남은 바람은 하나다. Qwen3.8세대 27~36B급 MoE, 특히 35B-A3B가 나와주면 좋겠다.
현재 3.8 계열 MoE는 2.4T-A95B뿐이라 64GB 기기엔 애초에 안 올라간다.
3.8의 정확도에 A3B의 속도가 붙으면 로컬 LLM 판이 한 번 더 뒤집힌다.
그날까진 32초짜리 첫 턴을 견디며 쓸 생각이다 😌
자주 묻는 질문
Q. Qwen3.8-27B는 64GB 맥에서 돌아가나?
돌아간다. 4비트 양자화 기준 15GB다. 64GB 통합 메모리면 KV 캐시까지 넉넉하다.
Q. MoE가 5배 빠른데 왜 굳이 Dense를 쓰나?
웹 검색 결과 요약과 재질문 회수에서 정확도 차이가 컸다. 같은 질문 20회 기준 100% 대 65%였다. 다만 이건 한국어 검색 요약 용도 기준이다.
Q. 답변이 이상할 때 모델부터 바꿔야 하나?
아니다. 서버가 실제로 받은 요청부터 덤프해야 한다. 내 경우 클라이언트가 검색 결과를 히스토리에 저장하지 않고 있었다. 어떤 모델을 올려도 똑같이 틀렸을 조건이다.
Q. 프리픽스 캐시가 안 걸리면 뭘 봐야 하나?
로그의 entry_cap과 cache_fetch를 먼저 본다. 턴 사이에만 안 걸리면 채팅 템플릿의 prefix 성립 여부를 확인한다.
※ 이 글의 수치는 맥미니 M4 Pro 64GB에서 직접 측정한 값이다. 한국어 자연스러움·지시 이해도 같은 주관적 평가는 필자의 실사용 경험이며, 같은 모델이라도 용도가 다르면 결론이 달라질 수 있다.