GCP News - 2026-10-20

Imagining traditional gearheads getting their hands on software-defined vehicles is an amusing thought experiment. With their socket wrenches and air compressors at the ready, they might be confused to encounter core functions more likely to run on 1s and 0s than oil and belts. But across the auto industry these days, more and more vehicles feature prominent systems built using cloud-native development, continuous integration/continuous delivery, fast digital iteration, and plenty of AI.

But there’s still a big gap to be found in many automakers’ and Tier 1 suppliers’ cloud-based development processes. On the one hand, these companies are commonly using software to develop vehicles’ digital entertainment and information screens, or other onboard high-performance computers. 

On the other, the dozens of microchips and control modules that make a car a car these days — such as gateways, body controllers, zone control units, sensor and actuator nodes — are still frequently hardwired to physical chips when they’re constructed, making them very difficult to update, reprogram, or expand after the vehicle drives off the factory floor. Teams have to wait for benches, samples, and rigs, and integration can easily slip to the end of the development process, where defects are most expensive to fix.

This inherent inefficiency has become a leading bottleneck. After all, manufacturers can’t really claim vehicles are software-defined if most of their electronics only function when connected to physical hardware and if developers are leaning heavily on actual hardware.

With Horizon, our agentic innovation platform for developing software-defined vehicles, our vision is to help manufacturers avoid these inefficiencies by working with partners like RemotiveLabs.

The cockpit already runs in the cloud

The Android team has invested a significant amount of time and effort over the last few years on enabling seamless development of the many digital systems in vehicles’ cockpits. Android Automotive OS (AAOS) runs inside Google’s official virtual testing environment for Android, Cuttlefish, which itself runs comfortably on Arm-based Google Cloud instances. With this approach, developers can build, boot, and test virtual versions of their infotainment stacks on the same Arm architecture that ships in vehicles.

And with the recent launch of Android 17 and AAOS SDV, this capability is also extended to further domains, whenever AAOS SDV is used. Deploying it with Cuttlefish, for example, proves the model: representative software, on representative architecture, in the cloud, on demand. The question that still needs to be answered is how to extend that model to the rest of the vehicle, especially when other operating systems are involved.

The harness around the virtual vehicle

That’s where RemotiveTopology comes into play. As the harness around the virtual vehicle, it’s the layer that connects AAOS in Cuttlefish to a full, simulated electrical and electronic (E/E) architecture: the rest of the vehicle’s onboard computers, its data networks, and the live signals that make the system function like a real vehicle rather than a collection of standalone apps.

RemotiveTopology automatically utilizes manufacturers’ existing network design files to build a working, virtual version of their cars’ networks. This is vehicle-as-code: the E/E architecture expressed as an executable specification, versioned and provisioned like infrastructure-as-code. In this way, an entire vehicle can be spun up on demand. Cockpit software talks to the rest of the vehicle exactly as it would in a real vehicle. As a result, developers get full and continuous signal and cross-domain visibility, so they can see real-time system status. And because it is built on standard Linux tooling, the same topology runs on a laptop and in a contiguous integration pipeline on Google Cloud.

Integrate across domains early, not late

The payoff for using this approach is that all onboard systems can be developed and integrated with software before any of them are connected to a vehicle’s hardware. That’s beneficial because the most difficult (and latest) integration in a vehicle’s development is bringing all its systems together. For example, advanced driver assistance systems (ADAS) produce object lists, trajectories, and mode requests that the cockpit has to render and react to, while the infotainment system and information cluster have to reflect driving state while body and chassis nodes sit in the loop.

With the full topology live on Google Cloud, the infotainment system and ADAS can operate simultaneously within a virtual vehicle, exchanging real signals over the simulated network. This means it’s possible to exercise handoffs like an ADAS event surfacing in the cluster or a driver-mode change rippling across domains from day one in continuous integration long before the benches and samples line up. In this way, developers can be confident they’ll discover multi-domain integration long before the end of the process so that they can test continuously from the start.

The full vehicle frontier

At the heart of this work is a shared desire to bring scalable software development to even the smallest and most common nodes in a vehicle, its microchips and control modules. That’s because these are the parts that have traditionally been wired to hardware, and as a result are the biggest blocker to fully software-defined vehicles.

The ultimate goal is that the same software that runs in the cloud can run on vehicles’ actual control modules with no re-tooling or re-validation needed to move between them. That parity is natural with Arm-based Google Cloud infrastructure because the cloud and the car share an instruction set. Google's Axion makes it straightforward: C4A metal, a bare-metal Arm instance, is provided explicitly for automotive systems development and Android software development, giving direct hardware access without unnecessary software layers and delivering the consistent performance that vehicle systems require.

Taken together, this holistic system allows teams, for the first time, to develop and integration-test an entire vehicle’s systems in the cloud and then apply it to the actual vehicle without having to rewrite it.

Why now, and where to start

The payoff is not abstract. Treating the vehicle as code and moving integration into the cloud compresses the slowest, most expensive phase of a program. Early customer engagements with RemotiveLabs have measured more than 10x faster integration cycles. And the development loop is now changing faster than the hardware loop: AI-assisted and agentic workflows can rapidly generate, test, and refine vehicle software, but only virtual systems provide the required scale. Every element that can’t be virtualized can slow the entire development process down.

RemotiveTopology provides this architecture as vehicle-as-code and makes it accessible for developers, testers, and autonomous AI agents alike. Best of all, there is no new third-party tooling to adopt just to get started. Instead, RemotiveLabs publishes an open-source simplified vehicle on GitHub that anyone can run in minutes on standard Linux tooling and platform definitions already in place. Full existing toolchains plug in as a manufacturer or Tier1 supplier scales, and RemotiveTopology can be easily dropped into an Arm-based Google Cloud environment.

For those building software-defined vehicles whose virtual development stops at the cockpit, it’s time to start with an open-source example, bring unique platform definitions, and run an entire vehicle in the cloud. RemotiveTopology is available in Horizon for easy usage in combination with other Horizon modules.

We are announcing  a new logging feature that  is now available in Python User-Defined Function (UDF) in BigQuery. Developers can now use Python’s standard logging library directly inside BigQuery UDFs to emit structured logs seamlessly into Cloud Logging—with zero external plugins or custom connectors required.

While UDF logging enables a wide range of operational monitoring and debugging workflows, to demonstrate this feature we are showcasing an example for building fault-tolerant, resilient data pipelines. In the example below, we are capturing row-level diagnostic telemetry during query execution, so that teams can easily isolate problematic records, trigger real-time alerts, and triage issues via SQL without halting entire workloads.

In this post, we’ll show you how to get started with Python UDF logging and walk through an e-commerce event ingestion pipeline as a practical, end-to-end example.

Architecture overview

The workflow consists of three stages:

1. Inline validation: The Python UDF parses incoming JSON payloads. Valid records pass to the destination table; corrupted or non-compliant rows trigger logging.error() and return NULL to prevent query failure.

2. Real-time alerting: A Cloud Monitoring log-based metric notifies your team when error rates breach SLA thresholds.

3. SQL triage & replay: Data engineers query the quarantined payloads in BigQuery using standard SQL over the linked _AllLogs view, diagnose the root cause, and re-ingest recovered data.

Although this specific demonstration relies on Python for data validation and transformation, you can seamlessly integrate Python-driven logging and validation into pipelines that perform SQL-based transformations.

Quickstart walkthrough: Step-by-step

Step 1: Create the generic Python UDF

This UDF parses JSON and checks for a required field. If parsing fails or the required key is missing, it logs structured diagnostic JSON and returns NULL.

Step 2: Run ingestion with logging enabled

In this example, we simulate an e-commerce event ingestion pipeline processing incoming user actions (click, view, checkout). Our goal is to extract valid events into our clean analytics table while gracefully quarantining broken or missing-schema payloads.

Enable logging in your session with SET @@udf.properties:

Ingestion Results

The query succeeds without interruption while bad rows (2 and 3) are routed to Cloud Logging.

Step 3: Set up real-time alerts on Cloud Logging

You can configure alerts to notify your on-call team as soon as malformed payloads exceed acceptable thresholds.

In the Google Cloud Console (1-Click)

1. In the Google Cloud Console, open Logs Explorer.

2. Paste the log filter for your UDF routine:

3. Click Create alert in the top action bar.

4. Set your notification channels (e.g., Slack, PagerDuty, or Email) and save the policy.

Step 4: Triage bad rows with BigQuery Log Analytics

"Note: To query your logs via BigQuery SQL, ensure you have enabled BigQuery Log Analytics on your Cloud Logging bucket and created a linked dataset."

Query the quarantined payloads using BigQuery SQL via the linked _AllLogs view:

Log Analytics output

Recovering data

Because full raw payloads are preserved in Cloud Logging, you can recover quarantined records directly with SQL once upstream data is fixed:

Final clean_events Table Result:

All valid and recovered data is now unified in the production table without any data loss.

Other use cases

• Shadow execution & safe migrations: Run legacy and new business logic side-by-side in a UDF. Return the legacy result to production while logging calculation differences to Cloud Logging.

• PII redaction auditing: Mask sensitive tokens (such as SSNs or account numbers) before writing to BigQuery, while emitting anonymized audit events to Cloud Logging.

• ML inference drift: Log warnings when embedded scoring logic encounters out-of-vocabulary inputs or low model confidence.

Best practices

• Enable debug output: Include SET @@udf.properties = JSON '{"enableDebugOutput": true}'; in the session where you want logs captured.

• Avoid sensitive data in logs: Cloud Logging is visible to users with Logging Viewer permissions. Do not log credentials or secrets.

• Cost management: On high-throughput pipelines, log selectively (e.g., only on errors or via sampling) to manage logging ingestion volume.

Getting started

• BigQuery Python UDF Documentation

• BigQuery Log Analytics Overview

Enterprise assistants still respond mostly in text. However, that can break down for visual, multi-step work, where every adjustment costs another slow chat turn.

