I run an AI platform and we need to tokenize fast and early to make a lot of decisions on the subsequent steps (things like routing, rate limiting and such). Its really important to do this efficiently even though its not a large % of total end to end time for the request.

To concur it's "latency critical", not "performance critical", people often confuse those two - optimize it all, but especially the chained critical path latency!

Latency isn't performance? Maybe you mean "not throughput-critical"?

Just to clarify, latency is one form of performance, and a separate thing to optimize from total resource usage in more classic "performance critical" situations. That performance might be energy, space, or other dimensions besides latency. It might also be something like reliability, accuracy, precision, or even the very human factors like simplicity, modifiability, and visibility.

Heck, even latency alone you can just reduce the standard deviation and get smoother flows. Little's law is a great callout here too, one of my favorite computer science principles.

but according to Little’s law, if you improve latency, you also improve throughput, right?

If I have the same number of CPU cores and they all can do their work in half the time they can double the number of requests now

I don't think that's accurate. If tokenization takes say 10ms and the rest of the inference steps take 50 ms then, improving tokenization will improve the time to first token but won't affect throughput much. After the first token, the inference steps effectively hide the tokenization time.

It depends on whether or not latency is the constraint of throughput in your circumstances.

‘I run an AI platform’ I have so many genuine questions I don’t even know where to start.

Pick one. I would like to hear it.

Same here, as we're sitting in the middle between requests and what budget constraints are allowed given a particular token allowance there can be 10 ~ 100 milliseconds improvement in the UX (TTFT) given such massive tokenization speed up.

Whats the prefered LLM runtime to use? vLLM?

Tips & Tricks on parameters/settings?

What happens at peak? Do people have to wait now? Increase of latency?

We use vllm as it generally has the best ecosystem support. Parameters are largely dependent on what type of requests you are serving (concurrency, input/output ratios, cached hit patterns). We've never had a limitation at the tokenizer step. Limitations at peak tend to manifest more on slower time in vllm doing prefill or decode though we actively try and minimize this.

1/1000 of inference compute is a non-trivial workload at scale. Gartner estimates ~$28B in inference spend for 2026 making this a $28 million dollar per year workload (edit: based on the assumption above)

Source: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...

The issue is it’s cpu compute which is underutilized in gpu clusters anyway, so practically it’s not really 1/1000.

Totally, edited my comment to specify "based on the assumption above." The main takeaway I was going for was 0.1% is not a small number in this context

Time to first token, especially for smaller models, can be sharply reduced.

Latency can be just as important as overall throughput, especially for inference providers like Groq and Cerebras.

Tokenization is <0.1% of the inference time for the first token in the same way it is <0.1% for the last.

Time to first token refers to the time until the model outputs one token, which includes the time to process the entire prompt (doing prefill). The GPU time per token is much lower when doing prefill, so the significance of tokenization is higher.

Have you done preliminary numbers on replacing tokenizer on, say, llama-server?

Added numbers here: https://news.ycombinator.com/item?id=49015014

Running the numbers now

Always good to make it 0.001%

Author here: Actually, depending on the nature of the inference you're doing it can be quite significant. Here are some numbers for time-to-first-token (time to process the entire input and produce the first token of output) for an 8B Qwen3 model running on a single B200. Obviously these numbers are more significant with smaller models and on faster GPUs. Credit to fastokens [0] for the benchmark.

  sglang_speed [huggingface]: mean=10.31ms median=6.48ms p99=45.98ms rps=96.8
  sglang_speed [gigatoken]: mean=10.13ms median=6.54ms p99=45.16ms rps=98.4

  input_len=  2048: TTFT mean    30.74 ->    29.05 ms (+5.5% reduction) | median    31.00 ->    28.80 (+7.1%) | p99    33.02 ->    32.02 (+3.0%)
  input_len=  8192: TTFT mean   105.20 ->    96.36 ms (+8.4% reduction) | median   103.87 ->    95.49 (+8.1%) | p99   126.88 ->   113.84 (+10.3%)
  input_len= 32768: TTFT mean   687.05 ->   633.66 ms (+7.8% reduction) | median   708.14 ->   657.35 (+7.2%) | p99   728.95 ->   678.79 (+6.9%)

These are preliminary numbers, so I will need to do some more testing before including this in the README.

[0] https://github.com/crusoecloud/fastokens

My understanding is that tokenization is largely serial, so for a large initial prompt it can make up a large chunk of input processing time since after handing it off to the model inference it's (able to be) fully parallel across all tokens.

For small models, tokenization can reach 1-10% of total inference time.