Quantization - 태그 - lee's bloghttps://ken-0913.github.io/myblog/tags/quantization/Quantization - 태그 - lee's blogHugo -- gohugo.ioko-krhyeonjae0913@gmail.com (ken-0913)hyeonjae0913@gmail.com (ken-0913)Fri, 28 Aug 2026 20:00:00 +0900LLM 스터디 5주차 - LLM 서빙 최적화 실전 — Qwen3-14B 벤치마크로 처리량 2.7배 끌어올리기https://ken-0913.github.io/myblog/posts/llm/llm-optimization-in-practice/Fri, 28 Aug 2026 20:00:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-optimization-in-practice/

Qwen3-14B vLLM 서빙 최적화 정리

  • 단일 GPU에서 Qwen3-14B를 vLLM으로 서빙할 때 처리량(throughput)과 지연시간(latency)을 체계적으로 측정하고 개선하는 7단계를 알아본다.

1단계 : GPU 하드웨어 점검

먼저 nvidia-smi로 사전 점검을 진행한다.

  • CUDA/드라이버 호환성
  • 성능 상태(P8=유휴, P0/P1=고성능)
  • 메모리 여유분(46GB 중 사용량)

사용률이 낮은데 부하가 걸려 있으면 배칭 문제를, 전력은 높은데 처리량이 낮으면 메모리 병목을 의심한다. 이 기준으로 이후 벤치마크 결과의 원인을 구분한다.


아래와 같이 플래그를 사용하여 관심있는 항목만 출력해본다.

bash 
root@da1d46d42395:/# nvidia-smi --query-gpu=name,compute_cap,memory.free,memory.used,memory.total --format=csv
name, compute_cap, memory.free [MiB], memory.used [MiB], memory.total [MiB]
NVIDIA A40, 8.6, 45489 MiB, 0 MiB, 46068 MiB

]]>LLM 스터디 3주차 - LLM 서빙 최적화 기법 — 배칭·어텐션·양자화·prefix 캐싱https://ken-0913.github.io/myblog/posts/llm/llm-essential-llm-optimization-techniques/Fri, 21 Aug 2026 21:00:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/llm/llm-essential-llm-optimization-techniques/

앞 글에서 병목이 어디에 있는지를 봤다. 이번에는  병목을 실제로 풀어보자. 

prefill은 프롬프트 토큰을 한꺼번에 처리해 연산 강도가 높다. (앞서 말했듯이 연산강도가 높다는 것은 같은 가중치를 한 번 읽고 그것으로 훨씬 많은 토큰을 처리한다)

문제는 decode다. 토큰 하나를 만들려고 수십억 개 파라미터를 전부 읽어야 하니 대역폭만 축내고 연산 유닛은 유휴상태이다. 

여기서 배칭이 들어간다. 요청 세 개를 묶으면 가중치는 여전히 한 번만 읽으면서 토큰은 세 개를 만든다. 연산 강도를 인위적으로 끌어올린다.

]]>