llama.cpp에 Qwen4Exp MTP 지원 추가

AI 요약

llama.cpp에 Qwen4Exp 모델의 MTP(Multi-Token Prediction) 경로를 추가하는 PR #29761이 병합됐습니다. MTP는 초안 모델이 다음 토큰 후보를 제안하고 본 모델이 이를 검증하는 speculative decoding 방식입니다. 이번 변경은 모델 변환부터 draft 모델 로딩, recurrent memory 처리까지 Qwen4Exp의 MTP 실행에 필요한 부분을 다룹니다.

MTP 블록 구성과 모델 변환

MTP head는 trunk 뒤에 붙는 full-attention QSA 블록 하나로 구성됩니다. 입력은 trunk에서 나온 hc-wide residual이며, 각 hc stream에서 정규화한 e와 h_s를 이어 붙여 eh_proj에 넣습니다. 블록 안의 hyper-connection mixer가 stream을 합칩니다. Draft context에는 이 블록만 들어가며, attention cache와 indexer cache를 보관합니다. recurrent layer는 포함하지 않습니다.

Converter는 MTP 블록을 내보낼 때 fc_embedding과 fc_hidden을 eh_proj로, nextn_hc_head를 mixer로 변환합니다. MTP 전용 파일에는 PLE를 넣지 않습니다. Draft loader도 target 모델 경로가 아니라 별도로 지정한 draft 경로를 엽니다.

빈 recurrent memory의 롤백 처리

MTP draft context에는 recurrent layer가 없어 recurrent memory 모듈이 비어 있을 수 있습니다. 기존 코드는 레이어 필터가 모든 레이어를 제거해도 ctxs_bufs가 비어 있는지로만 판단했습니다. 변경안은 is_empty()를 추가해 이 상태를 명시적으로 검사합니다. 빈 모듈에서는 rollback snapshot을 비활성화하고, 롤백 요청이 들어오면 실제 메모리 상태 대신 위치만 되돌립니다. 후속 변경에는 recurrent memory에서 잘못된 assert를 고치는 수정도 포함됐습니다.

속도와 메모리 사용 보고

사용자 테스트 결과는 하드웨어와 설정에 따라 달랐습니다. 한 사용자는 짧은 컨텍스트에서 생성 속도가 약 40 t/s에서 50 t/s로 늘었다고 보고했습니다. 반면 256k 컨텍스트에서는 메모리 사용량을 줄여도 OOM이 발생했습니다. 다른 테스트에서는 MTP context 초기화 중 CUDA compute buffer 할당에 실패했습니다. 로그에는 약 22GiB와 12GiB 할당 실패가 기록됐습니다.

댓글에서는 PR 측 수치로 DGX에서 약 1.4~1.5배 향상이 언급됐지만, offload 비중이 큰 MoE 구성에서는 draft token 검증에 필요한 expert 로딩이 병목이 될 수 있다는 반론도 나왔습니다. 실제 사용자 중에는 속도 향상을 봤다는 사례와 MTP를 켠 뒤 오히려 느려졌다는 사례가 모두 있습니다. 따라서 이 결과만으로 모든 GPU·메모리 구성에서 같은 향상을 기대하기는 어렵습니다.

Reddit 반응

• @u/pmttyji — u/am17an 👍
• @u/florinandrei — 좋습니다. 특정 quant에 묶인 기능이 아니니 Unsloth quant에서도 작동할 것 같습니다. MTP를 켜면 제가 쓰는 구형 모델과 비슷한 속도가 나올 것 같습니다. n-gram 문제까지 해결되면 더 빨라지겠습니다.
  • @u/unjustifiably_angry — n-gram 문제가 해결되면 더 빨라진다는 말은 무슨 뜻인가요?
• @u/dmter — MTP를 써 봤는데 오히려 느려졌습니다. MTP head가 전체 모델보다 훨씬 작지 않고 적중률도 낮아서, dense model에서만 쓸모 있는 것 같습니다.
  • @u/gh0stwriter1234 — Qwen4Exp용 MTP PR과 다른 PR 몇 개를 함께 적용해 봤는데, 꽤 오래된 아키텍처인 MI50에서도 조금 빨라졌습니다. 추가 계산량을 늘리지 않고 prefill을 높이는 방법이 있으면 더 좋겠습니다.
  • @u/nadavvadan — 서로 같은 weight를 재사용하는 구조가 아니기 때문입니다. 그 재사용이 MTP의 장점인데, 여기서는 토큰마다 다른 expert를 불러옵니다.
  • @u/nadavvadan — 검증 단계에서는 여전히 전체 forward pass가 필요합니다. 배치 처리 성능이 낮아지거나 예측 실패 뒤 순차 실행이 늘면 MTP가 속도를 떨어뜨릴 수도 있습니다. 구현 문제인지도 더 살펴봐야 합니다.
• @u/Combinatorilliance — MoE에서는 MTP 효과가 dense model보다 작다고 생각했는데, PR 댓글 수치가 DGX에서 1.4~1.5배라면 예상보다 큽니다. GPU, 특히 offload 구성의 벤치마크가 궁금합니다.
  • @u/karmaisnonsense — CPU로 offload한 expert가 많으면 draft token 검증이 병목이 될 수 있습니다. 메모리가 충분히 빠르거나 VRAM에 expert layer를 충분히 올리면 문제가 덜하지만, MoE offload가 많을수록 MTP가 성능을 해칠 수도 있습니다.
• @u/TuskNaPrezydenta2020 — Unsloth보다 메모리 사용량이 크게 늘었습니다. cache를 공유하지 않기 때문입니다.
  • @u/am17an — 아닙니다. 다른 버그였고 지금은 수정됐습니다.

원문: GitHub Pull Request #29761 / 번역·요약: Trawling