프롬프트 프리픽스 캐싱으로 LLM 서빙 비용과 처리량 다루기

캐시 적중 여부는 프롬프트 앞부분에서 갈린다

넷플릭스 GenRec이 vLLM의 프리픽스 캐싱으로 추천 추론을 처리하는 구성은, 프롬프트 구조가 곧 서빙 성능 변수임을 보여준다. 이전 요청의 KV 캐시를 다시 쓰면 공통 접두부를 재계산하지 않아도 되지만, 재사용은 접두부가 완전히 동일할 때만 가능하다.

따라서 시스템 지시, 도구 정의, 공통 예시, 정책 문구처럼 여러 요청이 공유하는 내용은 앞쪽에 고정해야 한다. 반대로 사용자 식별자, 이력, 후보 목록, 타임스탬프는 뒤로 보낸다. 요청 ID나 타임스탬프가 접두부에 들어가면 매 요청의 시작이 달라지고 캐시는 전혀 동작하지 않는다.

긴 공통 문서를 대상으로 질의하거나 다회차 대화를 처리할 때, 또는 추천처럼 시스템 지시가 긴 워크로드에서 이 배치 규칙의 영향이 특히 크다.

KV 캐시 재사용을 서빙 경로에 반영하는 방식

프롬프트를 고정 구간과 가변 구간으로 나누는 일은 템플릿 작성 규칙에 그치지 않는다. 라우팅, 배치, 캐시 관리, 성능 관측까지 이어지는 운영 구조가 필요하다.

고정 구간에 버전 문자열이 필요하다면 배포 단위에서만 바뀌게 둔다. 요청마다 달라지는 값이라면 더 이상 고정 접두부가 아니다. 요청별로 재사용한 토큰 수와 새로 계산한 토큰 수를 수집하고, 템플릿 버전별로 적중률을 나눠 보면 템플릿 변경이 미친 영향을 바로 확인할 수 있다. 적중률은 절감률을 가늠하는 대리 지표이기도 하다.

캐시 용량에는 한계가 있다. 축출된 접두부는 다음 요청에서 전량 다시 계산해야 한다. 용량과 적중률의 관계를 실측하고, 축출 정책이 최근 사용 기준일 경우 저빈도·고비용 프리픽스가 밀려나는지 살펴야 한다. 필요하다면 고정 접두부를 별도로 상주시키는 구성을 검토할 수 있다.

같은 접두부를 공유하는 요청은 함께 배치할수록 재사용 효과가 커진다. 라우팅 단계에서 접두부 기준 그룹화를 적용하고, 같은 프리픽스를 가진 요청을 동일 인스턴스로 보내면 인스턴스별 캐시 중복 구축을 줄일 수 있다. 인스턴스 간 캐시 공유가 가능한지도 확인 대상이다.

⤢✕

배치 확대와 응답성 사이의 운영 판단

배치 크기를 키우면 처리량은 오르지만 개별 요청의 지연은 늘어난다. 동일 접두부 요청을 한 배치로 묶을 수 있다는 장점도 있지만, 배치가 찰 때까지 기다리는 시간 때문에 지연 분포의 꼬리가 길어질 수 있다.

추천 랭킹처럼 지연 예산이 엄격한 온라인 경로와 사전 계산 성격의 오프라인 경로에는 같은 배치 정책을 적용하기 어렵다. 전자는 응답성과 지연 예산을, 후자는 GPU 활용률과 단위 비용을 더 우선할 수 있다. 워크로드 성격에 따라 균형점이 달라진다.

처리량만으로는 배치 확대로 인한 지연 악화를 놓치기 쉽다. 첫 토큰까지의 시간과 전체 응답 시간을 분리해 보고, 처리량과 함께 추적해야 한다. 프리픽스 캐싱은 주로 첫 토큰까지의 시간에 영향을 준다.

