기존 언어 모델 대비 최대 1000배 빠른 고속 토큰화 기술 'GigaToken' 등장

토큰 사용량 확인, 토큰 한도 초과 방지, 요청 배치 처리 등에 유용함. OpenAI API처럼 입출력 토큰 수를 계산할 때도 사용될 수 있음.

잠깐, 하이퍼 최적화된 게 유용한지 아닌지가 왜 중요함? 흥미로운 문제를 컴퓨터가 빠르게 처리한다는 그 자체로 이미 목표 달성임!

그렇다면 그 최적화들이 토큰화 속도에 제한을 받는 거임?

작성자임: 내 경우는 주로 사전 학습 실험인데, 데이터셋을 토큰 단위로 나누고 처리하는 데 며칠씩 CPU를 돌림. 오픈 소스 추론 엔진에서는 KV 캐시를 조회하기 전에 토큰화를 수행하는데, 이 때 토큰화 속도가 TTFT에 큰 영향을 미침. 오픈 소스 엔진들에서 왜 이렇게 하는지 다들 잘 알 거임.

사전 로딩 시점에 요청에 따라 토큰화할 수는 없나?

무시하려는 의도는 아니었음. 유용한 시나리오가 많을 거라고 생각함.

아주 좋음, 감사.

사전 학습 데이터는 GPU 계산 낭비를 막기 위해 미리 토큰화해 두는 게 일반적임. 데이터 파이프라인 효율을 높여주는 건 확실함.

차트를 한참 들여다봤음. 진짜 머리가 멍해질 정도로 대단한 작업을 해냈네.

멋지지만 토큰화는 일반적으로 전체 추론 시간의 0.1% 미만을 차지함. 물론 토큰화만 필요한 어플리케이션도 많으니 그런 쪽에는 아주 좋을 듯!

무시하려는 의도로 들리지 않았음. 어디에 이런 최적화가 도움이 되는지 궁금했고 다들 답변을 잘 해줘서 새로운 사용 사례를 많이 알게 됐음.

LLM 학습하려면 먼저 토큰화해야 함. GPU 학습과 병렬로 할 수 있긴 한데, 토큰화에만 10~15분씩 기다리다가 버그 때문에 크래시 나면 정말 허탈함.

꽤 훌륭한 소프트웨어네.

매번 실시간으로 임베딩해야 하는 상황에서 토큰화가 CPU 시간의 99%를 차지했던 적이 있음. 기본 토크나이저의 O(n^2) 알고리즘을 개선하는 것만으로도 엄청난 효과를 본 적이 있음.

와, 이번 주 최고의 릴리즈임.

토큰화 이후에는 패딩이나 잘림 문제가 생겨서 학습 시 데이터 셔플링이 어려워짐. 실무에서는 보통 분리된 단계에서 토큰화를 수행함.

흥미로운 프로젝트임! 호환성 모드에 대한 벤치마크도 있음, 아니면 모든 숫자가 GigaToken API 기준임?

현재 수치는 GigaToken API 기준임. 호환성 모드는 파이썬 오버헤드 때문에 성능 차이가 좀 있지만 여전히 200~300배 빠른 성능을 기대할 수 있음.

호환성 모드 벤치마크는 나중에 추가할 예정임. 아직 파이썬 인터럽트 최적화할 여지가 좀 더 남았거든.

0.001%로 줄이는 건 언제나 좋은 일이지.

추론 연산의 1/1000은 규모의 경제 관점에서는 절대 무시할 수 없는 작업량임. 가트너가 2026년 추론 비용을 280억 달러로 추산했으니 이건 연간 2800만 달러 규모의 작업임.

양질의 소프트웨어임.

AI 플랫폼을 운영 중인데 라우팅이나 속도 제한 등 다음 단계를 결정하려면 토큰화를 빠르고 일찍 끝내야 함. 전체 요청 시간에서 큰 비중은 아닐지라도 매우 효율적으로 처리하는 게 중요함.

실제 GPU 클러스터에서는 CPU가 원래 놀고 있는 경우가 많아서 실질적인 효율은 1000배까지는 아닐 수 있음.

이제 궁금한 건, 추론 파이프라인의 다른 부분들에도 1000배 최적화 기회가 얼마나 더 숨어있을까 하는 거네.

내 댓글 수정했음. 0.1%가 이 맥락에서는 결코 작은 숫자가 아니라는 점을 강조하고 싶었음.

