大模型API 服务行业分析报告
（2025）
目录
1. 简介 ...........................................................................................................................1
2. 模型 ...........................................................................................................................2
调用量 ..............................................................................................................2
服务商支持模型数量 ......................................................................................3
参数规模与价格 ..............................................................................................6
3. 服务商 .......................................................................................................................9
模型丰富度 ......................................................................................................9
价格、速度、上下文长度 ..............................................................................9
接口兼容性 ....................................................................................................13
接口质量 ........................................................................................................14
其他观察 ........................................................................................................16
4. 应用.........................................................................................................................18
场景分类 ........................................................................................................18
路由策略 ........................................................................................................20
智能路由提速降本效果 .................................................................................21
时空分布 ........................................................................................................22
值得关注的应用 ............................................................................................24
5. 趋势与预测 .............................................................................................................26
6. 总结与讨论 .............................................................................................................28
附录一 模型系列分类规则 ...............................................................................30
附录二 术语说明 ...............................................................................................31
1. 简介
近年来，大语言模型（LLM）在内容生成、代码辅助、知识检索与复杂推
理等场景中快速渗透，促使“模型能力”从单点算法指标走向可规模化交付的在线服
务形态。
大模型 API 服务，是指将模型推理能力以标准化接口对外提供，使开发者
能够在不自建训练与推理基础设施的前提下，按需调用并在业务系统中快速集成。
进一步地，Model-as-a-Service（MaaS，模型即服务）强调以云端资源与工程化
运维为支撑，提供可计量、可观测、可弹性伸缩的模型供给体系，将模型推理的成
本、时延与稳定性纳入统一的服务质量（SLA）框架，从而显著降低企业应用门
槛并加速规模化落地。
AI Ping 作为一站式 AI 评测与 API 服务智能路由平台，整合了中国境内的数
十家算力提供商的数百个大模型 API 服务，并基于 7×24 小时的持续性能监测， 为
用户提供统一的 API 接入与智能路由能力。在模型供给快速扩张、服务商异质性
显著、价格与性能竞争加剧的背景下，AI Ping 的价值在于通过专业评测、
统一接口、弹性调度与数据驱动的性能治理，缓解“多模型、多服务商、多场景” 带来
的接入复杂度与运维不确定性，为应用侧提供更稳定的质量—成本最优解。本文
基于 AI Ping 2025 年第四季度的抽样数据，对开源大模型 API 服务市
场的发展态势进行了系统分析。本文的三个关键结论如下：
1. DeepSeek 与 Qwen 系列模型占据开源模型的 API 调用的主导地位；
2. API 吞吐速率是用户选择服务商的重要因素，各服务商性能差距较大，全
行业性能水平正在持续提升；
3. 应用侧场景分化与模型偏好明显，通过智能路由可以有效提速降本。
下文将从模型、服务商与应用三个维度展开具体分析。
2. 模型
我们将调用量最多的开源模型归为几个类别，分类原则是把各个日期小版本
合并，Instruct 和 Thinking 也合并，详见附录一。
调用量
我们观察到，根据各开源模型请求数据，以总请求量排序，DeepSeek-V3/R1
位居首位、其后为 ，随后进入高调用梯队的是千问（Qwen）家族
的多款模型，包括 Qwen3-32B、-72B 与 Qwen3-235B-A22B 等。整体
而言，头部模型呈现出“少数强势型号占据大盘、同一模型家族内多版本并存”
的结构特征。如图 1 所示。
图 1：头部开源大模型总请求次数（归一化处理）
我们同时观察到，-72B 的调用量维持在较高水平，这一现象在“新模
型加速迭代”的叙事下具有一定反直觉性。一个合理解释是，近期新发布模型在
70B 量级的稠密（dense）架构供给相对稀缺，而部分存量 AI 应用在工程实现、
效果调优与线上回归体系上，曾围绕 -72B 与 Llama3-70B 等稠密模型
完成了较为充分的验证与沉淀。在此背景下，终端用户更倾向于继续采用已
被业务场景验证的“稳定基线”，而非立即迁移至理论能力更强但尚未完成工程化与
业务闭环验证的新模型。换言之，模型选择不仅由模型能力上限决定，也受到迁
移成本、线上风险与可验证性约束的共同塑造。
类似的“版本并存”现象亦体现在同一模型家族内部：尽管 Qwen3-32B 与
QwQ-32B 同属千问系列模型，参数规模接近且 Qwen3-32B 发布时间更晚，但
从调用结构看，Qwen3-32B 尚未完全替代早期的 QwQ-32B。同样地，DeepSeek
与 的推出并未完全挤出 DeepSeek-V3 的存量份额。这表
明，模型迭代并不必然带来“单调替换”，而更常呈现为多版本在不同任务偏好、推理
成本与既有集成依赖下的分层共存。
服务商支持模型数量
我们进一步统计了各开源模型被各个平台的支持程度，按模型所属系列进行
聚合，如图 2 所示。
图 2：提供各模型 API 调用的服务商的数量
从图 2 中可见，DeepSeek 是最受服务商欢迎的模型系列。 下共收录29
家服务商，头部的模型 DeepSeek-V3/R1、 均有 23 家服务商支持。
如果合并所有支持 DeepSeek 的服务商，共计 24 家服务商支持至少一种
Deepseek 模型。其中的差异是因为 DeepSeek 官方目前仅支持其最新的模型
，而不再提供 的服务。
未支持 DeepSeek 模型系列的 5 家服务商中，一家为图像/音视频类服务商（可灵
AI），一家仅提供蒸馏版模型，如 DeepSeek-R1-Distill-Qwen-7B 等模型（SCNet）， 3
家为仅提供自研模型的独立模型厂商。
同时，DeepSeek 系列和 Qwen 系列各个版本的模型也有不同的覆盖度，如图3
所示。
图 3：DeepSeek 和 Qwen 系列各模型的服务商支持覆盖度
DeepSeek 子模型的供给覆盖呈现明显分层：覆盖面最广的子类为 DeepSeek
‑（22 家） 与 DeepSeek‑R1‑0528（21 家）。这通常意味着这
些子版本
具有更高的生态可移植性和更强的市场可预期性，从而更容易被中立服务商优先
接入。相比之下，DeepSeek‑V3（14 家） 与 DeepSeek‑‑Terminus
（15 家）的覆盖率更低，反映出“旧版本/特定分支版本”在多服务商生态中更易
受到生命周期与产品定位的双重约束。
特别的，根据我们与模型 API 服务商之间的交流，服务商上架或下架具体模
型会考虑到客户需求、整体调用趋势、服务成本等综合因素，但总体上还是以客
户为导向，这一结论在下文其他章节将得到再次验证。
我们观察到，MaaS 服务商对 Qwen 系列模型的接入呈现出稳定而一致的覆
盖梯度：基础模型（Base）通常获得最广泛的供给覆盖，其次为指令模型（Instruct），
而强调显式推理过程的 Thinking 版本覆盖最为有限。例如，在 Qwen3-235B-
A22B 系列中，Base、Instruct-2507 与 Thinking-2507 分别被 19、13 与 10 家
服务商接入；在 Qwen3-30B-A3B 系列中亦呈现出类似的递减趋势。但是，在
实际使用层面，用户往往优先选择 Instruct 或 Thinking 模型以满足明确任务目标
或复杂推理需求。这一事实揭示了一种结构性的供需错位：供给侧优先扩散“最易部
署的通用能力”，而需求侧则集中于“最具任务效用的专用能力”。这种错位提示
MaaS 平台在模型细分上架时需要超越“可得性优先”的逻辑，尽管总体来看服务
商提供服务的模型和用户需求接近匹配，但是在较为细节的部分仍然存在着供需
错位，这些细节也同样值得服务商关注。
结合平台调用量，我们观察到 QwQ‑32B 的供给覆盖虽然达到 16 家，但
是调用量不高，说明调用量不仅和支持度有关，还受用户任务结构、模型发布时间、
成本预期等因素共同决定。
我们进一步分析了模型的供给与需求之间的匹配度，在图 4 中，横坐标是提
供该模型 API 服务的服务商数量，纵坐标是 2025 年 Q4 通过 对该模型
产生的调用次数。可以看到尽管服务商数量与模型调用次数并无严格的线性关系， 但
可以看到调用次数最多的一批模型整体上也是被最多服务商支持的，部分大模 型
API 服务商已经基于市场需求对自身的 API 供应策略进行了决策。根据我们
与模型服务商间的交流，大模型服务商的上架、下架模型会考虑大客户需求，整
体调用趋势，这与我们观测到的数据是一致的。
图 4：大模型 API 调用次数（以 DS-V3 为基准归一化）与服务商数量分布
参数规模与价格
图 5 呈现了几个热门大模型的输入输出价格与其激活参数量及总参数量之间
的关系。图中的横线表示各服务商提供的价格区间，而中间的圆点则是模型官方定
价。图中价格数据为过去某一时间点从各平台官方网站采集所得，模型的参数规模
数据亦为人工从各信源统计采集，可能与模型实际参数规模略有出入。
图 5：模型参数量与模型 API 价格（接下页）
图 5：模型参数量与模型 API 价格（接上页）
从图 5 可见，仅用“总参数量”不足以解释价格差异，在 MoE 模型中，总参
数量反映“模型体量”，但并不等同于单次推理的实际计算量；因此价格并不随总参
数量单调变化。典型例子是 Kimi‑K2‑Instruct 总参数量 1040B，
DeepSeek‑ 为 671B，二者价格差异显著，但这种差异不能用总参数量线
性解释。
我们认为 MoE 模型的激活参数规模相比总参数规模更贴近计算成本，但经
过统计发现激活参数规模仍不足以单独决定定价。激活参数量更接近推理阶段的
有效计算规模，因此在理论上比总参数量更可能与“价格下限”相关。从数据看， 即便
激活参数量相近，价格区间仍可显著分化。此外，同系列（或近似参数配置） 模型
仍可能出现显著价差。
尽管大部分大模型 API 服务商会以官方价格为锚点，仅做小幅度的调整，行
业的整体价格接近官方价格。但仍然有部分服务商采取了较为激进的定价策略，
例如 SophNet 和 SCNet 经常处于价格区间的左侧。需要注意的是，服务商可能为大
客户提供批量采购折扣，因此图中价格不一定代表最终用户的成本。
3. 服务商
模型丰富度
在模型丰富度方面，头部服务商供应量基本接近，第一梯队基石智算、派欧
云的开源模型覆盖数量最多，均为 27 个（见图 6），具体支持的模型存在差异。
这体现出了中国开源模型生态的繁荣。
图 6：服务商支持的开源大模型数量
价格、速度、上下文长度
本节以部分热门模型和部分头部服务商为例，继续分析服务商之间的价格、
速度、上下文长度的差异。本节图表中的“与官方相同”是指数值相差 5%以内。本节
的数据仅代表过去某一段时间的结果，感兴趣的读者可通过 获取实时更
新的测试数据。
本文中涉及的技术名词定义见附录二。
图 7 展示了部分热门模型在部分服务商的价格差异，从整体分布看，蓝色块
占显著多数，说明服务商的主流定价策略是“贴近官方价”而非大幅度价格竞争。这通
常意味着官方定价在生态中起到了强锚定作用，服务商更多通过可用性、稳定性、
功能等策略来竞争，而不是直接以显著降价作为主要差异化手段。
图 7：服务商的定价差异
我们进一步发现在推理速度这一关键体验指标上，市场呈现出明显的异质性
与分层，服务商之间的性能差异远大于其定价差异，如图 8 所示。无论是首字延
迟（TTFT），或是端到端完成速度，第三方服务商的性能均与模型原厂官方 API
服务有所差异。我们可以推断出这样一个结论：在热门模型 API 服务竞争中，
速度及稳定性正在成为比价格更具区分度的竞争维度。
图 8：服务商的性能差异
图 8 中还隐含了一个重要现象：官方渠道并不天然等于性能最优。大量绿色
格子的存在表明，第三方服务商在部分模型上可以系统性超越官方基线；与此同
时，红色格子也说明并非所有服务商都能稳定达到官方水平。
这个现象强化了评测与路由的价值：通过持续观测、动态选择与自动故障切
换，将速度波动与尾延迟风险从应用开发者侧迁移到基础设施层治理，从而把“同模型
不同服务商”的性能不确定性转化为可控、可优化的路由决策问题。
本文进一步对比了上下文长度的支持情况，如图 9 所示。上下文长度不仅决
定了单次请求能够容纳的历史对话、长文档与检索证据规模，也会显著影响推理
侧的显存占用、吞吐与排队策略，从而间接反馈到时延与稳定性。
图 9：服务商的上下文长度差异
基于图 9，我们发现上下文长度在供给侧呈现“高度一致但仍存在显著缺口” 的
结构。“上下文缩水”对应用侧的影响会比速度相关的因素影响更大。原因在于，许
多生产场景（如 RAG、长文档问答、合规审计、代码库级别的多文件理解、对话
客服）对上下文有明确的最小阈值，一旦服务商将可用窗口从官方规格下调，模
型服务有可能从“可用”直接退化为“不可用”或“需要大幅改造提示词与检索策略”。
综上，上下文长度维度揭示了一个与价格和性能同样关键的市场事实：多数
服务商能对齐官方规格，但仍存在不可忽视的上下文窗口缩水现象。
根据 的持续性能监测，我们发现大部分服务商提供的性能都在持续改
善，如图 10 所示。图中的“首周”为平台上架模型后首次获得测试数据开始的七
天，“末周”则是数据统计时的最后七天。
图 10：TTFT 和 TPS 的改善趋势
从图 10 中可以观察到一个具有“服务侧渐进优化”特征的分布性变化：相较于
上线后的首周，末周在多个热门模型上呈现出 TTFT 分布整体下移（首 token 延迟
降低）的迹象，吞吐分布整体保持不变或略微改善。这种变化不只体现在中心位置，
也体现在离散程度的收敛：在部分模型上，箱体（25%–75% 分位区间）变窄，表
明典型服务水平的波动区间缩小，性能更稳定。同时，线段两端（min
–max）所刻画的总体取值范围在部分模型中出现收缩，或尽管仍存在长尾极值，
但其相对位置与密度有所缓和，暗示极端慢启动/低吞吐情形发生频率降低。
因此我们推测大部分模型 API 服务在上线后经历了持续的性能优化工作，
整体性能分布向更优方向迁移并趋于稳定。
接口兼容性
在当前大模型服务市场中，接口规范的标准化程度已成为衡量服务商技术能
力与生态兼容性的重要指标。本小节对 18 家服务商对 OpenAI 与 Anthropic 两种
主流接口协议的兼容性问题进行了系统性测试与分析。
图 11：服务商对 OpenAI 和 Anthropic 接口的兼容性
图 11 表明，作为行业事实标准的 OpenAI 接口规范已被绝大多数服务商广泛
支持，平均每个测试模型可获得 个服务商的服务覆盖，这一数据充分印证
了 OpenAI 接口在推动行业生态互联互通方面的标杆地位。与此同时，随着 Vibe
Coding（氛围编程）理念的兴起以及 Agent 自主智能体应用的快速迭代，Anthropic 接
口因其在大规模上下文理解、多轮工具调用及复杂推理任务上的独特优势，其应
用场景与市场需求正呈现显著增长态势。然而，统计数据显示，Anthropic 接口
的整体支持率仅为 %，各模型平均仅有 个服务商提供支持，其中支持
率最高的 Kimi-K2-Thinking 模型也仅达到 %，最低的 Qwen3-30B-A3B 模
型更是低至 %。
这一结果表明，服务商在 Anthropic 接口支持方面仍存在较大的技术适配空
间与生态完善余地，未来需进一步推动多接口标准的协同发展，以更好地支撑日
益多元化的 AI 应用开发需求。
接口质量
基于对系统内数亿次接口调用行为的长期观测与统计分析，我们发现：当前
主流服务商在接口稳定性、错误语义表达规范性以及服务可预期性方面的表现存在
显著差异；同时，在性能分布层面，接口响应缓慢问题明显集中于特定服务商、特定
模型的请求场景。上述两类问题在实际运行中相互叠加，使接口行为的可预期性明
显下降，进而对用户体验的一致性以及系统在大规模场景下的稳定运行构成重要制
约。
从表 1 可见，部分平台在失败场景中缺乏及时、明确的错误返回，失败过程
表现为长时间无响应并以超时结束。常见形态包括连接建立阶段超时、等待首包
阶段超时、请求进入服务处理后因内部依赖或计算资源不足而超时等。
与此同时，不同服务商的失败形态具有明显的时间聚集特征，部分平台在同
一时间窗口内集中出现较高比例的服务端内部错误，高并发场景下失败率放大现
象更为突出。
即使在输入条件高度相似的情况下，不同平台的成功率差异依然显著，部分
平台能够稳定返回结果，部分平台更容易触发参数校验失败、内容安全检测失败
等问题。
错误返回规范性方面也存在系统性不一致，状态码与真实错误原因不匹配现
象较为常见，错误信息表达过于泛化且缺乏可定位上下文，部分接口以流式形式返
回但在内容中携带错误描述，错误结构缺乏稳定字段，导致自动化识别、归因、治理
的工程成本上升。
表 1：服务商接口问题汇总
服务商状态码 响应体内容 出现频率 响应问题
200 空 极高 应返回报错信息
200 {‘error’:{‘ ....’}} 极高 不应将报错信息放入正
常的请求响应体中
400 服务接口异常 较低 应使用 500 状态码
500 Unknown error 极高 语义模糊
503 空 偶发 无具体错误信息
在响应慢方面，高度集中于特定服务商和特定模型场景。服务商维度上，部
分平台在调用量显著较大的情况下仍能维持较低的慢响应比例，体现出较强的容
量规划与调度稳定性。部分平台在百万级以上调用量下慢响应比例低于 %，
表现出成熟基础设施在稳定性与弹性方面的优势。
与此同时，也观察到部分服务商在总体调用量相对较小的情况下慢响应比例仍
明显高于行业平均，个别接近 5%，更可能与峰值资源冗余不足、冷启动频繁、实
例弹性能力有限、调度链路偏长且对突发流量敏感等因素相关。在图 12 中， 我
们展示了部分服务商的慢响应比例。
图 12：服务商慢响应比例图
模型维度上，某些模型的慢响应比例显著高于平均水平，如图 13 所示，
慢响应比例约 %。需要强调的是，慢响应与模型自身推理特
性相关，也与承载该模型的服务商推理设施与调度策略相关，因此更适合在服务商
与模型的组合粒度上进行评估与治理。
其他观察
图 13：模型慢响应比例图
我们进一步观察到，部分服务商在“功能差异化”与“供给策略”上呈现出
较为明确的定位分化。
首先，在模型供给的时效性方面，SophNet、UCloud、七牛云、派欧云等服务 商
表现出较强的“快速跟进”能力，能够在多个开源模型发布当日即完成上线。这类策
略在生态竞争中可被理解为一种抢占早期流量与开发者心智的机制：以更短的上
架延迟换取更高的曝光度与潜在的冷启动优势。
其次，部分服务商采取了更为集中的资源投入策略，从而在特定模型或少数模
型族上形成可观的服务优势。例如，蓝耘将资源集中投入 ，使得该
模型在其平台上的表现更为突出；类似地，商汤大装置的模型覆盖相对有限， 但呈现出
较高的吞吐能力。这些现象提示，在给定算力与工程资源约束下，“广覆盖”与“深
优化”之间存在现实的权衡关系。
再次，在多轮对话等高重复请求场景中，缓存机制对端到端时延与调用成本
具有显著的边际改善效应。阿里云百炼与 MiniMax 提供显式缓存控制能力，允
许开发者通过 cache_control 等参数对缓存进行可控管理；相比之下，多数服务商
更倾向于提供平台侧的自动缓存策略。值得注意的是，对缓存命中请求的计费通
常伴随较大幅度的折扣（约 1–3 折），从而使缓存不仅是性能优化手段，也成
为成本治理的重要方式。
特别的，在我们统计的各服务商中，UCloud 对各接口协议适配得较好，支持
OpenAI 最新的 Response 类型接口、Anthropic 类型接口、Google Models 类型接口
等，提供服务商中少见的全协议覆盖。
总体而言，同时维护多模型矩阵能够提升供给多样性，但也显著增加了适配、运
维与持续优化的复杂度与成本；相反，聚焦于少数核心模型更有利于集中研发与算
力调度资源，进而在性能、稳定性或单位成本等关键指标上建立可持续优势。与此同
时，这一取舍也意味着平台在覆盖面与差异化能力之间需要进行明确的战略选择。
4. 应用
场景分类
我们使用部分参与调研的用户的任务类型和相关任务的输入输出长度，进一
步探究了大模型应用层的分化和规律。
从任务形态看，平台调用并非围绕单一模式展开，而是呈现出明显的差异性， 几
类常见应用的特征如图 14 所示。
图 14：不同类别应用的大模型请求输入输出长度分布
首先，“新闻资讯”落在极端的长输入、短输出区域，说明该类任务更依赖大量
上下文（例如长文、检索证据或聚合信息）而输出相对克制，属于典型的“重输入、
轻生成”的工作负载。
其次“创意写作”和“商业服务”位于较长输入与较长输出区域，显示此类任务既
需要较多上下文铺垫，又往往产生长篇生成，单次请求的总体 token 规模更大，
成本与体验均更敏感。
“内容营销”更偏向输出较高而输入中等，体现出以生成扩写为主的需求形态。
“专业服务”“知识翻译”“教育娱乐”“技术开发”等类别集中在中短输入与中等
输出区域，整体更接近交互式与工具型任务：单次 token 规模并不极端，但对
响应时延与稳定性更敏感。总体而言，该图给出的核心结论是：不同任务在“输入
—输出”结构上差异显著，因而同一套路由目标（只看价格或只看速度）难以覆盖
所有场景；路由需要能够感知任务形态，才能真正做到“提速降本而不牺牲体验”。
在此基础上，若进一步将该平面按输入与输出的高低分为四个象限，可以得
到一套智能路由算法策略：第一象限（长输入、长输出）属于总体 token 消耗
最大的负载，成本由 input_price 与 output_price 共同决定，应采用联合成本最
小化并加入延迟约束的策略；第二象限（短输入、长输出）以输出成本为主，应
优先优化 output_price，并兼顾解码吞吐；第三象限（短输入、短输出）单次成本
相对不敏感，体验更受固定开销与排队影响，适合以低延迟与高吞吐的性能路由为
主；第四象限（长输入、短输出）由输入侧主导，应以 input_price 与预填充相
关性能为核心，并优先保证上下文窗口能力的稳定满足。
图 15：任务类别与使用模型的比例
经过分析各类任务使用的模型，我们观察到明显的“任务与模型匹配”结构， 如
图 15 所示。不同模型在不同任务类别上的使用占比呈现出强烈的集中，而不是
均匀铺开，体现出稳定的“专长—需求匹配”格局。具体而言，部分模型在知
识/语言相关任务上占据主导权重，另一些模型则在专业服务、创意写作或内容
营销等更具风格化与产出导向的场景中形成优势；同时，亦存在任务覆盖更均衡
的模型，表现为跨任务的较强泛化与更广的应用带宽。上述现象表明，模型差异不
仅体现在总体能力标尺上，更体现在不同任务类型下的相对优势、产品定位与用
户选择偏好。此外，考虑到企业客户的调用具有更高的集中度与更强的工程沉淀：
一旦某模型被验证能稳定满足特定场景的质量、成本与交付约束（例如工具链兼
容性、输出风格、价格等等），其调用会固化到生产流程中，导致热力图中跨任
务的偏好差异更明显、模型间的分工边界更清晰。
路由策略
AI Ping 提供几种主要的服务路由策略：
1. 默认策略，由 AI Ping 根据服务商性能、价格、负载情况自动分配服务商，
是一种性价比较高的策略
2. 性能优先，由 AI Ping 分配给该当前速度最快的服务商
3. 成本优先，由 AI Ping 分配给当前最便宜的服务商
基于平台抽样数据可统计出实际使用的路由策略比例如图 16 所示。
图 16：用户选择不同路由策略的比例
如图 16 中展示，路由策略的采用结构显示“性能导向”的偏好显著。在调研
的用户中，“性能策略”达到默认路由用户数的 %。这表明推理速度更可能成为
获客与留存的关键竞争要素。当模型服务逐步趋于同质化时，延迟和吞吐往往更
直接映射到产品可用性与用户感知质量，因此更容易成为用户主动选择的
路由目标。性能策略在用户侧渗透率高、在请求侧也形成了可观的调用量，说明
它更接近可持续的主流使用模式。
智能路由提速降本效果
AI Ping 的智能路由为每一次用户请求调度到当时最合适的服务商，为评估
AI Ping 智能路由策略在实际业务中的成本与性能影响，本小节基于历史真实调
用数据，对比分析了在相同模型条件下，官方直连与智能调度策略的整体表现。
结果表明，智能路由在保证服务可用性的前提下，在成本控制与请求吞吐能力方面
均取得了显著改善，同时成本降低 %。
在成本评估中，选取 Qwen3-32B 模型作为分析对象，对比对象为官方定价
体系。智能路由在多服务商间进行动态调度，综合考虑实时价格与可用性。在约
150 万次请求、累计输入 token 超 10 亿、输出 token 约 亿的样本中，实际总
成本为 4577 元，对应官方定价成本为 7355 元。按统一口径计算，整体成本降低
约 %。该结果反映了智能调度在真实业务负载下的稳定降本能力。
图 17：智能路由降低调用成本
在性能评估中，以 为研究对象，对比官方与智能路由下的
吞吐表现，结果见图 18。基于约一百万次请求的统计结果显示，智能路由后的
整体平均 TPS 较官方提升约 90%。其中在输出 token 数量较多（>1000）的请
求中，平均吞吐提升更为显著。分位数角度看，智能路由后低速情况减少、高速情
况增多，体现出智能路由在高负载与复杂请求下的优势。
图 18：智能路由与官方接口的吞吐对比
时空分布
在日内尺度上，请求数与用户数整体呈现显著的昼夜节律：凌晨到清晨（约
0–7 点）持续下行，并在 6–8 点附近形成全日低谷；随后从 9 点开始快速回
升，在下午工作时段达到高位，并在 15–16 点附近形成全日主峰。晚间（约 18
–20 点）出现次级高位平台，之后请求数回落，但用户数在 21–23 点再次走
强，形成夜间用户活跃回升的特征。我们推测这是因为平台用户包括企业办公时段
用户、互联网办公节奏的用户与下班后的业余开发者用户。
考虑到请求数曲线与用户数曲线并非同步变化，可以推测单位用户的调用强
度在不同时段存在系统性差异。下午主峰附近，请求数上升幅度通常更陡、峰值更
尖，而用户数虽同步上升但相对更平滑，意味着该时段平均每用户请求数更高， 符合
企业客户在办公时段集中触发批处理任务、工作流编排或服务端链路调用的特征。
在 21–23 点，用户数显著抬升而请求数未同比例上升，用户参与面扩大， 但单个用
户的调用频率更低，符合开发者调试和交互的行为画像。
图 19：日内请求潮汐（以中午 12 点为基准归一化处理）
在周内尺度上，热力图进一步揭示了工作日的结构性集中，请求数在工作日
更容易出现局部热点，常见于晚间与午后时段，体现出企业侧的集中调用的特点。相
对而言，周末的格局更分散、强度更温和，用户数分布也更平滑。
图 20：周内请求分布（以周一中午 12 点为基准归一化处理）
图 21 展示了请求来源的地域分布。从总体构成看，请求以国内为主，且“北京
地区”和“国内其他地区”占比接近均衡：国内其他地区约 %，北京地区约
%，境外约 %。北京占比显著偏高的原因可能是需求往往与研发与总部集
聚程度相关。
图 21：用户请求地理分布和各时段占比
从日内动态看，三类区域的占比随北京时间呈系统性重分配。国内其他地区
在上午（约 8–12 点）占比更高，而北京地区在下午至傍晚（尤其 18 点附近） 占
比明显抬升并出现尖峰；境外占比整体较小且相对平稳，波动幅度远低于国内两类。
其中北京的尖峰提示其增量更集中，可能由少数大客户在特定时段的批量作业或工
作流触发所驱动。
值得关注的应用
在本次调研覆盖的客户样本中，我们观察到下游应用呈现出显著的跨行业分
布特征：既包含面向生产与经营的典型需求，例如效率提升、流程自动化与知识管
理等，也涵盖了生态环境保护、文化遗产传承与社会公益等公共价值导向的场
景。这表明，AI 正从单纯的生产力工具演进为可被更广泛社会主体采用的通用
能力，其影响边界正在从企业内部的降本增效扩展到公共服务与社会治理等更广阔
的领域。
同时，这也体现了 AI 技术扩散的普惠潜力：当高质量的智能能力能够以更
低门槛、更低边际成本被获取与复用时，中小组织、公益机构与资源相对有限的群
体也有机会获得接近同等水平的技术赋能，从而缩小能力差距与信息鸿沟。我们
相信，人工智能的持续演进与规模化应用将促进更高质量与更可持续的社会发展。
5. 趋势与预测
基于本次调研的数据，我们发现了一些大模型 API 服务发展的趋势，以及一
些用户侧还未被完全满足的需求。我们在本节进行趋势汇总与预测，供模型服务
商、应用下游开发作为参考，
首先，开源模型将继续成为中国模型厂家的标准化动作。自 DeepSeek 在 2025 年
初开源 DeepSeek-R1 模型引发全球广泛关注后，大量大厂也跟上了开源模型的
动作。如今年我们观察到了小米、美团等非传统模型厂商的重量级模型选择第一时
间在开源平台上发布，同时其他传统模型厂商继续快速迭代开源模型，如
MiniMax 的 MiniMax-M2, ，智谱的 ， 也都是
以权重开源模型的形式发布。受益于开源生态不断丰富，大模型 API 服务商上架
的模型范围也越来越广，头部的模型服务商如硅基流动，并行科技，基石智算，
派欧云，七牛云等覆盖了几乎所有市面上的开源模型。我们预测 26 年还会观测
到更多更好用的开源模型，而模型服务商的上架范围、其客户能选择的范围也会
越来越广。
除此之外，经过 AI Ping 的持续测试，我们发现普遍的服务商的服务优化趋
势，主流旗舰模型的服务能力在监测窗口内都有性能优化的表现：延时降低，吞
吐提高或稳定，部分厂商有较为特色的优化，如长上下文窗口、很高的吞吐数据
等。基于此，我们预测 2026 年的行业整体服务水平会进一步提升，而这一点会
对服务商本身的技术水平提出挑战，行业整体在进步，服务商自身也要不断加强
自己的算力优化能力，跟上时代的步伐。部分厂商在特定模型上做了非常极致的
优化，这可能会成为模型服务商本身的获客留存优势，可以预见随着服务商的技术
能力进步。会有更多极致性能表现的模型 API 可供用户采用。
更进一步地，随着 Agent 工具调用、多模态模型等更多场景和接口协议的出
现，服务商 API 需要适配的参数也呈现多元化的趋势，目前许多服务商仍存在未
对齐官方协议语法、部分参数已设置未生效等问题。如开启了思考开关但是没有
返回思考 token 的现象在多家服务商都有观测到。我们预测 2026 年将步入接口协
议适配的深水区，因为多模态的模型的 API 协议更加复杂，而 Agent 生态也在
不断涌现新的实现方式，如 MCP, Skills 等，服务商如果能够及时快速全面地
适配对应的参数接口，返回符合预期的结果，将获得相应生态的客户。
总的来说，2026 年对大模型服务商提出了关于模型覆盖范围、性能、协议适
配准确性的挑战，我们期待看到服务商不断打磨自己的产品能力。AI Ping 会持
续提供性能监测，及时发布新的观察报告，作为服务商优化和应用层技术选型的参
考。
6. 总结与讨论
本文基于 AI Ping 平台的真实调用与持续的性能监测数据，从模型、服务商、
应用三个维度，对大模型 API 服务行业的结构与演化进行了系统分析。我们重
点刻画了头部模型的调用与增长、服务商的模型覆盖与接口兼容，以及价格—速度
—延迟—上下文长度等关键服务指标的跨服务商差异，并结合任务形态与时空分布
对应用层使用规律进行了归纳。总体结论可以概括为几点：
第一，需求侧呈现头部集中，多版本共存的结构。DeepSeek 与 Qwen 构成
国内开源模型主要调用的基本盘，且模型迭代并不必然带来单调替换，存量应用
受迁移成本与可验证性约束，促使成熟版本在较长周期内与新版本并存。
第二，多数服务商对齐官方价，但在性能侧显著分化，且性能已成为用户选 择
服务商的首要因素。我们观察到速度与延迟的跨服务商差异远大于价格差异， 且
官方渠道并不天然等于最优性能，上下文长度整体对齐但仍存在窗口缩水风险， 对
长上下文生产场景可能产生影响。多数服务商的 TTFT 分布下移并趋于收敛， 吞
吐分布略微上移，表明供给侧正在持续优化服务水平。
第三，多种应用具有各自的模型偏好与差异化的上下文窗口需求，结合模型
与服务商的多样性，恰当选择底层 API 服务可以显著提升服务速度及降低服务
使用成本。
基于上述事实，我们认为智能路由是当前市场中极具确定性的工程增益来源：
在价格高度收敛而性能显著异质的条件下，智能路由能够将“同模型不同服务商” 的不
确定性转化为可优化的决策问题。本报告的实证结果也支持这一点：在代表 性样本上，
智能路由相对官方直连可实现约 % 的成本降低，并在吞吐上实
现约 90% 的提升，且在长上下文场景中收益更显著。
面向 2026 年，我们判断大模型 API 服务需求仍将延续快速增长态势，开源
模型仍将保持快速迭代，供给侧竞争热点将进一步从“价格”转向“交付质量”，包括吞
吐、尾延迟、稳定性、上下文能力与接口完整性。
平台与服务商的策略选择将更清晰地体现为两条路线的权衡：其一，追求快
速兼容更多模型，以更强的覆盖度与生态速度服务长尾需求；其二，聚焦少数关
键模型的极致性能与稳定性，在头部工作负载上形成可持续的交付优势。前者的
优势在于更高的生态适配与机会捕捉能力，代价是运维与优化资源被摊薄；后者
的优势在于更强的性能壁垒与一致性体验，代价是对模型迭代与需求迁移的敏捷
性要求更高。综合而言，更可行的路径是分层供给：以广覆盖满足多样性，同时
对少数高占比的任务模型组合投入工程深度优化，并以可观测、可回滚的智能路
由机制在两者之间动态平衡。
需要说明的是，本文的分析基于 在 2025 年四季度的抽样数据完成，
并非全量的数据分析，部分数据为过去某一时间点人工从各信源概括总结得来，
尽管统计工作已尽最大努力保证正确性，本报告所披露数据仍然可能与真实情况存
在部分偏差。随着行业的发展，部分结论可能产生变化，我们将在后续的分析报告
中进行回顾和更新。
感谢参与本次调研分析的 API 服务商、应用开发者、终端用户和研究者。
附录
附录一 模型系列分类规则
DeepSeek 系列模型
DeepSeek-V3/R1
DeepSeek-V3、DeepSeek-R1、DeepSeek-V3-0324、DeepSeek-R1-0528
、-Terminus
、-Speciale、-Exp
Qwen 系列模型
Qwen3-235B-A22B
Qwen3-235B-A22B、Qwen3-235B-A22B-Instruct-2507、
Qwen3-235B-A22B-Thinking-2507
Qwen3-Coder-480B-A35B
Qwen3-32B
Qwen3-30B-A3B
Qwen3-30B-A3B、Qwen3-30B-A3B-Instruct-2507、
Qwen3-30B-A3B-Thinking-2507
Qwen3-VL-235B
Qwen3-VL-235B-A22B-Instruct、Qwen3-VL-235B-A22B-Thiniking
Qwen3-VL-30B
Qwen3-VL-30B-Instruct、Qwen3-VL-30B-Thiniking
-72B
QwQ-32B
Kimi 系列模型
Kimi-K2
Kimi-K2-Thinking、Kimi-K2-0905、Kimi-K2-Instruct
GLM 系列模型
MiniMax 系列模型
MiniMax-M2
附录二 术语说明
TPS: Tokens Per Second，TPS 用于衡量模型在生成阶段的平均输出速率，刻画从开始生
成到生成结束的速度表现。
TTFT: 用于衡量用户从发出请求到看到首个输出 token 为止的等待时间，是最贴近交
互体验的延迟指标之一，尤其在流式响应中非常关键。
吞吐：Throughput, 本文使用输出侧吞吐，是指在一个统计窗口内，系统累计输出 token 数
除以窗口时长。
HTTP 状态码规范: 4xx 错误: 表示客户端（用户侧）错误。5xx 错误: 表示服务端错误。
