Gemini + Cloud Run：10分钟把AI应用从代码到公网部署-代码聚汇网

Gemini + Cloud Run：10分钟把AI应用从代码到公网部署

佚格麻瓜·2026-09-07·阅读 97 GEO检测（免费）

GeminiCloud Run分钟级部署

|难度：普通|阅读约 35 分钟

上周末我做了一场线下演示，内容很简单：把一个“已经写好代码但还没部署”的应用，从零开始推到线上，做成一个公网可访问的服务。我给自己定的要求是 10 分钟内完成，最终实际耗时 7 分 40 秒，中间甚至还有现场同学问问题打断了大约半分钟。说真的，这个数字放在五年前，我自己都不会信。

这次演示的技术选型就两个核心关键词：Gemini 和 Cloud Run。前者给应用提供“AI 大脑”，后者管应用的托管和发布。我一直觉得，很多开发团队并不是不会写代码，而是被“发布应用”这件事拖住了——买服务器、配环境、装依赖、搞域名、上证书，每天都是在重复劳动中消耗激情。把这两样东西组合起来之后，应用发布这件事真的可以做到“分钟级”。

这篇文章会对这次工作坊做一次完整的复盘：为什么这么选型、代码怎么搭、部署分几步、发布之后怎么做版本更新和回滚，以及我在实际操作中踩过的坑。如果你在做出海产品、想快速验证 AI 功能的市场价值，或者早就对“部署一次应用要折腾一上午”这件事不耐烦，这篇文章应该能给你一些可以立刻动手的参考。

1. 传统发布流程里的时间黑洞，以及我想复现的极限速度

1.1 传统部署为什么这么慢

先说我最熟悉的场景。很多年以前我要把一个 Web 服务发布上线，流程大致是这样的：先申请一台云服务器，等系统初始化；然后安装 Python 或者 Node 运行时，再装各种系统级依赖；代码上传之后拉取项目依赖，还可能要编译；接着配一个 Nginx 反代，把内部的端口暴露到公网；再去域名服务商那边加一条 A 记录；等 DNS 解析生效后，申请 HTTPS 证书，配置自动续期；最后还要盯进程守护，防止半夜进程挂掉没人管。

这里面任何一步出了问题，整个时间线就会无限拉长。以我的经验，顺利一点的部署也要两个小时打底，不顺利的话一下午就没了。

真正让人痛苦的还不是慢，而是这个过程的“有状态性”。你在某台服务器上折腾出来的环境、装的工具、调整过的配置，全都绑定在那台机器上。哪天想换一台机器，或者想把同样的应用复制到另一个区域，所有步骤基本上要重来一遍。服务器成了脆弱的“宠物”，而不是可以随时销毁重建的“牲畜”。

1.2 出海场景对发布速度的硬要求

后来我参与的几个出海项目，让我对“发布速度”这件事有了完全不同的认识。出海产品的典型节奏是：业务团队一天之内会提出多个 idea，想尽快看到真实用户的反馈。如果你发布一个版本要半天，团队根本没法做“一天多轮实验”，产品迭代速度会被基础设施硬生生拖慢。

还有一个很现实的场景是多区域部署。产品刚进入海外市场的时候，谁也不知道哪个区域接受度最高，需要把同一个应用部署到多个地理位置去分别观察数据。放在传统服务器的方案里，每新增一个区域，就要重复一遍完整的环境配置，成本几乎是线性上升的。

所以我一直觉得，对于出海团队来说，“基础设施不应该成为思考负担”这件事不是一句口号，而是直接关系到你能跑多快。容器化加托管平台，本质上就是把运维复杂度交给平台，让开发者只做业务本身。

1.3 这次工作坊要复现的具体目标

基于这些想法，我把这次工作坊的目标做了一个量化定义：从一个空目录开始，到“一个自带 AI 能力、可以公网访问的应用”发布上线，整个过程控制在 10 分钟以内。

