로컬에서 대형 언어모델을 돌리려는 실무자에게 가장 큰 벽은 메모리다. 모델 파일 전체가 RAM에 올라가야 제 속도가 나오는 구조에서는, 가진 메모리보다 큰 모델은 사실상 선택지에서 빠진다. Maurizio 'camauri' Cammalleri가 만든 Janas는 이 전제를 바꾸려는 시도다. C로 작성되고 C 표준 라이브러리 외에 의존성이 없는 이 도구 모음의 첫 구성요소인 Janas-LLM은, 가중치를 디스크에 둔 채 각 토큰이 필요로 하는 전문가(expert)만 NVMe SSD에서 스트리밍하고, 자주 호출되는 전문가는 메모리에 남겨 두는 방식으로 작동한다. 그 결과 48GB 크기의 Qwen3-Next-80B 모델이 32GB RAM 노트북에서 실제로 답변을 생성한다.
제시된 벤치마크 수치
개발자가 공개한 측정값은 구체적이다. Debian 13 리눅스, 인텔 Core Ultra 9 185H와 내장 Arc GPU, 32GB 메모리, NVMe SSD를 갖춘 노트북에서 2026년 10월 9~11일 측정한 결과, Qwen3-Next-80B는 드래프트(초안 예측)를 켠 상태에서 초당 37토큰, 끈 상태에서 24토큰을 생성했다. 같은 모델을 같은 기기에서 돌린 llama.cpp는 2.8토큰에 그쳤다. 프롬프트를 읽는 속도도 62토큰 대 16토큰으로 벌어졌다. Q4_K_M 양자화로 비교한 13개 모델 전부에서 Janas-LLM이 더 빨랐다고 한다. 예외는 3비트 Qwen3-30B 하나로, Q3_K 가중치가 아직 GPU의 빠른 프롬프트 경로로 넘어가지 않아 프롬프트 읽기는 llama.cpp보다 느렸지만 쓰기는 세 배 빨랐다.
이 격차가 벌어진 이유는 llama.cpp 쪽 측정 조건에 드러난다. Qwen3-Next-80B처럼 파일이 노트북의 30GB를 넘는 모델에서 llama.cpp는 GPU가 개입하는 순간 메모리 부족으로 실패했다. CPU 백엔드가 가중치를 재배치하려고 별도 메모리로 복사하고, Vulkan 백엔드도 CPU에 남긴 가중치를 시스템이 회수할 수 없는 버퍼로 복사하기 때문이다. 재배치를 끈 빌드(GGML_CPU_REPACK=OFF)에 --no-host 1 -lm mmap 옵션을 더해 전문가를 파일에 둔 채 페이지 캐시로 읽게 하고서야 읽기 16토큰, CPU 단독 쓰기 2.8토큰이 나왔다. 반면 Janas-LLM은 별도 옵션 없이 자주 쓰는 전문가를 약 19GB 캐시에 두고 나머지를 디스크에서 읽어 같은 모델을 돌렸다.
기기마다 스스로 조정하는 설계
주목할 점은 엔진이 성능 설정을 측정으로 직접 고른다는 것이다. janas-bench는 프롬프트 256토큰과 생성 64토큰을 세 번 돌린 평균을 보고하며, 성능 코어와 효율 코어를 번갈아 시도해 가장 빠른 스레드 구성을 유지하고 이따금 다른 구성도 다시 재 본다. 기기가 달아오르면 판정이 바뀔 수 있기 때문이다. GPU를 끄면(JANAS_GPU=0) Qwen3-4B는 프롬프트 읽기 85토큰, 쓰기 27토큰을 기록했다. 윈도우 11에서도 인텔 자체 드라이버로 리눅스와 비슷한 쓰기 속도가, 밀집 모델에서는 1.8배 빠른 프롬프트 읽기(Qwen3-4B 346 대 193토큰)가 나왔다. 측정 철학 자체가 '다른 기기는 다른 선택을 한다'는 전제 위에 서 있어서, 수치를 그대로 믿기보다 자기 기기에서 janas-bench를 돌려 보라는 권고가 따라붙는다.
드래프트 항목은 맥락에 따라 효용이 크게 갈린다. Qwen3.5·3.6과 Qwen3-Next의 예측 블록, Gemma 4의 보조 모델이 다음 토큰을 추측하고 본 모델이 검증하는 방식인데, 영어 질문에서는 초안이 74~89%(Gemma의 작은 E2B·E4B는 63~72%) 살아남은 반면 이탈리아어 산문에서 Qwen3.5-2B는 약 3분의 1만 유지해 이득이 거의 없었다. 즉 드래프트로 인한 가속은 입력 언어와 텍스트 성격에 민감하며, Qwen3-30B-A3B나 밀집 Qwen3처럼 예측 블록이 없는 모델에는 해당하지 않는다.
실무에서 감안할 한계
이 도구를 실제 워크로드에 넣으려면 몇 가지를 분명히 짚어야 한다. 전문가 캐시는 모델을 열 때 비어 있는 메모리를 가져가므로, 함께 돌아가는 다른 프로그램이 그만큼 몫을 떼어 간다. 브라우저와 편집기를 띄운 상태에서 측정하니 속도는 약 4분의 3을 유지했지만 디스크 대기 시간은 다섯 배로 늘었다. 성능이 급격히 무너지기보다 완만히 저하한다는 점은 장점이지만, 신뢰할 수 있는 수치는 기기를 비워 둔 상태에서만 나온다. 더 중요한 한계는 검증 범위다. 공개된 측정은 사실상 한 대의 노트북, 그것도 AVX-VNNI를 지원하는 인텔 CPU와 내장 GPU, 빠른 NVMe라는 특정 조합에 집중돼 있다. AMD나 구형 CPU, 외장 GPU, 느린 디스크, 메모리가 더 많거나 적은 환경은 아직 시험되지 않았고, 개발자 스스로도 이런 기기의 janas-bench 리포트를 가장 값진 기여로 꼽는다.
Janas는 GPL v3 이상으로 배포되며 모델 서빙용 HTTP API(OpenAI 호환), 편집기 커서 위치에 코드를 채워 주는 janas-server, Claude Code 등 MCP 클라이언트에 모델을 도구로 노출하는 janas-mcp를 함께 제공한다. 정리하면, 메모리에 다 올라가지 않는 MoE 모델을 로컬에서 쓰고 싶은 사람에게 Janas는 실질적인 선택지를 하나 늘려 준다. 다만 지금의 인상적인 수치는 특정 하드웨어 한 대에서 나온 1차 측정이라는 점, 그리고 드래프트 가속과 캐시 효과가 상황에 따라 달라진다는 점을 전제로, 자기 환경에서 직접 재어 보고 판단하는 것이 맞다.