Skip to content

Requirements

Hardware

Component Minimum
GPU recommended NVIDIA A100 or better; CUDA 12+
at minimum a multi-GPU cluster of A10s / L40s; CUDA 12+
RAM 240 GB
CPU 32 cores
Disk 1 TB — see Storage for sizing the working volume
Runtime Docker-capable environment

Training and inference scale linearly with the number of GPUs.

Storage

BaseModel writes its cache and checkpoints through ordinary file paths (POSIX), not through an object-storage API. Object storage (such as S3) on its own — without a filesystem layer — is not sufficient for the training working space. Storage plays three roles, each with different requirements:

Role Requirement
Input data (Parquet) May stay on object storage — either mounted as a filesystem (for example, a classic SageMaker training job) or, from 1.14, read directly from s3:// paths (see Reading Parquet from S3).
Training working space (cache + checkpoints) Must be a real filesystem and is performance-sensitive. Prefer a local instance disk (NVMe / EBS) over a FUSE-mounted object store.
Output artifacts May be written to object storage via a mounted output directory, or uploaded after training. Do not write checkpoints straight to s3:// during training.

Reading s3:// paths directly requires network access to the S3 endpoint. It also requires outbound internet access to the DuckDB extension repository: the image does not include the DuckDB httpfs extension, and DuckDB downloads it on first use. Without that access, mount the bucket as a filesystem instead. Without cache_path, every query reads from S3; with cache_path, the data is loaded into the local cache once and is not refreshed afterwards. Mount the data or use cache_path when throughput matters.

Sizing the working volume

Size the training working volume as:

≥ (total size of source Parquet files) + (model checkpoint size) + ~20% headroom

  • The cache materializes roughly 1:1 with your source data.
  • Checkpoints scale with the model, not the dataset — foundation- and scenario-model checkpoints dominate artifact size.
  • Persist the cache between runs: it is reused by successive scenario models trained on the same foundation model, saving significant time and cost.
  • DuckDB spill files for Parquet sources go to the system temporary directory by default. If the container's /tmp is small, redirect them as described in DuckDB temporary files.

Managed environments (SageMaker and similar)

Plan for classic training jobs that mount object storage and attach a local working disk, rather than notebook sessions — a notebook volume is often far smaller than the dataset, which makes cache-based training impossible.

Data

Minimum Structure

You need at least one event data source with:

Column Description
Entity ID Unique identifier, e.g. customer_id
Timestamp When the event occurred
Event attributes (min. 1) e.g. product_id, price, category

Adding entity attributes is recommended but not required:

Example table Example columns
Customer attributes customer_id, age, region, signup_date, segment
Item attributes product_id, category, brand, price_tier, product_name
Store attributes store_id, format, region, zip_code, city

Volume Guidelines

Requirement Threshold
Unique main entities ≥ 10 000 (e.g. customers, users)
Event volume ≥ 100 000 interactions per month
History — frequent interactions (banking, telco, FMCG, …) ≥ 3 months
History — infrequent interactions (fashion, insurance, automotive, …) ≥ 1 year

Supported Data Sources

  • Snowflake
  • BigQuery
  • Azure Synapse
  • Parquet
  • Databricks
  • Hive
  • ClickHouse

See Data Connect Sources for connection details.

Example Performance Profile

Real-world retail customer benchmark:

Metric Value
Events ~8 billion
Unique clients ~18 million
Unique products ~1 million
Foundation model training 12 h on 1× NVIDIA A100
Scenario fine-tuning (16 000 brands) 10 h on 1× NVIDIA A100
Inference throughput 2 718 clients/sec per GPU

Additional optimizations (Low‑Rank Adapter Tuning, model quantization) can further reduce cost at a slight quality trade-off.