My LLM Hoarding Got Out of Hand…So I Built This

🖼️ 인포그래픽

My LLM Hoarding Got Out of Hand…So I Built This 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 결론

LLM Hoarding 문제의 핵심은 모델 자체보다 중복 저장·불투명한 캐시·경로 관리이며, Model Shelf와 외장 NVMe 저장소는 로컬 AI 모델 라이브러리를 정리하는 해법으로 제시된다.

📌 핵심 요점

로컬 LLM, 이미지·비디오 모델, 다양한 quant variant가 내부 SSD를 빠르게 소모하고, 같은 모델이 여러 위치에 중복 저장되는 문제가 출발점이다.
Hugging Face 기본 캐시는 blobs, refs, snapshots 구조 때문에 사람이 모델 위치를 이해하거나 llama.cpp·MLX 같은 런타임에 바로 연결하기 어렵다.
Model Shelf는 드라이브별로 예측 가능한 모델 디렉터리를 만들고, 허브를 기준으로 모델 존재 여부·포맷·quantization을 확인해 다운로드와 경로 관리를 돕는다.
외장 Thunderbolt 5 NVMe 인클로저는 대용량 모델 저장소로 활용할 수 있으며, 내부 SSD보다 느릴 수 있지만 저장 공간 확보와 이동성 측면에서 장점이 있다.
RAID 0은 모델 로딩 대역폭을 높일 수 있는 선택지로 제시되지만, 드라이브 하나가 손상되면 전체 배열이 사라지는 구조라 재다운로드 가능한 모델 파일에 한정해 현실적인 옵션으로 다뤄진다.

🧩 배경과 문제 정의

이 영상의 문제의식은 로컬 LLM, 이미지 모델, 비디오 모델, 여러 quant variant를 계속 내려받다 보면 내부 SSD가 빠르게 차고, 같은 모델 파일이 여러 머신이나 폴더에 중복 저장되는 상황에서 출발한다.
Hugging Face 기본 캐시는 blobs, refs, snapshots처럼 사람이 바로 이해하기 어려운 구조를 만들기 때문에, 특정 모델이 실제로 어디에 있는지 파악하거나 llama.cpp, MLX 같은 런타임에 곧바로 연결하기 어렵다.
발표자는 모델을 단순히 빠른 외장 드라이브에 넣는 것만으로는 충분하지 않다고 본다. 어떤 드라이브에 어떤 모델이 있는지, 이미 내려받은 모델인지, 어떤 포맷과 quantization인지까지 에이전트가 일관되게 찾을 수 있어야 한다.
Model Shelf의 핵심은 Hugging Face Hub를 실시간 기준으로 검색하고, 여러 저장소에 흩어진 모델을 예측 가능한 경로 구조로 관리하며, 중복 다운로드를 피하게 만드는 것이다.
고속 외장 NVMe 인클로저와 Model Shelf를 결합하면 내부 SSD 공간을 아끼면서도 로컬 AI 모델을 빠르게 로드하고, 필요할 때 다른 머신으로 옮길 수 있는 이동식 모델 라이브러리처럼 다룰 수 있다.
검증이 필요한 부분은 실제 외장 드라이브 성능, RAID 0 구성의 체감 이점, 특정 모델 로딩 속도처럼 사용자의 하드웨어와 런타임 환경에 따라 달라질 수 있는 항목이다.

🕒 시간순 섹션별 상세정리

1. 로컬 모델 중복과 지저분한 캐시가 저장 공간 문제를 만든다

발표자는 에이전트에게 정확한 모델명을 완벽히 입력하지 않아도 Qwen 3 4B MLX 3-bit 요청을 해석하고, 이미 로컬 선반에 있는 모델을 찾아 다운로드 없이 위치와 실행 명령을 반환하는 흐름을 보여준다 [00:17]
모델 파일은 Hugging Face 캐시의 blobs나 snapshots 같은 불투명한 위치가 아니라 외장 OWC 드라이브의 MLX 커뮤니티 경로에 정리되어 있어, 파일 이름과 저장 위치를 사람이 바로 이해할 수 있다 [00:30]

2. Model Shelf는 드라이브마다 예측 가능한 모델 디렉터리를 만든다

단순히 빠른 드라이브를 쓰는 것만으로는 모델을 어디에 둘지, 에이전트가 어떻게 찾을지, 다운로드와 추적을 어떻게 관리할지 해결되지 않으며, models 폴더 하나에 기억을 의존하는 방식은 금방 한계에 부딪힌다 [04:37]
GitHub 저장소의 한 줄 설치 명령은 Model Shelf 도구와 에이전트 skill을 함께 설치하고, Claude Code는 설치 직후 별도 교육 없이 shell command 기반으로 이 기능을 사용할 수 있다 [05:04]

3. 에이전트는 훈련 데이터 기억이 아니라 실시간 허브를 기준으로 모델을 찾는다

오래된 훈련 데이터만 믿는 에이전트는 새 모델이 없다고 잘못 판단할 수 있지만, Model Shelf에서는 Hugging Face Hub가 source of truth가 되어 실제 존재 여부를 확인한다 [06:00]
음성 입력에서 Qwen이나 llama.cpp 철자가 틀려도 loose input으로 처리되며, skill은 먼저 hub를 검색해 요청한 포맷과 quantization에 맞는 후보를 찾는다 [06:39]

4. 여러 드라이브를 하나의 모델 라이브러리처럼 쓰면서 외장 로딩 성능을 확인한다

