无服务器推理实战：PyTorch模型部署到Gradient平台全流程指南

上个月我把一个 PyTorch 图像分类模型部署到了 DigitalOcean 的 Gradient 无服务器推理平台上，前前后后折腾了一周。不少朋友在后台问我：无服务器推理到底怎么玩，和传统租一台带 GPU 的云主机跑 FastAPI 服务有什么区别？Gradient 平台上的无服务器推理特别适合独立开发者和小团队，它把你从“运维 GPU 服务器”这件事里彻底解放出来，只要把模型打包成镜像推上去，平台自动帮你拉起算力、做负载均衡、按调用量计费。这篇文章我不打算讲太多理论，就把我自己的完整流程拆开：从本地镜像构建、推送、创建 Serverless 部署、配置自动伸缩参数，到推理代码优化和账单防坑，一步一步说清楚。目标是你看完之后，能直接照着把模型接成一个可对外调用的 API，而且尽可能少花钱、少踩坑。

1. 项目概述与整体思路

1.1 无服务器推理解决的是哪类问题

先明确一个概念：无服务器推理不是说没有服务器，而是服务器对使用者不可见。你说“我要部署一个模型”，平台就去调度一个带 GPU 的实例，加载你的镜像，暴露一个 HTTP 端点。你对底层虚拟机、驱动版本、容器编排统统不关心。调用量上来时，平台自动多拉几个实例；流量降下去，实例缩回来，甚至可以缩到 0。这一套逻辑，和日常坐车很像：传统自建 GPU 服务器相当于自己买一辆车，保养、保险、停车位都要管，哪怕不开车也得付钱；而无服务器推理相当于打车，按里程付费，不用车的时候完全不产生费用。

由此带来的直接收益是，开发者的心智负担大幅下降。我最早自己维护过一台带 GPU 的推理节点，要装 CUDA、配 Nginx、写守护进程、做监控告警，模型更新还要担心旧进程的优雅退出。这些问题，在无服务器推理里都被平台侧抽象的部署系统接管了。你只需要关注三件事：模型文件对不对、推理代码性能优不优、端点参数配得合不合理。

1.2 为什么选 Gradient 而不是自建 GPU 服务

选型的时候我其实比较过两条路：一条是自己租一台 GPU 云主机部署服务，另一条是用托管式的无服务器推理平台。自建方案我能拿到完整的机器控制权，但付出的代价是：高频的实例维护、扩缩容脚本、网络与安全配置。对于我的业务量——白天有一些外部调用，晚上基本无人访问——自建方案里 GPU 资源的利用率其实很低，大部分时间都在空转。Gradient 这类托管方案则天然贴合这种波形起伏的流量特征。

我选择 Gradient 还有几个比较实际的理由：

• 计费细粒度：按秒计量，GPU 实例只在真正跑推理时产生费用，而且平台有比较直观的 dashboard 能看每次调用的成本。
• GPU 类型选择直接：从 A4000 这类入门级到 A100、H100 这类高算力卡都可以选，不用自己装机查兼容性。
• 周边组件完整：项目、数据集、模型仓库、部署、监控都挂在同一个控制台里，团队协作时权限管理也省事。
• 与 Paperspace 时代一脉相承的成熟产品线，社区文档和示例比较多，出问题搜起来快。

我自己整理过一个简单对比，方便你们理解投入产出比：

当然，Gradient 无服务器推理也有限制，比如每个请求的响应时间上限、存储空间上限，以及冷启动延迟。这些我在后面的实操和常见问题里会详细讲。你只要提前意识到：它是一个“为 API 形态推理而设计”的产物，而不是一个通用计算平台。

1.3 一次完整部署的整体流程

为了让后面的步骤不迷路，我先给出整条链路的俯瞰图。一次标准的无服务器推理部署，本质上是五步：

1. 在本地把模型服务代码写成“可被 HTTP 调用的服务”，并构建成 Docker 镜像。
2. 把镜像推送到 Gradient 的镜像仓库。
3. 在控制台或 CLI 里创建无服务器部署，指定镜像、GPU 类型、自动伸缩参数。
4. 获取平台分配的调用端点，传入测试数据验证返回结果。
5. 根据调用延迟、账单和错误率，反向优化镜像体积、推理代码和伸缩参数。

