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 reads data and 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 read directly in streaming mode. |
| 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 input Parquet directly from object storage in streaming mode is slower than working from a local cache and requires HTTPS egress to the object-storage endpoint — mount the data or stage a local cache 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.
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.