AirLLM 사용법 — 4GB GPU로 70B 모델 로컬 구동하는 법

70B 모델 가중치를 다 내려받아 놓고 torch.cuda.OutOfMemoryError 를 마주한 적 있다면, 그 허탈함을 아실 겁니다. 디스크에는 140GB가 멀쩡히 누워 있는데 GPU가 4GB라서 한 줄도 못 돌립니다. 보통 여기서 양자화 버전을 찾아 헤매거나, 결국 클라우드 결제창을 엽니다.

AirLLM은 그 선택을 안 해도 되게 만든 라이브러리입니다. 깃허브 스타 3만 5천 개, 라이선스는 Apache 2.0. 저장소 한 줄 소개가 그대로 요약입니다 — "70B 모델을 단일 4GB GPU에서, 양자화·증류·프루닝 없이."

VRAM이 모델 크기를 못 따라가는 게 당연했던 이유

지금까지 추론은 "모델 전체를 메모리에 올린다"는 전제 위에 서 있었습니다. 70B를 FP16으로 올리면 140GB. A100 두 장이 필요하고, 405B는 아예 다른 세상 이야기였죠.

AirLLM이 바꾼 건 압축률이 아니라 그 전제 자체입니다.

핵심은 레이어 단위 스트리밍 추론(layer-wise streaming inference) 입니다. GPU에는 레이어를 한 번에 하나만 올립니다. 그 레이어의 연산이 끝나면 비우고, 다음 레이어를 디스크에서 읽어 올립니다. 이걸 마지막 레이어까지 반복하면 토큰이 나옵니다.

그러면 필요한 VRAM은 모델 전체 크기가 아니라 레이어 한 장의 크기로 결정됩니다. 671B짜리 DeepSeek-V3든 70B Llama든, 레이어 한 장은 수 GB를 넘지 않으니까요.

양자화도, 증류도, 프루닝도 쓰지 않습니다. 가중치는 원본 그대로입니다.

이 구분이 생각보다 중요합니다. 4bit 양자화는 모델을 줄이는 대신 정확도를 일부 내주는 거래입니다. AirLLM은 모델을 건드리지 않고 올리는 순서만 바꿨습니다. 성격이 아예 다른 기술입니다.

숫자로 보면 이렇습니다

공식 README에 실린 메모리 사용량 표입니다.

표를 처음 보면 235B가 70B보다 VRAM을 덜 먹는 게 이상해 보입니다. MoE(Mixture of Experts) 구조라서 그렇습니다. MoE는 토큰마다 전체 전문가 중 일부만 활성화하는데, AirLLM은 expert 단위로도 스트리밍을 하니 실제 올라가는 건 활성 파라미터뿐입니다. 전체 파라미터 수와 VRAM이 비례하지 않는 이유죠.

12GB면 RTX 3060 한 장입니다. 4GB면 중고 장터에서 몇 만 원짜리도 있습니다.

설치는 한 줄, 코드는 쓰던 그대로

pip install airllm

from airllm import AutoModel

model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

input_text = ['What is the capital of United States?']
input_tokens = model.tokenizer(input_text, return_tensors="pt",
                               return_attention_mask=False,
                               truncation=True, max_length=128, padding=False)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True
)
output = model.tokenizer.decode(generation_output.sequences[0])

transformers를 써본 사람이라면 낯선 줄이 하나도 없을 겁니다. 모델별 특화 코드도 필요 없습니다. AutoModel 하나가 Llama(2/3/3.1/3.3/4), Qwen(1~3.8, MoE·FP8·VL 포함), DeepSeek(V2/V3/R1), Mistral·Mixtral, Phi, Gemma, ChatGLM, Baichuan, InternLM, Yi, Kimi K3까지 자동으로 감지합니다.

곁들여 쓸 만한 옵션도 몇 개 있습니다.

