Apple Silicon 512 GiB 환경의 로컬 LLM 런타임 비교

Qwen 3.6 튜닝 모델과 보조 모델의 장기 컨텍스트·동시성 검증 보고서

문서 유형: 운영 증거를 포함한 재현 가능한 엔지니어링 기술 보고서 검증 기간: 2026-07-15 ~ 2026-07-21 JST 작성 기준일: 2026-07-22 JST 대상 호스트: Mac Studio M3 Ultra, 512 GiB unified memory, Apple Silicon

이 문서는 학술적 peer review 논문이 아니라, 동일 호스트에서 여러 모델 파일과 런타임을 실제로 기동하고 직접 API, 게이트웨이, 개인용 프록시 경로를 확인한 운영용 연구 기록이다. 공개 모델 카드와 런타임 문서는 재현을 위한 외부 근거이고, 성능 수치는 이 호스트에서 수집한 로컬 측정값이다.

초록

이 보고서는 Apple Silicon의 대용량 unified memory를 활용해 Qwen 3.⁶ 35B A3B와 27B 비공식 튜닝 모델을 운영할 때 llama.cpp, MLX-LM/oMLX, vLLM-Metal, Ollama, LM Studio, MTPLX를 비교한다. 비교 대상에는 에이전트·tool-call 특화 Qwopus, SuperGemma, Gemma 4 상태, Qwen3 임베딩·reranker도 포함했다. 모든 신규 장문 및 동시성 실험에서는 요청 단위 max_tokens와 동등한 출력 제한을 제거하여, 모델의 컨텍스트 처리와 런타임의 실제 종료 동작을 관찰했다.

최종 운영 결론은 다음과 같다.

현재 운영 경로는 llama.cpp가 가장 재현성이 높다. 35B Genesis-Hermes는 131K 컨텍스트 슬롯 8개를 수용하는 p8 구성을 유지하고, 27B Heretic은 p1로 유지한다.
MLX-LM/oMLX는 Apple Silicon에서 짧은 응답, 반복 prefix, 일부 prefill에서 매우 유망했다. 그러나 모델 identity 정규화, 장문 prefill, SSE lifecycle, 메모리 압박 시 장애 전파를 별도로 해결하기 전에는 운영 기본값으로 승격하지 않았다.
Qwopus 35B oQ6는 agent/tool 후보로, Qwopus coder 6-bit는 coding/vision 및 tool 보조 후보로 가장 의미가 있었다. 둘 다 일반 uncensored 모델의 대체재로 간주하지 않는다.
vLLM-Metal은 35B 단문 smoke는 통과했지만 32K SSE 응답과 27B 모델 초기화에서 운영상 차단되는 문제가 있었다. Ollama는 35B에서 p2가 유망했지만 27B의 parallel 증가는 선형 확장을 만들지 못했다.
131K 신규 prefill과 exact-repeat cache hit는 전혀 다른 측정이다. repeat가 1~3초라고 해서 신규 100K 요청이 빠르다는 뜻은 아니다.

연구 질문

512 GiB unified memory를 가진 Mac Studio에서 27B와 35B 모델의 실제 병목은 모델 크기, KV cache, prefill, decode, runtime scheduler 중 무엇인가?
parallel을 높이면 처리량이 늘어나는가, 아니면 각 요청의 TTFT와 메모리만 악화되는가?
짧은 chat smoke가 통과한 런타임을 대형 컨텍스트와 Claude Code/Hermes형 tool-call에도 사용할 수 있는가?
반복 prefix cache의 이점과 신규 요청의 비용을 분리해 운영 기본값을 결정할 수 있는가?

범위와 개인정보 경계

포함한 것은 Mac에서 실제로 다운로드·기동·health check·API 생성·tool-call 또는 운영 경로 검증 중 하나 이상을 거친 모델과 런타임이다. 단순 model alias, 원본 모델의 호환 입력, 접근이 막힌 모델 카드는 별도 상태로 분리했다.

