Aangepaste containermodellen implementeren op vertex ai: een productiehandleiding

Voordat we beginnen, moet u ervoor zorgen dat uw lokale omgeving en google cloud-project zijn ingesteld. Ik ga ervan uit dat u beschikt over:

• google cloud-project: met ingeschakelde facturering.
• gcloud cli: geïnstalleerd en geconfigureerd (versie 460.0.0 of hoger).
• docker: desktop of engine geïnstalleerd.
• python: 3.12+ en pip.
• terraform cli: geïnstalleerd (versie 1.7.0 of hoger).
• basisbegrip: van machine learning-concepten, docker en gcp.

• gcloud cli
• docker
• python 3.12+
• terraform cli
• google cloud sdk voor python (google-cloud-aiplatform)

Eerst controleer ik of mijn gcloud-configuratie verwijst naar mijn doelproject en -regio. Ik standaardiseer meestal op europe-west4 voor mijn eu-implementaties.

gcloud config set project $(gcloud config get-value project)
gcloud config set region europe-west4
gcloud auth application-default login

Het serviceaccount dat ik gebruik voor terraform- en gcloud-bewerkingen heeft specifieke iam-rollen nodig. Voor de initiële configuratie wordt vaak roles/owner gebruikt, maar voor productie pas ik het principe van het minste privilege toe, met een combinatie van de volgende rollen:

• `roles/resourcemanager.projectiamadmin

*

roles/serviceusage.serviceusageadmin

*

roles/compute.networkadmin

*

roles/aiplatform.admin

*

roles/artifactregistry.admin

*

roles/storage.admin

*

roles/logging.configwriter

*

roles/monitoring.editor

*

roles/accesscontextmanager.policyadmin`

Om mijn afhankelijkheden schoon en geïsoleerd te houden, maak en activeer ik altijd een speciale python virtuele omgeving voor elk project. Dit voorkomt conflicten en zorgt voor reproduceerbaarheid.

python3.12 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install google-cloud-aiplatform==1.42.0 google-cloud-storage==2.10.0 flask==3.0.3 gunicorn==22.0.0 transformers==4.38.2 torch==2.2.1 sentencepiece==0.1.99

Mijn eerste stap is het provisioneren van infrastructuur met behulp van infrastructure as code. Hiervoor gebruik ik terraform. Het helpt me reproduceerbaarheid te garanderen, versiebeheer te behouden en alles in mijn gekozen eu-regio te houden. Ik stel project api-activering, een aangepast vpc-netwerk, een serverloze vpc-toegangsconnector, een speciaal serviceaccount voor vertex ai en een artifact registry-repository in. Deze componenten zijn cruciaal voor een veilige en private modelimplementatie.

Om deze te provisioneren, definieer ik ze in mijn main.tf, variables.tf en terraform.tfvars-bestanden.

# main.tf
provider "google" {
  project = var.project_id
  region  = var.region
}

resource "google_project_service" "api_services" {
  for_each = toset([
    "artifactregistry.googleapis.com",
    "compute.googleapis.com",
    "containerregistry.googleapis.com", # voor backward compatibility met docker.
    "aiplatform.googleapis.com",
    "vpcaccess.googleapis.com",
    "cloudbuild.googleapis.com",
    "cloudresourcemanager.googleapis.com",
    "accesscontextmanager.googleapis.com", # voor vpc-servicecontroles
    "logging.googleapis.com",
    "monitoring.googleapis.com"
  ])
  service = each.key
  project = var.project_id
  disable_on_destroy = false
}

resource "google_compute_network" "vpc_network" {
  project = var.project_id
  name    = "vertex-ai-custom-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "vpc_subnetwork" {
  project       = var.project_id
  name          = "vertex-ai-custom-subnet"
  ip_cidr_range = "10.10.0.0/20"
  region        = var.region
  network       = google_compute_network.vpc_network.id
}

resource "google_vpc_access_connector" "connector" {
  project = var.project_id
  name    = "vertex-ai-connector"
  region  = var.region
  ip_cidr_range = "10.8.0.0/28"
  network = google_compute_network.vpc_network.id

  depends_on = [
    google_project_service.api_services["vpcaccess.googleapis.com"]
  ]
}

resource "google_service_account" "vertex_sa" {
  project      = var.project_id
  account_id   = "vertex-ai-model-deployer"
  display_name = "serviceaccount voor vertex ai-modelimplementatie"
}

resource "google_project_iam_member" "vertex_sa_permissions" {
  for_each = toset([
    "roles/aiplatform.user",
    "roles/artifactregistry.writer",
    "roles/storage.objectadmin",
    "roles/logging.logwriter",
    "roles/monitoring.metricwriter",
    "roles/compute.networkuser" # vereist voor vpc-toegang
  ])
  project = var.project_id
  role    = each.key
  member  = "serviceaccount:${google_service_account.vertex_sa.email}"
}

