ik begin altijd met ervoor te zorgen dat mijn lokale omgeving up-to-date is. dit omvat het bijwerken van de gcloud cli en het installeren van de benodigde python-bibliotheken:

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

daarna configureer ik mijn standaardproject en een geschikte europese regio. voor mijn werk kies ik vaak voor europe-west4 (groningen, nederland) vanwege de balans tussen kosten en beschikbaarheid:

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

vertex ai is vaak een belangrijke post op mijn rekening. ik heb gemerkt dat een van de meest effectieve manieren om deze kosten te verlagen, is door strategisch gebruik te maken van compute engine committed use discounts (cud's) voor voorspelbare, stabiele workloads, en spot vm's voor elke batch-inferentie die onderbrekingen kan verdragen.

vertex ai maakt onder de motorkap gebruik van compute engine-bronnen. dit betekent dat we compute engine cud's kunnen toepassen op de onderliggende compute. een 3-jarige verbintenis kan kortingen tot 50% opleveren. voor flexibeler, onvoorspelbaar batchwerk, dring ik altijd aan op spot vm's, die een enorme korting van 60-91% bieden op on-demand prijzen. deze strategie vereist architectonische veerkracht, maar de besparingen zijn het waard.

aanschaf van compute engine cud's

ik koop meestal cud's op cloud billing-accountniveau. dit biedt maximale flexibiliteit, waardoor de korting van toepassing is op elk project dat aan dat billing-account is gekoppeld. een 1-jarige verbintenis levert meestal een korting van 24-30% op, terwijl een 3-jarige verbintenis 42-50% kan bereiken voor compute engine-bronnen. als ik bijvoorbeeld 100 €/uur (108,70 $/uur) aan flexibele compute engine-uitgaven vastleg, kan dit tot 185,19 €/uur (201,29 $/uur) aan on-demand gebruik dekken na een korting van 46%, volgens de gcp's flexibele cud-documentatie. dit is een no-brainer voor voorspelbare basisbelastingen.

voor meer gedetailleerde informatie verwijs ik altijd naar het officiële compute engine committed use discounts overzicht.

batch-inferentie implementeren met spot vm's

wanneer ik batchvoorspellingstaken uitvoer, vooral die asynchroon zijn of opnieuw kunnen worden gestart, configureer ik ze om expliciet vooraf te kunnen worden afgesloten (spot) vm's aan te vragen (zie vertex ai custom jobs). dit is perfect voor workloads waarbij een occasionele onderbreking geen dealbreaker is. de meest robuuste manier die ik hiervoor heb gevonden, is door een customjob in vertex ai te definiëren, waarbij worker_pool_specs wordt gespecificeerd om vooraf af te sluiten replica's te gebruiken.

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

dit python-fragment demonstreert hoe ik een customjob indien om expliciet op een vooraf af te sluiten (spot) vm te draaien. dit geeft me directe controle over de onderliggende infrastructuur, wat garandeert dat mijn fouttolerante batch-workloads profiteren van die aanzienlijke kostenbesparingen van spot-instanties.

verwachte uitvoer:

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

problemen die ik ben tegengekomen:

• permission_denied: controleer altijd of het vertex ai-serviceaccount (service-${project_number}@gcp-sa-aiplatform.iam.gserviceaccount.com) storage object admin-machtigingen heeft op uw gcs-buckets en artifact registry reader-machtigingen op uw containerimage. dit is een veelvoorkomende configuratiefout.
• resourceexhausted: als u zeer specifieke machinetypes of gpu's aanvraagt, kunt u quotumlimieten bereiken. voor spot-instanties kan dit ook tijdelijke onbeschikbaarheid in de regio betekenen; de taak wacht en probeert het meestal opnieuw, maar dit is iets om in de gaten te houden.

cloud run is fantastisch voor serverless schaalbaarheid, maar voor ai-inferentie is het beheer van koude starts een constante evenwichtsoefening. het instellen van min-instances op een niet-nulwaarde elimineert koude starts, wat geweldig is voor de gebruikerservaring, maar het brengt ook continue kosten met zich mee. mijn aanpak is om de latency-eisen altijd af te wegen tegen de uurlijkse uitgaven.

voor een cloud run-instantie die is geconfigureerd met 2 vcpu en 8 gib geheugen, die 24/7 draait in europe-west4 met min-instances=1, heb ik berekend dat de kosten ongeveer 84 €/maand (91,30 $/maand) bedragen tegen on-demand tarieven. als mijn service slechts een paar uur per dag piekverkeer ziet, kan het instellen van min-instances=0 kosteneffectiever zijn, zelfs met de af en toe optredende koude start. voor services die echter reactietijden van minder dan een seconde vereisen, is een min-instances-instelling van 1 of 2 bijna altijd gerechtvaardigd.

berekening van de min-instance kosten

hier is hoe ik de kosten voor een typische cloud run-instantie (2 vcpu, 8 gib geheugen) in europe-west4 uitsplits: * vcpu: 0,038 €/uur (0,041 $/uur) * geheugen: 0,0049 €/gb-uur (0,0053 $/gb-uur)

uurkosten voor één instantie: (2 vcpu * 0,038 €/vcpu-uur) + (8 gb * 0,0049 €/gb-uur) = 0,076 € + 0,0392 € = 0,1152 €/uur (0,1252 $/uur)

maandelijkse kosten voor één instantie met min-instances=1 (uitgaande van 730 uur/maand): 0,1152 €/uur * 730 uur = ~84,00 €/maand (~91,30 $/maand)

ik presenteer deze continue kosten altijd aan belanghebbenden om hen te helpen de afweging met gebruikerservaring en waargenomen latency te begrijpen.

cloud run implementeren met min-instances

ik gebruik de opdracht gcloud run deploy om min-instances en max-instances in te stellen. cruciaal is dat ik altijd een europese regio specificeer om onze infrastructuur af te stemmen op onze geografische vereisten.

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

deze opdracht implementeert my-ai-inference-service met een minimum van 1 altijd draaiende instantie, waardoor koude starts worden geëlimineerd. het schaalt op tot 5 instanties op basis van verkeer en wijst 2 vcpu's en 8 gib geheugen toe per instantie, wat ik geschikt heb bevonden voor veel transformer-gebaseerde modellen.

verwachte uitvoer:

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

problemen die ik vaak tegenkom:

• permission denied on image: controleer of het cloud run-serviceaccount artifact registry reader- of storage object viewer-machtigingen heeft op de image-repository. dit is een klassiek autorisatieprobleem.
• quota exceeded: als u veel services of bijzonder grote instanties implementeert, kunt u regionale cpu/geheugenquota bereiken. ik vraag meestal proactief om verhogingen via de gcp-console.

alloydb, gcp's volledig beheerde postgresql-compatibele database, levert uitstekende prestaties, wat cruciaal is voor veeleisende workloads zoals vectoropslag in mijn rag-pipelines. wat kosten betreft, focus ik op de juiste instantiegrootte en intelligent opslagbeheer. net als cloud sql profiteert alloydb ook van cud's op zijn vcpu's en geheugen. cloud sql cud's kunnen bijvoorbeeld 25% korting bieden voor een 1-jarige verbintenis, dus ik zoek naar vergelijkbare opties met alloydb waar van toepassing.

alloydb instantie sizing

ik heb geleerd om overprovisioning vanaf het begin te vermijden. ik begin altijd met kleinere instantietypes en schaal alleen op wanneer de werkelijke behoeften dit dicteren. de ontkoppelde compute- en opslagarchitectuur van alloydb is hier een enorm voordeel, waardoor onafhankelijke schaalvergroting mogelijk is. ik monitor de resourcegebruik (cpu, geheugen, opslag iops) nauwlettend en pas mijn primaire en replica-instantietypes dienovereenkomstig aan. voor kostenefficiëntie kies ik vaak europe-west1 voor deze databases.

# 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"
}