이 공개용 문서에는 호스트 IP, SSH 정보, 개인 경로, API key, env-vault 값, 고객·구독·tenant ID, DB row ID, raw request body를 넣지 않았다. 운영 프록시는 개인용 프록시 경로를 사용했지만, URL과 인증정보는 재현에 필요하지 않으므로 식별 가능한 값으로 공개하지 않는다. 다른 고객 운영 데이터는 Mac 검증 증거로 사용하지 않았다.

방법

실험 계층

각 후보를 다음 순서로 판단했다.

로컬 프로세스: /health, 모델 identity, runtime metadata, slot/metrics를 확인했다.
직접 API: OpenAI-compatible chat, streaming, no-limit marker, JSON 또는 native tool-call을 확인했다.
게이트웨이: 모델 이름과 응답의 model field가 canonical identity로 보존되는지 확인했다.
개인용 프록시: HTTP status, terminal SSE, tool-call, queue/in-flight, 장기 요청 timeout을 확인했다.
운영 판정: 메모리 guard, stale request, partial response, model identity mismatch가 없을 때만 승격 후보로 취급했다.

측정 계약

신규 functional, tool-call, long-context, concurrency 테스트는 request-level max_tokens, max_completion_tokens를 생략했다. MLX-LM server의 기본 512 제한이 과거 측정에 섞였던 문제를 제거하기 위해 no-limit 계약을 별도로 적용했다.
8K, 32K, 65K, 100K, 131K 부근의 고정 prompt와 exact-repeat prompt를 분리했다.
concurrency 1/2/4/8과 runtime 내부 parallel p1/p2/p4/p8을 같은 의미로 취급하지 않았다. client concurrency는 요청 수이고, runtime parallel은 실행 슬롯이다.
기록 항목은 TTFT, first content, wall latency, prompt/decode throughput, completion token 수, RSS/unified-memory 상태, HTTP/SSE 종료, queue와 tool-call validity다.
sampling 기본 비교는 temperature 0.6, top-p 0.95, top-k 20을 사용한 기록과 모델 카드/런타임 기본값을 별도 보존했다. sampling을 바꿔서 runtime 병목을 감추지 않았다.

성공 조건

HTTP 200만으로 성공으로 세지 않았다. 다음을 모두 확인해야 clean pass로 분류했다.

정상 body 또는 [DONE] terminal SSE;
finish_reason 및 usage가 존재하거나, stream contract가 명확함;
marker/JSON/tool-call이 기대한 형태임;
모델 identity가 alias가 아닌 실제 canonical route와 일치함;
memory guard, process crash, stale slot, 반복 5xx가 없음.

검증 대상 전체 목록

A. 현재 유지하는 운영 모델

모델	양자화/형식	런타임 및 운영 설정	관찰 결과	판정
Qwen 3.6 35B A3B Genesis-Hermes V2	Q6 계열 GGUF	Homebrew `llama.cpp`; canonical 35B route, p8, 총 context 1,048,576, slot당 131,072, F16 KV, prompt cache 64 GiB	고정 131K 슬롯의 32K x 8에서 평균 TTFT 97.4초, 8/8 완료. 기존 p2의 104.0초보다 나빴다는 증거가 없었다. 직접 decode는 대략 35~43 tok/s 범위로 관찰됐다.	운영 primary
Qwen 3.6 27B Heretic V2	Q4_K_M GGUF	Homebrew `llama.cpp`; p1, context 131,072, F16 KV, prompt cache 32 GiB	직접 decode 약 15.13 tok/s, 짧은 요청 약 13.67~14.63 tok/s. 32K x 4 p1은 평균 TTFT 215.1초와 3/4 완료였고, p2는 323.3초로 느려졌다.	운영 specialist/fallback
Qwen3 Embedding 4B	GGUF	별도 `llama-server`, dedicated pooling route, 실행 슬롯 p4, 외부 admission 2	32개 embedding 요청에서 5.65 req/s, 오류 없음. LM Studio 단일 서버 대비 dedicated route가 안정적이었다.	운영 pooling
Qwen3 Reranker 4B	GGUF	별도 `llama-server`, ranking pooling, 실행 슬롯 p4, 외부 admission 8	32개 rerank 요청에서 8.84 req/s, 오류 없음. `/v1/rerank`와 chat 경로를 gateway에서 분리했다.	운영 pooling

