기업용 LLM 추론 게이트웨이 배포: 429 오류를 13%에서 0으로 줄였으며, 비용도 28% 절감했습니다.

지난달 블랙프라이데이 세일 기간 동안, 싱가포르에 있는 우리의 국제 전자상거래 기술 팀은 3명의 백엔드 개발자가 모니터링실에서 36시간 동안 근무했습니다. 그들은 요청 성공률의 그래프를 지켜보며 거의 환호할 뻔했습니다. 작년 같은 대규모 세일 기간에는 단일 LLM(대규모 언어 모델) 서비스 제공업체의 제한으로 인해 문제가 발생했었거든요.13%의 상품 설명 생성 요청이 직접 429 오류를 보고합니다.상점의 백엔드 시스템이 거의 4시간 동안 다운되었으며, 고객 불만만 2000건 이상 접수되었습니다.

먼저 이해해야 할 것은, 기업급 추론 게이트웨이가 도대체 무엇인지입니다.

그것은 뭔가 화려하거나 새로운 프레임워크가 아니며, 본질적으로는 여러분의 비즈니스 서비스와 다양한 LLM(대규모 언어 모델) 인터페이스 사이에서 트래픽을 조정하는 역할을 합니다. 핵심적인 파라미터들은 매우 간단합니다:정상적인 부하 하에서, 스케줄링 지연은 10ms를 초과해서는 안 됩니다., 초과하면 오히려 업무에 방해가 됩니다.

우리가 문제들을 해결한 후에 얻은 실질적인 이점 3가지를 요약해보겠습니다.

• 먼저, 부하 제한의 위험을 완전히 없앴습니다. 현재 우리는 3개의 주요 LLM(대규모 언어 모델) 서비스 제공업체와 동시에 연결되어 있으며, 게이트웨이는 자동으로 요청을 현재 할당량이 충분하고 응답 속도가 가장 빠른 노드로 분배합니다. 올해 블랙프라이데이 기간 동안의 QPS(초당 요청 수)는 작년보다 2.3배 증가했지만, 단 한 번도 대량의 429 오류가 발생하지 않았습니다.
• 둘째로, 비용이 눈에 띄게 줄었습니다. 우리는 저우선순위의 상품 태그 생성 요청을 자동으로 더 비용 효율적인 소형 모델로 라우팅시켰으며, 비즈니스 코드를 수정할 필요도 없었습니다. 7일 동안 토큰 사용 비용을 28%나 절약할 수 있었습니다.
• 마지막으로, 백엔드의 반복적인 작업 부담이 줄었습니다. 이전에는 모델을 교체하거나 새로운 서비스 제공자를 추가할 때마다 3개의 비즈니스 모듈 인터페이스를 일일이 수정해야 했지만, 이제는 게이트웨이 계층에서 모든 설정을 완료할 수 있어서 반나절 만에 처리가 끝납니다.

이점만 보지 말고, 우리는 이 3가지 문제점을 실제로 겪어봤습니다.

첫 출시 주에 이미 사고가 발생했습니다. 자동 패일백 기능을 활성화한 후, 게이트웨이가 GPT-4를 호출해야 했던 일부 고우선순위의 맞춤형 콘텐츠 요청들을 성능이 훨씬 낮은 작은 모델로 전환시켜버렸습니다. 그 결과 200개가 넘는 상업 광고 콘텐츠가 기준에 미달되었고, 결국 1만 원 가량의 홍보 쿠폰을 손해로 보았습니다. 나중에야 모든 요청이 자동으로 다운그레이드되어야 하는 것은 아니며, 민감한 상황에서는 반드시 추가적인 검증 규칙을 적용해야 한다는 것을 알게 되었습니다.

아직 많은 사람들이 언급하지 않은 비용 문제가 있습니다: 만약 QPS(초당 요청 수)가 장기간 10 미만으로 유지된다면, 게이트웨이 자체의 서버 비용과 유지보수 비용이 LLM(대규모 언어 모델) 서비스 제공업체의 고급 패키지 비용보다 더 많이 든다면, 굳이 그것을 사용할 필요가 없습니다.

또한 “전 기능이 바로 사용 가능하다”는 말을 믿지 마세요. 우리는 3개의 오픈소스 게이트웨이를 테스트해 봤는데, 기본적인 트래픽 분배 규칙이 전자상거래 시나리오에 전혀 맞지 않았습니다. 단지 가중치 규칙만 조정하는 데도 꼬박 이틀이 걸렸어요.

누가 나가야 할까? 누구는 시간을 낭비할 필요가 전혀 없어.

직접 판단 기준을 제시하세요, 고민하지 마세요:

• 다음 조건 중 하나라도 충족하면 고려할 수 있습니다: 매일 LLM(대형 언어 모델) 요청 횟수가 1만 회를 초과하거나, 2개 이상의 모델을 동시에 사용하거나, 서비스 가용성에 대한 요구 사항이 99.9% 이상인 경우;
• 만약 당신의 팀이 5명 미만의 소규모 스타트업이거나, 핵심 비즈니스와 대형 모델의 호출이 긴밀하게 연결되어 있지 않으며, 한 달간의 LLM(대규모 언어 모델) 사용 비용이 백엔드 엔지니어의 월급보다도 적다면, 기업 수준의 배포 시스템은 고려하지 마세요. 서비스 제공업체의 원본 인터페이스를 사용하는 것이 가장 경제적입니다.

처음 시작하는 분들을 위한 2가지 실용적인 조언

처음부터 모든 트래픽을 한 번에 전환하지 마세요. 먼저 저우선순위 트래픽의 10%를 사용하여 일주일 동안 그레이스케일 테스트를 진행하세요. 주로 두 가지 지표에 주목하세요: 요청이 중복으로 제출되는지, 스케줄링으로 인한 지연이 실제로 허용 가능한 범위 내에 있는지 확인하세요. 저희는 당시에도 애프터서비스 자동 응답 트래픽을 사용하여 3일 동안 테스트를 진행한 후에 문제가 없다고 확신한 후에야 핵심 비즈니스로 전환했습니다.

질문: 직접 처음부터 게이트웨이를 만들어야 할까요? 답변: 팀에 여유로운 전문가가 없는 한, 기성의 오픈소스 버전을 가져와서 수정하는 것이 더 좋습니다. 직접 만드는 것보다 적어도 2개월은 시간을 절약할 수 있으며, 안정성도 더 높습니다.