示例应用我选了一个非常有出海味道的工具：商品文案生成助手。用户在页面里输入几个商品卖点、目标市场和语言，后端调用 Gemini 模型，生成几版适合跨境电商平台使用的商品标题和描述。这个应用麻雀虽小但五脏俱全，有前端页面、有后端接口、有三方 AI 能力接入，发布过程中该遇到的配置问题基本都会遇到，非常适合用来当演示对象。

技术栈方面，后端我用 Python 的 FastAPI，前端就是一个静态 HTML 页面，AI 能力直接通过 Gemini API 接入。整个应用没有数据库，也没有消息队列，目的是先把核心链路跑通。更复杂的数据存储、异步任务、权限系统，我在文章最后会谈扩展思路。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 为什么是 Gemini + Cloud Run，而不是自己搭一套

2.1 用 Gemini 当“AI 大脑”，核心是不想重复造轮子

每次聊到基于大模型做应用，总有人会纠结一个问题：是自己训练模型，还是调用现成的 API？我的答案一直很明确：除非你的核心业务壁垒真的在模型本身，否则千万别自己造这个轮子。

自己做模型训练或者微调，意味着要解决数据准备、算力资源、训练框架、模型迭代、推理服务高可用等一系列问题。这些东西的成本极高，而且会把你从真正的产品逻辑上拉走。你可能只是想验证“帮用户生成商品文案”有没有市场，结果却陷入了一个又一个的工程泥潭，项目和业务完全脱节。

Gemini 在这个场景下有几点很吸引我。第一，接入路径极短，申请一个 API Key，装一个官方 SDK，几分钟就能写出第一个调用。第二，模型选择面宽，从轻快省钱的 Flash 系列到更高能力的 Pro 系列都有，按实际需求切换即可。第三，对多模态输入的支持很成熟，将来要做“看图写商品描述”、“用户上传图片提取文案”这类功能，不用换技术栈，直接扩展就好。

从使用者的视角看，调用 Gemini API 完全不需要关心模型部署在哪、底层有没有高可用，你只需要发请求、接结果、按 token 付费。这种“模型即服务”的方式，是开发者能把精力全部放在业务逻辑上的前提。

2.2 Cloud Run 的价值：连“服务器”三个字都可以忘掉

部署这层，我选择 Cloud Run 而不是虚拟机或者 Kubernetes 集群，原因特别简单：我不想管服务器。

Cloud Run 是 Google Cloud 上的无服务器容器平台。它能把我写的应用变成线上服务，有几个特性在“分钟级发布”这件事上非常关键：

不需要管理任何底层节点，没有补丁更新、磁盘扩容这类运维工作；
没有请求时可以缩到 0 个实例，不产生空闲费用；有请求时自动拉起实例；
每个服务自动分配 HTTPS 域名，证书由平台托管，不需要自备证书；
部署新版本只要一条命令，平台自己创建新版本并平滑切换流量。

但最打动我的一点是，Cloud Run 支持直接从源码部署。它通过 Buildpacks 自动识别工程类型、构建运行环境，也就是说我不需要先写一份 Dockerfile，也不需要手动把镜像推到仓库再拉下来部署。构建、推送、部署这三个原本独立的阶段，被压缩成了一个动作。这才是“分钟级发布”能够成立的根本原因。

2.3 两个服务叠加之后，成本与效率上发生了什么变化

把 Gemini 和 Cloud Run 放在一起使用，有一个隐藏的收益：网络路径更短。Cloud Run 实例和 Gemini API 在同一个云平台内部，访问起来稳定性和延迟表现都更好，而且 SDK、IAM 权限、网络配置这些都是一个生态里的东西，不需要各种拼凑。

成本模型也值得展开说说。Cloud Run 按“请求处理时长 × 实例规格”计费，如果服务没有流量，几乎不产生费用。Gemini API 按 token 计费，没有调用也没有花费。这意味着什么？意味着你可以在出海初期就把应用部署到多个区域，每天只有零星几个访问的时候，账单基本可以忽略不计。等流量真涨上来了，实例自动扩容，费用仍然按实际使用量走，不会被闲置资源白白吃掉预算。