35B p8은 단순히 parallel=8을 올린 결과가 아니다. 각 슬롯에 131K를 보장하도록 총 context를 1,048,576으로 늘린 fixed-slot 실험을 통과한 결과이며, 27B p1과 같은 메모리 기준을 적용할 수 없다. 27B의 p2/p4/p8을 35B의 p8 결론에 전이하지 않는 이유도 여기에 있다.

B. MLX-LM과 oMLX 후보

모델	런타임/형식	대표 측정	tool/장문/동시성	판정
Qwen 3.6 35B A3B uncensored Heretic	oMLX 0.3.9 및 `mlx_lm.server`, MLX 4-bit	5/5 no-limit profile pass; tool-call pass; 100K cache 후 RSS 약 33.7 GiB	8K/32K/64K/100K와 concurrency 1/2/4/8을 통과한 가장 강한 uncensored MLX 후보	유망 후보, 운영 미승격
Qwen 3.6 27B uncensored Heretic v2	oMLX 0.3.9, MLX 4-bit	5/5 profile pass; lower-memory fallback	long prefill은 35B 후보보다 느렸다. correctness는 통과했지만 운영 primary를 바꿀 만큼의 장점은 없었다.	유망하지만 느린 후보
Qwen 3.6 35B A3B uncensored Heretic text-only	MLX-LM, mixed 6/6/8-bit, vision encoder 제거	8K fresh 9.240초, 32K 19.695초, 65K 77.589초, 100K 160.135초, 131K 235.043초	exact-repeat는 약 0.4~1.2초였지만 신규 prefill과 다르다. 4-way는 54.343초가 가장 나았고 8-way는 228.633초로 interactive에는 부적합했다.	검증 후보, identity/운영 문제로 보류
Qwen 3.6 27B Abliterated Heretic	MLX-LM 0.31.3, MLX 6-bit	8,194 prompt 19.3초/약 424 tok/s; 32,770 prompt 162.9초/201 tok/s; 65,538 prompt 494.2초/133 tok/s	100K 신규 prefill은 69,632 부근에서 중단되어 후보를 회수했다. cache hit는 빠르지만 신규 long-context가 선형적으로 유지되지 않았다.	폐기/포트 회수
Qwopus 3.6 35B A3B Coder oQ6	oMLX, MLX oQ6	5/5 profile pass; native `lookup_weather` tool-call pass, completion 27 tokens; post-100K cache RSS 약 33.7 GiB	agent/tool에 특화된 가장 빠른 후보로 기록됐지만, 일반 uncensored 대체 모델은 아니다.	agent 후보, 미승격
Qwopus 3.6 35B A3B Coder 6-bit	oMLX, MLX 6-bit	5/5 profile pass; 단문 generation 약 57~62 tok/s 범위	coding/tool 보조 후보. oQ6와 달리 별도 vision/tool 보조 목적을 유지한다.	secondary 후보
Qwen 3.6 27B v2 Qwopus 6-bit	MLX/oMLX 예정	정확한 artifact가 인증 HF 요청에서 404로 확인되지 않음	sibling artifact로 대체하지 않았다.	검증 차단

oMLX 표의 5/5는 짧은 marker, card profile, coding/thinking profile을 의미한다. 그 숫자를 100K 신규 prompt의 전체 완료율이나 프록시 장시간 안정성으로 해석하면 안 된다. MLX 후보는 BatchedEngine, model_type_override=llm, context 131,072, model-memory budget 64 GiB, process-memory guard 70%, hot cache 32 GiB를 기준으로 재현해야 한다. runtime concurrency 8은 capacity 측정용이고, interactive proxy admission은 4가 더 안정적이었다.

설치·alias·접근 상태만 확인된 항목

다음 항목은 Mac 환경에서 이름, 설치 상태 또는 호환 alias가 확인되었지만, 이 campaign의 clean no-limit 장문·동시성 증거가 없거나 실제 모델 파일을 얻지 못했다. 따라서 위의 “검증 대상 전체 목록”에서 pass 모델로 세지 않았다.

