SageMaker Endpoint Leerlaufkosten sind Instanzstunden eines Inferenz-Endpunkts, der bereitsteht und keine Anfrage bekommt; dasselbe Muster heißt bei Vertex AI Knotenstunden eines Endpunkts mit bereitgestelltem Modell, bei Azure OpenAI und Microsoft Foundry Provisioned Throughput Units, die stündlich laufen, ob Token fließen oder nicht, und bei Amazon Bedrock Model Units mit Stundenpreis. Die Einsparung entsteht, weil ein Endpunkt ohne Aufrufe abgebaut, auf null skaliert oder durch eine Serverless- oder Token-basierte Variante ersetzt wird, und weil reservierter Durchsatz ohne Last zu einem Pay-per-Token-Deployment zurückkehrt. Die Behebung gehört dem Team, das das Modell betreibt, weil nur dort bekannt ist, welche Latenz ein Nutzer erwartet.

Symptom

Die Rechnung zeigt Endpunkt- und Kapazitätsstunden ohne Aufrufe. Bei AWS sind das lineItem/UsageType nach dem Muster EUC1-Host:ml.g5.xlarge unter AmazonSageMaker mit product/component Hosting, mit 720 Stunden je Endpunkt, und unter AmazonBedrock die Stunden je Model Unit eines Provisioned Throughput. Bei Azure sind es MeterCategory Azure OpenAI oder Foundry mit PTU-Stundenmetern je Deployment, die mit dem Anlegen beginnen und mit dem Löschen enden. In Google Cloud trägt Vertex AI die SKUs für Online-Vorhersage je Maschinentyp und Knotenstunde, von der Bereitstellung bis zum Abbau. Was KI-Dienste grundsätzlich berechnen, steht in KI- und Machine-Learning-Diensten und im Glossar unter Provisioned Throughput Unit; diese Seite behandelt Endpunkte und Durchsatz ohne Nutzung.

Angelegt, bereitgestelltoder gekauftAb dann zählen die Stunden:Host-Stunden je Endpunkt,Stunden je Model Unit, PTU-Stunden je Deployment,KnotenstundenBis zum Löschenoder AbbauAufrufe daneben: keineS
Endpunkt- und Durchsatzstunden laufen vom Anlegen bis zum Löschen, aufgerufen oder nicht, darum sind Stunden ohne Aufrufe das Symptom

So erkennen Sie es

AWS

Die Endpunkte mit Status und ihre Instanzen:

aws sagemaker list-endpoints --status-equals InService --query 'Endpoints[].[EndpointName,CreationTime,LastModifiedTime]' --output table
aws sagemaker describe-endpoint --endpoint-name <endpoint> --query 'ProductionVariants[].[VariantName,CurrentInstanceCount,CurrentWeight]' --output table

Die Aufrufe eines Endpunkts über zwei Wochen, als Summe je Tag:

aws cloudwatch get-metric-statistics --namespace AWS/SageMaker --metric-name Invocations \
  --dimensions Name=EndpointName,Value=<endpoint> Name=VariantName,Value=AllTraffic --statistics Sum \
  --start-time 2026-10-07T00:00:00Z --end-time 2026-10-21T00:00:00Z --period 86400

Compute Optimizer stuft einen SageMaker-Endpunkt als ungenutzt ein, der über 14 Tage null Aufrufe hatte, und empfiehlt Scale-to-Zero für Inferenzkomponenten oder das Löschen (gelesen am 2026-10-21): aws compute-optimizer get-idle-recommendations --filters name=ResourceType,values=SageMakerEndpoint. Der reservierte Durchsatz bei Bedrock wird je Model Unit und Stunde berechnet, ohne Commitment jederzeit löschbar, mit Commitment von einem oder sechs Monaten erst danach, und läuft, bis er gelöscht wird (Provisioned Throughput in Amazon Bedrock):

aws bedrock list-provisioned-model-throughputs --query 'provisionedModelSummaries[].[provisionedModelName,modelArn,modelUnits,commitmentDuration,status]' --output table

In den Abrechnungsdaten ist der Kandidat eine Host-Position mit vollen Stunden ohne Invocations und eine Bedrock-Position je Model Unit ohne Token-Positionen daneben (AWS Cost and Usage Report).

Azure

Die Deployments je Ressource mit SKU und Kapazität:

az cognitiveservices account deployment list --name <account> --resource-group <rg> \
  --query "[].{name:name, model:properties.model.name, sku:sku.name, capacity:sku.capacity}" -o table

Deployments mit den SKUs ProvisionedManaged, DataZoneProvisionedManaged und GlobalProvisionedManaged sind reservierter Durchsatz: sie werden je PTU und Stunde berechnet, unabhängig von den verbrauchten Token, vom Anlegen bis zum Löschen, und eine Reservierung über einen Monat oder ein Jahr senkt den Satz, ohne Kapazität zu sichern (Provisioned Throughput in Microsoft Foundry). Die Metrik Provisioned-managed Utilization V2 je Deployment zeigt die Auslastung; ein Deployment, das tagelang unter 10 Prozent bleibt, ist der Kandidat. Azure Advisor empfiehlt Reservierungen für Provisioned Throughput, keine Abschaltung. Im Kostenexport ist der Kandidat ein Deployment mit PTU-Stundenmeter ohne Token-Meter (Azure-Kostenexporte).

Google Cloud

Die Endpunkte je Region und die bereitgestellten Modelle mit Maschinentyp und Replikaten:

gcloud ai endpoints list --region=<region> --format="table(name.basename(),displayName,createTime,deployedModels[].id.list())"
gcloud ai endpoints describe <endpoint-id> --region=<region> --format="yaml(deployedModels[].dedicatedResources)"

