je commence toujours par m'assurer que mon environnement local est à jour. cela implique de mettre à jour la cli gcloud et d'installer les bibliothèques python nécessaires :

gcloud components update --quiet
pip install google-cloud-aiplatform==1.42.0 google-cloud-billing==1.1.0 google-cloud-logging==3.9.0

ensuite, je configure mon projet par défaut et une région européenne appropriée. pour mon travail, j'opte souvent pour europe-west4 (groningen, pays-bas) pour son équilibre entre coût et disponibilité :

gcloud config set project your-gcp-project-id # replace with your actual gcp project id
gcloud config set compute/region europe-west4

vertex ai représente souvent une ligne importante sur ma facture. j'ai constaté que l'un des moyens les plus efficaces de réduire ces coûts est d'utiliser stratégiquement les remises pour utilisation engagée (cud) de compute engine pour les charges de travail prévisibles et stables, et les vm spot pour toute inférence par lots pouvant tolérer des interruptions.

vertex ai, en interne, utilise les ressources compute engine. cela signifie que nous pouvons appliquer les cud de compute engine au calcul sous-jacent. un engagement de 3 ans peut offrir des remises allant jusqu'à 50 %. pour les tâches par lots plus flexibles et imprévisibles, j'insiste toujours pour utiliser des vm spot, qui offrent une énorme remise de 60 à 91 % par rapport aux prix à la demande. cette stratégie exige une résilience architecturale, mais les économies en valent la peine.

achat de cud de compute engine

je souscris généralement aux cud au niveau du compte de facturation cloud. cela offre une flexibilité maximale, permettant à la remise de s'appliquer à tous les projets liés à ce compte de facturation. un engagement d'un an rapporte généralement une remise de 24 à 30 %, tandis qu'un engagement de 3 ans peut atteindre 42 à 50 % pour les ressources compute engine. par exemple, si je m'engage à 100 €/heure (108,70 $/heure) de dépenses flexibles compute engine, cela pourrait couvrir jusqu'à 185,19 €/heure (201,29 $/heure) d'utilisation à la demande après une remise de 46 %, selon la documentation cud flexible de gcp. c'est une évidence pour les charges de base prévisibles.

pour des informations plus détaillées, je me réfère toujours à l'aperçu officiel des remises pour utilisation engagée de compute engine.

déploiement de l'inférence par lots avec des vm spot

lorsque j'exécute des tâches de prédiction par lots, en particulier celles qui sont asynchrones ou peuvent être redémarrées, je les configure pour demander explicitement des vm préemptibles (spot) (voir tâches personnalisées vertex ai). c'est parfait pour les charges de travail où une interruption occasionnelle n'est pas un problème majeur. la manière la plus robuste que j'ai trouvée pour ce faire est de définir un customjob dans vertex ai, en spécifiant worker_pool_specs pour utiliser des répliques préemptibles.

from google.cloud import aiplatform

project_id = "your-gcp-project-id" # replace with your actual gcp project id
region = "europe-west4"
container_image_uri = "gcr.io/your-gcp-project-id/my-batch-inference-container:latest" # replace with your container image uri
input_uri = "gs://your-input-bucket/input_data.jsonl" # replace with your gcs input path
output_uri = "gs://your-output-bucket/output_predictions/" # replace with your gcs output path
job_display_name = "batch-inference-spot-job"

aiplatform.init(project=project_id, location=region)

def deploy_batch_prediction_with_spot(project_id, region, display_name, container_image_uri, input_uri, output_uri):
    # i define the worker pool spec to explicitly request a preemptible vm.
    # setting replica_count=0 and preemptible_replica_count=1 ensures the job runs on a spot vm.
    worker_pool_specs = [
        {
            "machine_spec": {
                "machine_type": "n1-standard-4",
            },
            "replica_count": 0, # no dedicated, on-demand replicas
            "preemptible_replica_count": 1, # request one spot/preemptible replica
            "container_spec": {
                "image_uri": container_image_uri,
                # pass arguments to your container, e.g., pointing to input/output data
                "args": [
                    f"--input_file={input_uri}",
                    f"--output_prefix={output_uri}",
                ],
            },
        }
    ]

    # create and run the custom job
    custom_job = aiplatform.customjob(
        display_name=display_name,
        worker_pool_specs=worker_pool_specs,
        project=project_id,
        location=region,
    )

    custom_job.run()
    print(f"custom batch prediction job submitted: {custom_job.resource_name}")
    print(f"job state: {custom_job.state}")
    return custom_job

# to run this, uncomment the following lines and ensure your container and data paths are correct.
# batch_job = deploy_batch_prediction_with_spot(project_id, region, job_display_name, container_image_uri, input_uri, output_uri)
# batch_job.wait() # wait for the job to complete