这篇文章的主体就是围绕这五步展开。如果已经在 Gradient 平台上创建过项目，可以直接跳到镜像构建的部分。

2. 环境准备与镜像构建

2.1 前置准备：账号、项目与 CLI 工具

整个操作需要注册 DigitalOcean 账号并开通 Gradient 服务，新用户一般会送一部分免费额度，正好拿来跑通整个流程。登录控制台后，第一步是创建一个 Project。项目和后面所有部署记录、镜像仓库、账号成员绑定在一起，建议一个业务线一个项目，不要把实验内容都堆在 Default Project 里，否则后期找部署记录会很痛苦。

本地工具方面，需要安装 Gradient CLI。它是 Python 写的，直接用 pip 装就行：

bash复制pip install -U gradient
gradient version

如果你本机 Python 版本比较新，建议建一个虚拟环境再装，避免和其他包冲突。CLI 装好后，去控制台个人设置里生成 API Key，然后配置到环境变量：

bash复制export GRADIENT_API_KEY="your-api-key"
export GRADIENT_PROJECT_ID="your-project-id"

后续所有命令行操作都会自动读取这两个变量。我踩过一个小坑：API Key 权限如果没有勾选部署权限，gradient deployments create 会直接报 403。如果遇到权限错误，先检查 Key 的角色范围，而不是急着翻代码。

2.2 把模型包成一个 HTTP 推理服务

无服务器推理平台一般不会直接接收“一个 .pt 文件”，它接收的是“一个可以启动的容器镜像”。所以本地必须先写一个小的 Web 服务，把模型的加载、预处理、推理、后处理封装成 HTTP 接口。项目结构我推荐这样组织：

text复制model_repo/
├── app.py
├── model.pt
├── requirements.txt
└── Dockerfile

app.py 我用 FastAPI 实现，Uvicorn 做 ASGI 服务器。关键点有两个：模型必须在启动阶段加载，不能在请求里反复 load；推理时要切到 eval 模式并关闭梯度追踪。示例代码：

python复制import torch
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()
model = None

class PredictRequest(BaseModel):
    text: str

@app.on_event("startup")
def load_model():
    global model
    device = "cuda" if torch.cuda.is_available() else "cpu"
    # 这里替换成你自己的模型加载逻辑
    model = torch.load("model.pt", map_location=device)
    model.to(device)
    model.eval()

@app.post("/predict")
def predict(req: PredictRequest):
    if model is None:
        raise HTTPException(status_code=503, detail="model not loaded")
    # 预处理：tokenize、转 tensor、搬到 GPU
    inputs = preprocess(req.text)
    with torch.no_grad():
        outputs = model(**inputs)
    return {
        "label": postprocess(outputs)
    }

注意，在这段代码里，@app.on_event("startup") 的加载操作只会执行一次，真正影响体验的是第一次冷启动时模型从磁盘加载到显存的速度。另外with torch.no_grad() 这一行看起来不起眼，但它直接关系到推理速度和显存稳定性，后面的“梯度陷阱”小节还会重点展开。

2.3 Dockerfile 的编写与镜像体积控制

镜像体积是决定冷启动速度的第一个关键因素。无服务器平台每次扩容都要把镜像拉到新节点上，镜像越大，拉取时间越长，第一次调用就会越慢。我建议从一开始就养成“多阶段构建 + 运行时镜像”的习惯。

我在项目里用的 Dockerfile 大概是这样的：

dockerfile复制# 阶段一：依赖打包，只负责装 Python 包
FROM python:3.9-slim as builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

# 阶段二：真正运行的镜像
FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime
WORKDIR /app
COPY --from=builder /install /usr/local
COPY app.py model.pt ./

EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "1"]

这里有两个细节值得解释。第一，基础镜像没有选择 pytorch/pytorch:2.0.1-cuda11.7-cudnn8-devel，因为 devel 版本会带上编译工具链，镜像体积多出 2 GB 以上，运行时根本用不到。第二，先把 requirements.txt copy 进镜像再安装依赖，是为了利用 Docker 层缓存，改业务代码时不至于每次都重装依赖。依赖包统一装到 /prefix=/install 下，复制到最终镜像时路径清晰，也不会污染系统目录。

2.4 推送镜像到 Gradient Registry

