# Windows에서 Hugging Face 캐시: 확인, 정리 및 재배치

Hugging Face 다운로드는 여러 모델 리비전, 데이터셋 및 중단된 다운로드로 인해 Windows 드라이브를 가득 채울 수 있습니다. 다운로드를 수행한 환경의 캐시 도구부터 시작하세요. 임의의 `blobs` 폴더를 삭제하면 해당 파일을 여전히 공유하는 리비전이 손상될 수 있으며, `HF_HOME` 전체를 삭제하면 인증 상태도 제거될 수 있습니다.

## 애플리케이션이 실제로 사용하는 캐시 찾기

일반적인 Hub 캐시는 `%USERPROFILE%\.cache\huggingface\hub`이지만, 애플리케이션은 다른 계정, 환경 변수 또는 명시적 캐시 디렉터리를 사용할 수 있습니다. [환경 변수 참조](https://huggingface.co/docs/huggingface_hub/package_reference/environment_variables)는 `HF_HOME`, `HF_HUB_CACHE` 및 `HF_XET_CACHE`를 구분합니다. `HF_HOME`는 모델 캐시보다 광범위하며 저장된 인증 토큰을 포함합니다.

AI 애플리케이션이 사용하는 터미널 또는 Python 환경을 열고 설치된 명령을 확인하세요:

```
hf cache --help
hf cache ls
hf cache ls --revisions
```

이는 인벤토리 명령입니다. `hf` 또는 하위 명령을 사용할 수 없는 경우, 해당 환경의 `huggingface_hub` 버전과 도구가 지원하는 업그레이드 경로를 확인하세요. 무관한 전역 Python 설치를 업그레이드하고 그것이 앱의 전용 환경을 변경한다고 가정하지 마세요.

다른 곳에 구성된 Hub 캐시의 경우 `--cache-dir`와 함께 실제 경로를 전달하세요. 기본 위치의 목록은 더 큰 사용자 지정 위치가 비어 있음을 증명하지 않습니다.

## 총량을 신뢰하기 전에 명령과 경로를 확인하세요

PowerShell에서 다음 검사는 어떤 실행 파일이 호출되는지와 현재 프로세스의 경로 재정의를 보여 줍니다. 인증 토큰은 표시하지 않습니다:

```powershell
Get-Command hf | Select-Object Source
$env:HF_HOME
$env:HF_HUB_CACHE
$env:HF_XET_CACHE
```

빈 줄은 해당 변수가 이 PowerShell 프로세스에 설정되지 않았음을 뜻합니다. 데스크톱 실행기나 가상 환경, 서비스가 재정의를 쓰지 않는다는 증거는 아닙니다. 여러 Python 설치가 있는 경우에는 특히, 다운로드를 수행한 애플리케이션과 이 값들을 비교하세요.

사용자 지정 캐시를 예로 들려면, 목록 확인과 미리보기 모두에 그 명시적 경로를 사용하세요:

```powershell
hf cache ls --cache-dir "D:\AI\huggingface\hub" --revisions
hf cache rm model/OWNER/REPOSITORY --cache-dir "D:\AI\huggingface\hub" --dry-run
```

경로와 저장소 ID는 PC에서 확인한 값으로 바꾸세요. 설치된 명령이 옵션을 거부하면 멈추고 도움말을 읽으세요. 구문 오류를 수동 폴더 삭제로 바꾸지 마세요. 새로 입력한 경로에서 항목이 0개로 나열되는 것도 실제 캐시가 비어 있다는 증거는 아닙니다.

## Windows에서 여러 리비전의 비용이 더 클 수 있는 이유 이해하기

Hugging Face의 [캐시 설명](https://huggingface.co/docs/huggingface_hub/guides/manage-cache)은 공유 블롭과 리비전 스냅샷을 설명합니다. 심링크를 지원하지 않는 Windows에서는 파일이 스냅샷에 직접 저장될 수 있으므로, 동일한 파일이 리비전 전반에 걸쳐 공간을 두 번 이상 차지할 수 있습니다.

개발자 모드는 정책이 허용하는 경우 더 효율적인 심링크 동작을 활성화할 수 있습니다. 심링크 경고를 숨긴다고 해서 심링크가 활성화되거나 이전 다운로드가 소급하여 중복 제거되지는 않습니다. 해당 메시지를 없애기 위해 전체 AI 애플리케이션을 관리자로 실행하지 마세요.

또한 Hub 캐시와 애플리케이션 자체 폴더에 복사된 모델 파일을 구분하세요. 캐시 명령은 PC의 모든 `.safetensors` 또는 GGUF 파일을 목록화하지 않습니다.

## 공유 모델 파일을 두 번 세지 않도록 주의하세요

현재 캐시 문서에 따르면 공유는 리비전 간뿐 아니라, 조건을 충족하는 Xet 다운로드의 경우 저장소 간에도 이루어집니다. 저장소별로 보고되는 크기는 논리적일 수 있는 반면, 캐시 전체의 물리적 크기는 공유 파일을 한 번만 계산합니다. 따라서 모든 저장소 크기를 더하면, 삭제했을 때 회수할 수 있는 양을 과대평가할 수 있습니다.

이는 두 모델 이름이 똑같이 커 보일 때 중요합니다. 다운로드 방식과 파일 시스템에 따라 서로 다른 가중치를 담고 있거나, 파일을 공유하거나, 별도 사본일 수 있습니다. 나열된 기가바이트가 모두 독립적이라고 가정하지 말고 호환되는 캐시 도구가 삭제 계획을 계산하게 하세요.

같은 문서는 오래된 클라이언트가 모두 최신 공유 저장소를 올바르게 관리하지는 않는다고 경고합니다. 삭제에 사용하려는 도구보다 최신 라이브러리가 캐시를 만들었다면, 정리 전에 애플리케이션의 지원 버전을 확인하세요. 기존 환경을 보존하거나 호환되는 유지 관리 도구를 의도적으로 사용하세요. 애플리케이션의 고정된 종속성을 무작정 업데이트하지 마세요.

Hub 캐시는 한 위치일 뿐입니다. Xet 데이터, 데이터셋 처리 출력, 로컬 모델 디렉터리에 명시적으로 다운로드한 파일은 다른 곳에 있을 수 있습니다. Hub 미리보기가 디스크 사용량의 일부만 반영한다면, Hub 삭제를 더 공격적으로 하지 말고 그 밖의 다른 주인을 찾아내세요.

## 알려진 리포지토리 하나의 제거 미리 확인하기

대상 캐시를 사용하는 다운로드, 학습 및 추론을 중지하세요. 더 이상 필요하지 않은 리포지토리를 식별하고, 복구가 중요한 경우 정확한 리비전을 다시 사용할 수 있는지 확인하세요. 게이트 액세스, 업스트림 파일 삭제 및 오프라인 사용으로 인해 명목상 다운로드 가능한 모델을 교체하기 어려울 수 있습니다.

현재 [CLI 가이드](https://huggingface.co/docs/huggingface_hub/guides/cli)는 미리 확인을 지원합니다:

```
hf cache rm model/OWNER/REPOSITORY --dry-run
```

`model/OWNER/REPOSITORY`을 목록의 정확한 ID로 바꾸세요. 영향을 받는 리비전과 크기를 읽으세요. 그 검토 후에만 `--dry-run` 없이 동일한 명령을 실행하고 확인에 응답하세요. 이는 휴지통으로 이동하는 것이 아니라 삭제입니다.

참조되지 않은 캐시 자료의 정리의 경우, 설치된 도구의 계획을 별도로 미리 확인하세요:

```
hf cache prune --dry-run
```

참조되지 않은 리비전이 해당 커밋에 고정된 스크립트에 여전히 필요할 수 있습니다. 정리를 수락하기 전에 해당 프로젝트를 확인하세요. 그 검토를 우회하기 위해 포괄적인 확인 플래그를 사용하지 마세요.

## 정리 계획을 실제 프로젝트와 대조하세요

캐시의 브랜치나 태그 참조는 프로젝트에 필요한 것의 완전한 목록이 아닙니다. 스크립트가 캐시된 브랜치 끝이 아닌 정확한 리비전 해시를 지정할 수도 있습니다. 정리를 승인하기 전에 활성 프로젝트의 설정에서 모델 ID와 고정 리비전을 검색하고, 오프라인 또는 재현 가능한 작업에 필요한 것은 사본을 보관하세요.

현재 CLI 문서에 따르면 정리 동작에는 중단된 `.incomplete` 다운로드도 포함됩니다. 계획을 검토하기 전에 해당 다운로드를 완료하거나 중지하세요. 중단된 다운로드가 남긴 부분 파일은 다른 실행 중인 프로세스가 여전히 쓰고 있는 파일과 다릅니다.

검토한 삭제를 한 번 수행한 뒤 같은 명시적 캐시 경로로 목록을 다시 실행하고 같은 드라이브의 사용 가능 공간을 비교하세요. 그런 다음 작은 대표 작업을 실행하세요. 곧바로 큰 모델을 다시 다운로드한다면 그 작업에는 여전히 삭제된 데이터가 필요하므로, 정리를 반복하는 것은 디스크 사용량을 다운로드 시간과 맞바꿀 뿐입니다.

이동하는 경우, 인증 상태를 의도적으로 옮기는 것이 아니라면 작업에서 인증 상태를 빼두세요. `HF_HOME` 전체를 옮기는 것보다 `HF_HUB_CACHE`만 다른 드라이브로 지정하는 편이 범위가 좁습니다. 변경 전에 이전 값을 기록하고, 해당 앱을 재시작한 뒤 다음 실제 다운로드가 어디에 나타나는지 확인하세요. 앱이 계속 이전 디렉터리를 사용한다면 어느 사본도 지우기 전에 앱의 명시적 캐시 경로를 조사하세요.

## 위치를 혼동하지 않고 향후 다운로드 이동하기

Hub 캐시를 다른 드라이브에 배치하려면, 해당 캐시를 소유한 애플리케이션에 `HF_HUB_CACHE`를 구성한 다음 해당 애플리케이션을 완전히 다시 시작하세요. 라이브러리가 임포트되기 전에 환경 변경이 적용되어 있어야 합니다. 앱별 `cache_dir`가 여전히 다른 곳을 가리킬 수 있으므로, 다음 다운로드의 실제 대상을 확인하세요.

변수를 변경해도 이전 파일이 이동되지는 않습니다. 새 위치가 테스트되고 필요한 로컬 전용 자료가 보존될 때까지 이전 캐시를 유지하세요. 이전 디렉터리가 여전히 크면, 캐시 도구와 해당 경로로 명시적으로 검토하세요.

정리 후, 중요한 워크로드 하나를 테스트하고 동일한 볼륨의 여유 공간을 비교하세요. Ollama의 별도 모델 저장소의 경우 [Ollama 마이그레이션 가이드](/ko/windows/blog/move-ollama-models-windows)를 사용하세요. AI 관련 공유 브랜딩이 도구가 하나의 캐시나 하나의 안전한 삭제 명령을 공유한다는 것을 의미하지는 않습니다.


Canonical: https://mole.fit/ko/windows/blog/huggingface-cache-windows