Rackspace and Together AI: managed inference needs a shared operating contract

On November 10, 2026, Rackspace announced conditional 2027 GB300 infrastructure for Together AI’s platform. GPU financing remains uncommitted; a separate enterprise-marketing letter is nonbinding. Announcement

The useful way to read this development is as a question about operating responsibility. An enterprise buys a completed task, not a machine's activity. If a customer-support answer arrives too late, or an automated workflow repeats an unsuccessful action, keeping every accelerator busy does not establish value. The following is an analytical framework for evaluating managed inference, not a claim about unpublished terms between the companies.

Three economic clocks

Consider three clocks running at different speeds: the useful life of the equipment, the duration of the capacity commitment, and the lifetime of a particular model configuration. A deployment can be technically successful while those clocks create a commercial mismatch. A customer may change its model before its capacity commitment ends. Conversely, traffic can grow before additional physical capacity is ready.

Neither problem is resolved simply by calling infrastructure managed. Buyers should ask which commitments can be resized, when a configuration can change, and who absorbs idle capacity during migrations. These questions should be answered before projecting savings from a lower unit price.

Together AI’s documentation distinguishes stable endpoints, model-and-hardware deployments, and execution configurations. That is product context, not confirmation of this project's final design. Product architecture The analytical implication is that an unchanged API address need not mean an unchanged operating environment. Version history and rollback decisions therefore belong in the commercial discussion as well as the engineering runbook.

Measure completed work, not accelerator activity

For procurement, a useful proposed measure is total operating cost divided by successful tasks completed within the required response time. Include reserved capacity, software, monitoring, fallback processing and human review in the numerator. Exclude failed attempts and unacceptable outputs from the denominator. This is a suggested evaluation method, not a disclosed metric from either company.

It changes the comparison. A faster model can still cost more per accepted answer if it triggers more retries. A slower configuration may be cheaper for overnight document processing but unsuitable for a live conversation. Mixing these two workloads into one average hides both conclusions.

Together's support guidance distinguishes token-based serverless charging from continuing dedicated hosting costs. Billing context Buyers should not assume that this general product guidance describes a privately negotiated contract. Instead, request the actual billing meter, minimum commitment and treatment of unused reservations, then replay representative traffic against them.

A practical test should include quiet hours, a sudden peak, long inputs and a failed dependency. Report median performance alongside tail latency and the fraction of work meeting the service objective. Peak benchmark throughput alone is an incomplete purchasing argument.

The failure handoff is part of the product

NVIDIA describes GB300 NVL72 as a liquid-cooled, rack-scale platform. Hardware context That fact says nothing by itself about application availability. For a managed service, the procurement question is how a physical fault becomes an actionable incident rather than an argument over ownership.

A hypothetical request slows down. The facility operator sees healthy power and networking, the inference operator sees a growing queue, and the application team sees users abandoning sessions. Each can be correct locally while the service fails globally. A sensible contract needs one incident coordinator, shared timestamps, agreed diagnostic access and explicit restoration priorities.

Change management deserves the same discipline. Before changing a model revision, numerical precision or batching policy, the buyer should define what counts as a regression. Test quality, response time and cost together. A performance improvement that reduces answer quality should not pass merely because one dashboard turns green.

Capacity is not a compliance certificate

Dedicated hardware should not be treated as proof of an enterprise's desired data controls. Ask separately about prompt retention, diagnostic logs, support access, encryption-key control and deletion verification. Trace the path taken by retries and fallback requests too. A preferred primary location offers little assurance if an emergency route has different rules.

These are diligence questions, not allegations that either provider lacks controls. The distinction matters: a procurement team needs evidence for its particular workflow, not an inference drawn from a partnership announcement.

What would demonstrate progress

The next useful evidence would be confirmed funding, an accepted production environment and customer-facing service terms. An evaluation can then move from architectural possibility to measured delivery. Until then, purchasing teams can prepare representative workloads, assign incident ownership and specify exit tests without assuming the planned capacity is already available.

The broader lesson is operational rather than financial: splitting infrastructure and inference can create specialization, but the customer still needs one coherent service. Its value will be demonstrated when workload economics, failure recovery and responsibility boundaries are tested together.