상식을 깨는 주장: 4GB로 70B를?
Llama 70B급 대형 언어 모델을 돌리려면 보통 얼마나 필요할까요? FP16 정밀도 기준으로 파라미터를 담는 데만 140GB가 넘는 VRAM이 필요해요. A100 80GB 두 장, 돈으로 치면 수천만 원짜리 장비 얘기죠. 그런데 AirLLM이라는 오픈소스 프로젝트는 단 4GB VRAM의 GPU, 그러니까 몇 년 된 게이밍 노트북 수준의 장비로 70B 모델 추론이 가능하다고 해요. 그것도 양자화(모델 숫자의 정밀도를 낮춰 용량을 줄이는 압축 기법)나 지식 증류, 가지치기 없이 원본 모델 그대로요. 대체 어떻게 가능한 걸까요?
비결은 "한 번에 한 레이어씩"
이게 뭐냐면, 트랜스포머 모델의 구조적 특성을 역이용한 거예요. 70B 모델은 사실 80개 정도의 레이어(층)가 순서대로 쌓인 구조인데요, 추론할 때 데이터는 1번 레이어부터 마지막 레이어까지 차례대로 통과해요. 여기서 중요한 건, 3번 레이어를 계산하는 순간에는 1번과 2번 레이어의 파라미터가 전혀 필요 없다는 사실이에요.
AirLLM은 이 점을 파고들어요. 모델 전체를 VRAM에 올리는 대신, 디스크에서 레이어 하나만 읽어와 GPU에 올리고, 계산이 끝나면 바로 버리고, 다음 레이어를 로드하는 식으로 진행하거든요. 70B 모델도 레이어 하나만 떼어놓으면 1.6GB 정도라 4GB VRAM에 여유 있게 들어가요. 두꺼운 백과사전을 통째로 책상에 펼칠 필요 없이, 필요한 페이지만 한 장씩 넘겨 읽는 것과 같은 원리예요. 이를 위해 처음에 모델 파일을 레이어 단위로 쪼개 저장해두고(레이어 샤딩), safetensors 포맷으로 로딩 오버헤드를 줄이고, 플래시 어텐션 같은 메모리 최적화도 함께 적용해요. 원한다면 4비트/8비트 블록 압축을 켜서 로딩 속도를 몇 배 끌어올리는 옵션도 있고요.
물론 공짜 점심은 아니에요
눈치채셨겠지만 치명적인 트레이드오프가 있어요. 바로 속도예요. 토큰(모델이 생성하는 글자 조각) 하나를 만들 때마다 80개 레이어를 전부 디스크에서 다시 읽어와야 하거든요. GPU 연산이 아니라 디스크 입출력이 병목이 되면서, 토큰 하나 생성에 수 초씩 걸릴 수 있어요. 문장 하나 뽑는 데 몇 분이 걸리는 셈이라, 실시간 챗봇 용도로는 사실상 쓸 수 없어요. 대신 시간이 걸려도 되는 배치 작업, 예를 들어 밤새 돌려두는 데이터 라벨링이나 대형 모델의 출력 품질을 미리 검증해보는 실험에는 충분히 의미가 있죠.
업계 맥락: 저사양 추론의 여러 갈래
적은 자원으로 큰 모델을 돌리려는 시도는 AirLLM만이 아니에요. 가장 대중적인 건 llama.cpp 진영의 GGUF 양자화인데, 70B를 4비트로 압축하면 40GB 안팎까지 줄어서 고사양 맥이나 CPU+램 조합으로 돌릴 수 있어요. 다만 압축 과정에서 미세한 품질 손실이 생기죠. 연구 쪽에서는 FlexGen이나 DeepSpeed의 ZeRO-Inference처럼 GPU-CPU-디스크에 걸쳐 파라미터를 나눠 싣는 오프로딩 접근이 있었고, AirLLM은 그 아이디어를 "디스크에서 레이어 스트리밍"이라는 극단까지 밀어붙인 쪽이에요. 정리하면 양자화는 "품질을 조금 내주고 속도를 얻는" 길이고, AirLLM 방식은 "속도를 내주고 원본 정밀도를 지키는" 길이라고 볼 수 있어요.
한국 개발자에게 주는 시사점
고가 GPU 없이도 70B급 모델이 내 데이터에서 어떤 답을 내놓는지 직접 확인해볼 수 있다는 게 제일 커요. API 비용 부담 없이 로컬에서 대형 모델을 실험해보고, 그 결과를 보고 양자화 모델이나 클라우드 도입을 결정하는 사전 검증 도구로 쓰기 좋거든요. 파이썬 코드 몇 줄이면 시작할 수 있어서 진입장벽도 낮아요. 다만 응답 속도 때문에 실서비스에 붙일 물건은 아니라는 점만 분명히 하면 돼요.
마무리
"큰 모델 = 큰 GPU"라는 공식이 절대적이지 않다는 걸 보여준 재미있는 프로젝트예요. 메모리와 속도는 결국 서로 맞바꿀 수 있는 자원이라는, 시스템 설계의 오래된 교훈이기도 하고요. 여러분이라면 느리지만 원본 그대로인 AirLLM과 빠르지만 살짝 압축된 양자화 모델, 어느 쪽을 선택하시겠어요?
🔗 출처: Hacker News