开发者状态 · 2026 年 8 月 10 日
FLUX 3 API：官方端点与已公布价格。
一份面向开发者的梳理：已公布的 FLUX 3 Video API、它确切的按秒价格、相关的 FLUX.2 图片参考价，以及那些与服务商无关的接入决策。
| 模型或操作 | 产出 | 已公布价格 | 可用状态 |
|---|---|---|---|
| FLUX 3 Video 完整渲染 | HD 视频 | 每秒 $0.17 | 已正式开放 |
| FLUX 3 Video 完整渲染 | FHD 视频 | 每秒 $0.29 | 已正式开放 |
| FLUX 3 Video 草稿 | 视频草稿 | 每秒 $0.06 | 已正式开放 |
| FLUX 3 Video 续接 | HD 续接片段 | 每秒 $0.43 | 已正式开放 |
| FLUX.2 pro 生成 | 静态图片 | 每张 $0.03 | 可用 |
| FLUX.2 pro 改写 | 改写后的静态图片 | 每张 $0.045 | 可用 |
| FLUX.2 klein 4B | 静态图片 | 每张 $0.014 | 可用 |
| FLUX.2 klein 9B | 静态图片 | 每张 $0.015 | 可用 |
| FLUX.2 flex | 静态图片 | 每张 $0.05 | 可用 |
| FLUX.2 max | 静态图片 | 每张 $0.07 | 可用 |
今天的 FLUX 3 API 包含什么
Black Forest Labs 的生产 API schema 里有一条 FLUX 3 Video 路由。截至 2026 年 8 月 10 日，这个端点就是 FLUX 3 系列具体、且已正式开放的开发者接口。团队可以按已公布的每秒价格和可选的分辨率或草稿模式来规划视频负载。视频续接单独计价，HD 续接每秒 $0.43。
同一份已公布的 schema 里，并没有单独的 FLUX 3 静态图路由。一个多模态系列的发布，并不定义未见文档的请求字段、标识符、限制或价格。开发者应当把官方 schema 当作契约，把静态图 API 的调研与 Video 接口分开。
文档和代码也应该保持这个区分。公开的技术写作，应该把每一个价格和能力都挂到它确切对应的产品上。接入代码应该把产品标识符和能力放在数据里，而不是在路由和组件里到处按系列的营销名字做分支判断。
接入之前先算清视频成本
按秒计价让时长成为第一等的产品控件。一段十秒的完整渲染，HD 是 $1.70，FHD 是 $2.90，这还不算重试和多个版本。十秒的草稿是 $0.60，可以用来在付费跑完整渲染前验证运动或构图。把一段 HD 结果续接十秒，按已公布的续接价是 $4.30。
这些例子只是简单乘法，不含额外的服务商费用。真实的产品还应该为废弃的草稿、API 失败、存储、分发、内容审核和支付处理留出预算，并在请求开始前就把分辨率、时长以及由此产生的积分或金额扣费讲清楚。
在产品边界上，视频与静态图应该保持为两种任务类型。时长、续接、帧率和分辨率属于视频；画面比例、参考图改写和交付的图片字节属于静态图。把两者塞进一个松散的请求结构里，会让校验、计价、历史记录和错误处理都更难推理。
当前的图片 API 路径
FLUX.2 pro 公布的价格是生成每张 $0.03、改写每张 $0.045。一个典型的异步图片接入流程是：带 API key 提交一个产品特定的请求，拿到标识符和轮询地址，反复查询直到任务就绪，然后在临时输出链接过期前把结果下载下来。可靠的服务会存自己的产出，而不是把厂商链接当成永久交付。
在积分制的产品层，服务商成本可以映射到一个稳定的用户单位。请求在开始前应先校验身份、可用余额、提示词长度、输入大小和频率限制。持久化的生成记录和积分扣费，应当在后台执行开始之前就创建好。如果请求失败，由一条冲抵账目把等额积分退回。
这套模式把产品记账和 API 传输方式隔离开。同步 JSON、异步轮询、base64 输出和临时链接，最后都能收敛到同一个与服务商无关的结果：图片字节、内容类型、一个持久的任务状态，以及一条可追溯的积分事件。
为一个未知端点设计服务商层
FLUX 3 图片请求最终长什么样还不知道，所以应用应该依赖尽可能小的稳定领域输入：提示词、画面比例、可选的图片字节，以及一个模型键。服务商适配器负责把这份输入翻译成厂商请求，并返回图片字节和内容类型。业务路由不需要知道服务商的 URL 或凭证名。
模型注册表把模型键映射到服务商、厂商模型 ID、积分价格、能力和可用状态。加入一个新发布的模型，就变成一次数据添加；只有当现有适配器表达不了它时，才需要新写适配器。界面和 API 路由不会因此长出「如果是 FLUX 3 就多传这个字段」之类散落各处的条件判断。
这条边界也保住了跨托管平台的可移植性。Cloudflare 的数据库、对象存储和环境变量访问，应该收在一个平台模块背后。换成 Node 适配器和 PostgreSQL 时，不应该需要重写生成策略或页面组件。
发布当天的核验清单
在接入一个号称是 FLUX 3 Image 的端点之前，先核实来源、确切的模型 ID、认证方式、请求内容类型、支持的比例或尺寸、输入图片限制、输出表示形式、轮询行为、错误结构、频率限制、价格和条款。确认它的开放状态是预览、限量测试，还是正式开放。
跑一批有代表性的需求，而不是一条展示用的提示词。测量指令遵循、改写的保真度、文字渲染、延迟分位、失败行为和成本。如果服务商返回的是临时链接，立刻把输出字节下载下来。确认重试不会造成重复扣费或重复任务。
最后，用同一份核实过的记录，去更新公开状态、引擎披露、价格假设和对比表。如果端点已经变了，站点却还在描述旧模型，那这次上线就不算完成。
等待期间开发者可以做什么
在不猜测未来标识符的前提下，把产品注册表和服务商接口先建起来。把提示词、画面比例、与服务商无关的任务状态和积分事件，存进持久化结构里。把轮询、重试、认证和临时链接处理都关在适配器内部。准备好能反映真实产品需求的评估用例。
视频方面，把 FLUX 3 Video 明确的按秒经济性建模进去，并有意识地使用草稿生成。静态图调研方面，把已公布的 FLUX.2 参考价挂在它们确切对应的产品上。自建部署方面，不要假设一个托管 API 的发布意味着权重可以下载。
这些准备能让将来的 API 变更影响更小，同时保持当前行为准确。它比对着一个尚未公布的端点名或 schema 写代码有价值得多。