| ▲ | onlyrealcuzzo 12 hours ago |
| This is awesome, but tokenization is typically <0.1% of total inference time. Presumably there's a host of applications that just need to tokenize, though, and this would be great for those! |
|
| ▲ | marcelroed 7 hours ago | parent | next [-] |
| 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 |
|
| ▲ | scottcha 11 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | jaggederest 10 hours ago | parent | next [-] | | To concur it's "latency critical", not "performance critical", people often confuse those two - optimize it all, but especially the chained critical path latency! | | |
| ▲ | dataflow 6 hours ago | parent [-] | | Latency isn't performance? Maybe you mean "not throughput-critical"? | | |
| ▲ | jaggederest 3 hours ago | parent | next [-] | | 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. | |
| ▲ | rockwotj 5 hours ago | parent | prev [-] | | 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 | | |
| ▲ | scheme271 5 hours ago | parent [-] | | 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. |
|
|
| |
| ▲ | flockonus 7 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | quietfox 8 hours ago | parent | prev [-] | | ‘I run an AI platform’
I have so many genuine questions I don’t even know where to start. | | |
|
|
| ▲ | treyd 25 minutes ago | parent | prev | next [-] |
| 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. |
|
| ▲ | pipsterwo 11 hours ago | parent | prev | next [-] |
| 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... |
| |
| ▲ | boroboro4 11 hours ago | parent [-] | | The issue is it’s cpu compute which is underutilized in gpu clusters anyway, so practically it’s not really 1/1000. | | |
| ▲ | pipsterwo 10 hours ago | parent [-] | | 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 |
|
|
|
| ▲ | noahbp 10 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | fastball 10 hours ago | parent [-] | | Tokenization is <0.1% of the inference time for the first token in the same way it is <0.1% for the last. | | |
| ▲ | marcelroed 9 hours ago | parent [-] | | 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. | | |
|
|
|
| ▲ | GenerocUsername 11 hours ago | parent | prev | next [-] |
| Always good to make it 0.001% |
|
| ▲ | brcmthrowaway 11 hours ago | parent | prev [-] |
| [dead] |
