Question 1

Is on-premises performance the same as your cloud?

Accepted Answer

Yes - it's the same hardware, so you get exactly the same speeds. What on-premises changes is location and ownership, not performance: the racks sit in your datacenter and you hold the keys.

Question 2

Does owning hardware actually pay off versus consuming managed tokens?

Accepted Answer

On-premises is a capital investment with a minimum footprint and a lead time, versus zero-capex, instant managed tokens. Whether it pays off is genuinely case by case - at sustained, heavy utilization over a multi-year horizon, owning the hardware can work out economically, but that depends on how hard you run it, so we'd model it with you rather than promise it. Often the deciding factor isn't cost at all: source code or data that cannot leave your building, a client or regulator that mandates it, or a strategic decision to own the infrastructure. Performance is identical to our cloud either way. If your case has no hard requirement and the economics are marginal, the Inference API or Dedicated Capacity is usually the better call, and we'll tell you so.

Question 3

Can we test before buying hardware?

Accepted Answer

Yes, and we recommend it. Prove the value on the shared Inference API first - it's technically identical - then optionally on a dedicated rack in our datacenter, before any capital outlay. A small pilot belongs in the cloud, not on-premises.

Question 4

What's the minimum viable size, and what scale of investment is this?

Accepted Answer

On-premises is enterprise-scale, strategic infrastructure - not a small install. The practical minimum is a multi-node deployment plus a Core Services Rack for the control plane, scaling in fixed increments, which represents a significant capital investment. That minimum is deliberate: it delivers real resilience (lose a node and you lose only a small fraction of capacity, with everything still running), room for both long- and short-context models, and burst headroom. If you're a small team or still proving the use case, run it on the shared or dedicated cloud first - on-premises makes sense once you're operating AI at scale and a requirement drives ownership.

Question 5

What do we need in our datacenter - space, power, cooling?

Accepted Answer

Standard datacenter conditions. The systems are air-cooled (no exotic liquid cooling) at high-density-rack power levels, in a standard rack footprint - so they slot into a datacenter you already have rather than needing a purpose-built facility. What you provide is space, power, cooling, and network; the platform itself - including its Kubernetes control plane and supporting services - ships and runs on the Core Services Rack we deliver, so you don't have to stand up or operate Kubernetes yourself. We run a site survey to confirm your exact power, cooling, network, and storage readiness before anything ships.

Question 6

How does an air-gapped deployment work - and how do you update or diagnose it?

Accepted Answer

SambaStack runs fully offline. In an air-gap, software and model updates are shipped and installed manually (you provide an artifact staging server and a local registry), and diagnostics happen via file transfer and web conference - we have no direct network access to your cluster. It works well and we have real experience doing it, but be clear that an air-gap trades some support responsiveness for total isolation: every update is a deliberate, manual step rather than an automatic pull.

Question 7

How long does deployment take?

Accepted Answer

Plan for around 90 days from contract to production, covering hardware delivery, installation, configuration, and model bring-up. Timelines vary with hardware order volume and availability, datacenter readiness on your side, and whether any new model architectures need bringing up - we commit to a firm date only after a site survey.

Question 8

Which models can we run - and can we bring our own?

Accepted Answer

Any model in our catalog runs on-premises, and a dedicated deployment can also run models beyond the public catalog that we bring up for you. Bring Your Own Checkpoint works too: fine-tunes of supported architectures load immediately. Fine-tuning itself runs on GPUs - you train, then load the weights onto your racks. Support for entirely new architectures is a commercial conversation.

Question 9

How do model updates work once it's in our building?

Accepted Answer

Each SambaStack release bundles new models we've brought up. You choose which to deploy, test them, and apply the allocation yourself - for example shifting nodes between two models. Reconfiguring a node (say, long-context to short-context) takes about 30 minutes. In an air-gap, these updates are delivered and installed manually.

Question 10

How does the platform handle contention when many users hit it at once?

Accepted Answer

The inference router lets you apply quality-of-service rules - prioritizing certain users or traffic, and rate-limiting individual users so no single one can starve the cluster. Requests queue rather than fail, and at the deployment's scale there's substantial headroom, so it's genuinely hard for one user to cause a problem. You hold these controls, since you operate the platform.

Question 11

Can we deploy in our own datacenter, or do you host it?

Accepted Answer

Both. We can sell the hardware into your datacenter, co-locate it for you, or offer colocation-as-a-service - whichever fits your control and operational requirements.

Question 12

Can you contractually guarantee that nobody outside our organization can see our data?

Accepted Answer

On-premises, air-gapped is the strongest possible position: you hold all the keys, we have no runtime access, and nothing leaves your network. That's exactly why it's offered - it's the bulletproof answer for the strictest secrecy and regulatory requirements. (For completeness: the KV cache lives in memory only and is never written to disk, but like every provider it isn't encrypted in memory - an industry-wide limitation, not specific to us.)

Question 13

How self-sufficient are we once it's installed?

Accepted Answer

Day to day, you run it: you own the hardware, hold the keys, and operate the platform on your own network. Where we stay in the loop is the model pipeline - bringing up new models, packaging release bundles, and shipping fixes - the same way you'd rely on any platform vendor for updates. The platform is also steadily moving toward more self-service, so more of that pipeline comes into your hands over time. Either way you get full operational control and data isolation, with an ongoing software relationship for models and support.

On-premises AI inference.
Full control, cloud speed.

When your data can't leave, this is the answer

When to choose On-Premises

Data that can't leave

A mandate to meet

Full control

Provider independence

A premium-token engine you own

Hardware

Software & Support

From contract to production

Consultation & site survey

Hardware delivery

Configuration

Production

The full catalog, in your building

The same dataflow architecture

Questions, answered straight

Not sure which is right?

Inference API

Dedicated Capacity

Ready to explore on-premises?

On-premises AI inference.Full control, cloud speed.