젬마 4 26B-A4B는 전체 25.2B 중 토큰당 3.8B만 켜지는 전문가 혼합(MoE) 모델인데, 이 점을 이용해 공유 코어 1.35GB와 KV 캐시만 램에 두고 토큰마다 실제로 불리는 전문가만 SSD에서 읽어 오는 방식이에요. 만든 사람이 직접 잰 값으로는 같은 M5 프로에서 MLX가 램 14GB에 초당 75토큰인데 이 엔진은 램 2GB에 초당 31~35토큰이고, 정작 이 방식이 필요한 8GB M2 맥북 에어에서는 초당 5~6토큰이에요. 파일을 통째로 대응시키는 mmap 대신 필요한 자리만 집어 읽는 pread로 바꾼 것만으로 초당 0.5토큰이 4토큰이 됐다는 게 핵심 기법이에요.
용어 풀이
- MoE
- 모델을 여러 전문가로 쪼개 두고 입력마다 일부만 켜는 구조
- KV 캐시
- 이미 처리한 앞부분을 다시 계산하지 않으려고 담아 두는 메모리
- mmap
- 파일 전체를 메모리 주소에 대응시켜 두고 필요할 때 읽어 오는 운영체제 기능
- pread
- 파일에서 읽을 위치와 크기를 직접 지정해 가져오는 시스템 호출
- MLX
- 애플이 자사 칩에 맞춰 만든 기계학습 프레임워크
운영자 인사이트
사내 코드를 밖으로 못 보내는 팀이라면 '아직'이라는 답을 확인하는 용도로 보는 게 맞아요. 램 2GB는 컨텍스트 4K에서 잰 값이라 코드베이스를 물리는 순간 KV 캐시가 불어나고, 정작 이 기법이 필요한 8GB 기기 속도는 초당 5~6토큰이라 대화형 보조로는 못 써요. 램이 넉넉하면 만든 사람도 MLX를 쓰라고 해요. 다만 MoE에서 필요한 전문가만 골라 스트리밍하는 접근 자체는 로컬 코딩 모델의 하드웨어 문턱을 낮출 방향이라, 제품보다 기법을 눈여겨보면 돼요.
여러 관점으로 보기
- 만든 사람 설명 — 메모리와 속도의 맞바꿈 같은 M5 프로에서 MLX는 램 14GB에 초당 75토큰, 이 엔진은 램 2GB에 초당 31~35토큰이라고 본인이 직접 밝혔고, 속도와 유연성이 우선이면 그냥 MLX를 쓰라고도 했어요. Hacker News
- 회의론 — 24GB에서 잰 값이 기법의 증거냐 24GB 기기면 모델이 어차피 램에 거의 들어가고 운영체제가 파일을 캐시했을 뿐이라는 지적이 나왔고, 초당 30토큰 아래로는 대화형 작업이 사실상 어렵다는 반응, llama.cpp의 SSD 오프로딩과 맞대 본 수치가 없다는 요구도 있었어요. Hacker News
- 코딩 용도에 대한 실사용 증언 댓글에서는 젬마로 쓸 만한 코딩을 해 본 적이 거의 없다거나 온프레미스 방식은 제대로 된 코딩 보조와는 아직 거리가 멀다는 말이 이어졌고, 코딩이면 Qwen 3.6 쪽이 낫다는 언급이 반복됐어요. Hacker News
- 모델 쪽 사정 — 26B 중 3.8B만 켜지는 구조 전문가 128개 중 토큰마다 8개와 공유 전문가 1개만 켜지는 구조라 이런 스트리밍이 성립하는 거예요 — 이 기법은 조밀한(dense) 모델에는 그대로 통하지 않아요. Hugging Face