대규모 언어모델 추론 최적화: KV 캐시·연속 배칭·추측 디코딩

1. 개요

정의: 대규모 언어모델(LLM) 추론 최적화란 학습이 끝난 모델로 요청을 처리할 때 품질과 안전성을 유지하면서 응답 지연시간, 처리량, 메모리 사용량 및 토큰당 비용을 개선하는 모델·런타임·시스템 설계 활동이다.

LLM 서비스의 추론은 입력 프롬프트를 한 번 처리하는 단계와, 그 결과를 바탕으로 다음 토큰을 반복 생성하는 단계로 구성된다. 사용자가 보는 것은 하나의 응답이지만 서버에서는 프롬프트 길이, 출력 길이, 동시 요청, 모델 크기가 서로 다른 작업이 계속 유입된다. 따라서 단순히 GPU를 추가하는 방식만으로는 자원 활용도와 응답 경험을 함께 최적화하기 어렵다.

특히 자기회귀 생성에서는 앞서 계산한 문맥을 반복 계산하지 않도록 Key·Value 상태를 보관하는 KV 캐시가 중요하다. 그러나 캐시가 커질수록 GPU 메모리를 점유하고, 긴 문맥과 많은 동시 사용자 사이에 메모리 압박을 만든다. 결국 캐시 효율, 요청 스케줄링, 병렬화와 품질 손실을 종합적으로 조정해야 한다.

추론 최적화의 목적함수는 처리량 하나로 축약할 수 없다. 대화형 시스템은 첫 토큰까지의 시간과 토큰 간 지연이 중요하고, 오프라인 요약 작업은 총 처리량과 비용이 중요하다. 응답 품질, 안정성, 공정성, 보안 요구도 서비스의 SLO와 함께 고려해야 한다.

실무에서는 모델 자체의 저정밀 양자화와 경량화, KV 캐시의 메모리 관리, 배칭과 스케줄링, 병렬 실행, 요청 라우팅을 하나의 서빙 아키텍처로 결합한다. 각 기법의 효과는 하드웨어, 모델 구조, 프롬프트 분포, 응답 길이 및 동시성에 따라 달라지므로 실제 부하를 모사하는 벤치마크가 필수다.

2. 추론 구조와 병목의 위치

가. 전체 요청 처리 구조

아래 구조에서 게이트웨이는 인증·할당량·정책을 확인한 뒤 요청을 적합한 모델 엔진으로 전달한다. 엔진은 큐의 요청을 스케줄링하고, 토큰 생성 결과를 스트리밍하거나 완료 응답으로 반환한다.

flowchart LR
  U[사용자 요청] --> G[API 게이트웨이]
  G --> P[정책·할당량·라우팅]
  P --> Q[요청 큐와 스케줄러]
  Q --> E[LLM 추론 엔진]
  E --> W[모델 가중치]
  E --> K[KV 캐시 풀]
  E --> R[스트리밍 응답]
  R --> G
  G --> U
  M[메트릭·로그·트레이스] -.관측.-> G
  M -.관측.-> Q
  M -.관측.-> E

게이트웨이는 모델 실행과 분리된 정책 경계다. 토큰 한도, 최대 문맥 길이, 테넌트별 우선순위, 개인정보 마스킹을 검증하고, 요청의 모델·지역·하드웨어 요건에 맞춰 엔진을 고른다. 추론 엔진 안에 이 책임을 모두 넣으면 서비스 정책 변경이 모델 런타임 배포와 결합될 수 있다.

스케줄러는 현재 GPU 메모리와 실행 중 요청의 진행 상태를 고려해 다음 작업을 결정한다. 정적 배칭은 일정 시간 요청을 모아 한꺼번에 실행하지만, 응답 길이가 제각각이면 짧은 요청이 긴 요청의 종료를 기다려야 할 수 있다. 연속 배칭은 토큰 생성 단계마다 완료 요청을 빼고 대기 요청을 넣어 배치를 다시 구성한다.

