<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://rocm.blogs.amd.com/</id>
  <title>AMD ROCm Blogs</title>
  <updated>2026-08-12T17:33:51.563887+00:00</updated>
  <link href="https://rocm.blogs.amd.com/"/>
  <link href="https://rocm.blogs.amd.com/blog/atom.xml" rel="self"/>
  <generator uri="https://ablog.readthedocs.io/" version="0.11.12">ABlog</generator>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/odc-accelerate-training/README.html</id>
    <title>Using ODC to Accelerate AMD SFT Training</title>
    <updated>2026-08-12T00:00:00+00:00</updated>
    <author>
      <name>Gogineni Kailash</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;Large-scale training spends a surprising share of its wall-clock time waiting instead of computing. Under Fully Sharded Data Parallel (FSDP), every layer ends in a collective all-gather or reduce-scatter, and every collective is a barrier that the whole data-parallel group has to reach together. Feed that machinery variable-length supervised fine-tuning (SFT) data and the picture gets worse: some ranks draw long documents while others draw short ones, so the fast ranks sit idle waiting for the slow ones.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/odc-accelerate-training/README.html"/>
    <summary>Large-scale training spends a surprising share of its wall-clock time waiting instead of computing. Under Fully Sharded Data Parallel (FSDP), every layer ends in a collective all-gather or reduce-scatter, and every collective is a barrier that the whole data-parallel group has to reach together. Feed that machinery variable-length supervised fine-tuning (SFT) data and the picture gets worse: some ranks draw long documents while others draw short ones, so the fast ranks sit idle waiting for the slow ones.</summary>
    <category term="Optimization" label="Optimization"/>
    <published>2026-08-12T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/quark-diffusers/README.html</id>
    <title>Quark Support for HuggingFace Diffusers and SVDQuant</title>
    <updated>2026-08-06T00:00:00+00:00</updated>
    <author>
      <name>Ashish Sirasao</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;Diffusion models are heavy on memory and compute: a single text-to-image call runs a large transformer or UNet dozens of times. Quantization — storing weights (and sometimes activations) in low precision — is one of the most effective ways to cut both the memory footprint and the latency of these models.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/quark-diffusers/README.html"/>
    <summary>Diffusion models are heavy on memory and compute: a single text-to-image call runs a large transformer or UNet dozens of times. Quantization — storing weights (and sometimes activations) in low precision — is one of the most effective ways to cut both the memory footprint and the latency of these models.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="DiffusionModel" label="Diffusion Model"/>
    <category term="GenAI" label="GenAI"/>
    <category term="Performance" label="Performance"/>
    <published>2026-08-06T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/ecosystems-and-partners/rocm-aup-learning/README.html</id>
    <title>AUP Learning Cloud: Streamlining AI Education on AMD</title>
    <updated>2026-08-06T00:00:00+00:00</updated>
    <author>
      <name>Joshua Lu</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;AI education is becoming increasingly hands-on. Students are now expected to train models, build AI agents, experiment with large language models (LLMs), and develop applications accelerated by graphics processing units (GPUs), so courses depend as much on practical computing infrastructure as on learning materials. Yet standing up that infrastructure is usually the real bottleneck, and educators often spend more effort building it than teaching.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/ecosystems-and-partners/rocm-aup-learning/README.html"/>
    <summary>AI education is becoming increasingly hands-on. Students are now expected to train models, build AI agents, experiment with large language models (LLMs), and develop applications accelerated by graphics processing units (GPUs), so courses depend as much on practical computing infrastructure as on learning materials. Yet standing up that infrastructure is usually the real bottleneck, and educators often spend more effort building it than teaching.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="ComputerVision" label="Computer Vision"/>
    <category term="Kubernetes" label="Kubernetes"/>
    <category term="LLM" label="LLM"/>
    <category term="PyTorch" label="PyTorch"/>
    <category term="RecommendationSystems" label="Recommendation Systems"/>
    <published>2026-08-06T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/artificial-intelligence/vsa-sparse-attention/README.html</id>
    <title>VSA: Accelerating Video Diffusion Inference with Sparse Attention on AMD GPUs</title>
    <updated>2026-08-04T00:00:00+00:00</updated>
    <author>
      <name>Ashish Sirasao</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;Video generation powered by diffusion transformers has achieved remarkable quality, but the computational cost of attention mechanisms remains a critical bottleneck. With sequence lengths reaching tens of thousands of tokens in video generation tasks, the quadratic complexity of standard attention becomes prohibitively expensive.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/artificial-intelligence/vsa-sparse-attention/README.html"/>
    <summary>Video generation powered by diffusion transformers has achieved remarkable quality, but the computational cost of attention mechanisms remains a critical bottleneck. With sequence lengths reaching tens of thousands of tokens in video generation tasks, the quadratic complexity of standard attention becomes prohibitively expensive.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="DiffusionModel" label="Diffusion Model"/>
    <category term="GenAI" label="GenAI"/>
    <category term="Optimization" label="Optimization"/>
    <published>2026-08-04T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/artificial-intelligence/reverse-hipblaslt-tensilelite/README.html</id>
    <title>Reverse-Engineering hipBLASLt TensileLite Kernels: From Solution Name to a Tuning Config</title>
    <updated>2026-08-04T00:00:00+00:00</updated>
    <author>
      <name>Chunhung Wang</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;In a previous blog, &lt;a class="reference external" href="https://rocm.blogs.amd.com/artificial-intelligence/hipblaslt-tensilelite-tuning/README.html"&gt;Customizing Kernels with hipBLASLt TensileLite GEMM Tuning&lt;/a&gt;, we showed how TensileLite Tuning generates brand-new GEMM kernels by searching a parameter space and selecting the fastest valid candidate for a given problem size. The search space is defined entirely by the tuning configuration YAML you provide. Its &lt;code class="docutils literal notranslate"&gt;&lt;span class="pre"&gt;ForkParameters&lt;/span&gt;&lt;/code&gt; lists are expanded into a Cartesian product, and the tuning run can only ever return a kernel that is expressible as one combination within that product.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/artificial-intelligence/reverse-hipblaslt-tensilelite/README.html"/>
    <summary>In a previous blog, Customizing Kernels with hipBLASLt TensileLite GEMM Tuning, we showed how TensileLite Tuning generates brand-new GEMM kernels by searching a parameter space and selecting the fastest valid candidate for a given problem size. The search space is defined entirely by the tuning configuration YAML you provide. Its ForkParameters lists are expanded into a Cartesian product, and the tuning run can only ever return a kernel that is expressible as one combination within that product.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="LLM" label="LLM"/>
    <category term="Performance" label="Performance"/>
    <published>2026-08-04T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/ecosystems-and-partners/cdna5-helios/README.html</id>
    <title>Introducing AMD CDNA™ 5 and the AMD Helios™ Rackscale Solution</title>
    <updated>2026-08-04T00:00:00+00:00</updated>
    <author>
      <name>Abhishek Vashisth</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;AI infrastructure is being redefined at the scale of the entire rack. This blog will walk you through how the AMD CDNA™ 5 architecture, the AMD Instinct™ MI455X GPU, and the AMD Helios rackscale solution come together as a single open platform for large-scale AI training and inference. You will see how AMD balances compute, memory, and networking across 72 GPUs, how open standards keep the platform flexible, and how the AMD ROCm™ software stack ties it all into a complete, deployable system, from silicon to rack. By the end, you will understand what changes when AI infrastructure is designed as a unified rack rather than a collection of discrete GPU servers, and where AMD is taking it next.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/ecosystems-and-partners/cdna5-helios/README.html"/>
    <summary>AI infrastructure is being redefined at the scale of the entire rack. This blog will walk you through how the AMD CDNA™ 5 architecture, the AMD Instinct™ MI455X GPU, and the AMD Helios rackscale solution come together as a single open platform for large-scale AI training and inference. You will see how AMD balances compute, memory, and networking across 72 GPUs, how open standards keep the platform flexible, and how the AMD ROCm™ software stack ties it all into a complete, deployable system, from silicon to rack. By the end, you will understand what changes when AI infrastructure is designed as a unified rack rather than a collection of discrete GPU servers, and where AMD is taking it next.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="GenAI" label="GenAI"/>
    <category term="Hardware" label="Hardware"/>
    <category term="Performance" label="Performance"/>
    <published>2026-08-04T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/cvf/README.html</id>
    <title>Closing the GPU Cluster Validation Gap: A Kubernetes-Native Approach with CVF</title>
    <updated>2026-07-29T00:00:00+00:00</updated>
    <author>
      <name>Akhila Yeruva</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;As GPU clusters scale from dozens to thousands of accelerators, the assumption that every node is healthy at boot time becomes increasingly risky. Silent hardware degradation — a marginal XGMI link, a missing SR-IOV Virtual Function, or an under-performing RDMA rail — can turn a single node into a straggler that slows an entire distributed training job.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/cvf/README.html"/>
    <summary>As GPU clusters scale from dozens to thousands of accelerators, the assumption that every node is healthy at boot time becomes increasingly risky. Silent hardware degradation — a marginal XGMI link, a missing SR-IOV Virtual Function, or an under-performing RDMA rail — can turn a single node into a straggler that slows an entire distributed training job.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="Installation" label="Installation"/>
    <category term="Kubernetes" label="Kubernetes"/>
    <published>2026-07-29T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/gpu-operator-1.5.0/README.html</id>
    <title>AMD GPU Operator v1.5.0: DRA Support, Automated GPU Node Recovery, and Expanded Kubernetes Infrastructure Control</title>
    <updated>2026-07-28T00:00:00+00:00</updated>
    <author>
      <name>Akhila Yeruva</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;GPU Operator v1.5.0 introduces several major infrastructure capabilities for Kubernetes-based AMD GPU deployments, including support for Kubernetes Dynamic Resource Allocation (DRA), automated GPU node remediation workflows, and Node Problem Detector (NPD) integration.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/gpu-operator-1.5.0/README.html"/>
    <summary>GPU Operator v1.5.0 introduces several major infrastructure capabilities for Kubernetes-based AMD GPU deployments, including support for Kubernetes Dynamic Resource Allocation (DRA), automated GPU node remediation workflows, and Node Problem Detector (NPD) integration.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="Kubernetes" label="Kubernetes"/>
    <category term="Optimization" label="Optimization"/>
    <published>2026-07-28T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/gluon-attention-decode-mi450/README.html</id>
    <title>Attention Decode on AMD MI450 GPUs: A Gluon Kernel Optimization Guide</title>
    <updated>2026-07-27T00:00:00+00:00</updated>
    <author>
      <name>Lei Zhang antiagainst</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;Agentic AI applications are pushing LLM inference into a new regime. A request can now reach one million tokens from aggregated long prompts, tool calls, retrieval results, and multi-turn reasoning. During the text generation phase, each new token must attend to all previous tokens from the KV cache, so the kernel needs to repeatedly read past states from HBM. As a result, the performance bottleneck shifts from compute units to the memory system.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/gluon-attention-decode-mi450/README.html"/>
    <summary>Agentic AI applications are pushing LLM inference into a new regime. A request can now reach one million tokens from aggregated long prompts, tool calls, retrieval results, and multi-turn reasoning. During the text generation phase, each new token must attend to all previous tokens from the KV cache, so the kernel needs to repeatedly read past states from HBM. As a result, the performance bottleneck shifts from compute units to the memory system.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="Compiler" label="Compiler"/>
    <category term="Hardware" label="Hardware"/>
    <category term="LinearAlgebra" label="Linear Algebra"/>
    <category term="Optimization" label="Optimization"/>
    <category term="Performance" label="Performance"/>
    <category term="Profiling" label="Profiling"/>
    <published>2026-07-27T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/artificial-intelligence/instella-moe/README.html</id>
    <title>Introducing Instella-MoE: A State-of-the-Art Fully Open Mixture-of-Experts Language Model</title>
    <updated>2026-07-24T00:00:00+00:00</updated>
    <author>
      <name>Emad Barsoum</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;AMD is excited to introduce Instella-MoE, a state-of-the-art fully open Mixture-of-Experts (MoE) language model with 16 billion total parameters and 2.8 billion active parameters. Trained from scratch on AMD Instinct™ MI300X and MI325X GPUs with the AMD ROCm™ software stack, Instella-MoE combines a sparsely activated MoE design with architectural innovations such as Gated Multi-head Latent Attention (Gated MLA) and &lt;a class="reference external" href="https://rocm.blogs.amd.com/artificial-intelligence/farskip-collective-moe/README.html"&gt;FarSkip-Collective&lt;/a&gt; connectivity. Instella-MoE delivers competitive performance across a broad suite of benchmarks against both dense and MoE baselines (as shown in Figure 1) including models with comparable or larger active parameter counts, establishing it as one of the strongest fully open language models at its scale.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/artificial-intelligence/instella-moe/README.html"/>
    <summary>AMD is excited to introduce Instella-MoE, a state-of-the-art fully open Mixture-of-Experts (MoE) language model with 16 billion total parameters and 2.8 billion active parameters. Trained from scratch on AMD Instinct™ MI300X and MI325X GPUs with the AMD ROCm™ software stack, Instella-MoE combines a sparsely activated MoE design with architectural innovations such as Gated Multi-head Latent Attention (Gated MLA) and FarSkip-Collective connectivity. Instella-MoE delivers competitive performance across a broad suite of benchmarks against both dense and MoE baselines (as shown in Figure 1) including models with comparable or larger active parameter counts, establishing it as one of the strongest fully open language models at its scale.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <published>2026-07-24T00:00:00+00:00</published>
  </entry>
</feed>
