Lightning MTP란? oMLX 0.7.1rc1에서 답변 속도 높이기

PDF에 질문하는 앱을 oMLX의 API⁴에 연결하면, oMLX가 모델을 실행해 답변을 보내요. 일반 생성은 모델이 다음 토큰 하나를 고르고, 그 토큰을 문맥에 붙인 뒤 다음 토큰을 다시 계산해요. Multi-Token Prediction(MTP)은 모델에 함께 학습된 보조 예측 헤드로 다음 토큰 후보를 미리 만들고, 본 모델이 한 번에 후보를 확인해요. 본 모델이 연속해서 맞다고 확인한 후보는 답에 반영하고, 처음 틀린 후보부터는 버린 뒤 일반 생성으로 이어가요.

후보를 만들고 확인하는 작업에도 계산이 들어요. 제안한 토큰이 자주 맞는 모델과 요청에서는 순차 계산을 줄일 수 있지만, 잘 맞지 않으면 절약 폭도 작아질 수 있어요. 그래서 후보 깊이만 높이는 대신 같은 질문의 전체 완료 시간과 답변을 함께 비교해요.

지원 조합을 고르려면 oMLX 릴리스의 모델 목록에서 버전과 아키텍처를 확인해요. 체크포인트 안내에서 파일 형식을 살피고, 변환한 파일에 MTP 헤드 텐서가 남았는지도 확인해요. 마지막으로 모델 설정에 해당 체크포인트의 MTP 항목이 표시되는지 봐요.

처음 비교할 때는 일반 생성으로 정상 답변을 주는 파일을 기준으로 남겨두고, 지원 MTP 체크포인트 하나만 추가해요. 모델이 적재되지 않으면 MTP를 조정하기 전에 파일 경로와 메모리, 체크포인트 형식을 확인해요. 같은 모델의 일반 버전과 MTP 버전이 동시에 있다면 파일 크기뿐 아니라 MTP 텐서 포함 여부도 확인해야 해요.

2026년 10월 9일 공개된 개발판의 파일 편집 측정 범위와 완료 결과를 표에 모았어요. 이 결과는 요청을 끝내는 데 걸린 시간을 다루므로, 내 작업에 적용할 때는 아래처럼 모델과 입력 조건을 맞춰 비교해요.

해당 숫자를 내 작업에 옮기려면 모델과 체크포인트, 입력, 출력 길이, temperature를 맞춰요. 준비 실행 뒤 같은 파일 변경 요청을 일반 생성과 MTP에서 번갈아 실행하고, 전체 완료 시간과 코드가 실제 요구를 충족하는지 기록해요. 파일 편집이 아닌 PDF 질의나 짧은 대화라면 그 작업을 그대로 시험해야 해요.

0.7.1rc1에는 TurboQuant 4비트 KV 캐시⁵와 Lightning MTP를 함께 쓸 때의 개선도 들어 있어요. M3 Ultra에서 Qwen3.8-27B를 실행한 결과, 16K와 32K 입력 뒤 답변이 이어지는 속도가 높아졌어요. 같은 모델을 이미 쓰고 있다면 긴 입력에서 이 조합을 비교할 이유가 생긴 거예요.

M3 Ultra · Qwen3.8-27B · TurboQuant KV 4비트 + Lightning MTP · 각 변경 직전 코드와 비교한 개발자 측정 · 반복 횟수와 전체 샘플링 조건은 릴리스 표에 미기재

16K 결과는 1초에 생성하는 토큰이 약 29개 늘어난 경우예요. 실제 사용에서는 같은 문서를 넣고 답변 길이를 고정해, 첫 토큰까지의 시간과 답변 완료 시간을 각각 재보세요. TurboQuant는 KV 캐시의 표현을, Lightning MTP는 생성 후보 준비를 바꾸므로 비교 기록에 두 설정을 함께 적어두면 돼요.

도입에서 든 PDF 질문으로 MTP를 시험한다면 같은 파일과 페이지, 질문을 사용해요. 파일 편집을 다룬 앞 절의 릴리스 결과와는 작업이 다르니, 내게 자주 필요한 과제를 골라 따로 재면 돼요. 문서가 로딩된 뒤 첫 토큰까지는 프리필⁶과 요청 대기가 포함되고, 이어지는 토큰 속도는 생성 구간을 보여줘요. 마지막 문장까지의 전체 시간도 기록해요. MTP는 생성 경로를 바꾸므로 입력을 읽거나 모델을 처음 메모리에 올리는 시간은 별도로 봐요.

일반 생성과 MTP를 각각 준비 실행한 뒤 세 번씩 번갈아 시험하고, 중앙값을 비교하면 순간적인 백그라운드 작업의 영향을 줄일 수 있어요. 입력 토큰 수, 답변 길이, temperature, KV 캐시 설정, 동시 요청 수를 같게 두고 답변이 질문의 근거를 유지하는지도 확인해요. 여러 요청을 처리하는 서버라면 요청 한 개와 동시 요청을 각각 재야 운영 부하에서 달라지는 점을 볼 수 있어요.

MTP를 켰는데도 답변 생성 속도가 낮다면 로그에서 실제로 선택된 Lightning MTP 경로와 초안 깊이, 후보 승인 동작을 확인해요. 일반 생성으로 돌아갔다면 모델 구조와 캐시 조합을 대조하세요. Lightning MTP가 적용됐는데도 승인률이 낮다면 같은 요청에서 초안 깊이와 체크포인트를 하나씩 바꿔 비교해요.

KV 캐시는 이미 처리한 토큰의 계산 결과를 보관해 뒤따르는 토큰을 생성할 때 재사용해요. 다른 요청에서도 공통 입력의 계산을 재사용할지는 서버의 프리픽스 캐시 설정에 따라 달라져요. MTP 전후를 비교할 때는 캐시를 비운 새 대화와 같은 문서에 이어 묻는 대화를 나눠 기록하고, 입력 길이와 요청 순서도 맞춰요.

동시 요청이 들어오면 엔진의 배치와 메모리 사용량이 달라져요. 서버에서 MTP를 평가할 때는 요청 하나로 정상 응답과 처리량⁷ 기준을 먼저 기록해요. 이어 실제 동시 요청 패턴을 재현하고, 같은 입력으로 오류와 전체 처리량을 비교해요. 사용하는 모델과 체크포인트에서 이 측정을 진행해요.

MTP 결과가 반복해서 빠르고 답변 품질도 유지되면 해당 체크포인트와 oMLX 버전을 함께 사용해요. 모델이 자주 바뀌거나 변환 파일에 MTP 헤드가 없다면 일반 생성 경로를 기준으로 삼아요. 서버 로그에서 실제 실행 경로를 확인하고, 같은 요청의 전후 시간과 답의 정확성을 기록해요.