Jarvislabs is no longer just a place to rent a GPU

For years, Jarvislabs was easy to explain: pick a GPU, launch an instance, start working.

That simplicity is still important. But a GPU by itself is not much of a platform. Serious workloads often involve several machines and storage that outlives them. IP addresses have to survive pause and resume, and applications should not need somebody watching a dashboard to scale.

Some of this work is visible as a new page or button. Much of it is underneath: making launches, failures, pause and resume behave predictably.

The result is a Jarvislabs with four ways to run: a single VM when you want control, an InfiniBand cluster when one node is not enough, Serverless when you want an autoscaling API, and Managed Endpoints when you want us to own the serving recipe.

Private networking for VMs

The biggest change is networking.

Jarvislabs VMs can now join a Virtual Private Cloud. Each VM keeps a public interface for internet access and SSH, and gets a second private interface for traffic inside the VPC. The private address remains stable across pause and resume.

VMs in the same VPC can communicate over private IP addresses without exposing that traffic to the public internet. A training cluster can move data between its machines over the private network. Each customer's VPC is isolated, even when private address ranges overlap.

This network is limited to machines inside Jarvislabs. We do not currently offer a VPN or private interconnect to AWS or other clouds. A database running outside Jarvislabs still needs to be reached through its public endpoint.

Security Groups now cover the public interface. You can control which addresses and ports can reach a VM, reuse the same policy across several machines, and update it without restarting them. Traffic between VMs continues to use the private VPC network.

For services that do need a fixed address on the public internet, Reserved IPs now keep the same public IP across pause and resume. DNS records, partner allowlists and SSH configuration no longer need to change every time the machine comes back.

These features are currently available for VMs in our India regions. Reserved IPs cost $5 or ₹475 per month and remain billed while reserved, whether attached to a running VM or idle.

Shared Filesystems

GPU workloads accumulate datasets, checkpoints, model weights and environments that took hours to build. Shared Filesystems keep that data outside the lifecycle of one machine. We recently completed the work needed to support them on the new VM architecture.

A filesystem can grow to 10 TB and attach to multiple instances in the same region. It persists when compute is paused or destroyed and can be shared by a group of machines working on the same dataset or model.

Tools such as df now report the filesystem's real quota, so training jobs see the storage that is actually available to them.

Separating storage from compute also became the foundation for faster inference. Serverless deployments download a model once to persistent storage. New and replacement workers mount the existing weights instead of fetching the model again every time they scale up.

InfiniBand clusters

A VPC gets machines talking privately. Multi-node AI workloads also need a fast interconnect.

Jarvislabs now supports H200 SXM clusters connected over InfiniBand, with shared storage for the data and checkpoints every node needs. The machines are provisioned together as a cluster rather than as unrelated GPU VMs.

This gives teams a path from one GPU to multi-node training without changing clouds when the model or dataset outgrows a single machine. If you are planning a distributed training run, talk to us about the cluster size and capacity you need.

Serverless inference

You can now deploy an OpenAI-compatible inference endpoint on Jarvislabs with vLLM, SGLang or Ollama.

You choose the model, GPU, worker limits, concurrency and idle timeout. The platform creates persistent model storage, provisions workers, checks their health, routes requests to available capacity and removes idle workers. Set the minimum worker count to zero and compute scales to zero; the model remains on storage, ready for the next worker.

Most of our recent Serverless work has been on deployment and recovery:

• clearer deployment states and logs;
• download progress while a model is being prepared;
• support for gated and private Hugging Face repositories;
• image and audio inputs, including speech-to-text requests;
• automatic recovery when a worker becomes unhealthy.

H200 capacity is now available to Serverless workloads too. Larger models can span multiple GPUs per worker, while smaller workloads can use a single GPU and scale down when idle.

The API is OpenAI-compatible. Change the base URL and token, and keep the same client code.

Managed Endpoints

Serverless gives you control over the serving stack. Managed Endpoints remove most of that control deliberately.

For a managed model, our team selects and pins the GPU, serving image, precision, parallelism and runtime configuration. You pick a model from the catalog and deploy it. We own the recipe and improve it as we learn more.

The catalog currently includes DeepSeek V4 Flash, Gemma 4 31B, GLM-5.2, GLM-5.3 and GLM-5.3 Flash. New open models routinely depend on a narrow combination of framework version, precision and GPU architecture. The integration can take weeks. Managed Endpoints let us do that work once per model rather than asking every customer to repeat it. There is more detail in a separate post.

We kept the two separate rather than folding them into one product.

The jl command-line interface

The browser does not work well when the same operation needs to be repeated 100 times.

The jarvislabs Python package now includes the jl CLI. It can list availability and pricing, create a machine, SSH into it, transfer files, run a script, stream logs, pause the machine when the job finishes, and resume it later on a different GPU.

The command I care about most is this one:

jl run . --script train.py --gpu A100 --requirements requirements.txt

It creates the GPU, uploads the project, prepares the environment, runs the job, streams the output and pauses the machine afterward. A human can use it, but it was designed for coding agents too. jl setup can install a Jarvislabs skill so your coding agent learns the same operational workflow.

Earlier this year we cut launch time in our new architecture from about eight seconds to under two seconds. That difference matters when an agent is repeatedly launching and tearing down machines during an experiment. The full engineering story is here.

Operational fixes

The larger features are only part of this update. We have also worked on clearer launch errors, safer pause and destroy operations, and better visibility into failures.

Where this leaves Jarvislabs

The original promise remains: getting a GPU should be simple.

You can still rent a VM with root access. In our India regions, those VMs can use private networking, shared storage and a Reserved IP. The jl CLI makes these operations available to developers and coding agents.

The same choice runs through the inference products: Serverless when you want to own the stack, Managed Endpoints when you want us to.

Sign in to Jarvislabs to launch a VM or Serverless deployment. If you need help sizing an InfiniBand cluster or Managed Endpoint, email engineering@jarvislabs.ai.