비대해진 파이썬 코드는 다 러스트로 다시 짜야 세상이 더 좋아질 텐데. 참고로 난 러스트 옹호자임!

1년 전만 해도 이런 제안을 하면 미친 사람 취급받았을 텐데, 지금은 다들 '오 괜찮은 아이디어네'라며 수용하는 분위기임.

비교 대상인 기존 라이브러리들도 러스트 기반 파이썬 바인딩인데, LLM 활용 등으로 성능을 더 뽑아낸 건 대단함.

오픈 소스 엔진들이 캐시 조회를 위해 토큰화를 필수로 하는지 궁금함. 해시 기반으로 소스 텍스트를 조회해도 되잖아? 그럼 토큰화와 병렬로 캐시 조회를 할 수 있을 텐데. 모바일에서 토큰화 속도를 높이는 건 에너지 절약 측면에서 정말 좋을 것 같음.

모든 러스트 코드를 파이썬으로 다시 짜야 함. 기술적인 이유가 아니라 그냥 러스트 광신도들이 지겨워져서임.

첫 토큰 생성 시간(TTFT)은 특히 작은 모델들에서 크게 줄어들 수 있음. 지연 시간(Latency)은 전체 처리량(Throughput)만큼이나 중요함. Groq이나 Cerebras 같은 추론 제공 업체들한테는 특히 더.

토큰화는 첫 토큰 생성 때나 마지막 토큰 생성 때나 똑같이 전체의 0.1% 수준임.

추론의 다른 부분들은 코드 수정이 옳은지 그른지 즉각 확인하기 어렵지만 토큰화 레이어는 확인이 쉽다는 점이 다름.

추론 시간의 더 중요한 부분들에 이미 훨씬 많은 노력이 투입되었을 거라고 확신함.

해결할 과제가 너무 많음! 연구할 부분도 많고 앞으로 풀릴 잠재력이 상당함.

총 런타임의 0.1%를 차지하는 작업을 1000배 빠르게 만들려고 공을 들이는 건 진짜 개발자다운 행동이야.

실무적으로는 Hugging Face 모델들이 이걸 채택하기를 기다려야 하나? 지금 내 하니스 토크나이저는 API 호출 시 토큰화되니까 추정치일 뿐인데.

워크플로우에 따라 다름. 텍스트를 즉시 모델에 넣지 않는 토큰화 사용 사례들도 분명 존재함.

"탁월함을 추구하는 데에 정당성은 필요 없다."

웃기긴 한데, 이렇게 쉽게 최적화가 된다면 왜 안 하겠음?

성능(performance)이 아니라 지연 시간(latency) 관점에서 봐야 함. 사람들은 이걸 자주 혼동함. 지연 시간이 중요한 경로를 최적화하는 게 핵심임.

첫 토큰 생성 시간(TTFT)은 입력 전체를 처리하는 시간까지 포함함. 사전 학습(prefill) 중에는 토큰당 GPU 시간 소모가 훨씬 적어서 상대적으로 토큰화의 중요도가 더 높음.

멋진 작업임. 내 이해로는 추론 시점보다는 오프라인 사전 학습 데이터 준비 시 더 가치 있어 보임. 테라바이트 단위의 텍스트를 토큰화할 때는 이런 속도 향상이 시간과 비용을 실질적으로 절약해 줄 것임.

선형 대수 쪽 변경은 정확성 검증은 쉽지만, 50년 동안 쌓인 최적화와 경쟁해야 해서 먹을 게 별로 없음.

다른 건 200~300배라 modest한데, 이건 1000배니 modest하지 않음. 잘했음.

캐시 히트 여부를 따질 때 토큰 경계를 알아야 함. vLLM 같은 곳은 프리픽스 트리로 쪼개는데 토큰 수를 기준으로 슬라이스해야 해서 토큰화가 캐시 조회보다 먼저 수행되어야 함.

나도 AI 플랫폼 운영 중인데, 궁금한 점이 너무 많아서 어디서부터 물어봐야 할지 모르겠네.

llama-server 같은 곳에서 기존 토크나이저를 이걸로 대체하는 테스트 데이터가 있음?

하나만 골라 봐. 듣고 싶음.

BERT 기반 시스템을 운영했었는데 시스템은 초당 기가바이트를 처리하는 반면 토큰화가 초당 몇 메가바이트밖에 안 돼서 전체 병목이 됐음. 추론보다 비용은 낮아도 전체 시간의 10% 이상을 차지했었음.

