Fine-Tuning Capacity: What 8x RTX PRO 6000 Blackwell Plus aiDAPTIV+ Actually Runs

Overview

Fine-tuning capacity is usually discussed in vague terms. It is more useful to ask a precise question: on a specific machine, how many fine-tuning sessions can you actually run at once, per model size and precision? MiPhi has published exactly that table for a reference system — 8x RTX PRO 6000 Blackwell GPUs (96 GB each, 768 GB total) with 8 TB of aiDAPTIV+ NVMe — comparing GPU-only against GPU-plus-offload. The numbers are stark at the top end, and this article works through what they mean for buyers rather than simply repeating them.

What a session actually means

A fine-tuning session is one concurrent job holding its own model state — weights, optimiser state, gradients and activations — for the duration of the run. Counting sessions rather than raw memory is useful because it maps to how teams actually work: several researchers iterating on adapters at once, or one large job monopolising the machine. The reference hardware here is 8x RTX PRO 6000 Blackwell at 96 GB each (768 GB aggregate) plus 8 TB of aiDAPTIV+ NVMe (4x 2 TB). All figures below are the vendor’s published analysis for that configuration.

The published numbers

Reading the pattern: throughput versus feasibility

Two different benefits hide in that table. For small models the gain is throughput — 3B FP32 moves from 16 concurrent sessions to 136, which is the difference between a queue and a free-for-all across a research team. For large models the gain is feasibility: at 70B FP32 and above, the GPU-only column reads zero. Not slow — zero. The job does not fit, so no amount of patience produces a result. Offload turns an impossible job into a possible one, which is a categorical change rather than a percentage improvement.

Why the multiplier shrinks as models grow

Notice the ratio: 3B FP32 improves 8.5x, 13B improves 10x, 34B improves 15x, but 405B improves from 0 to 1. As model state grows, more of it must live in NVMe rather than VRAM, and the offload budget itself becomes the constraint. This is the honest shape of the technology — it extends reach, and reach has an edge. Treat the top rows of the table as “comfortable”, the middle as “productive”, and the last rows as “possible at all”, which is still a meaningful capability if that model is your requirement.

Precision is the cheapest lever you have

Across every row, FP16 roughly doubles the session count versus FP32 — 1B goes 96 to 272, 13B goes 8 to 81, 70B goes 1 to 14. Before buying more hardware, confirm whether your fine-tune genuinely requires FP32. Note also that the source table excludes Int8 and Int4 entirely, stating fine-tuning is not supported at those precisions — quantisation is an inference lever, not a training one. Our aiDAPTIV+ architecture explainer covers why memory, not compute, sets these limits.

Turning sessions into a buying decision

Work backwards from your team. If six researchers each need an independent 13B FP16 adapter run, the GPU-only figure of 8 already covers it and offload is not the deciding factor. If your roadmap includes a 70B or 90B domain model — common in BFSI, healthcare and public-sector work where an Indian-language or sector-specific model matters — the GPU-only column reads zero, and the question changes from “how fast” to “can we do this on our own hardware at all”. That is also where data residency argues for on-premises: under DPDP, training a domain model on sensitive records inside your own firewall avoids the cross-border questions entirely. Validate against your real workload in a scoped proof-of-concept before committing.

Frequently asked questions