🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Hugging Face Storage가 SkyPilot의 정식 스토리지 백엔드가 되면서, 팀은 Hub에 둔 모델·데이터셋을 hf://로 마운트하고 어떤 클라우드의 GPU에서도 읽기 egress 비용 없이 학습·개발·서빙 작업을 실행할 수 있게 되었다.

📌 핵심 요약

• 글은 AI 팀들이 모델과 데이터셋은 한 클라우드·한 리전에 두고, 실제로 확보 가능한 GPU는 다른 클라우드나 온프레미스에 있는 상황이 늘면서 cross-cloud 전송 비용이 병목이 된다는 문제에서 출발한다.
• Hugging Face와 SkyPilot은 Hugging Face Hub의 모델·데이터셋·Bucket을 SkyPilot 작업에 hf:// URL과 기존 HF_TOKEN만으로 연결할 수 있게 했고, SkyPilot은 20개 이상의 클라우드, Kubernetes, Slurm, 온프레미스에서 GPU가 있는 곳에 작업을 배치한다.
• Hugging Face Storage는 egress 및 CDN 비용을 부과하지 않기 때문에, 작업이 어느 클러스터에 배치되더라도 같은 Hub 데이터나 Bucket을 읽는 비용이 발생하지 않으며, 클라우드별 데이터 복제 필요성도 줄어든다.
• store: hf는 Hugging Face Bucket은 읽기·쓰기로, 모델·데이터셋·Space repo는 읽기 전용으로 마운트할 수 있고, MOUNT는 hf-mount FUSE와 Xet 기반 lazy read 및 디스크 캐시를 사용해 실제 접근한 바이트만 가져온다.
• 벤치마크에서는 Qwen/Qwen3.5-4B와 HuggingFaceH4/Multilingual-Thinking 데이터셋으로 작은 fine-tune을 수행했으며, 모델 로딩은 약 30초에 가능했고 체크포인트는 클라우드별로 약 112~168MB/s 수준으로 Hugging Face Bucket에 기록되었다.

🧩 주요 포인트

1. 글은 AI 팀들이 모델과 데이터셋은 한 클라우드·한 리전에 두고, 실제로 확보 가능한 GPU는 다른 클라우드나 온프레미스에 있는 상황이 늘면서 cross-cloud 전송 비용이 병목이 된다는 문제에서 출발한다.
2. Hugging Face와 SkyPilot은 Hugging Face Hub의 모델·데이터셋·Bucket을 SkyPilot 작업에 hf:// URL과 기존 HF_TOKEN만으로 연결할 수 있게 했고, SkyPilot은 20개 이상의 클라우드, Kubernetes, Slurm, 온프레미스에서 GPU가 있는 곳에 작업을 배치한다.
3. Hugging Face Storage는 egress 및 CDN 비용을 부과하지 않기 때문에, 작업이 어느 클러스터에 배치되더라도 같은 Hub 데이터나 Bucket을 읽는 비용이 발생하지 않으며, 클라우드별 데이터 복제 필요성도 줄어든다.
4. store: hf는 Hugging Face Bucket은 읽기·쓰기로, 모델·데이터셋·Space repo는 읽기 전용으로 마운트할 수 있고, MOUNT는 hf-mount FUSE와 Xet 기반 lazy read 및 디스크 캐시를 사용해 실제 접근한 바이트만 가져온다.
5. 벤치마크에서는 Qwen/Qwen3.5-4B와 HuggingFaceH4/Multilingual-Thinking 데이터셋으로 작은 fine-tune을 수행했으며, 모델 로딩은 약 30초에 가능했고 체크포인트는 클라우드별로 약 112~168MB/s 수준으로 Hugging Face Bucket에 기록되었다.

🧠 상세 정리

1. 데이터 위치와 GPU 위치가 갈라지는 문제

글의 출발점은 대부분의 팀이 모델과 데이터셋을 특정 클라우드의 특정 리전에 있는 버킷에 저장하지만, 개발·학습·서빙에 필요한 GPU는 점점 다른 클라우드나 다른 인프라에 존재하게 된다는 현실이다. 데이터와 GPU가 같은 위치에 있지 않으면, 팀은 자기 데이터를 자기 GPU에서 읽기 위해서도 cross-cloud 전송 비용을 지불해야 한다. 특히 여러 공급자에 걸쳐 예약 GPU와 온디맨드 GPU를 섞어 쓰는 팀일수록 이 문제가 커진다. 결국 데이터가 있는 클라우드에 작업을 묶어 두거나, 각 클라우드마다 데이터를 복제하거나, 반복적으로 egress 비용을 내는 선택지에 놓이게 된다.

