用 Removal.AI API 批量去除图片背景

Removal.AI 提供的是一个背景移除 API：把一张图片交给它，它返回主体保留、背景透明的结果图。适合需要在自己的应用或工作流里批量处理商品图、人像图、素材图的开发者与团队，比如电商后台自动抠图、设计工具内置去背景、媒体库批量清理。它不要求你懂图像分割算法，调用方式就是一次 HTTP 请求。如果你更想先在网页上手动处理几张图看看效果，可以先用 Removal.AI 的在线工具试一下，再决定是否接入 API。

下面按「准备工作 → 操作步骤 → 完整示例 → 注意事项」的顺序讲清楚怎么把它跑通。文中涉及的免费额度、速率上限、价格等信息都可能调整，实际以官网当前公布的信息为准。

准备工作

接入之前需要确认三件事：账号与 API Key、调用方式、以及图片本身的规格。

账号与 API Key

你需要一个 Removal.AI 账号，登录后在账号相关页面获取 API Key。这个 Key 在请求里通过请求头传递，字段名是 Rm-Token。默认情况下，每个账号每月有 10 个免费预览额度（free preview credits），额度用完后需要按官网的定价方案购买。免费额度的具体数值与计费方式请以官网当前信息为准，不要按本文的数字做预算。

API Key 等同于账号凭证，不要写进前端代码、不要提交到公开仓库。服务端调用时从环境变量或密钥管理服务读取。

调用方式

接口是一个标准的 HTTP POST 端点，接受 multipart/form-data 表单。这意味着任何能发 HTTP 请求的语言都能用：Python、PHP、C#、JavaScript、Node.js 都有现成的写法，官方也提供了这几种语言的示例代码。你不需要安装特定的 SDK，用语言自带的 HTTP 客户端即可。

请求地址为：

https://api.removal.ai/3.0/remove

图片规格

支持的分辨率上限是 25 百万像素（25 megapixels）。这个上限同时影响两件事：超过上限的图片无法处理；分辨率越高，单位时间内能处理的张数越少（见后文速率部分）。上传前建议先按实际用途压缩，商品图、头像这类场景通常不需要原始大图。

操作步骤

第一步：准备请求头与表单字段

一次最小可用的请求包含三部分：

• 请求头：Rm-Token: YOUR_API_KEY，把 YOUR_API_KEY 换成你自己的 Key。
• 图片来源：二选一。直接上传文件用 image_file 字段；或者用 URL 引用一张已经在线的图片。
• 输出方式：通过 get_file 参数决定返回的是图片文件本身，还是图片的引用地址 / Base64 编码数据。

最简形式就是官方给出的这条命令，用 curl 直接跑：

curl -L -X POST "https://api.removal.ai/3.0/remove" \
  -H "Rm-Token: YOUR_API_KEY" \
  -F "image_file=@path/to/image.jpg" \
  -F "get_file=1" \
  -o transparent_image.png

逐段解释：-X POST 指定方法；-H 带上鉴权头；两个 -F 分别传图片文件和输出开关；-o 把响应体直接写进本地文件。-L 让 curl 跟随重定向，避免因为跳转拿到空响应。

第二步：选择图片来源

两种输入方式各有适用场景：

• 直接上传：用 image_file 字段以 multipart 形式提交本地文件。适合图片在你自己服务器上、或者需要在上传前做压缩与格式转换的场景。
• URL 引用：把图片的公网地址交给接口，由服务端去拉取。适合图片已经在对象存储或 CDN 上、不想多一次下载再上传的场景。注意这个地址必须是服务端可访问的，内网地址或需要登录才能打开的链接不行。

第三步：选择输出方式

输出有两种形态：

• 文件流：设置 get_file=1，响应体就是处理后的图片二进制，可以直接存成 PNG 文件。适合服务端落盘、再转存到对象存储的流程。
• 引用地址或 Base64：不取文件流时，接口返回图片的引用 URL，或者 Base64 编码后的数据。适合把结果直接嵌进 JSON 响应、或者交给前端展示的场景。Base64 会让响应体变大，注意别把大图塞进日志。

具体参数名与可选值以官方参数文档为准，不同版本可能新增字段。请求发出前建议对照参数参考表核一遍，尤其是需要调整输出尺寸、格式的时候。

第四步：处理响应与错误

成功时按你选择的输出方式拿到图片或数据。失败时要区分几类情况：鉴权失败（Key 错误或额度耗尽）、图片不合规（格式不支持、超过 25 MP）、网络或服务端临时错误。对临时错误做有限次重试是合理的，对鉴权与参数错误重试没有意义，应该直接报出来。

批量处理时，建议把每张图的原始标识（文件名或业务 ID）与结果一起记录，方便失败后只补跑失败的那部分，而不是整批重来。

一个完整示例

