• 목록

LLM 응답이 느린 이유는 GPU 성능만의 문제가 아닙니다. 입력 프롬프트가 길거나 KV 캐시가 부족하고, CPU·네트워크·스토리지 설정이 맞지 않아도 지연시간이 커집니다. 같은 GPU를 사용하더라도 추론 엔진의 배칭 방식과 메모리 정책을 조정하면 처리량과 사용자 체감 속도를 개선할 수 있습니다. 이 글에서는 병목을 확인하는 순서와 서버에서 바로 점검할 설정을 정리합니다.

AI 생성 삽화 · LLM 추론 속도를 높이는 서버 설정 7가지의 내용을 설명하기 위한 이미지입니다.

핵심 정리
LLM 응답이 느린 이유는 GPU 성능만의 문제가 아닙니다.

1. 추론 지연시간을 만드는 핵심 병목

TTFT와 생성 속도를 분리해서 측정하기

LLM 지연시간은 보통 TTFT(Time to First Token)와 토큰 생성 속도로 나누어 봐야 합니다. TTFT는 요청 접수부터 첫 토큰이 나올 때까지의 시간이며, 프롬프트 처리와 대기열의 영향을 크게 받습니다. 이후 토큰이 생성되는 속도는 디코딩 단계의 성능과 관련이 깊습니다.

두 값을 하나의 평균 응답시간으로만 보면 원인을 놓치기 쉽습니다. 모니터링에서는 요청별 입력 토큰 수, 출력 토큰 수, 대기시간, 프리필 시간, 디코드 시간, GPU 메모리 사용량을 함께 기록하세요. p50뿐 아니라 p95와 p99 지연시간도 확인해야 순간적인 과부하를 파악할 수 있습니다.

긴 컨텍스트와 동시 요청 확인하기

긴 프롬프트는 GPU가 처리해야 할 연산량뿐 아니라 KV 캐시 사용량도 늘립니다. KV 캐시는 이전 토큰의 어텐션 관련 값을 저장해 다음 토큰 생성에 재사용하는 메모리 영역입니다. 동시 요청이 많거나 컨텍스트 길이가 길면 가용 캐시가 빠르게 줄어들고, 요청이 대기하거나 메모리 부족 오류가 발생할 수 있습니다.

먼저 실제 트래픽의 입력·출력 토큰 분포를 수집하세요. 최대 컨텍스트 길이를 필요 이상으로 높이지 말고, 시스템 프롬프트와 검색 결과가 중복되지 않는지 점검하는 편이 효과적입니다. 속도 개선 전에 요청 크기를 줄이는 작업이 가장 저렴한 최적화가 될 때도 많습니다.

---

2. GPU와 CPU 자원 배치 최적화

GPU 메모리와 전력 상태 점검하기

GPU 사용률이 낮다고 해서 항상 GPU가 남는 것은 아닙니다. 메모리 부족으로 배칭이 제한되거나 CPU에서 데이터를 기다리는 상황에서는 연산 사용률이 낮게 보일 수 있습니다. nvidia-smi 등으로 메모리 사용량, 온도, 전력 제한, 클럭 상태를 함께 확인하고, 컨테이너가 올바른 GPU를 인식하는지도 점검하세요.

모델 가중치와 KV 캐시가 GPU 메모리를 경쟁하지 않도록 여유 공간을 남겨야 합니다. 메모리 사용률을 무리하게 100%에 가깝게 설정하면 작은 요청 변화에도 오류가 날 수 있습니다. 여러 GPU를 쓴다면 텐서 병렬화가 통신 비용을 늘릴 수 있으므로, 모델 크기와 요청 패턴에 맞게 단일 GPU와 비교해야 합니다.

CPU 스레드와 NUMA 배치 조정하기

토크나이징, 요청 직렬화, 네트워크 처리, 샘플링은 CPU 자원을 사용합니다. GPU가 충분히 빠른데도 TTFT가 길다면 CPU 스레드 부족이나 프로세스 간 경쟁을 의심할 수 있습니다. 컨테이너의 CPU 제한을 확인하고, 추론 프로세스와 웹 프록시가 같은 코어를 과도하게 공유하지 않도록 배치하세요.

멀티소켓 서버에서는 NUMA 노드와 GPU의 물리적 연결 관계도 중요합니다. GPU와 가까운 CPU·메모리를 사용하도록 프로세스를 고정하면 PCIe와 메모리 접근 지연을 줄이는 데 도움이 됩니다. 다만 고정할 코어 수는 벤치마크로 결정해야 하며, 스레드를 많이 할당한다고 항상 빨라지지는 않습니다.