2. Hugging Face Hub와 SkyPilot을 연결한 핵심 제안

Hugging Face와 SkyPilot의 공동 작업은 모델과 데이터셋은 Hugging Face Hub에 그대로 두고, 실제 compute는 GPU가 있는 어느 클러스터에서든 실행하도록 연결하는 데 초점을 둔다. 사용자는 Hugging Face Bucket이나 Hub repo를 SkyPilot 작업에 하나의 hf:// URL로 지정하고, 이미 사용 중인 HF_TOKEN을 전달하면 된다. SkyPilot은 개발, 학습, 서빙 작업을 클라우드, Kubernetes, Slurm, 온프레미스 등에서 가능한 GPU가 있는 곳에 배치한다. 이 구조에서는 데이터를 클라우드별 버킷으로 옮기는 것이 아니라, Hub에 있는 동일한 저장소를 여러 실행 환경에서 읽는 방식이 된다.

3. store: hf와 hf:// 스토리지 백엔드

Hugging Face Storage는 SkyPilot에서 store: hf라는 정식 스토리지 백엔드로 추가되었다. 기존 SkyPilot 작업이 S3, GCS, Azure, R2 같은 객체 저장소를 로컬 경로에 마운트해 사용하던 방식과 유사하게, 이제 hf:// 스킴을 통해 Hugging Face Bucket이나 Hub repo를 연결할 수 있다. Bucket은 체크포인트, 로그, 처리된 데이터 등을 위해 읽기·쓰기로 사용할 수 있고, 모델·데이터셋·Space repo는 읽기 전용으로 마운트된다. 이 하나의 스킴으로 모델과 데이터셋을 읽고, 학습 중 체크포인트를 쓰고, 완성된 모델을 repo에 게시하고, 서빙 시 다시 불러오는 전체 흐름을 포괄한다.

4. MOUNT, COPY, lazy read와 캐시 동작

MOUNT 방식은 Hugging Face의 hf-mount FUSE 백엔드를 사용해 Bucket이나 repo를 로컬 파일 경로처럼 노출한다. 코드가 read()를 호출할 때 Xet 백엔드에서 필요한 바이트만 가져오므로, 실제로 접근한 데이터만 네트워크를 지난다. 또한 hf-mount는 디스크 캐시를 유지해 반복 읽기는 로컬에서 처리되도록 하며, 이 때문에 hf store에서는 MOUNT와 MOUNT_CACHED가 같은 방식으로 캐시를 유지한다. lazy read 덕분에 큰 파일 전체를 먼저 복사할 때까지 기다리지 않고, 다운로드가 진행되는 동안 프로세스가 바로 작업을 시작할 수 있다. 반면 COPY는 huggingface_hub를 통해 실행 전에 데이터를 미리 다운로드하는 방식이다.

5. 인증과 실행 환경의 단순화

인증 방식은 사용자가 이미 가진 Hugging Face 토큰을 그대로 활용한다. 환경 변수에 HF_TOKEN을 설정하고 SkyPilot 실행 시 --secret HF_TOKEN으로 전달하면, SkyPilot은 작업이 어느 클라우드나 클러스터에 배치되든 그 토큰으로 마운트를 수행한다. 글은 하나의 토큰이 AWS, GCP, Azure, Nebius, Lambda 또는 자체 Kubernetes 클러스터에서도 동일하게 작동한다고 설명한다. 따라서 클라우드별 버킷 키나 별도의 저장소 계정을 관리할 필요가 줄어든다. 대부분의 팀이 이미 모델과 데이터셋을 Hub에 보관하고 있다는 점도 강조되며, 이 경우 별도 마이그레이션 없이 기존 저장 위치를 그대로 사용할 수 있다.

6. egress 비용 제거가 실행 위치 선택에 주는 영향

글은 Hugging Face Storage의 핵심 이점을 읽기 egress 비용 제거로 설명한다. 일반 객체 저장소는 클라우드와 리전에 묶여 있기 때문에, 다른 공급자의 데이터센터에 있는 GPU나 inference 서버가 데이터를 읽으면 egress 비용이 발생하거나 클라우드별 복제가 필요하다. 예로 AWS에서 외부로 나가는 데이터에 GB당 약 0.09달러 수준의 비용이 언급되며, 같은 클라우드 내부의 리전 간 이동에도 비용이 붙는 경우가 있다고 설명한다. Hugging Face Storage는 egress와 CDN 비용을 부과하지 않아, 어느 클러스터에서 실행하든 같은 Bucket에서 모델과 데이터셋을 무료로 읽을 수 있다. 다만 글은 쓰기 방향에서는 compute cloud의 일반 egress 비용이 여전히 적용될 수 있다고 구분한다.

