Mistral Large vs Mistral Medium: 프로덕션 운영 중 얻은 CTO의 노트
3개월 전, 저는 LLM 기능을 출시했습니다. 그러고 나서 청구서가 날아왔습니다.
실수를 했다는 것을 깨달았습니다. Mistral Medium을 사용했어야 할 자리에 Mistral Large를 사용한 것이었습니다. 이로 인해 필요 이상으로 거의 4배나 더 많은 비용이 발생했습니다.
스타트업을 운영한다면, 단순히 느낌(vibes)에 의존해 아키텍처를 결정해서는 안 됩니다. 반드시 ROI를 기반으로 결정해야 합니다.
실수는 단순했습니다. 저는 더 큰 모델이 항상 더 좋을 것이라고 생각했습니다. 제 생각이 틀렸습니다.
현재 제가 LLM 비용을 관리하는 방법은 다음과 같습니다:
- 작업 복잡도 분류
- 단순 분류나 추출 작업에는 더 작은 모델을 사용합니다.
- 다단계 추론(multi-step reasoning)이 필요한 경우에만 더 큰 모델을 사용합니다.
- 토큰 사용량 추정
- 로그를 확인합니다.
- 성장세를 예측합니다.
- 배포하기 전에 미리 계산해 봅니다.
- 실제 평가(evals)로 측정
- 직감을 믿지 마세요.
- 두 모델 모두에 테스트 세트를 실행합니다.
- 제품에 중요한 지표들을 비교합니다.
제 작업의 70%는 Mistral Medium으로도 충분합니다. 고객 지원 티켓 분류 작업을 완벽하게 처리합니다. 비용은 Large의 3분의 1 수준입니다. Large는 고차원적인 추론 작업용으로 남겨둡니다.
또한 특정 벤더에 종속되는 것(vendor lock-in)을 방지합니다. 저는 여러 모델에 접속할 수 있는 통합 엔드포인트를 사용합니다. 한 제공업체가 가격을 올리면 몇 분 만에 모델을 교체할 수 있습니다. 이는 회사의 런웨이(runway)를 보호해 줍니다.
CTO를 위한 조언:
- 비용 절감을 위해 공격적으로 캐싱을 활용하세요.
- 사용자 경험을 개선하기 위해 응답을 스트리밍하세요.
- 시스템이 중단되지 않도록 폴백(fallback) 로직을 구축하세요.
- 프롬프트를 최적화하기 전에 모델을 먼저 선택하세요.
- 모든 작업에 대해 컨텍스트 윈도우(context window) 요구 사항을 확인하세요.
작은 망치가 필요한 작업에 대형 해머를 사용하지 마세요. 효율성이 경쟁 우위를 만듭니다. 효율성을 통해 사용자에게 더 나은 기능과 더 낮은 가격을 제공할 수 있습니다.
출처: https://dev.to/gentlenode/mistral-large-vs-mistral-medium-cto-notes-from-production-280f