추론 엔진은 모델의 가중치뿐 아니라 임시 활성값, KV 캐시, 커널 실행 버퍼를 관리한다. 메모리 할당과 커널 스케줄링이 맞물리므로, 캐시를 지나치게 많이 확보하면 새 요청을 받지 못하고, 지나치게 적게 확보하면 처리량이 낮아질 수 있다.

나. 프리필과 디코드

sequenceDiagram
  participant C as 클라이언트
  participant S as 스케줄러
  participant M as 모델 엔진
  participant K as KV 캐시
  C->>S: 프롬프트 제출
  S->>M: 프리필 작업 할당
  M->>M: 입력 토큰의 어텐션 계산
  M->>K: 계층별 Key·Value 상태 저장
  M-->>C: 첫 토큰 스트리밍(TTFT)
  loop 출력 토큰 생성
    S->>M: 디코드 스텝 실행
    M->>K: 과거 Key·Value 읽기
    M->>M: 다음 토큰 계산
    M-->>C: 토큰 전달(ITL)
  end
  M->>K: 요청 캐시 회수 또는 보존 정책 적용

프리필(prefill)은 입력 프롬프트의 토큰을 병렬로 처리하고 각 계층의 KV 상태를 만든다. 긴 입력은 많은 연산량과 활성값 메모리를 요구하므로 GPU 연산 사용률이 높아질 수 있다. 다만 프롬프트가 길면 캐시가 커지고, 다른 사용자의 디코드 작업과 자원 경쟁을 일으킨다.

디코드(decode)는 이전에 생성한 토큰을 포함해 다음 토큰을 하나씩 계산하는 자기회귀 단계다. 매 단계에서 과거 문맥과의 어텐션을 수행하고 모델 가중치를 반복 이용하므로, 많은 경우 연산보다 메모리 대역폭이나 토큰별 순차 지연이 병목이 된다. 워크로드와 모델에 따라 병목은 달라지므로 실제 측정으로 확인해야 한다.

첫 토큰까지의 지연시간(TTFT)은 입력 대기와 프리필의 영향을 크게 받는다. 토큰 간 지연(ITL 또는 TPOT)은 디코드 속도와 스케줄링에 민감하다. 두 단계를 구분해서 계측해야 긴 프롬프트에 따른 TTFT 악화와 느린 토큰 생성에 따른 ITL 악화를 구별할 수 있다.

3. KV 캐시와 메모리 관리

가. 캐시의 원리와 규모

트랜스포머는 각 토큰에서 어텐션에 쓰이는 Key와 Value 표현을 만든다. 이전 토큰의 K·V를 재사용하면 새 토큰을 생성할 때 과거 토큰의 K·V 투영을 다시 계산하지 않아도 된다. 다만 과거 K·V를 읽고 새 Query와 어텐션을 계산하는 일은 계속 필요하므로 캐시가 모든 연산을 제거하는 것은 아니다.

전체 어텐션을 사용하는 모델에서 한 요청의 캐시 메모리는 대략 다음과 같이 추정할 수 있다.

KV 캐시 바이트 ≈ 2 × 계층 수(L) × KV 헤드 수(Hₖᵥ) × 헤드 차원(d) × 토큰 수(T) × 원소당 바이트(b) × 동시 요청 수(N)

앞의 2는 Key와 Value를 함께 저장하기 때문이다. 그룹 질의 어텐션(GQA)이나 다중 질의 어텐션(MQA)은 Query 헤드보다 KV 헤드 수가 적어 캐시를 줄일 수 있다. 반대로 긴 문맥, 높은 동시성, 높은 정밀도는 캐시 용량을 증가시킨다.

예를 들어 32개 계층, KV 헤드 8개, 헤드 차원 128, 문맥 8,192토큰, FP16(원소당 2바이트)인 가상 모델은 요청 하나에 약 1GiB의 캐시가 필요하다. 실제 값은 모델의 어텐션 구조, 윈도우, 캐시 정밀도 및 런타임 구현에 따라 달라지는 근사치다.

