Gemma 4 上 Cloud Run：单文件 MCP 服务器包办部署与压测，顺带踩了 FastMCP 改名坑

核心洞察

这个项目最有意思的地方，是把模型部署和运维工具塞进了同一个 MCP 服务器。它不只帮你把 vLLM一个高性能的LLM推理和服务库，为DeepSeek-OCR提供优化的推理能力，支持流式输出和批量处理。 服务推上 Cloud RunGoogle Cloud 的无服务器容器运行环境，用于部署和扩展后端服务。，还顺手包办了权重暂存、健康检查、性能测试和资源回收。另外一个坑值得提前说：MCP Python SDK 2.x 把 FastMCP 改名成了 MCPServer，作者正好踩上这次迁移，所以文章里会专门交代怎么改。

核心结论

1. 该项目用一个单文件 MCP 服务器管理 Gemma 4 在 Cloud Run 上的 vLLM 服务，覆盖权重暂存、部署、健康检查、性能测试和资源销毁；实测暴露 27 个工具和 1 个资源（config://vllm-deployment-template）。
2. MCP Python SDK 2.x 将 FastMCP 重命名为 MCPServer；未锁定版本重新安装后会报 No module named 'mcp.server.fastmcp'，修复只需改导入和构造函数，并把依赖声明改为 mcp>=2。
3. Cloud Run 部署使用 NVIDIA L4 GPUNVIDIA 的推理优化型数据中心 GPU，本教程中作为 Cloud Run 服务的加速硬件，用于承载 Gemma 4 E2B 的 vLLM 推理。、区域 us-east4、vLLM 和 --no-allow-unauthenticated；关键参数包括 --concurrency=4、--max-num-seqs=8、--tool-call-parser=gemma4/--reasoning-parser=gemma4，启动探针首次检查前等待 initialDelaySeconds=180。
4. GCS 中 Gemma 4 E2BGoogle 开源的小型大语言模型，本教程中被部署为推理服务的模型本体，权重挂载路径为 /mnt/models/gemma-4-E2B-it。-it 权重总量为 9.57GiB（10,278,849,571 字节）；config.json 显示 model_type=gemma4、架构 Gemma4ForConditionalGeneration、hidden 1536、layers 35，因此不能靠文件夹名判断模型架构。
5. 项目验证结果：make lint 全部通过；make test 的 28 个测试在 1.151 秒内通过；手工 stdio JSON-RPC 测试中 tools/list 返回 27 个工具，resources/list 返回 1 个资源。

这个项目想做什么

项目是一个针对 Gemma 4 模型的 DevOps/SRE 助手。模型跑在 Cloud Run 上，用 NVIDIA L4 GPU，通过 vLLM 提供服务。整个 MCP 服务器是单文件 Python 实现的，提供的工具覆盖权重暂存、服务部署、健康检查、性能测试和资源销毁。

Cloud Run 是无服务器方案。不用配 VM，也不用装驱动，服务空闲时会缩到零，一条 gcloud 命令就能挂上 GPU。

过程中 MCP 服务器本身也得迁移到 MCP Python SDK 2.x，因为重新 pip install 之后它起不来了。迁移的内容放在 MCP 服务器那一节，也就是部署之前。

从哪里开始

MCP 开发的策略是分步推进。

首先搭好基础开发环境，配好系统变量和 Claude CodeAn AI coding assistant developed by Anthropic that provides code completion and explanations. 配置。

然后在本地通过 stdio 把 Python MCP 服务器跑起来，用 Claude Code 验证。这个服务器接着负责暂存模型、部署到 Cloud Run，并对线上端点做验证和跑一轮性能测试。

你需要先准备什么

• Python 3.10 或更高版本，mcp 2.x 声明了 Requires-Python >=3.10
• 装好并能正常用的 Claude Code
• Google Cloud SDK 已登录，且有应用默认凭据
• 一个在你所在区域能用 Cloud Run GPU 的 Google Cloud 项目，本文用的是 us-east4
• 一个名为 <project>-bucket 的 GCS 存储桶Google Cloud Storage 中的对象存储容器，本项目中命名为 <project>-bucket，用于存放 Gemma 4 E2B 的模型权重，部署时再由服务读取。，用来放模型权重

配置基础环境

