Strata: GPU와 시스템 메모리를 나눠 쓰는 대형 모델 추론 엔진

배경과 문제

대규모 언어 모델은 텍스트를 토큰(대략 단어 조각) 단위로 생성하며, 각 토큰마다 해당 토큰이 사용하는 모델 가중치를 하드웨어가 읽어야 한다. 일반 PC에서 가장 빠른 메모리는 그래픽카드의 VRAM(초당 수백 GB)이고, 다음은 시스템 RAM(초당 수십 GB), 가장 느린 것은 SSD다. 기술 보고서는 Qwen3.8-Flash-Next를 전체 1250억 파라미터 중 토큰마다 60억 개를 활성화하는 MoE 모델로 설명한다. 이 설명에 따르면, 쓸 만한 품질을 내는 가장 작은 양자화 파일도 66GB로 12GB 그래픽카드 메모리의 5.5배에 달한다.

기존에는 llama.cpp 같은 범용 엔진으로 일부 가중치를 시스템 RAM에 두고 CPU에서 계산하는 방식이 사용되었다. 그러나 Strata 개발자는 이 방식이 동작은 하지만 PC의 대부분을 대부분의 시간 동안 놀게 둔다고 지적한다. 한쪽 계산이나 메모리 이동을 기다리는 동안 다른 장치가 일을 못할 수 있다는 문제의식이다. Strata는 이 문제를 해결하기 위해 범용성을 포기하고 이 모델 하나만을 위한 엔진을 새로 작성하여, 게이밍 PC의 각 구성 요소가 동시에 자신이 잘하는 일을 맡도록 설계했다.

기존 접근의 한계

llama.cpp에서 MoE 모델을 실행하는 일반적인 방법은 전문가 층 일부를 CPU로 보내는 --n-cpu-moe 옵션을 사용하는 것이다. 개발자가 RTX 3060(12GB), RAM 46GB, Core Ultra 7 265를 갖춘 Linux PC에서 같은 IQ3_XXS GGUF 파일로 두 엔진을 비교한 결과, 엔진 0.1.40과 llama.cpp 0.6.0에서 온도 0·256토큰 생성 중앙값을 비교하면, 4K 프롬프트 뒤 생성 속도는 Strata가 초당 41.6토큰, llama.cpp가 9.1토큰으로 약 4.6배 차이가 났다. 32K 프롬프트에서도 Strata 41.8토큰 대 llama.cpp 8.8토큰으로 비슷한 격차를 보였다.

그러나 이 비교에는 중요한 단서가 있다. 3라운드 실행에서 4K 온도0의 표본은 Strata 8건·llama.cpp 6건, 32K는 각 3건이었다. 첫 요청의 파일 읽기와 메모리 적재도 결과에 영향을 주었다. llama.cpp 튜닝은 -ncmoe와 -ub 두 값만 좁게 훑었으며 텐서별 -ot 패턴과 스레드 수는 조정하지 않았다. 모델 크기도 IQ3_XXS 하나뿐이고 perplexity와 KL 같은 품질 비교는 이 기록에 없다. 또한 llama.cpp에 별도의 MTP 헤드를 붙이자 4K 생성이 초당 9.1토큰에서 7.0토큰으로 오히려 느려졌는데, 이는 헤드가 VRAM 3.4GB를 차지해 전문가 층이 더 많이 CPU로 밀려났기 때문이라고 개발자는 설명한다. 따라서 4.6배라는 수치는 일반적인 성능 보장이 아니라 특정 조건에서의 자체 측정 결과로 이해해야 한다.

연구방법을 단계별로

Strata의 핵심 설계는 모델의 구조에 맞춰 메모리 배치를 정하는 것이다. Qwen3.8-Flash-Next는 48개 층으로 구성되며, 각 층은 512개의 전문가 중 라우터가 10개를 선택한다. 따라서 토큰 하나가 읽는 전문가 가중치는 전체의 약 2%에 불과하다. Strata는 매 토큰에 필요한 공통 부분(약 3.5GB)과 자주 쓰이는 전문가 수천 개를 그래픽카드 VRAM에 두고, 전문가 24,576개 전체는 RAM에도 페이지 잠금(pinned) 상태로 올려 CPU가 그래픽카드와 같은 순간에 계산하게 한다. SSD에는 28.8GB 크기의 N-gram 임베딩 표를 두고, 엔진이 토큰마다 필요한 16개 행을 한 단계 앞서 읽어 둔다.

