切换模型之前，先完成一次可回退的测试

新模型在演示中表现不错，不代表它能直接接替生产环境里的旧模型。正式切换前，应先回答三个问题：现有请求能否正常运行，业务结果是否达标，成本与延迟是否可接受。下面用一套可重复、可回退的流程完成验证。

§ 第一步：固定基线，明确验收标准

记录当前模型、提示词版本、生成参数、工具定义和超时设置。首轮对比只更换模型，避免把提示词调整带来的收益误算成模型提升。例如，从 Claude Sonnet 5.5 测试切换到 GPT-6 Astra 时，先让两者处理相同任务。

• 质量：答案正确、关键事实完整，结构化输出能被程序解析。
• 性能：分别记录首个令牌等待时间、完整响应耗时，以及较慢请求的耗时。
• 可靠性：统计超时、限流、工具调用失败和重试次数。
• 成本：计算完成一次有效业务任务的费用，而不只比较单次请求价格。

§ 第二步：准备一组有代表性的请求

从真实业务中抽取几十条经过脱敏的样本，覆盖常规任务、长上下文、模糊表达、空输入和异常输入。为每条样本保存预期结果或评分规则。不要只挑模型容易答对的问题，也不要用几道困难题代替完整评估。

如果业务依赖工具调用、多轮对话或图片输入，应分别建立对应样本。涉及真实账户和外部系统的操作，先接入沙箱或模拟工具，防止测试触发发信、扣款或数据修改。

§ 第三步：接入候选模型，先跑通最小请求

尚未使用 Vana API，可以先创建账户，获取密钥并配置测试环境。它通过 https://api.vanaapi.com 提供兼容 OpenAI 的接口，同时支持 Anthropic Messages 和 Gemini 原生协议，便于沿用现有客户端的接入方式。

将密钥保存在环境变量中，按所用客户端配置服务地址和模型标识，先发送一条简单请求。随后检查流式输出、结束原因、令牌用量和错误处理。协议能够接通，不等于所有参数和能力完全一致。工具调用、结构化输出及多模态输入仍需逐项验证。

§ 第四步：运行固定测试集，保留原始记录

用同一批样本分别调用基线模型和候选模型，保持输入、输出上限与业务约束一致。若参数不受候选模型支持，应明确记录差异，不要静默忽略。对关键样本重复执行数次，观察结果波动，而不是只保留最好的一次。

每次请求记录样本编号、模型、参数、时间、响应、用量和错误。先用程序检查格式与必填字段，再人工评审事实准确性、任务完成度和表达是否符合业务要求。评审时隐藏模型名称，减少主观偏好。

§ 第五步：核算真实成本与等待时间

Vana API 按实际令牌计费，无月费。对比时应结合模型价格和实际用量核算：输出更长、重试更多，或者需要额外校验，都可能改变最终成本。建议同时统计每条有效结果的平均费用，以及完成同一批任务的总费用。

延迟测试应接近实际使用方式。交互式应用关注首个令牌到达速度，批处理更关注完整任务耗时。单请求测试通过后，再逐步提高并发，确认高峰时的错误率和等待时间仍在验收范围内。

§ 第六步：小流量验证，不直接全量替换

离线测试达标后，在自己的应用或网关中配置流量分配，先让少量请求使用候选模型。比例可从百分之一或百分之五起步，具体取决于请求量和风险。保持同一会话的模型选择稳定，避免多轮对话中途切换造成额外干扰。

若先做影子测试，让候选模型只生成结果、不影响用户，也要注意额外费用和数据处理范围。影子请求不得重复执行有副作用的工具操作。

§ 第七步：验证回退，再扩大流量

上线前保留旧模型配置，预设回退条件，例如错误率超标、关键字段缺失或延迟持续超过预算。亲自演练一次回退，确认新请求能够恢复使用旧模型，并检查在途请求如何处理。

观察覆盖一个有代表性的业务周期后，再分阶段提高流量。最终留下测试集、评分结果、成本记录和切换结论。模型升级不应依赖一次印象不错的回答，而应成为一套下一次仍可复用的发布流程。