소스에서 Triton 빌드하기

소스에서 Triton 빌드하기

이 문서는 Triton 서버를 소스에서 빌드하는 방법을 설명해요. Triton 클라이언트 라이브러리·예제 빌드는 Client Libraries and Examples, Triton SDK 컨테이너 빌드는 Build SDK Image, 빌드 테스트는 Testing Triton을 참고하세요.

소스에서 빌드하지 않고 릴리스된 백엔드의 일부만 담은 커스텀 Triton Docker 이미지를 만들 수도 있어요. 예를 들어 TensorRT·Python 백엔드만 담은 이미지가 필요할 때요. 이런 커스터마이즈는 소스에서 빌드할 필요 없이 compose 유틸리티를 쓰면 돼요.

출처: 공식문서

빌드 개요

Triton 소스는 여러 GitHub 저장소에 걸쳐 있고, 이들을 함께 빌드·설치하면 완전한 Triton 설치가 돼요. Triton 서버는 CMake와 (선택적으로) Docker로 빌드돼요. 빌드 과정을 단순화하기 위해 Triton은 build.py 스크립트를 제공해요. build.py는 Triton을 빌드하는 데 필요한 CMake·Docker 빌드 단계를 생성하고, 선택적으로 그 단계를 직접 실행하거나 실행을 여러분에게 맡겨요.

build.py는 현재 다음 플랫폼에 대한 Triton 빌드를 지원해요.

  • Ubuntu 22.04, x86-64

이 목록에 없는 플랫폼에서 빌드하려면 Unsupported Platforms에서 빌드를 참고하세요. Triton을 개발·디버깅 중이라면 개발·증분 빌드를 참고해 증분 빌드 방법을 확인하세요.

Ubuntu 22.04용 빌드

Ubuntu-22.04에서 build.py는 Docker 빌드와 비-Docker 빌드 둘 다 지원해요.

Docker로 빌드

가장 쉬운 빌드 방법이에요. 빌드 결과는 tritonserver라는 Docker 이미지로, /opt/tritonserver/bin에 tritonserver 실행 파일, /opt/tritonserver/lib에 필요한 공유 라이브러리가 들어 있어요. 빌드된 백엔드와 repository-agents는 각각 /opt/tritonserver/backends, /opt/tritonserver/repoagents에 있어요.

빌드의 첫 단계는 빌드할 릴리스의 triton-inference-server/server 저장소 브랜치(또는 개발 브랜치로 빌드하려면 main 브랜치)를 클론하는 거예요. 그런 다음 아래처럼 build.py를 실행해요. build.py는 Docker로 빌드할 때 다음 단계들을 수행해요.

  • server 저장소의 build 하위 디렉토리에서 docker_build 스크립트, cmake_build 스크립트, Triton 빌드에 필요한 Dockerfiles를 생성해요. –dryrun 플래그를 쓰면 build.py는 여기서 멈춰서 이 파일들을 살펴볼 수 있게 해줘요.
  • docker_build 스크립트를 실행해 Docker 기반 빌드를 수행해요. docker_build 스크립트는 다음 단계를 수행해요.
    • Triton 빌드에 필요한 빌드 의존성을 모두 모은 tritonserver_buildbase Docker 이미지를 빌드해요. 이 이미지는 minimal/base 이미지 기반이에요. GPU 지원(–enable-gpu)으로 빌드할 때 min 이미지는 Triton 빌드에 필요한 CUDA·cuDNN·TensorRT 등의 의존성을 담은 NGC에서 받은 <xx.yy>-py3-min 이미지예요. GPU 지원 없이 빌드할 때 min 이미지는 표준 ubuntu:22.04 이미지예요.
    • tritonserver_buildbase 이미지 안에서 cmake_build 스크립트를 실행해 실제로 Triton을 빌드해요. cmake_build는 다음 단계를 수행해요.
    • 빌드된 산출물을 컨테이너 밖, 호스트 시스템의 build 하위 디렉토리로 복사해요.
    • 빌드의 라이브러리·실행 파일·기타 산출물을 담은 최종 tritonserver Docker 이미지를 만들고, Testing Triton에 설명된 테스트에 필요한 QA 산출물을 담은 tritonserver_cibase Docker 이미지도 만들어요.

