Skip to main content
resource · gcp

Vertex AI Endpoint

live rule families
2
schedulable
no
category
ai-ml-services

Does ZopNight manage Vertex AI Endpoint?

A Vertex AI endpoint bills per node-hour for every serving node its deployed models hold, 24 hours a day, whether or not predictions arrive. ZopNight discovers endpoints through Cloud Asset Inventory, watches prediction traffic, and flags endpoints whose deployed models sit idle. The fix is undeploying the model, which releases the nodes.

A Vertex AI endpoint serves online predictions from deployed models on dedicated machines that bill per node-hour around the clock. Endpoints left serving after experiments end are a leading source of hidden ML spend.

Node-hours are the meter, predictions are not

The moment a model is deployed to an endpoint, Vertex AI provisions serving nodes of the machine type chosen at deployment and starts charging for each node-hour. Query volume never enters the calculation: an endpoint answering millions of predictions and an endpoint answering none pay identically for the same node count. Autoscaling can widen the fleet under load, but the configured minimum replica count is a floor the bill never drops below, and GPU-backed serving nodes multiply the stakes.

How ZopNight watches for idle serving

ZopDev discovers endpoints via Cloud Asset Inventory, monitors prediction traffic, and flags endpoints with idle deployed models in recommendations. Because the cost driver is the deployment rather than the endpoint shell, the signal that matters is a deployed model receiving no requests over the observation window, which is precisely what the idle-endpoint recommendation surfaces.

Undeploying is the lever that releases nodes

An endpoint is not schedulable in ZopNight: a deploy/undeploy executor exists internally, but the type is not exposed as schedulable. The effective action is undeploying models that no longer need to serve. Undeployment releases the serving nodes and ends their node-hour charges, while the model itself stays registered in the Model Registry and can be redeployed later. Deleting the empty endpoint shell afterwards is free hygiene.

How endpoints outlive their experiments

The recurring pattern is a model deployed for a demo, an A/B test, or a one-quarter experiment whose conclusion arrived months ago. Two variants show up constantly: a losing model version left co-deployed at a small traffic split after the winner was chosen, and a minimum replica count sized for a launch spike that never receded.

Reaching endpoints in the console

Google Cloud console → Vertex AI → Online prediction lists endpoints per region. Each endpoint’s page shows its deployed models, machine types, and replica counts (the numbers that decide the bill).

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·