Cloud Run GPU：让你的LLMs也能轻松上云（Cloud Run GPU）

管理服务，尤其是 无服务器服务（serverless services） ，已经改变了开发人员设计、构建和优化应用程序的方式。开发人员现在可以更专注于代码和业务价值，而云提供商则负责基础设施管理，包括资源可用性、补丁更新、扩展和备份等。

我最喜欢的 Google Cloud 无服务器服务是 Cloud Run。它允许你仅通过几个命令就能在大规模上运行容器。它有两种版本。

• 实时服务，为网站或 API 提供实时请求的服务

• 批处理作业，用于批处理长时间运行任务

  超兴奋的是，还有更多口味即将登场！请继续关注！

服务器less服务的优势在于自动供给。我从来不必担心服务器的创建或更新。然而，直到最近，我只能进行CPU处理，没有其他硬件支持。

不过这个夏天，事情改变了。

Cloud Run 服务现在已经支持图形处理单元了！

随着生成式人工智能的流行，开源的大型语言模型（LLM）正变得更高效和普及。这得益于它们能够本地部署，无需依赖外部提供商，如Google或OpenAI。

在某些实际的应用场景中，开源的大模型真的很重要：

• 当公司希望防止数据泄露给第三方并对其自有的AI组件保持完全控制时。
• 当公司希望根据特定需求调整大语言模型（LLM），并将它们托管时。
• 当公司希望摆脱第三方的限制、配额和成本时。

然而，随着大型语言模型（LLMs）变得越来越流行，GPU已经变得稀缺且昂贵，因为它们对优化响应延迟至关重要。

因此，在云平台上租用GPU时，通常的做法是让它一直开着，即使闲置，以确保其随时使用，以便随时可用。但这样做也有一些缺点。

首先，全天候运行GPU在经济上成本高昂，尤其是在需要过度配置来应对峰值活动时。

其次，这在环境上不可持续的，因为你不必要的消耗电力和冷却资源，阻止他人更高效地利用这些资源。

Cloud Run GPU 解决了这些问题。您不再需要过度配置或让带有GPU的机器一直运行。这是一项按需服务，可自动扩展，从零到多个实例（目前在私人预览中为7个实例，未来将提供更多实例）。

感谢这种设计，你仅在需要时使用和付费GPU，需要时扩展，闲置时缩减至0。这一切都由Cloud Run管理，真是太棒了，我非常喜爱这种方式！

为了展示这一点，我使用了最新的小巧而高效的Google开源大型语言模型：Gemma2(20亿参数的版本)。

我使用了Ollama在Cloud Run上运行Gemma，无论是带有GPU还是不带GPU的环境。Ollama自动适应可用硬件，并且预装了所有最新的驱动程序，这节省了我很多麻烦。

为了这次实验，我尽量保持简单，以便验证一下云平台上GPU的实际效果。

这里是为Cloud Run服务提供支持的Python代码main.py。
该云服务从JSON正文中的prompt键获取提示，并将LLM的响应返回。

导入 os  
from flask 导入 Flask, request  
from llama_index.llms.ollama 导入 Ollama  
llm = Ollama(model="gemma2:2b")  

app = Flask(__name__)  

@app.route('/', methods=['POST'])  
def call_function():  
    body = request.get_json(force=True)  
    prompt = body['prompt']  
    # 获取 llm 对 prompt 的响应  
    response = llm.complete(prompt)  
    # 返回响应  
    return f"{response}"  

if __name__ == "__main__":  
    # 在指定的主机和端口上运行应用  
    app.run(host='0.0.0.0', port=int(os.environ.get('PORT',8080)))

此代码静态使用gemma2:2b版本，但如有必要，也可以通过环境变量来实现动态化。

这段代码被打包在一个容器中。我从官方Ollama镜像开始，以确保默认配置并预装了NVidia驱动。
然后，我拉取了**gemma2:2b**模型，并安装了Python来运行代码。

    FROM ollama/ollama  

    RUN bash -c "ollama serve &" && sleep 4 && ollama pull gemma2:2b  

    RUN apt-get update && apt-get install -y python3 pip  

    WORKDIR /app  

    RUN pip install --no-cache-dir flask ollama llama_index llama-index-llms-ollama  

    ENV PORT 8080  

    COPY . .  

    ENTRYPOINT bash -c "ollama serve &" && sleep 4 && python3 main.py

注意，ollama运行一个web服务，我需要在后台运行它以便进行交互，无论是拉取模型还是设置入口点，在运行过程中。

代码完成后，你需要构建并部署容器。我自己通常用Cloud Build。

    gcloud builds submit --tag gcr.io/<项目ID>/ollama/gemma2.