• compression='4bit' — 가중치만 블록 단위로 양자화해 정확도 손실을 줄이면서 추론 속도를 약 3배 끌어올립니다.
• LoRA 파인튜닝 — Qwen3.8-Flash-Next(125B)가 6GB 미만, Qwen3.8-27B는 시퀀스 512 기준 약 2GB에서 훈련됩니다.
• macOS 지원 — Apple Silicon에서 mlx와 torch만 있으면 같은 코드가 그대로 돕니다.
• Prefetching — 모델 로딩과 연산을 겹쳐 약 10%를 벌어주고, 기본으로 켜져 있습니다.
• delete_original=True — 레이어 분할 후 원본 파일을 지워 디스크를 최대 절반까지 아낍니다.

v3.0부터는 FP8 모델도 별도 양자화 단계 없이 바로 올라갑니다.

그런데 느립니다. 이게 가장 중요한 단서입니다

여기서는 솔직해질 필요가 있습니다. 레이어를 매번 디스크에서 읽어오는 구조라, 속도의 병목은 연산이 아니라 디스크 I/O 입니다. prefetching과 압축이 어느 정도 완화해주지만, 일반 추론보다 느린 건 구조적으로 피할 수 없습니다.

최초 실행 때는 모델을 레이어 단위로 쪼개는 일회성 전처리가 돌고, 이때 디스크를 꽤 먹습니다. 공간이 모자라면 그냥 에러로 끝납니다. ChatGLM·Qwen 같은 일부 토크나이저는 기본 패딩 토큰이 없어 직접 지정해줘야 하는 자잘한 함정도 있습니다.

그러니까 AirLLM은 "빠르게 서빙하는 기술"이 아닙니다. 원래는 VRAM이 모자라 아예 못 돌리던 모델을, 느리더라도 돌아가게 만드는 기술입니다. 이 한 문장을 잘못 읽으면 도구 선택을 통째로 그르칩니다.

A100 클러스터가 갖춰진 조직이라면 이 라이브러리는 필요 없습니다. 반대로 개인 개발자, 서너 명짜리 팀, 장비 예산이 빠듯한 대학 연구실이라면 이야기가 달라집니다. "일단 내 손으로 한 번 돌려보고 판단하자"는 단계에서 클라우드 시간당 과금이나 GPU 대기열에 막히는 경험은 국내 개발자들 사이에서도 드물지 않습니다. 그 첫 삽을 뜨는 비용을 거의 0으로 만들어준다는 게 이 도구의 실질적인 값어치입니다.

대신 용도 구분은 칼같이 해야 합니다. 밤새 걸어두는 배치 처리, 논문·실험용 오프라인 평가, 그리고 데이터를 외부로 내보낼 수 없는 워크로드 — 망분리나 개인정보 이슈가 걸린 의료·금융·공공 쪽 — 에는 잘 맞습니다. 반대로 사용자가 화면 앞에서 응답을 기다리는 실시간 챗봇이나 동시 접속이 몰리는 서비스 서빙에는 쓰면 안 됩니다. 토큰 하나 뽑는 데 전체 레이어를 디스크에서 훑고 지나가는 구조니까요.

국내에서 많이 쓰는 vLLM이나 llama.cpp와 나란히 놓으면 포지션이 더 분명해집니다. vLLM은 모델이 VRAM에 올라간다는 전제 위에서 처리량을 끌어올리는 서빙 엔진이고, llama.cpp는 양자화로 모델 자체를 줄여 가벼운 하드웨어에 맞추는 쪽입니다. AirLLM은 둘 중 어느 쪽도 아닌, "압축 없이 원본 가중치로, VRAM 제약만 우회해서 일단 돌린다"는 세 번째 선택지에 가깝습니다. 셋이 경쟁한다기보다 쓰이는 장면이 다르다고 보는 편이 맞습니다.

---

정리하면 이렇습니다. AirLLM은 VRAM과 모델 크기를 분리시켜, 4GB GPU로 70B를, 12GB로 671B를 돌아가게 합니다. 가중치는 손대지 않으니 품질 손실 논쟁도 없습니다. 대가는 속도이고, 그 대가를 치를 가치가 있는지는 전적으로 용도에 달렸습니다.

여러분이라면 어떤 작업에 걸어보시겠어요? 집에 놀고 있는 GPU로 거대 모델을 돌려본 경험이 있다면, 실제 토큰 생성 속도가 어느 정도 나왔는지 댓글로 공유해주시면 서로에게 큰 참고가 될 것 같습니다.

---

📎 출처: 원문 보기