quicktok: tiktoken 대비 11배 속도, 저자 단독 보고, README 없음

quicktok이라는 새로운 오픈소스 프로젝트는 OpenAI의 tiktoken과 토큰 단위로 완전히 동일한 결과를 내면서도 몇 배 빠르게 동작한다고 주장합니다. 그 비결은 알고리즘을 바꾼 게 아니라, 대부분의 사람들이 간과하는 파이프라인 구간을 집중적으로 최적화한 데 있습니다. 바로 프리토크나이저입니다.

quicktok의 SIMD 프리토크나이저, 정규식 엔진을 대체하다

quicktok은 외부 의존성 없이 동작하는 C++20 BPE 토크나이저로, Maturin을 통해 Python 바인딩을 제공합니다. 범용 바이트 쌍 인코딩을 재구현하는 대신 OpenAI의 특정 토크나이제이션 파이프라인을 수작업으로 최적화하는 데 집중했습니다 . 핵심 설계 전략은 원시 텍스트를 프리토큰으로 분할하는 범용 정규식 엔진을 고정된 cl100k 및 o200k 분할 패턴을 기반으로 손수 작성한 SIMD 스캐너로 대체하는 것입니다 . 이 정규식들은 런타임에 변하지 않으므로, 작성자는 이를 상수로 취급하여 매번 정규식 VM에 넘기는 대신 벡터화된 바이트 스캐너로 전환했습니다.

프리토크나이저에는 반복 작업을 줄이기 위한 여러 보조 최적화가 포함되어 있습니다:

• CJK를 위한 2-바이트 트라이 + 제로 룩업 직접 테이블: 한중일 바이트 시퀀스를 해시 탐색 없이 바로 처리합니다 .
• 17비트 토큰 ID를 위한 밀집 "메모" 유효성 캐시 (~2 MB): 반복 등장하는 시퀀스가 BPE 병합 조회를 매번 수행하지 않도록 합니다 .
• ASCII 경로에 대한 단일 패스 "프로덕트 머신": 일반적인 케이스를 한 번의 스캔으로 처리합니다 .

바뀌지 않는 것은 병합 로직 자체입니다. 인코딩 단계는 여전히 정확한 백트래킹 BPE를 수행하며(근사치가 아닙니다), 출력 토큰 ID는 tiktoken과 "비슷한" 수준이 아니라 완전히 동일하게 맞추는 것을 목표로 합니다 . 이 차이가 이 프로젝트의 핵심 주장입니다. 속도 향상은 더 빠른 프론트엔드(프리토크나이제이션과 캐시 재사용)에서 비롯되며, 알고리즘적으로 중요한 백엔드는 그대로 유지됩니다. 이것이 사실이라면, "더 빠른 토크나이저"에 흔히 따르는 정확도 손실 없이 동일한 결과를 더 빠르게 얻을 수 있습니다.

이 라이브러리는 OpenAI의 cl100k_base, o200k_base, o200k_harmony를 지원하며, 오픈 모델 어휘도 포함합니다: Llama-3, Qwen2.5/3, 그리고 게이트된 Llama-4 세트 . 바이트 동일성 보장은 SIMD 스캐너가 작성된 고정 분할 패턴의 대상인 OpenAI 계열에서 가장 강력합니다. 이 동등성이 실제로 유지되는지, 그리고 속도가 작성자의 환경 외에서도 통하는지는 이후 분석에서 검증합니다.

바이트 동등성 보장과 단 하나의 주의사항

quicktok의 핵심 약속은 정확성입니다, 근사치가 아닙니다. OpenAI의 cl100k_base 및 o200k_base 계열에 대해 tiktoken과 바이트 단위로 동일한 토큰 ID를 출력하며, 인코딩 단계는 더 빠른 휴리스틱이 아닌 정확한 백트래킹 BPE를 그대로 수행합니다 . 이 주장은 코드로 강제됩니다. 임포트 시점에 자가 테스트를 수행하여 토큰 하나라도 불일치하면 로드를 거부하므로, 동등성은 README의 선언이 아니라 런타임에서 실시간으로 검증됩니다 . 이는 "믿어 달라"는 벤치마크보다 강한 입장입니다. 포팅이 어긋나면 패키지는 조용히 틀린 값을 반환하는 대신 아예 로드에 실패합니다.

