Skip to content

GPU capacity, operated

Around 500 eight-GPU nodes spanning H100, RTX 4090 and RTX 3080 tiers, with the cluster software, monitoring and on-call practice already attached. You get capacity that works on day one, not a rack and a wiki page.

Around 500 machines, every one an 8-GPU node

Three tiers, chosen by what the workload actually needs. Most teams overpay by putting a quantized 7B model on hardware built for 70B pre-training.

  • An open eight-GPU node on the bench, copper heatsinks and bridge connectors in a row

    8 × NVIDIA H100

    Flagship

    Flagship

    The tier for work that will not fit anywhere else: pre-training and full-parameter fine-tuning of large models, and high-throughput serving of 70B-plus and mixture-of-experts architectures at long context.

    Best for

    • Multi-node distributed training
    • Full-parameter fine-tuning at scale
    • 70B+ and MoE inference at long context
    • FP8 serving where throughput per node matters most
    • 80 GB HBM
    • NVLink
    • FP8
    • RDMA multi-node
  • Eight fan-shrouded cards racked in one chassis, seen down the row

    8 × NVIDIA RTX 4090

    Throughput per dollar

    The workhorse of the fleet. 192 GB of aggregate VRAM per node serves quantized large models and mid-size models at full precision, at a fraction of the cost per token of data center silicon.

    Best for

    • Production inference for 7B–32B models
    • Quantized 70B serving across the node
    • LoRA and QLoRA fine-tuning
    • Quantization and evaluation pipelines
    • 24 GB each
    • 192 GB / node
    • AWQ / GPTQ
    • vLLM tuned
  • A dense service aisle of identical compute nodes receding into the dark

    8 × NVIDIA RTX 3080

    Volume and batch

    Cost-optimized capacity for workloads measured in volume rather than model size: embeddings, classification, batch generation, and the development and CI environments that should never sit on flagship hardware.

    Best for

    • Embedding and reranking at volume
    • Batch and offline inference
    • Small and heavily quantized models
    • Development, staging and CI capacity
    • Batch workloads
    • Embeddings
    • Dev / CI
    • Lowest cost tier

Three ways to take the hardware

The right boundary depends on how much of the stack your team wants to own.

  • Bare metal

    Full root access to the physical node. You control the kernel, driver stack and scheduler; we own the hardware, power, cooling and network underneath.

    Best for

    Training runs and teams with an existing platform stack

  • Containers

    GPU-attached containers with the NVIDIA Container Toolkit configured, your image, our orchestration. Faster to start, fewer moving parts to maintain.

    Best for

    Inference services and iterative experimentation

  • Managed Kubernetes

    A namespace on a cluster we operate, with device plugins, autoscaling and observability already wired. LLMFabric handles engine placement.

    Best for

    Production serving without a platform team

The numbers, in one place

Regions, the current per-tier split and contractual availability targets are shared directly rather than published. Everything else is here.

Accelerators

Fleet size
~500 nodes · ~4,000 GPUs
Node configuration
8 GPUs per node
NVIDIA
H100 · RTX 4090 · RTX 3080
Per-tier availability
Current split on request
AMD / Ascend / Hygon / MThreads
Supported via LLMFabric

Cluster

Interconnect
RDMA fabric, NCCL-validated
Topology
Single node to multi-node
Aggregate VRAM
192 GB–640 GB per node
Storage
Shared NVMe, sized per engagement
Regions
Shared on request

Operations

Monitoring
Prometheus + Grafana, exposed to you
Coverage
24 / 7 on-call
Failure handling
Node replacement and run resumption
Availability target
Defined per contract

Commercial

Term
Hourly, monthly or reserved
Metering
Per GPU-hour or per token
Billing audit
Verifiable receipts on metered inference
Contracting
Direct, no reseller in the path

From first email to running workload

No discovery call theatre. Send us the shape of the workload and we size it.

  1. 01

    Describe the workload

    Model, expected concurrency, latency target and data residency constraints. That is enough for a first sizing.

  2. 02

    Get a sizing and a price

    We come back with an accelerator configuration, an engine recommendation and a number. If the workload is a bad fit for us, we say so.

  3. 03

    Benchmark before you commit

    A short paid pilot on the proposed configuration, measured against your own traffic, using the same methodology we publish in our open benchmarks.

  4. 04

    Run in production

    Handover with dashboards, alerting and an escalation path. Capacity scales without a renegotiation for every node.

Transparency

We publish our benchmarks, including the unflattering parts

Our Qwen3-235B-A22B-FP8 benchmark reports peak throughput alongside the concurrency level where success rate degraded, the rate-limit behaviour that broke standard client retries, and the run that crashed the upstream. Methodology and raw JSON are in the repository.

Read the benchmark