홈 서버에서 AI 런타임 상태를 모델 파일과 분리해야 하는 이유は?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Separate AI Runtime State From Model Files on a Home Server? - Zima Store Online

AI 런타임 상태는 모델 파일과 분리해야 합니다. 변경되지 않는 가중치와 변경 가능한 캐시는 서로 다른 권한, 백업, 업그레이드 및 복구 규칙을 필요로 하기 때문입니다.

로컬 AI 컨테이너는 모델 체크포인트를 읽는 동시에 다운로드 메타데이터, 컴파일된 커널, 프롬프트 캐시, 대화 상태, 임시 업로드 파일, 잠금 파일, 로그 및 메모리 할당자 스냅샷을 계속 기록할 수 있습니다. 이러한 파일을 모두 하나의 쓰기 가능한 디렉터리에 배치하면 어떤 파일이 기준 데이터인지, 삭제 가능한지, 개인정보를 포함하는지, 특정 버전에 종속되는지 또는 안전하게 삭제할 수 있는지 판단하기 어려워집니다. 아래에서는 분리된 레이아웃이 모델 무결성을 보호하면서 런타임 상태가 독립적으로 변경되고 만료되며 복구될 수 있도록 하는 방법을 설명합니다.

모델 아티팩트와 런타임 상태는 수명 주기가 다릅니다

모델 가중치, 토크나이저 자산, 구성 및 양자화 메타데이터는 일반적으로 특정 모델 리비전을 설치할 때만 변경됩니다. 반면 런타임 파일은 요청이나 재시작이 발생할 때마다 변경될 수 있습니다.

Harbor의 모델 관리 지침은 대규모 AI 파일에 아티팩트 불변성을 적용하여 이름이 지정된 리비전을 재현 가능하게 유지합니다. 변경 가능한 캐시 항목을 해당 아티팩트 경로에 섞으면 모델 버전의 의미가 약해집니다.

명확한 경계에서는 모델 디렉터리를 버전이 지정된 입력으로, 런타임 디렉터리를 생성된 상태로 취급합니다. 런타임은 설치된 가중치를 무심코 변경하지 않고도 다시 구축할 수 있습니다.

읽기 전용 모델 경로는 실수와 악의적인 변경을 제한합니다

추론 서비스는 일반적으로 모든 요청에서 모델 파일을 다시 쓰는 것이 아니라 읽기만 하면 됩니다. 해당 경로를 읽기 전용으로 마운트하면 침해된 플러그인, 잘못된 정리 작업 또는 실수로 실행된 컨테이너 명령이 체크포인트 샤드를 교체하는 것을 막을 수 있습니다.

컨테이너 보안 지침에서는 애플리케이션 트리 전체를 프로세스에 쓰기 가능하게 제공하기보다 로그, 캐시 및 임시 파일을 위한 제한된 쓰기 가능 경로를 사용할 것을 권장합니다.

읽기 전용 저장소가 모델의 신뢰성을 증명하는 것은 아니지만, 검증이 끝난 뒤 설치된 바이트를 보존하고 예상치 못한 쓰기 작업이 눈에 띄게 실패하도록 합니다.

새 모델 리비전은 사용자 프롬프트를 처리할 때 사용하는 권한과 동일한 권한으로 가져오지 말고, 제어된 가져오기 또는 배포 단계를 통해 제공해야 합니다.

컴파일된 커널과 실행 캐시는 런타임 상태에 속합니다

추론 엔진은 특정 GPU 모델, 드라이버, 프레임워크 빌드, 텐서 형태 및 구성에 맞춰 커널이나 실행 그래프를 컴파일할 수 있습니다. 이러한 아티팩트는 이후 시작 시간을 단축할 수 있지만 환경에서 파생된 데이터입니다.

NVIDIA 엔지니어링 문서는 초기화된 런타임 상태를 모델 가중치 자체와 별개의 콜드 스타트 지연 요인으로 설명합니다. 체크포인트가 변경되지 않았더라도 드라이버나 런타임 업데이트로 인해 해당 상태가 무효화될 수 있습니다.

컴파일 캐시와 커널 캐시는 버전이 지정된 런타임 캐시 루트 아래에 저장하세요. 그러면 기준 모델 사본을 삭제하지 않고도 캐시를 정리하거나 다시 생성할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

대화 및 프리픽스 캐시에는 사용자별 데이터가 포함됩니다

