A GPU that sits idle still costs money. ZStack wants to fix that, and it has released GPUWorks under the Apache License 2.0 to do it. The software lets several AI models take turns on shared GPU capacity, and it doesn’t need an existing Kubernetes cluster to run.
The method is straightforward. GPUWorks lets operators rank models by priority, free up resources that nobody is using and rotate workloads on a schedule. It also puts models to sleep and wakes them again, including models spread across several GPUs, which it handles as a group. The aim is to stop operators from reserving a separate GPU for every model and watching it wait for requests.
Sharing helps, but it doesn’t remove the need to plan for demand. Think of two customers whose models both wake up at once. Someone’s request has to wait. A rarely used internal document assistant can tolerate that. A customer-facing app with steady traffic probably can’t. So any savings should be judged next to response times and service promises. Averages can also hide the awkward moments when a model has to be restored.
Memory enters the bill too. ZStack’s fast restore keeps model weights in the host’s RAM, so a model doesn’t reload from storage every time. That speeds recovery, yet it means planners must count system memory when deciding how many models stay ready.
Then there’s the small install size of about 40 MB. That describes the software, not the whole environment, because models, runtimes and applications still need room. Skipping the Kubernetes requirement helps teams that lack orchestration. Teams already deep in Kubernetes might see GPUWorks as one more system to integrate.
Hardware coverage looks broad, with Nvidia, AMD and several Chinese accelerators listed. A shared interface doesn’t promise equal performance on every chip, though.
ZStack reports that one management server controlled 1,003 GPU servers in a physical test. That shows management scale. It says little about recovery, customer isolation or steady performance when workloads compete.
A provider planning to sell shared capacity should test failures first: a dead node, an interrupted model switch, a request arriving mid-reassignment. Those cases matter most, and demos rarely show them.