---

3. vLLM·SGLang 서버 설정

vLLM의 배칭과 메모리 설정

vLLM은 요청을 동적으로 묶는 연속 배칭과 PagedAttention을 활용해 여러 요청의 KV 캐시를 관리합니다. 실행 시 GPU 메모리 활용 비율, 최대 동시 시퀀스 수, 최대 배치 토큰 수, 최대 모델 길이를 트래픽에 맞춰 조정하는 것이 핵심입니다. 옵션 이름과 지원 범위는 버전에 따라 달라질 수 있으므로 설치한 버전의 공식 문서를 먼저 확인하세요.

배치 토큰 한도를 높이면 처리량이 좋아질 가능성이 있지만, 긴 요청이 짧은 요청을 지연시키거나 메모리 압박이 커질 수 있습니다. 대화형 서비스라면 낮은 TTFT를 우선하고, 오프라인 대량 생성이라면 처리량을 우선하는 식으로 목적을 나누세요. 설정을 바꿀 때는 동일한 프롬프트와 동시성으로 전후 결과를 비교해야 합니다.

SGLang의 라우팅과 프롬프트 재사용

SGLang은 구조화된 생성과 프롬프트 실행 흐름을 효율적으로 다루는 데 초점을 둔 추론 프레임워크입니다. 반복되는 시스템 프롬프트나 동일한 접두사가 많은 서비스에서는 RadixAttention 기반의 접두사 캐시 활용 여부가 성능에 영향을 줄 수 있습니다. 캐시가 자주 무효화되면 기대한 효과가 줄어드므로 요청 형식을 일정하게 유지하는 것이 좋습니다.

vLLM과 SGLang 중 무엇이 항상 빠르다고 단정하기보다 모델 아키텍처, 양자화 방식, 출력 형식, 동시성에 맞춰 측정해야 합니다. 동일한 GPU에서 워밍업 시간을 제외하고 TTFT, 초당 출력 토큰, 오류율, 메모리 사용량을 비교하세요. 라이브러리 버전과 CUDA·드라이버 조합도 함께 기록해야 재현 가능한 결과가 나옵니다.

---

4. KV 캐시·배칭·양자화 적용

KV 캐시를 아끼는 실무 설정

KV 캐시는 긴 대화를 빠르게 이어 가는 데 유용하지만, 동시 요청이 늘면 가장 먼저 메모리 병목을 일으킬 수 있습니다. 최대 컨텍스트 길이를 서비스 요구 수준으로 제한하고, 오래된 대화는 요약하거나 검색용 저장소로 옮기는 방식을 고려하세요. 프롬프트에 매번 동일한 문서를 통째로 넣기보다 필요한 부분만 검색해 전달하는 것도 효과적입니다.

접두사 캐시를 사용할 때는 캐시 적중률을 측정해야 합니다. 사용자별로 시스템 프롬프트의 위치나 형식이 지나치게 달라지면 재사용이 어렵습니다. 캐시가 메모리를 점유해 신규 요청의 배칭을 방해한다면 캐시 용량과 보존 정책을 낮추는 편이 전체 지연시간에 유리할 수 있습니다.

연속 배칭과 양자화의 균형

연속 배칭은 요청이 도착할 때마다 진행 중인 배치에 합류시키는 방식으로, GPU 유휴 시간을 줄이는 데 적합합니다. 그러나 동시성을 높이면 개별 요청의 지연시간이 늘 수 있으므로 대화형 API에는 요청 우선순위와 최대 대기시간이 필요합니다. 짧은 요청과 긴 요청을 무조건 같은 큐에 두지 않는 것도 방법입니다.

양자화는 가중치 또는 활성값의 정밀도를 낮춰 메모리 사용량과 메모리 대역폭 부담을 줄입니다. FP16·BF16, GPTQ, AWQ, FP8 등 지원 방식은 모델과 GPU에 따라 다르며 품질 손실도 달라질 수 있습니다. 적용 전 대표적인 한국어 질의와 구조화 출력으로 정확도를 검증하고, 단순히 모델 크기만 보고 선택하지 마세요.

---

5. 성능 측정과 비용 최적화

재현 가능한 부하 테스트 만들기

성능 비교에는 실제 서비스와 비슷한 입력 길이, 출력 제한, 동시성, 요청 간격이 필요합니다. 짧은 고정 프롬프트 하나로 측정한 결과는 긴 대화나 검색증강생성 환경을 대변하지 못합니다. 최소한 낮은 부하, 평상시 부하, 피크 부하를 나눠 테스트하고 p50·p95 TTFT와 출력 토큰 속도를 기록하세요.

