diff --git a/app/blog/[slug]/page.js b/app/blog/[slug]/page.js index 1f390b14..282ca283 100644 --- a/app/blog/[slug]/page.js +++ b/app/blog/[slug]/page.js @@ -10,6 +10,7 @@ import BlogToc from '@/components/BlogToc'; import BlogShareBar from '@/components/BlogShareBar'; import CodeBlockEnhancer from '@/components/CodeBlockEnhancer'; import NewsletterCTA from '@/components/NewsletterCTA'; +import SponsorCallout from '@/components/SponsorCallout'; import AuthorSocials from '@/components/AuthorSocials'; import Comments from '@/components/Comments'; @@ -32,7 +33,7 @@ export async function generateMetadata({ params }) { title: post.seoTitle || post.title, description: post.seoDescription || undefined, keywords: post.tags, - authors: [{ name: post.author.name, url: post.author.url }], + authors: post.authors.map((a) => ({ name: a.name, url: a.url })), alternates: { canonical: url }, openGraph: { type: 'article', @@ -42,7 +43,7 @@ export async function generateMetadata({ params }) { siteName: SITE.name, images: [{ url: ogImage, width: 1200, height: 630, alt: post.title }], publishedTime: post.datePublished, - authors: [post.author.name], + authors: post.authors.map((a) => a.name), tags: post.tags, }, twitter: { @@ -84,15 +85,15 @@ export default async function BlogPost({ params }) { dateModified: post.datePublished, inLanguage: 'en-US', isAccessibleForFree: true, - author: { + author: post.authors.map((a) => ({ '@type': 'Person', - '@id': post.author.url, - name: post.author.name, - url: post.author.url, - image: post.author.avatar?.startsWith('http') ? post.author.avatar : `${SITE.url}${post.author.avatar}`, - sameAs: post.author.sameAs?.length ? post.author.sameAs : undefined, - ...(post.author.bio ? { description: post.author.bio } : {}), - }, + '@id': a.url, + name: a.name, + url: a.url, + image: a.avatar?.startsWith('http') ? a.avatar : `${SITE.url}${a.avatar}`, + sameAs: a.sameAs?.length ? a.sameAs : undefined, + ...(a.bio ? { description: a.bio } : {}), + })), publisher: { '@type': 'Organization', '@id': 'https://kubesimplify.com#org', @@ -189,16 +190,31 @@ export default async function BlogPost({ params }) {

)}
- {/* eslint-disable-next-line @next/next/no-img-element */} - +
+ {post.authors.map((a) => ( + /* eslint-disable-next-line @next/next/no-img-element */ + + ))} +
- - {post.author.name} - + {post.authors.map((a, i) => ( + + {i > 0 && &} + + {a.name} + + + ))} · · @@ -223,6 +239,8 @@ export default async function BlogPost({ params }) { /> )} + + {/* Mobile TOC (desktop has it in the right sidebar) */} @@ -249,25 +267,29 @@ export default async function BlogPost({ params }) {
-
- {/* eslint-disable-next-line @next/next/no-img-element */} - -
- - {post.author.name} - - {post.author.bio && ( -

- {post.author.bio} -

- )} - -
-
+ + + {post.authors.map((a) => ( +
+ {/* eslint-disable-next-line @next/next/no-img-element */} + +
+ + {a.name} + + {a.bio && ( +

+ {a.bio} +

+ )} + +
+
+ ))} diff --git a/app/globals.css b/app/globals.css index cf3a94b5..1278e923 100644 --- a/app/globals.css +++ b/app/globals.css @@ -522,3 +522,9 @@ a:focus-visible, button:focus-visible { border-right: 1px solid var(--border-subtle); border-bottom: 1px solid var(--border-subtle); } + +/* Sponsor logo: show the dark-colored mark on light theme, the white mark on dark theme */ +.sponsor-logo--light { display: inline-block; } +.sponsor-logo--dark { display: none; } +.dark .sponsor-logo--light { display: none; } +.dark .sponsor-logo--dark { display: inline-block; } diff --git a/components/BlogCard.jsx b/components/BlogCard.jsx index 1b4cc1a8..8ebfb7b7 100644 --- a/components/BlogCard.jsx +++ b/components/BlogCard.jsx @@ -53,10 +53,14 @@ export default function BlogCard({ post, featured = false }) { )}
- {/* eslint-disable-next-line @next/next/no-img-element */} - {post.author.name} +
+ {(post.authors || [post.author]).map((a) => ( + /* eslint-disable-next-line @next/next/no-img-element */ + {a.name} + ))} +
- {post.author.name} · {post.readMinutes} min + {(post.authors || [post.author]).map((a) => a.name).join(' & ')} · {post.readMinutes} min
diff --git a/components/SponsorCallout.jsx b/components/SponsorCallout.jsx new file mode 100644 index 00000000..01c1ac70 --- /dev/null +++ b/components/SponsorCallout.jsx @@ -0,0 +1,91 @@ +/** + * Sponsor / hardware-partner callout, driven by a post's `sponsor` frontmatter: + * + * sponsor: + * name: Utho + * url: https://utho.com/... # full link (UTM params included) + * blurb: "One-line thank-you shown in the end CTA." + * + * `variant="strip"` renders a slim disclosure line (placed near the top). + * `variant="cta"` renders the end-of-post thank-you card. + * Renders nothing unless name + url are present, so non-sponsored posts are unaffected. + * Links use rel="sponsored" per Google's paid-link guidance. + */ +export default function SponsorCallout({ sponsor, variant = 'strip' }) { + if (!sponsor || !sponsor.name || !sponsor.url) return null; + const { name, url, blurb, logoLight, logoDark } = sponsor; + const hasLogo = logoLight && logoDark; + + if (variant === 'strip') { + return ( +
+ + Hardware partner + + + The GPU node in this post was provided by{' '} + + {name} + + . + +
+ ); + } + + return ( +
+

+ Thanks to our hardware partner +

+ {hasLogo ? ( +
+ {/* eslint-disable-next-line @next/next/no-img-element */} + {name} + {/* eslint-disable-next-line @next/next/no-img-element */} + {name} +
+ ) : ( +

+ {name} +

+ )} + {blurb && ( +

+ {blurb} +

+ )} + + Explore {name} + + + + +
+ ); +} diff --git a/content/blog/slicing-gpus-in-kubernetes-with-nvidia-mig.md b/content/blog/slicing-gpus-in-kubernetes-with-nvidia-mig.md new file mode 100644 index 00000000..da3b71a1 --- /dev/null +++ b/content/blog/slicing-gpus-in-kubernetes-with-nvidia-mig.md @@ -0,0 +1,1039 @@ +--- +title: "Slicing GPUs in Kubernetes with NVIDIA Multi-Instance GPU (MIG)" +seoTitle: "NVIDIA MIG on Kubernetes: GPU Sharing Done Right, From 8 GPUs to 32 Isolated Slices" +seoDescription: "GPU sharing in Kubernetes explained: time-slicing vs MPS vs MIG, every nvidia-smi command to enable and disable MIG on one GPU or eight, GPU Operator automation, pitfalls, and DCGM monitoring." +datePublished: 2026-07-15T10:00:00.000Z +slug: slicing-gpus-in-kubernetes-with-nvidia-mig +author: shubham-katara +authors: ["shubham-katara", "saiyam-pathak"] +cover: /img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/cover.png +tags: ["kubernetes", "gpu", "nvidia", "platform-engineering"] +draft: false +sponsor: + name: Utho + url: "https://utho.com/?utm_source=Kubesimplify&utm_medium=docs&utm_campaign=Saiyam" + # logoLight = navy mark (shown on light theme); logoDark = white mark (shown on dark theme) + logoLight: /img/sponsors/utho-logo-light.png + logoDark: /img/sponsors/utho-logo-dark.png + blurb: "This deep dive ran on an 8x NVIDIA RTX PRO 6000 Blackwell node from Utho Cloud. If you need GPU infrastructure to run workloads like these, take a look." +--- + +GPUs are the most expensive thing in your cluster and the worst shared. A CPU can be divided into millicores. Memory can be requested byte by byte. But ask Kubernetes for a GPU and you get the whole card, all 96GB of it, even if your model needs 20GB. + +This post is the story of fixing that. We take a node with **8x NVIDIA RTX PRO 6000 Blackwell GPUs** (768GB of VRAM in total) and slice it into **32 fully isolated 24GB GPU instances** using **Multi-Instance GPU (MIG)**. First by hand with `nvidia-smi`, one card at a time, so you see every command including how to undo everything. Then across all 8 cards at once. Then declaratively with the NVIDIA GPU Operator so it survives beyond a single SSH session. + +Who this is for: + +- Platform engineers and SREs who run GPU nodes in Kubernetes and are tired of watching 96GB cards sit mostly idle. +- Teams that need hardware-level tenant isolation on shared AI infrastructure while keeping finance happy about utilization. + +By the end, a PyTorch workload will be running on a single hardware-isolated slice, and you will be able to prove the isolation from both inside and outside the container. + +While this setup was tested on a single node, nothing here is single-node specific. It works the same regardless of how many GPU nodes you have. + +## The Problem: Kubernetes Hands Out GPUs Whole + +Here is a scenario that plays out on GPU clusters everywhere. + +Your team provisions a node equipped with 8x NVIDIA RTX PRO 6000 Blackwell GPUs. You deploy the standard Kubernetes GPU Operator, which registers the node resources as `nvidia.com/gpu: 8`. + +Then a developer deploys a lightweight LLM inference pod or a small PyTorch training job. Kubernetes assigns them a whole GPU. The workload claims the entire 96GB Blackwell card but only uses 20GB. + +The remaining 76GB sits idle. + +Because standard GPUs are scheduled as indivisible resources, eight small workloads lock down eight entire cards. Your platform is left with zero schedulable GPU capacity, artificially high queue latency, and a cluster operating at a fraction of its financial and compute potential. + +Now you are stuck answering an uncomfortable question: how do you justify low cluster utilization to finance while your development teams are complaining about lack of GPU availability? + +The fix is GPU sharing. But "sharing a GPU" means very different things depending on how you do it, and picking the wrong mechanism is how you end up with one tenant's memory leak crashing another tenant's training job. + +## The Three Ways to Share a GPU + +NVIDIA gives you three mechanisms to put more than one workload on a card. To understand why they behave so differently, you first need to know what actually happens when a process uses a GPU. + +### First: How a Process Talks to a GPU + +When a program calls its first CUDA function (a PyTorch `tensor.cuda()`, a TensorFlow session, anything), the driver creates a **CUDA context** for it on the GPU. Think of the context as the GPU-side equivalent of an operating system process: it owns the program's VRAM allocations and their page tables, its streams, and its pending kernel launches. Every CUDA process gets its own context, and contexts cannot see into each other's memory. + +When that program launches a kernel, the work is chopped into thread blocks, and the GPU's scheduler sprays those blocks across the Streaming Multiprocessors (SMs), the hardware units that execute the math. + +Here is the detail that makes GPU sharing interesting: **by default, only one CUDA context executes on the GPU at a time.** If your kernel only keeps 20 of the card's 188 SMs busy, the other 168 sit idle anyway, because they belong to your context's turn. Another process's kernels cannot sneak onto the idle SMs; that process's whole context has to wait for its own turn. A GPU is, out of the box, a single-tenant machine. + +Every sharing mechanism is an answer to this one problem, and each answers it at a different layer: + +![The GPU sharing spectrum: time-slicing, MPS, and MIG compared](/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-sharing-spectrum.png) + +### Time-Slicing: Contexts Take Turns + +Time-slicing accepts the one-context-at-a-time rule and makes the turns short. It sounds like how a CPU core runs many threads, but the comparison hides a crucial asymmetry: a CPU thread switch means saving a few registers, while a GPU context switch means draining the pipelines and spilling the on-chip state of every SM (register files and shared memory, tens of megabytes on a card this size) out to VRAM, then loading someone else's back in. It is orders of magnitude more expensive, and GPUs were historically designed to never do it. + +In fact, for years they could not do it at all. Before the Pascal architecture (2016), a running kernel was uninterruptible: the GPU could only switch contexts at kernel boundaries, so process A's kernel ran to completion, then process B's kernel ran, and the interleaving merely *looked* parallel. One long-running kernel meant everyone else waited, full stop. Pascal introduced **instruction-level compute preemption**: the driver can now stop a kernel mid-flight, snapshot its context to GPU DRAM, and swap in another one. Refined through Turing, Ampere, Hopper, and Blackwell, this is the machinery that makes time-slicing usable today. In practice short kernels still mostly interleave at kernel boundaries (they finish before the time slice expires, which is the cheap path), and preemption is the expensive escape hatch that stops a long kernel from hogging the card. + +In Kubernetes, the device plugin's time-slicing feature adds nothing at the GPU level. It just advertises one GPU as, say, 4 "replicas", lands 4 pods on it, and lets the driver's native context multiplexing sort it out. Pod A runs its kernels for a slice while B and C are frozen, then the heavy switch happens and B gets the card. Nothing ever truly runs in parallel, and the switching tax is paid on every turn. + +The name also over-promises. CPU time-slicing means enforced fair quanta: every process gets its turn, guaranteed by the kernel. GPU "time-slicing" guarantees nothing: no fixed quantum you can rely on, no priorities, no fair scheduler. A pod that keeps launching heavy kernels dominates the card while its neighbors starve. A more honest name would be GPU oversubscription: Kubernetes believes there are 4 GPUs, the silicon knows there is 1. + +This is also why training and inference are such different sharing stories. Training pushes long, dense, back-to-back kernels that saturate the SMs, so time-slicing just splits a saturated card into slower turns while adding switch overhead: everyone loses. Inference is short kernel bursts with idle gaps in between, which is exactly the shape that turn-taking (and, better, MPS below) can pack efficiently. + +The bigger problem is what is *not* partitioned: memory. Every context sees the full 96GB as allocatable, all of them draw from the same physical pool, and nothing (not the driver, not Kubernetes) tracks who was supposed to get how much. If pod A allocates or leaks until the pool is exhausted, pod B's next `cudaMalloc` fails and B crashes, even though B did nothing wrong. And a fatal fault that forces a GPU reset takes down every pod on the card. Time-slicing is fine for dev clusters and bursty, trusted workloads. It is not a tenant isolation story. + +### MPS: Many Processes Pretend to Be One + +MPS (Multi-Process Service) attacks the idle-SM waste directly with a clever trick: if only one context can execute at a time, then let everyone share **one context**. An MPS server process sits between the clients and the GPU. Client processes hand their kernel launches to the server, and the server submits all of them through its own single GPU context. From the hardware's point of view there is just one well-behaved tenant; in reality its work is a merge of everybody's kernels. + +Because it all lives in one context, kernels from different processes now genuinely run **at the same time on different SMs**. Three inference services that each keep 20% of the SMs busy stack up to 60% utilization instead of each waiting for a turn. This is space-sharing instead of time-sharing, and for lots of small kernels it is a real throughput win. + +But the same trick is also the weakness. The isolation you normally get from separate contexts is gone, replaced by bookkeeping inside the MPS server. Since the Volta architecture, MPS clients do keep separate GPU address spaces, so one client cannot simply read another's memory. What stays shared is everything else: per-client SM and memory caps exist (`CUDA_MPS_ACTIVE_THREAD_PERCENTAGE`, `CUDA_MPS_PINNED_DEVICE_MEM_LIMIT`), but they are opt-in environment variables, not hardware walls, and the fault domain is one big shared boat. A client hitting a fatal error (an illegal memory access, say) can bring down the MPS server itself, and when the server dies, every client's "GPU" disappears mid-flight. Better throughput than time-slicing, still soft isolation, best kept inside a single trust boundary, one team sharing a card with itself. + +### MIG: Split the Silicon + +MIG (Multi-Instance GPU) stops playing scheduling games and changes the hardware answer instead. It partitions the physical GPU at the silicon level: each instance gets its own dedicated VRAM slice with its own memory controllers and L2 cache portion, its own set of SMs, and its own fault domain. Each slice runs its *own* CUDA contexts, concurrently with the other slices, because each slice genuinely is a smaller GPU as far as the execution hardware is concerned. + +That changes all three failure stories at once. OOM? A slice's contexts allocate only from that slice's 24GB; exhaust it and only that tenant fails. Noisy neighbor? A slice's kernels physically cannot touch another slice's SMs, and because the memory bandwidth is partitioned too, your latency does not jitter when the neighbor gets busy. Crash? Fault containment is per slice; the other slices never notice. To the workload, the slice just looks like a smaller dedicated GPU with a stable, predictable performance profile. + +| | Time-slicing | MPS | MIG | +| --- | --- | --- | --- | +| The trick | Contexts take turns, fast | Everyone shares one context | Split the hardware itself | +| Parallelism | None (serialized turns) | Real (space-sharing SMs) | Real (separate silicon) | +| Isolation | None | Software (shared context) | Hardware (silicon level) | +| Memory protection | None, one shared pool | Opt-in limits | Enforced by hardware | +| Fault blast radius | Whole card | Whole card (server dies, all die) | One slice | +| Performance | Variable, context-switch overhead | Good for small kernels | Predictable, dedicated units | +| Best for | Dev/test, trusted bursty jobs | One team packing its own card | Shared platforms with real tenant boundaries | + +If you are building a platform where different teams, customers, or environments share the same silicon, MIG is the only option of the three that gives you a hardware guarantee instead of a promise. That is the mechanism this post is about. + +One caveat before you commit: MIG needs supported hardware (A100/A30 Ampere onwards, Hopper, Blackwell including the RTX PRO 6000 Server Edition we use here), and a MIG slice cannot exceed one physical card. If your model needs more than 96GB, MIG is not your problem to solve; multi-GPU is. + +## Prerequisites + +To follow along, you will need root access to a GPU node and admin access to a Kubernetes cluster. Here is the exact infrastructure used in this setup: + +- **Host OS:** Enterprise Linux VM (Ubuntu-based) on Utho Cloud. +- **Cloud Provider:** Utho Cloud. +- **Kubernetes:** v1.35.6 +- **GPU Operator Chart:** gpu-operator-v26.3.3 +- **Container Runtime:** `containerd`. +- **CPUs:** 256 Cores. +- **RAM:** 1259GB. +- **GPUs:** 8x NVIDIA RTX PRO 6000 Blackwell Server Edition (96GB VRAM, 188 Streaming Multiprocessors / SMs per card). +- **NVIDIA Host Driver:** `610.43.02` with **CUDA:** `13.3`. + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi -L +GPU 0: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-8b89b58e-b427-108d-ac50-06138d78fe78) +GPU 1: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-03a041b7-8abf-360a-d1a2-dfd70188cd5f) +GPU 2: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-ba09367f-dd50-32ca-e988-7ff66bece885) +GPU 3: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-30512c46-708b-f374-5698-ee24be6cd626) +GPU 4: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288) +GPU 5: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-04dc48d7-7048-aef5-ad36-f5db716e7668) +GPU 6: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-f4f5db98-143f-0a8d-47ce-956fab39a736) +GPU 7: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-f4c61521-240a-da09-2787-e576034e197e) +``` + +## The MIG Mental Model: GPU Instances and Compute Instances + +Before slicing a GPU, it is crucial to understand what a slice actually contains. + +Every slice consists of a **GPU Instance (GI)** and a **Compute Instance (CI)**. The easiest way to think about them: + +1. **The GPU Instance (GI) is the plot of land.** When you create a GI, you carve out a physical chunk of VRAM and its memory controllers. This land is securely fenced off at the silicon level. No other partition or process on the GPU can cross this boundary or access this memory. +2. **The Compute Instance (CI) is the building built on that land.** The building houses the execution machinery: the Streaming Multiprocessors (SMs) and Tensor Cores that perform the actual mathematical computations. + +![GPU Instance is the plot of land, Compute Instance is the building on it](/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gi-ci-relationship.png) + +The relationship between a GI and a CI is strictly hierarchical: + +- **No building without land.** You cannot establish a Compute Instance without first creating a parent GPU Instance. Execution units must have a dedicated memory boundary to run in. +- **Size constraints.** The capacity of the building (CI) cannot exceed the size of the plot of land (GI). You cannot allocate more compute slices (SMs) than the parent VRAM slice naturally supports. +- **Sub-division.** You can build a single large structure (one CI matching the full GI) or divide the plot to support multiple smaller buildings (multiple smaller CIs). In the latter scenario, those compute instances run in parallel, sharing the same VRAM pool of the parent GI while keeping their execution cores strictly isolated. +- **Teardown order matters.** You cannot clear the plot of land (destroy the GI) while the building is still standing (the CI exists). The driver will reject the command. You must demolish the building first (destroy all CIs), then reclaim the land (destroy the parent GI). This rule shows up again below in the hands-on teardown steps. + +Why split both memory and compute? If you only partitioned the memory and left the compute cores shared, you would have multiple isolated storage units but one set of hands trying to access all of them at once, causing traffic jams. If you only partitioned the compute cores but kept a shared memory pool, you would have independent workers writing on the same sheet of paper, causing conflicts and corruption. By slicing both, every tenant gets their own locked filing cabinet and their own dedicated worker. + +### How to Read MIG Profile Names + +NVIDIA profiles follow the naming scheme `{X}g.{Y}gb`: + +- **`{Y}gb`** is the VRAM partition (the GI layer). +- **`{X}g`** is the compute slice count. + +The RTX PRO 6000 Blackwell has 188 SMs and divides its silicon into **4 base compute slices**. So a **`1g.24gb`** slice gets roughly 1/4th of the card: **46 SMs** paired with a 24GB VRAM partition. (It is a hair under a clean quarter because the driver holds a few SMs back, so four slices use 184 of the 188.) A `2g.48gb` slice gets half the card, and `4g.96gb` is the full card expressed as a single MIG instance. + +You will also see suffixed variants like `1g.24gb-me` (a pure-compute slice with the video decode/encode engines stripped out) and `1g.24gb+me.all` (one slice that grabs all of the card's media engines). We will see the full list straight from the driver in a moment. + +## Hands-On Part 1: Slice One GPU, End to End + +Everything in this section happens on the host, with no Kubernetes involved. We will take GPU 0 through the complete lifecycle: check, enable, inspect, carve, verify, run, and then tear it all back down. If you understand this section, the rest of the post is just automation. + +### Step 0: Check the current MIG mode + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi -i 0 --query-gpu=index,name,mig.mode.current --format=csv +index, name, mig.mode.current +0, NVIDIA RTX PRO 6000 Blackwell Server Edition, Disabled +``` + +`-i 0` targets GPU index 0. Drop the `-i` flag and the same query prints the state of every card in the box. + +### Step 1: Stop the daemons holding the GPU + +Two operations here look similar but behave very differently under load: + +- **Toggling MIG mode (`nvidia-smi -mig 1`):** on older architectures like the Ampere A100, enabling MIG forced a disruptive GPU reset. Starting with Hopper and Blackwell, this is a non-disruptive logical toggle in the driver. +- **Carving the slices (`nvidia-smi mig -cgi ...`):** this is where physical reality hits. The command forces the GPU's memory controllers to partition the memory crossbars on the silicon. If any process holds even a single megabyte of VRAM, the operation fails with `Device or resource busy`. + +On enterprise systems, two background services commonly hold handles on GPU device files: + +1. **`nvidia-persistenced`:** keeps the driver loaded in kernel memory to avoid launch latency for new CUDA processes. +2. **`nvidia-fabricmanager`:** used on multi-GPU systems connected via NVSwitches (HGX baseboards). If your GPUs are slotted directly into PCIe like ours, this service is not present. + +Stop what applies to you: + +```sh +root@gpu-rtxpro6000-8:~# sudo systemctl stop nvidia-persistenced +``` + +Also make sure no CUDA workload (an Ollama server, a Jupyter kernel, anything) is running on the GPU you are about to slice. `nvidia-smi` shows active processes at the bottom of its output. + +### Step 2: Enable MIG mode on GPU 0 + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi -i 0 -mig 1 +Enabled MIG Mode for GPU 00000000:01:00.0 + +Warning: persistence mode is disabled on device 00000000:01:00.0. See the Known Issues section of the nvidia-smi(1) man page for more information. Run with [--help | -h] switch to get more information on how to enable persistence mode. +All done. +``` + +The warning is expected: we stopped `nvidia-persistenced` ourselves one step ago, and the driver is just pointing that out. If the driver cannot flip the mode because a client is still attached, it reports the GPU as being in a *pending enable* state instead. Kill the remaining clients (or reboot) and the mode activates. + +At this point the GPU is in MIG mode but has zero slices, which means **no CUDA workload can use it at all** until you carve instances. An enabled-but-empty MIG GPU is effectively offline for compute. Do not stop halfway. + +### Step 3: See what profiles the card supports + +Ask the driver what shapes it can cut: + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi mig -i 0 -lgip ++-------------------------------------------------------------------------------+ +| GPU instance profiles: | +| GPU Name ID Instances Memory P2P SM DEC ENC | +| Free/Total GiB CE JPEG OFA | +|===============================================================================| +| 0 MIG 1g.24gb 14 4/4 23.62 No 46 1 1 | +| 1 1 0 | ++-------------------------------------------------------------------------------+ +| 0 MIG 1g.24gb+me 21 1/1 23.62 No 46 1 1 | +| 1 1 1 | ++-------------------------------------------------------------------------------+ +| 0 MIG 1g.24gb+gfx 47 4/4 23.62 No 46 1 1 | +| 1 1 0 | ++-------------------------------------------------------------------------------+ +| 0 MIG 1g.24gb+me.all 65 1/1 23.62 No 46 4 4 | +| 1 4 1 | ++-------------------------------------------------------------------------------+ +| 0 MIG 1g.24gb-me 67 4/4 23.62 No 46 0 0 | +| 1 0 0 | ++-------------------------------------------------------------------------------+ +| 0 MIG 2g.48gb 5 2/2 47.38 No 94 2 2 | +| 2 2 0 | ++-------------------------------------------------------------------------------+ +| 0 MIG 2g.48gb+gfx 35 2/2 47.38 No 94 2 2 | +| 2 2 0 | ++-------------------------------------------------------------------------------+ +| 0 MIG 2g.48gb+me.all 64 1/1 47.38 No 94 4 4 | +| 2 4 1 | ++-------------------------------------------------------------------------------+ +| 0 MIG 2g.48gb-me 66 2/2 47.38 No 94 0 0 | +| 2 0 0 | ++-------------------------------------------------------------------------------+ +| 0 MIG 4g.96gb 0 1/1 95.12 No 188 4 4 | +| 4 4 1 | ++-------------------------------------------------------------------------------+ +| 0 MIG 4g.96gb+gfx 32 1/1 95.12 No 188 4 4 | +| 4 4 1 | ++-------------------------------------------------------------------------------+ +``` + +Read this table carefully, it is the source of truth for your card: + +- **ID** is the numeric profile ID you can use in create commands (`14` and the name `1g.24gb` are interchangeable). +- **Instances Free/Total** tells you how many of each profile fit: four 1g.24gb slices, or two 2g.48gb, or one 4g.96gb. +- **SM** confirms the compute split: 46/94/188 SMs. +- The suffixed variants redistribute the media engines and graphics support. Every plain slice already gets a proportional share of the media engines (the `1g.24gb` row shows one NVDEC and one NVENC). The suffixes change that: `-me` strips them out for a pure-compute slice, `+me.all` hands a single slice all of the card's decode/encode engines (hence it is limited to 1/1), and `+gfx` (new on Blackwell) enables graphics APIs inside the slice. + +You can also ask where those slices physically land on the card: + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi mig -i 0 -lgipp +GPU 0 Profile ID 14 Placements: {0,3,6,9}:3 +GPU 0 Profile ID 21 Placements: {0,3,6,9}:3 +GPU 0 Profile ID 47 Placements: {0,3,6,9}:3 +GPU 0 Profile ID 65 Placements: {0,3,6,9}:3 +GPU 0 Profile ID 67 Placements: {0,3,6,9}:3 +GPU 0 Profile ID 5 Placements: {0,6}:6 +GPU 0 Profile ID 35 Placements: {0,6}:6 +GPU 0 Profile ID 64 Placements: {0,6}:6 +GPU 0 Profile ID 66 Placements: {0,6}:6 +GPU 0 Profile ID 0 Placement : {0}:12 +GPU 0 Profile ID 32 Placement : {0}:12 +``` + +The card's memory is organized as a grid of 12 placement units. The notation `{0,3,6,9}:3` means a `1g.24gb` slice occupies 3 units and can start at position 0, 3, 6, or 9. A `2g.48gb` occupies 6 units and can only start at 0 or 6, and the full-card `4g.96gb` takes all 12. This matters when you mix profile sizes: create slices in the wrong order and you can fragment the grid so a big slice no longer fits, even though enough total memory is free. + +### Step 4: Carve the slices + +Create four `1g.24gb` GPU instances, each with its compute instance, in one command. `-cgi` creates the GPU Instances (the land), and the `-C` flag immediately builds the matching Compute Instance (the building) inside each one: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -i 0 -cgi 1g.24gb,1g.24gb,1g.24gb,1g.24gb -C +Successfully created GPU instance ID 3 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 3 using profile MIG 1g.24gb (ID 0) +Successfully created GPU instance ID 4 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 4 using profile MIG 1g.24gb (ID 0) +Successfully created GPU instance ID 5 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 5 using profile MIG 1g.24gb (ID 0) +Successfully created GPU instance ID 6 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 6 using profile MIG 1g.24gb (ID 0) +``` + +`sudo nvidia-smi mig -i 0 -cgi 14,14,14,14 -C` does exactly the same thing using the profile IDs from the table above. + +You do not have to make them all the same size. Want one big tenant and two small ones on the same card? Mix profiles: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -i 0 -cgi 2g.48gb,1g.24gb,1g.24gb -C +Successfully created GPU instance ID 1 on GPU 0 using profile MIG 2g.48gb (ID 5) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 1 using profile MIG 2g.48gb (ID 1) +Successfully created GPU instance ID 5 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 5 using profile MIG 1g.24gb (ID 0) +Successfully created GPU instance ID 6 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 6 using profile MIG 1g.24gb (ID 0) + +root@gpu-rtxpro6000-8:~# nvidia-smi mig -i 0 -lgi ++---------------------------------------------------------+ +| GPU instances: | +| GPU Name Profile Instance Placement | +| ID ID Start:Size | +|=========================================================| +| 0 MIG 1g.24gb 14 5 6:3 | ++---------------------------------------------------------+ +| 0 MIG 1g.24gb 14 6 9:3 | ++---------------------------------------------------------+ +| 0 MIG 2g.48gb 5 1 0:6 | ++---------------------------------------------------------+ +``` + +One 48GB half-card slice (placement 0:6) plus two 24GB quarter-card slices (6:3 and 9:3), and the placement grid adds up to exactly 12. This is how you serve a large LLM and two small inference services from a single physical GPU with hard boundaries between them. For the rest of this walkthrough we stick with the uniform four-slice layout, so tear the mixed one down (`-dci`, then `-dgi`) and recreate the four `1g.24gb` slices if you followed along. + +### Step 5: Verify the slices exist + +Three views of the same truth. The device list: + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi -L +GPU 0: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-8b89b58e-b427-108d-ac50-06138d78fe78) + MIG 1g.24gb Device 0: (UUID: MIG-445da789-865d-5fd1-b2b6-32a48bf66c39) + MIG 1g.24gb Device 1: (UUID: MIG-e78fd5d2-f2de-5632-8961-9a368cec8080) + MIG 1g.24gb Device 2: (UUID: MIG-b8861912-6285-56a1-99ca-297ac0f38ddb) + MIG 1g.24gb Device 3: (UUID: MIG-f46c5ab9-40ef-54a2-b796-a2101a6ed56d) +GPU 1: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-03a041b7-8abf-360a-d1a2-dfd70188cd5f) +... +``` + +Every MIG device has its own UUID. This is exactly how the Kubernetes device plugin will identify and schedule the slices later. + +The GPU instances (the land plots) with their physical placements: + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi mig -i 0 -lgi ++---------------------------------------------------------+ +| GPU instances: | +| GPU Name Profile Instance Placement | +| ID ID Start:Size | +|=========================================================| +| 0 MIG 1g.24gb 14 3 0:3 | ++---------------------------------------------------------+ +| 0 MIG 1g.24gb 14 4 3:3 | ++---------------------------------------------------------+ +| 0 MIG 1g.24gb 14 5 6:3 | ++---------------------------------------------------------+ +| 0 MIG 1g.24gb 14 6 9:3 | ++---------------------------------------------------------+ +``` + +Each instance occupies 3 units of the 12-unit placement grid, exactly as `-lgipp` promised. And the compute instances (the buildings) inside them: + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi mig -i 0 -lci ++--------------------------------------------------------------------+ +| Compute instances: | +| GPU GPU Name Profile Instance Placement | +| Instance ID ID Start:Size | +| ID | +|====================================================================| +| 0 3 MIG 1g.24gb 0 0 0:1 | ++--------------------------------------------------------------------+ +| 0 4 MIG 1g.24gb 0 0 0:1 | ++--------------------------------------------------------------------+ +| 0 5 MIG 1g.24gb 0 0 0:1 | ++--------------------------------------------------------------------+ +| 0 6 MIG 1g.24gb 0 0 0:1 | ++--------------------------------------------------------------------+ +``` + +### Step 6: Run something on a slice (no Kubernetes needed) + +MIG slices are addressable directly from the host via their UUID. This is handy for smoke-testing before the cluster ever gets involved. With PyTorch available on the host (a quick `python3 -m venv` plus `pip install torch --index-url https://download.pytorch.org/whl/cu130` is enough), pin a process to the first slice's UUID from `nvidia-smi -L`: + +```sh +root@gpu-rtxpro6000-8:~# CUDA_VISIBLE_DEVICES=MIG-445da789-865d-5fd1-b2b6-32a48bf66c39 python3 -c " +import torch +print('device count:', torch.cuda.device_count()) +print('device name :', torch.cuda.get_device_name(0)) +print('total memory:', torch.cuda.get_device_properties(0).total_memory // 2**20, 'MiB')" +device count: 1 +device name : NVIDIA RTX PRO 6000 Blackwell Server Edition MIG 1g.24gb +total memory: 24192 MiB +``` + +The process sees exactly one device, it identifies itself as a `1g.24gb` slice, and it has 24192 MiB, not the 97887 MiB of the full card. Isolation is already in force at the host level, no Kubernetes required. + +### Step 7: Tear it all down (disable MIG) + +You will reconfigure slices far more often than you think: profile sizes change, tenants come and go, and sometimes you just want the whole card back for one big training run. Remember the hierarchy rule: buildings before land. Compute instances first, then GPU instances, then the mode itself. + +Destroy the compute instances on GPU 0: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -i 0 -dci +Successfully destroyed compute instance ID 0 from GPU 0 GPU instance ID 3 +Successfully destroyed compute instance ID 0 from GPU 0 GPU instance ID 4 +Successfully destroyed compute instance ID 0 from GPU 0 GPU instance ID 5 +Successfully destroyed compute instance ID 0 from GPU 0 GPU instance ID 6 +``` + +Then the GPU instances: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -i 0 -dgi +Successfully destroyed GPU instance ID 3 from GPU 0 +Successfully destroyed GPU instance ID 4 from GPU 0 +Successfully destroyed GPU instance ID 5 from GPU 0 +Successfully destroyed GPU instance ID 6 from GPU 0 +``` + +If you run `-dgi` before `-dci`, the driver rejects it. This is what actually happens if you try: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -i 0 -dgi +Unable to destroy GPU instance ID 3 from GPU 0: In use by another client +Failed to destroy GPU instances: In use by another client +``` + +That is the land-and-building rule enforced in silicon: the CI still standing on GI 3 is the "another client". + +Also note: a slice with a running workload cannot be destroyed. Stop the pods or processes using it first, otherwise `-dci` fails with the same *In use by another client* error. + +Now disable MIG mode: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi -i 0 -mig 0 +Disabled MIG Mode for GPU 00000000:01:00.0 + +Warning: persistence mode is disabled on device 00000000:01:00.0. See the Known Issues section of the nvidia-smi(1) man page for more information. Run with [--help | -h] switch to get more information on how to enable persistence mode. +All done. +``` + +And confirm the card is whole again, then bring back the persistence daemon we stopped in Step 1: + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi -i 0 --query-gpu=index,mig.mode.current --format=csv +index, mig.mode.current +0, Disabled + +root@gpu-rtxpro6000-8:~# nvidia-smi -L | head -1 +GPU 0: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-8b89b58e-b427-108d-ac50-06138d78fe78) + +root@gpu-rtxpro6000-8:~# sudo systemctl start nvidia-persistenced +``` + +One GPU, full lifecycle, both directions. That is the entire mechanical core of MIG. + +## Hands-On Part 2: All 8 GPUs at Once + +Everything above used `-i 0` to target one card. The scaling trick is almost embarrassing: **drop the `-i` flag and every command applies to all GPUs**. + +Enable MIG everywhere: + +```sh +root@gpu-rtxpro6000-8:~# sudo systemctl stop nvidia-persistenced +root@gpu-rtxpro6000-8:~# sudo nvidia-smi -mig 1 +Enabled MIG Mode for GPU 00000000:01:00.0 +Enabled MIG Mode for GPU 00000000:21:00.0 +Enabled MIG Mode for GPU 00000000:41:00.0 +Enabled MIG Mode for GPU 00000000:61:00.0 +Enabled MIG Mode for GPU 00000000:81:00.0 +Enabled MIG Mode for GPU 00000000:A1:00.0 +Enabled MIG Mode for GPU 00000000:C1:00.0 +Enabled MIG Mode for GPU 00000000:E1:00.0 +All done. +``` + +(The per-GPU persistence-mode warnings are trimmed here; they are the same one we saw in Part 1.) + +Carve four slices on every MIG-enabled card in one command. The same GI IDs 3 through 6 appear on each of the 8 GPUs: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -cgi 1g.24gb,1g.24gb,1g.24gb,1g.24gb -C +Successfully created GPU instance ID 3 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 3 using profile MIG 1g.24gb (ID 0) +Successfully created GPU instance ID 4 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 4 using profile MIG 1g.24gb (ID 0) +Successfully created GPU instance ID 5 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 5 using profile MIG 1g.24gb (ID 0) +Successfully created GPU instance ID 6 on GPU 0 using profile MIG 1g.24gb (ID 14) +Successfully created compute instance ID 0 on GPU 0 GPU instance ID 6 using profile MIG 1g.24gb (ID 0) +... (identical output repeats for GPU 1 through GPU 7) ... + +root@gpu-rtxpro6000-8:~# sudo systemctl start nvidia-persistenced +``` + +And verify. This is the money shot, 8 physical cards now presenting as 32 isolated devices: + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi -L + +GPU 0: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-8b89b58e-b427-108d-ac50-06138d78fe78) + MIG 1g.24gb Device 0: (UUID: MIG-445da789-865d-5fd1-b2b6-32a48bf66c39) + MIG 1g.24gb Device 1: (UUID: MIG-e78fd5d2-f2de-5632-8961-9a368cec8080) + MIG 1g.24gb Device 2: (UUID: MIG-b8861912-6285-56a1-99ca-297ac0f38ddb) + MIG 1g.24gb Device 3: (UUID: MIG-f46c5ab9-40ef-54a2-b796-a2101a6ed56d) +GPU 1: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-03a041b7-8abf-360a-d1a2-dfd70188cd5f) + MIG 1g.24gb Device 0: (UUID: MIG-c614986b-8ca6-5114-b292-f7fdf532b32e) + MIG 1g.24gb Device 1: (UUID: MIG-ba182ecc-31c1-5a67-92f1-b6f14f39cc2f) + MIG 1g.24gb Device 2: (UUID: MIG-5976103f-bae0-5bd9-8de2-efcb0651ae5d) + MIG 1g.24gb Device 3: (UUID: MIG-09aa478f-191b-55ce-a012-235285f56a44) +GPU 2: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-ba09367f-dd50-32ca-e988-7ff66bece885) + MIG 1g.24gb Device 0: (UUID: MIG-07cdcefa-6330-5da7-9f25-0686ef5e6e7d) + MIG 1g.24gb Device 1: (UUID: MIG-91b206d2-cfbb-57d3-9ffb-00151f932469) + MIG 1g.24gb Device 2: (UUID: MIG-83bf707a-b369-5de9-a22a-e882e2a15f23) + MIG 1g.24gb Device 3: (UUID: MIG-db98d829-38c6-5490-ab37-54b3c1911690) +GPU 3: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-30512c46-708b-f374-5698-ee24be6cd626) + MIG 1g.24gb Device 0: (UUID: MIG-2d5513c3-03f4-54f0-9c70-688f7472c927) + MIG 1g.24gb Device 1: (UUID: MIG-471a3e25-40ba-5794-9d7b-2dfa7aa0a0ab) + MIG 1g.24gb Device 2: (UUID: MIG-f8584627-55b2-52be-ac92-0b4708e7dad6) + MIG 1g.24gb Device 3: (UUID: MIG-6e4f5dfc-7e1f-59dc-9fec-a13642abcd08) +GPU 4: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288) + MIG 1g.24gb Device 0: (UUID: MIG-0b090ecd-97b3-5022-b410-353a54064db3) + MIG 1g.24gb Device 1: (UUID: MIG-12e12a0a-56aa-5258-9cce-fb652a6d60ca) + MIG 1g.24gb Device 2: (UUID: MIG-e80daae6-94df-5114-b105-f4b8e14fe00c) + MIG 1g.24gb Device 3: (UUID: MIG-c652619d-ef73-5243-8313-163ba19341ce) +GPU 5: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-04dc48d7-7048-aef5-ad36-f5db716e7668) + MIG 1g.24gb Device 0: (UUID: MIG-ac982967-d17f-5636-8641-078e3f7ee88a) + MIG 1g.24gb Device 1: (UUID: MIG-9a6a33e8-352c-5b71-8523-7918f07f19d3) + MIG 1g.24gb Device 2: (UUID: MIG-dcdb7566-7372-56e3-ac66-29bbc7332280) + MIG 1g.24gb Device 3: (UUID: MIG-61f3820e-e817-5ae1-ac70-7d4ccc6752bd) +GPU 6: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-f4f5db98-143f-0a8d-47ce-956fab39a736) + MIG 1g.24gb Device 0: (UUID: MIG-fdae208b-7b6b-5360-b14d-7943f835591d) + MIG 1g.24gb Device 1: (UUID: MIG-bd87ccf3-dd60-556b-8fae-dd76a00f9f32) + MIG 1g.24gb Device 2: (UUID: MIG-4eb83867-7a48-50ec-98e4-590ca4a34bdb) + MIG 1g.24gb Device 3: (UUID: MIG-aa39a320-78fe-54f3-a33f-4e14a69a34fc) +GPU 7: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-f4c61521-240a-da09-2787-e576034e197e) + MIG 1g.24gb Device 0: (UUID: MIG-83e26b2c-d325-5f9e-b6ab-1dd76bf49ee0) + MIG 1g.24gb Device 1: (UUID: MIG-769267a5-61cf-5391-815c-df1af5592f2f) + MIG 1g.24gb Device 2: (UUID: MIG-bd09eec4-b779-57ff-b2e9-0c5dd4db132d) + MIG 1g.24gb Device 3: (UUID: MIG-0f8a469f-1116-5095-9e94-65e7809b554d) +``` + +Each physical card can now serve 4 tenants independently, each with a hardware-isolated slice. Across 8 cards, that is 32 schedulable GPUs where you previously had 8, and you did not buy a single new card. + +The fleet-wide teardown is the same story without `-i`, in the same strict order. First all compute instances, then all GPU instances (32 "Successfully destroyed" lines each, trimmed to the last GPU here), then the mode itself: + +```sh +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -dci +... +Successfully destroyed compute instance ID 0 from GPU 7 GPU instance ID 3 +Successfully destroyed compute instance ID 0 from GPU 7 GPU instance ID 4 +Successfully destroyed compute instance ID 0 from GPU 7 GPU instance ID 5 +Successfully destroyed compute instance ID 0 from GPU 7 GPU instance ID 6 + +root@gpu-rtxpro6000-8:~# sudo nvidia-smi mig -dgi +... +Successfully destroyed GPU instance ID 3 from GPU 7 +Successfully destroyed GPU instance ID 4 from GPU 7 +Successfully destroyed GPU instance ID 5 from GPU 7 +Successfully destroyed GPU instance ID 6 from GPU 7 + +root@gpu-rtxpro6000-8:~# sudo nvidia-smi -mig 0 +Disabled MIG Mode for GPU 00000000:01:00.0 +Disabled MIG Mode for GPU 00000000:21:00.0 +Disabled MIG Mode for GPU 00000000:41:00.0 +Disabled MIG Mode for GPU 00000000:61:00.0 +Disabled MIG Mode for GPU 00000000:81:00.0 +Disabled MIG Mode for GPU 00000000:A1:00.0 +Disabled MIG Mode for GPU 00000000:C1:00.0 +Disabled MIG Mode for GPU 00000000:E1:00.0 +All done. + +root@gpu-rtxpro6000-8:~# nvidia-smi --query-gpu=index,mig.mode.current --format=csv +index, mig.mode.current +0, Disabled +1, Disabled +2, Disabled +3, Disabled +4, Disabled +5, Disabled +6, Disabled +7, Disabled +``` + +Eight whole GPUs again, as if nothing happened. + +## Bringing Kubernetes In: The GPU Operator + +Everything we just did by hand works. It also does not scale. There is no way to GitOps a series of `nvidia-smi` commands and maintain them across a fleet. And the host slices are invisible to Kubernetes until something advertises them to the Kubelet. + +To run GPU workloads inside containers, three distinct layers have to cooperate, and the **NVIDIA GPU Operator** manages all of them for you: + +![The three-layer Kubernetes GPU stack managed by the GPU Operator](/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/k8s-gpu-stack.png) + +**Layer 1: The Host Kernel Driver.** Installed directly on the host OS. It interfaces with the physical PCIe silicon and exposes character device files such as `/dev/nvidia0` and `/dev/nvidiactl`. It does not know or care that Kubernetes exists. + +**Layer 2: The Container Toolkit (the OCI integration).** Container runtimes like `containerd` can partition CPU and memory, but they cannot natively manage GPUs. The **NVIDIA Container Toolkit** hooks into containerd: when a container requests a GPU, it mounts the driver files (`/dev/nvidia*`, `libcuda.so`) into the container's namespace. + +**Layer 3: The Kubernetes Device Plugin.** A DaemonSet that queries the host driver, counts the available GPUs or MIG slices, and advertises them to the Kubelet as schedulable capacity. + +Install the operator with Helm: + +```sh +root@gpu-rtxpro6000-8:~# helm repo add nvidia https://helm.ngc.nvidia.com/nvidia +root@gpu-rtxpro6000-8:~# helm repo update +root@gpu-rtxpro6000-8:~# helm install gpu-operator nvidia/gpu-operator \ + -n gpu-operator --create-namespace \ + --set mig.strategy=mixed +``` + +About that `mig.strategy` flag, it controls how slices show up as Kubernetes resources: + +- **`single`** (the default): all GPUs on the node carry one uniform profile, and slices are advertised as plain `nvidia.com/gpu`. Workloads do not even know MIG is involved. +- **`mixed`:** each profile is advertised as its own resource, like `nvidia.com/mig-1g.24gb` or `nvidia.com/mig-2g.48gb`. This is what you want when different cards carry different geometries, or when workloads should explicitly pick a slice size. + +We use `mixed` in this post so the slice type is visible end to end. + +The operator deploys these components in the `gpu-operator` namespace: + +- **`gpu-operator` (controller):** watches `ClusterPolicy` custom resources and reconciles all the DaemonSets below on every GPU node. +- **`node-feature-discovery (NFD)`:** scans host hardware and labels nodes (for example, `nvidia.com/gpu.present=true`). +- **`gpu-feature-discovery (GFD)`:** adds fine-grained GPU labels such as memory size, model, and active MIG profiles (for example, `nvidia.com/mig.config=all-1g.24gb`). +- **`nvidia-container-toolkit`:** registers the `nvidia` runtime class in `/etc/containerd/config.toml`: + +```toml +[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'] + runtime_type = "io.containerd.runc.v2" + +[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'.options] + BinaryName = "/usr/local/nvidia/toolkit/nvidia-container-runtime" + SystemdCgroup = true +``` + +- **`nvidia-device-plugin`:** queries the driver's NVML library for MIG slice UUIDs and advertises them to the Kubelet (for example, `nvidia.com/mig-1g.24gb: 32`). +- **`nvidia-mig-manager`:** watches the `nvidia.com/mig.config` node label and reconfigures MIG geometry declaratively. More on this next. +- **`nvidia-dcgm-exporter`:** exposes per-slice hardware telemetry on a Prometheus `/metrics` endpoint. +- **`nvidia-operator-validator`:** runs a one-shot CUDA job to verify the whole software-to-hardware pipeline before user pods land. + +### Declarative MIG: One Label Instead of All Those Commands + +With the operator in place, the entire hands-on section above compresses into a single node label: + +```sh +root@gpu-rtxpro6000-8:~# kubectl label node nvidia.com/mig.config=all-1g.24gb --overwrite +``` + +The MIG Manager notices the label and orchestrates the full lifecycle through a structured loop: + +1. **Evicts GPU workloads:** sets the node's GPU allocatable to `0` and drains GPU pods to release device locks. +2. **Stops telemetry daemons:** pauses the device plugin and DCGM exporter so NVML has no clients. +3. **Resets state:** clears VRAM and any existing MIG geometry. +4. **Applies the new geometry:** enables MIG mode and carves GIs and CIs exactly like our manual commands did. +5. **Regenerates CDI specs:** writes new Container Device Interface configs so the runtime can inject the new devices. +6. **Restores the stack:** restarts the device plugin and exporter, which advertise the 32 new slices to the Kubelet. + +Verify from the cluster side: + +```sh +root@gpu-rtxpro6000-8:~# kubectl describe node | grep mig-1g.24gb + nvidia.com/mig-1g.24gb: 32 +``` + +To go back to whole GPUs, the disable path is also just a label. `all-disabled` destroys every slice and turns MIG mode off, and the node advertises `nvidia.com/gpu: 8` again: + +```sh +root@gpu-rtxpro6000-8:~# kubectl label node nvidia.com/mig.config=all-disabled --overwrite +``` + +Mixed geometries are possible too: built-in profiles like `all-balanced`, or a custom layout in the `mig-parted` ConfigMap that gives different cards different shapes. Everything we did with `-cgi 2g.48gb,1g.24gb,1g.24gb` has a declarative equivalent. + +### How the NVIDIA Runtime Injects GPUs into Containers + +To understand why those containerd configuration blocks are necessary, here is the flow when a pod actually starts: + +![How the NVIDIA runtime injects GPU devices into a container](/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/nvidia-runtime-flow.png) + +1. **Pod submission:** a developer submits a Pod requesting a GPU (`nvidia.com/gpu: 1` or a specific MIG resource). +2. **containerd interception:** containerd sees the pod uses the `nvidia` runtime class and prepares the container. +3. **nvidia-container-runtime (the middleman):** reads the container's environment (such as `NVIDIA_VISIBLE_DEVICES` carrying the MIG UUID), locates the matching device files under `/dev/nvidia*` and driver libraries like `libcuda.so` on the host, and injects them into the container's OCI spec. +4. **runc execution:** the modified spec goes to `runc`, which sets up namespaces, cgroups, and mounts, then starts the container. +5. **Workload runs:** PyTorch or TensorFlow inside the container talks to its GPU slice natively, because the devices and libraries were injected during the handshake. + +## Common Production Pitfalls and How to Solve Them + +Here is the quick-reference version, the way you will hit these at 2 AM: + +| Symptom | Likely cause | Fix | +| --- | --- | --- | +| Toolkit cannot find containerd, or runtime class never appears | Non-standard containerd paths (RKE2/K3s) | Point the toolkit at the right socket and config via Helm env overrides (Pitfall A) | +| Your manual slices vanish after installing the Operator | MIG Manager defaults to `all-disabled` when no node label exists | Label the node with the matching `nvidia.com/mig.config` profile (Pitfall B) | +| You changed slices on the host but Kubernetes shows the old layout, Operator logs frozen | MIG Manager only reacts to node label events, it never polls the hardware | Restart the MIG Manager pod or toggle the label to force reconciliation (Pitfall C) | +| Manual MIG mode: Kubelet never discovers new slices | Nothing tells the device plugin the hardware changed | Disable `migManager` in Helm and restart the device plugin daemonset (Pitfall D) | + +Now the details. + +### Pitfall A: Non-Standard containerd Socket Configurations + +The GPU Operator assumes default paths for the containerd socket and config files. If your setup runs containerd through RKE2, you must explicitly point the toolkit to the non-standard paths during Helm installation: + +```yaml +toolkit: + env: + - name: CONTAINERD_CONFIG + value: /var/lib/rancher/rke2/agent/etc/containerd/config.toml + - name: CONTAINERD_SOCKET + value: /run/k3s/containerd/containerd.sock + - name: CONTAINERD_RUNTIME_CLASS + value: nvidia + - name: CONTAINERD_SET_AS_DEFAULT + value: "true" +``` + +### Pitfall B: MIG Manager Overriding Host Configurations + +If the `nvidia-mig-manager` pod is active and detects no configuration label on a node, it defaults to the `all-disabled` profile, wiping out any manual host-level slicing you performed. All that careful `nvidia-smi` work, gone. + +**The fix:** apply the appropriate label to your node so it aligns with the operator's config: + +```sh +root@gpu-rtxpro6000-8:~# kubectl label node nvidia.com/mig.config=all-1g.24gb --overwrite +``` + +### Pitfall C: Host-Level State Drift Undetected by MIG Manager + +If you manually delete or modify MIG profiles directly on the host using the `nvidia-smi` CLI, the changes will not be reflected in Kubernetes, and the operator will appear completely silent about it. + +**The root cause:** the `nvidia-mig-manager` watches for **Kubernetes node label events**. It does not poll the host's physical GPU registers continuously. Because your manual host modifications do not trigger Kubernetes events, the manager remains idle, thinking the old state is still successfully applied (its logs will remain frozen). + +**The fix (for operator-managed MIG):** trigger a reconciliation event. Either restart the MIG Manager pod (which forces a full check on boot) or toggle the node label back and forth: + +```sh +# Option 1: Restart the MIG Manager daemonset +root@gpu-rtxpro6000-8:~# kubectl rollout restart daemonset -n gpu-operator nvidia-mig-manager + +# Option 2: Toggle the node label to trigger the watch loop +root@gpu-rtxpro6000-8:~# kubectl label node nvidia.com/mig.config=all-disabled --overwrite +# Wait 10 seconds, then re-apply: +root@gpu-rtxpro6000-8:~# kubectl label node nvidia.com/mig.config=all-1g.24gb --overwrite +``` + +### Pitfall D: Forcing Kubelet Discovery for Manual MIG Configurations + +Maybe you want the opposite arrangement: manage MIG slices manually on the host with the exact commands from the hands-on sections, prevent the GPU Operator from ever overwriting them, but still have Kubernetes discover and schedule workloads on those manual slices. + +**The root cause:** when the automatic `nvidia-mig-manager` is disabled to allow manual slicing, there is no automated trigger to notify the Kubelet when the host-level MIG configuration changes. + +**The fix (force Kubelet discovery):** + +1. **Disable the MIG Manager in Helm** so the operator never wipes your manual settings: + +```sh +root@gpu-rtxpro6000-8:~# helm upgrade --install gpu-operator nvidia/gpu-operator \ + -n gpu-operator \ + --set migManager.enabled=false \ + --set mig.strategy=mixed +``` + +2. **Provision host slices** manually with the `nvidia-smi mig -cgi ... -C` commands from Part 1 and Part 2. + +3. **Force Kubelet discovery** by restarting the device plugin daemonset: + +```sh +root@gpu-rtxpro6000-8:~# kubectl rollout restart daemonset -n gpu-operator nvidia-device-plugin-daemonset +``` + +## How to Monitor GPU Slices with Prometheus and Grafana + +A platform is only as good as its observability. Once your 32 GPU slices are registered, you need a centralized dashboard to monitor metrics like VRAM usage, temperature, and Tensor Core utilization. + +To achieve this, deploy the Prometheus community stack and hook it into the telemetry streams of the `nvidia-dcgm-exporter`. + +**Step 1: Install the kube-prometheus-stack.** + +```sh +root@gpu-rtxpro6000-8:~# helm repo add prometheus-community https://prometheus-community.github.io/helm-charts +root@gpu-rtxpro6000-8:~# helm repo update + +root@gpu-rtxpro6000-8:~# helm install prometheus prometheus-community/kube-prometheus-stack \ + -n monitoring --create-namespace +``` + +**Step 2: Apply the ServiceMonitor.** By default, Prometheus only scans its own namespace. This manifest uses a `namespaceSelector` to target the `nvidia-dcgm-exporter` Service inside the `gpu-operator` namespace: + +```yaml +apiVersion: monitoring.coreos.com/v1 +kind: ServiceMonitor +metadata: + name: nvidia-dcgm-exporter + # Deploy in the 'monitoring' namespace where Prometheus runs + namespace: monitoring + labels: + release: prometheus + app.kubernetes.io/instance: prometheus + app.kubernetes.io/managed-by: Helm +spec: + # Scrapes the service in the gpu-operator namespace + namespaceSelector: + matchNames: + - gpu-operator + selector: + matchLabels: + # Matches the exact standard label created by the NVIDIA GPU Operator Helm chart + app: nvidia-dcgm-exporter + endpoints: + - port: gpu-metrics + interval: 15s + path: /metrics +``` + +Apply it: + +```sh +root@gpu-rtxpro6000-8:~# kubectl apply -f nvidia-servicemonitor.yaml +``` + +**Step 3: Configure the Grafana dashboard.** NVIDIA maintains an official dashboard for DCGM exporter metrics: + +1. Log into your Grafana UI. +2. Navigate to **Dashboards** -> **Import**. +3. Import **Dashboard ID: `22515`**. +4. Select your Prometheus data source and click **Import**. + +This loads an interactive panel showing real-time health and performance across all 32 partitions: + +![Grafana NVIDIA DCGM dashboard showing per-GPU power, memory, temperature, and Tensor Core utilization](/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-observability.jpg) + +## Run a Real Workload on a Slice (Blackwell, sm_120) + +There is one final trap waiting at the workload layer. + +The NVIDIA Blackwell architecture uses a new compute capability version: **Compute Capability 12.0 (`sm_120`)**. If you use older container images (such as `pytorch:2.1.2-cuda12.1`), execution crashes with: + +``` +RuntimeError: CUDA error: no kernel image is available for execution on the device +``` + +Older PyTorch binaries simply do not contain compiled kernels for `sm_120`. Use a modern PyTorch image compiled with CUDA 12.8+ or the official **NVIDIA NGC PyTorch containers** (version `25.01-py3` or later), which natively support Blackwell. + +Here is the verified Deployment manifest that runs a matrix multiplication load on a single 24GB Blackwell MIG slice. Note the resource request: `nvidia.com/mig-1g.24gb`, the mixed-strategy resource name our device plugin advertises: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: pytorch-mig-demo + labels: + app: pytorch-mig-demo +spec: + replicas: 1 + selector: + matchLabels: + app: pytorch-mig-demo + template: + metadata: + labels: + app: pytorch-mig-demo + spec: + runtimeClassName: nvidia + containers: + - name: pytorch + # NVIDIA's official PyTorch NGC container (25.01 or later) + # compiled to support the Blackwell architecture (sm_120) + image: nvcr.io/nvidia/pytorch:25.01-py3 + command: ["python3", "-c"] + args: + - | + import torch + import time + + print("=== CUDA MIG Slice Diagnostics ===") + print("CUDA Available:", torch.cuda.is_available()) + if torch.cuda.is_available(): + print("Device Name:", torch.cuda.get_device_name(0)) + print("Device Capability:", torch.cuda.get_device_capability(0)) + print("CUDA Device Count:", torch.cuda.device_count()) + + # Allocate memory and perform matrix multiplication to generate GPU load + print("Allocating tensors on GPU and starting matrix math load...") + device = torch.device("cuda") + x = torch.randn(10000, 10000, device=device) + y = torch.randn(10000, 10000, device=device) + + # Keep running matrix multiplications to hold the CUDA context and load + while True: + z = torch.matmul(x, y) + time.sleep(0.5) + else: + print("ERROR: CUDA is not available inside the container!") + time.sleep(3600) + resources: + limits: + nvidia.com/mig-1g.24gb: 1 + requests: + nvidia.com/mig-1g.24gb: 1 +``` + +### Prove the Isolation, From Both Sides + +Once the pod is running, exec into the container and run `nvidia-smi`. You will observe exactly **one GPU** with **24GB VRAM**. The container cannot see the other 7 physical cards or the other 31 slices: + +```sh +root@gpu-rtxpro6000-8:~# kubectl exec -it pytorch-mig-demo-c9f7c8b49-sl5qh -- bash +root@pytorch-mig-demo-c9f7c8b49-sl5qh:/workspace# nvidia-smi +Tue Jul 14 19:44:18 2026 ++-----------------------------------------------------------------------------------------+ +| NVIDIA-SMI 610.43.02 KMD Version: 610.43.02 CUDA UMD Version: 13.3 | ++-----------------------------------------+------------------------+----------------------+ +| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | +| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | +| | | MIG M. | +|=========================================+========================+======================| +| 0 NVIDIA RTX PRO 6000 Blac... On | 00000000:61:00.0 Off | On | +| N/A 34C P0 108W / 600W | N/A | N/A Default | +| | | Enabled | ++-----------------------------------------+------------------------+----------------------+ + ++-----------------------------------------------------------------------------------------+ +| MIG devices: | ++------------------+----------------------------------+-----------+-----------------------+ +| GPU GI CI MIG | Shared Memory-Usage | Vol| Shared | +| ID ID Dev | Shared BAR1-Usage | SM Unc| CE ENC DEC OFA JPG | +| | | ECC| | +|==================+==================================+===========+=======================| +| 0 6 0 0 | 1786MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ + ++-----------------------------------------------------------------------------------------+ +| Processes: | +| GPU GI CI PID Type Process name GPU Memory | +| ID ID Usage | +|=========================================================================================| +| 0 6 0 1 C python3 1714MiB | ++-----------------------------------------------------------------------------------------+ +``` + +The pod only sees the `1g.24gb` slice that has been given to it and nothing else, with its 24GiB of memory shown under the MIG devices section. + +Now look at the same moment from the host. The host sees everything: all cards, all slices, and the exact same `python3` process burning memory on one specific slice (output trimmed to two GPUs to keep it readable): + +```sh +root@gpu-rtxpro6000-8:~# nvidia-smi + +Tue Jul 14 19:52:39 2026 ++-----------------------------------------------------------------------------------------+ +| NVIDIA-SMI 610.43.02 KMD Version: 610.43.02 CUDA UMD Version: 13.3 | ++-----------------------------------------+------------------------+----------------------+ +| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | +| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | +| | | MIG M. | +|=========================================+========================+======================| +| 2 NVIDIA RTX PRO 6000 Blac... On | 00000000:41:00.0 Off | On | +| N/A 26C P8 40W / 600W | 256MiB / 97887MiB | N/A Default | +| | | Enabled | ++-----------------------------------------+------------------------+----------------------+ +| 3 NVIDIA RTX PRO 6000 Blac... On | 00000000:61:00.0 Off | On | +| N/A 36C P0 108W / 600W | 1977MiB / 97887MiB | N/A Default | +| | | Enabled | ++-----------------------------------------+------------------------+----------------------+ ++-----------------------------------------------------------------------------------------+ +| MIG devices: | ++------------------+----------------------------------+-----------+-----------------------+ +| GPU GI CI MIG | Shared Memory-Usage | Vol| Shared | +| ID ID Dev | Shared BAR1-Usage | SM Unc| CE ENC DEC OFA JPG | +| | | ECC| | +|==================+==================================+===========+=======================| +| 2 3 0 0 | 64MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ +| 2 4 0 1 | 64MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ +| 2 5 0 2 | 64MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ +| 2 6 0 3 | 64MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ +| 3 3 0 0 | 64MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ +| 3 4 0 1 | 64MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ +| 3 5 0 2 | 64MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ +| 3 6 0 3 | 1786MiB / 24192MiB | 46 0 | 1 1 1 0 1 | +| | 0MiB / 8317MiB | | | ++------------------+----------------------------------+-----------+-----------------------+ ++-----------------------------------------------------------------------------------------+ +| Processes: | +| GPU GI CI PID Type Process name GPU Memory | +| ID ID Usage | +|=========================================================================================| +| 3 6 0 698976 C python3 1714MiB | ++-----------------------------------------------------------------------------------------+ +``` + +Same `python3` process, same 1714MiB, visible in both views because both are looking at the same hardware-isolated MIG slice. The other slices on that card show 64MiB of idle overhead each, completely untouched by the running workload. This is the beauty of MIG. + +## The Platform Properties Compared + +Here is the before-and-after, the way your finance and platform teams will evaluate it: + +| Property | 8 whole GPUs | 32 MIG slices | +| --- | --- | --- | +| Schedulable GPU resources | 8 | 32 | +| Small workload claims | Entire 96GB card | One 24GB hardware-isolated slice | +| Isolation model | Software-level (container boundaries) | Silicon-level (memory crossbars + SM channels) | +| OOM blast radius | Can destabilize the whole card | Contained within the 24GB slice | +| Developer wait times | Queue behind 8 indivisible cards | Immediate self-service on 32 slices | +| Configuration | Ad-hoc `nvidia-smi` scripts | Declarative node labels via the GPU Operator | + +## Conclusion + +GPU sharing is a spectrum. Time-slicing shares by taking turns, MPS shares by trusting neighbors, and MIG shares by building walls in silicon. When the tenants are real (different teams, different customers, different blast radii), MIG is the one that lets you sleep. + +Here is what you accomplished in this walkthrough: + +1. Understood the three GPU sharing mechanisms and why only MIG gives hardware-enforced tenant isolation. +2. Learned the GPU Instance / Compute Instance hierarchy and why MIG must partition both memory and compute. +3. Took a single GPU through the full MIG lifecycle by hand: enable, inspect profiles, carve slices, verify, run a workload, and tear everything back down to a whole card. +4. Scaled the same commands to all 8 GPUs by dropping one flag, producing 32 hardware-isolated `1g.24gb` instances. +5. Deployed the NVIDIA GPU Operator to make the whole configuration declarative and GitOps-friendly, with a single node label replacing the manual command sequence. +6. Diagnosed and fixed four real production pitfalls: non-standard containerd paths, MIG Manager overwrites, host-level state drift, and manual-mode Kubelet discovery. +7. Wired DCGM telemetry into a Prometheus + Grafana dashboard for slice-level observability. +8. Verified the isolation from both sides by running a PyTorch workload on a single `sm_120` slice. + +Building a high-efficiency GPU platform is not just about having the fastest silicon. It is about managing and distributing that compute pool effectively. Slicing the Blackwell architecture with MIG gives you the balance of strict isolation, cost optimization, and developer self-service that makes the platform actually work. + +If this was useful, the NVIDIA GPU Operator lives at [docs.nvidia.com](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/index.html) and on [GitHub](https://github.com/NVIDIA/gpu-operator), and the full MIG user guide is at [docs.nvidia.com/datacenter/tesla/mig-user-guide](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/). diff --git a/lib/_blog-feed-data.js b/lib/_blog-feed-data.js index 54744455..4fe70c1d 100644 --- a/lib/_blog-feed-data.js +++ b/lib/_blog-feed-data.js @@ -24,6 +24,18 @@ export const FEED_POSTS = [ "llm" ] }, + { + "slug": "slicing-gpus-in-kubernetes-with-nvidia-mig", + "title": "Slicing GPUs in Kubernetes with NVIDIA Multi-Instance GPU (MIG)", + "description": "GPU sharing in Kubernetes explained: time-slicing vs MPS vs MIG, every nvidia-smi command to enable and disable MIG on one GPU or eight, GPU Operator automation, pitfalls, and DCGM monitoring.", + "datePublished": "2026-07-15T10:00:00.000Z", + "cover": "/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/cover.png", + "tags": [ + "kubernetes", + "gpu", + "nvidia" + ] + }, { "slug": "introducing-kiac-kubernetes-in-apple-containers", "title": "Introducing kiac: Real Kubernetes Nodes on Your Mac, Each Its Own Lightweight VM", @@ -343,17 +355,5 @@ export const FEED_POSTS = [ "ai-assistants", "ai-agent" ] - }, - { - "slug": "nemotron3-on-dgx-spark", - "title": "Here's What I Learned About Nemotron 3 Super -I Ran a 120B Parameter Model on Nvidia DGX Spark", - "description": "Understand everything about Nvidia DGX spark along with hands on and benchmarks. ", - "datePublished": "2026-03-14T12:44:36.246Z", - "cover": "/img/blog/nemotron3-on-dgx-spark/6f7096fe-54a1-4e2e-aacc-184cb109d071.png", - "tags": [ - "nvidia", - "ai-agents", - "dgxspark" - ] } ]; diff --git a/lib/blog.js b/lib/blog.js index c31546ed..ff10ba21 100644 --- a/lib/blog.js +++ b/lib/blog.js @@ -76,6 +76,11 @@ function loadAll() { const slug = data.slug || file.replace(/\.md$/, ''); const stats = readingTime(content); const fallbackDesc = data.seoDescription || extractDescriptionFromContent(content); + // `authors:` (array) takes precedence over legacy single `author:`; first entry is primary + const authorHandles = Array.isArray(data.authors) && data.authors.length > 0 + ? data.authors + : [data.author]; + const authors = authorHandles.map(resolveAuthor); return { slug, title: data.title || slug, @@ -85,7 +90,9 @@ function loadAll() { cover: data.cover || null, draft: data.draft === true, tags: Array.isArray(data.tags) ? data.tags : [], - author: resolveAuthor(data.author), + author: authors[0], + authors, + sponsor: data.sponsor || null, readMinutes: Math.max(1, Math.round(stats.minutes)), words: stats.words, content, @@ -128,8 +135,9 @@ export function getPostsByTag(tag) { export function getAllAuthors() { const counts = new Map(); for (const p of loadAll()) { - const h = p.author.handle; - counts.set(h, (counts.get(h) || 0) + 1); + for (const a of p.authors) { + counts.set(a.handle, (counts.get(a.handle) || 0) + 1); + } } // Return author profiles with post counts, sorted by count return Array.from(counts.entries()) @@ -142,7 +150,7 @@ export function getAuthor(handle) { } export function getPostsByAuthor(handle) { - return loadAll().filter((p) => p.author.handle === handle); + return loadAll().filter((p) => p.authors.some((a) => a.handle === handle)); } export function getRelatedPosts(slug, count = 3) { diff --git a/public/_redirects b/public/_redirects index 897912ac..b75470ca 100644 --- a/public/_redirects +++ b/public/_redirects @@ -178,6 +178,7 @@ /blog/rancher-desktop-evolution /rancher-desktop-evolution 301! /blog/ready-for-wasm-day-2023 /ready-for-wasm-day-2023 301! /blog/simplified-introduction-to-bacalhau /simplified-introduction-to-bacalhau 301! +/blog/slicing-gpus-in-kubernetes-with-nvidia-mig /slicing-gpus-in-kubernetes-with-nvidia-mig 301! /blog/speeding-up-using-microk8s /speeding-up-using-microk8s 301! /blog/ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale /ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale 301! /blog/starting-your-devops-journey-as-a-windows-user /starting-your-devops-journey-as-a-windows-user 301! @@ -390,6 +391,7 @@ /rancher-desktop-evolution /blog/rancher-desktop-evolution 200! /ready-for-wasm-day-2023 /blog/ready-for-wasm-day-2023 200! /simplified-introduction-to-bacalhau /blog/simplified-introduction-to-bacalhau 200! +/slicing-gpus-in-kubernetes-with-nvidia-mig /blog/slicing-gpus-in-kubernetes-with-nvidia-mig 200! /speeding-up-using-microk8s /blog/speeding-up-using-microk8s 200! /ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale /blog/ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale 200! /starting-your-devops-journey-as-a-windows-user /blog/starting-your-devops-journey-as-a-windows-user 200! diff --git a/public/_worker.js b/public/_worker.js index 40f24387..cb01a346 100644 --- a/public/_worker.js +++ b/public/_worker.js @@ -3,7 +3,7 @@ // Replaces _redirects (Pages picks _worker.js over _redirects when both exist). const KUBESIMPLIFY_ROUTES = new Set(['/about', '/workshops', '/partnerships', '/resources']); -const BLOG_SLUGS = new Set(["10-things-you-might-not-know-about-k9s","12-practical-grep-command-examples-in-linux","a-beginners-guide-to-dualbooting-windows-with-ubuntu-part-1","a-beginners-guide-to-dualbooting-windows-with-ubuntu-part-2","a-complete-walk-through-of-devops","a-kubeconfig-for-gke-that-doesnt-need-gcloud","a-simple-way-to-structure-your-terraform-code","a-simplified-guide-to-yaml","about-my-pdf-editor-project","an-overview-of-gitops-and-argocd","announcing-buildsafe","api-response-in-go","arkade","automate-repetitive-tasks-shell-scripting","automated-github-releases-with-github-actions-and-conventional-commits","avoid-overspending-with-kubecost","aws-elastic-cloud-compute","bake-your-container-images-with-bake","become-a-hashicorp-certified-terraform-associate-preparation-guide","best-devops-tools-2025","bonsai-27b-rtx-pro-6000-dgx-spark","breaking-down-docker","building-a-zero-cve-strategy","building-apigateway-with-lambda-using-pulumi","certified-kubernetes-security-specialist-cks-2022-exam-guide","cicd-pipeline-github-actions-with-aws-ecs","ckad-exam-april-2022","claude-code-leak-what-the-source-actually-teaches","clawspark-your-private-openclaw-ai-assistant-that-never-phones-home","cloud-computing","cloud-native-buildpacks-concepts","confidential-containers-running-on-kubernetes","container-and-kubernetes-security","controlling-mcp-tools-with-agentgateway-on-kubernetes","coolify","creating-multi-node-kubernetes-cluster-locally","day-1-the-local-llm-revolution-why-your-desk-just-became-the-new-datacenter","day-1-what-actually-happens-when-you-type-docker-run","day-2-anatomy-of-an-llm-inference-request-from-prompt-to-answer-step-by-step","day-2-your-images-are-a-supply-chain-and-it-s-probably-broken","day-3-stop-writing-dockerfiles-from-scratch","day-3-the-dgx-spark-unpacked-gb10-unified-memory-sm-121-and-the-one-reason-this-hardware-exists","day-4-breaking-isolation-on-purpose-volumes-networks-and-the-real-world","day-4-quantization-demystified-bf16-fp8-nvfp4-mxfp4-int4-gguf-and-why-it-all-matters","day-5-docker-compose-how-docker-actually-gets-used","day-5-local-llm-inference-engines-wrappers-and-what-to-pick","day-6-run-an-llm-on-your-laptop-with-docker","day-7-ship-it-and-what-comes-next","deploy-a-maven-project-on-a-tomcat-server-using-jenkins-and-aws","deploy-a-simple-server-using-aws-terraform","deploying-java-application-using-docker-and-kubernetes-devops-project","ditch-the-overheating-laptop-supercharge-your-docker-workflow-with-docker-offload","diy-how-to-build-a-kubernetes-policy-engine","docker-captain-journey","docker-mcp-catalog","docker-networking-demystified","embed-http-servers-in-wasm-with-rust-and-csharp","enhancing-runtime-security-with-falco-my-hands-on-experience","ephemeral-pull-request-environment-using-vcluster","essential-linux-commands-for-devops","event-driven-architecture-simplified-monolith-to-microservices","everything-you-need-to-know-about-docker-compose","everything-you-need-to-know-about-the-linux-ls-command","exploiting-metasploitable2-using-msfconsole-kali-linux-lab","firewall-a-networks-gatekeeper","four-pillars-of-observability-in-kubernetes","get-good-at-git","getting-started-with-kind-creating-a-multi-node-local-kubernetes-cluster","getting-started-with-ko-a-fast-container-image-builder-for-your-go-applications","getting-started-with-kyverno","git-and-github-a-beginners-guide","github-actions-101-what-are-github-actions-and-how-to-use-them-a-beginners-guide","gitops-demystified","ha-kubernetes","how-a-kubernetes-service-actually-works-and-all-5-types-you-need","how-get-started-with-hashicorp-vault","how-kubernetes-endpointslices-actually-work-and-why-endpoints-had-to-die","how-to-backup-kubernetes-with-kasten-community-edition","how-to-change-directory-in-shell-scripts","how-to-install-a-kubernetes-cluster-with-kubeadm-containerd-and-cilium-a-hands-on-guide","how-to-setup-your-ftp-server-in-linux","implementing-kubernetes-network-policies-a-comprehensive-guide","important-concepts-of-operating-systems","ing-switch-119-annotations-gateway-api-traefik-impact-ratings","ing-switch-migrate-from-ingress-nginx-to-traefik-or-gateway-api-in-minutes-not-days","installing-prometheus-with-selinux","introducing-kiac-kubernetes-in-apple-containers","introducing-unikraft-lightweight-virtualization-using-unikernels","introduction-of-jenkins-pipeline","introduction-to-cicd-and-cicd-pipeline","introduction-to-cri","introduction-to-developer-platforms-with-gimlet","introduction-to-helm","introduction-to-jenkins","introduction-to-kubernetes","introduction-to-terraform","iptables-demo","istio-service-mesh","k8sgpt-tutorial-when-kubernetes-meets-ai","keptn-getting-started","ksctl-making-kubernetes-easy-across-clouds","kube-proxy-deep-dive","kube-scheduler-deep-dive","kubecon-cloudnativecon-north-america-2024-recap-themes-innovations-and-community-spirit","kubecon-cloudnativecon-rejekts-and-wasm-io-wrap-up-a-leap-into-the-future-with-webassembly-ai-and-sustainable-cloud-practices","kubectl-run-nginx-inside","kubeflow-machine-learning-on-kubernetes-part-1","kubeflow-notebooks-ml-experimentation-made-easier-part-2","kubeflow-pipelines-orchestrating-machine-learning-workflows-part-3","kubernetes-125-dockerd","kubernetes-126","kubernetes-access-control-with-authentication-authorization-admission-control","kubernetes-adoption-key-challenges-in-migrating-to-kubernetes","kubernetes-backup-using-cloudcasa","kubernetes-containerd-setup","kubernetes-crio","kubernetes-management-with-rust-a-dive-into-generic-client-go-controller-abstractions-and-crd-macros-with-kubers","kubernetes-on-apple-macbooks-m-series","kubernetes-scheduling-the-complete-guide","kubernetes-v133-key-features-updates-and-what-you-need-to-know","kubernetes-v135-whats-new-whats-changing-and-what-you-should-know","kubesimplify-a-journey-to-remember","kubesimplify-at-wasmio-and-kubecon-eu-2024","kyverno-and-cosign","kyverno-cli","lets-learn-terraform","lets-simplify-golang-part-1","lets-simplify-golang-part-2","lets-simplify-golang-part-3","lets-talk-about-ansible","linux-boot-process-simplified","linux-system-directories-explained","llm-costs-and-observability-with-agentgateway-on-kubernetes","managing-contexts-in-kubernetes-with-plugins","managing-your-operating-system-with-package-managers","mastering-kubernetes-costs-from-monitoring-to-automation","microservices","mlxcel-rust-native-inference-engine-tested-on-m1-max","moving-code-between-git-repositories-with-copybara","multi-stage-docker-build","multi-tenancy-in-2025-and-beyond","my-first-international-conference-open-source-summit-2022","my-journey-to-kubestronaut-on-kubernetes-10th-birthday","my-kubecon-euvirtual-experience","my-schedule-for-kubecon-cloudnativecon-eu-2022","navigating-through-cncf-landscape","nemotron3-on-dgx-spark","networking-fundamentals-for-devops","nexus-repository-manager-what-is-it-and-how-to-configure-it-on-a-digital-ocean-droplet","nvcf-is-now-open-source-inside-nvidia-s-gpu-function-platform","operating-systems-101-essential-knowledge-for-devopssre-engineers","optimizing-kubernetes-costs-balancing-spot-and-on-demand-instances-with-topology-spread-constraints","optimizing-scalability-a-deep-dive-into-load-testing-with-locust-on-eks","package-managers-demystified","perform-crud-operations-on-kubernetes-using-golang","platform-engineering-demystified-navigating-the-basics","pods-in-kubernetes","practical-guide-to-kubernetes-api","progressive-rollouts-with-argo-cd-rollouts","prometheus-explained","pure-cilium-a-guide-for-local-load-balancing-and-bgp","quick-bites-of-fluxcd-health-assessment","rancher-desktop-evolution","ready-for-wasm-day-2023","simplified-introduction-to-bacalhau","speeding-up-using-microk8s","ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale","starting-your-devops-journey-as-a-windows-user","statefulsets","supply-chain-security-using-slsa-part-1-fundamentals","supply-chain-security-using-slsa-part-2-the-framework","terraform-best-practices","testing-docker-ais-gordon-how-smart-is-it","the-complete-guide-to-the-dd-command-in-linux","the-secret-gems-behind-building-container-images-enter-buildkit-and-docker-buildx","the-ultimate-guide-to-audit-logging-in-kubernetes-from-setup-to-analysis","the-webassembly-course","tutorial-build-a-cloud-cost-monitoring-system-with-terraform-ansible-and-komiser","understanding-docker-desktop-all-in-one-platform-for-containers","understanding-etcd-in-kubernetes-a-beginners-guide","understanding-how-containers-work-behind-the-scenes","understanding-the-architecture-of-kubernetes-a-beginners-guide","understanding-the-ins-and-outs-of-git-using-github","wandler-local-openai-compatible-inference-transformersjs-webgpu","what-is-reproducibility-and-why-does-it-matter","what-is-shell-scripting","why-are-network-policies-in-kubernetes-so-hard-to-understand","why-devops-case-study","wtf-is-linux-shell-command-substitution","yours-kindly-drone"]); +const BLOG_SLUGS = new Set(["10-things-you-might-not-know-about-k9s","12-practical-grep-command-examples-in-linux","a-beginners-guide-to-dualbooting-windows-with-ubuntu-part-1","a-beginners-guide-to-dualbooting-windows-with-ubuntu-part-2","a-complete-walk-through-of-devops","a-kubeconfig-for-gke-that-doesnt-need-gcloud","a-simple-way-to-structure-your-terraform-code","a-simplified-guide-to-yaml","about-my-pdf-editor-project","an-overview-of-gitops-and-argocd","announcing-buildsafe","api-response-in-go","arkade","automate-repetitive-tasks-shell-scripting","automated-github-releases-with-github-actions-and-conventional-commits","avoid-overspending-with-kubecost","aws-elastic-cloud-compute","bake-your-container-images-with-bake","become-a-hashicorp-certified-terraform-associate-preparation-guide","best-devops-tools-2025","bonsai-27b-rtx-pro-6000-dgx-spark","breaking-down-docker","building-a-zero-cve-strategy","building-apigateway-with-lambda-using-pulumi","certified-kubernetes-security-specialist-cks-2022-exam-guide","cicd-pipeline-github-actions-with-aws-ecs","ckad-exam-april-2022","claude-code-leak-what-the-source-actually-teaches","clawspark-your-private-openclaw-ai-assistant-that-never-phones-home","cloud-computing","cloud-native-buildpacks-concepts","confidential-containers-running-on-kubernetes","container-and-kubernetes-security","controlling-mcp-tools-with-agentgateway-on-kubernetes","coolify","creating-multi-node-kubernetes-cluster-locally","day-1-the-local-llm-revolution-why-your-desk-just-became-the-new-datacenter","day-1-what-actually-happens-when-you-type-docker-run","day-2-anatomy-of-an-llm-inference-request-from-prompt-to-answer-step-by-step","day-2-your-images-are-a-supply-chain-and-it-s-probably-broken","day-3-stop-writing-dockerfiles-from-scratch","day-3-the-dgx-spark-unpacked-gb10-unified-memory-sm-121-and-the-one-reason-this-hardware-exists","day-4-breaking-isolation-on-purpose-volumes-networks-and-the-real-world","day-4-quantization-demystified-bf16-fp8-nvfp4-mxfp4-int4-gguf-and-why-it-all-matters","day-5-docker-compose-how-docker-actually-gets-used","day-5-local-llm-inference-engines-wrappers-and-what-to-pick","day-6-run-an-llm-on-your-laptop-with-docker","day-7-ship-it-and-what-comes-next","deploy-a-maven-project-on-a-tomcat-server-using-jenkins-and-aws","deploy-a-simple-server-using-aws-terraform","deploying-java-application-using-docker-and-kubernetes-devops-project","ditch-the-overheating-laptop-supercharge-your-docker-workflow-with-docker-offload","diy-how-to-build-a-kubernetes-policy-engine","docker-captain-journey","docker-mcp-catalog","docker-networking-demystified","embed-http-servers-in-wasm-with-rust-and-csharp","enhancing-runtime-security-with-falco-my-hands-on-experience","ephemeral-pull-request-environment-using-vcluster","essential-linux-commands-for-devops","event-driven-architecture-simplified-monolith-to-microservices","everything-you-need-to-know-about-docker-compose","everything-you-need-to-know-about-the-linux-ls-command","exploiting-metasploitable2-using-msfconsole-kali-linux-lab","firewall-a-networks-gatekeeper","four-pillars-of-observability-in-kubernetes","get-good-at-git","getting-started-with-kind-creating-a-multi-node-local-kubernetes-cluster","getting-started-with-ko-a-fast-container-image-builder-for-your-go-applications","getting-started-with-kyverno","git-and-github-a-beginners-guide","github-actions-101-what-are-github-actions-and-how-to-use-them-a-beginners-guide","gitops-demystified","ha-kubernetes","how-a-kubernetes-service-actually-works-and-all-5-types-you-need","how-get-started-with-hashicorp-vault","how-kubernetes-endpointslices-actually-work-and-why-endpoints-had-to-die","how-to-backup-kubernetes-with-kasten-community-edition","how-to-change-directory-in-shell-scripts","how-to-install-a-kubernetes-cluster-with-kubeadm-containerd-and-cilium-a-hands-on-guide","how-to-setup-your-ftp-server-in-linux","implementing-kubernetes-network-policies-a-comprehensive-guide","important-concepts-of-operating-systems","ing-switch-119-annotations-gateway-api-traefik-impact-ratings","ing-switch-migrate-from-ingress-nginx-to-traefik-or-gateway-api-in-minutes-not-days","installing-prometheus-with-selinux","introducing-kiac-kubernetes-in-apple-containers","introducing-unikraft-lightweight-virtualization-using-unikernels","introduction-of-jenkins-pipeline","introduction-to-cicd-and-cicd-pipeline","introduction-to-cri","introduction-to-developer-platforms-with-gimlet","introduction-to-helm","introduction-to-jenkins","introduction-to-kubernetes","introduction-to-terraform","iptables-demo","istio-service-mesh","k8sgpt-tutorial-when-kubernetes-meets-ai","keptn-getting-started","ksctl-making-kubernetes-easy-across-clouds","kube-proxy-deep-dive","kube-scheduler-deep-dive","kubecon-cloudnativecon-north-america-2024-recap-themes-innovations-and-community-spirit","kubecon-cloudnativecon-rejekts-and-wasm-io-wrap-up-a-leap-into-the-future-with-webassembly-ai-and-sustainable-cloud-practices","kubectl-run-nginx-inside","kubeflow-machine-learning-on-kubernetes-part-1","kubeflow-notebooks-ml-experimentation-made-easier-part-2","kubeflow-pipelines-orchestrating-machine-learning-workflows-part-3","kubernetes-125-dockerd","kubernetes-126","kubernetes-access-control-with-authentication-authorization-admission-control","kubernetes-adoption-key-challenges-in-migrating-to-kubernetes","kubernetes-backup-using-cloudcasa","kubernetes-containerd-setup","kubernetes-crio","kubernetes-management-with-rust-a-dive-into-generic-client-go-controller-abstractions-and-crd-macros-with-kubers","kubernetes-on-apple-macbooks-m-series","kubernetes-scheduling-the-complete-guide","kubernetes-v133-key-features-updates-and-what-you-need-to-know","kubernetes-v135-whats-new-whats-changing-and-what-you-should-know","kubesimplify-a-journey-to-remember","kubesimplify-at-wasmio-and-kubecon-eu-2024","kyverno-and-cosign","kyverno-cli","lets-learn-terraform","lets-simplify-golang-part-1","lets-simplify-golang-part-2","lets-simplify-golang-part-3","lets-talk-about-ansible","linux-boot-process-simplified","linux-system-directories-explained","llm-costs-and-observability-with-agentgateway-on-kubernetes","managing-contexts-in-kubernetes-with-plugins","managing-your-operating-system-with-package-managers","mastering-kubernetes-costs-from-monitoring-to-automation","microservices","mlxcel-rust-native-inference-engine-tested-on-m1-max","moving-code-between-git-repositories-with-copybara","multi-stage-docker-build","multi-tenancy-in-2025-and-beyond","my-first-international-conference-open-source-summit-2022","my-journey-to-kubestronaut-on-kubernetes-10th-birthday","my-kubecon-euvirtual-experience","my-schedule-for-kubecon-cloudnativecon-eu-2022","navigating-through-cncf-landscape","nemotron3-on-dgx-spark","networking-fundamentals-for-devops","nexus-repository-manager-what-is-it-and-how-to-configure-it-on-a-digital-ocean-droplet","nvcf-is-now-open-source-inside-nvidia-s-gpu-function-platform","operating-systems-101-essential-knowledge-for-devopssre-engineers","optimizing-kubernetes-costs-balancing-spot-and-on-demand-instances-with-topology-spread-constraints","optimizing-scalability-a-deep-dive-into-load-testing-with-locust-on-eks","package-managers-demystified","perform-crud-operations-on-kubernetes-using-golang","platform-engineering-demystified-navigating-the-basics","pods-in-kubernetes","practical-guide-to-kubernetes-api","progressive-rollouts-with-argo-cd-rollouts","prometheus-explained","pure-cilium-a-guide-for-local-load-balancing-and-bgp","quick-bites-of-fluxcd-health-assessment","rancher-desktop-evolution","ready-for-wasm-day-2023","simplified-introduction-to-bacalhau","slicing-gpus-in-kubernetes-with-nvidia-mig","speeding-up-using-microk8s","ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale","starting-your-devops-journey-as-a-windows-user","statefulsets","supply-chain-security-using-slsa-part-1-fundamentals","supply-chain-security-using-slsa-part-2-the-framework","terraform-best-practices","testing-docker-ais-gordon-how-smart-is-it","the-complete-guide-to-the-dd-command-in-linux","the-secret-gems-behind-building-container-images-enter-buildkit-and-docker-buildx","the-ultimate-guide-to-audit-logging-in-kubernetes-from-setup-to-analysis","the-webassembly-course","tutorial-build-a-cloud-cost-monitoring-system-with-terraform-ansible-and-komiser","understanding-docker-desktop-all-in-one-platform-for-containers","understanding-etcd-in-kubernetes-a-beginners-guide","understanding-how-containers-work-behind-the-scenes","understanding-the-architecture-of-kubernetes-a-beginners-guide","understanding-the-ins-and-outs-of-git-using-github","wandler-local-openai-compatible-inference-transformersjs-webgpu","what-is-reproducibility-and-why-does-it-matter","what-is-shell-scripting","why-are-network-policies-in-kubernetes-so-hard-to-understand","why-devops-case-study","wtf-is-linux-shell-command-substitution","yours-kindly-drone"]); export default { async fetch(request, env) { diff --git a/public/atom.xml b/public/atom.xml index 1d1ba972..ac0e2e22 100644 --- a/public/atom.xml +++ b/public/atom.xml @@ -5,7 +5,7 @@ https://blog.kubesimplify.com/ - 2026-07-17T06:43:12.515Z + 2026-07-20T12:12:17.309Z Kubesimplify hello@kubesimplify.com @@ -36,6 +36,18 @@ + + Slicing GPUs in Kubernetes with NVIDIA Multi-Instance GPU (MIG) + + https://blog.kubesimplify.com/slicing-gpus-in-kubernetes-with-nvidia-mig + 2026-07-15T10:00:00.000Z + 2026-07-15T10:00:00.000Z + GPU sharing in Kubernetes explained: time-slicing vs MPS vs MIG, every nvidia-smi command to enable and disable MIG on one GPU or eight, GPU Operator automation, pitfalls, and DCGM monitoring. + + + + + Introducing kiac: Real Kubernetes Nodes on Your Mac, Each Its Own Lightweight VM diff --git a/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/cover.png b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/cover.png new file mode 100644 index 00000000..132f09e4 Binary files /dev/null and b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/cover.png differ diff --git a/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gi-ci-relationship.png b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gi-ci-relationship.png new file mode 100644 index 00000000..50f7f2f4 Binary files /dev/null and b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gi-ci-relationship.png differ diff --git a/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-observability.jpg b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-observability.jpg new file mode 100644 index 00000000..c0a78760 Binary files /dev/null and b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-observability.jpg differ diff --git a/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-sharing-spectrum.png b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-sharing-spectrum.png new file mode 100644 index 00000000..dad92cab Binary files /dev/null and b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/gpu-sharing-spectrum.png differ diff --git a/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/k8s-gpu-stack.png b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/k8s-gpu-stack.png new file mode 100644 index 00000000..03cd0a5b Binary files /dev/null and b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/k8s-gpu-stack.png differ diff --git a/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/nvidia-runtime-flow.png b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/nvidia-runtime-flow.png new file mode 100644 index 00000000..c03a2c94 Binary files /dev/null and b/public/img/blog/slicing-gpus-in-kubernetes-with-nvidia-mig/nvidia-runtime-flow.png differ diff --git a/public/img/sponsors/utho-logo-dark.png b/public/img/sponsors/utho-logo-dark.png new file mode 100644 index 00000000..458b66b4 Binary files /dev/null and b/public/img/sponsors/utho-logo-dark.png differ diff --git a/public/img/sponsors/utho-logo-light.png b/public/img/sponsors/utho-logo-light.png new file mode 100644 index 00000000..9bdd49a8 Binary files /dev/null and b/public/img/sponsors/utho-logo-light.png differ diff --git a/public/llms.txt b/public/llms.txt index 5ce998d9..2bdb4ee6 100644 --- a/public/llms.txt +++ b/public/llms.txt @@ -4,7 +4,7 @@ ## About -Kubesimplify is a community-driven publication on cloud-native technologies, with 190 in-depth technical articles by 62 practitioner authors. We cover Kubernetes (kubelet internals, scheduling, networking, operators), container runtimes (containerd, CRI-O, Docker), GitOps (Argo CD, Flux), service meshes, observability, AI/ML infrastructure on Kubernetes, GPU workloads, platform engineering, and the broader CNCF ecosystem. +Kubesimplify is a community-driven publication on cloud-native technologies, with 191 in-depth technical articles by 62 practitioner authors. We cover Kubernetes (kubelet internals, scheduling, networking, operators), container runtimes (containerd, CRI-O, Docker), GitOps (Argo CD, Flux), service meshes, observability, AI/ML infrastructure on Kubernetes, GPU workloads, platform engineering, and the broader CNCF ecosystem. Authoritative, practitioner-written, citation-friendly. Articles include code examples, diagrams, and references. @@ -34,10 +34,11 @@ Authoritative, practitioner-written, citation-friendly. Articles include code ex - Cloud Native Security: https://blog.kubesimplify.com/hub/security (network policies, Falco, Kyverno, SLSA supply-chain) - Linux Fundamentals: https://blog.kubesimplify.com/hub/linux (shell, sysadmin, networking primitives) -## Recent posts (most recent 30 of 190) +## Recent posts (most recent 30 of 191) - [Day 5: Local LLM Inference Engines, Wrappers, and What to Pick](https://blog.kubesimplify.com/day-5-local-llm-inference-engines-wrappers-and-what-to-pick) (2026-07-17). A beginner-friendly guide to local LLM inference, with the same Qwen model tested through Ollama, llama.cpp, Docker Model Runner, vLLM, SGLang, and TensorRT-LLM on NVIDIA DGX Spark. - [Bonsai 27B on RTX PRO 6000 vs DGX Spark: what actually works](https://blog.kubesimplify.com/bonsai-27b-rtx-pro-6000-dgx-spark) (2026-07-16). Real Bonsai 27B benchmarks on an RTX PRO 6000 and a DGX Spark, including the supported llama.cpp setup, ternary vs 1-bit results, and speculative decoding. +- [Slicing GPUs in Kubernetes with NVIDIA Multi-Instance GPU (MIG)](https://blog.kubesimplify.com/slicing-gpus-in-kubernetes-with-nvidia-mig) (2026-07-15). GPU sharing in Kubernetes explained: time-slicing vs MPS vs MIG, every nvidia-smi command to enable and disable MIG on one GPU or eight, GPU Operator automation, pitfalls, and DCGM monitoring. - [Introducing kiac: Real Kubernetes Nodes on Your Mac, Each Its Own Lightweight VM](https://blog.kubesimplify.com/introducing-kiac-kubernetes-in-apple-containers) (2026-07-06). kiac runs local Kubernetes on macOS where every node is its own lightweight VM via apple/container: kubeadm or k3s flavors, Cilium on a custom kernel, built-in LoadBalancer, Grafana, Gateway API, and clusters that survive reboots. - [LLM Costs and Observability with agentgateway on Kubernetes (Part 2)](https://blog.kubesimplify.com/llm-costs-and-observability-with-agentgateway-on-kubernetes) (2026-06-30). Part 2: scrape agentgateway with Prometheus, build a Grafana dashboard of token cost and per-tool usage, see blocked tool calls, and alert on spend. - [Controlling MCP Tools with agentgateway on Kubernetes (Part 1)](https://blog.kubesimplify.com/controlling-mcp-tools-with-agentgateway-on-kubernetes) (2026-06-29). Run AI agents behind agentgateway on Kubernetes: route their LLM and MCP tool calls through one proxy, keep secrets out of the agent, and block tools by policy. @@ -65,11 +66,10 @@ Authoritative, practitioner-written, citation-friendly. Articles include code ex - [What Claude Code's Leaked Source Actually Teaches Us About Building AI Agents](https://blog.kubesimplify.com/claude-code-leak-what-the-source-actually-teaches) (2026-04-01). 512K lines of TypeScript, verified against actual source. The engineering patterns in Claude Code's leaked codebase that most coverage got wrong. - [The Ingress NGINX Migration Just Got Easier: 119 Annotations, 3 Targets, Impact Ratings](https://blog.kubesimplify.com/ing-switch-119-annotations-gateway-api-traefik-impact-ratings) (2026-03-30). \"Ingress NGINX was archived March 24, 2026. ing-switch maps all 119 NGINX annotations with - [clawspark: Your Private OpenClaw AI Assistant That Never Phones Home](https://blog.kubesimplify.com/clawspark-your-private-openclaw-ai-assistant-that-never-phones-home) (2026-03-15). Clawspark provides a way to Install openclaw on your device in a secure way with a single command. -- [Here's What I Learned About Nemotron 3 Super -I Ran a 120B Parameter Model on Nvidia DGX Spark](https://blog.kubesimplify.com/nemotron3-on-dgx-spark) (2026-03-14). Understand everything about Nvidia DGX spark along with hands on and benchmarks. ## Topics covered (auto-derived from tags) -- kubernetes (95 articles): https://blog.kubesimplify.com/tag/kubernetes +- kubernetes (96 articles): https://blog.kubesimplify.com/tag/kubernetes - devops (71 articles): https://blog.kubesimplify.com/tag/devops - docker (31 articles): https://blog.kubesimplify.com/tag/docker - k8s (27 articles): https://blog.kubesimplify.com/tag/k8s @@ -80,10 +80,10 @@ Authoritative, practitioner-written, citation-friendly. Articles include code ex - llm (11 articles): https://blog.kubesimplify.com/tag/llm - cloud-native (11 articles): https://blog.kubesimplify.com/tag/cloud-native - security (11 articles): https://blog.kubesimplify.com/tag/security +- nvidia (9 articles): https://blog.kubesimplify.com/tag/nvidia - go (9 articles): https://blog.kubesimplify.com/tag/go - git (9 articles): https://blog.kubesimplify.com/tag/git - linux-for-beginners (9 articles): https://blog.kubesimplify.com/tag/linux-for-beginners -- nvidia (8 articles): https://blog.kubesimplify.com/tag/nvidia - github (8 articles): https://blog.kubesimplify.com/tag/github - terraform (8 articles): https://blog.kubesimplify.com/tag/terraform - dgxspark (7 articles): https://blog.kubesimplify.com/tag/dgxspark @@ -106,12 +106,12 @@ Authoritative, practitioner-written, citation-friendly. Articles include code ex - [Arnav Barman](https://blog.kubesimplify.com/author/arnav-barman) (5 posts) - [Srinivas Karnati](https://blog.kubesimplify.com/author/srinivas-karnati) (4 posts) - [Barkatul Mujauddin](https://blog.kubesimplify.com/author/barkatul-mujauddin) (4 posts) +- [Shubham Katara](https://blog.kubesimplify.com/author/shubham-katara) (3 posts) - [Santoshdts](https://blog.kubesimplify.com/author/santoshdts) (3 posts) - [Rishit Dagli](https://blog.kubesimplify.com/author/rishit-dagli) (3 posts) - [Bishal Das](https://blog.kubesimplify.com/author/bishal-das) (3 posts) - [Brijesh Kori](https://blog.kubesimplify.com/author/brijesh-kori) (3 posts) - [Hamees Sayed](https://blog.kubesimplify.com/author/hamees-sayed) (3 posts) -- [Batuhan Apaydın](https://blog.kubesimplify.com/author/batuhan-apaydin) (3 posts) ## Crawl policy diff --git a/public/rss.xml b/public/rss.xml index 49ea0cae..dbdee718 100644 --- a/public/rss.xml +++ b/public/rss.xml @@ -24,6 +24,14 @@ Real Bonsai 27B benchmarks on an RTX PRO 6000 and a DGX Spark, including the supported llama.cpp setup, ternary vs 1-bit results, and speculative decoding. aigpullminferencebenchmarks + + Slicing GPUs in Kubernetes with NVIDIA Multi-Instance GPU (MIG) + https://blog.kubesimplify.com/slicing-gpus-in-kubernetes-with-nvidia-mig + https://blog.kubesimplify.com/slicing-gpus-in-kubernetes-with-nvidia-mig + Wed, 15 Jul 2026 10:00:00 GMT + GPU sharing in Kubernetes explained: time-slicing vs MPS vs MIG, every nvidia-smi command to enable and disable MIG on one GPU or eight, GPU Operator automation, pitfalls, and DCGM monitoring. + kubernetesgpunvidiaplatform-engineering + Introducing kiac: Real Kubernetes Nodes on Your Mac, Each Its Own Lightweight VM https://blog.kubesimplify.com/introducing-kiac-kubernetes-in-apple-containers diff --git a/vercel.json b/vercel.json index b7432a51..d579f42a 100644 --- a/vercel.json +++ b/vercel.json @@ -881,6 +881,11 @@ "destination": "https://blog.kubesimplify.com/simplified-introduction-to-bacalhau", "permanent": true }, + { + "source": "/blog/slicing-gpus-in-kubernetes-with-nvidia-mig", + "destination": "https://blog.kubesimplify.com/slicing-gpus-in-kubernetes-with-nvidia-mig", + "permanent": true + }, { "source": "/blog/speeding-up-using-microk8s", "destination": "https://blog.kubesimplify.com/speeding-up-using-microk8s", @@ -2821,6 +2826,17 @@ } ] }, + { + "source": "/slicing-gpus-in-kubernetes-with-nvidia-mig", + "destination": "https://blog.kubesimplify.com/slicing-gpus-in-kubernetes-with-nvidia-mig", + "permanent": true, + "has": [ + { + "type": "host", + "value": "kubesimplify.com" + } + ] + }, { "source": "/speeding-up-using-microk8s", "destination": "https://blog.kubesimplify.com/speeding-up-using-microk8s",