Skip to content

Build1 publisher2 min readPublished

Routing on the prompt's first tokens cut AWS's median time to first token by up to 77 percent

SageMaker Inference now sends requests that begin with the same tokens to the same instance. On AWS's seven-node Llama 3.1 70B benchmark that lifted the KV cache hit rate from roughly 25 percent to 82 percent.

The Engineer · Build desk

Illustration accompanying Routing on the prompt's first tokens cut AWS's median time to first token by up to 77 percent

What happened

  • Amazon SageMaker Inference added prefix-aware routing, which reads the beginning of each request payload and keeps requests sharing an opening on the same instance so that instance's KV cache stays warm.
  • AWS benchmarked it against the random routing baseline on Llama 3.1 70B Instruct across seven ml.p5.48xlarge instances running vLLM with prefix caching enabled.
  • With 8,000-token shared prefixes sustained for an hour, the KV cache hit rate went from roughly 25 percent to 82 percent and throughput rose 15 to 16 percent.
  • On variable-length ShareGPT-style conversations run for 30 minutes, the same router moved throughput by 1.7 to 2.0 percent and P50 time to first token by 13 to 16 percent.
  • Two safeguards ship with it: a configurable concurrency limit that diverts requests away from a saturated instance, and scale events that shift only a small fraction of traffic rather than invalidating caches.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • capability Teams get cache affinity without building a consistent-hashing proxy in front of the fleet, because the endpoint picks the instance from request content and needs no client-side tagging or affinity bookkeeping.
  • decision Prompt template order is now a routing decision. Any per-request string stamped above the shared block gives every request a different beginning, and middleware that prepends session IDs or timestamps will undo the affinity.
  • exposure The workload with the best cache locality has the least predictable tail: when the instance serving your busiest prefix reaches the concurrency limit you set, those users are the ones sent to a cold instance.

Convert the cache numbers into misses, because misses are what the prefill hardware sees. Under random routing three requests in four recomputed the prefix from scratch; with affinity fewer than one in five do, a 76 percent cut in redundant prefill [15]. The median time-to-first-token reduction AWS reports on that same run, 71 to 77 percent, tracks it closely [7].

Fleet size sets the ceiling on that. Under random routing a request reaches the instance that last served its prefix roughly one time in N: about 14 percent across the seven instances AWS used, and 50 percent across two [16]. The smaller the fleet, the less redundant prefill there is to remove, and this benchmark ran on seven.

The tail moved less than the median. P90 TTFT fell 33 to 37 percent against P50's 71 to 77 percent, so the median improved about twice as much as the tail [17]. Overload protection accounts for part of that by design: when the instance holding a popular prefix reaches the concurrency limit, the endpoint sends the request to a less busy instance and eats the miss [11]. You configure that limit, so you also configure how often the endpoint throws away a hit.

For the long-context figures to transfer, you need an 8,000-token prefix genuinely shared across requests and sustained for an hour, vLLM with prefix caching switched on, and something like Llama 3.1 70B Instruct on p5 hardware [5][7]. AWS published its own control case. On variable-length ShareGPT-style conversations the throughput gain came out about eight times smaller than on the long-context run [18], and AWS attributes the gap to prefix length, since a longer shared prefix means more computation skipped per hit [14].

So the number that predicts your result is the share of prompt tokens that is identical across requests. In the worked example AWS uses, a 3,000-token instruction block sits above a 50-token customer question, which puts 98 percent of the prompt in the shared part [19]. Few production prompts are that lopsided once conversation history and retrieved documents start varying per user.

Routing keeps the whole prefix and pays for it once per instance instead of once per request. Whether that beats deleting tokens is not something this benchmark measures: every latency figure in the post is P50 or P90 time to first token, with no end-to-end latency and no comparison against prompt compression or trimming [20]. The post also does not say how many leading tokens of the payload the endpoint reads to pick an instance [21].

What to watch

  • Whether AWS documents how many leading tokens form the routing key, which decides how much per-request text can safely sit near the top of a prompt.
  • Whether the concurrency limit that triggers overload protection ships with a published default, since the post says only that the customer configures it.
  • Short-context results from a workload with a real shared system prompt instead of ShareGPT-style conversations.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories