TensorRT-LLM 1.3 RC: 레거시 TensorRT 백엔드 제거와 PyTorch·분리 서빙 전환의 운영 기준

왜 지금 봐야 하나

TensorRT-LLM v1.3.0rc21은 2026년 7월 15일에 공개됐다. 이번 릴리스의 핵심은 새 모델 몇 개를 더 얹은 것이 아니다. TensorRT-LLM이 앞으로 어떤 실행 경로를 중심으로 진화할지 방향을 분명히 한 릴리스라는 점이 더 중요하다.

이번 변화가 특히 중요한 이유는 세 가지다.

1. Python 패키지에서 레거시 TensorRT 실행 백엔드가 빠졌다. import tensorrt_llm과 PyTorch 백엔드 실행이 tensorrt Python 패키지 없이도 가능해졌다. 다만 이것이 "TensorRT가 완전히 사라졌다"는 뜻은 아니다. C++/packaging 레벨 정리는 후속 단계로 남아 있다.
2. trtllm-serve가 단순 데모 서버를 넘어 운영 표면을 넓혔다. OpenAI 호환 /v1/embeddings 엔드포인트, 서버 내부 동적 배칭, post-processing hook, CLI 인자 정리가 한 묶음으로 들어왔다.
3. 분리 서빙(disaggregated serving)은 더 전면으로 올라왔지만, 동시에 어디까지가 아직 위험한지도 더 선명해졌다. AutoDeploy 백엔드는 deprecated가 되었고, 특정 모델·GPU·분리 서빙 조합은 여전히 known issue로 남아 있다.

즉, 1.3 RC는 “더 빠른가?”를 묻기보다 TensorRT-LLM을 앞으로 어떤 런타임, 어떤 서버 표면, 어떤 배포 토폴로지로 운영해야 하는가를 다시 묻게 만드는 릴리스다.

핵심 변화 한눈에 보기

TensorRT 백엔드 제거는 무엇을 뜻하고, 무엇을 뜻하지 않는가

가장 먼저 잡아야 할 포인트는 이것이다. 이번 릴리스는 TensorRT-LLM 전체에서 TensorRT를 지운 것이 아니다. PR #15918이 실제로 한 일은 Python 패키지 내부에 남아 있던 레거시 TensorRT 실행 백엔드 코드를 걷어내고, PyTorch 백엔드가 필요한 심볼만 남긴 것이다.

이 구분이 중요한 이유는 현장에서 오해가 쉽게 생기기 때문이다.

• 맞는 해석: Python 레벨의 실행 경로와 import graph가 PyTorch 백엔드를 중심으로 정리됐다.
• 틀린 해석: 이제 TensorRT라는 이름은 완전히 없어졌고, 빌드/패키징/저수준 커널에서도 다 사라졌다.

PR 설명은 이를 아주 명시적으로 적어 둔다. import tensorrt_llm과 PyTorch 백엔드 실행은 tensorrt Python 패키지 없이 돌아가도록 만들었지만, requirements.txt 수준에서 pip dependency를 아예 드롭하는 작업은 후속 C++/packaging 단계로 미뤘다.

즉, 운영자가 지금 해야 할 일은 “TensorRT 전체가 없어졌나?”를 묻는 것이 아니라 다음 두 가지를 나눠 보는 것이다.

1. 우리 서비스 코드가 레거시 Python TensorRT 모듈 경로를 직접 import하고 있지 않은가?
2. 우리 배포 이미지가 여전히 tensorrt Python 패키지를 런타임 필수처럼 들고 다니고 있지 않은가?

이 릴리스의 의도는 분명하다. 앞으로 새 기능과 새 모델 지원 속도는 PyTorch backend + trtllm-serve 경로에 먼저 실릴 가능성이 높다. Release note에서 AutoDeploy backend deprecation을 함께 선언한 것도 같은 맥락이다.

왜 PyTorch 백엔드가 중심이 되었나

TensorRT-LLM의 PyTorch 아키텍처 문서는 상위 API를 tensorrt_llm.LLM으로 두고, 그 아래에 PyExecutor가 모델 추론을 조율한다고 설명한다. 여기서 중요한 구성요소는 네 가지다.

• Model Engine: GPU에서 단일 step forward를 효율적으로 실행한다.
• Decoder: 모델 출력을 바탕으로 다음 토큰을 생성한다.
• Scheduler: 현재 step에서 어떤 요청에 자원을 할당하고 forward를 실행할지 결정한다.
• ResourceManager / KVCacheManager: KV cache 같은 자원을 step 전후와 요청 종료 시점에 맞춰 관리한다.