resource "google_artifact_registry_repository" "model_repo" {
  project       = var.project_id
  location      = var.region
  repository_id = "vertex-ai-model-images"
  description   = "docker images voor vertex ai-aangepaste modelbediening"
  format        = "docker"

  depends_on = [
    google_project_service.api_services["artifactregistry.googleapis.com"]
  ]
}

# variables.tf
variable "project_id" {
  description = "de id van het google cloud-project."
  type        = string
}

variable "region" {
  description = "de gcp-regio voor implementaties (bijv. europe-west4)."
  type        = string
  default     = "europe-west4"
}

variable "access_policy_number" {
  description = "het toegangsbeleidsnummer van uw organisatie voor vpc-servicecontroles. vind dit met `gcloud access-context-manager policies list --organization organization_id`."
  type        = string
}

variable "model_display_name" {
  description = "weergavenaam voor het vertex ai-model."
  type        = string
  default     = "sentimentanalysismodel"
}

variable "vertex_model_resource_name" {
  description = "volledige vertex ai-modelresourcenaam van stap 3 (gcloud ai models list --format='value(name)')."
  type        = string
}

# terraform.tfvars (voorbeeld)
project_id           = "my-gcp-project-id"
region               = "europe-west4"
access_policy_number = "123456789"
model_display_name   = "sentimentanalysismodel"
vertex_model_resource_name = "projects/your_project_number/locations/europe-west4/models/your_model_id"

Nadat ik deze bestanden heb ingesteld, voer ik terraform uit om de resources te provisioneren:

terraform init
terraform plan
terraform apply --auto-approve

Verwachte uitvoer:

apply complete! resources: 10 added, 0 changed, 0 destroyed.

Problemen oplossen: * error 403: the caller does not have permission: ik zou dubbel controleren of mijn gcloud geauthenticeerde gebruiker roles/owner of de specifieke iam-rollen heeft die ik in de vereisten heb vermeld. * api not enabled: ik zou controleren of alle vereiste google_project_service-resources correct zijn vermeld en ingeschakeld in mijn main.tf.

Vervolgens moet ik mijn model en de serving-logica inpakken in een lichtgewicht, geoptimaliseerde docker-container. Ik gebruik een voorgegetraind sentimentanalysemodel van hugging face (distilbert-base-uncased-finetuned-sst-2-english) dat wordt aangeboden via een flask-applicatie. De sleutel hier is om de image klein te houden en snelle opstarttijden te garanderen voor efficiënte schaalvergroting.

Eerst download ik de modelartefacten lokaal naar een model/ directory:

# download_model.py
from transformers import pipeline

# laad een voorgegetraind sentimentanalysemodel
sentiment_pipeline = pipeline("sentiment-analysis", model="distilbert-base-uncased-finetuned-sst-2-english")

# sla het model en de tokenizer op
sentiment_pipeline.model.save_pretrained("model/")
sentiment_pipeline.tokenizer.save_pretrained("model/")
print("model saved to ./model/")

python download_model.py

Daarna maak ik mijn predict.py flask-applicatie en de bijbehorende dockerfile aan:

# predict.py
import os
from flask import flask, request, jsonify
from transformers import pipeline

app = flask(__name__)

# laad het model globaal om herladen bij elke aanvraag te voorkomen
def load_model():
    model_path = os.environ.get('aip_model_dir', './model/')
    print(f"loading model from: {model_path}")
    return pipeline("sentiment-analysis", model=model_path)

sentiment_pipeline = load_model()

@app.route('/ping', methods=['get'])
def ping():
    return jsonify({'status': 'healthy'})

@app.route('/predict', methods=['post'])
def predict():
    try:
        instances = request.json['instances']
        if not isinstance(instances, list):
            return jsonify({'error': 'instances must be a list of strings'}), 400

        results = sentiment_pipeline(instances)
        return jsonify({'predictions': results})
    except exception as e:
        return jsonify({'error': str(e)}), 500

if __name__ == '__main__':
    # gebruik gunicorn in productie voor robuustheid
    app.run(host='0.0.0.0', port=os.environ.get('aip_http_port', 8080))

# dockerfile
# gebruik een slanke python 3.12-image voor een kleinere grootte
from python:3.12-slim-bookworm as builder

