Qwen3.8-27B 설치부터 시작하기: Mac 로컬 배포 및 성능 최적화 가이드

Qwen3.8-27B 가 출시되었습니다.

일반 Mac 에서도 실행할 기회가 생겼습니다.

메모리, 속도, 컨텍스트 —

이 가이드에서 한 번에 설명합니다.

최근 두 가지 소식이 겹쳤습니다.

8월 14일, Qwen3.8-27B 가 공식적으로 가중치를 공개했습니다. 2주도 채 지나지 않아 Apple 은 M5 Max 및 M5 Ultra 를 탑재한 새로운 Mac Studio 를 출시하며 로컬 AI 성능과 최대 512GB 통합 메모리를 강조했습니다.

이러한 소개를 읽고 나면, Mac 에서 Qwen3.8-27B 를 실행하려면 최신 Mac Studio 를 구매해야 하거나, 심지어 Ultra 를 바로 선택해야 한다는 착각에 빠지기 쉽습니다.

사실, 그렇게까지 과장된 것은 아닙니다.

과거에는 27B Dense 모델이 실제로 로컬 사용자에게 선호되는 선택이 아니었습니다. Dense 모델의 특징은 토큰을 생성할 때마다 모든 주요 파라미터를 읽고 계산해야 한다는 것입니다. 24GB 급 기기에서는 양자화 후에도 간신히 메모리에 맞았으며, 초기 커뮤니티 테스트에서는 종종 초당 한 자릿수에서 낮은 두 자릿수 토큰 속도만 보여주었습니다.

반면, 35B-A3B 와 같은 MoE 모델은 총 파라미터 수는 더 많지만, 생성 시 약 3B 파라미터만 활성화되어 잠재적으로 몇 배 더 빠를 수 있습니다. 코드를 지속적으로 읽고, 도구를 호출하고, 파일을 반복적으로 수정해야 하는 Agent 의 경우, 모델 성능이 아무리 뛰어나도 매 라운드마다 시간이 오래 걸리면 일상적인 도구가 되기 어렵습니다. 따라서 많은 로컬 사용자들은 이전에 MoE 를 우선시했습니다.

이제 상황이 바뀌기 시작했습니다.

양자화 형식, Apple Silicon 추론 프레임워크, 새로운 세대의 디코딩 가속 방법이 점차 성숙해지면서 27B Dense 모델이 처음으로 성능과 속도의 균형을 맞출 기회를 얻었습니다. 반드시 최신 Ultra 가 필요하지는 않습니다. 24GB 및 32GB Mac 은 4비트 버전으로 시작할 수 있으며, 48GB 이상을 보유한 사용자는 더 유연한 옵션을 선택할 수 있습니다.

진짜 질문은 더 이상 "로드할 수 있는가"가 아니라, 양자화 버전을 선택하는 방법, 컨텍스트와 메모리를 제어하는 방법, 생성 속도를 실제로 사용 가능한 수준으로 조정하는 방법입니다.

이 글은 처음부터 재현 가능한 배포를 완료합니다. 먼저 메모리 요구 사항을 계산하고, 가속 없이 기본 속도를 실행한 다음, 동일한 작업으로 A/B 테스트를 수행하고, 마지막으로 OpenAI 및 Anthropic 클라이언트가 호출할 수 있는 로컬 API 로 모델을 실행합니다.

지금 배포할 계획이 없다면, 먼저 북마크에 추가해 두는 것이 좋습니다. 나중에 더 큰 메모리의 Mac 으로 업그레이드하거나 로컬 모델을 코드 Agent, 지식 베이스 및 자동화 워크플로우에 연결할 준비가 되면 이 가이드를 따라하면 됩니다.

결론부터: 내 Mac 에서 실행할 수 있을까?

통합 메모리만 고려한다면, 이 표를 사용하여 결정할 수 있습니다.

이 표는 "모델을 켤 수 있는지"의 절대적인 경계가 아니라 "안정적으로 작동할 수 있는지"에 대한 제안입니다.

일부 24GB Mac 은 실제로 4비트를 로드할 수 있지만, 성공적인 로드가 장기간 사용에 적합하다는 것을 의미하지는 않습니다. macOS, 브라우저, 개발 도구, 모델 실행 버퍼, 컨텍스트 캐시 및 DFlash 2 드래프트 모델 모두 동일한 통합 메모리를 두고 경쟁합니다. 모델은 시작 시 괜찮아 보일 수 있지만, 긴 코드를 입력한 후 스와핑이 시작될 때 가장 일반적인 오류가 발생합니다.

또한, 이 튜토리얼은 M1, M2, M3, M4 및 M5 시리즈 Mac 을 포함하는 Apple Silicon 에만 적용됩니다. Intel Mac 은 이 MLX 방식을 따르지 않습니다.

27B 가 정확히 무엇일까? 일반적인 오해 바로잡기

모델 이름의 'B'는 Billion 을 나타냅니다.

따라서 27B 는 약 270억 개의 파라미터를 의미하며, 2700억 개가 아닙니다.

파라미터는 훈련 후에 남은 큰 숫자 집합이라고 생각할 수 있습니다. 모델이 토큰을 생성할 때마다 이 숫자들을 읽고 계산하여 다음 토큰이 무엇인지 결정해야 합니다. 27B 는 270억 개의 노브가 있는 기계와 같습니다. 훈련은 노브를 올바른 위치로 조정하는 역할을 하고, 로컬 추론은 이러한 노브를 메모리에 로드하고 지속적으로 읽는 역할을 합니다.

Qwen3.8-27B 는 Dense 모델입니다. Dense 는 간단히 말해 생성되는 모든 토큰에 대해 주요 파라미터가 계산에 참여한다는 의미입니다.

