최근에 특정 도메인용 LLM 파인튜닝을 시작했는데 자꾸만 토큰 길이 제한에 걸려서 답답하네요. 기본 모델이 4K 토큰까지만 지원해서 실제 업무 데이터는 보통 그 이상이거든요.
컨텍스트 윈도우를 늘리려고 알아보니 여러 방법들이 있던데 뭐가 가장 현실적인지 헷갈려요. RoPE(Rotary Position Embedding) 외삽을 쓰면 메모리 오버헤드가 꽤 크다고 들었고, 슬라이딩 윈도우 방식도 정보 손실 위험이 있다고 하더라고요. 그냥 처음부터 더 큰 윈도우 지원하는 모델을 기반으로 파인튜닝하는 게 답일까요?
다른 분들은 이런 상황에서 어떻게 해결하셨어요? 혹은 토큰 길이를 줄이는 전처리 방식으로 잘 해결하신 케이스도 있으면 듣고 싶습니다. 지금은 임시방편으로 긴 문서를 청킹해서 여러 번 돌리고 있는데 이건 너무 비효율적이고 일관성 문제도 생기더라고요.
혹시 양자화나 증류 같은 방식을 먼저 적용하고 파인튜닝하면 상황이 나아질까요? 아니면 그렇게 하면 오히려 성능 저하만 늘어날까요? 비용과 성능의 밸런스를 맞추는 게 정말 어렵네요.
저도 비슷한 문제 겪었는데 결국 더 큰 윈도우 지원하는 모델로 갈아탔어요. Llama 2 70B 기반으로 시작하니 4K 제약이 없더라고요. 양자화나 증류는 오히려 성능 저하가 심했습니다. 청킹은 정말 일관성 문제가 크니까 피하시는 게 낫습니다. RoPE 외삽은 실제 써보면 메모리 오버헤드보다 성능 감소가 더 크다는 느낌이에요. 초기 모델 선택이 가장 중요한 것 같습니다.
흐름타는개발자
저도 비슷한 문제 겪었는데 결국 더 큰 윈도우 모델로 갈아탔어요. RoPE 외삽은 메모리도 메모리지만 품질 저하가 생각보다 크더라고요.
요즘 Llama 2 같은 모델들이 이미 4K 이상 지원하니까 처음부터 큰 모델 쓰는 게 시간상 낫습니다. 양자화는 나중에 배포할 때 하고 파인튜닝 전에는 피하세요. 정보 손실 뒤에 또 손실이 생기거든요.
청킹은 정말 비효율적이죠. 청크 경계에서 중요한 정보 놓치기도 하고 일관성 문제는 말하셨다시피 심각합니다. 예산이 괜찮으면 LLaMA-2-70B 같은 모델로 시작하는