Agentic Commerce GPU Infrastructure: Sizing AI Shopping Agents

Every agentic checkout is at least three separate systems doing cryptographic and inference work before a payment clears. UCP discovers the product and builds the cart. ACP or a UCP checkout session executes the transaction. AP2 signs a chain of mandates proving the user actually authorized it. None of that is free on the backend: each step is an LLM call, a signature, or both, and it has to happen in the time a human would tolerate waiting for a page to load. That's the agentic commerce GPU infrastructure problem retailers are only starting to size for: a Black-Friday-shaped traffic curve that doesn't go back to sleep after the sale ends.

Salesforce measured $67 billion in global AI-influenced sales during Cyber Week 2025, with AI touching 20% of all digital orders worldwide (Salesforce, via CMSWire). That volume runs through inference pipelines most retail infrastructure teams built for page loads, not model serving. This post is the capacity-planning layer for that shift: what the protocol stack actually costs in backend compute, and how to size, isolate, and bill for it. For the general economics of why agent workloads burn more tokens than chat in the first place, see our breakdown of agentic AI inference cost; this post narrows that framework to the commerce-specific case of product search and checkout.

What AP2, ACP, and UCP Mean for Backend Inference Load

UCP handles discovery and cart building, ACP executes checkout inside a chat surface, and AP2 signs the mandates that prove a payment was actually authorized. A single purchase can invoke all three, and each one is backend compute: LLM calls for reasoning and ranking, cryptographic signing for every mandate, and multiple verification round trips before a payment settles.

The Protocol Stack: Discovery (UCP), Checkout Execution (ACP), Payment Trust (AP2)

The three protocols split cleanly by function, and each one lands on infrastructure differently.

UCP was co-developed by Google, Shopify, Etsy, Wayfair, Target, and Walmart, and launched at NRF 2026 with more than 20 endorsing partners including Adyen, American Express, Mastercard, Stripe, Visa, The Home Depot, Macy's, Best Buy, Flipkart, and Zalando (Google Developers Blog). It's explicitly built to work over REST APIs, Agent2Agent, and the Model Context Protocol, so a retailer can plug in whichever transport already fits their stack. If you're standing up the MCP side of that integration, our MCP server deployment guide covers the GPU-backed setup, and the MCP orchestration and autoscaling guide covers scaling that layer once agent volume grows past a handful of concurrent sessions.

Why Every Mandate and Checkout Session Is Also an LLM Inference Call

A minimal UCP transaction needs at least three separate HTTP round trips at the protocol layer before a mandate or payment step even begins: a discovery fetch of the merchant's manifest, a POST to create the checkout session, and a PUT to apply pricing or discount updates (Google Developers Blog). AP2 adds its own chain on top of that. Google's original description of the flow lays out the sequence plainly: a shopping request is captured in an Intent Mandate, the agent presents a cart and the user's approval signs a Cart Mandate, and the sequence "from intent, to cart, to payment" creates the audit trail that proves authorization (Google Cloud Blog). Each mandate is a cryptographically signed, tamper-evident credential, and the AP2 specification requires separate signing steps as the mandate chain closes from an open, constraint-bearing state to a closed, transaction-specific one (AP2 Protocol Specification).

That mandate chain isn't free to verify, either. Payment service providers translate AP2 mandates into network-level artifacts before a processor will act on them, and every translation is another round trip a checkout session has to wait on (LeadGen Economy). On May 26, 2026, the FIDO Alliance announced that AP2 and Mastercard's Verifiable Intent had both been contributed to it, moving the agentic-payments trust layer under the same body that standardized passkeys, with the explicit goal of an interoperable trust infrastructure instead of fragmented, proprietary verification schemes (FIDO Alliance). Every one of those signing and verification steps is a backend operation that has to complete inside a checkout session's latency budget, on top of whatever LLM reasoning produced the cart in the first place.

