Blog ▸ Supplying Inference Capacity to packet.ai: What Providers Need to Know
GPU Infrastructure
The same node that rents by the hour on GPUaaS.com can earn by the token on packet.ai. What the agent does on your hardware, what you keep, and when it beats a cluster contract.
Supplying Inference Capacity to packet.ai: What Providers Need to Know
GPUaaS.com Team
GPU Infrastructure
October 15, 2026
No items found.
A GPU provider can supply the same 8-GPU node to packet.ai for per-token inference instead of, or alongside, a committed cluster rental on GPUaaS.com; packet.ai runs the inference stack and support, the provider keeps the hardware, the site and the ops, and earns on tokens served rather than hours committed.
Most providers on the network know one route: list capacity, get matched to a buyer who wants a dedicated cluster for a term, sign a three-party contract, get paid by the hour. There is a second route for the same hardware. packet.ai sells inference by the token to developers who do not want a cluster at all, and it needs GPU capacity to serve those tokens on. This post explains how that route works from the provider side, what changes compared with a cluster rental, and how to decide which route a given node should be on. It is the supply-side companion to the B300 vs B200 buyer post, which covers the hardware packet.ai runs best on.
Key takeaways
packet.ai is the token channel of the hosted.ai GPU Commerce Platform. GPUaaS.com is the short-term and long-term cluster channel. A provider can be on both with the same fleet
On packet.ai the provider supplies nodes; packet.ai deploys an agent that runs the inference serving stack, routes requests and handles 24/7 human support for the developers using it
The provider keeps the land, power, hardware, financing and site operations. Nothing about ownership changes. There is no cost to apply or to list
Revenue follows tokens served, not hours committed, which rewards nodes that would otherwise sit partially idle between cluster contracts
Inference favours memory per GPU. H200, B200 and B300 nodes earn best; H100 and RTX PRO 6000 are viable for smaller models
A node can move between routes: on packet.ai while waiting for a committed buyer, then off when a twelve-month contract lands
◆ TWO ROUTES, ONE FLEET
Where packet.ai sits next to GPUaaS.com
Since August the hosted.ai group has been one GPU Commerce Platform with one supply side and three demand channels. The software side is an agent that runs on any GPU site plus a federated network across sites. The demand side is tokens through packet.ai, short-term and long-term clusters through GPUaaS.com, and a partner portal. A provider plugs into the supply side once and chooses which channels their capacity is exposed to.
On GPUaaS.com a buyer wants a whole node or cluster, dedicated, for a stated term. The routing post covers how that request reaches you and the committed vs on-demand post covers why committed terms are worth more to a provider with fixed costs. Both of those assume one buyer takes the whole allocation.
On packet.ai nobody takes the node. Thousands of developers send inference requests to an API, and those requests are served from a pool of provider capacity. Your node is part of that pool. You are not matched to a buyer; you are supplying throughput to a channel. Payment follows what your hardware actually serves.
The practical result is that a provider with sixteen H200 nodes might have twelve on a twelve-month GPUaaS.com contract and four on packet.ai, and move nodes between the two as contracts start and end. That is the configuration we see most often.
◆ WHAT THE AGENT DOES ON YOUR NODE
The software side, and what stays yours
Supplying to packet.ai means running the hosted.ai agent on the nodes you want in the pool. The agent handles model deployment, request routing, batching, scaling and telemetry. It is the piece that makes a bare node into an inference endpoint. You do not operate a serving stack, choose models, or manage developer accounts. packet.ai does that.
What stays with you is everything physical and everything commercial about the site. Land, power, cooling, the hardware itself, its financing, and the operations that keep it running. The agent needs the node to be up, networked and healthy; it does not need you to do anything else. If a GPU fails, the replacement window you committed to during vetting still applies, because a developer's request that lands on a dead GPU is a support ticket either way.
Support for the developers using packet.ai is handled by packet.ai, with humans on the line around the clock. That matters more than it sounds. On a cluster rental the buyer calls you when something breaks. On packet.ai the developer calls packet.ai, and you only hear about it if the fault is on your node. For a provider without a 24/7 support desk of their own, that is the main reason the token route is lower-touch than the cluster route.
Data stays where the node is. packet.ai serves requests from the region the node sits in, so a node in Europe serves European traffic. That makes residency-bound developer demand a reason to list APAC and European nodes, where the demand snapshot shows supply is shortest.
◆ CLUSTER RENTAL VS TOKEN SUPPLY, FROM THE PROVIDER SIDE
GPUaaS.com cluster
packet.ai inference
Who uses the node
One buyer, dedicated
Many developers, pooled
Term
Short or long commitment, fixed
Rolling, node can leave the pool
Revenue basis
Per GPU-hour, every hour of the term
Per token served
Who runs the software
The buyer
The hosted.ai agent
Who supports the end user
The provider, per the SLA
packet.ai, 24/7 human support
Best hardware
Any current part; fabric matters
High memory per GPU: H200, B200, B300
Fabric requirement
InfiniBand often required
Not required; single-node serving
Fill risk
Idle between contracts
Idle only if traffic is low
Minimum
One 8-GPU node
One 8-GPU node
Comparison as the routes operate in October 2026. Specifics vary by provider agreement. Contact for commitment terms.
◆ WHICH NODES EARN BEST ON TOKENS
Memory first, fabric last
Inference economics are different from training economics, and the hardware preference flips accordingly. Training wants many GPUs on one fabric. Inference wants as much HBM per GPU as possible, because the model and its KV cache have to fit, and the fewer GPUs a model needs the more tokens each GPU serves. That is why B300 at 288GB and B200 at 192GB are the parts packet.ai wants most, with H200 at 141GB close behind.
H100 nodes still serve well for models under about 70B parameters, and RTX PRO 6000 with 96GB per card is a good fit for smaller models where cost per token matters more than latency. A100 80GB is viable at the floor. What does not matter much is the inter-node fabric: most serving is single-node, so a provider whose nodes sit on Ethernet rather than InfiniBand loses nothing on the token route, where they would lose matchability on a contiguous cluster request.
That makes the token route the natural home for exactly the nodes that are hardest to place on the cluster route: non-contiguous Ethernet capacity, odd node counts, and parts that are lower in the current demand ranking for dedicated clusters. The one-node listing post argued that a single node is enough for GPUaaS.com; it is more than enough for packet.ai.
Cooling and density requirements are the same as for any node you would list. If it can run a sustained inference load without throttling, it qualifies.
2
routes for the same node: a committed cluster term on GPUaaS.com, or per-token inference on packet.ai. A provider can run both and move nodes between them as contracts start and end
hosted.ai GPU Commerce Platform, October 2026
◆ HOW TO DECIDE WHICH ROUTE A NODE SHOULD BE ON
A simple rule, and the two cases where it breaks
The rule most providers settle on: if a node has a committed buyer, put it on the cluster. If it does not, put it on packet.ai rather than leaving it idle. A twelve-month committed contract at the published band is the highest-certainty revenue a GPU can produce, which the idle capacity post covers in cost terms, and nothing on the token route changes that. The token route is for the gaps.
The first case where the rule breaks is a high-memory part in a region short of inference supply. A B300 node in Europe can earn on tokens at a rate that competes with a short-term cluster quote, because European inference demand is residency-bound and the pool is thin. In that case it can be right to keep the node on packet.ai and decline a three-month cluster term.
The second is a provider with no support desk. A cluster contract puts you on the hook for the buyer's calls. If you cannot staff that, the token route, where packet.ai's team takes the developer calls, may be the only route your operation can actually honour. Be honest with the team about that during vetting and the matching will reflect it.
Moving a node between routes is not instant. The agent needs to be deployed or the node needs to be handed over clean, and a node leaving the packet.ai pool should give notice so traffic can be rebalanced. Plan transitions a week or two ahead rather than on the day a contract starts.
◆ HOW TO GET STARTED
What the team needs from you
If you are already a vetted partner on GPUaaS.com, tell the team which nodes you want in the packet.ai pool, by model, count, region and site. The vetting carries over. If you are not yet on the network, apply as a provider and say in the form that you are interested in the inference route; the same review covers both.
What the team will ask for is a current inventory with memory per GPU, the network path out of the site, and your replacement window on a failed GPU. There is no cost to apply, no cost to list, and no exclusivity: a node on packet.ai can still be quoted for a cluster request if you want it to be.
The buyer side of this is covered in the buyer profiles post. The developers using packet.ai are the ones who never show up as a cluster request at all, and they are the demand the token route reaches.
Put idle nodes to work on tokens.
Tell the team which nodes you want in the packet.ai pool, or apply as a provider and ask for the inference route. No cost to apply or list.
packet.ai is the token channel of the hosted.ai GPU Commerce Platform: developers buy inference by the token through an API. GPUaaS.com is the cluster channel: buyers commit to dedicated nodes for a short-term or long-term commitment. Both draw on the same provider network, and a provider can supply both from one fleet.
Revenue follows tokens served from the provider's nodes rather than hours committed by a single buyer. A node earns when it serves traffic, which rewards capacity that would otherwise sit idle between cluster contracts. Specific terms are agreed with each provider and are not published.
The hosted.ai agent, which handles model deployment, request routing, batching, scaling and telemetry. The provider does not operate a serving stack or manage developer accounts. The provider keeps the hardware, site, power and operations; packet.ai runs the inference layer and the developer support.
High-memory parts earn best: B300 at 288GB, B200 at 192GB and H200 at 141GB per GPU. H100 serves models under about 70B parameters well, and RTX PRO 6000 suits smaller models where cost per token matters most. Inter-node fabric is not required, so Ethernet-only nodes qualify.
Yes, though not at the same moment. The usual pattern is to put a node on packet.ai while it has no committed buyer and move it to a GPUaaS.com cluster contract when one lands. There is no exclusivity on either route, and the vetting carries across both.
packet.ai, with humans available around the clock. The provider only hears about an issue if the fault is on their node, and the replacement window agreed during vetting applies. For providers without a 24/7 support desk, that is the main reason the token route is lower-touch than a cluster contract.
Last reviewed: 16 October 2026. Route descriptions reflect the hosted.ai GPU Commerce Platform as operated in October 2026. Demand ranking from the October demand snapshot. Provider terms are agreed individually and are not published. Apply as a provider on GPUaaS.com.
