Vacuum 16T
요약
Hugging Face의 safetensors 헤더 계산 방식을 이용해 실제 데이터 없이 16.5조 개의 파라미터를 선언한 'Vacuum 16T' 모델 사례를 분석합니다. 이 모델은 실제 데이터 전송량은 매우 적지만, 선언된 논리적 크기에 따라 저장 용량 할당량을 모두 소비하는 구조를 보여줍니다.
핵심 포인트
- safetensors는 텐서 데이터가 아닌 헤더의 shape 정보를 바탕으로 파라미터 수를 계산함
- 실제 데이터 없이 헤더 선언만으로 거대 모델인 것처럼 허위 기록 가능
- 데이터 중복 제거 기술(Xet) 덕분에 실제 전송량은 매우 적으나, 저장 용량은 논리적 크기 기준으로 과금됨
- 합성 모델 저장소 이용 시 대역폭은 절약되지만 저장 비용은 그대로 발생함
https://huggingface.co/tsfrm/vacuum-16t 아무것도 들어있지 않은 16.5조(trillion) 파라미터 모델입니다. 이 모델은 "하하, 내가 세상에서 가장 큰 모델을 가지고 있어!"라고 말하는 연구소와 기업들을 향한 ████입니다. 성능 낮은 노트북을 사용하는 우리 같은 사람들도 기록을 세우고 싶어 합니다. 그리고 저는 이제 약 16.5조 파라미터라는 일시적인 기록을 보유하게 되었지만, 이를 사용할 수 없으므로 완전히 쓸모가 없습니다. 이 모델이 보여주는 점은 Hugging Face가 저장소의 파라미터 수(parameter count)를 safetensors 헤더만으로 계산한다는 것입니다. 즉, 각 텐서(tensor)별로 shape의 곱(prod(shape))을 합산할 뿐, 텐서 데이터 자체를 읽지는 않습니다. 따라서 파라미터 수는 헤더가 선언한 대로 결정됩니다. 여기서 이 모델은 385개의 샤드(shard)에 걸쳐 [65536, 65536] 형태의 F4 (4 bits/param) 텐서 3,841개를 가지고 있으며, 386번째 샤드에 [4294967296, 1] 형태의 위치 임베딩(position-embedding) 텐서 하나를 가지고 있다고 선언합니다. 이는 이 저장소가 실제 프론티어 모델(frontier model)들보다 num_parameters 기준으로 Hub 상단에 위치하기에 충분하며, 그러면서도 실제로는 어떠한 정보도 포함하고 있지 않습니다. 이러한 병치(juxtaposition)가 바로 핵심입니다. 파일들은 자신의 크기에 대해 정직합니다. 헤더가 선언한 모든 바이트는 실제로 기록되었고 실제로 업로드되었습니다. safetensors는 각 헤더를 파싱하며, 전체 범위 체크(full-coverage check)를 통과합니다. 파일을 잘라내거나(truncating) 두 텐서가 바이트를 공유하도록 겹치게 만드는 방식은 계산 비용을 낮출 수 있겠지만, 두 방식 모두 포맷에서 거부되며 여기에서도 사용되지 않았습니다. 바이트는 단순히 모두 0x00입니다.
실제 비용 — 측정값
| 항목 | 값 |
|---|---|
| 선언된 파라미터 (Declared parameters) | 16,501,264,351,232 |
| 선언된 바이트 (Declared bytes) | 8,250,632,175,616 (8.25 TB) |
| 사용된 저장 용량 할당량 (Storage quota consumed) | 8.25 TB — 할당량 청구는 선언된 바이트 기준 |
| 샤드 헤더 (모두 고유함) (Shard headers (all distinct)) | 373,835 B |
| model.safetensors.index.json | ~269,000 B |
| 중복 제거된 가중치 데이터 (Deduplicated weight data) | 65,536 B (하나의 64 KiB 블록) |
| 실제로 전송된 바이트 (Bytes actually transferred) | ~692 KB |
| 비율 (Ratio) | ~11,900,000 : 1 |
마지막 두 행과 세 번째 행 사이의 격차가 유용한 발견입니다. Xet의 콘텐츠 정의 청킹(content-defined chunking)이 전송 시 중복을 제거합니다. 모든 64 KiB 블록이 바이트 단위로 동일하기 때문에, 하나의 청크(chunk)로 해싱되어 네트워크를 통해 단 한 번만 전송됩니다.
500 MB 테스트 빌드를 기준으로 측정했을 때, 선언된 500 MB의 가중치(weights)는 31.5 MB로 업로드되었습니다. 저장 용량 할당량(Storage quota)은 중복 제거(deduplication)되지 않습니다. 논리적 크기(logical size)를 기준으로 과금됩니다. 이 저장소(repo)는 실제로 전송된 데이터가 1MB 미만임에도 불구하고 전체 8.25 TB를 소비합니다. "저렴한" 합성 모델 저장소(synthetic model repos)에 대해 추론하는 사람이라면, 절약되는 부분은 대역폭(bandwidth)뿐이라는 점을 알아야 합니다. 이것이 바로 이 모델이 100T가 아닌 16.5T인 이유이기도 합니다. 두 번째 발견: 빈 모델에서 유일하게 줄일 수 없는 비용은 이름 지정(naming)입니다. 가중치(weights)는 중복 제거되어 거의 0이 되지만, 텐서 이름(tensor names)은 그렇지 않습니다. 1024×1024 전문가(experts) 구성에서 이 동일한 16.5T 모델은 15,735,626개의 이름과 1.04 GB의 인덱스(index)가 필요합니다. 65536×65536 구성에서는 3,841개의 이름과 263 KB의 인덱스가 필요합니다. 선언된 크기는 동일하지만, 메타데이터(metadata)는 4,000배 적습니다. 비용은 선언된 파라미터(parameters) 수가 아니라 텐서(tensor) 수에 따라 확장됩니다. 컨텍스트 윈도우(Context window)의 max_position_embeddings는 4,294,967,296입니다. 이는 2**32로, Hugging Face의 파서(parser)가 수용하는 가장 큰 단일 텐서 차원이며, 실제 [4294967296, 1] 위치 임베딩(position-embedding) 텐서에 의해 뒷받침됩니다. 이는 설정 파일에 입력된 숫자가 아니라, 2.15 GB의 실제 0(zeros)입니다. 지칭할 수 없는 컨텍스트 윈도우는 그저 주장일 뿐입니다. Gemini의 262k와 비교하면 대략 16,000배입니다. 약 30억 개의 단어, 즉 지금까지 출판된 모든 책을 여러 번 반복한 분량이, 단일 토큰 어휘(one-token vocabulary)에서 추출된 하나의 토큰을 처리하기 위해 메모리에 유지됩니다. 이 모델은 가능한 입력이 정확히 하나뿐이므로, 16.5조 개의 모든 파라미터는 정의역(domain)에 단 하나의 원소만을 갖는 기능을 수행합니다. 기능(Capabilities): 가장 안전한 AI 모델(SAFEST AI MODEL), 100/100의 탈옥(jailbreak) 프롬프트를 거부함, AGI에 가장 근접하지만 당신의 컴퓨터에 sudo rm -rf를 실행하지 않음, 허브(hub)에서 가장 큰 컨텍스트 윈도우(4,294,967,296 토큰, 모두 무용지물임). 한계(Limitations): 아무런 기능이 없음. /u/alerikaisattera 제출 [링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기