“코드 대부분은 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,000배 개선되면 질적으로 새로운 기능이 가능해짐. 그 부분이 전체의 0.1%에 불과한 이유도 프로젝트 전반에서 “전체 성능에 영향이 없는데 왜 제대로 만들까”라는 태도를 반복한 결과일 때가 많음
LLM은 1,000배 개선 한계에 훨씬 가깝지만, 기본 PyTorch 연산도 단순 재작성보다 2배 느린 경우가 흔하고 더 나은 스케줄링 알고리즘은 5~10배 향상을 내기도 함. 빠른 토큰화가 지금까지 실현 불가능해 무시됐던 다른 기능을 열 수도 있음

라우팅용 초소형 언어 모델(SLM)을 실행하려고 토큰화한다면 비중이 0.1%보다 훨씬 커질 수 있음. 이는 “PC가 대부분 바탕화면에서 놀고 있으니 GPU 드라이버 최적화는 중요하지 않다”는 사고방식과 같음