很多人第一次接大模型，会把它当成普通接口：填个 key、发个请求、拿回 JSON，就以为完事了。真上手才发现，延迟忽高忽低、按 token 计费、输出不确定、还夹着限流和内容审核。这篇不堆概念，只给判断标准：什么场景该用 App、什么场景该接 API、什么场景该自建，以及接之前先量哪几项。
先分清：哪里一样，哪里根本不一样
先把「一样」的部分说清楚，不然后面容易越比越乱。普通 API 和大模型 API，在调用形式上基本是一套东西：客户端通过网络发一个请求，带上密钥做鉴权，服务端按约定的格式返回结构化结果，中间都要处理超时、重试、错误码。你要写的封装、日志、限流、密钥轮换，两边都能复用。
- 一样的地方
- 都是 HTTP 请求 + 密钥鉴权 + 约定格式 + 结构化返回 + 超时与重试
- 不一样的地方
- 计费按 token、同样输入两次结果可能不同、响应时间跨度从毫秒到几十秒
- 本质差异
- 普通 API 卖的是确定性数据，大模型 API 卖的是一次前向推理的算力时段
| 对比维度 | 普通 API | 大模型 API |
|---|---|---|
| 返回内容 | 同一请求基本同一结果 | 同一条输入两次可能不同 |
| 计费方式 | 按次、按调用量或按套餐 | 按 token 计量，输入输出分别算 |
| 响应时间 | 通常在毫秒到百毫秒级 | 从几百毫秒拉到几秒甚至几十秒 |
| 稳定性预期 | 可以要求结果完全确定 | 只能要求格式与语义可接受 |
- 别拿 REST 接口那套「同样入参必须同样出参」的标准去要求模型 API，会把自己逼死；
- 别把「超时」设成普通接口那种短阈值，生成类请求本来就要等；
- 别把模型返回当数据库字段直接写库，先做格式校验和兜底；
- 别只看单次调用成本，token 是随输入输出长度浮动的，去站内价格页看当时的计量口径；
- 别以为换个模型就能解决稳定性问题，很多时候是提示词和参数没收敛。
什么情况下上面这套不适用？如果你把模型 API 包了一层缓存，或者任务本身是分类、抽取这类答案空间很小的场景，那它的表现会接近普通 API，确定性高、耗时短。反过来，开放式写作、长文总结、多轮对话这类任务，就别指望稳定复现。判断口诀很简单：要的是「一个确定答案」，用普通 API；要的是「一段可接受的自然语言或结构化生成」，才轮到模型 API。
下一步想核对当前各家的计量口径和响应特征，去站内模型资料库和价格追踪页看当时的数字，别凭印象估。→App、普通 API、大模型 API 三者的分工
很多人把「用大模型」和「接接口」当成一回事，其实中间差着三层东西。App 是给人点着用的，普通 API 是给系统之间搬数据用的，大模型 API 是给系统里塞一段生成能力用的。三者解决的问题不一样，所以选错了不是贵不贵的问题，是白忙一场。
| 形态 | 它在替你解决什么 | 谁握着主动权 | 典型适用场景 |
|---|---|---|---|
| App | 人当下就要用一下 | 界面、额度、账号都在别人手里 | 偶尔问答、轻量日常、先试试水 |
| 普通 API | 系统之间搬固定字段的数据 | 你调、对方答，契约相对稳定 | 同步订单、拉取信息、对接表单 |
| 大模型 API | 系统里需要一段能生成、能理解的能力 | 账号、计费、日志、重试全归你管 | 嵌进自己的产品、批量处理文本、换模型对比 |
- App 的好处是零成本起步，坏处是你没法把它嵌进自己的业务流里，也没法统一管控账号和记录
- 普通 API 讲究的是字段固定、结果可复现，同样的输入基本给同样的输出，适合做确定性的事
- 大模型 API 的输入输出偏开放，同一句话换个问法结果就可能不同，所以你得自己兜住异常和边界
- 能嵌进自己流程、能批量跑、能随时换模型，是大模型 API 最实在的三个优势
- 代价也很直白：重试、计费、日志、内容边界这几件事，接进来之后都变成你的活
怎么判断自己该走哪条路，别看别人怎么写，看三件事：是不是只有一个人偶尔用、要不要一次跑很多条、要不要统一走自己的账号和审计。三条里只中第一条，用 App 更省事；中后两条任意一条，才值得考虑接 API。反过来，如果你只是想验证某个模型答得顺不顺口，却先花时间搭一套接口和日志，那就是顺序反了。
- 先数人头和频次只有一两个人偶尔用、没有批量需求，先老老实实用 App，把时间花在明确用途上，别一上来就啃接口文档。
- 再看要不要进流程如果这段能力要出现在你自己的产品里、要和已有系统串起来，那就得走 API，App 做不到这一步。
- 最后算运维这笔账决定接 API 之前，先想清楚重试、计费、日志、内容边界谁来管；没人管就别急着接，不然线上出问题只能干瞪眼。
- 比价和核对口径定方向之前，先到站内 换模型前先比一比率和额度（/ai-nav/category/ai-api） 看同类方案怎么给量，再到 官方 API 价格（/official-api） 核对当时的计费口径，别拿记忆里的数字做判断。
接 API 之前，先把这四项量出来
很多人接大模型 API 的姿势是：拿到 key，跑通一段 demo，就直接塞进业务里。等到线上出问题才发现，延迟顶不住、账单看不懂、超时没兜底。下面这四项不用做得很精细，但必须在上线前量一遍。
- 量延迟基线用站内的接口测速工具跑几轮，分别记录首字时间和整体耗时，注意区分短输入和长输入。首字时间决定用户「有没有反应」，整体耗时决定他愿不愿意等完。验证方法：在你的真实网络环境里重复几次，别只信办公室 Wi-Fi 下的数字。
- 量用量和成本用 Token 单价换算工具，按你实际的输入输出长度估算单次请求消耗的 token，再用模型成本计算器折成钱，乘以预估的日调用量。验证方法：拿你业务里最长的那类请求算一遍，因为成本往往被长输入吃掉。
- 定失败策略超时怎么返回、被限流怎么退避重试、内容被安全策略拦下怎么提示用户，这三件事要落到代码里。写法上把重试次数、退避间隔、降级返回文案做成可配置项，而不是散落在各处。验证方法：手动构造一次超时和一次限流，看程序是不是按你写的走。
- 定切换成本把模型名、关键参数、返回结构的解析方式都收敛到一个适配层，业务代码不直接碰供应商 SDK。验证方法：假设明天要换一家，问自己「需要改几个文件」，超过两三个就说明耦合太深。
| 量的东西 | 看什么 | 怎么算量完 | 不适用的情况 |
|---|---|---|---|
| 延迟 | 首字时间、整体耗时 | 真实环境下多次测速取区间 | 离线批处理、用户不看实时结果 |
| 用量成本 | 输入输出长度、日调用量 | 按实际最长请求折算 | 个人实验、每天几十次调用 |
| 失败策略 | 超时、限流、内容拦截 | 代码里有明确分支和兜底 | 单次调用脚本、用完即弃 |
| 切换成本 | 模型名、参数、返回格式 | 评估换供应商要改几个文件 | 纯 demo、不打算长期维护 |
- 先量延迟再看成本，因为延迟不达标后面都白搭；
- 成本按「最长请求 × 日调用量」估，别用平均值自我安慰；
- 失败策略写进代码，文档里的约定没人会在凌晨三点执行；
- 切换成本的核心是适配层，不是多接几家 SDK；
- 这四项量完再做压测和上线，顺序别倒。
给一个参考顺序：先测速拿到区间，再按最长请求算成本，然后写失败分支，最后留一层适配。四项不用一次做完，但上线之前缺一项，后面就要用线上故障来补课。价格和口径会变，折算前到站内的价格变动追踪页面核对当下口径，别拿旧数字做决策。
下一步把延迟和用量这两项先量出来，最快的方法是用现成工具跑一轮，拿到数字再谈架构。→常见问题
大模型 API 和普通 API 最核心的区别是什么？
核心是「确定性」和「计费口径」。普通 API 同样的请求基本给同样的结果，按调用次数或流量计费；大模型 API 的输出受参数和随机性影响，同样输入可能不同，按输入输出的 token 量计费，延迟也高一个量级。所以容错、重试、缓存和成本估算的写法都得换一套思路。
我只是想日常用一下，需要接 API 吗？
多数情况不需要。一个人偶尔问答、写点东西，用现成的 App 更省事，界面和额度都有人管。只有当你需要批量处理、把能力嵌进自己的系统、或者要统一账号和审计留痕时，接 API 的额外成本才划算。判断标准很简单：这件事一周要做几次，超过几十次再考虑接。
接了大模型 API，怎么知道成本会不会失控？
成本等于输入 token 加输出 token 乘以单价，先按你的真实提示词长度和期望输出长度估一遍，再用站内的换算工具折算；同时给单次请求设输出上限、给账号设预算告警。单价和计费口径会变，别记死数字，到官方 API 价格页和价格变动追踪页核对当时的口径。
