GPUWorks samler GPU-servere, leide skyinstanser og Mac-er bak ett OpenAI-kompatibelt endepunkt

Mange som kjører lokale modeller ender med en GPU-boks i kjelleren, en Mac på pulten og kanskje en leid instans på Vast.ai eller RunPod, hver med sin egen vLLM- eller llama.cpp-prosess. GPUWorks fra flitai-io samler dem i én klynge. Serveren og agenten er hver sin statiske Go-binær, tilstanden ligger i én SQLite-fil, og agentene kobler seg ut over WebSocket, så GPU-nodene trenger ingen åpne porter inn. Prosjektet er Apache 2.0-lisensiert, ble opprettet på GitHub 22. oktober og fikk versjon 26.11.1 den 4. november.

README-en kaller kontrollplanet en nedlasting på 40 MB, mens release-arkivene for 26.11.1 er på 44 til 46 MB. Du velger en modell, får et estimat av GPU-minnet til vekter, KV-cache og motor, og GPUWorks starter vLLM eller SGLang, eller vllm-metal, MLX og llama.cpp på Mac. Alt havner bak /v1 med API-nøkler og tokenforbruk per nøkkel, og /v1/messages og /v1/responses sendes rett gjennom. Flere modeller kan dele ett kort med harde minnekvoter, og et skrivebeskyttet MCP-endepunkt lar Claude Code spørre om tilstanden i klyngen.

Katalogen er skjev. Av 1 235 ferdige oppstartsoppsett for 392 modeller gjelder 745 NVIDIA, mens AMD har 15 og Apple 9. Resten er kinesiske akseleratorer som Huawei Ascend, T-Head PPU og Hygon. Har du en Ryzen AI Max eller en Mac, får du altså langt færre ferdigtestede kombinasjoner. Skaleringen er derimot prøvd: i en øvelse på Alibaba Cloud styrte én server 1 003 leide GPU-maskiner i sju regioner og 2 000 samtidige forespørsler med 1,6 GB minne. Produksjonsinstallasjoner sender som standard én anonym bruksrapport per døgn.

Hva bør du gjøre?

1. Installer serveren fra release-arkivet og sjekk SHA256SUMS i stedet for å sende get.sh rett til bash.
2. Sett usage_report: false i server.yaml før du kobler på noder.
3. Start med en liten modell som Qwen3-1.7B for å sjekke minneestimatet og plasseringen før du ruller ut større modeller.