GigaToken - 언어 모델 토큰화를 약 1,000배 가속

 (github.com/marcelroed)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 다양한 CPU와 널리 쓰이는 토크나이저를 지원하며, 텍스트를 GB/s 단위로 처리하는 Tiktoken 과 HuggingFace Tokenizers 대체 도구
  • 정규식 엔진이 맡던 사전 토큰화를 SIMD로 최적화하고 분기·스레드 통신·Python 상호작용을 줄이며, 이전에 본 단어의 토큰 매핑을 효율적으로 캐싱함
  • 11.9GB OpenWebText 벤치마크에서 GPT-2 처리량은 AMD EPYC 9565에서 24.53GB/s, Apple M4 Max에서 8.79GB/s, Ryzen 7 9800X3D에서 6.27GB/s를 기록함
  • HuggingFace·Tiktoken 호환 모드는 기존 코드를 거의 그대로 유지하지만 출력 일치 비용으로 성능이 낮아지며, Rust가 파일을 직접 읽는 Gigatoken API가 최대 병렬성과 최고 속도를 제공함
  • WordPiece와 파일 출력은 아직 지원하지 않고 SentencePiece 최적화와 Windows 검증도 부족해, 현재는 BPE 토크나이저와 Linux·macOS 또는 WSL 환경에 더 적합함

지원 범위와 사용 방식

  • Gigatoken은 언어 모델용 고속 토크나이저로, 현대적인 x86·ARM CPU와 거의 모든 일반적인 토크나이저를 대상으로 함
  • pip install gigatoken으로 설치하며 자체 API와 HuggingFace Tokenizers·Tiktoken 호환 모드를 제공함
  • 호환 모드는 기존 토크나이저를 감싸 각각 .as_hf() 또는 .as_tiktoken()으로 변환함
    • HuggingFace Tokenizers와 출력이 정확히 일치하도록 상당한 작업을 적용함
    • 호환성 처리에는 무시하기 어려운 성능 비용이 있어 자체 API의 약 1,000배 가속에는 미치지 못하지만, 전반적으로 기존 구현보다 빠름
  • 자체 API는 "Qwen/Qwen3-8B" 같은 HuggingFace 모델 이름과 TextFileSource를 받아 파일을 직접 인코딩함
    • Rust 구현이 데이터를 직접 읽어 불필요한 오버헤드를 건너뛰고 병렬성을 극대화함
    • Python 자료구조를 전달하면 Python에서 데이터를 읽는 비용이 남음

속도를 높이는 구현

  • 가장 큰 개선은 보통 정규식 엔진에 맡기는 사전 토큰화를 SIMD 기반으로 직접 고도화한 데서 나옴
  • 분기를 최소화하고, 이미 본 단어의 인코딩 토큰을 찾는 사전 토큰 매핑 캐시를 집중적으로 최적화함
    • 캐시는 빠르게 커지고 사전 토큰 분포가 긴 꼬리 형태여서 다루기 어려움
  • Python과의 상호작용 및 스레드 사이 통신을 줄여 추가 성능을 확보함
  • 특정 CPU나 토크나이저 하나에 맞춘 구현이 아니라 현대적인 x86·ARM CPU와 여러 토크나이저 조합을 각각 최적화했으며, 결과도 CPU와 토크나이저 전반에서 일관적임

11.9GB OpenWebText 벤치마크

  • AMD EPYC 9565 144코어 환경의 GPT-2 처리량은 24.53GB/s로, HuggingFace Tokenizers의 24.8MB/s보다 989배, Tiktoken의 36.0MB/s보다 681배 빠름
    • 주요 BPE 계열은 대체로 약 15.49~24.00GB/s를 기록함
    • SentencePiece 기반 항목은 약 2.51~4.82GB/s로 상대적으로 느림
  • Apple M4 Max 16코어에서 GPT-2는 8.79GB/s로 HuggingFace 대비 1,268배, Tiktoken 대비 140배임
    • OLMo 2/3는 HuggingFace 대비 1,299배, Qwen 2/2.5는 1,105배를 기록함
  • AMD Ryzen 7 9800X3D 16코어에서 GPT-2는 6.27GB/s로 HuggingFace 대비 106배, Tiktoken 대비 68배임
    • 주요 BPE 계열은 약 4.21~6.09GB/s, 상대적으로 덜 최적화된 계열은 약 1.12~2.84GB/s임