7. 벤치마크: 여러 클라우드에서 같은 작업 실행

벤치마크에서는 Qwen/Qwen3.5-4B 모델과 HuggingFaceH4/Multilingual-Thinking 데이터셋을 사용해 TRL의 SFTTrainer로 작은 fine-tune을 수행했다. 모델은 Hub repo에서 읽기 전용으로 마운트했고, 체크포인트는 Hugging Face Bucket에 기록했다. 같은 SkyPilot YAML을 AWS, GCP, Lambda에서 실행했으며, 바뀐 것은 --infra 지정뿐이었다. 모델 로딩은 lazy read 덕분에 from_pretrained가 실제로 접근하는 데이터만 가져와 약 30초 만에 학습 준비가 되었고, 최대 약 500MB/s 수준이 언급된다. 체크포인트는 8.43GB 크기의 weights를 Bucket에 직접 스트리밍했으며, AWS L40S는 약 168MB/s, GCP L4는 약 123MB/s, Lambda H100은 약 112MB/s로 기록되었다.

8. Xet 기반 중복 제거와 협업으로 완성된 구현

Hugging Face Buckets는 Xet 위에 구축되어 있으며, Xet은 파일을 약 64KB 크기의 content-defined chunk로 나누고 고유한 chunk만 저장한다. 이 방식은 체크포인트, 모델 변형, append되는 데이터셋에서 중복 저장과 전송을 줄이는 데 유리하다. 예를 들어 일부 레이어를 고정하거나 adapter만 학습하는 경우 변경된 chunk만 업로드되고, 같은 base model을 공유하는 fine-tune이나 quantization 결과도 겹치는 부분을 한 번만 저장할 수 있다. 글은 8.43GB blob을 다시 업로드했을 때 첫 업로드 24초 대비 재업로드가 약 8초였다고 설명한다. 구현 측면에서는 Nikhil Jha의 기여로 store: hf 지원이 시작되었고, Hugging Face 팀이 unprivileged container에서 동작하도록 hf-mount FUSE 수정사항을 upstream했으며, SkyPilot 팀이 이를 스토리지 백엔드에 연결했다고 정리한다.

🧾 핵심 주장 / 시사점

• 이 통합의 핵심은 단순한 스토리지 추가가 아니라, 데이터 위치가 GPU 스케줄링을 제한하던 구조를 완화해 여러 클라우드의 GPU를 더 유연하게 활용하게 만드는 데 있다.
• AI 워크로드에서는 모델 가중치와 데이터셋을 여러 번 읽는 비용이 큰 비중을 차지하므로, 읽기 egress 제거와 lazy read·캐시 조합은 첫 실행 비용뿐 아니라 반복 학습과 서빙 확장에도 직접적인 영향을 준다.
• Xet 기반 chunk 중복 제거는 체크포인트와 모델 변형이 계속 쌓이는 실제 학습 운영에서 저장량과 재업로드 시간을 줄일 수 있으며, Hugging Face Hub를 중심 저장소로 쓰는 팀일수록 도입 장벽이 낮다.

✅ 액션 아이템

• 모델·데이터셋·Bucket을 Hub에 둔 뒤 GPU가 다른 클러스터일 때도 hf:// 마운트로 일관되게 연결하는 실행 기준을 정한다.
• Hugging Face Storage의 egress·CDN 무료 주장을 cross-cloud 워크로드에서 재확인해 클라우드별 실제 과금 유무를 점검한다.
• SkyPilot에서 20개 이상 클라우드·Kubernetes·Slurm·온프레미스 모두를 대상으로 bucket 쓰기/레포지터리 읽기 전용 제약을 반영한 저장 정책을 정하고 checkpoint 성능(112~168MB/s)을 비교한다.

❓ 열린 질문

• hf:// 중심 구조에서 GPU 수요가 커질 때 기존 모델·데이터 중복 복제 없이 cross-cloud 지연을 억제할 수 있는 경계는 어디인가?
• hf-mount FUSE와 Xet lazy read가 실제 접근 바이트를 줄인다는 전제가 전체 모델 로딩(약 30초) 성능에서 언제까지 유지되는가?
• 현재 작업 패턴에서 bucket 쓰기 구간 병목은 어떤 구성요소에 집중되며, 112~168MB/s보다 낮아지는 구간이 존재하는가?