GCP News - 2026-10-06

Today, we’re announcing Google Cloud Modernize, an end-to-end transformation portfolio to help enterprises collapse multi-year roadmaps with the power of AI.

Google Cloud Modernize brings together Google Cloud’s proven migration and modernization tools, including Migration Center, Google Cloud VMware Engine, Google Cloud Mainframe Modernization and our new EKS-to-GKE Migration Agent, into a single portfolio. With it, enterprise teams now have purpose-built agentic capabilities across infrastructure assessment, platform modernization, and application modernization. 

Central to this portfolio is Modernization Hub, a newly launched in-console experience where developers and architects can analyze source code, map dependencies, and accelerate modernization for Java, .NET, and mainframe applications. 

Agentic infrastructure assessment

Every transformation begins with an accurate assessment. With new Gemini capabilities in Migration Center, the Agentic Quick Estimator (GA) converts VMware inventory exports (such as RVTools) and infrastructure inputs into total cost of ownership (TCO) projections for your Compute Engine environment.

Using an interactive chat interface, teams can test real-time modeling assumptions, such as evaluating multi-region footprints or comparing BYOL licensing against pay-as-you-go, to discover contextual cost optimizations. This condenses weeks of spreadsheet modeling into a defensible business case in minutes.

For specialized support, we also provide a comprehensive modernization assessment at no cost through our Rapid Migration & Modernization Program (RaMP).

Platform modernization

With the rise of real-time AI agents querying backend systems, workloads increasingly require high-throughput infrastructure that removes I/O bottlenecks. Once you’ve defined your target environment using our assessments, there are several new purpose-built compute options for mission-critical workloads:

• SAP S/4HANA at scale (X5 Series, GA): Delivers single-node 43 TiB memory configurations that remove the previous 29 TiB ceiling, allowing enterprise ERP estates to run without distributed partitioning overhead.

• Core-optimized database performance (M4N Series, GA): Delivers 26.57 GiB RAM per vCPU paired with Hyperdisk Extreme. This prevents organizations from overprovisioning compute cores to meet memory requirements, reducing software licensing costs by more than 20% for Oracle and other core-licensed databases.

• Ultra-low latency data engines (Z4D, GA and Z4M, Preview): Deliver up to 84,000 GiB and 168,000 GiB of high-speed local NVMe SSD respectively, 400 Gbps networking for both Z4D and Z4M, and RDMA support for Z4M. This throughput reduces I/O wait times and prevents query timeouts when real-time AI agents query vector stores, operational databases, and large-scale data pipelines.

Cloud elasticity for VMware environments

For organizations operating VMware estates that need the elasticity of the cloud but aren’t ready to re-architect their environment, the Google Cloud self-managed VMware solution provides administrative control on Bare Metal Z3 shapes with VMware Cloud Foundation (VCF) 9.1. Native global VPC links connect VMware estates directly to Compute Engine, Google Kubernetes Engine (GKE), BigQuery, and Gemini Enterprise, allowing teams to ground autonomous agents in operational data without code changes.

Automated container transitions to GKE

The new EKS-to-GKE Agentic Migration (Public Preview) automates transitions from AWS Elastic Kubernetes Service to GKE thanks to: 

• An automated pipeline: Manages discovery, Kubernetes manifest translations, storage and network mappings across clouds.

• Enterprise-grade security: Built-in Human-in-the-Loop (HITL) approval gates and in-memory credential security maintain strict GitOps compliance.

• A fast-track to modern runtimes: Quickly moves workloads to GKE to take advantage of low-latency model serving, autoscaling, and multi-agent orchestration.

NetEase Games demonstrated the value of this platform approach by containerizing services on GKE, reducing infrastructure scaling times from hours to five minutes during peak launches while cutting server costs by 40%:

"By integrating diverse computing instances and powerful orchestration, we have transformed our infrastructure into a competitive advantage, ensuring NetEase remains a leader in the global gaming market."  - Deng Ding, Director of Site Reliability Engineering, NetEase Games

Application modernization with Modernization Hub

Landing on modern infrastructure enables teams to unlock legacy business logic and modernize their core applications. Modernization Hub centralizes several modernization tools directly inside the Google Cloud console. 

.NET and Java modernization

