Fast Model Loading for AI Inference on Amazon EKS
AWS shares configuration best practices that significantly reduce cold-start times for AI inference workloads, especially large language models, running on Amazon EKS. These optimizations, which require no code changes, address bottlenecks in S3 weights loading and PyTorch's `torch.compile` phase. For a 64 GiB model, subsequent launches on the same node saw cold-start times drop from 82 to 16 seconds. This guidance primarily affects engineers and architects deploying LLM inference on EKS using engines like vLLM and SGLang.
- →Reducing Cold-Start Time for AI Inference on EKS
- →Identifying Cold-Start Bottlenecks
- →Strategy for Optimization and Upstream Contributions
- →Optimizing S3 Model Loading with Chunk Size Recommendations
- →Implementing Aggressive Timeout and Retries for S3 Requests
Notes (5) ›
- Reducing Cold-Start Time for AI Inference on EKS
AWS has identified configuration-only changes to accelerate AI model loading on Amazon EKS, specifically targeting large language models. These optimizations significantly cut cold-start times for inference workloads that load large model weights into GPU memory, impacting engines like vLLM and SGLang using Run:ai Model Streamer.
- Identifying Cold-Start Bottlenecks
Analysis revealed that for AI models under ~100 GiB, `torch.compile` (PyTorch's model compiler) is the primary cold-start bottleneck, while for larger models, loading weights from Amazon S3 dominates. This shift occurs because `torch.compile` time is relatively constant, whereas weights loading scales linearly with model size.
- Strategy for Optimization and Upstream Contributions
AWS opted for config-only tuning and contributions to the publicly available Run:ai Model Streamer to ensure rapid deployment and broad benefit across Amazon EC2, Amazon ECS, and Amazon SageMaker. This approach avoids proprietary EKS features or complex DaemonSets, leveraging existing integrations with common inference engines.
- Optimizing S3 Model Loading with Chunk Size Recommendations
Investigations into Run:ai Model Streamer's S3 downloading mechanism found that using a 4 GiB chunk size for model weights, which often matches SafeTensors shard sizes, provides optimal throughput. This single chunk per file approach minimizes serial requests and reduces the number of required TCP connections, simplifying configuration.
- Implementing Aggressive Timeout and Retries for S3 Requests
To mitigate the impact of long-tail S3 GET latencies, an aggressive timeout and retry mechanism was implemented for slow requests. If a request falls below a minimum speed threshold, it is killed and retried on a fresh connection, ensuring that a single stalled connection does not delay the entire model loading process.
https://aws.amazon.com/blogs/containers/fast-model-loading-for-ai-inference-on-amazon-eks/
Related releases
- Kyverno Automates Proxy Injection for EKS on Fargate AWS Containers Blog ·
- Amazon EC2 R9g and R9gd Memory-Optimized Instances Now Generally Available AWS What's New ·
- Amazon EMR on EKS Adds Job Run Concurrency Controls AWS What's New ·
- Mountpoint for Amazon S3 adds memory usage controls AWS What's New ·
- Break-Glass Access for Amazon EKS When Federated Identity Fails AWS Containers Blog ·
- GPU-accelerated Apache Spark on Amazon EMR with EC2 G7 instances runs up to 3.7x faster AWS Big Data Blog ·