<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Llm-Inference on Nawinder Pawar</title><link>https://pawar.me/tags/llm-inference/</link><description>Recent content in Llm-Inference on Nawinder Pawar</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sat, 26 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pawar.me/tags/llm-inference/index.xml" rel="self" type="application/rss+xml"/><item><title>How llm-d's Endpoint Picker knows which replica holds your prefix</title><link>https://pawar.me/2026/09/how-endpoint-picker-routes/</link><pubDate>Sat, 26 Sep 2026 00:00:00 +0000</pubDate><guid>https://pawar.me/2026/09/how-endpoint-picker-routes/</guid><description>&lt;p&gt;The first thing that struck me comparing typical HTTP request routing with routing for LLM inference was the importance of KV-cache-aware routing. A model has to build a KV cache entry for every token of the prompt before emitting the first token. On any prompt with non-trivial token count, prefill will dominate time-to-first-token.&lt;/p&gt;
&lt;p&gt;In a typical conversation, each request builds on the previous request; the new prompt starts with the old one. If we can go back to the same replica that served the previous request, we can re-use the existing KV cache blocks and generate only the new ones. If we end up on a new replica, then the whole KV cache has to be generated again.&lt;/p&gt;</description></item></channel></rss>