KV 캐시, 프롬프트 캐시, 검색된 문서, 임시 업로드 및 세션 메모리에는 가정 내 맥락이 포함되거나 해당 맥락이 인코딩될 수 있습니다. 이러한 데이터의 개인정보 보호 및 만료 규칙은 공개 모델 가중치와 동일하지 않습니다.

LMCache의 아키텍처는 KV 캐시 상태를 추론 워커와 분리하여 워커가 변경되어도 캐시 재사용이 유지되도록 합니다. 이러한 분리는 소유권, 보존 기간 및 정리 작업을 별도의 운영 책임으로 관리할 수 있게 합니다.

ZimaSpace의 사용자별 컨텍스트 가이드는 런타임 캐시가 하나의 공용 모델 디렉터리의 광범위한 공유 정책을 따르지 않고 사용자 ID를 따라야 하는 이유를 보여줍니다.

모델 파일을 백업한다는 이유만으로 일시적인 프롬프트 상태를 자동으로 백업하지 마세요. 먼저 해당 상태가 필요한지, 개인정보를 포함하는지, 재현 가능한지, 보존 기간 내에 있는지를 판단해야 합니다.

경로를 분리하면 업그레이드와 롤백을 예측 가능하게 관리할 수 있습니다

업데이트를 통해 런타임 이미지를 교체하거나 새 모델 리비전을 활성화하면서 호환되는 상태만 보존할 수 있어야 합니다. 코드, 모델 파일 및 생성된 데이터가 섞여 있으면 롤백 후 서로 맞지 않는 조합이 복원될 수 있습니다.

불변 배포 패턴은 애플리케이션 상태 위치를 명시적으로 유지합니다. 실패한 런타임 업그레이드는 교체할 수 있고, 영구 경로는 점검 가능한 상태로 유지되며 모델 리비전은 변경되지 않습니다.

가중치를 제자리에서 덮어쓰지 말고 리비전이 지정된 모델 디렉터리와 원자적으로 전환되는 활성 포인터를 사용하세요. 컴파일된 아티팩트를 안전하게 공유할 수 없다면 각 런타임 버전에 호환되는 별도의 캐시 네임스페이스를 제공하세요.

백업 및 정리 정책은 데이터의 가치에 따라 정해야 합니다

모델 파일은 다시 다운로드할 수 있거나, 로컬에서 미세 조정되었거나, 라이선스가 적용되었거나, 재구성하는 데 많은 비용이 들 수 있습니다. 런타임 상태는 삭제 가능한 임시 파일부터 중요한 대화와 다시 만들 수 없는 로컬 어댑터까지 다양합니다.

모델 아티팩트 전략은 모델 계보를 강조하여 배포에 사용된 정확한 가중치와 구성을 식별할 수 있도록 합니다. 반면 런타임 백업은 비즈니스 가치, 개인정보 보호 및 복구 가능성을 기준으로 선택해야 합니다.

다시 생성할 수 있는 커널 캐시, 불완전한 다운로드 및 임시 텐서는 일반 백업에서 제외하세요. 미세 조정 모델, 어댑터, 사용자가 승인한 기록 및 구성은 자체적으로 테스트된 복원 경로를 통해 보호해야 합니다.

캐시 삭제가 모델 가중치까지 탐색하지 못하고 모델 정리가 활성 사용자 상태를 삭제하지 못하도록 하면 디스크 정리를 더 안전하게 수행할 수 있습니다.

명확한 계약을 중심으로 저장소 레이아웃을 구성하세요

변경 불가능한 모델 리비전, 활성 모델 선택, 진행 중인 다운로드, 컴파일된 아티팩트, 프롬프트 또는 KV 캐시, 사용자 세션, 로그 및 임시 업로드를 각각 별도의 경로에 저장하세요. 각 경로에 대해 소유자, 권한, 할당량, 보존 기간 및 백업 정책을 기록해야 합니다.

클라우드 네이티브 모델 레지스트리 패턴은 버전이 지정된 모델 아티팩트를 사용하여 배포 상태가 특정 모델을 가리키도록 하며, 생성된 런타임 파일을 해당 리비전의 일부로 취급하지 않습니다.

모델 경로를 읽기 전용으로 설정하고, 캐시 경로만 삭제하고, 런타임을 재시작하고, 런타임 이미지를 롤백하고, 컴파일된 아티팩트는 복원하지 않은 채 사용자 상태를 복원하는 방식으로 테스트하세요. 각 작업은 절차에서 지정한 계층에만 영향을 주어야 합니다.