# PHPの重大脆弱性とLiteLLMの不正配布に対応

> PHPの重大脆弱性の修正版と、LiteLLM 1.107.0の不正配布への対応を確認する。Claude Duetの米国限定プレビュー、Google Cloud経由のOpenAI利用、createAIへの移行、Confidential G4の導入条件を整理し、FlintとTorchTitanの更新も追う。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261022
Published: 2026-10-22T06:30:00+09:00
Category: ai-digest
Tags: safety, ai-agent, anthropic, openai, enterprise-ai, cloudflare, infrastructure, nvidia, open-source

PHPの重大脆弱性は修正版への更新と再配備を、LiteLLMの不正配布は実行環境の調査と認証情報の失効・再発行を先に確認したい。新規導入では、Claude Duetの米国向け研究プレビュー、Google Cloud経由のOpenAIモデル利用、CloudflareのcreateAIへの移行、Confidential G4の構成条件を取り上げる。短報ではFlint、A5X、TorchTitanを追う。

これらは独立した更新だ。PHPは既存ランタイムの脆弱性、LiteLLMは配布物に混入した悪意のあるコードへの対応であり、同じ「更新」でも必要な作業が異なる。導入候補は、今使える機能と今後の予定、実行を任せる範囲と人の承認を分けて読む。（[PHPの更新案内](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/) / [LiteLLMの事故報告](https://docs.litellm.ai/blog/security-incident-oct-21-2026) / [Claude Duetの発表](https://claude.com/resources/articles/claude-duet) / [Google Cloudの発表](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/)）

## PHPの重大脆弱性、Google Cloud上の更新対応は実行環境で分岐

Google Cloudによると、PHPとWiz Researchが公開したコアPHPランタイムの脆弱性は、認証不要のリモートコード実行やメモリ情報の漏えいにつながり得る。Google Cloudの基盤自体は脆弱ではないが、その上でPHPを動かすアプリケーションは影響を受け得るため、修正版への更新と再デプロイが案内されている。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)）

Google Cloudの説明では、CVE-2026-109618は、メモリ不足によって初期化が中断されたリクエストデータを、後処理が有効と扱う問題。CVE-2026-109619は、メモリ解放後も内部状態が残り、同じワーカーが処理する後続リクエストで、通常の初期化によるリセット前に使われる問題だ。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)）

Wizは、Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを調査に使ったと説明している。OpenAIも、CalifがGPT-5.6 Solで重大な欠陥を特定し、Wizが独立に両脆弱性を発見・報告したと発表した。修正とリリースの主体はPHPのメンテナーであり、モデルによる発見と修正済み環境への切り替えは別の工程となる。（[Wizの調査](https://www.wiz.io/blog/php2shell-php-rce) / [OpenAIの協調開示報告](https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/)）

修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12。両脆弱性のCVSS v4基本値は9.2で、Criticalとされる。Google CloudはPHP 5.4以降の旧版に影響すると説明しており、サポート終了済みの8.1以前にはPHPプロジェクトから修正を提供しない。単に「8.2以降」へ移るのではなく、利用する系列の修正版へ更新する必要がある。（[PHPのOOM処理に関するアドバイザリー](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) / [PHPの状態初期化に関するアドバイザリー](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) / [Google Cloudの更新案内](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)）

独自コンテナイメージをCloud RunやApp Engine flexibleへ配備している場合は、修正版PHPで再ビルドし、再デプロイする。GKEも修正版PHPを含むイメージへの更新とPodの再デプロイが必要だ。PHPを含むGoogle Cloud Marketplaceソリューションでは、提供元の更新を適用するか、PHPを直接更新する。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)）

監視・監査については、Artifact Analysis利用者向けに影響を受けるイメージの特定を、Security Command Center利用者向けにGKEとCloud Runの脅威検出を案内している。これらは対象の特定や侵入の監視を担い、脆弱性そのものの解消にはアプリケーションへのパッチ適用が必要とされている。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)）

**比較表: 実行環境ごとの自動更新と手動対応**

自動更新は対象ランタイムや設定に依存する。サポート対象外のランタイムには修正が提供されない。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)）

