▲

Hypura – 애플 실리콘용 저장 계층 인식 LLM 추론 스케줄러

 (github.com/t8)
2P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • GPU·RAM·NVMe 간 텐서 배치를 최적화해 대형 언어 모델을 실행하는 저장 계층 인식형 추론 스케줄러
  • 32GB 맥 미니에서 Mixtral 8x7B(31GB) 모델을 2.2 tok/s, Llama 70B(40GB) 모델을 0.3 tok/s 속도로 실행 가능
  • 접근 패턴과 하드웨어 대역폭을 분석해 물리 메모리를 초과하는 모델도 안정적으로 구동, 기존 llama.cpp가 OOM으로 실패하던 모델까지 처리 가능
  • MoE 구조의 전문가 라우팅, 뉴런 캐시, 프리패치를 통해 I/O를 최대 75% 절감하고 캐시 적중률 99.5% 달성
  • 모델 크기와 하드웨어에 따라 Full-resident, Expert-streaming, Dense FFN-streaming 모드를 자동 선택해 최적 성능 유지
  • Ollama 호환 HTTP API를 제공해 OpenClaw 등과 연동 가능하며, SSD는 읽기 전용으로 사용해 수명 저하 없이 NVMe 기반 추론을 지원

개요

  • Hypura는 Apple Silicon 환경에서 저장 계층 인식형 LLM 추론 스케줄러로, GPU·RAM·NVMe 간 텐서 배치 최적화를 수행하는 도구
  • 접근 패턴, 대역폭 비용, 하드웨어 성능을 기반으로 텐서를 분산 배치해 물리 메모리를 초과하는 대형 모델도 안정적으로 실행 가능
  • 32GB Mac Mini에서 Mixtral 8x7B(31GB) 모델을 2.2 tok/s, Llama 70B(40GB) 모델을 0.3 tok/s 속도로 실행 가능
  • 동일 환경에서 llama.cpp는 OOM(Out of Memory)으로 실행 불가

문제 배경

  • 소비자용 Mac은 빠른 통합 메모리와 NVMe 저장장치를 갖지만, 메모리 용량이 제한적
  • 예를 들어 32GB M1 Max는 40GB 모델을 직접 로드할 수 없어 스왑 과다 및 OOM 종료 발생
  • Hypura는 모델 구조를 분석해 계층별로 최적 배치를 수행함으로써 이 문제를 해결

모델 구조 기반 계층 배치

  • Norms 및 Embeddings: 작지만 매 토큰마다 접근되므로 GPU에 고정
  • MoE Expert Routing: 희소성 활용, 토큰당 8개 중 2개 전문가만 활성화
    • 라우터 인터셉션으로 활성 전문가를 식별 후 필요한 부분만 NVMe에서 로드
    • I/O 75% 감소, 뉴런 캐시 99.5% 적중률 확보
    • 공동 활성화 추적(co-activation tracking) 으로 다음 활성 전문가를 예측해 사전 프리패치 수행
  • Dense FFN Weights: 모델 크기의 약 60% 차지
    • NVMe에서 동적 풀 버퍼를 통해 스트리밍
    • 프리패치 깊이(prefetch lookahead depth) 는 사용 가능한 메모리에 따라 자동 조정
  • 결과적으로 기존 mmap 방식으로는 크래시하던 모델도 실행 가능하며, 메모리에 맞는 모델은 Metal GPU 속도로 오버헤드 없이 동작

작동 방식

  • Hypura는 GGUF 파일을 읽고, GPU·RAM·NVMe 대역폭을 프로파일링
  • 각 텐서를 다음 세 계층 중 하나에 배치
    • GPU(Metal): Attention, Norm, Embedding 계층
    • RAM: GPU에 적재 불가한 오버플로 계층
    • NVMe: 나머지 계층, F_NOCACHE + pread로 직접 I/O 수행
  • 모델 크기와 하드웨어에 따라 자동으로 추론 모드 선택
    • Full-resident: GPU+RAM에 모델 전체 적재, NVMe I/O 없음
    • Expert-streaming: MoE 모델용, 비전문가 텐서만 GPU에 상주, 전문가 텐서는 NVMe 스트리밍
    • Dense FFN-streaming: 비-MoE 대형 모델용, Attention+Norm은 GPU에, FFN은 NVMe 스트리밍
  • 풀 버퍼 크기, 프리패치 깊이, 메모리 예산은 하드웨어 프로파일에 따라 자동 계산