측정 조건과 해석

  • OWT(OpenWebText)는 Common Crawl 문서를 추출한 뒤 얻는 텍스트를 대략 대표해 벤치마크 데이터로 선택됨
  • Gigatoken은 전체 파일을 미리 나누지 않고 처리하므로 분할 경계 탐색과 자동 병렬화까지 직접 수행함
  • 비교 대상은 <|endoftext|> 기준으로 미리 분할된 데이터를 처리함
    • HuggingFace encode_batch_fast는 첫 100MB를 사용함
    • Tiktoken encode_ordinary_batch는 첫 1GB를 사용함
    • 두 구현 모두 캐싱하지 않아 처리 과정의 속도가 대체로 일정하므로 이 비교 조건을 사용함
  • Tiktoken 결과는 공식 지원 토크나이저에만 포함됨
  • 각 행은 어휘·병합·사전 토크나이저가 동일한 하나의 고유 토크나이저를 대표함
    • Llama, Qwen, DeepSeek, GLM, Nemotron, Kimi, Phi, Gemma 계열의 여러 버전과 파생 모델이 같은 토크나이저 행에 묶임
  • 가장 느린 항목은 Gigatoken에서 아직 충분히 최적화되지 않은 SentencePiece 기반 토크나이저임

지원 여부 검증과 대규모 처리

  • 설치 없이 uvx --with tokenizers gigatoken bench 명령으로 HuggingFace 모델 저장소의 토큰화를 검증하고 시간을 측정할 수 있음
  • GPT-2 검증 예시에서는 20,401개 문서의 출력이 일치함
    • Apple M4 Max에서 11,920.51MB를 1.432초, 8,327.05MB/s로 처리해 HuggingFace보다 1,353.13배 빨랐음
    • AMD EPYC 9565에서 같은 데이터를 0.486초, 24,532.45MB/s로 처리해 989.21배 빨랐음
  • EPYC 처리율이라면 130조 토큰 규모의 Common Crawl 전체를 6.5시간 미만에 토큰화할 수 있음
  • 예시는 Stanford CS336 OWT 샘플을 사용하며, CLI는 기본적으로 검증과 HuggingFace 비교에 파일의 첫 100MB를 이용함
  • macOS의 첫 실행은 보안 검사 때문에 Rust 코드가 느려질 수 있어 정확한 측정을 위해 명령을 두 번 실행해야 할 수 있음
  • 출력 불일치나 느린 사례는 GitHub Issue로 보고하도록 요청함

알려진 제약

  • Python 반복 처리는 Rust에서 수행하지만 내부 CPython 버전별 API보다 느린 ABI3를 사용함
    • Python 버전별 특화를 계획하고 있으며 초기 실험에서는 오버헤드 지배 사례가 2배 빨라짐
  • Gigatoken API에는 아직 파일 출력 싱크가 구현되지 않음
  • WordPiece는 지원하지 않음
  • SentencePiece 기반 토큰화는 일반적인 BPE보다 최적화 수준이 낮음
    • 주로 Google 모델과 BERT 계열이 사용한다는 이유로 현재 우선순위도 낮음
  • Windows 테스트가 충분하지 않아 현재는 WSL 사용을 권장함

