AI 模型定价比较：在一个仪表板中查看 Token、图像和视频成本

AI 模型定价比较：在一个仪表板中查看 Token、图像和视频成本

只有当 AI 模型定价比较 与您的产品实际花钱的方式一致时，它才真正有用。静态的 token 价格表只是一个起点。真实的推理成本会随着输入 token、缓存输入、输出 token、图像输出单元、视频秒数、工具调用、重试、回退、失败作业，以及用户实际接受的生成结果百分比而变化。

本指南为开发者、产品团队和采购团队提供了一个实用的仪表板，用于比较跨文本、图像、视频和多提供商 API 路由的 AI 模型定价。真正耐用的指标不是标价最低的请求，而是每个被接受结果的成本。

Flatkey 适合这一工作流，因为它为团队提供一个 API key、一个预付余额、一张发票，以及覆盖 300+ 官方模型和 1,000+ 按次付费工具的共享使用账本。您仍然需要核对官方提供商价格，但在做出路由决策之前，您不必把来自不同供应商账户的每一次实验都进行对账。

快速 AI 模型定价比较框架

在切换提供商、批准更大的模型预算或将生产流量路由到新模型之前，请使用此框架。

成本层	原生定价单位	归一化为	仪表板字段
文本和 agent 调用	输入 token、缓存输入、输出 token、缓存写入、批处理作业、工具调用	每个被接受答案或完成任务的成本	accepted_task_cost_usd
图像生成	提示 token、图像输入、输出图像 token、生成图像、分辨率、被接受图像	每个被接受图像的成本	accepted_image_cost_usd
视频生成	秒数、剪辑、分辨率、队列尝试、失败的异步作业	每个被接受剪辑或被接受剪辑秒数的成本	accepted_clip_cost_usd
多模态工作流	混合文本、文件、图像、视频、工具、重试、回退	每个完成工作流的成本	workflow_cost_usd
采购与治理	密钥、发票、导出、预算、允许列表、审计需求	安全运行该路由的成本	operating_cost_note

高层指标可以很简单：每个被接受结果的成本。工程账本应保持详细，因为成本变化的原因可能是缓存未命中、输出长度变化、重试激增、模型回退，或者用户接受率降低。

为什么标价并不是完整答案

上线后，最低的 token 单价可能会变成最昂贵的路由。一个输入 token 价格较低的模型，如果需要更长的提示、生成更长的答案、错过缓存机会、重试更频繁，或者在过载时回退到更昂贵的路由，仍然可能输掉。

媒体成本让问题更加明显：

• 一个图像模型单次生成看起来很便宜，但如果用户拒绝了很多输出，那么每个被接受图像的成本就会很高。
• 一个视频模型按秒计看起来可负担，但如果用户在保存一个剪辑之前请求多个预览，那么成本就会变高。
• 一个编码或研究 agent 可能有便宜的聊天模型，但工具、浏览器、图像或增强类的旁路调用会很昂贵。
• 直接的提供商账户可能有更低的原始模型价格，但如果采购需要单独的密钥、发票、使用导出和预算控制，那么运营成本会更高。

这就是为什么AI 模型定价比较应当保留原生定价单位，然后将每条路由归一化为被接受结果经济性。

需要检查的当前定价来源

提供商定价经常变化。不要只复制一次费率表就把它当作长期有效。请维护一个来源表，包含官方 URL、检查日期、模型或路由 ID、单位和备注。

提供方或路由	需查看的官方来源	需捕获的定价维度	仪表板说明
OpenAI API	OpenAI API 定价	输入、缓存输入、输出、批处理模式、微调、图像、音频、视频、区域处理	确认准确的模型 ID、服务模式，以及是否适用批量定价。
Anthropic Claude API	Claude 定价	输入、输出、提示缓存、批量定价、模型系列、上下文窗口	缓存写入和缓存命中行为会实质性改变重复代理的经济性。
Google Gemini API	Gemini API 定价	免费或付费层级、输入、输出、缓存、批处理模式、优先级/灵活选项、搜索 grounding、媒体	捕获模型系列和服务模式，尤其是在启用搜索或 grounding 时。
DeepSeek API	DeepSeek API 定价	输入缓存未命中、输入缓存命中、输出、高峰或非高峰时段、模型别名	如果定价因时间窗口或缓存命中而变化，请求日志需要时间戳和缓存状态。
Alibaba Model Studio / Qwen	Alibaba Model Studio 模型	模型系列、模态、区域、token 或媒体单位、控制台模型 ID	在将 Qwen 路由计入预算之前，请检查准确的模型详情页和区域。
Flatkey multi-provider API	Flatkey 定价 和 Flatkey 模型	统一模型路由、单一余额、按请求账本、工具调用、发票、子密钥预算	用于路由可用性、多提供方治理以及基于账本的比较。

