제11장 — 플랫폼과 오케스트레이션 계층

LLM Primer VI: AI 시스템 확장하기를 챕터별로 걷는 워크스루의 열한 번째 글입니다. 플랫폼 선택은 기능이 아니라 어느 운영 모델이 팀의 기존 운영 문화에 맞는가의 문제라고 주장하는 장입니다.

이 장이 존재하는 이유

엔진은 GPU 위의 모델을 감싸고 토큰을 만듭니다. 그것이 그 일의 완전한 설명입니다. 프로덕션이 로드 밸런서 뒤의 두 리플리카, 한 엔드포인트 아래의 두 서로 다른 엔진, embed→retrieve→rerank→generate를 하나의 논리적 호출로 돌리는 파이프라인, 한 테넌트가 다른 테넌트를 굶기지 않게 하는 할당량 시스템, 또는 큐 깊이가 오르면 리플리카를 늘리는 오토스케일러를 필요로 하는 순간 엔진은 답을 다 썼습니다. 제11장은 2026년 그 일을 지배하는 네 플랫폼 — Ray Serve, KServe, BentoML, Triton Inference Server — 을 걷고, 그 사이의 선택이 기능 문제가 아니라 팀의 운영 문화에 대한 적합성 문제라고 주장합니다.

11.1 Ray Serve는 파이썬 우선, KServe는 쿠버네티스 우선

Ray Serve는 「모델 파이프라인을 구성하고 확장하고 배포하기 위해 파이썬을 결코 떠나지 않아도 되는 서빙 프레임워크는 어떤 모양일까?」라는 시작 질문에서 나옵니다. 답은 액터로 데코레이트된 파이썬 클래스이고, 파이썬 함수 호출로 서로 배선되며, Ray 런타임이 리플리케이션·배치·오토스케일링을 합니다. 배포는 서로의 메서드를 호출함으로써 파이프라인으로 구성됩니다. 파이프라인은 파이썬, 관측 가능성은 파이썬, 운영 이야기도 파이썬. 같은 클러스터가 이미 학습을 위해 Ray를 돌리고 있을 때 자연스러운 선택입니다. KServe는 반대의 시작점에서 나옵니다 — 쿠버네티스 우선, 벤더 중립, 선언적. KServe InferenceService는 가중치가 어디에 있는지, 어떤 런타임이 서빙하는지, 오토스케일링이 어떻게 행동해야 하는지를 담는 CRD입니다. 플랫폼은 Knative를 통해 스케일 투 제로, Istio를 통해 트래픽 라우팅을 하도록 파드를 배선하고 안정된 HTTP 엔드포인트를 노출합니다. 절충은 표현력 — KServe에서의 파이프라인 구성은 Ray Serve보다 YAML 중심 — 을 이식성과 표준화와 맞바꾸는 것입니다.

11.2 BentoML은 패키징하고, Triton은 이종 모델을 배치한다

BentoML은 세 번째 자세를 취합니다 — 플랫폼의 일차 임무는 모델 + 코드 + 의존성을 하나의 일관된 아티팩트 — 벤토 — 로 만들고 그 아티팩트를 어디든(Kubernetes, Lambda, Cloud Run, 베어 VM) 한 명령으로 배포하게 하는 것입니다. 일반 애플리케이션에 대한 도커 이미지가 모델 서빙 계층에 있는 것이라 할 수 있습니다. 저작 경험은 FastAPI 모양의 파이썬이고, 배포 이야기는 아티팩트 우선의 수입니다. 작은 운영 발자국과 「파이썬 클래스」에서 「어디서든 돌아가는 배포된 엔드포인트」까지 가장 빠른 경로를 원하는 팀에 가장 잘 맞습니다. Triton Inference Server는 역사적으로 NVIDIA 정렬 서빙을 지배했던 엔터프라이즈급 동적 배처입니다. TensorFlow, PyTorch, ONNX, TensorRT, TensorRT-LLM, 파이썬 백엔드를 나란히 호스트하고, 동적 배처를 비LLM 워크로드(추천기, 분류기, 임베더)에 적용하며, LLM에는 TensorRT-LLM 백엔드 아래에서 연속 배칭 스케줄러를 씁니다. 이종 워크로드나 이미 NVIDIA 스택에 깊이 들어간 팀에 가장 잘 맞습니다.

11.3 네 선택은 운영 문화 적합성으로 분할된다

네 플랫폼은 깔끔하게 나뉩니다. 파이썬과 Ray가 중심 → Ray Serve. 쿠버네티스, 선언적 매니페스트, 멀티 클라우드 이식성, 멀티 테넌트 격리 → KServe. 작은 운영 발자국, 클래스에서 엔드포인트로의 가장 빠른 경로 → BentoML. 이종 워크로드 또는 NVIDIA 우선 조직 → Triton. 조직 수준에서 상호 배타적이지 않습니다 — 큰 조직의 흔한 패턴은 가장 볼륨이 큰 프로덕션 LLM에는 Triton, 여러 모델 호출을 구성하는 RAG와 에이전트 파이프라인에는 Ray Serve, 멀티 테넌시를 강제하는 우산으로 KServe, 개발자 환경 안에는 BentoML입니다. 고를 때 유용한 훈련은 팀이 절대 필요로 하는 운영 성질 세 개와 절대 없어도 되는 성질 세 개를 나열하고, 그 목록에 대해 플랫폼들을 순위 매기는 것입니다. 「모든 것을 지원」하는 플랫폼에 저항하십시오 — 각 플랫폼은 자기 코어를 잘 지원하고 주변을 서투르게 지원합니다. 그 코어가 반드시 필요한 것들과 겹치는 것이 팀이 운영하기 즐거운 플랫폼입니다.

제11장이 준비하는 것

엔진/플랫폼 경계는 리플리케이션의 단위가 한 GPU 노드 위의 모델 하나를 소유하는 한 파드일 때 깔끔합니다. 제1장의 사실 — 프리필과 디코드는 서로 모순되는 워크로드 — 을 존중하는 순간 그 경계는 깔끔하지 않게 됩니다. 제12장은 그것들을 별도의 GPU 풀로 나누고, 네트워크 패브릭 위로 풀 사이에 KV 캐시를 보내며, 그 분할을 쿠버네티스 프리미티브 — LeaderWorkerSet, Grove의 PodCliqueSet, KAI Scheduler의 토폴로지 인식 — 로 표현합니다. 플랫폼 계층이 그 분할을 운영 가능하게 만들고, 플랫폼 계층이 그 분할을 표현 가능하게 만드는 이유입니다.

다음 → 제12장: 분리 서빙과 쿠버네티스. 프리필과 디코드를 별도 파드로 나누고 그 분할을 표현하는 쿠버네티스 프리미티브.