RTX PRO 6000 Blackwell Compute Cluster

Executive Summary

AGATE GREEN is deploying NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs across data centre sites in Malaysia, Thailand and Indonesia, alongside an AMD Instinct MI300X tier reserved for training. This document covers the RTX PRO 6000 tier: the hardware, the software stack, the commissioning plan, and the two service lines it exists to deliver.

The design thesis is narrow. Ninety-six gigabytes of memory per card is enough to hold a 70-billion-parameter model in FP8 on a single device, which removes tensor parallelism from the serving path. The same card carries a full ray-tracing pipeline and a four-encode, four-decode media engine, so a render customer and an inference customer can share one fleet. Memory capacity, not raw FLOPS, is the axis this tier is built on.

Three service lines run on the cluster. Token Factory bills inference by the token rather than by reserved GPU-hours. AI Agent Cloud carries agentic and multimodal workloads, including retrieval-heavy pipelines and model benchmarking. Render Farm provides GPU rendering for film, VFX and animation on the same hardware and the same metering system.

The document is written for two audiences. Creative studios evaluating in-region render capacity will find the rendering material in Section 8 most directly useful. Software and AI teams evaluating model-serving capacity inside Malaysia or Indonesia should start at Section 9. Enterprise IT groups with a data residency requirement will find the security and compliance material in Section 11 relevant.

1. Purpose and Scope

This document describes the NVIDIA RTX PRO 6000 Blackwell compute cluster that AGATE GREEN is deploying across its Malaysian and Indonesian data centre sites, and the workloads that cluster is built to serve. It covers the hardware configuration, the software stack, the commissioning sequence, and, in the most detail, the two service lines the cluster exists to deliver: a GPU render farm for film, animation and visual effects, and the AI Agent Cloud that carries LLM and agentic inference.

The intended readers are creative studios evaluating in-region rendering capacity, software and AI teams evaluating model-serving capacity, and enterprise IT groups that need to place GPU workloads physically inside Malaysia or Indonesia.

Two things this document is not. It is not a price list. It is not a service level agreement. Commercial terms, capacity commitments and support levels are issued separately and take precedence over anything stated here.

1.1 How to read the figures

Three kinds of number appear in the pages that follow, and they are labelled so that readers can tell them apart:

Reference design — an engineering target proposed by AGATE GREEN for the configuration described in Section 5. These are planning numbers, not measured results. They are stated so that customers can sanity-check whether the cluster is the right shape for their workload, and they will be replaced with as-built figures once each site is commissioned.

NVIDIA published — a specification or workload claim taken from NVIDIA's own product documentation and technical blogs. We cite the source in Appendix A and we have not independently reproduced these results.

Unlabelled — a published specification, an industry standard, or a definition (memory bandwidth of a part, the contents of a data protection statute, the name of a file system). These can be checked against the source listed in Appendix A.

Where a statement is AGATE GREEN's own commercial position rather than a measured or published fact, the text says so.

2. AGATE GREEN at a Glance

AGATE GREEN is a Malaysian AI infrastructure company. The team behind the company has worked in alternative asset management and real estate since 2016, and moved into data estate infrastructure and cloud computing between 2019 and 2022. From 2023 the business has operated as a full-stack data estate provider: computing, AI-driven analytics and secure storage under a single operator.

The company builds for one specific problem. Southeast Asian organisations increasingly need serious GPU capacity, and a large share of them cannot or will not route that work through data centres in the United States, Europe or Northeast Asia.

The reasons are practical rather than ideological: round-trip latency to a distant region is visible in interactive workloads, data residency rules apply to several of the sectors that need GPU compute most, and the cost of exporting a production pipeline is often higher than the cost of the compute itself.

2.1 Corporate details

2.2 Sites

AGATE GREEN's published build programme commits to four sites in the ASEAN region.

Phase 1 of the programme targets more than 20 MW of IT power across the Malaysian and Indonesian sites, with N+1 distributed UPS and a Tier III design intent. That figure describes site capacity, not cluster capacity. The RTX PRO 6000 tier discussed in this document occupies a fraction of it; the remainder is reserved for the AMD Instinct MI300X tier used for frontier training and the highest-throughput inference, and for later expansion.

2.3 Three service lines

Everything AGATE GREEN sells runs on one of three engines, and they share a single GPU fleet and a single metering system.

Token Factory is token-metered inference. Customers pay for the tokens their application actually consumes rather than for reserved GPU-hours. The commercial argument is straightforward: a reserved instance bills for wall-clock time whether or not it is doing work, while token metering tracks the work itself. That suits bursty or unpredictable inference traffic, and it removes the scale-to-zero problem that makes idle inference endpoints expensive.

AI Agent Cloud uses the same fleet and the same metering engine, aimed at autonomous and semi-autonomous agent workloads: multimodal assistants, multi-step tool-calling chains, retrieval-heavy pipelines, and model benchmarking.

Render Farm delivers GPU rendering for film, VFX, animation and architectural visualisation, running on the RTX PRO 6000 tier. It is the newest of the three and the one this document devotes the most space to.

3. Why This Cluster, and Where It Sits

This section sets out why a regional cluster is a different proposition from renting capacity abroad, how the RTX PRO 6000 tier differs from the MI300X tier beside it, and where the smaller of the two parts stops being the right answer.

3.1 The regional rendering problem

A studio in Kuala Lumpur, Jakarta or Ho Chi Minh City that needs large-scale GPU rendering today has roughly three options, and all three have a cost attached.

It can buy and run its own GPUs. That means capital expenditure, a machine room, power and cooling engineering, and a hardware refresh cycle that runs faster than most studio finance departments would like. It also leaves the studio holding capacity it cannot resell when a production wraps.

