Building a Token Factory Using Bridge by Armada
How Armada's GPU-as-a-Service Management Platform Orchestrates AI Token Factories at Scale
The Token Factory Challenge
The phrase "token factory" has moved from marketing metaphor to operational reality. Neoclouds and sovereign cloud providers are assembling clusters of hundreds — or thousands — of GPU nodes, connecting them over high-speed interconnect fabrics, shared across dozens of tenants simultaneously: each with their own isolated network, dedicated storage quota, optional private NVLink or IB partition, and bespoke mix of training, fine-tuning, and inference workloads.
Many of these providers are realizing that margins are slim when renting infrastructure alone, and that charging customers for GPU-hours and other infrastructure-related usage metrics — such as network and storage usage — generates limited IRR. Instead, providers want to move up the value chain by representing the underlying infrastructure as tokens, thereby providing more value to their customers and freeing end users from the burden of building the necessary software on top of the raw hardware.
Creating a token factory involves integrating popular model catalogs, such as Hugging Face, NIM, and the Azure model registry, in addition to the ability to create a local model repository to store versioned models (fine-tuned, distilled, compressed, optimized, and so on). The fine-tuned model versions are created with successive fine-tuning cycles, which requires support for data ingestion, dataset creation, and the necessary infrastructure for integrating with storage vendors' hardware. It also entails creating shared model inference endpoint deployments — with support for aggregated/disaggregated KV-cache-aware routing — for efficient GPU utilization and TTFT (time to first token). Finally, it requires integrated billing support so that the provider can set up pricing for the tokens and charge users based on their token consumption.
Bridge by Armada was built to solve this. It is a GPU-as-a-Service management platform (without the need for deploying any agents on the target hardware) that automates the full lifecycle of a token factory — from low-level hardware discovery and provisioning, all the way to model fine-tuning and inferencing, while tracking the customer's token usage with integrated billing. This blog walks through exactly how it does that, layer by layer.
Armada's Bridge lets compute owners rapidly deliver secure, sovereign GPU-as-a-Service — with auto-discovery, hard multi-tenancy, one-click AI-ready clusters, LLMs, other open source and commercial AI platforms and applications, and one pane of glass for billing and observability.
Platform Architecture: Four Pillars
Bridge is organized around four functional pillars, each solving a distinct operational domain of a token factory. Together, the pillars form a complete management stack — no external glue is required.
| Pillar | What it covers |
|---|---|
| GPU Infrastructure (IaaS) | Auto-discover, provision, and scale GPU infrastructure across bare metal and VM with MIG support |
| Hard Multi-Tenancy & Isolation | Secure, hard-isolated tenancy for sovereign AI across CPU, network, GPU, storage, and VPC |
| Platform & AI Services (PaaS) | One-click AI-ready Kubernetes clusters, model catalogs, inference endpoints, Jupyter workspaces, workload scheduling, and MLOps |
| Observability & Token Monetization | Full-stack monitoring, automated fault resolution, billing (covering both infrastructure and tokens), and detailed usage reporting |
The four pillars map directly onto the operational lifecycle of a token factory: stand up the hardware, isolate the tenants, deliver the services, run it efficiently, and finally create a token factory that enables monetization at scale.
Pillar 1 — GPU Infrastructure
Every token factory starts with hardware. Taking racks of unprovisioned servers — freshly racked and stacked — to a fully operational, NVIDIA reference architecture compliant GPU cluster without weeks of manual effort is where Bridge begins.
Auto-discovery and onboarding
Bridge's Infra Manager performs automated hardware discovery from the moment nodes are connected to the management network, building a complete, accurate hardware inventory without manual entry. As the cluster grows, new nodes register themselves and enter the available pool automatically.
Day-0 network configuration
One of the most operationally painful steps in bringing up a GPU cluster is the initial network configuration: programming every leaf switch port, establishing BGP underlay, configuring VXLAN overlays, and setting up InfiniBand fabric parameters. Bridge automates all of it on Day 0.
Flexible compute instances
Once infrastructure is ready, Bridge supports four compute delivery models — operators can offer any combination to their tenants:
| Instance Type | Description & Use Case |
|---|---|
| Bare Metal | Exclusive GPU node access; tenant OS via iPXE boot. Ideal for distributed LLM training, high-performance HPC, and latency-sensitive inference requiring full hardware control. Multiple bare metal instances can be provisioned to construct a GPU "supercomputer". |
| Virtual Machines | KVM-based GPU-passthrough VMs with full lifecycle management. Suited for teams that need cloud-like flexibility without giving up near-bare-metal GPU performance. |
| Kubernetes (K8s) | AI-ready Kubernetes clusters with GPU operators and device plugins, KubeRay, KAI scheduler, JupyterHub, Kubeflow, and Slurm integration. Enables containerized training and serving pipelines. |
| MIG / Fractional GPU | Hardware-level GPU partitioning via NVIDIA MIG. Enables multiple small workloads — fine-tuning runs, Jupyter notebooks, dev environments — to share a single GPU efficiently. |
All instance types support automatic elastic scaling — Bridge monitors cluster utilization and provisions or releases nodes on demand, without operator intervention.
Pillar 2 — Hard Multi-Tenancy & Isolation
Multi-tenancy is the defining requirement of a commercial token factory — and the hardest to get right. Soft isolation (quota enforcement, namespace separation) is insufficient when tenants are running proprietary models and sensitive training data on shared infrastructure. Bridge implements hard isolation at every layer of the stack.
"Hard" isolation means the boundary is enforced in hardware and the data plane — not just in software policy. A misconfigured or compromised tenant OS cannot cross the isolation boundary.
Bridge's isolation strategy is defense-in-depth across Ethernet, NVLink, and InfiniBand fabrics, along with compute, GPU, storage, and WAN gateways.
This layered isolation model means Bridge can confidently host unrelated enterprises, government agencies, or research institutions on the same physical cluster — each with the security posture of a dedicated private cloud.
Pillar 3 — Platform & AI Services
Beyond infrastructure, token factories need to accelerate time-to-model-deployment. Bridge's Platform Manager and AI Services layer gives tenant teams — data scientists, ML engineers, and AI developers — a self-service interface to AI-ready compute, without requiring deep infrastructure expertise.
For tenant administrators: Platform Manager
Tenant administrators interact with Bridge's Platform Manager to configure resources and services for their organization:
- Resource allocation — assign GPU, CPU, and memory quotas to users and teams; monitor consumption through an integrated observability dashboard
- AI-ready Kubernetes — one-click K8s cluster creation, pre-configured with KubeRay (distributed training), KAI scheduler (GPU-aware job scheduling), JupyterHub (interactive notebooks), Kubeflow (MLOps), and Slurm (HPC batch workloads)
- Model endpoints — deploy and manage inference endpoints and Jupyter workspace endpoints for team members
- Access and keys — issue API keys, Python SDK credentials, and REST API tokens with scope-limited permissions
For tenant users: AI Services
Tenant end users — ML practitioners who may never interact with infrastructure directly — get a clean service experience:
| Service | Capability |
|---|---|
| One-click model deploy | Browse multiple model catalogs and the local model repo, select a model, and deploy it to an inference endpoint in minutes — no YAML, no Helm charts required. |
| Auto-configured inference | Bridge handles inference service configuration, API surface, usage policies, and scaling automatically on deployment. |
| Model-as-a-Service | Subscribe to shared AI services deployed by other teams or by the platform operator — enabling internal model marketplaces. |
| Fine-tuning-as-a-Service | Create or import datasets, use models from public model repositories such as Hugging Face or NVIDIA NIM, fine-tune models, and deploy them, all in a seamless manner. |
| Agent development | Build, test, and deploy agentic AI applications directly against live inference endpoints via REST API or Python SDK. |
| Jupyter notebooks | Spin up Jupyter environments with full GPU, fractional GPU (MIG), or CPU-only resources — scoped to tenant quota. |
| Usage and cost dashboard | Real-time view of GPU-hour consumption, instance costs, and budget tracking — giving teams financial accountability over AI spend. |
Pillar 4 — Observability, Day-2 Ops & Token Monetization
Standing up a token factory is a one-time event. Running it profitably for years is the actual challenge. Bridge's observability, Day-2 operations, and monetization capabilities are what transform a GPU cluster from a capital expense into a recurring revenue platform.
Full-stack observability
Bridge provides a single pane of glass for every operational metric across the token factory:
- Infrastructure-level telemetry and storage observability
- Performance benchmarking
- Standard integrations
Day-2 operations: keeping the token factory running
Once tenants are active, the operational burden shifts to keeping the cluster healthy, current, and fault-free:
- Automated fault resolution — Bridge continuously monitors anomalies and applies automated root-cause analysis (RCA). Many fault classes are remediated automatically without opening a support ticket.
- Cluster autoscaling — GPU cluster capacity scales elastically in response to workload demand. Bridge provisions additional nodes from the available pool and integrates them into active tenant clusters without service interruption.
- Rolling upgrades — firmware updates, OS patches, and platform software upgrades are applied in rolling fashion — one node or rack at a time — ensuring zero-downtime maintenance for running workloads.
- NVIS integration — Bridge integrates with NVIDIA Infrastructure Specialist (NVIS) installation for Day-2 takeover workflows, enabling deep GPU-level diagnostics and remediation for hardware faults that require vendor engagement.
- Proactive fault management — rather than reacting to outages, Bridge's fault management system uses telemetry trends to detect degradation before it becomes a failure, generating alerts and recommended actions proactively.
Token monetization: from cost center to revenue platform
Bridge includes built-in monetization infrastructure — the missing layer that turns raw GPU capacity into a billable token service:
- Flexible consumption models — tenants can consume GPU capacity as on-demand bare metal, reserved VM instances, or long-term PaaS clusters. Providers can utilize the infrastructure in an optimal way by creating and offering model endpoints, and charging their customers based on token consumption.
- Billing and usage reporting — detailed, per-tenant billing reports with token or GPU-hour granularity (both of which can co-exist). Usage data is accurate enough to pass directly to finance for customer invoicing.
- Admin console — operator-facing dashboard for OPEX management, tenant portal access, capacity planning, and commercial reporting.
Bridge's billing engine turns GPU utilization data into tenant-level invoicing data — giving token factory operators the financial infrastructure of a cloud provider without building it from scratch.
End-to-End: Token Factory Lifecycle on Bridge
Across the four pillars, Bridge covers the complete operational lifecycle of a token factory. Here is what that looks like end-to-end, from hardware power-on to tenant invoice:
- Hardware arrives — auto-discovery begins
- Day-0 network bring-up
- Tenant onboarding
- Workload deployment
- Set up a token factory
- Steady-state operations
- Billing and renewal
Who Bridge Is Built For
Bridge addresses a specific segment of the market: organizations that own or operate GPU infrastructure at scale and need to deliver it as a secure, monetizable service. Four archetypes dominate:
| Operator Type | Bridge Value Proposition |
|---|---|
| Neoclouds | Neoclouds that need a sophisticated dynamic on-demand multi-tenancy layer with IaaS, PaaS, and AI applications, models, and platforms that can be offered to their end users (tenants). |
| Sovereign cloud providers | National governments and regional cloud operators building sovereign GPU infrastructure need Bridge's hard isolation guarantees and air-gap-compatible on-premises architecture. Bridge meets sovereign data requirements that hyperscalers cannot. |
| Telecom and colocation operators | Telcos and colo providers with existing data center real estate can monetize spare GPU capacity by offering GPU-as-a-Service to enterprise tenants. Bridge's billing engine and tenant portal reduce the GTM barrier significantly. |
| Enterprise AI platforms | Large enterprises standing up internal AI factories — to serve multiple business units with shared GPU infrastructure — need the same multi-tenancy, isolation, and chargeback capabilities as a commercial cloud. Bridge delivers all three without a custom build. |
Conclusion
The token factory is not a product — it is an operational discipline. Hundreds of GPU nodes, terabytes of NVMe and parallel storage, Ethernet and InfiniBand fabrics, dozens of concurrent tenants with conflicting workloads and competing resource demands. Managing all this manually, or with point tools that solve one layer at a time, is not viable at scale.
Bridge by Armada is the platform that makes token factories operational. For organizations building or operating GPU infrastructure at scale, Bridge answers the question that raw hardware cannot: how do you turn a token factory into a service?
Bridge by Armada — GPU-as-a-Service management platform. Rapidly monetize GPUs with secure, sovereign GPU-as-a-Service. Make a new world happen.