这和传统“按月付费买固定 CPU 核数”的模式完全不一样。我做过的几个项目里，最怕的就是业务还没起来，服务器费用已经烧了一大截。而按量计费的组合，让试错成本变得极低。

3. 代码怎么写：一个调用 Gemini 的轻量应用从零开始

3.1 工程结构和环境准备

这个示例应用我非常刻意地保持了精简。整个项目结构是这样的：

text复制gemini-demo-app/
├── main.py              # FastAPI 后端应用
├── requirements.txt     # Python 依赖
├── static/
│   └── index.html       # 前端页面
└── .gcloudignore        # 告诉 Cloud Run 哪些文件不需要打包

本地开发需要准备的东西也很少：Python 3.11 或以上版本，一个 Gemini API Key。API Key 可以去 Google AI Studio 申请，整个申请过程很快，拿到之后先保存好，后面会用环境变量的方式注入，不要写死在代码里。

依赖只用了三个包。FastAPI 负责接口，uvicorn 负责本地启动服务，google-genai 是 Google 官方的新版 Gemini SDK。requirements.txt 内容如下：

text复制fastapi
uvicorn
google-genai

3.2 Gemini API 调用的核心逻辑

后端代码的主线逻辑是：接收用户传来的商品卖点、目标市场和语言，调用 Gemini 生成文案，再把结果返回给前端。下面是 main.py 的完整实现：

python复制import os
from fastapi import FastAPI
from fastapi.staticfiles import StaticFiles
from pydantic import BaseModel
from google import genai

app = FastAPI()
app.mount("/static", StaticFiles(directory="static"), name="static")

client = genai.Client(api_key=os.environ.get("GEMINI_API_KEY"))

class CopyRequest(BaseModel):
    selling_points: str
    market: str = "US"
    language: str = "English"

class CopyResponse(BaseModel):
    titles: list[str]
    descriptions: list[str]

@app.post("/api/generate")
def generate_copy(req: CopyRequest) -> CopyResponse:
    prompt = f"""
    You are an experienced e-commerce copywriter.
    Generate 3 product titles and 3 product descriptions.
    Market: {req.market}
    Language: {req.language}
    Key selling points: {req.selling_points}

    Return JSON in this format:
    {{"titles": ["title1", "title2", "title3"],
      "descriptions": ["desc1", "desc2", "desc3"]}}
    """

    response = client.models.generate_content(
        model="gemini-2.0-flash",
        contents=prompt,
        config={
            "response_mime_type": "application/json"
        }
    )

    data = json.loads(response.text)
    return CopyResponse(**data)

这里有几个细节值得说明。

为什么要用新版 google-genai SDK 而不是老版 google-generativeai？因为新版的 API 设计更简洁统一，genai.Client 一个入口就能处理生成、对话、多模态等各种操作，而且配置参数都在一个 config 里传递，代码读起来很清晰。官方的支持重心也已经转移到新 SDK 上，新项目直接用新版是更明智的选择。

response_mime_type 设置为 application/json，这个参数太重要了。如果不设置，模型可能返回带 Markdown 格式的文本，你还得自己解析 JSON，非常容易出问题。设置了这个参数，模型会直接把结果作为纯 JSON 返回，配合 json.loads 解析非常稳定。这是我在多次调用之后养成的习惯——凡是要结构化结果的场景，一定要让模型以 JSON 输出，而不是返回后自己剥壳。

3.3 前端页面

前端我故意没有引入任何构建工具，就是单个 HTML 文件。考虑到这只是一个演示应用，没必要为了一个页面去搭一套 Node 工程。页面结构是：一个文本域让用户输入卖点，两个输入框让用户选择市场和语言，一个按钮触发请求，最后把结果展示在下方。

