배경

Qwen2.5-VL-32B를 vLLM으로 서빙하면서 영상을 입력으로 넣고 있었습니다. 그런데 영상 하나를 보낼 때마다 서버 로그가 유난히 지저분하더군요. 모델이 죽은 것도 아니고 응답은 200 OK로 잘 돌아오는데, 그 사이에 경고가 우르르 쏟아졌습니다.

솔직히 처음엔 그냥 넘어가려 했습니다. 근데 영상이 좀 길거나 살짝 깨져 있으면 로그가 화면을 가득 채워서, 정작 봐야 할 줄을 못 찾겠더라고요. "이거 한 번 파보자" 하고 시작한 게 이번 PR입니다.

깨진 영상을 넣었을 때 실제로 찍힌 로그입니다.

[h264 @ 0x7fbfa4089200] Invalid NAL unit size (0 > 1404).
[h264 @ 0x7fbfa4089200] Error splitting the input into NAL units.
[h264 @ 0x7fbfa4184c80] reference picture missing during reorder
[h264 @ 0x7fbfa4184c80] Missing reference picture, default is 65576
... (이런 줄이 십수 개) ...
(APIServer pid=1) WARNING [video.py:210] Failed to grab frame 17 during video loading. This frame will be skipped.
(APIServer pid=1) WARNING [video.py:232] Video loading completed with 1 broken/unreadable frames. Expected 26 frames but only loaded 25 frames.

여기서 줄들의 출처가 두 종류라는 게 보입니다.

• WARNING [video.py:...] — vLLM이 파이썬 logger로 찍는 줄
• [h264 @ ...] — 그 위에 잔뜩 깔린, 정체불명의 줄들

일단 vLLM이 찍는 쪽부터 추적해 봤습니다.

1차 추적: vLLM이 깨진 프레임마다 경고를 출력

vLLM의 영상 디코딩은 기본적으로 OpenCV 백엔드를 씁니다. vllm/multimodal/video.py의 프레임 읽기 루프를 보면 이렇게 생겼습니다.

for idx in range(max_frame_idx + 1):
    ok = cap.grab()
    if not ok:
        if idx in frame_indices:
            logger.warning(
                "Failed to grab frame %d during video loading. "
                "This frame will be skipped.",
                idx,
            )
        continue
    ...
# 루프가 끝난 뒤, 요약 한 줄
logger.warning(
    "Video loading completed with %d broken/unreadable frames. "
    "Expected %d frames but only loaded %d frames.",
    ...
)

문제가 보이시나요? 깨진 프레임을 만날 때마다 logger.warning을 한 줄씩 찍습니다. 그런데 루프가 끝나면 "총 N개가 깨졌다"는 요약 줄이 따로 또 찍힙니다.

즉, 프레임별 경고는 요약 줄에 이미 다 담겨 있는 정보의 중복입니다. 깨진 프레임이 1개면 별 티가 안 나지만, 많으면 같은 패턴의 줄이 그 수만큼 반복됩니다.

"근데 이게 실제로 몇 줄까지 가는데?" 가 궁금했습니다. 다행히 영상 디코딩은 GPU도 모델도 필요 없는, 순수 CPU(OpenCV) 작업입니다. 그래서 vLLM의 읽기 루프를 그대로 흉내 내서, 일부러 꼬리를 잘라낸 영상으로 측정했습니다.

깨진 프레임 수에 거의 1:1로 비례했습니다.

Qwen2.5-VL은 긴 영상이면 수백 프레임까지 샘플합니다. 그러니 거의 다 깨진 긴 영상 하나에 경고가 수백 줄까지 갈 수 있다는 뜻입니다. 요청 한 번에요.

물론 "폭증"이라고 부를 정도의 장애는 아닙니다. 그냥 눈에 거슬리고, 진짜 봐야 할 로그를 묻어버리는 수준이죠. 딱 고쳐서 깔끔하게 만들 만한 크기였습니다. sglang 에서 처럼 base64 이미지를 모두 다 찍는 문제는 아니였던거죠

근데 여기서 한 가지 짚고 넘어가야 할 부분은 정작 줄 수가 제일 많았던 [h264 @ ...] 쪽이었습니다. 깨진 프레임 1개짜리 영상인데도 십수 줄이 찍혔거든요.

생각해보면 당연합니다. 이 줄들은 vLLM이 찍는 게 아닙니다. OpenCV가 내부적으로 쓰는 ffmpeg/libav(C 라이브러리) 가 디코딩에 실패하면서 stderr로 직접 토해내는 메시지입니다. 파이썬 logger를 거치지 않기 때문에 VLLM_LOGGING_LEVEL로도 안 잡힙니다.

