M3 Max 36 GB 환경에서의 다섯 가지 엔진 성능 비교: Kapitsa 41 tok/s 밀집, Qwen3.6-35B-A3B에서

이 글은 2주 전 게시물의 후속 내용입니다. 당시 스레드에서 요청된 주요 내용은 일반적인 mlx-community 빌드 대신 oQ4e-mtp 체크포인트와 Lightning MTP를 사용하여 oMLX를 구동하는 것이었습니다. 저는 이를 수행하고, Kapitsa 0.2.12를 다섯 번째 엔진으로 추가했으며, Flint 40B-A2.5B를 테스트했습니다. 요약하자면: oMLX의 밀집(dense) 성능 수치가 완전히 바뀌었고, MoE 경쟁이 더 치열해졌으며, Rapid-MLX가 더 이상 저의 기본 선택지는 아닙니다.

TL;DR (M3 Max 36 GB, 지속적인 256 토큰 산문, 중앙값 3회):

• 밀집(Dense) Qwen3.8-27B-4bit: Kapitsa 41.3 tok/s , oMLX 34.1, Splash 33.0, MTPLX 31.6, Rapid 26.2.
• MoE Qwen3.6-35B-A3B: oMLX 122.9 , Kapitsa 122.7 (동률), Rapid 110.3, Splash 97.0, MTPLX 79.9.
• Flint 40B-A2.5B: Kapitsa 134.2, Rapid 103.0.

36 GB에서 구동되며, 저의 기본 선택지는 아닙니다. oMLX의 밀집 성능이 17.9에서 34.1로 급증한 것은 주로 체크포인트/추측(speculation) 변경(oQ4e-mtp + Lightning MTP) 때문이며, 순수 엔진만의 승리는 아닙니다. 초안 수용률은 밀집 방식의 경우 75–78%, MoE 방식의 경우 81–85%였습니다. 현재 저의 일일 기본 선택지는 35B-A3B에 대한 Kapitsa 0.2.12입니다 (클라이언트들이 변경하지 않도록 이전 qwen3.6-35b-4bit API 별칭을 유지했습니다).

설정 및 프로토콜: 14인치 M3 Max, 14코어 CPU / 30코어 GPU / 36 GB / 1 TB, macOS 27, AC 전원, 고성능 모드(High Power Mode), 30 GB GPU 유선 제한. 지속적인 부하가 걸리면 여전히 소음이 발생합니다.

엔진: oMLX 0.7.2 (Jundot oQ4e-mtp + Lightning MTP) / Rapid-MLX 0.16.8 (MTP 빌드) / Splash 1.4.0 (mlx-community + DFlash2) / MTPLX 2.12.2 (Optimized-Speed packs) / Kapitsa 0.2.12 (catalog 4-bit + MTP head + DFlash2 drafter)

Kapitsa는 저에게 새로운 엔진입니다: Qwen과 Flint 지원을 갖춘 코딩 에이전트를 목표로 하는 Apple silicon 엔진입니다. 각 엔진별로 하나의 셀(cell)을 사용하며, 두 개의 Flint 셀을 추가했습니다. 각 셀의 과정은 다음과 같습니다: 서버 중지, 해당 엔진의 지속적인 KV 캐시를 지우고, 새로 시작하여 지속 테스트 수행 (동일한 짧은 산문 프롬프트, 3회 × 256 토큰, temp 0, 지원되는 경우 reasoning_effort: none), 150초 간격 유지, 이후 프롬프트 크기 행렬(128:3, 2048:2, 8192:1 @ 256 토큰)을 처리하고 중지. 셀 사이는 300초 간격을 두었습니다. 총 12개의 셀이 모두 완료되었습니다. 가중치 파일은 동일하지 않습니다. 각 엔진은 자체적으로 가장 좋은 빌드를 실행합니다.

동일한 기본 모델 계열이지만 마감(finishing)이 다릅니다. 이것이 실제 선택지이지만, 이는 엔진 단독이 아닌 '엔진 + 빌드'라는 의미입니다. 중요하다고 판단되는 부분에 표시했습니다.

지속 디코딩 (Sustained decode) (중앙값 3, 최대치 256, 모든 실행에서 최대치 도달)

지난 게시물 이후 변경된 사항:

• oMLX: 17.9 / 104.2 → 34.1 / 122.9. MoE 게인은 +18%이며, dense 게인은 주로 추측이 마침내 사용된 것에 기인합니다. 지난번과 다른 체크포인트(checkpoint)이므로 이는 엔진 단독의 변화(delta)가 아닙니다.
• 'oMLX가 뒤처진다'는 댓글에 대해: MTP 빌드를 사용했을 때 현재 MoE 분야의 선두 주자이며, dense에서도 2위를 차지합니다. 일반적인 4비트 결과는 오해를 불러일으켰습니다.
• Splash: 31.7 / 77.0 → 33.0 / 97.0. 1.4.0 버전의 적응형(adaptive) MoE 초안 검증이 큰 변화입니다.
• Rapid: 27.7 / 110.2 → 26.2 / 110.3. Flat MoE의 경우 dense 성능이 약 5% 느립니다. 그 사이에 있었던 0.15.7 버전은 27.5 / 115.2였으므로, 0.16.8은 작은 단일 스트림(single-stream) 하락입니다. 이 버전의 릴리스 노트는 단일 스트림 속도가 아닌 Flint와 동시성(concurrency)에 초점을 맞추고 있습니다.
• MTPLX: 동일한 2.12.2 버전에서 31.5 / 79.0 → 31.6 / 79.9로 변경되었습니다. 이는 프로토콜이 안정적이라는 저의 검증(sanity check)입니다. 작성자가 지난 스레드에서 언급했던 35B greedy/MTP-depth 작업은 제가 아직 테스트할 수 있는 릴리스에 포함되어 있지 않으며, 현재 실행 기준으로 2.12.2가 여전히 최신 버전입니다.
• Kapitsa: 새로 추가되었습니다. 41.3 / 122.7. MoE에서는 oMLX와 동률이며, dense에서는 우위를 점합니다. 지난번의 'oMLX가 Splash보다 20% 느리다'는 언급은 여기서 반전됩니다 (dense에서 34.1 vs 33.0, MoE에서 122.9 vs 97.0). 하지만 다시 한번 말씀드리지만, 이는 oQ4e-mtp + MTP 대 Splash의 DFlash2 빌드이므로 엔진+빌드로 이해해야 합니다.

긴 프롬프트 행렬 (디코딩 tok/s; 목표 크기 128/2048/8192, 실제 프롬프트 토큰 ~100/1.4K/5.5K)
엔진 ~100 tok ~1.4K tok ~5.5K tok
Kapitsa dense 56.1 52.7 48.2
Kapitsa MoE 306.0* 226.5* 224.1*
Kapitsa Flint 133.8 129.3 119.3
oMLX dense 37.5 35.2 35.3
oMLX MoE 146.6 131.1 114.3
Splash dense 50.4 49.9 71.1*
Splash MoE 273.9* 211.3* 218.1*
Rapid dense 29.4 27.8 24.5*
Rapid MoE 213.2 122.6* 114.6*
Rapid Flint 102.5 96.5 91.8
MTPLX dense 36.3 30.0 26.0
MTPLX MoE 81.3 78.9 70.5

• = 최소한 하나의 실행이 256 토큰 이전에 중단됨 (36–214). 해당 속도는 지속적인 테이블과 비교할 수 없는 단기 샘플 버스트입니다. 반복적인 채우기(filler) 또한 추측 디코딩(speculative decoding)을 더 좋게 보이게 합니다. 따라서 산문(prose) 테이블이 공정한 측정치입니다.

8K TTFT (Time to First Token):
Kapitsa 3.8 s MoE / 32.9 s dense; Splash 4.1 / 22.0; Rapid 4.4 / 35.1; oMLX 4.5 / 35.7; MTPLX 4.9 / 36.7. Splash의 Neural Engine 프리필(prefill)은 지속적인 디코딩 속도가 세 번째임에도 불구하고 여전히 긴 밀집 프롬프트를 읽는 가장 빠른 방법입니다. TTFT는 디코딩 실행이 단기 샘플로 중단된 경우에도 유효합니다.

표준화된 rapidmlx 프로토콜 (pp512-tg128 / pp2048-tg512, 웜업 1회 + 측정 5회)
모델 pp512-tg128 pp2048-tg512
TTFT 512 / 2048
qwen3.5-9b-4bit 54.1 53.6 1.0 / 4.7 s
qwen3.8-27b-4bit 17.5 17.6 3.3 / 12.8 s
qwen3.5-4b-4bit 90.7 90.7 0.6 / 2.2 s
gemma-4-e4b-4bit 73.5 73.6 0.3 / 1.3 s
bonsai-1.7b-2bit 272.8 228.9 0.2 / 0.7 s
qwen3.6-35b-4bit 102.2 100.1 0.5 / 1.6 s

