TokenDagger – OpenAI의 Tiktoken보다 더 빠른 토크나이저

• OpenAI의 TikToken과 100% 호환되는 고성능 토크나이저로, 대규모 텍스트 처리에서 2배 이상 처리량과 4배 빠른 코드 토큰화 속도를 제공함
• PCRE2 기반 고속 정규표현식 파싱 엔진을 통해 토큰 패턴 매칭 속도 극대화
• 간소화된 BPE 알고리듬으로 대용량 스페셜 토큰 처리 시 성능 저하를 최소화
• 실제 벤치마크에서 코드 토큰화가 4배 이상 빠르며, 기존 TikToken 사용 코드를 그대로 교체해 활용 가능함
• Python 3.8+ 지원, PyPI pip install tokendagger 로 간단히 설치 가능하며 PCRE2 의존성을 가짐

[GN⁺]

Hacker News 의견

• 단기간에는 AI/ML 인프라 구조에서 이처럼 C++로 핵심 병목을 해결하는 방식으로 많은 성능 최적화 여지가 있다고 생각함, 전체를 C++로 다시 쓰는 건 아니고 현명한 엔지니어링 트레이드오프가 실제 성능 향상으로 이어지는 경우가 많음, 특히 중국 엔지니어들이 이런 작업을 잘하는 느낌임
  • 내 멘토가 가르쳐 주던 소프트웨어 개발의 관점이 있음: 1단계 일단 동작, 2단계 빠르게, 3단계 예쁘게, 트랜스포머와 LLM들은 이제 꽤 잘 동작하는 단계까지 왔으니, 지금은 성능 향상 쪽에서 가장 큰 진전이 이뤄지는 시기라고 느낌
  • 장기적으로는 Python 중심에서 벗어나는 게 의미 있을 거라 생각함, 단순히 ML 엔지니어들이 익숙해서 쓴다면 미래 지향적이지 않음
  • 실제로 TikToken은 Rust로 작성되어 있어서, 이번 개선이 정말 C++ 이식 덕분인지는 궁금증이 있음
  • 사실 토크나이징이 제일 큰 병목이 아니고 대부분의 계산은 실제 CUDA 커널 실행에서 발생함, Python 오버헤드는 매우 적음(VLLM도 주로 Python으로 작성됨), C++로 다시 쓴다는 건 거의 항상 CUDA 커널을 더 효율적으로 다시 짜는 걸 의미함
• 기존 시스템을 성능을 크게 개선하는 드롭인 교체로 만든다는 게 상당히 아름다운 일이라고 느낌, ScyllaDB가 생각남
  • 실제로 이런 대체제가 아니라면 아무도 사용하지 않을 거라고 생각함
• LLM의 전반적인 성능에서 토크나이저의 중요도가 궁금함, 토크나이저 최적화에 관심이 있는데 실제 측정은 아직 안 해봄, 대부분의 비용이 matmul에 의해 발생하는 것으로 추정했지만, 댓글 반응을 보면 토크나이저가 의미 있어 보임
  • 토크나이징은 보통 CPU에서 처리되고, 트레이닝이나 인퍼런스의 병목이 되는 경우는 드묾, 대부분의 시간은 GPU 커널에서 사용되고 매우 작은 모델만이 예외임, 토크나이저의 지연 시간은 CPU가 다음 배치를 준비하는 방식으로 ‘숨길 수도 있음’
  • 토크나이징 성능은 좀 복잡하지만, 진짜 실력과 자원을 가진 기관들은 매우 빠른 토크나이저를 직접 작성함, SentencePiece와 tiktoken이 대표적으로 복잡도와 배포상의 부담을 감수하고서도 선택됨, 실제 전문가들은 플레임 그래프를 통해 병목을 살핌, 대규모 러닝에서는 미리 토크나이징을 하기도 함, C++이 Rust 내러티브와 달리 다시 부상하는 것에 대한 업계 긴장도 느껴짐, 새로운 이유나 인사이트가 있기를 바람
  • 다른 코멘트들과 마찬가지로 실제로 토크나이저가 병목은 아님, 다만 추론 파이프라인에서 첫 단계라서 먼저 작업한 것임
  • 텍스트 토크나이징은 전체 계산 중에 정말 미미한 비중임, 그렇지만 페타바이트급 데이터 처리에는 조금이라도 더 빠르면 무조건 좋음
