HeadObject call against any object, you instruct LOTA to fetch the complete object from backend storage and place it into the distributed NVMe cache on your Nodes without transferring a response body to your client.
This eliminates the “cold start” latency penalty that occurs on first reads. Training jobs with a warm cache can see 30% to 50% faster first epochs, inference services can achieve sub-second Time-To-First-Token for large models, and checkpoint restores complete at full cache speed from the first byte.
Other benefits include:
- Zero client bandwidth.
HeadObjectreturns only headers. All cache-fill traffic stays inside the backend CoreWeave network. - No SDK changes required. Works with any S3-compatible tool or SDK (AWS CLI, Boto3, s3cmd) with no custom headers or proprietary extensions.
Use cases
The following use cases benefit from pre-staging the LOTA cache:How it works
Pre-staging uses aHeadObject call with a Range: bytes=0-0 header as the trigger. When LOTA receives this request:
- The object storage gateway authenticates the request.
- The object storage service returns the object’s metadata (size, content type, ETag, last modified date) in the response headers, exactly as a normal
HeadObjectcall. - LOTA fetches the complete object from the backend storage and writes it into the distributed NVMe cache across the Nodes in your CKS cluster.
- LOTA serves future
GETrequests for that object directly from the cache.
HeadObject doesn’t return a response body, pre-staging consumes minimal client-side resources and bandwidth. The cache fill happens entirely within the CoreWeave infrastructure.
Whole object caching
Pre-staging caches the entire object, since aHeadObject call with a Range: bytes=0-0 header caches the complete object. Byte-range pre-fetching of partial objects isn’t supported. However, the LOTA cache serves range-reads as usual.
LOTA endpoint required
Pre-staging works only through the LOTA endpoint (http://cwlota.com). HeadObject calls sent to the primary endpoint (https://cwobject.com) return metadata but don’t trigger a cache fill.
Billing and storage tier behavior
AHeadObject request with bytes=0-0 counts as an object access, triggering the transition of an object from the Cold or Warm tier to the Hot Storage Pricing tier. If bytes=0-0 isn’t included in the HeadObject request, no tier transition occurs.
Finite cache capacity
Total LOTA cache capacity scales with cluster size, with each Node contributing 3 TiB to the distributed cache by default (for example, a 30-Node cluster has approximately 90 TiB of cache). Pre-stage only the objects your workload will access in the near term. The cache uses LRU (Least Recently Used) eviction, so pre-staging more data than the cache can hold evicts objects that other active workloads may depend on. Use the CAIOS LOTA dashboard to monitor cache utilization and hit rates. To request a larger cache allocation, contact CoreWeave support. Before pre-staging a large dataset, check that the dataset fits in the cluster’s cache. Multiply the number of objects by their average size to get the size of the working set, then multiply the per-Node cache capacity by the number of Nodes to get the total cache capacity of the cluster. For example, suppose a cluster has approximately 30 TiB of cache in total. A dataset of 200,000 objects averaging 8 MB is a working set of about 1.6 TB, which fits. A dataset of 5 million objects averaging 8 MB is a working set of about 40 TB, which does not. When the working set is larger than the cache, LOTA evicts objects that the same pre-stage pass still needs, and pre-stage requests can time out or fail with502 or 503 Slow Down.
Pre-stage for cross-region workloads
Every AI Object Storage bucket resides in a home Availability Zone. LOTA serves reads of a bucket from any Availability Zone by fetching objects from the home Availability Zone and caching them on local Nodes, so a workload does not need its own copy of the data. For details, see Cross-region reads. AI Object Storage automatically pre-stages objects into the LOTA cache of clusters that run in the bucket’s home Availability Zone, so workloads there start with a warm cache. Automatic pre-staging does not extend to other Availability Zones, including other Availability Zones in the same region. To give a workload outside the bucket’s home Availability Zone the same warm cache, pre-stage the objects explicitly using the procedures on this page. Because AI Object Storage does not replicate buckets between Availability Zones, pre-staging is the recommended way to run a workload against a remote dataset at cache speed.When the transfer happens
A pre-stage pass fetches each object from the bucket’s home Availability Zone, so the remote transfer still happens. What pre-staging changes is when the transfer happens: before your workload starts, rather than during the first epoch while GPUs wait for data. After an object is in the local cache, later reads are served from that cache and do not leave the workload’s Availability Zone again. If LOTA evicts an object, the next read fetches it from the home Availability Zone again. Pre-stage immediately before the compute step that needs the data, and check your working set against the available cache so that eviction does not undo the pass. See Finite cache capacity.Minimum object size for caching
LOTA caches only objects larger than 4 MB, and that threshold applies to remote reads as well. Pre-staging has no effect on smaller objects, which are fetched from the bucket’s home Availability Zone on every read. A workload outside that Availability Zone that reads many small files pays the remote latency repeatedly, even after a pre-stage pass. Where you control how the data is written, packing small files into larger objects makes them eligible for the cache.Prerequisites
- An active CoreWeave organization with at least one AI Object Storage bucket containing objects.
- A valid API access key pair (Access Key ID and Secret Access Key) configured for your organization. See Get Started with AI Object Storage for setup instructions.
- A CKS cluster where your workload runs. Your workload must run inside a CoreWeave CKS cluster to reach the LOTA endpoint at
http://cwlota.com. - An S3-compatible client, such as AWS CLI, boto3 (Python), or s3cmd, installed and configured for CoreWeave AI Object Storage.
Configure CoreWeave credentials
We recommend using a separate profile for CoreWeave AI Object Storage to avoid conflicts with your other AWS profiles and S3-compatible services. If you don’t set up this configuration, you might encounter errors when using AI Object Storage. If you have no other AWS profiles, you can use thedefault profile instead of the cw profile created in the following steps. In that case, omit --profile cw from the commands.
Configure CoreWeave credentials with static access keys
Configure CoreWeave credentials with static access keys
-
Create a
cwprofile:Create a new profile -
When prompted, provide the following values:
- AWS Access Key ID: The Access Key ID of your CoreWeave AI Object Storage Access Key.
- AWS Secret Access Key: The Secret Key of your CoreWeave AI Object Storage Access Key.
- Default region name (Optional): To set a default region, see CoreWeave Availability Zones.
- Default output format: Use
jsonfor JSON output.
-
Set the default endpoint URL to the appropriate endpoint for your use case:
- The primary endpoint,
https://cwobject.com, for use outside a CoreWeave cluster. - The LOTA endpoint,
http://cwlota.com, for use inside a CoreWeave cluster. The LOTA endpoint routes to the LOTA path for best performance.
Set the primary endpoint for local development - The primary endpoint,
-
Set the S3
addressing_styletovirtual:Set virtual addressing style
--profile cw to your AWS CLI commands, or set AWS_PROFILE=cw in your environment.If you set endpoint_url and s3.addressing_style directly in your code (for example, in a Boto3 Config object), you can skip steps 3 and 4. The profile only needs the access key, secret key, and region.Configure CoreWeave credentials with Workload Identity Federation (OIDC)
Configure CoreWeave credentials with Workload Identity Federation (OIDC)
If you’ve configured Workload Identity Federation with OIDC, the AWS SDK automatically discovers temporary credentials. Set the following environment variables instead of configuring static access keys.Replace With WIF configured, your S3-compatible tools and Boto3 code automatically obtain and refresh temporary credentials without passing access keys explicitly.Requires
[ORG-ID] with your CoreWeave organization ID, [PATH-TO-JWT-TOKEN-FILE] with the path to your JWT token file, and [AVAILABILITY-ZONE] with your CoreWeave Availability Zone.Configure WIF OIDC credentials
awscli >= 2.33.2 or boto3 >= 1.42.5. See Use Workload Identity Federation with OIDC for the full setup guide.Pre-stage a single object
To pre-stage an object, send aHeadObject request to the LOTA endpoint for the target bucket and key. Run these commands from within the same CKS cluster where your training or inference Pods run, so that data is cached on the correct set of Nodes. LOTA returns a response after writing the object into the cache.
Before completing and running these commands, make sure you have configured your CoreWeave credentials.
- AWS CLI
- Boto3
- s3cmd
To pre-stage a single object, replace the following placeholders:The command returns the object’s metadata and triggers a cache fill:
[BUCKET-NAME]with the name of the bucket containing the object you want to pre-stage.[OBJECT-KEY]with the key of the object you want to pre-stage, for example,datasets/imagenet/shard-00001.tar.
Pre-stage a single object
Response
Pre-stage multiple objects in parallel
Parallelizing the pre-stage requests reduces the total time to warm a large dataset. For guidance on tuning connection pool size and concurrency for high-throughput workloads, see Maximize parallelism.Control the pre-stage request rate
A pre-stage pass over a large prefix can send requests faster than the storage backend accepts them. When that happens, pre-stage requests return timeouts and errors even though the backend itself is healthy. The risk is higher when the bucket is in another Availability Zone, because each request holds a connection open for longer. Request rate, rather than thread count, controls this. Set an explicit ceiling on requests per second and lower it if requests start failing. Keep concurrency bounded as well, so that listing a large prefix does not launch one request per object at the same time. Retry failed requests with exponential backoff and jitter rather than immediately, so that retries do not add to the load that caused the failure. The Boto3 example sets a requests-per-second ceiling directly, through theREQUESTS_PER_SECOND value. The AWS CLI and s3cmd examples have no rate limiter, so bound concurrency in those examples instead and lower it if requests start failing. The AWS CLI and Boto3 examples also retry with backoff and jitter.
Before completing and running these commands, make sure you have configured your CoreWeave credentials.
- AWS CLI
- Boto3
- s3cmd
To pre-stage all objects under a prefix, replace the following placeholders:
[BUCKET-NAME]with the name of the bucket containing the objects you want to pre-stage.[PREFIX]with the prefix of the objects you want to pre-stage, for example,datasets/imagenet/.[CONCURRENCY]with the number of pre-stage requests to run at once, for example,16. Lower this value if requests start failing.
AWS_RETRY_MODE=standard retries failed requests with exponential backoff and jitter, and AWS_MAX_ATTEMPTS sets how many attempts each request gets. xargs -P bounds concurrency, so the number of requests in flight does not grow with the size of the prefix. The tr and xargs -0 pair passes each key as a single argument, so keys that contain spaces or quotes are handled correctly.Pre-stage all objects under a prefix
Pre-stage before your training job starts
Use a Kubernetes Job as an initial step in your training pipeline. The Job pre-stages all training data, then your training pods start with a fully warmed cache. Replace[BUCKET-NAME] with the name of the bucket containing your training data, [PREFIX] with the object prefix to pre-stage (for example, datasets/imagenet/), and [CONCURRENCY] with the number of pre-stage requests to run at once (for example, 16). The Job reads credentials from a Kubernetes Secret named storage-credentials.
job-prestage-training-data.yaml
Schedule the pre-stage Job to run before your training pods launch. In an Argo Workflow or a Kubernetes-native pipeline, add a dependency so the training step waits for the pre-stage Job to succeed. Pre-stage data immediately before the compute step that needs it to balance warm cache benefits against cache capacity.
Related resources
- About LOTA (Local Object Transport Accelerator)
- Conditional writes: use the ETag returned by
HeadObjectwithIf-Matchto perform atomic compare-and-swap updates - Get Started with AI Object Storage
- Manage Buckets
- Storage Pricing
- CAIOS LOTA dashboard