marcelroed/gigatoken 딥다이브
— LLM 토크나이징을 초당 기가바이트로 끌어올린 Rust 엔진

1프로젝트 한 줄 요약

토크나이저가 뭔지부터 짚자. LLM은 글자를 직접 먹지 않는다. 텍스트를 토큰(token)이라는 정수 조각들로 쪼갠 뒤, 그 정수 배열을 입력으로 받는다. 이 "텍스트 → 정수 배열" 변환을 하는 게 토크나이저다. GPT 계열은 대부분 BPE(Byte-Pair Encoding)라는 방식을 쓴다.

문제는 양(量)이다. 현대 LLM은 수조~수십조 토큰으로 학습하는데, 그 전에 원본 텍스트(수 TB)를 전부 토큰화해야 한다. 이때 토크나이저 속도가 느리면 GPU가 놀고 데이터 준비에만 며칠이 날아간다. gigatoken은 바로 이 "학습 전 대량 토큰화" 구간을 겨냥한 순수 처리량(throughput) 특화 도구다. 챗봇이 한 문장 토큰화하는 지연시간(latency)이 아니라, "11.9 GB짜리 OpenWebText를 통째로 얼마나 빨리 삼키느냐"가 목표다.

구현은 순수 Rust다. GPU도 CUDA도 쓰지 않는다. 오직 CPU 한 대의 SIMD 명령어와 캐시 계층을 마지막 한 방울까지 짜내서 이 속도를 낸다. Python 사용자는 pyo3 바인딩을 통해 이 Rust 엔진을 그냥 import gigatoken으로 쓴다. 저자 Marcel Rød는 스탠퍼드 소속이며, 이 프로젝트는 스탠퍼드의 유명한 강의 CS336("Language Modeling from Scratch")의 BPE 과제에서 출발해 프로덕션 패키지로 자라난 것으로 보인다.

2왜 주목받는가 — tiktoken·HF와 뭐가 다른가

토큰화는 이미 최적화가 많이 된 분야다. OpenAI의 tiktoken도, HuggingFace의 tokenizers도 속도 때문에 Rust로 작성됐고 멀티스레드로 돈다. 그런데 gigatoken은 "이미 빠른" 그들보다 다시 100~1300배 빠르다고 주장한다. 보통 이런 주장은 과장이지만, gigatoken은 같은 입력에서 토큰이 한 개도 다르지 않음을 검증하고(공정 비교), 재현 명령까지 제공한다는 점에서 눈길을 끈다.

실측 벤치마크 (owt_train.txt = OpenWebText 11.9 GB)

표를 정직하게 읽는 법: BPE 계열(GPT-2·Llama·Qwen·DeepSeek)은 15~24 GB/s로 압도적이지만, SentencePiece 계열(Gemma·Mistral)은 3~4 GB/s로 뚝 떨어진다. 저자 스스로 "SentencePiece는 아직 최적화가 덜 됐다(우선순위 낮음)"라고 README에 명시한다. 즉 "1000배"는 BPE에서의 최고치이고, 실제 배수는 토크나이저 종류에 따라 10배~1300배로 갈린다. 이렇게 약점을 숨기지 않는 태도가 오히려 신뢰를 준다.

왜 이렇게까지 빠른가 — 핵심 통찰 하나

