无服务器推理实战：用DigitalOcean Gradient部署GPU推理服务全流程

最近帮一个做AIGC应用的朋友把推理服务从常驻GPU实例迁到了无服务器推理，用的就是DigitalOcean Gradient。折腾了差不多一个周末，跑了几个模型，把该踩的坑基本踩了一遍。今天这篇就把整个流程复盘一下，从环境准备到真实请求，再到参数调优和问题排查，尽量一次说透。

先说无服务器推理这个概念。它和你自己租一台GPU机器常驻服务的区别，在于你不需要预留一个永远在跑的实例。没有请求进来的时候，机器自动缩到零，不产生GPU费用；有请求进来时，平台在秒级时间内把对应规格的GPU实例拉起来，跑你的推理服务，返回结果，然后根据空闲时间再缩回去。计价按实际推理时长和所选实例规格来算，对波动明显、又不想花精力维护底层的团队来说，这个模式比常驻K8s集群或者裸金属GPU省心得多。

我这次用的是DigitalOcean的Gradient平台，它本质上是Paperspace被DigitalOcean收购之后整合出来的产品线。支持按需启动GPU实例、跑训练任务，也支持无服务器推理（Serverless Inference）。下面进入正题。

1. 先把无服务器推理这件事想明白

1.1 从一次痛苦的自建经历说起

以前我在另一家云厂商上自己搭过推理服务：先开一台带GPU的云主机，装驱动、装CUDA、配Python环境，然后把模型文件推上去，再用FastAPI包一层HTTP接口，最后用systemd保活。听起来不复杂，实际操作一个月之后各种问题就出来了。

最明显的是成本。为了应对突发流量，实例规格不能太低，我常年留着一张A10G空闲待命，一个月GPU账单固定几千块，但真实业务只有每天两个高峰时段有流量，大量算力是闲置的。其次是运维，镜像更新要停机，CUDA版本升级要重新部署，跑着跑着显存泄漏还得半夜起来重启容器。

同样的业务如果跑在无服务器推理上，思路会完全不同：GPU实例不是你的资产，而是按请求拉起的一个“计算胶囊”。请求结束，整个环境销毁，下次再来一个请求，又从镜像重新创建。既然实例是临时的，你的推理服务就必须做到两件事——启动要快、状态要无感。

1.2 无服务器推理与传统常驻服务的对比

我把两种模式的关键差异放在一起做了个对比：

无服务器推理不是万金油。如果你的业务要求P99延迟在100毫秒以内，而且流量平稳得像心电图，那常驻实例仍然是对的。但如果你的流量是“平时很闲、偶尔被推荐系统带飞”，或者你要频繁跑一批离线推理任务，无服务器模式能把成本打下来一个量级。

1.3 Gradient平台到底适合谁

Gradient的定位是给AI团队提供一个更偏“应用层”的部署平台。你不用管Kubernetes，不用管Ingress，也不用管GPU驱动，只管两件事：把一个能提供HTTP服务的镜像推到仓库里，然后在网页控制台上点几下配置，一个带公网地址的推理API就有了。

它适合几类人：一是想快速把Hugging Face模型做成API给前端联调的产品原型；二是需要跑定时批量推理但不想养GPU实例的团队；三是刚起步的独立开发者，希望按量付费而不是一次性掏大几千开卡。

当然，它也有自己的边界。如果你的模型要挂载庞大的向量数据库或者对象存储，需要对底层网络做精细控制，这类需求更适合用传统的云主机加自建K8s来解决。Gradient的输出是“开箱即用的推理API”，不是“高度可定制的GPU集群”。

2. 在Gradient上跑通无服务器推理全过程

2.1 准备阶段：注册账号与访问令牌

去DigitalOcean的官网找到Gradient入口，注册账号。注册之后，先别急着在网页上点来点去，建议直接打开Gradient的开发者文档，找到“API Keys / Tokens”页面，生成一个Personal Access Token。

这个Token非常关键。Gradient平台的很多操作都支持通过CLI或HTTP API完成，包括创建项目、部署Worker、创建Endpoint，脚本化的方式比网页点按更容易复现，也方便后续做自动化发布。生成Token后，在本地终端里设置环境变量：

bash复制export GRADIENT_API_TOKEN="your_token_here"

如果你打算直接用命令行工具，可以顺手安装Gradient CLI，官方文档里推荐的方式是下载二进制包或者用pip安装Python SDK。我个人习惯用SDK，后面无论是写脚本批量创建Endpoint还是集成到CI流水线，都比较顺手。

