Tokenizer Caching¶

SMG implements a two-level tokenizer cache that reduces tokenization overhead for repeated content. It applies where the gateway tokenizes prompts itself: requests to gRPC and ZMQ workers, and /v1/tokenize. HTTP workers tokenize on the engine, so the cache doesn't affect their requests.

Overview¶

Why Cache Tokenization?¶

The gateway tokenizes—converts text to token IDs—every request it sends to a gRPC or ZMQ worker. Each tokenization is fast, but the cost grows with prompt length and adds up at scale.

Cache Architecture¶

Each tokenizer SMG loads (from --model-path or --tokenizer-path, or for a gRPC or ZMQ worker's model) gets its own L0 and L1 caches with the configured limits. Tokenizers added through POST /v1/tokenizers are not cached. Decoding is never cached.

Special Token Boundaries (L1)¶

L1 splits inputs right after every special token the tokenizer declares: its BOS, EOS, UNK, SEP, PAD, CLS, and MASK tokens, and every added token marked special. An input without special tokens always misses L1. For example:

Multi-Turn Conversation Example¶

Consider how caching helps a typical chat application:

System: You are a helpful assistant.
User: What is Python?

System: You are a helpful assistant.
User: What is Python?
Assistant: Python is a programming language...
User: How do I install it?

Result: Turn 2 tokenizes only the new messages, not the shared history.

Configuration¶

Model & Tokenizer Paths¶

--model-path¶

HuggingFace model ID or local path to load the tokenizer from.

Usage:

# HuggingFace model ID (downloads automatically)
smg --model-path meta-llama/Llama-3.1-8B-Instruct ...

# Local path to model directory
smg --model-path /models/llama-3.1-8b-instruct ...

# Local path to tokenizer.json file
smg --model-path /models/llama-3.1-8b-instruct/tokenizer.json ...

When pointing to a local directory, SMG looks for a HuggingFace tokenizer.json, a vocab.json plus merges.txt pair, or a tiktoken file (tiktoken.model or *.tiktoken). When pulling from the HuggingFace Hub, SMG additionally falls back to tokenizer_config.json and vocab.json in the downloaded snapshot if a primary tokenizer file is not present.

--tokenizer-path¶

Explicit path to a tokenizer file. Overrides --model-path for tokenizer loading.

When to use:

• When the tokenizer is stored separately from the model
• When using a custom tokenizer with a standard model
• When the model directory structure is non-standard

# Load the tokenizer from its own file (--tokenizer-path wins over --model-path)
smg \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --tokenizer-path /custom/tokenizers/llama3-tokenizer.json \
  ...

Chat Templates¶

Chat templates convert structured messages (system, user, assistant roles) into the prompt format expected by specific models. SMG uses Jinja2 templates, the same format used by HuggingFace Transformers.

--chat-template¶

Path to a Jinja2 chat template file.

Template discovery priority:

1. Explicit --chat-template path (highest priority)
2. chat_template.json in model directory
3. chat_template.jinja in model directory
4. Any .jinja file in model directory
5. chat_template field in tokenizer_config.json

Template Variables¶

Chat templates use Jinja2 syntax with access to:

Keys in a request's chat_template_kwargs are passed to the template as extra variables.

Template Examples¶

{%- for message in messages %}
<|im_start|>{{ message.role }}
{{ message.content }}<|im_end|>
{% endfor %}
{%- if add_generation_prompt %}
<|im_start|>assistant
{% endif %}

<|begin_of_text|>{% for message in messages %}
<|start_header_id|>{{ message.role }}<|end_header_id|>

{{ message.content }}<|eot_id|>
{% endfor %}
{% if add_generation_prompt %}<|start_header_id|>assistant<|end_header_id|>

{% endif %}

L0 Cache Configuration¶

The L0 cache stores complete tokenization results for exact string matches.

L1 Cache Configuration¶

The L1 cache stores tokenization results at special token boundaries.

Memory Planning¶

L0 Cache Sizing¶

L0 is capped by entry count, not bytes. Each entry keeps the full input text and its encoding, so its size grows with the input: small for a short prompt, and roughly 2 MB per entry was observed for large inputs (smg-project/smg#2603). Size --tokenizer-cache-l0-max-entries from the number of distinct whole prompts that actually repeat in your traffic, and watch process memory when you raise it.

L1 Cache Sizing¶

L1 cache is bounded by total memory:

L1 keeps one entry per special-token boundary of each input it sees: the token IDs of the whole prefix up to that boundary. SMG charges each entry the prefix's length in bytes plus 4 bytes per token, so a long multi-turn prompt with many boundaries counts for many times its own length. When a new input's entries would exceed the budget, SMG evicts approximately least recently used entries (sampling 32 at a time) to make room. The budget is an estimate of cache contents, not a cap on process memory.

Recommended Configurations¶

smg \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --tokenizer-cache-enable-l0 \
  --tokenizer-cache-l0-max-entries 50000

smg \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --tokenizer-cache-enable-l0 \
  --tokenizer-cache-l0-max-entries 20000 \
  --tokenizer-cache-enable-l1 \
  --tokenizer-cache-l1-max-memory 104857600

smg \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --tokenizer-cache-enable-l0 \
  --tokenizer-cache-l0-max-entries 5000

smg \
  --model-path meta-llama/Llama-3.1-8B-Instruct
# Caching is disabled by default

Complete Example¶

Production configuration with tokenizer and caching:

smg \
  --worker-urls grpc://worker1:50051 grpc://worker2:50051 \
  --policy cache_aware \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --chat-template /templates/llama3.jinja \
  --tokenizer-cache-enable-l0 \
  --tokenizer-cache-l0-max-entries 25000 \
  --tokenizer-cache-enable-l1 \
  --tokenizer-cache-l1-max-memory 104857600 \
  --host 0.0.0.0 \
  --port 8080

Monitoring & Observability¶

The gateway exports cache activity on its Prometheus /metrics endpoint (smg-project/smg#2603):

The counters are totals across all tokenizers in the process, with no model label, and a disabled layer reports zeros. An L0 hit never reaches L1, and L1 counts inputs without special-token boundaries as misses, so compute each layer's hit ratio against its own lookups:

sum by (layer) (rate(smg_tokenizer_cache_lookups_total{result="hit"}[5m]))
/
sum by (layer) (rate(smg_tokenizer_cache_lookups_total[5m]))

See the Metrics Reference for details.

Sizing Signals to Watch¶

Use these signals when tuning --tokenizer-cache-l0-max-entries and --tokenizer-cache-l1-max-memory:

• A low L0 hit ratio with a steady L0 eviction rate (rate(smg_tokenizer_cache_evictions_total{layer="l0"}[5m])) means more distinct inputs arrive than L0 holds; raise max-entries if the workload repeats inputs at all.
• L1 evictions mean the prefix cache is at its memory bound. Multi-turn chat traffic with growing context benefits from a larger L1 budget; see L1 Cache Sizing.
• smg_tokenizer_cache_reused_bytes_total separates many small prefix hits from reuse of large prompts: a high hit ratio with little reused volume saves little tokenization work.
• Each L0 entry keeps the full input text and its encoding, so entry size grows with prompt length; the out-of-memory investigation that led to these metrics (smg-project/smg#2603) observed entries of roughly 2 MB for large inputs. Watch smg_allocator_allocated_bytes when raising max-entries.

Integration with Other Caching Layers¶

Tokenizer caching is part of SMG's three-level caching strategy:

What's Next?¶