aiDAPTIV+ Explained: Extending GPU Memory onto NVMe for On-Prem AI
Overview
The wall most teams hit when they try to fine-tune a large model on their own hardware is not compute — it is memory. A 70B model at FP32 needs roughly 280 GB just for weights, before optimiser state, gradients and activations. Buy enough GPUs to hold that and you have bought a power problem as well as a budget problem. aiDAPTIV+ takes a different route: it extends GPU memory onto high-endurance NVMe SSDs through a middleware layer, so the model that would not fit now fits. This article explains how the architecture works, what it genuinely changes, and where its honest limits are.
Key takeaways
- Memory is the wall, not compute — a 70B model at FP32 needs roughly 280 GB for weights alone.
- aiDAPTIV+ extends GPU memory onto NVMe, adding a reported 320 GB on PCs up to 8 TB on workstations and servers.
- It is PyTorch-compliant middleware — vendor documentation states no modification of the AI application is required.
- Endurance is the enabling spec — the cache SSDs are rated at an industry-leading 100 DWPD, because offload writes constantly.
- It extends capacity, not raw throughput — offload streaming targets inference and parameter-efficient fine-tuning; confirm performance in a scoped proof-of-concept.
Why GPU memory is the binding constraint
Model memory scales with parameter count and precision. At FP32 a parameter costs 4 bytes, at FP16 two. So 13B at FP32 is about 52 GB, 34B about 136 GB, 70B about 280 GB and 180B about 720 GB — weights only. Fine-tuning adds optimiser state and gradients on top, which is why a card that can serve a model often cannot train it. Teams respond by buying more GPUs, but GPUs are bought in whole units of cost, power and cooling, and most organisations run out of budget or building power long before they run out of ambition. See our local AI workstation guide for how far VRAM alone gets you.
How the architecture works
aiDAPTIV+ inserts a memory-management middleware between the framework and the hardware. Model state that does not fit in VRAM is held in aiDAPTIVCache — dedicated high-endurance NVMe — and streamed into GPU memory as the computation needs it. Per vendor documentation the extension is a reported 320 GB for PC-class systems and up to 8 TB for workstations and servers, and the layer is PyTorch-compliant, so existing training and inference code runs without modification. Nodes can be added to scale out.
Why endurance, not just speed, is the spec that matters
This is the detail that separates an offload cache from an ordinary SSD. Offloading model state means writing and rewriting continuously for the length of every training run — a workload that would exhaust a normal enterprise drive quickly. The aiDAPTIV+ cache drives are specified at 100 DWPD (drive writes per day), described by the vendor as industry-leading, using a specialised SSD design with an advanced NAND correction algorithm. When evaluating any GPU-memory-extension approach, endurance rating is the first question to ask; throughput is the second.
What each hardware tier reaches
| Tier | Vendor-stated capability | Typical use |
|---|---|---|
| AI notebook PC | Up to 8B parameter full model training | Development, testing |
| Desktop | Up to 13B parameter full model training | Individual practitioner |
| Workstation | Up to 100B parameter full model training | On-prem fine-tuning, team use |
| Server | Up to 405B parameter full model training | Large-scale training, high concurrency |
| Edge / IoT / robotics | Up to 70B parameter LoRA training | Where the data is created |
The honest limits
Offload extends the model size that fits; it does not turn a workstation into a supercomputer. NVMe is far slower than HBM, so streaming introduces movement that pure-VRAM execution avoids. Vendor guidance is explicit that offload streaming is optimised for inference and parameter-efficient fine-tuning, and that final performance should be confirmed in a scoped proof-of-concept. If your requirement is frontier pre-training from scratch or very high concurrency, the answer remains more GPUs and a rack-scale fabric — see rack-scale AI factory nodes. Offload is how you make a capable machine reach further, not a substitute for scale.
Why this matters for Indian buyers
Two constraints make on-premises offload attractive here. First, power and budget: reducing the number of high-cost, power-hungry GPU cards needed for a given model size lowers both capital and facility demands. Second, data control: the approach keeps AI processing where the data is created and allows LLM training behind your own firewall. Under the DPDP Act, where personal-data handling carries penalties up to ₹250 crore per violation, keeping training data in-country and under your control is the simplest defensible position — the same logic covered in our training cluster roadmap.
Frequently asked questions
What is aiDAPTIV+?
It is a GPU-memory extension approach: middleware plus high-endurance NVMe that holds model state which does not fit in VRAM and streams it to the GPU as needed. It lets a given machine fine-tune and serve larger models than its VRAM alone would allow.
Do I need to change my training code?
No. Vendor documentation states the memory-management layer is PyTorch-compliant and eliminates the need to modify your AI application, so existing training and inference scripts run unchanged.
How much memory does it add?
Vendor figures state the optimised middleware extends GPU memory by a reported 320 GB for PC-class systems and up to 8 TB for workstation and server systems using aiDAPTIVCache.
Why does SSD endurance matter here?
Offloading writes and rewrites model state continuously throughout a training run. The cache drives are rated at 100 DWPD with a specialised design and advanced NAND correction, because a standard enterprise SSD would wear out under this pattern.
Does offload make training faster?
No — it makes larger models fit. NVMe is slower than HBM, so streaming adds data movement. Vendor guidance positions offload for inference and parameter-efficient fine-tuning, with performance confirmed in a scoped proof-of-concept rather than assumed.
Ready to deploy?
Talk to an RDP architect about power, cooling and lead time.