AirLLM의 README는 믿기 어려운 문장으로 시작합니다:

AirLLM은 추론 메모리 사용량을 획기적으로 줄여, 양자화 (quantization), 증류 (distillation), 또는 가지치기 (pruning) 없이도 70B 거대 언어 모델 (LLM)을 단일 4GB GPU 카드에서 실행할 수 있게 합니다.

그럼 실제로 확인해 봅시다. 이 주장이 사실일까요? 어떻게 설정하나요? 그리고 — 아무도 크게 질문하지 않는 문제인 — 정말로 그렇게 해야 할까요?

요약 (TL;DR): 이 주장은 기술적으로 사실이며, 엔지니어링 측면에서도 정당합니다.

한 단락으로 요약한 핵심 원리

트랜스포머 (transformer)의 특징은 다음과 같습니다. 그것은 레이어 (layer)들의 스택이며, 이를 순서대로 실행합니다.

입력 (Input) → 레이어 1 → 레이어 2 → 레이어 3 → ... → 레이어 80 → 출력 (Output)

레이어 1이 계산을 수행하는 동안, 레이어 2부터 80까지는 그저... VRAM에 머물러 있습니다. 아무것도 하지 않은 채 공간만 차지하고 있죠.

일반적인 추론 (inference) 방식은 레이어를 유지하는 것이 빠르기 때문에 80개의 레이어 전체를 GPU 메모리에 로드합니다. AirLLM은 당연한 후속 질문을 던집니다. 만약 그렇게 하지 않는다면 어떨까요? 레이어 1을 로드하고, 실행하고, 버리고, 레이어 2를 로드하고, 실행하고, 버리는 방식 말입니다.

이제 VRAM 요구 사항은 "모델의 크기"가 아니라, **"단일 최대 레이어의 크기"**가 됩니다.

전체 FP16 정밀도의 70B 모델의 경우, 레이어당 약 1.75GB입니다. 이는 4GB 내에 여유 있게 들어갑니다. 모델은 여전히 140GB이지만, GPU 대신 디스크에 저장되어 한 번에 한 조각씩 스트리밍됩니다.

이것이 전부입니다. 이것이 핵심 아이디어이며, 실제로 작동합니다.

사실 확인: 주장이 사실인가?

네 — 하지만 모델 크기만큼이나 큰 주의사항(*)이 있습니다.

주장들을 하나씩 살펴보겠습니다.

"단일 4GB GPU에서 70B 실행"

사실입니다. 수학적으로 계산이 맞으며 (FP16 기준 레이어당 ~1.75GB), 충분히 많은 사람들이 독립적으로 재현했기에 논란의 여지가 없습니다.

"양자화 (quantization), 증류 (distillation), 또는 가지치기 (pruning) 없이"

정말로 그렇습니다. 그리고 진정으로 흥미로운 부분은 바로 이것입니다. 대부분의 "작은 하드웨어에서 큰 모델 실행하기" 기법들은 모델의 성능을 저하시킴으로써 작동합니다. 즉, 가중치(weights)를 16비트에서 4비트로 압축하여 정확도(accuracy)를 일부 희생하는 방식입니다. AirLLM은 그럴 필요가 없습니다. 여러분은 수정되지 않은 실제의 전체 정밀도(full-precision) 모델을 얻게 됩니다.

(여기서 양자화 (Quantization)는 _선택 사항_입니다. 더 빠르게 만들기 위해 compression='4bit'를 전달할 수 있습니다. 하지만 반드시 그럴 필요는 없으며, 이것이 그들이 강조하는 차이점입니다.)

더 큰 숫자들도 마찬가지입니다

README의 스케일링(scaling) 표는 터무니없어 보이지만 동일한 논리를 따릅니다:

이상한 점이 보이시나요? 2.8조 개의 파라미터를 가진 모델이 671B 모델보다 더 적은 VRAM을 필요로 합니다.

이것은 오류가 아닙니다. 이들은 전문가 혼합 (Mixture-of-Experts, MoE) 모델입니다. MoE 레이어는 수백 개의 "전문가 (expert)" 서브 네트워크를 포함하고 있지만, 각 토큰(token)은 그중 소수의 전문가에게만 라우팅(route)됩니다. v3.1.0 릴리스 노트에 따르면, Kimi K3는 레이어당 896개의 전문가를 보유하고 각 토큰을 단 16개에게만 라우팅합니다. 따라서 전체 레이어의 전문가들이 ~55GB로 확장되더라도, 단일 토큰은 실제로 그중 ~1GB만을 필요로 합니다. AirLLM은 전체 레이어 대신 해당 전문가들만 스트리밍(stream)합니다.

