Dedicated GPU Servers

Hetzner Dedicated GPU Server GEX63

Explore the Hetzner GEX63 dedicated GPU server: 96 GB GPU memory, Blackwell hardware, AI workloads, networking limits and published pricing.

29 Oct 20268 min read

Specifications performance and practical uses

Updated 29 October 2026

A dedicated platform for demanding GPU workloads

The Hetzner Dedicated GPU Server GEX63 brings a substantial amount of graphics memory to developers and businesses that want to run their own AI applications. Its appeal is straightforward: a powerful professional NVIDIA GPU, a capable Intel processor and dedicated hardware under the customer's control. For projects that regularly need GPU acceleration, it offers a practical foundation for building and operating a service.

The strongest reason to consider this server is its 96 GB of graphics memory. That capacity creates room for larger models and more demanding workflows, although actual performance still depends on software, model settings and workload design. This assessment examines the published specifications and their practical implications; it does not claim independently measured benchmark results. [1]

Hardware built around the GPU

The GEX63 combines an NVIDIA RTX PRO 6000 Blackwell Max-Q GPU with an Intel Core Ultra 7 265 processor. The CPU has 20 cores, comprising eight performance cores and twelve efficiency cores. Hetzner pairs this with 128 GB of DDR5 UDIMM system memory and two 1.92 TB Gen4 Datacenter Edition NVMe SSDs.

These components serve different purposes. Graphics memory holds the model and its working data during GPU computation. System RAM supports the operating system, data preparation and application services. NVMe storage holds model files, datasets and outputs. The two SSDs provide 3.84 TB of raw capacity; configuring them as a mirrored pair leaves approximately one drive's capacity before filesystem overhead. Mirroring improves resilience against a drive failure, but separate backups remain necessary. [1]

Understanding the Blackwell graphics card

NVIDIA specifies 96 GB of GDDR7 memory with error correction, fifth-generation Tensor Cores and fourth-generation ray-tracing cores for the Max-Q card. Its published memory bandwidth is 1,792 GB per second, and its maximum board power is 300 watts. Those are GPU specifications, rather than measurements of the entire server.

The advertised 3,511 AI TOPS figure also needs context. NVIDIA identifies it as theoretical FP4 performance using sparsity. It should not be interpreted as a guaranteed chatbot response rate or compared directly with figures measured at different numerical precisions. Useful application benchmarks include response latency, tokens generated per second and the number of simultaneous requests handled within an acceptable waiting time.

For buyers, the practical question is how well the chosen software uses this hardware. A compatible, carefully configured inference engine can matter as much as an impressive specification sheet. [2]

Running language models within the memory budget

A useful starting point is estimating memory for model weights. Using simple arithmetic, eight billion parameters stored at sixteen bits each require roughly 16 GB. Seventy billion parameters require roughly 140 GB at the same precision, exceeding the GEX63's GPU memory before any working space is included. These are decimal estimates for weights alone.

Quantisation changes that calculation by representing weights with fewer bits. At an idealised four bits per parameter, seventy billion parameters amount to approximately 35 GB. Real implementations need additional space for quantisation information, temporary buffers and the attention cache. Longer conversations and more concurrent users can increase memory demand significantly.

Consequently, some suitably quantised large models are plausible candidates for this server, but compatibility and capacity must be tested individually. Buying 96 GB of VRAM does not guarantee that every model, context length or batch size will work. [3]

Fine tuning and realistic training expectations

Fine-tuning an existing model is a more realistic starting point for many organisations than training a large general-purpose model from scratch. Methods such as LoRA train relatively small adapter matrices while leaving the original model weights frozen. Hugging Face's documentation explains how this reduces the number of trainable parameters and associated memory requirements.

On the GEX63, that approach could support experiments with specialist terminology, structured responses or a particular writing style. Feasibility still depends on the base model, sequence length, training method and batch size. Full training requires memory for more than model weights, including gradients, optimiser states and intermediate activations.

A sensible project begins with a small, well-prepared dataset and a clear evaluation task. Better hardware accelerates experimentation, but it cannot compensate for inconsistent examples or an unclear definition of success. [4]

Applications beyond chatbots

The graphics card also supports professional rendering, simulation and media workloads. Its ray-tracing capabilities can benefit compatible rendering applications, while its video engines provide dedicated encoding and decoding functions. NVIDIA lists four ninth-generation NVENC encoders and four sixth-generation NVDEC decoders for this model.

