8x RTX Pro 6000 Workstation: Camino Grando Benchmarks Explained
Real benchmark numbers from an 8x RTX Pro 6000 Camino Grando workstation: tokens/sec, prompt processing, power draw across GLM, Qwen, and DeepSeek models.
What is the Camino Grando and what does it cost?
The Camino Grando is a liquid-cooled workstation built around eight Nvidia RTX Pro 6000 Blackwell Server Edition GPUs, each with 96GB of VRAM, for a total of 768GB of VRAM in a single 4U chassis. It pairs those GPUs with a single AMD EPYC 9474F (48 cores, 96 threads) and 512GB of DDR5 RAM. At current pricing, the GPUs alone run about $15,000 each, so the eight cards represent roughly $120,000 of silicon before you count the chassis, cooling, CPU, or RAM. The unit tested weighs 121 pounds and can be rack mounted or run as a desktop tower.
The pitch isn’t a faster gaming rig. It’s a box that can hold and serve genuinely large open-weight models entirely in VRAM, locally, without touching a cloud API. That matters for anyone running multiple coding agents, long-context sessions, or a team sharing one inference server instead of paying per-token cloud bills.
TL;DR
- The Camino Grando packs eight RTX Pro 6000 GPUs (96GB VRAM each) into a 4U liquid-cooled chassis for 768GB total VRAM, paired with an EPYC 9474F CPU and 512GB of DDR5 RAM.
- A 433GB GLM 5.2 model loaded in about 4.5 minutes and consumed roughly 738GB of the 784GB available, around 95% of total VRAM for one model.
- Generation speeds ranged widely: GLM 5.2 hit 48 tokens/sec, Qwen 3 235B hit 85, and the fastest model tested, Qwen 3.8 Flash Next, hit 126 tokens/sec.
- Prompt processing speed varied even more, from about 2,200 tokens/sec on GLM 5.2 up to 12,600 tokens/sec on Qwen 3.8 Flash Next, which directly affects how fast large codebases get ingested.
- Capping GPU power at 300 watts instead of the 600-watt default barely changed throughput, showing the workload is memory-bandwidth bound, not compute-bound, during inference.
- The system has no NVLink, so all inter-GPU communication runs over PCIe, and testing showed that going from four GPUs to eight GPUs actually slowed one model down (58 tokens/sec on four cards versus 37 on eight for Qwen 3 235B).
- Idle power draw sat around 700 watts with a model loaded and doing nothing, and full 8-GPU load at 600 watts each would theoretically hit 4,800 watts, requiring multiple circuits or PSUs split across outlets.
One coffee. One working app.
You bring the idea. Remy manages the project.
How fast is it for a single developer or agent?
For a baseline single-user test (a 2,048 token prompt, 128 tokens generated), a single RTX Pro 6000 running a 30B-class model manages around 100 tokens per second on its own. Spreading a much larger model across all eight GPUs using tensor parallelism produces different numbers depending on the model:
- GLM 5.2 (433GB, MoE): 48 tokens/sec
- Qwen 3 235B: 85 tokens/sec
- DeepSeek V4 Flash: 102 tokens/sec
- GLM 5.3: 104 tokens/sec
- Qwen 3.8 Flash Next: 126 tokens/sec
The pattern is consistent: newer, more efficient architectures (Qwen 3.8 Flash Next specifically uses a newer Qwen 4 architecture despite the version number) generate faster, while the largest, most capable model, GLM 5.2, is also the slowest to generate tokens, though still usable at 48 tokens/sec for a single session.
Why does prompt processing speed matter so much?
Generation speed gets most of the attention in local LLM discussions, but prompt processing, the compute-bound stage where the model reads and encodes the input before generating anything, is arguably more important for coding workflows. Feeding an agent a large chunk of a repository means processing tens or hundreds of thousands of tokens before the model produces a single word of output.
Measured prompt processing throughput varied enormously across models:
- GLM 5.2: about 2,200 tokens/sec
- Qwen 3 235B: about 4,779 tokens/sec
- GLM 5.3 Flash: about 8,300 tokens/sec
- DeepSeek V4 Flash: about 8,700 tokens/sec
- Qwen 3.8 Flash Next: about 12,600 tokens/sec
At a 2,000 token prompt, time to first token ranged from about a quarter of a second (Flash Next) to nearly a second (GLM 5.2). At a 128,000 token prompt, roughly the size of a small codebase, the gap widened dramatically: Qwen 3.8 Flash Next reached first token in about 14.5 seconds, GLM 5.3 Flash in about 18 seconds, DeepSeek V4 Flash in about 26 seconds, and GLM 5.2 took around 50 seconds. Qwen 3 235B didn’t complete the longest prompt tests reliably during testing.
Generation speed, notably, stayed nearly flat as context length grew. Flash Next held around 120-122 tokens/sec even at 128,000 tokens of context, and GLM 5.2 held steady around 40-50 tokens/sec. None of the models tested showed meaningful slowdown in generation once the prompt was already processed, which suggests the VRAM capacity and bandwidth on this system are sufficient to avoid the usual context-length penalty seen on smaller setups.
Does the extra power draw actually buy more speed?
Testing at 300 watts per GPU versus the default 600-watt cap produced almost no difference in throughput. At 300 watts, GLM 5.2 generated 48 tokens/sec single-user and 111 tokens/sec at 32 concurrent users; Qwen 3 235B hit 85 tokens/sec single-user and 254 tokens/sec at 64 users. At 600 watts, those same multi-user numbers landed at 252 tokens/sec, statistically indistinguishable from the 300-watt result.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Measured power draw backs this up: at the 300-watt cap, the eight GPUs together pulled about 1,550 watts during GLM 5.2 inference. At 600 watts, they pulled about 1,700 watts, with a peak of 268 watts on any single card, well under the 600-watt ceiling. The conclusion is that inference on this workload is memory-bandwidth bound, not compute bound, so doubling the power ceiling mostly produces extra heat and, in testing, occasional instability rather than more speed. Running the cards capped at 300 watts also proved necessary in practice, since pushing 600 watts caused the machine to crash overnight during longer test runs.
Idle draw matters too: with a model loaded and the system sitting untouched, the GPUs pulled about 700 watts doing nothing. That’s a real ongoing cost for anyone planning to leave a system like this running continuously.
What are the practical bottlenecks of an 8-GPU PCIe setup?
The Grando has no NVLink, meaning every GPU-to-GPU communication happens over PCIe. The EPYC CPU provides 128 PCIe lanes, with seven GPUs getting a full 16 lanes and one getting 8, leaving only two M.2 slots for storage, which forced juggling models on and off disk during testing due to limited space.
This PCIe dependency shows up directly in benchmarks. Running Qwen 3 235B with tensor parallelism across four GPUs produced 58 tokens/sec, but spreading the same model across all eight GPUs produced only 37 tokens/sec. More GPUs made that particular model slower, because the communication overhead across PCIe outweighed the benefit of more parallel compute. This is the clearest illustration in the testing that raw GPU count doesn’t automatically translate to speed without a fast interconnect like NVLink.
Serving software also plays a large role. Using vLLM’s prefix caching, a 16,000-token conversation without caching enabled took GLM 5.2 5.9 seconds to first token, versus 0.83 seconds with caching turned on, a roughly 7x improvement. For agentic workflows that repeatedly resend large context, caching isn’t optional, it’s the difference between usable and painfully slow.
Is a system like this worth it?
For a single hobbyist chatting with one model, no. The value case is concurrency and model size: running a model with a 433GB footprint entirely in VRAM, serving multiple coding agents or several team members simultaneously, and avoiding cloud API costs and data exposure for large, sensitive codebases. Compared to something like Nvidia’s DGX Station, which uses faster high-bandwidth memory but tops out at 256GB of capacity, the Grando’s advantage is raw capacity: it can hold models the DGX Station physically cannot fit in VRAM at all, even if per-GPU memory bandwidth on the DGX is higher for smaller models.
At roughly $120,000 in GPUs alone plus the surrounding system cost, this isn’t a casual purchase. It fits organizations or power users who need one shared box running large open-weight models for a team, or a solo developer running many parallel agents whose combined token throughput resembles what a small team would generate.
Frequently Asked Questions
How much VRAM does the Camino Grando have?
768GB total, spread across eight Nvidia RTX Pro 6000 Blackwell Server Edition GPUs, each with 96GB of VRAM.
What models were tested on the Camino Grando?
GLM 5.2, GLM 5.3 (and GLM 5.3 Flash), Qwen 3 235B, Qwen 3.8 Flash Next, and DeepSeek V4 Flash, mostly run in NVFP4 (4-bit floating point) format optimized for Blackwell GPUs.
Does running GPUs at full power actually make inference faster?
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
No. Testing at 300 watts versus 600 watts per GPU produced almost identical throughput, because inference on this system is bound by memory bandwidth and PCIe communication rather than raw compute power.
Why doesn’t the Camino Grando use NVLink?
The RTX Pro 6000 Blackwell Server Edition cards in this configuration communicate over PCIe rather than NVLink, which limits multi-GPU scaling efficiency. In one test, running a model across four GPUs was actually faster than spreading it across all eight, due to PCIe communication overhead.
How much power does this workstation need?
At full tilt, eight RTX Pro 6000s at 600 watts each would draw 4,800 watts on GPUs alone, with the system’s four power supplies offering 8kW of combined capacity. Even idle, with a model loaded and no active requests, the GPUs alone pulled about 700 watts.