先克隆仓库并切换到 Cloud Run 目录：

cd ~
git clone https://github.com/xbill9/gemma4-dev
cd gemma4-dev/gpu-2B-cloudrun-devops-agent

然后跑一次 init.sh。它会检查你的 gcloud 登录状态和应用默认凭据，询问项目 ID，安装 Python 依赖，启用 Cloud Run、Secret Manager 等 API，并给默认的计算服务账号授予对应角色。脚本遇到错误会暂停等待输入，所以请到终端里跑：

source init.sh

如果会话超时或者变量需要重置，跑 set_env.sh：

source set_env.sh

Current Environment:
  GOOGLE_CLOUD_PROJECT=aisprint-491218
  GOOGLE_CLOUD_LOCATION=us-east4
  SERVICE_NAME=gpu-2b-l4-devops-agent
  MODEL_NAME=/mnt/models/gemma-4-E2B-it
  VLLM_BASE_URL=<unset — discovered via gcloud>

Cloud Run here is --no-allow-unauthenticated. If calls fail, run: source ./set_adc.sh

VLLM_BASE_URL 可以保持未设置状态，MCP 服务器第一次需要的时候会通过 gcloud 找到服务 URL。

用 MCP stdio 传输MCP 最简单的传输方式：客户端把服务器作为本地子进程启动，通过标准输入输出通信，要求二者运行在同一环境中。实现模型管理工具

MCP 库的一个关键特性是把各种传输方式抽象掉了。不管 MCP 客户端用哪种传输方式连接，工具实现都是一样的。

最简单的传输方式是 stdio。客户端把服务器作为本地进程启动，通过 stdin 和 stdout 通信。两者必须在同一个环境里跑。在本项目里，Claude Code 就是 MCP 客户端。

服务器一行代码就能创建：

# Initialize MCP server (mcp 2.x; FastMCP was renamed MCPServer)
mcp = MCPServer("Self-Hosted vLLM DevOps Agent")

这一行原来是 FastMCP。下一节说说为什么改了。

等等，为什么是 MCPServer 而不是 FastMCP

仓库里什么都没动，变的是新装的包。requirements.txt 里的 mcp 没有锁定版本，所以下一次 pip install 解析到了 2.x 分支，服务器就导入失败了：

python3 -c "from mcp.server.fastmcp import FastMCP"

    raise ModuleNotFoundError(_MESSAGE, name=__name__)
ModuleNotFoundError: No module named 'mcp.server.fastmcp'. This is mcp 2.x, where FastMCP was renamed to MCPServer (from mcp.server.mcpserver import MCPServer) and other APIs changed; see the migration guide at https://py.sdk.modelcontextprotocol.io/v2/migration/#fastmcp-renamed-to-mcpserver or pin 'mcp<2' to keep running v1 code.

在 Claude Code 里，报错信息看起来没什么帮助，只显示服务器 Connection closed，它还没握手就在导入阶段挂掉了。

错误信息给了两个修复方向。锁定 mcp<2 是合理的，v1 分支还能收到关键修复。但这些项目都装在一个系统 Python 里，没有虚拟环境，锁版本会影响到机器上其他所有项目。迁移的话，改动就只留在仓库内部。

代码改动其实就两处，导入和构造函数：

-from mcp.server.fastmcp import FastMCP
+from mcp.server.mcpserver import MCPServer
 ...
-mcp = FastMCP("Self-Hosted vLLM DevOps Agent")
+mcp = MCPServer("Self-Hosted vLLM DevOps Agent")

@mcp.tool()、@mcp.resource()、mcp.run() 以及所有工具函数体都保持不变。动手改之前，把迁移指南的其余条目对照一下你自己的服务器：

grep -c "^@mcp\.\(tool\|resource\)" server.py
grep -A1 "^@mcp\." server.py | grep -c "^def"
grep -n "get_running_loop\|asyncio.run(" server.py || echo "(no matches)"
grep -n "^import httpx" server.py; grep -n "^httpx" requirements.txt

从这段输出里能看到三件事：

• mcp 2.x 不再装 httpx 了。 它现在依赖 httpx2。这个服务器的代码里 import 了 httpx，之所以没翻车，是因为 requirements.txt 里本来就已经声明了。
• 那 12 个同步 handler 现在跑在 worker 线程上。 只有依赖 event loop 线程的代码会受影响，这个项目里没有这类代码。
• 服务器的 version 现在是空的，除非你在 MCPServer(...) 里传 version= 参数。功能不受影响，握手信息里会体现出来。

