vLLM 파라미터 튜닝을 통한 성능 개선

[SuwonPabby]

개요

vLLM에서 제공하는 파라미터를 튜닝하여 성능 개선
0.1초마다 40개 요청을 날려보는 Test로 수행

변경한 파라미터

• enable_prefix_caching
• chunked_prefill
• tokenizer_pooling

1. Enable_prefix_caching

• 기존에 입력했던 프롬프트의 kv 를 캐싱해두는 전략
• 우리 프로덕트의 시나리오의 경우 유저 프롬프트 전 들어가는 부분에 겹치는 Prompt가 매우 많고, 대화형이므로 이전 대화 내역 데이터가 들어가기도 함
• 따라서 이것을 활성화할 시 큰 성능 향상을 기대할 수 있음
• 그리고 무엇보다 기존 방법에서 우리 방법의 가장 큰 병목은 Prefill 부분이었음

성능 변화 확인

• 기존: TTFT가 2개 요청 씩 약 2초가 소요되며 Prefill 되었음 (뒷 요청은 점점 ttft가 크게 늘어남), TPS는 195 정도
• 적용 후: TTFT가 모든 요청이 거의 0.1초 급으로 통일 (뒷 요청의 병목이 완전히 사라진 것이 엄청난 성능 향상을 가능케함)
• 적용 후: TTFRT가 모든 요청이 유효 범위 이내 (25초 이내, 보통 17초대)로 들어옴
• 적용 후: TPS가 300초반까지 올라가는 성능 향상을 보였다.

물론 테스트케이스를 전부 동일 프롬프트로 처리하였기 때문에 성능이 크게 향상한 것이긴 하지만 (캐시 히트 레이트가 99.7% - 그런데 0.3% 히트가 안된 건 무엇인지 모르겠음) 우리 시나리오의 경우 Prefix 프롬프트가 거의 겹치기 때문에 실제 환경에서도 큰 성능 향상이 있을 것이라고 생각할 수 있다.

2. chunked_prefill

• vLLM은 기본적으로 prefill phase와 decoding phase로 나누어져있다.
• decoding phase보다 prefill phase의 우선순위가 보통 평균적으로 높다.
• 그런데 그렇게 되면 요청이 갑자기 몰렸을 때 Prefill phase에 연산이 집중되어, decoding 처리되던 연산의 속도가 느려지는 문제가 생긴다 (우선순위가 밀리는 문제)
• 이를 해결하기 위해 chunked_fill을 이용하면 prefill phase의 연산을 Chunking하여 decoding phase로 넘겨주게 된다.
• 이러면 ttft는 조금 늘어나지만 decoding phase에 있는 시퀸스의 우선순위를 지켜주게 된다.

성능 변화 확인

• 위의 enable_prefix_caching을 껐을 때 ttft 지표 확인

• 기존 2초씩 2개 요청씩 처리되던 페이즈와 달리 선형적으로 처리가 되고 있다.

• 기존에 prefill 용 slot을 2개 확보해서 처리하던 형태가 아니라, 큐에 들어오면 이걸 chunking하여 decoding phase에 뿌려주는 형태가 됬기에 이런 결과가 나오는 것이라고 생각됨

• caching 적용된 상태에서는

• ttft 첫 요청 값이 0.5 ~ 1초 정도 사이를 요동치는데 (0.1초에 비해서는 증가) 모든 토큰이 다 나오는데 걸리는 시간은 chunked_fill을 활성화 하나, 안하나 똑같음
• 이는 평균적인 tpot 값이 줄어, ttft의 손실을 메꾸는 작용이 일어나는 것으로 해석됨

적용 여부 판단 과정

1. Caching을 통해 어느정도 TTFT를 크게 줄일 수 있고 (중복되는 양이 많고, 사용자가 입력하는 부분만 달라짐, 말투에 따라서도 달라짐 -> 그러나 이거는 동적이지는 않음)

2. chunked_prefill를 해도 성능상 큰 이슈가 발생하지 않으며

3. 오히려 Prefill 부분이 병목이 발생했을 때 Decoding 단이 그래도 계속 진행될 수 있게 Decoding 단으로 Chunking 해서 추론이 이루어지므로 좀 더 안정적일 것이라고 생각

4. 물론 GPU 용량이 더 충분해서 Prefill 할 공간이 충분해서 이 파라미터로 인해 TTFT 손실이 커질 경우 False로 바꿀 필요성은 있어보이나

일단 현재로서는 Prefill 요청이 발생하더라도 진행하던 요청을 안정적으로 내보내는 것이 더 중요하다고 생각

(특히 caching이 잘 먹히는 상황이기 때문에 cache가 안된 일부 부분만 처리하면 된다는 측면에서 prefill이 우선순위를 더 먼저 가져갈 필요는 없음, 그러나 모니터링하면서 예의 주시해야 할듯)

-> 이에 따라 적용하는 것으로 결정

3. tokenizer_pooling

• tokenizer의 처리 과정을 비동기적으로 처리하여 성능 향상을 기대할 수 있음
• 하지만 비동기 처리를 적용하는 과정에서 오버헤드가 발생할 수 있다.

성능 변화 확인

• 체감되는 성능 변화는 없었다.
• 아무래도 비동기 처리의 이점이 이로인한 오버헤드로 인해 상충된 것으로 보임
• 하지만 향후 Scale up을 하거나 모델을 Quantize하여 더 많은 throughput을 처리할 수 있는 모델로 변경된다면 이 설정을 켜놓는 것이 이점을 줄 수 있을 것이라고 판단
• 비동기 처리 변경으로 인한 오버헤드도 크지 않음
• 따라서 적용하기로 함