deze terraform-configuratie zet een alloydb-cluster en een primaire instantie op met 4 cpu-kernen in europe-west1. ik maak er een gewoonte van om mijn alloydb-metrics regelmatig te controleren om mogelijkheden te vinden om de rekenkracht te verminderen of mijn queries te optimaliseren.

artifact registry opslag optimalisatie

artifact registry is waar ik mijn containerimages, taalmodel-artefacten en andere binaries opsla. wat ik heb geleerd, is dat opslagkosten snel kunnen oplopen als je niet voorzichtig bent. het implementeren van levenscyclusbeleid om oude of ongebruikte artefacten automatisch te verwijderen is een must om opslagkosten te verlagen. standaard kost artifact registry-opslag ongeveer 0,09 €/gb (0,098 $/gb) per maand in europese regio's, dus elke gb telt.

hoewel artifact registry geen gcs-achtige, granulaire objectlevenscyclusbeleidsregels direct heeft, beheer ik dit via mijn ci/cd-pipelines en regelmatige handmatige controles.

# 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

voor praktisch opslagkostenbeheer in artifact registry, integreer ik altijd het opschonen van artefacten in mijn ci/cd-pipelines. dit zorgt ervoor dat ik repositories regelmatig controleer op verouderde artefacten en beleid afdwing dat alleen noodzakelijke versies behoudt. als historische artefacten zelden worden benaderd, overweeg ik ze te verplaatsen naar goedkopere opslagopties (zoals coldline gcs), hoewel artifact registry zelf geen opslagklassen per artefact blootstelt.

