모바일 GPU에서 저비트 LLM 디코딩의 형변환과 KV 캐시 병목을 숨긴 BitLLM

무엇인가

이 논문은 모바일 GPU에서 저비트 LLM 디코딩이 왜 기대만큼 빠르지 않은지를 다룬다. LLM은 파라미터·토큰당 연산·KV 캐시 메모리 대역폭 요구가 커서 모바일의 연산·메모리 예산을 압박한다. 4비트 가중치·8비트 활성화 같은 양자화는 모델을 줄이지만, 모바일 GPU는 서버 GPU의 INT4/INT8 텐서코어 같은 네이티브 저비트 경로가 없다. 저자들은 OnePlus 12에서 MNN-LLM으로 FP16/INT8 CPU·GPU 지연을 프로파일링해, Snapdragon 8 Gen 3 GPU의 INT8 추론이 FP16보다 최대 2배 느리고 같은 SoC의 CPU INT8은 2배 빠르다는 결과를 제시한다. 32비트 워드에서 INT4 8개를 꺼내려면 약 16회 시프트와 16회 마스크가 필요해, 8회 곱셈과 7회 덧셈으로 끝나는 점곱 연산보다 비쌀 수 있다. 여기에 자기회귀 디코딩 중 KV 캐시가 커지면서 모바일 GPU의 2D 텍스처·RGBA 메모리 구조에 맞는 최적 레이아웃이 sequence length에 따라 바뀌고, 고정 레이아웃은 비정렬 접근과 주기적 지연 스파이크를 만든다. T-MAC·BitNet.cpp의 CPU 테이블 룩업이나 T-MAN의 NPU 정적 레이아웃은 GPU의 2D 텍스처 메모리 계층을 활용하기 어렵다.

어떻게 동작하나

BitLLM은 이를 커널 하나의 문제가 아니라 레이아웃·패킹·실행 파이프라인의 공동 문제로 정식화한다. 레이아웃 설정 L=(π,ρ,φ)에서 π는 어떤 축을 stride-1로 둘지, ρ는 2D 텍스처의 행·열 배치, φ는 4/8비트 값을 워드나 RGBA 레인에 어떻게 패킹할지를 뜻한다. 비용 모델 LEP는 α1·Bytes(π,ρ,φ,t)/BW_tex + α2·UnpackOps(φ)로, 데이터 접근 비용과 언패킹 비용을 가중 합한다. Bytes는 캐시 라인·뱅크 충돌을 고려한 분석 모델로, UnpackOps는 패킹 스킴별 커널을 정적 분석해 시프트·마스크 등 정수/비트 연산 수를 세어 구한다. α1, α2는 GPU별 오프라인 마이크로벤치마크로 한 번 보정하며 10분 미만이 걸리고 모델과 무관하다. 평가 GPU에서는 α1=0.5, α2=0.7이 최선이었다. 모든 후보의 Bytes와 UnpackOps를 오프라인에서 미리 계산해 두고, 런타임에는 가중 합만으로 수 마이크로초 안에 레이아웃을 고른다.

무엇과 다른가

디코딩 중에는 sequence length에 따라 레이아웃을 바꾼다. 짧은 문맥(예: 256 미만)은 QK^T가 지배해 D-contiguous 레이아웃이 유리하고, 긴 문맥(예: 512 초과)은 SV가 지배해 T-contiguous 레이아웃이 유리하다. BitLLM은 주기적으로 후보 레이아웃의 LEP를 평가해 더 나은 경우에만 전환하는 greedy 전략을 쓴다. 텍스처 차원 제한(각 차원 16K 픽셀 이하) 때문에 접기가 필요하면 연산의 reduction 축이 아닌 축으로만 접는다. QK^T는 D로 reduction하므로 T 축으로, SV는 T로 reduction하므로 D 축으로 접어 reduction 축의 stride-1 접근을 보존한다. 전환 비용은 append-only 세그먼트로 숨긴다. KV 캐시를 불변 세그먼트로 나누고 새 레이아웃이 필요하면 새 토큰만 새 세그먼트에 append하며, 기존 세그먼트는 복사·재배치하지 않는다. 짧은 변동으로 계속 쪼개지지 않도록 개선이 충분한 길이 동안 지속될 때만 전환하는 phase-aware 휴리스틱을 적용한다. 10K 토큰 실행에서 평균 2.25개, 최대 5개 세그먼트가 생기고 분할 오버헤드는 전체 디코딩 지연의 1% 미만이었다.

어떻게 쓰나

