> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server.

# GPU Sizing

> Size GPU compute, local SSD scratch, CPU, and RAM for Kumo Engine

This is the GPU sizing guide for Kumo workflows, which applies to Linux machines, Snowflake notebooks, and Databricks notebooks.

> **Note**
>
> Source Parquet size provides only a rough sizing estimate. Some graphs may require larger instances than shown on this page, depending on the final graph index size, for maximum performance.

## Start with Source Parquet Size

**S is the total size of the source Parquet files the graph reads.** Measure S in GiB and include all source tables used by the graph. S is not the final graph size or the size reported by a warehouse for its tables.

For example, if your graph reads 100 GiB of source Parquet, use **S = 100 GiB** in every calculation below. If you do not yet know the Parquet size, measure a representative export before choosing compute for the full graph.

## Resource Recommendations

Plan for at least **4 × S of free local SSD scratch** for most graphs. For graphs with many edges, use the recommended estimate of **8 × S**. Use the recommended CPU and RAM values when selecting compute.

| Resource          | Minimum                                                                                 | Recommended                                                 | Why it matters                                                                                                                                                                        |
| ----------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Local SSD scratch | 4 × S free space                                                                        | 8 × S free space for graphs with many edges                 | Graphs with many edges need more space for temporary files during preparation.                                                                                                        |
| vCPU              | 8                                                                                       | 32 for S below 200 GiB; 64 or more for S of 200 GiB or more | Encoding source data is CPU-bound. More CPU capacity helps keep graph preparation time manageable as data grows.                                                                      |
| RAM               | The larger of (12 GiB + 1 GiB per 10 high-cardinality categorical columns) and 10% of S | Meet both: at least 4 GiB per vCPU and at least 1.5 × S     | The minimum covers the process and category counts. Enough RAM per vCPU keeps more cores working during ingestion. RAM of about 1.5 × S helps keep graph indexes cached for training. |

These CPU recommendations target an encode stage of about 30 minutes. They are planning guidance, not a guarantee of total graph preparation or training time.

### Local SSD Scratch

Use **local SSD storage, such as NVMe or SATA SSDs**, for scratch. Prefer NVMe when choosing compute for large graphs. Network storage and cloud block volumes are not supported as job working storage. Confirm that your configured scratch directory uses storage local to the compute machine. A writable directory, mount name, or NVMe device name alone does not establish that.

For large graphs, compare storage throughput as well as capacity. Building the edge map and index is limited by disk performance, so enough free space alone does not ensure a fast graph build.

The table sizes free scratch space for one graph preparation. Allow additional space for retained graph snapshots, runs, and archives on the same filesystem. Keep completed models and outputs in retained storage as described in [Publish and Retrieve Models](/kumo-engine/1.0.0/user-code-guide/train-a-model/publish-and-retrieve-models).

### System RAM

High-cardinality categorical columns contain many distinct values, such as customer identifiers. For the minimum RAM calculation, add 1 GiB for every 10 such columns to the 12 GiB base, then compare that amount with 10% of S. Use the larger amount.

For recommended RAM, calculate both 4 GiB × vCPU and 1.5 × S, then choose a machine that meets the larger amount. For example, 32 vCPUs require at least 128 GiB by the CPU rule. If S is 100 GiB, the source size rule requires 150 GiB, so choose at least **150 GiB of RAM**.

With less than 4 GiB per vCPU, ingestion can still complete, but some cores may remain idle. Enough RAM to cache the graph indexes reduces the need to read them repeatedly from disk during training. System RAM is separate from GPU memory.

## Worked Sizing Examples

These examples use 20 high-cardinality categorical columns. Choose scratch capacity based on whether your graph has many edges, and meet or exceed the recommended CPU and RAM values.

| Source Parquet size (S) | Minimum free scratch | Scratch for graphs with many edges | Recommended vCPU | Minimum RAM | Recommended RAM                |
| ----------------------- | -------------------- | ---------------------------------- | ---------------- | ----------- | ------------------------------ |
| 100 GiB                 | 400 GiB              | 800 GiB                            | 32               | 14 GiB      | At least 150 GiB               |
| 300 GiB                 | 1,200 GiB            | 2,400 GiB                          | 64 or more       | 30 GiB      | At least 450 GiB with 64 vCPUs |

If you choose more vCPUs, recalculate RAM using the 4 GiB per vCPU rule. These examples size graph preparation and system memory. They do not establish how much GPU memory your model needs.

## Choose and Check GPU Memory

GPU memory needs depend on the model architecture, batch size, sampled neighborhoods, feature encoders, and prediction task. The CPU, RAM, and storage recommendations above do not specify a universal GPU memory minimum.

Choose a compatible NVIDIA GPU that is visible to the Python process running Kumo. After completing your environment's setup, inspect its total GPU memory:

```python
import torch

if not torch.cuda.is_available():
    raise RuntimeError("Select compatible GPU compute before training.")

for index in range(torch.cuda.device_count()):
    device = torch.cuda.get_device_properties(index)
    print(index, device.name, round(device.total_memory / 2**30, 1), "GiB")
```

This confirms GPU visibility and reports total GPU memory. It does not reserve memory or prove that a model will fit. In Snowflake and Databricks, size the compute that runs the notebook. Increasing the SQL warehouse size does not add GPU memory to that compute.

Start with a representative workload and a bounded [model plan](/kumo-engine/1.0.0/user-code-guide/train-a-model/training#model-plan). Observe peak GPU memory, system RAM, free scratch space, and the time taken for graph creation, training, and prediction before scaling up.

If training runs out of GPU memory, inspect other GPU activity and reduce the model plan's batch size or sampled neighborhoods before choosing a GPU with more memory. If graph preparation runs out of RAM or scratch space, increase those resources.

## Set Up Your Environment

Follow the setup guide for your deployment to install Kumo, configure scratch storage, and verify the runtime:

* [Linux Machine Deployment](/kumo-engine/1.0.0/get-started-with-kumo-engine/installation/linux-machine-deployment)
* [Snowflake Notebook](/kumo-engine/1.0.0/get-started-with-kumo-engine/installation/snowflake-notebook)
* [Databricks Notebook](/kumo-engine/1.0.0/get-started-with-kumo-engine/installation/databricks-notebook)