32GiB 호스트 메모리 안에서 30B MoE를 4비트로 압축하기

GPU 고대역폭 메모리보다 파드의 호스트 RAM이 먼저 바닥나는 상황을 겪어본 인프라 엔지니어라면, 이 논문이 정확히 그 지점을 다룬다는 걸 바로 알아볼 것입니다. ThakiCloud AI Research는 단일 NVIDIA H200 GPU와 32GiB 호스트 RAM만 있는 파드 위에서, 610억 파라미터급 체크포인트인 Qwen3-Coder-30B-A3B를 구조적으로 프루닝하고 4비트로 양자화한 실측 결과를 내놓았습니다. 대형 MoE(Mixture-of-Experts) 모델을 서빙 비용을 줄이려고 압축해야 하는데, 정작 압축 작업 자체가 메모리 부족으로 막히는 경험을 해본 분이라면 이 글이 바로 그 해법을 다룹니다.

문제의식: GPU가 아니라 압축 파이프라인 자체가 메모리에 막힌다

MoE 아키텍처는 각 토큰을 여러 전문가(expert) 서브네트워크 중 일부에만 라우팅해서, 전체 파라미터 수는 늘리면서도 토큰당 연산량은 낮게 유지합니다. 그런데 이 구조는 독특한 비용 문제를 만듭니다. 토큰당 연산은 가벼운데, 체크포인트 저장 용량과 메모리 풋프린트는 전체 파라미터 수에 비례해서 커진다는 점입니다. 지금까지 MoE 모델을 싸게 돌리려는 시도는 대부분 서빙 시점의 GPU 고대역폭 메모리 병목을 겨냥해왔습니다. 가중치를 저비트로 양자화하거나, 전문가 가중치를 스트리밍·오프로드해서 모든 전문가를 GPU에 상주시키지 않는 식입니다.

하지만 덜 논의되면서도 똑같이 까다로운 제약이 그보다 앞선 단계에 있습니다. 프루닝이나 양자화된 아티팩트를 만들어내야 하는 일회성 압축 파이프라인 자체가, 관례적으로 전체 체크포인트를 호스트 RAM(CPU 메모리)에 먼저 올려놓고 작업을 시작한다는 점입니다. Qwen3-Coder-30B-A3B처럼 디스크 용량이 61.0GB인 30B급 MoE 체크포인트라면, 이런 ‘로드 후 이동’ 방식은 최소한 그 크기만큼, 게다가 작업용 사본까지 더한 호스트 RAM을 요구합니다. 호스트 RAM 상한이 32GiB로 고정된 평범한 단일 GPU 파드에서는, 기반 모델 하나만으로도 이미 그 상한의 두 배 가까이 되기 때문에 이 설계는 구조적으로 아예 들어갈 수 없습니다.

이 논문이 던지는 질문은 명확합니다. 전체 모델을 CPU 메모리에 한 번도 통째로 올리지 않으면서, 30B급 MoE 모델을 구조적으로 프루닝하고 W4A16으로 양자화하는 작업을 고정된 소규모 호스트 RAM 예산 안에서 끝까지 해낼 수 있는가 하는 것입니다.

방법: 프로파일링, 선택, 샤드 스트리밍, 레이어별 양자화

저자들이 내놓은 답은 4단계 파이프라인입니다.

첫 단계인 프로파일링은 캘리브레이션 데이터로 전문가 중요도를 한 번만 점수화합니다. Qwen3-Coder-30B-A3B는 MoE 레이어 전체에 걸쳐 총 6144개의 전문가를 갖고 있고, 이 단계는 319만 4880개의 프로파일 행을 1017.7초에 걸쳐 처리합니다. 이 점수는 프루닝 비율과 무관하기 때문에 한 번만 계산해서 이후 네 개 변형 전체에 상각됩니다.

두 번째 선택 단계는 프로파일 점수를 바탕으로 몇 개의 전문가를 남길지 결정합니다. 저자들은 최적 비율 하나를 찾기보다, 10.16%부터 37.50%까지 프루닝 강도를 달리한 네 지점을 스윕했습니다.

가장 중요한 두 단계는 슬라이스와 양자화입니다. 슬라이스 단계는 전체 프루닝 안 된 체크포인트를 호스트 RAM에 올린 뒤 전문가를 제거하는 대신, 체크포인트를 샤드 단위로 읽어서 그 샤드에서 선택되지 않은 전문가를 버리고 곧바로 프루닝된 샤드를 써냅니다. 이 과정 어디에서도 61.0GB짜리 전체 모델이나 그 중간 사본이 호스트 RAM에 통째로 조립되는 순간이 없습니다. 양자화 단계도 마찬가지로, 스트리밍되는 각 샤드에 그룹 크기 128의 레이어별 RTN(round-to-nearest) W4A16 양자화를 곧바로 적용합니다. 슬라이스 단계에서 지킨 스트리밍 불변식이 양자화 단계에서도 그대로 유지되는 셈입니다. 결과적으로 파이프라인 전체의 최대 호스트 RAM 사용량은, 61.0GB짜리 기반 모델 크기가 아니라 활성 샤드 크기에 묶이도록 설계로 보장됩니다.

