Core concepts
Tenants, datasets, experiments and runs, model versions, approval, runtime images, serving, edge, alerts, drift
Terms used throughout the manual.
Tenants and roles
Tenant
The unit in which the platform is shared (a team, business unit or customer). Datasets, experiments, models, images, devices and alerts all belong to a tenant, and other tenants' items are invisible. Switch tenants with the selector at the top right. Features (training, serving, edge and so on) are turned on or off per tenant.
Members and roles
A user becomes a member of a tenant with one role (VIEWER, DEVELOPER, OPERATOR, APPROVER or ADMIN). The role decides the permissions → Roles and permissions
Global administrator
An account that manages the whole platform regardless of tenant. It creates tenants, wires GPUs and uses the system console.
Data and training
Dataset
A set of files used for training. It is finalised when created, and you can still add or remove files afterwards. Every change rewrites the file list (manifest), so the files a training run used are recorded. Upload directly or sync from an external DataOps system.
Training run
One training job submitted from the wizard. The server shows progress in six stages: Queued → Prepare training environment → Prepare dataset → Training → Register in model registry → Finalise results. It runs as a Kubernetes Job and can be stopped or resubmitted with the same settings. There is no way to continue a stopped run as-is; upload its checkpoint as starting weights and start a new run.
Training runtime
The container image that holds the training code. There are built-in runtimes such as YOLO, RF-DETR and Pointcept, and images built by partners are registered as external images. There are shared runtimes for every tenant and dedicated runtimes a tenant keeps for itself.
Experiments and runs
Each training run becomes one MLflow run. A run keeps parameters, metrics (per-epoch curves) and artifacts (model files and so on), and runs with the same purpose are grouped into one experiment.
Models and delivery
Model versions and stages
A registered model gets a version number, and its stage says what it is for: Staging (under validation) → Production (in service) → Archived. If Register in model registry (모델 레지스트리 등록) is turned on in the training wizard, a model version is registered automatically after the run succeeds. Otherwise, register the run as a model from Experiments (실험). New versions go to Staging.
Approval
Promotion to Production always starts as an approval request. Someone with the promotion permission (APPROVER, ADMIN) creates the request, and it takes effect once someone with the approve permission approves it. Safety-critical models (tagged geo.safety_critical) need two approvals.
Serving images and API services
A serving image is a model version built into an inference-server container. Deploying that image to the cluster and calling it over REST is an API service. You can try it in the on-screen inference console.
Deployment
The record of sending a model version to field devices. Devices actually receive the model through the Pull model command sent from Edge Fleet (Edge Fleet). A rollback marks the deployment record as rolled back; to restore devices, have them pull the previous version again.
Field and monitoring
Edge device
An inference device in the field. The geo-mlops-sdk agent sends heartbeats (the periodic signal a device sends to report that it is running), uploads sensor and PLC data and inference results, and receives commands, policies and models from the centre. When the network drops it buffers locally and sends once reconnected.
Alerts and notifications
An alert is a problem the system detected (a device went silent, API latency, drift…) that you acknowledge and resolve. Alerts from Alertmanager can also be muted. A notification is news addressed to you (an approval request, a training result…) that lands in the inbox under the bell icon.
Drift
The distribution of inputs in production drifting away from what the model was trained on. The platform measures how far the two distributions differ with the PSI and KS metrics, raises an alert when it crosses the threshold, and Retrain this model (이 모델 다시 학습하기) on that screen opens a new training wizard.
GPU wiring
Allocating the cluster's GPUs to tenants. There are shared pools used by several tenants and dedicated GPUs used by one; a tenant with no wiring cannot use GPUs for training or serving (CPU only).