AirLLM 딥다이브
— 4GB 그래픽카드로 70B 거대 모델을 돌리는 '레이어 한 겹씩 흘려보내기' 마술

1프로젝트 한줄 요약

한 문장으로 이 프로젝트가 뭘 하는지부터.

AirLLM = "VRAM이 모델 전체를 담지 못해도, 모델을 한 겹씩 디스크에서 꺼내 계산하며 추론을 끝까지 마치게 해 주는 메모리 절약 추론 엔진". 보통 70B 모델을 16비트로 돌리려면 약 140GB의 VRAM이 필요하다 — A100(80GB) 두 장이 있어야 한다는 뜻이다. AirLLM은 발상을 뒤집는다: "어차피 한 순간에 계산되는 건 신경망의 '한 층'뿐인데, 왜 모든 층을 동시에 VRAM에 올려둬야 하지?" 그래서 모델을 층별로 쪼개 디스크에 저장해 두고, 추론할 때 ① 1번 층을 GPU에 올려 계산 → ② 결과만 남기고 1번 층을 VRAM에서 비움 → ③ 2번 층을 올려 계산 …을 마지막 층까지 반복한다.

핵심을 한 번 더 못 박자면, AirLLM이 줄이는 것은 "한 순간에 GPU가 들고 있어야 하는 가중치의 양(peak VRAM)"이다. 70B 모델 전체는 여전히 디스크에 140GB가량 그대로 있고, 계산 총량도 줄지 않는다. 다만 '동시에 올라가는' 양만 한 층치(70B 기준 약 1.6GB 안팎)로 압축해, 4GB짜리 소비자용 GPU의 좁은 문을 통과시키는 것이다.

2왜 주목받는가

TrendShift 일간 17위까지 다시 올라온 이유 — 트렌딩의 배경.

2023년에 처음 나와 ⭐ 1.8만을 모은 '고전'이지만, 오픈웨이트 거대 모델(Llama 3.1 405B, Qwen2.5 등)이 쏟아지면서 "이 큰 걸 내 RTX 한 장으로 만져나 볼 수 없을까"라는 갈증이 다시 커졌고, 그때마다 AirLLM이 소환된다. 인기의 핵심을 다섯 가지로 정리한다.

① "불가능 → 가능"이라는 강렬한 한 줄

"4GB GPU로 70B", "8GB로 405B"는 한 번 들으면 안 잊히는 카피다. 보통은 모델 크기를 줄여(양자화·증류) 작은 GPU에 맞추는데, AirLLM은 모델을 줄이지 않고도(기본값) 돌린다는 점에서 접근이 신선하다. "내 게임용 그래픽카드로 최첨단 모델을?"이라는 호기심이 별점으로 직결된다.

② 설치·사용이 거의 transformers 그대로

거창한 분산 추론 프레임워크가 아니라 pip install airllm 한 줄로 끝나고, 사용법도 HuggingFace transformers와 판박이다. AutoModel.from_pretrained("...") 후 model.generate(...)를 호출하면 된다. 기존 코드 습관을 거의 안 바꾸고 거대 모델을 만질 수 있다는 점이 진입장벽을 크게 낮췄다.

③ '양자화 없이'가 기본 — 정확도 손실 회피

4비트 양자화는 메모리를 줄이지만 미세한 정확도 손실과 출력 변형을 부른다. AirLLM의 기본 경로는 원본 16비트 가중치를 그대로 한 층씩 흘려보내므로, 모델의 답 품질이 원본과 동일하다. "메모리는 부족하지만 품질은 타협하기 싫다"는 연구·평가 용도와 궁합이 맞는다.

④ 폭넓은 모델·플랫폼 지원

Llama 2/3/3.1, Mistral, Mixtral, Qwen·Qwen2.5, Baichuan, ChatGLM, InternLM 등 오픈 LLM 리더보드 상위 모델 대부분을 AutoModel이 자동 감지해 처리한다. 게다가 맥(Apple Silicon)에서는 MLX 백엔드로, CPU 단독 추론까지 지원한다. "내가 가진 하드웨어가 뭐든 일단 시도는 된다"가 강점.