AI 사용 범위

  • 코드베이스 대부분은 AI 없이 직접 작성했으며, 프로젝트 Git 기록에서 이를 확인할 수 있음
  • 프로젝트 최종 단계에서는 AI를 다음 작업에 활용함
    • 사용자용 API 구현
    • 더 많은 토크나이저를 위한 사전 토크나이저 일반화·이식과 호환성 확대
    • 패딩, 잘라내기, Unicode 정규화 지원
    • AVX512·AVX2·NEON 사이의 SIMD 전략 이식
    • 분기 제거와 사전 토큰 캐시 계층 개선을 통한 마지막 약 4배 성능 향상
    • 리팩터링과 코드 재사용 개선

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “코드 대부분은 AI 없이 직접 작성했으며 Git 기록에서도 확인 가능하다”니, 인간 프로그래밍은 끝났다는 선언이 무색해짐

  • 특정 CPU와 토크나이저 하나가 아니라 최신 x86·ARM과 여러 토크나이저 조합 전체를 과도하게 최적화해 일관된 성능을 얻은 것임
    보통 정규식 엔진에 맡기는 사전 토큰화를 SIMD로 직접 최적화하고 분기를 최소화했으며, 이미 본 단어의 인코딩 결과를 빠르게 찾도록 사전 토큰 매핑 캐시도 개선함. 이 분야의 캐시는 빠르게 커지고 분포의 꼬리가 길어 다루기 까다로움
    Python과의 상호작용 및 스레드 간 통신도 최소화함

  • 창의적인 프로그래밍으로 믿기 어려운 속도를 내는 simdjson이 떠오름. 널리 쓰이면 전력·비용·탄소 배출을 크게 줄일 수 있으니 Rust 크레이트도 배포하면 좋겠고, 필요하면 직접 돕고 싶음

    • 토큰화가 의미 있는 병목이었던 적은 거의 없으며, JSON 직렬화도 대체로 마찬가지임. 직렬화와 토큰화보다 입출력과 저장장치에 훨씬 많은 에너지를 씀
      경제성과 환경을 생각한다면 요청 일괄 처리가 더 큰 효과를 냄. 가장 비싼 문제는 GPU 활용률 저하이며, 작업을 일괄 처리 형태에 맞추면 현재 OAI에서도 50%를 절약할 수 있음. 모든 답변이 즉시 필요하지 않다면 일부는 며칠 기다려도 되고, 도구 호출은 시간 초과되지 않으며 LLM 자체에는 벽시계 시간이 존재하지 않음

  • 저장소를 복제해 살펴봤는데, 사전 토큰화 정규식 대체와 캐시 최적화는 일반적으로도 유용한 접근임. 토큰화 커뮤니티 전체가 이런 속도 향상의 비결을 배우고 싶어 할 만큼 훌륭한 작업임

    • 조만간 프로젝트의 기술 해설과 논문, 발표 영상을 만들어 Discord에도 공유할 예정임
    • 추론뿐 아니라 독점 데이터셋을 활용한 훈련에도 가치가 크며, 이 모든 것을 한 사람이 해냈다는 점도 인상적임

  • 멋진 성과지만 토큰화는 보통 전체 추론 시간의 0.1% 미만임. 다만 토큰화 자체가 필요한 응용에는 매우 유용할 것임

    • 추론 방식에 따라 토큰화 비중도 상당해질 수 있음. 단일 B200에서 8B Qwen3를 실행한 초기 측정에서는 gigatoken으로 바꿨을 때 첫 토큰 생성 시간(TTFT) 이 입력 길이 2,048에서 평균 5.5%, 8,192에서 8.4%, 32,768에서 7.8% 감소함
      작은 모델이나 더 빠른 GPU일수록 효과가 커지며, README에 넣기 전 추가 검증이 필요함. 벤치마크 출처는 fastokens임
    • AI 플랫폼에서는 이후의 라우팅·속도 제한 등을 결정하려고 요청 초기에 빠르게 토큰화해야 함. 전체 요청 시간에서 차지하는 비율이 작아도 효율이 중요함
    • 토큰화는 대부분 직렬 처리되므로, 초기 프롬프트가 크면 입력 처리 시간에서 큰 비중을 차지할 수 있음. 모델 추론으로 넘긴 뒤에는 모든 토큰을 병렬 처리할 수 있기 때문임
    • 추론 연산의 1/1,000도 규모가 커지면 무시하기 어려움. Gartner가 2026년 추론 지출을 약 280억 달러로 추산했으므로, 앞선 가정을 적용하면 연간 2,800만 달러 규모임
      출처: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...
    • 특히 작은 모델에서는 첫 토큰 생성 지연 시간을 크게 줄일 수 있음. Groq나 Cerebras 같은 추론 제공자에게는 전체 처리량만큼 지연 시간도 중요함

  • 추론 시점보다 오프라인 사전 훈련 데이터 준비에서 더 유용해 보임. 훈련 말뭉치로 수 테라바이트의 텍스트를 토큰화할 때 시간과 비용을 절약하고, 데이터셋을 조정하는 반복 주기도 단축할 수 있음

  • 전체 실행 시간의 0.1%를 차지하는 부분을 1,000배 빠르게 만들려고 공학 역량을 쏟는 모습이야말로 가장 소프트웨어 개발자다운 행동임

    • Rust로 고해상도 단어 구름을 약 100ms에 만들었고, 추가 최적화로 약 16ms까지 줄였음. 세상에 이렇게 빠른 단어 구름 생성기가 필요하진 않지만, 만들 거라면 가능한 한 빨라야 함
    • “탁월함의 추구에는 정당화가 필요하지 않음”
      https://x.com/mitchellh/status/2074225453217505494
    • 작업 흐름에 따라 달라짐. 텍스트를 곧바로 모델에 넣지 않고 토큰화만 수행하는 용도도 존재함
    • 하위 구성 요소라도 1,000배 개선되면 질적으로 새로운 기능이 가능해짐. 그 부분이 전체의 0.1%에 불과한 이유도 프로젝트 전반에서 “전체 성능에 영향이 없는데 왜 제대로 만들까”라는 태도를 반복한 결과일 때가 많음
      LLM은 1,000배 개선 한계에 훨씬 가깝지만, 기본 PyTorch 연산도 단순 재작성보다 2배 느린 경우가 흔하고 더 나은 스케줄링 알고리즘은 5~10배 향상을 내기도 함. 빠른 토큰화가 지금까지 실현 불가능해 무시됐던 다른 기능을 열 수도 있음
    • 라우팅용 초소형 언어 모델(SLM)을 실행하려고 토큰화한다면 비중이 0.1%보다 훨씬 커질 수 있음. 이는 “PC가 대부분 바탕화면에서 놀고 있으니 GPU 드라이버 최적화는 중요하지 않다”는 사고방식과 같음

  • 그래프의 수치를 이해하려고 한참 바라봐야 할 만큼 믿기 어려운 성능임

  • ClickHouse에도 정확히 필요한 기능이라 https://github.com/ClickHouse/ClickHouse/issues/108247에서 시험해 볼 예정임
    README가 코어당 성능을 더 강조하면 좋겠으며, 실제 알고리즘에는 완전 해시 테이블 매칭이 도움이 될지 궁금함

  • 그렇다면 추론 파이프라인의 다른 부분에는 아직도 1,000배 최적화 기회가 얼마나 남아 있을지 궁금해짐

    • 토큰화 계층과 달리 추론의 다른 변경은 정확성 여부를 단순 판정하기 어려움
    • 그런 부분은 많으며, 거의 모든 구성 요소에 전담 팀과 연구가 붙어 있음. 앞으로도 큰 돌파구가 다수 나올 가능성이 큼
    • 추론 시간에서 더 큰 비중을 차지하는 부분에는 이미 훨씬 많은 최적화 노력이 투입됐을 것임
답변달기