AI server for medical device makers: reproducible SaMD training under the MDR and AI Act

What a medical device manufacturer needs from an AI server

An AI server for a medical device manufacturer is the environment in which the company trains, verifies and documents the AI in its device, and rebuilds a model version the same way months later when a notified body asks how it came about. In practice that means a training server with four NVIDIA RTX PRO 6000 Blackwell Server Edition cards, a separate validation server with two cards that holds the locked test data, and a software stack pinned from the driver branch to the container image. Manufacturers who train large 3D models add or choose a node with four NVIDIA H200 NVL cards.

We wrote this for the head of R&D or regulatory affairs at a manufacturer of software as a medical device (SaMD) or of devices with AI inside, and for the IT team that runs the machines. Hospitals that use imaging models are covered by our guide to a medical imaging AI server, which sizes GPU memory for MONAI and 3D segmentation. This page stays on the manufacturer's side: how a model was built and how to show it.

When the AI in a device is high-risk under the AI Act

MDCG 2025-6, the FAQ on the interplay between the MDR, the IVDR and the AI Act published by the Commission on 19 June 2025, sets two conditions under which AI in a medical device (MDAI) is a high-risk AI system under Article 6(1) of the AI Act. One of them is that the device "is subject to a third-party conformity assessment by a notified body". Its table therefore marks non-sterile, non-measuring and non-reusable surgical Class I devices as neither assessed by a notified body nor high-risk, while sterile, measuring or reusable surgical Class I devices are both. The MDR and the IVDR remain in Section A of Annex I of the AI Act after the Digital Omnibus, as the Commission's AI Act Service Desk lists them. Under the AI Act as amended by Regulation (EU) 2026/1744, the Digital Omnibus on AI, these rules apply to Annex I products from 2 August 2028, as Article 113 of the AI Act in its amended form states and our article on the EU AI Act explains.

The FAQ then lists what the AI Act adds to the MDR. Several points land on the infrastructure:

MDCG 2025-6 / AIB 2025-1, FAQ on the interplay between the MDR, IVDR and AI Act (June 2025), questions 6, 8, 9, 12, 21, 29 and 30, read 24 October 2026; the last column is our reading of what this means for the GPU environment.

The FAQ also says that changes "pre-determined by the manufacturer and assessed" at the initial conformity assessment do not constitute a substantial modification. A planned retraining is only predictable when the environment that produced the first model still exists, which is the reason for the pinned stack below. The MDR itself already asks manufacturers to set out "minimum requirements concerning hardware, IT networks characteristics and IT security measures" needed to run the software as intended (Annex I, section 17.4, as quoted in MDCG 2019-16 rev. 1). That requirement concerns the device in use, so by our reading the hardware you name for it is also the hardware to verify on.

This is general information, not regulatory or legal advice. Your regulatory affairs team, your notified body and your legal counsel confirm what applies to your device.

Reproducibility starts below the framework

PyTorch's notes on reproducibility, version 2.14, are direct about the limits. They state that completely reproducible results are not assured across PyTorch releases, individual commits or different platforms, and that results "may not be reproducible between CPU and GPU executions, even when using identical seeds". Inside one platform, torch.use_deterministic_algorithms(True) makes PyTorch use deterministic algorithms and raises an error for operations that are known to be nondeterministic and have no deterministic alternative. Turning off cuDNN benchmarking makes the algorithm choice deterministic, "possibly at the cost of reduced performance", and data loader workers need a seeded generator.

For the server, "platform" means every layer below the training script. We record each of them for a validated environment:

PyTorch 2.14 reproducibility notes and NVIDIA framework containers support matrix (26.09: Ubuntu 24.04, CUDA 13.4.1, PyTorch 2.14.0a0), read 24 October 2026; driver lifecycle as in our guide to NVIDIA driver branches; the selection of layers is our recommendation.

The driver branch deserves a decision of its own. NVIDIA's table of 9 September 2026 lists R580 as a long-term support branch supported to June 2028 and R595 as a production branch supported to March 2027, as our guide to NVIDIA driver branches and CUDA versions sets out. For an environment that has to stay reproducible through a certification cycle, the longer branch is the calmer choice. NVIDIA's PyTorch containers 26.08 and 26.09 are built on CUDA 13.4.1, newer than the CUDA 13.0 that pairs with R580, so on an R580 host they rely on CUDA's compatibility mechanisms; validate the exact pair of driver and image you document. Security releases of the driver are changes too: NVIDIA's bulletin of 30 September 2026 names 580.178.04 as the fixed R580 driver, and an update goes through your change control with a re-run of the verification tests.

Deterministic settings slow some training. One workable approach is to develop with the fast settings and to run the documented training and the verification in deterministic mode; whichever you choose, write it into the record. We supply the training and validation servers with the driver branch and operating system you specify; tell us which framework, container and driver your quality system names, and our team proposes the configuration.

Training and validation on separate machines

The FAQ refers to "principles related to separation of datasets" in Commission guidelines that were still forthcoming when it was published. Two machines make that separation physical. The training server belongs to the development team, which updates it as models evolve. The validation server holds the locked test data, which the training team cannot read, and runs only released model candidates on the documented stack. It changes only through change control, so a test run in March and a test run in September use the same software.