이 계산은 가중치 메모리와 별개다. 대형 모델은 가중치가 GPU 메모리 대부분을 차지할 수 있으며, 캐시와 활성값까지 합산했을 때 요청 동시성이 제한된다. 따라서 적재 가능한 모델 크기만으로 서빙 가능성을 판단해서는 안 된다.

나. 페이지 기반 캐시와 공유

연속 메모리에 요청별 캐시를 길이에 맞춰 할당하면 요청 길이가 제각각일 때 외부 단편화가 생기고, 최대 길이를 미리 잡으면 사용하지 않는 공간이 생긴다. 페이지 기반 방식은 캐시를 고정 크기 블록으로 나누고 요청이 토큰을 생성할 때 필요한 블록만 연결한다. 논리적 토큰 순서와 물리 메모리 블록을 매핑 테이블로 분리하는 것이 핵심이다.

PagedAttention 계열 접근은 이런 블록 단위 KV 메모리 배치와 연결된다. 블록 크기가 작으면 낭비 공간을 줄이기 쉽지만 블록 관리와 주소 변환 비용이 늘 수 있다. 블록 크기가 커지면 관리가 단순해질 수 있으나 마지막 부분의 내부 낭비와 세밀한 공유 기회가 달라진다.

공통 시스템 프롬프트나 반복되는 RAG 지시문이 있을 때, 공통 접두부(prefix)의 캐시 블록을 요청 간 공유하면 중복 프리필을 줄일 수 있다. 캐시 공유는 콘텐츠의 동일성뿐 아니라 테넌트·권한·모델 버전이 같은지를 확인하는 키 설계가 전제되어야 한다.

캐시 퇴거 정책은 GPU 메모리가 부족할 때 어떤 블록을 해제할지 결정한다. 최근 사용 시각(LRU), 우선순위, 재사용 가능성, 보존 시간 등을 기준으로 삼을 수 있다. 캐시 적중률을 높이려 특정 사용자의 데이터를 오래 보관하면 보안·삭제 정책과 충돌할 수 있어 운영 정책과 함께 정의해야 한다.

다. 압축·양자화·오프로드

KV 캐시 양자화는 캐시 표현의 비트 수를 낮춰 메모리 사용량을 줄이는 방법이다. FP8 등 저정밀 표현은 더 많은 토큰이나 요청을 수용하게 할 수 있지만, 양자화 스케일과 값의 범위에 따라 출력 품질 또는 안정성에 영향이 생길 수 있다. 따라서 모델 가중치 양자화와 캐시 양자화는 별도의 품질 검증 항목으로 다뤄야 한다.

오프로드는 덜 자주 쓰는 캐시 블록을 CPU 메모리나 다른 메모리 계층으로 이동시키는 방식이다. GPU 공간을 확보하는 대신 전송 지연, CPU 메모리 용량, PCIe 또는 네트워크 대역폭을 소비한다. 다시 쓸 캐시를 언제 GPU로 가져올지 예측하지 못하면 재계산보다 느려질 수 있다.

슬라이딩 윈도우 어텐션처럼 일부 계층만 제한된 문맥을 보는 모델은 캐시를 오래 유지할 필요가 없는 토큰을 더 일찍 회수할 수 있다. 그러나 하이브리드 어텐션이나 상태를 보존하는 구조에서는 계층별 캐시 수명과 풀 크기가 다를 수 있다. 모델별 레이아웃을 모르는 채 일률적으로 캐시를 축소하면 정확성과 실행 호환성이 깨질 수 있다.

4. 배칭과 스케줄링

가. 정적 배칭과 연속 배칭

정적 배칭은 요청을 고정된 묶음으로 실행한다. 같은 크기의 입력을 대량 처리하는 오프라인 작업에는 구현과 운영이 단순하지만, 요청마다 생성 길이가 다르면 배치의 완료 시점이 가장 긴 요청에 끌려간다. 빈 슬롯이 생겨도 배치가 종료될 때까지 새 요청을 넣지 못하는 비효율이 발생한다.