층 하나를 처리하는 과정은 세 작업자가 동시에 일하는 방식이다. 그래픽카드가 라우터를 실행해 선택된 전문가 10개의 번호를 CPU 쪽 고정 메모리에 적으면(이를 '도어벨'이라고 부른다), 이를 기다리던 CPU가 즉시 전문가를 나눈다. VRAM 캐시에 있는 전문가는 그래픽카드가, 일부는 PCIe로 복사해 그래픽카드가, 나머지는 CPU가 RAM 안에서 직접 계산한다. 각 결과를 그래픽카드가 합친 뒤 다음 층으로 넘어간다. 전체 48층 통과는 하나의 캡처된 CUDA 그래프로 실행되어 호스트가 동기화 드라이버 호출을 기다리지 않는다.

생성 속도를 높이기 위해 Strata는 모델에 내장된 다중 토큰 예측(MTP) 층을 초안 모델로 사용하는 투기적 디코딩을 적용한다. MTP 층은 다음 토큰을 최대 3개까지 추측하고, 본 모델은 48개 층을 한 번 통과하면서 추측을 모두 확인해 맞는 것만 남기고 한 토큰을 직접 더 쓴다. 추측은 MTP 층의 확신이 50% 이상일 때만 넣으며, 측정 조건에 따라 한 번 통과할 때 평균 약 2.4~3.6토큰이 나온다. 그 결과 생성 속도는 1.6~1.8배 빨라진다. 논문에 따르면 이 방식은 일반 탐욕(greedy) 디코딩과 토큰 단위로 동일한 결과를 내며, 의도적으로 잘못된 초안과 롤백을 통해 검증했다고 한다.

결과와 숫자의 의미

개발자가 RTX 5070(12GB), Ryzen 5 7600, 64GB DDR5, NVMe SSD, Windows 10 PC에서 측정한 결과, Q2_0 양자화 모델은 4K 컨텍스트에서 초당 94.6토큰을 생성했다. 이는 256개 생성 토큰, greedy 디코딩, MTP 사용, 길이별 1프롬프트 1실행 조건에서 나온 값이다. 컨텍스트가 262K로 늘어나면 생성 속도는 초당 56.3토큰으로 떨어지고, 첫 토큰까지 걸리는 시간은 523.8초로 크게 증가한다. IQ3_XXS 모델은 262K에서 메모리 부족으로 측정되지 않았다.

프롬프트 읽기 속도는 Q2_0 기준 4K에서 초당 539토큰, 262K에서 496토큰으로 컨텍스트 길이에 따라 거의 평평하다. 이는 희소 어텐션이 컨텍스트 길이와 무관하게 제한된 위치만 읽기 때문이다. 그러나 현재 README에는 Q2_0 생성 94토큰/초, 프롬프트 읽기 2,650토큰/초처럼 다른 버전의 값이 함께 표기되어 있어 혼동하기 쉽다. README의 Q2_0 값은 엔진 0.1.36, 다른 행은 0.1.26, 생성 4K/입력 32K 조건이며, PDF의 이전 프롬프트 속도 539/571과 직접 비교해서는 안 된다.

RTX 3090이나 RTX 5060 Ti에 대한 PDF 표 6의 숫자는 실측이 아니라 예측이다. 같은 CPU와 64GB DDR5를 가정하고, GPU 부분은 메모리 대역폭으로, CPU 부분은 VRAM에 들어가지 않는 전문가 비율로 스케일링하여 추정한 값이다. 개발자는 누군가 실제로 측정하기 전까지 ±20%로 취급하라고 명시했다. 따라서 이 값들을 실제 성능으로 인용해서는 안 된다.

구체적인 예시

현재 README는 RAM 용량에 따라 모델 변형을 고르게 한다. 32GB에는 전문가 절반을 제거한 Coder를 권하며, 원모델 SWE-bench Verified 점수의 91%라는 값은 변형 제작자 측정이라고 표시한다. 한국어나 중국어 같은 코드 밖의 용도에서는 더 약할 수 있다. 64GB에는 IQ2_XS를 권장하고 IQ3 계열도 선택지로 제시하지만, 긴 문맥까지 모든 조합이 들어간다는 뜻은 아니다. 이 안내는 특정 모델 계열의 선택 기준이며 다른 대형 모델에 그대로 적용할 수 없다.

