오픈소스 LLM에 새로운 표준을 제시할 구글 Gemma

singleheart·2024년 4월 5일

Gemma 등장 이전의 표준 - Llama

최근 LLM 학습에 가장 큰 영향을 준 모델을 꼽으라면 아무래도 2023년 2월에 발표된 Meta의 라마일 것입니다.
OpenAI가 트랜스포머 구조에서 디코더를 활용해서 GPT를 고안한 이후 오랫동안 아키텍처에 큰 변화가 없었는데 라마에서 몇 가지 수정을 한 뒤로는 라마의 방식이 사실상 표준이 되었습니다.

주요한 변경사항을 열거하자면

활성화 함수를 GELU에서 SwiGLU로 변경
pre-normalization (attention 전에 정규화부터)
정규화를 LayerNorm에서 RMSNorm으로 변경
position embedding에 RoPE 도입
embedding layer와 output layer를 분리해서 따로 학습
GQA (grouped query attention) 도입

이후에 등장한 LLM들은 대개 이 방식을 따르고 있으므로 사실상 업계의 표준이 되었습니다.
저도 직접 실험해 보았는데 예전 방식에 비해서 모델의 성능이 향상되는 것을 확인할 수 있었습니다.
그런데 이러한 방법이 메타AI에서 처음 나온 것은 아닙니다. 대부분 구글에서 개발한 것입니다.
OpenAI에 가려서 요즘 주목을 못 받고 있지만 트랜스포머도 구글에서 처음 만든 것처럼 여전히 구글은 중요한 기술들을 새로 개발하고 있습니다.

기술의 원조 구글에서 처음으로 오픈소스 LLM, Gemma를 공개했습니다. LaMDA, PaLM, Gemini 등 구글에서 LLM은 꾸준히 발표해왔지만, 오픈소스는 처음입니다.
기술 보고서도 함께 공개해서 어떠한 기술이 사용됐는지를 엿볼 수 있습니다.

Gemma에 사용된 기술

우선 라마의 기술 중 아래는 그대로 유지했습니다:

RoPE
RMSNorm

GeGLU 활성화 함수

예전에는 ReLU나 GELU를 사용했고, 라마 이후로 SwiGLU가 유행하고 있는데 Gemma에서는 GEGLU를 사용했습니다.
GEGLU는 SwiGLU와 비슷한데 Swish 대신 GELU와 GLU를 결합합니다. GLU가 적용되면 파라미터가 확 늘어나기 때문에 라마에서는 균형을 맞추기 위해 히든 노드 수를 줄였는데요,
Gemma는 오히려 feedforward layer에서 히든 노드를 대폭 늘렸습니다.
굳이 줄이는 것보다는 늘리는 것이 성능이 낫다고 봤기 때문일 텐데 앞으로 다른 그룹들에서 실험으로 확인해야 하겠습니다.
GLU에 대한 자세한 내용은 논문을 참고하세요.

MQA (multi query attention)

MQA는 GQA (grouped query attention)의 원조 기술인데, 그룹을 1개만 사용하는 단순한 구조입니다.
속도가 빨라지지만 모델의 성능이 떨어진다는 우려가 있어서 소형 모델에서는 잘 사용하지 않았는데요,
Gemma는 2B 규모의 작은 모델에서도 MQA를 적용했습니다.
오히려 7B에서는 MQA를 사용하지 않고 기존의 MHA (multi head attention; 트랜스포머의 기본 구조)를 사용하였는데 구글에서 실험을 통해 결정했다고 합니다.

pre-and-post normalization

원조 transformer는 attention 뒤에 정규화를 했고, 최근의 추세는 attention 앞에 정규화를 하는 것이었는데요, Gemma는 attention 앞뒤로 모두 정규화를 합니다.

embedding layer와 output layer를 다시 합침

라마 이후로 두 레이어를 별도로 학습하는 것이 유행이었는데, Gemma는 다시 두 레이어의 weight를 공유하는 방식으로 회귀했습니다.

Gemma의 토크나이저

Gemini 토크나이저의 일부이며 호환된다고 합니다. 덕분에 비공개인 Gemini 토크나이저의 일부를 엿볼 수 있습니다. 주요 특징은 아래와 같습니다

SentencePiece
숫자를 낱자로 쪼갬 (OpenAI처럼 3자리씩 묶지 않고 자릿수마다 서로 다른 토큰으로 처리)
unknown token을 바이트 단위로 인코딩
vocab size 256000

토크나이저가 공개되어 있어서 내용을 볼 수 있는데 더욱 눈에 띄는 부분이 있었습니다

pre tokenizer를 사용하지 않음
- OpenAI cl100k_base등 다른 토크나이저에서 pre tokenizer를 사용해서 일부 토큰을 미리 분리해서 좋은 효과를 보았는데 구글은 사용하지 않았습니다
특수문자를 사용하지 않는 user, model 스페셜 토큰
- 보통 스페셜 토큰은 꺾쇠나 각괄호를 사용해서 표기하고, Gemma도 <pad>, <eos> 같은 스페셜 토큰이 있지만
  유독 user와 model 토큰은 스페셜 토큰임에도 특수문자를 사용하지 않고 영단어를 그대로 사용했습니다
<start_of_image> 토큰
- vocab size가 256000인데 마지막인 255999번 (0번부터 시작합니다) 토큰이 <start_of_image>입니다.
  이에 대응하는 <end_of_image>가 있어야 할 것 같은데 토크나이저 파일에는 없습니다. 아마도 제미나이 토크나이저에 있을 것으로 예상됩니다.
\n 1에서 31개, 공백문자(▁; U+2581)을 후처리로 공백(0x0020)으로 변환) 2에서 31개, \t 1에서 31개
- OpenAI도 그렇고 주요 토크나이저들은 이렇게 자주 연속되는 특수문자 패턴들을 여러 토큰으로 나누지 않고 한 토큰으로 처리하고 있습니다
주요 HTML 태그들을 1토큰으로 포함 (<table>, <h1>, </h6>, </strong> 등)
unicode <0x00>부터 <0xFF>까지 포함
- BPE byte fallback을 위한 것입니다
한글, 한자, 이모지 1글자 처리에 25000 정도 할당함
- vocab size가 256000개나 되다 보니 동아시아의 문자에 할당할 여유가 늘었습니다.
  다른 토크나이저같으면 바이트 단위로 쪼개서 1글자에 3토큰으로 처리할 것을 온전한 1글자-1토큰으로 처리하고 있습니다.

토크나이저의 한국어 효율

Gemma 토크나이저의 한국어 효율은 어떨까요? 데보션 매니페스토를 넣어 보면 107 토큰이 나옵니다.
한국어 중심 토크나이저는 55 토큰 정도 나오니까 2배 정도입니다.
(한국어 중심 토크나이저에 대한 자세한 내용은 이 블로그 포스팅
160토큰이 나오는 OpenAI cl100k_base보다는 낫지만, Palm2 토크나이저에서 88 토큰 정도였기때문에 그보다는 조금 약합니다.
제미나이는 한국어를 훨씬 잘하기 때문에 Gemma에 없는 토큰이 더 있을 것으로 추측하고 있습니다.

토크나이저의 한국어 효율이 왜 중요할까요? API를 호출할 때 토큰 수에 비례해서 과금되기 때문입니다.
OpenAI의 API와 구글의 API를 똑같이 1만 글자씩 호출하더라도 구글이 두 배 이상 쌉니다. (한국어 기준입니다. 언어에 따라 달라집니다)