이는 이름에 A3B 또는 A10B 가 포함된 MoE 모델과 다릅니다. 예를 들어, 35B-A3B 모델은 총 350억 개의 파라미터를 저장할 수 있지만, 매번 약 30억 개의 파라미터만 활성화합니다. 모든 가중치를 위한 저장 공간을 준비해야 하지만, 토큰당 계산 및 메모리 읽기는 훨씬 적습니다.

따라서 두 모델이 모두 "약 30B"라고 말한다고 해서 속도, 메모리 사용량 및 성능 수준이 비슷하다고 가정할 수 없습니다. 총 파라미터, 활성 파라미터, 모델 아키텍처 및 양자화 정밀도를 함께 고려해야 합니다.

Qwen3.8-27B 는 전통적인 "모든 레이어에 대한 전체 어텐션" 모델이 아닙니다. 공식 모델 카드에 따르면 64개의 레이어로 구성되어 있으며, Gated DeltaNet 과 Gated Attention 의 하이브리드 아키텍처를 사용합니다. 대략 선형 어텐션 3개 레이어마다 표준 어텐션 1개 레이어가穿插되어 있습니다. 기본적으로 262,144 토큰 컨텍스트를 지원하고, 이미지 및 비디오 이해 기능을 갖추고 있으며, 생각 모드가 기본적으로 활성화되어 있고, reasoning_effort 를 통해 추론 깊이를 조정할 수 있습니다.

이러한 기능은 코드, 연구, 긴 작업 및 Agent 에 적합한 이유를 설명합니다. 또한 배포 시 단순히 "27B"만 보면 안 되는 이유를 설명합니다.

그 성능은 어느 정도일까?

개인용 컴퓨터의 로컬 모델을 대략적으로 분류하면 다음과 같습니다.

• 3B–8B: 빠른 시작, 낮은 점유율, 일반 Q&A, 간단한 추출 및 경량 도구 호출에 적합합니다. 복잡한 작업은 쉽게 벗어나기 쉽습니다.
• 14B–30B: 현재 가장 실용적인 고품질 범위로, 코드 생성, 긴 텍스트 처리, 구조화된 분석 및 Agent 작업을 안정적으로 처리하기 시작합니다.
• 70B 이상 Dense: 전반적인 안정성이 종종 더 강력하지만, 메모리 용량 및 대역폭 요구 사항이 크게 증가하고 개인 배포 비용이 훨씬 높아집니다.

Qwen3.8-27B 는 "개인 기기가 현실적으로 배포할 수 있고, 성능이 프로덕션 워크플로우에 진입하기에 충분한" 위치에 있습니다.

공식 모델 카드에서 SWE-bench Pro 61.7점, Terminal Bench 2.1에서 73.0점을 기록했습니다. 동일한 표에서 Opus 4.6 Max 는 각각 53.4점과 78.2점을 기록했습니다. 이 결과는 일부 코딩 및 터미널 Agent 작업에서 Qwen3.8-27B 가 클로즈드 소스 플래그십과 동일한 표에서 논의될 자격이 있음을 나타냅니다.

하지만 이것을 "27B 가 클로즈드 소스 플래그십을 완전히 능가한다"고 다시 쓰지 마십시오.

벤치마크는 프롬프트, 샘플링 파라미터, 도구 환경, 테스트 프레임워크 및 추론 예산의 영향을 받습니다. 공식 모델 카드는 또한 다양한 테스트에 사용된 하네스를 공개했습니다. 더 높은 점수는 특정 테스트 조건에서 더 나은 성능을 보였음을 의미할 뿐, 지식의 폭, 개방형 추론, 긴 텍스트 안정성, 시각적 기능 및 실제 워크플로우에서 앞서 있음을 의미하지는 않습니다.

더 정확한 포지셔닝은 다음과 같습니다. 클로즈드 소스 플래그십을 완전히 대체하는 것은 아니지만, 진지하게 작업을 처리할 수 있는 로컬 모델입니다.

실제 결정 요인은 메모리 계산입니다

많은 사람들이 "모델 파라미터 수"를 "실행 메모리"와 직접 동일시합니다. 27B이므로 27GB가 필요하다고 생각합니다.

이 계산은 잘못되었습니다. 파라미터 수에 각 파라미터가 차지하는 비트 수를 곱해야 합니다.

270억 개의 파라미터에 대해 대략적으로 계산하면 다음과 같습니다.

• BF16: 파라미터당 2바이트, 원래 가중치는 약 54GB입니다.
• 8비트: 파라미터당 약 1바이트, 이론값은 약 27GB입니다.
• 4비트: 파라미터당 약 0.5바이트, 이론값은 약 13.5GB입니다.

이론값은 주요 가중치만 계산합니다. 실제 모델 저장소에는 양자화 스케일, 구성, 어휘, 시각적 구성 요소 등도 포함됩니다. Hugging Face 의 MLX 커뮤니티 버전은 4비트의 경우 약 16.1GB, 8비트의 경우 약 29.5GB입니다. 텍스트 BF16 커뮤니티 변환은 약 54GB라고 명시적으로 언급합니다.

이것은 단지 "파일 크기"일 뿐, "시작 후 차지하는 공간"이 아닙니다. 모델은 실행될 때 최소한 네 가지 유형의 공간을 소비합니다.

1. 컨텍스트 캐시

모델은 이미 읽은 내용을 기억해야 합니다. 그렇지 않으면 새 토큰마다 모든 것을 처음부터 다시 계산해야 합니다. 표준 어텐션 부분은 KV Cache 를 사용하고, 선형 어텐션 레이어는 자체 상태를 가지고 있습니다.

