Mac Studio M3 Ultra 512 GiB의 Qwen 3.6 35B·27B 운영 최적화 후속 검증

소스 카드

• 소스 유형: 로컬 재현 벤치마크, 공식 런타임 문서, 공개 커뮤니티 실험, 공개 이슈
• 조사 기준일: 2026-07-27
• 분석 대상: Qwen 3.6 35B-A3B 및 27B의 Apple Silicon 추론 성능, 장문 prefill, 병렬성, KV/prompt cache, MTP·dFlash, 런타임 안정성
• 조사 경로:
  • 넓은 연구 질문과 비교 축의 초기화: broad paper research
  • 식별된 최신 게시글과 공개 이슈의 회수·검증: MT110 + Hermes + Insane Search
  • 공식 지원 범위 확인: Qwen, llama.cpp, MLX-LM, vLLM-Metal 공개 문서
• 추출 품질:
  • 텍스트 본문과 공개 표: 검증 가능
  • 이미지에만 있는 표: 수치 재사용에서 제외
  • 커뮤니티 댓글: 정성적 운영 신호로만 사용

핵심 요약

현재 재현된 운영 기본값은 llama.cpp다. 35B는 각 슬롯에 131,072 context를 보장한 p8 구성에서 32K 입력 8건을 모두 완료했고 평균 TTFT는 97.4초였다. 이 결과는 단순히 parallel=8을 높인 것이 아니라 총 context와 prompt cache를 함께 확장한 capacity 실험이다. 27B는 p1이 장문 안정성의 균형점이며 p2와 p4는 prefill 대역폭과 KV 경합 때문에 TTFT 또는 timeout이 악화됐다.

MLX-LM과 oMLX는 반복 prefix 및 짧은 요청에서 유망하지만, 새로운 100K~131K 입력의 prefill, SSE 종료, 모델 identity, memory pressure를 통과하기 전에는 운영 기본값으로 승격할 근거가 부족하다. vLLM-Metal은 Apple Silicon용 비교 런타임으로 의미가 있지만, 현재 관찰된 32K 무본문 SSE와 일부 모델 형상 불일치 때문에 장문 운영 경로로 채택하지 않는다.

MTP와 dFlash는 runtime build, 모델 변환, context 길이, tool workload마다 별도 A/B가 필요하다. 높은 acceptance가 곧 낮은 latency를 뜻하지 않으며, 공개 Apple Metal 이슈와 커뮤니티 경험 모두 성능 저하·반복·툴 호출 문제를 보고한다.

커버리지 맵

범위	배치	근거
M3 Ultra 512 GiB 직접 성능	분석 완료	로컬 재현 벤치마크
Qwen 3.6 공식 Apple Silicon 지원	분석 완료	Qwen3.6 공식 저장소의 Local Use
llama.cpp 병렬·continuous batching·cache	분석 완료	llama.cpp HTTP server 문서
MLX-LM prompt cache·장문 메모리	분석 완료	MLX-LM 공식 저장소
vLLM-Metal 지원 범위	분석 완료	vLLM-Metal 공식 문서
최신 한국 커뮤니티 게시글	분석 완료	MT110 + Hermes + Insane Search로 회수한 한정 URL 집합
이미지에만 있는 벤치마크 표	사용 제외	OCR 없이 정확한 수치 검증 불가
다른 하드웨어의 수치	분리 기록	M3 Ultra 결과로 일반화하지 않음

직접 재현 결과

모델·런타임	조건	관찰 결과	판정
Qwen 3.6 35B-A3B Genesis-Hermes, llama.cpp p8	고정 131K 슬롯, 32K × 8	평균 TTFT 97.4초, 8/8 완료	capacity 기본값
같은 35B 경로	fresh 32K prefill	약 1,883.86 prompt tok/s	서버 prefill 지표이며 proxy wall time과 다름
Qwen 3.6 27B Heretic, llama.cpp p1	context 131,072	fresh decode 약 15.13 tok/s	안정성 우선 specialist
같은 27B 경로	32K × 4	p1 평균 TTFT 215.1초, 3/4 완료; p2 평균 323.3초	p1 유지
27B MLX-LM 6-bit	fresh 8K/32K/65K	424/201/133 prompt tok/s	context 증가에 따라 prefill 저하
35B MLX-LM	fresh 131K / 동일 prefix 반복	235.043초 / 약 1.176초	cache hit를 신규 prompt 성능으로 오해하면 안 됨
35B oMLX tool 후보	짧은 검증 profile	tool call 포함 5/5 통과	장문·lifecycle 검증 전 후보
vLLM-Metal 35B MLX 5-bit	8K / 32K SSE	짧은 요청 통과, 32K는 160초 동안 body 없음	장문 서비스 미승격
vLLM-Metal 27B MLX 6-bit	language-model-only 초기화	vision weight shape mismatch	conversion·지원 형식 재검증 필요

