Google Cloud Next Day2のメモになります。

基調講演

TPU、Axion、ストレージ、ネットワーク　Virgo NetworkまでAIワークロードで要求されるインフラが利用できる

Agent Platformに構成コンポーネントの話の中で、Agent RegistryがSkillをサポート、Model Armorが不正プロンプトをブロック

90%がダークデータ。そのままだと活用できていない。

Gov Tech 東京パートでは、災害時自治体サイトにはスパイクなリクエストが想定して、スケーラブルなインフラが求められる。Cloud Spanner

docomoパートでは、億レベルのデータからエージェントで個々のユーザへのマーケティングの活用をGemini Enterpriseで活用を進めている

最後に、セキュリティ。CodeMender

高度化する AI ワークロードを支える Google Cloud の AI インフラストラクチャ最新動向

GKE Inference Gateway、ClaudeなどのMaaSの基盤でも使われている。euリージョンが混んでいた場合は、usリージョンにルーティング。最近のClaude、globalモデルも提供していた

Pod Snapshot、ready になるまでfuse使った場合に比べて、1/5になる。Pod Snapshot自体はGCSにあるので、ノードがリプレースされた場合でも影響ない

BigQuery で始める AI エージェントのフィードバックループ

手順、検証済みクエリ、カスタム条件を入れることで正しく答えてくれる

Agent Runtime、GKE、Cloud Run Agentデプロイすべきか（G-genブースにて）

基調講演でも話していたが、Agent Registryに登録して、Gemini Enterpriseから利用するエージェントを利用するケースは、Agent Runtime。Cloud Runでも、Instance、Sandboxなり、エージェント実行できる環境は揃ってきている。Self-hosted LLMをデプロイするケースは。GKE、Cloud Run GPUになりそうな感じかな

AI の回答に責任を持てるか? LLM とナレッジグラフで実現する検証可能な意思決定

AI、もっともらしい回答をすることがある。結論に至るにはナレッジグラフでやれせることで、LLMは文書化することで回答の揺らぎが改善する

AI エージェント時代のクラウド インフラ設計ガイドラインの重要性

Cloud Run GPU で実現するゼロスケール AI 推論

Cloud Run GPUで使っているL4、NVIDIA RTX PRO 6000について

Cloud Run jobs、通常7日実行することができるが、GPU使うとservice同様上限1hに制限される

worker Poolsで推論必要な時にCloud Run GPUを呼び出す
Gemma 4 ModelにGCSに配置してCloud Run GPUが起動させる。GCSにおいて、SDKで取得するのが一番高速

Cloud Run GPU、cacheなり使っても、cold startは避けられないので、Worker poolsから非同期で必要な時に推論させるなりするパターンが一つの選択肢になりそう。

Cloud Run worker pools で実現する「運用負荷最小・コントロール最大・費用 90% 削減」の Pull 型メッセージング基盤

Push型、スパイク要件があると連携先に負荷がかかり、Cloud Run functionsがスパイクリクエスト分スケールするのでコストが激増する可能性もある。
また、Push型だとサブスクリプションに入れるところを止めないとメンテナンス時ロストしないように考慮しないといけない

Pull型だと送れる流量を制御可能
Pull型は常駐、バッチはコスト、24h絶え間なく送られてくるので課題がある。

Pull型、メッセージが送信されるまで順次処理されるので再開時とか時間かかることがある。