所以依赖声明要改成 mcp>=2，替换掉原来那行光秃秃的 mcp。

---

小技巧：先改调用，再改 import

这个项目挂了个 Claude Code hook，每次编辑之后都会跑 ruff check --fix。你要是先动了 import 那一行，MCPServer 会在那一瞬间变成"import 了但没用"的状态，hook 顺手就把它删了：

--- server.py
+++ server.py
@@ -1,3 +1,2 @@
-from mcp.server.mcpserver import MCPServer

 mcp = FastMCP("demo")

Would fix 1 error.

两处改动放在同一次编辑里，或者先改调用方再改 import。任何在保存时跑 ruff check --fix 的编辑器都有这个坑。

---

跑一下 Python 代码

lint 可以直接跑：

make lint

ruff check .
All checks passed!
ruff format --check .
14 files already formatted
mypy .
Success: no issues found in 6 source files

测试：

make test

----------------------------------------------------------------------
Ran 28 tests in 1.151s

OK

测试套件会拿注册的工具集合跟一份硬编码的列表对比。如果改名之后有工具静默地注册失败了，这里就能直接暴露出来。

---

手工测一下协议

单元测试调的是 Python 层。客户端走的是 stdio 上的 JSON-RPC，这部分也得测。用 sleep 把 stdin 撑住，否则一个光秃秃的 printf 管道会让服务器看到输入结束，答完 initialize 就退出了：

{ printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
  '{"jsonrpc":"2.0","id":3,"method":"resources/list","params":{}}'; sleep 5; } \
  | python3 server.py 2>/dev/null

输出摘要：

initialize OK: name='Self-Hosted vLLM DevOps Agent' version='' proto 2025-06-18
tools/list OK: 27 tools -> cloudrun_analyze_cloud_logging, cloudrun_analyze_gpu_logs, cloudrun_check_gpu_quotas, cloudrun_deploy, ...
resources/list OK: ['config://vllm-deployment-template']

27 个工具加上那个 resource。这段留着，它是区分"服务器挂了"和"客户端配置挂了"最快的手段。

---

Claude Code 的 .mcp.json

Claude Code 会读项目目录下的 .mcp.json，它用系统里的 python3 启动 server.py：

{
  "mcpServers": {
    "cloudrun-devops": {
      "command": "python3",
      "args": ["/home/xbill/gemma4-dev/gpu-2B-cloudrun-devops-agent/server.py"],
      "env": {
        "GOOGLE_CLOUD_PROJECT": "aisprint-491218",
        "GOOGLE_CLOUD_LOCATION": "us-east4",
        "VLLM_BASE_URL": "https://gpu-2b-l4-devops-agent-289270257791.us-east4.run.app",
        "MODEL_NAME": "/mnt/models/gemma-4-E2B-it"
      }
    }
  }
}

---

用 Claude Code 验证

检查 Claude Code 到本地服务器的连接：

claude mcp get cloudrun-devops

cloudrun-devops:
  Scope: Project config (shared via .mcp.json)
  Status: ✔ Connected

如果会话早期服务器启动失败了，从 /mcp 里重连一下，或者开个新会话让它加载修好的代码。

---

通过 MCP 管理模型生命周期

这些 MCP 工具覆盖了 Cloud Run 部署的整个生命周期。每个工具都带 cloudrun_ 前缀。下面是 cloudrun_get_help 的截取输出：

The server is running in CLOUD RUN mode targeting NVIDIA L4 GPU in region us-east4.

🐳 Infrastructure & Deployment
  cloudrun_deploy, cloudrun_destroy, cloudrun_status, cloudrun_update_scaling,
  cloudrun_get_deployment_config, cloudrun_get_gpu_deployment_config, cloudrun_check_gpu_quotas
📊 Model Management
  cloudrun_list_vertex_models, cloudrun_list_bucket_models, cloudrun_save_hf_token,
  cloudrun_get_vertex_ai_model_copy_instructions, cloudrun_get_huggingface_model_copy_instructions,
  cloudrun_get_huggingfacehub_download_path