# installeer build dependencies voor transformers
run apt-get update && apt-get install -y --no-install-recommends \n    build-essential \n    curl \n    && rm -rf /var/lib/apt/lists/*

# stel de werkdirectory in
workdir /app

# kopieer het requirements-bestand en installeer afhankelijkheden
copy requirements.txt .
run pip wheel --no-cache-dir --no-deps --wheel-dir /app/wheels -r requirements.txt

# finale image
from python:3.12-slim-bookworm

# installeer runtime-afhankelijkheden van wheels
workdir /app
copy --from=builder /app/wheels /app/wheels
copy --from=builder /usr/lib/python3.12/site-packages /usr/lib/python3.12/site-packages
run pip install --no-cache-dir --no-index --find-links=/app/wheels -r requirements.txt

# kopieer applicatiecode en model
copy predict.py .
copy model/ ./model/

# exposeer de poort die vertex ai verwacht
env aip_http_port=8080
expose 8080

# opdracht om de predictieserver te starten met gunicorn
entrypoint ["gunicorn", "--bind", "0.0.0.0:8080", "predict:app", "--timeout", "90", "--workers", "2"]

# requirements.txt
flask==3.0.3
gunicorn==22.0.0
transformers==4.38.2
torch==2.2.1
sentencepiece==0.1.99 # vereist door sommige hugging face-modellen

Nu bouw ik de docker-image en push deze naar mijn artifact registry-repository:

project_id=$(gcloud config get-value project)
region="europe-west4"
repo_name="vertex-ai-model-images"
image_name="sentiment-model-server:v1.0.0"

docker build -t ${region}-docker.pkg.dev/${project_id}/${repo_name}/${image_name} .

gcloud auth configure-docker ${region}-docker.pkg.dev
docker push ${region}-docker.pkg.dev/${project_id}/${repo_name}/${image_name}

export container_image_uri=${region}-docker.pkg.dev/${project_id}/${repo_name}/${image_name}
echo "container image pushed: ${container_image_uri}"

Verwachte uitvoer:

the push refers to repository [europe-west4-docker.pkg.dev/your-gcp-project-id/vertex-ai-model-images/sentiment-model-server]
... (layers pushed) ...
v1.0.0: digest: sha256:... size: ...
container image pushed: europe-west4-docker.pkg.dev/your-gcp-project-id/vertex-ai-model-images/sentiment-model-server:v1.0.0

Problemen oplossen: * denied: permission denied for repository: ik zou ervoor zorgen dat het serviceaccount of de geauthenticeerde gebruiker de artifact registry writer-rol heeft. * docker build fails: ik zou requirements.txt controleren op typefouten of ontbrekende afhankelijkheden en ervoor zorgen dat build-essential correct is geïnstalleerd in de builder-fase.

Vertex ai model registry is mijn gecentraliseerde hub voor het opslaan en versioneren van ml-modellen. Door hier mijn containerimage en de bijbehorende modelartefacten te registreren, kan vertex ai de levenscyclus van het model beheren en implementaties vereenvoudigen. Voor dit voorbeeld heb ik de modelgewichten direct in de containerimage gebakken voor de eenvoud. Voor grotere modellen zou ik ze meestal uploaden naar cloud storage (gcs) en de container ze bij het opstarten laten ophalen.

project_id=$(gcloud config get-value project)
region="europe-west4"
model_display_name="sentimentanalysismodel"

# registreer het model bij vertex ai model registry
gcloud ai models upload \n  --project=${project_id} \n  --region=${region} \n  --display-name=${model_display_name} \n  --container-image-uri=${container_image_uri} \n  --container-command='["gunicorn", "--bind", "0.0.0.0:8080", "predict:app", "--timeout", "90", "--workers", "2"]' \n  --container-predict-route="/predict" \n  --container-health-route="/ping" \n  --container-ports=8080 \n  --description="sentimentanalysemodel geïmplementeerd via aangepaste container"

# de werkelijke model-id is een lang nummer. ik heb deze nodig voor terraform.
# ik sla de volledige resourcenaam (inclusief project en locatie) op voor later gebruik.
export model_resource_name=$(gcloud ai models list --project=${project_id} --region=${region} --filter="displayname=${model_display_name}" --format="value(name)")
echo "model geregistreerd met resourcenaam: ${model_resource_name}"

Verwachte uitvoer:

model [projects/your_project_number/locations/europe-west4/models/your_model_id] uploaded.
... (details) ...
model registered with resource name: projects/your_project_number/locations/europe-west4/models/your_model_id

Problemen oplossen: * 403 permission denied: ik zou ervoor zorgen dat het serviceaccount roles/aiplatform.user heeft. * invalid image uri: ik zou de container_image_uri-variabele controleren op juistheid.

Om maximale beveiliging te garanderen en data-exfiltratie te voorkomen, implementeer ik mijn modellen altijd op een vertex ai-endpoint binnen een vpc service controls-perimeter. Dit isoleert mijn data en resources, waardoor ze ontoegankelijk worden van buiten mijn gedefinieerde perimeter. Het endpoint zal ook een privé-ip gebruiken voor inferentieaanvragen, waardoor het verkeer strikt binnen mijn vpc blijft. Dit is een cruciale stap voor gdpr-naleving en algehele databeveiliging in de eu.

Ik voeg de volgende resources toe aan mijn main.tf om de vpc-servicecontroles-perimeter en het vertex ai-endpoint te definiëren. Het model zelf wordt gerefereerd door de volledige resourcenaam van stap 3 (var.vertex_model_resource_name) wanneer ik gcloud ai endpoints deploy-model uitvoer nadat terraform het endpoint heeft gemaakt.

# main.tf (toevoegen aan vorig terraform-bestand)
#
# de hashicorp google-provider omvat google_vertex_ai_endpoint en vpc-servicecontroles,
# maar er is geen gegevensbron met de naam google_ai_models en geen resource google_vertex_ai_endpoint_model.
# nadat terraform het endpoint heeft gemaakt, implementeert u het model van stap 3 met gcloud (shell-blok hieronder).

resource "google_access_context_manager_service_perimeter" "vertex_ai_perimeter" {
  name        = "accesspolicies/${var.access_policy_number}/serviceperimeters/vertex_ai_perimeter_v1"
  title       = "vertex-ai-perimeter-v1"
  description = "vpc-servicecontroles-perimeter voor vertex ai"
  perimeter_type = "regular"

  status {
    restricted_services = [
      "aiplatform.googleapis.com",
      "artifactregistry.googleapis.com",
      "storage.googleapis.com",
      "cloudbuild.googleapis.com" # vereist als cloud build wordt gebruikt binnen de perimeter
    ]
    vpc_accessible_services {
      enable_restriction = true
      allowed_services   = [
        "restricted_services"
      ]
    }
  }

  # ingress/egress-beleid kan hier worden gedefinieerd voor fijnmazige controle
  # bijvoorbeeld om specifieke serviceaccounts of ip-bereiken toe te staan om met resources binnen de perimeter te interageren.
  # policy_data {
  #   ingress_policies {
  #     ingress_from {
  #       sources {
  #         resource = "projects/${var.project_id}"
  #       }
  #       identities = [
  #         "serviceaccount:${google_service_account.vertex_sa.email}"
  #       ]
  #     }
  #     ingress_to {
  #       resources = [
  #         "projects/${var.project_id}"
  #       ]
  #       operations {
  #         service_name = "aiplatform.googleapis.com"
  #         method_selectors {
  #           method = "*"
  #         }
  #       }
  #     }
  #   }
  # }

  depends_on = [
    google_project_service.api_services["accesscontextmanager.googleapis.com"]
  ]
}

resource "google_vertex_ai_endpoint" "sentiment_endpoint" {
  project         = var.project_id
  location        = var.region
  display_name    = "sentiment-analysis-endpoint"
  description     = "endpoint voor sentimentanalysemodel via aangepaste container"
  network         = google_compute_network.vpc_network.id # koppelen aan het vpc-netwerk
  service_account = google_service_account.vertex_sa.email

  depends_on = [
    google_access_context_manager_service_perimeter.vertex_ai_perimeter, # zorg ervoor dat perimeter bestaat
    google_project_iam_member.vertex_sa_permissions["roles/compute.networkuser"]
  ]
}

Nadat terraform apply het endpoint heeft gemaakt, implementeert u het geregistreerde model (numerieke id) naar dat endpoint:

project_id=$(gcloud config get-value project)
region="europe-west4"
# instellen vanuit stap 3 export of vanuit terraform.tfvars (variabele vertex_model_resource_name), bijv.:
# export vertex_model_resource_name="projects/123/locations/europe-west4/models/4567890123456789012"
: "${vertex_model_resource_name:?instellen op volledige modelnaam van stap 3}"

endpoint_num="$(gcloud ai endpoints list --project="${project_id}" --region="${region}" \n  --filter="displayname=sentiment-analysis-endpoint" --format="value(name)" | awk -f/ '{print $nf}')"
model_num="$(printf '%s' "${vertex_model_resource_name}" | awk -f/ '{print $nf}')"
service_account_email="vertex-ai-model-deployer@${project_id}.iam.gserviceaccount.com"

gcloud ai endpoints deploy-model "${endpoint_num}" \n  --project="${project_id}" \n  --region="${region}" \n  --model="${model_num}" \n  --display-name="sentiment-model-v1" \n  --machine-type=n1-standard-4 \n  --min-replica-count=1 \n  --max-replica-count=2 \n  --traffic-split=0=100 \n  --service-account="${service_account_email}"

Stel vertex_model_resource_name in op var.vertex_model_resource_name (van terraform.tfvars) of op de model_resource_name die u in stap 3 hebt vastgelegd.

Voordat ik terraform uitvoer, zorg ik ervoor dat het model van stap 3 succesvol is geüpload. Daarna pas ik deze wijzigingen toe:

terraform apply --auto-approve

Verwachte uitvoer:

apply complete! resources: 3 added, 0 changed, 0 destroyed.
... (uitvoer die de aanmaak van het endpoint toont) ...

Problemen oplossen: * 403 permission denied by vpc service controls: ik zou ervoor zorgen dat mijn serviceaccount zich binnen de perimeter bevindt of expliciete ingress/egress-regels heeft die toegang toestaan. Ik zou ook controleren of alle relevante services (aiplatform.googleapis.com, storage.googleapis.com, artifactregistry.googleapis.com) binnen de perimeter beperkt zijn. * invalid network configuration: ik zou controleren of google_vertex_ai_endpoint.sentiment_endpoint.network correct verwijst naar mijn vpc-netwerk-id. * endpoint does not exist of model not found: dit betekent meestal dat de endpoint- of model-id die met gcloud ai endpoints deploy-model is gebruikt onjuist was, of dat de gcloud ai models upload in stap 3 niet was voltooid vóór de implementatie.

Efficiënt verkeer beheren en schalen is cruciaal voor elke productie-implementatie. Vertex ai-autoscaling en verkeerssplitsing worden geconfigureerd op het geïmplementeerde model (via gcloud of de rest api), niet via een google_vertex_ai_endpoint_model terraform-resource – dat resourcetype maakt geen deel uit van de hashicorp google-provider. Na de implementatie pas ik replica's (en optioneel autoscaling-metrische doelen) aan met gcloud ai endpoints mutate-deployed-model, en ik pas de verkeerssplitsing aan wanneer ik een tweede implementatie aan hetzelfde endpoint toevoeg. online prediction autoscaling-metrieken gebruiken namen als aiplatform.googleapis.com/prediction/online/cpu/utilization (zie google's autoscaling-referentie).

project_id=$(gcloud config get-value project)
region="europe-west4"
endpoint_num="$(gcloud ai endpoints list --project="${project_id}" --region="${region}" \n  --filter="displayname=sentiment-analysis-endpoint" --format="value(name)" | awk -f/ '{print $nf}')"
deployed_model_id="$(gcloud ai endpoints describe "${endpoint_num}" --project="${project_id}" --region="${region}" \n  --format="value(deployedmodels[0].id)")"

gcloud ai endpoints mutate-deployed-model "${endpoint_num}" \n  --project="${project_id}" \n  --region="${region}" \n  --deployed-model-id="${deployed_model_id}" \n  --min-replica-count=1 \n  --max-replica-count=10

Voor canary releases implementeer ik een andere modelversie naar hetzelfde endpoint, en stel vervolgens de verkeerskaart van het endpoint in (bijvoorbeeld 90 % / 10 %) met behulp van gcloud ai endpoints update of de api – zie de vertex ai docs voor verkeerssplitsing op multi-implementatie-endpoints. online prediction autoscaling-metrieken gebruiken namen zoals aiplatform.googleapis.com/prediction/online/cpu/utilization (zie google's autoscaling-referentie).

Verwachte uitkomst: replica-aantallen worden zonder terraform bijgewerkt; verifieer dit in de cloud console of met gcloud ai endpoints describe.

Robuuste monitoring en logging zijn onmisbaar voor operationele excellentie, en nog meer voor gdpr-naleving. Ik configureer cloud logging om alle voorspellingsverzoeken en -antwoorden vast te leggen, en deze logboeken naar een regionale sink te sturen. Bovendien schakel ik vertex ai model monitoring in om datadrift, conceptdrift en attributiedrift te detecteren, zodat mijn model na verloop van tijd accuraat blijft en naar verwachting presteert. Voor gdpr is het essentieel dat mijn logboeken in eu-regio's worden bewaard met passend beleid.

# main.tf (toevoegen aan vorig terraform-bestand)
# model monitoring-taken worden gemaakt via console, gcloud of de vertex ai api. de hashicorp
# google-provider definieert geen google_vertex_ai_model_monitoring_job. hieronder: eu-logbucket + sink.

resource "google_logging_project_sink" "vertex_ai_log_sink" {
  project = var.project_id
  name    = "vertex-ai-audit-log-sink"
  # ik stuur logboeken naar een gcs-bucket, en zorg ervoor dat deze zich in een eu-regio bevindt.
  destination = "storage.googleapis.com/${google_storage_bucket.log_bucket.name}"
  filter      = "resource.type=("aiplatform.googleapis.com/endpoint" or "aiplatform.googleapis.com/model")"

  depends_on = [
    google_project_service.api_services["logging.googleapis.com"],
    google_project_service.api_services["storage.googleapis.com"]
  ]
}

resource "google_storage_bucket" "log_bucket" {
  project       = var.project_id
  name          = "vertex-ai-log-bucket-${var.project_id}"
  location      = upper(var.region) # bijv. europe-west4
  force_destroy = false
  uniform_bucket_level_access = true

  # ik stel een retentiebeleid in voor gdpr-naleving, bijvoorbeeld 365 dagen.
  retention_policy {
    is_locked        = false
    retention_period = 31536000 # 365 dagen in seconden
  }
}

data "google_project" "project" {
  project_id = var.project_id
}

# geef het logging serviceaccount toestemming om naar de bucket te schrijven
resource "google_storage_bucket_iam_member" "log_bucket_iam" {
  bucket = google_storage_bucket.log_bucket.name
  role   = "roles/storage.objectcreator"
  member = "serviceaccount:service-${data.google_project.project.number}@gcp-sa-logging.iam.gserviceaccount.com"
}

Modelbewaking: ik maak een modelbewakingstaak aan in de google cloud console (vertex ai → endpoints → monitoring) of met gcloud ai model-monitoring-jobs create, gebruikmakend van basisgegevens en schema in eu gcs-buckets. Ik geef de deployed model-id door van gcloud ai endpoints describe. Het verwijderde terraform-blok gebruikte een resourcetype dat niet bestaat in de hashicorp-provider.

Opmerking over schema's en baselines: monitoring vergelijkt live verkeer met een baseline dataset en schema. Bewaar beide in een eu-bucket voor residentie; vertrouw niet op us-only sample uri's voor productie baselines.

Nu voer ik terraform opnieuw uit:

terraform apply --auto-approve

Verwachte uitvoer:

apply complete! resources: 3 added, 0 changed, 0 destroyed.

Problemen oplossen: * model monitoring job failed: ik zou controleren of het gcs_path voor het schema en de basisgegevens correct en toegankelijk is voor het vertex ai-serviceaccount. Ik zou ook controleren of de deployed_model_id overeenkomt met een actieve implementatie op het endpoint. * permission denied for logging sink: ik zou controleren of het cloud logging serviceaccount (service-project_number@gcp-sa-logging.iam.gserviceaccount.com) de storage object creator-machtigingen heeft voor de bestemmingsbucket.

Voor elke in de eu gevestigde organisatie is het garanderen van gegevenssoevereiniteit cruciaal voor gdpr-naleving en de naleving van initiatieven zoals de eu chips act. De eu chips act benadrukt het versterken van het halfgeleiderecosysteem van de eu, wat van invloed is op hoe organisaties on-premises versus cloud-inferentie voor gevoelige gegevens zouden kunnen overwegen. Door resources uitsluitend in eu-regio's te implementeren, behoud ik de controle over de gegevenslocatie. Ik heb alles geconfigureerd in europe-west4, maar europe-west1 zou ook werken. Ik zal de locaties snel verifiëren met gcloud-opdrachten:

project_id=$(gcloud config get-value project)
region="europe-west4"

echo "artifact registry-locatie controleren..."
gcloud artifacts repositories describe vertex-ai-model-images --location=${region} --project=${project_id} --format="value(location)"

echo "vertex ai endpoint-locatie controleren..."
gcloud ai endpoints describe sentiment-analysis-endpoint --region=${region} --project=${project_id} --format="value(location)"

echo "logbucket-locatie controleren..."
gcloud storage buckets describe gs://vertex-ai-log-bucket-${project_id} --format="value(location)"

echo "vpc access connector-locatie controleren..."
gcloud vpc-access connectors describe vertex-ai-connector --region=${region} --project=${project_id} --format="value(location)"

Verwachte uitvoer:

verifying artifact registry location...
europe-west4
verifying vertex ai endpoint location...
europe-west4
verifying log bucket location...
europe-west4
verifying vpc access connector location...
europe-west4

Deze verificatie bevestigt dat mijn infrastructuur voldoet aan de eu-vereisten voor gegevenssoevereiniteit, waardoor mijn ml-implementaties voldoen aan de gdpr.

Nu het model is geïmplementeerd en de monitoring is geconfigureerd, is het tijd om een voorbeeldvoorspellingsverzoek te initiëren om het endpoint te testen en de resultaten in cloud logging te observeren. Dit demonstreert de end-to-end inferentiestroom.

# predict_client.py
import os
from google.cloud import aiplatform

project_id = os.environ.get('project_id')
region = os.environ.get('region', 'europe-west4')
endpoint_name = os.environ.get('endpoint_name', 'sentiment-analysis-endpoint')

def predict_text_sentiment(project: str, location: str, endpoint_name: str, text_instances: list):
    aiplatform.init(project=project, location=location)

    # ik filter op display_name om er zeker van te zijn dat ik het juiste endpoint krijg
    endpoints = aiplatform.endpoint.list(filter=f"display_name="{endpoint_name}"")
    if not endpoints:
        raise valueerror(f"endpoint with display_name {endpoint_name} not found.")
    endpoint = endpoints[0]

    # het aanvraagformaat is afhankelijk van de implementatie van de /predict-route van mijn container
    # voor mijn flask-app verwacht het {'instances': ["tekst1", "tekst2"]}
    instances_payload = [{"instances": text_instances}]

    response = endpoint.predict(instances=instances_payload)

    print("voorspellingsantwoord:")
    for prediction in response.predictions:
        print(prediction)

if __name__ == '__main__':
    # voorbeeldzinnen voor sentimentanalyse
    sample_texts = [
        "dit is een geweldig product, ik hou ervan!",
        "de service was verschrikkelijk en ik ben erg teleurgesteld.",
        "het was een oké ervaring, noch goed noch slecht."
    ]

    print(f"voorspellingsverzoek verzenden naar {endpoint_name} in {region} voor project {project_id}")
    predict_text_sentiment(project_id, region, endpoint_name, sample_texts)

Ik ga het predictiescript uitvoeren:

project_id=$(gcloud config get-value project)
region="europe-west4"
endpoint_name="sentiment-analysis-endpoint"

export project_id
export region
export endpoint_name

python predict_client.py

Verwachte uitvoer:

prediction response:
{'label': 'positive', 'score': 0.9998...}
{'label': 'negative', 'score': 0.9996...}
{'label': 'positive', 'score': 0.8876...} # (neutraal kan als licht positief of negatief worden geclassificeerd, afhankelijk van het model)

Na het uitvoeren van de voorspelling navigeer ik naar cloud logging in mijn gcp console. Ik filter logboeken op resource.type="aiplatform.googleapis.com/endpoint" en resource.labels.endpoint_id="uw_endpoint_id_van_terraform_output" om mijn voorspellingsverzoeken en -antwoorden te zien. Dit verifieert dat mijn logging sink actief inferentiegegevens vastlegt.

Problemen oplossen: * 403 permission denied: ik zou controleren of het serviceaccount dat predict_client.py uitvoert (mijn gebruikersaccount als ik gcloud auth application-default login gebruik) roles/aiplatform.user en de benodigde netwerktoegang heeft als het niet binnen de vpc wordt uitgevoerd. * valueerror: endpoint with display_name... not found.: ik zou de endpoint_name- en region-variabelen dubbel controleren en ervoor zorgen dat mijn endpoint succesvol is geïmplementeerd.

• vpc service controls: zoals ik heb aangetoond, gebruik altijd vpc service controls voor gevoelige workloads om data-exfiltratie te voorkomen. dit creëert een sterke beveiligingsperimeter rond uw vertex ai-resources.
• minste bevoegdheid: verleen het vertex ai-serviceaccount alleen de absoluut noodzakelijke iam-rollen. ik vermijd roles/editor of roles/owner voor productiedeployments.
• geheimbeheer: sla api-sleutels, inloggegevens of gevoelige modelparameters op in secret manager, niet direct in uw containerimage of code.
• containerbeveiliging: scan uw docker-images regelmatig op kwetsbaarheden met behulp van artifact analysis of tools van derden. gebruik minimale basisimages zoals python:3.12-slim om het aanvalsoppervlak te verkleinen.
• modelbestuur: implementeer modelondertekening (bijv. met sigstore/cosign) om de integriteit en oorsprong van uw modelartefacten te verifiëren. zorg ervoor dat uitgebreide auditlogging is ingeschakeld in alle fasen van de ml-levenscyclus.

• machinetypes: selecteer geschikte machinetypes (n1-standard, a2-highgpu, enz.) voor uw workload. gpu-instanties versnellen de inferentie voor grote deep learning-modellen aanzienlijk.
• containeroptimalisatie: optimaliseer uw dockerfile voor grootte en koudstartprestaties. gebruik multi-stage builds, ruim onnodige bestanden op en laad modellen vooraf in het geheugen.
• batching: implementeer voor scenario's met hoge doorvoer request batching binnen uw predict.py om meerdere inferenties in één aanroep te verwerken, waardoor de overhead wordt verminderd.
• horizontale schaalvergroting: configureer min_replica_count en max_replica_count met agressieve autoscaling_metric_specs om verkeersschommelingen effectief af te handelen.

• regionale implementatie: implementeer modellen in regio's die geografisch dicht bij uw gebruikers liggen om de latentie te minimaliseren, met name in europe-west1 of europe-west4 voor eu-gebruikers.
• beheerde service: vertex ai is een beheerde service, die de onderliggende infrastructuurschaling afhandelt. mijn focus verschuift naar het optimaliseren van mijn container en model voor efficiëntie in plaats van het beheren van kubernetes-clusters.
• quotumbeheer: ik ben me altijd bewust van de quotas van vertex ai en compute engine. ik vraag proactief verhogingen aan als ik zeer hoge verkeersvolumes verwacht.

• dashboards: ik maak aangepaste dashboards in cloud monitoring om belangrijke metrieken zoals aanvraaglatentie, foutpercentages, cpu/gpu-gebruik en replica-aantal te visualiseren.
• waarschuwingsbeleid: ik stel gedetailleerd waarschuwingsbeleid in voor kritieke drempels (bijv. p99-latentie van meer dan 500 ms, foutpercentage boven 1%).
• logboekanalyse: ik gebruik cloud logging met bigquery-exports voor geavanceerde logboekanalyse en auditing.
• modelbewaking: het continu gebruiken van vertex ai model monitoring om datadrift, conceptdrift en verslechtering van de voorspellingskwaliteit te detecteren, is essentieel. proactieve modelbewaking kan de gemiddelde tijd om modelverslechtering te detecteren met 70% verminderen, wat een aanzienlijke operationele winst is.

a: ik bereik dit door verkeerssplitsing op mijn vertex ai-endpoint te gebruiken. ik implementeer de nieuwe modelversie (bijv. versie 1) op hetzelfde endpoint met 0% verkeer. zodra dit is geverifieerd, verschuif ik geleidelijk het verkeer (bijv. 5%, dan 25%, dan 100%) naar de nieuwe versie. dit maakt canary-releases en eenvoudige rollback mogelijk als er problemen optreden.

a: de prijsstelling van vertex ai voor aangepaste containermodellen is voornamelijk gebaseerd op machinetype, acceleratorgebruik en replica-aantal. een n1-standard-4 machinetype zonder gpu's kost bijvoorbeeld ongeveer €0,15/uur ($0,16/uur) in europe-west4. modelmonitoring brengt extra kosten met zich mee, ongeveer €0,01/1000 voorspellingsaanvragen ($0,01/1000) bemonsterd. met een wisselkoers van $1 ≈ €0,92, zou een klein n1-standard-4 endpoint dat 24/7 draait met 1 replica ongeveer €109,50/maand ($119,00/maand) kosten voor de instantie, plus aanvraagkosten. ik raadpleeg altijd de vertex ai-prijslijstpagina voor de meest actuele cijfers en specifieke regionale variaties.

a: ja, vertex ai ondersteunt gpu-compatibele machinetypes. ik zou accelerator_type (bijv. nvidia_tesla_t4) en accelerator_count specificeren in mijn machine_spec binnen het dedicated_resources-blok van mijn google_vertex_ai_endpoint_model terraform-resource. het is cruciaal dat mijn docker-image de benodigde gpu-drivers en bibliotheken (bijv. cuda, cudnn, nvidia container toolkit) bevat.

a: voor modellen groter dan een paar gb sla ik de modelartefacten op in een gcs-bucket. mijn aangepaste container predict.py downloadt deze artefacten vervolgens van gcs naar de /tmp-directory van de container tijdens het opstarten van de container. vertex ai voorziet automatisch in inloggegevens voor het serviceaccount van het geïmplementeerde model om toegang te krijgen tot gcs, waardoor het toegangsbeheer wordt vereenvoudigd.

a: vpc-servicecontroles creëren een beveiligingsperimeter die gegevensbeweging beperkt. resources binnen de perimeter (zoals mijn vertex ai-endpoint en gcs-buckets) kunnen alleen communiceren met andere resources binnen dezelfde perimeter of expliciet toegestane services. dit betekent dat clients die toegang krijgen tot het endpoint zich ofwel binnen de perimeter moeten bevinden (bijv. een vm in mijn vpc), of expliciet ingrastoegang moeten krijgen via een toegangsniveau. dit verbetert de gegevensbeveiliging aanzienlijk door ongeautoriseerde toegang en data-exfiltratie te voorkomen.

a: de eu chips act heeft tot doel de halfgeleiderindustrie van de eu te versterken. hoewel het voornamelijk gericht is op fabricage, heeft het implicaties voor gegevensverwerking en de veerkracht van de toeleveringsketen. voor mijn ml-implementaties moedigt het me aan om te overwegen waar mijn inferentieverwerking plaatsvindt. het gebruik van cloudregio's binnen de eu, zoals europe-west1 of europe-west4, zorgt ervoor dat gegevens binnen de eu-jurisdictie blijven, wat voordelig is voor naleving en het verminderen van geopolitieke risico's die verband houden met gegevensverwerkingslocaties, zelfs als de onderliggende chips wereldwijd worden ingekocht. het benadrukt de noodzaak van duidelijke gegevenssoevereiniteitsstrategieën in cloudoperaties.

a: begin 2026 is python 3.12+ de aanbevolen versie voor nieuwe ontwikkelingen. het biedt prestatieverbeteringen en nieuwe functies die bijdragen aan efficiëntere modelbediening. ik streef er altijd naar om de nieuwste stabiele python-versie te gebruiken die wordt ondersteund door mijn kern ml-bibliotheken (pytorch, tensorflow, transformers) om te profiteren van de nieuwste optimalisaties en beveiligingspatches.