Modernization Hub integrates the Google Cloud App Modernization CLI (CodMod), which uses Gemini to analyze large source code repositories, understand legacy application architectures,maps hidden dependencies, identifies modernization challenges and generates modernization recommendations. This enables customers to migrate legacy .NET Framework applications to modern .NET Core  running on Linux containers, reducing OS licensing overhead, while also making these applications and data accessible to modern AI agent workflows.

Mainframe modernization

For customers running mainframes, we provide specialized solutions to help accelerate and de-risk end-to-end application transformation to Google Cloud:

• Mainframe Assessment Tool: Parses legacy mainframe codebases, extracts business rules, maps application and data dependencies to generate cloud-ready target application specifications and power agentic modernization workflows.

• Dual Run: Substantially reduces cutover risk by replaying live production transaction streams simultaneously across the mainframe and the new cloud applications, verifying functional equivalence before going live. 

• Mainframe Connector: Copies mainframe data directly into Google Cloud services (BigQuery, AlloyDB, GCS and others), , unlocking legacy data and supports hybrid architectures.

Intesa Sanpaolo used Google Cloud mainframe modernization solutions to accelerate their core banking transformation off the mainframe and onto Google Cloud:

“To confidently move forward with Mainframe Modernization, we will need to provide confidence and assure the bank's leadership and internal control units as well as get approval from the regulators. One of the enablers for this is Google Cloud Dual Run, which is gradually providing the evidences to build such confidence to all three groups.” - Claudio Balbo, Head of IT Architecture, Intesa Sanpaolo

A proven track record and partner ecosystem

Deutsche Börse Group transitioned its mission-critical SAP S/4HANA environment and DAX® index calculations to Google Cloud, cutting disaster recovery times from hours to minutes, reducing aggregation latency by over 50%, and shortening development cycles from months to days.

To deliver these capabilities at enterprise scale, we are also collaborating with our global partner ecosystem to integrate Google Cloud Modernize with enterprise delivery frameworks, including Cognizant:

“Google’s modernization offering heralds the next frontier of AI-native modernization — enabling enterprises to autonomously decode legacy complexity and accelerate into cloud-first, intelligent architectures. Coupled with Cognizant's AI-led, governed delivery engine, we amplify this shift through agentic business processing, unlocking faster, outcome-driven value at scale.” - Nishant Upadhyaya, Global Practice Head – Digital Engineering, Cognizant

Accelerate your transformation now

Modernizing your infrastructure and applications is the baseline requirement for enterprise AI agility. Google Cloud Modernize equips teams to navigate each phase safely and efficiently as they pursue AI readiness and adoption.

Get started:

• Join the webinar: Register for our upcoming session on November 17 to see live demos of Modernization Hub and our agentic migration tools.

• Explore the console: Log into the Google Cloud Modernize console to access Modernization Hub.   

• Start planning: Visit the Google Cloud Modernize webpage, or request a modernization assessment at no cost today.

For modern AI and RAG applications, achieving high search relevance requires that you combine at least two techniques: vector search for semantic context, and full-text search (FTS) for keyword precision. While AlloyDB for PostgreSQL supports both of these capabilities, managing them has traditionally required a more hands-on operational approach to ensure peak performance.

The challenge is not executing the searches, but the subsequent fusion of result sets. Merging results from the vector query (distance scores) and the FTS query (relevance scores) requires complex SQL queries or custom code in the application layer. This often means maintaining a separate system for fusion, score normalization, and re-ranking.

This article details how AlloyDB AI's hybrid search eliminates this complexity. We will explore how recent updates allow you to:

• Simplify hybrid search: Consolidate complex SQL queries, or multi-step application workflows into a single, high-performance SQL function powered by Reciprocal Rank Fusion (RRF).

• Optimize FTS performance: Use the new RUM extension to achieve low-latency relevance ranking and efficient phrase matching by storing word positions directly in the index.

• Leverage industry-standard ranking: Utilize the new natively supported BM25 index for superior keyword-based scoring directly out of the box.

• Expand search versatility: Execute queries against specialized external clusters, including Elasticsearch, OpenSearch, and Solr, using the new external search Foreign Data Wrapper (FDW) without leaving the AlloyDB environment.

The problem of the multi-step workflow

Before AlloyDB AI's native solution, achieving robust hybrid search was very demanding, especially for developers trying to keep this logic within the database using standard SQL. This approach required multi-step orchestration that was not only difficult to manage and maintain for two sources, but became virtually impossible to scale as additional sources were added. These steps included:

1. Executing vector search: Run a query using a vector column or vector index (for AlloyDB this can be a ScaNN index) to find top k results, generating vector scores.

2. Executing the FTS query: Run FTS query e.g. by using a generalized inverted index, or GIN, to find top k results.

3. Normalizing scores (the brittle step): Write complex SQL logic or custom application code to map both result sets onto a common scale. This logic is prone to breaking when data distributions change.

4. Performing cross-service joins and re-rankings: Use application memory to perform a complex FULL OUTER JOIN on document IDs, apply a weighted summation of the normalized scores, and finally sort the combined results in cases where the FTS search was done in a separate system than the one used for vector search.

This decentralized approach led to fragile score logic, increased latency, high operational load, and a dependency on application expertise for maintaining search quality.

Simplifying hybrid search architectures with AlloyDB

The key to simplifying this is to adopt RRF, which, because it is inherently rank-based, cleverly bypasses the brittle step of score normalization entirely. RRF consists of two parts:

1. The single source of truth

Instead of a multi-step fetch and join process, you simply call one SQL function, providing your search components as a declarative JSON array:

SQL

(Note: The unified ai.hybrid_search API isn't limited to just two components. It also natively supports external search sources via the new FDW).

2. Database-native orchestration

The hybrid_search() function executes the entire workflow in a single query plan, minimizing overhead and helping ensure transaction consistency. It uses:

• Dynamic CTE generation: The function constructs dynamic SQL, creating Common Table Expressions (CTEs) for each component. Each CTE is responsible for calculating the positional rank (ROW_NUMBER()) of its results.

• Kernel-level fusion: All ranked component results are immediately combined using a FULL OUTER JOIN based on the document ID.

• Final RRF score: The combined ranks are used to calculate the final, unified score using the RRF formula:

By taking this approach, brittle score calculations and application-side joins become unnecessary. While Reciprocal Rank Fusion (RRF) is our current ranking algorithm, we intend to introduce additional merging and ranking options down the road.

The result: Performance and operational simplicity

Moving from complex external workflows to native SQL functions provides immediate, measurable benefits:

Enhancing FTS performance: The RUM extension

AlloyDB AI's hybrid_search() function is designed to deliver comprehensive search relevance by combining high-performance vector search with FTS. While AlloyDB's native FTS capabilities are powerful, reliance on the standard PostgreSQL GIN index for the text component can present a bottleneck for advanced operations.

The challenge with GIN indexes is that they do not store the positional information of words. This limitation forces costly table scans to re-analyze content for:

• Relevance ranking: Calculating search result scores based on word proximity and frequency

• Phrase searching: Finding exact word order, which requires positional information.

Introducing the RUM extension for low-latency FTS

The RUM extension is a powerful index access method based on GIN that directly resolves these performance issues.

• RUM's core advantage: Unlike the GIN index (which maps word -> [docID]), the RUM index stores the positional information of each word directly within the index (e.g., word -> [(docID1, [pos])], ...).

• Performance benefits: This allows RUM to perform complex operations like ranking and phrase matching predominantly within the index itself, avoiding expensive heap scans. RUM provides significantly faster relevance ranking and efficient phrase and proximity searches.

• Great for hybrid search: RUM is a critical complement to vector search (like ScaNN) within a hybrid search framework, as GIN’s potential latency makes it less suitable for a real-time hybrid approach.

The RUM extension is an excellent choice for ranking-heavy or high-concurrency search applications. By storing word positions directly in the index, RUM cuts out the need to re-scan table pages during ranking, giving you fast and sorted results. However, it comes with some trade-offs: slower index builds and a larger disk footprint. If your workload prioritizes quick queries and precise ranking over write speeds and storage density, RUM is an investment that's well worth it.

Measurable gains and integration

Adopting RUM directly bolsters the performance of FTS in AlloyDB, showing considerable gains for raw FTS queries, as well as gains on hybrid search that includes FTS queries. Below are performance statistics showing the speedup between using RUM compared to GIN on various BEIR datasets.

RUM integrates with the specialized <=> distance operator for search and ranking, which is supported for use in hybrid search SQL calls, delivering the best of both worlds. The following codelab shows how to configure and use the RUM index with the Hybrid Search UDF. 

Introducing BM25 Index: The modern ranking standard

We recently introduced the BM25 index to CloudSQL and  AlloyDB in preview, bringing the industry-standard relevance ranking via the pg_textsearch extension. BM25 uses TF-IDF, which accounts for term frequency saturation and document length normalization, delivering significantly higher precision and quality for keyword-based search queries. By leveraging native BM25 indexes within AlloyDB AI, you can achieve superior ranking accuracy out of the box, so that exact-term matches and critical keywords score well without having to implement external search engines or complex custom scoring logic.

External search: Extending versatility with foreign data wrappers

To further extend search capabilities, we also introduced the external search Foreign Data Wrapper (FDW) in AlloyDB AI. This lets you execute full-text searches against specialized external clusters, starting with Elasticsearch, OpenSearch, and Solr, and provides several key architectural advantages:

1. Optimized retrieval: Leverage ranking algorithms and a richer feature set from dedicated search backends without leaving the AlloyDB environment.

2. Unified SQL interface: Interact with external data, perform joins, and meld results using standard PostgreSQL SQL without losing the expressiveness of advanced FTS queries.

3. Strong portability: Maintain existing search infrastructure while benefiting from the simplified hybrid architecture offered by AlloyDB AI.

The following codelabs are end-to-end code guides walking through hybrid search with Elasticsearch and Solr integrations.

A unified architecture for AI-powered search

The true challenge of modern search is not technical in nature, but in achieving architectural simplicity and sustained operational stability. AlloyDB AI addresses this with a unified platform built on three core innovations:

1. Simplifying hybrid search: AlloyDB AI’s hybrid search function, powered by RRF, transforms a fragile, multi-step application workflow into a single, high-performance SQL call. This native implementation eliminates the need for complex score normalization and application-side joins, drastically lowering the operational and engineering cost while delivering consistently accurate and fast hybrid relevant results.

2. Optimizing FTS performance: To ensure the FTS component of Hybrid Search meets diverse application demands, AlloyDB AI offers distinct full-text search options. The RUM extension optimizes for low-latency performance by storing positional data directly in the index to enable faster relevance ranking and efficient phrase searches — important when you need fast query speeds. Alternatively, the BM25 index provides industry-standard relevance ranking, and is the preferred choice when prioritizing keyword scoring precision. You can select between these options depending on whether your focus is search latency or ranking precision.

3. Enhancing versatility through external search: The addition of the external search through FDW extends AlloyDB’s reach to specialized search backends like Elasticsearch. This lets you leverage the superior scale and advanced retrieval features of dedicated search clusters while maintaining a familiar PostgreSQL interface. By integrating these external results directly into the hybrid search framework, AlloyDB AI ensures that you can combine even the most massive text repositories with vector-based semantic insights.

By consolidating the complexity of scoring, joining, and re-ranking within the database kernel, and offering a dual-path approach to FTS — leveraging RUM for optimized, low-latency, internal FTS or external search for specialized, scalable backends — AlloyDB AI delivers a robust and self-contained search foundation. This coexistence is essential to the overall hybrid search story, providing the flexibility to choose the optimal path based on workload, data volume, and existing infrastructure. Now, you can focus on building intelligent application features, confident that your search architecture is both highly performant and easy to maintain.

Watch it in action

Watch how AlloyDB is the ultimate hybrid search engine.

Learn about BM25 support in AlloyDB. 

Getting started 

Ready to bring more speed and cost-efficiency to your AI workloads?

• New to AlloyDB? Discover AlloyDB with a 30-day free trial.

• Getting started with hybrid search: Set up a text-search index and select a vector search index. Once these are created, you can find some examples to perform various hybrid search queries.

• External search: Create a foreign data wrapper and foreign table in AlloyDB to query external data from Elasticsearch, Solr, or OpenSearch.

Enterprises and individual developers frequently run multiple AI inference models. The right architecture can simplify how the models are called while also providing centralized governance. In this post, we'll look at two reference architectures focused on networking AI inference model serving: one for Google Kubernetes Engine (GKE) and one all other backend types. First, we'll explore the commonalities between the reference architectures that you'll see later. Then we'll explore unique components of the architecture for GKE backends and finally, we'll go over the elements of the architecture for all backend types.

The entry point

You can expose your model deployment behind a stable, secure, and reliable entry point that acts as the front end for inference calls. This entry point also acts as a control zone where policy, security, and logic can be enforced. Both the Cloud Load balancer and the Inference Gateway provide entry point capability. These types of endpoints can terminate secure connections with TLS, integrate with API management components, extend functionally with service extensions, and capitalize on capabilities of Model Armor for added security.  

Common services in the designs 

Both reference designs use these services:

• Private Service Connect inference endpoint: Anchors the entry point inside your consumer Virtual Private Cloud (VPC) network. Traffic hits a private internal IP address, keeping inference calls in your private network.

• Apigee API Management (Optional): Integrates via an Apigee Extension Processor callout to handle client identity verification, rate limits, and quota enforcement before requests ever reach compute resources.

• Model Armor: Serves as an inline AI safety checkpoint, screening prompts and output completions against prompt injection and sensitive data leakage.

Design pattern serving on GKE only

This section focuses on a GKE-only backend design. To understand the full end-to-end concept, please read the entire architecture document Networking for AI inference model serving on GKE. The design pattern is based on this diagram:

In addition to the common services identified in the previous section, the design for GKE uses these components:

• GKE Inference Gateway: Deployed as an internal Application Load Balancer (gke-l7-rilb). It acts as a specialized ingress engine that parses incoming request payloads, evaluates HTTPRoute rules, and steers queries to appropriate model-serving targets.

• Inference pools: A logical group containing replicas of the same model. When the Gateway receives a prompt, it evaluates HTTPRoute rules to select the appropriate inference pool based on the model identifier. Pools have an initial size and can be configured to autoscale dynamically.

• Model replica sets: Individual model replicas (inference server instances) deployed across single-node or multi-node GPU or TPU node pools. A replica set represents a uniform group of these model replicas.

The traffic flow GKE example

A client application that uses this GKE-based architecture to call a backend model would go through a flow like this:

• Ingress: A client application in the consumer VPC issues an OpenAI-compatible API call to the local Private Service Connect endpoint, routing directly to the GKE Inference gateway using a regional internal Application Load Balancer.

• Payload inspection: The Gateway reads the target model parameter specified in the request body and adds it to the HTTP headers.

• Control plane validation: If Apigee is used, it checks client credentials and quotas. Model Armor screens the prompt for policy violations or data leakage.

• Backend selection: The Gateway evaluates HTTPRoute mappings to identify the target pool, matches shared prefix cache context, and routes to the lowest-load GPU or TPU replica based on real-time Prometheus data.

• Egress: The replica runs the inference workload. Output tokens pass through Model Armor for final response verification before streaming back over the private connection.

Design pattern serving on all backends

This section focuses on multiple backend types which can be used for inference, and it provides an overview of the architecture in the following diagram. To understand the full end-to-end concept, please read the entire architecture document Networking for AI inference model serving on all backends.

For architectures spanning mixed environments such as GKE, Cloud Run, Agent Platform, on-premises data centers, or external clouds, these additional components are used:

• Regional internal Application Load Balancer: Serves as the central Layer 7 routing proxy that manages routing logic, SSL termination, and Service Extensions callouts.

• Inference Payload Processor (Service Extensions): This is similar to body-based routing as used in the GKE Inference Gateway, but to enable the functionality on an Application Load Balancer a service extension is needed. A lightweight Cloud Run callout inspects the JSON body of incoming OpenAI API requests, extracts the target model identifier, and writes an X-Gateway-Model-Name header to drive URL map routing.

• Network Endpoint Group (NEG): Delivers flexible routing to heterogeneous backends based on the injected model header.

All-backends traffic flow example

A client application that uses this architecture to call a backend model would go through a flow like this:

1. Private ingress: The client application targets the Private Service Connect endpoint over private IP address space. The regional internal Application Load Balancer receives the request.

2. Model name extraction: The load balancer sends the payload to the Cloud Run body-based router callout, which inspects the JSON payload and injects the X-Gateway-Model-Name header.

3. Policy and safety enforcement: The request passes to Apigee for identity and quota validation, then to Model Armor to scrub sensitive data and block malicious prompts.

4. NEG routing: The load balancer URL map inspects the model header and forwards the request to the matching backend NEG (Agent Platform, GKE, Cloud Run, Hybrid, or Internet).

5. Private delivery: The target backend executes the model prompt, Model Armor screens the completion, and the result returns privately along the ingress path.

What's next

Take a deeper dive into building AI workloads on Google Cloud:

• Document set: Agentic AI architecture guides

• Architecture Center: Multi-agent private networking patterns in Google Cloud

• Document: Gemini Enterprise Agent Platform networking access overview

Want to ask a question, find out more, or share a thought? Please connect with me on Linkedin. 

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

このたび、Google Compute Engine の次世代 Z4D ストレージ最適化マシンシリーズの一般提供が始まりました。仮想マシン（VM）インスタンスとベアメタル インスタンスの両方でご利用いただけます。

Z4D は、I/O 負荷の高い、ビジネス クリティカルなワークロードを想定して構築されたマシンシリーズであり、SQL、NoSQL、KVrocks、ベクトル データベース、データ分析、データ検索といった用途で大容量のローカル ストレージおよび高いストレージ パフォーマンスが必要な場合に適しています。AMD の第 5 世代の EPYC プロセッサ（Turin）を搭載し、Titanium の最新機能を組み合わせることで、最大 84,000 GiB のローカル SSD（LSSD）ストレージをサポートしています。前世代の Z3 インスタンスと比較して、パフォーマンスが最大 40% 向上しているため、特に要求の厳しいワークロードにおいて高い効果を発揮し、アプリケーションのスループット向上およびクラウド費用の最適化をもたらします。さらに、Z4D は大容量 LSSD を提供しているという点が大きな特徴であり、AI / ML のトレーニングおよび推論や、大規模な分散並列ファイル システムの実行といった用途に最適なストレージ ソリューションとなっています。

Z4D の VM インスタンスとベアメタル インスタンス

Z4D の VM ポートフォリオでは、大容量のローカル SSD および高密度の SSD（vCPU ごと）が提供されており、これらを使って、ワークロード要件に適したインフラストラクチャをサイジングし、クラスタをスケールできます。Z4D には 2 種類の VM タイプがあります。Z4D-highmem-standardlssd タイプは、7 種類の VM シェイプがあり、vCPU あたり 219 GiB の LSSD を提供します。これらの VM は、データ分析（OLAP）や SQL データベース（MySQL や Postgres など）向けに最適化されています。一方、Z4D-highmem-highlssd タイプは、 7 種類の VM シェイプがあり、vCPU あたり 438 GiB の LSSD を提供します。このタイプは、分散データベース、データ ストリーミング、大規模な並列ファイル システム、データ検索といった用途向けに最適化されています。さらに、Z3 ベースの既存のワークロードがある場合は、Z4D を含むクラスタに拡張することによって、簡単にスケールできます。

Z4D ベアメタル インスタンスでは、仮想化レイヤを介さずに物理ハードウェアに直接アクセスできます。これによりレイテンシが短縮されるため、レイテンシの影響を受けやすいワークロードや、カスタム ハイパーバイザ、一定のライセンス要件があるワークロードに適しています。さらに、Z4D ベアメタルは、AMD ベースのインスタンスとして初めて、複数のクラウド プロバイダにまたがるハイブリッド マルチクラウド プラットフォームである Nutanix Cloud Clusters（NC2）をサポートしています。また、Z4D ベアメタル インスタンスの大容量 LSSD および低レイテンシという特徴は、エージェント型 AI アーキテクチャにおいてマイクロ VM を使用するような場合にも最適です。たとえば、単一ホスト内で数千単位の分離サンドボックスを実行するような場合でも、ネイティブのパフォーマンスと効率を維持できます。

Z4D の VM インスタンスとベアメタル インスタンスは、84,000 GiB のローカル SSD ストレージに加え、最大 384 個の vCPU、最大 3,072 GiB のメモリを提供しています。Z4D インスタンスは Titanium SSD を基盤としており、ローカル ストレージの処理を CPU リソースからオフロードすることによって、リアルタイムのデータ処理、低レイテンシ、高スループットのストレージ パフォーマンスを実現してます。それと同時に、ストレージ セキュリティも強化されています。また、Z4D は最大 15,600K のランダム読み取り IOPS と、最大 75,600 MiB/秒のシーケンシャル読み取りスループットを提供しており、LSSD ストレージのパフォーマンスが Z3 と比べて最大 70% 向上します。さらに、書き込みレイテンシが Z3 と比較して最大 25% 短縮され、読み取り / 書き込み混在の IOPS が最大 30% 向上していますが、Z3 に比べて IO レイテンシは増加していません。また、ネットワーク スループットは Z3 と比べて 2 倍、標準ネットワーク帯域幅は最大 400 Gbps となっており、エンタープライズ ワークロードや AI / ML ワークロードに求められる接続性とストレージ パフォーマンスを提供します。

お客様とパートナー様の声

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

強化学習（RL）は、最新の LLM の事後学習の重要な要素となっていますが、大規模なトレーニング クラスタと、Gemini のような独自モデルでは外部の顧客がアクセスできないモデル内部へのアクセスを必要とします。そこで、Google Cloud は、これをマネージド RL ファインチューニング サービス（RLFT サービス） としてパッケージ化しました。お客様はプロンプトと報酬関数を用意するだけで、インフラストラクチャと独自モデルの内部は Google が処理します。

このサービスを使用すると、固定されたラベル付き回答セットではなく、定義した報酬シグナルに基づいてモデルに学習させることで、Gemini をサービスに適応させることができます。これにより、教師ありファインチューニング（SFT）では対応が難しい問題、つまり、実証は難しいものの、スコア付けは容易なタスクを解決できるようになります。

このガイドでは、RL ファインチューニング サービスを使用するための実践的なベスト プラクティスについて説明します。まず、RL トレーニング ループの概要、RL を使用するかどうか、いつ使用するかを判断する方法、このアプローチから最大限の価値を引き出す方法について説明します。

RLFT とは

RLFT は、ラベル付きの回答ではなく、定義した報酬シグナルに基づいて Gemini を調整します。大量のゴールド サンプルを作成する代わりに、回答をスコア付けするプログラムを 1 つ作成し、サービスがそれに基づいてモデルを改善します。これにより、実証は難しいが検証は容易なタスクを解決できるようになります。たとえば、すべてのスキーマに対して理想的な SQL を手動で記述することはできませんが、クエリを実行して結果を確認することはできます。

各トレーニング ステップで、サービスはプロンプトに対して複数の回答候補を生成し、報酬でスコアを付け、元の Gemini に近い状態を維持しながら、スコアの高い回答が生成される可能性が高くなるようにモデルを改善します。これを可能にする強化学習はフルマネージドであるため、構成する必要はありません。あなたがコントロールし、結果を最も左右するものは、報酬です。

RLFT でできることとできないことは、次の 3 つの特性で定義されます。

1. モデル自体の出力から学習する: 外部のターゲットをコピーするのではなく、モデルがすでに生成したものを改良するため、SFT よりも無関係な機能を損なう可能性が低くなります。

2. 経路ではなく結果に報酬を与える: 良い結果に到達した回答には報酬が与えられます。これは、有効な解決策が多数ある自由回答形式のタスクに適しています。

3. 既存の能力を増幅する: たまにしか起きない成功を確実に再現できるようにしますが、モデルが一度も実証したことのないスキルを教えることはできません。

RLFT を使用する状況

プロンプトと SFT でほとんどの適応に対処できるため、まずはこれらを試してください。RLFT がその価値を発揮するのは、回答を評価できるが、安価に作成できない場合、重要な指標（忠実性、スキーマの有効性、トーン）で SFT が頭打ちになった場合、またはタスクに等しく有効な回答が多数あり、単一の参照ターゲットでは誤ってペナルティが課される場合です。

SFT と RLFT は競合するものではなく、補完的なものです。

• 直接 RLFT: ベースモデルがすでに時々成功している場合（報酬によってより良い回答とより悪い回答が区別される程度）。

• SFT → RLFT の 2 段階: SFT データがある場合、またはベースの成功率が低すぎて RL が軌道に乗らない場合。SFT を短時間の安価なウォーム スタートとして使用します。デモンストレーションを過学習させると RL による改善の余地が少なくなるため、SFT は軽めにとどめておきます。その後、SFT チェックポイントから RL を初期化する継続的チューニングを介して RL に移行します。

先行ユーザーの間では、これらのパターンは RLFT が最も価値を発揮する領域であることが示されています。いずれのパターンでも、企業が重視するものの、安価に実証できなかった成果を RLFT でスコア付けしています。

RLFT のユースケース

ゲーム内の AI を活用した NPC

• 内容: 多言語対応でマルチターンの長い会話で、キャラクターやブランドにふさわしい対話が展開される。

• 問題: 既製のモデルでは、言語の誤り、ハルシネーションにより生じたアイテム、プレーヤーの無視、繰り返しのループなどにより、没入感が損なわれる。

• 目標と報酬: Gemini 自動評価ツール（LLM-as-a-judge）が、ペルソナ、フロー、ゲーム状態のシンタックスに基づいて各ターンをスコア付けし、形式や言語のエラーにペナルティを課す。

• 結果: ループと言語のドリフトが解消され、状態のシンタックスが維持されたことで、ゲーム内のキャラクターを大規模にリリースすることが現実的なものになりました。

構造化されたエンティティの抽出

• 内容: サプライヤーの請求書や出荷明細書などの非構造化ドキュメントから一連の項目を抽出し、構造化レコードに自動的に変換する。

• 問題: SFT が頭打ちになるロングテール。必要なフィールドが見落とされている（再現率）か、存在しないフィールドが捏造されている（適合率）。

• 目標と報酬: ルールベースの適合率 / 再現率の報酬を使用して、各フィールドがソーステキストにグラウンディングされるようにして、1 つの正解から模倣されないようにする。

• 結果: チューニングが停滞していたノイズの多い実社会のドキュメントに対して、フィールド レベルの精度が向上し、手動によるレビュー手順を自動化できました。

コンテンツ管理

• 内容: 複雑なポリシーとディシジョン ツリーを大規模に適用する。

• 問題: モデルのハルシネーションによる偽陽性や、無効な形式で評価を避けようとする報酬ハッキング。

• 目標と報酬: Cloud Run の報酬を使用して、形式の検証と決定論的な採点ツールを組み合わせて、複数ステップのポリシー遵守を強制する。

• 結果: モデルが複雑な免除措置を処理し、偽陽性を大幅に削減し、報酬ハッキングを阻止したことで、管理費用を増加させる人間へのエスカレーションの量が減少しました。

実行によって測定されるコード

• 内容: 顧客データに対して実際に実行されるかどうかに基づいて評価される SQL または API 呼び出し。

• 問題: SFT が 1 つの参照クエリを模倣し、未知の独自スキーマに対して機能しない。

• 目的と報酬: コード実行の報酬を使用して、安全なサンドボックスでコードを実行し、コンパイル、実行を経て、正しい結果が返された場合にのみ報酬を与える。

• 結果: モデルは、クローズド フロンティア品質の実行可能なクエリを最初の試行で生成し、推論コストを削減しました。これにより、技術者以外のユーザーも自然言語で独自のデータをクエリできるようになりました。

HTML によるプレゼンテーション スライドの生成

• 内容: HTML / CSS で作成された複数スライドの資料。

• 問題: テキストのみでトレーニングすると、視覚的な品質が無視されるため、オーバーフロー、要素のクリッピング、一貫性のないスタイル設定などが見過ごされる。

• 目標と報酬: コード実行の報酬を使用して、スライドをレンダリングし、ビジュアル デザイン、レイアウトの整合性、構造の完全性、評価基準の遵守をスコア付けする。

• 結果: モデルは、テーマに一貫性があり、レイアウトのオーバーフローがない、モジュール化された、適切なスタイルのスライドを出力しました。

どこから始めるべきか

• データセット。最初の実行には、検証用として取り分けたデータを含む、多様なプロンプトのセットで十分です。ループが収束し、報酬が期待どおりに推移していることを確認してから、スケールします。トレーニングと評価は厳密に分けるようにしてください。評価が汚染されると、過学習が見落とされてしまいます。

• 報酬関数。コードまたは構成としてのタスク仕様であり、品質を左右する重要な要因。優れた報酬は、人間の好みに相関し、不正な出力に対して堅牢であり（解析の失敗をキャッチし、クラッシュすることなく、明確に否定的なスコアを返します）、報酬ハッキングに耐性があります。具体的には、複数の評価を組み合わせ、長さへのペナルティを課し、異常な出力への下限を設定し、モデルの意見よりも検証可能なチェックを優先します。リリース前にオフラインで検証してください。

残りはサービスが処理します。デフォルト設定から開始し、コンソールで報酬と評価の曲線を確認して、最後の段階ではなく、検証報酬が頭打ちになった時点のチェックポイントを使用します。

使ってみる

あなたは何を構築しますか？そのために必要なツールがここにあります。

• ドキュメント: 強化学習ファインチューニング

- Google、シニア ソフトウェア エンジニア、Jiaqi Pan

- Google、シニア プロダクト マネージャー、Kunal Jha