이 구조가 주는 실무적 의미는 꽤 크다.

1) 실행 경로가 더 노출되고, 더 조정 가능해진다

PyTorch backend는 단일 블랙박스 엔진이라기보다 스케줄러·모델 엔진·디코더·자원 관리자가 분리된 실행기다. 스케줄러와 KV cache manager 인터페이스가 Python 쪽에서도 커스터마이즈 가능한 형태로 설명되어 있는 이유도 여기에 있다.

이는 곧, 모델 지원이나 배포 토폴로지 변화가 생겼을 때 전체를 새 엔진으로 갈아끼우는 대신 특정 레이어를 바꾸거나 우회하면서 따라갈 수 있는 여지가 있다는 뜻이다.

2) 새 기능이 들어오는 위치가 명확해진다

1.3 RC에서 눈에 띄는 변화들은 거의 모두 이 경로에 붙는다.

• DSv4 sparse MLA attention backend
• dynamic speculation 확장
• encoder-only /v1/embeddings 배칭 경로
• 분리 서빙에서의 KV cache 교환 구조
• prefix-aware scheduling 제어

이것은 단지 릴리스 노트의 feature 수가 많다는 얘기가 아니다. 새 모델·새 배포 형태·새 API 표면을 수용하는 실제 중심축이 PyTorch backend로 굳어지고 있다는 뜻이다.

3) AutoDeploy deprecation이 전략 변경을 드러낸다

release note는 AutoDeploy backend가 deprecated라고 바로 못 박는다. 더 중요한 문장은 뒤에 있다. NVIDIA는 “earlier model support is a critical priority”라고 적고, 그 속도를 PyTorch backend의 agentic approach로 개선하고 있다고 설명한다.

이 말은 번역하면 단순하다.

• 예전: 모델 지원 속도를 높이는 실험적 경로 중 하나가 AutoDeploy였다.
• 지금: 새 모델을 빨리 기능 수준에서라도 붙이는 중심 경로를 PyTorch backend 쪽으로 돌리겠다는 선언에 가깝다.

그래서 1.3 RC는 기능 추가 릴리스이면서도, 동시에 제품 전략 재배치 문서이기도 하다.

trtllm-serve는 이제 추론 서버라기보다 운영 표면이 된다

trtllm-serve 문서를 보면 OpenAI 호환 서버로서 /v1/models, /v1/completions, /v1/chat/completions를 지원하고, 여기에 /health, /metrics, /version 같은 운영 엔드포인트가 붙는다. 1.3 RC에서 중요한 것은 여기에 임베딩 전용 서브커맨드와 후처리 훅, CLI 정리가 함께 들어왔다는 점이다.

/v1/embeddings가 의미하는 변화

PR #15424는 trtllm-serve embeddings <model> 서브커맨드로 OpenAI 호환 /v1/embeddings 엔드포인트를 추가했다. 이 경로의 설계 포인트는 명확하다.

• 별도 Triton Inference Server dynamic batcher를 앞에 두지 않는다.
• 서버 내부의 lightweight async batcher가 동시 요청을 모은다.
• 배치는 세 조건 중 하나가 성립하면 즉시 flush 된다.

- max_batch_size 도달 - 다음 요청을 더하면 max_num_tokens 초과 - max_queue_delay 만료

• queue가 꽉 차면 429, oversized input은 400으로 돌려준다.

이 설계는 “encoder 모델도 기존 LLM IFB loop에 그냥 태우자”가 아니라, 인코더 모델은 짧은 단일 forward가 핵심이므로 그 위에 별도 경량 배처를 두는 편이 낫다는 판단을 반영한다.

이 변화가 실무에서 중요한 이유는 두 가지다.

1. 임베딩 서비스만 따로 Triton 앞단에 두던 구성을 단순화할 수 있다.
2. 운영자가 throughput/latency/backpressure를 LLM 서버 맥락 안에서 같이 튜닝할 수 있다.

다만 이것을 “모든 임베딩 워크로드가 즉시 대체 가능”으로 읽으면 안 된다. 문서도 범위를 분명히 한다. 이 경로는 encoder-only 모델을 위한 것이고, dimensions는 Matryoshka-trained 모델이 아니면 거절된다. 즉, 기존 클라이언트 호환성은 좋아졌지만 모델 출력 의미와 지원 범위는 여전히 모델별로 확인해야 한다.

post-processing hook은 정책 삽입 지점이 생겼다는 뜻이다

PR #15631은 trtllm-serve에 native post-processing hook을 추가했다. 이 기능을 너무 작게 보면 안 된다. 단순 문자열 후처리 기능이 아니라, 서버가 모델 출력 뒤에 정책을 삽입할 공식 지점이 생겼다는 의미다.