컨텍스트가 길수록 캐시도 커집니다. mlx-dspark 프로젝트의 테스트에 따르면 Qwen3.8-27B 의 128K 컨텍스트에서 캐시는 약 11GB를 추가할 수 있습니다. 전체 256K 컨텍스트는 약 23GB를 추가할 수 있습니다.

이것이 "모델이 262K를 지원한다"는 것이 24GB Mac 이 262K를 열어야 한다는 의미가 아닌 이유입니다. 성능 제한은 모델이 처리할 수 있는 것이지, 사용자 기기의 편안한 기본값이 아닙니다.

2. 실행 버퍼 및 임시 활성화

모델이 긴 프롬프트를 읽는 단계를 Prefill 이라고 합니다. 이 단계에서는 많은 양의 입력을 한 번에 처리해야 하므로 메모리와 계산 압력이 갑자기 증가할 수 있습니다. "안녕하세요"라고 말할 때의 메모리 스크린샷은 20,000 토큰의 코드를 붙여넣은 후의 상황을 나타내지 않습니다.

3. macOS 및 기타 애플리케이션

Apple Silicon 의 CPU 와 GPU 는 통합 메모리를 공유합니다. 이것이 MLX 효율성의 기초이자 메모리 예산을 보수적으로 설정해야 하는 이유입니다. 모델, 시스템, Chrome, Cursor, Docker 및 기타 프로그램은 모두 동일한 풀에서 공간을 두고 경쟁합니다.

4. DFlash 2 드래프트 모델

DFlash 2 는 무료 스위치가 아닙니다. 추가 드래프트 모델과 해당 캐시를 로드해야 합니다. 프로젝트는 최대 채팅 길이 참조를 제공합니다. 4비트 대상 모델과 드래프트의 경우 약 18GB, 8비트의 경우 약 29GB입니다. 이는 여전히 macOS 공간을 예약하지 않습니다.

따라서 완전한 공식은 다음과 같아야 합니다.

실제 메모리 = 모델 가중치 + 컨텍스트 캐시 + 실행 버퍼 + 드래프트 모델 + macOS 및 기타 앱

이 공식을 이해하는 것은 어떤 블로거의 컴퓨터 속도를 기억하는 것보다 중요합니다.

4비트, 8비트, BF16: 어떻게 선택할까?

양자화는 모델 파라미터를 더 간결하게 기록하는 것으로 이해할 수 있습니다. 비트가 낮을수록 모델이 메모리를 절약하고 일반적으로 더 빠릅니다. 대가는 일부 정밀도 손실입니다.

일반 Mac 사용자의 경우 다음과 같이 선택하는 것이 좋습니다.

24GB / 32GB: 4비트로 바로 시작

모델 저장소:

1mlx-community/Qwen3.8-27B-4bit

4비트 파일은 약 16.1GB입니다. 24GB는 시도해 볼 수 있지만, 대규모 백그라운드 애플리케이션을 적극적으로 닫고 8K–16K 컨텍스트로 시작해야 합니다. 32GB는 일상적인 사용에 더 적합합니다.

24GB가 "로드할 수 있다"고 해서 계속해서 초장기 컨텍스트와 DFlash 2 를 쌓지 마십시오. 먼저 안정적으로 실행한 다음 변수를 하나씩 추가하십시오.

48GB / 64GB: 8비트 고려

모델 저장소:

1mlx-community/Qwen3.8-27B-8bit

8비트 파일은 약 29.5GB입니다. 48GB는 현실적인 시작점이며, 64GB는 더 편안합니다. 속도, 컨텍스트 공간 및 시스템 여유를 더 중요하게 생각한다면 64GB에서도 계속 4비트를 사용할 수 있습니다. "더 높은 정밀도"를 위해 8비트를 강제할 필요는 없습니다.

BF16: "맞출 수 있다"를 "사용하기 적합하다"로 취급하지 마십시오

BF16 텍스트 가중치는 이미 약 54GB입니다. 64GB Mac 은 이론적으로 맞출 수 있지만, 시스템, 캐시 및 버퍼를 추가하면 여유 공간이 매우 작아집니다. 실제 장기간 사용하려면 96GB 이상을 고려하는 것이 좋습니다.

대부분의 사람들에게 4비트와 8비트 간의 경험 차이는 "메모리 부족으로 스와핑 시작"으로 인한 차이보다 훨씬 작습니다. 지속적인 스와핑이 발생하면 어떤 양자화 정밀도도 응답 속도를 구할 수 없습니다.

배포 전 준비: 칩, 메모리 및 디스크 확인

먼저 터미널을 열고 시스템 정보를 확인합니다.

1system_profiler SPHardwareDataType

Apple M 시리즈 칩과 통합 메모리 용량을 확인해야 합니다.

그런 다음 디스크를 확인합니다.

1df -h .

사용 가능한 공간을 모델 볼륨의 최소 두 배 이상 남겨 두는 것이 좋습니다. 다운로드 프로세스 중에 캐시가 생성될 수 있으며, 그 다음 드래프트 모델, 여러 양자화 버전 및 로그가 이어집니다. 4비트의 경우 35GB 이상, 8비트의 경우 60GB 이상의 여유 공간을 준비하는 것이 가장 좋습니다.

이 튜토리얼은 uv를 사용하여 Python 환경을 관리합니다. 설치되지 않은 경우:

1brew install uv

독립적인 디렉토리와 가상 환경을 만듭니다.

1mkdir -p qwen38-local/models
2cd qwen38-local
3
4uv venv .venv
5source .venv/bin/activate

