[리서치] AirLLM + EXAONE 4.0-32B: 레이어별 추론으로 저사양 GPU에서 32B 모델 실행 가능성 분석

[umyunsang]

배경

GovOn 아키텍처에서 EXAONE 4.0-32B를 planner/오케스트레이터 베이스 모델로 사용하려 합니다. 32B 모델은 tool calling을 네이티브 지원하지만 GPU 메모리(~64GB VRAM) 부담이 큽니다.

AirLLM은 **레이어별 순차 추론(layer-by-layer inference)**으로 70B 모델을 4GB GPU에서 실행하는 오픈소스입니다. 이를 EXAONE 4.0에 마이그레이션할 수 있는지 분석했습니다.

---

AirLLM 핵심 메커니즘

전체 모델을 GPU에 올리지 않고, 한 번에 1개 레이어만 GPU에 로드 → 연산 → 해제를 반복합니다.

1. 모델을 레이어 단위로 분할 저장 (safetensors)
2. forward pass 시:
   for layer in [embed, layer.0, layer.1, ..., norm, lm_head]:
     - 디스크/RAM → GPU 로드
     - layer(hidden_states) 연산
     - GPU → meta device 해제
3. ThreadPoolExecutor로 다음 레이어 prefetch

핵심 파일: airllm_base.py의 AirLLMBaseModel 클래스

---

소스코드 구조 (GovOn-Org/airllm 포크)

air_llm/airllm/
  ├── auto_model.py          # architectures → 클래스 매핑
  ├── airllm_base.py          # 핵심 base 클래스 (layer-by-layer forward)
  ├── airllm.py               # AirLLMLlama2 (Llama 구현)
  ├── airllm_qwen2.py         # Qwen2 구현
  ├── airllm_mistral.py       # Mistral 구현
  ├── airllm_chatglm.py       # ChatGLM 구현
  ├── airllm_internlm.py      # InternLM 구현
  ├── airllm_baichuan.py      # Baichuan 구현
  ├── airllm_mixtral.py       # Mixtral 구현
  └── persist/                # 레이어 분할 저장 로직

---

EXAONE 4.0-32B 아키텍처 분석

config.json 핵심 파라미터:

파라미터	값	비고
model_type	exaone4	HuggingFace 고유 타입
architectures	["Exaone4ForCausalLM"]	transformers 4.54+ 필요
num_hidden_layers	64	Llama-2-70B(80), Qwen2-72B(80) 대비 적음
hidden_size	5120
num_attention_heads	40
num_key_value_heads	8	GQA (Grouped Query Attention)
intermediate_size	27392
sliding_window	4096	하이브리드 어텐션
sliding_window_pattern	"LLLG"	3개 로컬 + 1개 글로벌 반복
max_position_embeddings	131072	128K 컨텍스트
vocab_size	102400

---

마이그레이션 난이도 분석

1단계: auto_model.py — 아키텍처 매핑 추가 (쉬움 ✅)

# auto_model.py에 추가
elif "Exaone4" in config.architectures[0]:
    return "airllm", "AirLLMExaone4"

2단계: airllm_exaone4.py — EXAONE4 전용 클래스 생성 (중간 ⚠️)

AirLLMBaseModel을 상속하고 set_layer_names_dict()를 오버라이드:

class AirLLMExaone4(AirLLMBaseModel):
    def set_layer_names_dict(self):
        self.layer_names_dict = {
            embed: model.embed_tokens,
            layer_prefix: model.layers,
            norm: model.norm,
            lm_head: lm_head,
        }

EXAONE 4.0의 레이어 이름 규칙이 Llama와 동일한 model.layers.{i} 패턴이면 이것만으로 충분합니다.

3단계: 하이브리드 어텐션 처리 (어려움 ❌)

이것이 핵심 난제입니다.

EXAONE 4.0은 sliding_window_pattern: "LLLG" — 레이어 0,1,2는 로컬 어텐션(sliding window 4096), 레이어 3은 **글로벌 어텐션(full attention)**을 반복합니다.

AirLLM의 forward() 메서드는 모든 레이어에 동일한 attention_mask를 전달합니다:

