VRAM의 2비트 복사본과 시스템 RAM의 정확한 잔차를 검증자로 활용하는 기법: GPU에 맞지 않는 모델을 위한 추측 디코딩
원문 제목 — 2-bit copy in VRAM + exact residual in system RAM as the verifier: speculative decoding for models that don't fit your GPU
📄 전문 번역
레딧 사용자 Happy_Guitar3521이 GPU에 모델이 다 들어가지 않는 상황을 위한 추측 디코딩 기법을 공유했다. 최근 연구 개발을 진행했지만 자녀 양육과 업무 등으로 아이디어를 더 발전시킬 시간이 없다고 밝혔다. 거대한 성과는 아니더라도 일부 사례에 활용할 수 있는 흥미로운 접근법이라고 보며, AI 슬롭(AI slop)이 아니라고 강조했다. 해당 정보를 활용해 Claude나 Astra로 직접 시도해 볼 수 있다고 했다. 아이디어는 전적으로 본인 것이며 LLM과 무관한 상용 앱에 적용해 많은 비용을 절감했다고 밝혔다. 오래된 아이디어인지는 확실하지 않지만 MTP와도 함께 동작할 수 있으며, 무례한 반응은 자제해 달라고 부탁하며 누구나 실험해 보기를 환영한다고 덧붙였다.
핵심 아이디어는 GPU에 모델의 2비트 버전을 두고 나머지 가중치인 6~8비트 잔차를 시스템 RAM에 보관하는 것이다. 2비트 복사본이 토큰을 초안 생성하면 전체 모델이 이를 검증하며, GPU는 2비트 부분을, CPU는 잔차 부분을 담당하고 활성화 값만 PCIe를 통해 오간다. 초안 생성에 추가 메모리가 전혀 들지 않으며, 사실상 검증자의 절반이라는 설명이다.
실제 가중치를 역양자화해 PyTorch로 실행해 측정했으며 아직 토큰/초 속도는 측정하지 않았다고 밝혔다. 2비트와 8비트 잔차 조합은 Q8_0보다 bf16에 더 가깝고 KL 발산은 약 절반이다. 6비트 잔차를 사용하면 Q8_0 수준 품질을 유지하면서 RAM에서 읽는 바이트 수를 약 28% 줄일 수 있다. 검증자의 KV 캐시를 재사용하는 2비트 드래프터는 구글 공식 Gemma 4 드래프터보다 검증 1회당 수용 토큰 수가 25~30% 많았다(31B, 16노드 트리 기준 5.23 대 4.20). CPU 커널은 메모리 바운드라서 16개 토큰을 검증하는 시간이 1개 토큰과 거의 같다고 한다.
구현과 초기 테스트 이후 찾은 가장 유사한 연구는 SubSpec이지만, 이는 비트별로 모델을 분할하는 대신 별도의 4비트 복사본을 사용하고 PCIe로 가중치를 스트리밍한다고 설명했다. 이 기법은 Q8_0이 VRAM에 맞지 않을 때만 의미가 있으며, 맞는다면 llama.cpp를 쓰면 된다는 입장이다. 허깅페이스에 공개 저장소를 올렸으며 누군가의 연구에 도움이 되기를 바란다고 덧붙였다.
프론티어급 LLM을 높은 추론 노력 설정으로 활용해 이 기법을 분석해 보면 더 깊은 통찰을 얻을 수 있다고 제안했다. 이 아이디어에는 잠재력이 있다고 확신한다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
레딧 사용자가 VRAM에는 모델의 2비트 복사본을, 시스템 RAM에는 6~8비트 잔차 가중치를 배치해 GPU와 CPU가 협업하는 추측 디코딩 기법을 공개했다. 2비트 복사본이 토큰을 초안 생성하고 CPU가 잔차로 검증하며 활성화 값만 PCIe로 오가기 때문에 초안 생성에 추가 VRAM이 필요 없다는 것이 핵심이다. 실측에서 6비트 잔차로 Q8_0 수준 품질을 유지하며 RAM 읽기를 약 28% 줄였고, KV 캐시를 재사용하는 2비트 드래프터가 구글 공식 Gemma 4 드래프터보다 수용 토큰이 25~30% 많았다. 다만 Q8_0이 VRAM에 들어가는 경우에는 llama.cpp를 쓰는 것이 낫다고 작성자 자신이 밝혔다.
— 루키 · glm-5.3-flash:cloud
이건 신선한 거 아닌가? 이런 걸 다룬 글을 본 적이 없는데.
구현과 첫 테스트 이후 찾은 가장 유사한 연구는 arXiv 논문 2509.18344다. 하지만 내 아이디어는 여전히 접근 방식에서 몇 가지 차이가 있다.
어떤 논문에서 2비트 양자화를 사용해 어떤 MoE 전문가를 핫캐시로 프리페치할지 예측한 적이 있으니, 아주아주 약간 비슷하긴 하다.
연구자에게 연락해 봐라. 논문 공로를 인정받을 수도 있다. 아니면 arXiv에 직접 게시할 수 있는지 알아보라.
내 자신을 연구자라고 부르기는 어렵다. 아니, 정확히는 연구자이긴 하지만 비공식적인 의미에서다. LLM과 관련 없는 상용 애플리케이션을 위한 것이지만 흥미로운 진전을 만들고 있다. 2년 넘게 지속 최적화를 연구하며 개발한 솔루션 중 일부가 LLM에도 적용될 수 있겠다는 생각이 들었다. 이 아이디어는 그런 사례 중 하나로, 비싼 RAM과 VRAM 비용 때문에 큰돈을 아껴준다. 유용하다고 생각하는 사람은 언제든 연락하기 바란다.