더 희소한(Sparser) 모델 → 더 작은 워킹 셋(working set) → 더 적은 VRAM. 직관에 어긋나지만, 맞습니다.

헤드라인에서 생략된 내용

여기 굵은 글씨로 강조되지 않은 부분이 있습니다. AirLLM의 자체 v3.1.0 릴리스 노트에서 RTX 6000 Ada로 측정한 결과는 다음과 같습니다:

이것이 무엇을 의미하는지 명확히 하자면, 100개 토큰의 응답을 생성하는 데 8시간이 조금 넘게 걸립니다.

공정하게 말하자면, 유지 관리자(maintainer)는 이 내용을 릴리스 노트에 정직하게 게시했습니다. 단지 마케팅 문구에 들어가는 숫자가 아닐 뿐입니다.

더 일반적인 설정의 경우, 커뮤니티 보고에 따르면 다음과 같은 범위에 해당합니다:

• 괜찮은 NVMe에서의 70B: 토큰당 대략 5~35초
• MacBook에서의 70B: 낮게는 ~0.07 tokens/sec (~토큰당 14초)로 보고됨
• 비교를 위해, RTX 4090에서 양자화된 70B를 사용하는 llama.cpp: 초당 8~15 tokens

따라서 이 주장의 솔직한 버전은 다음과 같습니다:

AirLLM은 4GB GPU에서 70B 모델을 빠르게 만드는 것이 아닙니다. 4GB GPU에서 70B 모델을 실행하는 것을 가능하게 만드는 것입니다.

왜 느린가 (이 계산을 한 번만 해보면 다시는 헷갈리지 않을 것입니다)

이 내용을 이해해 두는 것은 가치가 있습니다. 왜냐하면 이것이 모든 것을 설명해주며, 복잡하지도 않기 때문입니다.

토큰 하나를 생성하기 위해, 모델은 모든 레이어 (layer)를 실행해야 합니다. 이는 AirLLM이 매 토큰마다 디스크에서 모델 전체를 읽어야 함을 의미합니다.

따라서:

토큰당 초 (seconds per token) ≈ 디스크 상의 모델 크기 ÷ 디스크 읽기 속도

FP16 (~140GB)인 70B 모델을 대입해 보겠습니다:

여러분의 디스크가 곧 추론 엔진 (inference engine)입니다. GPU는 거의 작동하지 않습니다. 데이터를 기다리며 유휴 상태로 앉아 있을 뿐입니다. 이것이 AirLLM 사용자들이 팬 소음이 비명을 지르고 노트북을 사용할 수 없게 된다고 보고하는 이유입니다. 병목 현상 (bottleneck)은 연산 (compute)이 아니라 I/O와 CPU에 있습니다.

이 공식에서 바로 도출되는 두 가지 결과는 다음과 같습니다:

1. compression='4bit'를 사용하세요. 이는 읽어야 할 바이트 수를 약 4배 줄여줍니다. README에서는 최대 3배의 속도 향상을 광고하는데, 이제 그 이유를 정확히 알게 되셨을 겁니다. 이것은 더 빠른 수학 연산에 관한 것이 아니라, 더 적은 데이터를 이동시키는 것에 관한 것입니다.
2. RAM은 사실상 최고의 업그레이드 요소입니다. 시스템 RAM이 모델의 큰 부분을 담을 수 있다면, 운영체제(OS)의 페이지 캐시 (page cache)가 디스크 대신 메모리에서 레이어를 제공합니다. 이것이 128GB 사양의 컴퓨터를 사용하는 사람들이 단순한 디스크 계산 수치보다 훨씬 더 극적으로 좋은 수치를 보고하는 이유입니다.

설정 (Setup)

요구 사항 — 시작하기 전에 이 부분을 읽으세요

디스크 공간은 여러분을 괴롭힐 가장 큰 요소입니다. AirLLM은 모델을 다운로드한 후에, 이를 레이어별 샤드 (shards)로 분해합니다. 한동안은 두 복사본이 모두 디스크에 존재하게 됩니다.

70B FP16 모델의 경우, 다음 정도의 용량을 확보하세요:

~140GB (원본 다운로드)
+ ~140GB (레이어 샤드)
= ~280GB 여유 공간