It can send work to a hyperscale render service in the United States, Europe or Japan. This works, and it is what most regional studios do. The costs are latency and jurisdiction.

Multi-terabyte scene uploads over international links are slow and metered. Assets leave the country, which is a problem for productions working under contractual confidentiality or on material that touches local content regulation. And when a job fails at three in the morning, the person who can explain why is in another time zone.

It can wait for regional capacity to appear. Until recently, that meant waiting.

AGATE GREEN's position is that the third option is no longer necessary for the workloads in Section 8 of this document, because the hardware class needed to serve them became available in a form factor that can be deployed at regional scale.

3.2 Two tiers, two jobs

AGATE GREEN runs a dual-GPU strategy, and the split matters when reading the rest of this document.

The two tiers are not substitutes. The MI300X tier exists for jobs that need a GPU-to-GPU fabric because a single model or a single tensor-parallel group has to be spread across many devices with very high inter-device bandwidth. The RTX PRO 6000 tier exists for jobs where the binding constraint is memory capacity per GPU or ray-tracing throughput, and where the workload can be partitioned across independent GPUs rather than synchronised across them.

That distinction is the single most useful thing to understand about this cluster, so Section 4.5 returns to it. Readers who are planning a training run for a frontier-scale model should be reading the MI300X tier documentation instead; the RTX PRO 6000 tier is the wrong shape for pre-training at that scale, and AGATE GREEN would rather say so up front than sell the wrong product.

3.3 What the RTX PRO 6000 tier is good at

Three properties made this part the right choice for the universal tier.

96 GB of memory per GPU. This is the headline. It is enough to hold a 70-billion-parameter model in FP8 on a single device, which means a serving deployment for that model class needs no tensor parallelism at all. One GPU, one model, one process. That is the operationally simplest arrangement available, and it produces the fewest 3 a.m. surprises.

Both AI and graphics on the same silicon. The part carries fifth-generation Tensor Cores and fourth-generation RT Cores, plus a full media pipeline with four encode and four decode engines. A rendering customer and an inference customer can therefore be served from the same physical cluster, which is what makes the shared-fleet, shared-metering model in Section 2.3 economically workable.

MIG partitioning. The part supports Multi-Instance GPU, dividing into as many as four fully isolated instances of 24 GB each, each with its own memory, cache and compute cores, and each with guaranteed quality of service. That is the mechanism that makes secure multi-tenancy possible on a single card, and Section 9.4 depends on it.

3.4 What it is not good at

No NVLink. Cross-GPU traffic runs over PCIe Gen 5 and the host, not over a dedicated GPU-to-GPU fabric. Pipeline-parallel serving and one-model-per-GPU serving are unaffected. Tensor-parallel splitting of a very large model across many cards inside one node will hit the interconnect before it hits anything else. Workloads in that category belong on the MI300X tier.

Lower per-GPU compute than the SXM/HBM parts. The RTX PRO 6000 is competitive on memory capacity and on memory per unit of capital cost. It is not competitive with an H200 or MI300X on raw FLOPS per GPU. Judgement: match the part to the workload rather than the other way round.

Passive cooling. The Server Edition is passively cooled and needs a chassis whose airflow curve the vendor has qualified for it. It will not behave correctly in an arbitrary 2U box. This is a deployment constraint, not a defect, and Section 5.6 treats it as a design input.

4. The GPU

Everything in the universal tier follows from the part it is built on. This section covers the published specification, what the Blackwell architecture changes for serving economics, and the two design features that matter most to a multi-tenant operator.

4.1 Specification

The following is the published specification of the NVIDIA RTX PRO 6000 Blackwell Server Edition. Source: NVIDIA product documentation, listed in Appendix A.

Two notes on how to read this table. First, the 600 W figure is a ceiling, not a typical draw; OEMs ship the same part capped at 450 W for denser chassis, and the cap can also be applied unintentionally by an under-rated power cable.

Second, the two memory bandwidth figures that circulate (1,597 GB/s and 1.79 TB/s) come from different parts of NVIDIA's own documentation. The cluster design in Section 5 does not depend on which is used, because none of the reference workloads are bandwidth-bound in a way that this difference changes.

4.2 What the architecture changes

Fifth-generation Tensor Cores add FP4 precision support and a second-generation Transformer Engine. FP4 is the reason the 4 PFLOPS figure exists, and it matters for inference economics: a model quantised to FP4 moves a quarter of the bytes through memory that an FP8 model does, which raises throughput per GPU on memory-bound decode stages.

AGATE GREEN runs FP8 as the default serving precision and FP4 where the model tolerates it without quality loss. The decision is made per model and per customer, not globally.

Fourth-generation RT Cores are the graphics half of the same story. NVIDIA claims up to twice the RT performance of the previous generation, and the accompanying software features (neural shaders, DLSS 4, RTX Mega Geometry) move work from brute-force sampling into the AI pipeline. For rendering customers this is where the generational gain is largest.

The media pipeline is easy to overlook and relevant to two customer groups. Four encode and four decode engines per GPU, with 4:2:2 H.264 and HEVC support in both directions, means the same cluster can ingest footage, run inference over it, and emit broadcast-format output without a separate transcode tier. Video production and media-analytics pipelines should be sized with this in mind.

4.3 MIG

Multi-Instance GPU partitions one physical card into as many as four isolated instances, each with 24 GB of dedicated memory, its own cache, and its own compute cores. Isolation is enforced in hardware, and each instance carries a guaranteed quality-of-service level.