ce fragment de code python démontre comment je soumets une customjob pour l'exécuter explicitement sur une vm préemptible (spot). cela me donne un contrôle direct sur l'infrastructure sous-jacente, garantissant que mes charges de travail par lots tolérantes aux pannes bénéficient de ces économies significatives sur les instances spot.

sortie attendue :

custom batch prediction job submitted: projects/your-gcp-project-id/locations/europe-west4/customjobs/your-job-id
job state: job_state_pending

dépannage que j'ai rencontré :

• permission_denied : vérifiez toujours que le compte de service vertex ai (service-${project_number}@gcp-sa-aiplatform.iam.gserviceaccount.com) dispose des autorisations storage object admin sur vos buckets gcs et artifact registry reader sur votre image de conteneur. c'est une erreur de configuration courante.
• resourceexhausted : si vous demandez des types de machines ou des gpu très spécifiques, vous pourriez atteindre des limites de quota. pour les instances spot, cela pourrait également signifier une indisponibilité temporaire dans la région ; le travail attendra et réessayera généralement, mais c'est quelque chose à surveiller.

cloud run est fantastique pour la scalabilité serverless, mais pour l'inférence ia, la gestion des démarrages à froid est un équilibre constant. la définition de min-instances à une valeur non nulle élimine les démarrages à froid, ce qui est excellent pour l'expérience utilisateur, mais cela entraîne également des coûts continus. mon approche est de toujours peser les exigences de latence par rapport aux dépenses horaires.

pour une instance cloud run configurée avec 2 vcpu et 8 gio de mémoire, fonctionnant 24h/24 et 7j/7 dans europe-west4 avec min-instances=1, j'ai calculé que le coût s'élevait à environ 84 €/mois (91,30 $/mois) aux tarifs à la demande. si mon service ne connaît un trafic de pointe que quelques heures par jour, définir min-instances=0 pourrait être plus rentable, même avec des démarrages à froid occasionnels. cependant, pour les services nécessitant des temps de réponse inférieurs à la seconde, un réglage min-instances de 1 ou 2 est presque toujours justifié.

calcul du coût de min-instance

voici comment je décompose le coût d'une instance cloud run typique (2 vcpu, 8 gio de mémoire) dans europe-west4 : * vcpu : 0,038 €/heure (0,041 $/heure) * mémoire : 0,0049 €/go-heure (0,0053 $/go-heure)

coût horaire pour une instance : (2 vcpu * 0,038 €/vcpu-heure) + (8 go * 0,0049 €/go-heure) = 0,076 € + 0,0392 € = 0,1152 €/heure (0,1252 $/heure)

coût mensuel pour une instance avec min-instances=1 (en supposant 730 heures/mois) : 0,1152 €/heure * 730 heures = ~84,00 €/mois (~91,30 $/mois)

je présente toujours ce coût continu aux parties prenantes pour les aider à comprendre le compromis avec l'expérience utilisateur et la latence perçue.

déploiement de cloud run avec min-instances

j'utilise la commande gcloud run deploy pour définir min-instances et max-instances. surtout, je spécifie toujours une région européenne pour maintenir notre infrastructure alignée sur nos exigences géographiques.

gcloud run deploy my-ai-inference-service \
  --image gcr.io/your-gcp-project-id/my-inference-image:latest \
  --region europe-west4 \
  --platform managed \
  --cpu 2 \
  --memory 8gi \
  --min-instances 1 \
  --max-instances 5 \
  --no-allow-unauthenticated \
  --concurrency 80 \
  --timeout 300s

cette commande déploie my-ai-inference-service avec un minimum de 1 instance toujours en cours d'exécution, éliminant les démarrages à froid. elle s'adapte jusqu'à 5 instances en fonction du trafic et alloue 2 vcpu et 8 gio de mémoire par instance, ce que j'ai trouvé adapté à de nombreux modèles basés sur des transformeurs.

sortie attendue :

service [my-ai-inference-service] deployed.
service url: https://my-ai-inference-service-xxxxxx-ew.a.run.app

problèmes que je rencontre souvent :

• permission denied on image : vérifiez que le compte de service cloud run dispose des autorisations artifact registry reader ou storage object viewer sur le référentiel d'images. c'est un problème d'autorisation classique.
• quota exceeded : si vous déployez de nombreux services ou des instances particulièrement grandes, vous pourriez atteindre les quotas régionaux de cpu/mémoire. je demande généralement des augmentations de manière proactive via la console gcp.