写完 Dockerfile 后，本地先验证一下服务能不能起来：

bash复制docker build -t demo-repo/bert-sentiment:latest .
docker run --rm -p 8000:8000 demo-repo/bert-sentiment:latest
curl -X POST http://localhost:8000/predict -H "Content-Type: application/json" -d '{"text": "test"}'

本地通了再推镜像。Gradient 的镜像仓库可以用 CLI 直接推送：

bash复制gradient images push \
  --name demo-repo/bert-sentiment \
  --source . \
  --registryUrl registry.digitalocean.ai

推送完成后，在控制台的 Registry 页面应该能看到镜像记录。推镜像这一步最容易出的问题是本地 Docker 登录信息过期，报错一般是 authentication required。重新执行一次 gradient registry login 即可。

3. 创建无服务器推理端点

3.1 UI 创建：字段含义与配置逻辑

镜像推到仓库后，就可以创建无服务器部署了。控制台入口在 Deployments，点 Create Deployment，选择 Serverless 模式。创建表单里几个关键字段我逐个说一下：

• Container Image：填镜像名和 tag，比如 demo-repo/bert-sentiment:latest。
• Eviction Policy：一般选 Automatic，平台会在实例空闲后自动回收。
• Models：如果你的镜像里没有附带权重，而是希望从 Gradient Model Repository 挂载模型，就填模型路径。大多数场景直接把权重打进镜像更省事。
• Machine Type：选 GPU 型号。A4000 适合 7B 以下模型和中小流量；A5000、A100 适合大模型或高并发。如果只是跑通流程，选最小的 A4000 就行。
• Autoscaling Range：这是一个范围，包括最小实例数和最大实例数。最小实例数也叫 min idle，决定了系统始终预留多少个热实例；最大实例数决定了系统最多能弹到多少。

这里先说一个通识：自动伸缩选项里的 min idle 是费用的主要来源。如果给它设置 1，即使一个请求都没有，GPU 也在那里空转计费。一般情况下，对外正式环境为了保证调用响应速度，可以设置 1；个人实验项目，直接设 0，让平台在无流量时缩干净。

创建完成后，平台会分配一个 https://api.gradient.run/... 形式的端点。这个端点就是对外暴露的 API URL。

3.2 CLI 创建：把部署过程脚本化

UI 创建适合第一次操作，但后续更新镜像、调整参数，用 CLI 会更高效，尤其是要写自动化发布脚本的时候。对应的创建命令长这样：

bash复制gradient deployments create \
  --name bert-sentiment-serverless \
  --projectId ${GRADIENT_PROJECT_ID} \
  --image demo-repo/bert-sentiment:latest \
  --machineType A4000 \
  --minIdle 0 \
  --maxInstances 2 \
  --scaleDownDelay 60 \
  --serverless

参数对应关系：

• --minIdle：最小空闲实例数，设为 0 表示无请求时缩到 0。
• --maxInstances：最大实例数，平台最多弹多少个副本。
• --scaleDownDelay：从当前实例缩容前的等待秒数，用于容忍突发的流量抖动。
• --serverless：明确指定创建无服务器类型部署。

CLI 创建返回的 deployment id 要记好，后面查看日志、更新、删除都靠它。

3.3 成本与延迟的平衡：三个关键参数怎么选

参数配置是新手最没有头绪的地方。我结合自己的经验，用一个表格说明三个核心参数的取舍逻辑：

这里有一个容易忽略的点：无服务器推理的“并发”不只是你看到的请求数量。如果一个请求在抢占 GPU 显存，平台会在同一实例上排队；后面的请求可能触发扩容，也可能直接失败。所以 maxInstances 并不是一个越大越好的参数，它事实上决定了你在极端情况下的血条上限。我曾经为了省事把 maxInstances 调到 10，结果被一次爬虫循环调用打出一个星期的账单，教训相当深刻。

3.4 端点测试与日志排查

创建完成后，用 curl 直接验证：

bash复制curl -X POST https://api.gradient.run/your-project/bert-sentiment \
  -H "Content-Type: application/json" \
  -d '{"text": "I love this movie"}'

