Model Evaluation Service  ·  View 07 of 21  ·  Structure

Container View

The deployable units, the two planes they split across, and what sits outside the boundary.

Editable source SVG draw.io All views
Model Evaluation Service · Google Cloud europe-west4 Control plane · GKE Autopilot Candidate Register Go · 3 pods Frame Resolver Go · 3 pods Run Planner Go · 3 pods Gate Engine Python · 4 pods Execution plane · GKE node pools Harness Workers 0-600 pods Tool Sandbox gVisor · no egress Scoring Workers 0-200 pods State Run State Cloud SQL · HA Score Store BigQuery Artefacts Cloud Storage Label Store Cloud SQL Spine Work + Events Pub/Sub Score Cache Memorystore Outside the boundary Inference Vertex AI candidates Provider APIs judges Governance Policy Repository suites · gates Rater Console vendor SaaS Model Evaluation Service — Container View Application we own Decision point Security / platform Data store Queue / topic External / third party Edges are omitted deliberately: the control plane writes work to Pub/Sub and reads scores from BigQuery, and every execution-plane call to an inference surface leaves through the egress proxy shown in the trust-zone view. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • Control plane and execution plane scale independently: 3-4 pods against 0-600, on different node pools with different failure tolerance.
  • The tool sandbox is its own component, not a library in the harness, because it executes model-generated calls.

Assumptions

  • Peak 1,200 candidate generations per minute with a 4× burst for 30 minutes on release days (stated assumption).
  • BigQuery as the score store because the dominant query is a per-slice comparison over tens of millions of rows.

Deliberate omission

  • Edges are not drawn. Work flows through Pub/Sub and scores are read from BigQuery; the inference path is shown in the trust-zone view.