重构模型价格表设计以支持灵活计费策略

[sdcb]

📋 背景与现状

当前表设计

Model 表目前只有两个价格相关字段：

• InputTokenPrice1M (decimal(9,5)) - 输入 token 价格（每百万 token）
• OutputTokenPrice1M (decimal(9,5)) - 输出 token 价格（每百万 token）

存在的问题

1. 无法区分成本与售价 - 只有一个价格，无法计算利润
2. 不支持阶梯定价 - 固定价格，无法支持如 Gemini 2.5 Pro 的多档定价
3. 缺少缓存命中价格 - 无法为缓存命中设置更低的价格
4. 不支持混合计费 - 无法表达"成本按 token、售价按次数"的模式
5. 无法表示免费模型 - 0 值语义不明确（是免费还是未设置？）
6. 缺少历史版本管理 - 价格变更无法追溯
7. 单一计价单位 - 只支持按 token，不支持按调用次数、套餐等

🎯 需求概述

需要支持以下计费场景：

1. 成本与售价分离

• 区分成本价格（Cost Price）和消费价格（Consumer Price）
• 支持独立计算利润
• 允许仅存成本价或仅存售价

2. 多维度计费

• 输入 token 价格
• 输出 token 价格
• 缓存命中时的输入 token 价格（通常更便宜）
• 按次调用计费
• 套餐计费

3. 阶梯定价

• 支持固定价格模型（如 GPT-5: 输入 $1.25/M、输出 $10/M）
• 支持两档阶梯（如 Gemini 2.5 Pro: 前 200K 一个价，200K-1M 另一个价，1M 以上第三个价）
• 支持多档阶梯定价

4. 混合计费模式

• 成本按 token 计算，售价按套餐（如 300 次调用）
• 成本按 token 计算，售价按单次调用
• 支持免费模型（成本为 0 或售价为 0）

5. 价格版本管理

• 价格变更需要保留历史记录
• 支持多个价格计划并行（如不同用户组、不同时间段）
• 能够指定生效时间范围

📊 典型使用场景

场景 1: 固定价格模型（如 GPT-5）

• 成本价: 输入 $1.10/M tokens，输出 $9.00/M tokens
• 售价: 输入 $1.25/M tokens，输出 $10.00/M tokens
• 缓存命中: 输入 $0.40/M tokens（成本 $0.30/M）
• 特点: 简单固定价格，区分成本与售价

场景 2: 阶梯定价模型（如 Gemini 2.5 Pro）

• 输入 token:
  • 前 200K: $1.10/M（成本 $0.90/M）
  • 200K-1M: $1.60/M（成本 $1.40/M）
  • 1M 以上: $2.10/M（成本 $1.80/M）
• 输出 token: 同样有 3 个阶梯
• 特点: 多档阶梯定价，前期价格竞争力强，高用量利润更高

场景 3: 套餐计费模型

• 成本: 按实际 token 消耗计算（如 $1.20/M tokens）
• 售价: 按套餐出售（如 $199 包含 300 次调用）
• 特点: 成本与售价计量单位不同，用户更易理解"按次"计费

场景 4: 免费模型

• 情况 A: 对用户完全免费（售价 $0），但平台有成本
• 情况 B: 第三方提供免费 API（成本 $0），平台可选择是否收费
• 特点: 需要明确区分"免费"与"未设置价格"

场景 5: 混合定价（未来扩展）

• 基础 token 费用 + 附加功能费用（如联网搜索、图片生成）
• 不同输入类型不同价格（如文本、图片、音频）

� 面临的挑战

数据建模挑战

1. 灵活性 vs 复杂度 - 如何设计表结构既能支持各种计费场景，又不过度复杂
2. 阶梯边界处理 - 跨阶梯消费的计算逻辑（如用了 250K tokens，如何分段计费）
3. 混合单位 - 成本和售价单位不同时的数据表达
4. 历史数据 - 如何高效查询"某个时间点"的有效价格

业务逻辑挑战

1. 价格计算性能 - 复杂的阶梯计算是否需要缓存
2. 套餐余额管理 - 按次售卖时如何跟踪剩余次数
3. 成本归集 - 一次调用可能涉及多个计费维度（输入、输出、缓存）
4. 利润分析 - 如何高效统计各模型的成本、收入和利润

兼容性挑战

1. 数据迁移 - 现有简单价格数据如何迁移到新结构
2. API 变更 - 价格查询 API 是否需要重构
3. 向后兼容 - 是否需要保留旧的价格字段作为视图/计算字段

用户体验挑战

1. 价格展示 - 阶梯定价如何在前端清晰展示
2. 管理界面 - 管理员配置复杂价格计划的易用性
3. 账单透明 - 用户如何理解自己的消费明细

💡 期望的改进方向

1. 清晰的成本与收入分离 - 便于财务分析和利润计算
2. 灵活的计费维度 - 支持按 token、按次、按套餐等多种方式
3. 完善的价格版本控制 - 价格变更可追溯、可回滚
4. 可扩展的设计 - 未来易于添加新的计费方式（如按时长、按消息数）
5. 高性能查询 - 价格计算不应成为系统瓶颈

� 需要考虑的问题

• 是否所有模型都需要支持所有计费方式？
• 价格精度 decimal(9,5) 是否足够？（当前最多支持到小数点后 5 位）
• 是否需要支持多币种？
• 阶梯定价的"累计用量"如何定义？（按用户？按模型？按时间周期？）
• 套餐过期策略如何处理？
• 是否需要支持"包月无限量"类型的套餐？
• 价格调整是否需要审批流程？

📎 相关资源

• 当前 Model 表 DDL: src/BE/DB/Model.cs (需要查看完整结构)
• 相关计费逻辑: src/BE/Services/ (需要评估影响范围)
• 价格展示前端: src/FE/ (需要同步更新)

---

优先级: 中
预估影响: 数据库、后端计费服务、管理界面、前端价格展示
风险等级: 中高（涉及核心计费逻辑）