Transformers, 생성 입력의 원래 타입을 유지하도록 수정

생성 준비 중 입력의 클래스가 사라지던 문제

Transformers 5.20.2는 한국시간 2026년 10월 20일 공개됐습니다. 공식 패치 노트의 주요 수정은 generate() 내부의 prepare_inputs_for_generation 단계에서 일부 입력이 원래 타입을 잃던 문제입니다. 특히 여러 종류의 입력을 사용하는 모델에 문제가 생길 수 있다고 설명합니다.

변경 요청 #49731은 이전에 추가된 move_to_device 함수가 딕셔너리 형태의 입력을 처리하면서 클래스 정보를 잃게 했다고 짚습니다. Transformers 자체의 ModelOutput도 OrderedDict를 상속하므로 영향을 받습니다. 안에 든 텐서 값이 유지되더라도 객체가 일반 딕셔너리로 바뀌면, 다음 단계에서 기대하는 속성 접근이나 구조가 달라질 수 있습니다.

텐서를 옮기는 과정에서 바깥 구조도 보존합니다

수정 코드는 각 값을 재귀적으로 장치에 옮긴 뒤 일반 딕셔너리를 만드는 대신 원래 입력 타입으로 다시 구성합니다. 리스트와 튜플 같은 중첩 컨테이너의 형태를 유지하는 기존 처리와 함께, 값뿐 아니라 컨테이너의 의미도 보존하려는 변경입니다. 여기서 말하는 타입은 파이썬 객체의 클래스이며, FP16·BF16 같은 텐서 정밀도를 바꾸는 업데이트가 아닙니다.

공개된 회귀 테스트는 BaseModelOutput 안에 텐서와 텐서 튜플을 넣어 장치 이동 함수를 거치게 합니다. 결과가 여전히 BaseModelOutput이고 내부 hidden_states가 튜플인지 확인합니다. 이어 생성 입력 준비 단계에서도 이전 출력 객체와 내부 튜플의 타입이 유지되는지 검사합니다.

결과 문장만 비교하면 원인을 놓칠 수 있습니다

이 문제를 살피려면 모델의 최종 답변뿐 아니라 생성 준비 전후의 입력 구조를 함께 봐야 합니다. 동일한 텐서를 넣더라도 특정 모델은 딕셔너리 접근을, 다른 모델은 객체 속성이나 구조화된 출력을 기대할 수 있습니다. 따라서 단순한 텍스트 생성 하나가 성공했다고 모든 멀티모달 경로까지 검증된 것은 아닙니다.

프로젝트에 직접 만든 출력 타입이나 전처리 래퍼가 있다면 원래 클래스로 다시 구성할 수 있는지도 확인할 만합니다. 공식 수정이 임의의 사용자 정의 컨테이너와 모든 생성 설정을 보장한다고 확대해서 말할 근거는 없습니다. 문제가 발생했던 입력을 작은 사례로 줄이고 타입·키·내부 튜플 여부를 비교하면 회귀를 찾기 쉽습니다.

같은 패치의 다른 변경은 따로 봅니다

5.20.2에는 전문가 병렬과 FSDP 크기 조합에서 BF16 전문가 그래디언트가 0이 되는 문제, 일부 비전·언어 모델의 입력 종류 선언, 마스크 처리의 불필요한 호스트·장치 복사 수정도 포함됩니다. 각기 다른 경로이므로 이번 타입 보존 수정 하나로 설명하지 않았습니다. 이 글은 공식 릴리스와 코드·테스트 변경을 대조한 내용이며, 실제 모델 학습이나 생성 성능 시험을 수행한 결과는 아닙니다.

출처

• 공식 릴리스 원문
• 입력 타입 손실의 원인 #49731
• 타입 보존 구현과 회귀 테스트