기본적으로 build.py는 Triton의 선택 기능을 하나도 켜지 않지만, –enable-all 플래그로 모든 기능·백엔드·repository agent를 켤 수 있어요. -v 플래그는 상세 출력을 켜요.

$ ./build.py -v --enable-all

특정 Triton 기능·백엔드·repository agent만 켜고 싶다면 –enable-all을 쓰지 말고, –help에 문서화된 개별 플래그를 지정해야 해요.

특정 GitHub 브랜치로 빌드

위에서 설명한 것처럼 빌드는 server 저장소에서 이뤄지지만, 빌드 과정에서 다른 여러 저장소의 소스도 가져와요. 보통 이 저장소들에 대해 아무것도 지정할 필요는 없지만, 어떤 브랜치를 쓸지 제어하고 싶다면 다음과 같이 할 수 있어요.

$ ./build.py ... --repo-tag=common:<container tag> --repo-tag=core:<container tag> --repo-tag=backend:<container tag> --repo-tag=thirdparty:<container tag> ... --backend=tensorrt:<container tag> ... --repoagent=checksum:<container tag> ...

릴리스 브랜치에서 빌드하면 <container tag>는 기본적으로 그 브랜치 이름이 돼요. 예를 들어 r24.12 브랜치에서 빌드하면 <container tag>는 기본적으로 r24.12예요. 다른 브랜치(main 브랜치 포함)에서 빌드하면 <container tag>는 기본적으로 "main"이 돼요. 그래서 보통 <container tag>(앞의 콜론도)를 지정할 필요가 없어요. 특정 컴포넌트에 다른 <container tag>를 쓰면 빌드에서 해당 브랜치/태그를 사용해요. 예를 들어 onnxruntime_backend 저장소에 mybranch라는 브랜치가 있고 그걸 쓰고 싶다면 –backend=onnxruntime:mybranch를 지정하면 돼요.

실험 기능: 빌드 프리셋 (Build Presets)

실험 기능. 이 기능은 TRITON_BUILD_EXPERIMENTAL=1 환경 변수 뒤로 가려져 있고, 그 변수 없이는 --build-presets-file 플래그가 거부돼요.

빌드 프리셋은 (a) 각 컴포넌트가 정확히 어떤 cmake 플래그를 받는지 검사하고, (b) 단일 JSON 파일(--build-presets-file <path>)로 그 플래그를 고정할 수 있게 해줘요.

스냅샷(dump). --dryrun으로 실행하면 build.py가 완전히 해석된 cmake 구성을 provenance가 주석으로 달린 스냅샷으로 build 디렉토리의 build_presets.json에 기록해요. core, 각 백엔드, repoagent, cache에 대해 cmake_build에 들어가는 모든 -D 플래그를 그 출처(cli(명령줄), preset(불러온 프리셋 파일), default(build.py 기본/파생))와 함께 기록해요.

{
  "backends": {
    "onnxruntime": {
      "tag": { "value": "main", "source": "default" },
      "cmake_args": {
        "TRITON_ENABLE_GPU": { "value": "ON", "source": "cli" },
        "TRITON_BUILD_ONNXRUNTIME_VERSION": { "value": "1.27.0", "source": "default" }
      }
    }
  }
}

리로드. 같은 파일을 --build-presets-file로 다시 넣으면 그 플래그를 고정할 수 있어요(불러올 때 source 필드는 정보용이에요). 손으로 쓴 프리셋은 {value, source} 객체 대신 단순 스칼라를 써도 돼요.

{
  "backends": {
    "onnxruntime": {
      "tag": "r25.08_fix",
      "cmake_args": { "TRITON_ENABLE_ONNXRUNTIME_OPENVINO": "OFF" }
    },
    "python": {
      "extra_cmake_args": { "TRITON_BOOST_URL": "https://.../boost_1_80_0.tar.gz" }
    }
  }
}