AP2 launched September 16, 2025 with more than 60 partners across payments and technology, including PayPal, Mastercard, American Express, Adyen, Coinbase, Salesforce, ServiceNow, Worldpay, and Etsy (Google Cloud Blog). At NRF 2026, Google CEO Sundar Pichai framed the reason a shared protocol had to exist at all: "The industry needs a protocol that works at global scale and takes into account the nuances of commerce journeys" (Google, NRF 2026 remarks). The scale problem isn't abstract. Google's own API token volume on Vertex AI grew from 8.3 trillion tokens in December 2024 to more than 90 trillion tokens by December 2025, an 11x increase in a single year, and consumer shopping agents are adding directly onto that same inference-demand curve (Google, NRF 2026 remarks).

ACP's Instant Checkout Shutdown vs UCP's NRF Launch: What Actually Survived

OpenAI scaled back Instant Checkout on March 4, 2026, roughly five months after launching it alongside ACP on September 29, 2025 (Forbes). The consumer-facing product didn't survive. The protocol itself is built to outlast any single implementer: ACP is an Apache 2.0-licensed, platform-agnostic specification, not a feature tied to one chat surface, so Stripe and other partners can keep it running even where OpenAI's own in-chat checkout flow is gone (Orium). That's a useful distinction for infrastructure planning. Don't size capacity around a single vendor's consumer product; size it around the protocol layer, because an open, license-free spec is what keeps getting implemented across merchants regardless of which chat surface wins.

UCP, by contrast, launched into a market that was already primed for it. It shipped January 11, 2026 at NRF with retailer heavyweights already signed on, and its explicit multi-transport design (REST, A2A, MCP) means it doesn't depend on any single agent product surviving either. For a platform sizing GPU capacity today, the practical read is: build for the protocol traffic pattern (discovery calls, cart sessions, mandate signing), not for any one company's chat product, because the product layer above the protocol is still shaking out while the protocol traffic keeps growing underneath it.

Sizing GPU Capacity for Always-On Product Search and Personalization Agents

Shopping agents don't wait for a human to open a browser tab. They crawl, compare, and re-query on a schedule set by the agent framework, not by store hours, which turns "peak traffic" from a predictable holiday spike into a baseline that's already elevated every day of the year.

Continuous Load vs Bursty Traffic: Why Shopping Agents Don't Sleep Between Peak Spikes

Retail bot traffic from AI systems rose 5.4x over the course of 2025 across roughly 200 retail and e-commerce sites tracked in one analysis, and for every single visit OpenAI's systems deliver to a retail site, those same systems perform 198 crawls against it (PPC Land). That crawl-to-visit ratio matters for capacity planning because crawls aren't free either. Every one of those requests can trigger a discovery fetch, a product comparison query, or a personalization pass, and none of it shows up as a "session" in the way traditional web analytics count traffic.

The growth curve on top of that baseline is steep. Adobe Analytics found AI-driven traffic to US retail sites grew 805% year-over-year on Black Friday 2025, and shoppers who arrived from an AI service that same weekend saw a 38% conversion lift (Adobe Analytics, via eCommerceGuide). By Q1 2026 that growth hadn't leveled off: Adobe measured a 393% year-over-year rise in AI-driven traffic to US retail sites, based on more than a trillion visits analyzed (Adobe Analytics, via TechCrunch). Retailers that deployed branded AI agents grew sales 32% faster over Cyber Week 2025 than retailers that didn't (Salesforce, via CMSWire), which is the commercial case for building this out, but it's also exactly why the traffic keeps compounding instead of plateauing.

The scale of the underlying event traffic is already enormous even before you isolate the AI-specific share of it. Vercel's own network alone handled more than 115.8 billion total web requests over Black Friday-Cyber Monday 2025, up 33.6% year-over-year, with peak load hitting 518,027 requests per second on that single infrastructure provider (Vercel). That's the traffic through one platform's edge, not an industry total, and it's still a useful proxy for how much load a single provider's retail customers alone can generate in one weekend. Layer a continuously-crawling, 198x-multiplier agent traffic pattern on top of a curve like that, and the capacity question stops being "how big is our Black Friday spike" and becomes "how much of our baseline load is now agents that never stop querying."

Consumer trust hasn't caught up to that volume yet, which matters for how you should read this traffic. Only 9% of consumers say they'd let an AI agent initiate and complete a purchase autonomously within defined boundaries (Accenture, via AI News). Most of today's agent traffic is comparison shopping, discovery, and personalization on a human's behalf, not fully delegated purchasing. That's actually the harder capacity problem: it means the bulk of the inference load is in product search and ranking, running continuously and at high volume, while checkout volume itself stays comparatively small. Split your capacity plan on that line, not on total request count.