작성자 본인도 한 가지 주의사항을 인정합니다. 일부 포팅된 오픈 모델(비 OpenAI) 인코딩은 약 99.9998%의 일치율을 보이며, 나머지 불일치는 드문 랭크 대 병합 분할 케이스에서 발생합니다 . 따라서 바이트 동일성 보장은 SIMD 스캐너가 목표로 삼은 고정 분할 패턴을 사용하는 핵심 OpenAI cl100k/o200k 인코딩에서 가장 확실하고, 그 위에 추가된 오픈 모델 어휘에서는 가장 약합니다.

대부분의 개발자 워크플로에서 실질적인 영향은 제한적이며 대체로 긍정적입니다. OpenAI 모델 대상의 컨텍스트 윈도우 확인 및 API 비용 추정은 정확한 인코딩 출력과 올바른 모델-인코딩 매핑에 의존합니다. 현재 gpt-5, gpt-4.1, gpt-4o, o1, o3, o4-mini는 o200k_base로, GPT-4/GPT-3.5는 cl100k_base로 라우팅됩니다 . quicktok이 이 부분에서 일치한다면 토큰 계산도 일치합니다. 다만 파이프라인에 비 OpenAI 어휘가 포함된 경우, 카운트를 신뢰하기 전에 별도로 동등성을 검증해야 합니다.

한 가지 관점상 주의할 점이 있습니다. 신뢰할 수 있는 바이트 동일성 주장은 깔끔한 산문에 대한 .encode() 그 이상을 포괄해야 합니다. 모델-인코딩 매핑 재현, 특수 토큰 처리, 디코딩 시맨틱, UTF-8 경계 동작, 오류 및 배치 API 동작도 모두 포함되어야 합니다 . 자가 테스트는 안심을 주지만, 실제로 사용하는 tiktoken 버전을 기준으로 이러한 케이스들을 직접 테스트하는 것을 대체할 수는 없습니다.

검증 근거의 부재: README도, 재현 가능한 방법론도 없다

공개된 패키지에는 해당 주장을 뒷받침할 근거가 없다. PyPI에서 quicktok의 최신 릴리스는 0.2.0으로, 2026년 1월 6일에 업로드되었으며, 이전 버전 0.1.0/0.1.1은 2024년 2월에 배포되었다. 관리자는 krzysztofwos, Python >=3.8 지원, CPython/PyPy/Rust 분류자가 포함되어 있지만 프로젝트 설명은 전혀 없다 . 해당 페이지의 단일 저장소 링크는 quicktok 전용 저장소가 아닌 openai/tiktoken으로 연결된다 . 결국 공식 설치 경로가 자신이 능가한다고 주장하는 기준 구현체로 독자를 안내하는 셈이다.

메타데이터가 확인해 주는 것은 공급망 보안이지, 동등성이 아니다. 16.7 kB sdist에는 SHA256 해시값(0482ae1a…a648bd8)이 기록되어 있으며, 아티팩트는 Trusted Publishing 방식을 통해 Maturin 1.11.2로 배포되었다 . 이는 깔끔하고 검증 가능한 빌드 파이프라인이다. 그러나 토큰 ID가 tiktoken과 일치하는지, MB/s 수치가 실제로 유효한지에 대해서는 아무것도 말해 주지 않는다. 출처 검증과 정확성 검증은 별개의 문제이며, 여기서 답이 제시된 것은 첫 번째뿐이다.

모든 성능 및 동등성 수치는 저자가 직접 관리하는 두 곳의 출처, 즉 GitHub README와 Hugging Face Forums 공지로 귀결된다 . 제3자 재현 결과, 공개 CI 실행 기록, 배포된 sdist 내 벤치마크 스크립트는 발견되지 않았다. 가장 많이 인용되는 결과(The Pile에서 cl100k_base 기준 quicktok 92.8 MB/s 대 tiktoken 12.6 MB/s)는 단지 Apple M1, 단일 스레드라는 조건만 명시되어 있다 . tiktoken 버전, Python 버전, 운영체제가 명시되지 않아 이 수치를 재현하려면 그 공백을 직접 채워야 한다.