항목	상태	이 보고서에서의 처리
Qwen 3.6 original/base ID	canonical modified route의 compatibility input	별도 모델 성능으로 중복 집계하지 않음
Qwen 3.5 27B/35B legacy	과거 inventory 또는 alias에 남은 legacy	Qwen 3.6 campaign의 결과로 전이하지 않음; 새 검증 TODO
Official Gemma 4 31B IT	vLLM target/launcher 정의는 있으나 isolated/proxy pass 미완료	미검증으로 유지
Qwen3 Embedding/Reranker 외 Nomic Embed, 과거 creative 모델	설치/기록 항목	이번 paper의 generation 비교에서 제외
Kimi K2.5, GPT-OSS 20B/120B, C4AI Command R+	삭제 또는 최종 운영 대상 아님	현재 Mac 운영 결론에 포함하지 않음
Qwopus 27B v2 6-bit	정확한 artifact 접근 404	sibling checkpoint로 대체하지 않고 blocked로 기록

C. Ollama, LM Studio, vLLM-Metal

모델/형식	런타임 설정	측정	판정
Qwen 3.6 27B Heretic Q4_K_M	Ollama, `OLLAMA_NUM_PARALLEL=1/2/4`	client 1/2/4에서 대표 wall time 17.97/32.96/55.08초; parallel 증가가 선형 throughput을 만들지 못함	27B 운영 런타임으로 부적합
Qwen 3.6 35B Genesis-Hermes Q6_K	Ollama	parallel 2가 warm two-way 약 1.90초로 p1보다 좋았고, p4는 batch spread 약 2.09초	sandbox 후보, production 미승격
Qwen 3.6 27B Q8 HauhauCS 계열	LM Studio bundled llama.cpp	cold 128-token probe 70.47초; 동일 warm retry가 90초 안에 first token을 내지 못함	interactive agent 경로 거부
Qwen 3.6 35B A3B fast 4-bit	vLLM-Metal/MLX community candidate	짧은 normal prose는 약 44~49 tok/s, gateway smoke는 통과	32K와 장기 lifecycle이 운영 기준에 못 미쳐 역사적 후보
Qwen 3.6 35B A3B HauhauCS aggressive safetensors	vLLM-Metal	`enable_thinking=false`에서도 약 2.8 tok/s; no-thinking이 아닌 짧은 prose는 180초 초과	너무 느려 폐기
Qwen 3.6 35B A3B MLX 5-bit	vLLM-Metal	8K short probe는 통과했지만 32K SSE가 160초 동안 body를 내지 않음	장문 서비스 거부
Qwen 3.6 27B MLX 6-bit	vLLM-Metal	language-model-only 초기화가 vision weight shape mismatch로 실패	런타임/format 부적합

D. MTPLX와 SuperGemma/Gemma 4

모델	런타임	실제 검증	판정
Qwen 3.6 35B MTPLX Optimized Speed	MTPLX 2.x, MLX/MTP	resident D1에서 TTFT 1.103초, completion 1,222, decode 8.76 tok/s, wall 140.64초; native tool-call은 7.132초/56 tokens	llama.cpp를 중지한 단독 조건에서 300초 이상 incomplete가 되었고, 동시 운영 중 lifecycle/queue 문제가 있어 미승격
Qwen 3.6 27B MTPLX Optimized Speed	MTPLX 2.2, serial scheduler, MTP depth 3	marker 3.1초; 8,278 prompt 샘플 평균 proxy latency 64.5초, first decode 약 22.2 tok/s	137,471 prompt가 600초 내 응답하지 않았고 active 7/waiting 6까지 누적. rollback 및 삭제
SuperGemma 4 26B uncensored	MLX import 및 vLLM-Metal	short sample 약 82 tok/s, TTFT 0.21~~0.28초; 6.7K~~7.8K Claude-shaped prompt는 TTFT 6.3~~6.5초와 34~~38 tok/s	short interactive는 의미가 있지만 12K long probe가 300초 client wait을 넘었다. legacy/별도 follow-up
Official Gemma 4 31B IT	vLLM 별도 설치 예정	LM Studio asset은 불안정하여 삭제. vLLM target과 launcher는 정의됐지만 isolated load, structured output, proxy smoke의 완료 증거가 없음	Mac 검증 완료 모델로 세지 않음; 재검증 TODO

핵심 성능 결과

