<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Week 13 - AI Infrastructure Engineering on AI Platform Engineering Handbook</title><link>/docs/week-13/</link><description>Recent content in Week 13 - AI Infrastructure Engineering on AI Platform Engineering Handbook</description><generator>Hugo</generator><language>en</language><copyright>Copyright (c) 2026 Harshhaa</copyright><atom:link href="/docs/week-13/index.xml" rel="self" type="application/rss+xml"/><item><title>Distributed AI Infrastructure</title><link>/docs/week-13/distributed-ai-infrastructure/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-13/distributed-ai-infrastructure/</guid><description>&lt;hr&gt;
&lt;h1 id="distributed-ai-infrastructure"&gt;Distributed AI Infrastructure&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;Everything we&amp;rsquo;ve covered across this whole Week 13 material so far has largely assumed one GPU, or maybe a handful of them, working together on one machine. But the largest, most demanding AI workloads — training a genuinely huge model, or serving a genuinely massive volume of live traffic — routinely require coordinating work across dozens, hundreds, or even thousands of separate machines, each with their own GPUs, all working together as one unified whole. This introduces a genuinely different category of engineering challenge: how do you write code that can actually run across many separate machines at once, how do you reliably keep track of and manage all of that underlying hardware, and how do you make sure the whole system gracefully scales up when demand increases, and scales back down again when it doesn&amp;rsquo;t, all without constant manual intervention. This final section covers the tools and concepts built specifically to solve exactly this class of problem.&lt;/p&gt;</description></item><item><title>GPU Computing Fundamentals</title><link>/docs/week-13/gpu-computing-fundamentals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-13/gpu-computing-fundamentals/</guid><description>&lt;hr&gt;
&lt;h1 id="gpu-computing-fundamentals"&gt;GPU Computing Fundamentals&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;Everything we&amp;rsquo;ve discussed throughout this entire series so far — RAG, agents, LLMOps, security — has assumed that somewhere, underneath all of it, there&amp;rsquo;s actual physical computing hardware doing the real, heavy-lifting work of actually running these models. Week 13 finally opens up that hood and looks at what&amp;rsquo;s actually happening down at the hardware level. Here&amp;rsquo;s the core fact that explains basically everything in this whole explanation: training and running large language models involves doing an absolutely enormous number of relatively simple mathematical calculations (mostly multiplying and adding numbers together, over and over, at truly massive scale), and it turns out that regular computer processors, despite being genuinely powerful and flexible, are actually not the best-suited tool for this particular specific kind of work. A different kind of processor — the GPU — turns out to be dramatically better suited to it. Understanding why is really the foundation for understanding this entire week&amp;rsquo;s material.&lt;/p&gt;</description></item><item><title>Production AI Serving</title><link>/docs/week-13/production-ai-serving/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/week-13/production-ai-serving/</guid><description>&lt;hr&gt;
&lt;h1 id="production-ai-serving"&gt;Production AI Serving&lt;/h1&gt;
&lt;h2 id="the-big-picture-first"&gt;The Big Picture First&lt;/h2&gt;
&lt;p&gt;In the last explanation, we covered the raw hardware — GPUs, CUDA, memory. But having powerful hardware alone doesn&amp;rsquo;t automatically mean you can serve an AI model efficiently to lots of real users at once. Here&amp;rsquo;s the specific problem this whole section addresses: running a language model for just yourself, one question at a time, is relatively straightforward — but running that same model in production, handling potentially thousands of simultaneous users, each sending requests of wildly different lengths, all while trying to keep the GPU&amp;rsquo;s expensive hardware genuinely busy rather than sitting idle, is a genuinely much harder engineering problem. Production AI serving is the whole discipline built around solving exactly this problem — a collection of specialized software tools and clever techniques specifically designed to squeeze the maximum possible useful work out of expensive GPU hardware while serving real, live traffic. Let&amp;rsquo;s work through it.&lt;/p&gt;</description></item></channel></rss>