배경

vllm 서버 운영중 0.14.0 미만 버전에서 RCE 취약점이 발생했다고 해서 버전 패치를 했습니다. 
그런데 이전에 나와있던 취약점 중 모델 로드를 통해서 RCE 가 발생할 수 있다는 글을 보
고 이게 어떻게 가능한건지 찾아보게 되었는데요, 
배포포맷이나 일부 프레임워크에서 모델로드에서 가중치만 불러오는것이 아니라
파이썬 코드 로직을 탈 수 있다는 사실을 알게 되어 정리할 겸 글을 작성합니다.

모델 배포 포맷

인공지능 모델을 개발하다 보면 학습 자체보다 더 많은 문제가 발생하는 지점이 바로 배포입니다. 학습된 모델은 단순한 코드가 아니라 수백 MB에서 수십 GB에 이르는 가중치 데이터와 실행 구조를 함께 갖고 있기 때문입니다. 이때 모델을 어떤 형태로 저장하고 전달할 것인가에 대한 문제가 바로 모델 배포 포맷의 출발점입니다.

초기에는 학습한 프레임워크 내부에서만 모델을 사용했기 때문에, 단순히 메모리 객체를 그대로 직렬화하는 방식이 사용되었습니다. 하지만 모델이 커지고, 협업과 외부 공유가 늘어나면서 자연스러운 요구사항이 등장했습니다. 가장 큰 것은 다른 환경에서도 동일하게 모델을 로드할 수 있어야 한다는 것인데요, 모델을 만들고 학습시키는 것은 전체 파이프라인을 구성하지 않는 한 그다지 문제가 되지 않습니다만, 추론을 할 때에는 이식성이 중요하게 여겨졌습니다. 그래서 모델 파일만 export 하게 되었고, 이런 요구사항들을 해결하기 위해서 여러가지 모델 배포 포맷이 등장하게 되었습니다.

Pytorch .pt .pth

Pytorch 의 모델 저장 방식은 Python 객체를 그대로 데이터로 만드는 것인데 이것을 직렬화라고 합니다. 이 포맷도 다른 포맷들과 마찬가지로 모델 재현성의 요구사항을 해결했기 때문에 Research Level 에서는 편하게 사용될 수 있지만, 내부적으로 pickle 을 사용하고, 코드나 데이터 자체를 모두 직렬화 하기 때문에 해당 객체를 로드하는 경우 RCE가 가능하다는 치명적인 문제가 있습니다.

python 공시문서에서 pickle 은 직렬화와 역직렬화를 위한 모듈이라고 나와있습니다. 다른 예시로 사용되는 것들도 나중에 한번 찾아볼법 한 것 같습니다.

pickle — Python object serialization

그래서 Pytorch 의 모델은 배포환경에서는 사용을 지양하는 것이 좋은 것 입니다.

pytorch 는 모델의 형태를 저장할 때 아래와 같이 저장하면서 직렬화를 하는데요, 파라미터만 저장할 수도 있습니다.

import torch
#model 객체 그대로 직렬화
torch.save(model, 'model.pth')
torch.load('model.pth')

#model 파라미터 직렬화 
torch.save(model.state_dict(), 'model.pth')
model.load_state_dict(torch.load('model.pth'))

발생가능한 취약점

# Define model
class TheModelClass(nn.Module):
    def __init__(self):
        super(TheModelClass, self).__init__()
        self.conv1 = nn.Conv2d(3, 6, 5)
        self.pool = nn.MaxPool2d(2, 2)
        self.conv2 = nn.Conv2d(6, 16, 5)
        self.fc1 = nn.Linear(16 * 5 * 5, 120)
        self.fc2 = nn.Linear(120, 84)
        self.fc3 = nn.Linear(84, 10)

    def forward(self, x):
        x = self.pool(F.relu(self.conv1(x)))
        x = self.pool(F.relu(self.conv2(x)))
        x = x.view(-1, 16 * 5 * 5)
        x = F.relu(self.fc1(x))
        x = F.relu(self.fc2(x))
        x = self.fc3(x)
        return x

# Initialize model
model = TheModelClass()

만약 위와 같은 모델이 있다면 torch.save 하는 시점에서 TheModelClass 가 직렬화됩니다. 그럼 class 안에 있는 함수들에 뭔가 다른 목적의 코드가 있다면 torch.load() 하는 시점에서 그대로 실행되겠지요. 이것이 pytorch 의 model.state_dict() 를 저장하지 않고 save 했을 때의 문제점 입니다. 그래서 pytorch 권장사항은 파라미터만 저장되게 하는 torch.save(model.state_dict,’model.pth’) 메서드를 사용하게 합니다.

