제5부 추론 최적화와 서빙

5.7 TensorRT-LLM I — 아키텍처·KV 캐시

5.7.1 이 장에서 배우는 것 / 선수 지식

5.2~5.6에서 일반 TensorRT — ONNX 모델을 그 GPU에 특화된 엔진으로 컴파일하는 도구 — 를 익혔다. 그런데 LLM 추론은 일반 TRT 엔진 모델로 잘 안 풀린다. 자기회귀 디코딩(5.1.6)은 토큰을 하나씩 만들며 과거를 계속 재참조하고, 요청마다 시퀀스 길이가 가변이며, 요청들이 끝나는 시점이 제각각이다. 정적 입출력 형상을 가정한 일반 엔진으로는 이 동역학을 효율적으로 다룰 수 없다. 그래서 TensorRT-LLM(TRT-LLM) 이라는 LLM 특화 라이브러리가 따로 있다.

이 장은 제5부 LLM 묶음(5.7~5.10)의 출발점이다. TRT-LLM이 일반 TRT와 무엇이·왜 다른지, 그리고 LLM 추론 메모리·처리량의 핵심인 KV 캐시가 무엇이고 왜 존재하며 얼마나 큰지를 판다. 인플라이트 배칭·페이지드 KV의 원리는 여기서 세우고, 실전 운영은 5.8에서 깊게 간다.

배우는 것:

• 왜 TRT-LLM인가 — 일반 TRT가 LLM 추론에서 부딪히는 벽(자기회귀·가변 시퀀스·KV·인플라이트 배칭)과 TRT-LLM의 역할.
• KV 캐시의 원리 — 어텐션이 과거 토큰의 K·V를 왜 캐시하나, 캐시가 없으면 무슨 일이 나나(재계산 폭발), prefill이 채우고 decode가 읽는 구조.
• KV 캐시의 메모리 수식 — 레이어·헤드·시퀀스·배치·정밀도로 크기를 수계산하고, 그것이 동시 요청 수·처리량을 어떻게 정하는지(5.1.7 심화).
• GQA/MQA·KV 양자화가 KV를 줄이는 원리(3.7 연결).
• TRT-LLM의 아키텍처와 빌드 파이프라인 — 체크포인트 변환 → 엔진 빌드(trtllm-build) → 런타임의 흐름.

선수 지식: 5.1(prefill/decode·KV 캐시 도입·사면체), 3.6~3.7(어텐션·FlashAttention·GQA/MQA — KV의 출처), 5.2~5.3(TRT 빌드·동적 shape), 5.4~5.5(양자화 — KV·가중치), 1.9~1.10(HBM 대역폭·루프라인 — decode 메모리 바운드). 환경은 NGC TRT-LLM 컨테이너 권장.

정직: TRT-LLM은 이 책에서 가장 빠르게 변하는 소프트웨어 중 하나다. 체크포인트 변환 스크립트, trtllm-build 인자, 고수준 LLM API, 지원 모델·양자화·기능이 릴리스마다 바뀐다. 이 장은 개념과 흐름을 중심에 두고 명령은 한 시점의 형태를 예시한다 — 정확한 명령·인자·지원 범위는 당신 버전의 공식 문서로 확인("시점 의존, 확인 필요"). 모든 메모리·성능 수치는 환경 의존 개략값, 실측.

5.7.2 왜 일반 TRT로 부족한가 — LLM 추론의 동역학

일반 TRT 엔진은 "고정된 그래프에 (동적 shape 범위 안의) 입력을 넣어 출력을 받는" 모델이다. LLM 자기회귀 추론은 여기에 안 맞는 네 가지 동역학을 가진다(5.1.6 복습+심화):

이것을 일반 TRT로 흉내 내려면 매 토큰마다 엔진을 다시 부르고, KV를 직접 관리하고, 배치를 직접 재구성해야 한다 — 비효율적이고 깨지기 쉽다. TRT-LLM은 이 전부를 LLM에 맞춰 통합 제공한다:

한 줄 정의: TRT-LLM = "LLM을 그 GPU에 최적화된 추론 엔진으로 빌드하고, 자기회귀 디코딩·KV·배칭·병렬을 런타임으로 운용하는" 라이브러리. 일반 TRT 위에 LLM 특화 커널(어텐션·KV 관리 플러그인)과 런타임을 더한 것으로 봐도 좋다.

5.7.3 KV 캐시 — 왜 존재하나

LLM 디코더의 어텐션(3.6)은 매 위치에서 그 위치까지의 모든 토큰의 K(key)·V(value) 를 참조한다. 자기회귀 생성에서 토큰 t를 만들 때:

캐시가 없다면: 토큰 t+1을 만들 때 과거 모든 토큰의 K·V를 처음부터 다시 계산해야 한다. n개 토큰을 생성하면 누적 연산이 O(n²) — 길이가 길수록 폭발한다.

KV 캐시: 한 번 계산한 K·V를 HBM에 저장해 두고, 다음 스텝은 새 토큰 1개의 K·V만 계산해 캐시에 추가한 뒤, 캐시 전체를 읽어 어텐션한다.

→ 재계산 제거. 대신 '캐시를 읽는' 메모리 비용이 decode를 메모리 바운드로 만든다(5.1.6).

이것이 5.1.6의 "decode는 메모리 바운드"의 출처다: decode 스텝의 일은 가중치 + KV 캐시를 읽어 토큰 1개를 만드는 것 — 연산은 적고 읽을 바이트가 많다(1.10 루프라인). 그래서 KV 캐시가 클수록(긴 시퀀스·큰 배치) decode가 느리고, KV가 메모리를 차지해 동시 요청 수를 제한한다.

5.7.4 워크스루 (1) — KV 캐시 메모리 수식

KV 캐시 크기를 직접 계산해 본다(5.1.7.2 심화). 한 요청·시퀀스 길이 S의 KV 바이트:

KV_bytes(요청 1개) 는 다음 인자들의 곱이다:

예시(개략 가정): L=32, n_kv_heads×d_head = 4096, FP16(2B):

이것이 동시 요청 수의 상한을 정한다:

동시 요청 수 ≈ (가용 HBM − 가중치 W − 활성화 등) / KV_bytes(요청 1개). 예: 80GB GPU, 가중치 W≈30GB, 여유≈40GB:

핵심 함의(LLM 서빙 설계의 절반이 여기서 나온다):

• KV가 처리량·비용을 지배한다. 동시 처리 요청 수는 흔히 가중치가 아니라 KV가 정한다 → 토큰/초·$/토큰이 KV에 묶인다.
• 긴 문맥은 비용이 크다. KV는 S에 선형 → 8K·32K·128K 문맥은 동시성을 낮춰 요청당 비용을 높인다.
• KV를 줄이는 모든 기법이 곧 처리량·비용 개선이다 → GQA/MQA, KV 양자화, 페이지드 KV(단편화 제거).

5.7.5 KV를 줄이는 레버 — GQA/MQA·양자화·페이징

KV 수식의 각 항을 공략한다.

① n_kv_heads 줄이기 — GQA/MQA(3.7). 표준 MHA는 쿼리 헤드마다 K·V 헤드가 따로다. GQA(Grouped-Query) 는 여러 쿼리 헤드가 K·V 헤드를 공유하고, MQA(Multi-Query) 는 모든 쿼리가 K·V 헤드 1개를 공유한다.

→ KV_bytes가 n_kv_heads에 비례하므로 GQA(예 g=8)는 KV를 1/8로 줄인다.

이것이 최신 LLM이 GQA를 채택하는 이유 — 품질 손실을 최소화하며 KV·decode 메모리를 크게 줄인다. (모델 구조에 내장되어 있음, 추론이 바꾸는 것이 아님.)

② precision 줄이기 — KV 양자화. KV를 FP16 대신 FP8/INT8로 저장하면 바이트 절반 → 동시 요청 ~2×, decode 읽기 절반. 정밀도 영향은 보통 가중치 양자화보다 관대하지만 검증 필요(5.4~5.5 원리). TRT-LLM이 KV 양자화를 옵션으로 제공(버전 의존).

