저도 작년에 같은 고민했는데 결국 라마2로 gptq 양자화해서 썼거든요. 비용 대비 효과 좋더라고요.
API연동
최근에 LLM fine-tuning 해보신 분 계신가요?
회사 프로젝트에서 GPT 기반 챗봇을 만들고 있는데, 그냥 프롬프트 엔지니어링만으로는 한계가 있더라고요. 그래서 우리 도메인 데이터로 fine-tuning을 해야 하나 고민 중입니다.
근데 요새 비용이 장난 아닌 것 같아요. 사내 리소스도 부족하고, 오픈소스 모델(라마, 미스트럴 등)을 쓰는 게 낫지 않을까 싶기도 하고요. 다들 어떻게 하시나요? 실무에서 경험해보신 분 있으면 팁 좀 나눠주세요.
근데 요새 비용이 장난 아닌 것 같아요. 사내 리소스도 부족하고, 오픈소스 모델(라마, 미스트럴 등)을 쓰는 게 낫지 않을까 싶기도 하고요. 다들 어떻게 하시나요? 실무에서 경험해보신 분 있으면 팁 좀 나눠주세요.
추천 14 비추천 0
- 이전글LLM 파인튜닝 vs RAG, 실제로는 어느 쪽이 낫나요?26.03.28
- 다음글RAG 시스템에서 context window 크기 늘렸더니 성능이 떨어졌어요26.03.20
댓글
10
댓글목록
완전 공감이에요 ㅠㅠ
저도 비슷한 상황이었는데 결국 오픈소스 모델로 가는 게 맞더라고요. GPT fine-tuning은 비용도 비용인데 학습 데이터 준비하고 평가까지 다 고려하면 ROI가 안 맞았어요.
대신 라마2나 미스트럴을 QLoRA로 가볍게 튜닝한 후 온프레미스에서 돌리니까 비용도 훨씬 싸고, 모델도 자유도가 높더라고요. 다만 성능이 GPT보다는 떨어지긴 하는데, 도메인 데이터가 충분하면 오히려 더 좋은 결과가 나올 수도 있습니다.
혹시 학습 데이터가 얼마나 되시나요? 만약 5000개 미만이면 프롬프트 엔지니어링에 RAG를 추가하는 것도 고려
대신 라마2나 미스트럴을 QLoRA로 가볍게 튜닝한 후 온프레미스에서 돌리니까 비용도 훨씬 싸고, 모델도 자유도가 높더라고요. 다만 성능이 GPT보다는 떨어지긴 하는데, 도메인 데이터가 충분하면 오히려 더 좋은 결과가 나올 수도 있습니다.
혹시 학습 데이터가 얼마나 되시나요? 만약 5000개 미만이면 프롬프트 엔지니어링에 RAG를 추가하는 것도 고려
저도 비슷한 상황이었는데, 결국 오픈소스 모델로 가는 게 맞더라고요. GPT fine-tuning은 비용도 비용인데 결과물 소유권 문제도 있고, 업데이트할 때마다 또 돈이 들어가거든요.
라마 2나 미스트럴이면 충분하다 싶으면 LoRA로 가볍게 파인튜닝 하고, 온프레미스에서 돌리는 게 장기적으로 훨씬 경제적입니다. 초기 투자는 더 들지만 월 비용이 거의 없어서요.
다만 도메인 데이터 품질이 정말 중요한데, 요즘 비용 압박이 있으시니까 좀 지저분해도 일단 모아서 파인튜닝부터 해보고 성능을 보는 게 낫습니다.
라마 2나 미스트럴이면 충분하다 싶으면 LoRA로 가볍게 파인튜닝 하고, 온프레미스에서 돌리는 게 장기적으로 훨씬 경제적입니다. 초기 투자는 더 들지만 월 비용이 거의 없어서요.
다만 도메인 데이터 품질이 정말 중요한데, 요즘 비용 압박이 있으시니까 좀 지저분해도 일단 모아서 파인튜닝부터 해보고 성능을 보는 게 낫습니다.
저도 요즘 같은 고민 중이에요 ㅠㅠ
저도 비슷한 상황이었는데, 결국 라마2 13B를 로컬에서 fine-tuning했어요. OpenAI API 비용이 정말 장난 아니더라고요 ㅠㅠ LoRA 써서 학습 리소스도 줄였는데, 결과는 프롬프트 엔지니어링만 할 때보다 훨씬 낫더라고요. 데이터셋이 충분하면 오픈소스가 정답인 것 같습니다.
저도 지금 한창 고민 중이에요 ㅠㅠ
저도 요즘 같은 고민 중이더라고요. 프롬프트만으로는 일관성 있는 답변이 안 나오니까요. 근데 OpenAI의 fine-tuning 비용이 정말 비싼 편이라 저희는 일단 라마2 로컬 호스팅으로 시작했어요. GPU 비용은 들지만 장기적으로는 훨씬 경제적더라고요.
다만 프롬프트 엔지니어링을 최대한 끝내고 시작하는 게 좋습니다. few-shot 예제를 50개 정도 잘 구성해서 프롬프트만으로도 꽤 많이 개선되거든요. 그 다음에 정말 필요할 때만 fine-tuning 들어가는 게 비용 효율적일 것 같습니다.
혹시 LoRA(Low-Rank Adaptation) 방식은 살펴보셨나요?
다만 프롬프트 엔지니어링을 최대한 끝내고 시작하는 게 좋습니다. few-shot 예제를 50개 정도 잘 구성해서 프롬프트만으로도 꽤 많이 개선되거든요. 그 다음에 정말 필요할 때만 fine-tuning 들어가는 게 비용 효율적일 것 같습니다.
혹시 LoRA(Low-Rank Adaptation) 방식은 살펴보셨나요?
저도 요즘 같은 고민 중이었어요. 결론부터 말하면 오픈소스 모델이 맞는 것 같더라고요. 라마 2나 미스트럴로 LoRA fine-tuning 해봤는데 비용이 정말 차이 나요. 프롬프트 엔지니어링으로 어느 정도까지 가다가 성능이 안 나오면, 그때 fine-tuning을 하는 게 맞는 것 같습니다.
특히 도메인 특화 데이터가 있으면 오픈소스 모델이 더 효과적이더라고요. 우리는 Hugging Face에서 파인튜닝 파이프라인을 직접 구축해서 썼는데, 초기 세팅만 하면 계속 재사용할 수 있어서 괜찮았습니다. 양도 많지 않으면 QLoRA로 충분할 거예요.
GPT API
특히 도메인 특화 데이터가 있으면 오픈소스 모델이 더 효과적이더라고요. 우리는 Hugging Face에서 파인튜닝 파이프라인을 직접 구축해서 썼는데, 초기 세팅만 하면 계속 재사용할 수 있어서 괜찮았습니다. 양도 많지 않으면 QLoRA로 충분할 거예요.
GPT API
같은 상황이었는데 결국 라마2 7B를 로컬에서 LoRA로 fine-tuning했어요. 초기 비용은 좀 들었지만 장기적으로는 훨씬 싸더라고요. 다만 프롬프트 엔지니어링보다는 데이터 품질이 훨씬 중요하다는 걸 배웠습니다. 데이터 전처리에 시간을 많이 투자해야 성과가 나옵니다.
댓글을 작성하려면 로그인이 필요합니다.