Huggingface .safetensors

safetensors 는 가중치를 빠르게 저장하고 불러오기 위한 형식인데요, 다른 모델에서 발생할 수 있는 취약점 문제 특히 pickle 을 사용하면서 발생하는 python 객체저장이나 실행가능한 구조를 포함하고 있지 않습니다. safetensors 파일 구조는 헤더와 블록으로 구성되어 있습니다.

헤더는 JSON 형식으로 된 텐서들의 메타데이터이고, 데이터블록은 weight들이 존재하는 바이너리 형태입니다. 실제로 safetensors 를 열어서 확인해볼 수 있는데요

https://huggingface.co/Qwen/Qwen3-ASR-1.7B/tree/main

의 두번째 safetensors 가 발견한것중 용량이 좀 작네요, 이거로 테스트 해보셔도 좋을 듯 합니다.

from safetensors import safe_open

safetensors_file = 
with safe_open(safetensors_file, framework="pt") as f:
  tensor_name = f.keys()
  print(f"tensor list {tensor_name}")

  for key in tensor_name:
    tensor = f.get_tensor(key)
    print(f"tensor name {key} 의 데이터타입 : {tensor.dtype}")
    print(f"tensor name {key} 의 shape : {tensor.shape}")

tensor list ['thinker.model.layers.5.mlp.gate_proj.weight', 'thinker.model.layers.5.mlp.up_proj.weight', 'thinker.model.layers.5.post_attention_layernorm.weight', 'thinker.model.layers.5.self_attn.k_norm.weight', 'thinker.model.layers.5.self_attn.k_proj.weight', 'thinker.model.layers.5.self_attn.o_proj.weight', 'thinker.model.layers.5.self_attn.q_norm.weight', 'thinker.model.layers.5.self_attn.q_proj.weight', 'thinker.model.layers.5.self_attn.v_proj.weight', 'thinker.model.layers.6.input_layernorm.weight', 'thinker.model.layers.6.mlp.down_proj.weight', 'thinker.model.layers.6.mlp.gate_proj.weight', 'thinker.model.layers.6.mlp.up_proj.weight', 'thinker.model.layers.6.post_attention_layernorm.weight', 'thinker.model.layers.6.self_attn.k_norm.weight', 'thinker.model.layers.6.self_attn.k_proj.weight', 'thinker.model.layers.6.self_attn.o_proj.weight', 'thinker.model.layers.6.self_attn.q_norm.weight', 'thinker.model.layers.6.self_attn.q_proj.weight', 'thinker.model.layers.6.self_attn.v_proj.weight', 'thinker.model.layers.7.input_layernorm.weight', 'thinker.model.layers.7.mlp.down_proj.weight', 'thinker.model.layers.7.mlp.gate_proj.weight', 'thinker.model.layers.7.mlp.up_proj.weight', 'thinker.model.layers.7.post_attention_layernorm.weight', 'thinker.model.layers.7.self_attn.k_norm.weight', 'thinker.model.layers.7.self_attn.k_proj.weight', 'thinker.model.layers.7.self_attn.o_proj.weight', 'thinker.model.layers.7.self_attn.q_norm.weight', 'thinker.model.layers.7.self_attn.q_proj.weight', 'thinker.model.layers.7.self_attn.v_proj.weight', 'thinker.model.layers.8.input_layernorm.weight', 'thinker.model.layers.8.mlp.down_proj.weight', 'thinker.model.layers.8.mlp.gate_proj.weight', 'thinker.model.layers.8.mlp.up_proj.weight', 'thinker.model.layers.8.post_attention_layernorm.weight', 'thinker.model.layers.8.self_attn.k_norm.weight', 'thinker.model.layers.8.self_attn.k_proj.weight', 'thinker.model.layers.8.self_attn.o_proj.weight', 'thinker.model.layers.8.self_attn.q_norm.weight', 'thinker.model.layers.8.self_attn.q_proj.weight', 'thinker.model.layers.8.self_attn.v_proj.weight', 'thinker.model.layers.9.input_layernorm.weight', 'thinker.model.layers.9.mlp.down_proj.weight', 'thinker.model.layers.9.mlp.gate_proj.weight', 'thinker.model.layers.9.mlp.up_proj.weight', 'thinker.model.layers.9.post_attention_layernorm.weight', 'thinker.model.layers.9.self_attn.k_norm.weight', 'thinker.model.layers.9.self_attn.k_proj.weight', 'thinker.model.layers.9.self_attn.o_proj.weight', 'thinker.model.layers.9.self_attn.q_norm.weight', 'thinker.model.layers.9.self_attn.q_proj.weight', 'thinker.model.layers.9.self_attn.v_proj.weight', 'thinker.model.norm.weight']
tensor name thinker.model.layers.5.mlp.gate_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.mlp.gate_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.5.mlp.up_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.mlp.up_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.5.post_attention_layernorm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.post_attention_layernorm.weight 의 shape : torch.Size([2048])
tensor name thinker.model.layers.5.self_attn.k_norm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.k_norm.weight 의 shape : torch.Size([128])
tensor name thinker.model.layers.5.self_attn.k_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.k_proj.weight 의 shape : torch.Size([1024, 2048])
tensor name thinker.model.layers.5.self_attn.o_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.o_proj.weight 의 shape : torch.Size([2048, 2048])
tensor name thinker.model.layers.5.self_attn.q_norm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.q_norm.weight 의 shape : torch.Size([128])
tensor name thinker.model.layers.5.self_attn.q_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.q_proj.weight 의 shape : torch.Size([2048, 2048])
tensor name thinker.model.layers.5.self_attn.v_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.v_proj.weight 의 shape : torch.Size([1024, 2048])
tensor name thinker.model.layers.6.input_layernorm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.input_layernorm.weight 의 shape : torch.Size([2048])
tensor name thinker.model.layers.6.mlp.down_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.mlp.down_proj.weight 의 shape : torch.Size([2048, 6144])
tensor name thinker.model.layers.6.mlp.gate_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.mlp.gate_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.6.mlp.up_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.mlp.up_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.6.post_attention_layernorm.weight 의 데이터타입 : torch.bfloat16