③ 단편화 제거 — 페이지드 KV. 요청마다 KV를 연속 큰 블록으로 미리 잡으면(최대 길이 기준) 실제로 짧은 요청이 공간을 낭비한다. 페이지드 KV(가상메모리식 페이지 단위 할당)는 KV를 작은 페이지로 분할해 필요할 때 할당 → 단편화 제거로 같은 HBM에 더 많은 요청. 원리는 여기, 운영은 5.8.

→ 같은 메모리로 동시 요청 수↑ = 실효 처리량↑ (인플라이트 배칭과 짝, 5.8).

5.7.6 TRT-LLM 아키텍처와 빌드 파이프라인

TRT-LLM은 모델 정의 → 엔진 빌드 → 런타임의 세 층이다(일반 TRT의 빌드/런타임에 LLM 특화가 더해진 형태).

세 층 요지:

• 모델 정의·변환: HuggingFace 등의 체크포인트를 TRT-LLM이 이해하는 형태로 변환하고, 필요하면 양자화(FP8·가중치 INT4 등)를 이 단계에서 적용. 모델 구조(어텐션 종류·GQA·RoPE 등)는 TRT-LLM의 모델 구현이 알고 있다.
• 엔진 빌드(trtllm-build): 변환된 체크포인트를 TRT 엔진으로 컴파일하되, KV 캐시·페이지드 어텐션·인플라이트 배칭·병렬을 위한 LLM 특화 커널/플러그인을 포함. 빌드 시 최대 배치·최대 입력 길이·최대 시퀀스 길이를 정한다(KV 메모리 예산과 직결).
• 런타임: C++ Executor가 요청을 받아 인플라이트 배칭 + 자기회귀 디코딩 + KV 관리를 수행한다. Python으로 호출하거나, Triton의 TRT-LLM 백엔드(5.11)로 서빙하는 것이 흔하다.

5.7.7 워크스루 (2) — LLM 엔진 빌드·실행 (흐름)

개략 흐름(명령·인자는 버전 의존, 당신 버전 문서·예제로 확인):

# 0) NGC TRT-LLM 컨테이너 안에서. 버전 확인.
python -c "import tensorrt_llm; print(tensorrt_llm.__version__)"   # 버전 의존

# 1) 체크포인트 변환(예: HF → TRT-LLM checkpoint). 모델별 변환 스크립트 제공.
#    (스크립트명·인자는 모델·버전마다 다름 — 공식 예제 디렉터리 참조)
python convert_checkpoint.py \
    --model_dir ./hf_model \
    --output_dir ./trtllm_ckpt \
    --dtype float16            # 또는 양자화 옵션(fp8 등, 버전 의존)

# 2) 엔진 빌드 — KV·배칭·길이 예산을 여기서 정함
trtllm-build \
    --checkpoint_dir ./trtllm_ckpt \
    --output_dir ./engine \
    --gemm_plugin auto \
    --max_batch_size 32 \
    --max_input_len 2048 \
    --max_seq_len 4096 \
    --paged_kv_cache enable
# max_batch_size=최대 동시요청(KV 예산) · max_input_len=프롬프트 상한 · max_seq_len=입력+출력(KV 시퀀스 상한) · paged_kv_cache=페이지드 KV(인자명 버전 확인)

# 3) 실행(예: 제공 러너 스크립트로 생성)
python run.py --engine_dir ./engine --max_output_len 256 \
              --input_text "Explain KV cache in one paragraph."

빌드 인자가 곧 KV 메모리 예산이다: max_batch_size × max_seq_len이 KV 캐시의 상한을 정하고(5.7.4 수식), 이를 GPU HBM이 감당해야 한다. 너무 크게 잡으면 OOM, 너무 작게 잡으면 동시성·길이가 제한된다 — 실제 부하 분포로 정한다(5.3의 프로파일 사고와 동형).

