요약(TL;DR): 저는 9일 동안 MLX 모델을 위한 새로운 양자화 (quantization) 방법을 개발했으며, 단일 M5 Max MacBook Pro (128 GB)에서 18개의 변형 모델을 서로 비교 측정했습니다. 그 결과, 제가 알고 있는 모든 크기 중에서 Qwen3.5-122B-A10B에 대해 가장 성능이 뛰어난 MLX 양자화 모델이 탄생했습니다. 82 GiB 빌드는 9495 GiB 6-bit 빌드보다 우세하며, native MLX 상태를 유지하면서 imatrix-rounded 소스 GGUF와 0.30.7% 이내의 차이를 보입니다. Apache 2.0 라이선스이며, 가중치(weights)는 HF(HuggingFace)에 업로드되었습니다. GGUF가 더 나은데 왜 굳이 이걸 써야 할까요? Apple Silicon에서의 MLX는 동일한 하드웨어에서의 llama.cpp보다 실질적으로 더 빠릅니다. 제 M5 Max에서 측정했을 때 prefill은 약 9배 더 빠르고, 토큰 생성 (token generation)은 약 20% 더 빠릅니다. 긴 컨텍스트 (long context)와 많은 대화 턴이 필요한 작업일수록 그 격차는 더욱 커집니다. 문제는 기존의 6-bit 미만 MLX 양자화 모델들의 성능이 좋지 않다는 것이며, 이는 아래 표에서 확인할 수 있습니다: oQ4는 소스 GGUF 대비 짧은 컨텍스트에서 약 3.8%, 긴 컨텍스트에서 약 4.2%의 퍼플렉시티 (perplexity) 손실을 보입니다. 실제 환경에서는 이것이 일관성 없는 추론 과정 (reasoning traces)과 반올림 오차로 나타나며, 모델이 환각 (hallucination)을 일으키기 시작할 때까지 누적됩니다. 따라서 더 나은 MLX 양자화 방법은 에이전트 워크플로우 (agentic workflows)와 Apple Silicon 기반의 로컬 AI에 실질적인 이점을 제공합니다. 동시에, 저는 native MLX 지원을 필수적으로 요구하기로 의식적인 결정을 내렸습니다. MLX에서의 imatrix는 포맷 네이티브 (format native)가 아니며, 커스텀 커널 (custom kernels)이 필요합니다. WinterMix 양자화 모델은 포맷 네이티브이며 즉시 교체 가능한 (drop-in replacements) 모델입니다. WinterMix 양자화 모델은 오픈 가중치 (Apache 2.0)를 가진 포맷 네이티브 MLX 모델입니다. 커스텀 커널도, 포크된 런타임 (forked runtime)도, 플래그 (flags)도 필요 없습니다. LM Studio, mlx-vlm 및 관련 도구 등 MLX가 작동하는 어디에서나 기본 속도로 로드되며, 비전 타워 (vision tower)가 완전히 기능하고 일관된 추론 과정을 보여줍니다. 그냥 바로 써보고 싶다면: 아래 저장소(repo)를 다운로드하고 LM Studio에서 해당 경로를 지정하기만 하면 됩니다. HuggingFace 링크 WinterMix58 — 82 GiB, 6.0 bpw: 9495 GiB 6-bit oMLX 빌드와 비교했을 때를 포함하여 (2K에서 근소하게, 16K에서 더 명확하게), 제가 알고 있는 이 모델의 모든 크기 중 가장 성능이 뛰어난 MLX 양자화 모델입니다.

WinterMix48 — 68 GiB, ~5.0 bpw: 128 GB Mac에서 약 35–40 GB의 여유 공간을 남김 = 5–8개의 100K-token 에이전트 세션(agent sessions)을 동시에 상주 가능 (GDN 아키텍처는 100K 세션의 캐시를 약 5–10 GB로 유지함). 두 컨텍스트 길이 모두에서 직접적인 크기 경쟁 모델(oQ4, 67 GiB)을 약 1.4–1.5% 차이로 능가함. 모든 행에 대해 One scoring rule 적용 (각 윈도우의 후반부에 대한 NLL, 엔진 간 토큰 정렬 — llama.cpp의 네이티브 규칙이므로 Unsloth의 결과와 비교 가능), 두 모델 모두 MLX에서 실행되는 경우 per-token 쌍을 적용함. 참조 행은 동일한 토큰, 동일한 머신을 사용하는 본인의 하네스(harness)에서 측정됨. oMLX는 현재 MLX의 대중적인 옵션이므로 oMLX 양자화 모델(quants)을 포함함. 모든 행은 다양한 양자화 혼합 방식의 Qwen3.5-122B-A10B임.