p1/p2/p4/p8은 런타임 내부 슬롯 수이고, 클라이언트 동시 요청 수와 같은 값이 아니다. 35B p8 결론을 27B p8이나 다른 runtime의 concurrency 8로 전이해서는 안 된다.

공개 커뮤니티 근거

Apple Silicon

M1 Max 64GB에서 MLX로 측정된 Qwen 3.⁶ 35B-A3B oQ6 결과는 M3 Ultra 결과가 아니다. 다만 dFlash의 context 민감성을 보여 주는 보조 근거다.

조건	dFlash on	dFlash off
pp1024/tg128	670/199 tok/s	717/53 tok/s
pp8192/tg128	936/183 tok/s	931/48 tok/s
pp16384/tg128	876/172 tok/s	892/45 tok/s
pp131072/tg128	286/74 tok/s	180/23 tok/s

해당 게시글은 peak memory 40.05GB를 보고했다. 이 수치는 장치·quant·MLX build가 다른 공개 관측이므로 M3 Ultra 운영값을 대체하지 않는다.

다른 하드웨어와 정성적 신호

• Qwen 3.6 27B MTP depth 3에 정착했다는 운영 경험이 있으나, 본문에 재현 가능한 성능 표는 없다.
• 같은 토론에서 dFlash는 짧은 채팅보다 agent tool call·반복·100K급 장문 acceptance에서 문제가 있었다는 의견이 제시됐다.
• DGX Spark의 vLLM 장문 부하에서 MTP, 262K context, concurrency를 동시에 높였을 때 장치 hard reset 사례가 보고됐다. Apple Silicon 수치가 아니라 조합 위험을 보여 주는 경고로만 사용한다.
• OpenWebUI의 텍스트 서식 설정 때문에 Python 표현이 잘못 보인 사례는 모델 인식 오류가 아니라 presentation 변환 문제였다. 모델·runtime·UI 변환을 분리해 진단해야 한다.

공식 지원과 런타임 해석

Qwen 공식 저장소는 Qwen 3.6을 llama.cpp의 text·vision 경로와 Apple Silicon의 mlx-lm text 경로, mlx-vlm vision 경로에서 지원한다고 안내한다. 공식 예시의 262,144 context는 지원 예시이지, 특정 Mac에서 그 길이와 concurrency가 동시에 안정적이라는 보증은 아니다.

llama.cpp server는 parallel decoding, continuous batching, prompt/KV cache와 timing 지표를 제공한다. 운영 비교에서는 prompt throughput, predicted/decode throughput, TTFT, terminal completion을 분리해야 한다. HTTP 200이나 첫 토큰만으로 성공을 판정하지 않는다.

MLX-LM의 prompt caching은 동일 prefix 반복에 매우 효과적일 수 있다. 반대로 fresh long prefill은 별도 비용이므로 exact-repeat 결과를 신규 131K 입력 성능으로 제시하면 안 된다. MLX-LM server 문서는 production 보안 경계로 권장되지 않으므로 외부 노출은 별도 gateway가 필요하다.

vLLM-Metal은 MLX 기반 Apple Silicon 플러그인이지만, 지원 모델·변환·stream lifecycle은 버전별로 재검증해야 한다.

MTP와 dFlash의 판정

공개 llama.cpp 이슈에서는 Apple Metal에서 Qwen 3.⁶ 35B-A3B self-MTP가 95.6% acceptance를 기록하고도 baseline 26.²³ tok/s에서 1.⁹³ tok/s로 저하된 사례가 있다. 다른 공개 이슈에서는 MTP cleanup 뒤 depth 3 상대 성능이 이전 빌드의 85~90%로 낮아지고 depth 2가 95%였다고 보고했다. 이미지 평가 crash와 27B 장시간 반복 출력 이슈도 별도로 보고됐다.

따라서 MTP/dFlash 승격 조건은 다음과 같다.

1. exact build와 model artifact를 고정한다.
2. short chat, tool call, 32K, 100K~131K를 각각 측정한다.
3. acceptance와 실제 wall latency를 함께 기록한다.
4. 반복 출력, tool schema, terminal SSE, cancellation을 확인한다.
5. baseline보다 나빠지면 즉시 비활성화할 수 있어야 한다.

운영 권장안

목적	기본 선택	이유
35B 다중 장문 capacity	llama.cpp p8, 고정 131K 슬롯	직접 32K × 8 완료
27B 안정성·fallback	llama.cpp p1	p2/p4 대비 장문 TTFT·timeout 위험이 낮음
반복 prefix 실험	격리된 MLX-LM/oMLX	cache 이점은 크지만 fresh long prefill과 lifecycle 검증 필요
agent/tool 특화 후보	격리된 oMLX 후보	짧은 tool profile은 통과했지만 운영 승격 근거는 아님
MTP/dFlash	기본 off, build별 canary	acceptance만으로 성능·정확성을 보장하지 못함
vLLM-Metal	비교·호환성 실험	장문 SSE와 model format 문제가 남음

재현 가능한 다음 실험

