LLM 프루닝 보정을 디코딩 활성값으로 옮겨 생성 품질과 속도를 함께 잡는다
SparseDecoding: Decoding-Aware Pruning for Accurate and Efficient LLM Inference
무엇인가
LLM 추론에서 디코딩 단계는 메모리 바운드이고 전체 지연의 대부분을 차지한다. 가중치 프루닝은 메모리에서 읽는 비영(nonzero) 파라미터 수를 줄여 이 비용을 낮추는 접근인데, 학습이 필요 없는 OBS 계열 방법(SparseGPT 등)이 주류다. 문제는 이 계열이 보정(calibration)용 활성값을 C4 같은 미리 수집한 자연어 시퀀스에 teacher forcing으로 넣어 모은다는 점이다. 반면 실제 디코딩에서는 모델이 자기 생성 토큰을 입력으로 받는다. 두 시퀀스 사이에 분포 이동이 생기고, 자연어 시퀀스에서 계산한 헤시안 H = 2·X·X^T 는 생성 시퀀스에서 계산한 것과 달라진다. 논문은 이 불일치가 생성 중 활성 분포를 프루닝 시점과 어긋나게 만들어 프루닝 모델 성능을 떨어뜨린다고 관찰한다. 실측 그래프에서도 밀집 모델과 프루닝 모델의 상대 활성 불일치는 디코딩 초반에 급격히 커져, 모든 레이어가 12 디코딩 스텝 안에 최종 포화값의 90%에 도달한 뒤 그대로 유지된다. 시스템 쪽 문제도 있다. 실제 속도 향상을 내는 기존 프루닝 기법들은 대부분 희소 행렬-행렬 곱(SpMM)을 겨냥해, 디코딩을 지배하는 희소 행렬-벡터 곱(SpMV)은 지원이 제한적이다. 2:4 Sparse Tensor Core 경로는 프리필에서 1.31~1.46배 빨라지지만 디코딩에서는 밀집 실행의 0.85~0.87배로 오히려 느려진다.
어떻게 동작하나
알고리즘 축에서 SparseDecoding이 하는 일은 보정 행렬을 만드는 경로를 바꾸는 것이다. 대상 태스크에서 뽑은 보정 프롬프트 집합에 대해 고정 텍스트를 넣는 대신, 밀집 모델이 각 프롬프트의 이어짐을 스스로 생성하게 한다. 즉 매 스텝의 문맥이 모델 자신이 앞서 만든 출력으로 유도된다. 프롬프트 위치는 프리필 구간으로, 생성된 위치는 디코딩 구간으로 나눈 뒤, 프루닝 대상 선형 레이어마다 입력 활성값을 기록하되 디코딩 구간의 스텝만 남기고 프리필 구간의 활성값은 버린다. 이렇게 모은 활성값을 열로 쌓아 X_ℓ^AR 을 만들고, 레이어별 재구성 목적함수를 ‖(W_ℓ − Ŵ_ℓ)·X_ℓ^AR‖_F^2 로 정의한다. 이는 프롬프트별·디코딩 스텝별 제곱 오차의 합과 같다. 헤시안이 이제 생성 시점 활성값에서 나오므로, 어떤 가중치를 지우고 남은 가중치를 어떻게 보정할지가 실제 디코딩 상태에 맞춰진다. 프루닝 솔버 자체는 그대로 두고 보정 활성값만 바꾸는 구조라, SparseGPT나 Wanda 같은 기존 백엔드에 추가 학습 없이 얹을 수 있다.
무엇과 다른가
시스템 축에서는 N:M 반정형 희소성에 맞춘 SpMV 커널을 직접 설계한다. 첫째, 비영 가중치마다 32비트 열 인덱스를 따로 저장하는 대신 각 행의 희소 패턴을 비트마스크로 표현한다. 입력 열 하나당 1비트이고 32개 비트를 32비트 마스크 하나에 묶는다. 비영 가중치가 열 오름차순으로 저장되므로 마스크의 세트 비트가 저장된 가중치와 순서대로 대응해, 별도 인덱스나 로컬 오프셋이 필요 없다. 50% 희소성에서 비영 하나당 메타데이터가 2비트로, nmSPARSE의 int32 인덱스(32비트) 대비 16배, uint8 오프셋(8비트) 대비 4배 줄어든다. 둘째, 고정 스텝 순회다. 일반 희소 행렬은 행마다 비영 개수가 달라 순회 스텝 수가 제각각이지만, 50% N:M이고 M이 32 이하이면 정렬된 32비트 마스크마다 세트 비트가 정확히 16개다. 따라서 순회 스텝 수가 모든 행에서 동일하고 컴파일 시점에 알 수 있어 루프를 언롤할 수 있다. 각 스텝에서 최하위 세트 비트를 찾아 다음 비영의 열을 얻고 그 비트를 지우는 식으로 진행하며, 모든 행의 작업량이 같아 GPU 스레드 간 부하가 균일해진다.
어떻게 쓰나
실험은 A100 80GB에서 Llama-3.1-8B, Llama-3.3-70B, Qwen3-14B/32B 네 모델로 수행한다. 프루닝 백엔드가 지원하는 선형 레이어만 프루닝하고 나머지는 그대로 둔다. 벤치마크는 긴 출력 시나리오를 겨냥해 WritingBench(6개 도메인 100개 서브도메인, 1,000개 작문 프롬프트, 온도 0.7, top-k 20, top-p 0.8, 최대 16,000 토큰, DeepSeek-V4-Flash를 심사자로 사용, 1~10점)와 ClassEval(파이썬 클래스 생성 100개 과제, 410개 메서드, 클래스당 평균 33.1개 테스트, 클래스 수준 Pass@1)을 쓴다. 희소성 설정은 2:4, 8:16 N:M과 50% 비정형이며 모두 가중치의 50%를 남긴다. 보정은 C4 고정 텍스트와 SparseDecoding 두 가지로 비교하는데, 프롬프트는 작문 실험에 LongWriter, 코드 실험에 LiveCodeBench 문제 지문에서 가져온다. 양쪽 모두 100만 보정 토큰을 쓰되 SparseDecoding은 디코딩 스텝 토큰만 센다. 모델·프루닝 백엔드·잔존 가중치 비율을 고정한 비교다.
전제와 한계
결과는 일관되게 SparseDecoding이 앞선다. WritingBench에서 50% 비정형 기준 0.19~0.75점 향상, 2:4 기준으로 Llama-3.1-8B는 1.34에서 1.52로, Llama-3.3-70B는 3.10에서 3.29로 오른다. Qwen 모델의 상승폭이 특히 커서 Qwen3-14B는 1.85에서 4.18로, Qwen3-32B는 2.99에서 5.31로 뛴다. ClassEval에서는 8개 모델-희소성 조합 전부에서 4~15점 앞선다. 2:4에서 Qwen3-32B는 9.0%에서 24.0%로, Qwen3-14B는 0.0%에서 6.0%로, Llama-3.3-70B는 11.0%에서 15.0%로, Llama-3.1-8B는 0.0%에서 4.0%로 오른다. C4 보정이 Llama-3.1-8B와 Qwen3-14B에서 0.0%를 내던 것을 SparseDecoding이 0이 아닌 값으로 되살린 점이 눈에 띈다. 속도는 2:4부터 16:32까지 패턴을 바꿔도 처리량이 거의 동일하게 나오는데, 모두 가중치 50%를 남기고 같은 비트마스크 메타데이터를 쓰기 때문이다. Llama-3.1-8B 1.42배, Llama-3.3-70B 1.48배, Qwen3-14B 1.35배, Qwen3-32B 1.45배의 종단 간 디코딩 속도 향상을 보고한다. 절제 실험에서는 보정 토큰을 프루닝 대상 모델이 직접 생성하는 편이 다른 모델(32B가 만든 토큰으로 14B를 프루닝)을 쓰는 것보다 좋았고(2:4에서 4.18 대 4.13, 50% 비정형에서 5.35 대 5.23), 백엔드를 Wanda로 바꿔도 SparseDecoding이 C4보다 앞서 개선이 솔버 특정적이지 않음을 보인다.
개발자 관점에서 이 논문이 유효한 지점은 배치 1 또는 소배치로 긴 출력을 뽑는 서빙 환경이다. 이때 선형 레이어 연산은 GEMM보다 GEMV에 가까워 SpMV가 지배하고, cuSPARSELt 같은 SpMM 지향 라이브러리는 도움이 되지 않는다. 도입을 검토한다면 세 가지를 확인해야 한다. 첫째, 프루닝 백엔드가 N:M 패턴을 지원하는지, 그리고 그 백엔드에 디코딩 시점 활성값을 보정 행렬로 넘길 수 있는지. 둘째, 보정 비용이다. SparseDecoding은 프루닝 전에 밀집 모델을 대상 태스크 프롬프트로 자가회귀 생성시켜 100만 토큰 규모의 디코딩 활성값을 모아야 하므로, 모델과 태스크 도메인마다 이 비용이 반복된다. 셋째, 커널이 자체 구현이라는 점이다. 비트마스크 인덱싱과 고정 스텝 순회는 50% N:M, M≤32라는 조건에 기대고 있으므로 다른 희소성 비율이나 다른 하드웨어로 옮길 때 이득이 그대로 재현된다고 가정하면 안 된다.
논문이 제시한 범위에서 명시적인 한계 절은 확인되지 않지만, 전제는 분명하다. 프루닝은 백엔드가 지원하는 선형 레이어에만 적용되고, 보정 프롬프트는 대상 태스크에서 와야 하며(작문은 LongWriter, 코드는 LiveCodeBench 문제 지문), 보정 토큰은 프루닝 대상 모델이 직접 생성해야 한다. 고정 스텝 순회라는 커널 최적화는 50% N:M에 M≤32라는 조건에 의존한다. 실험은 A100 80GB와 GPT-Fast 프레임워크에서, 모델을 보정 후 한 번만 프루닝하는 설정으로, 비사고(non-thinking) 모드에서 수행됐다. 보고된 속도 향상은 최대 1.48배의 종단 간 wall-clock 디코딩 기준이며, 프리필 단계의 이득은 별도로 다루지 않는다.