📊 Monitoring & Status
  cloudrun_get_metrics, cloudrun_get_system_status, cloudrun_get_endpoint,
  cloudrun_get_endpoint_url, cloudrun_get_model_details, cloudrun_verify_model_health
📈 Performance & Benchmarking
  cloudrun_run_benchmark
💬 Interaction & Diagnostics
  cloudrun_query_gemma4, cloudrun_query_gemma4_with_stats, cloudrun_query,
  cloudrun_analyze_cloud_logging, cloudrun_analyze_gpu_logs, cloudrun_suggest_sre_remediation

把模型权重放进 GCS

Cloud Run 通过 GCS FUSE 把 bucket 只读挂到 /mnt/models，权重只需要往 GCS 传一次。下载到真实磁盘上，别用 /tmp，这台机器上它是个 RAM 支持的 tmpfs，比模型还小。

hf download google/gemma-4-E2B-it --local-dir ~/hf-downloads/gemma-4-E2B-it
gcloud storage rsync ~/hf-downloads/gemma-4-E2B-it gs://aisprint-491218-bucket/gemma-4-E2B-it \
  --recursive --exclude='^\.cache/'
gcloud storage ls -l gs://aisprint-491218-bucket/gemma-4-E2B-it/

Average throughput: 41.4MiB/s
      4954  2026-09-10T14:51:14Z  gs://aisprint-491218-bucket/gemma-4-E2B-it/config.json
10246621918  2026-09-10T14:55:13Z  gs://aisprint-491218-bucket/gemma-4-E2B-it/model.safetensors
  32169626  2026-09-10T14:51:34Z  gs://aisprint-491218-bucket/gemma-4-E2B-it/tokenizer.json
TOTAL: 9 objects, 10278849571 bytes (9.57GiB)

这个 bucket 还跟别的模型共用，跑一下 cloudrun_list_bucket_models 就能看到坑在哪：

> cloudrun_list_bucket_models

### Contents of GCS Bucket: aisprint-491218-bucket
- gemma-2b-it/config.json (0.00 MB)
- gemma-2b-it/model-00001-of-00002.safetensors (4716.15 MB)
...
- gemma-4-12B-it-qat-w4a16-ct/model.safetensors (9788.73 MB)
...

架构才是关键，文件夹名不作数。 gemma-2b-it/ 看着像答案，其实是初代 Gemma，gemma4 那套 parser 根本喂不进去。config.json 一读就清楚：

gcloud storage cat gs://aisprint-491218-bucket/gemma-4-E2B-it/config.json \
  | python3 -c 'import json,sys; c=json.load(sys.stdin); t=c["text_config"]; print(c["model_type"], c["architectures"], "hidden", t["hidden_size"], "layers", t["num_hidden_layers"])'

gemma4 ['Gemma4ForConditionalGeneration'] hidden 1536 layers 35

部署到 Cloud Run

Makefile 里的 deploy-vllm target 是 vLLM 和 Cloud Run flags 的唯一出处。几个最要紧的：

服务另外还挂了 --no-allow-unauthenticated，每个调用方都得带 identity token。

make deploy

Deploying container to Cloud Run service [gpu-2b-l4-devops-agent] in project [aisprint-491218] region [us-east4]
Deploying new service...
Routing traffic.....done
Done.
Service [gpu-2b-l4-devops-agent] revision [gpu-2b-l4-devops-agent-00001-ssq] has been deployed and is serving 100 percent of traffic.
Service URL: https://gpu-2b-l4-devops-agent-289270257791.us-east4.run.app

gcloud run deploy 会一直等到 startup probe 通过才返回，而这个 probe 第一次检查前要等 initialDelaySeconds=180。做好等几分钟的准备。

演示模式：固定实例数

默认配置在 0 和 1 个实例之间自动伸缩。服务一闲置，GPU 就要冷启，演示根本等不了。Makefile 留了个 SCALING 变量：

SCALING ?= auto
ifeq ($(SCALING),auto)
SCALING_FLAGS = --scaling=auto --max-instances=1 --min-instances=0
else
SCALING_FLAGS = --scaling=$(SCALING)
endif