1. 동일한 공개 prompt fixture로 1K, 8K, 32K, 65K, 100K, 131K fresh와 exact-repeat를 분리한다.
2. 각 runtime에서 request concurrency와 내부 parallel을 독립 축으로 둔다.
3. TTFT, prompt tok/s, decode tok/s, wall latency, completion ratio, peak memory, cache hit 여부를 기록한다.
4. tool call·strict JSON·SSE 종료·cancel·timeout을 성능 표와 같은 수준의 승격 조건으로 둔다.
5. MTP/dFlash는 depth별 A/B와 장시간 agent loop를 포함하고, runtime update마다 canary를 다시 실행한다.
6. 다른 장치의 공개 수치는 장치·메모리·quant·runtime·build를 함께 표시하고 M3 Ultra 측정값에 합산하지 않는다.

소스 주장과 분석자 판단

소스가 직접 말하는 것

• Qwen 공식 문서는 llama.cpp와 MLX 계열의 Qwen 3.6 지원 경로를 제시한다.
• llama.cpp와 MLX-LM 문서는 parallel·batching·cache 기능을 제공한다.
• 공개 커뮤니티와 이슈는 특정 build와 장치에서 MTP/dFlash 성능·정확성 회귀를 보고한다.
• 로컬 벤치마크는 특정 설정에서 35B p8과 27B p1의 완료율·TTFT·throughput을 기록했다.

분석자 판단

• 현재 운영 기본값은 llama.cpp가 가장 근거가 많다.
• MTP/dFlash는 기능 토글이 아니라 runtime-version-sensitive 실험 항목으로 관리해야 한다.
• Apple Silicon에서 unified memory 용량만으로 parallel을 계속 높일 수 없으며, prefill bandwidth와 KV/cache pressure가 함께 제한한다.
• DRA 같은 연구 시스템은 수치와 그 수치의 장치·build·workload locator를 함께 저장해야 후속 agent가 잘못 일반화하지 않는다.

제한과 열린 질문

• 커뮤니티 게시글의 이미지 전용 표는 OCR 검증 전 수치 근거에서 제외했다.
• 공개 이슈는 특정 build의 보고이며 최신 build 전체를 대표하지 않는다.
• 로컬 결과는 단일 장치와 현재 model artifact 집합에 대한 운영 근거다.
• MLX/oMLX의 100K~131K fresh prefill, 장기 SSE, memory pressure soak는 추가 검증이 필요하다.
• 27B MTP depth 2와 3의 동일 Apple Silicon·동일 build 비교가 아직 없다.

개인정보 검토

• 제거한 범주: 사설 endpoint, 계정·테넌트 정보, 장치 식별자, 세션·요청 식별자, 자격 증명, 내부 파일 경로
• 유지한 공개 메타데이터: 공개 프로젝트·모델 이름, 공개 URL, 공개 benchmark 조건
• 자동 검사: 통과
• 수동 맥락 검토: 완료
• 게시 상태: 재사용 가능

참고문헌

공식 문서

• Qwen3.6: https://github.com/QwenLM/Qwen3.6 — Local Use, Deployment
• llama.cpp HTTP server: https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md — Features, common parameters, metrics
• MLX-LM: https://github.com/ml-explore/mlx-lm — prompt caching, long-model memory guidance
• MLX-LM server: https://github.com/ml-explore/mlx-lm/blob/main/mlx_lm/SERVER.md — server security limitation
• vLLM-Metal: https://docs.vllm.ai/projects/vllm-metal/en/latest/ — Apple Silicon plugin overview

공개 커뮤니티 자료

• M1 Max MLX Qwen 3.6·Gemma 4: https://arca.live/b/alpaca/174667148
• Qwen 3.6 27B·35B 정성 비교: https://arca.live/b/alpaca/177444310
• Qwen 3.6 27B MTP depth 3 운영 경험: https://arca.live/b/alpaca/174809772
• DGX Spark vLLM·MTP 장문 안정성 사례: https://arca.live/b/alpaca/173319517
• OpenWebUI 표시 설정 오진 사례: https://arca.live/b/alpaca/177088825
• Qwen 3.6 35B 실행 난이도 게시글: https://arca.live/b/alpaca/176291512
• Hermes 사용 경험 토론: https://arca.live/b/alpaca/177802533
• AMD 환경의 생성·prefill 비교 게시글: https://arca.live/b/alpaca/177394805

공개 런타임 이슈

• llama.cpp #23011, Apple Metal self-MTP slowdown: https://github.com/ggml-org/llama.cpp/issues/23011
• llama.cpp #23230, MTP cleanup performance report: https://github.com/ggml-org/llama.cpp/issues/23230
• llama.cpp #23233, Qwen 3.6 MTP image crash: https://github.com/ggml-org/llama.cpp/issues/23233
• llama.cpp #23577, Qwen 3.6 27B long-session repetition: https://github.com/ggml-org/llama.cpp/issues/23577
• llama.cpp discussion #21112, Qwen 3.6 MTP configuration: https://github.com/ggml-org/llama.cpp/discussions/21112