早上打开群,站点发公告了:涨价、限速、或者把某个分组拆了。你手里还有余额、有正在跑的任务、有配好的客户端。这篇不讨论公告写得对不对,只解决一件事——先做什么、后做什么、什么时候不用动。三类公告各给一份清单和一段可复制的评估动作。
群里一弹公告,第一反应往往是「完了要不要换站」。其实多数公告不需要你当天做决定,真正要先做的是分清它改了什么、什么时候生效、影响你多少用量。这篇按涨价、限速、分组调整三类给出清单,帮你判断哪些要立刻动手、哪些先观察一两周、哪些只影响某类任务。
下面所有涉及具体数字的地方都不写死,请到站内对应页面核对当时的情况:价格看 /price-watch,站点可信度看 /sites,工具和测速看 /tools/speed-test,横向对比看 /rankings。判断标准可以照抄,数字必须自己现查。
先做三件事,再决定慌不慌
公告本身通常写得含糊,先把它翻译成你自己的处境。别急着在群里问「要不要跑」,先把事实、时间和影响面三件事拆开,很多焦虑会在第三步就消失。
- 把事实和猜测分开:涨的是单价、倍率还是最低充值门槛;限的是并发、速率还是某个分组;分组调整是改名、拆细还是取消了低价渠道。
- 确认生效时间和适用范围:立刻生效还是给过渡期,全站还是只对某类模型、某个分组、某类账号生效。
- 算真实影响面:翻最近一段用量记录,看受影响部分占总消耗的比例,比例低就先别动,比例高再进入后面的处理流程。
涨价公告:分三档处理
涨价最容易让人冲动迁移,但涨的是哪一档、你受影响多少,决定了完全不同的动作。可以对照下表先给自己归个档,再决定要不要动余额和客户端。
| 档位 | 你的情况 | 建议动作 |
|---|---|---|
| 立刻迁移 | 受影响渠道占主要用量,新价高于别处可拿到的价格,且还有未消耗的大额余额 | 暂停续充,先小额验证备选站,再逐步把主力任务切过去 |
| 先观察一两周 | 涨幅小,或不确定替代站稳定性 | 停续充,新任务临时切备选,老余额继续用,到期再复盘 |
| 只挪一部分 | 涨的只是某个高价分组或某类模型 | 把这类任务单独分流,其余保持不动,不必整体换站 |
如果你连自己最近用量结构都不清楚,先去站内把账单和用量导出看一遍;具体单价和倍率到 /price-watch 核对当时的数字,别拿几个月前的印象做决策。
- 抄下公告三个要点变了什么、什么时候生效、影响谁,写成三行贴在手边。
- 拉出最近用量记录标出受影响部分占了多少,占比低于你设定的容忍线就直接进入观察,不动配置。
- 对照同类报价到 /price-watch 和 /rankings 看同类站点的当前情况,把「留 / 分流 / 迁」三种结论各写一句理由。
- 定结论并设复查点选一个结论执行,并记下复查时间,避免每天改主意。
限速公告:先量基线,再谈换不换
限速比涨价更隐蔽,因为「变慢」这件事很主观。没有基线就没法判断是站点退化,还是你自己任务变重了。所以第一步不是骂,是量。
| 限的是什么 | 对交互任务的影响 | 对批量任务的影响 |
|---|---|---|
| 并发数 | 中等,取决于同时在线人数 | 较大,批量脚本容易互相排队 |
| 每分钟请求数 | 中等,长对话感知不明显 | 较大,跑批节奏会被直接打断 |
| 单次输出速度 | 明显,用户在前面等 | 偏小,只影响总时长不影响结果 |
- 用测速工具量基线到 /tools/speed-test 在正常时段跑一遍,记录响应区间,作为后面比对的参照。
- 限速后再量一次同样任务、同样时段、同样网络环境再跑一次,看是明显退化还是回到正常波动范围。
- 按任务类型分开评估把批量任务和交互任务分开看,前者能忍降速,后者不行,别用一套标准套所有场景。
- 决定忍还是分流如果退化只在高峰期且你本来就错峰跑批,通常不用换站;如果交互任务已经不可用,就把这部分单独挪走。
分组调整公告:改的是名字还是能力
分组调整是三类公告里最容易被误解的。改名和换渠道是两件完全不同的事,前者只动你的配置文件,后者可能直接改变输出质量和稳定性。
- 纯改名
- 报价单和客户端里的标识变了,背后渠道没变,改配置即可
- 渠道替换
- 背后的实际来源换了,输出风格、稳定性都可能变化,需要实测
- 拆细分组
- 原来一个分组被拆成多个,计费口径和限制可能各不相同,要逐项对照
- 取消低价渠道
- 原分组消失或并入更贵分组,属于实质性涨价,按涨价流程处理
判断方法很简单:先对照站内渠道分组说明,看新分组和你原分组在计费口径、限制条件上是否等价;再去 /sites 看该站分组调整的历史记录,判断这次是常规维护还是重大变动。
- 挑几个日常真实任务,在新分组下跑一遍,和旧结果比稳定性,别只看接口能不能通。
- 多数情况只需要改 Base URL 或模型名映射,客户端不用重装,改完做一次冒烟测试。
- 如果新分组在计费口径上和旧的不等价,按涨价那一节的三档流程重新判断一次。
一段可复制的评估动作
不管哪类公告,评估流程可以固定成同一套。下面这段可以直接复制到你的笔记里,每次发公告照着填。
- 抄公告要点三行:变了什么、什么时候生效、影响谁。抄不出第三行就说明公告信息不足,先别动。
- 翻用量记录标出受影响部分占比。占比写不出来,说明你还没做用量日志,先去把日志补上再谈迁移。
- 填对照表到 /price-watch、/rankings、/sites 看同类站点当前情况,填「留 / 分流 / 迁」三选一的表,每格写一句理由。
- 设观察期和止损线定一个观察时长和一条止损线(比如交互任务延迟超过某个阈值就迁),到期按预设结论执行,不临时改主意。
公告不可怕,可怕的是没有基线、没有日志、没有预设结论,只能靠情绪做迁移决定。下一步:把基线量出来不管这次公告你要不要动,先把当前站点的价格、延迟、分组情况记一份,下次再发公告你就有对照物了。去 /price-watch 抄价格,去 /tools/speed-test 量延迟,去 /sites 看站点可信度,三件事十分钟能做完。→
常见问题
站点一涨价就该换吗?
不一定。先看涨幅和它占你总消耗的比例。如果涨的只是你用得不多的分组,或者涨幅低于你迁移的折腾成本,留下继续用更划算。真正该立刻动的是:主要用量渠道涨价、你余额还很多、且已经有验证过的备选站。
限速公告之后怎么判断是站的问题还是我自己的问题?
先量基线再下结论。用站内测速工具在限速前后各测一次,如果只有你的请求慢、别的时间段正常,多半是高峰或你的并发设置问题;如果全天都慢、且换了客户端也一样,才考虑是站点侧的限制。
分组调整之后客户端要重配吗?
多数情况只要改模型名映射或分组标识即可,Base URL 通常不变。但如果公告说明是渠道替换,除了改配置,还要用小额实测验证输出质量是否对得上原来的预期,别默认新分组和旧分组等价。