weight 에 대한 데이터가 있는것을 볼 수 있습니다. RCE 를 원천적으로 막기 위해 설계 된 만큼 safetensors 모델자체에 대해서는 발견된 취약점이 없습니다.

Microsoft ONNX(Open Neural Network Exchange)

ONNX 는 많은 머신러닝 프레임워크 간의 모델을 통합할 수 있도록 설계된 오픈소스 포맷입니다. ONNX 를 통해서 개발자들은 Pytorch 나 Tensorflow 등 상이한 머신러닝 프레임워크에서 개발해도 ONNX 를 통해서 서로다른 프레임워크로 쉽게 전환해서 사용할 수 있습니다. 이 역시 배포를 원활하게 하자는 정신에서 개발되었습니다.

import torch
import torchvision.models as models
import onnx

# 사전 훈련된 PyTorch 모델 로드
model = models.resnet18(pretrained=True)
model.eval()

# 더미 입력 데이터 생성
x = torch.randn(1, 3, 224, 224, requires_grad=True)

# 모델을 ONNX 포맷으로 변환
torch.onnx.export(model,               # 실행할 모델
                  x,                   # 모델 입력값 (튜플 또는 여러 입력값을 위한 튜플도 가능)
                  "resnet18.onnx",     # 저장될 모델의 이름
                  export_params=True,  # 모델 파일 내 학습된 모델 가중치를 저장할지의 여부
                  opset_version=10,    # 모델을 변환할 때 사용할 ONNX 버전
                  do_constant_folding=True,  # 최적화: 상수 폴딩을 수행할지 여부
                  input_names = ['input'],   # 모델의 입력값에 대한 이름
                  output_names = ['output'], # 모델의 출력값에 대한 이름
                  dynamic_axes={'input' : {0 : 'batch_size'},    # 배치 크기에 따라 동적으로 변하는 입력 차원
                                'output' : {0 : 'batch_size'}})  # 배치 크기에 따라 동적으로 변하는 출력 차원

ONNX 발생 가능한 취약점

최근까지는 ONNX 의 보고된 취약점들에서 ONNX 자체의 취약점은 거의 없다고 해도 될정도로 없었고, 게다가 RCE 는 전혀 볼수 없었습니다. 이 마저도 C/C++ 엄밀히 말하면 런타임 유형의 취약점이라고 할 수 있었다는데요, 최근 발표 된 Path Traveling 취약점도 ONNX 포맷의 문제라기보다는, ONNX 모델을 처리하는 라이브러리 구현의 취약점이라고 합니다.

