2026/08/02

AirLLM으로 70B 모델을 4GB GPU에서 구동하기: 정직한 가이드

70B 대규모 언어 모델을 4GB GPU에서 정말 구동할 수 있을까요? AirLLM이 레이어를 디스크에서 스트리밍하는 원리, 추가로 필요한 하드웨어, 실행 방법 및 성능이 느린 이유를 알아봅니다.

네, 70B 대규모 언어 모델은 AirLLM을 사용하여 약 4GB의 GPU 메모리를 쓰면서 실행할 수 있습니다. 하지만 모델이 4GB 그래픽 카드 안에 들어가지는 않습니다. AirLLM은 체크포인트를 디스크에 두고 한 번에 하나의 트랜스포머 레이어를 VRAM에 로드한 뒤 그 레이어를 계산하고 해제한 후 반복합니다. 이 기법은 메모리를 스토리지 I/O와 지연으로 교환합니다.^[1]^[2]

이 구분이 전체 이야기입니다. 70B 모델은 원본 시연에서 사용한 정밀도 기준으로 약 130GB의 가중치 저장소가 필요합니다. 4GB 수치는 좁게 구성된 추론 실행 중 VRAM 피크를 설명하지만 총 머신 메모리, 다운로드 크기 또는 상호작용 성능은 아닙니다.

핵심 정리

AirLLM은 극단적인 오프로딩을 가능하게 합니다. 레이어 단위 샤드를 디스크에 저장하고 활성 레이어만 GPU로 이동합니다.
원본 결과는 16GB Nvidia T4에서 4GB 이하를 측정했습니다. 이것은 실제 4GB 카드에서 전체적으로 실행되는 빠른 챗봇을 시연하지 않았습니다.^[1]
디스크 용량과 속도는 여전히 중요합니다. 첫 실행은 체크포인트를 다운로드하고 재분할하며, 생성된 모든 토큰은 반복적으로 가중치를 계산 장치로 스트리밍합니다.
짧은 컨텍스트는 요령의 일부입니다. 원본 예시는 100 토큰의 입력 길이를 사용했으며 더 큰 KV 캐시와 런타임 버퍼는 더 많은 메모리를 소비합니다.^[1]
연구 또는 배치 속도를 예상하세요, 반응형 채팅이 아닙니다. AirLLM의 저자는 명시적으로 저사양 하드웨어를 대화형 애플리케이션보다 오프라인 작업으로 위치시킵니다.^[1]
출력 속도가 중요할 때는 API를 사용하세요. 극단적인 로컬 오프로딩은 학습과 가끔의 개인 작업에 유용하며 호스팅된 추론이 일반적으로 더 단순한 프로덕션 경로입니다.

"70B LLM을 4GB GPU에서 구동"의 실제 의미

네 가지 다른 리소스가 하나의 헤드라인으로 압축됩니다. 이들을 분리하면 대부분의 나쁜 하드웨어 결정을 방지합니다.

리소스	AirLLM이 변경하는 것	AirLLM이 변경하지 않는 것
GPU VRAM	대략 하나의 레이어와 런타임 상태를 상주 상태로 유지	전체 체크포인트는 VRAM에 없음
시스템 RAM	레이지 로딩과 메타 장치를 사용하여 전체 모델 구체화 방지	Python, 토크나이저, 버퍼 및 OS 메모리는 여전히 존재
디스크	완전한 모델을 레이어 지향 샤드로 저장	다운로드가 4GB가 되지 않음
시간	프리페치는 로딩과 계산의 일부를 겹칠 수 있음	스토리지 트래픽은 중앙 병목으로 유지

원본 2023 연습은 80개 트랜스포머 레이어가 있는 Llama 2 기반 70B 체크포인트를 사용했습니다. 하나의 레이어는 약 1.6GB로 추정되었고 100 토큰 예시의 KV 캐시는 약 30MB였습니다. 측정된 프로세스는 Nvidia T4에서 4GB의 GPU 메모리 이하로 유지되었습니다.^[1]

AirLLM의 현재 저장소는 같은 아이디어를 Llama 3.x, Qwen, DeepSeek, Mixtral, Phi, Gemma 및 기타 계열로 확장합니다. 현재 참조 테이블은 여전히 전체 정밀도 Llama 3.x 70B 실행을 약 4GB VRAM으로 나열합니다.^[2] 이것을 프로젝트 클레임과 메모리 목표로 취급하세요. 모든 4GB 카드에 대한 처리량 벤치마크는 아닙니다.

AirLLM 레이어 단위 추론의 작동 원리

AirLLM이 디스크에서 트랜스포머 레이어를 4GB GPU 스테이징 영역으로 스트리밍함

트랜스포머는 블록을 순차적으로 실행합니다. 레이어 12는 레이어 11의 숨겨진 상태를 소비하며 레이어 13은 레이어 12를 기다립니다. AirLLM은 이 순서를 5부 파이프라인으로 활용합니다.