对于每一行定价记录，都要存储三个必需字段：检查日期、模型或路由 ID 和 单位。每 token 美元值不能直接与每图像美元值、每视频秒美元值或按工具调用付费的数值进行比较。

仪表板架构

从一个请求账本开始。不要把文本、图像、视频和工具使用拆分到彼此断开的财务系统中。

{
  "request_id": "req_01j...",
  "workspace_id": "wk_product",
  "environment": "production",
  "feature": "creative_generator",
  "customer_id": "cus_123",
  "provider": "flatkey",
  "model_or_route": "example-route",
  "route_type": "image",
  "billing_unit": "output_image",
  "input_tokens": 1240,
  "output_tokens": 0,
  "cache_read_tokens": 0,
  "cache_write_tokens": 0,
  "tool_calls": 0,
  "images_generated": 4,
  "images_accepted": 1,
  "video_seconds_generated": 0,
  "video_seconds_accepted": 0,
  "retry_count": 1,
  "fallback_count": 0,
  "provider_cost_usd": 0.16,
  "gateway_or_platform_cost_usd": 0.00,
  "total_cost_usd": 0.16,
  "accepted_result": true,
  "latency_ms": 11800,
  "pricing_source_url": "https://provider.example/pricing",
  "pricing_checked_at": "2026-10-12"
}

这个架构让财务有一个可以对账的数字，也让工程团队拥有解释为什么某条模型路由变得更便宜或更昂贵所需的字段。

要使用的成本公式

文本与代理调用

对于文本路由，先计算原始请求成本：

raw_text_cost =
  input_tokens * input_rate
+ output_tokens * output_rate
+ cache_write_tokens * cache_write_rate
+ cache_read_tokens * cache_read_rate
+ tool_call_costs
+ retry_and_fallback_costs

然后将其归一化：

accepted_task_cost =
  sum(raw_text_cost for all attempts, retries, and fallbacks)
/ accepted_tasks

如果某个请求失败，用户从未得到答案，也不要把它隐藏起来。单独跟踪失败调用成本。当定价仪表板把失败、重试和回退流量可视化时，它才会真正有用。

图像生成

图像 API 定价并非单一通用单位。有些模型公开提示 token 和图像输出 token。另一些则公开按图像、分辨率、编辑或提供方特定单位计费。保留原生单位，并归一化到已接受图像：

accepted_image_cost =
  (prompt_cost + input_image_cost + output_image_cost + retry_cost)
/ accepted_images

分别跟踪 images_generated 和 images_accepted。一个每个已接受图像会生成四张图像的路由，不应与用户 1 选 1 接受的路由直接比较。

视频生成

视频定价需要时长、分辨率和异步作业状态。一个视频调用可能被排队、失败、取消、重新生成，或在之后才被接受。

accepted_clip_cost =
  sum(video_seconds_generated * per_second_rate by resolution)
+ retry_cost
+ fallback_cost
+ storage_or_tool_costs

对于产品决策，还要跟踪：

• accepted_clip_seconds
• preview_count
• regeneration_count
• failed_job_count
• time_to_first_preview_ms
• time_to_accepted_clip_ms

对于视频模型来说，按列出的单位计算可能更便宜，但如果用户重新生成的频率高出一倍，它对产品来说仍然更差。

比较直接的提供商账户与多提供商 API

当某一类模型就能处理你大部分工作负载，而且单独计费也容易管理时，直接的提供商账户就足够了。当你需要持续进行模型比较、故障切换路由，或者在多个提供商之间使用同一本总账时，多提供商 API 就会更有用。

决策点	在以下情况下，直接的提供商账户可能就足够了...	在以下情况下，多提供商 API 会有帮助...
模型选择	一个提供商在大多数任务中胜出。	不同工作负载需要 OpenAI、Claude、Gemini、DeepSeek、Qwen、图像、视频和工具路由。
工程投入	你的代码已经在调用一个提供商，而且很少变更。	你希望获得与 OpenAI 兼容的路由，并减少集成重写。
成本控制	一张账单和一个仪表板就能接受。	你需要子密钥预算、模型允许名单以及按请求导出的用量数据。
采购	分别签署的合同是可以管理的。	重复合同、闲置席位和分散的提供商密钥会拖慢团队。
可靠性	偶尔出现的提供商中断是可以接受的。	你需要故障切换策略，以及用于重试和故障切换成本的共享总账。
Agent 工作流	应用只调用文本模型。	Agent 会调用模型、网页搜索、浏览器操作、增强工具、图像和视频。

