Rendi：把 FFmpeg 原样塞进云端 API，不搞 DSL、不收隐藏编码费

FFmpeg 是视频处理的事实标准，但它也是出名的难伺候——本地装一遍编解码器是噩梦，serverless 函数（Vercel/Lambda）体积小、超时短，根本跑不动重编码。Rendi 把 FFmpeg 做成一个云 API：你不用装任何东西，直接 POST 一条原生 FFmpeg 命令，轮询拿结果。本文基于其官网与定价页，分析它的机制与定价口径。

一、背景：FFmpeg 上云的两种路线

视频处理上云已经是明确趋势，但多数方案选择”包一层自己的 DSL”——让你学一套新的参数语言，背后再翻译成 FFmpeg。这对开发者是额外学习成本，也是迁移负担。Rendi 反其道而行：它接受的就是你在终端里敲的那条原生 FFmpeg 命令。官网原话：“Yes, these are regular FFmpeg commands that you can run anywhere.” 这意味着迁移成本几乎为零——本地能跑的命令，丢给它的 REST API 一样能跑。

二、它是什么

工作流很简单：

1. 把 FFmpeg 命令作为 POST 请求发到 Rendi 的 REST API；
2. 轮询（或等 webhook）拿结果；
3. 输入输出文件通过存储/URL 传递。

它还提供 MCP Server（claude mcp add --transport http rendi https://www.rendi.dev/docs/mcp），让 Claude Code、Codex、Cursor、Gemini CLI 等 Agent 直接调用——你对 Agent 说”把音频抽成 MP3""生成 10 张缩略图""烧录 SRT 字幕”，它就去调 Rendi。同时兼容 Make、Zapier、n8n、Supabase 等自动化平台。

三、关键机制：为什么它比 Lambda 快

官网强调它和普通云函数的差异：

• 预留机器、无冷启动：“We keep reserve machines up so there is no cold start”；
• 高 CPU/内存实例：用 AMD 处理器，单条命令最多 32 vCPU，官方称”Your commands run faster than on Lambda or Cloud Functions”；
• 支持 20 分钟以上的重任务（Free 档限 1 分钟、Pro 档可到不限）；
• 99.9% 可用性承诺；
• Chained commands：多条 FFmpeg 命令批量提交，后续命令可依赖前一条输出，复用系统与网络资源，比逐条跑更省。

四、关键数据：定价怎么算

官网定价（已核实原文）：

几个关键口径：

• “处理量”怎么算：官方定义为输入文件与输出文件大小之和。比如处理一个 1GB 输入、产出 0.5GB 输出，计 1.5 GB 处理量；
• Pro 低至 $0.10/GB 处理量；
• 无出口/入口流量费，无按编码次数、时长、分辨率计价的特殊单位——这是它主打的”透明”；
• 免费档要绑信用卡并预授权 $5：官方说明这是为了身份验证防滥用，验证通过后 $5 会退还。

Koala 在周报里提到”Amazon 和 IKEA 每天用它处理数千个视频”——这个说法未在官网首页或定价页出现，应视为周报口径，选型时不要把它当作已核实的客户背书。

五、官方未明说的局限与口径偏差

1. 纯 API 形态，无终端用户界面：Koala 点得准——它更适合自动化工作流集成，不适合直接面向 C 端用户；
2. 免费档限制很死：单命令 1 分钟、每分钟 4 条命令、50GB 月额度，只能试水；
3. “无隐藏费用”不等于便宜：重编码大视频时，处理量（输入+输出都算）会快速累计，超出 Pro 250GB 后的计费需要看完整价目表；
4. 数据经过第三方：视频要上传到 Rendi 存储再处理，敏感内容要评估数据合规；
5. 99.9% 是承诺而非 SLA：真正的可用性赔偿在 Enterprise 档才写进合同。

六、适用 / 不适用场景

适合：

• 在 Vercel/Lambda 等跑不动 FFmpeg 的环境里，需要程序化转码/截帧/抽音频的自动化流水线；
• 用 n8n/Zapier/Make 搭视频自动化、不想自己运维转码服务器的团队；
• 想让 AI Agent 通过 MCP 直接调 FFmpeg 的人。

不适合：

• 需要给终端用户做”上传即转码”产品的重度场景（需 Enterprise 谈）；
• 对数据驻留有强合规要求、不允许视频出自己服务器的场景；
• 偶发、低频手动处理（本地 FFmpeg 或桌面工具更划算）。

七、客观分析：优势与局限

优势：

1. 原生 FFmpeg 命令，零迁移成本——这是它对开发者最友好的点；
2. 无冷启动、高 vCPU、长任务，补了 Lambda/函数计算的短板；
3. 定价透明：不按编码/分辨率花活收费，处理量口径清晰；
4. MCP 就绪，契合 Agent 工作流。

局限：

1. 纯 API、无 UI，面向开发者而非终端用户；
2. 超量后成本需仔细测算；
3. 视频要经过第三方存储，敏感数据需评估；
4. 相比自建转码集群，长期重度使用的单位成本未必最优。

八、它意味着什么

Rendi 代表了”重工具云原生化”的一个务实方向：不重新发明 FFmpeg，只把它搬到一个无冷启动、可 API 调用、按处理量透明计费的环境里。在 Vibe Coding 与自动化工作流盛行的今天，连 FFmpeg 这种老牌工具都需要被包装成 Agent 能直接调的 API——Rendi 的 MCP 接入就是这个趋势的缩影。对自动化团队，它省掉了运维转码集群的大麻烦；但它本质是个”被托管的 FFmpeg”，视频要上传出去、重度使用成本要算账，这些边界选型时要先想清楚。

参考来源

• Rendi 官网
• Rendi 定价页
• Koala 项目库条目