35B와 27B의 runtime 비교

아래 숫자는 서로 다른 workload를 섞지 않기 위해 측정 단위를 그대로 표시했다. fresh는 신규 prefix prefill이고, repeat는 동일 prompt cache 재사용이다.

계열	런타임	workload	결과	해석
35B Genesis-Hermes	llama.cpp p8	32K x 8, fixed 131K slot	평균 TTFT 97.4초, 8/8	현재 capacity 결론
35B Genesis-Hermes	llama.cpp	fresh 32K prefill	약 1,883.86 tok/s 기록	직접 server prefill 지표; proxy wall time과 동일하지 않음
35B text-only Heretic	MLX-LM	fresh 131K	235.043초	대형 입력을 실제로 끝냈지만 interactive latency는 큼
35B text-only Heretic	MLX-LM	exact repeat 131K	약 1.176초	cache hit; 신규 prompt 성능이 아님
27B Heretic	llama.cpp p1	fresh decode	약 15.13 tok/s	안정성 우선의 specialist baseline
27B Heretic	MLX-LM 6-bit	fresh 8K/32K/65K	424/201/133 prompt tok/s	context가 커질수록 prefill이 크게 악화
Qwopus 35B oQ6	oMLX	no-limit tool profile	tool-call pass, 5/5 profile	agent correctness 후보
HauhauCS 35B	vLLM-Metal	short prose	약 2.8 decode tok/s	사용 목적 대비 비용이 큼

Parallel 결과

35B llama.cpp 소규모 TTFT sweep에서는 p2가 p1보다 평균 TTFT가 낮았지만, fixed-slot capacity run에서는 총 context를 보장한 p8이 32K x 8을 모두 완료했다. 따라서 p8은 35B의 고정 슬롯 capacity 설정으로만 유효하며, p2의 모든 조건을 무조건 대체한다는 의미는 아니다.
27B llama.cpp는 p1이 long-context 기준점이다. p2는 더 많은 요청을 완료한 경우가 있어도 TTFT가 평균 323.3초로 악화했고, p4는 timeout이 남았다.
Ollama 27B의 OLLAMA_NUM_PARALLEL 2와 4는 요청을 받아들이는 수만 늘렸고, unified-memory bandwidth와 prefill contention을 해결하지 못했다.
oMLX의 runtime concurrency 8은 capacity용이며, interactive proxy admission 4 안에서 더 나은 latency가 관찰됐다. OLLAMA_NUM_PARALLEL 값을 oMLX나 llama.cpp에 이식하면 안 된다.

Cache와 메모리

512 GiB unified memory는 모델 weight를 적재하는 데 충분한 여유를 제공하지만, 동시 장문 KV cache를 공짜로 만들지는 않는다. 메모리 비용은 model weights, 각 slot의 KV, prompt cache retention, scheduler batch, macOS/Metal overhead가 동시에 증가한다.

관찰된 경계는 다음과 같다.

35B p8은 총 context 1,048,576과 64 GiB prompt cache retention으로 운영 관찰을 통과했다.
27B p1은 131,072 context와 32 GiB cache가 현재 균형점이다.
MLX 27B 6-bit는 8K/32K/65K에서 retained cache가 2.07/8.98/22.32 GiB로 증가했고, 100K 신규 prefill에서 부분 중단됐다.
vLLM-Metal의 초기 테스트는 KV budget을 명시하지 않아 free memory가 급격히 줄었고, 이후 후보 테스트에서는 memory fraction을 제한했다. 메모리 guard가 필요한 이유는 모델 크기 자체보다 여러 runtime과 cache가 공존할 때 드러난다.

따라서 “512 GiB이므로 parallel을 최대로”는 올바른 규칙이 아니다. slot별 context, prefill batch, cache retention, 운영 admission을 함께 고정하고, 같은 workload에서 TTFT·완료율·메모리를 비교해야 한다.

실패와 원인 분류

