diff --git a/app/blog/[slug]/page.js b/app/blog/[slug]/page.js
index 62a5bee66..3e8694e65 100644
--- a/app/blog/[slug]/page.js
+++ b/app/blog/[slug]/page.js
@@ -8,7 +8,6 @@ import { renderMarkdown } from '@/lib/markdown';
 import BlogReadingProgress from '@/components/BlogReadingProgress';
 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';
@@ -301,9 +300,6 @@ export default async function BlogPost({ params }) {
                   </div>
                 </section>
               )}
-
-              <CodeBlockEnhancer />
-
               <hr className="my-12" style={{ borderColor: 'var(--border-subtle)' }} />
 
               <SponsorCallout sponsor={post.sponsor} variant="cta" />
diff --git a/app/globals.css b/app/globals.css
index 87344354c..9b1d0bb36 100644
--- a/app/globals.css
+++ b/app/globals.css
@@ -405,6 +405,25 @@ a:focus-visible, button:focus-visible {
   margin: 1.5em auto;
 }
 
+.prose-blog .blog-video {
+  margin: 1.75em 0;
+}
+.prose-blog .blog-video video {
+  display: block;
+  width: 100%;
+  height: auto;
+  border-radius: 0.75rem;
+  border: 1px solid var(--border-subtle);
+  background: #05070a;
+}
+.prose-blog .blog-video figcaption {
+  margin-top: 0.65rem;
+  color: var(--text-secondary);
+  font-size: 0.875rem;
+  line-height: 1.5;
+  text-align: center;
+}
+
 .prose-blog hr {
   border: 0;
   height: 1px;
@@ -487,6 +506,10 @@ a:focus-visible, button:focus-visible {
   border-radius: 0 0 0.75rem 0.75rem;
   margin-top: 0;
 }
+.prose-blog [data-rehype-pretty-code-title] + .blog-code-block pre {
+  border-radius: 0 0 0.75rem 0.75rem;
+  margin-top: 0;
+}
 
 /* embedded iframes (youtube, codepens) */
 .prose-blog iframe {
diff --git a/components/CodeBlock.jsx b/components/CodeBlock.jsx
new file mode 100644
index 000000000..1288a4090
--- /dev/null
+++ b/components/CodeBlock.jsx
@@ -0,0 +1,43 @@
+'use client';
+
+import { useEffect, useRef, useState } from 'react';
+
+export default function CodeBlock({ children, ...props }) {
+  const preRef = useRef(null);
+  const resetTimerRef = useRef(null);
+  const [copied, setCopied] = useState(false);
+
+  useEffect(() => {
+    return () => {
+      if (resetTimerRef.current) clearTimeout(resetTimerRef.current);
+    };
+  }, []);
+
+  async function copyCode() {
+    const code = preRef.current?.innerText;
+    if (!code) return;
+
+    try {
+      await navigator.clipboard.writeText(code);
+      setCopied(true);
+      if (resetTimerRef.current) clearTimeout(resetTimerRef.current);
+      resetTimerRef.current = setTimeout(() => setCopied(false), 1500);
+    } catch {
+      // Clipboard access can be blocked by browser or page permissions.
+    }
+  }
+
+  return (
+    <div className="blog-code-block relative group">
+      <pre ref={preRef} {...props}>{children}</pre>
+      <button
+        type="button"
+        aria-label="Copy code"
+        className="absolute top-2 right-2 px-2 py-1 text-[11px] font-semibold rounded border border-white/20 bg-black/50 text-white/80 opacity-0 group-hover:opacity-100 focus:opacity-100 transition-opacity hover:bg-black/70"
+        onClick={copyCode}
+      >
+        {copied ? 'Copied!' : 'Copy'}
+      </button>
+    </div>
+  );
+}
diff --git a/components/CodeBlockEnhancer.jsx b/components/CodeBlockEnhancer.jsx
deleted file mode 100644
index aabd2a085..000000000
--- a/components/CodeBlockEnhancer.jsx
+++ /dev/null
@@ -1,35 +0,0 @@
-'use client';
-import { useEffect } from 'react';
-
-export default function CodeBlockEnhancer() {
-  useEffect(() => {
-    const blocks = document.querySelectorAll('article pre');
-    blocks.forEach((pre) => {
-      if (pre.dataset.enhanced) return;
-      pre.dataset.enhanced = '1';
-
-      const wrapper = document.createElement('div');
-      wrapper.className = 'relative group';
-      pre.parentNode.insertBefore(wrapper, pre);
-      wrapper.appendChild(pre);
-
-      const btn = document.createElement('button');
-      btn.type = 'button';
-      btn.setAttribute('aria-label', 'Copy code');
-      btn.className =
-        'absolute top-2 right-2 px-2 py-1 text-[11px] font-semibold rounded border border-white/20 bg-black/50 text-white/80 opacity-0 group-hover:opacity-100 transition-opacity hover:bg-black/70';
-      btn.textContent = 'Copy';
-      btn.addEventListener('click', async () => {
-        const code = pre.querySelector('code')?.innerText || pre.innerText;
-        try {
-          await navigator.clipboard.writeText(code);
-          btn.textContent = 'Copied!';
-          setTimeout(() => (btn.textContent = 'Copy'), 1500);
-        } catch {}
-      });
-      wrapper.appendChild(btn);
-    });
-  }, []);
-
-  return null;
-}
diff --git a/components/DynamicMigLifecycleAnimation.jsx b/components/DynamicMigLifecycleAnimation.jsx
new file mode 100644
index 000000000..c2581e601
--- /dev/null
+++ b/components/DynamicMigLifecycleAnimation.jsx
@@ -0,0 +1,314 @@
+const CURRENT_STEPS = [
+  { label: 'Discover', detail: 'NVML reports profiles and legal placements' },
+  { label: 'Reserve', detail: 'Scheduler selects the smallest fitting placement' },
+  { label: 'Create', detail: 'Device plugin creates that exact GI and CI' },
+  { label: 'Reclaim', detail: 'The pod ends and only its instance is removed' },
+];
+
+export default function DynamicMigLifecycleAnimation() {
+  return (
+    <figure className="dynamic-mig-lifecycle" aria-labelledby="dynamic-mig-lifecycle-title">
+      <style dangerouslySetInnerHTML={{ __html: `
+        .dynamic-mig-lifecycle {
+          margin: 2rem 0;
+          overflow: hidden;
+          border: 1px solid var(--border-subtle);
+          border-radius: 8px;
+          background: var(--bg-card);
+          box-shadow: var(--card-shadow);
+        }
+
+        .dynamic-mig-lifecycle * { box-sizing: border-box; }
+
+        .dynamic-mig-lifecycle__inner {
+          padding: clamp(1rem, 3vw, 1.6rem);
+        }
+
+        .dynamic-mig-lifecycle__eyebrow {
+          margin: 0 0 0.35rem;
+          color: #5d8f00;
+          font-size: 0.72rem;
+          font-weight: 900;
+          letter-spacing: 0.02em;
+          text-transform: uppercase;
+        }
+
+        .dark .dynamic-mig-lifecycle__eyebrow { color: #b2f2bb; }
+
+        .dynamic-mig-lifecycle__title {
+          margin: 0;
+          color: var(--text-primary);
+          font-size: clamp(1.15rem, 2.5vw, 1.55rem);
+          line-height: 1.25;
+        }
+
+        .dynamic-mig-lifecycle__subtitle {
+          max-width: 50rem;
+          margin: 0.55rem 0 1.15rem;
+          color: var(--text-secondary);
+          font-size: 0.92rem;
+          line-height: 1.6;
+        }
+
+        .dynamic-mig-lifecycle__request {
+          display: flex;
+          flex-wrap: wrap;
+          align-items: center;
+          justify-content: space-between;
+          gap: 0.6rem;
+          padding: 0.7rem 0.8rem;
+          border: 1px dashed color-mix(in srgb, #1971c2 75%, var(--border-medium));
+          border-radius: 6px;
+          background: color-mix(in srgb, #1971c2 6%, var(--bg-card));
+          color: var(--text-secondary);
+          font-size: 0.74rem;
+        }
+
+        .dynamic-mig-lifecycle__request strong { color: var(--text-primary); }
+
+        .dynamic-mig-lifecycle__request code {
+          color: #1971c2;
+          font-size: 0.74rem;
+          font-weight: 900;
+        }
+
+        .dark .dynamic-mig-lifecycle__request code { color: #74c0fc; }
+
+        .dynamic-mig-lifecycle__flow {
+          display: grid;
+          grid-template-columns: repeat(4, minmax(0, 1fr));
+          gap: 0.65rem;
+          margin-top: 0.85rem;
+        }
+
+        .dynamic-mig-lifecycle__step {
+          position: relative;
+          min-width: 0;
+          min-height: 7.2rem;
+          padding: 0.75rem;
+          border: 1px solid color-mix(in srgb, #1971c2 45%, var(--border-subtle));
+          border-radius: 5px 8px 4px 7px;
+          background: var(--bg-card);
+          animation: dynamicMigStepPulse 7s ease-in-out infinite;
+          animation-delay: calc(var(--step) * 1.15s);
+        }
+
+        .dynamic-mig-lifecycle__step:not(:last-child)::after {
+          content: '→';
+          position: absolute;
+          z-index: 2;
+          top: 50%;
+          right: -0.62rem;
+          display: grid;
+          place-items: center;
+          width: 0.9rem;
+          height: 0.9rem;
+          border-radius: 50%;
+          background: var(--bg-card);
+          color: #1971c2;
+          font-size: 0.82rem;
+          font-weight: 950;
+          transform: translateY(-50%);
+        }
+
+        .dynamic-mig-lifecycle__step-number {
+          display: grid;
+          place-items: center;
+          width: 1.45rem;
+          height: 1.45rem;
+          margin-bottom: 0.5rem;
+          border: 1px solid #1971c2;
+          border-radius: 50%;
+          background: color-mix(in srgb, #1971c2 12%, var(--bg-card));
+          color: #1971c2;
+          font-size: 0.67rem;
+          font-weight: 950;
+        }
+
+        .dark .dynamic-mig-lifecycle__step-number { color: #74c0fc; }
+
+        .dynamic-mig-lifecycle__step strong,
+        .dynamic-mig-lifecycle__step span { display: block; }
+
+        .dynamic-mig-lifecycle__step strong {
+          color: var(--text-primary);
+          font-size: 0.76rem;
+        }
+
+        .dynamic-mig-lifecycle__step span {
+          margin-top: 0.18rem;
+          color: var(--text-secondary);
+          font-size: 0.66rem;
+          line-height: 1.35;
+        }
+
+        .dynamic-mig-lifecycle__gpu {
+          margin-top: 0.9rem;
+          padding: 0.85rem;
+          border: 2px solid #495057;
+          border-radius: 6px 9px 5px 8px;
+          background: color-mix(in srgb, #868e96 7%, var(--bg-elevated));
+        }
+
+        .dynamic-mig-lifecycle__gpu-head {
+          display: flex;
+          flex-wrap: wrap;
+          align-items: center;
+          justify-content: space-between;
+          gap: 0.4rem;
+          margin-bottom: 0.65rem;
+          color: var(--text-secondary);
+          font-size: 0.68rem;
+        }
+
+        .dynamic-mig-lifecycle__gpu-head strong {
+          color: var(--text-primary);
+          font-size: 0.76rem;
+        }
+
+        .dynamic-mig-lifecycle__placements {
+          display: grid;
+          grid-template-columns: 2fr 1fr 1fr;
+          gap: 0.35rem;
+        }
+
+        .dynamic-mig-lifecycle__placement {
+          display: grid;
+          place-items: center;
+          min-width: 0;
+          min-height: 5.2rem;
+          padding: 0.45rem;
+          border: 1px solid var(--placement-color);
+          border-radius: 4px 7px 3px 6px;
+          background: color-mix(in srgb, var(--placement-color) 13%, var(--bg-card));
+          color: var(--text-primary);
+          text-align: center;
+          animation: dynamicMigPlacementPulse 7s ease-in-out infinite;
+          animation-delay: var(--placement-delay);
+        }
+
+        .dynamic-mig-lifecycle__placement--free {
+          border-style: dashed;
+          background: var(--bg-card);
+          animation: none;
+        }
+
+        .dynamic-mig-lifecycle__placement strong,
+        .dynamic-mig-lifecycle__placement span { display: block; }
+
+        .dynamic-mig-lifecycle__placement strong {
+          color: var(--placement-color);
+          font-size: 0.72rem;
+        }
+
+        .dynamic-mig-lifecycle__placement span {
+          margin-top: 0.2rem;
+          color: var(--text-secondary);
+          font-size: 0.6rem;
+          line-height: 1.3;
+        }
+
+        .dynamic-mig-lifecycle__takeaway {
+          margin: 0.9rem 0 0;
+          padding: 0.72rem 0.82rem;
+          border-left: 4px solid #087f5b;
+          background: color-mix(in srgb, #087f5b 8%, var(--bg-card));
+          color: var(--text-secondary);
+          font-size: 0.78rem;
+          line-height: 1.5;
+        }
+
+        .dynamic-mig-lifecycle__takeaway strong { color: var(--text-primary); }
+
+        @keyframes dynamicMigStepPulse {
+          0%, 12%, 100% { box-shadow: none; transform: translateY(0); }
+          20%, 34% {
+            box-shadow: 0 0 0 4px color-mix(in srgb, #1971c2 15%, transparent);
+            transform: translateY(-2px);
+          }
+        }
+
+        @keyframes dynamicMigPlacementPulse {
+          0%, 45%, 100% { opacity: 0.72; transform: scale(0.985); }
+          55%, 85% { opacity: 1; transform: scale(1); }
+        }
+
+        @media (max-width: 800px) {
+          .dynamic-mig-lifecycle__flow { grid-template-columns: repeat(2, minmax(0, 1fr)); }
+          .dynamic-mig-lifecycle__step:nth-child(2)::after { display: none; }
+        }
+
+        @media (max-width: 520px) {
+          .dynamic-mig-lifecycle__flow { grid-template-columns: 1fr; }
+          .dynamic-mig-lifecycle__step { min-height: 0; }
+          .dynamic-mig-lifecycle__step::after { display: none !important; }
+          .dynamic-mig-lifecycle__placements { grid-template-columns: 2fr 1fr; }
+          .dynamic-mig-lifecycle__placement--free { display: none; }
+        }
+
+        @media (prefers-reduced-motion: reduce) {
+          .dynamic-mig-lifecycle__step,
+          .dynamic-mig-lifecycle__placement { animation: none !important; }
+        }
+      ` }} />
+
+      <div className="dynamic-mig-lifecycle__inner">
+        <p className="dynamic-mig-lifecycle__eyebrow">Verified per-pod lifecycle</p>
+        <h3 className="dynamic-mig-lifecycle__title" id="dynamic-mig-lifecycle-title">
+          How one request becomes one hardware instance
+        </h3>
+        <p className="dynamic-mig-lifecycle__subtitle">
+          This is the topology-aware flow verified in this lab: discover, reserve, create, and reclaim one legal placement for one pod.
+        </p>
+
+        <div aria-hidden="true">
+          <div className="dynamic-mig-lifecycle__request">
+            <strong>Incoming Kubernetes pod</strong>
+            <code>gpu: 1 · gpumem: 8000 · mode: mig</code>
+          </div>
+
+          <div className="dynamic-mig-lifecycle__flow">
+            {CURRENT_STEPS.map((step, index) => (
+              <div className="dynamic-mig-lifecycle__step" style={{ '--step': index }} key={step.label}>
+                <span className="dynamic-mig-lifecycle__step-number">{index + 1}</span>
+                <strong>{step.label}</strong>
+                <span>{step.detail}</span>
+              </div>
+            ))}
+          </div>
+
+          <div className="dynamic-mig-lifecycle__gpu">
+            <div className="dynamic-mig-lifecycle__gpu-head">
+              <strong>Verified mixed placement on GPU 4</strong>
+              <span>NVML placement intervals · not GiB</span>
+            </div>
+            <div className="dynamic-mig-lifecycle__placements">
+              <div className="dynamic-mig-lifecycle__placement" style={{ '--placement-color': '#1971c2', '--placement-delay': '2.2s' }}>
+                <div>
+                  <strong>2g.48gb</strong>
+                  <span>start 0 · size 6</span>
+                </div>
+              </div>
+              <div className="dynamic-mig-lifecycle__placement dynamic-mig-lifecycle__placement--free" style={{ '--placement-color': '#868e96' }}>
+                <div>
+                  <strong>free</strong>
+                  <span>start 6 · size 3</span>
+                </div>
+              </div>
+              <div className="dynamic-mig-lifecycle__placement" style={{ '--placement-color': '#5d8f00', '--placement-delay': '3.35s' }}>
+                <div>
+                  <strong>1g.24gb</strong>
+                  <span>start 9 · size 3</span>
+                </div>
+              </div>
+            </div>
+          </div>
+        </div>
+
+        <p className="dynamic-mig-lifecycle__takeaway">
+          <strong>Smallest fitting profile, legal free placement, exact cleanup.</strong> Deleting the 1g pod reclaimed only its GI/CI while the neighboring 2g CUDA workload continued.
+        </p>
+      </div>
+    </figure>
+  );
+}
diff --git a/content/blog/dynamic-mig-in-kubernetes-with-hami.md b/content/blog/dynamic-mig-in-kubernetes-with-hami.md
new file mode 100644
index 000000000..2d0ce0f47
--- /dev/null
+++ b/content/blog/dynamic-mig-in-kubernetes-with-hami.md
@@ -0,0 +1,925 @@
+---
+title: "HAMi Dynamic MIG on RTX PRO 6000: A Live Kubernetes Test"
+seoTitle: "HAMi Dynamic MIG on Kubernetes: RTX PRO 6000 Live Test"
+seoDescription: "A hands-on test of topology-aware HAMi Dynamic MIG on RTX PRO 6000 Blackwell, with pinned setup commands, real allocations, mixed profiles, reclamation, and recovery."
+datePublished: 2026-08-11T10:00:00.000Z
+slug: dynamic-mig-in-kubernetes-with-hami
+author: shubham-katara
+authors: ["shubham-katara", "saiyam-pathak"]
+cover: /img/blog/dynamic-mig-in-kubernetes-with-hami/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."
+---
+
+The first two posts in this series explored opposite ends of GPU sharing.
+
+In [the MIG deep dive](/blog/slicing-gpus-in-kubernetes-with-nvidia-mig), we carved Blackwell cards into hardware-isolated slices. MIG gives each instance dedicated memory, cache, and compute resources, but a static layout makes profile changes an operational task. In [the HAMi vGPU post](/blog/sharing-gpus-in-kubernetes-with-hami), we requested exact memory and compute fractions through software-enforced `hami-core` mode. That improves packing density, but it is not a hardware isolation boundary.
+
+The natural third question is: can a Kubernetes pod request GPU memory, receive a real MIG instance, and let HAMi manage that instance from creation to cleanup?
+
+We reran that experiment from scratch on August 11, 2026, on an eight-GPU RTX PRO 6000 Blackwell server. This post follows HAMi's topology-aware, per-pod Dynamic MIG implementation from installation through cleanup.
+
+The results were straightforward:
+
+- Four 8,000 MiB requests became four `1g.24gb` instances on one GPU.
+- A fifth identical pod moved to a second GPU after we made that GPU available to HAMi.
+- A `1g.24gb` workload and a `2g.48gb` workload ran together on the same card.
+- Deleting the small workload reclaimed only its MIG instance; the neighboring CUDA workload continued.
+- A valid active allocation survived a HAMi device-plugin restart with the same MIG UUID and continued CUDA progress.
+
+> **Version and migration note:** [PR #2378](https://github.com/Project-HAMi/HAMi/pull/2378) is merged, and this post tests the resulting per-pod implementation at [commit `634bf2b32e68`](https://github.com/Project-HAMi/HAMi/commit/634bf2b32e68e07d3fbcbd6da1ee079392fc07c1). At the time of this rerun, the latest tagged release was `v2.9.0`, which predates that implementation, so reproducing the lab requires the pinned source build below. Once HAMi publishes a release containing PR #2378, prefer its matching official chart and image. Existing `knownMigGeometries` users should follow the [migration guide](https://github.com/Project-HAMi/HAMi/blob/634bf2b32e68e07d3fbcbd6da1ee079392fc07c1/docs/develop/dynamic-mig-migration.md); the walkthrough below covers only the merged per-pod design.
+
+{{dynamic-mig-lifecycle-animation}}
+
+## Dynamic MIG in one sentence
+
+A pod asks for GPU memory. HAMi chooses the smallest allowed MIG profile that has enough NVML-reported memory and a legal free placement, then creates that exact GPU Instance (GI) and Compute Instance (CI) for the pod.
+
+The workload request remains small:
+
+```yaml
+metadata:
+  annotations:
+    nvidia.com/vgpu-mode: "mig"
+spec:
+  schedulerName: hami-scheduler
+  containers:
+    - resources:
+        limits:
+          nvidia.com/gpu: 1
+          nvidia.com/gpumem: 8000
+```
+
+On a `hami-core` node, `gpumem: 8000` is a software-enforced memory limit. On a Dynamic MIG node, it is a minimum memory requirement used to select a hardware profile. This GPU has no 8 GB profile, so the 8,000 MiB request receives `1g.24gb`; the container sees the complete 24,192 MiB MIG instance.
+
+Three details matter:
+
+- `nvidia.com/vgpu-mode: "mig"` explicitly selects the MIG path.
+- Profile selection is memory-driven. `nvidia.com/gpucores` does not select a MIG profile; the profile fixes the compute fraction in hardware.
+- NVIDIA's legal profile sizes and placements still apply. HAMi automates those rules; it does not remove them.
+
+## Why use Dynamic MIG instead of HAMi-Core?
+
+NVIDIA MIG divides a supported GPU into hardware-isolated instances. Each instance receives dedicated memory paths, cache, and compute resources. That is a stronger boundary than several workloads sharing one full GPU through software.
+
+| | HAMi-Core | Topology-aware Dynamic MIG |
+| --- | --- | --- |
+| Isolation | Software-enforced sharing | NVIDIA MIG hardware instance |
+| Size choices | Fine-grained memory and core fractions | Fixed NVIDIA profiles |
+| Pod request | `gpu`, `gpumem`, optional `gpucores` | `gpu`, `gpumem`, and MIG mode annotation |
+| Lifecycle | Software allocation | Create and reclaim one GI/CI per pod |
+| Best fit | High packing flexibility | Stronger workload isolation |
+
+MIG can be part of a multi-tenant security design, but it does not make a platform secure or compliant by itself. Identity, admission, network, storage, runtime, and host controls still matter.
+
+## The RTX PRO 6000 profile menu
+
+NVIDIA's [supported MIG profile table](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/supported-mig-profiles.html) lists three profile sizes for the RTX PRO 6000 Blackwell Server Edition:
+
+| Profile | Approximate memory | SM fraction | Maximum instances |
+| --- | ---: | ---: | ---: |
+| `1g.24gb` | 24 GB | 1/4 | 4 |
+| `2g.48gb` | 48 GB | 1/2 | 2 |
+| `4g.96gb` | 96 GB | Full GPU | 1 |
+
+Profile rounding remains. An 8,000 MiB request receives the 24 GB profile, and the unused difference cannot be assigned to another pod inside that instance.
+
+The implementation tested here uses a profile allowlist as policy:
+
+```yaml
+nvidia:
+  migProfileAllowlist:
+    - models: ["RTX PRO 6000 Blackwell Server Edition"]
+      profiles: ["1g.24gb", "2g.48gb", "4g.96gb"]
+```
+
+For every allowed profile, the HAMi device plugin running on the GPU node asks NVIDIA's Management Library (NVML) for memory, compute metadata, instance count, and legal placements. The scheduler then chooses the smallest profile that satisfies the request and fits without overlapping a live placement.
+
+## Lab environment
+
+| Component | Tested value |
+| --- | --- |
+| Server | Utho single-node GPU server |
+| GPUs | 8 × NVIDIA RTX PRO 6000 Blackwell Server Edition |
+| GPU memory | 97,887 MiB per physical GPU |
+| NVIDIA driver | `610.43.02` |
+| Kubernetes | `v1.35.6` |
+| OS | Ubuntu 24.04.4 LTS, kernel `6.8.0-100-generic` |
+| Container runtime | containerd `2.2.1` |
+| HAMi source | `634bf2b32e68e07d3fbcbd6da1ee079392fc07c1` |
+
+The run started with MIG mode enabled on all eight cards and no active CUDA processes:
+
+```bash
+nvidia-smi \
+  --query-gpu=index,name,uuid,driver_version,memory.total,mig.mode.current \
+  --format=csv
+
+nvidia-smi \
+  --query-compute-apps=gpu_uuid,pid,process_name,used_gpu_memory \
+  --format=csv
+```
+
+The first command inventories the hardware and MIG mode. It returned all eight cards:
+
+```text
+index, name, uuid, driver_version, memory.total [MiB], mig.mode.current
+0, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-8b89b58e-b427-108d-ac50-06138d78fe78, 610.43.02, 97887 MiB, Enabled
+1, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-03a041b7-8abf-360a-d1a2-dfd70188cd5f, 610.43.02, 97887 MiB, Enabled
+2, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-ba09367f-dd50-32ca-e988-7ff66bece885, 610.43.02, 97887 MiB, Enabled
+3, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-30512c46-708b-f374-5698-ee24be6cd626, 610.43.02, 97887 MiB, Enabled
+4, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288, 610.43.02, 97887 MiB, Enabled
+5, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-04dc48d7-7048-aef5-ad36-f5db716e7668, 610.43.02, 97887 MiB, Enabled
+6, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-f4f5db98-143f-0a8d-47ce-956fab39a736, 610.43.02, 97887 MiB, Enabled
+7, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-f4c61521-240a-da09-2787-e576034e197e, 610.43.02, 97887 MiB, Enabled
+```
+
+The second command checks for active compute processes before any lifecycle operation. Its real output contained only the header:
+
+```text
+gpu_uuid, pid, process_name, used_gpu_memory [MiB]
+```
+
+That means no CUDA compute process was active at that instant.
+
+> **Host versus cluster commands:** run host-level `nvidia-smi`, Docker, and `ctr` commands on the GPU node. Run `kubectl` and Helm from any machine whose kubeconfig targets the intended cluster. In this lab they all ran on the single RTX node.
+
+## Pin the HAMi build before testing
+
+This step exposed the easiest version trap in the entire lab. At commit `634bf2b`, the checked-out chart and source contain topology-aware Dynamic MIG, but the chart metadata and default image tag still say `2.9.0`. Rendering that chart without image overrides deploys the `v2.9.0` binaries, not the code in the checkout.
+
+Helm's chart or app version is therefore not proof of the running binary. We built the commit and used the same pinned image for the scheduler extender, device plugin, and monitor.
+
+### 1. Back up and inventory the existing installation
+
+Before changing a running lab, capture both Helm's saved values and the live objects. They can differ:
+
+```bash
+export NODE=utho-gpu-rtxpro6000-8-62383
+export LAB=/root/hami-dynamic-mig-rerun-2026-08-11
+
+mkdir -p "$LAB"
+
+helm get values hami -n hami-system --all -o yaml \
+  > "$LAB/helm-values-before.yaml"
+helm get manifest hami -n hami-system \
+  > "$LAB/helm-manifest-before.yaml"
+kubectl get configmaps -n hami-system -o yaml \
+  > "$LAB/live-configmaps-before.yaml"
+kubectl get node "$NODE" -o yaml \
+  > "$LAB/node-before.yaml"
+kubectl get pods -A --field-selector spec.nodeName="$NODE" -o wide
+nvidia-smi -L > "$LAB/nvidia-smi-L-before.txt"
+```
+
+After taking the backups, we stopped every GPU workload and verified that the entire node was idle before continuing.
+
+### 2. Build the exact source snapshot
+
+```bash
+export HAMI_SHA=634bf2b32e68e07d3fbcbd6da1ee079392fc07c1
+export HAMI_TAG=master-634bf2b32e68
+export HAMI_IMAGE=localhost/hami-dynamic-mig:$HAMI_TAG
+
+git clone --recurse-submodules \
+  https://github.com/Project-HAMi/HAMi.git "$LAB/HAMi"
+git -C "$LAB/HAMi" checkout --detach "$HAMI_SHA"
+git -C "$LAB/HAMi" submodule update --init --recursive
+
+make -C "$LAB/HAMi" docker \
+  IMG_NAME=localhost/hami-dynamic-mig \
+  IMG_TAG="$HAMI_TAG" \
+  VERSION="$HAMI_TAG" \
+  TARGET_PLATFORMS=linux/amd64
+
+docker image inspect "$HAMI_IMAGE" \
+  --format='ID={{.Id}} Architecture={{.Architecture}} SizeBytes={{.Size}}'
+```
+
+The final command verifies what was built. Our result was:
+
+```text
+ID=sha256:0ddda56e333ff74e52d9908e00b85e7860cf4694fc09951aaa178e8c8e6dde76 Architecture=amd64 SizeBytes=411671341
+```
+
+For a normal multi-node cluster, push that immutable tag to a registry every target node can reach. Our single-node lab instead imported the image into containerd:
+
+```bash
+docker save --output "$LAB/hami-$HAMI_TAG.tar" "$HAMI_IMAGE"
+sudo ctr --namespace k8s.io images import "$LAB/hami-$HAMI_TAG.tar"
+sudo ctr --namespace k8s.io images list | grep -F "$HAMI_IMAGE"
+```
+
+That local import is suitable only because the scheduler, plugin, and both tested GPUs lived on the same node. `localhost/...` is not an image that another node can pull. On multiple nodes, push the pinned build to a registry or import it on every target node.
+
+### 3. Use current Dynamic MIG values
+
+The relevant parts of our `hami-current-mig-values.yaml` were:
+
+```yaml
+global:
+  imageTag: master-634bf2b32e68
+
+scheduler:
+  defaultSchedulerPolicy:
+    nodeSchedulerPolicy: binpack
+    gpuSchedulerPolicy: binpack
+  extender:
+    image:
+      registry: localhost
+      repository: hami-dynamic-mig
+      tag: master-634bf2b32e68
+      pullPolicy: Never
+
+devicePlugin:
+  image:
+    registry: localhost
+    repository: hami-dynamic-mig
+    tag: master-634bf2b32e68
+    pullPolicy: Never
+  monitor:
+    image:
+      registry: localhost
+      repository: hami-dynamic-mig
+      tag: master-634bf2b32e68
+      pullPolicy: Never
+
+  # This is NVIDIA's static resource-exposure strategy.
+  # Keep it separate from HAMi's per-node operating mode below.
+  migStrategy: none
+
+  nodeConfiguration:
+    config: |
+      {
+        "nodeconfig": [
+          {
+            "name": "utho-gpu-rtxpro6000-8-62383",
+            "operatingmode": "mig",
+            "devicememoryscaling": 1,
+            "devicecorescaling": 1,
+            "devicesplitcount": 10,
+            "preconfigureddevicememory": 0,
+            "enablenumatopology": false,
+            "migstrategy": "none",
+            "filterdevices": {
+              "uuid": [],
+              "index": [0, 1, 2, 3, 5, 6, 7]
+            },
+            "enablegetpreferredallocation": false
+          }
+        ]
+      }
+
+# Empty means: use the device-config.yaml bundled in this pinned chart.
+device-config:
+  content: ""
+```
+
+Two similarly named settings do different jobs:
+
+- `operatingmode: "mig"` activates HAMi Dynamic MIG for this node.
+- Top-level `devicePlugin.migStrategy: none` tells the NVIDIA device-plugin path not to publish pre-created MIG resources separately. The workload still requests the parent resource `nvidia.com/gpu` and HAMi creates the MIG instance dynamically.
+
+Also, `filterdevices.index` is an **exclusion list**. The initial list excluded every card except GPU 4. It did not protect the excluded GPUs from all startup actions; we return to that safety boundary later.
+
+### 4. Render before installing
+
+```bash
+helm lint "$LAB/HAMi/charts/hami" \
+  -f "$LAB/hami-current-mig-values.yaml"
+
+helm template hami "$LAB/HAMi/charts/hami" \
+  --namespace hami-system \
+  --kube-version 1.35.6 \
+  -f "$LAB/hami-current-mig-values.yaml" \
+  > "$LAB/rendered-current-hami.yaml"
+
+grep -n -A 25 'migProfileAllowlist' \
+  "$LAB/rendered-current-hami.yaml"
+grep -n -E 'image:|imagePullPolicy:' \
+  "$LAB/rendered-current-hami.yaml"
+```
+
+The rendered manifest contained the RTX profile allowlist and the pinned image in all three HAMi containers. No `projecthami/hami:v2.9.0` runtime image remained.
+
+Avoid `--reuse-values` here. A saved per-component tag takes precedence over `global.imageTag`, so a stale custom plugin image can survive even when the global tag looks correct.
+
+### 5. Perform the controlled lab handover
+
+> **Destructive lab step:** we used a fresh reinstall only after every GPU pod and process on the single node was gone. Existing clusters should follow the linked migration guide instead of treating `helm uninstall` as a general upgrade procedure.
+
+```bash
+helm uninstall hami -n hami-system --wait --timeout 5m
+
+helm upgrade --install hami "$LAB/HAMi/charts/hami" \
+  -n hami-system \
+  --create-namespace \
+  --reset-values \
+  -f "$LAB/hami-current-mig-values.yaml" \
+  --wait \
+  --timeout 10m
+
+kubectl get pods -n hami-system \
+  -o custom-columns='POD:.metadata.name,CONTAINERS:.spec.containers[*].name,IMAGES:.spec.containers[*].image'
+```
+
+The live output confirmed that the scheduler extender, device plugin, and monitor all used:
+
+```text
+localhost/hami-dynamic-mig:master-634bf2b32e68
+```
+
+The monitor had one transient CDI `StartError` referring to a stale MIG UUID during the handover. Kubernetes retried it, and both plugin containers became ready. We checked the previous container state instead of hiding that transition.
+
+## What HAMi discovered through NVML
+
+The node registration annotation is the clearest view of what the plugin learned from the driver:
+
+```bash
+kubectl get node "$NODE" -o json |
+jq '
+  .metadata.annotations["hami.io/node-nvidia-register"]
+  | fromjson
+  | .[]
+  | {id, index, type, mode, count, migProfiles}
+'
+```
+
+The live discovery was:
+
+| Profile | `memoryMB` | Core | `sliceCount` | Legal NVML placements (`start`, `size`) |
+| --- | ---: | ---: | ---: | --- |
+| `1g.24gb` | 24,192 | 25 | 1 | `(0,3)`, `(3,3)`, `(6,3)`, `(9,3)` |
+| `2g.48gb` | 48,512 | 50 | 2 | `(0,6)`, `(6,6)` |
+| `4g.96gb` | 97,408 | 100 | 4 | `(0,12)` |
+
+NVML reports each legal placement as `start` and `size`: `start` is the index of the first occupied memory slice, and `size` is the number of memory slices occupied. Together they describe the half-open interval `[start, start + size)`. On this RTX PRO 6000, the reported placement range was `[0,12)`; these values are not GiB and are specific to this GPU. Also, `size` is not the same thing as `sliceCount`: `1g.24gb` has `sliceCount: 1` but placement `size: 3` here.
+
+The registered `count: 4` is a coarse maximum derived from the profiles. It does not mean every arbitrary combination of four profiles fits. The placement arrays and current occupancy determine real capacity.
+
+## A repeatable CUDA workload
+
+The test container repeatedly runs NVIDIA's `vectorAdd` sample and increments `/tmp/gpu-progress` after each successful run. That gives us a better health check than a sleeping container.
+
+For readability, this Deployment combines the same workload template we used for the single-pod and packing tests. Save it as `mig-small-pack.yaml` and replace the node name if yours differs:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: mig-small-pack
+  namespace: hami-mig-retest
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: mig-small-pack
+  template:
+    metadata:
+      labels:
+        app: mig-small-pack
+      annotations:
+        nvidia.com/vgpu-mode: "mig"
+        hami.io/gpu-scheduler-policy: "binpack"
+    spec:
+      schedulerName: hami-scheduler
+      nodeSelector:
+        kubernetes.io/hostname: utho-gpu-rtxpro6000-8-62383
+      containers:
+        - name: cuda
+          image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04
+          imagePullPolicy: IfNotPresent
+          command:
+            - bash
+            - -lc
+            - |
+              set -euo pipefail
+              n=0
+              echo 0 > /tmp/gpu-progress
+              while true; do
+                /cuda-samples/vectorAdd > /tmp/vectoradd.last 2>&1
+                n=$((n + 1))
+                echo "$n" > /tmp/gpu-progress.next
+                mv /tmp/gpu-progress.next /tmp/gpu-progress
+              done
+          resources:
+            limits:
+              nvidia.com/gpu: 1
+              nvidia.com/gpumem: 8000
+```
+
+Create the namespace, apply the workload, and wait for the pod to become ready:
+
+```bash
+kubectl create namespace hami-mig-retest
+kubectl apply -f mig-small-pack.yaml
+kubectl rollout status deployment/mig-small-pack \
+  -n hami-mig-retest --timeout=180s
+
+POD=$(kubectl get pods -n hami-mig-retest \
+  -l app=mig-small-pack \
+  -o jsonpath='{.items[0].metadata.name}')
+```
+
+## Test 1: 8,000 MiB becomes one `1g.24gb` instance
+
+HAMi writes its controller-owned identity to `hami.io/vgpu-mig-allocations`. Users should inspect this annotation, but never create or edit it:
+
+```bash
+kubectl get pod "$POD" -n hami-mig-retest -o json |
+jq '.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson'
+```
+
+Our first allocation was:
+
+```json
+[
+  {
+    "containerIndex": 0,
+    "deviceIndex": 0,
+    "gpuUUID": "GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288",
+    "profile": "1g.24gb",
+    "placement": {"start": 9, "size": 3},
+    "migUUID": "MIG-a5fa6120-f6fa-51b6-9820-a42112640629",
+    "gpuInstanceID": 6,
+    "computeInstanceID": 0
+  }
+]
+```
+
+The host and container agreed about the device:
+
+```bash
+# On the GPU node
+nvidia-smi -L
+
+# Through the container's device view
+kubectl exec -n hami-mig-retest "$POD" -- nvidia-smi -L
+```
+
+Both showed one `1g.24gb` instance with UUID `MIG-a5fa...`. The placement happened to start at `9`; the first allocation is not required to start at `0`.
+
+Finally, we verified that the CUDA loop was doing work:
+
+```bash
+before=$(kubectl exec -n hami-mig-retest "$POD" -- cat /tmp/gpu-progress)
+sleep 3
+after=$(kubectl exec -n hami-mig-retest "$POD" -- cat /tmp/gpu-progress)
+printf 'before=%s after=%s\n' "$before" "$after"
+test "$after" -gt "$before"
+```
+
+```text
+before=75 after=77
+```
+
+## Test 2: four legal placements, then real saturation
+
+Scale the same Deployment to four replicas:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=4
+kubectl rollout status deployment/mig-small-pack \
+  -n hami-mig-retest --timeout=180s
+nvidia-smi -L
+```
+
+GPU 4 now contained four `1g.24gb` instances. The allocation annotations used all four legal starts:
+
+```bash
+kubectl get pods -n hami-mig-retest -l app=mig-small-pack -o json |
+jq -r '
+  ["PARENT_GPU", "PROFILE", "START", "SIZE"],
+  (
+    .items[]
+    | (.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson | .[0]) as $a
+    | [$a.gpuUUID, $a.profile, ($a.placement.start | tostring), ($a.placement.size | tostring)]
+  )
+  | @tsv
+'
+```
+
+```text
+PARENT_GPU                                   PROFILE    START  SIZE
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   0      3
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   3      3
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   6      3
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   9      3
+```
+
+<figure class="blog-video">
+  <video controls muted playsinline preload="metadata" aria-label="Four 1g.24gb MIG instances created on one RTX PRO 6000 GPU">
+    <source src="/img/blog/dynamic-mig-in-kubernetes-with-hami/4mig.mp4" type="video/mp4" />
+    Your browser does not support embedded MP4 video. You can <a href="/img/blog/dynamic-mig-in-kubernetes-with-hami/4mig.mp4">open the recording directly</a>.
+  </video>
+  <figcaption>Four pods fill the four legal <code>1g.24gb</code> placements on GPU 4.</figcaption>
+</figure>
+
+With only GPU 4 registered, scaling to five did **not** overcommit the card:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=5
+kubectl get pods -n hami-mig-retest -o wide
+```
+
+Four pods remained `Running`; the fifth stayed `Pending` and unbound. Its event included:
+
+```text
+0/1 nodes are available: 1 1/1 CardTimeSlicingExhausted.
+```
+
+That inherited event label is misleading—the test did not use time slicing. Here it meant that no legal MIG placement remained on any registered GPU.
+
+Scale back to four before the next test:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=4
+```
+
+## Test 3: mixed profiles share one physical GPU
+
+The topology-aware implementation can place different profiles together whenever NVML reports legal, non-overlapping placements.
+
+<figure class="blog-video">
+  <video controls muted playsinline preload="metadata" aria-label="Live HAMi Dynamic MIG test with 8000 MiB and 30000 MiB pod requests on one RTX PRO 6000 GPU">
+    <source src="/img/blog/dynamic-mig-in-kubernetes-with-hami/mixed-profiles-lifecycle.mp4" type="video/mp4" />
+    Your browser does not support embedded MP4 video. You can <a href="/img/blog/dynamic-mig-in-kubernetes-with-hami/mixed-profiles-lifecycle.mp4">open the recording directly</a>.
+  </video>
+  <figcaption>A live terminal recording: requests for 8,000 MiB and 30,000 MiB become <code>1g.24gb</code> and <code>2g.48gb</code> instances on the same GPU. Each instance is reclaimed when its requesting pod is deleted; the recording is shown at 2.5&times; speed to shorten the waits.</figcaption>
+</figure>
+
+We cleared the small-pod Deployment, then created an 8,000 MiB pod and a 30,000 MiB pod. Both used the same CUDA loop and were pinned to GPU 4 with `nvidia.com/use-gpuuuid` so the test measured one physical card:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=0
+kubectl wait -n hami-mig-retest \
+  --for=delete pod -l app=mig-small-pack --timeout=180s
+```
+
+This Bash helper creates the same pod twice; only its name and memory request change:
+
+```bash
+export GPU4=GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288
+
+create_mig_pod() {
+  local name="$1"
+  local memory="$2"
+
+  kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: ${name}
+  namespace: hami-mig-retest
+  annotations:
+    nvidia.com/vgpu-mode: "mig"
+    hami.io/gpu-scheduler-policy: "binpack"
+    nvidia.com/use-gpuuuid: "${GPU4}"
+spec:
+  schedulerName: hami-scheduler
+  nodeSelector:
+    kubernetes.io/hostname: ${NODE}
+  containers:
+    - name: cuda
+      image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04
+      imagePullPolicy: IfNotPresent
+      command:
+        - bash
+        - -lc
+        - |
+          set -euo pipefail
+          n=0
+          echo 0 > /tmp/gpu-progress
+          while true; do
+            /cuda-samples/vectorAdd > /tmp/vectoradd.last 2>&1
+            n=\$((n + 1))
+            echo "\$n" > /tmp/gpu-progress.next
+            mv /tmp/gpu-progress.next /tmp/gpu-progress
+          done
+      resources:
+        limits:
+          nvidia.com/gpu: 1
+          nvidia.com/gpumem: ${memory}
+EOF
+}
+
+create_mig_pod mixed-small 8000
+create_mig_pod mixed-large 30000
+
+kubectl wait -n hami-mig-retest --for=condition=Ready \
+  pod/mixed-small pod/mixed-large --timeout=180s
+```
+
+We inspected the controller-owned allocation records with:
+
+```bash
+kubectl get pods mixed-small mixed-large -n hami-mig-retest -o json |
+jq -r '
+  ["POD", "PROFILE", "START", "SIZE", "MIG_UUID", "GI", "CI"],
+  (
+    .items
+    | sort_by(.metadata.name)[]
+    | . as $pod
+    | ($pod.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson | .[0]) as $a
+    | [
+        $pod.metadata.name,
+        $a.profile,
+        ($a.placement.start | tostring),
+        ($a.placement.size | tostring),
+        $a.migUUID,
+        ($a.gpuInstanceID | tostring),
+        ($a.computeInstanceID | tostring)
+      ]
+  )
+  | @tsv
+'
+```
+
+The live allocation table was:
+
+```text
+POD          PROFILE    START  SIZE  MIG_UUID                                      GI  CI
+mixed-large  2g.48gb    0      6     MIG-b23491d8-d784-58d9-bcfa-3c171ead22da      1   0
+mixed-small  1g.24gb    9      3     MIG-a5fa6120-f6fa-51b6-9820-a42112640629      6   0
+```
+
+The intervals `[0,6)` and `[9,12)` do not overlap, so both profiles could coexist. `nvidia-smi -L` showed one `2g.48gb` and one `1g.24gb` instance under GPU 4.
+
+Both CUDA loops advanced during the same three-second window:
+
+```text
+small: 64 -> 67
+large: 37 -> 39
+PASS: both mixed-profile CUDA workloads progressed
+```
+
+## Test 4: reclaim only the pod's own instance
+
+Before deleting the small pod, we recorded the large pod's progress. Then we deleted only `mixed-small` and polled the host until its `1g.24gb` instance disappeared:
+
+```bash
+large_before=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+
+kubectl delete pod mixed-small -n hami-mig-retest
+
+# Reclamation is asynchronous; poll instead of assuming delete is instant.
+watch -n 1 nvidia-smi -L
+```
+
+The host retained only:
+
+```text
+MIG 2g.48gb Device 0: (UUID: MIG-b23491d8-d784-58d9-bcfa-3c171ead22da)
+```
+
+The neighboring CUDA workload continued:
+
+```text
+large: 61 -> 94
+PASS: 2g workload survived 1g reclamation
+```
+
+We produced that check with:
+
+```bash
+large_after=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+printf 'large: %s -> %s\n' "$large_before" "$large_after"
+test "$large_after" -gt "$large_before" \
+  && echo 'PASS: 2g workload survived 1g reclamation'
+```
+
+HAMi does not synchronously destroy the instance inside the `kubectl delete` call. Its annotation reconciler notices that the reservation is no longer active and removes the tracked CI and GI shortly afterward.
+
+We also recreated a `1g.24gb` instance at the freed placement. On this GPU and driver, it received the same `MIG-a5fa...` UUID. The UUID's observed disappearance proved reclamation; its later reappearance proved placement reuse. A MIG UUID is not a generation counter, so do not require a different UUID as proof of recreation.
+
+## Test 5: recover a valid allocation after plugin restart
+
+This is an advanced and disruptive controller test, not a normal workload step. We kept `mixed-large` active, recorded its progress and MIG UUID, then replaced the device-plugin pod:
+
+```bash
+OLD_DP_POD=$(kubectl get pods -n hami-system \
+  -l app.kubernetes.io/component=hami-device-plugin \
+  -o jsonpath='{.items[0].metadata.name}')
+
+progress_before=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+
+kubectl delete pod "$OLD_DP_POD" -n hami-system
+kubectl rollout status daemonset/hami-device-plugin \
+  -n hami-system --timeout=180s
+```
+
+The replacement plugin logged:
+
+```text
+mig init: resolved startup layout inUseGPUs=[4] resetGPUs=[0,1,2,3,5,6,7]
+```
+
+With a complete runtime allocation annotation, it classified GPU 4 as in use, left that card untouched during startup cleanup, verified the live profile and identity through NVML, and adopted the allocation.
+
+The same `2g.48gb` UUID remained, and the workload continued:
+
+```text
+progress: 115 -> 187
+PASS: MIG UUID and CUDA workload survived device-plugin restart
+```
+
+The verification checked both the device and the progress counter:
+
+```bash
+nvidia-smi -L | grep -F 'MIG-b23491d8-d784-58d9-bcfa-3c171ead22da'
+
+progress_after=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+printf 'progress: %s -> %s\n' "$progress_before" "$progress_after"
+test "$progress_after" -gt "$progress_before"
+```
+
+This proves the tested happy path for a valid annotation. It is not a guarantee that incomplete or malformed state can always be adopted.
+
+> **Node-wide safety warning:** `filterdevices` limits HAMi registration and scheduling, but at this commit it does not limit Dynamic MIG startup cleanup. The log shows that startup reconciled all eight physical GPUs, including filtered ones. Inventory and drain the entire node before the first install or a plugin restart; filtering a GPU is not a protection boundary.
+
+## Test 6: the fifth pod spills to GPU 5
+
+After deleting the mixed-profile workload and confirming no MIG instances remained, we changed the exclusion list from:
+
+```bash
+kubectl delete pod mixed-large -n hami-mig-retest
+
+until ! nvidia-smi -L | grep -q '^  MIG '; do
+  sleep 2
+done
+```
+
+```json
+"index": [0, 1, 2, 3, 5, 6, 7]
+```
+
+to:
+
+```json
+"index": [0, 1, 2, 3, 6, 7]
+```
+
+That made GPUs 4 and 5 available to HAMi. We applied the values and explicitly restarted the plugin only after confirming the whole node was idle:
+
+```bash
+helm upgrade hami "$LAB/HAMi/charts/hami" \
+  -n hami-system \
+  --reset-values \
+  -f "$LAB/hami-current-mig-values.yaml" \
+  --wait \
+  --timeout 10m
+
+# This configuration change did not trigger a plugin rollout by itself.
+kubectl rollout restart daemonset/hami-device-plugin -n hami-system
+kubectl rollout status daemonset/hami-device-plugin \
+  -n hami-system --timeout=180s
+```
+
+This revealed a chart behavior worth knowing: Helm successfully updated the node-configuration ConfigMap, but the DaemonSet template did not checksum that ConfigMap. Registration stayed unchanged until we restarted the plugin.
+
+The node then registered GPUs 4 and 5 in MIG mode. Scaling the small-pod Deployment to five produced this real distribution:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=5
+kubectl rollout status deployment/mig-small-pack \
+  -n hami-mig-retest --timeout=180s
+
+kubectl get pods -n hami-mig-retest -l app=mig-small-pack -o json |
+jq -r '
+  ["POD", "PARENT_GPU", "PROFILE", "START", "MIG_UUID"],
+  (
+    .items
+    | sort_by(.metadata.name)[]
+    | . as $pod
+    | ($pod.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson | .[0]) as $a
+    | [
+        $pod.metadata.name,
+        $a.gpuUUID,
+        $a.profile,
+        ($a.placement.start | tostring),
+        $a.migUUID
+      ]
+  )
+  | @tsv
+'
+```
+
+```text
+POD                               PARENT_GPU                                   PROFILE    START
+mig-small-pack-6f5b7bd7b-dwld2    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   3
+mig-small-pack-6f5b7bd7b-g72fd    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   0
+mig-small-pack-6f5b7bd7b-jgql2    GPU-04dc48d7-7048-aef5-ad36-f5db716e7668   1g.24gb   9
+mig-small-pack-6f5b7bd7b-rlxbn    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   9
+mig-small-pack-6f5b7bd7b-vjfv9    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   6
+```
+
+GPU 4 held all four legal `1g.24gb` placements. The fifth pod received a legal placement on GPU 5. Again, its first placement happened to start at `9`; HAMi does not promise to allocate starts in numerical order.
+
+## Cleanup and final state
+
+We deleted the test namespace and waited for all per-pod MIG instances to be reclaimed:
+
+```bash
+kubectl delete namespace hami-mig-retest \
+  --wait=true --timeout=180s
+
+if nvidia-smi -L | grep -q '^  MIG '; then
+  echo 'FAIL: MIG instances remain'
+  nvidia-smi -L
+else
+  echo 'PASS: no MIG instances remain'
+fi
+```
+
+Then we restored the original exclusion list, applied the values, and performed the same safe plugin restart. The final verification was:
+
+```bash
+printf 'Registered GPU indices: '
+kubectl get node "$NODE" -o json |
+jq -r '
+  .metadata.annotations["hami.io/node-nvidia-register"]
+  | fromjson
+  | map(.index)
+  | join(",")
+'
+
+if nvidia-smi -L | grep -q '^  MIG '; then
+  echo 'MIG state: FAIL — instances remain'
+else
+  echo 'MIG state: PASS — no instances remain'
+fi
+
+kubectl get pods -n hami-system
+```
+
+```text
+Registered GPU indices: 4
+MIG state: PASS — no instances remain
+NAME                              READY   STATUS    RESTARTS
+hami-device-plugin-6snlc          2/2     Running   0
+hami-scheduler-74fbfcfbb5-qxftm   2/2     Running   0
+```
+
+That left the lab in its intended baseline: only GPU 4 registered with HAMi, no test MIG instances, and both HAMi components healthy.
+
+## Operational traps we hit
+
+### Chart metadata is not the runtime version
+
+At the tested commit, the chart still defaults to `v2.9.0`. Pin and inspect the live images for the scheduler extender, device plugin, and monitor. Do not publish `latest`, and do not rely on Helm's app-version label.
+
+### `operatingmode` is not `migStrategy`
+
+Use per-node `operatingmode: "mig"` for HAMi Dynamic MIG. Keep the Helm-level `devicePlugin.migStrategy` decision separate; changing only the similarly named field inside the JSON is not how this chart controls the NVIDIA plugin flag.
+
+### `filterdevices` excludes registration, not startup mutation
+
+The exclusion list controls which GPUs HAMi advertises for scheduling. It does not isolate the other physical cards from startup reconciliation. Treat first installation and plugin restart as node-wide maintenance at this commit.
+
+### A Helm upgrade may not restart the device plugin
+
+Changing `devicePlugin.nodeConfiguration.config` updated the ConfigMap but did not roll the DaemonSet in our test. Restart it deliberately, only after the node-wide safety check, then verify the registration annotation rather than trusting Helm's success message.
+
+### Scheduler events can use inherited language
+
+`CardTimeSlicingExhausted` described exhausted MIG placements in this run; it did not mean HAMi silently switched to time slicing. Confirm the allocation annotation and host MIG state before interpreting a generic reason string.
+
+### Reclamation is eventual, and UUIDs may be reused
+
+Poll the actual host state after pod deletion. The same placement can return the same MIG UUID, so disappearance between deletion and recreation is stronger lifecycle evidence than UUID inequality.
+
+### Legal placement still controls mixed profiles
+
+Dynamic does not mean arbitrary. The scheduler can combine profiles only when their NVML placement intervals do not overlap, and active instances cannot be destroyed just to satisfy a new request.
+
+### Homogeneous success is not a heterogeneous-node guarantee
+
+This node contained eight identical supported GPUs. Test mixed-model nodes separately; do not assume that filtering unsupported cards reproduces the same startup behavior.
+
+## Conclusion
+
+Topology-aware Dynamic MIG kept the Kubernetes API simple while making the hardware lifecycle precise. An 8,000 MiB request selected `1g.24gb`; four legal placements filled GPU 4; a fifth pod used GPU 5; and `1g.24gb` plus `2g.48gb` occupied legal mixed placements on the same card.
+
+The most useful result was not just allocation. HAMi reclaimed the small pod's exact GI/CI while its neighbor kept computing, and a valid allocation survived device-plugin restart and adoption. Those are the behaviors a dynamic controller needs to prove.
+
+The caveats are equally important. Profile rounding and NVIDIA placement rules remain. Version alignment must be verified from live images. At this snapshot, plugin startup has a node-wide hardware scope even when only one GPU is registered, so controlled installation and restart procedures are mandatory.
+
+HAMi is a CNCF Incubating project. Its source is at [github.com/Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi). Existing installations can use the [pinned Dynamic MIG migration guide](https://github.com/Project-HAMi/HAMi/blob/634bf2b32e68e07d3fbcbd6da1ee079392fc07c1/docs/develop/dynamic-mig-migration.md) when moving to this per-pod implementation.
+
+If you are joining the series here, read the [static MIG deep dive](/blog/slicing-gpus-in-kubernetes-with-nvidia-mig) and the [HAMi software vGPU guide](/blog/sharing-gpus-in-kubernetes-with-hami) first.
diff --git a/lib/_blog-feed-data.js b/lib/_blog-feed-data.js
index eb184d604..077d2a5d4 100644
--- a/lib/_blog-feed-data.js
+++ b/lib/_blog-feed-data.js
@@ -1,5 +1,29 @@
 // AUTO-GENERATED by scripts/generate-feeds.mjs. Do not edit by hand.
 export const FEED_POSTS = [
+  {
+    "slug": "nemotron-3-5-lightning-on-dgx-spark",
+    "title": "Running Nemotron 3.5 Lightning on DGX Spark",
+    "description": "NVIDIA's new Nemotron 3.5 Lightning on DGX Spark: how to run it with Ollama and vLLM, the tokens per second I measured, and how the two paths compare.",
+    "datePublished": "2026-08-11T17:40:00.000Z",
+    "cover": "/img/blog/nemotron-3-5-lightning-on-dgx-spark/cover.png",
+    "tags": [
+      "nvidia",
+      "dgxspark",
+      "nemotron"
+    ]
+  },
+  {
+    "slug": "dynamic-mig-in-kubernetes-with-hami",
+    "title": "HAMi Dynamic MIG on RTX PRO 6000: A Live Kubernetes Test",
+    "description": "A hands-on test of topology-aware HAMi Dynamic MIG on RTX PRO 6000 Blackwell, with pinned setup commands, real allocations, mixed profiles, reclamation, and recovery.",
+    "datePublished": "2026-08-11T10:00:00.000Z",
+    "cover": "/img/blog/dynamic-mig-in-kubernetes-with-hami/cover.png",
+    "tags": [
+      "kubernetes",
+      "gpu",
+      "nvidia"
+    ]
+  },
   {
     "slug": "devin-outposts-on-kubernetes",
     "title": "Devin Outposts on Kubernetes: Why Your AI Agent Needs Your Cluster",
@@ -331,29 +355,5 @@ export const FEED_POSTS = [
       "docker",
       "devops"
     ]
-  },
-  {
-    "slug": "ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale",
-    "title": "\\\"SSH Into Your DGX Spark From Anywhere in the World Using Tailscale",
-    "description": "Learn how to set up Tailscale on your NVIDIA DGX Spark for secure SSH access from anywhere in the world.",
-    "datePublished": "2026-04-07T12:01:10.914Z",
-    "cover": "/img/blog/ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale/73a73de4-7383-44be-8853-78e3cf47b306.png",
-    "tags": [
-      "kubernetes",
-      "devops",
-      "ssh"
-    ]
-  },
-  {
-    "slug": "claude-code-leak-what-the-source-actually-teaches",
-    "title": "What Claude Code's Leaked Source Actually Teaches Us About Building AI Agents",
-    "description": "512K lines of TypeScript, verified against actual source. The engineering patterns in Claude Code's leaked codebase that most coverage got wrong.",
-    "datePublished": "2026-04-01T15:13:33.877Z",
-    "cover": "/img/blog/claude-code-leak-what-the-source-actually-teaches/0582a05f-42f3-4b97-8512-9c2133603126.svg",
-    "tags": [
-      "typescript",
-      "llm",
-      "ai-agents"
-    ]
   }
 ];
diff --git a/lib/markdown.js b/lib/markdown.js
index 5b1db6b71..56f0d4988 100644
--- a/lib/markdown.js
+++ b/lib/markdown.js
@@ -2,6 +2,7 @@ import { unified } from 'unified';
 import remarkParse from 'remark-parse';
 import remarkGfm from 'remark-gfm';
 import remarkRehype from 'remark-rehype';
+import rehypeRaw from 'rehype-raw';
 import rehypeSlug from 'rehype-slug';
 import rehypeAutolinkHeadings from 'rehype-autolink-headings';
 import rehypePrettyCode from 'rehype-pretty-code';
@@ -21,6 +22,8 @@ import Day5EngineChoiceAnimation from '@/components/Day5EngineChoiceAnimation';
 import HAMiBlastRadiusAnimation from '@/components/HAMiBlastRadiusAnimation';
 import HAMiRequestFlowAnimation from '@/components/HAMiRequestFlowAnimation';
 import HAMiSlotMathAnimation from '@/components/HAMiSlotMathAnimation';
+import DynamicMigLifecycleAnimation from '@/components/DynamicMigLifecycleAnimation';
+import CodeBlock from '@/components/CodeBlock';
 
 const BLOG_SHORTCODES = {
   '{{llm-request-animation}}': 'llm-request-animation',
@@ -37,6 +40,7 @@ const BLOG_SHORTCODES = {
   '{{hami-blast-radius-animation}}': 'hami-blast-radius-animation',
   '{{hami-request-flow-animation}}': 'hami-request-flow-animation',
   '{{hami-slot-math-animation}}': 'hami-slot-math-animation',
+  '{{dynamic-mig-lifecycle-animation}}': 'dynamic-mig-lifecycle-animation',
 };
 
 function remarkBlogShortcodes() {
@@ -75,6 +79,8 @@ const processor = unified()
   .use(remarkGfm)
   .use(remarkBlogShortcodes)
   .use(remarkRehype, { allowDangerousHtml: true })
+  // Materialize trusted raw HTML used by existing posts before rendering React.
+  .use(rehypeRaw)
   .use(rehypeSlug)
   .use(rehypeAutolinkHeadings, {
     behavior: 'append',
@@ -106,6 +112,8 @@ const processor = unified()
       'hami-blast-radius-animation': HAMiBlastRadiusAnimation,
       'hami-request-flow-animation': HAMiRequestFlowAnimation,
       'hami-slot-math-animation': HAMiSlotMathAnimation,
+      'dynamic-mig-lifecycle-animation': DynamicMigLifecycleAnimation,
+      pre: CodeBlock,
     },
   });
 
@@ -116,7 +124,7 @@ const processor = unified()
  * Patterns handled:
  *   ![alt](url align="center")  →  ![alt](url)
  *   %[https://example.com]      →  [https://example.com](https://example.com)
- *   {{llm-...-animation}}       →  interactive blog visuals
+ *   {{...-animation}}           → allow-listed blog visuals
  *   (Hashnode renders %[] as an embed card; we render as a plain link,
  *    which is the safest fallback.)
  */
diff --git a/public/_redirects b/public/_redirects
index fb0972631..99b953f96 100644
--- a/public/_redirects
+++ b/public/_redirects
@@ -70,6 +70,7 @@
 /blog/docker-captain-journey                                                           /docker-captain-journey  301!
 /blog/docker-mcp-catalog                                                               /docker-mcp-catalog  301!
 /blog/docker-networking-demystified                                                    /docker-networking-demystified  301!
+/blog/dynamic-mig-in-kubernetes-with-hami                                              /dynamic-mig-in-kubernetes-with-hami  301!
 /blog/embed-http-servers-in-wasm-with-rust-and-csharp                                  /embed-http-servers-in-wasm-with-rust-and-csharp  301!
 /blog/enhancing-runtime-security-with-falco-my-hands-on-experience                     /enhancing-runtime-security-with-falco-my-hands-on-experience  301!
 /blog/ephemeral-pull-request-environment-using-vcluster                                /ephemeral-pull-request-environment-using-vcluster  301!
@@ -160,6 +161,7 @@
 /blog/my-kubecon-euvirtual-experience                                                  /my-kubecon-euvirtual-experience  301!
 /blog/my-schedule-for-kubecon-cloudnativecon-eu-2022                                   /my-schedule-for-kubecon-cloudnativecon-eu-2022  301!
 /blog/navigating-through-cncf-landscape                                                /navigating-through-cncf-landscape  301!
+/blog/nemotron-3-5-lightning-on-dgx-spark                                              /nemotron-3-5-lightning-on-dgx-spark  301!
 /blog/nemotron3-on-dgx-spark                                                           /nemotron3-on-dgx-spark  301!
 /blog/networking-fundamentals-for-devops                                               /networking-fundamentals-for-devops  301!
 /blog/nexus-repository-manager-what-is-it-and-how-to-configure-it-on-a-digital-ocean-droplet /nexus-repository-manager-what-is-it-and-how-to-configure-it-on-a-digital-ocean-droplet  301!
@@ -290,6 +292,7 @@
 /docker-captain-journey                                                           /blog/docker-captain-journey  200!
 /docker-mcp-catalog                                                               /blog/docker-mcp-catalog  200!
 /docker-networking-demystified                                                    /blog/docker-networking-demystified  200!
+/dynamic-mig-in-kubernetes-with-hami                                              /blog/dynamic-mig-in-kubernetes-with-hami  200!
 /embed-http-servers-in-wasm-with-rust-and-csharp                                  /blog/embed-http-servers-in-wasm-with-rust-and-csharp  200!
 /enhancing-runtime-security-with-falco-my-hands-on-experience                     /blog/enhancing-runtime-security-with-falco-my-hands-on-experience  200!
 /ephemeral-pull-request-environment-using-vcluster                                /blog/ephemeral-pull-request-environment-using-vcluster  200!
@@ -380,6 +383,7 @@
 /my-kubecon-euvirtual-experience                                                  /blog/my-kubecon-euvirtual-experience  200!
 /my-schedule-for-kubecon-cloudnativecon-eu-2022                                   /blog/my-schedule-for-kubecon-cloudnativecon-eu-2022  200!
 /navigating-through-cncf-landscape                                                /blog/navigating-through-cncf-landscape  200!
+/nemotron-3-5-lightning-on-dgx-spark                                              /blog/nemotron-3-5-lightning-on-dgx-spark  200!
 /nemotron3-on-dgx-spark                                                           /blog/nemotron3-on-dgx-spark  200!
 /networking-fundamentals-for-devops                                               /blog/networking-fundamentals-for-devops  200!
 /nexus-repository-manager-what-is-it-and-how-to-configure-it-on-a-digital-ocean-droplet /blog/nexus-repository-manager-what-is-it-and-how-to-configure-it-on-a-digital-ocean-droplet  200!
diff --git a/public/_worker.js b/public/_worker.js
index 449aff42a..d11eef311 100644
--- a/public/_worker.js
+++ b/public/_worker.js
@@ -795,7 +795,7 @@ async function handleNewsletterApi(request, env) {
 
 const KUBESIMPLIFY_ROUTES = new Set(['/about', '/workshops', '/partnerships', '/resources', '/products', '/learn', '/privacy']);
 const KUBESIMPLIFY_PREFIXES = ['/products/', '/learn/'];
-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","devin-outposts-on-kubernetes","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","sharing-gpus-in-kubernetes-with-hami","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"]);
+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","devin-outposts-on-kubernetes","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","dynamic-mig-in-kubernetes-with-hami","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","nemotron-3-5-lightning-on-dgx-spark","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","sharing-gpus-in-kubernetes-with-hami","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 d87ebf41c..96b9de861 100644
--- a/public/atom.xml
+++ b/public/atom.xml
@@ -5,11 +5,36 @@
   <link href="https://blog.kubesimplify.com/atom.xml" rel="self"/>
   <link href="https://blog.kubesimplify.com/"/>
   <id>https://blog.kubesimplify.com/</id>
-  <updated>2026-08-10T14:13:29.920Z</updated>
+  <updated>2026-08-12T14:47:36.455Z</updated>
   <author>
     <name>Kubesimplify</name>
     <email>hello@kubesimplify.com</email>
   </author>
+  <entry>
+    <title>Running Nemotron 3.5 Lightning on DGX Spark</title>
+    <link href="https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark"/>
+    <id>https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark</id>
+    <updated>2026-08-11T17:40:00.000Z</updated>
+    <published>2026-08-11T17:40:00.000Z</published>
+    <summary>NVIDIA&apos;s new Nemotron 3.5 Lightning on DGX Spark: how to run it with Ollama and vLLM, the tokens per second I measured, and how the two paths compare.</summary>
+    <category term="nvidia"/>
+    <category term="dgxspark"/>
+    <category term="nemotron"/>
+    <category term="ai-agents"/>
+    <category term="ollama"/>
+  </entry>
+  <entry>
+    <title>HAMi Dynamic MIG on RTX PRO 6000: A Live Kubernetes Test</title>
+    <link href="https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami"/>
+    <id>https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami</id>
+    <updated>2026-08-11T10:00:00.000Z</updated>
+    <published>2026-08-11T10:00:00.000Z</published>
+    <summary>A hands-on test of topology-aware HAMi Dynamic MIG on RTX PRO 6000 Blackwell, with pinned setup commands, real allocations, mixed profiles, reclamation, and recovery.</summary>
+    <category term="kubernetes"/>
+    <category term="gpu"/>
+    <category term="nvidia"/>
+    <category term="platform-engineering"/>
+  </entry>
   <entry>
     <title>Devin Outposts on Kubernetes: Why Your AI Agent Needs Your Cluster</title>
     <link href="https://blog.kubesimplify.com/devin-outposts-on-kubernetes"/>
diff --git a/public/img/blog/dynamic-mig-in-kubernetes-with-hami/4mig.mp4 b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/4mig.mp4
new file mode 100644
index 000000000..ef0f2fb29
Binary files /dev/null and b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/4mig.mp4 differ
diff --git a/public/img/blog/dynamic-mig-in-kubernetes-with-hami/5mig.mp4 b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/5mig.mp4
new file mode 100644
index 000000000..298003b59
Binary files /dev/null and b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/5mig.mp4 differ
diff --git a/public/img/blog/dynamic-mig-in-kubernetes-with-hami/cover.png b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/cover.png
new file mode 100644
index 000000000..8bbfcfb87
Binary files /dev/null and b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/cover.png differ
diff --git a/public/img/blog/dynamic-mig-in-kubernetes-with-hami/cover.svg b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/cover.svg
new file mode 100644
index 000000000..3579e4c59
--- /dev/null
+++ b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/cover.svg
@@ -0,0 +1,41 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="630" viewBox="0 0 1200 630">
+<defs></defs>
+<rect width="1200" height="630" fill="#f8fafc"/>
+<text x="64" y="68" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="19" font-weight="800" fill="#5d8f00" text-anchor="start">KUBESIMPLIFY · GPU SHARING</text>
+<text x="64" y="158" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="52" font-weight="800" fill="#172033" text-anchor="start">HAMi Dynamic MIG on</text>
+<text x="64" y="216.24" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="52" font-weight="800" fill="#172033" text-anchor="start">RTX PRO 6000</text>
+<text x="64" y="292" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="22" font-weight="500" fill="#5c677d" text-anchor="start">Topology-aware per-pod placements, tested with</text>
+<text x="64" y="322.36" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="22" font-weight="500" fill="#5c677d" text-anchor="start">real CUDA workloads on Blackwell.</text>
+<path d="M 70.5 417.5 Q 74.0 412.6 80.8 406.4 M 70.1 428.5 Q 82.4 418.0 91.2 407.6 M 69.5 439.5 Q 87.7 423.4 102.4 406.6 M 70.1 451.7 Q 90.8 429.9 114.5 406.2 M 70.7 461.9 Q 97.6 433.4 124.9 406.9 M 69.0 474.0 Q 102.2 438.5 136.8 407.6 M 70.2 483.7 Q 108.7 446.3 146.8 406.5 M 69.7 494.1 Q 113.6 451.4 158.1 406.3 M 69.4 505.1 Q 119.4 456.0 170.0 407.1 M 69.9 517.4 Q 123.8 463.5 179.4 407.1 M 79.4 518.8 Q 136.5 462.1 190.9 407.5 M 90.6 518.2 Q 145.0 463.9 201.1 406.3 M 100.5 519.0 Q 157.4 462.6 213.0 406.2 M 112.5 518.5 Q 169.5 462.5 224.3 407.8 M 123.8 518.9 Q 178.9 462.8 236.0 406.6 M 134.5 519.1 Q 190.9 464.1 246.7 407.1 M 144.6 518.9 Q 200.4 462.5 257.1 407.3 M 155.9 518.0 Q 210.7 463.0 268.4 406.8 M 166.3 518.9 Q 222.8 464.3 278.6 406.8 M 178.4 519.9 Q 233.2 462.6 289.0 407.0 M 188.3 518.8 Q 246.0 463.1 300.3 407.6 M 200.2 518.7 Q 255.7 461.7 311.5 406.8 M 210.4 518.6 Q 266.4 463.3 324.0 406.4 M 222.6 518.3 Q 278.5 463.0 333.7 406.4 M 233.9 519.5 Q 288.4 462.0 345.2 407.0 M 243.6 518.8 Q 300.0 462.6 355.8 406.9 M 254.2 519.5 Q 310.5 462.6 366.8 406.0 M 265.4 519.7 Q 321.6 463.1 378.8 407.9 M 277.0 518.4 Q 333.9 462.2 389.7 407.6 M 288.3 519.3 Q 345.5 462.5 400.8 406.2 M 300.0 518.3 Q 355.5 464.5 410.7 406.1 M 310.0 518.3 Q 366.1 462.0 422.6 406.5 M 321.5 518.8 Q 376.1 462.5 433.9 407.2 M 332.9 519.0 Q 387.9 463.4 443.9 406.2 M 343.1 519.2 Q 399.8 462.0 454.7 406.8 M 354.0 519.3 Q 409.2 463.9 466.0 406.1 M 364.3 519.6 Q 421.4 463.5 476.4 406.1 M 376.9 519.1 Q 431.9 463.7 487.1 407.3 M 386.7 518.8 Q 442.6 463.0 499.7 407.7 M 397.1 519.5 Q 455.2 463.2 509.5 407.2 M 409.3 519.8 Q 463.6 462.9 520.7 407.8 M 420.0 519.8 Q 477.4 462.9 531.0 406.1 M 430.8 519.1 Q 486.9 463.1 543.3 407.2 M 442.5 519.6 Q 498.4 461.9 554.9 406.9 M 454.0 519.9 Q 507.8 462.8 564.8 406.7 M 463.7 518.6 Q 521.5 463.9 575.1 407.9 M 475.5 519.7 Q 530.4 465.3 584.3 409.0 M 485.5 518.9 Q 534.2 468.9 585.5 420.4 M 497.6 519.2 Q 540.2 474.8 585.0 431.6 M 507.4 519.3 Q 547.4 479.8 584.5 441.8 M 518.2 519.2 Q 551.2 486.4 584.7 452.3 M 529.8 519.9 Q 557.6 491.2 584.1 463.2 M 541.7 519.1 Q 562.3 497.6 584.0 475.6 M 551.3 518.8 Q 568.2 501.4 584.1 485.5 M 562.1 519.4 Q 574.6 507.1 585.5 496.2 M 574.0 519.5 Q 580.6 513.6 586.0 507.6" stroke="#a5d8ff" stroke-width="2.5" opacity="0.58" fill="none" stroke-linecap="round"/>
+<path d="M 70.1 407.7 Q 328.9 405.7 583.9 406.6 M 584.1 407.7 Q 585.5 463.6 584.4 518.9 M 585.9 520.1 Q 327.5 518.0 71.5 518.7 M 68.6 518.8 Q 69.6 461.9 71.0 408.8" stroke="#1971c2" stroke-width="2.4" opacity="1" fill="none" stroke-linecap="round"/>
+<path d="M 70.0 405.8 Q 328.7 407.5 586.1 407.1 M 584.7 406.9 Q 583.9 463.9 584.2 518.1 M 585.6 519.5 Q 326.8 520.5 70.5 518.6 M 70.3 518.3 Q 69.9 463.3 70.6 407.4" stroke="#1971c2" stroke-width="1.32" opacity="0.55" fill="none" stroke-linecap="round"/>
+<text x="327" y="449" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="22" font-weight="800" fill="#1971c2" text-anchor="middle">4 × 1g on GPU 4  →  fifth on GPU 5</text>
+<text x="327" y="488" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="18" font-weight="500" fill="#5c677d" text-anchor="middle">exact placement · exact reclamation</text>
+<path d="M 720.6 116.7 Q 730.1 105.0 742.7 95.9 M 719.7 127.5 Q 737.7 111.1 753.1 95.6 M 719.7 138.1 Q 742.9 118.0 763.4 94.7 M 720.2 150.5 Q 748.0 123.4 774.5 95.2 M 719.8 160.7 Q 753.9 126.6 786.8 95.2 M 720.9 172.5 Q 757.8 133.0 796.8 94.9 M 719.4 183.7 Q 762.9 137.7 808.5 94.6 M 719.4 193.5 Q 768.0 143.0 819.2 95.8 M 720.6 204.1 Q 774.7 149.8 830.9 94.5 M 719.4 215.1 Q 781.6 155.7 841.1 95.0 M 720.8 227.8 Q 786.0 159.9 852.5 95.6 M 719.4 237.1 Q 791.6 165.9 864.0 94.4 M 720.1 249.6 Q 798.3 173.1 873.3 95.4 M 719.4 261.0 Q 801.8 178.8 884.1 95.9 M 720.5 271.9 Q 809.2 183.9 895.5 94.8 M 719.9 282.7 Q 812.5 187.4 907.5 94.2 M 719.5 292.7 Q 818.1 195.1 918.5 94.6 M 719.2 303.6 Q 823.7 199.5 930.0 94.9 M 720.6 315.1 Q 829.2 205.4 940.4 94.6 M 720.8 326.2 Q 835.9 210.2 950.9 95.6 M 719.5 337.4 Q 840.8 217.4 961.0 95.6 M 719.7 347.2 Q 845.7 222.6 972.8 95.5 M 720.7 358.5 Q 853.3 226.5 984.1 95.6 M 720.2 369.1 Q 857.3 233.2 995.3 95.6 M 720.2 380.4 Q 863.7 237.2 1006.3 94.9 M 720.9 391.4 Q 868.6 244.1 1016.2 95.4 M 719.7 403.0 Q 874.7 248.8 1028.6 95.5 M 720.2 414.7 Q 880.9 253.7 1038.3 94.8 M 719.9 424.4 Q 884.5 259.3 1050.3 94.2 M 720.0 436.4 Q 891.6 264.3 1061.7 94.3 M 720.4 446.3 Q 895.7 269.8 1071.2 94.5 M 719.1 457.2 Q 900.7 277.7 1082.8 94.6 M 720.3 468.3 Q 907.8 281.7 1093.4 95.8 M 719.9 480.3 Q 913.6 288.5 1104.9 95.5 M 720.4 491.2 Q 914.1 295.9 1109.6 100.8 M 720.0 502.7 Q 915.6 305.6 1110.4 112.1 M 719.9 512.4 Q 916.2 318.7 1110.2 123.6 M 729.2 515.5 Q 918.1 323.8 1109.8 134.3 M 740.8 515.8 Q 925.8 331.5 1109.9 145.5 M 750.3 514.1 Q 929.9 336.2 1110.3 155.9 M 762.3 515.7 Q 937.5 340.5 1110.1 167.7 M 772.2 515.9 Q 942.2 346.6 1109.9 178.2 M 783.2 514.5 Q 947.7 351.8 1110.8 189.7 M 794.0 514.5 Q 953.0 356.4 1110.5 199.1 M 806.0 515.1 Q 958.6 363.6 1110.5 210.9 M 817.6 515.9 Q 963.9 367.2 1110.2 223.0 M 828.9 514.7 Q 969.6 373.5 1110.9 232.1 M 839.6 515.8 Q 973.5 379.6 1110.4 243.6 M 849.1 514.2 Q 981.4 385.3 1109.1 254.0 M 861.5 515.7 Q 986.9 389.7 1109.1 265.2 M 872.2 514.5 Q 990.3 397.2 1109.8 277.6 M 884.0 514.2 Q 996.8 402.3 1110.0 287.6 M 893.2 514.1 Q 1001.5 405.5 1110.3 298.1 M 905.5 515.1 Q 1008.4 411.0 1109.7 309.2 M 915.3 515.9 Q 1013.7 417.5 1109.9 320.9 M 926.2 514.4 Q 1017.9 423.5 1109.2 332.3 M 938.1 514.9 Q 1023.3 428.8 1109.6 342.5 M 948.3 515.7 Q 1028.3 434.3 1109.9 354.2 M 960.1 514.6 Q 1034.8 440.8 1109.8 365.8 M 971.8 515.3 Q 1040.1 444.3 1110.2 376.0 M 981.1 515.6 Q 1045.0 451.5 1110.1 386.7 M 993.1 514.1 Q 1050.6 455.9 1110.4 397.0 M 1004.0 515.0 Q 1056.4 461.0 1109.7 409.1 M 1015.1 514.9 Q 1061.5 466.6 1110.0 420.6 M 1025.7 514.1 Q 1067.2 474.2 1109.8 431.0 M 1036.6 515.3 Q 1074.4 479.8 1109.9 442.6 M 1047.8 514.5 Q 1079.9 484.6 1110.3 454.0 M 1058.6 514.7 Q 1083.3 490.4 1110.9 464.1 M 1070.2 515.7 Q 1089.1 495.6 1109.7 474.3 M 1081.5 515.9 Q 1094.1 500.0 1109.4 486.3" stroke="#e9ecef" stroke-width="2.5" opacity="0.58" fill="none" stroke-linecap="round"/>
+<path d="M 719.4 93.4 Q 915.1 95.9 1108.3 94.9 M 1109.9 97.0 Q 1110.8 304.1 1108.8 516.8 M 1111.7 513.2 Q 913.3 513.2 721.3 516.7 M 721.1 515.0 Q 717.6 306.6 718.2 94.3" stroke="#495057" stroke-width="3" opacity="1" fill="none" stroke-linecap="round"/>
+<path d="M 720.9 94.6 Q 915.5 93.7 1110.4 95.4 M 1110.6 95.9 Q 1111.4 304.8 1109.0 515.9 M 1108.8 513.9 Q 913.6 514.0 720.6 516.2 M 719.8 515.3 Q 719.7 306.8 719.2 94.3" stroke="#495057" stroke-width="1.6500000000000001" opacity="0.55" fill="none" stroke-linecap="round"/>
+<text x="915" y="138" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="26" font-weight="800" fill="#172033" text-anchor="middle">mixed profiles · one GPU</text>
+<text x="915" y="170" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="20" font-weight="500" fill="#5c677d" text-anchor="middle">NVML legal placements</text>
+<path d="M 749.0 235.2 Q 754.3 230.1 761.9 224.6 M 749.2 246.4 Q 762.3 237.5 772.2 224.3 M 750.7 257.3 Q 766.9 241.1 782.0 224.9 M 749.9 268.5 Q 770.5 246.5 793.5 224.4 M 749.4 279.9 Q 777.5 252.8 804.1 224.4 M 749.3 291.6 Q 781.6 257.2 815.6 225.8 M 749.6 302.4 Q 789.0 263.3 826.8 224.3 M 749.2 313.1 Q 795.0 268.0 838.7 224.0 M 749.3 323.2 Q 799.1 273.1 848.5 224.0 M 749.1 334.6 Q 806.2 279.2 859.5 225.3 M 749.9 345.2 Q 809.1 286.1 870.4 224.0 M 756.1 349.5 Q 818.7 288.0 882.7 225.1 M 768.0 349.8 Q 831.2 288.9 893.1 224.2 M 779.2 349.4 Q 841.4 287.4 903.7 225.5 M 789.2 349.2 Q 851.6 289.0 913.0 227.6 M 800.5 349.6 Q 858.3 294.7 913.2 237.0 M 812.0 349.9 Q 861.7 300.3 912.7 249.3 M 823.4 349.1 Q 866.6 303.9 912.9 259.6 M 834.9 349.0 Q 873.5 310.2 912.8 271.3 M 845.4 349.4 Q 878.2 316.9 913.3 282.9 M 856.6 349.3 Q 885.1 320.7 912.1 293.4 M 867.4 349.9 Q 890.5 325.5 913.8 304.2 M 878.1 350.2 Q 895.5 332.7 913.9 315.8 M 888.9 351.0 Q 900.9 336.9 912.2 326.0 M 900.7 349.4 Q 906.1 342.2 913.1 336.1" stroke="#a5d8ff" stroke-width="2.5" opacity="0.58" fill="none" stroke-linecap="round"/>
+<path d="M 749.0 224.0 Q 830.3 224.2 914.4 223.4 M 911.9 223.8 Q 911.8 285.6 912.8 350.4 M 911.0 349.6 Q 828.7 352.1 749.6 348.4 M 751.0 351.7 Q 747.7 286.6 750.3 226.1" stroke="#1971c2" stroke-width="2.4" opacity="1" fill="none" stroke-linecap="round"/>
+<path d="M 749.4 225.6 Q 830.5 225.1 913.2 224.8 M 913.4 226.1 Q 914.3 288.2 912.7 348.8 M 913.3 349.4 Q 831.4 351.5 751.0 350.1 M 750.7 349.4 Q 749.0 287.3 748.9 223.9" stroke="#1971c2" stroke-width="1.32" opacity="0.55" fill="none" stroke-linecap="round"/>
+<text x="831.5" y="276" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="20" font-weight="800" fill="#1971c2" text-anchor="middle">2g.48gb</text>
+<text x="831.5" y="308" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="15" font-weight="500" fill="#5c677d" text-anchor="middle">start 0 · size 6</text>
+<rect x="922" y="225" width="77" height="125" rx="7" fill="#ffffff" fill-opacity="0.62"/>
+<path d="M 920.0 223.5 Q 959.5 224.3 998.2 226.5 M 1000.8 223.3 Q 996.7 286.4 1000.0 349.7 M 999.2 348.8 Q 961.3 347.5 920.4 351.9 M 922.6 349.0 Q 924.6 285.1 921.8 226.6" stroke="#495057" stroke-width="2.4" opacity="1" fill="none" stroke-linecap="round" stroke-dasharray="9 8"/>
+<path d="M 922.2 224.3 Q 959.4 223.9 998.9 225.3 M 999.9 224.2 Q 1000.6 287.3 999.6 349.3 M 999.6 350.2 Q 962.3 349.6 921.4 349.0 M 920.8 349.4 Q 921.6 286.4 921.6 224.7" stroke="#495057" stroke-width="1.32" opacity="0.55" fill="none" stroke-linecap="round" stroke-dasharray="9 8"/>
+<text x="960.5" y="284" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="16" font-weight="700" fill="#495057" text-anchor="middle">free</text>
+<text x="960.5" y="309" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="14" font-weight="500" fill="#5c677d" text-anchor="middle">gap</text>
+<path d="M 1007.1 235.5 Q 1013.1 230.2 1019.3 225.7 M 1007.8 246.1 Q 1017.8 234.9 1030.9 225.0 M 1008.7 257.9 Q 1023.4 242.7 1041.9 224.4 M 1007.9 268.4 Q 1029.7 245.6 1051.5 224.6 M 1008.7 281.0 Q 1036.4 254.0 1063.5 226.0 M 1007.4 291.9 Q 1039.8 259.2 1073.3 224.6 M 1007.6 302.5 Q 1047.4 262.7 1084.8 225.6 M 1008.1 312.1 Q 1046.8 274.5 1084.1 236.8 M 1009.0 324.0 Q 1047.2 285.2 1085.3 247.9 M 1007.8 335.1 Q 1047.6 296.3 1084.4 258.6 M 1008.2 345.9 Q 1046.2 306.1 1085.4 268.7 M 1015.6 350.3 Q 1051.5 314.4 1085.6 280.2 M 1026.2 350.2 Q 1054.9 319.8 1085.2 291.4 M 1037.1 349.6 Q 1062.2 325.1 1085.4 302.2 M 1048.0 350.0 Q 1068.0 330.9 1086.0 312.5 M 1058.6 350.5 Q 1071.9 338.1 1084.8 324.8 M 1071.0 350.3 Q 1077.2 341.1 1085.8 335.1" stroke="#d8f5a2" stroke-width="2.5" opacity="0.58" fill="none" stroke-linecap="round"/>
+<path d="M 1008.6 225.2 Q 1048.6 227.6 1086.1 223.7 M 1084.7 223.5 Q 1085.1 286.0 1084.5 349.3 M 1084.7 348.7 Q 1046.7 352.6 1006.2 348.0 M 1007.4 350.3 Q 1005.7 289.1 1006.3 226.2" stroke="#5d8f00" stroke-width="2.4" opacity="1" fill="none" stroke-linecap="round"/>
+<path d="M 1009.1 225.2 Q 1045.5 223.9 1085.8 224.0 M 1086.0 224.3 Q 1084.4 287.9 1084.9 349.0 M 1084.9 350.5 Q 1047.9 348.5 1009.1 350.1 M 1008.9 350.7 Q 1009.2 285.9 1008.2 225.7" stroke="#5d8f00" stroke-width="1.32" opacity="0.55" fill="none" stroke-linecap="round"/>
+<text x="1046.5" y="270" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="19" font-weight="800" fill="#5d8f00" text-anchor="middle">1g</text>
+<text x="1046.5" y="297" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="15" font-weight="500" fill="#5c677d" text-anchor="middle">24gb</text>
+<text x="1046.5" y="324" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="13" font-weight="500" fill="#5c677d" text-anchor="middle">start 9</text>
+<path d="M 914.7 371.0 Q 914.0 389.6 914.0 410.2" stroke="#172033" stroke-width="2.6" fill="none" stroke-linecap="round"/>
+<path d="M 916.0 410.9 Q 910.4 403.3 906.3 398.2" stroke="#172033" stroke-width="2.6" fill="none" stroke-linecap="round"/>
+<path d="M 916.7 408.7 Q 917.5 406.0 921.6 398.8" stroke="#172033" stroke-width="2.6" fill="none" stroke-linecap="round"/>
+<text x="915" y="454" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="18" font-weight="700" fill="#087f5b" text-anchor="middle">both CUDA workloads progressed</text>
+<text x="915" y="487" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="17" font-weight="500" fill="#5c677d" text-anchor="middle">delete 1g · 2g keeps running</text>
+<text x="64" y="588" font-family="Chalkboard SE, Comic Sans MS, sans-serif" font-size="18" font-weight="700" fill="#d9480f" text-anchor="start">PER-POD GI/CI LIFECYCLE · LIVE CUDA TEST</text>
+</svg>
\ No newline at end of file
diff --git a/public/img/blog/dynamic-mig-in-kubernetes-with-hami/dynamic-recreation.mp4 b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/dynamic-recreation.mp4
new file mode 100644
index 000000000..dee7c1815
Binary files /dev/null and b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/dynamic-recreation.mp4 differ
diff --git a/public/img/blog/dynamic-mig-in-kubernetes-with-hami/mixed-profiles-lifecycle.mp4 b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/mixed-profiles-lifecycle.mp4
new file mode 100644
index 000000000..f27992e1b
Binary files /dev/null and b/public/img/blog/dynamic-mig-in-kubernetes-with-hami/mixed-profiles-lifecycle.mp4 differ
diff --git a/public/llms-full.txt b/public/llms-full.txt
index cd217f6b7..329797025 100644
--- a/public/llms-full.txt
+++ b/public/llms-full.txt
@@ -5,6 +5,1136 @@
 
 ---
 
+# Running Nemotron 3.5 Lightning on DGX Spark
+
+- Canonical: https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark
+- Published: 2026-08-11
+- Summary: NVIDIA's new Nemotron 3.5 Lightning on DGX Spark: how to run it with Ollama and vLLM, the tokens per second I measured, and how the two paths compare.
+
+NVIDIA released [Nemotron 3.5 Lightning](https://developer.nvidia.com/blog/nvidia-nemotron-3-5-lightning-delivers-fast-accurate-specialized-task-execution-for-long-running-agents/) today (August 11, 2026), and the pitch is simple: long-running agents spend most of their tokens on boring execution work (tool calls, validating outputs, formatting results), and you should not be burning frontier-model money on that. Lightning is the small, fast worker model for that layer.
+
+NVIDIA specifically calls out DGX Spark as a deployment target. I have a Spark on my desk. So instead of quoting their charts, I pulled the model the hour it landed and measured it myself. This is a short post with what I measured, and one gotcha you should know about if you try it right away.
+
+## What it actually is
+
+The specs, verified against the [model config on Hugging Face](https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16), not the press release:
+
+| Spec | Value |
+|---|---|
+| Total parameters | 30B |
+| Active parameters | ~3B per token |
+| Architecture | Hybrid Mamba-Transformer MoE (`nemotron_h`), 52 layers |
+| Experts | 128 routed, 6 active per token, plus 1 shared expert |
+| Context window | Up to 1M tokens (the HF config defaults to 256K, sized for single-GPU deployment) |
+| Pre-training | Over 20T tokens, with an NVFP4 pre-training recipe |
+| Speculative decoding | MTP layer baked in, plus separate DSpark and DFlash draft models on HF |
+| Checkpoints | BF16 and NVFP4 |
+| License | OpenMDW-1.1 (weights, data, and recipes released) |
+
+The family resemblance to Nemotron 3 Super and Ultra is deliberate. Same hybrid Mamba-Transformer MoE recipe, same multi-token prediction training, just shrunk to a size where 3B active parameters means memory bandwidth stops being your enemy. On a bandwidth-bound box like the Spark (273 GB/s), the active parameter count is what decides your decode speed. That is the reason this model exists at this size.
+
+NVIDIA's own positioning worth repeating: on PinchBench it scores 86% while completing 10,000 tasks about 30% faster than Qwen3.6 35B at similar accuracy (their blog says 30%, the launch tweet says 35%, I am going with the blog). They also claim up to 4x the output speed of similar-sized models. Those are NVIDIA's numbers, mine are below.
+
+## The gotcha: your Ollama is too old
+
+Ollama is a day-one launch partner, and the model is already in the library. But:
+
+```
+$ ollama pull nemotron-3.5-lightning:30b-a3b
+Error: pull model manifest: 412:
+The model you are attempting to pull requires a newer version of Ollama.
+```
+
+Support for the Nemotron 3.5 architecture landed in [Ollama v0.32.9](https://github.com/ollama/ollama/releases/tag/v0.32.9), released today, a few hours after the model itself. Anything older fails with that 412, and on launch day "older" included both my Spark's install (0.30.10) and the `ollama/ollama:latest` Docker image (still 0.32.6 when I tried it). The fix is to upgrade, then pull again.
+
+```bash
+curl -fsSL https://ollama.com/install.sh | sh
+ollama pull nemotron-3.5-lightning:30b-a3b
+ollama run nemotron-3.5-lightning:30b-a3b
+```
+
+By the time you read this, a plain upgrade is probably all you need. I mention it because if you searched that 412 error, this is why.
+
+25GB download. The Ollama build is a Q4_K_M GGUF that `ollama show` reports as 32.9B parameters (the gap vs the marketing 30B is likely the MTP layer and embeddings being counted). Two things worth noticing in the model metadata: it ships with `draft_num_predict 2`, meaning Ollama is already using the baked-in multi-token prediction for speculative decoding out of the box, and it lists `tools` and `thinking` capabilities. Keep in mind this is not the NVFP4 checkpoint. More on that at the end.
+
+## The numbers
+
+All runs on my DGX Spark (GB10, 128GB unified memory, DGX OS), Ollama 0.32.9, temperature 0, measured via the API so the tok/s figures come from Ollama's own eval counters, 3 runs each.
+
+First, the footprint. Cold load took 27.3 seconds, and `ollama ps` reports 26GB resident at 100% GPU. Interesting detail: Ollama loads this model with the full 262,144 token context window by default, and even at 256K context the whole thing plus KV cache room fits with roughly 86GB of the unified pool still available. On a 24GB card you would be making painful tradeoffs; here it just loads.
+
+```
+NAME                              SIZE     PROCESSOR    CONTEXT
+nemotron-3.5-lightning:30b-a3b    26 GB    100% GPU     262144
+```
+
+The throughput numbers:
+
+| Test | Prefill (uncached) | Decode |
+|---|---|---|
+| Short prompt (39 tok), 500 token generation | small prompt, not meaningful | 71.7 to 73.0 tok/s |
+| 8,194 token prompt, 200 token generation | 2,583 tok/s | 85 to 87 tok/s |
+| 15,820 token prompt (cache-busted rerun) | 2,655 tok/s | 83.9 tok/s |
+| Agent-style prompt (tool call JSON) | | 85.6 to 86.7 tok/s |
+
+And the raw runs behind that table, straight from the API counters (repeat runs of the same long prompt hit Ollama's prompt cache, which is why I only count uncached first passes for prefill):
+
+```
+short run 1: prompt 39 tok @ 87.6 tok/s   | decode 500 tok @ 73.01 tok/s
+short run 2: prompt 39 tok @ 918.5 tok/s  | decode 500 tok @ 71.90 tok/s
+short run 3: prompt 39 tok @ 824.5 tok/s  | decode 500 tok @ 71.73 tok/s
+long  run 1: prompt 8194 tok @ 2583.4 tok/s | decode 200 tok @ 38.36 tok/s (first-load outlier)
+long  run 2: prompt cached                  | decode 200 tok @ 86.97 tok/s
+long  run 3: prompt cached                  | decode 200 tok @ 85.38 tok/s
+cache-busted: prompt 15820 tok @ 2654.7 tok/s | decode 200 tok @ 83.93 tok/s
+agent run 1: decode 150 tok @ 85.62 tok/s
+agent run 2: decode 150 tok @ 86.17 tok/s
+agent run 3: decode 150 tok @ 85.94 tok/s
+```
+
+So: roughly **72 to 87 tok/s single-stream decode** and about **2,600 tok/s prefill**, sustained even with 8K to 16K tokens of context on the clock. An 8K-token prompt is fully ingested in just over 3 seconds. The one 38 tok/s decode reading happened immediately after the model's very first prefill and never reproduced; the cache-busted rerun confirms decode stays in the 80s with a fresh 15K-token prefill.
+
+Two things surprised me:
+
+**Decode speed depends on what the model is generating.** The short test (YAML plus prose) sat at 72 tok/s while the log-summary and JSON tool-call tests ran 84 to 87 tok/s. My best explanation is the built-in speculative decoding: the Ollama build ships with `draft_num_predict 2`, so the MTP head drafts ahead and predictable output (JSON, repetitive summaries) gets a higher acceptance rate than free-form prose. So the tok/s you get depends on the workload.
+
+**Agent-style calls come back fast.** I gave it a tool-calling prompt (find why an nginx deployment is CrashLooping, respond with the next tool call as JSON). It reasoned for a few hundred tokens, then returned exactly this, end to end in 5.9 seconds:
+
+```json
+{
+  "tool": "run_command",
+  "parameters": {
+    "cmd": "kubectl get pods -n web"
+  }
+}
+```
+
+That is the right first step, and it came back as clean JSON with nothing extra around it. This is a reasoning model by default (Ollama reports the `thinking` capability), so budget for a couple hundred thinking tokens per call, at 86 tok/s that is about 3 seconds of overhead per agent step.
+
+## How it compares with other models on the same box
+
+I first reached for the numbers I measured back in May and the comparison looked flattering. Then I reran everything today, on the same Ollama 0.32.9 server, same prompt, same settings, and the picture changed. (Note: NVIDIA's PinchBench comparison is against Qwen3.6 35B; what I have locally is its predecessor, qwen3.5:35b-a3b, so treat these as class comparisons, not a re-run of NVIDIA's benchmark.)
+
+| Model | Active params | Decode tok/s (today) | My May number |
+|---|---|---|---|
+| **Nemotron 3.5 Lightning 30B-A3B** | ~3B | **71.7 to 73.0** (prose), **84 to 87** (JSON, summaries) | n/a, launched today |
+| qwen3.5:35b-a3b | ~3B | 78.1 | 52.7 |
+| gemma4:26b (26B-A4B MoE) | ~4B | 66.2 | 58.0 |
+| nemotron-3-super (120B-A12B) | ~12B | 21.8 | 17.7 |
+
+The first thing this table shows has nothing to do with Nemotron: **the runtime itself got faster**. Qwen3.5 35B-A3B went from 52.7 to 78.1 tok/s on the same hardware since May, because Ollama now exploits its MTP head for speculative decoding too. If you are still quoting tok/s numbers from a months-old Ollama, they are stale. Mine were.
+
+The second thing: **through Ollama, raw decode speed against Qwen3.5 35B-A3B is basically a tie.** On the identical prose prompt, Qwen was actually a touch faster (78 vs 72). NVIDIA's "up to 4x the output speed of similar-sized models" comes from the Artificial Analysis leaderboard, measuring hosted NVFP4 endpoints with the full draft-model stack; you do not see that 4x through Ollama today. Against its own big brother Nemotron 3 Super, the model it is meant to take execution work from, Lightning is a real 3.3x to 4x.
+
+Where Lightning does win is token efficiency. I gave qwen3.5:35b-a3b the exact CrashLoop agent prompt from earlier, temperature 0. Both models produced the identical correct `kubectl get pods -n web` tool call:
+
+| | Tokens to answer | Wall clock |
+|---|---|---|
+| Nemotron 3.5 Lightning | 485 | 5.9s |
+| qwen3.5:35b-a3b | 1,953 | 26.0s |
+
+Qwen thought four times longer to reach the same place. One prompt is not a benchmark, but it is exactly the behavior NVIDIA claims Lightning was trained for: their PinchBench pitch is 30% faster task completion at similar accuracy, a time-to-done argument rather than a tok/s argument. On this one task the agent step finished 4.4x sooner. For an agent doing thousands of steps a day, tokens per step matters more than tokens per second.
+
+## Update: the NVFP4 checkpoint with vLLM and DSpark
+
+The Ollama numbers above are the Q4_K_M GGUF. NVIDIA's recommended path for the Spark is different: the NVFP4 checkpoint served by vLLM with the DSpark draft model doing speculative decoding. The exact recipe is on the [NVFP4 model card](https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4), and it runs in the stock `vllm/vllm-openai:v0.27.1` image, no special Spark build needed:
+
+```bash
+docker run -d --name vllm-lightning --gpus all --ipc=host --network=host \
+  -v $HOME/.cache/huggingface:/root/.cache/huggingface \
+  vllm/vllm-openai:v0.27.1 \
+  --model nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 \
+  --served-model-name nemotron-3.5-lightning \
+  --moe-backend marlin \
+  --kv-cache-dtype fp8 \
+  --max-model-len 65536 \
+  --enable-prefix-caching \
+  --speculative_config.method dspark \
+  --speculative_config.model nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark \
+  --speculative_config.num_speculative_tokens 3 \
+  --mamba-backend flashinfer \
+  --mamba-cache-mode align \
+  --gpu-memory-utilization 0.80 \
+  --reasoning-parser nemotron_v3 \
+  --tool-call-parser qwen3_coder \
+  --enable-auto-tool-choice
+```
+
+One note on NVIDIA's recipe: it sets `--gpu-memory-utilization 0.91`, which on this box allocates 88GB of KV cache. I tested both. 0.91 starts and runs fine on this stack, and decodes at the same speed, but it leaves about 1GB of free system memory on a machine where CPU and GPU share the pool. I ran the benchmarks at 0.80: identical single-stream decode, 75GB of KV cache, and 12GB of headroom. The bigger allocation only buys you more concurrent requests, so if the Spark is doing anything else at all, 0.80 is the safer number (weights are 21.5GB, engine init took just under 2 minutes).
+
+Same prompts, same method as the Ollama tests:
+
+![Ollama vs vLLM decode and prefill speeds for Nemotron 3.5 Lightning on DGX Spark](/img/blog/nemotron-3-5-lightning-on-dgx-spark/ollama-vs-vllm.png)
+
+| Test | Ollama (GGUF Q4_K_M) | vLLM (NVFP4 + DSpark) |
+|---|---|---|
+| Short prompt, 500 token decode | 72 tok/s | **108 tok/s** |
+| Agent-style prompt, decode | 86 tok/s | **95 to 98 tok/s** |
+| Long prompt, decode after prefill | 84 to 87 tok/s | **88 to 90 tok/s** |
+| Prefill, uncached | ~2,600 tok/s | **~5,400 tok/s** |
+
+The raw vLLM runs:
+
+```
+short run 1: decode 500 tok @ 108.31 tok/s
+short run 2: decode 500 tok @ 108.26 tok/s
+short run 3: decode 500 tok @ 108.22 tok/s
+long  run 1: prompt 21218 tok, TTFT 3.93s (~5,394 tok/s prefill) | decode @ 89.92 tok/s
+agent runs:  decode @ 98.28 / 94.31 / 95.90 tok/s
+```
+
+So the recommended path is roughly 1.5x the Ollama decode speed and about 2x the prefill, on the same hardware, and it holds ~90 tok/s with 21K tokens of context on the clock. The DSpark draft model is doing real work here: the one public comparison point, a sibling 30B-A3B NVFP4 on a Spark without speculative decoding, sits at 57 tok/s.
+
+One tuning note before someone asks: there are configs circulating that set 256K context and `num_speculative_tokens: 7` instead of 3, some on vLLM nightly builds. I tested the draft depth both ways on both the release image and a current nightly, four combinations total. Depth 3 gives about 108 tok/s single stream on the release image and on EXO's exact nightly alike; depth 7 gives 80 to 93 on both. The mechanics: every verification pass pays for all drafted tokens whether or not they get accepted, and on these prompts the acceptance rate at depth 7 does not cover the extra cost. EXO's numbers come from an 884-task agentic suite where longer contexts may shift that tradeoff, but for single-stream use on this box, 3 is the number I would run.
+
+Two smaller things this test surfaced. First, my "8,194 token prompt" in the Ollama runs was actually Ollama silently truncating a much longer prompt to fit its context setting; vLLM processed the full 21,218 tokens. The per-token prefill rates stand, but it is a good reminder to check `prompt_eval_count` when you benchmark Ollama. Second, these vLLM numbers came through the completions endpoint without the chat template, so the model skipped its long thinking pass on the agent prompt; decode speed is comparable, token counts are not, so I am not re-running the token-efficiency comparison here.
+
+### Benchmark it yourself
+
+The community leaderboard for this box is [Spark Arena](https://spark-arena.com), and it standardizes on llama-benchy sweeps. To run the same sweep against the server above, raise `--max-model-len` to 262144 in the serve command so the deeper context points fit, then:
+
+```bash
+pip install llama-benchy
+llama-benchy --base-url http://localhost:8000/v1 --model nemotron-3.5-lightning \
+  --depth 0 4096 8192 16384 32768 65535 100000 \
+  --pp 2048 --tg 128 --enable-prefix-caching \
+  --concurrency 1 2 5 10 --save-result results.csv
+```
+
+One reading tip for leaderboard numbers, there or anywhere: check whether a tok/s figure is single-stream or an aggregate peak across concurrent requests. The same recipe that decodes around 110 tok/s for one user can show 230+ tok/s summed over ten parallel streams, and the two numbers answer different questions.
+
+## Reality check
+
+A few things to know before you use these numbers:
+
+1. **Runtime matters as much as model.** The same checkpoint family spans 72 to 108 tok/s on this box depending on how you serve it. Quote numbers with their runtime attached.
+2. **Single stream only.** These are one-user interactive numbers. If you want aggregate throughput, that is a vLLM or TensorRT-LLM concurrency story (NVIDIA published [deployment guides](https://developer.nvidia.com/blog/nvidia-nemotron-3-5-lightning-delivers-fast-accurate-specialized-task-execution-for-long-running-agents/) for both).
+3. **Launch-day software.** Ollama support is hours old. Expect the numbers to move as kernels and the runtime settle. I will update if they move meaningfully.
+
+There is one other public number to compare against: the [NVIDIA forum benchmark of Nemotron 3 Nano Omni 30B-A3B](https://forums.developer.nvidia.com/t/benchmark-nvidia-nemotron-3-nano-omni-30b-a3b-reasoning-nvfp4/368566), an architecturally similar 30B-A3B, at 56.96 tok/s decode on a Spark via vLLM NVFP4 without speculative decoding. A 55 to 60 tok/s baseline for this size class, lifted into the 70s and 80s by MTP drafting, matches what I measured.
+
+## Why I care about this model specifically
+
+The interesting part is not the benchmark table, it is the division of labor NVIDIA is pushing. Alongside Lightning they released [NeMo Switchyard](https://developer.nvidia.com/blog/route-ai-agent-workloads-across-models-with-nvidia-nemo-switchyard/), an open source model router: plans go up to a frontier model, execution comes down to Lightning. LangChain measured a 74% cost reduction routing between Lightning and Claude Opus 4.8 with only 7% of calls escalating to the frontier model, at about a 6 point accuracy tradeoff.
+
+A 3B-active model decoding at 108 tok/s on a desktop box fits that execution layer well. The follow-up I want to do next: Lightning on the Spark as the local execution model, a frontier model in the cloud for planning, and Switchyard routing between them. If that sounds interesting, subscribe.
+
+---
+
+# HAMi Dynamic MIG on RTX PRO 6000: A Live Kubernetes Test
+
+- Canonical: https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami
+- Published: 2026-08-11
+- Summary: A hands-on test of topology-aware HAMi Dynamic MIG on RTX PRO 6000 Blackwell, with pinned setup commands, real allocations, mixed profiles, reclamation, and recovery.
+
+The first two posts in this series explored opposite ends of GPU sharing.
+
+In [the MIG deep dive](/blog/slicing-gpus-in-kubernetes-with-nvidia-mig), we carved Blackwell cards into hardware-isolated slices. MIG gives each instance dedicated memory, cache, and compute resources, but a static layout makes profile changes an operational task. In [the HAMi vGPU post](/blog/sharing-gpus-in-kubernetes-with-hami), we requested exact memory and compute fractions through software-enforced `hami-core` mode. That improves packing density, but it is not a hardware isolation boundary.
+
+The natural third question is: can a Kubernetes pod request GPU memory, receive a real MIG instance, and let HAMi manage that instance from creation to cleanup?
+
+We reran that experiment from scratch on August 11, 2026, on an eight-GPU RTX PRO 6000 Blackwell server. This post follows HAMi's topology-aware, per-pod Dynamic MIG implementation from installation through cleanup.
+
+The results were straightforward:
+
+- Four 8,000 MiB requests became four `1g.24gb` instances on one GPU.
+- A fifth identical pod moved to a second GPU after we made that GPU available to HAMi.
+- A `1g.24gb` workload and a `2g.48gb` workload ran together on the same card.
+- Deleting the small workload reclaimed only its MIG instance; the neighboring CUDA workload continued.
+- A valid active allocation survived a HAMi device-plugin restart with the same MIG UUID and continued CUDA progress.
+
+> **Version and migration note:** [PR #2378](https://github.com/Project-HAMi/HAMi/pull/2378) is merged, and this post tests the resulting per-pod implementation at [commit `634bf2b32e68`](https://github.com/Project-HAMi/HAMi/commit/634bf2b32e68e07d3fbcbd6da1ee079392fc07c1). At the time of this rerun, the latest tagged release was `v2.9.0`, which predates that implementation, so reproducing the lab requires the pinned source build below. Once HAMi publishes a release containing PR #2378, prefer its matching official chart and image. Existing `knownMigGeometries` users should follow the [migration guide](https://github.com/Project-HAMi/HAMi/blob/634bf2b32e68e07d3fbcbd6da1ee079392fc07c1/docs/develop/dynamic-mig-migration.md); the walkthrough below covers only the merged per-pod design.
+
+{{dynamic-mig-lifecycle-animation}}
+
+## Dynamic MIG in one sentence
+
+A pod asks for GPU memory. HAMi chooses the smallest allowed MIG profile that has enough NVML-reported memory and a legal free placement, then creates that exact GPU Instance (GI) and Compute Instance (CI) for the pod.
+
+The workload request remains small:
+
+```yaml
+metadata:
+  annotations:
+    nvidia.com/vgpu-mode: "mig"
+spec:
+  schedulerName: hami-scheduler
+  containers:
+    - resources:
+        limits:
+          nvidia.com/gpu: 1
+          nvidia.com/gpumem: 8000
+```
+
+On a `hami-core` node, `gpumem: 8000` is a software-enforced memory limit. On a Dynamic MIG node, it is a minimum memory requirement used to select a hardware profile. This GPU has no 8 GB profile, so the 8,000 MiB request receives `1g.24gb`; the container sees the complete 24,192 MiB MIG instance.
+
+Three details matter:
+
+- `nvidia.com/vgpu-mode: "mig"` explicitly selects the MIG path.
+- Profile selection is memory-driven. `nvidia.com/gpucores` does not select a MIG profile; the profile fixes the compute fraction in hardware.
+- NVIDIA's legal profile sizes and placements still apply. HAMi automates those rules; it does not remove them.
+
+## Why use Dynamic MIG instead of HAMi-Core?
+
+NVIDIA MIG divides a supported GPU into hardware-isolated instances. Each instance receives dedicated memory paths, cache, and compute resources. That is a stronger boundary than several workloads sharing one full GPU through software.
+
+| | HAMi-Core | Topology-aware Dynamic MIG |
+| --- | --- | --- |
+| Isolation | Software-enforced sharing | NVIDIA MIG hardware instance |
+| Size choices | Fine-grained memory and core fractions | Fixed NVIDIA profiles |
+| Pod request | `gpu`, `gpumem`, optional `gpucores` | `gpu`, `gpumem`, and MIG mode annotation |
+| Lifecycle | Software allocation | Create and reclaim one GI/CI per pod |
+| Best fit | High packing flexibility | Stronger workload isolation |
+
+MIG can be part of a multi-tenant security design, but it does not make a platform secure or compliant by itself. Identity, admission, network, storage, runtime, and host controls still matter.
+
+## The RTX PRO 6000 profile menu
+
+NVIDIA's [supported MIG profile table](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/supported-mig-profiles.html) lists three profile sizes for the RTX PRO 6000 Blackwell Server Edition:
+
+| Profile | Approximate memory | SM fraction | Maximum instances |
+| --- | ---: | ---: | ---: |
+| `1g.24gb` | 24 GB | 1/4 | 4 |
+| `2g.48gb` | 48 GB | 1/2 | 2 |
+| `4g.96gb` | 96 GB | Full GPU | 1 |
+
+Profile rounding remains. An 8,000 MiB request receives the 24 GB profile, and the unused difference cannot be assigned to another pod inside that instance.
+
+The implementation tested here uses a profile allowlist as policy:
+
+```yaml
+nvidia:
+  migProfileAllowlist:
+    - models: ["RTX PRO 6000 Blackwell Server Edition"]
+      profiles: ["1g.24gb", "2g.48gb", "4g.96gb"]
+```
+
+For every allowed profile, the HAMi device plugin running on the GPU node asks NVIDIA's Management Library (NVML) for memory, compute metadata, instance count, and legal placements. The scheduler then chooses the smallest profile that satisfies the request and fits without overlapping a live placement.
+
+## Lab environment
+
+| Component | Tested value |
+| --- | --- |
+| Server | Utho single-node GPU server |
+| GPUs | 8 × NVIDIA RTX PRO 6000 Blackwell Server Edition |
+| GPU memory | 97,887 MiB per physical GPU |
+| NVIDIA driver | `610.43.02` |
+| Kubernetes | `v1.35.6` |
+| OS | Ubuntu 24.04.4 LTS, kernel `6.8.0-100-generic` |
+| Container runtime | containerd `2.2.1` |
+| HAMi source | `634bf2b32e68e07d3fbcbd6da1ee079392fc07c1` |
+
+The run started with MIG mode enabled on all eight cards and no active CUDA processes:
+
+```bash
+nvidia-smi \
+  --query-gpu=index,name,uuid,driver_version,memory.total,mig.mode.current \
+  --format=csv
+
+nvidia-smi \
+  --query-compute-apps=gpu_uuid,pid,process_name,used_gpu_memory \
+  --format=csv
+```
+
+The first command inventories the hardware and MIG mode. It returned all eight cards:
+
+```text
+index, name, uuid, driver_version, memory.total [MiB], mig.mode.current
+0, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-8b89b58e-b427-108d-ac50-06138d78fe78, 610.43.02, 97887 MiB, Enabled
+1, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-03a041b7-8abf-360a-d1a2-dfd70188cd5f, 610.43.02, 97887 MiB, Enabled
+2, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-ba09367f-dd50-32ca-e988-7ff66bece885, 610.43.02, 97887 MiB, Enabled
+3, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-30512c46-708b-f374-5698-ee24be6cd626, 610.43.02, 97887 MiB, Enabled
+4, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288, 610.43.02, 97887 MiB, Enabled
+5, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-04dc48d7-7048-aef5-ad36-f5db716e7668, 610.43.02, 97887 MiB, Enabled
+6, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-f4f5db98-143f-0a8d-47ce-956fab39a736, 610.43.02, 97887 MiB, Enabled
+7, NVIDIA RTX PRO 6000 Blackwell Server Edition, GPU-f4c61521-240a-da09-2787-e576034e197e, 610.43.02, 97887 MiB, Enabled
+```
+
+The second command checks for active compute processes before any lifecycle operation. Its real output contained only the header:
+
+```text
+gpu_uuid, pid, process_name, used_gpu_memory [MiB]
+```
+
+That means no CUDA compute process was active at that instant.
+
+> **Host versus cluster commands:** run host-level `nvidia-smi`, Docker, and `ctr` commands on the GPU node. Run `kubectl` and Helm from any machine whose kubeconfig targets the intended cluster. In this lab they all ran on the single RTX node.
+
+## Pin the HAMi build before testing
+
+This step exposed the easiest version trap in the entire lab. At commit `634bf2b`, the checked-out chart and source contain topology-aware Dynamic MIG, but the chart metadata and default image tag still say `2.9.0`. Rendering that chart without image overrides deploys the `v2.9.0` binaries, not the code in the checkout.
+
+Helm's chart or app version is therefore not proof of the running binary. We built the commit and used the same pinned image for the scheduler extender, device plugin, and monitor.
+
+### 1. Back up and inventory the existing installation
+
+Before changing a running lab, capture both Helm's saved values and the live objects. They can differ:
+
+```bash
+export NODE=utho-gpu-rtxpro6000-8-62383
+export LAB=/root/hami-dynamic-mig-rerun-2026-08-11
+
+mkdir -p "$LAB"
+
+helm get values hami -n hami-system --all -o yaml \
+  > "$LAB/helm-values-before.yaml"
+helm get manifest hami -n hami-system \
+  > "$LAB/helm-manifest-before.yaml"
+kubectl get configmaps -n hami-system -o yaml \
+  > "$LAB/live-configmaps-before.yaml"
+kubectl get node "$NODE" -o yaml \
+  > "$LAB/node-before.yaml"
+kubectl get pods -A --field-selector spec.nodeName="$NODE" -o wide
+nvidia-smi -L > "$LAB/nvidia-smi-L-before.txt"
+```
+
+After taking the backups, we stopped every GPU workload and verified that the entire node was idle before continuing.
+
+### 2. Build the exact source snapshot
+
+```bash
+export HAMI_SHA=634bf2b32e68e07d3fbcbd6da1ee079392fc07c1
+export HAMI_TAG=master-634bf2b32e68
+export HAMI_IMAGE=localhost/hami-dynamic-mig:$HAMI_TAG
+
+git clone --recurse-submodules \
+  https://github.com/Project-HAMi/HAMi.git "$LAB/HAMi"
+git -C "$LAB/HAMi" checkout --detach "$HAMI_SHA"
+git -C "$LAB/HAMi" submodule update --init --recursive
+
+make -C "$LAB/HAMi" docker \
+  IMG_NAME=localhost/hami-dynamic-mig \
+  IMG_TAG="$HAMI_TAG" \
+  VERSION="$HAMI_TAG" \
+  TARGET_PLATFORMS=linux/amd64
+
+docker image inspect "$HAMI_IMAGE" \
+  --format='ID={{.Id}} Architecture={{.Architecture}} SizeBytes={{.Size}}'
+```
+
+The final command verifies what was built. Our result was:
+
+```text
+ID=sha256:0ddda56e333ff74e52d9908e00b85e7860cf4694fc09951aaa178e8c8e6dde76 Architecture=amd64 SizeBytes=411671341
+```
+
+For a normal multi-node cluster, push that immutable tag to a registry every target node can reach. Our single-node lab instead imported the image into containerd:
+
+```bash
+docker save --output "$LAB/hami-$HAMI_TAG.tar" "$HAMI_IMAGE"
+sudo ctr --namespace k8s.io images import "$LAB/hami-$HAMI_TAG.tar"
+sudo ctr --namespace k8s.io images list | grep -F "$HAMI_IMAGE"
+```
+
+That local import is suitable only because the scheduler, plugin, and both tested GPUs lived on the same node. `localhost/...` is not an image that another node can pull. On multiple nodes, push the pinned build to a registry or import it on every target node.
+
+### 3. Use current Dynamic MIG values
+
+The relevant parts of our `hami-current-mig-values.yaml` were:
+
+```yaml
+global:
+  imageTag: master-634bf2b32e68
+
+scheduler:
+  defaultSchedulerPolicy:
+    nodeSchedulerPolicy: binpack
+    gpuSchedulerPolicy: binpack
+  extender:
+    image:
+      registry: localhost
+      repository: hami-dynamic-mig
+      tag: master-634bf2b32e68
+      pullPolicy: Never
+
+devicePlugin:
+  image:
+    registry: localhost
+    repository: hami-dynamic-mig
+    tag: master-634bf2b32e68
+    pullPolicy: Never
+  monitor:
+    image:
+      registry: localhost
+      repository: hami-dynamic-mig
+      tag: master-634bf2b32e68
+      pullPolicy: Never
+
+  # This is NVIDIA's static resource-exposure strategy.
+  # Keep it separate from HAMi's per-node operating mode below.
+  migStrategy: none
+
+  nodeConfiguration:
+    config: |
+      {
+        "nodeconfig": [
+          {
+            "name": "utho-gpu-rtxpro6000-8-62383",
+            "operatingmode": "mig",
+            "devicememoryscaling": 1,
+            "devicecorescaling": 1,
+            "devicesplitcount": 10,
+            "preconfigureddevicememory": 0,
+            "enablenumatopology": false,
+            "migstrategy": "none",
+            "filterdevices": {
+              "uuid": [],
+              "index": [0, 1, 2, 3, 5, 6, 7]
+            },
+            "enablegetpreferredallocation": false
+          }
+        ]
+      }
+
+# Empty means: use the device-config.yaml bundled in this pinned chart.
+device-config:
+  content: ""
+```
+
+Two similarly named settings do different jobs:
+
+- `operatingmode: "mig"` activates HAMi Dynamic MIG for this node.
+- Top-level `devicePlugin.migStrategy: none` tells the NVIDIA device-plugin path not to publish pre-created MIG resources separately. The workload still requests the parent resource `nvidia.com/gpu` and HAMi creates the MIG instance dynamically.
+
+Also, `filterdevices.index` is an **exclusion list**. The initial list excluded every card except GPU 4. It did not protect the excluded GPUs from all startup actions; we return to that safety boundary later.
+
+### 4. Render before installing
+
+```bash
+helm lint "$LAB/HAMi/charts/hami" \
+  -f "$LAB/hami-current-mig-values.yaml"
+
+helm template hami "$LAB/HAMi/charts/hami" \
+  --namespace hami-system \
+  --kube-version 1.35.6 \
+  -f "$LAB/hami-current-mig-values.yaml" \
+  > "$LAB/rendered-current-hami.yaml"
+
+grep -n -A 25 'migProfileAllowlist' \
+  "$LAB/rendered-current-hami.yaml"
+grep -n -E 'image:|imagePullPolicy:' \
+  "$LAB/rendered-current-hami.yaml"
+```
+
+The rendered manifest contained the RTX profile allowlist and the pinned image in all three HAMi containers. No `projecthami/hami:v2.9.0` runtime image remained.
+
+Avoid `--reuse-values` here. A saved per-component tag takes precedence over `global.imageTag`, so a stale custom plugin image can survive even when the global tag looks correct.
+
+### 5. Perform the controlled lab handover
+
+> **Destructive lab step:** we used a fresh reinstall only after every GPU pod and process on the single node was gone. Existing clusters should follow the linked migration guide instead of treating `helm uninstall` as a general upgrade procedure.
+
+```bash
+helm uninstall hami -n hami-system --wait --timeout 5m
+
+helm upgrade --install hami "$LAB/HAMi/charts/hami" \
+  -n hami-system \
+  --create-namespace \
+  --reset-values \
+  -f "$LAB/hami-current-mig-values.yaml" \
+  --wait \
+  --timeout 10m
+
+kubectl get pods -n hami-system \
+  -o custom-columns='POD:.metadata.name,CONTAINERS:.spec.containers[*].name,IMAGES:.spec.containers[*].image'
+```
+
+The live output confirmed that the scheduler extender, device plugin, and monitor all used:
+
+```text
+localhost/hami-dynamic-mig:master-634bf2b32e68
+```
+
+The monitor had one transient CDI `StartError` referring to a stale MIG UUID during the handover. Kubernetes retried it, and both plugin containers became ready. We checked the previous container state instead of hiding that transition.
+
+## What HAMi discovered through NVML
+
+The node registration annotation is the clearest view of what the plugin learned from the driver:
+
+```bash
+kubectl get node "$NODE" -o json |
+jq '
+  .metadata.annotations["hami.io/node-nvidia-register"]
+  | fromjson
+  | .[]
+  | {id, index, type, mode, count, migProfiles}
+'
+```
+
+The live discovery was:
+
+| Profile | `memoryMB` | Core | `sliceCount` | Legal NVML placements (`start`, `size`) |
+| --- | ---: | ---: | ---: | --- |
+| `1g.24gb` | 24,192 | 25 | 1 | `(0,3)`, `(3,3)`, `(6,3)`, `(9,3)` |
+| `2g.48gb` | 48,512 | 50 | 2 | `(0,6)`, `(6,6)` |
+| `4g.96gb` | 97,408 | 100 | 4 | `(0,12)` |
+
+NVML reports each legal placement as `start` and `size`: `start` is the index of the first occupied memory slice, and `size` is the number of memory slices occupied. Together they describe the half-open interval `[start, start + size)`. On this RTX PRO 6000, the reported placement range was `[0,12)`; these values are not GiB and are specific to this GPU. Also, `size` is not the same thing as `sliceCount`: `1g.24gb` has `sliceCount: 1` but placement `size: 3` here.
+
+The registered `count: 4` is a coarse maximum derived from the profiles. It does not mean every arbitrary combination of four profiles fits. The placement arrays and current occupancy determine real capacity.
+
+## A repeatable CUDA workload
+
+The test container repeatedly runs NVIDIA's `vectorAdd` sample and increments `/tmp/gpu-progress` after each successful run. That gives us a better health check than a sleeping container.
+
+For readability, this Deployment combines the same workload template we used for the single-pod and packing tests. Save it as `mig-small-pack.yaml` and replace the node name if yours differs:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: mig-small-pack
+  namespace: hami-mig-retest
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: mig-small-pack
+  template:
+    metadata:
+      labels:
+        app: mig-small-pack
+      annotations:
+        nvidia.com/vgpu-mode: "mig"
+        hami.io/gpu-scheduler-policy: "binpack"
+    spec:
+      schedulerName: hami-scheduler
+      nodeSelector:
+        kubernetes.io/hostname: utho-gpu-rtxpro6000-8-62383
+      containers:
+        - name: cuda
+          image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04
+          imagePullPolicy: IfNotPresent
+          command:
+            - bash
+            - -lc
+            - |
+              set -euo pipefail
+              n=0
+              echo 0 > /tmp/gpu-progress
+              while true; do
+                /cuda-samples/vectorAdd > /tmp/vectoradd.last 2>&1
+                n=$((n + 1))
+                echo "$n" > /tmp/gpu-progress.next
+                mv /tmp/gpu-progress.next /tmp/gpu-progress
+              done
+          resources:
+            limits:
+              nvidia.com/gpu: 1
+              nvidia.com/gpumem: 8000
+```
+
+Create the namespace, apply the workload, and wait for the pod to become ready:
+
+```bash
+kubectl create namespace hami-mig-retest
+kubectl apply -f mig-small-pack.yaml
+kubectl rollout status deployment/mig-small-pack \
+  -n hami-mig-retest --timeout=180s
+
+POD=$(kubectl get pods -n hami-mig-retest \
+  -l app=mig-small-pack \
+  -o jsonpath='{.items[0].metadata.name}')
+```
+
+## Test 1: 8,000 MiB becomes one `1g.24gb` instance
+
+HAMi writes its controller-owned identity to `hami.io/vgpu-mig-allocations`. Users should inspect this annotation, but never create or edit it:
+
+```bash
+kubectl get pod "$POD" -n hami-mig-retest -o json |
+jq '.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson'
+```
+
+Our first allocation was:
+
+```json
+[
+  {
+    "containerIndex": 0,
+    "deviceIndex": 0,
+    "gpuUUID": "GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288",
+    "profile": "1g.24gb",
+    "placement": {"start": 9, "size": 3},
+    "migUUID": "MIG-a5fa6120-f6fa-51b6-9820-a42112640629",
+    "gpuInstanceID": 6,
+    "computeInstanceID": 0
+  }
+]
+```
+
+The host and container agreed about the device:
+
+```bash
+# On the GPU node
+nvidia-smi -L
+
+# Through the container's device view
+kubectl exec -n hami-mig-retest "$POD" -- nvidia-smi -L
+```
+
+Both showed one `1g.24gb` instance with UUID `MIG-a5fa...`. The placement happened to start at `9`; the first allocation is not required to start at `0`.
+
+Finally, we verified that the CUDA loop was doing work:
+
+```bash
+before=$(kubectl exec -n hami-mig-retest "$POD" -- cat /tmp/gpu-progress)
+sleep 3
+after=$(kubectl exec -n hami-mig-retest "$POD" -- cat /tmp/gpu-progress)
+printf 'before=%s after=%s\n' "$before" "$after"
+test "$after" -gt "$before"
+```
+
+```text
+before=75 after=77
+```
+
+## Test 2: four legal placements, then real saturation
+
+Scale the same Deployment to four replicas:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=4
+kubectl rollout status deployment/mig-small-pack \
+  -n hami-mig-retest --timeout=180s
+nvidia-smi -L
+```
+
+GPU 4 now contained four `1g.24gb` instances. The allocation annotations used all four legal starts:
+
+```bash
+kubectl get pods -n hami-mig-retest -l app=mig-small-pack -o json |
+jq -r '
+  ["PARENT_GPU", "PROFILE", "START", "SIZE"],
+  (
+    .items[]
+    | (.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson | .[0]) as $a
+    | [$a.gpuUUID, $a.profile, ($a.placement.start | tostring), ($a.placement.size | tostring)]
+  )
+  | @tsv
+'
+```
+
+```text
+PARENT_GPU                                   PROFILE    START  SIZE
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   0      3
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   3      3
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   6      3
+GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   9      3
+```
+
+<figure class="blog-video">
+  <video controls muted playsinline preload="metadata" aria-label="Four 1g.24gb MIG instances created on one RTX PRO 6000 GPU">
+    <source src="/img/blog/dynamic-mig-in-kubernetes-with-hami/4mig.mp4" type="video/mp4" />
+    Your browser does not support embedded MP4 video. You can <a href="/img/blog/dynamic-mig-in-kubernetes-with-hami/4mig.mp4">open the recording directly</a>.
+  </video>
+  <figcaption>Four pods fill the four legal <code>1g.24gb</code> placements on GPU 4.</figcaption>
+</figure>
+
+With only GPU 4 registered, scaling to five did **not** overcommit the card:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=5
+kubectl get pods -n hami-mig-retest -o wide
+```
+
+Four pods remained `Running`; the fifth stayed `Pending` and unbound. Its event included:
+
+```text
+0/1 nodes are available: 1 1/1 CardTimeSlicingExhausted.
+```
+
+That inherited event label is misleading—the test did not use time slicing. Here it meant that no legal MIG placement remained on any registered GPU.
+
+Scale back to four before the next test:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=4
+```
+
+## Test 3: mixed profiles share one physical GPU
+
+The topology-aware implementation can place different profiles together whenever NVML reports legal, non-overlapping placements.
+
+<figure class="blog-video">
+  <video controls muted playsinline preload="metadata" aria-label="Live HAMi Dynamic MIG test with 8000 MiB and 30000 MiB pod requests on one RTX PRO 6000 GPU">
+    <source src="/img/blog/dynamic-mig-in-kubernetes-with-hami/mixed-profiles-lifecycle.mp4" type="video/mp4" />
+    Your browser does not support embedded MP4 video. You can <a href="/img/blog/dynamic-mig-in-kubernetes-with-hami/mixed-profiles-lifecycle.mp4">open the recording directly</a>.
+  </video>
+  <figcaption>A live terminal recording: requests for 8,000 MiB and 30,000 MiB become <code>1g.24gb</code> and <code>2g.48gb</code> instances on the same GPU. Each instance is reclaimed when its requesting pod is deleted; the recording is shown at 2.5&times; speed to shorten the waits.</figcaption>
+</figure>
+
+We cleared the small-pod Deployment, then created an 8,000 MiB pod and a 30,000 MiB pod. Both used the same CUDA loop and were pinned to GPU 4 with `nvidia.com/use-gpuuuid` so the test measured one physical card:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=0
+kubectl wait -n hami-mig-retest \
+  --for=delete pod -l app=mig-small-pack --timeout=180s
+```
+
+This Bash helper creates the same pod twice; only its name and memory request change:
+
+```bash
+export GPU4=GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288
+
+create_mig_pod() {
+  local name="$1"
+  local memory="$2"
+
+  kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: ${name}
+  namespace: hami-mig-retest
+  annotations:
+    nvidia.com/vgpu-mode: "mig"
+    hami.io/gpu-scheduler-policy: "binpack"
+    nvidia.com/use-gpuuuid: "${GPU4}"
+spec:
+  schedulerName: hami-scheduler
+  nodeSelector:
+    kubernetes.io/hostname: ${NODE}
+  containers:
+    - name: cuda
+      image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04
+      imagePullPolicy: IfNotPresent
+      command:
+        - bash
+        - -lc
+        - |
+          set -euo pipefail
+          n=0
+          echo 0 > /tmp/gpu-progress
+          while true; do
+            /cuda-samples/vectorAdd > /tmp/vectoradd.last 2>&1
+            n=\$((n + 1))
+            echo "\$n" > /tmp/gpu-progress.next
+            mv /tmp/gpu-progress.next /tmp/gpu-progress
+          done
+      resources:
+        limits:
+          nvidia.com/gpu: 1
+          nvidia.com/gpumem: ${memory}
+EOF
+}
+
+create_mig_pod mixed-small 8000
+create_mig_pod mixed-large 30000
+
+kubectl wait -n hami-mig-retest --for=condition=Ready \
+  pod/mixed-small pod/mixed-large --timeout=180s
+```
+
+We inspected the controller-owned allocation records with:
+
+```bash
+kubectl get pods mixed-small mixed-large -n hami-mig-retest -o json |
+jq -r '
+  ["POD", "PROFILE", "START", "SIZE", "MIG_UUID", "GI", "CI"],
+  (
+    .items
+    | sort_by(.metadata.name)[]
+    | . as $pod
+    | ($pod.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson | .[0]) as $a
+    | [
+        $pod.metadata.name,
+        $a.profile,
+        ($a.placement.start | tostring),
+        ($a.placement.size | tostring),
+        $a.migUUID,
+        ($a.gpuInstanceID | tostring),
+        ($a.computeInstanceID | tostring)
+      ]
+  )
+  | @tsv
+'
+```
+
+The live allocation table was:
+
+```text
+POD          PROFILE    START  SIZE  MIG_UUID                                      GI  CI
+mixed-large  2g.48gb    0      6     MIG-b23491d8-d784-58d9-bcfa-3c171ead22da      1   0
+mixed-small  1g.24gb    9      3     MIG-a5fa6120-f6fa-51b6-9820-a42112640629      6   0
+```
+
+The intervals `[0,6)` and `[9,12)` do not overlap, so both profiles could coexist. `nvidia-smi -L` showed one `2g.48gb` and one `1g.24gb` instance under GPU 4.
+
+Both CUDA loops advanced during the same three-second window:
+
+```text
+small: 64 -> 67
+large: 37 -> 39
+PASS: both mixed-profile CUDA workloads progressed
+```
+
+## Test 4: reclaim only the pod's own instance
+
+Before deleting the small pod, we recorded the large pod's progress. Then we deleted only `mixed-small` and polled the host until its `1g.24gb` instance disappeared:
+
+```bash
+large_before=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+
+kubectl delete pod mixed-small -n hami-mig-retest
+
+# Reclamation is asynchronous; poll instead of assuming delete is instant.
+watch -n 1 nvidia-smi -L
+```
+
+The host retained only:
+
+```text
+MIG 2g.48gb Device 0: (UUID: MIG-b23491d8-d784-58d9-bcfa-3c171ead22da)
+```
+
+The neighboring CUDA workload continued:
+
+```text
+large: 61 -> 94
+PASS: 2g workload survived 1g reclamation
+```
+
+We produced that check with:
+
+```bash
+large_after=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+printf 'large: %s -> %s\n' "$large_before" "$large_after"
+test "$large_after" -gt "$large_before" \
+  && echo 'PASS: 2g workload survived 1g reclamation'
+```
+
+HAMi does not synchronously destroy the instance inside the `kubectl delete` call. Its annotation reconciler notices that the reservation is no longer active and removes the tracked CI and GI shortly afterward.
+
+We also recreated a `1g.24gb` instance at the freed placement. On this GPU and driver, it received the same `MIG-a5fa...` UUID. The UUID's observed disappearance proved reclamation; its later reappearance proved placement reuse. A MIG UUID is not a generation counter, so do not require a different UUID as proof of recreation.
+
+## Test 5: recover a valid allocation after plugin restart
+
+This is an advanced and disruptive controller test, not a normal workload step. We kept `mixed-large` active, recorded its progress and MIG UUID, then replaced the device-plugin pod:
+
+```bash
+OLD_DP_POD=$(kubectl get pods -n hami-system \
+  -l app.kubernetes.io/component=hami-device-plugin \
+  -o jsonpath='{.items[0].metadata.name}')
+
+progress_before=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+
+kubectl delete pod "$OLD_DP_POD" -n hami-system
+kubectl rollout status daemonset/hami-device-plugin \
+  -n hami-system --timeout=180s
+```
+
+The replacement plugin logged:
+
+```text
+mig init: resolved startup layout inUseGPUs=[4] resetGPUs=[0,1,2,3,5,6,7]
+```
+
+With a complete runtime allocation annotation, it classified GPU 4 as in use, left that card untouched during startup cleanup, verified the live profile and identity through NVML, and adopted the allocation.
+
+The same `2g.48gb` UUID remained, and the workload continued:
+
+```text
+progress: 115 -> 187
+PASS: MIG UUID and CUDA workload survived device-plugin restart
+```
+
+The verification checked both the device and the progress counter:
+
+```bash
+nvidia-smi -L | grep -F 'MIG-b23491d8-d784-58d9-bcfa-3c171ead22da'
+
+progress_after=$(kubectl exec -n hami-mig-retest mixed-large -- \
+  cat /tmp/gpu-progress)
+printf 'progress: %s -> %s\n' "$progress_before" "$progress_after"
+test "$progress_after" -gt "$progress_before"
+```
+
+This proves the tested happy path for a valid annotation. It is not a guarantee that incomplete or malformed state can always be adopted.
+
+> **Node-wide safety warning:** `filterdevices` limits HAMi registration and scheduling, but at this commit it does not limit Dynamic MIG startup cleanup. The log shows that startup reconciled all eight physical GPUs, including filtered ones. Inventory and drain the entire node before the first install or a plugin restart; filtering a GPU is not a protection boundary.
+
+## Test 6: the fifth pod spills to GPU 5
+
+After deleting the mixed-profile workload and confirming no MIG instances remained, we changed the exclusion list from:
+
+```bash
+kubectl delete pod mixed-large -n hami-mig-retest
+
+until ! nvidia-smi -L | grep -q '^  MIG '; do
+  sleep 2
+done
+```
+
+```json
+"index": [0, 1, 2, 3, 5, 6, 7]
+```
+
+to:
+
+```json
+"index": [0, 1, 2, 3, 6, 7]
+```
+
+That made GPUs 4 and 5 available to HAMi. We applied the values and explicitly restarted the plugin only after confirming the whole node was idle:
+
+```bash
+helm upgrade hami "$LAB/HAMi/charts/hami" \
+  -n hami-system \
+  --reset-values \
+  -f "$LAB/hami-current-mig-values.yaml" \
+  --wait \
+  --timeout 10m
+
+# This configuration change did not trigger a plugin rollout by itself.
+kubectl rollout restart daemonset/hami-device-plugin -n hami-system
+kubectl rollout status daemonset/hami-device-plugin \
+  -n hami-system --timeout=180s
+```
+
+This revealed a chart behavior worth knowing: Helm successfully updated the node-configuration ConfigMap, but the DaemonSet template did not checksum that ConfigMap. Registration stayed unchanged until we restarted the plugin.
+
+The node then registered GPUs 4 and 5 in MIG mode. Scaling the small-pod Deployment to five produced this real distribution:
+
+```bash
+kubectl scale deployment/mig-small-pack \
+  -n hami-mig-retest --replicas=5
+kubectl rollout status deployment/mig-small-pack \
+  -n hami-mig-retest --timeout=180s
+
+kubectl get pods -n hami-mig-retest -l app=mig-small-pack -o json |
+jq -r '
+  ["POD", "PARENT_GPU", "PROFILE", "START", "MIG_UUID"],
+  (
+    .items
+    | sort_by(.metadata.name)[]
+    | . as $pod
+    | ($pod.metadata.annotations["hami.io/vgpu-mig-allocations"] | fromjson | .[0]) as $a
+    | [
+        $pod.metadata.name,
+        $a.gpuUUID,
+        $a.profile,
+        ($a.placement.start | tostring),
+        $a.migUUID
+      ]
+  )
+  | @tsv
+'
+```
+
+```text
+POD                               PARENT_GPU                                   PROFILE    START
+mig-small-pack-6f5b7bd7b-dwld2    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   3
+mig-small-pack-6f5b7bd7b-g72fd    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   0
+mig-small-pack-6f5b7bd7b-jgql2    GPU-04dc48d7-7048-aef5-ad36-f5db716e7668   1g.24gb   9
+mig-small-pack-6f5b7bd7b-rlxbn    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   9
+mig-small-pack-6f5b7bd7b-vjfv9    GPU-4c395b7a-a7e6-d90f-1ced-d96e8dd68288   1g.24gb   6
+```
+
+GPU 4 held all four legal `1g.24gb` placements. The fifth pod received a legal placement on GPU 5. Again, its first placement happened to start at `9`; HAMi does not promise to allocate starts in numerical order.
+
+## Cleanup and final state
+
+We deleted the test namespace and waited for all per-pod MIG instances to be reclaimed:
+
+```bash
+kubectl delete namespace hami-mig-retest \
+  --wait=true --timeout=180s
+
+if nvidia-smi -L | grep -q '^  MIG '; then
+  echo 'FAIL: MIG instances remain'
+  nvidia-smi -L
+else
+  echo 'PASS: no MIG instances remain'
+fi
+```
+
+Then we restored the original exclusion list, applied the values, and performed the same safe plugin restart. The final verification was:
+
+```bash
+printf 'Registered GPU indices: '
+kubectl get node "$NODE" -o json |
+jq -r '
+  .metadata.annotations["hami.io/node-nvidia-register"]
+  | fromjson
+  | map(.index)
+  | join(",")
+'
+
+if nvidia-smi -L | grep -q '^  MIG '; then
+  echo 'MIG state: FAIL — instances remain'
+else
+  echo 'MIG state: PASS — no instances remain'
+fi
+
+kubectl get pods -n hami-system
+```
+
+```text
+Registered GPU indices: 4
+MIG state: PASS — no instances remain
+NAME                              READY   STATUS    RESTARTS
+hami-device-plugin-6snlc          2/2     Running   0
+hami-scheduler-74fbfcfbb5-qxftm   2/2     Running   0
+```
+
+That left the lab in its intended baseline: only GPU 4 registered with HAMi, no test MIG instances, and both HAMi components healthy.
+
+## Operational traps we hit
+
+### Chart metadata is not the runtime version
+
+At the tested commit, the chart still defaults to `v2.9.0`. Pin and inspect the live images for the scheduler extender, device plugin, and monitor. Do not publish `latest`, and do not rely on Helm's app-version label.
+
+### `operatingmode` is not `migStrategy`
+
+Use per-node `operatingmode: "mig"` for HAMi Dynamic MIG. Keep the Helm-level `devicePlugin.migStrategy` decision separate; changing only the similarly named field inside the JSON is not how this chart controls the NVIDIA plugin flag.
+
+### `filterdevices` excludes registration, not startup mutation
+
+The exclusion list controls which GPUs HAMi advertises for scheduling. It does not isolate the other physical cards from startup reconciliation. Treat first installation and plugin restart as node-wide maintenance at this commit.
+
+### A Helm upgrade may not restart the device plugin
+
+Changing `devicePlugin.nodeConfiguration.config` updated the ConfigMap but did not roll the DaemonSet in our test. Restart it deliberately, only after the node-wide safety check, then verify the registration annotation rather than trusting Helm's success message.
+
+### Scheduler events can use inherited language
+
+`CardTimeSlicingExhausted` described exhausted MIG placements in this run; it did not mean HAMi silently switched to time slicing. Confirm the allocation annotation and host MIG state before interpreting a generic reason string.
+
+### Reclamation is eventual, and UUIDs may be reused
+
+Poll the actual host state after pod deletion. The same placement can return the same MIG UUID, so disappearance between deletion and recreation is stronger lifecycle evidence than UUID inequality.
+
+### Legal placement still controls mixed profiles
+
+Dynamic does not mean arbitrary. The scheduler can combine profiles only when their NVML placement intervals do not overlap, and active instances cannot be destroyed just to satisfy a new request.
+
+### Homogeneous success is not a heterogeneous-node guarantee
+
+This node contained eight identical supported GPUs. Test mixed-model nodes separately; do not assume that filtering unsupported cards reproduces the same startup behavior.
+
+## Conclusion
+
+Topology-aware Dynamic MIG kept the Kubernetes API simple while making the hardware lifecycle precise. An 8,000 MiB request selected `1g.24gb`; four legal placements filled GPU 4; a fifth pod used GPU 5; and `1g.24gb` plus `2g.48gb` occupied legal mixed placements on the same card.
+
+The most useful result was not just allocation. HAMi reclaimed the small pod's exact GI/CI while its neighbor kept computing, and a valid allocation survived device-plugin restart and adoption. Those are the behaviors a dynamic controller needs to prove.
+
+The caveats are equally important. Profile rounding and NVIDIA placement rules remain. Version alignment must be verified from live images. At this snapshot, plugin startup has a node-wide hardware scope even when only one GPU is registered, so controlled installation and restart procedures are mandatory.
+
+HAMi is a CNCF Incubating project. Its source is at [github.com/Project-HAMi/HAMi](https://github.com/Project-HAMi/HAMi). Existing installations can use the [pinned Dynamic MIG migration guide](https://github.com/Project-HAMi/HAMi/blob/634bf2b32e68e07d3fbcbd6da1ee079392fc07c1/docs/develop/dynamic-mig-migration.md) when moving to this per-pod implementation.
+
+If you are joining the series here, read the [static MIG deep dive](/blog/slicing-gpus-in-kubernetes-with-nvidia-mig) and the [HAMi software vGPU guide](/blog/sharing-gpus-in-kubernetes-with-hami) first.
+
+---
+
 # Devin Outposts on Kubernetes: Why Your AI Agent Needs Your Cluster
 
 - Canonical: https://blog.kubesimplify.com/devin-outposts-on-kubernetes
diff --git a/public/llms.txt b/public/llms.txt
index bcb067242..ed601be2a 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 193 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 195 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,8 +34,10 @@ 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 193)
+## Recent posts (most recent 30 of 195)
 
+- [Running Nemotron 3.5 Lightning on DGX Spark](https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark) (2026-08-11). NVIDIA's new Nemotron 3.5 Lightning on DGX Spark: how to run it with Ollama and vLLM, the tokens per second I measured, and how the two paths compare.
+- [HAMi Dynamic MIG on RTX PRO 6000: A Live Kubernetes Test](https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami) (2026-08-11). A hands-on test of topology-aware HAMi Dynamic MIG on RTX PRO 6000 Blackwell, with pinned setup commands, real allocations, mixed profiles, reclamation, and recovery.
 - [Devin Outposts on Kubernetes: Why Your AI Agent Needs Your Cluster](https://blog.kubesimplify.com/devin-outposts-on-kubernetes) (2026-08-10). Devin Outposts runs AI coding agent sessions as pods on your own Kubernetes cluster, with an open-source operator to manage the fleet.
 - [How to Share GPUs in Kubernetes at Scale with HAMi (Software vGPU Slicing)](https://blog.kubesimplify.com/sharing-gpus-in-kubernetes-with-hami) (2026-07-23). Share NVIDIA GPUs in Kubernetes with HAMi software vGPU slicing: memory and compute limits, Helm configuration, a verified PyTorch manifest, a real RTX PRO 6000 OOM test, and Prometheus monitoring.
 - [Slicing GPUs in Kubernetes with NVIDIA Multi-Instance GPU (MIG)](https://blog.kubesimplify.com/slicing-gpus-in-kubernetes-with-nvidia-mig) (2026-07-20). 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.
@@ -64,47 +66,45 @@ Authoritative, practitioner-written, citation-friendly. Articles include code ex
 - [What Actually Happens When You Run kubectl run nginx](https://blog.kubesimplify.com/kubectl-run-nginx-inside) (2026-04-24). Every step of what happens when you run kubectl run nginx on Kubernetes. From argv to etcd Raft, scheduler, CRI, CNI, runc, and PLEG.
 - [Day 2: Your Images Are a Supply Chain - and It's Probably Broken](https://blog.kubesimplify.com/day-2-your-images-are-a-supply-chain-and-it-s-probably-broken) (2026-04-23)
 - [Day 1: What Actually Happens When You Type docker run](https://blog.kubesimplify.com/day-1-what-actually-happens-when-you-type-docker-run) (2026-04-22). Containers aren't VMs. They're Linux processes. A Docker Captain explains namespaces, cgroups, and how Docker really works on your Mac in 2026.    
-- [\"SSH Into Your DGX Spark From Anywhere in the World Using Tailscale](https://blog.kubesimplify.com/ssh-into-your-dgx-spark-from-anywhere-in-the-world-using-tailscale) (2026-04-07). Learn how to set up Tailscale on your NVIDIA DGX Spark for secure SSH access from anywhere in the world.
-- [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.
 
 ## Topics covered (auto-derived from tags)
 
-- kubernetes (98 articles): https://blog.kubesimplify.com/tag/kubernetes
+- kubernetes (99 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
 - linux (19 articles): https://blog.kubesimplify.com/tag/linux
 - containers (17 articles): https://blog.kubesimplify.com/tag/containers
 - cloud (16 articles): https://blog.kubesimplify.com/tag/cloud
+- nvidia (12 articles): https://blog.kubesimplify.com/tag/nvidia
 - aws (12 articles): https://blog.kubesimplify.com/tag/aws
 - 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 (10 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
+- dgxspark (8 articles): https://blog.kubesimplify.com/tag/dgxspark
 - 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
 - local-ai (7 articles): https://blog.kubesimplify.com/tag/local-ai
 - docker-images (7 articles): https://blog.kubesimplify.com/tag/docker-images
 - kubesimplify (7 articles): https://blog.kubesimplify.com/tag/kubesimplify
 - linux-basics (7 articles): https://blog.kubesimplify.com/tag/linux-basics
+- ai-agents (6 articles): https://blog.kubesimplify.com/tag/ai-agents
+- platform-engineering (6 articles): https://blog.kubesimplify.com/tag/platform-engineering
 - ai (6 articles): https://blog.kubesimplify.com/tag/ai
-- opensource (6 articles): https://blog.kubesimplify.com/tag/opensource
-- docker-desktop (6 articles): https://blog.kubesimplify.com/tag/docker-desktop
 
 ## Top contributors
 
-- [Saiyam Pathak](https://blog.kubesimplify.com/author/saiyam-pathak) (36 posts)
+- [Saiyam Pathak](https://blog.kubesimplify.com/author/saiyam-pathak) (37 posts)
 - [Saloni Narang](https://blog.kubesimplify.com/author/saloni-narang) (24 posts)
 - [Kunal Verma](https://blog.kubesimplify.com/author/kunal-verma) (12 posts)
 - [Dipankar Das](https://blog.kubesimplify.com/author/dipankar-das) (9 posts)
 - [Anurag Kumar](https://blog.kubesimplify.com/author/anurag-kumar) (8 posts)
 - [sysxplore](https://blog.kubesimplify.com/author/sysxplore) (6 posts)
+- [Shubham Katara](https://blog.kubesimplify.com/author/shubham-katara) (5 posts)
 - [Arnav Barman](https://blog.kubesimplify.com/author/arnav-barman) (5 posts)
-- [Shubham Katara](https://blog.kubesimplify.com/author/shubham-katara) (4 posts)
 - [Srinivas Karnati](https://blog.kubesimplify.com/author/srinivas-karnati) (4 posts)
 - [Barkatul Mujauddin](https://blog.kubesimplify.com/author/barkatul-mujauddin) (4 posts)
 - [Santoshdts](https://blog.kubesimplify.com/author/santoshdts) (3 posts)
diff --git a/public/rss.xml b/public/rss.xml
index 1a93de4bf..e6bf6d7bf 100644
--- a/public/rss.xml
+++ b/public/rss.xml
@@ -6,8 +6,24 @@
     <atom:link href="https://blog.kubesimplify.com/rss.xml" rel="self" type="application/rss+xml"/>
     <description>Deep dives on Kubernetes, AI infrastructure, GitOps, and the cloud-native stack, written by practitioners.</description>
     <language>en-us</language>
-    <lastBuildDate>Mon, 10 Aug 2026 14:15:00 GMT</lastBuildDate>
+    <lastBuildDate>Tue, 11 Aug 2026 17:40:00 GMT</lastBuildDate>
     <generator>Kubesimplify static blog</generator>
+    <item>
+      <title>Running Nemotron 3.5 Lightning on DGX Spark</title>
+      <link>https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark</link>
+      <guid isPermaLink="true">https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark</guid>
+      <pubDate>Tue, 11 Aug 2026 17:40:00 GMT</pubDate>
+      <description>NVIDIA&apos;s new Nemotron 3.5 Lightning on DGX Spark: how to run it with Ollama and vLLM, the tokens per second I measured, and how the two paths compare.</description>
+      <category>nvidia</category><category>dgxspark</category><category>nemotron</category><category>ai-agents</category><category>ollama</category>
+    </item>
+    <item>
+      <title>HAMi Dynamic MIG on RTX PRO 6000: A Live Kubernetes Test</title>
+      <link>https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami</link>
+      <guid isPermaLink="true">https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami</guid>
+      <pubDate>Tue, 11 Aug 2026 10:00:00 GMT</pubDate>
+      <description>A hands-on test of topology-aware HAMi Dynamic MIG on RTX PRO 6000 Blackwell, with pinned setup commands, real allocations, mixed profiles, reclamation, and recovery.</description>
+      <category>kubernetes</category><category>gpu</category><category>nvidia</category><category>platform-engineering</category>
+    </item>
     <item>
       <title>Devin Outposts on Kubernetes: Why Your AI Agent Needs Your Cluster</title>
       <link>https://blog.kubesimplify.com/devin-outposts-on-kubernetes</link>
diff --git a/scripts/gen-dynamic-mig-cover.mjs b/scripts/gen-dynamic-mig-cover.mjs
new file mode 100644
index 000000000..2a09672be
--- /dev/null
+++ b/scripts/gen-dynamic-mig-cover.mjs
@@ -0,0 +1,178 @@
+// Excalidraw-style cover for the HAMi dynamic MIG article.
+// Same sketch helpers as scripts/gen-hami-diagrams.mjs.
+import { mkdirSync, writeFileSync } from 'node:fs';
+import { join } from 'node:path';
+
+let seed = 42;
+const random = () => {
+  seed = (seed * 16807) % 2147483647;
+  return seed / 2147483647;
+};
+const jitter = (amount) => (random() - 0.5) * amount * 2;
+
+const COLORS = {
+  ink: '#172033',
+  muted: '#5c677d',
+  green: { stroke: '#5d8f00', fill: '#d8f5a2' },
+  blue: { stroke: '#1971c2', fill: '#a5d8ff' },
+  violet: { stroke: '#862e9c', fill: '#eebefa' },
+  orange: { stroke: '#d9480f', fill: '#ffd8a8' },
+  red: { stroke: '#c92a2a', fill: '#ffc9c9' },
+  teal: { stroke: '#087f5b', fill: '#b2f2bb' },
+  gray: { stroke: '#495057', fill: '#e9ecef' },
+};
+
+const FONT = 'Chalkboard SE, Comic Sans MS, sans-serif';
+
+function roughLine(x1, y1, x2, y2, amount = 1.8) {
+  const middleX = (x1 + x2) / 2 + jitter(amount * 1.5);
+  const middleY = (y1 + y2) / 2 + jitter(amount * 1.5);
+  return `M ${(x1 + jitter(amount)).toFixed(1)} ${(y1 + jitter(amount)).toFixed(1)} Q ${middleX.toFixed(1)} ${middleY.toFixed(1)} ${(x2 + jitter(amount)).toFixed(1)} ${(y2 + jitter(amount)).toFixed(1)}`;
+}
+
+class Sketch {
+  constructor(width, height, background = '#ffffff') {
+    this.width = width;
+    this.height = height;
+    this.background = background;
+    this.parts = [];
+    this.defs = [];
+    this.clipId = 0;
+  }
+
+  add(value) {
+    this.parts.push(value);
+  }
+
+  rect(x, y, width, height, options = {}) {
+    const {
+      stroke = COLORS.ink,
+      fill,
+      strokeWidth = 2.4,
+      dashed = false,
+      hachure = true,
+      radius = 7,
+    } = options;
+
+    if (fill) {
+      if (hachure) {
+        // Hatch lines are clipped in math rather than with an SVG clipPath so
+        // the file renders identically in renderers without clipPath support.
+        const hatch = [];
+        for (let offset = -height; offset < width; offset += 11) {
+          const tMin = Math.max(0, -offset / height);
+          const tMax = Math.min(1, (width - offset) / height);
+          if (tMax - tMin < 0.05) continue;
+          const x1 = x + offset + height * tMin;
+          const y1 = y + height - height * tMin;
+          const x2 = x + offset + height * tMax;
+          const y2 = y + height - height * tMax;
+          hatch.push(roughLine(x1, y1, x2, y2, 1));
+        }
+        this.add(`<path d="${hatch.join(' ')}" stroke="${fill}" stroke-width="2.5" opacity="0.58" fill="none" stroke-linecap="round"/>`);
+      } else {
+        this.add(`<rect x="${x}" y="${y}" width="${width}" height="${height}" rx="${radius}" fill="${fill}" fill-opacity="0.62"/>`);
+      }
+    }
+
+    const points = [[x, y], [x + width, y], [x + width, y + height], [x, y + height]];
+    for (let pass = 0; pass < 2; pass += 1) {
+      const path = points.map((point, index) => {
+        const next = points[(index + 1) % points.length];
+        return roughLine(point[0], point[1], next[0], next[1], pass === 0 ? 2 : 1.2);
+      }).join(' ');
+      this.add(`<path d="${path}" stroke="${stroke}" stroke-width="${pass === 0 ? strokeWidth : strokeWidth * 0.55}" opacity="${pass === 0 ? 1 : 0.55}" fill="none" stroke-linecap="round"${dashed ? ' stroke-dasharray="9 8"' : ''}/>`);
+    }
+  }
+
+  line(x1, y1, x2, y2, options = {}) {
+    const { stroke = COLORS.ink, strokeWidth = 2.4, dashed = false } = options;
+    this.add(`<path d="${roughLine(x1, y1, x2, y2)}" stroke="${stroke}" stroke-width="${strokeWidth}" fill="none" stroke-linecap="round"${dashed ? ' stroke-dasharray="8 8"' : ''}/>`);
+  }
+
+  arrow(x1, y1, x2, y2, options = {}) {
+    const { stroke = COLORS.ink, strokeWidth = 2.6, dashed = false } = options;
+    this.line(x1, y1, x2, y2, { stroke, strokeWidth, dashed });
+    const angle = Math.atan2(y2 - y1, x2 - x1);
+    const length = 14;
+    for (const offset of [Math.PI * 0.82, -Math.PI * 0.82]) {
+      this.line(
+        x2,
+        y2,
+        x2 + length * Math.cos(angle + offset),
+        y2 + length * Math.sin(angle + offset),
+        { stroke, strokeWidth }
+      );
+    }
+  }
+
+  text(x, y, value, options = {}) {
+    const {
+      size = 22,
+      color = COLORS.ink,
+      anchor = 'middle',
+      weight = 500,
+      family = FONT,
+    } = options;
+    const safe = String(value)
+      .replace(/&/g, '&amp;')
+      .replace(/</g, '&lt;')
+      .replace(/>/g, '&gt;');
+    this.add(`<text x="${x}" y="${y}" font-family="${family}" font-size="${size}" font-weight="${weight}" fill="${color}" text-anchor="${anchor}">${safe}</text>`);
+  }
+
+  lines(x, y, values, options = {}) {
+    const lineHeight = (options.size || 22) * (options.lineHeight || 1.28);
+    values.forEach((value, index) => this.text(x, y + index * lineHeight, value, options));
+  }
+
+  save(path) {
+    const svg = `<svg xmlns="http://www.w3.org/2000/svg" width="${this.width}" height="${this.height}" viewBox="0 0 ${this.width} ${this.height}">
+<defs>${this.defs.join('')}</defs>
+<rect width="${this.width}" height="${this.height}" fill="${this.background}"/>
+${this.parts.join('\n')}
+</svg>`;
+    writeFileSync(path, svg);
+  }
+}
+
+const output = process.argv[2] || '.';
+mkdirSync(output, { recursive: true });
+
+// Cover: social-card aspect ratio, matching the trilogy's visual language.
+{
+  const sketch = new Sketch(1200, 630, '#f8fafc');
+  sketch.text(64, 68, 'KUBESIMPLIFY · GPU SHARING', { size: 19, anchor: 'start', weight: 800, color: COLORS.green.stroke });
+  sketch.lines(64, 158, ['HAMi Dynamic MIG on', 'RTX PRO 6000'], { size: 52, anchor: 'start', weight: 800, lineHeight: 1.12 });
+  sketch.lines(64, 292, ['Topology-aware per-pod placements, tested with', 'real CUDA workloads on Blackwell.'], { size: 22, anchor: 'start', color: COLORS.muted, lineHeight: 1.38 });
+
+  sketch.rect(70, 407, 515, 112, { stroke: COLORS.blue.stroke, fill: COLORS.blue.fill });
+  sketch.text(327, 449, '4 × 1g on GPU 4  →  fifth on GPU 5', { size: 22, weight: 800, color: COLORS.blue.stroke });
+  sketch.text(327, 488, 'exact placement · exact reclamation', { size: 18, color: COLORS.muted });
+
+  sketch.rect(720, 95, 390, 420, { stroke: COLORS.gray.stroke, fill: COLORS.gray.fill, strokeWidth: 3 });
+  sketch.text(915, 138, 'mixed profiles · one GPU', { size: 26, weight: 800 });
+  sketch.text(915, 170, 'NVML legal placements', { size: 20, color: COLORS.muted });
+
+  const placementY = 225;
+  sketch.rect(750, placementY, 163, 125, { stroke: COLORS.blue.stroke, fill: COLORS.blue.fill });
+  sketch.text(831.5, placementY + 51, '2g.48gb', { size: 20, weight: 800, color: COLORS.blue.stroke });
+  sketch.text(831.5, placementY + 83, 'start 0 · size 6', { size: 15, color: COLORS.muted });
+
+  sketch.rect(922, placementY, 77, 125, { stroke: COLORS.gray.stroke, fill: '#ffffff', dashed: true, hachure: false });
+  sketch.text(960.5, placementY + 59, 'free', { size: 16, weight: 700, color: COLORS.gray.stroke });
+  sketch.text(960.5, placementY + 84, 'gap', { size: 14, color: COLORS.muted });
+
+  sketch.rect(1008, placementY, 77, 125, { stroke: COLORS.green.stroke, fill: COLORS.green.fill });
+  sketch.text(1046.5, placementY + 45, '1g', { size: 19, weight: 800, color: COLORS.green.stroke });
+  sketch.text(1046.5, placementY + 72, '24gb', { size: 15, color: COLORS.muted });
+  sketch.text(1046.5, placementY + 99, 'start 9', { size: 13, color: COLORS.muted });
+
+  sketch.arrow(915, 372, 915, 410, { stroke: COLORS.ink });
+  sketch.text(915, 454, 'both CUDA workloads progressed', { size: 18, weight: 700, color: COLORS.teal.stroke });
+  sketch.text(915, 487, 'delete 1g · 2g keeps running', { size: 17, color: COLORS.muted });
+  sketch.text(64, 588, 'PER-POD GI/CI LIFECYCLE · LIVE CUDA TEST', { size: 18, anchor: 'start', weight: 700, color: COLORS.orange.stroke });
+  sketch.save(join(output, 'cover.svg'));
+}
+
+console.log(`Wrote dynamic MIG cover to ${output}`);
diff --git a/vercel.json b/vercel.json
index 5b4c9b7eb..ca297af24 100644
--- a/vercel.json
+++ b/vercel.json
@@ -341,6 +341,11 @@
       "destination": "https://blog.kubesimplify.com/docker-networking-demystified",
       "permanent": true
     },
+    {
+      "source": "/blog/dynamic-mig-in-kubernetes-with-hami",
+      "destination": "https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami",
+      "permanent": true
+    },
     {
       "source": "/blog/embed-http-servers-in-wasm-with-rust-and-csharp",
       "destination": "https://blog.kubesimplify.com/embed-http-servers-in-wasm-with-rust-and-csharp",
@@ -791,6 +796,11 @@
       "destination": "https://blog.kubesimplify.com/navigating-through-cncf-landscape",
       "permanent": true
     },
+    {
+      "source": "/blog/nemotron-3-5-lightning-on-dgx-spark",
+      "destination": "https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark",
+      "permanent": true
+    },
     {
       "source": "/blog/nemotron3-on-dgx-spark",
       "destination": "https://blog.kubesimplify.com/nemotron3-on-dgx-spark",
@@ -1648,6 +1658,17 @@
         }
       ]
     },
+    {
+      "source": "/dynamic-mig-in-kubernetes-with-hami",
+      "destination": "https://blog.kubesimplify.com/dynamic-mig-in-kubernetes-with-hami",
+      "permanent": true,
+      "has": [
+        {
+          "type": "host",
+          "value": "kubesimplify.com"
+        }
+      ]
+    },
     {
       "source": "/embed-http-servers-in-wasm-with-rust-and-csharp",
       "destination": "https://blog.kubesimplify.com/embed-http-servers-in-wasm-with-rust-and-csharp",
@@ -2638,6 +2659,17 @@
         }
       ]
     },
+    {
+      "source": "/nemotron-3-5-lightning-on-dgx-spark",
+      "destination": "https://blog.kubesimplify.com/nemotron-3-5-lightning-on-dgx-spark",
+      "permanent": true,
+      "has": [
+        {
+          "type": "host",
+          "value": "kubesimplify.com"
+        }
+      ]
+    },
     {
       "source": "/nemotron3-on-dgx-spark",
       "destination": "https://blog.kubesimplify.com/nemotron3-on-dgx-spark",