verwachte uitvoer: terraform apply-uitvoer voor alloydb-bronnen, of succesberichten voor gcloud-opdrachten.

probleemoplossing: * alloydb initial user password policy not met: zorg er altijd voor dat uw wachtwoord voldoet aan de complexiteitsvereisten. dit overkomt me soms. * artifact registry artifact not found: controleer de repositorynaam en tag nogmaals. voor verwijdering is de rol artifact registry writer vereist.

voor een complete rag-pipeline met alloydb vond ik productie rag-pipeline: gcp cloud run, vertex ai, alloydb een zeer nuttige referentie.

het optimaliseren van het gemini api-gebruik is absoluut cruciaal voor kostenreductie, aangezien de kosten direct gebaseerd zijn op invoer- en uitvoertokens (zie vertex ai generatieve ai-prijzen). uit wat ik heb gezien, is de gemini api-prijs ongeveer 0,00018 € (0,0002 $) per 1000 invoertokens en 0,00055 € (0,0006 $) per 1000 uitvoertokens voor gemini-2.5-flash in europe-west4. prompt-caching en efficiënt beheer van het contextvenster kunnen deze kosten drastisch verlagen.

prompt caching strategie

ik implementeer altijd een cachingstrategie voor veelgebruikte prompts of veelvoorkomende vraag-antwoord-paren om redundante api-aanroepen te voorkomen. als mijn financiële analyseapplicatie bijvoorbeeld vaak de marktsentimenten voor een specifiek aandeel opvraagt, cache ik die prompt en het antwoord. dit voorkomt dat de api onnodig wordt aangeroepen voor identieke verzoeken.

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?"))

dit voltooide python-fragment demonstreert een basismechanisme voor prompt-caching. ik gebruik hashlib om een unieke sleutel te creëren voor elke prompt en zijn configuratie, en sla vervolgens antwoorden op met een time-to-live (ttl). in een productieomgeving zou ik de in-memory _prompt_cache vervangen door een persistente, high-performance opslag zoals redis of cloud memorystore. dit vermindert aanzienlijk redundante api-aanroepen en, bijgevolg, token-gebaseerde kosten.

om de impact van deze optimalisaties te illustreren, heb ik een conceptuele kostenbenchmark samengesteld voor een referentie rag-pipeline. dit gaat uit van een matige workload (bijv. 100k verzoeken/dag, 500k embedding-aanroepen/dag, 100gb vectoropslag) gedurende een maand in europe-west4, waarbij gebruik wordt gemaakt van de besproken strategieën.

opmerking: dit zijn illustratieve cijfers voor een hypothetische rag-pipeline op basis van mijn ervaring en huidige prijsstructuren, die het potentieel voor aanzienlijke besparingen aantonen. de cumulatieve besparingen van deze gecombineerde strategieën zijn aanzienlijk.