인접 연구들은 정확히 이 기준을 충족한다. 예를 들어 Peek2는 단순한 헤드라인 수치 하나 대신 알고리즘, 데이터셋, 기준선, 명시된 한계를 모두 공개한다 . 더 빠른 BPE 토크나이제이션에 관한 OpenAI 엔지니어링 글에서 지적하듯, 속도 주장은 버전과 워크로드가 명시될 때만 의미가 있다:

"tiktoken 0.2.0은 유사한 오픈소스 토크나이저보다 3–6배 빠릅니다" — GitHub Engineering, tokenizers==0.13.2 및 transformers==4.24.0 기준으로 1GB 텍스트에서 벤치마크 측정 (source: GitHub Blog).

이 문장은 버전, 비교 대상, 코퍼스 크기를 명시한다. quicktok의 공개 기록은 그렇지 않으며, 이로 인해 해당 수치는 제3자의 독립적인 재실행이 있기 전까지 저자 보고 단일 머신 데이터에 머문다.

보고된 MB/s 수치와 그 배경 조건

헤드라인 수치는 The Pile에서 cl100k_base를 대상으로 한 Apple M1 단일 스레드 실행 결과로, quicktok은 92.8 MB/s, tiktoken Python 바인딩은 12.6 MB/s(약 7.4배)로 보고되었다 . 같은 실행에서 Rust 비교 대상들은 그 사이에 위치한다: bpe-openai 29.8 MB/s, tiktoken-rs 13.6 MB/s, 별도 프로젝트 TokenDagger는 9.7 MB/s . 즉 7배 수치는 Python tiktoken을 기준으로 한 것이며, 네이티브 Rust 토크나이저와 비교하면 격차는 약 3배로 좁혀진다.

단일 수치 뒤에는 넓은 분포가 숨어 있다. 세 가지 25 MB 코퍼스(The Pile, 코드, Common Crawl)에서 quicktok은 55.6~114.9 MB/s로 보고되며, 코퍼스에 따라 bpe-openai 대비 2–3.4배, Python tiktoken 대비 3.5–11배로 요약된다 . 코드와 자연어 텍스트는 토크나이제이션 속도가 다르므로, 빌더는 최고 수치를 보편적 보장이 아닌 특정 워크로드에 한정된 결과로 봐야 한다.

코퍼스보다 더 중요한 조건이 하나 있다: 빌드 방식이다. 이식성 높은 PyPI 휠은 bpe-openai보다 1.1–1.6배 빠른 것으로만 보고되며 , 극적인 배율은 대상 CPU용으로 컴파일된 네이티브 빌드에 의존한다. 소스 빌드 없이 단순히 pip install만 하면 헤드라인이 시사하는 것보다 훨씬 작은 성능 차이를 얻게 되는데, SIMD 스캐너가 효과를 발휘하려면 호스트의 명령어 세트가 필요하기 때문이다.

배치 경로는 별도로 프로파일링되었으며 훨씬 높은 수치를 보인다: 8코어 네이티브에서 약 706 MB/s, Python encode_batch를 통해 약 550 MB/s(tiktoken 배치 API 대비 약 24배로 제시), encode_to_numpy()는 Python에서 네이티브에 근접한 ~92 MB/s . 이것들은 오버헤드가 각기 다른 별개의 코드 경로이며, 단일 호출·배치·NumPy 출력 각각을 파이프라인 설계의 기준으로 삼기 전에 독립적으로 측정해야 한다.

tiktoken 0.13.0과 계속 바뀌는 기준선

"tiktoken보다 ×배 빠르다"는 수치는 어떤 버전의 tiktoken을 기준으로 측정했느냐에 따라 달라지는데, 그 기준선은 계속 움직이고 있습니다. 현재 PyPI 최신 릴리스인 0.13.0(2026년 5월 15일)은 "성능을 대폭 향상"시키기 위해 fancy-regex를 업데이트했고, 비정상적인 입력의 느린 처리를 수정하기 위해 BPE 동작도 변경했습니다 . 따라서 이전 빌드를 기준으로 한 벤치마크는, 대부분의 팀이 현재 pip install로 받는 버전보다 느린 참조점을 대상으로 비교한 셈입니다 .