예를 들어 이런 작업을 더 깔끔하게 넣을 수 있다.

• 금칙어/포맷 정책 검사
• 모델 출력 교정 또는 suppression
• 특정 조건에서 즉시 종료(verdict-driven termination)
• 클라이언트별 응답 표면 차등 처리

지금까지는 이런 작업을 프록시나 애플리케이션 코드에서 우회적으로 넣는 경우가 많았다. hook이 서버 표면으로 올라오면, 추론 서버가 단지 토큰 생성기가 아니라 정책 엔진이 끼어드는 운영 경계가 된다.

서버 인자 rename은 사소한 정리가 아니다

PR #16091은 서버 인자를 더 명확한 이름으로 바꾸었다. 멀티모달 입력 처리 워커 수와 미디어 로드 워커 수처럼, 실행 비용과 스타트업 특성에 직접 영향을 주는 설정이 더 설명적인 이름으로 정리됐다.

또 PR #15640은 멀티모달 관련 인자와 환경 변수를 새 구성 표면으로 옮겼다. 이런 변경은 릴리스 노트에서 보면 사소한 chore처럼 보이지만, 운영 환경에서는 다음 문제로 바로 이어진다.

• Helm chart나 entrypoint script가 예전 인자 이름을 계속 사용함
• YAML 값은 바뀌었는데 env var가 예전 경로를 계속 덮어씀
• 멀티모달 모델만 특정 환경에서 성능/안정성이 다르게 나옴

즉, 이번 릴리스는 성능 숫자보다 먼저 배포 스크립트와 런타임 설정 표면을 다시 읽게 만든다.

분리 서빙은 더 좋아졌지만, 바로 기본값으로 두기는 이르다

TensorRT-LLM의 disaggregated serving 문서는 prefill과 decode를 서로 다른 GPU 풀로 분리하는 이유를 꽤 직설적으로 설명한다.

• prefill: 프롬프트 전체를 처리하며 compute 집약적이다.
• decode: 토큰을 하나씩 생성하며 memory bandwidth 집약적이다.

같은 GPU에서 둘을 섞으면 긴 prefill이 decode 배치를 밀어내서 TPOT가 흔들린다. 반대로 분리하면 TTFT와 TPOT을 별도로 최적화할 수 있다. 대신 KV cache block을 GPU 풀 사이로 옮기는 비용이 생긴다.

TensorRT-LLM 문서가 이 구조를 점점 전면에 두는 이유는 분명하다. 긴 입력과 중간 길이 출력이 많은 현대 LLM 워크로드에서 aggregated serving 하나로는 응답성과 처리량을 동시에 맞추기 어렵기 때문이다.

1.3 RC가 여기에 추가한 것들

release note 기준으로 1.3 RC는 분리 서빙 경계에서 다음 변화를 올렸다.

• DeepSeek V4 sparse MLA attention backend
• DSv4 follow-up 최적화와 disagg routing
• dynamic speculation을 모든 spec decode 알고리즘으로 확장
• prefix-aware scheduling opt-out flag 추가
• guided decoding을 위한 low-latency host task dispatch

이 중 운영자가 특히 주의해서 볼 것은 기능 추가보다 known issue 목록이다. release note는 다음과 같은 경고를 직접 적고 있다.

• DeepSeek V3.2에서 host KV cache offload가 multi-GPU에서 실패하거나 MTP와 함께 hang 가능
• disaggregated generation에서 DeepSeek V3 Lite + Helix 조합이 기대 문자열과 다른 출력을 낼 수 있음
• auto-dtype 경로가 disaggregated mode에서 실패하는 조합 존재
• 일부 multi-GPU parallelism 조합과 NVFP4, FlashInfer, CUDA graph 조합이 accuracy validation을 통과하지 못함

즉, TensorRT-LLM 1.3 RC는 분리 서빙을 더 강하게 밀고 있지만, “지원된다”와 “우리 모델·우리 GPU·우리 병렬화 조합에서 생산에 바로 올릴 수 있다”는 전혀 다른 문제라고 말하고 있다.

여기서 AutoDeploy deprecation이 다시 중요해진다

분리 서빙은 배포 토폴로지가 복잡해질수록 제어면이 중요해진다. 그런데 հենց release note는 AutoDeploy backend를 deprecated로 두고 있다. 이 조합은 결국 다음 메시지로 읽힌다.

• 제품이 가려는 방향: PyTorch backend + trtllm-serve + explicit disagg configuration
• 줄이려는 방향: 자동 추상화에 많이 기대는 경로

