<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Nilekh Chaudhari</title><link>https://nilekhc.github.io/</link><description>Recent content on Nilekh Chaudhari</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 28 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://nilekhc.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Napkin math for tensor parallelism</title><link>https://nilekhc.github.io/post/napkin-math-for-tensor-parallelism/</link><pubDate>Tue, 28 Jul 2026 00:00:00 +0000</pubDate><guid>https://nilekhc.github.io/post/napkin-math-for-tensor-parallelism/</guid><description>&lt;p&gt;If I hand you a model that is bigger than any single GPU you own, how do you decide what deployment shape will actually work? Which context length can you realistically serve? How many concurrent users can the memory hold? Which knob do you turn to trade one for the other? These sound like scheduling questions. They aren&amp;rsquo;t. Every one of them resolves to a memory calculation, and every calculation resolves to a handful of numbers you can read out of the model&amp;rsquo;s config file.&lt;/p&gt;</description></item><item><title>The memory that runs the model</title><link>https://nilekhc.github.io/post/memory-that-runs-the-model/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><guid>https://nilekhc.github.io/post/memory-that-runs-the-model/</guid><description>&lt;p&gt;If you&amp;rsquo;d asked me a year ago what limits how fast an LLM can answer, I&amp;rsquo;d have said the same thing you probably would, &amp;ldquo;the GPU.&amp;rdquo; Turns out that&amp;rsquo;s wrong. The GPU is often bored. What actually limits your LLM server is a piece of memory most people have never heard of. Once you see it, you can&amp;rsquo;t unsee it. This is how I learned to see it. And how I built a tool so you can too.&lt;/p&gt;</description></item><item><title>A new notebook</title><link>https://nilekhc.github.io/post/hello/</link><pubDate>Wed, 08 Jul 2026 00:00:00 +0000</pubDate><guid>https://nilekhc.github.io/post/hello/</guid><description>&lt;p&gt;This is the first post on a blog I just spun up. Calling it a &amp;ldquo;blog&amp;rdquo; is probably too generous. It&amp;rsquo;s really a working notebook. I wanted a public place to write down what I learn, and I wanted the writing to force me to actually understand the things I&amp;rsquo;m poking at.&lt;/p&gt;
&lt;h2 id="why-im-writing-this"&gt;Why I&amp;rsquo;m writing this&lt;/h2&gt;
&lt;p&gt;I&amp;rsquo;ve spent years shipping platform code for Kubernetes, service mesh, and distributed systems at planet scale on products such as Azure Kubernetes Service (AKS). Good work, but the ground is shifting, and with the advent of AI and LLMs, new problems are emerging. A lot of what I learned building substrate for one workload class turns out to be relevant to the next one, but not all of it, and the parts that aren&amp;rsquo;t are what I want to write about.&lt;/p&gt;</description></item><item><title>About</title><link>https://nilekhc.github.io/about/</link><pubDate>Wed, 08 Jul 2026 00:00:00 +0000</pubDate><guid>https://nilekhc.github.io/about/</guid><description>&lt;img src="https://github.com/nilekhc.png" alt="Nilekh Chaudhari" width="180" style="border-radius: 50%; display: block; margin: 0 auto 1.5rem;" /&gt;
&lt;p&gt;Hi, I&amp;rsquo;m Nilekh. I&amp;rsquo;m a Senior Software Engineer at Microsoft, specializing in Kubernetes, and working on the security, identity, and networking substrate for Azure Kubernetes Service (AKS). I&amp;rsquo;ve been writing and shipping open-source infrastructure for years, contributing to key upstream Kubernetes areas via SIG Auth and SIG API Machinery, the Secrets Store CSI Driver ecosystem (driver, sync controller, and Azure provider), and the Gatekeeper Library. I&amp;rsquo;m currently an active contributor to Istio.&lt;/p&gt;</description></item></channel></rss>