接下来，使用 gcloud CLI 488 或更新版本[部署此容器](参见 https://cloud.google.com/sdk 的 cloud.google.com/sdk)。(GPU 选项可在版本 488 的 beta CLI 中使用)

你可以有GPU或无GPU进行部署；Ollama的代码会自动适应可用硬件。记住，它是按需付费的，因此，即使使用多个服务，只要不使用，也不会额外收费。

    # 仅CPU
    gcloud run deploy ollama-gemma2 --image gcr.io/<project-id>/ollama/gemma2 \  
     --platform managed --region us-central1 --allow-unauthenticated \  
     --memory 16Gi --cpu 4 --timeout 600s --execution-environment=gen2  

    # 带GPU
    gcloud beta run deploy ollama-gemma2-gpu --image gcr.io/<project-id>/ollama/gemma2 \  
     --platform managed --region us-central1 --allow-unauthenticated \  
     --memory 16Gi --cpu 4 --timeout 600s --execution-environment=gen2 \  
     --gpu=1 --no-cpu-throttling  --gpu-type=nvidia-l4 --max-instances=1

部署的具体情况：

• Ollama 至少需要 4GB 内存，但 Cloud Run 的 GPU 选项需要 16GB。我将两者都设置为 16GB 以进行性能比较。
• 对于 在 Ollama 默认的 30 秒超时时间内 的响应，特别是在仅使用 CPU 的情况下，我设置了 4 个 CPU。
• GPU 所需的最大实例参数 必须不超过 7（这是一个预览限制）。
• 目前仅**us-central1**支持 GPU （预览限制）。
• 只有 gen2 支持 GPU 和 Ollama （gen1 被沙箱化，限制了 CPU 功能的使用）。
• 为了测试，我允许了 Cloud Run 服务的未认证连接。切勿在生产环境中这样做!

我使用了一个简单的prompt，包含少量tokens来避免触发Ollama的30秒超时限制。

    # 仅使用CPU  
    curl -X POST -d '{"prompt":"告诉我一个数字"}' \  
     https://ollama-gemma2-<project hash>-uc.a.run.app  

    # 使用GPU加速  
    curl -X POST -d '{"prompt":"告诉我一个数字"}' \  
     https://ollama-gemma2-gpu-<project hash>-uc.a.run.app
``

回应各不相同，但这并不是这里的重点。_可以试试不同的提示_。

以下是性能结果。

* **仅 CPU**  
首次请求（加载模型）：平均耗时 25 秒  
首次回应（未使用缓存）：12.5 秒  
使用缓存的回应：小于 1 秒  
* **使用 GPU**  
首次请求（加载模型）：4.5 秒  
首次回应（未使用缓存）：1.3 秒  
使用缓存的回应：小于 1 秒

# 额外的硬件要多少钱

在 Cloud Run 上添加额外组件会产生**额外费用**。目前，**一级地区中 GPU 的价格为每秒每块 GPU 0.000233 美元** （价格会变动）。

主要的成本驱动因素不是GPU本身，而是部署时需要使用参数`--no-cpu-throttling`。这个参数显著影响Google Cloud Run的成本。

通常，Cloud Run **仅在处理请求时按 CPU 和内存资源收费**（请求上限为 100 毫秒）。在请求处理之外的时间，资源会被限流且不计费。

然而，`--no-cpu-throttling` **即使在不处理请求的情况下，也能保持资源的活跃状态**，直到实例因15分钟不活动而被删除。这意味着即使资源没有处理请求，您仍然会为此付费。

详情请见[Cloud Run 定价文档](https://cloud.google.com/run/pricing#billable-time)

The [Cloud Run 价格表](https://cloud.google.com/run/pricing#tables) 让我们来做这样的比较

* **仅 CPU** : (CPU (0.000024) + 内存 (0.0000025)) × 请求时长  
约: 费用大约为每单请求 $0.00033125
* **带有 GPU** : (CPU (0.000018) + 内存 (0.0000020) + GPU (0.000233)) × 请求时长  
约: 费用大约为每单请求 $0.0003289

虽然 `--no-cpu-throttling` 可以让 CPU 节省 25% 的成本和内存节省 20% 的成本，但由于 GPU 的成本比 CPU 高 10 倍，处理速度也快 10 倍，因此每请求的总体费用仍然差不多。

这种在实例关闭前15分钟的空闲时间导致的额外费用，每块GPU的费用为0.23美元。然而，GPU提供了显著更低的延迟（平均为1秒，而CPU为10秒）。
想想用户体验：与延迟仅为1秒的机器人聊天 vs 延迟长达10秒的机器人。

GPU的实例也能够处理十倍于每个实例的请求数量。

# 发挥GPU的强大性能

GPU支持在Cloud Run中是一项**针对需要GPU的不可预测工作负载的颠覆者**，例如**提供开源LLM的部署**。Cloud Run会根据工作负载需求自动调整实例数量。

你在 Cloud Run 上会运行什么类型的 GPU 支持的任务？