For a multi-tenant operator this is the difference between offering "a GPU" and offering "a predictable, isolated slice of a GPU". A 24 GB slice is enough for a small language model, an embedding service, a vision model, or a single agent runtime.

It is not enough for a 70B model, and MIG is not the right mechanism for serving large models, which want a whole GPU. AGATE GREEN uses MIG for tenant isolation on smaller endpoints and whole GPUs for large-model tenants, and the two arrangements are priced differently because they cost differently to provide.

4.4 Confidential Computing

The RTX PRO 6000 is the first general-purpose GPU to support NVIDIA Confidential Computing. This provides a hardware-isolated trusted execution environment so that model weights and input data are protected while in use, not only while at rest or in transit.

This is the security property most relevant to the financial services and healthcare workloads in Section 10, and to any customer whose threat model includes the infrastructure operator. It is worth being precise about what it does and does not cover: it protects the workload from unauthorised access at the platform level. It does not replace tenant-side key management, application-level access control, or the network controls in Section 11.

4.5 The NVLink question

The RTX PRO 6000 Server Edition does not support NVLink. For a customer used to H100 or B200 fleets this looks like a serious omission, so it is worth stating plainly when it does and does not matter.

It does not matter for rendering. Render jobs are embarrassingly parallel at the frame and tile level. Independent GPUs, no inter-GPU communication.

It does not matter for one-model-per-GPU serving, which is the majority of 70B-class inference deployments. The model fits on one device; there is nothing to split.

It does not matter for pipeline-parallel serving, where the pipeline stages communicate on a scale that PCIe Gen 5 handles comfortably.

It does matter for tensor-parallel serving of models too large to fit on one device. If a customer needs to split a single model across four or eight GPUs and run them in lockstep, the inter-device traffic pattern is exactly the one this part is weakest at, and the right answer is the MI300X tier, where Infinity Fabric and 192 GB of HBM3 per GPU supply the coupling this workload needs.

NVIDIA's published workload positioning for the RTX PRO 6000 tier is inference, fine-tuning, visual computing and agentic AI. AGATE GREEN's deployment follows that positioning rather than working against it.

4.6 Published performance claims

NVIDIA publishes the following comparisons against the previous-generation NVIDIA L40S (Ada Lovelace architecture). These are NVIDIA's figures, not AGATE GREEN measurements.

AGATE GREEN's commitment on this point is procedural rather than promotional: before a customer signs for a serving tier, we will run their model on the target configuration and give them the measured throughput and latency for their workload, on our hardware. Vendor benchmarks are a useful filter for choosing hardware. They are not a substitute for measuring the specific model and the specific request distribution a customer actually runs.

5. Reference Cluster Architecture

The architecture below is a reference design rather than a bill of materials. It describes one compute node in detail, then scales that node to three sizes so that a reader can see how capacity, rack footprint and power grow together.

5.1 Design principles

Four constraints shaped the design.

The cluster has to be deployable inside a commercial data centre in Malaysia and Indonesia, which means standard 19-inch racks and power densities that the sites can actually supply.

It has to serve two dissimilar workloads, batch rendering and latency-sensitive inference, from one fleet without either starving the other.

It has to isolate tenants from each other at the hardware level, because several target sectors will not accept a software-only isolation story.

It has to be serviceable by a regional team. That rules out exotic cooling loops and bespoke chassis that require overseas engineers to maintain.

5.2 Compute node

Reference design: an eight-GPU node, which is the densest configuration the part supports and the form factor most OEMs ship.

The gap between the nominal and ceiling figures is normal and worth planning for. The ceiling is what the chassis and power supplies are rated to deliver; the nominal figure is what the configuration draws when the GPUs are at a sustained, realistic load rather than a synthetic peak. Rack power provisioning should be sized on the ceiling.

5.3 Interconnect

Three separate networks, for three different jobs.

Scale-out fabric. 400 Gb/s class Ethernet (RoCEv2) or InfiniBand NDR, depending on site. This carries distributed inference (pipeline parallelism, request routing between model replicas), distributed fine-tuning, and the control traffic for the render scheduler. For the workloads this cluster is designed for, 400 Gb/s per node is not the bottleneck.

Storage fabric. Separate from the compute fabric, sized to sustain 2–4 GB/s per GPU for training-adjacent and rendering-adjacent workloads that stream datasets. Keeping storage off the scale-out fabric matters more than its raw speed: a render farm that saturates the same links used for inference request routing will produce latency spikes in the inference service.

Management. Dual 10/25 GbE, BMC access, out-of-band only, no workload traffic.

5.4 Storage

The parallel file system choice is driven by what the customer's pipeline already speaks. Studios running Autodesk, Foundry or SideFX tooling generally arrive with a WekaFS or Lustre expectation; AI teams often want an S3-compatible object tier with a POSIX bridge. AGATE GREEN supports both and does not require a customer to re-platform their pipeline to use the farm.

5.5 Reference configurations

Three reference sizes, so that customers can see the shape of the scaling. All three are reference designs.

Note what the scaling is and is not. Aggregate memory and compute scale linearly with GPU count, which is what makes both rendering and partitioned inference scale predictably on this tier. Aggregate *interconnect* does not scale the same way, because the absence of NVLink means there is no all-to-all GPU fabric to grow. That is the reason the Large configuration is described as a multi-site serving platform rather than as a training cluster.

5.6 Rack, power and cooling

At 8 kW nominal per node, an eight-GPU node needs more than conventional air cooling can supply.

For reference, a GB200 NVL72 rack carries 72 GPUs in roughly 132 kW. The RTX PRO 6000 tier is a considerably lower-density proposition, which is precisely why it can be deployed at regional sites without a facility rebuild.

