# GigaToken - 언어 모델 토큰화를 약 1,000배 가속 > Clean Markdown view of GeekNews topic #31724. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31724](https://news.hada.io/topic?id=31724) - GeekNews Markdown: [https://news.hada.io/topic/31724.md](https://news.hada.io/topic/31724.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-23T15:33:21+09:00 - Updated: 2026-07-23T15:33:21+09:00 - Original source: [github.com/marcelroed](https://github.com/marcelroed/gigatoken/) - Points: 3 - Comments: 1 ## Topic Body - 다양한 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](https://arxiv.org/pdf/2211.04325) 전체를 6.5시간 미만에 토큰화할 수 있음 - 예시는 [Stanford CS336 OWT 샘플](https://huggingface.co/datasets/stanford-cs336/owt-sample)을 사용하며, CLI는 기본적으로 검증과 HuggingFace 비교에 파일의 첫 100MB를 이용함 - macOS의 첫 실행은 보안 검사 때문에 Rust 코드가 느려질 수 있어 정확한 측정을 위해 명령을 두 번 실행해야 할 수 있음 - 출력 불일치나 느린 사례는 [GitHub Issue](https://github.com/marcelroed/gigatoken/issues)로 보고하도록 요청함 ### 알려진 제약 - 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배 성능 향상** - 리팩터링과 코드 재사용 개선 ## Comments ### Comment 62262 - Author: neo - Created: 2026-07-23T15:33:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=49010167) - “코드 대부분은 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](https://github.com/crusoecloud/fastokens)임 - AI 플랫폼에서는 이후의 **라우팅·속도 제한** 등을 결정하려고 요청 초기에 빠르게 토큰화해야 함. 전체 요청 시간에서 차지하는 비율이 작아도 효율이 중요함 - 토큰화는 대부분 직렬 처리되므로, 초기 프롬프트가 크면 입력 처리 시간에서 큰 비중을 차지할 수 있음. 모델 추론으로 넘긴 뒤에는 모든 토큰을 병렬 처리할 수 있기 때문임 - 추론 연산의 1/1,000도 규모가 커지면 무시하기 어려움. Gartner가 2026년 추론 지출을 약 280억 달러로 추산했으므로, 앞선 가정을 적용하면 **연간 2,800만 달러 규모**임 출처: [https://www.gartner.com/en/newsroom/press-releases/2026-07-2...](https://www.gartner.com/en/newsroom/press-releases/2026-07-20-gartner-forecasts-worldwide-ai-platforms-and-models-market-to-grow-63-percent-in-2026) - 특히 작은 모델에서는 **첫 토큰 생성 지연 시간**을 크게 줄일 수 있음. Groq나 Cerebras 같은 추론 제공자에게는 전체 처리량만큼 지연 시간도 중요함 - 추론 시점보다 **오프라인 사전 훈련 데이터 준비**에서 더 유용해 보임. 훈련 말뭉치로 수 테라바이트의 텍스트를 토큰화할 때 시간과 비용을 절약하고, 데이터셋을 조정하는 반복 주기도 단축할 수 있음 - 전체 실행 시간의 0.1%를 차지하는 부분을 **1,000배 빠르게** 만들려고 공학 역량을 쏟는 모습이야말로 가장 소프트웨어 개발자다운 행동임 - Rust로 고해상도 단어 구름을 약 100ms에 만들었고, 추가 최적화로 약 **16ms**까지 줄였음. 세상에 이렇게 빠른 단어 구름 생성기가 필요하진 않지만, 만들 거라면 가능한 한 빨라야 함 - “**탁월함의 추구**에는 정당화가 필요하지 않음” [https://x.com/mitchellh/status/2074225453217505494](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](https://github.com/ClickHouse/ClickHouse/issues/108247)에서 시험해 볼 예정임 README가 **코어당 성능**을 더 강조하면 좋겠으며, 실제 알고리즘에는 완전 해시 테이블 매칭이 도움이 될지 궁금함 - 그렇다면 추론 파이프라인의 다른 부분에는 아직도 **1,000배 최적화 기회**가 얼마나 남아 있을지 궁금해짐 - 토큰화 계층과 달리 추론의 다른 변경은 **정확성 여부를 단순 판정하기 어려움** - 그런 부분은 많으며, 거의 모든 구성 요소에 전담 팀과 연구가 붙어 있음. 앞으로도 큰 돌파구가 다수 나올 가능성이 큼 - 추론 시간에서 더 큰 비중을 차지하는 부분에는 이미 훨씬 많은 최적화 노력이 투입됐을 것임