주제: TK-4 Token Length 문제 (Context Window / 비용 / 성능 Tradeoff)
문제 설정
LLM은 텍스트를 토큰(token) 단위로 처리하며 입력 길이에 제한이 있습니다. 이 제한을 context window라고 합니다.
예:
- 4K tokens
- 32K tokens
- 128K tokens
토큰 길이가 증가하면 다음 세 가지 요소 사이에서 tradeoff가 발생합니다.
- context window
- 연산 비용
- 모델 성능
직관 비유
- context window -> 모델의 기억력
- token 수 증가 -> 더 많은 정보를 기억
- 하지만 계산 비용 증가
1. Token Sequence 표현
LLM 입력은 다음과 같은 토큰 시퀀스입니다.
기호 의미
- t_i : token id
- n : sequence length
왜 중요한가
sequence length가 context window를 결정합니다.
주의점
n이 context window보다 크면 입력이 잘리거나(truncation) 분할됩니다.
2. Context Window
context window는 모델이 한 번에 처리할 수 있는 최대 토큰 수입니다.
n <= C
기호 의미
- n : 입력 토큰 길이
- C : context window
왜 필요한가
모델 메모리와 계산량을 제한합니다.
주의점
긴 문서는 여러 chunk로 분할해야 합니다.
3. Attention 계산 비용
Transformer의 self-attention 계산은 다음 복잡도를 가집니다.
기호 의미
- n : 토큰 길이
직관 설명
모든 토큰이 서로를 attention하기 때문에 계산량이 급격히 증가합니다.
예시
| tokens | attention pairs |
|---|---|
| 1K | 1M |
| 4K | 16M |
| 8K | 64M |
주의점
token 수가 2배 증가하면 계산량은 4배 증가합니다.
4. Token 비용
API 기반 LLM에서는 token 수가 비용을 결정합니다.
기호 의미
- tokens : 입력 + 출력 토큰 수
왜 중요한가
긴 context는 비용 증가로 이어집니다.
5. 성능과 Token Length
긴 context는 더 많은 정보를 제공합니다.
- 문서 이해
- 대화 기억
- 코드 분석
하지만 다음 문제도 발생합니다.
- attention dilution
- long-range dependency 문제
즉 너무 긴 context는 오히려 성능 저하를 일으킬 수 있습니다.
6. Tradeoff 요약
| 요소 | 효과 |
|---|---|
| 큰 context window | 더 많은 정보 처리 |
| 긴 token sequence | 계산 비용 증가 |
| 긴 context | attention 분산 가능 |
7. 실제 해결 전략
- Chunking
- RAG retrieval
- Sliding window
예:
문서 -> chunk1
-> chunk2
-> chunk3필요한 chunk만 모델에 입력합니다.
코드-수식 연결
| 개념 | 코드 | 설명 |
|---|---|---|
| tokenize | tokenizer.encode(text) |
텍스트 -> token |
| sequence length | len(tokens) |
토큰 길이 |
| max length | max_length |
context window 제한 |
자주 하는 오해 5개
- context window가 크면 항상 성능이 좋아진다고 생각한다
- token 길이는 모델 속도와 무관하다고 생각한다
- 긴 문서를 그대로 넣는 것이 항상 좋다고 생각한다
- attention 비용이 선형이라고 생각한다
- tokenization 방식이 token 길이에 영향을 주지 않는다고 생각한다
체크리스트 (스스로 설명 가능해야 하는 질문)
- context window란 무엇인가?
- 왜 attention 계산 비용은 O(n^2)인가?
- token length가 비용에 어떤 영향을 주는가?
- 긴 context가 항상 좋은 이유가 아닌 이유는 무엇인가?
- 긴 문서를 처리할 때 어떤 전략을 사용할 수 있는가?