GGUF / GGML

GGML (Georgi Gerganov Machine Learning Format)

GGML은 Georgi Gerganov가 개발한 경량 머신러닝 라이브러리로, 대규모 언어 모델을 포함한 신경망 모델을 CPU 환경에서 효율적으로 추론하기 위해 설계된 C/C++ 기반 프로젝트입니다. Hugging Face의 소개 글에서도 강조하듯, GGML은 기존 딥러닝 프레임워크가 갖는 복잡성과 무거운 의존성을 최소화하는 것을 목표로 만들어졌습니다.

일반적인 머신러닝 프레임워크인 PyTorch나 TensorFlow는 매우 강력하지만, 대규모 라이브러리 의존성과 복잡한 빌드 환경을 요구합니다. 이는 서버 환경에서는 문제가 되지 않을 수 있지만, 개인 PC나 내부망, 오프라인 환경, 혹은 리소스가 제한된 시스템에서는 부담으로 작용합니다. GGML은 이러한 문제를 해결하기 위해 외부 의존성을 거의 갖지 않는 구조, 그리고 단순한 C 코드 기반 구현을 선택했습니다.

GGML의 핵심 철학은 “작고, 단순하며, 예측 가능한 실행”입니다. 실제로 GGML은 몇 개의 소스 파일만으로 구성되어 있으며, 컴파일된 바이너리 크기 역시 매우 작습니다. 별도의 Python 런타임이나 대형 프레임워크 없이도 모델을 실행할 수 있기 때문에, 환경 이식성이 매우 뛰어납니다. Linux, macOS, Windows는 물론이고 ARM 아키텍처나 Apple Silicon 환경에서도 비교적 쉽게 빌드하고 실행할 수 있습니다.

또 하나의 중요한 특징은 메모리 효율성입니다. GGML은 텐서 표현과 연산에서 불필요한 오버헤드를 제거하고, CPU 캐시 친화적인 메모리 레이아웃을 사용합니다. 특히 GGML이 널리 주목받게 된 이유 중 하나는 강력한 양자화(quantization) 지원입니다. float32 기반 모델을 int8, int5, int4 수준으로 압축해 메모리 사용량을 크게 줄이면서도, 추론 성능을 실용적인 수준으로 유지할 수 있도록 설계되었습니다.

이러한 특성 덕분에 GGML은 학습보다는 추론 중심 라이브러리로 사용됩니다. 이미 학습된 모델을 가능한 한 적은 자원으로 빠르게 실행하는 것이 목적이며, 실제로 llama.cpp, whisper.cpp, GPT4All, LM Studio, Ollama와 같은 여러 프로젝트들이 GGML을 저수준 연산 엔진으로 활용하고 있습니다. 이 경우 GGML은 단순한 모델 포맷이라기보다는, 모델 실행을 담당하는 저수준 런타임에 가깝다고 볼 수 있습니다.

구조적으로 보면 GGML은 내부에 텐서와 연산 그래프를 관리하는 context를 두고, 연산 그래프를 기반으로 계산을 수행합니다. 또한 CPU, CUDA, Metal 등 다양한 백엔드를 지원할 수 있도록 설계되어 있으며, 백엔드별로 메모리 할당과 연산 스케줄링을 분리해 관리합니다. 이러한 구조 덕분에 가볍지만 단순한 수준을 넘는 유연성을 확보할 수 있었습니다.

다만 GGML은 이러한 장점과 함께 한계도 갖고 있습니다. C/C++ 기반 라이브러리 특성상 사용 난이도가 높고, Python 기반 프레임워크에 익숙한 사용자에게는 진입 장벽이 될 수 있습니다. 또한 모델 메타데이터 표현이 제한적이고, 토크나이저나 specia1 token, rope 설정과 같은 부가 정보를 함께 관리하는 데에는 불편함이 존재했습니다. 이러한 한계는 모델이 복잡해질수록 점점 더 문제가 되었습니다.

이러한 배경 속에서 GGML은 점차 GGUF(GGML Unified Format)로 발전하게 됩니다. GGUF는 GGML의 철학을 유지하면서도, 모델 실행에 필요한 메타데이터를 보다 명확하고 확장 가능하게 담기 위해 설계된 포맷입니다. 현재 llama.cpp 생태계에서도 GGML보다는 GGUF 사용이 권장되고 있으며, GGML은 점차 레거시 포맷의 위치로 이동하고 있습니다.

