이번에 카카오베이스에서 채팅기능을 구현하는데, 아무리 생각해도 응답속도가 너무 느릴것같아서 고민이었다...
Background (현재 모델 서빙 구조)
게다가 지금 현재 구조가
base llm + lora1(유튜브 요약)
+ lora2(소셜봇) 위와 같은 multi adapter라서..
Problem definition
만약에 유튜브영상 2시간짜리 넣으면, 해당 inference가 진행되는동안 채팅기능이 마비될 것으로 예상된다... ㅠ
Study
그래서 같은 카카오베이스팀에서 BE를 맡고 계신 rick.lee랑, 카카오테크 부트캠프 ai과정을 같이 듣고계신 simon.lee한테 많이 여쭤봐서 해당 내용을 기록한다.
20250712 밤 - rick
spring boot자체에는 이벤트 루프가 없다. fastapi는 자동으로 지원해주는것 같다.
이벤트 루프는 round queue같은건데, 들어오는 순서대로 일을 처리해준다.
20250713 낮 - simon
fastapi에 있는 이벤트 루프 == python 자체에 있는 이벤트 루프
fastapi
|
uvicorn
|
이벤트루프요런느낌이랬음. 그래서 각 요청(a,b,c)마다 3초씩 걸린다고 가정했을때,
[잘못 생각한 시나리오]
a요청 : 0~3초에 생성 및 응답 / 이벤트 루프 [b요청, c요청]
b요청 : 3~6초에 생성 및 응답 / 이벤트 루프 [c요청]
c요청 : 6~9초에 생성 및 응답 / 이벤트 루프 []
[실제 돌아가는 방법]
a 요청 : 0~3초에 생성하고, 응답을 이벤트루프에 넣기 / 이벤트 루프 [b요청, c요청, a응답]
b요청 : 3~6초에 생성하고, 응답을 이벤트루프에 넣기 / 이벤트 루프 [c요청, a응답, b응답]
c요청 : 6~9초에 생성하고, 응답을 이벤트루프에 넣기 / 이벤트 루프 [a응답, b응답, c응답]
9초쯤에 abc응답을 우다다 반환
그리고 fastapi에서 uvicorn의 worker를 n개로 설정하면 이벤트루프가 n개 생성되고 각각의 이벤트 루프위에 uvicorn과 fastapi가 있는거
Conclusion
결론 : uvicorn의 worker 수를 늘려야한다.
Limitation
그럼에도 불구하고 문제점이 있다.
우리 ai 서버는 현재 다음과 같은 구조로 되어있음.
- Hugging Face에 model정보 가져오기(lora도 가져오기)
- 모델을 vllm으로 띄우기 (따로 server 안띄우고 GCP 내부에서 실행)
결국 모델을 worker수인 n개만큼 띄우게 되는건데, OOM(메모리 부족 현상)이 발생할 가능성이 높아보임.
Future work
oom이 발생하지 않는 적정선의 worker수인 n을 찾아야한다.
