2026년 7월, “TurboFieldfare”라는 오픈소스 프로젝트가 Hacker News에서 608점과 200개가 넘는 댓글을 기록하며 뜨거운 화제를 모았습니다. 이유는 명확했습니다. 260억(26B) 파라미터를 가진 대형 언어 모델을 단 8GB 메모리를 탑재한 Mac 노트북에서, 그것도 불과 2GB 정도의 메모리 점유율만으로 성공적으로 실행했기 때문입니다.
260억 파라미터. 2GB 메모리. 이 두 숫자가 함께 놓여 있다는 사실 자체가 기존 상식을 깨뜨립니다.
“대형 모델이 반드시 고가의 대용량 GPU를 의미하는 것은 아니다.” 이것이 본 글을 통해 전달하고자 하는 핵심 메시지입니다.
불가능해 보였던 도전 과제
먼저 배경을 살펴보겠습니다. Gemma 4는 Google DeepMind가 2026년 초에 발표한 오픈 모델 시리즈입니다. 그중 “Gemma 4 26B-A4B”라는 모델은 혼합 전문가 아키텍처(MoE, 아래에서 설명)를 채택하고 있습니다. 이 모델은 4배 압축(양자화)을 거친 후에도 여전히 14GB의 저장 공간이 필요합니다.
하지만 대다수 일반 사용자의 Mac 노트북 메모리는 8GB에 불과합니다. 운영체제 자체가 3~4GB를 차지하므로 대형 모델에 할당할 수 있는 메모리 공간은 매우 제한적입니다.
기존의 추론 도구(llama.cpp나 MLX 등)는 모델 전체를 메모리에 완전히 로드한 뒤 실행합니다. 14GB 크기의 모델을 8GB 메모리 기기에서 모두 로드하는 것은 불가능합니다. 운영체제가 단일 앱의 전체 메모리 독점을 허용하지 않기 때문입니다. 이 방식은 처음부터 막혀 있었습니다.
따라서 질문은 다음과 같이 바뀌었습니다. “모델을 메모리에 전부 올리지 않고도 실행할 수 있는 방법이 있을까?”
TurboFieldfare의 개발자이자 iOS 및 Metal 엔지니어인 Andrey Mikhaylov는 이에 확실한 답을 제시했습니다. 그는 몇 주 동안 103번에 달하는 비교 실험을 수행하고, Swift 언어와 Apple의 Metal 그래픽 프레임워크를 사용해 바닥부터 추론 엔진을 직접 작성했습니다. 그 결과 M2 MacBook Air에서 초당 56개 토큰, 최신 M5 Pro에서는 초당 3135개 토큰의 생성 속도를 달성했습니다.
단순히 작동하는 데 그치지 않고 수용 가능한 속도를 보여주었습니다. 이는 이론적인 제안이 아니라 직접 다운로드하여 실행할 수 있는 엔지니어링 성과입니다.
MoE 모델의 숨은 강점: 스트리밍 로딩에 최적화된 구조
이 솔루션을 이해하려면 먼저 혼합 전문가 아키텍처(MoE)의 특성을 파악해야 합니다.
기존의 대형 언어 모델은 모든 분야를 다루는 “전통적 일꾼”입니다. 한 단어를 생성할 때마다 모델 전체의 모든 파라미터가 계산에 참여합니다. 이는 회사의 모든 직원이 모든 안건에 관여하는 것과 같아 매우 비효율적입니다.
MoE 모델은 전혀 다릅니다. 128개의 전문 부서를 가진 대기업과 같습니다. 새로운 작업이 들어오면 “라우터”라는 스케줄러가 작업 내용을 분석한 후 가장 적합한 8개 부서(전문가)만 활성화하여 일하게 합니다. 나머지 120개 부서는 휴식을 취합니다.
전체 260억 개 파라미터 중에서 실제로 매 계산에 참여하는 것은 약 38억 개에 불과합니다. 이것이 “26B-A4B”에서 A4B가 의미하는 바입니다(Active 4 Billion, 매회 약 40억 개 파라미터 활성화).
이 아키텍처적 특성이 TurboFieldfare의 전략 방향을 결정했습니다. “매번 전체의 10% 미만의 전문가만 사용한다면, 왜 나머지 90%의 가중치를 메모리에 계속 쌓아두어야 하는가?”
14GB 모델을 2GB에 구겨 넣은 3가지 핵심 최적화
기존 추론 프레임워크 방식은 128개 전문가의 가중치를 전부 메모리에 로드하여 상시 대기시킵니다. 일하지 않는 직원 120명의 자리까지 사무실에 미리 마련해 두어 층 전체를 차지하는 셈입니다.
TurboFieldfare의 방식은 매우 직관적입니다. “일하는 자만 자리에 앉힌다.”
첫 번째: 4배 압축을 통한 데이터 경량화
모델 가중치 데이터의 정밀도에는 상당한 중복성이 존재합니다. 4K 초고화질 사진을 1080P로 압축해도 일반인이 차이를 거의 느끼지 못하는 것과 비슷합니다.
TurboFieldfare는 4비트 양자화 기술을 사용하여 모델 파라미터 정밀도를 16비트에서 4비트로 축소함으로써 크기를 4분의 1로 줄였습니다. 14GB라는 압축 후 가중치 크기가 이렇게 탄생했습니다. 라우팅 정확도를 위해 라우터 부분에는 8비트 양자화를 적용하고, 메인 가중치 부분은 전부 4비트로 구성하여 수용 가능한 응답 품질을 유지했습니다.
두 번째: SSD 스트리밍 로딩, 메모리에는 공통 분모만 저장
이 프로젝트에서 가장 핵심적인 엔지니어링 설계 부분입니다.
TurboFieldfare는 모든 전문가가 공유하는 1.35GB의 공통 계산 레이어와 KV 캐시만 메모리에 상주시키고, 128개 전문가의 가중치는 모두 SSD에 남겨둡니다. 단어를 하나씩 생성하는 계산 과정마다 SSD에서 현재 필요한 8개의 전문가 데이터만 읽어옵니다.
그러나 물리적인 한계가 존재합니다. SSD의 읽기 속도는 메모리보다 훨씬 늦습니다. 메모리 지연 시간은 나노초 단위인 반면, SSD 지연 시간은 밀리초 단위로 수만 배 차이가 납니다. 매 읽기 작업마다 SSD를 그저 기다리기만 한다면 생성 속도가 터무니없이 느려집니다.
세 번째: 지능형 캐싱 + 시간 오버랩(병렬화)
개발자는 이 속도 차이를 해결하기 위해 3가지 차원의 최적화를 설계했습니다.
전문가 캐싱. 매번 8개의 전문가가 필요하지만, 연속적인 토큰 생성 과정에서 필요한 전문가는 자주 중복됩니다. TurboFieldfare는 각 레이어마다 16개의 캐시 슬롯을 유지하고 LFU(최소 사용) 알고리즘을 사용해 유지할 전문가를 결정합니다. 캐시에 적중한 전문가는 SSD에서 다시 읽을 필요가 없습니다. 실험 데이터에 따르면 이 캐시 덕분에 전문가 데이터 읽기 시간이 토큰당 166밀리초에서 88밀리초로 감소했습니다.
병렬 프리리드(Parallel pread). 온디맨드 페이징(mmap) 방식에 의존하여 운영체제가 자동으로 페이지를 로드하게 만드는 방식은 코드상 깔끔해 보이지만, 실제 측정 결과 콜드 스타트 시 속도가 0.5 tok/s에 불과하여 재앙에 가까웠습니다. 개발자는 명시적인 동시 pread 시스템 호출로 전환하여 능동적으로 병렬 읽기 요청을 시작했고, 속도를 3.97 tok/s까지 끌어올렸습니다. 이 선택은 이론적 추론이 아닌 실제 측정에서 비롯되었습니다.
시간 오버랩. SSD가 전문가 데이터를 읽는 동안 GPU는 쉬지 않고 모델의 공유 레이어를 계산합니다. 공유 레이어 계산이 끝날 때쯤 SSD 데이터도 딱 맞게 도착합니다. 이러한 정밀한 스케줄링을 통해 대기 시간이 거의 완벽하게 가려집니다. 하나씩 개별 처리하는 미세한 방식보다, 묶어서 읽은 후 일괄 계산하는 “조립식(Coarse-grained) 오버랩” 방식이 훨씬 안정적이고 효율적이었습니다.
103번의 실험, 그중 절반 이상의 실패
엔지니어링은 논문 작성과 다릅니다. 논문은 성공적인 경로만 보여주지만, 엔지니어링은 실패한 모든 갈림길을 직접 걸어봐야 합니다.
TurboFieldfare 문서에는 103번의 실험에 대한 상세한 결과가 기록되어 있으며, 개발자는 겉보기에는 좋아 보였으나 실제로는 효과가 없었던 시도들을 솔직하게 공유했습니다.
메모리 맵핑(mmap)의 유혹. 운영체제가 페이지 로딩을 관리하게 하면 코드 양이 가장 적습니다. 실제 측정 결과: 콜드 스타트 시 0.5 tok/s로 멈춘 것과 다름없었습니다.
SIMD 협력 커널. 여러 쓰레드가 하나의 전문가를 협력하여 처리하면 코드 구조가 깔끔해집니다. 실제 결과: GPU 계산 시간이 230밀리초에서 527밀리초로 두 배 이상 늘어나 결국 폐기되었습니다.
계층 간 전문가 예측 로딩. 이번 레이어에서 전문가 A와 B를 선택했다면 다음 레이어의 전문가를 미리 로드할 수 있을까? 분석 결과 인접한 레이어 간 전문가 선택은 상관관계가 거의 없었으며, 예측 정확도는 7%에 불과해 적용하지 않기로 했습니다.
미세 입자 비동기 처리. 각 전문가 데이터를 읽어오는 즉시 계산을 시작하는 방식입니다. 동기화 오버헤드가 오히려 전체 속도를 떨어뜨리고 출력 결과까지 변경시켰습니다. 결국 더 단순한 조립식 방식이 선택되었습니다.
이러한 실패의 가치는 성공 못지않게 큽니다. 이는 소박하지만 자주 간과되는 진리를 잘 보여줍니다. “진정으로 유용한 최적화는 실제 검증을 거친 최적화뿐이다.”
이것이 왜 중요한가?
TurboFieldfare의 의의는 한 가지 사실을 입증했다는 데 있습니다.
“대형 언어 모델 추론에 반드시 고가의 GPU가 필요한 것은 아니다.”
SSD 스트리밍 로딩, 지능형 캐싱, 하드웨어 인지형 커널 설계 등 극진한 소프트웨어 최적화를 통해 일반 사용자가 가진 노트북 컴퓨터도 충분한 AI 추론 기기가 될 수 있습니다.
현재 최고급 GPU는 소수 기업이 독점하고 있으며 가격이 비싸고 구하기 어렵습니다. TurboFieldfare와 같은 프로젝트는 또 다른 길을 보여줍니다. 더 비싼 하드웨어에 의존하는 대신 더 뛰어난 소프트웨어로 물리적 한계를 바꿔놓는 것입니다.
이는 1990년대 게임 산업을 떠올리게 합니다. 당시 3D 게임은 전문 그래픽 워크스테이션에서만 실행되었으나, 소비자용 3D 그래픽 카드의 등장으로 일반 PC에서도 3D 게임을 즐길 수 있게 되었습니다. TurboFieldfare는 이러한 역사적 과정의 초기 단계에 있으며, AI 추론이 하드웨어에 귀속될 필요가 없다는 사실을 업계 전체에 알리고 있습니다.
현재 이 프로젝트는 GitHub에서 900개 이상의 스타를 받았으며 커뮤니티에서 더 많은 성능 테스트 데이터를 기여하기 시작했습니다. 개발자는 iPhone과 iPad 버전도 출시하여 모바일 기기에서도 로컬로 대형 모델을 실행할 수 있도록 할 계획입니다.
어쩌면 멀지 않은 미래에 당신의 스마트폰, 심지어 이어폰 속에서도 수백억 파라미터 규모이지만 몇 십 MB의 메모리만 차지하는 AI 비서가 작동할지 모릅니다. TurboFieldfare는 그 길 위에 놓인 하나의 디딤돌이지만, 명확한 방향을 제시하고 있습니다.
참고 링크:
- GitHub: TurboFieldfare 저장소
- HN 토론 (item?id=49098510)
- Gemma 4 기술 보고서
- Maarten Grootendorst의 Gemma 4 시각화 가이드
- TurboFieldfare 시스템 설계 문서
- TurboFieldfare 최적화 실험 기록 (103회 실험)
