
최근 공개된 오픈소스 LLM 중에서 구조적으로 가장 흥미로운 변화를 보여준 모델을 꼽으라면 단연 다중 토큰 예측 기술을 적극적으로 도입한 모델들일 것입니다.
그동안 대형 언어 모델은 한 번에 딱 하나의 다음 토큰만을 예측하는 방식으로 동작해 왔습니다.
하지만 최신 아키텍처들은 이 고정관념을 깨고 한 번에 여러 개의 토큰을 동시에 예측하는 MTP 레이어를 탑재하기 시작했습니다.
과연 이 기술의 내부 동작 원리는 무엇이며, 실제로 우리의 추론 속도를 얼마나 끌어올려 줄 수 있을까요? 그리고 이를 서비스나 개인 시스템에 적용할 때 VRAM과 컨텍스트 길이에 따른 트레이드오프는 무엇인지 상세히 파헤쳐 보겠습니다.
기존의 일반적인 LLM 학습 및 추론 방식을 지속적 단어 예측이라고 부릅니다.
주어진 텍스트 배열을 보고 바로 다음에 올 가장 확률이 높은 토큰 1개만을 맞추도록 훈련하는 방식입니다.
반면, MTP는 모델이 다음 토큰뿐만 아니라, 그 다음에 이어질 2번째, 3번째 토큰까지 한 번에 예측하도록 모델을 학습시키는 기술입니다.
이를 실현하기 위해 기존 메인 모델 구조 뒤에 'MTP 레이어'라는 특수한 신경망 헤드를 추가로 붙이게 됩니다.
이 과정에서 가장 핵심이 되는 개념은 바로 '히든 스테이트'의 재활용입니다.
이해를 돕기 위해 내부 연산 흐름을 단계별로 쪼개어 살펴보겠습니다.
메인 모델 연산: 입력된 문장들이 거대한 메인 모델의 모든 어텐션 레이어를 거치고 나면, 마지막 토큰의 최종 연산 결과물인 최종 히든 스테이트가 생성됩니다.
첫 번째 토큰 생성: 이 Hidden State 0을 언어 모델 헤드에 통과시켜 우리가 최종적으로 보게 되는 첫 번째 다음 토큰을 예측해 냅니다.
일반 모델과의 차이점: 일반적인 모델은 토큰을 뽑아내고 나면 이 Hidden State 0을 버립니다.
그리고 다음 토큰을 찾기 위해 을 다시 입력으로 넣어 메인 모델의 무거운 레이어들을 처음부터 다시 통과시킵니다.
하지만 MTP는 이 비싼 히든 스테이트를 버리지 않고 그대로 킵합니다.
MTP 레이어 가동: 보관해 둔 Hidden State 0과 방금 예측한 토큰의 임베딩 값을 아주 가벼운 'MTP 레이어'에 입력으로 던집니다.
MTP 레이어는 이를 조합하여 다음 단계의 히든 스테이트를 빠르게 계산해 내고, 이를 통해 메인 모델을 거치지 않고도 그 다음 토큰을 연속으로 예측해 냅니다.
이 구조를 수식적 흐름으로 표현하면 다음과 같습니다.
[단계 1: 메인 모델 결과물로 첫 번째 토큰 예측]
hidden_0 (메인 모델의 최종 결과물 벡터) ──> lm_head ──> t+1 토큰 예측
[단계 2: MTP 레이어 1개를 거쳐 두 번째 토큰 예측]
[hidden_0 + t+1 임베딩] ──> MTP 레이어 1 ──> hidden_1 ──> lm_head ──> t+2 토큰 예측
[단계 3: MTP 레이어 2개를 거쳐 세 번째 토큰 예측]
[hidden_1 + t+2 임베딩] ──> MTP 레이어 2 ──> hidden_2 ──> lm_head ──> t+3 토큰 예측
극도로 가벼운 신경망: MTP 레이어는 문장 전체를 보는 것이 아니라, 고작 직전의 히든 스테이트 1개와 신규 생성될 토큰 임베딩 1개, 총 2개의 임베딩 벡터만 입력받아 연산합니다.
따라서 메인 모델에 비해 연산량이 거의 없다시피 할 정도로 가볍습니다.
독립된 외장형 구조: MTP 레이어는 기존 메인 모델의 핵심 트랜스포머 블록 내부를 수정하는 것이 아니라, 모델의 출력단 바깥에 별도로 존재하는 구조입니다.
모델 배포의 이원화: 기존의 일반적인 인퍼런스 엔진들과의 하위 호환성을 유지해야 하므로, 인공지능 연구소들은 동일한 모델이더라도 MTP 레이어가 포함된 버전과 포함되지 않은 버전을 별도로 배포합니다.
MTP 기능을 활성화하여 속도 이득을 보려면 반드시 MTP 전용 모델 파일을 사용해야 합니다.
"MTP는 가볍다는데, 왜 내 그래픽카드의 VRAM을 더 많이 잡아먹을까?"라는 의문이 생길 수 있습니다.
결론부터 말씀드리면 MTP는 메인 어텐션 레이어처럼 엄청난 크기의 Key-Value Cache를 추가로 생성하지는 않지만, 미래의 토큰을 예측해 두고 검증하는 과정에서 독자적인 컨텍스트 버퍼 공간을 요구합니다.
MTP를 구동할 때 추가로 필요한 VRAM 용량은 아래의 공식으로 결정됩니다.
각 항목이 메모리를 차지하는 상세한 이유는 다음과 같습니다.
MTP 레이어 자체도 엄연히 학습된 파라미터를 가진 신경망입니다.
따라서 이 레이어의 크기만큼 VRAM에 고정적으로 상주해야 합니다. 이 용량은 사용자가 예측할 토큰 수를 아무리 늘리거나 줄여도 변하지 않는 고정값입니다.
MTP가 미리 앞서가며 예측할 토큰 수가 길어질수록, 그 예측된 토큰들이 차지하는 미니 컨텍스트 공간이 필요합니다.
MTP가 실제로 다음 토큰들을 연속적으로 병렬 연산하고 검증할 때 사용하는 실제 계산용 버퍼 용량입니다.
이 영역이 VRAM을 생각보다 굉장히 크게 잡아먹습니다.
💡 VRAM 할당 팁
시스템 환경에 따라 차이가 있지만, MTP를 안정적으로 5~10토큰 이상 예측하도록 세팅하려면 최소 500MB 수준의 VRAM 여유 공간을 미리 확보해 두어야 합니다.
반면, 딱 2토큰 예측 수준으로 낮게 설정하면 이 연산 버퍼 크기가 극적으로 줄어들어 VRAM을幾乎 소비하지 않으므로 자원이 타이트한 환경에서도 부담 없이 켤 수 있습니다.
MTP가 이론적으로는 훌륭하지만, 실제 로컬 환경이나 운영 서버에 적용했을 때는 여러 가지 복잡한 변수들 때문에 무조건 성능이 올라가지 않습니다.
오히려 역효과가 나는 경우도 존재합니다. 그 이유는 크게 세 가지입니다.
그래픽카드 용량을 한계치까지 꽉 채워서 컨텍스트 길이를 최대한으로 확보해 쓰는 유저들의 경우가 여기 해당합니다.
MTP를 구동하기 위해 수백 메가바이트의 VRAM 버퍼가 추가로 필요해지면, 인퍼런스 엔진은 자리를 만들기 위해 기존 메인 모델의 레이어 일부를 시스템 메모리로 밀어내게 됩니다.
레이어가 시스템 메모리로 나가는 순간 통신 병목으로 인해 MTP를 켜기 전보다 추론 속도가 훨씬 더 느려지는 현상이 발생합니다.
MTP 레이어가 미리 예측해 놓은 2번째, 3번째 토큰들은 어디까지나 '가짜 후보 토큰'입니다. 메인 모델은 이 후보들이 정말 문맥상 맞는지 검증하는 과정을 거치게 되는데, 만약 메인 모델이 MTP가 제안한 후보를 거절하면 그동안 MTP 레이어가 뒤에서 미리 계산해 둔 연산들은 전부 폐기됩니다.
결국 처음부터 다시 메인 모델이 정석대로 연산해야 하므로, 후보 채택률이 떨어지면 MTP를 안 쓰니만 못한 추가 연산 및 검증 비용만 낭비하게 됩니다.
대다수의 풀-어텐션 메인 모델들도 수십, 수백 Kbyte에 달하는 긴 문맥을 입력받으면 컨텍스트 후반부에서 헛소리를 하거나 집중력이 흐려지는 현상이 발생합니다.
그런데 거대한 메인 모델도 감당하기 힘든 긴 문맥 상황에서, 고작 '직전 히든 스테이트'와 '직전 토큰' 몇 개만 조합해서 가볍게 미래를 예측하는 MTP 레이어가 정확한 토큰을 맞출 확률은 얼마나 될까요? 문맥이 길어질수록 MTP의 예측 채택률은 바닥을 치게 됩니다. 코드 전체를 프롬프트로 집어넣고 개발하는 사용자 환경에서는 MTP의 후보 채택률이 30% 미만으로 떨어질 수 있습니다. MTP가 연산 시간 이득을 보려면 최소한 채택률이 50% 이상은 유지되어야 합니다.
그렇다면 실제 환경에서 수치 변화는 어떻게 일어날까요? 고성능 로컬 하드웨어 환경에서 긴 컨텍스트를 로드한 뒤, MTP 설정을 세부적으로 변경하며 토큰 생성 속도를 측정한 결과입니다.
MTP 설정을 완전히 껐을 때와, 최대 예측 토큰 수 및 최소 예측 토큰 수 설정을 조정했을 때의 실측 변화는 다음과 같습니다.
| 설정 케이스 | MTP 설정값 | 실측 속도 (TPS) | 상태 변화 | 후보 토큰 채택률 (%) |
|---|---|---|---|---|
| 기본 상태 | MTP 비활성화 | 61.26 tok/sec | 기준점 | - |
| 케이스 1 | max: 1 / min: 0 | 59.93 tok/sec | 성능 하락 | 43.5% |
| 케이스 2 | max: 2 / min: 0 | 62.99 tok/sec | 소폭 상승 | 54.9% |
| 케이스 3 | max: 2 / min: 1 | 65.78 tok/sec | 최적 (7.4% 증가) | 56.1% |
| 케이스 4 | max: 2 / min: 2 | 62.22 tok/sec | 소폭 상승 | 54.1% |
무조건적인 max 상향의 실패 : max: 1 설정으로 아주 보수적으로 접근했음에도 채택률이 43.5%에 그치며 오히려 끄니만 못한 속도 저하가 일어났습니다.
검증 실패로 인한 비용이 이득을 넘어선 구간입니다.
최적의 스위트 스폿 발견 : 최대 2개 토큰을 예측하되 최소 1개 토큰은 강제로 유지하도록 세팅한 max: 2 / min: 1 구조에서 65.78 TPS라는 가장 높은 속도를 기록했습니다.
순수 알고리즘 변경만으로 약 7.4%의 유의미한 속도 향상을 이뤄낸 것입니다.
이때의 채택률은 56.1%로 손익분기점인 50%를 넘겼습니다.
강제 고정의 한계: 최소 예측 개수마저 2개로 강제 고정해 버리면, 모델이 확신하지 못하는 상황에서도 억지로 2번째 토큰 후보를 연산해야 하므로 채택률이 다시 54.1%로 떨어지며 속도 이득이 감소했습니다.
VRAM의 보이지 않는 벽: 실험 환경에서 예측 토큰 수를 3개 이상으로 올리는 순간, 연산에 필요한 버퍼 공간이 150MB 이상 추가로 급증하게 됩니다.
262k라는 초장문 컨텍스트를 유지하기 위해 VRAM을 극한까지 끌어 쓰고 있는 세팅에서는 MTP 버퍼 공간 때문에 다른 핵심 레이어가 오프로딩되어 전체 속도가 무너집니다.
결국 3 이상의 설정은 시도조차 불가능하거나 손해를 보게 됩니다.
Multi-Token Prediction 기술은 모델 내부의 중간 연산 결과물인 히든 스테이트를 효율적으로 재활용하여 추가적인 메인 레이어 연산 없이 미래의 단어들을 빠르게 훑어내는 획기적인 기술이 맞습니다.
다만, 이 기술이 100% 제 성능을 내기 위해서는 시스템 자원과 프롬프트 문맥의 길이에 따른 정교한 튜닝이 필수적입니다. 실측 데이터를 기반으로 내린 최종 가이드는 다음과 같습니다.
자원이 타이트하거나 긴 코드를 주로 다루는 경우: MTP 토큰 예측 개수를 무리하게 5개, 10개씩 크게 잡지 마십시오. 채택률 저하와 연산 버퍼 비대화로 역효과가 납니다.
가장 추천하는 실전 세팅: 최대 2토큰 예측 / 최소 1토큰 보장 구성을 추천합니다.
이 세팅은 하드웨어 자원을 거의 소모하지 않으면서도 문맥 검증 확률을 안정적으로 가져갈 수 있어, 대용량 컨텍스트 환경에서도 안전하게 약 5% ~ 7% 내외의 순수 추론 속도 향상을 챙길 수 있는 가장 현명한 타협점입니다.