무슨 일이 있었나
깃허브에 Strata라는 오픈소스 프로젝트가 올라왔어요. 내세우는 숫자가 꽤 자극적인데요. 파라미터가 1,250억 개(125B)인 Qwen 3.8 Flash Next 모델을 일반 소비자용 그래픽카드인 RTX 4090 한 장으로 초당 약 100토큰 속도로 돌릴 수 있다고 해요.
이 숫자가 왜 놀라운지는 간단히 계산해보면 알 수 있어요. 125B 모델은 가중치를 4비트로 압축해도 60GB가 넘거든요. 그런데 RTX 4090의 VRAM(그래픽카드 전용 메모리)은 24GB뿐이에요. 모델이 그래픽카드에 통째로 들어가지도 않는데 초당 100토큰이면 사람이 읽는 속도보다 훨씬 빠르고, 클라우드 API와 비교해도 밀리지 않는 속도예요. 그러니 “대체 어떻게?”라는 질문이 나올 수밖에 없죠.
어떻게 이게 가능할까: MoE와 전문가 오프로딩
핵심 키워드는 MoE(Mixture of Experts, 전문가 혼합)예요. 이게 뭐냐면, 모델 안에 작은 ‘전문가’ 네트워크를 수백 개 넣어두고 토큰 하나를 처리할 때마다 그중 몇 개만 골라 쓰는 구조예요. 대형 병원에 전문의가 수백 명 있어도 환자 한 명은 그중 두세 명만 만나는 것과 비슷하죠.
Qwen 계열에는 이미 선례가 있어요. 작년에 나온 Qwen3-Next-80B-A3B는 전체 파라미터가 80B인데, 토큰 하나를 처리할 때 실제로 계산에 쓰이는(활성) 파라미터는 약 3B밖에 안 됐거든요. 이름으로 보면 이번 모델도 ‘Next’ 계열의 후속 같아요. 그렇다면 전체 크기는 125B여도 활성 파라미터는 훨씬 작을 가능성이 높아요. 정확한 수치는 저장소와 모델 카드에서 꼭 확인해보세요.
이런 구조에서 힘을 발휘하는 게 오프로딩이에요. 매번 쓰이는 부분(어텐션 레이어, 공유 전문가, KV 캐시 등)은 빠른 GPU 메모리에 올려두고, 가끔 불리는 전문가들은 상대적으로 넉넉한 시스템 RAM에 두는 방식이에요. 여기에 자주 호출되는 ‘인기 전문가’를 GPU에 캐싱하거나 다음에 쓸 전문가를 미리 불러오는(prefetch) 최적화를 더하면 체감 속도가 크게 올라가요.
숫자를 읽을 때 체크할 것들
“초당 100토큰”은 측정 조건에 따라 의미가 완전히 달라지는 숫자예요. 직접 확인해볼 포인트를 정리해볼게요.
- 단일 사용자 기준인가, 배치 처리 합계인가? 요청 여러 개를 묶어서 처리한 합산 처리량이라면 한 사람이 체감하는 속도는 훨씬 낮을 수 있어요.
- 프롬프트 처리(prefill)인가, 답변 생성(decode)인가? 입력을 읽는 단계는 병렬 처리가 잘 돼서 숫자가 크게 나와요. 반면 체감 속도는 토큰을 하나씩 뽑아내는 생성 단계에서 결정돼요.
- 양자화는 몇 비트인가? 2~3비트까지 내리면 빨라지는 대신 답변 품질이 떨어질 수 있어요. 품질 벤치마크도 함께 공개됐는지 보세요.
- 컨텍스트 길이는? 짧은 프롬프트일 때와 수만 토큰짜리 문서를 넣었을 때의 속도는 꽤 차이가 날 수 있어요.
- 시스템 RAM과 CPU 사양은? 오프로딩 방식에서는 GPU만큼이나 메모리 대역폭(DDR5 채널 수 등)이 중요해요.
업계 맥락: 이미 이 길을 걷는 도구들
이 방향 자체는 새로운 게 아니에요. llama.cpp에는 MoE 전문가 가중치를 CPU 쪽에 두는 옵션(--override-tensor, --n-cpu-moe 등)이 있어서, 이미 많은 사람들이 큰 MoE 모델을 단일 GPU로 돌리고 있어요. 칭화대 쪽에서 나온 KTransformers는 CPU와 GPU를 섞어서 DeepSeek 같은 초대형 MoE를 돌리는 데 특화돼 있고요. 자주 활성화되는 뉴런만 GPU에 두는 PowerInfer 같은 연구도 있었어요.
그래서 Strata를 볼 때 핵심 질문은 “가능하냐”가 아니라 “기존 도구보다 같은 조건에서 얼마나 빠르냐”예요. llama.cpp 같은 기준선과 동일한 하드웨어, 동일한 양자화로 비교한 수치가 있다면 훨씬 믿을 만한 프로젝트라고 볼 수 있어요.
한국 개발자에게 주는 시사점
국내에는 사내 보안 때문에 외부 LLM API를 못 쓰는 회사가 정말 많아요. 이런 환경에서 게이밍 PC 한 대 수준의 장비로 100B급 모델을 쓸 만한 속도로 돌릴 수 있다면 꽤 현실적인 선택지가 돼요. 사내 코드 리뷰 봇이나 문서 검색 RAG, 개인 코딩 어시스턴트 같은 용도라면 더 그렇고요.
당장 써볼 생각이라면 먼저 README의 측정 조건부터 꼼꼼히 읽어보세요. 그다음 본인 장비에서 llama.cpp와 나란히 돌려서 속도와 답변 품질을 같이 비교해보는 걸 추천해요. 개인이 운영하는 저장소라면 업데이트가 끊길 수도 있으니까, 운영 환경에 바로 넣기보다는 실험용으로 먼저 써보는 게 안전해요.
마무리
한줄 정리: MoE와 오프로딩 덕분에 ‘큰 모델 = 비싼 서버’라는 공식이 깨지고 있어요. Strata는 그 흐름에 있는 실험이고, 숫자는 측정 조건과 함께 읽어야 해요.
여러분은 로컬 LLM을 실무에서 쓰고 계신가요? 쓰고 계신다면 속도와 품질 중 어디에서 타협하고 있는지 궁금해요.
🔗 출처: Hacker News