Ein bereitgestelltes Modell berechnet Knotenstunden nach Maschinentyp und minReplicaCount vom Zeitpunkt der Bereitstellung bis zum Abbau, ob Anfragen kommen oder nicht; die Metrik aiplatform.googleapis.com/prediction/online/prediction_count je Endpunkt über zwei Wochen ist der Nachweis. Einen Recommender für Endpunkte gibt es nicht. Im Abrechnungsexport ist der Kandidat eine Online-Vorhersage-SKU mit vollen Knotenstunden je resource.name (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Je Endpunkt und Deployment die Aufrufe je Tag und die Latenzanforderung festhalten; ein Endpunkt mit null Aufrufen über 14 Tage wird abgebaut, einer mit wenigen Aufrufen am Tag wechselt die Betriebsart, einer mit gleichmäßiger Last bleibt und bekommt die richtige Größe.
  2. Abbauen: aws sagemaker delete-endpoint --endpoint-name <endpoint>, bei Bedarf mit delete-endpoint-config; aws bedrock delete-provisioned-model-throughput --provisioned-model-id <id> für Durchsatz ohne Commitment; az cognitiveservices account deployment delete --name <account> --resource-group <rg> --deployment-name <deployment>; gcloud ai endpoints undeploy-model <endpoint-id> --region=<region> --deployed-model-id=<deployed-model-id>. Keiner dieser Aufrufe hat ein Dry-Run; die Liste aus der Erkennung ersetzt es, und die Modellartefakte bleiben in S3, Blob Storage oder der Model Registry erhalten.
  3. Die Betriebsart wechseln, wo die Last unregelmäßig ist: SageMaker Serverless Inference oder ein Endpunkt mit Inferenzkomponenten und einer Mindestinstanzzahl von null, die bei Leerlauf auf null skaliert; bei Azure ein Standard-Deployment je Token statt PTUs, mit Spillover als Puffer für Spitzen; bei Bedrock On-Demand je Token statt Model Units; bei Vertex AI ein kleinerer Maschinentyp, weniger Replikate oder ein Batch-Vorhersagejob statt eines stehenden Endpunkts.
  4. Die Vorlage korrigieren: Endpunkte aus Experimenten bekommen ein Ablaufdatum und ein Tag mit Verantwortlichem; reservierter Durchsatz wird erst gekauft, wenn ein Token-Deployment die Last über Wochen gezeigt hat, nach der Regel von Provisioned Throughput gegen Pay-as-you-go.

Die Stunden enden mit dem Abbau; der Tagesexport zeigt es am Folgetag.

keineeinigejanein: wenige am TagJe Endpunkt und Deployment:Aufrufe je Tag und dieLatenzanforderungAufrufe über14 Tage?Abbauen: kein Dry-Run,die Liste ersetzt es; dieModellartefakte bleibenGleichmäßige Last?Bleibt und bekommtdie richtige GrößeDie Betriebsart wechseln:Serverless oder auf nullskalieren, je Token stattPTUs oder Model Units, Batchstatt stehendem EndpunktDie Vorlage korrigieren:Ablaufdatum und Tag mitVerantwortlichem fürExperimente; reservierterDurchsatz erst nach Wochengezeigter Last
Keine Aufrufe heißt Abbau, unregelmäßige Last wechselt die Betriebsart, gleichmäßige Last behält den Endpunkt, und die Vorlage sichert neue ab

Risiken und Nebenwirkungen

  • Null auf dem Endpunkt heißt Kaltstart beim ersten Aufruf: Minuten für ein großes Modell, bis die Instanz steht und die Gewichte geladen sind. Ein Dienst mit Latenzzusage braucht die Instanz oder eine Serverless-Variante mit bereitgehaltener Kapazität.
  • Reservierter Durchsatz mit Commitment läuft bis zum Ende der Laufzeit, auch ohne Last; die Frage ist dann, ob andere Workloads ihn nutzen, nicht ob er gelöscht wird.
  • Kapazität ist nicht zugesichert: ein gelöschtes PTU-Deployment oder eine freigegebene GPU-Instanz ist später vielleicht nicht in derselben Region verfügbar. Wer nur Zeit sparen will, skaliert statt zu löschen.
  • GPU-Instanzen im Leerlauf sind dasselbe Muster auf einer anderen Ebene; wie Trainings- und Serving-Cluster ihre GPUs auslasten, steht in GPU-Kosten.
  • Modellartefakte und Logs eines gelöschten Endpunkts bleiben im Speicher; ihre Aufbewahrung ist ein eigener Fall (Objektspeicher ohne Lifecycle-Regeln).

So weisen Sie die Einsparung nach

Vorher: je Endpunkt und Deployment die Instanz-, Knoten- oder Einheitenstunden und ihr Betrag im letzten vollen Monat, daneben die Aufrufe und die Auslastung. Nachher: dieselben Ressourcen im ersten vollen Monat nach Abbau oder Wechsel; die Stundenposition muss auf null fallen, und an ihre Stelle tritt eine Token- oder Serverless-Position, die mit den Aufrufen wächst. Die Stundenposition ohne Aufrufe ist die Schätzung, die Freigabe des Teams macht sie akzeptiert, der Abbau umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Die Auslastung des reservierten Durchsatzes und die Zahl der Endpunkte ohne Aufrufe sind die Kennzahlen für das Kostenreview.

Quellen

Gelesen am 2026-10-21. Compute Optimizer, Leerlaufressourcen, Provisioned Throughput in Amazon Bedrock, aws sagemaker, Provisioned Throughput in Microsoft Foundry, Azure Advisor, Kostenempfehlungen, az cognitiveservices account deployment, Vertex AI, Rechenressourcen für Inferenz, gcloud ai endpoints.