<?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-27T14:50:14.497735+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/ecosystems-and-partners/rocm-x-blog/README.html</id>
    <title>ROCm 10.0: A Decade of Open Compute, Built for the Age of Agentic AI</title>
    <updated>2026-08-27T00:00:00+00:00</updated>
    <author>
      <name>Evan Groenke</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;AMD shipped ROCm 1.0 in April 2016: an open-source GPU compute stack built around a C++ compiler and a GPU programming language called HIP, aimed at high-performance computing. A decade later, the same platform trains and serves frontier AI models across industries and enables nearly every compute application benefiting from GPUs.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/ecosystems-and-partners/rocm-x-blog/README.html"/>
    <summary>AMD shipped ROCm 1.0 in April 2016: an open-source GPU compute stack built around a C++ compiler and a GPU programming language called HIP, aimed at high-performance computing. A decade later, the same platform trains and serves frontier AI models across industries and enables nearly every compute application benefiting from GPUs.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="AMDSkills" label="AMD Skills"/>
    <category term="AgenticAI" label="Agentic AI"/>
    <category term="Compiler" label="Compiler"/>
    <category term="ComputerVision" label="Computer Vision"/>
    <category term="HPC" label="HPC"/>
    <category term="Hardware" label="Hardware"/>
    <category term="Hyperloom" label="Hyperloom"/>
    <category term="Installation" label="Installation"/>
    <category term="JAX" label="JAX"/>
    <category term="LLM" label="LLM"/>
    <category term="LinearAlgebra" label="Linear Algebra"/>
    <category term="Memory" label="Memory"/>
    <category term="OpenMP" label="OpenMP"/>
    <category term="Performance" label="Performance"/>
    <category term="Profiling" label="Profiling"/>
    <category term="PyTorch" label="PyTorch"/>
    <category term="ROCmCLI" label="ROCm CLI"/>
    <category term="ROCm.AI" label="ROCm.AI"/>
    <published>2026-08-27T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/ecosystems-and-partners/rai-lemonade-agents/README.html</id>
    <title>Enabling Physical AI Agents with Lemonade</title>
    <updated>2026-08-25T00:00:00+00:00</updated>
    <author>
      <name>Graham Schelle</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;In this blog we will demonstrate how to run local agents enabled by VLMs (Vision-Language Models) hosted by the Lemonade framework in the domain of robot control. These models allowed us to run an interactive robotic arm manipulation simulation entirely locally, showing the effectiveness of Lemonade for Physical AI.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/ecosystems-and-partners/rai-lemonade-agents/README.html"/>
    <summary>In this blog we will demonstrate how to run local agents enabled by VLMs (Vision-Language Models) hosted by the Lemonade framework in the domain of robot control. These models allowed us to run an interactive robotic arm manipulation simulation entirely locally, showing the effectiveness of Lemonade for Physical AI.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <published>2026-08-25T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/artificial-intelligence/long-context-serving/README.html</id>
    <title>Serving 64Mi-Token Contexts on One AMD Instinct™ MI355X Node</title>
    <updated>2026-08-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;Error parsing meta tag attribute “keywords”: No content.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/artificial-intelligence/long-context-serving/README.html"/>
    <summary>Error parsing meta tag attribute “keywords”: No content.</summary>
    <category term="LLM" label="LLM"/>
    <published>2026-08-24T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/di-glm-wideep/README.html</id>
    <title>DI Series: Scaling GLM-5.1-FP8 to 64 MI300X GPUs</title>
    <updated>2026-08-21T00:00:00+00:00</updated>
    <author>
      <name>Emad Barsoum</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;Serving a frontier Mixture-of-Experts (MoE) model well is a systems problem, and it gets harder the moment one node is not enough. GLM-5.1 is a good example: it is a large, sparse MoE that users want to run at &lt;strong&gt;long context&lt;/strong&gt;, and it ships a &lt;strong&gt;new attention family&lt;/strong&gt; that breaks assumptions older serving stacks quietly relied on. Fitting it on eight GPUs is only the start. The real question is how to keep it correct and fast as you spread it across several nodes.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/di-glm-wideep/README.html"/>
    <summary>Serving a frontier Mixture-of-Experts (MoE) model well is a systems problem, and it gets harder the moment one node is not enough. GLM-5.1 is a good example: it is a large, sparse MoE that users want to run at long context, and it ships a new attention family that breaks assumptions older serving stacks quietly relied on. Fitting it on eight GPUs is only the start. The real question is how to keep it correct and fast as you spread it across several nodes.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="LLM" label="LLM"/>
    <category term="Optimization" label="Optimization"/>
    <category term="Performance" label="Performance"/>
    <category term="Serving" label="Serving"/>
    <published>2026-08-21T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/artificial-intelligence/verl/README.html</id>
    <title>Scaling RL with verl on AMD Instinct MI355X: Async Walkthrough and Sync Benchmark</title>
    <updated>2026-08-18T00:00:00+00:00</updated>
    <author>
      <name>Vish Vadlamani</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;Reinforcement learning (RL) for large language models (LLMs) alternates between two phases: generation (rollout), where the current policy produces responses, and training, where those responses are used to update the policy. In verl, the key design choices are when these phases run relative to each other (synchronously or with overlap) and where they run (colocated on the same GPUs or on separate GPU pools). This blog first explains the differences between the two modes and when to use each.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/artificial-intelligence/verl/README.html"/>
    <summary>Reinforcement learning (RL) for large language models (LLMs) alternates between two phases: generation (rollout), where the current policy produces responses, and training, where those responses are used to update the policy. In verl, the key design choices are when these phases run relative to each other (synchronously or with overlap) and where they run (colocated on the same GPUs or on separate GPU pools). This blog first explains the differences between the two modes and when to use each.</summary>
    <category term="ReinforcementLearning" label="Reinforcement Learning"/>
    <published>2026-08-18T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/xgboost_deep_dive/README.html</id>
    <title>Exploring XGBoost: A Deep Dive</title>
    <updated>2026-08-18T00:00:00+00:00</updated>
    <author>
      <name>Phani Vaddadi</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;&lt;a class="reference external" href="https://xgboost.readthedocs.io/en/stable/"&gt;XGBoost&lt;/a&gt; (Extreme Gradient Boosting) is an open-source library that implements gradient-boosted decision trees, an ensemble method that builds an additive sequence of trees where each new tree is fit to the gradient of the loss left by the ones before it. It supports regression, classification, ranking, and survival objectives behind a single training loop, and is implemented as a high-performance C++ core with CPU and CUDA/HIP backends, exposed through Python, R, and JVM bindings. On large tabular datasets it is a standard production choice for both accuracy and training throughput. This blog opens the box on how it works, end to end.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/xgboost_deep_dive/README.html"/>
    <summary>XGBoost (Extreme Gradient Boosting) is an open-source library that implements gradient-boosted decision trees, an ensemble method that builds an additive sequence of trees where each new tree is fit to the gradient of the loss left by the ones before it. It supports regression, classification, ranking, and survival objectives behind a single training loop, and is implemented as a high-performance C++ core with CPU and CUDA/HIP backends, exposed through Python, R, and JVM bindings. On large tabular datasets it is a standard production choice for both accuracy and training throughput. This blog opens the box on how it works, end to end.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="C++" label="C++"/>
    <category term="LinearAlgebra" label="Linear Algebra"/>
    <category term="ScientificComputing" label="Scientific Computing"/>
    <published>2026-08-18T00:00:00+00:00</published>
  </entry>
  <entry>
    <id>https://rocm.blogs.amd.com/software-tools-optimization/mxfp4-fused-rotation/README.html</id>
    <title>Production-Ready MXFP4 Online Rotation with Fused Kernels on AMD Instinct™ MI355X</title>
    <updated>2026-08-13T00:00:00+00:00</updated>
    <author>
      <name>Ashish Sirasao</name>
    </author>
    <content type="html">&lt;p class="ablog-post-excerpt"&gt;&lt;p&gt;Serving large language models affordably increasingly depends on low-bit quantization, and MXFP4 is one of the most aggressive options — but the smaller models that need it most rely on &lt;em&gt;online rotation&lt;/em&gt; to stay accurate, and that rotation has historically carried a steep latency tax. In this post you will learn how a single fused Gluon (Triton) kernel on AMD Instinct™ MI355X (CDNA4) removes that tax: we walk through the kernel-fusion design, the RS=64 optimization, the GEAK + Hyperloom tuning workflow, and end-to-end measurements showing online-rotation overhead falling from a prohibitive +5–10% to just +0.3–0.8% on Dense models — with no measurable accuracy loss. By the end, you will understand how to make accuracy-preserving MXFP4 online rotation cheap enough to ship by default.&lt;/p&gt;
&lt;/p&gt;
</content>
    <link href="https://rocm.blogs.amd.com/software-tools-optimization/mxfp4-fused-rotation/README.html"/>
    <summary>Serving large language models affordably increasingly depends on low-bit quantization, and MXFP4 is one of the most aggressive options — but the smaller models that need it most rely on online rotation to stay accurate, and that rotation has historically carried a steep latency tax. In this post you will learn how a single fused Gluon (Triton) kernel on AMD Instinct™ MI355X (CDNA4) removes that tax: we walk through the kernel-fusion design, the RS=64 optimization, the GEAK + Hyperloom tuning workflow, and end-to-end measurements showing online-rotation overhead falling from a prohibitive +5–10% to just +0.3–0.8% on Dense models — with no measurable accuracy loss. By the end, you will understand how to make accuracy-preserving MXFP4 online rotation cheap enough to ship by default.</summary>
    <category term="AI/ML" label="AI/ML"/>
    <category term="LLM" label="LLM"/>
    <category term="Optimization" label="Optimization"/>
    <category term="PyTorch" label="PyTorch"/>
    <published>2026-08-13T00:00:00+00:00</published>
  </entry>
  <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>
</feed>