실패 현상	실제 원인/해석	재발 방지
MLX 27B 100K가 부분 종료	신규 long prefill이 runtime cache와 memory guard 경계를 넘음	131K를 capacity ceiling으로 기록하고 100K fresh를 별도 gate로 유지
vLLM-Metal 32K에서 HTTP 200 후 SSE body 없음	HTTP header 성공과 engine body completion은 다름; engine/lifecycle 문제	terminal SSE까지 기다리고, body 없는 200을 pass로 세지 않음
vLLM-Metal 27B init shape mismatch	vision weight layout과 language-only 경로의 format mismatch	정확한 model conversion과 supported-model matrix를 먼저 확인
MTPLX 동시 운영 중 300초 이상 incomplete	runtime serial queue와 다른 모델의 resource pressure/lifecycle 영향	단독·공존·proxy 경로를 따로 검증하고 fail-open fallback을 만들지 않음
LM Studio 동일 요청 warm retry timeout	import/model template/runtime의 cold/warm lifecycle 불안정	GUI smoke만으로 production route를 승인하지 않음
HauhauCS 35B 약 2.8 tok/s	모델 weight/런타임 조합과 Metal memory policy가 성능에 불리	short speed만으로 대형 모델을 승격하지 않음
proxy DB tok/s가 비정상적으로 큼	일부 request row가 first-output와 finish timestamp가 너무 가까운 계산 artifact를 가짐	llama.cpp cumulative metric과 request-level metric을 분리; speed outlier를 필터링
27B parallel 증가 후 대기/timeout	prefill bandwidth와 KV contention이 slot 증가 이익을 상쇄	27B p1, proxy admission 1~2, excess queue 정책 유지

프록시의 request-level output_tokens_per_second는 first output부터 finish까지의 시간을 분모로 사용한다. 이 값은 server cumulative decode metric과 같은 지표가 아니며, stream timestamp artifact가 있는 row는 성능 평균에 넣지 않았다.

최종 운영 권장안

현재 유지

35B primary: qwen3.6-35b-a3b-genesis-hermes-v2
  runtime: llama.cpp
  context: 1,048,576 total / 131,072 per slot
  parallel: 8
  KV: F16
  prompt cache: 65,536 MiB, checkpoints 128

27B specialist: qwen3.6-27b-heretic-v2
  runtime: llama.cpp
  context: 131,072
  parallel: 1
  KV: F16
  prompt cache: 32,768 MiB, checkpoints 64

35B를 기본 agent route로 사용하고, 27B는 명시적으로 선택되는 slower specialist로 둔다. 27B가 오래 걸린다고 35B로 자동 교차 fallback하면 두 모델이 동시에 압박을 받아 queue가 더 악화될 수 있으므로, fallback은 proxy의 공통 admission/timeout/ retry 계약에서 별도로 판단해야 한다.

재검증 없이는 바꾸지 않을 항목

parallel과 OLLAMA_NUM_PARALLEL을 다른 runtime에 이식하지 않는다.
max_tokens를 추가해 장문 성능을 좋게 보이게 하지 않는다.
repeat cache 결과를 fresh prefill 결과로 보고하지 않는다.
모델 alias를 실제 model identity 검증 없이 production route로 연결하지 않는다.
vLLM-Metal의 max-model-len만 늘리고 KV/memory fraction을 지정하지 않는다.
MLX 후보를 승격할 때 direct API뿐 아니라 stream completion, model identity, tool-call, memory guard, proxy queue, 131K fresh probe를 다시 통과시킨다.

재현 절차

모델 card와 변환 형식의 실제 파일을 고정하고, sibling artifact를 대체하지 않는다.
기존 운영 프로세스를 중지하지 않은 상태에서 별도 port와 별도 memory budget으로 short marker를 먼저 실행한다.
no-limit plain chat, JSON/schema, native tool-call, 8K/32K/65K/100K/131K, exact-repeat를 순서대로 측정한다.
p1/p2/p4/p8은 prompt length와 total-context를 명시해 별도로 비교한다.
client concurrency와 runtime parallel을 각각 기록하고, wall latency, TTFT, decode tok/s, prompt tok/s, RSS, queue를 함께 저장한다.
direct API를 통과한 뒤 gateway와 개인용 proxy에서 terminal SSE, alias identity, tool-call, retry/timeout을 확인한다.
최소 2시간 canary, 24시간 completed-request gate, 7일 soak가 모두 필요한 경우에만 운영 승격으로 표시한다.

