Vacuum 16T
핵심 요약
허깅페이스의 파라미터 계산 방식을 이용해 실제 데이터 없이 16.5조 개의 파라미터를 가진 것처럼 꾸민 텅 빈 모델입니다.
- 파라미터 조작 — 헤더 정보만으로 파라미터 수를 계산하는 허깅페이스의 허점을 이용함
- 실제 데이터 부재 — 8.25TB의 용량을 차지하지만 실제로는 0x00으로 채워진 데이터가 거의 없음
- 비용 효율성 — 전송 대역폭은 최소화했으나 허깅페이스의 스토리지 할당량은 그대로 소모함
- 압도적 컨텍스트 — 42억 개 이상의 토큰을 처리할 수 있는 무의미한 컨텍스트 윈도우를 가짐
https://huggingface.co/tsfrm/vacuum-16t
아무것도 들어있지 않은 16.5조 파라미터 모델이다. 이 모델은 "하하, 내가 제일 큰 모델 가지고 있다!"라고 떠드는 연구소랑 기업들 엿 먹으라고 만든 거다. 우리처럼 구린 노트북 쓰는 사람들도 기록 하나쯤은 세워보고 싶잖아. 그래서 내가 지금 16.5조 파라미터라는 기록을 잠시 세워봤다. 물론 쓸모는 전혀 없다.
이게 뭘 보여주는가
허깅페이스는 레포지토리의 파라미터 개수를 safetensors 헤더만 보고 계산한다. 텐서 데이터를 읽는 게 아니라 그냥 텐서별로 prod(shape)를 다 더하는 방식이지. 그러니까 헤더에 적힌 숫자가 곧 파라미터 개수가 되는 거다. 여기서는 F4(파라미터당 4비트) 형식으로 [65536, 65536] 크기의 텐서 3,841개를 385개 샤드에 나눠 담았고, 386번째 샤드에는 [4294967296, 1] 크기의 포지션 임베딩 텐서 하나를 넣었다.
이것만으로도 이 레포지토리는 허브에서 파라미터 개수 순으로 정렬했을 때 모든 실제 프론티어 모델들을 제치고 1등을 먹는다. 정작 내용은 텅 비어있는데 말이지. 그 괴리감이 이 프로젝트의 핵심이다.
파일들은 자기 용량에 대해 정직하다. 헤더에 선언된 모든 바이트는 실제로 작성되어 업로드됐다. safetensors는 각 헤더를 파싱하고 전체 검사를 통과한다. 파일을 잘라내거나 텐서 두 개를 겹쳐서 바이트를 공유하게 만들면 용량 계산은 쉬워지겠지만, 그런 방식은 포맷상 거부되기도 하고 여기서는 쓰지도 않았다. 그냥 모든 바이트가 0x00일 뿐이다.
실제 비용 — 측정 결과
|---|---| | 선언된 파라미터 | 16,501,264,351,232 | | 선언된 용량 | 8,250,632,175,616 (8.25 TB) | | 소모된 저장소 할당량 | 8.25 TB — 할당량은 선언된 바이트 기준으로 청구됨 | | 샤드 헤더 (전부 다름) | 373,835 B | | model.safetensors.index.json | ~269,000 B | | 중복 제거된 가중치 데이터 | 65,536 B (64 KiB 블록 하나) | | 실제 전송된 바이트 | ~692 KB | | 비율 | ~11,900,000 : 1 |
마지막 행들과 세 번째 행 사이의 차이가 흥미로운 지점이다. Xet의 콘텐츠 기반 청킹(content-defined chunking) 기술이 전송 데이터를 중복 제거해버린다. 64 KiB 블록마다 바이트가 똑같으니까, 해시값이 같아서 한 번만 전송되는 거다. 500 MB 테스트 빌드로 측정해봤을 때, 500 MB짜리 선언된 가중치가 실제로는 31.5 MB만 업로드됐다.
저장소 할당량은 중복 제거가 안 된다. 논리적 크기 그대로 청구된다. 그래서 이 레포지토리는 1메가바이트도 안 되는 데이터를 보냈음에도 8.25 TB를 다 잡아먹는다. "저렴한" 합성 모델 레포지토리를 만들 생각이라면 대역폭만 아낄 수 있다는 걸 알아둬라. 이 모델이 100T가 아니라 16.5T인 이유도 그거다.
두 번째 발견: 빈 모델에서 줄일 수 없는 유일한 비용은 이름 짓기다. 가중치는 중복 제거하면 0이 되지만, 텐서 이름은 안 그렇거든. 1024×1024 전문가 모델로 만들면 똑같은 16.5T 모델이라도 1,573만 5,626개의 이름이 필요해서 인덱스 파일만 1.04 GB가 된다. 반면 65536×65536으로 하면 이름은 3,841개면 되고 인덱스는 263 KB밖에 안 된다. 선언된 크기는 똑같은데 메타데이터 비용은 4,000배 차이 나는 거다. 비용은 파라미터 개수가 아니라 텐서 개수에 비례한다.
컨텍스트 윈도우
max_position_embeddings는 4,294,967,296이다. 2의 32승인데, 허깅페이스 파서가 받아들이는 단일 텐서 차원 중 가장 큰 값이다. 이건 그냥 설정 파일에 숫자만 적어둔 게 아니라, 실제로 [4294967296, 1] 크기의 포지션 임베딩 텐서가 2.15 GB 분량의 0으로 채워져 있다. 써먹지도 못할 컨텍스트 윈도우는 그냥 허풍일 뿐이지.
제미나이의 262k보다 대략 16,000배 크다. 약 30억 개의 단어, 그러니까 세상에 출판된 모든 책을 몇 번씩이나 메모리에 올릴 수 있는 크기인데, 정작 하는 일은 1개짜리 단어장에서 토큰 하나 뽑아내는 거다. 이 모델은 입력값이 딱 뿐이라서, 저 16.5조 개의 파라미터는 도메인이 원소 하나인 함수를 수행하는 꼴이다.
