Triton과 vLLM으로 구성하는 멀티프레임워크 추론 서버 운영

하나의 추론 플랫폼에서 LLM과 기존 모델을 함께 다루는 방식

Netflix가 vLLM을 NVIDIA Triton Inference Server에 통합한 운영 구조를 공개하면서, 생성형 모델과 기존 딥러닝 모델을 동일 서버에서 운영하는 멀티프레임워크 추론 환경이 대규모 조직의 배치 방식으로 주목받고 있다.

이 구성에서 Triton은 모델 적재, 배칭, GPU 스케줄링, 멀티프레임워크 서빙을 맡는다. vLLM은 LLM 백엔드로 결합해 자체적인 배치 전략을 유지한다. gRPC와 OpenAI 호환 HTTP를 함께 제공하면 사내 표준 프로토콜과 외부 도구 생태계를 한 플랫폼에서 지원할 수 있다.

임베딩 생성, 프리필 전용 추론, 자기회귀 디코딩, 커스텀 제약 로직 모델도 같은 플랫폼에서 서빙 대상이 된다. 추천·랭킹 모델과 LLM이 배포 및 관측 체계를 공유하면 별도 파이프라인을 두 벌 유지할 필요가 줄어든다. TensorRT-LLM에서 vLLM으로 바꾸는 일도 플랫폼 전체를 다시 만드는 대신 백엔드를 교체하는 문제로 축소할 수 있다.

다만 표준 서버를 거치면서 엔진 고유 기능 일부는 추상화 뒤에 놓인다. 최적화 자유도와 운영 일관성 사이의 교환이다.

요청 경로와 실행 계층을 분리하는 구조

표준 추론 서버는 요청 수신, 라우팅, 메트릭 수집을 담당하고 실제 실행은 백엔드가 맡는다. LLM 백엔드는 자체 배치 스케줄러와 KV 캐시 관리를 계속 사용하므로, 상위 서버의 동적 배치가 이 기능과 이중으로 겹치지 않도록 설정을 정리해야 한다.

모델 리포지터리는 모델 아티팩트와 설정을 규약된 디렉터리 구조로 관리한다. 버전 디렉터리를 추가해 새 버전을 등록하는 방식이므로, 배포는 파일 배치 문제로 환원되고 배포 도구와의 결합도 단순해진다.

인스턴스 그룹에서는 모델별 인스턴스 수와 배치 장치를 선언한다. 동일 모델을 여러 인스턴스로 올려 처리량을 늘릴 수 있고, GPU를 지정해 격리할 수도 있다. 지연에 민감한 모델과 처리량을 우선하는 모델을 서로 다른 인스턴스 그룹 및 장치에 배치하는 것이 간섭을 줄이는 기본 방법이다.

전통적인 ML 모델에는 짧은 대기 시간 창에서 요청을 모아 처리량을 높이는 동적 배치가 유효하다. 전처리, 모델 실행, 후처리가 이어지는 앙상블 파이프라인은 서버 내부에서 단계를 연결해 네트워크 왕복을 줄이며, 다단계 추론에서 지연 이득이 커진다.

GPU 공유는 자원 효율을 높이지만 모델 사이의 지연 간섭을 일으킬 수 있다. 따라서 공유 여부는 모델 특성에 따라 선택해야 한다. 모델별 요청 수, 지연, 큐 대기, GPU 사용률을 동일 형식으로 노출하는 관측 체계도 공존 운영의 전제가 된다.

LLM은 적재 시간이 길기 때문에 준비 프로브 타임아웃을 별도로 잡아야 한다. 기존 ML 모델 기준값을 그대로 적용하면 배포가 실패할 수 있다. 워밍업 요청으로 커널 컴파일과 캐시 초기화를 마친 뒤 트래픽을 받아야 초기 요청의 지연 튐을 막을 수 있다.

⤢✕

모델을 올리기 전에 정할 운영 규약

공존 배치는 지연 요구가 느슨하거나 트래픽 패턴이 상보적인 모델에 적합하다. 반대로 P99 지연이 SLA인 실시간 경로 모델은 공존에 부적합하다. GPU 여유만 보고 모델을 추가하면 간섭이 발생한 뒤에야 원인을 추적하게 되므로, 공존 기준을 문서화해야 한다.

팀과 모델 단위의 GPU 쿼터도 플랫폼 정책으로 정의할 필요가 있다. 선착순 방식에서는 특정 팀이 자원을 독점할 수 있다. 쿼터는 GPU 개수뿐 아니라 메모리와 인스턴스 수로도 표현돼야 실효성이 있다.

모델 버전 롤아웃은 버전 디렉터리 추가, 소수 인스턴스 전환, 지표 확인, 전량 전환, 구버전 제거 순서로 표준화할 수 있다. LLM은 버전 사이의 아티팩트 크기가 크므로 두 버전이 동시에 적재되는 순간의 메모리 피크를 계산해야 한다.