공개 커뮤니티 근거와 해석

2026-07-26에 아카라이브 AI 언어모델 공개 게시물을 추가 조사했다. 아래 수치는 작성자의 공개 실험 조건을 그대로 요약한 것이며, 이 보고서의 M3 Ultra 512 GiB 로컬 실측과 합산하거나 동일 하드웨어 결과로 취급하지 않는다.

M1 Max 64GB의 Qwen 3.6 35B A3B oQ6 dflash 실험은 dflash 사용 시 1K~~16K decode가 약 172~~199 tok/s, 131K가 약 74 tok/s였고, 비사용 시 각각 약 45~53 tok/s와 23 tok/s였다고 보고한다. 단일 작성자의 합성 벤치마크이므로 장문 정답률·tool-call·동시성 안정성을 별도로 검증해야 한다.
27B MTP3 운영 선택 기록은 열·전력 제약을 고려해 27B MTP3로 정착한 사례다. 댓글의 dflash 100K acceptance 약 20%, tool/repetition 문제, FP8 MTP5 decode 약 15 tok/s 주장은 재현 조건이 불완전한 관찰값이므로 후보 가설로만 유지한다.
27B/35B 체감 비교와 27B 파인튜닝 체감 기록은 응답 지연, tool 사용, 모델 성향에 대한 사용자 관찰을 제공하지만 정규화된 benchmark가 아니다.

이 자료가 보강하는 결론은 “짧은 decode tok/s가 높다”와 “장문 agent 경로가 안정적이다”를 분리해야 한다는 점이다. dflash/MTP 후보는 cold 100K~131K prefill, acceptance rate, terminal SSE, 반복 오류, tool-call 정확도까지 같은 표에 기록한 canary에서만 운영 승격을 판단한다.

한계와 미완료 연구

이 수치는 특정 M3 Ultra 512 GiB, 특정 macOS/Metal/llama.cpp/MLX 버전에 대한 결과이며 다른 Apple Silicon에 일반화할 수 없다.
품질 평가는 marker와 coding/tool-call spot check 중심이다. 장기적인 factual benchmark나 독립적인 human preference 평가는 포함하지 않았다.
200K를 tokenizer/launcher ceiling으로 정의한 기록은 있으나, 모든 runtime에서 200K 신규 요청을 operationally 완료한 것은 아니다. 131K는 검증된 운영 목표이고 200K는 capacity ceiling으로만 취급한다.
oMLX 후보의 full matrix는 correctness와 cache를 보여주지만, 현재 운영 p8 llama.cpp와 동일한 proxy traffic 분포로 장기 비교한 자료는 부족하다.
공식 Gemma 4 31B IT는 Mac에서 완전한 isolated/proxy 검증이 아직 없다.
Deep Research Archives의 공개 검색·fetch·게스트 제출은 2026-07-26에 실제로 검증했다. 공개 아카이브는 이 보고서의 배포·계보·후속 비판 경로이며, 성능 수치의 독립적인 재현 증거를 대신하지 않는다.

후속 TODO

oMLX Heretic 35B와 Qwopus oQ6를 같은 131K fresh/concurrency/proxy 계약으로 재검증하고, canonical model identity normalization을 먼저 구현한다.
35B p8의 32K x 8뿐 아니라 65K x 8에서 timeout tail과 memory guard를 확인한다.
request-level tok/s 계산에서 first-output/finish timestamp artifact를 제거하고, server cumulative metric, TTFT, decode duration을 별도 필드로 기록한다.
official Gemma 4 31B IT의 실제 model load, strict JSON, tool parser, 131K, proxy SSE smoke를 isolated 상태에서 완료한다.
모든 신규 후보에 대해 semantic/tool-call regression과 7일 soak를 추가한다.

증거와 참고문헌

로컬 재현 기록

공개 runtime 문서

공개 model card

운영 기록의 해석 규칙

이 paper의 최종 판정은 오래된 skill의 p2 baseline보다 2026-07-20 high-cache soak와 2026-07-21 MTPLX cleanup 이후 기록을 우선한다. 문서 간 설정이 다르면 그 차이를 숨기지 않고 historical baseline과 final active route를 구분한다.