第一次请求通常会慢，因为实例正在冷启动。这段时间平台日志里能看到容器拉取和启动记录。Gradient 控制台的 Logs 页面能看到 stdout/stderr，排查 Python 依赖问题和模型加载错误非常有用。还有一个技巧：如果想让冷启动阶段暴露问题，在启动脚本里加一段 print 输出模型加载前后的耗时，这样从日志能直接判断时间花在哪里。

4. 模型推理优化与梯度陷阱

4.1 从训练代码到推理服务，删掉这三类逻辑

很多算法工程师把训练好的模型接入服务时，习惯直接把 training loop 里的一段推理函数拷贝出来，简单包一层 HTTP 就上云。这种跑法能通，但性能、稳定性都会打折扣。我自己总结过，从训练代码迁移到推理服务，至少有三类东西要删干净。

第一是优化器相关代码。优化器不仅不会被调用，它的状态字典还可能被错误地保留在内存里。第二是 loss 计算和 loss.backward()。这段逻辑在推理时没有任何意义，反而会让框架保存中间激活，显著增加显存占用。第三是数据增强和随机采样逻辑。训练时的随机翻转、裁剪、mixup 都可能改变推理语义，必须在预处理链里剔除。

删掉这些之后，还要确认模型权重处于冻结状态。即使没有显式调用 torch.no_grad()，很多层在 eval 模式下也不会更新参数，但 GPU 资源的分配行为仍然不同。为了让推理阶段真正做到“只做 forward，不建反向图”，需要在代码层面明确切断梯度追踪。

4.2 推理场景下的 stop gradient 到底该用在哪儿

这里要回应一个热词：stop gradient operator。很多人是在读反向传播源码时认识它的，比如 TensorFlow 里的 tf.stop_gradient、PyTorch 里张量的 .detach()，作用都是让梯度不能流过某个计算节点。训练时，这个操作符用来把某些分支和反向图隔离；推理时，它同样至关重要——只是很多人没意识到。

无服务器推理端点加载模型后，理论上只会执行 forward，不会再反向传播。但你的输入张量如果带有梯度追踪属性，框架依然会为每一次算子调用构造计算图，记录中间变量，以备潜在的 backward。这在训练时是必需品，在推理时却是实打实的性能浪费。节点规模小的时候看不出差别，模型一复杂、调用量一上来，显存占用、单次延迟都会有明显抬升。

正确的做法是：

python复制# 方式一：手动管理，适合在局部需要梯度时
with torch.no_grad():
    outputs = model(**inputs)

# 方式二：整个推理过程禁止梯度，性能更好
torch.inference_mode()
outputs = model(**inputs)

# 方式三：对输入做 detach，阻断反向传播
inputs = {k: v.detach() for k, v in inputs.items()}

三种方式不是完全等价。model.eval() 只影响 dropout 和 batch norm 的行为，并不会阻断 autograd 记录；真正决定是否构建计算图的是 no_grad()、inference_mode() 或 .detach()。inference_mode() 是 no_grad() 的增强版本，额外禁用自动微分跟踪，推理场景下优先用它。

这个细节直接关系到无服务器推理能不能稳定扛住并发。我见过一个部署，代码里漏了梯度禁用，单个请求明显变慢，显存占用几乎是正常值的两倍，结果平台在并发达到十几时就开始报错。加了 inference_mode() 之后，延迟下降了一大截，节点也稳了很多。

4.3 推理延迟优化：半精度与导出工具

梯度问题解决后，下一步是压单次推理延迟。在无服务器推理平台上，延迟直接影响到你的扩缩容行为和最终账单，同样规模的流量，延迟越低，占用的 GPU 时间越少，费用自然越低。

我常用的优化顺序是：先上半精度，再做算子融合。PyTorch 里半精度推理很简单：

python复制model = model.half()
inputs = {k: v.half() for k, v in inputs.items()}

前提是模型结构和数据转换对 FP16 足够友好。以 BERT 这类 Transformer 模型为例，FP16 推理在 A4000 上普遍能获得 1.5 到 2 倍的加速，而没有明显的精度损失。如果模型对精度敏感，还可以启用自动混合精度推理，关键层保持 FP32。

再进一步就是用 ONNX Runtime 或 TensorRT 导出模型。导出过程会做图优化、算子融合，推理速度比原生 PyTorch 快不少，代价是需要额外处理动态轴和预处理算子。我的建议是：如果模型在 FP16 下已经能满足性能目标，先用 FP16 顶住，等业务量真的大到需要压榨每一毫秒时，再考虑导出 ONNX。

