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초였다. 그러나 fresh 72K 입력 8건을 동시에 보낸 후속 실험은 7/8만 완료했고, 성공 요청의 서버 prompt-eval 중앙값은 95.08초였지만 사용자가 본 wall TTFT 중앙값은 416.80초, 마지막 성공은 679.27초였다. p8은 capacity 상한이지 interactive admission 목표가 아니다. 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 약 72K × 8	7/8 완료; 서버 prompt-eval 중앙값 95.08초, wall TTFT 중앙값 416.80초, 마지막 성공 679.27초	interactive admission은 2–4로 제한
같은 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 측정값에 합산하지 않는다.

2026-07-27 최신 게시글 후속 수집

이 절은 광범위한 논문 초기화가 아니라, 이미 정해진 커뮤니티 게시글과 공개 구현을 MT110 + Hermes + Insane Search 경로로 다시 확인한 결과다.

• arca.live의 178077889는 moe-ranked llama.cpp 포크의 GPU·RAM·disk 3단계 MoE expert cache가 특정 AMD/CUDA 장치에서 고정 배치보다 나았다고 보고한다. 연결된 저장소는 pinned host RAM, O_DIRECT, io_uring, CUDA를 전제로 하며 MTP와의 결합도 미검증이라고 명시한다. 따라서 이 구현을 Apple Metal에 그대로 적용할 수 있다는 근거는 아니다.
• 177625003은 AMD Strix Halo에서 Qwen 3.6 27B Q8이 26–32 tok/s였다고 주장하지만 본문에 독립 재현 절차가 부족하다. 연결된 Ternary-Bonsai 모델 카드는 AMD 전용 kernel과 Q8 reuse 조건에서 generation 15.864→32.758 tok/s, prompt 170.830→237.166 tok/s를 보고한다. 이 수치는 Apple Silicon 벤치마크와 합산하지 않는다.
• 177997838은 Windows llama.cpp 환경의 다른 MoE 모델 속도를 제시하지만 조건이 짧고 Qwen 3.6/Mac 경로가 아니다. 비교 아이디어 발굴에는 쓸 수 있어도 M3 Ultra 권장 설정의 직접 근거로 쓰지 않는다.
• 165145055는 M3 Ultra 512 GiB의 Qwen 3.5 122B MLX 실사용에서 prefill 454.064 tok/s와 decode 26.525 tok/s를 보고하고, 장문 prefill tail이 1분을 넘을 수 있다고 설명한다. 모델과 runtime이 다르므로 Qwen 3.6 35B 수치로 전이하지 않고 Apple host의 장문 tail 신호로만 쓴다.
• 165227269는 같은 계열의 Spark 대 M3 Ultra 비교에서 MTP acceptance가 낮을 때 speculative depth가 오히려 손해가 될 수 있다는 경험을 제시한다. 이는 실험 가설이며 공식 보증이 아니다.
• 177928138은 llama.cpp의 하이브리드 recurrent cache 문제가 수정됐다고 서술하지만, 공식 업스트림 PR 24785는 아직 열려 있다. 해당 PR에는 Apple Silicon p1의 긍정적 보고와 함께 parallel > 1 race·crash 보고가 존재한다. 현재 p8 서비스에는 적용하지 않고 격리된 multi-slot soak 뒤에만 후보로 다룬다.

이식성 판단

소스가 직접 뒷받침하는 것은 backend별 최적화의 존재다. 분석자 판단으로 재사용 가능한 가설은 expert working-set 계측, speculative verification reuse, cold/warm prefix 분리뿐이다. AMD kernel, CUDA pinned memory, Linux direct I/O 수치를 Apple unified memory 결과로 일반화해서는 안 된다.

다음 Apple 실험에서는 upstream Metal build를 기준으로 두고, 각 가설을 하나씩만 켠다. slot 1과 p8, 32K와 131K, cold와 warm prompt를 분리해 TTFT·prompt/decode throughput·완료율·peak memory·출력 동등성을 기록한다.

소스 주장과 분석자 판단

소스가 직접 말하는 것

• 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 전체를 대표하지 않는다.
• upstream PR 24785가 병합·수정되기 전에는 커뮤니티의 “cache bug fixed” 표현을 공식 p8 안전성 근거로 사용할 수 없다.
• 로컬 결과는 단일 장치와 현재 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
• MoE 3단계 expert cache 실험: https://arca.live/b/alpaca/178077889
• AMD Strix Halo Qwen 3.6 27B Q8 보고: https://arca.live/b/alpaca/177625003
• Windows llama.cpp MoE 속도 보고: https://arca.live/b/alpaca/177997838
• M3 Ultra Qwen 3.5 122B 실사용: https://arca.live/b/alpaca/165145055
• Spark 대 M3 Ultra Qwen 3.5 122B 비교: https://arca.live/b/alpaca/165227269
• llama.cpp recurrent cache 수정 후 Nemotron 3 Ultra 보고: https://arca.live/b/alpaca/177928138

공개 구현·모델 카드

• moe-ranked llama.cpp 포크: https://github.com/witherhoard99/llama.cpp/tree/moe-ranked
• AMD Strix Halo Ternary-Bonsai 모델 카드: https://huggingface.co/jcbtc/Ternary-Bonsai-27B-AMD-Strix-Halo

공개 런타임 이슈

• 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 #22746, Qwen 3.6 recurrent cache full reprocessing: https://github.com/ggml-org/llama.cpp/issues/22746
• llama.cpp PR #24785, recurrent state shrink/expand 제안과 p>1 race 보고: https://github.com/ggml-org/llama.cpp/pull/24785
• llama.cpp discussion #21112, Qwen 3.6 MTP configuration: https://github.com/ggml-org/llama.cpp/discussions/21112