이렇게 하면 "전문적으로 보이기" 위한 것뿐만 아니라 MLX, Transformers 및 기타 프로젝트 간의 종속성 상호 오염을 방지할 수 있습니다. 나중에 사용하지 않으려면 이 프로젝트 디렉토리를 삭제하기만 하면 됩니다.

필요한 도구를 설치합니다.

1uv pip install -U huggingface_hub mlx-dspark

mlx-dspark는 현재 Apple Silicon 과 Python 3.10 이상이 필요하며, mlx-lm, mlx-vlm 및 적절한 MLX 종속성을 자동으로 설치합니다.

모델 다운로드: 브라우저에서 파일을 하나씩 클릭하지 마십시오

대규모 모델은 일반적으로 여러 가중치 샤드로 분할됩니다. 브라우저에서 하나씩 다운로드하면 중단, 파일 누락 및 재개 불편이 발생하기 쉽습니다. 더 안정적인 방법은 공식 Hugging Face hf 명령을 사용하는 것입니다.

4비트 다운로드 명령

1MODEL_DIR="$PWD/models/Qwen3.8-27B-4bit"
2
3hf download mlx-community/Qwen3.8-27B-4bit \
4  --local-dir "$MODEL_DIR"

8비트 다운로드 명령

1MODEL_DIR="$PWD/models/Qwen3.8-27B-8bit"
2
3hf download mlx-community/Qwen3.8-27B-8bit \
4  --local-dir "$MODEL_DIR"

새로운 버전의 Hugging Face Hub 는 Xet 청크 다운로드를 사용하며, 기본적으로 네트워크에 따라 적응형 동시성을 사용합니다. 대부분의 사람들은 이전 튜토리얼에서 오래된 hf_transfer 구성을 복사할 필요가 없습니다.

이 "고성능 다운로드" 스위치도 볼 수 있습니다.

1HF_XET_HIGH_PERFORMANCE=1 hf download ...

무턱대고 활성화하지 마십시오. Hugging Face 공식 문서에 따르면 동시성, 버퍼링 및 CPU 사용량을 증가시켜 최소 64GB 메모리를 갖춘 고대역폭 시스템에 더 적합합니다. 저메모리 Mac 은 리소스 경합으로 인해 실제로 더 느릴 수 있습니다. 24GB 및 32GB 시스템은 먼저 기본 설정을 사용해야 합니다.

다운로드 후 디렉토리 크기를 확인합니다.

1du -sh "$MODEL_DIR"

첫 실행: 먼저 기본 속도 테스트, DFlash 2 를 서두르지 마십시오

로컬 모델 배포에서 가장 흔한 실수는 한 번에 10개의 최적화 옵션을 켜는 것입니다. 결국 빠르게 실행될 수도 있지만, 누구 덕분인지 알 수 없습니다. 느리게 실행되면 누구를 꺼야 할지 알 수 없습니다.

올바른 순서는 먼저 기준을 실행하는 것입니다.

고정 프롬프트를 준비하고, 가능하면 실제 작업에 가깝게 만드십시오. 예를 들어, 주로 코딩에 사용한다면 다음을 사용할 수 있습니다.

1Please implement a thread-safe cache in Python that supports expiration time and LRU eviction. Explain the design first, then provide the full code and tests.

기준 테스트:

1mlx-dspark generate \
2  --model "$MODEL_DIR" \
3  --mode baseline \
4  --prompt "Please implement a thread-safe cache in Python that supports expiration time and LRU eviction. Explain the design first, then provide the full code and tests." \
5  --max-new-tokens 600

네 가지 숫자를 기록합니다.

1. 모델 로딩 시간.
2. 프롬프트 처리 속도 (Prefill tok/s).
3. 첫 번째 토큰까지의 시간 (TTFT).
4. 공식 생성 속도 (generation tok/s).

생성 속도는 "단어가 하나씩 나오는 속도"를 결정하는 반면, Prefill 및 TTFT 는 "Enter 키를 누른 후 기다려야 하는 시간"을 결정합니다. 코드 Agent 의 경우 매 라운드마다 많은 양의 시스템 프롬프트와 코드를 다시 읽어야 할 수 있으므로 Prefill 은 종종 순수 생성 속도보다 사용자 경험에 더 큰 영향을 미칩니다.

테스트 중에는 "활성 상태 보기 → 메모리"를 열어 메모리 압력과 스왑을 관찰하십시오. 노란색이 반드시 즉각적인 문제를 의미하는 것은 아니지만, 스왑이 계속 증가하면 이 구성에 안정적인 여유가 없음을 의미합니다.

50 토큰만 실행하지 마십시오. 짧은 답변은 로딩 및 워밍업 시간이 너무 높은 비율을 차지하게 하고 지속적인 생성 중 실제 속도를 보여주지 않습니다. 최소 400–1000 토큰을 생성하는 것이 좋습니다.

DFlash 2 는 어떻게 27B 를 더 빠르게 실행할까?

일반 디코딩은 직렬입니다. Qwen3.8-27B 가 하나의 토큰을 생성하면 전체 대상 모델이 한 번 실행됩니다. 다음 토큰을 생성하면 다시 실행됩니다. 1000개의 토큰을 생성하려면 약 1000번의 연속 라운드가 필요합니다.

DFlash 2 는 더 가벼운 드래프트 모델을 추가합니다. 드래프트 모델은 먼저 병렬로 후보 토큰 세트를 제안한 다음, 27B 메인 모델이 이를 집합적으로 검증합니다. 올바른 추측은 한 번에 여러 개를 수락할 수 있는 반면, 잘못된 추측은 메인 모델에 의해 수정됩니다.

다음과 같이 생각할 수 있습니다.