전체 런타임의 0.1% 절약은 전 지구적으로 따지면 연간 50GWh임. 미국 가구 4,700곳이 소비하는 전력량과 맞먹는 수치임.

예전에 100ms 걸리던 워드 클라우드 생성기를 16ms로 줄인 적이 있음. 세상이 그렇게 빠른 게 필요하냐고? 아니. 내가 원하냐고? 응. 필요 없어도 최대한 빠르게 만드는 게 내 철학임.

데이터 계산 중임.

나도 공감함. 요청과 예산 사이에서 UX(TTFT)를 10~100ms 줄이는 건 매우 중요함.

토큰 대신 텍스트 청크 트리로 걷으면서 토큰 경계를 나중에 찾는 방식으로도 해결할 수 있지 않나? 난 여전히 왜 안 되는지 궁금함.

라우팅 용도로 작은 SLM을 돌리기 위해 토큰화한다면 0.1%보다 훨씬 큰 비중을 차지함. 이건 '데스크탑 PC가 노는 시간이 많으니 GPU 드라이버 최적화는 의미 없다'고 말하는 것과 같은 생각임.

작성자임: 사실 추론 방식에 따라 상당히 유의미할 수 있음. B200에서 8B Qwen3 모델 돌렸을 때 첫 토큰 생성 시간(TTFT) 결과임. 모델이 작고 GPU가 빠를수록 이 수치는 더 중요해짐. 테스트 결과 입력 길이가 길수록 5~10% 정도 TTFT가 줄어드는 효과가 있었음. 아직 초기 데이터라 더 테스트가 필요함.

여기에 수치 추가했음: [링크]

입력이 고정되어 있으면 출력 결과가 같은지 비교해서 코드 수정의 정확성을 확인하는 건 합리적임.

딱 우리가 필요하던 거임! 바로 테스트해 볼 예정. README에서 코어별 성능을 더 강조하면 좋겠음. 알고리즘 관련해서 완벽한 해시 테이블 매칭 방식도 도움이 될까?

이건 보급형 하드웨어에서 로컬 모델을 돌릴 때 엄청난 차이를 만들 수 있음.

지연 시간이 성능이 아니라고? '처리량(Throughput)이 중요한 게 아니다'라고 말하고 싶은 거임?

분명히 Kilotoken이라고 불렀어야지.

1000배 개선은 설령 하위 컴포넌트에 적용되더라도 질적으로 새로운 기능을 가능하게 함. 0.1%라는 수치는 프로젝트 전체를 그렇게 대우하기 때문에 나오는 수치일 뿐임. 또 누가 알겠음? 진짜 빠른 토큰화가 다른 부분에서 사람들이 불가능하다고 생각했던 새로운 기능들을 가능하게 할지.

우리 같은 게으른 사람들을 위해, 단일 아키텍처와 단일 CPU 코어에서도 이 정도 속도를 내게 한 핵심 기술 몇 가지만 알려줄 수 있음?

리틀의 법칙(Little’s law)에 따르면 지연 시간이 단축되면 처리량도 늘어나지 않나? 같은 수의 코어가 작업을 절반의 시간에 끝낼 수 있다면 처리량은 2배가 되는 거 아님?

환상적인 작업임. 토크나이저 디스코드에서 보고 리포지토리 클론함. 프리토큰화를 위해 Regex를 캐싱하고 교체한 아이디어는 매우 유용함. 0.1% 타령하는 사람들 신경 쓰지 마, 정말 대단한 결과물이야.

토큰화가 10ms, 나머지가 50ms라면 토큰화 개선은 TTFT에는 도움 되지만 처리량에는 큰 영향이 없음. 첫 토큰 이후에는 추론 시간이 토큰화 시간을 완전히 덮어버리니까.

나도 같은 반응임. 멋진 작업이야! 추론뿐 아니라 학습 데이터 준비에도 매우 가치 있음. 게다가 혼자서 이걸 다 해냈다는 게 인상적임. 한 사람의 힘이 세상을 바꿀 수 있군.

토큰화는 에이전트 스택에서 가장 저평가되고 최적화되지 않은 부분임. 모든 하드웨어 환경에서 생산용으로 적합한지는 모르겠지만, 이런 작업이 향후 연구에 큰 영감을 줄 것임.

지연 시간도 성능의 한 종류임. 전체 리소스 사용량과는 별개의 최적화 대상이지. 성능은 에너지, 공간, 안정성, 단순함, 인간적 요인 등 다양한 차원을 포함함.