Site power is delivered as N+1 distributed UPS with the Tier III design intent described in Section 2.2. The liquid-cooled single-slot FHXL variant of the part exists for customers who want higher GPU density per rack unit than the air-cooled dual-slot card allows; it is a deployment option, not a default.

5.7 Mapping to sites

6. Software Stack and Orchestration

A cluster is only as usable as the software on it. AGATE GREEN standardises on the following stack; deviations are possible for customers with their own toolchain, but the standard stack is what the platform team supports as a managed service.

6.1 Base platform

Ubuntu LTS with NVIDIA drivers, CUDA, and the container runtime (Docker or Podman). NVIDIA AI Enterprise is licensed across the fleet, which is what makes the agentic AI, inference and visual computing libraries below supportable at production grade rather than as community builds.

6.2 Inference serving

The choice between vLLM and TensorRT-LLM is a trade. vLLM handles model changes and new architectures faster and needs less per-model engineering. TensorRT-LLM produces better throughput and latency on a model that has been through the compilation step. AGATE GREEN runs both and lets the customer choose per endpoint.

The details that determine real-world performance (batching strategy, KV-cache configuration, prefix caching, speculative decoding, quantisation level) are tuned per deployment rather than fixed platform-wide.

6.3 Orchestration

Kubernetes with GPU-aware scheduling is the control plane, with a device plugin for MIG slice allocation and NVIDIA Run:ai for workload scheduling and quota management across tenants. The GPU operator handles driver and container-toolkit lifecycle.

Practically, this is what allows a customer's workloads and AGATE GREEN's other tenants to share the fleet without stepping on each other: quotas are enforced at the scheduler, isolation is enforced by MIG at the card level, and network policy is enforced by Kubernetes at the pod level.

6.4 Rendering stack

The farm runs commercial and open-source render managers on top of the same Kubernetes substrate. Deadline, Qube and OpenCue are all supported, and job submission is available through the render manager's own API, through command-line submission, and through a REST endpoint for pipeline integration.

Supported applications and renderers, as deployed:

OctaneRender is worth calling out specifically. OTOY has stated that the 96 GB framing is what lets OctaneRender's GPU path tracer hold complex neural rendering models alongside a scene, and that the server-edition part is what made those workflows viable for 3D content creators. That is an application-side statement about memory capacity, and it is the clearest illustration of why capacity rather than raw FLOPS was the right design axis for this tier.

6.5 Metering and observability

Token metering is measured at the gateway rather than estimated from job duration. Every inference call logs prompt tokens, completion tokens, and cached tokens, and the customer's dashboard shows consumption against their own applications and API keys. Render work is metered on the same principle: a job's resource consumption is recorded from the scheduler, not inferred from elapsed time.

For both service lines the customer-facing artefact is the same: a usage record that can be reconciled against a bill, and that can be attributed to a specific project, team or client.

7. Deployment Plan

The rollout follows four phases. Each phase has a stated exit condition, because a phase that ends without a measurable deliverable tends to become a phase that never ends.

7.1 Phase 1 — Deployment

Site preparation at the Malaysian and Indonesian sites; GPU hardware procurement and installation for both the MI300X and RTX PRO 6000 tiers; network and interconnect configuration; commissioning of the 20+ MW IT power programme.

Exit condition: nodes racked, cabled, powered, fabric-validated, and passing sustained burn-in at rated load. Storage fabric sustaining 2–4 GB/s per GPU.

7.2 Phase 2 — Integration

Token Factory billing engine integration; API gateway and developer portal launch; MIG activation and isolation testing; enterprise pilot programmes with local partners.

Exit condition: a pilot tenant can create an API key, run inference against a model, and reconcile token consumption to a usage record without manual intervention.

7.3 Phase 3 — Render Farm

RTX PRO 6000 render farm cluster commissioning; 3D pipeline integration across Blender, Maya, V-Ray and Octane; creative industry partnerships and onboarding; SLA and QA framework.

Exit condition: a full production sequence rendered end to end by an external studio, with measured turnaround times published.

7.4 Phase 4 — Expansion

Second-phase capacity additions; advanced agent templates and marketplace; regional expansion beyond the current three sites; evaluation of adjacent lines (edge inference, HPC-as-a-service).

Exit condition: not applicable. Phase 4 is a rolling programme rather than a project.

7.5 Dependency notes

Three dependencies are worth stating because they sit outside AGATE GREEN's direct control. GPU supply for both tiers is subject to allocation, and the RTX PRO 6000 has seen reported GDDR7-driven price movement during 2026; the phasing above assumes allocation is secured ahead of each phase.

Site power commissioning depends on utility timelines at each location. And Phase 3's exit condition requires a partner studio willing to put a real production through the farm, which is a commercial commitment rather than a technical one.

8. Use Case: GPU Render Farm for Film, VFX and Animation

Rendering is the workload that drove the universal tier into existence, and it is the one most constrained by geography. This section describes the problem from the studio's side, what the farm provides, and how jobs are scheduled when one fleet has to serve both a feature production and a one-hour rush job.

8.1 The customer problem, stated precisely

A regional animation studio running a 22-minute episode has a render queue that, on its own hardware, takes three to four days. The queue is bursty: near-empty in pre-production, saturated in the final two weeks before delivery. Buying for the peak means buying capacity that idles for most of the production cycle.

Renting overseas for the peak means multi-terabyte uploads, a compliance review for any asset under an NDA, and no in-house engineer who can diagnose a failed frame without a support ticket in a different time zone.

