Google brengt GKE Workspaces uit voor GPU- en TPU-notebooks

Google lanceert GKE Workspaces als open-source notebookomgeving voor GKE, waar ML-teams JupyterLab op GPU’s en TPU’s gebruiken en ondersteunde GPU-sessies kunnen pauzeren met behoud van hun staat, meldt het bedrijf op 4 november.

Een ML-team dat al GKE beheert, kan notebooks op datzelfde GKE-cluster laten draaien en toegewezen GPU-capaciteit teruggeven wanneer iemand pauzeert. Het platformteam blijft de omgeving, softwareomgevingen, hardwarekeuzes, opslag en toegangsregels beheren. De nieuwe interface neemt die Kubernetes-verantwoordelijkheid niet over.

ML-teams kiezen machines binnen vaste grenzen

GKE Workspaces bouwt op Kubeflow Workspaces en wordt op het eigen GKE-cluster van een team uitgerold. Vanuit een webdashboard kiest de gebruiker JupyterLab of VS Code, een softwareomgeving en een machinegrootte. Google noemt kleine CPU-machines en opties met GPU of TPU. Voor die selectie hoeft een onderzoeker geen Google Cloud Console, YAML-bestanden of opdrachtregel te openen.

Platformbeheerders bepalen vooraf welke softwareomgevingen en machineprofielen zichtbaar zijn en of capaciteit op aanvraag of met Spot wordt geleverd. Iedere workspace krijgt een eigen versleutelde Persistent Disk in het Google Cloud-project. Notebooks, bestanden en geïnstalleerde pakketten blijven daardoor beschikbaar na een herstart, pauze of verandering van machine. Dat maakt de notebook zelfbedienend, terwijl het team de toegestane machines en kostenkeuzes centraal houdt.

Pauzeren bewaart niet elke sessie op dezelfde manier

Google beschrijft een pauzeknop die een snapshot van de draaiende notebook naar Cloud Storage schrijft. Dat snapshot bevat volgens de aankondiging ook variabelen in het werkgeheugen en modellen die op de GPU zijn geladen. Daarna geeft de workspace de accelerator vrij. Bij hervatten wordt de opgeslagen toestand teruggezet; pauzeren kan ook automatisch na een periode zonder activiteit.

De actuele GKE-handleiding bevestigt geheugenherstel voor JupyterLab-notebooks op CPU en GPU. Daarin schaalt het systeem de pod van andere workspaces, zoals VS Code in de browser, terug om rekenkracht vrij te maken. Bestanden op de blijvende thuisschijf blijven staan, maar actieve kernelvariabelen en processtatus niet. De handleiding noemt TPU niet bij de ondersteunde hardware voor herstel van notebookgeheugen.

Voor TPU’s beschrijft Google een andere route: hetzelfde notebook kan van één chip opschalen naar meerdere chips en vervolgens naar een multi-host trainingsslice. Trainingslogs komen terug in de notebook en de TPU’s worden vrijgegeven als de taak klaar is. Dat is geen bevestiging dat een gepauzeerde TPU-notebook haar geheugenstatus bewaart. Voor teams die die eigenschap nodig hebben, is de precieze hardware- en workspacecombinatie dus bepalend.

De werkplek wordt ook een agent-sandbox

GKE Workspaces kan lokale codeeragenten verbinden met een notebook op afstand. Vanuit de webinterface maakt de gebruiker daarvoor een kortlevende, intrekbare link. Verkeer loopt via HTTPS, Google Identity-Aware Proxy en de toegangsproxy van het cluster. Die controleert rechten per verzoek; er zijn geen SSH-sleutels, lokale tunnels of clustergegevens op de laptop nodig.

Een notebook kan ook parallelle subagenten starten. Die draaien in afzonderlijke, lichte sandboxes op gedeelde clusternodes, blijven doorwerken nadat de gebruiker uitlogt en worden bij inactiviteit naar Cloud Storage weggeschreven zonder rekenkracht te gebruiken. De agent levert daarna een patch op die iemand kan beoordelen en samenvoegen. Google bouwt hiermee voort op Agent Substrate, de open-source GKE-runtime die agents met microVM- of gVisor-isolatie afschermt. Het bedrijf kondigde ook een hardware-geïsoleerde microVM per Gemini-agent met eigen Hyperdisk-opslag aan. Workspaces brengt die uitvoeringskeuze dichter bij de ontwikkelomgeving van een ML-team.

De clusterkeuze bepaalt ook de rekening

De software is Apache 2.0-gelicentieerd en de GKE-uitvoering kan volgens Google op Standard of Autopilot draaien, zonder de volledige Kubeflow-distributie of Istio te installeren. De beheergids laat tegelijk zien hoeveel platformwerk eromheen zit: clusterinstellingen, toegangsbeheer, goedgekeurde omgevingen, snapshots en capaciteit moeten worden ingericht. De gebruiker krijgt een eenvoudiger scherm; de beheerlast verdwijnt niet.

Google biedt met Agent Platform Workbench ook notebookinstanties aan die standaard na een ingestelde periode van inactiviteit afsluiten. Die tijd is aanpasbaar of de functie kan uit. Het verschil zit hier in de inzet op een cluster dat het team zelf beheert, met eigen hardwareprofielen en GKE-beleid. Ongebruikte rekenkracht beperken is dus al onderdeel van Googles notebookaanbod; Workspaces koppelt dat aan herstel van JupyterLab-status en agent-sandboxes op GKE.

De aankondiging noemt geen productprijs, regiolijst of onafhankelijke prestatiemeting. De GPU komt vrij, maar Persistent Disks blijven volgens de beheergids doorlopen totdat ze expliciet worden verwijderd. De besparing hangt af van de uren waarop de accelerator niet gebruikt hoeft te worden en van de kosten van cluster en opslag.

De productkeuze schuift notebookbeheer dichter naar het platformteam: gebruikers kiezen een goedgekeurde omgeving, terwijl het team cluster, capaciteit en toegangsregels beheert. Voor een team dat al GKE draait, wordt ongebruikte GPU-tijd zo onderdeel van de werkplekregeling zelf. Notebookstatus en bestanden blijven in die omgeving staan, terwijl de accelerator alleen tijdens actief werk nodig is. Dat maakt GKE Workspaces relevant voor teams die compute kunnen vrijgeven zonder hun ontwikkelomgeving los te koppelen van hun eigen platform.