고수준 API: 최근 TRT-LLM은 변환·빌드·실행을 감싼 고수준 LLM 파이썬 API도 제공한다(몇 줄로 모델 로드·생성). 편하지만 세부 제어는 줄어든다 — 운영 튜닝은 빌드 인자·Executor 설정을 직접 만지는 것이 보통. API 표면은 버전 의존이니 그 버전 예제를 출발점으로.

5.7.8 중간 점검 (체크포인트)

• [ ] 일반 TRT가 LLM 추론에서 부딪히는 네 동역학(자기회귀·과거 재참조·가변 시퀀스·비동기 종료)을 대고, TRT-LLM이 각각을 어떻게 푸는지 말한다.
• [ ] KV 캐시가 왜 존재하나(재계산 폭발 방지)를 설명하고, prefill이 채우고 decode가 읽는 구조를 그린다.
• [ ] KV 메모리 수식(2·L·n_kv·d·S·precision)으로 요청당 KV와 동시 요청 수 상한을 수계산한다.
• [ ] GQA/MQA·KV 양자화·페이지드 KV가 KV의 어느 항을 줄여 처리량을 높이는지 설명한다.
• [ ] TRT-LLM의 변환→빌드(trtllm-build)→런타임 파이프라인과, 빌드 인자(max_batch·max_seq_len)가 KV 예산인 이유를 안다.

증상→의심: 동시 요청 수가 기대보다 적음 → KV 캐시가 메모리를 다 씀(긴 시퀀스·큰 max_seq_len) → GQA 모델·KV 양자화·페이지드 KV·max_seq_len 축소. 긴 프롬프트에서 TTFT 급증 → prefill 컴퓨트 폭증(시퀀스²) → 청크 prefill·길이 정책(5.8). decode가 느림 → KV·가중치 읽기 메모리 바운드(정상) → 양자화·배칭으로 완화. 빌드 OOM → max_batch×max_seq_len이 HBM 초과 → 예산 축소 또는 병렬(5.9). 버전 상향 뒤 변환/빌드 인자 에러 → 스크립트·인자 변경 → 그 버전 문서 확인.

5.7.9 트레이드오프·대안

LLM 추론 런타임 선택.

견해: 엔비디아 GPU에서 최대 성능·FP8·대규모 서빙이 목표면 TRT-LLM, 모델 지원 속도·이식성·간편함이 우선이면 vLLM/SGLang — 그리고 둘을 당신 모델·SLA로 실측 비교(5.15)하는 것이 정석이다. 빌드·버전 관리 부담이 큰 것은 사실이니, 모델이 자주 바뀌는 초기엔 vLLM로 빠르게 출시하고 안정화 후 TRT-LLM 전환을 저울질하는 패턴도 합리적이다.

비엔비디아 정직: KV 캐시·페이지드 어텐션·연속 배칭은 TRT-LLM만의 발명이 아니라 LLM 추론의 공통 기법이다(페이지드 어텐션은 vLLM이 대중화). TRT-LLM의 차별점은 엔비디아 커널·FP8/FP4·트랜스포머 엔진·NVLink 병렬·Triton과의 수직 통합이다. 우열은 모델·하드웨어·시점에 따라 달라지니 실측으로.

5.7.10 흔한 함정

• KV 메모리를 과소평가. 동시 요청 수는 가중치가 아니라 KV가 정할 때가 많다. max_batch×max_seq_len을 KV 수식으로 계산해 HBM에 맞춰라 — 안 그러면 OOM 또는 기대보다 적은 동시성.
• max_seq_len을 막연히 크게. 긴 시퀀스 상한은 KV 예산을 키워 동시성을 낮춘다. 실제 분포에 맞게(긴 문맥이 드물면 별도 운영점).
• GQA를 추론이 만든다고 오해. GQA/MQA는 모델 구조다 — 추론이 바꾸는 것이 아니라 그렇게 학습·설계된 모델을 쓰는 것. KV가 크면 GQA 모델 선택을 고려.
• KV 양자화를 검증 없이. KV FP8/INT8은 메모리를 줄이나 품질 영향 가능 — 태스크 지표로 검증(5.4~5.5).
• 일반 TRT로 LLM을 빌드하려 함. 정적 엔진으로 자기회귀·KV·배칭을 흉내 내면 비효율·취약. LLM은 TRT-LLM.
• 빌드 인자·스크립트를 버전 불문 복붙. 변환 스크립트·trtllm-build 인자·기능 플래그가 릴리스마다 변함 — 그 버전 예제 기준.
• prefill 비용 간과. 긴 프롬프트는 prefill(컴퓨트, 시퀀스에 따라 급증)이 TTFT를 지배 — 청크 prefill·길이 정책 필요(5.8).
• 엔진을 다른 GPU/병렬도에서 재사용. TRT-LLM 엔진도 GPU·TP/PP 구성·버전 종속 — 대상 구성에서 빌드(5.2·5.9).

