r/LocalLLaMA가 주목한 mlx-lm의 Qwen3.5 native MTP와 1.5x 추론 개선 가능성

r/LocalLLaMA에서 무엇이 화제가 됐나

r/LocalLLaMA의 Reddit post는 capture 시점 기준 99 points, 17 comments를 기록하며 mlx-lm의 open PR #990, feat: native MTP speculative decoding for Qwen3.5를 빠르게 퍼뜨렸다. 이 thread가 실무자에게 중요했던 이유는 단순한 코드 변경 소개가 아니라, local inference 운영자가 바로 해석할 수 있는 성능 숫자를 함께 제시했기 때문이다. 게시글이 강조한 수치는 Qwen3.5-27B 4-bit를 M4 Pro에서 실행했을 때 15.3 -> 23.3 tok/s (~1.5x throughput boost), ~80.6% acceptance rate였다. Apple Silicon에서 단일 사용자 세션의 응답성을 개선하려는 개발자에게는, 새 model이 아니라 runtime 경로 최적화만으로도 체감 지연 시간을 줄일 수 있다는 신호로 읽힌다.

Upstream PR이 실제로 추가하는 것

PR summary에 따르면 Qwen3.5 checkpoint에는 이미 built-in Multi-Token Prediction head가 들어 있고, 핵심 설정은 mtp_num_hidden_layers: 1이다. 이 head는 backbone hidden state at t와 embedding of token t+1을 사용해 token t+2를 예측한다. 즉, 별도의 draft model을 붙이는 일반적인 speculative decoding과 달리, mlx-lm은 model 내부에 있는 native MTP head를 활용해 speculative path를 만든다. 계산 비용도 보조 model 하나를 더 두는 방식이 아니라 one extra transformer layer of compute에 가깝다는 점이 차별점이다.

• qwen3_5.py에 model-side support가 추가된다.
• generate.py에는 --mtp flag가 들어간다.
• server.py도 같은 --mtp 흐름을 지원한다.
• cache rollback support와 8 unit tests가 포함된다.

실무적으로 특히 중요한 부분은 verification loop다. generation loop는 draft를 먼저 제안한 뒤 이를 검증하고, rejection이 발생하면 SSM state를 rollback하고 KV cache를 trim한다. speculative decoding은 숫자만 보면 단순한 속도 기능처럼 보이지만, reject 경로에서 state 정합성이 깨지지 않아야 실제 서비스에서 안전하게 켤 수 있다. 이 PR은 바로 그 correctness 비용을 코드 수준에서 다루고 있다는 점이 핵심이다.

실무자가 봐야 할 latency tradeoff

장점은 분명하다. separate draft model 없이 native MTP를 쓰므로 배포 구성이 단순하고, CLI와 server 양쪽에서 같은 기능을 켤 수 있으며, benchmark도 single-stream 환경에서는 설득력이 있다. 하지만 제한도 명확하다. PR은 아직 open 상태이고, MTP weights가 보존된 converted checkpoint가 필요하며, MTP가 활성화되면 batching이 비활성화되고, PR summary 기준으로 MoE variants는 아직 테스트되지 않았다. 따라서 이 기능은 interactive local inference, 개인 workstation, low-concurrency API에는 매력적일 수 있지만, 여러 요청을 묶어 처리하는 shared server에는 그대로 적용하기 어렵다.

• mlx_lm.generate --model <path> --mtp와 mlx_lm.server --model <path> --mtp는 간단하지만, 운영 판단은 acceptance rate까지 함께 봐야 한다.
• tok/s만 볼 것이 아니라 acceptance rate, concurrency, batch serving 상실 비용을 같이 측정해야 한다.
• dense Qwen3.5 계열부터 검증하는 편이 보수적이다.
• checkpoint conversion 과정에서 mtp.* weights가 보존되지 않으면 기능 자체를 사용할 수 없다.

왜 Reddit thread가 의미 있었나

이 thread는 GitHub 링크를 옮겨 적은 수준을 넘었다. 커뮤니티가 초기 benchmark를 즉시 해석했고, ~80.6% acceptance rate가 default로 둘 만한 수준인지 논의했으며, top comment는 유사한 llama.cpp PR #20700을 가리켰다. 이는 MTP가 mlx-lm 한 곳의 실험이 아니라, local inference runtime 전반에서 공통 관심사가 되고 있음을 보여준다. 실무자 입장에서는 특정 구현의 우열보다도, 여러 runtime이 비슷한 방향으로 움직이는지 여부가 투자 판단에 더 중요할 때가 많다.

결국 이 소식의 가치는 benchmark 숫자와 운영 제약을 함께 보여줬다는 데 있다. 단일 세션 latency에는 도움이 될 수 있지만, batching을 잃는 순간 전체 서버 효율은 오히려 나빠질 수 있다. 원문 구현 세부사항은 https://github.com/ml-explore/mlx-lm/pull/990에서, 커뮤니티 반응은 https://www.reddit.com/r/LocalLLaMA/comments/1rzntv5/multitoken_prediction_mtp_for_qwen35_is_coming_to/에서 확인할 수 있다.