GPUWorks Open Source: 1 Server, 1,003 GPU Hosts [2026]

ZStack open-sourced GPUWorks, a lightweight enterprise AI inference and Model-as-a-Service platform, on November 4, 2026 under the Apache License 2.0 in the flitai-io/gpuworks repository. In a reported test, one GPUWorks server managed 1,003 GPU servers, brought up 500+ inference replicas in four minutes, and peaked at 9 CPU cores and 1.6 GB of memory while serving 69,000 tokens per second, with a control plane of roughly 40 MB (about 45 MB per the repository) and a single-command install the release says takes 60 seconds. The platform requires no pre-existing Kubernetes cluster and supports NVIDIA, AMD, Huawei Ascend, T-Head PPU, Hygon DCU and Apple Silicon hardware, though the sources name no price, no on-record spokesperson, and no hardware model, model name or test duration behind the headline figures.

ZStack open-sourced GPUWorks on November 4, 2026, releasing a lightweight enterprise AI inference and Model-as-a-Service MaaS platform under the Apache License 2.0. Business Insider’s markets section and KitGuru both carried the announcement, and the code sits in the flitai-io/gpuworks repository. The headline claim is blunt: in a reported test, one GPUWorks server managed 1,003 GPU servers. That figure lands at a moment when GPU fleets keep growing. South Korea’s Hangang supercomputer, which we covered with 8,496 GPUs online https://shattered.io/south-korea-hangang-supercomputer-8496-gpus-quantum-link-2026/ , shows how quickly a single site can reach thousands of accelerators. Managing hardware at that scale usually means heavy software. GPUWorks argues the opposite, with a control plane that weighs roughly 40 MB. This analysis walks through what the release confirms, what it leaves open, and what it could change for teams that run inference on their own hardware. It also flags the gaps. The available sources name no price and no on-record spokesperson, so this piece sticks to the reported specifications and treats everything else as analysis. Don't miss new tech stories on Google Add Shattered once in the Google app and our stories show up in your news suggestions. Add now https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F What ZStack Released With GPUWorks Open Source ZStack describes GPUWorks as a lightweight enterprise AI inference and MaaS platform. In plain terms, it takes a pool of GPU machines and turns them into a managed service that serves models through an API. Developers call an endpoint, and the platform decides which machine runs the work. The GPUWorks open source https://shattered.io/open-source-ai-coding-assistant-opencode-ollama-2026/ release carries the Apache License 2.0, one of the most permissive licenses in common use. Companies can run, modify, and ship it inside commercial products without paying a license fee. The code lives under the flitai-io/gpuworks repository name, and the open-source date is November 4, 2026. Two design choices stand out in the coverage. First, installation runs through a single command, and the release says deployment takes 60 seconds. Second, the platform needs no pre-existing Kubernetes cluster. Most AI serving stacks assume Kubernetes is already running, so removing that requirement changes who can adopt the tool. The release also names a broad hardware list, covering NVIDIA, AMD, Huawei Ascend, T-Head PPU, Hygon DCU, and Apple Silicon https://shattered.io/category/hardware/ . We come back to that list below, because it matters as much as the size claim does. GPUWorks by the Numbers The reported figures fit in one table. Each row below comes from the announcement coverage, and the repository supplies the second size figure. We separate what the sources state from what they leave out, because several numbers arrive without test conditions. | Metric | Reported value | Source status | |---|---|---| | Control-plane download | 40 MB | Release coverage | | Control-plane size, repository | About 45 MB | Repository description | | Install time | 60 seconds, single command | Release statement | | GPU servers managed by one server | 1,003 | Reported test | | Inference replicas brought up | 500+ in four minutes | Reported test | | Peak server resource use | 9 CPU cores, 1.6 GB memory | Reported test | | Throughput | 69,000 tokens per second | Release coverage | | License | Apache License 2.0 | Release and repository | Read the table as a claim sheet, not a benchmark report. The sources give the headline results but no hardware model for the 1,003 servers, no model name for the 69,000 tokens per second, and no test duration. Those details decide whether a number carries over to your own fleet. A 40 MB Control Plane, or 45 MB? The title claim rests on a 40 MB download. The repository, however, describes the control plane as approximately 45 MB. The sources do not say which figure is the final one, so we treat both as correct for different measurements until ZStack clarifies. Gaps like this usually come from simple causes. A compressed download and an unpacked install rarely match, and a binary built for one platform differs from another. A 5 MB gap does not change the story. It does show why readers should check the repository before quoting a size in a purchase document. The size matters for a practical reason. A control plane this small installs fast, copies across air-gapped networks on removable media, and leaves almost no footprint on the host. Enterprise AI platforms often ship as multi-gigabyte bundles with dozens of services. A 40 MB package sits at the other end of that range. Still, small size alone proves nothing about quality. A tiny binary can hide a lot of work, or it can simply do less. The reported scaling tests, covered below, carry more weight than the download size does. No Kubernetes Required: Why It Matters Kubernetes dominates cloud-native infrastructure, and many inference stacks build on top of it. That choice brings real benefits, including scheduling, networking, and a large tooling ecosystem. It also brings cost, because someone has to run and upgrade the cluster. Our guide to Karpenter on EKS https://shattered.io/karpenter-eks-tutorial-nodepool-spot-consolidation-12-steps-2026/ shows how many moving parts a production cluster carries even when a cloud provider handles the control plane. GPUWorks skips that dependency. The release states that no pre-existing Kubernetes cluster is required. A team with a rack of GPU servers and no platform engineers can, in principle, install one package and start serving models. That lowers the entry barrier for three groups. Small research labs gain a path to shared GPU use without cluster expertise. Enterprises with on-premises racks gain a way to pilot inference without a platform project. Edge sites with a handful of machines gain a lighter option than a full orchestration stack. The tradeoff is ecosystem fit. Teams that already standardize on Kubernetes for storage, networking, observability, and policy may find a separate control plane awkward. The sources do not say how GPUWorks integrates with existing clusters, so that question stays open for evaluators. The 1,003-Server Test and What It Shows The most quoted result is the 1,003-server figure. According to the release coverage, one GPUWorks server managed 1,003 GPU servers. At that scale, the control plane tracks health, placement, and model state across a thousand machines from a single node. The reported cost of doing so was modest. The server peaked at 9 CPU cores and 1.6 GB of memory. A modern server handles that load with room to spare, which hints that the control plane spends its effort on bookkeeping rather than heavy computation. What the sources leave out The coverage does not say whether the 1,003 servers were physical machines, virtual machines, or simulated nodes. It does not say how many GPUs each server held. It also gives no detail on how long the test ran. A simulated fleet and a physical one stress a control plane in very different ways, so buyers should ask for the test setup. Why the scale still matters Even with those caveats, a thousand-node claim gives a useful ceiling. Most enterprise GPU estates sit far below it. If the control plane holds up at 1,003 servers, a team with 50 or 200 machines has plenty of headroom. That makes the result relevant for the majority of buyers, not only hyperscale operators. 500 Replicas in Four Minutes: The Scaling Math The second reported test covers speed. The release says more than 500 inference replicas came up in four minutes. Four minutes equal 240 seconds, so the figure works out to roughly two replicas started per second on average, assuming a steady pace. That arithmetic comes from our own division, not from the sources. The release gives no per-replica breakdown, so the real pace may have varied. Replica startup also depends on model size, because large weights take time to load from disk or the network. Why does startup speed matter? Inference demand spikes. A product launch, a viral feature, or a batch job can multiply traffic within minutes. A platform that scales out in four minutes absorbs the spike. A platform that needs twenty minutes forces teams to overprovision and pay for idle GPUs. GPU idle time is expensive. Our report on the RTX 5090 street price rising 370% https://shattered.io/rtx-5090-street-price-370-percent-rtx-50-gpus-40-120-percent-2026/ shows how scarce and costly accelerators have become. When hardware costs this much, faster scale-up directly cuts waste, because teams can keep fewer machines warm. 69,000 Tokens per Second in Context The release also cites a throughput of 69,000 tokens per second. A token is a small chunk of text, roughly a short word or word fragment, and tokens per second is the standard measure of how fast an inference system produces output. On its own, the number says little. Throughput depends on the model, the GPU type, the batch size, the prompt length, and the number of machines involved. A small model on many GPUs can post a huge figure, while a large model on a few GPUs posts a modest one. The sources give none of those conditions. Treat the figure as a signal that the platform adds little overhead between the request and the engine. The engines do the actual token generation, and GPUWorks routes work to them. The more useful question for buyers is how much throughput the platform preserves compared with running an engine directly. The sources do not answer it. | Question to ask ZStack | Why it matters | |---|---| | Which model produced 69,000 tokens per second? | Model size sets the throughput ceiling | | How many GPUs and which type? | Hardware class changes results several-fold | | Were the 1,003 servers physical? | Simulated nodes stress the control plane less | | What was the test duration? | Short runs hide memory leaks and drift | | How does overhead compare with a bare engine? | Shows what the platform costs in speed | Six Accelerator Families, One Control Plane The hardware list is the strongest strategic detail. GPUWorks supports NVIDIA, AMD, Huawei Ascend, T-Head PPU, Hygon DCU, and Apple Silicon. That mix spans Western data center parts, Chinese domestic accelerators, and consumer-class Mac silicon. Mixed fleets are becoming normal. Supply limits, export rules, and price swings push buyers toward whatever hardware they can get. AMD’s momentum feeds that trend, and our coverage of AMD’s $13.4B record quarter https://shattered.io/amd-record-13-4b-quarter-cloud-buyers-epyc-mi450-2026/ looks at what cloud buyers get from its newer parts. A control plane that treats NVIDIA and AMD alike gives operators room to buy on price. The Chinese accelerator names carry extra weight. Huawei Ascend, T-Head PPU, and Hygon DCU matter most to operators in China, where access to Western chips faces limits. A platform that supports them from day one targets that market directly. The sources do not say how deep each integration runs, so support for a name on a list may mean different things per chip. Apple Silicon is the surprise entry. It suggests GPUWorks can scale down to developer machines and small office setups. Teams could prototype on a Mac and deploy to a rack with the same management layer. Engines, Templates, and the OpenAI-Compatible Endpoint GPUWorks does not generate tokens itself. It names vLLM, SGLang, Strata, and ninfer as inference engines or templates. vLLM and SGLang are widely used open-source serving engines. The platform packages them as deployable templates, which saves operators from hand-tuning each one. On the front end, the platform exposes an OpenAI-compatible endpoint. That choice carries real adoption value. Thousands of applications already speak the OpenAI request format, so pointing them at a new base URL often needs only a configuration change. The example below shows the standard wire format as an illustration. It is not copied from GPUWorks documentation, and the host and model names are placeholders. curl https://YOUR HOST/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR API KEY" \ -d '{ "model": "YOUR MODEL NAME", "messages": {"role": "user", "content": "Hello"} }' Compatibility at the API layer lets teams swap backends without rewriting code. A company can test GPUWorks against a hosted API, compare cost and latency, and move traffic gradually. That reduces switching risk, which usually blocks adoption of new infrastructure. Apache 2.0 and What It Means for Adopters License choice shapes how companies treat open-source infrastructure. The Apache License 2.0 allows commercial use, modification, and redistribution, and it includes an explicit patent grant. Legal teams approve it quickly because it has a long track record in enterprise software. The same license appeared in another big open release this season. We covered Tencent Hy4, a 770B-parameter model under Apache 2.0 https://shattered.io/tencent-hy4-770b-parameters-apache-2-0-open-source-model-2026/ . Together, the two releases hint at a pattern, with Chinese technology firms favoring permissive licenses to build developer communities fast. Open licensing does not remove business questions. ZStack could still earn money from support, managed services, or enterprise add-ons. The sources identify no price and describe no paid tier, so we cannot say how the company plans to monetize. Buyers should ask which features, if any, sit outside the open-source repository. Market Impact and Competitive Comparison GPUWorks enters a crowded field of ways to run models on owned hardware. We compare architectural approaches here, not named products, because the sources supply no head-to-head benchmarks. The rows describe typical traits of each category, and individual tools vary. | Approach | Typical strength | Typical cost to adopt | GPUWorks contrast | |---|---|---|---| | Kubernetes-based serving stacks | Rich ecosystem and policy tooling | Cluster operations skills | No cluster required | | Classic HPC job schedulers | Batch fairness and queueing | Scheduler tuning, less API focus | Serves models through an API | | Hosted inference APIs | Zero hardware management | Per-token fees, data leaves site | Runs on owned hardware | | Running a single engine by hand | Full control, simple start | Manual scaling and failover | Automates placement and scaling | The pressure falls hardest on two groups. Vendors that sell heavier on-premises AI platforms now face an open-source option that installs in about a minute. Small managed-inference resellers face a free alternative for customers who own GPUs. Chip vendors may gain. A neutral control plane makes it easier to add non-NVIDIA hardware to an existing fleet. Our AMD versus Nvidia driver and feature chart https://shattered.io/amd-vs-nvidia-driver-feature-support-chart-rtx-50-rx-9000-2026/ shows how uneven software support still is between the two, and platforms that smooth over those gaps help the challenger more than the incumbent. Historical Context: From Schedulers to Lightweight Planes GPU management has moved through several eras. Early clusters borrowed schedulers from scientific computing, where jobs queue for days and run to completion. Then the cloud-native wave brought containers and Kubernetes, which treat workloads as long-running services that scale on demand. Large language models changed the shape of demand again. Serving a model resembles a web service, but it also holds gigabytes of weights in GPU memory and cares about batching and cache reuse. Generic orchestration handles that poorly without extra layers, which is why a wave of model-aware serving tools appeared. GPUWorks represents a further step, pairing model-aware serving with a deliberately small control plane. Money explains part of the push. The industry’s capital commitments are huge, and our look at AI capex topping $740B https://shattered.io/ai-capex-boom-how-long-can-it-last-740-billion-markets-2026/ shows how much spending now flows to hardware. Software that raises the use rate of that hardware earns attention from every buyer who wants a better return. What Remains Unconfirmed Several details stay open after the announcement, and the table below lists them. We checked each against the available coverage, and none appears in the sources. | Detail | Status | |---|---| | Final control-plane size 40 MB or about 45 MB | Unconfirmed | | Pricing or paid tiers | No price identified | | Named ZStack spokesperson or direct quote | None identified | | Hardware and models used in the 1,003-server test | Not stated | | Independent third-party benchmark | None cited | The lack of a named speaker also limits what we can report about intent. We cannot say what ZStack expects from the release, who the target customers are, or how it plans to support the project. Anything beyond the fact sheet would be guesswork, so we leave it out. Independent testing will settle most of these questions. Open code makes that possible, because anyone can install the package, build a test fleet, and publish results. Early community benchmarks will tell more than the launch figures do. Predictions: What Happens Next These forecasts are our analysis, not reported facts. Each rests on the confirmed specifications and carries real uncertainty. 1. Independent benchmarks will surface within weeks. An Apache 2.0 repository with a one-command install invites quick testing. Expect community posts that either confirm or trim the 1,003-server and 69,000 tokens-per-second claims. 2. The size claim will get a footnote. The gap between 40 MB and about 45 MB will likely resolve into a clear note on what each figure measures, such as compressed versus installed size. 3. Rivals will answer on simplicity. Heavier platforms may ship lighter installers or Kubernetes-free modes, because the 60-second install sets a visible bar. 4. Mixed-vendor fleets will lead adoption. The six-family hardware list suits buyers who combine accelerators, so early users will probably come from operators who cannot rely on a single chip supplier. 5. A commercial layer will appear. Most open-source infrastructure projects add paid support or managed offerings over time. We expect ZStack to describe its plans, though no sources confirm any. What Operators Should Do Now Teams with spare GPUs can run a low-cost trial. Install GPUWorks on a small group of machines, deploy one model through a supported engine, and point a test application at the OpenAI-compatible endpoint. Measure startup time, throughput, and failure handling against your current setup. Security teams should review the repository before any production use. Read the dependency list, check how the platform handles authentication and tenant separation, and confirm how updates arrive. A small codebase helps here, since less code means less to audit. Finance teams should track utilization. The strongest argument for any control plane is higher GPU use, which lowers the cost per token. Collect a baseline before the trial so the comparison holds up. For more hardware coverage, see our hardware section https://shattered.io/hardware/ . FAQ: GPUWorks Open Source What is GPUWorks? GPUWorks is a lightweight enterprise AI inference and Model-as-a-Service platform from ZStack. It manages pools of GPU servers and serves models through an OpenAI-compatible endpoint. When did ZStack open-source it, and under what license? ZStack open-sourced GPUWorks on November 4, 2026, under the Apache License 2.0. The code sits in the flitai-io/gpuworks repository. How big is the GPUWorks control plane? The release cites a 40 MB download, while the repository describes it as approximately 45 MB. The sources do not say which figure is the final one. Does GPUWorks need Kubernetes? No. The release says no pre-existing Kubernetes cluster is required, and installation runs through a single command that takes about 60 seconds. How many servers can it manage? In a reported test, one GPUWorks server managed 1,003 GPU servers while peaking at 9 CPU cores and 1.6 GB of memory. The sources do not describe the test hardware. Which GPUs and accelerators does it support? The release names NVIDIA, AMD, Huawei Ascend, T-Head PPU, Hygon DCU, and Apple Silicon. It also lists bare-metal servers, virtual machines, cloud containers, on-premises data centers, private clouds, and public clouds as deployment targets. What does GPUWorks cost? The available sources identify no price. The code is free under Apache 2.0, but any paid support or hosted tier remains unconfirmed. Which inference engines does it run? The coverage names vLLM, SGLang, Strata, and ninfer as engines or templates. Applications reach them through the OpenAI-compatible endpoint.