무슨 일이 있었나
로컬에서 LLM 돌려보신 분들이라면 '이 모델 좋다던데 내 컴퓨터 메모리로는 안 올라가네' 하고 포기해본 적 있으실 거예요. Janas는 바로 이 문제를 겨냥한 오픈소스 프로젝트예요. 모델의 '전문가(expert)'를 필요할 때마다 SSD에서 읽어오는 방식으로, RAM보다 큰 LLM을 실행할 수 있게 하겠다는 거죠. 이게 왜 가능한지 이해하려면 먼저 MoE 구조부터 알아야 해요.
MoE가 뭐냐면
일반적인 LLM(Dense 모델)은 토큰 하나를 만들 때 모든 파라미터를 다 써요. 반면 MoE(Mixture of Experts)는 모델 안에 '전문가'라는 작은 신경망을 여러 개 두고, 라우터가 토큰마다 그중 몇 개만 골라서 일을 시켜요. 직원이 수백 명인 회사에서 질문이 들어올 때마다 담당자 몇 명만 불러서 처리하는 것과 비슷해요.
숫자로 보면 더 와닿아요. DeepSeek-V3는 전체 671B 파라미터 중 토큰당 약 37B만 쓰고, Qwen3-235B-A22B는 235B 중 22B, gpt-oss-120b는 약 117B 중 약 5B만 활성화돼요. 전체 덩치는 거대하지만 매 순간 실제로 일하는 건 일부라는 거죠.
문제는 다음에 어떤 전문가가 뽑힐지 미리 모른다는 거예요. 그래서 보통은 전부 메모리에 올려둬요. 235B 모델을 4비트로 양자화해도 120GB 안팎이라, RAM 32~64GB인 일반 PC에선 꿈도 못 꾸죠.
핵심 아이디어: 자주 쓰는 건 RAM, 나머지는 SSD
발상은 단순해요. 매번 쓰는 부분(어텐션, 임베딩 등)은 RAM에 두고, 전문가 가중치는 SSD에 둔 채 라우터가 고르면 그때 읽어오는 거예요. 이런 '전문가 오프로딩' 계열 프로젝트들은 보통 다음 기법들을 조합해요.
- 캐시: 자주 불리는 전문가는 RAM에 남겨둬요. 연속된 토큰은 비슷한 전문가를 다시 쓰는 경향(지역성)이 있어서 효과가 커요.
- 프리페치: 다음 레이어에서 쓸 전문가를 미리 예측해 읽기 시작해서, 계산과 디스크 읽기를 겹쳐요.
- 양자화: 가중치를 작게 만들어 읽어야 할 바이트 자체를 줄여요.
- I/O 최적화: NVMe SSD는 여러 요청을 동시에 던질 때 제 성능이 나와서 병렬 읽기가 중요해요.
현실적인 속도는?
기대치를 맞추는 게 중요해요. DDR5 듀얼채널 PC의 메모리 대역폭은 대략 60~100GB/s, 애플 M 시리즈는 수백 GB/s인데, NVMe SSD는 PCIe 4.0 기준 약 7GB/s, 5.0이라도 14GB/s 정도예요. 10배 이상 차이가 나죠.
간단히 계산해볼게요. 토큰 하나 만들 때 캐시에 없어서 새로 읽어야 하는 전문가 가중치가 2GB라면, 7GB/s SSD에선 읽기만 약 0.3초예요. 초당 3토큰 남짓이죠. 결국 캐시 적중률이 성능을 좌우해요. 그래서 이 방식의 가치는 '빠른 채팅'보다 '느려도 큰 모델을 돌려볼 수 있다'에 있어요. SSD 수명이 걱정되실 수도 있는데, 수명을 깎는 건 주로 쓰기라서 읽기 위주인 이 방식은 크게 걱정 안 하셔도 돼요.
업계 맥락: 메모리 계층을 하나로 쓰려는 흐름
사실 llama.cpp도 mmap(파일을 메모리처럼 매핑하는 기능) 덕분에 RAM보다 큰 모델을 '돌리는 것 자체'는 가능해요. 하지만 운영체제는 MoE 구조를 모르니까 페이지를 비효율적으로 내쫓고 다시 읽으면서 성능이 크게 떨어지기 쉬워요. 전문가 단위로 똑똑하게 관리하는 전용 시스템이 필요한 이유죠.
비슷한 시도도 꽤 있어요. 애플의 'LLM in a Flash'(2023) 논문은 플래시 저장소에서 필요한 부분만 불러오는 기법을 제안했고, Mixtral 오프로딩 연구는 GPU 메모리에 LRU 전문가 캐시를 두는 방식을 보여줬어요. PowerInfer는 자주 쓰는 뉴런은 GPU, 드문 뉴런은 CPU에 나눴고, KTransformers는 DeepSeek 같은 거대 MoE를 CPU와 GPU를 섞어 돌려요. Janas는 이 흐름에서 SSD까지 메모리 계층으로 끌어들인 사례라고 볼 수 있어요.
한국 개발자에게 주는 시사점
보안 때문에 외부 API를 못 쓰는 금융·공공·사내망 환경이라면, 비싼 GPU 서버를 들이기 전에 대형 MoE 모델의 품질을 미리 검증(PoC)해보는 용도로 쓸 만해요. 개인 워크스테이션이나 맥북에서 한국어를 잘하는 대형 오픈 모델을 체험해보는 것도 좋고요. 다만 동시 사용자를 받는 실서비스용은 아니라는 점은 기억해두세요.
공부 측면에서도 가치가 커요. 캐시 정책, 비동기 I/O, 메모리 계층 설계는 DB의 버퍼 풀이 디스크 페이지를 관리하는 원리와 똑같거든요. 백엔드 개발자에게 이런 코드는 훌륭한 시스템 프로그래밍 교재예요.
마무리
한 줄 정리: MoE의 '희소성' 덕분에 SSD도 LLM의 메모리가 될 수 있어요. 속도를 내주고 크기를 얻는 거래죠.
여러분은 초당 몇 토큰까지면 참고 쓸 수 있으세요? 작은 모델을 빠르게 쓰는 것과 큰 모델을 느리게 쓰는 것, 어느 쪽이 더 쓸모 있다고 보시나요?
🔗 출처: Hacker News