25 October 2026 EN ES
The Serving Desk

The stack under your AI product — models, serving, and what it costs

Infrastructure Startups

HUMAIN MI355X: a cost-per-token test for GPU clouds

Score a new GPU cloud on live capacity, interconnect, stack support, price, egress, SLA, and cost per token before routing production traffic.

Illustration: HUMAIN MI355X: a cost-per-token test for GPU clouds

Turn a GPU-cloud announcement into a cost-per-token test by converting live capacity, interconnect, and price into cost per token and failure cost. The trade-off is live capacity against future capacity. For one GPU-second of compute, raw cost is the GPU-hour price divided by 3600 per response; divide by token count to get raw cost per token. Future capacity is a planning input, not a serving input.

Capacity is the only number that starts the test

On August 31, 2026, the AMD, Cisco, and HUMAIN Instinct MI355X GPU deployment was live in Saudi Arabia and supporting HUMAIN clients in the country and other markets.

The Saudi production deployment uses AMD Instinct MI355X GPUs, AMD EPYC CPUs, and Cisco's critical networking infrastructure.

HUMAIN offers that capacity as a GPU-as-a-service model for training and inference.

A later phase of up to 250 MW using MI400 GPUs is scheduled to begin in 2027, with the added capacity becoming available in the latter half of that year.

The AMD-Cisco-HUMAIN joint venture targets up to 1 GW of AI infrastructure by 2030.

Expansion lines are context, not score. A production engineer needs today's numbers: live GPUs, live megawatts, and whether the fabric can carry the serving path. Planned megawatts do not carry today's requests.

The scorecard turns a launch into a cost model

Run these checks before you route traffic. Each item is a number you can request in a call.

  • Live GPU count and live MW, not planned MW.
  • Interconnect topology, fabric latency, and failure domains.
  • Stack support: model, driver, and serving framework compatibility.
  • GPU-hour price, egress price, and reserved capacity terms.
  • SLA, maintenance windows, and replacement time for failed nodes.
  • Cost-per-token model: tokens per GPU-hour, egress, and failure cost.

Capacity says whether the offer absorbs your traffic. Interconnect says whether tokens arrive on time. Stack support says whether the workload runs. Stack support is a go/no-go item before price. Price and egress set the cost. SLA sets the cost of a bad hour.

Start with the serving stack you already run. Pick a model size, batch size, and token length that match production. Measure tokens per GPU-hour, multiply by GPU-hour price, and add egress if the response leaves the region. That is raw cost per token before failure.

A pilot should surface missing live GPU count, fabric latency, or egress before you commit traffic.

Latency and failure cost decide the route

The announced Saudi MI355X deployment uses a Cisco Silicon One and Cisco 800G optics-based Cisco N9000 Series fabric to interconnect MI355X GPUs.

In GMO's July 2025 simulated Fukuoka–Tokyo GPU-storage test, a 15 ms latency condition produced an approximately 12% performance decline for two trial tasks.

Use it as a fabric-latency proxy: if the serving path adds enough delay to drop throughput, GPU-hour price stops mattering. A node failure also costs lost requests, retries, timeouts, and possibly a user.

Compute failure cost before signing. Multiply expected downtime by tokens you would have served, add egress for retries or cross-region moves, and compare the result to the GPU-hour price. If failure cost exceeds the price spread, the cheaper cloud is not cheaper.

Set a routing rule. Send a small share of traffic to the new cloud, keep the old path available, and measure tail latency, tokens per GPU-hour, and error rate. If the new path beats the old path on cost per token and stays inside the latency budget, increase the share. If it misses any line, stop and request the missing number.

The pilot should fail fast

Treat a pilot as a short test with a stop threshold, not a demo. Choose a representative workload that is cheap to rerun, run it long enough to see variance, and record the numbers you would use in a routing decision. A passing pilot is a routing decision, not a press release.

Write the stop threshold before traffic moves: cost per token, latency, or failure cost. If the new cloud misses the line, do not average it away. Request the missing capacity, interconnect detail, or price term. Record the missing number, not just the result.

When the pilot passes, test scale: live capacity at peak, fabric at target batch size, and SLA across the failure domain. If all pass, the launch becomes a serving option. If not, keep the production traffic on the old path and request the missing capacity, latency, or price term.

Advertisement