vLLM Prefix Caching과 Tensor Parallelism, 긴 프롬프트와 다중 GPU를 함께 조정하는 법

AI를 활용하여 생성한 이미지입니다.

vLLM 성능을 조정할 때 Prefix Caching과 Tensor Parallelism을 한 묶음의 “가속 옵션”으로 켜면 원인을 분리하기 어렵습니다. Prefix Caching은 반복되는 입력 앞부분의 prefill 계산을 재사용하는 기능이고, Tensor Parallelism은 모델 계산을 여러 GPU에 나누는 방식입니다. 하나는 입력 중복을, 다른 하나는 모델 배치와 GPU 통신을 다루므로 먼저 병목을 구분해야 합니다.

OpenAI API의 프롬프트 캐싱과 비용 관점은 기존 캐싱 글에서 다루는 주제에 가깝습니다. 여기서는 직접 vLLM 서버를 운영하며 긴 시스템 프롬프트, 긴 문서 질의, 다중 GPU를 함께 조정하는 기준을 설명합니다.

Prefix Caching이 재사용하는 범위

vLLM의 Automatic Prefix Caching(APC)은 이전 요청에서 계산한 공유 prefix의 KV 캐시 블록을 재사용하도록 설정하는 기능입니다. 공식 문서는 엔진 설정에서 enable_prefix_caching=True를 사용하도록 안내합니다.[1] 긴 시스템 지침, 고정 도구 스키마, 공통 문서 머리말이 매 요청에 반복될 때 검토할 가치가 있습니다.

문장이 비슷하다는 이유만으로 캐시가 적중하는 것은 아닙니다. 토큰화된 앞부분이 실제로 같아야 하므로 요청 ID, 현재 시각, 사용자 이름, 매번 바뀌는 검색 결과를 앞에 넣으면 공유 구간이 짧아집니다. 프롬프트를 아래처럼 고정 구간과 변동 구간으로 나누는 것이 출발점입니다.

[고정] 시스템 지침
[고정] 도구 스키마와 출력 형식
[고정] 버전이 고정된 문서 머리말
[변동] 사용자 질문
[변동] 검색 결과·대화 상태

APC를 켜기 전후에 비교할 값

짧은 프롬프트에서 차이가 작으면 APC가 고장 난 것이 아니라 재사용할 계산이 적은 것일 수 있습니다. 긴 prefix인데도 변화가 없다면 직렬화 결과, 공백과 구분자, 앞부분에 들어간 변동값부터 비교하세요. 캐시 적중률만 높고 전체 지연이 그대로라면 decode나 큐 대기가 병목일 수 있습니다.

Tensor Parallelism은 모델 배치 문제입니다

모델이 한 GPU의 메모리에 안정적으로 들어간다면 여러 장을 쓴다는 이유만으로 Tensor Parallelism을 켜지 않는 것이 먼저입니다. 장치 간 통신이 레이어 계산의 이득을 상쇄할 수 있으므로, 단일 GPU 기준선 없이 분산 결과만 보면 판단할 수 없습니다. vLLM 문서도 모델이 한 GPU에 들어갈 때는 분산 추론이 보통 필요하지 않다고 설명합니다.[2]

한 노드의 여러 GPU에 모델을 나눌 때 Tensor Parallelism을 사용하고, 한 노드에 모델이 들어가지 않을 때는 Tensor와 Pipeline Parallelism의 조합을 검토합니다.[2] 예를 들어 노드당 4개 GPU, 2개 노드라면 다음은 구성 형태를 보여 주는 예일 뿐 최적값을 보장하지 않습니다.

# 한 노드의 4개 GPU
vllm serve 모델경로 --tensor-parallel-size 4

# 2개 노드, 노드당 4개 GPU의 예
vllm serve 모델경로 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2

GPU 수보다 KV 캐시와 컨텍스트 상한을 먼저 보세요

가중치가 GPU에 올라갔다는 사실만으로 긴 요청을 많이 처리할 수 있는 것은 아닙니다. vLLM 로그의 GPU KV cache size와 최대 동시성 추정치는 요청 토큰 길이를 전제로 합니다.[2] max_model_len을 실제 업무보다 크게 잡으면 한 요청이 차지할 자원이 커지고, 짧은 질문을 처리하는 서비스의 동시성도 낮아질 수 있습니다.

평균 입력 길이만 보지 말고 상위 구간의 긴 요청을 별도로 확인하세요. 짧은 대화와 긴 문서 질의를 같은 큐에 섞으면 긴 요청이 다른 요청을 밀어낼 수 있습니다. 필요하다면 엔드포인트나 모델 인스턴스를 나누고, 나누기 어렵다면 긴 입력에 상한을 두거나 검색·요약 단계에서 문서를 줄입니다.

