{"slug": "accelerating-monai-digital-pathology-pipelines-on-amd-instincttm-gpus-with", "title": "Accelerating MONAI Digital-Pathology Pipelines on AMD Instinct™ GPUs with hipCIM", "summary": "AMD reported that hipCIM 26.06.00, its GPU-accelerated whole-slide image I/O library, delivers roughly 10× faster GPU patch reading than OpenSlide (9,661–9,930 patches/s versus ~943–951 patches/s) on the canonical MONAI digital-pathology workload running on an AMD Instinct MI355X with ROCm 10.0 and AMD Life Science 26.08. The MONAI data loader ran about 4.2× faster than MONAI's stock OpenSlide reader on the CMU-1.svs slide (roughly 2,750 versus ~660 patches/s with eight workers), and end-to-end inference across three whole-slide images was 1.6–3.8× faster at ~0.13 s/batch versus 0.21–0.51 s/batch. hipCIM's rocJPEG decode matched the CPU libjpeg-turbo path to a maximum absolute difference of 1 on 8-bit values, and the gains come from the reader path that still returns patches to the host, since MONAI's GPU-resident path is not yet wired up.", "body_md": "# Accelerating MONAI Digital-Pathology Pipelines on AMD Instinct™ GPUs with hipCIM[#](#accelerating-monai-digital-pathology-pipelines-on-amd-instinct-gpus-with-hipcim)\n\nA digital-pathology model is only as fast as the pipeline that feeds it. That’s simple to overlook when the conversation turns to network architectures and FLOPs, but on real whole-slide workloads the truth is stubborn: a great deal of the wall-clock time goes to reading gigapixel slides off disk and decoding them into the small tiles the model consumes. Speed up the model and leave the reader untouched, and the pipeline barely moves.\n\nA companion post introduces hipCIM, AMD’s GPU-accelerated whole-slide image (WSI)\nI/O library. This post answers the natural follow-on question: what happens when you drop hipCIM into a\nreal Medical Open Network for AI (MONAI) pipeline? With **AMD Life Science 26.08**, which supports **ROCm™ 10.0**, MONAI’s `WSIReader` can use\nhipCIM through its familiar `from cucim import CuImage` API. The gains measured here come from that\nreader path, which still returns patches to the host; MONAI’s GPU-resident path is not yet wired up. On the canonical MONAI digital-pathology workload, running on AMD Instinct™\nMI355X with ROCm 10.0, hipCIM GPU patch reading reaches **~10× over OpenSlide**, the MONAI data\nloader runs **~4.2× faster** than MONAI’s stock OpenSlide reader on the CMU-1.svs slide (from Carnegie Mellon University), and end-to-end inference across three\nwhole-slide images is **1.6–3.8× faster**.\n\n## Why the Reader Decides the Pace[#](#why-the-reader-decides-the-pace)\n\nConsider the anatomy of the workload. A whole-slide image is a pyramid of small JPEG-compressed tiles, each a few hundred pixels on a side; a single slide can be tens of thousands of pixels across. A pathology model samples these tiles by the thousand. The component that turns “a slide on disk” into “tensors on the accelerator” does an enormous amount of repetitive work, and it sits directly on the critical path. If it stalls, the GPU idles.\n\nMONAI’s `WSIReader` already supports a `cuCIM` backend, and on AMD ROCm that backend is hipCIM,\nexposing the identical `from cucim import CuImage` API. The question is a\nconcrete one: measured on real MI355X hardware, exactly how much does a MONAI pipeline gain when its\nreader is hipCIM 26.06.00 rather than the standard CPU reader?\n\n## At a Glance[#](#at-a-glance)\n\n| Metric | hipCIM 26.06.00 | Vanilla MONAI (OpenSlide CPU) | Speedup | System under test | \n|---|---|---|---|---|\n| WSI GPU patch read (CMU-1/2/3.svs) | 9,661–9,930 patches/s | ~943–951 patches/s | **~10×** | MI355X with ROCm 10.0 | \n| MONAI `PatchWSIDataset` loader, CMU-1.svs (eight workers) | ~2,750 patches/s | ~660 patches/s | **~4.2×** | MI355X with ROCm 10.0 | \n| End-to-end inference (pathology, `num_workers=8` ) | ~0.13 s/batch (stable) | 0.21–0.51 s/batch | **1.6–3.8×** (3 slides) | MI355X with ROCm 10.0 | \n| 3-D NIfTI and DICOM volume reading | Supported (GPU-resident via `cumed` ) | Not previously available | New capability | Capability, not a timed benchmark | \n\n*Table 1. Summary of the results in this post. Each row is detailed in its own section below.*\n\nTable 1 summarizes the results. The GPU output is faithful to the CPU reference, too: on the Aperio SVS slides benchmarked here, hipCIM’s rocJPEG decode agrees with the CPU libjpeg-turbo path to a maximum absolute difference of 1 on 8-bit values, the kind of off-by-one that rounding, not error, produces. The result is faster and correct.\n\n## What Was Benchmarked[#](#what-was-benchmarked)\n\nThe system under test was an AMD Instinct™ MI355X (gfx950), bare-metal, with\nROCm 10.0, Python 3.12, and a ROCm build of PyTorch. The hipCIM and MONAI wheels came from AMD’s\ninternal ROCm CI, which is what produces the released artifacts: the published equivalents are\n[`amd-hipcim`](https://pypi.amd.com/rocm-10.0.0/simple/amd-hipcim/) 26.06.00 and\n[`amd-monai`](https://pypi.amd.com/rocm-10.0.0/simple/amd-monai/) 1.6.0 on the AMD ROCm package\nindex. The MONAI side is AMD’s fork of upstream MONAI,\n[AMD-Ecosystem/MONAI](https://github.com/AMD-Ecosystem/MONAI), which carries the AMD-specific\nchanges and feeds them back to [Project-MONAI/MONAI](https://github.com/Project-MONAI/MONAI) as\nupstream pull requests. Patch-read, loader,\nand end-to-end inference throughputs were all measured on that system. The loader comparison was\nadditionally re-measured on AMD Instinct™ MI350X (gfx950) with ROCm 10.0.\n\nThe workload was chosen deliberately. The `pathology_tumor_detection` bundle from the MONAI Model Zoo\n(metastasis detection on Camelyon16 H&E, or hematoxylin and eosin, stained whole-slide images) is the one Model Zoo bundle that reads\nsource WSIs through `WSIReader(backend=\"cuCIM\")` today, via `monai.data.PatchWSIDataset` and\n`MaskedPatchWSIDataset`. That makes it the most direct, representative consumer of hipCIM available.\nIts network is the bundle’s TorchVision ResNet-18 fully-convolutional classifier, run for inference\nwith the pretrained `model.pt`, and its access pattern (224×224 patches at pyramid level 0, read as\n768×768 regions split 3×3) is a loop of many small GPU patch reads typical of WSI training and\ninference.\n\nTo keep the comparison clean, only one thing changes between variants: the installed hipCIM wheel. A\nsingle Docker image per node means MONAI and PyTorch are byte-identical across every comparison, so\nany measured difference is attributable to the reader alone. The WSI micro-benchmark uses Aperio\nCMU-1, CMU-2, and CMU-3 `.svs` files (CC0); the loader and end-to-end runs use Camelyon16 tiled-TIFF;\nthe 3-D coverage test uses MSD spleen CT volumes.\n\n## Benchmark Results[#](#benchmark-results)\n\n### Patch Read Throughput and Where the Win Originates[#](#patch-read-throughput-and-where-the-win-originates)\n\nEverything downstream traces back to how fast hipCIM can read patches. The GPU path is roughly an order of magnitude ahead of OpenSlide. Table 2 shows the per-slide figures on MI355X with ROCm 10.0:\n\n| Slide | hipCIM-GPU (patches/s) | OpenSlide (patches/s) | GPU vs OpenSlide (ratio of patches/s) | \n|---|---|---|---|\n| CMU-1.svs | 9,930 | 943 | **10.5×** | \n| CMU-2.svs | 9,661 | 951 | **10.2×** | \n| CMU-3.svs | 9,751 | 951 | **10.3×** | \n| **Average** | **9,781** | **~948** | **~10.3×** | \n\n*Table 2. Patch-read throughput in patches per second, all columns measured on MI355X with ROCm 10.0.\nThe MI355X OpenSlide baseline is ~950 patches/s on this node (bare-metal, ROCm 10.0 manylinux\ncontainer); the GPU versus OpenSlide ratio is therefore ~10×, consistent with the headline. The\ncompanion hipCIM post covers CPU path throughput (7–11× over OpenSlide on MI355X with ROCm 10.0).*\n\nThere is an important enabler in this table. GPU reads of JPEG-compressed Aperio SVS slides are new in hipCIM 26.06.00, which is what makes the GPU path functional, correct, and fast on real slides. That capability is the foundation everything else in this blog stands on.\n\nOne clarification before the tables that follow, because it explains an apparent oddity. The SVS GPU\nread path is new in 26.06.00. The MONAI loader and end-to-end runs below use the Camelyon16\n**tiled-TIFF** WSIs, a format both releases read, which is why 25.10.00 still produces numbers there.\nThose loader and end-to-end numbers come out equal between the two releases for a different reason\nentirely: both are bottlenecked on MONAI’s host-copy path, as explained next, rather than reflecting\nequivalent GPU capability.\n\n### From Raw Reads to the MONAI Loader[#](#from-raw-reads-to-the-monai-loader)\n\nRaw read throughput is the ceiling. What a user feels is the loader. Table 3 reports the bundle’s\nexact `PatchWSIDataset` pipeline at eight workers:\n\n| Variant (reader) | MI355X with ROCm 10.0 (patches/s) | MI350X with ROCm 10.0 (patches/s) | \n|---|---|---|\n| hipCIM 26.06.00 (cuCIM backend) | ~2,750 | ~3,103 | \n| Vanilla (OpenSlide) | ~660 | ~671 | \n| **hipCIM vs OpenSlide** (ratio) | **~4.2×** | **~4.6×** | \n\n*Table 3. MONAI `PatchWSIDataset` loader throughput. Both columns use the Aperio `CMU-1.svs` slide, 576 patches at level 0, `num_workers=8`, median of five\nfresh-process repeats. The ratio depends on the slide: OpenSlide reads tiled-TIFF considerably faster\nthan Aperio SVS, so quoting a loader ratio without naming the slide is misleading.*\n\nThere is a nuance worth surfacing. MONAI’s stock `CuCIMWSIReader` requests host output and copies each\npatch back to the CPU, which means it does not yet exercise hipCIM’s GPU-resident path. That is why\nthe 26.06.00 and 25.10.00 loader numbers are essentially equal here: both are bottlenecked on the same\nhost copy. Even so, hipCIM’s reader is ~4.2× faster than MONAI’s stock OpenSlide reader. Wiring MONAI’s\nreader to hipCIM’s GPU-resident path so tiles never round-trip to the host is the next opportunity, and\nit stacks on top of the gain shown here.\n\n### End-to-End Inference[#](#end-to-end-inference)\n\nAll of this matters only if it moves the number a practitioner cares about: total wall time. It does,\nand the size of the win depends on the slide. Across three Camelyon16 slides on MI355X with ROCm 10.0, at\n`num_workers=8`, the `pathology_tumor_detection` bundle runs **1.6–3.8× faster** with hipCIM than with\nthe OpenSlide reader, as Table 4 shows:\n\n| Slide | hipCIM 26.06.00 (s) | Vanilla OpenSlide (s) | hipCIM vs vanilla (ratio) | \n|---|---|---|---|\n| test_001 (715 batches) | 96 | 153 | **1.6×** | \n| test_004 (986 batches) | 128 | 225 | **1.8×** | \n| test_002 (893 batches) | 122 | 459 | **3.8×** | \n\n*Table 4. End-to-end `pathology_tumor_detection` inference, median of three repeats per slide, on\nMI355X with ROCm 10.0. Rows are ordered by speedup, not by slide number.*\n\nThis post quotes the range rather than a single slide on purpose. Normalized per batch, hipCIM’s read cost is\neffectively constant, at ~0.13 s/batch on every slide, while the OpenSlide baseline swings from 0.21 to\n0.51 s/batch. The ratio moves because the *baseline* moves, not hipCIM: the advantage is a\npipeline-throughput effect, hipCIM scaling cleanly across the eight DataLoader workers where OpenSlide\ndoes not (on the widest slide, OpenSlide is slower at eight workers than single-threaded). A\nsingle `read_region` call, single-threaded, isn’t where this win lives. It lives in the parallel loader.\nThese figures are for inference. Training is far more compute-bound, so data loading is a smaller\nslice of the total and the reader matters correspondingly less there. Those distinctions matter, so\nthey sit alongside the headline rather than behind it.\n\n### 3-D Volumes Through the Same API[#](#d-volumes-through-the-same-api)\n\n|  | hipCIM 26.06.00 (`cumed` ) | hipCIM 25.10.00 | nibabel (reference) | \n|---|---|---|---|\n| Open + read `spleen_*.nii.gz` | Yes, 1.0–1.7 s, GPU-resident | No plugin | 0.7–1.0 s | \n\n*Table 5. 3-D volume reading through the `cumed` reader, compared with the previous hipCIM release\nand with nibabel as a CPU reference.*\n\nBeyond speed, 26.06.00 adds a new capability. Its `cumed` reader opens NIfTI and uncompressed DICOM\nthrough the same `cucim.CuImage` API used for whole-slide images. For MONAI, this opens a path to\nroute 3-D CT and MRI pipelines through hipCIM for GPU-resident volume loading, so a single I/O layer\ncan eventually serve both the 2-D digital-pathology and 3-D radiology sides of a workflow. (Compressed\nDICOM JPEG and JP2K require a build with `-DCUMED_DICOM_COMPRESSED=ON`.)\n\nThis breadth is a differentiator: one GPU-resident I/O path, reached through one API, spanning whole-slide pathology and volumetric radiology on AMD Instinct™.\n\n## How to Adopt hipCIM in Your MONAI Pipeline[#](#how-to-adopt-hipcim-in-your-monai-pipeline)\n\n**Install the stack.** hipCIM and MONAI on ROCm are installed from the AMD ROCm package index. The\ncommands are maintained in the official documentation rather than reproduced here, so they stay\ncurrent with the release: see the\n[MONAI on ROCm installation guide](https://rocm.docs.amd.com/projects/monai/en/docs-26.08/install/installation.html),\nwhich covers PyTorch, hipCIM and MONAI together, and the\n[hipCIM documentation](https://rocm.docs.amd.com/projects/hipCIM/en/docs-26.08/). Both are part of\n[AMD Life Science](https://rocm.docs.amd.com/projects/lifescience/en/latest/); runnable examples live\nin [AMD-Ecosystem/lifescience-examples](https://github.com/AMD-Ecosystem/lifescience-examples).\n\n**Point MONAI at hipCIM.** This is the whole change. MONAI’s `WSIReader` already supports a `cuCIM`\nbackend, and on ROCm that backend is hipCIM, so no model code changes are required:\n\n``` python\nfrom monai.data import PatchWSIDataset, WSIReader\n\n# On ROCm, backend=\"cuCIM\" resolves to hipCIM\nreader = WSIReader(backend=\"cuCIM\")\n\ndataset = PatchWSIDataset(\n    data=[{\"image\": \"CMU-1.svs\", \"location\": [0, 0], \"size\": [224, 224]}],\n    patch_size=224,\n    reader=reader,\n)\n```\n\nIn a bundle, the same swap is a configuration override: set the reader on the dataset to\n`backend=\"cuCIM\"` and leave the rest of `configs/inference.json` untouched. That is the path the\nnumbers above were measured on.\n\n**Not available yet.** Two further steps are on the roadmap rather than in your hands today.\nHaving MONAI’s reader request `device=\"cuda\"` so decoded tiles stay GPU-resident is not yet wired\nthrough `CuCIMWSIReader`, which is why the loader figures here come from the host-copy path. Routing\n3-D NIfTI and DICOM loading through the `cumed` reader is new in 26.06.00 and not yet integrated into\nMONAI’s radiology pipelines.\n\n## Summary[#](#summary)\n\nThis blog showed what happens when hipCIM replaces the stock reader in a MONAI\ndigital-pathology pipeline: the bottleneck moves off the reader. On AMD Instinct™ MI355X with\nROCm 10.0, hipCIM reads whole-slide patches about 10 times faster than OpenSlide, the MONAI data\nloader runs about 4.2 times faster than the stock OpenSlide reader, and end-to-end inference over\nthree Camelyon16 slides is 1.6 to 3.8 times faster, with hipCIM holding a stable 0.13 seconds per\nbatch. It also showed where the win doesn’t come from, a single `read_region` call, and why a\ncompute-bound workload has less to gain from a faster reader.\n\nThe practical takeaway: because MONAI’s `WSIReader` already speaks the\n`cuCIM` backend API, adopting hipCIM needs no model changes and no rewrite of your transforms. Point\nthe reader at the `cuCIM` backend and your existing pipeline runs faster on the same code.\n\nThis is one layer of the AMD Life Science medical-imaging stack. Companion posts cover the rest of it:\nthe hipCIM library underneath, validated Model Zoo inference above it, and\ninteractive annotation on top. Work is continuing on the 3-D `cumed` radiology path and\nGPU-resident loading. Follow the AMD ROCm Blogs for the rest of the series.\n\n## Additional Resources[#](#additional-resources)\n\n- [Project MONAI](https://github.com/Project-MONAI/MONAI) :`WSIReader` ,`PatchWSIDataset` , and the[`pathology_tumor_detection` bundle](https://github.com/Project-MONAI/model-zoo/tree/dev/models/pathology_tumor_detection) .\n- [OpenSlide test data (Carnegie Mellon University)](https://openslide.cs.cmu.edu/download/openslide-testdata/) : CMU-1, CMU-2, and CMU-3 slides, licensed CC0-1.0.\n- [hipCIM on GitHub](https://github.com/AMD-Ecosystem/hipCIM)\n- [MONAI on GitHub](https://github.com/AMD-Ecosystem/MONAI)\n- [AMD ROCm documentation](https://rocm.docs.amd.com/)\n- [AMD ROCm Blogs](https://rocm.blogs.amd.com/)\n\n## System Configuration[#](#system-configuration)\n\nAll performance figures in this post were measured on the configuration below, on **10 September\n2026**.\n\n| Component | Configuration | \n|---|---|\n| GPU | AMD Instinct™ MI355X (gfx950), bare metal | \n| Host CPU | AMD Ryzen™ Threadripper™ PRO 7955WX, 32 threads pinned | \n| ROCm | 10.0 | \n| PyTorch | 2.13.0+rocm10.0.0 (HIP runtime 7.15.26333) | \n| torchvision / torchaudio | 0.28.0+rocm10.0.0 / 2.11.0.2+rocm10.0.0 | \n| MONAI | 1.6.0 | \n| hipCIM | 26.06.00 | \n| Python | 3.12 | \n| Package index | AMD ROCm `whl-next` index | \n\nThe amdgpu driver version and the container image digest were not recorded for this run, so they\nare omitted rather than inferred. Each variant runs in an isolated container with GPU passthrough\n(`--device=/dev/kfd --device=/dev/dri`, render group, `--shm-size=16g`); GPU JPEG decode requires\nbare-metal Instinct with a working DRM render node.\n\n**Workloads.** The end-to-end figures use the `pathology_tumor_detection` bundle over three\nCamelyon16 slides at `num_workers=8` and `batch_size=400`, three repeats per slide, median reported.\nThe slides are `test_001`, `test_002` and `test_004` from the Camelyon16 testing set, obtained from\nthe GigaDB mirror and size-verified against the remote copies. They are a sample of that set rather\nthan the whole of it, which is why the numbering is not contiguous. The loader comparison was additionally re-measured on\nAMD Instinct™ MI350X (gfx950) with ROCm 10.0, using the Aperio `CMU-1.svs` slide, 576 patches at\nlevel 0 and the median of five fresh-process repeats. The hipCIM baseline for comparison is\n`amd-hipcim==25.10.0` from the AMD ROCm package index.\n\n## Disclaimers[#](#disclaimers)\n\nPerformance may vary by hardware configuration, workload, and software version.\n\n## Third-Party Content Disclaimer[#](#third-party-content-disclaimer)\n\nThird-party content is licensed to you directly by the third party that owns the content and is not licensed to you by AMD. ALL LINKED THIRD-PARTY CONTENT IS PROVIDED “AS IS” WITHOUT A WARRANTY OF ANY KIND. USE OF SUCH THIRD-PARTY CONTENT IS DONE AT YOUR SOLE DISCRETION AND UNDER NO CIRCUMSTANCES WILL AMD BE LIABLE TO YOU FOR ANY THIRD-PARTY CONTENT. YOU ASSUME ALL RISK AND ARE SOLELY RESPONSIBLE FOR ANY DAMAGES THAT MAY ARISE FROM YOUR USE OF THIRD-PARTY CONTENT.\n\nThe information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions, and typographical errors. The information contained herein is subject to change and may be rendered inaccurate for many reasons, including but not limited to product and roadmap changes, component and motherboard version changes, new model and/or product releases, product differences between differing manufacturers, software changes, BIOS flashes, firmware upgrades, or the like. Any computer system has risks of security vulnerabilities that cannot be completely prevented or mitigated. AMD assumes no obligation to update or otherwise correct or revise this information. However, AMD reserves the right to revise this information and to make changes from time to time to the content hereof without obligation of AMD to notify any person of such revisions or changes. THIS INFORMATION IS PROVIDED ‘AS IS.” AMD MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES, ERRORS, OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION. AMD SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AMD BE LIABLE TO ANY PERSON FOR ANY RELIANCE, DIRECT, INDIRECT, SPECIAL, OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF AMD IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. AMD, the AMD Arrow logo, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies. © 2026 Advanced Micro Devices, Inc. All rights reserved", "url": "https://wpnews.pro/news/accelerating-monai-digital-pathology-pipelines-on-amd-instincttm-gpus-with", "canonical_source": "https://rocm.blogs.amd.com/artificial-intelligence/monai-hipcim-2608/README.html", "published_at": "2026-10-26 00:00:00+00:00", "updated_at": "2026-10-26 16:15:58.922144+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-infrastructure", "ai-tools", "computer-vision"], "entities": ["AMD", "hipCIM", "MONAI", "AMD Instinct MI355X", "ROCm 10.0", "OpenSlide", "AMD Life Science 26.08", "cuCIM"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/accelerating-monai-digital-pathology-pipelines-on-amd-instincttm-gpus-with", "markdown": "https://wpnews.pro/news/accelerating-monai-digital-pathology-pipelines-on-amd-instincttm-gpus-with.md", "text": "https://wpnews.pro/news/accelerating-monai-digital-pathology-pipelines-on-amd-instincttm-gpus-with.txt", "jsonld": "https://wpnews.pro/news/accelerating-monai-digital-pathology-pipelines-on-amd-instincttm-gpus-with.jsonld"}}