MTP란? 다중 토큰 예측의 원리와 조건

예를 들어 세 후보 가운데 첫 토큰만 맞으면 그 후보는 남고 뒤의 두 개는 버려요. 모델은 어긋난 지점부터 답을 이어가므로 버린 후보를 출력하지는 않지만, 그 후보를 준비하고 검증하는 계산은 들었어요. 반대로 세 토큰이 연이어 맞으면 본 모델이 일부 순차 계산을 줄일 수 있어요.

따라서 제안 깊이가 길수록 항상 빠르지는 않아요. 후보가 자주 어긋나면 버리는 계산이 늘고, 이어지는 후보가 자주 승인되면 순차 계산을 줄일 여지가 커져요. 예측 토큰 수가 아니라 실제 요청의 완료 시간을 비교해요.

사용할 체크포인트³에 MTP 가중치가 남아 있고 실행 프로그램⁴이 그 구조를 지원해야 해요. 이름이 같은 모델도 변환 과정에서 예측 가중치가 빠질 수 있어요. 파일과 양자화⁵를 고정하고 런타임 버전 및 지원 경로를 확인하면 바뀐 결과를 MTP 적용 여부와 연결하기 쉬워요.

MTP를 켰는데 결과가 그대로라면 체크포인트나 런타임이 맞지 않아 일반 생성으로 돌아갔는지, 적용은 됐지만 후보 승인이 적었는지 로그에서 나눠 봐요. 지원 여부를 찾는 동안에는 정상 동작하던 모델을 기준으로 두고 파일을 여러 개 한꺼번에 바꾸지 않아요.

먼저 MTP를 끈 채 파일·질문·요청 길이로 기준 답변을 만들고, 같은 모델 파일에서 MTP 설정만 바꿔 실행해요. 준비 실행 뒤 두 상태를 각각 세 번 재서 중앙값을 비교하고, 모델을 다시 불러오는 비용은 별도로 기록해요. 대화 캐시나 함께 실행한 앱도 양쪽에서 같은 조건으로 맞춰요.

입력 처리가 오래 걸리는지 답변 생성이 느린지 먼저 살펴요. MTP가 겨냥하는 것은 주로 뒤의 생성 구간이에요. PDF 검색이나 긴 입력 뒤 첫 답이 늦다면 프리필⁶과 문서 전달도 따로 측정해요.

요청부터 첫 토큰까지의 TTFT⁷, 그 뒤 디코드⁸, 전체 완료 시간을 나눠요. 디코드 tok/s는 첫 토큰 뒤 생성한 토큰 수를 디코드 시간으로 나누고, 로딩과 TTFT는 포함하지 않아요. 두 답의 수정 범위와 생성 토큰 수가 비슷한지 함께 확인해요.

결과 코드에서 함수 이름과 호출부, 빈 입력 오류, 정상 입력 처리를 확인해요. 후보 토큰 검증은 사용자의 요구사항 검사가 아니므로, 시간이 줄어도 수정 범위가 빠졌다면 같은 일을 더 빨리 끝낸 게 아니에요.

경로가 적용됐는데 디코드 시간이 달라지지 않았다면 이번 요청에서 이득을 관찰하지 못한 거예요. 긴 PDF에서 첫 답이 늦으면 프리필과 검색을, 메모리 오류면 입력 길이와 캐시를 먼저 살펴요.

반복 측정에서 MTP가 실제 완료 시간을 줄이고 코드가 요구대로 동작하면 현재 장비를 계속 써도 돼요. 반대로 MTP가 지원되지 않거나 결과가 비슷하다면 광고의 최고 가속 수치를 구매 판단 근거로 삼지 말고, 지금 작업이 멈춘 다른 구간부터 해결해요.