LLM WikiAccess-protected knowledge portal

WIKI

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

왜 지금 봐야 하나 TensorRT LLM v1.3.0rc21은 2026년 7월 15일에 공개됐다. 이번 릴리스의 핵심은 새 모델 몇 개를 더 얹은 것이 아니다. TensorRT LLM이 앞으로 어떤 실행 경로를 중심으로 진화할지 방향을 분명히 한 릴리스 라는 점이 더 중요하다. 이번 변화가 특히 중요한 이유는 세 가지다. 1. Python 패키지에서 레거시 TensorRT 실행 백엔드가 빠졌다. import tensorrt

경로human/study/content/ai-frontier/39-tensorrt-llm-1-3-rc-pytorch-backend-disagg-serving.md
카테고리Study
태그#ai-review #airflow #backend #disagg #llm #pytorch #serving #study

왜 지금 봐야 하나

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을 앞으로 어떤 런타임, 어떤 서버 표면, 어떤 배포 토폴로지로 운영해야 하는가를 다시 묻게 만드는 릴리스다.

핵심 변화 한눈에 보기

축1.3 RC에서 실제로 바뀐 점운영자가 받는 의미
실행 백엔드Python 패키지에서 레거시 TensorRT 백엔드 제거, PyTorch 백엔드 중심 구조로 정리새 기능이 어느 경로에 먼저 들어오는지 분명해짐. 커스텀 import·CI 이미지·런타임 의존성 점검 필요
서버 표면trtllm-serve embeddings, native dynamic batching, post-processing hook, 서버 인자 renameTriton 앞단 없이 임베딩 엔드포인트를 직접 운영할 수 있고, 서버 단에서 후처리/정책 삽입 가능
서빙 토폴로지disaggregated serving 문서화 성숙, DSv4 sparse MLA, prefix-aware scheduling opt-out, dynamic speculation 확장긴 프롬프트/중간 길이 출력 워크로드에서 TTFT와 TPOT을 분리 최적화할 수 있지만, known issue 기반 카나리 검증이 필수
제품 전략AutoDeploy backend deprecated“새 모델을 빨리 붙이는 경로”가 AutoDeploy보다 PyTorch backend 쪽으로 이동했음을 의미

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

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

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

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가 모델 추론을 조율한다고 설명한다. 여기서 중요한 구성요소는 네 가지다.

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

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

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

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

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

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

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

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

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

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

그래서 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 엔드포인트를 추가했다. 이 경로의 설계 포인트는 명확하다.

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

이 설계는 “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을 추가했다. 이 기능을 너무 작게 보면 안 된다. 단순 문자열 후처리 기능이 아니라, 서버가 모델 출력 뒤에 정책을 삽입할 공식 지점이 생겼다는 의미다.

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

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

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

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

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

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

TensorRT-LLM 1.3 RC는 Python 표면을 PyTorch backend + 분리 서빙 중심으로 다시 정렬한다 클라이언트 Chat / Completions / Responses Embeddings clients `trtllm-serve` 제어면 OpenAI 호환 엔드포인트 /v1/chat · /v1/completions · /v1/models `embeddings` 서브커맨드 native dynamic batching post-processing hook 응답 rewrite / suppress / terminate CLI / multimodal 설정 정리 arg rename · env 이동 관측 엔드포인트: /health · /metrics · /version PyTorch backend / `LLM` / `PyExecutor` Scheduler 요청 수용·배치 선택 Model Engine GPU forward 실행 Decoder 토큰 생성 ResourceManager / KVCacheManager 요청 step 전후 자원 갱신 · KV cache 수명주기 관리 분리 서빙 데이터면 Prefill GPU pool TTFT 최적화 KV cache exchange UCX / NIXL / MPI MLA / layout 변환 Decode GPU pool TPOT 최적화 1.3 RC 운영 경계 AutoDeploy deprecated 모델·GPU 조합 known issue 다수 카나리·실측이 먼저 이 릴리스의 본질 Python 표면은 PyTorch backend 중심으로 정리되고, 서버 표면은 OpenAI 호환 API + 정책 훅 + 임베딩 배칭을 품게 되며, 대규모 배포에서는 분리 서빙이 주력 옵션으로 올라오지만 그만큼 known issue 기반의 선별 도입이 중요해진다.
TensorRT-LLM 1.3 RC 실행/서빙 구조: PyTorch 중심 재정렬

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

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

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

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

1.3 RC가 여기에 추가한 것들

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

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

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

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

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

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

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

이번 릴리스는 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

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

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

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

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 도입 검증은 평균 처리량 하나로 끝내면 안 된다. 적어도 아래를 나눠 측정해야 한다.

특히 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하는 편이 빠르다.

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

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

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

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

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

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

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

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

운영 체크리스트

References