- Gigatoken은 144코어 AMD EPYC 9565 환경에서 GPT-2 토큰화를 24.53 GB/s로 처리하며 HuggingFace Tokenizers 대비 최대 989배, tiktoken 대비 최대 681배 빠른 성능을 보인다.
- 핵심 최적화 지점은 BPE 머지 루프 자체가 아니라 SIMD 기반 SWAR 프리토크나이저와 직전 단어 토큰 매핑 캐시 구조로 분석된다.
- Rust와 MIT 라이선스로 배포되어 LLM 학습 및 추론 파이프라인에 즉시 통합 가능한 오픈소스 인프라 소프트웨어다.
토크나이저는 조용한 병목이며, 이를 SIMD로 다시 깎으면 모델 외부의 비용 곡선이 바뀐다.
대형 언어 모델의 학습과 추론 비용이 GPU 시간으로 환산되는 세상에서, 정작 입력 텍스트를 토큰으로 잘라내는 전처리 단계는 상대적으로 주목받지 못했다. 2026년 7월 23일자로 공개된 Rust 기반 BPE(Byte Pair Encoding) 토크나이저 Gigatoken은 이 조용한 병목을 24.53 GB/s 수준으로 끌어올리며 다시 한번 화두에 올려놓았다. 본문에서는 이 프로젝트의 구조와 수치, 그리고 오픈소스 생태계로의 파급효과를 순서대로 풀어본다.
왜 LLM 파이프라인에서 토크나이저가 다시 주목받나
BPE 토크나이저의 구조와 기존 병목 지점
BPE 토크나이저는 입력 텍스트를 단어 단위로 잘게 분할하는 프리토크나이저와, 병합 규칙을 따라 반복적으로 토큰을 합치는 머지 루프로 구성된다. 기존 구현에서는 프리토크나이저가 정규식 기반이라 분기가 많고, 매 단어마다 Python 바인딩을 거치며, 스레드 간 통신 비용이 누적되는 것으로 분석된다. 결국 처리량의 천장은 BPE 머지 자체가 아니라 그 앞단의 전처리에 가려져 있었던 셈이다.
HuggingFace Tokenizers, tiktoken이 남긴 한계
HuggingFace Tokenizers는 이미 멀티스레드 Rust로 구현되어 업계 표준처럼 쓰이고 있고, tiktoken은 OpenAI 계통 모델에서 빠른 인코딩을 제공한다. 그러나 두 라이브러리 모두 정규식 기반 프리토크나이저와 직렬화된 워크플로에 머물러 있다는 평가가 있으며, 이로 인해 대용량 코퍼스에서는 CPU 자원이 충분히 활용되지 못하는 병목이 남아 있는 것으로 분석된다. Gigatoken은 이 한계를 SIMD(Single Instruction, Multiple Data)와 캐시 구조로 직접 공격한다.
Gigatoken 아키텍처 심층 분석
Rust와 MIT 라이선스로 풀어낸 프로젝트 개요
Gigatoken은 Rust로 작성된 BPE 토크나이저이며, 라이선스는 MIT로 배포된다. Rust 선택은 제로 코스트 추상화, 안전한 동시성, 그리고 SIMD 내장 함수 접근성이라는 세 가지 이점을 동시에 얻기 위한 것으로 보인다. MIT 라이선스는 상용 제품에 그대로 링크하거나 내부 fork해 최적화할 수 있다는 점에서 채택 장점으로 작용한다.
SWAR 프리토크나이저의 SIMD 최적화 원리
핵심은 프리토크나이저를 정규식이 아닌 SWAR(SIMD Within A Register) 기법으로 다시 구현한 부분이다. SWAR는 레지스터 폭 안에서 여러 바이트를 병렬로 검사하는 방식으로, 공백, 구두점, 특수문자 분류를 분기 없이 처리한다. 이로써 정규식 엔진이 일으키던 분기 예측 실패와 Python 바인딩 호출이 사라지고, 데이터는 1차 패스로 거의 분류된 채로 BPE 머지 단계에 도달한다.
프리토큰 캐시로 분기·스레드 통신·Python 상호작용을 줄인 전략
두 번째 차별점은 직전 단어의 토큰 매핑을 캐시에 보관하는 구조다. 자연어에서는 같은 단어가 빈번하게 반복되므로, 매번 처음부터 머지를 적용하지 않고 직전 결과를 재사용한다. 분석에 따르면 이 캐시가 분기, 스레드 간 동기화, 그리고 Python 상호작용을 동시에 줄여 단일 코어 효율과 멀티코어 확장성을 함께 끌어올린 것으로 보인다.
벤치마크 수치 해부
144코어 AMD EPYC 9565 환경이 의미하는 것
벤치마크는 144코어 AMD EPYC 9565 서버에서 수행되었다. 이는 데이터센터급 고다중 스레드 환경을 가정한 수치이며, 일반 데스크톱에서는 절대적인 GB/s가 낮게 나올 수 있다는 점을 유의해야 한다. 그럼에도 멀티코어 확장성이 잘 살아 있다는 사실 자체가 SWAR 프리토크나이저와 캐시 구조의 조합이 락 경합 없이 병렬화되었음을 시사한다.
24.53 GB/s, 989배, 681배 수치의 실용적 해석
보고된 수치를 한 표로 정리하면 다음과 같다.
| 항목 | 수치 | 비교 대상 |
|---|---|---|
| 처리량 | 24.53 GB/s | GPT-2 토큰화, 144코어 AMD EPYC 9565 |
| 속도 향상 | 최대 989배 | HuggingFace Tokenizers 대비 |
| 속도 향상 | 최대 681배 | tiktoken 대비 |
| baseline 성격 | 이미 멀티스레드 Rust | HuggingFace Tokenizers 기준선 |
여기서 중요한 점은 비교 대상 baseline이 이미 멀티스레드 Rust로 작성된 구현이라는 사실이다. 따라서 989배라는 수치는 단순히 인터프리터 언어를 교체한 효과가 아니라, 같은 언어와 같은 멀티스레드 전략 안에서 SIMD와 캐시 설계만으로 갈아낸 성능 차이라는 의미로 해석된다.
오픈소스 생태계에 미치는 영향
학습·추론 파이프라인 통합 시나리오
데이터 전처리 단계에서 토크나이저가 차지하는 시간이 수십 퍼센트에 달하던 코퍼스에서는, Gigatoken 도입만으로 학습 전처리 단계의 CPU 비용이 크게 줄어들 가능성이 있다. 추론 서버에서는 입력 단의 레이턴시가 줄어들어 첫 토큰 출력 시간에 직접 영향을 주며, 특히 배치 전 토큰화가 병목이던 시나리오에서 효과가 클 것으로 분석된다.
MIT 라이선스가 가져오는 채택 장점
MIT 라이선스는 소스 공개 의무가 없으면서 상용 제품에 그대로 임베드할 수 있다. 이는 클라우드 벤더, 추론 플랫폼, 그리고 사내 LLM 스택을 가진 팀이 별도의 라이선스 검토 없이 채택할 수 있다는 뜻이다. 또 Rust로 작성되어 있어 기존 Python 데이터 파이프라인에 PyO3 같은 경량 바인딩으로 붙이거나, Rust 기반 추론 스택에 네이티브로 통합하는 두 가지 경로가 모두 열린다.
도입 시 고려사항과 향후 과제
먼저 벤치마크는 144코어 환경에 최적화되어 있으므로, 일반적인 8코어에서 16코어 환경에서는 절대 처리량이 크게 낮아질 수 있다. 둘째, SWAR 프리토크나이저가 다루는 문자 분류 정책이 모델 학습 시 사용한 정규식과 미묘하게 다르면, 학습과 추론 사이의 토큰 경계 불일치가 발생할 수 있어 회귀 테스트가 필요하다. 셋째, 캐시 구조가 메모리 사용량을 늘릴 수 있으므로 대용량 배치 환경에서는 캐시 크기 정책에 대한 별도 튜닝이 요구된다. 그럼에도 LLM 인프라의 비용 곡선은 GPU 위에서만 결정되지 않으며, 토크나이저와 같은 CPU 단계의 극단적 최적화가 전체 비용 구조를 바꿀 수 있다는 점이 Gigatoken이 던지는 가장 중요한 시그널로 분석된다.
- 토크나이저는 GPU가 아닌 CPU 단계의 조용한 병목이며, 무시할 수 없는 비용을 만든다.
- Gigatoken의 989배 성능은 SIMD 프리토크나이저와 캐시 구조라는 두 축의 결합 효과로 분석된다.
- 비교 baseline이 이미 멀티스레드 Rust라는 점에서 989배는 같은 언어 안의 설계 차이로 해석된다.
- MIT 라이선스와 Rust 구현은 상용 스택과 사내 스택 양쪽으로의 채택 경로를 동시에 열어준다.
- 도입 시에는 코어 수 환경, 토큰 경계 일치성, 캐시 메모리 정책을 함께 검증해야 한다.
참고 자료: MarkTechPost 원문(https://www.marktechpost.com/2026/07/23/meet-gigatoken-a-rust-bpe-tokenizer-that-encodes-text-at-24-53-gb-s-up-to-989x-faster-than-huggingface-tokenizers/), GeekNews 요약(https://news.hada.io/topic?id=31724)