--- title: "기가토큰, 언어 모델 토크나이징을 최대 1000배 가까이 빠르게 만든 러스트 토크나이저" published: 2026-07-22T17:20:38.000Z canonical: https://jeff.news/article/5063 --- # 기가토큰, 언어 모델 토크나이징을 최대 1000배 가까이 빠르게 만든 러스트 토크나이저 Gigatoken은 언어 모델용 토크나이징을 Rust와 SIMD 최적화로 크게 가속하는 프로젝트다. GPT-2 기준 144코어 EPYC에서 24.53GB/s를 찍으며 HuggingFace Tokenizers 대비 989배, tiktoken 대비 681배 빠른 수치를 제시한다. ## 토크나이징 속도를 정면으로 때린 프로젝트 - Gigatoken은 언어 모델용 토크나이저를 극단적으로 빠르게 만든 Rust 기반 프로젝트임 - 설치는 `pip install gigatoken`으로 가능함 - 자체 API뿐 아니라 HuggingFace Tokenizers, tiktoken 호환 모드도 제공함 - 다만 최대 성능은 Gigatoken API를 직접 쓸 때 나오고, 호환 모드는 정확히 같은 출력을 맞추는 비용 때문에 속도가 줄어듦 - 주장하는 숫자가 꽤 세다. GPT-2 토크나이저 기준으로 HuggingFace 대비 거의 1000배까지 나옴 - 144코어 AMD EPYC 9565 듀얼 소켓에서 GPT-2는 24.53GB/s를 기록함 - 같은 조건에서 HuggingFace Tokenizers는 24.8MB/s, tiktoken은 36.0MB/s였음 - 배율로 보면 HuggingFace 대비 989배, tiktoken 대비 681배임 > [!IMPORTANT] > EPYC 기준 처리량이면 Common Crawl 전체로 자주 간주되는 130조 토큰 규모도 6.5시간 안쪽에 토크나이즈할 수 있다고 함. 전처리가 학습 일정보다 느려지는 팀이면 눈이 갈 수밖에 없는 수치임. ## CPU별 벤치마크도 꽤 넓게 제시함 - 144코어 EPYC에선 BPE 계열 대부분이 20GB/s 안팎을 찍음 - Phi-4는 24.00GB/s, GPT-OSS는 23.96GB/s, OLMo 2/3은 23.06GB/s였음 - Llama 3 계열은 22.15GB/s, DeepSeek V3/R1/V4 계열은 19.69GB/s를 기록함 - Qwen 3.5/3.6은 15.49GB/s로 상대적으로 낮지만, HuggingFace 대비 558배였음 - Apple M4 Max에서도 숫자가 만만치 않음 - GPT-2는 8.79GB/s로 HuggingFace 대비 1,268배, tiktoken 대비 140배였음 - OLMo 2/3은 7.56GB/s로 HuggingFace 대비 1,299배가 나옴 - Llama 3 계열은 7.60GB/s, DeepSeek V3/R1/V4는 5.68GB/s였음 - 데스크톱급 Ryzen 7 9800X3D에서도 GB/s 단위 처리량을 유지함 - GPT-2는 6.27GB/s, Phi-4는 6.09GB/s, OLMo 2/3은 6.06GB/s였음 - GPT-OSS는 5.68GB/s로 HuggingFace 대비 71배, tiktoken 대비 50배였음 - 대형 서버가 아니어도 데이터 전처리 반복 속도를 꽤 줄일 수 있다는 얘기임 ## 왜 이렇게 빠른가 - 핵심은 보통 정규식 엔진에 맡기는 pretokenization을 직접 최적화한 것임 - 텍스트를 토큰화하기 전 후보 조각으로 나누는 단계에서 SIMD를 적극 사용함 - 분기 줄이기, 캐시 최적화, 스레드 간 통신 최소화 같은 저수준 최적화도 들어감 - 이미 본 단어 조각을 다시 빠르게 찾는 캐싱도 큰 역할을 함 - 토크나이징에선 같은 pretoken이 반복해서 등장하므로, 인코딩 결과를 캐시하면 이득이 큼 - 다만 pretoken 분포는 롱테일이고 캐시가 빨리 커져서, 단순한 캐시 전략으로는 메모리와 성능을 같이 잡기 어려움 - Python과의 상호작용을 줄인 것도 중요함 - Gigatoken API는 Rust 구현이 데이터를 직접 읽고 최대한 병렬 처리함 - Python 자료구조를 넘기면 그 자체로 읽기 오버헤드가 생기므로, 큰 입력을 Rust 쪽에서 직접 다루는 게 유리함 ```mermaid sequenceDiagram participant 사용자코드 participant 파이썬API participant 러스트엔진 participant SIMD처리 participant 토큰캐시 사용자코드->>파이썬API: 텍스트 또는 파일 입력 파이썬API->>러스트엔진: 최소 변환으로 작업 전달 러스트엔진->>SIMD처리: pretokenization 병렬 처리 러스트엔진->>토큰캐시: 반복 pretoken 인코딩 조회 토큰캐시-->>러스트엔진: 기존 토큰 결과 반환 러스트엔진-->>사용자코드: 토큰 시퀀스 반환 ``` ## 호환성과 한계도 있음 - HuggingFace 호환 모드는 정확도에 신경 쓴 대신 최고 속도는 덜 나옴 - 작성자는 HuggingFace Tokenizers와 같은 설정에서 출력이 정확히 맞도록 상당한 노력을 넣었다고 설명함 - 그래도 전반적으로 훨씬 빠르지만, Gigatoken API에서 보는 1000배급 수치를 그대로 기대하긴 어렵다고 못박음 - SentencePiece 기반 토크나이저는 아직 덜 최적화돼 있음 - Gemma 4는 EPYC에서 4.82GB/s로 HuggingFace 대비 14배였고, Gemma 3은 3.43GB/s로 9.6배였음 - Mistral 7B v0.3, CodeLlama, TinyLlama/Phi-3 같은 행도 10배 안팎으로, BPE 계열의 수백 배와는 차이가 큼 - 작성자는 SentencePiece 계열은 주로 구글 모델이나 BERT 스타일 모델에서 쓰여 우선순위가 낮다고 설명함 - 아직 비어 있는 부분도 분명함 - WordPiece는 지원하지 않음 - File sink는 Gigatoken API에 아직 구현되지 않음 - Windows는 충분히 테스트되지 않아 당장은 WSL을 권장함 - Python 확장은 ABI3를 쓰는데, 향후 Python 버전별 CPython API 특화로 오버헤드 병목 케이스에서 2배 개선 가능성을 봄 ## 실무적으로 어디에 꽂히나 - 대규모 학습 데이터 전처리에서 바로 의미가 있음 - OWT 11.9GB 파일을 기준으로 측정했고, CommonCrawl에서 추출한 텍스트와 대략 비슷한 성격이라고 봄 - 사내에서 모델 학습, 파인튜닝, 데이터 필터링을 여러 번 돌리는 팀이면 토크나이저 속도가 전체 반복 주기를 줄일 수 있음 - 모델별 토크나이저 매핑도 실용적으로 정리돼 있음 - Llama 3 계열에는 Llama 3/3.1/3.2와 여러 파인튜닝 모델이 묶임 - Qwen 2/2.5, Qwen 3, DeepSeek V3/R1/V4, GLM 4/5, Kimi K2, Gemma 3/4 같은 최신 계열도 포함됨 - 자기 모델명이 표에 없어도 같은 vocab, merges, pretokenizer를 쓰면 해당 행 성능에 가까울 가능성이 있음 --- ## 기술 맥락 - Gigatoken이 건드린 지점은 모델 추론이 아니라 데이터 파이프라인 앞단이에요. LLM 학습이나 대규모 평가를 하면 텍스트를 토큰으로 바꾸는 일이 계속 반복되는데, 데이터가 커질수록 이 단계도 그냥 유틸 함수가 아니라 비용 중심이 되거든요. - 자체 API가 더 빠른 이유는 Python을 덜 거치기 때문이에요. Python 객체를 반복해서 넘기면 아무리 Rust 내부가 빨라도 경계 비용이 생기는데, 파일이나 큰 버퍼를 Rust 쪽에서 직접 읽으면 병렬화와 캐싱을 훨씬 공격적으로 할 수 있어요. - SIMD 최적화가 중요한 이유는 pretokenization이 결국 텍스트를 빠르게 훑는 작업이기 때문이에요. 공백, 기호, 문자 패턴을 대량으로 검사하는데, 이걸 정규식 엔진에 맡기는 대신 CPU 벡터 명령에 맞춰 직접 짜면 GB/s 단위 처리량을 노릴 수 있어요. - 그래도 모든 토크나이저가 똑같이 빨라지는 건 아니에요. BPE 계열은 큰 폭으로 빨라졌지만 SentencePiece 계열은 상대적으로 덜 최적화됐고, WordPiece는 아직 지원도 안 해요. 그래서 도입 전에 우리 모델의 토크나이저 계열이 표의 어느 행에 가까운지 먼저 확인하는 게 좋아요. - 호환 모드와 자체 API의 선택도 트레이드오프예요. 기존 HuggingFace 코드에 바로 끼우려면 호환 모드가 편하지만 최고 성능은 포기해야 하고, 전처리 파이프라인을 새로 짤 수 있으면 Gigatoken API로 데이터를 직접 밀어 넣는 쪽이 더 큰 이득을 줄 수 있어요. ## 핵심 포인트 - Gigatoken API를 쓰면 Python 오버헤드를 최대한 건너뛰고 Rust 구현이 데이터를 직접 읽어 병렬 처리함 - 144코어 EPYC에서 여러 BPE 계열 토크나이저가 20GB/s 안팎 처리량을 보였고 GPT-2는 24.53GB/s를 기록함 - Apple M4 Max에서도 GPT-2 8.79GB/s, HuggingFace 대비 1,268배 수치를 냈음 - SentencePiece 기반 토크나이저, WordPiece, Windows 지원은 아직 약하거나 미완성임 ## 인사이트 LLM 학습 파이프라인에서 토크나이징은 화려하진 않지만 데이터 규모가 커질수록 바로 돈과 시간으로 튀어나오는 병목임. Gigatoken의 수치가 재현된다면, 대규모 전처리나 반복 실험을 많이 하는 팀에겐 꽤 실용적인 도구가 될 수 있음.