• 드래프트 모델은 빠른 초안 작성을 담당하는 어시스턴트입니다.
• 27B 메인 모델은 최종 결정권을 가진 편집장입니다.
• 어시스턴트가 연속으로 올바르게 추측할수록 편집장이 수행해야 하는 전체 라운드가 줄어듭니다.

드래프트 모델은 출력을 독립적으로 결정하지 않습니다. DFlash 2 모델 카드에 따르면 그리디 디코딩에서 출력은 대상 모델과 일치합니다. 무작위 샘플링 중에는 대상 모델의 분포를 유지합니다.

또한 모든 시나리오에서 가속이 보장되지는 않습니다.

작업으로 인해 드래프트 모델을 예측하기 쉬운 경우(예: 코드 완성 또는 안정적인 형식의 긴 텍스트) 수락 길이는 일반적으로 더 높습니다. 내용이 크게 도약하거나, 답변이 매우 짧거나, 샘플링 무작위성이 높은 경우 드래프트는 종종 거부되고 추가 계산으로 인해 이득이 소모될 수 있습니다.

DFlash 2 활성화: 도구가 스스로 보정하도록 하고, 다른 사람의 파라미터를 복사하지 마십시오

먼저 프로젝트에 내장된 벤치마크를 실행합니다.

1mlx-dspark benchmark \
2  --model "$MODEL_DIR" \
3  --modes dflash \
4  --caps auto \
5  --trials 3

여기서 --modes dflash를 명시적으로 지정하는 이유는 현재 버전의 벤치마크가 기본적으로 DSpark 및 lookup 을 테스트하고 Qwen3.8-27B 의 DFlash 2 로 자동 전환되지 않기 때문입니다. 첫 번째 실행은 일치하는 드래프트 모델을 다운로드합니다. --caps auto는 Mac, 대상 모델 및 양자화 버전에 따라 적절한 드래프트 캡을 테스트합니다. M1 Max, M4 Pro 및 M5 Max 는 메모리 대역폭과 계산 비용이 다르므로 최적의 파라미터가 정확히 동일해서는 안 됩니다.

따라서 다른 사람이 --max-draft 7을 작성했다고 해서 영구적으로 복사하는 것은 권장되지 않습니다. 자동 보정이 먼저 답을 제공하도록 한 다음 실제 작업으로 다시 테스트하십시오.

동일한 프롬프트를 사용하여 자동 모드를 활성화합니다.

1mlx-dspark generate \
2  --model "$MODEL_DIR" \
3  --mode auto \
4  --prompt "Please implement a thread-safe cache in Python that supports expiration time and LRU eviction. Explain the design first, then provide the full code and tests." \
5  --max-new-tokens 600

이제 기준과 비교합니다.

• 출력 텍스트가 일치합니까?
• TTFT 가 크게 길어졌습니까?
• generation tok/s 가 얼마나 향상되었습니까?
• 평균 수락 길이는 얼마입니까?
• 피크 메모리와 스왑이 악화되었습니까?

이 명령은 기본적으로 그리디 디코딩을 사용하므로 기준과 자동 모드의 출력 텍스트는 매우 드문 부동 소수점 동점 경우를 제외하고는 일치해야 합니다. 답변이 크게 다른 경우 속도를 논의하기 전에 프롬프트, 생각 모드, 샘플링 파라미터 및 소프트웨어 버전이 동일한지 확인하십시오. 무작위 샘플링 중에 DFlash 2 는 대상 분포를 유지하지만 두 번 생성된 특정 단어가 동일하다고 보장하지는 않습니다.

mlx-dspark 프로젝트의 프로젝트 벤치마크에서 M4 Pro 48GB 의 경우 8비트는 약 8.4 tok/s에서 30.5 tok/s로 향상되어 평균 약 3.63배입니다. 4비트는 약 14.7 tok/s에서 33.8 tok/s로 향상되어 평균 약 2.30배입니다.

이는 특정 버전, 시스템, 핫 스타트 상태 및 테스트 프롬프트에서의 결과이며, 약속이 아닙니다. 프로젝트 자체의 분할 데이터는 채팅, 코드 및 수학 작업에 따라 가속 비율이 다르다는 것을 보여줍니다.

진정으로 유용한 기준은 "다른 사람이 30 tok/s에 도달했다"가 아니라 사용자의 빈번한 작업이 빨라졌는지 여부입니다.

일반적으로 모델이 코드를 수정하도록 한다면 실제 저장소의 수정 작업으로 테스트하십시오. 글을 쓰는 데 사용한다면 1500 토큰을 연속으로 생성하십시오. Agent 를 연결하려면 전체 도구 호출을 실행하십시오. 실제 작업의 총 시간이 감소하는 경우에만 DFlash 2 를 계속 켜 두는 것이 좋습니다.

모델을 로컬 API 로 실행

기본 및 자동 모드가 모두 안정적임을 확인한 후에는 모델을 상주 서비스로 만들 수 있습니다. 24GB Mac 의 경우 먼저 컨텍스트를 8K로 제한합니다.

1mlx-dspark serve \
2  --model "$MODEL_DIR" \
3  --mode auto \
4  --context-window 8192

32GB는 16K로 시작할 수 있습니다. 안정화 후 점차 32K로 증가시킵니다.

1mlx-dspark serve \
2  --model "$MODEL_DIR" \
3  --mode auto \
4  --context-window 16384

서비스가 시작된 후 다른 터미널에서 상태를 확인합니다.

1curl http://127.0.0.1:8080/health
2curl http://127.0.0.1:8080/v1/models

/health는 실제 모드, 컨텍스트 제한 및 메모리 경고를 반환합니다. /v1/models는 클라이언트가 입력해야 하는 모델 ID를 제공합니다.

두 가지 유형의 클라이언트에 대한 주소를 혼동하지 마십시오.