• tiktoken에 맞추려면 vocab 포맷 변환이 필요한데, 이 요구도 없어질 수 있으면 쓸 때 더 좋은 완전 호환 드롭인 대체제가 될 것임, 또한 tiktoken 초기화 후 tokendagger를 초기화해서 결과가 같은지 확인할 수 있는 양방향 예제도 있었으면 함
  • 0.1.1 버전부터는 진정한 드롭인 대체제가 됐음, 곧 예제도 추가할 계획임
  • 포인트를 잘 짚어줘서 바로 업데이트함
• 이 프로젝트가 BPE crate와 어떻게 비교되는지도 궁금함, 해당 crate의 강점은 텍스트를 점진적으로 재토크나이징하는 기능이고 tiktoken보다 빠름
  • 다음엔 점진적 재토크나이징 기능을 추가하고, 해당 crate와 벤치마크도 진행할 계획임
• 다른 LLM용으로 로컬 토크나이저를 구할 수 있는 방법이 궁금함, 예를 들어 Gemini는 원격 API만 공개함, 이게 독점적인 건지 아니면 API를 대량 호출해서 토큰 매핑을 추정할 방법이 있는지 궁금함
  • Gemini는 SentencePiece를 쓰고, Gemma와 동일한 토크나이저 vocabulary를 공유함 (참조1, 참조2, 참조3), 대형 랩 중 Claude 3 이상을 쓰는 Anthropic만 로컬 토크나이저가 없음
  • 모델별 토크나이저는 대부분 SentencePiece나 Byte-pair encoding(BPE) 같은 코어 알고리즘을 공유하면서 래퍼 수준에서 특수 토큰 처리 등만 다름, tiktoken과 TokenDagger도 BPE 구현임, 라이브러리 차원에서 모델별 특징을 반영해주면 소폭 성능 향상과 통합이 쉬워짐, 큰 일이 아니니 신모델에 맞추기에도 부담이 적음, 참고 예시는 llama의 tokenizer.py, Mistral 토크나이저
  • Gemini가 SentencePiece를 쓴다고 알고 있었음 SentencePiece
• 예전에 비슷한 걸 시도한 경험이 있음: tokie, 실제로는 토크나이저 러닝 비용 대다수가 프리토크나이징(정규표현식)에서 발생함, 더 빠른 regex 방식을 찾아낸 것 같은데 실제로 regex 엔진만 바꾸고 BPE는 tiktoken 그대로 뒀을 때 성능 변화도 비교해봤는지 궁금함, 만약 그렇다면 upstream 기여도 가능하지 않을까 싶음
  • 멋진 프로젝트임, tiktoken 관리하는 분에게 연락해둠
• Huggingface tokenizers와의 성능 비교도 했으면 좋겠음, tiktoken readme 기준 벤치마크가 너무 오래된 정보임
  • 개인적으로 tiktoken이 huggingface tokenizers보다 항상 더 느렸음, 왜그런지는 아직 tiktoken을 깊게 파보진 않았지만 HF Rust 토크나이저 사용자 입장에서 그렇게 느낌
• tiktoken WASM 바인딩도 보고 싶음, 아니면 js 순수 구현에서 "b"에서 나온 성능 향상도 적용할 수 있을지 궁금함
• 정말 멋진 프로젝트임, 우리도 tiktoken을 쓰고 있는데 드롭인 호환이면서 성능 향상이 된다면 효과가 궁금함, 드롭인 방식 선택이 훌륭함