# Digital Pathology AI Runs on NeuralMesh

**Author:** Liad Hermelin

**Published:** October 26, 2026

![Grayscale image of a microscope slide on a lab device, with data server racks and cables in the background.](https://cdn.sanity.io/images/ult5g8gw/production/ce6094e63063df90b90697d7336a0c1c9d4b2de3-1584x672.jpg)

## TL;DR

A complete digital pathology AI pipeline ran on NeuralMesh, measured at every stage, alone and under concurrent load.

- The four-hour clinical mix kept inference within about 2.5% of stand-alone speed, and every research-mix workload kept at least about 89% of its throughput.
- A 1,064-slide cohort went from raw slides to a trained classifier in 3.5 to 4.1 hours.
- No workload was slowed by storage.

A single pathology slide, once scanned, is a gigapixel image, and a cohort of them runs to terabytes. In a hospital running AI-assisted diagnostics on incoming slides, all of that data moves through one storage system. Scanners write new slides continuously. Inference reads each incoming slide tile by tile and writes back a heatmap marking suspicious regions. A pathologist pans and zooms across one slide while inference processes the next. In production all of it runs at once, and the question you have to answer is whether storage carries the whole load without one job slowing another.

We measured exactly that. The new white paper, Digital Pathology AI on NeuralMesh, records a complete digital pathology AI pipeline running on WEKA® NeuralMesh™ in AWS, with each stage measured alone and under concurrent load, as a hospital would run it and as a research lab would. The question was whether NeuralMesh supports digital pathology AI end to end, and the measured answer is yes. The pipeline spends most of its time in GPUs and CPUs, and in every mix, storage slowed no workload.

## What did the tests show?


| Result | What it means |
| --- | --- |
| Full clinical mix, four hours: inference within about 2.5% of stand-alone speed, median drift 0.05% | The hospital's entire workload runs at once on shared storage without slowing the clinical loop. |
| Research mix: every workload kept at least about 89% of stand-alone throughput | Extraction, training, ingest, and viewing coexist. The filesystem is never the contended resource. |
| Cohort to trained classifier: 3.5 to 4.1 h (1,064 slides) | A lab retrains a full cohort within an afternoon. |


Every step a hospital or research lab would run completed with measured headroom, alone and under contention. The rest of this post walks through what ran and what each result means.

## What did the test pipeline include?

Two public cohorts drove every test: 1,133 breast-cancer slides and 399 lymph-node slides, along with two pathology foundation models, Virchow2 and GigaPath. A whole-slide image is one scanned glass slide at microscope resolution, on the order of 100,000 by 100,000 pixels, stored compressed at roughly a gigabyte per slide. The pipeline has five stages.

1. Tissue detection finds the parts of a slide that contain tissue, since most of a slide is empty glass.
2. Tiling cuts those regions into small tiles.
3. Feature extraction runs a foundation model over the tiles and reduces each slide to a single embedding file.
4. Classifier training fits a compact diagnostic model on those embeddings.
5. Inference runs the whole chain on one slide and writes a heatmap image marking suspicious regions.

Every measurement comes from one client machine, a single GPU server, working against an 8-node NeuralMesh cluster in a realistic production configuration. That's deliberate. The workstation or inference node is the unit a deployment scales, so every claim in the paper is a per-client claim.

## Can one storage system carry a hospital's whole workload?

Yes. In a four-hour run, inference, scanner ingest, a heatmap viewer, and a slide viewer shared one storage system, and median inference latency stayed within about 2.5% of running alone. The paper measures each piece on its own first, then runs all of it at once.

On its own, the inference chain takes about 36 seconds per slide at the median, and most of that is the foundation model running on the GPU. Storage accounts for roughly 5% of it, mostly the heatmap write, and reading slides cold, with nothing cached, made no measurable difference to the median. A synthetic scanner delivering a new slide every minute never built a queue, so one GPU keeps pace with a scanner. Once inference writes a result, other software can open it within a millisecond, which means a finished result is on screen the moment inference ends. And with scanners writing at full rate, the small random reads of a pathologist panning and zooming stayed at about 2 milliseconds for the slowest one in a hundred, so viewing continues while ingest runs.

Then everything ran together, first for 30 minutes and then for four hours, and the four-hour median drifted 0.05% from the 30-minute one. In this test, the full hospital workload ran at once on shared storage without slowing the clinical loop.


![The hospital workflow: each incoming slide runs the inference chain while ingest and viewing continue on the same storage.](https://cdn.sanity.io/images/ult5g8gw/production/ce68d69f9c4ad590717b10dfef5273a4ceefa28d-2880x1053.png)


## How fast can a lab go from raw slides to a trained classifier?

In this test, under 4.2 hours for a 1,064-slide cohort. A research lab's sequence is a one-time preparation pass per cohort (transfer, catalog, tissue detection, feature extraction), then weeks of classifier training against the embeddings. Preparation is where the heavy reading and writing happens. Cataloging opened and indexed the full cohort in 1 to 2 seconds. Feature extraction ran with the GPUs near full utilization for both models, with the storage keeping the extractors fed. End to end, a lab goes from raw slides to a trained classifier within an afternoon.

On a shared cluster these jobs overlap, so ingest, extraction, training, and a viewer ran in every combination, ending in a four-hour endurance window. Extraction showed no slowdown in any mix, ingest never degraded, and no workload gave up more than about 11% of its stand-alone throughput. The filesystem was never the contended resource.

Real embedding corpora fit in memory, so the paper also replays the training read pattern against a synthetic archive larger than every cache in the system combined. The archive-scale figures in the paper come from direct measurement, not extrapolation.

## Want the full numbers?

Storage shouldn't be the reason your pathology AI waits, and in these tests it never was. The white paper has the numbers behind each result above, plus the measurements this post leaves out. [Read the full white paper](/resource/digital-pathology-ai-on-neuralmesh). And if you're planning a digital pathology AI deployment, [talk to our team](/contactPage/contact) about getting NeuralMesh set up for your environment.