27B 행은 서비스 텍스트 레인(MTP 사용 시 34.1)이 아니라 MLLM/비전 레인(17.5)입니다. 이는 모순이 아닌 레인의 차이입니다. qwen3.6-35b-4bit를 포함하여 모두 여섯 개가 완료되었습니다. 이전에 21 토큰에서 중단되던 모델도 포함됩니다. 저는 이 여섯 번의 실행 결과를 리더보드에 공유했습니다.

Flint 40B-A2.5B Kapitsa 0.2.12 --model flint , RecursiveSI/flint-int4 4-bit MLX, 22.6 GB. 로딩 시간 약 9초, 컨텍스트 253,952, 슬롯 4개, 일반 디코딩 (드래프트/MTP 없음). 지속 속도 134.2 tok/s; 8K에서 119.3 토큰/s.
Rapid 0.16.8 flint-40b-a2.5b-4bit , 동일한 체크포인트. 36 GB에서 실행되지만 48 GB 이상이 권장됨; 추측(speculation) 없음. 103.0 tok/s; 8K에서 91.8 토큰/s.

oMLX 0.7.2, Splash 1.4.0, MTPLX 2.12.2에서 Flint 지원을 찾을 수 없었습니다. 기본 모델은 아니지만, 36 GB는 빠듯하며, 35B-A3B가 더 나은 일일 에이전트 모델입니다. 하지만 36 GB 노트북에서 134 tok/s의 40B 성능은 이번 테스트에서 가장 놀라운 결과였습니다.

품질 주의사항: 공식적인 품질 평가는 없습니다. 이것은 속도에 관한 게시물이며, 품질 판결이 아닙니다. 지난번에 사람들이 지적했던 주요 격차였으며, 여전히 해결되지 않았습니다. 추측 디코딩(Speculative decoding)은 동점 근처의 출력을 변경할 수 있습니다.

oMLX의 MTP 수용률은 밀집(dense)에서 75–78% / MoE에서 81–85%였습니다. 수용률 자체가 품질을 의미하는 것은 아니지만, 속도 중 얼마나 많은 부분이 추측에 의한 것인지를 알려줍니다. Splash 1.4.0 자체 로그는 MoE --verify-rows auto가 실행마다 탐욕적(greedy)/시드된 출력을 변경할 수 있다고 경고합니다. 결정론적인 출력(deterministic outputs)이 필요하다면, --verify-rows all을 사용하거나 추측 기능을 꺼야 합니다.

저는 메모리를 12–24시간 동안 충분히 테스트(soak-test)하지 않았습니다. 여기서 가장 긴 셀은 약 5분입니다. 지난 스레드에서 언급된 oMLX의 메모리 문제는 이번 테스트를 통해 검증되지 않았으며, 단지 이 짧은 실행에서는 문제가 발생하지 않았다고만 말할 수 있습니다. 노트북 한 대, 세션 하나이며, 다이 온도 로깅(die-temperature logging)은 하지 않았습니다. 150초/300초의 냉각 시간은 열 제어(thermal control)를 위한 것입니다. (테스트 안 함 / 나중에 할 예정).

지난 스레드에서 언급된 unsloth GGUF 제안. 속도표 옆에 적절한 KL/작업 품질 평가(task quality eval). 단일 완료(single completions)보다는 긴 에이전트 세션(tool calls, multi-turn) 테스트. 특히 oMLX의 경우 12–24시간 메모리 충분히 테스트(memory soak).

제가 선택할 것은 일일 사용용으로 35B-A3B와 Kapitsa 0.2.12입니다. 이는 MoE에서 oMLX와 동률(122.7 vs 122.9, 내부 노이즈)이며, 밀집(dense)에서는 우세하고, JSON-schema 구조화된 출력을 문서화합니다. oMLX의 brew 빌드는 여전히 xgrammar가 부족합니다. 만약 에이전트 통합 기능에 의존한다면 Rapid는 여전히 합리적인 보수적 선택이지만, 현재 서비스되는 MoE 워크로드에서는 약 10% 뒤처져 있습니다.

밀집(Dense)에서는 27B Kapitsa 41.3, 그 다음 oMLX가 34.1입니다. 긴 프롬프트 사전 채우기(long-prompt prefill)가 디코딩보다 더 중요하다면, Splash의 8K TTFT (22초 대 ~33–37초)를 살펴보는 가치가 있습니다.

40B: Kapitsa의 Flint. 마지막 참고 사항: 이 프로젝트들 중 어느 것과도 제휴 관계가 없습니다. 저는 그저 맥북을 가진 사용자일 뿐입니다. /u/Hyungsun이 r/LocalLLaMA에 제출함 [링크] [댓글]