요약
Janas는 32GB 노트북에서 48GB짜리 Qwen3-Next-80B를 초당 37토큰으로 돌립니다.
개발자 마우리치오 캄말레리가 C 언어로만 만든 추론 엔진 Janas-LLM을 공개했습니다. 모델 가중치는 디스크에 둡니다. 그리고 토큰마다 필요한 전문가(MoE 모델에서 일부만 골라 쓰는 하위 신경망)만 NVMe SSD에서 읽어 옵니다.
왜 중요한가
- 메모리가 모자라 llama.cpp로는 초당 2.8토큰에 그친 80B 모델이 초안 없이도 초당 24토큰으로 돌아갑니다.
- 고가 GPU 없이 내장 GPU가 달린 일반 노트북으로도 RAM보다 큰 MoE 모델을 쓸 수 있다는 점을 보여 줍니다.
핵심 내용
- 자주 쓰는 전문가는 메모리 캐시에 남기고, 나머지는 운영체제 캐시를 거치지 않는 직접 읽기로 디스크에서 가져옵니다.
- 추측 디코딩(작은 초안이 다음 토큰을 짐작하고 본 모델이 검증하는 방식)으로 속도를 더 올립니다.
- Q4_K_M 양자화로 비교한 13개 모델 모두에서 llama.cpp보다 빨랐고, 80B 모델의 프롬프트 읽기도 초당 62 대 16토큰이었습니다.
- 시험한 기기는 인텔 Core Ultra 9 185H 노트북 한 대뿐이라 다른 CPU나 외장 GPU, 느린 디스크에서는 확인되지 않았습니다.
- 리눅스와 윈도용 실행 파일을 내놓았고, 코드는 GPL-3.0 라이선스입니다.
HN 반응
- llama.cpp에 이미 있는 기능을 또 만든다는 비판에, 범용 엔진은 기여가 어렵고 특정 모델에 맞추면 최대 2배 빨라진다는 반박이 나왔습니다.
- 하드웨어가 병목이라는 지적과 함께 고대역폭 플래시 개발 소식이 공유됐지만, 지금 SSD는 GPU 메모리보다 100배 느리다는 반론도 있었습니다.
이렇게 엄청난 일이 이제는 거의 상투적인 일이 됐다는 게 놀랍습니다.
나쁜 뜻으로 하는 말이 아닙니다. 오픈 웨이트 AI와 오픈소스 도구는 제가 희망을 걸 수 있는 거의 유일한 것이거든요.
이런 게 수십 개나 있다는 건, 누구나 쓸 수 있는 비독점 AI 도구가 시시할 만큼 당연한 것이 되기 시작했다는 신호입니다. 우리가 모두 살아남으려면 바로 그게 필요합니다.
병목은 하드웨어예요. 이게 풀리면 변화가 훨씬 더 빨라질 거예요.
근거를 댈 수는 없지만, 지금 쓸 수 있는 하드웨어에도 아직 여유가 있는 것 같아요. 지금의 공급 부족 때문에 어쩔 수 없이 그 여유를 점점 더 쥐어짜서 최적화하게 될 테고요. 그러다 병목이 풀리면 달성할 수 있는 상한선이 원래보다 훨씬 더 높아져 있겠죠.
SSD로 전문가(expert)를 스트리밍하는 이런 방식이 이미 쓸 만한 여지는 거의 다 쓰고 있다고 봅니다.
LLM의 소프트웨어나 아키텍처 쪽에는 아직 여유가 있을 수 있지만, 토큰 스트리밍 수준까지 내려가면 사실상 물리 법칙에 부딪히는 것 아닌가요?
특정 GPU 계열에 맞춰 최적화하면 아직 할 수 있는 게 많습니다. 예를 들어 Hipfire[1]와 q38rocm/HaloPFX[2]를 보세요. 소비자용 AMD GPU에서는 llama.cpp보다 훨씬 빠릅니다.
[1] https://github.com/warpfront/hipfire
[2] https://github.com/julianmb/q38rocm
네, 그건 저도 동의합니다. 다만 그런 것들은 이미 감안한 얘기였어요. 몇 주 전에 가상으로 R9700 박스를 구성해 보면서 조사했거든요.
다음 Qwen 시리즈에서 예상되는 아키텍처 변경 중 하나는 SSD 스트리밍과 잘 맞을 것 같습니다.
그리고 스트리밍 기능을 조정하고 더 잘 활용할 여지도 여전히 많을 겁니다. 예를 들어 투기적 스트리밍(speculative streaming)을 개선해서, 활성화될 전문가를 필요한 시점에 이미 RAM에 올려 두는 식으로요.
고대역폭 플래시(High Bandwidth Flash)의 새 표준이 개발 중입니다.
https://www.youtube.com/watch?v=3nTpW52nioI
문제는 소비자가 손에 넣기도 전에 대형 AI 기업들이 전부 쓸어 가지 않겠느냐는 거죠.
전부는 아니어도 가격을 높게 유지할 만큼은 쓸어 가겠죠.
데이터센터가 SSD를 싹쓸이하고 나서야 소비자도 살 만한 가격이 됐던 것과 똑같아요. HDD도 그랬고, 세대마다 RAM도 그랬고요. 처음엔 비싸다가 합리적인 가격이 되고, 다음 세대가 나오면 싸지는 거죠.
데이터센터용 SSD가 소비자용 SSD보다 정말 한참 먼저 보급됐나요?
저는 1세대 SSD는 소비자들을 상대로 시험한 거라고 늘 생각했거든요.
네, 1970년대 후반(1978년)에 StorageTek STC 4305로 시작됐습니다. 큰 캐비닛 크기에 45MB, 가격이 40만 달러였고, 제가 찾아본 바로는 이게 최초의 SSD입니다. 그때부터 2000년대까지는 비싸지만 꼭 필요한 네트워크 인프라용으로 쓰였습니다. 그러다 2000년대 초중반에 업계가 RAM 기반에서 NAND 기반으로 넘어갔고, NAND의 GB당 가격이 USB 메모리나 메모리 카드 용도를 넘어 제대로 된 저장 장치로 소비자 시장에 들어올 만큼 합리적이 됐습니다.
비교를 위해 대략적인 가격 추이를 적어 보겠습니다.
1978년: GB당 910만 달러
1985년: GB당 92만 달러
1990년: GB당 5만 달러
1995년: GB당 1,000달러 [0]
2005년: GB당 100달러
2006년에 노트북에 들어간 첫 상용 SSD가 시장에 나왔고, 2010년에는 GB당 3달러 정도까지 내려가 널리 보급됐습니다.
[0]: 2000년은 정체된 해였습니다. 제가 조사한 바로는 95년부터 2000년대 초까지 가격이 그대로였다가 2005년에 떨어졌습니다.
제가 보기에 가장 확실한 건 고대역폭 플래시입니다. 제가 아는 한 여러 회사가 활발히 개발하고 있고요.
읽어 본 바로는 한 가지 아키텍처는 사실상 플래시 칩/칩렛이나 PCB 수준에서 RAID0을 하는 겁니다. 빠른 플래시 칩 여러 개를 하나의 넓은 채널로 묶고, 그걸 넓고 빠른 스트리밍 저장 시스템으로 만드는 거죠. 여기서 빠르다는 건 적어도 대량의 데이터를 스트리밍할 때 DRAM과 겨룰 만하다는 뜻이고, AI 추론이 대부분 원하는 게 바로 그런 겁니다.
플래시는, 아주 빠른 플래시라 해도, GB당 가격이 DRAM보다 훨씬 쌉니다.
저는 2TB짜리 고대역폭 플래시, 16~32GB DRAM(어텐션과 기타 상태용), 그리고 큰 TPU로 이루어진 로컬 추론 전용 노드를 갖고 싶습니다. 그러면 Intel NUC 같은 큰 미니 PC 크기로 최첨단 규모의 모델을 돌릴 수 있을 겁니다. 플래시가 싸니까 비용 대부분은 프로세서 쪽으로 넘어가겠죠.
사실상 RAID0 플래시인데 꽤 쓸 만한 보드 레이아웃을 직접 만들어 보는 건 얼마나 현실성이 있을까요? 플래시 칩을 병렬로 잔뜩 붙이고, 싸고 빠른 ARM이나 RISC-V 칩을 플래시 컨트롤러로 써서 스트라이핑을 맡기는 거죠. 그리고 썬더볼트나 PCIe 인터페이스로는 하나의 추상화된 드라이브처럼 보이게 하고요.
지금 플래시를 연결하는 가장 빠른 방법은 PCIe 5.0 x4죠?
약 16GB/s입니다. 그런 드라이브 4개를 RAID0으로 묶어도 64GB/s밖에 안 돼요. 많은 게 아니죠. RTX 5090의 1792GB/s와 비교해 보세요. NVMe 플래시보다 100배 빠릅니다.
맞습니다. 하지만 그건 CPU 메모리에서 GPU 메모리로 스트리밍하는 것과 비슷한 수준이고, MoE 모델에서는 그게 그럭저럭 잘 돌아가는 것 같습니다. 하긴 모델이 SSD가 필요할 만큼 크다면 얘기가 다를 수도 있겠네요.
그래서 기존 모듈이나 SSD를 그냥 이어 붙이는 게 아니라 적어도 보드 수준에서 뭔가를 해야 한다고 생각하는 겁니다. 새로운 컨트롤러 아키텍처를 갖춘 새 보드에 플래시 칩을 채워 넣어야 하죠.
제가 본 삼성이나 인텔 같은 곳의 작업은 칩 수준입니다.
왜 아직 아무도 안 했을까요? 최근까지는 시장이 없었으니까요. 기존 플래시는 SSD 용도로는 충분히 빠르고, DRAM과 겨룰 만큼 빠르게 만들면 더 비싸집니다. 게다가 쓰기가 느리고, 진짜 랜덤 액세스는 DRAM보다 느리고, 쓰기 횟수가 많아지면 닳기 때문에 진짜 DRAM 대체재도 못 됩니다. 읽기 위주에 스트리밍이고 방대한 데이터가 필요한 용도에서만 의미가 있는데, AI 전에는 그게 작은 시장이었습니다.
몇 주마다 누군가 llama.cpp에 수년 전부터 있던 걸 또 우연히 발견하고는 다시 구현하더군요. 왜 그러는지 모르겠어요.
이런 자체 엔진이 생기는 건 대부분, 범용 프로젝트에 기여하는 것보다 자체 엔진을 유지하는 편이 훨씬 쉽기 때문입니다(어느 정도는 이해가 가는 일이죠). 그래서 범용 프로젝트는 최적화를 받아들이는 데 한참 걸리고, llama.cpp나 vllm이 자체 엔진과 성능이 같아질 즈음에는 최적화 대상이던 LLM 아키텍처가 이미 최선이 아니게 되니 별 의미가 없습니다.
llama.cpp 같은 프로젝트의 장점은 로컬 AI 판에 아직 익숙하지 않은 사람이 쓰기 쉽다는 것뿐입니다.
저도 직접 만든 게 하나 있습니다. 같은 모델 가중치로 llama.cpp보다 최대 2배까지 성능이 나오기 때문이에요. 모델 하나를 잘 서빙하는 데 맞춰 최적화했습니다.
저도 그랬어요. sd.cpp는 제 노트북에서 이미지를 생성하는 데 시간이 너무 오래 걸리고, 이미 알려진 문제인데 해결될 것 같지도 않아서 직접 만들었습니다. 그게 이거예요. https://github.com/netdur/qwen-image-cplus
업스트림에 기여해 볼 생각은 안 해 보셨나요?
llama.cpp는 AI의 도움을 받은 기여에 엄격한 정책이 있습니다. 이런 특화 프로젝트는 대부분 코딩 에이전트가 만들었고요. 그래서 llama.cpp는 받아 주지 않습니다(그럴 만하죠).
아니요, 그렇지 않습니다. 코드를 이해하고 있다면 AI로 만든 기여도 환영합니다. 업스트림에 올리고 싶은 게 있으면 저한테 직접 연락 주세요.
무례하게 들리려는 건 아닌데, 그건 그런 프로젝트의 메인테이너들에게 너무 많은 걸 기대하는 것일 수 있습니다.
말씀드렸듯이 llama.cpp 같은 프로젝트는 이 부분에서 까다롭게 고르는 게 낫습니다.
llama.cpp는 범용 추론 엔진이므로 모델별 최적화는 핵심 아키텍처 밖에 두는 게 맞습니다. 맞춤형 추론 애플리케이션을 개발할 때는 연산을 융합하고 대상 모델에 맞춰 연산 커널을 집중적으로 최적화하는 것이 일반적인 방식입니다.
AI 덕분에 이제 누구나 쉽게 바퀴를 다시 발명할 수 있으니까요.
Qwen 3요? (쥬만지) 지금이 몇 년도죠?
시간 낭비네요.
Strata는 이미 Qwen3.8-Flash-Next로 이걸 하고 있어요. https://github.com/Niko1221/Strata
방법론이 다르다면 이번 달 유행 모델이 안 들어 있더라도 HN에서 보고 싶어요.
지원하는 모델 목록에 Qwen3.8-Flash도 들어 있는데요.