MCP Apps (SEP-1865) solves this. This open Model Context Protocol (MCP) extension pairs a tool with a live UI. In Gemini Enterprise, that UI renders directly in the chat flow inside a sandboxed iframe, and can expand to fullscreen or a side panel. Edits run locally while the workspace and assistant stay synchronized.

You also avoid rebuilding core foundations: Gemini provides workforce sign-in, governed data access, and the Default Assistant, while you host your MCP server on a private Cloud Run service.

Why we need MCP Apps

Enterprise assistants have evolved through three generations:

• Generation 1 (Text chatbots): Returns static markdown with no interactive controls.

• Generation 2 (Standard MCP tools): Invokes live APIs, but outputs static text. Every change requires another model turn.

• Generation 3 (Interactive MCP Apps): Pairs each tool with a live workspace. Adjustments happen in the widget without a model turn, while the assistant stays in sync.

Building MCP Apps in Gemini delivers six benefits:

1. Responsive user experience: Single-click actions execute directly in the panel without round-tripping through the chat.

2. Purpose-built workflows: Deliver visual redaction views for legal review, 3D viewers for CAD, or sensitivity models for finance.

3. Enterprise security: Workforce OAuth sign-in, private Cloud Run ingress, and a sandboxed iframe protect every layer.

4. Human-in-the-loop governance: Experts inspect and approve high-stakes actions before execution.

5. Open standard: Portable across compatible hosts, with automatic text fallback.

6. Broad connectivity: Connect to BigQuery, Agent Platform, Cloud Storage, or internal ERP and CRM systems.

High-level architecture

Three decoupled tiers work together:

• Client browser: Shows the chat alongside the MCP App widget in the side panel.

• Gemini Enterprise: The default assistant calls tools, the AppBridge proxy relays widget messages, and the connector manages OAuth.

• Google Cloud (your project): You deploy and host the MCP server on Cloud Run, which exposes one JSON-RPC endpoint (/mcp), runs background jobs, and serves the single-file HTML widget.

Each tier talks only to its neighbor, letting Gemini Enterprise enforce security and routing.

Authentication with two independent layers

Each user signs in through OAuth 2.0. On every call, Gemini Enterprise sends its service agent token alongside the user's OAuth token:

• Layer 1 (Cloud Run IAM): Enforced at Google's edge, this answers "which service may call?" Public access is disabled; unauthorized callers receive HTTP 403.

• Layer 2 (In-App OAuth): Enforced inside the application, this answers "which user is calling?" Failed verification returns HTTP 401, prompting the user to sign in again.

Cloud Run IAM cannot distinguish end users, so both layers are required. Outbound calls use a least-privilege service account.

Build, deploy on Google Cloud, and register in Gemini Enterprise