Model Shelf는 내부 드라이브와 외장 드라이브를 함께 사용할 수 있고, 4-bay 구조에서는 각 bay가 독립 볼륨처럼 보이기 때문에 MLX용 드라이브와 GGUF용 드라이브처럼 역할을 나눌 수 있다 [07:31]
사용자는 처음부터 4개 bay를 모두 채울 필요 없이 1~2개 드라이브로 시작한 뒤, 모델 라이브러리가 커질수록 드라이브를 추가하는 방식으로 확장할 수 있다 [07:55]

5. 통합 검색, 깨끗한 경로, 안전한 실패 방식이 모델 관리 부담을 줄인다

세 개 외장 드라이브와 로컬 shelf에 모델을 나눠 넣어도 Model Shelf 목록에는 Qwen 3.5 9B llama.cpp, Gemma 3 4B, Qwen 3 4B 3-bit MLX, Bartowski small LM2가 한 번에 나타난다 [09:38]
에이전트는 모델이 어느 bay에 있는지 신경 쓰지 않고 Model Shelf에서 경로를 받아 사용할 수 있으며, 해당 드라이브를 다른 Mac으로 옮겨도 같은 구조로 계속 작동한다 [09:55]

6. RAID 0 구성으로 모델 저장소의 속도와 위험을 검증한다

RAID 0은 중복성을 제공하지 않고 속도를 높이는 방식이라 드라이브 하나가 손상되면 전체 스트라이프가 사라지지만, 모델 파일은 다시 다운로드할 수 있어 일반적인 중요 데이터보다 손실 위험을 감수하기 쉽다는 관점이 드러난다 [12:06]
70B 파라미터 모델을 VRAM에 올리려면 약 40GB를 스토리지 컨트롤러를 통해 빠르게 이동해야 하므로, 추론 환경에서는 저장장치 대역폭이 체감 성능에 직접 영향을 줄 수 있다는 설명이 계속된다 [12:16]

7. Model Shelf로 외장 RAID 모델 저장소를 연결하고 내부 용량 문제를 해소한다

RAID 배열 생성 후 TB504가 새 저장소로 잡히고, Model Shelf를 초기화해 Gemma 3 4B 모델을 MLX 4-bit quantization 형식으로 가져오면서 Hugging Face Hub 파일 구조가 새 저장소에 구성된다 [13:19]
모델은 외장 TB504에 있어도 사용 가능 상태로 등록되며, 에이전트는 별도 위치 변경을 신경 쓰지 않고 필요한 모델을 찾아 실행할 수 있어 내부 SSD 용량 문제를 줄이는 결론으로 계속된다 [13:40]

🧾 결론

이 영상의 핵심 메시지는 “더 빠른 드라이브”보다 “모델을 어디에 두고, 어떻게 찾고, 어떻게 재사용할 것인가”가 로컬 AI 환경의 실제 병목이라는 점이다.
Model Shelf는 로컬·외장 드라이브에 흩어진 모델을 하나의 라이브러리처럼 다루게 해, 불필요한 재다운로드와 내부 SSD 잠식을 줄이는 방향으로 설계되어 있다.
에이전트가 오래된 기억에 의존하지 않고 Hugging Face Hub를 source of truth로 확인한 뒤, 필요한 포맷과 quantization에 맞는 모델을 찾아 경로와 실행 명령까지 반환하는 흐름이 강조된다.
외장 NVMe 저장소는 내부 SSD보다 절대 속도에서 불리할 수 있지만, 40GB 이상 대형 quant 모델이나 수백 GB급 이미지·비디오 가중치를 다루는 환경에서는 공간 확보의 효용이 크다.
RAID 0은 속도와 용량을 얻는 대신 안정성을 포기하는 방식이므로, 영상에서는 사진·영상 프로젝트 같은 대체 불가능한 데이터가 아니라 다시 받을 수 있는 모델 가중치 저장소에 적합한 선택지로 구분한다.

📈 투자·시사 포인트

로컬 AI 모델 사용이 늘수록 GPU·메모리뿐 아니라 고속 외장 스토리지, NVMe 인클로저, 모델 관리 도구의 중요성이 함께 커질 수 있다.
단순한 저장장치 성능 경쟁보다, 여러 드라이브와 런타임을 연결하는 파일 구조·검색·중복 방지·안전한 실패 방식이 사용자 경험을 좌우하는 요소로 부각된다.
Hugging Face 캐시를 그대로 쓰는 방식과 달리, 사람이 읽을 수 있는 경로와 런타임 친화적 구조를 제공하는 도구는 로컬 AI 워크플로의 운영 부담을 줄이는 방향성을 보여준다.
대형 모델을 자주 바꾸고 여러 quant variant를 실험하는 사용자에게는 내부 SSD 증설보다 외장 모델 라이브러리 구성이 더 유연한 선택지가 될 수 있다.
검증 필요: TB504의 장기 안정성, 실제 RAID 0 지속 성능, Kickstarter 조건, 다양한 운영체제·런타임 조합에서의 호환성은 영상 시연만으로 단정하기 어렵고 별도 확인이 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

영상에 나온 TB504 외장 NVMe 인클로저의 속도 수치와 “각 bay가 자체 80Gbps lane을 가진다”는 설명은 제작자의 환경 기준으로 보이며, 공식 스펙과 독립 벤치마크로 별도 확인이 필요하다.
입력 내용 안에서 TB504 브랜드가 Acasis와 AKiTiO로 혼재되어 보이므로, 실제 제품명·제조사·Kickstarter 링크·early bird 조건은 공식 페이지에서 확인해야 한다.
Model Shelf가 Claude Code, llama.cpp, MLX, safetensors 계열 모델을 어느 범위까지 안정적으로 지원하는지는 영상 데모만으로 일반화하기 어렵다.
자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.