API services
The screen for creating central serving endpoints, watching their status and performance, and calling them directly from the inference console
Required permission: View
This screen runs a model version's serving image on the central cluster and offers it as an HTTP inference API (endpoint). An endpoint runs as a Kubernetes Deployment, and the platform forwards requests to it. Every member can view; creating and deleting endpoints needs deploy, and stopping, restarting and calling inference need operate.
To create an endpoint, you must first build the serving image on the version screen of the Model registry.
Endpoint list
| # | Area | Description |
|---|---|---|
| ① | Create serving (서빙 생성) | Endpoint creation dialog (deploy). |
| ② | Go to model registry (모델 레지스트리로) | Shortcut shown when there are no endpoints at all. |
Existing endpoints appear as cards. A card shows the name and status, RPS, P95(ms), Error(%), Ready, the model version and the number of GPUs used; if the endpoint misses the validation KPI, a KPI not met (KPI 미달) chip is attached (the service keeps running).
Create an endpoint
- Press Create serving (서빙 생성).
- Set the endpoint name (엔드포인트 이름) (lowercase letters, digits and hyphens, at most 63 characters — it becomes a Kubernetes object name), image (이미지) (only model versions whose build has finished are listed), Replicas, resources (실행 자원) (CPU or GPU slots) and Validation dataset (Validation 데이터셋) (optional — if set, a KPI smoke test (a short functional check) runs after deployment), then press Create (생성).
Create a serving endpoint — name, built image, replicas, resources and validation dataset - You move to the endpoint detail, which shows the rollout progress deploy → connect → validate → run (배포 → 연결 → 검증 → 가동).
Endpoint detail and inference console
The detail screen shows the status and the cause of any problem, the exposed port (NodePort) and the number of ready replicas, Stop (중단) and, once stopped, Restart (재기동) (operate) and Delete (삭제) (deploy; you must type the name once more), and the inference console (추론 콘솔).
In the inference console, enter input that matches the model's input format (image upload, text or table, or a JSON body) and call real inference with invocations (invocations). ping (ping) checks that it is alive and version (version) checks the version being served. For a detection model, results are drawn over the image as boxes, masks and labels, and you can filter them with the confidence threshold slider. Once requests have accumulated, RPS and latency charts appear below, together with the distribution of status codes (2xx, 4xx, 5xx).
Statuses and badges
| Badge | Value | Meaning |
|---|---|---|
| Deploying (배포 중) | DEPLOYING | Creating the Deployment and starting pods |
| Connecting (연결 중) | CONNECTING | Pods are up; the platform is checking the connection |
| Validating (검증 중) | VALIDATING | Running the KPI smoke test with the validation dataset |
| Available (정상) | AVAILABLE | Can accept requests |
| Degraded (성능 저하) | DEGRADED | Responds, but health checks have worsened — returns to Available when it recovers |
| Stopped (중단) | STOPPED | Stopped by a user. Bring it back with Restart (재기동) |
| Failed (실패) | FAILED | Failed at some step |
Failed and degraded states come with a cause — for example "The container is restarting repeatedly (컨테이너가 반복 재시작 중)" (CrashLoopBackOff), "The image cannot be pulled (이미지를 받지 못하는 중)" (ImagePullBackOff), "Deployment progress has stalled (배포 진행이 멈춤)" (ProgressDeadlineExceeded).