기가토큰(Gigatoken): HuggingFace보다 989배 빠른 Rust BPE 토크나이저

1. 한 번에 보면 — 기가토큰이란 무엇인가

기가토큰은 Rust로 작성된 바이트 페어 인코딩(BPE) 토크나이저자주 함께 나오는 문자 쌍을 반복 합쳐 하위 단어 토큰을 만드는 토큰화 기법입니다. Python에서도 호출할 수 있도록 Python 바인딩Rust 등 다른 언어로 만든 라이브러리를 Python에서 쓸 수 있게 연결하는 인터페이스이 함께 제공됩니다.

• PyPI 패키지명: gigatoken (버전 0.9.0, 2026년 7월 21일 공개)
• 설치 명령: pip install gigatoken
• 저장소 언어 구성: Rust 66.2% / Python 33.3%
• 공식 벤치마크에서 지원되는 토크나이저 계열: GPT-2, GPT-OSS, Llama 3~4, Qwen 2~3.6, DeepSeek V3/R1/V4, GLM 4·5, Kimi K2, Nemotron 3, Phi-4, OLMo 2/3, ModernBERT, Gemma, Mistral 등 23종

사용 방식은 두 가지입니다.

• 호환 모드: 기존 HuggingFace·tiktoken 토크나이저를 감싸 결과 정확도는 100% 동일. 대신 처리량(throughput)단위 시간당 실제로 처리하는 데이터 양은 줄어들어 약 200~300배 수준.
• 네이티브 API: Rust가 파일을 직접 읽어 파이썬 오버헤드 없이 동작. 공개된 모든 성능 수치는 이 모드 기준.

2. 성능 한눈에 보기 (GPT-2 토크나이저, OpenWebText 코퍼스)

이 수치는 특정 CPU 한 종류의 우연이 아닙니다. x86과 ARM, 그리고 23개 토크나이저 계열 전반에서 같은 추세가 유지됩니다.

3. 이렇게 빨라진 이유 — 두 가지 핵심 최적화

놀랍게도 성능 비결은 BPE 병합 루프를 더 빠르게 만든 것이 아닙니다. 대부분의 토크나이저가 "이미 풀었다"고 여기던 두 영역에서 나왔습니다.

(1) 직접 만든 사전 토큰화(pretokenization)세부 토큰화 전에 텍스트를 단어 단위로 미리 잘라두는 단계 엔진

대부분의 구현은 이 단계를 정규식 엔진(regex engine)패턴 문법으로 텍스트를 검색·매칭하는 실행기에 맡깁니다. 기가토큰은 이 부분만 손수 구현하고 단계적으로 최적화했습니다.

SWAR(SIMD Within A Register)는 8바이트를 하나의 64비트 정수(u64)로 한꺼번에 불러와, 분기(또 갈래로 나뉘는 제어문) 없이 산술 연산으로 8바이트 모두의 문자 속성을 한 번에 검사하는 기법입니다. 전용 SIMD 하드웨어 명령이 없는 환경에서도 비슷한 병렬 효과를 냅니다.

마지막 단계의 핵심 통찰은 이 지점의 병목이 처리량이 아니라 지연(latency)이라는 것이었습니다. 각 토큰의 끝 위치는 직전 토큰에 의존해 약 25~27사이클의 직렬 사슬을 만듭니다. 안전한 분할 지점에서 독립적인 커서 두 개를 돌리면 비순차(out-of-order) 실행 엔진이 유휴 포트에 두 작업을 번갈아 끼워 넣어 명령어 수준 병렬성(ILP)독립적인 명령들을 동시에 실행해 처리 속도를 높이는 능력을 끌어올립니다.

(2) 사전 토큰 캐싱

이미 본 단어라면 인코딩을 다시 계산하지 않고 캐시에서 토큰 결과를 그대로 꺼옵니다. 저자는 "캐시가 빠르게 커지고 단어 분포가 롱테일(극단적 꼬리) 형태라 실전 구현이 어렵다"고 설명합니다. Python과의 상호작용은 최소화했고, 스레드 간 통신도 최소화했습니다.

실패한 시도들 — 깐깐한 기록

