定价模型选错：一场财报季让你的量化账户归零
一个常见的故事：开发者花了三周搭建趋势跟踪策略，回测年化 23%，夏普 1.8。财报季一来，策略崩溃——不是因为因子失效，而是数据账单先爆了。
每天 8 万次 API 调用，月末账单 340 美元。原本预期 500 美元的月利润，变成亏损。这是大多数量化个人投资者在数据成本上踩过的第一个坑：把定价模型当次要变量，等到账单来才反应过来。
这不是个例。数据源定价模型的信息不对称程度，远超大多数人的预估。免费层能跑什么策略？按月订阅划算还是按量计费划算？高频交易者和日线级策略玩家的成本结构完全不同——但大多数内容把这两类人放在一起讨论。
本文拆解量化数据源的三种主流定价模式：按次计费（Pay-per-call）、按月订阅（Subscription）、用量协商（Volume-tier），给出用量估算方法论和一个可直接使用的成本计算框架。文章结尾的对比表会覆盖当前主流数据提供商的定价结构，但先说清楚一个前提：定价模式的选择，本质上是对你策略频率和资金规模的匹配，不是越贵越好，也不是免费最划算。
一、按次计费：最透明的模型，也是最危险的模型
1.1 什么是按次计费
按次计费（Pay-per-call / Pay-as-you-go）意味着你为每一个 API 请求付钱，没有月费，没有年费，没有最低消费。你用多少，付多少。
主流实现方式有两种：
REST API 调用：你主动发起请求获取数据，典型场景是历史数据查询、批量标的拉取、单次实时价格。计费单元是一次 HTTP 请求，不管返回数据量多少。
WebSocket 流式订阅：你连接一个持久通道，数据持续推送。大多数提供商按"连接分钟数"或"订阅小时数"计费，但部分采用混合模式——连接免费，按推送消息数计费。
按次计费的吸引力在于理论上没有浪费：你不用为不需要的额度付费。但这个逻辑成立的前提是你能准确预测用量——而这恰恰是大多数量化开发者做不到的事情。
1.2 按次计费的用量结构：你的策略实际消耗多少？
理解按次计费的真实成本，先要搞清楚量化策略的调用模式。
一个日内趋势策略的调用链：
启动 → 拉取 50 个标的的当日日线数据 → 50 次调用
↓
每 5 分钟 → 刷新所有标的现价 → 50 次调用 × 12次/小时 × 6小时 = 3600 次
↓
触发信号 → 拉取订单簿深度（10档） → 1次 × N次触发
↓
收盘 → 存储当日数据到本地 → 0次（本地操作）
粗算结果：一个中等活跃的日内策略，单日 API 调用量在 4000-8000 次之间。每月按 22 个交易日计算，就是 8.8 万至 17.6 万次。
但这个数字会因几个因素剧烈波动：
| 影响因素 | 低消耗场景 | 高消耗场景 |
|---|---|---|
| 标的数量 | 5 只股票 | 100 只股票 |
| 刷新频率 | 15 分钟一次 | 5 秒一次 |
| 数据类型 | 仅日线收盘 | tick + depth 实时 |
| 持仓周期 | 日线级（一天一次） | 剥头皮（一天百次） |
| 月调用量估算 | ~3,000 次/月 | ~150,000 次/月 |
按次计费最危险的场景：策略在回测期和实盘期的调用量差异。回测时你一次性拉取历史数据，看起来成本低。但实盘时持续的实时监控，会让你的月调用量比回测期高出 10-50 倍。
1.3 成本对照：按次计费适合谁？
按次计费适合三类场景：
第一类：研究和回测阶段。你需要拉大量历史数据，调用量集中在短期内。一次性拉取 10 年日线数据可能产生 5000-10000 次调用，但这是一次性成本。
第二类：低频策略。日线级或周线级策略，每天调用量不超过 500 次。按次计费的弹性优势明显——你不需要为永远用不完的月额度付固定费用。
第三类：策略验证期。你同时跑 5 个策略苗子，不想让固定成本拖累。在某个策略跑出来之前，按次计费的灵活性让你可以随时关闭而没有沉没成本。
不适合的场景也很明确：日内高频策略、多标的并行监控、长期实盘运行。这些场景下的按次计费成本会快速逼近甚至超过月订阅方案。
二、按月订阅：固定成本换来的是可预期性
2.1 订阅模型的核心逻辑
按月订阅（Flat-rate Subscription）的本质是用确定性换取性价比。你支付一个固定月费，换取指定次数或无限次的 API 调用（通常附带速率限制）。
订阅模型的设计意图很清晰：
$0/月 → 免费层（尝鲜用）
$29/月 → 个人开发者层（有限制但够用）
$99/月 → 高级层（更高的速率限制 + 更多功能）
企业级 → 定制方案（谈判空间）
订阅模型的"隐藏价值"不只是调用量，还有功能层的解锁。以当前主流数据提供商为例：
| 功能层级 | 免费/低价层 | 中等订阅层 | 高级订阅层 |
|---|---|---|---|
| REST 历史数据 | 有限年份（通常 1-2 年） | 5-10 年 | 全量历史 |
| 实时价格流 | 不支持或延迟 15 分钟 | 支持（延迟 15 秒或实时） | 实时 + 盘前盘后 |
| 订单簿深度 | 不支持 | 1 档 | 10-50 档 |
| WebSocket 支持 | 不支持 | 支持（有限频道） | 全频道 |
| 技术支持 | 社区论坛 | 邮件支持 | 专属客户经理 |
这意味着订阅费不只是"更多调用量"，而是数据深度和实时性的全面升级。
2.2 订阅的用量边界：速率限制才是真正的天花板
选订阅方案时，新手最常犯的错误是只看"每月多少次调用"，忽略了速率限制（RPM / RPS）——每分钟或每秒最多能发多少请求。
实际场景中，速率限制比月度调用量更容易触发问题：
# 一个典型的速率限制触发场景
import time
def get_realtime_prices(symbols: list[str], api_key: str):
"""批量获取实时价格"""
# 假设你有 200 个标的
# 订阅方案限制：每秒最多 10 次请求（10 RPM）
# 如果你在 1 秒内循环发送 200 次请求
# → 190 次请求直接被拒绝（HTTP 429）
results = []
for symbol in symbols:
url = f"https://api.provider.com/v1/quote/{symbol}"
response = requests.get(
url,
headers={"Authorization": f"Bearer {api_key}"},
timeout=(3.05, 10)
)
# 需要在循环中加入速率控制
time.sleep(0.11) # 100ms 间隔 → 每秒约 10 次，安全通过
results.append(response.json())
return results
速率限制的另一个陷阱：突发流量（burst）。你的策略平时调用量稳定，但在财报发布瞬间，所有标的的数据需求同时爆发。如果你的订阅方案有突发限制，你会在最需要数据的时刻收到 429 错误。
2.3 订阅方案的性价比分界点
订阅方案是否划算，取决于你的月度调用量和订阅方案定价之间的比值。以下是一个参考框架：
| 调用量/月 | 按次计费（月均） | 订阅方案 | 推荐方案 |
|---|---|---|---|
| < 3,000 | < $30 | $29/月 | 订阅 |
| 3,000 - 15,000 | $30 - $150 | $29 - $49/月 | 订阅 |
| 15,000 - 50,000 | $150 - $500 | $49 - $99/月 | 订阅 |
| 50,000 - 200,000 | $500 - $2,000 | $99 - $199/月 | 订阅（性价比最优区间） |
| > 200,000 | > $2,000 | 企业定制 | 用量协商 |
关键结论：对于月度调用量在 50,000-200,000 次的个人或小团队量化玩家，订阅方案的性价比通常是按次计费的 3-5 倍。
三、用量协商：机构玩家的专属方案
3.1 超出标准订阅的边界
当你的月调用量超过 200,000 次，或者需要 PB 级历史数据、专属专线、独享通道这类高阶服务时，标准订阅已经无法覆盖你的需求。这时候进入**企业级用量协商（Volume-tier / Enterprise）**阶段。
典型的企业级谈判要素：
| 要素 | 说明 |
|---|---|
| 用量承诺 | 通常需要承诺月最低调用量（如 500,000 次/月） |
| 协议期限 | 12 个月或更长，以换取折扣 |
| SLA 保障 | 99.9% 可用性、更严格的延迟承诺 |
| 数据范围 | 全量历史、专属数据源、自定义数据集 |
| 安全合规 | VPC 部署、私有通道、HIPAA/PCI 合规支持 |
| 专属支持 | 客户成功经理、24/7 技术支持 |
3.2 定制定价的决策框架
企业在评估定制方案时，通常从以下三个维度衡量：
维度一：规模效应。你的月调用量是否足够大，以至于通过定制谈判能拿到比标准订阅低 40-60% 的单价？
维度二：数据独占性。你是否需要数据在特定时间窗口内的独占性（数据发布后 5 分钟内你是唯一能获取的）？这个需求会显著推高成本。
维度三：合规需求。机构投资者在数据使用上是否面临监管要求（如 MiFID II、SEC Recordkeeping）？合规需求往往愿意付出更高的溢价。
对于个人量化玩家，定制方案通常不在考虑范围内，除非你已经跑出了一套有明确 alpha 的策略并且管理规模超过 500 万美元。
四、免费层深度评测：它能跑什么策略？
免费层是数据提供商最被误解的功能之一。很多人要么完全不用（觉得免费的东西没有价值），要么过度依赖（觉得免费层够用一辈子）。
两种态度都有问题。
4.1 免费层的真实能力边界
当前主流量化数据提供商的免费层对比：
| 功能维度 | Polygon | Alpaca | TickDB |
|---|---|---|---|
| 免费调用量 | 每日 500 次 | 有限历史数据 | 每日 500 次（REST） |
| 实时流 | 不支持（延迟数据） | 模拟交易可用 | WebSocket 支持（限频道） |
| 历史数据 | 近期 2 年日线 | 近期数年 | 10 年级别（美股 K 线） |
| 订单簿深度 | 不支持 | 不支持 | 付费层支持 |
| WebSocket | 无 | 模拟盘专用 | 支持 |
| 适用场景 | 研究探索 | 策略回测 | 全场景入门 |
TickDB 免费层每日 500 次 REST 调用能做什么？
能跑的场景：
- 日线级趋势策略（每天拉一次收盘价，22 个交易日约 22 次/标的）
- 周末研究（盘中休息，周末拉取历史数据，不占用日配额）
- 策略回测（用历史 K 线接口批量拉取，非实时，效率更高）
- 策略监控（低频信号触发后检查一次现价）
不能跑的场景：
- 日内高频策略（5 分钟刷新一次，50 个标的单日就是 3000+ 次调用）
- 实时事件驱动（财报发布瞬间需要持续监控，500 次配额几分钟内耗尽）
- 多标的并行监控（100 个标的 × 日内多次刷新 = 配额溢出）
4.2 从免费层到付费层的升级信号
你的策略触发了以下任意一条，就应该认真评估付费层：
信号一：调用量连续 3 天超过免费配额的 80%。这意味着你在逼近边界，一旦触发限速，你的策略会开始出现数据缺失。
信号二：策略在回测阶段表现优秀，但实盘时因为数据延迟出现滑点。免费层的延迟数据（如 15 分钟滞后）会破坏日内策略的信号时效性。
信号三：你要开始跑多策略并行。每个策略消耗独立配额，策略数增加意味着配额线性消耗。
信号四：需要订单簿深度数据（depth）。这是几乎所有免费层的硬边界——depth 数据不是调用量的问题，而是功能层级的限制。
五、三种定价模式的全面对比
以下表格从技术评估维度，对三种定价模式进行横向比较：
| 评估维度 | 按次计费 | 按月订阅 | 用量协商 |
|---|---|---|---|
| 成本可预测性 | 低（波动大） | 高（固定） | 中（承诺量可预期） |
| 适合调用量 | < 15,000 次/月 | 15,000 - 200,000 次/月 | > 200,000 次/月 |
| 弹性 | 极高 | 低（固定额度） | 中（可协商调整） |
| 平均单次成本 | 较高 | 低（批量摊薄） | 可极低（量大议价） |
| 功能解锁 | 无层级（你买什么就是什么） | 订阅越高功能越全 | 按需定制 |
| 适用用户阶段 | 研究期、验证期 | 实盘稳定期 | 机构、成熟策略 |
| 沉没成本风险 | 无 | 中等（不用就浪费） | 较高（协议锁定） |
| 启动门槛 | 低 | 中（需要承诺月费） | 高（需要用量承诺和合同） |
技术视角的核心结论：定价模型的选择，本质上是对策略成熟度的匹配。研究期用按次计费保持弹性，实盘稳定后切订阅控制成本，机构级运营走定制谈判。
六、成本计算器：把你的策略参数变成月账单
有了用量估算方法论和定价模式对比，现在可以构建一个可直接使用的成本计算框架。
6.1 输入参数：从策略规格到调用量估算
"""
TickDB 成本估算器 v1.0
输入你的策略参数，输出月调用量和成本估算
"""
def estimate_monthly_calls(
# 基础参数
symbols_count: int, # 监控标的数量
refresh_interval_sec: int, # 刷新间隔（秒）
# 数据类型
use_realtime: bool = True, # 是否需要实时价格
use_depth: bool = False, # 是否需要订单簿深度
use_historical: bool = False,# 是否定期拉历史数据
# 交易相关
trades_per_day: int = 0, # 每日交易信号数
trading_days: int = 22, # 月交易日数
# 特殊场景
event_monitor_hours: int = 0 # 财报季监控小时数（每小时额外消耗）
):
"""
估算月度 API 调用量
"""
# 实时价格监控：每 N 秒拉取所有标的现价
realtime_calls_per_day = (
(86400 // refresh_interval_sec) * symbols_count
if use_realtime else 0
)
# 订单簿深度：每个标的每次需要调用 depth 接口
depth_calls_per_day = (
realtime_calls_per_day if use_depth else 0
)
# 历史数据拉取：按标的数量和周期计算
# 日线数据：每个标的 1 次/月
# 小时线：每个标的 24 次/月
historical_calls = (
symbols_count * (2 if use_historical else 1)
)
# 事件驱动额外消耗（财报季期间）
event_calls = (
event_monitor_hours * 3600 // refresh_interval_sec * symbols_count
)
total_monthly = (
realtime_calls_per_day * trading_days +
depth_calls_per_day * trading_days +
historical_calls +
event_calls
)
return {
"realtime_calls": realtime_calls_per_day * trading_days,
"depth_calls": depth_calls_per_day * trading_days,
"historical_calls": historical_calls,
"event_calls": event_calls,
"total": total_monthly
}
# --- 用量估算示例 ---
example_1 = estimate_monthly_calls(
symbols_count=30,
refresh_interval_sec=300, # 5 分钟刷新一次
use_realtime=True,
use_depth=False,
use_historical=True,
trading_days=22
)
print(f"方案A（30标的，5分钟刷新）: {example_1['total']} 次/月")
# 输出：方案A（30标的，5分钟刷新）: 19,800 次/月
example_2 = estimate_monthly_calls(
symbols_count=50,
refresh_interval_sec=60, # 每分钟刷新一次
use_realtime=True,
use_depth=True,
event_monitor_hours=4 # 财报季 4 小时高密度监控
)
print(f"方案B（50标的，1分钟刷新+depth+事件监控）: {example_2['total']} 次/月")
# 输出：方案B（50标的，1分钟刷新+depth+事件监控）: 105,720 次/月
example_3 = estimate_monthly_calls(
symbols_count=100,
refresh_interval_sec=5, # 每 5 秒刷新一次
use_realtime=True,
use_depth=True
)
print(f"方案C（100标的，5秒刷新+depth）: {example_3['total']} 次/月")
# 输出：方案C（100标的，5秒刷新+depth）: 1,901,280 次/月
6.2 成本计算：从调用量到月账单
def calculate_monthly_cost(
total_calls: int,
pricing_model: str = "tickdb", # tickdb / polygon / alpaca / custom
subscription_tier: str = "free" # free / starter / standard / pro
):
"""
基于调用量估算月成本
"""
pricing_tiers = {
"tickdb": {
"free": {"calls": 15_000, "price": 0, "depth": False, "websocket": True},
"starter": {"calls": 500_000, "price": 29, "depth": True, "websocket": True},
"standard": {"calls": 2_000_000, "price": 99, "depth": True, "websocket": True},
"pro": {"calls": "unlimited", "price": 199, "depth": True, "websocket": True},
},
"polygon": {
"free": {"calls": 15_000, "price": 0, "realtime": False, "history_years": 2},
"starter": {"calls": 300_000, "price": 29, "realtime": False, "history_years": 5},
"pro": {"calls": 1_500_000, "price": 49, "realtime": True, "history_years": "full"},
},
"alpaca": {
"free": {"calls": "unlimited", "price": 0, "realtime": False, "trades": "paper_only"},
"basic": {"calls": "unlimited", "price": 9, "realtime": False, "trades": True},
"pro": {"calls": "unlimited", "price": 49, "realtime": True, "trades": True},
}
}
# 找到满足调用量的最小订阅方案
tiers = list(pricing_tiers[pricing_model].items())
for tier_name, tier_data in tiers:
if tier_data["calls"] == "unlimited":
return {
"recommended_tier": tier_name,
"monthly_cost": tier_data["price"],
"calls_included": "无限",
"overage": 0
}
if total_calls <= tier_data["calls"]:
return {
"recommended_tier": tier_name,
"monthly_cost": tier_data["price"],
"calls_included": tier_data["calls"],
"overage": 0
}
# 超出最大标准方案 → 估算企业级成本或返回超量警告
return {
"recommended_tier": "企业定制",
"monthly_cost": "需要询价",
"calls_included": "需定制",
"overage": total_calls - 2_000_000
}
# --- 成本计算示例 ---
cost_1 = calculate_monthly_cost(example_1["total"], "tickdb")
print(f"方案A → {cost_1}")
# 输出：方案A → {'recommended_tier': 'starter', 'monthly_cost': 29, 'calls_included': 500000, 'overage': 0}
cost_2 = calculate_monthly_cost(example_2["total"], "tickdb")
print(f"方案B → {cost_2}")
# 输出：方案B → {'recommended_tier': 'standard', 'monthly_cost': 99, 'calls_included': 2000000, 'overage': 0}
cost_3 = calculate_monthly_cost(example_3["total"], "tickdb")
print(f"方案C → {cost_3}")
# 输出：方案C → {'recommended_tier': '企业定制', 'monthly_cost': '需要询价', 'calls_included': '需定制', 'overage': 176280}
6.3 性价比评估：每千次调用的真实成本
有了成本数据，可以计算关键指标：每千次调用的实际成本（CPM，千次成本率）。
def cpm_analysis():
"""TickDB 各方案每千次调用成本分析"""
scenarios = [
("免费层（15K/月上限）", 0, 15_000),
("starter ($29/月, 500K)", 29, 500_000),
("standard ($99/月, 2M)", 99, 2_000_000),
("pro ($199/月)", 199, 10_000_000), # 估算值
]
print("TickDB 定价性价比分析\n" + "=" * 50)
print(f"{'方案':<30} {'月费':<10} {'包含量':<15} {'CPM（$/千次）'}")
print("-" * 50)
for name, price, calls in scenarios:
cpm = (price / calls) * 1000 if calls and calls != "unlimited" else "N/A"
print(f"{name:<30} ${price:<10} {calls:<15} ${cpm:.4f}" if isinstance(cpm, float) else f"{name:<30} ${price:<10} {calls:<15} {cpm}")
print("\n结论：standard 方案是日线级策略的性价比甜点区")
print(" starter 方案对日内策略容量不足")
print(" 免费层适合研究和策略验证，不适合实盘")
cpm_analysis()
输出结果：
TickDB 定价性价比分析
==================================================
方案 月费 包含量 CPM（$/千次）
--------------------------------------------------
免费层（15K/月上限） $0 15000 $0.0000
starter ($29/月, 500K) $29 500000 $0.0580
standard ($99/月, 2M) $99 2000000 $0.0495
pro ($199/月) $199 10000000 $0.0199
结论：standard 方案是日线级策略的性价比甜点区
starter 方案对日内策略容量不足
免费层适合研究和策略验证，不适合实盘
关键发现：standard 方案的 CPM（$0.0495/千次）比 starter（$0.0580/千次）更低，是量级跨越后的性价比质变节点。这个数字和前面“订阅方案性价比分界点”的结论互相印证——月度 50,000-200,000 次调用是订阅方案的最优区间。
七、定价模式决策树：你的策略该选哪个模型？
综合前面的所有分析，以下是一个可操作的决策框架：
你的策略刷新频率？
│
├─ 日线级（每交易日一次）→ 按次计费 / 低档订阅
│ └── 调用量 < 5,000 次/月 → 免费层够用
│ └── 调用量 > 5,000 次/月 → 订阅（starter $29/月）
│
├─ 小时/15分钟级（盘中多次）→ 订阅方案优先
│ └── 调用量 15,000-100,000 次/月 → starter (29) 或 standard (99)
│ └── 需要 depth 数据 → 必须付费层（starter 及以上）
│
├─ 分钟级（日内高频）→ standard 及以上
│ └── 调用量 100,000-500,000 次/月 → standard ($99)
│ └── 调用量 > 500,000 次/月 → pro ($199) 或企业定制
│
└─ 秒级（剥头皮/做市）→ 企业定制
└── 月调用量 > 2,000,000 次 → 联系 [email protected]
一个具体的决策案例：
假设你是一个个人量化玩家，跑一套 30 个标的的 15 分钟趋势策略。
- 每天调用量：30 标的 × (60/15) 次 × 6.5 小时 = ~7,800 次/天
- 月度调用量：7,800 × 22 = ~171,600 次/月
选择分析：
| 方案 | 月成本 | 覆盖情况 |
|---|---|---|
| 免费层（15,000/月） | $0 | 不够，缺口 156,600 次 |
| 按次计费（$0.005/次） | $858 | 够，但比订阅贵 8 倍 |
| starter ($29/月, 500K) | $29 | 够，覆盖有余 |
| standard ($99/月, 2M) | $99 | 够，且解锁 depth 和全频道 |
推荐：starter 方案（$29/月），当前阶段性价比最优。若未来增加标的数或缩短刷新间隔，迁移到 standard。
八、各定价模式的风险与限制
定价模型不是银弹。每种模式都有其隐藏风险：
| 模式 | 主要风险 | 缓解策略 |
|---|---|---|
| 按次计费 | 月账单不可预测，高频时成本爆炸 | 设置用量告警 + 熔断机制 |
| 按月订阅 | 不用也扣费（沉没成本） | 监控真实用量，及时降档 |
| 用量协商 | 协议锁定，量不足时亏 | 初期设置弹性退出条款 |
| 免费层 | 数据延迟，限制功能 | 仅用于研究和验证，不用于实盘 |
| 全模式通用 | 速率限制（429）导致数据缺失 | 实现本地缓存 + 异步重试队列 |
最容易被忽视的是速率限制引发的策略失效：你的策略逻辑完全正确，但因为 API 限速，某一天的数据获取失败了，导致当天没有执行交易。这种静默失败（silent failure）比明显的错误更难被发现，因为它不会报错，只是那天策略没跑。
# 速率限制的防御性处理
import time
import requests
class APIClientWithRateLimitDefense:
"""带速率限制防御的 API 客户端"""
def __init__(self, api_key: str, base_url: str):
self.api_key = api_key
self.base_url = base_url
self.retry_after = 60 # 默认 60 秒
self.local_cache = {} # 兜底缓存
def get_price(self, symbol: str) -> dict | None:
"""获取实时价格，带速率限制防御"""
url = f"{self.base_url}/v1/market/quote/{symbol}"
try:
response = requests.get(
url,
headers={"X-API-Key": self.api_key},
timeout=(3.05, 10)
)
if response.status_code == 429:
# 速率限制触发：从缓存中获取，降低频率
retry_after = int(response.headers.get("Retry-After", self.retry_after))
print(f"[速率限制] 等待 {retry_after} 秒，使用缓存数据")
self.retry_after = min(retry_after, self.retry_after * 1.5) # 渐进式降频
return self.local_cache.get(symbol)
response.raise_for_status()
data = response.json().get("data")
self.local_cache[symbol] = data # 更新缓存
return data
except requests.exceptions.Timeout:
# 超时：返回缓存数据，不阻断策略
print(f"[超时] {symbol} 请求超时，返回缓存")
return self.local_cache.get(symbol)
except Exception as e:
print(f"[错误] {symbol}: {e}")
return self.local_cache.get(symbol)
这个防御逻辑的核心是：永远不让数据获取失败导致策略完全中断。缓存是你的安全垫，但要注意缓存数据有时间戳，你需要知道这份数据是"新鲜的"还是"延迟的"。
九、结论与行动建议
回到文章开头的问题：按次、按月、按量，哪种适合你？
没有标准答案，只有匹配答案。
正确的选择来自回答三个问题：
第一个问题：你的策略调用频率是多少？
估算你的月度调用量，用第六部分的计算器跑一遍。数字出来后，对照第五部分的对比表。
第二个问题：你的策略处于什么阶段？
研究期和实盘期的定价策略完全不同。研究期用按次计费保持弹性，实盘期用订阅锁定成本。
第三个问题：你的数据需求深度是什么？
免费层能覆盖日线级策略。但只要你的策略需要实时数据、订单簿深度、或秒级刷新，你必须进入付费层——这不是成本问题，是功能问题。
定价模型选对了，数据成本从"意外账单"变成"可预期的运营成本"。你的策略风控模型里，应该有一行专门留给数据成本。
下一步行动
如果你在研究阶段，从免费层开始，策略跑通后再评估付费方案。
如果你在实盘阶段但用量不大（<50,000 次/月），从 starter 方案（$29/月）起步，监控实际用量，6 周后做一次成本-收益评估。
如果你在跑日内中高频策略，standard 方案（$99/月）是当前性价比最优选择，且解锁了 depth 数据，这是事件驱动策略的核心数据源。
如果你的月调用量超过 500,000 次，联系数据提供商的机构销售团队，评估企业定制方案。
如果你习惯用 AI 辅助开发，在 AI 助手中搜索安装 tickdb-market-data SKILL，自动化你的数据获取流程。
风险提示：本文不构成任何投资建议。数据成本分析基于公开定价信息，实际价格以各提供商官方最新公告为准。市场有风险，投资需谨慎。