核心的请求逻辑用原生 fetch 就能完成：

javascript复制async function generateCopy() {
  const req = {
    selling_points: document.getElementById("points").value,
    market: document.getElementById("market").value,
    language: document.getElementById("language").value
  };
  const res = await fetch("/api/generate", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(req)
  });
  const data = await res.json();
  // 渲染到页面上
}

3.4 本地先跑通，再谈部署

部署之前，强烈建议先在本地把整个应用跑通。我在每次发布会前都会做这一步，原因很简单：假如部署到线上才发现代码有问题，排错的成本会高很多。

本地启动只需要一行命令：

bash复制export GEMINI_API_KEY="你的API Key"
uvicorn main:app --reload --port 8080

然后用 curl 测一下接口：

bash复制curl -X POST http://localhost:8080/api/generate \
  -H "Content-Type: application/json" \
  -d '{"selling_points": "wireless earbuds, 30-hour battery, noise cancelling", "market": "US", "language": "English"}'

看到返回的 JSON 里有三条商品标题和三条描述，就说明 Gemini API 连通了。这里有个常见错误值得提醒：很多人在本地跑的时候喜欢把 API Key 写在代码里，这在小项目 Demo 阶段没关系，但只要代码一提交到仓库，Key 就可能泄露。我一般从第一步就坚持用环境变量，这样部署到 Cloud Run 时也可以无缝沿用同一套逻辑，代码里不需要做任何修改。

4. 扔到 Cloud Run：真正做到“分钟级发布”的关键一步

4.1 用源码直接部署，省掉“写 Dockerfile”的步骤

本地跑通了之后，真正的挑战来了：怎么把应用发布上线，并且控制在分钟级？

传统容器化的流程是：写 Dockerfile，构建镜像，push 到镜像仓库，再去服务器上拉取镜像、运行容器。这一套如果自己搞，光一个 Dockerfile 就能折腾很久，更不用说还要配置仓库权限。而 Cloud Run 的源码部署方式把这四步压缩成了一条命令。

前提是先完成 gcloud CLI 的初始化和登录。如果你第一次使用，需要执行这几步：

bash复制gcloud auth login
gcloud config set project your-project-id

然后直接执行部署命令：

bash复制gcloud run deploy gemini-demo-app \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --set-env-vars="GEMINI_API_KEY=你的API Key"

注意我这里用的是 --source .，关键点就在这里。Cloud Run 会把这个目录交给 Buildpacks 自动识别——它发现是 Python 项目，自动选择合适的运行时版本，自动安装依赖，自动构建出可运行的镜像，然后把镜像部署成服务。整个过程不需要你有 Dockerfile。

第一次部署大概需要三到五分钟，主要时间花在构建镜像上。构建完成后，命令行会直接输出一个 HTTPS 链接，类似 https://gemini-demo-app-xxxx-uc.a.run.app，浏览器打开就是刚才的页面。

为什么我要强调“本地先跑通”？因为如果本地已经很正常，部署到 Cloud Run 之后大概率也正常；如果部署后出了问题，问题几乎可以锁定在依赖安装或者环境变量配置这两个地方。这种排查方式会省很多时间。

4.2 部署参数背后的逻辑

gcloud run deploy 的参数每个都有实际意义，我逐个解释一下。

--region us-central1 是部署区域。Cloud Run 的服务是区域级资源，但终端用户可以从全球任何地方访问，因为 Google 有全球负载均衡。选择哪个 region 主要取决于目标用户在哪里。对于出海产品，如果你的目标市场是北美，us-central1 或者 us-east1 都是不错的默认选择；如果目标市场在亚洲，可以选 asia-southeast1 或者 asia-northeast1。地域选择对访问延迟有影响，建议根据主要流量来源来定。