2.2 核心概念：先分清Project、Worker和Endpoint

第一次用Gradient的时候，我一度被几个名词搞混了。这里先做一个名词解释，后面所有操作都围绕这三个对象展开：

• Project：一个项目空间，用来组织机器学习资源。账号下可以建多个Project，访问令牌也是绑定到Project的。
• Worker：一次具体的“算力任务”。你可以把它理解成一个短暂运行的容器任务。无服务器推理场景里，一个Worker就是“把一个镜像跑起来，注册成为可以被Endpoint调用的推理服务”。
• Endpoint：对外暴露的API入口。用户请求打到Endpoint上，平台根据请求量动态调度GPU实例来执行Worker中的镜像。

网络上有时候会把Worker叫“模型Worker”，其实平台这边并不会限制你必须用哪种格式部署模型。它可以是一个Triton Inference Server，也可以是你在FastAPI里自己加载模型写出来的推理接口。在后面这一部分里，我用的就是FastAPI方案。

2.3 构造一个推理镜像：Dockerfile实践

假设你已经有一个训练好的模型，比如一个文本分类模型，现在要把它部署成API。第一步是把模型文件和推理代码一起打包成一个Docker镜像。

我以PyTorch + STransformer为例写一个推理服务的Dockerfile，实际使用中你可以替换成自己的模型类型：

dockerfile复制FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 模型文件复制进镜像，规模较大时建议放在外部存储，启动时下载
COPY ./model /app/model
COPY ./inference_server.py /app/inference_server.py

EXPOSE 8000

CMD ["uvicorn", "inference_server.py:app", "--host", "0.0.0.0", "--port", "8000"]

在写推理服务代码时，有几点和本地跑脚本完全不同的地方。首先是不要在模块导入时就加载模型，应该把加载逻辑放到FastAPI的lifespan事件里，也就是服务进程启动后再加载。原因是无服务器平台在实例启动后可能做健康检查，如果健康检查时模型还没加载完成，平台会认为实例启动失败，反复重启，最终导致请求超时。

下面是一个推荐结构：

python复制from contextlib import asynccontextmanager
from fastapi import FastAPI
from pydantic import BaseModel

model = None
tokenizer = None

@asynccontextmanager
async def lifespan(app: FastAPI):
    global model, tokenizer
    # 在这个阶段加载模型，启动慢一点没事，但要保证加载完成后端口才真正“就绪”
    model = load_model("/app/model")
    tokenizer = load_tokenizer("/app/model")
    yield

app = FastAPI(lifespan=lifespan)

class PredictRequest(BaseModel):
    texts: list[str]

@app.post("/predict")
async def predict(req: PredictRequest):
    inputs = tokenizer(req.texts, padding=True, truncation=True, return_tensors="pt")
    with torch.no_grad():
        outputs = model(**inputs)
    return {"logits": outputs.logits.tolist()}

这里要提一下你可能在热搜里见过的那个词：stop gradient operator。在PyTorch里对应的是 detach()，在TensorFlow里对应的是 stop_gradient，作用是把张量从计算图中切出来，停止梯度回传。为什么推理代码里要刻意加这个？因为一些模型的forward方法可能会隐式创建计算图，哪怕你只需要前向结果。如果不小心把训练流程的代码直接搬进推理服务，轻则显存慢慢吃满，重则平台判定为异常进程直接重启实例。推理时所有不需要反传的中间量，能detach就detach；更极端的做法是直接把整个推理过程包在 torch.no_grad() 里，从源头上不建图。

2.4 推送镜像到Gradient仓库

镜像构建好之后，要push到Gradient自己的Container Registry，或者其他容器镜像仓库。我之前第一次部署时把镜像推到了Docker Hub，结果在Gradient拉取时超时了两次，后来干脆直接用Gradient内置的Registry，速度快很多。

Gradient的Registry地址一般在文档里能找到，格式类似 registry.gradient.run/your-project-id，登录的方式：

bash复制docker login registry.gradient.run -u your_token -p your_token
docker build -t registry.gradient.run/your-project-id/my-model-server:v1 .
docker push registry.gradient.run/your-project-id/my-model-server:v1