5.7.11 연습문제

연습 1 (KV 존재 이유). KV 캐시가 없다고 가정하고, n개 토큰을 자기회귀로 생성할 때 어텐션 K·V 계산이 왜 O(n²)로 폭발하는지 설명하라. KV 캐시는 이를 어떻게 바꾸나(스텝당·총)?

연습 2 (KV 수식). L=40, n_kv_heads×d_head=5120, FP16. (a) 토큰당 KV 바이트? (b) S=4096 요청 1개의 KV? (c) 여유 HBM 48GB에서 동시 요청 수 상한(개략)? (d) KV를 FP8로 바꾸면 (c)는?

연습 3 (KV 레버). 어떤 서비스가 8K 문맥에서 동시성이 너무 낮아 비용이 높다. KV를 줄여 동시성을 높일 레버 셋과 각 대가를 설명하라.

연습 4 (빌드 예산). trtllm-build에서 max_batch_size=64, max_seq_len=8192로 빌드했더니 OOM이다. KV 수식으로 원인을 진단하고 세 가지 해결책을 제시하라.

연습 5 (런타임 선택). 팀이 오픈웨이트 LLM을 Hopper GPU에서 대규모·저비용으로 서빙하려 한다. TRT-LLM과 vLLM 사이 결정 과정을 설계하라(무엇을 측정·비교).

5.7.12 요약 · 다음 장

• TRT-LLM은 LLM 자기회귀 추론의 동역학(자기회귀·과거 재참조·가변 시퀀스·비동기 종료)을 위해 KV 캐시·융합 어텐션·인플라이트 배칭·병렬을 통합한 LLM 특화 라이브러리다. 일반 TRT로는 이 동역학을 효율적으로 못 다룬다.
• KV 캐시는 과거 토큰의 K·V를 저장해 재계산 폭발(O(n²))을 막는다. prefill이 채우고 decode가 읽으며, 이 "읽기"가 decode를 메모리 바운드로 만든다(5.1·1.10).
• KV 메모리 = 2·L·n_kv·d·S·precision — 시퀀스·배치에 선형으로 커져 동시 요청 수·처리량·비용을 지배한다. 긴 문맥은 비용이 크다.
• KV를 줄이는 레버: GQA/MQA(헤드 공유)·KV 양자화(precision)·페이지드 KV(단편화 제거). 모두 처리량·비용 개선으로 직결.
• 파이프라인: 체크포인트 변환 → trtllm-build(max_batch·max_seq_len=KV 예산) → 런타임(Executor/Triton). 빌드 인자가 곧 KV 메모리 예산.
• 정직: TRT-LLM은 변동이 큰 소프트웨어(명령·인자·지원 버전 의존), 모든 수치 실측, KV 양자화는 검증과 함께.

다음 장: 5.8 TensorRT-LLM II — 인플라이트 배칭·페이지드 KV. 이 장에서 원리만 본 인플라이트(연속) 배칭과 페이지드 KV를 운영 수준으로 판다 — 요청이 제각각 끝나는 batch를 어떻게 계속 채워 GPU를 유휴 상태로 두지 않는지, 페이지드 KV가 단편화를 어떻게 없애 처리량을 끌어올리는지, 그리고 prefill/decode 스케줄링을 실습으로 본다.