빈 모델 셸을 만들어라. Hugging Face Accelerate의 메타 장치는 모든 매개변수에 대해 실제 저장소를 할당하지 않고 아키텍처를 초기화합니다.^[3]
체크포인트를 레이어별로 재분할하세요. Safetensors 파일은 한 레이어를 로드할 때 관련 없는 다중 기가바이트 샤드를 읽을 필요가 없도록 재정렬됩니다.
계산 장치에 하나의 레이어를 로드하세요. 오직 그 레이어와 필요한 런타임 텐서만 그 시점에 GPU를 차지합니다.
계산, 해제 및 계속합니다. 숨겨진 상태가 앞으로 이동하면서 레이어 가중치는 VRAM을 떠납니다.
생성된 모든 토큰에 대해 반복합니다. 프리페치는 스토리지 I/O를 계산과 겹치게 하지만 반복적인 데이터 이동을 제거할 수 없습니다.

FlashAttention은 타일 지정, I/O 인식 계산을 통해 주의에서 사용되는 임시 메모리를 줄입니다.^[4] 활성 레이어가 맞도록 도움을 주면서 레이어 스트리밍은 활성화되지 않은 가중치가 대기하는 위치의 별도 문제를 해결합니다.

여전히 필요한 하드웨어와 스토리지

GPU는 하나의 구성 요소일 뿐입니다. 70B 체크포인트를 다운로드하기 전에 나머지 머신을 확인하세요.

호환 가능한 계산 경로. 헤드라인 시연은 Nvidia CUDA를 목표로 합니다. AirLLM은 또한 Apple Silicon과 CPU 경로를 문서화하지만 메모리와 성능 특성이 다릅니다.^[2]
체크포인트와 변환을 위한 충분한 디스크. 프로젝트는 첫 실행 레이어 분할이 디스크 집약적이라고 경고합니다. 스토리지가 부족할 때 변환 후 원본 체크포인트를 제거할 수 있는 delete_original 옵션이 있습니다.
빠른 로컬 스토리지. NVMe는 레이어 스트리밍을 자유롭게 만들지는 않지만 느린 하드 드라이브는 이미 I/O 바운드 루프를 실질적으로 악화시킵니다.
짧은 초기 컨텍스트와 출력. 작은 프롬프트와 20~40개의 새 토큰으로 시작하세요. 더 긴 컨텍스트는 KV 캐시를 증가시키고 더 긴 출력은 전체 레이어 순회를 더 많은 횟수로 반복합니다.
모델 접근. 게이트 Meta 체크포인트에는 Hugging Face 토큰과 모델 라이선스 동의가 필요합니다.

단순히 환경이 작동하는지 테스트하려고 70B 다운로드로 시작하지 마세요. 먼저 8B 이하로 지원되는 모델을 실행하고, CUDA와 스토리지 경로를 확인한 후 확장하세요.

AirLLM을 70B 모델로 시도하는 방법

현재 프로젝트 빠른 시작은 Hugging Face 저장소 ID에서 적절한 구현을 선택하는 AutoModel을 사용합니다.^[2] 먼저 CUDA 드라이버와 호환되는 PyTorch 빌드를 설치한 후 AirLLM을 설치하세요.

python -m venv .venv
source .venv/bin/activate
pip install airllm

환경 변수에 시크릿을 유지하세요. 소스 코드에는 유지하지 마세요:

export HF_TOKEN="your_hugging_face_token"

그런 다음 의도적으로 작은 생성을 실행하세요:

import os

from airllm import AutoModel

MODEL_ID = "meta-llama/Llama-3.3-70B-Instruct"
MAX_LENGTH = 128

model = AutoModel.from_pretrained(
    MODEL_ID,
    hf_token=os.environ["HF_TOKEN"],
    layer_shards_saving_path="/data/airllm-shards",
)

prompt = ["Explain layer-wise inference in three short sentences."]
tokens = model.tokenizer(
    prompt,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False,
)

result = model.generate(
    tokens["input_ids"].cuda(),
    max_new_tokens=32,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(result.sequences[0]))

이는 저장소 빠른 시작의 최소 적응입니다. 모든 환경 잠금파일이 아닙니다. AirLLM, Transformers, PyTorch, CUDA 및 모델의 원격 코드는 버전 특정 제약 조건이 있을 수 있으므로 프로덕션 머신에 설치하기 전에 현재 저장소 이슈를 확인하세요.

첫 실행에서 일어나는 일

