기록관처럼 dtype 읽기

증명이 아닌 주장

리포가 모델이 BF16이라고 해. config가 "torch_dtype": "bfloat16" 이라고 해. 파일명이 bfloat16 이라고 해. 그 어느 것도 그 파일이 메이커의 네이티브 표현을 담고 있다는 증명이 아니야 — 그 파일이 BF16으로 인코딩된 숫자들을 담고 있다는 증명이지. 그건 다른 주장이고, 그 사이의 간극이 수집 실수가 사는 곳이야.

세 종류의 다른 아티팩트가 전부 정직하게 BF16 라벨을 달 수 있어:

네이티브 표현 — 메이커가 실제로 학습하거나 내보낸 정밀도. 이 모델의 최고 정보량. 아카이브의 기본 목표.
실제 변환 — FP32 마스터를 릴리스 시점에 BF16으로 내린 것. 정당하지만, 네이티브 형태와 같은 라벨을 단 파생형이야.
패딩 업캐스트 — 손실 많은 원본(양자화 파일, FP8 내보내기)을 16비트 그릇으로 다시 확장한 것. 라벨은 기술적으로 참이고 실제로는 함정이야: 바이트는 자기가 담은 정보보다 더 높은 정밀도를 주장해. 라벨만으로는 안 보여. 정보는 업캐스트 전에 이미 사라졌으니까.

산수가 기록관의 악기다

파라미터당 바이트 점검은 싸고, 잘못된 라벨의 대부분을 잡아. 파라미터 수에 주장된 원소당 바이트를 곱하고 실제 샤드 크기와 비교해:

7B 파라미터를 BF16(2바이트)으로 ≈ 텐서 14 GB. ~28 GB짜리 BF16 주장 리포는 F32 크기야 — 완전 정밀도 마스터(알아두면 좋음)이거나 업캐스트.
같은 7B가 ~7 GB면 Q8 모양이고. ~4 GB면 Q4 모양이야. 텐서 합계가 양자화 크기 발자국인 "BF16" 리포는 남의 라벨을 걸고 있는 거야.

그다음 출처로 뒷받침해 — 다음 트랙에서 읽는 법을 배울 거야: 메이커의 카드가 릴리스 정밀도를 이름 붙이는지? 리포의 커밋 히스토리에 변환 단계가 보이는지? 같은 릴리스의 독립 미러들이 크기에 동의하는지? dtype 주장 + 일관된 산수 + 신뢰할 만한 이야기 = verdict. 어떤 다리가 빠져도 라벨은 evidence로 남아.

dtype 라벨은 evidence지 verdict가 아니다. 라벨은 그릇의 정밀도를 말해. 네가 사는 건 정보의 정밀도야 — 그걸 말할 수 있는 건 산수와 출처뿐이야.

이게 하중을 받는 스킬인 이유

이 퀘스트의 모든 수집 정책(최고 충실도의 권위 있는 표현, 사물마다 한 사본)은 후보 아티팩트들을 충실도로 줄 세울 수 있음에 의존해. 줄 세우기에는 정확히 이게 필요해: 라벨을 주장으로 읽고, 크기 산수로 시험하고, 파일을 그 마스터로 임명하기 전에 출처를 찾는 것. 이 스킬이 먹여 주는 수집 결정이, 아카이브와 잘못 라벨된 파생형 더미의 차이야.

Code

파라미터당 바이트 샌티티 체크·python

def expected_bytes(params: float, dtype: str) -> float:
    per = {"fp32": 4, "fp16": 2, "bf16": 2, "fp8": 1}.get(dtype.lower())
    if per is None:
        raise ValueError(f"unknown dtype {dtype}")
    return params * per

# 후보 리포 주장: 7B 파라미터, BF16, 샤드 합계 X GB
params = 7.0e9
claimed = sum_shard_bytes  # 파일 트리 정찰 호출에서

expect_bf16 = expected_bytes(params, "bf16")
expect_fp32 = expected_bytes(params, "fp32")

ratio = claimed / expect_bf16
if 0.9 <= ratio <= 1.1:
    verdict = "크기가 BF16 주장과 일치"
elif 1.8 <= ratio <= 2.2:
    verdict = "F32 크기: 완전 정밀도 마스터 아니면 업캐스트 — 출처가 결정해"
elif ratio <= 0.6:
    verdict = "양자화 크기: BF16 라벨은 장식"
else:
    verdict = "둘 다 아님: 믿기 전에 조사"
print(f"{claimed/1e9:.1f} GB vs BF16 기대치 {expect_bf16/1e9:.1f} GB -> {verdict}")

Exercise

최소 두 개의 공개 변형이 있는 모델(예: 완전 정밀도 릴리스 + 같은 dtype을 주장하는 더 작은 재릴리스)을 골라. 둘 다 정찰 산수를 돌려: 주장된 dtype의 기대 바이트 대 실제 크기. 각각의 verdict 줄을 적고, 어느 아티팩트를 마스터로 아카이브할지, 그리고 아직 확인이 필요한 출처 사실이 뭔지 말해.

Hint

두 변형의 비율이 크게 다르면, 라벨이 말하는 대로인 건 많아야 하나야. 메이커의 릴리스 노트나 원래 발표가 보통 어느 쪽인지 정해 줘.

증명이 아닌 주장

산수가 기록관의 악기다

이게 하중을 받는 스킬인 이유

Code

External links

Exercise

Progress

댓글 0