--allow-unauthenticated 表示允许公网匿名访问。这个参数适合快速验证阶段。但如果你想做得更严谨，比如只允许自己公司的账号访问，就不要加这个参数，然后通过 Cloud IAM 给特定账号授予 roles/run.invoker 权限。对于面向真实用户的产品，更推荐的方式是先不加这个参数，在应用前面加一层 API Key 校验或者接入身份认证。

--set-env-vars 是设置环境变量。我把 GEMINI_API_KEY 直接传进去了。这适合快速 Demo，但在生产环境里，API Key 这样的敏感信息更推荐放进 Secret Manager，然后用 --set-secrets="GEMINI_API_KEY=gemini-api-key:latest" 这样的方式引用。好处是密钥不会出现在服务的明文配置里，而且可以独立轮换和审计。

4.3 首次访问验证

部署完成后不要急着收工，做个完整的验证。我的习惯是：

打开命令行输出的 URL，确认页面能加载；
提交一次真实的文案生成请求，确认 Gemini API 链路是通的；
打开 Cloud Run 控制台，查看日志，确认没有报错。

第一次验证尤其要看日志。Cloud Run 控制台里点进去服务，选“日志”标签，能看到每一次请求的详细信息。如果请求报 500，日志里会显示堆栈信息。大多数时候问题都出在环境变量没有传对，API Key 是空的或者无效，重新部署一遍就好了。

到这里，“分钟级发布”的核心路径已经走通。从代码写好，到公网可访问，前后不到十分钟。这基本上就是工作坊现场演示的完整过程。

5. 发布之后的事：版本迭代、流量切换、日志和回滚

5.1 版本更新与灰度流量

线上应用有一个铁律：代码改完之后，发布永远只是开始。出海产品通常用户分布在全球各地，任何一次全量发布都冒着比较大的风险。Cloud Run 在这块的设计是“版本不可变 + 流量可调”，它把每个部署都称为一个 revision，新部署会自动生成新 revision，并且默认把 100% 流量切到最新版本。

如果你不想全量发布，可以这么做：先部署新版本，但保持旧版本接收全部流量，确认新版本没问题后再逐步切流量。步骤是：

bash复制# 部署新版本，但不接流量
gcloud run deploy gemini-demo-app \
  --source . \
  --region us-central1 \
  --no-allow-unauthenticated \
  --no-traffic

# 查看 revision
gcloud run revisions list --service gemini-demo-app --region us-central1

# 把 30% 流量切到新 revision
gcloud run services update-traffic gemini-demo-app \
  --region us-central1 \
  --to-revisions=NEW-REVISION=30

灰度发布的价值在出海场景尤其明显。你可以先切 10% 的流量给东南亚用户，观察延迟和报错，再逐步扩大到 50%、100%。整个过程全在线操作，不需要重启服务。

5.2 日志、监控和常见排查路径

Cloud Run 自带日志和监控能力，不需要额外部署 Agent。控制台的服务详情页里能看到几个核心指标：请求数、延迟分布、错误率、实例数、内存使用。我最关注的是 p95 延迟和错误率。如果 p95 延迟突然飙升，通常有两种原因：一种是并发过高导致实例扩容跟不上，另一种是调用 Gemini API 的耗时变长了。

日志查看也是排查问题的第一入口。Cloud Logging 支持按请求 ID 关联所有日志，点开某一次请求就能看到完整链路。这里有一个我自己实践中很有用的技巧：在对外调用 Gemini API 的时候，往日志里打印模型名、输入 token 数和耗时。一旦用户反馈生成速度慢或者结果不对，你不需要去猜，日志里有数据可以直接定位。

5.3 出问题时候的一键回滚

即使做了灰度，线上出问题依然难以完全避免。Cloud Run 的回滚操作是我见过最克制的设计——不需要重新构建镜像，不需要重新编译，只需要把流量重新指向最近的正常版本。

比如发现新版本有内存泄漏，要回滚到上一个版本：

bash复制gcloud run services update-traffic gemini-demo-app \
  --region us-central1 \
  --to-revisions=PREVIOUS-REVISION=100