참고 사항:

  • 파일에 이름이 있는 컴포넌트는 (--backend/--repoagent/--cache 또는 --enable-all로) 빌드에도 포함되어야 해요.
  • 명령줄 플래그가 항상 파일보다 우선해요.
  • cmake_args는 build.py가 자체적으로 내보내는 플래그(override 채널로 적용)이고, extra_cmake_args는 build.py가 내보내지 않는 사용자 추가 플래그(append 채널로 적용)예요. 백엔드의 cmake_args에 TRITON_REPO_ORGANIZATION을 설정하면 그 백엔드의 클론 조직을 백엔드별로 설정해요(git clone URL과 -D 둘 다). 이건 전역 --github-organization이 못 하는 일이에요.
  • CMAKE_INSTALL_PREFIX는 절대 build-dir 경로라서 스냅샷에서 빠져요. repoagent/cache의 cmake_args는 가시성을 위해 보여주지만 리로드 시 그 태그만 다시 고정돼요. 리로드는 -D 값을 고정하지만 조건부로 내보내진 플래그는 다시 파생하지 않으므로, 정확한 재현을 위해 같은 최상위 플래그(또는 --enable-all)와 함께 리로드해야 해요.

복사해 쓸 수 있는 예제는 tools/build/build_presets.example.json에 있고, 전체 스키마는 tools/build/build_presets.py에 문서화되어 있어요.

CPU 전용 빌드

GPU 지원 없이 빌드하려면 --enable-gpu와 --enable-gpu-metrics 플래그를 포함하지 않고 개별 기능 플래그를 지정해야 해요. 비-GPU/CPU 전용 빌드에서 사용 가능한 백엔드는 identity, repeat, ensemble, square, pytorch, onnxruntime, openvino, python, fil뿐이에요.

PyTorch 백엔드의 CPU 전용 빌드에는 CPU 전용 base 컨테이너에 없는 CUDA 스텁과 런타임 의존성이 필요해요. 이들은 GPU base 컨테이너에서 가져오는데, --image=gpu-base,nvcr.io/nvidia/tritonserver:<xx.yy>-py3-min 플래그로 바꿀 수 있어요.

Docker 없이 빌드

Docker 없이 Triton을 빌드하려면 Docker로 빌드할 때 자동으로 처리되는 빌드 의존성을 직접 설치해야 해요.

첫 단계는 빌드할 릴리스의 triton-inference-server/server 저장소 브랜치(또는 main 브랜치)를 클론하는 거예요.

빌드에 필요한 의존성을 파악하려면 build.py를 –dryrun 플래그로 실행하고, build 하위 디렉토리의 Dockerfile.buildbase를 살펴봐요.

$ ./build.py -v --enable-all

Dockerfile.buildbase에서 호스트 시스템에 설치해야 할 의존성을 알 수 있어요. –enable-gpu(또는 –enable-all)로 빌드할 때 Dockerfile.buildbase는 NGC에서 받은 <xx.yy>-py3-min 이미지에 의존한다는 점을 유의하세요. 아쉽게도 <xx.yy>-py3-min 이미지용 Dockerfile은 현재 제공되지 않아요. 대신 아래 설명대로 CUDA·cuDNN과 TensorRT 의존성을 직접 설치해야 해요.

이 의존성들을 빌드 시스템에 설치하고 나면 –no-container-build 플래그로 build.py를 실행해 Triton을 빌드할 수 있어요.

$ ./build.py -v --no-container-build --build-dir=`pwd`/build --enable-all

cmake_build 스크립트가 어떻게 빌드에 쓰이는지 자세한 내용은 Docker로 빌드하기를 참고하세요.

CUDA, cuBLAS, cuDNN

Triton이 NVIDIA GPU를 지원하려면 CUDA·cuBLAS·cuDNN을 설치해야 해요. 이 라이브러리들은 빌드에서 사용할 수 있도록 시스템 include·library 경로에 설치되어야 해요. 특정 릴리스에서 사용되는 라이브러리 버전은 Framework Containers Support Matrix에서 볼 수 있어요.