운영자 입장에서는 편의성이 줄어든 것이 아니라, 숨겨진 자동화보다 노출된 제어면을 더 신뢰하라는 요구에 가깝다.

이 릴리스를 어떻게 도입해야 하나

이번 릴리스는 RC이기 때문에 “좋아 보이는 기능을 다 켠다”보다 변경된 경계부터 검증한다는 접근이 맞다.

1) 먼저 import와 의존성 경계를 확인한다

레거시 TensorRT backend 제거의 첫 번째 효과는 Python import graph 정리다. 가장 먼저 할 일은 서비스 이미지와 CI에서 아래를 분리 확인하는 것이다.

python - <<'PY'
import tensorrt_llm
from tensorrt_llm import LLM
print('import-ok', tensorrt_llm.__version__)
PY

• tensorrt Python 패키지가 없어도 import가 되는가?
• 우리 코드가 삭제된 legacy 모듈 경로를 import하지 않는가?
• 테스트 중 examples/나 오래된 helper path를 하드코딩하지 않는가?

2) 임베딩 워크로드는 Triton 앞단 제거 전후를 따로 잰다

현재 임베딩 서빙에 Triton dynamic batcher를 앞에 둔 구성이 있다면, trtllm-serve embeddings로 바꾼 뒤 다음을 실측해야 한다.

• 평균 latency와 p95/p99
• queue full 시 429 비율
• max_batch_size, max_queue_delay, max_queue_size별 throughput 차이
• 입력 길이 분포가 긴 경우 max_num_tokens 제약으로 batch가 얼마나 자주 잘리는지

시작점 예시는 공식 문서가 제시한 아래 수준이면 충분하다.

trtllm-serve embeddings <hf_model_or_path> \
  --max_batch_size 32 \
  --max_queue_delay 0.005 \
  --max_queue_size 2048 \
  --host 0.0.0.0 --port 8000

3) 분리 서빙은 TTFT/TPOT을 분리해서 본다

disagg 도입 검증은 평균 처리량 하나로 끝내면 안 된다. 적어도 아래를 나눠 측정해야 한다.

• 짧은 입력 / 짧은 출력
• 긴 입력 / 짧은 출력
• 긴 입력 / 긴 출력
• KV cache exchange backend별 차이(UCX, NIXL)
• prefll/decode GPU를 다른 SKU로 둘 때의 안정성

특히 release note에 이름이 등장한 모델 계열(DeepSeek V3/V4, Qwen 3.5/3.6, GPT-OSS, Gemma 4, MiniMax M3)은 모델 조합별 known issue를 먼저 읽고 카나리 범위를 좁혀야 한다.

4) 설정 마이그레이션은 grep부터 한다

인자 rename과 multimodal env 이동은 코드보다 스크립트에서 많이 터진다. Helm values, startup script, env template, runbook에서 아래를 먼저 grep하는 편이 빠르다.

• 예전 서버 worker 인자 이름
• 예전 multimodal env var
• AutoDeploy backend 관련 토글
• prefix-aware scheduling을 암묵적으로 기대하던 설정

5) AutoDeploy 사용자라면 “버티기”가 아니라 “탈출 경로”를 만든다

deprecated는 오늘 바로 죽는다는 뜻은 아니지만, 새 모델 지원 속도와 운영 주력 경로가 다른 곳으로 이동했다는 뜻이다. AutoDeploy를 계속 쓰는 팀이라면 최소한 다음 둘 중 하나는 해야 한다.

• 특정 모델/버전에서만 고정 사용하고 업그레이드 창을 좁힌다.
• PyTorch backend + trtllm-serve 경로로 옮기는 마이그레이션 계획을 별도로 세운다.

내 판단: 1.3 RC는 기능 릴리스가 아니라 중심축 이동이다

TensorRT-LLM 1.3 RC를 한 줄로 요약하면 이렇다.

TensorRT-LLM은 이제 “TensorRT 엔진을 감춘 Python 패키지”보다 “PyTorch backend를 중심으로 모델 지원과 서버 표면을 빠르게 확장하는 추론 런타임”에 더 가깝다.

이 판단의 근거는 기능 숫자가 아니라 방향성의 일관성이다.

• 레거시 TensorRT backend는 Python 패키지에서 걷어냈다.
• 임베딩, 후처리 훅, 설정 표면 정리는 trtllm-serve에 몰린다.
• 분리 서빙은 문서와 기능이 성숙해지지만, known issue로 인해 더 정교한 운영 판단이 필요하다.
• AutoDeploy는 deprecated다.

