max_new_tokens를 늘리면 긴 문서를 더 많이 읽을까

입력 분량과 새로 만들 출력 분량을 구분하는 AI 생성 개념 이미지입니다.

긴 입력이 잘리는 문제와 답변이 짧게 끝나는 문제를 나누고, 입력 길이와 새로 생성할 토큰 한도를 각각 확인하세요.

긴 문서를 읽혀도 답이 짧게 나오자 max_new_tokens를 크게 올립니다. 답변의 상한은 늘릴 수 있지만, 토크나이저가 이미 잘라 낸 문서가 다시 입력되는 것은 아닙니다. 입력을 얼마나 전달했는지와 출력을 얼마나 허용했는지가 다른 설정이기 때문입니다.

이 글은 2026년 9월 13일 확인한 Transformers v5.17.0 문서를 기준으로 설명합니다. 주로 입력과 출력이 하나의 문맥 길이를 함께 쓰는 decoder-only 텍스트 생성 상황을 다룹니다. 아래 8192토큰 예산은 가상 조건이며 특정 모델의 지원 길이나 실제 생성 결과가 아닙니다.

max_new_tokens는 새로 생성할 부분의 상한입니다

Transformers는 max_new_tokens를 프롬프트 토큰 수와 별개로 새로 생성할 토큰의 최대 개수로 설명합니다. 모델에 전달할 문서의 입력 한도를 늘리는 옵션은 아닙니다. max_length와 혼동하지 말고 현재 API의 길이 매개변수 정의를 확인해야 합니다. GenerationConfig의 출력 길이 설정

예를 들어 입력이 7000토큰이고 max_new_tokens가 1000이라면, 새 출력에 허용한 상한이 1000이라는 뜻입니다. 모델이 반드시 1000토큰을 채워야 한다는 뜻도 아니고, 입력 문서를 추가로 1000토큰 더 읽는다는 뜻도 아닙니다.

종료 토큰이나 stop 조건에 따라 더 일찍 끝날 수 있습니다. 따라서 “한도를 1000으로 설정했는데 200토큰만 나왔다”는 사실만으로 옵션이 무시됐다고 판단하지 않습니다. 무엇이 생성을 끝냈는지 확인해야 합니다.

답변을 자세하게 써 달라는 요청도 출력 한도와 다른 요소입니다. 내용을 충분히 풀어 설명하도록 요구하는 것과 그 설명이 들어갈 최대 공간을 허용하는 것은 함께 필요할 수 있지만 서로를 대신하지 않습니다.

입력 잘림은 토크나이저와 실행 환경에서 확인합니다

토크나이저의 truncation은 입력이 특정 길이를 넘을 때 잘라 내는 동작과 관련됩니다. max_length와 패딩·잘림 설정에 따라 실제 입력 ID가 달라질 수 있습니다. 입력 원문이 긴데 실행이 성공했다는 이유만으로 전체 문서가 전달됐다고 가정하지 않습니다. 토크나이저의 truncation과 max_length

원문 문자열의 길이와 토큰 수는 같지 않습니다. 한국어 글자 수나 띄어쓰기 단어 수를 곧바로 토큰 수로 바꾸면 안 됩니다. 모델에 맞는 토크나이저로 최종 입력을 만든 뒤 그 길이를 확인합니다.

대화형 입력에는 문서뿐 아니라 system 메시지, 앞선 대화, 역할과 종료를 표시하는 제어 토큰이 들어갈 수 있습니다. 질문과 문서의 텍스트만 세고 템플릿이 추가한 부분을 제외하면 문맥 예산이 어긋납니다. 대화 템플릿과 토큰열

서버를 경유한다면 서버가 문맥 크기를 별도로 제한하거나 입력을 처리하는 정책도 확인해야 합니다. 로컬 설정의 숫자와 실제 서버가 받아들인 길이가 같다는 증거가 필요합니다. 다만 모든 서버가 같은 오류나 잘림 방식을 쓴다고 일반화하지 않습니다.

가상 8192토큰 문맥에서 남는 공간을 계산해 봅니다

단순한 decoder-only 모델과 실행 환경이 입력·출력을 합쳐 8192토큰까지 허용한다고 가정하겠습니다. 템플릿과 대화를 포함한 최종 입력이 7000토큰이면 새 출력을 위한 남은 공간은 1192토큰입니다.

여기에 max_new_tokens=2048을 요구하면 합계는 9048이고 가정한 예산을 856토큰 초과합니다. 이 계산은 모델을 실행해서 얻은 오류가 아니라 명시한 조건의 산술입니다.

다음은 이 가상 예산을 검사하는 보조 함수입니다. Transformers가 제공하는 함수가 아니며 실제 모델의 한도를 자동으로 찾아 주지도 않습니다.

def check_budget(input_tokens, requested_output, context_limit):
    values = (input_tokens, requested_output, context_limit)
    if any(type(value) is not int for value in values):
        raise TypeError("토큰 수와 한도는 정수여야 합니다.")
    if input_tokens < 0 or requested_output < 1 or context_limit < 1:
        raise ValueError("토큰 수와 한도를 확인해야 합니다.")

    available = context_limit - input_tokens
    return {
        "input_tokens": input_tokens,
        "requested_output": requested_output,
        "available_output": max(available, 0),
        "fits": available >= requested_output,
    }

over = check_budget(7000, 2048, 8192)
assert over["available_output"] == 1192
assert over["fits"] is False

within = check_budget(7000, 1000, 8192)
assert within["fits"] is True

두 번째 검사는 1000토큰 상한이 이 단순 예산 안에 들어온다는 뜻일 뿐입니다. 실제 메모리가 충분한지, 해당 모델이 그 길이의 입력을 의미 있게 처리하는지, 답변 품질이 필요한 수준인지는 증명하지 않습니다.

