아카이브 작업에 브라우저보다 CLI가 나은 이유
브라우저 다운로드는 클릭 한 번과 기도야: 세션 너머의 인증 문맥 없음, 패턴 제어 없음(페이지가 주는 걸 받는 거지), 이성적으로 다룰 수 있는 재시도 의미론 없음, 목적지는 Downloads 폴더. 기가바이트로 재고 검증할 계획인 수집물에는 허브의 API를 고유하게 말하는 도구가 필요해: 공식 CLI — hf(새로운 명령. 오래된 자료는 huggingface-cli라고 해) — revision과 이어받기와 레이트 리밋과 파일 패턴을 이해하지.
수집에 중요한 명령들:
- 스냅샷 전체 받기:
hf download <org/model>— 리포지토리의 현재 상태, 파일 전부, 로컬 캐시로, 끝에 경로를 출력. - revision 고정:
hf download <org/model> --revision <sha>— 정찰 때 기록한 얼어붙은 객체. main이 그동안 뭐가 됐든 무관해. - 패턴 필터:
--include "*.safetensors" --exclude "*.bin"— 선택한 포맷 세대만 받고 pickle 시대 유산은 건너뛰기. - 목적지 선택:
--local-dir <path>— 캐시 대신 아카이브 레이아웃에 곧장 착지. - 필요시 인증: 게이트된 모델엔
hf auth login— 토큰이 브라우저가 아니라 도구와 함께 움직여.
브라우저가 줄 수 없는 것들
세 동작이 조용히 하중을 받아. 이어받기: 중단된 다운로드가 재시작이 아니라 이어져(다음 레슨의 주제). 검증 인식 경로: 캐시 레이아웃이 콘텐츠 주소 방식이라, 이미 전부 있는 재실행은 재다운로드가 아니라 빠른 무동작이야 — 멱등한 수입. 레이트 리밋 정직성: 허브가 조절하면 CLI는 잘린 성공을 serve하는 게 아니라 보고해서, 기다리거나 인증하는 게 정보 있는 결정이 돼.
주의 하나: 캐시는 캐시야. 사용자 데이터가 사는 곳에 살고, 디스크 압박이 닥치면 치워지고, 내부 레이아웃은 도구의 관할이야. 아카이브에는 --local-dir로 네 저장소 레이아웃에 착지시키는 게 소유의 첫 조건과 맞는 목적지야 — 내가 통제하는 저장소 위의 바이트, 아카이브가 의미 있는 방식으로 정렬된.
완전한 수집 호출
정찰에서 조립하면, 완전한 아카이브 다운로드는 이렇게 읽혀: 고정된 revision, 선택된 패턴, 명시적 목적지. 완료 뒤에는: 크기 점검, 포인터 참조와의 다이제스트 점검, 기록. 그 순서(정찰, 수집, 검증, 기록)이 무결성 트랙의 4박자 리듬이고, CLI는 그중 2박자일 뿐이야.