1OpenAI Base URL: http://127.0.0.1:8080/v1
2Anthropic Base URL: http://127.0.0.1:8080
3Anthropic Messages route: /v1/messages

OpenAI 및 Anthropic 호환 인터페이스를 모두 제공합니다. 사용자 정의 Base URL 을 지원하는 채팅 클라이언트, 코드 도구 및 Agent 는 일반적으로 연결할 수 있습니다.

curl로 대화 테스트를 수행합니다. 다음은 4비트에 대해 반환된 모델 ID를 예로 사용합니다. 8비트를 다운로드한 경우 /v1/models에서 반환된 실제 값으로 바꾸십시오.

1curl http://127.0.0.1:8080/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model": "Qwen3.8-27B-4bit",
5    "messages": [
6      {"role": "user", "content": "Explain what unified memory is in three sentences."}
7    ],
8    "max_tokens": 200
9  }'

로컬 시스템에서만 사용하는 경우 127.0.0.1이 가장 안전하고 쉬운 선택입니다. 일부 클라이언트는 API Key 를 강제로 입력하도록 합니다. 자리 표시자 문자열을 입력하면 됩니다. 인증이 활성화되지 않은 경우 로컬 서비스는 이를 확인하지 않습니다.

LAN 액세스가 필요한 경우에만 수신 주소 및 방화벽 수정을 고려하십시오. 인증, TLS 또는 속도 제한이 없는 인터페이스를 공개 인터넷에 직접 노출하지 마십시오. 모델이 로컬에서 실행된다고 해서 서비스가 자연스럽게 안전한 것은 아닙니다.

메모리가 폭발하지 않도록 컨텍스트를 설정하는 방법은?

가장 안정적인 방법은 추측이 아니라 단계적으로 증가시키는 것입니다.

1. 24GB는 8K부터 시작하고, 안정화된 후 16K를 시도하세요.
2. 32GB는 16K부터 시작하고, 그 다음 32K를 시도하세요.
3. 48GB / 64GB는 32K부터 시작하고, 작업에 따라 필요 시 64K를 시도하세요.
4. 정말로 초장문 문서나 대규모 코드베이스를 처리할 때만 128K까지 계속 늘리세요.

레벨을 올릴 때마다 동일한 테스트를 반복하세요: 고정 프롬프트, 고정 최대 출력, TTFT, 생성 속도, 최대 메모리, Swap을 기록하세요.

"모델이 262K를 지원한다"는 것은 기능 매개변수일 뿐, 기본 권장 사항이 아닙니다. 일상적인 채팅, 글쓰기, 대부분의 코딩 작업에서는 16K–32K로도 많은 시나리오를 이미 커버할 수 있습니다.

더 큰 컨텍스트가 더 똑똑하다는 의미는 아닙니다. 너무 많은 관련 없는 콘텐츠를 집어넣으면 핵심 정보가 희석되어 모델이 더 느려지고, 비용이 더 많이 들며, 주제에서 벗어날 가능성이 높아집니다.

서비스를 Agent에 사용하는 경우, Prefix Cache 유지를 우선시하세요. 코드 Agent의 시스템 프롬프트와 도구 정의는 종종 매우 깁니다. 여러 라운드에 걸쳐 프리픽스를 재사용하면 반복적인 Prefill을 크게 줄일 수 있습니다.

사고 모드 선택 방법? 테스트에서 가장 간과하기 쉬운 변수

Qwen3.8은 기본적으로 답변하기 전에 생각합니다. 복잡한 코드 수정, 수학적 추론, 연구 분석, 다중 라운드 Agent 작업의 경우 기본 사고 모드를 유지할 수 있습니다. 일반 채팅, 번역, 요약, 형식 변환의 경우 사고 과정은 종종 대기 시간과 출력 토큰만 늘립니다.

사고를 유지하되 추론 깊이를 줄이려면 전체 명령어를 사용하세요:

1mlx-dspark serve \
2  --model "$MODEL_DIR" \
3  --mode auto \
4  --context-window 16384 \
5  --reasoning-effort low

작업이 매우 직접적이라면 사고를 끌 수 있습니다:

1mlx-dspark serve \
2  --model "$MODEL_DIR" \
3  --mode auto \
4  --context-window 16384 \
5  --no-thinking

이 두 매개변수는 서비스의 기본 동작을 설정합니다. 관련 필드를 지원하는 클라이언트는 요청별로 이를 재정의할 수도 있으므로, 도구를 연결한 후 클라이언트가 자체 기본값으로 조용히 되돌리지 않았는지 확인하세요.

모든 작업에 적합한 단일 답변은 없습니다. "낮음"은 라운드당 더 빠르게 보일 수 있지만, 분석 부족으로 Agent가 반복적으로 재시도하게 하여 전체 작업 속도를 늦출 수 있습니다. 가장 신뢰할 수 있는 방법은 여전히 전체 작업의 총 시간을 계산하는 것이며, 첫 번째 라운드 답변만 비교하는 것이 아닙니다.

한 가지 규칙을 기억해야 합니다: baseline과 DFlash 2 A/B 테스트를 할 때는 사고 모드가 동일해야 합니다. 하나는 사고 켜짐이고 다른 하나는 꺼짐이면 토큰 수와 작업 경로가 변경되어 계산된 속도는 비교 의미가 없습니다. 샘플링 매개변수, 프롬프트, 최대 출력 길이, 컨텍스트, 콜드/핫 스타트 상태도 일관되어야 합니다.

최단 배포 경로: 필요한 명령어를 함께 압축하기

