Kumo Engine Prerequisites

Prepare your Python environment, local storage, and data access before following an environment-specific setup guide. These prerequisites apply to Kumo running in your notebook or Linux Python process.

1. Python and Package Access

Use Python 3.12 for the documented Linux and notebook setup paths, with pip available in the environment that will run Kumo.

You need:

• Package access: Access to the Python package index that supplies Kumo Engine and its dependencies, including any required index credentials.
• Installation permissions: Permission to install packages into the interpreter used by your script or notebook, and to restart the notebook’s Python process when required. On Linux, use a dedicated virtual environment to isolate dependencies.

Choose one installation command for your environment and source:

Each integration option installs Kumo Engine with the dependencies for that connector. The Python import name is kumo.engine for all installation choices. Use the Kumo Engine build supplied or approved for your selected environment, Python version, and PyTorch/CUDA stack. These guides use Kumo Engine 1.0.0 on public PyPI. The published package targets Linux x86-64 and requires Python 3.11 or later; the documented setup paths below use Python 3.12. The matching native dependencies must also be available for your environment and PyTorch/CUDA stack. Follow your environment’s setup guide for notebook command syntax, storage, and identity.

2. Documented Environment Targets

Use the environment version listed for your deployment with the matching Kumo build. The environment version alone does not identify a compatible Kumo artifact.

Google Colab and SageMaker are suitable for small or introductory graphs and models.

Python compatibility alone is not sufficient for GPU execution. Use PyTorch and torch-geometric versions compatible with your Kumo build and CUDA target. Kumo no longer requires the separate pyg-lib or torch-scatter packages. Follow the runtime-specific installation steps in your setup guide, including the required PyTorch upgrade for Databricks 16.4. Otherwise, do not replace runtime packages independently unless Kumo release instructions provide a tested stack for your environment. Run the setup guide’s verification cell after installation to check imports, effective versions, and GPU execution.

3. Compute

The GPU must be accessible to the Python process running Kumo. Use the shared GPU Sizing guide to choose CPU, RAM, and scratch capacity from the total source Parquet size, then check GPU memory for your model.

4. Local Storage

Kumo jobs require local storage for execution. Place job working files and scratch data on that storage. Use local SSD storage, such as NVMe or SATA SSDs. Verify that the storage is local to the compute machine rather than relying on its device or mount name. A writable directory alone does not meet this requirement.

For the S3 workflow on AWS, use EC2 compute with local instance storage. Amazon EBS volumes are not supported as execution storage for these jobs. Source data can reside in S3; job execution still requires local storage on the compute machine.

For an AWS Databricks cluster that runs Kumo jobs, disable elastic disk and EBS volumes in the cluster configuration:

{
  "enable_elastic_disk": false,
  "aws_attributes": {
    "ebs_volume_count": 0
  }
}

After the cluster starts, inspect its effective configuration and confirm that both values remain set. A cluster policy can override requested settings. This configuration is specific to AWS Databricks and does not apply to Azure compute.

Verify the storage backing your configured directories. An /dev/nvme* device name is not sufficient evidence: AWS also exposes EBS volumes through an NVMe interface. Refer to Amazon EBS volumes and NVMe.

Provide a writable scratch directory with enough space for staged source data, graph indexes, intermediate files, and prediction outputs. Configure the directory for your environment:

• Linux: Choose a directory on your mounted local SSD and set it as Kumo’s scratch directory. See Linux working storage setup.
• Snowflake notebook: Choose a directory on the compute pool’s local storage. The setup example uses /tmp/kumoai-local; verify that this path is on the intended local disk before using it. See Snowflake working storage setup.
• Databricks notebook: Use /tmp/kumoai-local on Serverless GPU or /local_disk0/kumo-scratch on a classic dedicated GPU cluster. Confirm that the path is backed by local storage on your selected compute. Prepare a Unity Catalog volume for model and prediction files you need to retain. See Databricks working storage setup.

Confirm how long that storage survives notebook restarts or machine shutdowns. An artifact directory does not automatically provide durable storage. Follow Publish and Retrieve Models to retain an independent model copy and identify the other artifacts that need separate retention.

5. Credentials and Data Permissions

Choose a deployment and connector below. Follow its setup and connector instructions to configure credentials and data permissions.

Continue to Setup

Choose the guide for where your Python code will run:

• Google Colab Notebook Example for a small or introductory local-file workflow
• Snowflake Notebook Setup
• Databricks Notebook Setup
• Linux Machine Deployment Setup for local files, S3, GCS, BigQuery, Snowflake, or Databricks

These guides configure execution, storage, and identity. Connector creation follows setup.