한계점에 대해 솔직히 말씀드리자면: imatrix-rounding이 적용된 소스 GGUF가 여전히 약간 앞서 있습니다 (+0.3–0.7% rule-matched 기준). MLX에서 imatrix 스타일의 가중치 반올림(weighted rounding)을 구현하려면 커스텀 추론 커널(inference kernels)이 필요하며, "순정 속도로 모든 것을 로드한다"는 점은 제가 타협하고 싶지 않았던 엄격한 제약 사항이었습니다. 네이티브 포맷 내에서는 이것이 거의 한계인 것으로 보입니다.

정말 흥미롭다고 생각하는 부분: 이 프로젝트의 중간 단계에서 저는 퍼플렉시티(perplexity)가 양자화 모델 간의 실제 행동 차이를 포착하지 못한다는 사실을 발견했습니다. 통계적으로 동일한 NLL을 가진 두 빌드가 50K-token 추론 트레이스(reasoning traces) 동안 스스로 말을 끊는 횟수("잠시만요, 다시 확인해 볼게요...")에서 2.5배 차이가 났습니다. 그러다 반대의 상황이 저를 덮쳤습니다. 제 NLL이 가장 낮은 빌드가 스스로 말을 끊는 횟수가 더 높게 나타났는데, 실제로 트레이스를 읽어보니 그것은 혼란이 아니라, 최종 답변을 내놓기 전 베이스 모델의 추론 버그를 두 번이나 잡아내는 절제된 검토 과정(audit passes)이었음이 드러났습니다.

따라서 출시된 모델들은 세 가지 지표를 통해 선정되었습니다: 쌍을 이룬 NLL (Negative Log-Likelihood), 심층적인 블라인드 스코어링 상태 추적(state-tracking) 벤치마크, 그리고 추론 흔적(reasoning traces)을 직접 읽는 방식입니다. 두 출시 버전 모두 모든 시드(seed)에 대해 30단계 적대적 상태 추적(adversarial state-tracking) 작업에서 완벽한 점수를 기록했습니다. 특히 68 GiB 빌드의 흔적을 보면, 출력이 나가기 전에 스스로 4비트 산술 오류(4-bit arithmetic slips)를 잡아내는 것을 확인할 수 있습니다. 만약 양자화 모델(quants)을 평가한다면, 저는 솔직히 무엇인가를 세는 것보다 흔적(traces)을 읽어보는 것을 추천합니다.

내부 작동 원리 (간략히):
민감도 기반 혼합 정밀도 할당 (Sensitivity-informed mixed-precision allocation, MoE 라우터는 양자화되는 것을 선호하지 않으므로 라우팅에 중요한 텐서들은 BF16으로 고정), MLX 아핀 형식(affine format)에 맞춰 네이티브로 재구현되어 레이어별로 실행되는 GPTQ 계열의 오류 보정 반올림 (GPTQ 전체 모델을 128 GB에서 122B 모델로 실행 시 OOM(Out of Memory)이 발생하므로, 스트리밍 방식을 사용하여 피크 시 약 28 GB를 사용), 그리고 모든 레이어의 모든 전문가(expert)가 실제로 보정될 수 있도록 설계된 다양한 롱 컨텍스트(long-context) 보정 혼합물(calibration mixture) — 여기에는 다국어 콘텐츠가 포함됩니다. 영어 전용 보정 세트는 언어 특화 전문가들을 조용히 굶주리게(starves) 만든다는 사실이 밝혀졌기 때문입니다. 쌍을 이룬 대조군 및 홀드아웃 도메인 외(held-out out-of-domain) 체크를 통해 18개의 측정된 변형 모델에 대해 검증되었습니다 (보정 결합 없음: 코드/수학 분야가 RTN 대비 ±0.1% 이내).

현재 파이프라인 코드는 공개하지 않을 예정입니다. 모델은 오픈 웨이트(open weights, Apache 2.0)이지만, 방법론에 대한 기술서는 비공개로 유지됩니다. 분위기를 전달하는 데 도움이 될까 하여 덧붙이자면, 워크로드를 길들여내기 전까지 개발 과정에서 M5 Max가 열 번이나 커널 패닉(kernel-panicked)을 일으켰습니다.

다른 모델의 MLX 양자화 요청을 받을 계획입니다. 댓글이나 HF(Hugging Face) 커뮤니티 탭에 남겨주세요. 실질적인 제약 사항으로는, 128 GB Mac에서 파이프라인이 돌아가야 하며 (최대 약 120B+ MoE까지 검증됨), 밀집 모델(dense models)은 MoE와 보정 방식이 다르기 때문에 아키텍처별로 튜닝하기 전까지는 결과가 다를 수 있습니다. 평가 방법론, 행동 테스트, Apple Silicon의 특이점(watchdog panics에 대해 물어보세요), 또는 Mac 롱 컨텍스트 에이전트 설정에 관한 질문은 언제든 환영합니다.

/u/WinterCharm 님이 r/LocalLLaMA에 게시함 [link] [comments]