특정 Triton 버전에서 지원하지 않는 버전의 라이브러리로 빌드를 시도할 수는 있지만, 지원되지 않는 버전은 테스트되지 않았으므로 빌드·실행에 문제가 생길 수 있어요.

TensorRT

TensorRT 헤더와 라이브러리를 시스템 include·library 경로에 설치해서 빌드에서 사용할 수 있게 해야 해요. 특정 릴리스에서 사용되는 TensorRT 버전은 Framework Containers Support Matrix에서 볼 수 있어요.

특정 Triton 버전에서 지원하지 않는 버전의 TensorRT로 빌드를 시도할 수는 있지만, 지원되지 않는 버전은 테스트되지 않았으므로 빌드·실행에 문제가 생길 수 있어요.

Unsupported Platforms에서 빌드

지원되지 않는 OS/하드웨어 플랫폼을 위한 빌드도 가능해요. 모든 빌드 스크립트·Dockerfiles·CMake 호출은 공개 저장소에 있거나 Docker로 빌드하기에서 설명한 대로 build.py가 생성해요. 이 파일들에서 필요한 의존성과 CMake 호출을 찾을 수 있어요. 다만 컴파일러·라이브러리·패키지 관리 등의 차이 때문에 빌드 스크립트·Dockerfiles·CMake 파일·소스 코드를 수정해야 할 수 있어요.

아래에서 참조하는 생성된 빌드 스크립트·Dockerfile을 보려면 다음을 사용하세요.

$ ./build.py -v --enable-all --dryrun

먼저 지원되는 플랫폼의 빌드 과정을 위 문서로 익히고, 관심 있는 플랫폼과 가장 비슷한 지원 플랫폼의 과정을 따라가야 해요(예: RHEL/x86-64용 빌드는 Ubuntu 22.04용 빌드 과정을 따라가요). 다음 영역에서 수정이 필요할 가능성이 높고, 그 후 docker_build·cmake_build(또는 동등한 명령)를 직접 실행해 빌드해야 해요.

  • 생성된 Dockerfiles는 apt-get(Ubuntu) 같은 플랫폼별 패키징 도구로 빌드 의존성을 설치해요. 여러분 플랫폼에 맞는 패키징 도구를 쓰도록 build.py를 수정해야 해요.
  • 여러분 플랫폼의 패키지·라이브러리 이름이 생성된 Dockerfiles가 쓰는 것과 다를 수 있어요. 해당 패키지를 찾아야 해요.
  • 여러분 플랫폼이 지원 플랫폼과 다른 컴파일러·컴파일러 버전을 쓸 수 있어요. 그 결과 소스 코드 수정이나 컴파일 플래그 변경으로 고쳐야 할 빌드 에러가 생길 수 있어요.
  • Triton은 소스에서 빌드하는 수많은 오픈소스 패키지에 의존해요. 그 중 하나가 플랫폼을 지원하지 않으면 그 패키지에 의존하는 Triton 기능을 꺼야 할 수 있어요. 예를 들어 Triton은 aws-sdk-cpp 패키지를 빌드해 S3 파일시스템을 지원해요. aws-sdk-cpp가 여러분 플랫폼에서 빌드되지 않으면 build.py 실행 시 –filesystem=s3를 지정하지 않아 그 패키지의 필요성을 없앨 수 있어요. 일반적으로 최소한의 필수 기능 집합으로 build.py를 실행하는 것부터 시작해야 해요.
  • 기본적으로 PyTorch 백엔드 빌드는 PyTorch NGC 컨테이너에서 미리 빌드된 공유 라이브러리를 추출해요. 하지만 여러분 플랫폼용으로 직접 빌드한 PyTorch 공유 라이브러리도 쓸 수 있어요. 자세한 내용은 pytorch_backend 빌드 과정을 참고하세요.

개발 및 증분 빌드

Docker 없는 개발 빌드