구분	프리픽스 캐싱 적용	미적용
접두부 연산	재사용	매번 재계산
처리량	개선	기준
첫 토큰 지연	단축	기준
메모리 사용	캐시 영역 필요	없음
프롬프트 구조 제약	있음	없음
운영 계측 항목	적중률 추가	기본

프리픽스 캐싱을 적용하면 공통 접두부가 긴 워크로드에서 재계산이 사라져 처리량과 첫 토큰 지연이 함께 개선되고 단가가 직접 내려간다. 일반적으로 적용 자체가 성능을 떨어뜨리지는 않는다. 반면 미적용 구성은 프롬프트 구조의 제약과 캐시 메모리, 추가 계측 항목이 없지만 같은 접두부를 요청 수만큼 반복 계산한다.

고정 구간을 전방에 두면 요청 간 접두부가 일치해 적중률을 높게 유지할 수 있고, 템플릿 변경 때만 적중률 변화가 발생해 관리가 예측 가능하다. 무순 배치는 작성 자유도가 있지만 가변값 하나가 앞에 들어오는 순간 이후 전 구간의 캐시가 무효화되어 적중률이 0에 가까워질 수 있다. 이 비대칭성 때문에 배치 규칙은 권고보다 강제 규칙과 자동 검사에 가깝게 다루는 편이 안전하다.

템플릿 변경을 배포 관리 대상으로 다루기

프롬프트 구조의 순서와 내용을 조직 표준으로 정하지 않으면 팀별 템플릿 차이로 인스턴스 캐시가 파편화된다. 고정 구간의 순서와 내용, 가변값의 후방 배치 규칙을 표준화하고 표준 위반을 자동 검출하는 린트를 파이프라인에 둘 수 있다.

요청 ID, 타임스탬프, 난수 값은 접두부에 넣지 않는다는 규칙도 명시해야 한다. 로깅용 식별자는 프롬프트가 아니라 요청 메타데이터로 전달한다.

워크로드별 적중률 목표를 정하고, 목표에 못 미치면 원인을 조사한다. 적중률과 단가의 관계를 실측하면 개선의 금전적 가치를 산정할 수 있다. 캐시 메모리를 늘릴지 결정할 때도 적중률 개선과 메모리 비용을 함께 비교해야 하며, 동시 요청 수와 프리픽스 종류 수를 고려해 인스턴스 수를 정해야 한다.

템플릿을 배포한 뒤에는 적중률 변화를 자동 비교한다. 문구 한 줄 추가만으로도 접두부가 달라질 수 있으므로, 회귀가 발생하면 배포를 자동 차단하는 게이트를 검토할 수 있다. 배치 크기와 캐시 용량 역시 트래픽 패턴 변화에 맞춰 재조정해야 한다. 초기 설정을 고정하면 시간이 지날수록 최적점에서 멀어진다.

공유 캐시가 만나는 격리 요구

접두부 인지 라우팅은 지역성을 이용해 자원을 배치하는 최적화다. 같은 접두부 요청을 같은 인스턴스로 보내 캐시 재사용을 높이고 중복 구축을 피한다. 캐시 용량, 인스턴스 수, 배치 크기는 서로 의존하는 용량 변수이므로 각각을 따로 최적화하기는 어렵다.

다중 테넌트 환경에서는 공유 캐시의 성능 이득과 격리 요건이 충돌할 수 있다. 프리픽스 공유가 정보 노출 경로가 될 가능성이 있으므로 공유 캐시 환경의 격리 요구를 별도로 검토하고, 프롬프트 구조 변경 권한과 승인 절차를 정할 필요가 있다.

프리픽스 캐시를 전제로 한 프롬프트 구조 규범이 서빙 프레임워크의 기본 권고로 문서화되고, 접두부 인지 라우팅은 LLM 게이트웨이의 표준 기능으로 편입되어 별도 구현 부담이 사라지는 방향이다. 캐시 적중률도 LLM 서비스 대시보드에서 상시 확인하는 운영 지표가 되고 있으며, 공유 캐시의 측면 채널 위험과 격리 옵션은 연구와 대응의 대상이 되고 있다.