Triton에서 텍스트 임베딩 모델을 서비스하는 구조

Triton에서 텍스트 임베딩 모델을 서비스하는 구조

Scope

핵심 질문

Tokenizer가 필요한 텍스트 임베딩 모델을 Triton에서 서비스할 때 전처리와 모델 추론을 어떻게 나누는 것이 좋은가?

Research

핵심 근거

• Triton은 model repository와 여러 backend, ensemble을 지원한다.
• Python backend를 사용하면 tokenizer 같은 전처리 로직을 Triton 내부 model step으로 구현할 수 있다.
• tokenizer를 client에 두면 Triton은 tensor inference에 집중할 수 있지만 client별 구현중복이 생긴다.

참고 자료

• https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/python_backend/README.html
• https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/model_repository.html

Draft

텍스트 임베딩 모델은 문자열을 바로 neural network에 넣을 수 없기 때문에 tokenizer 위치를 먼저 결정해야 한다.

Client-side Tokenization

Client가 tokenizer를 실행해 input_ids와 attention_mask를 Triton에 보내면 inference server는 tensor processing에만 집중할 수 있다.

장점은 server path가 단순하고 Python preprocessing overhead가 줄어든다는 점이다. 단점은 여러 client가 같은 tokenizer와 version을 정확히 맞춰야 한다는 것이다.

Triton 내부 Tokenization

Python backend를 preprocessing model로 두고 문자열을 token tensor로 바꾼 뒤 실제 ONNX, TensorRT, PyTorch backend 모델을 호출할 수 있다.

Ensemble로 두 단계를 묶으면 client는 문자열만 보내면 된다.

성능

Tokenizer는 CPU 작업이므로 높은 QPS에서는 Python process와 CPU core 수가 병목이 될 수 있다. Batch tokenization을 사용하고 model inference batch와 잘 맞추는 것이 중요하다.

Versioning

Tokenizer vocabulary와 normalization rule은 model version과 묶어 관리해야 한다. 모델만 교체하고 tokenizer가 다르면 embedding 품질이 깨질 수 있다.

결론

client가 하나이고 throughput이 중요하면 client-side가 단순할 수 있다. 여러 client에 일관된 text API를 제공하려면 Triton 내부 preprocessing과 ensemble이 관리 측면에서 유리하다.