alloydb, la base de données compatible postgresql entièrement gérée de gcp, offre d'excellentes performances, ce qui est essentiel pour les charges de travail exigeantes comme le stockage vectoriel dans mes pipelines rag. en ce qui concerne les coûts, je me concentre sur le dimensionnement approprié des instances et la gestion intelligente du stockage. comme cloud sql, alloydb bénéficie également de cud sur ses vcpu et sa mémoire. par exemple, les cud de cloud sql peuvent offrir une remise de 25 % pour un engagement d'un an, je recherche donc des options similaires avec alloydb le cas échéant.

dimensionnement des instances alloydb

j'ai appris à éviter le sur-approvisionnement dès le départ. je commence toujours par des types d'instances plus petits et n'augmente la taille que lorsque les besoins réels l'exigent. l'architecture découplée de calcul et de stockage d'alloydb est un énorme avantage ici, permettant une mise à l'échelle indépendante. je surveille de près l'utilisation des ressources (cpu, mémoire, iops de stockage) et ajuste mes types d'instances primaires et répliques en conséquence. pour l'efficacité des coûts, je choisis souvent europe-west1 pour ces bases de données.

# main.tf for alloydb cluster

resource "google_alloydb_cluster" "default" {
  project     = "your-gcp-project-id" # replace with your actual gcp project id
  location    = "europe-west1"
  cluster_id  = "rag-vector-db-cluster"
  network     = "projects/your-gcp-project-id/global/networks/default" # replace with your actual gcp project id

  display_name = "rag vector database cluster"

  initial_user {
    user     = "postgres"
    password = "your-strong-password" # replace with a strong, secure password
  }
}

resource "google_alloydb_instance" "primary" {
  project       = "your-gcp-project-id" # replace with your actual gcp project id
  location      = "europe-west1"
  cluster       = google_alloydb_cluster.default.cluster_id
  instance_id   = "rag-vector-db-primary"
  instance_type = "primary"

  machine_config {
    cpu_count = 4 # i start with a moderate cpu count and scale as needed
  }

  # adjust disk size and type based on your vector storage needs.
  # alloydb storage scales automatically, but instance type influences iops.
  # there's no explicit disk_size_gb for alloydb instances; it's usage-based.

  display_name = "primary instance for rag vectors"
}

cette configuration terraform met en place un cluster alloydb et une instance primaire avec 4 cœurs de cpu dans europe-west1. je prends l'habitude de réviser régulièrement mes métriques alloydb pour trouver des opportunités de réduire le calcul ou d'optimiser mes requêtes.

optimisation du stockage d'artifact registry

artifact registry est l'endroit où je stocke mes images de conteneurs, mes artefacts de modèles linguistiques et d'autres binaires. ce que j'ai appris, c'est que les coûts de stockage peuvent augmenter rapidement si vous ne faites pas attention. la mise en œuvre de politiques de cycle de vie pour supprimer automatiquement les artefacts anciens ou inutilisés est indispensable pour réduire les coûts de stockage. par défaut, le coût de stockage d'artifact registry est d'environ 0,09 €/go (0,098 $/go) par mois dans les régions européennes, donc chaque go compte.

bien qu'artifact registry n'ait pas de politiques de cycle de vie d'objets granulaires comme gcs directement, je gère cela via mes pipelines ci/cd et des examens manuels réguliers.

# example: to list repositories i often use:
gcloud artifacts repositories list --location=europe-west4

# for deleting old versions, i usually integrate this into ci/cd scripts.
# this is a conceptual snippet; direct lifecycle policy for artifact registry is not as granular as gcs.
# you'd typically integrate this into your ci/cd pipelines to manage image versions.

# example: listing old tags for a repository 'my-model-repo' and deleting them
# gcloud artifacts docker tags list europe-west4/my-model-repo --limit=all --format='json' |
# jq -r '.[] | select(.create_time | .[:-1] | fromdate < (now - (30 * 24 * 60 * 60))) | .tag_names[]' |
# xargs -i {} gcloud artifacts docker tags delete europe-west4/my-model-repo/{} --quiet

pour une gestion pratique des coûts de stockage dans artifact registry, j'intègre toujours le nettoyage des artefacts dans mes pipelines ci/cd. cela garantit que je révise régulièrement les référentiels pour les artefacts obsolètes et que j'applique des politiques qui ne conservent que les versions nécessaires. si les artefacts historiques sont rarement consultés, j'envisage de les déplacer vers des options de stockage moins chères (comme gcs coldline), bien qu'artifact registry lui-même n'expose pas de classes de stockage par artefact.

sortie attendue : sortie d'application terraform pour les ressources alloydb, ou messages de succès pour les commandes gcloud.

dépannage : * alloydb initial user password policy not met : assurez-vous toujours que votre mot de passe respecte les exigences de complexité. cela me surprend parfois. * artifact registry artifact not found : vérifiez le nom du référentiel et l'étiquette. la suppression nécessite le rôle artifact registry writer.

