很多人卡在同一个地方：ChatGPT 用着挺顺手，但一想到成本、访问稳定性、数据出不出内网，就开始琢磨换模型。问题是换谁的、换几成、换完怎么验证，没个准谱就容易白折腾一轮。这篇不讲谁强谁弱，只给一套从需求清单到灰度上线的判断顺序，让你在半天内把候选缩到一两个，并且知道什么情况下压根不该换。
很多人卡在同一个地方：ChatGPT 用着挺顺手，但一想到成本、访问稳定性、数据出不出内网，就开始琢磨换模型。问题是换谁的、换几成、换完怎么验证，没个准谱就容易白折腾一轮。
这篇不讲谁强谁弱，只给一套从需求清单到灰度上线的判断顺序，让你在半天内把候选缩到一两个，并且知道什么情况下压根不该换。先把任务、成本、合规、迁移四道关过一遍，比上来就注册十家账号试要省事得多。
先划能力边界：哪些活 ChatGPT 能接、替代品接不住
换模型最容易踩的坑是「感觉差不多」。文本任务看着都行，真跑起来差距往往出现在格式稳定性和边缘请求处理上。所以第一步不是去各家注册账号，而是把自己手头的活拆开，看清楚哪些是必须的、哪些是可以妥协的。
- 纯文本生成与改写：摘要、润色、翻译、写草稿，这一类替代模型基本都能接，差异主要在语气和啰嗦程度
- 结构化抽取与分类：从邮件里抠字段、给工单打标签，这类看的是格式稳定性，最容易出现模型换了以后 JSON 少个括号
- 长文档理解：合同、论文、长报告，这类拼的是上下文长度和中间信息的保持能力，要专门测
- 多模态输入输出：图片、语音、视频，先确认你实际用到哪几种，很多替代品只做了文本和图片，语音视频未必齐全
- 抽样做固定题面从最近两周的对话记录里挑十条最有代表性的任务，去掉人名和业务数据，整理成一份固定题面。后面所有候选模型都跑这份题面，结果才好横向比。
- 单独标记格式敏感任务把必须固定格式输出、必须带引用、必须拒绝某类请求的任务单独列一栏。这类任务换模型后最容易漂移，验收时要单独打分，不能混在总体感受里。
- 算工具链绑定的成本已经接进 IDE 的补全、已经写进代码里的函数调用，换模型不只是换模型，还要算改代码和重测的时间。如果这块占比高，往往不值得为了小幅度改善去折腾。
成本与延迟：别只比单价，要比一次任务的总账
单价是最容易误导人的指标。一次任务可能包含多轮对话加一次长文档输入，输入侧的量往往比输出侧大，光看每千 token 的输出价格会算出完全不同的结论。想清楚自己一次任务到底消耗多少，再去比价才有意义。
| 对比维度 | 怎么量 | 容易忽略的点 |
|---|---|---|
| 单次任务成本 | 按输入加输出的总用量估算 | 长文档输入侧成本常被低估 |
| 首字延迟 | 交互场景关注从提交到第一个字的时间 | 高峰期和闲时差别明显 |
| 整体完成时间 | 批量脚本关注跑完一条任务的总耗时 | 并发上限会拖长整体时间 |
| 限速与并发 | 看账号档位允许的同时请求数 | 批量任务才会暴露这个瓶颈 |
算这两笔账可以借助站内工具：用 /tools/model-cost-calculator 和 /tools/token-price-calculator 按自己的用量把两种模型各算一遍；想先排除网络因素，用 /tools/speed-test 跑一轮，把结果作为自己的基线，再判断差异是模型慢还是线路慢。
另外注意订阅制和按量计费是两套算法。如果你主要用对话式产品而不是 API，先去站内的套餐页面看当时的地区价，再和按量价格比，不要默认某一种一定更划算。具体档位和额度到 /official-api 和 /inference 按当前口径核对，这些数字会变。
合规与部署形态：数据能不能出去，决定了一半的候选
这一节经常被放到最后才想，结果前面比了半天发现候选里一半根本不能用。其实只要先回答一个问题：要处理的文本里有没有不适合发给第三方的内容。如果有，候选范围会自动缩到可私有化部署或可签数据处理协议的那一档。
- 可私有化部署
- 模型权重能放到自己机器上跑，数据不出内网，代价是要自己管算力和运维
- 数据处理协议
- 走第三方接口但要求对方承诺不留存、不训练，需要看条款细节而不是口头承诺
- 商用与再分发许可
- 决定你能不能把它嵌进对外卖的产品里，很多开源许可在这一点上限制不同
评估私有化部署时，先算显存和并发，再算许可证。显存和卡数测算可以用 /models/deploy 和 /compute/sizing 过一遍，许可证部分重点看商用边界和再分发限制。如果走中转或聚合平台，要额外做一次可信度检查，这块的口径和方法在 /tools/verify 上有实测探针和评分规则，建议先看规则再看结果，避免被单一指标带偏。
- 至少留一条主模型不可用时的降级路径，比如切到另一个厂商的同档模型，或者退回预设模板
- 这条降级路径要提前测过，不是写在文档里就算数
- 定期复查所选平台的条款变更，合规要求是会变的，不是一次确认就永久有效
迁移顺序：小步灰度，先跑影子流量
前面三步定完候选，最后就是怎么切。最常见的翻车方式是一次性全量替换，出问题才发现没有回退路径。稳妥的做法是分三步走，每一小步都有明确的观察指标。
- 影子对比，不碰线上把同样的输入同时发给旧模型和新模型，记录输出差异，人工抽检二十到三十条，看新模型有没有系统性偏差，比如更啰嗦、更容易编造、更爱拒答。
- 切一个低风险场景挑内部草稿生成或日志摘要这类场景先真切换，跑一到两周。重点看两件事：输出被人工改动的比例有没有上升，下游有没有因为格式变化而报错。
- 扩到核心场景前重调提示词很多提示词是针对原模型的措辞习惯调出来的，直接搬过去效果会打折。扩量之前把提示词重新过一遍，尤其是需要严格格式的那些。
- 保留回退开关哪怕只切一个接口，也要留一键切回旧模型的能力，并记录每次切换的原因，方便复盘问题出在模型还是提示词。
要横向看各家当前的可用状态和实测情况，可以到 /rankings 和 /price-watch 对照当时的记录，再决定候选顺序。灰度阶段出了问题，先查自己的提示词和参数，再怀疑模型本身。
下一步把你手头最典型的十条任务整理成固定题面，然后去站内把候选模型的当前价格和可用状态核一遍，再决定要不要进影子对比。→常见问题
ChatGPT 和替代模型的差距主要体现在哪？
多数情况下差距不在「能不能答对」，而在长链条任务的稳定性、指令跟随的严格程度，以及生态工具链的完整度。单轮问答往往拉不开差距，一旦变成多步骤、要固定格式、要接外部工具，掉链子的概率就会显出来。所以评估时别只测单点问答，要测完整任务链路。
什么情况下不建议换模型？
三种情况建议先别动：一是任务强依赖某家独有的能力或工具链，换过去要重写大量代码；二是当前用量很小，省下的钱还不够覆盖迁移和验证的人力；三是业务对输出稳定性极度敏感，且没有足够的灰度期。这几种情况下，优化提示词和调用方式通常比换模型收益更快。
换模型之后效果变差，从哪查起？
按顺序排查：先看是不是提示词没重调，这是最常见的原因；再看输入长度有没有超出新模型的上下文上限，超了会被截断；然后检查输出格式是否被下游解析器拒掉；最后才怀疑模型本身能力。建议每次只改一个变量，改完立刻用同一份固定题面复测，不然分不清是哪一步出的问题。