개발자가 공개한 복셀 탑 정원 웹페이지 데모는 RTX 5070과 IQ3_S, 128K 문맥 설정으로 만든 사례다. README의 49초는 전체 영상 길이로 표시되어 있으므로, 웹페이지 생성에 정확히 49초가 걸렸다는 측정으로 사용하지 않는다. 로컬 API를 통해 코딩 도구를 연결하는 활용은 가능하지만, 한 번의 데모가 일반적인 코딩 과제의 정확도나 성공률을 입증하지는 않는다. 기본 서버는 한 번에 한 요청을 처리하며, 12GB GPU에서 두 요청을 병렬로 돌리면 각 답변은 느려질 수 있다.

한계와 오해하기 쉬운 점

가장 흔한 오해는 12GB GPU에 전체 모델이 들어간다는 생각이다. 실제로 GPU에는 항상 사용하는 부분 약 3.5GB와 일부 전문가만 있고, RAM에는 24,576개 전문가 전체, SSD에는 28.8GB n-gram 표가 있다. 층마다 512개 전문가 중 10개를 선택하는 48층 구조이며, 전체 모델에서 전문가 10개만 쓰는 것이 아니다. 또한 32GB RAM 권장은 전문가 절반을 제거한 Coder 변형에 대한 것이며 원래 전체 모델과 같지 않다.

MTP가 같은 답을 유지한다는 PDF 설명은 greedy 검증 방식에 관한 것이며, 원래 고정밀 모델과 양자화 모델의 품질 동일성을 뜻하지 않는다. 현재 기본 설정에서는 하위 전문가 생략(route tail skip)이 함께 검증하는 토큰 구성에 따라 달라지고, IQ 계열 크기에서는 CPU가 전문가를 한 토큰씩 계산할 때와 여러 토큰을 묶어 계산할 때 반올림이 조금 다르다. 그래서 온도 0에서도 초안 구성에 따라 답이 달라질 수 있다. 또한 10월 6일 비교 로그의 모델 메타데이터는 177B/활성 약 3B라고 적혀 있어, 제목과 기술 보고서의 125B/활성 6B 표기와 일치하지 않는다. 이 모순을 임의로 해결하거나 여러 구성의 속도를 단일 검증 결과처럼 합쳐서는 안 된다.

공개한 속도는 개발자 자체 측정이며 동료 심사나 독립 재현을 확인하지 않았다. 서버의 외부 보안 감사도 확인하지 못했고 버전이 빠르게 바뀌므로, 장기 운영이나 여러 사용자 동시 접속을 계획한다면 별도 검증이 필요하다. 코드에는 MIT가 표시되어 있지만 모델과 파생 자료에는 별도 조건이 적용된다. 코드의 공개만으로 모델을 사용하는 모든 서비스의 상업적 이용 조건까지 확인된 것은 아니다.

실제로 어떻게 활용할까

설명용 활용 예로, 로컬 PC에서 큰 코드 파일을 읽고 수정 후보를 만드는 보조 도구를 생각할 수 있다. 이때 생성 토큰/초뿐 아니라 파일을 처음 읽는 시간, 후속 대화의 캐시 사용, RAM 여유와 결과 품질을 함께 재야 한다. 현재 README는 첫 실행에서 35~55GB를 메모리에 올리며 잠시 PC가 느려질 수 있다고 안내한다. 논문의 짧은 응답 속도만 보고 긴 코드 분석도 즉시 끝날 것으로 기대해서는 안 된다.

채팅과 Monitor 화면에서 GPU·CPU·RAM 사용량을 살펴보고, 같은 문서와 질문을 자기 장비에서 반복 측정하는 것이 활용의 출발점이다. 로컬 모델 서버를 쓰더라도 연결한 에이전트나 검색 도구의 외부 통신은 별도로 확인해야 한다. 또한 Mac 지원은 현재 README에서 커뮤니티가 작성한 실험 경로로 안내한다. NVIDIA 장비의 속도 수치를 Mac의 예상 성능으로 대입하거나, 기존 PDF의 기능 상태를 최신 엔진의 상태와 동일하게 보면 안 된다.