또한 encoder-decoder 모델처럼 입력과 출력 구조가 다른 경우에 이 합산식을 그대로 적용해서는 안 됩니다. 모델과 서빙 환경의 실제 문맥 계약을 확인한 뒤 맞는 예산식을 사용해야 합니다.

부족한 공간을 어떻게 마련할지는 작업 요구로 정합니다

가상 예시에서 2048토큰의 답변이 꼭 필요하다면 입력을 줄일지, 더 긴 문맥을 지원하는 구성을 사용할지 검토해야 합니다. max_new_tokens 숫자만 올리는 것으로 전체 예산을 늘릴 수는 없습니다.

입력을 줄일 때도 어떤 부분을 버릴지 정해야 합니다. 계약서의 예외 조항이나 문서 마지막의 조건을 잘라 놓고 전체를 읽었다고 답하면 원래 작업을 달성한 것이 아닙니다. 잘림 여부와 제외한 범위를 결과에 드러내야 합니다.

필요한 구간을 검색해서 넣거나 문서를 나누어 처리하는 방법도 후보입니다. 하지만 조각 사이의 관계를 읽어야 하는 질문이라면 단순 분할이 충분하지 않을 수 있습니다. 요약을 먼저 만들면 요약 과정에서 빠지는 정보도 검토해야 합니다.

반대로 짧은 형식의 답이 필요한 작업이라면 출력 예산을 줄이는 편이 맞을 수 있습니다. 중요한 것은 어떤 입력과 답변 요구를 유지했는지입니다. 실행 성공을 위해 범위를 바꿨다면 그 변경을 숨기지 않습니다.

짧게 끝난 답변은 종료 이유부터 봅니다

답변이 짧은 경우에는 실제 출력 토큰 수와 종료 조건을 나눠 봅니다. 길이 상한에 도달했는지, 종료 토큰을 생성했는지, 설정한 stop 문자열에 걸렸는지, 요청 자체가 중단됐는지에 따라 대응이 달라집니다. 생성 전략과 종료 설정

서빙 API가 종료 사유를 제공하면 그 정의를 확인합니다. 로컬 generate에서는 반환 값의 형태와 적용한 생성 설정을 함께 살펴봐야 합니다. 모든 실행 도구가 동일한 finish_reason 필드를 준다고 가정하지 않습니다.

일반적인 decoder-only generate 결과가 입력 토큰을 포함한 시퀀스라면 입력 길이를 빼서 새 출력 길이를 구분할 수 있습니다. 하지만 문자열을 디코딩한 뒤 프롬프트 글자 수를 빼는 방식은 토큰 계산이 아닙니다. 반환 형식이 다른 API나 다른 모델 구조에서는 그 방식도 다시 확인해야 합니다.

생성 한도에 도달하지 않았는데 설명이 부족하다면 질문의 요구, 모델의 특성, 대화 템플릿과 종료 설정을 검토합니다. 공간이 남아 있다는 이유만으로 모델이 알아서 필요한 예시와 결론을 모두 작성하지는 않습니다.

최소 길이 설정으로 종료를 늦추는 것은 별도의 선택입니다. 토큰을 더 채우는 것이 내용의 밀도를 높인다는 보장은 없으므로, 필요한 설명을 실제로 했는지와 반복 문장을 늘렸는지를 함께 봐야 합니다.

입력 한도를 늘리면 메모리와 시간도 다시 확인합니다

긴 문맥을 허용하는 구성으로 바꿨다고 비용 없이 문서를 더 읽는 것은 아닙니다. 입력 처리량이 늘고 생성 과정에서 유지할 상태도 커질 수 있습니다. 특히 KV 캐시의 크기는 모델의 attention 구조와 캐시 방식에 영향을 받습니다. 긴 문맥과 캐시 전략

따라서 문맥 한도 변경 전후에는 실제 입력 길이, 생성한 길이, 완료 여부와 메모리·시간을 함께 기록합니다. 설정한 최대값과 실제 처리한 길이를 같은 값으로 취급하지 않습니다.

토크나이저의 model_max_length 같은 숫자도 출처를 확인해야 합니다. 명확한 최대값이 없을 때 매우 큰 기본값이 사용될 수 있으므로 그 숫자를 모델의 검증된 문맥 지원으로 읽으면 안 됩니다. 토크나이저 최대 길이 설정

비교 결과가 없는 상태라면 “더 긴 입력을 지원하도록 설정했다”와 “그 길이의 문서를 정상적으로 처리했다”를 구분합니다. 이 글의 예산 계산 역시 실행이나 품질 검증의 대체물이 아닙니다.

두 종류의 부족을 나눠야 수정할 곳이 보입니다

문서가 빠지는 문제라면 먼저 최종 입력 ID와 잘림 설정, 서버의 문맥 제한을 확인합니다. 답변이 중간에 끊기는 문제라면 실제 출력 길이와 종료 사유를 봅니다. 둘 다 확인하지 않고 max_new_tokens만 바꾸면 원인이 그대로 남을 수 있습니다.

검수 자료에는 전달하려던 입력, 실제 입력 토큰 수, 출력 상한, 실제 출력 길이, 종료 조건과 제외된 입력 범위를 남깁니다. 문서 전체를 처리했는지와 필요한 답을 끝까지 작성했는지를 별도로 확인할 수 있어야 합니다.

max_new_tokens는 답변이 들어갈 공간의 상한입니다. 문서를 얼마나 읽었는지와 설명을 얼마나 충실하게 했는지는 따로 검증해야 합니다. 이 두 판단을 나누면 입력을 조용히 잘라 해결하거나 답변을 의미 없이 길게 늘리는 대신, 실제로 부족한 부분을 고칠 수 있습니다.