예산을 초과하지 않고 LLM을 사용하는 방법
AI 데모를 만드는 것은 쉽습니다. API 키를 받고, 프롬프트를 작성하면 바로 작동하죠.
하지만 실제 사용자에게 배포하는 것은 다릅니다. 트래픽이 몰리면 비용이 급증하고, 지연 시간(latency)이 늘어납니다. 재무팀에서 질문을 던지기 시작할 것입니다.
데모와 실제 제품 사이의 간극은 바로 엔지니어링입니다. 비용과 속도를 관리해야 합니다.
비용 절감을 위해 출력을 제어하세요
대부분의 API는 토큰 단위로 요금을 부과합니다. 사용자가 보내는 내용과 API가 응답하는 내용 모두에 대해 비용이 발생합니다. 출력 토큰은 입력 토큰보다 비용이 더 많이 듭니다.
단순히 프롬프트를 줄이는 데 그치지 마세요. 답변에 집중하세요. • JSON 형식으로 요청하세요. • 한 문장으로 요청하세요. • 최대 토큰 제한을 설정하세요. • 모델에게 간결하게 답변하도록 지시하세요.
짧은 답변이 더 저렴하고 빠릅니다.
호출 횟수를 줄이세요
가장 저렴한 호출은 아예 하지 않는 호출입니다.
- 캐싱을 사용하세요. 많은 사용자가 동일한 질문을 합니다. 캐싱을 사용하면 느린 API 호출을 빠른 조회(lookup)로 바꿀 수 있습니다.
- 라우터를 사용하세요. 모든 작업에 거대한 모델이 필요하지는 않습니다. 쉬운 작업에는 작고 저렴한 모델을 사용하고, 어려운 작업에만 비싼 모델을 사용하세요.
사용자 경험을 개선하세요
때로는 모델 자체를 더 빠르게 만들 수 없을 수도 있습니다. 하지만 더 빠르게 '느껴지게' 만들 수는 있습니다.
- 응답을 스트리밍하세요. 텍스트가 생성되는 대로 보여주세요. 사용자는 즉시 읽기 시작할 수 있으며, 이는 대기 시간을 더 짧게 느끼게 합니다.
- 진행 상황을 보여주세요. 작업이 여러 단계를 거친다면 사용자에게 알려주세요. 빈 로딩 스피너 대신 "문서 검색 중..."과 같은 메시지를 사용하세요.
느린 요청을 관리하세요
몇 개의 매우 느린 요청이 제품을 망칠 수 있습니다. 요청이 무한정 대기하게 두지 마세요.
- 엄격한 타임아웃을 설정하세요. 요청이 너무 오래 걸릴 경우 어떻게 처리할지 결정해야 합니다.
- 제한된 재시도(retry)를 사용하세요. 무한히 재시도하지 마세요.
- 서킷 브레이커(circuit breaker)를 사용하세요. 제공업체에 문제가 생기면 요청 전송을 중단하고 폴백(fallback)을 보여주세요.
데이터를 추적하세요
측정하지 않으면 개선할 수 없습니다. 모든 요청에 대해 다음 세 가지를 기록하세요: • 입력 토큰 • 출력 토큰 • 총 지연 시간(latency)
기능별로 추적하세요. 아마도 비용의 대부분을 차지하는 특정 기능이 하나쯤은 있을 것입니다.
모델을 마법처럼 대하지 마세요. 관리해야 할 느리고 비싼 의존성(dependency)으로 취급하세요.