한 토큰씩 기다리는 생성 경로를 줄이면 문장이 더 빨리 완성될까요. Next-Concept Modeling(NCM)은 텍스트를 거친 표현에서 세밀한 표현으로 이어지는 이산 코드 계층으로 바꾸고, 같은 계층의 코드를 병렬로 예측합니다. 질문은 토큰 하나를 얼마나 빨리 계산하느냐에서 몇 번의 순차 단계를 거쳐야 하느냐로 이동합니다.
10월 9일 제출 논문의 31배는 XSum에서 특정 확산 언어 모델과 비교한 결과입니다. 11월 9일 브리핑에서 다시 주목한 것이며 당일 발표 논문이 아닙니다. 범용 GPT 계열 서비스와의 비교로 읽으면 안 됩니다.
개념은 사람이 붙인 의미 라벨이 아니다
논문 §3은 먼저 텍스트의 다중 해상도 표현을 배우는 토크나이저, 그 표현의 계층을 생성하는 모델이라는 두 단계를 설명합니다. 잔차 양자화는 이전 단계에서 표현하지 못한 차이를 뒤의 코드로 보완합니다. 여기서 개념은 사람이 작성한 주제 목록이 아니라 학습된 이산 표현입니다.
텍스트 → 학습된 계층 코드 (표현 학습)
조건 → 거친 코드 → 세부 코드 → 텍스트 복원 (생성)
같은 계층 안의 코드는 병렬 예측
자체 개념 도식입니다. 계층 사이에는 순서가 남습니다. 따라서 “모든 텍스트를 한 번에 생성한다”는 설명도 정확하지 않습니다. 표현의 압축·복원 품질과 계층 예측 품질을 함께 평가해야 합니다.
NFE를 줄인 만큼만 빨라지는 것은 아니다
§4 Inference Efficiency와 Figure 1은 H100 SXM 80GB 한 장, 배치 16으로 1,024개 시퀀스를 생성한 wall-clock 비교를 제시합니다.
| 데이터셋 | 저자 보고 속도 배수 | 품질 비교 맥락 |
|---|---|---|
| LM1B | 21× | DUO보다 나은 generative perplexity |
| OpenWebText | 10× | 가장 강한 DLM과 경쟁적인 품질 |
| XSum | 31× | AURORA-LM과 비슷한 ROUGE-L |
서로 다른 품질 지표와 작업을 하나의 평균 속도로 합칠 수 없습니다. 논문은 LM1B에서 NFE가 11배 적으면서 속도는 21배, XSum에서 NFE가 16배 적으면서 속도는 31배라고 보고합니다. NFE는 모델 평가 횟수입니다. 각 평가의 비용이 같지 않으므로 단계 수만으로 지연시간을 예측할 수 없습니다. 초기의 거친 계층은 처리할 코드 수가 적다는 것이 논문이 설명하는 차이입니다.
서비스의 대기시간으로 옮기기 전에
위 실험은 1,024개 생성의 배치 조건입니다. 한 사용자가 첫 텍스트를 기다리는 시간이나 긴 대화의 스트리밍 경험을 직접 측정한 값은 아닙니다. 생성 결과의 perplexity가 좋다는 사실도 지시 이행, 도구 호출, 근거 충실성까지 보장하지 않습니다.
실무 비교표에는 전체 생성 시간, 첫 출력 시간, 출력 길이, 배치 크기, 품질 통과율을 별도 열로 두세요. 표현 학습과 복원 비용이 측정 경계에 들어가는지도 확인해야 합니다. 기존 자기회귀 모델의 가중치에 바로 붙이는 서빙 옵션이라고 가정하면 도입 비용을 과소평가합니다. 논문 자체가 두 단계 학습을 전제로 합니다.
지금 가져갈 것은 비교 방법이다
이 글에서는 모델을 학습하거나 추론하지 않았고 수치를 재현하지 않았습니다. 코드 예제를 가장해 존재하지 않는 API를 제시하지도 않습니다. 도입 검토에는 코드 공개 범위, 가중치·라이선스, 목표 길이에서의 품질과 메모리, 실제 서비스 지연시간을 추가로 확인해야 합니다.
NCM이 보여주는 중요한 방향은 짧은 순차 경로와 단계별 계산량을 함께 설계한다는 점입니다. 실무자는 당장 기존 모델을 교체하기보다, 자신의 평가가 초당 토큰만 보고 있는지 확인할 수 있습니다. 같은 품질 기준을 넘는 완성된 결과를 얻는 데 걸리는 시간을 비교해야 생성 방식의 차이를 판단할 수 있습니다.