⑤ 디스크 병목을 정조준한 '모델 압축' 옵션

느린 게 약점인 걸 알기에, 블록 단위 양자화(block-wise quantization)로 가중치만 압축해 디스크 로딩량을 줄이는 옵션(compression='4bit'/'8bit')을 더했다. 로딩이 병목이므로 로딩량을 줄이면 추론이 최대 3배 빨라지는데 정확도 손실은 거의 무시할 수준이라는 게 저자의 주장. "느리다"는 약점을 정면으로 보완한 영리한 추가다.

3기술 스택 전체 지도

requirements.txt · 소스 트리(air_llm/airllm)에서 뽑아낸 실제 구성.

AirLLM은 화려한 풀스택 앱이 아니라 "transformers·accelerate 위에 올라탄 한 장의 추론 레이어"다. 그래서 의존성도 단출하다. 핵심은 ⓐ 모델 로딩/실행을 빌려 오는 HuggingFace 생태계 ⓑ 빈 모델 골격을 만드는 accelerate ⓒ 디스크 저장 포맷 safetensors ⓓ 압축용 bitsandbytes ⓔ 맥 전용 MLX 백엔드, 이렇게 다섯 축으로 읽으면 된다.

ⓐ 모델·토크나이저 두뇌 — HuggingFace transformers

ⓑ 빈 골격 만들기 — accelerate (핵심 트릭)

ⓒ 디스크 포맷 · 압축 · 가속

ⓓ 맥 전용 백엔드 — MLX

4아키텍처 심화 분석

가중치 파일 하나가 '추론 결과'가 되기까지 — 레이어 스트리밍의 한살이.

AirLLM의 동작은 크게 두 단계다. ① 최초 1회: 받아온 모델을 층별 safetensors로 쪼개 디스크에 저장(splitting). ② 매 추론: 빈 모델 골격을 세우고, 층 목록을 순서대로 돌며 "디스크→CPU(고정 메모리)→GPU→계산→비움"을 반복. 아래 그림이 핵심 흐름이다.

핵심 설계 패턴 ① — 레이어 스트리밍 (한 층씩 로드·계산·해제)

트랜스포머는 층(layer)을 차례로 통과시키는 구조다. 입력이 1번 층을 지나 나온 결과가 2번 층의 입력이 되고… 이렇게 마지막까지 간다. 그러니 한 순간에 실제로 필요한 가중치는 '지금 통과 중인 한 층'뿐이다. AirLLM은 이 사실을 그대로 이용해, forward() 안에서 층 목록(embed → layers[0..N] → norm → lm_head)을 돌며 ① 그 층을 디스크에서 로드 → ② GPU에 올림 → ③ 계산 → ④ 비움을 반복한다. 그래서 peak VRAM이 '모델 전체'가 아니라 '가장 큰 한 층 + 활성값'으로 떨어진다.

핵심 설계 패턴 ② — 빈 골격 + 채우고 비우기 (accelerate)

모델을 통째로 메모리에 만들면 그 순간 OOM이다. 그래서 init_empty_weights()로 가중치가 비어 있는 70B '골격'을 먼저 세운다(메모리 거의 0). 그다음 매 층에서 set_module_tensor_to_device(model, 층이름, 'cuda', value=가중치)로 그 층의 자리에만 진짜 텐서를 꽂아 넣고, 계산이 끝나면 다시 비운다. "형태는 미리, 내용은 그때그때"라는 분리가 이 모든 마술의 토대다.

핵심 설계 패턴 ③ — 프리페칭으로 디스크 I/O와 계산 겹치기

디스크에서 층을 읽는 시간이 병목이라면, 읽는 동안 GPU를 놀리지 않으면 된다. AirLLM은 ThreadPoolExecutor로 지금 층(i)을 계산하는 사이에 다음 층(i+1)을 백그라운드 스레드가 미리 디스크→CPU로 읽어 둔다(future = executor.submit(load_layer_to_cpu, ...)). CPU의 pin_memory()로 고정해 두면 CPU→GPU 전송도 더 빠르다. 이 겹치기(overlap)로 약 10% 속도 향상을 얻는다.

