Launch HN: Outerport (YC S24) – Instant hot-swapping for AI model weights
‘Hot-swapping’ lets you serve different models on the same GPU machine with only ~2 second swap times (~150x faster than baseline). You can see this in action through a live demo where you try the same prompts on different open source large language models at https://hotswap.outerport.com and see the docs here https://docs.outerport.com.
Running AI models on the cloud is expensive. Outerport came from our own experience working on AI services ourselves and struggling with the cost.
Cloud GPUs are charged by the amount of time used. A long start-up time (from loading models into GPU memory) means that to serve requests quickly, we need to acquire extra GPUs with models pre-loaded for spare capacity (i.e. ‘overprovision’). The time spent on loading models also adds to the cost. Both lead to inefficient use of expensive hardware.
The long start-up times are caused by how massive modern AI models are, particularly large language models. These models are often several gigabytes to terabytes in size. Their sizes continue to grow as models evolve, exacerbating the issue.
GPU capacity also needs to adapt dynamically according to demand, further complicating the issue. Starting up a new machine with another GPU is time consuming, and sending a large model there is also time consuming.
Traditional container-based solutions and orchestration systems (like Docker, Kubernetes) are not optimized for these large, storage-intensive AI models, as they are designed for smaller, more numerous containerized applications (which are usually 50MB to 1GB in size). There needs to be a solution that is designed specifically for model weights (floating point arrays) running on GPUs, to take advantage of things like layer sharing, caching and compression.
We made Outerport, a specialized system to manage and deploy AI models, as a solution to these problems and to help save GPU costs.
Outerport is a caching system for model weights, allowing read-only models to be cached in pinned RAM for fast loading into GPU. Outerport is also hierarchical, maintaining a cache across S3 to local SSD to RAM to GPU memory, optimizing for reduced data transfer costs and load balancing.
Within Outerport, models are managed by a dedicated daemon process which handles transfer to GPU, loading models from registry, and orchestrates the ‘hot swapping’ of multiple models on one machine.
‘Hot-swapping’ lets you provision a single GPU machine to be ‘multi-tenant’, such that multiple services with different models can run on the same machine. For example, this can facilitate A/B testing of two different models or having a text generation & image generation endpoint on the same machine.
We have been busy running simulations to determine the cost reductions we can get from leveraging this multi-model service scheme instead of multiple single-model services. Our initial simulation results show that we can achieve a 40% reduction in GPU running time costs. This improvement can be attributed to the multi-model service’s ability to smoothen out peaks of traffic, enabling more effective horizontal scaling. Overall, less time is wasted on acquiring additional machines and model loading, significantly saving costs. Our hypothesis is that the cost savings are substantial enough to make a viable business while still saving customers significant amounts of money.
We think that there are lots of exciting directions to take from here—from more sophisticated compression algorithms to providing a central platform for model management and governance. Towaki worked on ML systems and model compression at NVIDIA, and Allen used to do research in operations resea...
24 comments
[ 3.6 ms ] story [ 57.7 ms ] threadDo you imagine Outerport being a better fit for OSS model hosts like Replicate, Anyscale, etc. or for companies that are trying to host multiple models themselves?
Your use case mentioned speaks more to the latter, but it seems like the value at scale is with model hosting as a service companies.
I think both are fits- we've gotten interest from both types of companies and our first customer is a "OSS model host".
Our 40% savings result is also specifically for the 5 model services case, so there could be non-trivial cost reduction even with a reasonably small number of models.
Like, for a particular portion of the workflow - assume some crawler of weird Insurance Claims data of scale - and you want particular weights for the aspects of certain logic that youre running to search for fraud.
This is really cool. Are the costs to run this mainly storage or how much compute is actually tied up in it?
The time/cost to download models on a gpu cloud instance really add up when you are paying per second.
Or can they be different types of models with different number of layers, etc?
That being said, there is some smart caching / hashing on layers such that if you do have models that are similar (i.e. a fine-tuned model where only some layers are fine-tuned), it'll minimize storage and transfer by reusing those weights.
We hope to make it easier to bridge the multi-cloud landscape by being independent and 'outer'.
(Please feel free to reach out to us too at towaki@outerport.com !)
Loading from disk to VRAM can be super slow- so doing this every time you have a new process is wasteful. Instead, if you have a daemon process that keeps multiple model weights in pinned RAM, you can load them much quicker (~1.5 seconds for a 8B model like we show in the demo).
You _could_ also make a single mega router process, but then there are issues like all services needing to agree on dependency versioning. This has been a problem for me in the past (like LAVIS requiring a certain transformer version that was not compatible with some other diffusion libraries)
Since we use pinned RAM memory for model loading and manage the cache hierarchy, the sever needs to at least make a call to our daemon. So we'd need to fork the Triton Server. But hopefully it'd only take a few lines of change!
I've actually never used Triton Server myself - curious how you have found it so far if you've used it. How does it compare to other alternatives in your opinion?
Our inference stack is built using candle in Rust, how hard would it be to integrate?