기가토큰, 언어 모델 토크나이징을 최대 1000배 가까이 빠르게 만든 러스트 토크나이저

토크나이징 속도를 정면으로 때린 프로젝트

• 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배임

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 쪽에서 직접 다루는 게 유리함

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로 데이터를 직접 밀어 넣는 쪽이 더 큰 이득을 줄 수 있어요.