연속 배칭(continuous/in-flight batching)은 생성 스텝 경계에서 완료된 요청을 제거하고 대기 중인 요청을 추가한다. 요청별 진행 상태를 분리하므로 GPU의 유휴 시간을 줄일 수 있고, 요청이 계속 들어오는 서비스에서 처리량을 높일 수 있다. 하지만 스케줄러의 입장 제어와 공정성이 중요해지고, 요청의 긴 프리필이 디코드 요청을 지연시키지 않도록 해야 한다.

연속 배칭은 무조건 지연시간을 낮추는 기법이 아니다. 배치에 더 많은 요청을 넣으면 처리량은 높아질 수 있지만, 한 요청이 스텝을 배정받기까지 기다리는 시간이 길어질 수 있다. 따라서 평균 처리량만 보지 말고 TTFT·ITL의 p95/p99와 큐 대기시간을 함께 측정한다.

나. 청크 프리필과 스케줄링 정책

청크 프리필은 긴 프롬프트를 여러 토큰 청크로 나눠 프리필 작업을 점진적으로 수행한다. 디코드 요청과 프리필 요청을 교차 스케줄링할 수 있어, 하나의 긴 입력이 다른 사용자의 토큰 생성을 장시간 막는 현상을 줄일 수 있다. 대신 청크 전환과 스케줄링 제어가 추가되며 프리필 총 완료시간이 달라질 수 있다.

스케줄러는 토큰 예산, 캐시 블록 여유, 요청 우선순위, 기한, 예상 출력 길이를 고려할 수 있다. 처리량을 우선하는 정책은 짧은 요청을 빨리 처리할 수 있지만 긴 요청을 굶길 수 있다. 공정성 정책은 테넌트별 가중치나 최대 대기시간을 적용해 서비스 차별을 완화한다.

최대 배치 토큰과 최대 동시 시퀀스 수를 크게 설정하면 병렬성이 증가하지만 캐시와 활성 메모리를 빠르게 소진할 수 있다. 작은 요청을 무리하게 많이 admission하면 이후의 긴 프롬프트가 반복해서 거절될 수도 있다. 부하 제한은 오류 발생 후가 아니라 큐 지연과 메모리 여유에 근거해 선제적으로 수행한다.

5. 모델 실행 최적화 기법

가. 양자화와 커널 최적화

모델 가중치 양자화는 FP16·BF16보다 낮은 비트폭으로 가중치를 저장하고 연산해 메모리 용량과 대역폭 부담을 줄이는 방식이다. 4비트나 8비트가 모든 모델과 작업에서 같은 품질을 보장하는 것은 아니므로, 도메인별 평가셋으로 정확도·환각·안전성 변화를 검증해야 한다.

퓨즈드 커널과 어텐션 커널 최적화는 여러 연산을 합치고 중간 데이터의 메모리 왕복을 줄이는 방식이다. 커널의 효과는 GPU 아키텍처, 입력 길이, 배치 모양, 라이브러리 버전에 따라 달라진다. 서빙 엔진을 바꿀 때는 지원 연산, 디버깅 가능성, 운영 경험 및 공급자 종속성도 평가한다.

나. 병렬화와 모델 배치

데이터 병렬화는 모델 복제본을 여러 GPU에 배치해 서로 다른 요청을 처리하므로 처리량 확장에 유리하다. 다만 각 복제본에 모델 가중치가 다시 필요하므로 모델이 단일 GPU에 들어가지 않으면 적용이 어렵다. 복제본 수가 많아지면 GPU별 캐시 여유가 줄 수 있어, 긴 문맥 요청의 용량도 함께 확인해야 한다.

텐서 병렬화는 한 계층의 행렬 연산을 여러 GPU로 나누며 큰 모델을 적재할 수 있지만 GPU 간 통신이 늘어난다. GPU를 많이 연결하면 계산량은 나뉘어도 통신과 동기화가 지연을 늘릴 수 있다. 파이프라인 병렬화는 계층 그룹을 GPU별로 배치하지만 단계 간 버블과 요청 스케줄링을 고려해야 한다.

