모델 가중치 레지스트리 (Model Weight Registry)

공개 사항: 소스 수집 및 편집 검토를 위해 AI 도구가 사용되었습니다. 이 기사는 인간 저자에 의해 작성되었으며, 저자가 사실, 코드 및 결론을 확인했습니다.

암호화폐 위험 고지: 이 기사는 기술적 설명이며 투자 조언이 아닙니다. 이는 어떠한 암호화폐 자산의 매수, 매도 또는 보유를 권장하는 것이 아닙니다.

모델 가중치 레지스트리 (Model Weight Registry)는 모델 이름을 모델의 정체성 (Identity)으로 취급해서는 안 됩니다. 이름, 저장소 (Repository), 태그 (Tag), 브랜치 (Branch) 또는 사용자 대상 라벨은 유용한 소프트웨어를 가리킬 수 있지만, AI 가중치 (Weights)의 안정적인 정체성은 로드되는 정확한 바이트 (Bytes)에서 시작됩니다.

이러한 경계는 AI x 암호화폐 (Crypto) 시스템에서 중요합니다. 왜냐하면 온체인 (Onchain) 상의 주장은 사용자가 이를 신뢰한 이후에 수정하려면 비용이 많이 들기 때문입니다. 만약 컨트랙트 (Contract), 에이전트 (Agent) 또는 감사 추적 (Audit trail)이 "모델 X"라고 말한다면, 다음 질문은 "어떤 파일, 리비전 (Revision), 크기, 다이제스트 (Digest), 그리고 영수증 (Receipt)인가?"가 되어야 합니다.

바이트 정체성 (Byte Identity)

다이제스트 (Digest)는 선택된 알고리즘과 입력값에 따라 바이트를 식별합니다. NIST FIPS 180-4는 보안 해시 알고리즘 (Secure hash algorithms)을 정의하며, RFC 6920은 해시를 포함한 명명 정보 (Naming information)를 설명합니다.

이러한 지원은 좁지만 유용합니다. SHA-256 다이제스트는 파일 바이트가 기록된 값과 일치한다고 말할 수 있습니다. 하지만 다이제스트는 모델이 안전한지, 정렬 (Aligned)되었는지, 라이선스 (Licensed)를 가졌는지, 유용한지, 또는 올바른 데이터로 학습되었는지는 말할 수 없습니다.

가중치 영수증 (Weight Receipt)

실질적인 결과물은 과도한 주장을 거부하는 영수증 (Receipt)입니다. 전체 JSON 객체 대신, 레지스트리는 영수증을 이름이 지정된 필드를 가진 감사 라인 (Audit line)으로 보여줄 수 있습니다:

영수증 필드 (Receipt field)	예시 값 (Example value)	필드가 존재하는 이유
Type	ai.weight_hash_receipt.v1	이 선언을 모델 카드 (Model card) 또는 벤치마크 (Benchmark)와 분리함
...

이 영수증은 보편적인 표준이 아닙니다. 이 영수증은 정확한 결과물 정체성 (Artifact identity)을 마케팅 라벨 (Marketing labels)과 분리하고자 하는 레지스트리를 위한 방어적인 형태입니다.

정형 영수증 (Canonical Receipt)

영수증(receipt) 자체가 해시(hash)되거나 서명(sign)되는 경우, 그 표현 방식이 중요합니다. RFC 8785가 존재하는 이유는 JSON이 안정적인 해싱(hashing)과 서명(signing)을 수행하기 전에 정형화(canonicalization) 과정이 필요하기 때문입니다.

따라서 레지스트리는 무엇을 해싱할지 결정해야 합니다: 모델 파일인지, 정형 영수증(canonical receipt)인지, 아니면 둘 다인지 말입니다. 이러한 주장(claims)들을 혼용하는 것이 바로 모델 레지스트리가 무엇이 검증되었는지 밝히지 않은 채 "검증됨"이라고 말하기 시작하는 방식입니다.

공급망 패턴 (Supply-Chain Pattern)

소프트웨어 공급망(software supply-chain) 시스템은 이미 대상-및-다이제스트(subject-plus-digest) 패턴을 사용하고 있습니다. SLSA Provenance와 in-toto Statement specification은 출처 증명(provenance statements)에서 대상(subjects)을 이름 및 다이제스트(digests)와 결합합니다.

모델 가중치 레지스트리(Model Weight Registry)는 문제가 해결된 척하지 않으면서도 이러한 관행을 차용할 수 있습니다. 다이제스트(digest)는 아티팩트(artifact)의 정체성을 부여하고, 출처 증명(provenance statement)은 발행자 및 프로세스 맥락을 제공하지만, 둘 중 어느 것도 모델의 동작을 증명하지는 않습니다.

