[LLM, Opensource Contribution ] SGlang VLM 모델 사용 중 오픈소스 기여하기

 

 

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

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

 

buf 로 이미지 구현한 데이터 입니다.

 

 

시작은 평범한 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자로 잘립니다.

Classify malformed-multimodal rejects as invalid_request by merrymercy · Pull Request #27451 · sgl-project/sglang

 

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

Guard image decode against oversized (decompression-bomb) images by hhhhhhhhhhhhhhhhho · Pull Request #28588 · sgl-project/sgl

 

[Bug] No pixel-count guard on image decode: oversized images cause ~1GB RSS + 100% CPU per request (pre-inference DoS risk) · I

 

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