이 흐름은 단 하나의 릴리스에 그치지 않습니다. tiktoken 공식 changelog에는 v0.3.0(+5–20%), v0.6.0(정규식 최적화로 약 +20% 추가), v0.7.0(GPT-4o 지원), v0.12.0(자유 스레드 지원 Python 3.14 휠 및 GPT-5 인식)이 차례로 기록되어 있습니다 . 누적된 속도 향상을 여러 차례 출시한 라이브러리를 대상으로 하면, 날짜가 명시되지 않은 "vs tiktoken" 비교는 어느 버전을 기준으로 했는지 알 수 없어 해석이 모호해집니다. quicktok이 제시한 3.5–11×라는 범위도 서로 다른 기준 버전에 걸쳐 있을 가능성이 높고, 버전이 고정되지 않으면 독자는 어느 버전 대비 수치인지 파악할 수 없습니다.

정확성도 고정된 목표가 아닙니다. 드롭인 교체재는 .encode() 출력만이 아니라 tiktoken의 모델-인코딩 해석 방식 전체를 정확히 재현해야 합니다. 현재 매핑 기준으로는 gpt-5, gpt-4.1, gpt-4o, o1, o3, o4-mini가 o200k_base로, 구형 GPT-4 및 GPT-3.5 계열이 cl100k_base로, gpt-oss-* 모델이 o200k_harmony로 연결됩니다 .

이 해석 레이어가 중요한 이유는, 인코딩마다 동일한 문자열을 다르게 분할하여 토큰 수와 API 비용 추정치가 달라지기 때문입니다 . .encode() 출력은 바이트 단위로 동일하더라도 모델 이름을 잘못된 인코딩으로 해석하는 라이브러리는, 컨텍스트 윈도우 적합성을 조용히 잘못 계산하고 비용을 잘못 추정하게 됩니다—예외조차 발생하지 않는 실패입니다. 동등성을 검증할 때는 tiktoken 버전을 고정하고, 원시 인코딩 출력만이 아니라 encoding_for_model() 전체 경로를 테스트하십시오.

직접 하드웨어에서 주장된 성능 재현하기

quicktok의 모든 수치를 이어받을 결과가 아니라 재검증할 가설로 취급하십시오. 공개된 수치는 단일 머신에서 작성자가 직접 측정한 것이므로, 의사결정에 실제로 의미 있는 비율은 여러분이 실제로 배포하는 tiktoken 휠을, 여러분의 코퍼스와 CPU에서 직접 측정한 값입니다. 먼저 기준선을 고정하십시오. tiktoken v0.13.0 릴리스(2026년 5월 15일 )는 성능 향상을 위해 fancy-regex를 업데이트하고 비정상 입력 처리를 수정하는 BPE 동작 변경을 포함했으므로 , 이전 휠 대비로 산출된 속도 향상 비율은 현재 버전에서는 그대로 적용되지 않을 수 있습니다.

정확한 비교 조건을 명시해야 한다는 요구사항은 새로운 것이 아닙니다. tiktoken 공식 README는 역사적으로 버전 0.2.0이 비슷한 GPT-2 토크나이저보다 3–6배 빠르다고 주장했지만, tokenizers==0.13.2와 transformers==4.24.0을 사용하고 1 GB 텍스트를 대상으로 했다는 단서가 붙어 있었습니다 :

"tiktoken은 유사한 오픈소스 토크나이저보다 3–6배 빠릅니다": 공개된 수치는 항상 특정 고정 버전과 1 GB 워크로드에 묶여 있었습니다 (source: GitHub Engineering).

그런 다음 실제 텍스트를 입력하는 방식에 맞게 테스트를 구성하십시오:

• The Pile이 아닌 자체 코퍼스를 사용하십시오. 보고된 3.5–11× 범위는 대규모 영어 중심 코퍼스에서 도출된 것이며 , 코드 중심 입력과 2,000 토큰 미만의 짧은 시퀀스는 실질적으로 다른 비율을 보입니다.
• 대표적인 샘플로 토큰 ID 동일성을 검증하십시오: UTF-8 경계 케이스, 특수 토큰(BOS/EOS/pad), 최대 컨텍스트 시퀀스. 라이브러리의 엄격한 임포트 자가 테스트는 내부 코퍼스를 검증할 뿐, 여러분의 코퍼스를 검증하지 않습니다.
• encode()와 encode_batch()를 별도로 프로파일링하십시오. 약 24배의 배치 수치는 단일 스레드 비율과 코드 경로가 다르며 , 이 둘을 혼동하면 겉보기 비교치가 부풀려지는 흔한 원인이 됩니다.

프로덕션 경로에서 모델 이름을 해석한다면, 원시 인코딩만이 아니라 전체 encoding_for_model 매핑을 검증하십시오. 여기서 조용히 발생하는 오차는 예외를 일으키지 않습니다.

경쟁 프로젝트 비교: GPUTOK, Peek2, 점진적 BPE

2026년에 동료 심사를 거친 토크나이저 프로젝트 세 개는 신뢰할 수 있는 속도 주장이 어떤 모습이어야 하는지 잘 보여주며, quicktok과의 대비도 시사하는 바가 크다. 이 프로젝트들은 각자 데이터셋을 명시하고, 하드웨어를 밝히며, 버전이 고정된 기준선을 제시하고, 성능이 떨어지는 구간까지 선언한다. GPUTOK(2026년 3월 3일 제출)은 131K 토큰 WikiText103 시퀀스에서 tiktoken 대비 약 1.67배(53.4 ms 대 598.1 ms)를 보고하지만, 약 2,000 토큰 미만에서는 tiktoken보다 명시적으로 느리다 . 언제 사용하지 말아야 할지를 정확히 알려주는 것이다.

Peek2(2026년 1월 9일 제출; ACL SRW 2026)는 다른 목표를 택한다. cl100k 방식의 정규식 프리토크나이저를 선형 시간 알고리즘으로 대체해 마이크로벤치마크에서 2.48배, 엔드투엔드에서 1.14배를 달성하면서도 테스트된 모든 입력에서 정규식 기준선과 동일한 출력을 낸다 . 이는 quicktok의 SIMD 스캐너가 공략하는 것과 같은 프리토크나이제이션 병목이지만, Peek2는 동등성 검사와 엔드투엔드 수치를 공개한다. 엔드투엔드 수치는 통상 마이크로벤치마크보다 훨씬 낮다.

점진적 BPE 토크나이제이션(2026년 5월 29일 제출; ICML 2026 Spotlight)은 바이트당 최악의 경우를 O(log²t)로 한정하고 병리적인 긴 입력을 대상으로 하며, 단일 헤드라인 비율 대신 명시적인 시퀀스 길이 조건을 제시하며 tiktoken 대비 지연 시간 감소를 보고한다 .

이 패턴이 바로 골격이다. 명명된 코퍼스, 선언된 하드웨어, 버전이 명시된 비교, 그리고 공개된 실패 구간. quicktok이 보고한 수치는 충분히 유효할 수 있지만(접근법 자체는 타당하고 동등성 검사도 엄격하다), 현재 공개된 기록에는 그 골격이 없어 검증의 부담은 사용자 몫이다. 구체적인 시사점은 이렇다. quicktok을 검증된 결과가 아닌 유망한 후보로 다뤄라. 정확한 tiktoken 버전을 고정하고, 자신의 인코딩에 대해 엄격한 임포트 검사를 실행하며, 속도 향상이 프로덕션에 반영되기 전에 직접 코퍼스에서 단일 스레드와 배치 경로를 별도로 벤치마크하라.

자주 묻는 질문

지금 당장 quicktok을 프로덕션 파이프라인에 교체해도 안전한가요?