해당 리포지토리(repo)의 FAQ에서 가장 흔하게 발생하는 단일 오류인 safetensors_rust.SafetensorError: Error while deserializing header: MetadataIncompleteBuffer는 유지 관리자들에 따르면, 거의 항상 단순히 디스크 공간이 부족해서 발생하는 문제입니다.

또한 다음 사항들이 필요합니다:

• NVMe SSD (SATA가 아닌 것, HDD는 절대 안 됨)
• 가능한 한 많은 시스템 RAM
• Llama와 같은 게이트 모델 (gated models)을 위한 Hugging Face 토큰
• 인내심. 진정한, 진심 어린 인내심.

1. 설치

pip install airllm

4비트 압축 가속을 위해 (권장 — 위의 수학적 계산 참고):

pip install -U bitsandbytes

2. 실행

from airllm import AutoModel

model = AutoModel.from_pretrained(
...

이것이 API의 전부입니다. 671B 모델로 교체하는 것은 단 한 줄의 변경만으로 가능합니다:

model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")   # 671B, ~12GB VRAM

작게 시작하세요. 70B 모델 다운로드에 280GB와 몇 시간을 투자하기 전에, 먼저 8B 모델을 실행하여 설정을 검증하시기 바랍니다.

3. 유용한 설정 플래그 (config flags)

일반적인 오류 해독

macOS

Apple Silicon에서만 작동합니다. mlx와 torch를 설치하고, 반드시 네이티브 (Rosetta가 아닌) Python을 사용 중인지 확인하세요. 그 외의 코드는 동일합니다.

살펴볼 가치가 있을까요?

당신이 다음 중 어디에 해당하느냐에 따라 전적으로 다릅니다.

거대 모델과 채팅하고 싶다면 건너뛰세요

이것이 사람들을 끌어들이는 환상이지만, 실제로는 작동하지 않습니다. 대화형 채팅(Interactive chat)에는 초당 약 20개 이상의 토큰이 필요합니다. AirLLM은 토큰 하나당 몇 초에서 몇 분이 걸립니다. 대화를 나누는 것은 불가능할 것입니다.

대량의 작업을 수행한다면 건너뛰세요

토큰 하나를 생성할 때마다 SSD에서 수십 GB를 읽어옵니다. 소비자용 NVMe 드라이브는 쓰기 가능한 테라바이트(TBW) 수가 정해져 있습니다. 지속적인 전체 모델 읽기와 샤드(shard) 재작성으로 드라이브를 혹사시키는 것은 설계 의도에 맞지 않습니다. 또한, 실행 중에는 컴퓨터를 사실상 사용할 수 없게 됩니다.

오프라인 배치 작업(offline batch work)에는 진정으로 훌륭합니다

이것이 실제 사용 사례이며, 과소평가되어 있습니다.

결정적인 통찰: 비용이 많이 드는 부분은 레이어(layer)를 _사용하는 것_이 아니라, 로드하는 것입니다. 따라서 Layer 1을 로드한 후 다음으로 넘어가기 전에 50개의 프롬프트를 실행하면 그 비용을 50가지 방식으로 상쇄할 수 있습니다.

보고된 벤치마크 중 하나: 단일 프롬프트의 경우 토큰당 35초 대, 50개를 배치(batching) 처리했을 때 토큰당 5.3초 — 이는 공짜로 얻는 6.6배 향상입니다.

따라서 밤새 분류해야 할 문서가 10,000개 있고 GPU 예산이 없다면, AirLLM은 정말 합리적인 도구입니다. 아무도 기다리지 않을 때는 지연 시간(Latency)이 중요하지 않습니다.

특히 _완벽한 정밀도(full precision)_가 필요할 때 좋습니다

양자화(quantization) 효과 연구, 수치 재현성(numerical reproducibility), 모델을 출판된 그대로 평가하는 경우 등 4비트 근사치가 핵심을 무색하게 만드는 사례들. AirLLM은 이미 소유하고 있는 하드웨어에서 이를 수행할 수 있는 거의 유일한 방법입니다.

결론

주장은 사실입니다. 4GB VRAM에 70B 모델을 완벽한 정밀도로, 속임수 없이 실행하는 것은 가능합니다. 엔지니어링이 영리하고 MoE(Mixture of Experts) 전문가 스트리밍 작업은 정말 인상적입니다.

문제는 프레이밍입니다.