The Three-Stage Inference Pipeline Behind Agent Product Search: Retrieval, Ranking, Reasoning

A single agent product search isn't one model call, it's a pipeline. Retrieval pulls candidate products from a vector index or a UCP catalog manifest. Ranking scores those candidates against the shopper's stated constraints, often with a smaller reranker model rather than the full LLM. Reasoning is the final LLM pass that turns ranked candidates into the actual response the agent hands back, whether that's a comparison table, a recommendation, or a cart proposal.

Each stage has a different GPU profile. Retrieval and reranking are cheap per call but run on every single search, including the 198 crawls-per-visit volume described above. Reasoning is the expensive stage per call, but it's also the stage where model choice matters most for output quality, since it's producing the text or structured cart data the shopper (or the shopper's agent) actually acts on. tau-Bench, the multi-turn agentic tool-calling benchmark built on Sierra's retail domain, tests exactly this kind of pipeline: a model has to maintain state across multiple tool calls, handle a user correction mid-task, and complete a task like an order change or a refund, not just answer one query correctly in isolation (tau-Bench methodology, covered in our tool-calling benchmark guide). That's a closer proxy for a real shopping agent's tool-calling loop than a single-turn accuracy benchmark, and it's worth running against your own model choice before committing capacity to it.

Concurrency Math: From Token Multiplier to a GPU-Hour Capacity Budget

Here's a worked example, using our own published throughput numbers as the anchor rather than a vendor spec sheet. In an internal case study, a single H100 SXM5 running Llama 3.1 8B Instruct in FP8 with chunked prefill served roughly 230,000 chat-style interactions per hour at a TTFT P50 of 78ms (100 concurrent AI agents case study). Treat one agent product-search reasoning call as roughly equivalent to one of those interactions.

Say a mid-size commerce platform sees a baseline of 40,000 agent-initiated product searches per hour, spiking to roughly 250,000 per hour during a flash-sale window, a spike shape consistent with the 5-6x traffic multiples retailers already see during BFCM-scale events. At 230,000 interactions per GPU per hour, that peak alone needs just over one H100, so two GPUs with headroom covers it. Checkout volume runs far lower by the 9%-autonomous-trust figure above, so assume 5% of searches convert into an agent-initiated checkout flow: 2,000 per hour baseline, 12,500 at peak. Checkout and mandate generation calls are heavier per request (larger model, structured JSON output, multiple signing round trips), so budget them separately rather than folding them into the search-stage GPU count. That separation, cheap high-volume search capacity plus a small dedicated pool for the expensive low-volume checkout path, is the core sizing decision this section is building toward, and it carries directly into the latency and billing sections below. For the underlying token-volume math behind why agent calls cost more than a single chat turn, see our agentic AI inference cost breakdown, and for the CPU-side bottleneck that shows up once you add tool calls and orchestration on top of this GPU count, see our CPU-to-GPU ratio guide for agentic workloads.

Pricing fluctuates based on GPU availability. The prices above are based on 21 Jul 2026 and may have changed. Check current GPU pricing → for live rates.

Serving Millions of Agent-Initiated Checkouts Without Latency Spikes

Checkout is the low-volume, high-stakes half of this traffic. A shopper (or their agent) waiting on a cart or mandate signature notices a 2-second stall in a way they don't notice a slightly-stale product ranking, so this is where latency budgets, tenant isolation, and GPU billing model all have to be deliberate rather than inherited from your search-stage setup.

Latency Budgets for Real-Time Cart and Mandate Generation

Cart and mandate payloads are schema-bound JSON, which means the constrained-decoding backend you pick matters as much as the model. Older backends like outlines add 5-60% latency overhead depending on schema complexity, with deeply nested schemas (the kind an AP2 Cart Mandate or an ACP checkout payload can produce) landing at the high end of that range. Modern backends like xgrammar shift most of that cost into a one-time grammar compilation step of roughly 20-50 milliseconds and reduce per-token overhead to near zero, and grammar caching eliminates even that compilation cost on repeated calls against the same schema (structured output and function calling inference guide). Since a checkout agent repeats the same mandate schema on every call by design, this is close to a free optimization: configure it once and the compilation cost amortizes to nothing.

Set your latency SLO the same way you would for any interactive workload, not looser just because a signing step is involved. Interactive chat targets a 300ms TTFT P99 with a 50ms inter-token latency target; a voice or highly interactive agent surface tightens that to 150ms TTFT because downstream steps (text-to-speech, or here, mandate signing round trips) eat into the same total budget the shopper actually feels (LLM inference SLO guide: TTFT, ITL, and P99 latency budgets). Treat a checkout agent's mandate-generation call closer to the tighter end of that range: the LLM reasoning that assembles the cart is only one leg of the round trip, and the cryptographic signing and multi-party verification steps described earlier in this post add real wall-clock time on top of it, before the shopper ever sees a confirmation.

Multi-Tenant Isolation for Retailer, Platform, and Agent Traffic

A commerce platform serving UCP or ACP traffic on behalf of multiple retailers has the exact multi-tenant problem any shared inference endpoint has, plus a compliance wrinkle: a slow or noisy retailer tenant shouldn't be able to degrade another retailer's checkout latency, and a retailer's transaction data has to stay isolated from every other tenant sharing the GPU pool. GPU batch slots aren't divisible. A single H100 SXM5 running a 70B-class model in FP8 might handle 40-80 concurrent sequences via continuous batching, and if one tenant's traffic spike consumes 30 of those slots, everyone else on that GPU is competing for what's left (multi-tenant LLM serving guide). Per-tenant token quotas and fair-share scheduling, enforced at the gateway before a request ever reaches the inference server, are what keep one retailer's Black-Friday spike from becoming every other retailer's latency incident on the same shared pool.

Matching GPU Billing to Checkout Traffic Patterns: Spot, Dedicated, and Burst Capacity

Split your billing model along the same line you split your capacity plan: dedicated for checkout, spot (or a mix) for search and personalization. A mandate-signing session that gets preempted mid-flow doesn't just fail gracefully, it leaves a half-signed transaction and a shopper staring at a stalled agent. That's not a workload you put on spot capacity. Live Spheron pricing at the time of writing puts H100 SXM5 on-demand at roughly $4.06 per GPU per hour, with spot running about $1.49 per GPU per hour (Spheron GPU offers API), a gap wide enough that it's tempting to push everything to spot. Resist that for the checkout path specifically, and reserve it for the product-search and personalization stage instead, where a restarted node just means a slightly delayed re-query, not a broken transaction.

For a rough monthly budget on the split described earlier in this post: one dedicated H100 on Spheron running the checkout and mandate path around the clock runs about $2,920 a month at the on-demand rate above. Add two more dedicated H100s covering an 8-hour daily peak search window, and a single spot H100 covering the remaining 16 hours of lower-volume search traffic, and the full commerce-agent inference stack for the mid-size scenario modeled above lands in the neighborhood of $5,500-$5,600 a month. That's an illustrative model, not a quote, sized to make the search-versus-checkout split concrete rather than to predict any specific platform's bill.

Pricing fluctuates based on GPU availability. The figures above are based on 21 Jul 2026 and may have changed. Check current GPU pricing → for live rates.

As agent volume scales past what a handful of dedicated instances can absorb, autoscaling triggers tied to queue depth rather than fixed schedules keep that budget proportional to actual traffic instead of provisioned for a peak that only happens a few days a year; our MCP orchestration and autoscaling guide covers the queue-based scaling patterns for that. For the broader compute playbook this post's checkout-specific sizing sits inside, see how to build GPU infrastructure for AI agents.

Agentic commerce is still early: 9% autonomous-purchase trust and a five-month product that didn't make it both say the consumer-facing layer is unsettled. The protocol traffic underneath it isn't waiting for that to resolve. Size for the crawl volume and the mandate chain you can already measure today, and treat the rest as headroom you'll need sooner than the adoption curve suggests.

AP2 and UCP traffic already looks like a capacity-planning problem, not a future one. Spot instances cover the always-on product search load; dedicated capacity covers the checkout path that can't afford a preemption mid-mandate.

Check GPU pricing and availability on Spheron →