직접 검증 없이는 그렇지 않습니다. quicktok은 토큰 하나라도 불일치하면 로드를 거부하는 엄격한 임포트 시점 자체 테스트를 탑재하고 있어, OpenAI cl100k_base 및 o200k_base 계열에 대한 프로그래밍적 동등성 보장을 제공한다 . 하지만 어떤 독립적인 기관도 동등성이나 속도 주장을 재현하지 않았으며, PyPI 패키지(최신 버전 0.2.0, 2026년 1월 6일)에는 README나 벤치마크 보고서가 없다 . 비용에 민감하거나 컨텍스트 윈도우에 민감한 워크로드를 이전하기 전에, 대표 샘플에서 정확한 tiktoken 버전 대비 토큰 ID 비교를 실행하라.

BPE 토크나이저에서 '바이트 동일'이란 무엇을 의미하나요?

동일한 입력 바이트에 대해 출력 토큰 ID가 참조 구현과 동일한 정수 시퀀스임을 의미하며, 근사치가 아닌 정확히 일치한다는 뜻이다. quicktok의 인코딩 단계는 여전히 근사가 아닌 정확한 역추적 BPE를 수행하므로, ID는 tiktoken의 것과 동일해야 한다 . 이 정밀도가 중요한 이유는 토큰 수가 입력이 모델의 컨텍스트 윈도우에 맞는지 여부와 API 호출 비용을 결정하기 때문이다. ID가 하나라도 다르면 이 계산이 달라진다 . 저자는 한 가지 주의사항을 언급한다. 포팅된 일부 비OpenAI 인코딩은 드문 분할 케이스에서 ~99.9998%의 일치율만 보이므로, 깔끔한 보장은 cl100k/o200k에서 가장 강하다 .

quicktok PyPI 페이지가 자체 저장소 대신 openai/tiktoken으로 연결되는 이유는 무엇인가요?

이는 업로드 시점에 설정된 메타데이터 오류일 가능성이 높다. quicktok 0.2.0의 PyPI 목록에는 프로젝트 설명이 없으며, 유일하게 표시된 저장소 링크는 quicktok 전용 트리가 아닌 openai/tiktoken으로 연결된다 . wheel과 16.7 kB sdist는 Trusted Publishing을 통해 maturin/1.11.2로 업로드되었으며, 이는 업로드 출처를 검증하지만 의미적 동등성이나 속도에 대해서는 아무것도 말하지 않는다 . 실질적 결과는 이렇다. PyPI 방문자는 패키지 페이지에서 프로젝트 자체 코드나 문서로 가는 직접적인 경로가 없다.

네이티브 빌드는 이식 가능한 PyPI 휠보다 얼마나 빠른가요?

헤드라인 성능 향상은 소스에서 컴파일하는 것에 달려 있다. 저자가 보고한 수치에 따르면 이식 가능한 PyPI 휠은 bpe-openai(Rust) 대비 ~1.1–1.6배에 불과하며, tiktoken 대비 3.5–11배의 수치는 대상 CPU 아키텍처에 맞게 조정된 네이티브 빌드가 필요하다 . 따라서 소스 빌드 없이 pip install만 하면 발표에서 시사하는 것보다 훨씬 작은 성능 차이가 나온다. 하드웨어에 맞게 빌드할 수 없다면, 네이티브 수치가 그대로 적용된다고 가정하지 말고 이식 가능한 휠을 직접 벤치마크하라.

quicktok은 tiktoken-rs, bpe-openai와 어떻게 다른가요?

세 프로젝트는 서로 다른 범용성 절충안을 취한다. tiktoken-rs는 tiktoken의 기본 로직을 감싼 Rust 래퍼이고, bpe-openai는 GitHub의 2024/2025 Rust 토크나이저이다 . quicktok은 대신 특정 고정된 cl100k/o200k 정규식 패턴에 대한 SIMD 스캐너를 처음부터 수동 컴파일하고, 2바이트 트라이와 밀집 유효성 캐시를 추가해, 해당 특정 어휘에 대한 처리량을 위해 범용성을 희생한다 . 저자가 The Pile에서 cl100k_base로 Apple M1 단일 스레드를 실행한 결과, quicktok은 92.8 MB/s를 기록한 반면 bpe-openai는 29.8, tiktoken-rs는 13.6, tiktoken(Python)은 12.6이었다 . 이 수치들은 여전히 저자 보고 기준의 단일 머신 결과다.