Hypura – Apple Silicon용 스토리지 계층 인식 LLM 추론 스케줄러 | AI Paper Digest

TL;DR Highlight

Rust 기반 오픈소스 프로젝트가 LLM을 GPU, RAM, NVMe에 분산 배치하여 Mac 물리 메모리 초과 모델을 실행하고 llama.cpp의 OOM 크래시 문제를 해결한다.

Who Should Read

Apple Silicon Mac(MacBook Pro, Mac Studio, Mac Mini 등)에서 로컬 LLM을 돌리고 싶은데 메모리 부족으로 포기했던 개발자. 특히 32GB 이하 메모리로 70B급 이상 대형 모델을 실험해보고 싶은 ML 엔지니어나 AI 연구자.

Core Mechanics

Hypura는 LLM 추론 시 모델 텐서를 GPU 메모리, RAM, NVMe SSD 세 가지 계층에 나눠서 배치하는 스케줄러다. Apple Silicon의 Unified Memory(통합 메모리) 구조와 빠른 NVMe를 활용해서, 물리 메모리보다 큰 모델도 OS가 강제 종료하지 않고 돌릴 수 있게 한다.
구체적인 성능 수치로는, 32GB Mac Mini에서 31GB짜리 Mixtral 8x7B를 2.2 tok/s로 실행하고, 40GB Llama 70B를 0.3 tok/s로 실행한다. 기존 vanilla llama.cpp는 두 모델 모두 크래시되지만 Hypura는 실행 자체를 가능하게 만든다.
MoE(Mixture of Experts, 여러 전문가 네트워크 중 일부만 활성화하는 모델 구조) 모델의 희소성(sparsity)을 적극 활용한다. 토큰당 8개 expert 중 2개만 실제로 사용되는 특성 덕분에, 라우터를 가로채서 필요한 expert 가중치만 NVMe에서 읽어온다. 이 방식으로 I/O를 75% 줄인다.
뉴런 캐시(neuron cache)를 통해 이미 로드된 expert 슬라이스를 추적하는데, 시간적 지역성(temporal locality, 최근에 사용된 데이터를 다시 사용하는 경향) 덕분에 99.5%의 캐시 히트율을 달성한다. 또한 co-activation tracking으로 다음에 어떤 expert가 활성화될지 예측해서 미리 prefetch한다.
Dense FFN(Feed-Forward Network, 밀집 연결 레이어) 가중치(gate, up, down 레이어로 전체 모델 크기의 약 60%)는 NVMe에서 스트리밍하고, attention 레이어와 norm 레이어는 GPU에 상주시킨다. 가용 메모리에 따라 prefetch lookahead 깊이를 자동으로 조절한다.
Norm과 embedding 레이어는 크기는 작지만 매 토큰마다 접근하는 핫 레이어여서 GPU에 고정(pin)한다. 이렇게 접근 빈도와 레이어 크기를 함께 고려한 배치 전략이 핵심이다.
모델이 물리 메모리에 다 들어가는 경우에는 오버헤드 없이 full Metal GPU 속도로 실행된다. 즉, 메모리가 충분한 환경에서는 성능 손실이 없다.
Rust로 작성되었고 GGUF 파일 포맷을 읽어 하드웨어를 프로파일링한 뒤 계층별 배치를 결정하는 방식으로 동작한다.

Evidence