정리하자면, GGML은 “모델을 안전하게 저장한다”는 배포 포맷의 개념보다는, “모델을 가볍고 효율적으로 실행한다”는 목적에 충실한 라이브러리입니다. Python 객체 직렬화나 실행 가능한 코드 로딩과는 거리가 멀기 때문에, 구조적으로 RCE와 같은 취약점과도 무관한 편입니다. 다만 다른 모든 실행 엔진과 마찬가지로, 최종적인 안정성과 보안성은 런타임 구현과 운영 방식에 의해 결정된다는 점은 동일하게 적용됩니다.

GGUF (GGML Unified Format)

GGUF는 GGML을 기반으로 한 개선된 포맷입니다. 이름에서 알 수 있듯 '통합된(Unified)' 형식을 지향하며, 더 많은 메타데이터를 포함하고 확장성을 높였습니다. 이름을 붙일때에도

<BaseName><SizeLabel><FineTune><Version><Encoding><Type><Shard>.gguf 라는 네이밍 규칙을 만들었습니다. 더 많은 메타데이터를 포함할 수 있게 파일구조가 개선되었습니다.

GGUF 는 너무 많은 이야기들이 있는데 따로 다루도록 하겠습니다. 결론은 GGML 은 트랜스포머 모델 서빙 특화 배포 포맷이고, GGUF 는 여기서 관리적인 측면을 고도화한 포맷이라고 생각하면 될 것 같습니다.

GGML /GGUF 의 취약점 발생 가능성

GGML 이나 GGUF 둘다 Python 객체를 포함하지 않고 같은 의미로 pickle 이나 어떤 스크립트를 포함하지 않습니다. 그래서 모델 자체가 코드를 실행시킨다던지의 취약점은 발생하지 않습니다.

프레임워크를 알아보다 보니 정말 너무 많은 프레임워크들이 있더라구요, 그래서 GPT 에게 정리를 좀 해달라 했더니 어디서 사용하고 있는지도 모르는 녀석들까지 가져다 정리를 했네요,

그래서 결론은 모델은 여러 요구사항들을 해결하기 위해서 통합된 프레임워크를 사용했고, 그곳에서 발생하는 취약점은 대체로 pickle 의 직렬화를 사용해서 기대되는 문제점들이였습니다.

그래서 pickle 의 직렬화를 사용하지 않는다면, RCE 같은 치명적인 문제들은 모델 자체에서 생기지 않을 것 같습니다. 다만 모델 런타임 프레임워크에서 발생하는 취약점들은 전혀 다른 영역이니 사용에 참고해야할 것 같습니다.

틀린 정보가 있다면 알려주세요!

Batch Normalization

https://arxiv.org/pdf/1502.03167

Background

batch normalizaion 은 2015년에 제시된 ICS(Internal Covariate Shift) 문제를 줄일 수 있는 아이디어입니다. covariate shift 는 학습 때 활용한 데이터가 실제 추론에 사용되는 데이터간의 분포가 다르면 추론 성능에 악영향을 미칠 수 있다라는 주장인데 이게 신경망 내부에서도 발생할 것이다 라는 주장을 하며 생긴용어가 Internal Covariate Shift 라고 합니다. 아래 사진을 보면 직관적으로 이해가 될 것 같습니다. 신경망을 통과하면서 데이터의 분포가 달라지는 현상이 발생하는데

통과하는 레이어 수가 많아질수록 그 정도가 심해지기 때문에 당연히 추론이나 학습 성능에 문제가 생길 확률이 큽니다. Batch Normalizaion 은 기존의 정규화 과정에서 학습데이터마다 분포가 다른것을 배치별로 평균과 분산을 활용해 정규화하는 것 입니다.

나동빈님의 영상을 참고하여 알게 된 batch normalizaion가 현실에서는 하이퍼파라미터 의존도를 줄였으며, 학습속도를 향상시키고, 모델이 일반적으로 즉, 학습데이터에만 태스크를 잘 처리하도록 하는것이 아닌 실제 현상을 잘 반영시키게 된 효과가 있었다고 합니다.

그런데 논문에서는 ics 를 감소시킨다고 주장하였으나 실제로 증명하지는 못했다고 합니다. 그래서 그것을 증명하기 위한 How Does Batch Normalization Help Optimization?  라는 논문이 나왔습니다.

https://arxiv.org/pdf/1805.11604

우선 일반적으로 Batch Norm 을 적용시킨 네트워크가 Accuracy 가 가파른 폭으로 올라갔다는 것을 보여줍니다.

