摘要：准备做A股行情看板、盘中筛选或投研观察池，股票API接口费用该怎么估？本文面向行情应用和投研工具负责人，从使用用途、数据范围、取数方式和计量规则拆解预算。结合TickDB实际取回的全市场行情，用5000只股票说明请求次数为何能相差100倍，并提供可运行的估算代码、场景选择表和询价清单，帮助团队比较满足同一需求的方案。
你准备做一个A股筛选工具：先观察5000只股票，筛出候选名单，再点开个股看历史走势。
需求单上写着“5000只股票、每5秒刷新”。看起来已经很具体，研发和供应商却仍可能给出不同的额度估算：有人按每批50只计算，有人建议一次取回全市场行情。
同样一轮更新，前者需要100次请求，后者只需要1次。如果直接拿着“多少次调用、每月多少钱”比较，很容易把取数方式不同的方案当成同一项服务。
先确认数据能做什么，再算怎样取数和怎样计费。这几步决定了一个方案是否适合上线，也关系到后面会不会重新采购、补接接口或调整刷新频率。
股票API费用，先按四步估算
一份可比较的预算，要能回答四个问题。
第一，数据能否满足实际用途。需要A股、港股还是美股？是团队内部研究，还是向客户展示？最新价之外，要不要历史K线或盘口？先确认这些条件，才能找到可用方案。
第二，这些功能需要多少数据。股票数量、刷新频率、历史访问量分别是多少？同一份数据是否被多个页面反复请求？
第三，供应商怎样计量。请求次数、连接数量、订阅范围怎样计算？全市场接口是否有独立的开放条件和限流规则？这些要按对应服务确认。
第四，应用还要承担什么投入。取回数据之后，下载、筛选、缓存、页面更新，以及异常后的恢复，都需要有人实现和维护。
预算可以按下面的项目整理：
| 预算部分 | 要确认什么 |
|---|---|
| 数据服务 | 所需市场、内容、历史范围及对应的访问条件 |
| 实际用途与许可 | 内部研究、客户展示、导出或分发的条件；是否涉及额外费用 |
| 应用运行 | 数据传输、处理、存储和页面服务的实际投入 |
| 开发维护 | 接入、名单维护、异常排查和恢复工作 |
把确认需要发生的项目计入预算。尚未问清的费用保留待询价，别先填成零；轮询和用来替代它的订阅，则作为两种备选方案分别比较。
FinOps Foundation在《Unit Economics》中提出，要把技术支出与它服务的业务结果联系起来。对行情工具而言，除了看请求数量，还应问：这些请求是否完成了我们需要的一轮筛选或一次研究任务？
同样5000只股票，100次和1次怎样算出来
先固定一个需求：同一个后台，为同一组5000只股票获取一轮最新行情。
这次我们使用TickDB核对取数方式。它既提供按股票代码查询的行情接口，也提供按市场获取行情的全市场快照接口。前者适合指定名单，后者可以先取回当前可用的市场行情，再筛选目标股票。
按[行情快照批量查询文档]，每批最多50个代码，那么一轮需要：
5000只 ÷ 每批50只 = 100次请求
使用全市场快照，一轮请求一次，再在应用里选出所需的5000只股票。
如果页面要求每5秒更新一轮，一分钟就是12轮：
| 取数方式 | 一轮更新的HTTP请求次数 | 每5秒更新一次的需求量 |
|---|---|---|
| 每批50只查询 | 100次 | 1200次/分钟 |
| 获取全市场快照后筛选 | 1次 | 12次/分钟 |
图1：AI生成方法示意。单市场、同一5000股观察池；100与1比较HTTP请求次数，不表示费用或速度比例。
标题中的“调用量”指这里的HTTP请求次数。表中是需求计算；上线前还要检查一轮查询能否按时完成，以及请求集中发出时是否符合限流规则。
5000只股票的规模，来自实际返回
2026年11月1日10:06左右，我们调用了TickDB的A股全市场快照接口：
GET /v1/market/ticker/cn-stock
对原始响应逐条统计，结果如下。以下是统计输出，并非接口原始JSON：
HTTP状态: 200
API业务码: 0
行情记录数: 8198
不同股票及产品代码数: 8198
沪深北三个股票类别记录数: 5577
本文选取的观察池代码数: 5000
三个股票类别按响应中的sh_stock、sz_stock、bj_stock筛选。本文从中选出5000个不同代码，包含寒武纪688256.SH。整份8198条响应还包含ETF、指数、债券等记录，不能直接写成8198只股票或上市公司。
核对入口与返回字段，可查阅[TickDB A股全市场快照文档]。采集日是周日，行情时间应读取每条记录的timestamp，页面不能把本次取数时间当成最新成交时间。
港股全市场接口在同轮核验中返回3315条行情，其中stock类型3310条、指数5条。目录显示美股股票类代码总数为14371，但当次全市场查询和订阅提示未启用。增加市场时，应分别确认开放状态与实际返回。
请求次数减少，为什么还要继续核算成本
全市场快照用一次请求带回更多数据，后台也要处理更多内容。
这次A股响应解压后的JSON约2.59MB。即使页面只使用其中5000只股票，后台仍需下载整份响应、解析并筛选；实际网络传输量还受压缩影响。
因此，100次请求变成1次之后，还有两件事要核对：
一是每次拿回的东西是否满足同一需求。需要的字段是否齐全？目标名单有没有缺失？行情时间是否可用？
二是供应商如何计量这两种服务。如果按市场访问权限收取订阅费用，请求减少未必改变月费；如果某些用量另计，也要按其具体单位核算。
请求数是预算输入，金额要结合服务条件计算。把这一层补上，才能从100倍的请求差距走到实际采购决定。
哪种取数方式适合自己的场景
全市场取数值得评估，也要看页面真正需要什么。
假如只关注寒武纪等少数几只股票，为显示几行价格，每隔几秒都下载整份市场快照，会增加无用的数据处理。按代码查询更贴近这种需求。
当观察范围扩大到几千只股票，后台需要不断重算筛选条件时，全市场快照的作用更明确：先拿到一份市场行情，再根据自己的名单和条件处理。
如果要持续监控大范围股票，还可以评估订阅。它先发送首批行情，再推送变化更新，需要结合连接、消息处理和断线恢复一起安排。
| 你的实际任务 | 优先评估的取数方式 | 重点核对 |
|---|---|---|
| 打开某只股票时查价格，或关注少量股票 | 按代码查询 | 批量大小、访问频率和字段 |
| 定期刷新几千只股票，生成筛选结果 | 全市场快照后筛选 | 范围、行情时间、响应处理与计量规则 |
| 持续监控大范围股票的变化 | 全市场订阅 | 开放条件、消息处理、连接恢复与盘中更新 |
这张表用于选择试接方向，具体取舍还要结合刷新要求和实际运行投入。
本次TickDB的A股和港股全市场订阅，分别收到了8198条和3315条首批行情，每批最多500条。这里的500是消息分批大小，不是股票覆盖上限。周日收到首批快照后，交易时段的持续更新和恢复能力仍需另行验收。
历史图表单独估算，别跟着最新价反复重拉
筛选出候选股票后，用户可能点开寒武纪，查看近一年日K。这个动作应按历史范围、周期、复权方式和访问量估算。
最新价每5秒刷新，没有必要因此把同一份历史K线也每5秒重新下载。缓存保留多久、哪些数据需要更新，由应用按任务设计。我们这次也分别核验了行情快照与寒武纪日K，两者承担不同工作。
多个页面关注同一份股票池时，可以由后台统一取数，再按获准用途提供给页面。如果每个人的名单不同，先把同时关注的股票去重，再估算需要维护的范围。
修改三个参数，算出自己的请求需求
下面的Python代码只做请求量估算，不调用行情接口，也不需要API Key。修改股票数量、每批数量和刷新间隔即可运行。
from math import ceil
def estimate(symbols=5000, batch_size=50, refresh_seconds=5):
if min(symbols, batch_size, refresh_seconds) <= 0:
raise ValueError("输入值必须大于0")
rounds_per_minute = 60 / refresh_seconds
batch_requests = ceil(symbols / batch_size)
return {
"每轮分批查询请求数": batch_requests,
"每轮全市场快照请求数": 1,
"分批查询每分钟请求数": batch_requests * rounds_per_minute,
"全市场快照每分钟请求数": rounds_per_minute,
"请求次数比例": batch_requests,
}
for name, value in estimate().items():
print(f"{name}: {value:g}")
默认输入的实际运行输出：
每轮分批查询请求数: 100
每轮全市场快照请求数: 1
分批查询每分钟请求数: 1200
全市场快照每分钟请求数: 12
请求次数比例: 100
这里按单市场、一个后台估算，全市场接口每轮请求一次。历史访问、失败重试和恢复取数要另外安排；1200次/分钟是计算出的需求，没有按该频率执行负荷测试。
带着同一份需求询价，才能比较方案
把估算结果写进需求单，研发和供应商就能围绕同一个交付讨论。下面这份示例可以直接修改使用：
| 需求项目 | 本文示例或需要填写的内容 |
|---|---|
| 产品任务 | 观察5000只股票并筛选候选名单，支持点开个股历史走势 |
| 市场范围 | 先核A股；增加港股、美股时分别确认 |
| 股票范围 | 固定5000个不同代码；说明后续新增、退出如何维护 |
| 所需内容 | 列明最新价等字段；盘口或其他数据另列 |
| 刷新需求 | 每5秒一轮；明确可接受的行情时间和页面更新时间 |
| 分批查询备选 | 每批50只时，每轮100次，平均1200次/分钟 |
| 全市场快照备选 | 每轮1次，平均12次/分钟，后台筛选目标股票 |
| 持续订阅备选 | 确认市场、订阅内容、连接需求及恢复方式 |
| 历史图表 | 例如近一年日K；填写复权方式、访问高峰及缓存安排 |
| 使用用途 | 内部研究、客户展示、导出或分发，按实际情况填写 |
| 验收要求 | 名单匹配、字段、行情时间、交易时段更新和异常恢复 |
用途最好在询价时就说明。TickDB服务条款对未经许可的共享、转售和再分发有要求；内部研究、客户看板和数据分发，应分别确认自己项目的使用条件。
可以把下面这段话与需求表一起发给供应商：
请按这份市场、字段、刷新频率和用途需求，说明可采用的取数方式、所需权限、计量与限流规则、已包含的服务，以及需要单独确认的费用。请同时列出试接时应核验的项目。
试接中如果出现数量或时间异常，先保留请求条件、原始响应和错误信息，再按市场、代码、分类及行情时间检查。把接口未开放、目标记录缺失和应用筛选错误分开处理，避免整份名单无差别重跑。
准备预算时，可以先把表中的5000只和5秒换成自己的需求，请研发确认取数设计，再让供应商按同一份条件答复。之后增加市场、扩大观察池或调整功能，也能沿着这份需求重新估算。
资料与核验依据
- TickDB官方文档：行情快照批量查询；A股、港股、美股全市场快照与全市场订阅说明；K线查询与产品目录。
- TickDB服务条款：数据使用与分发条件。
- FinOps Foundation：《Unit Economics》，用于理解技术支出与业务使用单位的关系。
- 本文接口核验日期：2026年11月1日；数量为该次原始响应统计，行情时间按逐条记录读取。请求量代码已实际运行。