Flatkey 正是为第二列而构建：一个 API 密钥、一个余额、一张账单，以及覆盖多个官方模型和工具路由的请求总账。这并不取代官方提供商定价。它只是为你的团队提供一个统一位置，用于路由、计量、治理和核对这些成本。关于网关费用和运营成本视角，请参见 AI 网关定价。

五个工作负载示例

1. 客服聊天

客服聊天通常具有中等输入、较短输出和高流量。请比较：

• 系统提示和政策文本的提示缓存命中率。
• 按回答类型划分的输出 token 预算。
• 升级到更强模型的比例。
• 按已解决会话计算的成本，而不只是按消息计算的成本。

对于这个工作负载，如果更便宜的快速模型能保持较高的解决质量，它就可能胜出。如果更便宜的模型增加了转接或编辑率，那么表面上的 token 节省就会消失。

2. 编码 Agent

编码 Agent 往往具有较大的上下文、工具调用、长输出以及多次重试。请比较：

• 仓库搜索或文件读取后的上下文大小。
• 可缓存的项目说明。
• 每个已接受任务的工具调用次数。
• 来自负载过高路由的重试浪费。
• 每个合并变更或已接受补丁的成本。

这就是AI 模型定价比较需要总账的地方。一次 Agent 运行可能包括模型调用、工具调用、故障切换调用和失败尝试。

3. RAG 回答生成

RAG 工作负载主要由检索到的上下文和回答长度决定。请比较：

• 平均检索 token 数。
• 稳定提示前缀占比。
• 重复文档的缓存行为。
• 引用或事实依据成本。
• 事实性评估器通过率。

不要只因为某个模型的输入 token 便宜就选择它。如果它需要两倍上下文，或者生成的答案无法通过评估，那么已接受答案的成本可能更高。如果这是主要的迁移问题，请使用 如何在切换提供商之前比较 AI 模型价格 中更深入的工作表。

4. 批量分类

批量分类通常可以容忍延迟结果。请比较：

• 提供商是否有批处理、灵活或延迟处理层级。
• 最大批量大小和完成窗口。
• 错误重放成本。
• 输出 schema 验证通过率。
• 每一行已接受记录的总成本。

如果提供商给出更低的批处理价格，那么只有当你的工作流可以等待，而且重试流程足够干净时，这些节省才会真正生效。

5. 图像和视频生成

图像和视频 API 很少能适配只看 token 的电子表格。请比较：

• 输出单位：图像、秒、片段、分辨率、token 或积分。
• 失败生成的计费规则。
• 编辑和重新生成率。
• 人工批准率。
• 每个已接受创意资产的成本。

对于媒体流水线，请把 token 模型和生成模型分别放在不同的工作表标签页中，然后汇总到已接受工作流成本。因为单位经济性差异太大，不适合合并成一行。

七步定价比较工作流

1. 冻结工作负载。 选择一个真实任务族，例如支持答复、编码代理补丁、RAG 答复、批量分类、图像生成或视频生成。
2. 收集当前官方价格。 使用提供商定价页面、Flatkey 模型页面以及已核对的日期。避免使用没有源 URL 的复制费率卡。
3. 重放具有代表性的流量。 在各条路由上使用相同的提示、输入、输出上限、工具策略和验证器。
4. 记录每一个可计费单位。 捕获输入 tokens、缓存 tokens、输出 tokens、媒体单元、工具调用、重试尝试、错误和状态。
5. 对已接受结果进行评分。 使用人工审核、自动化验证器或特定任务的通过/失败检查。
6. 计算有效成本。 用总路由成本除以已接受结果，而不是总请求数。
7. 添加运营控制。 确定获胜路由是否也满足预算上限、发票需求、关键治理、数据保留和事件回退。

结果是一种定价决策，工程、产品和采购都可以为其背书。

最低仪表板视图

路由比较

在一张表中展示文本、图像和视频路由。