Validation should also cover the hardware the device will run on. If your device runs on a hospital server with an NVIDIA L4 or an RTX PRO 4500 Blackwell Server Edition, put that card into the verification plan, because PyTorch makes no promise that results carry over between platforms. A validation server with two RTX PRO 6000 Server Edition cards can be split by MIG into up to eight isolated 24 GB instances to run several candidates in parallel; a MIG instance is still a fraction of an RTX PRO 6000, not the target card. Our article on MIG profiles of the RTX PRO 6000 lists the layouts.

Configuration options

The options follow the reference configurations on our AI servers page and NVIDIA's guide for certified systems: two processors, at least six cores per GPU and system memory of at least twice the GPU memory.

Reference configurations on our AI servers page; NVIDIA-Certified Systems configuration guide; power by our estimate (cards at 600 W, two processors, plus 15 per cent for the rest of the server), as in our sibling server guides.

Two cards in one server suit a start-up with one product: one card trains, the other runs verification in MIG instances. The separation is then by card and by user rights rather than by machine, which is weaker; plan the second server once the first device goes to a notified body. Four plus two is the layout we would propose for a manufacturer with one or two AI products in development. The RTX PRO 6000 Server Edition has 96 GB of GDDR7 at 1,597 GB/s per card; MONAI's whole-body CT bundle, for comparison, asks for 48 GB for training, as our medical imaging guide quotes.

Four H200 NVL carry 141 GB of HBM3e at 4.8 TB/s per card, joined by a four-way NVLink bridge with 900 GB/s per GPU, for 3D models whose patches or batches do not fit 96 GB, or for training runs long enough that the bandwidth pays off. The H200 NVL comes with a five-year NVIDIA AI Enterprise subscription, which starts 90 days after shipment to the server maker; our comparison of the H200 NVL and RTX PRO 6000 for fine-tuning covers the training trade-offs. Eight H200 NVL are our training node for several teams. Our guide to training vision models explains data-parallel training over PCIe and memory per card.

An assistant over the technical file

The technical documentation of a device is a large set of linked documents: requirements, risk files, verification reports, clinical evaluation and the quality manual. A language model with retrieval over these documents helps the regulatory team find where a requirement is addressed and draft text for a person to check, without sending unreleased design data to an outside service. By our users-per-card rule, which takes 90 per cent of the 95.6 GiB the driver reports, less 3 GiB per card and less the weights, gpt-oss-120b (Apache 2.0, 117B parameters with 5.1B active, 60.8 GiB of weights) holds 19 conversations of 32K tokens on one RTX PRO 6000 Server Edition, more than a regulatory team uses at once. Our Private AI/ML service sets up the model and the retrieval with access rights per document; our guide to RAG on company data describes the design. The assistant's drafts are inputs to your document control, not released documents, and a model change for the assistant goes through the regression tests our guide to LLM evaluation before model upgrades describes.

Data protection and data provenance

Training data for medical AI usually comes from hospitals and studies. Article 9(1) of the GDPR lists data concerning health among the special categories of personal data whose processing it prohibits, with exceptions set out in the regulation. Keeping the data on your own server makes access control and deletion concrete, but the legal basis, the contracts with data sources and a data protection impact assessment remain tasks for your data-protection officer. For the technical file, record for every data set where it came from, under which agreement, which version entered which split, and when it was deleted.

Notes for the IT team

1. Storage. Keep data sets on storage with version records and checksums, and give the training team read access to training and validation splits only. Our guide to NVMe storage for an AI server covers the drives; plan capacity from your data volume.
2. Backups. The record of an environment is only useful if the images, weights and data versions it names can be restored; our guide to backing up an AI server covers what to copy.
3. Drivers. On Ubuntu with NVIDIA's repository, install the pinning package for the branch before the driver, for example nvidia-driver-pinning-580, so that a routine upgrade does not move the server to a newer branch.
4. Firmware. BIOS, BMC and GPU firmware updates change the platform as well; our guide to GPU server firmware updates explains the order.
5. Containers. Keep the NVIDIA Container Toolkit at 1.17.8 or later and reference images by digest in the record, not by tag alone.
6. Isolation. A validation server often sits in a segmented network without internet access; our guide to an air-gapped server with offline installation shows what to mirror, and securing a GPU server covers the BMC and the endpoints.
7. Delivery. The servers arrive on request with the operating system, the NVIDIA driver, CUDA and a container runtime installed, on the branch you specify.

Power and room

By our estimate, a two-card server draws about 1.8 kW at the wall and fits one 230 V 16 A feed, which carries 2.94 kW at 80 per cent. Four RTX PRO 6000 Server Edition at 600 W draw about 3.4 kW, as do four H200 NVL by our estimate, and need 32 A or three-phase. Eight H200 NVL draw about 6.3 kW by our estimate and need three-phase; Dell's datasheet gives about 8 kW per eight-card node as an indicative figure, so plan the feeds on the maker's figure. A power estimate is confirmed by a measurement on the delivered system. Our guide to preparing a server room for a GPU server lists what to check. Without a server room of your own, our Private AI/ML service runs the platform on dedicated hardware in a Tier-3 data centre in Lithuania, inside the EU.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build the training and validation servers to order with RTX PRO 6000 Server Edition or H200 NVL cards, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Your own acceptance test belongs in the validation record, and our guide to GPU server acceptance testing gives a procedure. Describe your device, your models and the stack your quality system names, and we reply with both servers.

FAQ