Three specific costs follow from that, and they are the costs this service line exists to remove: capital tied up in peak-only capacity, elapsed time lost to international link throughput, and control lost when the render pipeline leaves the studio.

8.2 What the farm provides

Dedicated RTX PRO 6000 render capacity at Cyberjaya, Central Java and West Java, scheduled through the industry-standard render managers the studio already uses. Assets stay in-country. The submission interface is the studio's existing one, whether Deadline, Qube or OpenCue, so adopting the farm does not require the pipeline team to learn a new tool.

Latency to a Malaysian studio is in the tens of milliseconds, which is what makes interactive preview and iterative look-development workable rather than only final-frame batch work. AGATE GREEN states sub-50 ms latency for local studios as a design target.

8.3 Why capacity beats clock speed here

Rendering rewards memory capacity more than it rewards FLOPS. The reasons are mundane and decisive.

Complex scenes with heavy instancing, high-resolution textures, and large geometry sets either fit in VRAM or get streamed from disk. Streaming is slower by a large factor, and it also consumes the storage fabric that other tenants are using. A 96 GB card keeps the majority of production scenes resident. That is the difference between a farm whose throughput is GPU-bound and one whose throughput is I/O-bound.

The same capacity argument applies to the AI-adjacent rendering features that are becoming standard. Denoising, neural shaders, AI-assisted texture and lighting generation, and neural rendering models all consume VRAM on top of the scene itself. On a 24 GB or 48 GB card those features compete with the scene for space. On a 96 GB card they do not.

8.4 Reference job profiles

The following are reference designs used for capacity planning conversations. They describe the target configuration for each profile; they are not published benchmark results, and actual times depend on scene content, renderer version and shader complexity.

8.5 Scheduling and fairness

Two behaviours in a shared render fleet cause most of the friction.

The first is job starvation. A feature job that occupies a large share of the farm for days will starve a studio with a one-hour rendering need. AGATE GREEN addresses this with priority pools and pre-emption: reserved capacity for committed clients, a burst pool for short jobs, and a scheduler that will pre-empt checkpointed batch work in favour of a lower-priority-class job only when the batch work can resume safely.

Tile-level checkpointing is what makes pre-emption practical; without it, pre-empting a long render wastes the work already done.

The second is unbalanced tile splitting. Splitting a frame into tiles that finish at wildly different times wastes GPU time while the scheduler waits for the slowest tile. The farm's scheduler supports adaptive tile sizing and frame-level distribution, and AGATE GREEN tunes the split per production rather than applying one policy platform-wide.

8.6 Delivery, QA and the studio's own pipeline

Output is delivered to the studio's storage target of choice, including direct writes back to the studio's own on-premises storage over the regional fabric. Frame sequence integrity checking, checksum verification and re-render of failed frames are part of the service rather than a support request.

What the farm does not do is take over the studio's pipeline decisions. The colour management configuration, the renderer version, the output format and the naming conventions stay under the studio's control. The farm executes; the studio decides.

8.7 Commercial model

Render work is metered on the same principle as inference: by resource consumed, recorded from the scheduler, attributable to a project. The practical effect is that a studio can render a peak week and a quiet week and pay for the difference, without a reservation covering the whole year.

9. Use Case: AI Agent Cloud and LLM Serving

The same fleet that renders frames also serves models. This section covers the serving architecture, the deployment topologies that 96 GB of memory makes possible, how tenants are kept apart, and what agentic traffic changes about capacity planning.

9.1 The customer problem

A Malaysian enterprise deploying AI in 2026 typically ends up with four or five model providers, four or five sets of API credentials, four or five billing relationships, and no consolidated view of what any of it costs or who inside the company is using it.

Independent coverage of the regional market has documented this pattern extensively, and it is a governance problem more than a technical one: the organisation cannot answer "which models are in production, who can call them, and what did they cost last month" from a single place.

There is a second, less discussed problem. Most of that inference is running in another jurisdiction. For a bank, a hospital group or a government-linked entity in Malaysia or Indonesia, that is a data residency question that a procurement team will eventually escalate.

AGATE GREEN's AI Agent Cloud exists to answer both: one metered gateway, models running on hardware inside the region, and a usage record that the customer's finance and compliance functions can both read.

9.2 Reference serving architecture

An OpenAI-compatible surface is the pragmatic choice rather than an ideological one. It means an existing application can be pointed at the gateway by changing a base URL and an API key, with no code rewrite, and it means the customer is not locked into AGATE GREEN's SDK. Standard model-family endpoints (/chat/completions, /responses, /messages) and the standard bearer-token auth pattern are supported, and any OpenAI-compatible client library works unmodified.

9.3 Model sizing on a 96 GB device

The 96 GB device changes which deployment topologies are available. This is the part customers find most useful in practice, because it removes complexity rather than adding it.

The single most valuable line in that table is the third. A 70B-class model in FP8 on one GPU means no tensor parallelism, no NCCL tuning, no inter-GPU synchronisation in the serving path, and no cascade of failures when one device in a group misbehaves. Operationally, one model on one GPU is the easiest production arrangement there is, and this tier is the first at which it became true for the 70B class at reasonable cost.

9.4 Multi-tenant isolation

Section 4.3 described the mechanism. What matters for a customer is what it buys them.

A tenant on a MIG slice gets hardware-enforced separation of memory, cache and compute cores, plus a guaranteed share of quality of service. They do not share memory bandwidth with a noisy neighbour and they do not see another tenant's traffic. For regulated customers who would otherwise need a dedicated physical server to accept a shared platform, this is the difference between a shared-service model being acceptable and not.