gigatoken의 가장 중요한 발견은 이것이다: "토큰화의 병목은 BPE 병합이 아니라, 그 앞 단계인 사전 토큰화(pretokenization)다." 대부분의 토크나이저는 GPT-2가 정한 복잡한 정규식('s, ?\p{L}+, ?\p{N}+ 같은 규칙)으로 텍스트를 먼저 "단어 비슷한 조각"으로 자른다. 이 정규식 처리가 전체 시간의 절반을 먹는다. gigatoken은 이 정규식을 SIMD 명령어로 손수 재구현해 이 절반을 통째로 날려버렸다. 나머지 절반(BPE 병합, 캐시 조회)도 캐시 친화적으로 다시 짰다. 세부는 4장에서 뜯어본다.

드롭인 호환 — 갈아끼우기만 하면 된다

빠르기만 하면 안 쓴다. 기존 코드를 다 바꿔야 한다면 아무도 옮겨오지 않기 때문이다. gigatoken은 .as_hf(), .as_tiktoken() 어댑터로 HuggingFace fast tokenizer API와 tiktoken Encoding API 양쪽을 흉내 낸다. 특수 토큰, eot_token, n_vocab까지 맞춘다. 즉 기존 학습 스크립트에서 import 한 줄만 바꾸면 되는 이 "이식 비용 제로" 설계가, 순수 속도만큼이나 사람들이 몰리는 이유다.

3기술 스택 전체 지도

gigatoken의 기술 선택은 "속도를 위한 것"과 "쓰기 편하게 하기 위한 것"으로 딱 나뉜다. 무거운 계산은 전부 Rust가 하고, 사용자와 만나는 얇은 표면만 Python이다. 특이하게도 GPU·CUDA·C++이 전혀 없다 — CPU 한 대의 SIMD와 캐시만으로 승부한다.

계층별 지도

4아키텍처 심화 — 3개의 속도 축

gigatoken이 GB/s를 뽑는 비결은 하나의 마법이 아니라 세 개의 축이 곱해진 결과다. 전체 파이프라인을 먼저 그림으로 보자.

축 ① — 정규식을 SIMD 비트마스크로 대체 (가장 큰 승부수)

일반 토크나이저는 GPT-2가 정한 정규식으로 단어 경계를 찾는다. gigatoken은 이걸 simdjson 스타일 마스크 스캐너로 손수 짰다. 64바이트를 SIMD로 읽어 바이트마다 "글자/숫자/공백/구두점" 클래스를 비트마스크로 만들고, 단어 경계 비트를 레지스터 안 비트 연산만으로 유도한다. 워커는 경계 비트를 하나씩 pop하며 pretoken을 뽑는다 — 바이트마다 if로 분기하던 걸 없앤 것이다.

SIMD가 없는 CPU를 위한 스칼라 폴백도 배울 게 많다. 인트린식 없이 순수 산술로 8바이트를 병렬 판정하는 SWAR 기법이다:

// 분기(if) 없이 산술만으로 바이트 종류 판정 — SWAR
#[inline(always)]
fn is_letter(b: u8) -> bool { (b | 0x20).wrapping_sub(b'a') < 26 }
fn is_digit(b: u8)  -> bool {  b.wrapping_sub(b'0')         < 10 }

b | 0x20은 대문자를 소문자로 접는 트릭(비트 하나만 켜면 A→a)이고, wrapping_sub 뒤 범위 비교는 "a~z 사이냐"를 분기 없이 답한다. 분기가 없으면 CPU의 분기 예측 실패가 사라져 파이프라인이 안 멈춘다.

축 ② — 캐시 라인에 딱 맞춘 pretoken 캐시

같은 단어(pretoken)는 텍스트에 계속 나온다. the, of, and... 그래서 한 번 계산한 단어의 토큰 결과를 외워두면 BPE를 다시 돌릴 필요가 없다. gigatoken의 ShortPretokenCache는 1GB OpenWebText에서 99.4% 적중한다. 설계가 지독하게 하드웨어 친화적이다:

• 키 = u128 하나: 15바이트 이하 단어의 바이트를 128비트에 통째로 담아, 문자열 비교(memcmp) 대신 정수 비교 한 번으로 끝낸다.
• probe당 캐시 라인 1개: 엔트리를 32바이트로 맞춰 조회 한 번에 CPU 캐시 라인 딱 하나만 건드린다(표준 hashbrown은 2개).
• 값 인라인 저장: 단어의 90%가 토큰 1개, 98%가 2개 이하 → 결과 토큰을 캐시 안에 바로 넣어 2차 메모리 접근을 없앤다.
• 2 MiB huge page + 프리페치: 64MB 테이블을 작은 페이지로 쓰면 주소변환 캐시(dTLB)가 터진다. huge page로 묶고 소프트웨어 프리페치를 넣어 +15%를 더 짰다.

축 ③ — 병렬성과 "Python 우회"

마지막 축은 규모다. Rust가 파일을 직접 mmap해 텍스트가 Python 인터프리터를 아예 거치지 않고 rayon 풀로 흩어진다. 거대한 단일 문서조차 단어 경계에서 쪼개 전 코어를 쓰되, 토큰 결과는 바이트 단위로 동일하게 재조립한다. 출력은 문서마다 numpy 배열을 새로 만드는 대신 awkward Array(플랫 버퍼 1개 + 오프셋)로 담아 할당 폭발을 막는다. 불변(immutable) 모델 테이블은 Arc로 공유해 프로세스 fork도 O(1)이다.

물리적 바닥 — 더는 못 빠른 이유

흥미롭게도 저자는 프로파일링으로 "여기가 한계"임을 증명한다. 성능 카운터를 보면 Bad speculation(분기 예측 실패)이 25%인데, 단어 경계는 텍스트 내용에 따라 제멋대로라 CPU가 원리적으로 예측할 수 없다. 즉 이 25%는 튜닝으로 못 없애는 물리적 바닥이다. PGO(프로파일 기반 최적화)를 시도했다가 "데이터 의존 분기라 효과 없음"으로 되돌린 기록도 남아 있다.

5디렉토리 구조 해부

구조만 봐도 "어디를 먼저 읽어야 하는지"가 보인다. 속도의 핵심 3개는 src/batch.rs(병렬 엔진), src/pretokenize/fast/mask.rs(SIMD 스캐너), src/bpe/pretoken_cache.rs(캐시)다. 그런데 학습 자료로 가장 값진 파일은 코드가 아니라 문서다 — 루트의 pretokenizer_optimization_log.md와 profiling/ 폴더. 여기엔 "무엇을 시도해서 얼마가 나왔고, 무엇이 실패했으며 왜인지"가 단계별로 적혀 있다.

6학습 포인트 — 여기서 훔쳐올 설계

gigatoken이 특별한 이유는 "빠른 토크나이저"라서가 아니라, 고성능 CPU 코드를 어떻게 짜고 어떻게 증명하는지를 통째로 보여주는 살아있는 교본이라서다. 토큰화에 관심이 없어도 아래 다섯 가지는 어떤 성능 작업에나 그대로 옮겨 쓸 수 있다.

7하드웨어 / 시스템 요구사항

gigatoken은 GPU가 필요 없다. 대신 성능을 다 뽑으려면 SIMD를 지원하는 최신 CPU와 몇 가지 시스템 조건이 붙는다.

8직접 해볼 수 있는 실습 과제

import gigatoken as gt
tok = gt.Tokenizer("openai-community/gpt2")
ids = tok.encode("Tokenize your text data at GB/s!")
print(ids, tok.decode(ids).decode("utf-8"))

uvx --with tokenizers gigatoken bench 'openai-community/gpt2' \
     my_text.txt --validate --doc-separator "<|endoftext|>"

9관련 기술 심화 학습 로드맵

gigatoken을 제대로 씹어먹으려면 여러 층의 배경지식이 필요하다. 밑에서부터 쌓는 6주 로드맵을 제안한다.

10핵심 키워드 사전

11참고 링크

프로젝트

• github.com/marcelroed/gigatoken — 저장소 원본(MIT)
• PyPI: gigatoken — 설치 패키지(pip install gigatoken)
• 저장소 내 README.md · design_doc.md — 설계 의도와 벤치마크 표
• 저장소 내 pretokenizer_optimization_log.md — ★ 최적화 여정 일지(성공+실패 기록)

핵심 소스(먼저 읽을 파일)

• src/pretokenize/fast/mask.rs — SIMD 마스크 스캐너(속도의 핵심)
• src/bpe/pretoken_cache.rs — 캐시라인 친화 커스텀 해시테이블
• src/batch.rs — mmap→청크분할→rayon 병렬 엔진
• profiling/report.md · profiling/campaign_report.md — 프로파일 분해와 최적화 캠페인

기반 기술 / 배경

• karpathy/minbpe — BPE를 200줄로 이해하기(1주차 재료)
• openai/tiktoken · huggingface/tokenizers — 비교 대상(이미 Rust·멀티스레드)
• stanford-cs336/owt-sample — 벤치마크에 쓰인 OpenWebText 샘플 · CS336 강의
• Rust std::simd(portable_simd) · rayon · pyo3 — 핵심 크레이트 문서