새 파이프라인 객체는 독립 복제본이 아니다

Diffusers의 from_pipe가 새 작업용 객체를 만들면서 기존 모듈을 재사용하는 방식을 살펴보고, 객체 정체성과 상태 독립성을 구분해 생성 업무의 기록·검증 경계를 설계한다.

이 글의 개념을 표현하기 위해 GPT Image 2로 생성한 이미지이며, 실제 모델 구조나 실행 화면을 재현한 것이 아니다.

텍스트로 이미지를 만든 뒤 같은 모델로 이미지 변환을 이어 가려는 상황을 생각해 보자. 처음에는 text-to-image 파이프라인을 쓰고, 다음 단계에서는 image-to-image 파이프라인이 필요하다. Diffusers의 AutoPipeline은 요청한 작업에 맞는 구체적인 파이프라인 클래스를 고른다. 이미 불러온 파이프라인에서 from_pipe()를 호출하면 새 작업용 객체도 얻을 수 있다.[1]

Python 변수와 객체가 하나 더 생기면 모델도 독립적으로 한 벌 더 생겼다고 생각하기 쉽다. 공식 문서가 설명하는 동작은 다르다. from_pipe()는 기존 파이프라인의 모듈을 사용해 새 파이프라인을 초기화하며, 추가 메모리를 재할당하지 않는다.[1] 객체 수만 세어서는 내부 자원의 소유권을 알 수 없다.

이 구분은 생성 업무의 기록 방식까지 바꾼다. 어느 설정이 어떤 결과에 영향을 주었는지 추적하려면, "객체가 둘"이라는 관찰과 "상태가 독립적"이라는 주장을 분리해야 한다. 한 경로에서 바꾼 어댑터, offloading hook, scheduler 또는 교체 컴포넌트가 다른 경로에 미친 영향을 놓친 채 결과를 비교하기 쉽기 때문이다.

새 객체가 말해 주는 것과 말해 주지 않는 것

from_pretrained()와 from_pipe()는 출발점이 다르다. from_pretrained()는 모델 저장소나 로컬 디렉터리의 설정과 가중치에서 파이프라인을 불러온다. from_pipe()는 이미 존재하는 파이프라인 객체의 컴포넌트를 재사용해 다른 클래스의 객체를 만든다.[1][2] 두 호출이 모두 새 Python 객체를 반환할 수 있지만, 객체가 만들어진 경로는 서로 다르다.

새 객체에서는 클래스 정체성을 확인할 수 있다. 요청한 작업이 text-to-image인지 image-to-image인지, 실제 반환 클래스가 무엇인지 읽을 수 있다. 클래스가 맞더라도 체크포인트 호환성, 생성 품질, 메모리 절감 또는 상태 분리가 증명되지는 않는다. 자동 선택은 작업에 맞는 입구를 찾아 줄 뿐 결과의 적합성을 승인하지 않는다.

문서가 직접 약속하는 것은 컴포넌트 재사용이다. 현재 Diffusers의 loading 문서는 여러 파이프라인이 같은 모델을 사용할 때 from_pipe()로 모델을 다시 불러오지 않고 재사용할 수 있다고 설명한다. 메모리 요구량은 만든 객체의 수가 아니라 그중 가장 높은 요구량을 가진 파이프라인에 의해 결정된다는 설명도 함께 제시한다.[2] 이 설명이 "모든 호출의 순간 최대 메모리가 언제나 같다"거나 "어떤 조합에서도 추가 임시 메모리가 없다"는 보편 법칙은 아니다. 입력 크기, 중간 활성값, 장치 이동과 추가 컴포넌트는 별도 조건이다.

상태의 독립성은 직접 확인해야 한다. 문서의 재사용 설명만으로 deep copy, thread safety, hook 수명, LoRA 상태, callback 호환성까지 확정할 수 없다. 같은 모듈을 가리키는 두 객체가 모든 속성을 공유한다고 단정할 수도 없고, 클래스가 다르다는 이유로 상태가 완전히 분리됐다고 볼 수도 없다. 확인한 관계만 기록해야 한다.

메모리 절감과 격리는 다른 약속이다

생성 시스템에서는 메모리를 아끼는 선택과 실험을 격리하는 선택이 자주 충돌한다. from_pipe()는 공통 모델을 다시 적재하지 않는 장점이 있다. 하나의 체크포인트로 여러 작업을 오갈 때 유용하다. 하지만 비교 실험에서는 출발 객체의 변경 이력을 신뢰할 수 있는지가 더 중요할 수 있다.

예를 들어 text-to-image 경로에 LoRA를 적용한 뒤 image-to-image 객체를 파생했다고 하자. 두 경로의 결과가 달라졌을 때 원인이 작업 클래스인지, 입력 이미지인지, 공유된 어댑터 상태인지 바로 알기 어렵다. 모델 CPU offloading처럼 파이프라인별 실행 순서에 맞춰 hook을 설치하는 기능도 파생 객체에서 다시 확인해야 한다. Diffusers 문서는 같은 컴포넌트를 재사용하는 것이므로 새 파이프라인의 방식에 맞게 파이프라인 수준 메서드를 다시 적용하라고 안내한다.[2]