우측의 히스토그램을 보면 각 레이어의 분포를 나타내고 있는데요 가장우측의 Standard + Noisy BatchNorm 에서 Layer3 부터 분포가 갑작스럽게 변하여 ICS가 발생하고 있음을 볼 수 있습니다. ICS가 발생하고 있음에도 불구하고 왼쪽 그래프를 보면 학습성능이 우수함을 볼 수 있습니다.

즉 임의로 Batch Norm Layer 이후 바로 Noise 를 넣어 covariate shift 를 발생시켰을 때에도 BatchNorm 이 포함된 네트워크는 일반적인 네트워크보다 성능이 우수함을 보였습니다. 그래서 실험적으로 Batch Norm 이 ICS 문제를 해소할 수 있다는 이전 논문의 반박을 하였고, 심지어 ICS가 크게 발생함에도 불구하고 Batch Norm 이 있으면 성능이 좋아진다는 것을 보여준 사례가 되었습니다.

해당논문에서 ICS를 파라미터의 기울기 계산하여 ICS를 계산하는 방법을 제안했는데, 포스팅의 목적보다 너무 벗어나는것 같아 다루지 않겠습니다. 궁금하신분께서는 논문을 참고하시면 될 것 같습니다.

그렇다면 ICS 를 해소하지 못했음에도 불구하고 성능이 좋은 이유는 뭘까요? 논문에서는 Batch Norm 의 Smoothing 효과 때문이라고 설명합니다.

Loss Landscape 가 훨씬 더 예상 가능한 범위로 형성되면서 학습효과가 증대된다고 말하고 있습니다.

Batch Normalization Layer

미니배치의 평균값과 분산을 구해서 normalizaion 을 수행할 수 있습니다. 그리고 감마와 베타를 활용해 실제 output 을 내는데요, 여기서 감마와 베타가 실제 학습에 활용되는 파라미터입니다. 학습중에는 loss 를 최소화 하는 방향으로 감마와 베타를 찾아갈 것 입니다.

정규화에서 학습 파라미터를 사용하는 이유는 활성화 함수의 특징에 있습니다. sigmoid를 예시로 들면 어떤 구간에서는 매우 선형적으로 작동하기 때문에 표준정규분포로 정규화한 0과 1사이의 값에서 선형적으로 작동하게 됩니다. 그래서 감마와 베타를 활용해 non-linearity 를 지켜주고, 해당 정규화 레이어의 output 도 적절하게 내보낼 수 있게됩니다. 결론은 레이어의 입력을 정규화할 때는 linearity 를 주의해서 정규화 해야한다는 점 입니다.

Batch Normalization Layer 연산구분

batch normalization Layer 는 학습할때와 추론할 때 네트워크에서의 역할이 달라집니다. 학습할때 감마와 베타 파라미터를 학습시켜야 하지만 추론때에는 필요없습니다. 따라 해당 파라미터들을 고정하여 학습된 파라미터에 의한 값이 나와야합니다.

step 7 에서부터는 BN 이 training 모드로 네트워크에 있었던 것을 inference 모드로 바꿉니다. ( 파라미터 고정을 통해서 )

Batch Normalization Data Flow

입력 데이터 (X)

$$

X = \begin{bmatrix} [1,\ 2] \ [2,\ 4] \ [3,\ 6] \end{bmatrix}

$$

배치로 들어온 데이터

shape: (3, 2)

→ 샘플 3개, 각 샘플은 2차원 벡터

Linear Layer 통과

가중치와 bias를 이렇게 두겠습니:

$$ [ W = \begin{bmatrix} [1,0], \ [0,1] \end{bmatrix}, \quad b = [0,\ 0] ] $$

즉, 아무 변화 없는 선형층

$$ [ Z = XW + b = X ] $$

결과:

Z =
[
 [1, 2],
 [2, 4],
 [3, 6]
]

shape 그대로 (3, 2)

Batch Normalization

1️⃣ Batch Mean (μ)

feature별 평균:

$$ μ=[(1+2+3)/3, (2+4+6)/3]=[2, 4] $$

2️⃣ Batch Variance (σ²)

$$ σ2=[((1−2)2+(2−2)2+(3−2)2)/3,((2−4)2+(4−4)2+(6−4)2)/3]=[2/3, 8/3] $$

3️⃣ Normalize (x̂)

$$ \hat{x} = \frac{x - \mu}{\sqrt{\sigma^2 + \epsilon}} (ε 무시한다고 가정) $$