Docker 없이 빌드한다면 cmake_build의 CMake 호출 단계를 사용해, make를 호출해 Triton 코어·백엔드·repository agent를 증분 빌드할 수 있는 빌드 환경을 구성해요.

Docker를 쓰는 개발 빌드

Docker로 빌드한다면 생성된 tritonserver_buildbase 이미지가 전체·증분 빌드에 필요한 모든 의존성을 담고 있어요. tritonserver_buildbase 안의 /workspace/build/cmake_build에는 Triton 코어·백엔드·repository agent를 빌드하는 데 쓰는 CMake 호출이 들어 있어요.

tritonserver_buildbase 컨테이너 안에서 증분 빌드를 하려면 소스를 컨테이너에 매핑하고, 컨테이너 안 cmake_build의 적절한 CMake·make 단계를 실행해요.

Triton 코어 개발 빌드

호스트 시스템에 server 저장소 클론이 있고(예: /home/me/server) 거기서 변경하며 증분 빌드로 테스트하고 싶다고 가정해요. tritonserver_buildbase 컨테이너를 실행하고 server 소스 디렉토리를 컨테이너의 /server에 매핑해요.

$ docker run -it --rm -v/home/me/server:/server tritonserver_buildbase bash

컨테이너 안 /workspace/build/cmake_build에서 "Triton core library"를 빌드하는 명령 섹션을 확인해요. 그 명령을 그대로 따라 하거나, 빌드 디렉토리·CMake 옵션을 바꾸도록 수정할 수 있어요. CMake 명령은 CMakeLists.txt 파일과 소스 위치로 /workspace 대신 /server를 쓰도록 반드시 바꿔야 해요.

$ cmake <options> /server

그런 다음 build 디렉토리로 이동해 cmake_build에 나온 대로 make를 실행해요. 호스트 시스템 소스를 변경하며 make를 다시 실행해 증분 빌드를 할 수 있어요.

백엔드 또는 Repository Agent 개발 빌드

백엔드·repository agent의 전체·증분 빌드는 Triton 코어 빌드와 비슷해요. TensorRT 백엔드를 예로 들어볼게요. 호스트 시스템에 TensorRT 백엔드 저장소 클론이 있고(예: /home/me/tritonserver_backend) 거기서 변경하며 증분 빌드로 테스트하고 싶다고 가정해요. tritonserver_buildbase 컨테이너를 실행하고 TensorRT 백엔드 소스 디렉토리를 컨테이너의 /tensorrt_backend에 매핑해요. 일부 백엔드는 빌드 과정에 Docker를 쓰므로, 호스트의 Docker 레지스트리를 tritonserver_buildbase 안에서 쓸 수 있도록 docker.sock을 마운트해야 해요.

$ docker run -it --rm -v/var/run/docker.sock:/var/run/docker.sock -v/home/me/tensorrt_backend:/tensorrt_backend tritonserver_buildbase bash

컨테이너 안 /workspace/build/cmake_build에서 "TensorRT backend"를 빌드하는 명령 섹션을 확인해요. 그 명령을 그대로 따라 하거나, 빌드 디렉토리·CMake 옵션을 바꾸도록 수정할 수 있어요. CMake 명령은 CMakeLists.txt 파일과 소스 위치로 /workspace 대신 /tensorrt_backend를 쓰도록 반드시 바꿔야 해요.

$ cmake <options> /tensorrt_backend

그런 다음 build 디렉토리로 이동해 cmake_build에 나온 대로 make를 실행해요. 호스트 시스템 소스를 변경하며 make를 다시 실행해 증분 빌드를 할 수 있어요.

디버그 심볼로 빌드

디버그 심볼로 빌드하려면 build.py 실행 시 –build-type=Debug 인자를 쓰면 돼요. CMake로 직접 빌드한다면 -DCMAKE_BUILD_TYPE=Debug를 쓰면 돼요. 빌드한 서버를 gdb로 실행하면 gdb 트레이스에서 디버그 심볼·정보를 볼 수 있어요.

더 알아보기 (Learn more)