12. 100만 사용 AI 이루다 서비스
이루다 서비스
스캐터랩
<1> 서비스 성공 요인
<2> 도전
<3> 도전 대응 - GPU의 고비용 및 공급 부족?
<4> 도전 대응 - GPU연산에 많은 리소스가 필요함?
<5> 도전 대응 - 모델 연산에 필요한 I/O가 많음?
<1> 서비스 성공 요인
1
독점적인 대화 데이터 보유
데이터 - 라지랭귀지 모델은 모델의 크기, 데이터로 결정된다.
위키피디아 5배 크기 데이터를 가짐
2
재미있고 개성 있는 대화에 대한 기회 노하우
3
안전한 AI프로덕션 윤영 경험
<2> 도전
1
GPU의 고비용 및 공급 부족
2
GPU연산에 많은 리소스가 필요함
3
모델 연산에 필요한 I/O가 많음.
<3> 도전 대응 - GPU의 고비용 및 공급 부족?
1
EKS에 1000 TPS 요청, 1500ms 내 처리하도록 구성
2
HPA의 메트릭 RPS설정 - GPU 사용 최적화
3
모델 서버는 Spot 사용
4
inf1 instance , inf2 instance 사용
AWS에서 제공하는 저렴한 EC2 인스턴스
https://aws.amazon.com/ko/ec2/instance-types/inf2/
5
최근 GPU공급 부족으로 온디멘드로도 할당이 잘 안 됨(앞으로도 지속 예정)
다양한 GPU 인스턴스 타입을 사용함으로 문제에 대비함.
6
멀티 AZ , 멀티 리즌 사용으로 A100 부족 대응.
7
RI(할인) 사용.
RI는 비용 절감이지 장비 확보는 아니다.
ODCR(On-Demand Capacity Reserve) 필요하다. - 장비 확보하는 것이다. AWS와 확인하라.
<4> 도전 대응 - GPU연산에 많은 리소스가 필요함?
1
이루다의 경우, 딥러닝 모델은 사이즈가 커서 하나의 GPU에 하나의 모델밖에 올라가지 않음.
Pod와 node가 1:1 매칭됨.
트래픽 변화에 전체 인프라가 크게 영향을 받음.
Cluster Autoscaler보다 Node Provsioning 속도가 빠른 카펜터 적용.
Cluster Autoscaler는 반응 속도가 느림.
카펜터 사용
2
많은 트래픽이 예상될 때는 스케일을 키워 놓을 수 있는 PreSacler를 개발하여 미리 스케일을 키워 놓음.
<5> 도전 대응 - 모델 연산에 필요한 I/O가 많음?
1
모델 입력으로 프롬프트를 구성하는데 많은 정보가 필요함.
최근 다큐멘트 디비로 관리하던 정보를 더 많은 사용량에 대비하기 위해 다이나모 디비로 이전하고 있음.
DB 선택 링크
다큐멘트 디비에 쓰기가 많아 사양을 높여서 사용. 최대 제약이 있어 더 이상 증가 불가.
다이나모 디비는 여러 파티션에 분산된 SSD를 사용, 해쉬 함수를 사용해 어디에 저장되어 있는지 찾음.
1 자릿수 ms 내 응답, 잦은 오토스케일링에 대응됨.
2
AI서비스는 자체 데이터 확보가 핵심.
AWS에서 Amazon Bedrock을 활용하여 개선 가능.
<6> 개인 정리
HPA의 메트릭 RPS설정 - GPU 사용 최적화
모델 서버는 Spot 사용
inf1 instance , inf2 instance 사용
ODCR(On-Demand Capacity Reserve) 필요하다. - 장비 확보하는 것이다. AWS와 확인하라.
카펜터 사용
많은 트래픽이 예상될 때는 스케일을 키워 놓을 수 있는 PreSacler를 개발하여 미리 스케일을 키워 놓음.
쓰기가 계속 증가하는 서비스는 다이나모 디비 사용하라. 다큐멘트 디비는 한계가 있다.
AWS에서 Amazon Bedrock을 활용하여 데이터 확보 부분 개선 가능.
다음자료
https://brunch.co.kr/@topasvga/3369
모아보기
https://brunch.co.kr/@topasvga/3380
감사합니다.