따라서 from_pipe()와 독립적인 from_pretrained() 재적재 가운데 하나가 항상 더 옳지는 않다. 메모리 제약이 크고 상태 이력이 분명하면 재사용이 합리적이다. 반대로 원본 파이프라인에 어떤 변경이 있었는지 알 수 없거나 두 경로를 독립적인 기준선으로 비교해야 한다면, 별도 적재가 더 설명 가능한 선택일 수 있다. 별도 적재도 자동으로 깨끗한 실험을 보장하지는 않는다. 저장소 revision, 캐시, dtype, 교체 컴포넌트와 장치 배치를 같이 고정해야 한다.

AKM에는 객체 이름보다 관계를 남긴다

AKM에서 생성 결과를 지식 자산으로 다룰 때 pipe_a, pipe_b 같은 변수명은 거의 도움이 되지 않는다. 세션이 끝나면 이름은 사라지고, 어떤 출발점에서 어떤 작업 경로가 파생됐는지가 남아야 한다. 최소 기록은 다음 관계를 포함할 수 있다.

• 출발 체크포인트나 파이프라인의 식별자와 revision
• 요청한 작업과 실제 반환 클래스
• from_pretrained()인지 from_pipe()인지에 대한 구성 경로
• 재사용이 확인된 컴포넌트와 확인 방법
• LoRA, scheduler, offloading, callback, dtype와 장치 배치의 변경 이력
• 각 호출의 입력, 유효 설정, 출력 artifact와 검토 결과
• 비교가 성립하지 않게 된 첫 번째 불확실성

이 목록은 Diffusers가 요구하는 스키마가 아니라 작업 설계를 위한 최소 계약이다. 모든 내부 속성을 덤프하자는 뜻도 아니다. 결과 차이를 특정 조건에 귀속하고 나중에 같은 판단을 다시 검토하는 데 필요한 관계만 남긴다.

업무 흐름도 파이프라인 생성 성공 → 이미지 생성 성공처럼 한 줄로 끝내지 않는다. 구성, 호출, 파일 저장, 독립 재열기, 시각 검토, 실제 사용처의 채택은 서로 다른 단계다. 클래스가 정상적으로 반환됐어도 가중치 경고가 있을 수 있고, 이미지 객체가 생겼어도 저장 파일이 손상되거나 검토 기준을 통과하지 못할 수 있다. 각 단계의 readback을 분리하면 API 성공을 결과 승인으로 잘못 번역하는 일을 줄일 수 있다.

적용 범위와 한계

이 글은 현재 Hugging Face Diffusers 공식 문서의 AutoPipeline과 파이프라인 재사용 설명을 바탕으로 한다.[1][2] 특정 Diffusers 설치 버전, 체크포인트, GPU 또는 MPS 환경을 실행한 벤치마크가 아니다. 실제 객체의 모듈 identity, peak memory, 생성 시간, 동시 호출 안전성과 출력 품질도 측정하지 않았다.

공식 문서의 main 페이지는 바뀔 수 있다. 실제 업무에서는 설치된 Diffusers 버전과 그 버전에 해당하는 문서 또는 고정된 소스 revision을 대조해야 한다. 특정 파이프라인이 from_pipe()를 지원하는지, 교체한 컴포넌트가 호환되는지, 파생 객체에서 어떤 메서드를 다시 적용해야 하는지는 구체 클래스와 버전에서 확인해야 한다.

AKM 적용 역시 개념 제안이다. 어떤 필드를 필수로 만들고 얼마 동안 보관할지는 작업 위험과 재현 요구에 따라 달라진다. 개인 실험용 이미지 한 장과 공개 전시용 대량 생성은 같은 증거 비용을 들일 필요가 없다. 다만 결과를 비교하거나 인계할 계획이라면, 객체의 이름보다 구성 경로와 공유 관계를 먼저 남기는 편이 안전하다.

실무에서는 기록 순서부터 바꾼다

파이프라인을 만들 때 반환 클래스와 구성 경로를 함께 기록한다. AutoPipelineForImage2Image를 호출했다는 입력만 남기지 말고 실제 클래스와 출발 객체 또는 체크포인트를 읽어 둔다.

공유 상태를 바꿨다면 두 경로를 모두 다시 확인한다. 어댑터, scheduler, hook 또는 컴포넌트 교체가 있었다면 어느 객체에서 어떤 revision을 호출했는지 구분한다. 결과 이미지 한 장은 그 관계를 설명해 주지 않는다.

메모리 절감과 실험 격리도 따로 평가해야 한다. 메모리 재사용이 성공했어도 비교의 독립성이 부족할 수 있고, 별도 적재가 가능해도 revision과 입력이 다르면 실험은 무너진다. 객체를 몇 개 만들었는지보다 공유한 것과 분리한 것을 설명할 수 있는지가 중요하다.

from_pipe()는 모델을 복제하는 단축키가 아니다. 이미 가진 구성요소로 다른 작업 경로를 여는 도구다. 이 차이를 받아들이면 파이프라인 객체를 결과 생산 장치가 아니라 관계와 상태를 가진 작업 단위로 보게 된다. 생성 업무의 재현성은 변수 이름이 아니라 그 관계를 얼마나 정확히 남겼는지에서 시작한다.

Sources

[1] AutoPipeline · Hugging Face Diffusers

[2] DiffusionPipeline loading and reuse · Hugging Face Diffusers