这里有一个非常重要的细节：给镜像打标签时不要只打 latest。无服务器平台对部署一致性要求很高，如果你某天重新push了一个相同的 latest 标签，而Worker或Endpoint已经引用了这个标签对应的旧镜像，几乎一定会出诡异问题——有些实例跑新代码，有些实例还是旧镜像，你很难排查。最好使用不可变标签，比如时间戳加Git短哈希的组合：v1-20250121-a1b2c3。

2.5 创建Worker并配置Endpoints

镜像推完，回到Gradient控制台，在项目下找到“Workers”或“Deployments”页面，新建一个Worker。填写以下信息：

• 名称：一个可读的任务名，比如 bert-classifier-worker
• 镜像：填刚才push好的镜像地址
• 工作端口：填 8000（必须和Dockerfile里EXPOSE的端口一致）
• GPU类型：这一步取决于你创建的Endpoint配置，尽量和工作负载匹配

创建Worker只是完成“注册”动作，真正触发实例拉起的是Endpoint请求。接着切到“Endpoints”页面，新建一个Endpoint：

• 模型Worker选择刚才创建的Worker
• 引擎类型，选自定义服务（Custom Service）
• GPU选择，按需选，我后面会专门讲怎么选
• 实例数量和自动缩容策略，可以设最小为0，最大为2或3

创建成功后，平台会给一个类似 https://your-endpoint.gradient.run 的公网地址。到这里，一个最小可用的无服务器推理API就算搭好了。如果你在Worker启动日志里看到 Application startup complete 之类的输出，说明镜像内服务正常启动，可以发起正式请求了。

3. 关键参数与配置项深度解析

3.1 GPU型号别只看显存，要看算力性价比

Gradient平台提供多款GPU，常见的有T4、L4、A10G、A100、H100这种。很多人选GPU第一反应就是显存多大，其实被坑过之后你会明白，核数、显存带宽、平台计价三者必须放在一起看。

就我的实测经验来说：

• 如果你的模型是B榜小模型，几百MB以内，T4完全够用。T4推理文本分类和小型seq2seq，延迟基本在几十毫秒到几百毫秒之间。
• 如果跑7B级别的量化模型，L4是个不错的选择，比T4快不少，显存32GB够放量化后的权重。
• 如果跑13B以上甚至更大的模型，直接上A10G或A100，别指望T4。

另外要注意平台的“空闲计费策略”。无服务器推理虽然会有缩到零的行为，但在“从活跃回到零”的这段时间里，如果配置了Min Replicas=1，它依然会保留一个冷实例持续计费。开发环境可以容忍冷启动，生产环境如果对延迟极其敏感，才考虑保留最小实例。

3.2 并发上限与实例扩展策略

无服务器推理的并发模型，和你在K8s里设置的HPA不太一样。平台是通过“单个实例最大并发数”和“最大实例数”两个参数联合控制弹性的。

假设你设了Instance Count上限为3，单实例最大并发为8，那么理论上，你的服务瞬时最多可以承载3×8=24个并发请求，超出部分会排队或直接返回429。这个参数设置不好会出两种典型问题：

• 并发设置过高：多个请求同时打到一个实例上，GPU显存瞬间吃满，进程OOM，平台认为Worker不健康，重启实例，结果就是大面积请求超时。
• 并发设置过低：明明有足够算力，却因为并发上限卡了流量，平台反复拉起新实例，成本和延迟同时劣化。

一个靠谱的设置方式，是在本地先做压测。把自己期望的单用户推理延迟测出来，再去推算单实例能达到的并发数。比如某个模型单次推理峰值显存6GB，你的实例是L4 32GB，那么单实例至少能并发4个请求，留出余量设成2~3更稳。之后再根据预估总QPS反推最大实例数，比如峰值QPS是30，单实例能扛3个并发，那至少需要10个实例，但为了成本和排队容忍度，可以先设成5个，再慢慢调。

3.3 冷启动：无服务器推理永远绕不开的话题

冷启动时间就是实例从零到一的过程，包括拉镜像、启动容器、执行模型加载。Gradient的冷启动时间受镜像大小和模型加载耗时影响较大。我第一次部署一个加载时间将近30秒的大模型时，第一次请求几乎总是返回超时，后来才反应过来，要把平台的Health Check超时时间和Endpoint请求超时设置改大。

控制冷启动可以从三个方向入手：