네 가지 프루닝 변형별 슬라이스·양자화 단계 소요 시간(H200 파드 실측). 양자화 시간은 프루닝이 강할수록 줄어들지만, 슬라이스 시간은 남긴 전문가 수에 단순 비례하지 않습니다.

결과: 네 변형 모두 성공, 3.6배에서 4.8배까지 압축

단일 H200 GPU, 32GiB 호스트 RAM 파드 위에서 네 가지 프루닝 강도로 실행한 결과, 네 변형 모두 실패 없이 양자화까지 완료됐습니다.

변형	프루닝 비율	남긴 전문가 수	아티팩트 크기	압축 배율	WikiText-2 PPL	Δ
keep115_lowmem	10.16%	5,520개	16.9GB	3.6배	9.402	+3.9%
keep102_lowmem	20.31%	4,896개	15.4GB	4.0배	10.021	+10.7%
keep90_lowmem	29.69%	4,320개	13.9GB	4.4배	10.7757	+19.0%
keep80_lowmem	37.50%	3,840개	12.7GB	4.8배	11.8132	+30.5%

기반 모델(bf16)의 WikiText-2 테스트셋(29만 6815토큰) 퍼플렉시티는 9.0524입니다. 아티팩트 크기는 프루닝 강도에 정확히 비례해 16.9GB에서 12.7GB까지, 61.0GB 기반 모델 대비 3.6배에서 4.8배 작아졌습니다. 흥미로운 점은 양자화 소요 시간과 슬라이스 소요 시간이 다르게 움직인다는 것입니다. 양자화 시간은 남길 전문가 수가 줄어들수록 267.7초에서 202~204초로 줄어드는데, 이는 양자화할 대상 자체가 줄어드니 자연스러운 결과입니다. 반면 슬라이스 시간은 422.3초, 613.2초, 546.0초, 483.6초로 프루닝 강도와 단조롭게 비례하지 않습니다. 저자들은 샤드 입출력과 캘리브레이션 부기 작업의 오버헤드가 남은 전문가 수에 선형으로 비례하지 않을 가능성을 조심스럽게 제시하면서도, 실제 원인을 프로파일링하지는 않았다고 정직하게 밝히고 있습니다.

Qwen3-Coder-30B-A3B-Instruct 네 변형 모두 61.0GB 기반 모델 대비 12.7GB~16.9GB, 3.6배~4.8배로 압축됐습니다(H200 파드 실측).

이 결과의 진짜 핵심은 크기나 시간이 아니라 호스트 RAM이 32GiB를 넘지 않았다는 시스템적 사실 그 자체입니다. 논문은 전체 모델을 먼저 메모리에 올리는 방식이라면 61.0GB에 작업 사본 오버헤드까지 더해져 32GiB 한도 안에 애초에 들어갈 수 없다는 점을 분석적으로 짚습니다. 이 naive 방식을 실제로 돌려 비교하지는 않았으므로 OOM이 났을 것이라는 실측 주장은 아니지만, 기반 모델 크기가 한도의 거의 두 배라는 사실만으로도 왜 샤드 스트리밍이 필요한지는 분명해집니다. 네 가지 변형 전부가 한도 아래에서 성공적으로 끝났다는 사실 자체가 이 설계가 실제로 작동한다는 경험적 증거입니다.

품질과 압축의 줄다리기: 10~20% 프루닝이 방어 가능한 스위트스팟

압축률만큼 중요한 건 품질 손실입니다. 네 변형의 WikiText-2 퍼플렉시티는 각각 +3.9%, +10.7%, +19.0%, +30.5%로, 프루닝 강도에 따라 단조롭게 나빠집니다. 그런데 그 나빠지는 속도가 일정하지 않다는 점이 눈에 띕니다. 프루닝 비율을 10.16%에서 20.31%로 두 배 늘리면 상대적 손실도 거의 두 배(+3.9%에서 +10.7%)가 되고, 가장 공격적인 두 지점(+19.0%, +30.5%)에서는 손실이 오히려 가속하는 모습을 보입니다. 다시 말해 프루닝을 더 세게 걸수록 한계 품질 비용이 점점 더 비싸지는, 초선형적인 악화 곡선입니다.

