oMLX는 어떻게 동작하나: 페이징 SSD 캐싱과 아키텍처 내부 구조
oMLX의 고성능 추론 메커니즘은 3가지 핵심 축으로 구성됩니다: 페이징 KV 캐시(Paged KV Cache), 계층형 SSD 오프로딩(SSD Tiered Caching), 그리고 연속 배칭(Continuous Batching)입니다.
1. vLLM 스타일 Paged Block 관리 및 Copy-on-Write
LLM 추론 과정에서 생성되는 Key와 Value의 행렬 값은 동적으로 크기가 커지기 때문에 메모리 파편화를 유발합니다. oMLX는 연속적인 메모리 공간을 요구하는 대신, 가상 메모리 기법처럼 KV 캐시를 고정된 크기의 블록(Block) 단위로 파편화하여 관리합니다. 여러 분기나 대화 흐름이 공통의 이전 프롬프트를 공유하는 경우, 메모리 사본을 복사하지 않고 동일한 블록을 참조하게 만들며, 새로운 수정이 일어날 때만 해당 블록을 복사하는 Copy-on-Write 방식을 채택했습니다.
2. 계층형 KV 캐시 (Hot Memory & Cold SSD Storage)
애플 실리콘 Mac의 통합 메모리 용량은 한정되어 있습니다. oMLX는 메모리 용량 초과 시 오래된 캐시 블록을 삭제하지 않고 NVMe SSD 스토리지로 내보냅니다(Swap-out). 맥북에 탑재된 초고속 NVMe SSD는 초당 수 기가바이트의 읽기/쓰기 속도를 제공하므로, 다시 동일한 프롬프트 맥락이 들어왔을 때 GPU 연산으로 토큰을 재계산하는 것보다 SSD에서 캐시 블록을 읽어오는 것(Swap-in)이 훨씬 빠릅니다. 이 캐시 블록들은 서버가 재시작되어도 디바이스에 유지되는 영속성(Persistent Cache)을 갖습니다.
3. 연속 배칭과 동적 멀티 모델 서빙
mlx-lm을 한 단계 확장하여 여러 사용지 또는 에이전트 도구가 동시 다발적으로 보낸 요청을 한 번의 추론 루프에서 함께 처리하는 연속 배칭(Continuous Batching)을 지원합니다. 또한 메인 LLM 외에 메모리 검색을 위한 임베딩(Embedding) 모델과 리랭커(Reranker) 모델을 동시에 로드하여 필요에 따라 LRU(Least Recently Used) 방식으로 자원을 교체하며 서비스할 수 있습니다.
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
flowchart TD
A["에이전트 요청 수신"] --> B["프롬프트 해시 및 블록 분할"]
B --> C["Paged KV 캐시 테이블 조회"]
C --> D{"RAM Hot Tier에 블록 존재 유무"}
D -- "존재함" --> E["통합 메모리 블록 즉시 참조"]
D -- "없음" --> F{"SSD Cold Tier에 블록 존재 유무"}
F -- "존재함" --> G["NVMe SSD에서 RAM으로 Swap-in"]
F -- "없음" --> H["MLX GPU 커널 프리필 연산 수행"]
E --> I["연속 배칭 추론 루프 탑재"]
G --> I
H --> I
I --> J["스트리밍 응답 토큰 생성 및 반환"]
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
stateDiagram-v2
[*] --> Unallocated : 신규 캐시 블록 요청
Unallocated --> HotRAM : GPU 연산으로 캐시 생성
HotRAM --> ColdSSD : RAM 상주 한계 시 SSD 오프로드
ColdSSD --> HotRAM : 요청 재진입 시 고속 복원
HotRAM --> Eviction : LRU 만료 시 완전히 삭제
ColdSSD --> Eviction : 디스크 용량 초과 시 삭제
Eviction --> [*]
erDiagram
MODEL_ENTITY ||--o{ SESSION_ENTITY :
위 ER 다이어그램은 파일 끝에서 관계 설명이 잘린 조각이므로 실제 oMLX 스키마를 완성해 보여 주는 자료는 아닙니다. 현재 저장소의 설정과 API 문서를 기준으로 모델, 세션 저장 구조를 다시 확인해야 합니다.