AirLLM 저VRAM 실행의 대가: 70B·405B의 저장공간과 응답 지연

AirLLM 저VRAM 실행은 가중치를 레이어별로 GPU에 올렸다가 해제하는 방식으로 GPU 메모리 사용량을 줄입니다. 그렇다고 비용이 사라지지는 않아요. 체크포인트 저장공간, 호스트 RAM, 데이터 이동 시간, 응답 대기로 형태를 바꿔 남습니다. 도입을 고민한다면 GPU 용량보다 체크포인트의 정밀도와 감수할 수 있는 대기 시간을 먼저 보시길 권합니다.

AirLLM 공식 README는 70B를 약 4GB, 405B를 약 8GB VRAM에서 실행할 수 있다고 소개합니다. 이 수치는 프로젝트 측이 내세우는 실행 가능 주장이고, 시스템 전체에 필요한 메모리 양을 뜻하지는 않아요. 많은 분이 이 지점에서 헷갈립니다. AirLLM은 전체 가중치를 VRAM에 상주시키지 않고 레이어 분할 파일을 차례로 읽어 계산한 뒤 해제하는 구조라서, 데이터를 어디서 어떻게 옮기는지도 함께 따져 봐야 합니다.

405B를 8GB로 돌린다는 말, 4비트 예제 조건부터

먼저 볼 것은 모델 이름 뒤에 붙은 정밀도입니다.

공식 405B 예제는 unsloth/Meta-Llama-3.1-405B-Instruct-bnb-4bit를 씁니다. 입력 최대 길이는 128토큰, 생성 상한은 10토큰이고, 저장된 실행 결과는 비어 있어요. 이 예제로 확인할 수 있는 범위는 사전 양자화된 4비트 모델을 지정한 구성까지입니다. 비양자화 405B를 8GB에서 실행하는 조건이나 실제 생성 속도를 입증하는 자료로 읽기는 어렵습니다.

여기서 두 기술이 줄이는 대상이 서로 다르다는 점을 짚어 두면 좋겠어요. 레이어 스트리밍은 GPU에 동시에 올리는 가중치 양을 줄이고, 양자화는 가중치 하나를 표현하는 비트 수를 줄입니다. '405B 실행'이라는 표현만 보고 저장공간과 속도를 비교하면 이 조건을 놓치기 쉬워요. AirLLM의 compression='4bit'와 '8bit'도 가중치 양자화를 사용합니다. README에 적힌 최대 3배 속도 향상은 프로젝트의 주장으로 받아들이세요. 압축 효과는 같은 작업에서 속도와 한국어 답변의 정확성, 코드 생성 품질을 함께 비교해야 판단할 수 있습니다.

저장공간과 토큰 대기 시간은 따로 계산해야 합니다

AirLLM을 쓰면 원본 체크포인트 외에 레이어 분할본이 따로 생깁니다. 원본 파일 크기만 보고 디스크를 준비하면 공간이 모자랄 수 있어요. delete_original=True로 원본 삭제를 선택하더라도 변환 도중 필요한 최대 공간은 따로 확인해 두세요. 실행 중에는 파일을 읽는 비용이 들고, OS가 읽은 데이터를 캐시에 보관하면 호스트 RAM도 씁니다.

16비트 가중치는 파라미터당 2바이트입니다. 명목 파라미터 수에 2바이트를 곱하면 70B는 약 140GB, 405B는 약 810GB가 나와요. 이 값은 십진 단위로 계산한 가중치 규모입니다. 실제 파일 크기나 앞에서 본 4비트 예제의 다운로드 용량과는 구분해서 보세요. Meta 공식 405B 체크포인트의 BF16에도 이 계산에서는 같은 2바이트를 적용합니다.

대기 시간을 계산하려면 가정을 하나 더 세워야 합니다. 배치 1에서 매 생성 단계마다 해당 가중치 전체를 물리 디스크에서 다시 읽고, 유효 읽기 대역폭이 7GB/s라고 해 볼게요. 그러면 읽기에만 70B는 약 20초, 405B는 약 116초가 걸립니다. 각각 140÷7, 810÷7로 계산한 값이며, 연산·CPU→GPU 전송·압축 해제 비용은 넣지 않았습니다.

이 숫자는 가정 위에서 나온 읽기 시간이에요. 실측 생성 속도나 모든 환경에 적용되는 하한으로 볼 수는 없습니다. OS 캐시에 적중하면 물리 디스크 읽기량이 줄어들 수 있지만, 그만큼 RAM 사용량도 함께 살펴야 하죠. 캐시가 줄여 주는 것은 디스크 읽기이고, 가중치를 GPU로 옮기는 비용은 여전히 남는다는 점도 기억해 두세요.

첫 응답과 전체 완료 시간을 재고 나서 판단하세요

순서는 작은 지원 모델로 측정 환경부터 만드는 쪽을 권합니다. 초대형 체크포인트를 준비하기 전에 실행 구조와 기록 방법을 먼저 점검할 수 있기 때문이에요.

1. 모델 ID·리비전·정밀도와 AirLLM 실행 버전·커밋을 고정합니다. 최신 main과 배포 패키지가 같은 코드라고 가정하지 않습니다.
2. 다운로드·레이어 분할·초기화 시간을 나눠서 잽니다. 요청 후 첫 토큰까지의 지연, 이후 생성 속도, 전체 완료 시간도 각각 따로 측정합니다.
3. 캐시가 비어 있는 상태의 실행과 반복 실행에서 VRAM·RAM·물리 디스크 읽기량·최대 저장공간을 함께 기록합니다.
4. 실제로 쓸 한국어 답변이나 코드 생성 과제로 품질을 비교합니다. 압축 조건을 바꿀 때도 같은 프롬프트를 사용합니다.

초기화가 끝난 시점과 첫 응답이 나온 시점은 나눠서 재야 합니다. 소수 샘플로 실험할 때는 긴 대기를 감수할 수 있어도, 반복 호출에서는 지연이 쌓일 수 있어요. 그래서 활용성은 허용 대기 시간 안에 필요한 작업을 얼마나 끝내는지로 판단하는 게 맞습니다.

초대형 모델을 직접 실행해 확인하기 전까지는 Llama별 최소 RAM, 변환 중 임시 공간, 재현 가능한 첫 토큰 지연과 생성 속도를 확정 사양으로 잡지 않는 편이 좋습니다. 실제로 쓸 체크포인트와 하드웨어에서 이 항목들을 확인한 다음 도입 범위를 정하세요.