First, build your custom MCP server (exposing POST /mcp and a bundled ui:// HTML widget) using the MCP Apps SDK, or use Google Antigravity  to scaffold and deploy your MCP App with this starter prompt:

• Build an MCP App for Gemini Enterprise using the create-mcp-app skill (https://github.com/modelcontextprotocol/ext-apps/tree/main/plugins/mcp-apps/skills/create-mcp-app).

• Workflow: [describe your input data, side-panel UI controls, and approval or export actions].

• Generate a single-file HTML widget, a Streamable HTTP backend (POST /mcp) with <2s async tool responses and get_app_state polling, and Cloud Run deployment commands (--no-allow-unauthenticated, --no-cpu-throttling, --min-instances=1).

Once your MCP server code is ready, deploy it to Cloud Run and connect it to Gemini Enterprise:

• Step 1: Enable APIs for Cloud Run, Discovery Engine, Agent Platform, and Organization Policy.

• Step 2: Deploy your MCP server container to Cloud Run from source (gcloud run deploy <service> --source .) with --no-allow-unauthenticated, --no-cpu-throttling so background work does not freeze between polls, and --min-instances=1.

• Step 3: Grant the invoker role (roles/run.invoker) to your Discovery Engine service agent (Layer 1).

• Step 4: Create an OAuth 2.0 Web Client with redirect URI https://vertexaisearch.cloud.google.com/oauth-redirect(Layer 2).

• Step 5: Override the discoveryengine.managed.disableCustomMcpServerConnector constraint and complete the Before you begin prerequisites (roles/discoveryengine.editor for the admin, allowedEgressFqdns for your server and OAuth hosts, and custom_mcpin allowedDataSources if enforced). Then, in the Google Cloud Console under Gemini Enterprise > Data stores > Create data store, select Custom MCP Server and register the connector:

• Step 6: Enable actions on your data store. Gemini Enterprise imports your MCP server's tools as actions and disables them by default. In the Cloud Console, open Gemini Enterprise > Data stores > [Your MCP Data Store] > Actions, click Reload custom actions (which calls tools/list on your server), select your model-visible tools, and click Enable actions.

• Step 7: Connect the data store to your app. Open Gemini Enterprise > Apps > [Your App] > Connected data stores > Add existing data stores, and select your MCP data store. Connecting it as a data store gives the built-in Default Assistant access to your MCP tools and UI widget directly in main chat ( do not use "Add Agent,"  which is for external sub-agents rather than MCP data stores).

Build your own

An MCP App pairs backend tools with a live workspace in Gemini Enterprise. You do not build a chat frontend or identity pipeline; you deploy one Cloud Run container and attach it as a Data Store, making Gemini Enterprise where enterprise work gets done.

• Try Gemini here

• Co-build with Google Antigravity here

• Build on Google Cloud: MCP Apps Specification (SEP-1865), Cloud Run, and Google Cloud AI.

Is your LLM-as-a-judge truly objective? 

There’s a common misconception in tech that humans are subjective, so we should rely on AI for objective evaluation. But the reality is that LLMs are also subjective. Just like human reviewers, they can carry biases:

• Verbosity bias: LLM judges usually favor longer, confident-sounding answers, even when the underlying facts are wrong.
• Position bias: Swapping the order of two options can cause an LLM judge to flip its verdict over 75% of the time.
• The halo effect: Because LLMs generate text piece by piece, clean grammar and formatting can trick an AI judge into giving top marks for accuracy while missing errors.
• Agreeableness bias: LLM judges are great at recognizing valid work. But with detecting errors, they may fail to catch incorrect, buggy, or unsafe outputs up to 75% of the time.
• Self-enhancement bias: Also known as egocentric bias, AI evaluators systematically overrate outputs that were generated by themselves or from their own family.

Ultimately, LLM judges are not objective arbiters of truth. They are subjective models with their own distinct biases. Treating them as infallible tools that don't need their quality measured might leave your work compromised. 

In this post, we’ll explore what’s holding enterprises back from strong evals, and share an easy three-pillar method you can use to improve your quality. 

Three helpful ways to audit your LLM judges 

Pillar 1: Measure internal stability

Before you can trust an AI judge’s score, you need to know that it isn't just guessing. Because LLMs are probabilistic, they can be inconsistent, giving different scores to the exact same text.

You can test this internal stability by running multi-pass consistency checks on a single output and calculating the variance. If a judge's scores fluctuate wildly on identical inputs, its rubric is too ambiguous.

Pillar 2: Validate human alignment

When your evaluation datasets are mostly valid responses, a lenient AI judge can look great on paper. It might align closely with human reviewers overall, but miss a majority of invalid or even unsafe outputs.

To prove your LLM judge is catching real errors, you need chance-corrected metrics. These mathematical models filter out agreements driven purely by leniency or random chance, showing how closely your evaluator actually aligns with the informed decisions of human experts.

Pillar 3: Use multi-judge ensembles

To avoid the halo effect mentioned earlier, teams should use decomposed prompting. Instead of asking one LLM judge to score an entire response, assign a specialized judge to evaluate a single criteria, like factual accuracy or tone. This isolates traits and forces independent scoring.

Second, to track performance in real time without human intervention, the established best practice is ensembling. This means running at least two different models under the hood to evaluate the exact same output simultaneously. 

By finding the statistical consensus between these models, you can flag if their evaluations begin to diverge and avoid any scoring quality degradation.

Get started

Partner with Delta to design and implement statistically-audited evaluation pipelines for your enterprise agentic systems.

"Enterprises in highly regulated and air-gapped environments are eager to harness the transformative power of generative AI, but they cannot compromise on data privacy or analytical rigor. By bringing Teradata to Google Distributed Cloud, we are enabling our joint customers to run complex analytical workloads and AI inferencing right where their data resides. Together with Google Cloud, we are breaking down barriers between sovereign cloud infrastructure and enterprise-grade intelligence." - Sumeet Arora, Chief Product Officer, Teradata 

"At Meta, advancing the frontier of AI requires immense compute scale and deep hardware diversity. We cannot be constrained by a single hardware architecture. TorchTPU is a massive step forward — allowing us to co-develop hardware flexibly with the core machine learning systems team while supporting major LLM, Ads, and Recommendation systems workloads on key production use cases. It enables us to deploy our PyTorch workloads to Google TPUs, provide direct feedback to the engineering teams, and build the ecosystem flexibility everyone needs."- Jana van Greunen, Director of PyTorch Engineering, Meta

“Hugging Face is committed to being an open, neutral platform where AI builders can choose the models, frameworks and hardware that work best for them. Hardware diversity is essential to making open-source AI accessible to everyone. Our collaboration with Google to bring native TorchTPU support to our core libraries, including Transformers, puts that commitment into practice. Together, we’re making it easier for the community to run popular models from the Hub efficiently on Google Cloud TPUs using familiar PyTorch workflows. Giving developers more choice in how and where they build helps the entire open-source ecosystem grow.” - Jeff Boudier, VP Product, Hugging Face

"Our mission at Inferact has always been to make high-performance inference accessible, reliable, and cost-effective across the entire AI ecosystem. We are thrilled to partner on the launch of TorchTPU and bring first-class support for vLLM to TPUs. By bridging PyTorch’s optimized TPU capabilities directly into vLLM, developers can immediately run production workloads on TPUs with the high throughput, low latency, and memory efficiency they expect from our stack." - Simon Mo, CEO and co-founder, Inferact

SGLang: Accelerating agentic and structured workloads

Developed in partnership with RadixArk, our native PyTorch backend for SGLang accelerates highly structured and agentic workloads on TPUs. SGLang uses RadixAttention to reuse KV cache across requests, allowing repeated prompt prefixes to skip recomputation entirely. SGLang-TorchTPU preserves upstream worker models, schedulers, and API servers, using a disaggregation transfer backend that also acts as the I/O backend for HiCache to optimize latency and throughput for complex multi-step generation.

"At RadixArk, TorchTPU has supercharged our development velocity as we roll out SGLang support across diverse silicon. It’s given us a painless path to native TPU acceleration, passing massive efficiency gains and flexible compute choices directly down to our customers." - Banghua Zhu, CTO and co-founder, RadixArk

llm-d for distributed LLM inference

To run inference engines across large fleets, we are releasing llm-d 1.0 with Red Hat, IBM, and a community of more than 500 contributors and 25 organizations. As a Cloud Native Computing Foundation (CNCF) Sandbox project, llm-d connects two open-source communities: PyTorch, where vLLM and SGLang serve models, and Kubernetes, where distributed systems run and scale in production. The llm-d router sends each request to the replica that already holds its context, using prefix-cache-aware routing. It also splits compute-heavy prefill from memory-heavy decode. llm-d 1.0 makes that ready for production with multi-tenant flow control, router high availability, stable v1 APIs, and session-aware routing for agents. On Google Kubernetes Engine (GKE), you can have the choice of running on either GPUs or Google TPUs, with a common llm-d endpoint, and choose the hardware that fits each workload.

"At Zenteiq, we use GKE Inference Gateway powered by llm-d to accelerate synthetic data generation for our sovereign Scientific Foundation Models. By leveraging load-aware and prefix-cache-aware routing, we have achieved over 4× higher aggregate inference throughput, increasing daily generated token capacity from 1.47 billion to 5.97 billion tokens per 1,000 TPU v6e accelerators. The open-source foundation of llm-d, integrated with GKE, enables us to efficiently serve multiple model families at scale without developing and maintaining a custom inference scheduler." - Prof. Sashikumaar Ganesan, Founder, Zenteiq.ai

Training at scale

Scaling PyTorch training across thousands of accelerators requires fault-tolerant, compile-aware distributed frameworks. We have integrated TorchTPU into the PyTorch community’s core training, reinforcement learning (RL), and orchestration frameworks.

TorchTitan: Distributed high performance training at scale

TorchTitan is the PyTorch-native reference implementation for scalable distributed training and features a production-grade integration with TorchTPU. By connecting to PyTorch's torch.compile and TorchTitan’s compile friendly SimpleFSDP, specialized Pallas kernels, and graph-level optimizations, developers can build and train models on TPUs with high efficiency at scale.

TorchTitan provides recipes for pre-training large dense models (such as Llama 3 70B/405B, Qwen 3 8B/32B, and MuseGlimmer 30B), Mixture-of-Experts (MoE) such as Qwen 3 235B, and diffusion transformers (such as FLUX.1 12B), and has been validated running with up to 8000 Ironwood TPUs (TPU v7x). Beyond initial pre-training, TorchTitan serves as the scalable trainer inside post-training pipelines like VeRL for Group Relative Policy Optimization (GRPO) and RL alignment.To test large-scale efficiency on demanding open architectures, TorchTPU’s training paths via TorchTitan demonstrated up to 52% Model Flops Utilization (MFU) on Qwen 3 8B, showing near-linear scaling and stability across up to 8,192 Ironwood TPUs.

VeRL: Scalable post-training and reinforcement learning in preview

RL is a foundational technique for frontier labs that are advancing model capabilities, as well as for enterprises customizing models for domain-specific tasks. Yet, orchestrating distributed RL workloads remains one of the most complex challenges in modern AI infrastructure. Bridging that gap, VeRL has quickly become one of the most popular RL frameworks, supporting everything from verifiable math and coding rewards, to multi-turn agentic tool use at massive scale. 

To help expand hardware choice for this thriving community, we upstreamed a TPU backend and an end-to-end reference recipe to VeRL. Built on a disaggregated trainer-sampler architecture designed to maximize training efficiency, our GRPO reference recipe on mathematical reasoning datasets demonstrates how developers can deploy VeRL workloads on TPUs while preserving their existing, hardware-agnostic model and algorithm code. 

Ray: Orchestrating heterogenous compute

We’ve also added native TorchTPU support to Ray, enabling you to orchestrate PyTorch data processing, training, RL, and serving across CPUs, GPUs, and TPUs within a single workflow. With a few lines of resource configuration, you can schedule each stage of a heterogeneous AI pipeline onto the accelerator best suited for the job.

“At Ray Summit we talked about the PARK stack, PyTorch, AI models, Ray, and Kubernetes, because that's what teams are building production AI on today. TorchTPU embeds Google TPUs directly in that industry-standard stack. We've also worked closely with the Google team to support TPUs as a first-class accelerator in Ray. Coupled with native PyTorch support, teams can now seamlessly develop, scale, and monitor their workloads on TPUs." - Edward Oakes, Chief Architect, Anyscale

Deployment flexibility and operational efficiency

True portability requires standardizing deployment tools across different hardware profiles, including edge devices and cloud accelerators.

LiteRT joins the PyTorch Ecosystem

Many PyTorch models need to run on phones, laptops, browsers, and embedded devices. Today, LiteRT (formerly TensorFlow Lite), Google's high-performance on-device AI inference, joins the PyTorch ecosystem. 

With LiteRT-Torch, you convert a PyTorch model with a single litert-torch.convert() call. It builds on torch.export() and Core ATen operators, so your model code stays in PyTorch. For LLMs, LiteRT Torch exports Hugging Face Transformer models to run with LiteRT-LM. The converted models run on Android, iOS, macOS, Windows, Linux, web, and IoT devices, with hardware acceleration across CPUs (via XNNPack), GPUs (via open source ML Drift), and NPUs from major chipsets provided through a single API. 

TPU agent suite in early preview

To expand Pytorch adoption on TPUs, we are announcing that the TPU agent suite is in preview on GitHub. Integrating through plug-ins with several coding harness-model combinations, the TPU agent suite helps automate onboarding, diagnostics, user questions, and inference performance tuning for many PyTorch models. 

“At Snap, we are integrating llm-d into our production AI infrastructure to facilitate high-performance inference at scale. By employing prefix-cache-aware routing, we have achieved prefix cache hit rates ranging up to 75-80%. We appreciate the open-source nature of llm-d, as it enables seamless integration with our Envoy-based Service Mesh." - Vinay Kola, Senior Manager, Software Engineering, Snap Inc.

"At ZenteiQ, we use GKE Inference Gateway powered by llm-d to accelerate synthetic data generation for our sovereign Scientific Foundation Models. By leveraging load-aware and prefix-cache-aware routing, we have achieved over 4× higher aggregate inference throughput, increasing daily generated token capacity from 1.47 billion to 5.97 billion tokens per 1,000 TPU v6e accelerators. The open-source foundation of llm-d, integrated with GKE, enables us to efficiently serve multiple model families at scale without developing and maintaining a custom inference scheduler.” - Prof. Sashikumaar Ganesan, Founder, Zenteiq.ai 

“Serving frontier models across interactive applications and high-volume APIs means handling steep traffic spikes without letting bursty workloads degrade latency for priority customers. With llm-d's prefix-cache-aware routing, flow control and disaggregated serving support we can enforce strict priority bands across our commercial tiers, automatically holding or shedding lower-priority requests when pools saturate so paid traffic meets our latency SLOs. Mistral is a proud supporter of open-source software, and we will continue to contribute back to llm-d and DisaggregatedSet projects.” - Mathis Felardos, Lucas Fernandes-Martins and Nikhil Thomas, Mistral, Inference Engineers and llm-d contributors

※この投稿は米国時間 2026 年 10 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

ここ数十年間で、アイルランドはグローバル テクノロジーの一大拠点へと成長を遂げました。モダナイゼーションが加速するなか、政府機関から大手企業、AI などの分野で成長を続けるスタートアップに至るまで、アイルランドのさまざまな組織が技術基盤を強化しています。現在、国内のリーダーたちは、ビジネスや業務ワークフローのあらゆるレイヤにエージェント型 AI を導入しています。

Gemini Enterprise を活用し、初期のプロトタイプからプロダクション レディなデプロイへと移行する組織が増えています。このような進展が、欧州市場におけるアイルランドの競争力を強固なものにしています。Google の現地での貢献度を試算した Implement Consulting Group の最新レポートによると、官民のリーダーたちは、世界の AI 市場における経済効果を 400 億〜450 億ユーロと推計しています。

こうした強い意欲は、政府が進めるより広範な取り組みとも合致しています。2026 年後半の EU 理事会議長国就任を見据え、アイルランドはより高次元なテクノロジーおよび政策対話を主導してきました。そして、さまざまな分野における生産性とイノベーションの向上を目指し、国家デジタルおよび AI 戦略の枠組みを策定しました。

この戦略を支援するため、Google はこれらの機能をより手軽に利用できるよう注力しています。Google の現地チームは、業界をリードする企業と連携して Gemini Enterprise の導入を進めています。Gemini Enterprise は、会話型 AI エージェントや自然言語によるデータ分析から、エージェント型エコシステムを活用した業務運用の最適化まで、多彩な機能を提供します。

経済的な波及効果は、すでに目に見える形で現れ始めています。2025 年だけでも、AI やクラウド サービスを含む Google の事業活動は、アイルランドの国内総生産に推定 100 億ユーロの付加価値をもたらしました。この勢いはアイルランド全土に広がりを見せており、さまざまな組織が Google Cloud を活用してインフラストラクチャをモダナイズし、AI の本格的な業務活用を進めています。

アイルランドのさまざまな組織が Google Cloud と Gemini Enterprise を活用してモダナイゼーションを実現している事例をご紹介します。

Ryanair: AI を活用したオペレーションで数百万人の乗客をサポート

ヨーロッパ最大の航空会社である Ryanair は、約 35,000 人の従業員に Gemini Enterprise と Google Workspace を導入することで、協調的な業務とインフラストラクチャをモダナイズしています。乗務員、運航計画担当者、本社系スタッフは、意思決定の合理化、クルーのロジスティクスの最適化、本社業務の生産性向上によるメリットを享受できます。同時に、デュアル クラウド戦略が、インフラストラクチャの復元力を強化し、2034 年までに乗客数を 3 億人に増やすという同社の目標達成を支えています。

Smyths Toys: エージェント型サポートでカスタマー エクスペリエンスを刷新

世界最大級の玩具専門小売業者である Smyths Toys は、Google Cloud と Gemini Enterprise を活用してカスタマー サポートを刷新しています。AI エージェント「Codie」を導入したことで、同社はウェブ問い合わせの 60% 以上を自己解決へと導き、ホリデー シーズンの未対応メールの滞留を削減しました。繁忙期には 1 日最大 1,000 件のメール対応に追われていたカスタマーケア チームが、より複雑な判断を要する約 50 件の問い合わせに集中できるようになりました。

アイルランド歳入庁: 公共部門のデータを進化

アイルランドでは、公共機関も進歩を遂げています。税金や関税を管理し、アイルランド経済の円滑な運用を支えるアイルランド歳入庁は、Google Cloud と連携して、従来のオンプレミス システムから統合 AI レイクハウス アーキテクチャへの移行を進めています。このアーキテクチャは、データサイロを解消し、信頼できる唯一の情報源を確立するよう設計されています。厳格なデータ主権管理によって納税者情報を保護する一方で、Gemini Enterprise がエージェント型データ分析を推進し、歳入庁がセキュアで迅速かつ柔軟な行政サービスを提供できるよう支援しています。

Virgin Media Ireland: ワークフローを高速化

Google Cloud と Liberty Global のパートナーシップのもと、Virgin Media Ireland は AI の活用を概念検証から本番環境へと移行させています。最新のインフラストラクチャと自動化により、同チームはワークロードのデプロイ速度を 3 倍に向上させました。現在は複数の AI エージェントの展開を進めているほか、事業成長を牽引する新たなカスタマー サービスの立ち上げに取り組んでいます。

エンタープライズ向けツールで事業を拡大するアイルランドのスタートアップ

既存の大手企業がレガシー システムのモダナイズを進める一方で、アイルランドのスタートアップは創業初日から最新のテクノロジーを基盤にビジネスを展開しています。現地の強固なテクノロジー エコシステムに支えられたこれらの機動的なチームは、グローバルな舞台で競い合えるサービスを生み出しています。

Hexis: パーソナライズされたスポーツ栄養の提供を拡大

Hexis は、アスリートがパフォーマンスの最大化とコンディションの回復を図るためのテクノロジー ソリューションを開発しています。同社は、リアルタイムの生体データや行動データを Google Cloud 上で保存および処理し、Gemini Enterprise を活用して自然言語での対話機能を実現しています。これにより、ユーザーに対して 1 日を通じた最適な栄養補給の調整方法を説明しています。現在、このプラットフォームは、ツール・ド・フランスの集団に属する選手の 40% と、2026～2027 年シーズンのプレミアリーグ加盟クラブの半数をサポートしています。

Kitman Labs: パフォーマンス分析を統合

2012 年にダブリンで設立された Kitman Labs は、世界 26 か国、4,000 以上のスポーツ組織に向けて、スポーツ サイエンスとパフォーマンス インテリジェンスを提供しています。同社は、自社のインテリジェンス プラットフォームに高度なアナリティクスと Gemini Enterprise を組み合わせることで、チームがデータに基づく意思決定を行えるよう支援しています。これにより、アスリートの健康維持、怪我のリスク軽減、選手のキャリア延伸に貢献しています。

Spryt: 医療連携の自動化

Spryt は、Google Cloud と Gemini Enterprise を基盤とする AI を使用し、患者体験の最適化、無断キャンセルの削減、管理業務の負担軽減を実現することで、英国と米国における医療連携の効率化を図っています。同社は NHS と連携し、米国の 70 以上のクリニックで事業を展開しています。また、Mayo Clinic との複数年にわたる共同プロジェクトの一環として、これまでに 2 億 2,400 万件もの予約実績データを分析してきました。

IMPT: カーボン オフセットを自動化

IMPT は、AI、ブロックチェーン、Google Cloud を連携させることで、検証済みのカーボン オフセットを日常的なホテル予約やオンライン購入に組み込んでいます。15 週間かけて Google Cloud に移行した同社は、195 か国で 800 万件のリスティングをサポートしています。Gemini Enterprise の導入により、同社の少数精鋭チームは 1 日あたり約 400 件の顧客チャットに対応し、応答時間の中央値 6 秒という迅速なサポートを実現しています。これにより、スタッフはシステム管理の手間から解放され、ビジネスの成長に注力できるようになりました。

アイデアを構想から本番環境へ

アイルランドが世界のテクノロジー ハブとして発展を続けるなか、現地の組織は AI の持つ可能性をいかにして実質的な成果へと結びつけるか、その実践例を示しています。お客様事例をご覧いただき、他の組織が Google Cloud をどのように活用しているかをご確認ください。また、アイルランドの Google チームにお問い合わせいただき、導入への取り組みを加速させてください。

- Google Cloud 英国およびアイルランド担当マネージング ディレクター、Sandeep Khanna

※この投稿は米国時間 2026 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

企業や個人の開発者は、複数の AI 推論モデルを頻繁に実行しています。適切なアーキテクチャを使用することで、モデルの呼び出し方法を簡素化すると同時に、一元化されたガバナンスを提供できます。この投稿では、ネットワークにおける AI 推論モデルの提供に焦点を当てた 2 つのリファレンス アーキテクチャについて説明します。1 つは Google Kubernetes Engine（GKE）用、もう 1 つはその他のすべてのバックエンド タイプ用です。まず、後ほど紹介するリファレンス アーキテクチャの共通点について説明します。次に、GKE バックエンドのアーキテクチャに固有のコンポーネントについて説明し、最後に、すべてのバックエンド タイプに共通するアーキテクチャの要素を確認します。

エントリ ポイント

推論呼び出しのフロントエンドとして機能する、高い安定性、セキュリティ、信頼性を持つエントリ ポイントの背後にモデルのデプロイを公開できます。このエントリ ポイントは、ポリシー、セキュリティ、ロジックを適用できる制御ゾーンとしても機能します。Cloud ロードバランサと推論ゲートウェイはどちらもエントリ ポイント機能を提供します。これらのタイプのエンドポイントは、TLS によるセキュアな接続の終端、API 管理コンポーネントとの統合、Service Extensions による機能の拡張、Model Armor の機能を活用したセキュリティ強化が可能です。

設計における共通サービス

どちらのリファレンス設計でも、次のサービスを使用します。

• Private Service Connect 推論エンドポイント: 消費者の Virtual Private Cloud（VPC）ネットワーク内にエントリ ポイントを固定します。トラフィックはプライベート内部 IP アドレスに到達するため、推論呼び出しはプライベート ネットワーク内に保持されます。

• Apigee API Management（省略可）: Apigee Extension Processor コールアウトを介して統合され、リクエストがコンピューティング リソースに到達する前に、クライアント ID の検証、レート制限、割り当ての適用を処理します。

• Model Armor: インライン AI 安全性チェックポイントとして機能し、プロンプト インジェクションや機密データの漏洩がないか、プロンプトと出力補完をスクリーニングします。

GKE のみで提供される設計パターン

このセクションでは、GKE のみのバックエンド設計に焦点を当てます。エンドツーエンドのコンセプトを完全に理解するには、アーキテクチャに関するドキュメント GKE での AI 推論モデル提供のためのネットワーキングをすべてお読みください。設計パターンは、次の図に基づいています。

前のセクションで特定した共通サービスに加えて、GKE の設計では次のコンポーネントを使用します。

• GKE Inference Gateway: 内部アプリケーション ロードバランサ（gke-l7-rilb）としてデプロイされます。受信リクエストのペイロードを解析し、HTTPRoute ルールを評価して、適切なモデル提供ターゲットにクエリを転送する、特殊な内向きエンジンとして機能します。

• 推論プール: 同じモデルのレプリカを含む論理グループ。Gateway はプロンプトを受け取ると、HTTPRoute ルールを評価し、モデル識別子に基づいて適切な推論プールを選択します。プールには初期サイズがあり、動的に自動スケーリングされるように構成できます。

• モデル レプリカセット: シングルノードまたはマルチノードの GPU または TPU ノードプールにデプロイされた個々のモデルレプリカ（推論サーバー インスタンス）。レプリカセットは、これらのモデルレプリカの均一なグループを表します。

GKE のトラフィック フローの例

この GKE ベースのアーキテクチャを使用してバックエンド モデルを呼び出すクライアント アプリケーションは、次のようなフローをたどります。

• 内向き: コンシューマー VPC 内のクライアント アプリケーションが、ローカルの Private Service Connect エンドポイントに対して OpenAI 互換の API 呼び出しを発行し、リージョン内部アプリケーション ロードバランサを使用して GKE Inference Gateway に直接ルーティングします。

• ペイロード検査: Gateway は、リクエスト本文で指定されたターゲット モデル パラメータを読み取り、HTTP ヘッダーに追加します。

• コントロール プレーンの検証: Apigee が使用されている場合、クライアントの認証情報と割り当てがチェックされます。Model Armor がプロンプトをスクリーニングし、ポリシー違反やデータ漏洩がないかを確認します。

• バックエンドの選択: Gateway は HTTPRoute マッピングを評価してターゲット プールを特定し、プレフィックス キャッシュ共有コンテキストを照合して、リアルタイムの Prometheus データに基づいて最も負荷の低い GPU または TPU レプリカにルーティングします。

• 外向き: レプリカが推論ワークロードを実行します。出力トークンは Model Armor を通過して最終的なレスポンス検証が行われ、その後、プライベート接続を介してストリーミングで送り返されます。

すべてのバックエンドで提供される設計パターン

このセクションでは、推論に使用できる複数のバックエンド タイプに焦点を当て、次の図に示すアーキテクチャの概要を説明します。エンドツーエンドのコンセプトを完全に理解するには、アーキテクチャに関するドキュメントすべてのバックエンドでの AI 推論モデル提供のためのネットワーキングをすべてお読みください。

GKE、Cloud Run、Agent Platform、オンプレミス データセンター、外部クラウドなどの混合環境にまたがるアーキテクチャでは、次のコンポーネントが追加で使用されます。

• リージョン内部アプリケーション ロードバランサ: ルーティング ロジック、SSL 終端、Service Extensions コールアウトを管理する、中央のレイヤ 7 ルーティング プロキシとして機能します。

• 推論ペイロード プロセッサ（Service Extensions）: これは、GKE Inference Gateway で使用される本文ベースのルーティングに似ていますが、アプリケーション ロードバランサでこの機能を有効にするには、Service Extensions が必要です。軽量の Cloud Run コールアウトが、受信した OpenAI API リクエストの JSON 本文を検査し、ターゲット モデル識別子を抽出して、URL マップによるルーティングを実行するために X-Gateway-Model-Name ヘッダーを書き込みます。

• ネットワーク エンドポイント グループ（NEG）: 書き込まれたモデルヘッダーに基づいて、異種バックエンドへの柔軟なルーティングを実現します。

すべてのバックエンドのトラフィック フローの例

このアーキテクチャを使用してバックエンド モデルを呼び出すクライアント アプリケーションは、次のようなフローをたどります。

1. プライベート内向き: クライアント アプリケーションは、プライベート IP アドレス空間を介して Private Service Connect エンドポイントをターゲットにします。リージョン内部アプリケーション ロードバランサがリクエストを受信します。

2. モデル名の抽出: ロードバランサは、ペイロードを Cloud Run 本文ベースのルーター コールアウトに送信します。このコールアウトは、JSON ペイロードを検査して X-Gateway-Model-Name ヘッダーを挿入します。

3. ポリシーと安全性の適用: リクエストは Apigee に渡されて ID と割り当てが検証され、その後 Model Armor に渡されて機密データが削除され、悪意のあるプロンプトがブロックされます。

4. NEG ルーティング: ロードバランサの URL マップがモデルヘッダーを検査し、一致するバックエンド NEG（Agent Platform、GKE、Cloud Run、ハイブリッド、インターネット）にリクエストを転送します。

5. プライベート配信: ターゲット バックエンドがモデル プロンプトを実行し、Model Armor が補完をスクリーニングして、結果が内向きパスに沿ってプライベートに返されます。

次のステップ

Google Cloud での AI ワークロードの構築について詳しくは、以下をご覧ください。

• ドキュメント セット: エージェント型 AI アーキテクチャ ガイド

• アーキテクチャ センター: Google Cloud におけるマルチエージェント プライベート ネットワーキング パターン

• ドキュメント: Gemini Enterprise Agent Platform のネットワーキング アクセスの概要

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズ エンジニア、Ammett Williams

※この投稿は米国時間 2026 年 10 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

9 月はスケーラビリティ月間です。世界がエージェント フリートの急増に備えるなか、Google はそのニーズに迅速かつ適切に対応できるように AI インフラストラクチャとオーケストレーション サービスを強化するとともに、ワークロードの分離とセキュリティを維持し、コストを抑えています。今回の記事では、Google Cloud のコンピューティング、ネットワーク、ストレージ、オーケストレーションのサービス全体でこれらの機能強化がどのように現れているかに加えて、お客様が Google Cloud AI インフラストラクチャを使用する新しい方法、Google の戦略に対するサードパーティの業界検証をご紹介します。

プロダクト、テクノロジー、ツールに関する最新情報

Google Kubernetes Engine の更新: GKE チームはプラットフォームのスケーラビリティの向上に全力を注いでいます。9 月には、さまざまな形や規模で改善が行われました。

• 新機能: エージェント ワークロードに、より高密度の実行ランタイムが必要ですか？新しいオープンソースの GKE Agent Substrate は、標準的なコンテナ ランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。また Agent Substrate は、ネイティブのゼロトラスト カーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。

• プロダクトの最新情報: GKE にゼロへのスケーリング機能が組み込まれました。ワークロードをスケールダウンするために複雑なコンポーネントを構成する必要はありません。AutoscalingMetric を使用した HPA と KEP-2021 のサポートにより、その作業はすぐに自動的に行われます。詳細については、こちらのブログ記事をお読みください。

• プロダクトの最新情報: さらに、GKE HPA（前述の AutoscalingMetric を使用）では、標準指標に加えてカスタム PromQL 指標に基づいてスケールアップとスケールダウンを行えるようになりました。これにより、ビジネスにとって意味のある独自の条件に従ってワークロードをトリガーできます。詳しくはこちらをご覧ください。

• 新機能: もう一つのスケーラビリティ機能は GKE Pod スナップショットです。これは、CPU や GPU のメモリを含むワークロードの実行状態を保存し、オンデマンドで復元できるようにするものです。内部テストによると、GKE Pod スナップショットにより、AI 推論の起動時間を最大 89% 短縮できます。詳しくはこちらをご覧ください。

• 新しい移行ツール: 最後に、コンテナ ワークロードを AWS EKS から GKE に移行したいと考えていたものの、困難で摩擦の多いエンジニアリング作業を恐れていた方のために、GKE エージェント型移行をリリースしました。これは、不安定なアドホック プロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェント プラグインです。エージェント スキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを GKE ランディング ゾーンに直接変換します。オンボーディング ガイドを確認して利用を開始しましょう。

• 機能の更新: 強化学習（RL）と評価のワークロードは非常に複雑です。標準的なエージェント RL ループでは、LLM ポリシーが GPU 上でコード スニペットなどのアクションを生成し、分離された CPU サンドボックス内で実行して報酬シグナルを観察します。しかし、このループをスケールアップして数万の並列ロールアウトをサポートしようとすると、アクセラレータのアイドル状態、イメージのカーディナリティ、コントロール プレーンの飽和など、インフラストラクチャのボトルネックが発生します。そこで、RL 向けに最適化された GKE Agent Sandbox に加えて、Agent Sandbox RL オーケストレーション SDK、一般的な RL ジムやハーネスとのネイティブ連携機能を開発しました。すべて一般提供が開始されています。詳しくはこちらをご覧ください。

ストレージの最新情報: AI は大量のデータをトレーニングして作成します。そのデータは、ブロック ストレージ システム、ファイル システム、オブジェクト ストア、データベースのいずれかに保存する必要があります。この重要なレイヤがエージェントの要求に対応できるよう、ストレージ ポートフォリオの強化を発表しました。

• プロダクトの最新情報: Filestore エージェント ボリュームは、エージェント ワークロード向けに高パフォーマンスで柔軟な永続ファイル ストレージを提供します。GKE Agent Substrate および GKE Agent Sandbox との緊密なインテグレーションにより、Filestore エージェント ボリュームは、分離された専用ファイル ワークスペースを GKE Agent Sandbox にミリ秒単位で自動的に割り当て、アタッチします。プレビュー版へのアクセスはこちらからリクエストできます。

• 新しいプロダクト: 生成 AI と RAG のデータレイヤ（Milvus、Pinecone、Qdrant、Vespa、Redis、インメモリ コンテキスト キャッシュなど）を実行している場合は、M4N ファミリーの VMをご覧ください。一般提供が開始されたこれらの VM は、主要なハイパースケーラーの中でコアあたりの IOPS とスループットが最高です。M4N インスタンスは、Google Cloud のカスタム Titanium オフロード アーキテクチャおよび Hyperdisk Extreme と組み合わせることで、ホストあたり合計で最大 25,000 MiB/秒（25 GiB/秒）のストレージ スループットと最大 100 万 IOPS を実現します。

• 新しいプロダクト: もう一つの新しい Compute Engine プロダクトである Z4D の一般提供が開始され、AI / ML のトレーニングおよび推論ワークロード向けの強力なストレージ ソリューションとしてご利用いただけるようになりました。ベアメタル インスタンスとして構成すると、Z4D はエージェント型マイクロ VM に必要な大容量のローカル SSD（LSSD）と低レイテンシの両方を提供するため、ホストごとに数千の分離されたサンドボックスをネイティブのパフォーマンスと効率で実行できます。Z4D マシンの詳細はこちらでご確認ください。

• プロダクトの最新情報: 現在の AI トレーニングや推論のパイプラインは、ほとんどのストレージ管理システムが対応できないほどのスピードでデータを作成するため、ストレージ資産を把握しようとするチームにとって課題となっています。Storage Intelligence アドバイザーの新バージョンでは、「バケットには何が入っているか？」という疑問の答えが簡単にわかり、予期しない変更をすばやく特定できます。さらに、強化されたバッチ オペレーションにより、バケット全体にわたる一括変更、たとえば、ストレージ クラスの移動、古いデータや一時データの一括削除、メタデータ、タグ付け、保持、暗号化の変更の適用などを自動化できます。Storage Intelligence アドバイザーの最新情報については、こちらをご覧ください。

• 新しいプロダクト: 最後に、AlloyDB for PostgreSQL の新バージョンは、Google の先駆的なインフラストラクチャである Colossus 分散ファイル システムと Jupiter ネットワークを統合し、エージェントの時代における妥協のない新しいデータベース アーキテクチャを実現します。

実践ガイドとハウツー

• ハウツー: 世界中に分散している GPU と TPU を、単一のエントリ ポイントの背後にある単一のプールとして動作させたいとお考えの場合は、こちらのブログ記事でその方法をご確認いただけます。エッジでは、マルチクラスタ GKE Inference Gateway が、グローバルなマルチリージョン トラフィック分配と高可用性を担います。その下では、LLM-d ルーターが、使用率を高く維持するための複雑なメモリ認識型スケジューリング アルゴリズムを処理します。このアーキテクチャは、ランタイム、モデル、アクセラレータに依存しないように意図的に設計されており、テストでは、マルチクラスタ GKE Inference Gateway を介してトラフィックをルーティングしたところ、オーバーヘッドは 1% 未満でした。

• ガイド: AI モデルのトレーニングや推論に TPU 上の GKE を使用されているか、使用される予定ですか？巨大な大規模言語モデル（LLM）のトレーニングや、高スループットの推論サービングの実行には、Cloud TPU や Cloud GPU などの特殊な AI ハードウェアへの多額の投資が必要です。費用対効果を最大化するには、GKE のワークロード ライフサイクル指標を理解する必要があります。この詳細なガイドでは、不透明なクラスタの動作を実用的なテレメトリーに変換する方法を説明します。

お客様とパートナーに関する最新情報

• GKE のお客様: ゲームのスタートアップである SeaVerse がマルチテナント ワークロードに GKE Agent Sandbox を利用している理由と、このプラットフォームによってインフラストラクチャ費用を 60% 削減できた経緯をご覧ください。

調査、レポート、詳細解説

また、Google は Gartner と Forrester の 3 つの主要なアナリスト レポートでリーダーに選出され、プロダクトまたは戦略のいずれかで最高スコアを獲得しました。

• Google、「The Forrester Wave™: Public Cloud Platforms, Q3 2026」でリーダーに選出: クラウド プロバイダの中で最高の総合スコアを獲得しました。

• Google、2026 年 Gartner® Magic Quadrant™ で戦略的クラウド プラットフォーム サービス部門のリーダーに選出: 評価対象となったすべてのベンダーの中で、「ビジョンの完全性」において最高評価を獲得しました。

• Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出: 評価対象となった全ベンダーの中で「実行能力」において最高評価を獲得しました。

• Google Cloud は、世界中の GPU プロバイダの信頼性、パフォーマンス、サポート、料金、セキュリティを評価する最新の SemiAnalysis ClusterMax 3.0 レポートでゴールド評価を獲得しました。詳しくは、レポート全文をご覧ください。

2026 年 8 月

プロダクト、テクノロジー、ツールに関する最新情報

• プロダクトの最新情報: Filestore は Google Cloud がファーストパーティとして提供するセキュアでスケーラブルな NFS ファイル サービスであり、AI やエージェント ワークフロー向けのストレージ プラットフォームとして人気を集めています。このたび、Google の基盤となる分散ストレージ システムである Colossus 上に直接構築された新しいバックエンド ストレージ レイヤが追加され、これらのタスクにさらに適したサービスとなりました。この新しいバックエンドでは、ストレージ容量とは別に IOPS をプロビジョニングでき、GKE と緊密に統合されています。AI 環境では、いわゆるエージェント スウォーム（多数のエージェントからなる大規模なグループで、共通のデータセットに対して読み取りと書き込みを行う必要がある）を、パフォーマンスを低下させることなく処理できます。詳しくは、ブログ投稿をご覧ください。

• 新機能: gVisor サンドボックスを GKE 上の分散 Ray クラスタで利用できるようになりました。Anyscale との提携により、gVisor を分散 Ray クラスタに直接組み込むことができる、Ray 向けの試験運用版ライブラリを導入しました。gVisor は Google のオープンソース アプリケーション カーネルであり、通常のコンテナよりも強力な分離機能を持ち、起動時間が短く、メモリ オーバーヘッドが少ない軽量な環境を提供します。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックス ユーザーガイドをご覧ください。

• プロダクトの最新情報: 費用はあまりかけたくないけれど、パーソナル AI エージェントを実行するための高性能で使いやすいインフラストラクチャをお探しという方に朗報です。新しい Cloud Run インスタンスは、Cloud Run 上の専用のシングルトン コンピューティング ランタイムであり、エージェントがアイドル状態になってもシャットダウンされません。さらに、1 個の vCPU と 1 GiB のメモリを備えた Cloud Run インスタンスを 30 日間連続で実行しても、費用は 5.70 ドルしかかかりません。

実践ガイド、ドキュメント、ハウツー

• 入門ガイド: Model Context Protocol（MCP）に関する最新情報: 2026-07-28 仕様で、プロトコル コアは「完全にステートレスになりました。handshake はなくなり、initialize / initialized handshake（SEP-2575）と論理的な Mcp-Session-Id ヘッダー（SEP-2567）は完全に削除されました。代わりに、すべてのリクエストが自己記述型で独立したものになりました。」最新の MCP 仕様の変更点と、さらに重要なその実装方法について詳しくは、こちらの Google for Developers のブログ記事をご覧ください。

• ガイド: 従来のネットワーク ロード バランシング手法では、リアルタイム AI システムをうまく扱いきれない場合があります。「バックエンドは、今までのように個別のリクエストを処理するのではなく、継続的なライブ双方向ストリームを管理する必要があります。音声チャンク、文字起こし、モデル出力、合成音声が同時にやり取りされる、絶え間ないストリームを処理するからです。」ここにユーザーへの対応が追加されると、状況はさらに悪化します。「サーバーは、現在処理中の音声生成を即座に停止して、コンテキストを更新し、場合によっては新しいツールをトリガーして、別の回答の作成を開始する必要があります。また、これを接続を切断することなく行わなくてはなりません。」AI 時代における負荷管理の新しいアプローチについては、セッション対応のロード バランシングによるリアルタイム AI エージェントのスケーリングをご覧ください。

• ハウツー: さまざまな GPU アクセラレータが混在する場合でも、GKE 上に弾力性のあるスケーラブルな LLM 推論プラットフォームを構築する方法を学びます。ここで提案するアーキテクチャでは、Capacity Advisor と Compute Advisor に加え、Run:ai Model Streamer や、並列ダウンロード機能を備えた GCSFuse などの高性能ストレージを組み合わせて使用します。詳しくは、こちらをご覧ください。

• ドキュメント: GPU や TPU を搭載したホストの問題は、ライブ マイグレーションを使用して更新することができないためにメンテナンスが困難であることです。この新しいドキュメント ページでは、トレーニング ワークロードと推論ワークロードのダウンタイムをどれだけ許容できるかに応じて、アクセラレータ搭載ホストを更新する方法を説明します。

• ドキュメント: Advanced Compute Images（ACI）は AI / ML および HPC インフラストラクチャ用の標準化されたイメージ スタックであり、独自のカスタム イメージを手動で構築する必要はありません。この新しいドキュメント ページでは、Google Cloud CLI、コンソール、または SchedMD の Slurm ワークロード マネージャーを使用して ACI イメージを作成する方法を説明します。

• ガイド: AI ワークロードは、設計の難しさ、リソース消費の激しさ、そしてバースト性があることで知られています。これらはスケーリングのボトルネックを招くだけでなく、十分に活用されない（または誤用される）コンピューティング リソースを大量に発生させる原因にもなります。新しいブログ投稿では、Google Cloud で動的な容量管理を実現する 3 つの主な方法について説明します。その 3 つの方法は以下のとおりです。1）計画的なダウンタイムに備えて容量をスケジュールする、2）計画外のダウンタイムに備えて自動フォールバック容量を確保しておく、3）GKE のコア オーケストレーション機能を利用してリソース割り当てを自動化する。

お客様とパートナーに関する最新情報

• ビジネス オーケストレーション ソフトウェア プロバイダの UiPath は、急激に変動するワークロードに対処し、費用の予測可能性を高めたいと考えていました。これを実現するために、同社は分離された複数のクラスタで構成されていたインフラストラクチャを再設計し、トレーニング用の A3 VM インスタンス（NVIDIA H100 GPU）と推論用の G4 VM インスタンス（NVIDIA RTX PRO 6000 Blackwell Server Edition GPU）の両方を含む共有 Google Cloud GPU フリートへと移行しました。同社のアーキテクチャについて詳しくは、こちらをご覧ください。

• AI 開発の加速に注力する最先端の AI 研究所である Mirendil は、モデルの事前トレーニングとトレーニング後のアプリケーションをサポートするために、TPU と NVIDIA GPU の両方を備えた AI Hypercomputer を使用することを発表しました。

• 小売業向け CRM プロバイダの Replenit は、BigQuery、Gemini Enterprise Agent Platform、Cloud TPU で実行するオープンソースの Gemma モデルを使用して、Google Cloud で AI 意思決定エンジンを構築しました。同社では、この組み合わせにより、以前のクラウド プロバイダと比較してパイプライン費用が 90% 削減されたとしています。詳しくは、事例紹介の全文をご覧ください。

• Malachyte は、Bigtable、Managed Service for Apache Kafka、Pub/Sub、Compute Engine、そして GKE を基盤として、AI を活用した e コマース レコメンデーション プラットフォームを構築しました。こちらのブログ記事で、これらがどのように連携するかをご覧ください。

2026 年 7 月

プロダクト、テクノロジー、ツールに関する最新情報

• プロダクトの最新情報: Google Cloud Managed Lustre の一般提供が開始されました。4 種類のパフォーマンス ティアがあり、容量 1 TiB あたり 125 MB/秒、250 MB/秒、500 MB/秒、1,000 MB/秒のスループットを選択できます。ストレージ容量は最大 8 PB までスケールアップ可能です。Managed Lustre ソリューションは DDN の EXAScaler を活用しており、DDN が数十年にわたって培ってきた高パフォーマンス ストレージ界をリードする技術と、Google Cloud のクラウド インフラストラクチャに関する専門知識を組み合わせています。

• プロダクトの最新情報: C4N ネットワーク / ストレージ最適化 VM の一般提供を開始しました。C4N は、データ転送のボトルネックを解消するために構築された、Google 初のネットワークとブロック ストレージに最適化された VM シリーズです。第 5 世代 Intel Xeon スケーラブル プロセッサを搭載し、Google の Titanium オフロード ハードウェア上に構築された C4N は、400 Gbps のネットワーク帯域幅と 9,500 万パケット/秒（95 MPPS）の処理速度を実現します。また、Hyperdisk Extreme と組み合わせた場合のブロック ストレージ スループットは最大 25 GiB/秒に達します。

• 新機能: GKE Dataplane V2 が、ネットワーク ポリシー適用下で最大 15,000 ノードまでサポートできるようになりました（一般提供）。これにより、標準の GKE クラスタ上で、ネットワーク ポリシーの適用を完全に維持したまま、最大 15,000 ノードまでのスケールアップが可能になります。大企業や AI / ML を活用するお客様の膨大なインフラストラクチャ ニーズに対応する機能です。

• 新機能: llm-d が協調型タイムスライスに対応しました。強化学習（RL）ワークロードで、独立した RL ジョブを共有の物理ハードウェアにインターリーブして実行できるようになりました。これにより、モデルの収束や精度に影響を与えることなく、アクセラレータの総デューティ サイクルをベースラインの約 40% から最大 70% まで引き上げることが可能です。

• 新しい AI セキュリティ ツール: GKE 上の AI サプライ チェーンの保護、AI ワークロードの安全なデプロイ、シャドー AI の削減をお考えですか？Google は k8s-aibom をオープンソース化しました。これは、コンテナ クラスタを継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning 部品構成表（ML-BOM）を生成する、軽量で特権を必要としない Kubernetes コントローラです。k8s-aibom プロジェクトをチェックして、ぜひ開発にご参加ください。

実践ガイドとハウツー

• 入門ガイド: 7 月 27 日、Google は Moonshot AI の 2.8 兆パラメータのオープンウェイト モデルである Kimi K3 の「Day 0 サポート」を発表しました。モデルのウェイト公開と同時にサポートを開始し、即日の利用を可能にしました。Model Garden、カスタム オーケストレーション、llm-d レシピを使用した GKE など、選択したデプロイ手法に合わせて Google Cloud で Kimi K3 を評価して試験運用するための詳細な手順をこのガイドでご確認いただけます。

• 入門ガイド: Google Kubernetes Engine（GKE）マネージド DRANET は、GPU と TPU の両方に対応しています。この実装を使用するための構成には、標準クラスタ（ユーザーが完全に制御可能）や Autopilot クラスタ（Google によって複雑な構成が自動的に行われる）など、いくつか選択肢があります。詳細については、ハンズオンラボ TPU を使用する GKE Autopilot クラスタ、GKE マネージド DRANET、Gemma 4 でご確認いただけます。

• 入門ガイド: GPU ではなく TPU で Ray を実行する方法を学べます。全 2 回シリーズのパート 1 では、TPU スライスについて説明します（ヒント: Ray は TPU スライスを、スケジュール設定可能なアクセラレータの一種として認識します）。続くパート 2 では、Ray のさまざまな AI ライブラリについて説明します。

• 入門ガイド: 新しいマイクロベンチマーク スイートを使用して、サンプル ワークロードにおける TPU の性能を評価します。このスイートを活用することで、デバイスが理論上のパフォーマンス仕様を達成しているかを正確に測定できるほか、特定の性能ギャップやアーキテクチャ固有のボトルネックを特定することも可能です。詳細はこちらでご確認いただけます。

• 入門ガイド: 予算を圧迫することなく、エージェントをスケールしましょう。GKE Agent Sandbox と Pod スナップショットを活用して固定のコンピューティング リソース内でより多くのエージェントを安全に集約する方法を、GKE オーケストレーションの観点から解説します。パフォーマンス重視かコスト重視かを問わず、エージェントの効率を最大化するための適切な最適化方法を解説します。

• 技術ブループリント: Ironwood における Mistral 3 Large 推論の最適化について詳細に解説します。こちらのブログ記事では、Google のあるチームが Google の Ironwood（TPU v7x）で Mistral 3 Large MoE モデルの推論を最適化し、パフォーマンスを 1.5 倍向上させた方法について説明しています。具体的には、ハイブリッド シャーディングの導入、線形 VPU 合計からツリー リダクションへの置き換え、GMM / MLA カーネルの最適化、非同期スケジューリングの採用によって、これを実現しました。その結果、ベンチマーク精度を維持したまま、スループットを最大 48% 向上させるという成果を収めました。ブログの全文はこちらでご覧ください。

調査、レポート、詳細解説

• レポート: Google は、初めて発表された GartnerⓇ Magic Quadrant™ の AI インフラストラクチャ部門において、リーダーに選出され、「実行能力」で最高位、「ビジョンの完全性」で最も先進的との評価を獲得しました。Gartner は、Google 独自の拡張可能なコンピューティング、統合された AI Hypercomputer アーキテクチャ、AI コンピューティング容量の規模を主な強みとして挙げています。レポートはこちらからダウンロードしてお読みいただけます。

• レポート: Google は先ごろ、「AI インフラストラクチャの現状」レポートの作成にあたり、1,400 人を超える IT 部門の上級リーダーを対象に調査を実施しました。その結果、AI に対する構想とインフラストラクチャの実態との隔たりが広がっているという明確な傾向が浮かび上がりました。実際、83% の組織が、本番運用に対応できるエージェント型 AI を支えるには、インフラストラクチャのアップグレードが必要だと回答しています。この調査について紹介したブログ記事では、エージェント型アプリケーションがシステムに求める要件に合わせてインフラストラクチャを整備することで、試験導入から本番運用への移行を進めやすくなることを説明しています。

2026 年 6 月

プロダクト、テクノロジー、ツールに関する最新情報

• プロダクトの最新情報: AI で使用される機密データの保護は、先進的でセキュアなクラウド インフラストラクチャを実現するうえで欠かせない要素です。Confidential Computing は、ハードウェアベースの高信頼実行環境（TEE）で使用中のデータを暗号で保護し、データの完全性を検証可能にする技術です。このたびこの技術が、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載したアクセラレータ最適化型 G4 マシンシリーズで提供開始されました。Confidential G4 VMs と Confidential G4 GKE Nodes をぜひ使ってみてください。

• デベロッパー向けリソース: 新設された TPU デベロッパー ハブは、モデルの作成者、最適化担当者、デベロッパーが Google Cloud TPU のパフォーマンスを最大限に引き出す方法を学ぶための場所です。詳細については、こちらのブログ記事をご覧ください。

• 新プロダクト: 新しい OpenTelemetry ベースの TPU AI テレメトリー コレクタ エージェントを使用して、AI ワークロードをスケールしましょう。このたび初めて、高忠実度の TPU ハードウェア テレメトリーを、Google Cloud Monitoring、Google Managed Prometheus、または独自のセルフホスト型 Grafana スタックにルーティングできるようになりました。

実践ガイドとハウツー

• 入門ガイド: TPU、Cloud Storage FUSE、動的リソース割り当て（DRA）を使用して、GKE Inference Gateway で実行される AI 推論ワークロードで高可用性を実現する方法を学べます。こちらのブログ記事で概要を紹介しています。また、技術的な詳細についてはハンズオン Codelab でご確認いただけます。

• 入門ガイド: Model Context Protocol（MCP）を使用して、AI エージェントを Cloud Storage の非構造化データに接続できることをご存じですか？こちらのブログ記事では 3 つのお客様事例に基づく導入のメリットと、具体的な実装方法を解説しています。フルマネージド サービスにすべきか、詳細なカスタマイズと管理が可能なセルフマネージド ローカル サーバーにすべきかを判断する方法もご紹介しています。

調査、レポート、詳細解説

• レポート: 第三者機関によるベンチマーク レポートにおいて、GKE Inference Gateway は他社の主要マネージド Kubernetes サービスを凌駕するパフォーマンスを記録しました。具体的には、スループットは 15.7% 高く、待ち時間は 92.8% 短く、トークン間のレイテンシは 62.6% 低いという結果でした。このパフォーマンスの鍵は、接頭辞キャッシュの使用にあります。長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化しています。詳しくは、こちらのブログ記事をご覧ください。

• アーキテクチャの詳細解説: 今回は TPU と GKE におけるコールド スタート問題を深堀りし、Run:ai Model Streamer がどのようにその状況を変えられるかについて解説します。

お客様とパートナーに関する最新情報

• お客様の成功事例: Pager Health は、GKE、BigQuery、Cloud SQL、Gemini Enterprise Agent Platform を活用して運用の断片化を解消し、人々の生活に大きな変化をもたらすシンプルかつパーソナライズされた医療体験を米国で展開しています。

• お客様の成功事例: カスタマー レビュー プラットフォームの Trustpilot は、A100 GPU 搭載のコスト最適化済み A2 VM 上で Dataflow と Gemini Enterprise Agent Platform を活用して、大規模なストリーミング パイプラインを構築しました。ファインチューニングされた Gemma モデルや、同プラットフォームが管理する最適化版 vLLM を採用しています。

2026 年 5 月

プロダクト、テクノロジー、ツールに関する最新情報

• プロダクトの最新情報: GKE Agent Sandbox の一般提供が開始されました。

• 新しいオープンソース プロジェクト: Agent Substrate は、エージェント インフラストラクチャの密度を限界まで高めることを目指す、新しいオープンソース プロジェクトです。

• 新機能: Google AI Edge Portal は、オンデバイス ML を大規模にテストしてベンチマーク評価するためのソリューションです。このたび、オンデバイス LLM のベンチマークとデバッグに対応しました。詳しくはこちらをご覧ください。

• プロダクトの詳細解説: AI ワークロード向けの新しい高性能ストレージ サービス ファミリーである Cloud Storage Rapid について詳しく説明しました。リリース時点でご利用いただけるサービスには、高パフォーマンスのゾーン オブジェクト ストレージ サービスである Rapid Bucket（旧称: Rapid Storage）と、オンデマンドで読み取りを高速化して既存バケットのワークロードのコンピューティングとデータをコロケーションする Rapid Cache（旧称: Anywhere Cache）が含まれます。

調査、レポート、詳細解説

• アーキテクチャの詳細解説: Google グローバル インフラストラクチャ担当バイス プレジデントの Bikash Koley とエンジニアリング フェローの Arjun Singh が、AI ワークロードがネットワーク インフラストラクチャにもたらす課題の概要を説明し、AI ワークロードをより適切にサポートするためにデータセンター ファブリック、WAN、グローバル ネットワークに施した大幅な機能強化をご紹介します。

• アーキテクチャの詳細解説: TPU で最先端の AI モデルを開発するために、インスタンス レベルの信頼性モデルを廃止し、新しいクラスタレベルの信頼性モデルを公開しました。

お客様とパートナーに関する最新情報

• お客様の成功事例: ビジュアル メディア プロバイダの Imgix は、NVIDIA RTX PRO 6000 Blackwell GPU 搭載の G4 VM を備えた AI Hypercomputer を活用して、80 億を超える画像や動画を配信しています。

- Google Cloud ブログ編集者、Alex Barrett

Imagining traditional gearheads getting their hands on software-defined vehicles is an amusing thought experiment. With their socket wrenches and air compressors at the ready, they might be confused to encounter core functions more likely to run on 1s and 0s than oil and belts. But across the auto industry these days, more and more vehicles feature prominent systems built using cloud-native development, continuous integration/continuous delivery, fast digital iteration, and plenty of AI.

But there’s still a big gap to be found in many automakers’ and Tier 1 suppliers’ cloud-based development processes. On the one hand, these companies are commonly using software to develop vehicles’ digital entertainment and information screens, or other onboard high-performance computers. 

On the other, the dozens of microchips and control modules that make a car a car these days — such as gateways, body controllers, zone control units, sensor and actuator nodes — are still frequently hardwired to physical chips when they’re constructed, making them very difficult to update, reprogram, or expand after the vehicle drives off the factory floor. Teams have to wait for benches, samples, and rigs, and integration can easily slip to the end of the development process, where defects are most expensive to fix.

This inherent inefficiency has become a leading bottleneck. After all, manufacturers can’t really claim vehicles are software-defined if most of their electronics only function when connected to physical hardware and if developers are leaning heavily on actual hardware.

With Horizon, our agentic innovation platform for developing software-defined vehicles, our vision is to help manufacturers avoid these inefficiencies by working with partners like RemotiveLabs.

The cockpit already runs in the cloud

The Android team has invested a significant amount of time and effort over the last few years on enabling seamless development of the many digital systems in vehicles’ cockpits. Android Automotive OS (AAOS) runs inside Google’s official virtual testing environment for Android, Cuttlefish, which itself runs comfortably on Arm-based Google Cloud instances. With this approach, developers can build, boot, and test virtual versions of their infotainment stacks on the same Arm architecture that ships in vehicles.

And with the recent launch of Android 17 and AAOS SDV, this capability is also extended to further domains, whenever AAOS SDV is used. Deploying it with Cuttlefish, for example, proves the model: representative software, on representative architecture, in the cloud, on demand. The question that still needs to be answered is how to extend that model to the rest of the vehicle, especially when other operating systems are involved.

The harness around the virtual vehicle

That’s where RemotiveTopology comes into play. As the harness around the virtual vehicle, it’s the layer that connects AAOS in Cuttlefish to a full, simulated electrical and electronic (E/E) architecture: the rest of the vehicle’s onboard computers, its data networks, and the live signals that make the system function like a real vehicle rather than a collection of standalone apps.

RemotiveTopology automatically utilizes manufacturers’ existing network design files to build a working, virtual version of their cars’ networks. This is vehicle-as-code: the E/E architecture expressed as an executable specification, versioned and provisioned like infrastructure-as-code. In this way, an entire vehicle can be spun up on demand. Cockpit software talks to the rest of the vehicle exactly as it would in a real vehicle. As a result, developers get full and continuous signal and cross-domain visibility, so they can see real-time system status. And because it is built on standard Linux tooling, the same topology runs on a laptop and in a contiguous integration pipeline on Google Cloud.

Integrate across domains early, not late

The payoff for using this approach is that all onboard systems can be developed and integrated with software before any of them are connected to a vehicle’s hardware. That’s beneficial because the most difficult (and latest) integration in a vehicle’s development is bringing all its systems together. For example, advanced driver assistance systems (ADAS) produce object lists, trajectories, and mode requests that the cockpit has to render and react to, while the infotainment system and information cluster have to reflect driving state while body and chassis nodes sit in the loop.

With the full topology live on Google Cloud, the infotainment system and ADAS can operate simultaneously within a virtual vehicle, exchanging real signals over the simulated network. This means it’s possible to exercise handoffs like an ADAS event surfacing in the cluster or a driver-mode change rippling across domains from day one in continuous integration long before the benches and samples line up. In this way, developers can be confident they’ll discover multi-domain integration long before the end of the process so that they can test continuously from the start.

The full vehicle frontier

At the heart of this work is a shared desire to bring scalable software development to even the smallest and most common nodes in a vehicle, its microchips and control modules. That’s because these are the parts that have traditionally been wired to hardware, and as a result are the biggest blocker to fully software-defined vehicles.

The ultimate goal is that the same software that runs in the cloud can run on vehicles’ actual control modules with no re-tooling or re-validation needed to move between them. That parity is natural with Arm-based Google Cloud infrastructure because the cloud and the car share an instruction set. Google's Axion makes it straightforward: C4A metal, a bare-metal Arm instance, is provided explicitly for automotive systems development and Android software development, giving direct hardware access without unnecessary software layers and delivering the consistent performance that vehicle systems require.

Taken together, this holistic system allows teams, for the first time, to develop and integration-test an entire vehicle’s systems in the cloud and then apply it to the actual vehicle without having to rewrite it.

Why now, and where to start

The payoff is not abstract. Treating the vehicle as code and moving integration into the cloud compresses the slowest, most expensive phase of a program. Early customer engagements with RemotiveLabs have measured more than 10x faster integration cycles. And the development loop is now changing faster than the hardware loop: AI-assisted and agentic workflows can rapidly generate, test, and refine vehicle software, but only virtual systems provide the required scale. Every element that can’t be virtualized can slow the entire development process down.

RemotiveTopology provides this architecture as vehicle-as-code and makes it accessible for developers, testers, and autonomous AI agents alike. Best of all, there is no new third-party tooling to adopt just to get started. Instead, RemotiveLabs publishes an open-source simplified vehicle on GitHub that anyone can run in minutes on standard Linux tooling and platform definitions already in place. Full existing toolchains plug in as a manufacturer or Tier1 supplier scales, and RemotiveTopology can be easily dropped into an Arm-based Google Cloud environment.

For those building software-defined vehicles whose virtual development stops at the cockpit, it’s time to start with an open-source example, bring unique platform definitions, and run an entire vehicle in the cloud. RemotiveTopology is available in Horizon for easy usage in combination with other Horizon modules.

Is your LLM-as-a-judge truly objective? 

There’s a common misconception in tech that humans are subjective, so we should rely on AI for objective evaluation. But the reality is that LLMs are also subjective. Just like human reviewers, they can carry biases:

• Verbosity bias: LLM judges usually favor longer, confident-sounding answers, even when the underlying facts are wrong.
• Position bias: Swapping the order of two options can cause an LLM judge to flip its verdict over 75% of the time.
• The halo effect: Because LLMs generate text piece by piece, clean grammar and formatting can trick an AI judge into giving top marks for accuracy while missing errors.
• Agreeableness bias: LLM judges are great at recognizing valid work. But with detecting errors, they may fail to catch incorrect, buggy, or unsafe outputs up to 75% of the time.
• Self-enhancement bias: Also known as egocentric bias, AI evaluators systematically overrate outputs that were generated by themselves or from their own family.

Ultimately, LLM judges are not objective arbiters of truth. They are subjective models with their own distinct biases. Treating them as infallible tools that don't need their quality measured might leave your work compromised. 

In this post, we’ll explore what’s holding enterprises back from strong evals, and share an easy three-pillar method you can use to improve your quality. 

Three helpful ways to audit your LLM judges 

Pillar 1: Measure internal stability

Before you can trust an AI judge’s score, you need to know that it isn't just guessing. Because LLMs are probabilistic, they can be inconsistent, giving different scores to the exact same text.

You can test this internal stability by running multi-pass consistency checks on a single output and calculating the variance. If a judge's scores fluctuate wildly on identical inputs, its rubric is too ambiguous.

Pillar 2: Validate human alignment

When your evaluation datasets are mostly valid responses, a lenient AI judge can look great on paper. It might align closely with human reviewers overall, but miss a majority of invalid or even unsafe outputs.

To prove your LLM judge is catching real errors, you need chance-corrected metrics. These mathematical models filter out agreements driven purely by leniency or random chance, showing how closely your evaluator actually aligns with the informed decisions of human experts.

Pillar 3: Use multi-judge ensembles

To avoid the halo effect mentioned earlier, teams should use decomposed prompting. Instead of asking one LLM judge to score an entire response, assign a specialized judge to evaluate a single criteria, like factual accuracy or tone. This isolates traits and forces independent scoring.

Second, to track performance in real time without human intervention, the established best practice is ensembling. This means running at least two different models under the hood to evaluate the exact same output simultaneously. 

By finding the statistical consensus between these models, you can flag if their evaluations begin to diverge and avoid any scoring quality degradation.

Get started

Partner with Delta to design and implement statistically-audited evaluation pipelines for your enterprise agentic systems.