Welcome to CNLab

This is the documentation hub for the CNLab platform. Whether you're a first-time evaluator or a platform engineer rolling out CNLab for a hundred-person team, this is the right place to start.

What CNLab is

CNLab is a cloud-native orchestration layer that turns your existing GPU infrastructure into a multi-tenant, self-service compute platform. It runs on top of Kubernetes and the NVIDIA Device Plugin, partitions GPUs in 1% blocks, and bursts to public cloud only when local capacity is full.

What CNLab is not

It's not a managed cloud — you keep ownership of your hardware and your data. It's not a model registry or a training framework — your existing PyTorch and TensorFlow code runs unchanged. It's not a billing platform, though usage data is exposed for any billing system you already use.

Where to go next

• If you want to try it now: read the Quickstart.
• If you're evaluating: read the Technology overview.
• If you have a security question: see Security & Compliance.
• If you want to talk to a human: Book a demo.

Quickstart: your first GPU slice in 5 minutes

This walks you from zero to a running JupyterLab on a sliced H100. It assumes you have a CNLab account; if not, ask your admin or request a demo.

1. Install the CLI

curl -fsSL https://cnlab.ai/cli | sh
cnlab login

2. Pick a profile

cnlab profiles list
NAME                GPU       SLICE   AVAILABLE
h100-25pct          H100      25%     ✓ now
h100-full           H100      100%    queue: 12 min
a100-50pct          A100      50%     ✓ now
l40s-block          L40S      10%     ✓ now

3. Provision a server

cnlab server create \
  --name first-experiment \
  --image pytorch:2.4-cuda12.4 \
  --profile h100-25pct \
  --storage 50gb

✓ Provisioning... ETA 18s
✓ Ready: https://nb.cnlab.ai/srv_01HX...

4. Open in JupyterLab

Click the URL or run cnlab server open first-experiment. Your workspace is mounted at /workspace. Anything you put there persists across restarts.

5. Stop when done

cnlab server stop first-experiment

CLI Installation

The CNLab CLI is a single static binary. Linux, macOS, and Windows builds are available.

One-line install (Linux/macOS)

curl -fsSL https://cnlab.ai/cli | sh

Manual download

Download the binary for your platform from the releases page and put it on your $PATH.

Login

cnlab login
# opens your browser for OIDC sign-in
# alternatively: cnlab login --token $CNLAB_TOKEN

Configure shell completion

cnlab completion bash > /etc/bash_completion.d/cnlab
cnlab completion zsh  > "${fpath[1]}/_cnlab"
cnlab completion fish > ~/.config/fish/completions/cnlab.fish

GPU Slicing

CNLab combines NVIDIA Multi-Instance GPU (MIG) hardware partitioning with software-level 1% Block partitioning. Both can run on the same GPU at the same time.

1% Block partitioning

The smallest allocation in CNLab is one block: 1% of the GPU's CUDA cores and 1% of its VRAM. This makes it possible to run 100 simultaneous lightweight tenants on a single H100 — a course of 100 students, for example.

MIG profiles

For workloads that need full memory bandwidth, CNLab uses MIG. Profiles available on H100 80GB: 1g.10gb, 1g.20gb, 2g.20gb, 3g.40gb, 4g.40gb, 7g.80gb. The scheduler chooses the smallest profile that meets the request.

Combining

A single 1g MIG slice can host up to 14 1% blocks. Use this for cases where you need both hardware tenant boundaries and very small per-user allocations — typical in shared university clusters.

Scheduling

The CNLab scheduler is a multi-criteria optimizer. It balances priority, deadline, fair-share, GPU type, data locality, and queue depth on every placement decision.

Priority & deadline

Jobs can declare a priority class (low, normal, high, critical) and an optional deadline. The scheduler reserves slices forward in time to meet deadlines and pre-empts lower-priority work when needed.

Fair-share

Long-term per-team usage is normalised over a 7-day rolling window. A team that ran heavy yesterday yields ground to a starved team today.

Pre-emption

Production inference pre-empts development training. Pre-empted work resumes from the latest auto-checkpoint when capacity returns.

Live Migration

Live migration moves a running workload from one node to another atomically. There is no checkpoint-restart; the CUDA context, GPU memory, and process state move in a single operation.

How it works

Phase 1: pre-copy memory pages while the source still runs, tracking dirty pages. Phase 2: a sub-second pause where final pages and CUDA context flush to the target. Phase 3: target resumes from the exact instruction.

When CNLab uses it

• Cluster-A overload: migrate to Cluster-B.
• Burst-out: migrate from on-prem to cloud.
• Auto-return: migrate cloud workload back to on-prem.
• Maintenance: drain a node before kernel update.

On-Premise Setup

CNLab installs as a Kubernetes operator. Minimum: one control-plane node + one or more GPU nodes. K8s 1.27+ required.

Prerequisites

• Kubernetes 1.27+ (CNLab can install it for you on bare-metal).
• NVIDIA Driver 535+, CUDA 12.x.
• NVIDIA Container Toolkit + Device Plugin.
• For MIG: H100 / A100 GPUs with MIG mode enabled.

Install

helm repo add cnlab https://charts.cnlab.ai
helm repo update
helm install cnlab cnlab/cnlab \
  --namespace cnlab \
  --create-namespace \
  --values values.yaml

Hybrid Cloud Setup

Configure CNLab to burst to AWS, GCP, Azure, Naver, or KT Cloud when on-prem capacity tightens. All five clouds use the same configuration shape; only credentials differ.

1. Add cloud credentials

cnlab cloud add aws \
  --account 123456789012 \
  --region ap-northeast-2 \
  --instance-types g5.xlarge,g5.2xlarge,p5.48xlarge

2. Configure burst threshold

cnlab policy burst \
  --threshold 0.90 \
  --provider aws \
  --strategy spot-then-on-demand \
  --max-cloud-budget 50000

3. Pin sensitive workloads

cnlab project mark sensitive-research --on-prem-only
# bursting is now disabled for this project