이 곡선이 주는 실무적 함의는 명확합니다. 품질을 중시하는 사용자라면 전문가의 10~20%만 제거해서 3.6배에서 4.0배 작은 아티팩트를 얻고 퍼플렉시티는 +3.9%에서 +10.7%만 감수하면 됩니다. 반대로 저장·메모리 예산이 더 급한 사용자라면 29.69%나 37.50%까지 밀어붙여 4.4배에서 4.8배 압축을 얻는 대신, 훨씬 큰 +19.0%에서 +30.5%의 품질 손실을 받아들여야 합니다.

다만 이 퍼플렉시티는 어디까지나 언어모델링 품질 신호이지, 코드 과제 정확도가 아닙니다. 기반 모델이 코더(Coder) 모델인데도 HumanEval이나 MBPP 같은 다운스트림 코드 벤치마크는 이 논문에서 측정하지 않았습니다. 10~20% 스위트스팟이 코드 생성 정확도에도 그대로 적용될지는 이 논문만으로는 알 수 없고, 저자들도 이를 향후 과제로 명시적으로 남겨두고 있습니다.

압축 배율이 커질수록 퍼플렉시티 악화는 초선형적으로 커집니다. 10~20% 프루닝 구간은 거의 손실이 없거나 완만하게만 나빠지는 방어 가능한 스위트스팟입니다.

이 결과가 남기는 것: 회사, 사회, 과학 세 층위

회사 관점에서는 ThakiCloud가 단일 H200, 32GiB 호스트 파드라는 평범한 자원만으로 30B급 MoE 모델(Qwen3-Coder-30B-A3B)을 12.7GB에서 16.9GB로 압축할 수 있다는 게 확인됐다는 점이 큽니다. 서빙에 필요한 메모리와 GPU 자원을 실제로 줄일 수 있는 근거가 생긴 셈입니다.

사회적으로 보면, 이 파이프라인은 DiEP·SHAPE류의 전문가 중요도 채점 방식과 표준적인 RTN W4A16 양자화를 조합했을 뿐, 독점적인 도구를 전혀 쓰지 않았습니다. 대형 MoE 저비트 압축을 재현하는 진입장벽을 낮췄다는 의미가 있고, 비슷한 제약(적은 호스트 RAM, 적은 예산) 아래에서 대형 모델을 다뤄야 하는 다른 팀에도 그대로 적용할 수 있는 레시피입니다.

과학적으로 가장 흥미로운 대목은, 샤드 단위 스트리밍 구현과 레이어별 RTN 양자화를 결합하면, 로드 후 이동 방식으로는 구조적으로 불가능한 고정된 소규모 호스트 RAM 상한 안에서도 대형 MoE의 W4A16 압축이 가능해진다는 걸 보여줬다는 점입니다. 서빙 시점에서만 논의되던 전문가 스트리밍·페이징 개념을, 압축 파이프라인 자체로 앞당겨 적용할 수 있다는 것을 실측으로 증명한 셈입니다.

한계: 코드 정확도, 라우터 보존 정제, 균일 프루닝은 아직 미검증

이 논문이 스스로 밝히는 한계도 분명합니다. 첫째, 앞서 말한 대로 코드 과제 정확도는 전혀 측정하지 않았습니다. 기반 모델의 실제 용도가 코드 생성이라는 점을 감안하면, 이 부분이 가장 중요한 남은 과제입니다. 둘째, 더 넓은 방법론에는 라우터 보존 정제(router-preserving refinement) 단계가 존재하지만, 이는 작은 합성 Qwen3-MoE 픽스처에서만 검증됐을 뿐 30B 규모에서는 검증되지 않았습니다. 이 논문이 보고하는 30B 수치는 그 정제 없이 순수 RTN W4A16만 적용한 결과입니다. 정제를 30B 규모에 적용했을 때 가장 손실이 큰 29.69%, 37.50% 구간에서 손실을 얼마나 회복할 수 있을지는 열린 질문입니다.

셋째, 레이어마다 다른 비율을 할당하는 대신 균일한 프루닝 비율을 전 레이어에 적용했습니다. 넷째, GPTQ나 AWQ 같은 캘리브레이션 기반 양자화 대신 가장 단순한 RTN을 썼습니다. 두 선택 모두 의도적인 단순화이고, 저자들은 이 지점을 향후 개선 여지로 명시하고 있습니다. 마지막으로 실험 대상은 H200 하나, 기반 모델 계열도 Qwen3-Coder-30B-A3B 하나뿐이라, 다른 가속기나 다른 MoE 계열로의 일반화는 아직 확인되지 않았습니다.

논문 원문과 상세 데이터는 Hugging Face에서 확인할 수 있습니다.

https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-30-moe-w4a16-pruned-30b-single-gpu