모델별 워밍업 요청 세트는 배포 파이프라인에 포함한다. 대표 입력 길이 분포를 반영해야 캐시가 실사용과 유사하게 채워진다. 콜드스타트가 긴 대형 모델은 스케일아웃 반응도 느리므로 최소 인스턴스 수를 여유 있게 유지하는 편이 낫다.

관측 지표는 모델 유형과 무관하게 같은 이름과 라벨 규약을 사용해야 한다. 유형별로 스키마가 달라지면 통합 대시보드를 만들 수 없다. 한 모델의 장애가 서버 전체 중단으로 이어지지 않도록 인스턴스 그룹 단위 격리와 요청 타임아웃도 설정한다.

모델 등록, 배치 변경, 쿼터 조정은 승인 절차와 이력 관리 대상으로 둔다. 레지스트리 메타데이터에는 모델 소유자와 온콜 책임을 명시해 장애 발생 시 연락 경로를 분명히 한다.

통합 플랫폼과 전용 서비스의 선택 기준

구분	통합 추론 서버	모델별 전용 서비스
운영 복잡도	단일 체계	서비스 수만큼 증가
자원 효율	GPU 공유로 향상	파편화
장애 격리	인스턴스 그룹 단위	완전 격리
배포 유연성	표준 절차 강제	팀별 자유
최적화 자유도	추상화에 제약	완전
적합 상황	모델 다수·조직 규모 큼	소수 모델·특수 요구

통합 추론 서버는 배포, 관측, 자원 배분을 하나의 체계로 묶어 운영 부담과 GPU 파편화를 줄인다. 반면 전용 서비스는 완전한 장애 격리와 자유로운 최적화를 제공하지만, 서비스 수에 비례해 운영 표면이 늘어난다. 조직이 관리하는 모델 개수와 GPU 희소성이 전환점을 결정한다.

GPU 공유 배치는 유휴 자원을 줄여 총비용을 낮추지만 인접 워크로드의 부하가 지연에 영향을 준다. 전용 할당은 지연 예측성이 높지만 트래픽이 낮은 시간대에 자원이 놀 수 있다. 지연이 SLA인 모델은 전용으로, 배치·비동기 워크로드는 공유로 나누는 구성이 실무적인 균형점이다.

표준 서버를 경유하면 인터페이스, 메트릭, 배포 절차가 통일되어 이식성과 관측 일관성을 확보할 수 있다. 엔진을 직접 노출하면 엔진 고유 기능을 모두 활용할 수 있지만, 엔진 교체 시 클라이언트까지 영향이 미친다. 백엔드 플러그인 구조는 표준 인터페이스를 유지하면서 엔진별 배치 전략을 보존하는 중간 지점이다.

통합의 성패를 가르는 자원 정책과 책임 체계

이질적인 런타임을 하나의 서비스 계층으로 묶는 일은 통합 설계 문제다. 인터페이스와 메트릭을 통합 지점으로 삼고, 실행 계층은 플러그인으로 분리해야 확장 가능한 구조가 된다. 기술 자체보다 디렉터리 구조, 지표 이름, 배포 절차 같은 규약을 얼마나 강제하는지가 성패를 가른다.

희소한 GPU 자원에는 쿼터, 우선순위, 선점 규칙이 필요하다. 이를 정책으로 명시하지 않으면 자원 경쟁은 조직 갈등으로 번질 수 있다. 모델 특성에 따라 공유와 격리를 선택하는 이원 정책이 단일 정책보다 총효율이 높다.

모델 유형이 달라도 배포, 승인, 관측 절차를 하나로 유지해야 표준화의 이점이 남는다. 새 모델 유형이 생길 때마다 별도 절차를 만들면 표준은 무너진다. 레지스트리에 모델 소유자와 온콜 정보를 필수 항목으로 두는 일은 운영 책임을 명확히 하는 최소 장치다.

표준 추론 서버가 향하는 방향

표준 추론 서버 위에 LLM 전용 엔진을 백엔드로 올리는 구성이 대규모 조직의 기본 배치로 정착할 전망이다. OpenAI 호환 HTTP 인터페이스는 사내 플랫폼의 외부 노출 표준으로 굳어지며 도구 생태계 연동 비용을 낮출 수 있다.

GPU 공유와 격리 정책은 플랫폼 설정 항목으로 노출되고, 모델 등록 시 지연 등급을 선언하는 방식이 확산될 수 있다. 프리필·디코드 분리처럼 LLM에 특화된 배치 전략도 표준 서버의 스케줄링 개념에 흡수되는 방향으로 사양이 진화할 전망이다.