triton

Hermaeus Mora · · Devops

❯ 큐 하나당 서버가 하나씩 뜨면 굳이 triton이 필요 없는거아님? 2. trition이 지금은 파드 하나당 뜨는데, 이거 중앙화 해야하는거 아님? 3. 모델 preload를 하면 vram 터지는 경우가 있었는데 이거 lazy loading으로 바꿔야 하는거 아님? 4. lazy loading을 쓴다고 할 때, 이전 추론때 사용한 모델의 잔여 메모리를 전부 회수한 다음에 추론을 해야지 OOM이 안날거아냐? 이걸 trition에서 해주나? 1 skill available

근거 있게 답하려고 지금 GPU 메모리 실측부터.

Ran 1 shell command

실측하려고 했는데 AWS SSO 토큰이 만료돼서 클러스터에 못 붙음. 그래서 아래는 실측 없이, 어제 확인한 구성(A10G 24GB, ONNX 모델 2개 약 0.8GB, segcls worker는 segmenter랑 classifier 둘 다 씀)을 기준으로 답함.

  1. 큐마다 worker가 하나씩인데 Triton이 왜 필요한가? 필요함. worker는 큐에서 메시지를 받아오는 consumer일 뿐이고 추론 서버가 아님. Triton을 빼면 각 worker 프로세스가 직접 GPU에 모델을 올려야 함:
  • 프로세스마다 CUDA context가 따로 잡힘 (수백 MB씩).
  • 프로세스마다 ONNX Runtime 메모리 arena도 따로 커짐.
  • segcls도 classifier를 쓰니까 classifier가 VRAM에 두 번 올라감.
  • 두 프로세스가 동시에 추론하면 피크 메모리가 겹침.

예전에 OOM 나던 게 이 구조 때문일 가능성이 큼. Triton을 두 나라 모델도 한 벌씩만 올라가고, ratelimiter(GPU_EXECUTION:1)가 추론을 한 번에 하나씩만 돌게 직렬화함. Triton 없이 같은 효과를 내려면 큐 두 개를 프로세스 하나가 같이 소비하게 앱을 바꿔야 함.

  1. Triton을 중앙화해야 하나? 지금 구성에선 아님.
  • GPU가 1장이고 pod 1개가 노드 1대라, 따로 떼도 결국 같은 나 늘어남.
  • 스케일링 단위가 어긋나는 문제가 생김. worker만 떠 있고 Triton은 0인 상황 같은 걸 맞춰야 하고, 큐가 비면 0으로 내리는 흐름도 복잡해짐.

중앙화가 의미 있어지는 경우:

  • worker를 CPU 노드에서 GPU랑 따로 늘리고 싶을 때
  • 다른 서비스도 같은 모델을 쓸 때
  • GPU 여러 장에서 dynamic batching으로 처리량을 올려야 할
  1. preload 대신 lazy loading으로 바꿔야 하나? 지금 모델 크기면 아님. 가중치 0.8GB에 실행 중 쓰는 메모리를 더해도 24GB A10G에서는 여유가 많음.
  • lazy loading은 요청 때마다 모델 로드 시간(수 초)이 추가되면서 오히려 메모리 단편화나 latency가 불안정해짐.
  • 모델 전체 크기가 VRAM을 넘을 때만 필요함.

preload에서 VRAM이 터졌던 건 아마 예전 구조 때문일 것:

  • 여러 프로세스가 모델을 중복으로 들고 있었음.
  • 그 당시엔 SAM2 large encoder(813MB)까지 같이 올라가 있었음.
  • ONNX Runtime arena가 한 번 커지면 메모리를 반납하지 않음.
  1. lazy loading이면 Triton이 이전 모델 메모리를 회수해주나? 자동으로는 안 해줌.
  • --model-control-mode=explicit으로 두면 load/unload API는 고 다음 모델을 올리는 걸 자동으로 해주는 LRU 같은 기능은오픈소스 Triton에 없음. 순서는 우리가 직접 짜야 함.
  • unload하면 그 모델의 ONNX Runtime 세션이 정리되면서 메모 지만 처리 중인 요청이 끝날 때까지 기다리는 것도 우리가 챙겨야 하고, CUDA context나 Triton 메모리 풀은 그대로 남음.

그래서 OOM을 막고 싶으면 lazy loading보다 지금처럼 preload 해두고 메모리 상한을 거는 게 맞음:

  • rate limiter는 이미 적용돼 있음. 동시 실행 피크가 없으니 모델이 쓰는 실행 메모리"로 상한이 정해짐.
  • 모델별 config.pbtxt에서 ONNX Runtime의 gpu_mem_limit이랑 arena_extend_strategy(kSameAsRequested)를 설정하면 arena가 무한정 커지는 것도 막을 수 있음.

결론: 지금 구조(pod 하나에 Triton 하나, 모델 preload, rate 설계임. 남은 건 실측해서 확인하는 것뿐.