125B를 24GB에 넣은 게 아닙니다: 4090 한 장 기록을 정확히 읽는 법
로컬에서 큰 모델을 돌리려다 VRAM 앞에서 포기해 본 적이 있다면, 이 글은 그 계산을 다시 하게 만들 겁니다. RTX 4090 한 장에서 111GB짜리 모델을 250,000 컨텍스트로 돌렸다는 기록이 최근 공유됐고, 숫자는 원본 자료로 확인해 보니 대부분 사실이었습니다. 다만 그 기록에 붙은 “VRAM 장벽이 죽었다”는 결론은 사실이 아닙니다.
정확한 문장은 이렇습니다. 111GB 양자화 모델의 대부분을 110GB 시스템 RAM에 두고, GPU에는 어텐션과 KV 캐시만 남겨서, 단일 사용자 기준 약 21 tok/s로 돌렸습니다. 24GB VRAM과 110GB DDR4를 하나의 계층형 메모리로 쓴 것이 핵심입니다. 장벽은 사라지지 않았고 GPU에서 시스템 RAM으로 옮겨갔습니다.
그런데 이 구분을 하고 나서도 결과는 여전히 중요합니다. 어떤 모델 구조가 이걸 가능하게 했는지가 앞으로의 서빙 설계에 직접 영향을 주기 때문입니다.
글의 핵심 개념을 형상화했습니다.
무엇이 실제로 실행됐나
대상은 Qwen3.8-Flash-Next이고 흔한 125B 밀집 모델이 아닙니다. 공식 모델 카드는 이 모델을 “125B with 6B activated, plus 51B n-gram embedding and 4B MTP”로 적고 있습니다. 언어모델 본체가 125B인데 토큰 하나를 만들 때 실제로 켜지는 부분은 약 6B이고, 그와 별도로 51B 규모의 n-gram 임베딩과 4B MTP 계층이 붙어 있는 구조입니다.
사용된 파일은 Unsloth의 UD-Q4_K_XL GGUF 4샤드이고 실제 크기를 확인해 보니 10.9MB, 49.9GB, 49.4GB, 12.1GB로 합계 약 111.4GB였습니다. 원 기록의 111GB와 맞습니다.
실행 환경은 Ubuntu 22, CUDA 13.0, PCIe 4.0 x16, DDR4 110GB였고, llama.cpp 본체가 아닌 아직 병합되지 않은 PR에서 빌드해야 합니다. 이 부분은 확인이 필요해서 직접 조회했는데, PR #27742는 2026년 8월 26일에 열렸고 지금도 open 상태입니다. 즉, 이 실행 경로는 아직 master에 없습니다.
왜 111GB가 24GB 카드에서 도는가
세 가지 구조가 겹쳐서 만든 결과이고 셋 중 하나라도 빠지면 성립하지 않습니다.
첫째는 초희소 MoE입니다. 이 모델의 각 MoE 계층에는 전문가가 512개 있지만 토큰마다 routed 10개와 shared 1개만 사용합니다. 밀집 125B라면 토큰 하나에 거의 모든 파라미터를 훑어야 하지만 여기서는 대부분의 전문가 가중치가 대기 상태입니다. 대기 중인 가중치는 느린 메모리에 있어도 됩니다. 항상 쓰이는 어텐션과 공통 계층만 GPU에 남기고 나머지를 시스템 RAM으로 밀어내는 분할이 여기서 나옵니다.
둘째는 어텐션 구조입니다. 48개 계층이 균일하지 않습니다. 공식 카드의 표기를 그대로 옮기면 12 × (3 × (Gated DeltaNet → MoE) → 1 × (Qwen Sparse Attention → MoE))이고, 계산하면 36개 계층이 선형 어텐션이고 12개만 희소 어텐션입니다. 일반적인 full attention 모델처럼 모든 계층에서 컨텍스트 길이에 비례하는 KV 캐시를 만들지 않습니다. 게다가 QSA는 어텐션 헤드가 Q 24개에 KV 2개뿐이고 예산이 2,048토큰으로 묶여 있습니다. 긴 컨텍스트의 메모리 비용이 낮은 이유가 이 두 가지입니다.
셋째는 n-gram 임베딩의 성질입니다. 51B라는 숫자만 보면 무겁게 느껴지지만, 현재 bigram과 trigram에 해당하는 몇 개 행만 꺼내 쓰는 조회 테이블입니다. llama.cpp PR 설명도 97.7GiB 크기의 n-gram 해시 테이블을 host 쪽 행 인덱스로 받아 ggml_get_rows로 가져온다고 적고 있습니다. 파라미터 수 대비 실제 전송량과 계산량이 훨씬 작습니다.
flowchart TB
subgraph GPU["GPU · RTX 4090 (VRAM 18.3GB, 250K 예약 기준)"]
AT["어텐션 계층: DeltaNet 36 + QSA 12<br/>KV 헤드 2개, 컨텍스트 토큰당 약 39KB"]
AC["활성 가중치: 공통 계층 + MTP 4B"]
end
subgraph RAM["시스템 RAM · DDR4 110GB"]
EX["MoE 전문가 가중치<br/>111GB GGUF의 대부분<br/>512개/층, 매 토큰 활성 11개 (routed 10 + shared 1)"]
NG["n-gram 임베딩 51B<br/>97.7GiB 조회 테이블, ggml_get_rows로 필요한 행만 가져옴"]
end
TOK["토큰 스트림"] --> AT
AT --> AC
AC -->|"매 토큰 활성 11개 전문가만 PCIe 4.0 경유"| EX
EX --> AC
NG -.->|"bigram / trigram 행 조회"| TOK
숫자를 어떻게 읽나
원 기록의 네 가지 구성입니다.
| 구성 | 컨텍스트 예약 | Prefill | Decode | VRAM | RAM |
|---|---|---|---|---|---|
-ncmoe 40 |
80K | 383.85 tok/s | 22.52 tok/s | 23.85GB | 97GB |
-cmoe |
80K | 355.72 tok/s | 20.84 tok/s | 11.66GB | 110GB |
-cmoe |
180K | 357.75 tok/s | 20.98 tok/s | 15.6GB | 110GB |
-cmoe |
250K | 364.29 tok/s | 20.97 tok/s | 18.3GB | 110GB |
여기서 진짜 놀라운 자리는 첫 두 줄의 차이입니다. 전문가를 전부 CPU로 내리자 VRAM이 23.85GB에서 11.66GB로 절반 아래로 떨어졌는데 생성 속도는 22.52에서 20.84로 7.5퍼센트만 느려졌습니다. 전문가 가중치가 대기 상태라는 앞의 설명이 실측으로 확인된 셈입니다.
컨텍스트를 늘리는 비용도 작습니다. 80K에서 250K로 예약량을 17만 토큰 늘렸는데 VRAM은 6.64GB만 늘었습니다. 토큰당 39KB 정도인데, 선형 어텐션 36계층과 KV 헤드 2개짜리 QSA 12계층이라는 구조를 생각하면 납득이 갑니다. 그리고 250K는 이 모델의 네이티브 한계인 262,144 안쪽이므로 YaRN으로 억지로 늘린 수치도 아닙니다.
한 가지 자주 오해되는 플래그가 있습니다. 원 기록은 -ncmoe 40을 “40개 전문가 계층을 GPU로 오프로드”라고 적었는데, 실제 의미는 반대입니다. 40개 계층의 MoE 전문가를 CPU에 남긴다는 뜻이고 48계층 중 나머지 8계층의 전문가만 GPU에 올라갑니다. -cmoe는 그걸 전 계층으로 확장한 것입니다. “512개 전문가 계층”이라는 표현도 정확하지 않습니다. 계층은 48개이고 각 MoE 계층마다 전문가가 512개입니다.
250K는 아직 예약이지 실사용이 아닙니다
여기가 이 기록에서 가장 조심해야 할 대목입니다. 원 기록은 모든 실행에서 지속적으로 28K 프롬프트를 사용했다고 스스로 밝히고 있습니다. 그러니까 검증된 것은 “250K 컨텍스트 슬롯을 할당한 서버가 28K 프롬프트를 처리했다”입니다.
아직 확인되지 않은 것들이 남습니다. 실제 250K 토큰을 끝까지 prefill했을 때도 364 tok/s가 유지되는지, 250K 위치에서 needle retrieval이 살아 있는지, 장문 추론 정확도가 유지되는지, 반복 처리해도 안정적인지는 이 기록만으로 알 수 없습니다.
Prefill 속도를 그대로 대입해 보면 왜 이게 중요한지 보입니다. 28K 프롬프트를 364 tok/s로 읽는 데도 약 77초가 걸립니다. 같은 속도가 유지된다고 가정하면 80K는 약 3.7분, 180K는 약 8.2분, 250K는 약 11.4분입니다. 캐시 재사용이 없는 신규 250K 요청이라면 첫 토큰까지 10분 넘게 기다리는 시스템이라는 뜻입니다.
Decode 21 tok/s는 다르게 읽어야 합니다. 토큰당 약 48ms이니 1,000토큰 답변에 48초 정도이고 채팅이나 코드 생성에는 충분히 쓸 만합니다. 이 기록의 진짜 성과는 생성 속도이지 첫 응답 속도가 아닙니다.
MTP도 dflash도 KV 캐시 양자화도 쓰지 않았다는 단서가 붙어 있는데, 겸손이 아니라 오히려 강한 주장입니다. 여러 토큰을 한 번에 예측해 채택하거나 draft 모델로 부풀린 수치가 아니라 기본 autoregressive 디코드 성능이라는 뜻이기 때문입니다. 같은 이유로 speculative decoding으로 측정한 수백 tok/s급 수치와 이 21 tok/s를 나란히 놓고 비교하면 안 됩니다. 재는 대상이 다릅니다.
장벽은 죽지 않았고 자리를 옮겼습니다
이 구성이 실제로 요구하는 것은 VRAM 18.3GB와 시스템 RAM 약 110GB, 그리고 디스크의 모델 파일 111GB입니다. 합치면 128GB 이상의 빠른 메모리와 저장소를 갖춘 워크스테이션입니다. 24GB만으로 실행한 것이 아닙니다.
병목은 이렇게 이동했습니다. GPU VRAM 용량에서 시스템 RAM 용량으로, 다시 RAM 대역폭과 CPU 성능으로, 마지막으로 긴 prefill과 첫 토큰 대기시간으로 갑니다. 특히 CPU 모델과 메모리 채널 수, DDR4 속도가 공개되지 않았기 때문에 평범한 듀얼채널 데스크톱에서 21 tok/s가 그대로 재현된다고 보기 어렵습니다. 전문가 가중치를 RAM에서 끌어오는 구조라 메모리 대역폭이 곧 생성 속도입니다.
“프로덕션급 125B 서빙”이라는 표현도 아직 이릅니다. 동시 요청 수와 총 처리량, p95와 p99 지연, 수시간 연속 부하에서의 안정성, 4비트 양자화의 품질 저하, prompt caching 효과가 전부 공개되지 않았습니다. 지금 단계에서 정확한 이름은 상당히 인상적인 단일 사용자 로컬 추론 실증입니다.
그러면 27B 밀집 모델보다 나은가
기준에 따라 다릅니다. 공식 벤치마크에서 Flash-Next는 Qwen3.8-27B를 대체로 앞섭니다. DeepSWE 1.1이 58.7 대 42.2, SWE-bench Pro가 62.5 대 61.7, SWE-bench Multilingual이 81.0 대 73.8, JobBench가 55.7 대 33.4입니다. 다만 이건 Qwen 측 자체 벤치마크이고 UD-Q4_K_XL로 양자화한 상태의 품질을 따로 측정한 결과는 아닙니다.
실용 관점에서는 세 갈래로 나뉩니다. 일반적인 로컬 코딩과 채팅이라면 27B 밀집 모델이 여전히 설치가 쉽고 빠릅니다. 27B보다 높은 품질이 필요하고 100K에서 250K 구간의 장문을 다뤄야 하며 RAM이 넉넉한 워크스테이션이 있다면 Flash-Next가 흥미로운 선택입니다. 다중 사용자 프로덕션이라면 둘 다 llama.cpp 단일 노드보다는 vLLM이나 SGLang 기반 GPU 서버가 맞습니다.
ThakiCloud 관점
우리가 이 결과에서 가져갈 것은 서빙 프로파일이 하나 더 생겼다는 사실입니다.
Metis 추론 관점에서 이 구성은 새로운 티어를 시사합니다. 지금까지 서빙 설계는 모델이 VRAM에 들어가느냐를 이분법으로 물었는데, 초희소 MoE에서는 어텐션과 KV는 GPU에, 전문가 가중치는 CPU 메모리에 두는 배치가 실측으로 성립합니다. VRAM 절반을 내주고 생성 속도를 7.5퍼센트만 잃는 교환이라면, 동시성이 낮고 품질과 컨텍스트 길이가 중요한 워크로드에는 유효한 선택지입니다. 다만 이 프로파일은 첫 토큰 대기시간을 희생하므로 대화형 SLA에는 맞지 않고, 배치 분석이나 긴 문서를 한 번 읽고 오래 답하는 형태에 맞습니다.
Aegis 온프렘 관점에서는 진입 비용의 모양이 바뀝니다. 폐쇄망에 고품질 모델을 넣어야 하는데 데이터센터 GPU 예산이 안 나오는 상황에서, 고용량 RAM 워크스테이션이 현실적인 대안이 될 수 있습니다. 단일 사용자 또는 소수 사용자 기준이라는 전제는 분명히 해야 합니다.
우리 쪽에서 확인이 필요한 것도 분명합니다. 저 21 tok/s가 어떤 CPU와 몇 채널 메모리에서 나온 값인지 모르는 상태이고, 4비트 양자화 품질을 우리 평가셋으로 재보지 않았습니다. 도입을 논하기 전에 이 둘을 우리 하드웨어에서 직접 측정하는 것이 순서입니다.
재현하려면
llama.cpp master에는 아직 이 아키텍처가 없습니다. PR #27742 브랜치에서 빌드해야 하고 그 PR은 2026년 8월 26일에 열려 아직 병합되지 않았습니다. 실험적 브랜치를 프로덕션 경로에 넣지 않는 것이 좋습니다.
플래그 중에서는 -b 4096 -ub 4096이 가장 큰 차이를 만듭니다. 원 기록은 이 설정으로 프롬프트 처리 속도가 약 150에서 364 tok/s로 두 배 이상 올랐다고 적었습니다. 배치와 마이크로배치 크기를 키워 GPU 병렬성을 확보하는 것인데, 메모리 사용량이 함께 늘기 때문에 GPU와 CPU 조합에 따라 그대로 재현되지 않을 수 있습니다.
정리하면 이 기록은 “그냥 돌아갔다”보다 훨씬 중요합니다. 초희소 MoE와 선형 어텐션, RAM 오프로드를 결합하면 대규모 모델의 단일 사용자 추론에서 비싼 VRAM을 값싼 시스템 RAM으로 상당 부분 대체할 수 있다는 것을 보여줬습니다. 다만 그 문장을 “VRAM 장벽이 죽었다”로 줄이면 무엇을 사고 무엇을 잃었는지가 지워집니다. 산 것은 VRAM이고 낸 것은 RAM 용량과 대역폭, 그리고 첫 토큰까지의 시간입니다.