Add GPU memory profiling on AKS blog post

[Brian Benz (bbenz)]

Summary

• add a blog post explaining how GPU memory profiles connect allocation pressure to application function call paths
• show how to interpret flame graphs and use profiling to validate reliability, capacity, and cost improvements
• add Brian Benz to the blog author registry
• store the two referenced flame graph screenshots with the post

Validation

• npm run build from website/ succeeds
• Markdown and YAML diagnostics report no errors
• both local PNG assets decode successfully

[Copilot]

Pull request overview

This PR adds a new AKS blog post focused on GPU memory profiling (connecting allocation pressure to function call paths via flame graphs) and registers a new author entry so the post can be attributed correctly on the site.

Changes:

• Added brian-benz to the blog author registry.
• Added a new blog post explaining GPU memory profiling on AKS, including how to interpret flame graphs and apply findings to reliability/capacity/cost.

Reviewed changes

Copilot reviewed 2 out of 4 changed files in this pull request and generated 3 comments.

File	Description
website/blog/authors.yml	Registers brian-benz so the new post’s authors front matter resolves correctly.
website/blog/2026-08-25-gpu-memory-profiling-on-aks/index.md	Adds the GPU memory profiling blog post content, including flame graph interpretation guidance and links to related docs/projects.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Brian Benz (bbenz)]

Hi there! This is my first submission, working through the review.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

website/blog/2026-08-25-gpu-memory-profiling-on-aks/index.md:81

• The post uses two different names for the same service: earlier it says "Azure Monitor managed service for Prometheus", but here it switches to "Azure Monitor managed Prometheus". Using one consistent product name in the post will reduce confusion.

Everything so far has focused on inference, but the same workflow applies to training. The [KubeRay GPU profiling demo for AKS with Anyscale](https://github.com/pauldotyu/awesome-aks/tree/main/2026-07-17-kubecon-gpuprofiling) spins up an AKS Automatic cluster with GPU Node Autoprovisioning, Inspektor Gadget, Pyroscope, Azure Monitor managed Prometheus, and Azure Managed Grafana.

website/blog/2026-08-25-gpu-memory-profiling-on-aks/index.md:20

• The blog-post guidelines expect a hero image immediately after the <!-- truncate --> marker (and typically named ./hero-image.png). Right now the first image appears later in the post, so the listing page will have no hero image and the post deviates from the established structure. Consider moving the existing flame graph image to directly follow <!-- truncate --> (or renaming to hero-image.png).

<!-- truncate -->

:::note Preview
This preview covers GPU **memory** allocations, not GPU **compute** utilization. Your existing GPU metrics tell you that something is going on; the profile gives you specific details on where it is happening.
:::

[Copilot]

Pull request overview

Copilot reviewed 2 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

website/blog/2026-08-25-gpu-memory-profiling-on-aks/index.md:46

• The post defines and later uses the term "self memory", but this earlier example calls it "self allocation". Using one term consistently helps readers map the example back to the definition.

The AKS documentation includes a real example from a vLLM inference workload. The trail leads to `GPUModelRunner._allocate_kv_cache_tensors`, which shows **55.1 GB of self allocation**. It's the function creating the tensors for the KV cache, the store vLLM uses so it doesn't have to recompute attention for tokens it's already seen.

website/blog/2026-08-25-gpu-memory-profiling-on-aks/index.md:81

• This sentence uses "Azure Monitor managed Prometheus", but earlier you refer to "Azure Monitor managed service for Prometheus". Consider using the same product name throughout the post to avoid confusion.

Everything so far has focused on inference, but the same workflow applies to training. The [KubeRay GPU profiling demo for AKS with Anyscale](https://github.com/pauldotyu/awesome-aks/tree/main/2026-07-17-kubecon-gpuprofiling) spins up an AKS Automatic cluster with GPU Node Autoprovisioning, Inspektor Gadget, Pyroscope, Azure Monitor managed Prometheus, and Azure Managed Grafana.