앞서 논의한 것은 각 단계를 수행하는 이유입니다. 원리를 이미 이해하고 빠르게 재현하고 싶다면 다음 순서로 실행할 수 있습니다. 예시는 4비트와 8K 컨텍스트를 선택하며, 24GB Mac에서 보수적인 시작에 적합합니다. 다운로드 및 벤치마크의 실제 시간은 네트워크와 칩에 따라 달라지며 "최단"에 포함되지 않습니다:

1brew install uv
2
3mkdir -p qwen38-local/models
4cd qwen38-local
5uv venv .venv
6source .venv/bin/activate
7
8uv pip install -U huggingface_hub mlx-dspark
9
10MODEL_DIR="$PWD/models/Qwen3.8-27B-4bit"
11hf download mlx-community/Qwen3.8-27B-4bit \
12  --local-dir "$MODEL_DIR"
13
14mlx-dspark generate \
15  --model "$MODEL_DIR" \
16  --mode baseline \
17  --prompt "통합 메모리를 설명하고 로컬 대규모 모델 실행을 위한 세 가지 제안을 해주세요." \
18  --max-new-tokens 400
19
20mlx-dspark benchmark \
21  --model "$MODEL_DIR" \
22  --modes dflash \
23  --caps auto \
24  --trials 3
25
26mlx-dspark serve \
27  --model "$MODEL_DIR" \
28  --mode auto \
29  --context-window 8192

이 명령어 세트의 목표는 "먼저 안전하게 실행"하는 것이지 하드웨어를 최대한 활용하는 것이 아닙니다. 성공적으로 실행된 후 메모리 여유에 따라 16K 및 32K 컨텍스트를 순서대로 시도하거나 4비트 저장소를 8비트로 교체하세요. 한 번에 하나의 변수만 변경해야 테스트 데이터가 의미 있습니다.

서비스가 시작된 후 서드파티 클라이언트에 서두르지 말고 먼저 /health와 /v1/models에 접근하세요. 전자는 메모리 경고가 없고 예상 모드가 실제로 활성화되었는지 확인하며, 후자는 모델 ID를 확인합니다. 그런 다음 약 400 토큰의 긴 답변을 완료하고 Activity Monitor에서 메모리 압력과 Swap을 관찰하세요. 네 가지 모두 정상이면 Base URL을 일상적인 도구에 입력하세요. 이 몇 분의 확인으로 대부분의 "클라이언트 연결 불가" 및 "실행 후 전체 시스템이 느려짐" 문제를 제거할 수 있습니다.

다음 날 다시 시작하는 방법?

가상 환경과 MODEL_DIR은 현재 터미널 세션에서만 유효합니다. 다음 날 터미널을 다시 열면 다시 다운로드하거나 재설치할 필요 없이 디렉토리로 돌아가 환경을 활성화하고 경로를 다시 선언하기만 하면 됩니다:

1cd qwen38-local
2source .venv/bin/activate
3MODEL_DIR="$PWD/models/Qwen3.8-27B-4bit"
4
5mlx-dspark serve \
6  --model "$MODEL_DIR" \
7  --mode auto \
8  --context-window 8192

도구를 업그레이드할 때는 가상 환경 내에서 실행하세요:

1uv pip install -U huggingface_hub mlx-dspark

업그레이드 후, 장기 서비스를 재개하기 전에 먼저 짧은 baseline과 /health를 실행하여 모델을 여전히 로드할 수 있는지 확인하세요. 추론 도구는 빠르게 업데이트되며, 이전 버전에서 작동했던 매개변수가 항상 최선은 아니므로 자신의 baseline 기록을 유지하는 것이 가치 있습니다.

LAN 액세스: 최소한 잠금 장치를 추가하세요

기본 127.0.0.1은 로컬 시스템에서만 액세스할 수 있습니다. 동일한 Wi-Fi에 있는 다른 Mac이나 iPad가 이를 호출하도록 하려면 모든 네트워크 카드에서 수신하고 동시에 API Key를 설정할 수 있습니다:

1mlx-dspark serve \
2  --model "$MODEL_DIR" \
3  --mode auto \
4  --context-window 16384 \
5  --host 0.0.0.0 \
6  --api-key "충분히 긴 임의의 문자열로 바꿔주세요"

클라이언트는 127.0.0.1을 이 Mac의 LAN IP로 바꾸고 요청에 Authorization: Bearer your_key를 보냅니다. 또한 macOS 방화벽을 확인하여 신뢰할 수 있는 네트워크만 포트 8080에 액세스하도록 허용하세요.

이것은 여전히 LAN 솔루션일 뿐입니다. 인터넷을 통해 액세스하려면 TLS, 리버스 프록시, 액세스 제어, 속도 제한도 필요합니다. 라우터에서 8080을 직접 매핑하지 마세요. 가장 쉬운 방법은 신뢰할 수 있는 VPN을 통해 홈 네트워크로 돌아온 다음 로컬 서비스에 액세스하는 것입니다.

일반적인 문제 해결

1. 로딩 중간에 시스템에 의해 모델이 종료됨

먼저 올바른 양자화 버전을 선택했는지 확인하세요. 24GB와 32GB는 8비트를 잘못 다운로드해서는 안 되며, BF16은 절대 건드리지 마세요. Docker, 가상 머신, 많은 브라우저 탭, 기타 로컬 모델을 닫은 다음 4비트를 다시 시도하세요.

2. 실행은 되지만 Mac 전체가 매우 느려짐

Activity Monitor를 열어 Swap을 확인하세요. Swap이 계속 증가하면 먼저 컨텍스트를 줄인 다음 DFlash 2를 끄세요. 모델 프로세스 자체의 숫자만 보지 마세요. 통합 메모리 압력은 전체 시스템이 함께 일으키기 때문입니다.

3. DFlash 2가 실제로 더 느림