路由	原生单位	原生成本字段	验收字段	标准化 KPI
文本模型	Tokens	输入、输出、缓存 tokens	已接受答案	每个已接受答案的成本
编码代理	Tokens 加工具	Token 和工具成本	已合并 PR、已解决工单、已完成任务	每个已完成工作流的成本
图像模型	图像或 token 单元	生成的图像、输出图像 tokens	已接受图像	每张已接受图像的成本
视频模型	秒、片段或提供商单元	按分辨率生成的秒数	已接受片段	每个已接受片段的成本

功能预算

按功能分组，而不仅仅按提供商分组。对于产品团队来说，这比供应商发票更有用，因为它能显示是注册引导、聊天、创意生成、搜索还是导出在驱动支出。

建议列：

• feature
• route_type
• requests
• accepted_results
• acceptance_rate
• total_cost_usd
• cost_per_accepted_result
• p95_latency_ms
• fallback_rate
• retry_rate

提供商和模型漂移

每个提供商都会更改模型可用性、定价和生命周期状态。存储：

• 定价来源 URL。
• 定价核对日期。
• 模型版本或路由 ID。
• 单位类型。
• 缓存策略。
• 批量折扣策略（如果使用）。
• 弃用或生命周期说明。

这样可以让 ai model pricing comparison 在上线后仍然有用，而不只是用于初始模型选择。

利润护栏

为每个 AI 功能添加一个简单的利润规则：

max_ai_cost_per_customer_action =
  expected_revenue_per_action * target_ai_cost_percentage

示例：

如果一次客户操作带来 $0.40 的毛利
且 AI 成本应保持在 20% 以下，
那么路由预算就是每个已接受结果 $0.08。

这能让模型选择与业务保持一致，而不是依赖抽象的基准分数。

常见错误

错误	替代做法
只比较输入 token 费率	比较输入、缓存输入、输出、媒体、工具、重试和已接受结果。
将文本、图像、视频和工具混为一个单位	保留原生单位，然后将每条路由标准化为已接受结果成本。
忽视提示缓存	衡量稳定的提示前缀和缓存命中率。
忽视批处理资格	将低延迟敏感工作负载与离线工作负载分开。
相信过时的复制价格表	存储官方来源 URL 和核对日期。
把网关成本只当作加价	包含治理、故障切换、使用导出、发票和工程时间。
挑选最便宜的请求	选择满足质量和可靠性要求的最便宜已接受结果。

常见问题

比较 AI 模型定价的最佳方式是什么？

比较 AI 模型定价的最佳方式是保留每个提供商的原生计费单位，然后将每条路由标准化为每个已接受结果的成本。对于文本，这可能是每个已接受答案的成本。对于图像，使用每张已接受图像的成本。对于视频，使用每个已接受片段或已接受片段秒的成本。

AI 模型比较图表应包含什么？

AI 模型比较图表应包含模型或路由 ID、提供商、定价来源 URL、核对日期、输入 tokens、缓存输入、输出 tokens、媒体单元、工具调用、重试率、回退率、接受率、延迟和每个已接受结果的成本。

定价表应包含准确的提供商价格吗？

在内部工作表中使用精确价格，但要在每一行旁边保存来源 URL 和检查日期。公开的静态文章应避免使用没有来源的复制费率表，因为供应商价格、模型名称、折扣和生命周期状态都可能快速变化。

如何比较 token 成本与图像和视频成本？

不要强行把每条路径都转换为 token。保留账本中的原生单位，然后添加规范化字段，例如 accepted_task_cost_usd、accepted_image_cost_usd 和 accepted_clip_cost_usd。

Flatkey 在 AI 模型定价比较中有什么帮助？

当你希望在多个模型和工具路径中使用一个 key、一个余额、一张发票和一份用量账本时，Flatkey 就很有帮助。这让你无需先协调各个独立的供应商账户，就能更轻松地比较文本、图像、视频和代理成本。

应多久重新检查一次定价？

在每次重大的路由变更、合同审查或预算预测之前，都应重新检查定价。对于快速变化的生产工作负载，应每周刷新关键路径价格，并在供应商发布、重命名、弃用或重新定价你正在使用的模型后立即更新。

最终结论

AI 模型定价比较并不只是更美观的价格表。它是一个用于模型选择的操作系统。

保留供应商单位。加入接受情况跟踪。将每条路径规范化为每个已接受结果的成本。然后选择能提升产品利润率、可靠性和治理效果的路径，而不是单看起来最便宜的路径。

借助 Flatkey，这种比较可以建立在一个 key、一个余额和一份账本之上，因此开发者、产品团队和采购团队可以从零散的供应商账单转向按路由级别做成本决策。