-
-
SecurSpaces for AI and ML engineers
-
-
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
SecurSpaces for AI and ML engineers
AI/ML Engineer
Citrix SecurSpaces™ gives you a Linux environment with as much compute as your cluster can provide, GPUs attached when you need them, and shared access to training data that does not have to be copied onto your laptop.
The parts that matter for model work are the same parts that matter for any development work — the environment is disposable, the data is not, and neither leaves the platform.
If you are new to SecurSpaces, SecurSpaces for developers covers the basics of workspaces, templates, and connecting an IDE. This page covers what is different about training and experimentation.
How it works
A workspace is a Linux environment sized from a specification your platform administrator defines, so the CPU, memory, disk, and GPUs you get are requested rather than owned. A GPU workspace is scheduled onto a GPU-capable node in the cluster when you start it, and released when you stop it.
Training data is reached where it already lives. Instead of copying a dataset into the workspace, you attach a mount point to read it in place, or a data bucket if you need a snapshot pinned at a known version. A notebook server or inference endpoint you run inside the workspace is published through a workspace app, which puts it behind an authenticated URL rather than an open port. Outbound requests to AI services leave through the platform, so they can be attributed and governed.
The sections below cover each of these in turn.
What’s in it for you
The data does not have to move
Training data stays in your storage and your cluster. Nothing is cloned onto a laptop, which is often the whole reason a team adopts the platform in the first place.
Someone else can reproduce your run
A template fixes the image, the toolchain, and the resources, so an experiment a colleague repeats starts from the same place as yours.
The GPUs are not sitting in one person’s machine
A GPU node serves whoever needs it. You request the hardware for the run rather than owning it.
Access is governed without you managing it
Repository access, secrets, AI provider traffic, and outbound network are controlled centrally and audited, so you are not the one holding credentials.
Compute
A workspace is sized from a specification your platform administrator defines. The product ceilings are:
| Resource | Maximum |
|---|---|
| CPU | 1000 cores |
| Memory | 10,000 GiB |
| Disk | 10,000 GiB |
| GPUs | 1000 |
These are the limits the platform enforces. What you can actually request is whatever your administrator has made available in a workspace specification, bounded by the hardware in the cluster. If the size you need is not offered, that is a conversation with your platform administrator rather than a product limit.
GPUs are requested as a count on the specification and scheduled onto GPU-capable nodes. For how a platform administrator provides them, see GPU-enabled workspaces on AKS.
Training data
Copying a dataset into every workspace is slow and duplicates data you may not be allowed to duplicate. SecurSpaces offers two ways to avoid it, and they behave differently.
| Mount points | Data buckets | |
|---|---|---|
| How data arrives | A live connection to external storage | A snapshot copied onto the cluster |
| Shared edits | Immediately visible to every workspace using it | Requires a publish cycle |
| Duplication | None — data stays in the external storage | Each snapshot is replicated |
| Versioning | Use the storage provider’s own | Built in |
For a dataset several teams read, a mount point is usually the right choice: it is POSIX file storage mounted into the workspace, there is no per-mount size quota, and nothing is copied. For a dataset you want pinned at a known version, a data bucket gives you that.
See Choose between data buckets and mount points.
A mount point is shared infrastructure: every workspace that mounts it works on the same live files. Plan backups and retention in the storage provider, alongside the rest of your data platform. See Mount point limits and behavior.
Notebooks and long-running jobs
A notebook server, dashboard, or inference endpoint running in your workspace can be reached through a workspace app, which publishes a port over an authenticated URL. See Share a running application.
Workspaces pause when they are idle, which keeps GPU time from being spent on environments nobody is using. For a job that runs unattended — an overnight training run, a long batch evaluation — ask a platform administrator or security officer to turn on Bypass Schedule for that workspace. The workspace then keeps running until you stop it. See Workspace idle detection.
Access to AI providers
Traffic from workspaces to AI services can be routed through an internal AI Gateway. When it is configured, requests carry headers identifying the user, project, and workspace, so usage is attributable and can be reported on.
This is a platform-level integration rather than something you configure. See AI Gateway.
Outbound access is also governed by network policy, so the domains a workspace can reach — including model and package registries — may be restricted. If a download is blocked, that is the reason. See Network policies.
Next steps
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.