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