• #[cold]·#[inline(never)]를 이용한 핫/콜드 분리 → 580 MiB/s로 역행. 인라인 장벽 때문에 LLVM이 ASCII/유니코드 결합 루프를 더 이상 최적화하지 못함.
• SWAR 전환 횟수를 세는 2단계 분류 버퍼 → 알고리즘은 맞지만 354 MiB/s. 메모리 트래픽 추가 비용이 분기 절감보다 큼.
• 프로파일 기반 최적화(PGO)실제 실행 정보를 모아 컴파일러가 더 똑똑히 최적화하도록 돕는 기법 → 효과 없음. 내부 루프가 이미 분기 없이 동작하고 단어 경계 분기는 데이터에 의존.

4. 벤치마크는 공정했나 — 비교 조건 짚어 보기

기가토큰의 수치는 "완전히 동일한 조건"의 비교는 아닙니다. 조건 차이가 공개되어 있습니다.

• 기가토큰은 분할되지 않은 전체 파일을 그대로 인코딩하며, 문서 경계는 자체적으로 찾고 자동으로 병렬화.
• HuggingFace의 encode_batch_fast는 첫 100MB, tiktoken의 encode_ordinary_batch는 첫 1GB만 평가했고, 모두 <|endoftext|> 기준으로 미리 분할.
• 기준 구현에는 캐싱이 없어 처리량이 균일하게 유지됨.
• 병렬 처리를 켠 새 프로세스로 3라운드 교차 측정, 그중 최고 기록을 채택.

어휘 집합 유형에 따라서도 제약이 있습니다. SentencePiece 계열은 부분 최적화만 적용됐고, EPYC 기준 Gemma 1은 2.51GB/s(7.3배), Gemma 3은 3.43GB/s(9.6배), CodeLlama는 3.47GB/s(10.0배)에 그쳤습니다. 헤드라인 수치인 수백~수천 배보다는 한 자릿수 낮은 수준입니다.

5. 독립 재현 결과 — KrabArena 검증

4코어 Intel Xeon VM(2.20GHz)에서 174MB짜리 OpenWebText 일부를 돌린 결과:

• 기가토큰 0.9.0: 중앙값 277.8MB/s
• tiktoken 0.13.0: 10.62MB/s → 26.2배 차이
• tokenizers 0.23.1: 3.33MB/s → 83.4배 차이

35,356개 문서 전부 검증에 성공했고, 코어 수가 늘어날수록 성능 비례도 유지되었습니다.

6. 핵심 요약 — 한 줄 정리

• 기가토큰은 144코어 EPYC에서 GPT-2 토큰화를 24.53GB/s로 처리. HuggingFace 대비 989배, tiktoken 대비 681배.
• 성능 우위는 x86·ARM, 23개 토크나이저 계열에서 모두 유지.
• 비결은 더 빠른 BPE 병합 루프가 아니라 SWAR 사전 토크나이저 + 사전 토큰 캐싱.
• SentencePiece 어휘에서는 7~22배에 머무르고, WordPiece는 지원하지 않음.
• HuggingFace·tiktoken과 결과를 100% 동일하게 보장하는 호환 모드는 약 200~300배 수준.

7. 자주 묻는 질문 (FAQ)

기가토큰은 어디서 설치하나요?

PyPI에 gigatoken이라는 이름으로 배포됩니다. pip install gigatoken 한 줄이면 설치되며, 2026년 7월 21일 기준 최신 버전은 0.9.0입니다.

기존 HuggingFace 토크나이저 코드를 그대로 가져와도 되나요?

네. 호환 모드에서 기존 토크나이저를 감싸면 출력 결과가 정확히 동일합니다. 대신 처리 속도는 약 200~300배 수준으로 떨어집니다.

SentencePiece 기반 모델에서도 같은 속도 향상이 나오나요?

아쉽지만 아닙니다. BPE만큼 최적화되지 않아서 EPYC에서 7~10배 정도의 개선만 보고되었습니다. 헤드라인의 989배는 BPE 토크나이저 기준입니다.

WordPiece 토크나이저도 지원하나요?

현재 공식 벤치마크 기준 WordPiece는 지원하지 않습니다. BPE 계열(23개)에 집중한 라이브러리입니다.

어떤 GPU가 필요한가요?

필요하지 않습니다. 모든 최적화는 CPU의 분기 없는 산술, SWAR, 명령어 수준 병렬성으로 이루어집니다. 코어가 많을수록 효과는 더 커집니다.