핵심 설계 패턴 ④ — 블록 양자화로 '로딩량' 줄이기 (≠ 일반 양자화)

저자의 통찰: 병목은 '계산'이 아니라 '디스크 로딩'이다. 그러니 가중치만 압축해 파일을 작게 만들면 로딩이 빨라져 추론 전체가 빨라진다. 일반 양자화가 가중치와 활성값을 모두 양자화해 정확도를 해치는 것과 달리, AirLLM은 가중치만 블록 단위로 양자화(4bit/8bit)하고 GPU에서 다시 복원(dequantize)해 계산한다. 그래서 정확도 손실이 거의 없으면서 로딩량이 1/4~1/2로 줄어 최대 3배 빨라진다.

핵심 설계 패턴 ⑤ — AutoModel 아키텍처 자동 디스패치

모델마다 층 이름 구조가 조금씩 다르다(Llama·Qwen·ChatGLM…). auto_model.py의 AutoModel.from_pretrained은 config.architectures[0]를 보고 Qwen2→AirLLMQWen2, Mistral→AirLLMMistral, Llama→AirLLMLlama2 …처럼 알맞은 서브클래스로 분기한다. 각 서브클래스는 set_layer_names_dict()에서 그 모델의 embed/layer_prefix/norm/lm_head 이름만 바꿔 끼우면 되는, 깔끔한 전략 패턴이다. 맥이면 분기 이전에 통째로 MLX 경로로 보낸다.

5디렉토리 구조 해부

저장소를 열면 보이는 폴더·파일이 각각 무슨 일을 하는가.

저장소는 ① 실제 라이브러리 코드(air_llm/)와 ② 같은 저자가 만든 다른 프로젝트(anima_100k/, training/, rlhf/ 등)가 한곳에 섞여 있다. 우리가 공부할 핵심은 air_llm/airllm/ 한 폴더에 거의 다 들어 있다.

가장 먼저 열어볼 3개 파일

6학습 포인트 (기술별)

이 레포에서 '진짜로' 배울 수 있는 것 — 기술별 정리 + 실습 아이디어.

① 트랜스포머의 '레이어 순차 통과' 구조

AirLLM이 성립하는 이유 자체가 "트랜스포머는 층을 차례로 통과한다"는 사실이다. forward()를 읽으면 embed → layers[0..N] → norm → lm_head가 어떤 순서로, 어떤 중간값(hidden state)을 주고받으며 흘러가는지가 손에 잡힌다.

② accelerate의 빈 모델(meta device) 트릭

"메모리를 안 쓰고 거대 모델의 골격만 만든다"는 발상은 분산 로딩·체크포인트 샤딩 등 현대 LLM 인프라 전반에서 쓰인다. init_empty_weights() + set_module_tensor_to_device() 한 쌍을 여기서 제대로 익혀 두면 다른 프레임워크 코드도 읽힌다.

③ I/O와 계산을 겹치는 동시성(프리페칭)

ThreadPoolExecutor + future.result()로 다음 데이터를 미리 읽으며 현재 계산을 진행하는 패턴은 데이터 로더·스트리밍 처리의 보편 기법이다. GIL이 있는 파이썬에서도 I/O 대기는 스레드로 겹칠 수 있다는 실전 예시이기도 하다.

④ 양자화 두 갈래: '계산용'과 '저장용'의 차이

일반 양자화(활성값까지)와 AirLLM의 '가중치만, 로딩 축소용' 블록 양자화가 왜 목적과 정확도 영향이 다른지를 코드로 비교할 수 있다. utils.py의 dequantize_nf4/dequantize_blockwise가 압축을 어떻게 되돌리는지 보라.

⑤ 전략 패턴: 모델별 서브클래스 분기