모델 병렬화 방법은 파라미터 수만이 아니라 목표 지연시간, 네트워크 토폴로지, 배치 크기, 모델 구조에 따라 선택한다. MoE 모델은 전문가 병렬화와 토큰 라우팅을 추가로 고려할 수 있다. 여러 전략을 혼합하는 경우 성능 최적화보다 장애 격리와 배포 복잡도가 커지지 않는지도 살핀다.

다. 추측 디코딩

추측 디코딩은 더 작은 초안 모델이나 보조 예측기가 다음 토큰 후보를 여러 개 제안하고, 큰 대상 모델이 후보를 한 번에 검증하는 방법이다. 후보가 승인되면 여러 토큰을 한 번의 검증 단계에서 확정할 수 있으므로 순차 디코드의 반복 횟수가 줄어들 수 있다.

대상 모델의 분포를 보존하도록 승인·수정하는 알고리즘을 적용할 수 있지만, 초안 모델이 잘 맞지 않으면 검증 과정이 추가 부담이 된다. 초안 생성 비용, 승인율, 배치 환경, 메모리 사용량을 측정해야 한다. 추측 디코딩이 모든 요청에서 동일한 가속을 제공한다고 가정해서는 안 된다.

6. 기법 간 비교와 선택

기법	주된 병목	기대 효과	비용·주의점
KV 캐시	과거 토큰의 반복 K·V 계산	디코드의 중복 계산 감소	캐시 메모리 증가
페이지 기반 캐시	단편화·고정 예약 낭비	블록 단위 동적 할당·공유	매핑·퇴거 관리 복잡성
연속 배칭	정적 배치의 빈 슬롯과 대기	GPU 활용률·처리량 개선	큐 공정성·꼬리 지연 관리
청크 프리필	긴 입력이 디코드를 점유	프리필·디코드 간 스케줄링	청크 전환 오버헤드
캐시 양자화	KV 메모리 용량	동시성·문맥 용량 확대	정밀도·품질 검증
추측 디코딩	토큰별 순차 생성 지연	승인된 복수 토큰의 빠른 확정	초안 모델 비용·승인율 의존
모델 양자화	가중치 메모리·대역폭	모델 적재·처리 효율 향상	작업별 품질 하락 가능성

위 표의 기법은 서로 대체재라기보다 다른 병목에 대응하는 보완재다. 예를 들어 연속 배칭은 실행 슬롯을 효율화하고 페이지 기반 캐시는 요청의 KV 메모리 배치를 개선하므로 함께 적용할 수 있다. 반면 최대 배치 크기를 먼저 올리면 캐시 부족이 심해져 효과가 반전될 수 있다.

기법 선택은 서비스 프로파일을 기준으로 단계적으로 한다. 짧은 프롬프트·짧은 응답은 작은 모델 또는 복제본 확장이 중요할 수 있고, 긴 문맥의 RAG 서비스는 캐시 메모리와 재사용 가능한 접두부가 핵심일 수 있다. 대화형 서비스는 TTFT와 ITL SLO를, 오프라인 추론은 시간당 처리 토큰과 토큰당 비용을 우선 기준으로 둘 수 있다.

7. 산업 적용 사례

가. 고객지원 대화형 서비스

고객지원 시스템은 공통 시스템 프롬프트와 정책 지침을 다수 요청에 반복 적용한다. 해당 접두부를 안전하게 재사용하면 중복 프리필을 줄일 수 있지만, 고객별 대화 이력은 다른 테넌트와 섞이지 않도록 캐시 키를 분리한다.

저녁 시간에 요청이 급증하면 연속 배칭과 큐 제한을 적용하고, 높은 우선순위의 상담 업무가 일반 질의에 밀리지 않게 가중치 기반 스케줄링을 둔다. 관측 지표는 p95 TTFT, p95 ITL, 응답 성공률, 큐 초과 요청률 및 GPU 메모리 여유를 포함한다.

나. 사내 RAG 지식검색