AGATE GREEN's position on when MIG is and is not the right answer is stated plainly in Section 4.3: small models and embedding services on MIG, large models on whole GPUs. Customers who ask for a 70B model on a MIG slice will be told it does not fit, and offered a dedicated GPU instead.

9.5 Agentic workloads

Agentic patterns change the shape of inference traffic in ways that traditional capacity planning handles badly, and this is the main reason the AI Agent Cloud is a separate service line rather than a marketing label on the token service.

A chat request is one model call. An agent request is typically five to fifty: planning, tool calls, retrieval, verification, retries. The traffic is therefore spiky in a different way: token volume per user request is an order of magnitude higher, latency accumulates across the chain rather than being dominated by a single call, and a single slow tool can occupy a GPU slot for far longer than a chat completion would.

Three capabilities matter as a result, and AGATE GREEN provisions for all three: prefix and KV cache reuse, because agent chains resend overlapping context constantly and cache hits are the largest single lever on cost; per-request timeouts with graceful degradation, so that one stalled tool call does not consume a serving slot indefinitely; and fair-share scheduling across tenants, so that a tenant running long agent chains cannot crowd out short interactive traffic belonging to someone else.

Multimodal handling is native on this part. Vision, text and structured data inputs are processed on the same GPU, with the media pipeline handling video ingest where relevant. That makes it practical to build assistants that read documents, look at images and act on structured systems within one serving deployment, rather than assembling a separate vision stack.

9.6 Fine-tuning

The cluster supports parameter-efficient fine-tuning (LoRA and QLoRA) for model classes below roughly 70B, with one such job per GPU. Full-parameter fine-tuning of large models is an MI300X-tier workload, and Section 3.2 explains why.

For most enterprise use cases parameter-efficient tuning is sufficient: domain adaptation, format adherence, tone and terminology, retrieval-grounded behaviour. The 96 GB of memory per device means the base model, the adapter and the optimiser state can be held on one GPU for the common model classes, which keeps the fine-tuning operation as simple as the serving operation.

A fine-tuned model is versioned and traceable. Model registry, version pinning and rollback are part of the platform, not a customer responsibility, which matters when a compliance function asks which model version produced a given output six months ago.

9.7 Retrieval-augmented generation

RAG is the dominant production pattern in the region for good reason: it grounds model output in the customer's own documents and avoids the cost and risk of fine-tuning for every knowledge update. The cluster provides the retrieval layer (embedding models on MIG slices, a managed vector store, reranking) alongside the generation layer, so that the full retrieval path runs in-region.

Document ingestion, chunking strategy and index maintenance are the customer's design decisions. AGATE GREEN provides the compute, the vector store and the observability on the retrieval path. Vector store choice is tenant-selectable among pgvector, Milvus and Qdrant.

9.8 Model benchmarking

AGATE GREEN offers benchmarking of Mixture-of-Models architectures, meaning combinations of LLM, MoE, VLM and agent models, on regional infrastructure. In practice this is used by customers deciding which model to standardise on before committing to a production deployment, and by teams validating whether a smaller, cheaper model meets their accuracy bar for a specific task before defaulting to the largest available.

Running the evaluation on the same hardware that will serve production removes a common source of unpleasantness: benchmarks taken on a well-provisioned evaluation environment that the production deployment cannot reproduce.

9.9 What the customer gets, concretely

A customer onboarding onto the AI Agent Cloud receives: an API key with model allow-lists and budget limits; an OpenAI-compatible endpoint; a usage dashboard showing requests, tokens and attributable cost per key; audit logs of model invocation; and, for MIG-based tenants, documented hardware isolation. On request, a measured throughput and latency report for their own model and request distribution, run on the target configuration.

10. Workloads the Cluster Also Serves

The two service lines above account for the bulk of planned capacity. Four other workload families run on the same fleet and are worth describing, because they share the cluster rather than requiring separate infrastructure.

10.1 Financial services

Risk analytics, fraud detection, real-time transaction monitoring and regulatory reporting all benefit from in-region inference, because a cross-border round trip is a cost the application pays on every call. AGATE GREEN's corporate positioning has always been strongest in this sector, and the combination that matters here is Confidential Computing for model and data protection with in-region processing for residency.

Two patterns are in scope. Fraud and anomaly detection over streaming transaction data, served from small models on MIG slices with high concurrency and low per-call latency. And document-heavy work such as contract review, regulatory filing analysis and KYC, which is a RAG workload with a vision component and was one of the first patterns AGATE GREEN productised.

10.2 Life sciences and genomics

Genomics sequencing pipelines are among the largest published performance gains on this part, with NVIDIA claiming nearly 7× against the previous generation. Secondary analysis, variant calling and downstream interpretation pipelines are memory-hungry and parallelism-friendly, which is the profile this tier serves well.

Regulatory handling matters more here than in most sectors. Patient data residency is a hard constraint in both Malaysia and Indonesia, and the practical consequence is that any hospital group or research institution wanting to use AI in a clinical or research workflow needs the compute to be inside the country. This is the clearest case where an overseas option is not an option.

10.3 Industrial and physical AI

Omniverse-based digital twins, synthetic data generation for model training, robotics simulation and OpenUSD-based 3D pipelines run directly on this part, and are a stated NVIDIA workload target for it. For a manufacturer or an infrastructure operator in the region, the value is being able to develop and validate a physical-AI workflow against a digital twin without round-tripping large 3D assets to another continent.

Real-time photorealistic ray tracing matters here in a way it does not in offline rendering: a simulation that has to keep up with a physical process cannot be a batch job.

10.4 Engineering simulation, CAE and higher education