make deploy SCALING=1
gcloud run services describe gpu-2b-l4-devops-agent --region us-east4 --format='yaml(metadata.annotations)'

    run.googleapis.com/manualInstanceCount: '1'
    run.googleapis.com/scalingMode: manual

现在这块 L4 就一直跑着，直到你手动改回来。直接 make deploy，还有 cloudrun_deploy 和 cloudrun_update_scaling 这两个 MCP 工具，都是故意传 --scaling=auto 的——服务一旦卡在 manual 模式且实例数为 0，每个请求都吃 503。这几个命令谁跑一下，演示就被悄悄打回 scale-to-zero 了。

检查系统状态

看状态用一个 MCP 工具就够了：

> cloudrun_get_system_status

GPU Cloud Run System Status (gpu-2b-l4-devops-agent)
- vLLM Health: Online (https://gpu-2b-l4-devops-agent-289270257791.us-east4.run.app)
- Cloud Run Service Status: Ready
Next Step: Use cloudrun_query_gemma4 to interact with the model.

---

交叉验证部署的模型

直接问 vLLM 它加载了什么：

curl -s -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  https://gpu-2b-l4-devops-agent-289270257791.us-east4.run.app/v1/models | python3 -m json.tool

{
    "object": "list",
    "data": [
        {
            "id": "/mnt/models/gemma-4-E2B-it",
            "object": "model",
            "owned_by": "vllm",
            "max_model_len": 16384
        }
    ]
}

模型 id 取的是挂载路径。容器启动时带的是 --model=/mnt/models/<path>，OpenAI API 认的就是这个路径，和 Hugging Face 上的仓库名没关系。

再跑一遍 MCP 的健康检查：

> cloudrun_verify_model_health

Model health check PASSED.
Model: /mnt/models/gemma-4-E2B-it
Response: 'Hello! Yes, I am working. I am Gemma 4, a Large La...'
Latency: 0.87 seconds.

第一次部署刚完成时，同样的检查要 2.48 秒。这个回答走了整条链路：Claude Code 通过 MCP 调工具，工具再去 Cloud Run 上调 vLLM。

---

基准测试

让 agent 用 cloudrun_run_benchmark 的默认参数跑一遍：一次预热，然后并发 1、2、4、8 各打 20 个请求，每个最多输出 128 token，固定 prompt，temperature 0。

每一档的每个请求都成功了。有三点：

并发 1 到 4，吞吐几乎线性往上走。 188.46 token/s 是单流 49.63 的 3.8 倍，平均延迟只从 2.58 秒挪到 2.71 秒。L4 在并发 4 的时候远没吃满。

4 到 8，停了。 吞吐只涨了 0.6%，平均延迟从 2.71 秒跳到 4.86 秒。一半请求在排队。

瓶颈出在 Cloud Run 的配置上，GPU 没到极限。 一个实例同时只接 --concurrency=4 个请求，而 vLLM 那边能批量到 --max-num-seqs=8。下一节拿同一块卡、前面不加任何东西来验证这一点。

---

和其他部署比一比

同一个 checkpoint，同一块卡（AWS EC2 g6.2xlarge 上的单张 NVIDIA L4），用 vLLM 加 --max-num-seqs 8 起服务，再用 vllm bench serve 按同样的并发档位、同样 128 输出 token 扫一遍：

并发 4 之前，两边就是同一块卡在干同样的活。 每一档差距都在 8% 以内，Cloud Run 还略快一点。

到 8 的时候，g6 还能往上走。 它跑到 360.17 token/s，是 Cloud Run 189.53 的 1.9 倍，因为 vLLM 前面没有任何东西把并发卡在 4。这就直接说明 Cloud Run 的平台期来自 --concurrency=4，跟 L4 本身无关。

这几行看形状就行，别当排行榜。两次跑的引擎版本、KV cache 精度、prompt 和客户端位置都不一样，结尾的范围说明里都列了。

---

价格和性能怎么样

Cloud Run 的 GPU 服务在实例运行期间按秒计费，GPU、CPU、内存一起算，因为 L4 要求 --no-cpu-throttling。下面是 Cloud Billing 目录里 us-east4 的挂牌价：

演示模式下固定一个实例，一天 34.10 美元。默认模式下空闲的服务会缩到零实例。

按每百万输出 token 算，从基准测试推出来：

赢的是 VM，两个原因：小时单价更低，吞吐翻倍而且没有接入上限。Cloud Run 那个是挂牌价、按需计费；g6 是 spot 价，随时可能被回收。Cloud Run 换来的是不用管 VM，空闲时零成本。对断断续续的 SRE 活儿来说，这个数字才算数。

---

销毁

make destroy

这篇文章没跑这一步，演示服务还开着。它做的事是删掉 Cloud Run 服务，权重留在 bucket 里，下次部署接着用。

---

小结

这篇文章的目标是把 Gemma 4 E2B 部署到 Cloud Run 的 NVIDIA L4 GPU 上，用 vLLM 跑，并且通过一个 Python MCP 服务器，在 Claude Code 里把整个生命周期管起来。方案能跑通，是因为部署之前先把 MCP 服务器在本地拉起来验证过。也就是在这一步，MCP SDK 2.x 的迁移问题冒了出来，代价是一个 import 和一个类名。部署结果：

• MCP 服务器迁移之后，27 个工具和那个 resource 全部注册成功，没有变化，接着驱动了 staging、部署、验证和基准测试
• Gemma 4 E2B 一条 make deploy 就上了 Cloud Run，MCP 健康检查 0.87 秒通过
• 吞吐从并发 1 到 4 放大 3.8 倍，延迟基本持平，峰值 189.53 token/s
• 并发过了 4，Cloud Run 的 --concurrency=4 就是上限；同一块 L4 在 EC2 上并发 8 能跑到 360.17 token/s
• 固定一个 Cloud Run L4 实例的挂牌价是每小时 1.4209 美元，峰值时每百万输出 token 2.08 美元

范围说明：一个 Cloud Run 实例，一张 NVIDIA L4，区域 us-east4，vLLM v0.26.0-cu129，Gemma 4 E2B，bf16 权重加 fp8 KV cache，扫描期间手动固定为一个实例。每个档位扫 20 个请求，单一固定 prompt，128 最大输出 token，从笔记本经公网发起。EC2 那组是另一次运行：vLLM 0.28.0，bf16 KV cache，1024 token 的随机 prompt，每档 8 到 32 个请求，在实例本机上发起，spot 计价，区域 us-east-1。成本是按挂牌价算出来的，不是账单。MCP 服务器跑在 mcp 2.2.0 和 Python 3.14.7 上。

整套流程跑下来，用 MCP 配合 Claude Code 把 Gemma 4 部署到 Cloud Run，方案是验证通的。做法不复杂，就是增量推进，一步一步来，每一步确认通过了再往下走。出问题的时候也好排查，知道卡在哪一环。

参考链接

• gpu-2B-cloudrun-devops-agent | GitHub
• 迁移指南：v1 到 v2 | MCP Python SDK
• GitHub - modelcontextprotocol/python-sdk

常见问题（FAQ）

mcp 2.x 里 FastMCP 改成 MCPServer 后，服务器导入就崩溃，怎么修？

因为 requirements.txt 里的 mcp 没锁版本，重新 pip install 解析到了 2.x，FastMCP 已改名为 MCPServer。修复只有两处：导入改成 from mcp.server.mcpserver import MCPServer，构造函数同步改名；@mcp.tool()、@mcp.resource()、mcp.run() 和工具函数体都不用动。

不想降级全局 Python 环境，怎么把 MCP 服务器迁移到 mcp 2.x？

这些项目都装在同一个系统 Python 里，锁 mcp<2 会影响机器上其他项目，而改代码只动仓库内部两行。改完后把依赖声明从光秃秃的 mcp 换成 mcp>=2，再按迁移指南核查 httpxPython 的异步 HTTP 客户端库。mcp 2.x 起不再依赖 httpx 而改用 httpx2，因此直接 import httpx 的服务必须在 requirements.txt 中自行声明。、同步 handler 和 server version 即可。

部署 Gemma 4 E2B 到 Cloud Run 之前需要准备什么？VLLM_BASE_URL 要手动配吗？

需要 Python 3.10 或更高版本、可用的 Claude Code、已登录且有应用默认凭据的 Google Cloud SDK、支持 Cloud Run GPU 的项目，以及放权重的 GCS 桶。VLLM_BASE_URL 可以留空，MCP 服务器第一次需要时会用 gcloud 自动发现服务 URL。