• 减小镜像体积。能不用完整CUDA镜像就别用。PyTorch官方镜像动辄几个GB，考虑用带CUDA运行时依赖的精简版，再配合 pip install --no-cache-dir 减小层体积。
• 模型文件不要打进镜像。我把模型权重放在外部对象存储，容器启动时先下载再加载。有人会担心启动更慢，但如果你的模型只有1~2GB，这种方式比维护一个超大镜像划算得多。
• 请求超时设置合理。平台Endpoint通常有请求超时上限，模型加载慢时，可以把超时调大，但注意这也会影响平台判定实例“健康”的节奏。超时设得太大，加载失败后要等很久才重启，反而更容易被打挂。

3.4 那个容易被忽略的Stop Gradient Operator问题

回到关键词里的 stop gradient operator。这个词在无服务器推理里的意义，比你在训练代码里用 detach() 要更宽泛一些。

我在生产环境看到过这样一个线上事故：团队把一个训练脚本直接改成了推理服务，里面有一个自注意力模块，在计算权重时用了 torch.autograd.grad，导致每次请求都会构建完整计算图。模型在本地单测时没有问题，因为本地请求量小，显存增长不明显；但一上无服务器推理，平台按高并发拉起多个实例，所有实例的显存都在悄悄爬升，最终在凌晨流量高峰集体OOM，用户大量报错。

排查日志后发现，问题就出在这种“隐式建图”的操作上。正确的做法很简单：

python复制# 错误写法：每次推理都构建计算图
scores = torch.autograd.grad(outputs=logits, inputs=hidden_states, grad_outputs=torch.ones_like(logits))[0]

# 正确写法：推理只做前向，梯度相关操作全部关闭
with torch.no_grad():
    logits = model(input_ids)

在推理服务里，只要你的代码路径里出现了 backward()、autograd.grad()、create_graph=True 这类字样，就一定要警惕。无服务器平台不会帮你拦截这类操作，它只会以“实例反复重启”“显存持续增长”的形式让你看到异常。上线前全局搜一遍代码，把训练相关的stop gradient逻辑处理干净，能省掉很多半夜告警。

4. 一次完整的推理请求是怎么被处理掉的

4.1 请求到响应：实例生命周期完整走读

现在你已经部署好了Endpoint，我们来完整看一次请求的生命周期。

假设客户端发了一个POST请求到 https://your-endpoint.gradient.run/predict，携带一段JSON：

json复制{"texts": ["this movie is great", "the food was terrible"]}

平台收到请求后，发现当前没有活跃实例，会先选择一个匹配GPU类型的节点，拉起容器，执行你的启动逻辑。你的FastAPI服务开始加载模型，加载完成后监听端口，平台健康检查通过，随后把请求转发给你的服务进程。

服务进程返回logits之后，平台把响应回传给客户端，同时记录本次执行时长。接下来进入空闲等待期，如果继续有请求进来，实例复用；如果超过设定的空闲时间没有请求，实例被销毁，GPU资源释放。

这个流程中间最容易被忽略的是“健康检查与请求转发”的时序。平台默认在你设定端口上探测健康状态，如果你的健康检查路径是 /health 而你的FastAPI没有定义这个路由，平台会认为实例有问题。我第一次部署时就栽在这个地方，日志里明明显示应用已经起来了，平台却一直报告unhealthy。

解决方法很简单，加一个健康检查路由：

python复制@app.get("/health")
async def health():
    return {"status": "ok"}

4.2 用curl验证你的推理API

部署完成后，建议先在本地用curl做一次最小验证，别急着上压测工具。下面的命令可以直接复制使用：

bash复制curl -X POST "https://your-endpoint.gradient.run/predict" \
  -H "Content-Type: application/json" \
  -d '{"texts": ["this movie is great"]}'

正常情况下，你会收到类似下面的响应：

json复制{"logits": [[1.221, -2.341, 0.534]]}

如果这一步就报错，不要急着怀疑平台，先把下面几个点排查一遍。首先确认你本机能访问这个公网Endpoint，有些网络环境下公网API被代理拦截。其次确认请求格式和你在FastAPI里定义的请求体完全一致，字段名多一个少一个都会报422。还有就是Endpoint和Worker的状态，如果Worker本身是failed，请求大概率拿不到正常响应。

4.3 从日志到指标：定位问题的排查路线图

无服务器平台的一个特点是，实例销毁后你不能像传统VM那样SSH进去慢慢看。排查问题依赖的是平台提供的日志和指标面板。我把实际排查步骤整理成了一个清单：