5. 常见问题与避坑实战

5.1 冷启动慢到怀疑人生

这是无服务器推理被吐槽最多的地方。第一次调用或者闲置后第一次调用，可能要等几十秒，这对面向用户的实时接口极不友好。冷启动的耗时主要来自三块：镜像拉取时间、模型加载时间、Python 依赖 import 时间。三条路对应三种优化手段。

镜像层面，用多阶段构建减小体积，尽量不装不必要的系统依赖，模型文件单独放目录并做压缩。模型加载层面，可以用 torch.save 时只保存 state_dict，加载时先实例化模型再 load，比直接 torch.load 整个对象更快；也可以把权重格式转成 Safetensors 格式，这类格式对 PyTorch 加载做了优化。依赖 import 层面，尽量延迟 import 那些只在特定分支使用的大库，比如不用的时候别 import pandas。

如果业务真的不能容忍冷启动，最直接的办法就是把 min idle 设置为 1，相当于永远保留一个热实例。代价是费用会对应增加。各取所需就好。

5.2 请求间歇性 503 和并发被限

我在测试阶段遇到过一种很典型的现象：压测刚起时前几十个请求正常，紧接着开始大量 503。看日志发现，平台检测到流量上升，正在启动新实例，但新实例的冷启动时间跟不上流量增长的速度，队列塞满后服务端开始丢弃请求，表现为 503。

这类问题的处理思路是分层解决。第一层，把 maxInstances 调大，给扩容留足余量；第二层，调整 scaleDownDelay，让流量波峰过后实例不要立刻缩掉，否则下一次小高峰又得重新冷启动；第三层，如果调用方是批量任务，在客户端做指数退避重试，给平台扩容争取时间。必须注意，maxInstances 调大意味着最高账单上限变高，要和成本预期匹配。

5.3 账单异常偏高，先查这三个项目

使用无服务器推理后，最容易产生意外费用的不是单次推理成本，而是空闲资源、存储和流量。第一，min idle 长期大于 0 造成的空闲 GPU 计费，即便一整天没人调用，费用也在累加。第二，镜像和模型文件存在仓库里，超出免费额度后按 GB/月计费，旧镜像不清理会积累成一笔不小的费用。第三，出网流量费，某些部署平台出网是单独计费的，大文件响应或频繁调用，费用会超出预期。

建议开通账号后立刻设置预算告警，养成每周看一次 dashboard 用量的习惯。我自己就有一次把 min idle 从 0 改成 1 后忘了改回去，周末两天跑了 48 小时的空转，看到账单的瞬间整个人都清醒了。

5.4 模型版本更新与快速回滚

无服务器推理的版本更新逻辑很简单：push 一个新 tag 的镜像，然后创建新部署，或者直接在已部署的 Deployment 上更新镜像引用。推荐做法是保留旧版本的部署记录，而不是直接覆盖同一个 deployment。这样新版本如果出现严重线上问题，可以在控制台把端点切回旧部署，或者在路由层直接换 URL。

我习惯在每次发布前做三件事：一是在本地跑一遍完整预测流程，确认输入输出匹配；二是记录新部署的冷启动耗时；三是小流量试调，观察日志和延迟指标，确认无异常后再切正式流量。这套流程看着麻烦，但能挡住大部分低级事故。

5.5 问题排查速查表

结语

无服务器推理并不是银弹，但它确确实实把“我要为 GPU 服务器运维操碎心”这件事从待办清单里划掉了。如果你和我一样，属于模型训练的坑踩得多、但不想再碰服务器运维的开发者，Gradient 这套方案值得一试。我个人的习惯是：demo 和内部实验项目 min idle 直接设 0，省到极致；对外正式接口保持 1 个空闲实例，配合 2 个最大实例数，再把镜像压缩到 500MB 以内，每次发布前跑一次本地冷启动计时。这套组合拳用下来，成本基本可控，调用方的体验也不会太差。最后再分享一个小技巧：镜像里把健康检查接口做到 /health 并返回 200，很多平台探活、滚动更新时都依赖它，别小看这个端点，它可以帮你减少不少部署失败和误报。