0.3 tok/s 속도에 대해 '이게 실행(Run)이냐 기어다니는(Crawl) 거냐'는 비판이 있었다. 반면 다른 댓글에서는 '크래시 vs 하룻밤 돌면 완료'의 차이는 실질적으로 의미 있는 능력 차이라고 반박했다. 특히 포그라운드 작업에는 sub-1 tok/s가 무쓸모지만, 백그라운드 배치 작업에서는 충분히 활용 가능하다는 시각이다.
NVMe의 읽기 패턴이 성능의 핵심 병목이라는 기술적 토론이 있었다. 순차 읽기는 5~7 GB/s까지 나오지만, MoE의 랜덤 expert 접근 패턴은 랜덤 읽기(약 500 MB/s)를 유발해서 오히려 최악의 케이스가 된다는 지적이다. 1T 파라미터 모델 기준으로 forward pass당 2TB 가중치를 읽어야 한다면, 피크 순차 속도에서도 토큰당 300초 이상 걸린다는 계산도 나왔다.
NVMe 수명 우려에 대한 댓글도 있었다. 추론 중 NVMe에 지속적인 스트레스를 주는 구조여서 SSD 수명 단축이 걱정된다는 의견이었다. 프로젝트 자체는 'smart swap'처럼 동작해서 불필요한 I/O를 줄이는 게 목적이지만, 실제 장기 사용 시 영향은 미지수라는 반응이다.
유사한 설계의 다른 프로젝트(HN 링크 두 개 공유됨)와 비교가 필요하다는 댓글이 있었다. 특히 해당 프로젝트가 mmap을 사용한다는 점에서, 앞선 실험에서 mmap이 상당한 오버헤드를 유발했다는 결과와 비교 검증이 필요하다는 지적이 나왔다.
커뮤니티에서는 최신 모델(Qwen 3.5 MoE, 스트리밍 expert 방식)이나 Kimi K2.5 1T 파라미터 모델과의 벤치마크 비교를 원하는 목소리가 있었다. 현재 README의 비교 테이블이 Mixtral 8x7B, Llama 3.3 70B 같은 구 모델 위주라는 점도 지적됐다. 또한 llama.cpp mmap 모드와의 직접 비교가 없어서 실제 개선폭을 판단하기 어렵다는 비판적 댓글도 있었다.

How to Apply

32GB Mac에서 30~40GB급 Mixtral 8x7B나 Llama 70B 모델을 로컬에서 실행하고 싶은 경우, llama.cpp로 시도했다가 크래시가 났다면 Hypura를 대안으로 시도해볼 수 있다. 단, 속도가 0.3~2.2 tok/s 수준임을 감안하고 배치 처리나 오버나이트 작업에 적합하다.
MoE 구조 모델(Mixtral 계열, Qwen MoE 계열 등)을 Apple Silicon에서 돌릴 때 Hypura의 expert 스파스 로딩이 가장 효과적이다. Dense 모델보다 MoE 모델에서 I/O 절감 효과(75%)가 크기 때문에, 우선 MoE 모델부터 테스트해보는 게 유리하다.
로컬 LLM 추론 인프라를 직접 만들거나 커스터마이징하는 경우, Hypura의 스토리지 계층 인식 스케줄링 설계(RESEARCH_INTEGRATION_PLAN.md 참고)를 참고해서 자체 시스템에 유사한 접근 빈도 기반 레이어 배치 전략을 적용할 수 있다.

Terminology

MoE (Mixture of Experts)하나의 거대한 모델 대신 여러 '전문가' 서브네트워크를 두고, 입력에 따라 일부만 선택해서 실행하는 모델 구조. 전체 파라미터는 많지만 실제 연산은 일부만 해서 효율적이다.

Unified MemoryApple Silicon에서 CPU, GPU, Neural Engine이 같은 메모리 풀을 공유하는 구조. 별도 GPU VRAM이 없는 대신 빠른 메모리를 함께 쓴다.

GGUFllama.cpp 생태계에서 사용하는 모델 파일 포맷. 양자화(모델 크기 압축) 정보와 모델 아키텍처 메타데이터를 함께 담은 단일 파일 형식이다.

temporal locality최근에 사용된 데이터는 곧 다시 사용될 가능성이 높다는 컴퓨터 과학 원칙. CPU 캐시 설계의 근거이며, Hypura의 99.5% 캐시 히트율의 이론적 근거이기도 하다.

OOM killerLinux에서 메모리가 부족해질 때 OS가 프로세스를 강제 종료시키는 메커니즘. macOS에는 엄밀히 같은 개념이 없고 swap 공간 부족 시 다른 방식으로 처리된다.

forward pass입력 데이터가 모델의 각 레이어를 순서대로 통과하며 출력을 계산하는 과정. LLM에서는 토큰 하나를 생성할 때마다 한 번씩 발생한다.

Hypura – Apple Silicon용 스토리지 계층 인식 LLM 추론 스케줄러