pour un pipeline rag complet utilisant alloydb, j'ai trouvé pipeline rag de production : gcp cloud run, vertex ai, alloydb très utile.

l'optimisation de l'utilisation de l'api gemini est absolument critique pour la réduction des coûts, car les frais sont basés directement sur les jetons d'entrée et de sortie (voir tarification de l'ia générative de vertex ai). d'après ce que j'ai vu, le prix de l'api gemini est d'environ 0,00018 € (0,0002 $) pour 1000 jetons d'entrée et 0,00055 € (0,0006 $) pour 1000 jetons de sortie pour gemini-2.5-flash dans europe-west4. la mise en cache des invites et une gestion efficace de la fenêtre de contexte peuvent réduire considérablement ces coûts.

stratégie de mise en cache des invites

j'implémente toujours une stratégie de mise en cache pour les invites fréquemment utilisées ou les paires question-réponse courantes afin d'éviter les appels d'api redondants. par exemple, si mon application d'analyse financière interroge fréquemment le sentiment du marché pour une action spécifique, je mettrai en cache cette invite et sa réponse. cela évite de solliciter l'api inutilement pour des requêtes identiques.

import hashlib
import json
import time
from datetime import datetime, timedelta
from typing import dict, any, optional
from google.cloud import aiplatform

# initialize vertex ai client
aiplatform.init(project="your-gcp-project-id", location="europe-west4") # replace with your actual gcp project id

# in a real application, i'd use a persistent store (e.g., redis, cloud memorystore)
_prompt_cache: dict[str, dict[str, any]] = {}
cache_ttl_seconds = 3600 # cache entries expire after 1 hour

def generate_cache_key(prompt_text: str, model_config: dict[str, any]) -> str:
    # i create a unique key based on the prompt text and relevant model configuration.
    # this ensures different prompts or model parameters don't clash in the cache.
    hasher = hashlib.sha256()
    hasher.update(prompt_text.encode('utf-8'))
    hasher.update(json.dumps(model_config, sort_keys=true).encode('utf-8'))
    return hasher.hexdigest()

def _call_gemini_api(prompt_text: str, model_config: dict[str, any]) -> str:
    # this function would contain the actual gemini api call logic.
    # for demonstration, i'm simulating an api response.
    print("calling gemini api...")
    # in a real scenario, you'd use:
    # model = aiplatform.generativemodel("gemini-2.5-flash") # corrected from from_pretrained
    # response = model.generate_content(prompt_text, **model_config) # corrected from predict
    # return response.text
    time.sleep(1) # simulate api latency
    return f"simulated gemini response for: {prompt_text}"

def get_gemini_response_cached(prompt_text: str, model_config: optional[dict[str, any]] = none) -> str:
    if model_config is none:
        model_config = {}

    cache_key = generate_cache_key(prompt_text, model_config)
    cached_entry = _prompt_cache.get(cache_key)

    if cached_entry:
        expiration_time = cached_entry['timestamp'] + cache_ttl_seconds
        if datetime.now().timestamp() < expiration_time:
            print("returning cached response.")
            return cached_entry['response']
        else:
            print("cache expired, fetching new response.")

    # if no cache hit or cache expired, call the actual api
    response = _call_gemini_api(prompt_text, model_config)
    _prompt_cache[cache_key] = {
        'response': response,
        'timestamp': datetime.now().timestamp()
    }
    return response

# example usage:
# print(get_gemini_response_cached("what is the capital of france?"))
# print(get_gemini_response_cached("what is the capital of france?")) # this should be cached
# print(get_gemini_response_cached("how does photosynthesis work?"))

ce fragment de code python complété démontre un mécanisme de mise en cache d'invites basique. j'utilise hashlib pour créer une clé unique pour chaque invite et sa configuration, puis je stocke les réponses avec une durée de vie (ttl). dans un environnement de production, je remplacerais le _prompt_cache en mémoire par un stockage persistant et performant comme redis ou cloud memorystore. cela réduit considérablement les appels d'api redondants et, par conséquent, les coûts basés sur les jetons.

pour illustrer l'impact de ces optimisations, j'ai élaboré une analyse comparative des coûts conceptuelle pour un pipeline rag de référence. cela suppose une charge de travail modérée (par exemple, 100 000 requêtes/jour, 500 000 appels d'embedding/jour, 100 go de stockage vectoriel) sur un mois dans europe-west4, en tirant parti des stratégies discutées.

note : ce sont des chiffres illustratifs pour un pipeline rag hypothétique basé sur mon expérience et les structures de prix actuelles, démontrant le potentiel d'économies significatives. les économies cumulées de ces stratégies combinées sont substantielles.