확인해 보니 vLLM은 이 ffmpeg 로그 레벨을 따로 설정하지 않더군요. 이건 환경변수로 따로 눌러줘야 합니다.

# 서버 띄우기 전에 ffmpeg 로그 레벨을 낮추면 [h264 @ ...] 줄이 사라진다
OPENCV_FFMPEG_LOGLEVEL=-8 vllm serve ...

그래서 이번 PR의 범위를 명확히 정했습니다. 이 PR은 vLLM이 직접 찍는 중복 경고만 정리합니다. ffmpeg 쪽 노이즈는 레이어가 다른 별개 문제라 섞지 않았습니다. (괜히 욕심내서 한 PR에 두 개를 묶으면 리뷰만 복잡해집니다.)

수정: 딱 6줄

해법은 단순합니다. 프레임별 경고를 warning에서 debug로 내리고, 요약 줄은 warning 그대로 둡니다. 정보 손실은 없습니다 — 총 몇 개가 깨졌는지는 요약 줄에 그대로 남으니까요.

-                    logger.warning(
+                    logger.debug(
                         "Failed to grab frame %d during video loading. "
                         "This frame will be skipped.",
                         idx,
                     )

이런 식으로 프레임 단위로 찍던 줄 다섯 군데를 debug로 바꿨습니다. 로직은 한 글자도 안 건드렸고요.

근데 왜 debug로 바꾸면 줄어드는 거죠?

이게 헷갈릴 수 있는 부분입니다. 메시지를 지운 것도 아닌데 왜 안 보일까요? vLLM의 기본 로그 레벨은 INFO입니다. 로거는 자기 레벨 이상만 출력합니다.

• WARNING(30)은 INFO(20)보다 높음 → 보임
• DEBUG(10)는 INFO(20)보다 낮음 → 기본값에선 걸러져서 안 보임

즉 "삭제"가 아니라 "기준선 아래로 내린" 겁니다. 디버깅할 때 프레임별 상세가 필요하면 VLLM_LOGGING_LEVEL=DEBUG로 다시 켜면 됩니다.

직접 재현한 before/after는 이렇습니다. (32프레임 샘플, 21개 깨진 영상)

[before] main 브랜치 (프레임별 = warning)
  WARNING Failed to grab frame 42 during video loading. This frame will be skipped.
  WARNING Failed to grab frame 46 during video loading. This frame will be skipped.
  ... (19줄 더) ...
  WARNING Video loading completed with 21 broken/unreadable frames. Expected 32 frames but only loaded 11 frames.
  => WARNING 22줄

[after] PR 적용 (프레임별 = debug)
  WARNING Video loading completed with 21 broken/unreadable frames. Expected 32 frames but only loaded 11 frames.
  => WARNING 1줄

22줄이 1줄로. 앞서 본 긴 영상 케이스(486줄)도 똑같이 1줄로 줄어듭니다.

PR을 올리고 나서 — DCO와의 싸움

코드는 6줄이었는데, 정작 시간을 잡아먹은 건 PR 절차였습니다. 이 얘기가 오픈소스 처음 기여하는 분들께 더 도움이 될 것 같네요.

vLLM은 모든 커밋에 DCO(Developer Certificate of Origin) 서명을 요구합니다. 커밋 메시지 끝에 이런 줄이 있어야 합니다.

Signed-off-by: 이름 <이메일>

git commit -s를 붙이면 자동으로 들어갑니다. 이게 단순 권장사항이 아니라 봇이 검사하는 강제 체크라, 없으면 PR이 빨간불입니다.

저는 처음에 이 줄을 빼고 올렸다가 보기 좋게 막혔습니다. 게다가 GitHub 웹에서 "Update branch" 버튼을 두 번 눌렀더니, 서명 없는 머지 커밋 2개가 추가로 끼어들어서 더 꼬였죠. 메인테이너 피드백도 정확히 그 지점이었습니다.

"DCO won't pass even after a rerun. You didn't sign off your own commits. Create a new branch and cherry-pick your changes, then overwrite the old branch."

해결은 깔끔하게 다시 쌓는 것이었습니다. 머지 커밋들을 버리고, 최신 main 위에 서명된 단일 커밋으로 재구성한 뒤 force-push 했습니다.

git fetch origin
git checkout -B fix/video-broken-frame-log-noise origin/main
git cherry-pick --signoff <원래_변경_커밋>   # 변경 재적용 + 서명 추가
git push -f fork fix/video-broken-frame-log-noise

여기서 알아둘 점 하나. force-push해도 새 PR을 다시 열 필요는 없습니다. 같은 브랜치를 덮어쓰면 기존 PR이 그 커밋으로 그대로 갱신됩니다. 번호도, 리뷰도, 댓글도 다 유지돼요. 메인테이너가 말한 "overwrite the old branch"가 바로 이겁니다.

재구성 후 DCO는 초록불이 됐고, 승인도 풀리지 않고 남아 있었습니다.

PR이 ready 라벨을 받으면 그제서야 풀 CI가 돕니다. 잡이 수십 개라 시간이 꽤 걸리고, 중간중간 우리 변경과 무관한 잡이 빨갛게 뜨기도 합니다. 실제로 이번에도 두 개가 실패했는데,

• test_traces — 추적(tracing) span 0개 (flaky)
• test_image_embedding_models[llava] — llava 모델 config 로딩 에러

둘 다 영상 로그와는 코드 경로가 겹치지 않는, 전형적인 flaky/인프라 실패였습니다. 이런 건 작성자가 고칠 게 아니라 재실행으로 풀립니다. 빨간불이 떴다고 다 내 잘못은 아니다 — 로그를 열어 실제 에러를 확인하는 습관이 중요했습니다.

마치며

겨우 6줄짜리, 그것도 로그 레벨만 바꾸는 PR이었습니다. 그런데 그 6줄에 도달하기까지가 더 길었네요.

• 거슬리는 로그를 그냥 넘기지 않고 출처를 끝까지 쪼개본 것 (vLLM vs ffmpeg)
• "심각한가?"를 감이 아니라 숫자로 재현해 본 것
• 작은 변경이라도 요약 줄은 남겨서 정보 손실을 없앤 것
• DCO/CI 같은 절차에서 막히고 푸는 경험

오픈소스 기여라고 거창한 기능을 넣을 필요는 없었습니다. 매일 보던 거슬리는 로그 한 줄도, 파고들면 충분히 깔끔한 PR이 된다는 것을 알게되었습니다.

읽어주셔서 감사합니다.

OCR 파이프라인을 만지다가 SGLang에 버그 리포트랑 PR까지 올리게 된 과정을 정리해봤는데요, 생각보다 원인이 여러 겹으로 얽혀 있었습니다.

첫오픈소스 기여( Openwebui vLLM Usage )  이후 두번째 오픈소스 기여인데, 지난번에는 docs 의 usage 정도 기여했지만 이번에는 버그 해결을 제안한 기여여서 기록하고자 합니다.

시작은 평범한 OCR 작업이었습니다

Qwen3-VL-8B-Instruct를 SGLang으로 띄워놓고 문서 OCR을 돌리고 있었는데요. 구성은 이랬습니다.

docker run -d --restart unless-stopped --gpus all -p 1011:30000 \
  -v /models:/models --ipc=host \
  lmsysorg/sglang:v0.5.10.post1-cu130 python3 -m sglang.launch_server \
  --model-path /models/qwen3-vl-8b-instruct --host 0.0.0.0 --port 30000 \
  --tp 1 --mem-fraction-static 0.3 --max-running-requests 256

PDF를 300DPI로 래스터화해서 이미지로 만든 다음 모델에 넣는, 그냥 흔한 흐름이었습니다. 원본 PDF는 10MB 남짓이었고요.

그런데 요청 하나를 보냈더니 응답이 1분 50초가 넘게 걸리더라고요. 그것도 모자라서, 터미널 로그창에 base64 인코딩된 이미지 raw 데이터가 끝도 없이 주르륵 찍히기 시작했습니다. AAAAAA... 같은 게 몇 분 동안 화면을 가득 채우는데, 솔직히 처음엔 서버가 죽은 줄 알았습니다.

재밌는 건 같은 파일을 vLLM에 넣었을 때였는데요. vLLM은 PIL이 "decompression bomb이 의심된다"는 경고를 띄우고 깔끔하게 넘어갔습니다. 이미지 raw가 로그에 토해지는 일도 없었고요. 같은 입력인데 두 프레임워크의 반응이 이렇게 다른 게 이상해서, 코드를 직접 까보기로 했습니다.

1차 용의자: 왜 raw 이미지가 로그에 찍히나

가장 먼저 의심한 건 요청 로깅이었습니다. SGLang에는 --log-requests 옵션이 있어서 요청 내용을 로그에 남길 수 있거든요. 그런데 저는 그 옵션을 켠 적이 없었습니다. 실제로 코드를 보니 log_requests 기본값은 False였고요.

log_requests: bool = False

플래그를 안 켰는데 어떻게 이미지가 로그에 남았을까. 여기서 한참 헤맸습니다. 정상 로깅 경로는 전부 이 플래그 뒤에 가려져 있었으니까요.

결국 답은 예외 처리 쪽에 있었습니다. 이미지를 디코딩하는 base_processor.py에서, 제가 쓰던 v0.5.10.post1 버전은 이렇게 되어 있었거든요.

except Exception as e:
    raise RuntimeError(f"Error while loading data {data}: {e}")

여기 {data}가 문제였습니다. 이미지 로딩이 실패하면 그 예외 메시지 안에 입력 데이터 전체, 그러니까 수십~백 MB짜리 base64 문자열이 통째로 들어갑니다. 그리고 이 RuntimeError가 위로 전파되면서 serving_base.py의

except Exception as e:
    logger.exception(f"Error in request: {e}")

여기서 그대로 로그로 출력됩니다. --log-requests와는 아무 상관 없는 경로였던 거죠. 디코딩이 실패하기만 하면 무조건 찍힙니다.

그리고 한 가지 더. 제가 1분 50초나 기다린 이유가 사실 이미지 디코딩이 아니라 이 로깅 자체였을 가능성이 큽니다. 100MB가 넘는 문자열을 f-string으로 만들고 stdout으로 쏟아내는 동안 CPU 코어 하나가 꼬박 100%로 돌거든요. 추론은 시작도 안 했는데 말이죠.

그럼 애초에 예외는 왜 났을까

여기서 vLLM이 보여준 경고가 결정적인 힌트였습니다. "decompression bomb이 의심된다"는 그 메시지, 바로 PIL 내장 보호 장치가 띄우는 겁니다.

PIL은 이미지의 픽셀 수가 MAX_IMAGE_PIXELS(기본값 89,478,485)를 넘으면 경고를, 그 2배인 178,956,970을 넘으면 아예 DecompressionBombError를 던집니다. 디스크상 파일 크기가 아니라 압축을 푼 픽셀 수 기준이라는 게 핵심인데요.

300DPI로 키운 PDF 페이지는 이 한계를 넘기기 딱 좋습니다. 큰 용지를 고해상도로 래스터화하면 1억~2억 픽셀은 우습게 나오니까요. 원본 파일이 10MB라도 픽셀로 펼치면 전혀 다른 이야기가 됩니다.

정리하면 이렇게 됩니다.

1. 큰 이미지가 들어옴 → PIL이 픽셀 수 한계 초과를 감지하고 DecompressionBombError를 던짐
2. SGLang이 그 예외를 잡아서 base64 원문과 함께 다시 던짐
3. logger.exception이 그 100MB짜리 메시지를 로그로 출력 → CPU 점유, 로그 폭발

vLLM은 1번에서 PIL 메시지만 보여주고 끝냈는데, SGLang(해당 버전)은 거기에 raw 데이터까지 얹어서 토해낸 셈이었습니다.

더 심각한 문제: 메모리와 DoS

여기까지도 충분히 골치 아픈데, 테스트하다 보니 더 위험한 게 보였습니다. 요청 하나 처리할 때마다 RSS가 1GB씩 치솟았다가 끝나면 풀리더라고요.

생각해보면 당연합니다. HTTP 바디(133MB) → UTF-8 문자열 → base64 디코드 → PIL 디코딩(1.4억 픽셀 RGB면 그것만 430MB가 넘습니다) → 리사이즈 복사본… 단계마다 큰 객체가 새로 생기니까요.

문제는 제가 --max-running-requests 256으로 띄워놨다는 점이었습니다. 이런 요청이 동시에 몇 개만 들어와도 메모리가 선형으로 불어납니다. 8개면 8GB, 16개면 16GB. GPU 추론에 닿기도 전에 서버가 OOM으로 죽을 수 있다는 뜻이죠.

이게 무서운 건, 공격자 입장에서 GPU 한 톨 쓸 필요가 없다는 겁니다. 유효한 이미지일 필요도 없습니다. 그냥 큰 base64 문자열을 /v1/chat/completions에 몇 번 던지는 것만으로 CPU랑 메모리를 갉아먹을 수 있으니까요. 단순한 성능 이슈를 넘어 사실상 추론 이전 단계의 DoS 취약점입니다.

이미 고쳐진 부분과 아직 안 고쳐진 부분

이슈를 정리하다가 알게 된 건데요, 위에서 본 그 무제한 {data} 로깅은  PR #27451에서 이미 손을 봤더라고요. 다만 제가 쓰던 v0.5.10.post1에는 아직 안 들어간 상태였습니다. 최신 main에서는 이렇게 100자로 잘립니다.

except Exception as e:
    data_str = str(data)
    if len(data_str) > 100:
        data_str = data_str[:100] + "..."
    raise RuntimeError(f"Error while loading data {data_str}: {e}") from e

이걸 보고 "아 그럼 해결됐네" 하고 넘어갈 뻔했는데, 곱씹어보니 이 truncation이 막는 건 깨진 입력 케이스뿐이었습니다. 즉 Image.open이 실패해서 예외 메시지에만 데이터가 실리던 경로요.

정작 제 실제 상황, 그러니까 멀쩡하지만 그냥 거대한 이미지는 예외를 안 냅니다. 디코딩에 성공하거든요. 다만 그 디코딩이 느리고 메모리를 많이 먹을 뿐입니다. 이 경로는 예외 메시지를 안 거치니까 truncation과는 무관하고, 최신 버전에서도 그대로 느립니다. DoS 가능성도 살아 있고요.

그래서 이슈에 "#27451이 고친 것과 못 고친 것"을 명확히 나눠서 적었습니다. 누가 봐도 "어 이거 이미 고쳐진 거 아니야?"라고 할 만한 부분이라서요.

제안한 수정: 디코딩 전에 막자

해결 방향은 단순합니다. PIL의 Image.open은 헤더만 읽습니다. 즉 실제 픽셀을 디코딩하기 전에 이미지의 가로·세로 크기를 이미 알 수 있다는 거죠. 그러니 비싼 디코딩에 들어가기 전에 픽셀 수를 먼저 확인하고, 한계를 넘으면 깔끔하게 거부하면 됩니다.

def _check_image_pixels(width: int, height: int) -> None:
    max_pixels = envs.SGLANG_IMAGE_MAX_DECODE_PIXELS.get()
    num_pixels = width * height
    if max_pixels > 0 and num_pixels > max_pixels:
        raise ValueError(
            f"Image is too large to decode: {width}x{height} = {num_pixels} pixels "
            f"exceeds the limit of {max_pixels} pixels. Raise "
            f"SGLANG_IMAGE_MAX_DECODE_PIXELS to allow larger images."
        )

그리고 이미지를 여는 지점에서 디코딩(.convert())이 일어나기 전에 이 검사를 끼워 넣었습니다.

image = Image.open(BytesIO(image_bytes))
_check_image_pixels(image.width, image.height)
return image

한계값은 SGLANG_IMAGE_MAX_DECODE_PIXELS 환경변수로 빼뒀습니다. 기본값은 PIL의 bomb 임계값과 동일한 89,478,485로 잡았고요. OCR처럼 정말 큰 이미지를 다뤄야 하는 분들은 이 값을 올리면 되고, 0으로 두면 검사를 끌 수 있습니다.

이렇게 하면 거대한 이미지가 들어와도 디코딩 전에 명확한 ValueError로 막히니까, 430MB짜리 픽셀 버퍼를 만들 일도, raw 데이터를 로그에 토할 일도 없습니다. 느려질 일도, 메모리가 터질 일도 없고요. vLLM이 PIL 경고로 짧게 끊고 가는 것과 비슷한 동작이 됩니다.

물론 한계도 솔직히 적어뒀습니다. 이 가드는 유효한 헤더가 있어야 동작합니다. 아예 깨진 base64는 Image.open 자체가 먼저 터지니까요. 그쪽은 앞서 본 #27451이 담당하는 영역이고, 제 PR은 "멀쩡하지만 너무 큰" 케이스를 맡는 식으로 역할이 갈립니다.

마치며

처음엔 그냥 "로그가 좀 많이 찍히네?" 정도로 보였는데, 파고들수록 성능 문제 → 정보 노출 → DoS 가능성까지 세 겹으로 엮여 있던 사례였습니다. 그리고 "이미 PR로 고쳐진 것 같다"는 지점에서 한 번 더 의심해본 게 결과적으로 맞았고요. 겉보기 증상 하나에 원인이 하나만 있는 건 아니라는 걸 다시 느꼈습니다.

작업한 내용은 아래에 올려뒀습니다.

• 이슈: sgl-project/sglang#28587
• PR: sgl-project/sglang#28588

혹시 비슷하게 VLM 서빙에서 큰 이미지를 다루신다면, 들어오는 이미지의 픽셀 수에 상한을 걸어두시는 걸 권합니다. 파일 크기만 보면 안 되고요, 압축을 풀었을 때의 픽셀 수가 진짜 비용이라는 점을 꼭 기억하시면 좋겠습니다.

배경

머신러닝 디자인패턴을 읽던 중 4장 distilling 에 관한 기법이 나와 찾아보게 되었습니다.

요약

지금까지으 대규모 머신러닝 시스템은 학습과 배포단계에서 같으느 모델을 사용했는데 이때문에 추론 레벨에서 리소스가 커진다는 단점이 있었습니다. 그래서 거대한 모델로부터 지식을 하나의 작은 모델로 전이하는 방법을 통해 이 제약을 극복하려고 합니다. 이것이 “증류” 의 표현입니다.

기존의 hard label 은 [1,0,0] 처럼 정확한 확률을 알려주었는데, 실제로는 고양이를 닮은 개가 있을수도 있으니 [0.6,0.4,0] 같은 label 도 의미있는 지식일 수 있다는것이 아이디어 입니다.

그래서 정리하자면 거대한 모델에서 산출된 마지막 레이어의 값들을 학습에 활용하는 soft target 으로 활용하자는 것입니다.

Distillation

기존의 신경망은 클래스 분류 태스크를 수행할 때 output layer 에 softmax 를 취해 logit 을 변환합니다.

일반적으로 T 는 1로 세팅되어 있습니다. T를 높게 할수록 클래스 확률값이 soft 하게 출력됩니다.

T 가 커질수록 클래스 값들이 soft 해지는 것을 알 수 있습니다.

논문에서 제안한 “증류” 의 방식은 거대한 모델을 teacher model 로 특수한 목적으로 만들 작은 모델을 Student(distilled model) 이라 합니다.

t를 최대로 하고, 기존의 transfer dataset 을 teacher 모델에 넣고 soft label (1) 을 얻습니다. 그리고 student 모델에 inference 해서 soft prediction(2) 을 얻습니다. 그리고 student model 에서 hard prediction(3)결과를 얻습니다. 그리고 (1) 와 (2) 의 cross entropy , (2) 와 (3) 의 cross entropy 를 가중합 하는 방식이 성능이 좋다고 합니다.

cross entropy gradient 의 는 아래와 같이 나타냅니다. 여기서 Vi 는 큰 모델의 결과값을 나타내고 pi 는 soft label 의 확률값을 의미합니다. 그러니까 qi 와 pi 의 cross entropy 를 계산하는 문제가 logit 간의 차이를 근사하는 문제로 변환시키고 있음을 의미합니다.

증류에서 Teacher Model 과 Student 의 모델 output 차이를 활용해 gradient 계산을 하려는 움직임입니다.

여기서 T가 충분히 크다면 테일러 근사를 활용해 아래와 같이 나타낼 수 있습니다

그리고 logit 의 평균이 0 이라고 가정한다면 0 으로 변환되니

student model output 에 대한 Cross entropy 변화율 즉 gradient 는 nt^1 에 반비례하게 됩니다. 그래서 결론은 “T가 충분히 큰 상황에서 logit 들의 평균이 0 으로 주어졌다면, Distillation 은 1/nt^2 을 최소화 하는 문제가 됩니다.

반대로 T 가 낮다면 gradient 를 최대화 시키니 모델이 너무 작다면 중간정도의 temperature 를 사용하는것이 좋다고 주장합니다

기여도

본 논문의 가장 큰 기여는 다음 세 가지로 정리할 수 있습니다.

1. Soft Target을 활용한 지식 전달 방식의 정식화

기존의 분류 모델은 정답 레이블(one-hot 벡터)만을 학습 신호로 사용하였습니다. 그러나 본 논문은 모델의 출력 확률 분포 전체가 지식이라는 관점을 제시하였습니다.

특히 Teacher 모델이 출력한 softmax 확률 분포에는 다음과 같은 정보가 포함되어 있습니다.

• 클래스 간 유사도
• 모델이 헷갈리는 정도
• 데이터 분포에 대한 암묵적 구조

이를 Student 모델이 학습하도록 만들면, 단순히 정답을 맞추는 것이 아니라 Teacher의 판단 구조 자체를 모방하게 됩니다.

이는 이후 모든 Knowledge Distillation 연구의 출발점이 되었습니다.

2. Temperature 기반 확률 분포 제어 메커니즘 제안

논문은 softmax 함수에 temperature TTT를 도입하여 확률 분포를 조절하는 방식을 제안하였습니다.

• T=1일 경우 일반적인 softmax
• T>1일 경우 분포가 평탄해짐

Temperature를 높이면 모델의 확신(confidence)이 낮아지고, 클래스 간 상대적 관계 정보가 더 잘 드러납니다. 이로 인해 Student 모델은 단순 정답이 아니라 확률 구조 자체를 학습하게 됩니다.

이러한 수학적 근사 분석을 통해, KD가 결국 logit 간 차이를 줄이는 문제로 수렴한다는 것을 보인 점 역시 중요한 기여입니다.

3. 앙상블 모델의 압축 방법 제시

논문은 여러 개의 모델을 앙상블하여 얻은 고성능 Teacher 모델을 단일 Student 모델로 압축할 수 있음을 보였습니다.

이는 다음과 같은 실용적 의미를 가집니다.

• 학습 단계에서는 대규모 모델 사용
• 배포 단계에서는 경량 모델 사용
• 추론 속도 향상 및 리소스 절감

즉, 학습과 배포의 구조적 분리를 가능하게 한 기법이라는 점에서 산업적 의미가 매우 큽니다.

실험결과

MNIST

MNIST 실험에서는 다음과 같은 설정을 사용하였습니다.

• Teacher 모델: 여러 개의 모델을 앙상블한 고성능 네트워크
• Student 모델: 상대적으로 작은 네트워크

결과적으로 Student 모델은 다음과 같은 특징을 보였습니다.

1. 일반적인 hard label 학습 대비 더 낮은 error rate
2. Teacher의 성능에 근접한 정확도 달성
3. 과적합 감소 효과

특히 데이터가 충분하지 않은 상황에서도 soft target을 사용하면 일반화 성능이 개선되는 경향을 보였습니다.

이는 soft target이 일종의 regularizer 역할을 수행한다는 것을 의미합니다.

Speech Recognition

음성 인식 실험에서는 대규모 acoustic model을 Teacher로 사용하였습니다.

Teacher는 매우 복잡하고 큰 네트워크였으며, 직접 배포하기에는 비효율적이었습니다.

Distillation을 적용한 Student 모델은:

• 파라미터 수 감소
• 추론 속도 개선
• 정확도는 Teacher에 근접

특히 soft target 기반 학습이 hard label 기반 학습보다 안정적인 수렴 특성을 보였습니다.

이는 KD가 classification뿐 아니라 sequence 기반 문제에도 적용 가능함을 보여주는 사례입니다.

참교자료 :

[논문 리뷰] Distilling the Knowledge in a Neural Network​

배경

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 같은 치명적인 문제들은 모델 자체에서 생기지 않을 것 같습니다. 다만 모델 런타임 프레임워크에서 발생하는 취약점들은 전혀 다른 영역이니 사용에 참고해야할 것 같습니다.

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

배경

머신러닝 디자인패턴 4장 모델 학습 디자인패턴 읽던 중 과적합이 사용될 수 있는 사례에 대한 설명을 읽었습니다. 닫힌 해가 없는 경우 즉 데이터가 현실을 100% 반영할 수 있는 경우 계산 overhead 극복을 위해 ML 설계가 도움이 되는데, 이때 과적합이 더 적합하다는 내용을 읽었습니다. 또한 uniform approximation theorem 에서 하나의 hidden layer 와 activation function 이 있는 Network 에 의해 근사될 수 있다는 실험이 많이 증명되었습니다. 이의 연장선으로 조금 뒤 현실세계에서는 모든 입력을 테이블로 만드는 것이 불가능한 경우가 많으니 입력 공간을 샘플링해서 데이터를 만들어내는 몬테카를로 접근방식을 제안했습니다.

그리고 몬테카를로 방법 대신 머신러닝을 활용한다면 PDE 의 데이터 기반 이산화를만들어낼 수 있다고 합니다. 즉, 현실세계의 현상을 모델링하는 PDE 를 직접만들지 말고 머신러닝을 활용해서 확보된 데이터필드를 어떻게 섞어야하는지를 학습시키는 것 입니다. 함수없이 함수에 근사시키려는 노력입니다. 

그리고 본 포스팅에서 리뷰할 논문이 바로 이에 대한 효과를 잘 보여준 Learning data driven discretization for partial differential equations 입니다. 

요약

PDE 의 수치적 솔루션은 다차원의 시공간적 피처들을 잘 해결하지 못합니다. ( 차원의 저주 ) 이걸 해결하려면 너무 많은 양의 계산이 필요하기 때문인데요. 기존의 유일한 방법은 좀 제대로하지 못할지라도 근사시키려고 노력하는 것 입니다. 근데 물론 그것도 어마어마하게 어렵습니다. 그래서 해당 논문에서는 현상에 PDE 를 근사시키는 것이 아니라 data driven 방정식을 제안합니다. PDE를 일반적으로 알려진 방정식에 기반해서 neural network 를 사용해 차원의 저주 문제를 해결할 방법입니다.

다시 정리하자면 기존 PDE 문제를 해결할 때 접근은 잘 정의된 PDE를 얼마나 정확하게 근사시킬 것인지 였지만, 이제는 PDE를 정확하게 근사하지 않고 이산화된 연산자를 데이터에 기반해 학습시키자는 관점입니다.

일반적으로 대부분의 물리현상은 PDE 로 표현할 수 있고 시간에 따라서 변하는 연속적인 물리량은 아래와 같이 나타낼 수 있습니다. 문제는 이걸 컴퓨터로 풀어내는 방법인데요,

컴퓨터는 연속적인 데이터를 직접 다룰 수 없기 때문에 우리가 인지할 수 있는 grid 위에 이산적으로 표시하게 됩니다. 그리고 최대한 연속적으로 다루려고 노력하지요. 이때 유한차분 (FD) 을 통해서 시간에 대한 ODE Form 으로 바뀌게 됩니다.

여기서 F 는 이제 이것들을 gird 주변의 값들로 근사해야 하는데,

여기서 a(i)^n 을 신경망으로 학습해서 국소적 구조에 따라 현실에 다가가도록 설계하는 것 입니다. 고해상도 시뮬레이션 데이터로 학습 데이터를 만들고 해당 식에 등장하는 미분항들의 이산근사식( 여기서는 sigma alpha ^ n v(i) ) 을 학습합니다. 이 과정이 계산비용 측면에서의 트레이드 오프를 만드는데 이건 전체 필드가 아닌 작은 부분에서 고해상도 시뮬레이션 데이터를 추출해 완화할 수 있습니다. 이렇게 하면 훨씬 큰 시스템에[서도 낮은 공간에서 얻은 데이터로 계산할 수 있습니다.

→ 작은 지역에서 solution manifold 위의 실제 현상을 잘 근사하면 , 그 국소적 이산화 규칙(ML 모델)이 더 큰 시스템에서도 재사용 가능하다고 하는 것 입니다. 그러니까 중요한 것은 완벽한 적합이 아니라 국소 영역에서 실제 물리계의 역학 상태를 잘 포착(근사)하는 것입니다.

실제로 신경망을 활용해 실제 현상에 기여하는 비교를 해보면 방정식으로 근사하는 것보다 성능이 더 좋다고 주장합니다.

기여도

이 논문의 가장 큰 기여는 PDE 해법 자체가 아니라, PDE 이산화를 학습의 대상으로 재정의했다는 점입니다. 기존 수치해석은 미분 연산자를 보편적으로 근사하려고 시도했는데요, 본 연구는 해가 실제로 존재하는 solution manifold 위에서만 유효한 국소 이산화 규칙을 데이터로부터 학습합니다.

구체적으로는 다음과 같은 기여가 있습니다.

첫째, equation-specific discretization이라는 개념을 명확히 제시합니다. 유한차분 계수는 보편적이어야 한다는 기존 관점에서 벗어나, 방정식과 국소 상태에 따라 달라지는 이산화 계수를 허용함으로써 under-resolved 조건에서도 높은 정확도를 달성합니다.

둘째, solution manifold 기반 학습 관점을 제시합니다. 신경망은 전체 함수 공간을 근사하는 것이 아니라, 물리적으로 가능한 해가 놓이는 저차원 다양체(manifold)만을 파라미터화합니다. 이로 인해 격자 해상도를 낮추더라도 실제 물리적 동역학을 유지할 수 있음을 보입니다.

실험결과

본 논문에서는 데이터 기반 이산화가 실제 PDE 문제에서 기존 수치해석보다 얼마나 뛰어난지 보이기 위해 여러 대표적 비선형 PDE를 대상으로 실험을 수행했습니다. 그중 가장 중요한 것은 1차원 Burgers’ equation인데요, 이 방정식은 간단하지만 충격파(shock) 형성과 같은 복잡한 비선형 현상을 포함해 수치적 근사가 어렵다는 점에서 이상적인 테스트베드입니다.

burger’s equation 은 아래와 같이 쓰입니다.

burger’s equation 은 해상도를 많이 낮춘 경우에도 발산하지 않고 오차가 줄어들었으며 충격파의 위치화 형태를 안정적으로 적분했습니다. 신경망이 충격파와 같은 비선형적이고 예측하기 힘들보이는 비선형PDE에서도 그 구조를 잘 반영했기 때문입니다.

이 실험으로 추가적으로 학습 도메인보다 훨씬 큰 도메인에서도 잘 작동함을 증명했습니다. 논문을 읽으며 초반에 국소적 영역의 실제 데이터로만 학습시켰는데, 과연 모든 영역에서 잘 작동할까? 걱정했지만, trainig domain 보다 10배 더 큰 공간에서도 burger’s equation 을 풀어보았음에도 잘 작동하여 일반화 했음을 보여줍니다.

결론은 실험결과를 통해 데이터 기반 이산화가 전통적 수치해법보다 정교하고 쉬우며 안정적이라는 것을 보여줍니다.

향후 연구 방향 

연구에서는 두가지 챌린지가 남아있다고 합니다.

첫번째로, 속도입니다. FD 를 구현할 때 많은 convolution 연산을 사용합니다. 저자들은 이것보다 다른 머신러닝 접근법이 훨씬 더 빠를 수 있다고 생각하고 있고, pre-trained linear filter 가 수십배 이상의 성능 향상을 보인바가 있습니다.

두번째는 고차원 문제와 higher dimensional problem 입니다. 2,3차원에서는 dimension 이 제곱, 세제곱으로 커지니 연산 overhead 를 더욱 줄여 이득을 기대할 수 있습니다.

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을 사용하는 또 다른 중요한 이유입니다.