下面用 Python 走一遍从单张到批量的完整流程。示例只用标准库与常见的 requests，不依赖特定 SDK。

单张处理

import os
import requests

API_URL = "https://api.removal.ai/3.0/remove"
API_KEY = os.environ["REMOVAL_AI_KEY"]

with open("input.jpg", "rb") as f:
    resp = requests.post(
        API_URL,
        headers={"Rm-Token": API_KEY},
        files={"image_file": ("input.jpg", f, "image/jpeg")},
        data={"get_file": "1"},
        timeout=60,
    )

resp.raise_for_status()
with open("transparent_image.png", "wb") as out:
    out.write(resp.content)
print("saved", len(resp.content), "bytes")

几个要点：Key 从环境变量读取，不硬编码；files 里显式给出文件名与 MIME 类型，避免服务端判断格式出错；timeout 必须设，大图处理时间会明显变长；raise_for_status() 让非 2xx 直接抛异常，而不是把错误页写进 PNG。

批量处理

批量时不要无脑并发。前面说过，实际吞吐取决于图片像素数和你的网络带宽，开太多并发只会互相挤占。一个稳妥的做法是限制并发数，并对失败项单独记录：

import os
import time
import requests
from concurrent.futures import ThreadPoolExecutor

API_URL = "https://api.removal.ai/3.0/remove"
API_KEY = os.environ["REMOVAL_AI_KEY"]

def remove_bg(path):
    try:
        with open(path, "rb") as f:
            resp = requests.post(
                API_URL,
                headers={"Rm-Token": API_KEY},
                files={"image_file": (os.path.basename(path), f, "image/jpeg")},
                data={"get_file": "1"},
                timeout=120,
            )
        resp.raise_for_status()
        out_path = os.path.splitext(path)[0] + "_nobg.png"
        with open(out_path, "wb") as out:
            out.write(resp.content)
        return (path, out_path, None)
    except Exception as e:
        return (path, None, str(e))

files = ["a.jpg", "b.jpg", "c.jpg"]
failures = []
with ThreadPoolExecutor(max_workers=4) as pool:
    for src, dst, err in pool.map(remove_bg, files):
        if err:
            failures.append((src, err))
        else:
            print("ok", src, "->", dst)

for src, err in failures:
    print("failed", src, err)

并发数从 4 起步，观察耗时与错误率再调整。如果图片普遍在 10 MP 以上，单张处理时间会拉长，并发开大反而容易触发超时。

用 URL 输入

如果图片已经在公网可访问的位置，可以省掉上传这一步，直接把地址交给接口。具体字段名以参数文档为准，思路是把图片来源从文件换成 URL，其余鉴权与输出参数不变。这样做的代价是服务端拉图的时间也算进请求耗时里，图片托管方响应慢会直接拖慢整体。

注意事项

速率上限按像素折算

接口的理论上限是每分钟 500 张图，但实际能跑多少，主要取决于图片的百万像素数和你的网络速度。像素越高，单张占用的处理资源越多，每分钟能过的张数就越少。按素材给出的折算关系：

输入尺寸	百万像素	有效速率
625 × 400	1 MP	500 张 / 分钟
1200 × 800	1 MP	500 张 / 分钟
1600 × 1200	2 MP	250 张 / 分钟
2500 × 1600	4 MP	125 张 / 分钟
4000 × 2500	10 MP	50 张 / 分钟
6250 × 4000	25 MP	20 张 / 分钟

规律很直接：速率大致与像素数成反比。所以批量任务开始前，先按用途把图片压到够用的尺寸，是最有效的提速手段。另外这张表是理论值，真实环境里网络带宽往往是更早出现的瓶颈。

分辨率上限

单张图片最高支持 25 百万像素。超过这个尺寸的图需要先缩放或裁切，否则请求会失败。反过来，如果业务只需要小图（比如列表缩略图），没必要传原图，白白消耗处理时间。

免费额度与计费

默认每月 10 个免费预览额度，超出后按官网定价方案计费。额度、价格、套餐内容都可能调整，做成本估算前请查官网当前信息。批量任务尤其要注意：一次跑几千张图，额度消耗会非常快，建议先用少量样本验证效果与参数，再放开跑。

错误排查

社区反馈的罕见错误案例会被持续整理，遇到不常见的报错时，先确认三件事：Key 是否有效且额度未耗尽、图片是否在 25 MP 以内且格式受支持、请求是否按 multipart 正确构造。这三点能覆盖大部分失败情况。剩下的再对照参数文档逐项核对。

安全与合规

API Key 只放在服务端；处理用户上传的图片时，注意你所在地区对个人图像数据的处理要求，不要把结果图长期公开可访问。图片通过 URL 方式提交时，确认该地址不包含签名参数等敏感信息，避免被写进日志。