단일 3090에서 122B MoE 모델을 35 t/s로: ik_llama.cpp가 바꾼 로컬 추론의 게임
122B짜리 거대 모델을 방구석 책상 위에서 초당 35토큰으로 돌린다고? 처음엔 또 어그로성 낚시글인 줄 알았다. (70B도 단일 GPU로 돌리려면 곡소리가 나는데 122B라니?)
로컬 LLM 커뮤니티의 오랜 화두는 “얼마나 큰 모델을 가정에서 돌릴 수 있는가”다. 클라우드 API가 편하긴 하지만, 비용은 눈덩이처럼 불어나고 내 프라이빗 데이터는 고스란히 남의 서버로 날아간다. 그래서 로컬 추론은 늘 매력적인 꿈이었다. 문제는 살벌한 하드웨어 가격. 70B 모델도 24GB VRAM GPU 하나로는 빡빡한 판에, 122B는 꿈도 못 꿀 영역으로 여겨졌다.
그런데 r/openclaw에서 한 유저가 놀라운 결과를 공유했다. 192GB DDR5 RAM과 중고 RTX 3090 단 한 장으로 Qwen 3.5 122B MoE 모델을 초당 35 토큰(t/s) 속도로 시원하게 뽑아낸 거다. 총 하드웨어 비용은 약 $3,600.
이 글에서는 이게 어떻게 가능했는지, 핵심 기술인 ik_llama.cpp의 MTP 최적화가 무엇인지, 그리고 이것이 로컬 LLM 생태계에 의미하는 바를 정리한다.
핵심 기술 1: MoE 아키텍처와 오프로딩
MoE가 왜 다른가
Qwen 3.5 122B는 Mixture of Experts(MoE) 아키텍처를 사용한다. Dense 모델이 모든 파라미터를 매 추론마다 활성화하는 것과 달리, MoE는 입력에 따라 일부 전문가(expert) 레이어만 선택적으로 활성화한다. 즉, 총 파라미터는 122B지만 실제 연산량은 훨씬 적다.
이게 오프로딩(offloading)과 시너지를 낸다. 전체 모델을 VRAM에 올릴 필요 없이, 대부분의 가중치를 시스템 RAM(DDR5)에 두고, 활성화된 전문가 레이어만 GPU로 가져오는 방식이다. GPU VRAM 24GB는 핫 패스용 캐시로 쓰고, 192GB DDR5가 메인 메모리 역할을 하는 셈이다.
기존 llama.cpp의 한계
문제는 속도다. RAM↔GPU 간 데이터 이동이 병목이 되어, 기존 llama.cpp로 MoE 모델을 오프로드하면 속도가 처참하다(토큰 하나 뽑는데 하염없이 커서 깜빡이는 거 보면 속이 터진다). 특히 Multi-Token Prediction(MTP) 기능을 켜면 오히려 속도가 +4% 향상에 그친다. MTP는 여러 토큰을 동시에 예측해 추론 속도를 높이는 기술인데, 오프로드된 MoE에서는 전문가 선택이 매 토큰마다 달라져 MTP의 이점이 거의 사라진다.
핵심 기술 2: ik_llama.cpp의 fused MoE ops
왜 5배 차이가 나는가
여기서 ik_llama.cpp 포크가 등장한다. 이 포크의 핵심 차이는 fused MoE operations이다.
기존 llama.cpp는 MoE 레이어를 처리할 때 각 전문가의 연산을 개별적으로 수행한다. 전문가 A 계산 → 결과 저장 → 전문가 B 계산 → 결과 저장 → … 이 방식은 GPU↔RAM 간 데이터 이동이 빈번해 오프로딩 환경에서 치명적이다.
ik_llama.cpp는 이를 통합(fused) 처리한다. 필요한 전문가들을 한 번에 GPU로 가져와서 연속적으로 계산하고, 결과를 한 번에 돌려보낸다. 이게 왜 차이가 크냐:
- 메모리 전송 횟수 감소: 왕복 횟수가 전문가 수만큼 줄어든다
- GPU 캐시 효율 증가: 연속 연산으로 L2 캐시 적중률이 급상승
- MTP와 MoE의 결합: MTP로 예측한 여러 토큰에 대해 전문가 선택을 최적화할 수 있어, 속도 향상이 +4%가 아니라 +20%에 달함
실제 성능
해당 유저의 세팅에서 측정된 수치:
| 모델 | 속도 (t/s) | 용도 |
|---|---|---|
| Qwen 3.5 122B MoE | 35 | 코딩, 복잡 추론 |
| Qwen 3.5 35B | 135 | 창의 작업, 빠른 응답 |
35 t/s는 실시간 채팅에는 약간 느리지만, 코딩 에이전트나 문서 분석에는 충분한 속도다. 35B 모델을 병행 운영하면 빠른 응답이 필요할 때 가볍게 전환할 수도 있다.
왜 주목할까: 하드웨어가 아닌 소프트웨어의 승리
이 사례의 진짜 의미는 “비싼 GPU 여러 장 없이도 큰 모델을 돌린다”가 아니다. $3,600도 적은 돈은 아니니까. 핵심은 문제를 하드웨어로 해결하지 않고 소프트웨어로 해결했다는 점이다.
기존 접근은 “VRAM이 부족하면 GPU를 더 사라”였다. 122B를 제대로 돌리려면 A100이나 H100이 필요하다는 게 정설이었다. 하지만 ik_llama.cpp는 연산 패턴 자체를 최적화해서, 중간급 하드웨어에서도 상당한 성능을 끌어낸다.
이건 로컬 LLM 생태계 전체에 시사하는 바가 크다:
- 접근성 확대: 클라우드 비용 부담 없이 대형 모델을 로컬에서 실험할 수 있는 길이 열렸다
- 오픈소스의 힘: llama.cpp 포크 하나가 생태계를 바꾸는 사례. 커뮤니티 주도 최적화가 계속해서 속도를 내고 있다
- MoE의 실전 검증: MoE가 이론적 장점을 넘어 실제 오프로딩 환경에서도 경제적 이점이 있음이 입증되었다
정리
단일 3090 + 192GB DDR5 시스템에서 Qwen 3.5 122B MoE를 35 t/s로 구동한 사례는, 로컬 LLM 추론의 한계를 소프트웨어 최적화로 돌파한 의미 있는 성과다. ik_llama.cpp의 fused MoE ops가 기존 대비 5배의 MTP 속도 향상(+4% → +20%)을 달성한 게 핵심이다.
앞으로 MoE 모델이 더 다양해지고, 이런 소프트웨어 최적화가 지속되면, “어떤 모델이 좋은가”보다 “어떻게 싸게 굴리는가”가 더 중요한 질문이 될 것이다. 로컬 추론은 여전히 클라우드보다 불편하지만, 그 격차는 빠르게 좁혀지고 있다.
참고: r/openclaw의 논의 데이터를 바탕으로 정리했다.