태그 경계 (Tag Boundary)

컨테이너 레지스트리(Container registries)는 포인터(pointer) 문제를 익숙하게 만들어 주었습니다. OCI descriptor는 미디어 타입(media type), 다이제스트(digest), 크기(size)로 콘텐츠를 식별하는 반면, 태그(tags)는 이동할 수 있는 편리한 이름으로 남습니다.

AI 가중치에도 동일한 규율이 필요합니다. "latest", "main", 또는 "production"과 같은 레이블(label)은 운영상의 포인터(operational pointer)입니다. 다이제스트(digest)와 크기(size)가 안정적인 아티팩트(artifact) 정체성의 시작입니다.

리비전 경계 (Revision Boundary)

모델 허브(Model hubs)는 이미 유동적인 이름보다 더 나은 경로를 제공하고 있습니다. Hugging Face Hub download docs는 브랜치(branches), 태그(tags), 커밋 식별자(commit identifiers)를 포함하여 리비전이 고정된(revision-pinned) 다운로드 방식을 설명합니다.

레지스트리는 단순히 저장소 이름(repository name)뿐만 아니라 리비전(revision)을 기록해야 합니다. 리비전과 파일 경로(file path)가 없다면, "우리는 org/model-name을 사용했다"라는 문구는 정체성(identity)이 아니라 단서(clue)에 불과합니다.

콘텐츠 주소 (Content Address)

콘텐츠 주소 지정 (Content addressing)이 도움이 될 수 있지만, 모델 가중치 레지스트리 (Model Weight Registry)가 모든 콘텐츠 주소를 단순히 "파일 해시"로 평탄화(flatten)해서는 안 됩니다. IPFS 콘텐츠 주소 지정 문서는 콘텐츠 유래 식별자 (content-derived identifiers)를 설명하며, CID 구성은 표현 세부 사항 (representation details)에 따라 달라집니다.

그러한 주의 사항은 영수증 (receipt)에 포함되어야 합니다. 레지스트리가 CID 버전, 코덱 (codec), 청킹 (chunking) 또는 가져오기 방법 (import method), 그리고 CID와 파일 다이제스트 (file digest) 사이의 관계를 기록할 때 CID는 유용합니다.

서명된 진술 (Signed Statement)

서명된 영수증은 누가 해당 주장을 했는지 인증할 수 있습니다. EIP-712는 도메인 분리 (domain separation)를 포함한 타입화된 구조화 데이터 서명 (typed structured-data signing)을 지원하며, 이는 불투명한 문자열 (opaque string)보다 레지스트리 영수증에 더 적합합니다.

서명에도 여전히 엄격한 한계가 있습니다. 서명된 거짓 영수증은 여전히 거짓이며, 서명된 바이트 정체성 (byte-identity) 영수증은 안전성, 라이선스 권리, 또는 학습 데이터에 대해 여전히 아무것도 말해주지 않습니다.

형식 경계 (Format Boundary)

모델 가중치는 단순한 이름이 아니기 때문에 파일 형식 (file format)은 영수증의 일부입니다. SafeTensors는 텐서 파일과 메타데이터에 대한 구체적인 형식 컨텍스트 (format context)를 제공합니다.

형식 (format) 필드는 흔히 발생하는 실수, 즉 변환 과정을 기록하지 않고 변환된 아티팩트 (artifact)를 동일한 객체로 취급하는 실수를 방지합니다. 모델이 유사하게 동작하도록 의도되었더라도, 직렬화 (serialization)가 변경되면 바이트 정체성 (byte identity)은 변경됩니다.

경계 테이블 (Boundary Table)

레지스트리는 모든 주장을 각자의 영역에 유지해야 합니다.

필드	말할 수 있는 것	말할 수 없는 것
모델 라벨 (Model label)	사람이 읽을 수 있는 포인터	안정적인 정체성 (Stable identity)
...

이 테이블이 바로 결과물입니다. 모델 가중치 레지스트리는 소비자가 특정 주장이 이름에 관한 것인지, 파일에 관한 것인지, 영수증에 관한 것인지, 아니면 모델의 동작에 관한 것인지를 구분할 수 있을 때 유용해집니다.

최종 영수증 (Final Receipt)

가장 안전한 레지스트리 문장은 짧습니다: "이 영수증은 이 바이트들과 이 한계들을 식별합니다." 그 외의 모든 것은 별도의 증거로 연결되어야 합니다.

이는 온체인 (onchain) AI 주장들을 덜 취약하게 만듭니다. 모델 이름은 포인터 (pointer)일 뿐이며, 가중치 해시 영수증 (weight hash receipt)은 시스템이 실제로 로드한 아티팩트 (artifact)를 둘러싼 검증 가능한 경계입니다.