양자화 패킹은 하드웨어가 바로 먹을 수 있는 형태로 바꾼다. 모바일 GPU의 dp4a·udot8은 INT8 쌍을 곱해 INT32에 누적하는 네이티브 정수 점곱 명령을 제공하므로, 피연산자를 특정 32비트 벡터 레이아웃으로 패킹해야 한다. INT4를 단순히 연속으로 32비트 워드에 넣으면 8개 값이 바이트 경계를 넘어 각 값을 꺼내 INT8로 확장해야 한다. 저자들은 패킹을 스케줄 가능한 차원으로 보고 구조화 패킹 계열을 제안한다. contiguous-in-byte는 저장 밀도가 가장 높지만 4워드 벡터에서 값을 꺼내는 데 약 31회 시프트와 31회 마스크가 들어 언패킹 비용이 가장 크고, lane-interleaved 패킹은 니블을 재배열해 각 바이트에 정렬된 INT4 두 개를 담는다. 이와 함께 integer-native 실행 파이프라인이 형변환을 compute hot path 밖으로 지연·중첩하고 핵심 MatMul 단계는 정수 영역에 유지한다. 논문은 이 조합으로 언패킹 명령을 약 80% 줄였다고 보고한다.

전제와 한계

실험은 GQA와 MHA를 포함한 Llama-3.2, Qwen3, Gemma-2, Phi-2를 FP16, W8A8, W4A8에서 평가한다. 베이스라인은 LLAMA.CPP, MNN-LLM, LiteRT-LM, MLC-LLM이다. 여러 모델·양자화 수준 평균으로 BitLLM은 각각 1.78배, 1.73배, 1.58배, 1.47배 빠르다. 긴 문맥 생성에서는 토큰당 평균 에너지를 최대 88.9% 줄였고, 최신 베이스라인 대비 평균 토큰당 에너지 56~76% 절감을 보고한다. KV 캐시가 커질 때 다른 프레임워크에서 나타나는 지연 스파이크도 제거했다고 주장한다. 추가 분석에서는 W8A8 최대 18.6%, W4A8 최대 7.9% 개선이 언패킹 명령 약 80% 감소와 형변환 은닉에서 나온다고 설명한다.

LEP의 선택 품질과 이식성도 수치로 제시된다. 세 모바일 GPU에서 모든 후보를 벤치마크하는 oracle search는 1413.6~2747.3초 걸리지만, LEP는 45.5~95.2밀리초로 네 자릿수 이상 빠르게 레이아웃을 고른다. 선택된 레이아웃은 oracle 대비 평균 1.86~3.89%, P95 5.83~10.40% 느린 수준이다. α 값을 크게 바꿔도 성능 저하는 약 10~15%에 그친다. OnePlus 11과 Pixel 8에서는 Llama-3.2-1B와 Qwen3-1.7B를 FP16/W8A8/W4A8, P-O=512-512로 실행해 저비트에서 OnePlus 11 1.3~2.9배, Pixel 8 1.4~3.6배(평균 1.7배 대 1.9배) 속도를 보고한다. FP16에서도 1.1~2.1배, 1.1~3.6배로 적응형 레이아웃 자체의 효과가 있다고 본다.

개발자에게 이 논문은 온디바이스 LLM에서 4/8비트 커널만 교체하는 접근이 왜 한계인지 보여준다. 모바일 GPU에서는 양자화 해제와 형변환, KV 캐시 레이아웃이 같은 critical path에서 얽히므로, 런타임이 sequence length에 따라 레이아웃과 패킹을 바꾸고 전환 비용을 세그먼트로 숨기는 설계가 필요하다. 긴 문맥·에너지 제약·다양한 모바일 GPU를 다루는 서비스라면 벤치마크 시 모델·정밀도뿐 아니라 group size, GPU별 LEP 가중치 보정, KV 캐시 세그먼트 수, 전환 임계값을 함께 확인해야 한다. 반대로 짧은 문맥 위주이거나 CPU/NPU 경로가 중심인 서비스에는 그대로 적용된다고 보기 어렵다.

저자들이 밝힌 전제는 분명하다. 현재 구현은 2D 텍스처·RGBA 접근, GPU 지향 패킹, 저비트 점곱 명령을 가정하고 W8A8/W4A8, group size 32를 평가한다. 2비트 같은 공격적 포맷은 정확도 손실 때문에 대상에서 제외했다. CPU·GPU·NPU가 섞인 SoC로 확장하려면 백엔드별 레이아웃·메모리 모델·명령 집합이 필요하고, 백엔드 전환 비용 T_trans를 LEP에 더하는 확장이 과제로 남는다. 동시 워크로드가 있으면 오프라인 보정한 대역폭·가중치가 최적이 아닐 수 있어 contention-aware 보정도 미래 작업이다. paged KV 캐시나 speculative decoding은 세그먼트·KV 상태 관리가 추가로 필요해 통합을 future work로 남겼다. 또한 이 본문에 인용된 결과는 지연시간·에너지·레이아웃 선택 품질 중심이며, 정확도 손실에 대한 정량 표는 제시되지 않았다.