Abstract:
- 이 논문은 대형 언어 모델(LLMs)의 전체적인 응답 생성 시간을 줄이기 위한 새로운 방법을 제안하고 있음.
- 현재 대부분의 최첨단 LLM들은 단어를 하나씩 순차적으로 생성하는 방식(순차적 디코딩)을 사용하고 있는데, 이 방식은 응답 생성에 시간이 많이 걸리는 주요 원인 중 하나임.
- 여기서 제안하는 Skeleton-of-Thought(SoT) 방법은 인간의 사고와 글쓰기 방식을 본떠 제안된 방법임. 인간은 글을 쓸 때 먼저 전체적인 구조나 뼈대를 잡은 후, 각 부분의 내용을 채워나가는 식으로 글을 작성함. 마찬가지로 SoT 도 다음과 같은 두 단계로 이뤄짐:
- 뼈대 생성: LLM이 먼저 응답의 전체적인 구조나 주요 포인트를 생성함.
- 내용 채우기: 생성된 각 뼈대 포인트에 대해 병렬 API 호출이나 배치 디코딩을 사용하여 동시에 상세한 내용을 완성함.
- SoT 의 장점은 다음과 같다:
- 속도 개선: 12개의 LLM을 대상으로 한 실험에서 SoT는 응답 생성 시간을 상당히 단축시켰다고 함.
- 품질 개선: 몇몇 유형의 질문에서는 SoT를 사용함으로써 응답의 품질이 향상되는 잠재력도 발견되었다고 함.
Introduction:
- LLM 의 대표적인 문제점은 느린 추론 속도이다. 추론 과정이 느려서 실시간 상호작용에 제약이 있음.
- 느린 추론의 이유:
- 모델 크기: 거대한 모델 크기는 많은 메모리와 계산 자원을 필요로 함. 예를 들어, GPT-3의 FP16 가중치는 350GB의 메모리를 차지하여 최소한 5개의 80GB A100 GPU가 필요함.
- 어텐션 연산의 복잡성: Transformer 아키텍처에서의 어텐션 연산은 시퀀스 길이에 따라 메모리와 계산 복잡도가 제곱으로 증가하며, I/O 병목 현상을 일으킴.
- 순차적 디코딩 방식: 현재의 추론 방식은 토큰을 하나씩 순차적으로 생성하기 때문에, 토큰 생성이 병렬화되지 않아 지연 시간이 크게 증가하는 문제점이 있음.
- 이전 연구들은 주로 모델 크기와 어텐션 연산의 효율성을 개선하기 위해 모델을 압축하거나 재설계하고, 시스템이나 하드웨어를 개선하는 데 초점을 맞춤.
- 그러나 이 논문에서는 세 번째 원인인 순차적 디코딩 방식에 주목하여, LLM들이 반드시 완전히 순차적으로 디코딩해야 하는가에 대한 의문을 제기함.
- 모델, 시스템, 하드웨어의 변경 없이도 기존 LLM에서 병렬 디코딩이 가능함을 보여주며, 이를 통해 추론 속도를 크게 향상시킬 수 있음을 입증했다:
- LLM 의 추론 속도가 나오지 않는 이유가 가중치 로딩이 주요 병목 원인으로 지목함. (활성화 로딩이나 계산이 병목이 아니라고 함)
- 가중치 로딩은 모델의 가중치를 메모리에서 불러오는 작업을 말함. 아무래도 가중치가 엄청나게 많은 메모리를 차지하니까 발생한 문제.
- 활성화 로딩은 모델의 중간 계산 결과로, 주어진 입력이 각 레이어를 통과할 때 발생하는 출력을 불러오는 걸 말함. 활성화 값은 레이어를 통과할 때마다 나오는 출력을 뜻하고, 활성화 로딩은 모델이 다음 레이어의 계산을 위해 이 활성화 값을 불러오는 과정을 말함. 활성화 로딩이 병목이 아닌 이유는 활성화가 상대적으로 가벼운 데이터이기 때문임.
- 계산이 병목이 아닌 이유는, 현대의 고성능 GPU나 TPU가 이러한 수학적 계산을 매우 빠르게 수행할 수 있도록 최적화되어 있어서 그렇다고 함.
- 예를 들어, Claude 모델에서는 응답 시간이 22초에서 12초로, Vicuna-33B V1.3 모델에서는 43초에서 16초로 감소했음.
- Skeleton-of-Thought (SoT) 방법 제안:
- 사람들은 답변을 작성할 때 항상 순차적으로 생각하지 않고, 먼저 전체적인 골격을 잡은 후 각 부분의 세부 내용을 추가하는 방식을 이용.
- SoT는 다음과 같은 두 단계로 구성:
- 골격 생성: LLM이 먼저 답변의 주요 포인트나 구조를 생성
- 세부 내용 완성: 생성된 골격의 각 부분에 대해 동시에 세부 내용을 채워나간다. 여기서 병렬 처리가 가능해져 전체적인 응답 시간을 단축시킬 수 있음.
- SoT의 적용 범위와 확장:
- SoT는 구조를 미리 계획할 수 있는 긴 답변이 필요한 질문에 적합하지만, 단계별 추론이 필요한 문제나 짧은 답변에는 적합하지 않을 수 있음. 이를 보완하기 위해서 SoT-R(SoT with Router) 라는 걸 제안함. 적절한 질문에만 SoT 라우터를 사용하도록 하는 것.
- 12개의 최신 LLM을 대상으로 한 실험에서 SoT는 최대 2.39배의 속도 향상을 보였다고 함.
SKELETON-OF-THOUGHT (SOT):
- SoT가 사용자 질문 q에 대한 최종 답변을 생성하는 과정은 다음과 같음:
- (1) Skeleton 단계:
- Skeleton 요청 생성: SoT는 먼저 질문 q를 파라미터로 하여 Skeleton 프롬프트 템플릿 T_s 을 사용해 Skeleton 요청 T_s(question = q) 을 구성함.
- 이 프롬프트는 LLM이 답변의 간결한 골격을 출력하도록 설계되었음.
- LLM이 생성한 Skeleton 응답 R_s에서 B개의 주요 골격 포인트를 생성함.
- (2) 포인트 확장 단계:
- 추출된 각 포인트에 대해, 인덱스 b와 해당 골격 R_s^b를 사용하여 LLM에 포인트 확장 요청을 보낸다. 이때 포인트 확장 프롬프트 템플릿 T_{pe} 을 사용하여 요청을 구성함.
- 각 포인트에 대한 확장 응답을 모두 완료해서 연결하면 최종 응답이 만들어진다.
- 여기서 병렬 포인트 확장을 이용해서 병렬 처리를 하면 됨.
- 논문에서는 로컬에서 실행 가능한 오픈 소스 모델의 경우 배치 처리가 크게 추론 속도에 영향을 주지 않을 수 있다고 함. 배치 처리를 하면 여러 요청을 동시에 처리할 수 있지만, LLM의 디코딩 단계에서는 여전히 각 배치 내의 요청에 대해 토큰을 하나씩 순차적으로 생성하고 있기 때문. 그리고 가중치 로딩도 병목으로 발생할 수 있고.
- 로컬에서 사용할 땐 키-값 캐시를 이용하면 성능에 기여할 수 있다고 한다. 키 값 캐시는 모델이 생성한 중간 계산 결과를 저장해두는 메모리 공간임. 특히, LLM이 토큰을 예측할 때 이전 계산 결과를 다시 계산하지 않도록 만듬. Transformer 아키텍처에서, 각 토큰은 이전에 생성된 모든 토큰과 상호작용해서 다음 토큰을 예측함. 이 어텐션 메커니즘에서 사용되는게 키 값 캐시. 배치 처리를 통해 여러 요청을 동시에 처리할 때, 각 요청은 같은 디코딩 단계에 대해 공통된 키-값 캐시를 공유하도록 하면 중복된 연산을 줄일 수 있어서 성능 개선을 할 수 있다고 함.
- 로컬로 LLM 을 사용하는 방식이 아니라 API를 통해 외부 LLM에 접근할 때, 각 요청이 서버를 통해 개별적으로 처리하기 때문에 병렬 처리로 속도 개선의 이점을 누릴 수 있음.
- (1) Skeleton 단계:
Skeleton 프롬프트:
- LLM이 답변의 전체적인 구조만 제공하도록 유도하는 방식으로 설계된 프롬프트임.
- SoT에서 Skeleton 프롬프트는 전체 답변의 세부 내용을 작성하지 않고, 간략한 핵심 포인트만을 뽑아내는 단계에서 사용됨.
- LLM이 질문에 대한 답변을 짧고 일관된 포인트 리스트로 생성하도록 함. 예를 들어 중국 요리의 대표적인 종류는? 이라고 물어보면 다음과 같이 나열한다:
-
- Dumplings.
-
- Noodles.
-
- Dim Sum.
-
- 프롬프트를 보면 작업 지침으로 Skeleton만 생성하고, 구체적인 세부 내용은 포함하지 말라고 함. 이로 인해 LLM은 전체 내용을 작성하지 않고 중요한 핵심 포인트만을 짧게 요약하는데 집중한다.
- Prompt 3을보면 예시를 제공해줘서 어떻게 답변하면 되는지 더 자세하게 설명하고 있음.
포인트 확장 프롬프트:
- 이 프롬프트는 Skeleton의 각 포인트를 독립적으로 확장하여 병렬로 처리할 수 있도록 설계되었음.
- 이 프롬프트의 작업 지침을 보면 Skeleton 포인트를 한 가지씩 확장하되, 다른 포인트로 넘어가지 않도록 지시하여 LLM이 특정 포인트에만 집중하도록 유도함.
- "[User:] You're responsible for continuing the writing of one and only one point in the overall answer to the following question. {question} The skeleton of the answer is {skeleton} Continue and only continue the writing of point {point index}. Write it very shortly in 1∼2 sentence and do not continue with other points! [Assistant:] {point index}. {point skeleton}" 를 보면 됨.
- 그리고 작업 지침에 "Write it very shortly in 1∼2 sentence" 를 적어서 간결한 답변을 유도함.
- 포인트 확장 프롬프트는 Skeleton 전체와 확장해야 할 포인트의 인덱스를 명시적으로 제공함. 이 정보를 통해 LLM이 확장할 포인트의 위치와 내용을 정확히 파악하게 해준다.
- "The skeleton of the answer is {skeleton} Continue and only continue the writing of point {point index}." 이렇게 지시한 걸 볼 수 있음.
포인트 추출 방법:
- Skeleton 에서 만든 포인트 리스트들에서 포인트를 출력하기 위해 간단한 정규 표현식을 사용함: (\d+).\s?([\s\S]+?)(?=\n|\n*$)
Skeleton-of-Thought with Router, SoT-R
- SoT는 질문에 대한 답변을 독립적인 포인트들로 분리하여 병렬적으로 처리할 수 있을 때 효과적으로 사용할 수 있음. 구조적으로 분해 가능한 질문에 적합하다. 단계별 추론 질문에서는 적합하지 않음.
- SoT의 실용적 적용을 확대하기 위해, 우리는 SoT를 적절한 경우에만 적응적으로 적용하는게 필요함. 그게 SoT-R 임. 여기서는 라우터 모듈을 제안하는 것.
- 이 라우터는 사용자 요청에 대해 SoT를 적용할지 여부를 결정하고, 그에 따라 SoT 또는 일반적인 디코딩 방식을 선택한다. 이러한 접근법은 복잡한 작업을 해결하기 위해 여러 모델을 조합하는 최근의 추세와 일치한다.
- 라우터를 구현하기 위해 두 가지 방법을 소개함:
- LLM 프롬프트를 이용한 라우터: 모델 훈련이 필요 없이 프롬프트를 사용해 라우팅 역할을 수행
- 훈련된 RoBERTa를 이용한 라우터: 작은 언어 모델을 훈련시켜 라우터로 사용함.
- 프롬프트 라우터:
- LLM에게 직접 질문이 SoT에 적합한지 여부를 묻는 방법임.
- 구체적으로, 원하는 답변이 독립적인 포인트들의 리스트로 구성되었는지 묻는 방법이다.
- 답변이 ‘예’라면 SoT를 적용하고, 그렇지 않다면 일반적인 생성 방식을 사용하면 됨.
- 훈련된 라우터:
- GPT-4를 라우터로 활용하면 모델 훈련이 필요 없지만, 프롬프트 디자인에 민감하다는 단점이 있음.
- 따라서 우리는 이 문제를 시퀀스 분류 작업으로 접근해서 작은 언어 모델을 파인튜닝하는 접근법을 사용.
- 여기서는 RoBERTa 모델을 사용함. 이건 약 1억 2천만 개의 파라미터를 가진 작은 모델임.
- SoT-R 을 사용하면 SoT보다 낮은 속도 향상을 보일거임. 하지만 SoT-R 을 사용하더라도 1배 정도는 더 빨라진다고 함.
- 훈련된 라우터를 사용한 SoT-R 은 더 높은 속도 향상을 보였다고 함.
Limitations:
- 현재 SoT는 포인트 간의 의존성을 고려하지 않고 있음. 그래서 독립적인 포인트들로 나뉠때만 가능함.
- Graph-of-Thoughts 를 사용하면 포인트들을 그래프 구조로 조직화하여 각 포인트의 의존성을 명시하는게 가능함.
- 응답 품질 향상을 위한 데이터 중심 엔지니어링은 이미 인기를 얻고 있지만 추론 효율성에 대한 잠재력은 아직 충분히 탐구되지 않았다고 함.
- SoT는 추론 효율성에 대한 데이터 중심 최적화의 첫 번째 시도임.
- LLM의 능력과 LLM이 생성한 데이터의 양이 급격히 증가함에 따라 데이터 중심 기법이 더욱 중요해질 것.