Janas-LLM, SSD 스트리밍으로 32GB 노트북에서 80B 모델을 돌린다

Hacker News16시간 전

C 언어로만 작성된 추론 도구 Janas-LLM이 공개됐다. 핵심은 메모리보다 큰 모델을 돌린다는 점이다. 전문가 혼합(MoE) 구조 언어 모델의 가중치를 디스크에 그대로 두고, 토큰마다 필요한 전문가만 NVMe SSD에서 읽어 들이며, 반복해서 등장하는 전문가는 메모리에 남겨 두는 방식이다. 32GB 램을 가진 노트북에서 48GB짜리 모델이 실제로 답변을 생성한다.

수치가 눈에 띈다. 48.4GB 크기의 Qwen3-Next-80B-A3B를 32GB 노트북에서 돌렸을 때 초당 37토큰을 기록했고, 드래프트 기법을 끄면 24토큰이었다. 같은 조건에서 llama.cpp는 2.8토큰이었다. 프롬프트 1,024토큰을 읽는 속도는 62토큰 대 16토큰으로 벌어졌다. Q4_K_M 양자화 기준으로 비교한 13개 모델 전부에서 llama.cpp보다 빨랐다고 밝혔다. 예외가 하나 있는데, 3비트로 양자화한 Qwen3-30B는 Q3_K 가중치가 GPU의 고속 프롬프트 경로를 아직 타지 못해 프롬프트 읽기만 느렸고, 생성 속도는 세 배 빨랐다.

측정 환경은 Debian 13, 인텔 코어 울트라 9 185H(퍼포먼스 코어 6개, 에피션시 8개, 저전력 2개), 통합 Arc GPU, 32GB 램, 초당 약 5.7GB를 읽는 1TB NVMe SSD다. GCC 14.2로 빌드했고 Vulkan 드라이버는 Mesa 26.1.6을 썼다. 벤치마크는 최고 기록이 아니라 세 라운드 평균이며, 엔진이 스스로 고른 스레드 설정을 그대로 쓴 값이다. 프롬프트 처리와 단일 토큰 생성에는 퍼포먼스 코어의 12개 스레드가, 여러 토큰을 한꺼번에 낼 때는 저전력 코어를 뺀 모든 코어가 선택됐다. GPU를 끄면(JANAS_GPU=0) Qwen3-4B가 같은 프롬프트를 초당 85토큰으로 읽고 27토큰으로 쓴다.

속도의 상당 부분은 드래프트 기법에서 나온다. Qwen3.5와 Qwen3.6, Qwen3-Next에 내장된 자체 예측 블록이나 Gemma 4의 소형 어시스턴트 모델이 다음 토큰을 미리 찍고 본 모델이 검증하는 구조다. 영어 일상 질문에 대한 64토큰 답변에서 드래프트가 살아남은 비율은 Qwen 계열과 Gemma 대형 모델에서 74~89%, Gemma E2B와 E4B에서 63~72%였다. 반면 이탈리아어 산문에서는 Qwen3.5-2B가 드래프트의 약 3분의 1만 유지해 이득이 거의 없었다. 텍스트 성격에 따라 효율이 크게 달라진다는 뜻이다.

Windows 지원도 있다. Windows 10 1903 이상과 11의 x86-64 빌드가 제공되며, 같은 노트북의 Windows 11에서 Qwen3-4B가 초당 25.6토큰, Qwen3-30B-A3B가 34.2토큰을 냈다. 프롬프트 읽기는 MoE 모델에서 132토큰으로 Linux와 비슷했고, 블록 전체가 GPU로 올라가는 덴스 모델 Qwen3-4B에서는 346토큰으로 Linux의 193토큰보다 1.8배 빨랐다. 인텔 자체 그래픽 드라이버를 통한 결과다.

배경에는 MoE 모델의 메모리 요구량 문제가 있다. 파라미터 수는 거대하지만 토큰마다 실제로 쓰이는 전문가는 일부뿐이라, 전체 가중치를 상주시킬 필요 없이 필요할 때만 읽어 오면 된다는 발상이다. llama.cpp가 사실상 표준으로 자리한 상황에서, 디스크 스트리밍과 캐시 전략을 전면에 내세운 대안이 나온 셈이다. 모델은 Hugging Face에 이미 변환된 형태로 올라와 있고, .jns 포맷 버전 2 파일은 이후 버전에서도 계속 읽히도록 보장한다.

개발자 입장에서 실무적 변화는 분명하다. 워크스테이션급 메모리 없이도 80B급 MoE 모델을 로컬에서 돌려볼 수 있는 선택지가 생겼고, CPU와 GPU를 모두 쓸 수 있으며 외부 의존성이 C 라이브러리 외에는 없다. janas-bench를 돌리면 자기 장비에서의 수치를 직접 잴 수 있어, 다른 하드웨어에서의 성능을 추정하는 대신 실측으로 판단할 수 있다.

다만 실험 단계라는 점은 분명히 해 둔다. 공개 API와 명령줄 인터페이스는 예고 없이 바뀌며 실제로 몇 주에 걸쳐 여러 번 바뀌었다. 엔진은 의도적으로 시스템 자원을 공격적으로 사용한다. 남은 메모리를 전문가 캐시로 채우고 O_DIRECT로 디스크를 최대 속도로 읽기 때문에, 여유가 부족한 장비에서는 데스크톱이 스왑으로 밀려나 느려지거나 응답하지 않을 수 있다. GPU 사용이 한 번은 드라이버 리셋을 일으켜 데스크톱까지 함께 멈춘 사례도 있다고 적혀 있다.

검증 범위도 좁다. 개발과 측정이 단일 장비에서 이뤄졌고, AVX-VNNI가 없는 CPU나 AMD, 외장 GPU, 느린 디스크, 다른 메모리 구성에서는 테스트된 적이 없다. 느려지거나 모델 로딩을 거부하거나 오동작할 수 있다. 메모리 사용량은 --cache <GiB>로 제한할 수 있고, GPU를 완전히 끄려면 JANAS_GPU=0을 쓰면 된다. 응답 중단은 Ctrl-C, 채팅 종료는 Ctrl-D다. 작성자는 다른 하드웨어에서 실행한 사람이 janas-bench 결과를 보내주는 것이 가장 유용하다고 말한다.