| 観点 | 自動更新される条件 | 手動対応が必要な条件と作業 |
| --- | --- | --- |
| App Engine | standardのPHP 8.2以降は自動更新され、操作不要。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)） | flexibleは再デプロイが必要。カスタムランタイムはPHP依存関係を修正版に更新して再デプロイ。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)） |
| Cloud Run | PHP 8.2以降で、ベースイメージの自動更新が有効なら自動更新。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)） | ベースイメージの自動更新が無効なら、再ビルドと再デプロイが必要。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)） |
| Cloud Run functions | PHP 8.2以降のfunctionsは、ベースイメージの自動更新を有効にしている場合に自動更新される。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)） | ベースイメージの自動更新が無効なら、再デプロイが必要。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)） |

**EastBraverの見立て:** 対応の分岐点は、サービス名だけでなく、PHPのサポート状況と更新方式にある。自動更新に任せられる範囲と、利用者が再ビルド・再デプロイする範囲を分けて捉える必要がある。（[出典1](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)）

- 出典: [PHP](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) / [PHP](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)（公式セキュリティアドバイザリー、原文日付2026-10-21） / [Wiz](https://www.wiz.io/blog/php2shell-php-rce)（調査原文、2026-10-21 22:59 JST） / [Google Cloud](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/)（公式対応案内、2026-10-22 06:14 JST）

## LiteLLM 1.107.0の配布物に不正コード、更新だけでは認証情報を守れない

LiteLLMは、10月21日にリリース経路が侵害され、PyPIの`litellm==1.107.0`とコンテナ配布物に、認証情報を盗むコードと遠隔コード実行用の仕組みが混入したと公表した。公式GitHubの`v1.107.0`ソースタグには不正ファイルがなく、攻撃者が管理するリポジトリから配布物が作られたという。ソースタグの確認だけでは、実際に取得した配布物の安全性を判断できない。（[LiteLLMの事故報告](https://docs.litellm.ai/blog/security-incident-oct-21-2026)）

公式報告の時刻をJSTへ換算すると、PyPIの不正なwheelは10月21日20:39から22:23まで配布された。Docker Hubの`v1.107.0`、`latest`、`main-latest`、`main-stable`は20:46から23:20まで影響を受け、GHCRの対象タグは22:51までに取得不能となった。非公開の企業向けレジストリは影響を受けていないと同社は説明している。（[LiteLLMの対象配布物と時系列](https://docs.litellm.ai/blog/security-incident-oct-21-2026)）

Wizの解析でも、Python起動時に読み込まれる`cook.pth`と`sitecustomize.py`などを通じた不正処理を確認している。窃取対象にはクラウド認証情報、LLM提供元のAPIキー、ブラウザーの認証情報、LiteLLM Proxyのデータベースに保存された提供元キーが含まれる。（[Wizの解析](https://www.wiz.io/blog/litellm-compromised-steals-credentials)）

> [!CAUTION] 影響環境でpipを先に起動しない
> LiteLLMは、`pip`を含むPythonの起動が不正コードを再実行すると警告している。対象ファイルと常駐プロセスを処理し、クリーンな環境・イメージを再構築する手順を公式報告で確認する。暫定的な固定先は`1.106.2`などの明示した旧版であり、外向き通信が可能なホストに不正版を導入した場合は、窃取が成功した前提で到達可能だった認証情報を失効・再発行する。（[公式の対処手順](https://docs.litellm.ai/blog/security-incident-oct-21-2026)）

**EastBraverの見立て:** パッケージを旧版へ戻すだけでは、既に持ち出されたキーへの対処は終わらない。[AIサプライチェーンの構成記録](/guides/ai-bom)から、実際に動いたバージョンとイメージのダイジェストを特定し、その環境が読めた秘密情報まで調査範囲を広げる必要がある。（[LiteLLMの事故報告](https://docs.litellm.ai/blog/security-incident-oct-21-2026)）

- 出典: [LiteLLM](https://docs.litellm.ai/blog/security-incident-oct-21-2026)（公式事故報告、原文の最終更新2026-10-22 01:00 JST） / [Wiz](https://www.wiz.io/blog/litellm-compromised-steals-credentials)（独立した解析、初出2026-10-21 22:44 JST）

## Claude Duet、米国のPro・Max利用者向けに研究プレビュー

Anthropicは、Claudeが利用者へ必要な作業を知らせ、依頼後もバックグラウンドで処理を続けるClaude Duetを発表した。対象はまず米国のPro・Max利用者で、待機リストへの登録が必要となる。iOS、Androidの独立アプリとWebで提供し、研究プレビュー中は既存プランに含まれるが、Claudeの他の機能と利用上限を共有する。（[Anthropicの発表](https://claude.com/resources/articles/claude-duet)）

Claudeアカウントのメモリ、スキル、接続アプリを引き継ぎ、ブラウザー付きの仮想マシンで作業するため、利用者の端末を起動し続ける必要はない。接続先は数時間ごとに確認し、この確認も利用上限に計上される。常時監視のサービスとして読むと、確認頻度と費用負担を取り違える。（[Anthropicの仕組みの説明](https://claude.com/resources/articles/claude-duet)）

送信、支払い、文書への署名、削除の前には、実行内容を示して[利用者の承認](/guides/human-in-the-loop)を待つとAnthropicは説明する。証券取引や口座間の資金移動は承認があっても実行しない。これらは提供元が示す制御であり、独立した安全性検証の結果ではない。（[Anthropicの操作制限](https://claude.com/resources/articles/claude-duet)）

> [!CAUTION] 初期版の判断と可視性には制約
> Anthropicは、会話の読み違いや緊急度の判断ミスが残り、現時点ではDuetのブラウザーを利用者に表示できないとしている。日本向け提供開始の発表ではない。（[研究プレビューの条件](https://claude.com/resources/articles/claude-duet)）

**EastBraverの見立て:** 導入判断は、自律的に作業を続ける能力だけでなく、接続する[アカウントの権限](/guides/ai-identity-authorization)、承認時に確認できる情報、バックグラウンド処理が消費する利用枠を組み合わせて行いたい。（[Anthropicの発表](https://claude.com/resources/articles/claude-duet)）

- 出典: [Anthropic](https://claude.com/resources/articles/claude-duet)（公式発表、原文日付2026-10-21） / [The Verge](https://www.theverge.com/ai-artificial-intelligence/1015843/anthropic-claude-duet-ai-agent)（同発表の二次報道、2026-10-22 04:53 JST）

## Google Cloud、OpenAIモデルを限定プレビューで提供開始

Google Cloudは、GPT-6 Astra、GPT-6.1 Sol、GPT-6 LunaをModel Gardenで、一部の企業顧客向けの限定プレビューとして順次提供開始すると発表した。同社によると、Google Cloudの[API](/guides/llm-api)経由で利用でき、ローカルのCodex CLIとDesktopのワークフローをGeminiプラットフォームへ直接接続して推論を実行できる。（[出典1](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/)）

調達と請求もGoogle Cloudにまとまる。OpenAIモデルの取引はGoogle Cloud Marketplaceを通じて行われ、利用分はGoogle Cloudの請求書に計上される。既存のクラウド利用コミットメントを消化でき、モデル提供元をまたぐFlexible Savings Plansの対象にもなる。Google Cloudは、同社プラットフォーム上で性能、遅延、費用効率に応じてモデルを選択・切り替えでき、提供元ごとの別契約は不要と説明している。（[出典1](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/)）

データの扱いについて、Google Cloudは、OpenAIモデルが専用のGoogle Cloudインフラで稼働し、問い合わせは隔離されたゲートウェイを通ると説明している。顧客のコンテキストと出力は指定されたデータ境界内に保持され、基盤モデルの学習には使われないとしている。（[出典1](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/)）

ただし、Zero Data Retentionの選択肢とConfidential Computeは今後の提供予定だ。Gemini for businessとGoogle AntigravityでのOpenAIモデル提供も、今回の提供開始には含まれず、今後の予定とされている。（[出典1](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/)）

> [!CAUTION] 確認できていない点
> Google Cloudの発表では、利用地域、顧客選定の詳細、料金、Zero Data Retentionなどの提供日は示されていない。OpenAIは一般提供を今後数週間以内の予定としているが、確定日は示していない。Google Cloudの関心登録フォームも、登録によるアクセスを保証しないと明記している。（[Google Cloudの発表](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/) / [OpenAIの発表](https://openai.com/index/openai-models-google-cloud/) / [登録フォーム](https://cloud.google.com/resources/interest/openai-models)）

**EastBraverの見立て:** 既存のクラウド利用コミットメントを持つ企業には、OpenAIモデルの採用をGoogle Cloudの調達・請求に組み込める点が判断材料になる。一方、Zero Data Retentionが必須の用途では、今後の提供予定であることが導入時期を左右する。（[出典1](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/)）

- 出典: [Google Cloud](https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-brings-openai-models-to-customers/)（公式発表、原文日付2026-10-22） / [OpenAI](https://openai.com/index/openai-models-google-cloud/)（公式発表、原文日付2026-10-21）

## Cloudflare、旧プロバイダーを非推奨化しcreateAIへの移行を案内

Cloudflareは10月21日の変更履歴で、`workers-ai-provider`と`ai-gateway-provider`の機能追加を凍結し、非推奨としてcreateAIへの移行を案内した。createAIはWorkers AI、AI Gatewayのカタログモデル、動的ルート、ベンダーのモデルを共通の関数で扱い、AI SDKとPi AIに対応する。関数自体は以前から存在しており、今回の新たな点は旧パッケージの非推奨化と移行案内だ。（[Cloudflareの変更履歴](https://developers.cloudflare.com/changelog/post/2026-10-21-createai/) / [導入済みのagents 0.25.0](https://github.com/cloudflare/agents/releases/tag/agents%400.25.0)）

AI SDK向けでは、createAIを`agents/models/ai-sdk`からインポートする。`createWorkersAI({ binding })`は`createAI({ binding })`へ置き換える。アカウント認証を使うコードは、`createWorkersAI({ accountId, apiKey })`から`createAI({ accountId, apiToken })`へ変わり、引数名の変更も必要になる。`createAiGateway(...)`も`createAI(...)`へ置き換え、モデルのリストには`fallback`を使う。AI Searchは別の移行先となり、`workers-ai-provider`の`createAISearch`から`ai-search-provider`の`createAISearchNamespace`へ移る。（[出典1](https://developers.cloudflare.com/changelog/post/2026-10-21-createai/)）

AI SDK向けcreateAIでカタログIDを渡す場合、ベンダーのパッケージやキーは不要で、IDはカタログ側の表記を使う。一方、ベンダーのモデルオブジェクトを渡す場合は、そのベンダーのAI SDKプロバイダーを追加し、ベンダー側のモデルIDを使う。指定方法によって、必要な依存関係とIDの表記が異なる。（[出典1](https://developers.cloudflare.com/agents/models/ai-sdk/)）

`agents/models/ai-sdk`の導入コマンドは`npm i agents ai @ai-sdk/provider`。必要な依存バージョンは`ai@^7`と`@ai-sdk/provider@^4`で、いずれもagentsの任意のピア依存関係となる。上記の`accountId`・`apiToken`による認証とカタログIDの新しい経路は、agents 0.29.0で追加済みだ。（[公式ドキュメント](https://developers.cloudflare.com/agents/models/ai-sdk/) / [agents 0.29.0のリリース](https://github.com/cloudflare/agents/releases/tag/agents%400.29.0)）

> [!CAUTION] AI SDK向けプロバイダーはベータ
> 公式ドキュメントは、マイナーリリースでもAPIが変わり得ると明記している。既存の呼び出し方と依存バージョンを照合して移行する。（[公式の提供状態](https://developers.cloudflare.com/agents/models/ai-sdk/)）

**EastBraverの見立て:** 移行は関数名の置換だけでは完結しない。認証引数の変更、モデル一覧へのfallbackの適用、AI Searchの別パッケージへの移行を含むため、利用している呼び出し方ごとに変更範囲を判断する必要がある。（[出典1](https://developers.cloudflare.com/changelog/post/2026-10-21-createai/)）

- 出典: [Cloudflare](https://developers.cloudflare.com/changelog/post/2026-10-21-createai/)（公式変更履歴、原文日付2026-10-21。時刻は未公表）

## Google Cloud、Confidential G4を36ゾーンで正式提供

Google Cloudは、NVIDIA RTX PRO 6000 Blackwell Server edition GPUを搭載するConfidential G4を、プレビューから正式提供へ移行した。Compute Engine VMとGKEノードで、36ゾーンに対応する。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/confidential-g4-gpus-are-ga/)）

保護対象は、計算処理中のデータとモデルパラメータだ。Google Cloudによると、ハードウェアで強制される実行環境内で暗号化し、ホスト管理者、ハイパーバイザー、クラウド事業者によるアクセスから保護する。さらに、ハードウェアを信頼の起点とするリモートアテステーションで、機密データの提供と処理の実行前に、コード、プラットフォーム構成、環境の完全性を検証できるとしている。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/confidential-g4-gpus-are-ga/)）

GPUを接続したG4のConfidential VMには、アジア、欧州、米国の対応ゾーンがある。例として、アジアはasia-east1-aやasia-southeast1-a、欧州はeurope-north1-aやeurope-west1-c、米国はus-central1-dやus-east1-bが対象となる。（[出典1](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations)）

Google Cloudは、標準のUbuntu OSイメージ、NVIDIAドライバー、NVIDIA CUDA-Xライブラリを使い、アプリケーション変更やカスタムビルドなしで導入できるとしている。ただし、対応するG4のマシンタイプは`g4-standard-48`で、AMD SEVとNVIDIA Confidential Computingを組み合わせる。対応するゾーンとOSを選び、新しいConfidential VMを作成する必要があり、既存VMからの変換はできない。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/confidential-g4-gpus-are-ga/) / [出典2](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations)）

構成にも制約がある。Confidential VMのディスクはNVMeインターフェースが必須で、SCSIには対応しない。NVIDIA Confidential ComputingのVMでは、複数ノードのワークロード用クラスタの作成とHyperdisk Extremeもサポートされない。（[出典1](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations)）

ドライバーとクォータも導入条件に含まれる。公式手順はNVIDIAのオープンカーネルモジュールドライバー580以降を推奨し、Linux Kernel Crypto APIと永続モードの有効化後に再起動するよう案内している。G4の通常インスタンスは`GPU_FAMILY:NVIDIA_RTX_PRO_6000`、SpotとFlex-startは`PREEMPTIBLE_NVIDIA_RTX_PRO_6000_GPUS`のクォータを消費する。GPU種別、地域、調達方式に対応する枠を確認したい。（[GPU付きConfidential VMの作成手順](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/create-a-confidential-vm-instance-with-gpu) / [GPUクォータ](https://docs.cloud.google.com/confidential-computing/confidential-vm/quotas)）

> [!CAUTION] アプリケーション変更不要でも追加費用と設定は残る
> G4ではNVIDIA Confidential Computingのソフトウェアとサービスのライセンス料金が自動的に発生する。ドライバー580以降は推奨条件であり、公式資料が示す必須最小版と読み替えない。（[公式作成手順](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/create-a-confidential-vm-instance-with-gpu)）

**EastBraverの見立て:** アプリケーション改修を抑えた導入候補だが、移行の容易さは別に評価する必要がある。新規VMの作成が必要であり、複数ノードのワークロード用クラスタを前提とする構成には制約が残る。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/confidential-g4-gpus-are-ga/) / [出典2](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations)）

- 出典: [Google Cloud](https://cloud.google.com/blog/topics/ai-infrastructure/confidential-g4-gpus-are-ga/)（公式発表、2026-10-22 03:30 JST） / [Google Cloud Documentation](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations)（公式の構成条件）

## ほかの確認済みの更新

本文と同じ方法で根拠を確認した更新を、要点だけ短くまとめる。

- **Flint、ローカル実行向けのコード生成モデルを公開**：Recursiveは、総パラメータ約400億、トークン当たりの有効パラメータ約25億のMoEモデルFlintをApache-2.0で公開した。Apple Siliconなど向けの推論エンジン`rec`も提供する。速度と評価値は提供元の測定であり、採用時には重みの精度、ハードウェア、推論エンジンをそろえて確認したい。（[Recursiveの発表](https://recursive.com/updates/introducing-recursive-flint) / [公式モデルカード](https://huggingface.co/RecursiveSI/flint)）
- **Google CloudのA5X、Vera Rubin搭載で一般提供は11月予定**：Google CloudとNVIDIAが発表したA5Xは、NVIDIA Vera Rubin NVL72を搭載するベアメタルGPUインスタンスだ。NVIDIAの見出しは一般提供をうたうが、両社の本文は発表翌月、すなわち2026年11月の開始予定としている。提供開始済みとは読まない。（[NVIDIAの発表](https://blogs.nvidia.com/blog/google-cloud-vera-rubin-infrastructure/) / [Google Cloudの発表](https://cloud.google.com/blog/topics/ai-infrastructure/google-cloud-infrastructure-at-nvidia-gtc-berlin-2026)）
- **TorchTitan、対応モデルを拡充しTitanRLを追加**：Muse Spark Open、Muse Glimmer、Qwen3-VL、Qwen3.5、Kimi K2.7、Kimi K3、DeepSeek-V4へのPyTorchネイティブ対応を追加した。TitanRLでは、事前学習、追加学習、vLLM内の推論で同じモデル実装を使い、学習と生成を別々に拡張できる。導入時には対象モデルのレシピと必要な並列化構成を確認したい。（[PyTorchの技術解説](https://pytorch.org/blog/torchtitan-update-new-sota-models-performance-at-scale-titanrl/)）