# Hypura – 애플 실리콘용 저장 계층 인식 LLM 추론 스케줄러 > Clean Markdown view of GeekNews topic #27835. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27835](https://news.hada.io/topic?id=27835) - GeekNews Markdown: [https://news.hada.io/topic/27835.md](https://news.hada.io/topic/27835.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-03-25T11:59:10+09:00 - Updated: 2026-03-25T11:59:10+09:00 - Original source: [github.com/t8](https://github.com/t8/hypura) - Points: 3 - Comments: 1 ## Topic Body - **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** 필요 - 설치 절차 ```sh git clone --recurse-submodules https://github.com/hypura/hypura.git cd hypura cargo build --release ``` - 실행 예시 ```sh 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 기반 도구와 완전 호환** ```sh 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 기반 추론의 활용 가능성을 탐구하기 위한 프로젝트임 ## Comments ### Comment 53787 - Author: neo - Created: 2026-03-25T11:59:10+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47504695) - 유지보수자에게 제안하고 싶음. 현재 비교표에는 Qwen 2.5 14B, Mixtral 8x7B, Llama 3.3 70B 같은 **오래된 모델**이 포함되어 있음 최근에는 Apple 하드웨어에서 Qwen 3.5 MoE 모델이 놀라운 성능을 보인다는 보고가 많음 [Simon Willison의 글](https://simonwillison.net/2026/Mar/24/streaming-experts/)을 참고하면 좋겠음 가능하다면 **Kimi K2.5 (1T 파라미터)** 모델도 표에 추가되면 좋겠음 관련 트윗: [seikixtc](https://twitter.com/seikixtc/status/2036246162936910322), [danpacary](https://twitter.com/danpacary/status/2036480556045836603) - 공유해줘서 고마움. 혹시 Hypura로 직접 벤치마크를 돌릴 의향이 있다면 결과를 통계에 병합하겠음. 아니면 내 **todo 리스트**에 추가해두겠음 - Simon, 약간 다른 얘기지만 당신의 사이트가 잠시 **다운**되어 있었음 Heroku 관련 오류 메시지가 떴는데, 지금은 다시 정상 작동함 [이 글](https://simonwillison.net/2026/Mar/19/openai-acquiring-astra...)을 보려고 들어갔는데, 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는 쓰기 횟수에 따라 셀 수명이 줄긴 하지만, **읽기 부하**로 컨트롤러가 손상되는 일은 거의 없음 만약 그렇다면 시스템에 다른 문제가 있는 것임 - 이 프로젝트를 [이전 실험들](https://news.ycombinator.com/item?id=47476422), [또 다른 시도](https://news.ycombinator.com/item?id=47490070)와 비교하면 좋겠음 이번 것은 **mmap 기반**이라 오버헤드가 크다는 보고가 있었음 - 해당 코드는 **LLM이 작성한 것**이라 신뢰성은 낮음 - 게다가 이번 구현은 **강한 양자화(quantization)** 를 사용하지 않아 품질 저하가 적음