일반적인 로컬 개발 환경에서 70B 이상의 대형 언어 모델(LLM)을 실행하려고 시도하면 거의 예외 없이 GPU 메모리 부족(OOM, Out Of Memory) 오류가 발생합니다. 트랜스포머 기반의 표준 딥러닝 프레임워크는 빠른 연산을 위해 모델 가중치 전체를 그래픽 카드의 고속 VRAM에 모두 상주시킨 뒤 추론을 수행하도록 설계되어 있기 때문입니다. 수십 기가바이트에서 수백 기가바이트에 달하는 고가의 전문 연구용 GPU가 없는 개인 개발자나 소형 연구 환경에서는 최신 오픈소스 대형 모델을 직접 코드로 제어해보는 일 자체가 진입 장벽이었습니다.
AirLLM은 이러한 GPU 하드웨어 메모리의 물리적 한계를 해결하기 위해 공개된 파이썬 추론 라이브러리입니다. 모델 전체를 그래픽 메모리에 한 번에 올리는 대신 계층 구조를 분할하여 처리함으로써, 고가의 장비 없이도 단일 4GB GPU 카드에서 대형 언어 모델을 구동할 수 있도록 돕습니다.
이 글에서는 AirLLM 라이브러리의 설치 단계부터 AutoModel 클래스를 활용한 로드 방식, 입력 토큰화 및 model.generate() 호출을 통한 텍스트 디코딩 절차, 그리고 레이어 분할 과정에서 발생하는 디스크 캐시 용량 관리 설정까지 공식 가이드에 맞추어 상세히 살펴봅니다.
소형 GPU의 VRAM 한계와 AirLLM의 메모리 절감 원리
기존에 VRAM이 부족한 시스템에서 대형 모델을 테스트할 때는 모델 가중치의 정밀도를 8비트나 4비트로 축소하는 양자화(quantization), 덜 중요한 파라미터 연결을 제거하는 가지치기(pruning), 혹은 작은 학생 모델로 지식을 압축해 넘기는 증류(distillation) 기법을 주로 활용해 왔습니다. 하지만 이러한 기법들은 원본 모델의 파라미터 구조를 영구적으로 수정하거나 별도의 압축 변환 작업이 선행되어야 하며, 구조에 따라 성능 저하나 변환 오차가 발생할 가능성이 존재합니다.
AirLLM은 양자화나 가지치기, 증류 과정을 필수적으로 거치지 않고도 대형 언어 모델을 레이어 단위로 세분화하여 순차적으로 연산합니다. 트랜스포머 아키텍처는 여러 개의 레이어가 연속적으로 연결된 직렬 파이프라인 형태를 띠고 있으므로, 특정 시점의 순전파(forward pass) 연산에는 현재 계산 중인 단일 레이어의 가중치와 이전 레이어의 출력 텐서만이 필요하다는 특성을 이용한 것입니다. AirLLM은 이를 통해 전체 모델 파라미터를 VRAM에 한꺼번에 올려둘 필요 없이, 현재 연산에 필요한 레이어 가중치만을 메모리에 로드하고 연산이 끝나면 즉시 다음 레이어로 교체하는 방식을 취합니다. 공식 저장소 자료에 따르면 이러한 레이어 단위 분할 처리를 통해 70B 파라미터 규모의 모델도 단일 4GB GPU 카드 환경에서 추론할 수 있도록 지원합니다.
이러한 아키텍처는 GPU 메모리 점유율을 획기적으로 낮춰주지만 시스템의 동작 특성을 크게 바꾸어 놓습니다. 기존 추론 환경의 제약이 주로 GPU의 VRAM 용량 부족이었다면, AirLLM 환경에서는 주된 병목 지점이 디스크 로딩(disk loading) 단계에 위치하게 됩니다. 레이어별 가중치를 연산할 때마다 로컬 저장장치로부터 계층 데이터를 반복해서 읽어 들여야 하기 때문입니다. 따라서 시스템의 VRAM 크기보다는 로컬 스토리지의 입출력 대역폭과 충분한 디스크 공간 확보가 추론 안정성을 좌우하는 핵심 조건이 됩니다.
추론 준비를 위한 패키지 설치와 디스크 환경 요구조건
AirLLM을 사용하여 추론 환경을 구축하려면 먼저 파이썬 환경에 라이브러리를 설치하고, 모델이 디스크에 안전하게 분해되어 저장될 수 있도록 여유 공간을 점검해야 합니다. 라이브러리 자체는 표준 패키지 관리자를 통해 즉시 설치할 수 있습니다.
pip install airllm라이브러리 패키지를 설치한 후 가장 주의 깊게 살펴야 하는 부분은 로컬 드라이브의 디스크 여유 공간입니다. AirLLM은 추론을 시작할 때 지정된 원본 모델을 다운로드한 뒤, 이를 레이어 단위로 먼저 분해(decompose)하여 로컬에 저장하는 과정을 거칩니다. 레이어별 순차 로딩을 수행하기 위해서는 통째로 묶여 있는 원본 가중치 파일들을 개별 계층 단위의 샤드 파일로 나누어 디스크에 미리 보관해 두어야 하기 때문입니다.
따라서 Hugging Face 캐시 디렉터리가 위치한 저장장치에는 다운로드된 원본 모델 파일의 크기뿐만 아니라, 새롭게 분해되어 생성되는 레이어 샤드 파일들을 동시에 수용할 수 있는 충분한 공간이 미리 준비되어 있어야 합니다. 예를 들어 수십 기가바이트 크기의 대형 모델을 다룰 경우, 캐시 드라이브에 모델 파일 용량의 2배에 가까운 공간이 순간적으로 요구될 수 있습니다. 디스크 공간이 부족하면 모델 분할 작업 도중 프로세스가 비정상 종료되므로, 코드 실행 전에 캐시 디렉터리가 위치한 파티션의 가용 용량을 넉넉하게 확보해 두는 과정이 필수적입니다.
AutoModel 기본 코드 작성과 추론 결과 생성 절차
AirLLM은 from airllm import AutoModel 구문을 통해 모델을 로드할 수 있는 통일된 인터페이스를 제공합니다. 사용자는 Hugging Face 허브의 저장소 ID나 사전에 다운로드된 로컬 스냅샷 경로를 AutoModel.from_pretrained() 함수에 전달하여 모델을 인스턴스화할 수 있습니다.
다음은 공식 저장소에서 제공하는 Qwen 32B 모델 기반의 표준 추론 실행 코드입니다. 입력 텍스트를 구성하고 토크나이저를 통해 텐서로 변환한 뒤, GPU 메모리에 전달하여 텍스트를 생성하고 결과를 화면에 출력하는 전 과정을 담고 있습니다.
from airllm import AutoModel
MAX_LENGTH = 128
# Hugging Face 저장소 ID를 전달하여 모델 로드
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=MAX_LENGTH,
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])
print(output)위 코드를 실행하여 첫 추론 결과를 도출하는 구체적인 단계는 다음과 같습니다.
- 환경 준비 및 라이브러리 설치: 터미널 환경에서
pip install airllm명령을 실행해 관련 환경을 구성합니다. - 모델 인스턴스 초기화: 파이썬 스크립트에서
from airllm import AutoModel을 임포트하고,AutoModel.from_pretrained("Qwen/Qwen3-32B")를 호출하여 모델을 로드합니다. 이때 원본 가중치 다운로드와 계층별 분해 및 디스크 저장이 자동으로 진행됩니다. - GPU 메모리 전달 및 생성 실행: 토큰화된 텐서 중
input_tokens['input_ids']를.cuda()를 통해 GPU 메모리로 전송합니다. 이후model.generate()를 호출하여 추론을 실행합니다. 이때 생성할 토큰의 길이를 지정하는max_new_tokens=20과 함께use_cache=True,return_dict_in_generate=True인수를 함께 부여합니다. - 결과 디코딩 및 콘솔 확인: 반환된
generation_output.sequences[0]를model.tokenizer.decode()에 전달해 텍스트 형태로 역토큰화하고, 최종 문자열 결과를 출력합니다.
코드가 정상적으로 동작하면 콘솔 창에 모델이 질문을 인식하고 생성해낸 답변 텍스트(예: 미국 수도와 관련된 설명 문장)가 출력됩니다. 만약 실행 도중 오류가 발생하거나 동작이 멈춘다면 다음 원인들을 점검해야 합니다.
- 디스크 여유 공간 부족: 초기 모델 분해 과정에서 디스크 저장공간이 완전히 차버리면 입출력 쓰기 오류가 발생하며 작업이 중단됩니다. 캐시 드라이브 용량을 점검해야 합니다.
- CUDA GPU 메모리 충돌: 토큰 텐서를
.cuda()로 올리는 순간 다른 백그라운드 프로세스가 VRAM을 과도하게 점유하고 있다면 사소한 텐서 할당에서도 OOM이 발생할 수 있으므로 GPU 점유 상태를 확인해야 합니다. - 디스크 I/O 대기 지연: AirLLM의 주된 병목 지점은 디스크 로딩입니다. 특히 첫 실행 시 모델을 다운로드하고 레이어로 분할해 디스크에 기록하는 작업은 파일 용량에 비례해 상당한 시간이 소요됩니다. 시스템이 멈춘 것이 아니라 저장장치에서 데이터를 쓰는 과정일 수 있으므로 디스크 I/O 활성도를 확인하며 완료를 기다려야 합니다.
캐시 디스크 부족 방지를 위한 delete_original 설정 적용법
AirLLM은 레이어 단위 분할 방식을 통해 VRAM 요구량을 4GB 수준으로 낮추는 데 성공했지만, 대신 대형 가중치를 로컬 파일 시스템에 저장해야 하는 부담을 독자에게 안겨줍니다. 특히 일반적인 데스크톱이나 노트북 환경에서는 고용량 SSD를 단일 파티션으로 사용하는 경우가 많아, 수십 기가바이트 크기의 원본 파일과 레이어 샤드가 동시에 보관되면 디스크 용량이 금세 한계에 도달하게 됩니다.
디스크 저장공간이 여유롭지 못한 환경을 위해 AirLLM은 원본 캐시를 정리할 수 있는 delete_original 설정을 제공합니다. 모델을 초기화할 때 delete_original=True 옵션을 함께 부여하면, Hugging Face 허브로부터 다운로드된 원본 모델 파일을 레이어 단위 분해 작업이 끝난 직후 로컬 디스크에서 자동으로 삭제합니다.
이 옵션을 적용하면 시스템 디스크에는 레이어 분할 추론에 실제로 사용되는 변환 샤드 파일만 남게 되므로, 모델 저장에 필요한 전체 디스크 공간을 절반으로 절약할 수 있습니다. 이미 디스크 용량이 빠듯한 환경이거나 동일한 드라이브에 여러 대형 모델을 번갈아 테스트해 보아야 하는 경우, 이 설정을 활용하면 스토리지 용량 고갈로 인한 비정상 오류를 사전에 효과적으로 방지할 수 있습니다.
사용 중 모델 로드 동작이나 추가 매개변수 설정에 대해 확인이 필요한 경우, 공식 GitHub 저장소의 리드미(README) 문서를 참고하여 현재 지원되는 모델 목록과 디스크 설정 안내를 교차 확인하는 것을 권장합니다.