AirLLMBaseModel(공통) + 모델별 서브클래스(set_layer_names_dict()만 다름)는 "공통 알고리즘 + 부분만 교체"라는 객체지향 설계의 모범 사례다. 새 아키텍처를 추가할 때 무엇만 바꾸면 되는지가 명확히 보인다.

7하드웨어 / 시스템 요구사항

"진짜로 돌리려면" 무엇이 필요한가 — VRAM만 보면 함정에 빠진다.

AirLLM의 광고 문구는 VRAM만 말하지만, 실제로 발목을 잡는 건 디스크 용량과 디스크 속도다. 매 토큰마다 모델 전체를 디스크에서 읽기 때문이다. 아래 표로 현실적인 요건을 정리한다.

8직접 해볼 수 있는 실습 과제

난이도별 5개 — 직접 손으로 돌려야 진짜 이해된다.

🟢 Lv.1 — 7B 모델로 첫 추론 성공시키기 입문

거대 모델로 바로 가지 말고 작은 7B(예: Mistral-7B)로 파이프라인을 익힌다. 최초 실행 때 모델이 층별로 쪼개져 저장되는 로그를 눈으로 확인하는 게 목표.

pip install airllm
python -c "
from airllm import AutoModel
m = AutoModel.from_pretrained('mistralai/Mistral-7B-Instruct-v0.1')
t = m.tokenizer(['What is the capital of Korea?'],
                return_tensors='pt', return_attention_mask=False)
out = m.generate(t['input_ids'].cuda(), max_new_tokens=10,
                 use_cache=True, return_dict_in_generate=True)
print(m.tokenizer.decode(out.sequences[0]))
"

🟢 Lv.2 — 프로파일링으로 '병목' 눈으로 보기 입문+

profiling_mode=True로 초기화해, 층마다 디스크 로딩 시간과 계산 시간이 따로 찍히게 한다. "거의 다 로딩이고 계산은 짧다"는 AirLLM의 본질을 데이터로 확인한다.

from airllm import AutoModel
m = AutoModel.from_pretrained('mistralai/Mistral-7B-Instruct-v0.1',
                              profiling_mode=True)
# 생성 후 출력되는 load_safe_tensor vs create_layer 시간을 비교

🟡 Lv.3 — 압축 ON/OFF 비교 실험 중급

compression=None vs '4bit'로 같은 프롬프트를 생성해, ① 출력 텍스트 일치도 ② 총 생성 시간 ③ 디스크 사용량을 표로 만든다. "정확도 거의 그대로, 속도는 빨라짐"이라는 주장을 직접 검증한다. (pip install -U bitsandbytes 선행)

🟡 Lv.4 — '레이어 루프'를 손으로 재현하기 중급+

AirLLM 없이, 작은 모델로 직접 미니 레이어 스트리밍을 구현해 본다: ① init_empty_weights()로 골격 → ② 층 하나를 set_module_tensor_to_device로 GPU에 올림 → ③ 그 층만 통과 → ④ 비움. airllm_base.py의 forward()를 교과서 삼아 핵심 30줄만 베껴 보면 구조가 완전히 내 것이 된다.

🔴 Lv.5 — 70B를 작은 GPU에서 끝까지 돌려 리포트 쓰기 고급

충분한 디스크(NVMe 권장)를 확보하고, 70B(예: Llama 3 70B)를 4~8GB GPU에서 실제로 추론해 토큰당 평균 시간·총 VRAM·디스크 사용량을 측정한다. 같은 모델을 클라우드 양자화 추론과 비교해 "AirLLM은 언제 합리적인 선택인가"에 대한 자기만의 판단 기준을 글로 정리하면, 이 레포 학습의 완성이다.

9관련 기술 심화 학습 로드맵

AirLLM을 출발점으로 'LLM 추론 최적화' 전반을 익히는 4주 코스.

10핵심 키워드 사전

이 문서·이 레포에 등장한 주요 용어 한 줄 정리.

11참고 링크

원문과 더 깊이 파고들 자료.