# airllm_base.py line 429-430
attention_mask = torch.ones(self.max_seq_len, self.max_seq_len)
attention_mask = attention_mask.triu(diagonal=1)[None, None, ...] == 0

이는 causal full attention mask이며, EXAONE 4.0의 로컬/글로벌 하이브리드 패턴을 처리하지 못합니다. 수정 필요:

# EXAONE 4.0 하이브리드 어텐션 대응
def get_attention_mask_for_layer(self, layer_idx, seq_len):
    pattern = "LLLG"  # from config
    is_global = pattern[layer_idx % len(pattern)] == "G"
    if is_global:
        # full causal attention
        return causal_mask(seq_len)
    else:
        # sliding window attention (4096)
        return sliding_window_mask(seq_len, window_size=4096)

4단계: QK-Reorder-Norm 처리 (중간 ⚠️)

EXAONE 4.0은 표준 Pre-LN 대신 QK-Reorder-Norm을 사용합니다:

• LayerNorm을 attention/MLP 출력에 적용
• Q, K projection 직후 RMSNorm 추가

이는 transformers의 Exaone4ForCausalLM 구현에 이미 포함되어 있으므로, AirLLM이 AutoModelForCausalLM.from_config()으로 모델 구조를 생성하면 자동 적용됩니다. 단, transformers >= 4.54.0 필요.

5단계: RoPE 없는 글로벌 어텐션 (어려움 ❌)

EXAONE 4.0은 글로벌 어텐션 레이어에서 RoPE를 사용하지 않습니다. AirLLM의 position embedding 처리가 이를 감안해야 합니다.

---

예상 GPU 메모리 사용량

방식	VRAM 필요	속도
일반 로딩 (fp16)	~64GB	빠름
일반 로딩 (4-bit GPTQ)	~18GB	빠름
AirLLM (fp16)	~4GB	느림 (~30초/토큰)
AirLLM (4-bit)	~2GB	느림 (~15초/토큰)

주의: AirLLM은 매 토큰 생성마다 64개 레이어를 순차 로드하므로 추론 속도가 매우 느립니다. planner용(도구 선택 JSON 1회 생성)에는 허용 가능하지만, 실시간 대화에는 부적합합니다.

---

결론 및 제안

마이그레이션 가능성: 가능하지만 비자명한 작업 필요

항목	난이도	상태
아키텍처 매핑	✅ 쉬움	auto_model.py 1줄 추가
레이어 이름 매핑	✅ 쉬움	set_layer_names_dict 오버라이드
transformers 호환	⚠️ 중간	4.54+ 필요, trust_remote_code
하이브리드 어텐션	❌ 어려움	forward() 내 레이어별 mask 분기 필요
RoPE 조건부 적용	❌ 어려움	글로벌 레이어에서 RoPE 비활성화
QK-Reorder-Norm	✅ 자동	transformers가 처리

대안 검토

대안	장점	단점
EXAONE 4.0-32B + GPTQ 4-bit	18GB VRAM, 빠른 속도	T4(16GB) 불가, A100(40GB) 필요
EXAONE 4.0-1.2B	3GB VRAM, T4 가능	tool calling 품질 저하 우려
AirLLM 마이그레이션	4GB VRAM	느린 속도, 개발 비용
EXAONE 3.5-7.8B + tool-calling LoRA	8GB VRAM, 빠름	tool calling 네이티브 미지원

다음 단계 제안

1. 단기: EXAONE 3.5-7.8B + tool-calling LoRA (옵션 B) — MVP에 적합
2. 중기: AirLLM EXAONE 4.0 마이그레이션 PoC (이 리서치 기반)
3. 장기: A100/H100 확보 시 EXAONE 4.0-32B GPTQ 직접 서빙

---

관련 리소스

• 포크된 레포: https://github.com/GovOn-Org/airllm
• EXAONE 4.0 config.json: https://huggingface.co/LGAI-EXAONE/EXAONE-4.0-32B/blob/main/config.json
• AirLLM 원본: https://github.com/lyogavin/airllm
• EXAONE 4.0 기술 보고서: https://www.lgresearch.ai/data/cdn/upload/EXAONE_4_0.pdf