첫 실행은 나중 실행의 대표가 아닙니다. AirLLM은 모델을 다운로드하고 아키텍처를 검사하고 체크포인트를 레이어 샤드로 분할하고 구성된 경로에 이 샤드를 써야 합니다. 변환을 중단하거나 디스크를 완전히 사용하면 불완전한 safetensors 헤더가 남을 수 있으며 프로젝트의 FAQ는 불완전한 캐시를 지우고 공간을 만든 후 다시 실행하기를 권장합니다. ^[2]

네 가지 신호를 별도로 모니터링합니다:

nvidia-smi -l 1          # GPU 메모리 및 이용률
free -h                  # 시스템 메모리
df -h /data              # 여유 디스크 공간
iostat -xz 1             # 스토리지 포화, sysstat가 설치되어 있으면

낮은 VRAM 수는 그 자체로 성공이 아닙니다. 첫 토큰까지의 시간, 출력 토큰당 초, 디스크 읽기 볼륨 및 반복 실행이 완료된 샤드를 재사용하는지 여부를 기록하세요.

맞아도 AirLLM이 느린 이유

정상적인 GPU 추론은 가중치를 한 번 로드하고 많은 토큰과 요청에 재사용합니다. 극단적인 레이어 오프로딩은 이 이점을 역으로 합니다. 각 새 토큰은 모델의 전체 스택을 통과해야 하면서 가중치는 스토리지에서 작은 조각으로 GPU로 이동합니다.

AirLLM은 로딩을 계산과 겹치게 하는 프리페치를 추가했으며 디스크 트래픽을 줄이기 위해 4비트 또는 8비트 블록 단위 가중치 압축을 제공합니다. 저장소는 압축에서 최대 3배 개선을 보고하지만 실제 성능은 모델, 스토리지, GPU, 컨텍스트 및 소프트웨어 버전에 따라 다릅니다.^[2]

이것은 다음의 방법을 더 신뢰할 수 있게 합니다:

그렇지 않으면 로드할 수 없는 모델의 일회 평가;
오프라인 문서 분류 또는 추출;
지연이 부차적인 저용량 개인 배치 처리;
메모리 스케줄링 및 모델 아키텍처 연구.

그것은 라이브 채팅, 에이전트 루프, 높은 동시성 또는 지연 목표가 있는 API에 대한 나쁜 기본값입니다.

AirLLM 대 양자화 대 API

접근법	로컬 가중치	일반적인 목표	주요 교환
AirLLM 레이어 스트리밍	예	과도한 크기의 모델 실행	매우 낮은 처리량과 무거운 디스크 I/O
4비트 양자화	예	모델을 더 작고 빠르게	밀집 70B 모델은 여전히 가중치용으로 훨씬 4GB 이상이 필요함
CPU/GPU 오프로드	예	중등도 과도한 모델을 RAM과 VRAM 간에 분할	상당한 시스템 RAM 필요
호스팅 API	아니오	대화형 또는 프로덕션 추론 받기	원격 실행, 사용 비용, 제공자 신뢰

실험이 요점일 때 AirLLM을 선택합니다. 로컬 상호작용이 요점일 때 더 작은 양자화 모델을 선택합니다. 70B급 모델과 사용 가능한 응답 시간이 모두 요구사항일 때 API를 선택합니다.

같은 구분은 훨씬 더 큰 클레임에 적용됩니다. 우리의 Kimi K3 on a 4GB GPU 분석은 희소 전문가가 스트리밍 단위를 변경하지만 체크포인트를 지우지 않는 이유를 설명합니다. 현재 긴 컨텍스트 API 예시는 MiniMax M3 API 가이드를 참고하거나 라이브 모델 카탈로그를 찾아보세요.

실질적인 결정 체크리스트

70B LLM을 4GB GPU에서 시도하기 전에 이 질문에 답하세요:

목표는 실행을 증명하는 것인가 아니면 반응형 제품을 구축하는 것인가?
디스크가 원본 모델과 변환 중 레이어 분할 복사본을 모두 보유할 수 있나?
체크포인트 아키텍처가 현재 AirLLM 릴리스에서 명시적으로 지원되나?
워크로드가 긴 첫 토큰까지의 시간과 낮은 처리량을 견딜 수 있나?
모델 라이선스가 의도한 용도를 허용하나?
작은 체크포인트로 같은 소프트웨어 스택을 테스트했나?

2번부터 4번까지 질문에 대한 답이 아니오라면, 4GB 헤드라인은 유용한 배포 계획이 아닙니다.

Gavin Li. Unbelievable! Run 70B LLM Inference on a Single 4GB GPU with This New Technique. November 30, 2023. huggingface.co/blog/lyogavin/airllm
AirLLM. AirLLM repository, current quickstart, supported models, configuration, and FAQ. Retrieved August 2, 2026. github.com/lyogavin/airllm
Hugging Face Accelerate. Big Model Inference and the meta device. huggingface.co/docs/accelerate/usage_guides/big_modeling
Dao et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS 2022. arxiv.org/abs/2205.14135