그래서 1.3 RC를 평가할 때는 벤치마크 그래프 한 장보다 다음 질문이 더 중요하다.

• 우리 팀은 새 모델 지원 속도가 더 중요한가?
• 아니면 검증된 좁은 경로의 안정성이 더 중요한가?
• 우리가 원하는 것은 단일 GPU 최대 처리량인가, 아니면 Prefill/Decode를 분리한 클러스터 수준 제어인가?

이 질문에 "새 모델 대응 속도"와 "서빙 토폴로지 유연성" 쪽으로 답이 기운다면, TensorRT-LLM 1.3 RC는 지금 바로 카나리로 확인할 가치가 있다. 반대로 모델·GPU 조합이 이미 민감하고, known issue 목록에 가까운 워크로드를 운영 중이라면 GA 또는 후속 RC를 기다리면서 실험 범위를 좁게 유지하는 쪽이 더 안전하다.

운영 체크리스트

• [ ] 서비스 코드와 테스트 코드에서 삭제된 legacy TensorRT Python 모듈 import가 없는지 확인한다.
• [ ] tensorrt Python 패키지 없이도 import tensorrt_llm과 기본 PyTorch backend smoke test가 통과하는지 확인한다.
• [ ] trtllm-serve embeddings 도입 시 기존 Triton dynamic batcher 설정을 --max_batch_size, --max_queue_delay, --max_queue_size로 매핑해 실측한다.
• [ ] 임베딩 엔드포인트의 429/400 동작을 클라이언트 재시도 정책과 함께 검증한다.
• [ ] post-processing hook이 rewrite / suppress / terminate 중 어떤 정책을 적용하는지 문서화한다.
• [ ] 서버 인자 rename과 multimodal env 변경이 Helm chart, systemd unit, Kubernetes manifest에 반영됐는지 grep으로 확인한다.
• [ ] 분리 서빙은 TTFT와 TPOT을 분리 측정하고, UCX/NIXL backend 선택과 long-prompt 시나리오를 따로 검증한다.
• [ ] DeepSeek·Qwen·Gemma·GPT-OSS 등 실제 운영 모델이 release note known issue 목록에 걸리지 않는지 확인한다.
• [ ] AutoDeploy backend를 쓰고 있다면 deprecated 이후 유지 전략 또는 PyTorch backend 마이그레이션 계획을 세운다.

References

• NVIDIA TensorRT-LLM Release v1.3.0rc21, GitHub Releases, published 2026-07-15. https://github.com/NVIDIA/TensorRT-LLM/releases/tag/v1.3.0rc21
• NVIDIA TensorRT-LLM PR #15918, "BREAKING: Remove python modules and tests for legacy TensorRT backend", merged 2026-07-14. https://github.com/NVIDIA/TensorRT-LLM/pull/15918
• NVIDIA TensorRT-LLM PR #15424, "Native /v1/embeddings dynamic batching for encoder-only models", merged 2026-07-10. https://github.com/NVIDIA/TensorRT-LLM/pull/15424
• NVIDIA TensorRT-LLM PR #15631, "Add native post-processing hook to trtllm-serve", merged 2026-06-30. https://github.com/NVIDIA/TensorRT-LLM/pull/15631
• NVIDIA TensorRT-LLM PR #15526, "Add prefix-aware scheduling config flag to support opt-out", merged 2026-06-30. https://github.com/NVIDIA/TensorRT-LLM/pull/15526
• NVIDIA TensorRT-LLM PR #15640, "BREAKING: move multimodal related args / env vars", merged 2026-07-07. https://github.com/NVIDIA/TensorRT-LLM/pull/15640
• NVIDIA TensorRT-LLM PR #16091, "BREAKING: rename server args", merged 2026-07-10. https://github.com/NVIDIA/TensorRT-LLM/pull/16091
• NVIDIA TensorRT-LLM, "Architecture Overview" (PyTorch backend). https://github.com/NVIDIA/TensorRT-LLM/blob/v1.3.0rc21/docs/source/torch/arch_overview.md
• NVIDIA TensorRT-LLM, "Disaggregated Serving". https://github.com/NVIDIA/TensorRT-LLM/blob/v1.3.0rc21/docs/source/features/disagg-serving.md
• NVIDIA TensorRT-LLM, "trtllm-serve" command reference. https://github.com/NVIDIA/TensorRT-LLM/blob/v1.3.0rc21/docs/source/commands/trtllm-serve/trtllm-serve.rst
• NVIDIA TensorRT-LLM, "Embeddings (Encoder-Only Models)". https://github.com/NVIDIA/TensorRT-LLM/blob/v1.3.0rc21/docs/source/features/embeddings.md