워밍업 요청과 모델 로딩 시간은 운영 지표와 분리해 관리해야 합니다. 테스트 중에는 CPU 사용률, GPU 메모리, PCIe 전송, 네트워크 재전송, 큐 길이를 함께 수집하세요. 성능을 높였더라도 오류율이나 타임아웃이 증가했다면 성공적인 최적화가 아닙니다. 변경 사항은 한 번에 하나씩 적용해야 효과를 추적하기 쉽습니다.

비용 대비 처리량으로 서버 선택하기

GPU 한 대의 최대 속도보다 유효 처리량당 비용을 계산하는 것이 중요합니다. 시간당 인스턴스 비용을 성공한 요청 수나 생성 토큰 수로 나누고, 유휴 시간과 장애 재시작 비용도 고려하세요. 작은 모델에 큰 GPU를 붙이는 것보다 양자화한 모델을 여러 인스턴스로 분산하는 편이 유리할 수 있지만, 네트워크와 운영 복잡성이 증가합니다.

자동 확장을 적용할 때는 GPU 사용률 하나만 기준으로 삼지 마세요. 대기 중인 토큰 수, 큐 길이, p95 TTFT, 동시 요청 수를 함께 보는 방식이 적합합니다. 새 인스턴스의 모델 로딩 시간이 길다면 예열된 최소 인스턴스를 유지하고, 트래픽이 줄어드는 시간대에는 축소하는 정책을 검토할 수 있습니다.

---

6. 자주 묻는 질문 (FAQ)

Q1. GPU 사용률이 낮은데 LLM 응답이 느린 이유는 무엇인가요?

GPU가 계산을 끝내고 CPU의 토큰화나 네트워크 응답을 기다릴 수 있습니다. 또한 긴 큐, 작은 배치, KV 캐시 부족, GPU 메모리 압박으로 작업이 자주 중단되는 경우에도 사용률이 낮게 보입니다. TTFT와 디코드 시간을 나누고 CPU·GPU·큐 지표를 동시에 확인하세요.

Q2. vLLM과 SGLang 중 어떤 추론 서버를 선택해야 하나요?

모델과 트래픽에 따라 결과가 달라 한쪽을 일반적으로 추천하기는 어렵습니다. 사용하는 모델의 지원 여부, 접두사 캐시, 구조화 출력, 양자화 커널을 먼저 확인한 뒤 동일한 부하 테스트를 진행하세요. 속도뿐 아니라 오류율, 운영 편의성, 버전 호환성까지 함께 비교해야 합니다.

Q3. 양자화를 적용하면 답변 품질이 반드시 떨어지나요?

정밀도 감소 방식과 모델 특성, 작업 종류에 따라 품질 변화가 다릅니다. 간단한 질의에서는 차이가 작아도 수학 계산, 긴 문맥, 한국어 표현, JSON 형식 출력에서는 차이가 커질 수 있습니다. 운영 전 대표 평가 세트로 정확도와 형식 준수율을 확인하고 배포하세요.

Q4. 컨텍스트 길이를 최대로 설정하면 더 좋은 것 아닌가요?

최대 길이를 크게 잡으면 긴 입력을 수용할 수 있지만, KV 캐시 점유량과 메모리 부담이 증가합니다. 실제 사용량보다 과도하게 설정하면 동시 요청 수가 줄고 지연시간이 커질 수 있습니다. 서비스의 입력 분포를 측정한 뒤 필요한 범위에 여유를 더해 설정하는 편이 안전합니다.

---

7. 마무리

LLM 추론 속도를 높이는 서버 설정은 GPU 교체보다 측정과 조정의 순서가 중요합니다. 먼저 TTFT·생성 속도·큐 대기시간을 분리하고, GPU 메모리와 CPU·NUMA 배치를 점검하세요. 그다음 vLLM 또는 SGLang의 배칭, KV 캐시, 컨텍스트 길이, 양자화를 하나씩 바꾸며 비교해야 합니다. 마지막으로 실제 트래픽에 가까운 부하 테스트와 비용 계산을 진행하면, 같은 GPU로 더 빠르고 안정적인 서비스를 설계할 수 있습니다.

태그: #LLM최적화 #추론서버 #GPU서버 #vLLM #SGLang

---

참고 자료

• vLLM 최적화 공식 문서