LLM 서빙 시스템은 프롬프트 KV 상태를 캐싱하지만, 대부분의 프런트엔드는 여전히 매 호출마다 전체 요청 텍스트를 다시 토큰화 (re-tokenize) 합니다. 이 비용은 코딩 에이전트 (coding agents)에게 전가되는데, 이들은 작은 도구 결과가 나올 때마다 긴 트랜스크립트를 다시 제출하며, 짧은 추가(append)만으로도 이전 시퀀스 끝부분 근처의 토큰 경계 (token boundaries)가 바뀔 수 있어 재사용이 어렵습니다. 두 개의 에이전트 생태계에서 발생한 153,951회의 호출을 분석한 결과, 중간값 기준 호출 시 약 1.4K 자가 추가되었으며, 수백만 자의 컨텍스트로 세션을 시작하거나 재구축하는 호출은 단 1.0~3.6%에 불과했습니다. 94.1%의 플릿 프롬프트 캐시 적중률 (fleet prompt-cache hit rate) 상황에서도, 토큰화 (tokenization) 과정이 첫 번째 토큰 생성 시간 (time to first token)의 최대 64%를 차지합니다.

TokTier는 하나의 계약을 가진 상태 유지 토큰화 (stateful tokenization) 서비스입니다: 생성된 토큰 ID는 항상 요청 텍스트의 전체 참조 토큰화 (full reference tokenization) 결과와 동일해야 합니다. 세션 지속 (session continuation)을 위해, TokTier는 추가된 부분 주변의 작은 윈도우 (window)를 다시 토큰화하고, 요청별 안정적 경계 (stable-boundary) 확인 후에만 결합(splice)하며, 실패 시 윈도우를 넓히거나 전체 토큰화로 전환합니다. 재사용 가능한 접두사 (reusable prefix)가 없는 호출의 경우, GPT 계열의 정규식 사전 토큰화 (regex pre-tokenization)를 실행 로컬 규칙 (run-local rules)으로 분해하고 GPU에서 정확한 사전 토큰화 및 BPE를 실행합니다. 샘플링된 섀도우 검증기 (shadow verifier)가 라이브 트래픽을 재검증합니다.

17개의 토크나이저 (tokenizer) 제품군에 대해, 차등 캠페인 (differential campaigns)을 통해 1.5x10^10회의 분할 확인, 12.4 TB의 실제 텍스트 코퍼스(corpus), 그리고 93,000회 이상의 재현된 에이전트 단계를 수행하였으며, 편차(divergence)는 0을 기록했습니다. 증분 수리 (Incremental repair)는 100K에서 3M 자까지 0.51.1 ms가 소요되어, HF 토큰화보다 최대 437배 빠르며, 완전히 예열된(prewarmed) 가장 강력한 캐시 기반 베이스라인(Gigatoken)보다 1M 자 기준 2.1배 빠릅니다. GPU 전체 토큰화는 1M 자 요청을 0.87 ms 내에 인코딩하며, 이는 HF보다 최대 491배, 가장 빠른 공개 CPU 방식보다 23.4배 빠릅니다. vLLM과 함께 사용할 경우, 중간값 기준 첫 번째 토큰 생성 시간 (time to first token)은 1634% 감소하며, 기록된 버스트(bursts) 상황에서 P99는 23% 감소합니다. 50 ms P99 목표 하에서, 4개의 수리 코어와 1개의 GPU는 1,821 requests/s를 유지하는 반면, 16코어 상태 비저장(stateless) 프런트엔드는 40에서 포화(saturate)됩니다.