"파일명은 그 파일에 대한 사람의 주장이야. 안에 든 tensor 는 파일 자신의 고백이고. 고백 쪽을 믿어."
사람은 이름을 틀려
진짜 모델 디렉토리를 한 바퀴 돌아 보면 거짓말이 나와. lora_something.safetensors 라는 이름인데 사실은 backbone 이 통째로 구워진 merged checkpoint 인 파일. sdxl/ 이라는 폴더인데 누가 잘못 떨어뜨린 SD1.5 모델이 들어 있는 경우. vendor 이름을 달고 있는데 실은 커뮤니티가 fine-tune 한 checkpoint. 사람은 끊임없이 이름 바꾸고 폴더 옮기고 잘못 붙여. 그리고 파일명을 믿는 분류기는 그 실수를 하나도 빠짐없이 물려받아.
tensor 가 기준이야
safetensors 파일 안에는 tensor 를 전부 나열한 헤더가 있어. key 이름이랑 shape 이 적혀 있지. 그 key 랑 shape 은 모델의 실제 아키텍처가 정하는 거라 파일 이름 바꾼다고 흉내 낼 수가 없어. 진짜 SDXL 모델은 SDXL 의 tensor key 를 갖고, 진짜 FLUX transformer 는 FLUX 의 것을 가져. 이 파일이 진짜로 뭔지 알고 싶으면 이름을 읽지 말고 헤더를 읽어. 안에 실제로 뭐가 들었는지 보는 거야.
구체적인 함정: merged checkpoint
이게 왜 중요한지 실제 예를 보자. 누가 LoRA tensor 를 backbone 이랑 같이 구워 놓은 checkpoint 를 공유해. 파일명이나 lora_ key 가 있다는 것만 보면 순진한 분류기는 이걸 LoRA, 그러니까 작은 덧붙임 파일이라고 불러. 그런데 backbone 이 통째로 들어 있으니까 실제로는 기가바이트짜리 full checkpoint 야. 이걸 틀리면 엔진이 몇 GB 짜리 'LoRA' 를 작은 패치인 줄 알고 올리려 하고, 그 아래로 전부 깨져. 해법은 LoRA key 를 보기 전에 backbone 이 통째로 들어 있는지부터 확인하는 거야. 검사 순서가 곧 증거의 우선순위인 거지.
어디를 훑느냐와 무엇이냐는 다른 축이야
여기 미묘한 두 번째 교훈이 있어. 어느 디렉토리를 훑을지 정하는 것과 이 파일이 무슨 종류인지 정하는 건 별개의 질문이야. 엔진은 models 디렉토리는 훑고 embeddings 디렉토리는 뺀다고 치자. 그건 훑을 범위에 대한 결정이고, 폴더로 정해도 돼. 그런데 그 범위 안에서 파일의 종류는 절대 폴더로 안 정해. 오직 tensor 로만 정해. 이 두 축을 뭉뚱그리는 게 폴더를 믿으면 안 되는 자리에서까지 폴더를 믿게 되는 길이야.