2026년 airllm으로 4GB GPU에 70B 로컬 LLM 돌리기, 292초 속도부터 확인하세요
퀀텀점프클럽 정상록6 min read2 viewsFree Resource
PDF · Free
4GB 그래픽카드로 AI 거인을 돌린다? 진짜일까: 비개발자를 위한 쉬운 가이드
Get the practical guide first, before diving into the full article.
2026년 airllm으로 4GB GPU에 70B 로컬 LLM 돌리기, 292초 속도부터 확인하세요
4GB GPU로 70B 모델을 돌리는 airllm은 레이어를 디스크에서 순차 로딩해 메모리를 아끼지만, 그 대가로 토큰당 292초라는 느린 속도를 감수해야 합니다.
결론부터 말하면 airllm은 4GB짜리 GPU에서도 70B급 모델을 진짜로 돌릴 수 있게 해줍니다. 다만 그 그림이 다가 아니에요. "이거 우리 노트북에서도 진짜 되나요?"라는 질문을 커뮤니티 곳곳에서 봤습니다. 신기한 기술 이야기를 들으면 일단 의심부터 하고 보는 게 당연하죠. 이 글에서는 airllm이 어떻게 4GB로 70B 모델을 돌리는지 원리부터, 저자가 직접 공개한 292초라는 속도, 아직 검증되지 않은 부분까지 순서대로 짚어보겠습니다.
airllm이 다시 화제인 이유: v3.1.0과 킴 K3
이번 재조명의 방아쇠는 2026-07-29에 공개된 v3.1.0 릴리스입니다. 이 버전은 2026-07-16에 등장한 2.8조 파라미터급 모델 킴 K3(Kimi K3)를 단일 GPU 카드, 그것도 3.72GB VRAM만으로 돌린 실측을 공개하면서 다시 주목받았어요. GitHub API로 확인한 최근 커밋 시점도 2026-07-29로 같아, 이 릴리스가 재부상의 진원지라는 정황이 맞아떨어집니다. 2024-09-21 v2.11.0 이후 약 21개월(647일) 동안 조용했던 프로젝트가 이 릴리스로 다시 움직이기 시작했다는 점도 눈여겨볼 만해요.
speed_improvement
이미지 출처: github.com
4GB로 70B가 돌아가는 원리: 책 80권을 한 권씩 꺼내 읽는 법
원리를 이해하려면 저자가 직접 쓴 기술 해설 원문의 비유가 가장 쉽습니다. 70B 모델은 두꺼운 백과사전 80권짜리 전집이라고 생각해 보세요. 전체 용량은 130GB인데, 내 책상(GPU VRAM)에는 4권도 못 올립니다. 흔한 해법은 글자를 줄여 요약본을 만드는 것, 즉 양자화죠. airllm은 다른 길을 갑니다. 책을 원본 그대로 두고, 서가(디스크)에서 딱 한 권씩 꺼내 읽고 도로 꽂아 넣는 방식입니다. 이 방식을 레이어 분할 추론이라고 부릅니다. 70B 모델의 트랜스포머 레이어는 80장인데 앞 레이어의 출력이 다음 레이어의 입력이 되니, 어느 순간이든 GPU에 필요한 건 레이어 딱 1장, 약 1.6GB뿐이에요. 내용 손실은 0이지만 매 레이어마다 디스크를 오가야 해서 그만큼 느려집니다. 여기에 flash attention으로 어텐션 계산 메모리를 줄이고, 모델 파일을 레이어 단위로 재분할해 두고, 가중치 없이 골격만 먼저 불러오는 meta device까지 더해져야 4GB라는 숫자가 실제로 나옵니다.
4GB로 70B가 돌아가는 원리: 책 80권을 한 권씩 꺼내 읽는 법
이미지 출처: huggingface.co
airllm이란?: 70B급 대형 언어모델을 4GB 수준의 GPU VRAM에서도 실행할 수 있게 해주는 오픈소스 추론 엔진입니다. 양자화 대신 트랜스포머 레이어를 디스크에서 하나씩 순차 로딩해 메모리를 아끼는 대신, 속도를 크게 희생합니다.
MoE 모델에서 더 작은 VRAM으로 내려가는 이유
킴 K3처럼 파라미터가 훨씬 큰 모델이 오히려 더 적은 VRAM으로 도는 이유는 Kimi K3 공식 블로그가 밝힌 구조에 있습니다. K3는 희소 MoE(Mixture of Experts) 구조라 레이어 하나에 전문가 896개를 두고, 토큰 하나를 처리할 때 그중 16개만 골라 씁니다. v3.1.0은 이 특성을 이용해 레이어 전체가 아니라 전문가 하나 단위로 스트리밍하도록 바꿨어요. 레이어의 전문가를 다 펼치면 약 55GB지만, 토큰 하나가 실제로 필요로 하는 양은 약 1GB에 그칩니다. 여기에 MXFP4로 압축한 가중치가 GPU로 넘어간 뒤에야 펼쳐지니 전송량도 4분의 1로 줄어듭니다. 1.56TB짜리 체크포인트를 레이어별로 새로 나누면 원래 두 배 용량(3.12TB)이 필요했는데, K3의 샤드가 모듈 단위로 깔끔하게 나뉘어 있던 덕에 복사 대신 하드링크로 처리했다는 설명도 릴리스 노트에 담겨 있습니다.
Kimi K3 benchmark comparison
이미지 출처: kimi.com
설치와 기본 사용법
설치와 실행 방법은 공식 README에 정리돼 있고, 시작 자체는 단순해요.
Bloome — Run AI Agent Teams in the Cloud
이미지 출처: github.com
pip install airllm
from airllm import AutoModel
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
input_tokens = model.tokenizer(
["What is the capital of United States?"],
return_tensors="pt", return_attention_mask=False,
truncation=True, max_length=128, padding=False,
)
out = model.generate(
input_tokens["input_ids"].cuda(),
max_new_tokens=20, use_cache=True, return_dict_in_generate=True,
)
print(model.tokenizer.decode(out.sequences[0]))
코드는 몇 줄 안 되지만, 첫 실행에서는 원본 모델을 레이어 단위로 재분할해 다시 저장하는 과정이 먼저 돌아갑니다. 이 단계에서 디스크 여유 공간이 부족하면 실패하는 경우가 많고, README FAQ 1번도 이 문제를 다뤄요. 킴 K3처럼 MoE 모델을 돌리려면 요구사항이 하나 더 있습니다.
pip install airllm compressed-tensors flash-attn
flash-attn은 필수고, CUDA 12 계열 torch가 필요하며, transformers는 4.56대여야 K3의 원격 코드가 정상 로드됩니다. macOS는 Apple Silicon에서만 지원하고 mlx 설치가 전제 조건이에요.
속도의 진실: 292초에 담긴 의미
여기서부터가 진짜 중요한 부분입니다. v3.1.0 릴리스 노트는 RTX 6000 Ada(48GB) 기준으로 킴 K3 생성 속도를 저자 스스로 292초/토큰이라고 공개했습니다. 초당 약 0.0034토큰, 짧은 답변 100토큰을 뽑는 데도 산술적으로 8시간이 넘게 걸리는 셈이에요. 여기에 프로세스당 1회씩 900초짜리 초기화 시간도 따로 붙습니다. 이 수치는 비판이 아니라 저자 본인이 밝힌 값이라, 설계상 트레이드오프를 스스로 인정한 셈이죠. 커뮤니티 증언도 자릿수는 어긋나지 않습니다. 2024-01-19 r/LocalLLaMA 스레드에서 89 추천을 받은 댓글은 "7B도 응답에 수 분이 걸리고, 70B는 응답 하나에 2시간 걸렸다는 사람도 있다"고 적었어요. 대화형 챗봇으로 쓸 수 있는 속도는 아니라는 뜻입니다. 저자도 2023년 원문에서 "챗봇 같은 대화형 시나리오보다는 RAG나 문서 분석 같은 오프라인 작업에 맞다"고 미리 적어 뒀습니다.
검증되지 않은 부분과 2026년 대안: 무엇을 확인하고 넘어가야 할까
헤드라인 수치를 그대로 믿기 전에 꼭 봐야 할 자료가 저장소 안에 있습니다. 이슈 #295는 2026-06-21에 등록된 뒤 오늘(2026-08-03) 기준 43일째 열려 있는 상태고, README의 4GB/70B·8GB/405B·3배 속도 향상 같은 헤드라인 수치에 재현 가능한 벤치마크 스크립트나 CI 증거가 없다고 지적합니다. 특히 405B 예제로 링크된 모델이 실제로는 사전 4bit 양자화 버전(unsloth/Meta-Llama-3.1-405B-Instruct-bnb-4bit)이라, "양자화 없이"라는 문구와 어긋난다는 지적도 있어요. 저자는 아직 이 지적에 반박하지 않았습니다. AMD 사용자라면 이슈 #301도 함께 봐야 해요. ROCm 환경에서 model.generate()가 무한 대기에 빠진다는 보고이고, 2026-08-02에 제3자가 같은 증상을 재현했다고 확인했습니다. 지금은 사실상 NVIDIA/CUDA 중심 프로젝트로 보는 게 안전합니다.
그렇다면 2026년 지금, 로컬 LLM을 실용적으로 쓰고 싶을 때 답은 무엇일까요. 대부분의 경우 정답은 airllm이 아니라 llama.cpp 계열의 MoE 오프로딩입니다. --n-cpu-moe 같은 옵션으로 전문가 가중치만 CPU로 내리면 중급 GPU에서도 초당 수십 토큰대가 나온다는 보고가 흔해요. airllm의 자리는 셋 중 하나입니다. 양자화 손실 없이 원본 정밀도 그대로 검증해야 하는 연구·평가 목적, 어떤 방법으로도 하드웨어에 안 들어가는 초거대 모델을 딱 한 번 돌려봐야 하는 상황, 지연시간이 문제 되지 않는 오프라인 배치 작업입니다. "빠른 대화"가 필요하면 airllm은 답이 아니고, "이 하드웨어로는 아예 못 돌리던 모델을 한 번은 돌려보는 것"이 이 프로젝트의 진짜 쓸모예요.
마무리
정리하면 "4GB로 70B가 된다"는 헤드라인 자체는 사실에 가깝습니다. 다만 그 뒤에 292초/토큰이라는 속도와, 아직 재현되지 않은 벤치마크 논란이 함께 붙어 있다는 것도 같이 봐야 완전한 그림이 돼요. 도입을 검토 중이라면 대화형 챗봇이 아니라 오프라인 배치나 연구 목적에 맞는지부터 따져보는 게 순서입니다.
우리 팀 환경에 airllm이 맞는지는 천천히 따져보셔도 충분해요. 로컬 실험을 넘어 팀 전체의 AI 도입 전략이 궁금하시다면 QJC 블로그의 다른 글도 참고해 보세요.
자주 묻는 질문 (FAQ)
Q: airllm은 정말 양자화 없이 70B가 돌아가나요?
네, 레이어 분할 추론이 핵심이라 원본 가중치 정밀도를 그대로 씁니다. 다만 이슈 #295가 지적하듯 대표 예제인 405B 케이스는 실제로 사전 4bit 양자화 모델을 쓰고 있어서, 모든 데모가 "양자화 없이"는 아니라는 점은 감안해야 해요.
Q: 속도가 실제로 쓸 만한가요?
대화형으로 쓰기엔 어렵습니다. 저자가 직접 공개한 킴 K3 실측이 292초/토큰이라, 짧은 답변 하나에도 8시간 넘게 걸릴 수 있어요. 오프라인 배치 작업이나 지연시간이 문제 되지 않는 용도에 맞습니다.
Q: AMD GPU에서도 쓸 수 있나요?
현재는 권하기 어렵습니다. 이슈 #301에 따르면 ROCm 환경에서 generate() 호출이 무한 대기에 빠지는 문제가 2026-08-02에도 재현됐고, 아직 해결되지 않았어요. 사실상 NVIDIA/CUDA 환경에 맞춰진 프로젝트입니다.