사내 지식검색은 질의마다 동일한 시스템 지침과 검색 결과 형식을 사용하고, 검색 문서 길이는 사용자의 질문에 따라 달라진다. 공통 프리픽스 캐시와 청크 프리필은 반복 계산과 긴 문맥의 자원 독점을 줄이는 데 도움을 줄 수 있다.

문서가 민감한 조직에서는 캐시 재사용을 조직·권한 단위로 제한하고, 퇴직자·권한 변경·문서 삭제 시 캐시 무효화도 고려한다. 캐시 적중률을 높이는 것보다 접근통제와 정보분리 요구를 우선하며, 프롬프트 및 결과 로그에는 최소 수집 원칙을 적용한다.

다. 코드 생성 보조 도구

코드 생성은 긴 파일 컨텍스트와 짧은 반복 완성 요청이 혼재한다. 짧은 제안은 첫 토큰과 토큰 간 지연에 민감하며, 긴 분석 요청은 프리필 비용과 캐시 용량이 더 중요하다. 요청 유형별 큐나 서로 다른 모델·엔진 풀을 두면 상충하는 SLO를 분리할 수 있다.

초안 모델을 활용한 추측 디코딩은 초안과 대상 모델 간 토큰 분포가 잘 맞는 코드 영역에서 시험할 수 있다. 적용 전에는 코드 정확성, 보안 취약 코드 발생, 승인율, 평균 지연 및 추론 비용을 기존 방식과 같은 입력 분포로 비교해야 한다.

8. 성능 측정과 운영 절차

성능 비교는 평균 한 건의 단일 요청이 아니라 동시 요청, 입력·출력 길이 분포, 도착률을 포함한 부하 시험으로 수행한다. 실제 로그를 그대로 재사용하기 어렵다면 개인정보를 제거한 대표 워크로드를 생성하고, 프롬프트 길이와 응답 길이의 분포를 유지한다.

핵심 지표에는 TTFT, ITL/TPOT, 요청별 총 지연, 입력·출력 토큰 처리량, 대기열 지연, 성공·타임아웃·거절률, GPU 사용률, 가중치와 KV 캐시 메모리가 포함된다. 사용량이 낮은 시간의 평균 처리량만 보면 급증 부하에서의 SLO 위반을 놓칠 수 있다.

비용 지표는 GPU 시간뿐 아니라 모델 크기, 유휴 복제본, CPU 오프로드, 네트워크 전송, 재시도 및 품질 저하로 인한 후처리 비용까지 고려한다. 토큰당 비용이 낮아져도 정확도나 안전성이 떨어져 사람의 재작업이 늘면 총소유비용은 오히려 증가할 수 있다.

운영 절차는 기준선 측정, 한 번에 하나의 최적화 적용, 품질 회귀시험, 부하 재현, 카나리 배포, SLO 비교, 점진 확대 순서로 설계한다. 런타임·커널·모델 토크나이저 버전은 함께 기록하고, 성능 향상이 특정 GPU나 입력 길이에만 국한되는지 확인한다.

9. 심화: 프리필·디코드 분리와 캐시 재사용

프리필과 디코드는 자원 특성이 다르므로, 대규모 시스템에서는 두 단계를 별도의 작업 풀이나 장비로 분리하는 아키텍처를 검토할 수 있다. 프리필 풀은 긴 입력을 빠르게 처리하고, 디코드 풀은 캐시를 보유한 채 토큰을 스트리밍하도록 각각 최적화한다.

단계 분리는 서로 다른 작업을 독립적으로 확장하게 하지만, KV 상태를 장비 간 전달해야 한다. 전송할 데이터가 크면 네트워크 대역폭과 복사 지연이 이점보다 커질 수 있고, 요청 라우팅과 장애 복구가 복잡해진다. 따라서 캐시 이동 시간, 프리필·디코드 대기시간, 네트워크 혼잡을 포함해 종단 간으로 비교한다.