Potential projects include processing video libraries, generating images, rendering product scenes and running GPU-accelerated analysis. Each application needs its own compatibility check and representative benchmark. A production team should test an actual scene, dataset or media file before estimating completion times. Rendering performance and language-model performance measure different tasks, so neither provides a reliable shortcut for predicting the other. [5]

An example for an AI search service

Consider a business building a product search website. A possible design uses ordinary search software to retrieve matching products, then sends a short selection of descriptions to a language model for explanation. The GPU handles the language task, while prices, stock information and product identifiers remain in a regularly updated database. This is an architectural example, rather than a supplied Hetzner feature.

The separation matters because generating fluent text is different from maintaining accurate records. A model should receive current facts from the application instead of guessing them. Start by testing a modest model against real customer queries, including ambiguous requests and missing information. Measure whether its answers are useful before moving to a larger model. Extra memory creates options, but the quality of the retrieval process and source data remains central to the experience.

Networking location and expansion limits

Hetzner lists the GEX63 in Helsinki, Finland, with a 1 Gbit/s connection and unlimited traffic on that standard connection. Network capacity deserves attention when models, training datasets or video files move frequently between locations. The theoretical transfer ceiling is approximately 125 megabytes per second before protocol overhead and other bottlenecks.

The configuration is fixed. Hetzner's GPU documentation lists no additional RAM or drive upgrades for the GEX63, and the 10 Gbit/s uplink option is unavailable for this model. Extra GPU cards cannot simply be added later. Teams anticipating substantial growth should plan for another server or a different configuration, including the work required to migrate data and services. [6][7]

Software and day to day operation

A dedicated GPU server needs an operating environment that matches its hardware. Installing an inference package is only part of the process: the NVIDIA driver, CUDA libraries, machine-learning framework and model format must work together. For example, vLLM's installation guidance warns that compiled components can be incompatible with different CUDA and PyTorch builds, and recommends a fresh environment.

For production use, maintain a tested configuration and record software versions before upgrading. Monitor GPU memory, utilisation, disk space and application errors. Place authentication and request limits in front of public services, and keep administration access restricted. Backups should include configuration and essential data, with a recovery procedure that has actually been tested. Budgeting time for this operational work is part of choosing dedicated infrastructure. [8][7]

A practical evaluation before launch

An effective trial should resemble a normal working day. Load the intended model, run typical requests, then introduce longer inputs and bursts of simultaneous activity. Record how long users wait for the first response, how quickly answers finish and whether memory usage remains stable. A successful single request demonstrates basic functionality; a sustained test reveals whether the proposed service is ready for customers.

Also test what happens when a process stops unexpectedly. Confirm that jobs restart safely, incomplete work is handled correctly and monitoring raises an actionable alert. Keep enough operational headroom for maintenance and unpredictable demand. Choosing a smaller model that consistently meets the service target can be more useful than filling nearly all available memory with a larger one. Capacity planning should follow measured behaviour and the needs of the people using the application. Repeat these checks after significant software or model changes.

Pricing and the importance of utilisation

Hetzner's announcement dated 6 October 2026 gives a monthly price of €1,188.81 including 19% German VAT and an IPv4 address. That is equivalent to €999 before VAT. A separate setup charge applies; check the configurator for its current amount, applicable taxes and the final order total. The German gross figure should not be treated as a universal price for every customer.

Value depends heavily on utilisation. A server running useful workloads throughout the month spreads its rental cost across more completed work. Occasional experiments may justify a different charging model. Compare the full operating cost, including administration, backups and software licences, against expected usage. Cost per completed task is usually more informative than the monthly rental alone. [9]

Choosing the right place in the GEX range

Within Hetzner's range, the GEX45 offers 24 GB of GPU memory, while the GEX131 combines the same 96 GB GPU class with a Xeon platform and larger system-memory options. The GEX430 provides four GPUs. These alternatives address different constraints: a smaller model, more CPU-side resources or workloads designed for multiple accelerators.

The GEX63 is therefore worth shortlisting when a project needs substantial GPU memory without requiring the larger host configuration of the GEX131. Before committing, test the intended model or application, measure performance under realistic demand and confirm that storage and networking are adequate. Its strongest case is a sustained workload that fits comfortably on one GPU and has a team ready to manage the service. [6]