성능

  • 테스트 환경: M1 Max, 32GB 통합 메모리, NVMe 5.1GB/s
  • 주요 벤치마크 결과
    • Qwen 2.5 14B Q4_K_M (8.4GB): GPU 완전 적재, 21 tok/s
    • Mixtral 8x7B Q5_K_M (30.9GB): Expert-streaming 모드, 2.2 tok/s, 99.5% 캐시 적중률
    • Llama 3.3 70B Q4_K_M (39.6GB): Dense FFN-streaming 모드, 0.3 tok/s, 24슬롯 풀, 7계층 프리패치
  • 메모리에 맞는 모델은 오버헤드 0, 초과 모델은 Hypura 덕분에 실행 가능 상태 유지

설치 및 실행

  • Rust 1.75+ 및 CMake 필요
  • 설치 절차 
    git clone --recurse-submodules https://github.com/hypura/hypura.git  
cd hypura  
cargo build --release
  • 실행 예시 
    hypura profile  
hypura run ./model.gguf --prompt "Hello, world"  
hypura run ./model.gguf --interactive  
hypura bench ./model.gguf  
hypura inspect ./model.gguf
  • 미검증 모델은 --max-tokens 10으로 테스트 권장

Ollama 호환 서버

  • Hypura는 Ollama 호환 HTTP API를 제공해 OpenClaw 등 Ollama 기반 도구와 완전 호환 
    hypura serve ./model.gguf  

Endpoint: http://127.0.0.1:8080  

API: /api/generate, /api/chat, /api/tags
  • 주요 엔드포인트
    Endpoint 기능
    GET / 상태 확인
    GET /api/tags 로드된 모델 목록
    GET /api/version 서버 버전
    POST /api/show 모델 메타데이터
    POST /api/generate 텍스트 생성
    POST /api/chat 대화형 생성
  • OpenClaw 연동은 ~/.openclaw/openclaw.json에서 Ollama base URL을 Hypura로 지정
  • 서버 옵션 
    hypura serve  [OPTIONS]  
--host    기본값 127.0.0.1  
--port    기본값 8080  
--context    기본값 4096

아키텍처

  • Cargo workspace 구조로, 두 개의 crate로 구성
    • hypura: 메인 바이너리 및 라이브러리
    • hypura-sys: llama.cpp FFI 바인딩 (CMake 빌드)
  • 주요 모듈
    모듈 역할
    scheduler/placement.rs GPU/RAM/NVMe 간 텐서 배치 최적화
    compute/inference.rs 추론 엔진 및 서버용 로드/생성 함수
    compute/nvme_backend.rs NVMe 스트리밍, 뉴런 캐시, 평가 콜백
    server/routes.rs Ollama 호환 HTTP 핸들러
    profiler/ 하드웨어 프로파일링
    cli/bench.rs 벤치마크 도구
    model/tensor_role.rs 텐서 역할 분류

FAQ

  • SSD 수명 문제 없음

    • Hypura는 SSD에서 읽기만 수행, 쓰기 없음
    • NVMe I/O는 pread() + F_NOCACHE로 읽기 전용 수행
    • SSD는 콜드 스토리지 역할만 하며, 연산은 RAM/GPU에서 수행
    • 쓰기 발생은 벤치마크 결과 JSON, 통계 파일 등 KB 단위의 미미한 수준

안전 지침

  • 모델이 RAM 한계(–4GB 여유) 초과 시 bench --baseline 차단
  • 미검증 모델은 --max-tokens 10으로 테스트
  • 테스트 모델은 ./test-models/ 디렉터리에 저장

라이선스

  • MIT License

