헤드-투-헤드 리매치: MTPLX의 native-MTP 런타임이 파트 원에서 수동 조정된 mlx-vlm 레인에 대항하여 128 GB M1 Ultra에서 실행됩니다. 오토튜너가 약속했습니다 2.20x. 서빙 경로는 다른 계획을 가졌습니다 — Kimi K3에서 1 일 동안 측정되었습니다.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
리매치는 1 일 앞서 도착했습니다. 어제의 M1 Ultra tuning article는 예측으로 마무리되었습니다: MLX 릴리스가 컴파일된 디코드 그래프를 출시하면, 20.3 토크/초 레인에 대한 리매치는 오후와 1번 다운로드가 걸릴 것입니다. 오늘 아침, 나는 MTPLX라는 새로운 런타임을 발견했습니다. 그것은 완성된 제품으로서 미래를 약속합니다 — Apple 실리콘에서 네이티브 멀티-토큰-프리딕션 스펙추얼 디코딩, 당신의 특정 기계를 측정하는 오토튜너, OpenAI-와 Anthropic-호환 서버, 실제로 사용하는 에이전트 하네스에 대한 1-클릭 실행, 그리고 Qwen3.8-27B를 플래그십 코딩 모델로 제공합니다. 그들의 사이트는 "당신이 가장 좋아하는 도구, 두 배 속도로"라고 말합니다. 나는 그것을 Kimi K3에게 가져왔습니다. 그날 전날 튜닝 모험의 동료였고, 우리는 함께 조건을 정했습니다: Studio에 깨끗이 설치하고, 자신의 튜너가 최선의 사례를 만들도록 하고, 그 다음 서버가 실제로 제공하는 것을 측정합니다. Kimi는 원격 작업과 카운터를 실행했고, 나는 집 규칙을 지키며 호출을 했습니다. 이것이 실제로 하루가 진행된 방식입니다.
아키텍처는 처음부터 신용을 받을 만하다, 왜냐하면 그것은 진지하게 실행된 올바른 아이디어이기 때문이다. MTPLX는 모델 자체의 MTP 헤드를 사용해 초안을 작성한다 — 우리 레인이 사용하는 동일한 메커니즘 — 그리고 정확한 거절 샘플링을 통해 초안을 수락한다. 따라서 온도 0.6에서 샘플링하면 일반 디코딩과 동일한 분포를 생성하지만 더 빠르다. 별도의 초안 모델이 메모리를 소비하지 않으며, 초안 깊이는 기계별로 자가 회귀 기준선에 맞춰 조정되고, 프로젝트는 검증되지 않은 MTP 사이드카를 임의의 가중치에 부착하는 것을 거부한다. 그 마지막 정책은 Kimi와 내가 전날 수동으로 적용해야 했던 규율이다. 우리는 Qwen3.8의 떨어진 MTP 텐서를 그들의 트렁크와 재페어링했다. 파트 원의 레인은 명백한 측정 기준이었다: 같은 Studio, 같은 모델 패밀리, 같은 방식으로 측정했다.
첫 번째 검사는 제 것이었습니다. 3월에, 제 자율 정제 연구소에서 우리는 격리된 Python 환경이 Apple의 가속 라이브러리에 조용히 접근을 잃고 숫자만 느리게 돌아오는 함정에 빠졌습니다. Kimi가 더 진행하기 전에, 저는 그 함정이 적용되지 않았다는 증거를 요청했습니다. 3-라인 프로브가 이를 해결했습니다 — 네이티브 arm64 인터프리터, Metal 사용 가능, GPU가 기본 장치. Apple의 Metal 경로는 mlx-metal 휠 자체 안에 포함되어 있으므로 인터프리터의 출처는 GPU 접근과 무관하며, 1부의 레인은 동일한 격리 형태를 통해 GPU-네이티브 처리량을 이미 입증했습니다. MTPLX의 자체 검사관도 동의했으며, 두 개의 Qwen3.8-27B 빌드가 모두 검증된 네이티브이며 모든 15 MTP 텐서가 존재함을 평가했습니다.
두 번째 검사는 Kimi의 것이었으며, 다운로드 중간에. MTPLX의 pull 명령은 일반적인 Hugging Face 캐시 환경 변수를 무시하며, 첫 번째 시도는 Studio의 홈 디렉터리에 20GB 모델을 쓰려 했습니다 대신에 가정 규칙이 보호하는 데이터 볼륨이었습니다. Kimi는 풀을 중단하고 자신이 만든 것만 제거했으며, 명시적 캐시 디렉터리와 함께 재시작했습니다. 팬들은 하루 종일 Apple의 곡선을 유지했으며, 이는 비행 시뮬레이터로도 활동하는 기계에서 중요합니다.
다운로드 중간에, 내 워크스테이션이 급격히 급증했습니다 — 부하 평균이 50를 넘어섰고, 우리는 더 중요한 질문에 답하기 위해 실험을 중단했습니다: 이것이 우리 때문이었는가? 그렇지 않았습니다. 우리의 작업은 Studio에서 짧은 SSH 세션으로 실행되었으며, 로컬 흔적은 몇 개의 완료된 curl 및 ssh 프로세스였습니다. 폭풍은 Apple 데몬 파도였습니다 — 멈춘 자산 다운로드, 인덱싱, 그리고 가상화 프로세스가 사라지기 전에 이름을 붙일 수 없었던 폭발 — 그리고 내가 죽이던 "미스터리 재생 노드 프로세스"가 실제로는 서버를 재시작하여 정확히 일을 수행하는 3개의 개발 감독이었습니다. 우리는 전체를 기계-보호자 인계에 기록하고 깨끗한 양심으로 실험으로 돌아갔습니다. 이 일시 중지는 이 이야기에서 중요합니다. 왜냐하면 규율은 벤치마크가 실행되는 것과 동일하기 때문입니다: 기계를 비난하기 전에 자신의 흔적을 알아야 합니다.
MTPLX의 튜닝 의식은 정직한 엔지니어링입니다: 각 초안 깊이에서 실제 모델을 귀하의 하드웨어에서 실행하고, 자기 회귀 디코딩을 기준선으로 유지하며, 그 기준선을 이길 경우에만 깊이를 저장합니다. M1 Ultra에서 AR 11.4를 생성했고, 깊이 1는 9.2에서, 깊이 2는 25.1에서, 깊이 3는 20.7 토크/초에서 — 깊이 2이 2.20배에서 우승자를 차지했고, 모든 향후 실행을 위해 저장되었습니다.
그 25.1는 실제 엔진의 실제 측정값이며, 24%는 우리 레인의 20.3 서비스 속도보다 높습니다. 서버가 이를 재현했다면, 이 기사는 마이그레이션 가이드가 되었을 것입니다.
서비스 벤치는 동일한 프롬프트, 온도 0, 그리고 레인의 기준선과 동일한 월클록 회계를 사용했습니다. 첫 실행은 14.7 토크/초로 돌아왔고, 응답 메타데이터는 2 기본값이 측정값에 반대되는 것을 드러냈습니다:
추론 모드는 기본적으로 켜져 있고, Qwen3.8는 답변하기 전에 생각합니다. 10까지 세는 단순 프롬프트에서, 44의 64 생성 토큰은 클라이언트가 표시하지 않는 추론에 숨겨졌습니다. 실제 작업 부하에서는 그 토큰에 대해 비용을 지불하므로, 월별 요율은 이미 포함합니다 — 그러나 튜너의 프롬프트에는 그런 세금이 없습니다.
Turbo 런타임 프로파일은 컴파일된 검증 커널을 포함하며, 이는 네이티브 Mac 앱의 실행 규칙입니다. 터미널 mtplx serve은 Sustained 프로파일로 해결되므로, 명령줄 경로는 빠른 커널을 보지 못합니다 unless you ask.
Turbo를 고정하고, 깊이 2, 그리고 추론을 끄면 FP16 빌드를 16.5 토크/초 월에 올렸습니다 — MTPLX가 하루 종일 가장 좋았습니다. 4-비트 최적화 속도 빌드는 프로젝트가 코딩에 권장하는 빌드이며, 15.5를 제공했습니다. 두 빌드는 디스크에서 우리 레인의 15 GB와 비교해 20.4 GB에 있습니다, 그리고 대역폭이 제한된 머신에서는 매 토큰이 추가 5 GB를 스트리밍하는 비용을 지불합니다.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)Chart data
오늘 가장 유용한 발견은 25.1와 16.5 사이의 차이를 설명합니다. MTPLX의 자체 서버는 시작 시 워밍업 사다리를 기록하며, 그 사다리는 엔진에서 20-24 토크/초를 보고합니다 — 같은 프로세스 내에서 그 후 16.5를 HTTP에 제공합니다. 엔진은 빠르고 전송은 과중됩니다. 디코드 루프와 클라이언트 사이에는 HTTP 레이어, 요청당 세션-뱅크 회계(첫 요청 통계에 160 MB 스냅샷 기록이 나타남), 그리고 추론 기계가 있으며, 각 토큰은 그 경계를 통과합니다. M4와 M5 칩에서, 프로젝트가 발표한 1.6-2.24x 수치가 측정된 곳에서, 더 빠른 CPU와 패브릭이 교차를 흡수합니다. M1 Ultra의 엔진은 따라갑니다; 그 서빙 경로는 그렇지 않습니다.
Diagram source
graph LR
subgraph 튜너 경로
A[실제 모델] --> B[초안 깊이 D1-D3]
B --> C[디코드 전용 타이머
25.1 토크/초]
end
subgraph 서빙 경로
D[HTTP 요청] --> E[세션 뱅크
+ 추론 기본값]
E --> F[동일 엔진
사다리는 20-24를 보여줍니다]
F --> G[토큰 경계마다
16.5 토크/초 벽]
end
style C fill:transparent,stroke:#10B981,stroke-width:2px
style G fill:transparent,stroke:#F59E0B,stroke-width:2px
이것은 파트 하나의 교훈으로 새로운 복장을 입는 것과 같습니다. llama.cpp의 커뮤니티가 주장한 25-32 토크/초는 이 칩과 접촉했을 때 살아남지 않았으며, MTPLX의 튜너 25.1는 자체 서버에서 살아남지 않았습니다. 내구성 있는 규칙이 날카로워집니다: 제공률은 HTTP 경계에서 측정되며, 생산 기본값이 표시되고, 튜너 내부에서는 절대 측정되지 않습니다. 이는 benchmark-driven development이 스택에서 한 레이어 위에 적용된 것입니다.
나는 실험이 시작되기 전에 Kimi에게 1 비협상 가능 조건을 주었습니다: 그 스튜디오에서 실행되는 모든 것은 유휴 시에 스스로 중지되어야 합니다, 왜냐하면 기계의 저녁 작업은 비행 시뮬레이터이기 때문입니다. MTPLX는 채팅 서버에 유휴 타임아웃을 제공하지 않으므로 Kimi는 작은 래퍼 스크립트에 워치독을 구축했습니다 — 루프백 전용 바인딩, Apple의 정책에 팬을 켜고, 클라이언트가 없으면 10분 후에 서버를 중지하는 연결 감시기. 그것은 실전 훈련을 통과했고, 60‑초 표시에서 테스트 인스턴스를 해체하고 포트를 깨끗이 해제했습니다. 래퍼와 가상 환경은 기계에 남아 있으므로, MTPLX 릴리스가 M1‑세대 서비스 경로를 실행하거나 15 GB에 더 가까운 일치 MTP 아티팩트를 배송하면 재테스트는 1 다운로드만 남습니다.
가중치 자체는 남지 않았습니다. 판결이 명확해지자 우리는 정리 과정을 신중히 진행했습니다 — MTPLX 모델 디렉터리 모두, FP16와 4‑비트 빌드에서 38 GB, 프로세스가 보유하지 않았는지 확인한 후 삭제하고, 부피를 정확히 실험 전의 여유 공간으로 되돌렸습니다. 삭제는 워크플로의 일부로 남아 있습니다: 패배한 모든 도전자는 같은 날 디스크를 비우며, 이는 다음 실험을 정직하게 유지합니다.
파트 원의 레인은 움직이지 않았다. 아침에는 20.3 토크/초를 제공했고, 저녁에는 20.3 토크/초를 제공했고, 이제는 3 도전자 대신 2에 대해 슬롯을 보유하고 있다 — 여전히 실험적 레인, 1 다음 재전투까지 다운로드가 남아 있다. 파트 원의 체크리스트는 3 항목을 추가한다:
튜너의 번호는 엔진의 천장을 의미하며, 서비스 경로는 그 중 얼마나 유지할지 결정한다. 경계에서 실제로 클라이언트가 건너는 지점을 측정한다.
기본값은 벤치마크의 일부이다. 추론 모드, 런타임 프로파일, 세션 캐시는 모두 토큰이나 시간을 소비하며, 공정한 싸움은 양쪽에 명시적으로 부착한다.
디스크는 가설 예산이다. 2 도전자는 20.4 GB를 매번 구입한 1 오후에 구축하며, 확실성은 바이트가 일정에 따라 나갈 때 더 저렴해진다.
쌍의 만족스러운 대칭은 파트 원이 이 정확한 실험을 대기열에 넣어 끝냈고, 실험은 진정한 장인 정신이 담긴 제품으로 포장되어 도착했다 — 정확한 샘플링, 기계별 튜닝, 정직한 검증. 장인 정신은 실제였고 손실도 실제였으며, 두 발견은 모두 같은 측정일, CPU 폭풍과 함께 나온 결과다. 점수판이 있는 모험이 가장 좋은 종류이며, 이 경우 Kimi K3가 나 옆에서 모든 카운터를 읽었다 — 내가 로컬 AI 이득을 인프라로 취급하는 것에서 얻는 동일한 복리 수익. 레인은 슬롯을 유지하고, 디스크는 가볍고, 체크리스트는 길어졌으며, 다음 도전자는 이미 시도할 수 있다.