샘플별 계산

첫 번째 샘플

$$ [1,2] → [-1/\sqrt{2/3},\ -2/\sqrt{8/3}] ≈ [-1.22,\ -1.22] $$

두 번째

$$ [2,4] → [0,\ 0] $$

세 번째

$$ [3,6] → [1.22,\ 1.22] $$

결과:

X_hat =
[
 [-1.22, -1.22],
 [ 0.00,  0.00],
 [ 1.22,  1.22]
]

그리고 해당값에 gamma 와 betta 연산을 통해 Layer 를 통과시킵니다. 이처럼 batch norm 은 미니 배치의 피처별로 평균, 분산을 구해서 원본 데이터에 대입시키는 방법으로 Normalizaion 을 수행하게 됩니다.

Layer Normalization

arxiv.org

Layer Normalization 은 Batch Norm 이 RNN 에 적용하기 어려운 문제점을 해소하기 위해 제시된 방법입니다. RNN은 시간단위로 계산을 합니다. 따라서 미니배치의 각 피쳐마다 통계를 이용해 정규화하는 BN 의 경우에는 해당 스트림의 맥락을 반영하지 못합니다.

가장 큰 문제는 RNN 이나 NLP, 혹은 음성데이터의 경우는 배치마다 길이가 다릅니다.

샘플 1: "나는 밥을 먹었다"        (길이 4)
샘플 2: "오늘"                    (길이 1)
샘플 3: "어제 비가 와서 우산을 썼다" (길이 6)

이것을 BN 을 활용한 Layer output 을 사용한다면 샘플2 의 2,3 샘플1의 3,4 가 0이 됩니다. 그렇기 때문에 데이터의 의미를 충분히 반영하지 못하는 문제가 발생합니다. 이 문제는 시계열 데이터에도 그대로 적용됩니다. 이미지나 성적통계(국어는 국어끼리, 수학은 수학끼리) 와 같은 데이터가 아니라 피쳐하나가 다른 피쳐나 데이터에도 영향을 주는경우는 Batch 사이즈에 영향을 받지 않고 데이터의 의미를 잘 반영할 수 있는 LN 이 성능이 좋다고 주장합니다.

BN 과의 차이점

Batch Normalization은 미니배치 단위로 평균과 분산을 계산하여 정규화를 수행합니다. 반면 **Layer Normalization(LN)**은 이름 그대로 레이어 단위, 정확히는 하나의 샘플 내부 feature들에 대해서만 정규화를 수행합니다. 즉, 정규화의 기준이 완전히 다릅니다.

• Batch Normalization
  • 평균, 분산 계산 축: batch 방향
  • 같은 feature를 가진 여러 샘플을 함께 사용
• Layer Normalization
  • 평균, 분산 계산 축: feature 방향
  • 하나의 샘플 안에서만 계산

하나의 샘플 x = [x₁, x₂, ..., xₐ]에 대해:

$$ \mu = \frac{1}{d} \sum_{i=1}^{d} x_i $$

$$ \sigma^2 = \frac{1}{d} \sum_{i=1}^{d} (x_i - \mu)^2 $$

$$ \hat{x}_i = \frac{x_i - \mu}{\sqrt{\sigma^2 + \epsilon}} $$

그리고 Batch Normalization과 동일하게 scale, shift 파라미터를 적용합니다:

$$ y_i = \gamma_i \hat{x}_i + \beta_i $$

여기서 중요한 점은 γ, β는 feature 차원에 대해서만 존재하며 batch 크기와 무관하다는 것입니다.

위의 수식대로 같은 샘플을 가지고 레이어를 통과하는 연산을 수행해보겠습니다.

Layer Normalization Data Flow

입력 데이터 (X)

$$ X = \begin{bmatrix} [1,\ 2] \\ [2,\ 4] \\ [3,\ 6] \end{bmatrix} $$

shape: (3, 2)

→ 샘플 3개, 각 샘플은 2차원 벡터

Linear Layer 통과

가중치와 bias는 이전과 동일하게 설정합니다.

$$ Z = X $$

Layer Normalization 적용

Layer Normalization은 각 샘플마다 독립적으로 평균과 분산을 계산합니다.

첫 번째 샘플 [1, 2]

$$ \mu = (1 + 2) / 2 = 1.5 $$

$$ \sigma^2 = ((1 - 1.5)^2 + (2 - 1.5)^2) / 2 = 0.25 $$

정규화 결과:

$$ [1, 2] \rightarrow [-1, 1] $$

두 번째 샘플 [2, 4]

$$ \mu = 3,\quad \sigma^2 = 1 $$

정규화 결과:

$$ [2, 4] \rightarrow [-1, 1] $$

세 번째 샘플 [3, 6]

$$ \mu = 4.5,\quad \sigma^2 = 2.25 $$

정규화 결과:

$$ [3, 6] \rightarrow [-1, 1] $$

Layer Normalization 결과

X_hat =
[
 [-1,  1],
 [-1,  1],
 [-1,  1]
]

Transformer 구조에서 Layer Normalization 이 Batch Normalization 보다 적합한 이유

1. 시퀀스 길이 가변성과 Masking 문제

Transformer의 Self-Attention은 가변 길이 시퀀스를 처리해야 합니다. 입력형태는 각 문장마다 길이가 다르다는 점입니다. 이를 해결하기 위해 짧은 문장에는 padding을 추가하 attention mask를 사용해야 합니다.

Batch Normalization을 이러한 구조에 적용하면 심각한 문제가 발생합니다. BN은 배치와 시퀀스 차원 전체에 걸쳐 평균과 분산을 계산하는데 위에서 봤던 것 처럼 의미 없는 padding 토큰의 0 벡터가 통계에 포함됩니다. 결과적으로 문장 길이에 따라 정규화 통계가 왜곡되고, 같은 내용의 문장이라도 padding의 양에 따라 다르게 정규화될 수 있습니다.

반면 Layer Normalization은 각 토큰의 feature 차원에 대해서만 정규화를 수행합니다. 즉, 하나의 토큰 내부에서만 평균과 분산을 계산하기 때문에 padding 토큰이나 시퀀스 길이가 정규화 통계에 전혀 영향을 미치지 않습니다. 각 토큰은 독립적으로 정규화되므로 데이터의 의미가 충실히 반영되고 배치나 시퀀스 구조와 무관하게 일관된 정규화가 가능합니다.

2. Autoregressive Decoding과 배치 크기 불일치

Transformer Decoder는 추론 시 미래의 정보를 참조하지 못하도록 autoregressive 방식으로 동작합니다. 즉, 이전에 생성한 토큰을 바탕으로 다음 토큰을 하나씩 순차적으로 생성합니다. 이 과정에서 대부분의 경우 배치 크기가 1이 됩니다. 이는 Layer Normalization 논문에서 보여준것처럼 Batch Normalization에 치명적인 문제를 야기합니다.

Layer Normalization은 배치 크기와 무관하게 안정적으로 동작합니다. 배치 크기가 1이든 32든 정규화 결과는 일관되며, 학습 시 관찰한 성능이 추론 시에도 그대로 유지됩니다. 이는 Transformer Decoder의 생성 품질에 결정적으로 중요한 특성입니다.

3. Residual Connection과의 구조적 불일치

Transformer의 각 블록은 residual connection을 사용합니다: y = x + Sublayer(LN(x)). 이 구조가 중요한 이유는 gradient의 흐름 때문입니다. 역전파 시 ∂y/∂x = 1 + ∂Sublayer/∂x 가 되어, gradient가 항상 직접 흐를 수 있는 경로(identity mapping)가 보장됩니다. 이는 깊은 네트워크에서 gradient vanishing 문제를 해결하는 핵심 메커니즘입니다.

만약 Batch Normalization을 residual path에 사용하면, BN의 출력이 배치 통계에 의존하기 때문에 residual path에 batch-dependent noise가 주입됩니다. 이는 gradient flow를 불안정하게 만들고, 특히 깊은 Transformer에서는 gradient 폭발이나 소실을 일으킬 수 있습니다. 실제로 Post-LN Transformer(residual 후에 LN을 적용)는 레이어가 깊어질수록 학습이 불안정해지는 것으로 알려져 있으며, Pre-LN Transformer(residual 전에 LN을 적용)가 더 안정적인 학습을 보입니다. BN은 이러한 residual connection의 특성과 근본적으로 충돌합니다.

Layer Normalization은 각 샘플을 독립적으로 정규화하기 때문에 배치에 의존하지 않습니다. 따라서 residual path의 gradient flow를 방해하지 않으며, 수십 개의 레이어로 이루어진 깊은 Transformer에서도 안정적인 학습이 가능합니다. 이러한 구조적 조화가 Transformer가 Layer Normalization을 사용하는 또 다른 중요한 이유입니다.