윤리적 고지

  • 저장소의 코드는 작성자가 직접 작성한 것이 아님
  • LLM을 활용한 지시 기반 코드 생성 실험으로 제작
  • NVMe 기반 추론의 활용 가능성을 탐구하기 위한 프로젝트임
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 유지보수자에게 제안하고 싶음. 현재 비교표에는 Qwen 2.5 14B, Mixtral 8x7B, Llama 3.3 70B 같은 오래된 모델이 포함되어 있음
    최근에는 Apple 하드웨어에서 Qwen 3.5 MoE 모델이 놀라운 성능을 보인다는 보고가 많음
    Simon Willison의 글을 참고하면 좋겠음
    가능하다면 Kimi K2.5 (1T 파라미터) 모델도 표에 추가되면 좋겠음
    관련 트윗: seikixtc, danpacary

    • 공유해줘서 고마움. 혹시 Hypura로 직접 벤치마크를 돌릴 의향이 있다면 결과를 통계에 병합하겠음. 아니면 내 todo 리스트에 추가해두겠음
    • Simon, 약간 다른 얘기지만 당신의 사이트가 잠시 다운되어 있었음
      Heroku 관련 오류 메시지가 떴는데, 지금은 다시 정상 작동함
      이 글을 보려고 들어갔는데, litellm 관련 글도 이미 작성하셨더군요. 잘 읽었음
    • Kimi 예시에서 토큰 속도(metric) 가 빠져 있는 점이 아쉬움

  • 로컬 작업에서는 초당 1토큰 미만 속도라도 백그라운드 작업이라면 충분히 쓸 만함
    “즉시 종료”와 “하룻밤에 완료”의 차이는 여전히 의미 있는 성능 도약임

  • 실제로는 읽기 패턴이 얼마나 순차적(sequential) 인지가 중요함
    NVMe는 순차 읽기 시 5–7GB/s지만, 랜덤 읽기에서는 500MB/s 수준으로 떨어짐
    1T 모델의 경우 fp16 기준으로 한 번의 forward pass에 2TB를 스트리밍해야 하므로, 이론상 토큰당 300초 이상 걸림
    상호작용용으로는 부적합하지만 배치 추론(batch inference) 에는 가능성이 있음

    • M1 Max에서 4K 랜덤 읽기(QD=1)는 약 65MB/s 수준임
    • 동의함. 이건 실용보다는 POC(Proof of Concept) 에 가까움
      하지만 작은 MoE 모델에서는 초당 여러 토큰을 생성할 수 있어 실제로 쓸 만함
    • MoE 모델의 핵심은 희소 활성화(sparse activation) 임
      모든 2TB를 읽는 게 아니라 일부 전문가 레이어만 접근함
      각 레이어가 수 MiB 단위라 NVMe 접근 효율도 나쁘지 않음

  • “1T 파라미터 모델”이 어디서 나온 건지 궁금했음. 리포에는 70B 이하 모델만 보임

    • 가능성 차원에서 언급한 것임. 하지만 성능이 너무 느려서 특수한 장기 작업 외에는 실용적이지 않음
      현실적인 모델은 작지만 초당 여러 토큰을 생성할 수 있는 MoE 계열임
    • 제목이 과장된 감이 있음. 결국 중요한 건 속도인데, 그 부분에 대한 정보가 없음

  • MoE의 포인트는 희소 활성화로 인해 2TB 전체를 읽지 않는다는 것임
    하지만 접근 패턴이 랜덤화되어 NVMe에는 최악의 조건이 됨
    에이전트 추론처럼 지연시간(latency) 이 중요한 작업에서는 이 부분이 핵심임

  • Intel Optane이 무덤에서 뒤척일 듯한 상황임

    • Memristor도 10년 전엔 곧 상용화될 것처럼 보였는데, 지금은 완전히 사라졌음
    • 아직 새 Optane 4개를 보관 중임. 농담이지만 진짜 있음
      다만 실제로는 NVMe보다 빠르지 않음. 병렬 읽기/쓰기를 지원하는 소프트웨어에서는 차이가 거의 없음
    • Intel이 좋은 걸 만들다 중간에 포기하는 건 이제 익숙함
      그래도 RAID 0으로 4개 묶으면 PCIe 16x 대역폭을 꽉 채울 수 있을 듯
    • pmem 언급

  • 소비자용 Mac 하드웨어는 빠른 통합 메모리와 NVMe를 갖췄지만 용량이 제한적임
    32GB M1 Max로 40GB 모델을 로드하면 스왑이 폭주하고 결국 panic 상태가 됨
    macOS에는 Linux식 OOM killer가 없고, 단순히 swap 공간이 부족해질 뿐임

  • “메모리를 최대한 많이” 확보하는 것도 중요하지만, 대역폭(bandwidth) 이 더 큰 변수임
    M4 Pro는 273GB/s, M4 Max는 546GB/s, M4 Ultra는 819GB/s
    모델이 메모리에 들어간 뒤에는 대역폭이 토큰 속도를 결정함
    Hypura 기준으로는 M4 Max가 sweet spot임. 64GB로 70B 모델(Q4)을 여유 있게 돌릴 수 있고, Pro 대비 2배 속도로 생성 가능함

  • 이 프로젝트는 사실상 스마트 스왑 메모리처럼 작동함
    NVMe를 과도하게 쓰지 않도록 조절하는 점이 흥미로움
    다만 실제로 NVMe에 부하가 많이 걸리면 수명 단축이 우려됨

    • “NVMe에 부하를 준다”는 표현이 낯설음
      SSD는 쓰기 횟수에 따라 셀 수명이 줄긴 하지만, 읽기 부하로 컨트롤러가 손상되는 일은 거의 없음
      만약 그렇다면 시스템에 다른 문제가 있는 것임

  • 이 프로젝트를 이전 실험들, 또 다른 시도와 비교하면 좋겠음
    이번 것은 mmap 기반이라 오버헤드가 크다는 보고가 있었음

    • 해당 코드는 LLM이 작성한 것이라 신뢰성은 낮음
    • 게다가 이번 구현은 강한 양자화(quantization) 를 사용하지 않아 품질 저하가 적음
답변달기