The headline configuration combines four RTX PRO 6000 Blackwell Max-Q cards for 384 GB of aggregate GPU memory. That is substantial capacity, but the distinction between aggregate memory and a single memory pool matters just as much as the number on the specification sheet.
Two configurations, different priorities
G2’s own product page separates the range into a workstation-oriented build and an EPYC-based server:
| Configuration | Processor family | GPUs | System memory | Listed Windows option |
|---|---|---|---|---|
| PT9W workstation | AMD Threadripper | Two GeForce RTX 5090 cards | 512 GB ECC RDIMM | Windows 11 Pro / Workstation |
| SE5 server | AMD EPYC | Four RTX PRO 4000, 5000 or 6000 cards | 1 TB ECC LRDIMM | Windows Server |
These are vendor-listed specifications, rather than independently tested configurations. G2 does not identify the Windows Server release in that listing.
The company describes the system as built in Hampshire and lists an 890 mm-deep chassis, a 2,700 W power supply, dual 10GbE networking and IPMI management. Buyers should therefore assess more than rack height: depth, power provision and management integration belong on the procurement checklist too.
What 384 GB actually buys
Nvidia’s official datasheet confirms that each RTX PRO 6000 Blackwell Max-Q has 96 GB of GDDR7 ECC memory, a PCIe 5.0 x16 interface and a 300 W board-power rating. Four cards therefore provide 384 GB in total, with combined GPU board-power ratings of 1,200 W before accounting for the rest of the server. That is specification arithmetic, not a measurement of Q-Power’s wall-power consumption.
Crucially, four cards do not establish one transparently accessible 384 GB allocation. Nvidia’s inference documentation describes model-parallel techniques that distribute weights and activations across GPUs; it also explains that serving requests requires additional memory for the key/value cache. More concurrent requests can increase that cache footprint considerably.
DEVELOP3D reports support for 70-billion-parameter models at “full precision,” plus larger models using lower precision or quantisation. However, the report does not specify the model, numerical format, context length or concurrent-user count behind that claim. Treat it as a capability assertion, not a guarantee that every 70B deployment will fit—or deliver the same performance.
The practical takeaway: ask for a demonstration using the intended model, serving software, context length and user load. GPU capacity is the starting point, not the acceptance test.
Cloud savings need a reproducible comparison
G2 claims up to 18-fold lower costs per million tokens than premium cloud AI APIs under sustained use, alongside local latency below 40 milliseconds versus roughly 1.5 seconds for cloud APIs. Those are company claims; its product page does not provide a reproducible comparison identifying the cloud service, model, workload and latency metric.
For procurement, request three separate results:
- Responsiveness: time to first token and subsequent generation speed.
- Capacity: throughput at the required number of simultaneous users.
- Economics: total ownership costs against the actual API and model being replaced.
Those are proposed evaluation criteria, not results established for this machine.
Local control is not automatic compliance
G2 presents on-premises operation as a way to keep proprietary information within an organisation’s environment, citing GDPR, HIPAA and SOC 2 considerations. Its page does not establish a product-level compliance guarantee; buyers should not read that positioning as one.
The Q-Power’s clearest supported proposition is compact four-GPU packaging, with separate workstation and server configurations. The sensible next step is workload validation—not assuming that a dense rack enclosure automatically delivers cloud-beating economics. The chassis may be compact; the proof still needs room.