Requirements
Saptiva AI installs the platform on a Kubernetes cluster provided by the Client. Before the installation, Saptiva AI runs a preflight check that verifies each item on this list and reports what is missing.
Cluster
| Component | Requirement |
|---|---|
| Kubernetes | Version 1.32 or 1.33. |
| Certificate management | cert-manager 1.20 or later with an available issuer. |
| Storage | A default storage class for user volumes and artifacts. Snapshots (CSI) recommended for backup. |
| GPU nodes | NVIDIA drivers and GPU operator installed; GPU metrics (DCGM) exposed. |
| Monitoring | Prometheus operator (for platform metrics and alerts). |
Preflight checklist
What Saptiva AI checks before installing, and how you can check it yourself beforehand so the report comes out clean:
| Item | How to verify it | Expected result |
|---|---|---|
| Kubernetes version | kubectl version | 1.32 or 1.33 on the server. |
| GPU nodes visible | kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu | Each GPU node reports its number of devices. |
| Default storage class | kubectl get storageclass | A class marked (default). |
| Snapshots | kubectl get volumesnapshotclass | At least one class (recommended, not required). |
| Certificate issuer | kubectl get clusterissuer | An issuer in Ready state. |
| GPU metrics | The operator's GPU dashboard shows utilization per device | Each GPU reports. |
| DNS | nslookup studio.<dominio base> from the user network | Resolves to the cluster ingress. |
| Image registry | docker login <registro> or equivalent from a node | Read access from all nodes; about 200 GB free. |
GPU node firmware
On servers with recent-generation GPUs, the firmware profile determines whether the operating system can reserve the address space that the cards request at boot. A profile change made after the installation can leave all eight GPUs uninitialized even though nothing has changed in the cluster.
Real case (reference installation, 2026-07-11): someone changed the profile of a server with 8 GPUs to a graphics-oriented one, which disables I/O virtualization; the driver stopped loading on all eight cards and the node was left without compute until the virtualization profile recommended by the manufacturer was restored. Two rules that follow from this:
- Document the firmware profile each GPU node was installed with and treat it as part of the configuration, not as a free setting.
- If a GPU or an entire node stops reporting after a reboot, check the firmware before the cluster.
Indicative sizing
It depends on the number of concurrent labs and the models to serve. As a reference for a university lab: 8 GPUs of 96 GB (about 760 GB of GPU memory in total) allow about 10 to 15 active labs with shared GPU plus two or three language models in service.
Quick rule for estimating: add up the VRAM est. (Est. VRAM) of the models you want to serve (the model catalog shows it), add the VRAM of the default size multiplied by the concurrent labs you expect, and leave 15% free for peaks. If the result exceeds the capacity, serve fewer models or reduce the default size. Saptiva AI sizes with the Client based on its usage plan.
Network
- A base domain (for example
ia.<empresa>) with subdomains for Studio, the API, InferNode, and the lab panel, resolved from the users' network. - TLS certificates for those names, or an internal issuer that cert-manager can use.
- User access over HTTPS to the cluster ingress.
- If there is a corporate identity provider (SSO), connectivity from the cluster to it.
Image registry
All platform images are served from a registry inside the Client's network, mirrored by Saptiva AI and pinned by version. The Client provides the registry (or Saptiva AI installs it) and the space: about 200 GB for the platform plus whatever the models take up.
Internet egress
In an installation with controlled egress, these are the only external connections the platform may need, all of them optional and able to be turned off:
| Destination | Purpose | If not allowed |
|---|---|---|
| External model providers (Anthropic, Google, OpenRouter) | Agents that use models outside the infrastructure | Only local models through InferNode. |
| WhatsApp Business (Meta) | WhatsApp channel in workflows | The channel is disabled. |
| Public model registry | Download models to the catalog | Models are loaded from local media. |
Without any of them, the platform works fully with local models. See Air-gapped installation.