FP32 throughput of 120 TFLOPS per GPU, combined with 96 GB of memory, serves the medium-scale end of engineering simulation: CFD on models that were previously mesh-simplified for memory reasons, FEA, seismic and geoscience processing. These workloads do not need NVLink-scale coupling, which makes them a natural fit for this tier, and they are the reason several universities and research institutions in the region are in scope as customers.

10.5 Edge and small-language-model deployments

Small language models tuned for a specific vertical, deployed close to where the data is generated, are a pattern AGATE GREEN has already productised for three sectors.

Clinical documentation in healthcare, where an on-premises SLM generates patient summaries with retrieval over clinical guidelines.

Fraud detection in financial services, where SLM clusters analyse transaction patterns in real time and escalate anomalies to human analysts.

Visual quality control in manufacturing, where an edge SLM inspects product images on an assembly line with sub-500 ms latency targets.

These deployments are small by cluster standards, a handful of MIG slices or a single node, and they are usually customer-premises rather than in the AGATE GREEN data centres, with the central cluster providing training, tuning and benchmarking.

11. Security and Compliance

Security on a multi-tenant GPU platform is a layered problem, and a credible answer has to address all four layers. NVIDIA hardware is one of them; it is not a substitute for the other three.

11.1 Physical

Biometric entry, 24/7 surveillance, visitor logging and escorted access at each site. Physical access to a shared rack is the most basic threat to workload isolation, and it is handled by the facility rather than by the platform.

11.2 Network

Palo Alto IPS/IDS at the network edge, encrypted inter-node communication across the GPU and storage fabric, and tenant network separation. Inter-node encryption is the control that matters most for multi-node inference and distributed fine-tuning, because that traffic crosses shared switching.

11.3 Platform

Kubernetes role-based access control with quarterly recertification, network policies enforced at the pod level for workload isolation, and centralised audit logging with defined retention. A customer with access to the platform's own administration surface, without RBAC and audit, is a customer who can see other tenants' traffic patterns. Both controls exist to prevent that.

11.4 Silicon

NVIDIA Confidential Computing on the RTX PRO 6000 provides a hardware-isolated trusted execution environment protecting model weights and data while in use. This is the layer that addresses the threat model in which the infrastructure operator is not fully trusted, and it is the reason this part is suitable for regulated workloads that would otherwise require dedicated, single-tenant hardware.

11.5 Data residency and applicable law

The operational commitment is straightforward: data processed in Malaysia stays in Malaysia, and data processed in Indonesia stays in Indonesia. No workload is routed across the border without the customer's explicit instruction, and cross-border replication is opt-in rather than a platform default.

The relevant statutes are the Personal Data Protection Act 2010 in Malaysia and Law No. 27 of 2022 on Personal Data Protection in Indonesia. Both impose obligations that extend beyond where data is stored: lawful basis, purpose limitation, data subject rights, breach notification.

AGATE GREEN provides the infrastructure controls that support a customer's compliance posture; the customer's own compliance programme remains the customer's responsibility, and this document does not offer legal advice.

11.6 Supply chain

Firmware signing, verified boot on management controllers, and documented patch cadence for drivers, CUDA and the container stack. For regulated customers AGATE GREEN will provide the patch history and the software bill of materials for the platform stack on request.

12. Efficiency and Sustainability

AGATE GREEN's stated metric for this platform is tokens per watt rather than FLOPS per dollar, and the reason is that electricity, not silicon, is the dominant operating cost of an inference platform over its life. A GPU whose throughput per watt is 40% worse costs more to run for five years than the purchase price difference suggests.

12.1 What the design does about it

Three things, in descending order of effect.

Serving efficiency at the software layer. FP8 and FP4 serving, continuous batching, KV and prefix caching, and quantisation tuned per model. Published claims put the RTX PRO 6000 at up to 5× the LLM inference throughput of the previous generation on agentic workloads, which is a throughput-per-watt claim as much as a throughput claim.

Rack-level PUE. Liquid-cooled and hybrid liquid-air configurations at the 35–40 kW rack tier, which is where cooling overhead drops fastest. AGATE GREEN's stated position is that its green energy approach reduces energy consumption by up to 40% against traditional data centre designs; that figure is AGATE GREEN's own claim and the basis for it is a design comparison rather than a measured third-party audit, which we would rather say in plain terms than present as verified.

Scale-to-zero. Token metering is an efficiency mechanism, not only a billing mechanism. A platform that charges for idle GPU-hours has no incentive to release capacity; a platform that charges per token does, because unused capacity is a cost to the operator. This is the least visible of the three and probably the one that matters most over a five-year horizon.

12.2 Measurement and reporting

AGATE GREEN commits to publishing, per site, platform PUE, Tokens per Watt for the standard benchmark set, and the renewable energy share of consumed electricity. Published figures will be measured rather than modelled, and stated with their measurement boundary. Facility PUE and IT PUE are different numbers, and conflating them is the most common way efficiency claims become misleading.

The company's stated position is 100% green computing across the estate. For a customer whose own reporting obligations require verified renewable energy attribution, AGATE GREEN will provide the underlying energy source documentation for their consumed capacity on request. Where verification is not available for a specific site at a specific time, that will be stated rather than assumed.

13. Service Models and Access

Five ways to consume the platform. They differ in who operates what, and in how consumption is measured.

The on-premises path is delivered as a hardware, software and deployment project rather than as a service. Customers who want the RTX PRO 6000 capability inside their own building, with their own operational control, can buy the configuration described in Section 5 and have it deployed and integrated by AGATE GREEN's team. The MIG multi-tenant path is the inverse: minimum commitment, maximum isolation, no operational responsibility.

13.1 Getting started

