很多人是这么栽跟头的：试用阶段随便调都通，速度也快，于是直接充钱；充完才发现模型被换了、并发只能一个、长输出被砍半、商用条款还不允许。问题不在你手气差，而在试用账号和付费账号经常不是同一套配置。这篇把试用期常见限制逐条列出来，再给一份必须完成的验证清单和记录方法，让你在掏钱之前就把水面下的部分摸清楚。
很多人栽跟头的方式几乎一样：试用阶段随便调都通，速度也快，于是直接充钱；充完才发现模型被换了、并发只剩一个、长输出被砍半、商用条款还不允许。问题不在你手气差，而在试用账号和付费账号经常不是同一套配置。免费额度是获客手段，不是产品说明书，它的设计目标就是让你先尝到甜头。
这篇把试用期常见限制逐条拆开，再给一份掏钱前必须跑完的验证清单和记录方法。核心思路只有一句：不要相信首页写的「免费额度」四个字，要自己把水面下的部分摸出来，并且留下证据。涉及合规与条款的部分，可到 /safety 对照站内整理的口径。
试用期最常见的六类限制
这六类限制里，前四类是技术层面的，后两类是条款层面的。技术限制通常压测就能暴露，条款限制往往只有问客服或翻文档才看得到，而后者一旦踩中，代价比限流大得多。建议按下面的顺序逐条排查，先技术后条款。
- 调用次数与频率：每日总量、每分钟请求数、按账号还是按 IP 限流，很多站点只写「有免费额度」不写数字，得自己压测出来；额度用完是直接报错还是降级到小模型，结果完全不同
- 可用模型范围：试用只能碰便宜档位，贵档位付费后才解锁；有些站点试用走官方直连，付费后切到渠道分组，质量和对齐程度会变，可到 /sites 与 /channels 相关页面核对分组口径
- 并发与上下文缩水：宣称的上下文长度在试用期可能被截短，并发默认 1，批量任务会排队；这类限制一般不写在首页，要问客服或翻文档细则
- 输出截断与超时：单次最大输出被压到很小，长文任务中途断掉，看起来像模型能力差，其实是服务端设了上限
- 数据用途与留存：免费额度常附带「用于改进服务」的条款，输入可能被留存或人工查看；涉及客户资料、内部代码时先到 /safety 看合规口径
- 商用与转售限制：部分试用明确禁止商用、禁止对外提供接口；一旦你的产品跑在上面，属于条款风险而不是技术风险
| 限制类型 | 试用期常见表现 | 验证动作 |
|---|---|---|
| 频率限制 | 每日总额有上限，每分钟请求被卡 | 连续快速发请求，记录第几次开始报错 |
| 模型范围 | 贵档位不可选或静默换档 | 比对返回里的模型字段与 /models 规格 |
| 并发与上下文 | 并发为 1，长输入被截断 | 同时发三个请求，记录报错与排队现象 |
| 输出与超时 | 单次输出长度明显偏小 | 要一段长输出，看是否中途被切 |
| 数据与商用 | 输入被留存，禁止商用 | 问客服，截图留存，对照 /safety |
试用期必须验证的 5 件事
验证的核心不是「能不能通」，而是「试用和付费是不是同一套东西」。下面五件事建议按顺序做，每件都留下可复查的证据，不要只凭印象。测试用的提示词设计思路可以参考 /tools/verify#probes 里的探针方式。
- 同题复测用同一个提示词在试用和小额充值后各跑一遍，对比返回内容、长度上限和响应速度；不要只比能不能通，要逐字对比差异。
- 边界压力测试故意发长输入、要长输出、并发两三个请求，看是报错、截断还是静默降级；把每次报错原文记下来，后面排查和维权都用得上。
- 模型核对让模型自我介绍不可靠，更实用的办法是看返回里的模型字段、token 用量口径和响应特征，再到 /models 对照规格是否一致。
- 计费口径确认问清输入输出是否同价、缓存怎么算、失败请求是否计费；口径差异的拆解方式可参考 /token-cost 的思路，别只看单价。
- 条款与数据边界确认免费阶段的数据会不会被留存、能不能商用、能否转售，把客服答复截图存下来，作为后续争议的依据。
记录方式：让每一次试用都留痕
很多人后面说不清楚「到底哪变了」，就是因为试用期没记录。记录不需要多复杂，一张表加几条截图就够，关键是字段固定、每次填、两边分开存。字段清单可以直接照搬 /usage-log-fields 的格式。
- 时间
- 精确到分钟，方便和报错日志对齐
- 模型名与参数
- 模型名、输入长度、最大输出设置，缺一项后面就复现不了
- 返回长度与耗时
- 这是判断输出是否被砍的核心证据
- 是否报错与原文
- 报错原文比你的转述可靠得多
- 账号类型
- 试用和付费分开记，重跑时才能做对照
记录之外还有两条纪律：每个结论必须配一条证据，说「并发只能 1」就要有两个并发请求的报错截图，说「输出被砍」就要有返回长度对比；试用账号和付费账号的记录分开存，充钱后第一件事就是拿同一批测试重跑，看哪些限制消失了、哪些换了个形式还在。
这些判断什么时候不适用
上面这套方法不是所有场景都值得做。逐项压测本身有成本，如果你的使用强度很低，花两小时验证可能不如直接换个口碑稳定的渠道。先判断自己属于哪一类，再决定投入多少精力。
- 如果只是偶尔试几个短问题、不打算长期用，那大部分限制对你没影响，没必要逐项压测
- 如果站点明确写了试用与付费同配置、同渠道，只限制总额度，那「换配置」的怀疑可以降级，但仍要验证输出长度和并发
- 企业采购、批量接入的场景，不能靠试用观察代替正式验收，额度、SLA、数据条款要走合同和 /buy-checklist 的流程
- 涉及合规敏感数据时，无论额度多划算，都先解决数据留存和商用授权问题，再谈技术验证
免费额度是让你上头的，验证清单是让你清醒的；掏钱之前多花两小时，充钱之后少后悔两个月。下一步把你看中的渠道放进对照表，逐项跑完试用验证并记下证据，再看当时的额度与分组数字，充钱前先做到心里有数。→
常见问题
试用跑得好好的，为什么充钱后反而变差了？
常见原因是试用和付费走了不同渠道分组：试用可能给的是官方直连或高质量线路，付费后按你的套餐切到成本更低的线路。另外并发、上下文、输出上限也可能在付费档位被重新定义。对策是充钱后用同一批测试重跑，逐项对比，别用感觉判断。
免费额度写着「不限量」，是不是真的随便用？
不限量通常限的是次数而不是资源。背后一般跟着频率上限、并发上限、队列等待或输出长度限制，重的任务会变慢甚至被拒。判断办法是压测长输入和并发，看是报错、排队还是降级。按次与按量哪种更贵，可参考 /per-call-vs-usage-billing 的思路。
怎么判断试用期是不是被换了模型？
别问模型自己是谁，它答的不可靠。更实用的判断是看返回里的模型字段、同题在不同档位的作答差异、以及 token 用量口径是否对得上。拿同一批固定问题在试用和付费两边跑，把返回并排比对，再到 /models 核对规格，差异明显就要问客服。