整个回滚过程在几秒内完成，不需要经历一次完整的部署。这一点对于出海产品非常重要：你的服务可能同时服务着十几个国家的用户，如果出了问题不能快速恢复，影响面会被扩大很多。能在几秒内回到正常状态，是托管平台优于自建服务器方案的一个实实在在的优势。

5.4 我实测中遇到的三个坑

最后分享三个我在实际发布过程中踩过的坑，希望你看完能绕开。

第一个坑：.env 文件被一起打包部署。有一次我在项目根目录放了一个 .env 文件，里面存了 API Key。用 --source . 部署的时候，这个文件会被 Buildpacks 一起打包进镜像，等于把密钥放到了服务端。虽然没有直接暴露给用户，但这种做法非常危险。后来我养成了习惯，项目里一定加 .gcloudignore 文件，把 .env、.git、__pycache__ 这些都排除掉。

第二个坑：用了已经不存在的模型名。某次我复制了一段老代码，里面写的是 gemini-pro，结果请求直接报 404。后来查了文档才发现模型版本已经更新，当前可用的名称是 gemini-2.0-flash、gemini-1.5-pro 这类。这提醒我，使用大模型 API 的时候，模型名最好不要硬编码在代码深处，要么集中配置在一个常量里，要么用环境变量设置，方便将来切换。

第三个坑：没有限制实例数，收到意外账单。又一次我部署了一个服务，晚上被人刷了一下接口，Cloud Run 自动扩容了几十个实例。第二天看账单才发现，虽然单价不高，但因为请求量巨大，费用也不小。解决方案是在部署时加上 --max-instances=10 限制最大实例数。对于没有做限流的应用，这个参数是强制性的，尤其是接入了大模型 API——一次请求可能消耗很多 token，被刷的代价比普通接口高得多。

6. 从工作坊里沉淀出来的经验，以及还可以往哪走

这次工作坊演示完了之后，有不止一个同学问我同一个问题：这真的能用在生产环境吗？我的答案是能，但前提是你把安全、成本、可观测性这三件事补齐。

安全方面，把 API Key 放进 Secret Manager，用服务账号的 IAM 权限而不是裸奔的匿名访问，这一点在生产环境是必须的。成本方面，给 Cloud Run 设置最大实例数，给 Gemini API 设置每用户的调用频率限制，防止被恶意刷取。可观测性方面，在日志里埋入模型调用耗时和 token 消耗数据，让每一次 AI 调用都可追溯。

从产品和架构角度，这个示例应用还可以在几个方向上继续扩展。比如加上 Firestore 保存用户的生成历史，让用户可以看到自己之前生成过的所有文案，这就从“一次性工具”变成了“有留存的工具”，对用户粘性有实质帮助。也可以接入 Cloud Scheduler，每天早上定时跑一批商品文案生成任务，把结果存储成草稿，运营人员上班直接审。更进一步，可以用 Gemini 的多模态能力，让用户上传产品图片，自动生成一份包含图片和文案的完整商品素材包——这个应用的价值就会比今天的 Demo 大很多。

还有一个我后来一直在实践的思路：把基于大模型的应用拆成“前端交互、业务逻辑、模型能力”三层，每一层都可以独立替换。今天用 Gemini，明天可能因为价格或者能力换了别的模型，对业务无感；今天部署在 Cloud Run，明天想迁移到其他平台，只要容器化的基础打好了，也不算伤筋动骨。

这次梳理下来，我最大的感受是：技术的进步并不能让你“不写代码”，但它能把那些和核心业务无关的脏活累活——服务器管理、环境配置、域名证书、部署流程——从你的工作清单上一个一个划掉。当“发布一个带 AI 能力的应用”从“需要半天”变成“需要一杯咖啡的时间”，你会发现自己对产品方向的思考和实验次数明显变多了。这可能才是“分钟级发布”带来的真正价值。