"7B 모델" 의 7B 는 파라미터 수이고, "컨텍스트 128K" 의 128K 는 토큰 수다. 둘 다 숫자로 표기되고 모델 사양표에 나란히 적히다 보니 같은 축의 값처럼 읽히는데, 완전히 다른 층의 개념이다.
입력 토큰 → 모델(파라미터) → 출력 토큰
파라미터는 모델 안 에 고정되어 있는 값이고, 토큰은 모델을 지나가는 데이터다.
학습으로 정해진 가중치의 개수다. 어텐션의 투영 행렬, 피드포워드 층의 행렬, 임베딩 행렬 등이 모두 포함된다. 수학적으로 쓰면 모델은 y = f(x; θ) 이고 파라미터는 θ 다.
파라미터 수는 두 가지를 직접 결정한다. 하나는 메모리 요구량 이다. 추론에 필요한 가중치 메모리는 대략 파라미터 수 × 데이터 타입 크기다. FP16 이면 파라미터당 2바이트이므로 7B 모델은 약 14GB, 8비트 양자화면 약 7GB, 4비트면 약 3.5GB 가 가중치만으로 필요하다. 여기에 KV 캐시와 활성값이 더 붙는다.
다른 하나는 표현 능력 이다. 파라미터가 많을수록 복잡한 패턴을 담을 수 있다. 다만 학습 데이터의 양과 질이 받쳐 주지 않으면 파라미터만 늘려도 성능이 비례해 오르지 않는다.
텍스트를 모델이 처리하는 단위로 쪼갠 조각이다. 단어와 일치하지 않는다. 대개 서브워드 단위로 쪼개진다.
"running" -> ["run", "ning"]
"Hello world" -> ["Hello", " world"]
한국어는 영어보다 토큰이 잘게 쪼개지는 경향이 있어, 같은 의미의 문장이라도 영어보다 토큰을 더 쓴다. 토크나이저가 어떤 데이터로 학습되었느냐에 따라 달라지므로 모델마다 다르다.
여기서 구분해야 할 것이 어휘 크기(vocabulary size) 다. 토크나이저가 아는 토큰 종류의 수(예: 5만 개)를 뜻하며, 입력 문장의 토큰 수와는 다른 값이다.
| 오해 | 실제 |
|---|---|
| 파라미터 수 = 저장된 토큰 수 | 파라미터는 가중치다. 토큰을 저장하지 않는다 |
| 토큰 = 모델이 가진 최소 단어의 수 | 토큰은 모델이 가진 것이 아니라 드나드는 데이터 단위다 |
| 토큰 = 단어 | 서브워드 단위라 단어보다 잘다 |
| 파라미터 = 조합 가능성의 수 | 조합 공간의 크기가 아니라 함수의 가중치 개수다 |
| 파라미터가 크면 한 번에 더 긴 글을 쓴다 | 출력 길이는 컨텍스트 길이와 생성 설정이 정한다 |
비유하자면 파라미터는 사람의 숙련도이고 토큰은 그 사람이 읽고 쓰는 글자 수다. 숙련도가 높다고 한 번에 더 많은 글자를 쓰는 것은 아니다.
둘 사이에 1:1 대응은 없지만 운영상 얽힌다.
연산량 측면. 어텐션의 계산량은 시퀀스 길이에 대해 제곱에 비례한다. 토큰이 두 배가 되면 어텐션 부분의 비용은 대략 네 배가 된다. 최근 구현은 여러 최적화로 이 비용을 줄이지만 증가 경향 자체는 남는다.
메모리 측면. KV 캐시는 토큰 수에 비례해 늘어난다. 파라미터 수로 계산한 가중치 메모리에 더해, 긴 컨텍스트를 쓰면 이 캐시가 GPU 메모리를 크게 잡아먹는다. 긴 문서를 다루는 서비스에서 OOM 이 나는 원인은 대개 가중치가 아니라 KV 캐시다.
비용 측면. API 과금은 파라미터가 아니라 토큰 수로 매겨진다. 모델을 크게 바꾸면 토큰당 단가가 오르고, 프롬프트를 길게 쓰면 토큰 수가 는다. 두 축을 따로 관리해야 한다.
"컨텍스트 128K" 는 입력과 출력을 합쳐 한 번에 다룰 수 있는 토큰 수의 상한이다. 파라미터 수와 무관하게 정해진다. 작은 모델이 긴 컨텍스트를 가질 수도 있고 그 반대도 가능하다.
상한까지 넣을 수 있다는 것과 상한 근처에서도 품질이 유지된다는 것은 다른 이야기다. 긴 입력의 가운데 부분을 놓치는 경향이 알려져 있으므로, 중요한 지시는 앞이나 뒤에 둔다.