저도 작년에 같은 고민했는데 결국 라마2로 gptq 양자화해서 썼거든요. 비용 대비 효과 좋더라고요.
API연동
최근에 LLM fine-tuning 해보신 분 계신가요?
회사 프로젝트에서 GPT 기반 챗봇을 만들고 있는데, 그냥 프롬프트 엔지니어링만으로는 한계가 있더라고요. 그래서 우리 도메인 데이터로 fine-tuning을 해야 하나 고민 중입니다.
근데 요새 비용이 장난 아닌 것 같아요. 사내 리소스도 부족하고, 오픈소스 모델(라마, 미스트럴 등)을 쓰는 게 낫지 않을까 싶기도 하고요. 다들 어떻게 하시나요? 실무에서 경험해보신 분 있으면 팁 좀 나눠주세요.
근데 요새 비용이 장난 아닌 것 같아요. 사내 리소스도 부족하고, 오픈소스 모델(라마, 미스트럴 등)을 쓰는 게 낫지 않을까 싶기도 하고요. 다들 어떻게 하시나요? 실무에서 경험해보신 분 있으면 팁 좀 나눠주세요.
추천 14 비추천 0
- 이전글최근에 LLM 토큰 길이 제한 때문에 골치 아프신 분 있나요?26.03.22
- 다음글LLM 파인튜닝 비용 때문에 고민인데 실무에서 어떻게 하세요?26.03.20
댓글
11
댓글목록
완전 공감이에요 ㅠㅠ
저도 비슷한 상황이었는데 결국 오픈소스 모델로 가는 게 맞더라고요. 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했어요. 초기 비용은 좀 들었지만 장기적으로는 훨씬 싸더라고요. 다만 프롬프트 엔지니어링보다는 데이터 품질이 훨씬 중요하다는 걸 배웠습니다. 데이터 전처리에 시간을 많이 투자해야 성과가 나옵니다.
저도 비슷한 고민을 했었는데, 결국 오픈소스 모델로 가는 게 맞더라고요. GPT fine-tuning은 비용도 비용인데 학습 과정이 블랙박스라 실제 개선 효과를 측정하기도 애매했어요.
라마 2나 미스트럴을 사내 서버에서 돌리면 비용이 훨씬 싸고, 모델 구조도 투명해서 디버깅이 쉬워요. 다만 도메인 특화 데이터가 충분해야 하고, 메모리 리소스는 좀 먹습니다.
프롬프트 엔지니어링 한계를 느끼신다면 RAG(Retrieval-Augmented Generation) 먼저 시도해보는 것도 좋은데, fine-tuning보다 구현이 간단하고 효과도 빠르게 볼 수 있어요. 데이터
라마 2나 미스트럴을 사내 서버에서 돌리면 비용이 훨씬 싸고, 모델 구조도 투명해서 디버깅이 쉬워요. 다만 도메인 특화 데이터가 충분해야 하고, 메모리 리소스는 좀 먹습니다.
프롬프트 엔지니어링 한계를 느끼신다면 RAG(Retrieval-Augmented Generation) 먼저 시도해보는 것도 좋은데, fine-tuning보다 구현이 간단하고 효과도 빠르게 볼 수 있어요. 데이터
댓글을 작성하려면 로그인이 필요합니다.