반복 접두부 캐시와 외부 라우팅을 결합하면 캐시가 이미 존재하는 엔진으로 요청을 보낼 수 있다. 이는 전체 클러스터 처리량만이 아니라 캐시 친화성과 부하 균형을 함께 고려하는 문제다. 한 엔진에 접두부가 몰리는 경우 핫스폿이 생기므로 재사용 이득과 엔진별 큐 길이를 균형화해야 한다.

캐시 내용을 다른 요청이 재사용하는 경로는 보안 경계가 된다. 강한 해시 기반 캐시 키, 테넌트·사용자별 격리, 민감 프롬프트의 보존시간, 퇴거·삭제 증적을 설계하고, 캐시 측면 채널이나 프롬프트 추론 가능성도 위협 모델에 포함한다. 제품별 구현과 버전에 따라 실제 제공 기능은 달라질 수 있으므로 공식 문서와 배포 버전을 확인한다.

10. 고려사항 및 시사점

SLO에 맞는 목적함수 설정: 대화형 서비스는 처리량만 높이는 것이 아니라 TTFT·ITL 꼬리 지연, 오류율, 공정성을 함께 최적화해야 한다. 업무 중요도별로 허용 지연과 최대 큐 대기시간을 정의한다.
메모리 예산의 통합 관리: 모델 가중치, 활성값, KV 캐시, 런타임 버퍼를 한 GPU 메모리 예산으로 관리한다. 문맥 길이와 동시 요청을 함께 제한하고, 캐시 사용률과 OOM 발생 전의 안전 여유를 관측한다.
품질·안전 회귀 검증: 가중치나 KV 캐시의 저정밀화, 추측 디코딩을 도입할 때 대표 업무 평가와 안전성 테스트를 병행한다. 평균 점수뿐 아니라 특정 언어·고위험 업무·긴 문맥의 악화 여부를 확인한다.
테넌트 격리와 데이터 수명주기: 접두부·캐시 공유는 권한 경계와 데이터 보존정책에 맞춰 제한한다. 민감정보가 캐시에 남는 시간, 사용자 삭제 요청의 반영, 로그와 캐시의 차이를 문서화한다.
공정한 스케줄링과 부하 제어: 우선순위가 높은 요청의 지연을 보호하되 일반 요청의 기아를 막는 최대 대기시간, 가중치, 입장제어를 둔다. 부하가 한도를 넘으면 명확한 재시도 지침과 대체 응답을 제공한다.
종단 간 비용 최적화: 토큰당 GPU 비용만으로 개선을 판단하지 않는다. 품질, 재시도, 캐시 전송, 유휴 자원, 운영 복잡도를 포함한 단위 업무 비용을 비교한다.
벤더·런타임 변경관리: 런타임별 캐시 레이아웃과 스케줄링 기능, 양자화 형식은 버전별로 달라진다. 엔진 전환이나 GPU 세대 변경 전 표준 워크로드로 호환성·성능·복구 절차를 재검증한다.

정보관리기술사는 모델 선택과 GPU 규모산정에 머물지 않고, 서비스 SLO에서 역산한 요청 프로파일·캐시 예산·배치 정책·정보보호 통제를 하나의 용량 계획으로 연결해야 한다. 이러한 체계가 성능 수치의 단기 개선을 지속 가능한 서비스 품질과 비용 효율로 전환한다.

참고자료

NVIDIA TensorRT-LLM, KV Cache System: https://nvidia.github.io/TensorRT-LLM/features/kvcache.html
Hugging Face, Continuous batching from first principles: https://huggingface.co/blog/continuous_batching
Hugging Face Transformers, Cache strategies: https://huggingface.co/docs/transformers/main/kv_cache
vLLM Documentation, Paged Attention (문서에 원 논문 기반의 역사적 설명이며 현재 코드와 다를 수 있음을 명시): https://docs.vllm.ai/en/stable/design/paged_attention/

한 줄 요약: LLM 추론 최적화는 KV 캐시·배칭·모델 실행을 SLO, 품질, 보안 및 비용에 맞춰 함께 설계하고 실제 부하로 검증하는 일이다.