• 第一步，看Endpoint的最近请求日志。平台会把每次请求的相关日志展示出来，包括请求开始的实例ID、执行时长、返回状态码。如果看到一堆500，说明你的推理服务本身在报错。
• 第二步，看Worker的实例日志。这里能定位到Python的Traceback，比如模型加载报错、依赖缺失、OOM退出等。
• 第三步，看实例启动记录。如果实例反复“Starting”然后“Stopped”，大概率是镜像启动失败或健康检查失败。
• 第四步，看GPU利用率和显存指标。如果长时间高利用率并且伴随请求超时，大概率是并发设高了或模型推理太慢，需要调大实例数或升级GPU。

有一次我遇到一种诡异的情况：单个请求响应正常，一旦并发一高就大量超时。日志里没有Python报错，实例也没有重启。后来我看了平台的执行时长指标，发现高并发时单请求耗时从200毫秒涨到了6秒，这就不是平台问题，而是我的服务本身没有做并发控制，GPU算力被多个请求争抢。解决方法是给FastAPI加一个信号量，限制同一时刻最多处理几个推理任务，超出的排队，这样单请求耗时能稳住，实例也不会因显存爆掉而崩。

4.4 常见问题速查表

5. 几个让无服务器推理更好用的进阶技巧

5.1 用SDK脚本化部署流程

网页控制台适合学习阶段，真正频繁更新模型时，手点按钮效率太低。我现在的部署流程几乎全脚本化，用官方Python SDK封装了一个部署函数，每次更新模型权重后自动打镜像、push、更新Endpoint配置。

python复制import gradient

client = gradient.Gradient(api_token=os.environ["GRADIENT_API_TOKEN"])
project_id = "your_project_id"

client.deployments.create(
    name="bert-classifier-v1",
    image="registry.gradient.run/your-project-id/bert-classifier:v1-20250121",
    project_id=project_id,
    machine_type="L4",
    container_port=8000,
)

脚本化之后，模型更新变成一个可重复的发布流程，回滚也只是换一个镜像tag再部署一次的事。你可以把这段逻辑接进GitHub Actions，打tag自动触发部署。

5.2 实测压测：先测出真实容量再上生产

部署完以后，我建议做一次简单的并发压测，不要用重型压测工具，直接用Python脚本模拟并发请求就够了：

python复制import asyncio
import aiohttp

async def send_one(session, url, text):
    async with session.post(url, json={"texts": [text]}) as resp:
        return resp.status

async def main():
    url = "https://your-endpoint.gradient.run/predict"
    async with aiohttp.ClientSession() as session:
        tasks = [send_one(session, url, f"sample text {i}") for i in range(20)]
        results = await asyncio.gather(*tasks)
        print(results)

asyncio.run(main())

压测时从1个并发逐步加到5、10、20，观察每个梯度的成功率和响应时间。如果成功率断崖式下跌，基本就是并发参数需要调整。记录下数据后，再结合业务真实流量特点配置实例数和并发数，比拍脑袋靠谱得多。

5.3 别忽略成本监控

无服务器推理的按量付费模式，成本容易失控的地方是“并发实例数设得太大，流量没上来时不会暴露问题”。平台一般会有成本估算面板，通过它可以看到每天不同时段的GPU消耗情况。建议给Endpoint设置最大实例数为真正能承受的天花板，而不要为了保险盲目调大。实测发现，某些框架的服务加载时间特别长，平台会在冷启动阶段就计入计费时长，这类开销是隐性的，只能通过优化镜像启动速度来压缩。

6. 收个尾：一些真实体会

如果你问我对Gradient的无服务器推理整体是什么评价，我的答案是有条件的推荐。条件在于，你的模型镜像能跑通、能忍受冷启动、流量有波动。如果你满足这三点，这个平台能把你在GPU基础设施上的运维成本降得非常低，很多以前需要专门SRE干的活，平台都替你处理掉了。

我个人在实际操作里最深的体会是“别和平台对着干”。无服务器模式的整套逻辑都在逼你把推理服务做轻、做快、做无状态。当你受限于这些约束时，其实也是在倒逼自己的工程水平提升。冷启动不是洪水猛兽，可以通过镜像精简和权重外置来缓解；并发参数不是玄学，压测一跑就有数。最后再分享一个小技巧，部署完Endpoint之后，不要急着删，先把worker的日志导一份存起来，后面排查很多模糊问题的时候，这些日志经常是唯一能用的线索。