Four steps. A capacity and workload scoping conversation, producing a recommended reference configuration from Section 5.5. A benchmark run on the target configuration with the customer's own workload. Commercial terms issued separately on the basis of that scoping. Onboarding, which for token and agent services is an API key and a base URL change, and for render is pipeline integration with the customer's existing render manager.

14. Support and Service Levels

Support is a commercial commitment, and its shape follows from where the engineering team sits. A regional model produces three things: regional response times, service level agreements scoped by service line, and a periodic review of whether the current tier still fits.

14.1 Support

24/7 technical support with regional engineers, on-site hardware response at all three sites, and spare parts held locally rather than shipped from overseas. Regional support is a deliberate cost: it is the reason a failed GPU is a same-day incident rather than a same-week incident, and it is also the reason AGATE GREEN is willing to publish response targets rather than only best-effort language.

14.2 What a service level agreement covers

Service level agreements are issued per service line and cover platform availability, ticket response times by severity, and hardware replacement times. They do not cover things outside the platform's control, such as customer-side network faults, third-party model behaviour, or a render job that fails because of a problem in a scene file, and AGATE GREEN would rather scope an SLA honestly than write one that appears to promise more than it delivers.

14.3 Capacity reviews

Customers above an agreed consumption threshold receive quarterly capacity reviews covering usage trend, headroom against committed capacity, and a recommendation on whether the current tier remains the right one. The point of the review is to catch the case where a customer has outgrown the RTX PRO 6000 tier for a specific workload and should be moved to the MI300X tier, or has over-provisioned a dedicated GPU where a MIG slice would serve.

15. Glossary

Agentic AI — AI systems that take sequences of actions, call tools and make intermediate decisions, rather than producing a single response to a single prompt.

Confidential Computing — hardware-based isolation that protects data and model weights while in use, not only at rest or in transit.

Continuous batching — a serving technique that admits new requests into a running batch rather than waiting for the current batch to finish, which raises GPU utilisation on inference workloads.

FP4 / FP8 — reduced-precision numeric formats. Lower precision means less memory traffic and higher throughput, at the cost of some numerical accuracy. FP8 is a common default for LLM serving; FP4 is used where the model tolerates it.

KV cache — the stored attention keys and values from earlier tokens in a sequence, reused on subsequent tokens. Cache reuse is the single largest performance lever in multi-turn and agentic serving.

MIG (Multi-Instance GPU) — hardware partitioning of one GPU into multiple isolated instances, each with dedicated memory, cache and compute, and guaranteed quality of service.

MoE (Mixture of Experts) — a model architecture in which only a subset of parameters is active for each token, which reduces cost per token but increases memory requirements.

NVLink — NVIDIA's dedicated GPU-to-GPU interconnect. Absent on the RTX PRO 6000 Server Edition, which runs cross-GPU traffic over PCIe Gen 5; the MI300X tier uses AMD Infinity Fabric instead.

PUE (Power Usage Effectiveness) — total facility power divided by IT power. A lower number means less energy spent on cooling and distribution relative to computation.

Prefix caching — storing and reusing the processed representation of a shared prompt prefix across requests, which is highly effective for agent chains and system-prompt-heavy applications.

RAG (Retrieval-Augmented Generation) — grounding a model's output in documents retrieved at request time, rather than relying only on the model's trained parameters.

Scale-to-zero — releasing compute when there is no traffic and paying nothing for idle capacity.

Tensor parallelism — splitting a single model across multiple GPUs, requiring frequent and high-bandwidth communication between them. On this tier it is limited by the absence of NVLink.

Token — the unit of text a language model processes, and the unit of consumption in token metering. Roughly, a token is about three-quarters of an English word.

Tokens per Watt — throughput of model tokens per unit of electrical power. AGATE GREEN's stated efficiency metric for this platform.

16. Contact

AGATE GREEN TECH SDN BHD (AGT)

Email: info@agatecap.com

Corporate website: www.agatecap.com

Platform website: agategreen.com

For platform, Render Farm and AI Agent Cloud enquiries, contact the address above and state the workload in the subject line. For investor relations, governance and financial disclosures, please refer to the corporate website.

Appendix A — Sources

AGATE GREEN published material

Corporate website: agatecap.com (company background, sites, service lines, security controls)

Platform website: agategreen.com (Token Factory, AI Agent Cloud and Render Farm service descriptions, deployment phases)

Enterprise SLM cloud solution description, agatecap.com/solutions

Third-party technical reference

Independent OEM and integrator documentation on RTX PRO 6000 server platforms, node power figures and rack density tiers — used for the node power and rack cooling tables in Sections 5.2 and 5.6

Independent regional market coverage of unified AI gateway platforms in Malaysia — used for the enterprise model-governance problem statement in Section 9.1

Statutes

Malaysia: Personal Data Protection Act 2010

Indonesia: Law No. 27 of 2022 on Personal Data Protection

Note on figures. All performance figures attributed to NVIDIA are NVIDIA's own published claims and have not been independently reproduced by AGATE GREEN. All items marked as reference design in this document are engineering targets and will be replaced with as-built figures following commissioning of each site. Figures attributed to AGATE GREEN as design positions rather than measurements are identified as such in the text.

Appendix B — Document Revision History

AGATE GREEN TECH SDN. BHD. maintains this document as a controlled publication. Each version is dated on release. The table below records the versions issued to date.

Only the most recent version should be relied on. Figures marked in Section 1.1 as reference designs are planning targets and may change between versions; readers should confirm current figures against the latest release before committing to a configuration.

Enquiries about a specific revision should be sent to info@agatecap.com with the version number in the subject line.