비교 조건이 일관된지 확인하세요: 동일한 프롬프트, 동일한 출력 길이, 동일한 사고 모드, 동일한 콜드 스타트 또는 핫 스타트. 짧은 답변은 추측적 디코딩 이득을 판단하는 데 적합하지 않습니다. 세 라운드 이상 실행하고 실제 긴 작업으로 테스트하세요.

여전히 느리다면 현재 작업 수락률이 낮거나 드래프트 모델이 가져온 추가 메모리로 인해 시스템이 스와핑을 시작했음을 의미합니다. 끄는 것은 실패가 아닙니다. 안정적인 baseline은 이미 효과적인 솔루션입니다.

4. 첫 번째 토큰은 매우 느리지만 후속 생성은 괜찮음

이것은 Prefill 병목 현상입니다. 입력이 너무 긴지, 매 라운드마다 많은 수의 관련 없는 파일이 반복적으로 채워지는지, Prefix Cache가 적중하는지 확인하세요. Agent의 경우 프롬프트 길이를 최적화하는 것이 생성 tok/s를 계속 추구하는 것보다 종종 더 효과적입니다.

5. 다운로드 속도가 매우 느리거나 중단됨

동일한 hf download 명령어를 다시 실행하여 캐시와 재개를 활용하세요. 완료되지 않은 디렉토리를 삭제하고 처음부터 시작하지 마세요. Hugging Face 액세스가 불안정할 때는 공식 권장 ModelScope 경로를 고려하세요.

6. 이미지 인식을 원함

"모델에 시각 기능이 있음"과 "현재 서비스가 시각 입력을 지원함"을 구분하세요. 앞서 언급한 MLX 저장소는 시각 구성 요소를 유지하지만, mlx-dspark는 현재 텍스트 추론 서비스를 제공합니다. 여기에 전송된 이미지 콘텐츠는 모델에 들어가지 않습니다.

이미지를 테스트하려면 일시적으로 DFlash 2를 우회하고 mlx-vlm을 대신 사용해야 합니다:

1uv run python -m mlx_vlm.generate \
2  --model "$MODEL_DIR" \
3  --max-tokens 200 \
4  --temperature 0 \
5  --prompt "이 이미지를 설명해주세요." \
6  --image "/absolute/path/example.jpg"

시각 입력은 처리 복잡성과 메모리 점유율을 증가시킵니다. 주요 용도가 코드, 글쓰기, Agent라면 먼저 텍스트 체인을 안정화한 다음 시각 작업을 별도로 테스트하세요.

가장 실패할 가능성이 적은 배포 순서

실행 체크리스트:

1. Apple Silicon Mac인지 확인하세요.
2. 16GB는 27B를 포기하세요. 24GB/32GB는 4비트를 선택하세요. 48GB/64GB는 8비트를 고려하세요.
3. 모델을 위한 충분한 디스크 공간을 확보하고 uv를 사용하여 독립적인 환경을 만드세요.
4. hf download를 사용하여 전체 저장소를 다운로드하세요. 브라우저에서 가중치 파일을 하나씩 클릭하지 마세요.
5. --mode baseline으로 고정 프롬프트를 먼저 실행하여 로딩, Prefill, TTFT, 생성 속도, 메모리를 기록하세요.
6. 8K, 16K 또는 32K 컨텍스트로 시작하세요. 전체 262K를 직접 열지 마세요.
7. mlx-dspark benchmark --modes dflash --caps auto --trials 3를 실행하여 도구가 사용자 시스템에 맞게 보정하도록 하세요.
8. 정확히 동일한 실제 작업으로 baseline과 auto를 비교하세요.
9. 속도가 크게 향상되고 메모리 압력이 안정적일 때만 DFlash 2를 장기적으로 활성화하세요.
10. 마지막으로 로컬 API를 시작하고 코드 도구, 지식 베이스 또는 Agent를 연결하세요.

로컬 배포의 의미는 단지 API 비용을 절약하는 것만이 아닙니다.

Qwen3.8-27B가 Mac에서 언제든지 호출할 수 있는 로컬 서비스가 되면, 민감한 코드와 문서를 자체 시스템에 보관하고, 오프라인으로 자료를 처리하며, 자동화 작업, 개인 지식 베이스, 장기 실행 Agent 워크플로우에 연결할 수 있습니다.

제 개인적인 통과 기준은 간단합니다: 일반적인 작업에서 Swap이 발생하지 않고, 답변 속도가 참을 만하며, 다음 날에도 적극적으로 열어볼 의향이 있습니다. 이 세 가지가 충족될 때만 배포가 진정으로 성공한 것입니다.

이미 실행에 성공했다면 댓글로 "칩 모델, 통합 메모리, 4/8비트, 컨텍스트 길이, baseline 및 DFlash 2 tok/s"를 남겨주세요. 데이터가 충분하면 Mac 구성 테스트 표로 계속 정리할 수 있습니다.

여전히 배포가 번거롭다고 생각된다면

이 글에 포함된 설치 명령어, 모델 다운로드, 속도 테스트, DFlash 2 가속, 로컬 API 시작, 일반적인 문제 해결을 바로 따라할 수 있는 배포 체크리스트로 정리했습니다:

1https://github.com/wdwxw/macRunqwen38_27b_install

직접 순서대로 복사하여 실행하거나, 이 GitHub 저장소를 Codex나 Claude Code에 직접 제공하여 README.md를 읽고 Mac 구성을 확인한 후 체크리스트에 따라 설치를 완료하도록 할 수 있습니다. 이렇게 하면 긴 글에서 명령어를 반복해서 찾을 필요가 없으며, 후속 업데이트와 문제 해결도 더 편리합니다.