실험 순서를 고정하면 원인을 찾기 쉽습니다

1. 동일 모델과 요청 목록으로 APC를 끄고, 단일 GPU 또는 기존 분산 설정의 기준선을 기록합니다.
2. APC만 켜고 같은 순서로 반복 요청을 보내 prefill·첫 토큰·전체 지연을 비교합니다.
3. 같은 총 GPU 수에서 Tensor Parallel 크기만 바꾸고, 통신·KV 캐시·오류를 함께 기록합니다.
4. 긴 요청과 짧은 요청을 분리해 동시성 변화를 확인합니다.
5. 한 번에 옵션을 여러 개 바꾸지 말고, 설정·모델 버전·컨텍스트 상한을 실험표에 남깁니다.

APC가 prefill을 줄여도 decode가 병목이면 전체 응답 시간은 크게 변하지 않을 수 있습니다. Tensor Parallel 크기를 키워 모델 로딩은 해결했지만 토큰 생성이 느려질 수도 있습니다. 첫 토큰 지연, 생성 속도, 동시 처리량 중 어느 것을 우선하는지 먼저 정해야 합니다.

GPU 연결 방식과 다중 노드의 예외

같은 노드 안에서도 GPU 연결 방식에 따라 통신 비용이 다르고, 노드 사이를 네트워크로 연결하면 지연 조건이 추가됩니다. NVLink가 없는 환경에서는 일부 구성에서 Pipeline Parallelism이 더 나은 선택이 될 수 있다고 vLLM 문서가 설명하지만, 이는 모든 GPU·모델에 적용되는 수치가 아닙니다.[2] GPU 종류, 연결 방식, 노드 수, 요청 길이를 같이 기록하지 않은 토큰 속도 비교는 운영 판단으로 쓰기 어렵습니다.

다중 노드에서는 노드별 환경, 모델 파일, 통신 설정이 일치해야 합니다. 한 노드만 다른 컨텍스트 상한이나 라이브러리 버전을 사용하면 재현되지 않는 실패가 생길 수 있습니다. 모델이 단일 노드에 들어가는지부터 확인한 뒤, 정말 필요한 경우에만 노드 수를 늘리세요.

문제가 생겼을 때 되돌리는 순서

• 메모리 부족: 실제 요청 길이에 맞춰 max_model_len과 동시 요청 상한을 먼저 낮춥니다.
• APC 효과 없음: APC를 끄고 prefix의 토큰화 결과와 변동값을 비교합니다.
• 다중 GPU가 더 느림: 같은 모델을 단일 GPU 또는 더 작은 Tensor Parallel 크기로 실행해 통신 비용을 분리합니다.
• 긴 요청만 밀림: 긴 문서 전용 큐·상한·검색 전처리를 검토합니다.

운영 체크리스트

• 고정 prefix와 변동 구간이 요청 구성에서 분리돼 있나요?
• APC 전후 prefill·첫 토큰·전체 지연을 따로 기록했나요?
• 단일 GPU 기준선을 만든 뒤 분산 설정을 비교했나요?
• KV 캐시 크기와 긴 요청의 실제 토큰 길이를 함께 봤나요?
• Tensor·Pipeline Parallel 크기와 GPU 연결 방식을 기록했나요?
• 캐시 적중률이 아니라 사용자 목표 지표가 개선됐나요?

관련된 검색 파이프라인을 조정한다면 RAG 검색 튜닝 글도 함께 참고할 수 있습니다. 검색 결과를 prefix 앞쪽에 고정하는 방식은 재사용을 떨어뜨릴 수 있으므로, 문서 버전과 질의별 변동 영역을 분리해 읽어 보세요.

자주 묻는 질문

GPU가 많을수록 Tensor Parallelism이 항상 빠른가요?

아닙니다. 모델을 한 GPU에 올릴 수 있다면 통신이 추가될 수 있고, 다중 GPU라도 연결 방식과 요청 길이에 따라 결과가 달라집니다. 기준선과 같은 요청 목록으로 비교하세요.

APC 적중률이 높으면 전체 응답도 빨라지나요?

보장되지 않습니다. prefill이 줄어도 decode, 큐 대기, 네트워크가 병목일 수 있습니다. 첫 토큰과 전체 완료 시간을 나눠 보세요.

긴 prefix를 무조건 앞에 붙이면 좋은가요?

아닙니다. 오래된 문서와 불필요한 설명이 입력을 늘리면 품질·메모리·지연에 부담이 됩니다. 재사용 가치가 있는 고정 정보만 남기고 버전을 바꿀 때는 새 기준선을 만드세요.

Sources

1. [1] vLLM Docs: Automatic Prefix Caching
2. [2] vLLM Docs: Parallelism and Scaling